All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Lubomir Rintel <lkundrak@v3.sk>, Lee Jones <lee.jones@linaro.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Pavel Machek <pavel@ucw.cz>, Dan Murphy <dmurphy@ti.com>,
	Sebastian Reichel <sre@kernel.org>,
	devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-leds@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for KB930 and Acer A500
Date: Tue, 8 Sep 2020 15:53:52 -0600	[thread overview]
Message-ID: <20200908215352.GA989862@bogus> (raw)
In-Reply-To: <c536557c-de42-d6bd-890c-ef71ca0e3116@gmail.com>

On Mon, Aug 24, 2020 at 01:09:22PM +0300, Dmitry Osipenko wrote:
> 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?

Seems like separate bindings makes sense here.

Rob

  reply	other threads:[~2020-09-08 21:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-23 14:08 [PATCH v1 0/6] Introduce Embedded Controller driver for Acer A500 Dmitry Osipenko
2020-08-23 14:08 ` [PATCH v1 1/6] mfd: Add driver for Embedded Controller found on Acer Iconia Tab A500 Dmitry Osipenko
2020-08-23 18:16   ` Lubomir Rintel
2020-08-23 19:28     ` Dmitry Osipenko
2020-08-24  7:33       ` Lee Jones
2020-08-24 10:10         ` Dmitry Osipenko
2020-08-24 10:43           ` Lee Jones
2020-08-23 14:08 ` [PATCH v1 2/6] power: supply: Add battery gauge driver for " Dmitry Osipenko
2020-08-24 14:07   ` Sebastian Reichel
2020-08-24 18:55     ` Dmitry Osipenko
2020-08-24 21:38       ` Sebastian Reichel
2020-08-26  6:34         ` Dmitry Osipenko
2020-08-23 14:08 ` [PATCH v1 3/6] leds: Add " Dmitry Osipenko
2020-08-23 22:30   ` Pavel Machek
2020-08-24 10:11     ` Dmitry Osipenko
2020-08-24 11:38     ` Dmitry Osipenko
2020-08-23 22:34   ` Pavel Machek
2020-08-24 10:16     ` Dmitry Osipenko
2020-08-23 14:08 ` [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for KB930 and Acer A500 Dmitry Osipenko
2020-08-23 18:20   ` Lubomir Rintel
2020-08-23 19:31     ` Dmitry Osipenko
2020-08-23 21:16       ` Lubomir Rintel
2020-08-24 10:09         ` Dmitry Osipenko
2020-09-08 21:53           ` Rob Herring [this message]
2020-09-08 22:01             ` Dmitry Osipenko
2020-08-23 14:08 ` [PATCH v1 5/6] dt-bindings: mfd: ene-kb3930: Document power-supplies and monitored-battery properties Dmitry Osipenko
2020-08-23 18:00   ` Lubomir Rintel
2020-08-23 14:08 ` [PATCH v1 6/6] ARM: tegra: acer-a500: Add Embedded Controller Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200908215352.GA989862@bogus \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=dmurphy@ti.com \
    --cc=jonathanh@nvidia.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lkundrak@v3.sk \
    --cc=pavel@ucw.cz \
    --cc=sre@kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.