media: gspca: Make use of the helper macro kthread_run()

Repalce kthread_create/wake_up_process() with kthread_run()
to simplify the code.

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: aspeed: fix mode-detect always time out at 2nd run

aspeed_video_get_resolution() will try to do res-detect again if the
timing got in last try is invalid. But it will always time out because
VE_SEQ_CTRL_TRIG_MODE_DET is only cleared after 1st mode-detect.

To fix the problem, just clear VE_SEQ_CTRL_TRIG_MODE_DET before setting
it in aspeed_video_enable_mode_detect().

Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver")
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: Remove unneeded null check

In ia_css_frame_map, the check of 'err' is unneeded to be done twice.

Link: https://lore.kernel.org/linux-media/20211110094910.67951-1-vulab@iscas.ac.cn
Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: get rid of atomisp_get_frame_pgnr() abstraction

Simplify the code by getting rid of this function, as it ends
being just a single line of code.

Link: https://lore.kernel.org/linux-media/80ea920d14379124ba92aab2e6a6d12a92d79b2b.1636544620.git.mchehab+huawei@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: simplify asd check on open() fops

The open() fops support two types of devices: "acc" and normal
ones. the acc works on a different way, using a different pipe
struct. Not sure yet if it would make sense to setup a run_mode
there. Also, As default_run_mode exists only on normal modes,
we can simplify the logic to check if the device is in normal
mode.

That solves this warning:

../drivers/staging/media/atomisp/pci/atomisp_fops.c:904 atomisp_open() warn: variable dereferenced before check 'asd' (see line 807)

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: check before deference asd variable

The asd->isp was referenced before checking if asd is not
NULL.

This fixes this warning:

../drivers/staging/media/atomisp/pci/atomisp_cmd.c:5548 atomisp_set_fmt_to_snr() warn: variable dereferenced before check 'asd' (see line 5540)

While here, avoid getting the pipe pointer twice.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: only initialize mode if pipe is not null

During atomisp register, udev tries to open all devices. For
some, pipe is NULL, at least during register time, causing the
driver to try to access a NULL pointer.

So, add an extra check to avoid such condition.

Link: https://lore.kernel.org/linux-media/6406265f2d5f3791d5c7cbd1364186217f19524c.1636364423.git.mchehab+huawei@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix uninitialized bug in gmin_get_pmic_id_and_addr()

The "power" pointer is not initialized on the else path and that would
lead to an Oops.

Link: https://lore.kernel.org/linux-media/20211012082150.GA31086@kili
Fixes: c30f4cb2d4c7 ("media: atomisp: Refactor PMIC detection to a separate function")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: properly set the vts value

The vts value should be set before being checked, as otherwise a
warning will arise:

drivers/staging/media/atomisp/i2c/atomisp-ov2680.c: In function 'ov2680_set_fmt':
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:873:33: warning: 'vts' may be used uninitialized
[-Wmaybe-uninitialized]
  873 |         if (dev->exposure > vts - OV2680_INTEGRATION_TIME_MARGIN)

Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Fixes: 62b984359b6f ("media: atomisp-ov2680: Fix ov2680_set_fmt() messing up high exposure settings")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: initialize return var

As the settings are only applied when the device is powered on,
it should return 0 when the device is not powered.

Not doing that causes a warning:

drivers/staging/media/atomisp/i2c/atomisp-ov2680.c: In function 'ov2680_ioctl':
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:390:16: warning: 'ret' may be used uninitialized in this
function [-Wmaybe-uninitialized]
  390 |         return ov2680_set_exposure(sd, coarse_itg, analog_gain, digital_gain);
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:359:13: note: 'ret' was declared here
  359 |         int ret;
      |             ^~~

Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Fixes: 6b5b60687ada ("media: atomisp-ov2680: Save/restore exposure and gain over sensor power-down")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Fix ov2680_set_fmt() messing up high exposure settings

For exposure settings > (lines_per_frame - vts_margin) the VTS register
needs to be programmed to (exposure + vts_margin) rather then being
set to lines_per_frame.

The res->regs register array was clobbering this higher setting causing
high exposure settings to not work. Fix this by letting ov2680_set_fmt()
calculate the vts value, instead of hardcoding it.

This is the last in a series of fixes which fixes exposure and gain
settings not working, with this everything works, so drop the comment
that it does not work.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-12-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Fix ov2680_set_fmt() clobbering the exposure

Now that we restore the default or last user set exposure setting on
power_up() there is no need for the registers written by ov2680_set_fmt()
to write to the exposure register.

Not doing so fixes the exposure always being reset to the value from
the res->regs array after a set_fmt().

Link: https://lore.kernel.org/linux-media/20211107171549.267583-11-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Fix ov2680_write_reg() always writing 0 to 16 bit registers

The shift << 16 of the value in the code path for 16 bit values is
bogus, put_unaligned_be16() takes the lower 16 bits which will not
always be 0.

This was causing __ov2680_set_exposure() to always set the
OV2680_AGC and OV2680_TIMING_VTS registers to 0.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-10-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Fix and simplify ov2680_q_exposure()

Switch to ov2680_read_reg() to read all 24 bits in one go;
and the exposure value sits in bits 4-19 of the 24 bit exposure
register, so we need to shift the read value by 4 to report the
correct value.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-9-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Make ov2680_read_reg() support 24 bit registers

Some ov2680 registers like exposure are 24 bit,
ov2680_read_reg() already mostly supports this, we just
need to change the return type from u16 to u32.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-8-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Save/restore exposure and gain over sensor power-down

Save/restore exposure and gain over sensor power-down and don't write them
to the sensor when ov2680_set_exposure() is called while the sensor is off.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-7-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Move ov2680_init_registers() call to power_up()

Move ov2680_init_registers() call to power_up(), so that we also
init the registers on code-paths which do not call ov2680_s_power()
like running camorama.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-6-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Remove the ov2680_res and N_RES global variables

The ov2680_res and N_RES global variables are just hardcoded as aliases
for ov2680_res_preview and N_RES_PREVIEW, remove them.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-5-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Push the input_lock taking up into ov2680_s_power()

ov2680_s_power() is the only caller of ov2680_init(), push the input_lock
taking from ov2680_init() up into ov2680_s_power(), this way the new
power_on bool is also protected by it.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-4-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Turn on power only once

Add a power_on bool to track if the power is on, and make
power_up() a no-op if the power is already on.

This also removes a power_down() call from ov2680_s_config() since
that is a no-op now, this is ok because s_config() is only called
once on probe and the sensor is off at boot.

Besides avoiding to the work in power_up() multiple times this patch
is also a preparation for switching to the clk and regulator frameworks
which keep an enable count, so there we must call enable() and
disable() only once per power-cycle.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-3-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: Remove a bunch of unused vars from ov2680_device

Remove a couple of variables which where either completely unused,
or only ever got a value assigned to them but were never read.

Link: https://lore.kernel.org/linux-media/20211107171549.267583-2-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: register first the preview devnode

The atomisp currenyl registers 5 pairs of devices each one
for one different run_mode, plus one for "ACC". The only
one that behaves like a normal V4L2 device is the preview
one. The others are doing weird things, and perhaps are
using some proprietary extensions to the API.

Change the device order to start with the preview one,
e. g:

/dev/video0: ATOMISP ISP PREVIEW output
/dev/video1: ATOMISP ISP CAPTURE output
/dev/video2: ATOMISP ISP VIEWFINDER output
/dev/video3: ATOMISP ISP VIDEO output
/dev/video4: ATOMISP ACC

This way, a normal V4L2 application will get the right
device, as the first one will be the one they should use.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: set per-device's default mode

The atomisp driver originally used the s_parm command to
initialize the run_mode type to the driver. So, before start
setting up the streaming, s_parm should be called.

So, even having 5 "normal" video devices, one meant to be used
for each type, the run_mode was actually selected when
s_parm is called.

Without setting the run mode, applications that don't call
VIDIOC_SET_PARM with a custom atomisp parameters won't work, as
the pipeline won't be set:

atomisp-isp2 0000:00:03.0: can't create streams
atomisp-isp2 0000:00:03.0: __get_frame_info 1600x1200 (padded to 0) returned -22

However, commit 8a7c5594c020 ("media: v4l2-ioctl: clear fields in s_parm")
broke support for it, with a good reason, as drivers shoudn't be
extending the API for their own purposes.

So, as an step to allow generic apps to use this driver, put
the device's run_mode in preview after open.

After this patch, using v4l2grab starts to work on preview
mode (/dev/video2):

$ v4l2grab -f YUYV -x 1600 -y 1200 -d /dev/video2 -n 1 -u
$ feh out000.pnm

So, let's just setup the default run_mode that each video devnode
should assume, setting it at open() time.

Reported-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: get rid of ISP2401_NEW_INPUT_SYSTEM

All ISP2401 devices use the new input system. So, get rid
of the remaining definitions, replacing them by runtime
checks for BYT/CHT when applicable.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: return errors from ia_css_dma_configure_from_info()

Now that the pipeline config functions can return errors, change
ia_css_dma_configure_from_info() and callers in order for them
to return errors at pipelines instead of using assert().

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: add return codes for pipeline config functions

Those functions can internally break, but, as they don't return
errors, internally there are some assert() calls, which is bad,
as it hangs the driver.

So, add return codes there, in preparation for removing such
assert() calls.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: sh_css_sp: better handle pipeline config errors

If something gets wrong while setup a pipeline, return an
error code.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: propagate errors at ia_css_*_configure()

Propagate the lower lever ia_css config errors to the next
level.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: cleanup ia_css_isp_configs() code

The auto-generated code inside ia_css_isp_configs() is more
complex than it should be. Also, it doesn't return any errors.

However, the functions called by it can mis-configure the pipelines,
but, as there's no way to return errors, it internally calls the
assert() macro.

So, add a return parameter to each routine there, in order to
prepare the code to be more robust.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: unify ia_css_isp_params.c

The contents of ia_css_isp_params.c is almost identical for
2400 and 2401. The only difference is that, on 2400, there
are some duplicated assignments. So, drop it, unifying this
file.

While here, simplify the Makefile's logic by dropping an
unused define.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: drop duplicated ia_css_isp_states.c

Both 2400 and 2401 have this file, but they're identical.
So, drop one of them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: drop duplicated ia_css_isp_configs.c

Both 2400 and 2401 have this file, but they're identical.

So, drop one of them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: allocate a v4l2_fh at open time

This avoids an OOPS when VIDIOC_*_PRIORITY calls are used.

[   90.820011] BUG: kernel NULL pointer dereference, address: 0000000000000020
[   90.820021] #PF: supervisor read access in kernel mode
[   90.820026] #PF: error_code(0x0000) - not-present page
[   90.820030] PGD 1221bc067 P4D 1221bc067 PUD 1221bd067 PMD 0
[   90.820042] Oops: 0000 [#1] SMP
[   90.820048] CPU: 0 PID: 2007 Comm: qv4l2 Tainted: G         C        5.15.0-rc4+ #77
[   90.820055] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019
[   90.820059] RIP: 0010:v4l2_prio_change+0xf/0x40 [videodev]
[   90.820096] Code: 48 8b 47 20 8b 40 44 25 ff ff 0f 00 48 8b 04 c5 20 58 44 c0 c3 66 0f 1f 44 00 00 0f 1f 44 00 00 8d 42 ff 83 f8 02 77 21 31 c0 <39> 16 74 20 8d 02 f0 ff 04 87 8b 06 89 c1 83 e9 01 83 f9 02 77 04
[   90.820103] RSP: 0018:ffffb348c142fd70 EFLAGS: 00010246
[   90.820109] RAX: 0000000000000000 RBX: ffff95575fbe2760 RCX: ffffb348c142fe48
[   90.820114] RDX: 0000000000000002 RSI: 0000000000000020 RDI: ffff955740996088
[   90.820118] RBP: 0000000040045644 R08: ffffffffc070da80 R09: 0000000000004000
[   90.820122] R10: 0000000000000000 R11: 0000000000000000 R12: ffff955766725300
[   90.820126] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000044
[   90.820131] FS:  00007f848526b900(0000) GS:ffff9557bbe00000(0000) knlGS:0000000000000000
[   90.820137] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   90.820141] CR2: 0000000000000020 CR3: 00000001221bf000 CR4: 00000000001006f0
[   90.820146] Call Trace:
[   90.820155]  __video_do_ioctl+0x37d/0x3b0 [videodev]
[   90.820189]  video_usercopy+0x188/0x7a0 [videodev]
[   90.820218]  ? v4l_print_control+0x20/0x20 [videodev]
[   90.820247]  ? swake_up_one+0x39/0x70
[   90.820258]  ? rcu_core+0xff/0x2e0
[   90.820267]  ? sched_clock_cpu+0x9/0xa0
[   90.820275]  ? irqtime_account_irq+0x38/0xb0
[   90.820282]  v4l2_ioctl+0x46/0x50 [videodev]

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-mt9m114: use v4l2_find_nearest_size()

Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.

This should address a bug where the wrong resolution was
selected.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-gc2235: use v4l2_find_nearest_size()

Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.

This should address a bug where the wrong resolution was
selected.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-gc0310: use v4l2_find_nearest_size()

Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.

This should address a bug where the wrong resolution was
selected.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2722: use v4l2_find_nearest_size()

Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.

This should address a bug where the wrong resolution was
selected.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp-ov2680: use v4l2_find_nearest_size()

Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.

This should address a bug where the wrong resolution was
selected.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix g_fmt logic

The g_fmt logic is currently broken, as it is not returning
the same imagesize as previoulsy calculated by s_fmt.

Fix it by just re-using whatever it was defined at s_fmt,
if this was called before.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix try_fmt logic

The internal try_fmt logic is not meant to provide everything
that the V4L2 API should provide. Also, it doesn't decrement
the pads that are used only internally by the driver, but aren't
part of the device's output.

Fix it.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: move atomisp_g_fmt_cap()

move atomisp_g_fmt_cap() for it to be after try_fmt, as we'll
re-use try_fmt there.

No functional changes.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix enum_fmt logic

Currently, the enum lists the sensor's native format as a
supported format. However, trying to setup a pipeline using
it doesn't work.

So, exclude such formats from the enum.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix VIDIOC_S_FMT logic

There are several issues on S_FMT implementation:

- it doesn't properly handle pad_h/pad_w;
- it reports a wrong visible size to userspace;
- it allows setting the format to a raw mode, which
  currently causes the pipeline to break.

Address such issues, for it to start working with generic
apps.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: move a debug printf to a better place

The sensor width/height report is alread being printed after
its calculus. The only reason for an extra debug printk is
when dis is used. So, change its message to reflect and move
it to be inside the if checks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: align sizes returned by g_fmt

Repeat the same round logic used inside s_fmt here, for the sake
of sanity.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: TODO: make it updated to the current issues

Now that this driver starting to show signals of real progress,
let's update its TODO list.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: add a default case at __get_frame_info()

The switch() logic there misses a break and a default case.
That makes it more prone to problems as the code change.

Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: max96712: Add basic support for MAX96712 GMSL2 deserializer

Add basic support for Maxim MAX96712 quad GMSL2 deserializers. The
driver is capable of powering on the device and configuring the MIPI
CSI-2 bus in a DPHY 4-lane configuration as well as operating the
internal VTG (Video Timing Generator) and VPG (Video Pattern Generator).

Using these features the driver is able to act as a 1080p @ 30 fps V4L2
video source. Producing either a checkerboard or gradient pattern on the
CSI-2 bus, selectable thru a V4L2 control.

While the driver is useful as-is and have been used to prove the correct
operation of the MAX96712 itself and "downstream" devices using the
MAX96712 as a video source there are a lot of features missing. Most
notably the ability to operate the GMSL bus.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: comment-out JPEG format

This is already disabled on some parts of the code, and trying
to use it with current firmware causes an error:

[   53.799946] atomisp-isp2 0000:00:03.0: can't create streams
[   53.799962] atomisp-isp2 0000:00:03.0: __get_frame_info 1600x900 (padded to 0) returned -22

So, completely disable reporting it.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: report the visible resolution

The atomisp sensors and logic adds an extra pad lines/columns,
called "dvs envelope". It also uses an extra 12 lines/columns
at the sensor for BYT.

As those are not visible to userspace, the V4L2 API should
decrement such values when reporting the current resolution.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: don't print errors for ignored MBUS formats

The bayer formats aren't currently available for userspace
to select: those are marked as IA_CSS_FRAME_FORMAT_RAW and
trying to get them result on binary firmware load errors:

[74625.258097] atomisp-isp2 0000:00:03.0: Using binary isp_preview_var_isp2 (id 22), type 0, mode 1, continuous true
[74625.258146] atomisp-isp2 0000:00:03.0: Seeking for binary failed at:
[74625.258161] CPU: 3 PID: 2792 Comm: v4l2grab Tainted: G         C        5.15.0-rc4+ #77
[74625.258190] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019
[74625.258208] Call Trace:
[74625.258231]  dump_stack_lvl+0x46/0x5a
[74625.258272]  ia_css_binary_find+0xa7d/0xcf0 [atomisp]
[74625.258570]  load_preview_binaries+0x323/0x3c0 [atomisp]
...
[74625.265892] atomisp-isp2 0000:00:03.0: can't create streams
[74625.265937] atomisp-isp2 0000:00:03.0: __get_frame_info 1604x1200 (padded to 0) returned -22
[74625.265962] atomisp-isp2 0000:00:03.0: Can't set format on ISP. Error -22

As those formats are ignored by purpose, it doesn't make any sense
to print a message like:

atomisp_enum_fmt_cap(): format for code 3007 not found.

for those.

Yet, some day it would be interesting to also report the bayer
formats, letting userspace to decode them on a different way.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: report colorspace information

While different sensors could have different colorspaces, the
colorspace V4L2 support didn't exist by the time atomisp driver
was written. So, the sensors won't have any data about that.

So, let's report what Asus T101HA uses (ov2680 sensor).

It may require further changes, if other sensors used on this
driver have different colorspaces.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: properly implement g_fmt

The current logic only initializes pipe->pix after setting up a
pipeline - e. g. after start streaming.

While it makes sense to get the format of the pipeline, when
it is set, this breaks support for generic applications, as they
rely on getting the current sensor format (which is usually the
highest resolution format).

So, implement a call to the sensor's get_fmt, when this is called
before setting up a pipeline.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: better describe get_frame_info issues

When atomisp is used by a normal client, it fails to get
frame info. However, the information is confusing and misleading,
as there are several wrappers for such function, and the error
could be on different places.

So, improve the error log in order to allow narrowing down
where the error is actually occuring.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix enum formats logic

Changeset 374d62e7aa50 ("media: v4l2-subdev: Verify v4l2_subdev_call() pad config argument")
added an extra verification for a pads parameter for enum mbus
format code.

Such change broke atomisp, because now the V4L2 core
refuses to enum MBUS formats if the state is empty.

So, add .which field in order to select the active formats,
in order to make it work again.

While here, improve error messages.

Fixes: 374d62e7aa50 ("media: v4l2-subdev: Verify v4l2_subdev_call() pad config argument")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: add NULL check for asd obtained from atomisp_video_pipe

This is almost a BUG report with RFC patch that just avoids kernel
oopses. Thus, prefixed with [BUG][RFC].

Here is the kernel log after running `v4l2-compliance -d /dev/video4`
with this patch applied:

kern  :err   : [25507.580392] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible)
kern  :warn  : [25507.592343] isys dma store at addr(0xcd408) val(0)
kern  :err   : [25507.592995] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.593685] atomisp-isp2 0000:00:03.0: atomisp_g_input(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.593719] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.593727] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
[omitting 42 same messages]
kern  :err   : [25507.593976] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.594191] atomisp-isp2 0000:00:03.0: atomisp_g_input(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.594449] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
[omitting 43 same messages]
kern  :err   : [25507.594756] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.594779] atomisp-isp2 0000:00:03.0: atomisp_g_ctrl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.594787] atomisp-isp2 0000:00:03.0: atomisp_s_ctrl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.594803] atomisp-isp2 0000:00:03.0: atomisp_camera_g_ext_ctrls(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.594880] atomisp-isp2 0000:00:03.0: atomisp_enum_fmt_cap(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.594915] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.595058] atomisp-isp2 0000:00:03.0: atomisp_try_fmt(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.595089] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.595124] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.595221] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.595241] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.601571] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible)
kern  :warn  : [25507.607496] isys dma store at addr(0xcd408) val(0)
kern  :err   : [25507.608604] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.611988] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible)
kern  :warn  : [25507.617420] isys dma store at addr(0xcd408) val(0)
kern  :err   : [25507.618429] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.618811] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.622193] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible)
kern  :warn  : [25507.627355] isys dma store at addr(0xcd408) val(0)
kern  :err   : [25507.628391] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.631143] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible)
kern  :warn  : [25507.635813] isys dma store at addr(0xcd408) val(0)
kern  :err   : [25507.636489] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.636504] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.636516] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.639111] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible)
kern  :warn  : [25507.646152] isys dma store at addr(0xcd408) val(0)
kern  :err   : [25507.646831] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.646847] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.650079] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible)
kern  :warn  : [25507.657476] isys dma store at addr(0xcd408) val(0)
kern  :err   : [25507.658741] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.658759] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.658771] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC
kern  :err   : [25507.660959] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible)
kern  :warn  : [25507.666665] isys dma store at addr(0xcd408) val(0)
kern  :err   : [25507.667397] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC

[mchehab: fix coding style]
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: Fix up the open v load race

Date: Mon, 06 Nov 2017 23:36:36 +0000

This isn't the ideal final solution but it stops the main problem for now
where an open (often from udev) races the device initialization and we try
and load the firmware twice at the same time. This needless to say doesn't
usually end well.

[kitakar: ported to upstream Kernel]
[mchehab: make comments to use our coding style]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: add Microsoft Surface 3 ACPI vars

Microsoft Surface 3 does not describe CsiPort/CsiLanes in DSDT [1] or
EFI, or at least not desctibed in the forms the current atomisp driver
expects. This results in the default values (port: 0 lanes: 1) to be
used, which does not work.

So, define them ourselves in the driver.

The user-facing camera is AR0330 (2-lane) and the world-facing camera
is OV8835 (4-lane).

According to the portconfigs definition in atomisp_csi_lane_config()
[atomisp_v4l2.c]:

} portconfigs[] = {
/* Tangier/Merrifield available lane configurations */
{ 0x00, { 4, 1, 0 } }, /* 00000 */
{ 0x01, { 3, 1, 0 } }, /* 00001 */
{ 0x02, { 2, 1, 0 } }, /* 00010 */
{ 0x03, { 1, 1, 0 } }, /* 00011 */
{ 0x04, { 2, 1, 2 } }, /* 00100 */
{ 0x08, { 3, 1, 1 } }, /* 01000 */
{ 0x09, { 2, 1, 1 } }, /* 01001 */
{ 0x0a, { 1, 1, 1 } }, /* 01010 */

/* Anniedale/Moorefield only configurations */
{ 0x10, { 4, 2, 0 } }, /* 10000 */
{ 0x11, { 3, 2, 0 } }, /* 10001 */
{ 0x12, { 2, 2, 0 } }, /* 10010 */
{ 0x13, { 1, 2, 0 } }, /* 10011 */
{ 0x14, { 2, 2, 2 } }, /* 10100 */
{ 0x18, { 3, 2, 1 } }, /* 11000 */
{ 0x19, { 2, 2, 1 } }, /* 11001 */
{ 0x1a, { 1, 2, 1 } }, /* 11010 */
};

4-lane camera is always connected to the PRIMARY (port1) port [2]. In
this case, 2-lane camera can be connected to the only SECONDARY (port0)
port.

So, add these data accordingly as the gmin_cfg_var ACPI variables for
Surface 3.

[1] https://github.com/linux-surface/acpidumps/blob/7da48a392b4085c2021952290def1fc28505a643/surface_3/dsdt.dsl#L5879-L6278

[2] Yes, the PRIMARY port is port1 according to atomisp_camera_port
    [atomisp.h]:

enum atomisp_camera_port {
ATOMISP_CAMERA_PORT_SECONDARY,
ATOMISP_CAMERA_PORT_PRIMARY,
ATOMISP_CAMERA_PORT_TERTIARY,
ATOMISP_CAMERA_NR_PORTS
};

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: pci: release_version is now irci_stable_candrpv_0415_20150521_0458

Now that we made atomisp work with firmware version
irci_stable_candrpv_0415_20150521_0458 also for ISP2401, the
release_version for ISP2401 is not irci_ecr-master_20150911_0724
anymore.

So, use the same release_version for both ISP2400 and ISP2401 (i.e.,
irci_stable_candrpv_0415_20150521_0458).

Referred to the following diff to make this patch:
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/staging/media/atomisp/pci/sh_css_firmware.c?id=3c0538fbad9f1d07d588f631e380256d941e3d3a
  ("media: atomisp: get rid of most checks for ISP2401 version")
  changes for file sh_css_firmware.c

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: make fw ver irci_stable_candrpv_0415_20150521_0458 work

This patch removes the unnamed struct `shading` from
`struct sh_css_sp_pipeline` as well as its usage [1].

[1] added on updating css version to irci_master_20150701_0213
    https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch
    ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213")

This patch, together with the 4 patches applied before it revert incompatible
changes in the current css version for ISP2401 (irci_ecr-master_20150911_0724)
back to irci_stable_candrpv_0415_20150521_0458.

Some `struct`s are `sizeof()`ed in sh_css_firmware.c file. So, I guess
issues will happen if these sizes are changed. Therefore, keep them the
same as css version irci_stable_candrpv_0415_20150521_0458 to make atomisp
work for firmware made for such css version since we don't have firmware
made for the current css version.

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: remove polling_mode and subscr_index

This patch removes polling_mode and subscr_index from
`struct virtual_input_system_stream_s` as well as its usage [1]. Note
that for subscr_index, only the definition were removed because it was
not used anywhere.

[1] added on updating css version to irci_master_20150701_0213
    https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch
    ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213")

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: remove struct ia_css_isp_parameter xnr3

This patch removes `struct ia_css_isp_parameter xnr3` from
`struct ia_css_memory_offsets` as well as its usage [1].

[1] added on updating css version to irci_master_20150701_0213
    https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch
    ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213")

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: remove struct ia_css_isp_parameter

This patch removes `struct ia_css_isp_parameter sc` from
`struct ia_css_config_memory_offsets` as well as its usage [1].

[1] added on updating css version to irci_master_20150701_0213
    https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch
    ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213")

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: drop luma_only, input_yuv and input_raw from ISP2401

This patch removes luma_only, input_yuv and input_raw from
`struct ia_css_binary_info` as well as its usage [1]. Note that for
input_yuv and input_raw, only the definitions were removed because these
were not used anywhere.

[1] added on updating css version to irci_master_20150701_0213
    https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch
    ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213")

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix ifdefs in sh_css.c

 ## `if (pipe->stream->config.mode == IA_CSS_INPUT_MODE_TPG) {` case

The intel-aero atomisp has `#if defined(IS_ISP_2400_SYSTEM)` [1]. It is
to be defined in the following two places [2]:

  - css/hive_isp_css_common/system_global.h
  - css/css_2401_csi2p_system/system_global.h

and the former file is to be included on ISP2400 devices, too. So, it
is to be defined for both ISP2400 and ISP2401 devices.

Because the upstreamed atomisp driver now supports only ISP2400 and
ISP2401, just remove the ISP version test again. This matches the other
upstream commits like 3c0538fbad9f ("media: atomisp: get rid of most
checks for ISP2401 version").

While here, moved the comment for define GP_ISEL_TPG_MODE to the
appropriate place.

[1] https://github.com/intel-aero/linux-kernel/blob/a1b673258feb915268377275130c5c5df0eafc82/drivers/media/pci/atomisp/css/sh_css.c#L552-L558
[2] https://github.com/intel-aero/linux-kernel/search?q=IS_ISP_2400_SYSTEM

  ## `isys_stream_descr->polling_mode` case

This does not exist on the intel-aero atomisp. This is because it is
based on css version irci_stable_candrpv_0415_20150521_0458.

On the other hand, the upstreamed atomisp is based on the following css
version depending on the ISP version using ifdefs:

  - ISP2400: irci_stable_candrpv_0415_20150521_0458
  - ISP2401: irci_master_20150911_0724

The `isys_stream_descr->polling_mode` usage was added on updating css
version to irci_master_20150701_0213 [3].

So, it is not a ISP version specific thing, but css version specific
thing. Because the upstreamed atomisp driver uses irci_master_20150911_0724
for ISP2401, re-add the ISP version check for now.

I say "for now" because ISP2401 should eventually use the same css
version with ISP2400 (i.e., irci_stable_candrpv_0415_20150521_0458)

[3] https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch
    ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213")
    Link to Intel's Android kernel patch.

 ## `coord = &me->config.internal_frame_origin_bqs_on_sctbl;` case

it was added on commit 4f744a573db3 ("media: atomisp: make
sh_css_sp_init_pipeline() ISP version independent") for ISP2401. Because
the upstreamed atomisp for the ISP2401 part is based on
irci_master_20150911_0724, hence the difference.

Because the upstreamed atomisp driver uses irci_master_20150911_0724
for ISP2401, revert the test back to `if (IS_ISP2401)`.

Fixes: 27333dadef57 ("media: atomisp: adjust some code at sh_css that could be broken")
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: use IA_CSS_ERROR() for error messages in sh_css_mipi.c

Some debug messages for error cases (messages contain "error: ") use
IA_CSS_DEBUG_TRACE_PRIVATE debug level. This causes these error messages
not to appear unless users raise debug output level to 7 or higher (using
module parameter, dbg_level=7).

So, use IA_CSS_DEBUG_ERROR debug level (dbg_level=1) instead considering
that these are error messages. There is already a macro IA_CSS_ERROR()
for this use case. Let's use it. It automatically appends "error: " at
the beginning and a newline to a message. Therefore, we can remove them
from these messages.

While here, remove the unnecessary newline from one IA_CSS_ERROR()
occurrence in the same file.

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix inverted error check for ia_css_mipi_is_source_port_valid()

The function ia_css_mipi_is_source_port_valid() returns true if the port
is valid. So, we can't use the existing err variable as is.

To fix this issue while reusing that variable, invert the return value
when assigning it to the variable.

Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version")
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: do not use err var when checking port validity for ISP2400

Currently, the `port >= N_CSI_PORTS || err` checks for ISP2400 are always
evaluated as true because the err variable is set to `-EINVAL` on
declaration but the variable is never used until the evaluation.

Looking at the diff of commit 3c0538fbad9f ("media: atomisp: get rid of
most checks for ISP2401 version"), the `port >= N_CSI_PORTS` check is
for ISP2400 and the err variable check is for ISP2401. Fix this issue
by adding ISP version test there accordingly.

Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version")
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix inverted logic in buffers_needed()

When config.mode is IA_CSS_INPUT_MODE_BUFFERED_SENSOR, it rather needs
buffers. Fix it by inverting the return value.

Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version")
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix punit_ddr_dvfs_enable() argument for mrfld_power up case

When comparing with intel-aero atomisp [1], it looks like
punit_ddr_dvfs_enable() should take `false` as an argument on mrfld_power
up case.

Code from the intel-aero kernel [1]:

        int atomisp_mrfld_power_down(struct atomisp_device *isp)
        {
        [...]
/*WA:Enable DVFS*/
if (IS_CHT)
punit_ddr_dvfs_enable(true);

        int atomisp_mrfld_power_up(struct atomisp_device *isp)
        {
        [...]
/*WA for PUNIT, if DVFS enabled, ISP timeout observed*/
if (IS_CHT)
punit_ddr_dvfs_enable(false);

This patch fixes the inverted argument as per the intel-aero code, as
well as its comment. While here, fix space issues for comments in
atomisp_mrfld_power().

Note that it does not seem to be possible to unify the up/down cases for
punit_ddr_dvfs_enable(), i.e., we can't do something like the following:

        if (IS_CHT)
punit_ddr_dvfs_enable(!enable);

because according to the intel-aero code [1], the DVFS is disabled
before "writing 0x0 to ISPSSPM0 bit[1:0]" and the DVFS is enabled after
"writing 0x3 to ISPSSPM0 bit[1:0]".

[1] https://github.com/intel-aero/linux-kernel/blob/a1b673258feb915268377275130c5c5df0eafc82/drivers/media/pci/atomisp/atomisp_driver/atomisp_v4l2.c#L431-L514

Fixes: 0f441fd70b1e ("media: atomisp: simplify the power down/up code")
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: add missing media_device_cleanup() in atomisp_unregister_entities()

After the commit 9832e155f1ed ("[media] media-device: split media
initialization and registration"), calling media_device_cleanup()
is needed it seems. However, currently it is missing for the module
unload path.

Note that for the probe failure path, it is already added in
atomisp_register_entities().

This patch adds the missing call of media_device_cleanup() in
atomisp_unregister_entities().

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dw9768: activate runtime PM and turn off device

When dw9768 working with ACPI systems, the dw9768 was turned
by i2c-core during probe, driver need activate the PM runtime
and ask runtime PM to turn off the device.

Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: ccs: replace snprintf in show functions with sysfs_emit

show() should not use snprintf() when formatting the value to be
returned to user space.

Fix the following coccicheck warning:
drivers/media/i2c/ccs/ccs-core.c:3761: WARNING: use scnprintf or sprintf.

Signed-off-by: Qing Wang <wangqing@vivo.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: ipu3-cio2: fix error code in cio2_bridge_connect_sensor()

Return -ENODEV if acpi_get_physical_device_location() fails.  Don't
return success.

Fixes: 485aa3df0dff ("media: ipu3-cio2: Parse sensor orientation and rotation")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Scally <djrscally@gmail.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: ipu3-imgu: clarify the limitation of grid config

There are some grid configuration limitations for ImgU, which was
not described clearly in current uAPI header file, add the description
to help user to set the grid configuration correctly.

Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: get rid of two unused functions

Those cause build to break with -Werror with clang-12:

drivers/staging/media/atomisp/pci/hive_isp_css_common/host/gdc.c:121:24: error: unused function 'gdc_reg_load' [-Werror,-Wunused-function]
drivers/staging/media/atomisp/pci/isp/kernels/raw/raw_1.0/ia_css_raw.host.c:33:1: error: unused function 'sh_css_elems_bytes_from_info' [-Werror,-Wunused-function]

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: stm32-dma2d: STM32 DMA2D driver

This V4L2 subdev m2m driver enables Chrom-Art Accelerator unit
of STMicroelectronics STM32 SoC series.

Currently support r2m, m2m, m2m_pfc functions.
- r2m, Filling a part or the whole of a destination image with a specific
  color.
- m2m, Copying a part or the whole of a source image into a part or the
  whole of a destination.
- m2m_pfc, Copying a part or the whole of a source image into a part or the
  whole of a destination image with a pixel format conversion.

[hverkuil: fix typo in commit log]

Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-ctrls: Add RGB color effects control

Add V4L2_COLORFX_SET_RGB color effects control, V4L2_CID_COLORFX_RGB
for RGB color setting.

with two mirror changes:
- change 0xFFFFFF to 0xffffff
- fix comments 2^24 to 2^24 - 1

[hverkuil: dropped spaces around + with V4L2_CID_BASE for consistency]

Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-ctrls: Add V4L2_CID_COLORFX_CBCR max setting

The max of V4L2_CID_COLORFX_CBCR is 0xffff, so add it to v4l2_ctrl_fill()
to sure not beyond that.

Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: videobuf2: Fix the size printk format

Since the type of parameter size is unsigned long,
it should printk by %lu, instead of %ld, fix it.

Fixes: 7952be9b6ece ("media: drivers/media/common/videobuf2: rename from videobuf")
Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-mem2mem: add v4l2_m2m_get_unmapped_area for no-mmu platform

For platforms without MMU the m2m provides a helper method
v4l2_m2m_get_unmapped_area(), The mmap() routines will call
this to get a proposed address for the mapping.

More detailed information about get_unmapped_area can be found in
Documentation/nommu-mmap.txt

Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: media: add document for STM32 DMA2d bindings

This adds documentation of device tree bindings for the STM32 DMA2D

Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add stm32-dma2d description

add stm32-dma2d description for dma2d driver

Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Linux 5.16-rc1

kconfig: Add support for -Wimplicit-fallthrough

Add Kconfig support for -Wimplicit-fallthrough for both GCC and Clang.

The compiler option is under configuration CC_IMPLICIT_FALLTHROUGH,
which is enabled by default.

Special thanks to Nathan Chancellor who fixed the Clang bug[1][2]. This
bugfix only appears in Clang 14.0.0, so older versions still contain
the bug and -Wimplicit-fallthrough won't be enabled for them, for now.

This concludes a long journey and now we are finally getting rid
of the unintentional fallthrough bug-class in the kernel, entirely. :)

Link: https://github.com/llvm/llvm-project/commit/9ed4a94d6451046a51ef393cd62f00710820a7e8
Link: https://bugs.llvm.org/show_bug.cgi?id=51094
Link: https://github.com/KSPP/linux/issues/115
Link: https://github.com/ClangBuiltLinux/linux/issues/236
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'xfs-5.16-merge-5' of git://git./fs/xfs/xfs-linux

Pull xfs cleanups from Darrick Wong:
 "The most 'exciting' aspect of this branch is that the xfsprogs
  maintainer and I have worked through the last of the code
  discrepancies between kernel and userspace libxfs such that there are
  no code differences between the two except for #includes.

  IOWs, diff suffices to demonstrate that the userspace tools behave the
  same as the kernel, and kernel-only bits are clearly marked in the
  /kernel/ source code instead of just the userspace source.

  Summary:

   - Clean up open-coded swap() calls.

   - A little bit of #ifdef golf to complete the reunification of the
     kernel and userspace libxfs source code"

* tag 'xfs-5.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  xfs: sync xfs_btree_split macros with userspace libxfs
  xfs: #ifdef out perag code for userspace
  xfs: use swap() to make dabtree code cleaner

Merge tag 'for-5.16/parisc-3' of git://git./linux/kernel/git/deller/parisc-linux

Pull more parisc fixes from Helge Deller:
 "Fix a build error in stracktrace.c, fix resolving of addresses to
  function names in backtraces, fix single-stepping in assembly code and
  flush userspace pte's when using set_pte_at()"

* tag 'for-5.16/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc/entry: fix trace test in syscall exit path
  parisc: Flush kernel data mapping in set_pte_at() when installing pte for user page
  parisc: Fix implicit declaration of function '__kernel_text_address'
  parisc: Fix backtrace to always include init funtion names

Merge tag 'sh-for-5.16' of git://git.libc.org/linux-sh

Pull arch/sh updates from Rich Felker.

* tag 'sh-for-5.16' of git://git.libc.org/linux-sh:
  sh: pgtable-3level: Fix cast to pointer from integer of different size
  sh: fix READ/WRITE redefinition warnings
  sh: define __BIG_ENDIAN for math-emu
  sh: math-emu: drop unused functions
  sh: fix kconfig unmet dependency warning for FRAME_POINTER
  sh: Cleanup about SPARSE_IRQ
  sh: kdump: add some attribute to function
  maple: fix wrong return value of maple_bus_init().
  sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/
  sh: boot: add intermediate vmlinux.bin* to targets instead of extra-y
  sh: boards: Fix the cacography in irq.c
  sh: check return code of request_irq
  sh: fix trivial misannotations

Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:

 - Fix early_iounmap

 - Drop cc-option fallbacks for architecture selection

* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 9156/1: drop cc-option fallbacks for architecture selection
  ARM: 9155/1: fix early early_iounmap()

Merge tag 'devicetree-fixes-for-5.16-1' of git://git./linux/kernel/git/robh/linux

Pull devicetree fixes from Rob Herring:

 - Two fixes due to DT node name changes on Arm, Ltd. boards

 - Treewide rename of Ingenic CGU headers

 - Update ST email addresses

 - Remove Netlogic DT bindings

 - Dropping few more cases of redundant 'maxItems' in schemas

 - Convert toshiba,tc358767 bridge binding to schema

* tag 'devicetree-fixes-for-5.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  dt-bindings: watchdog: sunxi: fix error in schema
  bindings: media: venus: Drop redundant maxItems for power-domain-names
  dt-bindings: Remove Netlogic bindings
  clk: versatile: clk-icst: Ensure clock names are unique
  of: Support using 'mask' in making device bus id
  dt-bindings: treewide: Update @st.com email address to @foss.st.com
  dt-bindings: media: Update maintainers for st,stm32-hwspinlock.yaml
  dt-bindings: media: Update maintainers for st,stm32-cec.yaml
  dt-bindings: mfd: timers: Update maintainers for st,stm32-timers
  dt-bindings: timer: Update maintainers for st,stm32-timer
  dt-bindings: i2c: imx: hardware do not restrict clock-frequency to only 100 and 400 kHz
  dt-bindings: display: bridge: Convert toshiba,tc358767.txt to yaml
  dt-bindings: Rename Ingenic CGU headers to ingenic,*.h

Merge tag 'timers-urgent-2021-11-14' of git://git./linux/kernel/git/tip/tip

Pull timer fix from Thomas Gleixner:
 "A single fix for POSIX CPU timers to address a problem where POSIX CPU
  timer delivery stops working for a new child task because
  copy_process() copies state information which is only valid for the
  parent task"

* tag 'timers-urgent-2021-11-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  posix-cpu-timers: Clear task::posix_cputimers_work in copy_process()

Merge tag 'irq-urgent-2021-11-14' of git://git./linux/kernel/git/tip/tip

Pull irq fixes from Thomas Gleixner:
 "A set of fixes for the interrupt subsystem

  Core code:

   - A regression fix for the Open Firmware interrupt mapping code where
     a interrupt controller property in a node caused a map property in
     the same node to be ignored.

  Interrupt chip drivers:

   - Workaround a limitation in SiFive PLIC interrupt chip which
     silently ignores an EOI when the interrupt line is masked.

   - Provide the missing mask/unmask implementation for the CSKY MP
     interrupt controller.

  PCI/MSI:

   - Prevent a use after free when PCI/MSI interrupts are released by
     destroying the sysfs entries before freeing the memory which is
     accessed in the sysfs show() function.

   - Implement a mask quirk for the Nvidia ION AHCI chip which does not
     advertise masking capability despite implementing it. Even worse
     the chip comes out of reset with all MSI entries masked, which due
     to the missing masking capability never get unmasked.

   - Move the check which prevents accessing the MSI[X] masking for XEN
     back into the low level accessors. The recent consolidation missed
     that these accessors can be invoked from places which do not have
     that check which broke XEN. Move them back to he original place
     instead of sprinkling tons of these checks all over the code"

* tag 'irq-urgent-2021-11-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  of/irq: Don't ignore interrupt-controller when interrupt-map failed
  irqchip/sifive-plic: Fixup EOI failed when masked
  irqchip/csky-mpintc: Fixup mask/unmask implementation
  PCI/MSI: Destroy sysfs before freeing entries
  PCI: Add MSI masking quirk for Nvidia ION AHCI
  PCI/MSI: Deal with devices lying about their MSI mask capability
  PCI/MSI: Move non-mask check back into low level accessors

Merge tag 'locking-urgent-2021-11-14' of git://git./linux/kernel/git/tip/tip

Pull x86 static call update from Thomas Gleixner:
 "A single fix for static calls to make the trampoline patching more
  robust by placing explicit signature bytes after the call trampoline
  to prevent patching random other jumps like the CFI jump table
  entries"

* tag 'locking-urgent-2021-11-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  static_call,x86: Robustify trampoline patching

Merge tag 'sched_urgent_for_v5.16_rc1' of git://git./linux/kernel/git/tip/tip

Pull scheduler fixes from Borislav Petkov:

 - Avoid touching ~100 config files in order to be able to select the
   preemption model

 - clear cluster CPU masks too, on the CPU unplug path

 - prevent use-after-free in cfs

 - Prevent a race condition when updating CPU cache domains

 - Factor out common shared part of smp_prepare_cpus() into a common
   helper which can be called by both baremetal and Xen, in order to fix
   a booting of Xen PV guests

* tag 'sched_urgent_for_v5.16_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  preempt: Restore preemption model selection configs
  arch_topology: Fix missing clear cluster_cpumask in remove_cpu_topology()
  sched/fair: Prevent dead task groups from regaining cfs_rq's
  sched/core: Mitigate race cpus_share_cache()/update_top_cache_domain()
  x86/smp: Factor out parts of native_smp_prepare_cpus()

Merge tag 'perf_urgent_for_v5.16_rc1' of git://git./linux/kernel/git/tip/tip

Pull perf fixes from Borislav Petkov:

 - Prevent unintentional page sharing by checking whether a page
   reference to a PMU samples page has been acquired properly before
   that

 - Make sure the LBR_SELECT MSR is saved/restored too

 - Reset the LBR_SELECT MSR when resetting the LBR PMU to clear any
   residual data left

* tag 'perf_urgent_for_v5.16_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/core: Avoid put_page() when GUP fails
  perf/x86/vlbr: Add c->flags to vlbr event constraints
  perf/x86/lbr: Reset LBR_SELECT during vlbr reset

Merge tag 'x86_urgent_for_v5.16_rc1' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Borislav Petkov:

 - Add the model number of a new, Raptor Lake CPU, to intel-family.h

 - Do not log spurious corrected MCEs on SKL too, due to an erratum

 - Clarify the path of paravirt ops patches upstream

 - Add an optimization to avoid writing out AMX components to sigframes
   when former are in init state

* tag 'x86_urgent_for_v5.16_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/cpu: Add Raptor Lake to Intel family
  x86/mce: Add errata workaround for Skylake SKX37
  MAINTAINERS: Add some information to PARAVIRT_OPS entry
  x86/fpu: Optimize out sigframe xfeatures when in init state

Merge tag 'perf-tools-for-v5.16-2021-11-13' of git://git./linux/kernel/git/acme/linux

Pull more perf tools updates from Arnaldo Carvalho de Melo:
 "Hardware tracing:

   - ARM:
      * Print the size of the buffer size consistently in hexadecimal in
        ARM Coresight.
      * Add Coresight snapshot mode support.
      * Update --switch-events docs in 'perf record'.
      * Support hardware-based PID tracing.
      * Track task context switch for cpu-mode events.

   - Vendor events:
      * Add metric events JSON file for power10 platform

  perf test:

   - Get 'perf test' unit tests closer to kunit.

   - Topology tests improvements.

   - Remove bashisms from some tests.

  perf bench:

   - Fix memory leak of perf_cpu_map__new() in the futex benchmarks.

  libbpf:

   - Add some more weak libbpf functions o allow building with the
     libbpf versions, old ones, present in distros.

  libbeauty:

   - Translate [gs]setsockopt 'level' argument integer values to
     strings.

  tools headers UAPI:

   - Sync futex_waitv, arch prctl, sound, i195_drm and msr-index files
     with the kernel sources.

  Documentation:

   - Add documentation to 'struct symbol'.

   - Synchronize the definition of enum perf_hw_id with code in
     tools/perf/design.txt"

* tag 'perf-tools-for-v5.16-2021-11-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (67 commits)
  perf tests: Remove bash constructs from stat_all_pmu.sh
  perf tests: Remove bash construct from record+zstd_comp_decomp.sh
  perf test: Remove bash construct from stat_bpf_counters.sh test
  perf bench futex: Fix memory leak of perf_cpu_map__new()
  tools arch x86: Sync the msr-index.h copy with the kernel sources
  tools headers UAPI: Sync drm/i915_drm.h with the kernel sources
  tools headers UAPI: Sync sound/asound.h with the kernel sources
  tools headers UAPI: Sync linux/prctl.h with the kernel sources
  tools headers UAPI: Sync arch prctl headers with the kernel sources
  perf tools: Add more weak libbpf functions
  perf bpf: Avoid memory leak from perf_env__insert_btf()
  perf symbols: Factor out annotation init/exit
  perf symbols: Bit pack to save a byte
  perf symbols: Add documentation to 'struct symbol'
  tools headers UAPI: Sync files changed by new futex_waitv syscall
  perf test bpf: Use ARRAY_CHECK() instead of ad-hoc equivalent, addressing array_size.cocci warning
  perf arm-spe: Support hardware-based PID tracing
  perf arm-spe: Save context ID in record
  perf arm-spe: Update --switch-events docs in 'perf record'
  perf arm-spe: Track task context switch for cpu-mode events
  ...

Merge tag 'irqchip-fixes-5.16-1' of git://git./linux/kernel/git/maz/arm-platforms into irq/urgent

Pull irqchip fixes from Marc Zyngier:

  - Address an issue with the SiFive PLIC being unable to EOI
    a masked interrupt

  - Move the disable/enable methods in the CSky mpintc to
    mask/unmask

  - Fix a regression in the OF irq code where an interrupt-controller
    property in the same node as an interrupt-map property would get
    ignored

Link: https://lore.kernel.org/all/20211112173459.4015233-1-maz@kernel.org

Merge tag 'zstd-for-linus-v5.16' of git://github.com/terrelln/linux

Pull zstd update from Nick Terrell:
 "Update to zstd-1.4.10.

  Add myself as the maintainer of zstd and update the zstd version in
  the kernel, which is now 4 years out of date, to a much more recent
  zstd release. This includes bug fixes, much more extensive fuzzing,
  and performance improvements. And generates the kernel zstd
  automatically from upstream zstd, so it is easier to keep the zstd
  verison up to date, and we don't fall so far out of date again.

  This includes 5 commits that update the zstd library version:

   - Adds a new kernel-style wrapper around zstd.

     This wrapper API is functionally equivalent to the subset of the
     current zstd API that is currently used. The wrapper API changes to
     be kernel style so that the symbols don't collide with zstd's
     symbols. The update to zstd-1.4.10 maintains the same API and
     preserves the semantics, so that none of the callers need to be
     updated. All callers are updated in the commit, because there are
     zero functional changes.

   - Adds an indirection for `lib/decompress_unzstd.c` so it doesn't
     depend on the layout of `lib/zstd/` to include every source file.
     This allows the next patch to be automatically generated.

   - Imports the zstd-1.4.10 source code. This commit is automatically
     generated from upstream zstd (https://github.com/facebook/zstd).

   - Adds me (terrelln@fb.com) as the maintainer of `lib/zstd`.

   - Fixes a newly added build warning for clang.

  The discussion around this patchset has been pretty long, so I've
  included a FAQ-style summary of the history of the patchset, and why
  we are taking this approach.

  Why do we need to update?
  -------------------------

  The zstd version in the kernel is based off of zstd-1.3.1, which is
  was released August 20, 2017. Since then zstd has seen many bug fixes
  and performance improvements. And, importantly, upstream zstd is
  continuously fuzzed by OSS-Fuzz, and bug fixes aren't backported to
  older versions. So the only way to sanely get these fixes is to keep
  up to date with upstream zstd.

  There are no known security issues that affect the kernel, but we need
  to be able to update in case there are. And while there are no known
  security issues, there are relevant bug fixes. For example the problem
  with large kernel decompression has been fixed upstream for over 2
  years [1]

  Additionally the performance improvements for kernel use cases are
  significant. Measured for x86_64 on my Intel i9-9900k @ 3.6 GHz:

   - BtrFS zstd compression at levels 1 and 3 is 5% faster

   - BtrFS zstd decompression+read is 15% faster

   - SquashFS zstd decompression+read is 15% faster

   - F2FS zstd compression+write at level 3 is 8% faster

   - F2FS zstd decompression+read is 20% faster

   - ZRAM decompression+read is 30% faster

   - Kernel zstd decompression is 35% faster

   - Initramfs zstd decompression+build is 5% faster

  On top of this, there are significant performance improvements coming
  down the line in the next zstd release, and the new automated update
  patch generation will allow us to pull them easily.

  How is the update patch generated?
  ----------------------------------

  The first two patches are preparation for updating the zstd version.
  Then the 3rd patch in the series imports upstream zstd into the
  kernel. This patch is automatically generated from upstream. A script
  makes the necessary changes and imports it into the kernel. The
  changes are:

   - Replace all libc dependencies with kernel replacements and rewrite
     includes.

   - Remove unncessary portability macros like: #if defined(_MSC_VER).

   - Use the kernel xxhash instead of bundling it.

  This automation gets tested every commit by upstream's continuous
  integration. When we cut a new zstd release, we will submit a patch to
  the kernel to update the zstd version in the kernel.

  The automated process makes it easy to keep the kernel version of zstd
  up to date. The current zstd in the kernel shares the guts of the
  code, but has a lot of API and minor changes to work in the kernel.
  This is because at the time upstream zstd was not ready to be used in
  the kernel envrionment as-is. But, since then upstream zstd has
  evolved to support being used in the kernel as-is.

  Why are we updating in one big patch?
  -------------------------------------

  The 3rd patch in the series is very large. This is because it is
  restructuring the code, so it both deletes the existing zstd, and
  re-adds the new structure. Future updates will be directly
  proportional to the changes in upstream zstd since the last import.
  They will admittidly be large, as zstd is an actively developed
  project, and has hundreds of commits between every release. However,
  there is no other great alternative.

  One option ruled out is to replay every upstream zstd commit. This is
  not feasible for several reasons:

   - There are over 3500 upstream commits since the zstd version in the
     kernel.

   - The automation to automatically generate the kernel update was only
     added recently, so older commits cannot easily be imported.

   - Not every upstream zstd commit builds.

   - Only zstd releases are "supported", and individual commits may have
     bugs that were fixed before a release.

  Another option to reduce the patch size would be to first reorganize
  to the new file structure, and then apply the patch. However, the
  current kernel zstd is formatted with clang-format to be more
  "kernel-like". But, the new method imports zstd as-is, without
  additional formatting, to allow for closer correlation with upstream,
  and easier debugging. So the patch wouldn't be any smaller.

  It also doesn't make sense to import upstream zstd commit by commit
  going forward. Upstream zstd doesn't support production use cases
  running of the development branch. We have a lot of post-commit
  fuzzing that catches many bugs, so indiviudal commits may be buggy,
  but fixed before a release. So going forward, I intend to import every
  (important) zstd release into the Kernel.

  So, while it isn't ideal, updating in one big patch is the only patch
  I see forward.

  Who is responsible for this code?
  ---------------------------------

  I am. This patchset adds me as the maintainer for zstd. Previously,
  there was no tree for zstd patches. Because of that, there were
  several patches that either got ignored, or took a long time to merge,
  since it wasn't clear which tree should pick them up. I'm officially
  stepping up as maintainer, and setting up my tree as the path through
  which zstd patches get merged. I'll make sure that patches to the
  kernel zstd get ported upstream, so they aren't erased when the next
  version update happens.

  How is this code tested?
  ------------------------

  I tested every caller of zstd on x86_64 (BtrFS, ZRAM, SquashFS, F2FS,
  Kernel, InitRAMFS). I also tested Kernel & InitRAMFS on i386 and
  aarch64. I checked both performance and correctness.

  Also, thanks to many people in the community who have tested these
  patches locally.

  Lastly, this code will bake in linux-next before being merged into
  v5.16.

  Why update to zstd-1.4.10 when zstd-1.5.0 has been released?
  ------------------------------------------------------------

  This patchset has been outstanding since 2020, and zstd-1.4.10 was the
  latest release when it was created. Since the update patch is
  automatically generated from upstream, I could generate it from
  zstd-1.5.0.

  However, there were some large stack usage regressions in zstd-1.5.0,
  and are only fixed in the latest development branch. And the latest
  development branch contains some new code that needs to bake in the
  fuzzer before I would feel comfortable releasing to the kernel.

  Once this patchset has been merged, and we've released zstd-1.5.1, we
  can update the kernel to zstd-1.5.1, and exercise the update process.

  You may notice that zstd-1.4.10 doesn't exist upstream. This release
  is an artifical release based off of zstd-1.4.9, with some fixes for
  the kernel backported from the development branch. I will tag the
  zstd-1.4.10 release after this patchset is merged, so the Linux Kernel
  is running a known version of zstd that can be debugged upstream.

  Why was a wrapper API added?
  ----------------------------

  The first versions of this patchset migrated the kernel to the
  upstream zstd API. It first added a shim API that supported the new
  upstream API with the old code, then updated callers to use the new
  shim API, then transitioned to the new code and deleted the shim API.
  However, Cristoph Hellwig suggested that we transition to a kernel
  style API, and hide zstd's upstream API behind that. This is because
  zstd's upstream API is supports many other use cases, and does not
  follow the kernel style guide, while the kernel API is focused on the
  kernel's use cases, and follows the kernel style guide.

  Where is the previous discussion?
  ---------------------------------

  Links for the discussions of the previous versions of the patch set
  below. The largest changes in the design of the patchset are driven by
  the discussions in v11, v5, and v1. Sorry for the mix of links, I
  couldn't find most of the the threads on lkml.org"

Link: https://lkml.org/lkml/2020/9/29/27
Link: https://www.spinics.net/lists/linux-crypto/msg58189.html
Link: https://lore.kernel.org/linux-btrfs/20210430013157.747152-1-nickrterrell@gmail.com/
Link: https://lore.kernel.org/lkml/20210426234621.870684-2-nickrterrell@gmail.com/
Link: https://lore.kernel.org/linux-btrfs/20210330225112.496213-1-nickrterrell@gmail.com/
Link: https://lore.kernel.org/linux-f2fs-devel/20210326191859.1542272-1-nickrterrell@gmail.com/
Link: https://lkml.org/lkml/2020/12/3/1195
Link: https://lkml.org/lkml/2020/12/2/1245
Link: https://lore.kernel.org/linux-btrfs/20200916034307.2092020-1-nickrterrell@gmail.com/
Link: https://www.spinics.net/lists/linux-btrfs/msg105783.html
Link: https://lkml.org/lkml/2020/9/23/1074
Link: https://www.spinics.net/lists/linux-btrfs/msg105505.html
Link: https://lore.kernel.org/linux-btrfs/20200916034307.2092020-1-nickrterrell@gmail.com/
Signed-off-by: Nick Terrell <terrelln@fb.com>
Tested By: Paul Jones <paul@pauljones.id.au>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v13.0.0 on x86-64
Tested-by: Jean-Denis Girard <jd.girard@sysnux.pf>
* tag 'zstd-for-linus-v5.16' of git://github.com/terrelln/linux:
  lib: zstd: Add cast to silence clang's -Wbitwise-instead-of-logical
  MAINTAINERS: Add maintainer entry for zstd
  lib: zstd: Upgrade to latest upstream zstd version 1.4.10
  lib: zstd: Add decompress_sources.h for decompress_unzstd
  lib: zstd: Add kernel-specific API

Merge tag 'virtio-mem-for-5.16' of git://github.com/davidhildenbrand/linux

Pull virtio-mem update from David Hildenbrand:
 "Support the VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature in virtio-mem,
  now that "accidential" access to logically unplugged memory inside
  added Linux memory blocks is no longer possible, because we:

   - Removed /dev/kmem in commit bbcd53c96071 ("drivers/char: remove
     /dev/kmem for good")

   - Disallowed access to virtio-mem device memory via /dev/mem in
     commit 2128f4e21aa ("virtio-mem: disallow mapping virtio-mem memory
     via /dev/mem")

   - Sanitized access to virtio-mem device memory via /proc/kcore in
     commit 0daa322b8ff9 ("fs/proc/kcore: don't read offline sections,
     logically offline pages and hwpoisoned pages")

   - Sanitized access to virtio-mem device memory via /proc/vmcore in
     commit ce2814622e84 ("virtio-mem: kdump mode to sanitize
     /proc/vmcore access")

  The new VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature that will be
  required by some hypervisors implementing virtio-mem in the near
  future, so let's support it now that we safely can"

* tag 'virtio-mem-for-5.16' of git://github.com/davidhildenbrand/linux:
  virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE