From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755116AbcE3OD2 (ORCPT ); Mon, 30 May 2016 10:03:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:45108 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754814AbcE3OD0 (ORCPT ); Mon, 30 May 2016 10:03:26 -0400 Message-ID: <1464616767.5364.5.camel@suse.com> Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class From: Oliver Neukum To: Heikki Krogerus Cc: Guenter Roeck , Andy Shevchenko , Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Date: Mon, 30 May 2016 15:59:27 +0200 In-Reply-To: <20160530131951.GA13055@kuha.fi.intel.com> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <20160530131951.GA13055@kuha.fi.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote: > Hi guys, > > I'm attaching a diff instead of full v3. I'm not yet adding attributes > for the reset and cable_reset. I still don't understand what is the > case where the userspace would need to be able to tricker reset? Why > isn't it enough for the userspace to be able to enter/exit modes? > Oliver! Can you please comment? 1. Because we need error handling. Devices crash. Cables will crash. We will get out of sync. You never put yourself in a place where you cannot handle an IO error. 2. Because it is in the spec. We do not second guess the spec. We implement it. > I also made a change to the partner devices so that they always have > the port as their parent. That will have an effect on the location > where the partner device is exposed in sysfs (so now always under the > port). And because of that, I would like to get an OK from you guys. It is not very important. i am fine with it. > I'm a bit concerned about the current API for adding the alternate > modes. Since we are passing the parent for an alternate mode as > struct device, it makes it possible for the caller to place it into > some wrong place. But I guess we can change the API even later. > > We also need to decide how the alternate modes a port support are > exposed to the userspace. Do we just assume the port drivers will > create them as devices under the port device itself, just like > alternate modes of partners and cable plugs are exposed under the > partners and cable plugs? That works for me, but again, the class does > not have any effect on that, and it will be just a guideline. Maybe > we can add some kind of helpers and force the port drivers to use > them. What are the alternatives? > And finally, mostly as a reminder for myself. I didn't yet add > attributes for Try.SRC/SNK. So can we make it something like > "preferred_role" like I think you proposed Guenter? The > "current_data_role" I'm dropping. That sounds good. Regards Oliver