| 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
| ||
|
Message-ID: <CAEXTbpf8JXRYv-5nA_sNEM_D2jP6Hv_kp9o1vkrsEXjyKuOS6g@mail.gmail.com>
Date: Fri, 31 Mar 2023 15:43:32 +0900
From: Pin-yen Lin <treapking@...omium.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <neil.armstrong@...aro.org>,
Robert Foss <rfoss@...nel.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...il.com>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Daniel Scally <djrscally@...il.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Prashant Malani <pmalani@...omium.org>,
Benson Leung <bleung@...omium.org>,
Guenter Roeck <groeck@...omium.org>,
Xin Ji <xji@...logixsemi.com>, linux-kernel@...r.kernel.org,
Thomas Zimmermann <tzimmermann@...e.de>,
linux-acpi@...r.kernel.org,
Javier Martinez Canillas <javierm@...hat.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
Hsin-Yi Wang <hsinyi@...omium.org>,
Lyude Paul <lyude@...hat.com>,
Nícolas F . R . A . Prado
<nfraprado@...labora.com>, dri-devel@...ts.freedesktop.org,
Marek Vasut <marex@...x.de>,
Stephen Boyd <swboyd@...omium.org>,
chrome-platform@...ts.linux.dev, devicetree@...r.kernel.org,
Andi Shyti <andi.shyti@...ux.intel.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Douglas Anderson <dianders@...omium.org>,
Imre Deak <imre.deak@...el.com>,
Jani Nikula <jani.nikula@...el.com>,
Linus Walleij <linus.walleij@...aro.org>,
YueHaibing <yuehaibing@...wei.com>
Subject: Re: [PATCH v14 03/10] drm/display: Add Type-C switch helpers
On Fri, Mar 31, 2023 at 11:36 AM Pin-yen Lin <treapking@...omium.org> wrote:
>
> Hi Andy,
>
> Thanks for the review.
>
> On Wed, Mar 22, 2023 at 8:01 PM Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> >
> > On Wed, Mar 22, 2023 at 06:46:32PM +0800, Pin-yen Lin wrote:
> > > Add helpers to register and unregister Type-C "switches" for bridges
> > > capable of switching their output between two downstream devices.
> > >
> > > The helper registers USB Type-C mode switches when the "mode-switch"
> > > and the "reg" properties are available in Device Tree.
> >
> > ...
> >
> > > +config DRM_DISPLAY_DP_TYPEC_HELPER
> >
> > > + bool
> > > + default y
> >
> > def_bool y
> >
> > > + depends on DRM_DISPLAY_HELPER
> > > + depends on DRM_DISPLAY_HELPER=TYPEC || TYPEC=y
> > > + help
> > > + DRM display helpers for USB Type-C Displayport Alternate mode.
> >
> > Hmm... Dunno if this help is enough.
>
> Okay I'll add more detail in the next version.
> >
> > ...
> >
> > > + snprintf(name, sizeof(name), "%pfwP-%u", fwnode, port_num);
> >
> > Would it be possible to have a dup in name and would it be a problem if so?
> >
> The port_num is included in the name, so the names should be unique.
> Also, the fwnode name actually contains the reg property, so this name
> looks like "endpoint@0-1" now... I'll change the name from fwnode name
This should be "endpoint@0-0", or "endpoint@1-1@. The `port_num` value
has the same number as the `reg` property
> to dev_name() per Dmitry's comment.
> > ...
> >
> > > +/**
> > > + * drm_dp_register_typec_switches() - register Type-C switches
> > > + * @dev: Device that registers Type-C switches
> > > + * @port: Device node for the switch
> > > + * @switch_desc: A Type-C switch descriptor
> > > + * @data: Private data for the switches
> > > + * @mux_set: Callback function for typec_mux_set
> > > + *
> > > + * This function registers USB Type-C switches for DP bridges that can switch
> > > + * the output signal between their output pins. This function uses devm_kcalloc
> > > + * to allocate memory, so it is expected to only call this in the driver probe
> > > + * functions.
> > > + *
> > > + * Currently only mode switches are implemented, and the function assumes the
> > > + * given @port device node has endpoints with "mode-switch" property.
> > > + * The port number is determined by the "reg" property of the endpoint.
> >
> > `kernel-doc -v ...` should complain on absence of "Return" section.
> >
> > > + */
> >
> > ...
> >
> > > + switch_desc->typec_ports = devm_kcalloc(dev, switch_desc->num_typec_switches,
> > > + sizeof(struct drm_dp_typec_port_data),
> >
> > sizeof(*switch_desc_typec_ports),
> >
> > ?
> >
> > > + GFP_KERNEL);
> > > + if (!switch_desc->typec_ports)
> > > + return -ENOMEM;
> >
> > ...
> >
> > > +#ifdef CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER
> >
> > Ah, maybe this should use IS_REACHABLE() ?
>
> CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER is a boolean. Is there any
> difference between IS_REACHABLE and ifdef when the given config is a
> boolean?
> >
> > > +void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_desc *switch_desc);
> > > +int drm_dp_register_typec_switches(struct device *dev, struct fwnode_handle *port,
> > > + struct drm_dp_typec_switch_desc *switch_desc,
> > > + void *data, typec_mux_set_fn_t mux_set);
> > > +#else
> > > +static inline void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_desc *switch_desc)
> > > +{
> > > +}
> > > +static inline int drm_dp_register_typec_switches(
> > > + struct device *dev, struct fwnode_handle *port,
> > > + struct drm_dp_typec_switch_desc *switch_desc, void *data,
> > > + typec_mux_set_fn_t mux_set)
> > > +{
> > > + return -EOPNOTSUPP;
> > > +}
> > > +#endif
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
>
> Best regards,
> Pin-yen
> >
Powered by blists - more mailing lists