public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: Brad Boyer <flar@allandria.com>,
	Laurent Vivier <Laurent@lvivier.info>,
	linux-m68k@vger.kernel.org
Subject: Re: [PATCH] Add SWIM floppy support for m68k Macs.
Date: Tue, 11 Nov 2008 09:52:44 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0811110937580.19341@anakin> (raw)
In-Reply-To: <Pine.LNX.4.64.0811101041560.365@loopy.telegraphics.com.au>

On Mon, 10 Nov 2008, Finn Thain wrote:
> 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.

No, its creation code should not depend on any config option (except
CONFIG_MAC :-). This means the platform device will always be created when the
physical hardware is present.

> It also makes drivers/block/swim.c less cohesive.

When the device framework was introduced, platform devices and platform drivers
were handled in the driver (source file) itself. Later it was realized this was
actually a mistake, and the platform devices and platform drivers were
separated.

> > 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? 

You need some logic to device whether to create a platform device or not.
On Mac, the logical way is to look in the macintosh_config table.

On Amiga, you would use

    if (AMIGAHW_PRESENT(AMI_XXX))
	platform_device_register{,_simple}(...);

Converting the existing Amiga drivers is somewhere on my todo-list (since a
just way too long time)...

> Would you explain it is we gain from moving platform init routines into 
> config.c? I can only see disadvantages.

The device framework is the recommended way to handle devices and drivers
across all Linux platforms.

All existing platform devices show up under /sys/devices/platform/. Based on
this information, the device entry in /dev can be created automatically, and
the corresponding platform driver loadable kernel modules can be loaded
automatically.

E.g. you no longer have to specify in /etc/modules.conf which floppy driver
to load. Currently you have to choose one of:

    alias block-major-2 amiflop
    alias block-major-2 ataflop
    alias block-major-2 swim3

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

  reply	other threads:[~2008-11-11  8:52 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-01  9:43 [PATCH] Add SWIM floppy support for m68k Macs Laurent
2008-11-01 18:10 ` Brad Boyer
2008-11-02  0:29   ` Finn Thain
2008-11-02  5:23     ` Brad Boyer
2008-11-02 12:02   ` Laurent Vivier
2008-11-04 18:34     ` Riccardo
2008-11-04 20:06       ` Brad Boyer
2008-11-05  0:58         ` Riccardo
2008-11-05  2:28           ` Brad Boyer
2008-11-05 21:43             ` Riccardo
2008-11-06  4:18               ` Brad Boyer
2008-11-05  6:58           ` Finn Thain
2008-11-05 21:45             ` Riccardo
2008-11-05  7:37         ` Joshua Juran
2008-11-05 10:31           ` Finn Thain
2008-11-05 12:20             ` Joshua Juran
2008-11-05 13:10               ` Finn Thain
2008-11-05 14:32                 ` Laurent Vivier
2008-11-06  4:09                   ` Brad Boyer
2008-11-02  6:00 ` Finn Thain
2008-11-02 11:59   ` Laurent Vivier
2008-11-02  8:54 ` Geert Uytterhoeven
2008-11-02 11:21   ` Laurent Vivier
2008-11-02 21:28     ` Brad Boyer
2008-11-03  0:14       ` Finn Thain
2008-11-03 18:58         ` Laurent Vivier
2008-11-09 16:16         ` Geert Uytterhoeven
2008-11-09 21:47           ` Laurent Vivier
2008-11-09 23:05           ` Michael Schmitz
2008-11-10  0:15           ` Finn Thain
2008-11-11  8:52             ` Geert Uytterhoeven [this message]
2008-11-11  9:43               ` Finn Thain
2008-11-11 10:21                 ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0811110937580.19341@anakin \
    --to=geert@linux-m68k.org \
    --cc=Laurent@lvivier.info \
    --cc=flar@allandria.com \
    --cc=fthain@telegraphics.com.au \
    --cc=linux-m68k@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox