From: Kishon Vijay Abraham I <kishon@ti.com>
To: "Antoine Ténart" <antoine.tenart@free-electrons.com>
Cc: sebastian.hesselbarth@gmail.com, tj@kernel.org,
alexandre.belloni@free-electrons.com,
thomas.petazzoni@free-electrons.com, zmxu@marvell.com,
jszhang@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-ide@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/6] phy: add a driver for the Berlin SATA PHY
Date: Thu, 15 May 2014 11:45:16 +0530 [thread overview]
Message-ID: <53745B74.2040808@ti.com> (raw)
In-Reply-To: <20140514102122.GA11140@kwain>
Hi,
On Wednesday 14 May 2014 03:51 PM, Antoine Ténart wrote:
> Hi,
>
> On Wed, May 14, 2014 at 03:43:03PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 14 May 2014 03:18 PM, Antoine Ténart wrote:
>
> […]
>
>>> +#define to_berlin_sata_phy_priv(desc) \
>>> + container_of((desc), struct phy_berlin_priv, phys[(desc)->index])
>>> +
>>> +struct phy_berlin_desc {
>>> + struct phy *phy;
>>> + u32 val;
>>> + unsigned index;
>>> +};
>>> +
>>> +struct phy_berlin_priv {
>>> + void __iomem *base;
>>> + spinlock_t lock;
>>> + struct phy_berlin_desc phys[BERLIN_SATA_PHY_NB];
>>
>> Can't we do away with hardcoding BERLIN_SATA_PHY_NB?
>
> We can't if we want to be able to use the container_of macro in
> to_berlin_sata_phy_priv(). And we want a common structure to store the
> common spinlock and base address.
to get phy_berlin_priv, you can use dev_get_drvdata(phy->dev->parent).
>
> […]
>
>>> + /*
>>> + * By default the PHY node is used to request and match a PHY.
>>> + * We describe one PHY per sub-node here. Use the right node.
>>> + */
>>> + phy->dev.of_node = child;
>>> +
>>> + priv->phys[phy_id].phy = phy;
>>> + priv->phys[phy_id].val = desc[phy_id].val;
>>> + priv->phys[phy_id].index = phy_id;
>>> + phy_set_drvdata(phy, &priv->phys[phy_id]);
>>> +
>>> + /* Make sure the PHY is off */
>>> + phy_berlin_sata_power_off(phy);
>>> +
>>> + phy_provider = devm_of_phy_provider_register(&phy->dev,
>>> + of_phy_simple_xlate);
>>> + if (IS_ERR(phy_provider))
>>> + return PTR_ERR(phy_provider);
>>
>> was this intentional? registering multiple PHY providers?
>
> Yes. Each sub-node describe a PHY and register as a PHY provider. This
> allow to reference the PHY as <&sata_phy0> and not <&sata_phy 0>. It
> would be confusing to have a sub-node sata_phy0 and to use its parent
> to access it.
It is still a single PHY provider, so you can't register multiple PHY
providers. So in this case <&sata_phy 0> is not that bad.
However phy-core.c should be patched with the following (only compile tested)
From 2517d4c0ad7f13abc2613516ef2b222a1fbcb550 Mon Sep 17 00:00:00 2001
From: Kishon Vijay Abraham I <kishon@ti.com>
Date: Thu, 15 May 2014 11:32:57 +0530
Subject: [PATCH] phy: phy-core: Support modelling multi-PHY PHY nodes as
subnodes of PHY PROVIDER
When a single PHY provider implementing multiple PHYs is represented in dt,
the PHYs should be modelled as sub nodes of the PHY PROVIDER node.
So the consumers using the PHY will have the phandle of the sub node rather
than the phandle of the PHY PROVIDER. Amended *of_phy_provider_lookup* in
PHY core to return the PHY PROVIDER even when the phandle of the PHY PROVIDERs
sub node is provided.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
drivers/phy/phy-core.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 03cf8fb..124c6ec 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -83,10 +83,18 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
{
struct phy_provider *phy_provider;
+ struct device_node *child;
list_for_each_entry(phy_provider, &phy_provider_list, list) {
- if (phy_provider->dev->of_node == node)
+ if (phy_provider->dev->of_node != node) {
+ for_each_child_of_node(phy_provider->dev->of_node,
+ child) {
+ if (child == node)
+ return phy_provider;
+ }
+ } else {
return phy_provider;
+ }
}
return ERR_PTR(-EPROBE_DEFER);
--
1.7.9.5
Thanks
Kishon
next prev parent reply other threads:[~2014-05-15 6:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 9:48 [PATCH v3 0/6] ARM: berlin: add AHCI support Antoine Ténart
2014-05-14 9:48 ` [PATCH v3 1/6] phy: add a driver for the Berlin SATA PHY Antoine Ténart
2014-05-14 10:13 ` Kishon Vijay Abraham I
2014-05-14 10:21 ` Antoine Ténart
2014-05-15 6:15 ` Kishon Vijay Abraham I [this message]
2014-05-14 13:02 ` Arnd Bergmann
2014-05-14 14:50 ` Antoine Ténart
2014-05-14 15:31 ` Arnd Bergmann
2014-05-14 15:49 ` Antoine Ténart
2014-05-14 16:11 ` Arnd Bergmann
2014-05-14 16:57 ` Antoine Ténart
2014-05-14 17:57 ` Sebastian Hesselbarth
2014-05-14 18:12 ` Arnd Bergmann
2014-05-14 18:42 ` Sebastian Hesselbarth
2014-05-14 18:51 ` Arnd Bergmann
2014-05-14 18:56 ` Sebastian Hesselbarth
2014-05-14 19:10 ` Arnd Bergmann
2014-05-15 6:45 ` Kishon Vijay Abraham I
2014-05-15 7:02 ` Sebastian Hesselbarth
2014-05-15 8:46 ` Kishon Vijay Abraham I
[not found] ` <53747F03.5030206-l0cyMroinI0@public.gmane.org>
2014-05-15 9:17 ` Sebastian Hesselbarth
2014-05-15 9:25 ` Kishon Vijay Abraham I
2014-05-14 9:48 ` [PATCH v3 2/6] Documentation: bindings: add " Antoine Ténart
[not found] ` <1400060942-10588-1-git-send-email-antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-05-14 9:48 ` [PATCH v3 3/6] ata: ahci: add AHCI support for the Berlin BG2Q Antoine Ténart
2014-05-14 9:49 ` [PATCH v3 4/6] Documentation: bindings: add the berlin-ahci compatible to the ahci platform Antoine Ténart
2014-05-14 9:49 ` [PATCH v3 5/6] ARM: berlin: add the AHCI node for the BG2Q Antoine Ténart
2014-05-14 9:49 ` [PATCH v3 6/6] ARM: berlin: enable the eSATA interface on the BG2Q DMP Antoine Ténart
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=53745B74.2040808@ti.com \
--to=kishon@ti.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=antoine.tenart@free-electrons.com \
--cc=devicetree@vger.kernel.org \
--cc=jszhang@marvell.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=tj@kernel.org \
--cc=zmxu@marvell.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).