linux-kernel - Re: [RFC] (early draft) dt: Linux dt usage model documentation

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

Message-ID: <BANLkTinp19mk0Hjwuw0ewGOnbL9VQjfisw@mail.gmail.com>
Date:	Tue, 14 Jun 2011 11:47:40 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	FarMcKon@...labs.net
Cc:	devicetree-discuss@...ts.ozlabs.org,
	Randy Dunlap <rdunlap@...otime.net>,
	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: Re: [RFC] (early draft) dt: Linux dt usage model documentation

On Tue, Jun 14, 2011 at 8:05 AM, Far McKon <far.mckon@...labs.net> wrote:
> Grant,
> I don't see any system for indicating an expandable bus or a pulg in
> module so far? Am I missing something, or does this protocol/layout
> not allow for plug in or expansion modules?

The DT as we're using it now primarily captures the static structure
of the system.  Typically this means anything directly on-board, or
unlikely to ever be hot-plugged (like a CPU module on a carrier
board).  The DT is expressive enough to capture the details of plugged
in modules, but in general if the device can be detected and
identified reliably by the hardware (like USB and PCI devices), then
there is no real need to describe it in the DT.

With 'real' OpenFirmware, the firmware did indeed enumerate hot
plugged devices in the DT, but we don't do that at all for the
firmware using the flattened tree.

That said, you may have a need to describe the internal details of a
plug in module, and you could do that with DT.  XIlinx has done some
work that allows a partial DT to be passed in at runtime to describe
the behaviour of an FPGA module after it has been programmed with a
bitstream.

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