Re: [PATCH] PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap

[sashiko-bot@kernel.org]

> Currently, mmap() of a resourceN file for an I/O BAR fails with
> -ENODEV on architectures where arch_can_pci_mmap_io() is 0, such as
> x86, because the attribute has no mmap callback there and the error
> comes from the generic kernfs dispatch.
> 
> This is a side effect of commit e854d8b2a82e ("PCI: Add
> arch_can_pci_mmap_io() on architectures which can mmap() I/O space"),
> which removed the mmap callback from the I/O resource attribute on
> these architectures.  Previously the request reached the architecture
> mmap code and failed with -EINVAL, and the same commit deliberately
> kept -EINVAL for the identical operation on the procfs interface, so
> the two PCI userspace interfaces have disagreed ever since.
> 
> Therefore, add a pci_mmap_resource_io_unsupported() callback that
> returns -EINVAL and use it as the mmap handler of the I/O resource
> attribute when arch_can_pci_mmap_io() is 0, so the failure is
> produced deliberately by PCI code, consistent with the procfs
> interface and with the behaviour before e854d8b2a82e.
> 
> Architectures where arch_can_pci_mmap_io() is non-zero keep the real
> pci_mmap_resource_uc() handler and are unaffected.  The mmap() fails
> either way.  Only the reported error changes from -ENODEV to -EINVAL.
> 
> Fixes: e854d8b2a82e ("PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space")
> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720204624.1503794-1-kwilczynski@kernel.org?part=1