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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 1FFF8C433DF for ; Thu, 9 Jul 2020 23:20:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 02DD620578 for ; Thu, 9 Jul 2020 23:20:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726918AbgGIXUi (ORCPT ); Thu, 9 Jul 2020 19:20:38 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:56234 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726560AbgGIXUh (ORCPT ); Thu, 9 Jul 2020 19:20:37 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1jtfqF-004OW7-9c; Fri, 10 Jul 2020 01:20:35 +0200 Date: Fri, 10 Jul 2020 01:20:35 +0200 From: Andrew Lunn To: Vladimir Oltean Cc: Tobias Waldekranz , netdev@vger.kernel.org, f.fainelli@gmail.com, hkallweit1@gmail.com Subject: Re: MDIO Debug Interface Message-ID: <20200709232035.GE1014141@lunn.ch> References: <20200709223936.GC1014141@lunn.ch> <20200709225725.xwmyhny4hmiyb5nt@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200709225725.xwmyhny4hmiyb5nt@skbuf> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > Fear not, the lack of a mainline UAPI for MDIO access will not prevent > any vendor from adding a sysfs mdio_read and mdio_write, if they need it > for their user space SDK :) They do. But it means you have to use their kernel, or at least their kernel module. That will put off some people. But if they can claim it works on any kernel after v5.9, it makes the marketing much easier. Like i said, it is a trade off. > Virtualization is a reasonable use case in my opinion and it would > need something like this, for the guest kernel to have access to its > PHY. And i would like a better understanding of this use case. It seems odd you are putting the driver for a PHY in the VM. Is the MAC driver also in the VM? As you said, VM context switches are expensive, so it would seem to make more sense to let the host drive the hardware, which it can do without all these context switches, and export a much simpler and efficient API to the VM. Andrew