Thread (27 messages) 27 messages, 3 authors, 2014-12-08

[PATCHv6 4/5] hwspinlock/core: add common OF helpers

From: Suman Anna <hidden>
Date: 2014-11-12 19:32:44
Also in: linux-devicetree, linux-omap, lkml

Hi Ohad,

Thanks for the review.

On 11/12/2014 01:08 PM, Ohad Ben-Cohen wrote:
Hi Suman,

On Fri, Sep 12, 2014 at 11:24 PM, Suman Anna [off-list ref] wrote:
quoted
+int of_hwspin_lock_get_id(struct device_node *np, int index)
+{
+       struct hwspinlock_device *bank;
+       struct of_phandle_args args;
+       int id;
+       int ret;
+
+       ret = of_parse_phandle_with_args(np, "hwlocks", "#hwlock-cells", index,
+                                        &args);
+       if (ret)
+               return ret;
+
+       mutex_lock(&hwspinlock_tree_lock);
+       list_for_each_entry(bank, &hwspinlock_devices, list)
+               if (bank->dev->of_node == args.np)
+                       break;
+       mutex_unlock(&hwspinlock_tree_lock);
+       if (&bank->list == &hwspinlock_devices) {
+               ret = -EPROBE_DEFER;
+               goto out;
+       }
Is this the validation you mentioned which requires the existence of
"hwspinlock/core: maintain a list of registered hwspinlock banks" ?
Well, not exactly. The validation is on the following segment,

+	id = of_hwspin_lock_simple_xlate(bank, &args);
+	if (id < 0 || id >= bank->num_locks) {
+		ret = -EINVAL;
+		goto out;
+	}

That said, it is also needed to provide the support for deferred probing
without changing the return code conventions on the existing API.
I'm not convinced this is needed for several reasons:
- the user isn't using the lock yet at this point, and may only need
the id in order to communicate it to a remote processor
Yes, and wouldn't that require that the id is validated? It just cannot
return any return value, and expect it will be verified somewhere else
or in a following API call. Not doing the validation unnecessarily
complicates the system usage of a lock as you are sharing an invalid
lock to a remote processor and then you have two validation failure
paths on different processors.
- if the user will try to use the lock prematurely,
hwspin_lock_request_specific should stop her
- moreover, hwspin_lock_request_specific must be the one who validates
the id, since in heterogeneous systems the user may get the id from a
remote processor and not via of_hwspin_lock_get_id

 "hwspinlock/core: maintain a list of registered hwspinlock banks"
adds complexity which must be very strongly justified.

If we're not sure there is a strong justification for it, we better
not merge it.
quoted
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
...
quoted
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_locks);
Do we really must expose these two helpers globally?

Can we instead make these "static inline" methods and embed them in
hwspinlock_internal.h ?
Actually, not a bad idea, I will move it, thanks. All the client drivers
would need it, and they already have to include the internal header.

regards
Suman
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help