linux-kernel - Re: [PATCH 00/14] Blackfin on-chip SPI controller driver updates and bug-fixing

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 30 Oct 2007 13:42:18 -0700
From:	David Brownell <david-b@...bell.net>
To:	"Mike Frysinger" <vapier.adi@...il.com>
Cc:	"Bryan Wu" <bryan.wu@...log.com>,
	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/14] Blackfin on-chip SPI controller driver updates and bug-fixing

On Tuesday 30 October 2007, Mike Frysinger wrote:
> On 10/30/07, David Brownell <david-b@...bell.net> wrote:
> > And also, pay closer attention to when you may be making
> > changes that make device drivers work differently over
> > your spi_master controller driver than anyone elses ...
> > such platform-specific behaviors are undesirable, and when
> > they go against specified behavior they are also bugs.
> 
> was there something that caught your eye other than the ugly udelay()
> you mentioned in the other thread ?

That one was a feature that might be more generally necessary,
just to meet chip timing specs.  Mostly they're no trouble.
But sometimes there are constraints around chipselect, or at
particular points in a protocol exchange ... as you know, SPI
has no in-band synchronization, so timing delays are about as
good as any standardized infrastructure can get.  So if that
particular timing tweak was essential to make that driver work,
it might be something the API should address -- instead of just
a particular controller.

The other point was the handling of the two spi_transfer protocol
tweaking options.  The comment went against the interface spec.
Now, maybe that was an issue of weak English skills ... but from
my scanning the patch, I got the impression one intent of that
patch really was to do what the comment said.  (Of course it did
a lot of other stuff, which looked less dubious and might have
had a lot more to do with why the patch made that m25p16 chip
behave on that new board.)

- Dave
-
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/