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]
Message-ID: <c536557c-de42-d6bd-890c-ef71ca0e3116@gmail.com>
Date:   Mon, 24 Aug 2020 13:09:22 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Lubomir Rintel <lkundrak@...sk>, Rob Herring <robh+dt@...nel.org>
Cc:     Lee Jones <lee.jones@...aro.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Pavel Machek <pavel@....cz>, Dan Murphy <dmurphy@...com>,
        Sebastian Reichel <sre@...nel.org>, devicetree@...r.kernel.org,
        linux-tegra@...r.kernel.org, linux-leds@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for
 KB930 and Acer A500

24.08.2020 00:16, Lubomir Rintel пишет:
> Hello,
> 
> On Sun, Aug 23, 2020 at 10:31:36PM +0300, Dmitry Osipenko wrote:
>> 23.08.2020 21:20, Lubomir Rintel пишет:
>>> On Sun, Aug 23, 2020 at 05:08:44PM +0300, Dmitry Osipenko wrote:
>>>> The ENE KB930 hardware is compatible with KB3930.
>>>>
>>>> Acer A500 Iconia Tab is Android tablet device, it has KB930 controller
>>>> that is running firmware specifically customized for the needs of the
>>>> Acer A500 hardware. This means that firmware interface isn't re-usable
>>>> by other non-Acer devices. Some akin models of Acer tablets should be
>>>> able to re-use the FW interface of A500 model, like A200 for example.
>>>>
>>>> This patch adds the new compatibles to the binding.
>>>
>>> I've responded to patch 5/6 with what should've been said here [1].
>>> Sorry for the confusion.
>>>
>>> In any case please consider adding a new binding file instead of
>>> modifying the kb3930 binding doc. It would also remove a dependency on
>>> my patch set which should have slipped out of maintainers' radar.
>>>
>>> [1] https://lore.kernel.org/lkml/20200823180041.GB209852@demiurge.local/
>>
>> Hello, Lubomir! I was doing some research about the differences of
>> KB3930 and KB930 before created this patch and my understanding is that
>> the controllers are mostly identical. I've seen posts from people who
>> replaced KB3930 with KB930 (and vice versa) on various notebooks and it
>> worked, although not always.
>>
>> It's a very common practice to re-use binding in a case of a sibling
>> hardware. Do you know what are the exact differences between KB3930 and
>> KB930 which could justify having separate bindings?
>>
>> The firmware implementation varies a lot from device to device,
> 
> It sometimes does. The ENE's downstream driver suggests there are parts
> that run more-or-less stock firmware that are comatible with each other.
> That is why I grabbed the generic kb3930 name.
> 
>> and
>> thus, each device needs to have its own driver in order to talk to the
>> firmware, but hardware description (i.e. DT binding) should be common
>> for all devices.
> 
> Note the DT is not the hardware description. It's the description of how
> the hardware presents itself, from the software's perspective. As far as
> that is concerned, the devices don't seem to have anything in common at
> all (other than the bus address). The fact that you need an entirely
> different driver implies this.
> 
> This would be the case even if the A500 EC was based directly on a KB3930.
> 
> A good reason to keep bindings for different yet somewhat similar devices in
> a single document is to avoid duplication. Yet here there's very little to
> share here. If you've done your bindings correctly, you'd need to
> conditionalize the monitored-battery and power-supplies properties for
> acer,a500-iconia-ec, complicating the binding too much. It makes more
> sense to just add a new document.

Alright, I don't mind to separate the bindings. Although, before doing
that, I'd want to get opinion from the device-tree experts, i.e. from
Rob Herring :)

Rob, will it be fine to have separate bindings for each firmware version
of the ENE controller given that firmware is individual for every device
and given that FW has no compatibility with other devices?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ