Re: [PATCH 07/10] IOCHK interface for I/O error handling/detecting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

David Mosberger wrote:
On Thu, 09 Jun 2005 21:58:26 +0900, Hidetoshi Seto <[email protected]> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux