linux-kernel - Re: [PATCHv9 3/3] arm: dts: Add Altera SDRAM controller bindings

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] [day] [month] [year] [list]

Message-ID: <53F21156.70400@opensource.altera.com>
Date:	Mon, 18 Aug 2014 09:44:38 -0500
From:	Thor Thayer <tthayer@...nsource.altera.com>
To:	Rob Herring <robherring2@...il.com>, <pawel.moll@....com>,
	<mark.rutland@....com>, <ijc+devicetree@...lion.org.uk>,
	<galak@...eaurora.org>, <rob@...dley.net>,
	<linux@....linux.org.uk>, <atull@...era.com>,
	<delicious.quinoa@...il.com>, <dinguyen@...era.com>,
	<dougthompson@...ssion.com>, <grant.likely@...aro.org>,
	<bp@...en8.de>, <sameo@...ux.intel.com>, <lee.jones@...aro.org>
CC:	<devicetree@...r.kernel.org>, <linux-doc@...r.kernel.org>,
	<linux-edac@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <tthayer.linux@...il.com>
Subject: Re: [PATCHv9 3/3] arm: dts: Add Altera SDRAM controller bindings


On 08/17/2014 07:50 PM, Rob Herring wrote:
> On 07/30/2014 01:22 PM, tthayer@...nsource.altera.com wrote:
>> From: Thor Thayer <tthayer@...nsource.altera.com>
>>
>> Add the Altera SDRAM controller bindings and device tree changes to the Altera SoC project.
>>
>> Signed-off-by: Thor Thayer <tthayer@...nsource.altera.com>
>> ---
>> v2: Changes to SoC SDRAM EDAC code.
>>
>> v3: Implement code suggestions for SDRAM EDAC code.
>>
>> v4: Remove syscon from SDRAM controller bindings.
>>
>> v5: No Change, bump version for consistency.
>>
>> v6: Only map the ctrlcfg register as syscon.
>>
>> v7: No change. Bump for consistency.
>>
>> v8: No change. Bump for consistency.
>>
>> v9: Changes to support a MFD SDRAM controller with nested EDAC.
>> ---
>>   .../devicetree/bindings/arm/altera/socfpga-sdr.txt |   13 +++++++++++++
>>   arch/arm/boot/dts/socfpga.dtsi                     |   10 ++++++++++
>>   2 files changed, 23 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt
>> new file mode 100644
>> index 0000000..2bb1ddf
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt
>> @@ -0,0 +1,13 @@
>> +Altera SOCFPGA SDRAM Controller
>> +The SDRAM controller is implemented as a MFD so various drivers may
>> +nest under this main SDRAM controller binding.
>> +
>> +Required properties:
>> +- compatible : "altr,sdr";
>> +- reg : Should contain 1 register range(address and length)
>> +
>> +Example:
>> +	sdr@...fc25000 {
>> +		compatible = "altr,sdr";
>> +		reg = <0xffc25000 0x1000>;
>> +	};
>> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
>> index 4676f25..ecb306d 100644
>> --- a/arch/arm/boot/dts/socfpga.dtsi
>> +++ b/arch/arm/boot/dts/socfpga.dtsi
>> @@ -603,6 +603,16 @@
>>   			};
>>   		};
>>   
>> +		sdr@...fc25000 {
>> +			compatible = "altr,sdr";
>> +			reg = <0xffc25000 0x1000>;
>> +
>> +			sdramedac@0 {
>> +				compatible = "altr,sdram-edac";
>> +				interrupts = <0 39 4>;
>> +			};
> This doesn't match the documentation, but I don't think this is a move
> in the right direction anyway. Because Linux has/wants an MFD driver is
> not a reason to add a sub node. It is a single h/w block and DT should
> reflect that.
>
> Rob
Hi Rob,

Thanks for reviewing. After discussions with the community and 
internally, I reverted to using the syscon case in revision 10. I 
apologize for the confusion but the syscon method seems to be a cleaner 
solution. I submitted the sycon version on 8/11/14.

Thanks,

Thor

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