| Message ID | 20220107184614.2670254-1-f.fainelli@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | BCMA support for brcmnand | expand |
Florian, On Fri, Jan 7, 2022 at 1:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > Hi all, > > This patch series adds support for the BRCMNAND controller revision 3.4 > embedded in MIPS-based SoCs such as 5357, typically found in the Netgear > WNR3500L v2 and other kinds of Wi-Fi routers. The upstream platform that > uses this controller is under arch/mips/bcm47xx/ and does not use Device > Tree (and probably never will by now). BCMA (Broadcom AMBA) is a special > kind of discoverable memory mapped interface which requires the use of > special accessors to read from/write to the hardware block. > > The integration of brcmnand into that SoC is a bit quirky in that every > register offering byte level data about the flash (OOB, device ID, etc.) > requires byte swapping. The command shift should also have been 24, but > is in fact 0, took me a while to understand why no reads were actually > working because of that. > > This has been tested with Linux 5.10.82 and Linus' master with OpenWrt > and confirmed that the squashfs + jffs2 overlay that OpenWrt creates is > entirely functional and that written data is made persistent. > > Changes in v3: > > - fixed a few typo/grammar errors in the commit messages, mention when > changes are non functional changes > - removed the stray hunk in 2 to enable the static key > > Changes in v2: > > - re-ordered the patch such that the soc variable is initialized as > early as possible > - corrected bug in the conversion of brcmnand_init_cs() which > incorrectly used the wrong device_node variable (parent instead of > child) > - took Andy's feedback to make the test for a valid interrupt to be > 0 > while calling platform_get_irq_optional() > - utilized static branch (disabled by default) and conditional > compilation and confirm with disassembly that the generated code is > as efficient as before if not enabling the BCMA shim and as efficient > as possible if enabling BCMA shim > - updated BCMA shim driver descriptor, author and added helper function > to encapsulate the container_of usage > - added comment to explain why a slightly different platform device name > is used for the 5357-style NAND controller > > Florian Fainelli (9): > mtd: rawnand: brcmnand: Assign soc as early as possible > mtd: rawnand: brcmnand: Allow SoC to provide I/O operations > mtd: rawnand: brcmnand: Avoid pdev in brcmnand_init_cs() > mtd: rawnand: brcmnand: Move OF operations out of brcmnand_init_cs() > mtd: rawnand: brcmnand: Allow working without interrupts > mtd: rawnand: brcmnand: Add platform data structure for BCMA > mtd: rawnand: brcmnand: Allow platform data instantation > mtd: rawnand: brcmnand: BCMA controller uses command shift of 0 > mtd: rawnand: brcmnand: Add BCMA shim > > MAINTAINERS | 1 + > drivers/bcma/driver_chipcommon_nflash.c | 20 ++- > drivers/mtd/nand/raw/Kconfig | 13 ++ > drivers/mtd/nand/raw/brcmnand/Makefile | 2 + > drivers/mtd/nand/raw/brcmnand/bcma_nand.c | 132 ++++++++++++++++ > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 160 +++++++++++++------- > drivers/mtd/nand/raw/brcmnand/brcmnand.h | 29 ++++ > include/linux/bcma/bcma_driver_chipcommon.h | 5 + > include/linux/platform_data/brcmnand.h | 12 ++ > 9 files changed, 321 insertions(+), 53 deletions(-) > create mode 100644 drivers/mtd/nand/raw/brcmnand/bcma_nand.c > create mode 100644 include/linux/platform_data/brcmnand.h > > -- > 2.25.1 > The patch series as in v3 LGTM Kamal
Hi Florian, f.fainelli@gmail.com wrote on Fri, 7 Jan 2022 10:46:05 -0800: > Hi all, > > This patch series adds support for the BRCMNAND controller revision 3.4 > embedded in MIPS-based SoCs such as 5357, typically found in the Netgear > WNR3500L v2 and other kinds of Wi-Fi routers. The upstream platform that > uses this controller is under arch/mips/bcm47xx/ and does not use Device > Tree (and probably never will by now). BCMA (Broadcom AMBA) is a special > kind of discoverable memory mapped interface which requires the use of > special accessors to read from/write to the hardware block. > > The integration of brcmnand into that SoC is a bit quirky in that every > register offering byte level data about the flash (OOB, device ID, etc.) > requires byte swapping. The command shift should also have been 24, but > is in fact 0, took me a while to understand why no reads were actually > working because of that. > > This has been tested with Linux 5.10.82 and Linus' master with OpenWrt > and confirmed that the squashfs + jffs2 overlay that OpenWrt creates is > entirely functional and that written data is made persistent. Series applied on nand/next. Thanks, Miquèl