From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C53492EE5F6 for ; Tue, 12 Aug 2025 11:41:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754998867; cv=none; b=Wcr6aAJCT/sxPlDsL30y48ism+Ls8FdAARV69iQ7mqKd0P7mrNkz0S1BPGEVb5Mz21qVP6ymGgR1jbCsqTUkcQzQna4/4BM0njevO9fXkTJRzoeDdEaye/o+MOmQT4oQOUOInAd8ZpdPH5Z7KKlsEnxaqNqNIAuguLwBolDNCOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754998867; c=relaxed/simple; bh=8cHX/Sr/SKiYCY8L0anyseQRntP0r49oVVkND9FPyS4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uBAc3vCnlxdyV65vBFgsti0ZjCe0cE8ypVeR2XCsWvtc9OAIJHU0YJh7+2zZCCl7NfyqAoZbH7ed5ohBaahKaWyi+SUW0+ssWtOLbAL/syp+iBALOVOqv4EnTuhZJXccdR9xDOORAmZqYJXuINe8pahcK3/glEmQQkRrHv9Ovzs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nIRVjaCw; arc=none smtp.client-ip=198.175.65.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nIRVjaCw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1754998865; x=1786534865; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=8cHX/Sr/SKiYCY8L0anyseQRntP0r49oVVkND9FPyS4=; b=nIRVjaCw0RfCV71PokxEHDGH6D4JrK5M4RzdRTSHHIxpkyHq9dG3ezlV M0ucRlFu/W0pXglqjXrd/Fu7wWMSFEwv4JfAV6bTOBRujIM0JqYkPIKbV bV25YzbgWvSFCetG1fPPyzvD02IAFZ7ppLY0r6g26rqNTyNvWDOBxwns0 oiTuOP5n1bUS114FD9IBoK9eUTg9NXrFyLML6BPJ+o0sSH897oz6kje7B w9qv6pFBKMwBnuc5Iu4GjT4XCjPP0bwemRItl1bMW9LSjwgQNJFQBGuzO HUJrSo7G90FMq2jZLB+qWubkcC43cwXy0BkVIZxyTSdVsylpdM1Ht0JGU g==; X-CSE-ConnectionGUID: OMfodcBFTQy57OXyDbIuiQ== X-CSE-MsgGUID: L2crtVi+RLWf7iTni0/DzQ== X-IronPort-AV: E=McAfee;i="6800,10657,11518"; a="57417923" X-IronPort-AV: E=Sophos;i="6.17,284,1747724400"; d="scan'208";a="57417923" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Aug 2025 04:41:05 -0700 X-CSE-ConnectionGUID: 088z0gfNSJymyLmSnlB/lw== X-CSE-MsgGUID: y+O8W3nPTQynoLrDy6xRfw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,284,1747724400"; d="scan'208";a="170377978" Received: from kuha.fi.intel.com ([10.237.72.152]) by orviesa003.jf.intel.com with SMTP; 12 Aug 2025 04:41:01 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Tue, 12 Aug 2025 14:40:59 +0300 Date: Tue, 12 Aug 2025 14:40:59 +0300 From: Heikki Krogerus To: Abhishek Pandit-Subedi Cc: Andrei Kuchynski , Benson Leung , Jameson Thies , Tzung-Bi Shih , linux-usb@vger.kernel.org, chrome-platform@lists.linux.dev, Guenter Roeck , Greg Kroah-Hartman , Dmitry Baryshkov , "Christian A. Ehrhardt" , Venkat Jayaraman , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 04/10] usb: typec: Expose mode priorities via sysfs Message-ID: References: <20250804090340.3062182-1-akuchynski@chromium.org> <20250804090340.3062182-5-akuchynski@chromium.org> Precedence: bulk X-Mailing-List: chrome-platform@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Abhishek, On Mon, Aug 11, 2025 at 11:22:38AM -0700, Abhishek Pandit-Subedi wrote: > On Mon, Aug 11, 2025 at 7:25 AM Heikki Krogerus > wrote: > > > > Hi Andrei, > > > > On Mon, Aug 04, 2025 at 09:03:33AM +0000, Andrei Kuchynski wrote: > > > This patch introduces new sysfs attributes to allow users to configure > > > and view Type-C mode priorities. > > > > > > `priority`, `usb4_priority` attributes allow users to assign a numeric > > > priority to DisplayPort alt-mode, Thunderbolt alt-mode, and USB4 mode. > > > > > > `mode_priorities` - read-only attribute that displays an ordered list > > > of all modes based on their configured priorities. > > > > > > Signed-off-by: Andrei Kuchynski > > > --- > > > Documentation/ABI/testing/sysfs-class-typec | 33 +++++ > > > drivers/usb/typec/Makefile | 2 +- > > > drivers/usb/typec/class.c | 103 +++++++++++++++- > > > drivers/usb/typec/class.h | 1 + > > > drivers/usb/typec/mode_selection.c | 130 ++++++++++++++++++++ > > > drivers/usb/typec/mode_selection.h | 23 ++++ > > > include/linux/usb/typec_altmode.h | 7 ++ > > > 7 files changed, 295 insertions(+), 4 deletions(-) > > > create mode 100644 drivers/usb/typec/mode_selection.c > > > create mode 100644 drivers/usb/typec/mode_selection.h > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-typec b/Documentation/ABI/testing/sysfs-class-typec > > > index 38e101c17a00..575dd94f33ab 100644 > > > --- a/Documentation/ABI/testing/sysfs-class-typec > > > +++ b/Documentation/ABI/testing/sysfs-class-typec > > > @@ -162,6 +162,39 @@ Description: Lists the supported USB Modes. The default USB mode that is used > > > - usb3 (USB 3.2) > > > - usb4 (USB4) > > > > > > + What: /sys/class/typec///priority > > > +Date: July 2025 > > > +Contact: Andrei Kuchynski > > > +Description: > > > + Displays and allows setting the priority for a specific alt-mode. > > > + When read, it shows the current integer priority value. Lower numerical > > > + values indicate higher priority (0 is the highest priority). > > > + If the new value is already in use by another mode, the priority of the > > > + conflicting mode and any subsequent modes will be incremented until they > > > + are all unique. > > > + This attribute is visible only if the kernel supports mode selection. > > > + > > > + What: /sys/class/typec//usb4_priority > > > +Date: July 2025 > > > +Contact: Andrei Kuchynski > > > +Description: > > > + Displays and allows setting the priority for USB4 mode. Its behavior and > > > + priority numbering scheme are identical to the general alt-mode > > > + "priority" attributes. > > > > I'm not sure those above two file make any sense. > > > > > +What: /sys/class/typec//mode_priorities > > > +Date: July 2025 > > > +Contact: Andrei Kuchynski > > > +Description: This read-only file lists the modes supported by the port, > > > + ordered by their activation priority. It reflects the preferred sequence > > > + the kernel will attempt to activate modes (DisplayPort alt-mode, > > > + Thunderbolt alt-mode, USB4 mode). > > > + This attribute is visible only if the kernel supports mode selection. > > > + > > > + Example values: > > > + - "USB4 Thunderbolt3 DisplayPort" > > > + - "DisplayPort": the port only supports Displayport alt-mode > > > > Why not just use this one instead so that you write the highest > > priority mode to it? > > Feedback from Greg on > https://lore.kernel.org/linux-usb/2025070159-judgingly-baggage-042a@gregkh/: > > "quote": > Multiple value sysfs files are generally frowned apon. sysfs files that > also have to be manually parsed in the kernel are also frowned apon. > Are you _SURE_ there is no other way that you could possibly do this? > > The reason we originally suggested a single "mode priorities" was > because we weren't sure what to do about USB4. Otherwise, it makes > sense to push a priority field to each alt_mode sysfs group and keep > it internally ordered. This is where I really wish we just treated > USB4 as an alternate mode :) I'm probable forgetting something, but I'm pretty sure I already told you guys that I agree, it should be an alt mode. So why not just register a special alt mode for it? Sorry if I missed something. > As such, our current API recommendation looks like the following: > > * On each port, we lay out priorities for all supported alternate modes + USB4. This first part I understand. > * We expose a file to trigger the mode selection task. Reading from it > gives you the current status of mode selection (single value). > * Detailed results from mode entry are pushed to the mode sysfs group > (via entry_results). Converting these to UEVENT is fine but a more > persistent value in debugfs would be useful for debugging. This second part I would really like to handle separately, after we have a solution for the first part. thanks, -- heikki