Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-18 Thread Linus Walleij
On Tue, Jun 18, 2013 at 9:33 AM, Wolfram Sang  wrote:
> On Mon, Jun 17, 2013 at 11:15:30PM +0100, Grant Likely wrote:
>> On Mon, Jun 17, 2013 at 5:33 PM, Linus Walleij  
>> wrote:
>> > OK that works for me, I'm not in any hurry.
>>
>> Deferring by a merge window isn't going to make it any less painful.
>> Do your best to find all the users that need to be changed. Use a
>> coccinelle search perhaps, but I think it should be merged anyway.
>
> I'll try a bit of my coccinelle-foo today and then decide.

Thanks Wolfram, much appreciated.

Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-17 Thread Stephen Warren
On 06/17/2013 04:15 PM, Grant Likely wrote:
> On Mon, Jun 17, 2013 at 5:33 PM, Linus Walleij  
> wrote:
>> On Mon, Jun 17, 2013 at 5:48 PM, Stephen Warren  
>> wrote:
>>
>>> This has just shown up in next-20130617, and breaks at least the
>>> TPS65910 and TPS62360 drivers, since they assume that the id parameter
>>> passed to probe is non-NULL. However, now the parameter is NULL since
>>> these drivers have both an ID table and an OF match table.
>>
>> So you mean they come in through the DT boot path and assume
>> that parameter is non-null even though they should not make use of
>> it?
>>
>>> I'd like to suggest this patch be reverted an re-introduced immediately
>>> after the merge window. That should give enough time for everyone to get
>>> a heads-up on fixing any drivers with a similar problem, rather than
>>> trying to cram all that in immediately before the merge window.
>>
>> OK that works for me, I'm not in any hurry.
> 
> Deferring by a merge window isn't going to make it any less painful.

It'll give a lot more time for people to be exposed to the change and
hence find/fix it linux-next rather than seeing it for the first time in
Linus's tree.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-17 Thread Grant Likely
On Mon, Jun 17, 2013 at 5:33 PM, Linus Walleij  wrote:
> On Mon, Jun 17, 2013 at 5:48 PM, Stephen Warren  wrote:
>
>> This has just shown up in next-20130617, and breaks at least the
>> TPS65910 and TPS62360 drivers, since they assume that the id parameter
>> passed to probe is non-NULL. However, now the parameter is NULL since
>> these drivers have both an ID table and an OF match table.
>
> So you mean they come in through the DT boot path and assume
> that parameter is non-null even though they should not make use of
> it?
>
>> I'd like to suggest this patch be reverted an re-introduced immediately
>> after the merge window. That should give enough time for everyone to get
>> a heads-up on fixing any drivers with a similar problem, rather than
>> trying to cram all that in immediately before the merge window.
>
> OK that works for me, I'm not in any hurry.

Deferring by a merge window isn't going to make it any less painful.
Do your best to find all the users that need to be changed. Use a
coccinelle search perhaps, but I think it should be merged anyway.

g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-17 Thread Stephen Warren
On 06/17/2013 10:33 AM, Linus Walleij wrote:
> On Mon, Jun 17, 2013 at 5:48 PM, Stephen Warren  wrote:
> 
>> This has just shown up in next-20130617, and breaks at least the
>> TPS65910 and TPS62360 drivers, since they assume that the id parameter
>> passed to probe is non-NULL. However, now the parameter is NULL since
>> these drivers have both an ID table and an OF match table.
> 
> So you mean they come in through the DT boot path and assume
> that parameter is non-null even though they should not make use of
> it?

Yes. Since this wasn't true/enforced before, it probably wasn't clear
that rule existed.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-17 Thread Linus Walleij
On Mon, Jun 17, 2013 at 5:48 PM, Stephen Warren  wrote:

> This has just shown up in next-20130617, and breaks at least the
> TPS65910 and TPS62360 drivers, since they assume that the id parameter
> passed to probe is non-NULL. However, now the parameter is NULL since
> these drivers have both an ID table and an OF match table.

So you mean they come in through the DT boot path and assume
that parameter is non-null even though they should not make use of
it?

> I'd like to suggest this patch be reverted an re-introduced immediately
> after the merge window. That should give enough time for everyone to get
> a heads-up on fixing any drivers with a similar problem, rather than
> trying to cram all that in immediately before the merge window.

OK that works for me, I'm not in any hurry.

Wolfram get to decide how to handle this...

Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-17 Thread Stephen Warren
On 05/22/2013 01:56 AM, Linus Walleij wrote:
> On Mon, May 13, 2013 at 10:18 PM, Linus Walleij
>  wrote:
> 
>> This tries to address an issue found when writing an MFD driver
>> for the Nomadik STw481x PMICs: as the platform is using device
>> tree exclusively I want to specify the driver matching like
>> this:
> (...)
>> ---
>> ChangeLog v1->v2:
>> - Use of_match_device() to determine if there is a DT match in
>>   the probe code. If there is a match we pass NULL for the
>>   id_table match parameter.
> 
> Ping on this.
> 
> v2 should be doing what Grant suggested...

This has just shown up in next-20130617, and breaks at least the
TPS65910 and TPS62360 drivers, since they assume that the id parameter
passed to probe is non-NULL. However, now the parameter is NULL since
these drivers have both an ID table and an OF match table.

I'd like to suggest this patch be reverted an re-introduced immediately
after the merge window. That should give enough time for everyone to get
a heads-up on fixing any drivers with a similar problem, rather than
trying to cram all that in immediately before the merge window. I'd also
suggest that this patch should be accompanied by fixes for any similarly
broken drivers, based on code inspection.

Do people agree? If not, please let us know ASAP so we can post patches
to fix this.

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-13 Thread Linus Walleij
On Wed, Jun 12, 2013 at 3:20 PM, Grant Likely  wrote:
> On Fri, 7 Jun 2013 23:32:42 +0200, Wolfram Sang  wrote:

>> I guess your solution is the least intrusive one. Still, it could happen
>> that of_match_table is scanned three times (by driver core, i2c layer,
>> and i2c driver) which is IMO an indication to look for a more elegant
>> solution tp find out what really matched?
>
> It's what we do on platform_devices. It really isn't an expensive
> operation so I haven't pushed anyone to go optimize it.

I tried to think of something and it ended up with ideas like
decorating the device tree representation and it was just ...
ouch.

Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-12 Thread Grant Likely
On Mon, 10 Jun 2013 15:40:14 +0200, Wolfram Sang  wrote:
> On Mon, Jun 10, 2013 at 02:18:17PM +0200, Linus Walleij wrote:
> > On Fri, Jun 7, 2013 at 11:32 PM, Wolfram Sang  wrote:
> > > ...
> > >> I2C devices probed from device tree should subsequently be
> > >> fixed to handle the case where of_match_table() is
> > >> used (I think none of them do that today), and platforms should
> > >> fix their device trees to use compatible strings for I2C devices
> > >> instead of setting the name to Linux device driver names as is
> > >> done in multiple cases today.
> > >
> > > I guess your solution is the least intrusive one. Still, it could happen
> > > that of_match_table is scanned three times (by driver core, i2c layer,
> > > and i2c driver) which is IMO an indication to look for a more elegant
> > > solution tp find out what really matched?
> > 
> > I think that is a generic problem with the device tree
> > being completely stateless, and rather a comment on the
> > of_match_device() intrinsics being inelegant than on this
> > patch?
> 
> Yes.
> 
> > Do you see it as a blocker for the patch?
> 
> No blocker. Yet, I was hoping for somebody perhaps having a good idea.
> Platform devices have 'id_entry', for example. Sadly, I don't have the
> resources to pick up a similar idea.
> 

I did at one time have a patch that kept the pointer around in the
struct device if an of_match_table succeeded, but it caused subtle race
conditions that weren't easy to solve. I reverted back to just calling
of_match_table() several times because it was easy.

g.

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-12 Thread Grant Likely
On Fri, 7 Jun 2013 23:32:42 +0200, Wolfram Sang  wrote:
> ...
> > I2C devices probed from device tree should subsequently be
> > fixed to handle the case where of_match_table() is
> > used (I think none of them do that today), and platforms should
> > fix their device trees to use compatible strings for I2C devices
> > instead of setting the name to Linux device driver names as is
> > done in multiple cases today.
> 
> I guess your solution is the least intrusive one. Still, it could happen
> that of_match_table is scanned three times (by driver core, i2c layer,
> and i2c driver) which is IMO an indication to look for a more elegant
> solution tp find out what really matched?

It's what we do on platform_devices. It really isn't an expensive
operation so I haven't pushed anyone to go optimize it.

g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-06-10 Thread Linus Walleij
On Fri, Jun 7, 2013 at 11:32 PM, Wolfram Sang  wrote:
> ...
>> I2C devices probed from device tree should subsequently be
>> fixed to handle the case where of_match_table() is
>> used (I think none of them do that today), and platforms should
>> fix their device trees to use compatible strings for I2C devices
>> instead of setting the name to Linux device driver names as is
>> done in multiple cases today.
>
> I guess your solution is the least intrusive one. Still, it could happen
> that of_match_table is scanned three times (by driver core, i2c layer,
> and i2c driver) which is IMO an indication to look for a more elegant
> solution tp find out what really matched?

I think that is a generic problem with the device tree
being completely stateless, and rather a comment on the
of_match_device() intrinsics being inelegant than on this
patch?

Do you see it as a blocker for the patch?

What happens before this patch is that instead of looping
over the of_match_table, the id_table is always iterated
to the end also in the DT case, yielding NULL as the last
argument to driver->probe() anyway.

Maybe the OF people have some comments on this...
I cannot really see how it could be any different given
the way the FDT works :-/

Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-05-30 Thread Linus Walleij
On Wed, May 22, 2013 at 9:56 AM, Linus Walleij  wrote:
> On Mon, May 13, 2013 at 10:18 PM, Linus Walleij
>  wrote:
>
>> This tries to address an issue found when writing an MFD driver
>> for the Nomadik STw481x PMICs: as the platform is using device
>> tree exclusively I want to specify the driver matching like
>> this:
> (...)
>> ---
>> ChangeLog v1->v2:
>> - Use of_match_device() to determine if there is a DT match in
>>   the probe code. If there is a match we pass NULL for the
>>   id_table match parameter.
>
> Ping on this.
>
> v2 should be doing what Grant suggested...

Ping, nocheinmal.

Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

2013-05-22 Thread Linus Walleij
On Mon, May 13, 2013 at 10:18 PM, Linus Walleij
 wrote:

> This tries to address an issue found when writing an MFD driver
> for the Nomadik STw481x PMICs: as the platform is using device
> tree exclusively I want to specify the driver matching like
> this:
(...)
> ---
> ChangeLog v1->v2:
> - Use of_match_device() to determine if there is a DT match in
>   the probe code. If there is a match we pass NULL for the
>   id_table match parameter.

Ping on this.

v2 should be doing what Grant suggested...

Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss