linux-kernel - Re: [PATCH 5/5] net: mtip: The L2 switch driver for imx287

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <39ec01b8-c2d7-47c3-90d9-32fe41f08a5d@kernel.org>
Date: Tue, 25 Mar 2025 18:13:10 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Lukasz Majewski <lukma@...x.de>, Andrew Lunn <andrew@...n.ch>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
 Sascha Hauer <s.hauer@...gutronix.de>, Paolo Abeni <pabeni@...hat.com>,
 Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
 davem@...emloft.net, Andrew Lunn <andrew+netdev@...n.ch>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, devicetree@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Richard Cochran <richardcochran@...il.com>,
 netdev@...r.kernel.org, Maxime Chevallier <maxime.chevallier@...tlin.com>
Subject: Re: [PATCH 5/5] net: mtip: The L2 switch driver for imx287

On 25/03/2025 17:38, Lukasz Majewski wrote:
>>>>
>>>> I don't understand this code. Do you want to re-implement
>>>> get_optional? But why?  
>>>
>>> Here the get_optional() shall be used.  
>>
>> This is the problem with trying to use old code. It needs more work
>> than just making it compile. It needs to be brought up to HEAD of
>> mainline standard, which often nearly ends in a re-write.
> 
> But you cannot rewrite this code from scratch, as the IP block is not
> so well documented, and there maybe are some issues that you are not
> aware of.
> 
> Moreover, this code is already in production use, and you don't want to
> be in situation when regression tests cannot be run.

This is a good reason to add it to staging, but not to mainline. Just
because someone has somewhere products with poor code is not the reason
to accept that poor code. Otherwise all the people and companies who
upstream BEFORE would be quite disappointed. Why anyone would care to
work on upstreaming BEFORE hardware release, if you can ship whatever to
production and then ask mainline to pick up "because it is in production
use".

Best regards,
Krzysztof