From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C15F6C47089 for ; Mon, 5 Dec 2022 16:34:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231756AbiLEQeP (ORCPT ); Mon, 5 Dec 2022 11:34:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232781AbiLEQdZ (ORCPT ); Mon, 5 Dec 2022 11:33:25 -0500 Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 110C01EAEC; Mon, 5 Dec 2022 08:33:08 -0800 (PST) Received: by mail-oi1-f171.google.com with SMTP id r11so7932091oie.13; Mon, 05 Dec 2022 08:33:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hqhqp0ZXnkI0q0Biib9w/buyr5MoNs1FLwzcB1Vt6bM=; b=71fZkXsVoFEwPozUmoFH15ih8+FavB3OmObN52fagiBXdkMVxUZ51CHy+G6WM9QNgt gWb6jfaH0eeUfdqfukhAzvrtHAeaLeGLzhBR2iGnKIyaLf9NEd3oj+ijs3OseqL5kSxj CgCZC03pUANw8cuQbzljhwmqTR/2AQHe/LnIvMcjjS3F7K5YM0q9/CRyT0AKhPsuRDts Lu3BWvePePkihYPZ793Lh2UmTkQksDM1a2d2Y8BreYkrv+mlWMBlxyv7RX3Et07f6Qzm LAUzRuIoyH7X7bHzzdjAbvjon18ajfJKZAkHfHLldeidn/dDi2ceErwHFUsOkkXrnIo7 Q+TQ== X-Gm-Message-State: ANoB5pkS6btfy+yYt0oEnfgUuMssB21qhg7WtmPrDU4xMS6pWLdKcjlq VEM9c0JIRn+SGG9XJ9s82iL90+ZHxQ== X-Google-Smtp-Source: AA0mqf4MvfbOP05MYi3I90IViiSBgYnNTh5GEOHb/N8V1hTeGsbZjHM0XH27IkGpGsVY9fC3KRZDQA== X-Received: by 2002:a54:451a:0:b0:35b:3f80:32e8 with SMTP id l26-20020a54451a000000b0035b3f8032e8mr29418287oil.177.1670257987238; Mon, 05 Dec 2022 08:33:07 -0800 (PST) Received: from robh_at_kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id j2-20020a4a9442000000b0049f0671a23asm6803680ooi.9.2022.12.05.08.33.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Dec 2022 08:33:06 -0800 (PST) Received: (nullmailer pid 2034077 invoked by uid 1000); Mon, 05 Dec 2022 16:33:06 -0000 Date: Mon, 5 Dec 2022 10:33:06 -0600 From: Rob Herring To: Geert Uytterhoeven Cc: Michael Walle , Tudor Ambarus , Pratyush Yadav , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Krzysztof Kozlowski , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts Message-ID: <20221205163306.GB2012644-robh@kernel.org> References: <363186079b4269891073f620e3e2353cf7d2559a.1669988238.git.geert+renesas@glider.be> <1503a3857107e3a4f34e0c7fb5dada39@walle.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, Dec 02, 2022 at 02:56:01PM +0100, Geert Uytterhoeven wrote: > Hi Michael, > > On Fri, Dec 2, 2022 at 2:50 PM Michael Walle wrote: > > Am 2022-12-02 14:37, schrieb Geert Uytterhoeven: > > > Document support for the Micron MT25QU256A and MT25QU512A Serial NOR > > > FLASHes. > > > > > > Merge the new entries with the existing entry for MT25QU02G. > > > > > > Signed-off-by: Geert Uytterhoeven > > > --- > > > mt25qu512a is already in active use, causing "make dtbs_check" errors. > > > mt25qu256a is supported by the Linux spi-nor driver, but there are no > > > upstream users yet. > > > > Is it encouraged to use the specific compatible with SPI-NOR flashes? > > As far as I know it isn't. The spi-nor subsys tries hard to identify > > any flashes at runtime and any additional information in the device tree > > is used as a last resort (just for flashes which doesn't support the > > read jedec id command yet). And usually boards have different sources > > for flash chips, so hardcoding a particular part in the device tree > > doesn't make sense. > > Thanks, I am aware there have been pushbacks when trying to > document more compatible values. > > IMHO either all or none of them should be documented. > If device-specific compatible values are discouraged, the bindings > should be updated to reflect that, and document a single compatible > value ("jedec,spi-nor") only. That's already allowed, so there's your answer. The caveat is don't be adding them later to your DT when you find an issue and new quirk properties will probably be rejected. Rob