Messages in this thread | | | Date | Mon, 23 Sep 2013 13:48:09 +0300 | From | Mika Westerberg <> | Subject | Re: [PATCH 2/2] gpio / ACPI: add support for GPIO operation regions |
| |
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@linux.intel.com> 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.
| |