LKML Archive on
help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <>
To: Linus Walleij <>
Cc: Alexandre Courbot <>,
	Heikki Krogerus <>,
	"Rafael J. Wysocki" <>,
	Darren Hart <>,
	Arnd Bergmann <>,
	Andy Shevchenko <>,
	Mika Westerberg <>,
	"" <>,
	"" <>,
	ACPI Devel Maling List <>
Subject: Re: [RFC PATCH] gpio: support for GPIO forwarding
Date: Tue, 20 Jan 2015 22:25:17 +0100	[thread overview]
Message-ID: <4078818.ecVtLF3hjd@vostro.rjw.lan> (raw)
In-Reply-To: <>

On Tuesday, January 20, 2015 01:16:06 PM Linus Walleij wrote:
> On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot <> wrote:
> > I am not really fond of this idea since it adds complexity to the
> > (already too complex) GPIO lookup, and only solves to a local level
> > (GPIO) what is a more global problem (bad ACPI tables that can affect
> > any subsystem).
> (...)
> > it
> > seems more to-the-point to find a way to fix/patch the ACPI tables at
> > runtime, if that is possible at all, to provide a more general
> > solution to this issue.
> This is my position as well, until proven that this cannot be done.

Well, that goes against the current practice, mind you, which *is* to put
workarounds for buggy ACPI tables into the kernel.  I'm not going to defend
that, but it has been done for several years now.

Also someone may say to that: "Why don't *you* demonstrate that it can be done
in the first place?"  And what if it can be done, but is too complex to be
practical or similar?

My personal opinion is that having a way to apply a fix on top of broken ACPI
tables (or an extension on top of correct ones for that matter) without touching
the kernel would be very useful indeed, but making it secure may be somewhat
challenging, because in principle there's no reason why the kernel should trust
such "external" fixes.

> In device tree the same mechanism is called "device tree overlays"
> and I just have some vague feeling that such stuff is patched around in
> some Intel platforms already, but maybe that involves replacing
> the whole DSDT from userspace,

>From initramfs rather than from user space, but yes, it does.

> surely the mechanism can be refined?

Yes, it can (in principle).  In fact, we have a plan to refine it, but it is
going to take some time.  Once we've done that, we'll see how painful it is to
"patch" ACPI tables this way in practice.

Also there is an ecosystem problem related to distributing such "patches".
Today, distributions don't need to worry about patching buggy platform
firmware, because they get workarounds in the kernel, but if we switch over
to the model in which platform firmware "overlays" need to be provided in
addition to it, then suddenly questions arise about who should be responsible
for making them available, how to avoid duplication of efforts between
distributions etc.

All of that needs to be clarified before we start making hard statements like
"No in-kernel workarounds for that!"

And, of course, there's the question of what the kernel should do if the given
firmware patch is not effective, so it doesn't really fix the problem it is
supposed to fix or it fixes that problem only partially or, worse yet, it
introuces more bugs than it fixes.  Should the kernel simply fail then (and
in what way if so) or should it try to carry out some default "sanitization"
of what the firmare (and patch) tells it and try to continue on the best
effort basis?

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

  reply	other threads:[~2015-01-20 21:02 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 [this message]
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

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:

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

  git send-email \
    --in-reply-to=4078818.ecVtLF3hjd@vostro.rjw.lan \ \ \ \ \ \ \ \ \ \ \ \ \
    --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).