[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.23.453.2009160758350.6@nippy.intranet>
Date: Wed, 16 Sep 2020 08:56:58 +1000 (AEST)
From: Finn Thain <fthain@...egraphics.com.au>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
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 v2] ide/macide: Convert Mac IDE driver to platform
driver
On Tue, 15 Sep 2020, Geert Uytterhoeven wrote:
> > > > --- a/drivers/ide/macide.c
> > > > +++ b/drivers/ide/macide.c
> > >
> > > > @@ -109,42 +110,61 @@ static const char *mac_ide_name[] =
> > > > * Probe for a Macintosh IDE interface
> > > > */
> > > >
> > > > -static int __init macide_init(void)
> > > > +static int mac_ide_probe(struct platform_device *pdev)
> > > > {
> > >
> > > > printk(KERN_INFO "ide: Macintosh %s IDE controller\n",
> > > > mac_ide_name[macintosh_config->ide_type - 1]);
> > > >
> > > > - macide_setup_ports(&hw, base, irq);
> > > > + macide_setup_ports(&hw, mem->start, irq->start);
> > > >
> > > > - return ide_host_add(&d, hws, 1, NULL);
> > > > + rc = ide_host_add(&d, hws, 1, &host);
> > > > + if (rc)
> > > > + return rc;
> > > > +
> > > > + platform_set_drvdata(pdev, host);
> > >
> > > Move one up, to play it safe?
> > >
> >
> > You mean, before calling ide_host_add? The 'host' pointer is uninitialized
> > prior to that call.
>
> Oh right, so the IDE subsystem doesn't let you use the drvdata inside
> your driver (besides in remove()) in a safe way :-(
>
The IDE subsystem does allow other patterns here. I could have changed
ide_host_alloc() into ide_host_register() followed by ide_host_add() but I
could not see any benefit from that change.
A quick search for "platform_device" shows that the driver does not use
any uninitialized driver_data pointer (because ide_ifr is a global). In
your message of September 9th you readily reached the same conclusion when
you reviewed v1.
If mac_ide_probe() followed the usual pattern it might make review easier
(as reviewers may not wish to consider the entire driver) but does that
really make the code more "safe"?
Powered by blists - more mailing lists