Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Wed, Jan 11, 2012 at 11:09:18AM +0100, Chase Douglas wrote:
> On 01/11/2012 11:04 AM, Henrik Rydberg wrote:
> >>> Applied, however I removed stable notation as this change IMO does not
> >>> qualify for the stable since it does not address a regression.
> >>
> >> It's not a regression per-se, but we want to fix buttonpad support, and
> >> we can't do that without this patch. It's a clear bug that when the
> >> property was added we did not set the property in the devices that need it.
> > 
> > The current behavior depends on userspace and is not a kernel bug,
> > please stop the nonsense already.
> > 
> > For bcm5974 devices, extracting buttonpad properties has been possible
> > since early 2009 (158e9287). The mechanism, predating the input
> > properties interface by nearly two years, has been used in the
> > multitouch and mtrack X drivers ever since. To those users, the
> > present patch has no effect at all.
> 
> Just because an alternative interface has existed does not mean there
> isn't a bug. 

No, there isn't a bug. The driver simply does not support new interface
yet. In all our discussions, AFAIR, property bits were always supposed
to carry only advisory role, i.e. if a driver sets them up then
userspace has it easy and can act upon them. Absence of a property does
not guarantee anything.

Hmm, speaking of properties, shouldn't we set INPUT_PROP_POINTER on
bcm5974 while we are at it?

> A device that has a physical property, but does not set the
> property bit in the driver is a real bug that needs to be fixed.
> Userspace should not have to quirk around broken implementations.
> 
> It's true that userspace can quirk around things in a kernel that
> predates the property bits, but where the property bits are available
> the devices *must* set them or else things will break.

If you are already supporting older kernels that do not support property
bits then you should already be set.

Anyway, this is not a regression and not even new hardware enablement:

" - It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
   security issue, or some "oh, that's not good" issue.  In short,
   something critical.
 - New device IDs and quirks are also accepted."

Therefore I do not feel that stable nomination is warranted. You may
still send it to stable, I'll add similar comment to that request and
leave it up to Greg to decide if he still wants to put it into stable.

Thanks.

-- 
Dmitry