Uwe Bonnes wrote:
>
> >>>>> "im" == Tim Waugh <twaugh@redhat.com> writes:
>
> im> On Sun, Mar 18, 2001 at 06:41:13PM +0100, Uwe Bonnes wrote:
>
> >> However a cleaner solution would be i.m.h.o. to have a /proc/superio
> >> entry, that exports the relevant information (manufacturer, ioport
> im> I'd rather not add even more bloat to that file. If we had to keep
> im> this information around, it would go in /proc/sys/dev/parport/*/,
> im> but I don't think it's really needed.
>
> Well, these Super IO chips not only affect Parport. So this would be a new
> directory in the ../linux/drivers -tree, like drivers/pnp.
>
> I am trying to implement something like this:
>
> /proc/superio/superio: Lists available Superio Chips
> /proc/superio/0: Entry for first chip
> /proc/superio/1: Entry for second chip
...
> Writing on some items would be allowed in some situations, like
> "echo "ppaddr 278" >/proc/superio/0
> would change the parallel port address, if the old adress isn't actual used.
>
> Exporting the Super IO Chip registers and decoding these in a user programm
> would be another possibility. However I feel bad about letting the user
> program write random registers...
>
Don't overdesign the kernel superio interface, my original intent
was to detect IRQ and DMA for parport.
(This has been nearly obsoleted by my lastest PNPBIOS and ACPI patches.)
I would prefer to do as much superio works by a user mode application
(ls_superio, set_superio). This would enable the user to see all settings
like lspci and changing (root only) like setpci.
There will not be much benefit for other device drivers (I think just IrDA here,
which has it's own superio code already).
-
Regards, Gunther
P.S.
Tim, check_region is fine with me.
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Tue Mar 20 2001 - 13:10:20 EST