On Wed Jun 24, 2026 at 1:47 PM CEST, Maxime Ripard wrote: > On Fri, Jun 12, 2026 at 02:57:39PM +0200, Luca Ceresoli wrote: >> On Mon Jun 8, 2026 at 1:41 PM CEST, Maxime Ripard wrote: >> > On Tue, May 19, 2026 at 12:37:23PM +0200, Luca Ceresoli wrote: >> >> Currently drm_bridge_connector_init() always returns the added connector >> >> or >> >> errors out. When adding bridge hotplug the bridge-connector can be >> >> successfully initialized without creating a connector, which can be added >> >> later when the pipeline will be complete. >> >> >> >> For this the internal function drm_bridge_connector_add_connector() must >> >> be >> >> able to return a valid drm_bridge_connector even without any >> >> drm_connector. >> >> >> >> In preparation to support bridge hotplug, change its return value to be >> >> the >> >> same drm_bridge_connector pointer it gets as input, or a PTR_ERR. >> >> >> >> No functional changes, just changing an internal API. >> >> >> >> Note the return value could now become an int (0 or negative error) >> >> because >> >> returning the same value received as input does not carry any added >> >> value. However this would be change a lot of lines, so leave such change >> >> as >> >> a future cleanup. >> > >> > You just created that function and changed "a lot of lines" already, so >> > I'm not sure that argument holds. >> >> Do you refer to the previous patch? >> >> My comment is more about the following patches. It means I separated >> changes moving code to a subfunction from changes to the the return value >> in separate patches, so that each patch is trivial to review for >> correctness. >> >> Makes sense? > > What confused me is that I took it as "I'm not going to do that work > (yet?)". If you do it later on, I'd drop the "future cleanup" part, or > rephrase it.
Ah, I see the issue. I really meant "this change [returning int] is done in a following commit". I guess I'll just drop the whole paragraph. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
