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=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 7B722C433E0 for ; Thu, 2 Jul 2020 07:03:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 480E720884 for ; Thu, 2 Jul 2020 07:03:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="j2I18Eka"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=walle.cc header.i=@walle.cc header.b="HZaoPNov" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 480E720884 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FcgDdWp63zAAp2K1MDxRA5dcMSKJocIwBAHF9WqFBUE=; b=j2I18EkawT/fAcbnABDWGJhG9 TIWTvWJ9pANC1KdXkgg+9G+qA/f3nir/N1CZ8rEfjaeCHoV9pC7kbJ7A9eLwaTm2wzFXnBtUo+5Si ZGgrvw2sounsXWUXx7eK2eIK4gzqiQQwtcSVEEiyTHDL3SLDgCrQbklUcka/iqu7bSuVJyXbK+vrO T1Tij9cgdYqu+T08t8NrjlQSJQypwLCTXQKuhwQFa6dW5P6thphqBc2XmaJ9/4eCKV/Gy6MgQ9ujT c/hmpCApkl5GdLu8wX8zn6QzAlWGzpVJWES+IPBLK7mVyDQDqYirblSOJVhjf1bDXGgZuKFueWIvh dKFkcgsWA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqtEg-0002mw-PC; Thu, 02 Jul 2020 07:02:18 +0000 Received: from ssl.serverraum.org ([176.9.125.105]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqtEd-0002m6-5Y for linux-arm-kernel@lists.infradead.org; Thu, 02 Jul 2020 07:02:17 +0000 Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 905E6226F6; Thu, 2 Jul 2020 09:02:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1593673328; 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=pQTu4YMfujJ6SsFKBNKHKnCTWInZclRPA0DmiPcnXYk=; b=HZaoPNovjNwu6Yk/SOwWYw1fhIdC38F9BrryUbHU8llqhJMlKSvgQMMyA0Z8KtxVxvD9P1 2VZfRjm8Vl+MptUj/8XoC1+VWT58nEGQfdbsgKadyjtWyWGEaYmau91kEkBY0Lv1qkJOJ1 gcCM9ZC/sJFsMEnIEVAO3Pa0kWmJliU= MIME-Version: 1.0 Date: Thu, 02 Jul 2020 09:02:05 +0200 From: Michael Walle To: Lee Jones Subject: Re: [PATCH v4 1/1] mfd: Add I2C based System Configuaration (SYSCON) access In-Reply-To: <20200702065412.GO1179328@dell> References: <20200622075145.1464020-1-lee.jones@linaro.org> <20200701070434.GP1179328@dell> <5d1d41504172d86d395b0135923f6f02@walle.cc> <20200702065412.GO1179328@dell> User-Agent: Roundcube Webmail/1.4.6 Message-ID: X-Sender: michael@walle.cc X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200702_030215_540468_30A51614 X-CRM114-Status: GOOD ( 31.62 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org, linus.walleij@linaro.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, bgolaszewski@baylibre.com, broonie@kernel.org, andriy.shevchenko@linux.intel.com, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am 2020-07-02 08:54, schrieb Lee Jones: > On Wed, 01 Jul 2020, Michael Walle wrote: > >> Am 2020-07-01 09:04, schrieb Lee Jones: >> > On Wed, 01 Jul 2020, Michael Walle wrote: >> > >> > > Hi Lee, >> > > >> > > Am 2020-06-30 11:16, schrieb Michael Walle: >> > > > I'm just trying to use this for my sl28 driver. Some remarks, see below. >> > > > >> > > > Am 2020-06-22 09:51, schrieb Lee Jones: >> > > > > The existing SYSCON implementation only supports MMIO (memory mapped) >> > > > > accesses, facilitated by Regmap. This extends support for registers >> > > > > held behind I2C busses. >> > > > > >> > > > > Signed-off-by: Lee Jones >> > > > > --- >> > > > > Changelog: >> > > > > >> > > > > v3 => v4 >> > > > > - Add ability to provide a non-default Regmap configuration >> > > > > >> > > > > v2 => v3 >> > > > > - Change 'is CONFIG' present check to include loadable modules >> > > > > - s/#ifdef CONFIG_MFD_SYSCON_I2C/#if >> > > > > IS_ENABLED(CONFIG_MFD_SYSCON_I2C)/ >> > > > > >> > > > > v1 => v2 >> > > > > - Remove legacy references to OF >> > > > > - Allow building as a module (fixes h8300 0-day issue) >> > > > > >> > > > > drivers/mfd/Kconfig | 7 +++ >> > > > > drivers/mfd/Makefile | 1 + >> > > > > drivers/mfd/syscon-i2c.c | 104 >> > > > > +++++++++++++++++++++++++++++++++ >> > > > > include/linux/mfd/syscon-i2c.h | 36 ++++++++++++ >> > > > > 4 files changed, 148 insertions(+) >> > > > > create mode 100644 drivers/mfd/syscon-i2c.c >> > > > > create mode 100644 include/linux/mfd/syscon-i2c.h > > [...] > >> > > > This way, (a) a driver doesn't have to use "#include " just >> > > > to call to_i2c_client() (or i2c_verify_client()) and (b) you won't do it >> > > > all over again in all sub drivers. >> > > > >> > > > So you could just do a >> > > > regmap = syscon_i2c_to_regmap(pdev->dev.parent); >> > > > >> > > > I've also noticed that the mmio syscon uses device_node as parameter. >> > > > What >> > > > was the reason to divert from that? Just curious. >> > > >> > > How is this supposed to be used? >> > > >> > > I had something like the following in mind: >> > > >> > > &i2c { >> > > cpld@4a { >> > > compatible = "simple-mfd"; >> > > reg = <0x4a>; >> > > >> > > gpio@4 { >> > > compatible = "vendor,gpio"; >> > > reg = <0x4>; >> > > }; >> > > }; >> > > }; >> > >> > Yes, that was the idea. >> > >> > > But I think the childen are not enumerated if its an I2C device. And >> > > the actual i2c driver is also missing. >> > >> > What do you mean? Can you elaborate? >> >> There is no i2c_driver instance who would create the regmap. > > The regmap is created by the first caller of: > > syscon_i2c_to_regmap{_config}() But which one is an i2c_driver? All the sub devices are platform drivers and there should be no need for them to know that they are behind an i2c driver (or spi driver or just mmio). All they have to know is how to access the registers. >> If I'm >> reading the I2C code correctly, it won't probe any i2c device of a >> bus if there is no i2c_driver with an associated .probe() or >> .probe_new(). > > Why wouldn't the children be registered using i2c_driver? Where is the code which enumerates the children? >> And even if it is probed, its subnodes won't be >> enumerated; the "simple-mfd" code only works for MMIO busses, right? >> Or I'm getting something really wrong here.. > > Then how are these I2C based devices able to call > of_platform_populate()? I don't mean they can't do it, I mean, I'm calling of_platform_populate() myself. But who is actually calling it when one uses the this patch series? -michael > drivers/mfd/gateworks-gsc.c > drivers/mfd/lochnagar-i2c.c > drivers/mfd/palmas.c > drivers/mfd/smsc-ece1099.c > drivers/mfd/stpmic1.c > drivers/mfd/twl-core.c > > Might require some more research into where your use-case is breaking > down. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel