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=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 63288C47255 for ; Mon, 11 May 2020 21:45:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3848020752 for ; Mon, 11 May 2020 21:45:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=walle.cc header.i=@walle.cc header.b="ZuzW3gEV" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725912AbgEKVpF (ORCPT ); Mon, 11 May 2020 17:45:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725860AbgEKVpF (ORCPT ); Mon, 11 May 2020 17:45:05 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4D32C061A0C; Mon, 11 May 2020 14:45:02 -0700 (PDT) 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 425DF23E4D; Mon, 11 May 2020 23:44:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1589233499; 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=mUeXc7qWDqMsAtbmJANeooU975mp9voikExXUtAFyd4=; b=ZuzW3gEV27FW2OH77G50DUqIKwSr42+SNZXiF4IiL/x/xPKFd7o/8WjGXnjzVnF9r/m+nB ssw9jCD2ST5osYVZ1HaXphfRYwygT2ZucLtvS/LLW9YdkovQ6FaMYje0dUpU07z8LBZFqy bZhJbEpmpgmLqlQGh2PaJrHX77NFMTE= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 May 2020 23:44:58 +0200 From: Michael Walle To: Rob Herring Cc: Andy Shevchenko , linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-pwm@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linus Walleij , Bartosz Golaszewski , Jean Delvare , Guenter Roeck , Lee Jones , Thierry Reding , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Wim Van Sebroeck , Shawn Guo , Li Yang , Thomas Gleixner , Jason Cooper , Marc Zyngier , Mark Brown , Greg Kroah-Hartman Subject: Re: [PATCH v3 05/16] mfd: Add support for Kontron sl28cpld management controller In-Reply-To: <20200511211359.GB3518@bogus> References: <20200423174543.17161-1-michael@walle.cc> <20200423174543.17161-6-michael@walle.cc> <20200511211359.GB3518@bogus> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: michael@walle.cc Sender: linux-hwmon-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org Am 2020-05-11 23:13, schrieb Rob Herring: > On Thu, Apr 23, 2020 at 07:45:32PM +0200, Michael Walle wrote: >> This patch adds core support for the board management controller found >> on the SMARC-sAL28 board. It consists of the following functions: >> - watchdog >> - GPIO controller >> - PWM controller >> - fan sensor >> - interrupt controller >> >> At the moment, this controller is used on the Kontron SMARC-sAL28 >> board. >> >> Please note that the MFD driver is defined as bool in the Kconfig >> because the next patch will add interrupt support. >> >> Signed-off-by: Michael Walle >> --- >> drivers/mfd/Kconfig | 19 +++++ >> drivers/mfd/Makefile | 2 + >> drivers/mfd/sl28cpld.c | 153 >> +++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 174 insertions(+) >> create mode 100644 drivers/mfd/sl28cpld.c >> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig >> index 0a59249198d3..be0c8d93c526 100644 >> --- a/drivers/mfd/Kconfig >> +++ b/drivers/mfd/Kconfig >> @@ -2060,5 +2060,24 @@ config SGI_MFD_IOC3 >> If you have an SGI Origin, Octane, or a PCI IOC3 card, >> then say Y. Otherwise say N. >> >> +config MFD_SL28CPLD >> + bool "Kontron sl28 core driver" >> + depends on I2C=y >> + depends on OF >> + select REGMAP_I2C >> + select MFD_CORE >> + help >> + This option enables support for the board management controller >> + found on the Kontron sl28 CPLD. You have to select individual >> + functions, such as watchdog, GPIO, etc, under the corresponding >> menus >> + in order to enable them. >> + >> + Currently supported boards are: >> + >> + Kontron SMARC-sAL28 >> + >> + To compile this driver as a module, choose M here: the module will >> be >> + called sl28cpld. >> + >> endmenu >> endif >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile >> index f935d10cbf0f..9bc38863b9c7 100644 >> --- a/drivers/mfd/Makefile >> +++ b/drivers/mfd/Makefile >> @@ -259,3 +259,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o >> obj-$(CONFIG_MFD_STMFX) += stmfx.o >> >> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o >> + >> +obj-$(CONFIG_MFD_SL28CPLD) += sl28cpld.o >> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c >> new file mode 100644 >> index 000000000000..1e5860cc7ffc >> --- /dev/null >> +++ b/drivers/mfd/sl28cpld.c >> @@ -0,0 +1,153 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * MFD core for the sl28cpld. >> + * >> + * Copyright 2019 Kontron Europe GmbH >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define SL28CPLD_VERSION 0x03 >> +#define SL28CPLD_WATCHDOG_BASE 0x04 >> +#define SL28CPLD_HWMON_FAN_BASE 0x0b >> +#define SL28CPLD_PWM0_BASE 0x0c >> +#define SL28CPLD_PWM1_BASE 0x0e >> +#define SL28CPLD_GPIO0_BASE 0x10 >> +#define SL28CPLD_GPIO1_BASE 0x15 >> +#define SL28CPLD_GPO_BASE 0x1a >> +#define SL28CPLD_GPI_BASE 0x1b >> +#define SL28CPLD_INTC_BASE 0x1c > > If you want to use 'reg' in the binding, these are the numbers you > should be using rather than making up numbering! My motivation is that I don't want to hardcode the internal addresses of the management controller in the device tree. For example if they will move around with a later update of the controller, so a driver can be compatible with both the old and the new version. If they are in the device tree, only one register layout is possible. > However, I still don't think you need any child nodes. All the data in > the DT binding is right here in the driver already. There's no > advantage > to putting child nodes in DT, because this driver still has to be > updated if you add more nodes. But then any phandle will reference the mfd device. And for example there are two different interrupt controllers, that is the INTC and the GPIO[01], which will then be combined into one device tree node, right? So the mfd node would be cpld: sl28cpld@4a { interrupt-controller; #interrupt-cells = <2>; gpio-controller; #gpio-cells = <2>; [..] }; and then depending on the mapping one could use: interrupts-extended = <&cpld 0 FLAGS>; /* gpio0 line 0 */ interrupts-extended = <&cpld 8 FLAGS>; /* gpio1 line 0 */ interrupts-extended = <&cpld 12 FLAGS>; /* irq0 */ gpios = <&cpld 0> /* gpio0 line 0 */ But there is also offset 12, but then it is the GPI controller: gpios = <&cpld 12> /* gpi line 0, nothing to do with irq0 */ I don't know if this is good practice, I guess you have to tell me. And is it possible to combine any sub device into the mfd node in that way? -michael From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Walle Subject: Re: [PATCH v3 05/16] mfd: Add support for Kontron sl28cpld management controller Date: Mon, 11 May 2020 23:44:58 +0200 Message-ID: References: <20200423174543.17161-1-michael@walle.cc> <20200423174543.17161-6-michael@walle.cc> <20200511211359.GB3518@bogus> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200511211359.GB3518@bogus> Sender: linux-kernel-owner@vger.kernel.org To: Rob Herring Cc: Andy Shevchenko , linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-pwm@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linus Walleij , Bartosz Golaszewski , Jean Delvare , Guenter Roeck , Lee Jones , Thierry Reding , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Wim Van Sebroeck , Shawn Guo , Li Yang , Thomas Gleixner , Jason Cooper Marc Zyngier List-Id: linux-pwm@vger.kernel.org Am 2020-05-11 23:13, schrieb Rob Herring: > On Thu, Apr 23, 2020 at 07:45:32PM +0200, Michael Walle wrote: >> This patch adds core support for the board management controller found >> on the SMARC-sAL28 board. It consists of the following functions: >> - watchdog >> - GPIO controller >> - PWM controller >> - fan sensor >> - interrupt controller >> >> At the moment, this controller is used on the Kontron SMARC-sAL28 >> board. >> >> Please note that the MFD driver is defined as bool in the Kconfig >> because the next patch will add interrupt support. >> >> Signed-off-by: Michael Walle >> --- >> drivers/mfd/Kconfig | 19 +++++ >> drivers/mfd/Makefile | 2 + >> drivers/mfd/sl28cpld.c | 153 >> +++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 174 insertions(+) >> create mode 100644 drivers/mfd/sl28cpld.c >> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig >> index 0a59249198d3..be0c8d93c526 100644 >> --- a/drivers/mfd/Kconfig >> +++ b/drivers/mfd/Kconfig >> @@ -2060,5 +2060,24 @@ config SGI_MFD_IOC3 >> If you have an SGI Origin, Octane, or a PCI IOC3 card, >> then say Y. Otherwise say N. >> >> +config MFD_SL28CPLD >> + bool "Kontron sl28 core driver" >> + depends on I2C=y >> + depends on OF >> + select REGMAP_I2C >> + select MFD_CORE >> + help >> + This option enables support for the board management controller >> + found on the Kontron sl28 CPLD. You have to select individual >> + functions, such as watchdog, GPIO, etc, under the corresponding >> menus >> + in order to enable them. >> + >> + Currently supported boards are: >> + >> + Kontron SMARC-sAL28 >> + >> + To compile this driver as a module, choose M here: the module will >> be >> + called sl28cpld. >> + >> endmenu >> endif >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile >> index f935d10cbf0f..9bc38863b9c7 100644 >> --- a/drivers/mfd/Makefile >> +++ b/drivers/mfd/Makefile >> @@ -259,3 +259,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o >> obj-$(CONFIG_MFD_STMFX) += stmfx.o >> >> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o >> + >> +obj-$(CONFIG_MFD_SL28CPLD) += sl28cpld.o >> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c >> new file mode 100644 >> index 000000000000..1e5860cc7ffc >> --- /dev/null >> +++ b/drivers/mfd/sl28cpld.c >> @@ -0,0 +1,153 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * MFD core for the sl28cpld. >> + * >> + * Copyright 2019 Kontron Europe GmbH >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define SL28CPLD_VERSION 0x03 >> +#define SL28CPLD_WATCHDOG_BASE 0x04 >> +#define SL28CPLD_HWMON_FAN_BASE 0x0b >> +#define SL28CPLD_PWM0_BASE 0x0c >> +#define SL28CPLD_PWM1_BASE 0x0e >> +#define SL28CPLD_GPIO0_BASE 0x10 >> +#define SL28CPLD_GPIO1_BASE 0x15 >> +#define SL28CPLD_GPO_BASE 0x1a >> +#define SL28CPLD_GPI_BASE 0x1b >> +#define SL28CPLD_INTC_BASE 0x1c > > If you want to use 'reg' in the binding, these are the numbers you > should be using rather than making up numbering! My motivation is that I don't want to hardcode the internal addresses of the management controller in the device tree. For example if they will move around with a later update of the controller, so a driver can be compatible with both the old and the new version. If they are in the device tree, only one register layout is possible. > However, I still don't think you need any child nodes. All the data in > the DT binding is right here in the driver already. There's no > advantage > to putting child nodes in DT, because this driver still has to be > updated if you add more nodes. But then any phandle will reference the mfd device. And for example there are two different interrupt controllers, that is the INTC and the GPIO[01], which will then be combined into one device tree node, right? So the mfd node would be cpld: sl28cpld@4a { interrupt-controller; #interrupt-cells = <2>; gpio-controller; #gpio-cells = <2>; [..] }; and then depending on the mapping one could use: interrupts-extended = <&cpld 0 FLAGS>; /* gpio0 line 0 */ interrupts-extended = <&cpld 8 FLAGS>; /* gpio1 line 0 */ interrupts-extended = <&cpld 12 FLAGS>; /* irq0 */ gpios = <&cpld 0> /* gpio0 line 0 */ But there is also offset 12, but then it is the GPI controller: gpios = <&cpld 12> /* gpi line 0, nothing to do with irq0 */ I don't know if this is good practice, I guess you have to tell me. And is it possible to combine any sub device into the mfd node in that way? -michael 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS 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 717D7C54E4A for ; Mon, 11 May 2020 21:45:12 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4449B2070B for ; Mon, 11 May 2020 21:45:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="R/6s0iur"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=walle.cc header.i=@walle.cc header.b="ZuzW3gEV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4449B2070B 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+infradead-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=bombadil.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=w3d7N9eloMhBiYlwS1ysAyVTGYV+JTA/WTPBuW8OWSY=; b=R/6s0iur6tMNFdGLAIhI6hPJP U90FjMG3oPOjCu0Hu119DDwrTVw4XwBT3VM9c/J4VyigQD6YECXnSUUltT0hXMGzDp7vt4UL5rqSh Zw3uqAafhgoeADO2gGPzXNl2wCcuhWT6sktVImevxna9fPMa9weBYzIlCaAI8Ou8JgvhdMeYt4o5Y 6lnDFLFwtK+DqgaIwgaN2CvHSYok0YnYqIh3hEGPvMpB4R1SLPzhMzaRDt7pyx26gXNP8eyZU0Jb2 9cBSbWVpxrjNwR2m8STGoMaTwcBc2zByxYiCqYEIxuP3QwIeWMjWYB3L8mJiPJ/eNcyQTvYzVJsbU qPqJ0yeyA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jYGEZ-00010U-7G; Mon, 11 May 2020 21:45:11 +0000 Received: from ssl.serverraum.org ([176.9.125.105]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jYGEU-0007Z0-Ub for linux-arm-kernel@lists.infradead.org; Mon, 11 May 2020 21:45:09 +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 425DF23E4D; Mon, 11 May 2020 23:44:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1589233499; 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=mUeXc7qWDqMsAtbmJANeooU975mp9voikExXUtAFyd4=; b=ZuzW3gEV27FW2OH77G50DUqIKwSr42+SNZXiF4IiL/x/xPKFd7o/8WjGXnjzVnF9r/m+nB ssw9jCD2ST5osYVZ1HaXphfRYwygT2ZucLtvS/LLW9YdkovQ6FaMYje0dUpU07z8LBZFqy bZhJbEpmpgmLqlQGh2PaJrHX77NFMTE= MIME-Version: 1.0 Date: Mon, 11 May 2020 23:44:58 +0200 From: Michael Walle To: Rob Herring Subject: Re: [PATCH v3 05/16] mfd: Add support for Kontron sl28cpld management controller In-Reply-To: <20200511211359.GB3518@bogus> References: <20200423174543.17161-1-michael@walle.cc> <20200423174543.17161-6-michael@walle.cc> <20200511211359.GB3518@bogus> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: michael@walle.cc X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200511_144507_298245_A2670198 X-CRM114-Status: GOOD ( 23.40 ) 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, Linus Walleij , Thierry Reding , Lee Jones , Jason Cooper , Andy Shevchenko , Marc Zyngier , Bartosz Golaszewski , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Guenter Roeck , linux-pwm@vger.kernel.org, Jean Delvare , linux-watchdog@vger.kernel.org, linux-gpio@vger.kernel.org, Mark Brown , Thomas Gleixner , Wim Van Sebroeck , linux-arm-kernel@lists.infradead.org, linux-hwmon@vger.kernel.org, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Li Yang , Shawn Guo Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am 2020-05-11 23:13, schrieb Rob Herring: > On Thu, Apr 23, 2020 at 07:45:32PM +0200, Michael Walle wrote: >> This patch adds core support for the board management controller found >> on the SMARC-sAL28 board. It consists of the following functions: >> - watchdog >> - GPIO controller >> - PWM controller >> - fan sensor >> - interrupt controller >> >> At the moment, this controller is used on the Kontron SMARC-sAL28 >> board. >> >> Please note that the MFD driver is defined as bool in the Kconfig >> because the next patch will add interrupt support. >> >> Signed-off-by: Michael Walle >> --- >> drivers/mfd/Kconfig | 19 +++++ >> drivers/mfd/Makefile | 2 + >> drivers/mfd/sl28cpld.c | 153 >> +++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 174 insertions(+) >> create mode 100644 drivers/mfd/sl28cpld.c >> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig >> index 0a59249198d3..be0c8d93c526 100644 >> --- a/drivers/mfd/Kconfig >> +++ b/drivers/mfd/Kconfig >> @@ -2060,5 +2060,24 @@ config SGI_MFD_IOC3 >> If you have an SGI Origin, Octane, or a PCI IOC3 card, >> then say Y. Otherwise say N. >> >> +config MFD_SL28CPLD >> + bool "Kontron sl28 core driver" >> + depends on I2C=y >> + depends on OF >> + select REGMAP_I2C >> + select MFD_CORE >> + help >> + This option enables support for the board management controller >> + found on the Kontron sl28 CPLD. You have to select individual >> + functions, such as watchdog, GPIO, etc, under the corresponding >> menus >> + in order to enable them. >> + >> + Currently supported boards are: >> + >> + Kontron SMARC-sAL28 >> + >> + To compile this driver as a module, choose M here: the module will >> be >> + called sl28cpld. >> + >> endmenu >> endif >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile >> index f935d10cbf0f..9bc38863b9c7 100644 >> --- a/drivers/mfd/Makefile >> +++ b/drivers/mfd/Makefile >> @@ -259,3 +259,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o >> obj-$(CONFIG_MFD_STMFX) += stmfx.o >> >> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o >> + >> +obj-$(CONFIG_MFD_SL28CPLD) += sl28cpld.o >> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c >> new file mode 100644 >> index 000000000000..1e5860cc7ffc >> --- /dev/null >> +++ b/drivers/mfd/sl28cpld.c >> @@ -0,0 +1,153 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * MFD core for the sl28cpld. >> + * >> + * Copyright 2019 Kontron Europe GmbH >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define SL28CPLD_VERSION 0x03 >> +#define SL28CPLD_WATCHDOG_BASE 0x04 >> +#define SL28CPLD_HWMON_FAN_BASE 0x0b >> +#define SL28CPLD_PWM0_BASE 0x0c >> +#define SL28CPLD_PWM1_BASE 0x0e >> +#define SL28CPLD_GPIO0_BASE 0x10 >> +#define SL28CPLD_GPIO1_BASE 0x15 >> +#define SL28CPLD_GPO_BASE 0x1a >> +#define SL28CPLD_GPI_BASE 0x1b >> +#define SL28CPLD_INTC_BASE 0x1c > > If you want to use 'reg' in the binding, these are the numbers you > should be using rather than making up numbering! My motivation is that I don't want to hardcode the internal addresses of the management controller in the device tree. For example if they will move around with a later update of the controller, so a driver can be compatible with both the old and the new version. If they are in the device tree, only one register layout is possible. > However, I still don't think you need any child nodes. All the data in > the DT binding is right here in the driver already. There's no > advantage > to putting child nodes in DT, because this driver still has to be > updated if you add more nodes. But then any phandle will reference the mfd device. And for example there are two different interrupt controllers, that is the INTC and the GPIO[01], which will then be combined into one device tree node, right? So the mfd node would be cpld: sl28cpld@4a { interrupt-controller; #interrupt-cells = <2>; gpio-controller; #gpio-cells = <2>; [..] }; and then depending on the mapping one could use: interrupts-extended = <&cpld 0 FLAGS>; /* gpio0 line 0 */ interrupts-extended = <&cpld 8 FLAGS>; /* gpio1 line 0 */ interrupts-extended = <&cpld 12 FLAGS>; /* irq0 */ gpios = <&cpld 0> /* gpio0 line 0 */ But there is also offset 12, but then it is the GPI controller: gpios = <&cpld 12> /* gpi line 0, nothing to do with irq0 */ I don't know if this is good practice, I guess you have to tell me. And is it possible to combine any sub device into the mfd node in that way? -michael _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel