public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: mtd@infradead.org
Cc: ahennessy@mvista.com, ds@schleef.org, jonas.holmberg@axis.com,
	cwryu@debian.org, eauth@softsys.co.at, nico@cam.org
Subject: Flash driver probe/commandset separation.
Date: Sun, 29 Apr 2001 19:38:17 +0100	[thread overview]
Message-ID: <26353.988569497@redhat.com> (raw)


We seem to have an unnecessary amount of duplication of flash chip driver 
code. We have three drivers for AMD/Fujitsu compatible chips - 
cfi_cmdset_0002.c, amd_flash.c and jedec.c. We have two drivers for Intel/
Sharp compatible chips - cfi_cmdset_0001.c and sharp.c.

Erwin noticed this and wrote code to fall back to an AMD-compatible probe
for JEDEC ID if the CFI probe failed, and then use cfi_cmdset_0002.c if 
appropriate. I think that was the right approach, but I don't like merging
the probes together like that. I think the mfr-specific probes for JEDEC ID 
should be kept separate. The map driver can always call them in order if 
the CFI probe fails, if it wants to.

What I'd like to do is provide core drivers for each of the different 
command sets, and separate probe functions which set up the necessary 
parameters and invoke the core drivers.

The current cfi_cmdset_000x drivers are the most generic, so I'd like to use
those as the basis of the core drivers, and ensure that they can fully
replace the functionality of the other individual drivers. 

We end up with:
	cmdset_intel (and sharp, etc.)
	cmdset_amd (and fujitsu, macronix, etc.)
	cfi_probe
	intel_jedec_probe
	amd_jedec_probe
	
Comments?

Even assuming people agree (or disagree unconvincingly :), I'm not sure
whether I should hold off on this until after I've sync'd up with Linus, or 
whether I should get this all done first and worry about feeding the new 
code to Linus later on. Probably the latter.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

             reply	other threads:[~2001-04-29 18:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-29 18:38 David Woodhouse [this message]
2001-04-30 15:17 ` AW: Flash driver probe/commandset separation Florian Schirmer / TayTron
2001-04-30 15:56   ` David Woodhouse
2001-04-30 15:56 ` Eric W. Biederman
2001-05-01 14:26   ` David Woodhouse
2001-04-30 17:56 ` Alice Hennessy
2001-05-02 15:33 ` Nicolas Pitre
2001-05-02 15:39   ` David Woodhouse
2001-05-03 17:32     ` Eric W. Biederman
2001-05-03 21:40       ` David Woodhouse
2001-05-03 21:45         ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2001-05-02 16:22 Kári Davíðsson

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=26353.988569497@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=ahennessy@mvista.com \
    --cc=cwryu@debian.org \
    --cc=ds@schleef.org \
    --cc=eauth@softsys.co.at \
    --cc=jonas.holmberg@axis.com \
    --cc=mtd@infradead.org \
    --cc=nico@cam.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