Input: convert net/bluetooth to dynamic input_dev allocation
This is required for input_dev sysfs integration
Signed-off-by: Dmitry Torokhov <[email protected]>
---
net/bluetooth/hidp/core.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
Index: work/net/bluetooth/hidp/core.c
===================================================================
--- work.orig/net/bluetooth/hidp/core.c
+++ work/net/bluetooth/hidp/core.c
@@ -520,7 +520,7 @@ static int hidp_session(void *arg)
if (session->input) {
input_unregister_device(session->input);
- kfree(session->input);
+ session->input = NULL;
}
up_write(&hidp_session_sem);
@@ -536,6 +536,8 @@ static inline void hidp_setup_input(stru
input->private = session;
+ input->name = "Bluetooth HID Boot Protocol Device";
+
input->id.bustype = BUS_BLUETOOTH;
input->id.vendor = req->vendor;
input->id.product = req->product;
@@ -582,16 +584,15 @@ int hidp_add_connection(struct hidp_conn
return -ENOTUNIQ;
session = kmalloc(sizeof(struct hidp_session), GFP_KERNEL);
- if (!session)
+ if (!session)
return -ENOMEM;
memset(session, 0, sizeof(struct hidp_session));
- session->input = kmalloc(sizeof(struct input_dev), GFP_KERNEL);
+ session->input = input_allocate_device();
if (!session->input) {
kfree(session);
return -ENOMEM;
}
- memset(session->input, 0, sizeof(struct input_dev));
down_write(&hidp_session_sem);
@@ -651,8 +652,10 @@ unlink:
__hidp_unlink_session(session);
- if (session->input)
+ if (session->input) {
input_unregister_device(session->input);
+ session->input = NULL; /* don't try to free it here */
+ }
failed:
up_write(&hidp_session_sem);
Hi Dmitry,
> Input: convert net/bluetooth to dynamic input_dev allocation
>
> This is required for input_dev sysfs integration
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
on the condition your stuff got merged, then this patch is ok with me.
Signed-off-by: Marcel Holtmann <[email protected]>
Regards
Marcel
On 9/15/05, Marcel Holtmann <[email protected]> wrote:
> Hi Dmitry,
>
> > Input: convert net/bluetooth to dynamic input_dev allocation
> >
> > This is required for input_dev sysfs integration
> >
> > Signed-off-by: Dmitry Torokhov <[email protected]>
>
> on the condition your stuff got merged, then this patch is ok with me.
>
> Signed-off-by: Marcel Holtmann <[email protected]>
>
I was planning on getting patch 8 (preparation patch) into kernel ASAP
and then just sending individual subsystem patches to maintainers and
Andrew so they can merge at their leisure (but don't wait for too long
;))
--
Dmitry
Hi Dmitry,
> > > Input: convert net/bluetooth to dynamic input_dev allocation
> > >
> > > This is required for input_dev sysfs integration
> > >
> > > Signed-off-by: Dmitry Torokhov <[email protected]>
> >
> > on the condition your stuff got merged, then this patch is ok with me.
> >
> > Signed-off-by: Marcel Holtmann <[email protected]>
> >
>
> I was planning on getting patch 8 (preparation patch) into kernel ASAP
> and then just sending individual subsystem patches to maintainers and
> Andrew so they can merge at their leisure (but don't wait for too long
> ;))
I have no problem with you submitting the changes. If Vojtech is fine
with the proposed way, I would say that we get all of these changes into
mainline now. The device model integration is long overdue.
Regards
Marcel
On Thu, Sep 15, 2005 at 04:41:50PM +0200, Marcel Holtmann wrote:
> Hi Dmitry,
>
> > > > Input: convert net/bluetooth to dynamic input_dev allocation
> > > >
> > > > This is required for input_dev sysfs integration
> > > >
> > > > Signed-off-by: Dmitry Torokhov <[email protected]>
> > >
> > > on the condition your stuff got merged, then this patch is ok with me.
> > >
> > > Signed-off-by: Marcel Holtmann <[email protected]>
> > >
> >
> > I was planning on getting patch 8 (preparation patch) into kernel ASAP
> > and then just sending individual subsystem patches to maintainers and
> > Andrew so they can merge at their leisure (but don't wait for too long
> > ;))
>
> I have no problem with you submitting the changes. If Vojtech is fine
> with the proposed way, I would say that we get all of these changes into
> mainline now. The device model integration is long overdue.
I'm fine with it, yes. I'm not completely convinced that an input device
is really a class and not a device. ;) But I can understand that view.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On 9/15/05, Vojtech Pavlik <[email protected]> wrote:
> On Thu, Sep 15, 2005 at 04:41:50PM +0200, Marcel Holtmann wrote:
> > Hi Dmitry,
> >
> > > > > Input: convert net/bluetooth to dynamic input_dev allocation
> > > > >
> > > > > This is required for input_dev sysfs integration
> > > > >
> > > > > Signed-off-by: Dmitry Torokhov <[email protected]>
> > > >
> > > > on the condition your stuff got merged, then this patch is ok with me.
> > > >
> > > > Signed-off-by: Marcel Holtmann <[email protected]>
> > > >
> > >
> > > I was planning on getting patch 8 (preparation patch) into kernel ASAP
> > > and then just sending individual subsystem patches to maintainers and
> > > Andrew so they can merge at their leisure (but don't wait for too long
> > > ;))
> >
> > I have no problem with you submitting the changes. If Vojtech is fine
> > with the proposed way, I would say that we get all of these changes into
> > mainline now. The device model integration is long overdue.
>
> I'm fine with it, yes. I'm not completely convinced that an input device
> is really a class and not a device. ;) But I can understand that view.
They are devices - class devices :). I have the following distinction
in my head - "normal" devices (bus devices) are real hardware devices
and their drivers need to do resource and/or power management. Class
devices represent virtual devices - some kind of abstraction - that
unify and combine "real" devices from several buses into one class.
And of course nothing shoudl stop us from building class devices on
top of other class devices, if needed.
Anyway, I think if Greg gives up and agrees on nesting classes all of
it can go in -mm for now and I will contact other maintainers to
verify that changes work. IIRC video/dvb mainatiners prefered all
changes to go through them.
In any case I don't expect it reach Linus until after 2.6.14 released
- do you agree?
--
Dmitry
On Thu, Sep 15, 2005 at 02:22:34PM -0500, Dmitry Torokhov wrote:
>
> Anyway, I think if Greg gives up and agrees on nesting classes all of
> it can go in -mm for now and I will contact other maintainers to
> verify that changes work. IIRC video/dvb mainatiners prefered all
> changes to go through them.
No, I don't agree with this. Give me a day to write up what I think we
should do instead (something along the lines of "subclasses")
> In any case I don't expect it reach Linus until after 2.6.14 released
> - do you agree?
Oh, I agree this isn't 2.6.14 material :)
thanks,
greg k-h
On 9/15/05, Greg KH <[email protected]> wrote:
> On Thu, Sep 15, 2005 at 02:22:34PM -0500, Dmitry Torokhov wrote:
> >
> > Anyway, I think if Greg gives up and agrees on nesting classes all of
> > it can go in -mm for now and I will contact other maintainers to
> > verify that changes work. IIRC video/dvb mainatiners prefered all
> > changes to go through them.
>
> No, I don't agree with this. Give me a day to write up what I think we
> should do instead (something along the lines of "subclasses")
>
Hmm.. nested class _is_ a subclass. It is just not a separate object
structure (like you don't have sub-devices either). But I guess I
better wait fro your write-up...
--
Dmitry
On Thu, Sep 15, 2005 at 02:22:34PM -0500, Dmitry Torokhov wrote:
> On 9/15/05, Vojtech Pavlik <[email protected]> wrote:
> > On Thu, Sep 15, 2005 at 04:41:50PM +0200, Marcel Holtmann wrote:
> > > Hi Dmitry,
> > >
> > > > > > Input: convert net/bluetooth to dynamic input_dev allocation
> > > > > >
> > > > > > This is required for input_dev sysfs integration
> > > > > >
> > > > > > Signed-off-by: Dmitry Torokhov <[email protected]>
> > > > >
> > > > > on the condition your stuff got merged, then this patch is ok with me.
> > > > >
> > > > > Signed-off-by: Marcel Holtmann <[email protected]>
> > > > >
> > > >
> > > > I was planning on getting patch 8 (preparation patch) into kernel ASAP
> > > > and then just sending individual subsystem patches to maintainers and
> > > > Andrew so they can merge at their leisure (but don't wait for too long
> > > > ;))
> > >
> > > I have no problem with you submitting the changes. If Vojtech is fine
> > > with the proposed way, I would say that we get all of these changes into
> > > mainline now. The device model integration is long overdue.
> >
> > I'm fine with it, yes. I'm not completely convinced that an input device
> > is really a class and not a device. ;) But I can understand that view.
>
> They are devices - class devices :). I have the following distinction
> in my head - "normal" devices (bus devices) are real hardware devices
> and their drivers need to do resource and/or power management. Class
> devices represent virtual devices - some kind of abstraction - that
> unify and combine "real" devices from several buses into one class.
Yes. While input drivers do need to care about power management usually,
the input device abstraction itself doesn't have to, which makes it
indeed a special kind of a device.
> And of course nothing shoudl stop us from building class devices on
> top of other class devices, if needed.
I was always wondering whether the distinction between bus/class was
needed, as the border isn't very clear.
> Anyway, I think if Greg gives up and agrees on nesting classes all of
> it can go in -mm for now and I will contact other maintainers to
> verify that changes work. IIRC video/dvb mainatiners prefered all
> changes to go through them.
>
> In any case I don't expect it reach Linus until after 2.6.14 released
> - do you agree?
Yup.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On 9/15/05, Vojtech Pavlik <[email protected]> wrote:
> On Thu, Sep 15, 2005 at 02:22:34PM -0500, Dmitry Torokhov wrote:
> > They are devices - class devices :). I have the following distinction
> > in my head - "normal" devices (bus devices) are real hardware devices
> > and their drivers need to do resource and/or power management. Class
> > devices represent virtual devices - some kind of abstraction - that
> > unify and combine "real" devices from several buses into one class.
>
> Yes. While input drivers do need to care about power management usually,
> the input device abstraction itself doesn't have to, which makes it
> indeed a special kind of a device.
>
Right. They just signal to underlying hardware driver when they are in
use (open), but the actual power management is left to the specific
bus/driver, not input core.
> I was always wondering whether the distinction between bus/class was
> needed, as the border isn't very clear.
>
Classes combine devices which are logically the same, i.e. they
perform similar functions. Buses combine devices that are perform
different functions but have similar hardware interface. For example a
network cards - it is a class. You can have network card sit on a PCI,
USB, ISA buses but for the rest of the kernel they are accesses
through netdev abstraction. At least this is my understanding of our
device model ;)
--
Dmitry
On Thu, Sep 15, 2005 at 03:55:23PM -0500, Dmitry Torokhov wrote:
> On 9/15/05, Vojtech Pavlik <[email protected]> wrote:
> > On Thu, Sep 15, 2005 at 02:22:34PM -0500, Dmitry Torokhov wrote:
> > > They are devices - class devices :). I have the following distinction
> > > in my head - "normal" devices (bus devices) are real hardware devices
> > > and their drivers need to do resource and/or power management. Class
> > > devices represent virtual devices - some kind of abstraction - that
> > > unify and combine "real" devices from several buses into one class.
> >
> > Yes. While input drivers do need to care about power management usually,
> > the input device abstraction itself doesn't have to, which makes it
> > indeed a special kind of a device.
> >
>
> Right. They just signal to underlying hardware driver when they are in
> use (open), but the actual power management is left to the specific
> bus/driver, not input core.
>
> > I was always wondering whether the distinction between bus/class was
> > needed, as the border isn't very clear.
> >
>
> Classes combine devices which are logically the same, i.e. they
> perform similar functions. Buses combine devices that are perform
> different functions but have similar hardware interface. For example a
> network cards - it is a class. You can have network card sit on a PCI,
> USB, ISA buses but for the rest of the kernel they are accesses
> through netdev abstraction. At least this is my understanding of our
> device model ;)
Especially with things like Ethernet - there is not much difference
between it and other busses like SCSI. Both the Ethernet card and the
SCSI card give access to a bus behind them, they're in fact just
bridges.
You can have a harddrive sitting on both SCSI and Ethernet (iSCSI), and
there even is an IP-over-SCSI patch somewhere that allows connecting two
machines with a SCSI cable.
Similarly, you can have USB on PCI and on ISA. There will be two
different USB controllers in different places in the bus hierarchy. Yet
they can be accessed through the same means, something that would make
them a class.
[I'm playing a bit of a devil's advocate here - I see what the
distinction is trying to achieve.]
--
Vojtech Pavlik
SuSE Labs, SuSE CR