On Fri, Aug 29, 2025 at 09:40:30AM -0700, Doug Anderson wrote: > Hi, > > On Wed, Aug 20, 2025 at 8:24 AM John Ripple <[email protected]> wrote: > > > > The commit c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our > > DSI device at probe") was intended to prevent probe ordering issues and > > created the ti_sn_attach_host function. > > > > In practice, I found the following when using the nwl-dsi driver: > > - ti_sn_bridge_probe happens and it adds the i2c bridge. Then > > ti_sn_attach_host runs (in the ti_sn_bridge_probe function) and fails to > > find the dsi host which then returns to ti_sn_bridge_probe and removes > > the i2c bridge because of the failure. > > - The nwl_dsi_probe then runs and adds dsi host to the host list and then > > looks for the i2c bridge, which is now gone, so it fails. This loop > > continues for the entire boot sequence. > > Which i2c bridge are you talking about? You mean the one created by > i2c_add_adapter() in drm_dp_aux_register()? I guess I'm confused about > why the DSI probe routine would even be looking for that adapter. > > In any case, I don't _think_ your patch is valid. Specifically, if you > notice ti_sn_attach_host() can return "-EPROBE_DEFER". That's a valid > error code to return from a probe routine but I don't think it's a > valid error code to return from a bridge attach function, is it?
It's not documented anywhere though, so we'd need to document (and assess) if it's acceptable first. We should also amend https://docs.kernel.org/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges Maxime
signature.asc
Description: PGP signature
