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

[Hans de G. <hde...@re...>]

Hi Hisashi,

On 3/29/19 5:46 AM, Hisashi T Fujinaka wrote:
> On Thu, 28 Mar 2019, 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.
> 
> Sorry for replying from home. It's either that or top-posting with
> Outlook.
> 
> It sounds to me like Andriy's arguments are counter to what he suggests
> since we'd have to fix the USB and the Ethernet and that would add more
> special case code, right? However, I'm just the old igb bug fixer and
> not a clock guy, and I've spent little time outside of the Ethernet
> drivers.
> 
> It really sounded like there were going to be changes to the clock code
> that would resolve the issue. Were those done? Do I still need to change
> the igb driver to change the clocks used?

Andy and I are still discussing this, we will get back to you when
we've a conclusion on how best to fix this.

Regards,

Hans