Hi Geert, On 07/29/2019 11:05 AM, Geert Uytterhoeven wrote:
--- a/drivers/ata/pata_buddha.c +++ b/drivers/ata/pata_buddha.c+static const struct zorro_device_id pata_buddha_zorro_tbl[] = { + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA, }, + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_CATWEASEL, }, + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, },drivers/net/ethernet/8390/zorro8390.c also matches against ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, while only a single zorro_driver can bind to it. Hence you can no longer use both IDE and Ethernet on X-Surf :-( Before, this worked, as the IDE driver just walked the list of devices.
Okay, now this gets dirty. The reason why I've submitted this patch is to allow pata_buddha to be built into the kernel at all. Without this patch, its initcall would be called before the Zorro structures are initialised, hence not finding any boards. That means that not only would the previous driver only make sense as a module that is manually ensured to be loaded after Zorro has started, but the X-Surf IDE support was a really ugly hack to begin with.
I think the proper solution is to create MFD devices for Zorro boards with multiple functions, and bind against the individual MFD cells. That would also get rid of the nr_ports loop in the IDE driver, as each instance would have its own cell. I played with this a long time ago, but never finished it. It worked fine for my Ariadne Ethernet card. Last state at https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=zorro-mfd Oh, seems I wrote up most of this before in https://lore.kernel.org/lkml/CAMuHMdVe1KgQWYZ_BfBkSo3zr0c+TenLMEw3T=BLEQNoZ6ex7A@xxxxxxxxxxxxxx/
This looks great! Unfortunately, I don't have any MFD hardware other than a single Buddha to test this with. I especially don't have an X-Surf, hence no good way of testing this other than the two IDE channels on my Buddha. WinUAE doesn't seem to emulate the IDE controller either. 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 ;) On another note: Maybe your MFD idea could be used to expose the clockports on the Buddhas as well? That wouldn't solve the issue of clockport *expansions* being fundamentally non-enumerable, but maybe you can think of a reasonable way to attach a driver? Thanks for your feedback, Max
