Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1228880 > unrolled thread
| Started by | Ohad Ben-Cohen <ohad@wizery.com> |
|---|---|
| First post | 2015-09-20 15:10 +0200 |
| Last post | 2015-09-20 15:10 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device Ohad Ben-Cohen <ohad@wizery.com> - 2015-09-20 15:10 +0200
| From | Ohad Ben-Cohen <ohad@wizery.com> |
|---|---|
| Date | 2015-09-20 15:10 +0200 |
| Subject | Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device |
| Message-ID | <qaMxs-IY-9@gated-at.bofh.it> |
On Fri, Aug 14, 2015 at 6:24 PM, Lina Iyer <lina.iyer@linaro.org> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to top | Article view | linux.kernel
csiph-web