From: Thomas Gleixner <tglx@linutronix.de>
To: Nicolas Pouillon <nipo@ssji.net>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Patch !
Date: Mon, 04 Oct 2004 23:04:58 +0200 [thread overview]
Message-ID: <1096923898.21297.485.camel@thomas> (raw)
In-Reply-To: <20041004224700.422a9f2c.nipo@ssji.net>
On Mon, 2004-10-04 at 22:47, Nicolas Pouillon wrote:
> > The configuration register reflects the state of the IF_CFG pin.
>
> I assume this is an hardware configuration.
> Would it be possible to change 16bit access to 32bit in MTD chip while
> running?
RTFM !!!!
Configuration Register
Type: Read/Write (except bit 7, which is Read Only)
7 IF_CFG (Interface Configuration). Reflects the state of the IF_CFG
input pin.
That's a bit to read what the hardware is configured for. I doubt that
there is a possibility to reconfigure the PCB by software. :)
> I tried to reconfigure PXA bank mode to 32 bit mode: probing no more
> works, and mmio transfers dont crash any more...
That's really surprising that it works no more.
> So if I understood well, PXA just makes kernel crash if accessing a
> 16bit mapped zone with 32bits words (quite normal, in fact, but not
> straightforward for me as I'm learning at the same time ;)
This is either a configuration problem or a bug/feature of the MTD code.
Which driver / part of the MTD framework is the source of this problem ?
> As I saw different bug reports/issues on MLs with this kind of thing
> (PXA kernel crashing while probing mtd), shouldn't a #warning, or a
> printk just before probing annoucing the issue could be added ?
He ? An Oops or a BUG are warning enough, that something is going wrong.
If we put for everything what can go wrong a warning into the kernel
then the majority of the kernel source will be printk and string
constants instead of functional code.
tglx
prev parent reply other threads:[~2004-10-04 21:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-01 13:46 Issues with a Doc Milplus Nicolas Pouillon
2004-10-01 13:57 ` David Woodhouse
2004-10-01 14:27 ` Nicolas Pouillon
2004-10-02 13:55 ` Patch ! Nicolas Pouillon
2004-10-02 20:42 ` Thomas Gleixner
2004-10-03 1:11 ` Nicolas Pouillon
[not found] ` <20041003030653.2e0452a7.nipo@ssji.net>
[not found] ` <1096768161.21297.129.camel@thomas>
2004-10-03 20:18 ` Nicolas Pouillon
2004-10-04 8:05 ` Thomas Gleixner
2004-10-04 16:38 ` Nicolas Pouillon
2004-10-04 17:59 ` Thomas Gleixner
2004-10-04 20:47 ` Nicolas Pouillon
2004-10-04 21:04 ` Thomas Gleixner [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=1096923898.21297.485.camel@thomas \
--to=tglx@linutronix.de \
--cc=linux-mtd@lists.infradead.org \
--cc=nipo@ssji.net \
/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