On Thu, 26 Sept 2024 at 13:37, Esben Haabendal <esben@xxxxxxxxxx> wrote: > > Erez <erezgeva2@xxxxxxxxx> writes: > > > On Thu, 26 Sept 2024 at 09:46, Esben Haabendal <esben@xxxxxxxxxx> wrote: > >> > >> Erez <erezgeva2@xxxxxxxxx> writes: > >> > >> > On Mon, 23 Sept 2024 at 18:19, Michael Walle <mwalle@xxxxxxxxxx> 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.
