linux-kernel - Re: [PATCH 00/17] various fixes for atomisp to make it work

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]

Message-ID: <20211030193001.43c916e1@sal.lan>
Date:   Sat, 30 Oct 2021 19:30:01 +0100
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.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 00/17] various fixes for atomisp to make it work

Em Sat, 30 Oct 2021 14:01:01 +0300
Andy Shevchenko <andy.shevchenko@...il.com> escreveu:

> On Sat, Oct 30, 2021 at 1:49 PM Mauro Carvalho Chehab
> <mchehab@...nel.org> wrote:
> > Em Sat, 30 Oct 2021 18:50:14 +0900
> > Tsuchiya Yuto <kitakar@...il.com> escreveu:  
> 
> ...
> 
> > What I'm saying is that, IMHO, we should:
> >
> > 1. Fix the ioctls in order to allow a normal app to use it. I'm
> >    already doing some work on this sense. We should ensure that the
> >    driver will pass v4l2-compliance tests on this step;
> >
> > 2. remove VIDEO_ATOMISP_ISP2401, making the driver to auto-detect the
> >    register address differences between ISP2400 and ISP2401;
> >
> > 3. Cleanup the driver code, removing the abstraction layers inside it;
> >
> > 4. Migrate the sensor drivers out of staging (or re-using existing
> >    drivers);
> >
> > 5. Remove the logic which sets up pipelines inside it, moving it to
> >    libcamera and implement MC support;
> >
> > 6. Move it out of staging.
> >
> > This is easily said than done, as steps 2-6 are very complex and will
> > require lots of work. Also, both ISP2400 and 2401 should be tested
> > while doing some of those major reworks, in order to avoid breakages.  
> 
> This is a great roadmap nevertheless!

> However, we missed one important step here, i.e. persuade Intel to
> clarify license of the firmware (for distirbution) and make sure we
> have it in Linux firmware project, so it won't get lost.

Heh, true!

I suspect that the firmare for ISP2401, used on Intel Aero, is probably
easier to make it available than the firmware for ISP2400.

At least looking at the github repository for Intel Aero, it says at the 
package metadata that its content is under GPL:

	https://github.com/intel-aero/meta-intel-aero-base/blob/master/LICENSE

The firmware itself is there, at:

	https://github.com/intel-aero/meta-intel-aero-base/blob/master/recipes-kernel/linux/linux-yocto/shisp_2401a0_v21.bin


The Yocto's meta package for the firmware blob is at:

	https://github.com/intel-aero/packages/tree/master/firmware-atomisp

Also says, on its copyright's notice:

	https://github.com/intel-aero/packages/blob/master/firmware-atomisp/debian/copyright

that:

	Source: https://github.com/intel-aero/meta-intel-aero-base

	Files: *
	Copyright: 2016 Intel Corporation
	License: GPL-2
	 /usr/share/common-licenses/GPL-2

Granted, it doesn't make sense to say that a firmware blob is under
GPL. My reading is that the original intend was to allow GPL software
to use/distribute such firmware, but yeah, someone at Intel should
provide the community an explicit authorization to allow distros to
start packaging such firmware.

Regards,
Mauro