linux-kernel - Re: [PATCH 09/14] Blackfin SPI driver: Fix SPI driver to work with SPI flash ST25P16 on bf548

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:	Wed, 31 Oct 2007 14:50:31 +0800
From:	Bryan Wu <bryan.wu@...log.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Bryan Wu <bryan.wu@...log.com>,
	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, Sonic Zhang <sonic.zhang@...log.com>
Subject: Re: [PATCH 09/14] Blackfin SPI driver: Fix SPI driver to work with
	SPI flash ST25P16 on bf548


On Tue, 2007-10-30 at 13:05 -0700, David Brownell wrote:
> On Tuesday 30 October 2007, Bryan Wu wrote:
> > Current SPI driver enables SPI controller and set the SPI baud register
> > for each SPI transfer. But, they should never be changed within a SPI
> > message session, in which seveal SPI transfers are pumped.
> 
> That's actually not true.  If a driver sets spi_transfer.max_speed_hz
> to a nonzero value that's different from the previous bit rate (which
> may be spi_device.max_speed_hz), it should be updated before that
> transfer segment.  Example, sometimes data can't be clocked out at
> the same rate commands can be clocked in.
> 
> Similarly with spi_transfer.bits_per_word ... again, it's very possible
> that commands and data have different sizes.
> 
I agree with you here. 

Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz
with the spi_device.max_speed_hz.

spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is
for the default max speed value.
spi_transfer.speed_hz comes from upper applications for each spi
transfer setting.

Am I right?

I will fix this later.

> Of course, if those values don't change, there'd be no point in
> reconfiguring any aspect of those communications parameters...
> 
> 
> I'll be forwarding this patch, since this looks like another case
> where the main effect of the patch doesn't match its description
> and since this patch series has taken too long already.  (Does this
> patch even really relate primarily to working with an ST M25P16
> flash part??)  Though it'd be reasonable to be more hard-nosed
> about this and insist on another go-around for thesse patches.
> (Making this the fifth one??)
> 
> But I *STRONGLY* suggest someone revisit the issue of whether those
> two per-transfer options are now being handled correctly.  As well
> as update procedures so that the patch comments start to have a
> direct correspondence to what the patches have changed...
> 

OK, we will test this on our hardware.
Thanks, Dave
-Bryan Wu
-
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/