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 <[email protected]>
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 that you
already have? And what is this going to be used for?
We have discussed this before, but the current bus notifier cannot achieve the
expected notification [0].
[0] https://lore.kernel.org/all/[email protected]/
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.
The first one is the registered event of the port device,
and the second one is the registered event of the partner device. The 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:
/* The partners are bind to drivers */
if (is_typec_partner(parent))
alt->adev.dev.bus = &typec_bus;
I hope it's not too late. In fact, the notifier here will notify DRM to
establish a bridge chain.
The downstream DP controller driver hopes to obtain the fwnode of the
last-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 Detect)
event.
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 driver will
also be deferred accordingly.
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 because
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 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?
Additionally, the current version of CONFIG_DRM_AUX_BRIDGE is selected by the
DP driver in patch9.
--
Best,
Chaoyi
