Not sure who takes this, but please pull these 2 changes for pstore for
3.11. These are necessary to get pstore to work with on-chip RAM on
Calxeda highbank platform.
I dropped the write-combine change from this series. While write-combine
is technically the correct mapping needed for ARM, it doesn't solve any
problem for me.
Rob
The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:
Linux 3.10-rc2 (2013-05-20 14:37:38 -0700)
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git tags/pstore-for-3.11
for you to fetch changes up to da98a8882b3b388e9580821c8ad281c85f94d025:
pstore/ram: avoid atomic accesses for ioremapped regions (2013-05-21
15:32:44 -0500)
----------------------------------------------------------------
2 changes for pstore ram:
- Don't use atomic ops on ioremapped RAM which is not supported on ARM
- Allow non-power of 2 sized RAM buffers
----------------------------------------------------------------
Rob Herring (2):
pstore/ram: remove the power of buffer size limitation
pstore/ram: avoid atomic accesses for ioremapped regions
fs/pstore/ram.c | 2 --
fs/pstore/ram_core.c | 54
++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 52 insertions(+), 4 deletions(-)
On Wed, Jun 12, 2013 at 8:44 PM, Rob Herring <[email protected]> wrote:
> Not sure who takes this, but please pull these 2 changes for pstore for
> 3.11. These are necessary to get pstore to work with on-chip RAM on
> Calxeda highbank platform.
Were these posted for discussion and review? Is there anyone who should
be providing {Acked,Reviewed,Tested}-by: tags for them? I haven't ever had
a sub-maintained tree to pull from - so I'm being double-extra cautious before
doing something with this as it all feels new and strange.
-Tony
On 06/14/2013 05:18 PM, Tony Luck wrote:
> On Wed, Jun 12, 2013 at 8:44 PM, Rob Herring <[email protected]> wrote:
>> Not sure who takes this, but please pull these 2 changes for pstore for
>> 3.11. These are necessary to get pstore to work with on-chip RAM on
>> Calxeda highbank platform.
>
> Were these posted for discussion and review? Is there anyone who should
> be providing {Acked,Reviewed,Tested}-by: tags for them? I haven't ever had
> a sub-maintained tree to pull from - so I'm being double-extra cautious before
> doing something with this as it all feels new and strange.
Yes, here:
https://lkml.org/lkml/2013/4/9/831
The main discussion was around the write-combining change which I
dropped. You can pick patches 2 and 3 off the mail list if you prefer. I
would assume they only require an ack from one of the 4 of you which
pulling the tree implicitly does.
Rob
On Fri, Jun 14, 2013 at 05:32:16PM -0500, Rob Herring wrote:
> https://lkml.org/lkml/2013/4/9/831
>
> The main discussion was around the write-combining change which I
> dropped. You can pick patches 2 and 3 off the mail list if you prefer. I
> would assume they only require an ack from one of the 4 of you which
> pulling the tree implicitly does.
I've just re-reviewed the discussion. I see Colin was talking about ftrace
causing infinite loops due to recursion. Once I stumbled onto this too
(but the issue itself was due to missing 'notrace' mark), and Stephen told
that recursion protection is kind of mandatory:
http://lists.linaro.org/pipermail/linaro-kernel/2012-August/002084.html
I belive that the protection is actually there nowadays, and that is why
Rob does not see the problem with his patch.
So, I guess the patches are good, at least they fix real issues for Rob.
:)
Acked-by: Anton Vorontsov <[email protected]>
(Or I can pick this via linux-pstore.git tree, I'll let Tony decide.)
Thanks!
Anton
On Fri, Jun 14, 2013 at 3:47 PM, Anton Vorontsov <[email protected]> wrote:
>
> Acked-by: Anton Vorontsov <[email protected]>
>
> (Or I can pick this via linux-pstore.git tree, I'll let Tony decide.)
Added that Acked-by: and applied to my tree.
Thanks
-Tony