Hi, On Sat, Mar 15, 2025 at 2:00 AM Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote: > > Hi Doug, > > > Seems reasonable to me. I would probably put an error message in this > > case, though? I don't think regmap_read() necessarily prints an error > > so it would just be a mysterious failure for why things didn't probe, > > right? > > OK, can do that. > > > This also only solves the problems for one of the 4 devices in this > > file. I think the GPIO device, PWM device, and DP-AUX device will > > still confusingly stick around. It's probably better to add a bogus > > regmap read in ti_sn65dsi86_probe(). > > Could be argued. I just wonder about all the other error cases in > ti_sn_attach_host() plus ti_sn_bridge_probe(). They have the same > problem with the other devices dangling? They do, though the other ones don't seem quite the same to me. It feels like an i2c device not actually showing up on the bus is a _somewhat_ normal/expected error. It also is an error that would affect all of the other sub-devices, so making sure they're not dangling is something that is worth doing. It feels like other errors that ti_sn_attach_host() plus ti_sn_bridge_probe() are likely to face are either unexpected (like a small memory allocation failing or an i2c transfer failing after a previous one succeeded) or are errors where leaving the dangling devices isn't really a problem. For instance: if somehow you fail to link up to a MIPI source then it feels OK that the GPIO / PWM and DP-AUX bus parts of the bridge continue to dangle. You can still use them, right? -Doug
