<div dir="auto"><div>The purpose of this driver is to allow manipulation of the UART routing at runtime. Setting the routing in the DTS would obviously not allow that.</div><div dir="auto"><br></div><div dir="auto">From what I remember, I used am existing unrelated driver as template. Apologies for using the wrong APIs - I literally just followed what I had seen elsewhere.</div><div dir="auto"><br></div><div dir="auto">Since posting this driver, we found that while it solved our initial use case, that use case has evolved. We're now using Aspeed's VUART where bytes are routed "manually" (i.e. copied between devices) rather than in hardware. So I don't need this driver anymore.</div><div dir="auto"><br></div><div dir="auto">If it's still useful to anyone, please take ownership and modify it as needed to be able to submit it. I'm still happy to keep an eye on it and help explain its purpose.</div><div dir="auto"><br></div><div dir="auto">Oskar.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Dec 10, 2020, 5:28 AM Greg Kroah-Hartman <<a href="mailto:gregkh@linuxfoundation.org" target="_blank" rel="noreferrer">gregkh@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Dec 10, 2020 at 06:06:59PM +0800, John Wang wrote:<br>
> On Thu, Dec 10, 2020 at 5:42 PM Greg Kroah-Hartman<br>
> <<a href="mailto:gregkh@linuxfoundation.org" rel="noreferrer noreferrer" target="_blank">gregkh@linuxfoundation.org</a>> wrote:<br>
> ><br>
> > On Thu, Dec 10, 2020 at 05:28:53PM +0800, John Wang wrote:<br>
> > > From: Oskar Senft <<a href="mailto:osk@google.com" rel="noreferrer noreferrer" target="_blank">osk@google.com</a>><br>
> > ><br>
> > > This driver adds sysfs files that allow the BMC userspace to configure<br>
> > > how UARTs and physical serial I/O ports are routed.<br>
> > ><br>
> > > Tested: Checked correct behavior (both read & write) on TYAN S7106<br>
> > > board by manually changing routing settings and confirming that bits<br>
> > > flow as expected. Tested for UART1 and UART3 as this board doesn't have<br>
> > > the other UARTs wired up in a testable way.<br>
> > ><br>
> > > Signed-off-by: Oskar Senft <<a href="mailto:osk@google.com" rel="noreferrer noreferrer" target="_blank">osk@google.com</a>><br>
> > > Signed-off-by: Yong Li <<a href="mailto:yong.b.li@linux.intel.com" rel="noreferrer noreferrer" target="_blank">yong.b.li@linux.intel.com</a>><br>
> > > Signed-off-by: Vernon Mauery <<a href="mailto:vernon.mauery@linux.intel.com" rel="noreferrer noreferrer" target="_blank">vernon.mauery@linux.intel.com</a>><br>
> > > Signed-off-by: John Wang <<a href="mailto:wangzhiqiang.bj@bytedance.com" rel="noreferrer noreferrer" target="_blank">wangzhiqiang.bj@bytedance.com</a>><br>
> > > ---<br>
> > > .../stable/sysfs-driver-aspeed-uart-routing | 14 +<br>
> > > .../misc-devices/aspeed-uart-routing.txt | 49 +++<br>
> > > drivers/misc/Kconfig | 6 +<br>
> > > drivers/misc/Makefile | 1 +<br>
> > > drivers/misc/aspeed-uart-routing.c | 383 ++++++++++++++++++<br>
> > > 5 files changed, 453 insertions(+)<br>
> > > create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-uart-routing<br>
> > > create mode 100644 Documentation/misc-devices/aspeed-uart-routing.txt<br>
> > > create mode 100644 drivers/misc/aspeed-uart-routing.c<br>
> > ><br>
> > > diff --git a/Documentation/ABI/stable/sysfs-driver-aspeed-uart-routing b/Documentation/ABI/stable/sysfs-driver-aspeed-uart-routing<br>
> > > new file mode 100644<br>
> > > index 000000000000..5068737d9c12<br>
> > > --- /dev/null<br>
> > > +++ b/Documentation/ABI/stable/sysfs-driver-aspeed-uart-routing<br>
> > > @@ -0,0 +1,14 @@<br>
> > > +What: /sys/bus/platform/drivers/aspeed-uart-routing/*/io*<br>
> > > +Date: August 2018<br>
> > > +Contact: Oskar Senft <<a href="mailto:osk@google.com" rel="noreferrer noreferrer" target="_blank">osk@google.com</a>><br>
> > > +Description: Configures the input source for the specific physical<br>
> > > + serial I/O port.<br>
> > > +Users: OpenBMC. Proposed changes should be mailed to<br>
> > > + <a href="mailto:openbmc@lists.ozlabs.org" rel="noreferrer noreferrer" target="_blank">openbmc@lists.ozlabs.org</a><br>
> > > +<br>
> > > +What: /sys/bus/platform/drivers/aspeed-uart-routing/*/uart*<br>
> > > +Date: August 2018<br>
> > > +Contact: Oskar Senft <<a href="mailto:osk@google.com" rel="noreferrer noreferrer" target="_blank">osk@google.com</a>><br>
> > > +Description: Configures the input source for the specific UART.<br>
> > > +Users: OpenBMC. Proposed changes should be mailed to<br>
> > > + <a href="mailto:openbmc@lists.ozlabs.org" rel="noreferrer noreferrer" target="_blank">openbmc@lists.ozlabs.org</a><br>
> > > diff --git a/Documentation/misc-devices/aspeed-uart-routing.txt b/Documentation/misc-devices/aspeed-uart-routing.txt<br>
> > > new file mode 100644<br>
> > > index 000000000000..cf1c2a466875<br>
> > > --- /dev/null<br>
> > > +++ b/Documentation/misc-devices/aspeed-uart-routing.txt<br>
> > > @@ -0,0 +1,49 @@<br>
> > > +Kernel driver aspeed-uart-routing<br>
> > > +=================================<br>
> > > +<br>
> > > +Supported chips:<br>
> > > +ASPEED AST2500/AST2600<br>
> > > +<br>
> > > +Author:<br>
> > > +Google LLC<br>
> > > +<br>
> > > +Description<br>
> > > +-----------<br>
> > > +<br>
> > > +The Aspeed AST2500/AST2600 allows to dynamically route the inputs for the<br>
> > > +built-in UARTS and physical serial I/O ports.<br>
> > > +<br>
> > > +This allows, for example, to connect the output of UART to another UART.<br>
> > > +This can be used to enable host<->BMC communication via UARTs, e.g. to allow<br>
> > > +access to the host's serial console.<br>
> > > +<br>
> > > +This driver is for the BMC side. The sysfs files allow the BMC userspace<br>
> > > +which owns the system configuration policy, to configure how UARTs and<br>
> > > +physical serial I/O ports are routed.<br>
> > > +<br>
> > > +The driver provides the following files in sysfs:<br>
> > > +uart1 Configure the input signal to UART1.<br>
> > > +uart2 Configure the input signal to UART2.<br>
> > > +uart3 Configure the input signal to UART3.<br>
> > > +uart4 Configure the input signal to UART4.<br>
> > > +uart5 Configure the input signal to UART5.<br>
> > > +io1 Configure the input signal to physical serial port 1.<br>
> > > +io2 Configure the input signal to physical serial port 2.<br>
> > > +io3 Configure the input signal to physical serial port 3.<br>
> > > +io4 Configure the input signal to physical serial port 4.<br>
> > > +io5 Configure the input signal to physical serial port 5.<br>
> > > +<br>
> > > +When read, each file shows the list of available options with the currently<br>
> > > +selected option marked by square brackets "[]". The list of available options<br>
> > > +depends on the selected file.<br>
> > > +<br>
> > > +Example:<br>
> > > +$ cat /sys/bus/platform/drivers/aspeed-uart-routing/*.uart_routing/uart1<br>
> > > +[io1] io2 io3 io4 uart2 uart3 uart4 io6<br>
> > > +<br>
> > > +In this case, UART1 gets its input signal from IO1 (physical serial port 1).<br>
> > > +<br>
> > > +$ echo -n "uart3" \<br>
> > > + >/sys/bus/platform/drivers/aspeed-uart-routing/*.uart_routing/uart1<br>
> > > +$ cat /sys/bus/platform/drivers/aspeed-uart-routing/*.uart_routing/uart1<br>
> > > +io1 io2 io3 io4 uart2 [uart3] uart4 io6<br>
> ><br>
> > Are you sure there are no other ways to configure this type of thing,<br>
> > than to a driver-specific sysfs file?<br>
> <br>
> I think this is good. but what's your suggestion?<br>
<br>
I do not know, but isn't this normally handled in a dts file? Why must<br>
it be done "on the fly" like this?<br>
<br>
> If I use a driver-specific sysfs and modify the code based on the<br>
> comments, is this a good direction to go?<br>
<br>
That's what you are trying to do here, and is why I am objecting to it<br>
:)<br>
<br>
thanks,<br>
<br>
greg k-h<br>
</blockquote></div></div></div>