[linux-dvb] Re: refactoring

[Gerd Knorr <kraxel@bytesex.org>]

> > Having a struct device* pointer within the new struct dvb_fe would be a
> > good thing.  dvb_register_frontend() can correctly register the physical
> > device for /sys/class/dvb/dvb.frontent then.
> 
> I'm not convinced representing the "frontend" as the demodulator's i2c_client 
> in sysfs is good, although I do agree we need *a* device in sysfs to 
> represent the frontend.

There are different types of objects in the sysfs tree, don't mix them
up:

There are the device _classes_ and the entries per device there.  Thats
the stuff which shows up below /sys/class, one node per device, where
"device" is a unix device, i.e. something with an major + minor which
can be accessed by opening /dev/foo.

There are physical devices, i.e. pci cards, usb devices, i2c clients,
whatever.  Thats something different, that is the tree below
/dev/devices.

The devices in /sys/class can have a link to the physical device.  In
the kernel structures that is just a pointer in struct class_device
pointing to a struct device, in sysfs it is visible as a symbolic link
named "device", like this:

eskarina kraxel /sys/class/video4linux/video0# ls -l
total 0
-r--r--r--  1 root root 4096 Oct 10 13:58 card
-r--r--r--  1 root root 4096 Oct 10 13:58 dev
lrwxrwxrwx  1 root root    0 Oct 10 13:58 device -> ../../../devices/pci0000:00/0000:00:06.0/0000:02:07.0/
lrwxrwxrwx  1 root root    0 Oct 10 13:58 driver -> ../../../bus/pci/drivers/bttv/
-r--r--r--  1 root root 4096 Oct 10 13:58 name

i2c_client has a "struct device" embedded, so if you have and register a
i2c_client _anyway_ (and I think it is a good idea to do that), you can
just register that as physical device for your (unix) frontend device as
well.  If your frontend isn't a i2c device -- well, no problem.  You can
use something else as well.  Pretty much every device structure in the
kernel (struct pci_dev, ...) has a generic "struct device" embedded.
The sysfs stuff hasn't any dependency to i2c here.

> Ideally, what I would want is to have the main DVB adapter, then under that, 
> DVB-specific frontend device(s) -  a new _type_ of device.

Hmm, not sure that this is possible to have multiple levels below
/sys/class.  Maybe we'll have to use /dev/sys/dvb_<subclass> for that,
simliar to scsi which has several scsi_* directories in there.

> Any frontend configuration files/power management stuff is then
> attached to those entries so that the card can bring up the frontend
> in its entirety in one go. This also allows for frontends attached to
> proprietary weirdy buses that have no standard kernel representation.

Wrong approach.  The powermanagement doesn't care about the /dev/class
tree (where you register the frontend (unix) device), it walks the
physical devices below /dev/devices.  And that is one of the reasons why
I think it is a good idea to have the i2c devices in the (physical)
device tree.

> To me, exposing the different bits making up the "frontend" is wrong - it 
> should conceptually just be the one device. If we expose the demodulator as 
> an i2c_client, then shouldn't we also expose all the other i2c devices for 
> consistency? (e.g. the PLL).

My cx22702 implementation actually has two i2c_clients, both visible as
(physical) devices in sysfs.

  Gerd

-- 
return -ENOSIG;