linux-kernel - Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI

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: <CAFcVEC+vWwepHgsCAP63YG2F_0ZXKMck1YYwi7XU3JQdpC9ZQw@mail.gmail.com>
Date:	Sat, 5 Apr 2014 11:35:03 +0530
From:	Harini Katakam <harinikatakamlinux@...il.com>
To:	Peter Crosthwaite <peter.crosthwaite@...inx.com>
Cc:	Mark Brown <broonie@...nel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>, linux-spi@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation
 for Cadence SPI

Hi Peter,

On Sat, Apr 5, 2014 at 4:44 AM, Peter Crosthwaite
<peter.crosthwaite@...inx.com> wrote:
> On Sat, Apr 5, 2014 at 12:30 AM, Harini Katakam
> <harinikatakamlinux@...il.com> wrote:
>> Hi,
>>
>> On Fri, Apr 4, 2014 at 7:38 PM, Harini Katakam
>> <harinikatakamlinux@...il.com> wrote:
>>> Hi Mark,
>>>
>>> On Fri, Apr 4, 2014 at 6:16 PM, Mark Brown <broonie@...nel.org> wrote:
>>>> On Fri, Apr 04, 2014 at 05:44:23PM +0530, Harini Katakam wrote:
>>>>> On Fri, Apr 4, 2014 at 3:39 PM, Mark Brown <broonie@...nel.org> wrote:
>>>>> > On Fri, Apr 04, 2014 at 08:30:38AM +0530, Harini Katakam wrote:
>>>>
>>>>> >> This IP can drive 4 slaves.
>>>>> >> The sCS line to be driven is selected in spi device structure and
>>>>> >> that is driven by the software.
>>>>
>>>>> > So why specify this in the binding at all?  If the device always has the
>>>>> > same number of chip selects it's redundant.
>>>>
>>>>> I'm sorry, I should have explained that better.
>>>>> The IP can support upto 4 chip selects.
>>>>> The num-cs value here is the number of chip selects actually used on the board.
>
> Shouldnt it be a property of the controller not the board? How for
> example do we differentiate between different implementations of
> cadence SPI controller that only supports up to two CS lines? My
> thinking is that this property should always be present and = 4 in the
> Zynq case as the controller always has 4 physical CS lines coming out
> (before any decoders, pin muxes or slaves etc.).
>
>>>>
>>>> Why does that need to be configured?  Surely the presence of slaves is
>>>> enough information.
>
> And presence of slaves / board info is inferable from subnodes.
>
>>>
>>> OK. I understand.
>>> Can you comment on the case where a decoder is used?
>>>
>>> There is support for adding a decoder where extended slaves can be selected
>>> through the IP's control register.
>>> (This is not currently implemented in the driver but will be in the future.)
>>>
>
> I think thats seperate information. is-decoded-cs property of something.
>
>>> How should the driver know whether it is 4 or 16 select lines for example?
>>> This has to be written to master->num_chipselect.
>>>
>
> If you only have one property (== 4) how do you tell the difference
> between 4 un-decoded CS lines vs 2 decoded CS lines?
>

If an SoC implements 2 CS and sets "decoder" property,
then we'd configure the register with "select decode" bit and write
0b0011 to the slave select field to select 4th slave.

If decoder property is not set, then we'd write 0b1000 to select 4th slave.

But yes, if the SoC only implements 2 CS, doesn't use decoder but
if there is an erroneous input to set_cs for 4th slave, it would be a problem.

>
> I think num-cs has validity as the number of CS lines implemented in
> the controller. For any given SoC, it's constant but could differ
> between SoCs.
>

I dint consider that this property will be useful to SoC's implementing <4 CS;
master->num_chipselect (when set to this property's value)
will be used to check error conditions.

Regards,
Harini
--
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/