Hi Benoit, On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoit <b-cousson@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
