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 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