From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A85CAC38A2A for ; Sun, 10 May 2020 18:23:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8474E20801 for ; Sun, 10 May 2020 18:23:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="TRP5b82Q" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729168AbgEJSXA (ORCPT ); Sun, 10 May 2020 14:23:00 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:52256 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728381AbgEJSXA (ORCPT ); Sun, 10 May 2020 14:23:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+wTTue85UKK8u9gn7iF3cdOlcPbNDEBhdVWO2JXxlzQ=; b=TRP5b82QvDQqP2q2KFGoHfEjS7 tKugHCr0QpNjSAXmyl1xI0rg4Nz+Orp14NRtOGECL1p1jMI6KJr6XhU5rbYTcQt/B2LFzIOyAjWT8 FVpG+lIR4UM+qhK3ixVz3jhAUliTrUSVKeWdqnzwF42i/c42Wd/CaApnOfY+tJRE/RH4=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jXqbE-001jJC-SH; Sun, 10 May 2020 20:22:52 +0200 Date: Sun, 10 May 2020 20:22:52 +0200 From: Andrew Lunn To: Jakub Kicinski Cc: Michal Kubecek , netdev@vger.kernel.org, David Miller , Florian Fainelli , Heiner Kallweit , Chris Healy , michael@walle.cc Subject: Re: [PATCH net-next v3 06/10] net: ethtool: Add infrastructure for reporting cable test results Message-ID: <20200510182252.GA411829@lunn.ch> References: <20200509162851.362346-1-andrew@lunn.ch> <20200509162851.362346-7-andrew@lunn.ch> <20200510151226.GI30711@lion.mk-sys.cz> <20200510160758.GN362499@lunn.ch> <20200510110013.0ae22016@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200510110013.0ae22016@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 > > > > > > Reviewed-by: Michal Kubecek > > > > > > 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