From: David Woodhouse <dwmw2@infradead.org>
To: joakim.tjernlund@lumentis.se
Cc: linux-mtd@lists.infradead.org
Subject: Re: seeking help on JFFS2
Date: Thu, 07 Nov 2002 08:49:02 +0000 [thread overview]
Message-ID: <7618.1036658942@passion.cambridge.redhat.com> (raw)
In-Reply-To: <IGEFJKJNHJDCBKALBJLLOELLFHAA.joakim.tjernlund@lumentis.se>
joakim.tjernlund@lumentis.se said:
> Why does JEDEC end up in cfi_cmdset_0001.c?
CFI only defines how you _probe_ chips. The actual Intel command set is the
same as it's always been, likewise the AMD one. This is why jedec_probe
passes control to the CFI drivers and all the other chip drivers are
deprecated.
> If it should end up in cfi_cmdset_0001.c, why does it not set cmdset_priv?
IIRC because cmdset_priv is just a copy of the extended CFI table from the
chip, which we don't have in the case of a non-CFI chip. It's that which
holds the details of whether we can do erase suspend, etc.
Perhaps the table in jedec_probe should also contain a 'fake' extended CFI
table. More sensibly, perhaps we should have a structure in the cmdset_priv
with just the flags we care about, and at probe time either parse the
extended CFI table or copy those flags from the jedec_probe table.
For now, we just assume jedec-probed chips have none of the extended
features.
--
dwmw2
next prev parent reply other threads:[~2002-11-07 8:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-06 16:09 seeking help on JFFS2 Junping Zhang
2002-11-06 16:14 ` David Woodhouse
2002-11-07 8:28 ` Joakim Tjernlund
2002-11-07 8:49 ` David Woodhouse [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-11-06 18:26 Junping Zhang
2002-11-06 13:13 Junping Zhang
2002-11-05 19:56 Junping Zhang
2002-11-05 21:08 ` Jörn Engel
2002-11-05 17:39 Junping Zhang
2002-11-05 19:31 ` Jörn Engel
2002-11-05 17:17 Jeffrey Lim
2002-11-05 19:32 ` Jörn Engel
2002-11-05 13:40 Junping Zhang
2002-11-05 16:41 ` Jörn Engel
2002-11-06 3:57 ` Darren Freeman
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=7618.1036658942@passion.cambridge.redhat.com \
--to=dwmw2@infradead.org \
--cc=joakim.tjernlund@lumentis.se \
--cc=linux-mtd@lists.infradead.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 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.