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]
Message-Id: <20070929203942.4302D20F0A2@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ