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]
Message-ID: <20161114204650.GB17677@roeck-us.net>
Date:   Mon, 14 Nov 2016 12:46:50 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Oliver Neukum <oneukum@...e.com>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Bin Gao <bin.gao@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: 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 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 Alternate Modes.
> > > 
> > > Reviewed-by: Guenter Roeck <linux@...ck-us.net>
> > > Tested-by: Guenter Roeck <linux@...ck-us.net>
> > > Signed-off-by: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> > > ---
> > >  Documentation/ABI/testing/sysfs-class-typec |  218 ++++++
> > >  Documentation/usb/typec.txt                 |  103 +++
> > >  MAINTAINERS                                 |    9 +
> > >  drivers/usb/Kconfig                         |    2 +
> > >  drivers/usb/Makefile                        |    2 +
> > >  drivers/usb/typec/Kconfig                   |    7 +
> > >  drivers/usb/typec/Makefile                  |    1 +
> > >  drivers/usb/typec/typec.c                   | 1075 +++++++++++++++++++++++++++
> > >  include/linux/usb/typec.h                   |  252 +++++++
> > >  9 files changed, 1669 insertions(+)
> > >  create mode 100644 Documentation/ABI/testing/sysfs-class-typec
> > >  create mode 100644 Documentation/usb/typec.txt
> > >  create mode 100644 drivers/usb/typec/Kconfig
> > >  create mode 100644 drivers/usb/typec/Makefile
> > >  create mode 100644 drivers/usb/typec/typec.c
> > >  create mode 100644 include/linux/usb/typec.h
> > 
[ ... ]

> > > +
> > > +int typec_connect(struct typec_port *port, struct typec_connection *con)
> > > +{
> > > +	int ret;
> > > +
> > > +	if (!con->partner && !con->cable)
> > > +		return -EINVAL;
> > > +
> > > +	port->connected = 1;
> > > +	port->data_role = con->data_role;
> > > +	port->pwr_role = con->pwr_role;
> > > +	port->vconn_role = con->vconn_role;
> > > +	port->pwr_opmode = con->pwr_opmode;
> > > +
> > > +	kobject_uevent(&port->dev.kobj, KOBJ_CHANGE);
> > 
> > This worries me.  Who is listening for it?  What will you do with it?
> > Shouldn't you just poll on an attribute file instead?
> 
> Oliver! Did you need this or can we remove it?
> 
> I remember I removed the "connected" attribute because you did not see
> any use for it at one point. I don't remember the reason exactly why?
> 

The Android team tells me that they are currently using the udev events
to track port role changes, and to detect presence of port partner.

Also, there are plans to track changes on usbc*cable to differentiate
between cable attach vs. device being attached on the remote end. 

What is the problem with using kobject_uevent() and thus presumably
udev events ?

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ