Re: [PATCH] Minor change to platform_device_register_simple prototype

From: Dmitry Torokhov
Date: Wed Dec 07 2005 - 13:10:27 EST


On 12/7/05, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> On 12/7/05, Dmitry Torokhov <dtor_core@xxxxxxxxxxxxx> wrote:
> > On Monday 05 December 2005 15:27, Russell King wrote:
> > > On Mon, Dec 05, 2005 at 09:23:37PM +0100, Jean Delvare wrote:
> > > > The name parameter of platform_device_register_simple should be of
> > > > type const char * instead of char *, as we simply pass it to
> > > > platform_device_alloc, where it has type const char *.
> > > >
> > > > Signed-off-by: Jean Delvare <khali@xxxxxxxxxxxx>
> > >
> > > Acked-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx>
> > >
> > > However, I've been wondering whether we want to keep this "simple"
> > > interface around long-term given that we now have a more flexible
> > > platform device allocation interface - I don't particularly like
> > > having superfluous interfaces for folk to get confused with.
> >
> > Now that you made platform_device_alloc install default release
> > handler there is no need to have the _simple interface. I will
> > convert input devices (main users of _simple) to the new interface
> > and then we can get rid of it.
> >
>
> I have started moving drivers from the "_simple" interface and I found
> that I'm missing platform_device_del that would complement
> platform_device_add. Would you object to having such a function, like
> we do for other sysfs objects? With it one can write somthing like
> this:
>
> err_delete_device:
> platform_device_del(i8042_platform_device);
> err_free_device:
> platform_device_put(i8042_platform_device);
> err_unregister_driver:
> platform_driver_unregister(&i8042_driver);
>

Btw, what is the policy on placing EXPORT_SYMBOL(...). Should they all
go together (at the top or teh bottom) or after each symbol
definition? Right now platform.c mixes 2 styles...

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/