From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC88414D29E for ; Thu, 6 Jun 2024 12:03:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717675417; cv=none; b=jdfCxVMRiSW/bPDAe6oX43Fu315OrBfhi0Xl+QVGXZFgtqBUX6U/BaPPy0kp43PXuoumRj/+D1jmwK1EtmAB9wsLfaQn1d6JBcJrecVyEjLxlnrvNXnKsiveHzV3Z0ygmlKPpbQE6iPqFf0VTZ5hw8vMt1yQ53AVqXn+KXg8ztk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717675417; c=relaxed/simple; bh=aNpXvfN77ldJ43zIxp6GfuvwOV+4cBY5Tw8CrZX/K4k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hMhcDk+LecKdk7IBFTl9lnNiuiCeDZaYPqVGmcyZT9oDZyHMDqc4hh6VbB6hJacYf9UQG5TEVkIirzPk16CAK1osmhyv1n3+0jNk1MX2rv0PyT5HcY1ouJuEiMiQ6WfRydYroISuF+/89QHuTjqfP8ThIq7Wg+FwkKH8WL0P5b8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=yNdGafmt; arc=none smtp.client-ip=209.85.218.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="yNdGafmt" Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a66e9eac48fso96020266b.2 for ; Thu, 06 Jun 2024 05:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1717675414; x=1718280214; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+vPS4Wu3K1+SNHP7/UCC3zuql6I1R/Uod3WHUVV4Y/k=; b=yNdGafmtvMWC9nFxaK2Ca0EctQhOJeDEgbruhnDMEOB3/GpzKlrmtit8tQoMguOZon hBkr/ygCs9ZEovohKzry0CKndQA9rCn1KkuaQqrm079p1sSjjfv5ljh5E2wZStjHVfwn WG0MoGJYzeSvVmu233WFh+14X+7SVv8FtBxbQ5quEDb7/HQ4j1q+qmAVkRDfAYJCbUeO mn8dXORNcD6DcKn/ly3q9iy7NAGiWDxEbU0Dwx4UyaTpnCLlZ90n7ev4he+6WIgrc4Bo 1r6Vf1PPsLxDmLJtRHo7M+2/ox7oRe/fj/4LoRkduGS86vwc3o4jTVUs8LNpr8cSyOoA 5HWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717675414; x=1718280214; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+vPS4Wu3K1+SNHP7/UCC3zuql6I1R/Uod3WHUVV4Y/k=; b=OAk7A7zkBUTCjCQmhL89pZNckkQ1MOIkgbdHXoft6Wj/95muGISMrnwXtL6uNRQgOw JiNZy8z9eE8s9t3T/y7LI9v5l3mWVIZRICv6ao0PBpVtmUteF/eA7vjWeMfuOZY0DUDb CnCgjgZ9Ou5cHAmxrIEOPgrUjOiTH9OrE99OwVAv2G4Jk35Y+arJ0Q8TyK4TsZjRweU0 6xkbcs/CjqRf2L8b5rGdhRjO2sdZ82QI/SjJfyqI3fb+2edP7lat/It9U0hzt3IEAJIG kv/9KTn5ccBZAdktdx6YtGfINh7EyaOuF7INbfnxLw9/up7ez2STpIkFgbmAAotbw239 7vDA== X-Forwarded-Encrypted: i=1; AJvYcCX8qbH7wTc0qBtBpkKPIHY5zAKYsFZfzvjjutI74G1NTa+BmhipT4JmKSOD/Z3Oj5uFCaRnikT/ZTmkLZDenaa65hiQ6O6CdPVuaw== X-Gm-Message-State: AOJu0YzK2MkD0PaWVpOOdW4O3ZyaXFv9riXmesBfldVtYtL/YNkJ2PPH V0hSCeWJ0uuom2FaKubj6L8qZCuNE8dTdS3Ck8QEvPcIMWjOa61ra1cgAh9lExA= X-Google-Smtp-Source: AGHT+IFmMz1GmHTUvHk6s/qP+CRB/I1EcEnEfMew6pgb89m5yDF7bhdBICxRyQM/+EXeB1BQOKXDcQ== X-Received: by 2002:a17:906:4915:b0:a66:d1a1:f92f with SMTP id a640c23a62f3a-a699f34da1emr363268166b.14.1717675414101; Thu, 06 Jun 2024 05:03:34 -0700 (PDT) Received: from [192.168.2.107] ([79.115.63.17]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6c8070e839sm89223766b.176.2024.06.06.05.03.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jun 2024 05:03:33 -0700 (PDT) Message-ID: <0bb5cdc8-37fe-42c1-a18e-bb1494924095@linaro.org> Date: Thu, 6 Jun 2024 13:03:31 +0100 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices To: Conor Dooley , Michael Walle Cc: Pratyush Yadav , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Thorsten Scherer , Marek Vasut , Imre Kaloz , Andrew Lunn , Flavio Suligoi , Takahiro Kuwano , Bacem.Daassi@infineon.com References: <20240604074231.1874972-1-mwalle@kernel.org> <20240604-ladylike-gout-6fd6ae992712@spud> <20240605-cosmetics-upgrade-837934256ede@spud> Content-Language: en-US From: Tudor Ambarus In-Reply-To: <20240605-cosmetics-upgrade-837934256ede@spud> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 6/5/24 18:40, Conor Dooley wrote: > On Tue, Jun 04, 2024 at 07:42:16PM +0200, Michael Walle wrote: >> 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. >>>> >>>> Signed-off-by: Michael Walle >>>> Cc: Uwe Kleine-König >>>> 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. >>>> >>>> There are three in-tree users of this. I hope I've CCed all the relevant >>>> 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. >>>> >>>> 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(-) >>>> >>>> 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|25635e)|\ >>>> (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/eeprom/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 Takahiro from cc may help with the cypress FRAM testing. >> hardware to actually write the proper driver support. Maybe we >> should settle on the binding first, i.e. >> >> compatible = "everspin,mr25", "atmel,at25"; >> size = ; >> >> vs >> >> compatible = "everspin,mr25h256"; # no size needed > > I dunno, I am usually biased to having the more specific compatible > and not needing the extra properties. I agree with the more specific compatible idea, but we shall aim that the specific compatible to be generic: "spi-fram" and maybe "spi-mram". Can it be done? > >> >> For reference, the already supported cypress fram has the following: >> >> compatible = "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 >>