Hi Benoit,

On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoit [off-list ref] wrote:

Hehe, I'm not the one who wrote that driver :-)

This is not wrong for the current HW. The point is do we want to anticipate
potential HW evolution that might never happen on that IP?

I originally really thought we can ignore those cases (hence the 0
base id ;), and personally I still think the scenario is a bit
fictional, and wouldn't even mind just having omap_hwspinlock_probe()
return an error if it is unexpectedly probed with a second device.

But if fixing this entirely only means doing a small change, then it's
surely nicer.

This is no different than the multiple GPIO controllers we have today.
Since we cannot rely on the DT nodes order, I added an explicit "id"
attribute to provide that information to the driver. And then the baseid is
"id * #gpios".

That would work if #hwspinlock is a fixed number, but a "baseid"
attribute would allow supporting devices with different #hwspinlocks
per device. Since I am not aware of any real hardware that does this
kind of blasphemy, I can't say if the latter is really necessary :) If
you prefer the former, I'm entirely fine with it.

Thanks,
Ohad.