All of lore.kernel.org
 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 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.