* Re: [PATCH v6 1/5] mm: rmap: support batched checks of the references for large folios
From: Baolin Wang @ 2026-03-26 1:47 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), David Hildenbrand (Arm)
Cc: Barry Song, akpm, catalin.marinas, will, lorenzo.stoakes,
ryan.roberts, Liam.Howlett, vbabka, rppt, surenb, mhocko, riel,
harry.yoo, jannh, willy, dev.jain, linux-mm, linux-arm-kernel,
linux-kernel
In-Reply-To: <e227a7f7-0186-4d10-b7b4-c84ca8424bdd@lucifer.local>
On 3/25/26 11:06 PM, Lorenzo Stoakes (Oracle) wrote:
> On Wed, Mar 25, 2026 at 03:58:36PM +0100, David Hildenbrand (Arm) wrote:
>> On 3/25/26 15:36, Lorenzo Stoakes (Oracle) wrote:
>>> On Mon, Mar 16, 2026 at 03:15:18PM +0100, David Hildenbrand (Arm) wrote:
>>>> On 3/16/26 07:25, Baolin Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>> Sure. However, after investigating RISC‑V and x86, I found that
>>>>> ptep_clear_flush_young() does not flush the TLB on these architectures:
>>>>>
>>>>> int ptep_clear_flush_young(struct vm_area_struct *vma,
>>>>> unsigned long address, pte_t *ptep)
>>>>> {
>>>>> /*
>>>>> * On x86 CPUs, clearing the accessed bit without a TLB flush
>>>>> * doesn't cause data corruption. [ It could cause incorrect
>>>>> * page aging and the (mistaken) reclaim of hot pages, but the
>>>>> * chance of that should be relatively low. ]
>>>>> *
>>>>> * So as a performance optimization don't flush the TLB when
>>>>> * clearing the accessed bit, it will eventually be flushed by
>>>>> * a context switch or a VM operation anyway. [ In the rare
>>>>> * event of it not getting flushed for a long time the delay
>>>>> * shouldn't really matter because there's no real memory
>>>>> * pressure for swapout to react to. ]
>>>>> */
>>>>> return ptep_test_and_clear_young(vma, address, ptep);
>>>>> }
>>>>
>>>> You'd probably want an arch helper then, that tells you whether
>>>> a flush_tlb_range() after ptep_test_and_clear_young() is required.
>>>>
>>>> Or some special flush_tlb_range() helper.
>>>>
>>>> I agree that it requires more work.
(Sorry, David. I forgot to reply to your email because I've had a lot to
sort out recently.)
Rather than adding more arch helpers (we already have plenty for the
young flag check), I think we should try removing the TLB flush, as I
mentioned to Barry[1]. MGLRU reclaim already skips the TLB flush, and it
seems to work fine. What do you think?
Here are our previous attempts to remove the TLB flush:
My patch: https://lkml.org/lkml/2023/10/24/533
Barry's patch:
https://lore.kernel.org/lkml/20220617070555.344368-1-21cnbao@gmail.com/
[1]
https://lore.kernel.org/all/6bdc4b03-9631-4717-a3fa-2785a7930aba@linux.alibaba.com/
>>> Sorry unclear here - does the series need more work or does a follow up patch
>>> need more work?
>>
>> Follow up!
>
> Ok good as in mm-stable now. Sadly means I don't get to review it but there we
> go.
Actually this patchset has already been merged upstream:)
^ permalink raw reply
* Testing remoteproc on imx8mp-evk
From: Fabio Estevam @ 2026-03-26 1:48 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: NXP Linux Team,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
Hi Peng,
I'm trying to use remoteproc on an imx8mp-evk board running mainline
U-Boot and the mainline kernel.
Could you please share a simple Cortex-M7 .elf file I can use for
testing? Even a simple Hello World will suffice.
It would be helpful if we add an imx8mp-evk devicetree overlay that
includes the described remoteproc nodes.
Could you please share the remoteproc devicetree?
Thanks,
Fabio Estevam
^ permalink raw reply
* Re: [PATCH v5 00/12] scsi: ufs: Add TX Equalization support for UFS 5.0
From: Peter Wang (王信友) @ 2026-03-26 1:52 UTC (permalink / raw)
To: beanhuo@micron.com, mani@kernel.org, can.guo@oss.qualcomm.com,
avri.altman@wdc.com, bvanassche@acm.org,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
AngeloGioacchino Del Regno, matthias.bgg@gmail.com,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org
In-Reply-To: <20260325152154.1604082-1-can.guo@oss.qualcomm.com>
On Wed, 2026-03-25 at 08:21 -0700, Can Guo wrote:
> Hi,
>
> The UFS v5.0 and UFSHCI v5.0 standards have published, introducing
> support
> for HS-G6 (46.6 Gbps per lane) through the new UniPro V3.0
> interconnect
> layer and M-PHY V6.0 physical layer specifications. To achieve
> reliable
> operation at these higher speeds, UniPro V3.0 introduces TX
> Equalization
> and Pre-Coding mechanisms that are essential for signal integrity.
>
> This patch series implements TX Equalization support in the UFS core
> driver as specified in UFSHCI v5.0, along with the necessary vendor
> operations and a reference implementation for Qualcomm UFS host
> controllers.
>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
^ permalink raw reply
* Re: [PATCH] media: nxp: imx8-isi: remove kzalloc_objs
From: Rosen Penev @ 2026-03-26 1:53 UTC (permalink / raw)
To: Kees Cook
Cc: Laurent Pinchart, linux-media, linux-hardening, gustavoars,
Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <202603201114.9A02FDA977@keescook>
On Fri, Mar 20, 2026 at 11:15 AM Kees Cook <kees@kernel.org> wrote:
>
> On Thu, Mar 19, 2026 at 05:11:22PM -0700, Rosen Penev wrote:
> > Technically kzalloc_flex is simpler but I assume a devm version of
> > that will be handled in another treewide commit.
>
> Yup, that's coming. I wanted to get the "first pass" of the base kmalloc
> family converted first. There are a few classes of "kmalloc wrappers"
> like devm_* that I'm hoping to convert to type-based allocations. devm
> is next. :)
As an aside, I recently noticed a pattern of kzalloc + kmemdup_array.
As kzalloc_flex is basically, kzalloc + kcalloc, Would a kmemdup_flex
make sense?
>
> --
> Kees Cook
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: mm: Handle invalid large leaf mappings correctly
From: Jinjiang Tu @ 2026-03-26 1:54 UTC (permalink / raw)
To: Ryan Roberts, Catalin Marinas, Will Deacon,
David Hildenbrand (Arm), Dev Jain, Yang Shi, Suzuki K Poulose,
Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, stable
In-Reply-To: <c6aef714-6736-42c8-8866-eb4da7ab85a1@arm.com>
在 2026/3/26 1:31, Ryan Roberts 写道:
> On 24/03/2026 02:30, Jinjiang Tu wrote:
>> 在 2026/3/23 21:03, Ryan Roberts 写道:
>>> It has been possible for a long time to mark ptes in the linear map as
>>> invalid. This is done for secretmem, kfence, realm dma memory un/share,
>>> and others, by simply clearing the PTE_VALID bit. But until commit
>>> a166563e7ec37 ("arm64: mm: support large block mapping when
>>> rodata=full") large leaf mappings were never made invalid in this way.
>>>
>>> It turns out various parts of the code base are not equipped to handle
>>> invalid large leaf mappings (in the way they are currently encoded) and
>>> I've observed a kernel panic while booting a realm guest on a
>>> BBML2_NOABORT system as a result:
>>>
>>> [ 15.432706] software IO TLB: Memory encryption is active and system is
>>> using DMA bounce buffers
>>> [ 15.476896] Unable to handle kernel paging request at virtual address
>>> ffff000019600000
>>> [ 15.513762] Mem abort info:
>>> [ 15.527245] ESR = 0x0000000096000046
>>> [ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits
>>> [ 15.572146] SET = 0, FnV = 0
>>> [ 15.592141] EA = 0, S1PTW = 0
>>> [ 15.612694] FSC = 0x06: level 2 translation fault
>>> [ 15.640644] Data abort info:
>>> [ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
>>> [ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
>>> [ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
>>> [ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000
>>> [ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403,
>>> pud=180000009fffe403, pmd=00e8000199600704
>>> [ 15.855046] Internal error: Oops: 0000000096000046 [#1] SMP
>>> [ 15.886394] Modules linked in:
>>> [ 15.900029] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc4-
>>> dirty #4 PREEMPT
>>> [ 15.935258] Hardware name: linux,dummy-virt (DT)
>>> [ 15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
>>> [ 15.986009] pc : __pi_memcpy_generic+0x128/0x22c
>>> [ 16.006163] lr : swiotlb_bounce+0xf4/0x158
>>> [ 16.024145] sp : ffff80008000b8f0
>>> [ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000
>>> [ 16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000
>>> [ 16.100876] x23: 0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0
>>> [ 16.131946] x20: 0000000084570010 x19: 0000000000000000 x18: ffff00001ffe3fcc
>>> [ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15: 646e612065766974
>>> [ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
>>> [ 16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018
>>> [ 16.256113] x8 : 0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000
>>> [ 16.287203] x5 : ffff000019607ff0 x4 : ffff000004578000 x3 : ffff000019600000
>>> [ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 : ffff000019600000
>>> [ 16.349071] Call trace:
>>> [ 16.360143] __pi_memcpy_generic+0x128/0x22c (P)
>>> [ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4
>>> [ 16.400282] swiotlb_map+0x5c/0x228
>>> [ 16.415984] dma_map_phys+0x244/0x2b8
>>> [ 16.432199] dma_map_page_attrs+0x44/0x58
>>> [ 16.449782] virtqueue_map_page_attrs+0x38/0x44
>>> [ 16.469596] virtqueue_map_single_attrs+0xc0/0x130
>>> [ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc
>>> [ 16.510355] try_fill_recv+0x2a4/0x584
>>> [ 16.526989] virtnet_open+0xd4/0x238
>>> [ 16.542775] __dev_open+0x110/0x24c
>>> [ 16.558280] __dev_change_flags+0x194/0x20c
>>> [ 16.576879] netif_change_flags+0x24/0x6c
>>> [ 16.594489] dev_change_flags+0x48/0x7c
>>> [ 16.611462] ip_auto_config+0x258/0x1114
>>> [ 16.628727] do_one_initcall+0x80/0x1c8
>>> [ 16.645590] kernel_init_freeable+0x208/0x2f0
>>> [ 16.664917] kernel_init+0x24/0x1e0
>>> [ 16.680295] ret_from_fork+0x10/0x20
>>> [ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c)
>>> [ 16.723106] ---[ end trace 0000000000000000 ]---
>>> [ 16.752866] Kernel panic - not syncing: Attempted to kill init!
>>> exitcode=0x0000000b
>>> [ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff800080000000
>>> [ 16.818966] PHYS_OFFSET: 0xfff1000080000000
>>> [ 16.837237] CPU features: 0x0000000,00060005,13e38581,957e772f
>>> [ 16.862904] Memory Limit: none
>>> [ 16.876526] ---[ end Kernel panic - not syncing: Attempted to kill init!
>>> exitcode=0x0000000b ]---
>>>
>>> This panic occurs because the swiotlb memory was previously shared to
>>> the host (__set_memory_enc_dec()), which involves transitioning the
>>> (large) leaf mappings to invalid, sharing to the host, then marking the
>>> mappings valid again. But pageattr_p[mu]d_entry() would only update the
>>> entry if it is a section mapping, since otherwise it concluded it must
>>> be a table entry so shouldn't be modified. But p[mu]d_sect() only
>>> returns true if the entry is valid. So the result was that the large
>> Maybe I missed something, pmd_sect() only checks PMD_TYPE_SECT, doesn't check
>> PTE_VALID?
>> Why it only returns true if the entry is valid?
> PTE_VALID is bit 0.
>
> #define PMD_TYPE_MASK (_AT(pmdval_t, 3) << 0)
> #define PMD_TYPE_TABLE (_AT(pmdval_t, 3) << 0)
> #define PMD_TYPE_SECT (_AT(pmdval_t, 1) << 0)
>
> So PMD_TYPE_TABLE and PMD_TYPE_SECT are both implicitly checking that PTE_VALID
> is set.
Understood, thanks.
>> #define pmd_sect(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
>> PMD_TYPE_SECT)
>>
> Thanks,
> Ryan
>
>
^ permalink raw reply
* RE: [PATCH v27 3/4] i2c: ast2600: Add controller driver for AST2600 new register set
From: Ryan Chen @ 2026-03-26 2:04 UTC (permalink / raw)
To: Jeremy Kerr, andriy.shevchenko@linux.intel.com, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Benjamin Herrenschmidt, Philipp Zabel
Cc: linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <28eee6d05ed1e1814f09ec907d56798a279f226d.camel@codeconstruct.com.au>
> Subject: Re: [PATCH v27 3/4] i2c: ast2600: Add controller driver for AST2600
> new register set
>
> Hi Ryan,
>
> > > I would suggest separating the string parsing from the "is the mode
> available"
> > > logic, more on that below.
> > >
> > I will separate with following.
> >
> > static int ast2600_i2c_xfer_mode_parse(const char *buf, enum xfer_mode
> > *mode) {
> > if (sysfs_streq(buf, "byte")) { *mode = BYTE_MODE; return 0; }
> > if (sysfs_streq(buf, "buffer")) { *mode = BUFF_MODE; return 0; }
> > if (sysfs_streq(buf, "dma")) { *mode = DMA_MODE; return 0; }
> > return -EINVAL;
> > }
>
> OK, but with kernel-style formatting.
Yes, will update
static int ast2600_i2c_xfer_mode_parse(const char *buf, enum xfer_mode *mode)
{
if (sysfs_streq(buf, "byte")) {
*mode = BYTE_MODE;
return 0;
}
if (sysfs_streq(buf, "buffer")) {
*mode = BUFF_MODE;
return 0;
}
if (sysfs_streq(buf, "dma")) {
*mode = DMA_MODE;
return 0;
}
return -EINVAL;
}
>
> >
> > static int ast2600_i2c_xfer_mode_check(struct ast2600_i2c_bus
> > *i2c_bus,
> > enum
> xfer_mode mode) {
> > if (mode == BUFF_MODE && !i2c_bus->buf_base)
> > return -EINVAL;
> > if (mode == DMA_MODE && !i2c_bus->dma_available)
> > return -EINVAL;
> > return 0;
> > }
> >
> > > > +
> > > > +static const char *ast2600_i2c_xfer_mode_name(enum xfer_mode
> > > > +mode) {
> > > > + switch (mode) {
> > > > + case BYTE_MODE:
> > > > + return "byte";
> > > > + case DMA_MODE:
> > > > + return "dma";
> > > > + case BUFF_MODE:
> > > > + default:
> > > > + return "buffer";
> > > > + }
> > > > +}
> > > > +
> > > > +static ssize_t xfer_mode_show(struct device *dev, struct
> > > > +device_attribute *attr, char *buf) {
> > > > + struct ast2600_i2c_bus *i2c_bus = dev_get_drvdata(dev);
> > > > +
> > > > + return sysfs_emit(buf, "%s\n",
> > > > +ast2600_i2c_xfer_mode_name(i2c_bus->mode));
> > > > +}
> > > > +
> > > > +static ssize_t xfer_mode_store(struct device *dev,
> > > > + struct device_attribute
> *attr,
> > > > + const char *buf, size_t
> count)
> > > {
> > > > + struct ast2600_i2c_bus *i2c_bus = dev_get_drvdata(dev);
> > > > + enum xfer_mode mode;
> > > > + int ret;
> > > > +
> > > > + ret = ast2600_i2c_xfer_mode_parse(i2c_bus, buf, &mode);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + i2c_lock_bus(&i2c_bus->adap, I2C_LOCK_ROOT_ADAPTER);
> > > > + ast2600_i2c_set_xfer_mode(i2c_bus, mode);
> > > > + i2c_unlock_bus(&i2c_bus->adap,
> I2C_LOCK_ROOT_ADAPTER);
> > > > +
> > > > + return count;
> > > > +}
> > > > +
> > > > +static DEVICE_ATTR_RW(xfer_mode);
> > >
> > > This will need sysfs ABI documentation.
> >
> > Since it is in sysfs /sys/bus/platform/drivers/i2c_ast2600
> > So I add
> > Documentation/ABI/testing/sysfs-bus-platform-drivers-i2c-ast2600
> > am I right?
>
> I would suggest Documentation/ABI/testing/sysfs-driver-ast2600-i2c
Thanks ~ will update.
>
> >
> > What: /sys/bus/platform/drivers/i2c-ast2600/.../xfer_mode
> > Date: March 2026
> > KernelVersion: 6.x
>
> KernelVersion is optional, but if you include it, it would be 7.x.
Will update
>
> > Contact: Ryan Chen <ryan_chen@aspeedtech.com>
> > Description:
>
> Keep the first line of the description on the same line.
Will update
>
> > Shows or sets the transfer mode for the ASPEED
> AST2600
> > I2C
> > controller. Valid values are:
> >
> > - "byte": Programmed I/O, one byte at a time.
> > - "buffer": Programmed I/O using the hardware
> FIFO buffer.
> > - "dma": DMA transfer (only available if
> > aspeed,enable-dma
> > is set in the device tree).
>
> Decouple this from the device tree configuration mechanism:
Will remove.
>
> - "dma": DMA transfer (if DMA is available for
> this
> controller)
>
> > i2c_bus->buf_base = devm_platform_get_and_ioremap_resource(pdev, 1,
> > &res); if (!IS_ERR(i2c_bus->buf_base))
> > i2c_bus->buf_size = resource_size(res) / 2; else
> > i2c_bus->buf_base = NULL;
>
> I would suggest a temporary, so there's no chance that future changes could
> see an ERR_PTR value in i2c_bus->buf_base:
>
> buf_base = devm_platform_get_and_ioremap_resource(pdev, 1, &res);
> if (!IS_ERR(buf_base)) {
> i2c_bus->buf_base = buf_base
> i2c_bus->buf_size = resource_size(res) / 2;
> }
>
> and you have kzalloc()ed, so no need for the NULL init in the error path.
Thanks will update.
>
> Cheers,
>
>
> Jeremy
^ permalink raw reply
* RE: [PATCH v27 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and transfer-mode properties
From: Ryan Chen @ 2026-03-26 2:19 UTC (permalink / raw)
To: Rob Herring
Cc: Jeremy Kerr, andriy.shevchenko@linux.intel.com, Andi Shyti,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20260325165233.GA3782899-robh@kernel.org>
> Subject: Re: [PATCH v27 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and transfer-mode properties
>
> On Wed, Mar 25, 2026 at 08:11:54AM +0000, Ryan Chen wrote:
> > Hello Jeremy,
> > Thanks the review.
> >
> > > Subject: Re: [PATCH v27 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
> > > global-regs and transfer-mode properties
> > >
> > > Hi Ryan,
> > >
> > > > The AST2600 I2C controller supports three transfer modes (byte,
> > > > buffer, DMA). Add "aspeed,transfer-mode" so DT can select the
> > > > preferred transfer method per controller instance.
> > >
> > > This patch does not add an aspeed,transfer-mode property.
> > Will update use aspeed,enable-dma
>
> [...]
>
> > > > + aspeed,enable-dma:
> > > > + type: boolean
> > > > + description: |
> > > > + I2C bus enable dma mode transfer.
> > > > +
> > > > + ASPEED ast2600 platform equipped with 16 I2C controllers
> > > > +that share a
> > > > + single DMA engine. DTS files can specify the data transfer
> > > > +mode to/from
> > > > + the device, either DMA or programmed I/O.
> > >
> > > As we had discussed: this does not define the transfer mode, only
> > > whether DMA is available to the peripheral.
> > >
> > > Why mention the 16 i2c controllers here?
> > >
> > > Please keep this description simple and relevant to the specific
> > > purpose of the property.
> >
> > Will update with following.
> > description: Enable DMA for transfers on this I2C bus.
>
> You still don't understand the distinction. It's not enable, but that the h/w
> instance *has* DMA capability or not. It is still up to the OS what to do with
> that information.
>
Thanks
Will update
description: Indicates this I2C controller instance has DMA capability.
^ permalink raw reply
* [PATCH] perf/arm-cmn: Fix resource_size_t printk specifier in arm_cmn_init_dtc()
From: Nathan Chancellor @ 2026-03-26 2:19 UTC (permalink / raw)
To: Robin Murphy, Will Deacon, Mark Rutland, Ilkka Koskinen
Cc: linux-arm-kernel, linux-perf-users, linux-kernel,
Nathan Chancellor
When building for 32-bit ARM, there is a warning when using the %llx
specifier to print a resource_size_t variable:
drivers/perf/arm-cmn.c: In function 'arm_cmn_init_dtc':
drivers/perf/arm-cmn.c:2149:73: error: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'resource_size_t' {aka 'unsigned int'} [-Werror=format=]
2149 | "Failed to request DTC region 0x%llx\n", base);
| ~~~^ ~~~~
| | |
| | resource_size_t {aka unsigned int}
| long long unsigned int
| %x
Use the %pa specifier to handle the possible sizes of phys_addr_t
properly. This requires passing the variable by reference.
Fixes: 5394396ff548 ("perf/arm-cmn: Stop claiming entire iomem region")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
drivers/perf/arm-cmn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 1ac91cda6780..5c727c2abaf0 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -2146,7 +2146,7 @@ static int arm_cmn_init_dtc(struct arm_cmn *cmn, struct arm_cmn_node *dn, int id
size = cmn->part == PART_CMN600 ? SZ_16K : SZ_64K;
if (!devm_request_mem_region(cmn->dev, base, size, dev_name(cmn->dev)))
return dev_err_probe(cmn->dev, -EBUSY,
- "Failed to request DTC region 0x%llx\n", base);
+ "Failed to request DTC region 0x%pa\n", &base);
writel_relaxed(CMN_DT_DTC_CTL_DT_EN, dtc->base + CMN_DT_DTC_CTL);
writel_relaxed(CMN_DT_PMCR_PMU_EN | CMN_DT_PMCR_OVFL_INTR_EN, CMN_DT_PMCR(dtc));
---
base-commit: 2f89b7f78c50ca973ca035ceb30426f78d9e0996
change-id: 20260325-perf-arm-cmn-fix-resource_size_t-format-b01795e36e60
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply related
* [PATCH] ARM: omap2: simplify allocation for omap_device
From: Rosen Penev @ 2026-03-26 2:34 UTC (permalink / raw)
To: linux-omap
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM SUB-ARCHITECTURES, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Use a flexible array member to combine allocations.
Add __counted_by for extra runtime analysis.
Remove goto paths as they are not really needed anymore.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/mach-omap2/omap_device.c | 21 ++++++---------------
arch/arm/mach-omap2/omap_device.h | 2 +-
2 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 79db4c49ffc9..55f2a9d5f4df 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -309,17 +309,15 @@ static struct omap_device *omap_device_alloc(struct platform_device *pdev,
int i;
struct omap_hwmod **hwmods;
- od = kzalloc_obj(struct omap_device);
- if (!od)
- goto oda_exit1;
+ od = kzalloc_flex(*od, hwmods, oh_cnt);
+ if (!od) {
+ dev_err(&pdev->dev, "omap_device: build failed (%d)\n", ret);
+ return ERR_PTR(ret);
+ }
od->hwmods_cnt = oh_cnt;
+ memcpy(od->hwmods, ohs, oh_cnt * sizeof(*od->hwmods));
- hwmods = kmemdup_array(ohs, oh_cnt, sizeof(*hwmods), GFP_KERNEL);
- if (!hwmods)
- goto oda_exit2;
-
- od->hwmods = hwmods;
od->pdev = pdev;
pdev->archdata.od = od;
@@ -329,13 +327,6 @@ static struct omap_device *omap_device_alloc(struct platform_device *pdev,
}
return od;
-
-oda_exit2:
- kfree(od);
-oda_exit1:
- dev_err(&pdev->dev, "omap_device: build failed (%d)\n", ret);
-
- return ERR_PTR(ret);
}
static void omap_device_delete(struct omap_device *od)
diff --git a/arch/arm/mach-omap2/omap_device.h b/arch/arm/mach-omap2/omap_device.h
index aa8096ecb23c..9283c15c2403 100644
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -51,11 +51,11 @@
*/
struct omap_device {
struct platform_device *pdev;
- struct omap_hwmod **hwmods;
unsigned long _driver_status;
u8 hwmods_cnt;
u8 _state;
u8 flags;
+ struct omap_hwmod *hwmods[] __counted_by(hwmods_cnt);
};
/* Device driver interface (call via platform_data fn ptrs) */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Nathan Chancellor @ 2026-03-26 2:42 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nicolas Schier, Nick Desaulniers, Bill Wendling, Justin Stitt,
David Gow, Russell King, Richard Weinberger, Anton Ivanov,
Johannes Berg, aliceryhl, linux-um, llvm, linux-arm-kernel,
linux-kbuild, a.hindborg, acourbot, akpm, bjorn3_gh, boqun.feng,
dakr, gary, linux-kernel, linux-mm, lossin, mark.rutland, mmaurer,
nicolas.schier, peterz, rust-for-linux, tmgross, urezki, will
In-Reply-To: <20260322192159.88138-1-ojeda@kernel.org>
On Sun, Mar 22, 2026 at 08:21:59PM +0100, Miguel Ojeda wrote:
> - Clang passes `-Werror=unused-command-line-argument`, which means
> under arm (i.e. 32-bit) we get:
>
> clang: error: argument unused during compilation: '-U arm' [-Werror,-Wunused-command-line-argument]
>
> And under UML I see:
>
> clang: error: argument unused during compilation: '-I ./arch/um/include/shared' [-Werror,-Wunused-command-line-argument]
> clang: error: argument unused during compilation: '-I ./arch/x86/um/shared' [-Werror,-Wunused-command-line-argument]
> clang: error: argument unused during compilation: '-I ./arch/um/include/shared/skas' [-Werror,-Wunused-command-line-argument]
>
> So we would need e.g. `-Wno-unused-command-line-argument` there
> close to the `-Wno-override-module` one, unless Kbuild or
> ClangBuiltLinux thinks it is important to keep it for this case.
No, I don't think it is worth trying to make -Wunused-command-line-argument
work for this command. Just disable it. This mirrors what is being done
for cmd_cc_o_bc in the distributed ThinLTO:
https://lore.kernel.org/20260316212930.120438-3-xur@google.com/
> On the other hand, regardless of whether we fix this (and another
> issue in a separate email found thanks to the UML build), we could
> instead add `depends on` listing explicitly the architectures where
> this is going to be actually tested. That way maintainers can decide
> whether they want to support it when they are ready. Thoughts?
>
> Cc'ing Nathan, Nicolas, Nick, Bill, Justin, David, UML, ARM.
I do agree with some of the concerns that adding an architecure
dimension to this is a little complicated. I would rather try to flush
out those build problems with patches and keep it enabled for all
architectures. At the same time though, I understand that enabling it
for the "tier 1" architectures is a low barrier of entry for getting the
feature upstream, validated, and distributed to the majority of people
that would actually use and depend on it, so I ultimately leave that
call up to you.
> - If we use the `.bc` extension, we need to add a `.gitignore` for
> `.bc` files, and an exception for `kernel/time/timeconst.bc`.
>
> I guess we will not have too many `bc` scripts in the future for
> that to be a problem. On the other hand, we have the chance to use
> another extension (either for LLVM bitcode or for `bc` scripts).
>
> But please let me know on e.g. the Kbuild side if someone has
> concerns...
No real concern on that front but .gitignore has a command to run when
modifying it, which will require a !timeconst.bc in a
kernel/time/.gitignore file.
Cheers,
Nathan
^ permalink raw reply
* RE: Re: [PATCH v2] ASoC: dt-bindings: imx-card: Add dsp_a DAI format
From: Chancel Liu @ 2026-03-26 2:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: lgirdwood@gmail.com, broonie@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, Frank Li,
shengjiu.wang@gmail.com, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-sound@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <83024a54-74dd-43b0-8c8c-0c23820bb5e0@kernel.org>
> >>> The imx-card machine driver originally supported only codecs
> >>> operating in i2s or dsp_b formats. This machine driver can support
> >>> CS42448 codec and this codec typically uses dsp_a for its TDM
> >>> interface. Therefore,
> >>
> >> And what about other formats, which was asked last time?
> >>
> >
> > The imx-card machine driver currently implements support only for
> > codecs with i2s and dsp_b format. The newly added CS42448 codec
> > requires dsp_a and that is why this patch adds dsp_a only. No other
> > formats are used or supported by the existing hardware covered by this
>
> First sentence says about driver, here you speak about hardware, so feels like
> you are mixing these.
>
> Best regards,
> Krzysztof
You're right, I should not mention the driver. What I meant is that the
existing i.MX audio sound card described by this binding use codecs
that operate in i2s or dsp_b formats.
Regards,
Chancel Liu
^ permalink raw reply
* [GIT PULL] aspeed: first batch of fixes for v7.0
From: Andrew Jeffery @ 2026-03-26 2:55 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel, linux-aspeed, linux-kernel, Joel Stanley
Hello SoC maintainers,
I've been intending to send out this fix PR for a while now, but time
has escaped me recently.
Andrew
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git tags/aspeed-7.0-fixes-0
for you to fetch changes up to 7ec1bd3d9be671d04325b9e06149b8813f6a4836:
soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching (2026-02-23 09:43:21 +1030)
----------------------------------------------------------------
aspeed: first batch of fixes for v7.0
----------------------------------------------------------------
Potin Lai (1):
soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching
drivers/soc/aspeed/aspeed-socinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH RESEND] mmc: mtk-sd: disable new_tx/rx and modify related settings for mt8189
From: Cathy Xu @ 2026-03-26 3:05 UTC (permalink / raw)
To: Chaotian Jing, Ulf Hansson, Matthias Brugger,
AngeloGioacchino Del Regno, Louis-Alexis Eyraud
Cc: linux-mmc, linux-kernel, linux-arm-kernel, linux-mediatek,
Mengqi Zhang, Wenbin Mei, Andy-ld Lu, Axe Yang, Yong Mao,
Cathy Xu, stable
Disable new_tx/rx to avoid data transmission instability, and adjust
.data_tune, .stop_dly_sel, and .pop_en_cnt to fit the overall
configuration after disabling new_tx/rx, making it more compatible
with mt8189.
Fixes: 846a3a2fdff5 ("mmc: mtk-sd: add support for MT8189 SoC")
Cc: stable@vger.kernel.org
Tested-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Signed-off-by: Cathy Xu <ot_cathy.xu@mediatek.com>
---
drivers/mmc/host/mtk-sd.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 302ac8529c4f..b2680cc054bd 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -682,15 +682,15 @@ static const struct mtk_mmc_compatible mt8189_compat = {
.needs_top_base = true,
.pad_tune_reg = MSDC_PAD_TUNE0,
.async_fifo = true,
- .data_tune = true,
+ .data_tune = false,
.busy_check = true,
.stop_clk_fix = true,
- .stop_dly_sel = 1,
- .pop_en_cnt = 2,
+ .stop_dly_sel = 3,
+ .pop_en_cnt = 8,
.enhance_rx = true,
.support_64g = true,
- .support_new_tx = true,
- .support_new_rx = true,
+ .support_new_tx = false,
+ .support_new_rx = false,
.support_spm_res_release = true,
};
--
2.45.2
^ permalink raw reply related
* [GIT PULL] aspeed: first batch of devicetree changes for v7.1
From: Andrew Jeffery @ 2026-03-26 3:09 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel, linux-aspeed, linux-kernel, Joel Stanley
Hello SoC maintainers,
Here's the first batch of ASPEED devicetree changes for v7.1.
Please pull.
Cheers,
Andrew
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git tags/aspeed-7.1-devicetree-0
for you to fetch changes up to 76b4ec8efdc3887cdbf730da2e55881fc1a18770:
ARM: dts: aspeed: anacapa: Add retimer EEPROMs (2026-02-23 12:02:22 +1030)
----------------------------------------------------------------
aspeed: first batch of devicetree changes for v7.1
New platforms:
- Asus Kommando IPMI card
- Asrock Paul IPMI card
Updated platforms:
- Anacapa (Meta): NFC and EEPROMs
- MSX4 (Nvidia): 128M layout for the alternate boot flash
----------------------------------------------------------------
Anirudh Srinivasan (4):
dt-bindings: arm: aspeed: Add Asus Kommando IPMI card
ARM: dts: aspeed: Add Asus Kommando IPMI card
dt-bindings: arm: aspeed: Add Asrock Paul IPMI card
ARM: dts: aspeed: Add Asrock Paul IPMI card
Carl Lee (1):
ARM: dts: aspeed: anacapa: add NFC device
Dirk Chen (1):
ARM: dts: aspeed: anacapa: Add retimer EEPROMs
Marc Olberding (1):
ARM: dts: aspeed: Add 128M alt flash layout to NVIDIA MSX4
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 2 ++
arch/arm/boot/dts/aspeed/Makefile | 2 ++
arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-paul-ipmi-card.dts | 131 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 22 +++++++++++++++
arch/arm/boot/dts/aspeed/aspeed-bmc-nvidia-msx4-bmc.dts | 1 +
arch/arm/boot/dts/aspeed/openbmc-flash-layout-128-alt.dtsi | 32 ++++++++++++++++++++++
7 files changed, 307 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-paul-ipmi-card.dts
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
create mode 100644 arch/arm/boot/dts/aspeed/openbmc-flash-layout-128-alt.dtsi
^ permalink raw reply
* Re: Re: [PATCH net-next v5 3/3] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: 李志 @ 2026-03-26 3:14 UTC (permalink / raw)
To: Simon Horman
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan
In-Reply-To: <20260325180330.GL111839@horms.kernel.org>
> -----原始邮件-----
> 发件人: "Simon Horman" <horms@kernel.org>
> 发送时间:2026-03-26 02:03:30 (星期四)
> 收件人: lizhi2@eswincomputing.com
> 抄送: devicetree@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, linux-riscv@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, maxime.chevallier@bootlin.com, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com, pritesh.patel@einfochips.com, weishangjuan@eswincomputing.com
> 主题: Re: [PATCH net-next v5 3/3] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
>
> On Tue, Mar 24, 2026 at 03:34:08PM +0800, lizhi2@eswincomputing.com wrote:
> > From: Zhi Li <lizhi2@eswincomputing.com>
> >
> > Enable the on-board Gigabit Ethernet controller on the
> > HiFive Premier P550 development board.
> >
> > Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> > ---
> > .../dts/eswin/eic7700-hifive-premier-p550.dts | 42 ++++++++++++
> > arch/riscv/boot/dts/eswin/eic7700.dtsi | 66 +++++++++++++++++++
> > 2 files changed, 108 insertions(+)
>
> Unfortunately this does not compile:
>
> $ ARCH=riscv make allmodconfig dtbs
> ...
> DTC arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dtb
> arch/riscv/boot/dts/eswin/eic7700.dtsi:300.28-330.5: ERROR (phandle_references): /soc/ethernet@50400000: Reference to non-existent node or label "clk"
> ...
>
> --
> pw-bot: changes-requested
Hi Simon,
Thanks for your review.
You're right, this build failure is due to an invalid clock reference
("clk") in the Ethernet node, which does not correspond to an existing
clock provider label in the current DTS.
For context, this was discussed during an earlier revision:
https://lore.kernel.org/lkml/5dea8ce0.4435.19c471231f5.Coremail.lizhi2@eswincomputing.com/
The EIC7700 clock controller support has since been applied, so I will
update the DTS to reference the correct clock provider and ensure the
build passes cleanly.
I will fix this in the next revision (v6).
Thanks,
Zhi Li
^ permalink raw reply
* Re: (subset) [PATCH 0/7] arm64: dts: Drop CPU masks from GICv3 PPI interrupts
From: Bjorn Andersson @ 2026-03-26 3:19 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Peter Griffin, André Draszik, Tudor Ambarus, Alim Akhtar,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dinh Nguyen, Konrad Dybcio, Thierry Reding, Marc Zyngier,
Geert Uytterhoeven
Cc: linux-arm-kernel, linux-amlogic, linux-samsung-soc, imx,
linux-arm-msm, linux-renesas-soc, linux-kernel
In-Reply-To: <cover.1772643434.git.geert+renesas@glider.be>
On Wed, 04 Mar 2026 18:10:57 +0100, Geert Uytterhoeven wrote:
> Hi all,
>
> Unlike older GIC variants, the GICv3 DT bindings do not support
> specifying a CPU mask in PPI interrupt specifiers. Hence this patch
> series drop all such masks where they are still present.
>
> This has been compile-tested only. But note that all such masks were
> removed before from Renesas SoCs in commit 8b6a006c914aac17 ("arm64:
> dts: renesas: Drop specifying the GIC_CPU_MASK_SIMPLE() for GICv3
> systems")).
>
> [...]
Applied, thanks!
[7/7] arm64: dts: qcom: Drop CPU masks from GICv3 PPI interrupts
commit: 99bb0693df91db9338fa69d496de4601c9582058
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* [GIT PULL] nuvoton: first batch of arm64 devicetree changes for v7.1
From: Andrew Jeffery @ 2026-03-26 3:26 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel, openbmc, linux-kernel, Joel Stanley
Hello SoC maintainers,
Just the one Nuvoton devicetree change for v7.1
Please pull.
Andrew
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git tags/nuvoton-arm64-7.1-devicetree-0
for you to fetch changes up to 6ee3f20368a4a6198988a54c1a744cbae1354359:
arm64: dts: nuvoton: drop unused syscon property from watchdog node (2026-02-23 09:43:36 +1030)
----------------------------------------------------------------
nuvoton: first batch of arm64 devicetree changes for v7.1
Just the one change this time, dropping syscon properties where they weren't
defined.
----------------------------------------------------------------
Tomer Maimon (1):
arm64: dts: nuvoton: drop unused syscon property from watchdog node
arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
^ permalink raw reply
* [PATCH 1/1] arm64: defconfig: Enable options for CIX Sky1 SoC
From: Peter Chen @ 2026-03-26 3:39 UTC (permalink / raw)
To: arnd
Cc: krzysztof.kozlowski, geert+renesas, linux-kernel,
linux-arm-kernel, Peter Chen, Yunseong Kim
Enable pinctrl, gpio, pcie and hda audio support.
Cc: Yunseong Kim <ysk@kzalloc.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
arch/arm64/configs/defconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b67d5b1fc45b..85151adc7d65 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -241,6 +241,7 @@ CONFIG_PCIE_XILINX_DMA_PL=y
CONFIG_PCIE_XILINX_NWL=y
CONFIG_PCIE_XILINX_CPM=y
CONFIG_PCI_J721E_HOST=m
+CONFIG_PCI_SKY1_HOST=m
CONFIG_PCI_IMX6_HOST=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
@@ -676,6 +677,7 @@ CONFIG_PINCTRL_SDM660=y
CONFIG_PINCTRL_SDM670=y
CONFIG_PINCTRL_SDM845=y
CONFIG_PINCTRL_SDX75=y
+CONFIG_PINCTRL_SKY1=y
CONFIG_PINCTRL_SM4450=y
CONFIG_PINCTRL_SM6115=y
CONFIG_PINCTRL_SM6125=y
@@ -701,6 +703,7 @@ CONFIG_PINCTRL_SM8550_LPASS_LPI=m
CONFIG_PINCTRL_SM8650_LPASS_LPI=m
CONFIG_PINCTRL_SOPHGO_SG2000=y
CONFIG_GPIO_ALTERA=m
+CONFIG_GPIO_CADENCE=m
CONFIG_GPIO_DAVINCI=y
CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_MB86S7X=y
@@ -1060,6 +1063,7 @@ CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_ALOOP=m
CONFIG_SND_HDA_TEGRA=m
+CONFIG_SND_HDA_CIX_IPBLOQ=m
CONFIG_SND_HDA_CODEC_HDMI=m
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_AUDIO_QMI=m
--
2.50.1
^ permalink raw reply related
* Re: [PATCH RESEND 1/2] regulator: dt-bindings: mt6315: Add regulator supplies
From: Chen-Yu Tsai @ 2026-03-26 4:14 UTC (permalink / raw)
To: Mark Brown, Krzysztof Kozlowski
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-mediatek, devicetree
In-Reply-To: <32638731-8f33-4203-9e68-1170cff99280@sirena.org.uk>
On Thu, Mar 26, 2026 at 12:55 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Mar 25, 2026 at 09:56:00AM +0100, Krzysztof Kozlowski wrote:
> > On Tue, Mar 24, 2026 at 01:30:28PM +0800, Chen-Yu Tsai wrote:
>
> > > + pvdd4-supply:
> > > + description: Supply for vbuck4
>
> > These all look per-regulator supplies, so I think they should be in each
> > regulator node (see also regulator.yaml).
>
> > Or in top-level, but not in "regulators" node. The regulators is only
> > wrapping node for children.
>
> > I wonder what should be our preference - have supplies per regulator or
> > in top-level node. @Mark, any preference from your side?
>
> The top level, so people can figure out where to describe supplies
> without having to read the bindings so much - the supplies go into the
> chip, even if they're distributed within it.
OK. What about the more complicated mfd PMICs? We already added
*-supplies for the regulator side of these PMICs in
- regulator/mediatek,mt6358-regulator.yaml
- regulator/mediatek,mt6363-regulator.yaml
And my other series for the MT6359 also adds them in this manner.
Thanks
ChenYu
^ permalink raw reply
* [PATCH] clk: visconti: pll: use kzalloc_flex
From: Rosen Penev @ 2026-03-26 4:23 UTC (permalink / raw)
To: linux-clk
Cc: Michael Turquette, Stephen Boyd, Nobuhiro Iwamatsu, Kees Cook,
Gustavo A. R. Silva,
moderated list:ARM/TOSHIBA VISCONTI ARCHITECTURE, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Simplify allocation by using a flexible array member and kzalloc_flex.
Add __counted_by for extra runtime analysis. Assign after allocation as
required by __counted_by.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/clk/visconti/pll.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/visconti/pll.c b/drivers/clk/visconti/pll.c
index 6fd02c4b641e..ca29d12f9316 100644
--- a/drivers/clk/visconti/pll.c
+++ b/drivers/clk/visconti/pll.c
@@ -21,9 +21,9 @@ struct visconti_pll {
void __iomem *pll_base;
spinlock_t *lock;
unsigned long flags;
- const struct visconti_pll_rate_table *rate_table;
size_t rate_count;
struct visconti_pll_provider *ctx;
+ struct visconti_pll_rate_table rate_table[] __counted_by(rate_count);
};
#define PLL_CONF_REG 0x0000
@@ -255,10 +255,6 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
size_t len;
int ret;
- pll = kzalloc_obj(*pll);
- if (!pll)
- return ERR_PTR(-ENOMEM);
-
init.name = name;
init.flags = CLK_IGNORE_UNUSED;
init.parent_names = &parent_name;
@@ -266,11 +262,13 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
for (len = 0; rate_table[len].rate != 0; )
len++;
+
+ pll = kzalloc_flex(*pll, rate_table, len);
+ if (!pll)
+ return ERR_PTR(-ENOMEM);
+
pll->rate_count = len;
- pll->rate_table = kmemdup_array(rate_table,
- pll->rate_count, sizeof(*pll->rate_table),
- GFP_KERNEL);
- WARN(!pll->rate_table, "%s: could not allocate rate table for %s\n", __func__, name);
+ memcpy(pll->rate_table, rate_table, len * sizeof(*pll->rate_table));
init.ops = &visconti_pll_ops;
pll->hw.init = &init;
@@ -282,7 +280,6 @@ static struct clk_hw *visconti_register_pll(struct visconti_pll_provider *ctx,
ret = clk_hw_register(NULL, &pll->hw);
if (ret) {
pr_err("failed to register pll clock %s : %d\n", name, ret);
- kfree(pll->rate_table);
kfree(pll);
pll_hw_clk = ERR_PTR(ret);
}
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: renesas: Fix missing cells and reg
From: Marek Vasut @ 2026-03-26 4:23 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
Add missing cells and reg DT property into DTOs to fix warnings like this:
"
arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
"
Marek Vasut (4):
arm64: dts: renesas: Fix missing cells and reg in Draak/Ebisu panel
DTO
arm64: dts: renesas: Fix missing cells and reg in Salvator-X panel DTO
arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into CSI2
subnode
arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into DU
subnode
arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso | 5 +++++
arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi | 5 +++++
arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi | 5 +++++
arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso | 5 +++++
4 files changed, 20 insertions(+)
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
--
2.53.0
^ permalink raw reply
* [PATCH 1/4] arm64: dts: renesas: Fix missing cells and reg in Draak/Ebisu panel DTO
From: Marek Vasut @ 2026-03-26 4:23 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-1-marek.vasut+renesas@mailbox.org>
Add missing cells and reg DT property into Draak/Ebisu panel DTO to fix
the following warning:
"
arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
"
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso b/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
index 258f8668ca361..90767d74e21b2 100644
--- a/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
+++ b/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
@@ -27,7 +27,12 @@ &lvds1 {
status = "okay";
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@1 {
+ reg = <1>;
+
lvds1_out: endpoint {
remote-endpoint = <&panel_in>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: renesas: Fix missing cells and reg in Salvator-X panel DTO
From: Marek Vasut @ 2026-03-26 4:23 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-1-marek.vasut+renesas@mailbox.org>
Add missing cells and reg DT property into Salvator-X panel DTO to fix
the following warning:
"
arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
"
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso b/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
index c83a30adc6adf..7807c3f80409a 100644
--- a/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
+++ b/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
@@ -27,7 +27,12 @@ &lvds0 {
status = "okay";
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@1 {
+ reg = <1>;
+
lvds0_out: endpoint {
remote-endpoint = <&panel_in>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into DU subnode
From: Marek Vasut @ 2026-03-26 4:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-1-marek.vasut+renesas@mailbox.org>
Add missing cells and reg DT property into DU subnode to fix
the following warning:
"
arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi:29.10-33.5: Warning (unit_address_vs_reg): /fragment@1/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
"
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi b/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
index 36707576030d4..f5412578ee65f 100644
--- a/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
+++ b/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
@@ -26,7 +26,12 @@ &du {
status = "okay";
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@0 {
+ reg = <0>;
+
du_out_rgb: endpoint {
remote-endpoint = <&adv7513_in>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into CSI2 subnode
From: Marek Vasut @ 2026-03-26 4:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-1-marek.vasut+renesas@mailbox.org>
Add missing cells and reg DT property into CSI2 subnode to fix
the following warning:
"
arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi:49.10-55.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
"
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi b/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
index 4d2b0655859ab..3feffa4f16a9a 100644
--- a/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
+++ b/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
@@ -46,7 +46,12 @@ &csi2 {
status = "okay";
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@0 {
+ reg = <0>;
+
csi2_in: endpoint {
clock-lanes = <0>;
data-lanes = <1 2>;
--
2.53.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