Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 12 Feb 2022 08:41:48 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@orcam.me.uk>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>
cc:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Mike Skoog <mskoog@endruntechnologies.com>,
        Mike Korreng <mkorreng@endruntechnologies.com>,
        info@endruntechnologies.com, linux-serial@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/2] serial: 8250: Fixes for Oxford Semiconductor 950
 UARTs
Message-ID: <alpine.DEB.2.21.2202100424280.34636@angie.orcam.me.uk>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

Hi,

 Cc-ing the general contact point at EndRun for 1/2 of this series in case 
the original submitters of the affected code are not there anymore after 
those 7 years.

 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