Hi Benoit, On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoit <[email protected]> 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. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
