linux-kernel - Re: [PATCH] usb: typec: pd: Add symlink to linked device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y3sls9+NcQrdjb9y@chromium.org>
Date:   Mon, 21 Nov 2022 07:16:03 +0000
From:   Prashant Malani <pmalani@...omium.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Benson Leung <bleung@...omium.org>
Subject: Re: [PATCH] usb: typec: pd: Add symlink to linked device

Hi Greg,

Thanks for reviewing the patch.

On Nov 21 07:35, Greg Kroah-Hartman wrote:
> On Mon, Nov 21, 2022 at 06:20:39AM +0000, Prashant Malani wrote:
> >  
> > +What:		/sys/class/usb_power_delivery/.../device
> > +Date:		November 2022
> > +Contact:	Prashant Malani <pmalani@...omium.org>
> > +Description:
> > +		Symbolic link to the directory of the device to which the USB PD object is linked.
> 
> Line is way too long.

Sorry about that. I'll try to make it more concise in the next version.

> 
> But wait, a "device" has a specific meaning in a sysfs file, and that is
> not what is happening here.
> 
> Please don't make fake "device" symlinks when these are not really using
> a device here.  Either fix it up to properly use the device structures
> in the code, or call this something else.

Got it, sorry about using that specific term. How about:
1. "linked_device"
2. "base_device" ?

I prefer 1.) but happy to use the other, or any other suggestion.

> 
> What in userspace wants to see this symlink?

ChromeOS's userspace Type-C daemon. It listens for Type-C partner uevents, but the PD objects
can be created later (and destroyed and then recreated again, for PD chargers which dynamically
change their source caps), and this helps determine which partner does those events apply to.

Thanks,

-Prashant