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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 10 May 2020 20:22:52 +0200 From: Andrew Lunn <andrew@...n.ch> To: Jakub Kicinski <kuba@...nel.org> Cc: Michal Kubecek <mkubecek@...e.cz>, netdev@...r.kernel.org, David Miller <davem@...emloft.net>, Florian Fainelli <f.fainelli@...il.com>, Heiner Kallweit <hkallweit1@...il.com>, Chris Healy <cphealy@...il.com>, michael@...le.cc Subject: Re: [PATCH net-next v3 06/10] net: ethtool: Add infrastructure for reporting cable test results On Sun, May 10, 2020 at 11:00:13AM -0700, Jakub Kicinski wrote: > On Sun, 10 May 2020 18:07:58 +0200 Andrew Lunn wrote: > > On Sun, May 10, 2020 at 05:12:26PM +0200, Michal Kubecek wrote: > > > On Sat, May 09, 2020 at 06:28:47PM +0200, Andrew Lunn wrote: > > > > Provide infrastructure for PHY drivers to report the cable test > > > > results. A netlink skb is associated to the phydev. Helpers will be > > > > added which can add results to this skb. Once the test has finished > > > > the results are sent to user space. > > > > > > > > When netlink ethtool is not part of the kernel configuration stubs are > > > > provided. It is also impossible to trigger a cable test, so the error > > > > code returned by the alloc function is of no consequence. > > > > > > > > v2: > > > > Include the status complete in the netlink notification message > > > > > > > > Signed-off-by: Andrew Lunn <andrew@...n.ch> > > > > > > Reviewed-by: Michal Kubecek <mkubecek@...e.cz> > > > > > > It seems you applied the changes to ethnl_cable_test_alloc() suggested > > > in v2 review as part of patch 7 rather than here. I don't think it's > > > necessary to fix that unless there is some actual problem that would > > > require a resubmit. > > > > Hi Michal > > > > Yes, squashed it into the wrong patch. But since all it does it change > > one errno for another, it is unlikely to break bisect. As i agree, we > > can live with this. > > Sorry Andrew, would you mind doing one more quick spin? :( No problem. > More importantly we should not use the ENOTSUPP error code, AFAIU it's > for NFS, it's not a standard error code and user space struggles to > translate it with strerror(). Would you mind replacing all ENOTSUPPs > with EOPNOTSUPPs? O.K. Would it be worth getting checkpatch warning about this? Andrew
Powered by blists - more mailing lists