Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753928AbcKPOsJ (ORCPT <rfc822;w@1wt.eu>);
        Wed, 16 Nov 2016 09:48:09 -0500
Received: from mga07.intel.com ([134.134.136.100]:42414 "EHLO mga07.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752375AbcKPOsH (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 16 Nov 2016 09:48:07 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.31,500,1473145200"; 
   d="scan'208";a="5058306"
Date: Wed, 16 Nov 2016 16:43:48 +0200
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Badhri Jagan Sridharan <badhri@google.com>
Cc: Oliver Neukum <oneukum@suse.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>
Subject: Re: [PATHCv10 1/2] usb: USB Type-C connector class
Message-ID: <20161116144348.GC30235@kuha.fi.intel.com>
References: <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>
 <CAPTae5KsUQow-Doo+Wc=Efc3cZpzUzZfszLOMkAKiF0PXtPiSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPTae5KsUQow-Doo+Wc=Efc3cZpzUzZfszLOMkAKiF0PXtPiSQ@mail.gmail.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 994
Lines: 28

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

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.


Br,

-- 
heikki