Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1640854 > unrolled thread

[PATCH 0/8] serial/gpio: exar: Fixes and support for IOT2000

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/8] serial/gpio: exar: Fixes and support for IOT2000 Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-13 09:40 +0200
    [PATCH 5/8] gpio: exar: Fix reading of directions and values Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-13 09:40 +0200
      Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-13 15:40 +0200
        Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-18 07:30 +0200
          Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-18 12:20 +0200
            Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-18 12:30 +0200
            Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-18 12:30 +0200
          Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-18 12:20 +0200
    [PATCH 7/8] gpio-exar/8250-exar: Make set of exported GPIOs configurable Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-13 09:40 +0200
      Re: [PATCH 7/8] gpio-exar/8250-exar: Make set of exported GPIOs configurable Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-13 16:00 +0200
    [PATCH 1/8] serial: exar: Preconfigure xr17v35x MPIOs as output Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-13 09:40 +0200
      Re: [PATCH 1/8] serial: exar: Preconfigure xr17v35x MPIOs as output Linus Walleij <linus.walleij@linaro.org> - 2017-05-22 17:50 +0200
    [PATCH 3/8] gpio: exar: Allocate resources on behalf of the platform device Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-13 09:40 +0200
      Re: [PATCH 3/8] gpio: exar: Allocate resources on behalf of the  platform device Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-13 15:30 +0200
      Re: [PATCH 3/8] gpio: exar: Allocate resources on behalf of the  platform device Linus Walleij <linus.walleij@linaro.org> - 2017-05-22 17:50 +0200
    [PATCH 6/8] serial: uapi: Add support for bus termination Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-13 09:40 +0200

#1640854 — [PATCH 0/8] serial/gpio: exar: Fixes and support for IOT2000

This makes the gpio-exar driver usable, which was prevented by a number
of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar
driver and, indirectly, to gpio-exar as well. It's a cross-subsystem
series, so I'm also cross-posting to the serial and gpio lists.

Jan

Jan Kiszka (8):
  serial: exar: Preconfigure xr17v35x MPIOs as output
  gpio: exar: Fix passing in of parent PCI device
  gpio: exar: Allocate resources on behalf of the platform device
  gpio: exar: Fix iomap request
  gpio: exar: Fix reading of directions and values
  serial: uapi: Add support for bus termination
  gpio-exar/8250-exar: Make set of exported GPIOs configurable
  serial: exar: Add support for IOT2040 device

 drivers/gpio/gpio-exar.c            |  55 ++++++++------
 drivers/tty/serial/8250/8250_exar.c | 145 +++++++++++++++++++++++++++++++++---
 include/uapi/linux/serial.h         |   3 +
 3 files changed, 169 insertions(+), 34 deletions(-)

-- 
2.12.0

[toc] | [next] | [standalone]

#1640855 — [PATCH 5/8] gpio: exar: Fix reading of directions and values

First, the logic for translating a register bit to the return code of
exar_get_direction and exar_get_value were wrong. And second, there was
a flip regarding the register bank in exar_get_direction.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/gpio/gpio-exar.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index d6ffb3d89b9c..98bd3eb1290e 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
 	value = readb(exar_gpio->regs + reg);
 	mutex_unlock(&exar_gpio->lock);
 
-	return !!value;
+	return value;
 }
 
 static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
@@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
 	addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
 	val = exar_get(chip, addr) >> (offset % 8);
 
-	return !!val;
+	return val & 1;
 }
 
 static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
@@ -89,10 +89,10 @@ static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
 	unsigned int addr;
 	int val;
 
-	addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI;
+	addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
 	val = exar_get(chip, addr) >> (offset % 8);
 
-	return !!val;
+	return val & 1;
 }
 
 static void exar_set_value(struct gpio_chip *chip, unsigned int offset,
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]

#1640916 — Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> First, the logic for translating a register bit to the return code of
> exar_get_direction and exar_get_value were wrong. And second, there was
> a flip regarding the register bank in exar_get_direction.

Again, I wish it was tested in the first place.

After addressing below:
FWIW:
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
>         value = readb(exar_gpio->regs + reg);
>         mutex_unlock(&exar_gpio->lock);
>
> -       return !!value;
> +       return value;

This one is correct.

> @@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
>         addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
>         val = exar_get(chip, addr) >> (offset % 8);
>
> -       return !!val;
> +       return val & 1;

It should be rather

        val = exar_get(chip, addr) & BIT(offset % 8);

>  }
>
>  static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
> @@ -89,10 +89,10 @@ static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
>         unsigned int addr;
>         int val;
>
> -       addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI;
> +       addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;

Good catch!

>         val = exar_get(chip, addr) >> (offset % 8);
>
> -       return !!val;
> +       return val & 1;

Ditto (see above).

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1643821 — Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

On 2017-05-13 15:36, Andy Shevchenko wrote:
> On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> First, the logic for translating a register bit to the return code of
>> exar_get_direction and exar_get_value were wrong. And second, there was
>> a flip regarding the register bank in exar_get_direction.
> 
> Again, I wish it was tested in the first place.
> 
> After addressing below:
> FWIW:
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> 
>> @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
>>         value = readb(exar_gpio->regs + reg);
>>         mutex_unlock(&exar_gpio->lock);
>>
>> -       return !!value;
>> +       return value;
> 
> This one is correct.
> 
>> @@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
>>         addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
>>         val = exar_get(chip, addr) >> (offset % 8);
>>
>> -       return !!val;
>> +       return val & 1;
> 
> It should be rather
> 
>         val = exar_get(chip, addr) & BIT(offset % 8);

That won't give us 0 or 1 as return value, thus would be incorrect.

> 
>>  }
>>
>>  static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
>> @@ -89,10 +89,10 @@ static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
>>         unsigned int addr;
>>         int val;
>>
>> -       addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI;
>> +       addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
> 
> Good catch!
> 
>>         val = exar_get(chip, addr) >> (offset % 8);
>>
>> -       return !!val;
>> +       return val & 1;
> 
> Ditto (see above).
> 

Same here.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[toc] | [prev] | [next] | [standalone]

#1644046 — Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

On 2017-05-18 12:11, Andy Shevchenko wrote:
> On Thu, May 18, 2017 at 8:20 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2017-05-13 15:36, Andy Shevchenko wrote:
>>> On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> First, the logic for translating a register bit to the return code of
>>>> exar_get_direction and exar_get_value were wrong. And second, there was
>>>> a flip regarding the register bank in exar_get_direction.
>>>
>>> Again, I wish it was tested in the first place.
>>>
>>> After addressing below:
>>> FWIW:
>>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>>>
>>>> @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
>>>>         value = readb(exar_gpio->regs + reg);
>>>>         mutex_unlock(&exar_gpio->lock);
>>>>
>>>> -       return !!value;
>>>> +       return value;
>>>
>>> This one is correct.
> 
>>>
>>>> @@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
>>>>         addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
>>>>         val = exar_get(chip, addr) >> (offset % 8);
>>>>
>>>> -       return !!val;
>>>> +       return val & 1;
>>>
>>> It should be rather
>>>
>>>         val = exar_get(chip, addr) & BIT(offset % 8);
>>
>> That won't give us 0 or 1 as return value, thus would be incorrect.
> 
> Full picture:
> 
>  val = exar_get(chip, addr) & BIT(offset % 8);
> 
>  return !!val;
> 
> How it could be non-(1 or 0)?
> 

Right - but what is the point of that other style?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[toc] | [prev] | [next] | [standalone]

#1644052 — Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

On 2017-05-18 12:23, Andy Shevchenko wrote:
> On Thu, May 18, 2017 at 1:16 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2017-05-18 12:11, Andy Shevchenko wrote:
>>> On Thu, May 18, 2017 at 8:20 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>>> Full picture:
>>>
>>>  val = exar_get(chip, addr) & BIT(offset % 8);
>>>
>>>  return !!val;
>>>
>>> How it could be non-(1 or 0)?
>>>
>>
>> Right - but what is the point of that other style?
> 
> gpio-exar.c is just 4th module which is using it, OTOH the rest of
> GPIO drivers are using return !!val style.
> 

OK, consistency is valid point. Will adjust.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[toc] | [prev] | [next] | [standalone]

#1644055 — Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

On Thu, May 18, 2017 at 1:16 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-05-18 12:11, Andy Shevchenko wrote:
>> On Thu, May 18, 2017 at 8:20 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

>> Full picture:
>>
>>  val = exar_get(chip, addr) & BIT(offset % 8);
>>
>>  return !!val;
>>
>> How it could be non-(1 or 0)?
>>
>
> Right - but what is the point of that other style?

gpio-exar.c is just 4th module which is using it, OTOH the rest of
GPIO drivers are using return !!val style.


-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1644049 — Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

On Thu, May 18, 2017 at 8:20 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-05-13 15:36, Andy Shevchenko wrote:
>> On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> First, the logic for translating a register bit to the return code of
>>> exar_get_direction and exar_get_value were wrong. And second, there was
>>> a flip regarding the register bank in exar_get_direction.
>>
>> Again, I wish it was tested in the first place.
>>
>> After addressing below:
>> FWIW:
>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>>
>>> @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
>>>         value = readb(exar_gpio->regs + reg);
>>>         mutex_unlock(&exar_gpio->lock);
>>>
>>> -       return !!value;
>>> +       return value;
>>
>> This one is correct.

>>
>>> @@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
>>>         addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
>>>         val = exar_get(chip, addr) >> (offset % 8);
>>>
>>> -       return !!val;
>>> +       return val & 1;
>>
>> It should be rather
>>
>>         val = exar_get(chip, addr) & BIT(offset % 8);
>
> That won't give us 0 or 1 as return value, thus would be incorrect.

Full picture:

 val = exar_get(chip, addr) & BIT(offset % 8);

 return !!val;

How it could be non-(1 or 0)?

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1640856 — [PATCH 7/8] gpio-exar/8250-exar: Make set of exported GPIOs configurable

On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
rest is required to operate the UART. To allow modeling this case,
use device properties to specify a (consecutive) pin subset for
exporting by the gpio-exar driver.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/gpio/gpio-exar.c            | 31 ++++++++++++++++++++++---------
 drivers/tty/serial/8250/8250_exar.c | 16 ++++++++++++----
 2 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 98bd3eb1290e..e2cb1d83e4b0 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -31,6 +31,7 @@ struct exar_gpio_chip {
 	int index;
 	void __iomem *regs;
 	char name[20];
+	unsigned int first_gpio;
 };
 
 static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
@@ -51,9 +52,11 @@ static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
 static int exar_set_direction(struct gpio_chip *chip, int direction,
 			      unsigned int offset)
 {
-	unsigned int bank = offset / 8;
-	unsigned int addr;
+	struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+	unsigned int bank, addr;
 
+	offset += exar_gpio->first_gpio;
+	bank = offset / 8;
 	addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
 	exar_update(chip, addr, direction, offset % 8);
 	return 0;
@@ -73,10 +76,12 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
 
 static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
 {
-	unsigned int bank = offset / 8;
-	unsigned int addr;
+	struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+	unsigned int bank, addr;
 	int val;
 
+	offset += exar_gpio->first_gpio;
+	bank = offset / 8;
 	addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
 	val = exar_get(chip, addr) >> (offset % 8);
 
@@ -85,10 +90,12 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
 
 static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
 {
-	unsigned int bank = offset / 8;
-	unsigned int addr;
+	struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+	unsigned int bank, addr;
 	int val;
 
+	offset += exar_gpio->first_gpio;
+	bank = offset / 8;
 	addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
 	val = exar_get(chip, addr) >> (offset % 8);
 
@@ -98,9 +105,11 @@ static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
 static void exar_set_value(struct gpio_chip *chip, unsigned int offset,
 			   int value)
 {
-	unsigned int bank = offset / 8;
-	unsigned int addr;
+	struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+	unsigned int bank, addr;
 
+	offset += exar_gpio->first_gpio;
+	bank = offset / 8;
 	addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
 	exar_update(chip, addr, value, offset % 8);
 }
@@ -123,6 +132,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	struct exar_gpio_chip *exar_gpio;
 	void __iomem *p;
 	int index, ret;
+	u32 val;
 
 	if (pcidev->vendor != PCI_VENDOR_ID_EXAR)
 		return -ENODEV;
@@ -152,9 +162,12 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	exar_gpio->gpio_chip.get = exar_get_value;
 	exar_gpio->gpio_chip.set = exar_set_value;
 	exar_gpio->gpio_chip.base = -1;
-	exar_gpio->gpio_chip.ngpio = 16;
+	device_property_read_u32(&pdev->dev, "ngpio", &val);
+	exar_gpio->gpio_chip.ngpio = val;
 	exar_gpio->regs = p;
 	exar_gpio->index = index;
+	device_property_read_u32(&pdev->dev, "first_gpio", &val);
+	exar_gpio->first_gpio = val;
 
 	ret = devm_gpiochip_add_data(&pdev->dev,
 				     &exar_gpio->gpio_chip, exar_gpio);
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 2d056d1eeca3..8e9c0e9495f5 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -19,6 +19,7 @@
 #include <linux/string.h>
 #include <linux/tty.h>
 #include <linux/8250_pci.h>
+#include <linux/property.h>
 
 #include <asm/byteorder.h>
 
@@ -188,8 +189,14 @@ static void setup_gpio(u8 __iomem *p)
 }
 
 static void *
-xr17v35x_register_gpio(struct pci_dev *pcidev)
+xr17v35x_register_gpio(struct pci_dev *pcidev, unsigned int first_gpio,
+		       unsigned int ngpio)
 {
+	struct property_entry properties[] = {
+		PROPERTY_ENTRY_U32("first_gpio", first_gpio),
+		PROPERTY_ENTRY_U32("ngpio", ngpio),
+		{ }
+	};
 	struct platform_device *pdev;
 
 	pdev = platform_device_alloc("gpio_exar", PLATFORM_DEVID_AUTO);
@@ -197,10 +204,11 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
 		return NULL;
 
 	/*
-	 * platform_device_add_data kmemdups the data, therefore we can safely
-	 * pass a stack reference.
+	 * platform_device_add_data and platform_device_add_properties copy
+	 * the data, therefore we can safely pass a stack references.
 	 */
 	if (platform_device_add_data(pdev, &pcidev, sizeof(pcidev)) < 0 ||
+	    platform_device_add_properties(pdev, properties) < 0 ||
 	    platform_device_add(pdev) < 0) {
 		platform_device_put(pdev);
 		return NULL;
@@ -242,7 +250,7 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
 		/* Setup Multipurpose Input/Output pins. */
 		setup_gpio(p);
 
-		port->port.private_data = xr17v35x_register_gpio(pcidev);
+		port->port.private_data = xr17v35x_register_gpio(pcidev, 0, 16);
 	}
 
 	return 0;
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]

#1640920 — Re: [PATCH 7/8] gpio-exar/8250-exar: Make set of exported GPIOs configurable

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
> rest is required to operate the UART. To allow modeling this case,
> use device properties to specify a (consecutive) pin subset for
> exporting by the gpio-exar driver.

> @@ -123,6 +132,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
>         struct exar_gpio_chip *exar_gpio;
>         void __iomem *p;
>         int index, ret;
> +       u32 val;
>
>         if (pcidev->vendor != PCI_VENDOR_ID_EXAR)
>                 return -ENODEV;
> @@ -152,9 +162,12 @@ static int gpio_exar_probe(struct platform_device *pdev)
>         exar_gpio->gpio_chip.get = exar_get_value;
>         exar_gpio->gpio_chip.set = exar_set_value;
>         exar_gpio->gpio_chip.base = -1;
> -       exar_gpio->gpio_chip.ngpio = 16;

> +       device_property_read_u32(&pdev->dev, "ngpio", &val);
> +       exar_gpio->gpio_chip.ngpio = val;

You have to check return code, otherwise you might end up with
uninitialized data.

>         exar_gpio->regs = p;
>         exar_gpio->index = index;
> +       device_property_read_u32(&pdev->dev, "first_gpio", &val);
> +       exar_gpio->first_gpio = val;

Ditto.

>  #include <linux/string.h>
>  #include <linux/tty.h>
>  #include <linux/8250_pci.h>

> +#include <linux/property.h>

Alphabetical order, please.

>  static void *
> -xr17v35x_register_gpio(struct pci_dev *pcidev)
> +xr17v35x_register_gpio(struct pci_dev *pcidev, unsigned int first_gpio,
> +                      unsigned int ngpio)
>  {
> +       struct property_entry properties[] = {

> +               PROPERTY_ENTRY_U32("first_gpio", first_gpio),

This should be documented in device tree bindings, otherwise it's a
linux software hook and I'm not sure it's the best what we can do
here.

> +               PROPERTY_ENTRY_U32("ngpio", ngpio),

This should be a registered property name (I see "ngpios" in the bindings).

> +               { }
> +       };
>         struct platform_device *pdev;
>
>         pdev = platform_device_alloc("gpio_exar", PLATFORM_DEVID_AUTO);


>         /*
> -        * platform_device_add_data kmemdups the data, therefore we can safely
> -        * pass a stack reference.
> +        * platform_device_add_data and platform_device_add_properties copy
> +        * the data, therefore we can safely pass a stack references.
>          */

Can you formulate this in an order to reduce ping-ponging lines across
the series?

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1640857 — [PATCH 1/8] serial: exar: Preconfigure xr17v35x MPIOs as output

This is the safe default for GPIOs with unknown external wiring.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/tty/serial/8250/8250_exar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 1270ff163f63..b4fa585156c7 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -177,13 +177,13 @@ static void setup_gpio(u8 __iomem *p)
 	writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
 	writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
 	writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
-	writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
+	writeb(0xff, p + UART_EXAR_MPIOSEL_7_0);
 	writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
 	writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
 	writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
 	writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
 	writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
-	writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
+	writeb(0xff, p + UART_EXAR_MPIOSEL_15_8);
 	writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
 }
 
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]

#1647056 — Re: [PATCH 1/8] serial: exar: Preconfigure xr17v35x MPIOs as output

On Sat, May 13, 2017 at 9:28 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> This is the safe default for GPIOs with unknown external wiring.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1640858 — [PATCH 3/8] gpio: exar: Allocate resources on behalf of the platform device

Do not allocate resources on behalf of the parent device but on our own.
Otherwise, cleanup does not properly work if gpio-exar is removed but
not the parent device.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/gpio/gpio-exar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 0a2085faf271..9138ee087c5d 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -139,7 +139,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	if (!p)
 		return -ENOMEM;
 
-	exar_gpio = devm_kzalloc(&pcidev->dev, sizeof(*exar_gpio), GFP_KERNEL);
+	exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL);
 	if (!exar_gpio)
 		return -ENOMEM;
 
@@ -160,7 +160,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	exar_gpio->regs = p;
 	exar_gpio->index = index;
 
-	ret = devm_gpiochip_add_data(&pcidev->dev,
+	ret = devm_gpiochip_add_data(&pdev->dev,
 				     &exar_gpio->gpio_chip, exar_gpio);
 	if (ret)
 		goto err_destroy;
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]

#1640914 — Re: [PATCH 3/8] gpio: exar: Allocate resources on behalf of the platform device

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Do not allocate resources on behalf of the parent device but on our own.
> Otherwise, cleanup does not properly work if gpio-exar is removed but
> not the parent device.

This sounds to me like a good catch.
FWIW:
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  drivers/gpio/gpio-exar.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
> index 0a2085faf271..9138ee087c5d 100644
> --- a/drivers/gpio/gpio-exar.c
> +++ b/drivers/gpio/gpio-exar.c
> @@ -139,7 +139,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
>         if (!p)
>                 return -ENOMEM;
>
> -       exar_gpio = devm_kzalloc(&pcidev->dev, sizeof(*exar_gpio), GFP_KERNEL);
> +       exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL);
>         if (!exar_gpio)
>                 return -ENOMEM;
>
> @@ -160,7 +160,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
>         exar_gpio->regs = p;
>         exar_gpio->index = index;
>
> -       ret = devm_gpiochip_add_data(&pcidev->dev,
> +       ret = devm_gpiochip_add_data(&pdev->dev,
>                                      &exar_gpio->gpio_chip, exar_gpio);
>         if (ret)
>                 goto err_destroy;
> --
> 2.12.0
>



-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1647050 — Re: [PATCH 3/8] gpio: exar: Allocate resources on behalf of the platform device

On Sat, May 13, 2017 at 9:29 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> Do not allocate resources on behalf of the parent device but on our own.
> Otherwise, cleanup does not properly work if gpio-exar is removed but
> not the parent device.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1640859 — [PATCH 6/8] serial: uapi: Add support for bus termination

The Siemens IOT2040 comes with a RS485 interface that allows to enable
or disable bus termination via software. Add a bit to the flags field of
serial_rs485 that applications can set in order to request this feature
from the hardware. This seems generic enough to add it for everyone.
Existing driver will simply ignore it when set.

Signed-off-by: Sascha Weisenberger <sascha.weisenberger@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 include/uapi/linux/serial.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h
index 5d59c3ebf459..d2667ecd54ac 100644
--- a/include/uapi/linux/serial.h
+++ b/include/uapi/linux/serial.h
@@ -122,6 +122,9 @@ struct serial_rs485 {
 #define SER_RS485_RTS_AFTER_SEND	(1 << 2)	/* Logical level for
 							   RTS pin after sent*/
 #define SER_RS485_RX_DURING_TX		(1 << 4)
+#define SER_RS485_TERMINATE_BUS		(1 << 5)	/* Enable bus
+							   termination
+							   (if supported) */
 	__u32	delay_rts_before_send;	/* Delay before send (milliseconds) */
 	__u32	delay_rts_after_send;	/* Delay after send (milliseconds) */
 	__u32	padding[5];		/* Memory is cheap, new structs
-- 
2.12.0

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web