On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
> > > I have a slightly different concern - the superio is a completely new
> > > subsystem and it should be integtrated with the driver model
> > > ("superio" bus?). Right now it looks like it is reimplementing most of
> > > the abstractions (device lists, driver lists, matching, probing).
> > > Moving to driver model significatntly affects lifetime rules for the
> > > objects, etc. etc. and will definitely not allow code such as above.
> > >
> > > It would be nice it we get things right from the start.
> >
> > bus model is not good here - we need bus in each logical device and
> > bus in each superio chip(or at least second case).
> > Each bus bus have some crosslinking to devices in other buses,
> > and each new device
> > must be checked in each bus and probably added to each device...
> >
> > It is not like I see it.
> >
> > Consider folowing example:
> > each device from set A belongs to each device from set B.
> > n <-> n, it is not the case when one bus can handle all features.
> >
> > That is why I did not use driver model there.
> > It is specific design feature, which is proven to work.
> >
>
> Ok, I briefly looked over the patches and that is what I understand
> (please correct me where I am wrong):
>
> - you have superio chips which are containers providing set of interfaces;
> - you have superio chip driver that detects superio chip and manages
> (enables/disables) individual interfaces.
> - you have set of interface drivers (gpio, acb) that bind to individual
> superio interfaces and provide unified userspace interface that allows
> reading, writing and analog of ioctl.
>
> So the question is why you can't have superio bus where superio chips
> register their individual interfaces as individual devices. gpio, acb, etc
> are drivers that bind to superio devices and create class devices gpio.
>
> You could have:
>
> sys
> |-bus
> | |-superio
> | | |-devices
> | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> | | |-drivers
> | | | |-gpio
> | | | | |-sio1 ->
> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> | | | | |-sio2 ->
> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> | | | |-acb
> | | | | |-sio0 ->
> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> |
> |-class
> | |-gpio
> | | |-gpio0
> | | |-gpio1
>
> gpioX have control and data attributes that allow reading and writing...
>
> Am I missing something?
You try to create n <-> 1 relation, but superio by design supposed to be
n <-> n.
Above schema does not allow linking from each logical device to
appropriate superio chips
or vice versa - sc chips do not have link to it's logical devices.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
