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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 11 Sep 2020 08:28:45 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Finn Thain <fthain@...egraphics.com.au>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Joshua Thompson <funaho@...ai.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-ide@...r.kernel.org
Subject: Re: [PATCH] ide/macide: Convert Mac IDE driver to platform driver

Hi Finn,

On Fri, Sep 11, 2020 at 1:05 AM Finn Thain <fthain@...egraphics.com.au> wrote:
> On Thu, 10 Sep 2020, Geert Uytterhoeven wrote:
> > On Thu, Sep 10, 2020 at 2:23 AM Finn Thain <fthain@...egraphics.com.au> wrote:
> > > > How does the driver know not to use the special port_ops after
> > > > this change?
> > > >
> > >
> > > The driver always uses the special port_ops after this change because it
> > > no longer handles the MAC_IDE_BABOON case. That case is handled by either
> >
> > non-MAC_IDE_BABOON case?
> >
> > > drivers/ata/pata_platform.c or drivers/ide/ide_platform.c, depending on
> > > .config.
> >
> > Ideally, we do need to differentiate, right?
> >
>
> Sorry, I'm lost.
>
> The commit log explains that the macide driver is only intended to support
> two of the three variants, because the generic drivers are already able to
> support the third variant (Baboon). Stan confirmed this on his PB 190.
>
> But, IIUC, you seem to want macide to continue to support all three
> variants (?) The existing code to implement that has an old bug that
> reassigns d.port_ops when it is const. IMO, the const is correct because
> macide should concern itself with mac hardware quirks and should not try
> to mimic a generic driver by setting d.port_ops = NULL. Does that make
> sense?

Sorry, I completely missed that the Baboon case registers a "pata_platform"
device instead of a "macide" device.  Hence please ignore my comments
related to that.  Sorry for the noise.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ