Re: [Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

[Linus Walleij <linus.walleij@linaro.org>]

On Sun, May 4, 2014 at 2:58 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Sunday, May 04, 2014 10:23:18 AM Olof Johansson wrote:

>> Same for pin control, where we have frameworks in the kernel on ARM, but
>> x86/ACPI tends to let firmware handle it all...
>
> I would say if pin control information is made available to us by the firmware,
> we can use it.  If it is not, we need to live without it.

I would like to know *how* it will be made available in that case.

What I think will actually happen is this:

- Handling pin control is deemed unnecessary for the kernel in the same
way that early reviews of the subsystem was received: "well we only set
up this once at boot and never touch it, ideally the boot loader/ROM/BIOS
do this and we need not care"

- Further down the road a "uh oh" moment - we *need* to screw around
with pin control - usually due to firmware bugs and power savings - "we
only need to augment this or these pins a little bit here ..."

- Ugliness threatens to invade, pin control subsystem maintainer get
angry.

The thing is: with things like BayTrail I already *know* the pin control
registers are there, they are just not implemented any handling of.
I know very well how much the HW implementers think that a kernel
"should never touch" these registers, and I know it will invariably happen
sooner or later but like to be proven wrong.

Yours,
Linus Walleij