From: Kishon Vijay Abraham I <kishon@ti.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Felipe Balbi <balbi@ti.com>,
Vivek Gautam <gautam.vivek@samsung.com>,
<linux-kernel@vger.kernel.org>, <linux-usb@vger.kernel.org>
Subject: Re: [PATCH 2/6] phy: improved lookup method
Date: Mon, 29 Sep 2014 11:58:15 +0530 [thread overview]
Message-ID: <5428FBFF.6050804@ti.com> (raw)
In-Reply-To: <20140925070034.GA15854@xps8300>
On Thursday 25 September 2014 12:30 PM, Heikki Krogerus wrote:
>>>>>>>>> Assume you have 2 phys in your system..
>>>>>>>>> static struct phy_lookup usb_lookup = {
>>>>>>>>> .phy_name = "phy-usb.0",
>>>>>>>>> .dev_id = "usb.0",
>>>>>>>>> .con_id = "usb",
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> static struct phy_lookup sata_lookup = {
>>>>>>>>> .phy_name = "sata-usb.1",
>>>>>>>>> .dev_id = "sata.0",
>>>>>>>>> .con_id = "sata",
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> First you do modprobe phy-usb, the probe of USB PHY driver gets invoked and it
>>>>>>>>> creates the PHY. The phy-core will find a free id (now it will be 0) and then
>>>>>>>>> name the phy as phy-usb.0.
>>>>>>>>> Then with modprobe phy-sata, the phy-core will create phy-sata.1.
>>>>>>>>>
>>>>>>>>> This is an ideal case where the .phy_name in phy_lookup matches.
>>>>>>>>>
>>>>>>>>> Consider if the order is flipped and the user does modprobe phy-sata first. The
>>>>>>>>> phy_names won't match anymore (the sata phy device name would be "sata-usb.0").
>>>>>>>
>>>>>>> Actually, I don't think there would be this problem if we used the
>>>>>>> name of the actual device which is the parent of phy devices, right?
>>>>>>
>>>>>> hmm.. but if the parent is a multi-phy phy provider (like pipe3 PHY driver), we
>>>>>> might end up with the same problem.
>>>>>
>>>>> I'm not completely sure what you mean? If you are talking about
>>>>> platforms with multiple instances of a single phy, I don't see how
>>>>> there could ever be a scenario where we did not know the order in
>>>>> which they were enumerated. Can you give an example again?
>>>>
>>>> If a single IP implements multiple PHYs (phy-miphy365x.c in linux-phy next),
>>>> the parent for all the phy devices would be the same.
>
> Hold on...
>
> Let's take a step back here. Where could we actually have a scenario
> where the phy device, the dev_id (consumer) and the con_id would all
> be the same? There can't be such a case.
>
> It's not like you could ever have a driver requesting multiple phys
> with the same con_id. You would just get the same phy handle even if
> you used dt.
>
> phy1 = phy_get(dev, "phy");
> ...
> phy2 = phy_get(dev, "phy");
>
> And if the drivers requesting those phys are different, your consumers
> are different.
sounds right to me.
Cheers
Kishon
next prev parent reply other threads:[~2014-09-29 6:28 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-21 11:33 [PATCHv3 0/6] phy: simplified phy lookup Heikki Krogerus
2014-08-21 11:33 ` [PATCH 1/6] phy: safer to_phy() macro Heikki Krogerus
2014-08-21 11:33 ` [PATCH 2/6] phy: improved lookup method Heikki Krogerus
2014-09-11 15:33 ` Kishon Vijay Abraham I
2014-09-12 14:07 ` Heikki Krogerus
2014-09-12 14:46 ` Kishon Vijay Abraham I
2014-09-15 12:35 ` Heikki Krogerus
2014-09-18 10:25 ` Heikki Krogerus
2014-09-22 11:37 ` Kishon Vijay Abraham I
2014-09-23 10:53 ` Heikki Krogerus
2014-09-23 11:03 ` Kishon Vijay Abraham I
2014-09-23 11:43 ` Heikki Krogerus
2014-09-24 9:44 ` Kishon Vijay Abraham I
2014-09-25 7:00 ` Heikki Krogerus
2014-09-29 6:28 ` Kishon Vijay Abraham I [this message]
2014-08-21 11:33 ` [PATCH 3/6] arm: omap3: twl: use the new lookup method with usb phy Heikki Krogerus
2014-09-11 15:26 ` Kishon Vijay Abraham I
2014-09-12 13:50 ` Heikki Krogerus
2014-08-21 11:33 ` [PATCH 4/6] phy: remove the old lookup method Heikki Krogerus
2014-08-25 7:41 ` Vivek Gautam
2014-08-25 8:17 ` Heikki Krogerus
2014-08-25 8:25 ` Vivek Gautam
2014-08-26 8:27 ` [PATCHv4 " Heikki Krogerus
2014-08-21 11:33 ` [PATCH 5/6] base: platform: name the device already during allocation Heikki Krogerus
2014-08-21 11:33 ` [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci Heikki Krogerus
2014-09-11 15:01 ` Kishon Vijay Abraham I
2014-09-12 13:49 ` Heikki Krogerus
2014-09-12 14:11 ` Kishon Vijay Abraham I
2014-09-15 12:06 ` Heikki Krogerus
2014-09-16 6:37 ` Kishon Vijay Abraham I
2014-09-16 12:13 ` Heikki Krogerus
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=5428FBFF.6050804@ti.com \
--to=kishon@ti.com \
--cc=balbi@ti.com \
--cc=gautam.vivek@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.