On Fri, Mar 12, 2010 at 01:32:23AM -0300, Mauro Carvalho Chehab wrote:

Dmitry Torokhov wrote:

quoted

Hi Mauro,

On Thu, Mar 11, 2010 at 12:46:19PM -0300, Mauro Carvalho Chehab wrote:

quoted

In order to allow userspace programs to autoload an IR table, a link is
needed to point to the corresponding input device.

$ tree /sys/class/irrcv/irrcv0
/sys/class/irrcv/irrcv0
|-- current_protocol
|-- input -> ../../../pci0000:00/0000:00:0b.1/usb1/1-3/input/input22
|-- power
|   `-- wakeup
|-- subsystem -> ../../../../class/irrcv
`-- uevent

It is now easy to associate an irrcv device with the corresponding
device node, at the input interface.

I guess the question is why don't you make input device a child of your
irrcvX device? Then I believe driver core will link them properly. It
will also ensure proper power management hierarchy.

That probably will require you changing from class_dev into device but
that's the direction kernel is going to anyway.

Done, see enclosed. It is now using class_register/device_register. The
newly created device for irrcv is used as the parent for input_dev->dev.

The resulting code looked cleaner after the change ;)

It is indeed better, however I wonder if current hierarchy expresses the
hardware in best way. You currently have irrcv devices grow in parallel
with input devices whereas I would expect input devices be children of
irrcv devices:


	parent (PCI board, USB) -> irrcvX -> input1
                                          -> input2
					 ...

This way your PM sequence as follows - input core does its thing and
releases all pressed keys, etc, then you can shut off the receiver and
then board driver can shut doen the main piece. Otherwise irrcv0 suspend
may be racing with input suspend and so forth.

Thanks.

-- 
Dmitry