mbox series

[v5,0/2] Introduce support for mlxreg mfd core driver

Message ID 1505371738-128683-1-git-send-email-vadimp@mellanox.com
Headers show
Series Introduce support for mlxreg mfd core driver | expand

Message

Vadim Pasternak Sept. 14, 2017, 6:48 a.m. UTC
This patch adds support for the Mellanox BMC card equipped with the
programmable devices controlling hardware.
The support includes:
- signal handling for chassis, ASIC, CPU events;
- LED control;
- exposing sysfs interface for reset control, reset monitoring and mux
  selection for the access to remote devices at the host side.
- device tree binding documentation;

This patch depends on previously sent:
[patch v3 1/3] platform/mellanox: Introduce Mellanox hardware
 platform hotplug driver
because it includes include/linux/platform_data/mlxreg.h from this patch.

Vadim Pasternak (2):
  mfd: Add Mellanox regmap core driver
  dt-bindings: mfd: Add Device Tree bindings for Mellanox programmable
    devices

 .../bindings/mfd/mellanox,mlxreg-core.txt          | 165 ++++
 MAINTAINERS                                        |   6 +
 drivers/mfd/Kconfig                                |  14 +
 drivers/mfd/Makefile                               |   1 +
 drivers/mfd/mlxreg-core.c                          | 843 +++++++++++++++++++++
 5 files changed, 1029 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core.txt
 create mode 100644 drivers/mfd/mlxreg-core.c

Comments

Lee Jones Sept. 14, 2017, 9:43 a.m. UTC | #1
On Thu, 14 Sep 2017, Vadim Pasternak wrote:

> This patch adds core regmap platform driver for Mellanox BMC cards with
> the programmable devices based chassis control. The device logics,
> controlled by software includes:
> - Interrupt handling for chassis, ASIC, CPU events;
> - LED handling;
> - Exposes through sysfs mux, reset signals, reset cause notification;
> The patch provides support for the access to programmable device through
> the register map and allows dynamic device tree manipulation at runtime
> for removable devices.
> 
> This driver requires activator driver, which responsibility is to create
> register map and pass it to regmap core. Such activator could be based for
> example on I2C, SPI or MMIO interface.
> 
> Drivers exposes the number of hwmon attributes to sysfs according to the
> attribute groups, defined in the device tree. These attributes will be
> located for example in /sys/class/hwmon/hwmonX folder, which is a symbolic
> link to for example:
> /sys/bus/i2c/devices/4-0072/mlxreg-core.1138/hwmon/hwmon10.
> The attributes are divided to the groups, like in the below example:
>  MUX nodes
>  - safe_bios_disable
>  - spi_burn_bios_ci
>  - spi_burn_ncsi
>  - uart_sel
>  Reset nodes:
>  - sys_power_cycle
>  - bmc_upgrade
>  - asic_reset
>  Cause of reset nodes:
>  - cpu_kernel_panic
>  - cpu_shutdown
>  - bmc_warm_reset
>  General purpose RW nodes:
>  - version
> 
> Drivers also probes LED and hotplug drivers, in case device tree
> description contains LED and hotplug nodes.
> 
> Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
> ---
> v4->v5:
>  Comments pointed out by Lee:
>  - Remove mlxreg-i2c module from the patchset;
>  Changes added by Vadim:
>  - Remove include/linux/platform_data/mlxreg.h from the patcheset, since
>    it have been sent with
>  - Modify dts parsing routines;
>  - Disable compliation of_update_property if CONFIG_COMPILE_TEST is set;
> v3->v4:
>  Comments pointed out by Lee:
>  - Split interrupt related logic into separate module and place this logic
>    within the existing Mellanox hotplug driver. Move for this reason this
>    driver from drivers/platform/x86 to drivers/platform/mellanox folder;
>  Comments pointed out by Rob:
>  - Make a separate patch /devicetree/bindings/vendor-prefixes.txt;
>  - Add .txt to Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
>    and send it within this series;
>  - Modify "compatible" property;
>  - Modify explanation for "deferred" property;
>  - Describe each subnode by its own section;
>  - Don't use underscore in attribute names;
>  Changes added by Vadim:
>  - Add mlxreg_hotplug_device and mlxreg_core_item structures to mlxreg.h
>    and modify mlxreg_core_led_platform_data structure;
> v2->v3:
>  Changes added by Vadim:
>  - Change name of field led data in struct mlxreg_core_led_platform_data
>    in mlxreg.h;
>  - fix data position assignment in mlxreg_core_get;
>  - update name of field led data in mlxreg_core_set_led;
> v1->v2:
>  Comments pointed out by Pavel:
>  - Remove extra new line in mellanox,mlxreg-core;
>  - Replace three NOT with one in mlxreg_core_attr_show;
>  - Make error message in mlxreg_core_work_helper shorter;
>  - Make attribute assignment more readable;
>  - Separate mellanox,mlxreg-core file for sending to DT maintainers.
>  Comments pointed out by Jacek:
>  - Since  brightness_set_blocking is used instead of
>    brightness_set, three fields from mlxreg_core_led_data are removed.
> ---
>  MAINTAINERS               |   6 +
>  drivers/mfd/Kconfig       |  14 +
>  drivers/mfd/Makefile      |   1 +
>  drivers/mfd/mlxreg-core.c | 843 ++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 864 insertions(+)
>  create mode 100644 drivers/mfd/mlxreg-core.c

I thought we agreed that this was not an MFD driver?

If it doesn't use the MFD framework, it's not an MFD driver.

Looking at it very briefly, it appears at though it should actually be
split up.  In your commit message you say that this is a platform
driver that does LED handling and deals with the regmap and HWMON
subsystem.

I suggest moving the core code into /drivers/platform/* and split the
other sections into their own drivers within their own subsystems.
Lee Jones Sept. 14, 2017, 12:12 p.m. UTC | #2
On Thu, 14 Sep 2017, Vadim Pasternak wrote:

> 
> > > v4->v5:
> > >  Comments pointed out by Lee:
> > >  - Remove mlxreg-i2c module from the patchset;  Changes added by
> > > Vadim:
> > >  - Remove include/linux/platform_data/mlxreg.h from the patcheset, since
> > >    it have been sent with
> > >  - Modify dts parsing routines;
> > >  - Disable compliation of_update_property if CONFIG_COMPILE_TEST is
> > > set;
> > > v3->v4:
> > >  Comments pointed out by Lee:
> > >  - Split interrupt related logic into separate module and place this logic
> > >    within the existing Mellanox hotplug driver. Move for this reason this
> > >    driver from drivers/platform/x86 to drivers/platform/mellanox
> > > folder;  Comments pointed out by Rob:
> > >  - Make a separate patch /devicetree/bindings/vendor-prefixes.txt;
> > >  - Add .txt to Documentation/devicetree/bindings/mfd/mellanox,mlxreg-
> > core
> > >    and send it within this series;
> > >  - Modify "compatible" property;
> > >  - Modify explanation for "deferred" property;
> > >  - Describe each subnode by its own section;
> > >  - Don't use underscore in attribute names;  Changes added by Vadim:
> > >  - Add mlxreg_hotplug_device and mlxreg_core_item structures to mlxreg.h
> > >    and modify mlxreg_core_led_platform_data structure;
> > > v2->v3:
> > >  Changes added by Vadim:
> > >  - Change name of field led data in struct mlxreg_core_led_platform_data
> > >    in mlxreg.h;
> > >  - fix data position assignment in mlxreg_core_get;
> > >  - update name of field led data in mlxreg_core_set_led;
> > > v1->v2:
> > >  Comments pointed out by Pavel:
> > >  - Remove extra new line in mellanox,mlxreg-core;
> > >  - Replace three NOT with one in mlxreg_core_attr_show;
> > >  - Make error message in mlxreg_core_work_helper shorter;
> > >  - Make attribute assignment more readable;
> > >  - Separate mellanox,mlxreg-core file for sending to DT maintainers.
> > >  Comments pointed out by Jacek:
> > >  - Since  brightness_set_blocking is used instead of
> > >    brightness_set, three fields from mlxreg_core_led_data are removed.
> > > ---
> > >  MAINTAINERS               |   6 +
> > >  drivers/mfd/Kconfig       |  14 +
> > >  drivers/mfd/Makefile      |   1 +
> > >  drivers/mfd/mlxreg-core.c | 843
> > > ++++++++++++++++++++++++++++++++++++++++++++++
> > >  4 files changed, 864 insertions(+)
> > >  create mode 100644 drivers/mfd/mlxreg-core.c
> > 
> > I thought we agreed that this was not an MFD driver?
> 
> Your comment was regarding mlxreg-i2c module, which I removed from the
> patchset. So I was under impression that we agreed about mlx reg-i2c, but not
> about mlxreg-core.
> 
> > 
> > If it doesn't use the MFD framework, it's not an MFD driver.
> > 
> > Looking at it very briefly, it appears at though it should actually be split up.
> > In your commit message you say that this is a platform driver that does LED
> > handling and deals with the regmap and HWMON subsystem.
> > 
> > I suggest moving the core code into /drivers/platform/* and split the other
> > sections into their own drivers within their own subsystems.
> 
> According to your suggestion for patch v2 IC related code was splitted in v3,
> while LED driver has been separated in initial patchset version.
> Which other sections you suggested to split?
> There is now hwmon driver functionality within mlxreg-core. It expose some
> Registers with, f.e. reset and reset cause info to the user space through sysfs. 
> Also regmap is just the common interface, which is used by driver.
> 
> This driver, LED, IC and as I wrote before, there is a plan to extend it with WD
> and PWM drivers work against the same programmable device.
> So at the moment I provided two child devices for led and platform subsystems
> and planned to add  two more for hwmon or pwm and watchdog subsystems.
> 
> And all of them uses the same register space, accessible through regmap
> Interface.
> Based on the above I considered such driver as MFD.
> 
> Why do you think that drivers/platform is more suitable location, is it because
> I am using for subsystem drivers activation platform_device_add and not
> mfd_add_devices?
> Or there are some others considerations?

After a closer look, it seems as though some of it could be converted
into an MFD driver, but my prediction is that it's going to require
almost a complete re-write and we're going to need to re-work it over
several submissions.

The first thing you need to do is convert all of the hand rolled
platform device registration over to the MFD API.

The rest of the code is a mess.  It's over-complicated and mostly
unreadable.  What is it that you're trying to achieve?  What does the
device do and how does it function?  Do you have a datasheet that
you're working from?