Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 21 Nov 2022 08:36:55 +0100
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Prashant Malani <pmalani@chromium.org>
Cc:     linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Benson Leung <bleung@chromium.org>
Subject: Re: [PATCH] usb: typec: pd: Add symlink to linked device
Message-ID: <Y3sql/3xgXvre6rT@kroah.com>
References: <20221121062106.2569297-1-pmalani@chromium.org>
 <Y3scND+8DVe8SGeD@kroah.com>
 <Y3sls9+NcQrdjb9y@chromium.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y3sls9+NcQrdjb9y@chromium.org>
Precedence: bulk

On Mon, Nov 21, 2022 at 07:16:03AM +0000, Prashant Malani wrote:
> 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@chromium.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.

That's not the issue, the problem is that it needs to be properly
line-wrapped.

> > 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" ?

Why either?  What exactly is this "device" that you are trying to link
to?  And why not just use the real device symlink instead?

> 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.

Then set up the proper device symlink like the driver model supports,
then you don't have to create a new one, and you don't have to add the
documentation entry as it's implied.

thanks,

greg k-h