[2.6 patch] add SGI_IOC4 hardware dependencies

[2.6 patch] add SGI_IOC4 hardware dependencies

[Adrian Bunk]

Considering that all users of this code depend on
(IA64_SGI_SN2 || IA64_GENERIC) the SGI_IOC4 option
should also depend on it.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
6b2d1a0c7d1a46f6a99966a0454cb1feaa7f1562 diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 962817e..85888d2 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -62,7 +62,7 @@ config EEPROM_93CX6
 
 config SGI_IOC4
 	tristate "SGI IOC4 Base IO support"
-	depends on PCI
+	depends on PCI && (IA64_SGI_SN2 || IA64_GENERIC)
 	---help---
 	  This option enables basic support for the IOC4 chip on certain
 	  SGI IO controller cards (IO9, IO10, and PCI-RT).  This option

Re: [2.6 patch] add SGI_IOC4 hardware dependencies

[Brent Casavant]

On Sun, 13 Apr 2008, Adrian Bunk wrote:

> Considering that all users of this code depend on
> (IA64_SGI_SN2 || IA64_GENERIC) the SGI_IOC4 option
> should also depend on it.
> 
> Signed-off-by: Adrian Bunk <bunk@kernel.org>

Tony,

Please don't apply this yet.  I'll need some guidance from Adrian
and you on how to proceed.

The IOC4 chip _is_ available on a PCI card for x86 based systems.
And that is why I removed the dependence of the config option on
IA64_SGI_SN2 || IA64_GENERIC.

Unfortunately the only user of IOC4 on x86 is the "external interrupt"
IOC4 sub-driver which is available under the GPL, but was not accepted
into the Linux kernel.  I just realized that this driver is supplied
to SGI's customers (and they're free to modify and distribute it as
per the GPL -- there's no problems there), but I neglected to ever
make it available for download from http://oss.sgi.com.  I'll be happy
to fix that oversight.

On IA64 the IOC4 IDE and serial sub-drivers (in the mainline kernel), as
well as the external interrupt sub-driver (available seperately), are
available.

I'm not sure exactly how to approach this problem because the IOC4 is
a bit unique.  Since it is a single PCI device, I cannot register
entirely seperate device drivers for each of the three distinct
hardware functionalities it provides -- only a single driver can own the
PCI device.  At the same time, the one function for which we need the
card on x86 has its device driver maintained out-of-tree, so Adrian's
patch makes perfect sense from the purely in-kernel perspective.

History: Due to the odd nature of IOC4 hardware (and IOC3 for that matter),
I split off the low-level "here's how to drive the hardware" portion of
the external interrupt driver from the "here's the interface to user space"
portion, along with an interface between the two.  I submitted a patch for
this several years ago.  Of course, as you can probably predict, this was
panned as being far too complex for the one piece of hardware that uses it
-- which is true.

However, it does lay the groundwork for the MIPS folks to write the IOC3
sub-driver for external interrupts if they should so choose (IOC3 is used
on the Octane and certain Origin 2000 machines), and take advantage of the
user space portion of the external interrupt driver.  They've even asked
me a few questions about this at a few points in time.  Anyway, what we
end up with is a situation where the set of external interrupt drivers
isn't accepted into the mainline kernel, but SGI has in good faith made the
drivers available under the GPL.

So I'm kind of left in a difficult position with this one.  I understand
the desire to make the change Adrian offered, but it then makes it very
difficult to support the GPL'd external interrupt driver on x86.

Any guidance?

Brent

-- 
Brent Casavant                          All music is folk music.  I ain't
bcasavan@sgi.com                        never heard a horse sing a song.
Silicon Graphics, Inc.                    -- Louis Armstrong

RE: [2.6 patch] add SGI_IOC4 hardware dependencies

[Luck, Tony]

Brent,

I'll hold off on this.  Adrian's commit comment is incorrect (I
guess that he was unaware of the out of tree driver).  Making
life hard for an out of tree GPL driver doesn't sound like the
right direction for us to take.

-Tony

Re: [2.6 patch] add SGI_IOC4 hardware dependencies

[Adrian Bunk]

On Mon, Apr 14, 2008 at 02:40:37PM -0500, Brent Casavant wrote:
> On Sun, 13 Apr 2008, Adrian Bunk wrote:
> 
> > Considering that all users of this code depend on
> > (IA64_SGI_SN2 || IA64_GENERIC) the SGI_IOC4 option
> > should also depend on it.
> > 
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> 
> Tony,
> 
> Please don't apply this yet.  I'll need some guidance from Adrian
> and you on how to proceed.
> 
> The IOC4 chip _is_ available on a PCI card for x86 based systems.
> And that is why I removed the dependence of the config option on
> IA64_SGI_SN2 || IA64_GENERIC.
> 
> Unfortunately the only user of IOC4 on x86 is the "external interrupt"
> IOC4 sub-driver which is available under the GPL, but was not accepted
> into the Linux kernel.
>...

I wasn't aware of that driver.

Why wasn't it accepted?

> Brent

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] add SGI_IOC4 hardware dependencies

[Brent Casavant]

On Mon, 14 Apr 2008, Adrian Bunk wrote:

> On Mon, Apr 14, 2008 at 02:40:37PM -0500, Brent Casavant wrote:
> > On Sun, 13 Apr 2008, Adrian Bunk wrote:
> > 
> > > Considering that all users of this code depend on
> > > (IA64_SGI_SN2 || IA64_GENERIC) the SGI_IOC4 option
> > > should also depend on it.
> > > 
> > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > 
> > Tony,
> > 
> > Please don't apply this yet.  I'll need some guidance from Adrian
> > and you on how to proceed.
> > 
> > The IOC4 chip _is_ available on a PCI card for x86 based systems.
> > And that is why I removed the dependence of the config option on
> > IA64_SGI_SN2 || IA64_GENERIC.
> > 
> > Unfortunately the only user of IOC4 on x86 is the "external interrupt"
> > IOC4 sub-driver which is available under the GPL, but was not accepted
> > into the Linux kernel.
> >...
> 
> I wasn't aware of that driver.

No big deal.  It's not very well publicized, and as I mentioned I
overlooked making it easily available for download (we do make the
source available on physical media to everyone we send precompiled
binaries to).  I'm working on rectifying that oversight.

> Why wasn't it accepted?

The short answer is (to paraphrase) "the code is too complex for a
one-off device".

The linux-kernel thread regarding this begins with these three posts:

	http://marc.info/?l=linux-kernel&m\x112448872525388&w=2
	http://marc.info/?l=linux-kernel&m\x112448872506580&w=2
	http://marc.info/?l=linux-kernel&m\x112448872526711&w=2

(Don't look too hard at the code, it's been improved since then.  But
the general structure remains the same.)

Curiously enough I can't find the message where there were complaints
about it being too complex.  I wonder if those only came to me privately.
I was a bit more timid in my early lkml experience, and might have been
too easily dissuaded from pursuing this. Anyway. . .

In order to present a common method of interacting with external
interrupt hardware to user space (i.e. present a common set of
/sys/class/extint/*/* files and operations), I split the external
interrupt driver into two parts.  This was done so that not only would
the IOC4 chip would be supported, but so that if there was interest
someone else could write external interrupt support for the IOC3
chip, or use this same interface as a generic mechanism for any
similar device other parties may provide.

The first "low level" part is the section resposible for functioning
the underlying hardware.  The second "abstraction" part exports the
consistent user-visible portions (i.e. the /sys/class and /dev interfaces).
These two portions interact with one another to abstract away all
the nitty-gritty low-level details of the hardware, such that the
user doesn't have to be concerned with what hardware device is
at the bottom of the stack.  Sort of like how you don't worry which
Ethernet controller is being used when writing (most) networking
applications.

As you can imagine, this means there was a whole layer of interface
between the low-level and abstraction driver that was generalized to
handle the needs of both.  I submitted only a single low-level driver
(for IOC4) as part of the original patch set, as that's all I had
written.  The patch set was rejected because it was carrying around far
too much complexity/generality for the one device which would use it.

It's hard to argue that such complaints were invalid given what I'd
submitted. :)

Since then I've had the Linux MIPS folks ask me about this code at a
few points in time, as they might want to use it for the IOC3 present
on SGI's old Octane and Origin 2000 machines.  Also, as SGI moves onto
newer platforms we're investigating replacing the IOC4-based devices with
something else, hopefully that we don't have to build ourselves.  We
would certainly be looking to fit any such device into the existing
external interrupt framework.  At that point it would become a lot
easier to justify the additional complexity of the abstraction layer,
but sadly we're not there yet.

I hope that's some useful background.

Looking again at the feedback I received originally, I may just have
been too timid to push this for inclusion.  Perhaps I need to try
again with the latest and greatest.

Brent

-- 
Brent Casavant                          All music is folk music.  I ain't
bcasavan@sgi.com                        never heard a horse sing a song.
Silicon Graphics, Inc.                    -- Louis Armstrong