* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Mathieu Poirier @ 2026-05-14 17:35 UTC (permalink / raw)
To: Shenwei Wang
Cc: Arnaud POULIQUEN, Beleswar Prasad Padhi, Andrew Lunn,
Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <PAXPR04MB9185BFA6E7375FAD0B15B021893C2@PAXPR04MB9185.eurprd04.prod.outlook.com>
On Thu, May 07, 2026 at 07:43:33PM +0000, Shenwei Wang wrote:
>
>
> > -----Original Message-----
> > From: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Sent: Thursday, May 7, 2026 12:13 PM
> > To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
> > Cc: Beleswar Prasad Padhi <b-padhi@ti.com>; Shenwei Wang
> > <shenwei.wang@nxp.com>; Andrew Lunn <andrew@lunn.ch>; Linus Walleij
> > <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> > <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> > <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> > <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> > <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> > gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> > devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> > imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> > imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > > > From my perspective, based on your proposal:
> > > > > 1) Linux should send a get_config message to the remote proc (0x405 ->
> > 0xD). 2) The remote processor would respond with the list of ports, associated
> > > > > with an remote endpoint addresses.
> > > >
> > > >
> > > > Agreed, we can scale it for multiple remote endpoints like this.
> > > >
> > > > > 3) Linux would parse the response, compare it with the DT, enable the
> > GPIO
> > > > > ports accordingly, creating it local endpoint and associating it with
> > > > > the remote endpoint.
> > > > > Using name service to identify the ports should avoid step 1 & 2 ...
> > > >
> > > >
> > > > Yes, but won't that make a lot of hard-codings in the driver?
> > > >
> > > > +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > > > + { .name = "rpmsg-io-25" },
> > > > + { .name = "rpmsg-io-32" },
> > > > + { .name = "rpmsg-io-35" },
> > > > + { },
> > > > +};
> > > >
> > > > What if tomorrow another vendor decides to add more remoteproc
> > > > controlled GPIO ports to Linux, they would have to update this
> > > > struct in the driver everytime. And the port indexes (25/32/35)
> > > > could also differ between vendors. We should make the driver dynamic
> > > > i.e. vendor agnostic.
> > > >
> > > > I think querying the remote firmware at runtime (step 1 & 2 above)
> > > > is a common design pattern and makes the driver vendor agnostic. But
> > > > feel free to correct me.
> > > >
> > >
> > > You are right. My proposal would require a patch in rpmsg-core. The
> > > idea of allowing a postfix in the compatible string has been discussed
> > > before, but, if I remember correctly, it was not concluded.
> > >
> >
> > I also remember discussing this. I even reviewed one of Arnaud's patch and
> > submitted one myself. This must have been in 2020 and the reason why it wasn't
> > merged has escaped my memory.
> >
> > > /* rpmsg devices and drivers are matched using the service name */
> > > static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> > > const struct rpmsg_device_id *id) {
> > > size_t len;
> > >
> > > + len = strnlen(id->name, RPMSG_NAME_SIZE);
> > > + if (len && id->name[len - 1] == '*')
> > > + return !strncmp(id->name, rpdev->id.name, len - 1);
> > >
> > > return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> > > }
> > >
> > > Then, in rpmsg-gpio, and possibly in other drivers such as rpmsg-tty
> > > and a future rpmsg-i2c, we could use:
> > > static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > > { .name = "rpmsg-io" },
> > > { .name = "rpmsg-io-*" },
> > > { },
> > > };
> >
> > That was my initial approach. We don't even need an additional "rpmsg-io-*" in
> > rpmsg_gpio_channel_id_table[]. All we need is:
> >
> > /* rpmsg devices and drivers are matched using the service name */ static inline
> > int rpmsg_id_match(const struct rpmsg_device *rpdev,
> > const struct rpmsg_device_id *id) {
> > + size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
> >
> > - return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> > + return strncmp(id->name, rpdev->id.name, len) == 0;
> > }
> >
>
> If we encode the port index directly into ept->src, for example:
>
> ept->src = (baseaddr << 8) | port_index;
>
There is no rpmsg_endpoint::src. You likely meant ept->addr. This would work
but not optimal on two front:
(1) rpms_endpoint::addr is a u32 and idr_alloc() returns an 'int'. As such
there is a possibility of conflict. I concede the possibility is marginal, but
it still exists.
(2) By proceeding this way, the kernel exposes the GPIO controller it knows
about. It is preferrable to have the remote processor tell the kernel about the
GPIO controller it wants.
I am done reviewing this revision. Given the amount of refactoring needed, I
will not look at the code. Please refer to this reply [1] for what I am
expecting in the next revision.
[1]. https://lwn.net/ml/all/CANLsYkwBk0KbN-k9ce+5=oT+scdZ3nU5AOr3Fz4zT=0AFzghDA@mail.gmail.com/
> where baseaddr can be derived from the channel address, we can avoid the possible address conflict.
>
> With this approach, the patch to rpmsg-core would no longer be necessary.
>
> Thanks,
> Shenwei
>
> > And let the rpmsg-virtio-gpio driver parse @rpdev->id.name to match with a
> > GPIO controller in the DT.
> >
> > >
> > > If exact name matching is strongly required, then this proposal would
> > > not be suitablea.
> > >
> > > A third option would be a combination of both approaches: instantiate
> > > the device using the same name service from the remote side, as done
> > > in rpmsg-tty. In that case, a get_config message, or a similar
> > > mechanism, would also be needed to retrieve the port information from the
> > remote side.
> > >
> >
> > I'm not overly fond of a get_config message because it is one more thing we have
> > to define and maintain.
> >
> > Arnaud: is there a get_config message already defined for rpmsg_tty?
> >
> > Beleswar: Can you provide a link to a virtio device that would use a get_config
> > message?
> >
> > > Tanmaya also proposed another alternative based on reserved addresses.
> > >
> > > At this point, I suggest letting Mathieu review the discussion and
> > > recommend the most suitable approach.
> > >
> > > Thanks,
> > > Arnaud
> > >
> > > > >
> > > > > At the end, whatever solution is implemented, my main concern is
> > > > > that the Linux driver design should, if possible, avoid adding
> > > > > unnecessary complexity or limitations on the remote side (for instance in
> > openAMP project).
> > > >
> > > >
> > > > Yes definitely, I want the same. Feel free to let me know if this
> > > > does not suit with the OpenAMP project.
> > > >
> > > > Thanks,
> > > > Beleswar
> > > >
> > > > >
> > > > > Thanks,
> > > > > Arnaud
> > > > >
> > > > >
> > > > > > So Linux does not need to send the port idx everytime while
> > > > > > sending a gpio message anymore.
> > > > > >
> > > > > > Thanks,
> > > > > > Beleswar
> > > > > >
> > > > > > [...]
> > > > > >
> > > > >
> > >
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Jamie Nguyen @ 2026-05-14 17:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260514-serious-bumblebee-of-prowess-b6bf2b@sudeepholla>
> On May 14, 2026, at 2:16 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
>
> On Wed, May 13, 2026 at 07:48:05PM +0000, Jamie Nguyen wrote:
>>
>>
>>> On May 13, 2026, at 10:15 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
>>>
>>> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
>>>> __ffa_partition_info_get_regs() walks the response with a hardcoded
>>>> 24-byte stride (regs += 3) even though the SPMC tells us the actual
>>>> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
>>>> read into buf_sz and then thrown away.
>>>>
>>>> That works while every SPMC returns the FF-A v1.1 layout, but it falls
>>>> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
>>>> strides over half a descriptor at a time and ends up parsing every
>>>> other entry from a slice of two adjacent ones.
>>>>
>>>> The FF-A spec (v1.2, section 18.5) says that the producer should
>>>> report the descriptor size, and the consumer is supposed to stride by
>>>> that size and ignore any trailing fields it doesn't understand. The
>>>> non-REGS path (__ffa_partition_info_get) does this already, and the
>>>> REGS path should match.
>>>>
>>>> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
>>>> reports something we can't safely walk.
>>>>
>>>
>>> Can you check if the issue is addressed in -next by:
>>> Commit 3974ea193840 ("firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies")
>>
>> Thanks for the pointer. I tested 3974ea193840 on the same hardware
>> that reproduces the bug, but the descriptor-stride issue is still
>> present.
>>
>> The relevant loop at the end of __ffa_partition_info_get_regs()
>> still has:
>>
>> buf_sz = PARTITION_INFO_SZ(partition_info.a2);
>> if (buf_sz > sizeof(*buffer))
>> buf_sz = sizeof(*buffer);
>> ...
>> for (idx = 0; idx < nr_desc; idx++, buf++) {
>> ...
>> regs += 3; /* bug is here */
>> }
>>
>> With 48-byte descriptors the SPMC returns nr_desc = 2 per call,
>
> Well why is the firmware sending 48byte entry when 24byte is expected.
We're starting to test with a v1.3 SPMC implementation. UEFI brings
up its FF-A driver first and negotiates v1.3, which the SPMC then must
keep for the lifetime of the primary VM per DEN0077A v1.2 REL0 section
13.2.2 [0]:
"Once an FF-A version has been negotiated between a caller and a
callee, the version may not be changed for the lifetime of the
calling component.”
When Linux later asks for v1.2 the SPMC stays at 1.3 and emits the
48-byte v1.3 layout: DEN0077A v1.3 ALP4 section 13.9 [1]: "Size of each
descriptor is 48 bytes as per the FF-A v1.3 spec”.
[0]: https://developer.arm.com/documentation/den0077/j
[1]: https://developer.arm.com/documentation/den0077/o
> --
> Regards,
> Sudeep
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Jamie Nguyen @ 2026-05-14 17:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260514-generous-undetectable-mastiff-cc43d3@sudeepholla>
> On May 14, 2026, at 2:31 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
>
> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
>> __ffa_partition_info_get_regs() walks the response with a hardcoded
>> 24-byte stride (regs += 3) even though the SPMC tells us the actual
>> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
>> read into buf_sz and then thrown away.
>>
>> That works while every SPMC returns the FF-A v1.1 layout, but it falls
>> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
>> strides over half a descriptor at a time and ends up parsing every
>> other entry from a slice of two adjacent ones.
>>
>> The FF-A spec (v1.2, section 18.5) says that the producer should
>> report the descriptor size, and the consumer is supposed to stride by
>> that size and ignore any trailing fields it doesn't understand. The
>> non-REGS path (__ffa_partition_info_get) does this already, and the
>> REGS path should match.
>>
>> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
>> reports something we can't safely walk.
>>
>> Fixes: 7bc0f589c81d ("firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()")
>> Signed-off-by: Jamie Nguyen <jamien@nvidia.com>
>> ---
>> drivers/firmware/arm_ffa/driver.c | 35 ++++++++++++++++++++++++++++---
>> 1 file changed, 32 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
>> index c72ee4756585..b712e8a03dab 100644
>> --- a/drivers/firmware/arm_ffa/driver.c
>> +++ b/drivers/firmware/arm_ffa/driver.c
>> @@ -321,6 +321,22 @@ __ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
>> #define PART_INFO_ID(x) ((u16)(FIELD_GET(PART_INFO_ID_MASK, (x))))
>> #define PART_INFO_EXEC_CXT(x) ((u16)(FIELD_GET(PART_INFO_EXEC_CXT_MASK, (x))))
>> #define PART_INFO_PROPERTIES(x) ((u32)(FIELD_GET(PART_INFO_PROPS_MASK, (x))))
>> +
>> +/*
>> + * FF-A v1.2 section 13.9 Table 13.40: registers x3..x17 carry the partition
>> + * descriptors, i.e. 15 u64 of payload per FFA_PARTITION_INFO_GET_REGS call.
>> + */
>> +#define FFA_PART_INFO_REGS_PAYLOAD_U64 15
>> +
>> +/*
>> + * FF-A v1.1 partition information descriptor (FF-A v1.2 section 6.2.1
>> + * Table 6.1): id (2) + exec_ctxt (2) + properties (4) + UUID (16) = 24
>> + * bytes. This is the minimum size the SPMC must report; the kernel reads
>> + * exactly these fields and ignores any trailing ones per the forward-
>> + * compatibility rules in FF-A v1.2 section 18.5.
>> + */
>
> I can't see any such details is the above mention version and section.
> Can you confirm you are looking at [1] ?
Yes, I am looking at [1]. The size field and the rule are in two
different places:
- Section 13.9 Table 13.40, page 188:
x2 Bits[63:48] = "Size in bytes of each partition information
entry descriptor."
(read into buf_sz today and discarded)
- Section 18.5 page 264 rule 4:
"A consumer of this data structure uses the size corresponding
to the Framework version it implements to consume only fields
defined in its version. Additional fields in the producer's
version of this data structure are safely ignored enabling
forward compatibility."
If you agree, I'll rebase against linux-next and send a v2.
[1]: https://developer.arm.com/documentation/den0077/j
> --
> Regards,
> Sudeep
>
> [1] https://developer.arm.com/documentation/den0077/j
^ permalink raw reply
* Re: [PATCH v2] perf record: Refactor ARM64 leaf caller setup out of arch
From: Ian Rogers @ 2026-05-14 17:38 UTC (permalink / raw)
To: acme, james.clark, namhyung
Cc: adrian.hunter, alexander.shishkin, dapeng1.mi, john.g.garry,
jolsa, leo.yan, linux-arm-kernel, linux-kernel, linux-perf-users,
mark.rutland, mike.leach, mingo, peterz, shimin.guo, will
In-Reply-To: <20260512054140.3427725-1-irogers@google.com>
On Mon, May 11, 2026 at 10:41 PM Ian Rogers <irogers@google.com> wrote:
>
> Code in tools/perf/arch causes portability issues/opaqueness and LTO
> issues due to the use of weak symbols. Move the adding of LR to the
> sample_user_regs into arm64-frame-pointer-unwind-support.c conditional
> on EM_HOST == EM_AARCH64 (false on all non-ARM64 builds). This also
> better encapsulates the use of the sampled registers by
> get_leaf_frame_caller_aarch64 and the set up by the new
> add_leaf_frame_caller_opts_aarch64, exposing opportunities for
> possibly sampling PC and SP to help the unwinder.
>
> Reviewed-by: James Clark <james.clark@linaro.org>
> Signed-off-by: Ian Rogers <irogers@google.com>
Ping.
Thanks,
Ian
> ---
> tools/perf/arch/arm64/util/Build | 1 -
> tools/perf/arch/arm64/util/machine.c | 12 ------------
> tools/perf/builtin-record.c | 11 +++++------
> tools/perf/util/arm64-frame-pointer-unwind-support.c | 6 ++++++
> tools/perf/util/arm64-frame-pointer-unwind-support.h | 2 ++
> tools/perf/util/callchain.h | 2 --
> 6 files changed, 13 insertions(+), 21 deletions(-)
> delete mode 100644 tools/perf/arch/arm64/util/machine.c
>
> diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
> index 4e06a08d281a..638aa6948ab5 100644
> --- a/tools/perf/arch/arm64/util/Build
> +++ b/tools/perf/arch/arm64/util/Build
> @@ -5,7 +5,6 @@ perf-util-y += ../../arm/util/pmu.o
> perf-util-y += arm-spe.o
> perf-util-y += header.o
> perf-util-y += hisi-ptt.o
> -perf-util-y += machine.o
> perf-util-y += mem-events.o
> perf-util-y += pmu.o
> perf-util-y += tsc.o
> diff --git a/tools/perf/arch/arm64/util/machine.c b/tools/perf/arch/arm64/util/machine.c
> deleted file mode 100644
> index 80fb13c958d9..000000000000
> --- a/tools/perf/arch/arm64/util/machine.c
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -
> -#include "callchain.h" // prototype of arch__add_leaf_frame_record_opts
> -#include "perf_regs.h"
> -#include "record.h"
> -
> -#define SMPL_REG_MASK(b) (1ULL << (b))
> -
> -void arch__add_leaf_frame_record_opts(struct record_opts *opts)
> -{
> - opts->sample_user_regs |= SMPL_REG_MASK(PERF_REG_ARM64_LR);
> -}
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 4a5eba498c02..272bba7f4b9e 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -14,6 +14,7 @@
> #include "util/parse-events.h"
> #include "util/config.h"
>
> +#include "util/arm64-frame-pointer-unwind-support.h"
> #include "util/callchain.h"
> #include "util/cgroup.h"
> #include "util/header.h"
> @@ -3230,10 +3231,6 @@ static int record__parse_off_cpu_thresh(const struct option *opt,
> return 0;
> }
>
> -void __weak arch__add_leaf_frame_record_opts(struct record_opts *opts __maybe_unused)
> -{
> -}
> -
> static int parse_control_option(const struct option *opt,
> const char *str,
> int unset __maybe_unused)
> @@ -4319,8 +4316,10 @@ int cmd_record(int argc, const char **argv)
>
> evlist__warn_user_requested_cpus(rec->evlist, rec->opts.target.cpu_list);
>
> - if (callchain_param.enabled && callchain_param.record_mode == CALLCHAIN_FP)
> - arch__add_leaf_frame_record_opts(&rec->opts);
> + if (callchain_param.enabled && callchain_param.record_mode == CALLCHAIN_FP) {
> + if (EM_HOST == EM_AARCH64)
> + add_leaf_frame_caller_opts_aarch64(&rec->opts);
> + }
>
> err = -ENOMEM;
> if (evlist__create_maps(rec->evlist, &rec->opts.target) < 0) {
> diff --git a/tools/perf/util/arm64-frame-pointer-unwind-support.c b/tools/perf/util/arm64-frame-pointer-unwind-support.c
> index 858ce2b01812..3af8c7a466e0 100644
> --- a/tools/perf/util/arm64-frame-pointer-unwind-support.c
> +++ b/tools/perf/util/arm64-frame-pointer-unwind-support.c
> @@ -2,6 +2,7 @@
> #include "arm64-frame-pointer-unwind-support.h"
> #include "callchain.h"
> #include "event.h"
> +#include "record.h"
> #include "unwind.h"
> #include <string.h>
>
> @@ -16,6 +17,11 @@ struct entries {
>
> #define SMPL_REG_MASK(b) (1ULL << (b))
>
> +void add_leaf_frame_caller_opts_aarch64(struct record_opts *opts)
> +{
> + opts->sample_user_regs |= SMPL_REG_MASK(PERF_REG_ARM64_LR);
> +}
> +
> static bool get_leaf_frame_caller_enabled(struct perf_sample *sample)
> {
> struct regs_dump *regs;
> diff --git a/tools/perf/util/arm64-frame-pointer-unwind-support.h b/tools/perf/util/arm64-frame-pointer-unwind-support.h
> index 42d3a45490f5..ba35b295bfcd 100644
> --- a/tools/perf/util/arm64-frame-pointer-unwind-support.h
> +++ b/tools/perf/util/arm64-frame-pointer-unwind-support.h
> @@ -5,8 +5,10 @@
> #include <linux/types.h>
>
> struct perf_sample;
> +struct record_opts;
> struct thread;
>
> +void add_leaf_frame_caller_opts_aarch64(struct record_opts *opts);
> u64 get_leaf_frame_caller_aarch64(struct perf_sample *sample, struct thread *thread, int user_idx);
>
> #endif /* __PERF_ARM_FRAME_POINTER_UNWIND_SUPPORT_H */
> diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
> index 06d463ccc7a0..b7702d65ad60 100644
> --- a/tools/perf/util/callchain.h
> +++ b/tools/perf/util/callchain.h
> @@ -277,8 +277,6 @@ static inline int arch_skip_callchain_idx(struct thread *thread __maybe_unused,
> }
> #endif
>
> -void arch__add_leaf_frame_record_opts(struct record_opts *opts);
> -
> char *callchain_list__sym_name(struct callchain_list *cl,
> char *bf, size_t bfsize, bool show_dso);
> char *callchain_node__scnprintf_value(struct callchain_node *node,
> --
> 2.54.0.563.g4f69b47b94-goog
>
^ permalink raw reply
* [PATCH] Bluetooth: btmtk: Fix FUNC_CTRL parsing for devices with zero-length payloads
From: Shivam Kalra via B4 Relay @ 2026-05-14 17:48 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, Tristan Madani
Cc: Luiz Augusto von Dentz, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, stable, Shivam Kalra
From: Shivam Kalra <shivamkalra98@zohomail.in>
Commit 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length
before struct access") added strict SKB length checks to prevent OOB
memory reads when parsing WMT events.
However, when enabling the protocol (flag = 0), the MT7922 returns a WMT
event with a zero-length payload (skb->len == 7), omitting the 2-byte
status field entirely.
The strict sizeof() check unconditionally enforced the presence of the
status field for all BTMTK_WMT_FUNC_CTRL events. This caused the driver
to reject these payload-less responses with -EINVAL, failing Bluetooth
initialization ("Failed to send wmt func ctrl (-22)").
Fix this by making skb_pull_data() conditional: if the status payload is
present, parse it as before; if omitted, default to BTMTK_WMT_ON_UNDONE.
This restores the pre-regression initialization behavior while
maintaining the memory safety bounds of the previous patch.
Fixes: 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221511
Cc: stable@vger.kernel.org
Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
---
Tested on a laptop with a single MediaTek MT7922 (USB ID 0489:e0e0)
Bluetooth controller. Before this patch, Bluetooth initialization failed
with "Failed to send wmt func ctrl (-22)" on every boot. After applying
this patch, initialization succeeds reliably.
This regression is also reported by other users on the kernel bug
tracker [1].
Note: btmtksdio.c and btmtkuart.c have similar FUNC_CTRL parsing code
but were not modified by the original commit 634a4408c061, so they are
not affected by this regression and do not require changes.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=221511
---
drivers/bluetooth/btmtk.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index f70c1b0f8990..026e5a76b086 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -717,19 +717,19 @@ static int btmtk_usb_hci_wmt_sync(struct hci_dev *hdev,
status = BTMTK_WMT_PATCH_DONE;
break;
case BTMTK_WMT_FUNC_CTRL:
- if (!skb_pull_data(data->evt_skb,
- sizeof(wmt_evt_funcc->status))) {
- err = -EINVAL;
- goto err_free_skb;
- }
-
- wmt_evt_funcc = (struct btmtk_hci_wmt_evt_funcc *)wmt_evt;
- if (be16_to_cpu(wmt_evt_funcc->status) == 0x404)
- status = BTMTK_WMT_ON_DONE;
- else if (be16_to_cpu(wmt_evt_funcc->status) == 0x420)
- status = BTMTK_WMT_ON_PROGRESS;
- else
+ if (skb_pull_data(data->evt_skb,
+ sizeof(wmt_evt_funcc->status))) {
+ wmt_evt_funcc =
+ (struct btmtk_hci_wmt_evt_funcc *)wmt_evt;
+ if (be16_to_cpu(wmt_evt_funcc->status) == 0x404)
+ status = BTMTK_WMT_ON_DONE;
+ else if (be16_to_cpu(wmt_evt_funcc->status) == 0x420)
+ status = BTMTK_WMT_ON_PROGRESS;
+ else
+ status = BTMTK_WMT_ON_UNDONE;
+ } else {
status = BTMTK_WMT_ON_UNDONE;
+ }
break;
case BTMTK_WMT_PATCH_DWNLD:
if (wmt_evt->whdr.flag == 2)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260514-bluetooh-fix-mt7922-92bbbeff229b
Best regards,
--
Shivam Kalra <shivamkalra98@zohomail.in>
^ permalink raw reply related
* Re: [PATCH v7 07/20] KVM: arm64: Set up FGT for Partitioned PMU
From: Colton Lewis @ 2026-05-14 17:49 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <agQpbiD8Fi6fzomf@kernel.org>
Hi Oliver. Thanks for the review.
Oliver Upton <oupton@kernel.org> writes:
> On Mon, May 04, 2026 at 09:18:00PM +0000, Colton Lewis wrote:
>> +static void __compute_hdfgrtr(struct kvm_vcpu *vcpu)
>> +{
>> + __compute_fgt(vcpu, HDFGRTR_EL2);
>> +
>> + *vcpu_fgt(vcpu, HDFGRTR_EL2) |=
>> + HDFGRTR_EL2_PMOVS
>> + | HDFGRTR_EL2_PMCCFILTR_EL0
>> + | HDFGRTR_EL2_PMEVTYPERn_EL0
>> + | HDFGRTR_EL2_PMCEIDn_EL0
>> + | HDFGRTR_EL2_PMMIR_EL1;
>> +}
>> +
> I've given this feedback at least twice already...
> Operators go on the preceding line in the case of line continuations.
I apologize for letting that slip through again.
>> +
>> +/**
>> + * kvm_pmu_is_partitioned() - Determine if given PMU is partitioned
>> + * @pmu: Pointer to arm_pmu struct
>> + *
>> + * Determine if given PMU is partitioned by looking at hpmn field. The
>> + * PMU is partitioned if this field is less than the number of
>> + * counters in the system.
>> + *
>> + * Return: True if the PMU is partitioned, false otherwise
>> + */
>> +bool kvm_pmu_is_partitioned(struct arm_pmu *pmu)
>> +{
>> + if (!pmu)
>> + return false;
>> +
>> + return pmu->max_guest_counters >= 0 &&
>> + pmu->max_guest_counters <= *host_data_ptr(nr_event_counters);
>> +}
>> +
>> +/**
>> + * kvm_vcpu_pmu_is_partitioned() - Determine if given VCPU has a
>> partitioned PMU
>> + * @vcpu: Pointer to kvm_vcpu struct
>> + *
>> + * Determine if given VCPU has a partitioned PMU by extracting that
>> + * field and passing it to :c:func:`kvm_pmu_is_partitioned`
>> + *
>> + * Return: True if the VCPU PMU is partitioned, false otherwise
>> + */
>> +bool kvm_vcpu_pmu_is_partitioned(struct kvm_vcpu *vcpu)
>> +{
>> + return kvm_pmu_is_partitioned(vcpu->kvm->arch.arm_pmu) &&
>> + false;
>> +}
> Ok, I'm thoroughly confused about these predicates.
> Whether or not a vCPU is using a partitioned PMU is a per-VM property.
> This is separate from whether or not the backing arm_pmu has a range of
> available counters for the guest to use.
> It is entirely possible that a VM *isn't* using the partitioned PMU
> feature (i.e. backed with perf events) yet the supporting arm_pmu has a
> guest counter range.
Yes and I add that to this predicate in a later patch when I introduce
the flag. I can always reorder to introduce the flag before (or along
with) this predicate.
>> +#if !defined(__KVM_NVHE_HYPERVISOR__)
>> +bool kvm_vcpu_pmu_is_partitioned(struct kvm_vcpu *vcpu);
>> +bool kvm_vcpu_pmu_use_fgt(struct kvm_vcpu *vcpu);
>> +#else
>> +static inline bool kvm_vcpu_pmu_is_partitioned(struct kvm_vcpu *vcpu)
>> +{
>> + return false;
>> +}
>> +
>> +static inline bool kvm_vcpu_pmu_use_fgt(struct kvm_vcpu *vcpu)
>> +{
>> + return false;
>> +}
>> +#endif
>> +
> Don't use ifdeffery for this. Aim to have a single definition and rely
> on has_vhe() to do the rest of the work.
Will do.
> Thanks,
> Oliver
^ permalink raw reply
* [arm-platforms:timers/el2-vtimer 1/17] Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
From: kernel test robot @ 2026-05-14 18:06 UTC (permalink / raw)
To: Marc Zyngier; +Cc: oe-kbuild-all, linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git timers/el2-vtimer
head: e793e78f4ead18e3dfe5a3a1be912a7ec5bc55d8
commit: c58180850debdd9b2306a86238860769137f40cd [1/17] ACPI: GTDT: Account for GTDTv3 size when walking the platform timer descriptors
config: arm64-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260514/202605141925.PkUUh1mk-lkp@intel.com/config)
compiler: aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260514/202605141925.PkUUh1mk-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605141925.PkUUh1mk-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
>> Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm64: dts: airoha: Add an7583 entry
From: Conor Dooley @ 2026-05-14 18:09 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Felix Fietkau,
John Crispin, Matthias Brugger, AngeloGioacchino Del Regno,
Christian Marangi, devicetree, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260513-airoha-7583-v2-1-ee0d82b37ce7@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v4 09/13] net: lan966x: add PCIe FDMA support
From: Daniel Machon @ 2026-05-14 18:14 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <73a19f89-ccd7-4762-8e07-812d8d95ead2@redhat.com>
> On 5/9/26 10:27 AM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 10 potential issue(s) to consider:
> >> +static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
> >> +{
> > [ ... ]
> >> + /* Get all received skbs. */
> >> + while (counter < weight) {
> >> + if (!fdma_has_frames(fdma))
> >> + break;
> >> + /* Order DONE read before DCB/frame reads below. */
> >> + dma_rmb();
> >> + counter++;
> >> + switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> >> + case FDMA_PASS:
> >> + break;
> >> + case FDMA_ERROR:
> >> + fdma_dcb_advance(fdma);
> >> + goto allocate_new;
> >> + }
> >> + skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
> >> + fdma_dcb_advance(fdma);
> >> + if (!skb)
> >> + goto allocate_new;
> >
> > If napi_alloc_skb() fails due to memory pressure, does branching to
> > allocate_new prematurely break out of the processing loop? Since the hardware
> > interrupt was already cleared, and napi_complete_done() is called below,
> > will this cause the RX queue to stall permanently for the remaining
> > unprocessed frames? Should the code drop the packet and continue instead?
>
> I went over the series and sashiko feedback, and generally speaking the
> series LGTM, but I think this one is real and should be addressed.
Thanks for reviewing. Before I respin, I'd like to sanity-check the design
expectation.
I had already looked at this and concluded it was fine — the reasoning being
that any leftover DCBs (frames) would be drained on the next IRQ when new
traffic arrives. Same pattern exists in all other Microchip FDMA drivers
(lan966x platform, sparx5/lan969x, ocelot) and has been running since their
introduction without a reported issue, AFAIK.
Is calling napi_complete_done() with DCBs still pending in the ring itself a
NAPI-contract violation — in that case this is a pattern that needs fixing
across all four drivers.
Happy to go either way — just want to make sure I understand the problem :-)
>
> Also it would be very helpful if you could (for future series/revision)
> reply to the (wrong) sashiko comments individually explaining with a few
> words why the are off: decoding the context requires much more time for
> whoever has not wrote the code itself.
Ack.
>
> I understand that dealing with AI feedback is a pain, but, paraphrasing
> a great aphorisms creator, I can assure you that ours (maintainers) pain
> is greater.
I can only imagine.
>
> Thanks,
>
> Paolo
>
/Daniel
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: timer: pit: add PIT node example for s32g2/3 platforms
From: Conor Dooley @ 2026-05-14 18:14 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pengutronix Kernel Team, linux-arm-kernel, imx,
devicetree, linux-kernel, NXP S32 Linux, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo
In-Reply-To: <20260514070605.996462-3-khristineandreea.barbulescu@oss.nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
On Thu, May 14, 2026 at 09:06:05AM +0200, Khristine Andreea Barbulescu wrote:
> Add devicetree binding example for the PIT timer as used on
> NXP S32G2 and S32G3 platforms.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
This doesn't add anything to the binding of value, all properties appear
the same as the existing example?
pw-bot: rejected
Cheers,
Conor.
> ---
> .../devicetree/bindings/timer/fsl,vf610-pit.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> index 42e130654d58..8696696776b3 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> +++ b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> @@ -57,3 +57,11 @@ examples:
> clocks = <&clks VF610_CLK_PIT>;
> clock-names = "pit";
> };
> +
> + pit@40188000 {
> + compatible = "nxp,s32g2-pit";
> + reg = <0x40188000 0x3000>;
> + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 61>;
> + clock-names = "pit";
> + };
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: display: rockchip: analogix-dp: Expose inherited properties
From: Conor Dooley @ 2026-05-14 18:16 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260514070133.2275069-2-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
On Thu, May 14, 2026 at 03:01:31PM +0800, Damon Ding wrote:
> Expose the inherited properties from the base analogix-dp schema
> to satisfy unevaluatedProperties constraints.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Given it's unevaluatedProperties, not addtionalProperties, this patch
shouldn't be needed?
> ---
> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index bb75d898a5c5..896ded87880f 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -50,6 +50,13 @@ properties:
> aux-bus:
> $ref: /schemas/display/dp-aux-bus.yaml#
>
> + reg: true
> + interrupts: true
> + phys: true
> + phy-names: true
> + force-hpd: true
> + ports: true
> +
> required:
> - compatible
> - clocks
> --
> 2.34.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 08/20] KVM: arm64: Add Partitioned PMU register trap handlers
From: Colton Lewis @ 2026-05-14 18:18 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <agQsM7XFsbxbFRLO@kernel.org>
Oliver Upton <oupton@kernel.org> writes:
> On Mon, May 04, 2026 at 09:18:01PM +0000, Colton Lewis wrote:
>> We may want a partitioned PMU but not have FEAT_FGT to untrap the
>> specific registers that would normally be untrapped. Add handling for
>> those trapped register accesses that does the right thing if the PMU
>> is partitioned.
>> For registers that shouldn't be written to hardware because they
>> require special handling (PMEVTYPER and PMOVS), write to the virtual
>> register. A later patch will ensure these are handled correctly at
>> vcpu_load time.
>> Signed-off-by: Colton Lewis <coltonlewis@google.com>
> I'd prefer an approach that provides a single accessor helper that takes
> a vcpu_sysreg enum as an argument and internally handles the dispatch
> between partitioned and emulated PMUs. That goes for all of the PMU
> sysregs.
That seems ugly to me. It'll need a giant switch or two to re-dispatch
to the correct sysreg handling when we were already dispatched courtesy
of the function we are in.
Are you thinking:
single_accessor(vcpu_sysreg)
{
if (is_partitioned) {
switch (vcpu_sysreg) {
...
}
return;
}
switch (vcpu_sysreg) {
...
}
}
or I could do the switch on the outside and duplicate the is_partitioned
check but that's the same as what happens now with extra steps.
> This will help you reuse some of the PMU emuation code that you'll still
> need for things like nested...
I'm not seeing what you mean. Could you explain further please?
> Thanks,
> Oliver
^ permalink raw reply
* Re: [PATCH v1 2/3] dt-bindings: display: bridge: analogix-dp: Add data-lanes support for endpoint
From: Conor Dooley @ 2026-05-14 18:19 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260514070133.2275069-3-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
On Thu, May 14, 2026 at 03:01:32PM +0800, Damon Ding wrote:
> Add data-lanes property support to the port@1 endpoint for physical
> lane mapping configuration.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> ---
> .../bindings/display/bridge/analogix,dp.yaml | 24 +++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> index 62f0521b0924..a82f9b7776c0 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> @@ -36,19 +36,35 @@ properties:
> Hotplug detect GPIO.
> Indicates which GPIO should be used for hotplug detection
>
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + deprecated: true
Why are you adding a new property as deprecated? Why does this duplicate
what you're adding to the port node? At the very least, your commit is
lacking an explanation.
pw-bot: changes-requested
Cheers,
Conor.
> + minItems: 1
> + maxItems: 4
> + items:
> + maximum: 3
> +
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> properties:
> port@0:
> $ref: /schemas/graph.yaml#/properties/port
> - description:
> - Input node to receive pixel data.
> + description: Input node to receive pixel data.
>
> port@1:
> $ref: /schemas/graph.yaml#/properties/port
> - description:
> - Port node with one endpoint connected to a dp-connector node.
> + description: Port node with one endpoint connected to sink device node.
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> + items:
> + enum: [ 0, 1, 2, 3 ]
>
> required:
> - port@0
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
From: Conor Dooley @ 2026-05-14 18:19 UTC (permalink / raw)
To: Prasanth Kumar Padarthi
Cc: joel, andrew, robh, krzk+dt, conor+dt, devicetree, linux-aspeed,
linux-arm-kernel
In-Reply-To: <20260514031622.1416922-2-prasanth.padarthi10@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: timer: pit: add PIT node example for s32g2/3 platforms
From: Frank Li @ 2026-05-14 18:38 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Sascha Hauer,
Fabio Estevam, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pengutronix Kernel Team, linux-arm-kernel, imx, devicetree,
linux-kernel, NXP S32 Linux, Christophe Lizzi, Alberto Ruiz,
Enric Balletbo
In-Reply-To: <20260514070605.996462-3-khristineandreea.barbulescu@oss.nxp.com>
On Thu, May 14, 2026 at 09:06:05AM +0200, Khristine Andreea Barbulescu wrote:
> Add devicetree binding example for the PIT timer as used on
> NXP S32G2 and S32G3 platforms.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
> .../devicetree/bindings/timer/fsl,vf610-pit.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> index 42e130654d58..8696696776b3 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> +++ b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> @@ -57,3 +57,11 @@ examples:
> clocks = <&clks VF610_CLK_PIT>;
> clock-names = "pit";
> };
> +
> + pit@40188000 {
> + compatible = "nxp,s32g2-pit";
> + reg = <0x40188000 0x3000>;
> + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 61>;
> + clock-names = "pit";
> + };
Needn't change example
Frank
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 0/5] scmi: Log client subsystem entity counts
From: Sudeep Holla @ 2026-05-14 18:42 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Alex Tran, Sudeep Holla, Jyoti Bhayana, David Lechner,
Nuno Sá, Andy Shevchenko, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck,
linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon
In-Reply-To: <20260514164422.0eba9a61@jic23-huawei>
On Thu, May 14, 2026 at 04:44:22PM +0100, Jonathan Cameron wrote:
> On Wed, 13 May 2026 10:16:53 -0700
> Alex Tran <alex.tran@oss.qualcomm.com> wrote:
>
> > SCMI client drivers do not consistently log the number of supported
> > entities discovered from firmware. This information is useful during
> > debugging because it shows which domains or resources were exposed by
> > firmware during probe.
> >
> > Add logging of the number of supported entities to the SCMI cpufreq,
> > pinctrl, reset, hwmon, and powercap client drivers after a successful
> > probe. This aligns these drivers with the existing logging in the SCMI
> > power and performance domain drivers.
> >
> > Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
> Hi Alex,
>
> Just curious but why +CC linux-iio and IIO folk?
>
> May be you had a false suggestion to add them from get maintainers.
> If so be sure to check it's suggestions make sense!
>
My guess, the intention was to add similar logging in scmi_iio_dev_probe()
as well, may have got dropped {un/}intentionally, but the list remained
in place. The author of the driver is also cc-ed.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v7 09/20] KVM: arm64: Set up MDCR_EL2 to handle a Partitioned PMU
From: Colton Lewis @ 2026-05-14 18:43 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <agQu9kLnbHjSni-C@kernel.org>
Oliver Upton <oupton@kernel.org> writes:
> On Mon, May 04, 2026 at 09:18:02PM +0000, Colton Lewis wrote:
>> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
>> index 3ad6b7c6e4ba7..0ab89c91e19cb 100644
>> --- a/arch/arm64/kvm/debug.c
>> +++ b/arch/arm64/kvm/debug.c
>> @@ -36,20 +36,43 @@ static int cpu_has_spe(u64 dfr0)
>> */
>> static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)
>> {
>> + int hpmn = kvm_pmu_hpmn(vcpu);
>> +
>> preempt_disable();
>> /*
>> * This also clears MDCR_EL2_E2PB_MASK and MDCR_EL2_E2TB_MASK
>> * to disable guest access to the profiling and trace buffers
>> */
>> - vcpu->arch.mdcr_el2 = FIELD_PREP(MDCR_EL2_HPMN,
>> - *host_data_ptr(nr_event_counters));
>> +
>> + vcpu->arch.mdcr_el2 = FIELD_PREP(MDCR_EL2_HPMN, hpmn);
>> vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
>> MDCR_EL2_TPMS |
>> MDCR_EL2_TTRF |
>> MDCR_EL2_TPMCR |
>> MDCR_EL2_TDRA |
>> - MDCR_EL2_TDOSA);
>> + MDCR_EL2_TDOSA |
>> + MDCR_EL2_HPME);
>> +
>> + if (kvm_vcpu_pmu_is_partitioned(vcpu)) {
>> + /*
>> + * Filtering these should be redundant because we trap
>> + * all the TYPER and FILTR registers anyway and ensure
>> + * they filter EL2, but set the bits if they are here.
>> + */
>> + if (is_pmuv3p1(read_pmuver()))
>> + vcpu->arch.mdcr_el2 |= MDCR_EL2_HPMD;
>> + if (is_pmuv3p5(read_pmuver()))
>> + vcpu->arch.mdcr_el2 |= MDCR_EL2_HCCD;
> Neither of these controls are of any consequence on unsupported
> hardware (RES0). Set them unconditionally?
Sure.
>> + /*
>> + * Take out the coarse grain traps if we are using
>> + * fine grain traps.
>> + */
>> + if (kvm_vcpu_pmu_use_fgt(vcpu))
> I think open coding the check here would actually improve readability.
> if (cpus_have_final_cap(ARM64_HAS_FGT) &&
> (cpus_have_final_cap(ARM64_HAS_HPMN0) ||
> vcpu->kvm->arch.nr_pmu_counters != 0))
> vcpu->arch.mdcr_el2 &= ~(MDCR_EL2_TPM | MDCR_EL2_TPMCR);
I disagree but I'll do it.
>> +
>> +/**
>> + * kvm_pmu_hpmn() - Calculate HPMN field value
>> + * @vcpu: Pointer to struct kvm_vcpu
>> + *
>> + * Calculate the appropriate value to set for MDCR_EL2.HPMN. If
>> + * partitioned, this is the number of counters set for the guest if
>> + * supported, falling back to max_guest_counters if needed. If we are
>> not
>> + * partitioned or can't set the implied HPMN value, fall back to the
>> + * host value.
>> + *
>> + * Return: A valid HPMN value
>> + */
>> +u8 kvm_pmu_hpmn(struct kvm_vcpu *vcpu)
>> +{
>> + u8 nr_guest_cntr = vcpu->kvm->arch.nr_pmu_counters;
>> +
>> + if (kvm_vcpu_pmu_is_partitioned(vcpu)
>> + && !vcpu_on_unsupported_cpu(vcpu)
>> + && (cpus_have_final_cap(ARM64_HAS_HPMN0) || nr_guest_cntr > 0))
>> + return nr_guest_cntr;
>> +
>> + return *host_data_ptr(nr_event_counters);
>> +}
> This helper isn't helpful. Just open code it in the place where we are
> computing MDCR_EL2.
I disagree but I'll do it.
>> @@ -542,6 +542,13 @@ u8 kvm_arm_pmu_get_max_counters(struct kvm *kvm)
>> if (cpus_have_final_cap(ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS))
>> return 1;
>> + /*
>> + * If partitioned then we are limited by the max counters in
>> + * the guest partition.
>> + */
>> + if (kvm_pmu_is_partitioned(arm_pmu))
>> + return arm_pmu->max_guest_counters;
>> +
> Ok, this is exactly what I was getting at earlier. What about a VM with
> an emulated PMU? It should use cntr_mask calculation, not the guest
> range.
True. I should use something different here.
> Thanks,
> Oliver
^ permalink raw reply
* Re: [PATCH v2] soc: ti: knav_qmss_queue: Implement resource cleanup in remove()
From: Md Shofiqul Islam @ 2026-05-14 18:58 UTC (permalink / raw)
To: nm; +Cc: ssantosh, linux-arm-kernel, linux-kernel
In-Reply-To: <20260506154114.2288-1-shofiqtest@gmail.com>
Hi Nishanth,
Gentle ping on this patch. You suggested this fix — the patch
implements exactly what was discussed: stopping PDSPs and freeing
queue regions and queue ranges before disabling runtime PM,
mirroring the cleanup already done in the probe error path, and
setting device_ready to false before teardown.
Could you take a look and provide an Acked-by if it looks correct?
The patch has been waiting since November 2025 across several
versions with no reviewer feedback.
Link: https://lore.kernel.org/linux-arm-kernel/20260506154114.2288-1-shofiqtest@gmail.com/
Thanks,
Shofiq
^ permalink raw reply
* Re: [PATCH v7 10/20] KVM: arm64: Context swap Partitioned PMU guest registers
From: Colton Lewis @ 2026-05-14 18:59 UTC (permalink / raw)
To: Oliver Upton
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <agRBzkVcR-qZZdx2@kernel.org>
Oliver Upton <oupton@kernel.org> writes:
> On Mon, May 04, 2026 at 09:18:03PM +0000, Colton Lewis wrote:
>> +
>> +/**
>> + * kvm_pmu_host_counter_mask() - Compute bitmask of host-reserved
>> counters
>> + * @pmu: Pointer to arm_pmu struct
>> + *
>> + * Compute the bitmask that selects the host-reserved counters in the
>> + * {PMCNTEN,PMINTEN,PMOVS}{SET,CLR} registers. These are the counters
>> + * in HPMN..N
>> + *
>> + * Return: Bitmask
>> + */
>> +u64 kvm_pmu_host_counter_mask(struct arm_pmu *pmu)
>> +{
>> + u8 nr_counters = *host_data_ptr(nr_event_counters);
>> +
>> + if (kvm_pmu_is_partitioned(pmu))
>> + return GENMASK(nr_counters - 1, pmu->max_guest_counters);
>> +
>> + return ARMV8_PMU_CNT_MASK_ALL;
>> +}
>> +
>> +/**
>> + * kvm_pmu_guest_counter_mask() - Compute bitmask of guest-reserved
>> counters
>> + * @pmu: Pointer to arm_pmu struct
>> + *
>> + * Compute the bitmask that selects the guest-reserved counters in the
>> + * {PMCNTEN,PMINTEN,PMOVS}{SET,CLR} registers. These are the counters
>> + * in 0..HPMN and the cycle and instruction counters.
>> + *
>> + * Return: Bitmask
>> + */
>> +u64 kvm_pmu_guest_counter_mask(struct arm_pmu *pmu)
>> +{
>> + if (kvm_pmu_is_partitioned(pmu))
>> + return ARMV8_PMU_CNT_MASK_C | GENMASK(pmu->max_guest_counters - 1, 0);
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * kvm_pmu_load() - Load untrapped PMU registers
>> + * @vcpu: Pointer to struct kvm_vcpu
>> + *
>> + * Load all untrapped PMU registers from the VCPU into the PCPU. Mask
>> + * to only bits belonging to guest-reserved counters and leave
>> + * host-reserved counters alone in bitmask registers.
>> + */
>> +void kvm_pmu_load(struct kvm_vcpu *vcpu)
>> +{
>> + struct arm_pmu *pmu;
>> + unsigned long guest_counters;
>> + u64 mask;
>> + u8 i;
>> + u64 val;
>> +
>> + /*
>> + * If we aren't guest-owned then we know the guest isn't using
>> + * the PMU anyway, so no need to bother with the swap.
>> + */
>> + if (!kvm_vcpu_pmu_is_partitioned(vcpu))
>> + return;
>> +
>> + preempt_disable();
>> +
>> + pmu = vcpu->kvm->arch.arm_pmu;
>> + guest_counters = kvm_pmu_guest_counter_mask(pmu);
>> +
>> + for_each_set_bit(i, &guest_counters, ARMPMU_MAX_HWEVENTS) {
>> + val = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i);
>> +
>> + if (i == ARMV8_PMU_CYCLE_IDX) {
>> + write_sysreg(val, pmccntr_el0);
>> + } else {
>> + write_sysreg(i, pmselr_el0);
>> + write_sysreg(val, pmxevcntr_el0);
> This is wrong, you would need an intervening ISB. It'd be better to
> avoid the ISB altogether and just use {read,write}_pmevcntrn().
Good catch, I was using {read,write}_pmevcntrn here before but changed
it after your feedback that:
> I'd prefer KVM directly accessed the PMU registers to
> avoid the possibility of taking some instrumented codepath in the
> future.
https://lore.kernel.org/kvm/aUH7oC41XaEMsXf_@kernel.org/
I assume this is a compromise with that.
^ permalink raw reply
* Re: [PATCH v7 13/20] KVM: arm64: Apply dynamic guest counter reservations
From: Colton Lewis @ 2026-05-14 19:05 UTC (permalink / raw)
To: James Clark
Cc: alexandru.elisei, pbonzini, corbet, linux, catalin.marinas, will,
maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose, yuzenghui,
mark.rutland, shuah, gankulkarni, linux-doc, linux-kernel,
linux-arm-kernel, kvmarm, linux-perf-users, linux-kselftest, kvm
In-Reply-To: <66797cb2-18f7-4782-9370-68d0c10c35f4@linaro.org>
James Clark <james.clark@linaro.org> writes:
> On 13/05/2026 5:45 pm, Colton Lewis wrote:
>> James Clark <james.clark@linaro.org> writes:
>>> On 04/05/2026 10:18 pm, Colton Lewis wrote:
>>>> Apply dynamic guest counter reservations by checking if the requested
>>>> guest mask collides with any events the host has scheduled and calling
>>>> pmu_perf_resched_update() with a hook that updates the mask of
>>>> available counters in between schedule out and schedule in.
>>>> Signed-off-by: Colton Lewis <coltonlewis@google.com>
>>>> ---
>>>> arch/arm64/kvm/pmu-direct.c | 69 ++++++++++++++++++++++++++++++++
>>>> ++++
>>>> include/linux/perf/arm_pmu.h | 1 +
>>>> 2 files changed, 70 insertions(+)
>>>> diff --git a/arch/arm64/kvm/pmu-direct.c b/arch/arm64/kvm/pmu-direct.c
>>>> index 2252d3b905db9..14cc419dbafad 100644
>>>> --- a/arch/arm64/kvm/pmu-direct.c
>>>> +++ b/arch/arm64/kvm/pmu-direct.c
>>>> @@ -100,6 +100,73 @@ u8 kvm_pmu_hpmn(struct kvm_vcpu *vcpu)
>>>> return *host_data_ptr(nr_event_counters);
>>>> }
>>>> +/* Callback to update counter mask between perf scheduling */
>>>> +static void kvm_pmu_update_mask(struct pmu *pmu, void *data)
>>>> +{
>>>> + struct arm_pmu *arm_pmu = to_arm_pmu(pmu);
>>>> + unsigned long *new_mask = data;
>>>> +
>>>> + bitmap_copy(arm_pmu->cntr_mask, new_mask, ARMPMU_MAX_HWEVENTS);
>>>> +}
>>>> +
>>>> +/**
>>>> + * kvm_pmu_set_guest_counters() - Handle dynamic counter reservations
>>>> + * @cpu_pmu: struct arm_pmu to potentially modify
>>>> + * @guest_mask: new guest mask for the pmu
>>>> + *
>>>> + * Check if guest counters will interfere with current host events and
>>>> + * call into perf_pmu_resched_update if a reschedule is required.
>>>> + */
>>>> +static void kvm_pmu_set_guest_counters(struct arm_pmu *cpu_pmu, u64
>>>> guest_mask)
>>>> +{
>>>> + struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
>>>> + DECLARE_BITMAP(guest_bitmap, ARMPMU_MAX_HWEVENTS);
>>>> + DECLARE_BITMAP(new_mask, ARMPMU_MAX_HWEVENTS);
>>>> + bool need_resched = false;
>>>> +
>>>> + bitmap_from_arr64(guest_bitmap, &guest_mask, ARMPMU_MAX_HWEVENTS);
>>>> + bitmap_copy(new_mask, cpu_pmu->hw_cntr_mask, ARMPMU_MAX_HWEVENTS);
>>>> +
>>>> + if (guest_mask) {
>>>> + /* Subtract guest counters from available host mask */
>>>> + bitmap_andnot(new_mask, new_mask, guest_bitmap,
>>>> ARMPMU_MAX_HWEVENTS);
>>>> +
>>>> + /* Did we collide with an active host event? */
>>>> + if (bitmap_intersects(cpuc->used_mask, guest_bitmap,
>>>> ARMPMU_MAX_HWEVENTS)) {
>>>> + int idx;
>>>> +
>>>> + need_resched = true;
>>>> + cpuc->host_squeezed = true;
>>>> +
>>>> + /* Look for pinned events that are about to be preempted
>>>> */
>>>> + for_each_set_bit(idx, guest_bitmap, ARMPMU_MAX_HWEVENTS) {
>>>> + if (test_bit(idx, cpuc->used_mask) && cpuc-
>>>> >events[idx] &&
>>>> + cpuc->events[idx]->attr.pinned) {
>>>> + pr_warn_ratelimited("perf: Pinned host event
>>>> squeezed out by KVM guest PMU partition\n");
>>> Hi Colton,
>>> I get "perf: Pinned host event squeezed out by KVM guest PMU partition"
>>> even with arm_pmuv3.reserved_host_counters=3 for example. I would have
>>> expected any non zero value to stop the warning.
>>> I think armv8pmu_get_single_idx() needs to be changed to allocate from
>>> the high end host counters first. A more complicated option would be
>>> checking to see if there are any non-pinned counters in the host
>>> reserved half when a new pinned counter is opened, then swapping the
>>> places of the new pinned and existing non-pinned counters so pinned
>>> always prefer being put into the host half. But it's probably not worth
>>> doing that.
>>> James
>> I agree it makes the most sense to allocate from the top, but I'm happy
>> the basic idea works.
> Another thing I forgot to mention is that even with the ratelimited
> warning, this spams the logs any time the host and guest are both using
> the PMU and I'm not sure how useful that is.
I'm sure it does. I'll delete it.
>>>> + break;
>>>> + }
>>>> + }
>>>> + }
>>>> + } else {
>>>> + /*
>>>> + * Restoring to hw_cntr_mask.
>>>> + * Only resched if we previously squeezed an event.
>>>> + */
>>>> + if (cpuc->host_squeezed) {
>>>> + need_resched = true;
>>>> + cpuc->host_squeezed = false;
>>>> + }
>>>> + }
>>>> +
>>>> + if (need_resched) {
>>>> + /* Collision: run full perf reschedule */
>>>> + perf_pmu_resched_update(&cpu_pmu->pmu, kvm_pmu_update_mask,
>>>> new_mask);
>>>> + } else {
>>>> + /* Host was never using guest counters anyway */
>>>> + bitmap_copy(cpu_pmu->cntr_mask, new_mask,
>>>> ARMPMU_MAX_HWEVENTS);
>>>> + }
>>>> +}
>>>> +
>>>> /**
>>>> * kvm_pmu_host_counter_mask() - Compute bitmask of host-reserved
>>>> counters
>>>> * @pmu: Pointer to arm_pmu struct
>>>> @@ -218,6 +285,7 @@ void kvm_pmu_load(struct kvm_vcpu *vcpu)
>>>> pmu = vcpu->kvm->arch.arm_pmu;
>>>> guest_counters = kvm_pmu_guest_counter_mask(pmu);
>>>> + kvm_pmu_set_guest_counters(pmu, guest_counters);
>>>> kvm_pmu_apply_event_filter(vcpu);
>>>> for_each_set_bit(i, &guest_counters, ARMPMU_MAX_HWEVENTS) {
>>>> @@ -319,5 +387,6 @@ void kvm_pmu_put(struct kvm_vcpu *vcpu)
>>>> val = read_sysreg(pmintenset_el1);
>>>> __vcpu_assign_sys_reg(vcpu, PMINTENSET_EL1, val & mask);
>>>> + kvm_pmu_set_guest_counters(pmu, 0);
>>>> preempt_enable();
>>>> }
>>>> diff --git a/include/linux/perf/arm_pmu.h
>>>> b/include/linux/perf/arm_pmu.h
>>>> index f7b000bb3eca8..63f88fec5e80f 100644
>>>> --- a/include/linux/perf/arm_pmu.h
>>>> +++ b/include/linux/perf/arm_pmu.h
>>>> @@ -75,6 +75,7 @@ struct pmu_hw_events {
>>>> /* Active events requesting branch records */
>>>> unsigned int branch_users;
>>>> + bool host_squeezed;
>>>> };
>>>> enum armpmu_attr_groups {
^ permalink raw reply
* [PATCH] media: rp1-cfe: Use IS_ERR() check for media_entity_remote_source_pad_unique()
From: Ingyu Jang @ 2026-05-14 19:31 UTC (permalink / raw)
To: Tomi Valkeinen, Raspberry Pi Kernel Maintenance,
Mauro Carvalho Chehab, Florian Fainelli
Cc: Broadcom internal kernel review list, linux-media,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
media_entity_remote_source_pad_unique() returns either a valid struct
media_pad pointer or an error pointer (ERR_PTR(-ENOTUNIQ) or
ERR_PTR(-ENOLINK)); it never returns NULL. The current NULL check
therefore never triggers, and the "pad not connected" error path is
unreachable.
Replace the NULL check with an IS_ERR() check so the validation
actually detects malformed media graphs.
Signed-off-by: Ingyu Jang <ingyujang25@korea.ac.kr>
---
drivers/media/platform/raspberrypi/rp1-cfe/cfe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c b/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
index 8375ed3e97b9f..91e9fa0341e06 100644
--- a/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
+++ b/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
@@ -1779,7 +1779,7 @@ static int cfe_video_link_validate(struct media_link *link)
link->source->entity->name, link->source->index,
link->sink->entity->name, link->sink->index);
- if (!media_entity_remote_source_pad_unique(link->sink->entity)) {
+ if (IS_ERR(media_entity_remote_source_pad_unique(link->sink->entity))) {
cfe_err(cfe, "video node %s pad not connected\n", vd->name);
return -ENOTCONN;
}
--
2.34.1
^ permalink raw reply related
* [PATCH] wifi: mt76: Use IS_ERR() check for mt76_register_debugfs_fops()
From: Ingyu Jang @ 2026-05-14 19:32 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee
Cc: Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, linux-wireless, linux-arm-kernel,
linux-mediatek, linux-kernel
mt76_register_debugfs_fops() returns the dentry from
debugfs_create_dir(), which yields an error pointer on failure and
never NULL. The NULL checks in the per-chip *_init_debugfs() helpers
are therefore unreachable, and on a real failure the ERR_PTR would
be returned to callers as a valid pointer.
Use IS_ERR() and propagate the actual error via PTR_ERR() in
mt7615/mt7915/mt7921/mt7925/mt7996.
Signed-off-by: Ingyu Jang <ingyujang25@korea.ac.kr>
---
drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c | 4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
index 0f7b20152279c..5c3646a67e4b7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
@@ -550,8 +550,8 @@ int mt7615_init_debugfs(struct mt7615_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
if (is_mt7615(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues", dir,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
index 26ed3745af43e..f62a17c8958ac 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
@@ -1296,8 +1296,8 @@ int mt7915_init_debugfs(struct mt7915_phy *phy)
struct dentry *dir;
dir = mt76_register_debugfs_fops(phy->mt76, NULL);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
debugfs_create_file("muru_debug", 0600, dir, dev, &fops_muru_debug);
debugfs_create_file("muru_stats", 0400, dir, phy,
&mt7915_muru_stats_fops);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
index 4333005b3ad95..4da339867b6a7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
@@ -266,8 +266,8 @@ int mt7921_init_debugfs(struct mt792x_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
if (mt76_is_mmio(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues",
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
index e2498659c884e..01aa4a1071fdd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
@@ -291,8 +291,8 @@ int mt7925_init_debugfs(struct mt792x_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
if (mt76_is_mmio(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues",
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
index 34af800964d11..63cd490977106 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
@@ -875,8 +875,8 @@ int mt7996_init_debugfs(struct mt7996_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, NULL);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
debugfs_create_file("hw-queues", 0400, dir, dev,
&mt7996_hw_queues_fops);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 00/12] crypto: atmel - refactor common i2c support and add SHA256 ahash support
From: Thorsten Blum @ 2026-05-14 19:51 UTC (permalink / raw)
To: Lothar Rubusch
Cc: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512224349.64621-1-l.rubusch@gmail.com>
Hi Lothar,
On Tue, May 12, 2026 at 10:43:37PM +0000, Lothar Rubusch wrote:
> This series restructures the Atmel secure element drivers around a
> shared atmel-i2c core and adds SHA256 ahash support for ATSHA204A and
> ECC based devices.
>
> The existing drivers duplicated substantial parts of the transport,
> RNG, EEPROM and device management logic. This series consolidates the
> common functionality into the shared i2c core and converts the client
> drivers to capability based allocation.
>
> The series also introduces per-device timing configuration through
> match data, moves sanity checks and RNG handling into the core driver,
> updates workqueue handling and cleans up internal constants and helper
> definitions.
>
> The final patch adds SHA256 ahash support using the hardware SHA engine
> provided by the devices.
>
> ATSHA204A devices require software-side SHA256 padding according to
> FIPS 180-4, while newer ECC devices provide a dedicated SHA final
> command and perform padding internally in hardware.
>
> Supporting the SHA engine also requires changes to the command
> transport path. SHA operations must execute as a strict uninterrupted
> sequence consisting of SHA INIT, one or more SHA COMPUTE commands and,
> for ECC devices, a terminating SHA FINAL command. The device loses its
> internal SHA state if it enters sleep mode or if unrelated commands
> are interleaved during the transaction.
>
> To satisfy these hardware requirements, the send/receive path is split
> into a low-level transfer helper and a higher-level wrapper managing
> wakeup, sleep and locking. SHA operations keep the device awake and
> hold the i2c lock for the full duration of the hashing transaction.
>
> The series has been tested on ATSHA204A and ATECC508A devices.
> Tests are ongoing/pending on ATECC608A and ATECC608B.
> ---
> Lothar Rubusch (12):
> crypto: atmel - introduce shared I2C client management
> crypto: atmel - move capability-based client allocation into i2c core
> crypto: atmel - remove obsolete CONFIG_OF guard
> crypto: atmel - add per-device timing and match-data driven
> configuration
> crypto: atmel - move RNG support into common i2c core
> crypto: atmel - move EEPROM access support into common i2c core
> crypto: atmel - expose CONFIG zone through sysfs
> crypto: atmel - move device sanity check to core driver
> crypto: atmel - check client data in remove callbacks
> crypto: atmel - update workqueue flags and add flush on exit
> crypto: atmel - refactor and localize driver constants
> crypto: atmel - add SHA256 ahash support
>
> drivers/crypto/atmel-ecc.c | 252 +++++++-----
> drivers/crypto/atmel-i2c.c | 679 +++++++++++++++++++++++++++++----
> drivers/crypto/atmel-i2c.h | 180 +++++----
> drivers/crypto/atmel-sha204a.c | 284 +++++++-------
> 4 files changed, 1010 insertions(+), 385 deletions(-)
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Thanks, but I'm not sure reviewing such a large series is sustainable.
I've only skimmed it, but it also mixes several different things that
should probably be submitted separately (e.g., refactorings and new
features).
Sashiko [1] also reviewed the series and found potential regressions
that might be helpful to consider.
Thanks,
Thorsten
[1] https://sashiko.dev/#/patchset/20260512224349.64621-1-l.rubusch%40gmail.com
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Goffredo Baroncelli @ 2026-05-14 19:51 UTC (permalink / raw)
To: Christoph Hellwig, David Sterba
Cc: Andrew Morton, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Herbert Xu, Dan Williams,
Chris Mason, David Sterba, Arnd Bergmann, Song Liu, Yu Kuai,
Li Nan, linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260513054742.GA1018@lst.de>
On 13/05/2026 07.47, Christoph Hellwig wrote:
> On Tue, May 12, 2026 at 01:42:31PM +0200, David Sterba wrote:
>
>> The degenerate modes of
>> raid0, 5, or 6 are explicit as a possible middle step when converting
>> profiles. We can use a fallback implementation for this case if the
>> accelerated implementations cannot do it.
>
> This is not about a degenerated mode. For a degenerated RAID 6, parity
> generation uses the RAID 5 XOR routines as the second parity will be
> missing. This is about generating two parities for a single data disk,
> which must be explicitly selected.
>
I think that the David concern is : "what happens for an already
existing btrfs raid6 3 disks filesystem when the user upgrade the kernel ?"
(I am thinking when a new BG needs to be allocated)...
BR
GB
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: H. Peter Anvin @ 2026-05-14 19:57 UTC (permalink / raw)
To: kreijack, Goffredo Baroncelli, Christoph Hellwig, David Sterba
Cc: Andrew Morton, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <0a8d1ff4-f5a2-49e9-aa45-d25dbe4ded40@libero.it>
On May 14, 2026 12:51:59 PM PDT, Goffredo Baroncelli <kreijack@libero.it> wrote:
>On 13/05/2026 07.47, Christoph Hellwig wrote:
>> On Tue, May 12, 2026 at 01:42:31PM +0200, David Sterba wrote:
>
>>
>>> The degenerate modes of
>>> raid0, 5, or 6 are explicit as a possible middle step when converting
>>> profiles. We can use a fallback implementation for this case if the
>>> accelerated implementations cannot do it.
>>
>> This is not about a degenerated mode. For a degenerated RAID 6, parity
>> generation uses the RAID 5 XOR routines as the second parity will be
>> missing. This is about generating two parities for a single data disk,
>> which must be explicitly selected.
>>
>
>I think that the David concern is : "what happens for an already
>existing btrfs raid6 3 disks filesystem when the user upgrade the kernel ?"
>(I am thinking when a new BG needs to be allocated)...
>
>BR
>GB
>
That's what I'm saying – it should invoke the RAID-1 code under the cover (as with 3 disks, D = P = Q.)
^ 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