On 03/31/2015 07:47 AM, Mark Brown wrote:

On Mon, Mar 30, 2015 at 08:46:10AM +0200, Michal Simek wrote:

quoted

On 03/27/2015 06:53 PM, Mark Brown wrote:

quoted

On Fri, Mar 27, 2015 at 11:55:49AM +0100, Michal Simek wrote:

quoted

quoted

Please fix your mail client to word wrap within paragraphs at less than
80 columns - this makes your mails easier to read and reply to.

quoted

You are the first one who had problem with this. But I have setup lower
limit and hopefully it is better now.

That looks better, yes...  I may just be the first one who's bothered
remarking on this.

yes and I definitely thank you for that.

quoted

quoted

quoted

On 03/08/2015 08:00 PM, Mark Brown wrote:

quoted

On Fri, Jan 16, 2015 at 01:55:14PM +0100, Michal Simek wrote:

quoted

quoted

Remember that we can at least in theory have additional chip selects
that aren't controlled by the IP block but are instead GPIOs.  

quoted

I agree with you but this can be generic case for every SPI driver. Also
using external decoder is possible for every driver. Maybe there are
others options via I2C too.

Remember that this in the context of me saying I don't think num-cs is
a particularly good idea at all...

yes.

quoted

quoted

There's
also some potential confusion for users between the number of chip
selects in use in a given system and the size of the bitfield that the
driver needs to take care of.

quoted

num-ss-bits is autogenerated directly from design tools for particular
hardware design and this size is exactly setup and hardcoded. (num-cs
can be just the same case)
If there are 5 bits there are 5 wires from IP. And value of num-ss-bits
and num-cs will be the same.

But what your patch did was *replace* num-ss-bits in the binding, not
just add it.

yes. Sync binding was the main my point.

quoted

If user wants to use less lines then physically available we could
potentially extend binding to say. num-ss-bit - number of chip selects
available in hardware. num-cs - number of chip selects used by the driver.
But I expect that this will be rejected because it is software setting
not hardware description.

num-cs *is* a software setting.

ok - what to do with that? Remove it because it shouldn't be passed via DT?

Thanks,
Michal