commit f5f96cdad153566dbca9dcfdcf36245319968b0a
Author: Shérab <Sebastien.Hinderer@ens-lyon.org>
Date:   Wed Aug 25 11:39:42 2010 +0200

    Eurobraille/Iris power off.
    
    The Iris machines from EuroBraille do not have APM or ACPI support
    to shut themselves down properly.  A special I/O sequence is
    needed to do so.  This modle runs this I/O sequence at
    kernel shutdown.
    
    This is only for Iris machines from EuroBraille.
    Signed-off-by: Shérab <Sebastien.Hinderer@ens-lyon.org>

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ac7827f..88bf897 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -493,6 +493,19 @@ config X86_ES7000
 	  Support for Unisys ES7000 systems.  Say 'Y' here if this kernel is
 	  supposed to run on an IA32-based Unisys ES7000 system.
 
+config X86_32_IRIS
+	tristate "Eurobraille/Iris poweroff module"
+	depends on X86_32
+	---help---
+	  The Iris machines from EuroBraille do not have APM or ACPI support
+	  to shut themselves down properly.  A special I/O sequence is
+	  needed to do so, which is what this module does at
+	  kernel shutdown.
+
+	  This is only for Iris machines from EuroBraille.
+
+	  If unused, say N.
+
 config SCHED_OMIT_FRAME_POINTER
 	def_bool y
 	prompt "Single-depth WCHAN output"
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0925676..98dd1c8 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -115,6 +115,7 @@ obj-$(CONFIG_MICROCODE)			+= microcode.o
 obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
 
 obj-$(CONFIG_SWIOTLB)			+= pci-swiotlb.o
+obj-$(CONFIG_X86_32_IRIS)		+= iris.o
 
 ###
 # 64 bit specific files
diff --git a/arch/x86/kernel/iris.c b/arch/x86/kernel/iris.c
new file mode 100644
index 0000000..7c8a942
--- /dev/null
+++ b/arch/x86/kernel/iris.c
@@ -0,0 +1,66 @@
+/*
+ * Eurobraille/Iris power off support.
+ *
+ * Eurobraille's Iris machine is a PC with no APM or ACPI support.
+ * It is shutdown by a special I/O ...
[ message continues ]

According to
www.multitech.com/en_us/news/articles/success_stories/eurobraille.pdf :

"EURObraille’s latest invention is the IRIS portable assistant.
 The use of a powerful microprocessor coupled with the most advanced
 Microsoft Windows operating system provides the blind with a powerful
 computing solution"

What version of Microsoft Windows ships on this box?
Does it run in ACPI mode?  Does it power-off successfully?

Does Linux run in ACPI mode?
Please send along the dmesg from a Linux kernel built with:

CONFIG_ACPI=y
CONFIG_ACPI_DEBUG=y

thanks,
Len Brown, Intel Open Source Technology Center
[ message continues ]

I don't know and I don't think it would be possible to determine it,
since one just has access to a dedicated application and not to the



It's attached.

Thanks,
Shérab.
[ message continues ]

What about APM?

	-hpa
--

[ message continues ]

--

[ message continues ]

Hello...

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--

[ message continues ]

Hi,


I couldn't compile the kernel with APM support.
I'm on master, APM depends on PM_SLEEP which I couldn't find in any
Kconfig file. So I added it by hand in.config and ran make menuconfig
again. This time the APM stuff was visible, so I could activate it,
but then compiling the kernel failed.
I'm sure I'm missing something and I'm sorry about that, if someone
could help that would be very appreciated.

Thanks,
Shérab.
--

[ message continues ]

Hi,


Not either, I think.
See attached dmesg output.
Shérab.
[ message continues ]

Dear all,

This thread has been sleeping for a few days now so I'm trying to wake
it up.

Brief summary: the included patch provides an iris module with a power
off function for a machine that, as has already been seen, has no APM,
no ACPI and no DMI.

The output of lspci -vv -n is included again.

Thanks for your attention,
Shérab.

00:00.0 0600: 1078:0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0

00:02.0 0200: 1282:9102 (rev 40)
	Subsystem: 0291:8212
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 165 (5000ns min, 10000ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 1000 [size=256]
	Region 1: Memory at fedfe000 (32-bit, non-prefetchable) [size=256]
	[virtual] Expansion ROM at 08000000 [disabled] [size=256K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=160mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: dmfe

00:12.0 0601: 1078:0100 (rev 30)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 16 bytes

00:12.1 0680: 1078:0101
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at 40012000 (32-bit, non-prefetchable) [size=256]

00:12.2 0101: 1078:0102 (prog-if 80 [Master])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- ...
[ message continues ]

Is it actually safe to assume that this will do the right thing on a machine that
is a non-Iris that has something *else* at that I/O  address?  Any further sanity
checking we can do?  (For that matter, are there machines that will get indigestion
at this sort of unexpected inb() access?)
[ message continues ]

I have asked the manufacturer and will be happy to provide patches to

That, I don't know.

Shérab.
--

[ message continues ]

Yes, there are... since it's an address which can contain any kind of
I/O device.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--

[ message continues ]

No. The format of the value there is quite unknown, it's just quite sure
it won't be 0xff on the Iris.

Again, I'm not sure we really should try hard to make it automatically
detected (and thus always enabled).  Having to pass a kernel parameter
to enable the functionality is completely fine, since installing Linux
on this device requires quite some tinkering already.

Samuel
--

[ message continues ]

Could you describe this kind of tinkering?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--

[ message continues ]

Basically, opening the device to select boot on the external
CompactFlash reader.

Samuel
--

[ message continues ]

I'm agreeing that if iris_init() checks that the user passed 'irisinit.force=1'
on the command line or as a module parameter, and bailed immediately if it
wasn't passed, then doing the inb() and testing it should be safe enough. Doing
stuff that's only known safe on an Iris is no great sin if the user has said
"Yes, you're on a Iris" - at that point it's the user's fault.

static int iris_init(void)
{
	unsigned char status;

	if (!irisinit.force) return; /* or whatever the appropriate test is */

	status = inb(IRIS_GIO_INPUT);
	if (status == IRIS_GIO_NODEV) {
		printk(KERN_ERR "This machine does not seem to be an Iris. Power_off handler not installed.\n");
		return -ENODEV;
	}

That look safe enough to everybody?  That way, even if a distro turns on every
CONFIG_FOO that compiles (you guys know who you are ;), it should still DTRT on
all platforms.

[ message continues ]

Hi,


Fine. I'd be happy to submit another patch where the module takes a
force argument if that's okay to you guys.

Shérab.
--

[ message continues ]

Dear all,


Please find below a revised version of the module that does what has
been asked.

Cheers,
Shérab.

From c7d27a83ba8ec5e5c18f1ef02af4f740f4db1b7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sh=C3=A9rab?= <Sebastien.Hinderer@ens-lyon.org>
Date: Mon, 20 Sep 2010 10:15:16 +0200
Subject: [PATCH] Eurobraille/Iris power off.
 The Iris machines from EuroBraille do not have APM or ACPI support
 to shut themselves down properly.  A special I/O sequence is
 needed to do so.  This modle runs this I/O sequence at
 kernel shutdown when its force parameter is set to 1.
Content-Type: text/plain; charset="utf-8"

---
 arch/x86/Kconfig         |   13 +++++++
 arch/x86/kernel/Makefile |    1 +
 arch/x86/kernel/iris.c   |   90 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/kernel/iris.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cea0cd9..7c8e261 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -493,6 +493,19 @@ config X86_ES7000
 	  Support for Unisys ES7000 systems.  Say 'Y' here if this kernel is
 	  supposed to run on an IA32-based Unisys ES7000 system.
 
+config X86_32_IRIS
+	tristate "Eurobraille/Iris poweroff module"
+	depends on X86_32
+	---help---
+	  The Iris machines from EuroBraille do not have APM or ACPI support
+	  to shut themselves down properly.  A special I/O sequence is
+	  needed to do so, which is what this module does at
+	  kernel shutdown.
+
+	  This is only for Iris machines from EuroBraille.
+
+	  If unused, say N.
+
 config SCHED_OMIT_FRAME_POINTER
 	def_bool y
 	prompt "Single-depth WCHAN output"
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0925676..98dd1c8 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -115,6 +115,7 @@ obj-$(CONFIG_MICROCODE)			+= microcode.o
 obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
 
 obj-$(CONFIG_SWIOTLB)			+= pci-swiotlb.o
+obj-$(CONFIG_X86_32_IRIS)		+= ...
[ message continues ]

Hello,


The previous patch had a few style problem and the moduleparam.h header
was not included whereas it should have been.
The version below passes ./script/checkpatch and the missing header has
been included, so the patch should be correct now.
Moreover the patch has been updated to apply on top of current master.

Shérab.

From 2af50581bb591cd25ac59a7cf16902ea50f766db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sh=C3=A9rab?= <Sebastien.Hinderer@ens-lyon.org>
Date: Sat, 25 Sep 2010 06:06:57 +0200
Subject: [PATCH] Eurobraille/Iris power off.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"

The Iris machines from Eurobraille do not have APM or ACPI support
to shut themselves down properly.  A special I/O sequence is
needed to do so.  This modle runs this I/O sequence at
kernel shutdown when its force parameter is set to 1.
Signed-off-by: Shérab <Sebastien.Hinderer@ens-lyon.org>
---
 arch/x86/Kconfig         |   13 +++++++
 arch/x86/kernel/Makefile |    1 +
 arch/x86/kernel/iris.c   |   90 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/kernel/iris.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cea0cd9..7c8e261 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -493,6 +493,19 @@ config X86_ES7000
 	  Support for Unisys ES7000 systems.  Say 'Y' here if this kernel is
 	  supposed to run on an IA32-based Unisys ES7000 system.
 
+config X86_32_IRIS
+	tristate "Eurobraille/Iris poweroff module"
+	depends on X86_32
+	---help---
+	  The Iris machines from EuroBraille do not have APM or ACPI support
+	  to shut themselves down properly.  A special I/O sequence is
+	  needed to do so, which is what this module does at
+	  kernel shutdown.
+
+	  This is only for Iris machines from EuroBraille.
+
+	  If unused, say N.
+
 config SCHED_OMIT_FRAME_POINTER
 	def_bool y
 	prompt "Single-depth ...
[ message continues ]

Hi,

I'm resending and would appreciate it very much if someone good have a
lookto it.
Thanks,
Shérab.

--

[ message continues ]

Dear all,

I am resending this patch which got no criticisms and has stillnot been
integrated so far.

Many thanks in advance for examining it.

Cheers,

Shérab.

[ message continues ]