[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5037CE45.4010309@wwwdotorg.org>
Date: Fri, 24 Aug 2012 12:56:05 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Timur Tabi <timur@...escale.com>
CC: Fleming Andy-AFLEMING <afleming@...escale.com>,
David Miller <davem@...emloft.net>,
"ddaney.cavm@...il.com" <ddaney.cavm@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
Scott Wood <scottwood@...escale.com>
Subject: Re: [PATCH] [v2] netdev/phy: add MDIO bus multiplexer driven by a
memory-mapped device
On 08/24/2012 12:36 PM, Timur Tabi wrote:
> Stephen Warren wrote:
>> When translating the child node's reg property into the parent's address
>> space, the parent's reg property shouldn't even be used at all; all the
>> mapping is done through the ranges property.
>>
>> I thought the code error-checked for a missing ranges property, but I
>> guess not...
>
> I don't think 'ranges' is always necessary, because sometimes the child
> nodes have a different address space that's not mapped to the parent. For
> instance, I2C devices have addresses that are not mapped to the I2C
> controller itself.
In the I2C case, the address spaces are disjoint, so there's never any
mapping between them, so there's no need for ranges.
Any time the child address space is intended to be part of the parent's
address space, I believe ranges is supposed to be specified, perhaps
even mandatory, even if the translation is 1:1.
> Anyway, thanks to Scott for helping me figure this out. I was missing a
> ranges property:
>
> fpga: board-control@3,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,p5020ds-fpga", "fsl,fpga-ngpixis";
> reg = <3 0 0x30>;
> ranges = <0 3 0 0x30>;
>
> This maps the child address of 0 to the parent address of 3 0.
Yes, that looks reasonable.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists