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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 11765C433E0 for ; Tue, 9 Jun 2020 18:52:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D58ED2078D for ; Tue, 9 Jun 2020 18:52:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ArNCp5jy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728012AbgFISwn (ORCPT ); Tue, 9 Jun 2020 14:52:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729371AbgFISwi (ORCPT ); Tue, 9 Jun 2020 14:52:38 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F02FCC08C5C5 for ; Tue, 9 Jun 2020 11:52:35 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id f185so4204687wmf.3 for ; Tue, 09 Jun 2020 11:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Rx+KqvmtdByLRiHw7ISbnHgkCLyaMrdXIypQJ9D83NM=; b=ArNCp5jy8xw0o8QYdJ3Qz1qQoc5OchvaEoyPj/G3Qwd05C7R7/XwhufiBSsQAM3dmM o0o0yks+I4S6jJDHffPGL+45DtgPleewkT66ldWqf86ww/dLeMP4ZtCohqmksRgJPz/3 cg7JbiDfz+XazkwnFo3bl4Qh1Pgcd7l+MUv645Vmj6YkhES6S5IX42bQhMaCpXAnhpFH 8d43uufA2OACUuQ9lwM1TydKIO0QRdLKkPIMNd8j9lf3nKqYCXvC8ZnBgxtwxqH3Js7M lE2iXBVCw2E3+yLybw5nLs2eUzHLcDA9pV66llGAGFA074R7HHjv9OaEJR6iGCSCMiKi Vjsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Rx+KqvmtdByLRiHw7ISbnHgkCLyaMrdXIypQJ9D83NM=; b=qEdozBWtxmuzdQGU2wJ1nZUXRNiMOJqhMSF3uWeWE5APk729YI9/2vXQhTpES2BMtl +qaLz1/113+ngH6bjf/Tbmyrj6c2+/qWDf1J/wFOOsW3CAJEbU+c1j1JS87uFlnsxKaY WBeWUigSeVAi9YgDib9v4dvyQrBKTZAYe2ne8n2YgSRJAMbLpp23EMNATJ1prfPjUsJl 0AZTO8IDiwgKMTAgN23EjpdDvNdooPnjHEPcaSEJD4VX+iLhyEED5pvo7wqt7gwpbV13 L2sJkjvkAWF/ZIFaRb/rOBGfT4Kp5XK2TPzDb2FO9Emk62IBa8L3U8ofZWJVAuR1TV/x hM3Q== X-Gm-Message-State: AOAM530OykfEYwfBBnfvR6WYIkGQdMMAqqbnzJ4gs+v/whVzju+w7K1i ppAge+GOILdF0Y4zme0L0DIjzg== X-Google-Smtp-Source: ABdhPJwpZZ7S4GqJFNik24T6FJp5nAop3BUokybQq1cMXdlH57TCJy3rpjeZBHUZlWR02zEPG6whnQ== X-Received: by 2002:a1c:2b01:: with SMTP id r1mr5692273wmr.26.1591728754296; Tue, 09 Jun 2020 11:52:34 -0700 (PDT) Received: from dell ([2.27.167.101]) by smtp.gmail.com with ESMTPSA id b185sm4390216wmd.3.2020.06.09.11.52.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 11:52:33 -0700 (PDT) Date: Tue, 9 Jun 2020 19:52:31 +0100 From: Lee Jones To: Rob Herring Cc: Michael Walle , Mark Brown , 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 , Thierry Reding , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Wim Van Sebroeck , Shawn Guo , Li Yang , Thomas Gleixner , Jason Cooper , Marc Zyngier , Greg Kroah-Hartman , Andy Shevchenko Subject: Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Message-ID: <20200609185231.GO4106@dell> References: <20200604211039.12689-1-michael@walle.cc> <20200604211039.12689-3-michael@walle.cc> <20200605065709.GD3714@dell> <20200605105026.GC5413@sirena.org.uk> <20200606114645.GB2055@sirena.org.uk> <20200608082827.GB3567@dell> <20200609165401.GB1019634@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200609165401.GB1019634@bogus> Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Tue, 09 Jun 2020, Rob Herring wrote: > On Mon, Jun 08, 2020 at 09:28:27AM +0100, Lee Jones wrote: > > Rob, something for you below. > > > > On Sat, 06 Jun 2020, Michael Walle wrote: > > > Am 2020-06-06 13:46, schrieb Mark Brown: > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote: > > > > > Am 2020-06-05 12:50, schrieb Mark Brown: > > > > > > > > > > I have no idea what you are thinking of when you say "simple-regmap" so > > > > > > it is difficult to comment. > > > > > > > > > I guess, Lee is suggesting to be able to create a regmap instance via > > > > > device tree (and populate its child nodes?). Like > > > > > compatible = "syscon", "simple-mfd"; > > > > > but for any regmap, not just MMIO. > > > > Bingo! > > > > > > I don't understand why this would be anything separate to > > > > simple-mfd. > > > > > > Don't just simple-mfd tells the of core, to probe the children this > > > node? Where does the regmap then come from? > > > > Right. I'm suggesting a means to extrapolate complex shared and > > sometimes intertwined batches of register sets to be consumed by > > multiple (sub-)devices spanning different subsystems. > > > > Actually scrap that. The most common case I see is a single Regmap > > covering all child-devices. It would be great if there was a way in > > which we could make an assumption that the entire register address > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between > > each of the devices described by its child-nodes. Probably by picking > > up on the 'simple-mfd' compatible string in the first instance. > > > > Rob, is the above something you would contemplate? > > No. I'd like to just kill off syscon and simple-mfd really. Those are > just hints meaning a specific compatible is still needed, but I see them > all the time alone (or combined like above). 'syscon' just serves to > create a regmap. This could be accomplished just with a list of > compatibles to register a regmap for. That might be a longish list, but > wanting a regmap is really a kernel implementation detail and decision. Exactly. Syscon is a real tangible thing and Regmap is a Linux subsystem. So swapping out the former for the latter sounds like the opposite of what you'd want to do. > > > MFD core can > > > match a device tree node today; but only one per unique compatible > > > string. So what should I use to differentiate the different > > > subdevices? > > > > Right. I have been aware of this issue. The only suitable solution > > to this would be to match on 'reg'. > > > > FYI: I plan to fix this. > > > > If your register map needs to change, then I suggest that this is > > either a new device or at least a different version of the device and > > would also have to be represented as different (sub-)mfd_cell. > > The same register set at a different offset is the same (sub)device. See below. > > > Rob suggested the internal offset, which I did here. > > > > FWIW, I don't like this idea. DTs should not have to be modified > > (either in the first instance or subsequently) or specifically > > designed to patch inadequacies in any given OS. > > My understanding is there can be differing combinations or number of > instances of sub devices for this device. That's when having DT sub > devices makes sense. If the h/w changes, then the DT should change. This is the same point I was making above. > Multiple instances of devices require an address to identify them and we > don't make up numbering if we can avoid it. The earlier revisions just > had made up indices for addresses. Right. Which I'm against. Placing "internal offsets" into the 'reg' property is a hack. The issue is, if we need to configure the devices differently, then how do we identify them in order to ensure the correct OF node pointer is allocated to the correct platform device? -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones Subject: Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Date: Tue, 9 Jun 2020 19:52:31 +0100 Message-ID: <20200609185231.GO4106@dell> References: <20200604211039.12689-1-michael@walle.cc> <20200604211039.12689-3-michael@walle.cc> <20200605065709.GD3714@dell> <20200605105026.GC5413@sirena.org.uk> <20200606114645.GB2055@sirena.org.uk> <20200608082827.GB3567@dell> <20200609165401.GB1019634@bogus> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729371AbgFISwg (ORCPT ); Tue, 9 Jun 2020 14:52:36 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D77C8C08C5C2 for ; Tue, 9 Jun 2020 11:52:35 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id r15so4176951wmh.5 for ; Tue, 09 Jun 2020 11:52:35 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20200609165401.GB1019634@bogus> Sender: linux-pwm-owner@vger.kernel.org List-Id: linux-pwm@vger.kernel.org To: Rob Herring Cc: Michael Walle , Mark Brown , 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 , Thierry Reding , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Wim Van Sebroeck , Shawn Guo , Li Yang , Thomas Gleixner , Jason Cooper , Marc Zyngier On Tue, 09 Jun 2020, Rob Herring wrote: > On Mon, Jun 08, 2020 at 09:28:27AM +0100, Lee Jones wrote: > > Rob, something for you below. > > > > On Sat, 06 Jun 2020, Michael Walle wrote: > > > Am 2020-06-06 13:46, schrieb Mark Brown: > > > > On Fri, Jun 05, 2020 at 10:07:36PM +0200, Michael Walle wrote: > > > > > Am 2020-06-05 12:50, schrieb Mark Brown: > > > > > > > > > > I have no idea what you are thinking of when you say "simple-regmap" so > > > > > > it is difficult to comment. > > > > > > > > > I guess, Lee is suggesting to be able to create a regmap instance via > > > > > device tree (and populate its child nodes?). Like > > > > > compatible = "syscon", "simple-mfd"; > > > > > but for any regmap, not just MMIO. > > > > Bingo! > > > > > > I don't understand why this would be anything separate to > > > > simple-mfd. > > > > > > Don't just simple-mfd tells the of core, to probe the children this > > > node? Where does the regmap then come from? > > > > Right. I'm suggesting a means to extrapolate complex shared and > > sometimes intertwined batches of register sets to be consumed by > > multiple (sub-)devices spanning different subsystems. > > > > Actually scrap that. The most common case I see is a single Regmap > > covering all child-devices. It would be great if there was a way in > > which we could make an assumption that the entire register address > > space for a 'tagged' (MFD) device is to be shared (via Regmap) between > > each of the devices described by its child-nodes. Probably by picking > > up on the 'simple-mfd' compatible string in the first instance. > > > > Rob, is the above something you would contemplate? > > No. I'd like to just kill off syscon and simple-mfd really. Those are > just hints meaning a specific compatible is still needed, but I see them > all the time alone (or combined like above). 'syscon' just serves to > create a regmap. This could be accomplished just with a list of > compatibles to register a regmap for. That might be a longish list, but > wanting a regmap is really a kernel implementation detail and decision. Exactly. Syscon is a real tangible thing and Regmap is a Linux subsystem. So swapping out the former for the latter sounds like the opposite of what you'd want to do. > > > MFD core can > > > match a device tree node today; but only one per unique compatible > > > string. So what should I use to differentiate the different > > > subdevices? > > > > Right. I have been aware of this issue. The only suitable solution > > to this would be to match on 'reg'. > > > > FYI: I plan to fix this. > > > > If your register map needs to change, then I suggest that this is > > either a new device or at least a different version of the device and > > would also have to be represented as different (sub-)mfd_cell. > > The same register set at a different offset is the same (sub)device. See below. > > > Rob suggested the internal offset, which I did here. > > > > FWIW, I don't like this idea. DTs should not have to be modified > > (either in the first instance or subsequently) or specifically > > designed to patch inadequacies in any given OS. > > My understanding is there can be differing combinations or number of > instances of sub devices for this device. That's when having DT sub > devices makes sense. If the h/w changes, then the DT should change. This is the same point I was making above. > Multiple instances of devices require an address to identify them and we > don't make up numbering if we can avoid it. The earlier revisions just > had made up indices for addresses. Right. Which I'm against. Placing "internal offsets" into the 'reg' property is a hack. The issue is, if we need to configure the devices differently, then how do we identify them in order to ensure the correct OF node pointer is allocated to the correct platform device? -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog 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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 19033C433DF for ; Tue, 9 Jun 2020 18:52:41 +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 DD118206C3 for ; Tue, 9 Jun 2020 18:52:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="isuT/Ssc"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ArNCp5jy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DD118206C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wOncwHQVMT69qY8mQ86uF48YRHMV1fmvBG+GLZ+xD8Q=; b=isuT/SscIYhGZZ Ctq3Mf5+K+MGqGafF/MeY4jFc71RjSJFuY+o1QRTvoNSpFiovUkNj/DPdDQTL7RjIoD5hRiswnWpN 8czRdVnn3msYaDBQS00jDwjzva5Pnn6a9ZspLSonj1mHQd3UKniZwU1m8X6AjYVTqj0F1TxFiDzP6 fwaKr5uyivns0yJrv1hwCzhZNdX0tk1xdyVBbifVXHAO97SG9QkjDj0A3b8WQuWy4OdKhqig0Xs/H 9Qxnw9i1gFYEsggXEfZcZmXweiGhCf98p9cRziAFQiXBOIg3Ay9yQI8VbZB5NZCNPfDducSg58n6m Wrp7Vh/jaGeRqPEP8Mig==; 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 1jijMV-0005Ex-Pm; Tue, 09 Jun 2020 18:52:39 +0000 Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jijMR-0005Ee-Ta for linux-arm-kernel@lists.infradead.org; Tue, 09 Jun 2020 18:52:37 +0000 Received: by mail-wm1-x342.google.com with SMTP id r15so4176952wmh.5 for ; Tue, 09 Jun 2020 11:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Rx+KqvmtdByLRiHw7ISbnHgkCLyaMrdXIypQJ9D83NM=; b=ArNCp5jy8xw0o8QYdJ3Qz1qQoc5OchvaEoyPj/G3Qwd05C7R7/XwhufiBSsQAM3dmM o0o0yks+I4S6jJDHffPGL+45DtgPleewkT66ldWqf86ww/dLeMP4ZtCohqmksRgJPz/3 cg7JbiDfz+XazkwnFo3bl4Qh1Pgcd7l+MUv645Vmj6YkhES6S5IX42bQhMaCpXAnhpFH 8d43uufA2OACUuQ9lwM1TydKIO0QRdLKkPIMNd8j9lf3nKqYCXvC8ZnBgxtwxqH3Js7M lE2iXBVCw2E3+yLybw5nLs2eUzHLcDA9pV66llGAGFA074R7HHjv9OaEJR6iGCSCMiKi Vjsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Rx+KqvmtdByLRiHw7ISbnHgkCLyaMrdXIypQJ9D83NM=; b=jP8yT9ybdpsQL8ygpk1veNC6kdj9buXUvNBa9n2D6QiE0jfxcsARINCKrVfwoP7sbq a8NYVjzifAohmyhpJQ6JqW/szCdFurDpAEeH6NJ74taycKD/ghSiqLfwbPoT5AHaKspI hn4zXak2keep3UGAnz7MV5A5XSFz7+a2O2jVJPyjdhmf7wnVb808dux8hWOAyunsjNwK 2IMz9udnWVwsOBzIVpCHgbksxWVVyZ2cTHxoT1jqf6dgl5xdK7wRNRZaIiWjrfbDmOFN m3y5loXLrDudzK/O4+nf30gWJBV43X2OPCh6nvNgBwiSV4w3Sb+RbL0X/zjyIVLncq+h EVFA== X-Gm-Message-State: AOAM5335iImsbqOtQYILAfocBCA9A5E4jra51CljLGv32oph06Q9qg5x pqdtXOuKNamfA8tLzj/SlUpJxg== X-Google-Smtp-Source: ABdhPJwpZZ7S4GqJFNik24T6FJp5nAop3BUokybQq1cMXdlH57TCJy3rpjeZBHUZlWR02zEPG6whnQ== X-Received: by 2002:a1c:2b01:: with SMTP id r1mr5692273wmr.26.1591728754296; Tue, 09 Jun 2020 11:52:34 -0700 (PDT) Received: from dell ([2.27.167.101]) by smtp.gmail.com with ESMTPSA id b185sm4390216wmd.3.2020.06.09.11.52.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 11:52:33 -0700 (PDT) Date: Tue, 9 Jun 2020 19:52:31 +0100 From: Lee Jones To: Rob Herring Subject: Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Message-ID: <20200609185231.GO4106@dell> References: <20200604211039.12689-1-michael@walle.cc> <20200604211039.12689-3-michael@walle.cc> <20200605065709.GD3714@dell> <20200605105026.GC5413@sirena.org.uk> <20200606114645.GB2055@sirena.org.uk> <20200608082827.GB3567@dell> <20200609165401.GB1019634@bogus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200609165401.GB1019634@bogus> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200609_115235_961103_F3687B29 X-CRM114-Status: GOOD ( 31.63 ) 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: linux-pwm@vger.kernel.org, Linus Walleij , Thierry Reding , Jason Cooper , Andy Shevchenko , Marc Zyngier , Bartosz Golaszewski , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Guenter Roeck , devicetree@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 , Michael Walle , Shawn Guo Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gVHVlLCAwOSBKdW4gMjAyMCwgUm9iIEhlcnJpbmcgd3JvdGU6Cgo+IE9uIE1vbiwgSnVuIDA4 LCAyMDIwIGF0IDA5OjI4OjI3QU0gKzAxMDAsIExlZSBKb25lcyB3cm90ZToKPiA+IFJvYiwgc29t ZXRoaW5nIGZvciB5b3UgYmVsb3cuCj4gPiAKPiA+IE9uIFNhdCwgMDYgSnVuIDIwMjAsIE1pY2hh ZWwgV2FsbGUgd3JvdGU6Cj4gPiA+IEFtIDIwMjAtMDYtMDYgMTM6NDYsIHNjaHJpZWIgTWFyayBC cm93bjoKPiA+ID4gPiBPbiBGcmksIEp1biAwNSwgMjAyMCBhdCAxMDowNzozNlBNICswMjAwLCBN aWNoYWVsIFdhbGxlIHdyb3RlOgo+ID4gPiA+ID4gQW0gMjAyMC0wNi0wNSAxMjo1MCwgc2Nocmll YiBNYXJrIEJyb3duOgo+ID4gPiA+IAo+ID4gPiA+ID4gPiBJIGhhdmUgbm8gaWRlYSB3aGF0IHlv dSBhcmUgdGhpbmtpbmcgb2Ygd2hlbiB5b3Ugc2F5ICJzaW1wbGUtcmVnbWFwIiBzbwo+ID4gPiA+ ID4gPiBpdCBpcyBkaWZmaWN1bHQgdG8gY29tbWVudC4KPiA+ID4gPiAKPiA+ID4gPiA+IEkgZ3Vl c3MsIExlZSBpcyBzdWdnZXN0aW5nIHRvIGJlIGFibGUgdG8gY3JlYXRlIGEgcmVnbWFwIGluc3Rh bmNlIHZpYQo+ID4gPiA+ID4gZGV2aWNlIHRyZWUgKGFuZCBwb3B1bGF0ZSBpdHMgY2hpbGQgbm9k ZXM/KS4gTGlrZQo+ID4gPiA+ID4gICBjb21wYXRpYmxlID0gInN5c2NvbiIsICJzaW1wbGUtbWZk IjsKPiA+ID4gPiA+IGJ1dCBmb3IgYW55IHJlZ21hcCwgbm90IGp1c3QgTU1JTy4KPiA+IAo+ID4g QmluZ28hCj4gPiAKPiA+ID4gPiBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoaXMgd291bGQgYmUg YW55dGhpbmcgc2VwYXJhdGUgdG8KPiA+ID4gPiBzaW1wbGUtbWZkLgo+ID4gPiAKPiA+ID4gRG9u J3QganVzdCBzaW1wbGUtbWZkIHRlbGxzIHRoZSBvZiBjb3JlLCB0byBwcm9iZSB0aGUgY2hpbGRy ZW4gdGhpcwo+ID4gPiBub2RlPyBXaGVyZSBkb2VzIHRoZSByZWdtYXAgdGhlbiBjb21lIGZyb20/ Cj4gPiAKPiA+IFJpZ2h0LiAgSSdtIHN1Z2dlc3RpbmcgYSBtZWFucyB0byBleHRyYXBvbGF0ZSBj b21wbGV4IHNoYXJlZCBhbmQKPiA+IHNvbWV0aW1lcyBpbnRlcnR3aW5lZCBiYXRjaGVzIG9mIHJl Z2lzdGVyIHNldHMgdG8gYmUgY29uc3VtZWQgYnkKPiA+IG11bHRpcGxlIChzdWItKWRldmljZXMg c3Bhbm5pbmcgZGlmZmVyZW50IHN1YnN5c3RlbXMuCj4gPiAKPiA+IEFjdHVhbGx5IHNjcmFwIHRo YXQuICBUaGUgbW9zdCBjb21tb24gY2FzZSBJIHNlZSBpcyBhIHNpbmdsZSBSZWdtYXAKPiA+IGNv dmVyaW5nIGFsbCBjaGlsZC1kZXZpY2VzLiAgSXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlcmUgd2Fz IGEgd2F5IGluCj4gPiB3aGljaCB3ZSBjb3VsZCBtYWtlIGFuIGFzc3VtcHRpb24gdGhhdCB0aGUg ZW50aXJlIHJlZ2lzdGVyIGFkZHJlc3MKPiA+IHNwYWNlIGZvciBhICd0YWdnZWQnIChNRkQpIGRl dmljZSBpcyB0byBiZSBzaGFyZWQgKHZpYSBSZWdtYXApIGJldHdlZW4KPiA+IGVhY2ggb2YgdGhl IGRldmljZXMgZGVzY3JpYmVkIGJ5IGl0cyBjaGlsZC1ub2Rlcy4gIFByb2JhYmx5IGJ5IHBpY2tp bmcKPiA+IHVwIG9uIHRoZSAnc2ltcGxlLW1mZCcgY29tcGF0aWJsZSBzdHJpbmcgaW4gdGhlIGZp cnN0IGluc3RhbmNlLgo+ID4gCj4gPiBSb2IsIGlzIHRoZSBhYm92ZSBzb21ldGhpbmcgeW91IHdv dWxkIGNvbnRlbXBsYXRlPwo+IAo+IE5vLiBJJ2QgbGlrZSB0byBqdXN0IGtpbGwgb2ZmIHN5c2Nv biBhbmQgc2ltcGxlLW1mZCByZWFsbHkuIFRob3NlIGFyZSAKPiBqdXN0IGhpbnRzIG1lYW5pbmcg YSBzcGVjaWZpYyBjb21wYXRpYmxlIGlzIHN0aWxsIG5lZWRlZCwgYnV0IEkgc2VlIHRoZW0gCj4g YWxsIHRoZSB0aW1lIGFsb25lIChvciBjb21iaW5lZCBsaWtlIGFib3ZlKS4gJ3N5c2NvbicganVz dCBzZXJ2ZXMgdG8gCj4gY3JlYXRlIGEgcmVnbWFwLiBUaGlzIGNvdWxkIGJlIGFjY29tcGxpc2hl ZCBqdXN0IHdpdGggYSBsaXN0IG9mIAo+IGNvbXBhdGlibGVzIHRvIHJlZ2lzdGVyIGEgcmVnbWFw IGZvci4gVGhhdCBtaWdodCBiZSBhIGxvbmdpc2ggbGlzdCwgYnV0IAo+IHdhbnRpbmcgYSByZWdt YXAgaXMgcmVhbGx5IGEga2VybmVsIGltcGxlbWVudGF0aW9uIGRldGFpbCBhbmQgZGVjaXNpb24u CgpFeGFjdGx5LiAgU3lzY29uIGlzIGEgcmVhbCB0YW5naWJsZSB0aGluZyBhbmQgUmVnbWFwIGlz IGEgTGludXgKc3Vic3lzdGVtLiAgU28gc3dhcHBpbmcgb3V0IHRoZSBmb3JtZXIgZm9yIHRoZSBs YXR0ZXIgc291bmRzIGxpa2UgdGhlCm9wcG9zaXRlIG9mIHdoYXQgeW91J2Qgd2FudCB0byBkby4K Cj4gPiA+IE1GRCBjb3JlIGNhbgo+ID4gPiBtYXRjaCBhIGRldmljZSB0cmVlIG5vZGUgdG9kYXk7 IGJ1dCBvbmx5IG9uZSBwZXIgdW5pcXVlIGNvbXBhdGlibGUKPiA+ID4gc3RyaW5nLiBTbyB3aGF0 IHNob3VsZCBJIHVzZSB0byBkaWZmZXJlbnRpYXRlIHRoZSBkaWZmZXJlbnQKPiA+ID4gc3ViZGV2 aWNlcz8KPiA+IAo+ID4gUmlnaHQuICBJIGhhdmUgYmVlbiBhd2FyZSBvZiB0aGlzIGlzc3VlLiAg VGhlIG9ubHkgc3VpdGFibGUgc29sdXRpb24KPiA+IHRvIHRoaXMgd291bGQgYmUgdG8gbWF0Y2gg b24gJ3JlZycuCj4gPiAKPiA+IEZZSTogSSBwbGFuIHRvIGZpeCB0aGlzLgo+ID4gCj4gPiBJZiB5 b3VyIHJlZ2lzdGVyIG1hcCBuZWVkcyB0byBjaGFuZ2UsIHRoZW4gSSBzdWdnZXN0IHRoYXQgdGhp cyBpcwo+ID4gZWl0aGVyIGEgbmV3IGRldmljZSBvciBhdCBsZWFzdCBhIGRpZmZlcmVudCB2ZXJz aW9uIG9mIHRoZSBkZXZpY2UgYW5kCj4gPiB3b3VsZCBhbHNvIGhhdmUgdG8gYmUgcmVwcmVzZW50 ZWQgYXMgZGlmZmVyZW50IChzdWItKW1mZF9jZWxsLgo+IAo+IFRoZSBzYW1lIHJlZ2lzdGVyIHNl dCBhdCBhIGRpZmZlcmVudCBvZmZzZXQgaXMgdGhlIHNhbWUgKHN1YilkZXZpY2UuCgpTZWUgYmVs b3cuCgo+ID4gPiBSb2Igc3VnZ2VzdGVkIHRoZSBpbnRlcm5hbCBvZmZzZXQsIHdoaWNoIEkgZGlk IGhlcmUuCj4gPiAKPiA+IEZXSVcsIEkgZG9uJ3QgbGlrZSB0aGlzIGlkZWEuICBEVHMgc2hvdWxk IG5vdCBoYXZlIHRvIGJlIG1vZGlmaWVkCj4gPiAoZWl0aGVyIGluIHRoZSBmaXJzdCBpbnN0YW5j ZSBvciBzdWJzZXF1ZW50bHkpIG9yIHNwZWNpZmljYWxseQo+ID4gZGVzaWduZWQgdG8gcGF0Y2gg aW5hZGVxdWFjaWVzIGluIGFueSBnaXZlbiBPUy4KPiAKPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRo ZXJlIGNhbiBiZSBkaWZmZXJpbmcgY29tYmluYXRpb25zIG9yIG51bWJlciBvZiAKPiBpbnN0YW5j ZXMgb2Ygc3ViIGRldmljZXMgZm9yIHRoaXMgZGV2aWNlLiBUaGF0J3Mgd2hlbiBoYXZpbmcgRFQg c3ViIAo+IGRldmljZXMgbWFrZXMgc2Vuc2UuIElmIHRoZSBoL3cgY2hhbmdlcywgdGhlbiB0aGUg RFQgc2hvdWxkIGNoYW5nZS4KClRoaXMgaXMgdGhlIHNhbWUgcG9pbnQgSSB3YXMgbWFraW5nIGFi b3ZlLgoKPiBNdWx0aXBsZSBpbnN0YW5jZXMgb2YgZGV2aWNlcyByZXF1aXJlIGFuIGFkZHJlc3Mg dG8gaWRlbnRpZnkgdGhlbSBhbmQgd2UgCj4gZG9uJ3QgbWFrZSB1cCBudW1iZXJpbmcgaWYgd2Ug Y2FuIGF2b2lkIGl0LiBUaGUgZWFybGllciByZXZpc2lvbnMganVzdCAKPiBoYWQgbWFkZSB1cCBp bmRpY2VzIGZvciBhZGRyZXNzZXMuCgpSaWdodC4gIFdoaWNoIEknbSBhZ2FpbnN0LgoKUGxhY2lu ZyAiaW50ZXJuYWwgb2Zmc2V0cyIgaW50byB0aGUgJ3JlZycgcHJvcGVydHkgaXMgYSBoYWNrLgoK VGhlIGlzc3VlIGlzLCBpZiB3ZSBuZWVkIHRvIGNvbmZpZ3VyZSB0aGUgZGV2aWNlcyBkaWZmZXJl bnRseSwgdGhlbgpob3cgZG8gd2UgaWRlbnRpZnkgdGhlbSBpbiBvcmRlciB0byBlbnN1cmUgdGhl IGNvcnJlY3QgT0Ygbm9kZSBwb2ludGVyCmlzIGFsbG9jYXRlZCB0byB0aGUgY29ycmVjdCBwbGF0 Zm9ybSBkZXZpY2U/CgotLSAKTGVlIEpvbmVzIFvmnY7nkLzmlq9dClNlbmlvciBUZWNobmljYWwg TGVhZCAtIERldmVsb3BlciBTZXJ2aWNlcwpMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0 d2FyZSBmb3IgQXJtIFNvQ3MKRm9sbG93IExpbmFybzogRmFjZWJvb2sgfCBUd2l0dGVyIHwgQmxv ZwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgt YXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQu b3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJt LWtlcm5lbAo=