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

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

On Thu, Nov 27, 2025 at 09:07:10PM +0100, Gerhard Engleder wrote:
> On 27.11.25 20:56, Andy Shevchenko wrote:
> > 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:

...

> > > > 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.
> 
> Yes, PCI subfunctions would have been much nicer, with direct drivers
> and no auxiliary/platform stuff in between. But these were not
> supported by the FPGA vendor.

Unfortunately...

> > > 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?
> 
> Yes, the only changes are bugfixes. The register interface must be kept
> compatible. Like a microcontroller with a firmware which implements an
> USB device.

Got it, thanks for the elaboration on this.

-- 
With Best Regards,
Andy Shevchenko