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]

Message-ID: <20211101200347.2910cbc7@sal.lan>
Date:   Mon, 1 Nov 2021 20:03:47 +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 20:06:52 +0100
Hans de Goede <hdegoede@...hat.com> escreveu:

> Hi,
> 
> On 11/1/21 15:10, Mauro Carvalho Chehab wrote:
> 
> <snip>
> 
> >>> Did you test on Baytrail (ISP2400), and with the compile-time option
> >>> enabled/disabled?    
> >>
> >> Sorry, I should have clarified on the cover later. For ISP2400, I did
> >> compile test only (CONFIG_VIDEO_ATOMISP_ISP2401 enabled/disabled).  
> > 
> > Maybe Hans could help us on that. I guess he has an Asus T100 device, 
> > which is BYT based.
> > 
> > Hans, if you're willing to do the tests, you could either use nvt
> > or v4l2grab to test it.
> > 
> > It seems that BYT has an additional issue, though: the ISP seems to
> > require 12 non-visible lines/columns (in addition to 16 ones required
> > by CHT?) for it to work.
> > 
> > So, you may need to tweak the resolution a bit, as otherwise the
> > driver will return an -EINVAL.
> > 
> > See:
> > 
> > 	https://git.linuxtv.org/media_stage.git/commit/?id=dcbc4f570495dbd490975979471687cbe2246f99
> > 
> > For the workaround I had to add for CHT to properly report the
> > visible resolution.  
> 
> Testing BYT support definitely is on my radar. Note that BYT
> also has the additional issue that the atomisp2 on BYT can be
> enumerated as either a PCI dev (which may work) or an ACPI/platform
> dev which is unsupported in the original atomisp2 code-drop and
> seems non trivial (because of pci config space writes) to get to
> work.
> 
> On the T100TA the device is actually enumerated as an ACPI/platform
> device and the BIOS option to change this is hidden. In the mean
> time I've gained quite a lot of experience with changing hidden
> BIOS options though, so I can easily put it in PCI mode for
> testing. But eventually we also need to tackle ACPI enumeration
> support...
> 
> Anyways I've let me self get distracted (hobby time wise) by
> looking into PMIC/charger/fuel-gauge issues on the Xiaomi Mi Pad 2.
> I've made a list of 3 (small-ish) loose ends which I want to
> tie up there and then I plan to start looking into atomisp2
> support in my hobby time. ATM my plan is:
> 
>    -Test on T101HA to reproduce Mauro's work

Yeah, it would be great to have a second test on it. I suspect that it
should work just fine with USERPTR (with v4l2grab or nvt).

>    -Try to get things to work on the T116

Didn't test it here either, but won't be able to do in the next
couple of weeks.

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

> And I've just added:
> 
>    -Try out BYT support 

Thanks!

> 
> As 4th item. Eventually I want to look into writing a proper
> regulator driver for the PMICs

Yeah, a proper regulator driver would be a lot better than the
PMIC ones.

> and then try to make the atomisp2
> code work with the non "atomisp_xxx" versions of the sensor drivers.

With a regulator driver, part of the problem will be solved. However, 
as the ISP driver "eats" 16 lines and 16 columns. It means that the sensor 
needs to be adjusted for it to provide those extra data. So, the atomisp 
sensor resolutions are (X + 16) x (Y + 16), e. g. in the case of
ov2680, it is set to 1616x1216, while the upstream one is 1600x1200.

Not sure if the selection API currently allows changing that to
satisfy atomisp, or if something else would be needed.

Regards,
Mauro