Re: 2.6.11-rc2-mm1

[Dmitry Torokhov]

On Wed, 26 Jan 2005 23:07:12 +0300, Evgeniy Polyakov
<johnpol@xxxxxxxxxxx> wrote:
> 
> Chip driver provides access methods to the attached logical devices.
> It probes and activates them, if appropriate module is loaded.
> 
> Your example again is not suitable for superio case.
> 
> With superio you have several identical logical devices, access to which
> is absolutely standard in second level(logic befind access),
> but in first one(physicall access) it can differ.
> 
> So here is the real example of superio usage:
> 
>     userspace
>        |
>    superio core
>      ......
> 
>       GPIO
>  |----|  |--|
> pc87366     sc1100
>  |----| |---|
>       WDT
> 
> Logical device GPIO is accessed by read/write methods, which only have
> pin number(it is not how this methods are exactly implemeted though)
> as parameter.
> 
> For example userspace accesses GPIO at sc1100 - it will be translated
> into read methods called from appropriate superio chip with appropriate
> parameters.
> 
> When we have multiple GPIO logical devices(each in it's own superio chip)
> it is more convenient to use just the same object.

I take an exception to that. I think useroace is not concerned with
topology and ownership of logical devices, the data is more important.
I.e. you need to know that some pin respons to CPU temperature but you
don't really care that it connected to it87 as opposed to some other
chip. Therefore I think that ldev should translate to exactly the same
underlying object. Consider the picture below:

        GPIO0     GPIO1   GPIO2 GPIO3
          |         |       |     |
       pc87266   sc1100     blah123
          |         |
         WDT0      WDT1

This will allow:
- map every hardware piece (not entire chip, separate functions) to a
device file to userspace can use standard read/write/select/poll if
choses so.
- easily represent them in sysfs and also allow userspace access to
individual bits through sysfs attributes.
- will not give headaches with poer management when half of device is
powered down and half is active.
- provided that there are alternative interfaces outlined above
superio can be decoupled from the connector.

I wonder if it should be called "gpio" bus as opposed to superio
because only chips are "super", the bus consists of very simple
devices and drivers.

> I did not understand you from the beginning...

We are getting there I believe ;) 

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