All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
Cc: Linus Walleij
	<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Jonathan Hunter
	<jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v6 00/12] gpio: Tight IRQ chip integration
Date: Tue, 7 Nov 2017 12:52:38 +0100	[thread overview]
Message-ID: <20171107115238.GB7314@ulmo> (raw)
In-Reply-To: <20171107111344.GA7314@ulmo>

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

On Tue, Nov 07, 2017 at 12:13:44PM +0100, Thierry Reding wrote:
> On Mon, Nov 06, 2017 at 05:13:33PM -0600, Grygorii Strashko wrote:
> > On 11/06/2017 05:18 AM, Thierry Reding wrote:
> > > On Fri, Nov 03, 2017 at 05:30:30PM -0500, Grygorii Strashko wrote:
[...]
> > >> @@ -312,8 +321,29 @@ struct gpio_chip {
> > >>   extern const char *gpiochip_is_requested(struct gpio_chip *chip,
> > >>   			unsigned offset);
> > >>   
> > >> +extern int gpiochip_add_data_key(struct gpio_chip *chip, void *data,
> > >> +				 struct  *irq_lock_key);
> > >> +#ifdef CONFIG_LOCKDEP
> > >> +/*
> > >> + * Lockdep requires that each irqchip instance be created with a
> > >> + * unique key so as to avoid unnecessary warnings. This upfront
> > >> + * boilerplate static inlines provides such a key for each
> > >> + * unique instance which is created now from inside gpiochip_add_data_key().
> > >> + */
> > >> +static inline int gpiochip_add_data(struct gpio_chip *chip, void *data)
> > >> +{
> > >> +	static struct lock_class_key key;
> > >> +
> > >> +	return gpiochip_add_data_key(chip, data, key);
> > >> +}
> > > 
> > > This looks like a neat improvement, but I think it can be done in a
> > > follow-up to remove the boilerplate in drivers.
> > 
> > Can't agree here - it better to be considered now. 
> > Now only two GPIO drivers define lock_class_key:
> > ./drivers/gpio/gpio-bcm-kona.c:static struct lock_class_key gpio_lock_class;
> > ./drivers/gpio/gpio-brcmstb.c:static struct lock_class_key brcmstb_gpio_irq_lock_class;
> > 
> > and these drivers do not use gpioirq framework (your tegra driver will be the third).
> > 
> > So, if proposed changes will be applied all drivers switched to use it will need to define
> > its own lock_class_key again and it will be step back.
> 
> I think this would be a minor, mostly mechanical refactoring to do as
> follow-up. But since you feel very strongly about it, I'll add that into
> the series.

After implementing this, I'm having second thoughts. We've got a bunch
of drivers calling gpiochip_add_data() that never register an IRQ chip
but which will each add a struct lock_class_key after this change, and
it will never be used. Now, struct lock_class_key is only 8 bytes big,
so maybe this isn't a big deal, but it still seems like a waste.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-gpio@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 00/12] gpio: Tight IRQ chip integration
Date: Tue, 7 Nov 2017 12:52:38 +0100	[thread overview]
Message-ID: <20171107115238.GB7314@ulmo> (raw)
In-Reply-To: <20171107111344.GA7314@ulmo>

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

On Tue, Nov 07, 2017 at 12:13:44PM +0100, Thierry Reding wrote:
> On Mon, Nov 06, 2017 at 05:13:33PM -0600, Grygorii Strashko wrote:
> > On 11/06/2017 05:18 AM, Thierry Reding wrote:
> > > On Fri, Nov 03, 2017 at 05:30:30PM -0500, Grygorii Strashko wrote:
[...]
> > >> @@ -312,8 +321,29 @@ struct gpio_chip {
> > >>   extern const char *gpiochip_is_requested(struct gpio_chip *chip,
> > >>   			unsigned offset);
> > >>   
> > >> +extern int gpiochip_add_data_key(struct gpio_chip *chip, void *data,
> > >> +				 struct  *irq_lock_key);
> > >> +#ifdef CONFIG_LOCKDEP
> > >> +/*
> > >> + * Lockdep requires that each irqchip instance be created with a
> > >> + * unique key so as to avoid unnecessary warnings. This upfront
> > >> + * boilerplate static inlines provides such a key for each
> > >> + * unique instance which is created now from inside gpiochip_add_data_key().
> > >> + */
> > >> +static inline int gpiochip_add_data(struct gpio_chip *chip, void *data)
> > >> +{
> > >> +	static struct lock_class_key key;
> > >> +
> > >> +	return gpiochip_add_data_key(chip, data, key);
> > >> +}
> > > 
> > > This looks like a neat improvement, but I think it can be done in a
> > > follow-up to remove the boilerplate in drivers.
> > 
> > Can't agree here - it better to be considered now. 
> > Now only two GPIO drivers define lock_class_key:
> > ./drivers/gpio/gpio-bcm-kona.c:static struct lock_class_key gpio_lock_class;
> > ./drivers/gpio/gpio-brcmstb.c:static struct lock_class_key brcmstb_gpio_irq_lock_class;
> > 
> > and these drivers do not use gpioirq framework (your tegra driver will be the third).
> > 
> > So, if proposed changes will be applied all drivers switched to use it will need to define
> > its own lock_class_key again and it will be step back.
> 
> I think this would be a minor, mostly mechanical refactoring to do as
> follow-up. But since you feel very strongly about it, I'll add that into
> the series.

After implementing this, I'm having second thoughts. We've got a bunch
of drivers calling gpiochip_add_data() that never register an IRQ chip
but which will each add a struct lock_class_key after this change, and
it will never be used. Now, struct lock_class_key is only 8 bytes big,
so maybe this isn't a big deal, but it still seems like a waste.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-11-07 11:52 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-02 17:49 [PATCH v6 00/12] gpio: Tight IRQ chip integration Thierry Reding
2017-11-02 17:49 ` [PATCH v6 01/12] gpio: Introduce struct gpio_irq_chip Thierry Reding
2017-11-02 17:49 ` [PATCH v6 02/12] gpio: Move irqchip into " Thierry Reding
2017-11-02 17:49 ` [PATCH v6 04/12] gpio: Move irq_handler to " Thierry Reding
2017-11-02 17:49 ` [PATCH v6 05/12] gpio: Move irq_default_type " Thierry Reding
2017-11-02 17:49 ` [PATCH v6 06/12] gpio: Move irq_chained_parent " Thierry Reding
2017-11-02 17:49 ` [PATCH v6 07/12] gpio: Move irq_nested into " Thierry Reding
2017-11-02 17:49 ` [PATCH v6 08/12] gpio: Move irq_valid_mask " Thierry Reding
     [not found] ` <20171102174941.3461-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-02 17:49   ` [PATCH v6 03/12] gpio: Move irqdomain " Thierry Reding
2017-11-02 17:49     ` Thierry Reding
2017-11-02 17:49   ` [PATCH v6 09/12] gpio: Move lock_key " Thierry Reding
2017-11-02 17:49     ` Thierry Reding
2017-11-02 17:49   ` [PATCH v6 10/12] gpio: Implement tighter IRQ chip integration Thierry Reding
2017-11-02 17:49     ` Thierry Reding
2017-11-03 22:50   ` [PATCH v6 00/12] gpio: Tight " Linus Walleij
2017-11-03 22:50     ` Linus Walleij
     [not found]     ` <CACRpkdZaLtpEfx6C5cqHFMk11TXnHxp-sZ+T38PCf+Jh1B2BjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-11-03 23:50       ` Grygorii Strashko
2017-11-03 23:50         ` Grygorii Strashko
2017-11-06 13:22         ` Linus Walleij
     [not found]           ` <CACRpkda888GdPdH_qkeyA64hukyqxryc1uvHWEab92PR32Xt_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-11-06 14:36             ` Thierry Reding
2017-11-06 14:36               ` Thierry Reding
2017-11-02 17:49 ` [PATCH v6 11/12] gpio: Export gpiochip_irq_{map,unmap}() Thierry Reding
2017-11-02 17:49 ` [PATCH v6 12/12] gpio: Add Tegra186 support Thierry Reding
2017-11-03 22:30 ` [PATCH v6 00/12] gpio: Tight IRQ chip integration Grygorii Strashko
2017-11-03 22:30   ` Grygorii Strashko
2017-11-03 22:30   ` Grygorii Strashko
     [not found]   ` <ca8c7138-2e87-0481-ac8c-7077bed749f6-l0cyMroinI0@public.gmane.org>
2017-11-06 11:18     ` Thierry Reding
2017-11-06 11:18       ` Thierry Reding
2017-11-06 23:13       ` Grygorii Strashko
2017-11-06 23:13         ` Grygorii Strashko
2017-11-07 11:13         ` Thierry Reding
2017-11-07 11:52           ` Thierry Reding [this message]
2017-11-07 11:52             ` Thierry Reding
2017-11-07 16:49             ` Grygorii Strashko
2017-11-07 16:49               ` Grygorii Strashko
2017-11-07 17:00           ` Grygorii Strashko
2017-11-07 17:00             ` Grygorii Strashko
2017-11-07 18:19             ` Thierry Reding

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=20171107115238.GB7314@ulmo \
    --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=grygorii.strashko-l0cyMroinI0@public.gmane.org \
    --cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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: link
Be 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.