Hi,
On 3/28/19 4:49 PM, Andy Shevchenko wrote:
On Thu, Mar 28, 2019 at 04:32:27PM +0100, Hans de Goede wrote:
On 28-03-19 16:24, Andy Shevchenko wrote:
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:
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.
Can you elaborate a bit more the case you are talking about?
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?
This is an industrial embedded PC, so it is not running on battery and
I doubt it typically spends a lot of time in suspend at all.
Okay, but still from logical point of view wouldn't be better to fix the driver
for such case? At least I see benefits out of this approach: a) less hackish,
less quirk code; b) if this happens on non-industrial case it would be better
to have in the driver due to power consumption.
Maybe, I guess we first need to figure out which platforms clock(s) is (are)
being used, if there is more then one; or it is a different one then in the
realtek ethernet case it might be better to go with the dmi quirk option.
Semyon Verchenko can you (as root) run the following command on a kernel
where the ethernet does work:
grep . /sys/kernel/debug/clk/pmc_plt_clk_?/flags
And then email us the output please?
Regards,
Hans
_______________________________________________
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
