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

[Rafael J. Wysocki]

On Wednesday, January 14, 2015 08:32:12 AM Darren Hart wrote:
> 
> On 1/14/15 4:58 AM, Linus Walleij wrote:
> > On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
> > <heikki.krogerus@xxxxxxxxxxxxxxx> wrote:
> > 
> >> This makes it possible to assign GPIOs at runtime. The
> >> motivation for it is because of need to forward GPIOs from
> >> one device to an other. That feature may be useful for
> >> example with some mfd devices, but initially it is needed
> 
> +Samuel Ortiz for his thoughts on applicability to MFD.
> 
> >> because on some Intel Braswell based ACPI platforms the GPIO
> >> resources controlling signals of the USB PHY are given to
> >> the controller device object for whatever reason, so the
> >> driver of that controller needs be able to pass them to the
> >> PHY device somehow.
> >>
> >> So basically this is meant to allow patching of bad (bad
> >> from Linux kernels point of view) hardware descriptions
> >> provided by system fw in the drivers.
> >>
> >> Signed-off-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
> >> ---
> >>
> >> Hi,
> >>
> >> I'm sending this first as a RFC in case you guys have some better
> >> idea how to solve our problem. I actually already have couple
> >> platforms where the GPIO resources are given to the "wrong" device
> >> objects now.
> >>
> >> Originally we were thinking about simply handling our problem with
> >> hacks to the PHY drivers, basically also checking if the parent has
> >> GPIOs. That would only work if the controller is always the parent,
> >> which it's not, but even if it was, it would be too risky. The PHY
> >> drivers don't know which controller they are attached to, so what is
> >> to say that the GPIOs aren't really attached to the controller.
> >>
> >> So the safest way to handle our problem is to deal with it in quirks
> >> in the controller drivers. Solving it by bouncing the GPIOs did not
> >> feel ideal there doesn't seem to be any other way. The API is copied
> >> from clkdev (clk_register_clkdev). In the end it's really only one
> >> function for adding the lookups and one for removing them.
> >>
> >> The way it's implemented is by modifying the current style of handling
> >> the lookups a little bit. The per device lookup table is basically
> >> reverted back to the single linked-list format since it seems that
> >> these lookups may have to be assigned from several sources.
> > 
> > Oh ain't that great.
> > 
> > So now we start patching around the kernel because the ACPI
> > tables are erroneous for GPIOs. I'd like some feedback from
> > Rafael &| Darren on this patch, i.e. if you two think this is a good
> > way of accounting for bad GPIO descriptions in ACPI tables then
> > ACK this patch.
> > 
> > I guess the other option would be to fix up the ACPI DSDT
> > itself to put resources right, correct? Is this not possible?
> 
> This is my gut reaction as well.

Pretty much agreed.

> Heikki, why can't we correct the firmware tables? That needs to be made clear
> before we start adding hacks to the kernel.

We need to start working in that direction really.  Fixing problems in ACPI
tables via kernel code is not going to scale sufficiently IMO.

> You said, "Bad for Linux", why is this not a problem for other operating
> systems?

Good question. :-)

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/