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

[Darren Vincent Hart <darren@dvhart.com>]

On Mon, 2014-05-05 at 19:41 -0700, Linus Walleij wrote:
> 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.

I agree with you on this Linus, see my response to Rafael just a minute
ago. I think perhaps we can discuss this separately from this thread? I
have a few other people I'd like to loop in - but it would be a very
specific discussion perhaps rat-holing in this context.

Or possibly you have an LKML thread I need to go find and pick this up
there?

-- 
Darren Hart
Intel Open Source Technology Center