On Fri, Aug 16, 2024 at 12:17 PM Frank Li <Frank.li@xxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/ > > 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
