Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP

[Lee Jones]

On Sun, 20 Sep 2015, Herbert Xu wrote:

> On Sat, Sep 19, 2015 at 10:21:45AM +0100, Lee Jones wrote:
> >
> > That's not how it works.  It's helpful, more often than not, to submit
> > the entire set to each maintainer concerned so they can keep up with
> > the general conversation.  By only sending specific patches to
> > maintainers you essentially blinker them to the bigger picture.
> > 
> > As a maintainer you should _know_ that you can't apply patches from
> > other subsystems without appropriate Acks.  I'm sure you'd take
> > exception to another maintainer who started accepting patches for
> > subsystems you are responsible for.  This works both ways.
> 
> No you are mistaken.  You should only put patches which have
> dependencies on each other in a series.  If the patches can be
> applied independently of each other there is no need to have
> them in a single series.

That's just not true.  I've explained why it's important for everyone
involved to see the bigger picture.  Let me use this set in an
example.  The patches can (and should) be applied separately, but they
are heavily entwined.  Let's say I only sent the ARM patch to Maxime
(the STi Maintainer) and only sent you the driver and the binding
document.  There's a chance Maxime could apply the DTS changes prior
to a proper review of the bindings.  Granted, one way round this would
be to place the DTS changes into a holding-pen until the binding has
been accepted, but this method is highly impractical and puts
unnecessary burden on the contributor.

There are 1000's of examples where all parties need to see reviews on
other, related but not dependant, parts of a set.  For many of the
sets I review it's critical for me what else is going on in related
diffs.  I guess for the subsystems you maintain it's less of an issue,
but still, it _is_ how people tend to submit code and there is no good
reason for you to dictate otherwise.

> Obviously if they can go into different trees then they cannot
> have dependencies.
> 
> Cheers,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mfd: tps65912: Rewrite driver adding DT support and using regmap

[Lee Jones]

On Tue, 15 Sep 2015, Andrew F. Davis wrote:

> The old driver does not support DT. Rewrite the driver adding DT support
> and use modern kernel features such as regmap and related helpers.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/gpio/gpio-tps65912.c   | 291 ++--
>  drivers/mfd/Kconfig|  20 +-
>  drivers/mfd/Makefile   |   3 +-
>  drivers/mfd/tps65912-core.c| 288 +---
>  drivers/mfd/tps65912-i2c.c | 233 --
>  drivers/mfd/tps65912-irq.c | 217 -
>  drivers/mfd/tps65912-spi.c | 236 --
>  drivers/regulator/tps65912-regulator.c | 783 
> ++---
>  include/linux/mfd/tps65912.h   | 256 +++
>  9 files changed, 854 insertions(+), 1473 deletions(-)
>  rewrite drivers/gpio/gpio-tps65912.c (68%)
>  rewrite drivers/mfd/tps65912-core.c (96%)
>  rewrite drivers/mfd/tps65912-i2c.c (92%)
>  delete mode 100644 drivers/mfd/tps65912-irq.c
>  rewrite drivers/mfd/tps65912-spi.c (91%)
>  rewrite drivers/regulator/tps65912-regulator.c (94%)

Is there really no other way to split this up?

> diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
> dissimilarity index 68%
> index 9cdbc0c..a15d4e7 100644
> --- a/drivers/gpio/gpio-tps65912.c
> +++ b/drivers/gpio/gpio-tps65912.c
> @@ -1,153 +1,138 @@
> -/*
> - * Copyright 2011 Texas Instruments Inc.
> - *
> - * Author: Margarita Olaya 
> - *
> - *  This program is free software; you can redistribute it and/or modify it
> - *  under  the terms of the GNU General  Public License as published by the
> - *  Free Software Foundation;  either version 2 of the License, or (at your
> - *  option) any later version.
> - *
> - * This driver is based on wm8350 implementation.
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -struct tps65912_gpio_data {
> - struct tps65912 *tps65912;
> - struct gpio_chip gpio_chip;
> -};
> -
> -#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
> -
> -static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> - int val;
> -
> - val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
> -
> - if (val & GPIO_STS_MASK)
> - return 1;
> -
> - return 0;
> -}
> -
> -static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
> -   int value)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> -
> - if (value)
> - tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_SET_MASK);
> - else
> - tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_SET_MASK);
> -}
> -
> -static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
> - int value)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> -
> - /* Set the initial value */
> - tps65912_gpio_set(gc, offset, value);
> -
> - return tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_CFG_MASK);
> -}
> -
> -static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> -
> - return tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_CFG_MASK);
> -}
> -
> -static struct gpio_chip template_chip = {
> - .label  = "tps65912",
> - .owner  = THIS_MODULE,
> - .direction_input= tps65912_gpio_input,
> - .direction_output   = tps65912_gpio_output,
> - .get= tps65912_gpio_get,
> - .set= tps65912_gpio_set,
> - .can_sleep  = true,
> - .ngpio  = 5,
> - .base   = -1,
> -};
> -
> -static int tps65912_gpio_probe(struct platform_device *pdev)
> -{
> - struct tps65912 *tps65912 = dev_get_drvdata(pdev->dev.parent);
> - struct tps65912_board *pdata = dev_get_platdata(tps65912->dev);
> - struct tps65912_gpio_data *tps65912_gpio;
> - int ret;
> -
> - tps65912_gpio = devm_kzalloc(&pdev->dev, sizeof(*tps65912_gpio),
> -  GFP_KERNEL);
> - if (tps65912_gpio == NULL)
> - return -ENOMEM;
> -
> - tps65912_gpio->tps65912 = tps65912;
> - tps65912_gpio->gpio_chip =

Re: [PATCH 5/6] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Wed, 16 Sep 2015, Charles Keepax wrote:

> Add additional bindings to allow configuration of the system specific
> microphone detection settings.
> 
> Signed-off-by: Charles Keepax 
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt |   21 
> +
>  include/dt-bindings/mfd/arizona.h |5 +
>  2 files changed, 26 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index a8fee60..b98a11b 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -73,6 +73,27 @@ Optional properties:
>  If this node is not mentioned or if the value is unknown, then
>  headphone detection mode is set to HPDETL.
>  
> +  - wlf,micd-software-compare : Use a software comparison to determine mic
> +presence
> +  - wlf,micd-detect-debounce : Additional software microphone detection
> +debounce specified in milliseconds.
> +  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> +polarity if one exists.
> +  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> +performing microphone detection, specified as per the 
> ARIZONA_MICD_TIME_XXX
> +defines.
> +  - wlf,micd-rate : Delay between successive microphone detection 
> measurements,
> +specified as per the ARIZONA_MICD_TIME_XXX defines.
> +  - wlf,micd-dbtime : Microphone detection hardware debounces specified as 
> the
> +number of measurements to take, valid values being 2 and 4.
> +  - wlf,micd-timeout : Timeout for microphone detection, specified in
> +milliseconds.
> +  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> +detection.
> +
> +  - wlf,gpsw : Settings for the general purpose switch, set as one of the
> +ARIZONA_GPSW_XXX defines.

I either need an Ack from the DT folks, or at least someone who knows
about this stuff.  Mark perhaps.

>- DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified 
> if
>  they are being externally supplied. As covered in
>  Documentation/devicetree/bindings/regulator/regulator.txt
> diff --git a/include/dt-bindings/mfd/arizona.h 
> b/include/dt-bindings/mfd/arizona.h
> index c40f665..dedf46f 100644
> --- a/include/dt-bindings/mfd/arizona.h
> +++ b/include/dt-bindings/mfd/arizona.h
> @@ -110,4 +110,9 @@
>  #define ARIZONA_ACCDET_MODE_HPM 4
>  #define ARIZONA_ACCDET_MODE_ADC 7
>  
> +#define ARIZONA_GPSW_OPEN   0
> +#define ARIZONA_GPSW_CLOSED 1
> +#define ARIZONA_GPSW_CLAMP_ENABLED  2
> +#define ARIZONA_GPSW_CLAMP_DISABLED 3
> +
>  #endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] mfd: arizona: Update DT binding documentation for jack detection

[Lee Jones]

On Wed, 16 Sep 2015, Charles Keepax wrote:

> Add additional bindings for both inverting the polarity of the jack
> detection pins and allowing the use of a second jack detection pin. Note
> that the second jack detection pin is hard wired in the chip so can only
> be enabled through the binding, rather than a pin being specified.
> 
> Signed-off-by: Charles Keepax 
> Reviewed-by: Chanwoo Choi 
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index b98a11b..cb3a652 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -73,6 +73,12 @@ Optional properties:
>  If this node is not mentioned or if the value is unknown, then
>  headphone detection mode is set to HPDETL.
>  
> +  - wlf,use-jd-gpio : Use GPIO input along with JD1 for dual pin jack
> +detection.
> +  - wlf,use-jd-gpio-nopull : Internal pull on GPIO is disabled when used for
> +jack detection.
> +  - wlf,jd-invert : Invert the polarity of the jack detection switch

As before, I need an Ack from one of the DT guys, or perhaps Linus W.

>- wlf,micd-software-compare : Use a software comparison to determine mic
>  presence
>- wlf,micd-detect-debounce : Additional software microphone detection

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux-next v9 0/3] mfd: flexcom: add a driver for Flexcom

[Lee Jones]

Patch set description?

Once Rob is satisfied, please re-submit this set with Nicolas' Acks
and I will re-review.

> ChangeLog
> 
> v9:
> - go back to v5 (use the new "atmel,flexcom-mode" DT property).
> - fix the name of the spi node in the DT example: from spi@f8034400 to
>   spi@400
> - align the fields of the struct platform_driver atmel_flexcom_driver as
>   suggested by Lee Jones.
> 
> v8:
> - fix the name of the spi node in the DT example: from spi@f8034400 to
>   spi@2,0
> - use the return code of op_property_read_u32_index() instead of -EINVAL
>   to report error.
> - add Acked-by from Nicolas Ferre
> 
> v7:
> - read the operating mode from the very first u32 of the reg property from
>   the first available child node (should be unique).
> - update the DT bindings documentation accordingly.
> 
> v6:
> - select the operating mode according to the "compatible" DT property of
>   the first available child node (should be unique).
> - remove the "atmel,flexcom-mode" DT property so the need of a header file
>   defining macros for the possible values of this deprecated property.
> 
> v5:
> - create a header file containing macros used by DT bindings
> - use numeric constants instead of strings to select the Flexcom mode
> - change the license to "GPL v2"
> - update the DT binding documentation to make it more readable and add
>   references to USART, SPI and I2C DT binding documentations. remove the
>   useless label in the Example section.
> - change the register prefix from FX_ to FLEX_ to match the Flexcom
>   programmer datasheet.
> - rename some variables to make them more understandable.
> 
> v4:
> - check clk_prepare_enable() return code in atmel_flexcom_probe()
> - add a commit message to the DT binding patch
> 
> v3:
> - remove MODULE_ALIAS()
> - add Acked-by from Boris Brezillon and Alexandre Belloni
> 
> v2:
> - enhance the documentation of DT bindings and change the way the "ranges"
>   property is used.
> - replace __raw_readl() and __raw_writel() by readl() and writel().
> - change the module license to "GPL" for v2 or later
> - print the selected flexcom mode after the hardware version
> 
> v1:
> This series of patches a support to the Atmel Flexcom, a wrapper which
> integrates an USART, a SPI controller and a TWI controller. Only one
> peripheral can be used at a time. The active function is selected though
> the Flexcom Mode Register.
> 
> Cyrille Pitchen (3):
>   mfd: atmel-flexcom: create include file with macros used by DT
> bindings
>   mfd: devicetree: add bindings for Atmel Flexcom
>   mfd: atmel-flexcom: add a driver for Atmel Flexible Serial
> Communication Unit
> 
>  .../devicetree/bindings/mfd/atmel-flexcom.txt  |  67 +
>  drivers/mfd/Kconfig|  11 +++
>  drivers/mfd/Makefile   |   1 +
>  drivers/mfd/atmel-flexcom.c| 104 
> +
>  include/dt-bindings/mfd/atmel-flexcom.h|  16 
>  5 files changed, 199 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>  create mode 100644 drivers/mfd/atmel-flexcom.c
>  create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mfd: Add battery charger as subdevice to the tps65217.

[Lee Jones]

On Tue, 08 Sep 2015, Enric Balletbo i Serra wrote:

> Add tps65217 battery charger subdevice.
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  drivers/mfd/tps65217.c | 4 
>  1 file changed, 4 insertions(+)

Applied, thanks.

> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 55add04..d32b5442 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -39,6 +39,10 @@ static const struct mfd_cell tps65217s[] = {
>   .name = "tps65217-bl",
>   .of_compatible = "ti,tps65217-bl",
>   },
> + {
> + .name = "tps65217-charger",
> + .of_compatible = "ti,tps65217-charger",
> + },
>  };
>  
>  /**

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO regulators

[Lee Jones]

On Wed, 16 Sep 2015, Chen-Yu Tsai wrote:

> The DC1SW and DC5LDO regulators in the AXP221 are internally chained
> to DCDC1 and DCDC5, hence the names. The original bindings used the
> parent regulator names for the supply regulator property. This causes
> some confusion when we actually use it in the dts:
> 
>   axp221 {
>   /* self supplying? */
>   dcdc1-supply = <&dcdc1>;
>   dcdc5-supply = <&dcdc5>;
> 
>   dcdc1: dcdc1 {
>   ...
>   };
> 
>   dcdc5: dcdc5 {
>   ...
>   };
>   };
> 
> Change them to the downstream regulator names, or "dc1sw" and "dc5ldo"
> respectively.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 41811223e5be..8e79252b1e7c 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -60,8 +60,8 @@ DCDC2   : DC-DC buck: vin2-supply
>  DCDC3: DC-DC buck: vin3-supply
>  DCDC4: DC-DC buck: vin4-supply
>  DCDC5: DC-DC buck: vin5-supply
> -DC1SW: On/Off Switch : dcdc1-supply  : DCDC1 
> secondary output
> -DC5LDO   : LDO   : dcdc5-supply  : input from 
> DCDC5
> +DC1SW: On/Off Switch : dc1sw-supply  : DCDC1 
> secondary output
> +DC5LDO   : LDO   : dc5ldo-supply : input from 
> DCDC5
>  ALDO1: LDO   : aldoin-supply : shared supply
>  ALDO2: LDO   : aldoin-supply : shared supply
>  ALDO3: LDO   : aldoin-supply : shared supply

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

[Lee Jones]

On Tue, 15 Sep 2015, Andrew F. Davis wrote:

> The TPS65912 PMIC contains several regulators and a GPIO controller.
> Add bindings for the TPS65912 PMIC.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  .../devicetree/bindings/gpio/gpio-tps65912.txt | 17 +
>  Documentation/devicetree/bindings/mfd/tps65912.txt | 43 
> ++
>  .../bindings/regulator/tps65912-regulator.txt  | 32 
>  3 files changed, 92 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
> new file mode 100644
> index 000..f65370b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
> @@ -0,0 +1,17 @@
> +* TPS65912 GPIO controller bindings

Suggest s/controller/Controller/

> +Required properties:
> + - compatible : Should be "ti,tps65912-gpio".
> + - gpio-controller : Marks the device node as a gpio controller.

s/gpio/GPIO/

As above for controller.

> + - #gpio-cells : Should be two.  The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> +   0 = active high
> +   1 = active low

Best to use the #defines in include/dt-bindings/gpio.

> +Example:
> +
> + gpio4: tps65912_gpio {
> + compatible = "ti,tps65912-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt 
> b/Documentation/devicetree/bindings/mfd/tps65912.txt
> new file mode 100644
> index 000..081af66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
> @@ -0,0 +1,43 @@
> +* TPS65912 Power Management Integrated Circuit bindings
> +
> +Required properties:
> + - compatible : Should be "ti,tps65912".
> + - reg : Slave address or chip select number (I2C / SPI).
> + - interrupt-parent : The parent interrupt controller.
> + - interrupts : The interrupt line the device is connected to.
> + - interrupt-controller : Marks the device node as an interrupt controller.
> + - #interrupt-cells: the number of cells to describe an IRQ, this should be 
> 2.

s/the/The/

> + The first cell is the IRQ number.
> + The second cell is the flags, encoded as the trigger masks from
> + Documentation/devicetree/bindings/interrupts.txt

No such file.

> +Optional nodes:
> + - Regulators: 
> Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> + - GPIO: Documentation/devicetree/bindings/gpio/gpio-tps65912.txt.

Better to use ../gpio, ../regulator, etc.

"Regulators" and "GPIO" aren't valid node names.

Please be more specific.

> +Example:
> +
> + pmic: tps65912@2d {
> + compatible = "ti,tps65912";
> + reg = <0x2d>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + dcdc1: regulator-dcdc1 {
> + compatible = "ti,tps65912-dcdc1";
> + regulator-name = "vdd_core";
> + regulator-min-microvolt = <912000>;
> + regulator-max-microvolt = <1144000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + ...

No need for this.

> + gpio4: tps65912_gpio {
> + compatible = "ti,tps65912-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
> diff --git 
> a/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt 
> b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> new file mode 100644
> index 000..a417ff7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> @@ -0,0 +1,32 @@
> +* TPS65912 regulator bindings
> +
> +Required properties:
> + - compatible: Should be:
> +   - "ti,tps65912-dcdc1" for DCDC1
> +   - "ti,tps65912-dcdc2" for DCDC2
> +   - "ti,tps65912-dcdc3" for DCDC3
> +   - "ti,tps65912-dcdc4" for DCDC4
> +   - "ti,tps65912-ldo1" for LDO1
> +   - "ti,tps65912-ldo2" for LDO2
> +   - "ti,tps65912-ldo3" for LDO3
> +   - "ti,tps65912-ldo4" for LDO4
> +   - "ti,tps65912-ldo5" for LDO5
> +   - "ti,tps65912-ldo6" for LDO6
> +   - "ti,tps65912-ldo7" for LDO7
> +   - "ti,tps65912-ldo8" for LDO8
> +   - "ti,tps65912-ldo9" for LDO9
> +   - "ti,tps65912-ldo10" for LDO10
> +
> +Optional properties:
> + - Any optional property defined in bindings/regulator/regulator.txt

../regulator/...

> +Example:
> +
> + xyz: regulator@0 {
> + compatible = "ti,tps65912-dcdc1";
> + regulator-name =

Re: [PATCH 00/14] ARM: dts: apq8064 dt cleanups and additions

[Andy Gross]

On Fri, Sep 18, 2015 at 01:29:31PM +0100, Srinivas Kandagatla wrote:
> Hi Andy, 
> 
> Here are few cleanup and additions to the existing APQ8064 device tree.
> 
> Some of the patches are to do with princtrl cleanup which was always not
> in the right place and some of the pinctrls were missing.
> Other set of patches is to do with adding more devices like rtc rng
> and pwr key for pmic 8921.
> Last set of patches are related to pwrseq and SD card detect taking Stephens
> comments into consideration.

These all look fine.  I tested in ifc6410 as well.  I'll test on qs600 to be
sure.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP

[Herbert Xu]

On Sat, Sep 19, 2015 at 10:21:45AM +0100, Lee Jones wrote:
>
> That's not how it works.  It's helpful, more often than not, to submit
> the entire set to each maintainer concerned so they can keep up with
> the general conversation.  By only sending specific patches to
> maintainers you essentially blinker them to the bigger picture.
> 
> As a maintainer you should _know_ that you can't apply patches from
> other subsystems without appropriate Acks.  I'm sure you'd take
> exception to another maintainer who started accepting patches for
> subsystems you are responsible for.  This works both ways.

No you are mistaken.  You should only put patches which have
dependencies on each other in a series.  If the patches can be
applied independently of each other there is no need to have
them in a single series.

Obviously if they can go into different trees then they cannot
have dependencies.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] ASoC: da7219: Add bindings documentation for DA7219 audio codec

[Mark Brown]

On Thu, Sep 17, 2015 at 05:01:16PM +0100, Adam Thomson wrote:

> +- dlg,io-lvl : Expected voltage level range for digital IO
> + ["2.5V_3.6V", "1.2V_2.8V"]

If the driver needs to read or set the voltage a supply is at it should
do that via the regulator API.

> +- dlg,cp-mchange : Charge pump voltage tracking mode
> + ["largest_vol", "dac_vol", "sig_mag"]
> +- dlg,cp-vol-thresh : Charge pump volume threshold value (6-bit value)
> + [ 0 - 0x3F ]

Why are these in the device tree rather than runtime parameters?

> +Child node - 'da7219_aad':
> +
> +Required properties:
> +- interrupt-parent : Specifies the phandle of the interrupt controller to 
> which
> +  the IRQs from DA7219 AAD block are delivered to.
> +- interrupts : IRQ line info for DA7219 AAD block.
> +  (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt 
> for
> +   further information relating to interrupt properties)

Why is this not specified at the device level (the device does not
appear to support other interrupts)?


signature.asc
Description: Digital signature

Re: [PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

[Mark Brown]

On Fri, Sep 18, 2015 at 02:06:39PM +0300, Jyri Sarha wrote:
> Add IEC958 channel status helper that gets the audio properties from
> snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
> produce the channel status bits already in audio stream configuration
> phase.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  include/sound/pcm_iec958.h |  2 ++
>  sound/core/pcm_iec958.c| 52 
> +++---

This is core ALSA code, you need to CC Takashi (added him, not cutting
context).

>  2 files changed, 37 insertions(+), 17 deletions(-)
> 
> diff --git a/include/sound/pcm_iec958.h b/include/sound/pcm_iec958.h
> index 0eed397..36f023a 100644
> --- a/include/sound/pcm_iec958.h
> +++ b/include/sound/pcm_iec958.h
> @@ -6,4 +6,6 @@
>  int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
>   size_t len);
>  
> +int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params 
> *params,
> +  u8 *cs, size_t len);
>  #endif
> diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
> index 36b2d7a..c9f8b66 100644
> --- a/sound/core/pcm_iec958.c
> +++ b/sound/core/pcm_iec958.c
> @@ -9,30 +9,18 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> -/**
> - * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
> status
> - * @runtime: pcm runtime structure with ->rate filled in
> - * @cs: channel status buffer, at least four bytes
> - * @len: length of channel status buffer
> - *
> - * Create the consumer format channel status data in @cs of maximum size
> - * @len corresponding to the parameters of the PCM runtime @runtime.
> - *
> - * Drivers may wish to tweak the contents of the buffer after creation.
> - *
> - * Returns: length of buffer, or negative error code if something failed.
> - */
> -int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
> - size_t len)
> +static int create_iec958_consumer(uint rate, uint sample_width,
> +   u8 *cs, size_t len)
>  {
>   unsigned int fs, ws;
>  
>   if (len < 4)
>   return -EINVAL;
>  
> - switch (runtime->rate) {
> + switch (rate) {
>   case 32000:
>   fs = IEC958_AES3_CON_FS_32000;
>   break;
> @@ -59,7 +47,7 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
> *runtime, u8 *cs,
>   }
>  
>   if (len > 4) {
> - switch (snd_pcm_format_width(runtime->format)) {
> + switch (sample_width) {
>   case 16:
>   ws = IEC958_AES4_CON_WORDLEN_20_16;
>   break;
> @@ -92,4 +80,34 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
> *runtime, u8 *cs,
>  
>   return len;
>  }
> +
> +/**
> + * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
> status
> + * @runtime: pcm runtime structure with ->rate filled in
> + * @cs: channel status buffer, at least four bytes
> + * @len: length of channel status buffer
> + *
> + * Create the consumer format channel status data in @cs of maximum size
> + * @len corresponding to the parameters of the PCM runtime @runtime.
> + *
> + * Drivers may wish to tweak the contents of the buffer after creation.
> + *
> + * Returns: length of buffer, or negative error code if something failed.
> + */
> +int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
> + size_t len)
> +{
> + return create_iec958_consumer(runtime->rate,
> +   snd_pcm_format_width(runtime->format),
> +   cs, len);
> +}
>  EXPORT_SYMBOL(snd_pcm_create_iec958_consumer);
> +
> +
> +int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params 
> *params,
> +  u8 *cs, size_t len)
> +{
> + return create_iec958_consumer(params_rate(params), params_width(params),
> +   cs, len);
> +}
> +EXPORT_SYMBOL(snd_pcm_create_iec958_consumer_hw_params);
> -- 
> 1.9.1
> 
> 


signature.asc
Description: Digital signature

Re: [PATCH 1/3] ASoC: codecs: Add da7219 codec driver

[Mark Brown]

On Thu, Sep 17, 2015 at 05:01:14PM +0100, Adam Thomson wrote:

> + do {
> + statusa = snd_soc_read(codec, DA7219_ACCDET_STATUS_A);
> + if (statusa & DA7219_MICBIAS_UP_STS_MASK)
> + micbias_up = true;
> + } while (!micbias_up);

This could go into an inifinite loop.

> +static void da7219_aad_hptest_work(struct work_struct *work)
> +{
> + struct da7219_aad_priv *da7219_aad =
> + container_of(work, struct da7219_aad_priv, hptest_work);
> + struct snd_soc_codec *codec = da7219_aad->codec;
> + struct da7219_priv *da7219 = snd_soc_codec_get_drvdata(codec);
> +
> + u8 tonegen_cfg1, tonegen_cfg2, tonegen_onper;
> + u16 tonegen_freq1, tonegen_freq_hptest;
> + u8 hpl_gain, hpr_gain, dacl_gain, dacr_gain, dac_filters1, dac_filters4;
> + u8 dac_filters5, cp_ctrl, routing_dac, dacl_ctrl, dacr_ctrl;
> + u8 mixoutl_sel, mixoutr_sel, st_outfilt_1l, st_outfilt_1r;
> + u8 mixoutl_ctrl, mixoutr_ctrl, hpl_ctrl, hpr_ctrl, accdet_cfg8;
> + int report = 0;
> +
> + /* Save current settings */

This is obviously a massive reconfiguration of the device.  I'm not
seeing anything here which prevents userspace coming in and change the
configuration while we're in this function, that would obviously have
serious issues.

I'm also wondering if this might be more elegantly implemented by going
into cache bypass mode, doing the test and then using a cache resync to
restore the initial configuration.  That will at least avoid issues with
updates adding a new register but not modifying it.

> + if (statusa & DA7219_JACK_TYPE_STS_MASK) {
> + report |= SND_JACK_HEADSET;
> + mask |= SND_JACK_HEADSET | SND_JACK_LINEOUT;
> + schedule_work(&da7219_aad->btn_det_work);
> + } else {
> + schedule_work(&da7219_aad->hptest_work);
> + }

Why are we scheduling work - we're already in thread context?

> + /* Un-drive headphones/lineout */
> + snd_soc_update_bits(codec, DA7219_HP_R_CTRL,
> + DA7219_HP_R_AMP_OE_MASK, 0);
> + snd_soc_update_bits(codec, DA7219_HP_L_CTRL,
> + DA7219_HP_L_AMP_OE_MASK, 0);

This looks like DAPM?

> +static enum da7219_aad_jack_ins_deb da7219_aad_of_jack_ins_deb(u32 val)
> +{
> + switch (val) {
> + case 5:
> + return DA7219_AAD_JACK_INS_DEB_5MS;
> + case 10:
> + return DA7219_AAD_JACK_INS_DEB_10MS;
> + case 20:
> + return DA7219_AAD_JACK_INS_DEB_20MS;
> + case 50:
> + return DA7219_AAD_JACK_INS_DEB_50MS;
> + case 100:
> + return DA7219_AAD_JACK_INS_DEB_100MS;
> + case 200:
> + return DA7219_AAD_JACK_INS_DEB_200MS;
> + case 500:
> + return DA7219_AAD_JACK_INS_DEB_500MS;
> + case 1000:
> + return DA7219_AAD_JACK_INS_DEB_1S;
> + default:
> + return DA7219_AAD_JACK_INS_DEB_20MS;

This isn't an error?

> +/* Input/Output Enums */
> +static const char * const da7219_gain_ramp_rate_txt[] = {
> + "nominal rate * 8", "nominal rate", "nominal rate / 8",
> + "nominal rate / 16"
> +};

The ALSA ABI generally capitalises words.

> +/* ToneGen */
> +static int da7219_tonegen_freq_get(struct snd_kcontrol *kcontrol,
> +struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
> + struct da7219_priv *da7219 = snd_soc_codec_get_drvdata(codec);
> + struct soc_mixer_control *mixer_ctrl =
> + (struct soc_mixer_control *) kcontrol->private_value;
> + unsigned int reg = mixer_ctrl->reg;
> + u16 val;
> + int ret;
> +
> + ret = regmap_bulk_read(da7219->regmap, reg, &val, sizeof(val));
> + if (ret)
> + return ret;
> +
> + ucontrol->value.integer.value[0] = le16_to_cpu(val);

This is *weird*.  We do a bulk read for a single register using an API
that returns CPU endian data then make it CPU endian (without any
annotations on variables...).  Why not use regmap_read()?  Why swap?
Why not use raw I/O?

> +static int da7219_hpf_put(struct snd_kcontrol *kcontrol,
> +   struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
> + struct soc_enum *enum_ctrl = (struct soc_enum *)kcontrol->private_value;
> + unsigned int reg = enum_ctrl->reg;
> + unsigned int sel = ucontrol->value.integer.value[0];
> + unsigned int bits;
> +
> + switch (sel) {
> + case DA7219_HPF_MODE_DISABLED:
> + bits = DA7219_HPF_DISABLED;
> + break;
> + case DA7219_HPF_MODE_AUDIO:
> + bits = DA7219_HPF_AUDIO_EN;
> + break;
> + case D

Re: [PATCH 02/16] PM / OPP: Add 'opp-microvolt-triplets' binding

[Mark Brown]

On Tue, Sep 15, 2015 at 09:00:27AM +0530, Viresh Kumar wrote:

> [+Cc Mark, I thought I cc'd him earlier, but no, I cc'd him only for
> the first patch]

I'm reading this on a plane so have no other context and to be honest
I'm struggling to understand what is being discussed here.  It would be
really helpful if you were to describe in words what proposed bindings
are intended to do as well as presenting examples, the examples by
themselves require the reader to reverse engineer what the semantics are
intended to be.

> But if we can define something like:

> supply0: regulator@f800 {
> regulator-cells or microvolt-cells = 1 or 3;
> ...
> }

As far as I can tell this is proposing adding something to the regulator
binding specifying if users must present either a single value or a
min/target/max triplet.  This is obviously problematic since regulators
can be shared - the needs of one user may not match the needs of another
user, and of course most users should not be specifying voltages at all
in the device tree in the first place.


signature.asc
Description: Digital signature

Re: [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Mark Brown]

On Fri, Sep 18, 2015 at 02:06:40PM +0300, Jyri Sarha wrote:

> +#define SPDIF_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | 
> SNDRV_PCM_FMTBIT_S16_BE |\
> +  SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> +  SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
> +  SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE)
> +
> +#define I2S_FORMATS  (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\
> +  SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE |\
> +  SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> +  SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
> +  SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\
> +  SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)

I'm not sure how abstracted this I2S and S/PDIF DAI business is - it
doesn't feel like something that's going to be a property of all HDMI
devices, and the specific sets of formats above cause me to raise a bit
of an eyebrow.  Should this be an interface where the HDMI chip
registers multiple interfaces if it has them instead of automatically
getting this split as is?

We can probably skip more specific constraint stuff I guess on the basis
that things tend to support the full range of HDMI functionality, or at
least that can be added later?

Otherwise this looks mostly OK on a first pass, thanks for working on
it.


signature.asc
Description: Digital signature

Re: [PATCH 1/3] mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO regulators

[Mark Brown]

On Wed, Sep 16, 2015 at 11:05:30AM +0800, Chen-Yu Tsai wrote:
> The DC1SW and DC5LDO regulators in the AXP221 are internally chained
> to DCDC1 and DCDC5, hence the names. The original bindings used the
> parent regulator names for the supply regulator property. This causes
> some confusion when we actually use it in the dts:

If these regulators are internally always connected to other regulators
in the same device why are we even representing their supplies in DT?


signature.asc
Description: Digital signature

Re: [PATCH v5 07/23] regulator: core: Remove regulator_list

[Mark Brown]

On Thu, Sep 17, 2015 at 02:57:01PM +0200, Tomeu Vizoso wrote:
> As we are already registering a device with regulator_class for each
> regulator device, regulator_list is redundant and can be replaced with
> calls to class_find_device() and class_for_each_device().

This appears to leak references to the struct devices returned by
class_find_device() - it takes a reference before it returns so any
device found using class_find_device() needs to be released with
put_device() and I don't see any new put_device() calls in here.

> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None

This is not the case at all, this patch was newly added.  If you want
to include changelogs like this in the patch description try to ensure
that they bear some relationship to reality, if they don't they are
actively harmful as they are likely to mislead or annoy the reader.


signature.asc
Description: Digital signature

Re: [PATCH 2/3] mfd: tps65912: Rewrite driver adding DT support and using regmap

[Mark Brown]

On Tue, Sep 15, 2015 at 12:57:40PM -0500, Andrew F. Davis wrote:
> The old driver does not support DT. Rewrite the driver adding DT support
> and use modern kernel features such as regmap and related helpers.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/gpio/gpio-tps65912.c   | 291 ++--
>  drivers/mfd/Kconfig|  20 +-
>  drivers/mfd/Makefile   |   3 +-
>  drivers/mfd/tps65912-core.c| 288 +---
>  drivers/mfd/tps65912-i2c.c | 233 --
>  drivers/mfd/tps65912-irq.c | 217 -
>  drivers/mfd/tps65912-spi.c | 236 --
>  drivers/regulator/tps65912-regulator.c | 783 
> ++---
>  include/linux/mfd/tps65912.h   | 256 +++
>  9 files changed, 854 insertions(+), 1473 deletions(-)

It's not OK to have a single commit that rewrites multiple drivers over
many subsystems, that's really not something that can be sensibly
reviewed.  You should split this into a patch series which makes one
specific change at a time as covered in SubmittingPatches.  That will
allow the changes to be reviewed much more sensibly.


signature.asc
Description: Digital signature

Re: [PATCH RFC] ASoC: simple-card: Update clocks binding for simple-card DAI subnodes

[Mark Brown]

On Fri, Sep 11, 2015 at 04:18:02PM +0300, Jyri Sarha wrote:

> The updated binding provides a way to set clock-ID and direction
> parameters for DAI drivers set_sysclk() call back.

> I proposed something similar about a year ago, but Mark rejected that
> at the time. This RFC is to start that discussion again. This time
> before I do any code changes.

What's the use case again?  Can we address this by converting the
relevant drivers to the clock API (or improving their clock API
support)?


signature.asc
Description: Digital signature

Re: [PATCH 0/7] Phy and mdiobus fixes

[Florian Fainelli]

Le 09/18/15 02:46, Russell King - ARM Linux a écrit :
> Hi,
> 
> While looking at the phy code, I identified a number of weaknesses
> where refcounting on device structures was being leaked, where
> modules could be removed while in-use, and where the fixed-phy could
> end up having unintended consequences caused by incorrect calls to
> fixed_phy_update_state().
> 
> This patch series resolves those issues, some of which were discovered
> with testing on an Armada 388 board.  Not all patches are fully tested,
> particularly the one which touches several network drivers.
> 
> When resolving the struct device refcounting problems, several different
> solutions were considered before settling on the implementation here -
> one of the considerations was to avoid touching many network drivers.
> The solution here is:
> 
>   phy_attach*() - takes a refcount
>   phy_detach*() - drops the phy_attach refcount
> 
> Provided drivers always attach and detach their phys, which they should
> already be doing, this should change nothing, even if they leak a refcount.
> 
>   of_phy_find_device() and of_* functions which use that take
>   a refcount.  Arrange for this refcount to be dropped once
>   the phy is attached.
> 
> This is the reason why the previous change is important - we can't drop
> this refcount taken by of_phy_find_device() until something else holds
> a reference on the device.  This resolves the leaked refcount caused by
> using of_phy_connect() or of_phy_attach().
> 
> Even without the above changes, these drivers are leaking by calling
> of_phy_find_device().  These drivers are addressed by adding the
> appropriate release of that refcount.
> 
> The mdiobus code also suffered from the same kind of leak, but thankfully
> this only happened in one place - the mdio-mux code.
> 
> I also found that the try_module_get() in the phy layer code was utterly
> useless: phydev->dev.driver was guaranteed to always be NULL, so
> try_module_get() was always being called with a NULL argument.  I proved
> this with my SFP code, which declares its own MDIO bus - the module use
> count was never incremented irrespective of how I set the MDIO bus up.
> This allowed the MDIO bus code to be removed from the kernel while there
> were still PHYs attached to it.
> 
> One other bug was discovered: while using in-band-status with mvneta, it
> was found that if a real phy is attached with in-band-status enabled,
> and another ethernet interface is using the fixed-phy infrastructure, the
> interface using the fixed-phy infrastructure is configured according to
> the other interface using the in-band-status - which is caused by the
> fixed-phy code not verifying that the phy_device passed in is actually
> a fixed-phy device, rather than a real MDIO phy.
> 
> Lastly, having mdio_bus reversing phy_device_register() internals seems
> like a layering violation - it's trivial to move that code to the phy
> device layer.

Reviewed-by: Florian Fainelli 

Thanks!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] input: gpio_keys_polled: Add support for abs/rel axis

[Dmitry Torokhov]

On Thu, Sep 17, 2015 at 06:14:40PM -0400, Hans de Goede wrote:
> Add support for EV_ABS / EV_REL events to the gpio-keys-polled driver.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Fix commit message to actually describe what the patch does
>  (fix patch squashing fail)
> ---
>  drivers/input/keyboard/gpio_keys_polled.c | 88 
> +++
>  1 file changed, 79 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/input/keyboard/gpio_keys_polled.c 
> b/drivers/input/keyboard/gpio_keys_polled.c
> index 870cfa6..62bdb1d 100644
> --- a/drivers/input/keyboard/gpio_keys_polled.c
> +++ b/drivers/input/keyboard/gpio_keys_polled.c
> @@ -40,10 +40,36 @@ struct gpio_keys_polled_dev {
>   struct input_polled_dev *poll_dev;
>   struct device *dev;
>   const struct gpio_keys_platform_data *pdata;
> + unsigned long rel_axis_seen[BITS_TO_LONGS(REL_CNT)];
> + unsigned long abs_axis_seen[BITS_TO_LONGS(ABS_CNT)];
>   struct gpio_keys_button_data data[0];
>  };
>  
> -static void gpio_keys_polled_check_state(struct input_dev *input,
> +static void gpio_keys_button_event(struct input_polled_dev *dev,
> +struct gpio_keys_button *button,
> +int state)
> +{
> + struct gpio_keys_polled_dev *bdev = dev->private;
> + struct input_dev *input = dev->input;
> + unsigned int type = button->type ?: EV_KEY;
> +
> + if (type == EV_REL) {
> + if (state) {
> + input_event(input, type, button->code, button->value);
> + __set_bit(button->code, bdev->rel_axis_seen);
> + }
> + } else if (type == EV_ABS) {
> + if (state) {
> + input_event(input, type, button->code, button->value);
> + __set_bit(button->code, bdev->abs_axis_seen);
> + }
> + } else {
> + input_event(input, type, button->code, state);
> + input_sync(input);
> + }
> +}
> +
> +static void gpio_keys_polled_check_state(struct input_polled_dev *dev,
>struct gpio_keys_button *button,
>struct gpio_keys_button_data *bdata)
>  {
> @@ -54,11 +80,9 @@ static void gpio_keys_polled_check_state(struct input_dev 
> *input,
>   else
>   state = !!gpiod_get_value(button->gpiod);
>  
> - if (state != bdata->last_state) {
> - unsigned int type = button->type ?: EV_KEY;
> + gpio_keys_button_event(dev, button, state);
>  
> - input_event(input, type, button->code, state);
> - input_sync(input);
> + if (state != bdata->last_state) {
>   bdata->count = 0;
>   bdata->last_state = state;
>   }
> @@ -71,15 +95,33 @@ static void gpio_keys_polled_poll(struct input_polled_dev 
> *dev)
>   struct input_dev *input = dev->input;
>   int i;
>  
> + memset(bdev->rel_axis_seen, 0, sizeof(bdev->rel_axis_seen));
> + memset(bdev->abs_axis_seen, 0, sizeof(bdev->abs_axis_seen));
> +
>   for (i = 0; i < pdata->nbuttons; i++) {
>   struct gpio_keys_button_data *bdata = &bdev->data[i];
>  
> - if (bdata->count < bdata->threshold)
> + if (bdata->count < bdata->threshold) {
>   bdata->count++;
> - else
> - gpio_keys_polled_check_state(input, &pdata->buttons[i],
> + gpio_keys_button_event(dev, &pdata->buttons[i],
> +bdata->last_state);
> + } else {
> + gpio_keys_polled_check_state(dev, &pdata->buttons[i],
>bdata);
> + }
> + }
> +
> + for_each_set_bit(i, input->relbit, REL_CNT) {
> + if (!test_bit(i, bdev->rel_axis_seen))
> + input_event(input, EV_REL, i, 0);
> + }

I wonder if this should be written as

for_each_set_bit(i, bdev->rel_axis_seen, REL_CNT)
input_event(input, EV_REL, i, 0);

i.e. the 2nd bit test is not really needed because we should not see
unsupported bits in "seen" axes.

> +
> + for_each_set_bit(i, input->absbit, ABS_CNT) {
> + if (!test_bit(i, bdev->abs_axis_seen))
> + input_event(input, EV_ABS, i, 0);
>   }
> +
> + input_sync(input);
>  }
>  
>  static void gpio_keys_polled_open(struct input_polled_dev *dev)
> @@ -152,6 +194,10 @@ static struct gpio_keys_platform_data 
> *gpio_keys_polled_get_devtree_pdata(struct
>&button->type))
>   button->type = EV_KEY;
>  
> + if (fwnode_property_read_u32(child, "linux,input-value",
> +  (u32 *)&button->value))
> + button->value = 1;

Umm, we need negative values too... but there is no
fwnode_pro

Re: [PATCH] Documentation: cypress,cyapa.txt: correct the I2C address of Gen3 touchpads to 0x67

[Dmitry Torokhov]

On Fri, Sep 18, 2015 at 10:37:44AM +0800, Dudley Du wrote:
> All of the Gen3 touchpads are fixed with I2C address 0x67, so correct the
> reg value description from 0x24 to 0x67.
> 
> Signed-off-by: Dudley Du 

Applied, thank you.

> ---
>  Documentation/devicetree/bindings/input/cypress,cyapa.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.txt 
> b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> index 635a3b0..8d91ba9 100644
> --- a/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> +++ b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> @@ -25,7 +25,7 @@ Example:
>   /* Cypress Gen3 touchpad */
>   touchpad@67 {
>   compatible = "cypress,cyapa";
> - reg = <0x24>;
> + reg = <0x67>;
>   interrupt-parent = <&gpio>;
>   interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
>   wakeup-source;
> -- 
> 1.9.1
> 
> 
> ---
> This message and any attachments may contain Cypress (or its
> subsidiaries) confidential information. If it has been received
> in error, please advise the sender and immediately delete this
> message.
> ---
> 

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] arm64: dts: berlin4ct: add the pinctrl node and muxing setup for uart0

[Jisheng Zhang]

Add the avio, soc, sm pinctrl nodes for Marvell berlin4ct SoC. This
patch also adds urt0 txd and rxd muxing setup in the dtsi because uart0
always use them to work, no other possibilities.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
index a3b5f1d..4566e4e 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
@@ -225,6 +225,16 @@
};
};
 
+   soc_pinctrl: pinctrl@ea8000 {
+   compatible = "marvell,berlin4ct-soc-pinctrl";
+   reg = <0xea8000 0x14>;
+   };
+
+   avio_pinctrl: pinctrl@ea8400 {
+   compatible = "marvell,berlin4ct-avio-pinctrl";
+   reg = <0xea8400 8>;
+   };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -278,6 +288,23 @@
clocks = <&osc>;
reg-shift = <2>;
status = "disabled";
+   pinctrl-0 = <&urt0_txd_pmux>, <&urt0_rxd_pmux>;
+   pinctrl-names = "default", "default";
+   };
+   };
+
+   sm_pinctrl: pinctrl@fe2200 {
+   compatible = "marvell,berlin4ct-sm-pinctrl";
+   reg = <0xfe2200 0xc>;
+
+   urt0_txd_pmux: urt0_txd-pmux {
+   groups = "SM_URT0_TXD";
+   function = "sm_urt0_txd";
+   };
+
+   urt0_rxd_pmux: urt0_rxd-pmux {
+   groups = "SM_URT0_RXD";
+   function = "sm_urt0_rxd";
};
};
};
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs

[Jisheng Zhang]

This is to add the pinctrl dependency for Marvell Berlin SoCs.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index c6e2c75..3d17ee2 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -9,6 +9,7 @@ config ARCH_BERLIN
bool "Marvell Berlin SoC Family"
select ARCH_REQUIRE_GPIOLIB
select DW_APB_ICTL
+   select PINCTRL
help
  This enables support for Marvell Berlin SoC Family
 
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] pinctrl: berlin: regmap as an extra argument of berlin_pinctrl_probe()

[Jisheng Zhang]

Let berlin_pinctrl_probe() accepts an extra argument: regmap, this is to
prepare for the next berlin4ct support, where we won't use simple-mfd
any more.

Signed-off-by: Jisheng Zhang 
---
 drivers/pinctrl/berlin/berlin-bg2.c   | 9 -
 drivers/pinctrl/berlin/berlin-bg2cd.c | 9 -
 drivers/pinctrl/berlin/berlin-bg2q.c  | 9 -
 drivers/pinctrl/berlin/berlin.c   | 8 +---
 drivers/pinctrl/berlin/berlin.h   | 1 +
 5 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/berlin/berlin-bg2.c 
b/drivers/pinctrl/berlin/berlin-bg2.c
index 274c553..b2be9be 100644
--- a/drivers/pinctrl/berlin/berlin-bg2.c
+++ b/drivers/pinctrl/berlin/berlin-bg2.c
@@ -233,8 +233,15 @@ static int berlin2_pinctrl_probe(struct platform_device 
*pdev)
 {
const struct of_device_id *match =
of_match_device(berlin2_pinctrl_match, &pdev->dev);
+   struct device *dev = &pdev->dev;
+   struct device_node *parent_np = of_get_parent(dev->of_node);
+   struct regmap *regmap = syscon_node_to_regmap(parent_np);
 
-   return berlin_pinctrl_probe(pdev, match->data);
+   of_node_put(parent_np);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   return berlin_pinctrl_probe(pdev, regmap, match->data);
 }
 
 static struct platform_driver berlin2_pinctrl_driver = {
diff --git a/drivers/pinctrl/berlin/berlin-bg2cd.c 
b/drivers/pinctrl/berlin/berlin-bg2cd.c
index 0cb793a..f88a6e5 100644
--- a/drivers/pinctrl/berlin/berlin-bg2cd.c
+++ b/drivers/pinctrl/berlin/berlin-bg2cd.c
@@ -176,8 +176,15 @@ static int berlin2cd_pinctrl_probe(struct platform_device 
*pdev)
 {
const struct of_device_id *match =
of_match_device(berlin2cd_pinctrl_match, &pdev->dev);
+   struct device *dev = &pdev->dev;
+   struct device_node *parent_np = of_get_parent(dev->of_node);
+   struct regmap *regmap = syscon_node_to_regmap(parent_np);
 
-   return berlin_pinctrl_probe(pdev, match->data);
+   of_node_put(parent_np);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   return berlin_pinctrl_probe(pdev, regmap, match->data);
 }
 
 static struct platform_driver berlin2cd_pinctrl_driver = {
diff --git a/drivers/pinctrl/berlin/berlin-bg2q.c 
b/drivers/pinctrl/berlin/berlin-bg2q.c
index a466054..c0bc0ec 100644
--- a/drivers/pinctrl/berlin/berlin-bg2q.c
+++ b/drivers/pinctrl/berlin/berlin-bg2q.c
@@ -395,8 +395,15 @@ static int berlin2q_pinctrl_probe(struct platform_device 
*pdev)
 {
const struct of_device_id *match =
of_match_device(berlin2q_pinctrl_match, &pdev->dev);
+   struct device *dev = &pdev->dev;
+   struct device_node *parent_np = of_get_parent(dev->of_node);
+   struct regmap *regmap = syscon_node_to_regmap(parent_np);
 
-   return berlin_pinctrl_probe(pdev, match->data);
+   of_node_put(parent_np);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   return berlin_pinctrl_probe(pdev, regmap, match->data);
 }
 
 static struct platform_driver berlin2q_pinctrl_driver = {
diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
index f495806..6d593b5 100644
--- a/drivers/pinctrl/berlin/berlin.c
+++ b/drivers/pinctrl/berlin/berlin.c
@@ -293,19 +293,13 @@ static struct pinctrl_desc berlin_pctrl_desc = {
 };
 
 int berlin_pinctrl_probe(struct platform_device *pdev,
+struct regmap *regmap,
 const struct berlin_pinctrl_desc *desc)
 {
struct device *dev = &pdev->dev;
-   struct device_node *parent_np = of_get_parent(dev->of_node);
struct berlin_pinctrl *pctrl;
-   struct regmap *regmap;
int ret;
 
-   regmap = syscon_node_to_regmap(parent_np);
-   of_node_put(parent_np);
-   if (IS_ERR(regmap))
-   return PTR_ERR(regmap);
-
pctrl = devm_kzalloc(dev, sizeof(*pctrl), GFP_KERNEL);
if (!pctrl)
return -ENOMEM;
diff --git a/drivers/pinctrl/berlin/berlin.h b/drivers/pinctrl/berlin/berlin.h
index e1aa841..bf5781a 100644
--- a/drivers/pinctrl/berlin/berlin.h
+++ b/drivers/pinctrl/berlin/berlin.h
@@ -56,6 +56,7 @@ struct berlin_pinctrl_function {
 #define BERLIN_PINCTRL_FUNCTION_UNKNOWN{}
 
 int berlin_pinctrl_probe(struct platform_device *pdev,
+struct regmap *regmap,
 const struct berlin_pinctrl_desc *desc);
 
 #endif /* __PINCTRL_BERLIN_H */
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] pinctrl: berlin: add the berlin4ct pinctrl driver

[Jisheng Zhang]

Add the pin-controller driver for Marvell Berlin BG4CT SoC, with definition
of its groups and functions. This uses the core Berlin pinctrl driver.

Signed-off-by: Jisheng Zhang 
---
 drivers/pinctrl/berlin/Kconfig |   5 +
 drivers/pinctrl/berlin/Makefile|   1 +
 drivers/pinctrl/berlin/berlin4ct.c | 503 +
 3 files changed, 509 insertions(+)
 create mode 100644 drivers/pinctrl/berlin/berlin4ct.c

diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index b18322b..eac4d28 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -17,4 +17,9 @@ config PINCTRL_BERLIN_BG2Q
bool
select PINCTRL_BERLIN
 
+config PINCTRL_BERLIN4CT
+   depends on OF && (ARCH_BERLIN || COMPILE_TEST)
+   bool "Marvell berlin4ct pin controller driver"
+   select PINCTRL_BERLIN
+
 endif
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
index deb0c6b..c8fe2a0 100644
--- a/drivers/pinctrl/berlin/Makefile
+++ b/drivers/pinctrl/berlin/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_PINCTRL_BERLIN)+= berlin.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2)   += berlin-bg2.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2CD) += berlin-bg2cd.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2Q)  += berlin-bg2q.o
+obj-$(CONFIG_PINCTRL_BERLIN4CT)+= berlin4ct.o
diff --git a/drivers/pinctrl/berlin/berlin4ct.c 
b/drivers/pinctrl/berlin/berlin4ct.c
new file mode 100644
index 000..2960e16
--- /dev/null
+++ b/drivers/pinctrl/berlin/berlin4ct.c
@@ -0,0 +1,503 @@
+/*
+ * Marvell berlin4ct pinctrl driver
+ *
+ * Copyright (C) 2015 Marvell Technology Group Ltd.
+ *
+ * Jisheng Zhang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "berlin.h"
+
+static const struct berlin_desc_group berlin4ct_soc_pinctrl_groups[] = {
+   BERLIN_PINCTRL_GROUP("EMMC_RSTn", 0x0, 0x3, 0x00,
+   BERLIN_PINCTRL_FUNCTION(0x0, "emmc_rstn"),
+   BERLIN_PINCTRL_FUNCTION(0x1, "gpio47")),
+   BERLIN_PINCTRL_GROUP("NAND_IO0", 0x0, 0x3, 0x03,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io0"),
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_rxd0"),
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_clk"),
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio0")),
+   BERLIN_PINCTRL_GROUP("NAND_IO1", 0x0, 0x3, 0x06,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io1"),
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_rxd1"),
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_cdn"),
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio1")),
+   BERLIN_PINCTRL_GROUP("NAND_IO2", 0x0, 0x3, 0x09,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io2"),
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_rxd2"),
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_dat0"),
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio2")),
+   BERLIN_PINCTRL_GROUP("NAND_IO3", 0x0, 0x3, 0x0c,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io3"),
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_rxd3"),
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_dat1"),
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio3")),
+   BERLIN_PINCTRL_GROUP("NAND_IO4", 0x0, 0x3, 0x0f,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io4"),
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_rxc"),
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_dat2"),
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio4")),
+   BERLIN_PINCTRL_GROUP("NAND_IO5", 0x0, 0x3, 0x12,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io5"),
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_rxctl"),
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_dat3"),
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio5")),
+   BERLIN_PINCTRL_GROUP("NAND_IO6", 0x0, 0x3, 0x15,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io6"),
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_mdc"),
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_cmd"),
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio6")),
+   BERLIN_PINCTRL_GROUP("NAND_IO7", 0x0, 0x3, 0x18,
+   BERLIN_PINCTRL_FUNCTION(0x0,

[PATCH 0/5] arm64: berlin: add pinctrl support

[Jisheng Zhang]

This series adds support for Marvell berlin4ct pin-controller, allowing
to configure the pin muxing from the device tree.

This series applies on top of patches adding GPIO support for berlin4ct[1].

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371106.html

Jisheng Zhang (5):
  pinctrl: berlin: regmap as an extra argument of berlin_pinctrl_probe()
  pinctrl: berlin: add the berlin4ct pinctrl driver
  arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs
  pinctrl: dt-binding: document berlin4ct SoC
  arm64: dts: berlin4ct: add the pinctrl node and muxing setup for uart0

 .../devicetree/bindings/pinctrl/berlin,pinctrl.txt |   5 +-
 arch/arm64/Kconfig.platforms   |   1 +
 arch/arm64/boot/dts/marvell/berlin4ct.dtsi |  27 ++
 drivers/pinctrl/berlin/Kconfig |   5 +
 drivers/pinctrl/berlin/Makefile|   1 +
 drivers/pinctrl/berlin/berlin-bg2.c|   9 +-
 drivers/pinctrl/berlin/berlin-bg2cd.c  |   9 +-
 drivers/pinctrl/berlin/berlin-bg2q.c   |   9 +-
 drivers/pinctrl/berlin/berlin.c|   8 +-
 drivers/pinctrl/berlin/berlin.h|   1 +
 drivers/pinctrl/berlin/berlin4ct.c | 503 +
 11 files changed, 567 insertions(+), 11 deletions(-)
 create mode 100644 drivers/pinctrl/berlin/berlin4ct.c

-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] pinctrl: dt-binding: document berlin4ct SoC

[Jisheng Zhang]

Add berlin4ct to existing berlin pinctrl device tree binding.

Signed-off-by: Jisheng Zhang 
---
 Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
index a8bb5e2..0580860 100644
--- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
@@ -20,7 +20,10 @@ Required properties:
"marvell,berlin2cd-soc-pinctrl",
"marvell,berlin2cd-system-pinctrl",
"marvell,berlin2q-soc-pinctrl",
-   "marvell,berlin2q-system-pinctrl"
+   "marvell,berlin2q-system-pinctrl",
+   "marvell,berlin4ct-avio-pinctrl",
+   "marvell,berlin4ct-sm-pinctrl",
+   "marvell,berlin4ct-soc-pinctrl"
 
 Required subnode-properties:
 - groups: a list of strings describing the group names.
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP

[Lee Jones]

On Sat, 19 Sep 2015, Herbert Xu wrote:
> On Fri, Sep 18, 2015 at 04:51:12PM +0100, Lee Jones wrote:
> >
> > I think it's okay for you to take all but patch 6.
> > 
> > Patch 6 is an ARM patch and needs to go into ARM SoC via
> > STMicroelectronics STi tree.
> 
> In future please don't send me patches that you don't want me to
> merge in the series.

That's not how it works.  It's helpful, more often than not, to submit
the entire set to each maintainer concerned so they can keep up with
the general conversation.  By only sending specific patches to
maintainers you essentially blinker them to the bigger picture.

As a maintainer you should _know_ that you can't apply patches from
other subsystems without appropriate Acks.  I'm sure you'd take
exception to another maintainer who started accepting patches for
subsystems you are responsible for.  This works both ways.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html