From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Prashant Malani <pmalani@chromium.org>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
gregkh@linuxfoundation.org, enric.balletbo@collabora.com
Subject: Re: [PATCH v3 03/11] usb: typec: Add plug num_altmodes sysfs attr
Date: Wed, 18 Nov 2020 14:04:08 +0200 [thread overview]
Message-ID: <20201118120408.GL3437448@kuha.fi.intel.com> (raw)
In-Reply-To: <20201117174016.GA1819103@google.com>
On Tue, Nov 17, 2020 at 09:40:16AM -0800, Prashant Malani wrote:
> Hi Heikki,
>
> On Tue, Nov 17, 2020 at 02:41:43PM +0200, Heikki Krogerus wrote:
> > On Mon, Nov 16, 2020 at 12:11:42PM -0800, Prashant Malani wrote:
> > > Add a field to the typec_plug struct to record the number of available
> > > altmodes as well as the corresponding sysfs attribute to expose this to
> > > userspace.
> > >
> > > This allows userspace to determine whether there are any
> > > remaining alternate modes left to be registered by the kernel driver. It
> > > can begin executing any policy state machine after all available
> > > alternate modes have been registered with the connector class framework.
> > >
> > > This value is set to "-1" initially, signifying that a valid number of
> > > alternate modes haven't been set for the plug. The sysfs file remains
> > > hidden as long as the attribute value is -1.
> >
> > Why couldn't we just keep it hidden for as long as the number of
> > alt modes is 0? If you already explained that, then I apologise, I've
> > forgotten.
> >
>
> No worries :)
>
> Succinctly, because 0 is a valid value for "number of altmodes
> supported".
>
> If we keep the attribute hidden for 0, then there won't
> be a way for userspace to determine that PD discovery is done and we
> don't expect any more cable plug altmodes to be registered by the kernel
> Type C port driver (it can determine this by comparing
> "number_of_altmodes" against the actual number of alt modes registered
> by the Type C port driver).
>
> If we keep "number_of_altmodes" hidden even for 0, the userspace cannot
> differentiate between "this cable doesn't support any altmodes" and
> "it does altmodes, but the PD stack hasn't completed PD Discovery
> including DiscoverIdentity yet".
>
> For reference, here is the initial patch and mini-discussion around it
> back in July for port-partner altmodes [1] (I've followed a similar
> logic here).
>
> Hope this helps the rationale a bit more.
Got it. Thanks for the explanation (again :-).
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Best regards,
>
> -Prashant
>
> [1]:
> https://lore.kernel.org/linux-usb/20200701082230.GF856968@kuha.fi.intel.com/
thanks,
--
heikki
next prev parent reply other threads:[~2020-11-18 12:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-16 20:11 [PATCH v3 00/11] chrome/platform: cros_ec_typec: Register cables, partner altmodes and plug altmodes Prashant Malani
2020-11-16 20:11 ` [PATCH v3 01/11] usb: pd: Add captive Type C cable type Prashant Malani
2020-11-16 20:11 ` [PATCH v3 02/11] usb: typec: Add number of altmodes partner attr Prashant Malani
2020-11-16 20:11 ` [PATCH v3 03/11] usb: typec: Add plug num_altmodes sysfs attr Prashant Malani
2020-11-17 12:41 ` Heikki Krogerus
2020-11-17 17:40 ` Prashant Malani
2020-11-18 12:04 ` Heikki Krogerus [this message]
2020-11-16 20:11 ` [PATCH v3 04/11] platform/chrome: cros_ec_typec: Make disc_done flag partner-only Prashant Malani
2020-11-16 20:11 ` [PATCH v3 05/11] platform/chrome: cros_ec_typec: Factor out PD identity parsing Prashant Malani
2020-11-16 20:11 ` [PATCH v3 06/11] platform/chrome: cros_ec_typec: Rename discovery struct Prashant Malani
2020-11-16 20:11 ` [PATCH v3 07/11] platform/chrome: cros_ec_typec: Register cable Prashant Malani
2020-11-16 20:11 ` [PATCH v3 08/11] platform/chrome: cros_ec_typec: Store cable plug type Prashant Malani
2020-11-16 20:11 ` [PATCH v3 09/11] platform/chrome: cros_ec_typec: Set partner num_altmodes Prashant Malani
2020-11-16 20:11 ` [PATCH v3 10/11] platform/chrome: cros_ec_typec: Register SOP' cable plug Prashant Malani
2020-11-17 12:45 ` Heikki Krogerus
2020-11-16 20:11 ` [PATCH v3 11/11] platform/chrome: cros_ec_typec: Register plug altmodes Prashant Malani
2020-11-17 13:09 ` Heikki Krogerus
2020-11-18 11:59 ` [PATCH v3 00/11] chrome/platform: cros_ec_typec: Register cables, partner altmodes and " Greg KH
2020-11-18 12:16 ` Greg KH
2020-11-19 3:56 ` Prashant Malani
2021-01-05 19:26 ` Benson Leung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201118120408.GL3437448@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=enric.balletbo@collabora.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pmalani@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).