On Sun, 9 Nov 2008, Geert Uytterhoeven wrote:
> On Mon, 3 Nov 2008, Finn Thain wrote:
> >
> > I agree with Geert. Ignore my comment about device_initcall -- I was
> > looking at via-cuda.c but that is not a good example.
> > drivers/scsi/mac_esp.c is a better example.
> >
> > esp_mac_probe checks the macintosh_config entry. That and
> > esp_mac_remove are the platform device entry points Geert referred to.
> > The module entry points are mac_esp_init and mac_esp_exit. I think you
> > could use either of the platform device probe routine or the module
> > init routine to set the base address.
>
> Ideally, the _probe() routine should not look at the bits in
> macintosh_config, but only at the platform device and its resources.
Makes sense.
> The creation of the platform device should be moved to
> arch/m68k/mac/config
That means adding #if CONFIG_BLK_DEV_SWIM to config.c.
It also makes drivers/block/swim.c less cohesive.
> which would create the platform device, and only if the bits in
> macintosh_config indicate that the hardware is present. The actual value
> of swim_base can be stored in a struct resource linked to the platform
> device.
I'm probably missing something here, but I can see some benefit in doing
this only in the absence of a global macintosh_config.
But if you didn't have a global macintosh_config, several parts of
macintosh_config (especially macintosh_config->ident) would end up
duplicated in each of the struct resources for the platform devices, no?
Would you explain it is we gain from moving platform init routines into
config.c? I can only see disadvantages.
Finn
> So far the only platform device for m68k (not in mainline) is Michael's
> EtherNAT driver, cfr. arch/m68k/atari/config.c. Note that that one
> registers the platform device unconditionally, as there's no magic
> predictor for its presence in the firmware or machine tables.
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
