linux-kernel - Re: [PATCH v2 3/4] dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210601091208.GB543307@dell>
Date:   Tue, 1 Jun 2021 10:12:08 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Robert Marko <robert.marko@...tura.hr>
Cc:     Rob Herring <robh@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Luka Perkov <luka.perkov@...tura.hr>, jmp@...phyte.org,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        Donald Buczek <buczek@...gen.mpg.de>
Subject: Re: [PATCH v2 3/4] dt-bindings: mfd: Add Delta TN48M CPLD drivers
 bindings

On Tue, 01 Jun 2021, Robert Marko wrote:

> On Tue, Jun 1, 2021 at 10:19 AM Lee Jones <lee.jones@...aro.org> wrote:
> >
> > On Mon, 31 May 2021, Robert Marko wrote:
> >
> > > On Wed, May 26, 2021 at 9:52 AM Lee Jones <lee.jones@...aro.org> wrote:
> > > >
> > > > On Tue, 25 May 2021, Robert Marko wrote:
> > > >
> > > > > On Tue, May 25, 2021 at 9:46 AM Lee Jones <lee.jones@...aro.org> 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 <robert.marko@...tura.hr>
> > > > > > > > ---
> > > > > > > > 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.
> 
> Yeah, I understand.
> This one is a generic CPLD used in multiple switch models, however in this
> switch model, it has the smallest set of features.
> Things that are usable for the kernel and userspace it provides are SFP pins,
> resets and debug information.
> Debug information is quite detailed actually.
> 
> I have added the reset driver in v3 as that is something that was gonna get
> added later as well as it exposes resets for the ethernet PHY-s and U-boot
> messes with the OOB PHY configuration.
> 
> >
> > Why do you require one single Regmap anyway?  Are they register banks
> > not neatly separated on a per-function basis?
> 
> For GPIO and reset drivers, I could get away with each of them
> registering a regmap
> but the debug driver will require accessing certain registers from their space.

> Also, I see using a single regmap that is provided by a generic driver
> much simpler and cleaner than doing that in each of the child drivers.

Obviously not. :)

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog