On Fri, Dec 9, 2016 at 10:05 AM, Doug Anderson [off-list ref] wrote:

Hi,

On Thu, Dec 8, 2016 at 8:01 AM, Rob Herring [off-list ref] wrote:

quoted

quoted

Just my $0.02.  Feel free to ignore.

One thought is that I would say that the need to power on the device
explicitly seems more like a board level difference and less like a
difference associated with a particular digitizer.  Said another way,
it seems likely there will be boards with a w9013 without explicit
control of the regulator in software and it seems like there will be
boards with other digitizers where suddenly a new board will come out
that needs explicit control of the regulator.

Then either the regulator is optional or you don't say it is a w9013
for that board. But if you do need to initialize the device and
therefore know what type of device it is, then you need a compatible
for the device. It's when things really vary by board that we add DT
properties.

quoted

In this particular case I feel like we can draw a lot of parallels to
an SDIO bus.

When you specify an SDIO bus you don't specify what kind of card will
be present, you just say "I've got an SDIO bus" and then the specific
device underneath is probed.  Here we've say "I've got an i2c
connection intended for HID" and then you probe for the HID device
that's on the connection.

No, the soldered down devices require all sorts of extra non-SDIO
connections and we do specify the device in those cases.

We have never specified the device on boards I've worked with.

On rk3288-veyron, for instance, we might have stuffed a Broadcom 4354
WiFi chip or a Marvell 8897 WiFi chip.  Some veyron boards have one
chip and some have the other.  ...and during bringup we even had some
of the exact same boards where half were stuffed with one chip and
half with the other.

Nothing in the device tree says which chip is stuffed.  In both cases
the board uses the same power on sequence for the WiFi chip.  Once
that is done, we dynamically probe which actual WiFi part is stuffed.

That's good and I'm happy when that works, but it doesn't work in the
general case. I'm not saying you can't do exactly the same thing here.
All I'm asking for is add the properties to the binding AND a
compatible. The kernel can ignore the added compatible. The key point
is if you have additional properties outside of what it means to be
HID-over-I2C, then you must have a compatible for that device. Whether
you enforce that in the driver, I don't give a shit. I do care how it
is documented though and will care when or if we start validating
bindings (I don't think that's the kernel's job).

This is not just a problem with probe-able buses. This dual sourcing
happens with non-probe-able devices too. Look at Hans' series for
Allwinner tablet touchscreens.

Certainly not all users that have these WiFi chips use the same power
on sequence.  I have certainly seen development boards for these chips
where you just insert them into a regular SD card slot.  This is a
more expensive solution because you need more logic on the board, but
it shows that the power on sequence is not associated with these
chips.

If SD slots were the primary target for SDIO cards, we'd be in much
better shape without all the misc side band signals. Many devices I
don't think could be made to work as a card.

quoted

quoted

Also for an SDIO bus, you've possibly got a regulators / GPIOs /
resets that need to be controlled, but the specific details of these
regulator / GPIOs / resets are specific to a given board and not
necessarily a given SDIO device.

It's both. The device defines what is needed and the specs to control
them (active states of GPIOs, de/assertion times of resets, supply
voltages, etc.). The board only determines what the connections are
and if you can control them.

It's not always that simple.  The device says that it needs power and
resets to happen.  How power is provided and how resets happen is
awfully board specific.  As per above it is possible that the board
wouldn't need to be involved above is you want to spend more money /
power.

We have ways to deal with board specifics. If you want something
completely generic to handle any possible power sequence of any board
and any device, then propose something that does that. That's not what
we have here with 2 properties.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html