[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMMMRMfo4n_xZPZG++OXoXJTeHuzzSBL0Bossn7+DMZMoRbqjQ@mail.gmail.com>
Date: Thu, 14 Aug 2025 10:22:07 +0200
From: Andrei Kuchynski <akuchynski@...omium.org>
To: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc: Benson Leung <bleung@...omium.org>, Jameson Thies <jthies@...gle.com>,
Tzung-Bi Shih <tzungbi@...nel.org>, linux-usb@...r.kernel.org,
chrome-platform@...ts.linux.dev, Guenter Roeck <groeck@...omium.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, "Christian A. Ehrhardt" <lk@...e.de>,
Venkat Jayaraman <venkat.jayaraman@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 04/10] usb: typec: Expose mode priorities via sysfs
On Tue, Aug 12, 2025 at 10:34 PM Abhishek Pandit-Subedi
<abhishekpandit@...omium.org> wrote:
>
>
> We interpreted this a bit differently (as just rename it):
> https://patchwork.kernel.org/project/linux-usb/patch/20250616133147.1835939-5-akuchynski@chromium.org/#26431992
>
> Thanks for the clarification here. In that case, we'll get rid of
> `usb_priorities` and `usb_results` and just add a new alternate mode
> for USB4. The vendor ids list on usb.org
> (https://www.usb.org/sites/default/files/vendor_ids072325_1.pdf) shows
> 0xff00 for USB4 so that's what we'll use. So the attributes should be:
> .active (similar to other modes), .mode = 1 (unused really), .svid =
> 0xff00, .vdo = <usb eudo> (if supported).
>
> >
> > > 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.
>
> Ack. We'll reduce the series so it's easier to review for mode_priorities first.
>
Hi Heikki, Abhishek,
Thank you for your review. I have addressed the feedback and plan to
resubmit the series.
Here are the changes I will make:
- The `typec_mode_selection_init` function and the `name` member
from the mode_selection_state struct will be removed.
- Patch 4 will be split into API and ABI parts.
- The entire series will be divided into `mode priority` (patches 1-4)
and then `mode selection`.
- The mode selection logic will be standardized to function
identically for all modes, including USB4.
Thanks again for your guidance.
Andrei
Powered by blists - more mailing lists