linux-kernel - Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition

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: <CABxcv=nq9XvyN0aPOBFDm0UyoaW-Htyy0tyP3YhYaDnDUo3a5w@mail.gmail.com>
Date:	Tue, 13 May 2014 16:06:02 +0200
From:	Javier Martinez Canillas <javier@...hile0.org>
To:	Tom Rini <trini@...com>
Cc:	Robert Nelson <robertcnelson@...il.com>,
	Tony Lindgren <tony@...mide.com>,
	Matt Ranostay <mranostay@...il.com>, robh+dt@...nel.org,
	Mark Rutland <mark.rutland@....com>,
	Russell King <linux@....linux.org.uk>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	devicetree <devicetree@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Pantelis Antoniou <pantelis.antoniou@...il.com>,
	Matt Porter <matt.porter@...aro.org>
Subject: Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition

On Tue, May 13, 2014 at 2:53 PM, Tom Rini <trini@...com> wrote:
> On 05/12/2014 04:57 PM, Robert Nelson wrote:
>>>> Either case if fine with me.  As who knows when the dtc "overlay" will
>>>> every truly make it mainline, as the capemgr was the only real kernel
>>>> user of the i2c/at24 eeprom information.
>>>
>>> Sounds like we should keep it disabled though so u-boot can be used
>>> to toggle it while waiting for the capemgr. That's because the board
>>> has a header for pins, so it's not exactly limited to just the capes.
>>>
>>> Anybody working on enabling/disabling cape dtb configurations in u-boot?
>>
>> Well,
>>
>> Would Tom even approve of that in mainline u-boot? He didn't want my
>> "invert" the gpio to enable the usb hub on the older beagle xm A/B..
>>
>> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
>>
>> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.

>
> I would think that using the 'fdt' command in U-Boot to add all
> properties of every cape found on a running system would drive someone
> to madness quite quickly.  Moving all of Pantelis' work for dynamic
> device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
> etc) sounds like a step in the wrong direction.
>

Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.

> --
> Tom

Best regards,
Javier
--
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/