* RE: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Joakim Zhang @ 2026-06-18 1:43 UTC (permalink / raw)
To: Conor Dooley
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
p.zabel@pengutronix.de, Gary Yang, cix-kernel-upstream,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260617-clinic-blank-61289f8fc1c2@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:56 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> clock controller
>
> On Wed, Jun 17, 2026 at 02:04:35PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The AUDSS CRU contains an internal clock tree of muxes, dividers and
> > gates for DSP, I2S, HDA, DMAC and related blocks. The clock provider
> > is a child node of the cix,sky1-audss-system-control syscon and
> > accesses registers through the parent MMIO region.
>
> Why can this not just be part of the parent syscon node?
The clock and reset blocks are handled by different subsystems and maintainers (clk vs reset). Putting the clock provider on the parent syscon node would mean a single driver has to register both the reset controller and the clock provider on one device, which doesn't fit well.
Thanks,
Joakim
^ permalink raw reply
* RE: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Joakim Zhang @ 2026-06-18 1:38 UTC (permalink / raw)
To: Conor Dooley, krzk+dt@kernel.org
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Gary Yang, cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260617-chummy-automatic-6c11e9958bbf@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:54 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss
> system control
>
> On Wed, Jun 17, 2026 at 02:04:33PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The Cix Sky1 Audio Subsystem (AUDSS) groups audio-related clock, reset
> > and control registers in a dedicated CRU block. Software reset lines
> > are exposed on the syscon parent via #reset-cells, following the same
> > model as the existing Sky1 FCH and S5 system control bindings.
> >
> > A clock-controller child node is required under the audss syscon. It
> > has no reg property of its own and accesses the parent register block
> > for mux, divider and gate fields.
> >
> > The AUDSS is also controlled by one power domain and reset part.
> >
> > Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> > ---
> > .../soc/cix/cix,sky1-system-control.yaml | 48 +++++++++++++++++++
> > .../reset/cix,sky1-audss-system-control.h | 25 ++++++++++
> > 2 files changed, 73 insertions(+)
> > create mode 100644
> > include/dt-bindings/reset/cix,sky1-audss-system-control.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml index a01a515222c6..5a1cd5c24ade 100644
> > ---
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > +++ b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-contro
> > +++ l.yaml
> > @@ -19,6 +19,7 @@ properties:
> > - enum:
> > - cix,sky1-system-control
> > - cix,sky1-s5-system-control
> > + - cix,sky1-audss-system-control
> > - const: syscon
>
> If the only thing these share are being a reset controller and having a syscon
> fallback, I think it should be in a different file.
>
Thanks for the review. I'll split the AUDSS bindings into a separate YAML file.
One follow-up: should the AUDSS CRU driver be split out as well? I'm inclined to do that, so each binding maps to its own driver, but wanted to check whether you'd prefer a separate audss reset driver or keeping everything in reset-sky1 before I rework the series.
Hello @krzk+dt@kernel.org, what's your opinion?
Thanks,
Joakim
^ permalink raw reply
* [linusw-nomadik:ux500-power-domains-v7.1 6/11] include/linux/mfd/dbx500-prcmu.h:408:19: error: redefinition of 'prcmu_abb_read'
From: kernel test robot @ 2026-06-18 1:30 UTC (permalink / raw)
To: Linus Walleij; +Cc: oe-kbuild-all, linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-power-domains-v7.1
head: b2481ed07ce2ef552c0104079bdcde6d532ec16b
commit: a5269e25e37c9ec0e13756f8fc3d109eaa291721 [6/11] pmdomain: st: ux500: Control DB8500 EPODs
config: sh-allyesconfig (https://download.01.org/0day-ci/archive/20260618/202606180825.vUSQntkJ-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260618/202606180825.vUSQntkJ-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/202606180825.vUSQntkJ-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/pmdomain/st/ste-ux500-pm-domain.c:13:
>> include/linux/mfd/dbx500-prcmu.h:408:19: error: redefinition of 'prcmu_abb_read'
408 | static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
| ^~~~~~~~~~~~~~
In file included from include/linux/mfd/dbx500-prcmu.h:212:
include/linux/mfd/db8500-prcmu.h:638:19: note: previous definition of 'prcmu_abb_read' with type 'int(u8, u8, u8 *, u8)' {aka 'int(unsigned char, unsigned char, unsigned char *, unsigned char)'}
638 | static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
| ^~~~~~~~~~~~~~
>> include/linux/mfd/dbx500-prcmu.h:413:19: error: redefinition of 'prcmu_abb_write'
413 | static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
| ^~~~~~~~~~~~~~~
include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of 'prcmu_abb_write' with type 'int(u8, u8, u8 *, u8)' {aka 'int(unsigned char, unsigned char, unsigned char *, unsigned char)'}
643 | static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
| ^~~~~~~~~~~~~~~
>> include/linux/mfd/dbx500-prcmu.h:424:19: error: redefinition of 'prcmu_config_clkout'
424 | static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
| ^~~~~~~~~~~~~~~~~~~
include/linux/mfd/db8500-prcmu.h:608:19: note: previous definition of 'prcmu_config_clkout' with type 'int(u8, u8, u8)' {aka 'int(unsigned char, unsigned char, unsigned char)'}
608 | static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
| ^~~~~~~~~~~~~~~~~~~
>> include/linux/mfd/dbx500-prcmu.h:486:19: error: redefinition of 'prcmu_ac_wake_req'
486 | static inline int prcmu_ac_wake_req(void)
| ^~~~~~~~~~~~~~~~~
include/linux/mfd/db8500-prcmu.h:648:19: note: previous definition of 'prcmu_ac_wake_req' with type 'int(void)'
648 | static inline int prcmu_ac_wake_req(void)
| ^~~~~~~~~~~~~~~~~
>> include/linux/mfd/dbx500-prcmu.h:491:20: error: redefinition of 'prcmu_ac_sleep_req'
491 | static inline void prcmu_ac_sleep_req(void) {}
| ^~~~~~~~~~~~~~~~~~
include/linux/mfd/db8500-prcmu.h:653:20: note: previous definition of 'prcmu_ac_sleep_req' with type 'void(void)'
653 | static inline void prcmu_ac_sleep_req(void) {}
| ^~~~~~~~~~~~~~~~~~
vim +/prcmu_abb_read +408 include/linux/mfd/dbx500-prcmu.h
fea799e3d3ab84a Mattias Nilsson 2011-08-12 407
fea799e3d3ab84a Mattias Nilsson 2011-08-12 @408 static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 409 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 410 return -ENOSYS;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 411 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 412
fea799e3d3ab84a Mattias Nilsson 2011-08-12 @413 static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 414 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 415 return -ENOSYS;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 416 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 417
3c3e489831b601e Mattias Nilsson 2012-03-08 418 static inline int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value, u8 *mask,
3c3e489831b601e Mattias Nilsson 2012-03-08 419 u8 size)
3c3e489831b601e Mattias Nilsson 2012-03-08 420 {
3c3e489831b601e Mattias Nilsson 2012-03-08 421 return -ENOSYS;
3c3e489831b601e Mattias Nilsson 2012-03-08 422 }
3c3e489831b601e Mattias Nilsson 2012-03-08 423
fea799e3d3ab84a Mattias Nilsson 2011-08-12 @424 static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 425 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 426 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 427 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 428
fea799e3d3ab84a Mattias Nilsson 2011-08-12 429 static inline int prcmu_request_clock(u8 clock, bool enable)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 430 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 431 return 0;
6b6fae2b890826c Mattias Nilsson 2012-01-13 432 }
6b6fae2b890826c Mattias Nilsson 2012-01-13 433
6b6fae2b890826c Mattias Nilsson 2012-01-13 434 static inline long prcmu_round_clock_rate(u8 clock, unsigned long rate)
6b6fae2b890826c Mattias Nilsson 2012-01-13 435 {
6b6fae2b890826c Mattias Nilsson 2012-01-13 436 return 0;
6b6fae2b890826c Mattias Nilsson 2012-01-13 437 }
6b6fae2b890826c Mattias Nilsson 2012-01-13 438
6b6fae2b890826c Mattias Nilsson 2012-01-13 439 static inline int prcmu_set_clock_rate(u8 clock, unsigned long rate)
6b6fae2b890826c Mattias Nilsson 2012-01-13 440 {
6b6fae2b890826c Mattias Nilsson 2012-01-13 441 return 0;
6b6fae2b890826c Mattias Nilsson 2012-01-13 442 }
6b6fae2b890826c Mattias Nilsson 2012-01-13 443
6b6fae2b890826c Mattias Nilsson 2012-01-13 444 static inline unsigned long prcmu_clock_rate(u8 clock)
6b6fae2b890826c Mattias Nilsson 2012-01-13 445 {
6b6fae2b890826c Mattias Nilsson 2012-01-13 446 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 447 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 448
fea799e3d3ab84a Mattias Nilsson 2011-08-12 449 static inline int prcmu_set_ape_opp(u8 opp)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 450 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 451 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 452 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 453
fea799e3d3ab84a Mattias Nilsson 2011-08-12 454 static inline int prcmu_get_ape_opp(void)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 455 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 456 return APE_100_OPP;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 457 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 458
686f871b7109e7e Ulf Hansson 2012-09-24 459 static inline int prcmu_request_ape_opp_100_voltage(bool enable)
686f871b7109e7e Ulf Hansson 2012-09-24 460 {
686f871b7109e7e Ulf Hansson 2012-09-24 461 return 0;
686f871b7109e7e Ulf Hansson 2012-09-24 462 }
686f871b7109e7e Ulf Hansson 2012-09-24 463
fea799e3d3ab84a Mattias Nilsson 2011-08-12 464 static inline int prcmu_set_arm_opp(u8 opp)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 465 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 466 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 467 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 468
fea799e3d3ab84a Mattias Nilsson 2011-08-12 469 static inline int prcmu_get_arm_opp(void)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 470 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 471 return ARM_100_OPP;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 472 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 473
fea799e3d3ab84a Mattias Nilsson 2011-08-12 474 static inline int prcmu_get_ddr_opp(void)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 475 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 476 return DDR_100_OPP;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 477 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 478
fea799e3d3ab84a Mattias Nilsson 2011-08-12 479 static inline void prcmu_system_reset(u16 reset_code) {}
fea799e3d3ab84a Mattias Nilsson 2011-08-12 480
fea799e3d3ab84a Mattias Nilsson 2011-08-12 481 static inline u16 prcmu_get_reset_code(void)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 482 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 483 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 484 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 485
5261e101198e7ef Arun Murthy 2012-05-21 @486 static inline int prcmu_ac_wake_req(void)
5261e101198e7ef Arun Murthy 2012-05-21 487 {
5261e101198e7ef Arun Murthy 2012-05-21 488 return 0;
5261e101198e7ef Arun Murthy 2012-05-21 489 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 490
fea799e3d3ab84a Mattias Nilsson 2011-08-12 @491 static inline void prcmu_ac_sleep_req(void) {}
fea799e3d3ab84a Mattias Nilsson 2011-08-12 492
:::::: The code at line 408 was first introduced by commit
:::::: fea799e3d3ab84ac675de7e48a13a79fb76b6e63 mfd: Create a common interface for dbx500 PRCMU drivers
:::::: TO: Mattias Nilsson <mattias.i.nilsson@stericsson.com>
:::::: CC: Samuel Ortiz <sameo@linux.intel.com>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2 4/4] irqchip/gic-v3-its: some minor improvement in comments
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260618011459.58347-1-shikemeng@huaweicloud.com>
1. "If it some" -> "If some"
2. "by table by reading" -> by reading"
3. "reading bit at offset '62'" -> "reading GITS_BASER_INDIRECT"
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 449e2cfd0c99..5bc8bba733dd 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -163,7 +163,7 @@ struct event_lpi_map {
/*
* The ITS view of a device - belongs to an ITS, owns an interrupt
- * translation table, and a list of interrupts. If it some of its
+ * translation table, and a list of interrupts. If some of its
* LPIs are injected into a guest (GICv4), the event_map.vm field
* indicates which one.
*/
@@ -2504,7 +2504,7 @@ static bool its_parse_indirect_baser(struct its_node *its,
if ((esz << ids) > (psz * 2)) {
/*
* Find out whether hw supports a single or two-level table by
- * table by reading bit at offset '62' after writing '1' to it.
+ * reading GITS_BASER_INDIRECT after writing '1' to it.
*/
its_write_baser(its, baser, val | GITS_BASER_INDIRECT);
indirect = !!(baser->val & GITS_BASER_INDIRECT);
--
2.33.0
^ permalink raw reply related
* [PATCH v2 1/4] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260618011459.58347-1-shikemeng@huaweicloud.com>
Fix collection leak when its_init_domain() failed in its_probe_one().
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 291d7668cc8d..d721b6101e0a 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5326,7 +5326,7 @@ static int __init its_probe_one(struct its_node *its)
err = its_init_domain(its);
if (err)
- goto out_free_tables;
+ goto out_free_col;
raw_spin_lock(&its_lock);
list_add(&its->entry, &its_nodes);
@@ -5334,6 +5334,8 @@ static int __init its_probe_one(struct its_node *its)
return 0;
+out_free_col:
+ kfree(its->collections);
out_free_tables:
its_free_tables(its);
out_free_cmd:
--
2.33.0
^ permalink raw reply related
* [PATCH v2 3/4] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260618011459.58347-1-shikemeng@huaweicloud.com>
We have a lot of logs containing ITS address info which is helpful to
distiguish which ITS occurs error. Just add ITS address info into more
exsiting error logs.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 3e4edcb64065..449e2cfd0c99 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1120,7 +1120,7 @@ static struct its_cmd_block *its_allocate_entry(struct its_node *its)
while (its_queue_full(its)) {
count--;
if (!count) {
- pr_err_ratelimited("ITS queue not draining\n");
+ pr_err_ratelimited("ITS@%pa queue not draining\n", &its->phys_base);
return NULL;
}
cpu_relax();
@@ -1196,8 +1196,8 @@ static int its_wait_for_range_completion(struct its_node *its,
count--;
if (!count) {
- pr_err_ratelimited("ITS queue timeout (%llu %llu)\n",
- to_idx, linear_idx);
+ pr_err_ratelimited("ITS@%pa queue timeout (%llu %llu)\n",
+ &its->phys_base, to_idx, linear_idx);
return -1;
}
prev_idx = rd_idx;
@@ -1244,7 +1244,7 @@ post: \
raw_spin_unlock_irqrestore(&its->lock, flags); \
\
if (its_wait_for_range_completion(its, rd_idx, next_cmd)) \
- pr_err_ratelimited("ITS cmd %ps failed\n", builder); \
+ pr_err_ratelimited("ITS@%pa cmd %ps failed\n", &its->phys_base, &builder); \
}
static void its_build_sync_cmd(struct its_node *its,
@@ -2411,7 +2411,8 @@ static int its_setup_baser(struct its_node *its, struct its_baser *baser,
/* 52bit PA is supported only when PageSize=64K */
if (psz != SZ_64K) {
- pr_err("ITS: no 52bit PA support when psz=%d\n", psz);
+ pr_err("ITS@%pa: no 52bit PA support when psz=%d\n",
+ &its->phys_base, psz);
its_free_pages(base, order);
return -ENXIO;
}
@@ -5181,7 +5182,7 @@ static int its_init_vpe_domain(void)
vpe_proxy.dev = its_create_device(its, devid, entries, false);
if (!vpe_proxy.dev) {
kfree(vpe_proxy.vpes);
- pr_err("ITS: Can't allocate GICv4 proxy device\n");
+ pr_err("ITS@%pa: Can't allocate GICv4 proxy device\n", &its->phys_base);
return -ENOMEM;
}
--
2.33.0
^ permalink raw reply related
* [PATCH v2 2/4] irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260618011459.58347-1-shikemeng@huaweicloud.com>
Fix its node leak when its_probe_one() failed in
gic_acpi_parse_madt_its().
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index d721b6101e0a..3e4edcb64065 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5747,9 +5747,13 @@ static int __init gic_acpi_parse_madt_its(union acpi_subtable_headers *header,
its->flags |= ITS_FLAGS_FORCE_NON_SHAREABLE;
err = its_probe_one(its);
- if (!err)
- return 0;
+ if (err)
+ goto probe_err;
+
+ return 0;
+probe_err:
+ its_node_destroy(its);
node_err:
iort_deregister_domain_token(its_entry->translation_id);
dom_err:
--
2.33.0
^ permalink raw reply related
* [PATCH v2 0/4] Some Minor cleanups and fixes
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng, w30042819
From: w30042819 <wanghaitao78@h-partners.com>
There are some random fixes and cleanups to irqchip/gic-v3-its. More
details can be found in respective patches.
Thanks.
v1->v2:
- Drop unneeded patches and some minor improvement.
Kemeng Shi (4):
irqchip/gic-v3-its: Fix memleak in its_probe_one()
irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()
irqchip/gic-v3-its: Add ITS address info in more error logs
irqchip/gic-v3-its: some minor improvement in comments
drivers/irqchip/irq-gic-v3-its.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
--
2.33.0
^ permalink raw reply
* Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc()
From: Kemeng Shi @ 2026-06-18 1:00 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <86y0gds700.wl-maz@kernel.org>
在 2026/6/17 20:09:51, Marc Zyngier 写道:
> On Tue, 16 Jun 2026 02:31:22 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> 在 2026/6/15 16:52:56, Marc Zyngier 写道:
>>> On Mon, 15 Jun 2026 04:29:05 +0100,
>>> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>>>
>>>> Fix the LIP range leak when bitmap_zalloc() failed. Besides refactor
>>>
>>> Typo.
>>>
>>>> error handling code to make it a little simpler.
>>>
>>> No. Please don't mix fixes and (totally pointless) refactoring.
>> OK, I will only keep fix in this patch.>
>>>>
>>>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>>>> ---
>>>> drivers/irqchip/irq-gic-v3-its.c | 21 +++++++++------------
>>>> 1 file changed, 9 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>>> index 291d7668cc8d..2b7b546c43c8 100644
>>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>>> @@ -2217,10 +2217,9 @@ static int __init its_lpi_init(u32 id_bits)
>>>> static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
>>>> {
>>>> unsigned long *bitmap = NULL;
>>>> - int err = 0;
>>>>
>>>> do {
>>>> - err = alloc_lpi_range(nr_irqs, base);
>>>> + int err = alloc_lpi_range(nr_irqs, base);
>>>> if (!err)
>>>> break;
>>>>
>>>> @@ -2228,22 +2227,20 @@ static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
>>>> } while (nr_irqs > 0);
>>>>
>>>> if (!nr_irqs)
>>>> - err = -ENOSPC;
>>>> -
>>>> - if (err)
>>>> - goto out;
>>>> + goto err_out;
>>>>
>>>> bitmap = bitmap_zalloc(nr_irqs, GFP_ATOMIC);
>>>> if (!bitmap)
>>>> - goto out;
>>>> + goto err_free_lpi;
>>>>
>>>> *nr_ids = nr_irqs;
>>>> -
>>>> -out:
>>>> - if (!bitmap)
>>>> - *base = *nr_ids = 0;
>>>> -
>>>> return bitmap;
>>>> +
>>>> +err_free_lpi:
>>>> + free_lpi_range(*base, nr_irqs);
>>>> +err_out:
>>>> + *base = *nr_ids = 0;
>>>> + return NULL;
>>>> }
>>>>
>>>> static void its_lpi_free(unsigned long *bitmap, u32 base, u32 nr_ids)
>>>
>>> Honestly, I question the validity of handling errors this way. You are
>>> already unable to allocate a per-device bitmap. And yet you are
>>> calling free_lpi_range(), which has the interesting property of
>>> *allocating* memory. Which you don't have. Oh wait...
>> You are right. I'm considering use xarray to track the lpi range or
>> modify free_lpi_range to try merge first before memory allocation.
>> What would you recommend?
>
> My personal take on this is that leaking a few LPIs is not a big deal,
> given how many we have. You are trying to optimise for an error case
> that never happens, and I really don't want to add more complexity to
> this.
OK. I will drop this patch in next version.
Thanks,
Kemeng>
> M.
>
^ permalink raw reply
* Re: [PATCH 2/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Kemeng Shi @ 2026-06-18 1:00 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <86zf0ts739.wl-maz@kernel.org>
在 2026/6/17 20:07:54, Marc Zyngier 写道:
> On Tue, 16 Jun 2026 02:39:10 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> 在 2026/6/15 16:59:14, Marc Zyngier 写道:
>>> On Mon, 15 Jun 2026 04:29:06 +0100,
>>> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>>>
>>>> Fix collection leak when its_init_domain() failed in its_probe_one().
>>>>
>>>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>>>> ---
>>>> drivers/irqchip/irq-gic-v3-its.c | 10 +++++++++-
>>>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>>> index 2b7b546c43c8..df26ddc97ae2 100644
>>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>>> @@ -3032,6 +3032,12 @@ static int its_alloc_collections(struct its_node *its)
>>>> return 0;
>>>> }
>>>>
>>>> +static void its_free_collections(struct its_node *its)
>>>> +{
>>>> + kfree(its->collections);
>>>> + its->collections = NULL;
>>>> +}
>>>
>>> Why do we need an extra helper for something that has a single calling
>>> spot? Why is it important to set collections to NULL, given that we're
>>> about to free the structure without even looking further?
>>>
>> The extra helper is added for symmetry with its_alloc_collections(), keeping
>> allocation/deallocation logic paired.
>
> But there is zero logic here. None. it is a call to kfree(), just
> that, and we don't need any additional abstraction.
>
>> In this way, we need to only modified
>> allocation/deallocation function if more member is added for collections.
>
> Well, when we get there, we can always add an abstraction.
>
>> Setting collections to NULL is a personal habit to quickly catch use-after-free
>> of collections. Could drop this which is not that import.
>
> I don't see the point of doing that.
>
Thanks for feedback. I will drop its_free_collections() in release code in next
version.
Thanks,
Kemeng> M.
>
^ permalink raw reply
* Re: [PATCH v2 1/2] soc: aspeed: add BMC-side PCIe BMC device driver
From: Andrew Jeffery @ 2026-06-18 0:58 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel, anirudhsriniv
In-Reply-To: <CAFi2wKYgxKpp0ezzryYhFPDeqAeHhUq9Lhm67pVpnXRg+c2Vhw@mail.gmail.com>
Hi Grégoire,
On Wed, 2026-06-17 at 08:40 +0200, Grégoire Layet wrote:
> Hello Andrew,
>
> > The concept sounds reasonable to me. There's probably some bikeshedding
> > to do on the devicetree property though.
>
> Yes, having looked at how it's done, I would say :
> 'aspeed,vuart-over-pci' and 'aspeed,kcs-over-pci' flags would be
> better.
>
> > Can you outline the duplication you're concerned about? I think it's a
> > matter of resolving the SCU syscon to its regmap, then performing the
> > necessary accesses?
>
> Both drivers will need to set :
> - Enable PCI BMC Device MMIO
> - Enable PCI BMC Device IRQ
> - Enable PCI BMC Device MSI rooting over PCI Device 1 (BAR1)
> - Enable Host 2 BMC MSI interrupts
> - PCI device class to 0xff000000 to be identified as a MFD device. The
> reset default is 0x0C070100 which is an IPMI KCS device, but that
> causes issues as it is detected by ipmi_si but can't be loaded because
> of non default KCS address.
>
> Sorry for my errors, there is not that much. But both drivers will do
> almost the same initialisation. That was my code duplication concern.
I think it's valid to be concerned, but perhaps not for the reason of
code duplication. If there are multiple consumers then we need to
ensure consistency of configuration and correctness wrt to enabling /
disabling the capability based on the number of consumers.
>
> > I think it's not as bad as you make it out to be. The SCU's regmap
> > protects updates to individual registers under a lock, so concurrent
> > modification isn't a concern. The hardware design choices make all of
> > this slightly awkward for any related software design. As an
> > alternative you could implement a mini subsystem that relevant drivers
> > could call through to set the bits, but I currently think that's
> > unnecessary work.
>
> You are right it's not as bad as I thought.
> For now, I will focus on the VUART until the solution has been
> validated. Then I will easily do the same for the KCS over PCI.
I think it's a good step to at least solve one thing at a time, so long
as we're not precluding making those future steps.
>
> So I'll do for the V3 of the BMC side driver:
> - modify the device tree binding to have 'aspeed,ast2600-vuart' and
> add the 'aspeed,vuart-over-pci' boolean flag, only for the ast2600.
Just to confirm, you're proposing modifying the 8250 binding?
> - modify the '8250_aspeed_vuart' driver to add 'aspeed,ast2600-vuart' support.
> - add vuart over pci enable and disable code to the '8250_aspeed_vuart' driver.
>
Sounds like a reasonable start to me.
Andrew
^ permalink raw reply
* Re: [PATCH v6] soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read
From: Andrew Jeffery @ 2026-06-18 0:44 UTC (permalink / raw)
To: Karthikeyan KS
Cc: joel, andrew, Kees Cook, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-hardening
In-Reply-To: <20260617131013.64188-1-karthiproffesional@gmail.com>
On Wed, 2026-06-17 at 13:10 +0000, Karthikeyan KS wrote:
> This looks like a lot of heavily LLM-assisted effort. Please review the
> relevant documentation, starting here:
> https://docs.kernel.org/process/submitting-patches.html#using-assisted-by
>
> ==> I partly agree. The code and bug analysis are done manually.
> LLM use was the out of tree test harness and lightly polishing
> the commit message. None of the submitted code is generated.
> If you'd prefer, I can reword the changelog in my own words or
> add an Assisted-by tag ?
>
Thanks for the clarification. It's probably okay as-is in that case,
but that was unclear previously.
> I feel the testing strategy is pretty questionable. Any invariant
> violation is possible with that type of meddling.
>
> ==> The underlying bug is a kfifo SPSC contract violation. My intent with the
> test wasn't to simulate the race itself, but to reconstruct the post race state
> specifically where (in - out) exceeds the buffer size and show it causes a
> usercopy overflow in the unpatched code, handled safely after the fix.
>
> ==> I take your point that forcing that state can itself produce violations that
> wouldn't occur naturally. Since the bug is provable from the source but hard to
> trigger on demand, I'd rather ask what validation you'd accept here?
I'm aiming to build confidence that the change has been tested in
practice beyond spherical-cow circumstances. Isolating the conditions
this way seems okay, but I'd class the testing approach as necessary-
but-not-sufficient. It's important that the change is tested under
typical conditions to build confidence against regressions, as well as
atypical conditions.
>
> I was interested in whether you drove the interrupt sequence via
> emulated hardware. I asked because upstream qemu doesn't currently
> support the snoop device.
>
> ==> My apologies for the confusion, I mixed up things. I have not driven the
> interrupt sequence in emulation; as you noted, upstream QEMU doesn't model the
> snoop device. I've described the actual hardware context below.
>
> In v3 you said:
> The issue was observed on physical AST2600 (dual-core Cortex-A7)
> in production under heavy POST code traffic during concurrent
> userspace reads.
> https://lore.kernel.org/all/20260527175939.2939714-1-karthiproffesional@gmail.com/
> Is this true? What platform did you test with?
>
> ==> Yes, the underlying failure is real. It was observed on an AST2600-based
> production BMC running a vendor BSP kernel under continuous host reboot
> cycles. Because that platform can't currently be brought up on pure
> mainline without substantial out-of-tree board support, I have not run
> this exact mainline patch on the physical silicon, observed under the
> BSP kernel, not yet verified as the mainline patch. I should have made
> that distinction clear earlier in the thread.
Can you confirm you you have tested on hardware a backport of this
patch to your BSP kernel?
>
> ==> If there's a way you'd consider valid for validating a fix like this
> without a full mainline bring up on the SoC, such as a targeted kfifo unit
> test, or something else you'd accept.I'd appreciate the pointer and I'll
> do that.
No, I believe the change is fine, but the claim of testing under qemu
when qemu doesn't model the necessary hardware was a red flag that
needed to be addressed, doubly so in the absence of your track record
of upstream work.
Thanks,
Andrew
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: patchwork-bot+netdevbpf @ 2026-06-18 0:20 UTC (permalink / raw)
To: Christian Marangi
Cc: nbd, lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, daniel, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260615151106.15438-1-ansuelsmth@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 15 Jun 2026 17:11:00 +0200 you wrote:
> Everything configured in phylink_config it's assumed to be set before
> calling phylink_create() to permit correct parsing of all the different
> modes and capabilities.
>
> Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
> internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
> probably due to an auto-rebase, placed the configuration of the INTERNAL
> interface mode for the supported_interfaces for phylink_config right after
> phylink_create() introducing a possible problem with supported interfaces
> parsing.
>
> [...]
Here is the summary with links:
- [net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
https://git.kernel.org/netdev/net/c/e4b4d8410c7c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: airoha: Stop TX queues on error path in airoha_dev_open
From: Jakub Kicinski @ 2026-06-17 23:44 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178160729880.2156257.7978513589649053826@gmail.com>
On Tue, 16 Jun 2026 18:50:39 +0800 Wayen Yan wrote:
> In airoha_dev_open(), if airoha_set_vip_for_gdm_port() fails after
> netif_tx_start_all_queues() has been called, the TX queues remain
> started while the device configuration is incomplete. This leaves
> the device in an inconsistent state where packets could be
> transmitted before the VIP/IFC port configuration is complete.
Not sure if this was superseded by another posting but FWIW
this posting did not apply.
^ permalink raw reply
* [PATCH v2] firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()
From: Unnathi Chalicheemala @ 2026-06-17 23:35 UTC (permalink / raw)
To: Sudeep Holla, Jens Wiklander
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, kernel,
Trilok Soni, Satya Durga Srinivasu Prabhala,
Unnathi Chalicheemala
ffa_partition_info_get() passes uuid_str directly to uuid_parse()
without a NULL check. When a caller passes NULL, uuid_parse() ->
__uuid_parse() -> uuid_is_valid() dereferences the pointer, causing
a kernel panic:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000040
pc : uuid_parse+0x40/0xac
lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa]
Add a NULL guard before uuid_parse() so a NULL argument returns
-ENODEV instead of crashing. Callers are expected to always supply
a valid partition UUID, so NULL is not a supported input.
Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions")
Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
---
Changes in v2:
- Drop special-casing of NULL/empty string to uuid_null; treat NULL as
an error instead - as pointed out by Sudeep in v1.
- Simplify to a single NULL guard before uuid_parse() rather than a
separate branch
- Link to v1: https://patch.msgid.link/20260611-ffa_partition_nullptr_fix-v1-1-ec2b7ef7e130@oss.qualcomm.com
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index b9f17fda7243..4090be782329 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1129,7 +1129,7 @@ static int ffa_partition_info_get(const char *uuid_str,
uuid_t uuid;
struct ffa_partition_info *pbuf;
- if (uuid_parse(uuid_str, &uuid)) {
+ if (!uuid_str || uuid_parse(uuid_str, &uuid)) {
pr_err("invalid uuid (%s)\n", uuid_str);
return -ENODEV;
}
---
base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
change-id: 20260604-ffa_partition_nullptr_fix-66f37bb2630b
Best regards,
--
Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH net v3] net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()
From: Jakub Kicinski @ 2026-06-17 23:19 UTC (permalink / raw)
To: lorenzo
Cc: Wayen Yan, netdev, horms, pabeni, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161373805.2167512.2544164327472822616@gmail.com>
On Sun, 14 Jun 2026 07:30:54 +0800 Wayen Yan wrote:
> In airoha_dev_select_queue(), the expression:
>
> queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES;
>
> implicitly converts to unsigned arithmetic: when skb->priority is 0
> (the default for unclassified traffic), (0u - 1u) wraps to UINT_MAX,
> and UINT_MAX % 8 = 7, routing default best-effort packets to the
> highest-priority QoS queue. This causes QoS inversion where the
> majority of traffic on a PON gateway starves actual high-priority
> flows (VoIP, gaming, etc.).
>
> Fix by guarding the subtraction: when priority is 0, map to queue 0
> (lowest priority), otherwise apply the original (priority - 1) % 8
> mapping.
>
> Fixes: 2b288b81560b ("net: airoha: Introduce ndo_select_queue callback")
> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Reviewed-by: Joe Damato <joe@dama.to>
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..d476ef83c3 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1933,7 +1933,7 @@ static u16 airoha_dev_select_queue(struct net_device *dev, struct sk_buff *skb,
> */
> channel = netdev_uses_dsa(dev) ? skb_get_queue_mapping(skb) : port->id;
> channel = channel % AIROHA_NUM_QOS_CHANNELS;
> - queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES; /* QoS queue */
> + queue = skb->priority ? (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES : 0;
Hi Lorenzo, is there a reason we're subtracting 1 here in the first
place? Could be just me, but may be worth adding a comment here.
Intuitively if we are "narrowing" 16 prios to 8 queues it'd make most
sense to group the adjacent ones -- divide by two.
Please respin with some sort of an explanation..
> queue = channel * AIROHA_NUM_QOS_QUEUES + queue;
>
> return queue < dev->num_tx_queues ? queue : 0;
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: stmmac: loongson1: Use dev_err_probe()
From: Jacob Keller @ 2026-06-17 22:36 UTC (permalink / raw)
To: Jakub Kicinski
Cc: keguang.zhang, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, linux-mips,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260617150744.05756f0b@kernel.org>
On 6/17/2026 3:07 PM, Jakub Kicinski wrote:
> On Wed, 17 Jun 2026 14:26:25 -0700 Jacob Keller wrote:
>> It does claim that it has benefit since you get the error code emitted
>> symbolically. But we have %pe for that. I wonder if dev_err_probe
>> predates %pe?
>
> I'd argue
>
> No of match data provided: -EINVAL
>
> is more confusing than just:
>
> No of match data provided
>
> the EINVAL is meaningless and hardcoded in this case?
Yea, it is a bit more pointless with a hard-coded error.
^ permalink raw reply
* Re: [PATCH v5 2/8] media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
From: Sakari Ailus @ 2026-06-17 22:36 UTC (permalink / raw)
To: Frank.Li
Cc: Mauro Carvalho Chehab, Michael Riesch, Laurent Pinchart, Frank Li,
Martin Kepplinger-Novakovic, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-media, linux-kernel,
imx, devicetree, linux-arm-kernel
In-Reply-To: <20260617-imx8qxp_pcam-v5-2-7fa6c8e7fba7@nxp.com>
Hi Frank,
Thanks for the patch.
On Wed, Jun 17, 2026 at 03:50:12PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Many V4L2 subdev drivers implement the same registration and media pad
> setup logic for simple pipelines consisting of a single sink pad and a
> single source pad. As a result, the same boilerplate code is duplicated
> across multiple drivers.
>
> Introduce a common helper library for 1-to-1 subdevs to encapsulate the
> registration, media entity initialization, and cleanup paths. Drivers
> can embed a struct v4l2_subdev_1to1 instance and use the provided helper
> APIs instead of open-coding the setup sequence.
I appreciate your efforts in trying to reduce the amount of code drivers
need simply to get things done but I think there are a few issues with the
approach taken in this patch:
- The new helpers aren't generic enough, but require two pads; one sink,
one source. You could provide special helpers for just this case, but
right now it looks like that if there's something you need that the
helper assumes you don't, you can't use the helper at all. In other
words, more modularity would be nice.
- The new helper should work with the existing types and not add new types
(struct v4l2_subdev_1to1).
- There should be a way to provide default V4L2 fwnode endpoint
configuration as well as to validate the obtained configuration.
I don't have a good proposal to address the above but at least one way I
can think of making error handling easier would be to use devm_() for
teardown in more places we to today. That certainly does have its own
issues though.
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH] net: stmmac: loongson1: Use dev_err_probe()
From: Jakub Kicinski @ 2026-06-17 22:07 UTC (permalink / raw)
To: Jacob Keller
Cc: keguang.zhang, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, linux-mips,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <6b8db599-5bb2-47f9-ab53-a0b5141af2e5@intel.com>
On Wed, 17 Jun 2026 14:26:25 -0700 Jacob Keller wrote:
> It does claim that it has benefit since you get the error code emitted
> symbolically. But we have %pe for that. I wonder if dev_err_probe
> predates %pe?
I'd argue
No of match data provided: -EINVAL
is more confusing than just:
No of match data provided
the EINVAL is meaningless and hardcoded in this case?
^ permalink raw reply
* [PATCH] pinctrl: bcm2835: Don't remove an unregistered GPIO chip
From: Daniel McCarthy @ 2026-06-17 22:04 UTC (permalink / raw)
To: Linus Walleij, Florian Fainelli, Ray Jui, Scott Branden
Cc: linux-gpio, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Daniel McCarthy
If the devm_pinctrl_register() function fails,
bcm2835_pinctrl_probe() calls gpiochip_remove()
before gpiochip_add_data() has registered the GPIO chip.
This means that upon failure the gpio_chip.gpiodev
is NULL resulting in a null pointer dereference
inside the gpiochip_remove() function.
Remove the unnecessary function call to gpiochip_remove().
No GPIO cleanup is required because the GPIO chip
has not yet been registered. Without this change there
is potential for a kernel panic upon registration failure
Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
Signed-off-by: Daniel McCarthy <daniel@dragonzap.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index e7b35019a5a7..725e880ae086 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -1350,7 +1350,6 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
pc->pctl_desc = *pdata->pctl_desc;
pc->pctl_dev = devm_pinctrl_register(dev, &pc->pctl_desc, pc);
if (IS_ERR(pc->pctl_dev)) {
- gpiochip_remove(&pc->gpio_chip);
return PTR_ERR(pc->pctl_dev);
}
--
2.53.0
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: spi: nxp,imx94-xspi: add DMA properties
From: han.xu @ 2026-06-17 21:55 UTC (permalink / raw)
To: Han Xu, Haibo Chen, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-spi, imx, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260617215520.3327836-1-han.xu@oss.nxp.com>
From: Han Xu <han.xu@nxp.com>
Add dmas and dma-names to describe TX and RX DMA channels for the i.MX94
XSPI controller.
Signed-off-by: Han Xu <han.xu@nxp.com>
---
.../devicetree/bindings/spi/nxp,imx94-xspi.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/nxp,imx94-xspi.yaml b/Documentation/devicetree/bindings/spi/nxp,imx94-xspi.yaml
index 16a0598c6d033..ccf841f194c06 100644
--- a/Documentation/devicetree/bindings/spi/nxp,imx94-xspi.yaml
+++ b/Documentation/devicetree/bindings/spi/nxp,imx94-xspi.yaml
@@ -30,6 +30,16 @@ properties:
- const: base
- const: mmap
+ dmas:
+ items:
+ - description: Transmit DMA
+ - description: Receive DMA
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
interrupts:
items:
- description: interrupt for EENV0
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: imx94-xspi: add the DMA channels
From: han.xu @ 2026-06-17 21:55 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Han Xu, devicetree, imx, linux-arm-kernel, linux-kernel
From: Han Xu <han.xu@nxp.com>
Add the DMA channels for iMX94 XSPI controller.
Signed-off-by: Han Xu <han.xu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx94.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index c460ece6070f8..9de1b9754450e 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -820,6 +820,8 @@ xspi1: spi@42b90000 {
#size-cells = <0>;
clocks = <&scmi_clk IMX94_CLK_XSPI1>;
clock-names = "per";
+ dmas = <&edma2 27 0 0>, <&edma2 28 0 FSL_EDMA_RX>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -836,6 +838,8 @@ xspi2: spi@42be0000 {
#size-cells = <0>;
clocks = <&scmi_clk IMX94_CLK_XSPI2>;
clock-names = "per";
+ dmas = <&edma4 42 0 0>, <&edma4 43 0 FSL_EDMA_RX>;
+ dma-names = "tx", "rx";
status = "disabled";
};
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Conor Dooley @ 2026-06-17 21:41 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617-deed-snap-4649ffae0e27@spud>
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
On Wed, Jun 17, 2026 at 10:23:56PM +0100, Conor Dooley wrote:
> On Wed, Jun 17, 2026 at 08:47:53PM +0300, Stefan Dösinger wrote:
> > Am Mittwoch, 17. Juni 2026, 19:08:02 Ostafrikanische Zeit schrieb Conor
> > Dooley:
> > > On Tue, Jun 16, 2026 at 11:26:21PM +0300, Stefan Dösinger wrote:
> >
> > > > +F: Documentation/devicetree/zte,zx297520v3-*
> > >
> > > Sashiko complaint here looks valid.
> >
> > Yes, it is valid.
> >
> > It also brought up another concern in patch 12 that has an impact on this
> > binding:
> >
> > Am Dienstag, 16. Juni 2026, 23:42:19 Ostafrikanische Zeit schrieb sashiko-
> > bot@kernel.org:
> > > issue(s) to consider: - [Low] The `syscon-reboot` node is incorrectly
> > > defined at the root level using the explicitly deprecated `regmap`
> > > property. --
> >
> > And indeed "regmap" is deprecated and I missed it somehow. As far as I
> > understand, to put syscon-reboot as a child of the clock, I need to add the
> > simple-mfd .compatible:
> >
> > Either
> >
> > topclk: clock-controller@13b000 {
> > compatible = "zte,zx297520v3-topclk", "syscon", "simple-mfd";
> > reg = <0x0013b000 0x400>;
> > ...
> > syscon-reboot {
> > compatible = "syscon-reboot";
> > regmap = <&topclk>;
> > offset = <0x0>;
> > mask = <0x1>;
> > };
> > };
> >
> > --- or ---
> >
> > something@13b000 {
> > compatible = "zte,zx297520v3-topcrm", "syscon", "simple-mfd";
> > reg = <0x0013b000 0x400>;
> > ranges;
> >
> > topclk: clock-controller@0 {
> > compatible = "zte,zx297520v3-topclk";
> > ...
> > }
> >
> > syscon-reboot {
> > compatible = "syscon-reboot";
> > offset = <0x0>;
> > mask = <0x1>;
> > };
> > };
> >
> > I see both ways in existing DTS files (e.g. imx6sl.dtsi for the fomer,
> > uniphier-pro4.dtsi for the latter). Is there a preferred way? I have a mild
> > preference for the first, as it would keep all 3 clocks in the same way. If I
> > go for the second, the clock driver would have to query its own node and the
> > parent node for the regmap.
>
> The first one is more natural...
>
> > AFAIU unrelated to syscon-reboot option 2 would give me the opportunity to
> > have separate clock and reset nodes and bindings and skip the aux bus, but
> > this would not be a correct representation of how the hardware works.
>
> ...for this reason!
> Do you actually need an aux bus here though? Since you have to add
> simple-mfd for your the syscon-reboot and simple-mfd is a real bus, can you
> set the reset controller up with an mfd_cell + devm_mfd_add_devices()
> instead?
Although, the /naming/ is more natural in the second case. "topcrm"
sounds like the actual name of this register region. And syscon@ for the
node name.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] net: stmmac: loongson1: Use dev_err_probe()
From: Jacob Keller @ 2026-06-17 21:26 UTC (permalink / raw)
To: Jakub Kicinski
Cc: keguang.zhang, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, linux-mips,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260617135407.6ff54e27@kernel.org>
On 6/17/2026 1:54 PM, Jakub Kicinski wrote:
> On Tue, 16 Jun 2026 16:42:18 -0700 Jacob Keller wrote:
>> I'd probably also argue this may go against the desired goals of
>> net-next with only wanting such cleanups when in the context of other
>> larger work. Of course that decision ultimately belongs to the maintainers.
>
> Yes, feeding const EINVAL into dev_err_probe() is pretty pointless
> so if this helps it's just by "saving" 2 LoC. I'm not sure it's worth
> it even in context of larger work, let along by itself.
It does claim that it has benefit since you get the error code emitted
symbolically. But we have %pe for that. I wonder if dev_err_probe
predates %pe?
Per commit: 532888a59505 ("driver core: Better advertise dev_err_probe()"):
> Describing the usage of dev_err_probe() as being (only?) "deemed
> acceptable" has a bad connotation. In fact dev_err_probe() fulfills
> three tasks:
>
> - handling of EPROBE_DEFER (even more than degrading to dev_dbg())
> - symbolic output of the error code
> - return err for compact error code paths
This was in 2023.. %pe was introduced in 2019, so I guess %pe is even older.
I personally find dev_err_probe acceptable and might find it nice when
writing new code, but I agree its not really meaningful gain to refactor
existing legacy code.
Anyways, all this to say in too many words: this patch doesn't seem to
have much value for netdev.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Conor Dooley @ 2026-06-17 21:23 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <-l2OM6P0RNSYRQfOSObOyw@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]
On Wed, Jun 17, 2026 at 08:47:53PM +0300, Stefan Dösinger wrote:
> Am Mittwoch, 17. Juni 2026, 19:08:02 Ostafrikanische Zeit schrieb Conor
> Dooley:
> > On Tue, Jun 16, 2026 at 11:26:21PM +0300, Stefan Dösinger wrote:
>
> > > +F: Documentation/devicetree/zte,zx297520v3-*
> >
> > Sashiko complaint here looks valid.
>
> Yes, it is valid.
>
> It also brought up another concern in patch 12 that has an impact on this
> binding:
>
> Am Dienstag, 16. Juni 2026, 23:42:19 Ostafrikanische Zeit schrieb sashiko-
> bot@kernel.org:
> > issue(s) to consider: - [Low] The `syscon-reboot` node is incorrectly
> > defined at the root level using the explicitly deprecated `regmap`
> > property. --
>
> And indeed "regmap" is deprecated and I missed it somehow. As far as I
> understand, to put syscon-reboot as a child of the clock, I need to add the
> simple-mfd .compatible:
>
> Either
>
> topclk: clock-controller@13b000 {
> compatible = "zte,zx297520v3-topclk", "syscon", "simple-mfd";
> reg = <0x0013b000 0x400>;
> ...
> syscon-reboot {
> compatible = "syscon-reboot";
> regmap = <&topclk>;
> offset = <0x0>;
> mask = <0x1>;
> };
> };
>
> --- or ---
>
> something@13b000 {
> compatible = "zte,zx297520v3-topcrm", "syscon", "simple-mfd";
> reg = <0x0013b000 0x400>;
> ranges;
>
> topclk: clock-controller@0 {
> compatible = "zte,zx297520v3-topclk";
> ...
> }
>
> syscon-reboot {
> compatible = "syscon-reboot";
> offset = <0x0>;
> mask = <0x1>;
> };
> };
>
> I see both ways in existing DTS files (e.g. imx6sl.dtsi for the fomer,
> uniphier-pro4.dtsi for the latter). Is there a preferred way? I have a mild
> preference for the first, as it would keep all 3 clocks in the same way. If I
> go for the second, the clock driver would have to query its own node and the
> parent node for the regmap.
The first one is more natural...
> AFAIU unrelated to syscon-reboot option 2 would give me the opportunity to
> have separate clock and reset nodes and bindings and skip the aux bus, but
> this would not be a correct representation of how the hardware works.
...for this reason!
Do you actually need an aux bus here though? Since you have to add
simple-mfd for your the syscon-reboot and simple-mfd is a real bus, can you
set the reset controller up with an mfd_cell + devm_mfd_add_devices()
instead?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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