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: <YwgOXL6mFdt8hk+b@lunn.ch> Date: Fri, 26 Aug 2022 02:05:48 +0200 From: Andrew Lunn <andrew@...n.ch> To: Jakub Kicinski <kuba@...nel.org> Cc: Marek Behún <kabel@...nel.org>, Marcus Carlberg <marcus.carlberg@...s.com>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, kernel@...s.com, Pavana Sharma <pavana.sharma@...i.com>, Ashkan Boldaji <ashkan.boldaji@...i.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v3] net: dsa: mv88e6xxx: support RGMII cmode On Thu, Aug 25, 2022 at 04:42:06PM -0700, Jakub Kicinski wrote: > On Fri, 26 Aug 2022 01:26:59 +0200 Marek Behún wrote: > > > Could you explain why? Is there an upstream-supported platform > > > already in Linus's tree which doesn't boot or something? > > > > If you mean whether there is a device-tree of such a device, they I > > don't think so, because AFAIK there isn't a device-tree with 6393 in > > upstream Linux other than CN9130-CRB. > > > > But it is possible though that there is such a device which has > > everything but the switch supported on older kernels, due to this RGMII > > bug. > > > > I think RGMII should have been supported on this switch when I send the > > patch adding support for it, and it is a bug that it is not, becuase > > RGMII is supported for similar switches driven by mv88e6xxx driver > > (6390, for example). I don't know why I overlooked it then. > > > > Note that I wouldn't consider adding support for USXGMII a fix, because > > although the switch can do it, it was never done with this driver. > > > > But if you think it doesn't apply anyway, remove the Fixes tag. This is > > just my opinion that it should stay. > > I see, I can only go by our general guidance of not treating omissions > as fixes, but I lack the knowledge to be certain what's right here. > Anyone willing to cast a tie-break vote? Andrew? net or net-next? Stable rules say: o It must fix a real bug that bothers people (not a, “This could be a problem…” type thing). We know anything with a Fixes: tag pretty much gets considered as a candidate for stable by the machine learning bot, even if we don't mark it so. So i would say drop the Fixes: tag, it does not fulfil the stable requirements. Andrew
Powered by blists - more mailing lists