Hi Vitaly,
On Wed, 25 Apr 2007 21:06:10 +0400, Vitaly Bordug wrote:
> Jean Delvare wrote:
> >>>> +/* Structure for a device driver */
> >>>> +static struct device_driver i2c_rpx_driver = {
> >>>> + .name = "fsl-i2c-cpm",
> >>>> + .bus = &platform_bus_type,
> >>>> + .probe = i2c_rpx_probe,
> >>>> + .remove = i2c_rpx_remove,
> >>>> +};
> >>>>
> >>> Why don't you declare it as a struct platform_driver, register it with
> >>> platform_driver_register() and unregister it with
> >>> platform_driver_unregister()?
> >>>
> >> Well. This stuff belongs to CPM1, of the mpc8xx family, but the
> >> target boards are different, and they may/should provide board
> >> specific inits and filling of platform data. With
> >> platform_driver_register we may end up with ifdef stuff here
> >> (which is evil).
> >>
> >
> > I don't follow you here, sorry. Platform devices are declared by
> > board-specific code which can include all the needed initialization.
> > And device-specific data can be carried to the platform driver for
> > further use. The platform device/driver infrastructure is meant to
> > handle that kind of situation, so there really is no excuse that I can
> > see not to use it. i2c-omap and i2c-mpc use it. As a matter of fact you
> > _are_ declaring a platform driver (.bus = &platform_bus_type), just not
> > using the standard way.
> >
> >
> Standard way here - platform devices got registered from elsewhere -
> from arch/ppc/ppc_sys.c if arch/ppc or from
> arch/powerpc/sysdev/fsl_soc.c if powerpc.
> Every way (powerpc is more flexible since is pulling the information
> from the firmware-passed device tree) fills in the resources and
> platform data, and
> is capable with device/drive bound you are talking about.
This doesn't explain why you can't use platform_driver_register(),
which is the right way to register a platform driver.
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
