From patchwork Thu Apr 8 20:52:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sander Vanheule X-Patchwork-Id: 417729 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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable 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 DA27CC43461 for ; Thu, 8 Apr 2021 20:52:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B2E2D61177 for ; Thu, 8 Apr 2021 20:52:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231676AbhDHUw7 (ORCPT ); Thu, 8 Apr 2021 16:52:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232156AbhDHUw7 (ORCPT ); Thu, 8 Apr 2021 16:52:59 -0400 Received: from polaris.svanheule.net (polaris.svanheule.net [IPv6:2a00:c98:2060:a004:1::200]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50F45C061762 for ; Thu, 8 Apr 2021 13:52:47 -0700 (PDT) Received: from terra.local.svanheule.net (unknown [IPv6:2a02:a03f:eaff:9f01:6fea:16c6:2e86:c69]) (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 D173F1ECD38; Thu, 8 Apr 2021 22:52:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=svanheule.net; s=mail1707; t=1617915165; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=sG03pRQrsSv16JasG5fXBdpoORWxuYvG5/eb22d+2KY=; b=p66tD7p82IwvsJh81iGfIwzdgVgsz0HbrvfkXoojdsFWA/nxpYSTSsOaJ6xs1iRQt8z52v 00AKQFOkaOwxZNKgMon+nxrCvpcIpERTUG1N/OhGpcc3yY7DdcOJjghOmMQe+cTzBfCe5L N/CNnVHwpl1wWpzeXFZxOD4masedh5KryAqXO6h1KhbSpHPFjVSCHGzzAPBoWjssjBNHoO CwjeZ1JgEBC5G9/Yxq7xPHgsyljVPirjKyDFNINsaRPKblN8J9oSPWKzF3FhiTtIj1+NGG /N61FFXRbyvCXjg9i7U7JziZEWib7HYxPvuGLDnKLsI8qfaNKhhLrKufhFxCeA== From: Sander Vanheule To: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, Mark Brown , Greg Kroah-Hartman , "Rafael J . Wysocki" Cc: bert@biot.com, Sander Vanheule Subject: [RFC PATCH 0/2] MIIM regmap and RTL8231 GPIO expander support Date: Thu, 8 Apr 2021 22:52:33 +0200 Message-Id: X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org The RTL8231 GPIO and LED expander can be configured for use as an MIIM or I2C bus device. To provide uniform data access between these two modes, the regmap interface is used. Since no regmap interface exists for MIIM busses, a basic implementation is provided. Currently outstanding questions: - The REGMAP_MIIM symbol should depend on MDIO_DEVICE (or a better suited, related symbol), but this results in circular Kconfig dependencies: drivers/of/Kconfig:69:error: recursive dependency detected! drivers/of/Kconfig:69: symbol OF_IRQ depends on IRQ_DOMAIN kernel/irq/Kconfig:59: symbol IRQ_DOMAIN is selected by REGMAP drivers/base/regmap/Kconfig:7: symbol REGMAP default is visible depending on REGMAP_MIIM drivers/base/regmap/Kconfig:39: symbol REGMAP_MIIM depends on MDIO_DEVICE drivers/net/mdio/Kconfig:6: symbol MDIO_DEVICE is selected by PHYLIB drivers/net/phy/Kconfig:16: symbol PHYLIB is selected by ARC_EMAC_CORE drivers/net/ethernet/arc/Kconfig:19: symbol ARC_EMAC_CORE is selected by ARC_EMAC drivers/net/ethernet/arc/Kconfig:25: symbol ARC_EMAC depends on OF_IRQ Suggestions on how to resolve this are welcome. - Providing no compatible for an MDIO child node is considered to be equivalent to a c22 ethernet phy, so one must be provided. However, this node is then not automatically probed. Is it okay to provide a binding without a driver? If some code is required, where should this be put? Current devicetree structure: mdio-bus { compatible = "vendor,mdio"; ... expander0: expander@0 { /* * Provide compatible for working registration of mdio device. * Device probing happens in gpio1 node. */ compatible = "realtek,rtl8231-expander"; reg = <0>; }; }; gpio1 : ext_gpio { compatible = "realtek,rtl8231-mdio"; gpio-controller; ... }; - MFD driver: The RTL8231 is not just a GPIO expander, but also a pin controller and LED matrix controller. Regmap initialisation could probably be moved to a parent MFD, with gpio, led, and pinctrl cells. Is this a hard requirement if only a GPIO controller is provided? Sander Vanheule (2): regmap: add miim bus support gpio: Add Realtek RTL8231 support drivers/base/regmap/Kconfig | 6 +- drivers/base/regmap/Makefile | 1 + drivers/base/regmap/regmap-miim.c | 58 +++++ drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-rtl8231.c | 404 ++++++++++++++++++++++++++++++ include/linux/regmap.h | 36 +++ 7 files changed, 514 insertions(+), 1 deletion(-) create mode 100644 drivers/base/regmap/regmap-miim.c create mode 100644 drivers/gpio/gpio-rtl8231.c