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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Changeset 374d62e7aa ("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: 374d62e7aa ("media: v4l2-subdev: Verify v4l2_subdev_call() pad config argument")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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>
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>
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>
## `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 3c0538fbad ("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] a1b673258f/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 4f744a573d ("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: 27333dadef ("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>
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>
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: 3c0538fbad ("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>
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 3c0538fbad ("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: 3c0538fbad ("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>
When config.mode is IA_CSS_INPUT_MODE_BUFFERED_SENSOR, it rather needs
buffers. Fix it by inverting the return value.
Fixes: 3c0538fbad ("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>
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] a1b673258f/drivers/media/pci/atomisp/atomisp_driver/atomisp_v4l2.c (L431-L514)
Fixes: 0f441fd70b ("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>
After the commit 9832e155f1 ("[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: a49d25364d ("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>
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>
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>
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>
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>
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>
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>
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>
Since the type of parameter size is unsigned long,
it should printk by %lu, instead of %ld, fix it.
Fixes: 7952be9b6e ("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>
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>
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>
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: 9ed4a94d64 [1]
Link: https://bugs.llvm.org/show_bug.cgi?id=51094 [2]
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>
* Clean up open-coded swap() calls.
* A little bit of #ifdef golf to complete the reunification of the
kernel and userspace libxfs source code.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmGNT1IACgkQ+H93GTRK
tOucKA//Qk2NX3QBm/8pCrFE5V+eqooPANhZmzeviJCN/6++jcNOy0f+YK6JXVRC
U2WdotHFH5fF6lsDkzNtMPHZ8JMZmOfEiPx5CGFiWT5iUW7FbLkROHm7GFtbwMoH
qm3Lt7PbdSzJqTuOTvaGCw1xWkjDXMLdsdFM7mx3JO5zT9a/fCqjjmyR2Kl0qcSP
RzfruVe20wUka2BeaXfZzSasgfLswratkU4xsiNiwA37yQaldzhrg8fg6uP3OSYi
dkWFXi6WdWwQzARnjWNPwigUwA3xVaYgV+I6+ME0DYsUBvywZzUg3pkowhRAHyA9
kv86L5Zt5K7kQcVqyd+lIvIuAcGrOZ9hA18PIXnwahLBqmjcqAJoF9XhTTZDMD4J
LfujGMrf7DSDcf0vH8G9wlQQthsPGUOoFia5rr8MhdVVNee/b1Qvwsh7kmyg0DOK
9WuNQxGPd7s+X+kwdmGrK7E6fqyPwEfC43l8wtCiBIyGz6QcorwD7kH9DGzv5xGF
NX7WQeKvcaoXn1XVfonb0YgdVOnbyqK4AiY3Po1Ood3IxGyiLGCgDnusvYu+C9/r
T0rRMbljkX1lUKqfzGkg2egOKPR+8RFgFKrKNSXUkDxl8TFLRd3ZObowPPlohq1I
9lIIirip5UFYRv+7srDU1oZPWkvwkpJmaMFgagD3w+OWdo6zwao=
=wsFu
-----END PGP SIGNATURE-----
Merge tag 'xfs-5.16-merge-5' of git://git.kernel.org/pub/scm/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
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().
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCYZAyIAAKCRD3ErUQojoP
X8zUAQCV4fijXlUEOnZorH42QsSvs1SowHXu2YdHU8CmauWVawEAt14Zj3fmMBcS
+uSacieZROU9maQtGgJAYHZVJwgPyQY=
=OQRw
-----END PGP SIGNATURE-----
Merge tag 'for-5.16/parisc-3' of git://git.kernel.org/pub/scm/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
Mauro Carvalho Chehab