[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201022124248.GQ1667571@kuha.fi.intel.com>
Date: Thu, 22 Oct 2020 15:42:48 +0300
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Prashant Malani <pmalani@...omium.org>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:USB NETWORKING DRIVERS" <linux-usb@...r.kernel.org>,
Benson Leung <bleung@...omium.org>
Subject: Re: [PATCH v2] usb: typec: Expose Product Type VDOs via sysfs
On Thu, Oct 22, 2020 at 12:25:07AM -0700, Prashant Malani wrote:
> Hi Greg,
>
> On Thu, Oct 22, 2020 at 12:17 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > > > > +What: /sys/class/typec/<port>-partner/identity/product_type_vdo
> > > > > +Date: October 2020
> > > > > +Contact: Prashant Malani <pmalani@...omium.org>
> > > > > +Description:
> > > > > + Product Type VDOs part of Discover Identity command result. 3 values
> > > > > + are displayed (for the 3 possible Product Type VDOs), one per line.
> > > >
> > > > sysfs is "one value per file", not "one value per line". This is not
> > > > ok.
> > >
> > > I see. Would listing these out as three separate vdos (i.e vdo0, vdo1,
> > > vdo2) be better?
> >
> > Given that your current implementation is not acceptable, something has
> > to change :)
>
> Got it. I'd like to see if Heikki has any suggestions on naming these
> entries better.
Why not have product type specific attribute files?
So if the partner is UFP, then we expose ufp1 and ufp2 files that
return the UFP1 and UFP2 VDO values and hide the other files:
% ls /sys/class/typec/port0-partner/identity/
id_header cert_stat product ufp1 ufp2
If the partner is DFP, then you expose the dfp file and hide
everything else:
% ls /sys/class/typec/port0-partner/identity/
id_header cert_stat product dfp
And so on.
thanks,
--
heikki
Powered by blists - more mailing lists