Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp461740pxb; Thu, 26 Aug 2021 07:08:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfEMGuBeRL/rDwSt6fkmzMbFp/O0rUTKtlNAR7Y5cMwxlLFlv2WvDbHPWZdbxARMiCkVWr X-Received: by 2002:a05:6638:521:: with SMTP id j1mr3604618jar.122.1629986910747; Thu, 26 Aug 2021 07:08:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629986910; cv=none; d=google.com; s=arc-20160816; b=qxGFIIMUubKxPaTWv5K3VukYmymdYGJptVxJnG2WAllOW7UcC40TVra9FdhpumfFor rD66GOf2HJmojhg2XjdMHM8Oanpc2geFo93jv+Pita0MRyUBcbLhE1UYxghpfmmoaAzR LzNNtI9+WkuCqXrrY9Rzfy69Uq7GE4Imi+gCe+MYz/Cy/H8zNVV1ro+SPcUj+nKQeCaV FMasduRdeHKwRy5trZ6psGyaBRc7Rd67bM5o491nBgdX9JUqGEac+CUMOG/M2VqMqbQU YGBmmqzo1iEC6OrlgE2BQ7tvEBcKFcoTmz9n+xxFfyjl+LdJ+UkqKUUvoK0APiZttjgT d5ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=1lkhnZcq8a3f/mZvYT8ADDYGGbDHDb3e5vZseBA5Wi8=; b=AaZIua+RdLnBNL5VxyTTttZcSMcpPmjF5eZ8N79oSnyo2ExN7KtFyepnCSJb2CqBpY fKyYqlxolKDcYjjcxX6PMf5Fs2rFIcXQC/LL95oW5a8+fP5UdyLD9CV6Er/xZm77ZouE T5BIiUZEGRAn3sNeWxrt1l5lpt+YS7cCgbNtAm207C5gqbsCNSsB97dWoHqGB0QpwJ5y +4kdChoA6WetMxidvEXxYTJPXtT3xdShhln21F4RiyntdH7rzQSlSA7XNr59jPsvHuLg 6lAKenQJqwAXhHy8XEKzOSwcq1j+wEUIqiNT1QDa8HiR/ybmRR4Tb+6dWaLEDHWUStTf 6HFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id s20si2878102ioa.93.2021.08.26.07.08.13; Thu, 26 Aug 2021 07:08:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S242855AbhHZOHF (ORCPT + 99 others); Thu, 26 Aug 2021 10:07:05 -0400 Received: from mga05.intel.com ([192.55.52.43]:33804 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242859AbhHZOHA (ORCPT ); Thu, 26 Aug 2021 10:07:00 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10087"; a="303326971" X-IronPort-AV: E=Sophos;i="5.84,353,1620716400"; d="scan'208";a="303326971" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2021 07:06:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,353,1620716400"; d="scan'208";a="598493202" Received: from kuha.fi.intel.com ([10.237.72.162]) by fmsmga001.fm.intel.com with SMTP; 26 Aug 2021 07:06:09 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Thu, 26 Aug 2021 17:06:08 +0300 Date: Thu, 26 Aug 2021 17:06:08 +0300 From: Heikki Krogerus To: "Deucher, Alexander" Cc: Felipe Balbi , "Shah, Nehal-bakulchandra" , "gregkh@linuxfoundation.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Liu, Kun" Subject: Re: [RESEND PATCH 2/2] usb: dwc3: pci add property to allow user space role switch Message-ID: References: <20210824192337.3100288-1-Nehal-Bakulchandra.shah@amd.com> <87ilzu5ap0.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexander, On Wed, Aug 25, 2021 at 01:50:48PM +0000, Deucher, Alexander wrote: > I'm not a USB expert, but I think the idea was to pop up a message asking the > user what role they wanted when they plugged in USB cable? Then based on > their input, the role could be changed. What exactly is the ACPI/EC interrupt in this case? Note, that simply selecting one role will only work if the partner device happens to be in the opposite role at the same time (actually, even that may not be enough). So for example by selecting host role will only work if the partner happens to be in device role. If the parter is also in host role, nothing happens, or both ends just fail to enumerate each other. So you always have to negotiate the role with the partner one way or the other. Now we need to understand how that negotiation is handled (or is expected to be handled) on this platform. Which type of connector are we talking about here? Is it USB Type-C, or is it something else? thanks, -- heikki