Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 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

* 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: 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 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

* [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: 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

* 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 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 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 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 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

* [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

* [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 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 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 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

* [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

* 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

* 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 v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-18  1:50 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
	Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
	Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260617-imx_mbox_rproc-v3-1-77948112defc@linutronix.de>

Hi Sebastian,

Thanks for your patch.

On Wed, Jun 17, 2026 at 08:55:26AM +0200, Sebastian Andrzej Siewior wrote:
>imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register
>which may timeout and is recognized as an error. This error is siltently
>dropped and not dropped to the caller.
>
>Forward the error to the caller.
>
>Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition")
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> drivers/mailbox/imx-mailbox.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>index 246a9a9e39520..0028073be4a71 100644
>--- a/drivers/mailbox/imx-mailbox.c
>+++ b/drivers/mailbox/imx-mailbox.c
>@@ -227,6 +227,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> 	u32 val;
> 	int ret, count;
> 
>+	ret = 0;
> 	switch (cp->type) {
> 	case IMX_MU_TYPE_TX:
> 		imx_mu_write(priv, *arg, priv->dcfg->xTR + cp->idx * 4);
>@@ -259,7 +260,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> 		return -EINVAL;
> 	}
> 
>-	return 0;
>+	return ret;
> }

I just rethink about the logic here and rewrite the logic as below.
error code is propogated to caller and poll timeout are removed.
Please see whether it looks good for you or not.

[PATCH] mailbox: imx: make TXDB non-blocking and avoid polling in atomic context

The IMX_MU_TYPE_TXDB_V2 path currently writes to the GIR register and
then polls until the bit is cleared using readl_poll_timeout().

Because send_data() is invoked under spin_lock_irqsave() from the mailbox
core, meaning the polling loop can run in atomic context with interrupts
disabled. In the worst case, the current implementation may busy-wait for
up to 100ms, leading to excessive interrupt latency and potential soft
lockup warnings.

Moreover, the TXDB channel implements a doorbell mechanism, where the
sender only needs to trigger the event when the channel is idle. Waiting
for the GIR bit to clear after the write is no good with polling.

Fix this by:
  - Checking the GIR bit before issuing the write
  - Returning -EBUSY if the channel is still active
  - Removing the post-write polling loop

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/mailbox/imx-mailbox.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 796ba983db29e..ed53bcffec673 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -241,7 +241,6 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
 {
 	u32 *arg = data;
 	u32 val;
-	int ret, count;
 
 	switch (cp->type) {
 	case IMX_MU_TYPE_TX:
@@ -253,22 +252,14 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
 		queue_work(system_bh_wq, &cp->txdb_work);
 		break;
 	case IMX_MU_TYPE_TXDB_V2:
+		val = readl(priv->base + priv->dcfg->xCR[IMX_MU_GCR]);
+		if (val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)) {
+			dev_info(priv->dev, "channel [%d] type: %d busy\n", cp->idx, cp->type);
+			return -EBUSY;
+		}
+
 		imx_mu_write(priv, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx),
 			     priv->dcfg->xCR[IMX_MU_GCR]);
-		ret = -ETIMEDOUT;
-		count = 0;
-		while (ret && (count < 10)) {
-			ret =
-			readl_poll_timeout(priv->base + priv->dcfg->xCR[IMX_MU_GCR], val,
-					   !(val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)),
-					   0, 10000);
-
-			if (ret) {
-				dev_warn_ratelimited(priv->dev,
-						     "channel type: %d timeout, %d times, retry\n",
-						     cp->type, ++count);
-			}
-		}
 		break;
 	default:
 		dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);
-- 
2.50.1

Thanks,
Peng

> 
> static int imx_mu_generic_rx(struct imx_mu_priv *priv,
>
>-- 
>2.53.0
>


^ permalink raw reply related

* Re: [PATCH v1] mfd: mt6397-irq: Fix PM notifier use-after-free
From: 최유호 @ 2026-06-18  1:53 UTC (permalink / raw)
  To: Lee Jones
  Cc: Matthias Brugger, AngeloGioacchino Del Regno, linux-kernel,
	linux-arm-kernel, linux-mediatek
In-Reply-To: <20260617152615.GO10056@google.com>

On Wed, 17 Jun 2026 at 11:26, Lee Jones <lee@kernel.org> wrote:

> [Severity: High]
> Is it safe to explicitly remove the IRQ domain here while the devm-managed
> parent threaded IRQ remains active?
>
> The parent IRQ was requested earlier via devm_request_threaded_irq(). Because
> devres cleanup does not run until the probe function completely fails and
> returns, the parent IRQ remains active and enabled during this window.
>
> If an interrupt triggers during this error path, the active IRQ handler
> mt6397_irq_thread() will execute and call mt6397_irq_handle_reg(). This in
> turn calls irq_find_mapping(), which will dereference the freed irq_domain,
> resulting in a use-after-free.

Thanks for pointing this out. Findings 1 and 3 look like pre-existing
issues. Finding 2, however, appears to be related to the error-path cleanup
I added.

I will rework the patch so the notifier and irq_domain cleanup ordering is
handled consistently.


^ permalink raw reply

* Re: [PATCH v7 15/20] perf: arm_pmuv3: Handle IRQs for Partitioned PMU guest counters
From: wuyifan @ 2026-06-18  1:53 UTC (permalink / raw)
  To: Colton Lewis, kvm
  Cc: Alexandru Elisei, Paolo Bonzini, Jonathan Corbet, Russell King,
	Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
	Mingwei Zhang, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
	Mark Rutland, Shuah Khan, Ganapatrao Kulkarni, James Clark,
	linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
	linux-perf-users, linux-kselftest, wangyushan, Zhou Wang, xuwei5,
	prime.zeng, fanghao11
In-Reply-To: <20260504211813.1804997-16-coltonlewis@google.com>

Hi Colton,

On 5/5/2026 5:18 AM, Colton Lewis wrote:
>   static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
>   {
> -	u64 pmovsr;
>   	struct perf_sample_data data;
>   	struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
>   	struct pt_regs *regs;
> +	u64 host_set = kvm_pmu_host_counter_mask(cpu_pmu);
> +	u64 pmovsr;
kvm_pmu_host_counter_mask() is called from armv8pmu_handle_irq(). This
interrupt fires in both host and guest contexts.

However, kvm_pmu_host_counter_mask() dereferences
host_data_ptr(nr_event_counters). This indirection requires
kvm_arm_hyp_percpu_base[cpu] to be initialized, which only happens during
KVM hypervisor setup. When the interrupt fires in a guest kernel where 
KVM is
compiled but not active, the per-CPU base is NULL and the dereference 
faults.

Thanks,
Yifan



^ permalink raw reply

* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-18  1:57 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
	Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
	Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <ajNO3KSZV/elWONW@shlinux89>

On Thu, Jun 18, 2026 at 09:50:20AM +0800, Peng Fan wrote:
>Hi Sebastian,
>
>Thanks for your patch.
>
>On Wed, Jun 17, 2026 at 08:55:26AM +0200, Sebastian Andrzej Siewior wrote:
>>imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register
>>which may timeout and is recognized as an error. This error is siltently
>>dropped and not dropped to the caller.
>>
>>Forward the error to the caller.
>>
>>Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition")
>>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>>---
>> drivers/mailbox/imx-mailbox.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>>index 246a9a9e39520..0028073be4a71 100644
>>--- a/drivers/mailbox/imx-mailbox.c
>>+++ b/drivers/mailbox/imx-mailbox.c
>>@@ -227,6 +227,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
>> 	u32 val;
>> 	int ret, count;
>> 
>>+	ret = 0;
>> 	switch (cp->type) {
>> 	case IMX_MU_TYPE_TX:
>> 		imx_mu_write(priv, *arg, priv->dcfg->xTR + cp->idx * 4);
>>@@ -259,7 +260,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
>> 		return -EINVAL;
>> 	}
>> 
>>-	return 0;
>>+	return ret;
>> }
>
>I just rethink about the logic here and rewrite the logic as below.
>error code is propogated to caller and poll timeout are removed.
>Please see whether it looks good for you or not.

Ignore this. Pushed the button too early

>
>[PATCH] mailbox: imx: make TXDB non-blocking and avoid polling in atomic context
>
>+
> 		imx_mu_write(priv, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx),
> 			     priv->dcfg->xCR[IMX_MU_GCR]);

Oh. there might be issues without waiting here. For example, Linux just writes
the doorbell to notify SCMI processor power up a power domain, but when linux
continues to write registers, the SCMI processor may not fetch the message, then
linux will crash.

Regards
Peng

>-		ret = -ETIMEDOUT;
>-		count = 0;
>-		while (ret && (count < 10)) {
>-			ret =
>-			readl_poll_timeout(priv->base + priv->dcfg->xCR[IMX_MU_GCR], val,
>-					   !(val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)),
>-					   0, 10000);
>-
>-			if (ret) {
>-				dev_warn_ratelimited(priv->dev,
>-						     "channel type: %d timeout, %d times, retry\n",
>-						     cp->type, ++count);
>-			}
>-		}
> 		break;
> 	default:
> 		dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);
>-- 
>2.50.1
>
>Thanks,
>Peng
>
>> 
>> static int imx_mu_generic_rx(struct imx_mu_priv *priv,
>>
>>-- 
>>2.53.0
>>
>
>


^ permalink raw reply

* [PATCH v4] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Hongling Zeng @ 2026-06-18  2:06 UTC (permalink / raw)
  To: vkoul, Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd
  Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
	zhongling0719, Hongling Zeng, Frank Li

When terminating DMA transfers, active descriptors are not properly
reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
descriptors and their LLI chains to be permanently leaked.

Fix by using vchan_terminate_vdesc() which handles both cyclic and
non-cyclic descriptors by adding them to desc_terminated queue for
proper cleanup.

Add pchan->desc != pchan->done check to prevent double-adding completed
descriptors, which would corrupt the list.

Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Suggested-by: Frank Li <Frank.li@oss.nxp.com>

---
 Change in v2;
 -Add pchan->desc != pchan->done check to prevent race condition
  where completed descriptors could be double-added to desc_completed
  list, causing list corruption
---
 Change in v3:
 -Fix by using vchan_terminate_vdesc() as suggested by Frank Li
---
 Change in v4:
 -Correct the commit message
---
 drivers/dma/sun6i-dma.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 7a79f346250a..134ae840f176 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -946,16 +946,13 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
 
 	spin_lock_irqsave(&vchan->vc.lock, flags);
 
-	if (vchan->cyclic) {
-		vchan->cyclic = false;
-		if (pchan && pchan->desc) {
-			struct virt_dma_desc *vd = &pchan->desc->vd;
-			struct virt_dma_chan *vc = &vchan->vc;
-
-			list_add_tail(&vd->node, &vc->desc_completed);
-		}
+	if (pchan && pchan->desc && pchan->desc != pchan->done) {
+		struct virt_dma_desc *vd = &pchan->desc->vd;
+		
+		vchan_terminate_vdesc(vd);
 	}
 
+	vchan->cyclic = false;
 	vchan_get_all_descriptors(&vchan->vc, &head);
 
 	if (pchan) {
-- 
2.25.1



^ permalink raw reply related

* [PATCH v2] nvme-apple: Use acquire/release for queue enabled state
From: Gui-Dong Han @ 2026-06-18  2:15 UTC (permalink / raw)
  To: sven, kbusch, linux-nvme
  Cc: axboe, hch, sagi, j, neal, asahi, linux-kernel, linux-arm-kernel,
	baijiaju1990, Gui-Dong Han

apple_nvme_init_queue() initializes queue state and then marks the queue
enabled. The interrupt and request paths check enabled before using that
queue state.

The old wmb() after WRITE_ONCE(enabled, true) does not publish the
earlier initialization before enabled becomes visible. Use a release store
when enabling the queue and acquire loads when testing it.

Although the shutdown-side enabled accesses are not used for publishing
queue initialization, use helpers for them as well for consistency.

Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver")
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
---
v2:
- Drop the old wmb(), as suggested by Keith Busch.
- Use the queue enabled helpers in apple_nvme_disable(), as suggested by
  Keith Busch.
v1:
- Found by auditing READ_ONCE() used for synchronization.
- A similar fix can be found in 8df672bfe3ec.
---
 drivers/nvme/host/apple.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
index f9327feb87d0..291271c3954b 100644
--- a/drivers/nvme/host/apple.c
+++ b/drivers/nvme/host/apple.c
@@ -151,6 +151,23 @@ struct apple_nvme_queue {
 	bool enabled;
 };
 
+static inline bool apple_nvme_queue_enabled(struct apple_nvme_queue *q)
+{
+	/* Pair with apple_nvme_enable_queue(). */
+	return smp_load_acquire(&q->enabled);
+}
+
+static inline void apple_nvme_enable_queue(struct apple_nvme_queue *q)
+{
+	/* Publish queue initialization before setting q->enabled. */
+	smp_store_release(&q->enabled, true);
+}
+
+static inline void apple_nvme_disable_queue(struct apple_nvme_queue *q)
+{
+	WRITE_ONCE(q->enabled, false);
+}
+
 /*
  * The apple_nvme_iod describes the data in an I/O.
  *
@@ -677,7 +694,7 @@ static bool apple_nvme_handle_cq(struct apple_nvme_queue *q, bool force)
 	bool found;
 	DEFINE_IO_COMP_BATCH(iob);
 
-	if (!READ_ONCE(q->enabled) && !force)
+	if (!apple_nvme_queue_enabled(q) && !force)
 		return false;
 
 	found = apple_nvme_poll_cq(q, &iob);
@@ -780,7 +797,7 @@ static blk_status_t apple_nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
 	 * We should not need to do this, but we're still using this to
 	 * ensure we can drain requests on a dying queue.
 	 */
-	if (unlikely(!READ_ONCE(q->enabled)))
+	if (unlikely(!apple_nvme_queue_enabled(q)))
 		return BLK_STS_IOERR;
 
 	if (!nvme_check_ready(&anv->ctrl, req, true))
@@ -863,7 +880,7 @@ static void apple_nvme_disable(struct apple_nvme *anv, bool shutdown)
 	nvme_quiesce_io_queues(&anv->ctrl);
 
 	if (!dead) {
-		if (READ_ONCE(anv->ioq.enabled)) {
+		if (apple_nvme_queue_enabled(&anv->ioq)) {
 			apple_nvme_remove_sq(anv);
 			apple_nvme_remove_cq(anv);
 		}
@@ -887,8 +904,8 @@ static void apple_nvme_disable(struct apple_nvme *anv, bool shutdown)
 		nvme_disable_ctrl(&anv->ctrl, false);
 	}
 
-	WRITE_ONCE(anv->ioq.enabled, false);
-	WRITE_ONCE(anv->adminq.enabled, false);
+	apple_nvme_disable_queue(&anv->ioq);
+	apple_nvme_disable_queue(&anv->adminq);
 	mb(); /* ensure that nvme_queue_rq() sees that enabled is cleared */
 	nvme_quiesce_admin_queue(&anv->ctrl);
 
@@ -1016,8 +1033,7 @@ static void apple_nvme_init_queue(struct apple_nvme_queue *q)
 		memset(q->tcbs, 0, anv->hw->max_queue_depth
 			* sizeof(struct apple_nvmmu_tcb));
 	memset(q->cqes, 0, depth * sizeof(struct nvme_completion));
-	WRITE_ONCE(q->enabled, true);
-	wmb(); /* ensure the first interrupt sees the initialization */
+	apple_nvme_enable_queue(q);
 }
 
 static void apple_nvme_reset_work(struct work_struct *work)
-- 
2.34.1


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox