search for: read32

...oper value. Hey Pierre, This patch is incorrect. As Robert pointed out in an older thread, the registers don't take the physical address of a page, but a somewhat odd "negative offset from the end of carveout". See this example (referring to Robert's last email): 220.926392 read32 #3 +0x00100e10 -> 0x00070000 220.926406 read32 #3 +0x00100e14 -> 0x00010000 carveout_base = 0x70000000 carveout_size = 0x10000000 -- snip -- 223.300495 read32 #3 +0x00100c14 -> 0x00000000 223.300521 read32 #3 +0x00100c18 -> 0x00000000 223.300547 write32 #3 +0x00100c18 <...

...TYPE_STRING }, + { "CLONE_OFFSET", TYPE_INT }, + { "CLONE_LEN", TYPE_INT } +}; +#define MAX_ATTRS (sizeof(attrs) / sizeof(struct attr_types)) + +uint16_t +read16(const void *d) +{ + const uint8_t *data = d; + + return data[0] + (1 << 8) * (uint16_t)data[1]; +} + +uint32_t +read32(const void *d) +{ + const uint8_t *data = d; + + return read16(data) + (1 << 16) * (uint32_t)read16(data + 2); +} + +uint64_t +read64(const void *d) +{ + const uint8_t *data = d; + + return read32(data) + (1ull << 32) * (uint64_t)read32(data + 2); +} + +/* + * Extracted from the linux...

Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau_drm.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c index afb93bb..ffa1e4f 100644 --- a/drm/nouveau_drm.c +++ b/drm/nouveau_drm.c @@ -61,9 +61,10 @@ MODULE_PARM_DESC(debug, "debug string to pass to driver core"); static char

..._v |= ((const uint8_t *)_p)[1] << 8; return _v; } static inline void write16(le16_t *_p, uint16_t _v) { - _p[0] = _v & 0xFF; - _p[1] = (_v >> 8) & 0xFF; + ((uint8_t *)_p)[0] = _v & 0xFF; + ((uint8_t *)_p)[1] = (_v >> 8) & 0xFF; } static inline unsigned int read32(le32_t *_p) { - _v = _p[0]; - _v |= _p[1] << 8; - _v |= _p[2] << 16; - _v |= _p[3] << 24; + uint32_t _v; + + _v = ((const uint8_t *)_p)[0]; + _v |= ((const uint8_t *)_p)[1] << 8; + _v |= ((const uint8_t *)_p)[2] << 16; + _v |= ((const uint8_t *)_p)[3] <&l...

This should allow testing when QEMU gets VIRTIO_PCI_CAP_PCI_CFG support, but I'm pretty sure we should never allow these patches upstream. Tested with lguest (in virtio-next), which supports VIRTIO_PCI_CAP_PCI_CFG. Rusty Russell (2): virtio_pci: abstract all MMIO accesses. virtio: Introducing virtio_pci.no_mmio, the worst boot option in history. drivers/virtio/virtio_pci_common.c |

This should allow testing when QEMU gets VIRTIO_PCI_CAP_PCI_CFG support, but I'm pretty sure we should never allow these patches upstream. Tested with lguest (in virtio-next), which supports VIRTIO_PCI_CAP_PCI_CFG. Rusty Russell (2): virtio_pci: abstract all MMIO accesses. virtio: Introducing virtio_pci.no_mmio, the worst boot option in history. drivers/virtio/virtio_pci_common.c |

...ead16(const void __iomem *xaddr) { unsigned long addr = (unsigned long) xaddr; unsigned long result, base_and_type; @@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem *xaddr) *(vuip) ((addr << 5) + base_and_type) = w; } -__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr) +__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr) { unsigned long addr = (unsigned long) xaddr; if (addr < APECS_DENSE_MEM) diff --git a/arch/alpha/include/asm/core_cia.h b/arch/alpha/include/asm/core_cia.h index c706a7f2b061..cb22991f6761 100644 -...

...ead16(const void __iomem *xaddr) { unsigned long addr = (unsigned long) xaddr; unsigned long result, base_and_type; @@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem *xaddr) *(vuip) ((addr << 5) + base_and_type) = w; } -__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr) +__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr) { unsigned long addr = (unsigned long) xaddr; if (addr < APECS_DENSE_MEM) diff --git a/arch/alpha/include/asm/core_cia.h b/arch/alpha/include/asm/core_cia.h index c706a7f2b061..cb22991f6761 100644 -...

...ead16(const void __iomem *xaddr) { unsigned long addr = (unsigned long) xaddr; unsigned long result, base_and_type; @@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem *xaddr) *(vuip) ((addr << 5) + base_and_type) = w; } -__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr) +__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr) { unsigned long addr = (unsigned long) xaddr; if (addr < APECS_DENSE_MEM) diff --git a/arch/alpha/include/asm/core_cia.h b/arch/alpha/include/asm/core_cia.h index c706a7f2b061..cb22991f6761 100644 -...

...eally stopping all of them to take pointer to const. Patchset was only compile tested on affected architectures. No real testing. volatile ======== There is still interface inconsistency between architectures around "volatile" qualifier: - include/asm-generic/io.h:static inline u32 ioread32(const volatile void __iomem *addr) - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem *); This is still discussed and out of scope of this patchset. Best regards, Krzysztof Krzysztof Kozlowski (4): iomap: Constify ioreadX() iomem argument (as in generic implem...

http://defect.opensolaris.org/bz/show_bug.cgi?id=1986 Summary: ''zfs destroy'' hangs on encrypted dataset Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: other

...set was not really tested on all affected architectures. Build testing is in progress - I hope auto-builders will point any issues. volatile ======== There is still interface inconsistency between architectures around "volatile" qualifier: - include/asm-generic/io.h:static inline u32 ioread32(const volatile void __iomem *addr) - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem *); This is still discussed and out of scope of this patchset. Merging ======= Multiple architectures are affected in first patch so acks are welcomed. Patches 2-4 depend on first p...

...eally stopping all of them to take pointer to const. Patchset was only compile tested on affected architectures. No real testing. volatile ======== There is still interface inconsistency between architectures around "volatile" qualifier: - include/asm-generic/io.h:static inline u32 ioread32(const volatile void __iomem *addr) - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem *); This is still discussed and out of scope of this patchset. Merging ======= Multiple architectures are affected in first patch so acks are welcomed. 1. All patches depend on firs...

...eally stopping all of them to take pointer to const. Patchset was only compile tested on affected architectures. No real testing. volatile ======== There is still interface inconsistency between architectures around "volatile" qualifier: - include/asm-generic/io.h:static inline u32 ioread32(const volatile void __iomem *addr) - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem *); This is still discussed and out of scope of this patchset. Merging ======= Multiple architectures are affected in first patch so acks are welcomed. 1. All patches depend on firs...

...eally stopping all of them to take pointer to const. Patchset was only compile tested on affected architectures. No real testing. volatile ======== There is still interface inconsistency between architectures around "volatile" qualifier: - include/asm-generic/io.h:static inline u32 ioread32(const volatile void __iomem *addr) - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem *); This is still discussed and out of scope of this patchset. Merging ======= Multiple architectures are affected in first patch so acks are welcomed. 1. All patches depend on firs...

Hi, The ioread8/16/32() and others have inconsistent interface among the architectures: some taking address as const, some not. It seems there is nothing really stopping all of them to take pointer to const. Patchset was really tested on all affected architectures. Build testing is in progress - I hope auto-builders will point any issues. Todo ==== Convert also string versions (ioread16_rep()

Hi, The ioread8/16/32() and others have inconsistent interface among the architectures: some taking address as const, some not. It seems there is nothing really stopping all of them to take pointer to const. Patchset was really tested on all affected architectures. Build testing is in progress - I hope auto-builders will point any issues. Todo ==== Convert also string versions (ioread16_rep()

Hi, The ioread8/16/32() and others have inconsistent interface among the architectures: some taking address as const, some not. It seems there is nothing really stopping all of them to take pointer to const. Patchset was really tested on all affected architectures. Build testing is in progress - I hope auto-builders will point any issues. Todo ==== Convert also string versions (ioread16_rep()

I''ve recently re-installed an X4500 running Nevada b109 and have been experiencing ZFS lock ups regularly (perhaps once every 2-3 days). The machine is a backup server and receives hourly ZFS snapshots from another thumper - as such, the amount of zfs activity tends to be reasonably high. After about 48 - 72 hours, the file system seems to lock up and I''m unable to do anything

Now at 36 hours since zdb process start and: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 827 root 4936M 4931M sleep 59 0 0:50:47 0.2% zdb/209 Idling at 0.2% processor for nearly the past 24 hours... feels very stuck. Thoughts on how to determine where and why? -- This message posted from opensolaris.org