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 *str
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;
> > > +
> > >
> 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:
> Hi Greg,
>
> On Mon, Nov 14, 2016 a
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];
>
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. T
> 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 is
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.
Regar
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 Presenc
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*-par
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
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
> notific
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;
> >>> +
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 assumi
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 wr
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 purpose
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 th
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(&typec_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(&typec_class);
> > >
> > > You forgot to clean up your idr :(
> >
> > Sorry, what id
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
b
On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote:
> > > +static void __exit typec_exit(void)
> > > +{
> > > + class_unregister(&typec_class);
> >
> > You forgot to clean up your idr :(
>
> Sorry, what idr? The port ids get removed in typec_release().
You have a static idr structur
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 con
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 s
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 Alt
23 matches
Mail list logo