On 6 December 2012 15:41, Lee Jones [off-list ref] wrote:

So then I'm back to my original question, why?

What is it used for? What difference does it make?

I could understand if the .data attribute was used in the driver
to make vital decisions based on STMPE version, but it's not. So
why are we burdening the driver with unused code that's not
required? Other than to get your mainlined patch-count up of
course? This has an air of "placing header files in alphabetical
order" about it. ;)

The count would still be the same as some part of this patch will
go :)

I said that because of Grant's comment: "An of_match_table is the
robust way of identifying specific devices and allows for matching
against any entry in the compatible list."

So, thought its better we keep it.

Now, the problem is, with this new table we will bind device and
driver based on of_device_id table and probe it using device_id
table. Ahh.. that's broken. Maybe yes, can remove it unless we
have a real need of it.

quoted

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.

Or you could not put unnecessary bindings into the Device Tree
by putting two and two together and realise that using the table
is the correct thing to do instead. This actually gives reason
to you previous patch, but should probably be fixed-up into it
so it has some proper meaning/purpose. ;)

Couldn't understand this one :(