* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Dev Jain @ 2026-06-19 4:46 UTC (permalink / raw)
To: Lance Yang
Cc: ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will,
catalin.marinas
In-Reply-To: <20260613060637.40039-1-lance.yang@linux.dev>
On 13/06/26 11:36 am, Lance Yang wrote:
>
> On Fri, Jun 12, 2026 at 04:44:22AM +0000, Dev Jain wrote:
>> Introduce a boot option to tag only at allocation time of the objects. This
>> reduces KASAN MTE overhead, the tradeoff being reduced ability of
>> catching bugs.
>>
>> Now, when a memory object will be freed, it will retain the random tag it
>> had at allocation time. This compromises on catching UAF bugs, till the
>> time the object is not reallocated, at which point it will have a new
>> random tag.
>>
>> Hence, not catching "use-after-free-before-reallocation" and not catching
>> "double-free" will be the compromise for reduced KASAN overhead.
>
> Hmm ... do we also need to teach the KASAN KUnit tests about this mode?
>
> With kasan.tag_only_on_alloc=on, free-time poisoning is skipped, so
> some UAF and double-free reports are skipped on purpose, but the tests
> still expect them :)
Yeah my opinion is that we shouldn't bother - but if we go ahead with this
patch in some shape or form then I'll see how to make kasan_test work with
this.
>
> Cheers, Lance
>
^ permalink raw reply
* Re: [RFC PATCH 2/2] kasan: hw_tags: Add boot option to elide free time poisoning
From: Dev Jain @ 2026-06-19 4:44 UTC (permalink / raw)
To: Isaac Manjarres
Cc: ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will,
catalin.marinas
In-Reply-To: <aiyi5flNkNNm0pSR@google.com>
On 13/06/26 5:53 am, Isaac Manjarres wrote:
> On Fri, Jun 12, 2026 at 04:44:24AM +0000, Dev Jain wrote:
>> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
>> index fc9169a547662..4fa8abb312faa 100644
>> --- a/mm/kasan/kasan.h
>> +++ b/mm/kasan/kasan.h
>> #ifdef CONFIG_KASAN_GENERIC
>> @@ -478,6 +489,16 @@ static inline u8 kasan_random_tag(void) { return 0; }
>>
>> static inline void kasan_poison(const void *addr, size_t size, u8 value, bool init)
>> {
>> + if (kasan_tag_only_on_alloc_enabled()) {
>> + if ((value != KASAN_SLAB_REDZONE) && (value != KASAN_PAGE_REDZONE)) {
>> + if (init)
>> + memset((void *)kasan_reset_tag(addr), 0, size);
>> + return;
>> + }
>> + }
>> +
>> + value |= 0xF0;
>> +
>
> I wonder if it would make more sense to have this as:
>
> if (kasan_tag_only_on_alloc_enabled() && (value == KASAN_SLAB_FREE ||
> value == KASAN_PAGE_FREE)) {
> if (init)
> memset((void *)kasan_reset_tag(addr), 0, size);
> return;
> }
>
> That seems a bit clearer to me as to what it is that you're doing, and
> also makes it so that you don't have to do any bit manipulation
> on the value when you're filling in the redzones.
Ah so you mean, we can define KASAN_SLAB_FREE and KASAN_PAGE_FREE to be
different values, leaving KASAN_SLAB_REDZONE and KASAN_PAGE_REDZONE to
be 0xFE, the poison value. Yep I'll do that.
>
> Thanks,
> Isaac
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Xueyuan Chen @ 2026-06-19 2:55 UTC (permalink / raw)
To: david
Cc: xueyuan.chen21, dave.hansen, akpm, linux-mm, linux-kernel,
linux-arm-kernel, x86, catalin.marinas, will, tglx, mingo, bp,
dave.hansen, luto, peterz, hpa, ljs, liam, vbabka, rppt, surenb,
mhocko, ziy, baolin.wang, npache, ryan.roberts, dev.jain, baohua,
lance.yang, yang, jannh
In-Reply-To: <0e5b23a6-4895-454a-9dfa-6dc21adc2991@kernel.org>
On Thu, Jun 18, 2026 at 02:36:25PM +0200, David Hildenbrand (Arm) wrote:
Hi, David
[...]
>Best to wait for some feedback.
Sure.
>I do wonder whether we want to pass an address instead of a page.
>
>https://lore.kernel.org/r/20260410151746.61150-2-kalyazin@amazon.com
>
>Wants to convert existing ones as well.
>
>That would imply that the caller must check for highmem.
>
>But then, we could just use existing set_memory_ro(), right?
>
Agreed. Passing an address and reusing the existing set_memory_ro()
definitely makes things simpler.
However, there is an arm64 specific limitation:
currently, the set_memory_r* api on arm64 only support the vmap
region and do not handle linear map addresses.
If we go this route, should I extend the arm64 set_memory_r*
implementation in the next version? The plan would be to make it check
for the bblm2 feature and modify the linear map PTEs accordingly.
What do you think?
Thanks,
Xueyuan
^ permalink raw reply
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Alexey Kardashevskiy @ 2026-06-19 2:05 UTC (permalink / raw)
To: Jason Gunthorpe, Aneesh Kumar K.V
Cc: Catalin Marinas, iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun, linuxppc-dev,
linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260618153705.GH231643@ziepe.ca>
On 19/6/26 01:37, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 09:37:22AM +0100, Aneesh Kumar K.V wrote:
>> Alexey Kardashevskiy <aik@amd.com> writes:
>>
>>> On 10/6/26 00:47, Jason Gunthorpe wrote:
>>>> On Tue, Jun 09, 2026 at 02:43:08PM +0100, Catalin Marinas wrote:
>>>>> On Thu, Jun 04, 2026 at 02:09:39PM +0530, Aneesh Kumar K.V (Arm) wrote:
>>>>>> This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
>>>>>> dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
>>>>>> are handled consistently.
>>>>>>
>>>>>> Today, the direct DMA path mostly relies on force_dma_unencrypted() for
>>>>>> shared/decrypted buffer handling. This series consolidates the
>>>>>> force_dma_unencrypted() checks in the top-level functions and ensures
>>>>>> that the remaining DMA interfaces use DMA attributes to make the correct
>>>>>> decisions.
>>>>>
>>>>> Please check Sashiko's reports, it has some good points:
>>>>>
>>>>> https://sashiko.dev/#/patchset/20260604083959.1265923-1-aneesh.kumar@kernel.org
>>>>>
>>>>> I think the main one is the swiotlb_tbl_map_single() changes which break
>>>>> AMD SME host support. There cc_platform_has(CC_ATTR_MEM_ENCRYPT) is true
>>>>> but force_dma_unencrypted() is false. Normally you'd not end up on this
>>>>> path but you can have swiotlb=force.
>>>>
>>>> IMHO that's an AMD issue, not with the design of this series..
>>>>
>>>> The series is right, a device that is !force_dma_decrypted() must be
>>>> considerd to be a trusted device and we must never place any DMA
>>>> mappings for a trusted device into shared memory.
>>>
>>> swiotlb=force forces swiotlb, not decryption.
>
> If force_dma_decrypted() == true then swiotlb must allocate from a
> decrypted memory pool. It is right there in the name!
>
> The hypervisor environment should *never* set force_dma_decrypted()
> because all devices can access all hypervisor memory, up to their IOVA
> limits.
True. But we do not have encrypted swiotlb pool today, right?
>
>>> So when I try "mem_encrypt=on iommu=pt swiotlb=force" with this
>>> patchset, it fails to boot. But it boots with a hack like this:
>
> On the host side I expect this to cause swiotlb to allocate encrypted
> memory and bounce to it.
>
>> u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
>> u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
>> dev->bus_dma_limit);
>> + /*
>> + * With memory encryption enabled, SWIOTLB is marked decrypted.
>> + * If SWIOTLB bouncing is forced, treat the device as requiring
>> + * decrypted DMA.
>> + */
>
> And this is more insane logic. The right fix is to allocate the
> swiotlb bounce from the *encrypted* pools when running on the
> hypervisor which requires undoing this abuse of force_dma_decrypted().
+1.
But how does the kernel decide if it is this swiotlb pool or just some page which happens to be below the IOVA limit?
swiotlb can be for bouncing (with all these dma_sync_single_for_cpu) or, if dev->dma_io_tlb_mem->for_alloc = true, for coherent allocation (no need in dma_sync_single_for_cpu).
I am looking for a way to set up my "sev-guest" device such as when dma_alloc_attrs(snp_dev->dev,...) happens, it allocates a page from the shared swiotlb pool (with no actual bouncing) and there is no obvious way to trick the DMA layer into doing that.
>
> Jason
--
Alexey
^ permalink raw reply
* Re: [PATCH v2] [net] net: airoha: fix foe_check_time allocation size
From: patchwork-bot+netdevbpf @ 2026-06-19 1:10 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161119471.2163752.14373384830691569758@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 19:52:36 +0800 you wrote:
> foe_check_time is declared as u16 pointer but was allocated with
> only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).
>
> When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2,
> it writes beyond the allocated buffer, causing heap buffer overflow and
> potential kernel crash.
>
> [...]
Here is the summary with links:
- [v2,net] net: airoha: fix foe_check_time allocation size
https://git.kernel.org/netdev/net/c/5c121ee63568
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 wireless-next] wifi: mt76: fix of_get_mac_address error handling
From: Rosen Penev @ 2026-06-19 1:50 UTC (permalink / raw)
To: Klara Modin, Rosen Penev
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <ajSDtsJCmYnMNJSD@parmesan.int.kasm.eu>
On Thu Jun 18, 2026 at 4:51 PM PDT, Klara Modin wrote:
> On 2026-06-18 16:01:45 -0700, Rosen Penev wrote:
>> On Thu, Jun 18, 2026 at 2:47 PM Klara Modin <klarasmodin@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > On 2026-04-26 22:17:46 -0700, Rosen Penev wrote:
>> > > Check return value instead of is_valid_ether_addr. The latter is handled
>> > > by the former.
>> > >
>> > > Signed-off-by: Rosen Penev <rosenp@gmail.com>
>> > > ---
>> > > drivers/net/wireless/mediatek/mt76/eeprom.c | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
>> > > index 93d91264687f..0f6ccf6ed53d 100644
>> > > --- a/drivers/net/wireless/mediatek/mt76/eeprom.c
>> > > +++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
>> > > @@ -93,7 +93,7 @@ mt76_eeprom_override(struct mt76_phy *phy)
>> > > if (err == -EPROBE_DEFER)
>> > > return err;
>> > >
>> > > - if (!is_valid_ether_addr(phy->macaddr)) {
>> > > + if (err) {
>> > > eth_random_addr(phy->macaddr);
>> > > dev_info(dev->dev,
>> > > "Invalid MAC address, using random address %pM\n",
>> > > --
>> > > 2.54.0
>> > >
>> >
>> > Recently I have started to see randomized MAC-addresses on my x86 laptop
>> > with a MT7922 and the above message printed in the kernel log. I have
>> > CONFIG_OF turned on, but since this is an ACPI system the device is not
>> > described by any device tree and the earlier of_get_mac_address() likely
>> > fails with -ENODEV. Looking at the !CONFIG_OF stub for
>> > of_get_mac_address it always returns -ENODEV, meaning this will always
>> > randomize the mac in that case too.
>
>> IIRC, the normal device_get_mac_address supports nvmem now. Does that
>> fix your use case?
>
> I tried this:
>
> diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
> index b99d7452800f..243a8f2c7bda 100644
> --- a/drivers/net/wireless/mediatek/mt76/eeprom.c
> +++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
> @@ -174,10 +174,9 @@ int
> mt76_eeprom_override(struct mt76_phy *phy)
> {
> struct mt76_dev *dev = phy->dev;
> - struct device_node *np = dev->dev->of_node;
> int err;
>
> - err = of_get_mac_address(np, phy->macaddr);
> + err = device_get_mac_address(dev->dev, phy->macaddr);
> if (err == -EPROBE_DEFER)
> return err;
>
>
> but I still get a random MAC.
Then the original patch should be reverted. Unfortunate that it doesn't
workq
>
>> >
>> > Reverting this patch fixes the issue and the correct MAC address is
>> > used. I'm not sure if there is any case where of_get_mac_addres() could
>> > fail in a way that results in a valid MAC address but it seems unlikely
>> > to me.
>> >
>> > Regards,
>> > Klara Modin
^ permalink raw reply
* Re: [PATCH v2] net: macb: add TX stall timeout callback to recover from lost TSTART write
From: patchwork-bot+netdevbpf @ 2026-06-19 1:20 UTC (permalink / raw)
To: Andrea della Porta
Cc: netdev, theo.lebrun, nicolas.ferre, claudiu.beznea, andrew+netdev,
davem, edumazet, kuba, pabeni, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, nb, lukasz, sjaeckel
In-Reply-To: <468f480454a314303bac6a54780b153f689f2267.1781598350.git.andrea.porta@suse.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 15:23:03 +0200 you wrote:
> From: Lukasz Raczylo <lukasz@raczylo.com>
>
> The MACB found in the Raspberry Pi RP1 suffers from sporadic stalls on
> the TX queue.
> While the exact root cause is not yet fully understood, it is likely
> related to a hardware issue where a TSTART write to the NCR register
> is missed, preventing the transmission from being kicked off.
>
> [...]
Here is the summary with links:
- [v2] net: macb: add TX stall timeout callback to recover from lost TSTART write
https://git.kernel.org/netdev/net/c/e438ec3e9e95
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [GIT PULL] pmdomain updates for v7.2
From: pr-tracker-bot @ 2026-06-19 0:09 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Linus, linux-pm, linux-kernel, Ulf Hansson, linux-arm-kernel
In-Reply-To: <20260617090546.18688-1-ulf.hansson@oss.qualcomm.com>
The pull request you sent on Wed, 17 Jun 2026 11:05:46 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git tags/pmdomain-v7.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7849ce38717e64213bf9cbb166d1cda14e05143f
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mt76: fix of_get_mac_address error handling
From: Klara Modin @ 2026-06-18 23:51 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <CAKxU2N-gfH8Tq29-j2MArogLZuO7JEqtN5LNPVygJzrAERa3cg@mail.gmail.com>
On 2026-06-18 16:01:45 -0700, Rosen Penev wrote:
> On Thu, Jun 18, 2026 at 2:47 PM Klara Modin <klarasmodin@gmail.com> wrote:
> >
> > Hi,
> >
> > On 2026-04-26 22:17:46 -0700, Rosen Penev wrote:
> > > Check return value instead of is_valid_ether_addr. The latter is handled
> > > by the former.
> > >
> > > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > > ---
> > > drivers/net/wireless/mediatek/mt76/eeprom.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
> > > index 93d91264687f..0f6ccf6ed53d 100644
> > > --- a/drivers/net/wireless/mediatek/mt76/eeprom.c
> > > +++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
> > > @@ -93,7 +93,7 @@ mt76_eeprom_override(struct mt76_phy *phy)
> > > if (err == -EPROBE_DEFER)
> > > return err;
> > >
> > > - if (!is_valid_ether_addr(phy->macaddr)) {
> > > + if (err) {
> > > eth_random_addr(phy->macaddr);
> > > dev_info(dev->dev,
> > > "Invalid MAC address, using random address %pM\n",
> > > --
> > > 2.54.0
> > >
> >
> > Recently I have started to see randomized MAC-addresses on my x86 laptop
> > with a MT7922 and the above message printed in the kernel log. I have
> > CONFIG_OF turned on, but since this is an ACPI system the device is not
> > described by any device tree and the earlier of_get_mac_address() likely
> > fails with -ENODEV. Looking at the !CONFIG_OF stub for
> > of_get_mac_address it always returns -ENODEV, meaning this will always
> > randomize the mac in that case too.
> IIRC, the normal device_get_mac_address supports nvmem now. Does that
> fix your use case?
I tried this:
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index b99d7452800f..243a8f2c7bda 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -174,10 +174,9 @@ int
mt76_eeprom_override(struct mt76_phy *phy)
{
struct mt76_dev *dev = phy->dev;
- struct device_node *np = dev->dev->of_node;
int err;
- err = of_get_mac_address(np, phy->macaddr);
+ err = device_get_mac_address(dev->dev, phy->macaddr);
if (err == -EPROBE_DEFER)
return err;
but I still get a random MAC.
> >
> > Reverting this patch fixes the issue and the correct MAC address is
> > used. I'm not sure if there is any case where of_get_mac_addres() could
> > fail in a way that results in a valid MAC address but it seems unlikely
> > to me.
> >
> > Regards,
> > Klara Modin
^ permalink raw reply related
* Re: [PATCH wireless-next] wifi: mt76: fix of_get_mac_address error handling
From: Rosen Penev @ 2026-06-18 23:01 UTC (permalink / raw)
To: Klara Modin
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <ajRmlyx_AEGybykL@soda.int.kasm.eu>
On Thu, Jun 18, 2026 at 2:47 PM Klara Modin <klarasmodin@gmail.com> wrote:
>
> Hi,
>
> On 2026-04-26 22:17:46 -0700, Rosen Penev wrote:
> > Check return value instead of is_valid_ether_addr. The latter is handled
> > by the former.
> >
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > drivers/net/wireless/mediatek/mt76/eeprom.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
> > index 93d91264687f..0f6ccf6ed53d 100644
> > --- a/drivers/net/wireless/mediatek/mt76/eeprom.c
> > +++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
> > @@ -93,7 +93,7 @@ mt76_eeprom_override(struct mt76_phy *phy)
> > if (err == -EPROBE_DEFER)
> > return err;
> >
> > - if (!is_valid_ether_addr(phy->macaddr)) {
> > + if (err) {
> > eth_random_addr(phy->macaddr);
> > dev_info(dev->dev,
> > "Invalid MAC address, using random address %pM\n",
> > --
> > 2.54.0
> >
>
> Recently I have started to see randomized MAC-addresses on my x86 laptop
> with a MT7922 and the above message printed in the kernel log. I have
> CONFIG_OF turned on, but since this is an ACPI system the device is not
> described by any device tree and the earlier of_get_mac_address() likely
> fails with -ENODEV. Looking at the !CONFIG_OF stub for
> of_get_mac_address it always returns -ENODEV, meaning this will always
> randomize the mac in that case too.
IIRC, the normal device_get_mac_address supports nvmem now. Does that
fix your use case?
>
> Reverting this patch fixes the issue and the correct MAC address is
> used. I'm not sure if there is any case where of_get_mac_addres() could
> fail in a way that results in a valid MAC address but it seems unlikely
> to me.
>
> Regards,
> Klara Modin
^ permalink raw reply
* Re: [PATCH v7 15/20] perf: arm_pmuv3: Handle IRQs for Partitioned PMU guest counters
From: Colton Lewis @ 2026-06-18 23:32 UTC (permalink / raw)
To: wuyifan
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest, wangyushan12, wangzhou1,
xuwei5, prime.zeng, fanghao11
In-Reply-To: <6dca2d6e-54d0-42c4-95df-45a30a473e0b@huawei.com>
wuyifan <wuyifan50@huawei.com> writes:
> 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.
I will fix that.
> Thanks,
> Yifan
^ permalink raw reply
* Re: [PATCH v7 11/20] KVM: arm64: Enforce PMU event filter at vcpu_load()
From: Colton Lewis @ 2026-06-18 23:30 UTC (permalink / raw)
To: wuyifan
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, james.clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest, wangyushan12, fanghao11,
wangzhou1, prime.zeng, xuwei5
In-Reply-To: <df30b9e0-6938-47f5-bb5d-5b1e67c8879c@huawei.com>
Hi Yifan, thanks for the review.
wuyifan <wuyifan50@huawei.com> writes:
> Hi Colton,
> On 5/5/2026 5:18 AM, Colton Lewis wrote:
>> + for_each_set_bit(i, &guest_counters, ARMPMU_MAX_HWEVENTS) {
>> + if (i == ARMV8_PMU_CYCLE_IDX) {
>> + val = __vcpu_sys_reg(vcpu, PMCCFILTR_EL0);
>> + evsel = ARMV8_PMUV3_PERFCTR_CPU_CYCLES;
>> + } else {
>> + val = __vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i);
>> + evsel = val & kvm_pmu_event_mask(vcpu->kvm);
>> + }
>> +
>> + guest_include_el2 = (val & ARMV8_PMU_INCLUDE_EL2);
>> + val &= ~evtyper_clr;
>> +
>> + if (unlikely(is_hyp_ctxt(vcpu)) && guest_include_el2)
>> + val &= ~ARMV8_PMU_EXCLUDE_EL1;
>> +
>> + if (vcpu->kvm->arch.pmu_filter &&
>> + !test_bit(evsel, vcpu->kvm->arch.pmu_filter))
>> + val |= evtyper_set;
>> +
>> + if (i == ARMV8_PMU_CYCLE_IDX) {
>> + write_sysreg(val, pmccntr_el0);
> This should be pmccfiltr_el0.
> Writing the filter bits to pmccntr_el0 would corrupt the cycle count
> value.
Yes it should. I found that and thought I corrected it before I sent out
the series. Thanks for catching it.
>> + } else {
>> + write_sysreg(i, pmselr_el0);
>> + write_sysreg(val, pmxevtyper_el0);
>> + }
>> + }
>> +}
> Thanks,
> Yifan
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: Cristian Marussi @ 2026-06-18 23:28 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Cristian Marussi, Christian Brauner, linux-kernel,
linux-arm-kernel, arm-scmi, linux-fsdevel, linux-doc,
sudeep.holla, james.quinlan, f.fainelli, vincent.guittot,
etienne.carriere, peng.fan, michal.simek, d-gole, jic23,
elif.topuz, lukasz.luba, philip.radford, souvik.chakravarty,
leitao, kas, puranjay, usama.arif, kernel-team
In-Reply-To: <29a304f0-1e62-418a-b84f-aabdc4c0de8d@kernel.org>
On Thu, Jun 18, 2026 at 07:22:29PM +0200, David Hildenbrand (Arm) wrote:
> Hi,
Hi David,
>
> asking some clarifying questions that I assume also Christian might want to know.
>
Thanks for having a look !
> >>> In a nutshell, the SCMI Telemetry protocol allows an agent to discover at
> >>> runtime the set of Telemetry Data Events (DEs) available on a specific
> >>> platform and provides the means to configure the set of DEs that a user is
>
> Is the configuration aspect limited to enabling selected events, or is there
> more that can be configured?
>
The needed configuration is:
- global Telemetry enable (tlm_enable)
- global common update_interval (current_update_interval)
- per-DE enable/disable (des/0x<NNNN>/enable)
- per-DE timestamping enable/disable (des/0x<NNNN>/tstamp_enable)
... then there are a couple of handy catch-all entries:
all_des_enable, all_des_tstamp_enable
Note that all the existent DEs are discovered at runtime dynamically via
SCMI in the background at init/probe and then never change: i.e.
the tree is statically created upon discovery, user cannot
create/destroy or symlink files at will, nor the backend platform FW
running the SCMI server can pop-up new DataEvents after the initial
enumeration.
All the above configs can also be pre-defined in the FW (at built time)
as being default boot-on with predefined values, like a specific
boot-on update interval, so that you could have a system in which really
you dont need to configure anything...everything is on and you just
read data. (unless you want to change config of course...)
There is more stuff that indeed is configurable per the SCMI spec
but these additional params are hidden into the SCMI Telemetry protocol
layer (the initial patches in this series) and NOT made available to
the driver/users of the protocol (like the SCMI FS driver that sits on
top)
IOW, this humonguos series (~8k lines) is only partially composed by
the Filesystem driver (~3k): the bulk of the Telemetry logic and SCMI
message exchanges are contained in the SCMI Protocol stack which has
been extended to support the Telemerty protocol at first
(the 'firmware: arm_scmi:' initial patches).
This latter common support is exposed by the SCMI stack for the SCMI
drivers to use via custom per-protocol operations (not an orginal name :P)
exposed in include/linux/scmi_protocol.h
So when you write into FS to configure smth, you end up calling an internal
tlm_proto_ops that in turn will cause an SCMI message to be sent
(in some cases say to enable a DE or set the update interval)
When you read something, you end up calling another Telemetry operation
that in turn returns you the DataEvent value you were looking for...how
this is retrieved via SCMI in the background is transparent to the
FS driver because, again, these details are buried into the protocol
layer. Talking about reads, you can:
- read a single value from des/0x<NNNN>/value
- read ALL the currently enabled DE in a bulk read via des_bulk_read
...most of the other entries in the tree are simply RO properties of the DEs
that have been discovered at enumeration time.
Given that walking a FS tree and issuing configuration as writes is NOT
performant really (nor handy if you are not a human), currently, even
in this FS-based series you can really perform all of the discovery AND
the configuration tasks WITHOUT walking the filesystem tree, but instead
issuing a bunch of IOCTLs issued on a special 'control' file that I
embedded in the FS. Such UAPI IOCTLs described at:
https://lore.kernel.org/arm-scmi/20260612223802.1337232-6-cristian.marussi@arm.com/T/#u
So my plan of action in order to get rid of the FS in-kenel implementation
would be to drop this Filesystem in favour of simple character devices
and move the existent IOCTLs interface (revisited where needed) on top of
these devices: that way you will be able to use IOCTLs to enumerate the
Telemetry sources and then configure them.
Read will then happen (probably) leveraging a number of chardev fops like:
IOCTLs, .read and .mmap...up to the tool decide what to use.
After this porting to chardev is done, I would start optionally exposing
again all of this in a human-readable alternative way by adding a layer
of FUSE on top of this chardev interface.
Basically my aim is to drop the FS implementation from the kernel, as
advised, while trying to optionally make it still available via a userspace
FUSE implementation...IOW the intention would be for the next V5 to expose
the same interfaces as V4 but with the help of a tool instead that builds,
if wanted, a FUSE mount built on top of the chardev interface.
So basically 'floating up' the current FS-like interface into userspace.
> >>> interested into, while reading them back using the collection method that
> >>> is deeemed more suitable for the usecase at hand. (...amongst the various
> >>> possible collection methods allowed by SCMI specification)
> >>>
> >>> Without delving into the gory details of the whole SCMI Telemetry protocol
> >>> let's just say that the SCMI platform/server firmware advertises a number
> >>> of Telemetry Data Events, each one identified by a 32bit unique ID, and an
> >>> SCMI agent/client, like Linux, can discover them and read back at will the
> >>> associated data value in a number of ways.
> >>> Data collection is mainly intended to happen on demand via shared memory
> >>> areas exposed by the platform firmware, discovered dynamically via SCMI
> >>> Telemetry and accessed by Linux on-demand, but some DE can also be reported
> >>> via SCMI Notifications asynchronous messages or via direct dedicated
> >>> FastChannels (another kind of SCMI memory based access): all of this
> >>> underlying mechanism is anyway hidden to the user since it is mediated by
> >>> the kernel driver which will return the proper data value when queried.
> >>>
> >>> Anyway, the set of well-known architected DE IDs defined by the spec is
> >>> limited to a dozen IDs, which means that the vast majority of DE IDs are
> >>> customizable per-platform: as a consequence, though, the same ID, say
> >>> '0x1234', could represent completely different things on different systems.
> >>>
> >>> Precise definitions and semantic of such custom Data Event IDs are out of
> >>> the scope of the SCMI Telemetry specification and of this implementation:
> >>> they are supposed to be provided using some kind of JSON-like description
> >>> file that will have to be consumed by a userspace tool which would be
> >>> finally in charge of making sense of the set of available DEs.
>
> You mention json here ... but I assume the data we are getting fed by the
> protocol is not in some default format? (e.g., json)
The data format is defined by the SCMI spec and it is buried in the SCMI
layer, there are a number of collection method and a number of formats: this
is NOT exposed from the SCMI core BUT handled transparently.
The raw spec format basically defines how DE ID, Tstamps, values are represented
in memory and how their consistency can be assured despite the fact that
platform could update the same entries that a user is concurrently reading...
JSON definitions only assign a semantic to the DEs (in theory...): e.g. on this
specific platform...wth is 0x1234 ? ..also note that JSON defs are NOT part of
the spec....they do NOT really exist for the Kernel: they are parsed and
interpreted by more complex user space tools that are supposed to leverage some
of these interfaces to retrieve data and carry-on analysis.
>
> >>>
> >>> IOW, in turn, this means that even though the DEs enumerated via SCMI come
> >>> with some sort of topological and qualitative description provided by the
> >>> protocol (like unit of measurements, name, topology info etc), kernel-wise
> >>> we CANNOT be completely sure of "what is what" without being fed-back some
> >>> sort of information about the DEs by the afore mentioned userspace tool.
>
> Maybe you have it in some of the patches here, but what does the typical
> directory + file structure look like in the current implementation?
>
> Do you have an example?
>
> Also, is everything in that filesystem read-only, or are there some writable
> file (IOW, how is stuff configured?).
See above for config/write entry ... and I think you found the FS layout in the
doc already...
>
> >>>
> >>> For these reasons, currently this series does NOT attempt to register any
> >>> of these DEs with any of the usual in-kernel subsystems (like HWMON, IIO,
> >>> PERF etc), simply because we cannot be sure which DE is suitable, or even
> >>> desirable, for a given subsystem. This also means there are NO in-kernel
> >>> users of these Telemetry data events as of now.
>
> Okay, so you really only feed this data to user space, exposing all the data you
> have easily available as part of the protocol.
Yes, no interpetation nor filtering: I expose all that have enumerated and/
discovered by the protocol, allowing for configurations while hiding the inner
SCMI Telemetry mechanism...
>
> >>>
> >>> So, while we do not exclude, for the future, to feed/register some of the
> >>> discovered DEs to/with some of the above mentioned Kernel subsystems, as
> >>> of now we have ONLY modeled a custom userspace API to make SCMI Telemetry
> >>> available to userspace tools.
>
> It's a good question how that could be done, if you need more information about
> these events from user space.
I have NOT really delved into that, so as of know we do NOT fed any data
to existing Kernel subsystems, not there is any available in-kernel
interface to consume DE data (nobody asked), but, I can imagine 2 solution:
- our beloved architects decide to 'architect' more DataEvents in the
next version of the spec.. i.e. they reserve some specific DE IDs to
represent some well defined entity (like it is done already in the spec
for a dozen IDs)...this avoids the needs of any new interface all
together
OR
- we open some sort of user-->kernel ABI channel 'somewhere' where the
userspace tool, interpreting the JSON description, can communicate something
like " on this platform ID 1,2,3,4 should be fed to the IIO sensors frmwk
too, while ID 39,8,76 can be fed to HWMON..." etc
>
> >>>
> >>> In deciding which kind of interface to expose SCMI Telemetry data to a
> >>> user, this new SCMI Telemetry driver aims at satisfying 2 main reqs:
> >>>
> >>> - exposing an FS-based human-readable interface that can be used to
> >>> discover, configure and access our Telemetry data directly also from
> >>> the shell without special tools
> >>>
> >>> - exposing alternative machine-friendly, more-performant, binary
> >>> interfaces that can be used to avoid the overhead of multiple accesses
> >>> to the VFS and that can be more suitable to access with custom tools
> [...]
>
> >>>
> >>> Due to the above reasoning, since V1 we opted for a new approach with the
> >>> proposed interfaces now based on a full fledged, unified, virtual pseudo
> >>> filesystem implemented from scratch, so that we can:
> >>>
> >>> - expose all the DEs property we like as before with SysFS, but without
> >>> any of the constraint imposed by the usage of SysFs or kernfs.
> >>>
> >>> - easily expose additional alternative views of the same set of DEs
> >>> using symlinking capabilities (e.g. alternative topological view)
>
> That sounds reasonable.
>
> [...]
>
> > ...I would not say that this was the kind of feedback I was hoping for,
> > but I am NOT gonna argue, given that you shot down already what I thought
> > were all my best selling points :P
> >
> > At this point my understanding is that the way forward must be to use
> > a custom tool to configure/extract/translate the raw Telemetry data and
> > move up into userspace the whole human readable FS layer via FUSE, if
> > really needed.
> >
> > I suppose that the new kernel/user interface has to be some dedicated char
> > device implementing proper fops. (like I did previously in early versions
> > of this series and then abandoned...)
> >
> > Is this you have in mind ? Dedicated character device(s) with enough fops
> > to be able to configure/extract Telemetry data with a custom tool ?
>
> I cannot speak for Christian, but I guess you could have some kind of libscmi in
> user space that can obtain the information (as you say, probably char device,
> not sure which alternatives we have), to expose the data through a nice ABI, to
> then either make tools build upon that directly, or have a fuse server in user
> space that mimics what you currently do with the file system.
My aim would be at first a simple tool that can exercise the chardev interface to
discover configure and read back data, and then a FUSE server on top of this to
optionally expose the human readable FS....I suppose our internal and external
customers can use the FS interface to validate/test/script on one side, OR
simply code their own tools/libs to use directly the bare chardev inteface...
...we do have a tools team already working on a library to ease all of this
SCMI Telemtry collection and analysis...it is just a matter to re-target the
kind of lower level interfaces that they are using in the near future
probably (they were already planning indeed AFAIK to use more performant
interface that FS...)
>
> One thing that is not clear to me yet is how stuff would be configured, and how
> possibly multiple users of libscmi would possibly interact.
>
Configuration/discovery will happen via IOCTls, while consuming the Data
can happen:
- all together in bulk via a device read fops
- a single DE via a targeted IOCTL
- direct access to the raw SCMI data via dev/mmap of the underlying SCMI
areas (that means the tool has to parse the SCMI format defined by the
spec on its own, without the currently provided Kernel mediation...)
Regarding the user concurrency, I have already explicitly pushed back on
this, our own tools team: any concurrent read or configuration write is
allowed and properly handled in a consistent way, BUT on the configuration
side the last write/ioctl wins: there is NO in-kernel OR userspace
co-ordination provided out of the box: IOW if you use multiple tools
concurrently to apply conflicting configurations, it is none of our problem
...similarly as if you have an actively running network configuration daemon
and you try to set your IP manually...nobody will prevent you from doing this,
the same netlink will be used freely by you on the shell and the daemon (if you
have enough privilege), but you will gonna have unexpected result...
I dont either see the case to enforce exclusive access for Telemetry resources:
co-ordination is up to the user in my view...I mean if you have 2 tools
configuring concurrently SCMI telemetry in a conflicting way something has been
misconfigured somewhere
.....having said that, I understand that the concurrency co-ordination
issue can be particularly tricky to spot and solve in userspace, so I DO
expose a generation counter entry that is updated on any configuration
change, so that a userspace app using Telemetry can monitor (poll) this
counter to spot if someone else on the system is quietly suddenly applying
configuration changes...
> >
> > Should/could such a tool live in the kernel tree (tools/) at least for
> > ease of development/deployment ?
>
> I think OOT.
>
Ok.
Sorry for the long email..I hope I have clarified the situation, anyway
I am already moving to get rid of the in-kernel interface as advised in
favour of a chardev kernel interface and an optional FUSE based FS...
Any further feedback is welcome...
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 21:54 UTC (permalink / raw)
To: Marc Zyngier
Cc: Marek Vasut, linux-pci, Yoshihiro Shimoda,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring, devicetree,
linux-arm-kernel, linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <86ldccs0oj.wl-maz@kernel.org>
On 6/18/26 10:38 AM, Marc Zyngier wrote:
Hello Marc,
>>>> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
>>>> or APB interface configured to 32 bit, it can therefore access only
>>>> the first 4 GiB of physical address space. This information comes from
>>>> R-Car V4H Interface Specification sheet, there is currently no technical
>>>> update number assigned to this limitation. Further input from hardware
>>>> engineer indicates that this limitation also applies to R-Car S4 and V4M.
>>>> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
>>>> limitation.
>>
>> My concern is this ^ , I do not have an erratum number, because there
>> isn't one. I am in touch with the hardware engineer and I did get a
>> glimpse at internal details of the three SoC, which confirm the
>> limitations. Is this sufficient ?
>
> To be honest, this is between you and the SoC vendor. I'll take
> whatever symbol you come up with at face value, and will assume that
> the vendor agrees with it. After all, they are on Cc and have their
> SoB on the patch.
All right.
>>>> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
>>>> common for many ARM GICv3 implementations. Therefore, add an extra
>>>
>>> Not quite. It designates GIC600 unambiguously.
>>
>> What I am trying to communicate is, that the 0x0201743b ID is not ID
>> of the Renesas GIC implementation, but it is a generic ARM GIC600
>> ID. That is why we cannot match the quirk on the ID (it is generic ARM
>> GIC600 ID), and instead we have to match the quirk on the [ ID
>> combined with of_machine_is_compatible("renesas,...") ].
>
> This is understood, and is no different from the other broken
> platforms in the tree.
>
>>
>>> It is just that GIC600
>>> is integrated in zillions of SoCs, most of which don't have this
>>> problem (the machine I'm typing this from has a GIC600 *and* 96GB of
>>> RAM).
>>
>> Right.
>>
>> Shall I reword this paragraph somehow to make it clearer ?
>
> I'd simply say that the workaround is keyed on the combination of the
> GIC implementation and the platform identification in the device tree.
OK
>>>> of_machine_is_compatible() check.
>>>>
>>>> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
>>>
>>> Is this relevant?
>>
>> I included it for the sake of completeness and to provide all relevant
>> information, based on previous discussions about similar limitations
>> that I could find on lore.k.o
>
> This information is already contained in the ID you quote (bits
> [19:12]), and can be decoded using the public TRM [1].
I'll drop it then.
Thanks
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 21:53 UTC (permalink / raw)
To: Marc Zyngier, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <8633yltylq.wl-maz@kernel.org>
On 6/17/26 9:28 AM, Marc Zyngier wrote:
[...]
>> +/* INTC address */
>> +#define AXIINTCADDR 0x0a00
>> +/* GITS GIC ITS translation register */
>> +#define AXIINTCADDR_VAL 0xf1050000
>
> Wouldn't it be preferable to source the address from the device tree,
> rather than hardcoding this?
It would, I will do so in V2.
^ permalink raw reply
* [PATCH v2 4/4] arm64: dts: renesas: r8a779g0: Add GICv3 ITS and update PCIe nodes
From: Marek Vasut @ 2026-06-18 22:02 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-1-marek.vasut+renesas@mailbox.org>
This SoC implements GIC600 with GICv3 ITS and PCIe host mode on this
SoC can use it. Add GIC ITS node into GIC node, update interrupt-map
and add msi-map into PCIe controller node.
The GIC ITS does have master interface to issue transactions to RAM.
The interface does support cacheable transactions, however, it does
not support shareable attribute, because the AXI port signals are tied
to inactive in this implementation. Therefore, add "dma-noncoherent"
DT property into the GIC ITS subnode.
The GIC redistributor does not have cacheable/shareable, therefore
add "dma-noncoherent" DT property into the GIC node.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
NOTE: This would not be possible without prior work from Shimoda-san
https://lore.kernel.org/all/20240214052144.1966569-1-yoshihiro.shimoda.uh@renesas.com/
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: No change
---
arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 31 ++++++++++++++++-------
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
index 3a8af825bb253..82e864acf2601 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
@@ -792,6 +792,7 @@ pciec0: pcie@e65d0000 {
resets = <&cpg 624>;
reset-names = "pwr";
max-link-speed = <4>;
+ msi-parent = <&its>;
num-lanes = <2>;
#address-cells = <3>;
#size-cells = <2>;
@@ -802,10 +803,10 @@ pciec0: pcie@e65d0000 {
dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &gic GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &gic GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &gic GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &gic GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &gic 0 0 GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &gic 0 0 GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &gic 0 0 GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>;
snps,enable-cdm-check;
status = "disabled";
@@ -839,6 +840,7 @@ pciec1: pcie@e65d8000 {
resets = <&cpg 625>;
reset-names = "pwr";
max-link-speed = <4>;
+ msi-parent = <&its>;
num-lanes = <2>;
#address-cells = <3>;
#size-cells = <2>;
@@ -849,10 +851,10 @@ pciec1: pcie@e65d8000 {
dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &gic GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &gic GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &gic GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &gic GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &gic 0 0 GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &gic 0 0 GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &gic 0 0 GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>;
snps,enable-cdm-check;
status = "disabled";
@@ -2131,11 +2133,22 @@ ipmmu_mm: iommu@eefc0000 {
gic: interrupt-controller@f1000000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
- #address-cells = <0>;
+ #address-cells = <2>;
+ #size-cells = <2>;
interrupt-controller;
reg = <0x0 0xf1000000 0 0x20000>,
<0x0 0xf1060000 0 0x110000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ dma-noncoherent;
+
+ ranges = <0x0 0x0 0x0 0xf1000000 0x0 0x200000>;
+
+ its: msi-controller@40000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x40000 0x0 0x20000>;
+ dma-noncoherent;
+ msi-controller;
+ };
};
gpu: gpu@fd000000 {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 22:02 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-1-marek.vasut+renesas@mailbox.org>
Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
or APB interface configured to 32 bit, it can therefore access only
the first 4 GiB of physical address space. This information comes from
R-Car V4H Interface Specification sheet, there is currently no technical
update number assigned to this limitation. Further input from hardware
engineer indicates that this limitation also applies to R-Car S4 and V4M.
Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
limitation.
The quirk is keyed on the combination of the GIC implementation
and the platform identification in the device tree.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
NOTE: This would not be possible without prior work from Shimoda-san
https://lore.kernel.org/all/20240214052050.1966439-1-yoshihiro.shimoda.uh@renesas.com/
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Minimize the patch based on newly added patch in the series and
only add entries into dma_32bit_impaired_platforms array. Update
second paragraph of commit message slightly.
---
Documentation/arch/arm64/silicon-errata.rst | 1 +
arch/arm64/Kconfig | 9 +++++++++
drivers/irqchip/irq-gic-v3-its.c | 5 +++++
3 files changed, 15 insertions(+)
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 014aa1c215a16..b0c68b64f5ac2 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -352,6 +352,7 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
+----------------+-----------------+-----------------+-----------------------------+
+| Renesas | S4/V4H/V4M | N/A | RENESAS_ERRATUM_GEN4GICITS1 |
+----------------+-----------------+-----------------+-----------------------------+
| Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
+----------------+-----------------+-----------------+-----------------------------+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b3afe0688919b..b9e17ce475e61 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1382,6 +1382,15 @@ config NVIDIA_CARMEL_CNP_ERRATUM
If unsure, say Y.
+config RENESAS_ERRATUM_GEN4GICITS1
+ bool "Renesas R-Car Gen4: GIC600 can not access physical addresses above 4 GiB"
+ default y
+ help
+ The Renesas R-Car Gen4 S4/V4H/V4M GIC600 SoC integrations have AXI
+ addressing limited to the first 32-bit of physical address space.
+
+ If unsure, say Y.
+
config ROCKCHIP_ERRATUM_3568002
bool "Rockchip 3568002: GIC600 can not access physical addresses higher than 4GB"
default y
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 8ec2175b78288..96b26822e5bd2 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4891,6 +4891,11 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
}
static const char * const dma_32bit_impaired_platforms[] = {
+#ifdef CONFIG_RENESAS_ERRATUM_GEN4GICITS1
+ "renesas,r8a779f0",
+ "renesas,r8a779g0",
+ "renesas,r8a779h0",
+#endif
#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
"rockchip,rk3566",
"rockchip,rk3568",
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/4] PCI: rcar-gen4: irqchip/gic-v3: Handle GIC ITS
From: Marek Vasut @ 2026-06-18 22:01 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, Yoshihiro Shimoda, devicetree,
linux-arm-kernel, linux-doc, linux-kernel, linux-renesas-soc
Configure all R-Car Gen4 PCIe controller MSI registers fully, both in
case MSI are enabled and disabled.
Patch GIC ITS driver and add quirks for R-Car Gen4 GIC ITS, which is
configured to 32-bit address width for AXI or APB interface.
Switch R-Car V4H to use GIC ITS in its DT and describe the GIC ITS
implementation cacheable and shareable limitations.
Marek Vasut (4):
PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
arm64: dts: renesas: r8a779g0: Add GICv3 ITS and update PCIe nodes
Documentation/arch/arm64/silicon-errata.rst | 1 +
arch/arm64/Kconfig | 9 ++
arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 31 +++--
drivers/irqchip/irq-gic-v3-its.c | 24 ++--
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 118 +++++++++++++++++++-
5 files changed, 162 insertions(+), 21 deletions(-)
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
--
2.53.0
^ permalink raw reply
* [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Marek Vasut @ 2026-06-18 22:02 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Marc Zyngier, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-1-marek.vasut+renesas@mailbox.org>
The GIC600 implementation is now known to be used on multiple 64-bit
SoCs, where it has address width for AXI or APB interface configured
to 32 bit, and it can access only the first 4GiB of physical address
space.
Rework the handling of the quirk to work around this limitation such
that new entries can be added purely as new compatible strings, with
no need to add additional functions or new its_quirk array entries.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
V2: New patch
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/irqchip/irq-gic-v3-its.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index b57d81ad33a0a..8ec2175b78288 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4890,10 +4890,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
return true;
}
-static bool __maybe_unused its_enable_rk3568002(void *data)
+static const char * const dma_32bit_impaired_platforms[] = {
+#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
+ "rockchip,rk3566",
+ "rockchip,rk3568",
+#endif
+ NULL,
+};
+
+static bool __maybe_unused its_enable_dma32(void *data)
{
- if (!of_machine_is_compatible("rockchip,rk3566") &&
- !of_machine_is_compatible("rockchip,rk3568"))
+ if (!of_machine_compatible_match(dma_32bit_impaired_platforms))
return false;
gfp_flags_quirk |= GFP_DMA32;
@@ -4968,14 +4975,12 @@ static const struct gic_quirk its_quirks[] = {
.property = "dma-noncoherent",
.init = its_set_non_coherent,
},
-#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
{
- .desc = "ITS: Rockchip erratum RK3568002",
+ .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
.iidr = 0x0201743b,
.mask = 0xffffffff,
- .init = its_enable_rk3568002,
+ .init = its_enable_dma32,
},
-#endif
{
}
};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/4] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 22:01 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-1-marek.vasut+renesas@mailbox.org>
In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
MSI are handled via GIC ITS. Configure all controller MSI registers
fully.
Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
enable MSI_CTRL_INT bit according to MSI enable state, set both bits
if MSI are enabled, clear both bits if MSI are disabled.
If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
pass through of MSI TLPs onto the AXI bus and then further into
GIC ITS translation registers.
If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
with target address of GIC ITS translation registers, and configure
AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
GIC ITS. This specific configuration allows handling of MSI via the
GIC ITS instead of integrated iMSI-RX.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
NOTE: This would not be possible without prior work from Shimoda-san
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Pull GITS_TRANSLATER address from DT, which also fixes missing +0x40
offset of the GITS_TRANSLATER register
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 118 +++++++++++++++++++-
1 file changed, 113 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 8b03c42f8c84c..6300ab4dc38b3 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -13,8 +13,11 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/iopoll.h>
+#include <linux/irqchip/arm-gic-v3.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <linux/pci.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
@@ -31,6 +34,10 @@
#define DEVICE_TYPE_RC BIT(4)
#define BIFUR_MOD_SET_ON BIT(0)
+/* MSI Capability */
+#define MSICAP0 0x0050
+#define MSICAP0_MSIE BIT(16)
+
/* PCIe Interrupt Status 0 */
#define PCIEINTSTS0 0x0084
@@ -55,6 +62,14 @@
#define APP_HOLD_PHY_RST BIT(16)
#define APP_LTSSM_ENABLE BIT(0)
+/* INTC address */
+#define AXIINTCADDR 0x0a00
+
+/* INTC control & mask */
+#define AXIINTCCONT 0x0a04
+#define INTC_EN BIT(31)
+#define INTC_MASK GENMASK(11, 2)
+
/* PCIe Power Management Control */
#define PCIEPWRMNGCTRL 0x0070
#define APP_CLK_REQ_N BIT(11)
@@ -305,13 +320,103 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
return rcar;
}
+static int rcar_gen4_pcie_host_msi_addr(struct dw_pcie_rp *pp, u32 *msi_addr)
+{
+ struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
+ struct device_node *msi_node = NULL;
+ struct device *dev = dw->dev;
+ struct resource res;
+ u64 addr;
+ int ret;
+
+ /*
+ * Either the "msi-parent" or the "msi-map" phandle needs to exist
+ * to obtain the MSI node.
+ */
+ of_msi_xlate(dev, &msi_node, 0);
+ if (!msi_node)
+ return -ENODEV;
+
+ /* Check if "msi-parent" or the "msi-map" points to ARM GICv3 ITS. */
+ if (!of_device_is_compatible(msi_node, "arm,gic-v3-its"))
+ return dev_err_probe(dev, -ENODEV, "Compatible MSI controller not found\n");
+
+ /* Derive GITS_TRANSLATER address from GICv3 */
+ ret = of_address_to_resource(msi_node, 0, &res);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "MSI controller resources not obtained\n");
+
+ addr = res.start + GITS_TRANSLATER;
+ if (addr >= SZ_4G)
+ return dev_err_probe(dev, -EINVAL, "MSI controller address above 32bit range\n");
+
+ *msi_addr = addr;
+ return 0;
+}
+
+static int rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
+{
+ struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+ u32 val;
+ int ret;
+
+ /* Make sure MSICAP0 MSIE is configured. */
+ val = dw_pcie_readl_dbi(dw, MSICAP0);
+ if (pci_msi_enabled())
+ val |= MSICAP0_MSIE;
+ else
+ val &= ~MSICAP0_MSIE;
+ dw_pcie_writel_dbi(dw, MSICAP0, val);
+
+ if (!pci_msi_enabled() || pp->use_imsi_rx) {
+ /* Clear AXIINTC mapping. */
+ writel(0, rcar->base + AXIINTCADDR);
+ writel(0, rcar->base + AXIINTCCONT);
+ } else {
+ ret = rcar_gen4_pcie_host_msi_addr(pp, &val);
+ if (ret)
+ goto err;
+
+ /* Point AXIINTC to GIC ITS and enable. */
+ writel(val, rcar->base + AXIINTCADDR);
+ writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
+ }
+
+ /* Configure MSI interrupt signal */
+ val = readl(rcar->base + PCIEINTSTS0EN);
+ if (pci_msi_enabled())
+ val |= MSI_CTRL_INT;
+ else
+ val &= ~MSI_CTRL_INT;
+ writel(val, rcar->base + PCIEINTSTS0EN);
+
+ return 0;
+
+err:
+ /* Deconfigure MSICAP0 MSIE. */
+ val = dw_pcie_readl_dbi(dw, MSICAP0);
+ val &= ~MSICAP0_MSIE;
+ dw_pcie_writel_dbi(dw, MSICAP0, val);
+
+ /* Clear AXIINTC mapping. */
+ writel(0, rcar->base + AXIINTCADDR);
+ writel(0, rcar->base + AXIINTCCONT);
+
+ /* Deconfigure MSI interrupt signal */
+ val = readl(rcar->base + PCIEINTSTS0EN);
+ val &= ~MSI_CTRL_INT;
+ writel(val, rcar->base + PCIEINTSTS0EN);
+
+ return ret;
+}
+
/* Host mode */
static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
{
struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
int ret;
- u32 val;
gpiod_set_value_cansleep(dw->pe_rst, 1);
@@ -328,16 +433,19 @@ static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_0, 0x0);
dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_1, 0x0);
- /* Enable MSI interrupt signal */
- val = readl(rcar->base + PCIEINTSTS0EN);
- val |= MSI_CTRL_INT;
- writel(val, rcar->base + PCIEINTSTS0EN);
+ ret = rcar_gen4_pcie_host_msi_init(pp);
+ if (ret)
+ goto err;
msleep(PCIE_T_PVPERL_MS); /* pe_rst requires 100msec delay */
gpiod_set_value_cansleep(dw->pe_rst, 0);
return 0;
+
+err:
+ rcar_gen4_pcie_common_deinit(rcar);
+ return ret;
}
static void rcar_gen4_pcie_host_deinit(struct dw_pcie_rp *pp)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH wireless-next] wifi: mt76: fix of_get_mac_address error handling
From: Klara Modin @ 2026-06-18 21:47 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20260427051746.954704-1-rosenp@gmail.com>
Hi,
On 2026-04-26 22:17:46 -0700, Rosen Penev wrote:
> Check return value instead of is_valid_ether_addr. The latter is handled
> by the former.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/net/wireless/mediatek/mt76/eeprom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
> index 93d91264687f..0f6ccf6ed53d 100644
> --- a/drivers/net/wireless/mediatek/mt76/eeprom.c
> +++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
> @@ -93,7 +93,7 @@ mt76_eeprom_override(struct mt76_phy *phy)
> if (err == -EPROBE_DEFER)
> return err;
>
> - if (!is_valid_ether_addr(phy->macaddr)) {
> + if (err) {
> eth_random_addr(phy->macaddr);
> dev_info(dev->dev,
> "Invalid MAC address, using random address %pM\n",
> --
> 2.54.0
>
Recently I have started to see randomized MAC-addresses on my x86 laptop
with a MT7922 and the above message printed in the kernel log. I have
CONFIG_OF turned on, but since this is an ACPI system the device is not
described by any device tree and the earlier of_get_mac_address() likely
fails with -ENODEV. Looking at the !CONFIG_OF stub for
of_get_mac_address it always returns -ENODEV, meaning this will always
randomize the mac in that case too.
Reverting this patch fixes the issue and the correct MAC address is
used. I'm not sure if there is any case where of_get_mac_addres() could
fail in a way that results in a valid MAC address but it seems unlikely
to me.
Regards,
Klara Modin
^ permalink raw reply
* Re: [PATCH v7 09/20] KVM: selftests: Add VFIO device support to eventfd IRQ test
From: Sean Christopherson @ 2026-06-18 21:42 UTC (permalink / raw)
To: David Matlack
Cc: Paolo Bonzini, Marc Zyngier, Oliver Upton, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, kvm,
linux-arm-kernel, kvmarm, linux-kernel, Josh Hilke
In-Reply-To: <ajRTZNum3u7oVdRa@google.com>
On Thu, Jun 18, 2026, David Matlack wrote:
> On 2026-06-12 05:20 PM, Sean Christopherson wrote:
> > From: David Matlack <dmatlack@google.com>
> >
> > Extend the eventfd IRQ test with a '-d' argument that takes a BDF (in the
> > format segment:bus:device.function) of an interrupt-capable PCI(e) device
> > bound to VFIO, and use said device to trigger interrupts instead of always
> > synthesizing interrupts via direct writes to the eventfd.
> >
> > Using a VFIO device to trigger interrupts validates the end-to-end delivery
> > of IRQs for "real" devices, and when supported by hardware (and KVM), also
> > validates interrupt delivery via IRQ bypass, i.e. via device posted IRQs.
> >
> > Now that IOMMUFD is a thing, auto-probe IOMMUFD vs. "legacy" VFIO by
> > temporarily opening /dev/iommufd, and skip the test if neither IOMMUFD nor
> > legacy VFIO is available. Add a '-t' option to the user override the probe
> > logic, e.g. in case IOMMUFD is available but the system is configured for
> > legacy usage.
> >
> > Note, the device must have a VFIO selftest driver in order to work with
> > the test. A helper script to list supported devices will hopefully be
> > available in the near future at
> > tools/testing/selftests/vfio/scripts/list_supported_devices.sh[1].
>
> > +static int vfio_setup_msi(struct vfio_pci_device *device)
> > +{
> > + const int flags = MAP_SHARED | MAP_ANONYMOUS;
> > + const int prot = PROT_READ | PROT_WRITE;
> > + struct dma_region *region;
> > +
> > + /* A driver is required to generate an MSI. */
> > + TEST_REQUIRE(device->driver.ops);
>
> This series is probably going to race with merging another VFIO
> selftests patch to make send_msi() optional [1]. Can you add a check for
> that here?
>
> TEST_REQUIRE(device->driver.ops);
> TEST_REQUIRE(device->driver.ops->send_msi);
Ya, will do.
^ permalink raw reply
* Re: [PATCH] drm/mediatek: mtk_dsi: enable hs clock during pre-enable
From: Adam Thiede @ 2026-06-18 21:06 UTC (permalink / raw)
To: Gary Bisson, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Matthias Brugger, AngeloGioacchino Del Regno
Cc: dri-devel, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260120-mtkdsi-v1-1-b0f4094f3ac3@gmail.com>
On 1/20/26 05:36, Gary Bisson wrote:
> Some bridges, such as the TI SN65DSI83, require the HS clock to be
> running in order to lock its PLL during its own pre-enable function.
>
> Without this change, the bridge gives the following error:
> sn65dsi83 14-002c: failed to lock PLL, ret=-110
> sn65dsi83 14-002c: Unexpected link status 0x01
> sn65dsi83 14-002c: reset the pipe
>
> Move the necessary functions from enable to pre-enable.
>
> Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
> ---
> Tested on Tungsten510 module with sn65dsi83 + tm070jdhg30 panel.
>
> Left mtk_dsi_set_mode() as part of the enable function to mimic what is
> done in the Samsung DSIM driver which is known to be working the TI
> bridge.
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 35 +++++++++++++++++------------------
> 1 file changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0e2bcd5f67b7..b560245d1be9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -672,6 +672,21 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> }
> }
>
> +static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
> +{
> + if (!dsi->lanes_ready) {
> + dsi->lanes_ready = true;
> + mtk_dsi_rxtx_control(dsi);
> + usleep_range(30, 100);
> + mtk_dsi_reset_dphy(dsi);
> + mtk_dsi_clk_ulp_mode_leave(dsi);
> + mtk_dsi_lane0_ulp_mode_leave(dsi);
> + mtk_dsi_clk_hs_mode(dsi, 0);
> + usleep_range(1000, 3000);
> + /* The reaction time after pulling up the mipi signal for dsi_rx */
> + }
> +}
> +
> static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> {
> struct device *dev = dsi->host.dev;
> @@ -724,6 +739,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> mtk_dsi_set_vm_cmd(dsi);
> mtk_dsi_config_vdo_timing(dsi);
> mtk_dsi_set_interrupt_enable(dsi);
> + mtk_dsi_lane_ready(dsi);
> + mtk_dsi_clk_hs_mode(dsi, 1);
>
> return 0;
> err_disable_engine_clk:
> @@ -769,30 +786,12 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> dsi->lanes_ready = false;
> }
>
> -static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
> -{
> - if (!dsi->lanes_ready) {
> - dsi->lanes_ready = true;
> - mtk_dsi_rxtx_control(dsi);
> - usleep_range(30, 100);
> - mtk_dsi_reset_dphy(dsi);
> - mtk_dsi_clk_ulp_mode_leave(dsi);
> - mtk_dsi_lane0_ulp_mode_leave(dsi);
> - mtk_dsi_clk_hs_mode(dsi, 0);
> - usleep_range(1000, 3000);
> - /* The reaction time after pulling up the mipi signal for dsi_rx */
> - }
> -}
> -
> static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> {
> if (dsi->enabled)
> return;
>
> - mtk_dsi_lane_ready(dsi);
> mtk_dsi_set_mode(dsi);
> - mtk_dsi_clk_hs_mode(dsi, 1);
> -
> mtk_dsi_start(dsi);
>
> dsi->enabled = true;
>
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20260120-mtkdsi-29e4c84e7b38
>
> Best regards,
Hello,
This commit was part of 7.1 and caused a problem for me.
I'm running postmarketOS (basically Alpine Linux) on a Lenovo C330
chromebook with a Mediatek MT8173 processor.
The problem: when the display on my laptop powers off (via suspend or
idle, like xset dpms off) the picture does not come back when the
display powers back on (from resume). The display backlight comes on and
brightness is adjustable but there is no picture. The only fix is to reboot.
Reverting this commit and applying it as a patch on top of 7.1 addresses
the issue for me.
You can view the config I'm using here:
https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8819
Is there any sort of testing or other debugging info I can provide to
help address this issue?
Thanks,
- Adam Thiede
^ permalink raw reply
* [PATCH v6 0/2] add mcf54415 DAC driver
From: Angelo Dureghello @ 2026-06-18 21:04 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Geert Uytterhoeven, Maxime Coquelin, Alexandre Torgue
Cc: linux-kernel, linux-iio, linux-m68k, linux-stm32,
linux-arm-kernel, Angelo Dureghello
This patchset adds a minimalistic DAC driver for the NXP mcf54415/6/7/8
builtin DACs.
Currently the driver enables the raw write only. Feature as dma, sync, or
format are not supoprted for this version.
Additional options suppoerted by the DAC module will be added to the driver
later on, as needed.
The same patchset prepares the m68k/coldfire architecture to support
the driver.
Below some basic tests done on stmark2 mcf54415-based board, voltage check
on DAC0 and DAC1:
~ # cd /sys/bus/iio/devices/iio:device0/
/sys/bus/iio/devices/iio:device0 # ls
name out_voltage_scale uevent
out_voltage_raw subsystem
/sys/bus/iio/devices/iio:device0 # cat name
mcf54415
/sys/bus/iio/devices/iio:device0 # echo 4095 > out_voltage_raw
/sys/bus/iio/devices/iio:device0 # echo 2048 > out_voltage_raw
/sys/bus/iio/devices/iio:device0 # echo 4096 > out_voltage_raw
sh: write error: Invalid argument
/sys/bus/iio/devices/iio:device0 # cat out_voltage_raw
2048
/sys/bus/iio/devices/iio:device0 #
Same behavior for /sys/bus/iio/devices/iio:device1.
Generated a sine wave by shell script, sine shape is good.
is actually in progress:
Note: this patchset depends on mew mcf_read/mcf_write implementation that
Link: https://lore.kernel.org/linux-m68k/209d0653-6386-4b64-9e15-e358f84453ab@app.fastmail.com/T/#t
Link: https://lore.kernel.org/linux-m68k/20260506142644.3234270-2-gerg@kernel.org/
---
Changes in v6:
- Removed patches 1 to 8, already pushed in m68knommu for-next by
Greg Ungerer <gerg@linux-m68k.org>
- keeping changelog in each single patch, where any
- Link to v5: https://patch.msgid.link/20260610-wip-stmark2-dac-v5-0-b76b83366d5c@baylibre.com
Changes in v5:
- keeping changelog in each single patch, where any
- Link to v4: https://patch.msgid.link/20260531-wip-stmark2-dac-v4-0-7e65ab4215dd@baylibre.com
Changes in v4:
- keeping changelog in each single patch, where any
- Link to v3: https://patch.msgid.link/20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com
Changes in v3:
- keeping changelog in each single patch, where any
- Link to v2: https://patch.msgid.link/20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com
Changes in v2:
- keeping changelog in each single patch, where any
- Link to v1: https://patch.msgid.link/20260504-wip-stmark2-dac-v1-0-874c36a4910d@baylibre.com
To: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
To: Nuno Sá <nuno.sa@analog.com>
To: Andy Shevchenko <andy@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
To: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
Angelo Dureghello (2):
iio: dac: add mcf54415 DAC
m68k: defconfig: update stmark2 defconfig
arch/m68k/configs/stmark2_defconfig | 2 +
drivers/iio/dac/Kconfig | 11 +++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/mcf54415_dac.c | 183 ++++++++++++++++++++++++++++++++++++
4 files changed, 197 insertions(+)
---
base-commit: d43c76b1fd85cf6f9a53145ed397d10e76f99213
change-id: 20260430-wip-stmark2-dac-7060f49dd94f
Best regards,
--
Angelo Dureghello <adureghello@baylibre.com>
^ permalink raw reply
* [PATCH v6 2/2] m68k: defconfig: update stmark2 defconfig
From: Angelo Dureghello @ 2026-06-18 21:04 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Geert Uytterhoeven, Maxime Coquelin, Alexandre Torgue
Cc: linux-kernel, linux-iio, linux-m68k, linux-stm32,
linux-arm-kernel, Angelo Dureghello
In-Reply-To: <20260618-wip-stmark2-dac-v6-0-48761dbb96d7@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Update stmark2 defconfig enabling MCF5441X DACs.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes for v5:
- move this patch after new Kconfig symbols are added
---
arch/m68k/configs/stmark2_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/m68k/configs/stmark2_defconfig b/arch/m68k/configs/stmark2_defconfig
index b3fb95f73a95..3941113bc60b 100644
--- a/arch/m68k/configs/stmark2_defconfig
+++ b/arch/m68k/configs/stmark2_defconfig
@@ -76,6 +76,8 @@ CONFIG_DMADEVICES=y
CONFIG_MCF_EDMA=y
# CONFIG_VIRTIO_MENU is not set
# CONFIG_VHOST_MENU is not set
+CONFIG_IIO=y
+CONFIG_MCF54415_DAC=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
--
2.54.0
^ permalink raw reply related
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