On Wed, Mar 27, 2019 at 06:31:19PM +0100, David Müller wrote: > Andy Shevchenko wrote: > > On Wed, Mar 27, 2019 at 05:02:31PM +0100, Hans de Goede wrote: > > > I think that it might be better to restore the CLK_IS_CRITICAL workaround > > > for this, but then only on select boards, based on DMI matching. > > > > > > I've added a bunch of relevant people / lists to the Cc. > > > > > > Andy, Stephen, what is your take on this ? > > > > I'm afraid I forgot all details about that (semi-)famous issue. Though, > > looking > > into your patch against r8169 and taking into account DT practice, it would > > be > > not bad to fix a driver, we have by the way devm_clk_get_optional() now, > > so, it > > would be not a big deal. > > > > > I'm myself starting to believe the DMI based applying of the > > > CLK_IS_CRITICAL workaround is the best solution here. > > > > DMI quirk table tends to grow in mysterious ways. I would prefer in this > > case > > logical solution — if platform has an optional clock, then use it. > > The pmc_plt_clks may also be used for external hardware purposes without > the need for a driver involved. So I'm afraid a fix similar to the r8169 > approach will not suit all needs. Please see > https://www.spinics.net/lists/linux-clk/msg35800.html for details.
Any driver for device which is using PMC clock should take it into consideration. I don't see any issues with patching devices drivers based on case-by-case approach. Is there any other impediment that prevents us to update the driver in question? -- With Best Regards, Andy Shevchenko _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired