RE: [patch v5 1/2] mfd: Add Mellanox regmap core driver

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

 



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

Thanks,
Vadim.

> 
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source
> software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog




[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux