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

On Wed, Nov 16, 2016 at 04:31:07PM +0100, Greg KH wrote: > On Wed, Nov 16, 2016 at 05:20:24PM +0200, Heikki Krogerus wrote: > > Hi Greg, > > > > On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote: > > > > +static int sysfs_strmatch(const char * const *array, size_t n, const > > > > char

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

On Wed, Nov 16, 2016 at 05:20:24PM +0200, Heikki Krogerus wrote: > Hi Greg, > > On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote: > > > +static int sysfs_strmatch(const char * const *array, size_t n, const > > > char *str) > > > +{ > > > + const char *item; > > > + int index; > > > + > >

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

> Yes, though I don't KOBJ_ADD separately with the partners and cables. > That uevent is sent when the device for them is registered, so it's > already there Makes sense. Thanks Heikki. Regards, Badhri On Wed, Nov 16, 2016 at 7:20 AM, Heikki Krogerus wrote: >

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

Hi Greg, On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote: > > +static int sysfs_strmatch(const char * const *array, size_t n, const char > > *str) > > +{ > > + const char *item; > > + int index; > > + > > + for (index = 0; index < n; index++) { > > + item = array[index];

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

On Wed, Nov 16, 2016 at 06:30:23AM -0800, Badhri Jagan Sridharan wrote: > > IMHO the uevent is cheaper. User space cannot just poll without further > > infrastructure. A task needs to run to poll. A uevent can be handled > > through established infrastructure. > > Thanks Oliver for stating this.

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

> IMHO the uevent is cheaper. User space cannot just poll without further > infrastructure. A task needs to run to poll. A uevent can be handled > through established infrastructure. Thanks Oliver for stating this. This is exactly what I was facing. > OK, I'll add KOBJ_CHANGE for those. > > So

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

On Wed, 2016-11-16 at 13:09 +0200, Heikki Krogerus wrote: > OK, I'll add KOBJ_CHANGE for those. > > So is it OK to everybody if I remove the KOBJ_CHANGE in > typec_connect()? We will see uevent KOBJ_ADD since the partner (or > cable) is added in any case. Badhri, Oliver? OK by me.

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

On Wed, Nov 16, 2016 at 10:49:49AM +0100, Greg KH wrote: > 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

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

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

On Wed, 2016-11-16 at 11:30 +0200, Heikki Krogerus wrote: > On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote: > > 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

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

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 >

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

On Mon, 2016-11-14 at 06:34 -0800, Guenter Roeck wrote: > >>> +int typec_connect(struct typec_port *port, struct > typec_connection *con) > >>> +{ > >>> + int ret; > >>> + > >>> + if (!con->partner && !con->cable) > >>> + return -EINVAL; > >>> + > >>> + port->connected = 1; > >>> +

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

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

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

On 11/14/2016 11:07 PM, Greg KH wrote: On Mon, Nov 14, 2016 at 12:46:50PM -0800, Guenter Roeck wrote: On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote: Hi Greg, On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote: On Mon, Sep 19, 2016 at 02:16:56PM +0300, Heikki Krogerus

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

On Mon, Nov 14, 2016 at 12:46:50PM -0800, Guenter Roeck wrote: > On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote: > > Hi Greg, > > > > On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote: > > > On Mon, Sep 19, 2016 at 02:16:56PM +0300, Heikki Krogerus wrote: > > > > The

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

On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote: > Hi Greg, > > On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote: > > On Mon, Sep 19, 2016 at 02:16:56PM +0300, Heikki Krogerus wrote: > > > The purpose of USB Type-C connector class is to provide > > > unified interface for

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

On Mon, Nov 14, 2016 at 04:39:10PM +0200, Heikki Krogerus wrote: > On Mon, Nov 14, 2016 at 03:11:23PM +0100, Greg KH wrote: > > On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote: > > > > > +static void __exit typec_exit(void) > > > > > +{ > > > > > + class_unregister(_class); > >

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

On Mon, Nov 14, 2016 at 03:11:23PM +0100, Greg KH wrote: > On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote: > > > > +static void __exit typec_exit(void) > > > > +{ > > > > + class_unregister(_class); > > > > > > You forgot to clean up your idr :( > > > > Sorry, what idr?

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

On 11/14/2016 04:32 AM, Heikki Krogerus wrote: Hi Greg, On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote: On Mon, Sep 19, 2016 at 02:16:56PM +0300, Heikki Krogerus wrote: The purpose of USB Type-C connector class is to provide unified interface for the user space to get the status and

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

On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote: > > > +static void __exit typec_exit(void) > > > +{ > > > + class_unregister(_class); > > > > You forgot to clean up your idr :( > > Sorry, what idr? The port ids get removed in typec_release(). You have a static idr structure in

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

Hi Greg, On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote: > On Mon, Sep 19, 2016 at 02:16:56PM +0300, Heikki Krogerus wrote: > > The purpose of USB Type-C connector class is to provide > > unified interface for the user space to get the status and > > basic information about USB Type-C

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

On Mon, Sep 19, 2016 at 02:16:56PM +0300, Heikki Krogerus wrote: > The purpose of USB Type-C connector class is to provide > unified interface for the user space to get the status and > basic information about USB Type-C connectors on a system, > control over data role swapping, and when the port

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

The purpose of USB Type-C connector class is to provide unified interface for the user space to get the status and basic information about USB Type-C connectors on a system, control over data role swapping, and when the port supports USB Power Delivery, also control over power role swapping and