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 A51B3C47096 for ; Thu, 3 Jun 2021 11:28:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8657761287 for ; Thu, 3 Jun 2021 11:28:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229629AbhFCLab (ORCPT ); Thu, 3 Jun 2021 07:30:31 -0400 Received: from polaris.svanheule.net ([84.16.241.116]:35140 "EHLO polaris.svanheule.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229702AbhFCLab (ORCPT ); Thu, 3 Jun 2021 07:30:31 -0400 Received: from [IPv6:2a02:a03f:eafb:ee01:398f:956e:2c86:f184] (unknown [IPv6:2a02:a03f:eafb:ee01:398f:956e:2c86:f184]) (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 35D2B2080B3; Thu, 3 Jun 2021 13:28:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=svanheule.net; s=mail1707; t=1622719725; 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=uy7edqnqtaAtBfOfz9dzIFfc/RSIZezcm98QJ+kd+pE=; b=rjue1kvPQCF8teUA4zwFe2KhhwYS58jf/JZvoxI2Z2CeeO6RERVPNNTrN+01Bi1VBdNwnC FrGIN2vSuHzr/rZrK4pmMPVjPvoJn9mTge44lYbJavcC+tkgeQ8nrWuz9RPhIX1bgEwc4K yxCpBCt2ejTJRaEPyqxf2oOsxhPAdCufUu1UWcevbDk/jRJln+tds0HvcZiEWvqTYnlFES E62QrB5ah+CPN35IsglmUoS76Ee9PNycwvVhVqwYKOpIBVtehDwG3ELV6KcjFbKYcGZb0F udI5N0Fl3biJbM8fOFPoZyPGAlLmwnfD24b9cc6Ohbl0AOKIPGTVFuMmxanD5g== Message-ID: Subject: Re: [PATCH v4 3/5] mfd: Add RTL8231 core device From: Sander Vanheule To: Andy Shevchenko Cc: Pavel Machek , Rob Herring , Lee Jones , Linus Walleij , Michael Walle , Linux LED Subsystem , devicetree , "open list:GPIO SUBSYSTEM" , Hans de Goede , Andrew Lunn , Linux Kernel Mailing List Date: Thu, 03 Jun 2021 13:28:42 +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: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Thu, 2021-06-03 at 13:58 +0300, Andy Shevchenko wrote: > On Thu, Jun 3, 2021 at 1:01 PM Sander Vanheule wrote: > > > > The RTL8231 is implemented as an MDIO device, and provides a regmap > > interface for register access by the core and child devices. > > > > The chip can also be a device on an SMI bus, an I2C-like bus by Realtek. > > Since kernel support for SMI is limited, and no real-world SMI > > implementations have been encountered for this device, this is currently > > unimplemented. The use of the regmap interface should make any future > > support relatively straightforward. > > > > After reset, all pins are muxed to GPIO inputs before the pin drivers > > are enabled. This is done to prevent accidental system resets, when a > > pin is connected to the parent SoC's reset line. > > > > To provide different read and write semantics for the GPIO data > > registers, a secondary virtual register range is used to enable separate > > cacheing properties of pin input and output values. > > caching > > ... > > > > +static int rtl8231_reg_read(void *context, unsigned int reg, unsigned int > > *val) > > +{ > > +       struct mdio_device *mdio_dev = context; > > +       int ret; > > + > > +       ret = mdiobus_read(mdio_dev->bus, mdio_dev->addr, > > RTL8231_REAL_REG(reg)); > > + > > +       if (ret < 0) > > +               return ret; > > + > > +       *val = ret & 0xffff; > > + > > +       return 0; > > +} > > + > > +static int rtl8231_reg_write(void *context, unsigned int reg, unsigned int > > val) > > +{ > > +       struct mdio_device *mdio_dev = context; > > + > > +       return mdiobus_write(mdio_dev->bus, mdio_dev->addr, > > RTL8231_REAL_REG(reg), val); > > +} > > Hmm... Maybe we can amend regmap-mdio to avoid duplication of the > above? Something like xlate in gpio-regmap or so? > 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. > > +       mdiodev->reset_gpio = devm_gpiod_get_optional(dev, "reset", > > GPIOD_OUT_LOW); > > Missed > >   if (IS_ERR(mdiodev->reset_gpio)) >     return PTR_ERR(mdiodev->reset_gpio); > Will fix. Best, Sander