From: Scott Wood <scottwood@freescale.com>
To: David Miller <davem@davemloft.net>
Cc: <swarren@wwwdotorg.org>, <timur@freescale.com>,
<afleming@freescale.com>, <ddaney.cavm@gmail.com>,
<netdev@vger.kernel.org>, <devicetree-discuss@lists.ozlabs.org>
Subject: Re: [PATCH] [v2] netdev/phy: add MDIO bus multiplexer driven by a memory-mapped device
Date: Fri, 24 Aug 2012 14:18:02 -0500 [thread overview]
Message-ID: <5037D36A.50705@freescale.com> (raw)
In-Reply-To: <20120824.150740.9047511945034908.davem@davemloft.net>
On 08/24/2012 02:07 PM, David Miller wrote:
> From: Stephen Warren <swarren@wwwdotorg.org>
> Date: Fri, 24 Aug 2012 12:56:05 -0600
>
>> 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.
Yes, it's mandatory (even if the kernel lets you get away without it for
the sake of some broken Apple firmware, IIRC). If the translation is an
identity map you can use an empty "ranges;".
> Regardless, you really can't just generically translate ranges
> in some universal way and expect it to work in all cases.
>
> You need bus specific drivers to deal with various special
> cases.
>
> See the *_map() methods implemented in:
>
> arch/sparc/kernel/of_device_64.c
>
> for example.
We don't expect it to work in all cases. We expect it to work if the
bus node is on the whitelist for which we create devices on
platform_bus, there's a platform driver that binds against it, and that
driver calls of_iomap() or equivalent because the binding says that reg
refers to something that is memory mapped.
-Scott
prev parent reply other threads:[~2012-08-24 19:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-23 19:44 [PATCH] [v2] netdev/phy: add MDIO bus multiplexer driven by a memory-mapped device Timur Tabi
[not found] ` <1345751071-23128-1-git-send-email-timur-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2012-08-23 22:54 ` Stephen Warren
2012-08-24 0:28 ` Tabi Timur-B04825
[not found] ` <6AE080B68D46FC4BA2D2769E68D765B7059D1DC7-RL0Hj/+nBVC81RJBUSuqCa4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
2012-08-24 2:46 ` Stephen Warren
2012-08-24 16:27 ` Timur Tabi
2012-08-24 18:29 ` Stephen Warren
2012-08-24 18:36 ` Timur Tabi
2012-08-24 18:43 ` Scott Wood
2012-08-24 18:56 ` Stephen Warren
2012-08-24 19:07 ` David Miller
2012-08-24 19:18 ` Scott Wood [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5037D36A.50705@freescale.com \
--to=scottwood@freescale.com \
--cc=afleming@freescale.com \
--cc=davem@davemloft.net \
--cc=ddaney.cavm@gmail.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=timur@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).