[PATCH 07/10] IOCHK interface for I/O error handling/detecting
Hidetoshi Seto
seto.hidetoshi at jp.fujitsu.com
Fri Jun 10 20:29:58 EST 2005
Hi David,
David Mosberger wrote:
>>>>>>On Thu, 09 Jun 2005 21:58:26 +0900, Hidetoshi Seto <seto.hidetoshi at jp.fujitsu.com> said:
>
> Hidetoshi> +/*
> Hidetoshi> + * Some I/O bridges may poison the data read, instead of
> Hidetoshi> + * signaling a BERR. The consummation of poisoned data
> Hidetoshi> + * triggers a local, imprecise MCA.
> Hidetoshi> + * Note that the read operation by itself does not consume
> Hidetoshi> + * the bad data, you have to do something with it, e.g.:
> Hidetoshi> + *
> Hidetoshi> + * ld.8 r9=[r10];; // r10 == I/O address
> Hidetoshi> + * add.8 r8=r9,r9;; // fake operation
> Hidetoshi> + */
> Hidetoshi> +#define ia64_poison_check(val) \
> Hidetoshi> +{ register unsigned long gr8 asm("r8"); \
> Hidetoshi> + asm volatile ("add %0=%1,r0" : "=r"(gr8) : "r"(val)); }
> Hidetoshi> +
> Hidetoshi> #endif /* CONFIG_IOMAP_CHECK */
>
> I have only looked that this briefly and I didn't see off hand where you get
> the "r9=[r10]" sequence from --- I hope you're not relying on the compiler
> happening to generate this sequence!
+static inline unsigned char
+___ia64_readb (const volatile void __iomem *addr)
+{
+ unsigned char val;
+
+ val = *(volatile unsigned char __force *)addr;
+ ia64_poison_check(val);
+
+ return val;
+}
Assigning value from addr to variable val stands for "ld", is it right?
What I want to do here is making sure that ld actually finishs loading data
from memory or mmaped register or far place to general register, and make
sure that the data is healthy enough to operate, not poisoned.
> More importantly: please avoid inline "asm" and use the intrinsics
> defined by gcc_intrin.h instead (if you need something new, we can add
> that), but I think ia64_getreg() will do much of what you want already.
Umm, I think I need something like ia64_setreg(ANYWHERE_DUMMY_REG, val).
How do you think?
Or don't you mind if I move the definition of ia64_poison_check above to
gcc_intrin.h?
Thanks,
H.Seto
More information about the Linuxppc64-dev
mailing list