Re: [PATCH v3 3/5] dt-bindings: input: Add poll-interval property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16. 10. 19 2:23, Dmitry Torokhov wrote:
On Fri, Oct 11, 2019 at 10:03:25AM +0200, Michal Vokáč wrote:
On 10. 10. 19 22:01, Dmitry Torokhov wrote:
On Thu, Oct 10, 2019 at 02:40:36PM -0500, Rob Herring wrote:
On Thu, Oct 03, 2019 at 08:12:54AM +0200, Michal Vokáč wrote:
Add an option to periodicaly poll the device to get state of the inputs
as the interrupt line may not be used on some platforms.

Signed-off-by: Michal Vokáč <michal.vokac@xxxxxxxxx>
---
Changes since v2:
   - None

Changes since v1:
   - Use poll-interval instead of linux,poll-interval.
   - Place the poll-interval binding into the common schema.
   - Properly describe that either interrupts or poll-interval property is
     required.
   - Fix the example to pass validation.

   .../bindings/input/fsl,mpr121-touchkey.yaml        | 25 +++++++++++++++++++++-
   Documentation/devicetree/bindings/input/input.yaml |  4 ++++
   2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml b/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml
index c6fbcdf78556..035b2fee4491 100644
--- a/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml
+++ b/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml
@@ -17,6 +17,10 @@ description: |
   allOf:
     - $ref: input.yaml#
+oneOf:

It should be valid to have both properties present, right?

The poll does not really sense and does not have any effect when
interrupt is supplied.

 From technical point of view, yes it is possible to have both
properties. But I agree that it does not really make sense to
use both at the same time.

The h/w description can't know what the OS supports.

It also has no idea what OS does at all and whether it even pays
attention to any of these properties. We are just trying to say here "I
do not have an interrupt wired, so for this device's primary use case
(that is coupled with a certain $PRIMARY OS) we need to poll the
controller ever so often to handle our use case".

If I understand correctly the relationship between Linux and DT
binding, in Linux we are free to implement just part of all the
possible configuration options described by the binding.

In this case if somebody would enable both interrupt and polling,
we will happily use the interrupt mode only. Maybe it would be nice
to at least print a message that the poll-intervall is ignored?

In that case, we should use 'anyOf' here instead.

What I am afraid of is that some DT writers may really use both
properties and expect that Linux will actually do something useful
in this case. Anyway, I am OK with that.

OK, I changed it to "anyOf", folded into driver change and applied.

AFAIK this is discouraged and DT binding changes and driver changes
should ideally be kept as separate patches. Separating the binding
from driver changes makes is easier for other projects to reuse
the binding.

The other thing is, Rob reviewed just the binding part, not the driver
change, but now his tag covers both changes.

Michal




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux