linux-kernel - Re: [spi-devel-general] IT8716F SPI driver submission?

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] [day] [month] [year] [list]

Date:	Sat, 29 Sep 2007 13:39:43 -0700
From:	David Brownell <david-b@...bell.net>
To:	spi-devel-general@...ts.sourceforge.net,
	c-d.hailfinger.devel.2006@....net
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [spi-devel-general] IT8716F SPI driver submission?

> The IT8716F accepts commands byte-wise and does all of the lifting on
> the SPI bus as well. There are limitations, though:
> - It can send 1,2,4,5 bytes (including command byte) to the slave and
> read 0,1,2,3 bytes back. Other values are not possible.
> - Bus clock rate is either 33 MHz or 16.5 MHz.
>
> Is there any driver I can start from as reference?

None that I know of.  You might find it's easier to just work with
a bastardized version of the (latest, with the 2.6.24 MTD updates
so it handleds even more chips) m25p80 driver and not go through the
SPI framework.  It doesn't look like you could even bitbang SPI there,
since not all those pins are usable for bit-level I/O.

As you note, that hardware doesn't support all that a SPI controller
does.  It's provided for accessing a single serial flash chip; and
not even to do that very smoothly.  You'd have to somehow prevent that
driver from reading or writing normal size blocks.  And you'd need to
defend against drivers trying to do full duplex or multi-segment I/O
requests, etc.  Lots more work than a bastardized m25p80 driver.  ;)

My limited exposure to SPI on PC hardware -- LPC chips like this, and
newer southbridges -- suggests they tend to be just as, erm, "limited"
as this one in terms of supporting anything other than one particular
variety of serial flash interface.  I think the idea was just to let
board makers use cheaper flash chips when loading the BIOS.  For that,
they don't need the kind of flexible expansion bus SPI is on most SOC
chips; or much throughput.

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