* [PATCH v3 08/10] gpio: exar: Refactor address and bit calculations
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1495814557.git.jan.kiszka@siemens.com>
Make the address and bit calculation more friendly for introducing a
"first pin" offset later on. The new form is also more compact and
regular.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/gpio/gpio-exar.c | 38 ++++++++++++++++----------------------
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 1a629831d45b..d13bf20b8639 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -51,11 +51,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;
+ unsigned int addr = offset / 8 ?
+ EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
+ unsigned int bit = offset % 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 +73,30 @@ 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;
+ unsigned int addr = offset / 8 ?
+ EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
+ unsigned int bit = offset % 8;
- addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
- val = exar_get(chip, addr) & BIT(offset % 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);
+ unsigned int addr = offset / 8 ?
+ EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+ unsigned int bit = offset % 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;
+ unsigned int addr = offset / 8 ?
+ EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+ unsigned int bit = offset % 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,
--
2.12.0
^ permalink raw reply related
* [PATCH v3 07/10] gpio-exar/8250-exar: Rearrange gpiochip parenthood
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1495814557.git.jan.kiszka@siemens.com>
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 <jan.kiszka@siemens.com>
---
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.0
^ permalink raw reply related
* [PATCH v3 06/10] gpio: exar: Fix reading of directions and values
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1495814557.git.jan.kiszka@siemens.com>
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>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.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 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.0
^ permalink raw reply related
* [PATCH v3 05/10] gpio: exar: Fix iomap request
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1495814557.git.jan.kiszka@siemens.com>
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
^ permalink raw reply related
* [PATCH v3 04/10] gpio: exar: Allocate resources on behalf of the platform device
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1495814557.git.jan.kiszka@siemens.com>
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
^ permalink raw reply related
* [PATCH v3 03/10] gpio-exar/8250-exar: Fix passing in of parent PCI device
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1495814557.git.jan.kiszka@siemens.com>
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
^ permalink raw reply related
* [PATCH v3 02/10] gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1495814557.git.jan.kiszka@siemens.com>
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 <jan.kiszka@siemens.com>
---
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.0
^ permalink raw reply related
* [PATCH v3 01/10] serial: exar: Leave MPIOs as output for Commtech adapters
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1495814557.git.jan.kiszka@siemens.com>
Commtech adapters apparently need the original setting as outputs, see
https://marc.info/?l=linux-gpio&m=149557425201323&w=2. Account for that.
Fixes: 7dea8165f1d6 ("serial: exar: Preconfigure xr17v35x MPIOs as output")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/tty/serial/8250/8250_exar.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index b4fa585156c7..8984e8b2d524 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -171,19 +171,26 @@ pci_xr17c154_setup(struct exar8250 *priv, struct pci_dev *pcidev,
return default_setup(priv, pcidev, idx, offset, port);
}
-static void setup_gpio(u8 __iomem *p)
+static void setup_gpio(struct pci_dev *pcidev, u8 __iomem *p)
{
+ /*
+ * The Commtech adapters required the MPIOs to be driven low. The Exar
+ * devices will export them as GPIOs, so we pre-configure them safely
+ * as inputs.
+ */
+ u8 dir = pcidev->vendor == PCI_VENDOR_ID_EXAR ? 0xff : 0x00;
+
writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
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(0xff, p + UART_EXAR_MPIOSEL_7_0);
+ writeb(dir, 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(0xff, p + UART_EXAR_MPIOSEL_15_8);
+ writeb(dir, p + UART_EXAR_MPIOSEL_15_8);
writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
}
@@ -236,7 +243,7 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
if (idx == 0) {
/* Setup Multipurpose Input/Output pins. */
- setup_gpio(p);
+ setup_gpio(pcidev, p);
port->port.private_data = xr17v35x_register_gpio(pcidev);
}
--
2.12.0
^ permalink raw reply related
* [PATCH v3 00/10] serial/gpio: exar: Fixes and support for IOT2000
From: Jan Kiszka @ 2017-05-26 16:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot
Cc: Linux Kernel Mailing List, linux-serial, linux-gpio,
Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
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
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile
From: YT Shen @ 2017-05-26 14:33 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Jason Cooper, srv_heupstream,
Marc Zyngier, Greg Kroah-Hartman, Will Deacon, linux-kernel,
Mars Cheng, linux-serial, Catalin Marinas, Matthias Brugger,
linux-mediatek, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20170523150137.ouyloy46ahuhsenu@rob-hp-laptop>
On Tue, 2017-05-23 at 10:01 -0500, Rob Herring wrote:
> On Fri, May 19, 2017 at 07:09:46PM +0800, YT Shen wrote:
> > This adds basic chip support for Mediatek 2712
> >
> > Signed-off-by: YT Shen <yt.shen@mediatek.com>
> > ---
> > arch/arm64/boot/dts/mediatek/Makefile | 1 +
> > arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 44 +++++++
> > arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 172 ++++++++++++++++++++++++++++
> > 3 files changed, 217 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > index 9fbfd32..fcc0604 100644
> > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > @@ -1,3 +1,4 @@
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
> > dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
> > dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
> > dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> > diff --git a/arch/arm64/boot/dts/mediatek/mt2712-evb.dts b/arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> > new file mode 100644
> > index 0000000..40b0c91
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> > @@ -0,0 +1,44 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: YT Shen <yt.shen@mediatek.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
>
> You may want to dual license this. Not sure what the rest of Mediatek
> dts files do though. Also, you can use SPDX tag here if you want.
Okay, will change to SPDX tag and dual license in the next version.
SPDX-License-Identifier: (GPL-2.0 OR MIT)
>
> > +
> > +/dts-v1/;
> > +#include "mt2712e.dtsi"
> > +
> > +/ {
> > + model = "MediaTek MT2712 evaluation board";
> > + compatible = "mediatek,mt2712-evb", "mediatek,mt2712";
> > +
> > + aliases {
> > + serial0 = &uart0;
> > + serial1 = &uart1;
> > + serial2 = &uart2;
> > + serial3 = &uart3;
> > + serial4 = &uart4;
> > + serial5 = &uart5;
> > + };
> > +
> > + memory@40000000 {
> > + device_type = "memory";
> > + reg = <0 0x40000000 0 0x80000000>;
> > + };
> > +
> > + chosen {
> > + bootargs = "console=ttyS0,921600n1 initrd=0x45000000,90M";
>
> Both of these have a way to be expressed in DT. For the initrd, the
> bootloader should be setting the address and size anyway.
OK, will change to DT usage.
stdout-path = "serial0:921600n8";
linux,initrd-start = <...>;
linux,initrd-end = <...>;
>
> > + };
> > +};
> > +
> > +&uart0 {
> > + status = "okay";
> > +};
> > +
> > diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> > new file mode 100644
> > index 0000000..40747a9
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> > @@ -0,0 +1,172 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: YT Shen <yt.shen@mediatek.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > + compatible = "mediatek,mt2712";
> > + interrupt-parent = <&sysirq>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu-map {
> > + cluster0 {
> > + core0 {
> > + cpu = <&cpu0>;
> > + };
> > + core1 {
> > + cpu = <&cpu1>;
> > + };
> > + };
> > +
> > + cluster1 {
> > + core0 {
> > + cpu = <&cpu2>;
> > + };
> > + };
> > + };
> > +
> > + cpu0: cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a35";
> > + reg = <0x000>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a35";
> > + reg = <0x001>;
> > + enable-method = "psci";
> > + };
> > +
> > + cpu2: cpu@200 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x200>;
> > + enable-method = "psci";
> > + };
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + uart_clk: dummy26m {
> > + compatible = "fixed-clock";
> > + clock-frequency = <26000000>;
> > + #clock-cells = <0>;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupt-parent = <&gic>;
> > + interrupts = <GIC_PPI 13
> > + (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 14
> > + (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 11
> > + (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 10
> > + (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
> > + };
> > +
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + compatible = "simple-bus";
> > + ranges;
> > +
> > + uart5: serial@1000f000 {
> > + compatible = "mediatek,mt2712-uart",
> > + "mediatek,mt6577-uart";
> > + reg = <0 0x1000f000 0 0x400>;
> > + interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&uart_clk>;
> > + status = "disabled";
> > + };
> > +
> > + sysirq: intpol-controller@10220a80 {
>
> interrupt-controller@...
Will check this part, thanks for the review.
yt.shen
>
> > + compatible = "mediatek,mt2712-sysirq",
> > + "mediatek,mt6577-sysirq";
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > + interrupt-parent = <&gic>;
> > + reg = <0 0x10220a80 0 0x40>;
> > + };
> > +
> > + gic: interrupt-controller@10510000 {
> > + compatible = "arm,gic-400";
> > + #interrupt-cells = <3>;
> > + interrupt-parent = <&gic>;
> > + interrupt-controller;
> > + reg = <0 0x10510000 0 0x1000>,
> > + <0 0x10520000 0 0x1000>,
> > + <0 0x10540000 0 0x2000>,
> > + <0 0x10560000 0 0x2000>;
> > + interrupts = <GIC_PPI 9
> > + (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
> > + };
> > +
> > + uart0: serial@11002000 {
> > + compatible = "mediatek,mt2712-uart",
> > + "mediatek,mt6577-uart";
> > + reg = <0 0x11002000 0 0x400>;
> > + interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&uart_clk>;
> > + status = "disabled";
> > + };
> > +
> > + uart1: serial@11003000 {
> > + compatible = "mediatek,mt2712-uart",
> > + "mediatek,mt6577-uart";
> > + reg = <0 0x11003000 0 0x400>;
> > + interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&uart_clk>;
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@11004000 {
> > + compatible = "mediatek,mt2712-uart",
> > + "mediatek,mt6577-uart";
> > + reg = <0 0x11004000 0 0x400>;
> > + interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&uart_clk>;
> > + status = "disabled";
> > + };
> > +
> > + uart3: serial@11005000 {
> > + compatible = "mediatek,mt2712-uart",
> > + "mediatek,mt6577-uart";
> > + reg = <0 0x11005000 0 0x400>;
> > + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&uart_clk>;
> > + status = "disabled";
> > + };
> > +
> > + uart4: serial@11019000 {
> > + compatible = "mediatek,mt2712-uart",
> > + "mediatek,mt6577-uart";
> > + reg = <0 0x11019000 0 0x400>;
> > + interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&uart_clk>;
> > + status = "disabled";
> > + };
> > + };
> > +};
> > +
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/8] serial: exar: Preconfigure xr17v35x MPIOs as output
From: Andy Shevchenko @ 2017-05-26 14:22 UTC (permalink / raw)
To: Jan Kiszka
Cc: Greg Kroah-Hartman, Linus Walleij, Alexandre Courbot,
Linux Kernel Mailing List, linux-serial@vger.kernel.org,
linux-gpio@vger.kernel.org, Sudip Mukherjee, Sascha Weisenberger
In-Reply-To: <9bb8d972-6535-1611-8fa7-f5fe89760531@siemens.com>
On Fri, May 26, 2017 at 4:04 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Greg,
> Please drop from this tty-next, it may break Commtech adapters. I have
> an update ready.
>
> I may also send a fix on top if that is preferred, just let me know.
AFAIK what is in tty-next is left there, so, looks like latter is the option.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/8] serial: exar: Preconfigure xr17v35x MPIOs as output
From: Jan Kiszka @ 2017-05-26 13:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linus Walleij, Alexandre Courbot, Linux Kernel Mailing List,
linux-serial, linux-gpio, Sudip Mukherjee, Andy Shevchenko,
Sascha Weisenberger
In-Reply-To: <6155891d19531be018d30fd55ffd6d42493af8c1.1494660546.git.jan.kiszka@siemens.com>
Greg,
On 2017-05-13 09:28, Jan Kiszka wrote:
> 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);
> }
>
>
Please drop from this tty-next, it may break Commtech adapters. I have
an update ready.
I may also send a fix on top if that is preferred, just let me know.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH] serial: uartps: Fix kernel doc warnings
From: Michal Simek @ 2017-05-26 11:13 UTC (permalink / raw)
To: linux-kernel, monstr
Cc: Nava kishore Manne, Jiri Slaby, Sören Brinkmann,
linux-serial, Greg Kroah-Hartman, linux-arm-kernel
From: Nava kishore Manne <nava.manne@xilinx.com>
This patch fixes the kernel doc warnings in the driver.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/tty/serial/xilinx_uartps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index d82133d0f79a..81d1d553a5db 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -186,6 +186,7 @@
* @pclk: APB clock
* @baud: Current baud rate
* @clk_rate_change_nb: Notifier block for clock changes
+ * @quirks: Flags for RXBS support.
*/
struct cdns_uart {
struct uart_port *port;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v9 3/3] printk: fix double printing with earlycon
From: Aleksey Makarov @ 2017-05-26 9:37 UTC (permalink / raw)
To: Petr Mladek, Aleksey Makarov
Cc: Sergey Senozhatsky, Sabrina Dubroca, linux-serial, linux-kernel,
Sudeep Holla, Greg Kroah-Hartman, Peter Hurley, Jiri Slaby,
Robin Murphy, Steven Rostedt, Nair, Jayachandran,
Sergey Senozhatsky
In-Reply-To: <20170518154918.GE8621@pathway.suse.cz>
On 05/18/2017 06:49 PM, Petr Mladek wrote:
> On Sun 2017-05-14 23:37:50, Aleksey Makarov wrote:
>>
>>
>> On 05/12/2017 03:57 PM, Petr Mladek wrote:
>>> On Thu 2017-05-11 17:41:58, Sergey Senozhatsky wrote:
>>>> On (05/11/17 17:24), Sergey Senozhatsky wrote:
>>>>> On (05/09/17 10:29), Sabrina Dubroca wrote: [..]
>>>>>> That's caused a change of behavior in my qemu setup, with
>>>>>> this cmdline
>>>>>>
>>>>>> root=/dev/sda1 console=ttyS1 console=ttyS0
>>>>>>
>>>>>> Before, the kernel logs appeared on ttyS1, and I logged in
>>>>>> with ttyS0 (with my setup, ttyS1 is a file and ttyS0 is
>>>>>> unix socket). Now, the kernel logs go to ttyS0. I need to
>>>>>> swap the two console= parameters to restore behavior.
>>>>>>
>>>>>> There might be some other problem (in qemu?) though,
>>>>>> because adding console=tty0 anywhere on that cmdline makes
>>>>>> the logs appear on both tty0 and one ttyS* (but only one of
>>>>>> them, and the ordering of the ttyS* matters).
>>>>>
>>
>> The problem is that when we are registering a new console, we walk
>> over the `console_cmdline` list and match _only one_ of the
>> specified consoles, contrary to what stated in
>> Documentation/admin-guide/serial-console.rst:
>>
>> You can specify multiple console= options on the kernel command
>> line. Output will appear on *all* of them.
>
> and from the other mail:
>
>> Last mentioned 'console=' (preferred console) is the console that
>> should become /dev/console. Its driver is returned by
>> console_device(). In other respects the last mentioned console is
>> not special, so I believe it is irrelevant to the report.
>
> Thanks a lot for explanation. I missed these pieces.
>
> But this also means that your commit cf39bf58afdaabc0b ("printk: fix
> double printing with earlycon") helps only when the duplicate of the
> boot console is defined as the preferred one.
>
> Well, the reverse order of searching the console_cmdline might help
> also in other cases but it is weird approach.
>
>
>> I emphasized all here. Moreover, it is impossible to fix this
>> without deep reworking of all the console framework.
>
> IMHO, the same is true also for fixing the bug with double printing
> correctly. The current fix helps in some situations but it might
> break others. The question is how many people will see the good and
> "bad" effects.
I meant that it is difficult to fix the bug that only one line
(first matched) of registered console device receives kernel logs.
That is because of 'index' field of struct console can refer to only one
tty line.
I re-evaluated the "printk: fix double printing with earlycon"
patch and still think it is ok as it breaks only situations
that should not happen, when different lines of the same
console are registered in console_cmdline. But I agree that
someone else with more experience should decide.
- The reason why logs appear twice is that earlycon is not
deregistered after non-early consoles are available.
- Earlycon is not deregistered because in some cases
flag CON_CONSDEV is not set for any of the new non-early
consoles.
- That flag is not set when two entries of console_cmdline
array refer to the same console. We match the first entry,
it is not preferred and the flag CON_CONSDEV is set only
for preferred console.
- So I changed the order of array walk so that if there
are two entries referring to the same console, last one is matched.
If we specify a console as prefered (last entry in command line)
that means that we expect a driver will eventually register
its console and for that driver we will match the last
entry and the earlycon will be deregistered.
- The subtle question is why we deregister earlycon only
when CON_CONSDEV is set (i. e. only for preferred console).
That check for CON_CONSDEV was initially introduced in
d37bf60de0b4 console: console handover to preferred console
and then refactored in
4d09161196c9 printk: Enable the use of more than one CON_BOOT (early console)
8259cf434202 printk: Ensure that "console enabled" messages are printed on the console
The reason is that some consoles can be registered later or earlier
and if we deregister earlycon when the first non-early console
is registered, we can lose some lines of log. To prevent that
we specify the console *which is being watched* as preferred
(the last console in the console_cmdline array) and
deregister earlycon only when kernel registers its driver.
> BTW: I wonder if we really need to add consoles defined by ACPI SPCR
> table into the console_cmdline array.
The console_cmdline array is the place where we add descriptions
of consoles that should receive log output. ACPI SPCR specifies exactly
that information, and I believe it should go to that array.
I don't quite follow your concern.
> I am even more curious when
> seeing the following code in drivers/acpi/spcr.c:
>
> int __init parse_spcr(bool earlycon) { [...] if (earlycon)
> setup_earlycon(opts);
>
> err = add_preferred_console(uart, 0, opts + strlen(uart) + 1); }
>
> It seems that we setup (register) the early console before we add it
> to the console_cmdline array. Do we really need to call
> add_preferred_console() for these early consoles?
Yes we need. When we setup an earlycon, we enable output
to that console immediately. Drivers can register its real
non-early consoles much later so we just add description
of that consoles to the console_cmdline arraly so that
when the driver registers a matching driver, earlycon is replaced
by a regular device. Or maybe I don't understand your concern here.
> If we do not call add_preferred_console() here, it should fix the
> duplicate output as well. Or do I still miss something?
Yes it will "fix", but the output will be from earlycon.
We want to replace earlycon with non-early console eventually
and that is why we call add_preferred_console() here.
Thank you
Aleksey Makarov
^ permalink raw reply
* [PATCH v2] serial: 8250_of: Add reset support
From: Joel Stanley @ 2017-05-26 1:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Philipp Zabel
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
This adds the hooks for an optional reset controller in the 8250 device
tree node.
Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
---
v2:
Address Philipp's comments. Thanks for the review!
- use _shared variant
- remove unnecessary error handling
Documentation/devicetree/bindings/serial/8250.txt | 1 +
drivers/tty/serial/8250/8250_of.c | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index 10276a46ecef..63e32393f82b 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -45,6 +45,7 @@ Optional properties:
property.
- tx-threshold: Specify the TX FIFO low water indication for parts with
programmable TX FIFO thresholds.
+- resets : phandle + reset specifier pairs
Note:
* fsl,ns16550:
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index 1cbadafc6889..e95cc9698c32 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -19,11 +19,13 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/clk.h>
+#include <linux/reset.h>
#include "8250.h"
struct of_serial_info {
struct clk *clk;
+ struct reset_control *rst;
int type;
int line;
};
@@ -132,6 +134,13 @@ static int of_platform_serial_setup(struct platform_device *ofdev,
}
}
+ info->rst = devm_reset_control_get_optional_shared(&ofdev->dev, NULL);
+ if (IS_ERR(info->rst))
+ goto out;
+ ret = reset_control_deassert(info->rst);
+ if (ret)
+ goto out;
+
port->type = type;
port->uartclk = clk;
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
@@ -231,6 +240,7 @@ static int of_platform_serial_remove(struct platform_device *ofdev)
if (info->clk)
clk_disable_unprepare(info->clk);
+ reset_control_assert(info->rst);
kfree(info);
return 0;
}
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] serial: 8250_of: Add reset support
From: Joel Stanley @ 2017-05-26 1:54 UTC (permalink / raw)
To: Philipp Zabel
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, linux-serial,
devicetree, Linux Kernel Mailing List
In-Reply-To: <1495613916.3840.16.camel@pengutronix.de>
On Wed, May 24, 2017 at 6:18 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi Joel,
>
> On Wed, 2017-05-24 at 14:53 +1000, Joel Stanley wrote:
>> @@ -132,6 +134,18 @@ static int of_platform_serial_setup(struct platform_device *ofdev,
>> }
>> }
>>
>> + info->rst = devm_reset_control_get_optional(&ofdev->dev, NULL);
>
> Please use devm_reset_control_get_optional_shared instead.
>
> This looks like shared (clock-like) reset use, where you just have to
> make sure that the reset is deasserted while the module is in use, but
> you don't care whether it is actually asserted all the time otherwise.
Thanks for the review. The new reset API is much nicer, and it worked
for me once I realised the changes came in for 4.11 (my test setup is
based on 4.10).
Cheers,
Joel
^ permalink raw reply
* Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN)
From: Max Filippov @ 2017-05-25 22:52 UTC (permalink / raw)
To: Babu Moger
Cc: Arnd Bergmann, Geert Uytterhoeven, David S. Miller,
Peter Zijlstra, Ingo Molnar, sparclinux,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Arch,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <116e7ba5-cb5e-8e96-ea74-bf91b4818d69-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Thu, May 25, 2017 at 3:41 PM, Babu Moger <babu.moger-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> On 5/25/2017 5:27 PM, Max Filippov wrote:
>> Xtensa may have either endianness and for xtensa we define
>> CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN
>> in the arch/xtensa/Makefile based on the value of the compiler builtin
>> macro.
>
> Hmm.. That means defining CPU_LITTLE_ENDIAN based on "def_bool
> !CPU_BIG_ENDIAN" will
> be a problem for Xtensa because menuconfig does not have the knowledge of
> compiler builtin macro.
> Is that correct?
I think so. OTOH outside the arch/ CPU_LITTLE_ENDIAN is only used in
two Kconfig files:
drivers/crypto/nx/Kconfig
drivers/isdn/hisax/Kconfig
both of which are irrelevant for xtensa.
--
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN)
From: Max Filippov @ 2017-05-25 22:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Babu Moger, David S. Miller, Peter Zijlstra,
Ingo Molnar, sparclinux, linux-kernel@vger.kernel.org, Linux-Arch,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org
In-Reply-To: <CAMo8BfL8G0Fzn2SZ1356yaoxGgm8tpTDmFJ8cCxEEEgyObMwCQ@mail.gmail.com>
On Thu, May 25, 2017 at 3:27 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Wed, May 24, 2017 at 3:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, May 24, 2017 at 11:59 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> I guess the time is ripe for adding (both) symbols to all architectures?
>>
>> Good idea. I think we can do most of this by adding a few lines to
>> arch/Kconfig:
>>
>> config CPU_BIG_ENDIAN
>> bool
>>
>> config CPU_LITTLE_ENDIAN
>> def_bool !CPU_BIG_ENDIAN
>>
>> This way, we only need to add 'select CPU_BIG_ENDIAN' to the
>> architectures that are always big-endian, and we don't need to
>> change anything for the ones that have a single 'CPU_BIG_ENDIAN'
>> option.
>>
>> The three architectures that have a 'choice' statement (mips, ppc and
>> sh) will have to convert, and m32r will have to replace the
>> option with the opposite one, which could break 'make oldconfig',
>> but nobody really cares about m32r any more.
>
> Xtensa may have either endianness and for xtensa we define
> CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN
> in the arch/xtensa/Makefile based on the value of the compiler builtin
> macro.
Also, in outside the Kconfig files there's much more instances of
__{BIG,LITTLE}_ENDIAN than CONFIG_CPU_{BIG,LITTLE}_ENDIAN:
$ git grep '__\(BIG\|LITTLE\)_ENDIAN' | wc -l
4537
$ git grep 'CONFIG_CPU_\(BIG\|LITTLE\)_ENDIAN' | wc -l
247
My understanding is that CONFIG_CPU_{BIG,LITTLE}_ENDIAN was
intended to be used only in Kconfig files, and perhaps all of its uses
outside should be replaced with __{BIG,LITTLE}_ENDIAN.
--
Thanks.
-- Max
^ permalink raw reply
* Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN)
From: Babu Moger @ 2017-05-25 22:41 UTC (permalink / raw)
To: Max Filippov, Arnd Bergmann
Cc: Geert Uytterhoeven, David S. Miller, Peter Zijlstra, Ingo Molnar,
sparclinux, linux-kernel@vger.kernel.org, Linux-Arch,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org
In-Reply-To: <CAMo8BfL8G0Fzn2SZ1356yaoxGgm8tpTDmFJ8cCxEEEgyObMwCQ@mail.gmail.com>
On 5/25/2017 5:27 PM, Max Filippov wrote:
> On Wed, May 24, 2017 at 3:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, May 24, 2017 at 11:59 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> I guess the time is ripe for adding (both) symbols to all architectures?
>> Good idea. I think we can do most of this by adding a few lines to
>> arch/Kconfig:
>>
>> config CPU_BIG_ENDIAN
>> bool
>>
>> config CPU_LITTLE_ENDIAN
>> def_bool !CPU_BIG_ENDIAN
>>
>> This way, we only need to add 'select CPU_BIG_ENDIAN' to the
>> architectures that are always big-endian, and we don't need to
>> change anything for the ones that have a single 'CPU_BIG_ENDIAN'
>> option.
>>
>> The three architectures that have a 'choice' statement (mips, ppc and
>> sh) will have to convert, and m32r will have to replace the
>> option with the opposite one, which could break 'make oldconfig',
>> but nobody really cares about m32r any more.
> Xtensa may have either endianness and for xtensa we define
> CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN
> in the arch/xtensa/Makefile based on the value of the compiler builtin
> macro.
Hmm.. That means defining CPU_LITTLE_ENDIAN based on "def_bool
!CPU_BIG_ENDIAN" will
be a problem for Xtensa because menuconfig does not have the knowledge
of compiler builtin macro.
Is that correct?
^ permalink raw reply
* Re: [BUG] tty/serial: stty hangs for 30 seconds after interrupted transfer
From: Rob Herring @ 2017-05-25 22:34 UTC (permalink / raw)
To: Dmitry Artamonow
Cc: Greg Kroah-Hartman, Peter Hurley, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, Uwe Kleine-König,
Fabio Estevam, Alan Cox
In-Reply-To: <c87da751-0692-e381-be16-a2adf0f0104f@inbox.lv>
On Thu, May 25, 2017 at 8:22 AM, Dmitry Artamonow <mad_soft@inbox.lv> wrote:
> Hello.
>
> While working on i.MX6-based board I found weird problem with serial ports.
> When I do some write in serial port and then interrupt it prematurely with
> Ctrl-C, following call to stty hangs for 30 seconds. Basic reproducing steps:
>
> 1. cat some_large_text_file.txt > /dev/ttymxc1
> 2. Press Ctrl-C
> 3. stty -F /dev/ttymxc1
I've tried this on an db410c and can't reproduce. Different serial
driver though. I do get a few second delay after ctrl-C. Do you get a
delay there?
I couldn't repo with 8250 either, but that was on qemu which is
doesn't have realistic timing.
> If I send some more data over the port afterwards and don't interrupt it,
> following call to stty doesn't hang.
[...]
> I located the place of the hang inside the tty_wait_until_sent() function.
> Looks like it waits for UART to finish sending, but as the UART doesn't
> actually send anything, it exits only after 30 second timeout.
So the only way to get a 30 sec timeout is if tty_chars_in_buffer()
returns that the circular buffer contains some characters.
> After some digging I found that the problem seems to be caused by
> commit 761ed4a94582 ("tty: serial_core: convert uart_close to use
> tty_port_close"). Reverting this and related commits (a5a2b13074fd,
> be2c92b8f164, 4dda864d7307) makes the problem go away.
>
> Also note that statistics seems to be broken in the log above. After
> running "sendandkill" it says that 0 bytes were sent while actually
> about 970 bytes were transferred. And after sending one more character with
> echo, it actually sends 2400+1 characters, i.e. resends the whole previously
> interrupted buffer before sending 'X'. Reverts above fix this only partially.
> UART doesn't resend previous characters anymore, but still statistics is
> wrong about first interrupted transfer. But I suspect this could be a separate
> problem in imx driver.
>
> Any ideas how to fix this hang? I tried to put uart_flush_buffer() into
> uart_close() before call to tty_port_close() and it kind of works, but
> I'm not really sure whether it's a proper fix. Given my lack of experience
> with TTY subsystem and level of its complexity I suspect that I can
> easily miss something.
Kind of works? Is there still some problem beyond the statistics?
uart_flush_buffer would ensure the circular buffer is empty. It seems
like that is getting corrupted.
Can you add some debug prints in open, close and the tx isr with the
circular buffer head and tail values?
Rob
^ permalink raw reply
* Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN)
From: Max Filippov @ 2017-05-25 22:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Babu Moger, David S. Miller, Peter Zijlstra,
Ingo Molnar, sparclinux,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Arch,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAK8P3a1XZGQk3b3q+JFJ+mLgw_upUdAtTM1VBjHZq5f2m-YdUg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, May 24, 2017 at 3:18 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wed, May 24, 2017 at 11:59 AM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>> I guess the time is ripe for adding (both) symbols to all architectures?
>
> Good idea. I think we can do most of this by adding a few lines to
> arch/Kconfig:
>
> config CPU_BIG_ENDIAN
> bool
>
> config CPU_LITTLE_ENDIAN
> def_bool !CPU_BIG_ENDIAN
>
> This way, we only need to add 'select CPU_BIG_ENDIAN' to the
> architectures that are always big-endian, and we don't need to
> change anything for the ones that have a single 'CPU_BIG_ENDIAN'
> option.
>
> The three architectures that have a 'choice' statement (mips, ppc and
> sh) will have to convert, and m32r will have to replace the
> option with the opposite one, which could break 'make oldconfig',
> but nobody really cares about m32r any more.
Xtensa may have either endianness and for xtensa we define
CONFIG_CPU_BIG_ENDIAN or CONFIG_CPU_LITTLE_ENDIAN
in the arch/xtensa/Makefile based on the value of the compiler builtin
macro.
--
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN)
From: Babu Moger @ 2017-05-25 20:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, David S. Miller, Peter Zijlstra, Ingo Molnar,
sparclinux, linux-kernel@vger.kernel.org, Linux-Arch,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org
In-Reply-To: <CAK8P3a0MEkZ0wpsrit+sS8A0Z5T_jFWF5vFq_BqF2A1tReb7tQ@mail.gmail.com>
On 5/25/2017 3:09 PM, Arnd Bergmann wrote:
> On Thu, May 25, 2017 at 4:51 PM, Babu Moger <babu.moger@oracle.com> wrote:
>> On 5/24/2017 5:18 AM, Arnd Bergmann wrote:
>>>> I guess the time is ripe for adding (both) symbols to all architectures?
>>> Good idea. I think we can do most of this by adding a few lines to
>>> arch/Kconfig:
>>>
>>> config CPU_BIG_ENDIAN
>>> bool
>>>
>>> config CPU_LITTLE_ENDIAN
>>> def_bool !CPU_BIG_ENDIAN
>>>
>>> This way, we only need to add 'select CPU_BIG_ENDIAN' to the
>>> architectures that are always big-endian, and we don't need to
>>> change anything for the ones that have a single 'CPU_BIG_ENDIAN'
>>> option.
>>>
>>> The three architectures that have a 'choice' statement (mips, ppc and
>>> sh) will have to convert, and m32r will have to replace the
>>
>> what to you mean by "(mips, ppc andsh) will have to convert"? Do you expect
>> any changes here?
>>
> Kconfig does not allow you to have the same symbol as both a regular
> 'bool' and also 'bool within choice', so those three have to replace the
> choice with a user-visible 'config CPU_BIG_ENDIAN' option like the
> other ones have.
Ok. I will address it in my next version. Thanks
>
> I also notice that for arch/s390/Kconfig you now have both the
> 'select CPU_BIG_ENDIAN' and the 'config CPU_BIG_ENDIAN
> def_bool y', I'd remove the second one in the same patch.
Sure. Will correct it.
> Arnd
^ permalink raw reply
* Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN)
From: Arnd Bergmann @ 2017-05-25 20:09 UTC (permalink / raw)
To: Babu Moger
Cc: Geert Uytterhoeven, David S. Miller, Peter Zijlstra, Ingo Molnar,
sparclinux, linux-kernel@vger.kernel.org, Linux-Arch,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org
In-Reply-To: <8ddc7276-6296-2284-51d3-01093ccbeccb@oracle.com>
On Thu, May 25, 2017 at 4:51 PM, Babu Moger <babu.moger@oracle.com> wrote:
> On 5/24/2017 5:18 AM, Arnd Bergmann wrote:
>>> I guess the time is ripe for adding (both) symbols to all architectures?
>>
>> Good idea. I think we can do most of this by adding a few lines to
>> arch/Kconfig:
>>
>> config CPU_BIG_ENDIAN
>> bool
>>
>> config CPU_LITTLE_ENDIAN
>> def_bool !CPU_BIG_ENDIAN
>>
>> This way, we only need to add 'select CPU_BIG_ENDIAN' to the
>> architectures that are always big-endian, and we don't need to
>> change anything for the ones that have a single 'CPU_BIG_ENDIAN'
>> option.
>>
>> The three architectures that have a 'choice' statement (mips, ppc and
>> sh) will have to convert, and m32r will have to replace the
>
>
> what to you mean by "(mips, ppc andsh) will have to convert"? Do you expect
> any changes here?
>
Kconfig does not allow you to have the same symbol as both a regular
'bool' and also 'bool within choice', so those three have to replace the
choice with a user-visible 'config CPU_BIG_ENDIAN' option like the
other ones have.
I also notice that for arch/s390/Kconfig you now have both the
'select CPU_BIG_ENDIAN' and the 'config CPU_BIG_ENDIAN
def_bool y', I'd remove the second one in the same patch.
Arnd
^ permalink raw reply
* Re: [PATCH v7 net-next 17/17] net: qualcomm: add QCA7000 UART driver
From: David Miller @ 2017-05-25 17:13 UTC (permalink / raw)
To: stefan.wahren
Cc: robh+dt, mark.rutland, gregkh, jslaby, LinoSanfilippo, kubakici,
devicetree, netdev, linux-serial, linux-kernel
In-Reply-To: <1495618181-1204-1-git-send-email-stefan.wahren@i2se.com>
When you submit a new version of a patch within a patch series, you must
always resubmit the entire series not just the patches which change.
Thank you.
^ permalink raw reply
* Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts
From: Michal Simek @ 2017-05-25 15:33 UTC (permalink / raw)
To: Alan Cox, Michal Simek
Cc: Rob Herring, Sam Povilus, gregkh, jslaby, soren.brinkmann,
linux-serial, linux-arm-kernel, linux-kernel
In-Reply-To: <20170525142920.1d662467@alans-desktop>
On 25.5.2017 15:29, Alan Cox wrote:
>> Ok. Is there any problem if uart_register_driver is called for every
>> instance separately with nr=1? This driver has major 0, minor 0. Based
>
> If you are doing that level of code restructuring none that I am aware
> of, and if you find one I'm happy to work on fixing it.
ok. Let me try to play with it and see if this is working.
M
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox