linux-kernel - Re: [PATCH v3] ata/pata_buddha: Probe via modalias instead of initcall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 29 Jul 2019 13:09:58 +0200
From:   Max Staudt <max@...as.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Jens Axboe <axboe@...nel.dk>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        Michael Schmitz <schmitzmic@...il.com>,
        linux-ide@...r.kernel.org, Linux/m68k <linux-m68k@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] ata/pata_buddha: Probe via modalias instead of
 initcall

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@mail.gmail.com/

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