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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 1 Nov 2021 21:33:52 +0000
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     Hans de Goede <hdegoede@...hat.com>
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

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

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