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

Reply via email to