[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8b81025d-a35d-da91-b059-eab1108013e8@redhat.com>
Date: Mon, 1 Nov 2021 22:06:12 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Mauro Carvalho Chehab <mchehab@...nel.org>
Cc: Tsuchiya Yuto <kitakar@...il.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-media@...r.kernel.org, linux-staging@...ts.linux.dev,
linux-kernel@...r.kernel.org,
Nable <nable.maininbox@...glemail.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Fabio Aiuto <fabioaiuto83@...il.com>,
"andrey.i.trufanov" <andrey.i.trufanov@...il.com>,
Patrik Gfeller <patrik.gfeller@...il.com>
Subject: Re: [PATCH 04/17] media: atomisp: pci: do not use err var when
checking port validity for ISP2400
Hi,
On 11/1/21 21:03, Mauro Carvalho Chehab wrote:
> Em Mon, 1 Nov 2021 20:06:52 +0100
> Hans de Goede <hdegoede@...hat.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 :)
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
Powered by blists - more mailing lists