From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 09605CFD313 for ; Mon, 24 Nov 2025 16:33:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wlM9sl3IOcPXydq8nQoAMEgVrlZPFjRsZT8yk+7huws=; b=H0ZhRE1Ia0P+Ln 9XGO2MQLz0KCbrnEouT1VrF1EJC+OeQ8bqMzGPan/1DpAfaZT5hzWfY7wOM7B30HGPsLonMaTKtJL ZhqSkUKLbaCyss9JucNjQoAIs0ysIAimMreIXZGgF9VI/E146YWSkAJMqim7JJ+CaHAddw6aYGuli aOubWKY9kalVV3tCYBp8pp5Jxo9atmZRDNup+LDTCIhKa8DqGSbvHBVpUKpxL3i32F9Up8SRdM9TE MBXffIcyTko9TZ1bULFvDdGLju4tRWQMFVB52iCZq7znBuHUCL8gyNspqb4kIF/Ap3HAo0VWM7IAX xuMDQtFUAEzBPxDhGvjA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vNZVN-0000000C04T-2j1s; Mon, 24 Nov 2025 16:33:33 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vNZVL-0000000C041-1rMD; Mon, 24 Nov 2025 16:33:31 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 8E38D60173; Mon, 24 Nov 2025 16:33:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2D80C116C6; Mon, 24 Nov 2025 16:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1764002010; bh=b0HsFdIr9UYeg1Jbb+ezqHtOK4AZhADd9B70yMMGZFc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=g+47ol/xVPKvHq8mO+c2fpgR8DW18YAaKTmijBBG2VtkLGfdTcX8n57jEGZgYFtXt DF01gZjsrt73ZFaL90qrJ9go9zBaa62onSiMzWQEv3i/waUjE3nOD4/TVDH9cmjl4K 53oeGgUWsOdxH3qnIhbrSMDif3kOexD/8BLXzSs0= Date: Mon, 24 Nov 2025 17:33:27 +0100 From: Greg Kroah-Hartman To: Chaoyi Chen Cc: Chaoyi Chen , Heikki Krogerus , Dmitry Baryshkov , Peter Chen , Luca Ceresoli , 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 Subject: Re: [PATCH v10 01/11] usb: typec: Add notifier functions Message-ID: <2025112448-brush-porcupine-c851@gregkh> References: <20251120022343.250-1-kernel@airkyi.com> <20251120022343.250-2-kernel@airkyi.com> <2025112102-laurel-mulch-58e4@gregkh> <462ad1bd-7eec-4f26-b383-96b049e14559@rock-chips.com> <2025112402-unopposed-polio-e6e9@gregkh> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org On Mon, Nov 24, 2025 at 04:05:53PM +0800, Chaoyi Chen wrote: > Hi Greg, > = > On 11/24/2025 3:10 PM, Greg Kroah-Hartman wrote: > = > > On Mon, Nov 24, 2025 at 09:40:03AM +0800, Chaoyi Chen wrote: > > > Hi Greg, > > > = > > > On 11/21/2025 10:07 PM, Greg Kroah-Hartman wrote: > > > > On Thu, Nov 20, 2025 at 10:23:33AM +0800, Chaoyi Chen wrote: > > > > > From: Chaoyi Chen > > > > > = > > > > > Some other part of kernel may want to know the event of typec bus. > > > > Be specific, WHAT part of the kernel will need to know this? > > > For now, it is DRM. > > Then say this. > = > Okay, please refer to the discussion below. > = > > = > > > > And why a new notifier, why not just use the existing notifiers tha= t you > > > > already have? And what is this going to be used for? > > > We have discussed this before, but the current bus notifier cannot ac= hieve the expected notification [0]. > > > = > > > [0] https://lore.kernel.org/all/aPsuLREPS_FEV3DS@kuha.fi.intel.com/ > > Then you need to document the heck out of this in the changelog text. > > But I'm still not quite understanding why the bus notifier does not work > > here, as you only want this information if the usb device is bound to > > the bus there, you do not want to know this if it did not complete. > > = > > That thread says you want this not "too late", but why? What is the > > problem there, and how will you handle your code getting loaded after > > the typec code is loaded? Notifier callbacks don't work for that > > situation, right? > = > In fact, the typec_register_altmode() function generates two > registered events.=A0The first one is the registered event of the port > device, and the second one is the registered event of the partner > device.=A0The second one event only occurs after a Type-C device is > inserted. > The bus notifier event does not actually take effect for the port > device, because it only sets the bus for the partner device: > = > =A0 =A0 /* The partners are bind to drivers */ > =A0 =A0 if (is_typec_partner(parent)) > =A0 =A0 =A0 =A0 alt->adev.dev.bus =3D &typec_bus; Setting the bus is correct, then it needs to be registered with the driver core so the bus link shows up (and a driver is bound to it.) That is when the bus notifier can happen, right? > I hope it's not too late. In fact, the notifier here will notify DRM to e= stablish a bridge chain. What is a "bridge chain"? > The downstream DP controller driver hopes to obtain the fwnode of the las= t-level Type-C device > through this bridge chain to create a DRM connector. And when a device is= inserted, > drivers/usb/typec/altmodes/displayport.c can notify the HPD (Hot Plug Det= ect) event. But aren't you just the driver for the "partner device"? If not, why isn't a real device being created that you then bind to, what "fake" type of thing are you attempting to do here that would require you to do this out-of-band? > If relying on the second event, the bridge chain may never be established= , and the operations of the DP driver will be > always deferred. Furthermore, other parts of the display controller drive= r will also be deferred accordingly. What operations? What exactly is delayed? You should not be touching a device before you have it on your bus, right? > > > > Notifiers are a pain, and should almost never be added. Use real > > > > function calls instead. > > > In v6, I used direct function calls, but had to switch to notifiers b= ecause couldn't resolve the dependencies between DRM and Type-C [1]. Do you= have any good ideas? Thank you. > > Only allow this DRM code to be built if typec code is enabled, do NOT > > use a select, use a depends in the drm code. > = > Sorry, I didn't get your point. Does this mean that the current notifiers= approach still needs to be changed to direct function calls? If you somehow convince me that the existing bus notifiers will not work, yes :) > If so, then based on the previous discussion, typec should not depend > on any DRM components. Does this mean that we should add the if > (IS_REACHABLE(CONFIG_DRM_AUX_BRIDGE)) before the direct function call? No, do it properly like any other function call to another subsystem. > Additionally, the current version of CONFIG_DRM_AUX_BRIDGE is selected > by the DP driver in patch9. Don't do "select" if at all possible, always try to do "depends on". thanks, greg k-h -- = linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy