linux-pm.vger.kernel.org archive mirror
 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:53 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).