Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3614618ybl; Mon, 12 Aug 2019 03:33:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqyhJpZLAtjbcSA267AgF0P6yiybCL4OdtGGDQUyglzwWLv2N8g1T7CRpvjl2i5Mbcmx3Lee X-Received: by 2002:a17:90a:c68c:: with SMTP id n12mr22824063pjt.33.1565606005554; Mon, 12 Aug 2019 03:33:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565606005; cv=none; d=google.com; s=arc-20160816; b=sCULTB4HSWG4HPVfbDcwmDbnIKTmLLkdyRBZUfab27LHhVvC6CnB5zsoJhMMKtEKmj 8ksNVAOLvEzxkQBgYfSLmqBjpdNUduR+/BxyMIX5agxcFwaEQ3oRcGTNsNLocUwXPoh4 TLgYR9HWsf75GUWbDi1b/OhJna1WeiA69K5HToGymHbr/g5snUG5Kf7LfZNTNGibQO/D tDvhN15YfxNjvjrtITEcoHr9uJ+/sHHwuRrYLvLHUYcqvfEuu5kCGtkVgE9p77CDzIYK TjSFAYhOfgiKfE7rS9MRx6k3yzXI7rORUkyMrMzVHcf8ShdEiAYZ92dHrLD9w9BZx+df QcgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=gw+sXvc1XgmM0vsx+5WjJpw7smKxTHJ4YgxQTrNQhcU=; b=oR4TWMv6YphNYtD0z7ZH2++WpWZVNjxU+wKLft94ofC0KEFIJ2sLzIAT6wiaa3ROqX SldoX8QEsAsBsNUjx/Ymw/d21qk0KyJWgFk9SFD22WBn/j3iUIKa2XmQ3Hyuwfot6RWY HBhJ9tWrvvjOfs8D8A0J9NihtbNET9pFI7kAkZKDtp/kimxsMcvuVk6WHRp8rTtEg9di /W2sxpV12zyq1CfdqAs6w4UedtDraJVm9iWT0hZ64SJdtvXdUS0D8PlNhDkmC9wxRUma Q+kr+Xh9pxJBjBHT2u/1CRIqaY7bniH3cIy03u5EfQCxYcawgGW2mbncXdaxbR9/4mr4 9rwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y71si59077865pgd.271.2019.08.12.03.33.09; Mon, 12 Aug 2019 03:33:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727822AbfHLKc3 (ORCPT + 99 others); Mon, 12 Aug 2019 06:32:29 -0400 Received: from mga18.intel.com ([134.134.136.126]:29383 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727744AbfHLKc3 (ORCPT ); Mon, 12 Aug 2019 06:32:29 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Aug 2019 03:31:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,377,1559545200"; d="scan'208";a="193928694" Received: from kuha.fi.intel.com ([10.237.72.189]) by fmsmga001.fm.intel.com with SMTP; 12 Aug 2019 03:31:48 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Mon, 12 Aug 2019 13:31:47 +0300 Date: Mon, 12 Aug 2019 13:31:47 +0300 From: Heikki Krogerus To: Pawel Laszczak Cc: Roger Quadros , "felipe.balbi@linux.intel.com" , "gregkh@linuxfoundation.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "jbergsagel@ti.com" , "nsekhar@ti.com" , "nm@ti.com" , Suresh Punnoose , Jayshri Dajiram Pawar , Rahul Kumar , Anil Joy Varughese Subject: Re: [PATCH v10 5/6] usb:cdns3 Add Cadence USB3 DRD Driver Message-ID: <20190812103147.GA4691@kuha.fi.intel.com> References: <1563733939-21214-1-git-send-email-pawell@cadence.com> <1563733939-21214-6-git-send-email-pawell@cadence.com> <88742d5b-ee10-cf4e-6724-58e7bdd19cb9@ti.com> <1e557bcf-2d50-f600-0e81-1f9fba5499a1@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > >>>> + real_role = cdsn3_real_role_switch_get(cdns->dev); > >>>> + > >>>> + current_role = role; > >>>> + dev_dbg(cdns->dev, "Switching role"); > >>>> + > >>>> + ret = cdns3_role_start(cdns, real_role); > >>>> + if (ret) { > >>>> + /* Back to current role */ > >>>> + dev_err(cdns->dev, "set %d has failed, back to %d\n", > >>>> + role, current_role); > >>>> + ret = cdns3_role_start(cdns, current_role); > >>>> + if (ret) > >>>> + dev_err(cdns->dev, "back to %d failed too\n", > >>>> + current_role); > >>>> + } > >>>> +exit: > >>>> + pm_runtime_put_sync(cdns->dev); > >>>> + return ret; > >>>> +} > >>>> + > >>>> +static const struct usb_role_switch_desc cdns3_switch_desc = { > >>>> + .set = cdns3_role_switch_set, > >>>> + .get = cdsn3_real_role_switch_get, > >>>> + .allow_userspace_control = true, > >>> > >>> how does user initiated cdns3_role_switch_set() via sysfs co-exist with role > >>> changes done by hardware events. e.g. ID/VBUS? > >>> > >> > >> Do you expect any issues whit this, have you seen any problem with this > >> on your platform ? > >> > >> I assume that it should work in this way: > >> 1. user change role by sysfs > >> 2. Driver change the role according with user request. > >> 3. If we receive correct ID/VBUS then role should not be changed > >> because new role is the same as current set in point 2. > >> > > > >I have not tested this series yet. > >My understanding is that if user sets role to "host" or "device" then it should > >remain in that role irrespective of ID/VBUS. Once user sets it to "none" then > >port should set role based on ID/VBUS. > > According with your understanding it works the same way as by debugfs. > Now I have no doubts to remove debugfs.c file :) Hold on! The role "none" means that the connector should not be connected to either the host nor device. The sysfs file we expose from the class for the role switches is primarily meant for supporting proprietary protocols that require us to basically override the connector USB data role. The default role should always be selected in the drivers. With USB Type-C connectors and alternate modes, the "none" role is used for example when the connector is put into "USB Safe State". In case you guys are not familiar with USB Safe State, then it is a state (defined in USB PD specifications) for the connector where the data lines on the connector should not be physically connected to anything. The connector needs to be put into safe state always when entering or exiting an alternate mode, before the final mode (USB or alternate) is actually being set for the connector. thanks, -- heikki