Hi Mark, On Fri, Apr 4, 2014 at 3:04 AM, Mark Brown <broonie@xxxxxxxxxx> 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. Regards, Harini -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
