linux-kernel - Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOesGMi9F2S4LP5pp0tR4Ax0uf3z5cOgG6UKB3r3hAmjrC9gFQ@mail.gmail.com>
Date: Fri, 16 Aug 2024 16:14:27 -0700
From: Olof Johansson <olof@...om.net>
To: Frank Li <Frank.li@....com>
Cc: Bjorn Helgaas <helgaas@...nel.org>, 
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, Rob Herring <robh@...nel.org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Lorenzo Pieralisi <lpieralisi@...nel.org>, 
	Krzysztof Wilczyński <kw@...ux.com>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Zhiqiang.Hou@....com, 
	linux-pci@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev
Subject: Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

On Fri, Aug 16, 2024 at 12:17 PM Frank Li <Frank.li@....com> wrote:
>
> On Fri, Aug 16, 2024 at 01:15:00PM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 16, 2024 at 01:09:50PM -0400, Frank Li wrote:
> > > On Fri, Aug 16, 2024 at 11:12:31AM +0530, Manivannan Sadhasivam wrote:
> > > > On Thu, Aug 15, 2024 at 03:15:52PM -0600, Rob Herring wrote:
> > > > > On Thu, Aug 15, 2024 at 9:53 AM Manivannan Sadhasivam
> > > > > <manivannan.sadhasivam@...aro.org> wrote:
> > > > > > On Thu, Aug 08, 2024 at 12:02:17PM -0400, Frank Li wrote:
> > > > > > > LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> > > > > > > PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> > > > > > > so drop maintainer information for that.
> > > > > >
> > > > > > Instead of suddenly removing the code and breaking users, you can just mark the
> > > > > > driver as 'Obsolete' in MAINTAINERS. Then after some point of time, we could
> > > > > > hopefully remove.
> > > > >
> > > > > Is anyone really going to pay attention to that? It doesn't sound like
> > > > > there's anyone to really care, and it is the company that made the h/w
> > > > > asking to remove it. The only thing people use pre-production h/w for
> > > > > once there's production h/w is as a dust collector.
> > > > >
> > > > > If anyone complains, it's simple enough to revert these patches.
> > > >
> > > > My comment was based on the fact that Bjorn was not comfortable in removing the
> > > > driver [1] unless no Rev1 boards are not in use and Frank said that he was not
> > > > sure about that [2].
> > > >
> > > > But I think if Frank can atleast guarantee that the chip never made into mass
> > > > production or shared with customers, then we can remove the driver IMO. But that
> > > > is up to the discretion of Bjorn.
> > >
> > > I think Bjorn's request is impossible task. Generally chip company send
> > > out some evaluted sample to parter, which use these sample to built up
> > > some small quantity production. Chip company have not responsibility to
> > > call back this samples. There are always some reasons to drop mobivel and
> > > switch designware, it may be caused by some IP issues which can't match
> > > mass production's requirememnt. Such informaiton already removed from
> > > nxp.com. Only Rev2 left.
> >
> > If you're reasonably confident that nobody will notice the removal of
> > support for Rev1, we can include that in the commit log and just
> > remove it.
> >
> > The original commit log basically said "we don't want to support Rev1"
> > without any indication of where those parts went or whether anybody
> > might care about them.  But if Rev1 only went to partners for
> > evaluation and we don't expect end users to have them, I think it's
> > reasonable to say that and remove the code.
>
> Thanks, I just find 2020 Yang li try to drop dts part in below thread:
>
> https://lore.kernel.org/all/CAOesGMhz8PYNG_bgMX-6gka77k1hJOZUv6xqJRqATaJ6mFbk6A@mail.gmail.com/
>
> Olof Johansson raise concern about their HoneyComb.
>
> I added Olof Johansson in this thread. I think HoneyComb use evaluation
> chip to build some small quaitity boards.
>
> As my best knowledge, rev1 should have some big problem. I can't find any
> detail about these because rev1 informaion already cleanup totally. I don't
> prefer continue use risking rev1 chip.

I paid good money for my HoneyComb, and while it was an early system,
I certainly wouldn't expect it to stop working because some maintainer
is bored of supporting it. It's clearly been commercially sold as
systems.

Mind you, I can't remember last time I powered on my system any more,
since I mostly use the Ampere board or VMs on my Mac for ARM linux
work when needed, but that doesn't mean I want to send off the
HoneyComb to recycling.

Don't regress your users. Thanks.


-Olof