Re: [RFC PATCH v10 1/2] media: iris: introduce helper module to select video driver

[Johan Hovold <johan@kernel.org>]

On Mon, Feb 03, 2025 at 05:34:20PM +0100, Krzysztof Kozlowski wrote:
> On 03/02/2025 16:16, Dmitry Baryshkov wrote:
> > On Mon, Feb 03, 2025 at 09:22:51AM +0100, Johan Hovold wrote:
> >> On Fri, Jan 31, 2025 at 10:44:28AM -0800, Abhinav Kumar wrote:
> >>> On 1/29/2025 2:44 AM, Krzysztof Kozlowski wrote:
> >>>> On 28/01/2025 09:04, Dikshita Agarwal wrote:

> >>>>> @@ -196,6 +196,9 @@ static int iris_probe(struct platform_device *pdev)
> >>>>>   	u64 dma_mask;
> >>>>>   	int ret;
> >>>>>   
> >>>>> +	if (!video_drv_should_bind(&pdev->dev, true))
> >>>>> +		return -ENODEV;
> >>>>
> >>>> Wouldn't it mark the probe as failed and cause dmesg regressions?
> >>
> >> No, this is perfectly fine. Probe can return -ENODEV and driver core
> >> will continue with any further matches.

> >>> 2) with current approach, one of the probes (either venus or iris) will 
> >>> certainly fail as video_drv_should_bind() will fail for one of them. 
> >>> This can be considered as a regression and should not happen.
> >>
> >> How can that be a regression? One driver must fail to probe (see above).
> > 
> > I also don't think that it's a regression. I think Krzysztof was
> > concerned about the 'failed to bind' messages in dmesg.
> 
> I never used word "regression" alone. I said "dmesg regression", which
> means you have error in logs or any system facility which provides you
> self-information about device probe history. I don't remember if -ENODEV
> leads to any printks, so maybe I am wrong here, but regardless normal
> and expected operation of a driver should never result in -ERRNO, except
> deferred probe of course.

A probe function returning -ENODEV is not an error and is used to signal
that the driver should not bind to the device it has just probed. So
that part is perfectly fine here as I mentioned above.

Johan