Em Mon, 1 Nov 2021 22:06:12 +0100 Hans de Goede <hdegoede@xxxxxxxxxx> 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@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 :) 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
