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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 25 May 2021, Robert Marko wrote:

> On Tue, May 25, 2021 at 9:46 AM Lee Jones <lee.jones@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > > ---
> > > > 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?

> 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.

> > > >  .../bindings/gpio/delta,tn48m-gpio.yaml       | 42 ++++++++++
> > > >  .../bindings/mfd/delta,tn48m-cpld.yaml        | 81 +++++++++++++++++++
> > > >  2 files changed, 123 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml
> > > >  create mode 100644 Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml
> >
> 
> 
> 

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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux