Re: [PATCH 04/17] media: atomisp: pci: do not use err var when checking port validity for ISP2400

[Mauro Carvalho Chehab <mchehab@kernel.org>]

Em Mon, 1 Nov 2021 22:06:12 +0100
Hans de Goede <hdegoede@redhat.com> escreveu:

> Hi,
> 
> On 11/1/21 21:03, Mauro Carvalho Chehab wrote:
> > Em Mon, 1 Nov 2021 20:06:52 +0100
> > Hans de Goede <hdegoede@redhat.com> escreveu:  
> 
> <snip>
> 
> >>    -Patch to not load atomisp_foo sensor drivers on !BYT && !CHT  
> > 
> > Not sure if it is worth doing it, as there are a lot more to be
> > done before being able to use a generic sensor driver.  
> 
> As you may know, I'm also working on IPU3 support for $dayjob atm
> actually :)

Didn't know that... Btw, I have one Dell device with IPU3. It would 
be great to have it working there ;-)

> So the drivers for e.g. the ov5693 sensor conflict, by adding
> a small (one line) check to atomisp_ov5693.c to not register
> the driver at all when not on BYT/CHT we can avoid the conflict
> on most devices for now. And when actually on BYT/CHT the user
> will need to blacklist the non atomisp sensor-modules which, well
> sucks, but atomisp is in staging for a reason ...
> 
> So the idea here is that with some small added ugliness to the
> atomisp_foo.c sensor drivers we can make the 2 drivers co-exist
> a bit more, allowing e.g. generic distro kernels to (maybe) enable
> the atomisp2 stuff without regressing the IPU3 support.
> 
> ###
> 
> Since we are discussing this now anyways, the atomisp_foo.c
> patches would look like this:
> 
> #include <linux/platform_data/x86/soc.h>
> 
>         if (!soc_intel_is_byt() && !soc_intel_is_cht())
>                 return -ENODEV;
> 
> In the probe() function and change driver.name from
> e.g. "ov5693" to "atom_ov5693".
> 
> Before I spend time on writing patches for this, would patches doing
> this for conflicting drivers be acceptable ?

Surely. Yeah, it makes sense to me. Feel free to submit such
patches.

Regards,
Mauro