Hi,
Resending as requested; with EndRun participants removed, as clearly they
have not been interested.
Here's v3 of the outstanding fixes for Oxford Semiconductor 950 UARTs.
As the change for the default FIFO rx trigger level has been already
merged with commit d7aff291d069 ("serial: 8250: Define RX trigger levels
for OxSemi 950 devices") only one patch of the original series remains.
However in the course of preparing v3 of that change I have noticed that
the EndRun device is actually also an OxSemi 952 device in disguise (note
that the OxSemi chips have fully customer-programmable PCI vendor:device
ID values). Therefore it requires a similar fix to the base baud rate as
with commit 6cbe45d8ac93 ("serial: 8250: Correct the clock for OxSemi PCIe
devices"), and also duplicate code can be removed.
I have therefore added a fix for the EndRun device as 1/2 in this version
and the original outstanding change is now 2/2, updated accordingly, also
for a change in the handling of the MCR made with commit b4a29b94804c
("serial: 8250: Move Alpha-specific quirk out of the core").
As noted in the course of v2 review I don't believe the Linux kernel has
a policy for any of its subsystems to require rewriting parts of existing
code to fix bugs or internal API deficiencies as a prerequisite for bug
fix (or even functional improvement) acceptance. Therefore I consider
this v3 of the series final and I am not going to continue pursuing this
submission any further unless there is an actual technical defect (a bug,
a coding style issue, etc.) within this series itself.
Please apply.
Maciej
On Thu, 31 Mar 2022, Maciej W. Rozycki wrote:
> Here's v3 of the outstanding fixes for Oxford Semiconductor 950 UARTs.
> As the change for the default FIFO rx trigger level has been already
> merged with commit d7aff291d069 ("serial: 8250: Define RX trigger levels
> for OxSemi 950 devices") only one patch of the original series remains.
Ping for:
<https://lore.kernel.org/lkml/[email protected]/>
Maciej
On Thu, Apr 14, 2022 at 1:53 AM Maciej W. Rozycki <[email protected]> wrote:
> On Thu, 31 Mar 2022, Maciej W. Rozycki wrote:
>
> > Here's v3 of the outstanding fixes for Oxford Semiconductor 950 UARTs.
> > As the change for the default FIFO rx trigger level has been already
> > merged with commit d7aff291d069 ("serial: 8250: Define RX trigger levels
> > for OxSemi 950 devices") only one patch of the original series remains.
>
> Ping for:
> <https://lore.kernel.org/lkml/[email protected]/>
I still didn't get the answer why BOTHER can't be used instead of
spreading the old hack. You mentioned fractional baud rates and
something else, and I asked why do you need them and from where you
got the limitation of 16-bit values for dividers when using BOTHER.
--
With Best Regards,
Andy Shevchenko
On Thu, 14 Apr 2022, Andy Shevchenko wrote:
> > > Here's v3 of the outstanding fixes for Oxford Semiconductor 950 UARTs.
> > > As the change for the default FIFO rx trigger level has been already
> > > merged with commit d7aff291d069 ("serial: 8250: Define RX trigger levels
> > > for OxSemi 950 devices") only one patch of the original series remains.
> >
> > Ping for:
> > <https://lore.kernel.org/lkml/[email protected]/>
>
> I still didn't get the answer why BOTHER can't be used instead of
> spreading the old hack.
I just fail to see any sense in repeating myself over and over.
> You mentioned fractional baud rates and
> something else, and I asked why do you need them and from where you
> got the limitation of 16-bit values for dividers when using BOTHER.
Sigh, I have documented it there with the original submission 10 months
ago and then repeated with every reiteration:
> Finally the 16-bit UART_DIV_MAX limitation of the baud rate requested
> with `serial8250_get_baud_rate' makes the standard rates of 200bps and
> lower inaccessible in the regular way with the baud base of 15625000.
> That could be avoided by tweaking our 8250 driver core appropriately, but
> I have figured out with modern serial port usage that would not be the
> best use of my time. Someone who does have a real need to use an Oxford
> device at these low rates can step in and make the necessary chances.
To put it shortly: the `spd_cust' feature is out there and it works, and
contrary to what you assert requires no maintenance effort if you just
leave it alone, while the alternative has various shortcomings that do
require effort if they were to be addressed. So please just get over it
and let users choose what suits them best while letting developers focus
on other stuff that keeps waiting. If someone is happy with what BOTHER
offers, then by no means I keep them from using it.
I fail to understand really why a piece of code to correct and improve
broken UART baud rate calculation has to be stuck in limbo for almost a
year. There is nothing wrong with this code and it has a proper change
description and my observation has been that actually broken code often
with half a sentence serving as justification gets accepted with no fuss
all the time. :(
Maciej
On Thu, Apr 14, 2022 at 4:47 PM Maciej W. Rozycki <[email protected]> wrote:
> On Thu, 14 Apr 2022, Andy Shevchenko wrote:
> I fail to understand really why a piece of code to correct and improve
> broken UART baud rate calculation has to be stuck in limbo for almost a
> year. There is nothing wrong with this code and it has a proper change
> description and my observation has been that actually broken code often
> with half a sentence serving as justification gets accepted with no fuss
> all the time. :(
If you remove those 3 or so lines of the code (that are pushing old
SPD_CUST hack) I would be happy to Ack your patches immediately.
Otherwise it's up to maintainers, if they are fine on that. I think
it's a step back advertising something that should have not existed
from day 1.
--
With Best Regards,
Andy Shevchenko