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

[Greg KH <gregkh@linuxfoundation.org>]

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