drivers/core/of: Add symlink to device-tree from devices with an OF node
PATCH 2/2 drivers/core/of: Add symlink to device-tree from devices with an OF node
So I've been annoyed lately with having a bunch of devices such as i2c eeproms (for use by VPDs, server world !) and other bits and pieces that I want to be able to identify from userspace, and possibly provide additional data about from FW.
Basically, it boils down to correlating the sysfs device with the OF tree device node, so that user space can use device-tree info such as additional "location" or "label" (or whatever else we can come up with) properties to identify a given device, or get some attributes of use about it, etc...
Now, so far, we've done that in some subsystem in a fairly ad-hoc basis using "devspec" properties. For example, PCI creates them if it can correlate the probed device with a DT node. Some powerpc specific busses do that too.
However, i2c doesn't and it would be nice to have something more generic since technically any device can have a corresponding device tree node these days.
This patch achieves this by adding an "of_node" symlink to devices that have a non-NULL dev->of_node pointer.
--- drivers/base/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/base/core.c +8 -0
@@ -469,6 +469,7 @@ static int device_add_attrs(struct device *dev) {struct class *class = dev->class;const struct device_type *type = dev->type; +struct device_node *of_node;int error;if (class) {
@@ -493,6 +494,13 @@ static int device_add_attrs(struct device *dev) goto err_remove_dev_groups; } + of_node =dev_of_node (dev); +if (of_node) { + error =sysfs_create_link (&dev->kobj, &of_node->kobj,"of_node" ); +if (error) +dev_warn (dev,"Error %d creating of_node link\n" , error); + } +return 0 ; err_remove_dev_groups:
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · On Monday 16 February 2015 14:59:16 Benjamin Herrenschmidt wrote:
So I've been annoyed lately with having a bunch of devices such as i2c eeproms (for use by VPDs, server world !) and other bits and pieces that I want to be able to identify from userspace, and possibly provide additional data about from FW.
Basically, it boils down to correlating the sysfs device with the OF tree device node, so that user space can use device-tree info such as additional "location" or "label" (or whatever else we can come up with) properties to identify a given device, or get some attributes of use about it, etc...
Now, so far, we've done that in some subsystem in a fairly ad-hoc basis using "devspec" properties. For example, PCI creates them if it can correlate the probed device with a DT node. Some powerpc specific busses do that too.
Quoted 8 lines
However, i2c doesn't and it would be nice to have something more generic since technically any device can have a corresponding device tree node these days.
This patch achieves this by adding an "
of_node" symlink to devices that have a non-NULLdev->of_nodepointer.Signed-off-by Benjamin Herrenschmidt <[email protected]>
I like the idea, this seems very useful.
+GregKH
Quoted 16 lines · Benjamin Herrenschmidt
So I've been annoyed lately with having a bunch of devices such as i2c eeproms (for use by VPDs, server world !) and other bits and pieces that I want to be able to identify from userspace, and possibly provide additional data about from FW.
Basically, it boils down to correlating the sysfs device with the OF tree device node, so that user space can use device-tree info such as additional "location" or "label" (or whatever else we can come up with) properties to identify a given device, or get some attributes of use about it, etc...
Now, so far, we've done that in some subsystem in a fairly ad-hoc basis using "devspec" properties. For example, PCI creates them if it can correlate the probed device with a DT node. Some powerpc specific busses do that too.
Quoted 6 lines
However, i2c doesn't and it would be nice to have something more generic since technically any device can have a corresponding device tree node these days.
This patch achieves this by adding an "
of_node" symlink to devices that have a non-NULLdev->of_nodepointer.
Doesn't this need sysfs documentation?
Quoted 1 line
Signed-off-by Benjamin Herrenschmidt <[email protected]>
I don't mind applying, but this is Greg's code.
Rob
Quoted 33 lines
--- drivers/base/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)drivers/base/core.c +8
-0@@ -469,6 +469,7 @@ static int device_add_attrs(struct device *dev) {struct class *class = dev->class;const struct device_type *type = dev->type; +struct device_node *of_node;int error;if (class) {@@ -493,6 +494,13 @@ static int device_add_attrs(struct device *dev) goto err_remove_dev_groups; } + of_node =dev_of_node (dev); +if (of_node) { + error =sysfs_create_link (&dev->kobj, &of_node->kobj,"of_node" ); +if (error) +dev_warn (dev,"Error %d creating of_node link\n" , error); + } +return 0 ; err_remove_dev_groups:
Greg Kroah-Hartman
maintainerQuoted 20 lines · Rob Herring
+GregKH
Quoted 16 lines · Benjamin Herrenschmidt
So I've been annoyed lately with having a bunch of devices such as i2c eeproms (for use by VPDs, server world !) and other bits and pieces that I want to be able to identify from userspace, and possibly provide additional data about from FW.
Basically, it boils down to correlating the sysfs device with the OF tree device node, so that user space can use device-tree info such as additional "location" or "label" (or whatever else we can come up with) properties to identify a given device, or get some attributes of use about it, etc...
Now, so far, we've done that in some subsystem in a fairly ad-hoc basis using "devspec" properties. For example, PCI creates them if it can correlate the probed device with a DT node. Some powerpc specific busses do that too.
Quoted 8 lines
Quoted 6 lines
However, i2c doesn't and it would be nice to have something more generic since technically any device can have a corresponding device tree node these days.
This patch achieves this by adding an "
of_node" symlink to devices that have a non-NULLdev->of_nodepointer.Doesn't this need sysfs documentation?
Yes it does.
Quoted 26 lines
Quoted 1 line
Signed-off-by Benjamin Herrenschmidt <[email protected]>I don't mind applying, but this is Greg's code.
Rob
Quoted 20 lines
--- drivers/base/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)drivers/base/core.c +1
-0@@ -469,6 +469,7 @@ static int device_add_attrs(struct device *dev) {struct class *class = dev->class;const struct device_type *type = dev->type; +struct device_node *of_node;int error;if (class) {@@ -493,6 +494,13 @@ static int device_add_attrs(struct device *dev) goto err_remove_dev_groups; }
Quoted 6 lines
drivers/base/core.c static int device_add_attrs(struct device *dev) · line 502
Quoted 6 lines
drivers/base/core.c +6
-0+ of_node =dev_of_node (dev); +if (of_node) { + error =sysfs_create_link (&dev->kobj, &of_node->kobj,"of_node" ); +if (error) +dev_warn (dev,"Error %d creating of_node link\n" , error); + }
You don't clean up the link when the device is removed?
And why do it here and not in device_add_class_symlinks() like all other devices do?
thanks,
greg k-h
Quoted 4 lines · Greg Kroah-Hartman
Quoted 2 lines
Doesn't this need sysfs documentation?
Yes it does.
Ok, will do.
Quoted 26 lines
Quoted 26 lines
Quoted 1 line
Signed-off-by Benjamin Herrenschmidt <[email protected]>I don't mind applying, but this is Greg's code.
Rob
Quoted 20 lines
--- drivers/base/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)drivers/base/core.c +1
-0@@ -469,6 +469,7 @@ static int device_add_attrs(struct device *dev) {struct class *class = dev->class;const struct device_type *type = dev->type; +struct device_node *of_node;int error;if (class) {@@ -493,6 +494,13 @@ static int device_add_attrs(struct device *dev) goto err_remove_dev_groups; }
Quoted 8 lines
Quoted 6 lines
drivers/base/core.c static int device_add_attrs(struct device *dev) · line 502
Quoted 6 lines
drivers/base/core.c +6
-0+ of_node =dev_of_node (dev); +if (of_node) { + error =sysfs_create_link (&dev->kobj, &of_node->kobj,"of_node" ); +if (error) +dev_warn (dev,"Error %d creating of_node link\n" , error); + }You don't clean up the link when the device is removed?
Hrm, I suppose I do :-)
Quoted 2 lines
And why do it here and not in
device_add_class_symlinks()like all other devices do?
Well, device_add_class_symlinks() had "class" in the name so I (incorrectly) assumed that was for class related stuff, but I see that the parent pointer is there too. Also originally my patch was adding an attribute and got turned into a symlink later. I'll move it.
Cheers,
Ben.
Quoted 7 lines
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · Benjamin Herrenschmidt
So I've been annoyed lately with having a bunch of devices such as i2c eeproms (for use by VPDs, server world !) and other bits and pieces that I want to be able to identify from userspace, and possibly provide additional data about from FW.
Basically, it boils down to correlating the sysfs device with the OF tree device node, so that user space can use device-tree info such as additional "location" or "label" (or whatever else we can come up with) properties to identify a given device, or get some attributes of use about it, etc...
Now, so far, we've done that in some subsystem in a fairly ad-hoc basis using "devspec" properties. For example, PCI creates them if it can correlate the probed device with a DT node. Some powerpc specific busses do that too.
Quoted 8 lines
However, i2c doesn't and it would be nice to have something more generic since technically any device can have a corresponding device tree node these days.
This patch achieves this by adding an "
of_node" symlink to devices that have a non-NULLdev->of_nodepointer.Signed-off-by Benjamin Herrenschmidt <[email protected]>
Concept:
We've come across similar needs on product, and always had to do some less-than-optimal alternate solution. This seems like a good idea to me.
-Olof