On Thu, Mar 28, 2019 at 04:01:37PM +0100, Hans de Goede wrote:
> On 28-03-19 15:58, Andy Shevchenko wrote:
> > On Thu, Mar 28, 2019 at 03:35:58PM +0100, David Müller wrote:
> > > Andy Shevchenko wrote:
> > > > On Wed, Mar 27, 2019 at 06:31:19PM +0100, David Müller wrote:
> > > > > 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 agree that each driver should properly request the clocks and other
> > > resources needed.
> > > 
> > > But what if the PMC clock is used by hardware for which no driver is
> > > being loaded or needed?
> > 
> > Perhaps I didn't get a full picture.
> > 
> > In the original message you referred to igb _driver_ and devices that are 
> > not
> > working properly after resume.
> > 
> > The igb driver patching can fix that, right?
> > 
> > If the driver is not loaded, then the clock is not in use and can be gated,
> > correct?
> > 
> > If there is a connection of this clock to the hardware which is served by
> > firmware, then its firmware's deal, no?
> > 
> > Can you elaborate a bit more the case you are talking about?
> 
> In David's case we are talking about a USB hub which needs a pmc-clk
> (yes really).

OK, this is understandable (what a weird HW design)...

> Also see me other mail I send about this about 5 minutes
> ago.
> 
> David's case is the reason why I believe we need a DMI quirk table; and
> once we have that I think the board with igb ethernet controllers might
> just as well be handled the same way (I already checked it has usable
> DMI identifying info).

But am I right that in the case of igb we will loose power at suspend? Wouldn't
be better to patch the driver?

-- 
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