Thread (26 messages) 26 messages, 5 authors, 2012-12-07

Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver

From: Viresh Kumar <hidden>
Date: 2012-12-06 10:20:54
Also in: lkml

On 6 December 2012 15:20, Lee Jones [off-list ref] wrote:
quoted
quoted
But regardless, it is the responsiblity of the probe function to go and
look if of_driver_match_device() matches against anything if it cares
about the of_match_table entries (for instance, if there is extra data
attached).
Ok, so filling .data field in of_device_id[] is not required for our case as
we aren't doing anything special in our drivers.
This is exactly my point, and the reason I bought it up in the
first place. Normally when you specify an ID table and populate
the .data attribute, you parse for it in the code and then cast
it back to some kind of useful data. However, you're not doing
that, which is precisely why I wondered if the table was
necessary at all. In all my testing, the DT portion worked and
the correct STMPE chip was identified without it.
Probably Vipul (Author of this patch), copied it from existing i2c/spi
clients, which have also added this blindly :)
So, are you adding the table for good reason, or because you
think it's the right thing to do?
I would be keeping the table as that's the right thing to do. By chance
our non-DT and DT tables had a difference of "st," only in the name
of instances and so it worked without tables. Otherwise it couldn't
have worked.

Over that, i am looking to bring the "stmpe,id" binding back again (unless
you have a better option), as device name is not coming from DT currently,
which we discussed earlier.

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