LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Heikki Krogerus <firstname.lastname@example.org>
To: Alexandre Courbot <email@example.com>
Cc: Linus Walleij <firstname.lastname@example.org>,
"Rafael J. Wysocki" <email@example.com>,
"Rafael J. Wysocki" <firstname.lastname@example.org>,
Darren Hart <email@example.com>,
Arnd Bergmann <firstname.lastname@example.org>,
Andy Shevchenko <email@example.com>,
Mika Westerberg <firstname.lastname@example.org>,
ACPI Devel Maling List <email@example.com>
Subject: Re: [RFC PATCH] gpio: support for GPIO forwarding
Date: Thu, 12 Feb 2015 14:38:19 +0200 [thread overview]
Message-ID: <20150212123819.GB18860@kuha.fi.intel.com> (raw)
On Tue, Feb 10, 2015 at 06:44:34PM +0900, Alexandre Courbot wrote:
> On Wed, Feb 4, 2015 at 11:11 PM, Heikki Krogerus
> <firstname.lastname@example.org> wrote:
> > On Wed, Feb 04, 2015 at 10:51:27AM +0100, Linus Walleij wrote:
> >> On Fri, Jan 30, 2015 at 5:17 PM, Rafael J. Wysocki <email@example.com> wrote:
> >> > On Friday, January 30, 2015 03:48:30 PM Linus Walleij wrote:
> >> >> So you could detect one by making a checksum of the binary or something.
> >> >>
> >> >> And then you'd know that the table with this checksum needs patching?
> >> >
> >> > At a single table level it is generally difficult to say whether or not
> >> > things are going to work.
> >> >
> >> > What needs to work is the namespace which is built from all of the tables
> >> > provided combined. So the namespace needs to be populated first and then
> >> > fixes applied on top of that (presumably by deleting, adding or replacing
> >> > objects).
> >> >
> >> > Now, in theory, you *may* be able to figure out that combination of tables
> >> > A produces namespace B which then will require fix X if the system is Y,
> >> > but quite frankly I wouldn't count on that.
> >> >
> >> > Moreover, fixups (or "patches" as I called them, but that wasn't exactly
> >> > correct) need to be provided in the form of AML definition blocks to apply on
> >> > top of an already populated namespace and if you want to use a binary kernel image,
> >> > you can't really afford putting all that stuff for all systems it can possibly
> >> > run on into it. This means that distros need to be able to combine a fixup for
> >> > the ACPI tables with the binary kernel and install the result into the system's
> >> > boot medium (whatever it is). Also it should be possible to update the fixup
> >> > and the kernel image separately if necessary.
> >> >
> >> > Now from the kernel's perspective that raises the question: "What if the
> >> > ACPI tables fixup provided by the distro is not sufficient?"
> >> >
> >> > That needs to be addressed somehow in the code.
> >> Yeah I guess I'm convinced that we need to handle this particular
> >> weirdness in the gpio-acpi code... if it can be contained there as
> >> expressed by Alexandre.
> > I'm still fine if we want to confine this "gpio forwarding" to acpi
> > if you guys want it, but I was looking at the Sound SoC drivers and I
> > realised that we do have places which pass gpio descriptors to other
> > devices in platform data. And these of course aren't always used on
> > acpi platforms. By greping gpio_desc I saw at least these files are
> > passing it in platform data structures:
> > include/sound/soc.h
> > include/linux/leds.h
> > include/linux/usb/usb_phy_generic.h
> > There are probable others but I checked those. And of course now there
> > is nothing preventing people from adding more of them.
> For sound/soc.h, the member is indeed public but I don't see it being
> used to pass descriptors around between drivers.
> For linux/leds.h, I think this is the reason why we introduced
> These looks more like a bad usage of GPIO descriptors, but AFAICT they
> can be fixed by fixing the drivers and, by all means, this is where we
> should do it.
> This is a different situation from yours where we are trying to deal
> with broken firmware and need to resort to tricks at one point or the
> Or am I missing your point?
Well, in this case the motivation would be to make it possible to live
without platform data with these drivers, but in the end the situation
would be exactly the same. We need to give a gpio descriptor to
some other device in a driver. So the goal would be that in the actual
consumer driver of the gpio we could request it always in one way,
ideally always with gpiod_get() call.
But if there is no real need in other places for this thing, then
let's forget about it.
prev parent reply other threads:[~2015-02-12 12:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 8:23 Heikki Krogerus
2015-01-08 8:25 ` Heikki Krogerus
2015-01-15 9:21 ` Rafael J. Wysocki
2015-01-14 12:58 ` Linus Walleij
2015-01-14 16:32 ` Darren Hart
2015-01-15 9:28 ` Rafael J. Wysocki
2015-01-15 9:40 ` Heikki Krogerus
2015-01-14 16:32 ` Darren Hart
2015-01-19 5:59 ` Alexandre Courbot
2015-01-19 11:53 ` Heikki Krogerus
2015-01-20 12:16 ` Linus Walleij
2015-01-20 21:25 ` Rafael J. Wysocki
2015-01-22 2:57 ` Alexandre Courbot
2015-01-22 16:14 ` Rafael J. Wysocki
2015-01-23 11:21 ` Heikki Krogerus
2015-01-23 15:14 ` Rafael J. Wysocki
2015-01-26 13:06 ` Heikki Krogerus
2015-02-10 9:32 ` Alexandre Courbot
2015-02-10 15:10 ` Rafael J. Wysocki
2015-02-12 12:46 ` Heikki Krogerus
2015-02-24 20:34 ` David Cohen
2015-02-25 1:34 ` Alexandre Courbot
2015-02-25 18:25 ` David Cohen
2015-03-07 22:13 ` Linus Walleij
2015-01-22 8:17 ` Linus Walleij
2015-01-22 16:12 ` Rafael J. Wysocki
2015-01-30 14:48 ` Linus Walleij
2015-01-30 16:17 ` Rafael J. Wysocki
2015-02-04 9:51 ` Linus Walleij
2015-02-04 14:11 ` Heikki Krogerus
2015-02-10 9:44 ` Alexandre Courbot
2015-02-12 12:38 ` Heikki Krogerus [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [RFC PATCH] gpio: support for GPIO forwarding' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).