On Fri, 2021-08-20 at 10:02 +0200, Christian Borntraeger wrote: > > On 20.08.21 00:58, Randy Dunlap wrote: > > On 8/16/21 2:41 PM, Jonathan Lemon wrote: > > > On Mon, Aug 16, 2021 at 02:15:51PM -0700, Randy Dunlap wrote: > > > > On 8/16/21 2:09 PM, Jonathan Lemon wrote: > > > > > On Fri, Aug 13, 2021 at 01:30:26PM -0700, Randy Dunlap wrote: > > > > > > There is no 8250 serial on S390. See commit 1598e38c0770. > > > > > > > > > > There's a 8250 serial device on the PCI card. Its been > > > > > ages since I've worked on the architecture, but does S390 > > > > > even support PCI? > > > > > > > > Yes, it does. > > We do support PCI, but only a (very) limited amount of cards. > So there never will be a PCI card with 8250 on s390 and > I also doubt that we will see the "OpenCompute TimeCard" > on s390. > > So in essence the original patch is ok but the patch below > would also be ok for KVM. But it results in a larger kernel > with code that will never be used. So I guess the original > patch is the better choice. It looks to me like the SERIAL_8250 driver can be build as a module so would then not increase the kernel image size or am I missing something? In that case I would vote for the patch below. For PCI on s390 we do intend to, in principle, support arbitrary PCI devices and have already seen cases where non-trivial cards that were never before tested on s390 did "just work" once someone needed them. While I do agree that both 8250 and the Time Card are unlikely to be used on s390 never say never and compile testing a variety of driver code against our PCI primitives is good for quality control. In the end I'm okay with either. > > > > > > > Is this driver useful even without 8250 serial? > > > > > > > > > > The FB timecard has an FPGA that will internally parse the > > > > > GNSS strings and correct the clock, so the PTP clock will > > > > > work even without the serial devices. > > > > > > > > > > However, there are userspace tools which want to read the > > > > > GNSS signal (for holdolver and leap second indication), > > > > > which is why they are exposed. > > > > > > > > So what do you recommend here? > > > > > > Looking at 1598e38c0770, it appears the 8250 console is the > > > problem. Couldn't S390 be fenced by SERIAL_8250_CONSOLE, instead > > > of SERIAL_8250, which would make the 8250 driver available? > > > > OK, that sounds somewhat reasonable. > > > > > For now, just disabling the driver on S390 sounds reasonable. > > > > > > > S390 people, how does this look to you? > > > > This still avoids having serial 8250 console conflicting > > with S390's sclp console. > > (reference commit 1598e38c0770) > > > > > > --- > > drivers/tty/serial/8250/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- linux-next-20210819.orig/drivers/tty/serial/8250/Kconfig > > +++ linux-next-20210819/drivers/tty/serial/8250/Kconfig > > @@ -6,7 +6,6 @@ > > > > config SERIAL_8250 > > tristate "8250/16550 and compatible serial support" > > - depends on !S390 > > select SERIAL_CORE > > select SERIAL_MCTRL_GPIO if GPIOLIB > > help > > @@ -85,6 +84,7 @@ config SERIAL_8250_FINTEK > > config SERIAL_8250_CONSOLE > > bool "Console on 8250/16550 and compatible serial port" > > depends on SERIAL_8250=y > > + depends on !S390 > > select SERIAL_CORE_CONSOLE > > select SERIAL_EARLYCON > > help > > > >
