I only now realized that you stripped the most important
part when quoting me:

What
about all the mainboards that use this driver by properly
matching the PCI IDs?

Maybe you misunderstood. This driver is not only used
via a `chip` entry in the devicetree. It is foremost
used as a usual PCI driver.

    $ git grep 'device pci 1[89e].* on.*UART' src/mainboard/

This says there are at least 120 cases in the tree that
potentially use it and might break due to this change. The
driver would even be used if the device is not mentioned
in the dt at all, it's PCI.

I can't say if this is working, or even if it can work.

I wonder how this one is different from drivers/wifi/generic, which uses the same dummy model?

Except it doesn't? It does not use a generic device below
a PCI device. And it checks the device path so it doesn't
attach PCI ops to a non-PCI device in the first place.

What is this then?

		device pci 14.3 on
			chip drivers/wifi/generic
				register "wake" = "GPE0_PME_B0"
				device generic 0 on end
			end
		end  # CNVi wifi

Sorry, my bad. I didn't realize it's used with two
different topologies. The difference is that the driver
is prepared for that and attaches the CNVi ops only
in case of the generic device. And only then the parent
is queried.

Here, OTOH, you always use the parent, no matter the
topology.

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?

View Change

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