Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1303627 > unrolled thread

[PATCH 0/6] Add support for MAXIM MAX77620/MAX20024 PMIC

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/6] Add support for MAXIM MAX77620/MAX20024 PMIC Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-07 15:50 +0100
    [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC driver Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-07 15:50 +0100
      Re: [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC  driver Linux Kernel <linuxkernelmails@gmail.com> - 2016-01-08 02:10 +0100
        Re: [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC  driver Lee Jones <lee.jones@linaro.org> - 2016-01-11 06:50 +0100
          Re: [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC driver Linus Walleij <linus.walleij@linaro.org> - 2016-01-14 10:10 +0100
      Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for  max77620/max20024 RTC driver Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-01-08 03:10 +0100
        Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024  RTC driver Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-08 11:40 +0100
          Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for  max77620/max20024 RTC driver Mark Brown <broonie@kernel.org> - 2016-01-08 14:00 +0100
            Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024  RTC driver Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-08 14:20 +0100
              Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for  max77620/max20024 RTC driver Mark Brown <broonie@kernel.org> - 2016-01-08 14:40 +0100
                Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024  RTC driver Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-08 14:50 +0100
                  Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024  RTC driver Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-11 14:30 +0100
                    Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for  max77620/max20024 RTC driver Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-01-11 17:10 +0100
                      Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024  RTC driver Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-11 18:20 +0100
                        Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for  max77620/max20024 RTC driver Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-01-12 01:20 +0100
                          Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024  RTC driver Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-12 03:50 +0100
                            Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for  max77620/max20024 RTC driver Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-01-12 05:00 +0100
          Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for  max77620/max20024 RTC driver Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-01-08 14:10 +0100
            Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024  RTC driver Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-08 14:30 +0100
    [PATCH 6/6] regulator: max77620: add regulator driver for max77620/max20024 Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-07 16:00 +0100
      Re: [PATCH 6/6] regulator: max77620: add regulator driver for  max77620/max20024 Mark Brown <broonie@kernel.org> - 2016-01-10 13:50 +0100
        Re: [PATCH 6/6] regulator: max77620: add regulator driver for max77620/max20024 Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-11 11:30 +0100
    [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024 Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-07 16:00 +0100
      Re: [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC  max77620/max20024 Rob Herring <robh@kernel.org> - 2016-01-08 00:20 +0100
        Re: [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024 Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-08 07:20 +0100
          Re: [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024 Rob Herring <robh@kernel.org> - 2016-01-08 15:30 +0100
    Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024 Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-08 10:30 +0100
      Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for  MAX77620/MAX20024 Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-01-08 14:20 +0100
        Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024 Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-08 14:30 +0100
          Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024 Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-01-08 14:40 +0100
    Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for  MAX77620/MAX20024 Lee Jones <lee.jones@linaro.org> - 2016-01-11 06:50 +0100
      Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for  MAX77620/MAX20024 Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-01-11 07:30 +0100
        Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for  MAX77620/MAX20024 Lee Jones <lee.jones@linaro.org> - 2016-01-11 10:10 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1305549 — Re: [PATCH 6/6] regulator: max77620: add regulator driver for max77620/max20024

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 07, 2016 at 08:08:44PM +0530, Laxman Dewangan wrote:

This looks mostly good, a few fairly small things:

> +	if (rinfo->type == MAX77620_REGULATOR_TYPE_SD)
> +		addr = rinfo->cfg_addr;

Please write things like this as switch statement so if we end up adding
more variants the code looks more natural.

> +	case REGULATOR_MODE_IDLE:
> +	case REGULATOR_MODE_STANDBY:
> +		if (rpdata->glpm_enable)
> +			power_mode = MAX77620_POWER_MODE_GLPM;
> +		else
> +			power_mode = MAX77620_POWER_MODE_LPM;
> +		break;

If there's no difference between two modes just don't implement one of
the modes and let the framework worry about what to do for the other
one.

> +static int max77620_get_regulator_dt_data(struct platform_device *pdev,
> +		struct max77620_regulator *max77620_regs)
> +{
> +	struct device_node *np;
> +	u32 prop;
> +	int id;
> +	int ret;
> +
> +	np = of_get_child_by_name(pdev->dev.parent->of_node, "regulators");
> +	if (!np) {
> +		dev_err(&pdev->dev, "Device is not having regulators node\n");
> +		return -ENODEV;
> +	}
> +	pdev->dev.of_node = np;
> +
> +	ret = of_regulator_match(&pdev->dev, np, max77620_regulator_matches,
> +			ARRAY_SIZE(max77620_regulator_matches));
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Parsing of regulator node failed: %d\n",
> +			ret);
> +		return ret;
> +	}

Don't open code this, use the core support via regulators and of_match.

> +		if (reg_pdata->disable_remote_sense_on_suspend &&
> +				(rinfo->remote_sense_addr != 0xFF)) {

Weird indentation here, the second line doesn't seem to be aligned with
anything.

[toc] | [prev] | [next] | [standalone]

#1306013 — Re: [PATCH 6/6] regulator: max77620: add regulator driver for max77620/max20024

Thanks Mark for review.

I have query in one of comment.

On Sunday 10 January 2016 06:10 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Thu, Jan 07, 2016 at 08:08:44PM +0530, Laxman Dewangan wrote:
>
>
> +	np = of_get_child_by_name(pdev->dev.parent->of_node, "regulators");
> +	if (!np) {
> +		dev_err(&pdev->dev, "Device is not having regulators node\n");
> +		return -ENODEV;
> +	}
> +	pdev->dev.of_node = np;
> +
> +	ret = of_regulator_match(&pdev->dev, np, max77620_regulator_matches,
> +			ARRAY_SIZE(max77620_regulator_matches));
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Parsing of regulator node failed: %d\n",
> +			ret);
> +		return ret;
> +	}
> Don't open code this, use the core support via regulators and of_match.
>

I did not get this point? Here I am using the of_regulator_match from 
core? Can you please help to explain this?

[toc] | [prev] | [next] | [standalone]

#1303642 — [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024

The MAXIM PMIC MAX77620 and MAX20024 are power management IC
which supports RTC, GPIO, DCDC/LDO regulators, interrupt,
watchdog etc.

Add DT binding document for the different functionality of
this device.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 Documentation/devicetree/bindings/mfd/max77620.txt | 383 +++++++++++++++++++++
 include/dt-bindings/mfd/max77620.h                 |  38 ++
 2 files changed, 421 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
 create mode 100644 include/dt-bindings/mfd/max77620.h

diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
new file mode 100644
index 0000000..09cff4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77620.txt
@@ -0,0 +1,383 @@
+* MAX77620 Power management IC from Maxim Semiconductor.
+
+Required properties:
+-------------------
+- compatible: Must be one of
+		"maxim,max77620" or
+		"maxim,max20024".
+- reg: I2C device address.
+- interrupt-controller: MAX77620 has internal interrupt controller which
+  takes the interrupt request from internal sub-blocks like RTC,
+  regulators, GPIOs as well as external input.
+- #interrupt-cells: Should be set to 2 for IRQ number and flags.
+  The first cell is the IRQ number. IRQ numbers for different interrupt
+  source of MAX77620 are defined at dt-bindings/mfd/max77620.h
+  The second cell is the flags, encoded as the trigger masks from binding
+  document interrupts.txt, using dt-bindings/irq.
+
+Optional properties:
+-------------------
+This device also supports the power OFF of system.
+Following properties are used for this purpose:
+- system-power-controller: Boolean, This device will be use as
+	system power controller and used for power OFF of system.
+	Host issue necessary command to PMIC.
+
+
+Optional submodule and their properties:
+=======================================
+
+Flexible power sequence configuration
+====================================
+This sub-node configures the Flexible Power Sequnece(FPS) for power ON slot,
+power OFF slot and slot period of the device. Device has 3 FPS as FPS0,
+FPS1 and FPS2. The details of FPS configuration is provided through
+subnode "fps". The details of FPS0, FPS1, FPS2 are provided through the
+child node under this subnodes. The FPS number is provided via reg property.
+
+The property for fps child nodes as:
+Required properties:
+	-reg: FPS number like 0, 1, 2 for FPS0, FPS1 and FPS2 respectively.
+Optinal properties:
+	-maxim,active-fps-time-period: Active state FPS time period.
+	-maxim,suspend-fps-time-period: Suspend state FPS time period.
+	-maxim,fps-enable-input: FPS enable source like EN0, EN1 or SW. The
+			macros are defined on dt-bindings/mfd/max77620.h for
+			different enable source.
+				FPS_EN_SRC_EN0 for EN0 enable source.
+				FPS_EN_SRC_EN1 for En1 enable source.
+				FPS_EN_SRC_SW for SW based control.
+	-maxim,fps-sw-enable: Boolean, applicable if enable input is SW.
+			If this property present then enable the FPS else
+			disable FPS.
+	-maxim,enable-sleep: Enable sleep when the external control goes from
+			HIGH to LOW.
+	-maxim,enable-global-lpm: Enable global LPM when the external control
+			goes from HIGH to LOW.
+
+Pinmux and GPIO:
+===============
+Device has 8 GPIO pins which can be configured as GPIO as well as the
+special IO functions.
+
+Please refer to pinctrl-bindings.txt for details of the common pinctrl
+bindings used by client devices, including the meaning of the phrase
+"pin configuration node".
+
+Following are properties which is needed if GPIO and pinmux functionality
+is required:
+    Required properties:
+    -------------------
+	- gpio-controller: Marks the device node as a GPIO controller.
+	- #gpio-cells: Number of GPIO cells. Refer to binding document
+			gpio/gpio.txt
+
+    Optional properties:
+    --------------------
+	Following properties are require if pin control setting is required
+	at boot.
+	- pinctrl-names: A pinctrl state named "default" be defined, using
+		the bindings in pinctrl/pinctrl-binding.txt.
+	- pinctrl[0...n]: Properties to contain the phandle that refer to
+		different nodes of pin control settings. These nodes
+		represents the pin control setting of state 0 to state n.
+		Each of these nodes contains different subnodes to
+		represents some desired configuration for a list of pins.
+		This configuration can include the mux function to select
+		on those pin(s), and various pin configuration parameters,
+		such as pull-up, open drain.
+
+		Each subnode have following properties:
+		Required properties:
+		    - pins: List of pins. Valid values of pins properties
+				are: gpio0, gpio1, gpio2, gpio3, gpio4,
+				gpio5, gpio6, gpio7
+
+		Optional properties:
+			function, drive-push-pull, drive-open-drain,
+			bias-pull-up, bias-pull-down.
+				Definitions are in the pinmux dt binding
+			devicetree/bindings/pinctrl/pinctrl-bindings.txt
+			Absence of properties will leave the configuration
+			on default.
+
+			Valid values for function properties are:
+				gpio, lpm-control-in, fps-out, 32k-out,
+				sd0-dvs-in, sd1-dvs-in, reference-out
+			Theres is also customised property for the GPIO1,
+				GPIO2 and GPIO3.
+			- maxim,active-fps-source: FPS source for the gpios in
+				active state of the GPIO. Valid values are
+				FPS_SRC_0, FPS_SRC_1, FPS_SRC_2 and
+				FPS_SRC_NONE. Absence of this property will
+				leave the pin on default.
+			- maxim,active-fps-power-up-slot: Power up slot on
+				given FPS for acive state.Valid values are 0
+				to 7.
+			- maxim,active-fps-power-down-slot: Power down slot
+				on given FPS for active state. Valid values
+				are 0 t  7.
+			- maxim,suspend-fps-source: Suspend state FPS source.
+			- maxim,suspend-fps-power-down-slot: Suspend state
+				power down slot.
+			- maxim,suspend-fps-power-up-slot: Suspend state power
+				up slot.
+
+Regulators:
+===========
+Device has multiple DCDC(sd[0-3] and LDOs(ldo[0-8]). The node "regulators"
+is require if regulator functionality is needed.
+
+Following are properties of regulator subnode.
+
+    Optional properties:
+    -------------------
+	The input supply of regulators are the optional properties on the
+	regulator node. The input supply of these regulators are provided
+	through following properties:
+		in-sd0-supply: Input supply for SD0, INA-SD0 or INB-SD0 pins.
+		in-sd1-supply: Input supply for SD1.
+		in-sd2-supply: Input supply for SD2.
+		in-sd3-supply: Input supply for SD3.
+		in-ldo0-1-supply: Input supply for LDO0 and LDO1.
+		in-ldo2-supply: Input supply for LDO2.
+		in-ldo3-5-supply: Input supply for LDO3 and LDO5
+		in-ldo4-6-supply: Input supply for LDO4 and LDO6.
+		in-ldo7-8-supply: Input supply for LDO7 and LDO8.
+
+
+    Optional sub nodes for regulators:
+    ---------------------------------
+	The subnodes name is the name of regulator and it must be one of:
+	sd[0-3], ldo[0-8]
+
+	Each sub-node should contain the constraints and initialization
+	information for that regulator. See regulator.txt for a description
+	of standard properties for these sub-nodes.
+	Additional optional custom properties  are listed below.
+		maxim,active-fps-source: FPS source. The macros are defined at
+			dt-bindings/mfd/max77620.h
+		maxim,shutdown-fps-source: Same as maxim,fps-source, but it
+			will apply during shutdown of system.
+		maxim,active-fps-power-up-slot: Active state Power up slot for
+			rail on given FPS.
+		maxim,active-fps-power-down-slot: Active state Power down slot
+			for rail on given FPS.
+		maxim,suspend-fps-source: Suspend state FPS source of rail.
+		maxim,suspend-fps-power-up-slot: Suspend state FPS power
+			up slot.
+		maxim,suspend-fps-power-down-slot: Suspend state FPS power
+			down slot.
+		maxim,enable-group-low-power: Enable Group low power mode.
+		maxim,enable-sd0-en2-control: Enable EN2 pincontrol for SD0.
+			This property is only applicable for SD0.
+		maxim,disable-remote-sense-on-suspend: Boolean, disable
+			remote sense on suspend and re-enable on resume.
+			If this property is not there then no change on
+			configuration.
+
+Backup Battery:
+==============
+This sub-node configure charging backup battery of the device. Device
+has support of charging the backup battery. The subnode name is
+"backup-battery".
+
+The property for backup-battery child nodes as:
+Presense of this child node will enable the backup battery charging.
+
+Optinal properties:
+	-maxim,backup-battery-charging-current: Charging current setting.
+			The device supports 50/100/200/400/600/800uA.
+			If this property is unavailable then it will
+			charge with 50uA.
+	-maxim,backup-battery-charging-voltage: Charging Voltage Limit Setting.
+			Device supports 2500000/3000000/3300000/350000uV.
+			Default will be set to 2500mV. The voltage will be roundoff
+			to nearest lower side if other than above is configured.
+	-maxim,backup-battery-output-resister: Output resistor on Ohm.
+			Device supports 100/1000/3000/6000 Ohms.
+
+Low-Battery Monitor:
+==================
+This sub-node configure low battery monitor configuration registers.
+Device has support for low-battery monitor configuration through
+child DT node "low-battery-monitor".
+
+Optinal properties:
+	- maxim,low-battery-dac-enable: Enable low battery DAC.
+	- maxim,low-battery-dac-disable: Disable low battery DAC.
+	- maxim,low-battery-shutdown-enable: Enable low battery shutdown.
+	- maxim,low-battery-shutdown-disable: Disable low battery shutdown.
+	- maxim,low-battery-reset-enable: Enable low battery reset.
+	- maxim,low-battery-reset-disable: Disable low battery reset.
+
+Example:
+--------
+#include <dt-bindings/mfd/max77620.h>
+...
+max77620@3c {
+	compatible = "maxim,max77620";
+	reg = <0x3c>;
+
+	interrupt-parent = <&intc>;
+	interrupts = <0 86 IRQ_TYPE_NONE>;
+
+
+Example:
+--------
+#include <dt-bindings/mfd/max77620.h>
+...
+max77620@3c {
+	compatible = "maxim,max77620";
+	reg = <0x3c>;
+
+	interrupt-parent = <&intc>;
+	interrupts = <0 86 IRQ_TYPE_NONE>;
+
+	interrupt-controller;
+	#interrupt-cells = <2>;
+
+	gpio-controller;
+	#gpio-cells = <2>;
+
+	backup-battery {
+		maxim,backup-battery-charging-current = <100>;
+		maxim,backup-battery-charging-voltage = <3000000>;
+		maxim,backup-battery-output-resister = <100>;
+	};
+
+	fps {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		fps@0 {
+			reg = <0>;
+			maxim,fps-time-period = <100>;
+			maxim,fps-enable-input = <FPS_EN_SRC_EN0>;
+		};
+
+		fps@1 {
+			reg = <1>;
+			maxim,fps-time-period = <100>;
+			maxim,fps-enable-input = <FPS_EN_SRC_EN1>;
+		};
+
+		fps@2 {
+			reg = <2>;
+			maxim,fps-time-period = <100>;
+			maxim,fps-enable-input = <FPS_EN_SRC_SW>;
+		};
+	};
+
+	regulators {
+		in-ldo0-1-supply = <&max77620_sd2>;
+		in-ldo7-8-supply = <&max77620_sd2>;
+
+		max77620_sd0: sd0 {
+			regulator-name = "vdd-core";
+			regulator-min-microvolt = <600000>;
+			regulator-max-microvolt = <1400000>;
+			regulator-boot-on;
+			regulator-always-on;
+			maxim,fps-source = <FPS_SRC_1>;
+			regulator-init-mode = <REGULATOR_MODE_NORMAL>;
+		};
+
+		max77620_sd1: sd1 {
+			regulator-name = "vddio-ddr";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-always-on;
+			regulator-boot-on;
+			regulator-init-mode = <REGULATOR_MODE_NORMAL>;
+			maxim,fps-source = <FPS_SRC_0>;
+		};
+
+		max77620_sd2: sd2 {
+			regulator-name = "vdd-pre-reg";
+			regulator-min-microvolt = <1350000>;
+			regulator-max-microvolt = <1350000>;
+			maxim,fps-source = <FPS_SRC_1>;
+		};
+
+		max77620_sd3: sd3 {
+			regulator-name = "vdd-1v8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-always-on;
+			regulator-boot-on;
+			maxim,fps-source = <FPS_SRC_0>;
+			regulator-init-mode = <REGULATOR_MODE_NORMAL>;
+		};
+
+		max77620_ldo0: ldo0 {
+			regulator-name = "avdd-sys";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-always-on;
+			regulator-boot-on;
+			maxim,fps-source = <FPS_SRC_NONE>;
+		};
+
+		max77620_ldo1: ldo1 {
+			regulator-name = "vdd-pex";
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			maxim,fps-source = <FPS_SRC_NONE>;
+		};
+
+		max77620_ldo2: ldo2 {
+			regulator-name = "vddio-sdmmc3";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3300000>;
+			maxim,fps-source = <FPS_SRC_NONE>;
+		};
+
+		max77620_ldo3: ldo3 {
+			regulator-name = "vdd-cam-hv";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			maxim,fps-source = <FPS_SRC_NONE>;
+		};
+
+		max77620_ldo4: ldo4 {
+			regulator-name = "vdd-rtc";
+			regulator-min-microvolt = <1250000>;
+			regulator-max-microvolt = <1250000>;
+			regulator-always-on;
+			regulator-boot-on;
+			maxim,fps-source = <FPS_SRC_0>;
+		};
+
+		max77620_ldo5: ldo5 {
+			regulator-name = "avdd-ts-hv";
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+			maxim,fps-source = <FPS_SRC_NONE>;
+		};
+
+		max77620_ldo6: ldo6 {
+			regulator-name = "vdd-ts";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-always-on;
+			regulator-boot-on;
+			maxim,fps-source = <FPS_SRC_NONE>;
+		};
+
+		max77620_ldo7: ldo7 {
+			regulator-name = "vdd-gen-pll-edp";
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			regulator-always-on;
+			regulator-boot-on;
+			maxim,fps-source = <FPS_SRC_1>;
+		};
+
+		max77620_ldo8: ldo8 {
+			regulator-name = "vdd-hdmi-dp";
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			maxim,fps-source = <FPS_SRC_NONE>;
+		};
+	};
+};
diff --git a/include/dt-bindings/mfd/max77620.h b/include/dt-bindings/mfd/max77620.h
new file mode 100644
index 0000000..8423d1d
--- /dev/null
+++ b/include/dt-bindings/mfd/max77620.h
@@ -0,0 +1,38 @@
+/*
+ * This header provides macros for MAXIM MAX77620 device bindings.
+ *
+ * Copyright (c) 2016, NVIDIA Corporation.
+ *
+ * Author: Laxman Dewangan <ldewangan@nvidia.com>
+ *
+ */
+
+#ifndef _DT_BINDINGS_MFD_MAX77620_H
+#define _DT_BINDINGS_MFD_MAX77620_H
+
+/* MAX77620 interrupts */
+#define MAX77620_IRQ_TOP_GLBL		0 /* Low-Battery */
+#define MAX77620_IRQ_TOP_SD		1 /* SD power fail */
+#define MAX77620_IRQ_TOP_LDO		2 /* LDO power fail */
+#define MAX77620_IRQ_TOP_GPIO		3 /* GPIO internal int to MAX77620 */
+#define MAX77620_IRQ_TOP_RTC		4 /* RTC */
+#define MAX77620_IRQ_TOP_32K		5 /* 32kHz oscillator */
+#define MAX77620_IRQ_TOP_ONOFF		6 /* ON/OFF oscillator */
+#define MAX77620_IRQ_LBT_MBATLOW	7 /* Thermal alarm status, > 120C */
+#define MAX77620_IRQ_LBT_TJALRM1	8 /* Thermal alarm status, > 120C */
+#define MAX77620_IRQ_LBT_TJALRM2	9 /* Thermal alarm status, > 140C */
+
+/* FPS enable -inputs */
+#define FPS_EN_SRC_EN0	0
+#define FPS_EN_SRC_EN1	1
+#define FPS_EN_SRC_SW	2
+#define FPS_EN_SRC_RSVD	3
+
+/* FPS source */
+#define FPS_SRC_0	0
+#define FPS_SRC_1	1
+#define FPS_SRC_2	2
+#define FPS_SRC_NONE	3
+#define FPS_SRC_DEF	4
+
+#endif
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303995 — Re: [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024

On Thu, Jan 07, 2016 at 08:08:39PM +0530, Laxman Dewangan wrote:
> The MAXIM PMIC MAX77620 and MAX20024 are power management IC
> which supports RTC, GPIO, DCDC/LDO regulators, interrupt,
> watchdog etc.
> 
> Add DT binding document for the different functionality of
> this device.
> 
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> ---
>  Documentation/devicetree/bindings/mfd/max77620.txt | 383 +++++++++++++++++++++
>  include/dt-bindings/mfd/max77620.h                 |  38 ++
>  2 files changed, 421 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
>  create mode 100644 include/dt-bindings/mfd/max77620.h
> 
> diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
> new file mode 100644
> index 0000000..09cff4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/max77620.txt
> @@ -0,0 +1,383 @@
> +* MAX77620 Power management IC from Maxim Semiconductor.
> +
> +Required properties:
> +-------------------
> +- compatible: Must be one of
> +		"maxim,max77620" or
> +		"maxim,max20024".
> +- reg: I2C device address.
> +- interrupt-controller: MAX77620 has internal interrupt controller which
> +  takes the interrupt request from internal sub-blocks like RTC,
> +  regulators, GPIOs as well as external input.
> +- #interrupt-cells: Should be set to 2 for IRQ number and flags.
> +  The first cell is the IRQ number. IRQ numbers for different interrupt
> +  source of MAX77620 are defined at dt-bindings/mfd/max77620.h
> +  The second cell is the flags, encoded as the trigger masks from binding
> +  document interrupts.txt, using dt-bindings/irq.
> +
> +Optional properties:
> +-------------------
> +This device also supports the power OFF of system.
> +Following properties are used for this purpose:
> +- system-power-controller: Boolean, This device will be use as
> +	system power controller and used for power OFF of system.
> +	Host issue necessary command to PMIC.
> +
> +
> +Optional submodule and their properties:
> +=======================================
> +
> +Flexible power sequence configuration
> +====================================
> +This sub-node configures the Flexible Power Sequnece(FPS) for power ON slot,
> +power OFF slot and slot period of the device. Device has 3 FPS as FPS0,
> +FPS1 and FPS2. The details of FPS configuration is provided through
> +subnode "fps". The details of FPS0, FPS1, FPS2 are provided through the
> +child node under this subnodes. The FPS number is provided via reg property.
> +
> +The property for fps child nodes as:
> +Required properties:
> +	-reg: FPS number like 0, 1, 2 for FPS0, FPS1 and FPS2 respectively.
> +Optinal properties:
> +	-maxim,active-fps-time-period: Active state FPS time period.
> +	-maxim,suspend-fps-time-period: Suspend state FPS time period.

What are the units?

> +	-maxim,fps-enable-input: FPS enable source like EN0, EN1 or SW. The
> +			macros are defined on dt-bindings/mfd/max77620.h for
> +			different enable source.
> +				FPS_EN_SRC_EN0 for EN0 enable source.
> +				FPS_EN_SRC_EN1 for En1 enable source.
> +				FPS_EN_SRC_SW for SW based control.
> +	-maxim,fps-sw-enable: Boolean, applicable if enable input is SW.
> +			If this property present then enable the FPS else
> +			disable FPS.
> +	-maxim,enable-sleep: Enable sleep when the external control goes from
> +			HIGH to LOW.

Boolean?

> +	-maxim,enable-global-lpm: Enable global LPM when the external control
> +			goes from HIGH to LOW.

Boolean?

> +
> +Pinmux and GPIO:
> +===============
> +Device has 8 GPIO pins which can be configured as GPIO as well as the
> +special IO functions.
> +
> +Please refer to pinctrl-bindings.txt for details of the common pinctrl
> +bindings used by client devices, including the meaning of the phrase
> +"pin configuration node".
> +
> +Following are properties which is needed if GPIO and pinmux functionality
> +is required:
> +    Required properties:
> +    -------------------
> +	- gpio-controller: Marks the device node as a GPIO controller.
> +	- #gpio-cells: Number of GPIO cells. Refer to binding document
> +			gpio/gpio.txt
> +
> +    Optional properties:
> +    --------------------
> +	Following properties are require if pin control setting is required
> +	at boot.
> +	- pinctrl-names: A pinctrl state named "default" be defined, using
> +		the bindings in pinctrl/pinctrl-binding.txt.
> +	- pinctrl[0...n]: Properties to contain the phandle that refer to
> +		different nodes of pin control settings. These nodes
> +		represents the pin control setting of state 0 to state n.
> +		Each of these nodes contains different subnodes to
> +		represents some desired configuration for a list of pins.
> +		This configuration can include the mux function to select
> +		on those pin(s), and various pin configuration parameters,
> +		such as pull-up, open drain.
> +
> +		Each subnode have following properties:
> +		Required properties:
> +		    - pins: List of pins. Valid values of pins properties
> +				are: gpio0, gpio1, gpio2, gpio3, gpio4,
> +				gpio5, gpio6, gpio7
> +
> +		Optional properties:
> +			function, drive-push-pull, drive-open-drain,
> +			bias-pull-up, bias-pull-down.
> +				Definitions are in the pinmux dt binding
> +			devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +			Absence of properties will leave the configuration
> +			on default.
> +
> +			Valid values for function properties are:
> +				gpio, lpm-control-in, fps-out, 32k-out,
> +				sd0-dvs-in, sd1-dvs-in, reference-out
> +			Theres is also customised property for the GPIO1,
> +				GPIO2 and GPIO3.
> +			- maxim,active-fps-source: FPS source for the gpios in
> +				active state of the GPIO. Valid values are
> +				FPS_SRC_0, FPS_SRC_1, FPS_SRC_2 and
> +				FPS_SRC_NONE. Absence of this property will
> +				leave the pin on default.
> +			- maxim,active-fps-power-up-slot: Power up slot on
> +				given FPS for acive state.Valid values are 0
> +				to 7.
> +			- maxim,active-fps-power-down-slot: Power down slot
> +				on given FPS for active state. Valid values
> +				are 0 t  7.
> +			- maxim,suspend-fps-source: Suspend state FPS source.
> +			- maxim,suspend-fps-power-down-slot: Suspend state
> +				power down slot.
> +			- maxim,suspend-fps-power-up-slot: Suspend state power
> +				up slot.
> +
> +Regulators:
> +===========
> +Device has multiple DCDC(sd[0-3] and LDOs(ldo[0-8]). The node "regulators"
> +is require if regulator functionality is needed.
> +
> +Following are properties of regulator subnode.
> +
> +    Optional properties:
> +    -------------------
> +	The input supply of regulators are the optional properties on the
> +	regulator node. The input supply of these regulators are provided
> +	through following properties:
> +		in-sd0-supply: Input supply for SD0, INA-SD0 or INB-SD0 pins.
> +		in-sd1-supply: Input supply for SD1.
> +		in-sd2-supply: Input supply for SD2.
> +		in-sd3-supply: Input supply for SD3.
> +		in-ldo0-1-supply: Input supply for LDO0 and LDO1.
> +		in-ldo2-supply: Input supply for LDO2.
> +		in-ldo3-5-supply: Input supply for LDO3 and LDO5
> +		in-ldo4-6-supply: Input supply for LDO4 and LDO6.
> +		in-ldo7-8-supply: Input supply for LDO7 and LDO8.
> +
> +
> +    Optional sub nodes for regulators:
> +    ---------------------------------
> +	The subnodes name is the name of regulator and it must be one of:
> +	sd[0-3], ldo[0-8]
> +
> +	Each sub-node should contain the constraints and initialization
> +	information for that regulator. See regulator.txt for a description
> +	of standard properties for these sub-nodes.
> +	Additional optional custom properties  are listed below.
> +		maxim,active-fps-source: FPS source. The macros are defined at
> +			dt-bindings/mfd/max77620.h
> +		maxim,shutdown-fps-source: Same as maxim,fps-source, but it
> +			will apply during shutdown of system.
> +		maxim,active-fps-power-up-slot: Active state Power up slot for
> +			rail on given FPS.
> +		maxim,active-fps-power-down-slot: Active state Power down slot
> +			for rail on given FPS.
> +		maxim,suspend-fps-source: Suspend state FPS source of rail.
> +		maxim,suspend-fps-power-up-slot: Suspend state FPS power
> +			up slot.
> +		maxim,suspend-fps-power-down-slot: Suspend state FPS power
> +			down slot.
> +		maxim,enable-group-low-power: Enable Group low power mode.
> +		maxim,enable-sd0-en2-control: Enable EN2 pincontrol for SD0.
> +			This property is only applicable for SD0.
> +		maxim,disable-remote-sense-on-suspend: Boolean, disable
> +			remote sense on suspend and re-enable on resume.
> +			If this property is not there then no change on
> +			configuration.
> +
> +Backup Battery:
> +==============
> +This sub-node configure charging backup battery of the device. Device
> +has support of charging the backup battery. The subnode name is
> +"backup-battery".
> +
> +The property for backup-battery child nodes as:
> +Presense of this child node will enable the backup battery charging.
> +
> +Optinal properties:
> +	-maxim,backup-battery-charging-current: Charging current setting.
> +			The device supports 50/100/200/400/600/800uA.
> +			If this property is unavailable then it will
> +			charge with 50uA.

Add units suffix (-microamp).

> +	-maxim,backup-battery-charging-voltage: Charging Voltage Limit Setting.
> +			Device supports 2500000/3000000/3300000/350000uV.
> +			Default will be set to 2500mV. The voltage will be roundoff
> +			to nearest lower side if other than above is configured.

Add units suffix (-microvolt).

> +	-maxim,backup-battery-output-resister: Output resistor on Ohm.
> +			Device supports 100/1000/3000/6000 Ohms.

Add units suffix.

> +
> +Low-Battery Monitor:
> +==================
> +This sub-node configure low battery monitor configuration registers.
> +Device has support for low-battery monitor configuration through
> +child DT node "low-battery-monitor".
> +
> +Optinal properties:
> +	- maxim,low-battery-dac-enable: Enable low battery DAC.
> +	- maxim,low-battery-dac-disable: Disable low battery DAC.
> +	- maxim,low-battery-shutdown-enable: Enable low battery shutdown.
> +	- maxim,low-battery-shutdown-disable: Disable low battery shutdown.
> +	- maxim,low-battery-reset-enable: Enable low battery reset.
> +	- maxim,low-battery-reset-disable: Disable low battery reset.

Why not boolean? Not present means keep default value? I'd prefer 
boolean or tristate of not present, 0 to disable, or 1 to enable.

Rob

[toc] | [prev] | [next] | [standalone]

#1304204 — Re: [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024

Thanks Rob for review.
I have taken care of all comment except following which I have query.

On Friday 08 January 2016 04:42 AM, Rob Herring wrote:
> +	- maxim,low-battery-reset-enable: Enable low battery reset.
> +	- maxim,low-battery-reset-disable: Disable low battery reset.
> Why not boolean? Not present means keep default value? I'd prefer
> boolean or tristate of not present, 0 to disable, or 1 to enable.
>
>
Here, the properties are boolean. I will add this on the description.

I like to enable or disable with the DT and properties are not there 
then left to default.
So added two properties for enable and disable. If properties are there, 
do the activity.

Here tristate is also possible:
maxim,low-battery-reset: tristate, low battery reset control. 0 for 
disable, 1 for enable and
                                  absence of this will leave 
configuration on default.

Does it look fine?

[toc] | [prev] | [next] | [standalone]

#1304614 — Re: [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024

On Fri, Jan 8, 2016 at 12:06 AM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
> Thanks Rob for review.
> I have taken care of all comment except following which I have query.
>
> On Friday 08 January 2016 04:42 AM, Rob Herring wrote:
>>
>> +       - maxim,low-battery-reset-enable: Enable low battery reset.
>> +       - maxim,low-battery-reset-disable: Disable low battery reset.
>> Why not boolean? Not present means keep default value? I'd prefer
>> boolean or tristate of not present, 0 to disable, or 1 to enable.
>>
>>
> Here, the properties are boolean. I will add this on the description.
>
> I like to enable or disable with the DT and properties are not there then
> left to default.
> So added two properties for enable and disable. If properties are there, do
> the activity.
>
> Here tristate is also possible:
> maxim,low-battery-reset: tristate, low battery reset control. 0 for disable,
> 1 for enable and
>                                  absence of this will leave configuration on
> default.
>
> Does it look fine?

Yes.

Rob

[toc] | [prev] | [next] | [standalone]

#1304307 — Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024

Hi Krzysztof,
Thanks for review.
I will fix most of your comment on my next patch.

Answering to some of comment/query.

On Friday 08 January 2016 07:05 AM, Krzysztof Kozlowski wrote:
> ()2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@nvidia.com>:
> +                               dev_err(dev,
> +                                   "FPS enable-input %u is not supported\n",
> +                                       pval);
> Indentation of arguments does not seem equal here or maybe this is
> just my email client. Have you run this through checkpatch? And
> sparse? And coccicheck (that one definitely not because kbuild is
> complaining)?
I ran checkpatch before I sent.

> +               chip->rmap[i] = devm_regmap_init_i2c(chip->clients[i],
> +               (const struct regmap_config *)&max77620_regmap_config[i]);
> Indentation looks weird here (or again this is my email client...).
> The cast is even weirder?!? Why casting?
There is some parameter difference for MAX77620 and MAX20024. I have 
only one structure for it and changing tun time so I have not define 
this structure as constant.
Now API needs const type structure and hence casting it.

However, I have  define different structure for MAX77620 and MAX20024 
which are const type and hence no need to explicitly casting here. This 
will be in my next patch.

+static inline int max77620_reg_update(struct device *dev, int sid,
+               unsigned int reg, unsigned int mask, unsigned int val)
+{
+       struct max77620_chip *chip = dev_get_drvdata(dev);
+
+       return regmap_update_bits(chip->rmap[sid], reg, mask, val);
+}

> I think all these shouldn't be static inlines in header. Although some
> of them are one-liners but rest are not. Let the compiler decide what
> to do with these wrappers.

If I dont make inline from header then this will complain as unused 
static function on related C compilation if it is not used on C. This 
header included from all sub module driver and they are not using all 
these APIs.

To avoid compilation warning,  I need to use inline here.

[toc] | [prev] | [next] | [standalone]

#1304529 — Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024

W dniu 08.01.2016 o 18:16, Laxman Dewangan pisze:
> Hi Krzysztof,
> Thanks for review.
> I will fix most of your comment on my next patch.
> 
> Answering to some of comment/query.
> 
> On Friday 08 January 2016 07:05 AM, Krzysztof Kozlowski wrote:
>> ()2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@nvidia.com>:
>> +                               dev_err(dev,
>> +                                   "FPS enable-input %u is not
>> supported\n",
>> +                                       pval);
>> Indentation of arguments does not seem equal here or maybe this is
>> just my email client. Have you run this through checkpatch? And
>> sparse? And coccicheck (that one definitely not because kbuild is
>> complaining)?
> I ran checkpatch before I sent.

Anyway please be sure that indentation is consistent.

> 
>> +               chip->rmap[i] = devm_regmap_init_i2c(chip->clients[i],
>> +               (const struct regmap_config
>> *)&max77620_regmap_config[i]);
>> Indentation looks weird here (or again this is my email client...).
>> The cast is even weirder?!? Why casting?
> There is some parameter difference for MAX77620 and MAX20024. I have
> only one structure for it and changing tun time so I have not define
> this structure as constant.
> Now API needs const type structure and hence casting it.

I don't quite get... usually there is no need of casting pointer to a
writable memory when function accepts pointer to const.

> 
> However, I have  define different structure for MAX77620 and MAX20024
> which are const type and hence no need to explicitly casting here. This
> will be in my next patch.

You mean v2? Okay, let's wait for that...

> 
> +static inline int max77620_reg_update(struct device *dev, int sid,
> +               unsigned int reg, unsigned int mask, unsigned int val)
> +{
> +       struct max77620_chip *chip = dev_get_drvdata(dev);
> +
> +       return regmap_update_bits(chip->rmap[sid], reg, mask, val);
> +}
> 
>> I think all these shouldn't be static inlines in header. Although some
>> of them are one-liners but rest are not. Let the compiler decide what
>> to do with these wrappers.
> 
> If I dont make inline from header then this will complain as unused
> static function on related C compilation if it is not used on C. This
> header included from all sub module driver and they are not using all
> these APIs.
> 
> To avoid compilation warning,  I need to use inline here.

Because this shouldn't be defined in header at the first place. Instead
define it in main MFD driver with EXPORT_SYMBOL() and put in headers
just declaration.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1304535 — Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024

On Friday 08 January 2016 06:44 PM, Krzysztof Kozlowski wrote:
>
> To avoid compilation warning,  I need to use inline here.
> Because this shouldn't be defined in header at the first place. Instead
> define it in main MFD driver with EXPORT_SYMBOL() and put in headers
> just declaration.
>
what about __maybe_unused instead on inline and keep in header.

Anyhow, I do not have any personal choice here.

[toc] | [prev] | [next] | [standalone]

#1304547 — Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024

2016-01-08 22:19 GMT+09:00 Laxman Dewangan <ldewangan@nvidia.com>:
>
> On Friday 08 January 2016 06:44 PM, Krzysztof Kozlowski wrote:
>>
>>
>> To avoid compilation warning,  I need to use inline here.
>> Because this shouldn't be defined in header at the first place. Instead
>> define it in main MFD driver with EXPORT_SYMBOL() and put in headers
>> just declaration.
>>
> what about __maybe_unused instead on inline and keep in header.
>
> Anyhow, I do not have any personal choice here.

This just shouldn't be defined in header because that makes it
spreading over many object files. There are just no benefits.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1305855 — Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024

On Fri, 08 Jan 2016, Krzysztof Kozlowski wrote:

Thanks for taking the time to review.

> ()2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@nvidia.com>:
> > MAX77620/MAX20024 are Power Management IC from the MAXIM.
> > It supports RTC, multiple GPIOs, multiple DCDC and LDOs,
> > watchdog, clock etc.
> >
> > Add MFD drier to provides common support for accessing the
> > device; additional drivers is developed on respected subsystem
> > in order to use the functionality of the device.
> >
> > Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> > Signed-off-by: Chaitanya Bandi <bandik@nvidia.com>
> > Signed-off-by: Mallikarjun Kasoju <mkasoju@nvidia.com>
> > Tested-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
> 
> The Testing and Reviewed are statements (see SubmittingPatches) so
> they should be made explicitly by people. As this is v1 how they could
> make a public statement so far?

SubmittingPatches bears no mention that Reviewed-by/Tested-by
statements have to be provided on one of the public mailing lists.
These can be provided privately prior to upstream submission v1.

> > ---
> >  drivers/mfd/Kconfig          |  15 +
> >  drivers/mfd/Makefile         |   1 +
> >  drivers/mfd/max77620.c       | 926 +++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/mfd/max77620.h | 503 +++++++++++++++++++++++
> >  4 files changed, 1445 insertions(+)
> >  create mode 100644 drivers/mfd/max77620.c
> >  create mode 100644 include/linux/mfd/max77620.h

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

[toc] | [prev] | [next] | [standalone]

#1305878 — Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024

On 11.01.2016 14:46, Lee Jones wrote:
> On Fri, 08 Jan 2016, Krzysztof Kozlowski wrote:
> 
> Thanks for taking the time to review.
> 
>> ()2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@nvidia.com>:
>>> MAX77620/MAX20024 are Power Management IC from the MAXIM.
>>> It supports RTC, multiple GPIOs, multiple DCDC and LDOs,
>>> watchdog, clock etc.
>>>
>>> Add MFD drier to provides common support for accessing the
>>> device; additional drivers is developed on respected subsystem
>>> in order to use the functionality of the device.
>>>
>>> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
>>> Signed-off-by: Chaitanya Bandi <bandik@nvidia.com>
>>> Signed-off-by: Mallikarjun Kasoju <mkasoju@nvidia.com>
>>> Tested-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
>>
>> The Testing and Reviewed are statements (see SubmittingPatches) so
>> they should be made explicitly by people. As this is v1 how they could
>> make a public statement so far?
> 
> SubmittingPatches bears no mention that Reviewed-by/Tested-by
> statements have to be provided on one of the public mailing lists.
> These can be provided privately prior to upstream submission v1.

Indeed the document does not mention that they have to be provided by
public.

In the same time these are statements given by a reviewer ("By offering
my Reviewed-by: tag, I state that:")... and how can you validate a
statement given through a private channel? Is it true? Is it a thorough
testing or just copy-paste from Gerrit (or other automated system)?

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1305966 — Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024

On Mon, 11 Jan 2016, Krzysztof Kozlowski wrote:

> On 11.01.2016 14:46, Lee Jones wrote:
> > On Fri, 08 Jan 2016, Krzysztof Kozlowski wrote:
> > 
> > Thanks for taking the time to review.
> > 
> >> ()2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@nvidia.com>:
> >>> MAX77620/MAX20024 are Power Management IC from the MAXIM.
> >>> It supports RTC, multiple GPIOs, multiple DCDC and LDOs,
> >>> watchdog, clock etc.
> >>>
> >>> Add MFD drier to provides common support for accessing the
> >>> device; additional drivers is developed on respected subsystem
> >>> in order to use the functionality of the device.
> >>>
> >>> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> >>> Signed-off-by: Chaitanya Bandi <bandik@nvidia.com>
> >>> Signed-off-by: Mallikarjun Kasoju <mkasoju@nvidia.com>
> >>> Tested-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
> >>
> >> The Testing and Reviewed are statements (see SubmittingPatches) so
> >> they should be made explicitly by people. As this is v1 how they could
> >> make a public statement so far?
> > 
> > SubmittingPatches bears no mention that Reviewed-by/Tested-by
> > statements have to be provided on one of the public mailing lists.
> > These can be provided privately prior to upstream submission v1.
> 
> Indeed the document does not mention that they have to be provided by
> public.
> 
> In the same time these are statements given by a reviewer ("By offering
> my Reviewed-by: tag, I state that:")... and how can you validate a
> statement given through a private channel? Is it true? Is it a thorough
> testing or just copy-paste from Gerrit (or other automated system)?

That is for the submitter's conscience to decide.  If the statements
are supplied, we must assume they were provided in good faith and in
accordance with the rules set out by the Linux Kernel.  We can not ask
for every Tested-by/Acked-by/Reviewed-by/etc provider to verify on
each upstream submission.

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web