Hi Laurent, On Mon, Sep 18, 2023 at 04:24:55PM +0300, Laurent Pinchart wrote: > Hi Sakari, > > Thank you for the patch. > > On Mon, Sep 18, 2023 at 03:51:35PM +0300, Sakari Ailus wrote: > > With ipu bridge, endpoints may only be created when ipu bridge has > > initialised. This may happen after the sensor driver has first probed. > > > > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > > --- > > drivers/media/i2c/ov2740.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/media/i2c/ov2740.c b/drivers/media/i2c/ov2740.c > > index 2c00e653ec47..ccbb15e730ae 100644 > > --- a/drivers/media/i2c/ov2740.c > > +++ b/drivers/media/i2c/ov2740.c > > @@ -976,7 +976,7 @@ static int ov2740_check_hwcfg(struct device *dev) > > > > ep = fwnode_graph_get_next_endpoint(fwnode, NULL); > > if (!ep) > > - return -ENXIO; > > + return -EPROBE_DEFER; > > This is fine as a quick fix, so > > Reviewed-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> Thank you. > > but I'm thinking that we need better in the long run, for multiple > reasons: > > - All sensor drivers that support ACPI should do the same, as they > shouldn't be aware of platform-specific integration details. This > could be done by mass-patching them, with a documentation update to > clearly indicate what error code is appropriate. Another option could > be to return an error pointer from fwnode_graph_get_next_endpoint(), > with the appropriate error being set depending on the platform. Other > solutions may be possible too. I'd like to see IPU bridge in the ACPI framework but that won't happen overnight. Then this issue would disappear. The problem with the error is that callers don't expect it and how do you tell if you're expecting something you don't know about to appear. > > - On OF systems, a DT error will result in probe deferral, which is > harder to debug than probe failures. It would be nice to avoid that. Yes. I change it for this sensor only as I was otherwise working on it. -- Regards, Sakari Ailus
