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: Fri, 30 Jan 2015 15:48:30 +0100	[thread overview]
Message-ID: <CACRpkdZWEq_6eNf_rj2rje0KzAKQZ7DeB6L5PW-nacE6=rzmEQ@mail.gmail.com> (raw)
In-Reply-To: <4006695.qV8Mor20ru@vostro.rjw.lan>

On Thu, Jan 22, 2015 at 5:12 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Thursday, January 22, 2015 09:17:38 AM Linus Walleij wrote:

>> 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?
>
> It needs to know what to patch and how so the result is still consistent.
>
> How do you think the kernel is going to figure that out?

Isn't every DSDT (etc) unique? 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?

>> They are both in-kernel ACPI fixes, just that one
>> of the mechanisms is generic.
>
> I'm not following you here, sorry.

As per above? Fix the firmware table, not work around the
fact that it is buggy.

>> 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.
>
> This is not an obsession and your suggestion here leads to having custom
> per-board kernels which is not supportable in the long term.

Not at all. The other suggestion leads to having custom per-board
fixes in every driver for which broken ACPI descriptions exists,
which is just as bad, isn't it? Instead of collecting the problem
in one place (patch any broken ACPI table) it is distrubuted across
N drivers, where each and every one has to detect that it is
being malinformed by a broken ACPI table.

Yours,
Linus Walleij

  reply	other threads:[~2015-01-30 14:56 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 [this message]
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='CACRpkdZWEq_6eNf_rj2rje0KzAKQZ7DeB6L5PW-nacE6=rzmEQ@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).