Probing devices by their less-specific "compatible" bindings (here: brcmnand)

[William Zhang]

On 03/17/2023 02:54 PM, Florian Fainelli wrote:
> +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 at 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?
> 
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?

>>
>> 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.
>>
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?

>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4212 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20230317/d39f9356/attachment-0001.p7s>