On 01-09-17 23:38, Rob Herring wrote:
On Fri, Sep 1, 2017 at 2:10 PM, Arend van Spriel
<arend.vanspriel@xxxxxxxxxxxx> wrote:
On 01-09-17 18:49, Rob Herring wrote:
On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote:
hi,
On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote:
On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony <antony@xxxxxxxxxxx>
wrote:
a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
+++
b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
@@ -6,7 +6,9 @@ connects the device to the system.
Required properties:
- - compatible : Should be "brcm,bcm4329-fmac".
+ - compatible : should be one of the following:
+ * "brcm,bcm4329-fmac"
+ * "brcm,bcm43430-fmac"
You updated the bindings, but not the driver. So it's not actually
going to work. More specifically, OOB interrupts won't work.
understood, ignore this patch for now. Thanks Chen-Yu.
IIRC, The compatible string for this particular case, as it was
originally proposed, only serves as a placeholder for the driver
to check against. None of the instances in sunxi device trees
match the actual chip model. Actual model matching is done
through SDIO, as you've already seen.
yes it seems SDIO driveer code is smarter, once it initialize
brcm,bcm4329-fmac it ignore the DT info and read the chip details to
locate
firmware file.
I also noticed other boards using bcm4329-fmac in similar situations.
https://patchwork.kernel.org/patch/9739181/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7
I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see
where
it goes.
Adding the compatible or instead of? The former would be better. You
should still have the actual chip in case you do have some difference to
handle.
Hi Rob,
Actually the Broadcom wifi chips themselves are discoverable. So once the
driver has access to the register space of the device it can determine the
actual chip, its revision, and exactly what cores (and their revision) are
present in the chip. Hence there is a single compatible string as there is
no need to convey the same information through device tree data.
So if a chip has different power on/off sequencing you can discover that?
I realize that most often you don't need it, but a more specific
compatible is there in case you do and so it doesn't require a DTB
update to handle some difference. But you can keep using one
compatible because I can't really enforce any of that.
For SDIO chips the power sequencing is defined by power-seq-* in
bindings/mmc and handled by the MMC stack itself. So the wifi driver is
not dealing with that.
Regards,
Arend
