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]
Message-ID: <5554E957.3030809@gmail.com>
Date:	Thu, 14 May 2015 11:28:39 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Scott Branden <sbranden@...adcom.com>,
	Mark Brown <broonie@...nel.org>
CC:	Jonathan Richardson <jonathar@...adcom.com>,
	Dmitry Torokhov <dtor@...gle.com>,
	Anatol Pomazau <anatol@...gle.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
	devicetree@...r.kernel.org, cernekee@...il.com,
	computersforpeace@...il.com
Subject: Re: [PATCH 2/2] spi: bcm-mspi: Add support for Broadcom MSPI driver.

On 14/05/15 11:19, Scott Branden wrote:
> Hi Mark,
> 
> On 15-05-14 03:31 AM, Mark Brown wrote:
>> On Wed, May 13, 2015 at 05:19:06PM -0700, Scott Branden wrote:
>>
>>> The purpose of this mspi interface is to connect to NOR flash.  There
>>> are
>>> other SPI interfaces on the devices used to connect to other SPI
>>> devies.  We
>>> don't have any need to support full duplex slaves on this port (NOR
>>> have any
>>> hardware wired this way - pun realized after typing this).
>>
>> Chip vendors often say this sort of thing and then get surprised by what
>> their users choose to do, and even if it only ever gets used with flash
>> all it would take is some new flash command which can use full duplex
>> for something.  Please write the code so it at least tries to handle
>> full duplex operation, if you can't test it fully that's not the end of
>> the world.  It doesn't look like it should be particularly difficult.
>>
> Yes, there is always room for improvements in code.  In this case - it
> really is not worth our time to add code we can't test.  We try to
> deliver code that we can test and actually works.  Yes, if anyone needs
> to use the mspi for full duplex operation code can be added in the
> future - it is software.  This block has gone through many generations
> of our SoCs and has only been used for this purpose - the bootROM boots
> from this SPI only.  It is dedicated for this purpose.
> 
> Also, there are other SPI blocks on the SoC that are used for connect
> other SPI devices.  These SPI blocks are properly designed for
> full-duplex operation.  This mspi block is designed for connecting to
> NOR flash.

This is an implementation detail and architectural choice that is
specific to the Cygnus SoCs where a single MSPI is present, right?

This same MSPI block is instantiated multiple times in BCM7xxx chips to
interface to general purpose SPI slaves, ranging from Ethernet switches
to bluetooth chips etc... those will definitively want full-duplex to be
working.

I would greatly appreciate if some thought to supporting full duplex
transfers was given in this driver drop. If you cannot test that, then
maybe just flag the driver has been half-duplex only for now...

Thank you.
-- 
Florian
--
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