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. @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. > 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. > 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. Max
