Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2959985ybl; Sun, 25 Aug 2019 05:55:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqzTmmnf479CxNzfMW62hZE/HChn5p1T/rsCZGGNfdyNO49MXguxroOGiMfkaoQ4lk12FkfD X-Received: by 2002:a62:f204:: with SMTP id m4mr15558306pfh.7.1566737719986; Sun, 25 Aug 2019 05:55:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566737719; cv=none; d=google.com; s=arc-20160816; b=mcQ6u+LC54sovNdm6E89IeFuPUIGz/aGHCgz1d1LyHHTCZUDXDBaltEjcyHDeaXw6C pwWWtIS5ChmYIYA3x36icbEUcgCDf/NohVHxk2dRv5fDtm0wFCUowOp9QSf25zAUl02Y e9zHRfz1eJStRbGCR9Ii7IbyFjOJLzjDukS/JPvZcngV6I1IhnQE6kRXSv5q3bPasAyH Gw/gDNmIIDDwAO3iM7Y3vLnJFgsJzYQwt4wrYuTBbsc/vQJYuoPdkAkBb1YxO+GNqPY/ APsyv4TWdSdLSomE1jupU+sxsGFu9qcBEvxjI7jQHH8XZDDmE1yC2rdWA333FbA+/X/5 wlJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=m8/jrcroGPEz4MOj25P/aeI8En6M306Qu2w0tThcmjI=; b=jE9C6DRxq6xAipMWCwi6RooMYhS0aj5Dah83lcYW8Ko0/x0FDBzdHv8OFbcOvUkH+Z 54Ki/U9nzRjHS0RW4rYG7yzvXVu2fIJnW769416PBX8HYIvXhyhGvI2vDYCE4g0ptp0+ 1DHSwHu2kq4gWQSpCre7K3FP1rGBV3ULzR1dvQ2KbBvVRCZncaEHGJQr7Xbb3A3nK5pp RAi5z8mFNobb3JpfK4QiZBu4Kr8veVccdsIFN/c6YbxODYgTYtrBhhdpoKueivO7eMj0 sYWRDNWsVSmxe+hSnYPi+kd3dFxQDzlLDb8MYEP+cK0huc0A2PuDTMtVFDqwt6xufIhN w+DQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b74si7645788pfb.281.2019.08.25.05.55.04; Sun, 25 Aug 2019 05:55:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728121AbfHYMvr (ORCPT + 99 others); Sun, 25 Aug 2019 08:51:47 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:38268 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726686AbfHYMvq (ORCPT ); Sun, 25 Aug 2019 08:51:46 -0400 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id B932C28A1AB; Sun, 25 Aug 2019 13:51:44 +0100 (BST) Date: Sun, 25 Aug 2019 14:51:41 +0200 From: Boris Brezillon To: Cc: , , , , , Subject: Re: [PATCH v2 4/7] mtd: spi-nor: Split spi_nor_init_params() Message-ID: <20190825145141.71a647ab@collabora.com> In-Reply-To: <78202b39-1c40-dbaa-3ebc-3481ecbe4643@microchip.com> References: <20190824120027.14452-1-tudor.ambarus@microchip.com> <20190824120027.14452-5-tudor.ambarus@microchip.com> <20190825140302.21ca2623@collabora.com> <78202b39-1c40-dbaa-3ebc-3481ecbe4643@microchip.com> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 25 Aug 2019 12:23:45 +0000 wrote: > On 08/25/2019 03:03 PM, Boris Brezillon wrote: > > External E-Mail > > > > > > On Sat, 24 Aug 2019 12:00:43 +0000 > > wrote: > > > >> From: Tudor Ambarus > >> > >> Add functions to delimit what the chunks of code do: > >> > >> static void spi_nor_init_params() > >> { > >> spi_nor_legacy_init_params() > >> spi_nor_manufacturer_init_params() > >> spi_nor_sfdp_init_params() > >> } > >> > >> Add descriptions to all methods. > >> > >> spi_nor_init_params() becomes of type void, as all its children > >> return void. > >> > >> Signed-off-by: Tudor Ambarus > >> --- > >> drivers/mtd/spi-nor/spi-nor.c | 83 ++++++++++++++++++++++++++++++++----------- > >> 1 file changed, 63 insertions(+), 20 deletions(-) > >> > >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > >> index c9514dfd7d6d..93424f914159 100644 > >> --- a/drivers/mtd/spi-nor/spi-nor.c > >> +++ b/drivers/mtd/spi-nor/spi-nor.c > >> @@ -4186,7 +4186,34 @@ static void spi_nor_manufacturer_init_params(struct spi_nor *nor) > >> nor->info->fixups->default_init(nor); > >> } > >> > >> -static int spi_nor_init_params(struct spi_nor *nor) > >> +/** > >> + * spi_nor_sfdp_init_params() - Initialize the flash's parameters and settings > >> + * based on JESD216 SFDP standard. > >> + * @nor: pointer to a 'struct spi-nor'. > >> + * > >> + * The method has a roll-back mechanism: in case the SFDP parsing fails, the > >> + * legacy flash parameters and settings will be restored. > >> + */ > >> +static void spi_nor_sfdp_init_params(struct spi_nor *nor) > >> +{ > >> + struct spi_nor_flash_parameter sfdp_params; > >> + > >> + memcpy(&sfdp_params, &nor->params, sizeof(sfdp_params)); > >> + > >> + if (spi_nor_parse_sfdp(nor, &sfdp_params)) { > >> + nor->addr_width = 0; > >> + nor->flags &= ~SNOR_F_4B_OPCODES; > >> + } else { > >> + memcpy(&nor->params, &sfdp_params, sizeof(nor->params)); > >> + } > >> +} > >> + > >> +/** > >> + * spi_nor_legacy_init_params() - Initialize the flash's parameters and settings > >> + * based on nor->info data. > >> + * @nor: pointer to a 'struct spi-nor'. > >> + */ > >> +static void spi_nor_legacy_init_params(struct spi_nor *nor) > > > > Nitpick: hm, I'm not a big fan of the 'legacy' term here as I'm not sure > > it reflects the reality. I guess this function will stay around, and > > even new NORs are not guaranteed to provide SFDP tables. How about > > spi_nor_set_default_params() or spi_nor_info_init_params()? > > I can rename it to spi_nor_info_init_params() to be in sync with > spi_nor_manufacturer_init_params() and > spi_nor_sfdp_init_params() > > or I can rename all to: > spi_nor_set_params() > spi_nor_set_default_params() > spi_nor_set_manufacturer_params() > spi_nor_set_sfdp_params() > > Both are ok, but the second option seems better. What would you choose? Both sound good, pick the one you prefer.