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
next prev parent reply other threads:[~2004-10-04 21:12 UTC|newest]
Thread overview: 16+ 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]
-- strict thread matches above, loose matches on Subject: below --
2007-04-28 21:47 PATCH: Mark Lord
2004-11-21 23:58 Patch, Andreas Fenkart
2004-11-22 6:37 ` Patch, Jaroslav Kysela
2000-07-12 16:24 PATCH: Juan J. Quintela
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.