On 03/17/2023 02:54 PM, Florian Fainelli wrote:
Same question here. I just tried latest linux master code on my 4908 reference board and the Micron NAND on my board works fine. Can you post the log from the brcmnand driver?+William, On 3/17/23 03:02, Rafał Miłecki wrote:Hi, I just spent few hours debugging hidden hw lockup and I need to consult driver core code behaviour. I have a BCM4908 SoC based board with a NAND controller on it. ### Hardware binding Hardware details: arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi Relevant part: nand-controller@1800 {compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";reg = <0x1800 0x600>, <0x2000 0x10>; reg-names = "nand", "nand-int-base"; }: Above binding is based on the documentation: Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml ### Linux drivers Linux has separated drivers for few Broadcom's NAND controller bindings: 1. drivers/mtd/nand/raw/brcmnand/bcm63138_nand.c for: brcm,nand-bcm63138 2. drivers/mtd/nand/raw/brcmnand/brcmnand.c for: brcm,brcmnand-v2.1 brcm,brcmnand-v2.2 brcm,brcmnand-v4.0 brcm,brcmnand-v5.0 brcm,brcmnand-v6.0 brcm,brcmnand-v6.1 brcm,brcmnand-v6.2 brcm,brcmnand-v7.0 brcm,brcmnand-v7.1 brcm,brcmnand-v7.2 brcm,brcmnand-v7.3 3. drivers/mtd/nand/raw/brcmnand/brcmstb_nand.c for: brcm,brcmnand ### Problem As first Linux probes my hardware using the "brcm,nand-bcm63138" compatibility string driver bcm63138_nand.c. That's good. It that fails however (.probe() returns an error) then Linux core starts probing using drivers for less specific bindings.Why does it fail?
Are you saying the bcm63138_nand.c probe function return -EPROBE_DEFER and late on kernel call brcmstb_nand.c probe instead of bcm63138_nand's probe again?In my case probing with the "brcm,brcmnand" string driver brcmstb_nand.c results in ignoring SoC specific bits and causes a hardware lockup. Hw isn't initialized properly and writel_relaxed(0x00000009, base + 0x04) just make it hang.Well, the missing piece here is that brcmnand.c is a library driver, therefore it needs an entry point, the next one that matches is brcmstb_nand.c.That obviously isn't an acceptable behavior for me. So I'm wondering what's going on wrong here. Should Linux avoid probing with less-specific compatible strings? Or should I not claim hw to be "brcm,brcmnand" compatible if it REQUIRES SoC-specific handling? An extra note: that fallback probing happens even with .probe() returning -EPROBE_DEFER. This actually smells fishy for me on the Linux core part. I'm not an expect but I think core should wait for actual error without trying less-specific compatible strings & drivers.
______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
