lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 20 Aug 2021 10:02:24 +0200
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Randy Dunlap <rdunlap@...radead.org>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Hendrik Brueckner <brueckner@...ux.vnet.ibm.com>,
        linux-s390 <linux-s390@...r.kernel.org>
Cc:     netdev@...r.kernel.org, Richard Cochran <richardcochran@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] ptp: ocp: don't allow on S390



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.

>>>
>>>>> 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
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ