[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74f6b75a-66b0-789f-658b-0e9f5cfed5a8@roeck-us.net>
Date: Fri, 27 Jan 2017 06:14:57 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Pavel Machek <pavel@....cz>
Cc: Zhang Rui <rui.zhang@...el.com>,
Pali Rohár <pali.rohar@...il.com>,
sre@...nel.org, kernel list <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-omap@...r.kernel.org, tony@...mide.com, khilman@...nel.org,
aaro.koskinen@....fi, ivo.g.dimitrov.75@...il.com,
patrikbachan@...il.com, serge@...lyn.com, abcloriens@...il.com,
fabio.estevam@....com
Subject: Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900
On 01/27/2017 03:09 AM, Pavel Machek wrote:
>
>>> If this is the case, you'd better set
>>> (struct thermal_zone_params)->no_hwmon when registering the thermal
>>> zone device, in which case, the hwmon device will not be created.
>>>
>>> In fact, I'd prefer to change tzp->no_hwmon to tzp->hwmon to not create
>>> hwmon I/F by default, and see if there is anyone using it. If yes, we
>>> can set the flag in soc thermal driver, explicitly, at meantime, a
>>> hwmon compatible name is required.
>>>
>>> But one foreseeable result is that we may get bug reports from end user
>>> that some sensors (acpitz, etc) are gone in 'sensors' output. And TBH,
>>> I'm not quite sure if this can be counted as a regression or not.
>>>
>>
>> That sounds like fun. Changing bq27200-0 to bq27200_0 is Forbidden by
>> the ABI Police, but taking the entire device away is ok.
>
> Stop trying to break other people's systems. Thanks you.
>
You still have not shown that it does. Actually, I am trying to _fix_
other people's systems (those using libsensors).
Guenter
Powered by blists - more mailing lists