On Tue, Jun 1, 2021 at 10:22 AM Lee Jones [off-list ref] wrote:

On Tue, 01 Jun 2021, Lee Jones wrote:

quoted

On Mon, 31 May 2021, Robert Marko wrote:

quoted

On Wed, May 26, 2021 at 9:52 AM Lee Jones [off-list ref] wrote:

quoted

On Tue, 25 May 2021, Robert Marko wrote:

quoted

On Tue, May 25, 2021 at 9:46 AM Lee Jones [off-list ref] wrote:

quoted

On Mon, 24 May 2021, Rob Herring wrote:

quoted

On Mon, May 24, 2021 at 02:05:38PM +0200, Robert Marko wrote:

quoted

Add binding documents for the Delta TN48M CPLD drivers.

Signed-off-by: Robert Marko <robert.marko@sartura.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.

quoted

quoted

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.

quoted

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?

Also, if this is really just a GPIO expander, can't the GPIO driver
output something to /sysfs that identifies it to userspace instead?

I replied to your previous reply instead of this one directly.
It's not just a GPIO expander, it also provides resets to all of the HW
and a lot of debugging information.
Note that other switches use the same CPLD but with more features
so I want to just extend these drivers and add for example hwmon.

It's not just about it identifying itself, it offers a lot of various
debug info,
quite literally down to what CPU has access to the serial console on the
front and their bootstrap pins.

So, I want to expose the CPLD version, code version, switch model,
PSU status pins and a lot more using a separate driver as they
don't really belong to any other subsystem than misc using debugfs.

I hope this clears things up,
Robert

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

-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@sartura.hr
Web: www.sartura.hr