On Fri, Sep 20, 2013 at 09:21:37PM +0200, Linus Walleij wrote:
> On Fri, Sep 13, 2013 at 5:14 PM, Mika Westerberg
> <mika.westerberg@xxxxxxxxxxxxxxx> wrote:
>
> > diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> (...)
> > +struct acpi_gpio_chip_data {
> > + /*
> > + * acpi_install_address_space_handler() wants to put the connection
> > + * information at the start of the context structure we pass it, in
> > + * case we are dealing with GPIO operation regions.
> > + */
> > + struct acpi_connection_info ci;
> > + struct gpio_chip *chip;
> > + struct list_head *evt_pins;
> > +};
>
> Consider just naming this acpi_gpio_chip, as it is obviously some
> generic container that you will keep adding to.
Sure.
> I'm uncertain how things work, it wouldn't add something to have
> struct gpio_chip be a true member (not a pointer) so you can
> allocate one thing from the drivers, and e.g. use container_of()
> to get from the gpio_chip to the acpi_gpio_chip[_data]?
The drivers are just normal platform drivers (for example gpio-lynxpoint.c)
and they shouldn't care if they got enumerated from ACPI. Allocating
acpi_gpio_chip from a driver would make it depend on ACPI, if I'm
understanding correctly.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
