All of lore.kernel.org
 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
>

WARNING: multiple messages have this Message-ID (diff)
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: 75+ 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 ` tthayer
     [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-29 19:13     ` tthayer
2016-03-30 11:35     ` Lee Jones
2016-03-30 11:36       ` Lee Jones
2016-03-31 14:06       ` Rob Herring
2016-03-31 18:21       ` Thor Thayer
2016-03-31 18:21         ` Thor Thayer
2016-04-01  8:14         ` Lee Jones
2016-04-01  8:14           ` Lee Jones
2016-04-01 20:21           ` Thor Thayer
2016-04-01 20:21             ` Thor Thayer
2016-03-29 19:13   ` [RFC 2/8] MAINTAINERS: Addition of Altera Arria10 System Resource Chip tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-29 19:13     ` tthayer
2016-03-30  8:19     ` Lee Jones
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-29 19:13     ` tthayer
2016-03-30 11:51     ` Lee Jones
2016-03-30 11:51       ` Lee Jones
2016-03-30 14:52       ` Thor Thayer
2016-03-30 14:52         ` Thor Thayer
2016-03-30 14:52         ` Lee Jones
2016-03-30 14:52           ` Lee Jones
2016-03-30 16:10           ` Mark Brown
2016-03-31  9:10             ` Lee Jones
2016-03-31  9:11               ` Lee Jones
2016-03-29 19:13   ` [RFC 4/8] gpio: altera-a10sr: Add A10 System Resource Chip GPIO support tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-29 19:13     ` tthayer
     [not found]     ` <1459278791-3646-5-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2016-03-30  8:18       ` Lee Jones
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-01 20:34         ` Thor Thayer
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
2016-03-29 19:13     ` tthayer
     [not found]     ` <1459278791-3646-6-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2016-03-30 17:42       ` Dinh Nguyen
2016-03-30 17:42         ` Dinh Nguyen
2016-03-31 18:28         ` Thor Thayer
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     ` tthayer
2016-03-29 19:13   ` [RFC 8/8] ARM: socfpga: dts: Add Devkit Arria10-SR HWMON tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2016-03-29 19:13     ` tthayer
2016-03-30  8:14   ` [RFC] Addition of Altera Arria10 System Resource Chip Lee Jones
2016-03-30  8:14     ` Lee Jones
2016-03-29 19:13 ` [RFC 7/8] hwmon: Altera Arria10 System Resource Chip - HW Monitor tthayer
2016-03-29 19:13   ` tthayer
2016-03-29 20:16   ` Guenter Roeck
2016-03-29 21:43     ` Thor Thayer
2016-03-29 21:43       ` Thor Thayer
2016-03-29 22:29       ` Mark Brown
2016-03-29 22:30       ` Guenter Roeck
2016-03-30  8:17   ` Lee Jones
2016-03-30  8:18     ` Lee Jones
2016-03-30 14:27 ` Thor Thayer
2016-03-30 14:31   ` Thor Thayer
2016-04-15 16:57 ` [RFC 1/8] dt-bindings: mfd: Add Altera Arria10 System Resource Chip bindings Thor Thayer
2016-04-15 17:02   ` Thor Thayer
2016-04-18  7:43   ` Lee Jones
2016-04-18  7:44     ` Lee Jones
2016-04-18  7:45   ` Lee Jones
2016-04-18  7:46     ` Lee Jones
2016-04-18 14:51 ` Thor Thayer
2016-04-18 14:55   ` Thor Thayer
2016-04-18 15:07 ` Thor Thayer
2016-04-18 15:12   ` Thor Thayer
2016-04-19  7:23   ` Lee Jones
2016-04-19  7:25     ` Lee Jones
2016-04-19 14:38     ` Thor Thayer
2016-04-19 14:38       ` Thor Thayer
2016-04-20  1:48       ` Guenter Roeck
2016-04-20  1:48         ` Guenter Roeck

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 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.