Re: [E1000-devel] igb driver with Intel Atom Bay Trail issue

From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "David Müller" <dave.mueller@gmx.ch>,
	"Fujinaka, Todd" <todd.fujinaka@intel.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"e1000-devel@lists.sf.net" <e1000-devel@lists.sf.net>,
	"Stephen Boyd" <sboyd@kernel.org>,
	linux-clk@vger.kernel.org,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@codeaurora.org>,
	"Semyon Verchenko" <semverchenko@factor-ts.ru>
Subject: Re: [E1000-devel] igb driver with Intel Atom Bay Trail issue
Date: Fri, 29 Mar 2019 13:30:35 +0100	[thread overview]
Message-ID: <d4c44bc8-ae0c-a6ff-3042-ae3185ceb33e@redhat.com> (raw)
In-Reply-To: <20190328154931.GK9224@smile.fi.intel.com>

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