The connect and disconnect functions are unnecessary - everything they do can be
accomplished in the initial probe - so remove them.
Signed-off-by: Adrian McMenamin <[email protected]>
---
diff --git a/include/linux/maple.h b/include/linux/maple.h
index 39a125a..d49e2d3 100644
--- a/include/linux/maple.h
+++ b/include/linux/maple.h
@@ -62,8 +62,6 @@ struct maple_device {
struct maple_driver {
unsigned long function;
- int (*connect) (struct maple_device * dev);
- void (*disconnect) (struct maple_device * dev);
struct device_driver drv;
};
On Sun, Jun 15, 2008 at 08:48:09PM +0100, Adrian McMenamin wrote:
> The connect and disconnect functions are unnecessary - everything they do can be
> accomplished in the initial probe - so remove them.
>
> Signed-off-by: Adrian McMenamin <[email protected]>
Applied, thanks.
On Tue, June 24, 2008 5:01 am, Paul Mundt wrote:
> On Sun, Jun 15, 2008 at 08:48:09PM +0100, Adrian McMenamin wrote:
>> The connect and disconnect functions are unnecessary - everything they
>> do can be
>> accomplished in the initial probe - so remove them.
>>
>> Signed-off-by: Adrian McMenamin <[email protected]>
>
> Applied, thanks.
>
Paul,
Just to note that this (http://lkml.org/lkml/2008/6/15/122) will break the
keyboard driver unless this (http://lkml.org/lkml/2008/6/15/121) is also
applied.
I haven't heard back from Dmitry on the keyboard patch yet.
Adrian
On Tue, Jun 24, 2008 at 11:59:07AM +0100, Adrian McMenamin wrote:
> On Tue, June 24, 2008 5:01 am, Paul Mundt wrote:
> > On Sun, Jun 15, 2008 at 08:48:09PM +0100, Adrian McMenamin wrote:
> >> The connect and disconnect functions are unnecessary - everything they
> >> do can be
> >> accomplished in the initial probe - so remove them.
> >>
> >> Signed-off-by: Adrian McMenamin <[email protected]>
> >
> > Applied, thanks.
> >
> Paul,
>
> Just to note that this (http://lkml.org/lkml/2008/6/15/122) will break the
> keyboard driver unless this (http://lkml.org/lkml/2008/6/15/121) is also
> applied.
>
> I haven't heard back from Dmitry on the keyboard patch yet.
>
Yes, I'm aware of that. This should fix itself in linux-next once it is
merged in the input tree, and I don't intend on pushing my changes until
that's in place, so we don't break bisection.