linux-kernel - Re: [PATCH v7 2/9] drm/bridge: Implement generic USB Type-C DP HPD bridge

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: <6f769567-b383-4c79-b441-3dd84f21cdae@rock-chips.com>
Date: Thu, 23 Oct 2025 20:10:20 +0800
From: Chaoyi Chen <chaoyi.chen@...k-chips.com>
To: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Vinod Koul <vkoul@...nel.org>,
 Kishon Vijay Abraham I <kishon@...nel.org>, Heiko Stuebner
 <heiko@...ech.de>, Sandy Huang <hjc@...k-chips.com>,
 Andy Yan <andy.yan@...k-chips.com>,
 Yubing Zhang <yubing.zhang@...k-chips.com>,
 Frank Wang <frank.wang@...k-chips.com>,
 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>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Amit Sunil Dhamne <amitsd@...gle.com>, Dragan Simic <dsimic@...jaro.org>,
 Johan Jonker <jbx6244@...il.com>, Diederik de Haas <didi.debian@...ow.org>,
 Peter Robinson <pbrobinson@...il.com>, linux-usb@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-phy@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v7 2/9] drm/bridge: Implement generic USB Type-C DP HPD
 bridge

Hi Heikki,

On 10/23/2025 8:03 PM, Heikki Krogerus wrote:
>>>> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
>>>> index 245e8a27e3fc..e91736829167 100644
>>>> --- a/drivers/gpu/drm/bridge/Makefile
>>>> +++ b/drivers/gpu/drm/bridge/Makefile
>>>> @@ -1,6 +1,7 @@
>>>>    # SPDX-License-Identifier: GPL-2.0
>>>>    obj-$(CONFIG_DRM_AUX_BRIDGE) += aux-bridge.o
>>>>    obj-$(CONFIG_DRM_AUX_HPD_BRIDGE) += aux-hpd-bridge.o
>>>> +obj-$(CONFIG_DRM_AUX_TYPEC_DP_HPD_BRIDGE) += aux-hpd-typec-dp-bridge.o
>>> Instead, why not just make that a part of aux-hpd-bridge
>>> conditionally:
>>>
>>> ifneq ($(CONFIG_TYPEC),)
>>>           aux-hpd-bridge-y        += aux-hpd-typec-dp-bridge.o
>>> endif
>> Oh, I did consider that! But I noticed that aux-hpd-bridge.c contains the
>> following statement module_auxiliary_driver(drm_aux_hpd_bridge_drv), which
>> already includes a module_init. In the newly added file, in order to call the
>> register function, another module_init was also added. If the two files are
>> each made into a module separately, would there be a problem?
> You would not call module_init() from the new file. Instead you would
> call drm_aux_hpd_typec_dp_bridge_init() and what ever directly from
> aux-hpd-bridge.c:
>
> diff --git a/drivers/gpu/drm/bridge/aux-bridge.h b/drivers/gpu/drm/bridge/aux-bridge.h
> new file mode 100644
> index 000000000000..ae689a7778fa
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef AUX_HPD_BRIDGE_H
> +#define AUX_HPD_BRIDGE_H
> +
> +#if IS_ENABLED(CONFIG_TYPEC)
> +int drm_aux_hpd_typec_dp_bridge_init(void);
> +void drm_aux_hpd_typec_dp_bridge_exit(void);
> +#else
> +static inline int drm_aux_hpd_typec_dp_bridge_init(void) { return 0; }
> +static inline void drm_aux_hpd_typec_dp_bridge_exit(void) { }
> +#endif /* IS_ENABLED(CONFIG_TYPEC) */
> +
> +#endif /* AUX_HPD_BRIDGE_H */
> diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> index 2e9c702c7087..3578df1df78a 100644
> --- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> @@ -12,6 +12,8 @@
>   #include <drm/drm_bridge.h>
>   #include <drm/bridge/aux-bridge.h>
>   
> +#include "aux-hpd-bridge.h"
> +
>   static DEFINE_IDA(drm_aux_hpd_bridge_ida);
>   
>   struct drm_aux_hpd_bridge_data {
> @@ -190,9 +192,16 @@ static int drm_aux_hpd_bridge_probe(struct auxiliary_device *auxdev,
>   
>          auxiliary_set_drvdata(auxdev, data);
>   
> +       drm_aux_hpd_typec_dp_bridge_init();
> +
>          return devm_drm_bridge_add(data->dev, &data->bridge);
>   }
>   
> +static void drm_aux_hpd_bridge_remove(struct auxiliary_device *auxdev)
> +{
> +       drm_aux_hpd_typec_dp_bridge_exit();
> +}
> +
>   static const struct auxiliary_device_id drm_aux_hpd_bridge_table[] = {
>          { .name = KBUILD_MODNAME ".dp_hpd_bridge", .driver_data = DRM_MODE_CONNECTOR_DisplayPort, },
>          {},
> @@ -203,6 +212,7 @@ static struct auxiliary_driver drm_aux_hpd_bridge_drv = {
>          .name = "aux_hpd_bridge",
>          .id_table = drm_aux_hpd_bridge_table,
>          .probe = drm_aux_hpd_bridge_probe,
> +       .remove = drm_aux_hpd_bridge_remove,
>   };
>   module_auxiliary_driver(drm_aux_hpd_bridge_drv);

Yes, if we don't distinguish them through Kconfig, we need to use the IS_ENABLED macro in the code. Thanks again for you code.


Another thing is that CONFIG_DRM_AUX_HPD_BRIDGE originally needed to be selected by other modules. With this change, we also need to expose it in Kconfig.


>
>
-- 
Best,
Chaoyi