linux-kernel - Re: [PATCH 0/2] serial: 8250: Let drivers request full 16550A feature probing

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:   Sun, 18 Sep 2022 09:26:39 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Josh Triplett <josh@...htriplett.org>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Anders Blomdell <anders.blomdell@...trol.lth.se>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH 0/2] serial: 8250: Let drivers request full 16550A feature
 probing

On Sat, 17 Sep 2022, Josh Triplett wrote:

> > This small patch series fixes the issue by letting individual device 
> >subdrivers to request full 16550A device feature probing by means of a 
> >flag regardless of the SERIAL_8250_16550A_VARIANTS setting chosen.
> >
> > The changes have been verified with an OXPCIe952 device, in the native 
> >UART mode and a 64-bit RISC-V system as well as in the legacy UART mode 
> >and a 32-bit x86 system.
> 
> Seems reasonable to me, as long as the flag is only set by drivers that 
> know they've found their hardware.

 That has been my intent or otherwise the change would make no sense as 
far as I am concerned.

 In principle for most if not all PCI/e devices we could suppress UART 
probing altogether and still support device's features as we could infer 
the features from the vendor:device ID pair via a table of per-device 
flags.  This might even have worked if we started making one right from 
the beginning as individual devices were added to our 8250/PCI driver.

 Though I can imagine that for some devices no documentation was available 
to the contributor and it could have been hard to determine whether a 
feature actually discovered is really guaranteed for a given vendor:device 
ID or whether there are additional constraints, such as a device revision.  

 I imagine especially early PCI serial port devices may have used discrete 
UART chips behind a piece of PCI glue (just as we now see numerous PCIe 
devices with the actual device placed behind a PCIe-to-PCI bridge onboard) 
and then the set of features could have depended on the specific UART 
chips chosen which may have changed in the course of the life of product.

 At this point however I suspect it would be hard to (re)construct such a 
table and in any case it could have been a maintenance burden, so I guess 
we need to live with what we have.

 Thank you for your input.

  Maciej