linux-kernel - Re: drivers/mtd/devices/at91

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200706250835.04848.hjk@linutronix.de>
Date:	Mon, 25 Jun 2007 08:35:04 +0200
From:	Hans-Jürgen Koch <hjk@...utronix.de>
To:	David Brownell <david-b@...bell.net>
Cc:	dwmw2@...radead.org, Andrew Victor <andrew@...people.com>,
	tglx@...utronix.de,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: drivers/mtd/devices/at91_dataflash26.c

Am Montag 25 Juni 2007 04:51 schrieb David Brownell:
> On Thursday 10 May 2007, Hans-Jürgen Koch wrote:
> > Am Donnerstag 10 Mai 2007 22:07 schrieb David Brownell:
> > > On Friday 27 April 2007, David Brownell wrote:
> > > > On Friday 27 April 2007, Hans-Jürgen Koch wrote:
> > > > 
> > > > > > 	 the m25p80 driver
> > > > > > was pretty close to working with those Atmel devices too ...
> > > > > > most of the commands are identical.
> > > > > 
> > > > > Thanks for that hint, I'll have a look at the data sheet.
> > > 
> > > Any progress on that?  I looked again, and yes most commands
> > > are identical.
> 
> Still true.  :)

I came to the same conclusion.

> 
> For that and a boatload of other SPI flash chips.  I'm
> wondering just what that JEDEC standard covers; either
> it's got useful command coverage, or vendors of SPI flash
> noticed that converging command sets is a Good Thing.
> 
> 
> > >  - That driver relies on an AT91-only SPI stack that's not
> > >    going upstream, instead of drivers/spi/atmel_spi.c;
> > > 
> > >  - Driver can't even be selected on kernel.org kernel (!!);
> > > 
> > >  - The m25p80 driver will need at most minor tweaks to
> > >    handle those AT26 (and AT25) series chips;
> > > 
> > > So 340ea370c2ce89d1c15fbf785460f2f74314ce58 should be reverted.
> 
> Also still true...

I agree.

> 
> 
> > > 
> > > - Dave
> > >
> > 
> > Dave,
> > sorry for not responding earlier, I was busy with lots of other 
> > stuff. At the moment, I'm working on this again. I had a bit
> > of trouble getting a recent kernel working on my test system,
> > but that seems to be OK now.
> > 
> > You'll hear from me soon.
> 
> Ping?  Have a look at
> 
>     http://lists.infradead.org/pipermail/linux-mtd/2007-June/018706.html

Great! Didn't notice that one.

> 
> which depends on the resent mutex conversion patch in the
> "previous message" link of that patch.
> 
> That should highlight more reasons why at91_dataflash should
> be reverted ASAP.  I'd expect you would be able to just drop
> that in and have it work ... 

Looks like that.

> unless you're seeing that nCS0 
> issue built out of at91rm9200 errata, in which case there's
> an experiment I can forward to you.  :)

I'll look at that ASAP. I had tons of other work on my desk and last time
I tried, SPI was broken on my device. It would be OK for me if you threw out
that at91_dataflash/at91_dataflash26 stuff now.

Thanks,
Hans

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/