Change in coreboot[master]: soc/intel/common/block/uart: rework to use dummy device

[Michael Niewöhner (Code Review)]

Michael Niewöhner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/48385 )

Change subject: soc/intel/common/block/uart: rework to use dummy device
......................................................................

Patch Set 3:
> Patch Set 3:
> > > > You really should check the history of drivers/wifi/generic, commit d436750 for example...
> > >
> > > Well, the history is one thing. The current code is what
> > > matters however. How about you read that?
> >
> > I did ;) Actually I meant that one change, the wording is just misleading
>
> One major difference in the way UART driver is being handled in this CL and how CNVi device is handled is:
> For CNVi:
> PCI operations are still performed as part of the PCI driver for the CNVi controller
> ACPI operations are performed as part of the chip driver written for the dummy device under CNVi controller
>
> For UART:
> This change performs PCI and ACPI operations on the parent of the dummy device. This does not work for the platforms that do not add the dummy device in devicetree/overridetree.

So, that's actually what I had marked here already, right? https://review.coreboot.org/c/coreboot/+/48385/1/src/soc/intel/common/block/...
> There are other drivers in coreboot that handle this in a similar way. Example: ISH. PCI operations are handled by PCI driver (either default PCI ops or by the special PCI driver provided in soc/intel) and ACPI operations are handled by chip driver implemented as part of src/drivers.
>
> One way to handle the UART situation in a similar way would be to provide only the PCI operations in PCI driver provided by soc/intel/common/block/uart and implement a chip driver in drivers/intel_lpss_uart or something similar that generates the required ACPI tables.
> > Well, if we rework the driver/chip modeling like you proposed, we indeed can get rid of any fake devices. Also I'm not sure if we want to mix "drivers" and "chips" then, because it's not always certain which model needs to be used. Or would we keep chips for real devices then and only use "driver" when the port is the device?
> >
> > Where would we place driver options then?
>
> I would be curious to understand how the new model would work too.