linux-kernel - Re: [PATCH v7 1/3] DMA: Freescale: revise device tree binding document

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: <1377125156.5029.40.camel@snotra.buserror.net>
Date:	Wed, 21 Aug 2013 17:45:56 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	<hongbo.zhang@...escale.com>, <vinod.koul@...el.com>,
	<djbw@...com>, <leoli@...escale.com>,
	<linuxppc-dev@...ts.ozlabs.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 1/3] DMA: Freescale: revise device tree binding
 document

On Wed, 2013-08-21 at 16:33 -0600, Stephen Warren wrote:
> On 07/29/2013 04:49 AM, hongbo.zhang@...escale.com wrote:
> > From: Hongbo Zhang <hongbo.zhang@...escale.com>
> > 
> > This patch updates the discription of each type of DMA controller and its
> > channels, it is preparation for adding another new DMA controller binding, it
> > also fixes some defects of indent for text alignment at the same time.
> 
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> 
> > -- compatible        : compatible list, contains 2 entries, first is
> > -		 "fsl,CHIP-dma", where CHIP is the processor
> > -		 (mpc8349, mpc8360, etc.) and the second is
> > -		 "fsl,elo-dma"
> > +- compatible        : must include "fsl,elo-dma"
> 
> Why remove the list of supported compatible values. Lately it seems that
> we're moving towards listing more/all the values rather than removing
> their documentation...

Previous versions had language that required fsl,CHIP-dma for 83xx (and
maybe 85xx?) but not the new chip.  I asked for it to be consistent.
The reason that 83xx still has fsl,CHIP-dma is not because of anything
special to 83xx, but that most other chips with this device have been
converted to dtsi and it's much more of a pain to specify the specific
SoC in that context.  The existing language does not match actual device
trees when it comes to 85xx.

Plus, the exact SoC name is of dubious value for integrated devices.  It
doesn't uniquely identify the hardware because different versions of the
SoC could have different versions of the subdevice.  As such, on our
chips we've been moving away from including a compatible that specifies
the exact SoC.  If it turns out we made a mistake in naming different
versions of the device, or if there are errata, the exact SoC can still
be determined at runtime using SVR.

> > -- ranges		: Should be defined as specified in 1) to describe the
> > -		  DMA controller channels.
> > +- ranges            : describes the mapping between the address space of the
> > +                      DMA channels and the address space of the DMA controller
> 
> What is "the address space of the DMA controller". Perhaps this should
> say "the CPU-visible address space" instead?

It's translating from the addresses used in the child nodes to a CCSR
offset.  It's really just a convenience for the readability and
macro-ability of the device tree that we do this translation at all,
versus having an empty ranges and using CCSR offsets in the children.

It's not about translating between the DMA controller's view and the
CPU's view or anything like that.

-Scott

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