Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3640086pxb; Mon, 1 Nov 2021 17:53:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvoJvT0xO01DhZnjfyxvHDNhVwUJqML3r3IV+lqxc81zD5cheKws9n4v5tPlmt/LJkZfat X-Received: by 2002:a17:906:6592:: with SMTP id x18mr41521832ejn.307.1635814412068; Mon, 01 Nov 2021 17:53:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635814412; cv=none; d=google.com; s=arc-20160816; b=r9ziOTEaeybiIQor/jhDEALmZ0tUdAkLSZaXKKahetafUcI0BodgYA3nuDhJ0HsC2z Q3DTSNR76txFXb9m9ppnjcjipNGC05QEe9x01tR4Un3FHsuJV00vUwNb/p3IWFqwaYbG NtT8g4JKhj4VhStBVTg7HSRZdiYC9tt0aDq0ZX08mxGln/qpYe9Ww84Zhdr+5cGW0W6/ dGyoczFH7beyX5bTGGV1bKVQNt2AZAwF7pbNrv4KrVD6tNiJAXCDx4xZRI5Zq5wZgjKh 7iNpdf0/Kf0U1/fRzy5k18Fp7ygEa9lx01N58FqeyWrDxoCeVmdS61gWRMHEXecCAut5 JBLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Oat4dkNGPgPrMhy99YcPihYIB0B0LOufAF+2fSLtM9c=; b=mnqvEGcs4P2NTE+MzsnI8uOEgvMw1ZXurSjurTiZ4rWxEHzDbZq131OSGCE82+7APU DxsB3WF19ge/02xq4t8oRBC5MRiD/tUMIblHvwnHCoMXPJt0ClBGG1OtrYROWPREz8OH CnMbVkT0s1FVxpUcbUD85zmVcyyeKCkVgefSojESAOJPmCitOVUolnaA+Gg8Z+hLzTOs npJDH38s28mTEmvMZ0X7Jlxmoi0fygyCgoEeoOyKLLZzDTbP+Fy57YN7xKo1hxxaRWmV GKGLPEy1KHE6gBOlGeGpgYUQF0m0wkmq4cIA5MW3AF2b9cHc5v8wExPSZ3oFoQLk4D+D +73Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="3LFdum8/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g9si14016045eds.418.2021.11.01.17.53.04; Mon, 01 Nov 2021 17:53:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="3LFdum8/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230109AbhKBAw1 (ORCPT + 99 others); Mon, 1 Nov 2021 20:52:27 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:42266 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbhKBAw0 (ORCPT ); Mon, 1 Nov 2021 20:52:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=Oat4dkNGPgPrMhy99YcPihYIB0B0LOufAF+2fSLtM9c=; b=3LFdum8/tu48Iz3Tf/FCDBCcgt hQ/j3oRtBM+RJoLmYoRJ4hh6mi3g1VwB7xLyMMQwATUHAJMXk9tdD0DnGmseE6RGPYh2xAhalaTje SvwV7RbmEUDrVCSXo+5YnlRViwXItm00jzFO/iAIwkqGCHHYzlw0KgHtCO7ty7mhkGIY=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1mhhzi-00CM5B-4M; Tue, 02 Nov 2021 01:49:42 +0100 Date: Tue, 2 Nov 2021 01:49:42 +0100 From: Andrew Lunn To: "Russell King (Oracle)" Cc: Grygorii Strashko , "David S. Miller" , netdev@vger.kernel.org, Jakub Kicinski , Heiner Kallweit , Florian Fainelli , linux-kernel@vger.kernel.org, Vignesh Raghavendra Subject: Re: [RFC PATCH] net: phy/mdio: enable mmd indirect access through phy_mii_ioctl() Message-ID: References: <20211101182859.24073-1-grygorii.strashko@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > The use of the indirect registers is specific to PHYs, and we already > know that various PHYs don't support indirect access, and some emulate > access to the EEE registers - both of which are handled at the PHY > driver level. That is actually an interesting point. Should the ioctl call actually use the PHY driver read_mmd and write_mmd? Or should it go direct to the bus? realtek uses MII_MMD_DATA for something to do with suspend, and hence it uses genphy_write_mmd_unsupported(), or it has its own function emulating MMD operations. So maybe the ioctl handler actually needs to use __phy_read_mmd() if there is a phy at the address, rather than go direct to the bus? Or maybe we should just say no, you should do this all from userspace, by implementing C45 over C22 in userspace, the ioctl allows that, the kernel does not need to be involved. Andrew