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  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:	Fri, 4 Apr 2014 08:30:38 +0530
From:	Harini Katakam <>
To:	Mark Brown <>
Cc:	Grant Likely <>,
	Rob Herring <>,
	Pawel Moll <>,
	Mark Rutland <>,
	"" <>,
	Kumar Gala <>,,
	"" <>,
	"" <>,
	"" <>
Subject: Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation
 for Cadence SPI

Hi Mark,

On Fri, Apr 4, 2014 at 3:04 AM, Mark Brown <> wrote:
> On Thu, Apr 03, 2014 at 04:40:31PM +0530, Harini Katakam wrote:
>> +Optional properties:
>> +- num-cs             : Number of chip selects used.
> How does this translate to the hardware?

This IP can drive 4 slaves.
The CS line to be driven is selected in spi device structure and
that is driven by the software.

>> +             num-cs = /bits/ 16 <4>;
> What's going on with the /bits/ - is this something that's required for
> the property?

The master->num-chipselect property is 16 bit but writing <4> here directly
leads to 0 being read in of_property_read (because it's big endian).
Instead using of property read u32 and then copying, we decided to do this.
This was discussed on v2 between Michal and Rob:
>>>> +               num-chip-select = /bits/ 16 <4>;
>> I was expecting you will comment this a little bit. :-)
>> Because all just reading this num-cs as 32bit and then
>> assigning this value to master->num_chipselect which is 16bit.
> Well, everyone else has that problem then. Obviously it takes a bit
> more care than just reading into a u32, but that is a kernel problem
> and not a problem of the binding.
They are not reading it directly with read_u32 but they are using
intermediate u32 value which is assigned to u16 which is fine.
This pattern is in most drivers(maybe all).
The point is if binding should or can't simplify driver code.
And from your reaction above I expect that it is up to driver
owner and binding doc how you want to do it.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists