From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933037AbcKPOa2 (ORCPT <rfc822;w@1wt.eu>);
        Wed, 16 Nov 2016 09:30:28 -0500
Received: from mail-yw0-f178.google.com ([209.85.161.178]:33637 "EHLO
        mail-yw0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753187AbcKPOaZ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 16 Nov 2016 09:30:25 -0500
MIME-Version: 1.0
In-Reply-To: <1479295658.2000.9.camel@suse.com>
References: <20160919111657.22127-1-heikki.krogerus@linux.intel.com>
 <20160919111657.22127-2-heikki.krogerus@linux.intel.com> <20161114095148.GA10306@kroah.com>
 <20161114123235.GD22706@kuha.fi.intel.com> <20161114204650.GB17677@roeck-us.net>
 <20161115070754.GA26240@kroah.com> <74c10d95-47b6-cc5d-eda0-056439db4ec7@roeck-us.net>
 <CAPTae5JX7ts3oxGVMO_jRwEWpA_aYFws9p9JGZ99xn0kDD+xXQ@mail.gmail.com>
 <20161116093035.GA30235@kuha.fi.intel.com> <20161116094949.GB3067@kroah.com>
 <20161116110910.GB30235@kuha.fi.intel.com> <1479295658.2000.9.camel@suse.com>
From: Badhri Jagan Sridharan <badhri@google.com>
Date: Wed, 16 Nov 2016 06:30:23 -0800
Message-ID: <CAPTae5KsUQow-Doo+Wc=Efc3cZpzUzZfszLOMkAKiF0PXtPiSQ@mail.gmail.com>
Subject: Re: [PATHCv10 1/2] usb: USB Type-C connector class
To: Oliver Neukum <oneukum@suse.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Guenter Roeck <linux@roeck-us.net>, Bin Gao <bin.gao@linux.intel.com>,
        Felipe Balbi <felipe.balbi@linux.intel.com>,
        LKML <linux-kernel@vger.kernel.org>, USB <linux-usb@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> 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 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?

Yes Heikki.. That's OK for me as well.
Just to get my understanding right. You are planning to add
KOBJ_CHANGE uevents when current_power_role or
current_data_role changes and KOBJ_ADD when new port-partner
or the cable is attached. Is that right ?

Thanks,
Badhri.

On Wed, Nov 16, 2016 at 3:27 AM, Oliver Neukum <oneukum@suse.com> wrote:
> 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.
>
>         Regards
>                 Oliver
>
>