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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
