> > >> > Loading f71805f on sparc64 causes hard reboot beacuse on invalid
> > >> > hardware access. Should this driver be restricted to PC, or some wider
> > >> > subset of platforms where this LPC SUper-IO chip is present?
> > >>
> > >> Which tree is f71805f in? Not in Linus'.
> > >
> > > Running upstream 3.4.0-09547-gfb21aff and it is there as
> > > SENSORS_F71805F.
> > >
> > > In fact, there are more LPC hwmon drivers that people can use to "shoot
> > > themselves in the leg" - SMSC LPC*, SMSC SCH*, SMSC DME1737 (partly I2C,
> > > partly ISA IO), and Fintek F71882FG and compatibles. Maybe more.
> > 
> > Sorry, I thought it was a git SHA1 commit ID.
> > Didn't know hardware manufacturers christen their chips to the abbreviated
> > commit ID in their VHDL repository ;-)
> > 
> > Indeed, it seems commit 746cdfbf01c0a30d59f6e1b6942d432658d7c7cd
> > ("hwmon: Avoid building drivers for powerpc that read/write ISA addresses")
> > was a bit too limited...
> 
> I am fine extending that commit to other architectures. Now the
> question is, do we just add SPARC64 to the exception list, or do we
> restrict these drivers to X86? I know they are mostly used on X86, but
> I have no proof they aren't used on other architectures. That's why
> Dean and myself decided to play it safe at first and only exclude PPC.
> 
> Apparently other drivers (e.g. watchdog drivers) for similar chips are
> limited to X86 so we might as well do the same here. And see if anybody
> complains...
> 
> Meelis, do you feel like sending a patch, or do you prefer if I take
> care of it?

I can send a patch in a couple of days, but I do not know either wihich 
way is better.

What other architectures can use the ISA-IO style LPC - probably quite 
several if hardware has been made (but it probably hasn't)?

-- 
Meelis Roos (mroos@ut.ee)      http://www.cs.ut.ee/~mroos/