[PATCH 0/5] serial: Add Generic Serial Device Tree Bindings

[PATCH 0/5] serial: Add Generic Serial Device Tree Bindings

[Geert Uytterhoeven]

	Hi all,

This patch series, against next-20160414, introduces Generic Serial
Device Tree Bindings, and converts drivers using vendor-specific DT
properties to the generic properies where appropriate.

The Generic Serial Device Tree Bindings document a set of generic
properties for describing UARTs in a device tree:
  1. The GPIO modem control properties are currently duplicated across
     hardware-specific binding documentation,
  2. The property for dedicated RTS/CTS hardware flow control lines is
     already supported by several drivers, albeit with a vendor-specific
     prefix, hence make it generic.
Whether these generic properties apply to a particular device still
depends on the DT bindings of the actual device.

The old (deprecated) vendor-specific properties are still supported by
the drivers for backwards compatibility.  Actual DTS files are to be
updated later, after this series has been integrated into mainline.

Thanks for your comments!

Geert Uytterhoeven (5):
  doc: DT: Add Generic Serial Device Tree Bindings
  serial: imx: Use generic uart-has-rtscts DT property
  serial: mxs-auart: Use generic uart-has-rtscts DT property
  serial: sirf: Introduce helper variable struct device_node *np
  serial: sirf: Use generic uart-has-rtscts DT property

 .../devicetree/bindings/serial/fsl-imx-uart.txt    |  4 +-
 .../devicetree/bindings/serial/fsl-mxs-auart.txt   |  2 +-
 .../devicetree/bindings/serial/serial.txt          | 61 ++++++++++++++++++++++
 .../devicetree/bindings/serial/sirf-uart.txt       |  8 +--
 drivers/tty/serial/imx.c                           |  3 +-
 drivers/tty/serial/mxs-auart.c                     |  3 +-
 drivers/tty/serial/sirfsoc_uart.c                  | 39 +++++++-------
 7 files changed, 91 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/serial.txt

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH 1/5] doc: DT: Add Generic Serial Device Tree Bindings

[Geert Uytterhoeven]

Document a set of generic properties for describing UARTs in a
device tree:
  1. The GPIO modem control properties are currently duplicated across
     hardware-specific binding documentation,
  2. The property for dedicated RTS/CTS hardware flow control lines is
     already supported by several drivers, albeit with a vendor-specific
     prefix, hence make it generic.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 .../devicetree/bindings/serial/serial.txt          | 61 ++++++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/serial.txt

diff --git a/Documentation/devicetree/bindings/serial/serial.txt b/Documentation/devicetree/bindings/serial/serial.txt
new file mode 100644
index 0000000000000000..21afdbd973b07a44
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/serial.txt
@@ -0,0 +1,61 @@
+Generic Serial DT Bindings
+
+This document lists a set of generic properties for describing UARTs in a
+device tree.  Whether these properties apply to a particular device depends on
+the DT bindings for the actual device.
+
+Optional properties:
+  - cts-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
+    used as the UART's CTS line.
+  - dcd-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
+    used as the UART's DCD line.
+  - dsr-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
+    used as the UART's DSR line.
+  - dtr-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
+    used as the UART's DTR line.
+  - out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
+    used as the UART's OUT1 line.
+  - out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
+    used as the UART's OUT2 line.
+  - rng-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
+    used as the UART's RNG line.
+  - rts-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
+    used as the UART's RTS line.
+
+  - uart-has-rtscts: The presence of this property indicates that the
+    UART has dedicated lines for RTS/CTS hardware flow control, and that
+    they are available for use (wired and enabled by pinmux configuration).
+    This depends on both the UART hardware and the board wiring.
+    Note that this property is mutually-exclusive with "cts-gpios" and
+    "rts-gpios" above.
+
+
+Examples:
+
+	uart1: serial at 48022000 {
+		compatible = "ti,am3352-uart", "ti,omap3-uart";
+		ti,hwmods = "uart2";
+		clock-frequency = <48000000>;
+		reg = <0x48022000 0x2000>;
+		interrupts = <73>;
+		dmas = <&edma 28 0>, <&edma 29 0>;
+		dma-names = "tx", "rx";
+		dtr-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>;
+		dsr-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
+		dcd-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
+		rng-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>;
+		cts-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+		rts-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+		status = "okay";
+	};
+
+	scifa4: serial at e6c80000 {
+		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
+		reg = <0xe6c80000 0x100>;
+		interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp2_clks SH73A0_CLK_SCIFA4>;
+		clock-names = "fck";
+		power-domains = <&pd_a3sp>;
+		uart-has-rtscts;
+		status = "okay";
+	};
-- 
1.9.1

[PATCH 1/5] doc: DT: Add Generic Serial Device Tree Bindings

[Rob Herring]

On Thu, Apr 14, 2016 at 02:13:19PM +0200, Geert Uytterhoeven wrote:
> Document a set of generic properties for describing UARTs in a
> device tree:
>   1. The GPIO modem control properties are currently duplicated across
>      hardware-specific binding documentation,
>   2. The property for dedicated RTS/CTS hardware flow control lines is
>      already supported by several drivers, albeit with a vendor-specific
>      prefix, hence make it generic.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  .../devicetree/bindings/serial/serial.txt          | 61 ++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/serial/serial.txt

Thanks for doing this.

Acked-by: Rob Herring <rob@kernel.org>

[PATCH 1/5] doc: DT: Add Generic Serial Device Tree Bindings

[Arnd Bergmann]

On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
> Document a set of generic properties for describing UARTs in a
> device tree:
>   1. The GPIO modem control properties are currently duplicated across
>      hardware-specific binding documentation,
>   2. The property for dedicated RTS/CTS hardware flow control lines is
>      already supported by several drivers, albeit with a vendor-specific
>      prefix, hence make it generic.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Originally the ISA 8250 uart binding (from ieee) was used as the
template for other uart bindings. How about documenting the parts that
are used in 8250-of today (current-speed, clock-frequency,
reg-offset, reg-shift, fifo-size, reg-io-width, auto-flow-control)
in the same file?

>  - out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
>    used as the UART's OUT1 line.
>  - out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
>    used as the UART's OUT2 line.

I had to look up what OUT1 and OUT2 are, but I still don't see how you'd
implement them using a GPIO line: From all I can tell, these are usually
internal registers in a hardware uart but they are not assigned to an
external line on the standard db9 or even the old db25 connectors. Should
we drop these instead?

On a related note, do you think it would be possible to do a bit-banged
uart if we defined gpio lines for rxd and txd?

	Arnd

[PATCH 1/5] doc: DT: Add Generic Serial Device Tree Bindings

[Geert Uytterhoeven]

Hi Arnd,

CC Richard (serial-mctrl-gpio)
CC Grant (ePAPR successor) and Frank

On Sat, Apr 16, 2016 at 6:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
>> Document a set of generic properties for describing UARTs in a
>> device tree:
>>   1. The GPIO modem control properties are currently duplicated across
>>      hardware-specific binding documentation,
>>   2. The property for dedicated RTS/CTS hardware flow control lines is
>>      already supported by several drivers, albeit with a vendor-specific
>>      prefix, hence make it generic.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Originally the ISA 8250 uart binding (from ieee) was used as the
> template for other uart bindings. How about documenting the parts that
> are used in 8250-of today (current-speed, clock-frequency,
> reg-offset, reg-shift, fifo-size, reg-io-width, auto-flow-control)
> in the same file?

I don't think we have the habit of documenting (duplicating) bindings for ePAPR
under Documentation/devicetree/bindings/. Perhaps we should?

Apart from that, most of the properties you mention look legacy or overly
broad too me.

  - current-speed: This is configuration, not a property of the hardware.
    For the console, this has been deprecated by appending the serial config
    to chosen/stdout-path (e.g. "serial0:115200n8").
    For non-consoles, its use is debatable, IMHO.
    It's users are mostly legacy powerpc and early adaptors of DT on ARM.
  - clock-frequency: Legacy predating the Common Clock Framework.
    Any modern SoC uses clock specifiers with clock handles pointing to clock
    providers.
  - reg-offset, reg-shift, reg-io-width: These are much broader than serial,
    and IMHO thus don't belong in
    Documentation/devicetree/bindings/serial/serial.txt.
  - auto-flow-control: Looks a bit like a vague version of "uart-has-rtscts".
    Documentation/devicetree/bindings/serial/8250.txt doesn't make it clear
    whether this is about hardware capabilities or software configuration.
    Even the driver doesn't make it clear:
    #define UART_CAP_AFE    (1 << 11)       /* MCR-based hw flow control */
    "MCR" could mean RTS/CTS, DSR/DTR, ...
  - fifo-size: This one could be generic. atmel-usart uses a vendor-specific
    version "atmel,fifo-size".

I suggest we move forward with my initial set, as I have patches that depend on
them? We can always add more properties later.

>>  - out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
>>    used as the UART's OUT1 line.
>>  - out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
>>    used as the UART's OUT2 line.
>
> I had to look up what OUT1 and OUT2 are, but I still don't see how you'd
> implement them using a GPIO line: From all I can tell, these are usually
> internal registers in a hardware uart but they are not assigned to an
> external line on the standard db9 or even the old db25 connectors. Should
> we drop these instead?

They're indeed fairly exotic, and they're burried deeply in the ns16550
datasheet. We do have TIOCM_OUT1 and TIOCM_LOOP in asm-generic/termios.h,
probably for obscure historical reasons.

If we drop them, I guess they should be removed from the helper code in
drivers/tty/serial/serial_mctrl_gpio.c, too? There don't seem to be any
current users.

> On a related note, do you think it would be possible to do a bit-banged
> uart if we defined gpio lines for rxd and txd?

Sure we can. Whether it would work well is another question ;-)
Regardless of flow control, byte transmission and reception has hard real-time
requirements due to the implicit clocking.
Bit-banging i2c and spi (master) is much easier, as clocking is explicit.
Even i2c slave is easier, as the slave can stretch cycles.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 1/5] doc: DT: Add Generic Serial Device Tree Bindings

[Arnd Bergmann]

On Monday 18 April 2016 14:34:12 Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> CC Richard (serial-mctrl-gpio)
> CC Grant (ePAPR successor) and Frank
> 
> On Sat, Apr 16, 2016 at 6:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
> >> Document a set of generic properties for describing UARTs in a
> >> device tree:
> >>   1. The GPIO modem control properties are currently duplicated across
> >>      hardware-specific binding documentation,
> >>   2. The property for dedicated RTS/CTS hardware flow control lines is
> >>      already supported by several drivers, albeit with a vendor-specific
> >>      prefix, hence make it generic.
> >>
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Originally the ISA 8250 uart binding (from ieee) was used as the
> > template for other uart bindings. How about documenting the parts that
> > are used in 8250-of today (current-speed, clock-frequency,
> > reg-offset, reg-shift, fifo-size, reg-io-width, auto-flow-control)
> > in the same file?
> 
> I don't think we have the habit of documenting (duplicating) bindings for ePAPR
> under Documentation/devicetree/bindings/. Perhaps we should?
> 
> Apart from that, most of the properties you mention look legacy or overly
> broad too me.
> 
>   - current-speed: This is configuration, not a property of the hardware.
>     For the console, this has been deprecated by appending the serial config
>     to chosen/stdout-path (e.g. "serial0:115200n8").
>     For non-consoles, its use is debatable, IMHO.
>     It's users are mostly legacy powerpc and early adaptors of DT on ARM.
>   - clock-frequency: Legacy predating the Common Clock Framework.
>     Any modern SoC uses clock specifiers with clock handles pointing to clock
>     providers.

I think both are still used by IBM Firmware, which does not use the clock
binding or the linux syntax for passing the speed.

>   - reg-offset, reg-shift, reg-io-width: These are much broader than serial,
>     and IMHO thus don't belong in
>     Documentation/devicetree/bindings/serial/serial.txt.

The exact meaning can be explained elsewhere, but I think the binding
can mention that they are allowed.

>   - auto-flow-control: Looks a bit like a vague version of "uart-has-rtscts".
>     Documentation/devicetree/bindings/serial/8250.txt doesn't make it clear
>     whether this is about hardware capabilities or software configuration.
>     Even the driver doesn't make it clear:
>     #define UART_CAP_AFE    (1 << 11)       /* MCR-based hw flow control */
>     "MCR" could mean RTS/CTS, DSR/DTR, ...
>   - fifo-size: This one could be generic. atmel-usart uses a vendor-specific
>     version "atmel,fifo-size".
> 
> I suggest we move forward with my initial set, as I have patches that depend on
> them? We can always add more properties later.

Sounds ok to me.

> >>  - out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
> >>    used as the UART's OUT1 line.
> >>  - out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
> >>    used as the UART's OUT2 line.
> >
> > I had to look up what OUT1 and OUT2 are, but I still don't see how you'd
> > implement them using a GPIO line: From all I can tell, these are usually
> > internal registers in a hardware uart but they are not assigned to an
> > external line on the standard db9 or even the old db25 connectors. Should
> > we drop these instead?
> 
> They're indeed fairly exotic, and they're burried deeply in the ns16550
> datasheet. We do have TIOCM_OUT1 and TIOCM_LOOP in asm-generic/termios.h,
> probably for obscure historical reasons.
> 
> If we drop them, I guess they should be removed from the helper code in
> drivers/tty/serial/serial_mctrl_gpio.c, too? There don't seem to be any
> current users.

I think it makes sense for user space to toggle at least TIOCM_OUT1
through the ioctl and for drivers to implement it correctly. Apparently
the "Hayes SmartModem" used this for resetting the modem from its
integrated uart.

	Arnd

[PATCH 1/5] doc: DT: Add Generic Serial Device Tree Bindings

[Richard Genoud]

2016-04-18 14:34 GMT+02:00 Geert Uytterhoeven <geert@linux-m68k.org>:
> Hi Arnd,
>
> CC Richard (serial-mctrl-gpio)
> CC Grant (ePAPR successor) and Frank
>
> On Sat, Apr 16, 2016 at 6:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
>>> Document a set of generic properties for describing UARTs in a
>>> device tree:
>>>   1. The GPIO modem control properties are currently duplicated across
>>>      hardware-specific binding documentation,
>>>   2. The property for dedicated RTS/CTS hardware flow control lines is
>>>      already supported by several drivers, albeit with a vendor-specific
>>>      prefix, hence make it generic.
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> Originally the ISA 8250 uart binding (from ieee) was used as the
>> template for other uart bindings. How about documenting the parts that
>> are used in 8250-of today (current-speed, clock-frequency,
>> reg-offset, reg-shift, fifo-size, reg-io-width, auto-flow-control)
>> in the same file?
>
> I don't think we have the habit of documenting (duplicating) bindings for ePAPR
> under Documentation/devicetree/bindings/. Perhaps we should?
>
> Apart from that, most of the properties you mention look legacy or overly
> broad too me.
>
>   - current-speed: This is configuration, not a property of the hardware.
>     For the console, this has been deprecated by appending the serial config
>     to chosen/stdout-path (e.g. "serial0:115200n8").
>     For non-consoles, its use is debatable, IMHO.
>     It's users are mostly legacy powerpc and early adaptors of DT on ARM.
>   - clock-frequency: Legacy predating the Common Clock Framework.
>     Any modern SoC uses clock specifiers with clock handles pointing to clock
>     providers.
>   - reg-offset, reg-shift, reg-io-width: These are much broader than serial,
>     and IMHO thus don't belong in
>     Documentation/devicetree/bindings/serial/serial.txt.
>   - auto-flow-control: Looks a bit like a vague version of "uart-has-rtscts".
>     Documentation/devicetree/bindings/serial/8250.txt doesn't make it clear
>     whether this is about hardware capabilities or software configuration.
>     Even the driver doesn't make it clear:
>     #define UART_CAP_AFE    (1 << 11)       /* MCR-based hw flow control */
>     "MCR" could mean RTS/CTS, DSR/DTR, ...
>   - fifo-size: This one could be generic. atmel-usart uses a vendor-specific
>     version "atmel,fifo-size".
>
> I suggest we move forward with my initial set, as I have patches that depend on
> them? We can always add more properties later.
>
>>>  - out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
>>>    used as the UART's OUT1 line.
>>>  - out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
>>>    used as the UART's OUT2 line.
>>
>> I had to look up what OUT1 and OUT2 are, but I still don't see how you'd
>> implement them using a GPIO line: From all I can tell, these are usually
>> internal registers in a hardware uart but they are not assigned to an
>> external line on the standard db9 or even the old db25 connectors. Should
>> we drop these instead?
>
> They're indeed fairly exotic, and they're burried deeply in the ns16550
> datasheet. We do have TIOCM_OUT1 and TIOCM_LOOP in asm-generic/termios.h,
> probably for obscure historical reasons.
>
> If we drop them, I guess they should be removed from the helper code in
> drivers/tty/serial/serial_mctrl_gpio.c, too? There don't seem to be any
> current users.
I must confess that I don't really know what TIOCM_OUT1&2 are for.
(I implemented them for completeness)
But it seems that OUT2 is used in some drivers:
drivers/tty/serial/omap-serial.c:
        /*
         * Most PC uarts need OUT2 raised to enable interrupts.
         */
        up->port.mctrl |= TIOCM_OUT2;
>
>> On a related note, do you think it would be possible to do a bit-banged
>> uart if we defined gpio lines for rxd and txd?
>
> Sure we can. Whether it would work well is another question ;-)
> Regardless of flow control, byte transmission and reception has hard real-time
> requirements due to the implicit clocking.
> Bit-banging i2c and spi (master) is much easier, as clocking is explicit.
> Even i2c slave is easier, as the slave can stretch cycles.
+1

[PATCH 1/5] doc: DT: Add Generic Serial Device Tree Bindings

[Peter Hurley]

On 04/18/2016 08:43 AM, Richard Genoud wrote:
> 2016-04-18 14:34 GMT+02:00 Geert Uytterhoeven <geert@linux-m68k.org>:
>> Hi Arnd,
>>
>> CC Richard (serial-mctrl-gpio)
>> CC Grant (ePAPR successor) and Frank
>>
>> On Sat, Apr 16, 2016 at 6:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:

[...]

>>>>  - out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
>>>>    used as the UART's OUT1 line.
>>>>  - out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be
>>>>    used as the UART's OUT2 line.
>>>
>>> I had to look up what OUT1 and OUT2 are, but I still don't see how you'd
>>> implement them using a GPIO line: From all I can tell, these are usually
>>> internal registers in a hardware uart but they are not assigned to an
>>> external line on the standard db9 or even the old db25 connectors. Should
>>> we drop these instead?

Yeah, not sure how those snuck in for gpios.

The original 8250/16550 uarts had OUT1 and OUT2 pins, and OUT1 could be used
like gpio. That was 3 decades ago though so maybe we don't need to try to
recreate that tech again :)


>> They're indeed fairly exotic, and they're burried deeply in the ns16550
>> datasheet. We do have TIOCM_OUT1 and TIOCM_LOOP in asm-generic/termios.h,
>> probably for obscure historical reasons.

Please leave the bit defs alone.


>> If we drop them, I guess they should be removed from the helper code in
>> drivers/tty/serial/serial_mctrl_gpio.c, too? There don't seem to be any
>> current users.
> I must confess that I don't really know what TIOCM_OUT1&2 are for.
> (I implemented them for completeness)
> But it seems that OUT2 is used in some drivers:
> drivers/tty/serial/omap-serial.c:
>         /*
>          * Most PC uarts need OUT2 raised to enable interrupts.
>          */
>         up->port.mctrl |= TIOCM_OUT2;

There's no need for OUT1 and OUT2 gpios; let's fix that.

Regards,
Peter Hurley

[PATCH 2/5] serial: imx: Use generic uart-has-rtscts DT property

[Geert Uytterhoeven]

Convert the Freescale IMX UART driver from using the vendor-specific
"fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as
documented by the Generic Serial DT Bindings.

The old vendor-specific property is still recognized by the driver for
backwards compatibility, but deprecated.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 4 ++--
 drivers/tty/serial/imx.c                                  | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
index ed94c217c98d18a6..1e82802d8e322db5 100644
--- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
@@ -6,7 +6,7 @@ Required properties:
 - interrupts : Should contain uart interrupt
 
 Optional properties:
-- fsl,uart-has-rtscts : Indicate the uart has rts and cts
+- uart-has-rtscts : Indicate the uart has rts and cts
 - fsl,irda-mode : Indicate the uart supports irda mode
 - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
                   in DCE mode by default.
@@ -24,6 +24,6 @@ uart1: serial at 73fbc000 {
 	compatible = "fsl,imx51-uart", "fsl,imx21-uart";
 	reg = <0x73fbc000 0x4000>;
 	interrupts = <31>;
-	fsl,uart-has-rtscts;
+	uart-has-rtscts;
 	fsl,dte-mode;
 };
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 231e7d5caf6c1845..9fc09d3de1e2428b 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1927,7 +1927,8 @@ static int serial_imx_probe_dt(struct imx_port *sport,
 	}
 	sport->port.line = ret;
 
-	if (of_get_property(np, "fsl,uart-has-rtscts", NULL))
+	if (of_get_property(np, "uart-has-rtscts", NULL) ||
+	    of_get_property(np, "fsl,uart-has-rtscts", NULL) /* deprecated */)
 		sport->have_rtscts = 1;
 
 	if (of_get_property(np, "fsl,dte-mode", NULL))
-- 
1.9.1

[PATCH 2/5] serial: imx: Use generic uart-has-rtscts DT property

[Rob Herring]

On Thu, Apr 14, 2016 at 02:13:20PM +0200, Geert Uytterhoeven wrote:
> Convert the Freescale IMX UART driver from using the vendor-specific
> "fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as
> documented by the Generic Serial DT Bindings.
> 
> The old vendor-specific property is still recognized by the driver for
> backwards compatibility, but deprecated.

You should update the dts files as well.

> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 4 ++--
>  drivers/tty/serial/imx.c                                  | 3 ++-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> index ed94c217c98d18a6..1e82802d8e322db5 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> @@ -6,7 +6,7 @@ Required properties:
>  - interrupts : Should contain uart interrupt
>  
>  Optional properties:
> -- fsl,uart-has-rtscts : Indicate the uart has rts and cts
> +- uart-has-rtscts : Indicate the uart has rts and cts
>  - fsl,irda-mode : Indicate the uart supports irda mode
>  - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
>                    in DCE mode by default.
> @@ -24,6 +24,6 @@ uart1: serial at 73fbc000 {
>  	compatible = "fsl,imx51-uart", "fsl,imx21-uart";
>  	reg = <0x73fbc000 0x4000>;
>  	interrupts = <31>;
> -	fsl,uart-has-rtscts;
> +	uart-has-rtscts;
>  	fsl,dte-mode;
>  };
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 231e7d5caf6c1845..9fc09d3de1e2428b 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1927,7 +1927,8 @@ static int serial_imx_probe_dt(struct imx_port *sport,
>  	}
>  	sport->port.line = ret;
>  
> -	if (of_get_property(np, "fsl,uart-has-rtscts", NULL))
> +	if (of_get_property(np, "uart-has-rtscts", NULL) ||
> +	    of_get_property(np, "fsl,uart-has-rtscts", NULL) /* deprecated */)
>  		sport->have_rtscts = 1;
>  
>  	if (of_get_property(np, "fsl,dte-mode", NULL))
> -- 
> 1.9.1
> 

[PATCH 2/5] serial: imx: Use generic uart-has-rtscts DT property

[Geert Uytterhoeven]

Hi Rob,

On Thu, Apr 14, 2016 at 7:22 PM, Rob Herring <robh@kernel.org> wrote:
> On Thu, Apr 14, 2016 at 02:13:20PM +0200, Geert Uytterhoeven wrote:
>> Convert the Freescale IMX UART driver from using the vendor-specific
>> "fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as
>> documented by the Generic Serial DT Bindings.
>>
>> The old vendor-specific property is still recognized by the driver for
>> backwards compatibility, but deprecated.
>
> You should update the dts files as well.

Indeed. But as I said in the cover letter:

"Actual DTS files are to be updated later, after this series has been
 integrated into mainline."

DTS updates typically go through a different path (e.g. arm-soc).
RTS/CTS support will be broken if the DTSes are updated before the drivers.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 3/5] serial: mxs-auart: Use generic uart-has-rtscts DT property

[Geert Uytterhoeven]

Convert the Freescale MXS AUART driver from using the vendor-specific
"fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as
documented by the Generic Serial DT Bindings.

The old vendor-specific property is still recognized by the driver for
backwards compatibility, but it is deprecated.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt | 2 +-
 drivers/tty/serial/mxs-auart.c                             | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt
index 7c408c87e6138979..9ba60c14047a0be8 100644
--- a/Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt
@@ -11,7 +11,7 @@ Required properties:
 - dma-names: "rx" for RX channel, "tx" for TX channel.
 
 Optional properties:
-- fsl,uart-has-rtscts : Indicate the UART has RTS and CTS lines
+- uart-has-rtscts : Indicate the UART has RTS and CTS lines
   for hardware flow control,
 	it also means you enable the DMA support for this UART.
 - {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index cd0414bbe094898e..c988544f38bbb885 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1185,7 +1185,8 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
 	}
 	s->port.line = ret;
 
-	if (of_get_property(np, "fsl,uart-has-rtscts", NULL))
+	if (of_get_property(np, "uart-has-rtscts", NULL) ||
+	    of_get_property(np, "fsl,uart-has-rtscts", NULL) /* deprecated */)
 		set_bit(MXS_AUART_RTSCTS, &s->flags);
 
 	return 0;
-- 
1.9.1

[PATCH 4/5] serial: sirf: Introduce helper variable struct device_node *np

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sirfsoc_uart.c | 38 ++++++++++++++++++--------------------
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
index c6657de789977c90..1d1c0b9857ff6900 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -1264,6 +1264,7 @@ MODULE_DEVICE_TABLE(of, sirfsoc_uart_ids);
 
 static int sirfsoc_uart_probe(struct platform_device *pdev)
 {
+	struct device_node *np = pdev->dev.of_node;
 	struct sirfsoc_uart_port *sirfport;
 	struct uart_port *port;
 	struct resource *res;
@@ -1276,13 +1277,13 @@ static int sirfsoc_uart_probe(struct platform_device *pdev)
 	};
 	const struct of_device_id *match;
 
-	match = of_match_node(sirfsoc_uart_ids, pdev->dev.of_node);
+	match = of_match_node(sirfsoc_uart_ids, np);
 	sirfport = devm_kzalloc(&pdev->dev, sizeof(*sirfport), GFP_KERNEL);
 	if (!sirfport) {
 		ret = -ENOMEM;
 		goto err;
 	}
-	sirfport->port.line = of_alias_get_id(pdev->dev.of_node, "serial");
+	sirfport->port.line = of_alias_get_id(np, "serial");
 	sirf_ports[sirfport->port.line] = sirfport;
 	sirfport->port.iotype = UPIO_MEM;
 	sirfport->port.flags = UPF_BOOT_AUTOCONF;
@@ -1291,25 +1292,24 @@ static int sirfsoc_uart_probe(struct platform_device *pdev)
 	port->private_data = sirfport;
 	sirfport->uart_reg = (struct sirfsoc_uart_register *)match->data;
 
-	sirfport->hw_flow_ctrl = of_property_read_bool(pdev->dev.of_node,
-		"sirf,uart-has-rtscts");
-	if (of_device_is_compatible(pdev->dev.of_node, "sirf,prima2-uart") ||
-		of_device_is_compatible(pdev->dev.of_node, "sirf,atlas7-uart"))
+	sirfport->hw_flow_ctrl =
+		of_property_read_bool(np, "sirf,uart-has-rtscts");
+	if (of_device_is_compatible(np, "sirf,prima2-uart") ||
+		of_device_is_compatible(np, "sirf,atlas7-uart"))
 		sirfport->uart_reg->uart_type = SIRF_REAL_UART;
-	if (of_device_is_compatible(pdev->dev.of_node,
-		"sirf,prima2-usp-uart") || of_device_is_compatible(
-		pdev->dev.of_node, "sirf,atlas7-usp-uart")) {
+	if (of_device_is_compatible(np, "sirf,prima2-usp-uart") ||
+	    of_device_is_compatible(np, "sirf,atlas7-usp-uart")) {
 		sirfport->uart_reg->uart_type =	SIRF_USP_UART;
 		if (!sirfport->hw_flow_ctrl)
 			goto usp_no_flow_control;
-		if (of_find_property(pdev->dev.of_node, "cts-gpios", NULL))
-			sirfport->cts_gpio = of_get_named_gpio(
-					pdev->dev.of_node, "cts-gpios", 0);
+		if (of_find_property(np, "cts-gpios", NULL))
+			sirfport->cts_gpio =
+				of_get_named_gpio(np, "cts-gpios", 0);
 		else
 			sirfport->cts_gpio = -1;
-		if (of_find_property(pdev->dev.of_node, "rts-gpios", NULL))
-			sirfport->rts_gpio = of_get_named_gpio(
-					pdev->dev.of_node, "rts-gpios", 0);
+		if (of_find_property(np, "rts-gpios", NULL))
+			sirfport->rts_gpio =
+				of_get_named_gpio(np, "rts-gpios", 0);
 		else
 			sirfport->rts_gpio = -1;
 
@@ -1336,13 +1336,11 @@ static int sirfsoc_uart_probe(struct platform_device *pdev)
 		gpio_direction_output(sirfport->rts_gpio, 1);
 	}
 usp_no_flow_control:
-	if (of_device_is_compatible(pdev->dev.of_node, "sirf,atlas7-uart") ||
-	    of_device_is_compatible(pdev->dev.of_node, "sirf,atlas7-usp-uart"))
+	if (of_device_is_compatible(np, "sirf,atlas7-uart") ||
+	    of_device_is_compatible(np, "sirf,atlas7-usp-uart"))
 		sirfport->is_atlas7 = true;
 
-	if (of_property_read_u32(pdev->dev.of_node,
-			"fifosize",
-			&port->fifosize)) {
+	if (of_property_read_u32(np, "fifosize", &port->fifosize)) {
 		dev_err(&pdev->dev,
 			"Unable to find fifosize in uart node.\n");
 		ret = -EFAULT;
-- 
1.9.1

[PATCH 5/5] serial: sirf: Use generic uart-has-rtscts DT property

[Geert Uytterhoeven]

Convert the SiRF UART driver from using the vendor-specific
"sirf,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as
documented by the Generic Serial DT Bindings.

The old vendor-specific property is still recognized by the driver for
backwards compatibility, but deprecated.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 Documentation/devicetree/bindings/serial/sirf-uart.txt | 8 ++++----
 drivers/tty/serial/sirfsoc_uart.c                      | 3 ++-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/sirf-uart.txt b/Documentation/devicetree/bindings/serial/sirf-uart.txt
index 67e2a0aeb0429572..1e48bbbeecc6dd27 100644
--- a/Documentation/devicetree/bindings/serial/sirf-uart.txt
+++ b/Documentation/devicetree/bindings/serial/sirf-uart.txt
@@ -9,9 +9,9 @@ Required properties:
 - clocks : Should contain uart clock number
 
 Optional properties:
-- sirf,uart-has-rtscts: we have hardware flow controller pins in hardware
-- rts-gpios: RTS pin for USP-based UART if sirf,uart-has-rtscts is true
-- cts-gpios: CTS pin for USP-based UART if sirf,uart-has-rtscts is true
+- uart-has-rtscts: we have hardware flow controller pins in hardware
+- rts-gpios: RTS pin for USP-based UART if uart-has-rtscts is true
+- cts-gpios: CTS pin for USP-based UART if uart-has-rtscts is true
 
 Example:
 
@@ -28,7 +28,7 @@ On the board-specific dts, we can put rts-gpios and cts-gpios like
 
 usp at b0090000 {
 	compatible = "sirf,prima2-usp-uart";
-	sirf,uart-has-rtscts;
+	uart-has-rtscts;
 	rts-gpios = <&gpio 15 0>;
 	cts-gpios = <&gpio 46 0>;
 };
diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
index 1d1c0b9857ff6900..b186c9c4f850cc16 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -1293,7 +1293,8 @@ static int sirfsoc_uart_probe(struct platform_device *pdev)
 	sirfport->uart_reg = (struct sirfsoc_uart_register *)match->data;
 
 	sirfport->hw_flow_ctrl =
-		of_property_read_bool(np, "sirf,uart-has-rtscts");
+		of_property_read_bool(np, "uart-has-rtscts") ||
+		of_property_read_bool(np, "sirf,uart-has-rtscts") /* deprecated */;
 	if (of_device_is_compatible(np, "sirf,prima2-uart") ||
 		of_device_is_compatible(np, "sirf,atlas7-uart"))
 		sirfport->uart_reg->uart_type = SIRF_REAL_UART;
-- 
1.9.1