Re: [RFC PATCH] gpio: support for GPIO forwarding

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Thursday, January 22, 2015 09:17:38 AM Linus Walleij wrote:
> 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?

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?

> They are both in-kernel ACPI fixes, just that one
> of the mechanisms is generic.

I'm not following you here, sorry.

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


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