linux-kernel - Re: [PATCH] dt-bindings: i2c: Add armada-38x i2c 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] [day] [month] [year] [list]

Message-ID: <CAL_JsqKq1Gb3wvWEY0xJYsz=f5_1Y7G_t6LSgP1BuAK5rmU8zw@mail.gmail.com>
Date:   Wed, 4 Oct 2017 08:33:35 -0500
From:   Rob Herring <robh@...nel.org>
To:     Gregory CLEMENT <gregory.clement@...e-electrons.com>
Cc:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
        Kalyan Kinthada <Kalyan.Kinthada@...iedtelesis.co.nz>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "wsa@...-dreams.de" <wsa@...-dreams.de>,
        "pawel.moll@....com" <pawel.moll@....com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
        "galak@...eaurora.org" <galak@...eaurora.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dt-bindings: i2c: Add armada-38x i2c binding

On Wed, Oct 4, 2017 at 7:52 AM, Gregory CLEMENT
<gregory.clement@...e-electrons.com> wrote:
> Hi Rob,
>
>  On mer., oct. 04 2017, Rob Herring <robh@...nel.org> wrote:
>
>> On Wed, Oct 4, 2017 at 3:33 AM, Gregory CLEMENT
>> <gregory.clement@...e-electrons.com> wrote:
>>> Hi Rob,
>>>
>>>  On mar., oct. 03 2017, Rob Herring <robh@...nel.org> wrote:
>>>
>>>> On Wed, Sep 27, 2017 at 09:33:00AM +0200, Gregory CLEMENT wrote:
>>>>> Hi Chris,
>>>>>
>>>>>  On mer., sept. 27 2017, Chris Packham <Chris.Packham@...iedtelesis.co.nz> wrote:

[...]

>>>>> If the IP is compatible then there is no reason to add a new one, else
>>>>> we will end with a compatible for each SoC and the compatible property
>>>>> will just loose its meaning.
>>>>
>>>> If you all had added compatibles for each SoC in the first place, then
>>>> we wouldn't be having this dicussion.
>>>
>>> Really??
>>>
>>> For Armada 38x we have already 6 flavor 381, 382, 383, 385, 388.  Then
>>> we have 9 SoC families on mvebu: orion5x, kirkwood, dove, Armada 370,
>>> Armada XP, Armada 375, Armada 39x, Armada 7K, Armada 8K. Of course in
>>> each family we have several flavors.
>>>
>>> But then Allwiner also use this driver in 8 SoC families: sun4i, sun5i,
>>> sun6i, sun7i, sun8i, sun9i, sunxi, sun50i. Here again each family have
>>> their own flavor.
>>>
>>> So you are just suggesting to blot the i2c driver with more than 50
>>> compatible string!
>>
>> No.
>>
>>> That also mean updating the i2c driver each time a new SoC flavor
>>> appear, so more or less for each release.
>>
>> No. You can have one or several fallbacks. Use the fallback as long as
>> you think they are the same and then add the more specific one to the
>> driver when you find differences.
>
> So you mean adding all the possible variant of the SoC in the binding
> documentation, but only implement them in the driver when needed?

Yes, and in the dts files. If some are the same die, but just
different packaging or fusing then I would not distinguish those. But
I realize you probably don't have that information being outside of
Marvell.

For the older parts, I'd guess they've been around long enough you've
either found the differences by now or few people care anymore, so I'm
not saying go back and add possible string now.

Rob