From: "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com> To: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: "Tirdea, Irina" <irina.tirdea@intel.com>, Bastien Nocera <hadess@hadess.net>, Aleksei Mamlin <mamlinav@gmail.com>, Karsten Merker <merker@debian.org>, "linux-input@vger.kernel.org" <linux-input@vger.kernel.org>, Mark Rutland <mark.rutland@arm.com>, "Purdila, Octavian" <octavian.purdila@intel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "Dolca, Robert" <robert.dolca@intel.com> Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init Date: Mon, 2 Nov 2015 12:17:33 +0200 [thread overview] Message-ID: <20151102101733.GB1509@lahna.fi.intel.com> (raw) In-Reply-To: <20151030163328.GA17589@dtor-pixel> On Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote: > cpi_dev_add_driver_gpios() does not really help with generic drivers > (unless we keep adding more and more board specific data to them). How > about we keep track of names used and only allow conversion for the > first name used, like in the patch below? That works but it misses one case: When you have optional GPIOs and not all of them are provided. Currently it ends up the same situation returning the same GPIO. I've commented below how we could handle that case as well. > -- > Dmitry > > gpiolib: tighten up ACPI legacy gpio lookups > > From: Dmitry Torokhov <dmitry.torokhov@gmail.com> > > We should not fall back to the legacy unnamed gpio lookup style if the > driver requests gpios with different names, because we'll give out the same > gpio twice. Let's keep track of the names that were used for the device and > only do the fallback for the first name used. > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > --- > drivers/gpio/gpiolib.c | 42 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index 5db3445..4ae5447 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1738,6 +1738,45 @@ static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id, > return desc; > } > > +struct acpi_gpio_lookup { > + struct list_head node; > + struct device *dev; > + const char *con_id; > +}; > + > +static DEFINE_MUTEX(acpi_gpio_lookup_lock); > +static LIST_HEAD(acpi_gpio_lookup_list); > + > +static bool acpi_can_fallback_crs(struct device *dev, const char *con_id) > +{ > + struct acpi_gpio_lookup *l, *lookup = NULL; I'm thinking if we here do struct acpi_device *adev = ACPI_COMPANION(dev); /* Never fallback if the device has properties */ if (adev->data.properties || adev->driver_gpios) return false; > + > + mutex_lock(&acpi_gpio_lookup_lock); > + > + list_for_each_entry(l, &acpi_gpio_lookup_list, node) { > + if (l->dev == dev) { > + lookup = l; > + break; > + } > + } > + > + if (!lookup) { > + lookup = kmalloc(sizeof(*lookup), GFP_KERNEL); > + if (lookup) { > + lookup->dev = dev; > + lookup->con_id = con_id; > + list_add_tail(&lookup->node, &acpi_gpio_lookup_list); > + } > + } > + > + mutex_lock(&acpi_gpio_lookup_lock); > + > + return lookup && > + ((!lookup->con_id && !con_id) || > + (lookup->con_id && con_id && > + strcmp(lookup->con_id, con_id) == 0)); > +} > + > static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id, > unsigned int idx, > enum gpio_lookup_flags *flags) > @@ -1765,7 +1804,8 @@ static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id, > > /* Then from plain _CRS GPIOs */ > if (IS_ERR(desc)) { > - desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); > + if (acpi_can_fallback_crs(dev, con_id)) > + desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); and here we could do if (!acpi_can_fallback_crs(dev, con_id)) return ERR_PTR(-ENOENT); desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); So instead return -ENOENT so that gpiod_get_index_optional() handles the missing optional GPIO properly. > if (IS_ERR(desc)) > return desc; > }
WARNING: multiple messages have this Message-ID (diff)
From: "mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org" <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> To: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: "Tirdea, Irina" <irina.tirdea-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Bastien Nocera <hadess-0MeiytkfxGOsTnJN9+BGXg@public.gmane.org>, Aleksei Mamlin <mamlinav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Karsten Merker <merker-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>, "linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, "Purdila, Octavian" <octavian.purdila-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "Dolca, Robert" <robert.dolca-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init Date: Mon, 2 Nov 2015 12:17:33 +0200 [thread overview] Message-ID: <20151102101733.GB1509@lahna.fi.intel.com> (raw) In-Reply-To: <20151030163328.GA17589@dtor-pixel> On Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote: > cpi_dev_add_driver_gpios() does not really help with generic drivers > (unless we keep adding more and more board specific data to them). How > about we keep track of names used and only allow conversion for the > first name used, like in the patch below? That works but it misses one case: When you have optional GPIOs and not all of them are provided. Currently it ends up the same situation returning the same GPIO. I've commented below how we could handle that case as well. > -- > Dmitry > > gpiolib: tighten up ACPI legacy gpio lookups > > From: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > We should not fall back to the legacy unnamed gpio lookup style if the > driver requests gpios with different names, because we'll give out the same > gpio twice. Let's keep track of the names that were used for the device and > only do the fallback for the first name used. > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > --- > drivers/gpio/gpiolib.c | 42 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index 5db3445..4ae5447 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1738,6 +1738,45 @@ static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id, > return desc; > } > > +struct acpi_gpio_lookup { > + struct list_head node; > + struct device *dev; > + const char *con_id; > +}; > + > +static DEFINE_MUTEX(acpi_gpio_lookup_lock); > +static LIST_HEAD(acpi_gpio_lookup_list); > + > +static bool acpi_can_fallback_crs(struct device *dev, const char *con_id) > +{ > + struct acpi_gpio_lookup *l, *lookup = NULL; I'm thinking if we here do struct acpi_device *adev = ACPI_COMPANION(dev); /* Never fallback if the device has properties */ if (adev->data.properties || adev->driver_gpios) return false; > + > + mutex_lock(&acpi_gpio_lookup_lock); > + > + list_for_each_entry(l, &acpi_gpio_lookup_list, node) { > + if (l->dev == dev) { > + lookup = l; > + break; > + } > + } > + > + if (!lookup) { > + lookup = kmalloc(sizeof(*lookup), GFP_KERNEL); > + if (lookup) { > + lookup->dev = dev; > + lookup->con_id = con_id; > + list_add_tail(&lookup->node, &acpi_gpio_lookup_list); > + } > + } > + > + mutex_lock(&acpi_gpio_lookup_lock); > + > + return lookup && > + ((!lookup->con_id && !con_id) || > + (lookup->con_id && con_id && > + strcmp(lookup->con_id, con_id) == 0)); > +} > + > static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id, > unsigned int idx, > enum gpio_lookup_flags *flags) > @@ -1765,7 +1804,8 @@ static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id, > > /* Then from plain _CRS GPIOs */ > if (IS_ERR(desc)) { > - desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); > + if (acpi_can_fallback_crs(dev, con_id)) > + desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); and here we could do if (!acpi_can_fallback_crs(dev, con_id)) return ERR_PTR(-ENOENT); desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); So instead return -ENOENT so that gpiod_get_index_optional() handles the missing optional GPIO properly. > if (IS_ERR(desc)) > return desc; > } -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-11-02 10:17 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-12 15:24 [PATCH v9 0/9] Goodix touchscreen enhancements Irina Tirdea 2015-10-12 15:24 ` Irina Tirdea 2015-10-12 15:24 ` [PATCH v9 1/9] Input: goodix - use actual config length for each device type Irina Tirdea 2015-10-12 15:24 ` [PATCH v9 2/9] Input: goodix - reset device at init Irina Tirdea 2015-10-12 16:48 ` Dmitry Torokhov 2015-10-13 6:38 ` Tirdea, Irina 2015-10-13 7:08 ` Dmitry Torokhov 2015-10-13 7:08 ` Dmitry Torokhov 2015-10-13 8:54 ` Tirdea, Irina 2015-10-13 10:07 ` mika.westerberg 2015-10-14 6:23 ` Dmitry Torokhov 2015-10-14 11:18 ` mika.westerberg 2015-10-14 13:44 ` mika.westerberg 2015-10-14 13:44 ` mika.westerberg-VuQAYsv1563Yd54FQh9/CA 2015-10-19 14:32 ` Tirdea, Irina 2015-10-19 14:52 ` mika.westerberg 2015-10-30 16:33 ` Dmitry Torokhov 2015-10-31 17:28 ` Dmitry Torokhov 2015-11-02 10:17 ` mika.westerberg [this message] 2015-11-02 10:17 ` mika.westerberg-VuQAYsv1563Yd54FQh9/CA 2015-10-12 15:24 ` [PATCH v9 3/9] Input: goodix - write configuration data to device Irina Tirdea 2015-10-12 15:24 ` [PATCH v9 4/9] Input: goodix - add power management support Irina Tirdea 2015-10-12 15:24 ` [PATCH v9 5/9] Input: goodix - use goodix_i2c_write_u8 instead of i2c_master_send Irina Tirdea 2015-10-12 15:24 ` [PATCH v9 6/9] Input: goodix - add support for ESD Irina Tirdea 2015-10-12 15:24 ` [PATCH v9 7/9] Input: goodix - add sysfs interface to dump config Irina Tirdea 2015-10-12 15:24 ` [PATCH v9 8/9] Input: goodix - add runtime power management support Irina Tirdea 2015-10-12 15:24 ` [PATCH v9 9/9] Input: goodix - sort includes using inverse Xmas tree order Irina Tirdea 2015-10-12 15:39 ` Mark Rutland 2015-10-12 15:39 ` Mark Rutland 2015-10-12 15:40 ` Bastien Nocera 2015-10-12 15:51 ` Mark Rutland 2015-10-12 15:51 ` Mark Rutland 2015-10-12 15:53 ` Bastien Nocera 2015-10-12 16:30 ` Dmitry Torokhov 2015-10-12 16:30 ` Dmitry Torokhov 2015-10-13 6:42 ` Tirdea, Irina 2015-10-13 6:42 ` Tirdea, Irina 2015-10-26 15:06 ` [PATCH v9 0/9] Goodix touchscreen enhancements Bastien Nocera 2015-10-26 15:06 ` Bastien Nocera 2015-10-26 18:21 ` Karsten Merker 2015-10-26 18:40 ` Bastien Nocera 2015-10-26 23:32 ` Dmitry Torokhov 2015-10-27 9:13 ` Tirdea, Irina 2015-10-27 9:13 ` Tirdea, Irina 2015-10-27 9:15 ` Tirdea, Irina 2015-10-27 9:15 ` Tirdea, Irina
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20151102101733.GB1509@lahna.fi.intel.com \ --to=mika.westerberg@linux.intel.com \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.torokhov@gmail.com \ --cc=hadess@hadess.net \ --cc=irina.tirdea@intel.com \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mamlinav@gmail.com \ --cc=mark.rutland@arm.com \ --cc=merker@debian.org \ --cc=octavian.purdila@intel.com \ --cc=robert.dolca@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.