From: Yongqiang Liu <liuyongqiang13@huawei.com>
Unaligned access is harmful for non-x86 archs such as arm64. When we
use pwrite or pread to access the I/O port resources with unaligned
offset, system will crash as follows:
Unable to handle kernel paging request at virtual address fffffbfffe8010c1
Internal error: Oops: 0000000096000061 [#1] SMP
Call trace:
_outw include/asm-generic/io.h:594 [inline]
logic_outw+0x54/0x218 lib/logic_pio.c:305
pci_resource_io drivers/pci/pci-sysfs.c:1157 [inline]
pci_write_resource_io drivers/pci/pci-sysfs.c:1191 [inline]
pci_write_resource_io+0x208/0x260 drivers/pci/pci-sysfs.c:1181
sysfs_kf_bin_write+0x188/0x210 fs/sysfs/file.c:158
kernfs_fop_write_iter+0x2e8/0x4b0 fs/kernfs/file.c:338
vfs_write+0x7bc/0xac8 fs/read_write.c:586
ksys_write+0x12c/0x270 fs/read_write.c:639
__arm64_sys_write+0x78/0xb8 fs/read_write.c:648
Powerpc seems affected as well, so prohibit the unaligned access
on non-x86 archs.
Fixes: 8633328be242 ("PCI: Allow read/write access to sysfs I/O port resources")
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
Signed-off-by: Ziming Du <duziming2@huawei.com>
---
drivers/pci/pci-sysfs.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 7e697b82c5e1..11d8b7ec4263 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -31,6 +31,7 @@
#include <linux/of.h>
#include <linux/aperture.h>
#include <linux/unaligned.h>
+#include <linux/align.h>
#include "pci.h"
#ifndef ARCH_PCI_DEV_GROUPS
@@ -1166,12 +1167,20 @@ static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
*(u8 *)buf = inb(port);
return 1;
case 2:
+ #if !defined(CONFIG_X86)
+ if (!IS_ALIGNED(port, count))
+ return -EFAULT;
+ #endif
if (write)
outw(*(u16 *)buf, port);
else
*(u16 *)buf = inw(port);
return 2;
case 4:
+ #if !defined(CONFIG_X86)
+ if (!IS_ALIGNED(port, count))
+ return -EFAULT;
+ #endif
if (write)
outl(*(u32 *)buf, port);
else
--
2.43.0On Thu, 8 Jan 2026 09:59:44 +0800
Ziming Du <duziming2@huawei.com> wrote:
> From: Yongqiang Liu <liuyongqiang13@huawei.com>
>
> Unaligned access is harmful for non-x86 archs such as arm64. When we
> use pwrite or pread to access the I/O port resources with unaligned
> offset, system will crash as follows:
>
> Unable to handle kernel paging request at virtual address fffffbfffe8010c1
> Internal error: Oops: 0000000096000061 [#1] SMP
> Call trace:
> _outw include/asm-generic/io.h:594 [inline]
> logic_outw+0x54/0x218 lib/logic_pio.c:305
> pci_resource_io drivers/pci/pci-sysfs.c:1157 [inline]
> pci_write_resource_io drivers/pci/pci-sysfs.c:1191 [inline]
> pci_write_resource_io+0x208/0x260 drivers/pci/pci-sysfs.c:1181
> sysfs_kf_bin_write+0x188/0x210 fs/sysfs/file.c:158
> kernfs_fop_write_iter+0x2e8/0x4b0 fs/kernfs/file.c:338
> vfs_write+0x7bc/0xac8 fs/read_write.c:586
> ksys_write+0x12c/0x270 fs/read_write.c:639
> __arm64_sys_write+0x78/0xb8 fs/read_write.c:648
>
> Powerpc seems affected as well, so prohibit the unaligned access
> on non-x86 archs.
I'm not sure it makes any real sense for x86 either.
IIRC io space is just like memory space, so a 16bit io access looks the
same as two 8bit accesses to an 8bit device (some put the 'data fifo' on
addresses 0 and 1 so the code could use 16bit io accesses to speed things up).
The same will have applied to misaligned accesses.
But, in reality, all device registers are aligned.
I'm not sure EFAULT is the best error code though, EINVAL might be better.
(EINVAL is returned for other address/size errors.)
EFAULT is usually returned for errors accessing the user buffer, a least
one unix system raises SIGSEGV whenever EFAULT is returned.
David
>
> Fixes: 8633328be242 ("PCI: Allow read/write access to sysfs I/O port resources")
> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
> Signed-off-by: Ziming Du <duziming2@huawei.com>
> ---
> drivers/pci/pci-sysfs.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 7e697b82c5e1..11d8b7ec4263 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -31,6 +31,7 @@
> #include <linux/of.h>
> #include <linux/aperture.h>
> #include <linux/unaligned.h>
> +#include <linux/align.h>
> #include "pci.h"
>
> #ifndef ARCH_PCI_DEV_GROUPS
> @@ -1166,12 +1167,20 @@ static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
> *(u8 *)buf = inb(port);
> return 1;
> case 2:
> + #if !defined(CONFIG_X86)
> + if (!IS_ALIGNED(port, count))
> + return -EFAULT;
> + #endif
> if (write)
> outw(*(u16 *)buf, port);
> else
> *(u16 *)buf = inw(port);
> return 2;
> case 4:
> + #if !defined(CONFIG_X86)
> + if (!IS_ALIGNED(port, count))
> + return -EFAULT;
> + #endif
> if (write)
> outl(*(u32 *)buf, port);
> else
On Thu, 8 Jan 2026, David Laight wrote: > I'm not sure it makes any real sense for x86 either. FWIW I agree. > IIRC io space is just like memory space, so a 16bit io access looks the > same as two 8bit accesses to an 8bit device (some put the 'data fifo' on > addresses 0 and 1 so the code could use 16bit io accesses to speed things up). Huh? A 16-bit port I/O access will have the byte enables set accordingly on PCI and the target device's data lines are driven accordingly in the data cycle. Just as with MMIO; it's just a different bus command (or TLP type for PCIe). There's no data FIFO or anything as exotic in normal hardware to drive or collect data for port I/O accesses wider than 8 bits. Some peripheral hardware may ignore byte enables though to simplify logic and e.g. assume that all port I/O or MMIO accesses are of a certain width, such as 16-bit or 32-bit. > The same will have applied to misaligned accesses. Misaligned accesses may or may not have to be split depending on whether they span the data bus width boundary or not. E.g. a 16-bit access to port I/O location 1 won't be split on 32-bit PCI as it fits on the bus: byte enables #1 and #2 will be driven active and byte enables #0 and #3 will be left inactive. Conversely such an access to location 3 needs to be split into two cycles, with byte enables #3 and #0 only driven active respectively in the first and the second cycle. The x86 BIU will do the split automatically for port I/O instructions as will some other CPU architectures that use memory access instructions to reach the PCI port I/O decoding window in their memory address space (this is a simplified view, as the split may have to be done in the chipset when passing the boundary between data buses of a different width each). With other architectures such as MIPS designated instructions need to be used to drive the byte enables by hand for individual partial accesses in a split access, and the remaining architectures cannot drive some of the byte-enable patterns needed for such split accesses at all (and do masking in software instead for unaligned accesses to regular memory). > But, in reality, all device registers are aligned. True, sometimes beyond their width too. Maciej
On Fri, 9 Jan 2026 00:38:05 +0000 (GMT) "Maciej W. Rozycki" <macro@orcam.me.uk> wrote: > On Thu, 8 Jan 2026, David Laight wrote: > > > I'm not sure it makes any real sense for x86 either. > > FWIW I agree. The interface could have allowed arbitrary transfers and split them into aligned bus cycles. That would let you hexdump an io bar (useful for diagnostics, but some reads end up being destructive - caveat emptor). But it doesn't.... It is also of limited use because (IIRC) you can't access the device this way once a driver has mapped the bar. The driver can, of course, support applications using mmap() to directly access device memory over PCIe. (The difficulty is mmap() of kernel memory allocated with dma_alloc_coherent().) > > IIRC io space is just like memory space, so a 16bit io access looks the > > same as two 8bit accesses to an 8bit device (some put the 'data fifo' on > > addresses 0 and 1 so the code could use 16bit io accesses to speed things up). > > Huh? A 16-bit port I/O access will have the byte enables set accordingly > on PCI and the target device's data lines are driven accordingly in the > data cycle. Just as with MMIO; it's just a different bus command (or TLP > type for PCIe). I was going back to the historic implementations - like 8086 and 8088. For pcie I know it is all different and the cpu just generates read/write TLP with the required byte enables and the tlp type marked 'io'. (I can't remember whether IO writes end up 'not posted' - failed to find it in a 5cm thick book on my shelf.) > There's no data FIFO or anything as exotic in normal hardware to drive or > collect data for port I/O accesses wider than 8 bits. Some peripheral > hardware may ignore byte enables though to simplify logic and e.g. assume > that all port I/O or MMIO accesses are of a certain width, such as 16-bit > or 32-bit. Not to mention an fpga fabric that converted the TLP for an (aligned) 32bit access into a pair of 32bit accesses - one of which had no byte enables set! Confused the hw engineers who had ignored the byte enables... > > The same will have applied to misaligned accesses. > > Misaligned accesses may or may not have to be split depending on whether > they span the data bus width boundary or not. E.g. a 16-bit access to > port I/O location 1 won't be split on 32-bit PCI as it fits on the bus: > byte enables #1 and #2 will be driven active and byte enables #0 and #3 > will be left inactive. Conversely such an access to location 3 needs to > be split into two cycles, with byte enables #3 and #0 only driven active > respectively in the first and the second cycle. And on PCIe (which is 64bit) a misaligned transfer that crosses a 64bit boundary generates a single 16 byte TLP (not sure about page boundaries). > The x86 BIU will do the split automatically for port I/O instructions as > will some other CPU architectures that use memory access instructions to > reach the PCI port I/O decoding window in their memory address space (this > is a simplified view, as the split may have to be done in the chipset when > passing the boundary between data buses of a different width each). Yes, and I don't understand the HAS_IOPORT option. Pretty much only x86 has separate instructions, but a lot of others will have PCI/PCIe interface logic that can convert cpu memory accesses into 'io' accesses - so the pci_map_bar() should be able to transparently map an io bar into kernel address space. So x86 should be the outlier because it can't do that! Even the strongarm system I used years ago has an address window that generated 'io' cycles on a pcmcia bus. I think a host PCI/PCIe interface could do io accesses for the bottom 64k of its memory window - but I don't know any that work that way. > > With other architectures such as MIPS designated instructions need to be > used to drive the byte enables by hand for individual partial accesses in > a split access, and the remaining architectures cannot drive some of the > byte-enable patterns needed for such split accesses at all (and do masking > in software instead for unaligned accesses to regular memory). > > > But, in reality, all device registers are aligned. > > True, sometimes beyond their width too. Which means you don't want the multiple cycles that happen when someone marks a structure as 'packed' even though it is completely aligned. David > > Maciej >
On Fri, 9 Jan 2026, David Laight wrote:
> > > IIRC io space is just like memory space, so a 16bit io access looks the
> > > same as two 8bit accesses to an 8bit device (some put the 'data fifo' on
> > > addresses 0 and 1 so the code could use 16bit io accesses to speed things up).
> >
> > Huh? A 16-bit port I/O access will have the byte enables set accordingly
> > on PCI and the target device's data lines are driven accordingly in the
> > data cycle. Just as with MMIO; it's just a different bus command (or TLP
> > type for PCIe).
>
> I was going back to the historic implementations - like 8086 and 8088.
Historical systems had various odd bus designs that are out of scope for
our consideration. Even the 80386, but that was never interfaced to PCI,
perhaps for this very reason.
> > Misaligned accesses may or may not have to be split depending on whether
> > they span the data bus width boundary or not. E.g. a 16-bit access to
> > port I/O location 1 won't be split on 32-bit PCI as it fits on the bus:
> > byte enables #1 and #2 will be driven active and byte enables #0 and #3
> > will be left inactive. Conversely such an access to location 3 needs to
> > be split into two cycles, with byte enables #3 and #0 only driven active
> > respectively in the first and the second cycle.
>
> And on PCIe (which is 64bit) a misaligned transfer that crosses a 64bit
> boundary generates a single 16 byte TLP (not sure about page boundaries).
Which is also what is covered (without diving into exact details) by my
observation that a transfer may have to be split downstream, e.g. by a
PCIe-to-PCI bridge, or internally by the target device.
> > The x86 BIU will do the split automatically for port I/O instructions as
> > will some other CPU architectures that use memory access instructions to
> > reach the PCI port I/O decoding window in their memory address space (this
> > is a simplified view, as the split may have to be done in the chipset when
> > passing the boundary between data buses of a different width each).
>
> Yes, and I don't understand the HAS_IOPORT option.
> Pretty much only x86 has separate instructions, but a lot of others will
> have PCI/PCIe interface logic that can convert cpu memory accesses into
> 'io' accesses - so the pci_map_bar() should be able to transparently map
> an io bar into kernel address space.
> So x86 should be the outlier because it can't do that!
>
> Even the strongarm system I used years ago has an address window that
> generated 'io' cycles on a pcmcia bus.
>
> I think a host PCI/PCIe interface could do io accesses for the bottom
> 64k of its memory window - but I don't know any that work that way.
Only x86 (and its predecessors such as 8080, Z80, etc.) has the port I/O
space defined at the CPU bus level. All the other architectures do define
the port I/O space, but only in the chipset at the PCI/e bus/interconnect
level where implemented. It is where the HAS_IOPORT option is concerned.
Several contemporary systems have no way to produce port I/O cycles on
PCIe owing to the lack of support for the required TLP types in the host
bridge. There's simply no way to produce a transaction that would match
an I/O BAR in a target device. I own such a system myself, it's a POWER9
machine[1][2]. I'm told numerous ARM systems also have such a limitation.
FWIW port I/O TLP types have been deprecated from the beginning of PCIe.
References:
[1] "Power Systems Host Bridge 4 (PHB4) Specification", Version 1.0,
International Business Machines Corporation, 27 July 2018, Table 3-2.
"PCIe TLP command summary", p. 29.
[2] "pcmcia: add HAS_IOPORT dependencies",
<https://lore.kernel.org/r/alpine.DEB.2.21.2205041311280.9548@angie.orcam.me.uk/>.
Maciej
在 2026/1/8 16:56, David Laight 写道:
> On Thu, 8 Jan 2026 09:59:44 +0800
> Ziming Du <duziming2@huawei.com> wrote:
>
>> From: Yongqiang Liu <liuyongqiang13@huawei.com>
>>
>> Unaligned access is harmful for non-x86 archs such as arm64. When we
>> use pwrite or pread to access the I/O port resources with unaligned
>> offset, system will crash as follows:
>>
>> Unable to handle kernel paging request at virtual address fffffbfffe8010c1
>> Internal error: Oops: 0000000096000061 [#1] SMP
>> Call trace:
>> _outw include/asm-generic/io.h:594 [inline]
>> logic_outw+0x54/0x218 lib/logic_pio.c:305
>> pci_resource_io drivers/pci/pci-sysfs.c:1157 [inline]
>> pci_write_resource_io drivers/pci/pci-sysfs.c:1191 [inline]
>> pci_write_resource_io+0x208/0x260 drivers/pci/pci-sysfs.c:1181
>> sysfs_kf_bin_write+0x188/0x210 fs/sysfs/file.c:158
>> kernfs_fop_write_iter+0x2e8/0x4b0 fs/kernfs/file.c:338
>> vfs_write+0x7bc/0xac8 fs/read_write.c:586
>> ksys_write+0x12c/0x270 fs/read_write.c:639
>> __arm64_sys_write+0x78/0xb8 fs/read_write.c:648
>>
>> Powerpc seems affected as well, so prohibit the unaligned access
>> on non-x86 archs.
> I'm not sure it makes any real sense for x86 either.
> IIRC io space is just like memory space, so a 16bit io access looks the
> same as two 8bit accesses to an 8bit device (some put the 'data fifo' on
> addresses 0 and 1 so the code could use 16bit io accesses to speed things up).
> The same will have applied to misaligned accesses.
> But, in reality, all device registers are aligned.
>
> I'm not sure EFAULT is the best error code though, EINVAL might be better.
> (EINVAL is returned for other address/size errors.)
> EFAULT is usually returned for errors accessing the user buffer, a least
> one unix system raises SIGSEGV whenever EFAULT is returned.
>
> David
Just to confirm: should all architectures prohibit unaligned access to
device registers?
>> Fixes: 8633328be242 ("PCI: Allow read/write access to sysfs I/O port resources")
>> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
>> Signed-off-by: Ziming Du <duziming2@huawei.com>
>> ---
>> drivers/pci/pci-sysfs.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>> index 7e697b82c5e1..11d8b7ec4263 100644
>> --- a/drivers/pci/pci-sysfs.c
>> +++ b/drivers/pci/pci-sysfs.c
>> @@ -31,6 +31,7 @@
>> #include <linux/of.h>
>> #include <linux/aperture.h>
>> #include <linux/unaligned.h>
>> +#include <linux/align.h>
>> #include "pci.h"
>>
>> #ifndef ARCH_PCI_DEV_GROUPS
>> @@ -1166,12 +1167,20 @@ static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
>> *(u8 *)buf = inb(port);
>> return 1;
>> case 2:
>> + #if !defined(CONFIG_X86)
>> + if (!IS_ALIGNED(port, count))
>> + return -EFAULT;
>> + #endif
>> if (write)
>> outw(*(u16 *)buf, port);
>> else
>> *(u16 *)buf = inw(port);
>> return 2;
>> case 4:
>> + #if !defined(CONFIG_X86)
>> + if (!IS_ALIGNED(port, count))
>> + return -EFAULT;
>> + #endif
>> if (write)
>> outl(*(u32 *)buf, port);
>> else
On Thu, 8 Jan 2026, duziming wrote:
>
> 在 2026/1/8 16:56, David Laight 写道:
> > On Thu, 8 Jan 2026 09:59:44 +0800
> > Ziming Du <duziming2@huawei.com> wrote:
> >
> > > From: Yongqiang Liu <liuyongqiang13@huawei.com>
> > >
> > > Unaligned access is harmful for non-x86 archs such as arm64. When we
> > > use pwrite or pread to access the I/O port resources with unaligned
> > > offset, system will crash as follows:
> > >
> > > Unable to handle kernel paging request at virtual address fffffbfffe8010c1
> > > Internal error: Oops: 0000000096000061 [#1] SMP
> > > Call trace:
> > > _outw include/asm-generic/io.h:594 [inline]
> > > logic_outw+0x54/0x218 lib/logic_pio.c:305
> > > pci_resource_io drivers/pci/pci-sysfs.c:1157 [inline]
> > > pci_write_resource_io drivers/pci/pci-sysfs.c:1191 [inline]
> > > pci_write_resource_io+0x208/0x260 drivers/pci/pci-sysfs.c:1181
> > > sysfs_kf_bin_write+0x188/0x210 fs/sysfs/file.c:158
> > > kernfs_fop_write_iter+0x2e8/0x4b0 fs/kernfs/file.c:338
> > > vfs_write+0x7bc/0xac8 fs/read_write.c:586
> > > ksys_write+0x12c/0x270 fs/read_write.c:639
> > > __arm64_sys_write+0x78/0xb8 fs/read_write.c:648
> > >
> > > Powerpc seems affected as well, so prohibit the unaligned access
> > > on non-x86 archs.
> > I'm not sure it makes any real sense for x86 either.
> > IIRC io space is just like memory space, so a 16bit io access looks the
> > same as two 8bit accesses to an 8bit device (some put the 'data fifo' on
> > addresses 0 and 1 so the code could use 16bit io accesses to speed things
> > up).
> > The same will have applied to misaligned accesses.
> > But, in reality, all device registers are aligned.
> >
> > I'm not sure EFAULT is the best error code though, EINVAL might be better.
> > (EINVAL is returned for other address/size errors.)
> > EFAULT is usually returned for errors accessing the user buffer, a least
> > one unix system raises SIGSEGV whenever EFAULT is returned.
> >
> Just to confirm: should all architectures prohibit unaligned access to device
> registers?
In my opinion, yes, also x86 should prohibit it (like I already
expressed but you ignored that comment until now).
--
i.
> > > Fixes: 8633328be242 ("PCI: Allow read/write access to sysfs I/O port
> > > resources")
> > > Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
> > > Signed-off-by: Ziming Du <duziming2@huawei.com>
> > > ---
> > > drivers/pci/pci-sysfs.c | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > > index 7e697b82c5e1..11d8b7ec4263 100644
> > > --- a/drivers/pci/pci-sysfs.c
> > > +++ b/drivers/pci/pci-sysfs.c
> > > @@ -31,6 +31,7 @@
> > > #include <linux/of.h>
> > > #include <linux/aperture.h>
> > > #include <linux/unaligned.h>
> > > +#include <linux/align.h>
> > > #include "pci.h"
> > > #ifndef ARCH_PCI_DEV_GROUPS
> > > @@ -1166,12 +1167,20 @@ static ssize_t pci_resource_io(struct file *filp,
> > > struct kobject *kobj,
> > > *(u8 *)buf = inb(port);
> > > return 1;
> > > case 2:
> > > + #if !defined(CONFIG_X86)
> > > + if (!IS_ALIGNED(port, count))
> > > + return -EFAULT;
> > > + #endif
> > > if (write)
> > > outw(*(u16 *)buf, port);
> > > else
> > > *(u16 *)buf = inw(port);
> > > return 2;
> > > case 4:
> > > + #if !defined(CONFIG_X86)
> > > + if (!IS_ALIGNED(port, count))
> > > + return -EFAULT;
> > > + #endif
> > > if (write)
> > > outl(*(u32 *)buf, port);
> > > else
>
在 2026/1/9 15:21, Ilpo Järvinen 写道: > On Thu, 8 Jan 2026, duziming wrote: > >> 在 2026/1/8 16:56, David Laight 写道: >>> On Thu, 8 Jan 2026 09:59:44 +0800 >>> Ziming Du <duziming2@huawei.com> wrote: >>> >>>> From: Yongqiang Liu <liuyongqiang13@huawei.com> >>>> >>>> Unaligned access is harmful for non-x86 archs such as arm64. When we >>>> use pwrite or pread to access the I/O port resources with unaligned >>>> offset, system will crash as follows: >>>> >>>> Unable to handle kernel paging request at virtual address fffffbfffe8010c1 >>>> Internal error: Oops: 0000000096000061 [#1] SMP >>>> Call trace: >>>> _outw include/asm-generic/io.h:594 [inline] >>>> logic_outw+0x54/0x218 lib/logic_pio.c:305 >>>> pci_resource_io drivers/pci/pci-sysfs.c:1157 [inline] >>>> pci_write_resource_io drivers/pci/pci-sysfs.c:1191 [inline] >>>> pci_write_resource_io+0x208/0x260 drivers/pci/pci-sysfs.c:1181 >>>> sysfs_kf_bin_write+0x188/0x210 fs/sysfs/file.c:158 >>>> kernfs_fop_write_iter+0x2e8/0x4b0 fs/kernfs/file.c:338 >>>> vfs_write+0x7bc/0xac8 fs/read_write.c:586 >>>> ksys_write+0x12c/0x270 fs/read_write.c:639 >>>> __arm64_sys_write+0x78/0xb8 fs/read_write.c:648 >>>> >>>> Powerpc seems affected as well, so prohibit the unaligned access >>>> on non-x86 archs. >>> I'm not sure it makes any real sense for x86 either. >>> IIRC io space is just like memory space, so a 16bit io access looks the >>> same as two 8bit accesses to an 8bit device (some put the 'data fifo' on >>> addresses 0 and 1 so the code could use 16bit io accesses to speed things >>> up). >>> The same will have applied to misaligned accesses. >>> But, in reality, all device registers are aligned. >>> >>> I'm not sure EFAULT is the best error code though, EINVAL might be better. >>> (EINVAL is returned for other address/size errors.) >>> EFAULT is usually returned for errors accessing the user buffer, a least >>> one unix system raises SIGSEGV whenever EFAULT is returned. >>> >> Just to confirm: should all architectures prohibit unaligned access to device >> registers? > In my opinion, yes, also x86 should prohibit it (like I already > expressed but you ignored that comment until now). Oops, I didn’t quite understand your opinion earlier :( >
© 2016 - 2026 Red Hat, Inc.