Re: [PATCH v2 0/2] serial: add KEBA UART driver

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Thu, Nov 27, 2025 at 08:26:13PM +0100, Gerhard Engleder wrote:
> On 27.11.25 17:05, Andy Shevchenko wrote:
> > On Fri, Oct 17, 2025 at 04:42:07PM +0200, Gerhard Engleder wrote:
> > > First the serial subsystem is prepared to keep rs485 settings from the
> > > driver if no firmware node exists. This enables drivers to configure a
> > > default rs485 mode, which is set by the serial subsystem.
> > > 
> > > Second the driver for the KEBA UART is added. This driver supports
> > > multiple rs485 modes and selects RS485 as default mode. This UART is
> > > found in KEBA PLC devices. The auxiliary devices for this driver are
> > > created by the cp500 driver.
> > 
> > I just realised (thanks, Lukas!) that this is for some kind of FPGA which makes
> > even bigger question here.
> > 
> > First of all, we have the FPGA framework, which handles (re-)configurations of
> > FPGAs. Second, why do you need a new driver when we have already one, i.e.
> > 8250_dfl that follows some kind of standards?
> 
> Yes, there is FPGA framework, which handles FPGA re-configuration.
> There is no FPGA re-configuration in the driver and neither in the
> system. The FPGA does not even support re-configuration. The FPGA is
> just a variant to implement a PCIe target. The FPGA loads its
> configuration on power up once from flash before the BIOS starts. So
> the operating system does not need to know that it is an FPGA. It is
> just a PCIe target.
> 
> Why not 8250_dfl? Because this is a driver for a different IP core.
> The UART is no Altera/Intel or AMD/Xilinx IP core. It is a KEBA
> IP core and the 8250_keba driver only implements feature added by
> KEBA. The rest is 8250 and uses the 8250 infrastructure.
> 
> > Third, the expect approach is to see DT overlay provided along with the FPGA
> > configuration. So, basically your cp500.c should not have been existed to begin
> > with.
> 
> Like first, it is just a PCIe target and this PCIe target is divided
> into auxiliary devices, which was suggested by gregkh. Initially I
> divided it into platform devices, but the suggestion of gregkh is a
> better fit. It is a single PCIe target, which consists of multiple
> logical devices with its own registers and interrupts. This logical
> devices are then separated by auxiliary devices.

This is implementation detail in Linux, but in HW why are those not a proper
PCI endpoints / functions? With that done, the drivers can be just normal
PCI device drivers.

> 3 years ago Intel was not able to deliver enough FPGAs. With just being
> a PCIe target, it was possible to switch the FPGA vendor without
> touching the software in the field. With Linux re-configuring the FPGA
> that would not have been possible. So re-configuring FPGAs during
> runtime is something that should be only used if needed.
> 
> > Can you elaborate on these considerations?
> 
> I hope you get a better impression what this is about. For the drivers
> it is not relevant that the device is FPGA based.

Yes, so it's rather something with a custom FW that is not supposed to be
changed (at least from the device hierarchy / functionality perspective),
or very little from version to version. Is this a correct summary?

-- 
With Best Regards,
Andy Shevchenko