LinuxLists.cc - [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

[permalink] [raw]

Subject: [PATCH v6 03/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 <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
---
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.3

2017-06-09 18:33:32

[permalink] [raw]

Subject: [PATCH v6 06/10] gpio-exar/8250-exar: Rearrange gpiochip parenthood

Set the parent of the exar gpiochip to its platform device, like other
gpiochips are doing it. In order to keep the relationship discoverable
for ACPI systems, set the platform device companion to the PCI device.

Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
---
drivers/gpio/gpio-exar.c | 2 +-
drivers/tty/serial/8250/8250_exar.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index f3585a184f39..1a629831d45b 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -142,7 +142,7 @@ static int gpio_exar_probe(struct platform_device *pdev)

sprintf(exar_gpio->name, "exar_gpio%d", index);
exar_gpio->gpio_chip.label = exar_gpio->name;
- exar_gpio->gpio_chip.parent = &pcidev->dev;
+ exar_gpio->gpio_chip.parent = &pdev->dev;
exar_gpio->gpio_chip.direction_output = exar_direction_output;
exar_gpio->gpio_chip.direction_input = exar_direction_input;
exar_gpio->gpio_chip.get_direction = exar_get_direction;
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 0f4b236d7e68..ee4b142f3ed0 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -9,6 +9,7 @@
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License.
*/
+#include <linux/acpi.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -204,6 +205,7 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
return NULL;

pdev->dev.parent = &pcidev->dev;
+ ACPI_COMPANION_SET(&pdev->dev, ACPI_COMPANION(&pcidev->dev));

if (platform_device_add(pdev) < 0) {
platform_device_put(pdev);
--
2.12.3

2017-06-09 18:33:42

[permalink] [raw]

Subject: [PATCH v6 07/10] serial: exar: Factor out platform hooks

This prepares the addition of IOT2040 platform support by preparing the
needed setup and rs485_config hooks.

Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
drivers/tty/serial/8250/8250_exar.c | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index ee4b142f3ed0..1106f1f58c77 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -63,6 +63,11 @@

struct exar8250;

+struct exar8250_platform {
+ int (*rs485_config)(struct uart_port *, struct serial_rs485 *);
+ int (*register_gpio)(struct pci_dev *, struct uart_8250_port *);
+};
+
/**
* struct exar8250_board - board information
* @num_ports: number of serial ports
@@ -196,7 +201,7 @@ static void setup_gpio(struct pci_dev *pcidev, u8 __iomem *p)
}

static void *
-xr17v35x_register_gpio(struct pci_dev *pcidev)
+__xr17v35x_register_gpio(struct pci_dev *pcidev)
{
struct platform_device *pdev;

@@ -215,17 +220,36 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
return pdev;
}

+static int xr17v35x_register_gpio(struct pci_dev *pcidev,
+ struct uart_8250_port *port)
+{
+ if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
+ port->port.private_data =
+ __xr17v35x_register_gpio(pcidev);
+
+ return 0;
+}
+
+static const struct exar8250_platform exar8250_default_platform = {
+ .register_gpio = xr17v35x_register_gpio,
+};
+
static int
pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
struct uart_8250_port *port, int idx)
{
const struct exar8250_board *board = priv->board;
+ const struct exar8250_platform *platform;
unsigned int offset = idx * 0x400;
unsigned int baud = 7812500;
u8 __iomem *p;
int ret;

+ platform = &exar8250_default_platform;
+
port->port.uartclk = baud * 16;
+ port->port.rs485_config = platform->rs485_config;
+
/*
* Setup the uart clock for the devices on expansion slot to
* half the clock speed of the main chip (which is 125MHz)
@@ -248,12 +272,10 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
/* Setup Multipurpose Input/Output pins. */
setup_gpio(pcidev, p);

- if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
- port->port.private_data =
- xr17v35x_register_gpio(pcidev);
+ ret = platform->register_gpio(pcidev, port);
}

- return 0;
+ return ret;
}

static void pci_xr17v35x_exit(struct pci_dev *pcidev)
--
2.12.3

2017-06-09 18:33:37

[permalink] [raw]

Subject: [PATCH v6 04/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 <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
---
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.3

2017-06-09 18:33:53

[permalink] [raw]

Subject: [PATCH v6 01/10] gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards

Commtech adapters need the MPIOs for internal purposes, and the
gpio-exar driver already refused to pick them up. But there is actually
no point in even creating the underlying platform device.

Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
---
drivers/gpio/gpio-exar.c | 3 ---
drivers/tty/serial/8250/8250_exar.c | 4 +++-
2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 081076771217..006a9a67c2a4 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -124,9 +124,6 @@ static int gpio_exar_probe(struct platform_device *pdev)
void __iomem *p;
int index, ret;

- if (pcidev->vendor != PCI_VENDOR_ID_EXAR)
- return -ENODEV;
-
/*
* Map the pci device to get the register addresses.
* We will need to read and write those registers to control
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 8984e8b2d524..c29c7e675890 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -245,7 +245,9 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
/* Setup Multipurpose Input/Output pins. */
setup_gpio(pcidev, p);

- port->port.private_data = xr17v35x_register_gpio(pcidev);
+ if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
+ port->port.private_data =
+ xr17v35x_register_gpio(pcidev);
}

return 0;
--
2.12.3

2017-06-09 18:33:57

[permalink] [raw]

Subject: [PATCH v6 05/10] 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 <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
---
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 b29890b143ce..f3585a184f39 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)
@@ -78,7 +78,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
int val;

addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
- val = exar_get(chip, addr) >> (offset % 8);
+ val = exar_get(chip, addr) & BIT(offset % 8);

return !!val;
}
@@ -89,8 +89,8 @@ 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;
- val = exar_get(chip, addr) >> (offset % 8);
+ addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+ val = exar_get(chip, addr) & BIT(offset % 8);

return !!val;
}
--
2.12.3

2017-06-09 18:33:36

[permalink] [raw]

Subject: [PATCH v6 08/10] platform: Accept const properties

Aligns us with device_add_properties, the function we call.

Signed-off-by: Jan Kiszka <[email protected]>
---
drivers/base/platform.c | 2 +-
include/linux/platform_device.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index a102152301c8..71ea6f4d33c2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -344,7 +344,7 @@ EXPORT_SYMBOL_GPL(platform_device_add_data);
* platform device is released.
*/
int platform_device_add_properties(struct platform_device *pdev,
- struct property_entry *properties)
+ const struct property_entry *properties)
{
return device_add_properties(&pdev->dev, properties);
}
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 98c2a7c7108e..49f634d96118 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -172,7 +172,7 @@ extern int platform_device_add_resources(struct platform_device *pdev,
extern int platform_device_add_data(struct platform_device *pdev,
const void *data, size_t size);
extern int platform_device_add_properties(struct platform_device *pdev,
- struct property_entry *properties);
+ const struct property_entry *properties);
extern int platform_device_add(struct platform_device *pdev);
extern void platform_device_del(struct platform_device *pdev);
extern void platform_device_put(struct platform_device *pdev);
--
2.12.3

2017-06-09 18:33:35

[permalink] [raw]

Subject: [PATCH v6 10/10] serial: exar: Add support for IOT2040 device

This implements the setup of RS232 and the switch-over to RS485 or RS422
for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
to switch between the different modes. The external logic is controlled
via MPIO pins of the EXAR controller.

Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
an LED.

As the XR17V352 used on the IOT2040 is not equipped with an external
EEPROM, it cannot present itself as IOT2040-variant via subvendor/
subdevice IDs. Thus, we have to check via DMI for the target platform.

Co-developed with Sascha Weisenberger.

Signed-off-by: Sascha Weisenberger <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
drivers/tty/serial/8250/8250_exar.c | 129 +++++++++++++++++++++++++++++++++++-
1 file changed, 128 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 95c6e24ebff1..6dfa7b86501f 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -10,6 +10,7 @@
* the Free Software Foundation; either version 2 of the License.
*/
#include <linux/acpi.h>
+#include <linux/dmi.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -62,6 +63,43 @@
#define UART_EXAR_MPIOSEL_15_8 0x99 /* MPIOSEL[15:8] */
#define UART_EXAR_MPIOOD_15_8 0x9a /* MPIOOD[15:8] */

+#define UART_EXAR_RS485_DLY(x) ((x) << 4)
+
+/*
+ * IOT2040 MPIO wiring semantics:
+ *
+ * MPIO Port Function
+ * ---- ---- --------
+ * 0 2 Mode bit 0
+ * 1 2 Mode bit 1
+ * 2 2 Terminate bus
+ * 3 - <reserved>
+ * 4 3 Mode bit 0
+ * 5 3 Mode bit 1
+ * 6 3 Terminate bus
+ * 7 - <reserved>
+ * 8 2 Enable
+ * 9 3 Enable
+ * 10 - Red LED
+ * 11..15 - <unused>
+ */
+
+/* IOT2040 MPIOs 0..7 */
+#define IOT2040_UART_MODE_RS232 0x01
+#define IOT2040_UART_MODE_RS485 0x02
+#define IOT2040_UART_MODE_RS422 0x03
+#define IOT2040_UART_TERMINATE_BUS 0x04
+
+#define IOT2040_UART1_MASK 0x0f
+#define IOT2040_UART2_SHIFT 4
+
+#define IOT2040_UARTS_DEFAULT_MODE 0x11 /* both RS232 */
+#define IOT2040_UARTS_GPIO_LO_MODE 0x88 /* reserved pins as input */
+
+/* IOT2040 MPIOs 8..15 */
+#define IOT2040_UARTS_ENABLE 0x03
+#define IOT2040_UARTS_GPIO_HI_MODE 0xF8 /* enable & LED as outputs */
+
struct exar8250;

struct exar8250_platform {
@@ -243,18 +281,107 @@ static const struct exar8250_platform exar8250_default_platform = {
.register_gpio = xr17v35x_register_gpio,
};

+static int iot2040_rs485_config(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+ bool is_rs485 = !!(rs485->flags & SER_RS485_ENABLED);
+ u8 __iomem *p = port->membase;
+ u8 mask = IOT2040_UART1_MASK;
+ u8 mode, value;
+
+ if (is_rs485) {
+ if (rs485->flags & SER_RS485_RX_DURING_TX)
+ mode = IOT2040_UART_MODE_RS422;
+ else
+ mode = IOT2040_UART_MODE_RS485;
+
+ if (rs485->flags & SER_RS485_TERMINATE_BUS)
+ mode |= IOT2040_UART_TERMINATE_BUS;
+ } else {
+ mode = IOT2040_UART_MODE_RS232;
+ }
+
+ if (port->line == 3) {
+ mask <<= IOT2040_UART2_SHIFT;
+ mode <<= IOT2040_UART2_SHIFT;
+ }
+
+ value = readb(p + UART_EXAR_MPIOLVL_7_0);
+ value &= ~mask;
+ value |= mode;
+ writeb(value, p + UART_EXAR_MPIOLVL_7_0);
+
+ value = readb(p + UART_EXAR_FCTR);
+ if (is_rs485)
+ value |= UART_FCTR_EXAR_485;
+ else
+ value &= ~UART_FCTR_EXAR_485;
+ writeb(value, p + UART_EXAR_FCTR);
+
+ if (is_rs485)
+ writeb(UART_EXAR_RS485_DLY(4), p + UART_MSR);
+
+ port->rs485 = *rs485;
+
+ return 0;
+}
+
+static const struct property_entry iot2040_gpio_properties[] = {
+ PROPERTY_ENTRY_U32("linux,first-pin", 10),
+ PROPERTY_ENTRY_U32("ngpios", 1),
+ { }
+};
+
+static int iot2040_register_gpio(struct pci_dev *pcidev,
+ struct uart_8250_port *port)
+{
+ u8 __iomem *p = port->port.membase;
+
+ writeb(IOT2040_UARTS_DEFAULT_MODE, p + UART_EXAR_MPIOLVL_7_0);
+ writeb(IOT2040_UARTS_GPIO_LO_MODE, p + UART_EXAR_MPIOSEL_7_0);
+ writeb(IOT2040_UARTS_ENABLE, p + UART_EXAR_MPIOLVL_15_8);
+ writeb(IOT2040_UARTS_GPIO_HI_MODE, p + UART_EXAR_MPIOSEL_15_8);
+
+ port->port.private_data =
+ __xr17v35x_register_gpio(pcidev, iot2040_gpio_properties);
+
+ return 0;
+}
+
+static const struct exar8250_platform iot2040_platform = {
+ .rs485_config = iot2040_rs485_config,
+ .register_gpio = iot2040_register_gpio,
+};
+
+static const struct dmi_system_id exar_platforms[] = {
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+ DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+ "6ES7647-0AA00-1YA2"),
+ },
+ .driver_data = (void *)&iot2040_platform,
+ },
+ {}
+};
+
static int
pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
struct uart_8250_port *port, int idx)
{
const struct exar8250_board *board = priv->board;
const struct exar8250_platform *platform;
+ const struct dmi_system_id *dmi_match;
unsigned int offset = idx * 0x400;
unsigned int baud = 7812500;
u8 __iomem *p;
int ret;

- platform = &exar8250_default_platform;
+ dmi_match = dmi_first_match(exar_platforms);
+ if (dmi_match)
+ platform = dmi_match->driver_data;
+ else
+ platform = &exar8250_default_platform;

port->port.uartclk = baud * 16;
port->port.rs485_config = platform->rs485_config;
--
2.12.3

2017-06-09 18:35:00

[permalink] [raw]

Subject: [PATCH v6 02/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 <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
---
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.3

2017-06-09 18:35:21

[permalink] [raw]

Subject: [PATCH v6 09/10] 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,
expand the platform device data structure to specify a (consecutive) pin
subset for exporting by the gpio-exar driver.

Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
drivers/gpio/gpio-exar.c | 56 ++++++++++++++++++++++---------------
drivers/tty/serial/8250/8250_exar.c | 15 ++++++++--
2 files changed, 45 insertions(+), 26 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 1a629831d45b..fb8d304cfa17 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_pin;
};

static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
@@ -51,11 +52,12 @@ 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 addr = (offset + exar_gpio->first_pin) / 8 ?
+ EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
+ unsigned int bit = (offset + exar_gpio->first_pin) % 8;

- addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
- exar_update(chip, addr, direction, offset % 8);
+ exar_update(chip, addr, direction, bit);
return 0;
}

@@ -73,36 +75,33 @@ 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;
- int val;
-
- addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
- val = exar_get(chip, addr) & BIT(offset % 8);
+ struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+ unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+ EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
+ unsigned int bit = (offset + exar_gpio->first_pin) % 8;

- return !!val;
+ return !!(exar_get(chip, addr) & BIT(bit));
}

static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
{
- unsigned int bank = offset / 8;
- unsigned int addr;
- int val;
-
- addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
- val = exar_get(chip, addr) & BIT(offset % 8);
+ struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+ unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+ EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+ unsigned int bit = (offset + exar_gpio->first_pin) % 8;

- return !!val;
+ return !!(exar_get(chip, addr) & BIT(bit));
}

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 addr = (offset + exar_gpio->first_pin) / 8 ?
+ EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+ unsigned int bit = (offset + exar_gpio->first_pin) % 8;

- addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
- exar_update(chip, addr, value, offset % 8);
+ exar_update(chip, addr, value, bit);
}

static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
@@ -121,6 +120,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
{
struct pci_dev *pcidev = to_pci_dev(pdev->dev.parent);
struct exar_gpio_chip *exar_gpio;
+ u32 first_pin, ngpios;
void __iomem *p;
int index, ret;

@@ -132,6 +132,15 @@ static int gpio_exar_probe(struct platform_device *pdev)
if (!p)
return -ENOMEM;

+ ret = device_property_read_u32(&pdev->dev, "linux,first-pin",
+ &first_pin);
+ if (ret)
+ return ret;
+
+ ret = device_property_read_u32(&pdev->dev, "ngpios", &ngpios);
+ if (ret)
+ return ret;
+
exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL);
if (!exar_gpio)
return -ENOMEM;
@@ -149,9 +158,10 @@ 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;
+ exar_gpio->gpio_chip.ngpio = ngpios;
exar_gpio->regs = p;
exar_gpio->index = index;
+ exar_gpio->first_pin = first_pin;

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 1106f1f58c77..95c6e24ebff1 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -14,6 +14,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pci.h>
+#include <linux/property.h>
#include <linux/serial_core.h>
#include <linux/serial_reg.h>
#include <linux/slab.h>
@@ -201,7 +202,8 @@ static void setup_gpio(struct pci_dev *pcidev, u8 __iomem *p)
}

static void *
-__xr17v35x_register_gpio(struct pci_dev *pcidev)
+__xr17v35x_register_gpio(struct pci_dev *pcidev,
+ const struct property_entry *properties)
{
struct platform_device *pdev;

@@ -212,7 +214,8 @@ __xr17v35x_register_gpio(struct pci_dev *pcidev)
pdev->dev.parent = &pcidev->dev;
ACPI_COMPANION_SET(&pdev->dev, ACPI_COMPANION(&pcidev->dev));

- if (platform_device_add(pdev) < 0) {
+ if (platform_device_add_properties(pdev, properties) < 0 ||
+ platform_device_add(pdev) < 0) {
platform_device_put(pdev);
return NULL;
}
@@ -220,12 +223,18 @@ __xr17v35x_register_gpio(struct pci_dev *pcidev)
return pdev;
}

+static const struct property_entry exar_gpio_properties[] = {
+ PROPERTY_ENTRY_U32("linux,first-pin", 0),
+ PROPERTY_ENTRY_U32("ngpios", 16),
+ { }
+};
+
static int xr17v35x_register_gpio(struct pci_dev *pcidev,
struct uart_8250_port *port)
{
if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
port->port.private_data =
- __xr17v35x_register_gpio(pcidev);
+ __xr17v35x_register_gpio(pcidev, exar_gpio_properties);

return 0;
}
--
2.12.3

2017-06-20 08:13:42

[permalink] [raw]

Subject: Re: [PATCH v6 02/10] gpio-exar/8250-exar: Fix passing in of parent PCI device

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>
> Acked-by: Linus Walleij <[email protected]>
> Acked-by: Greg Kroah-Hartman <[email protected]>

Patch applied to the GPIO tree so we advance this series.

Patch 1 does not apply.

Let's see how it goes.

Yours,
Linus Walleij

2017-06-20 08:14:31

[permalink] [raw]

Subject: Re: [PATCH v6 03/10] gpio: exar: Allocate resources on behalf of the platform device

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>
> Acked-by: Linus Walleij <[email protected]>

Patch applied.

Yours,
Linus Walleij

2017-06-20 08:15:57

[permalink] [raw]

Subject: Re: [PATCH v6 04/10] gpio: exar: Fix iomap request

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>
> Acked-by: Linus Walleij <[email protected]>

This patch does not apply to the GPIO tree.

I don't know why.

Yours,
Linus Walleij

2017-06-20 08:16:50

[permalink] [raw]

Subject: Re: [PATCH v6 05/10] gpio: exar: Fix reading of directions and values

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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.
>
> Signed-off-by: Jan Kiszka <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>
> Acked-by: Linus Walleij <[email protected]>

Patch applied.

Yours,
Linus Walleij

2017-06-20 08:19:33

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 v6:

I merged some of the patches, that applied. Let's see if they survive
in linux-next, else I guess we need to fix this in the -rcs or for the next
kernel cycle.

Yours,
Linus Walleij

2017-06-20 08:55:08

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On 2017-06-20 10:19, Linus Walleij wrote:
> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 v6:
>
> I merged some of the patches, that applied. Let's see if they survive
> in linux-next, else I guess we need to fix this in the -rcs or for the next
> kernel cycle.

Weird that things did not apply. I just did a cherry-pick for all those
10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
know which baseline is needed, and I will rebase.

Thanks,
Jan

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

2017-06-20 11:38:32

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <[email protected]> wrote:
> On 2017-06-20 10:19, Linus Walleij wrote:
>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 v6:
>>
>> I merged some of the patches, that applied. Let's see if they survive
>> in linux-next, else I guess we need to fix this in the -rcs or for the next
>> kernel cycle.
>
> Weird that things did not apply. I just did a cherry-pick for all those
> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
> know which baseline is needed, and I will rebase.

This was on the "devel" branch of my GPIO tree:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel

Yours,
Linus Walleij

2017-06-21 06:30:12

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On 2017-06-20 13:38, Linus Walleij wrote:
> On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <[email protected]> wrote:
>> On 2017-06-20 10:19, Linus Walleij wrote:
>>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 v6:
>>>
>>> I merged some of the patches, that applied. Let's see if they survive
>>> in linux-next, else I guess we need to fix this in the -rcs or for the next
>>> kernel cycle.
>>
>> Weird that things did not apply. I just did a cherry-pick for all those
>> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
>> know which baseline is needed, and I will rebase.
>
> This was on the "devel" branch of my GPIO tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel

Again, all (missing) patches applied absolutely cleanly for me, see

http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000

Jan

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

2017-06-23 20:09:28

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On 2017-06-21 08:29, Jan Kiszka wrote:
> On 2017-06-20 13:38, Linus Walleij wrote:
>> On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <[email protected]> wrote:
>>> On 2017-06-20 10:19, Linus Walleij wrote:
>>>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 v6:
>>>>
>>>> I merged some of the patches, that applied. Let's see if they survive
>>>> in linux-next, else I guess we need to fix this in the -rcs or for the next
>>>> kernel cycle.
>>>
>>> Weird that things did not apply. I just did a cherry-pick for all those
>>> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
>>> know which baseline is needed, and I will rebase.
>>
>> This was on the "devel" branch of my GPIO tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
>
> Again, all (missing) patches applied absolutely cleanly for me, see
>
> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000

I've rebased over devel and noticed along this that you will have to
include "serial: uapi: Add support for bus termination" from Greg's
tty-next for the last patch to avoid breaking the build. Result pushed to

http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000

If you want me to resend anything, just let me know. Would be great to
have the remaining pieces lined up in time for the next merge window.

Thanks,
Jan

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

2017-06-29 09:51:20

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka <[email protected]> wrote:
> On 2017-06-21 08:29, Jan Kiszka wrote:
>> On 2017-06-20 13:38, Linus Walleij wrote:
>>> On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <[email protected]> wrote:
>>>> On 2017-06-20 10:19, Linus Walleij wrote:
>>>>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 v6:
>>>>>
>>>>> I merged some of the patches, that applied. Let's see if they survive
>>>>> in linux-next, else I guess we need to fix this in the -rcs or for the next
>>>>> kernel cycle.
>>>>
>>>> Weird that things did not apply. I just did a cherry-pick for all those
>>>> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
>>>> know which baseline is needed, and I will rebase.
>>>
>>> This was on the "devel" branch of my GPIO tree:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
>>
>> Again, all (missing) patches applied absolutely cleanly for me, see
>>
>> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>
> I've rebased over devel and noticed along this that you will have to
> include "serial: uapi: Add support for bus termination" from Greg's
> tty-next for the last patch to avoid breaking the build. Result pushed to
>
> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>
> If you want me to resend anything, just let me know. Would be great to
> have the remaining pieces lined up in time for the next merge window.

I could just pull it in, but then I want a clear indication that Greg and
say Andy are happy with this.

The serial patches are missing Gregs explicit ACK and the platform
patch could use Andy's ACK. The last patch adding the
IOT2040 is so obviously out of my GPIO territory that I want
Greg 100% aligned with this.

I am sorry that it is troublesome when things cross subsystem
boundaries, I already stretched it a bit with the things I queued
up because it annoys me too, but this is the process we have :/

Yours,
Linus Walleij

2017-06-29 11:43:48

by Andy Shevchenko

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Thu, Jun 29, 2017 at 12:51 PM, Linus Walleij
<[email protected]> wrote:
> On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka <[email protected]> wrote:
>> On 2017-06-21 08:29, Jan Kiszka wrote:

>> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>>
>> If you want me to resend anything, just let me know. Would be great to
>> have the remaining pieces lined up in time for the next merge window.
>
> I could just pull it in, but then I want a clear indication that Greg and
> say Andy are happy with this.

All patches that have my tag already are good from my point of view.
The rest, i.e.
"platform: Accept const properties", needs a slightly more attention.

This one on one hand does the right thing, though I would like to hear
Mika on this.

We still have platform_device_info and mfd_cell that doesn't define
the properties with const.
(I believe they should, though is it matter of this patch?)

P.S. I have looked at the current state of the use of the API in
question and rather agree with the patch, thus

Reviewed-by: Andy Shevchenko <[email protected]>

--
With Best Regards,
Andy Shevchenko

2017-06-29 14:48:28

[permalink] [raw]

Subject: Re: [PATCH v6 07/10] serial: exar: Factor out platform hooks

On Fri, Jun 09, 2017 at 08:33:15PM +0200, Jan Kiszka wrote:
> This prepares the addition of IOT2040 platform support by preparing the
> needed setup and rs485_config hooks.
>
> Signed-off-by: Jan Kiszka <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>

Acked-by: Greg Kroah-Hartman <[email protected]>

2017-06-29 14:49:04

[permalink] [raw]

Subject: Re: [PATCH v6 01/10] gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards

On Fri, Jun 09, 2017 at 08:33:09PM +0200, Jan Kiszka wrote:
> Commtech adapters need the MPIOs for internal purposes, and the
> gpio-exar driver already refused to pick them up. But there is actually
> no point in even creating the underlying platform device.
>
> Signed-off-by: Jan Kiszka <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>
> Acked-by: Linus Walleij <[email protected]>

Acked-by: Greg Kroah-Hartman <[email protected]>

2017-06-29 14:49:38

[permalink] [raw]

Subject: Re: [PATCH v6 10/10] serial: exar: Add support for IOT2040 device

On Fri, Jun 09, 2017 at 08:33:18PM +0200, Jan Kiszka wrote:
> This implements the setup of RS232 and the switch-over to RS485 or RS422
> for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
> to switch between the different modes. The external logic is controlled
> via MPIO pins of the EXAR controller.
>
> Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
> an LED.
>
> As the XR17V352 used on the IOT2040 is not equipped with an external
> EEPROM, it cannot present itself as IOT2040-variant via subvendor/
> subdevice IDs. Thus, we have to check via DMI for the target platform.
>
> Co-developed with Sascha Weisenberger.
>
> Signed-off-by: Sascha Weisenberger <[email protected]>
> Signed-off-by: Jan Kiszka <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>

Acked-by: Greg Kroah-Hartman <[email protected]>

2017-06-29 14:50:00

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Thu, Jun 29, 2017 at 11:51:08AM +0200, Linus Walleij wrote:
> On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka <[email protected]> wrote:
> > On 2017-06-21 08:29, Jan Kiszka wrote:
> >> On 2017-06-20 13:38, Linus Walleij wrote:
> >>> On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <[email protected]> wrote:
> >>>> On 2017-06-20 10:19, Linus Walleij wrote:
> >>>>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 v6:
> >>>>>
> >>>>> I merged some of the patches, that applied. Let's see if they survive
> >>>>> in linux-next, else I guess we need to fix this in the -rcs or for the next
> >>>>> kernel cycle.
> >>>>
> >>>> Weird that things did not apply. I just did a cherry-pick for all those
> >>>> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
> >>>> know which baseline is needed, and I will rebase.
> >>>
> >>> This was on the "devel" branch of my GPIO tree:
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
> >>
> >> Again, all (missing) patches applied absolutely cleanly for me, see
> >>
> >> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
> >
> > I've rebased over devel and noticed along this that you will have to
> > include "serial: uapi: Add support for bus termination" from Greg's
> > tty-next for the last patch to avoid breaking the build. Result pushed to
> >
> > http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
> >
> > If you want me to resend anything, just let me know. Would be great to
> > have the remaining pieces lined up in time for the next merge window.
>
> I could just pull it in, but then I want a clear indication that Greg and
> say Andy are happy with this.
>
> The serial patches are missing Gregs explicit ACK and the platform
> patch could use Andy's ACK. The last patch adding the
> IOT2040 is so obviously out of my GPIO territory that I want
> Greg 100% aligned with this.
>
> I am sorry that it is troublesome when things cross subsystem
> boundaries, I already stretched it a bit with the things I queued
> up because it annoys me too, but this is the process we have :/

I've added my acks to the serial patches, so all should be fine for you
to take this all through your tree now.

thanks,

greg k-h

2017-06-29 22:13:20

[permalink] [raw]

Subject: Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Thu, Jun 29, 2017 at 4:49 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Thu, Jun 29, 2017 at 11:51:08AM +0200, Linus Walleij wrote:
>> On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka <[email protected]> wrote:
>> > On 2017-06-21 08:29, Jan Kiszka wrote:
>> >> On 2017-06-20 13:38, Linus Walleij wrote:
>> >>> On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <[email protected]> wrote:
>> >>>> On 2017-06-20 10:19, Linus Walleij wrote:
>> >>>>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <[email protected]> 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 v6:
>> >>>>>
>> >>>>> I merged some of the patches, that applied. Let's see if they survive
>> >>>>> in linux-next, else I guess we need to fix this in the -rcs or for the next
>> >>>>> kernel cycle.
>> >>>>
>> >>>> Weird that things did not apply. I just did a cherry-pick for all those
>> >>>> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
>> >>>> know which baseline is needed, and I will rebase.
>> >>>
>> >>> This was on the "devel" branch of my GPIO tree:
>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
>> >>
>> >> Again, all (missing) patches applied absolutely cleanly for me, see
>> >>
>> >> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>> >
>> > I've rebased over devel and noticed along this that you will have to
>> > include "serial: uapi: Add support for bus termination" from Greg's
>> > tty-next for the last patch to avoid breaking the build. Result pushed to
>> >
>> > http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>> >
>> > If you want me to resend anything, just let me know. Would be great to
>> > have the remaining pieces lined up in time for the next merge window.
>>
>> I could just pull it in, but then I want a clear indication that Greg and
>> say Andy are happy with this.
>>
>> The serial patches are missing Gregs explicit ACK and the platform
>> patch could use Andy's ACK. The last patch adding the
>> IOT2040 is so obviously out of my GPIO territory that I want
>> Greg 100% aligned with this.
>>
>> I am sorry that it is troublesome when things cross subsystem
>> boundaries, I already stretched it a bit with the things I queued
>> up because it annoys me too, but this is the process we have :/
>
> I've added my acks to the serial patches, so all should be fine for you
> to take this all through your tree now.

Awesome, Jan can you:

- Collect the ACKs

- Send me a pull request based on my devel branch?

Yours,
Linus Walleij

2017-07-03 07:21:45

[permalink] [raw]

Subject: [PULL] serial/gpio: exar: Fixes and support for IOT2000

The following changes since commit 85bb4646f8908eb786dfa19a6bb2ff1423dc8aa4:

gpio: rcar: Add R8A7743 (RZ/G1M) support (2017-06-29 14:22:38 +0200)

are available in the git repository at:

git://git.kiszka.org/linux.git queues/gpio-iot2000

for you to fetch changes up to 413058df4331ce29f9934a5870d582c7e71fe15f:

serial: exar: Add support for IOT2040 device (2017-07-03 08:33:20 +0200)

This corresponds to v6 of the series with additional review and ack
tags.

----------------------------------------------------------------
Jan Kiszka (8):
serial: uapi: Add support for bus termination
gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards
gpio: exar: Fix iomap request
gpio-exar/8250-exar: Rearrange gpiochip parenthood
serial: exar: Factor out platform hooks
platform: Accept const properties
gpio-exar/8250-exar: Make set of exported GPIOs configurable
serial: exar: Add support for IOT2040 device

drivers/base/platform.c | 2 +-
drivers/gpio/gpio-exar.c | 71 +++++++--------
drivers/tty/serial/8250/8250_exar.c | 170 +++++++++++++++++++++++++++++++++++-
include/linux/platform_device.h | 2 +-
include/uapi/linux/serial.h | 3 +
5 files changed, 208 insertions(+), 40 deletions(-)

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

2017-07-03 08:10:38