On Tue, Jul 16, 2019 at 08:32:04AM +0200, Thomas Petazzoni wrote: > Hello, > > On Mon, 15 Jul 2019 16:10:16 +0100 > Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> wrote: > > > > Also, the advk_pci_bridge_emul_pcie_conf_read() and > > > advk_pci_bridge_emul_pcie_conf_write() return values that are in the > > > CPU endianness. > > > > > > Am I missing something ? > > > > Getting the types correct and then using Sparse to validate the code > > will help to identify issues exactly like this. > > Yes, I absolutely agree with your recommendation on the other thread. > > In fact, I am wondering if it really makes sense to store the "fake" > config space in LE, since anyway the read/write accessors should return > values in the CPU endianness. Consider: u16 vendor; u16 device; and how they are laid out in LE and BE. Then consider what happens when you read "vendor" using a u32 accessor. This is where the problem lies. Using host endian means you'd have to read the members using an appropriately sized host access (in other words, not using a dword accessor) to end up with the correct result - but we don't want a large switch() statement here... -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
