From: Linus Walleij <linus.walleij@linaro.org> To: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>, Jonathan Corbet <corbet@lwn.net>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Harish Jenny K N <harish_kandiga@mentor.com>, Eugeniu Rosca <erosca@de.adit-jv.com>, Alexander Graf <graf@amazon.com>, Peter Maydell <peter.maydell@linaro.org>, Paolo Bonzini <pbonzini@redhat.com>, Phil Reid <preid@electromag.com.au>, Marc Zyngier <marc.zyngier@arm.com>, Christoffer Dall <christoffer.dall@arm.com>, Magnus Damm <magnus.damm@gmail.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, Linux Doc Mailing List <linux-doc@vger.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, QEMU Developers <qemu-devel@nongnu.org> Subject: Re: [PATCH v3 3/7] gpiolib: Add support for GPIO line table lookup Date: Thu, 12 Dec 2019 14:40:29 +0100 [thread overview] Message-ID: <CACRpkdZs0_VvfpE34bgrMtBVeamCsq6BaqfyJc1tyvWCornSUw@mail.gmail.com> (raw) In-Reply-To: <20191127084253.16356-4-geert+renesas@glider.be> On Wed, Nov 27, 2019 at 9:43 AM Geert Uytterhoeven <geert+renesas@glider.be> wrote: > Currently GPIOs can only be referred to by GPIO controller and offset in > GPIO lookup tables. > > Add support for looking them up by line name. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> OK I see what you want to do... > + if (p->chip_hwnum == (u16)-1) { If you want to use this then use: if (p->chip_hwnum == U16_MAX) from <linux/limits.h> > + desc = gpio_name_to_desc(p->chip_label); > + if (desc) { > + *flags = p->flags; > + return desc; > + } > + > + dev_warn(dev, "cannot find GPIO line %s, deferring\n", > + p->chip_label); > + return ERR_PTR(-EPROBE_DEFER); > + } > + > chip = find_chip_by_name(p->chip_label); > > if (!chip) { > diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h > index 1ebe5be05d5f81fa..84c1c097e55eefaf 100644 > --- a/include/linux/gpio/machine.h > +++ b/include/linux/gpio/machine.h > @@ -31,7 +31,7 @@ enum gpio_lookup_flags { > */ > struct gpiod_lookup { > const char *chip_label; > - u16 chip_hwnum; > + u16 chip_hwnum; /* if -1, chip_label is named line */ /* if U16_MAX then chip_label is the named line we are looking for */ But the member name "chip_label" is completely abused with this setup, it should then be renamed as part of the patch set to something like chip_label_or_line_name so it is clear what it is or just name it "const char *key". But I'm not entirely convinced about reusing the existing struct gpio_lookup for this. What about constructing a new lookup struct specifically for this? I understand it is more work, but will that not be more maintainable and readable? Yours, Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org> To: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Mark Rutland <mark.rutland@arm.com>, Peter Maydell <peter.maydell@linaro.org>, QEMU Developers <qemu-devel@nongnu.org>, Phil Reid <preid@electromag.com.au>, Jonathan Corbet <corbet@lwn.net>, Marc Zyngier <marc.zyngier@arm.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, Linux Doc Mailing List <linux-doc@vger.kernel.org>, Magnus Damm <magnus.damm@gmail.com>, Christoffer Dall <christoffer.dall@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Harish Jenny K N <harish_kandiga@mentor.com>, Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>, Eugeniu Rosca <erosca@de.adit-jv.com> Subject: Re: [PATCH v3 3/7] gpiolib: Add support for GPIO line table lookup Date: Thu, 12 Dec 2019 14:40:29 +0100 [thread overview] Message-ID: <CACRpkdZs0_VvfpE34bgrMtBVeamCsq6BaqfyJc1tyvWCornSUw@mail.gmail.com> (raw) In-Reply-To: <20191127084253.16356-4-geert+renesas@glider.be> On Wed, Nov 27, 2019 at 9:43 AM Geert Uytterhoeven <geert+renesas@glider.be> wrote: > Currently GPIOs can only be referred to by GPIO controller and offset in > GPIO lookup tables. > > Add support for looking them up by line name. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> OK I see what you want to do... > + if (p->chip_hwnum == (u16)-1) { If you want to use this then use: if (p->chip_hwnum == U16_MAX) from <linux/limits.h> > + desc = gpio_name_to_desc(p->chip_label); > + if (desc) { > + *flags = p->flags; > + return desc; > + } > + > + dev_warn(dev, "cannot find GPIO line %s, deferring\n", > + p->chip_label); > + return ERR_PTR(-EPROBE_DEFER); > + } > + > chip = find_chip_by_name(p->chip_label); > > if (!chip) { > diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h > index 1ebe5be05d5f81fa..84c1c097e55eefaf 100644 > --- a/include/linux/gpio/machine.h > +++ b/include/linux/gpio/machine.h > @@ -31,7 +31,7 @@ enum gpio_lookup_flags { > */ > struct gpiod_lookup { > const char *chip_label; > - u16 chip_hwnum; > + u16 chip_hwnum; /* if -1, chip_label is named line */ /* if U16_MAX then chip_label is the named line we are looking for */ But the member name "chip_label" is completely abused with this setup, it should then be renamed as part of the patch set to something like chip_label_or_line_name so it is clear what it is or just name it "const char *key". But I'm not entirely convinced about reusing the existing struct gpio_lookup for this. What about constructing a new lookup struct specifically for this? I understand it is more work, but will that not be more maintainable and readable? Yours, Linus Walleij
next prev parent reply other threads:[~2019-12-12 13:40 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-27 8:42 [PATCH v3 0/7] gpio: Add GPIO Aggregator/Repeater Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-27 8:42 ` [PATCH v3 1/7] gpiolib: Add GPIOCHIP_NAME definition Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:38 ` Ulrich Hecht 2019-11-28 3:38 ` Ulrich Hecht 2019-12-02 21:17 ` Eugeniu Rosca 2019-12-02 21:17 ` Eugeniu Rosca 2019-12-12 10:37 ` Linus Walleij 2019-12-12 10:37 ` Linus Walleij 2019-11-27 8:42 ` [PATCH v3 2/7] gpiolib: Add support for gpiochipN-based table lookup Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:38 ` Ulrich Hecht 2019-11-28 3:38 ` Ulrich Hecht 2019-12-12 13:20 ` Linus Walleij 2019-12-12 13:20 ` Linus Walleij 2019-12-12 13:33 ` Geert Uytterhoeven 2019-12-12 13:33 ` Geert Uytterhoeven 2019-12-12 14:36 ` Linus Walleij 2019-12-12 14:36 ` Linus Walleij 2019-11-27 8:42 ` [PATCH v3 3/7] gpiolib: Add support for GPIO line " Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:39 ` Ulrich Hecht 2019-11-28 3:39 ` Ulrich Hecht 2019-12-12 13:40 ` Linus Walleij [this message] 2019-12-12 13:40 ` Linus Walleij 2019-11-27 8:42 ` [PATCH v3 4/7] dt-bindings: gpio: Add gpio-repeater bindings Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:39 ` Ulrich Hecht 2019-11-28 3:39 ` Ulrich Hecht 2019-12-03 5:51 ` Harish Jenny K N 2019-12-03 5:51 ` Harish Jenny K N 2019-12-05 21:06 ` Rob Herring 2019-12-05 21:06 ` Rob Herring 2019-12-06 9:17 ` Geert Uytterhoeven 2019-12-06 9:17 ` Geert Uytterhoeven 2019-12-06 15:03 ` Rob Herring 2019-12-06 15:03 ` Rob Herring 2020-01-06 8:12 ` Geert Uytterhoeven 2020-01-06 8:12 ` Geert Uytterhoeven 2020-01-07 9:22 ` Harish Jenny K N 2020-01-07 9:22 ` Harish Jenny K N 2020-01-16 5:09 ` Harish Jenny K N 2020-01-16 5:09 ` Harish Jenny K N 2019-11-27 8:42 ` [PATCH v3 5/7] gpio: Add GPIO Aggregator/Repeater driver Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-27 14:15 ` Eugeniu Rosca 2019-11-27 14:15 ` Eugeniu Rosca 2019-11-27 14:33 ` Geert Uytterhoeven 2019-11-27 14:33 ` Geert Uytterhoeven 2019-11-28 3:40 ` Ulrich Hecht 2019-11-28 3:40 ` Ulrich Hecht 2019-12-03 5:42 ` Harish Jenny K N 2019-12-03 5:42 ` Harish Jenny K N 2019-12-03 8:17 ` Geert Uytterhoeven 2019-12-03 8:17 ` Geert Uytterhoeven 2019-12-03 8:51 ` Harish Jenny K N 2019-12-03 8:51 ` Harish Jenny K N 2019-12-03 10:51 ` Eugeniu Rosca 2019-12-03 10:51 ` Eugeniu Rosca 2020-01-09 13:35 ` Geert Uytterhoeven 2020-01-09 13:35 ` Geert Uytterhoeven 2020-01-09 13:49 ` Eugeniu Rosca 2020-01-09 13:49 ` Eugeniu Rosca 2019-12-12 14:34 ` Linus Walleij 2019-12-12 14:34 ` Linus Walleij 2019-12-12 15:24 ` Geert Uytterhoeven 2019-12-12 15:24 ` Geert Uytterhoeven 2020-01-04 0:38 ` Linus Walleij 2020-01-04 0:38 ` Linus Walleij 2020-01-06 8:23 ` Geert Uytterhoeven 2020-01-06 8:23 ` Geert Uytterhoeven 2020-01-08 23:12 ` Linus Walleij 2020-01-08 23:12 ` Linus Walleij 2019-11-27 8:42 ` [PATCH v3 6/7] docs: gpio: Add GPIO Aggregator/Repeater documentation Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:41 ` Ulrich Hecht 2019-11-28 3:41 ` Ulrich Hecht 2019-12-12 14:42 ` Linus Walleij 2019-12-12 14:42 ` Linus Walleij 2019-12-12 14:48 ` Geert Uytterhoeven 2019-12-12 14:48 ` Geert Uytterhoeven 2020-01-04 0:21 ` Linus Walleij 2020-01-04 0:21 ` Linus Walleij 2020-01-06 8:06 ` Geert Uytterhoeven 2020-01-06 8:06 ` Geert Uytterhoeven 2019-11-27 8:42 ` [PATCH v3 7/7] MAINTAINERS: Add GPIO Aggregator/Repeater section Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-12-03 5:38 ` Harish Jenny K N 2019-12-03 5:38 ` Harish Jenny K N 2020-01-18 1:46 ` [PATCH v3 0/7] gpio: Add GPIO Aggregator/Repeater Eugeniu Rosca 2020-01-18 1:46 ` Eugeniu Rosca 2020-01-20 9:33 ` Geert Uytterhoeven 2020-01-20 9:33 ` Geert Uytterhoeven 2020-01-20 12:14 ` Eugeniu Rosca 2020-01-20 12:14 ` Eugeniu Rosca
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=CACRpkdZs0_VvfpE34bgrMtBVeamCsq6BaqfyJc1tyvWCornSUw@mail.gmail.com \ --to=linus.walleij@linaro.org \ --cc=bgolaszewski@baylibre.com \ --cc=christoffer.dall@arm.com \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=erosca@de.adit-jv.com \ --cc=geert+renesas@glider.be \ --cc=graf@amazon.com \ --cc=harish_kandiga@mentor.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=magnus.damm@gmail.com \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=pbonzini@redhat.com \ --cc=peter.maydell@linaro.org \ --cc=preid@electromag.com.au \ --cc=qemu-devel@nongnu.org \ --cc=robh+dt@kernel.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: 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.