Current Samsung UART driver relies on probe order of particular
samsung-uart instances, which makes it impossible to get proper
initialization of ports when not all ports are available on board,
not even saying of deterministic device naming.
This series intends to fix this situation by adding support to parse
aliases from device tree and use them to assign instance IDs to
particular port instances.
Tested on Exynos4412-based Trats2 board:
1) without patch 3/3 adding aliases,
2) with patch 3/3 with all UART ports enabled,
3) with patch 3/3 with selected UART ports disabled.
Tomasz Figa (3):
Documentation: devicetree: Update samsung UART bindings
serial: samsung: Consider DT alias when probing ports
ARM: dts: SAMSUNG: Add aliases of UART nodes
.../devicetree/bindings/serial/samsung_uart.txt | 52 +++++++++++++++++++---
arch/arm/boot/dts/exynos3250.dtsi | 2 +
arch/arm/boot/dts/exynos4.dtsi | 12 +++--
arch/arm/boot/dts/exynos5.dtsi | 15 +++++--
arch/arm/boot/dts/exynos5260.dtsi | 4 ++
arch/arm/boot/dts/exynos5410.dtsi | 6 +++
arch/arm/boot/dts/exynos5440.dtsi | 6 ++-
arch/arm/boot/dts/s3c2416.dtsi | 6 ++-
arch/arm/boot/dts/s3c24xx.dtsi | 9 ++--
arch/arm/boot/dts/s3c64xx.dtsi | 4 ++
drivers/tty/serial/samsung.c | 13 ++++--
11 files changed, 106 insertions(+), 23 deletions(-)
--
1.9.3
Current driver code relies on probe order of particular samsung-uart
instances, which makes it impossible to get proper initialization of
ports when not all ports are available on board, not even saying of
deterministic device naming.
This patch fixes this on DT-enabled systems by using DT aliases for
ports as instance ID, if specified, or falling back to legacy method
otherwise to provide backwards compatibility.
Signed-off-by: Tomasz Figa <[email protected]>
---
drivers/tty/serial/samsung.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index c1d3ebd..a9bf024 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1275,11 +1275,18 @@ static inline struct s3c24xx_serial_drv_data *s3c24xx_get_driver_data(
static int s3c24xx_serial_probe(struct platform_device *pdev)
{
struct s3c24xx_uart_port *ourport;
+ int index = probe_index;
int ret;
- dbg("s3c24xx_serial_probe(%p) %d\n", pdev, probe_index);
+ if (pdev->dev.of_node) {
+ ret = of_alias_get_id(pdev->dev.of_node, "serial");
+ if (ret >= 0)
+ index = ret;
+ }
+
+ dbg("s3c24xx_serial_probe(%p) %d\n", pdev, index);
- ourport = &s3c24xx_serial_ports[probe_index];
+ ourport = &s3c24xx_serial_ports[index];
ourport->drv_data = s3c24xx_get_driver_data(pdev);
if (!ourport->drv_data) {
@@ -1295,7 +1302,7 @@ static int s3c24xx_serial_probe(struct platform_device *pdev)
ourport->port.fifosize = (ourport->info->fifosize) ?
ourport->info->fifosize :
- ourport->drv_data->fifosize[probe_index];
+ ourport->drv_data->fifosize[index];
probe_index++;
--
1.9.3
The primary purpose of this patch is to add information about (now
required) aliases of UART ports. However the documentation currently is
heavily outdated and so this patch also takes care of this.
Signed-off-by: Tomasz Figa <[email protected]>
---
.../devicetree/bindings/serial/samsung_uart.txt | 52 +++++++++++++++++++---
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.txt b/Documentation/devicetree/bindings/serial/samsung_uart.txt
index 2c8a17c..85e8ee2 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.txt
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.txt
@@ -1,14 +1,54 @@
* Samsung's UART Controller
-The Samsung's UART controller is used for interfacing SoC with serial communicaion
-devices.
+The Samsung's UART controller is used for interfacing SoC with serial
+communicaion devices.
Required properties:
-- compatible: should be
- - "samsung,exynos4210-uart", for UART's compatible with Exynos4210 uart ports.
+- compatible: should be one of following:
+ - "samsung,exynos4210-uart" - Exynos4210 SoC,
+ - "samsung,s3c2410-uart" - compatible with ports present on S3C2410 SoC,
+ - "samsung,s3c2412-uart" - compatible with ports present on S3C2412 SoC,
+ - "samsung,s3c2440-uart" - compatible with ports present on S3C2440 SoC,
+ - "samsung,s3c6400-uart" - compatible with ports present on S3C6400 SoC,
+ - "samsung,s5pv210-uart" - compatible with ports present on S5PV210 SoC.
- reg: base physical address of the controller and length of memory mapped
region.
-- interrupts: interrupt number to the cpu. The interrupt specifier format depends
- on the interrupt controller parent.
+- interrupts: a single interrupt signal to SoC interrupt controller,
+ according to interrupt bindings documentation [1].
+
+- clock-names: input names of clocks used by the controller:
+ - "uart" - controller bus clock,
+ - "clk_uart_baudN" - Nth baud base clock input (N = 0, 1, ...),
+ according to SoC User's Manual (only N = 0 is allowedfor SoCs without
+ internal baud clock mux).
+- clocks: phandles and specifiers for all clocks specified in "clock-names"
+ property, in the same order, according to clock bindings documentation [2].
+
+[1] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Note: Each Samsung UART should have an alias correctly numbered in the
+"aliases" node, according to serialN format, where N is the port number
+(non-negative decimal integer) as specified by User's Manual of respective
+SoC.
+
+Example:
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ };
+
+Example:
+ uart1: serial@7f005400 {
+ compatible = "samsung,s3c6400-uart";
+ reg = <0x7f005400 0x100>;
+ interrupt-parent = <&vic1>;
+ interrupts = <6>;
+ clock-names = "uart", "clk_uart_baud2",
+ "clk_uart_baud3";
+ clocks = <&clocks PCLK_UART1>, <&clocks PCLK_UART1>,
+ <&clocks SCLK_UART>;
+ };
--
1.9.3
This patch adds alias entries for UART nodes of all SoCs using
samsung-uart compatible UART controllers, so that the dependency on
probe order is removed and deterministic device naming is assured.
Signed-off-by: Tomasz Figa <[email protected]>
---
arch/arm/boot/dts/exynos3250.dtsi | 2 ++
arch/arm/boot/dts/exynos4.dtsi | 12 ++++++++----
arch/arm/boot/dts/exynos5.dtsi | 15 +++++++++++----
arch/arm/boot/dts/exynos5260.dtsi | 4 ++++
arch/arm/boot/dts/exynos5410.dtsi | 6 ++++++
arch/arm/boot/dts/exynos5440.dtsi | 6 ++++--
arch/arm/boot/dts/s3c2416.dtsi | 6 +++++-
arch/arm/boot/dts/s3c24xx.dtsi | 9 ++++++---
arch/arm/boot/dts/s3c64xx.dtsi | 4 ++++
9 files changed, 50 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 3e678fa..f4b5411 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -39,6 +39,8 @@
i2c5 = &i2c_5;
i2c6 = &i2c_6;
i2c7 = &i2c_7;
+ serial0 = &serial_0;
+ serial1 = &serial_1;
};
cpus {
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index fbaf426..536d3c3 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -44,6 +44,10 @@
fimc1 = &fimc_1;
fimc2 = &fimc_2;
fimc3 = &fimc_3;
+ serial0 = &serial_0;
+ serial1 = &serial_1;
+ serial2 = &serial_2;
+ serial3 = &serial_3;
};
clock_audss: clock-controller@03810000 {
@@ -363,7 +367,7 @@
status = "disabled";
};
- serial@13800000 {
+ serial_0: serial@13800000 {
compatible = "samsung,exynos4210-uart";
reg = <0x13800000 0x100>;
interrupts = <0 52 0>;
@@ -372,7 +376,7 @@
status = "disabled";
};
- serial@13810000 {
+ serial_1: serial@13810000 {
compatible = "samsung,exynos4210-uart";
reg = <0x13810000 0x100>;
interrupts = <0 53 0>;
@@ -381,7 +385,7 @@
status = "disabled";
};
- serial@13820000 {
+ serial_2: serial@13820000 {
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
@@ -390,7 +394,7 @@
status = "disabled";
};
- serial@13830000 {
+ serial_3: serial@13830000 {
compatible = "samsung,exynos4210-uart";
reg = <0x13830000 0x100>;
interrupts = <0 55 0>;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608..ff2d2cb 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -18,6 +18,13 @@
/ {
interrupt-parent = <&gic>;
+ aliases {
+ serial0 = &serial_0;
+ serial1 = &serial_1;
+ serial2 = &serial_2;
+ serial3 = &serial_3;
+ };
+
chipid@10000000 {
compatible = "samsung,exynos4210-chipid";
reg = <0x10000000 0x100>;
@@ -50,25 +57,25 @@
interrupts = <1 9 0xf04>;
};
- serial@12C00000 {
+ serial_0: serial@12C00000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <0 51 0>;
};
- serial@12C10000 {
+ serial_1: serial@12C10000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C10000 0x100>;
interrupts = <0 52 0>;
};
- serial@12C20000 {
+ serial_2: serial@12C20000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C20000 0x100>;
interrupts = <0 53 0>;
};
- serial@12C30000 {
+ serial_3: serial@12C30000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C30000 0x100>;
interrupts = <0 54 0>;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
index 5398a60..4539a0a 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -21,6 +21,10 @@
pinctrl0 = &pinctrl_0;
pinctrl1 = &pinctrl_1;
pinctrl2 = &pinctrl_2;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
};
cpus {
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index 3839c26..52070e5 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -20,6 +20,12 @@
compatible = "samsung,exynos5410", "samsung,exynos5";
interrupt-parent = <&gic>;
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index ae3a17c..8f3373c 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -18,6 +18,8 @@
interrupt-parent = <&gic>;
aliases {
+ serial0 = &serial_0;
+ serial1 = &serial_1;
spi0 = &spi_0;
tmuctrl0 = &tmuctrl_0;
tmuctrl1 = &tmuctrl_1;
@@ -102,7 +104,7 @@
>;
};
- serial@B0000 {
+ serial_0: serial@B0000 {
compatible = "samsung,exynos4210-uart";
reg = <0xB0000 0x1000>;
interrupts = <0 2 0>;
@@ -110,7 +112,7 @@
clock-names = "uart", "clk_uart_baud0";
};
- serial@C0000 {
+ serial_1: serial@C0000 {
compatible = "samsung,exynos4210-uart";
reg = <0xC0000 0x1000>;
interrupts = <0 3 0>;
diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
index 955e4a4..30b8f7e 100644
--- a/arch/arm/boot/dts/s3c2416.dtsi
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -16,6 +16,10 @@
model = "Samsung S3C2416 SoC";
compatible = "samsung,s3c2416";
+ aliases {
+ serial3 = &uart3;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -68,7 +72,7 @@
<&clocks SCLK_UART>;
};
- serial@5000C000 {
+ uart3: serial@5000C000 {
compatible = "samsung,s3c2440-uart";
reg = <0x5000C000 0x4000>;
interrupts = <1 18 24 4>, <1 18 25 4>;
diff --git a/arch/arm/boot/dts/s3c24xx.dtsi b/arch/arm/boot/dts/s3c24xx.dtsi
index 2d1d7dc..5ed43b8 100644
--- a/arch/arm/boot/dts/s3c24xx.dtsi
+++ b/arch/arm/boot/dts/s3c24xx.dtsi
@@ -16,6 +16,9 @@
aliases {
pinctrl0 = &pinctrl_0;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
};
intc:interrupt-controller@4a000000 {
@@ -46,21 +49,21 @@
#pwm-cells = <4>;
};
- serial@50000000 {
+ uart0: serial@50000000 {
compatible = "samsung,s3c2410-uart";
reg = <0x50000000 0x4000>;
interrupts = <1 28 0 4>, <1 28 1 4>;
status = "disabled";
};
- serial@50004000 {
+ uart1: serial@50004000 {
compatible = "samsung,s3c2410-uart";
reg = <0x50004000 0x4000>;
interrupts = <1 23 3 4>, <1 23 4 4>;
status = "disabled";
};
- serial@50008000 {
+ uart2: serial@50008000 {
compatible = "samsung,s3c2410-uart";
reg = <0x50008000 0x4000>;
interrupts = <1 15 6 4>, <1 15 7 4>;
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
index 4e3be4d..ff5bdaa 100644
--- a/arch/arm/boot/dts/s3c64xx.dtsi
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -23,6 +23,10 @@
aliases {
i2c0 = &i2c0;
pinctrl0 = &pinctrl0;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
};
cpus {
--
1.9.3
On Thu, Jun 26, 2014 at 01:24:32PM +0200, Tomasz Figa wrote:
> Current Samsung UART driver relies on probe order of particular
> samsung-uart instances, which makes it impossible to get proper
> initialization of ports when not all ports are available on board,
> not even saying of deterministic device naming.
>
> This series intends to fix this situation by adding support to parse
> aliases from device tree and use them to assign instance IDs to
> particular port instances.
How about instead exporting the path/id information so that userspace
can create /dev/serial/by-{path,id}/... for internal devices instead?
The problem you're raising is very much the same problem you have when
there are multiple USB serial devices connected to the machine - you
just get a bunch of /dev/ttyUSB* devices which are unordered (they can
change on each boot, or change order if you disconnect and reconnect
them.)
/dev/serial/by-{path,id}/ allows for a much more stable path.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
On 26.06.2014 13:39, Russell King - ARM Linux wrote:
> On Thu, Jun 26, 2014 at 01:24:32PM +0200, Tomasz Figa wrote:
>> Current Samsung UART driver relies on probe order of particular
>> samsung-uart instances, which makes it impossible to get proper
>> initialization of ports when not all ports are available on board,
>> not even saying of deterministic device naming.
>>
>> This series intends to fix this situation by adding support to parse
>> aliases from device tree and use them to assign instance IDs to
>> particular port instances.
>
> How about instead exporting the path/id information so that userspace
> can create /dev/serial/by-{path,id}/... for internal devices instead?
>
> The problem you're raising is very much the same problem you have when
> there are multiple USB serial devices connected to the machine - you
> just get a bunch of /dev/ttyUSB* devices which are unordered (they can
> change on each boot, or change order if you disconnect and reconnect
> them.)
>
> /dev/serial/by-{path,id}/ allows for a much more stable path.
>
The problem being solved has slightly different constraints than the one
with USB serials you mentioned:
- basically Samsung UART already has its own namespace (ttySAC) and the
order inside it is well-defined - instance ID shall be the hardware
instance number as specified by documentation. The ports vary in certain
aspects and the ID is important knowledge of the driver. The problem
here was broken implementation of assigning IDs based on probe order,
which worked only because on all Exynos platforms all ports have been
always registered (which we want to change now and keep unused ones
"disabled" in DT),
- we already have a lot of userspace depending on the aforementioned
ttySAC namespace and proper ordering of instances there. While I believe
the proper solution as of today would be to go back to standard ttyS
namespace and make userspace use a smarter way of identifying the
instances (e.g. by path or id, as you suggested), I don't think this
will make anyone's life easier with current assumptions,
- correct me if I'm wrong, but I don't think the
/dev/serial/by-{path,id} would be handled in kernel's console= parameter.
Best regards,
Tomasz
Hi,
How can we move forward here?
On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa <[email protected]> wrote:
> - basically Samsung UART already has its own namespace (ttySAC) and the
> order inside it is well-defined - instance ID shall be the hardware
> instance number as specified by documentation. The ports vary in certain
> aspects and the ID is important knowledge of the driver. The problem
> here was broken implementation of assigning IDs based on probe order,
> which worked only because on all Exynos platforms all ports have been
> always registered (which we want to change now and keep unused ones
> "disabled" in DT),
Yes, the kernel help text documents this quite well:
config SERIAL_SAMSUNG
tristate "Samsung SoC serial support"
depends on PLAT_SAMSUNG
select SERIAL_CORE
help
Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
providing /dev/ttySAC0, 1 and 2 (note, some machines may not
provide all of these ports, depending on how the serial port
pins are configured.
> - we already have a lot of userspace depending on the aforementioned
> ttySAC namespace and proper ordering of instances there. While I believe
> the proper solution as of today would be to go back to standard ttyS
> namespace and make userspace use a smarter way of identifying the
> instances (e.g. by path or id, as you suggested), I don't think this
> will make anyone's life easier with current assumptions,
I like the sound of going to the standard ttyS notation and only
providing ports for ones that exist, but is this userspace-visible
naming change OK? You could argue that userspace that relies on fixed
device paths is a bit broken, but that argument would be a bit cloudy
given the kernel documentation for the ttySAC devices above.
> - correct me if I'm wrong, but I don't think the
> /dev/serial/by-{path,id} would be handled in kernel's console= parameter.
That's right, that problem is left to the user, but at least we'd be
consistent with other SoCs (and open to generic solutions to that
inconvenience).
Daniel
On 08.07.2014 10:32, Daniel Drake wrote:
> Hi,
>
> How can we move forward here?
Greg, Jiri, what do you think?
>
> On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa <[email protected]> wrote:
>> - basically Samsung UART already has its own namespace (ttySAC) and the
>> order inside it is well-defined - instance ID shall be the hardware
>> instance number as specified by documentation. The ports vary in certain
>> aspects and the ID is important knowledge of the driver. The problem
>> here was broken implementation of assigning IDs based on probe order,
>> which worked only because on all Exynos platforms all ports have been
>> always registered (which we want to change now and keep unused ones
>> "disabled" in DT),
>
> Yes, the kernel help text documents this quite well:
>
> config SERIAL_SAMSUNG
> tristate "Samsung SoC serial support"
> depends on PLAT_SAMSUNG
> select SERIAL_CORE
> help
> Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
> providing /dev/ttySAC0, 1 and 2 (note, some machines may not
> provide all of these ports, depending on how the serial port
> pins are configured.
>
>> - we already have a lot of userspace depending on the aforementioned
>> ttySAC namespace and proper ordering of instances there. While I believe
>> the proper solution as of today would be to go back to standard ttyS
>> namespace and make userspace use a smarter way of identifying the
>> instances (e.g. by path or id, as you suggested), I don't think this
>> will make anyone's life easier with current assumptions,
>
> I like the sound of going to the standard ttyS notation and only
> providing ports for ones that exist, but is this userspace-visible
> naming change OK? You could argue that userspace that relies on fixed
> device paths is a bit broken, but that argument would be a bit cloudy
> given the kernel documentation for the ttySAC devices above.
I'd say such argument would be completely invalid as this is most likely
almost all of the userspace for Samsung SoCs and, in addition to this,
quite a lot of firmware which pass console=ttySACx through command line.
>
>> - correct me if I'm wrong, but I don't think the
>> /dev/serial/by-{path,id} would be handled in kernel's console= parameter.
>
> That's right, that problem is left to the user, but at least we'd be
> consistent with other SoCs (and open to generic solutions to that
> inconvenience).
And so the point of this series is to make this no longer be left to the
user, making hardware UART 2 always UART 2 (which is supposed to be the
current behavior, but not always due to broken implementation) which is
completely orthogonal to raised issues.
Regardless of whether we stick to ttySAC or move back to ttyS, we still
need a deterministic way to assign the ID (even for internal driver
purposes) and that's why this series adds parsing of aliases. No user
visible behavior should be changed by this series.
Best regards,
Tomasz
> I like the sound of going to the standard ttyS notation and only
> providing ports for ones that exist, but is this userspace-visible
ttyS is 8250 compatible UARTS.
If the Samsung is not an 8250 compatible UART then it doesn't belong as
ttyS from the kernel perspective.
How your udev handles it is up to you.
Alan
On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes
<[email protected]> wrote:
>> I like the sound of going to the standard ttyS notation and only
>> providing ports for ones that exist, but is this userspace-visible
>
> ttyS is 8250 compatible UARTS.
>
> If the Samsung is not an 8250 compatible UART then it doesn't belong as
> ttyS from the kernel perspective.
OK, thanks for pointing that out.
So we stick with the ttySAC namespace. And by doing that, and sticking
to the existing and documented behaviour, it seems like we have
already addressed Russells's concern:
> The problem you're raising is very much the same problem you have when
> there are multiple USB serial devices connected to the machine - you
> just get a bunch of /dev/ttyUSB* devices which are unordered (they can
> change on each boot, or change order if you disconnect and reconnect
> them.)
In this case, we have a dedicated namespace and the path information
is already fully encoded in the device name. The order and number of
ports are fixed, they can't be disconnected and reconnected. There is
no real risk of an additional serial controller driver coming to play
in the ttySAC namespace.
So I think Tomasz's approach is good - although I haven't looked at
the code in detail.
Thanks
Daniel