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
