[RFC] Describing arbitrary bus mastering relationships in DT

Grant Grundler grundler at chromium.org
Fri May 9 07:59:44 PDT 2014

Mostly agree with your assessment. My $0.02 on one comment:

On Fri, May 9, 2014 at 3:33 AM, Dave Martin <Dave.Martin at arm.com> wrote:
> The downside is that is any path flows through a dynamically
> configurable component, such as an IOMMU or a bridge that can be
> remapped, turned off etc., then unless we describe how the path is
> really linked together the kernel will need all sorts of baked-in
> knowledge in order to manage the system safely.

Absolutely. Some knowledge (assumptions) will be "baked in" as code
and some knowledge (explicit parameters) as device tree.

My understanding of device tree is it essentially specifies
"parameters" and "methods" (code provided in the kernel). All methods
make some assumptions about the behavior of the HW it's operating on
and as long as all users of a method share that assumption, all is
well. We don't need device tree to describe those assumptions.


More information about the linux-arm-kernel mailing list