On Thu, May 20, 2021 at 8:49 AM Lee Jones [off-list ref] wrote:

On Wed, 19 May 2021, Michael Walle wrote:

quoted

Hi,

Am 2021-05-19 13:53, schrieb Robert Marko:

quoted

On Thu, May 6, 2021 at 6:34 PM Michael Walle [off-list ref] wrote:

quoted

Am 2021-04-30 14:35, schrieb Robert Marko:

quoted

Delta TN48M switches have a Lattice CPLD that serves
multiple purposes including being a GPIO expander.
So lets add the MFD core driver for it.

Did you have a look at mfd/simple-mfd-i2c.c?

Yes, that was my first idea but we have a requirement to expose CPLD
information via debugfs as there are userspace applications using it.
And simple-mfd-i2c does not allow us to do so.

Mh, last time Lee wasn't very fond of having a driver that just populates
sub-drivers while doing almost nothing itself. See
https://lore.kernel.org/lkml/20200605065709.GD3714@dell/ (local)

Right.  I still feel that way.

quoted

That being said, I'd also like to expose our CPLD version, but until now
haven't found a good solution.

Why though?  Does S/W *need* it?

Because we have userspace S/W that uses it as the same CPLD is in
multiple variants of the board but the correct board model is set during
manufacturing and we can read it from the CPLD.

We also have information about PSU1 and PSU2(Some models only)
power good, whether they are present and some other info that I need
to expose as these are monitored in userspace.

I planned to do that via the hwmon driver but according to Guenther they
are not hwmon attributes and I agree.

Would it be possible to have a dedicated driver that would only expose
the required information via debugfs?
Then I could simply use the simple I2C MFD driver with only a GPIO
driver on top of it.

Regards,
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