Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp751140pxk; Wed, 9 Sep 2020 19:03:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwv4lN3enrrrh114CF53/an6AhvqonhcHFc+MPGRoZTEa99vZ7xUzK5u7m92ac/pCOYC+rC X-Received: by 2002:a17:906:3191:: with SMTP id 17mr6328903ejy.239.1599703405718; Wed, 09 Sep 2020 19:03:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599703405; cv=none; d=google.com; s=arc-20160816; b=tJ2PQZI4g+4nufldaID6Ul3RKZzUSGtf1PuwunieXGnJEYFPOnvrU+NL7fSbzkSiMi shGofdte+NTpzdpORKEw3BPSFQ8bNsD+/NX30uAp53toGDJ17e9WIz2gNrXbxjUVXSPd UXuudfo0dgiwiYiJDiRxfJamacSA1ZoBUxZVsfuAAe5KaK00s8vRHxlaG9ObBqv5MADq jByG/7fMFV45Vv4PwDBbZukxLoqbMN2YhwPgMe/EVkh7sFC/IBXyh+AXdwKQCxldmVJa vNfrgaUdRL9r9rhYJwxpNqcW445gbhzO5YUkD3mbzEnQjRIS+V3aYmzyGTnJ1pmW7T4r i91Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=tLd0F4W2p9PkUqgU8fXbNkVElMbhkHJrvkAYkhKktfw=; b=Z1JI8r2D/DfxYX4LZV2WY5DxBRMVYUn/71oNAOJaaKvEjxftOFaMx+I4KV7mpCeqhS Q8tbdzbpyltT/Zqd39FHb9oQJthDObr4BuiMdHV8NqKti3pcGymPOYFzlisrpwKkgWxG APwSa2P+kG+YWWYwIHBj+QAJjf05ikMTAMsNlT0CogcumauQ36zp2ELTSsJryiZY6bXU KC0ghEsAp8x45M0wQjSRccDXdQnAfohlPoNYyHkYP36c4Jd23Glc4Db1U7gaPzANCGyN YQJiQxsXwaGnWK8inpJFcamcMiuHdztt1+lqfX3BNMmjvn8mNdj8BRhOi5ysuSgLzIS6 PtIg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f7si2709075ejt.351.2020.09.09.19.03.02; Wed, 09 Sep 2020 19:03:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730523AbgIJCCU (ORCPT + 99 others); Wed, 9 Sep 2020 22:02:20 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:41474 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729413AbgIJBku (ORCPT ); Wed, 9 Sep 2020 21:40:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 5FCBA2BA1F; Wed, 9 Sep 2020 20:23:28 -0400 (EDT) Date: Thu, 10 Sep 2020 10:23:30 +1000 (AEST) From: Finn Thain To: Geert Uytterhoeven cc: "David S. Miller" , Bartlomiej Zolnierkiewicz , Joshua Thompson , linux-m68k , Linux Kernel Mailing List , linux-ide@vger.kernel.org Subject: Re: [PATCH] ide/macide: Convert Mac IDE driver to platform driver In-Reply-To: Message-ID: References: <00ee44fe6ecdce1c783c3cc3b1b9a62b498dcdb2.1597736545.git.fthain@telegraphics.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 9 Sep 2020, Geert Uytterhoeven wrote: > > Thanks for your patch! > Thanks for your review. > > --- a/arch/m68k/mac/config.c +++ b/arch/m68k/mac/config.c > > > @@ -940,6 +941,50 @@ static const struct resource mac_scsi_ccl_rsrc[] __initconst = { > > }, > > }; > > > > +static const struct resource mac_ide_quadra_rsrc[] __initconst = { > > + { > > + .flags = IORESOURCE_MEM, > > + .start = 0x50F1A000, > > + .end = 0x50F1A103, > > + }, { > > + .flags = IORESOURCE_IRQ, > > + .start = IRQ_NUBUS_F, > > + .end = IRQ_NUBUS_F, > > + }, > > +}; > > + > > +static const struct resource mac_ide_pb_rsrc[] __initconst = { > > + { > > + .flags = IORESOURCE_MEM, > > + .start = 0x50F1A000, > > + .end = 0x50F1A103, > > + }, { > > + .flags = IORESOURCE_IRQ, > > + .start = IRQ_NUBUS_C, > > + .end = IRQ_NUBUS_C, > > + }, > > +}; > > As the above two variants are almost identical, perhaps it makes sense > to drop one of them, drop the const, and override the irq values > dynamically? > I prefer a declarative or data-driven style, even if it takes a few more lines of code. But there is a compromise: static const struct resource mac_ide_quadra_rsrc[] __initconst = { DEFINE_RES_MEM(0x50F1A000, 0x104), DEFINE_RES_IRQ(IRQ_NUBUS_F), } static const struct resource mac_ide_pb_rsrc[] __initconst = { DEFINE_RES_MEM(0x50F1A000, 0x104), DEFINE_RES_IRQ(IRQ_NUBUS_C), } The reason I didn't use these macros was to avoid making the reader go and look up their definitions. Anyway, would that style be preferred here? I could do the same with the mac_ide_baboon_rsrc[] initializer: static const struct resource mac_pata_baboon_rsrc[] __initconst = { DEFINE_RES_MEM(0x50F1A000, 0x38), DEFINE_RES_MEM(0x50F1A038, 0x04), DEFINE_RES_IRQ(IRQ_BABOON_1), }; ... but that would lose the IORESOURCE_IRQ_SHAREABLE flag. I'm not sure whether that matters (it's a vestige of macide.c). > > + > > +static const struct resource mac_pata_baboon_rsrc[] __initconst = { > > + { > > + .flags = IORESOURCE_MEM, > > + .start = 0x50F1A000, > > + .end = 0x50F1A037, > > + }, { > > + .flags = IORESOURCE_MEM, > > + .start = 0x50F1A038, > > + .end = 0x50F1A03B, > > + }, { > > + .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_SHAREABLE, > > + .start = IRQ_BABOON_1, > > + .end = IRQ_BABOON_1, > > + }, > > +}; > > + > > +static const struct pata_platform_info mac_pata_baboon_data __initconst = { > > + .ioport_shift = 2, > > +}; > > Just wondering: how is this implemented in drivers/ide/macide.c, which > doesn't use the platform info? > That factor of 4 is embedded in the address caclulation: for (i = 0; i < 8; i++) hw->io_ports_array[i] = base + i * 4; > > --- a/drivers/ide/macide.c > > +++ b/drivers/ide/macide.c > > @@ -18,10 +18,11 @@ > > #include > > #include > > #include > > +#include > > > > #include > > -#include > > -#include > > + > > +#define DRV_NAME "mac_ide" > > > > #define IDE_BASE 0x50F1A000 /* Base address of IDE controller */ > > Do you still need this definition? > Yes, because it's still used to access IDE_IFR. > Ideally, that should be converted to use the base from the resource, > too. > Yes, that was my thought too. I can make the change if you like, but I can't test it until I set up the appropriate hardware (MAC_IDE_QUADRA or MAC_IDE_PB). I do own that hardware but it is located in Melbourne and it is now illegal to visit Melbourne without official papers. Besides, once I can test on that hardware I can replace the entire driver anyway, and this kind of refactoring would become moot. > > > > @@ -109,42 +110,65 @@ 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) > > { > > - unsigned long base; > > - int irq; > > + struct resource *mem, *irq; > > struct ide_hw hw, *hws[] = { &hw }; > > struct ide_port_info d = macide_port_info; > > + struct ide_host *host; > > + int rc; > > > > if (!MACH_IS_MAC) > > return -ENODEV; > > > > - switch (macintosh_config->ide_type) { > > - case MAC_IDE_QUADRA: > > - base = IDE_BASE; > > - irq = IRQ_NUBUS_F; > > - break; > > - case MAC_IDE_PB: > > - base = IDE_BASE; > > - irq = IRQ_NUBUS_C; > > - break; > > - case MAC_IDE_BABOON: > > - base = BABOON_BASE; > > - d.port_ops = NULL; > > 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 drivers/ata/pata_platform.c or drivers/ide/ide_platform.c, depending on .config. > > - irq = IRQ_BABOON_1; > > - break; > > - default: > > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > + if (!mem) > > + return -ENODEV; > > + > > + irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0); > > + if (!irq) > > return -ENODEV; > > + > > + if (!devm_request_mem_region(&pdev->dev, mem->start, > > + resource_size(mem), DRV_NAME)) { > > + dev_err(&pdev->dev, "resources busy\n"); > > + return -EBUSY; > > } > > > > 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); > > + > > + rc = ide_host_add(&d, hws, 1, &host); > > + if (rc) > > + goto release_mem; > > + > > + platform_set_drvdata(pdev, host); > > In general, it's safer to move the platform_set_drvdata() call before > the ide_host_add() call, as the IDE core may start calling into your > driver as soon as the host has been added. Fortunately you're using > dev_get_drvdata() in the .remove() callback only, and not in other parts > of the driver. > Right. > > + return 0; > > + > > +release_mem: > > + release_mem_region(mem->start, resource_size(mem)); > > Not needed, as you used devm_*() for allocation. > OK, I'll remove this. I put it there after I looked at falconide.c and wondered whether the automatic release would take place after both init failure and exit (or just exit). I see now that pata_gayle.c does it differently. > > + return rc; > > +} > > + > > +static int mac_ide_remove(struct platform_device *pdev) > > +{ > > + struct ide_host *host = dev_get_drvdata(&pdev->dev); > > > > - return ide_host_add(&d, hws, 1, NULL); > > + ide_host_remove(host); > > + return 0; > > } > > > Gr{oetje,eeting}s, > > Geert >