On Wed, Dec 07, 2022 at 11:07:53AM -0600, Rob Herring wrote: > On Tue, Dec 06, 2022 at 05:20:16AM +0200, Dmitry Baryshkov wrote: > > 6 декабря 2022 г. 00:04:33 GMT+02:00, Rob Herring <robh@xxxxxxxxxx> пишет: > > >On Sun, Dec 04, 2022 at 08:15:52AM +0200, Dmitry Baryshkov wrote: > > >> Convert the bindings for the keypad subdevices of Qualcomm PM8921 and > > >> PM8058 PMICs from text to YAML format. > > >> > > >> While doing the conversion also change linux,keypad-no-autorepeat > > >> property to linux,input-no-autorepeat. The former property was never > > >> used by DT and was never handled by the driver. > > > > > >Changing from the documented one to one some drivers use. I guess > > >that's a slight improvement. Please see this discussion[1]. > > > > Well, the problem is that the documentation is misleading. The driver > > doesn't handle the documented property, so we should change either > > the driver, or the docs. Which change is the preferred one? > > The preference is autorepeat is not the default and setting > 'autorepeat' enables it. You can't really change that unless you don't > really need autorepeat by default. I can't see why it would be > needed for the power button, but I haven't looked what else you have. > > Of all the no autorepeat options, I prefer 'linux,no-autorepeat' as I > find 'input' or 'keypad' redundant. But Dmitry T. didn't think it should > be a common property at the time. Right, I would prefer for new bindings we used assertive "autorepeat", instead of negating "no-autorepeat". However here we are dealing with existing binding. The issue is complicated with the driver using one option, binding specifying another, and existing in-kernel DTSes not using any and thus activating autorepeat as the default driver behavior. Do we have an idea if there are out-of-tree users of this? If we are reasonable sure there are not we could converge on the standard "autorepeat" property. -- Dmitry
