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
| ||
|
Message-ID: <1aadcc20-4ee7-af56-36db-1d036c7747c5@arinc9.com> Date: Wed, 29 Mar 2023 00:26:46 +0300 From: Arınç ÜNAL <arinc.unal@...nc9.com> To: Vladimir Oltean <olteanv@...il.com> Cc: Sean Wang <sean.wang@...iatek.com>, Landen Chao <Landen.Chao@...iatek.com>, DENG Qingfang <dqfext@...il.com>, Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Matthias Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Russell King <linux@...linux.org.uk>, René van Dorst <opensource@...rst.com>, Russell King <rmk+kernel@...linux.org.uk>, Ilya Lipnitskiy <ilya.lipnitskiy@...il.com>, Richard van Schagen <richard@...terhints.com>, Richard van Schagen <vschagen@...com>, Frank Wunderlich <frank-w@...lic-files.de>, erkin.bozoglu@...ont.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org Subject: Re: [PATCH net 4/7] net: dsa: mt7530: set both CPU port interfaces to PHY_INTERFACE_MODE_NA On 28/03/2023 14:20, Vladimir Oltean wrote: > On Tue, Mar 28, 2023 at 12:57:57AM +0300, Arınç ÜNAL wrote: >> I don't appreciate your consistent use of the word "abuse" on my patches. > > Consistent would mean that, when given the same kind of input, I respond > with the same kind of output. I'm thinking you'd want a reviewer to do that? Of course. > > Last time I said: "It's best not to abuse the net.git tree with non-bugfix patches." > https://patchwork.kernel.org/project/netdevbpf/patch/20230307220328.11186-1-arinc.unal@arinc9.com/ > > If anything, Jakub was/is slightly inconsistent by accepting those previous > non-bugfix patches to the net.git tree, and then agreeing with me. He probably > did that thinking it wasn't a hill worth dying on, which I can agree with. > But I'm afraid that this didn't help you realize that yes, maybe you really > are abusing the process by submitting exclusively non-bugfix commits to the > net tree. There's a fine balance between trying to be nice and trying not to > transmit the wrong message. > > It would be good if you could clarify your objection regarding my consistent > use of the word "abuse" on your patches. > > There is a document at Documentation/process/stable-kernel-rules.rst > which I remember having shared with you before, where there are some > indications as to what constitutes a legitimate candidate for "stable" > and what does not. I forgot this existed, sorry about that. I had this thought left in my mind that "any changes that are not new features must go to the net tree", which clearly is not the case. I see what you mean now. None of my patches on the series satisfy all of the rules specified on the document. I just think your response could've been less harsh considering I didn't intentionally do this. Anyway, it's all resolved now so let's not drag this further. > >> I'm by no means a senior C programmer. I'm doing my best to correct the >> driver. >> >> Thank you for explaining the process of phylink with DSA, I will adjust my >> patches accordingly. >> >> I suggest you don't take my patches seriously for a while, until I know >> better. > > Whether you're a junior or a senior C programmer is entirely irrelevant > here. I have no choice but to take your patches seriously unless otherwise > specified, in the commit message, cover letter, or by marking them as > RFC/RFT (but even then, their intention must be very clearly specified, > so that I know what to comment on, or test). > > I don't think you really want what you're asking for, which is for > people to not take your patches seriously. I recommend forming a smaller > community of people which does preliminary patch review and discusses > issues around the hardware you're working on, prior to upstream submission. > That would, at least, be more productive. Yes, of course. I'm actually planning something similar that involves OpenWrt, thanks. Arınç
Powered by blists - more mailing lists