Re: [PATCH v2] MAINTAINERS: Remove Ohad Ben-Cohen from hwspinlock subsystem

[Ohad Ben Cohen]

On Mon, Dec 18, 2023 at 3:29 PM Bagas Sanjaya  wrote:
> Commit 62c46d55688894 ("MAINTAINERS: Removing Ohad from remoteproc/rpmsg
> maintenance") removes his MAINTAINERS entry in regards to remoteproc
> subsystem due to his inactivity (the last commit with his Signed-off-by
> is 99c429cb4e628e ("remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to
> export alias") which is authored in 2015 and his last LKML message prior
> to 62c46d55688894 was [1]).
>
> Remove also his MAINTAINERS entry for hwspinlock subsystem as there is
> no point of Cc'ing maintainers who never respond in a long time.
>
> [1]: 
> https://lore.kernel.org/r/CAK=Wgbbcyi36ef1-PV8VS=m6nfoqnfgudwy6v7ocnkt0ddr...@mail.gmail.com/
>
> Signed-off-by: Bagas Sanjaya 
> ---

Acked-by: Ohad Ben Cohen 

Re: [PATCH] MAINTAINERS: Remove Ohad Ben-Cohen from hwspinlock subsystem

[Ohad Ben Cohen]

Hi Bagas,

On Sat, Dec 16, 2023 at 1:10 PM Bagas Sanjaya  wrote:
> --- a/CREDITS
> +++ b/CREDITS
> @@ -323,6 +323,7 @@ N: Ohad Ben Cohen
>  E: o...@wizery.com
>  D: Remote Processor (remoteproc) subsystem
>  D: Remote Processor Messaging (rpmsg) subsystem
> +D: Hardware spinlock (hwspinlock) subsystem

Please also add:

D: OMAP hwspinlock driver
D: OMAP remoteproc driver

Thanks,
Ohad.

Re: linux-next: remove the remoteproc tree?

[Ohad Ben-Cohen]

Hi Stephen,

On Wed, Nov 23, 2016 at 6:41 AM, Stephen Rothwell  wrote:
> Should I remove it from linux-next?

Yes, please.

Thanks,
Ohad.

Re: linux-next: remove the remoteproc tree?

[Ohad Ben-Cohen]

Hi Stephen,

On Wed, Nov 23, 2016 at 6:41 AM, Stephen Rothwell  wrote:
> Should I remove it from linux-next?

Yes, please.

Thanks,
Ohad.

Re: [GIT PULL] remoteproc updates for v4.6

[Ohad Ben-Cohen]

On Thu, Mar 17, 2016 at 3:27 AM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Mon, Mar 14, 2016 at 10:54 PM, Bjorn Andersson
> <bjorn.anders...@linaro.org> wrote:
>>
>> New driver for controlling ST's remote processors and a couple of minor
>> fixes. Also includes the addition of myself as co-maintainer.
>
> So I don't have any issue with this, but I _do_ want to get acks from
> the person I used to pull from before I switch to pulling from another
> person.
>
> Ohad?

Acked-by: Ohad Ben-Cohen <o...@wizery.com>

Thanks,
Ohad.

Re: [GIT PULL] remoteproc updates for v4.6

[Ohad Ben-Cohen]

On Thu, Mar 17, 2016 at 3:27 AM, Linus Torvalds
 wrote:
> On Mon, Mar 14, 2016 at 10:54 PM, Bjorn Andersson
>  wrote:
>>
>> New driver for controlling ST's remote processors and a couple of minor
>> fixes. Also includes the addition of myself as co-maintainer.
>
> So I don't have any issue with this, but I _do_ want to get acks from
> the person I used to pull from before I switch to pulling from another
> person.
>
> Ohad?

Acked-by: Ohad Ben-Cohen 

Thanks,
Ohad.

Re: linux-next: removal of the rpmsg tree

[Ohad Ben-Cohen]

Hi Stephen,

On Wed, Mar 9, 2016 at 7:28 AM, Stephen Rothwell  wrote:
> Hi Ohad,
>
> I noticed that the rpmsg tree
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git branch for-next
>
> has not been updated since November 2014.  I am going to remove it from
> linux-next tomorrow unless I hear that it may be useful.  It can always
> be easily added back if it proves useful in the future.

That should be fine.

FWIW, Bjorn will most likely setup another rpmsg tree and ask you to
add it to linux-next, as he's co-maintaining
remoteproc/rpmsg/hwspinlock now.

Thanks a lot,
Ohad.

Re: linux-next: removal of the rpmsg tree

[Ohad Ben-Cohen]

Hi Stephen,

On Wed, Mar 9, 2016 at 7:28 AM, Stephen Rothwell  wrote:
> Hi Ohad,
>
> I noticed that the rpmsg tree
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git branch for-next
>
> has not been updated since November 2014.  I am going to remove it from
> linux-next tomorrow unless I hear that it may be useful.  It can always
> be easily added back if it proves useful in the future.

That should be fine.

FWIW, Bjorn will most likely setup another rpmsg tree and ask you to
add it to linux-next, as he's co-maintaining
remoteproc/rpmsg/hwspinlock now.

Thanks a lot,
Ohad.

Re: [PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems

[Ohad Ben-Cohen]

On Sun, Feb 14, 2016 at 3:35 AM, Bjorn Andersson
<bjorn.anders...@linaro.org> wrote:
>
> Add myself as co-maintainer for the remote processor related subsystems,
> as agreed with Ohad.
>
> Signed-off-by: Bjorn Andersson <bjorn.anders...@linaro.org>

Thank you Bjorn for the help!

Acked-by: Ohad Ben-Cohen <o...@wizery.com>

> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4ebe2e886d36..f51056b02fcd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4989,6 +4989,7 @@ F:include/linux/hw_random.h
>
>  HARDWARE SPINLOCK CORE
>  M: Ohad Ben-Cohen <o...@wizery.com>
> +M: Bjorn Andersson <bjorn.anders...@linaro.org>
>  S: Maintained
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
>  F: Documentation/hwspinlock.txt
> @@ -9170,6 +9171,7 @@ F:include/linux/regmap.h
>
>  REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
>  M: Ohad Ben-Cohen <o...@wizery.com>
> +M: Bjorn Andersson <bjorn.anders...@linaro.org>
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
>  S: Maintained
>  F: drivers/remoteproc/
> @@ -9178,6 +9180,7 @@ F:include/linux/remoteproc.h
>
>  REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
>  M: Ohad Ben-Cohen <o...@wizery.com>
> +M: Bjorn Andersson <bjorn.anders...@linaro.org>
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
>  S: Maintained
>  F: drivers/rpmsg/
> --
> 2.5.0
>

Re: [PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems

[Ohad Ben-Cohen]

On Sun, Feb 14, 2016 at 3:35 AM, Bjorn Andersson
 wrote:
>
> Add myself as co-maintainer for the remote processor related subsystems,
> as agreed with Ohad.
>
> Signed-off-by: Bjorn Andersson 

Thank you Bjorn for the help!

Acked-by: Ohad Ben-Cohen 

> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4ebe2e886d36..f51056b02fcd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4989,6 +4989,7 @@ F:include/linux/hw_random.h
>
>  HARDWARE SPINLOCK CORE
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  S: Maintained
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
>  F: Documentation/hwspinlock.txt
> @@ -9170,6 +9171,7 @@ F:include/linux/regmap.h
>
>  REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
>  S: Maintained
>  F: drivers/remoteproc/
> @@ -9178,6 +9180,7 @@ F:    include/linux/remoteproc.h
>
>  REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
>  S: Maintained
>  F: drivers/rpmsg/
> --
> 2.5.0
>

co-maintainance of remoteproc/rpmsg/hwspinlock

[Ohad Ben-Cohen]

Hi everyone,

Due to lack of time in the next few months, I've asked Bjorn Andersson for
help with the remoteproc/rpmsg/hwspinlock maintainership.

Bjorn has kindly agreed to step up and co-maintain
remoteproc/rpmsg/hwspinlock with me, and we expect that Bjorn will start
picking up patches as soon as the next development cycle begins.

Bjorn, thanks so much and please feel free to send a MAINTAINERS patch
adding yourself as a maintainer for these three subsystems.

I will still be available for any assistance or questions,

Best wishes,
Ohad.

co-maintainance of remoteproc/rpmsg/hwspinlock

[Ohad Ben-Cohen]

Hi everyone,

Due to lack of time in the next few months, I've asked Bjorn Andersson for
help with the remoteproc/rpmsg/hwspinlock maintainership.

Bjorn has kindly agreed to step up and co-maintain
remoteproc/rpmsg/hwspinlock with me, and we expect that Bjorn will start
picking up patches as soon as the next development cycle begins.

Bjorn, thanks so much and please feel free to send a MAINTAINERS patch
adding yourself as a maintainer for these three subsystems.

I will still be available for any assistance or questions,

Best wishes,
Ohad.

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

On Mon, Dec 28, 2015 at 8:41 PM, Bjorn Andersson  wrote:
> I interpreted this as you picked patch 1-4 and didn't pay more
> attention to them, but I can't find them in your kernel.org trees. So
> I've looked through them again.
>
> Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
> a v5 of patch 2, but it's unrelated so no need to wait for a new
> version of that.

I was under the impression that Lee plans to resubmit once the
discussion around patch 2 settles, so I haven't picked the series yet.

Lee please let me know - I can take 1/3/4 and wait for the new 2 as well.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

On Mon, Dec 28, 2015 at 8:41 PM, Bjorn Andersson  wrote:
> I interpreted this as you picked patch 1-4 and didn't pay more
> attention to them, but I can't find them in your kernel.org trees. So
> I've looked through them again.
>
> Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
> a v5 of patch 2, but it's unrelated so no need to wait for a new
> version of that.

I was under the impression that Lee plans to resubmit once the
discussion around patch 2 settles, so I haven't picked the series yet.

Lee please let me know - I can take 1/3/4 and wait for the new 2 as well.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/10] omap_hwspinlock: Replace "hweight_long(i & 0xf) != 1" with "!is_power_of_2(i & 0xf)"

[Ohad Ben-Cohen]

On Mon, Dec 7, 2015 at 5:03 PM, zhaoxiu.zeng  wrote:
> is_power_of_2 is simple, and faster than "hweightN(x) == 1" on most 
> architectures.

Thanks. I'm not sure that speed is a major concern here, since this
code executes only once during the lifetime of the driver. Readability
is probably more important.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/10] omap_hwspinlock: Replace "hweight_long(i & 0xf) != 1" with "!is_power_of_2(i & 0xf)"

[Ohad Ben-Cohen]

Hi,

On Sun, Dec 6, 2015 at 12:33 PM, Zhaoxiu Zeng  wrote:
>
> From: Zeng Zhaoxiu 
>
> Signed-off-by: Zeng Zhaoxiu 

Please explain why do you think we should make this change.

Btw, the original code used is_power_of_2, but we thought hweight is
more explicit so it was adopted.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/10] omap_hwspinlock: Replace "hweight_long(i & 0xf) != 1" with "!is_power_of_2(i & 0xf)"

[Ohad Ben-Cohen]

On Mon, Dec 7, 2015 at 5:03 PM, zhaoxiu.zeng  wrote:
> is_power_of_2 is simple, and faster than "hweightN(x) == 1" on most 
> architectures.

Thanks. I'm not sure that speed is a major concern here, since this
code executes only once during the lifetime of the driver. Readability
is probably more important.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/10] omap_hwspinlock: Replace "hweight_long(i & 0xf) != 1" with "!is_power_of_2(i & 0xf)"

[Ohad Ben-Cohen]

Hi,

On Sun, Dec 6, 2015 at 12:33 PM, Zhaoxiu Zeng  wrote:
>
> From: Zeng Zhaoxiu 
>
> Signed-off-by: Zeng Zhaoxiu 

Please explain why do you think we should make this change.

Btw, the original code used is_power_of_2, but we thought hweight is
more explicit so it was adopted.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] remoteproc fixes for 4.4

[Ohad Ben-Cohen]

The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4:

  Linux 4.4-rc2 (2015-11-22 16:45:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-4.4-fixes

for you to fetch changes up to f42f79af16ce2e8fff49ea9ba4949d3abdd6f26f:

  remoteproc: fix memory leak of remoteproc ida cache layers
(2015-11-26 17:44:28 +0200)


Remoteproc fixes for 4.4: two 1-liners coming from Suman and Arnd.


Arnd Bergmann (1):
  remoteproc: avoid stack overflow in debugfs file

Suman Anna (1):
  remoteproc: fix memory leak of remoteproc ida cache layers

 drivers/remoteproc/remoteproc_core.c| 2 ++
 drivers/remoteproc/remoteproc_debugfs.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] remoteproc fixes for 4.4

[Ohad Ben-Cohen]

The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4:

  Linux 4.4-rc2 (2015-11-22 16:45:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-4.4-fixes

for you to fetch changes up to f42f79af16ce2e8fff49ea9ba4949d3abdd6f26f:

  remoteproc: fix memory leak of remoteproc ida cache layers
(2015-11-26 17:44:28 +0200)


Remoteproc fixes for 4.4: two 1-liners coming from Suman and Arnd.


Arnd Bergmann (1):
  remoteproc: avoid stack overflow in debugfs file

Suman Anna (1):
  remoteproc: fix memory leak of remoteproc ida cache layers

 drivers/remoteproc/remoteproc_core.c| 2 ++
 drivers/remoteproc/remoteproc_debugfs.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] remoteproc: fix memory leak of remoteproc ida cache layers

[Ohad Ben-Cohen]

On Thu, Nov 26, 2015 at 12:37 PM, Michael S. Tsirkin  wrote:
> On Thu, Nov 26, 2015 at 11:38:06AM +0200, Ohad Ben-Cohen wrote:
>> I saw there was some discussion about this between Michael, James and
>> Tejun whether this should be fixed in the IDA core or not.
>>
>> Has it been resolved?
>
> I don't think we reached any conclusions.
> I guess I'll merge the virtio patch as-is then.
> Ohad, would you like to merge 2/2?

Sure, applied 2/2 to remoteproc-fixes. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias

[Ohad Ben-Cohen]

On Wed, Sep 16, 2015 at 3:32 PM, Dave Gerlach  wrote:
> Use MODULE_DEVICE_TABLE with wkup_m3_rproc_of_match so the module alias
> is exported and the wkup_m3_rproc driver can automatically probe.
>
> Signed-off-by: Dave Gerlach 

Applied to remoteproc-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] remoteproc: fix memory leak of remoteproc ida cache layers

[Ohad Ben-Cohen]

Hi Suman,

On Thu, Sep 17, 2015 at 3:29 AM, Suman Anna  wrote:
> The remoteproc core uses a static ida named rproc_dev_index for
> assigning an automatic index number to a registered remoteproc.
> The ida core may allocate some internal idr cache layers and ida
> bitmap upon any ida allocation, and all these layers are truely
> freed only upon the ida destruction. The rproc_dev_index ida is
> not destroyed at present, leading to a memory leak when using the
> remoteproc core as a module and atleast one rproc device is
> registered and unregistered.
>
> Fix this by invoking ida_destroy() in the remoteproc core module
> exit.

I saw there was some discussion about this between Michael, James and
Tejun whether this should be fixed in the IDA core or not.

Has it been resolved?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones  wrote:
> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones  wrote:
>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
>> > on-board.  This provides the Linux-side infrastructure to flash and boot
>> > them successfully.
>> >
>> > This set has been tested on an STiH410-B2120.
>>
>> It would be nice if you could get at least one Reviewed-by tag coming
>> outside of ST (e.g., Suman or Bjorn who are actively using and
>> improving remoteproc).
>
> If you require reviews by these guys, shouldn't they be Maintainers?

Additional review isn't a requirement, but it's a plus.

> Please be aware that
> the DTS(I) changes are applied to this set for your information only
> and are not to be applied through the RemoteProc tree.  The usual
> process to which we conform is that Maxime (the STi Maintainer) will
> apply the DT changes *after* the main driver has been applied, in this
> case by you.

Ok, great, so I will not take patches 5 and 6.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] remoteproc: report error if resource table doesn't exist

[Ohad Ben-Cohen]

Hi Stefan,

On Sat, Aug 29, 2015 at 4:08 AM, Stefan Agner  wrote:
> Currently, if the resource table is completely missing in the
> firmware, powering up the remoteproc fails silently. Add a message
> indicating that the resource table is missing in the firmware.
>
> Signed-off-by: Stefan Agner 

Applied to remoteproc-next, thanks.

> This also opens up a more general question: Is it mandatory to have
> a resource table in the firmware?

The implementation we have today does require it, but that's just
because this is what we had to support so far.

> Theoretically a remoteproc could
> also work completely independent, all what would be used from the
> remoteproc framework is the loading and starting capabilities...

Sure. Feel free to add support for your hardware as needed.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

Hi Lee,

On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones  wrote:
> ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> on-board.  This provides the Linux-side infrastructure to flash and boot
> them successfully.
>
> This set has been tested on an STiH410-B2120.

It would be nice if you could get at least one Reviewed-by tag coming
outside of ST (e.g., Suman or Bjorn who are actively using and
improving remoteproc).

>  arch/arm/boot/dts/stih407-family.dtsi  |  70 +

Since this is outside of remoteproc, please have it Acked, preferably
by ARM DT maintainer (Olof?).

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] remoteproc: avoid stack overflow in debugfs file

[Ohad Ben-Cohen]

On Fri, Nov 20, 2015 at 7:26 PM, Arnd Bergmann  wrote:
> Recent gcc versions warn about reading from a negative offset of
> an on-stack array:
>
> drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':
> drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> I don't see anything in sys_write() that prevents us from
> being called with a zero 'count' argument, so we should
> add an extra check in rproc_recovery_write() to prevent the
> access and avoid the warning.
>
> Signed-off-by: Arnd Bergmann 
> Fixes: 2e37abb89a2e ("remoteproc: create a 'recovery' debugfs entry")

Applied to remoteproc-fixes, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] remoteproc: avoid stack overflow in debugfs file

[Ohad Ben-Cohen]

On Fri, Nov 20, 2015 at 7:26 PM, Arnd Bergmann  wrote:
> Recent gcc versions warn about reading from a negative offset of
> an on-stack array:
>
> drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':
> drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> I don't see anything in sys_write() that prevents us from
> being called with a zero 'count' argument, so we should
> add an extra check in rproc_recovery_write() to prevent the
> access and avoid the warning.
>
> Signed-off-by: Arnd Bergmann 
> Fixes: 2e37abb89a2e ("remoteproc: create a 'recovery' debugfs entry")

Applied to remoteproc-fixes, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

Hi Lee,

On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones  wrote:
> ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> on-board.  This provides the Linux-side infrastructure to flash and boot
> them successfully.
>
> This set has been tested on an STiH410-B2120.

It would be nice if you could get at least one Reviewed-by tag coming
outside of ST (e.g., Suman or Bjorn who are actively using and
improving remoteproc).

>  arch/arm/boot/dts/stih407-family.dtsi  |  70 +

Since this is outside of remoteproc, please have it Acked, preferably
by ARM DT maintainer (Olof?).

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] remoteproc: report error if resource table doesn't exist

[Ohad Ben-Cohen]

Hi Stefan,

On Sat, Aug 29, 2015 at 4:08 AM, Stefan Agner  wrote:
> Currently, if the resource table is completely missing in the
> firmware, powering up the remoteproc fails silently. Add a message
> indicating that the resource table is missing in the firmware.
>
> Signed-off-by: Stefan Agner 

Applied to remoteproc-next, thanks.

> This also opens up a more general question: Is it mandatory to have
> a resource table in the firmware?

The implementation we have today does require it, but that's just
because this is what we had to support so far.

> Theoretically a remoteproc could
> also work completely independent, all what would be used from the
> remoteproc framework is the loading and starting capabilities...

Sure. Feel free to add support for your hardware as needed.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones <lee.jo...@linaro.org> wrote:
> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <lee.jo...@linaro.org> wrote:
>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
>> > on-board.  This provides the Linux-side infrastructure to flash and boot
>> > them successfully.
>> >
>> > This set has been tested on an STiH410-B2120.
>>
>> It would be nice if you could get at least one Reviewed-by tag coming
>> outside of ST (e.g., Suman or Bjorn who are actively using and
>> improving remoteproc).
>
> If you require reviews by these guys, shouldn't they be Maintainers?

Additional review isn't a requirement, but it's a plus.

> Please be aware that
> the DTS(I) changes are applied to this set for your information only
> and are not to be applied through the RemoteProc tree.  The usual
> process to which we conform is that Maxime (the STi Maintainer) will
> apply the DT changes *after* the main driver has been applied, in this
> case by you.

Ok, great, so I will not take patches 5 and 6.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] remoteproc: fix memory leak of remoteproc ida cache layers

[Ohad Ben-Cohen]

Hi Suman,

On Thu, Sep 17, 2015 at 3:29 AM, Suman Anna  wrote:
> The remoteproc core uses a static ida named rproc_dev_index for
> assigning an automatic index number to a registered remoteproc.
> The ida core may allocate some internal idr cache layers and ida
> bitmap upon any ida allocation, and all these layers are truely
> freed only upon the ida destruction. The rproc_dev_index ida is
> not destroyed at present, leading to a memory leak when using the
> remoteproc core as a module and atleast one rproc device is
> registered and unregistered.
>
> Fix this by invoking ida_destroy() in the remoteproc core module
> exit.

I saw there was some discussion about this between Michael, James and
Tejun whether this should be fixed in the IDA core or not.

Has it been resolved?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias

[Ohad Ben-Cohen]

On Wed, Sep 16, 2015 at 3:32 PM, Dave Gerlach  wrote:
> Use MODULE_DEVICE_TABLE with wkup_m3_rproc_of_match so the module alias
> is exported and the wkup_m3_rproc driver can automatically probe.
>
> Signed-off-by: Dave Gerlach 

Applied to remoteproc-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] remoteproc: fix memory leak of remoteproc ida cache layers

[Ohad Ben-Cohen]

On Thu, Nov 26, 2015 at 12:37 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> On Thu, Nov 26, 2015 at 11:38:06AM +0200, Ohad Ben-Cohen wrote:
>> I saw there was some discussion about this between Michael, James and
>> Tejun whether this should be fixed in the IDA core or not.
>>
>> Has it been resolved?
>
> I don't think we reached any conclusions.
> I guess I'll merge the virtio patch as-is then.
> Ohad, would you like to merge 2/2?

Sure, applied 2/2 to remoteproc-fixes. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

On Fri, Aug 14, 2015 at 6:24 PM, Lina Iyer  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

On Fri, Aug 14, 2015 at 6:24 PM, Lina Iyer  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

On Thu, Aug 13, 2015 at 6:25 PM, Andy Gross  wrote:
> The issue in hardwiring this into the driver itself means forfeiting
> extensibility.  So on one side (w/ raw support), we get the ability to deal 
> with
> the lock number changing.  On the other side (w/o raw), we'd have to probably
> tie this to chip compat to figure out which lock is the 'special' if it ever
> changes.

It sounds like the decision "which lock to use" is a separate problem
from "can it go raw".

If the hardware doesn't prohibit raw mode, then every lock can be used
in raw mode. So you just have to pick one and make sure both sides
know which lock you use --- which is a classic multi-processor
synchronization issue.

> It's arbitrary right now.  The remote processor selected a number, not the
> processor running Linux.

Is the number hardcoded right now? and you're using
hwspin_lock_request_specific on the Linux side to acquire the lock?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

On Thu, Aug 13, 2015 at 6:25 PM, Andy Gross agr...@codeaurora.org wrote:
 The issue in hardwiring this into the driver itself means forfeiting
 extensibility.  So on one side (w/ raw support), we get the ability to deal 
 with
 the lock number changing.  On the other side (w/o raw), we'd have to probably
 tie this to chip compat to figure out which lock is the 'special' if it ever
 changes.

It sounds like the decision which lock to use is a separate problem
from can it go raw.

If the hardware doesn't prohibit raw mode, then every lock can be used
in raw mode. So you just have to pick one and make sure both sides
know which lock you use --- which is a classic multi-processor
synchronization issue.

 It's arbitrary right now.  The remote processor selected a number, not the
 processor running Linux.

Is the number hardcoded right now? and you're using
hwspin_lock_request_specific on the Linux side to acquire the lock?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer  wrote:
>> Let's not make this more complicated than needed, so please add the
>> hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
>> could always change this later if it proves to be insufficient.
>>
> 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, while another driver may
> 'acquire' the lock (since the value written to the lock would be the
> same as raw api would). That is why you should have the capability on
> hwspinlock and not on hwspinlock_device. Locks that are defined are RAW
> capable should be used as RAW only.
>
> QCOM platform hwlock #7 is unique that different CPUs trying to acquire
> the lock would write different values and hence would be fine. But, the
> same is not true for other locks in the bank.

As far as I understand, there is nothing special about QCOM's hwlock
#7 in terms of hardware. It's exactly the same lock as all the others.

The only difference in hwlock #7 is the way you use it, and that
sounds like a decision the driver should be able to make. It's a
policy, and I'm not sure we should put it in the DT. I'm also not sure
we need this hwlock-specific complexity in the hwspinlock framework.

The driver already makes a decision whether to disable the interrupts
or not and whether to save their state or not. So it can also make a
decision whether to take a sw spinlock at all or not --- if the
hardware allows it. and that if should be encoded in an accessible
vendor specific (not hwlock specific) struct, which is setup by the
underlying vendor specific hwspinlock driver (no DT involved).

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.

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

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer lina.i...@linaro.org wrote:
 Let's not make this more complicated than needed, so please add the
 hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
 could always change this later if it proves to be insufficient.

 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, while another driver may
 'acquire' the lock (since the value written to the lock would be the
 same as raw api would). That is why you should have the capability on
 hwspinlock and not on hwspinlock_device. Locks that are defined are RAW
 capable should be used as RAW only.

 QCOM platform hwlock #7 is unique that different CPUs trying to acquire
 the lock would write different values and hence would be fine. But, the
 same is not true for other locks in the bank.

As far as I understand, there is nothing special about QCOM's hwlock
#7 in terms of hardware. It's exactly the same lock as all the others.

The only difference in hwlock #7 is the way you use it, and that
sounds like a decision the driver should be able to make. It's a
policy, and I'm not sure we should put it in the DT. I'm also not sure
we need this hwlock-specific complexity in the hwspinlock framework.

The driver already makes a decision whether to disable the interrupts
or not and whether to save their state or not. So it can also make a
decision whether to take a sw spinlock at all or not --- if the
hardware allows it. and that if should be encoded in an accessible
vendor specific (not hwlock specific) struct, which is setup by the
underlying vendor specific hwspinlock driver (no DT involved).

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.

 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.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

Hi Lina,

On Thu, Jul 2, 2015 at 11:30 PM, Lina Iyer  wrote:
> You are right, RAW capability is not lock specific. But we dont want to
> impose this on every lock in the bank either.

I'm not sure I'm following your concern here: drivers still need to
explicitly indicate RAW in order for this to kick in, so this lenient
approach is not being imposed on them.

Your original patch allowed every driver on all platforms to disable
the sw spinlock mechanism. What I'm merely suggesting is that the
underlying platform-specific driver should first allow this before it
is being used, as some vendors prohibit this completely.

Let's not make this more complicated than needed, so please add the
hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
could always change this later if it proves to be insufficient.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

Hi Lina,

On Thu, Jul 2, 2015 at 11:30 PM, Lina Iyer lina.i...@linaro.org wrote:
 You are right, RAW capability is not lock specific. But we dont want to
 impose this on every lock in the bank either.

I'm not sure I'm following your concern here: drivers still need to
explicitly indicate RAW in order for this to kick in, so this lenient
approach is not being imposed on them.

Your original patch allowed every driver on all platforms to disable
the sw spinlock mechanism. What I'm merely suggesting is that the
underlying platform-specific driver should first allow this before it
is being used, as some vendors prohibit this completely.

Let's not make this more complicated than needed, so please add the
hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
could always change this later if it proves to be insufficient.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] remoteproc for 4.2

[Ohad Ben-Cohen]

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-4.2

for you to fetch changes up to 8de3dbd0895bebe52d069a82feae8e3fb51c1bdf:

  remoteproc: fix !CONFIG_OF build breakage (2015-06-18 11:44:41 +0300)


- remoteproc fixes/cleanups from Suman Anna
- new remoteproc TI Wakeup M3 driver from Dave Gerlach
- remoteproc core support for TI's Wakeup M3 driver from both Dave and Suman
- tiny remoteproc build fix from myself


Dave Gerlach (3):
  remoteproc: introduce rproc_get_by_phandle API
  Documentation: dt: add bindings for TI Wakeup M3 processor
  remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

Ohad Ben-Cohen (1):
  remoteproc: fix !CONFIG_OF build breakage

Suman Anna (4):
  remoteproc/ste: add blank lines after declarations
  remoteproc/davinci: fix quoted split string checkpatch warning
  remoteproc: fix various checkpatch warnings
  remoteproc: add a rproc ops for performing address translation

 Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt |  52
++
 Documentation/remoteproc.txt   |   6 +++
 drivers/remoteproc/Kconfig |  13 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/da8xx_remoteproc.c  |   3 +-
 drivers/remoteproc/remoteproc_core.c   | 115
+--
 drivers/remoteproc/remoteproc_internal.h   |   2 +-
 drivers/remoteproc/ste_modem_rproc.c   |   4 +-
 drivers/remoteproc/wkup_m3_rproc.c | 257
+
 include/linux/platform_data/wkup_m3.h  |  30
+
 include/linux/remoteproc.h |   9 ++--
 11 files changed, 460 insertions(+), 32 deletions(-)
 create mode 100644
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] hwspinlock for 4.2

[Ohad Ben-Cohen]

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-4.2

for you to fetch changes up to bd5717a4632cdecafe82d03de7dcb3b1876e2828:

  hwspinlock: qcom: Correct msb in regmap_field (2015-07-01 16:15:05 +0300)


- hwspinlock core DT support from Suman Anna
- OMAP hwspinlock DT support from Suman Anna
- QCOM hwspinlock DT support from Bjorn Andersson
- a new CSR atlas7 hwspinlock driver from Wei Chen
- CSR atlas7 hwspinlock DT binding document from Wei Chen
- a tiny QCOM hwspinlock driver fix from Bjorn Andersson


Bjorn Andersson (3):
  DT: hwspinlock: Add binding documentation for Qualcomm hwmutex
  hwspinlock: qcom: Add support for Qualcomm HW Mutex block
  hwspinlock: qcom: Correct msb in regmap_field

Suman Anna (4):
  Documentation: dt: add common bindings for hwspinlock
  hwspinlock/core: add device tree support
  Documentation: dt: add the omap hwspinlock bindings document
  hwspinlock/omap: add support for dt nodes

Wei Chen (2):
  hwspinlock: add a CSR atlas7 driver
  DT: hwspinlock: add the CSR atlas7 hwspinlock bindings document

 Documentation/devicetree/bindings/hwlock/hwlock.txt  |  59
+++
 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt |  26

 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt |  39
+++
 Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt |  28
+
 Documentation/hwspinlock.txt |  10 ++
 MAINTAINERS  |   1 -
 arch/arm/mach-omap2/Makefile |   3 --
 arch/arm/mach-omap2/hwspinlock.c |  60

 drivers/hwspinlock/Kconfig   |  24
+++
 drivers/hwspinlock/Makefile  |   2 ++
 drivers/hwspinlock/hwspinlock_core.c |  79
+++
 drivers/hwspinlock/omap_hwspinlock.c |  18 ---
 drivers/hwspinlock/qcom_hwspinlock.c | 181
+++
 drivers/hwspinlock/sirf_hwspinlock.c | 136

 include/linux/hwspinlock.h   |   7 +
 15 files changed, 605 insertions(+), 68 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
 create mode 100644 drivers/hwspinlock/qcom_hwspinlock.c
 create mode 100644 drivers/hwspinlock/sirf_hwspinlock.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] hwspinlock for 4.2

[Ohad Ben-Cohen]

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-4.2

for you to fetch changes up to bd5717a4632cdecafe82d03de7dcb3b1876e2828:

  hwspinlock: qcom: Correct msb in regmap_field (2015-07-01 16:15:05 +0300)


- hwspinlock core DT support from Suman Anna
- OMAP hwspinlock DT support from Suman Anna
- QCOM hwspinlock DT support from Bjorn Andersson
- a new CSR atlas7 hwspinlock driver from Wei Chen
- CSR atlas7 hwspinlock DT binding document from Wei Chen
- a tiny QCOM hwspinlock driver fix from Bjorn Andersson


Bjorn Andersson (3):
  DT: hwspinlock: Add binding documentation for Qualcomm hwmutex
  hwspinlock: qcom: Add support for Qualcomm HW Mutex block
  hwspinlock: qcom: Correct msb in regmap_field

Suman Anna (4):
  Documentation: dt: add common bindings for hwspinlock
  hwspinlock/core: add device tree support
  Documentation: dt: add the omap hwspinlock bindings document
  hwspinlock/omap: add support for dt nodes

Wei Chen (2):
  hwspinlock: add a CSR atlas7 driver
  DT: hwspinlock: add the CSR atlas7 hwspinlock bindings document

 Documentation/devicetree/bindings/hwlock/hwlock.txt  |  59
+++
 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt |  26

 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt |  39
+++
 Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt |  28
+
 Documentation/hwspinlock.txt |  10 ++
 MAINTAINERS  |   1 -
 arch/arm/mach-omap2/Makefile |   3 --
 arch/arm/mach-omap2/hwspinlock.c |  60

 drivers/hwspinlock/Kconfig   |  24
+++
 drivers/hwspinlock/Makefile  |   2 ++
 drivers/hwspinlock/hwspinlock_core.c |  79
+++
 drivers/hwspinlock/omap_hwspinlock.c |  18 ---
 drivers/hwspinlock/qcom_hwspinlock.c | 181
+++
 drivers/hwspinlock/sirf_hwspinlock.c | 136

 include/linux/hwspinlock.h   |   7 +
 15 files changed, 605 insertions(+), 68 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
 create mode 100644 drivers/hwspinlock/qcom_hwspinlock.c
 create mode 100644 drivers/hwspinlock/sirf_hwspinlock.c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] remoteproc for 4.2

[Ohad Ben-Cohen]

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-4.2

for you to fetch changes up to 8de3dbd0895bebe52d069a82feae8e3fb51c1bdf:

  remoteproc: fix !CONFIG_OF build breakage (2015-06-18 11:44:41 +0300)


- remoteproc fixes/cleanups from Suman Anna
- new remoteproc TI Wakeup M3 driver from Dave Gerlach
- remoteproc core support for TI's Wakeup M3 driver from both Dave and Suman
- tiny remoteproc build fix from myself


Dave Gerlach (3):
  remoteproc: introduce rproc_get_by_phandle API
  Documentation: dt: add bindings for TI Wakeup M3 processor
  remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

Ohad Ben-Cohen (1):
  remoteproc: fix !CONFIG_OF build breakage

Suman Anna (4):
  remoteproc/ste: add blank lines after declarations
  remoteproc/davinci: fix quoted split string checkpatch warning
  remoteproc: fix various checkpatch warnings
  remoteproc: add a rproc ops for performing address translation

 Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt |  52
++
 Documentation/remoteproc.txt   |   6 +++
 drivers/remoteproc/Kconfig |  13 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/da8xx_remoteproc.c  |   3 +-
 drivers/remoteproc/remoteproc_core.c   | 115
+--
 drivers/remoteproc/remoteproc_internal.h   |   2 +-
 drivers/remoteproc/ste_modem_rproc.c   |   4 +-
 drivers/remoteproc/wkup_m3_rproc.c | 257
+
 include/linux/platform_data/wkup_m3.h  |  30
+
 include/linux/remoteproc.h |   9 ++--
 11 files changed, 460 insertions(+), 32 deletions(-)
 create mode 100644
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

Hi Lina,

On Sat, Jun 27, 2015 at 6:05 AM, Lina Iyer  wrote:
> Hi Ohad,
>
> Any comments?

Sorry, I was under the impression the discussion with Bjorn is still open.

Like Bjorn, I'm not so sure too we want to bind a specific lock to the
RAW capability since this is not a lock-specific hardware detail.

As far as I can see, the hardware-specific differences (if any) are at
the vendor level and not at the lock level, therefore it might make
more sense to add the caps member to hwspinlock_device rather than to
the hwspinlock struct (Jeffrey commented about this too).

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Ohad Ben-Cohen]

Hi Lina,

On Sat, Jun 27, 2015 at 6:05 AM, Lina Iyer lina.i...@linaro.org wrote:
 Hi Ohad,

 Any comments?

Sorry, I was under the impression the discussion with Bjorn is still open.

Like Bjorn, I'm not so sure too we want to bind a specific lock to the
RAW capability since this is not a lock-specific hardware detail.

As far as I can see, the hardware-specific differences (if any) are at
the vendor level and not at the lock level, therefore it might make
more sense to add the caps member to hwspinlock_device rather than to
the hwspinlock struct (Jeffrey commented about this too).

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/4] remoteproc: introduce rproc_get_by_phandle API

[Ohad Ben-Cohen]

On Thu, Jun 18, 2015 at 7:01 PM, Dave Gerlach  wrote:
> Oh sorry about. Pulled your for-next, tried it out, everything looks good to 
> me,
> thanks!

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/4] remoteproc: introduce rproc_get_by_phandle API

[Ohad Ben-Cohen]

Hi Dave,

On Wed, Jun 17, 2015 at 9:46 PM, Dave Gerlach  wrote:
> Allow users of remoteproc the ability to get a handle to an rproc by
> passing a phandle supplied in the user's device tree node. This is
> useful in situations that require manual booting of the rproc.
>
> This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc:
> remove the get_by_name/put API") for the ref counting but is modified
> to use a simple list and locking mechanism and has rproc_get_by_name
> replaced with an rproc_get_by_phandle API.
>
> Signed-off-by: Dave Gerlach 
> Signed-off-by: Suman Anna 
> ---
> v4->v5: Fixed build error from of_find_node_by_phandle when !CONFIG_OF
> based on offline discussion.

We can't rebase our for-next branch, so I've applied a
similar fix in a separate patch.

Please check our for-next branch to make sure things still work for you.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/4] remoteproc: introduce rproc_get_by_phandle API

[Ohad Ben-Cohen]

On Thu, Jun 18, 2015 at 7:01 PM, Dave Gerlach d-gerl...@ti.com wrote:
 Oh sorry about. Pulled your for-next, tried it out, everything looks good to 
 me,
 thanks!

Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/4] remoteproc: introduce rproc_get_by_phandle API

[Ohad Ben-Cohen]

Hi Dave,

On Wed, Jun 17, 2015 at 9:46 PM, Dave Gerlach d-gerl...@ti.com wrote:
 Allow users of remoteproc the ability to get a handle to an rproc by
 passing a phandle supplied in the user's device tree node. This is
 useful in situations that require manual booting of the rproc.

 This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
 remove the get_by_name/put API) for the ref counting but is modified
 to use a simple list and locking mechanism and has rproc_get_by_name
 replaced with an rproc_get_by_phandle API.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 Signed-off-by: Suman Anna s-a...@ti.com
 ---
 v4-v5: Fixed build error from of_find_node_by_phandle when !CONFIG_OF
 based on offline discussion.

We can't rebase our for-next branch, so I've applied a
similar fix in a separate patch.

Please check our for-next branch to make sure things still work for you.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 0/4] remoteproc: Introduce wkup_m3_rproc driver

[Ohad Ben-Cohen]

On Fri, May 22, 2015 at 11:45 PM, Dave Gerlach  wrote:
> Hi,
> This patch series is v4 of the series to add a wkup_m3_rproc driver
> for TI AM335xi and AM437x SoCs. This family of SoCs contains an ARM
> Cortex M3 coprocessor that is responsible for low-level power tasks
> that cannot be handled by the main ARM Cortex A8 so firmware running
> from the CM3 can be used instead. This driver handles loading
> of the firmware and reset of the CM3. Change info can be found
> with each patch.

Applied all 4 patches to remoteproc's for-next branch.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 0/4] remoteproc: Introduce wkup_m3_rproc driver

[Ohad Ben-Cohen]

On Fri, May 22, 2015 at 11:45 PM, Dave Gerlach d-gerl...@ti.com wrote:
 Hi,
 This patch series is v4 of the series to add a wkup_m3_rproc driver
 for TI AM335xi and AM437x SoCs. This family of SoCs contains an ARM
 Cortex M3 coprocessor that is responsible for low-level power tasks
 that cannot be handled by the main ARM Cortex A8 so firmware running
 from the CM3 can be used instead. This driver handles loading
 of the firmware and reset of the CM3. Change info can be found
 with each patch.

Applied all 4 patches to remoteproc's for-next branch.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

On Sat, Jun 6, 2015 at 2:50 AM, Jeffrey Hugo  wrote:
> If you still wish to scope out a capability based alternative, would you
> please provide some details about how you envision it working?  An example
> of the API, how it would be used, future usecases that might be covered by
> it, etc.  That would give us specifics we can discuss and weigh the merits
> of.

How about:
- add a 'hwcaps' member to hwspinlock_device, and define single cap
called HWL_CAP_ALLOW_RAW
- add new 'hwcaps' parameter to hwspin_lock_register
- omap_hwspinlock.c will pass NULL, qcom_hwspinlock will pass HWL_CAP_ALLOW_RAW
- hwspin_lock_register will set hwcaps accordingly
- before a lock is taken in RAW mode, the capabilities are checked
- document everything nicely

Unless I'm missing something, it should take 5 minutes or less. For
reference, feel free to check out mmc_host's caps member and its
usage.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

On Sat, Jun 6, 2015 at 2:50 AM, Jeffrey Hugo jh...@codeaurora.org wrote:
 If you still wish to scope out a capability based alternative, would you
 please provide some details about how you envision it working?  An example
 of the API, how it would be used, future usecases that might be covered by
 it, etc.  That would give us specifics we can discuss and weigh the merits
 of.

How about:
- add a 'hwcaps' member to hwspinlock_device, and define single cap
called HWL_CAP_ALLOW_RAW
- add new 'hwcaps' parameter to hwspin_lock_register
- omap_hwspinlock.c will pass NULL, qcom_hwspinlock will pass HWL_CAP_ALLOW_RAW
- hwspin_lock_register will set hwcaps accordingly
- before a lock is taken in RAW mode, the capabilities are checked
- document everything nicely

Unless I'm missing something, it should take 5 minutes or less. For
reference, feel free to check out mmc_host's caps member and its
usage.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

On Tue, May 26, 2015 at 11:36 PM, Lina Iyer  wrote:
>> Just to make sure I understand, is this how your scenario is solved?
>>
>> - c1 goes down
>> - c0 goes down, carries information about shared resources
>> - c1 takes HWLOCK and calls into SCM, stuck handling FIQs
>> - c0 wants to call into SCM but is waiting spinning on HWLOCK
>> - c1 completes handling FIQs, goes idle, HWLOCK is released by secure monitor
>> - c0 takes HWLOCK, calls into SCM, shared resources handled correctly,
>>
>> HWLOCK in this example is a single shared hwspinlock accessible by c0,
>> c1 and secure monitor.
>>
> That is correct.

Ok, thanks.

If we adopt the proposed approach in your patch, I'm thinking maybe we
should restrict it only to hardware implementations that explicitly
allow it, using some hardware capability flag published by the
hwspinlock driver.

In OMAP, e.g., it is prohibited to spin on this hwlock for a long
period of time, so such a hw cap flag would allow you guys to enable
this behaviour specifically for your driver.

What do you think?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

On Tue, May 26, 2015 at 11:36 PM, Lina Iyer lina.i...@linaro.org wrote:
 Just to make sure I understand, is this how your scenario is solved?

 - c1 goes down
 - c0 goes down, carries information about shared resources
 - c1 takes HWLOCK and calls into SCM, stuck handling FIQs
 - c0 wants to call into SCM but is waiting spinning on HWLOCK
 - c1 completes handling FIQs, goes idle, HWLOCK is released by secure monitor
 - c0 takes HWLOCK, calls into SCM, shared resources handled correctly,

 HWLOCK in this example is a single shared hwspinlock accessible by c0,
 c1 and secure monitor.

 That is correct.

Ok, thanks.

If we adopt the proposed approach in your patch, I'm thinking maybe we
should restrict it only to hardware implementations that explicitly
allow it, using some hardware capability flag published by the
hwspinlock driver.

In OMAP, e.g., it is prohibited to spin on this hwlock for a long
period of time, so such a hw cap flag would allow you guys to enable
this behaviour specifically for your driver.

What do you think?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

Hi Lina,

On Mon, May 18, 2015 at 6:03 PM, Lina Iyer  wrote:
> The lock in question is used differently than traditional locks across
> processors. This lock helps synchronizes context transition from
> non-secure to secure on the same processor.
>
> The usecase, goes like this. In cpuidle, any core can be the last core
> to power down. The last man also holds the responsibility of shutting
> down shared resources like caches etc. The way the power down of a core
> works is, there are some high level decisions made in Linux and these
> decisions (like to flush and invalidate caches) etc gets transferred
> over to the the secure layer. The secure layer executes the ARM WFI that
> powers down the cpu, but uses these decisions passed into to determine
> if the cache needs to be invalidated upon wakeup etc.
>
> There is a possible race condition between what Linux thinks is the last
> core, vs what secure layer thinks is the last core. Lets say, two cores
> c0, c1 are going down. c1 is the second last core to go down from Linux
> as such, will not carry information about shared resources when making
> the SCM call. c1  made the SCM call, but is stuck handling some FIQs. In
> the meanwhile c0, goes idle and since its the last core in Linux,
> figures out the state of the shared resources. c0 calls into SCM, and
> ends up powering down earlier than c1. Per secure layer, the last core
> to go down is c1 and the votes of the shared resources are considered
> from that core. Things like cache invalidation without flush may happen
> as a result of this inconsistency of last man view point.
>
> The way we have solved it, Linux acquires a hw spinlock for each core,
> when calling into SCM and the secure monitor releases the spinlock. At
> any given time, only one core can switch the context from Linux to
> secure for power down operations. This guarantees the last man is
> synchronized between both Linux and secure. Another core may be spinning
> waiting for hw mutex, but they all happen serialized. This mutex is held
> in an irq disable context in cpuidle.
>
> There may be another processor spining to wait on hw mutex, but there
> isnt much to do otherwise, because the only operation at this time while
> holding the lock is to call into SCM and that would unlock the mutex.

Just to make sure I understand, is this how your scenario is solved?

- c1 goes down
- c0 goes down, carries information about shared resources
- c1 takes HWLOCK and calls into SCM, stuck handling FIQs
- c0 wants to call into SCM but is waiting spinning on HWLOCK
- c1 completes handling FIQs, goes idle, HWLOCK is released by secure monitor
- c0 takes HWLOCK, calls into SCM, shared resources handled correctly,

HWLOCK in this example is a single shared hwspinlock accessible by c0,
c1 and secure monitor.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

Hi Lina,

On Mon, May 18, 2015 at 6:03 PM, Lina Iyer lina.i...@linaro.org wrote:
 The lock in question is used differently than traditional locks across
 processors. This lock helps synchronizes context transition from
 non-secure to secure on the same processor.

 The usecase, goes like this. In cpuidle, any core can be the last core
 to power down. The last man also holds the responsibility of shutting
 down shared resources like caches etc. The way the power down of a core
 works is, there are some high level decisions made in Linux and these
 decisions (like to flush and invalidate caches) etc gets transferred
 over to the the secure layer. The secure layer executes the ARM WFI that
 powers down the cpu, but uses these decisions passed into to determine
 if the cache needs to be invalidated upon wakeup etc.

 There is a possible race condition between what Linux thinks is the last
 core, vs what secure layer thinks is the last core. Lets say, two cores
 c0, c1 are going down. c1 is the second last core to go down from Linux
 as such, will not carry information about shared resources when making
 the SCM call. c1  made the SCM call, but is stuck handling some FIQs. In
 the meanwhile c0, goes idle and since its the last core in Linux,
 figures out the state of the shared resources. c0 calls into SCM, and
 ends up powering down earlier than c1. Per secure layer, the last core
 to go down is c1 and the votes of the shared resources are considered
 from that core. Things like cache invalidation without flush may happen
 as a result of this inconsistency of last man view point.

 The way we have solved it, Linux acquires a hw spinlock for each core,
 when calling into SCM and the secure monitor releases the spinlock. At
 any given time, only one core can switch the context from Linux to
 secure for power down operations. This guarantees the last man is
 synchronized between both Linux and secure. Another core may be spinning
 waiting for hw mutex, but they all happen serialized. This mutex is held
 in an irq disable context in cpuidle.

 There may be another processor spining to wait on hw mutex, but there
 isnt much to do otherwise, because the only operation at this time while
 holding the lock is to call into SCM and that would unlock the mutex.

Just to make sure I understand, is this how your scenario is solved?

- c1 goes down
- c0 goes down, carries information about shared resources
- c1 takes HWLOCK and calls into SCM, stuck handling FIQs
- c0 wants to call into SCM but is waiting spinning on HWLOCK
- c1 completes handling FIQs, goes idle, HWLOCK is released by secure monitor
- c0 takes HWLOCK, calls into SCM, shared resources handled correctly,

HWLOCK in this example is a single shared hwspinlock accessible by c0,
c1 and secure monitor.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

On Mon, May 11, 2015 at 5:46 PM, Lina Iyer  wrote:
> On Sat, May 09 2015 at 03:25 -0600, Ohad Ben-Cohen wrote:
>> On Fri, May 1, 2015 at 8:07 PM, Lina Iyer  wrote:
>> Let's discuss whether we really want to expose this functionality
>> under the same hwspinlock API or not.
>>
>> In this new mode, unlike previously, users will now be able to sleep
>> after taking the lock, and others trying to take the lock might poll
>> the hardware for a long period of time without the ability to sleep
>> while waiting for the lock. It almost sounds like you were looking for
>> some hwmutex functionality.
>
> I agree, that it opens up a possiblity that user may sleep after holding
> a hw spinlock.  But really, why should it prevents us from using it as a
> hw mutex, if the need is legitimate?

If we want hw mutex functionality, let's discuss how to expose it.
Exposing it using the existing hw spinlock API might not be ideal, as
users might get confused.

Additionally, there are hardware IP locking blocks out there which
encourage users to sleep while waiting for a lock, by providing
interrupt functionality to wake them up when the lock is freed. So if
we choose to add a hw mutex API it might be used by others in the
future too (though this reason alone is not why we would choose to add
it now of course).

API discussions aside, what do you want to happen in your scenario
while the lock is taken? are you OK with other users spinning on the
lock waiting for it to be released? IIUC that might mean processors
spinning for a non-negligible period of time?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

[Ohad Ben-Cohen]

Hi Suman,

On Mon, May 11, 2015 at 6:01 PM, Suman Anna  wrote:
> We don't have any carveouts or usage of any external DDR, as this
> processor is used during Power Management, like cpuidle or suspend path,
> and is used to control the MPU and DDR states. The resource table is
> very simple and straight-forward [1].

Ok thanks.

Could you please document in the patch how the WkupM3 memory is
managed? Perhaps add to this latter explanation of yours also what
stands behind the umem/dmem names, justify usage of '__force' and
document the code around the l4_offset math (which I suspect may not
always be correct, as it seems the value of l4_offset depends on the
order of mem resources returned by platform_get_resource_byname).

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API

[Ohad Ben-Cohen]

Hi Suman,

On Mon, May 11, 2015 at 6:09 PM, Suman Anna  wrote:
> On 05/09/2015 02:39 AM, Ohad Ben-Cohen wrote:
> > On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach  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.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API

[Ohad Ben-Cohen]

Hi Suman,

On Mon, May 11, 2015 at 6:09 PM, Suman Anna s-a...@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-gerl...@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.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

On Mon, May 11, 2015 at 5:46 PM, Lina Iyer lina.i...@linaro.org wrote:
 On Sat, May 09 2015 at 03:25 -0600, Ohad Ben-Cohen wrote:
 On Fri, May 1, 2015 at 8:07 PM, Lina Iyer lina.i...@linaro.org wrote:
 Let's discuss whether we really want to expose this functionality
 under the same hwspinlock API or not.

 In this new mode, unlike previously, users will now be able to sleep
 after taking the lock, and others trying to take the lock might poll
 the hardware for a long period of time without the ability to sleep
 while waiting for the lock. It almost sounds like you were looking for
 some hwmutex functionality.

 I agree, that it opens up a possiblity that user may sleep after holding
 a hw spinlock.  But really, why should it prevents us from using it as a
 hw mutex, if the need is legitimate?

If we want hw mutex functionality, let's discuss how to expose it.
Exposing it using the existing hw spinlock API might not be ideal, as
users might get confused.

Additionally, there are hardware IP locking blocks out there which
encourage users to sleep while waiting for a lock, by providing
interrupt functionality to wake them up when the lock is freed. So if
we choose to add a hw mutex API it might be used by others in the
future too (though this reason alone is not why we would choose to add
it now of course).

API discussions aside, what do you want to happen in your scenario
while the lock is taken? are you OK with other users spinning on the
lock waiting for it to be released? IIUC that might mean processors
spinning for a non-negligible period of time?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

[Ohad Ben-Cohen]

Hi Suman,

On Mon, May 11, 2015 at 6:01 PM, Suman Anna s-a...@ti.com wrote:
 We don't have any carveouts or usage of any external DDR, as this
 processor is used during Power Management, like cpuidle or suspend path,
 and is used to control the MPU and DDR states. The resource table is
 very simple and straight-forward [1].

Ok thanks.

Could you please document in the patch how the WkupM3 memory is
managed? Perhaps add to this latter explanation of yours also what
stands behind the umem/dmem names, justify usage of '__force' and
document the code around the l4_offset math (which I suspect may not
always be correct, as it seems the value of l4_offset depends on the
order of mem resources returned by platform_get_resource_byname).

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

Hi Lina,

On Fri, May 1, 2015 at 8:07 PM, Lina Iyer  wrote:
> Some uses of the hwspinlock could be that one entity acquires the lock
> and the other entity releases the lock. This allows for a serialized
> traversal path from the locking entity to the other.
>
> For example, the cpuidle entry from Linux to the firmware to power down
> the core, can be serialized across the context switch by locking the
> hwspinlock in Linux and releasing it in the firmware.
>
> Do not force the caller of __hwspin_trylock() to acquire a kernel
> spinlock before acquiring the hwspinlock.

Let's discuss whether we really want to expose this functionality
under the same hwspinlock API or not.

In this new mode, unlike previously, users will now be able to sleep
after taking the lock, and others trying to take the lock might poll
the hardware for a long period of time without the ability to sleep
while waiting for the lock. It almost sounds like you were looking for
some hwmutex functionality.

What do you think about this?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

[Ohad Ben-Cohen]

Hi Dave,

On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach  wrote:
> Add a remoteproc driver to load the firmware and boot a small
> Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
> Wakeup M3 remote processor is an integrated Cortex M3 that allows
> the SoC to enter the lowest possible power state by taking control
> from the MPU after it has gone into its own low power state and
> shutting off any additional peripherals.

>From a remoteproc point of view this looks generally ok.

The only non-standard remoteproc aspect here is the handling of the
internal memories. Can you please generally describe how are these
memories being used in the context of remoteproc? how does the
resource table of your firmware look like - do you also have carveouts
or other resources?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation

[Ohad Ben-Cohen]

Hi Dave,

On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach  wrote:
> From: Suman Anna 
>
> The rproc_da_to_va API is currently used to perform any device to
> kernel address translations to meet the different needs of the remoteproc
> core/drivers (eg: loading). The functionality is achieved within the
> remoteproc core, and is limited only for carveouts allocated within the
> core.
>
> A new rproc ops, da_to_va, is added to provide flexibility to platform
> implementations to perform the address translation themselves when the
> above conditions cannot be met by the implementations. The rproc_da_to_va()
> API is extended to invoke this ops if present, and fallback to regular
> processing if the platform implementation cannot provide the translation.
> This will allow any remoteproc implementations to translate addresses for
> dedicated memories like internal memories.

Can you please provide specific examples where this is needed and how
it is going to be used?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API

[Ohad Ben-Cohen]

Hi Dave,

On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach  wrote:
> Allow users of remoteproc the ability to get a handle to an rproc by
> passing a phandle supplied in the user's device tree node. This is
> useful in situations that require manual booting of the rproc.
>
> 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.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API

[Ohad Ben-Cohen]

Hi Dave,

On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach d-gerl...@ti.com wrote:
 Allow users of remoteproc the ability to get a handle to an rproc by
 passing a phandle supplied in the user's device tree node. This is
 useful in situations that require manual booting of the rproc.

 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.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation

[Ohad Ben-Cohen]

Hi Dave,

On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach d-gerl...@ti.com wrote:
 From: Suman Anna s-a...@ti.com

 The rproc_da_to_va API is currently used to perform any device to
 kernel address translations to meet the different needs of the remoteproc
 core/drivers (eg: loading). The functionality is achieved within the
 remoteproc core, and is limited only for carveouts allocated within the
 core.

 A new rproc ops, da_to_va, is added to provide flexibility to platform
 implementations to perform the address translation themselves when the
 above conditions cannot be met by the implementations. The rproc_da_to_va()
 API is extended to invoke this ops if present, and fallback to regular
 processing if the platform implementation cannot provide the translation.
 This will allow any remoteproc implementations to translate addresses for
 dedicated memories like internal memories.

Can you please provide specific examples where this is needed and how
it is going to be used?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

[Ohad Ben-Cohen]

Hi Dave,

On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach d-gerl...@ti.com wrote:
 Add a remoteproc driver to load the firmware and boot a small
 Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
 Wakeup M3 remote processor is an integrated Cortex M3 that allows
 the SoC to enter the lowest possible power state by taking control
 from the MPU after it has gone into its own low power state and
 shutting off any additional peripherals.

From a remoteproc point of view this looks generally ok.

The only non-standard remoteproc aspect here is the handling of the
internal memories. Can you please generally describe how are these
memories being used in the context of remoteproc? how does the
resource table of your firmware look like - do you also have carveouts
or other resources?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

Hi Lina,

On Fri, May 1, 2015 at 8:07 PM, Lina Iyer lina.i...@linaro.org wrote:
 Some uses of the hwspinlock could be that one entity acquires the lock
 and the other entity releases the lock. This allows for a serialized
 traversal path from the locking entity to the other.

 For example, the cpuidle entry from Linux to the firmware to power down
 the core, can be serialized across the context switch by locking the
 hwspinlock in Linux and releasing it in the firmware.

 Do not force the caller of __hwspin_trylock() to acquire a kernel
 spinlock before acquiring the hwspinlock.

Let's discuss whether we really want to expose this functionality
under the same hwspinlock API or not.

In this new mode, unlike previously, users will now be able to sleep
after taking the lock, and others trying to take the lock might poll
the hardware for a long period of time without the ability to sleep
while waiting for the lock. It almost sounds like you were looking for
some hwmutex functionality.

What do you think about this?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver

[Ohad Ben-Cohen]

Hi Suman,

On Wed, Apr 29, 2015 at 7:05 PM, Suman Anna  wrote:
> Ping, do you have any comments on this series?

I'll get to review this next week.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] remoteproc checkpatch fixes

[Ohad Ben-Cohen]

On Sat, Feb 28, 2015 at 1:18 AM, Suman Anna  wrote:
> Suman Anna (3):
>   remoteproc/ste: add blank lines after declarations
>   remoteproc/davinci: fix quoted split string checkpatch warning
>   remoteproc: fix various checkpatch warnings

Applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Tue, Mar 24, 2015 at 7:11 PM, Bjorn Andersson
 wrote:
> Add binding documentation for the Qualcomm Hardware Mutex.
>
> Reviewed-by: Andy Gross 
> Reviewed-by: Jeffrey Hugo 
> Signed-off-by: Bjorn Andersson 
> ---

Both patches have been applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 0/4] hwspinlock core & omap dt support

[Ohad Ben-Cohen]

On Thu, Apr 16, 2015 at 1:28 PM, Ohad Ben-Cohen  wrote:
> On Thu, Apr 16, 2015 at 12:31 PM, Mark Rutland  wrote:
> > Hi,
> >
> > Apologies for the delay on this.
> >
> >> > Gentle reminder. Can you please provide your ack on the bindings in this
> >> > series (Patches 1 & 3) for Ohad to queue up the series for 4.1.
> >> >
> >>
> >> Ping again, if you can provide your ack on these bindings and the qcom
> >> hwmutex bindings, then Ohad can pick up both the series for 4.1. Both
> >> series are blocked on getting the binding acks.
> >
> > Both the bindings look sane to me, so for patches 1 and 3:
> >
> > Acked-by: Mark Rutland 
>
> Great, thanks a lot Mark!

All 4 patches in this series have been applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 0/4] hwspinlock core omap dt support

[Ohad Ben-Cohen]

On Thu, Apr 16, 2015 at 1:28 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Thu, Apr 16, 2015 at 12:31 PM, Mark Rutland mark.rutl...@arm.com wrote:
  Hi,
 
  Apologies for the delay on this.
 
   Gentle reminder. Can you please provide your ack on the bindings in this
   series (Patches 1  3) for Ohad to queue up the series for 4.1.
  
 
  Ping again, if you can provide your ack on these bindings and the qcom
  hwmutex bindings, then Ohad can pick up both the series for 4.1. Both
  series are blocked on getting the binding acks.
 
  Both the bindings look sane to me, so for patches 1 and 3:
 
  Acked-by: Mark Rutland mark.rutl...@arm.com

 Great, thanks a lot Mark!

All 4 patches in this series have been applied, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Tue, Mar 24, 2015 at 7:11 PM, Bjorn Andersson
bjorn.anders...@sonymobile.com wrote:
 Add binding documentation for the Qualcomm Hardware Mutex.

 Reviewed-by: Andy Gross agr...@codeaurora.org
 Reviewed-by: Jeffrey Hugo jh...@codeaurora.org
 Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
 ---

Both patches have been applied, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver

[Ohad Ben-Cohen]

Hi Suman,

On Wed, Apr 29, 2015 at 7:05 PM, Suman Anna s-a...@ti.com wrote:
 Ping, do you have any comments on this series?

I'll get to review this next week.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] remoteproc checkpatch fixes

[Ohad Ben-Cohen]

On Sat, Feb 28, 2015 at 1:18 AM, Suman Anna s-a...@ti.com wrote:
 Suman Anna (3):
   remoteproc/ste: add blank lines after declarations
   remoteproc/davinci: fix quoted split string checkpatch warning
   remoteproc: fix various checkpatch warnings

Applied, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] remoteproc for 4.1

[Ohad Ben-Cohen]

The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-4.1-next

for you to fetch changes up to 315491e5d6ee66838a18a8ca0c14e6ffb376e48c:

  remoteproc: add IOMMU hardware capability flag (2015-03-12 10:43:26 +0200)


Suman Anna is adding remoteproc support for processors not behind IOMMUs.


Suman Anna (1):
  remoteproc: add IOMMU hardware capability flag

 drivers/remoteproc/da8xx_remoteproc.c |  1 +
 drivers/remoteproc/omap_remoteproc.c  |  2 ++
 drivers/remoteproc/remoteproc_core.c  | 15 ++-
 drivers/remoteproc/ste_modem_rproc.c  |  1 +
 include/linux/remoteproc.h|  2 ++
 5 files changed, 8 insertions(+), 13 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] remoteproc for 4.1

[Ohad Ben-Cohen]

The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-4.1-next

for you to fetch changes up to 315491e5d6ee66838a18a8ca0c14e6ffb376e48c:

  remoteproc: add IOMMU hardware capability flag (2015-03-12 10:43:26 +0200)


Suman Anna is adding remoteproc support for processors not behind IOMMUs.


Suman Anna (1):
  remoteproc: add IOMMU hardware capability flag

 drivers/remoteproc/da8xx_remoteproc.c |  1 +
 drivers/remoteproc/omap_remoteproc.c  |  2 ++
 drivers/remoteproc/remoteproc_core.c  | 15 ++-
 drivers/remoteproc/ste_modem_rproc.c  |  1 +
 include/linux/remoteproc.h|  2 ++
 5 files changed, 8 insertions(+), 13 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 0/4] hwspinlock core & omap dt support

[Ohad Ben-Cohen]

On Thu, Apr 16, 2015 at 12:31 PM, Mark Rutland  wrote:
> Hi,
>
> Apologies for the delay on this.
>
>> > Gentle reminder. Can you please provide your ack on the bindings in this
>> > series (Patches 1 & 3) for Ohad to queue up the series for 4.1.
>> >
>>
>> Ping again, if you can provide your ack on these bindings and the qcom
>> hwmutex bindings, then Ohad can pick up both the series for 4.1. Both
>> series are blocked on getting the binding acks.
>
> Both the bindings look sane to me, so for patches 1 and 3:
>
> Acked-by: Mark Rutland 

Great, thanks a lot Mark!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 0/4] hwspinlock core omap dt support

[Ohad Ben-Cohen]

On Thu, Apr 16, 2015 at 12:31 PM, Mark Rutland mark.rutl...@arm.com wrote:
 Hi,

 Apologies for the delay on this.

  Gentle reminder. Can you please provide your ack on the bindings in this
  series (Patches 1  3) for Ohad to queue up the series for 4.1.
 

 Ping again, if you can provide your ack on these bindings and the qcom
 hwmutex bindings, then Ohad can pick up both the series for 4.1. Both
 series are blocked on getting the binding acks.

 Both the bindings look sane to me, so for patches 1 and 3:

 Acked-by: Mark Rutland mark.rutl...@arm.com

Great, thanks a lot Mark!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Tue, Apr 14, 2015 at 10:18 PM, Kumar Gala  wrote:
>> On Feb 27, 2015, at 4:30 PM, Bjorn Andersson 
>>  wrote:
>>
>> Add binding documentation for the Qualcomm Hardware Mutex.
>>
>> Signed-off-by: Bjorn Andersson 
>> —
>>
>
> Acked-by: Kumar Gala 

Perfect, thanks a lot, Kumar.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Tue, Apr 14, 2015 at 10:18 PM, Kumar Gala ga...@codeaurora.org wrote:
 On Feb 27, 2015, at 4:30 PM, Bjorn Andersson 
 bjorn.anders...@sonymobile.com wrote:

 Add binding documentation for the Qualcomm Hardware Mutex.

 Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
 —


 Acked-by: Kumar Gala ga...@codeaurora.org

Perfect, thanks a lot, Kumar.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Mon, Apr 6, 2015 at 10:04 PM, Ohad Ben-Cohen  wrote:
> Mark, are you OK with the latest iteration from Suman? it would be
> nice to get your +1 just to make sure we don't merge stuff you're
> uncomfortable with.

Quick update:

As Tim pointed out, we can move forward with the driver binding patch
according to the process described under II.2 of [1]. Both Bjorn and
myself would still prefer to make sure Mark is satisfied with the
response Bjorn sent to Mark's question, but we understand if Mark is
swamped and we eventually would proceed according to the DT's
submitting-patches guidance below. Tim, thanks for pointing that out
as I wasn't aware of this.

What we probably do need a DT ack on is the hwspinlock subsystem
binding submitted by Suman, again according to the process described
under II.2 of [1]: "Subsystem bindings (anything affecting more than a
single device): then getting a devicetree maintainer to review it is
required".

Mark and Rob: thanks so much for all your help so far as you have
substantially helped shaping the hwspinlock binding. Please let us
know if you are satisfied with Suman's latest iteration, still prefer
to take another look at it, or are too swamped. If the latter, then
maybe we can ask Kumar to take a look, as this seems to be blocking
Qualcomm's upstream roadmap.

Thanks,
Ohad.

[1] Documentation/devicetree/bindings/submitting-patches.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Mon, Apr 6, 2015 at 10:04 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 Mark, are you OK with the latest iteration from Suman? it would be
 nice to get your +1 just to make sure we don't merge stuff you're
 uncomfortable with.

Quick update:

As Tim pointed out, we can move forward with the driver binding patch
according to the process described under II.2 of [1]. Both Bjorn and
myself would still prefer to make sure Mark is satisfied with the
response Bjorn sent to Mark's question, but we understand if Mark is
swamped and we eventually would proceed according to the DT's
submitting-patches guidance below. Tim, thanks for pointing that out
as I wasn't aware of this.

What we probably do need a DT ack on is the hwspinlock subsystem
binding submitted by Suman, again according to the process described
under II.2 of [1]: Subsystem bindings (anything affecting more than a
single device): then getting a devicetree maintainer to review it is
required.

Mark and Rob: thanks so much for all your help so far as you have
substantially helped shaping the hwspinlock binding. Please let us
know if you are satisfied with Suman's latest iteration, still prefer
to take another look at it, or are too swamped. If the latter, then
maybe we can ask Kumar to take a look, as this seems to be blocking
Qualcomm's upstream roadmap.

Thanks,
Ohad.

[1] Documentation/devicetree/bindings/submitting-patches.txt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Mon, Apr 6, 2015 at 7:48 PM, Bjorn Andersson  wrote:
> Based on the long discussion we had on one of the previous iterations
> of Suman's DT binding, with the DT maintainers I believe that it would
> be fine to move along and sent Suman's patches to Linus - without an
> explicit Ack from the DT guys (or did I just miss one?).

Thanks Bjorn.

Mark, are you OK with the latest iteration from Suman? it would be
nice to get your +1 just to make sure we don't merge stuff you're
uncomfortable with.

Thanks!
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Mon, Apr 6, 2015 at 7:22 PM, Tim Bird  wrote:
> On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen  wrote:
>> On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird  wrote:
>>> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen  wrote:
>>>> Sorry, I can't take this without a DT ack.
>>>
>>> Hmmm.
>>>
>>> The policy seems to be:
>>>  "For driver (not subsystem) bindings: If you are comfortable with the
>>>  binding, and it hasn't received an Acked-by from the devicetree
>>>  maintainers after a few weeks, go ahead and take it."
>>>
>>> The syscon property is only relative to the qcom hwspinlock driver,
>>> (unless I'm missing something) and both Qualcomm and Sony devs are
>>> OK with it.  So while an ACK from the DT side would be nice, I don't
>>> think it's required.  This is exactly the type of delay that is really
>>> holding up a lot of out-of-tree code.
>>
>> Sorry, I do prefer to make sure Mark is OK with this devicetree patch,
>> especially since it wasn't clear whether Mark is entirely comfortable
>> with it in his last response.
>
> Just to be clear - do you personally have any objections to the patch?

No, but this patch is for a folder I don't maintain so I prefer
someone who does to take a look.

Mark did take a look, and said he's confused by this patch (see this thread).

Do you want me to ignore him and just send it to Linus anyway?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Mon, Apr 6, 2015 at 7:48 PM, Bjorn Andersson bj...@kryo.se wrote:
 Based on the long discussion we had on one of the previous iterations
 of Suman's DT binding, with the DT maintainers I believe that it would
 be fine to move along and sent Suman's patches to Linus - without an
 explicit Ack from the DT guys (or did I just miss one?).

Thanks Bjorn.

Mark, are you OK with the latest iteration from Suman? it would be
nice to get your +1 just to make sure we don't merge stuff you're
uncomfortable with.

Thanks!
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Mon, Apr 6, 2015 at 7:22 PM, Tim Bird tbird...@gmail.com wrote:
 On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird tbird...@gmail.com wrote:
 On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 Sorry, I can't take this without a DT ack.

 Hmmm.

 The policy seems to be:
  For driver (not subsystem) bindings: If you are comfortable with the
  binding, and it hasn't received an Acked-by from the devicetree
  maintainers after a few weeks, go ahead and take it.

 The syscon property is only relative to the qcom hwspinlock driver,
 (unless I'm missing something) and both Qualcomm and Sony devs are
 OK with it.  So while an ACK from the DT side would be nice, I don't
 think it's required.  This is exactly the type of delay that is really
 holding up a lot of out-of-tree code.

 Sorry, I do prefer to make sure Mark is OK with this devicetree patch,
 especially since it wasn't clear whether Mark is entirely comfortable
 with it in his last response.

 Just to be clear - do you personally have any objections to the patch?

No, but this patch is for a folder I don't maintain so I prefer
someone who does to take a look.

Mark did take a look, and said he's confused by this patch (see this thread).

Do you want me to ignore him and just send it to Linus anyway?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird  wrote:
> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen  wrote:
>> Sorry, I can't take this without a DT ack.
>
> Hmmm.
>
> The policy seems to be:
>  "For driver (not subsystem) bindings: If you are comfortable with the
>  binding, and it hasn't received an Acked-by from the devicetree
>  maintainers after a few weeks, go ahead and take it."
>
> The syscon property is only relative to the qcom hwspinlock driver,
> (unless I'm missing something) and both Qualcomm and Sony devs are
> OK with it.  So while an ACK from the DT side would be nice, I don't
> think it's required.  This is exactly the type of delay that is really
> holding up a lot of out-of-tree code.

Sorry, I do prefer to make sure Mark is OK with this devicetree patch,
especially since it wasn't clear whether Mark is entirely comfortable
with it in his last response.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird tbird...@gmail.com wrote:
 On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 Sorry, I can't take this without a DT ack.

 Hmmm.

 The policy seems to be:
  For driver (not subsystem) bindings: If you are comfortable with the
  binding, and it hasn't received an Acked-by from the devicetree
  maintainers after a few weeks, go ahead and take it.

 The syscon property is only relative to the qcom hwspinlock driver,
 (unless I'm missing something) and both Qualcomm and Sony devs are
 OK with it.  So while an ACK from the DT side would be nice, I don't
 think it's required.  This is exactly the type of delay that is really
 holding up a lot of out-of-tree code.

Sorry, I do prefer to make sure Mark is OK with this devicetree patch,
especially since it wasn't clear whether Mark is entirely comfortable
with it in his last response.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Thu, Apr 2, 2015 at 12:32 AM, Tim Bird  wrote:
> I didn't see an Ack from Mark or Rob.  But I did see a question from
> Mark and response from Bjorn.
>
> Ohad - did you take this or are you still waiting for something?
>
> Who should I pester about this? :-)

Sorry, I can't take this without a DT ack.

Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

On Thu, Apr 2, 2015 at 12:32 AM, Tim Bird tbird...@gmail.com wrote:
 I didn't see an Ack from Mark or Rob.  But I did see a question from
 Mark and response from Bjorn.

 Ohad - did you take this or are you still waiting for something?

 Who should I pester about this? :-)

Sorry, I can't take this without a DT ack.

Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Ohad Ben-Cohen]

Hi Mark, Rob,

On Sat, Feb 28, 2015 at 12:30 AM, Bjorn Andersson
 wrote:
> Add binding documentation for the Qualcomm Hardware Mutex.
>
> Signed-off-by: Bjorn Andersson 
> ---
>
> I think the conclusion on the dt binding discussion for hwspinlocks was that
> we're down to having the #hwlock-cells intact. So this version includes that,
> but non of the other previously discussed properties.
>
> Changes since v5:
> - Extracted the dt binding documentation into a separate patch
> - Moved the driver to consume a syscon
> - Dropped previously suggested generic hwlock dt bindings
>
>  .../devicetree/bindings/hwlock/qcom-hwspinlock.txt | 39 
> ++
>  1 file changed, 39 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt

Could you please ack this one patch from Bjorn?

I'll need your Ack before I can this forward.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 0/4] hwspinlock core & omap dt support

[Ohad Ben-Cohen]

Hi Suman,

On Thu, Mar 5, 2015 at 4:01 AM, Suman Anna  wrote:
> This is the latest version of the hwspinlock dt support series,
> rebased onto v4.0-rc1 and addressing the long discussion on the
> bindings in v7 [1]. I really hope that this series can make it
> into 4.1.

>From a quick glance this looks great, thanks!

> Mark,
> Can you please provide your Acked-by for the binding documents
> so that Ohad can pick up the patches for the next merge window?

That would be perfect. Once we'll have it I could move forward with
this towards 4.1.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/