LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Alexandre Courbot <gnurou@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Darren Hart <dvhart@linux.intel.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [RFC PATCH] gpio: support for GPIO forwarding
Date: Thu, 22 Jan 2015 09:17:38 +0100	[thread overview]
Message-ID: <CACRpkdZpUU71suzt9JhiBZez2VuJ6-Zm3D1uvmn71bjdn=oU_A@mail.gmail.com> (raw)
In-Reply-To: <4078818.ecVtLF3hjd@vostro.rjw.lan>

On Tue, Jan 20, 2015 at 10:25 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:

> 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!"

OK so why can't the patching happen in the kernel?

If the kernel anyway has to supply some kind of workaround for
the issue, it is more a question of where to place it. Whether it does
so by patching the ACPI tables or by detecting a bad ACPI thing
and working around it at runtime in a certain driver doesn't really
matter, does it? They are both in-kernel ACPI fixes, just that one
of the mechanisms is generic.

I don't understand why this obsession with userspace having
to do the ACPI table patching - if kernels should "just work" then
put this stuff behind Kconfig and have it in the kernel.

Yours,
Linus Walleij

  parent reply	other threads:[~2015-01-22  8:17 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 [this message]
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:
  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='CACRpkdZpUU71suzt9JhiBZez2VuJ6-Zm3D1uvmn71bjdn=oU_A@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=dvhart@linux.intel.com \
    --cc=gnurou@gmail.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --subject='Re: [RFC PATCH] gpio: support for GPIO forwarding' \
    /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

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).