Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp26331lfe; Fri, 15 Apr 2022 17:47:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxIAIyHW9+aSm/HYMrDKrntopK3sZh7w5sruXBjZc4pIUTkaOaSDGtTlQN4ALGWqzsID24r X-Received: by 2002:a63:e912:0:b0:39d:f8f:ca7 with SMTP id i18-20020a63e912000000b0039d0f8f0ca7mr1153489pgh.121.1650070075601; Fri, 15 Apr 2022 17:47:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650070075; cv=none; d=google.com; s=arc-20160816; b=xpfO7eecDmPK9ZC7cIeK1yxjoNV/ZDYqtDgdaX8V0WLyHA1n3nzci/ut2YLHF5PsRh 2oDiHqLN/eZQo+R+BtAvAIhuj0rZ7UCcLoG5s6R/W2JjMXm9xB6YGqsorqcS4LfG38Gz qaRCYGRphUI4LBU0l1BXbVMg8/b+7Mcye3PGUZhkX1fpyTUtt9PpMiSUWCXOO1NBBQDn ReteAAzBHGshv66Nfon9TGcnWlxDRZHeALFZS7UBQKCn6PP/ori/Ig/LHgYMe6BWLIbC y0TC88TmIEdWiD5kLoD/MpoPhJ5KHQtTLoYH6D5uFMo6dXi7gwKjoTJYBjYVRqNA25Ty /ToQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=BgdCT580fMolvON0khTX3w7+ckEWpiYEKVZGLDeXoxE=; b=k4WuKd7O5VPVcUHcSInUs5VcgEJ74zO7dux/FHgvPEuLvTt60p3Lf2z0nd6GaEoYoe KtvMuFX6d3sGI+xYflfIVDi5Adr2FchZR0MLo2ktilM9ahmx1cy5uUVGUSye4Amf6QZ7 bIqJ8Tct1PFSII0qdqcUxJUY0d80t/CyZGZ5+eATy6t9XMC/FB9pcoZv9HTr2DmyNd6/ u3tfDouOToiU7d1v5zygup5NkH0nToyQipwQl9haRHbYO2XmuJ9qG10tI8BNYFHZsiq7 A1K+ztiXolgFLTuqX3ErpZ+c324fM/pq+uuBgWo+0I+fMhcRbOw++KQToHR4WCStf7/1 SWDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=BqoNpi73; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id s11-20020a65584b000000b003816043eed3si3307151pgr.200.2022.04.15.17.47.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 17:47:55 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=BqoNpi73; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E84C3F55E4; Fri, 15 Apr 2022 17:38:50 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350859AbiDOHDm (ORCPT + 99 others); Fri, 15 Apr 2022 03:03:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245147AbiDOHDk (ORCPT ); Fri, 15 Apr 2022 03:03:40 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2700038BE8 for ; Fri, 15 Apr 2022 00:01:11 -0700 (PDT) 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 3B8C81F47DA4; Fri, 15 Apr 2022 08:01:01 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1650006061; bh=oDcnz0m1mddcgO5NTlXqk8XUEUGT5espCP0WO07gMYU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BqoNpi73XsRvh2WdiBmbhYZ5vFnRU5vebFpBxD/SKyw977vSyO9VpL23vPM4gmFvt zBA8w74ae/N+oLLB2g6MtNK5UxWSgsvGC4qVrHDtoaJEfIy8otJdhn8t0L1tItMaAT vWHFPwRPA7vkZnA/KaFCLY9eKqNwSxEHLtHwamW6k7r8OWOujpJaUp5Luv2jPd466C VB/0KSlvHxcwhHsdanmzpHZhUyIPu4x+iXWhDQChp1ai6qzfGyMf5FAS7VjjvggIK3 yY/T88bYcKPSIix8MacYKu9C3eVni8nI0CsFF7ulNyOH1qM7c1h+MbUuxEov6zzzoD 2VMyiKsmCtvZA== Date: Fri, 15 Apr 2022 09:00:58 +0200 From: Boris Brezillon To: Chuanhong Guo Cc: linux-mtd@lists.infradead.org, Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Patrice Chotard , Christophe Kerello , Mark Brown , Daniel Palmer , linux-kernel@vger.kernel.org (open list) Subject: Re: [PATCH v2 2/3] mtd: spinand: add support for detection with param page Message-ID: <20220415090058.5044ae17@collabora.com> In-Reply-To: <20220415034844.1024538-3-gch981213@gmail.com> References: <20220415034844.1024538-1-gch981213@gmail.com> <20220415034844.1024538-3-gch981213@gmail.com> Organization: Collabora X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Apr 2022 11:48:43 +0800 Chuanhong Guo wrote: > + > +static const struct spinand_manufacturer *spinand_onfi_manufacturers[] = {}; Do we really need a separate manufacturer array? Looks like we could re-use the one we have in core.c and do the matching against it (we just need an extra NULL sentinel to detect the end of this array). > + > +static const struct spinand_onfi_info * > +spinand_onfi_chip_match(struct nand_onfi_params *p, > + const struct spinand_manufacturer *m) > +{ > + size_t i, j; > + > + for (i = 0; i < m->nchips; i++) > + for (j = 0; m->onfi_chips[i].models[j]; j++) > + if (!strcasecmp(m->onfi_chips[i].models[j], p->model)) > + return &m->onfi_chips[i]; > + return NULL; > +} > +/** > + * struct spinand_onfi_info - Structure used to describe SPI NAND with ONFI > + * parameter page > + * @models: Model name array. Null terminated. > + * @flags: OR-ing of the SPINAND_XXX flags > + * @eccinfo: on-die ECC info > + * @op_variants: operations variants > + * @op_variants.read_cache: variants of the read-cache operation > + * @op_variants.write_cache: variants of the write-cache operation > + * @op_variants.update_cache: variants of the update-cache operation > + * @select_target: function used to select a target/die. Required only for > + * multi-die chips > + * > + * Each SPI NAND manufacturer driver should have a spinand_onfi_info table > + * describing all the chips supported by the driver. > + */ > +struct spinand_onfi_info { > + const char **const models; > + u32 flags; > + struct spinand_ecc_info eccinfo; > + struct { > + const struct spinand_op_variants *read_cache; > + const struct spinand_op_variants *write_cache; > + const struct spinand_op_variants *update_cache; > + } op_variants; > + int (*select_target)(struct spinand_device *spinand, > + unsigned int target); > +}; Can't we just extend spinand_info instead of defining a new struct. AFAICT, the only difference is that model is replaced by a model array, and devid is dropped, and I think we can rework the existing ID-based matching logic to return ->models[0] instead of ->model.