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

Groups > linux.kernel > #1651463 > unrolled thread

[PATCH v3 00/10] serial/gpio: exar: Fixes and support for IOT2000

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 00/10] serial/gpio: exar: Fixes and support for IOT2000 Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-26 18:10 +0200
    [PATCH v3 04/10] gpio: exar: Allocate resources on behalf of the platform device Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-26 18:10 +0200
      Re: [PATCH v3 04/10] gpio: exar: Allocate resources on behalf of the  platform device Linus Walleij <linus.walleij@linaro.org> - 2017-05-29 14:40 +0200
    [PATCH v3 03/10] gpio-exar/8250-exar: Fix passing in of parent PCI device Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-26 18:10 +0200
      Re: [PATCH v3 03/10] gpio-exar/8250-exar: Fix passing in of parent  PCI device Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-27 15:50 +0200
      Re: [PATCH v3 03/10] gpio-exar/8250-exar: Fix passing in of parent  PCI device Linus Walleij <linus.walleij@linaro.org> - 2017-05-29 14:40 +0200
    [PATCH v3 05/10] gpio: exar: Fix iomap request Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-26 18:10 +0200
      Re: [PATCH v3 05/10] gpio: exar: Fix iomap request Linus Walleij <linus.walleij@linaro.org> - 2017-05-29 14:40 +0200
    Re: [PATCH v3 00/10] serial/gpio: exar: Fixes and support for IOT2000 Linus Walleij <linus.walleij@linaro.org> - 2017-05-29 14:40 +0200
      Re: [PATCH v3 00/10] serial/gpio: exar: Fixes and support for IOT2000 Jan Kiszka <jan.kiszka@siemens.com> - 2017-05-29 15:50 +0200
        Re: [PATCH v3 00/10] serial/gpio: exar: Fixes and support for IOT2000 Linus Walleij <linus.walleij@linaro.org> - 2017-05-31 02:10 +0200

#1651463 — [PATCH v3 00/10] 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.

Changes in v3:
 - fix MPIO state for Commtech adapters (regression of merged patch from
   previous round)
 - do not create gpio device for Commtech adapters
 - switch back to device properties
 - pass parent reference via device.parent instead of platform data
 - use dmi_system_id table instead of open-coded matching
 - address some smaller review remarks
 - fix reading back of rs485 state
 - adjust parenthood of exar gpiochip

Jan

Jan Kiszka (10):
  serial: exar: Leave MPIOs as output for Commtech adapters
  gpio-exar/8250-exar: Do not even instantiate a GPIO device for
    Commtech cards
  gpio-exar/8250-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
  gpio-exar/8250-exar: Rearrange gpiochip parenthood
  gpio: exar: Refactor address and bit calculations
  gpio-exar/8250-exar: Make set of exported GPIOs configurable
  serial: exar: Add support for IOT2040 device

 drivers/gpio/gpio-exar.c            |  74 ++++++++-------
 drivers/tty/serial/8250/8250_exar.c | 180 ++++++++++++++++++++++++++++++++++--
 2 files changed, 207 insertions(+), 47 deletions(-)

-- 
2.12.0

[toc] | [next] | [standalone]

#1651467 — [PATCH v3 04/10] 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>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.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 da4550bb9939..65126fa1e512 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -136,7 +136,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;
 
@@ -157,7 +157,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]

#1652497 — Re: [PATCH v3 04/10] gpio: exar: Allocate resources on behalf of the platform device

On Fri, May 26, 2017 at 6:02 PM, 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>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

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

Yours,
Linus Walleij

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

#1651468 — [PATCH v3 03/10] gpio-exar/8250-exar: Fix passing in of parent PCI device

This fixes reloading of the GPIO driver for the same platform device
instance as created by the exar UART driver: First of all, the driver
sets drvdata to its own value during probing and does not restore the
original value on exit. But this won't help anyway as the core clears
drvdata after the driver left.

Set the platform device parent instead.

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

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 006a9a67c2a4..da4550bb9939 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -119,7 +119,7 @@ static int exar_direction_input(struct gpio_chip *chip, unsigned int offset)
 
 static int gpio_exar_probe(struct platform_device *pdev)
 {
-	struct pci_dev *pcidev = platform_get_drvdata(pdev);
+	struct pci_dev *pcidev = to_pci_dev(pdev->dev.parent);
 	struct exar_gpio_chip *exar_gpio;
 	void __iomem *p;
 	int index, ret;
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index c29c7e675890..0f4b236d7e68 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -203,7 +203,8 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
 	if (!pdev)
 		return NULL;
 
-	platform_set_drvdata(pdev, pcidev);
+	pdev->dev.parent = &pcidev->dev;
+
 	if (platform_device_add(pdev) < 0) {
 		platform_device_put(pdev);
 		return NULL;
-- 
2.12.0

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

#1651881 — Re: [PATCH v3 03/10] gpio-exar/8250-exar: Fix passing in of parent PCI device

On Fri, May 26, 2017 at 7:02 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> This fixes reloading of the GPIO driver for the same platform device
> instance as created by the exar UART driver: First of all, the driver
> sets drvdata to its own value during probing and does not restore the
> original value on exit. But this won't help anyway as the core clears
> drvdata after the driver left.
>
> Set the platform device parent instead.

Now this one looks much better than first efforts.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  drivers/gpio/gpio-exar.c            | 2 +-
>  drivers/tty/serial/8250/8250_exar.c | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
> index 006a9a67c2a4..da4550bb9939 100644
> --- a/drivers/gpio/gpio-exar.c
> +++ b/drivers/gpio/gpio-exar.c
> @@ -119,7 +119,7 @@ static int exar_direction_input(struct gpio_chip *chip, unsigned int offset)
>
>  static int gpio_exar_probe(struct platform_device *pdev)
>  {
> -       struct pci_dev *pcidev = platform_get_drvdata(pdev);
> +       struct pci_dev *pcidev = to_pci_dev(pdev->dev.parent);
>         struct exar_gpio_chip *exar_gpio;
>         void __iomem *p;
>         int index, ret;
> diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
> index c29c7e675890..0f4b236d7e68 100644
> --- a/drivers/tty/serial/8250/8250_exar.c
> +++ b/drivers/tty/serial/8250/8250_exar.c
> @@ -203,7 +203,8 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
>         if (!pdev)
>                 return NULL;
>
> -       platform_set_drvdata(pdev, pcidev);
> +       pdev->dev.parent = &pcidev->dev;
> +
>         if (platform_device_add(pdev) < 0) {
>                 platform_device_put(pdev);
>                 return NULL;
> --
> 2.12.0
>



-- 
With Best Regards,
Andy Shevchenko

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

#1652495 — Re: [PATCH v3 03/10] gpio-exar/8250-exar: Fix passing in of parent PCI device

On Fri, May 26, 2017 at 6:02 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> This fixes reloading of the GPIO driver for the same platform device
> instance as created by the exar UART driver: First of all, the driver
> sets drvdata to its own value during probing and does not restore the
> original value on exit. But this won't help anyway as the core clears
> drvdata after the driver left.
>
> Set the platform device parent instead.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

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

Yours,
Linus Walleij

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

#1651470 — [PATCH v3 05/10] gpio: exar: Fix iomap request

The UART driver already maps the resource for us. Trying to do this here
only fails and leaves us with a non-working device.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 drivers/gpio/gpio-exar.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 65126fa1e512..b29890b143ce 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -125,14 +125,10 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	int index, ret;
 
 	/*
-	 * Map the pci device to get the register addresses.
-	 * We will need to read and write those registers to control
-	 * the GPIO pins.
-	 * Using managed functions will save us from unmaping on exit.
-	 * As the device is enabled using managed functions by the
-	 * UART driver we can also use managed functions here.
+	 * The UART driver must have mapped region 0 prior to registering this
+	 * device - use it.
 	 */
-	p = pcim_iomap(pcidev, 0, 0);
+	p = pcim_iomap_table(pcidev)[0];
 	if (!p)
 		return -ENOMEM;
 
-- 
2.12.0

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

#1652494 — Re: [PATCH v3 05/10] gpio: exar: Fix iomap request

On Fri, May 26, 2017 at 6:02 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> The UART driver already maps the resource for us. Trying to do this here
> only fails and leaves us with a non-working device.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

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

Yours,
Linus Walleij

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

#1652493

On Fri, May 26, 2017 at 6:02 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> 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.
>
> Changes in v3:
>  - fix MPIO state for Commtech adapters (regression of merged patch from
>    previous round)
>  - do not create gpio device for Commtech adapters
>  - switch back to device properties
>  - pass parent reference via device.parent instead of platform data
>  - use dmi_system_id table instead of open-coded matching
>  - address some smaller review remarks
>  - fix reading back of rs485 state
>  - adjust parenthood of exar gpiochip

I ACKed some patches if Greg need to merge them.

Can you suggest a merge strategy for this patch set?

It appears Greg will have to merge at least the first one.

Will it work to merge the GPIO patches orthogonally to the GPIO
tree or are they all dependent on the serial changes?

Should I merge them all? Should Greg merge them all?
Should one of us produce an immutable branch?

Yours,
Linus Walleij

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

#1652536

On 2017-05-29 14:39, Linus Walleij wrote:
> On Fri, May 26, 2017 at 6:02 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>> 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.
>>
>> Changes in v3:
>>  - fix MPIO state for Commtech adapters (regression of merged patch from
>>    previous round)
>>  - do not create gpio device for Commtech adapters
>>  - switch back to device properties
>>  - pass parent reference via device.parent instead of platform data
>>  - use dmi_system_id table instead of open-coded matching
>>  - address some smaller review remarks
>>  - fix reading back of rs485 state
>>  - adjust parenthood of exar gpiochip
> 
> I ACKed some patches if Greg need to merge them.

Thanks!

> 
> Can you suggest a merge strategy for this patch set?
> 
> It appears Greg will have to merge at least the first one.
> 
> Will it work to merge the GPIO patches orthogonally to the GPIO
> tree or are they all dependent on the serial changes?
> 
> Should I merge them all? Should Greg merge them all?
> Should one of us produce an immutable branch?

Half of the patch are affecting both serial and GPIO subsystem, most
have GPIO focus, though. Just patch 10 or more serial than GPIO. All in
all, maybe Greg can ack and things can flow through the GPIO tree?

Jan

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

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

#1653732

On Mon, May 29, 2017 at 3:41 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-05-29 14:39, Linus Walleij wrote:

>> Should I merge them all? Should Greg merge them all?
>> Should one of us produce an immutable branch?
>
> Half of the patch are affecting both serial and GPIO subsystem, most
> have GPIO focus, though. Just patch 10 or more serial than GPIO. All in
> all, maybe Greg can ack and things can flow through the GPIO tree?

OK with me, let's see what Greg says.

Yours,
Linus Walleij

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web