iio: adc: ti-ads8344: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
iio: adc: ti-ads7950: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to include 'may'.
Fixes: 902c4b2446d4 ("iio: adc: New driver for TI ADS7950 chips") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: David Lechner <david@lechnology.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-37-jic23@kernel.org
iio: adc: ti-ads131e08: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Fixes: d935eddd2799 ("iio: adc: Add driver for Texas Instruments ADS131E0x ADC family") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Tomislav Denis <tomislav.denis@avl.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-36-jic23@kernel.org
iio: adc: ti-ads124s08: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
iio: adc: ti-adc161s626: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Fixes: 4d671b71beef ("iio: adc: ti-adc161s626: add support for TI 1-channel differential ADCs") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Matt Ranostay <mranostay@gmail.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-34-jic23@kernel.org
iio: adc: ti-adc128s052: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
iio: adc: ti-adc12138: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Fixes: 50a6edb1b6e0 ("iio: adc: add ADC12130/ADC12132/ADC12138 ADC driver") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-32-jic23@kernel.org
iio: adc: ti-adc108s102: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Dual fixes tags as two cases that were introduced in different patches.
One of those patches is a fix however and likely to have been backported
to stable kernels.
Note the second alignment marking is likely to be unnecessary, but is
left for now to keep this fix simple.
Fixes: 3691e5a69449 ("iio: adc: add driver for the ti-adc084s021 chip") Fixes: cbe5c6977604 ("iio: adc: ti-adc108s102: Fix alignment of buffer pushed to iio buffers.") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-31-jic23@kernel.org
iio: adc: ti-adc084s021: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to include 'may'.
Fixes: 3691e5a69449 ("iio: adc: add driver for the ti-adc084s021 chip") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Acked-by: Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20220508175712.647246-30-jic23@kernel.org
iio: adc: ti-adc0832: Fix alignment for DMA safety
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Fixes: efc945fb729c ("iio: adc: add support for ADC0831/ADC0832/ADC0834/ADC0838 chips") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-29-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Worth noting the fixes tag refers to the same issue being observed
on a platform that probably had only 64 byte cachelines.
Fixes: 0e81bc99a082 ("iio: mcp320x: Fix occasional incorrect readings") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Michael Welling <mwelling@ieee.org> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-28-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Fixes: 8a80a71d9020 ("iio: adc: Add MAX1241 driver") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Alexandru Lazar <alazar@startmail.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-27-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Fixes: a9e9c7153e96 ("iio: adc: add max1117/max1118/max1119 ADC driver") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-26-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to include 'may'.
Fixes: bc82222fcca1 ("iio:adc: Driver for Linear Technology LTC2497 ADC") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-23-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to include 'may'.
Fixes: e4c5c4dfaa88 ("iio: adc: new driver to support Linear technology's ltc2496") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-22-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Note the fixes tag predates some changes to this line of code so
automated application of this fix may fail.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to include 'may'.
Note that some other fixes have applied to this line of code
that may complicate automated backporting.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to include 'may'.
Fixes tag is clearly not where this was introduced but it is very unlikely
anyone will back port it past that point.
Fixes: 65dd3d3d7a9b ("staging:iio:ad7887: Squash everything into one file") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-18-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to reflect that separate cachelines 'may' be
required.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to reflect the fact DMA safety 'may' require
separate cachelines.
Fixes: aa16c6bd0e09 ("iio:adc: Add support for AD7766/AD7767") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-16-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_ALIGN definition.
Update the comment to reflect the fact DMA safety 'may' require
separate cachelines.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to reflect that DMA safety 'may' require separate
cachelines.
Fixes tag is unlikely to be the actual introdution of the problem but is
far enough back to cover any likely backporting.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Fixes: 506d2e317a0a ("iio: adc: Add driver support for AD7292") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-12-jic23@kernel.org
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
____cacheline_aligned is an insufficient guarantee for non-coherent DMA
on platforms with 128 byte cachelines above L1. Switch to the updated
IIO_DMA_MINALIGN definition.
Update the comment to reflect that DMA safety 'may' require separate
cachelines.
iio: core: Fix IIO_ALIGN and rename as it was not sufficiently large
Discussion of the series:
https://lore.kernel.org/all/20220405135758.774016-1-catalin.marinas@arm.com/
mm, arm64: Reduce ARCH_KMALLOC_MINALIGN brought to my attention that
our current IIO usage of L1CACHE_ALIGN is insufficient as their are Arm
platforms out their with non coherent DMA and larger cache lines at
at higher levels of their cache hierarchy.
Rename the define to make it's purpose more explicit. It will be used
much more widely going forwards (to replace incorrect ____cacheline_aligned
markings.
Note this patch will greatly reduce the padding on some architectures
that have smaller requirements for DMA safe buffers.
The history of changing values of ARCH_KMALLOC_MINALIGN via
ARCH_DMA_MINALIGN on arm64 is rather complex. I'm not tagging this
as fixing a particular patch from that route as it's not clear what to tag.
Most recently a change to bring them back inline was reverted because
of some Qualcomm Kryo cores with an L2 cache with 128-byte lines
sitting above the point of coherency.
c1132702c71f Revert "arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"
That reverts: 65688d2a05de arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES) which
refers to the change originally being motivated by Thunder x1 performance
rather than correctness.
Fixes: 6f7c8ee585e9d ("staging:iio: Add ability to allocate private data space to iio_allocate_device") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220508175712.647246-2-jic23@kernel.org
Stephen Boyd [Tue, 3 May 2022 19:39:36 +0000 (12:39 -0700)]
dt-bindings: iio: sx9324: Add CS idle/sleep mode
We need to configure the sleep and idle mode of the CS pins for this
device. Add a DT property to do this so pins are in a proper state
during sleep (either hi-z, grounded, or pulled up to vdd).
Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220503193937.3794477-2-swboyd@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 20 Feb 2022 17:51:48 +0000 (17:51 +0000)]
iio: gyro: mpu3050: Drop unused symbol exports.
This driver is built as a single module. There is an note in the makefile
about SPI support being a reason to split the build in future. That
support has never arrived so drop these symbol exports.
Jonathan Cameron [Sun, 20 Feb 2022 17:37:00 +0000 (17:37 +0000)]
iio: adc: adi-axi: Move exported symbols into IIO_ADI_AXI namespace.
Avoid unnecessary pollution of the global symbol namespace by
moving library functions in to a specific namespace and import
that into the drivers that make use of the functions.
Jonathan Cameron [Sun, 20 Feb 2022 16:33:27 +0000 (16:33 +0000)]
iio: core: drop iio_get_time_res()
This function was introduced with the ability to pick a clock.
There are no upstream users so presumably it isn't as obviously useful
as it seemed at the time. Hence drop it.
The starting bit is always zero, it doesn't make much sense to
use for_each_set_bit_from. Replace it with for_each_set_bit
which doesn't start from a particular bit.
LI Qingwu [Sun, 29 May 2022 06:18:53 +0000 (06:18 +0000)]
iio: accel: sca3300: Add inclination channels
Different from SCA3300, SCL3300 can output inclination angles.
Angles are formed from acceleration with following equations:
ANG_X = atan2(accx , sqrt(pow(accy , 2) + pow(accz , 2)))
ANG_Y = atan2(accy , sqrt(pow(accx , 2) + pow(accz , 2)))
ANG_Z = atan2(accz , sqrt(pow(accx , 2) + pow(accy , 2)))
The commit adds the output of the raw value, scale
and scale_available of angles.
New interfaces:
in_incli_scale
in_incli_scale_available
in_incli_x_raw
in_incli_y_raw
in_incli_z_raw
Data converted by application of scale to degrees.
LI Qingwu [Sun, 29 May 2022 06:18:51 +0000 (06:18 +0000)]
iio: accel: sca3300: modified to support multi chips
Prepare the way for multiple chips and additional channels:
- Modify the driver to read the device ID and load the corresponding
sensor information from the table to support multiple chips
- Add prepares for the addition of extra channels
- Prepare for handling the operation modes for multiple chips
Fix whitespace coding style: use single space instead of tabs or
multiple spaces around '=' sign in property assignment. No functional
changes (same DTB).
Ville Syrjälä [Tue, 3 May 2022 18:22:30 +0000 (21:22 +0300)]
drm/i915: Skip FDI vs. dotclock sanity check during readout
The VBIOS/GOP may not program the FDI M/n vs. dotclock entirely
consistently. Eg. on a SNB Thinkpad X220 LVDS I see dotclock of
69.286 MHz (the best the DPLL can do) vs. FDI M/N 69.3 MHz
(matches what the EDID actually declares).
Ville Syrjälä [Wed, 4 May 2022 21:21:09 +0000 (00:21 +0300)]
drm/i915: Introduce struct iclkip_params
Pull the various iCLKIP parameters into a struct. Later on
we'll reuse this during the state computation to determine
the exact dotclock the hardware will be generating for us.
v2: Don't lose the phaseinc calculation
v3: Drop the misplaced '#include <intel_pch_refclk.h>' from intel_crt.c (Jani)
Ville Syrjälä [Wed, 4 May 2022 12:33:50 +0000 (15:33 +0300)]
drm/i915: Extract intel_crtc_dotclock()
Extract intel_crtc_dotclock() from ddi_dotclock_get(). We'll reuse
this during state computation in order to determine the actual final
dotclcok after the DPLL computation has been done (which may not give
us the exact same port_clock that we fed in).
Bard Liao [Tue, 14 Jun 2022 09:26:30 +0000 (17:26 +0800)]
ASoC: SOF: ipc4-topology: add SoundWire/ALH aggregation support
Some SoundWire hardware topologies rely on different amplifiers or
capture devices connected on different links. These devices need to be
'aggregated', remain synchronized and be handled as a single logical
device.
In the IPC3 solution, the aggregation for amplifiers was handled by a
firmware 'demux' component. In the IPC4 solution, the demux component is
not needed, the gateway component can handle multiple ALH/DMA transfers
at the same time. This change makes the topology slightly more complicated
in that only one ALH DAI will be connected in the topology with the
gateway. The other DAIs that are part of the 'aggregated' dailink are not
shown in the DAPM graph as connected to the gateway, but they will however
be activated thanks to a feature in soc-dapm.c where events are forwarded
to all DAIs in the dailink (see soc_dapm_stream_event).
The topology also sets the same stream name for all widgets, dais and
dailinks, so a search for the stream name helps identify cases where
SoundWire/ALH aggregation is needed.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220614092630.20144-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Fri, 3 Jun 2022 11:25:08 +0000 (13:25 +0200)]
ASoC: ops: Don't modify the driver's plaform_max when reading state
Currently snd_soc_info_volsw() will set a platform_max based on the limit
the control has if one is not already set. This isn't really great, we
shouldn't be modifying the passed in driver data especially in a path like
this which may not ever be executed or where we may execute other callbacks
before this one. Instead make this function leave the data unchanged, and
clarify things a bit by referring to max rather than platform_max within
the function. platform_max is now applied as a limit after working out the
natural maximum value for the control.
This means that platform_max is no longer treated as a direct register
value for controls were min is non-zero. The put() callbacks already
validate on this basis, and there do not appear to be any in tree users
that would be affected.
Peter Ujfalusi [Tue, 14 Jun 2022 07:56:17 +0000 (10:56 +0300)]
ASoC: SOF: Compile and runtime IPC version selection
The new IPC4 version is only supported by Intel platforms, iMX, AMD and
MediaTek only uses the standard SOF IPC.
There is no need for these platforms to build kernel support for IPC4 as
it is just dead code for them.
SND_SOC_SOF_IPC3 and SND_SOC_SOF_INTEL_IPC4 is introduced to allow compile
time selection and exclusion of IPC implementations.
To avoid randconfig failures add also support for runtime selection of
the IPC ops in ipc.c based on sdev->pdata->ipc_type
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220614075618.28605-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Serge Semin [Fri, 10 Jun 2022 10:40:30 +0000 (13:40 +0300)]
bus: bt1-axi: Don't print error on -EPROBE_DEFER
The Baikal-T1 AXI bus driver correctly handles the deferred probe
situation, but still pollutes the system log with a misleading error
message. Let's fix that by using the dev_err_probe() method to print the
log message in case of the clocks/resets request errors.
Serge Semin [Fri, 10 Jun 2022 10:40:29 +0000 (13:40 +0300)]
bus: bt1-apb: Don't print error on -EPROBE_DEFER
The Baikal-T1 APB bus driver correctly handles the deferred probe
situation, but still pollutes the system log with a misleading error
message. Let's fix that by using the dev_err_probe() method to print the
log message in case of the clocks/resets request errors.
Arnd Bergmann [Tue, 14 Jun 2022 10:19:57 +0000 (12:19 +0200)]
Merge tag 's32g2-fixes-5.19' of https://github.com/chesterlintw/linux-s32g into arm/fixes
S32G2 fixes for 5.19
- MAINTAINERS: Add s32@nxp.com as a review group.
- dts: Pass unit name to soc node to fix a W=1 build warning.
* tag 's32g2-fixes-5.19' of https://github.com/chesterlintw/linux-s32g:
MAINTAINERS: add a new reviewer for S32G
arm64: s32g2: Pass unit name to soc node
Miaoqian Lin [Wed, 1 Jun 2022 09:05:48 +0000 (13:05 +0400)]
ARM: Fix refcount leak in axxia_boot_secondary
of_find_compatible_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
When calling setattr_prepare() to determine the validity of the
attributes the ia_{g,u}id fields contain the value that will be written
to inode->i_{g,u}id. This is exactly the same for idmapped and
non-idmapped mounts and allows callers to pass in the values they want
to see written to inode->i_{g,u}id.
When group ownership is changed a caller whose fsuid owns the inode can
change the group of the inode to any group they are a member of. When
searching through the caller's groups we need to use the gid mapped
according to the idmapped mount otherwise we will fail to change
ownership for unprivileged users.
Consider a caller running with fsuid and fsgid 1000 using an idmapped
mount that maps id 65534 to 1000 and 65535 to 1001. Consequently, a file
owned by 65534:65535 in the filesystem will be owned by 1000:1001 in the
idmapped mount.
The caller now requests the gid of the file to be changed to 1000 going
through the idmapped mount. In the vfs we will immediately map the
requested gid to the value that will need to be written to inode->i_gid
and place it in attr->ia_gid. Since this idmapped mount maps 65534 to
1000 we place 65534 in attr->ia_gid.
When we check whether the caller is allowed to change group ownership we
first validate that their fsuid matches the inode's uid. The
inode->i_uid is 65534 which is mapped to uid 1000 in the idmapped mount.
Since the caller's fsuid is 1000 we pass the check.
We now check whether the caller is allowed to change inode->i_gid to the
requested gid by calling in_group_p(). This will compare the passed in
gid to the caller's fsgid and search the caller's additional groups.
Since we're dealing with an idmapped mount we need to pass in the gid
mapped according to the idmapped mount. This is akin to checking whether
a caller is privileged over the future group the inode is owned by. And
that needs to take the idmapped mount into account. Note, all helpers
are nops without idmapped mounts.
Alexandre Torgue [Mon, 13 Jun 2022 07:19:20 +0000 (09:19 +0200)]
ARM: dts: stm32: move SCMI related nodes in a dedicated file for stm32mp15
Adding a "secure" version of STM32 boards (DK1/DK2/ED1/EV1), SCMI (clock/
reset) protocol and OP-TEE node have been added in SoC dtsi file
(stm32mp151.dtsi). They have been added with a status disabled in order to
keep our legacy unchanged. It is actually not enough to keep our legacy
unchanged.
First, just a reminder about our use case: TF-A (BL2) loads and starts
OP-TEE, then loads and runs U-Boot. U-Boot code checks if an OP-TEE is
running, if yes it searches in Kernel device tree if an OP-TEE node is
present:
-If the OP-TEE node is not present then U-Boot copies OP-TEE node and its
reserved memory region from U-Boot device tree to the kernel device tree.
-If the OP-TEE node is present then it does nothing (this OP-TEE node will
be used by Linux). So U-Boot lets the kernel device tree unchanged thinking
it is correct for an OP-TEE usage. It is the case for our legacy boards,
the OP-TEE node is present (although disabled) but the reserved memory
region is not declared. As no memory region has been reserved for OP-TEE,
the end of DDR is seen by the kernel as free and then used for CMA. But as
OP-TEE is running, this end of DDR is already used by OP-TEE. So as soon as
kernel tries to access to the CMA region OP-TEE raises an error.
To fix it, all OP-TEE node and SCMI is moved in a dedicated file.
Arnd Bergmann [Tue, 14 Jun 2022 10:16:34 +0000 (12:16 +0200)]
Merge tag 'scmi-fixes-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm SCMI firmware driver fixes for v5.19
Bunch of fixes to address:
1. Issues reported on RK3568 EVB1 and BPI-R2 pro platforms using SCMI.
More checks were added to validate the firmware response but that
resulted in breaking above platforms, so the checks are relaxed when
for cases where there is no potential memory corruption issues.
2. Possible data leak by reading more than required length from the firmware.
Recent addition of support for v3.1 extended names used larger buffers
in the kernel and used their size to read response from the firmware even
for cases where shorter formats are used. While that is mostly harmless
except when firmware sends malformed non-NULL terminated buffers.
3. Possible issues sending unsupported commands to the firmware.
SENSOR_AXIS_NAME_GET added in v3.1 needs to be used only if the firmware
supports it. While the firmware conformant to the spec must return not
supported error for any unsupported features, it is always safer to
avoid issuing commands that are known to be unsupported.
4. Incorrect error propagation in scmi_voltage_descriptors_get.
Since the return value is not reset for each iteration of the loop, the
error value in the previous iteration will be carried for the current one.
Fix that by not saving the return values into local variable.
5. Some warnings reported by cppcheck
* tag 'scmi-fixes-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Fix incorrect error propagation in scmi_voltage_descriptors_get
firmware: arm_scmi: Avoid using extended string-buffers sizes if not necessary
firmware: arm_scmi: Fix SENSOR_AXIS_NAME_GET behaviour when unsupported
firmware: arm_scmi: Remove all the unused local variables
firmware: arm_scmi: Relax base protocol sanity checks on the protocol list
Arnd Bergmann [Tue, 14 Jun 2022 10:15:43 +0000 (12:15 +0200)]
Merge tag 'imx-fixes-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 5.19:
- Correct i.MX7 power domain for HSIC USB PHY node to fix an USB Host
issue, that is all downstream events will be lost if USB host is
runtime suspended.
- Fix i.MX8M blk-ctrl LCDIF2 power domain to point to refer to the
correct clock.
- Correct i.MX6Q/DL PU regulator ramp delay to fix some peripherals
power-up failure especially when the chip is at a low temperature.
- Fix capacitive touch reset polarity for imx6qdl-colibri board.
* tag 'imx-fixes-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
soc: imx: imx8m-blk-ctrl: fix display clock for LCDIF2 power domain
ARM: dts: imx6qdl-colibri: Fix capacitive touch reset polarity
ARM: dts: imx6qdl: correct PU regulator ramp delay
ARM: dts: imx7: Move hsic_phy power domain to HSIC PHY node
Fix whitespace coding style: use single space instead of tabs or
multiple spaces around '=' sign in property assignment. No functional
changes (same DTB).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Lucas Stach [Wed, 25 May 2022 10:35:20 +0000 (12:35 +0200)]
arm64: dts: imx8mp-evk: add regulator supply to CPU nodes
This supply is used by cpufreq to scale the voltage applied to the
ARM voltage domain of the SoC when switching between the different
operating points.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Conor Dooley [Tue, 14 Jun 2022 06:58:10 +0000 (07:58 +0100)]
spi: microchip-core: fix potentially incorrect return from probe
If platform_get_irqi() returns 0, the error case will be triggered but
probe() will return 0 rather than an error. Ape the other drivers using
this pattern and return -ENXIO.
Stephen Boyd [Tue, 14 Jun 2022 07:57:26 +0000 (00:57 -0700)]
platform/chrome: cros_ec: Always expose last resume result
The last resume result exposing logic in cros_ec_sleep_event()
incorrectly requires S0ix support, which doesn't work on ARM based
systems where S0ix doesn't exist. That's because cros_ec_sleep_event()
only reports the last resume result when the EC indicates the last sleep
event was an S0ix resume. On ARM systems, the last sleep event is always
S3 resume, but the EC can still detect sleep hang events in case some
other part of the AP is blocking sleep.
Always expose the last resume result if the EC supports it so that this
works on all devices regardless of S0ix support. This fixes sleep hang
detection on ARM based chromebooks like Trogdor.
Cc: Rajat Jain <rajatja@chromium.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Fixes: 7235560ac77a ("platform/chrome: Add support for v1 of host sleep event") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220614075726.2729987-1-swboyd@chromium.org
This is overkill in most cases, we already have a message thrown in
case of errors and have tracepoints enabled to check for IPC
duration. The only case where this might be useful is to check if
there is an interleaved IPC RX. Add a flag and only print those logs
if enabled.
In addition, the DMA_POSITION_UPDATE for traces brings limited
information in most cases and pollutes the logs for no good reason.
This information is only helpful when debugging the trace support, not
when using the trace. Add a flag to only print DMA position update
logs if enabled.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220610214601.43005-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
The same message was added twice for dai and link_dma, remove the
latter one and add dai name and direction to better understand
problematic sequences.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220610214504.42974-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 13 Jun 2022 16:15:52 +0000 (17:15 +0100)]
ASoC: mediatek: mt8186: Use new direct clock defines
Update this driver to the new direct clock producer/consumer defines. It
appears this driver was added with the inversion taken account of but
still uses the CODEC defines so no inversion of the producer/consumer
is necessary.
Charles Keepax [Mon, 13 Jun 2022 16:15:51 +0000 (17:15 +0100)]
ASoC: sun8i-codec: Partial revert to fix clock specifiers
Recent updates accidentally updated the clock producer/consumer
specifiers on this device as part of refactoring the CPU side of the DAI
links. However, this device sits on the CODEC side and shouldn't have
been updated. Partially revert the changes keeping the switch to the new
clock terminology but going back to the CODEC defines.
Fixes: 7cc3965fde74 ("ASoC: sunxi: Update to use set_fmt_new callback") Reported-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Tested-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20220613161552.481337-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>