|
From: Hisashi T F. <ht...@tw...> - 2019-03-29 05:02:57
|
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? -- Todd Fujinaka <tod...@in...> |