Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

Pavel Machek
2017-01-27T19:06:51Z

[-- Attachment #1.1: Type: text/plain, Size: 1788 bytes --]

On Fri 2017-01-27 06:13:43, Guenter Roeck wrote:
> On 01/27/2017 03:16 AM, Pavel Machek wrote:
> >Hi!
> >
> >>>>That sounds like fun. Changing bq27200-0 to bq27200_0 is Forbidden by
> >>>>the ABI Police, but taking the entire device away is ok.
> >
> >Changing bq27200-0 to bq27200_0 is forbidden in -rc6 time. If you
> >believe noone depends on the name, argue your case, and it might be
> >possible to change it in -rc0.
> >
> >If someone uses the name, they care about the device, and you can't
> >take it away.
> >
> >>>No. IMO, it depends on if the interface is used or not.
> >>>If hwmon I/F is used, we can not take it away, nor change its name.
> >>
> >>Even if the use doesn't depend on that name ?
> >
> >If the use doesn't depend on the name, you may get away with changing
> >the name. (But not in -rc6.)
> >
> >>>If thermal zone I/F is used, we can not change it's 'type' name to be
> >>>compatible with new hwmon API.
> >>
> >>You mean you can not fix the name to be compatible with libsensors.
> >>
> >>Makes me wonder if there shouldn't be a rule that exploits must not
> >>be fixed if already exploited.
> >
> >That is not useful argumentation.
>
> Oh, but it is. Providing a valid name is a bug fix for me. For you it is
> an ABI change. So the ultimate question is what counts as an ABI change
> and what counts as a bug fix.

You may not fix bugs if it breaks someone's configuration. Now,
obviously security is something we can't sacrifice. But if docs don't
match the code.. we fix the docs, not the code.

Do you want to call me? I'll give you cellphone number.

Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org