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: <fa686aa40805190857u317d3304ie75d11870e109fc5@mail.gmail.com>
Date:	Mon, 19 May 2008 09:57:21 -0600
From:	"Grant Likely" <grant.likely@...retlab.ca>
To:	"Guennadi Liakhovetski" <g.liakhovetski@....de>
Cc:	linuxppc-dev@...abs.org, spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, dbrownell@...rs.sourceforge.net,
	fabrizio.garetto@...il.com, jonsmirl@...il.com
Subject: Re: [PATCH 3/4] spi: Add OF binding support for SPI busses

On Mon, May 19, 2008 at 7:17 AM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:
> On Fri, 16 May 2008, Grant Likely wrote:
>
>> +    However, the binding does not attempt to define the specific method for
>> +    assigning chip select numbers.  Since SPI chip select configuration is
>> +    flexible and non-standardized, it is left out of this binding with the
>> +    assumption that board specific platform code will be used to manage
>> +    chip selects.  Individual drivers can define additional properties to
>> +    support describing the chip select layout.
>
> Yes, this looks like a problem to me. This means, SPI devices will need
> two bindings - OF and platform?... Maybe define an spi_chipselect
> OF-binding?

Actually, spi devices have *neither*.  :-)  They bind to the SPI bus.
Not the platform bus or of_platform bus.  But that is Linux internal
details; this discussion is about device tree bindings.

Note that I did say that drivers can define additional properties for
supporting chip select changes as needed.  I'm just not attempting to
encode them into the formal binding.  There is simply just too many
different ways to manipulate chip select signals and so I don't feel
confident trying to define a *common* binding at this moment in time.
At some point in the future when we have a number of examples to
choose from then we can extend this binding with chip select related
properties.

As for the Linux internals, the 5200 SPI bus driver that I posted
exports a function that allows another driver to call in and
manipulated the CS lines before the transfer.  It isn't the prettiest
solution, but I'm not locked into the approach and that gives some
time to consider cleaner interfaces.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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