Hi Max, On Mon, Jul 29, 2019 at 4:31 PM Max Staudt <m...@enpas.org> wrote: > On 07/29/2019 01:30 PM, Geert Uytterhoeven wrote: > >> What shall I do? Maybe as a stop-gap measure, we could hard-code a > >> module_init() again, just for X-Surf? It's been good enough until a > >> few weeks ago, so what could go wrong ;) > > > > In the short run: keep on using drivers/ide/buddha.c? > > See Bartlomiej's reply to your email: It suffers from the same problem. > Building it in will result in the Buddha not being recognised, as the IDE > driver scans for it before Zorro si initialised.
Thanks for the confirmation. > @Bartlomiej: You're not missing anything, the problem has gone unnoticed for > ages ;) > However, using ide/buddha would work exactly as it has before: When loaded as > a module after Zorro has been initialised, it works just fine. > > We *could* also temporarily split off a pata_buddha_xsurf driver: pata_buddha > would be auto-probed by the new framework, and pata_buddha_xsurf would do the > old module_init() dance. > That is, until the MFD conversion happens. Or add temporarily a late_initcall() to find all X-Surf boards using zorro_find_device(), create fake zorro_device_id entries, and pass both to pata_buddha_probe()? A big ugly, but that should work. > > Your single Buddha should be sufficient to convert pata_buddha.c from > > a plain Zorro driver to an MFD cell driver, and test it. > > I expect the buddha-mfd.c MFD driver from my zorro-mfd branch to > > work as-is, or with very minor changes. > > > > However, to keep X-Surf working, this needs to be synchronized with > > a Zorro MFD conversion of the zorro8390 driver, too. > > Yeah, this second part is where I get caught up. I'd really like to test this > with a real X-Surf, or have someone test it, before sending it upstream. Of course it should be tested ;-) Converting zorro8390.c from a zorro driver to an MFD cell driver should not require that many changes, most bugs should be caught by code review. I already have a skeleton 8390-cell.c driver in my zorro-mfd branch. > > Yes, the clockport could be added as an extra MFD cell. Later, drivers can > > be written to bind against the clockport cell. > > Yes, but how can we assign specific drivers to specific clockports? As they > are non-enumerable (are they?), we can't auto-probe them. That's something the user has to configure. The Buddha MFD driver registers an "a1200-clockport" cell, which is really a separate platform device. The user writes the name of the actual driver to use to the device's driver_override file in sysfs, after which the driver is bound automatically. See Documentation/ABI/testing/sysfs-bus-platform, The alternative would be to have multiple drivers matching against "a1200-clockport", and the user modprobe'ing the correct one to use. But that won't work with http://wiki.icomp.de/wiki/A500/A1000_clockport and plugging in two different clock port boards. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
