[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANeKEMMMYu9ugZksnJscCPROAS2vbi_BXHnJcc-MsDZMwJeTvg@mail.gmail.com>
Date: Thu, 26 Sep 2024 15:16:31 +0200
From: Erez <erezgeva2@...il.com>
To: Esben Haabendal <esben@...nix.com>
Cc: Michael Walle <mwalle@...nel.org>, Tudor Ambarus <tudor.ambarus@...aro.org>,
Erez Geva <erezgeva@...ime.org>, linux-mtd@...ts.infradead.org,
Pratyush Yadav <pratyush@...nel.org>, linux-kernel@...r.kernel.org,
Miquel Raynal <miquel.raynal@...tlin.com>, Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>, devicetree@...r.kernel.org, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Subject: Re: [PATCH v5 1/5] mtd: spi-nor: core: add manufacturer flags
On Thu, 26 Sept 2024 at 13:37, Esben Haabendal <esben@...nix.com> wrote:
>
> Erez <erezgeva2@...il.com> writes:
>
> > On Thu, 26 Sept 2024 at 09:46, Esben Haabendal <esben@...nix.com> wrote:
> >>
> >> Erez <erezgeva2@...il.com> writes:
> >>
> >> > On Mon, 23 Sept 2024 at 18:19, Michael Walle <mwalle@...nel.org> wrote:
> >> >>
> >> >> > > > I would gladly remove the obsolete mx25l12805d.
> >> >> > > Why? I don't see any need for that.
> >> >> > Maybe because we do not want compatibility table?
> >> >>
> >> >> I don't get this? Anyway, we do not remove support for older
> >> >> flashes for no reason.
> >> >
> >> > I did not insist, you asked.
> >> > Macronix stopped selling these chips 15 year ago.
> >> > How long do you want to support old chips?
> >>
> >> It is not unusual for embedded products to have a support span of more
> >> than 20 years. And chips such as these flashes might not be entirely new
> >> when the product is introduced. So dropping support for SPI-NOR flashes
> >> that are newer than 25-30 years is definitely a risk. Somebody out there
> >> might not be able to upgrade to latest kernel versions anymore, which is
> >> not a position we should put anyone in. With the increasing pressure to
> >> upgrade product for better security, we definitely should not make it
> >> more difficult to run newer kernel versions than absolutely necessary.
> >
> > I do not insist. Nor send any patch in this direction.
>
> I did not say or imply that you did any such thing.
>
> You asked an open question, and I gave my response. Nothing more,
> nothing less.
+
>
> > Each project can define the extent of backward compatibility.
> > In terms of compilers, linkers and tools, i.e. build environment.
> > In terms of standards like the C standard we use.
> > In terms of network protocols.
> > And also what Hardware do we support.
> >
> > There is no harm in asking where the boundaries are.
> > All projects move their boundaries all the time.
> > The Linux kernel is no exception.
Powered by blists - more mailing lists