On Tue, Sep 17, 2019 at 07:18:14PM +0200, Marco Felsch wrote: > Hi Dmitry, > > On 19-09-17 10:07, Dmitry Torokhov wrote: > > On Tue, Sep 17, 2019 at 05:58:04PM +0200, Marco Felsch wrote: > > > The default driver behaviour is to enable the wakeup-source everytime. > > > There are hardware designs which have a dedicated gpio to act as wakeup > > > device. So it must be allowed to disable the wakeup-source capability. > > > > > > This patch adds the binding documentation to disable the wakeup-source > > > capability. > > > > > > Signed-off-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> > > > --- > > > .../devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt > > > index 870b8c5cce9b..4d6524fe3cf4 100644 > > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt > > > @@ -35,6 +35,10 @@ Optional properties: > > > - pinctrl-0: a phandle pointing to the pin settings for the > > > control gpios > > > > > > + - edt,disable-wakeup-source: If left the device will act as wakeup-source > > > + (for legacy compatibility). Add the property > > > + so the device won't act as wakeup-source. > > > > I think this is too ugly and I consider it being a bug in the driver > > that it enables wakeup unconditionally. > > That's right. > > > Let's just update DTS in tree for devices that actually want it (I am > > curious how many that do not declare "wakeup-source" have it working and > > actually want it) and key the dirver behavior off the standard property. > > There are a few DTS using this driver and the current driver behaviour. > We need to keep the backward compatibility since the DTB is part of the > firmware and firmware isn't always included during a system-update. I > know its ugly but IMHO that's the right way to go to keep the backward > compatibility. Let us see what the DT-folk says. > > > Until we start seeing this controller in devices that actually have DTS > > in hardware device tree I think it is better to use standard property. > > Sorry, I didn't get you here.. What I was trying to say is that I have not actually seen DTB that is part of hardware or separately upgradable frimware (not talking about ppc or sparc boxes, but ones that might be using this driver). It is always built into the kernel in my experience, so backward compatibility is simply a tool that is being used to prevent us from being too wild with hacking on bindings, but rarely a practical concern. In cases like this I think it is worthwhile to simply update in-tree DTS and arrive at a sane binding. Thanks. -- Dmitry
