From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 1/2] sh: mach-ecovec24: modify memory area calculation
Date: Mon, 30 Nov 2009 02:16:26 +0000 [thread overview]
Message-ID: <20091130021626.GA7217@linux-sh.org> (raw)
In-Reply-To: <u8wdto9qh.wl%morimoto.kuninori@renesas.com>
On Thu, Nov 26, 2009 at 11:46:29AM +0000, Matt Fleming wrote:
> On Thu, Nov 26, 2009 at 08:08:17PM +0900, Kuninori Morimoto wrote:
> >
> > Dear Matt
> >
> > Thank you for checking patch !!
> >
>
> No problem.
>
> > > I think both of these patches should be using the variable
> > > "cached_to_uncached", rather than hard coding the value 0x20000000.
> >
> > I didn't know cached_to_uncached.
> > But I wonder can I use this variable here (romImage) ?
> > I think we can use macro here, but can not variable.
> >
>
> Ah, sorry, I forgot that this is a romImage thing. Yeah, including
> system_32.h causes lots of assembler errors to appear so I'm guessing it
> was never intended to be included by assembly code.
It was never intended to be used in assembly code, no, but assembly code
was not intended to make cached<->uncached transitions on its own either.
Applying the 0x20000000 shift here works fine for legacy mode, but will
obviously completely blow up on 32-bit mode when legacy mappings don't
exist.
As it stands now this cached<->uncached thing is completely bogus and
doesn't deserve to live, there is no way to make this transition safely
from a fixed macro given the differing boot options available. EcoVec
presumably also supports a 32-bit boot mode that will be broken by this.
Basically any new code referencing P1SEG or P2SEG definitions is broken
by design and is grounds for an immediate NAK. The sooner we can kill
those macros off in their entirety the better.
prev parent reply other threads:[~2009-11-30 2:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-26 10:34 [PATCH 1/2] sh: mach-ecovec24: modify memory area calculation Kuninori Morimoto
2009-11-26 10:51 ` Matt Fleming
2009-11-26 11:08 ` Kuninori Morimoto
2009-11-26 11:46 ` Matt Fleming
2009-11-30 2:16 ` Paul Mundt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091130021626.GA7217@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=linux-sh@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).