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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 11/1/21 21:03, Mauro Carvalho Chehab wrote:
> Em Mon, 1 Nov 2021 20:06:52 +0100
> Hans de Goede <hdegoede@xxxxxxxxxx> 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 :)

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 ?

Regards,

Hans





[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux