On Fri, Mar 12, 2010 at 01:32:23AM -0300, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > Hi Mauro,
> >
> > On Thu, Mar 11, 2010 at 12:46:19PM -0300, Mauro Carvalho Chehab wrote:
> >> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
