| Message ID | 20170627185619.21847-1-ard.biesheuvel@linaro.org |
|---|---|
| Headers | show |
| Series | Platforms/AMD/Cello: implement MAC override | expand |
On Tue, Jun 27, 2017 at 06:56:17PM +0000, Ard Biesheuvel wrote: > Given that we're unlikely to ever see Cellos with the MAC programmed > correctly, implement a driver that programs a MAC in a volatile manner > instead. This still does not allow us to boot from the network, but at > least we no longer have to care about this at the OS level. For OpenPlatformPkg: Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> But ... this does not fit well with the intent for edk2-platforms. So I can't really migrate this across. Hopefully, we can reach some sort of understanding over this sort of not-quite-drivers (like the Renesas USB firmware loader) so that we can get them into edk2. I'll bring it up at the next stewards sync, next week. / Leif > Ard Biesheuvel (2): > Drivers/Net: add MAC override driver for Realtek 8169 > Platforms/AMD/Cello: add Realtek MAC override driver > > Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.c | 262 ++++++++++++++++++++ > Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.inf | 44 ++++ > OpenPlatformPkg.dec | 3 + > Platforms/AMD/Styx/CelloBoard/CelloBoard.dsc | 7 + > Platforms/AMD/Styx/CelloBoard/CelloBoard.fdf | 4 + > 5 files changed, 320 insertions(+) > create mode 100644 Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.c > create mode 100644 Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.inf > > -- > 2.9.3 >
On 27 June 2017 at 19:42, Leif Lindholm <leif.lindholm@linaro.org> wrote: > On Tue, Jun 27, 2017 at 06:56:17PM +0000, Ard Biesheuvel wrote: >> Given that we're unlikely to ever see Cellos with the MAC programmed >> correctly, implement a driver that programs a MAC in a volatile manner >> instead. This still does not allow us to boot from the network, but at >> least we no longer have to care about this at the OS level. > > For OpenPlatformPkg: > Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> > > But ... this does not fit well with the intent for edk2-platforms. > So I can't really migrate this across. > Hopefully, we can reach some sort of understanding over this sort of > not-quite-drivers (like the Renesas USB firmware loader) so that we > can get them into edk2. I'll bring it up at the next stewards sync, > next week. > 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. * 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
On Tue, Jun 27, 2017 at 08:06:58PM +0000, Ard Biesheuvel wrote: > On 27 June 2017 at 19:42, Leif Lindholm <leif.lindholm@linaro.org> wrote: > > On Tue, Jun 27, 2017 at 06:56:17PM +0000, Ard Biesheuvel wrote: > >> Given that we're unlikely to ever see Cellos with the MAC programmed > >> correctly, implement a driver that programs a MAC in a volatile manner > >> instead. This still does not allow us to boot from the network, but at > >> least we no longer have to care about this at the OS level. > > > > For OpenPlatformPkg: > > Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> > > > > But ... this does not fit well with the intent for edk2-platforms. > > So I can't really migrate this across. > > Hopefully, we can reach some sort of understanding over this sort of > > not-quite-drivers (like the Renesas USB firmware loader) so that we > > can get them into edk2. I'll bring it up at the next stewards sync, > > next week. > > 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? 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. / Leif
On 28 June 2017 at 13:24, Leif Lindholm <leif.lindholm@linaro.org> wrote: > On Tue, Jun 27, 2017 at 08:06:58PM +0000, Ard Biesheuvel wrote: >> On 27 June 2017 at 19:42, Leif Lindholm <leif.lindholm@linaro.org> wrote: >> > On Tue, Jun 27, 2017 at 06:56:17PM +0000, Ard Biesheuvel wrote: >> >> Given that we're unlikely to ever see Cellos with the MAC programmed >> >> correctly, implement a driver that programs a MAC in a volatile manner >> >> instead. This still does not allow us to boot from the network, but at >> >> least we no longer have to care about this at the OS level. >> > >> > For OpenPlatformPkg: >> > Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> >> > >> > But ... this does not fit well with the intent for edk2-platforms. >> > So I can't really migrate this across. >> > Hopefully, we can reach some sort of understanding over this sort of >> > not-quite-drivers (like the Renesas USB firmware loader) so that we >> > can get them into edk2. I'll bring it up at the next stewards sync, >> > next week. >> >> 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. > 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. 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.
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
On 28 June 2017 at 21:48, Leif Lindholm <leif.lindholm@linaro.org> wrote: > 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? > I don't think so. PCDs simply assume their default values if the DSC does not specify a value for them. >> > 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