linux-kernel - Re: [PATCH v3 20/27] ARM: dts: dra7: Fix NAND device nodes.

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: <561E689E.70104@ti.com>
Date:	Wed, 14 Oct 2015 09:37:18 -0500
From:	"Franklin S Cooper Jr." <fcooper@...com>
To:	Roger Quadros <rogerq@...com>
CC:	<dwmw2@...radead.org>, <computersforpeace@...il.com>,
	<ezequiel@...guardiasur.com.ar>, <javier@...hile0.org>,
	<nsekhar@...com>, <linux-mtd@...ts.infradead.org>,
	<linux-omap@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <tony@...mide.com>
Subject: Re: [PATCH v3 20/27] ARM: dts: dra7: Fix NAND device nodes.



On 10/14/2015 09:17 AM, Roger Quadros wrote:
> On 14/10/15 16:34, Franklin S Cooper Jr. wrote:
>>
>> On 09/18/2015 09:53 AM, Roger Quadros wrote:
>>> Add compatible id, GPMC register resource and interrupt
>>> resource to NAND controller nodes.
>>>
>>> The GPMC driver now implements gpiochip and irqchip so
>>> enable gpio-controller and interrupt-controller properties.
>>>
>>> With this the interrupt parent of NAND node changes so fix it
>>> accordingly.
>>>
>>> Signed-off-by: Roger Quadros <rogerq@...com>
>>> ---
>>>  arch/arm/boot/dts/dra7-evm.dts  | 5 ++++-
>>>  arch/arm/boot/dts/dra7.dtsi     | 4 ++++
>>>  arch/arm/boot/dts/dra72-evm.dts | 5 ++++-
>>>  3 files changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>>> index a6c82e5..8a31161 100644
>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>> @@ -585,9 +585,12 @@
>>>  	status = "okay";
>>>  	pinctrl-names = "default";
>>>  	pinctrl-0 = <&nand_flash_x16>;
>>> -	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
>>> +	ranges = <0 0 0x08000000 0x01000000>;	/* minimum GPMC partition = 16MB */
>>>  	nand@0,0 {
>>> +		compatible = "ti,omap2-nand";
>>>  		reg = <0 0 4>;		/* device IO registers */
>>> +		interrupt-parent = <&crossbar_mpu>;
>>> +		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
>>>  		ti,nand-ecc-opt = "bch8";
>>>  		ti,elm-id = <&elm>;
>>>  		nand-bus-width = <16>;
>>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>>> index 5d65db9..f0a3616 100644
>>> --- a/arch/arm/boot/dts/dra7.dtsi
>>> +++ b/arch/arm/boot/dts/dra7.dtsi
>>> @@ -1389,6 +1389,10 @@
>>>  			gpmc,num-waitpins = <2>;
>>>  			#address-cells = <2>;
>>>  			#size-cells = <1>;
>>> +			gpio-controller;
>>> +			#gpio-cells = <2>;
>>> +			interrupt-controller;
>>> +			#interrupt-cells = <2>;
>>>  			status = "disabled";
>>>  		};
>> Based on the discussion on my patchset I noticed that the nand node defines the
>> interrupt but it is also defined in the parent node. Similar to the dma channel we
>> should conclude where the best place for it to be defined.  But to me it seems at
>> least it should only be defined once.
> The interrupt is defined at both places because it is used at both places.
> It is used as a shared interrupt. Wait_pin interrupts are managed by the
> gpmc driver and NAND specific interrupts are managed by the NAND driver.
>
> If GPMC dma channel is going to be used only by the NAND driver then
> we should define the channel in the NAND node.
>
>> This is true for your other patches making similar changes to the dt.
> Yes, GPMC IRQ is defined in both GPMC and NAND nodes.
Ok. I would still think you would just reuse the entry from the
parent since you know it will always be the same. But we can
go with what Tony thinks is best.
>
> --
> cheers,
> -roger

--
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/