From: Artem Bityutskiy <dedekind1@gmail.com>
To: John Crispin <blogic@openwrt.org>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
Ralph Hempel <ralph.hempel@lantiq.com>,
linux-mtd@lists.infradead.org,
Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH V7] MIPS: lantiq: add NOR flash support
Date: Tue, 05 Apr 2011 15:36:35 +0300 [thread overview]
Message-ID: <1302006995.2760.120.camel@localhost> (raw)
In-Reply-To: <1302006830-10345-1-git-send-email-blogic@openwrt.org>
On Tue, 2011-04-05 at 14:33 +0200, John Crispin wrote:
> +#include <lantiq_soc.h>
> +#include <lantiq_platform.h>
> +
> +/*
> + * The NOR flash is connected to the same external bus unit (EBU) as PCI.
> + * To make PCI work we need to enable the endianess swapping for the address
> + * written to the EBU. This endianess swapping works for PCI correctly but
> + * fails for attached NOR devices. To workaround this we need to use a complex
> + * map. The workaround involves swapping all addresses whilste probing the chip.
> + * Once probing is complete we stop swapping the addresses but swizzle the
> + * unlock addresses to ensure that access to the NOR device works correctly.
> + */
> +
> +static int ltq_mtd_probing;
Disclamer: I do not really understand the PCI/swapping issue, even
though you wrote a comment about this, but still....
... I'm worried about this global variable. If you have multiple
instances of such NOR flash, then you theoretically may have a situation
when one of them is being probed, while another is being used for real.
And this single global switch will break the one which is used for real.
IOW, the right solution would be to have per-chip flag, not a global
flag.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2011-04-05 12:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-05 12:33 [PATCH V7] MIPS: lantiq: add NOR flash support John Crispin
2011-04-05 12:36 ` Artem Bityutskiy [this message]
2011-04-05 12:57 ` John Crispin
2011-04-05 12:58 ` Artem Bityutskiy
2011-04-05 13:06 ` John Crispin
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=1302006995.2760.120.camel@localhost \
--to=dedekind1@gmail.com \
--cc=blogic@openwrt.org \
--cc=daniel.schwierzeck@googlemail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-mtd@lists.infradead.org \
--cc=ralf@linux-mips.org \
--cc=ralph.hempel@lantiq.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox