linux-kernel - Re: [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts

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: <1dd57ac3-554f-7d66-97b0-b76c3ddc7854@lechnology.com>
Date:   Wed, 11 Jan 2017 10:25:18 -0600
From:   David Lechner <david@...hnology.com>
To:     Sekhar Nori <nsekhar@...com>
Cc:     Kevin Hilman <khilman@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts

On 01/11/2017 04:42 AM, Sekhar Nori wrote:
> On Friday 06 January 2017 10:03 AM, David Lechner wrote:
>
>> +	beeper {
>> +		compatible = "pwm-beeper";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&ehrpwm0b_pins>, <&amp_pins>;
>> +		pwms = <&ehrpwm0 1 0 0>;
>> +		enable-gpios = <&gpio 111 GPIO_ACTIVE_HIGH>;
>
> Since the enable-gpios binding for pwm beeper is still not accepted, can
> you drop the property or the node itself (if that makes more sense)?

No sound will come out of the speaker without enabling this gpio. So, I 
guess I will just drop this node for now.


>
>> +&spi0 {
>> +	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>> +
>> +	flash@0 {
>> +		compatible = "n25q128a13", "jedec,spi-nor";
>> +		reg = <0>;
>> +		spi-max-frequency = <50000000>;
>> +		ti,spi-wdelay = <8>;
>> +
>> +		/* Partitions are based on the official firmware from LEGO */
>> +		partitions {
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			partition@0 {
>> +				label = "U-Boot";
>> +				reg = <0 0x40000>;
>> +			};
>> +
>> +			partition@...00 {
>> +				label = "U-Boot Env";
>> +				reg = <0x40000 0x10000>;
>> +			};
>> +
>> +			partition@...00 {
>> +				label = "Kernel";
>> +				reg = <0x50000 0x200000>;
>> +			};
>> +
>> +			partition@...000 {
>> +				label = "Filesystem";
>> +				reg = <0x250000 0xa50000>;
>> +			};
>> +
>> +			partition@...000 {
>> +				label = "Storage";
>> +				reg = <0xcb0000 0x2f0000>;
>> +			};
>> +		};
>> +	};
>> +
>> +	adc@3 {
>> +		compatible = "ti-ads7957";
>
> So looks like this works because of_register_spi_device() sets up
> modalias of spi device from compatible string. I am fine with it, just
> highlighting it here to make sure this is acceptable practice. I did not
> really find any precedence for using SPI device name as compatible
> property in existing DTS files.

Indeed. It looks like this sort of "trivial" device binding is just used 
for i2c devices. I will submit some patches to add proper device tree 
bindings and change this to "ti,ads7957".

>
>> +		reg = <3>;
>> +		spi-max-frequency = <10000000>;
>> +		refin-supply = <&adc_ref>;
>> +	};
>
> Rest of the patch looks good to me.
>
> Thanks,
> Sekhar
>