netdev - Re: [PATCH] dt: bindings: Add a generic ethernet device binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 Jul 2016 12:18:40 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Chen-Yu Tsai <wens@...e.org>, netdev@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH] dt: bindings: Add a generic ethernet device binding

Hi,

On 15-07-16 22:42, Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 12:20:04 PM CEST Hans de Goede wrote:
>> +&mmc1 {
>> +       non-removable;
>> +       status = "okay";
>> +
>> +       sdio_wifi: sdio_wifi@1 {
>> +               compatible = "generic,ethernet"
>> +               reg = <1>;
>> +       };
>> +};
>
> For discoverable buses, we normally use a compatible property that
> reflects the device ID on that bus, e.g. on PCI we have "pci1A2B:3C4D"
> and I think that makes more sense than having to come up with strings
> for sdio devices.

2 things:

1) The problem here is that different batches of the same board
(cheap chinese tablet) have different sdio wifi modules, so we
actually cannot specify a vendor / product id as in your example.

2) In some cases we do want an actual compatible because some devices
have some oob (out-of-band) going with e.g. gpio-s which cannot be
handled by mmc-pwrseq.

> In fact, Linux completely ignores the compatible strings on those
> buses (pci, usb, sdio, ...),

You're mostly right, but at least the brcmfmac driver looks for a
compatible in the mmc-host child node describing its sdio function
to see if it should check for oob irq information there.

> so I think we can just do the same thing
> using no compatible string at all.

I'm all for not using any compatible string at all, actually I submitted
a patch for a sunxi dt file which did that and Maxime pointed out that
the compatible is listed as Required in:
Documentation/devicetree/bindings/mmc/mmc-card.txt

If we can agree to make it optional, then I'll happily submit a patch
with that change and Maxime can take my sunxi dts patch as is :)

Regards,

Hans