Thread (28 messages) 28 messages, 6 authors, 2020-09-08

Re: [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for KB930 and Acer A500

From: Dmitry Osipenko <digetx@gmail.com>
Date: 2020-08-24 10:09:41
Also in: linux-devicetree, linux-leds, linux-tegra, lkml

24.08.2020 00:16, Lubomir Rintel пишет:
Hello,

On Sun, Aug 23, 2020 at 10:31:36PM +0300, Dmitry Osipenko wrote:
quoted
23.08.2020 21:20, Lubomir Rintel пишет:
quoted
On Sun, Aug 23, 2020 at 05:08:44PM +0300, Dmitry Osipenko wrote:
quoted
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/ (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.
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help