mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Jeffery <andrew@aj.id.au>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Joel Stanley <joel@jms.id.au>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: [PATCH v2 2/2] gpio: aspeed: Add banks Y, Z, AA, AB and AC
Date: Fri, 27 Jan 2017 12:19:44 +1030	[thread overview]
Message-ID: <1485481784.4137.15.camel@aj.id.au> (raw)
In-Reply-To: <CACRpkdZ4hZY1j5U1xfn=trnDJMG1A=K2DbMWxD=79MzmEgouaw@mail.gmail.com>

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

On Thu, 2017-01-26 at 14:51 +0100, Linus Walleij wrote:
> > On Tue, Jan 24, 2017 at 7:16 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> 
> > This is less straight-forward than one would hope, as some banks only
> > have 4 pins rather than 8, others are output only, yet more (W and
> > X, already supported) are input-only, and in the case of the g4 SoC bank
> > AC doesn't exist.
> > 
> > Add some structs to describe the varying properties of different banks
> > and integrate mechanisms to deny requests for unsupported
> > configurations.
> > 
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> 
> (...)
> > +#include <linux/gpio.h>
> 
> NAK don't do that. (I will explain below...)
> 
> (...)
> 
> > @@ -189,6 +258,12 @@ static int aspeed_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
> >         unsigned long flags;
> >         u32 val;
> > 
> > +       if (!have_input(gpio, offset))
> > +               return GPIOF_DIR_OUT;
> > +
> > +       if (!have_output(gpio, offset))
> > +               return GPIOF_DIR_IN;
> 
> Please refrain from using GPIOF_* in drivers like this.
> 
> These flags are part of the consumer API, not the driver API.
> 
> Make sure the only header you include in your driver is
> <linux/gpio/driver.h> and just return 0/1 instead of these
> constants.

No worries, I'll send a follow-up fixing that. I was hesitant, but then
figured there was a reasonable chance I'd get the values around the
wrong way and went looking for macros that made it obviously correct.

> 
> > +static void set_irq_valid_mask(struct aspeed_gpio *gpio)
> > +{
> > +       const struct aspeed_bank_props *props = gpio->config->props;
> > +
> > +       while (!is_bank_props_sentinel(props)) {
> > +               unsigned int offset;
> > +               const unsigned long int input = props->input;
> > +
> > +               /* Pretty crummy approach, but similar to GPIO core */
> > +               for_each_clear_bit(offset, &input, 32) {
> > +                       unsigned int i = props->bank * 32 + offset;
> > +
> > +                       if (i >= gpio->config->nr_gpios)
> > +                               break;
> > +
> > +                       clear_bit(i, gpio->chip.irq_valid_mask);
> > +               }
> > +
> > +               props++;
> > +       }
> > +}
> 
> Nice that you use this feature!
> 
> > +/*
> > + * Any banks not specified in a struct aspeed_bank_props array are assumed to
> > + * have the properties:
> > + *
> > + *     { .input = 0xffffffff, .output = 0xffffffff }
> > + */
> > +
> > +static const struct aspeed_bank_props ast2400_bank_props[] = {
> > +       /*     input      output   */
> > +       { 5, 0xffffffff, 0x0000ffff }, /* U/V/W/X */
> > +       { 6, 0x0000000f, 0x0fffff0f }, /* Y/Z/AA/AB, two 4-GPIO holes */
> > +       { },
> > +};
> > +
> > +static const struct aspeed_gpio_config ast2400_config =
> > +       /* 220 for simplicity, really 216 with two 4-GPIO holes, four at end */
> > +       { .nr_gpios = 220, .props = ast2400_bank_props, };
> > +
> > +static const struct aspeed_bank_props ast2500_bank_props[] = {
> > +       /*     input      output   */
> > +       { 5, 0xffffffff, 0x0000ffff }, /* U/V/W/X */
> > +       { 6, 0x0fffffff, 0x0fffffff }, /* Y/Z/AA/AB, 4-GPIO hole */
> > +       { 7, 0x000000ff, 0x000000ff }, /* AC */
> > +       { },
> > +};
> 
> A bit of magic values but there are comments to explain it so OK.
> 
> You could consider using the GENMASK() macro from <linux/bitops.h>
> to indicate the bits here but no big deal.

I'm going to leave it as is if you're not bothered, unless there are
strong objections from others.

Thanks,

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

      reply	other threads:[~2017-01-27  1:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24  6:16 [PATCH v2 0/2] gpio: aspeed: Implement " Andrew Jeffery
2017-01-24  6:16 ` [PATCH v2 1/2] gpio: aspeed: Make bank names strings Andrew Jeffery
2017-01-26 13:45   ` Linus Walleij
2017-01-24  6:16 ` [PATCH v2 2/2] gpio: aspeed: Add banks Y, Z, AA, AB and AC Andrew Jeffery
2017-01-26 13:51   ` Linus Walleij
2017-01-27  1:49     ` Andrew Jeffery [this message]

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=1485481784.4137.15.camel@aj.id.au \
    --to=andrew@aj.id.au \
    --cc=joel@jms.id.au \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®