Re: [PATCH 2/6] phy: improved lookup method
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
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
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
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
Hi,
On Tuesday 23 September 2014 05:13 PM, Heikki Krogerus wrote:
On Tue, Sep 23, 2014 at 04:33:09PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 September 2014 04:23 PM, Heikki Krogerus wrote:
On Mon, Sep 22, 2014 at 05:07:55PM +0530, Kishon Vijay Abraham I wrote:
On Thursday 18 September 2014 03:55 PM, Heikki Krogerus wrote:
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I 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.
OK, got it. So I guess we need to match to the phy dev and to the phy
name. First to the dev and then in case the phy name is defined in the
lookup, to that as well. That should cover both cases.
So what would be the phy name? I mean it's completely user-defined or it's
derived from device name?
Isn't making the PHY to be aware of it's user much simpler?
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
On Mon, Sep 22, 2014 at 05:07:55PM +0530, Kishon Vijay Abraham I wrote:
On Thursday 18 September 2014 03:55 PM, Heikki Krogerus wrote:
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I 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?
Thanks,
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
Hi,
On Tuesday 23 September 2014 04:23 PM, Heikki Krogerus wrote:
On Mon, Sep 22, 2014 at 05:07:55PM +0530, Kishon Vijay Abraham I wrote:
On Thursday 18 September 2014 03:55 PM, Heikki Krogerus wrote:
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I 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.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
On Tue, Sep 23, 2014 at 04:33:09PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 September 2014 04:23 PM, Heikki Krogerus wrote:
On Mon, Sep 22, 2014 at 05:07:55PM +0530, Kishon Vijay Abraham I wrote:
On Thursday 18 September 2014 03:55 PM, Heikki Krogerus wrote:
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I 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.
OK, got it. So I guess we need to match to the phy dev and to the phy
name. First to the dev and then in case the phy name is defined in the
lookup, to that as well. That should cover both cases.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
Hi,
On Thursday 18 September 2014 03:55 PM, Heikki Krogerus wrote:
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I 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.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I 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?
Cheers,
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I 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).
True!
So we can't accept statically created lookups. Which is probable the
best thing to do in any case even if there wasn't this issue.
I think we already talked about this. I know I was going to create the
lookup for twl4030 in twl-core.c instead of the board file at one
point, but forgot about it. I need to do that now.
In any case, I'll fix this by dropping the possibility of creating the
lookups statically. I'll prepare new version of the whole set.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
On Thu, Sep 11, 2014 at 09:03:06PM +0530, Kishon Vijay Abraham I wrote:
+static struct phy *phy_find(struct device *dev, const char *con_id)
+{
+ const char *dev_id = dev ? dev_name(dev) : NULL;
+ int match, best_found = 0, best_possible = 0;
+ struct phy *phy = ERR_PTR(-ENODEV);
+ struct phy_lookup *p, *pl = NULL;
+
+ if (dev_id)
+ best_possible += 2;
+ if (con_id)
+ best_possible += 1;
+
+ list_for_each_entry(p, phys, node) {
+ match = 0;
+ if (p-dev_id) {
+ if (!dev_id || strcmp(p-dev_id, dev_id))
+ continue;
+ match += 2;
+ }
+ if (p-con_id) {
+ if (!con_id || strcmp(p-con_id, con_id))
+ continue;
+ match += 1;
+ }
+
+ if (match best_found) {
+ pl = p;
+ if (match != best_possible)
+ best_found = match;
+ else
+ break;
+ }
+ }
+
+ if (pl) {
+ struct class_dev_iter iter;
+ struct device *phy_dev;
+
+ class_dev_iter_init(iter, phy_class, NULL, NULL);
+ while ((phy_dev = class_dev_iter_next(iter))) {
+ if (!strcmp(dev_name(phy_dev), pl-phy_name)) {
I'm not sure how it'll work with systems which has multiple PHYs since the
id
component of the device is determined purely in runtime.
I'd assume we'll be constantly patching the lookup data for non-dt boot :-/
I'm sorry but I don't think I understand (I must be a bit tired
today)? Could you please elaborate?
Have a nice weekend!
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
Hi,
On Friday 12 September 2014 07:37 PM, Heikki Krogerus wrote:
On Thu, Sep 11, 2014 at 09:03:06PM +0530, Kishon Vijay Abraham I wrote:
+static struct phy *phy_find(struct device *dev, const char *con_id)
+{
+ const char *dev_id = dev ? dev_name(dev) : NULL;
+ int match, best_found = 0, best_possible = 0;
+ struct phy *phy = ERR_PTR(-ENODEV);
+ struct phy_lookup *p, *pl = NULL;
+
+ if (dev_id)
+ best_possible += 2;
+ if (con_id)
+ best_possible += 1;
+
+ list_for_each_entry(p, phys, node) {
+ match = 0;
+ if (p-dev_id) {
+ if (!dev_id || strcmp(p-dev_id, dev_id))
+ continue;
+ match += 2;
+ }
+ if (p-con_id) {
+ if (!con_id || strcmp(p-con_id, con_id))
+ continue;
+ match += 1;
+ }
+
+ if (match best_found) {
+ pl = p;
+ if (match != best_possible)
+ best_found = match;
+ else
+ break;
+ }
+ }
+
+ if (pl) {
+ struct class_dev_iter iter;
+ struct device *phy_dev;
+
+ class_dev_iter_init(iter, phy_class, NULL, NULL);
+ while ((phy_dev = class_dev_iter_next(iter))) {
+ if (!strcmp(dev_name(phy_dev), pl-phy_name)) {
I'm not sure how it'll work with systems which has multiple PHYs since the
id
component of the device is determined purely in runtime.
I'd assume we'll be constantly patching the lookup data for non-dt boot :-/
I'm sorry but I don't think I understand (I must be a bit tired
today)? Could you please elaborate?
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).
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
Hi,
On Thursday 21 August 2014 05:03 PM, Heikki Krogerus wrote:
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from clkdev.c.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
.
.
skip
.
.
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index ff5eec5..67a8c726 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -26,6 +26,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phys);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -84,6 +85,138 @@ static struct phy *phy_lookup(struct device *device,
const char *port)
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_register_lookup() - register PHY/device association
+ * @pl: association to register
+ */
+void phy_register_lookup(struct phy_lookup *pl)
+{
+ mutex_lock(phy_provider_mutex);
+ list_add_tail(pl-node, phys);
+ mutex_unlock(phy_provider_mutex);
+}
+
+/**
+ * phy_unregister_lookup() - remove PHY/device association
+ * @pl: association to be removed
+ */
+void phy_unregister_lookup(struct phy_lookup *pl)
+{
+ mutex_lock(phy_provider_mutex);
+ list_del(pl-node);
+ mutex_unlock(phy_provider_mutex);
+}
+
+/**
+ * phy_create_lookup() - allocate and register PHY/device association
+ * @phy: the phy of the association
+ * @con_id: connection ID string on device
+ * @dev_id: the device of the association
+ *
+ * Creates and registers phy_lookup entry.
+ */
+int phy_create_lookup(struct phy *phy, const char *con_id, const char
*dev_id)
+{
+ struct phy_lookup *pl;
+
+ if (!phy || (!dev_id !con_id))
+ return -EINVAL;
+
+ pl = kzalloc(sizeof(*pl), GFP_KERNEL);
+ if (!pl)
+ return -ENOMEM;
+
+ pl-phy_name = dev_name(phy-dev);
+ pl-dev_id = dev_id;
+ pl-con_id = con_id;
+
+ phy_register_lookup(pl);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(phy_create_lookup);
+
+/**
+ * phy_remove_lookup() - find and remove PHY/device association
+ * @phy: the phy of the association
+ * @con_id: connection ID string on device
+ * @dev_id: the device of the association
+ *
+ * Finds and unregisters phy_lookup entry that was created with
+ * phy_create_lookup().
+ */
+void phy_remove_lookup(struct phy *phy, const char *con_id, const char
*dev_id)
+{
+ struct phy_lookup *pl;
+
+ if (!phy || (!dev_id !con_id))
+ return;
+
+ list_for_each_entry(pl, phys, node)
+ if (!strcmp(pl-phy_name, dev_name(phy-dev))
+ !strcmp(pl-dev_id, dev_id)
+ !strcmp(pl-con_id, con_id)) {
+ phy_unregister_lookup(pl);
+ kfree(pl);
+ return;
+ }
+}
+EXPORT_SYMBOL_GPL(phy_remove_lookup);
+
+static struct phy *phy_find(struct device *dev, const char *con_id)
+{
+ const char *dev_id = dev ? dev_name(dev) : NULL;
+ int match, best_found = 0, best_possible = 0;
+ struct phy *phy = ERR_PTR(-ENODEV);
+ struct phy_lookup *p, *pl = NULL;
+
+ if (dev_id)
+ best_possible += 2;
+ if (con_id)
+ best_possible += 1;
+
+ list_for_each_entry(p, phys, node) {
+ match = 0;
+ if (p-dev_id) {
+ if (!dev_id || strcmp(p-dev_id, dev_id))
+ continue;
+ match += 2;
+ }
+ if (p-con_id) {
+ if (!con_id || strcmp(p-con_id, con_id))
+ continue;
+ match += 1;
+ }
+
+ if (match best_found) {
+ pl = p;
+ if (match != best_possible)
+ best_found = match;
+ else
+ break;
+ }
+ }
+
+ if (pl) {
+ struct class_dev_iter iter;
+ struct device *phy_dev;
+
+ class_dev_iter_init(iter, phy_class, NULL, NULL);
+ while ((phy_dev = class_dev_iter_next(iter))) {
+ if (!strcmp(dev_name(phy_dev), pl-phy_name)) {
I'm not sure how it'll work with systems which has multiple PHYs since the id
component of the device is determined purely in runtime.
I'd assume we'll be constantly patching the lookup data for non-dt boot :-/
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] phy: improved lookup method
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from clkdev.c.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
Documentation/phy.txt | 66 ---
drivers/phy/phy-core.c | 135 +++-
include/linux/phy/phy.h | 27 ++
3 files changed, 183 insertions(+), 45 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index c6594af..8add515 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for other
peripheral controllers
to make use of it. The PHY framework provides 2 APIs to create the PHY.
struct phy *phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer and phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
Inorder to dereference the private data (in phy_ops), the phy provider driver
can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
@@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get,
phy_pm_runtime_get_sync,
phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
phy_pm_runtime_forbid for performing PM operations.
-8. Board File Initialization
-
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
-
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(dwc3.0, usb),
- PHY_CONSUMER(pcie.0, pcie),
- PHY_CONSUMER(sata.0, sata),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
-
-static const struct platform_device pipe3_phy_dev = {
- .name = pipe3-phy,
- .id = -1,
- .dev = {
- .platform_data = {
- .init_data = init_data,
- },
- },
-};
-
-then, while doing phy_create, the PHY driver should pass this init_data
- phy_create(dev, ops, pdata-init_data);
-
-and the controller driver (phy consumer) should pass the port name along with
-the device to get a reference to the PHY
- phy_get(dev, pcie);
+8. PHY Mappings
+
+In order to get reference to a PHY without help from DeviceTree, the framework
+offers lookups which can be compared to clkdev that allow clk structures to be
+bound to devices. A lookup can be made statically by directly registering
+phy_lookup structure which contains the name of the PHY device, the name of the
+device which the PHY will be bind to and Connection ID string. Alternatively a
+lookup can be made during runtime when a handle to the struct phy already
+exists.
+
+The framework offers the following APIs for registering and unregistering the
+lookups.
+
+void phy_register_lookup(struct phy_lookup *pl);
+int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id);
+
+void phy_unregister_lookup(struct phy_lookup *pl);
+void phy_remove_lookup(struct phy *phy, const char *con_id, const char
*dev_id);
9. DeviceTree Binding
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index ff5eec5..67a8c726 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -26,6 +26,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phys);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -84,6 +85,138 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_register_lookup() - register PHY/device association
+ * @pl: association to register
+ */
+void phy_register_lookup(struct phy_lookup *pl)
+{
+ mutex_lock(phy_provider_mutex);
+ list_add_tail(pl-node, phys);
+
