linux-kernel - Re: [PATCH v4 06/18] drm/bridge: aux-hpd: Support USB Type-C DP altmodes via DRM lane assignment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZthaCQel2aHhyIu4@smile.fi.intel.com>
Date: Wed, 4 Sep 2024 16:00:57 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Stephen Boyd <swboyd@...omium.org>
Cc: chrome-platform@...ts.linux.dev, linux-kernel@...r.kernel.org,
	patches@...ts.linux.dev, devicetree@...r.kernel.org,
	Douglas Anderson <dianders@...omium.org>,
	Pin-yen Lin <treapking@...omium.org>,
	Andrzej Hajda <andrzej.hajda@...el.com>,
	Benson Leung <bleung@...omium.org>,
	Conor Dooley <conor+dt@...nel.org>, Daniel Vetter <daniel@...ll.ch>,
	David Airlie <airlied@...il.com>,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	dri-devel@...ts.freedesktop.org,
	Guenter Roeck <groeck@...omium.org>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Jonas Karlman <jonas@...boo.se>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
	Lee Jones <lee@...nel.org>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Prashant Malani <pmalani@...omium.org>,
	Robert Foss <rfoss@...nel.org>, Rob Herring <robh+dt@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	Tzung-Bi Shih <tzungbi@...nel.org>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Daniel Scally <djrscally@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Ivan Orlov <ivan.orlov0322@...il.com>, linux-acpi@...r.kernel.org,
	linux-usb@...r.kernel.org,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Vinod Koul <vkoul@...nel.org>
Subject: Re: [PATCH v4 06/18] drm/bridge: aux-hpd: Support USB Type-C DP
 altmodes via DRM lane assignment

On Tue, Sep 03, 2024 at 06:20:14PM -0400, Stephen Boyd wrote:
> Quoting Andy Shevchenko (2024-09-02 04:35:46)
> > On Sat, Aug 31, 2024 at 09:06:44PM -0700, Stephen Boyd wrote:

> > > Extend the aux-hpd bridge driver to support assigning DP lanes to USB
> > > type-c pins based on typec mux state entry. Existing users of this
> > > driver only need the HPD signaling support, so leave that in place and
> > > wrap the code with a variant that supports more features of USB type-c
> >
> > Isn't the proper spelling "USB Type-C"?
> 
> Perhaps in a title?

I am talking about the commit message :-)

> > > DP altmode, i.e. pin configurations. Prefix that code with
> > > 'drm_dp_typec_bridge' to differentiate it from the existing
> > > 'drm_aux_hpd_bridge' code.
> > >
> > > Parse the struct typec_mux_state members to determine if DP altmode has
> > > been entered and if HPD is asserted or not. Signal HPD to the drm bridge
> > > chain when HPD is asserted. Similarly, parse the pin assignment and map
> > > the DP lanes to the usb-c output lanes, taking into account any lane
> > > remapping from the data-lanes endpoint property. Pass that lane mapping
> > > to the previous drm_bridge in the bridge chain during the atomic check
> > > phase.

...

> > > +     adev->dev.of_node = of_node_get(parent->of_node);
> >
> > device_set_node() ?
> 
> Or device_set_of_node_from_dev()?

This is quite unclear to me. The second one bumps the reference count IIRC
for no reason (in usual cases). Also only few drivers use that, I would hear
what OF people can tell about this API and its usage scope.

...

> > > +static int dp_lane_to_typec_lane(enum dp_lane lane)
> > > +{
> > > +     switch (lane) {
> > > +     case DP_ML0:
> > > +             return USB_SSTX2;
> > > +     case DP_ML1:
> > > +             return USB_SSRX2;
> > > +     case DP_ML2:
> > > +             return USB_SSTX1;
> > > +     case DP_ML3:
> > > +             return USB_SSRX1;
> > > +     }
> >
> > > +     return -EINVAL;
> >
> > Hmm... This can be simply made as default case.
> 
> And then the enum is always "covered" and the compiler doesn't complain
> about missing cases (I don't think we have -Wswitch-enum)? Seems worse.

Hmm... You mean if I remove one of the above cases I will get the warning?

> > > +}

-- 
With Best Regards,
Andy Shevchenko