Messages in this thread | | | Date | Mon, 18 May 2020 10:04:35 +0200 | From | Greg Kroah-Hartman <> | Subject | Re: [RFC PATCH v1] driver core: Expose device link details in sysfs |
| |
On Mon, May 18, 2020 at 12:06:07AM -0700, Saravana Kannan wrote: > It's helpful to be able to look at device link details from sysfs. So, > expose it in sysfs. > > Say device-A is supplier of device-B. These are the additional files > this patch would create: > > /sys/class/devlink/device-A:device-B/ > flags > supplier/ -> .../device-A/ > consumer/ -> .../device-B/ > > /sys/devices/.../device-A/ > consumer:device-B/ -> /sys/class/devlink/device-A:device-B/ > > /sys/devices/.../device-B/ > supplier:device-A/ -> /sys/class/devlink/device-A:device-B/ > > That way: > To get a list of all the device link in the system: > ls /sys/class/devlink/ > > To get the consumer names and links of a device: > ls -d /sys/devices/.../device-X/consumer:* > > To get the supplier names and links of a device: > ls -d /sys/devices/.../device-X/supplier:* > > For now, I'm just exporting "flags", supplier and consumer for each > device link. But the goal is to expand it to "state", etc once the > overall idea is accepted. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > Greg/Rafael, > > Wanted to check if both of you are okay with the overall idea of > exporting device link details through sysfs and if using a "struct > device" is how you'd like to do it. I think this information would be > helpful in debugging all kinds of suspend/resume, probe and power issues > in a production system. I didn't want to spend more time on this patch > before I got your okays. > > I'm not too familiar with the right way to do kobjs and symlinks in > sysfs -- so apologies any crazy code. But overall, the patch does create > the layout I describe above and seems to work.
Looks sane to me, nice work.
> I could also remove kref and switch to using link_dev to keep track of > refcount and releasing stuff, but I wasn't sure if we really needed the > srcu implementation or not. So didn't remove it in this series and left > it as is.
I would just leave that alone for now, as that would be a different change here, right?
thanks,
greg k-h
| |