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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,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 46994C47080 for ; Tue, 1 Jun 2021 08:19:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2556D6136E for ; Tue, 1 Jun 2021 08:19:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233354AbhFAIVV (ORCPT ); Tue, 1 Jun 2021 04:21:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233439AbhFAIVT (ORCPT ); Tue, 1 Jun 2021 04:21:19 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A0DBC06174A for ; Tue, 1 Jun 2021 01:19:37 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id g17so13223296wrs.13 for ; Tue, 01 Jun 2021 01:19:37 -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=KukDru8x9QpmY3cmltufnJ8Ttohzvm/qv7QdMVbte6Q=; b=vWeB5vM7l9vQeqWDCKYiIIf6rdKeCS6rOqxAXs5SkMsl0zAQz2MreKsTuutru/3KHS N1rcbpd/MbStA2AoeesYEmPdzGkiTCGDYi/nDwtr20SLW6k/u+oA3n1nHf01dCkhj7PZ m4DafUjHVAs8x9mThNr6lYhqzZOb/vbRG1C5dS+aheSb2hxaEfZPI1Dnre5AvV+o7kai S9AjWb34gmTK7ksUnM540qp51IG0ALLZVF8WglKka5lDjz1nibnhwC6nWsU6k8f6nHkf dfgq2w8i4Vadgo8Q0i8N+ORUGoYsfD+53/LD2JKkQ+q+WBN0vkAqEByoqGwJRoma/S2R gA9w== 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=KukDru8x9QpmY3cmltufnJ8Ttohzvm/qv7QdMVbte6Q=; b=k8NnGQJXVBbAXQKauylPMDtcB7d/WuO1bEudaQeOo+zYNXFSIf5hGiarDo0wvZgZxB ncKer5VJTHJp/I2YJDU6Sl0sIyG2cTL5QTz013Zm4CMYW/Gnx91yJz8p26SSdyu6VnzL o/BNCqlr3YvzI42Tuu06yL+goeVngYwqadrMZyCyBOsJYuNaMz9BrMw0tF6zq27l60q5 tYg5v4yaC/fiIMhjRn7M/d29yIcs4/EEMD2dBeKwY1ufgm/KuP8gKv+LgYuZYY3hx3Tu L5gxkc+6gGbYA8sY7LBo+H9w1GrojSasuI/qFL3FOCzCFtIpHZPDPVE0KP5eFj0dz+ZH zHYA== X-Gm-Message-State: AOAM533iNRjEMRx2Itjo2T1B6fuwluCU0qBYi36fya79Y0p3PfT2NblH bGEl5u5SEXLEC3y+dIrJXrGi/XYb5cFerg== X-Google-Smtp-Source: ABdhPJzIworTj34S1WsMzhTicK84t6ne3uMrwkffGkcGsO94WMOa27KFQn7os5+/Ub6oYkfJI2b+AQ== X-Received: by 2002:adf:f14d:: with SMTP id y13mr26368165wro.261.1622535575803; Tue, 01 Jun 2021 01:19:35 -0700 (PDT) Received: from dell ([91.110.221.249]) by smtp.gmail.com with ESMTPSA id t4sm612108wru.53.2021.06.01.01.19.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 01:19:35 -0700 (PDT) Date: Tue, 1 Jun 2021 09:19:33 +0100 From: Lee Jones To: Robert Marko Cc: Rob Herring , Linus Walleij , bgolaszewski@baylibre.com, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Luka Perkov , jmp@epiphyte.org, Paul Menzel , Donald Buczek Subject: Re: [PATCH v2 3/4] dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings Message-ID: <20210601081933.GU543307@dell> References: <20210524120539.3267145-1-robert.marko@sartura.hr> <20210524120539.3267145-3-robert.marko@sartura.hr> <20210524230940.GA1350504@robh.at.kernel.org> <20210525074649.GC4005783@dell> <20210526075255.GG4005783@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, 31 May 2021, Robert Marko wrote: > On Wed, May 26, 2021 at 9:52 AM Lee Jones wrote: > > > > On Tue, 25 May 2021, Robert Marko wrote: > > > > > On Tue, May 25, 2021 at 9:46 AM Lee Jones wrote: > > > > > > > > On Mon, 24 May 2021, Rob Herring wrote: > > > > > > > > > On Mon, May 24, 2021 at 02:05:38PM +0200, Robert Marko wrote: > > > > > > Add binding documents for the Delta TN48M CPLD drivers. > > > > > > > > > > > > Signed-off-by: Robert Marko > > > > > > --- > > > > > > Changes in v2: > > > > > > * Implement MFD as a simple I2C MFD > > > > > > * Add GPIO bindings as separate > > > > > > > > > > I don't understand why this changed. This doesn't look like an MFD to > > > > > me. Make your binding complete if there are missing functions. > > > > > Otherwise, stick with what I already ok'ed. > > > > > > > > Right. What else, besides GPIO, does this do? > > > > > > It currently does not do anything else as hwmon driver was essentially > > > NACK-ed for not exposing standard attributes. > > > > Once this provides more than GPIO capabilities i.e. becomes a proper > > Multi-Function Device, then it can use the MFD framework. Until then, > > it's a GPIO device I'm afraid. > > > > Are you going to re-author the HWMON driver to conform? > hwmon cannot be reathored as it has no standard hwmon attributes. > > > > > > The CPLD itself has PSU status-related information, bootstrap related > > > information, > > > various resets for the CPU-s, OOB ethernet PHY, information on the exact board > > > model it's running etc. > > > > > > PSU and model-related info stuff is gonna be exposed via a misc driver > > > in debugfs as > > > we have user-space SW depending on that. > > > I thought we agreed on that as v1 MFD driver was exposing those directly and > > > not doing anything else. > > > > Yes, we agreed that creating an MFD driver just to expose chip > > attributes was not an acceptable solution. > > > > > So I moved to use the simple I2C MFD driver, this is all modeled on the sl28cpld > > > which currently uses the same driver and then GPIO regmap as I do. > > > > > > Other stuff like the resets is probably gonna get exposed later when > > > it's required > > > to control it directly. > > > > In order for this driver to tick the MFD box, it's going to need more > > than one function. > > Understood, would a debug driver count or I can expose the resets via > a reset driver > as we have a future use for them? CPLDs and FPGAs are funny ones and are often difficult to support in Linux. Especially if they can change their behaviour. It's hard to make a solid suggestion as to how your device is handled without knowing the intricacies of the device. Why do you require one single Regmap anyway? Are they register banks not neatly separated on a per-function basis? -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog