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]
Date:	Wed, 21 Aug 2013 08:23:05 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Dong Aisheng <b29396@...escale.com>
Cc:	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>, rob@...dley.net,
	Rob Herring <rob.herring@...xeda.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/3] of: add update device node status via cmdline feature

On Wed, Aug 21, 2013 at 7:47 AM, Dong Aisheng <b29396@...escale.com> wrote:
> On Thu, Aug 15, 2013 at 07:37:04AM -0500, Rob Herring wrote:
>> On 08/15/2013 05:55 AM, Dong Aisheng wrote:
>> > We meet some boards having a lot of pin conflicts between different devices,
>> > only one of them can be enabled to run at one time.
>> >
>> > e.g. imx6q sabreauto board, i2c, spi, weim, flexcan, uart and etc involved
>> > with pin conflict.
>> >
>> > Instead of changing dts manually or adding a lot dts files according to
>> > different device availability, we provide feature to dynamically update the
>> > device node status via command line, then those devices involved with
>> > pin conflict can be enabled or disabled dynamically.
>> >
>> > It's conveniently to use and can save a lot dts board files, also can
>> > permenantly fix the pin conflicts issue.
>>
>> This doesn't scale either with updating of lots devices or when the next
>> person comes along and wants to edit another property.
>>
>
> I'm not sure about other property.
> But we update it did cause by the real requirement, not arbitrary.
> Or we can try to find another better way to avoid it.
>
>> This is something u-boot is perfectly capable of handling and updating
>> status is something lots of boards already do.
>>
>
> How does uboot handle this according to our needs?
> Also dynamically update the device node status with uboot command?
> Can you help point out an example for me to check?
>

Here's an example adding a status property with u-boot commands:

Highbank #fdt print /soc/ethernet
ethernet@...50000 {
        compatible = "calxeda,hb-xgmac";
        reg = <0xfff50000 0x00001000>;
        interrupts = <0x00000000 0x0000004d 0x00000004 0x00000000
0x0000004e 0x00000004 0x00000000 0x0000004f 0x00000004>;
        dma-coherent;
};
Highbank #fdt set /soc/ethernet status okay
Highbank #fdt print /soc/ethernet
ethernet@...50000 {
        status = "okay";
        compatible = "calxeda,hb-xgmac";
        reg = <0xfff50000 0x00001000>;
        interrupts = <0x00000000 0x0000004d 0x00000004 0x00000000
0x0000004e 0x00000004 0x00000000 0x0000004f 0x00000004>;
        dma-coherent;
};

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ