linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Kishon Vijay Abraham I <kishon@ti.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: Thu, 25 Sep 2014 10:00:34 +0300	[thread overview]
Message-ID: <20140925070034.GA15854@xps8300> (raw)
In-Reply-To: <54229276.5050000@ti.com>

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

> Isn't making the PHY to be aware of it's user much simpler?

No it's not. I'm not going into this again. We have already gone
through this in the past.


Cheers,

-- 
heikki

  reply	other threads:[~2014-09-25  7:00 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 [this message]
2014-09-29  6:28                         ` Kishon Vijay Abraham I
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=20140925070034.GA15854@xps8300 \
    --to=heikki.krogerus@linux.intel.com \
    --cc=balbi@ti.com \
    --cc=gautam.vivek@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@ti.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 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).