From: Dave Gerlach <d-gerlach@ti.com>
To: Ohad Ben-Cohen <ohad@wizery.com>, Suman Anna <s-anna@ti.com>
Cc: linux-arm <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Kevin Hilman <khilman@linaro.org>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API
Date: Mon, 18 May 2015 09:33:28 -0500 [thread overview]
Message-ID: <5559F838.4010003@ti.com> (raw)
In-Reply-To: <CAK=WgbZGYa-xWE_cxPA1aq50kK2NBdQfhQHX+sPyowky6Syekg@mail.gmail.com>
Ohad,
On 05/16/2015 02:18 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
>
> On Mon, May 11, 2015 at 6:09 PM, Suman Anna <s-anna@ti.com> wrote:
>> On 05/09/2015 02:39 AM, Ohad Ben-Cohen wrote:
>>> On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>> This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc:
>>>> remove the get_by_name/put API") for the ref counting a rproc klist
>>>> code but has rproc_get_by_name replaced with an rproc_get_by_phandle API.
>>>
>>> The general idea makes sense to me, but I'm not sure we really do need
>>> a klist here, since the usage profile of this list is expected to be
>>> super simple: very small number of accessors, looking for small number
>>> of list members a small number of times, and probably never do need to
>>> modify the list while accessing it.
>>>
>>> I suspect that the code would be simpler to maintain, debug and
>>> understand if we just use a simple list with a simple locking
>>> methodology here.
>>
>> The klist usage is something that we restored from previous remoteproc
>> core code as used by the rproc_get_by_name() API. This was removed in
>> commit 40e575b1d0b3 ("remoteproc: remove the get_by_name/put API"). We
>> chose to use the code that had been present before rather than inventing
>> something new all over again. If you feel that a regular list is the way
>> to go forward, we can make the switch.
>
> Yes, please. Using a regular list with a simple locking methodology
> should make the code easier to understand and debug.
Ok, that makes sense, we can change this. Thanks for your input.
Regards,
Dave
>
> Thanks,
> Ohad.
>
WARNING: multiple messages have this Message-ID (diff)
From: d-gerlach@ti.com (Dave Gerlach)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API
Date: Mon, 18 May 2015 09:33:28 -0500 [thread overview]
Message-ID: <5559F838.4010003@ti.com> (raw)
In-Reply-To: <CAK=WgbZGYa-xWE_cxPA1aq50kK2NBdQfhQHX+sPyowky6Syekg@mail.gmail.com>
Ohad,
On 05/16/2015 02:18 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
>
> On Mon, May 11, 2015 at 6:09 PM, Suman Anna <s-anna@ti.com> wrote:
>> On 05/09/2015 02:39 AM, Ohad Ben-Cohen wrote:
>>> On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>> This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc:
>>>> remove the get_by_name/put API") for the ref counting a rproc klist
>>>> code but has rproc_get_by_name replaced with an rproc_get_by_phandle API.
>>>
>>> The general idea makes sense to me, but I'm not sure we really do need
>>> a klist here, since the usage profile of this list is expected to be
>>> super simple: very small number of accessors, looking for small number
>>> of list members a small number of times, and probably never do need to
>>> modify the list while accessing it.
>>>
>>> I suspect that the code would be simpler to maintain, debug and
>>> understand if we just use a simple list with a simple locking
>>> methodology here.
>>
>> The klist usage is something that we restored from previous remoteproc
>> core code as used by the rproc_get_by_name() API. This was removed in
>> commit 40e575b1d0b3 ("remoteproc: remove the get_by_name/put API"). We
>> chose to use the code that had been present before rather than inventing
>> something new all over again. If you feel that a regular list is the way
>> to go forward, we can make the switch.
>
> Yes, please. Using a regular list with a simple locking methodology
> should make the code easier to understand and debug.
Ok, that makes sense, we can change this. Thanks for your input.
Regards,
Dave
>
> Thanks,
> Ohad.
>
next prev parent reply other threads:[~2015-05-18 14:33 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 19:37 [PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
[not found] ` <1427917039-43206-2-git-send-email-d-gerlach-l0cyMroinI0@public.gmane.org>
2015-05-09 7:39 ` Ohad Ben-Cohen
2015-05-09 7:39 ` Ohad Ben-Cohen
2015-05-09 7:39 ` Ohad Ben-Cohen
2015-05-11 15:09 ` Suman Anna
2015-05-11 15:09 ` Suman Anna
2015-05-16 7:18 ` Ohad Ben-Cohen
2015-05-16 7:18 ` Ohad Ben-Cohen
2015-05-18 14:33 ` Dave Gerlach [this message]
2015-05-18 14:33 ` Dave Gerlach
2015-04-01 19:37 ` [PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-05-09 7:54 ` Ohad Ben-Cohen
2015-05-09 7:54 ` Ohad Ben-Cohen
2015-05-11 14:55 ` Suman Anna
2015-05-11 14:55 ` Suman Anna
2015-04-01 19:37 ` [PATCH v3 3/4] Documentation: dt: add bindings for TI Wakeup M3 processor Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
[not found] ` <1427917039-43206-4-git-send-email-d-gerlach-l0cyMroinI0@public.gmane.org>
2015-05-11 17:28 ` Tony Lindgren
2015-05-11 17:28 ` Tony Lindgren
2015-05-11 17:28 ` Tony Lindgren
2015-04-01 19:37 ` [PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3 Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach
2015-05-09 8:42 ` Ohad Ben-Cohen
2015-05-09 8:42 ` Ohad Ben-Cohen
2015-05-11 15:01 ` Suman Anna
2015-05-11 15:01 ` Suman Anna
[not found] ` <5550C43F.3070507-l0cyMroinI0@public.gmane.org>
2015-05-16 8:43 ` Ohad Ben-Cohen
2015-05-16 8:43 ` Ohad Ben-Cohen
2015-05-16 8:43 ` Ohad Ben-Cohen
[not found] ` <1427917039-43206-1-git-send-email-d-gerlach-l0cyMroinI0@public.gmane.org>
2015-04-29 16:05 ` [PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver Suman Anna
2015-04-29 16:05 ` Suman Anna
2015-04-29 16:05 ` Suman Anna
2015-05-02 8:45 ` Ohad Ben-Cohen
2015-05-02 8:45 ` Ohad Ben-Cohen
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=5559F838.4010003@ti.com \
--to=d-gerlach@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=ohad@wizery.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.