From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m49195.qiye.163.com (mail-m49195.qiye.163.com [45.254.49.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B262330F93F; Thu, 23 Oct 2025 12:10:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.254.49.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761221449; cv=none; b=H8CmKjOOg249vW3gl3Y4h286MRfQxn1TLE37hzO1nL6R9XxrC+/GuJeQN8aqYRWD2zwb/8DJLWugxADfssQueBKfD+qt2omdOuMzjBILiljAhkItPK8zOrE6GltDu094XhLlzSYciTujO/seVtlrffVlPnPBo5Ri7ecTe1M3vhQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761221449; c=relaxed/simple; bh=oAZzN4JwMBb4zdgdgHMUaM0HJArOfgw/LUeK6U1j1qg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=e/4mmLjJ+BabY5CS/QHLDEleXNJ5wz2AmWmggQw7XVcNBGCiyQfJnmWPckXJfQWjYhSySu1WE63CySb3hH9nLGvAzVPoB9RMSR5OADVwua7CSRqtLm8n8JO9G9q0P6Fmmq3yfFMklGcdRxG+nLBmv42F48/RUebMPFyl6MhO99w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rock-chips.com; spf=pass smtp.mailfrom=rock-chips.com; dkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com header.b=biNjzk7L; arc=none smtp.client-ip=45.254.49.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rock-chips.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rock-chips.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com header.b="biNjzk7L" Received: from [172.16.12.149] (unknown [58.22.7.114]) by smtp.qiye.163.com (Hmail) with ESMTP id 26f2c95f7; Thu, 23 Oct 2025 20:10:21 +0800 (GMT+08:00) Message-ID: <6f769567-b383-4c79-b441-3dd84f21cdae@rock-chips.com> Date: Thu, 23 Oct 2025 20:10:20 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 2/9] drm/bridge: Implement generic USB Type-C DP HPD bridge To: Heikki Krogerus Cc: Greg Kroah-Hartman , Dmitry Baryshkov , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Vinod Koul , Kishon Vijay Abraham I , Heiko Stuebner , Sandy Huang , Andy Yan , Yubing Zhang , Frank Wang , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Amit Sunil Dhamne , Dragan Simic , Johan Jonker , Diederik de Haas , Peter Robinson , linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, dri-devel@lists.freedesktop.org References: <20251023033009.90-1-kernel@airkyi.com> <20251023033009.90-3-kernel@airkyi.com> <14b8ac71-489b-4192-92d6-5f228ff3881d@rock-chips.com> Content-Language: en-US From: Chaoyi Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-HM-Tid: 0a9a10fa2ad903abkunm63b0b3181a1121 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFDSUNOT01LS0k3V1ktWUFJV1kPCRoVCBIfWUFZQ0hCTlZDT0xDTk4ZSUgdHRhWFRQJFh oXVRMBExYaEhckFA4PWVdZGBILWUFZTkNVSUlVTFVKSk9ZV1kWGg8SFR0UWUFZT0tIVUpLSEpPSE xVSktLVUpCS0tZBg++ DKIM-Signature: a=rsa-sha256; b=biNjzk7LSVRSGV1ZBRFm2pqDrcSqN6X6pQT3v+20RIGWpgAkjhtuaHxj6ZVvF/acb202inF411z7yGIUoF/7CHQ2Pg/L6wLybWl0rz+LjhvsgHqysLYlVIWIXUgVF/qQOrfHbm3hQOkvKYsFtMh9rTdxx3ulZty1nhOw2ruKgYk=; s=default; c=relaxed/relaxed; d=rock-chips.com; v=1; bh=+tppR1r2GR2aHsAGWh+r4F7VMu3ZGa0gIoTITM9UMtU=; h=date:mime-version:subject:message-id:from; 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 > #include > > +#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