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: "Семен Верченко" <semverchenko@factor-ts.ru>,
	"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>
Subject: Re: [E1000-devel] igb driver with Intel Atom Bay Trail issue
Date: Thu, 18 Apr 2019 15:09:15 +0200	[thread overview]
Message-ID: <a05e2ac3-de31-bd7a-6b39-8cdf00190f67@redhat.com> (raw)
In-Reply-To: <20190409153125.GU9224@smile.fi.intel.com>

Hi,

On 09-04-19 17:31, Andy Shevchenko wrote:
> On Mon, Apr 08, 2019 at 08:43:10PM +0200, Hans de Goede wrote:
>> On 08-04-19 19:21, Andy Shevchenko wrote:
>>> On Thu, Apr 04, 2019 at 04:43:03PM +0200, Hans de Goede wrote:
>>>> On 29-03-19 16:53, Hans de Goede wrote:
>>>>> On 3/29/19 2:59 PM, Семен Верченко wrote:
>>>
>>>>> Hmm, so 4 ethernet cards and 4 enabled / marked as critical clocks.
>>>>>
>>>>> Supporting this through get_clk is going to require a DMI table in the igb driver
>>>>> combined with checking which PCI "slot" the card is to get the correct clock
>>>>> for each ethernet controller.
>>>>>
>>>>> I believe tht just restoring the old behavior to mark all clocks enabled
>>>>> on boot as critical, but then limited to this system based on a dmi match,
>>>>> is the best solution here.
>>>>>
>>>>> Andy?
>>>>
>>>> Andy? Now that we've the patch ready for the other system which needs to
>>>> have the CLK_IS_CRITICAL workaround and enables this based on DMI info,
>>>> I believe the best fix for this system is to simply add it to that DMI
>>>> table?
>>>
>>> I reviewed v4, supposed to go via CLK tree.
>>
>> Right, but that patch adds the quirk for the system with the USB hub,
>> do you agree, that given that each ethernet controller seems to be
>> using its own clock, it is best to use a DMI quirk for this case too?
>>
>> If you agree then someone needs to prepare a follow-up patch on top of
>> v4 which adds the DMI info for this board to the table.
> 
> I hope we may find a better solution in the future, but for now as a quick fix
> the proposed can be done.

Ok.

Семен Верченко, this means that we are going to need DMI info from
the board in question. I thought we already had that, but I now see that
you original report did not have that a

Please run as root:

dmidecode &> dmidecode.log

And then reply to this email with the generated dmidecode.log file
attached. Once I have that file I can prepare a patch fixing this.

Regards,

Hans