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/uart/uart.c

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.

View Change

To view, visit change 48385. To unsubscribe, or for help writing mail filters, visit settings.