* [PATCH v2 2/3] MAINTAINERS: Update imagination maintainers
From: Matt Coster @ 2026-06-26 12:43 UTC (permalink / raw)
To: imagination, linux-kernel
Cc: Conor Dooley, Alessio Belle, Luigi Santivetti, Frank Binns,
Brajesh Gupta, Alexandru Dadu, dri-devel, devicetree, Matt Coster
In-Reply-To: <20260626-maintainer-updates-v2-0-e1b3f246c44c@imgtec.com>
New people are taking up maintainership roles within the team.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b45e60524762..fe02d1087ab2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12567,8 +12567,9 @@ S: Orphan
F: drivers/media/rc/img-ir/
IMGTEC POWERVR DRM DRIVER
-M: Frank Binns <frank.binns@imgtec.com>
M: Matt Coster <matt.coster@imgtec.com>
+M: Alessio Belle <alessio.belle@imgtec.com>
+M: Luigi Santivetti <luigi.santivetti@imgtec.com>
L: imagination@lists.freedesktop.org
S: Supported
Q: https://patchwork.freedesktop.org/project/imagination/list/
--
2.48.1
^ permalink raw reply related
* [PATCH v2 3/3] dt-bindings: gpu: img,powervr-*: Add maintainer entries
From: Matt Coster @ 2026-06-26 12:43 UTC (permalink / raw)
To: imagination, linux-kernel
Cc: Conor Dooley, Alessio Belle, Luigi Santivetti, Frank Binns,
Brajesh Gupta, Alexandru Dadu, dri-devel, devicetree, Matt Coster
In-Reply-To: <20260626-maintainer-updates-v2-0-e1b3f246c44c@imgtec.com>
These entries were previously unaligned with MAINTAINERS, but will be
even more so now that entries are being changed there. Bring them in
sync by replacing the list here with the updated one from MAINTAINERS.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
---
Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 4 +++-
Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
index a1f54dbae3f3..91e4ff61b394 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
@@ -8,7 +8,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Imagination Technologies PowerVR and IMG Rogue GPUs
maintainers:
- - Frank Binns <frank.binns@imgtec.com>
+ - Matt Coster <matt.coster@imgtec.com>
+ - Alessio Belle <alessio.belle@imgtec.com>
+ - Luigi Santivetti <luigi.santivetti@imgtec.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
index f5898b04381c..3e7df7344430 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
@@ -9,7 +9,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Imagination Technologies PowerVR SGX GPUs
maintainers:
- - Frank Binns <frank.binns@imgtec.com>
+ - Matt Coster <matt.coster@imgtec.com>
+ - Alessio Belle <alessio.belle@imgtec.com>
+ - Luigi Santivetti <luigi.santivetti@imgtec.com>
properties:
compatible:
--
2.48.1
^ permalink raw reply related
* [PATCH v2 1/3] MAINTAINERS: Update imagination details
From: Matt Coster @ 2026-06-26 12:43 UTC (permalink / raw)
To: imagination, linux-kernel
Cc: Conor Dooley, Alessio Belle, Luigi Santivetti, Frank Binns,
Brajesh Gupta, Alexandru Dadu, dri-devel, devicetree, Matt Coster
In-Reply-To: <20260626-maintainer-updates-v2-0-e1b3f246c44c@imgtec.com>
There's a bunch of useful information missing from this entry, flesh it
out and simplify the dt-bindings pattern while we're at it.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
---
MAINTAINERS | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 987635948cde..b45e60524762 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12569,10 +12569,13 @@ F: drivers/media/rc/img-ir/
IMGTEC POWERVR DRM DRIVER
M: Frank Binns <frank.binns@imgtec.com>
M: Matt Coster <matt.coster@imgtec.com>
+L: imagination@lists.freedesktop.org
S: Supported
+Q: https://patchwork.freedesktop.org/project/imagination/list/
+B: https://gitlab.freedesktop.org/imagination/linux/-/issues
+C: irc://irc.oftc.net/powervr
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
-F: Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
-F: Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
+F: Documentation/devicetree/bindings/gpu/img,powervr-*.yaml
F: Documentation/gpu/imagination/
F: drivers/gpu/drm/ci/xfails/powervr*
F: drivers/gpu/drm/imagination/
--
2.48.1
^ permalink raw reply related
* [PATCH v2 0/3] drm/imagination: Maintainer updates
From: Matt Coster @ 2026-06-26 12:43 UTC (permalink / raw)
To: imagination, linux-kernel
Cc: Conor Dooley, Alessio Belle, Luigi Santivetti, Frank Binns,
Brajesh Gupta, Alexandru Dadu, dri-devel, devicetree, Matt Coster
We've got some new people stepping up to help out with maintainership of
the imagination driver, so let's take this opportunity to unify the
maintainer list where it appears across multiple files.
There are also some new resources (mailing list, patchwork, IRC) that
didn't previously exist and had not yet been added, so let's do that now
as well.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
---
Changes in v2:
- EDITME: describe what is new in this series revision.
- EDITME: use bulletpoints and terse descriptions.
- Link to v1: https://patch.msgid.link/20260625-maintainer-updates-v1-0-35112b2f038e@imgtec.com
---
Matt Coster (3):
MAINTAINERS: Update imagination details
MAINTAINERS: Update imagination maintainers
dt-bindings: gpu: img,powervr-*: Add maintainer entries
Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 4 +++-
Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml | 4 +++-
MAINTAINERS | 10 +++++++---
3 files changed, 13 insertions(+), 5 deletions(-)
---
base-commit: 60b5fa6edfef867322fce7c8306e5c4b46211be7
change-id: 20260624-maintainer-updates-bfc189254555
^ permalink raw reply
* Re: [PATCH v4 19/19] arm64: dts: qcom: sdm845: Add minidump SRAM config to SCM node
From: Konrad Dybcio @ 2026-06-26 12:44 UTC (permalink / raw)
To: Mukesh Ojha, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Marko,
Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260624190830.3131112-20-mukesh.ojha@oss.qualcomm.com>
On 6/24/26 9:08 PM, Mukesh Ojha wrote:
> Point the SCM node at the minidump config slot in the always-on SRAM.
> Boot firmware reads this word before DDR is initialised on a warm reset
> to decide where to deliver the minidump.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 0/4] Enable SPI on SA8255p Qualcomm platforms
From: Mattijs Korpershoek @ 2026-06-26 12:53 UTC (permalink / raw)
To: Praveen Talari, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, bjorn.andersson, Praveen Talari
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
mukesh.savaliya, aniket.randive, chandana.chiluveru,
jyothi.seerapu, chiluka.harish, Nikunj Kela, Krzysztof Kozlowski
In-Reply-To: <20260618-enable-spi-on-sa8255p-v4-0-f5b5067e7e1e@oss.qualcomm.com>
Hi Praveen,
Thank you for the series.
On Thu, Jun 18, 2026 at 14:36, Praveen Talari <praveen.talari@oss.qualcomm.com> wrote:
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM.
> The driver requests resources operations over SCMI using power
> and performance protocols.
>
> The SCMI power protocol enables or disables resources like clocks,
> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
> such as resume/suspend, to control power states(on/off).
>
> The SCMI performance protocol manages SPI frequency, with each
> frequency rate represented by a performance level. The driver uses
> geni_se_set_perf_opp() API to request the desired frequency rate.
>
> As part of geni_se_set_perf_opp(), the OPP for the requested frequency
> is obtained using dev_pm_opp_find_freq_floor() and the performance
> level is set using dev_pm_opp_set_opp().
>
> Praveen Talari (4):
> spi: dt-bindings: describe SA8255p
> spi: qcom-geni: Use geni_se_resources_init() for resource
> initialization
> spi: qcom-geni: Use resources helper APIs in runtime PM functions
> spi: qcom-geni: Enable SPI on SA8255p Qualcomm platforms
>
> .../bindings/spi/qcom,sa8255p-geni-spi.yaml | 63 ++++++++++++++
> drivers/spi/spi-geni-qcom.c | 83 ++++++++-----------
> 2 files changed, 97 insertions(+), 49 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/qcom,sa8255p-geni-spi.yaml
Tested on top of linux-next-20260625 with my Ride SX (SA8775P) board:
/ # uname -a
Linux (none) 7.1.0-next-20260625+ #3 SMP PREEMPT_RT Fri Jun 26 11:53:34 CEST 2026 aarch64 aarch64 aarch64 GNU/Linux
With spidev_test, we ping the on-board mercury codec and get a valid
response buffer from the codec (b6 49):
/ # spidev_test -D /dev/spidev16.0 -v
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................|
RX | B6 49 00 13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.I..............................|
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] iio: adc: Add Nuvoton MA35D1 EADC driver
From: Andy Shevchenko @ 2026-06-26 12:54 UTC (permalink / raw)
To: Chi-Wen Weng
Cc: jic23, robh, krzk+dt, conor+dt, dlechner, nuno.sa, andy,
linux-arm-kernel, linux-iio, devicetree, linux-kernel, cwweng
In-Reply-To: <20260625110638.38438-3-cwweng.linux@gmail.com>
On Thu, Jun 25, 2026 at 07:06:38PM +0800, Chi-Wen Weng wrote:
> Add an IIO driver for the Nuvoton MA35D1 Enhanced ADC controller.
>
> The driver supports direct raw reads and triggered buffered capture. The
> controller end-of-conversion interrupt is exposed as the device trigger
> and is used to push samples into the IIO buffer.
>
> Channels are described by firmware child nodes and can be configured as
> single-ended or differential inputs. Since the differential enable bit is
> global, mixed single-ended and differential buffered scans are rejected.
>
> DMA support is intentionally not included in this initial upstream driver;
> conversions are handled through the interrupt-driven path.
Nice written driver, some small issues here and there, and I think in a couple
of versions it will stabilize and can be accepted.
...
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
No need, bitmap.h covers this.
> +#include <linux/bitmap.h>
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/device.h>
No need, covered by platform_device.h.
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
No way this header should be in the mere drivers.
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm.h>
> +#include <linux/property.h>
Also missing some headers, such as types.h.
...
> +#define MA35D1_EADC_TIMEOUT msecs_to_jiffies(1000)
+ jiffies.h
...
> +static inline u32 ma35d1_adc_read(struct ma35d1_adc *adc, u32 reg)
> +{
> + return readl(adc->regs + reg);
> +}
> +
> +static inline void ma35d1_adc_write(struct ma35d1_adc *adc, u32 reg, u32 val)
> +{
> + writel(val, adc->regs + reg);
> +}
> +
> +static void ma35d1_adc_rmw(struct ma35d1_adc *adc, u32 reg, u32 mask, u32 val)
Name it _update() to be aligned with the _read() and _write() above.
> +{
> + u32 tmp;
> +
> + tmp = ma35d1_adc_read(adc, reg);
> + tmp &= ~mask;
> + tmp |= val;
Correct pattern is to use
tmp = (tmp & ~mask) | (val & mask);
> + ma35d1_adc_write(adc, reg, tmp);
> +}
...
> +static void ma35d1_adc_config_sample(struct ma35d1_adc *adc,
> + unsigned int sample, unsigned int channel)
> +{
> + u32 reg = MA35D1_EADC_SCTL(sample);
I don't see the need of this variable, use the value directly.
> + ma35d1_adc_rmw(adc, reg,
> + MA35D1_EADC_SCTL_CHSEL_MASK |
> + MA35D1_EADC_SCTL_TRGSEL_MASK,
> + FIELD_PREP(MA35D1_EADC_SCTL_CHSEL_MASK, channel) |
> + MA35D1_EADC_SCTL_TRGSEL_ADINT0);
> +}
...
> +static irqreturn_t ma35d1_adc_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + for (i = 0; i < adc->scan_chancnt; i++)
for (unsigned int i = 0; i < adc->scan_chancnt; i++)
> + adc->scan.channels[i] =
> + ma35d1_adc_read(adc, MA35D1_EADC_DAT(i)) &
> + MA35D1_EADC_DAT_MASK;
> +
> + iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan, pf->timestamp);
> + iio_trigger_notify_done(adc->trig);
> +
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + return IRQ_HANDLED;
> +}
...
> +static int ma35d1_adc_validate_scan(struct iio_dev *indio_dev,
> + const unsigned long *scan_mask)
> +{
> + const struct iio_chan_spec *chan;
> + bool have_single = false;
> + bool have_diff = false;
> + unsigned int count = 0;
> + unsigned long bit;
> +
> + for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
> + chan = &indio_dev->channels[bit];
> +
> + if (chan->type == IIO_TIMESTAMP)
> + continue;
> + count++;
Make it last in the loop, it will be standard pattern. Otherwise it's hard to
read and find. Also it's recommended to split assignment and definition
for better maintenance.
unsigned int count;
...
count = 0;
for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
...
count++;
}
> + if (chan->differential)
> + have_diff = true;
> + else
> + have_single = true;
> + }
> +
> + if (!count || count > MA35D1_EADC_MAX_SAMPLE_MODULES)
> + return -EINVAL;
> + if (have_single && have_diff)
> + return -EINVAL;
Is it possible IRL?
> + return 0;
> +}
...
> +static int ma35d1_adc_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + if (!adc->scan_chancnt)
> + return -EINVAL;
> +
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_INTSRC0,
> + MA35D1_EADC_INTSRC0_ADINT0,
> + MA35D1_EADC_INTSRC0_ADINT0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_REFADJCTL,
> + MA35D1_EADC_REFADJCTL_EXT_VREF,
> + MA35D1_EADC_REFADJCTL_EXT_VREF);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SELSMP0, GENMASK(1, 0), 3);
> + ma35d1_adc_set_diff(adc, adc->scan_differential);
> + for (i = 0; i < adc->scan_chancnt; i++)
for (unsigned int i = 0; i < adc->scan_chancnt; i++)
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
> + MA35D1_EADC_SCTL_TRGDLY_MASK,
> + MA35D1_EADC_SCTL_TRGDLY_MASK);
> +
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + ma35d1_adc_disable_irq(adc);
> + for (i = 0; i < adc->scan_chancnt; i++)
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
> + MA35D1_EADC_SCTL_TRGSEL_MASK, 0);
Ditto.
Also looking to the cases of setting 0s, I would rather have a helper
_set_bits() / _clear_bits() in conjunction with _update().
> + return 0;
> +}
...
> +static void ma35d1_adc_init_channel(struct ma35d1_adc *adc,
> + struct iio_chan_spec *chan, u32 vinp,
> + u32 vinn, int scan_index, bool differential)
> +{
> + char *name = adc->chan_name[vinp];
> +
> + chan->type = IIO_VOLTAGE;
> + chan->indexed = 1;
> + chan->channel = vinp;
> + chan->address = vinp;
> + chan->scan_index = scan_index;
> + chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
> + chan->scan_type.sign = 'u';
> + chan->scan_type.realbits = 12;
> + chan->scan_type.storagebits = 16;
> + chan->scan_type.endianness = IIO_CPU;
> +
> + if (differential) {
> + chan->differential = 1;
> + chan->channel2 = vinn;
> + snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d-in%d", vinp,
> + vinn);
Can compiler prove the buffer size is enough?
> + } else {
> + snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d", vinp);
> + }
> +
> + chan->datasheet_name = name;
Why not use devm_kasprintf() instead?
> +}
...
> +static int ma35d1_adc_parse_channels(struct iio_dev *indio_dev,
> + struct device *dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + DECLARE_BITMAP(used_channels, MA35D1_EADC_MAX_CHANNELS);
> + struct fwnode_handle *child;
> + struct iio_chan_spec *channels;
> + int num_channels;
> + int scan_index = 0;
> + int ret;
> +
> + bitmap_zero(used_channels, MA35D1_EADC_MAX_CHANNELS);
> +
> + num_channels = device_get_child_node_count(dev);
> + if (!num_channels)
> + return dev_err_probe(dev, -ENODATA,
> + "no ADC channels configured\n");
> +
> + if (num_channels > MA35D1_EADC_MAX_CHANNELS)
Perhaps >= ?
> + return dev_err_probe(dev, -EINVAL, "too many ADC channels\n");
> +
> + channels = devm_kcalloc(dev, num_channels + 1, sizeof(*channels),
> + GFP_KERNEL);
> + if (!channels)
> + return -ENOMEM;
> +
> + device_for_each_child_node(dev, child) {
Use _scoped() variant.
> + u32 diff[2];
> + u32 reg;
> + bool differential = false;
> +
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, ret,
> + "missing channel reg property\n");
> + }
> +
> + if (reg >= MA35D1_EADC_MAX_CHANNELS) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "invalid ADC channel %u\n", reg);
> + }
> +
> + if (test_and_set_bit(reg, used_channels)) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "duplicate ADC channel %u\n", reg);
> + }
> +
> + if (fwnode_property_present(child, "diff-channels")) {
> + ret = fwnode_property_read_u32_array(child,
> + "diff-channels",
> + diff,
> + ARRAY_SIZE(diff));
> + if (ret) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, ret,
> + "invalid diff-channels for channel %u\n",
> + reg);
> + }
> +
> + if (diff[0] != reg ||
> + diff[1] >= MA35D1_EADC_MAX_CHANNELS ||
> + diff[0] == diff[1]) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "invalid differential ADC channel %u-%u\n",
> + diff[0], diff[1]);
> + }
> +
> + if (test_and_set_bit(diff[1], used_channels)) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "ADC channel %u already used\n",
> + diff[1]);
> + }
> +
> + differential = true;
> + }
> +
> + ma35d1_adc_init_channel(adc, &channels[scan_index], reg,
> + differential ? diff[1] : 0,
> + scan_index, differential);
> + scan_index++;
> + }
> +
> + channels[scan_index] = (struct iio_chan_spec)
> + IIO_CHAN_SOFT_TIMESTAMP(scan_index);
> +
> + indio_dev->channels = channels;
> + indio_dev->num_channels = scan_index + 1;
> + indio_dev->masklength = indio_dev->num_channels;
> +
> + return 0;
> +}
...
> + ret = devm_request_irq(dev, irq, ma35d1_adc_isr, 0, dev_name(dev),
> + indio_dev);
Make it a single line, here it's fine.
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to request IRQ %d\n", irq);
Remove duplicate error message.
...
> + ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
> + iio_pollfunc_store_time,
> + ma35d1_adc_trigger_handler,
> + &ma35d1_adc_buffer_ops);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to setup triggered buffer\n");
So, it seems this is very rarely can be not -ENOMEM, and hence it's 99.99% dead
code, just
return ret;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: spmi-gpio: Add PMG1110 GPIO support
From: Linus Walleij @ 2026-06-26 13:00 UTC (permalink / raw)
To: Fenglin Wu, Bartosz Golaszewski
Cc: linux-arm-msm, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-gpio, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <20260610-pmg1110-gpio-v1-2-a9c50cd8b5d9@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 9:05 AM Fenglin Wu <fenglin.wu@oss.qualcomm.com> wrote:
> Add PMG1110 GPIO support with its compatible string and match data.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Acked-by: Linus Walleij <linusw@kernel.org>
Bartosz will queue the patch, I think.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: media: Add macros for video interface devices
From: Vladimir Zapolskiy @ 2026-06-26 13:21 UTC (permalink / raw)
To: Kieran Bingham, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jacopo Mondi, Sakari Ailus,
Jimmy Su, Matthias Fend, Mikhail Rudenko, Daniel Scally,
Jacopo Mondi, Michael Riesch, Benjamin Mugnier, Sylvain Petinot,
Laurent Pinchart, Paul Elder, Martin Kepplinger, Quentin Schulz,
Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan, Thierry Reding,
Jonathan Hunter, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven,
Magnus Damm, Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Conor Dooley
In-Reply-To: <20260626-kbingham-orientation-v2-1-47178be927b4@ideasonboard.com>
On 6/26/26 15:07, Kieran Bingham wrote:
> Add a new dt-bindings/media/video-interface-devices.h header that
> defines macros corresponding to the orientation enumeration types from
> media/video-interface-devices.yaml.
>
> This allows avoiding hardcoded constants in device tree sources.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> include/dt-bindings/media/video-interface-devices.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/dt-bindings/media/video-interface-devices.h b/include/dt-bindings/media/video-interface-devices.h
> new file mode 100644
> index 000000000000..d2340b457292
> --- /dev/null
> +++ b/include/dt-bindings/media/video-interface-devices.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
> +/*
> + * Copyright (C) 2026 Kieran Bingham <kieran.bingham@ideasonboard.com>
> + */
> +
> +#ifndef __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
> +#define __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
> +
> +#define MEDIA_ORIENTATION_FRONT 0
> +#define MEDIA_ORIENTATION_BACK 1
> +#define MEDIA_ORIENTATION_EXTERNAL 2
> +
> +#endif /* __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__ */
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Vladimir Zapolskiy @ 2026-06-26 13:21 UTC (permalink / raw)
To: Kieran Bingham, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jacopo Mondi, Sakari Ailus,
Jimmy Su, Matthias Fend, Mikhail Rudenko, Daniel Scally,
Jacopo Mondi, Michael Riesch, Benjamin Mugnier, Sylvain Petinot,
Laurent Pinchart, Paul Elder, Martin Kepplinger, Quentin Schulz,
Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan, Thierry Reding,
Jonathan Hunter, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven,
Magnus Damm, Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-2-47178be927b4@ideasonboard.com>
On 6/26/26 15:07, Kieran Bingham wrote:
> Expand the documentation of the video-interface-devices orientation to
> reference the include/dt-bindings/media/video-interface-devices.h header
> which provides human readable defines for the orientation enum, to help
> avoid hardcoding values in dts.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> .../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> index a81d2a155fe6..c9c3f4f16719 100644
> --- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> @@ -392,17 +392,22 @@ properties:
> The orientation of a device (typically an image sensor or a flash LED)
> describing its mounting position relative to the usage orientation of the
> system where the device is installed on.
> + See include/dt-bindings/media/video-interface-devices.h.
> +
> $ref: /schemas/types.yaml#/definitions/uint32
> enum:
> - # Front. The device is mounted on the front facing side of the system. For
> - # mobile devices such as smartphones, tablets and laptops the front side
> - # is the user facing side.
> + # MEDIA_ORIENTATION_FRONT
> + # The device is mounted on the front facing side of the system. For
> + # mobile devices such as smartphones, tablets and laptops the front
> + # side is the user facing side.
> - 0
> - # Back. The device is mounted on the back side of the system, which is
> + # MEDIA_ORIENTATION_BACK
> + # The device is mounted on the back side of the system, which is
> # defined as the opposite side of the front facing one.
> - 1
> - # External. The device is not attached directly to the system but is
> - # attached in a way that allows it to move freely.
> + # MEDIA_ORIENTATION_EXTERNAL
> + # The device is not attached directly to the system but is attached in
> + # a way that allows it to move freely.
> - 2
>
> additionalProperties: true
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: media: i2c: Utilise video-interface-devices enums
From: Vladimir Zapolskiy @ 2026-06-26 13:22 UTC (permalink / raw)
To: Kieran Bingham, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jacopo Mondi, Sakari Ailus,
Jimmy Su, Matthias Fend, Mikhail Rudenko, Daniel Scally,
Jacopo Mondi, Michael Riesch, Benjamin Mugnier, Sylvain Petinot,
Laurent Pinchart, Paul Elder, Martin Kepplinger, Quentin Schulz,
Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan, Thierry Reding,
Jonathan Hunter, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven,
Magnus Damm, Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-3-47178be927b4@ideasonboard.com>
On 6/26/26 15:07, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the existing examples throughout the bindings documentation for
> camera sensors.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml | 3 ++-
> 12 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> index 1a57f2aa1982..b7bc6ba26e6e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> @@ -86,6 +86,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -102,7 +103,7 @@ examples:
> vddio-supply = <®_camera_vddio>;
> reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
> shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> index 6f2017c75125..b9c61395b24f 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> @@ -69,6 +69,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -84,7 +85,7 @@ examples:
> avdd-supply = <&ov08d10_vdda_2v8>;
> dvdd-supply = <&ov08d10_vddd_1v2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> index d96199031b66..fcd617848ce3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> @@ -96,6 +96,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -114,7 +115,7 @@ examples:
> powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> index ad07204057f9..6df62fd0c0c0 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> @@ -85,6 +85,7 @@ examples:
> - |
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> i2c {
> @@ -108,7 +109,7 @@ examples:
> dovdd-supply = <&vcc_2v8>;
>
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> ucam_out: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> index 3368b3bd8ef2..5732657e1484 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> @@ -103,6 +103,7 @@ examples:
> - |
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> i2c {
> @@ -126,7 +127,7 @@ examples:
> dovdd-supply = <&vcc_2v8>;
>
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> ucam_out: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> index 2b6143aff391..24787c9aa155 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> @@ -72,6 +72,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -87,7 +88,7 @@ examples:
> powerdown-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> rotation = <180>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
>
> port {
> endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> index 20f48d5e9b2d..56fb5f18f07b 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> @@ -69,6 +69,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -84,7 +85,7 @@ examples:
> dvdd-supply = <&camera_vddd_1v2>;
> avdd-supply = <&camera_vdda_2v7>;
>
> - orientation = <1>;
> + orientation = <MEDIA_ORIENTATION_BACK>;
> rotation = <90>;
>
> nvmem = <&eeprom>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> index 6050d7e7dcfe..b4a88eaa7ef2 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> @@ -74,6 +74,7 @@ examples:
> - |
> #include <dt-bindings/clock/qcom,camcc-sdm845.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -98,7 +99,7 @@ examples:
> pinctrl-0 = <&cam_front_default>;
>
> rotation = <270>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> cam_front_endpoint: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> index 7c11e871dca6..69a37ff68db3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> @@ -86,6 +86,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -98,7 +99,7 @@ examples:
> clocks = <&clock_cam>;
> dvdd-supply = <&vcc1v1_cam>;
> lens-focus = <&vcm>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&vcc1v8_cam>;
> reset-gpios = <&gpio_expander 14 GPIO_ACTIVE_LOW>;
> rotation = <180>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> index 060ac6829b66..db9f0c15576c 100644
> --- a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> @@ -105,6 +105,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -123,7 +124,7 @@ examples:
> reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> st,leds = <2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> index c6673b8539db..48db22ca4a7e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> @@ -107,6 +107,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -125,7 +126,7 @@ examples:
> reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> st,leds = <6>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> index bc339a7374b2..4a66cb711372 100644
> --- a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> @@ -173,6 +173,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -196,7 +197,7 @@ examples:
> vddgpio-0-supply = <&vsys_v4p2>;
> vddgpio-1-supply = <&vsys_v4p2>;
>
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <0>;
>
> sensors {
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 6/8] arm64: dts: qcom: Convert to new media orientation definitions
From: Vladimir Zapolskiy @ 2026-06-26 13:22 UTC (permalink / raw)
To: Kieran Bingham, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jacopo Mondi, Sakari Ailus,
Jimmy Su, Matthias Fend, Mikhail Rudenko, Daniel Scally,
Jacopo Mondi, Michael Riesch, Benjamin Mugnier, Sylvain Petinot,
Laurent Pinchart, Paul Elder, Martin Kepplinger, Quentin Schulz,
Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan, Thierry Reding,
Jonathan Hunter, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven,
Magnus Damm, Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-6-47178be927b4@ideasonboard.com>
On 6/26/26 15:07, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the qualcomm device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 3 ++-
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 3 ++-
> arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 3 ++-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 04cb9230d29f..d79be22108c8 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -13,6 +13,7 @@
> #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
> #include <dt-bindings/leds/common.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> #include <dt-bindings/sound/qcom,q6asm.h>
> @@ -701,7 +702,7 @@ camera@10 {
> pinctrl-0 = <&cam_mclk3_default>;
> pinctrl-names = "default";
>
> - orientation = <0>; /* Front facing */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <270>;
>
> port {
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index abd9c5a67b9f..543fc691fd3c 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -11,6 +11,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>
> #include "sc8280xp.dtsi"
> @@ -682,7 +683,7 @@ camera@10 {
>
> clocks = <&camcc CAMCC_MCLK3_CLK>;
>
> - orientation = <0>; /* Front facing */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> avdd-supply = <&vreg_l6q>;
> dvdd-supply = <&vreg_l2q>;
> diff --git a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> index 0f57b915186b..375b3c0edea7 100644
> --- a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> @@ -9,6 +9,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> #include <dt-bindings/power/qcom-rpmpd.h>
> #include "sdm670.dtsi"
> @@ -460,7 +461,7 @@ camera@1a {
> pinctrl-names = "default";
>
> rotation = <270>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> cam_front_endpoint: endpoint {
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* [GIT PULL] Devicetree fixes for v7.2, part 1
From: Rob Herring @ 2026-06-26 13:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Saravana Kannan, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
devicetree
Linus,
Please pull DT fixes for 7.2. It's based on your tree as of a few days
ago to fix the warnings introduced by amlogic,thermal.yaml changes.
Rob
The following changes since commit 840ef6c78e6a2f694b578ecb9063241c992aaa9e:
Merge tag 'nfs-for-7.2-1' of git://git.linux-nfs.org/projects/anna/linux-nfs (2026-06-23 18:36:41 -0700)
are available in the Git repository at:
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-fixes-for-7.2-1
for you to fetch changes up to b39a6b2e9d5bd6a3153aed4c7440172b8f6a739e:
dt-bindings: mfd: khadas,mcu: Drop type reference from "fan-supply" (2026-06-24 08:48:09 -0500)
----------------------------------------------------------------
Devicetree fixes for v7.2-rc, part 1:
- Drop unnecessary type reference from khadas,mcu "fan-supply"
- Fix clocks in Renesas R-Mobile APE6 example
- Add missing Unisoc SC2730 PMIC regulators schema
- Fix Amlogic thermal example
- kernel-doc fix for of_map_id()
- Handle negative index in of_fwnode_get_reference_args()
----------------------------------------------------------------
Alban Bedel (1):
of: property: Fix of_fwnode_get_reference_args() with negative index
Krzysztof Kozlowski (2):
dt-bindings: thermal: amlogic: Fix missing header in the example
dt-bindings: thermal: amlogic: Correct 'reg' in the example
Marek Vasut (1):
dt-bindings: clock: renesas: div6: Use ZT/ZTR trace clock in R-Mobile APE6 example
Otto Pflüger (1):
regulator: dt-bindings: Add Unisoc SC2730 PMIC
Rob Herring (Arm) (1):
dt-bindings: mfd: khadas,mcu: Drop type reference from "fan-supply"
Vijayanand Jitta (1):
of: Fix RST inline emphasis warnings in of_map_id() kernel-doc
.../bindings/clock/renesas,cpg-div6-clock.yaml | 2 +-
.../devicetree/bindings/mfd/khadas,mcu.yaml | 1 -
.../bindings/regulator/sprd,sc2730-regulator.yaml | 44 ++++++++++++++++++++++
.../bindings/thermal/amlogic,thermal.yaml | 5 ++-
drivers/of/base.c | 4 +-
drivers/of/property.c | 8 ++++
6 files changed, 59 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/sprd,sc2730-regulator.yaml
^ permalink raw reply
* Re: [PATCH 3/6] Bluetooth: btqca: Add IPQ5018 support
From: sashiko-bot @ 2026-06-26 14:10 UTC (permalink / raw)
To: George Moussalem via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260625-ipq5018-bluetooth-v1-3-d999be0e04f7@outlook.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds read of tag_id and tag_len via integer underflow in qca_tlv_check_data.
--
commit 513dbc31af180171927da878907af8ede1372fc7
Author: George Moussalem <george.moussalem@outlook.com>
Bluetooth: btqca: Add IPQ5018 support
Add the IPQ5018 SoC type and support for loading its firmware.
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -378,6 +378,9 @@ static int qca_tlv_check_data(struct hci_dev *hdev,
> break;
>
> case TLV_TYPE_NVM:
> + if (soc_type == QCA_IPQ5018)
> + break;
> +
> if (fw_size < sizeof(struct tlv_type_hdr))
> return -EINVAL;
[ ... ]
> idx = 0;
> data = tlv->data;
> while (idx < length - sizeof(struct tlv_type_nvm)) {
> tlv_nvm = (struct tlv_type_nvm *)(data + idx);
>
> tag_id = le16_to_cpu(tlv_nvm->tag_id);
> tag_len = le16_to_cpu(tlv_nvm->tag_len);
[Severity: High]
This is a pre-existing issue, but does this loop risk an out-of-bounds read
if length is less than the size of struct tlv_type_nvm?
Since sizeof(struct tlv_type_nvm) evaluates to an unsigned size_t, a small
length (like 0 or 1) will cause the subtraction to underflow and wrap around
to a very large positive value.
This would cause the while loop condition in qca_tlv_check_data() to
incorrectly evaluate to true. The assignments to tag_id and tag_len would
then read 4 bytes of memory, which could be out of bounds of the allocated
firmware buffer if a malformed or truncated TLV_TYPE_NVM file is processed.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-ipq5018-bluetooth-v1-0-d999be0e04f7@outlook.com?part=3
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: qcom: ipq5018: add nodes required for Bluetooth support
From: sashiko-bot @ 2026-06-26 14:10 UTC (permalink / raw)
To: George Moussalem via B4 Relay; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260625-ipq5018-bluetooth-v1-6-d999be0e04f7@outlook.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Adding 'syscon' to the 'apcs_glb' compatible string list without updating the devicetree bindings causes a schema validation failure.
--
commit d7e5dd126ba08d18fdb72c0c8149b7aba5e36e82
Author: George Moussalem <george.moussalem@outlook.com>
arm64: dts: qcom: ipq5018: add nodes required for Bluetooth support
Add nodes for the M0 remoteproc, reserved memory carveout, and Bluetooth
to bring up the M0 core and enable the Bluetooth Subsystem.
> diff --git a/arch/arm64/boot/dts/qcom/ipq5018.dtsi b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
> index 6f8004a22a1ff..4fdf20c87b0a9 100644
> --- a/arch/arm64/boot/dts/qcom/ipq5018.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
[ ... ]
> @@ -647,7 +678,8 @@ watchdog: watchdog@b017000 {
>
> apcs_glb: mailbox@b111000 {
> compatible = "qcom,ipq5018-apcs-apps-global",
> - "qcom,ipq6018-apcs-apps-global";
> + "qcom,ipq6018-apcs-apps-global",
> + "syscon";
[Severity: Low]
Will appending "syscon" to the apcs_glb compatible string list cause a
devicetree schema validation failure?
It looks like the qcom,apcs-kpss-global.yaml bindings enforce that the
qcom,ipq5018-apcs-apps-global compatible list must contain exactly two strings.
Running make dtbs_check might fail here without a corresponding update to the
YAML binding to permit this third item.
> reg = <0x0b111000 0x1000>;
> #clock-cells = <1>;
> clocks = <&a53pll>, <&xo_board_clk>, <&gcc GPLL0>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-ipq5018-bluetooth-v1-0-d999be0e04f7@outlook.com?part=6
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: sashiko-bot @ 2026-06-26 14:10 UTC (permalink / raw)
To: George Moussalem via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260625-ipq5018-bluetooth-v1-4-d999be0e04f7@outlook.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The description for the 'interrupts' property is abruptly truncated mid-sentence.
--
commit 6f8911a9af73d725c2b86b32d5b5e404664a0809
Author: George Moussalem <george.moussalem@outlook.com>
dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
This commit documents the Qualcomm IPQ5018 Bluetooth controller by adding a
new device tree binding schema.
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
> new file mode 100644
> index 0000000000000..afd33f8518588
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
[ ... ]
> +properties:
> + compatible:
> + enum:
> + - qcom,ipq5018-bt
> +
> + interrupts:
> + items:
> + - description:
> + Interrupt line from the M0 Bluetooth Subsystem to the host processor
> + to notify it of events such as re
[Severity: Low]
Is this description abruptly truncated mid-sentence? It appears to cut off at
"events such as re".
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-ipq5018-bluetooth-v1-0-d999be0e04f7@outlook.com?part=4
^ permalink raw reply
* Re: [PATCH 5/6] Bluetooth: Introduce Qualcomm IPQ5018 IPC based HCI driver
From: sashiko-bot @ 2026-06-26 14:10 UTC (permalink / raw)
To: George Moussalem via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260625-ipq5018-bluetooth-v1-5-d999be0e04f7@outlook.com>
Thank you for your contribution! Sashiko AI review found 12 potential issue(s) to consider:
- [Critical] Integer underflow when computing auxiliary pointer lengths causes a heap buffer overflow.
- [Critical] Unvalidated shared memory offsets allow the M0 co-processor to trigger arbitrary out-of-bounds reads/writes on the host.
- [High] Missing locking in the TX path corrupts shared IPC ring buffers and state.
- [High] Lifecycle mismanagement of the workqueue and IRQ leads to memory leaks and broken interface toggling.
- [High] Device memory offsets are cast directly to host virtual pointers in ring buffer loops.
- [High] Off-by-one errors during HCI frame length validation allow out-of-bounds memory reads.
- [High] Directly dereferencing __iomem memory via struct pointers violates safe I/O access and triggers synchronous aborts.
- [High] Permanent leak of shared long message buffer capacity on failed short buffer acquires.
- [High] Unvalidated indices from shared memory can hang the workqueue thread in an infinite loop.
- [High] Lockless IPC ring buffers omit memory barriers, risking data corruption due to reordering.
- [Medium] Native arithmetic and bitwise operations on little-endian IPC structures break big-endian compatibility.
- [Medium] Missing acquire/release memory barriers around `desc->running` flag risk NULL pointer dereferences.
--
commit b13642cec5c040da0ea77113de5feea1556c0a79
Author: George Moussalem <george.moussalem@outlook.com>
Bluetooth: Introduce Qualcomm IPQ5018 IPC based HCI driver
This commit adds support for the Qualcomm IPQ5018 Bluetooth chip, using
shared memory for transport between the host and the M0 co-processor.
It implements ring buffers for communication and uses IPC registers
and interrupts for event notifications.
> --- /dev/null
> +++ b/drivers/bluetooth/btqcomipc.c
[ ... ]
> +static struct ring_buffer_info *btss_get_tx_rbuf(struct qcom_btss *desc,
> + bool *is_sbuf_full)
> +{
> + u8 idx;
> + struct ring_buffer_info *rinfo;
> +
> + for (rinfo = &(desc->tx_ctxt->sring_buf_info); rinfo != NULL;
> + rinfo = (struct ring_buffer_info *)(uintptr_t)(rinfo->next)) {
[Severity: High]
Can this direct pointer cast cause a panic?
The firmware provides the next ring buffer via rinfo->next, which is an
__le32 field in shared memory.
Directly casting this 32-bit device offset to a host virtual pointer might
result in an unmapped address being dereferenced on the next loop iteration.
[ ... ]
> +static int btss_send(struct qcom_btss *desc, u16 msg_hdr,
> + struct sk_buff *skb)
> +{
[ ... ]
> + if (len > IPC_MSG_PLD_SZ) {
> + hdr |= IPC_HDR_LONG_MSG;
> +
> + ptr_buf = btss_alloc_lmsg(desc, len,
> + &aux_ptr, &is_lbuf_full);
> + if (IS_ERR(ptr_buf)) {
> + bt_dev_err(hdev, "long msg buf full");
> + hdev->stat.err_tx++;
> + return PTR_ERR(ptr_buf);
> + }
> + }
> +
> + rinfo = btss_get_tx_rbuf(desc, &is_sbuf_full);
> + if (IS_ERR(rinfo)) {
> + bt_dev_err(hdev, "short msg buf full");
> + hdev->stat.err_tx++;
> + return PTR_ERR(rinfo);
> + }
[Severity: High]
Does returning early here permanently leak the long message buffer?
When transmitting a large packet, btss_alloc_lmsg() reserves space in the
long message ring. If the short ring is full and btss_get_tx_rbuf() returns
-EAGAIN, the network stack requeues the packet.
The successfully allocated long message space doesn't appear to be freed,
which could exhaust the IPC transport's capability upon retries.
[ ... ]
> + rbuf->msg_hdr = cpu_to_le16(hdr);
> + rbuf->len = cpu_to_le16(len);
> +
> + rinfo->widx = (rinfo->widx + 1) % desc->tx_ctxt->smsg_buf_cnt;
[Severity: High]
Are memory barriers required here to prevent reordering?
The IPC protocol uses lockless ring buffers across the CPU and coprocessor.
Without a wmb() before updating rinfo->widx, the M0 processor might perceive
the incremented write index before the payload writes are fully visible.
[ ... ]
> +static inline int btss_recv_hci_frame(struct qcom_btss *desc, const u8 *data, size_t len)
> +{
[ ... ]
> + case HCI_EVENT_PKT:
> + {
> + if (len < HCI_EVENT_HDR_SIZE)
> + return -EILSEQ;
[Severity: High]
Could this size check allow out-of-bounds reads?
The len parameter includes the 1-byte packet type prefix in data[0], but
validations like this one do not account for it. If len is exactly
HCI_EVENT_HDR_SIZE (2 bytes), the check passes.
Reading hdr->plen could then access out-of-bounds memory.
[ ... ]
> + if (pkt_len > len)
> + return -EINVAL;
[Severity: High]
Similarly, does this permit an out-of-bounds read during the skb data copy?
If pkt_len is exactly equal to len, the subsequent call to
skb_put_data(skb, data + 1, pkt_len) will copy len bytes from a buffer tail
that only contains len - 1 bytes.
[ ... ]
> +static inline int btss_process_rx(struct qcom_btss *desc,
> + struct ring_buffer_info *rinfo,
> + bool *ack, u8 *rx_count)
> +{
[ ... ]
> + while (ridx != rinfo->widx) {
[Severity: High]
Can this loop hang the workqueue thread?
The termination relies on ridx matching rinfo->widx, which is read from
shared memory. If the firmware provides a corrupted widx that is greater
than or equal to ring_buf_cnt, the modulo-wrapped ridx will never match it.
This could potentially cause an infinite loop, halting IPC processing.
[ ... ]
> + if (rbuf->msg_hdr & IPC_HDR_LONG_MSG) {
[Severity: Medium]
Does this code safely handle endianness?
The IPC protocol structures define sizes and offsets as explicit __le16 and
__le32 fields. Performing bitwise operations like rbuf->msg_hdr &
IPC_HDR_LONG_MSG without conversion could yield reversed bytes on big-endian
architectures.
> + rxbuf = TO_APPS_ADDR(rbuf->payload.lmsg_data);
[Severity: Critical]
Does this translation of the payload offset trust the M0 firmware too much?
TO_APPS_ADDR() translates the untrusted 32-bit value into a direct host
pointer. If the coprocessor supplies a maliciously large offset, the pointer
could aim outside the ioremapped mem_region.
This could allow arbitrary out-of-bounds reads.
[ ... ]
> + blks_consumed = desc->rx_ctxt->lmsg_buf_cnt -
> + lbuf_idx;
> + aux_ptr.len = rbuf->len - (blks_consumed * lsz);
[Severity: Critical]
Can this calculation underflow and cause a heap buffer overflow?
Both blks_consumed and lsz are derived from inputs supplied by the
coprocessor. If (blks_consumed * lsz) is greater than rbuf->len,
aux_ptr.len will wrap to an excessively large 32-bit value.
[ ... ]
> + case IPC_HDR_PKT_TYPE_HCI:
> + buf = kmalloc(rbuf->len, GFP_ATOMIC);
[Severity: Medium]
As noted above, using the __le16 field rbuf->len directly in kmalloc() on
big-endian architectures could lead to excessively large allocation requests.
[ ... ]
> + memcpy_fromio(buf, rxbuf, rbuf->len - aux_ptr.len);
[Severity: Critical]
If aux_ptr.len underflows, this subtraction evaluates back to the large
(blks_consumed * lsz) value.
Since buf is only allocated to rbuf->len, could this copy operation
write far out-of-bounds?
[ ... ]
> +static void btss_worker(struct work_struct *work)
> +{
[ ... ]
> + if (unlikely(!READ_ONCE(desc->running))) {
> + // FW sets offset of RX context info at start of memory region upon boot
> + offset = readl(desc->mem_region);
> + dev_dbg(desc->dev, "offset after M0 boot: 0x%08x\n", offset);
> + desc->rx_ctxt = (struct context_info *)(desc->mem_region + offset);
[Severity: Critical]
Does this offset need bounds checking?
The offset is read directly from the coprocessor and used to set the context
pointer. If an abnormally large offset is provided, this could point outside
the allocated mem_size, leading to out-of-bounds accesses.
[Severity: High]
Does this directly dereference I/O memory using a host struct pointer?
The shared memory region is mapped as void __iomem, but here it is cast to
a native struct context_info pointer. Because the struct is packed, the
compiler might generate unaligned or byte-wise loads when its fields are
accessed.
On architectures like ARM64, unaligned loads to strongly-ordered device
memory can trigger synchronous external aborts.
[ ... ]
> +static int btss_init(struct qcom_btss *desc)
> +{
[ ... ]
> + desc->wq = create_singlethread_workqueue("btss_wq");
> + if (!desc->wq) {
> + dev_err(dev, "Failed to initialize workqueue\n");
> + return -EAGAIN;
> + }
> +
> + INIT_WORK(&desc->work, btss_worker);
> +
> + ret = devm_request_threaded_irq(dev, desc->irq, NULL, btss_irq_handler,
> + IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> + "btss_irq", desc);
[ ... ]
> +static int btqcomipc_close(struct hci_dev *hdev)
> +{
> + struct qcom_btss *desc = hci_get_drvdata(hdev);
> +
> + rproc_shutdown(desc->rproc);
> + msleep(POWER_CONTROL_DELAY_MS);
> +
> + return 0;
> +}
[Severity: High]
Does this implementation leak the workqueue and break interface toggling?
During btqcomipc_open(), btss_init() allocates a new workqueue and requests
the IRQ line. However, btqcomipc_close() doesn't tear down the workqueue or
free the IRQ.
Toggling the interface via 'hciconfig hci0 down && hciconfig hci0 up'
would leak the workqueue, and the subsequent open might fail with -EBUSY
since the IRQ is already registered.
[ ... ]
> +static int btqcomipc_send(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + u16 hdr = FIELD_PREP(IPC_HDR_PKT_TYPE_MASK, IPC_HDR_PKT_TYPE_HCI);
> + struct qcom_btss *desc = hci_get_drvdata(hdev);
> + int ret;
> +
> + if (unlikely(!READ_ONCE(desc->running))) {
[Severity: Medium]
Is a memory barrier needed here to safely access the dependent context
pointers?
In btss_recv_cust_frame(), pointers to shared context regions are populated
before calling WRITE_ONCE(desc->running, true). Without smp_store_release()
and smp_load_acquire(), weakly-ordered architectures could reorder the
execution.
This could allow the path below to observe desc->running as true while
reading a stale or NULL tx_ctxt.
> + bt_dev_err(hdev, "BTSS not initialized, failed to send message");
> + ret = -ENODEV;
> + goto free_skb;
> + }
> +
> + ret = btss_send(desc, hdr, skb);
[Severity: High]
Can this lockless call corrupt the shared IPC ring buffers?
btqcomipc_send() executes locklessly from the network stack context, while
btss_worker() can process the TX queue simultaneously. Both paths modify the
exact same ring buffer indices like rinfo->widx and internal state.
Could this race lead to ring buffer corruption or packet loss without
acquiring desc->lock?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-ipq5018-bluetooth-v1-0-d999be0e04f7@outlook.com?part=5
^ permalink raw reply
* Re: [PATCH 2/6] remoteproc: qcom: Add M0 BTSS secure PIL driver
From: sashiko-bot @ 2026-06-26 14:10 UTC (permalink / raw)
To: George Moussalem via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260625-ipq5018-bluetooth-v1-2-d999be0e04f7@outlook.com>
Thank you for your contribution! Sashiko AI review found 10 potential issue(s) to consider:
- [High] Redundant request_firmware call leaks newly allocated firmware and metadata on success path.
- [High] Direct return on kstrdup failure leaks previously acquired metadata and firmware objects.
- [High] Heap buffer underflow and overflow when formatting split segment filenames with sprintf.
- [High] 32-bit integer overflow in ELF segment bounds validation allows out-of-bounds memory writes.
- [High] Missing size validation for split firmware segments leads to out-of-bounds reads.
- [High] Out-of-bounds read due to unvalidated ELF headers and hardcoded program header offset.
- [High] Time-of-Check to Time-of-Use (TOCTOU) vulnerability due to parsing ELF headers from a different firmware copy than the one authenticated.
- [Medium] Subsystem guide violation: Mixing goto-based error handling with scope-based __free() cleanup.
- [Medium] Failure to zero-initialize the BSS section of ELF segments exposes stale memory to the peripheral.
- [Medium] Missing reset assertion on late probe failures and driver removal leads to resource leaks and state mismatch.
--
commit a3d2212c4a13a5646a7fb048e4d391fc0784f11e
Author: George Moussalem <george.moussalem@outlook.com>
Subject: remoteproc: qcom: Add M0 BTSS secure PIL driver
This commit introduces a new Peripheral Image Loader driver for the M0
bluetooth subsystem found in the IPQ5018 SoC. The driver brings up the
M0 core by loading signed firmware, authenticating it via TrustZone,
and starting the peripheral using a Secure Channel Manager call.
> diff --git a/drivers/remoteproc/qcom_m0_btss_pil.c b/drivers/remoteproc/qcom_m0_btss_pil.c
> new file mode 100644
> index 0000000000000..7168e270e4d46
> --- /dev/null
> +++ b/drivers/remoteproc/qcom_m0_btss_pil.c
[ ... ]
> +static int m0_btss_load(struct rproc *rproc, const struct firmware *fw)
> +{
> + struct m0_btss *desc = rproc->priv;
> + const struct elf32_phdr *phdrs;
> + const struct firmware *seg_fw;
> + const struct elf32_phdr *phdr;
> + const struct elf32_hdr *ehdr;
> + void __iomem *metadata;
> + size_t metadata_size;
> + int i, ret;
> +
> + ehdr = (const struct elf32_hdr *)fw->data;
> + phdrs = (const struct elf32_phdr *)(ehdr + 1);
[Severity: High]
Does this code perform an out-of-bounds read if the firmware file is smaller
than the ELF header structure? The pointer is cast and dereferenced without
validating that the provided firmware is large enough.
[Severity: High]
Is there an issue with using a hardcoded offset to locate the program headers
instead of using the standard e_phoff field from the ELF header? If the file
uses a non-standard layout, it could parse arbitrary memory as program
headers.
> +
> + ret = request_firmware(&fw, rproc->firmware, rproc->dev.parent);
[Severity: High]
Does this code introduce a time-of-check to time-of-use vulnerability? The
ehdr and phdrs pointers are established from the original fw parameter, but
then a new fw copy is requested and authenticated by TrustZone. If the file
changes between these reads, could malicious segment locations from the first
unauthenticated read be used to subvert the loading of the authenticated data?
[Severity: High]
Is this call to request_firmware() redundantly overwriting the local fw
parameter, preventing the original structure from being accessed?
> + if (ret) {
> + dev_err(rproc->dev.parent, "Failed to request firmware: %d\n",
> + ret);
> + return ret;
> + }
> +
> + metadata = qcom_mdt_read_metadata(fw, &metadata_size, rproc->firmware,
> + rproc->dev.parent);
> + if (IS_ERR(metadata)) {
> + ret = PTR_ERR(metadata);
> + dev_err(rproc->dev.parent,
> + "Failed to read firmware metadata: %d\n", ret);
> + goto release_fw;
> + }
> +
> + ret = qcom_scm_pas_init_image(BTSS_PAS_ID, metadata,
> + metadata_size, NULL);
> + if (ret) {
> + dev_err(rproc->dev.parent, "PAS init image failed: %d\n", ret);
> + goto free_metadata;
> + }
> +
> + for (i = 0; i < ehdr->e_phnum; i++) {
> + char *seg_name __free(kfree) = kstrdup(rproc->firmware,
> + GFP_KERNEL);
[Severity: Medium]
Is it safe to mix goto-based error handling with scope-based cleanup helpers
like __free(kfree) in the same function? The kernel cleanup subsystem
guidelines indicate that functions should either use goto-based cleanup
exclusively, or scope-based cleanup exclusively, to prevent confusing
ownership semantics.
> + if (!seg_name)
> + return -ENOMEM;
[Severity: High]
Does returning directly here leak the metadata buffer and the locally
requested fw structure? It appears this direct return bypasses the
free_metadata and release_fw cleanup labels.
> +
> + phdr = &phdrs[i];
> +
> + /* Only process valid loadable data segments */
> + if (phdr->p_type != PT_LOAD || !phdr->p_memsz)
> + continue;
> +
> + if (phdr->p_vaddr + phdr->p_filesz > desc->mem_size) {
[Severity: High]
Can the addition of phdr->p_vaddr and phdr->p_filesz overflow? Since both
are read directly from the ELF header as 32-bit integers, a crafted firmware
could provide values that wrap around the 32-bit limit, passing the bounds
check against desc->mem_size and allowing out-of-bounds memory writes.
> + dev_err(rproc->dev.parent,
> + "Segment data exceeds the reserved memory area!\n");
> + goto free_metadata;
> + }
> +
> + /* Check if firmware is split across multiple segment files */
> + if (phdr->p_offset > fw->size ||
> + phdr->p_offset + phdr->p_filesz > fw->size) {
> + sprintf(seg_name + strlen(seg_name) - 3, "b%02d", i);
[Severity: High]
Could this sprintf() call result in a heap buffer underflow or overflow?
If the provided firmware-name is fewer than 3 characters long, the pointer
arithmetic could underflow. Additionally, if the unvalidated ehdr->e_phnum
produces a large index, the formatted string could overflow the allocated
buffer.
> + ret = request_firmware(&seg_fw, seg_name,
> + rproc->dev.parent);
> + if (ret) {
> + dev_err(rproc->dev.parent,
> + "Could not find split segment binary: %s\n",
> + seg_name);
> + goto free_metadata;
> + }
> +
> + /*
> + * Use the virtual instead of the physical address as
> + * the offset
> + */
> + memcpy_toio(desc->mem_region + phdr->p_vaddr,
> + seg_fw->data, phdr->p_filesz);
[Severity: High]
Does this memcpy_toio() read past the end of seg_fw->data? It uses
phdr->p_filesz from the main ELF header, but there doesn't seem to be a check
ensuring that the loaded seg_fw->size is actually at least that large.
> +
> + release_firmware(seg_fw);
> + } else {
> + memcpy_toio(desc->mem_region + phdr->p_vaddr,
> + fw->data + phdr->p_offset, phdr->p_filesz);
[Severity: Medium]
If an ELF segment's memory size (p_memsz) exceeds its file size (p_filesz),
does the remaining memory need to be zero-initialized for the BSS section?
The driver currently only copies p_filesz bytes, which might leave stale
kernel memory exposed to the peripheral.
> + }
> + }
> +
> + return 0;
[Severity: High]
Does this success path leak the dynamically allocated metadata buffer and the
firmware structure? The function returns directly without freeing them.
> +
> +free_metadata:
> + kfree(metadata);
> +release_fw:
> + release_firmware(fw);
> + return ret;
> +}
[ ... ]
> +static int m0_btss_pil_probe(struct platform_device *pdev)
> +{
[ ... ]
> + desc->btss_reset = devm_reset_control_get(dev, "btss_reset");
> + if (IS_ERR_OR_NULL(desc->btss_reset))
> + return dev_err_probe(dev, PTR_ERR(desc->btss_reset),
> + "unable to acquire btss_reset\n");
> +
> + ret = reset_control_deassert(desc->btss_reset);
[Severity: Medium]
Is a cleanup action needed to assert the reset if probe fails later or if the
driver is unbound? The probe function deasserts desc->btss_reset but
doesn't seem to register a corresponding devm_add_action_or_reset() to handle
teardown.
> + if (ret)
> + return dev_err_probe(rproc->dev.parent, ret,
> + "Failed to deassert reset\n");
> +
> + rproc->auto_boot = false;
> + ret = devm_rproc_add(dev, rproc);
> + if (ret)
> + return ret;
> +
> + platform_set_drvdata(pdev, rproc);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-ipq5018-bluetooth-v1-0-d999be0e04f7@outlook.com?part=2
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg @ 2026-06-26 14:11 UTC (permalink / raw)
To: Dmitry Torokhov, Bjorn Andersson
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Konrad Dybcio,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel, Rob Herring
In-Reply-To: <aj4QUY5p7gqLplVT@google.com>
[...]
>
> OK, I applied the binding change, the dts change should go through some
> other tree.
>
> Thanks.
>
Thank you, I think Bjorn will be picking the dts change :)
David
^ permalink raw reply
* Re: [PATCH v11 5/6] arm64: dts: qcom: monaco: Add OPP-table for ICE UFS and ICE eMMC nodes
From: Konrad Dybcio @ 2026-06-26 14:28 UTC (permalink / raw)
To: Abhinaba Rakshit
Cc: Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam,
James E.J. Bottomley, Martin K. Petersen, Adrian Hunter,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neeraj Soni, Harshal Dev, Kuldeep Singh, linux-arm-msm,
linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <ajjmXMKdWzae5qqk@hu-arakshit-hyd.qualcomm.com>
On 6/22/26 9:38 AM, Abhinaba Rakshit wrote:
> On Thu, Jun 18, 2026 at 03:04:57PM +0200, Konrad Dybcio wrote:
>> On 6/8/26 11:47 PM, Abhinaba Rakshit wrote:
>>> Qualcomm Inline Crypto Engine (ICE) platform driver now, supports
>>> an optional OPP-table.
>>>
>>> Add OPP-table for ICE UFS and ICE eMMC device nodes for Monaco
>>> platform.
>>>
>>> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/monaco.dtsi | 37 ++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 37 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
>>> index a1b6e6211b84d0d5008231c55613a0ccd61b9450..d9298d8b7874b8669b2cded2a28a99dce6eadbda 100644
>>> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
>>> @@ -2742,6 +2742,27 @@ ice: crypto@1d88000 {
>>> clock-names = "core",
>>> "iface";
>>> power-domains = <&gcc GCC_UFS_PHY_GDSC>;
>>> +
>>> + operating-points-v2 = <&ice_opp_table>;
>>> +
>>> + ice_opp_table: opp-table {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-75000000 {
>>> + opp-hz = /bits/ 64 <75000000>;
>>> + required-opps = <&rpmhpd_opp_svs_l1>;
>>> + };
>>> +
>>> + opp-201600000 {
>>> + opp-hz = /bits/ 64 <201600000>;
>>> + required-opps = <&rpmhpd_opp_svs_l1>;
>>> + };
>>
>> Since 75 MHz and 201.6 Mhz require the same power level, is the former
>> OPP any useful?
>
> Yes, both use the same power requirements. However recommended by the ICE team,
> the DT should include all opp/freq supported by the hardware.
Is there any reason at all where the OS would prefer the lower OPP?
I think you at one point mentioned some dependency vs the storage
controller's clock frequency
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Laurent Pinchart @ 2026-06-26 14:30 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-2-47178be927b4@ideasonboard.com>
Hi Kieran,
Thank you for the patch.
On Fri, Jun 26, 2026 at 01:07:54PM +0100, Kieran Bingham wrote:
> Expand the documentation of the video-interface-devices orientation to
> reference the include/dt-bindings/media/video-interface-devices.h header
> which provides human readable defines for the orientation enum, to help
> avoid hardcoding values in dts.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> .../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> index a81d2a155fe6..c9c3f4f16719 100644
> --- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> @@ -392,17 +392,22 @@ properties:
> The orientation of a device (typically an image sensor or a flash LED)
> describing its mounting position relative to the usage orientation of the
> system where the device is installed on.
> + See include/dt-bindings/media/video-interface-devices.h.
If you want this to be a separate paragraph, you need a blnk line on
top. Otherwise, Move "See" to the previous line.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> $ref: /schemas/types.yaml#/definitions/uint32
> enum:
> - # Front. The device is mounted on the front facing side of the system. For
> - # mobile devices such as smartphones, tablets and laptops the front side
> - # is the user facing side.
> + # MEDIA_ORIENTATION_FRONT
> + # The device is mounted on the front facing side of the system. For
> + # mobile devices such as smartphones, tablets and laptops the front
> + # side is the user facing side.
> - 0
> - # Back. The device is mounted on the back side of the system, which is
> + # MEDIA_ORIENTATION_BACK
> + # The device is mounted on the back side of the system, which is
> # defined as the opposite side of the front facing one.
> - 1
> - # External. The device is not attached directly to the system but is
> - # attached in a way that allows it to move freely.
> + # MEDIA_ORIENTATION_EXTERNAL
> + # The device is not attached directly to the system but is attached in
> + # a way that allows it to move freely.
> - 2
>
> additionalProperties: true
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: media: i2c: Utilise video-interface-devices enums
From: Laurent Pinchart @ 2026-06-26 14:31 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-3-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:55PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the existing examples throughout the bindings documentation for
> camera sensors.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml | 3 ++-
> 12 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> index 1a57f2aa1982..b7bc6ba26e6e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> @@ -86,6 +86,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -102,7 +103,7 @@ examples:
> vddio-supply = <®_camera_vddio>;
> reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
> shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> index 6f2017c75125..b9c61395b24f 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> @@ -69,6 +69,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -84,7 +85,7 @@ examples:
> avdd-supply = <&ov08d10_vdda_2v8>;
> dvdd-supply = <&ov08d10_vddd_1v2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> index d96199031b66..fcd617848ce3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> @@ -96,6 +96,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -114,7 +115,7 @@ examples:
> powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> index ad07204057f9..6df62fd0c0c0 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> @@ -85,6 +85,7 @@ examples:
> - |
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> i2c {
> @@ -108,7 +109,7 @@ examples:
> dovdd-supply = <&vcc_2v8>;
>
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> ucam_out: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> index 3368b3bd8ef2..5732657e1484 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> @@ -103,6 +103,7 @@ examples:
> - |
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> i2c {
> @@ -126,7 +127,7 @@ examples:
> dovdd-supply = <&vcc_2v8>;
>
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> ucam_out: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> index 2b6143aff391..24787c9aa155 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> @@ -72,6 +72,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -87,7 +88,7 @@ examples:
> powerdown-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> rotation = <180>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
>
> port {
> endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> index 20f48d5e9b2d..56fb5f18f07b 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> @@ -69,6 +69,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -84,7 +85,7 @@ examples:
> dvdd-supply = <&camera_vddd_1v2>;
> avdd-supply = <&camera_vdda_2v7>;
>
> - orientation = <1>;
> + orientation = <MEDIA_ORIENTATION_BACK>;
> rotation = <90>;
>
> nvmem = <&eeprom>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> index 6050d7e7dcfe..b4a88eaa7ef2 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> @@ -74,6 +74,7 @@ examples:
> - |
> #include <dt-bindings/clock/qcom,camcc-sdm845.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -98,7 +99,7 @@ examples:
> pinctrl-0 = <&cam_front_default>;
>
> rotation = <270>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> cam_front_endpoint: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> index 7c11e871dca6..69a37ff68db3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> @@ -86,6 +86,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -98,7 +99,7 @@ examples:
> clocks = <&clock_cam>;
> dvdd-supply = <&vcc1v1_cam>;
> lens-focus = <&vcm>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&vcc1v8_cam>;
> reset-gpios = <&gpio_expander 14 GPIO_ACTIVE_LOW>;
> rotation = <180>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> index 060ac6829b66..db9f0c15576c 100644
> --- a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> @@ -105,6 +105,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -123,7 +124,7 @@ examples:
> reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> st,leds = <2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> index c6673b8539db..48db22ca4a7e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> @@ -107,6 +107,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -125,7 +126,7 @@ examples:
> reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> st,leds = <6>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> index bc339a7374b2..4a66cb711372 100644
> --- a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> @@ -173,6 +173,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -196,7 +197,7 @@ examples:
> vddgpio-0-supply = <&vsys_v4p2>;
> vddgpio-1-supply = <&vsys_v4p2>;
>
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <0>;
>
> sensors {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:33 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-4-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:56PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the nvidia device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi | 3 ++-
> arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi | 3 ++-
> arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 4 +++-
> arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
> 4 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
> index 892d718294dd..a7fdd194300c 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
> +++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
> @@ -3,6 +3,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/power/summit,smb347-charger.h>
> #include <dt-bindings/thermal/thermal.h>
>
> @@ -991,7 +992,7 @@ front-camera@48 {
> vdd-supply = <&vddio_cam>;
> vaa-supply = <&avdd_cam1>;
>
> - orientation = <0>; /* Front camera */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
> <&tegra_car TEGRA30_CLK_CSUS>;
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
> index bf1c3a31d406..76286e15684c 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
> +++ b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
> @@ -3,6 +3,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/thermal/thermal.h>
>
> #include "tegra30.dtsi"
> @@ -1262,7 +1263,7 @@ front-camera@48 {
> vdd-supply = <&vdd_1v8_cam>;
> vaa-supply = <&avdd_2v85_fcam>;
>
> - orientation = <0>; /* Front camera */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
> <&tegra_car TEGRA30_CLK_CSUS>;
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
> index 896639599c12..28680063bcc0 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
> +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
> @@ -1,6 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> /dts-v1/;
>
> +#include <dt-bindings/media/video-interface-devices.h>
> +
> #include "tegra30-lg-x3.dtsi"
>
> / {
> @@ -132,7 +134,7 @@ front-camera@48 {
> vdd-supply = <&vt_1v8_front>;
> vaa-supply = <&vt_2v8_front>;
>
> - orientation = <0>; /* Front camera */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
> <&tegra_car TEGRA30_CLK_CSUS>;
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> index 60e8a19aa70e..c58e3026a115 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> @@ -4,6 +4,7 @@
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/leds/common.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/mfd/max77620.h>
> #include <dt-bindings/thermal/thermal.h>
>
> @@ -1216,7 +1217,7 @@ rear-camera@10 {
> dvdd-supply = <&vdd_1v2_rear>;
> avdd-supply = <&vdd_2v7_rear>;
>
> - orientation = <1>; /* Rear camera */
> + orientation = <MEDIA_ORIENTATION_REAR>;
This should be MEDIA_ORIENTATION_BACK. And you should compile all the
device trees the series touch.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> rotation = <90>;
>
> nvmem = <&m24c08>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Bryan O'Donoghue @ 2026-06-26 14:33 UTC (permalink / raw)
To: Hans de Goede, Rafael J . Wysocki, Bjorn Andersson, Konrad Dybcio
Cc: Srinivas Kandagatla, Krzysztof Kozlowski, Dmitry Baryshkov,
Bartosz Golaszewski, Abel Vesa, linux-arm-msm, devicetree,
linux-acpi
In-Reply-To: <20260623145225.143218-1-johannes.goede@oss.qualcomm.com>
On 23/06/2026 15:52, Hans de Goede wrote:
> Comments, thoughts ?
Throw out DT and just do this...
One thing I like about this approach TBH is that you don't do the easy
thing of presuming to push the hard work into the bootloader - thus
creating a dependency on bootloader.
We've had _alot_ of problems doing DT selectivity to get OSes installed
on arm64 laptops. You mentioned I2C-HID devices and EC controllers which
I agree are a good and obvious targets.
I don't think this can replace a full and complete DT but, then I don't
think that should be the objective.
Much like installing cursed OSes like Windows on "normal" laptops or x86
machines, you'd expect to boot in ACPI mode have enough of the OS
running to install more of the OS - which I think _can_ be a viable
objective with an ACPI-DT translator.
Sadly OpenBSD could boot all the way to console on the Qcom laptops
where Linux could not - because ACPI support was better there.
And, we have Nvidia laptops coming too, Windows laptops which will parse
ACPI tables to boot.
There's almost no upside in having ACPI data and not trying to make
maximal use of it, especially if you don't have a DT supplied by
antecedent boot stages.
---
bod
^ permalink raw reply
* Re: [PATCH v2 5/8] arm64: dts: freescale: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:33 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-5-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:57PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the freescale/NXP device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> .../boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso | 3 ++-
> arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> index e5a2b3780215..7b44ae0f19b2 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> #include "imx8mp-pinfunc.h"
>
> @@ -47,7 +48,7 @@ camera@10 {
> VANA-supply = <®_cam>;
> VDIG-supply = <®_cam>;
> VDDL-supply = <®_cam>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> index f5d529c5baf3..178cfad93483 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> @@ -8,6 +8,7 @@
> #include "dt-bindings/input/input.h"
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include "dt-bindings/pwm/pwm.h"
> #include "dt-bindings/usb/pd.h"
> #include "imx8mq.dtsi"
> @@ -1116,7 +1117,7 @@ camera_front: camera@20 {
> vddd-supply = <®_vcam_1v2>;
> vddio-supply = <®_csi_1v8>;
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> camera1_ep: endpoint {
--
Regards,
Laurent Pinchart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox