From nobody Mon Sep 28 14:47:47 2026 Received: from 12.mo561.mail-out.ovh.net (12.mo561.mail-out.ovh.net [188.165.41.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A21B47D47C for ; Thu, 20 Aug 2026 16:30:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=188.165.41.191 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787243424; cv=none; b=S01wtV1LxNxCO4vUMKhe/C/p4H8WTT3KM8P2tPZMPi4DwJ6vCXVK08XaPGQ0cS5ecr/tM3CzbzcnYvQsZWn86kxJvbaLR2NofWb73xn49Q/GsXLQaqxY1crKaehcEgzC2uA2K+qDDG7orl6K+57xkWWwLN+Ch8RaHAg1SCul5Y8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787243424; c=relaxed/simple; bh=MhE0/wkYHzuHF8BSJwZYmKYWzxbk/rV3AvAFxVB2hlA=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=fJn3Uyd3r6xi+qmLex8aNI8yvMVzty9oCeM6XNgiFUIgVUhzIBcX+leXdq3f+0nfl5HaWlBFYI0iiAytm/9YkvddQiwRBTF/CtlMoMkNXyQEui3w3kdBm8AyWrVel/CGX9Uwj3gvH1oPlZC+zfxdGbmWvMkDHtRG4MOjsRAi87s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=m-works.net; spf=pass smtp.mailfrom=m-works.net; arc=none smtp.client-ip=188.165.41.191 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=m-works.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=m-works.net Received: from director11.ghost.mail-out.ovh.net (unknown [10.110.37.140]) by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4hQlTy6YVBz69w7 for ; Thu, 20 Aug 2026 14:01:26 +0000 (UTC) Received: from ghost-submission-c7b579475-5flvk (unknown [10.108.42.231]) by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 9EDEEC2980; Thu, 20 Aug 2026 14:01:24 +0000 (UTC) Received: from m-works.net ([37.59.142.101]) by ghost-submission-c7b579475-5flvk with ESMTPSA id V8Q4F7QIh2o7QAkAoCPlrQ (envelope-from ); Thu, 20 Aug 2026 14:01:24 +0000 Authentication-Results: garm.ovh; auth=pass (GARM-101G0040abbf50e-72bc-4bc8-bdce-1a017c43d6c3, F470D10F53EF0FE28D2744507C2115D6BA5D3262) smtp.auth=maciej.andrzejewski@m-works.net X-OVh-ClientIp: 144.125.48.245 Date: Thu, 20 Aug 2026 16:01:23 +0200 From: Maciej Andrzejewski ICEYE To: Greg Kroah-Hartman , chris.packham@alliedtelesis.co.nz, daniel@zonque.org, andriy.shevchenko@linux.intel.com, sakari.ailus@linux.intel.com, stable@vger.kernel.org, linux-kernel@vger.kernel.org, maciej.andrzejewski@m-works.net Cc: Chris Packham , Daniel Mack , Andy Shevchenko , Sakari Ailus , stable@vger.kernel.org, linux-kernel@vger.kernel.org, Maciej Andrzejewski ICEYE Subject: [PATCH] uio: uio_pdrv_genirq: restore UIO name without the unit address Message-ID: <20260820140119.1546932-1-maciej.andrzejewski@m-works.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline X-Mailer: git-send-email 2.43.0 x-ovh-tracer-id: 627689202175910691 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: dmFkZTEG0ngEF9nRi0MYWm+kVUjyBHmUn9yCNaNneXS6IBhjHr6KvhiN9BRC2dM8u9zc1J8Ywvpy79Q0PgOY9YjTWIP9i97DLyCyCQwp+uJhf4XF6YzZhPN+2K2bGoqy2tKzXAIZKLKUiVeVvJTQs/Z7ezIxsif+FzkSu9ijThO74jGUFUVQj82Tpnn+fLA2SKsMnDFylvD8b62TcYiJoErQJ7f/8a1k8nrbt/y/XxF78fXbuTjPWY0kgvp3Nwlkoay1cAScly/x48W0P4KgGR+rYQsaRDw59OO6eYP6hQ5GUy3ASZZkWJmWfACgMdCaSZ1cpg4XVtf1IonX4BMtkb1LLt+ILHWX3V1IyBvA77FqeHvaPWwDv/NYyjaKc15OL2p4RlKGRDvDQ/cRAENnFr7s4Cs5wUCni6Fo0P2g7PyzsT6STgSAWgK3plp0i+k4T/sbafZwIY3HRWOTeOjYO87b8YTTjDJ7nSWH6oEIgEl0tzxHc8dSV/RV/5kxS97WwFA7lTNPX8eiCEAE/7a9W+7AM3NO+UYGM3PwBG7l4Ucy8BRtxsy5l4p1B3jKqRr7AX2z+18O/krGVTr2vMh3pA6a4zJj91+zqK2H2+3LQVKG/nN4hmyQYcvVnn46Z9pOA9oH7z7UDZo67og20edIOvtcAwQVKvahzveO4IY3K1OT92SYIg Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit 90fa0280553a ("uio_pdrv_genirq: convert to use device_property APIs") switched the driver to the device_property API so that a UIO device can also be described through an ACPI overlay. As part of that conversion the default name handed to userspace changed from "%pOFn" to "%pfwP". The two specifiers are not interchangeable. The printk format documentation defines %pfwP as the node name including an address if there is one, while %pOFn prints the device tree node name with the unit address stripped. A node named "dma@a0000000" therefore appeared in /sys/class/uio/uioN/name as "dma" up to v6.9 and as "dma@a0000000" from v6.10 onwards. That name is the only stable handle userspace has for a UIO device, because the uioN index follows probe order. Applications that resolve a device by name, for instance through the libuio uio_find_by_uio_name() helper, stop finding it. Nothing in the conversion suggests the rename was intended. Documentation/driver-api/uio-howto.rst still states that the node's name without the unit address is exposed as the name for the UIO device in userspace, and uio_dmem_genirq still builds its name with %pOFn. The "linux,uio-name" property added by commit b0297622a972 ("uio: uio_pdrv_genirq: Make UIO name controllable via DT node property") already lets a board distinguish several identically named nodes, so the default does not need to carry the unit address. fwnode has no equivalent of the %pOFn name-only modifier, which is likely why the closest specifier was picked. Print device tree nodes through %pOFn and leave every other firmware node type on %pfwP. This driver could not be probed from ACPI before 90fa0280553a, so ACPI naming is unaffected. Should the unit address in the default name turn out to be wanted after all, then uio-howto.rst is the file that needs the change instead, and I am happy to send that patch rather than this one. Fixes: 90fa0280553a ("uio_pdrv_genirq: convert to use device_property APIs") Cc: stable@vger.kernel.org Signed-off-by: Maciej Andrzejewski ICEYE Reviewed-by: Sakari Ailus --- Notes: Found on a Zynq UltraScale+ platform where FPGA blocks are exposed through generic-uio nodes. Userspace uses libuio and resolves those devices by name, so the applications stopped finding them after a move from 4.19 to 6.12. The single generic-uio node in tree is renamed the same way: uio@d0000000 in arch/arc/boot/dts/vdk_axs10x_mb.dtsi reads back as "uio" before v6.10 and as "uio@d0000000" after it. Build tested on x86_64 with W=3D1 and CONFIG_UIO_PDRV_GENIRQ=3Dm, once = with CONFIG_OF=3Dy and once with CONFIG_OF=3Dn. No warnings either way. drivers/uio/uio_pdrv_genirq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c index 0c8d73e7be52..27268c8d1b94 100644 --- a/drivers/uio/uio_pdrv_genirq.c +++ b/drivers/uio/uio_pdrv_genirq.c @@ -128,6 +128,9 @@ static int uio_pdrv_genirq_probe(struct platform_device= *pdev) if (!device_property_read_string(&pdev->dev, "linux,uio-name", &name)) uioinfo->name =3D devm_kstrdup(&pdev->dev, name, GFP_KERNEL); + else if (is_of_node(node)) + uioinfo->name =3D devm_kasprintf(&pdev->dev, GFP_KERNEL, + "%pOFn", to_of_node(node)); else uioinfo->name =3D devm_kasprintf(&pdev->dev, GFP_KERNEL, "%pfwP", node); -- 2.50.1