On Fri, Aug 14, 2015 at 6:24 PM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote: > Would you rather query the hwspinlock driver to see if the framework > should take a s/w spinlock or not, IOW, raw-accessible or not? Sorry, I'm afraid I rather not. This seems to make things even more complicated without introducing any technical merit. >> Let's go over your aforementioned concerns: >>> >>> But this could yield wrong locking scenarios. If banks are allowed RAW >>> capability and is not enforced on a per-lock basis, a driver may lock >>> using non-raw lock using the _raw API >> >> >> If this is allowed by the hardware, then this is a valid scenario. >> There's no such thing a non-raw lock: a lock is raw if a raw >> functionality is required. >> > Agreed. I believe, we are saying the same thing. > A raw access is a request from the calling driver. It is a request from > the driver to directly talk to its hwspinlock driver, without any > encumberance from the framework. > >>> while another driver may >>> 'acquire' the lock (since the value written to the lock would be the >>> same as raw api would). >> >> >> Not sure I understand this one. If a lock has already been assigned to >> a driver, it cannot be re-assigned to another driver. >> > Nevermind, not a good example. Please let me know then if you have any other technical concern that requires this capability to be maintained separately for every lock. So far, though, it seems like maintaining this capability separately per lock is adding complexity, without it solving any technical problem, that the simpler proposal doesn't solve as well. If I'm missing anything please let me know, Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
