Thread (30 messages) 30 messages, 6 authors, 2016-12-13

Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support

From: Doug Anderson <dianders@chromium.org>
Date: 2016-12-09 16:17:03
Also in: linux-input, linux-rockchip, lkml

Hi,

On Fri, Dec 9, 2016 at 7:01 AM, Rob Herring [off-list ref] wrote:
On Fri, Dec 9, 2016 at 8:36 AM, Jiri Kosina [off-list ref] wrote:
quoted
On Thu, 8 Dec 2016, Rob Herring wrote:
quoted
quoted
And if tomorrow there is Elan device that is drop-in compatible (same
connector, etc) with Wacom i2c-hid, will you ask for Elan-specific
binding? Atmel? Weida? They all need to be powered up ultimately.
Yes, I will.
What advantage does that bring?
quoted
That in no way means the OS driver has to know about each and every one.
If they can all claim compatibility with Wacom (including power
control), then they can have a Wacom compatible string too. Or you can
just never tell me that there's a different manufacturer and I won't
care as long you don't need different control. But soon as a device
needs another power rail, GPIO or different timing, then you'd better
have a new compatible string.
Again, I simply don't understand what advantage does the aproach you are
trying to use bring.
This is simply how DT works. HID-over-I2C devices are no different
than any other I2C device or any other component. You are not special.
...but once you say that it's HID over I2C then it becomes probe-able,
right?  Said another way: we need to specify just enough to power the
device up properly and then we can ask it what kind of device it is
and then we can make quirk decisions based on that.

So specifying what kind of device it is in the device tree is somewhat
redundant and it also means that you make it needlessly difficult to
build a system with dual-sourced components.

One of the major points of probe-able connections is that you could
put anything you want there and the kernel _doesn't_ need to describe
it.  ...and the whole point of device tree (I thought) was to
specifically handle connections that _aren't_ probe-able.

For instance, if a board has a USB bus on it but you need to assert a
special reset or turn on a special regulator (besides vbus) before you
can probe the USB bus, you wouldn't think that the board should
specify exactly what device was stuffed in the connection, would you?

quoted
HID over I2C is a generic protocol.
DT describes h/w, not protocols.
Isn't it a little of each, though?  When you say that there's a USB
port or an SDIO port or a serial port on the board, you're saying more
than just that there are 2, 4, or 8 wires coming out of the board.
You're saying that you're expecting to talk a certain protocol over
those wires.

-Doug
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help