Received: by 2002:a05:6500:1b41:b0:1fb:d597:ff75 with SMTP id cz1csp269591lqb; Tue, 4 Jun 2024 10:43:55 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWo4gYZyiHaM/qv96f6w0bHyJ94Mhl0jKuVx1E7QjuqlPczKbDvFFB80WxoIb2ZE8m9+SvyPV6va48Q7lBBF40uooKduV3BxmUFR2GIPw== X-Google-Smtp-Source: AGHT+IEXCk7vv6AHaqtfW+MHYbQ+xB2scgk2eQf9CV2NqTUIiBdv5eygqBQYKResEyVpMANoYeGm X-Received: by 2002:a17:903:1c2:b0:1f6:18f9:b764 with SMTP id d9443c01a7336-1f6a5a1391fmr1591265ad.30.1717523035460; Tue, 04 Jun 2024 10:43:55 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717523035; cv=pass; d=google.com; s=arc-20160816; b=o4BrHP4aE5ZIfcJ//O6JFWcYTddmiaous10Q3890nfHHhowECTe2vrL7OAZ7C0nOP2 w7vIMPWJSL7qYdztf4mvcVOs4N45jmLstiTFFbPhSkqYlrh7DlxkS6Xucn2Y3ys7bWOE vWtOQEmo5KvYy8UIYM4h6JmydBxrnb8jAOQCTx+lofwi1zCJQeWoxAo5fIkfuMIecyRs Omoh7akB45GFNjd4DzIDnHRuqQDk57CcBO7jz8ixCLMTdpjf+VHzy1HMC8moqbq/Z3x/ ZUr0sFwHhQxyFK4z6KXQ2H0Or30+JrL8WufLkcA7E4zTMgkMvP7UizgCmEd7ePBXch/I 6ICQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:references:to:from:cc:subject:message-id:date :content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence; bh=93Zxfdy+nK222Y8E3bINj94tLh8q8uXjbYI4H/IYmm8=; fh=AwUPBJzewSKsTbXbFGQGTxBo/TCnHh3JUPbE4YBMPPc=; b=N4jHU6KRlXC7BAL82XViP4i8MOWO7JUkd1aDD7+1Yqx1IOvhvKfuzXFvueUUrWXchP Yyo9Sm4jLcclXVUE2oSuhRk2nLDyA0fxkcGNfYEg8mEpfBiV2GiNNGBjsaZQjsEFFnV5 5JMDfVe++31VUxWTZhsKGRbdt73HnwZuDY9Q1FYgXJyouJMXLr8gGFa1/opJOcAdD2Gl 9ebhIr/9UUOPIxU1umzX2h4CXBlJTmBK77cHJPxiMGZHjuEGxooG+eDx7UX4C+Es5INb RnoBD5tkPP3LSFGYfJjUVlT5Y+dqasEJI1YUReq19ug8dboxKq7RWygtGufU/zfgYzpB AkZQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=walle.cc); spf=pass (google.com: domain of linux-kernel+bounces-201179-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-201179-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id d9443c01a7336-1f681f9d1aesi33227995ad.581.2024.06.04.10.43.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jun 2024 10:43:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-201179-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=walle.cc); spf=pass (google.com: domain of linux-kernel+bounces-201179-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-201179-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 5DEFA286646 for ; Tue, 4 Jun 2024 17:42:27 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1312914A09F; Tue, 4 Jun 2024 17:42:23 +0000 (UTC) Received: from mail.3ffe.de (0001.3ffe.de [159.69.201.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6434F5F860; Tue, 4 Jun 2024 17:42:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.69.201.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717522942; cv=none; b=XhJ9ez/AzAeHa2WMYW9E3xw6twUoJPNHR1bkExdqgUFfnDJDxqmfio5XB/uelFUYLJpchy5zLIK78nlJOfu2uHIjfYe6rCH1mI4OllwCiMu7TTgG6pTJSYwEmK+jdkmYygLqCq0mP1OuWESdXQ/aaQdkpnej0ljpiBt8kJlPGVc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717522942; c=relaxed/simple; bh=a8141EOsQxFmboV4YLmQ/aNMHC1QnCobXdkGlyO/faw=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:From:To: References:In-Reply-To; b=jkluBZxwjohJRsRQjx5dDomBKMpAZUt33BsDgEmJyrtPRho9JMj4J38eVmT5tjcB/IRtH3oyApVxeXyqoF2HgSZiOXZOTkUJiHZPdhVGxI20dPDI0iJOIEEysdjIMtisvoo2UwiWW3GsEljnjyDU9mv0nJyD3FjeqTCMaAAX/ls= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org; spf=pass smtp.mailfrom=walle.cc; arc=none smtp.client-ip=159.69.201.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=walle.cc Received: from localhost (unknown [IPv6:2a02:810b:4340:4ee9:4685:ff:fe12:5967]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id E08B675; Tue, 4 Jun 2024 19:42:16 +0200 (CEST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 04 Jun 2024 19:42:16 +0200 Message-Id: Subject: Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices Cc: "Tudor Ambarus" , "Pratyush Yadav" , "Miquel Raynal" , "Richard Weinberger" , "Vignesh Raghavendra" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , , , , =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= , "Thorsten Scherer" , "Marek Vasut" , "Imre Kaloz" , "Andrew Lunn" , "Flavio Suligoi" From: "Michael Walle" To: "Conor Dooley" X-Mailer: aerc 0.16.0 References: <20240604074231.1874972-1-mwalle@kernel.org> <20240604-ladylike-gout-6fd6ae992712@spud> In-Reply-To: <20240604-ladylike-gout-6fd6ae992712@spud> On Tue Jun 4, 2024 at 7:01 PM CEST, Conor Dooley wrote: > On Tue, Jun 04, 2024 at 09:42:31AM +0200, Michael Walle wrote: > > These devices are more like an AT25 compatible EEPROM instead of > > flashes. Like an EEPROM the user doesn't need to explicitly erase the > > memory, nor are there sectors or pages. Thus, instead of the SPI-NOR > > (flash) driver, one should instead use the at25 EEPROM driver. > >=20 > > Signed-off-by: Michael Walle > > Cc: Uwe Kleine-K=C3=B6nig > > Cc: Thorsten Scherer > > Cc: Marek Vasut > > Cc: Imre Kaloz > > Cc: Andrew Lunn > > Cc: Flavio Suligoi > > --- > > The referenced binding only supports the true AT25 compatible EEPROMs > > where you have to specify additional properties like size and page size > > or cypress FRAM devices where all the properties are discovered by the > > driver. I don't have the actual hardware, therefore I can't work on a > > proper driver and binding. But I really want to deprecate the use of > > these EEPROM like devices in SPI-NOR. So as a first step, mark the > > devices in the DT bindings as deprecated. > >=20 > > There are three in-tree users of this. I hope I've CCed all the relevan= t > > people. With the switch to the at25 driver also comes a user-space > > facing change: there is no more MTD device. Instead there is an "eeprom= " > > file in /sys now, just like for every other EEPROM. > >=20 > > Marek already expressed, that the sps1 dts can likely be removed > > altogether. I'd like to hear from the other board DTS maintainers if > > they seem some problems moving to the EEPROM interface - or maybe that > > device isn't used at all anyway. So in the end, we can hopefully move > > all the users over to the at25 driver. > > --- > > Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > >=20 > > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b= /Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > index 6e3afb42926e..2dccb6b049ea 100644 > > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > @@ -21,7 +21,6 @@ properties: > > (m25p(40|80|16|32|64|128)|\ > > n25q(32b|064|128a11|128a13|256a|512a|164k)))|\ > > atmel,at25df(321a|641|081a)|\ > > - everspin,mr25h(10|40|128|256)|\ > > (mxicy|macronix),mx25l(4005a|1606e|6405d|8005|12805d|256= 35e)|\ > > (mxicy|macronix),mx25u(4033|4035)|\ > > (spansion,)?s25fl(128s|256s1|512s|008k|064k|164k)|\ > > @@ -42,6 +41,14 @@ properties: > > - spansion,s25fs512s > > - const: jedec,spi-nor > > - const: jedec,spi-nor > > + > > + # Deprecated bindings > > + - items: > > + - pattern: "^everspin,mr25h(10|40|128|256)$" > > + - const: jedec,spi-nor > > + description: > > + Deprecated binding, use Documentation/devicetree/bindings/ee= prom/at25.yaml. > > + deprecated: true > > The idea here seems okay, but directing people to use the at25 binding, > without actually documenting the replacement compatibles etc is far from > ideal. I think even a wording change that points out that that these > devices need to be documented in that file would be an improvement, the > current wording makes it seem like the works been done. > Until there's a replacement driver, I don't think you could really > expect anyone to move to a new binding anyway. Fair enough. The driver is already there and it basically works - Flavio is already using it. It is just, that at the moment you have to use the (deprecated) "atmel,at25" compatible and you'll have to specify pagesize etc. That is really hacky, because F/MRAM devices doesn't have a pagesize. Anyway, I was already working on the at25 binding but then I've noticed that the current FRAM binding is really hardcoded to cypress devices and as mentioned in the commit message, I don't have any hardware to actually write the proper driver support. Maybe we should settle on the binding first, i.e. compatible =3D "everspin,mr25", "atmel,at25"; size =3D ; vs compatible =3D "everspin,mr25h256"; # no size needed For reference, the already supported cypress fram has the following: compatible =3D "cypress,fm25", "atmel,at25"; # no size needed, because the driver will figure it out by reading # the ID Besides that, I would really get some feedback from the three in-tree users on migrating to the EEPROM driver and thus away from MTD. -michael