linux-kernel - Re: [PATHCv10 1/2] usb: USB Type-C connector class

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]

Date:   Wed, 16 Nov 2016 10:49:49 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Badhri Jagan Sridharan <badhri@...gle.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Oliver Neukum <oneukum@...e.com>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Bin Gao <bin.gao@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        USB <linux-usb@...r.kernel.org>
Subject: Re: [PATHCv10 1/2] usb: USB Type-C connector class

On Wed, Nov 16, 2016 at 11:30:35AM +0200, Heikki Krogerus wrote:
> On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote:
> > Hi,
> > 
> > At present I am using the uevent in the userspace to infer
> > the Presence of a port on the remote end through the
> > appearance of usbc*-partner.
> > 
> > Userspace uses this info to decide on when to show a USB
> > notification on the screen and what should be the options
> > provided in the dialog.
> > 
> > I was assuming that this is not something that would be dropped.
> > 
> > Coding using events was relatively easier to program from userspace ..
> > 
> > Is it possible to use POLL for identifying the appearance of port partner ?
> > I did not notice sysfs_notify call in typec_connect/typec_disconnect.
> > 
> > It would also be nice to have uevent notifications when the contents
> > of current_data_role or current_power_role changes.
> > 
> > Is that too costly to have ?
> 
> Greg, could you give your opinion. In this case we do have attribute
> files that the user space can poll. Data role is the USB data role, so
> host or device, and it can change for example if the partner executes
> a swap. The same can happen with the power role.

So the same 'struct device' switches roles and attribute files are
updated that need to be re-read?  If so, yes KOBJ_CHANGE is correct, if
a struct device is added/removed for this, then no, it doesn't make
sense.

Again, document this to describe what is happening and it might be more
obvious to people and so these questions would not come up :)

thanks,

greg k-h