Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2736141pxf; Sun, 4 Apr 2021 12:27:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBZFjw9tXNbkGV2UJZzMuHkUadJBKCFCLd7EH5F0sFfM3uQwtiWNM5LZJ6tovO2QFv5GBO X-Received: by 2002:a02:c908:: with SMTP id t8mr21065083jao.78.1617564476394; Sun, 04 Apr 2021 12:27:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617564476; cv=none; d=google.com; s=arc-20160816; b=C/uc/QYb1CiURr5tkbjimzkCJGSEd/9b7FgBSWmvfHuW3c/ik5qtHBTYHX6CaBhAMx 3lrLXsMIXDYU6yw88zysSjwzgnLAgPGHKECOHk+5g3xQA3OG7RbVH+P297SgAoMKmwv6 SPx/VUuVSXJOKr+k2GK8Td7R2DXNBynGx/iNQ3Gngvdkeab7JisgcuzglPrDN89di2ix 2t+YBf7IjU8NdGJAkyWS5EvMk6wiNGz8+hltVasCLSWwHt8FM5nYjUKlQsoXxeBKrCGp NbjVbpZXMZ4zhPW8xGDIUVOM0Thp9frKa0V2ALYMKmFWMy3Kn6m/gnnjxDMb+9V0XI/l iiqw== 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; bh=/jYV2agxJn2d/uK6E4eA19Ui9sFtbaeAUbGwKTEmKsE=; b=jRP1VO02jA6WyCqtcoDFDkuS7zpU3hwjVx+yfl3xP99pfyycq1tIhnz+eDp5O00Wms aiLACdyMIwrBl+xgqOvfO5J0Yg4bxya7pH+1LLyxciIafFrF1y+P0y+WQPcVhDz7Qrjm ufNK7CfnaTYRjzbCpgnmX3i+eWS0rF+OP9brfzMGdT7o8wKrHH/xXdmhvNng5EblDgn6 xdq+pOj8cEHhm/j5NM6XRwRb5llQAr3ho6yNVvTezn63p2yFx8Mcwo3Ibzii4r3y+gkK 8GxEHF4Sc/cj6vf5ijQnLNk2dLBAyz75PUzetRoWrtVmsznt35Ki4nMa/PLyMPOvzkFR uCLw== ARC-Authentication-Results: i=1; mx.google.com; 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 s21si12976829iov.70.2021.04.04.12.27.17; Sun, 04 Apr 2021 12:27:56 -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; 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 S231396AbhDDTYK (ORCPT + 99 others); Sun, 4 Apr 2021 15:24:10 -0400 Received: from hs01.dk-develop.de ([173.249.23.66]:46914 "EHLO hs01.dk-develop.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231284AbhDDTYJ (ORCPT ); Sun, 4 Apr 2021 15:24:09 -0400 Date: Sun, 4 Apr 2021 21:23:55 +0200 From: Danilo Krummrich To: Russell King - ARM Linux admin Cc: Andrew Lunn , davem@davemloft.net, hkallweit1@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jeremy.linton@arm.com Subject: Re: [PATCH 2/2] net: mdio: support c45 peripherals on c22 busses Message-ID: References: <20210331141755.126178-1-danilokrummrich@dk-develop.de> <20210331141755.126178-3-danilokrummrich@dk-develop.de> <6f1dfc28368d098ace9564e53ed92041@dk-develop.de> <20210331183524.GV1463@shell.armlinux.org.uk> <2f0ea3c3076466e197ca2977753b07f3@dk-develop.de> <20210401084857.GW1463@shell.armlinux.org.uk> <20210402125858.GB1463@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210402125858.GB1463@shell.armlinux.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 02, 2021 at 01:58:58PM +0100, Russell King - ARM Linux admin wrote: > On Fri, Apr 02, 2021 at 03:10:49AM +0200, Danilo Krummrich wrote: > > On Thu, Apr 01, 2021 at 09:48:58AM +0100, Russell King - ARM Linux admin wrote: > > > One could also argue this is a feature, and it allows userspace to > > > know whether C45 cycles are supported or not. > > > > > No, if the userspace requests such a transfer although the MDIO controller > > does not support real c45 framing the kernel will call mdiobus_c45_addr() to > > join the devaddr and and regaddr in one parameter and pass it to > > mdiobus_read() or mdiobus_write(). A bus driver not supporting c45 framing > > will not care and just mask/shift the joined value and write it to the > > particular register. Obviously, this will result into complete garbage being > > read or (even worse) written. > > > We have established that MDIO drivers need to reject accesses for > reads/writes that they do not support - this isn't something that > they have historically checked for because it is only recent that > phylib has really started to support clause 45 PHYs. > I see, that's why you consider it a feature - because it is. What do you think about adding a flag MDIO_PHY_ID_MMD (or similar) analog to MDIO_PHY_ID_C45 for phy_mii_ioctl() to check for, such that userspace can ask for an indirect access in order to save userspace doing the indirect access itself. A nice side effect would be saving 3 syscalls per request. > More modern MDIO drivers check the requested access type and error > out - we need the older MDIO drivers to do the same. > So currently every driver should check for the flag MII_ADDR_C45 and report an error in case it's unsupported. What do you think about checking the bus' capabilities instead in mdiobus_c45_*()? This way the check if C45 is supported can even happen before calling the driver at all. I think that would be a little cleaner than having two places where information of the bus' capabilities are stored (return value of read/write functions and the capabilities field). I think there are not too many drivers setting their capabilities though, but it should be easy to derive this information from how and if they handle the MII_ADDR_C45 flag.