On Wed, Jun 28, 2017 at 09:12:04PM +0000, Ard Biesheuvel wrote:
Well, given how both these drivers are tightly coupled to Cello*, I'd be perfectly happy making them a part of the platform in this case.
Well, they're not really. Sure, that may be the only platform we have in the tree currently using it, but the minnowboard max uses the same Realtek controller (only it currently requires a separate binary driver, and probably actually has a MAC address programmed).
- the renesas driver requires an FV section with a certain GUID to be
present, and this driver depends on a PCD, which in both cases means that the drivers cannot be built in a generic way anyway
Both that GUID and that PCD can live just as happily in an OptionRomPkg/ (or Drivers/) .dec as they can in an OpenPlatformPkg one. Or am I missing something?
True. My point was rather that you can't build this driver from, say, EmbeddedPkg/EmbeddedPkg.dsc in a generic manner, and deploy it as a standalone binary.
Oh, indeed. Hmm. Is there any way to express such a thing? Dummy Pcd dependency or Depex or something?
If we have something that is truly a one-off (or superseded), I agree it makes sense to integrate it into the platform code. But as far as I know, both of those components are still on the market, and some manufacturers still fail to program on-device config areas.
I will let you fight this battle, if you don't mind. I do agree with the reasoning, but it is not something I care deeply about, and I sure as hell don't intend to get involved with other boards that use these parts.
Yeah, this one is mine. I just don't see this kind of thing not happening again (and again), so having a precedent with regards to how we upstream it would be useful.
The devboard market is not cost driven, so it makes no sense whatsoever to get the cheapest variant of the part, like they did with the XHCI controller. And for an on-board PCI NIC, we're better off using a Marvell Yukon like SoftIron did.
/ Leif