linux-kernel - Re: [PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver

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: <529DB784.5010308@ti.com>
Date:	Tue, 3 Dec 2013 12:50:44 +0200
From:	"ivan.khoronzhuk" <ivan.khoronzhuk@...com>
To:	Santosh Shilimkar <santosh.shilimkar@...com>,
	Grygorii Strashko <grygorii.strashko@...com>
CC:	Kumar Gala <galak@...nel.crashing.org>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Rob Landley <rob@...dley.net>,
	Russell King <linux@....linux.org.uk>,
	Mark Rutland <mark.rutland@....com>,
	devicetree <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Herring <rob.herring@...xeda.com>,
	<linux-kernel@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver

On 11/29/2013 05:10 PM, Santosh Shilimkar wrote:
> On Friday 29 November 2013 10:00 AM, Grygorii Strashko wrote:
>> Hi Kumar Gala,
>>
>> On 11/22/2013 11:06 PM, Kumar Gala wrote:
>>>
>>> On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk <ivan.khoronzhuk@...com> wrote:
>>>
>>>> On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>> +				the chip select signal.
>>>>>> +				Minimum value is 1 (0 treated as 1).
>>>>>> +
>>>>>> +- ti,cs-wsetup:		write setup width, ns
>>>>>> +				Time between the beginning of a memory cycle
>>>>>> +				and the activation of write strobe.
>>>>>> +				Minimum value is 1 (0 treated as 1).
>>>>>> +
>>>>>> +- ti,cs-wstrobe:	write strobe width, ns
>>>>>> +				Time between the activation and deactivation of
>>>>>> +				the write strobe.
>>>>>> +				Minimum value is 1 (0 treated as 1).
>>>>>> +
>>>>>> +- ti,cs-whold:		write hold width, ns
>>>>>> +				Time between the deactivation of the write
>>>>>> +				strobe and the end of the cycle (which may be
>>>>>> +				either an address change or the deactivation of
>>>>>> +				the chip select signal.
>>>>>> +				Minimum value is 1 (0 treated as 1).
>>>>>> +
>>>>>> +If any of the above parameters are absent, current parameter value will be taken
>>>>>> +from the corresponding HW reg.
>>>>>> +
>>>>>> +The name for cs node must be in format csN, where N is the cs number.
>>>>>
>>>>> this is wired we should use reg instead to represent the cs as done for SPI
>>>>> or a an other property
>>>>>
>>>>> Best Regards,
>>>>> J.
>>>>>
>>>>
>>>> Ok, I will add new property cs-chipselect like following :
>>>>
>>>> ti,cs-chipselect:	number of chipselect. Indicates on the
>>>> 			aemif driver which chipselect is used
>>>> 			for accessing the memory.
>>>> 			For compatibles "ti,davinci-aemif" and
>>>> 			"ti,keystone-aemif" it can be in range [0-3].
>>>> 			For compatible "ti,omap-L138-aemif" range is [2-5].
>>>>
>>>> Is it OK?
>>>
>>> Why do you need this? As it was mentioned just use reg:
>>>
>>> So you’d have something like:
>>>
>>> memory-controller@...00A00 {
>>> 	…
>>> 	nand:cs2@2 {
>>> 		reg = <2 0 0>;
>>> 		ranges;
>>> 		...
>>>
>>> 	}:
>>> };
>>
>> I'd prefer to continue with "ti,cs-chipselect" (this is more human friendly definition, as for me),
>> but if you insist - it can be changed as:
>> memory-controller@...00A00 {
>> 	compatible = "ti,keystone-aemif";
>> ...
>>
>> 	cs2 {
>> 		compatible = "ti,aemif-cs";
>> 		reg = <2>;
>> ...
>> 	}
>>
>> 	cs0 {
>> 		compatible = "ti,aemif-cs";
>> 		reg = <0>;
>> ...
>> 	}
>>
>>>
>>> However, I’m confused by the example in which you have:
>>>
>>> +		nand@0,0x8000000 {
>>> +			compatible = "ti,davinci-nand";
>>> +			reg = <0 0x8000000 0x4000000
>>> +			       1 0x0000000 0x0000100>;
>>> +
>>> +			.. see davinci-nand.txt
>>> +		};
>>>
>>> What chipselects is this on 0 & 1?
>>
>> As I described in https://lkml.org/lkml/2013/11/26/282 we are not encoding CS number in reg
>>   - it's memory partition number.
>>
>> Also, I'd like to note that we *DO NOT introduce* NAND device bindings here.
>> The Davinci NAND bindings was introduced and accepted more then one year ago, and
>> we've just updated its a bit (keeping full compatibility) and reused
>> (see https://lkml.org/lkml/2013/11/21/182).
>> And the CS number is encoded for Davinci NAND node using standalone property
>> "ti,davinci-chipselect" and we need to provide (2) two memory ranges to it,
>> as result we can't encode CS number in "reg" for AEMIF child devices (NAND/NOR/etc),
>> as it will break bindings compatibility.
>>
>> In this document, NAND node is used just as an example of child node.
>>
> The above should have been really captured in the commit log to get a better
> picture. No way on earth, a reviewer can figure out whether this is new bindings
> or copy of bindings already used.
>
> Regards,
> Santosh
>

Ok, I will add it.

-- 
Regards,
Ivan Khoronzhuk
--
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/