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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 52F35C43381 for ; Tue, 26 Mar 2019 18:29:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 23AD920700 for ; Tue, 26 Mar 2019 18:29:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FoyCugeD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732942AbfCZS3p (ORCPT ); Tue, 26 Mar 2019 14:29:45 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:36788 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732748AbfCZS2c (ORCPT ); Tue, 26 Mar 2019 14:28:32 -0400 Received: by mail-wm1-f67.google.com with SMTP id h18so14074735wml.1 for ; Tue, 26 Mar 2019 11:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GvGaEvqAVtTvka/cWH4V57Zcp+kv0NNGeLEVxtwrQqk=; b=FoyCugeDJQ30buOpZvne7xhvaNZEd661C4Z2junQa5rai8RqmULYeqCZnnla0zBImt 7d1VKCivVl4r+BllA6e38/BAwIUZSYXUWdBwoga4a1FEMlV1hufj679GDCIO4Mmv/Lx1 mYkxLzyV83N3Z3mdMe8qJ6FuUaREJ+IVay68/Jjdxj/3YTsFuW/wtZkFkiXorfKUe0wa SNnfimgL38x9lkzdMpTGqe1B76n83HBudmbLYYMkJpKUuB9MrkQBBntvOd5abRLCM9EC 8eZxvwjjNiCqyv3AXuCmHc2Cit13D3Y9fsQIJEYRUCVRg2TyhIcBbxul5+K2xo5/OZW0 52Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GvGaEvqAVtTvka/cWH4V57Zcp+kv0NNGeLEVxtwrQqk=; b=LB/ghlbwvxileSmcs4oRbjfWgr2btt75PrFlVnw22o2cM6rZog744aDHVu8BijKgJN O4oxs9uIteTsXZ9FR01puE4KIaRHP0osAEOdss2KECWS3/5kgZWfi5ZvmmmkyPL/Epct hPB4kJTCFZo0uRsBoua7yCWgAa5zghRezvC8sxhvDSujHpHfAvXlUQg/SiYeWItm0GN+ YGKhV2n98WDhV1Qk6lh41wErjM1owmqW/irDgYmBXiN1AXqSMNZJnXYZtJixjfPXNVNM gT7zS18AYzGOybI+XWkESJMmlC1LMQW2MMfm+iuyx7vi+SR9lwSX2zCzeeA9F+xfEWzS 3IEg== X-Gm-Message-State: APjAAAUneepYMaB7lFHYYIrc+MmSrHfUKW7tFSxg2768tVtmNlQ2obJt 1HM/y6MHzPCDWqmdbqbLoLa7en3Z X-Google-Smtp-Source: APXvYqwgsBU7gVt4FLUBO6xU9+mtGEldQ1udJ/BTRxrCm3ipma5F6JucnkURUzhoZdD+Cluu3U1ybQ== X-Received: by 2002:a1c:35c5:: with SMTP id c188mr9613696wma.79.1553624911150; Tue, 26 Mar 2019 11:28:31 -0700 (PDT) Received: from ?IPv6:2003:ea:8bc4:dc00:8c1:5e0b:d735:c3dc? (p200300EA8BC4DC0008C15E0BD735C3DC.dip0.t-ipconnect.de. [2003:ea:8bc4:dc00:8c1:5e0b:d735:c3dc]) by smtp.googlemail.com with ESMTPSA id c17sm14802170wrs.17.2019.03.26.11.28.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 11:28:30 -0700 (PDT) Subject: Re: [PATCH net-next 1/2] ethtool: add PHY Fast Link Down support To: Michal Kubecek , Andrew Lunn Cc: Florian Fainelli , David Miller , "John W. Linville" , "netdev@vger.kernel.org" References: <506ae10e-5d93-f64e-a615-c320010a5529@gmail.com> <20190325174928.GF26076@unicorn.suse.cz> <20190326082438.GB31524@lunn.ch> <20190326091721.GH26076@unicorn.suse.cz> From: Heiner Kallweit Message-ID: <19bcf3af-968e-b186-e19f-87e20b24e7e9@gmail.com> Date: Tue, 26 Mar 2019 19:28:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190326091721.GH26076@unicorn.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 26.03.2019 10:17, Michal Kubecek wrote: > On Tue, Mar 26, 2019 at 09:24:38AM +0100, Andrew Lunn wrote: >>>> +#define ETHTOOL_PHY_FAST_LINK_DOWN_ON 0 >>>> +#define ETHTOOL_PHY_FAST_LINK_DOWN_OFF 0xff >>>> + >>>> enum phy_tunable_id { >>>> ETHTOOL_PHY_ID_UNSPEC, >>>> ETHTOOL_PHY_DOWNSHIFT, >>>> + ETHTOOL_PHY_FAST_LINK_DOWN, >>>> /* >>>> * Add your fresh new phy tunable attribute above and remember to update >>>> * phy_tunable_strings[] in net/core/ethtool.c >>> >>> It would be nice to have a short summary around here explaining how is >>> the value interpreted. While it's obvious from the second patch, one >>> shouldn't have to go into driver specific implementation to find out. >>> >>> I also wonder if the range 0-254 ms is sufficient. Would it be possible >>> that there is some other hardware which would support e.g. 300 ms? >> >> The default, as defined by the 802.3 standard, is i think 750ms. >> >> The Marvel PHY also supports 50ms, 20ms and 0ms, if i remember >> correctly. > > The reason why I asked about this is that PHY tunables are supposed to > be universal, not specific to a particular driver, and there might be > other hardware supporting the feature with different set of supported > values. > >> One problem we have here is discovery. How does the user find out the >> values the driver supports. For a netlink socket API, extended errors >> could be used to pass back a string indicating the supported >> values. For the old ethtool, i think all we have is -EINVAL, which is >> not very helpful. > > As supported values are determined by the driver, we would need to pass > extack to ethtool_ops handler - but that is something we will want to do > eventually (ideally, for all ethtool_ops handlers). > > AFAICS the implementation in patch 2/2 rounds user supplied value to > closest value supported by hardware so that user doesn't have to guess > which values are supported. But it would still deserve a warning via > netlink extack, IMHO. > Not to confuse Dave with the discussion: This is not about whether the patch is wrong or right, but about how a future architecture based on ethtool-nl could look like. Like Michael said, based on the current ethtool architecture it's simple: Driver will choose closest supported value. When reading back the setting you will get the exact value chosen by the driver. > Michal > . > Heiner