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.
