Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp5072034pxb; Tue, 5 Oct 2021 17:07:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwATKpFIijJauxIKQPcDdkXOMKnFvf3KwRuWgbpdsxt1jKVVY1Ksc/I4TjyFQrHwadtnKvk X-Received: by 2002:a50:a2a5:: with SMTP id 34mr31474631edm.180.1633478824355; Tue, 05 Oct 2021 17:07:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633478824; cv=none; d=google.com; s=arc-20160816; b=pKRpzaw/7396MURu8uGB21EoSaMZ1/WJHuTaOCWFrpIN4P2wT/5XdpVGCO3AsGTDAH hR5TJGInlHeIhOy2ftw7PGGx15CPZVBBdIYVm1fM54sErGBoMXMI1z/VnTqjAt4p3Xmt SMkEVLCbCSmexnOHJNTl6V2fYwK3H2crXi32J/CuVc2IIgdt/Wp2rsc20qN6xRFxgyNm tyyEHFLMjULuyYNxfJ1cWGSt0fmUXpMKsCHvc5uKgu1SmwHDpmWETYE8aD53ynpowAUB eSnSk8XYXJ+5LSqawu0w+hoLyBa4qQhVClOhuH6uGDMbEJjSJPiMyPd56KmXHO5J0Fyz jD4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature:dkim-filter; bh=Lba9wJEZ48njfaVv79S/RD8k06p4EsANJ/0HCRU1yKM=; b=vQPNjy5Xc2jpLYDaA1lPbpBFKsQRHMM27KIjPU7YXmuSlZIWsVAUdHDWMCsKvxaeJc mMzdAVaguVD78j1hO68Z/5OJcIE0vv4OlVCafMXbnnCfVhqcdC4PJJxUX4PDOtN4LKI3 65eKP07D3OnfCZREq4j2TOSgbP/dE0+Y/Pl9XffrgFtGNJgsfc8wWq6GogGZorXxglfx dD1j6uT2Erp2KDm6plmO9kg0ZprX4n512SPR///HVybIgnfaW38qT+XZW+005WiywZNh HJ/waRetxquKXzGiMtI7sJb/Bd/mgHxNRZHRchAgYcnb4kw/js/o03mV7vHSlt7VLQ52 JRng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=Z1tmXIJ1; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p16si22805357ejm.464.2021.10.05.17.06.38; Tue, 05 Oct 2021 17:07:04 -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; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=Z1tmXIJ1; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236873AbhJFAFj (ORCPT + 99 others); Tue, 5 Oct 2021 20:05:39 -0400 Received: from linux.microsoft.com ([13.77.154.182]:42988 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231373AbhJFAFj (ORCPT ); Tue, 5 Oct 2021 20:05:39 -0400 Received: by linux.microsoft.com (Postfix, from userid 1046) id D8A1C20B861E; Tue, 5 Oct 2021 17:03:47 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D8A1C20B861E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1633478627; bh=Lba9wJEZ48njfaVv79S/RD8k06p4EsANJ/0HCRU1yKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z1tmXIJ1YElDF76BCq50LrBsRxfIyeMYNGIXdZvUB1ikVsM92HjWmTlGOc3YsEXoL 7Tj043DIAAMst2f3czz/PcRI8/AwSiIU5oIOSd2+ZW8vHm2Igf5ILftBNUKFUGKF/M iJ70OmGEujqxsd0Pi/QyxnQF06Ro/tIuJVGAyeuU= From: Dhananjay Phadke To: zev@bewilderbeest.net Cc: andrew@aj.id.au, clg@kaod.org, gregkh@linuxfoundation.org, jk@codeconstruct.com.au, joel@jms.id.au, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, michael@walle.cc, miquel.raynal@bootlin.com, openbmc@lists.ozlabs.org, p.yadav@ti.com, richard@nod.at, tudor.ambarus@microchip.com, vigneshr@ti.com, Dhananjay Phadke Subject: Re: [PATCH 3/6] mtd: spi-nor: aspeed: Refactor registration/unregistration Date: Tue, 5 Oct 2021 17:03:14 -0700 Message-Id: <1633478594-16793-1-git-send-email-dphadke@linux.microsoft.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <20210929115409.21254-4-zev@bewilderbeest.net> References: <20210929115409.21254-4-zev@bewilderbeest.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Sep 2021, Zev Weiss wrote: > We now have separate functions for registering and unregistering > individual flash chips, instead of the entire controller. This is a > preparatory step for allowing userspace to request that a specific > chip be attached or detached at runtime. > > Signed-off-by: Zev Weiss > --- > drivers/mtd/spi-nor/controllers/aspeed-smc.c | 73 ++++++++++++-------- > 1 file changed, 45 insertions(+), 28 deletions(-) > > diff --git a/drivers/mtd/spi-nor/controllers/aspeed-smc.c b/drivers/mtd/spi-nor/controllers/aspeed-smc.c > index 7225870e8b18..3c153104a905 100644 > --- a/drivers/mtd/spi-nor/controllers/aspeed-smc.c > +++ b/drivers/mtd/spi-nor/controllers/aspeed-smc.c > @@ -107,9 +107,10 @@ struct aspeed_smc_controller { > const struct aspeed_smc_info *info; /* type info of controller */ > void __iomem *regs; /* controller registers */ > void __iomem *ahb_base; /* per-chip windows resource */ > + struct resource *ahb_res; /* resource for AHB address space */ > u32 ahb_window_size; /* full mapping window size */ > > - struct aspeed_smc_chip *chips[]; /* pointers to attached chips */ > + struct aspeed_smc_chip *chips[]; /* pointers to connected chips */ > }; > > /* > @@ -399,15 +400,24 @@ static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to, > return len; > } > > +static int aspeed_smc_unregister_chip(struct aspeed_smc_chip *chip) > +{ > + return mtd_device_unregister(&chip->nor.mtd); > +} > + > static int aspeed_smc_unregister(struct aspeed_smc_controller *controller) > { > struct aspeed_smc_chip *chip; > - int n; > + int n, ret; > > for (n = 0; n < controller->info->nce; n++) { > chip = controller->chips[n]; > - if (chip) > - mtd_device_unregister(&chip->nor.mtd); > + if (chip) { > + ret = aspeed_smc_unregister_chip(chip); > + if (ret) > + dev_warn(controller->dev, "failed to unregister CS%d: %d\n", > + n, ret); > + } > } > > return 0; > @@ -756,14 +766,39 @@ static const struct spi_nor_controller_ops aspeed_smc_controller_ops = { > .write = aspeed_smc_write_user, > }; > > -static int aspeed_smc_setup_flash(struct aspeed_smc_controller *controller, > - struct device_node *np, struct resource *r) > +static int aspeed_smc_register_chip(struct aspeed_smc_chip *chip) > { > - const struct spi_nor_hwcaps hwcaps = { > + static const struct spi_nor_hwcaps hwcaps = { > .mask = SNOR_HWCAPS_READ | > SNOR_HWCAPS_READ_FAST | > SNOR_HWCAPS_PP, > }; > + int ret; > + > + ret = aspeed_smc_chip_setup_init(chip, chip->controller->ahb_res); > + if (ret) > + goto out; > + > + /* > + * TODO: Add support for Dual and Quad SPI protocols attach when board > + * support is present as determined by of property. > + */ > + ret = spi_nor_scan(&chip->nor, NULL, &hwcaps); > + if (ret) > + goto out; > + > + ret = aspeed_smc_chip_setup_finish(chip); > + if (ret) > + goto out; > + > + ret = mtd_device_register(&chip->nor.mtd, NULL, 0); > +out: > + return ret; > +} I was looking into this driver probe walking sub-nodes. It looks like all controller drivers are doing / have to do similar work - (1) Parse common dt bindings documented in Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml (2) Run spi_nor_scan() with tweaked/reduced capabilities. (3) mtd_register_device(). It would be good to absorb this workflow in mtd/spi-nor core and add 'reserved' as common dt property to avoid (2) and (3) from probe. Regards, Dhananjay