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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 A7F89C47098 for ; Thu, 3 Jun 2021 15:20:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8CDAB60FF0 for ; Thu, 3 Jun 2021 15:20:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231866AbhFCPWC (ORCPT ); Thu, 3 Jun 2021 11:22:02 -0400 Received: from polaris.svanheule.net ([84.16.241.116]:39438 "EHLO polaris.svanheule.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231792AbhFCPWA (ORCPT ); Thu, 3 Jun 2021 11:22:00 -0400 Received: from [IPv6:2a02:a03f:eafb:ee01:eb34:edf2:c0ff:9e88] (unknown [IPv6:2a02:a03f:eafb:ee01:eb34:edf2:c0ff:9e88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sander@svanheule.net) by polaris.svanheule.net (Postfix) with ESMTPSA id 4D1C82081DF; Thu, 3 Jun 2021 17:20:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=svanheule.net; s=mail1707; t=1622733613; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C3soFR1tkb3QWtEaQ45qX8n9gA+coVmmtAY/2wAgXEY=; b=0MUMf/C8N2OijrODvrYxGdaBX4Duppo962UNbWKD2iDNM102o2qAjAyfPvnAg63ojfdyFY Yc0wK13qZXd8uMYqGOIw33D0OfUJhoqhhn2GwYqy6t28I8R4uKrzY5YSaFLShQMOUQfNEN z4BBI3dQlnD0/J58iDfsRczdMCs5zGzO+p21a2as2VKg8CkQiRzz/VlIE5khKCIRE9hZAO xKLxDdU3oXHk/r/B6q0lM7MFrg5KQWOSasO1g2QrT9UiLDJ0ozVRKPnxeTreMEfBI+7rAK 08TWndr2fn4Ku0kTThR2gMVNqPxIYvn+kRj+PHD3ZIkZz29pn2BXQAhfh+u88w== Message-ID: <983cb8ef005f93b650f3228256babaf7680fc0fc.camel@svanheule.net> Subject: Re: [PATCH v4 3/5] mfd: Add RTL8231 core device From: Sander Vanheule To: Andrew Lunn Cc: Andy Shevchenko , Pavel Machek , Rob Herring , Lee Jones , Linus Walleij , Michael Walle , Linux LED Subsystem , devicetree , "open list:GPIO SUBSYSTEM" , Hans de Goede , Linux Kernel Mailing List Date: Thu, 03 Jun 2021 17:20:09 +0200 In-Reply-To: References: <56fb027587fa067a249237ecaf40828cd508cdcc.1622713678.git.sander@svanheule.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2021-06-03 at 16:03 +0200, Andrew Lunn wrote: > > I wanted to make the masking explicit, but since regmap-mdio currently > > requires > > a register address width of 5 bit, it could move there. > > > > Actually, can we safely assume that any MDIO driver implementing clause-22 > > access (5-bit register address width) will just ignore higher bits? In that > > case, I could just drop these functions and not even modify regmap-mdio. It > > appears to work for bitbanged MDIO. > > How are C45 addresses handled? The API to the MDIO bus driver uses a > register value which is 32 bits in width. Bit 30 indicates the address > is a C45 address, and then you have 21 bits of actual address. > regmap-mdio needs to be generic and support both C22 and C45. Currently regmap-mdio will only accept regmap_config structs where the register width is 5 bit, but this is not enforced for the reg_read/reg_write functions and the regnum is passed verbatim to mdiobus_read/mdiobus_write. So, if I understand correctly: * for a regmap configured for C22 access, register addresses should be masked with 0x1f to create a C22 regnum * for a regmap configured for C45 access, register addresses should be masked and formatted with (MII_ADDR_C45 | (mdiodev->addr << MII_DEVADDR_C45_SHIFT) | (reg_addr 0xffff)) I would think that a device that supports both C22 and C45 access, can then just be set up to have two regmaps. If they can be considered to be independent register spaces, one regmap for each access type would make sense to me. I'll cook up a patch for this. Best, Sander