linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ohad Ben-Cohen <ohad@wizery.com>
To: Suman Anna <s-anna@ti.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Kumar Gala <galak@codeaurora.org>,
	Tony Lindgren <tony@atomide.com>,
	Josh Cartwright <joshc@codeaurora.org>,
	Bjorn Andersson <bjorn@kryo.se>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCHv6 4/5] hwspinlock/core: add common OF helpers
Date: Thu, 13 Nov 2014 12:03:20 +0200	[thread overview]
Message-ID: <CAK=WgbbatPTiz3efDWHVEcuug_UQfkCViMoK0zcfUg3JwB2oTA@mail.gmail.com> (raw)
In-Reply-To: <5463B5B6.8040709@ti.com>

Hi Suman,

On Wed, Nov 12, 2014 at 9:32 PM, Suman Anna <s-anna@ti.com> wrote:
>> 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;
> +       }

I'm not entirely convinced that this justifies adding the proposed
linked list. Can't we can get the base_id and number of locks by
traversing the DT?

> That said, it is also needed to provide the support for deferred probing
> without changing the return code conventions on the existing API.

Here too, adding a data structure maintaining memory objects and
taking care of it life cycle seems a bit overkill for anything to do
with return values.

> 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.

Validation is great but I'm still not convinced it can't be done
without maintaining another data structure.

Please show me specific technical issues that can't be resolved
without adding the proposed linked list.

Thanks,
Ohad.

  reply	other threads:[~2014-11-13 10:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-12 20:24 [PATCHv6 0/5] hwspinlock core/omap dt support Suman Anna
2014-09-12 20:24 ` [PATCHv6 1/5] Documentation: dt: add common bindings for hwspinlock Suman Anna
2014-11-12 15:14   ` Ohad Ben-Cohen
2014-11-12 17:08     ` Suman Anna
2014-12-08 17:21       ` Bjorn Andersson
2014-09-12 20:24 ` [PATCHv6 2/5] Documentation: dt: add the omap hwspinlock bindings document Suman Anna
2014-11-12 15:16   ` Ohad Ben-Cohen
2014-09-12 20:24 ` [PATCHv6 3/5] hwspinlock/core: maintain a list of registered hwspinlock banks Suman Anna
2014-09-12 20:24 ` [PATCHv6 4/5] hwspinlock/core: add common OF helpers Suman Anna
2014-11-12 19:08   ` Ohad Ben-Cohen
2014-11-12 19:32     ` Suman Anna
2014-11-13 10:03       ` Ohad Ben-Cohen [this message]
2014-11-13 17:38         ` Suman Anna
2014-11-13 19:45           ` Ohad Ben-Cohen
2014-11-13 21:02             ` Suman Anna
2014-11-14  7:11               ` Ohad Ben-Cohen
2014-11-14 17:09                 ` Suman Anna
2014-11-14 20:05                   ` Ohad Ben-Cohen
2014-09-12 20:24 ` [PATCHv6 5/5] hwspinlock/omap: add support for dt nodes Suman Anna
2014-11-12 19:14   ` Ohad Ben-Cohen
2014-11-12 19:50     ` Suman Anna
2014-11-13  9:04       ` Ohad Ben-Cohen
2014-11-20  0:43     ` Bjorn Andersson
2014-11-20  6:36       ` Ohad Ben-Cohen
2014-09-30 16:25 ` [PATCHv6 0/5] hwspinlock core/omap dt support Suman Anna
2014-09-30 20:54 ` Bjorn Andersson
2014-09-30 21:27   ` Suman Anna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK=WgbbatPTiz3efDWHVEcuug_UQfkCViMoK0zcfUg3JwB2oTA@mail.gmail.com' \
    --to=ohad@wizery.com \
    --cc=bjorn@kryo.se \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=joshc@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=s-anna@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).