devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thor Thayer <tthayer@opensource.altera.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>,
	Alexandre Courbot <gnurou@gmail.com>,
	jdelvare@suse.com, Guenter Roeck <linux@roeck-us.net>,
	Rob Herring <robh+dt@kernel.org>,
	pawell.moll@arm.com, Mark Rutland <mark.rutland@arm.com>,
	"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
	Dinh Nguyen <dinguyen@opensource.altera.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	linux-hwmon@vger.kernel.org,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [RFC 4/8] gpio: altera-a10sr: Add A10 System Resource Chip GPIO support.
Date: Fri, 1 Apr 2016 15:34:42 -0500	[thread overview]
Message-ID: <56FEDB62.1010308@opensource.altera.com> (raw)
In-Reply-To: <CACRpkda8VTDGVsRqbCs6ESeokA3t_p2X91FUNiqA7YM=F-JXBQ@mail.gmail.com>

Hi Linus,

On 04/01/2016 07:17 AM, Linus Walleij wrote:
> On Tue, Mar 29, 2016 at 9:13 PM,  <tthayer@opensource.altera.com> wrote:
>
>> From: Thor Thayer <tthayer@opensource.altera.com>
>>
>> Add the GPIO functionality for the Altera Arria10 MAX5 System Resource
>> Chip. The A10 MAX5 has 12 bits of GPIO assigned to switches, buttons,
>> and LEDs as a GPIO extender on the SPI bus.
>>
>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>
> OK...
>
> As Lee says: split off the MFD patch so it is a pure GPIO driver
> patch.
>

ACK

>> +#include <linux/gpio.h>
>
> You should instead #include <linux/gpio/driver.h>
>
>> +#include <linux/mfd/altera-a10sr.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/seq_file.h>
>> +#include <linux/syscalls.h>
>> +#include <linux/uaccess.h>
>
> Syscalls and uaccess??? I don't think so.
>
OK.

>> +struct altr_a10sr_gpio {
>> +       struct altr_a10sr *a10sc;
>> +       struct gpio_chip gp;
>> +};
>
> Add some kerneldoc.

OK. To clarify, is this comment referring to the bindings document or 
something different?

>
>> +static inline struct altr_a10sr_gpio *to_altr_a10sr_gpio(struct gpio_chip *chip)
>> +{
>> +       return container_of(chip, struct altr_a10sr_gpio, gp);
>> +}
>
> Don't use this old design pattern.
>
> Use [devm_]gpiochip_add_data() and use gpiochip_get_data(gc) to get
> a data pointer from the gpiochip.
>
>> +static int altr_a10sr_gpio_get(struct gpio_chip *gc, unsigned int nr)
>> +{
>> +       struct altr_a10sr_gpio *gpio = to_altr_a10sr_gpio(gc);
>
> So this becomes
> struct altr_a10sr_gpio *gpio = gpiochip_get_data(gc);
>

Got it. Thanks!

>> +       int ret;
>> +       unsigned char reg = ALTR_A10SR_LED_RD_REG + ALTR_A10SR_REG_OFFSET(nr);
>> +
>> +       ret = altr_a10sr_reg_read(gpio->a10sc, reg);
>> +
>> +       if (ret < 0)
>> +               return ret;
>> +
>> +       if (ret & (1 << ALTR_A10SR_REG_BIT(nr)))
>> +               return 1;
>
> Do this instead:
>
> return !!(ret & (1 << ALTR_A10SR_REG_BIT(nr)))
>
> It raises the question whether ALTR_A10SR_REG_BIT
> is just a reimplementation of the BIT() macro from
> <linux/bitops.h>, please check this.
>

Got it. Yes, I will check that. Thanks.

>> +static int altr_a10sr_gpio_direction_input(struct gpio_chip *gc,
>> +                                          unsigned int nr)
>> +{
>> +       if ((nr >= ALTR_A10SR_IN_VALID_RANGE_LO) &&
>> +           (nr <= ALTR_A10SR_IN_VALID_RANGE_HI))
>> +               return 0;
>> +       return -EINVAL;
>> +}
>> +
>> +static int altr_a10sr_gpio_direction_output(struct gpio_chip *gc,
>> +                                           unsigned int nr, int value)
>> +{
>> +       if ((nr >= ALTR_A10SR_OUT_VALID_RANGE_LO) &&
>> +           (nr <= ALTR_A10SR_OUT_VALID_RANGE_HI))
>> +               return 0;
>> +       return -EINVAL;
>> +}
>
> Does this mean that all lines are *always* input and output
> at the same time?
>
> If there is no .set_direction() callback and all lines are both
> input and output it kind of implies that all lines are also
> implicitly open drain do you agree?
>
> Please check:
> - If there is really no direction setting anywhere
> - For example if some lines are hardwired as input and
>    some lines are hardwired as output
> - If that is not the case, verify that all lines are really
>    open drain, they should be if all are both input and
>    output at the same time.
>

I see your point. I'll investigate how to do this properly for your 2nd 
check above. Registers are hard-wired as input or output so I'll need to 
handle this properly and is why I didn't implement the .set_direction 
callback. Thanks for the explanation.

In my case, there are 12 valid GPIOs out of the 16 bits (the first 4 
bits are unused). Bits 4-7 are output and bits 8-15 are inputs. I was 
using the IN_VALID range for the inputs and the OUT_VALID range for the 
outputs.

>> +       ret = gpiochip_add(&gpio->gp);
>> +       if (ret < 0) {
>> +               dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
>> +               return ret;
>> +       }
>
> Use devm_gpiochip_add_data() instead.
>

OK. Thanks for reviewing!

> Yours,
> Linus Walleij
>

  reply	other threads:[~2016-04-01 20:34 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 19:13 [RFC] Addition of Altera Arria10 System Resource Chip tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-29 19:13 ` [RFC 7/8] hwmon: Altera Arria10 System Resource Chip - HW Monitor tthayer
2016-03-29 20:16   ` Guenter Roeck
2016-03-29 21:43     ` Thor Thayer
2016-03-29 22:29       ` Mark Brown
2016-03-30 14:31         ` Thor Thayer
2016-03-29 22:30       ` Guenter Roeck
2016-03-30  8:17   ` Lee Jones
     [not found] ` <1459278791-3646-1-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2016-03-29 19:13   ` [RFC 1/8] dt-bindings: mfd: Add Altera Arria10 System Resource Chip bindings tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-30 11:35     ` Lee Jones
2016-03-31 14:06       ` Rob Herring
2016-03-31 18:21       ` Thor Thayer
2016-04-01  8:14         ` Lee Jones
2016-04-01 20:21           ` Thor Thayer
2016-04-15 17:02       ` Thor Thayer
2016-04-18  7:43         ` Lee Jones
2016-04-18 14:55           ` Thor Thayer
2016-04-18  7:45         ` Lee Jones
2016-04-18 15:12           ` Thor Thayer
2016-04-19  7:23             ` Lee Jones
2016-04-19 14:38               ` Thor Thayer
2016-04-20  1:48                 ` Guenter Roeck
2016-03-29 19:13   ` [RFC 2/8] MAINTAINERS: Addition of Altera Arria10 System Resource Chip tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-30  8:19     ` Lee Jones
2016-03-29 19:13   ` [RFC 3/8] mfd: altr_a10sr: Add Altera Arria10 DevKit " tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-30 11:51     ` Lee Jones
2016-03-30 14:52       ` Thor Thayer
2016-03-30 14:52         ` Lee Jones
2016-03-30 16:10           ` Mark Brown
2016-03-31  9:10             ` Lee Jones
2016-03-29 19:13   ` [RFC 4/8] gpio: altera-a10sr: Add A10 System Resource Chip GPIO support tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
     [not found]     ` <1459278791-3646-5-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2016-03-30  8:18       ` Lee Jones
2016-04-01 12:17     ` Linus Walleij
2016-04-01 20:34       ` Thor Thayer [this message]
2016-04-08 11:39         ` Linus Walleij
2016-03-29 19:13   ` [RFC 5/8] ARM: socfpga: dts: Add Devkit A10-SR fields for Arria10 tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
     [not found]     ` <1459278791-3646-6-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2016-03-30 17:42       ` Dinh Nguyen
2016-03-31 18:28         ` Thor Thayer
2016-03-29 19:13   ` [RFC 6/8] ARM: socfpga: dts: Add LED framework to A10-SR GPIO tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-29 19:13   ` [RFC 8/8] ARM: socfpga: dts: Add Devkit Arria10-SR HWMON tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-30  8:14   ` [RFC] Addition of Altera Arria10 System Resource Chip Lee Jones

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=56FEDB62.1010308@opensource.altera.com \
    --to=tthayer@opensource.altera.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dinguyen@opensource.altera.com \
    --cc=gnurou@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jdelvare@suse.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mark.rutland@arm.com \
    --cc=pawell.moll@arm.com \
    --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: 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;
as well as URLs for NNTP newsgroup(s).