Re: [PATCHv2 1/2] iio: adc: Add TI ADS868X

[Peter Meerwald]

> This patch adds support for the Texas Intruments ADS868x ADC.

looks good, some minor comments below
maybe add link to datasheet
 
> Signed-off-by: Sean Nyekjaer 
> Reviewed-by: Martin Hundebøll 
> ---
> Changes since v1:
> - Now possible to read and write the actual offset and scale values
> - Removed unused includes
> - Removed unused buffer references
> 
>  drivers/iio/adc/Kconfig  |  10 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads868x.c | 456 
> +++
>  3 files changed, 467 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads868x.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index deea62c..39924d5 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -322,6 +322,16 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS868X
> + tristate "Texas Instruments ADS8684/8"
> + depends on SPI && OF
> + help
> +   If you say yes here you get support for Texas Instruments ADS8684 and
> +   and ADS8688 ADC chips
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads868x.
> +
>  config TI_AM335X_ADC
>   tristate "TI's AM335X ADC driver"
>   depends on MFD_TI_AM335X_TSCADC
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fa5723a..75170d2 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> +obj-$(CONFIG_TI_ADS868X) += ti-ads868x.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>  obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> diff --git a/drivers/iio/adc/ti-ads868x.c b/drivers/iio/adc/ti-ads868x.c
> new file mode 100644
> index 000..66d9b64
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads868x.c
> @@ -0,0 +1,456 @@
> +/*
> + * Copyright (C) 2015 Prevas A/S
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define ADS868X_CMD_REG(x)   (x << 8)
> +#define ADS868X_CMD_REG_NOOP 0x00
> +#define ADS868X_CMD_REG_RST  0x85
> +#define ADS868X_CMD_REG_MAN_CH(chan) (0xC0 | (4 * chan))
> +#define ADS868X_CMD_DONT_CARE_BITS   16
> +
> +#define ADS868X_PROG_REG(x)  (x << 9)
> +#define ADS868X_PROG_REG_RANGE_CH(chan)  (0x05 + chan)
> +#define ADS868X_PROG_WR_BIT  BIT(8)
> +#define ADS868X_PROG_DONT_CARE_BITS  8
> +
> +#define ADS868X_VREF_MV  4096
> +#define ADS868X_REALBITS 16
> +
> +struct ads868x_chip_info {
> + unsigned int id;
> + const struct iio_chan_spec *channels;
> + unsigned int num_channels;
> + unsigned int flags;
> + const struct iio_info *iio_info;
> +};
> +
> +struct ads868x_state {
> + const struct ads868x_chip_info  *chip_info;
> + struct spi_device   *spi;
> + struct regulator*reg;
> + unsigned intvref_mv;
> + charrange[8];
> + union {
> + __be32 d32;
> + u8 d8[4];
> + } data[2] cacheline_aligned;
> +};
> +
> +enum ads868x_id {
> + ID_ADS8684,
> + ID_ADS8688,
> +};
> +
> +enum ads868x_range {
> + ADS868X_PLUSMINUS25VREF = 0x00,
> + ADS868X_PLUSMINUS125VREF= 0x01,
> + ADS868X_PLUSMINUS0625VREF   = 0x02,
> + ADS868X_PLUS25VREF  = 0x05,
> + ADS868X_PLUS125VREF = 0x06,
> +};
> +
> +struct ads868x_ranges {
> + enum ads868x_range range;
> + unsigned int scale;
> + int offset;
> +};
> +
> +static struct ads868x_ranges ads868x_range_def[5] = {

can be const?

> + {
> + .range = ADS868X_PLUSMINUS25VREF,
> + .scale = 76295,
> + .offset = -(1 << (ADS868X_REALBITS - 1)),
> + }, {
> + .range = ADS868X_PLUSMINUS125VREF,
> + .scale = 38148,
> + .offset = -(1 << (ADS868X_REALBITS - 1)),
> + }, {
> + .range = ADS868X_PLUSMINUS0625VREF,
> + .scale = 19074,
> + .offset = -(1 << (ADS868X_REALBITS - 1)),
> + }, {
> + .range = ADS868X_PLUS25VREF,
> + .scale = 38148,
> + .offset = 0,
> + }, {
> + .range = ADS868X_PLUS125VREF,
> + .scale = 19074,
> + .offset = 0,
> + }
> +};
> +
> +static ssize_t ads868x_sho

Re: [linux-sunxi][PATCH v3] ARM: sun7i: dt: Add new Olimex A20 EVB device

[Maxime Ripard]

On Wed, Sep 23, 2015 at 08:47:50PM +0200, codekip...@gmail.com wrote:
> From: Marcus Cooper 
> 
> The A20-SOM-EVB is a reference design of a 2-layer board for the
> A20-SOM.
> It expands the features of A20-SOM by adding VGA connector, HDMI
> connector, audio In/Out, LCD connector, 2 Mpix camera, gigabit
> Ethernet, SATA, USB-OTG and 2 USB hosts.
> 
> Signed-off-by: Marcus Cooper 
> ---
> Changes since v2:
> - changed dcdc2 to have max voltage of 1.4V
> Changes since v1:
> - renamed dts from sun7i-a20-olinuxino-evb to sun7i-a20-olimex-som-evb
> - added "axp209 dtsi"
> - change regulator settings
> ---
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 216 
> +
>  2 files changed, 217 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 359dcb5..8419a3e 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -617,6 +617,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>   sun7i-a20-i12-tvbox.dtb \
>   sun7i-a20-m3.dtb \
>   sun7i-a20-mk808c.dtb \
> + sun7i-a20-olimex-som-evb.dtb \
>   sun7i-a20-olinuxino-lime.dtb \
>   sun7i-a20-olinuxino-lime2.dtb \
>   sun7i-a20-olinuxino-micro.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts 
> b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> new file mode 100644
> index 000..41b4b4a
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> @@ -0,0 +1,216 @@
> +/*
> + * Copyright 2015 - Marcus Cooper 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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 file is distributed in the hope that 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Olimex A20-Olimex-SOM-EVB";
> + compatible = "olimex,a20-olimex-som-evb", "allwinner,sun7i-a20";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&led_pins_olimex_som_evb>;
> +
> + green {
> + label = "a20-olimex-som-evb:green:usr";
> + gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> + };
> +
> + reg_axp_ipsout: axp_ipsout {
> + compatible = "regulator-fixed";
> + regulator-name = "axp-ipsout";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };

Are you using that regulator somewhere?

> +};
> +
> +&ahci {
> + target-supply = <®_ahci_5v>;
> + status = "okay";
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
>

Re: [PATCH] gpio:pca953x: add mechanism to simulate open drain outputs

[H. Nikolaus Schaller]

Am 25.09.2015 um 00:11 schrieb Linus Walleij :

> On Wed, Sep 23, 2015 at 11:13 AM, H. Nikolaus Schaller
>  wrote:
> 
>> 1. add a DT property to specify the list of GPIO pins that are to become
>>   "open drain"
>> 2. if a pin is configured as "open drain", set value by either outputting a
>>   "0" (low level) or switching to input (high impedance)
>> 
>> Tested on OMAP5 uEVM with TCA6424 and some LEDs connected to 5V.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
> 
> I understand the approach, but this is the wrong way to do it.
> Instead of indicating that a pin on the pin controller should be
> open drain, the *consumer* specifying its gpios = <> should
> do this.

On a second thought I am no longer sure if that is the right approach.

A gpio is for input and output of “0” and “1” values. And a gpio consumer
can control if the output should be active or inactive and input.

How the output is physically represented (totem-pole or single-ended,
high power, low power etc.) is not a property of the gpio itself and
there is IMHO no need for the consumer to be able to define (or change)
it.

On SoC with integrated gpio controllers it is very common to have
pinmux definitions completely separated from the gpio controller
properties. But the gpio consumer can connect to pinctrl settings
to describe that the pin should have certain physical properties.

There, it is common to be able to enable/disable pull-up/downs as
well.

So turning a totem-pole output (as it is available in the tca6424)
into an open-drain output is sort of turning off the pull-up transistor.
I.e. comparable to a pinmux setting.

So such controllers should get the option to define pinctrl.

Some chips might have special control registers for doing that
while others need the trick to switch between input and output
mode but that is driver implementation detail.

But I am not sure if this has other implications.

> 
> I just sent a patch adding the bindings because Tony Lindgren
> and Grygorii Strashko approached me similar problems so let's
> begin with the bindings.
> 
> Implementing it in the kernel requires some elaboration and it's
> going to be more complicated than this local approach, but it
> will be more generic and reusable so that is what we need to do.
> 
> Yours,
> Linus Walleij

BR,
Nikolaus Schaller--
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] Revert "ARM: dts: sun8i: Add new sun8i-a33-q8-tzx-723q4.dts file"

[Maxime Ripard]

On Thu, Sep 24, 2015 at 05:23:52PM +0200, Hans de Goede wrote:
> The tzx-723q[a]4 board variant of A33 based Q8 formfactor tablets was
> given its own dts file because the mmc would not work with a drive
> strength of 30mA, Android seemed to be using a lower drive-strength
> and doing the same with the upstream kernel seemed to fix this issue.
> 
> While working on a similar fix for u-boot I noticed that Android did
> not use a lower drive strength for mmc0, but for mmc1, so mmc0 should
> work fine with a drive strength of 30mA.
> 
> Further investigation has shown that Allwinner is using slightly
> tweaked clock sample phase settings in newer Android kernels, and
> that updating the mainstream sunxi mmc driver to these settings fixes
> this.
> 
> With this fixed we no longer need a dts file specifically for these
> pcb varants -> drop this dts file.

I dropped the patch.

> This reverts commit fb61c559a810f1487892b83d2d0606af1d020318.

Checkpatch prints an error about this one. Make sure you have the
right commit format.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[PATCH v2] net: Fix Hisilicon Network Subsystem Support Compilation

[huangdaode]

This patch fixes the compilation error with arm allmodconfig, this error
generated due to unavailability of readq() on 32-bit platform which was
found during net-next daily compilation. In the same time, fix all the
hns drivers compilation warnings.

Signed-off-by: huangdaode 
Signed-off-by: zhaungyuzeng 
Signed-off-by: kenneth Lee 
Signed-off-by: yankejian 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c  |  2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |  4 ++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c  | 10 --
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  | 10 +-
 drivers/net/ethernet/hisilicon/hns/hns_enet.c  | 17 -
 5 files changed, 20 insertions(+), 23 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a8bd27b..95bf42a 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -86,7 +86,7 @@ int hns_mac_get_sfp_prsnt(struct hns_mac_cb *mac_cb, int 
*sfp_prsnt)
if (!mac_cb->cpld_vaddr)
return -ENODEV;
 
-   *sfp_prsnt = !dsaf_read_b((u64)mac_cb->cpld_vaddr
+   *sfp_prsnt = !dsaf_read_b((u8 *)mac_cb->cpld_vaddr
+ MAC_SFP_PORT_OFFSET);
 
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index e0417c0..315b07e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -43,7 +43,7 @@ struct hns_mac_cb;
 #define DSAF_DUMP_REGS_NUM 504
 #define DSAF_STATIC_NUM 28
 
-#define DSAF_STATS_READ(p, offset) (*((u64 *)((u64)(p) + (offset
+#define DSAF_STATS_READ(p, offset) (*((u64 *)((u8 *)(p) + (offset
 
 enum hal_dsaf_mode {
HRD_DSAF_NO_DSAF_MODE   = 0x0,
@@ -302,7 +302,7 @@ struct dsaf_device {
 
 static inline void *hns_dsaf_dev_priv(const struct dsaf_device *dsaf_dev)
 {
-   return (void *)((u64)dsaf_dev + sizeof(*dsaf_dev));
+   return (void *)((u8 *)dsaf_dev + sizeof(*dsaf_dev));
 }
 
 struct dsaf_drv_tbl_tcam_key {
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 50f3427..1e10f65 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -191,9 +191,12 @@ static void hns_rcb_ring_init(struct ring_pair_cb 
*ring_pair, int ring_type)
if (ring_type == RX_RING) {
dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_L_REG,
   (u32)dma);
+#ifdef CONFIG_64BIT
dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG,
   (u32)(dma >> 32));
-
+#else
+   dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG, 0);
+#endif
dsaf_write_dev(q, RCB_RING_RX_RING_BD_LEN_REG,
   bd_size_type);
dsaf_write_dev(q, RCB_RING_RX_RING_BD_NUM_REG,
@@ -203,9 +206,12 @@ static void hns_rcb_ring_init(struct ring_pair_cb 
*ring_pair, int ring_type)
} else {
dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_L_REG,
   (u32)dma);
+#ifdef CONFIG_64BIT
dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_H_REG,
   (u32)(dma >> 32));
-
+#else
+   dsaf_write_dev(q, RCB_RING_TX_RING_BASEADDR_H_REG, 0);
+#endif
dsaf_write_dev(q, RCB_RING_TX_RING_BD_LEN_REG,
   bd_size_type);
dsaf_write_dev(q, RCB_RING_TX_RING_BD_NUM_REG,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 6fc58ba..8dcaf5f 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -966,7 +966,15 @@ static inline u32 dsaf_get_reg_field(void *base, u32 reg, 
u32 mask, u32 shift)
 #define dsaf_read_b(addr)\
readb((__iomem unsigned char *)(addr))
 
+#ifndef readq
+static inline u64 readq(void __iomem *reg)
+{
+   return (((u64)readl(reg + 0x4UL) << 32) |
+   (u64)readl(reg));
+}
+#endif
+
 #define hns_mac_reg_read64(drv, offset) \
-   readq((__iomem void *)(((u64)(drv)->io_base + 0xc00 + (offset
+   readq((__iomem void *)(((u8 *)(drv)->io_base + 0xc00 + (offset
 
 #endif /* _DSAF_REG_H */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 0713ced..ce7f2e0 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -31,8 +31,6 @@
 #define NIC_TX_CLEAN_MAX_NUM 256
 #define NIC_RX_CLEAN_MAX_NUM 64
 
-#define RCB_ERR_PRINT_CYCLE 1000
-
 #define RCB_IRQ_NOT_INITED 0
 #define RCB_IRQ_INITED 1
 
@@ -434,21 +432,12 @@ out_bnu

[PATCH] soc: mediatek: Fix random hang up issue while kernel init

[James Liao]

In kernel late init, it turns off all unused clocks, which
needs to access subsystem registers such as VENC and VENC_LT.

Accessing MT8173 VENC registers needs two top clocks, mm_sel and
venc_sel. Accessing VENC_LT registers needs mm_sel and venclt_sel.
So we need to keep these clocks on before accessing their registers.

This patch keeps venc_sel / venclt_sel clock on when
VENC / VENC_LT's power is on, to prevent system hang up while
accessing its registeres.

Signed-off-by: James Liao 
---

This patch is based on v4.3-rc2, to fix system hanging up issue
while disabling unused clocks.

 arch/arm64/boot/dts/mediatek/mt8173.dtsi |  6 ++-
 drivers/soc/mediatek/mtk-scpsys.c| 67 +---
 2 files changed, 48 insertions(+), 25 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..188917f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -227,8 +227,10 @@
#power-domain-cells = <1>;
reg = <0 0x10006000 0 0x1000>;
clocks = <&clk26m>,
-<&topckgen CLK_TOP_MM_SEL>;
-   clock-names = "mfg", "mm";
+<&topckgen CLK_TOP_MM_SEL>,
+<&topckgen CLK_TOP_VENC_SEL>,
+<&topckgen CLK_TOP_VENC_LT_SEL>;
+   clock-names = "mfg", "mm", "venc", "venc_lt";
infracfg = <&infracfg>;
};
 
diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 164a7d8..06032ba 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -54,12 +54,16 @@
 #define PWR_STATUS_USB BIT(25)
 
 enum clk_id {
+   MT8173_CLK_NONE,
MT8173_CLK_MM,
MT8173_CLK_MFG,
-   MT8173_CLK_NONE,
-   MT8173_CLK_MAX = MT8173_CLK_NONE,
+   MT8173_CLK_VENC,
+   MT8173_CLK_VENC_LT,
+   MT8173_CLK_MAX,
 };
 
+#define MAX_CLKS   2
+
 struct scp_domain_data {
const char *name;
u32 sta_mask;
@@ -67,7 +71,7 @@ struct scp_domain_data {
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
u32 bus_prot_mask;
-   enum clk_id clk_id;
+   enum clk_id clk_id[MAX_CLKS];
 };
 
 static const struct scp_domain_data scp_domain_data[] __initconst = {
@@ -77,7 +81,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_VDE_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM},
},
[MT8173_POWER_DOMAIN_VENC] = {
.name = "venc",
@@ -85,7 +89,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_VEN_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
},
[MT8173_POWER_DOMAIN_ISP] = {
.name = "isp",
@@ -93,7 +97,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_ISP_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM},
},
[MT8173_POWER_DOMAIN_MM] = {
.name = "mm",
@@ -101,7 +105,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM},
.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
MT8173_TOP_AXI_PROT_EN_MM_M1,
},
@@ -111,7 +115,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_VEN2_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC_LT},
},
[MT8173_POWER_DOMAIN_AUDIO] = {
.name = "audio",
@@ -119,7 +123,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_AUDIO_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = MT8173_CLK_NONE,
+   .clk_id = {MT8173_CLK_NONE},
},
[MT8173_POWER_DOMAIN_USB] = {
.name = "usb",
@@ -

[PATCHv2 2/2] iio: ti-ads868x: Add DT binding documentation

[Sean Nyekjaer]

Adding binding documentation for Texas Instruments ADS868X ADC.

Signed-off-by: Sean Nyekjaer 
Reviewed-by: Martin Hundebøll 
---
 .../devicetree/bindings/iio/adc/ti-ads868x.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-ads868x.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/ti-ads868x.txt 
b/Documentation/devicetree/bindings/iio/adc/ti-ads868x.txt
new file mode 100644
index 000..bc3c305
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti-ads868x.txt
@@ -0,0 +1,18 @@
+* Texas Instruments' ADS8684 and ADS8688 ADC chip
+
+Required properties:
+ - compatible: Should be "ti,ads8684" or "ti,ads8688"
+ - reg: spi chip select number for the device
+ - vref-supply: The regulator supply for ADC reference voltage
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+adc@0 {
+   compatible = "ti,ads8688";
+   reg = <0>;
+   vref-supply = <&vdd_supply>;
+   spi-max-frequency = <100>;
+};
-- 
2.5.3

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

[PATCHv2 1/2] iio: adc: Add TI ADS868X

[Sean Nyekjaer]

This patch adds support for the Texas Intruments ADS868x ADC.

Signed-off-by: Sean Nyekjaer 
Reviewed-by: Martin Hundebøll 
---
Changes since v1:
- Now possible to read and write the actual offset and scale values
- Removed unused includes
- Removed unused buffer references

 drivers/iio/adc/Kconfig  |  10 +
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/ti-ads868x.c | 456 +++
 3 files changed, 467 insertions(+)
 create mode 100644 drivers/iio/adc/ti-ads868x.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index deea62c..39924d5 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -322,6 +322,16 @@ config TI_ADC128S052
  This driver can also be built as a module. If so, the module will be
  called ti-adc128s052.
 
+config TI_ADS868X
+   tristate "Texas Instruments ADS8684/8"
+   depends on SPI && OF
+   help
+ If you say yes here you get support for Texas Instruments ADS8684 and
+ and ADS8688 ADC chips
+
+ This driver can also be built as a module. If so, the module will be
+ called ti-ads868x.
+
 config TI_AM335X_ADC
tristate "TI's AM335X ADC driver"
depends on MFD_TI_AM335X_TSCADC
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index fa5723a..75170d2 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
 obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
+obj-$(CONFIG_TI_ADS868X) += ti-ads868x.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
 obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
 obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
diff --git a/drivers/iio/adc/ti-ads868x.c b/drivers/iio/adc/ti-ads868x.c
new file mode 100644
index 000..66d9b64
--- /dev/null
+++ b/drivers/iio/adc/ti-ads868x.c
@@ -0,0 +1,456 @@
+/*
+ * Copyright (C) 2015 Prevas A/S
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define ADS868X_CMD_REG(x) (x << 8)
+#define ADS868X_CMD_REG_NOOP   0x00
+#define ADS868X_CMD_REG_RST0x85
+#define ADS868X_CMD_REG_MAN_CH(chan)   (0xC0 | (4 * chan))
+#define ADS868X_CMD_DONT_CARE_BITS 16
+
+#define ADS868X_PROG_REG(x)(x << 9)
+#define ADS868X_PROG_REG_RANGE_CH(chan)(0x05 + chan)
+#define ADS868X_PROG_WR_BITBIT(8)
+#define ADS868X_PROG_DONT_CARE_BITS8
+
+#define ADS868X_VREF_MV4096
+#define ADS868X_REALBITS   16
+
+struct ads868x_chip_info {
+   unsigned int id;
+   const struct iio_chan_spec *channels;
+   unsigned int num_channels;
+   unsigned int flags;
+   const struct iio_info *iio_info;
+};
+
+struct ads868x_state {
+   const struct ads868x_chip_info  *chip_info;
+   struct spi_device   *spi;
+   struct regulator*reg;
+   unsigned intvref_mv;
+   charrange[8];
+   union {
+   __be32 d32;
+   u8 d8[4];
+   } data[2] cacheline_aligned;
+};
+
+enum ads868x_id {
+   ID_ADS8684,
+   ID_ADS8688,
+};
+
+enum ads868x_range {
+   ADS868X_PLUSMINUS25VREF = 0x00,
+   ADS868X_PLUSMINUS125VREF= 0x01,
+   ADS868X_PLUSMINUS0625VREF   = 0x02,
+   ADS868X_PLUS25VREF  = 0x05,
+   ADS868X_PLUS125VREF = 0x06,
+};
+
+struct ads868x_ranges {
+   enum ads868x_range range;
+   unsigned int scale;
+   int offset;
+};
+
+static struct ads868x_ranges ads868x_range_def[5] = {
+   {
+   .range = ADS868X_PLUSMINUS25VREF,
+   .scale = 76295,
+   .offset = -(1 << (ADS868X_REALBITS - 1)),
+   }, {
+   .range = ADS868X_PLUSMINUS125VREF,
+   .scale = 38148,
+   .offset = -(1 << (ADS868X_REALBITS - 1)),
+   }, {
+   .range = ADS868X_PLUSMINUS0625VREF,
+   .scale = 19074,
+   .offset = -(1 << (ADS868X_REALBITS - 1)),
+   }, {
+   .range = ADS868X_PLUS25VREF,
+   .scale = 38148,
+   .offset = 0,
+   }, {
+   .range = ADS868X_PLUS125VREF,
+   .scale = 19074,
+   .offset = 0,
+   }
+};
+
+static ssize_t ads868x_show_scales(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct ads868x_state *st = iio_priv(dev_to_iio_dev(dev));
+
+   return sprintf(buf, "0.%09u 0.%09u 0.%09u\n",
+  ads868

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[David Miller]

From: Florian Fainelli 
Date: Thu, 24 Sep 2015 18:39:56 -0700

> On 24/09/15 12:17, Russell King - ARM Linux wrote:
>> Hi,
>> 
>> The third version of this series fixes the build error which David
>> identified, and drops the broken changes for the Cavium Thunger BGX
>> ethernet driver as this driver requires some complex changes to
>> resolve the leakage - and this is best done by people who can test
>> the driver.
>> 
>> Compared to v2, the only patch which has changed is patch 6
>>   "net: fix phy refcounting in a bunch of drivers"
>> 
>> I _think_ I've been able to build-test all the drivers touched by
>> that patch to some degree now, though several of them needed the
>> Kconfig hacked to allow it (not all had || COMPILE_TEST clause on
>> their dependencies.)
> 
> Tested-by: Florian Fainelli 
> Reviewed-by: Florian Fainelli 
> 
> Thanks for fixing that.

Series applied, thanks.
--
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] gpio:pca953x: add mechanism to simulate open drain outputs

[H. Nikolaus Schaller]

Am 25.09.2015 um 00:11 schrieb Linus Walleij :

> On Wed, Sep 23, 2015 at 11:13 AM, H. Nikolaus Schaller
>  wrote:
> 
>> 1. add a DT property to specify the list of GPIO pins that are to become
>>   "open drain"
>> 2. if a pin is configured as "open drain", set value by either outputting a
>>   "0" (low level) or switching to input (high impedance)
>> 
>> Tested on OMAP5 uEVM with TCA6424 and some LEDs connected to 5V.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
> 
> I understand the approach, but this is the wrong way to do it.
> Instead of indicating that a pin on the pin controller should be
> open drain, the *consumer* specifying its gpios = <> should
> do this.
> 
> I just sent a patch adding the bindings because Tony Lindgren
> and Grygorii Strashko approached me similar problems so let's
> begin with the bindings.
> 
> Implementing it in the kernel requires some elaboration and it's
> going to be more complicated than this local approach, but it
> will be more generic and reusable so that is what we need to do.

Ok, I understand.

Should not be too difficult to modify the driver.

BR,
Nikolaus Schaller


--
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 v4 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135

[Yingjoe Chen]

On Thu, 2015-09-24 at 23:38 +0800, Yingjoe Chen wrote:
> Add arch timer node to enable arch-timer support. MT8135 firmware
> doesn't correctly setup arch-timer frequency and CNTVOFF, add
> properties to workaround this.
> 
> This also set cpu enable-method to enable SMP.
> 
> Signed-off-by: Yingjoe Chen 
> ---
>  arch/arm/boot/dts/mt8135.dtsi | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
> index 08371db..c3c90f2 100644
> --- a/arch/arm/boot/dts/mt8135.dtsi
> +++ b/arch/arm/boot/dts/mt8135.dtsi
> @@ -46,6 +46,7 @@
>   cpus {
>   #address-cells = <1>;
>   #size-cells = <0>;
> + enable-method = "mediatek,mt81xx-tz-smp";
>  
>   cpu0: cpu@0 {
>   device_type = "cpu";
> @@ -72,6 +73,17 @@
>   };
>   };
>  
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + trustzone-bootinfo: trustzone-bootinfo@80002000 {


Sorry, this should be

+   trustzone-bootinfo@80002000 {

I'll fix this in next version.

Joe.C


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

Error: arch/arm/boot/dts/mt8127.dtsi:56.21-22 syntax error

[kbuild test robot]

Hi Yingjoe,

FYI, build test results on v4.3-rc2 (pls ignore if it's inappropriate base for 
your patch).

config: arm-multi_v7_defconfig (attached as .config)
reproduce:
  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout 41626f34b6fad3bd9f733a6d8f5542683d2356d5
  # save the attached .config to linux build tree
  make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/mt8127.dtsi:56.21-22 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.3.0-rc2 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT_MAP=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0x
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_HANDLE_DOMAIN_IRQ=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_GENERIC_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_USERFAULTFD is not set
CONFIG_PCI_QUIRKS=y
CONFIG_MEMBARRIER=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not s

Error: arch/arm/boot/dts/mt8135.dtsi:81.21-22 syntax error

[kbuild test robot]

Hi Yingjoe,

FYI, build test results on v4.3-rc2 (pls ignore if it's inappropriate base for 
your patch).

config: arm-multi_v7_defconfig (attached as .config)
reproduce:
  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout 8a73387f4d2fc100197bd3a0d05398b7e243237d
  # save the attached .config to linux build tree
  make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/mt8135.dtsi:81.21-22 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.3.0-rc2 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT_MAP=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0x
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_HANDLE_DOMAIN_IRQ=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_GENERIC_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_USERFAULTFD is not set
CONFIG_PCI_QUIRKS=y
CONFIG_MEMBARRIER=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not s

[PATCH v6 10/14] power: bq24257: Add input DPM voltage threshold setting support

[Andreas Dannenberg]

A new optional device property called "ti,in-dpm-voltage" is introduced
to allow configuring the input voltage threshold for the devices'
dynamic power path management (DPM) feature. In short, it can be used to
prevent the input voltage from dropping below a certain value as current
is drawn to charge the battery or supply the system.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 43 +
 1 file changed, 43 insertions(+)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index b5acbc5..146ef8b 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -79,6 +79,7 @@ struct bq24257_init_data {
u8 iterm;   /* termination current */
u8 iilimit; /* input current limit */
u8 vovp;/* over voltage protection voltage */
+   u8 vindpm;  /* VDMP input threshold voltage */
 };
 
 struct bq24257_state {
@@ -208,6 +209,13 @@ static const u32 bq24257_vovp_map[] = {
 
 #define BQ24257_VOVP_MAP_SIZE  ARRAY_SIZE(bq24257_vovp_map)
 
+static const u32 bq24257_vindpm_map[] = {
+   420, 428, 436, 444, 452, 460, 468,
+   476
+};
+
+#define BQ24257_VINDPM_MAP_SIZEARRAY_SIZE(bq24257_vindpm_map)
+
 static int bq24257_field_read(struct bq24257_device *bq,
  enum bq24257_fields field_id)
 {
@@ -434,6 +442,17 @@ enum bq24257_vovp {
VOVP_10500
 };
 
+enum bq24257_vindpm {
+   VINDPM_4200,
+   VINDPM_4280,
+   VINDPM_4360,
+   VINDPM_4440,
+   VINDPM_4520,
+   VINDPM_4600,
+   VINDPM_4680,
+   VINDPM_4760
+};
+
 enum bq24257_port_type {
PORT_TYPE_DCP,  /* Dedicated Charging Port */
PORT_TYPE_CDP,  /* Charging Downstream Port */
@@ -604,6 +623,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
{F_VBAT, bq->init_data.vbat},
{F_ITERM, bq->init_data.iterm},
{F_VOVP, bq->init_data.vovp},
+   {F_VINDPM, bq->init_data.vindpm},
};
 
/*
@@ -684,10 +704,23 @@ static ssize_t bq24257_show_ovp_voltage(struct device 
*dev,
 bq24257_vovp_map[bq->init_data.vovp]);
 }
 
+static ssize_t bq24257_show_in_dpm_voltage(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct power_supply *psy = dev_get_drvdata(dev);
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+
+   return scnprintf(buf, PAGE_SIZE, "%u\n",
+bq24257_vindpm_map[bq->init_data.vindpm]);
+}
+
 static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
+static DEVICE_ATTR(in_dpm_voltage, S_IRUGO, bq24257_show_in_dpm_voltage, NULL);
 
 static struct attribute *bq24257_charger_attr[] = {
&dev_attr_ovp_voltage.attr,
+   &dev_attr_in_dpm_voltage.attr,
NULL,
 };
 
@@ -782,6 +815,16 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
  bq24257_vovp_map,
  BQ24257_VOVP_MAP_SIZE);
 
+   ret = device_property_read_u32(bq->dev, "ti,in-dpm-voltage",
+  &property);
+   if (ret < 0)
+   bq->init_data.vindpm = VINDPM_4360;
+   else
+   bq->init_data.vindpm =
+   bq24257_find_idx(property,
+bq24257_vindpm_map,
+BQ24257_VINDPM_MAP_SIZE);
+
return 0;
 }
 
-- 
1.9.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 v6 08/14] power: bq24257: Use managed power supply register

[Andreas Dannenberg]

Use the devm_* managed version of the function to register the power
supply and remove the associated unregister function.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 9d2b412..7acc10a 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -660,8 +660,10 @@ static int bq24257_power_supply_init(struct bq24257_device 
*bq)
psy_cfg.supplied_to = bq24257_charger_supplied_to;
psy_cfg.num_supplicants = ARRAY_SIZE(bq24257_charger_supplied_to);
 
-   bq->charger = power_supply_register(bq->dev, &bq24257_power_supply_desc,
-   &psy_cfg);
+   bq->charger = devm_power_supply_register(bq->dev,
+&bq24257_power_supply_desc,
+&psy_cfg);
+
if (IS_ERR(bq->charger))
return PTR_ERR(bq->charger);
 
@@ -865,8 +867,6 @@ static int bq24257_remove(struct i2c_client *client)
if (bq->iilimit_autoset_enable)
cancel_delayed_work_sync(&bq->iilimit_setup_work);
 
-   power_supply_unregister(bq->charger);
-
bq24257_field_write(bq, F_RESET, 1); /* reset to defaults */
 
return 0;
-- 
1.9.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 v6 07/14] power: bq24257: Add SW-based approach for Power Good determination

[Andreas Dannenberg]

A software-based approach for determining the charger's input voltage
"Power Good" state is introduced for devices like the bq24250 which
don't have a dedicated hardware pin for that purpose. This SW-based
approach is also used for other devices (with dedicated PG pin) as a
fall back solution if that pin is not configured to be used through
"pg-gpios".

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 49 -
 1 file changed, 39 insertions(+), 10 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 6daaac2..9d2b412 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -359,7 +359,26 @@ static int bq24257_get_chip_state(struct bq24257_device 
*bq,
 
state->fault = ret;
 
-   state->power_good = !gpiod_get_value_cansleep(bq->pg);
+   if (bq->pg)
+   state->power_good = !gpiod_get_value_cansleep(bq->pg);
+   else
+   /*
+* If we have a chip without a dedicated power-good GPIO or
+* some other explicit bit that would provide this information
+* assume the power is good if there is no supply related
+* fault - and not good otherwise. There is a possibility for
+* other errors to mask that power in fact is not good but this
+* is probably the best we can do here.
+*/
+   switch (state->fault) {
+   case FAULT_INPUT_OVP:
+   case FAULT_INPUT_UVLO:
+   case FAULT_INPUT_LDO_LOW:
+   state->power_good = false;
+   break;
+   default:
+   state->power_good = true;
+   }
 
return 0;
 }
@@ -649,15 +668,18 @@ static int bq24257_power_supply_init(struct 
bq24257_device *bq)
return 0;
 }
 
-static int bq24257_pg_gpio_probe(struct bq24257_device *bq)
+static void bq24257_pg_gpio_probe(struct bq24257_device *bq)
 {
-   bq->pg = devm_gpiod_get_index(bq->dev, BQ24257_PG_GPIO, 0, GPIOD_IN);
+   bq->pg = devm_gpiod_get_optional(bq->dev, BQ24257_PG_GPIO, GPIOD_IN);
+
if (IS_ERR(bq->pg)) {
-   dev_err(bq->dev, "could not probe PG pin\n");
-   return PTR_ERR(bq->pg);
+   dev_err(bq->dev, "error probing PG pin\n");
+   bq->pg = NULL;
+   return;
}
 
-   return 0;
+   if (bq->pg)
+   dev_dbg(bq->dev, "probed PG pin = %d", desc_to_gpio(bq->pg));
 }
 
 static int bq24257_fw_probe(struct bq24257_device *bq)
@@ -787,10 +809,17 @@ static int bq24257_probe(struct i2c_client *client,
INIT_DELAYED_WORK(&bq->iilimit_setup_work,
  bq24257_iilimit_setup_work);
 
-   /* we can only check Power Good status by probing the PG pin */
-   ret = bq24257_pg_gpio_probe(bq);
-   if (ret < 0)
-   return ret;
+   /*
+* The BQ24250 doesn't have a dedicated Power Good (PG) pin so let's
+* not probe for it and instead use a SW-based approach to determine
+* the PG state. We also use a SW-based approach for all other devices
+* if the PG pin is either not defined or can't be probed.
+*/
+   if (bq->chip != BQ24250)
+   bq24257_pg_gpio_probe(bq);
+
+   if (!bq->pg)
+   dev_info(bq->dev, "using SW-based power-good detection\n");
 
/* reset all registers to defaults */
ret = bq24257_field_write(bq, F_RESET, 1);
-- 
1.9.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 v6 04/14] power: bq24257: Add basic support for bq24250/bq24251

[Andreas Dannenberg]

This patch adds basic support for bq24250 and bq24251 which are very
similar to the bq24257 the driver was originally written for. Basic
support means the ability to select a device through Kconfig, DT and
ACPI, an instance variable allowing to check which chip is active, and
the reporting back of the selected device through the model_name power
supply sysfs property.

This patch by itself is not sufficient to actually use those two added
devices in a real-world setting due to some feature differences which
are addressed by other patches in this series.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/Kconfig   |  5 ++--
 drivers/power/bq24257_charger.c | 52 ++---
 2 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index eeb5776..9e68853 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -409,12 +409,13 @@ config CHARGER_BQ24190
  Say Y to enable support for the TI BQ24190 battery charger.
 
 config CHARGER_BQ24257
-   tristate "TI BQ24257 battery charger driver"
+   tristate "TI BQ24250/24251/24257 battery charger driver"
depends on I2C
depends on GPIOLIB || COMPILE_TEST
depends on REGMAP_I2C
help
- Say Y to enable support for the TI BQ24257 battery charger.
+ Say Y to enable support for the TI BQ24250, BQ24251, and BQ24257 
battery
+ chargers.
 
 config CHARGER_BQ24735
tristate "TI BQ24735 battery charger support"
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index d8939dc..77c895f 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -13,6 +13,10 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
+ * Datasheets:
+ * http://www.ti.com/product/bq24250
+ * http://www.ti.com/product/bq24251
+ * http://www.ti.com/product/bq24257
  */
 
 #include 
@@ -40,6 +44,22 @@
 
 #define BQ24257_ILIM_SET_DELAY 1000/* msec */
 
+/*
+ * When adding support for new devices make sure that enum bq2425x_chip and
+ * bq2425x_chip_name[] always stay in sync!
+ */
+enum bq2425x_chip {
+   BQ24250,
+   BQ24251,
+   BQ24257,
+};
+
+static const char *const bq2425x_chip_name[] = {
+   "bq24250",
+   "bq24251",
+   "bq24257",
+};
+
 enum bq24257_fields {
F_WD_FAULT, F_WD_EN, F_STAT, F_FAULT,   /* REG 1 */
F_RESET, F_IILIMIT, F_EN_STAT, F_EN_TERM, F_CE, F_HZ_MODE,  /* REG 2 */
@@ -70,6 +90,8 @@ struct bq24257_device {
struct device *dev;
struct power_supply *charger;
 
+   enum bq2425x_chip chip;
+
struct regmap *rmap;
struct regmap_field *rmap_fields[F_MAX_FIELDS];
 
@@ -248,6 +270,10 @@ static int bq24257_power_supply_get_property(struct 
power_supply *psy,
val->strval = BQ24257_MANUFACTURER;
break;
 
+   case POWER_SUPPLY_PROP_MODEL_NAME:
+   val->strval = bq2425x_chip_name[bq->chip];
+   break;
+
case POWER_SUPPLY_PROP_ONLINE:
val->intval = state.power_good;
break;
@@ -561,6 +587,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
 
 static enum power_supply_property bq24257_power_supply_props[] = {
POWER_SUPPLY_PROP_MANUFACTURER,
+   POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_HEALTH,
@@ -645,6 +672,7 @@ static int bq24257_probe(struct i2c_client *client,
 {
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
struct device *dev = &client->dev;
+   const struct acpi_device_id *acpi_id;
struct bq24257_device *bq;
int ret;
int i;
@@ -661,6 +689,18 @@ static int bq24257_probe(struct i2c_client *client,
bq->client = client;
bq->dev = dev;
 
+   if (ACPI_HANDLE(dev)) {
+   acpi_id = acpi_match_device(dev->driver->acpi_match_table,
+   &client->dev);
+   if (!acpi_id) {
+   dev_err(dev, "Failed to match ACPI device\n");
+   return -ENODEV;
+   }
+   bq->chip = (enum bq2425x_chip)acpi_id->driver_data;
+   } else {
+   bq->chip = (enum bq2425x_chip)id->driver_data;
+   }
+
mutex_init(&bq->lock);
 
bq->rmap = devm_regmap_init_i2c(client, &bq24257_regmap_config);
@@ -723,7 +763,7 @@ static int bq24257_probe(struct i2c_client *client,
bq24257_irq_handler_thread,
IRQF_TRIGGER_FALLING |
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
-   "bq24257", bq);
+   bq2425x_chip_name[bq->chip], bq);
   

[PATCH v6 09/14] power: bq24257: Add over voltage protection setting support

[Andreas Dannenberg]

A new optional device property called "ti,ovp-voltage" is introduced to
allow configuring the input over voltage protection setting.

This commit also adds the basic sysfs support for custom properties
which is being used to allow userspace to read the current ovp-voltage
setting.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 67 +++--
 1 file changed, 64 insertions(+), 3 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 7acc10a..b5acbc5 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -78,6 +78,7 @@ struct bq24257_init_data {
u8 vbat;/* regulation voltage  */
u8 iterm;   /* termination current */
u8 iilimit; /* input current limit */
+   u8 vovp;/* over voltage protection voltage */
 };
 
 struct bq24257_state {
@@ -200,6 +201,13 @@ static const u32 bq24257_iilimit_map[] = {
 
 #define BQ24257_IILIMIT_MAP_SIZE   ARRAY_SIZE(bq24257_iilimit_map)
 
+static const u32 bq24257_vovp_map[] = {
+   600, 650, 700, 800, 900, 950, 1000,
+   1050
+};
+
+#define BQ24257_VOVP_MAP_SIZE  ARRAY_SIZE(bq24257_vovp_map)
+
 static int bq24257_field_read(struct bq24257_device *bq,
  enum bq24257_fields field_id)
 {
@@ -415,6 +423,17 @@ enum bq24257_in_ilimit {
IILIMIT_NONE,
 };
 
+enum bq24257_vovp {
+   VOVP_6000,
+   VOVP_6500,
+   VOVP_7000,
+   VOVP_8000,
+   VOVP_9000,
+   VOVP_9500,
+   VOVP_1,
+   VOVP_10500
+};
+
 enum bq24257_port_type {
PORT_TYPE_DCP,  /* Dedicated Charging Port */
PORT_TYPE_CDP,  /* Charging Downstream Port */
@@ -583,7 +602,8 @@ static int bq24257_hw_init(struct bq24257_device *bq)
} init_data[] = {
{F_ICHG, bq->init_data.ichg},
{F_VBAT, bq->init_data.vbat},
-   {F_ITERM, bq->init_data.iterm}
+   {F_ITERM, bq->init_data.iterm},
+   {F_VOVP, bq->init_data.vovp},
};
 
/*
@@ -653,6 +673,28 @@ static const struct power_supply_desc 
bq24257_power_supply_desc = {
.get_property = bq24257_power_supply_get_property,
 };
 
+static ssize_t bq24257_show_ovp_voltage(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct power_supply *psy = dev_get_drvdata(dev);
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+
+   return scnprintf(buf, PAGE_SIZE, "%u\n",
+bq24257_vovp_map[bq->init_data.vovp]);
+}
+
+static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
+
+static struct attribute *bq24257_charger_attr[] = {
+   &dev_attr_ovp_voltage.attr,
+   NULL,
+};
+
+static const struct attribute_group bq24257_attr_group = {
+   .attrs = bq24257_charger_attr,
+};
+
 static int bq24257_power_supply_init(struct bq24257_device *bq)
 {
struct power_supply_config psy_cfg = { .drv_data = bq, };
@@ -731,6 +773,15 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
 bq24257_iilimit_map,
 BQ24257_IILIMIT_MAP_SIZE);
 
+   ret = device_property_read_u32(bq->dev, "ti,ovp-voltage",
+  &property);
+   if (ret < 0)
+   bq->init_data.vovp = VOVP_6500;
+   else
+   bq->init_data.vovp = bq24257_find_idx(property,
+ bq24257_vovp_map,
+ BQ24257_VOVP_MAP_SIZE);
+
return 0;
 }
 
@@ -854,10 +905,18 @@ static int bq24257_probe(struct i2c_client *client,
}
 
ret = bq24257_power_supply_init(bq);
-   if (ret < 0)
+   if (ret < 0) {
dev_err(dev, "Failed to register power supply\n");
+   return ret;
+   }
 
-   return ret;
+   ret = sysfs_create_group(&bq->charger->dev.kobj, &bq24257_attr_group);
+   if (ret < 0) {
+   dev_err(dev, "Can't create sysfs entries\n");
+   return ret;
+   }
+
+   return 0;
 }
 
 static int bq24257_remove(struct i2c_client *client)
@@ -867,6 +926,8 @@ static int bq24257_remove(struct i2c_client *client)
if (bq->iilimit_autoset_enable)
cancel_delayed_work_sync(&bq->iilimit_setup_work);
 
+   sysfs_remove_group(&bq->charger->dev.kobj, &bq24257_attr_group);
+
bq24257_field_write(bq, F_RESET, 1); /* reset to defaults */
 
return 0;
-- 
1.9.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 v6 14/14] Documentation: power: bq24257: Document exported sysfs entries

[Andreas Dannenberg]

Document the settings exported by bq24257 charger driver through sysfs
entries:
- ovp_voltage
- in_dpm_voltage
- high_impedance_enable
- sysoff_enable

Signed-off-by: Andreas Dannenberg 
---
 Documentation/ABI/testing/sysfs-class-power | 58 +
 1 file changed, 58 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-power 
b/Documentation/ABI/testing/sysfs-class-power
index 369d2a2..fd6cb79 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -74,3 +74,61 @@ Description:
 
Valid values:
- 0 - 70 (minutes), step by 10 (rounded down)
+
+What:  /sys/class/power_supply/bq24257-charger/ovp_voltage
+Date:  September 2015
+KernelVersion: 4.3.0
+Contact:   Andreas Dannenberg 
+Description:
+   This entry configures the overvoltage protection feature of 
bq24257-
+   type charger devices. This feature protects the device and other
+   components against damage from overvoltage on the input supply. 
See
+   device datasheet for details.
+
+   Valid values:
+   - 600, 650, 700, 800, 900, 950, 
1000,
+ 1050 (all uV)
+
+What:  /sys/class/power_supply/bq24257-charger/in_dpm_voltage
+Date:  September 2015
+KernelVersion: 4.3.0
+Contact:   Andreas Dannenberg 
+Description:
+   This entry configures the input dynamic power path management 
voltage of
+   bq24257-type charger devices. Once the supply drops to the 
configured
+   voltage, the input current limit is reduced down to prevent the 
further
+   drop of the supply. When the IC enters this mode, the charge 
current is
+   lower than the set. See device datasheet for details.
+
+   Valid values:
+   - 420, 428, 436, 444, 452, 460, 468,
+ 476 (all uV)
+
+What:  /sys/class/power_supply/bq24257-charger/high_impedance_enable
+Date:  September 2015
+KernelVersion: 4.3.0
+Contact:   Andreas Dannenberg 
+Description:
+   This entry allows enabling the high-impedance mode of 
bq24257-type
+   charger devices. If enabled, it places the charger IC into low 
power
+   standby mode with the switch mode controller disabled. When 
disabled,
+   the charger operates normally. See device datasheet for details.
+
+   Valid values:
+   - 1: enabled
+   - 0: disabled
+
+What:  /sys/class/power_supply/bq24257-charger/sysoff_enable
+Date:  September 2015
+KernelVersion: 4.3.0
+Contact:   Andreas Dannenberg 
+Description:
+   This entry allows enabling the sysoff mode of bq24257-type 
charger
+   devices. If enabled and the input is removed, the internal 
battery FET
+   is turned off in order to reduce the leakage from the BAT pin 
to less
+   than 1uA. Note that on some devices/systems this disconnects 
the battery
+   from the system. See device datasheet for details.
+
+   Valid values:
+   - 1: enabled
+   - 0: disabled
-- 
1.9.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 v6 05/14] power: bq24257: Add bit definition for temp sense enable

[Andreas Dannenberg]

Adding a missing bit definition for the sake of consistency device model
vs. bit field representation. No change in functionality.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 77c895f..ac471cd 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -66,7 +66,7 @@ enum bq24257_fields {
F_VBAT, F_USB_DET,  /* REG 3 */
F_ICHG, F_ITERM,/* REG 4 */
F_LOOP_STATUS, F_LOW_CHG, F_DPDM_EN, F_CE_STATUS, F_VINDPM, /* REG 5 */
-   F_X2_TMR_EN, F_TMR, F_SYSOFF, F_TS_STAT,/* REG 6 */
+   F_X2_TMR_EN, F_TMR, F_SYSOFF, F_TS_EN, F_TS_STAT,   /* REG 6 */
F_VOVP, F_CLR_VDP, F_FORCE_BATDET, F_FORCE_PTM, /* REG 7 */
 
F_MAX_FIELDS
@@ -156,6 +156,7 @@ static const struct reg_field bq24257_reg_fields[] = {
[F_X2_TMR_EN]   = REG_FIELD(BQ24257_REG_6, 7, 7),
[F_TMR] = REG_FIELD(BQ24257_REG_6, 5, 6),
[F_SYSOFF]  = REG_FIELD(BQ24257_REG_6, 4, 4),
+   [F_TS_EN]   = REG_FIELD(BQ24257_REG_6, 3, 3),
[F_TS_STAT] = REG_FIELD(BQ24257_REG_6, 0, 2),
/* REG 7 */
[F_VOVP]= REG_FIELD(BQ24257_REG_7, 5, 7),
-- 
1.9.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 v6 12/14] power: bq24257: Add various device-specific sysfs properties

[Andreas Dannenberg]

This patch adds support for enabling/disabling optional device specific
features through sysfs properties at runtime.

* High-impedance mode enable/disable
* Sysoff enable/disable

Refer to the respective device datasheets for more information:

http://www.ti.com/product/bq24250
http://www.ti.com/product/bq24251
http://www.ti.com/product/bq24257

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 53 +
 1 file changed, 53 insertions(+)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index b029fdf..ccd0205 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -790,12 +790,65 @@ static ssize_t bq24257_show_in_dpm_voltage(struct device 
*dev,
 bq24257_vindpm_map[bq->init_data.vindpm]);
 }
 
+static ssize_t bq24257_sysfs_show_enable(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct power_supply *psy = dev_get_drvdata(dev);
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+   int ret;
+
+   if (strcmp(attr->attr.name, "high_impedance_enable") == 0)
+   ret = bq24257_field_read(bq, F_HZ_MODE);
+   else if (strcmp(attr->attr.name, "sysoff_enable") == 0)
+   ret = bq24257_field_read(bq, F_SYSOFF);
+   else
+   return -EINVAL;
+
+   if (ret < 0)
+   return ret;
+
+   return scnprintf(buf, PAGE_SIZE, "%d\n", ret);
+}
+
+static ssize_t bq24257_sysfs_set_enable(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf,
+   size_t count)
+{
+   struct power_supply *psy = dev_get_drvdata(dev);
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+   long val;
+   int ret;
+
+   if (kstrtol(buf, 10, &val) < 0)
+   return -EINVAL;
+
+   if (strcmp(attr->attr.name, "high_impedance_enable") == 0)
+   ret = bq24257_field_write(bq, F_HZ_MODE, (bool)val);
+   else if (strcmp(attr->attr.name, "sysoff_enable") == 0)
+   ret = bq24257_field_write(bq, F_SYSOFF, (bool)val);
+   else
+   return -EINVAL;
+
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+
 static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
 static DEVICE_ATTR(in_dpm_voltage, S_IRUGO, bq24257_show_in_dpm_voltage, NULL);
+static DEVICE_ATTR(high_impedance_enable, S_IWUSR | S_IRUGO,
+  bq24257_sysfs_show_enable, bq24257_sysfs_set_enable);
+static DEVICE_ATTR(sysoff_enable, S_IWUSR | S_IRUGO,
+  bq24257_sysfs_show_enable, bq24257_sysfs_set_enable);
 
 static struct attribute *bq24257_charger_attr[] = {
&dev_attr_ovp_voltage.attr,
&dev_attr_in_dpm_voltage.attr,
+   &dev_attr_high_impedance_enable.attr,
+   &dev_attr_sysoff_enable.attr,
NULL,
 };
 
-- 
1.9.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 v6 13/14] power: bq24257: Add platform data based initialization

[Andreas Dannenberg]

The patch adds a way to setup and initialize the device through the use
of platform data with configuration options equivalent to when using
device firmware (DT or ACPI) for systems where this is not available.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c   | 39 +--
 include/linux/power/bq24257_charger.h | 25 ++
 2 files changed, 62 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/power/bq24257_charger.h

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index ccd0205..6bbf406 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -27,10 +27,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
+#include 
+
 #define BQ24257_REG_1  0x00
 #define BQ24257_REG_2  0x01
 #define BQ24257_REG_3  0x02
@@ -887,6 +890,36 @@ static void bq24257_pg_gpio_probe(struct bq24257_device 
*bq)
dev_dbg(bq->dev, "probed PG pin = %d", desc_to_gpio(bq->pg));
 }
 
+static void bq24257_pdata_probe(struct bq24257_device *bq,
+   struct bq24257_platform_data *pdata)
+{
+   bq->init_data.ichg = bq24257_find_idx(pdata->ichg,
+ bq24257_ichg_map,
+ BQ24257_ICHG_MAP_SIZE);
+
+   bq->init_data.vbat = bq24257_find_idx(pdata->vbat,
+ bq24257_vbat_map,
+ BQ24257_VBAT_MAP_SIZE);
+
+   bq->init_data.iterm = bq24257_find_idx(pdata->iterm,
+  bq24257_iterm_map,
+  BQ24257_ITERM_MAP_SIZE);
+
+   bq->init_data.iilimit = bq24257_find_idx(pdata->iilimit,
+bq24257_iilimit_map,
+BQ24257_IILIMIT_MAP_SIZE);
+
+   bq->init_data.vovp = bq24257_find_idx(pdata->vovp,
+ bq24257_vovp_map,
+ BQ24257_VOVP_MAP_SIZE);
+
+   bq->init_data.vindpm = bq24257_find_idx(pdata->vindpm,
+   bq24257_vindpm_map,
+   BQ24257_VINDPM_MAP_SIZE);
+
+   bq->iilimit_autoset_enable = pdata->iilimit_autoset_enable;
+}
+
 static int bq24257_fw_probe(struct bq24257_device *bq)
 {
int ret;
@@ -962,6 +995,7 @@ static int bq24257_probe(struct i2c_client *client,
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
struct device *dev = &client->dev;
const struct acpi_device_id *acpi_id;
+   struct bq24257_platform_data *pdata = client->dev.platform_data;
struct bq24257_device *bq;
int ret;
int i;
@@ -1011,14 +1045,15 @@ static int bq24257_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, bq);
 
-   if (!dev->platform_data) {
+   if (!pdata) {
ret = bq24257_fw_probe(bq);
if (ret < 0) {
dev_err(dev, "Cannot read device properties.\n");
return ret;
}
} else {
-   return -ENODEV;
+   dev_dbg(dev, "init using platform data\n");
+   bq24257_pdata_probe(bq, pdata);
}
 
/*
diff --git a/include/linux/power/bq24257_charger.h 
b/include/linux/power/bq24257_charger.h
new file mode 100644
index 000..c131c5d
--- /dev/null
+++ b/include/linux/power/bq24257_charger.h
@@ -0,0 +1,25 @@
+/*
+ * Platform data for the TI bq24257 battery charger driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _BQ24257_CHARGER_H_
+#define _BQ24257_CHARGER_H_
+
+#include 
+#include 
+
+struct bq24257_platform_data {
+   u32 ichg;  /* charge current (uA) */
+   u32 vbat;  /* regulation voltage (uV) */
+   u32 iterm;/* termination current (uA) */
+   u32 iilimit;  /* input current limit (uA) */
+   u32 vovp; /* over voltage protection voltage (uV) */
+   u32 vindpm;  /* VDMP input threshold voltage (uV) */
+   bool iilimit_autoset_enable;/* auto-detect of input current limit */
+};
+
+#endif /* _BQ24257_CHARGER_H_ */
-- 
1.9.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 v6 06/14] power: bq24257: Allow manual setting of input current limit

[Andreas Dannenberg]

A new optional device property called "ti,current-limit" is introduced
to allow disabling the D+/D- USB signal-based charger type auto-
detection algorithm used to set the input current limit and instead to
use a fixed input current limit.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 86 +
 1 file changed, 70 insertions(+), 16 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index ac471cd..6daaac2 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -77,6 +77,7 @@ struct bq24257_init_data {
u8 ichg;/* charge current  */
u8 vbat;/* regulation voltage  */
u8 iterm;   /* termination current */
+   u8 iilimit; /* input current limit */
 };
 
 struct bq24257_state {
@@ -103,6 +104,8 @@ struct bq24257_device {
struct bq24257_state state;
 
struct mutex lock; /* protect state data */
+
+   bool iilimit_autoset_enable;
 };
 
 static bool bq24257_is_volatile_reg(struct device *dev, unsigned int reg)
@@ -191,6 +194,12 @@ static const u32 bq24257_iterm_map[] = {
 
 #define BQ24257_ITERM_MAP_SIZE ARRAY_SIZE(bq24257_iterm_map)
 
+static const u32 bq24257_iilimit_map[] = {
+   10, 15, 50, 90, 150, 200
+};
+
+#define BQ24257_IILIMIT_MAP_SIZE   ARRAY_SIZE(bq24257_iilimit_map)
+
 static int bq24257_field_read(struct bq24257_device *bq,
  enum bq24257_fields field_id)
 {
@@ -480,19 +489,24 @@ static void bq24257_handle_state_change(struct 
bq24257_device *bq,
old_state = bq->state;
mutex_unlock(&bq->lock);
 
+   /*
+* Handle BQ2425x state changes observing whether the D+/D- based input
+* current limit autoset functionality is enabled.
+*/
if (!new_state->power_good) {
dev_dbg(bq->dev, "Power removed\n");
-   cancel_delayed_work_sync(&bq->iilimit_setup_work);
-
-   /* activate D+/D- port detection algorithm */
-   ret = bq24257_field_write(bq, F_DPDM_EN, 1);
-   if (ret < 0)
-   goto error;
-
-   /* reset input current limit */
-   ret = bq24257_field_write(bq, F_IILIMIT, IILIMIT_500);
-   if (ret < 0)
-   goto error;
+   if (bq->iilimit_autoset_enable) {
+   cancel_delayed_work_sync(&bq->iilimit_setup_work);
+
+   /* activate D+/D- port detection algorithm */
+   ret = bq24257_field_write(bq, F_DPDM_EN, 1);
+   if (ret < 0)
+   goto error;
+   /* reset input current limit */
+   ret = bq24257_field_write(bq, F_IILIMIT, IILIMIT_500);
+   if (ret < 0)
+   goto error;
+   }
} else if (!old_state.power_good) {
dev_dbg(bq->dev, "Power inserted\n");
if (bq->iilimit_autoset_enable)
@@ -577,7 +591,16 @@ static int bq24257_hw_init(struct bq24257_device *bq)
bq->state = state;
mutex_unlock(&bq->lock);
 
-   if (!state.power_good)
+   if (!bq->iilimit_autoset_enable) {
+   dev_dbg(bq->dev, "manually setting iilimit = %u\n",
+   bq->init_data.iilimit);
+
+   /* program fixed input current limit */
+   ret = bq24257_field_write(bq, F_IILIMIT,
+ bq->init_data.iilimit);
+   if (ret < 0)
+   return ret;
+   } else if (!state.power_good)
/* activate D+/D- detection algorithm */
ret = bq24257_field_write(bq, F_DPDM_EN, 1);
else if (state.fault != FAULT_NO_BAT)
@@ -642,6 +665,7 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
int ret;
u32 property;
 
+   /* Required properties */
ret = device_property_read_u32(bq->dev, "ti,charge-current", &property);
if (ret < 0)
return ret;
@@ -665,6 +689,24 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
bq->init_data.iterm = bq24257_find_idx(property, bq24257_iterm_map,
   BQ24257_ITERM_MAP_SIZE);
 
+   /* Optional properties. If not provided use reasonable default. */
+   ret = device_property_read_u32(bq->dev, "ti,current-limit",
+  &property);
+   if (ret < 0) {
+   bq->iilimit_autoset_enable = true;
+
+   /*
+* Explicitly set a default value which will be needed for
+* devices that don't support the automatic setting of the input
+* current limit through the charger type detection mechanism.
+*/
+   bq->init_data.i

[PATCH v6 01/14] dt: power: bq24257-charger: Cover additional devices

[Andreas Dannenberg]

Extend the bq24257 charger's device tree documentation to cover the
bq24250 and bq24251 devices as well feature additions.

Signed-off-by: Andreas Dannenberg 
---
 .../devicetree/bindings/power/bq24257.txt  | 53 --
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/bq24257.txt 
b/Documentation/devicetree/bindings/power/bq24257.txt
index 5c9d394..6c376ef 100644
--- a/Documentation/devicetree/bindings/power/bq24257.txt
+++ b/Documentation/devicetree/bindings/power/bq24257.txt
@@ -1,21 +1,64 @@
-Binding for TI bq24257 Li-Ion Charger
+Binding for TI bq24250/bq24251/bq24257 Li-Ion Charger
 
 Required properties:
 - compatible: Should contain one of the following:
+ * "ti,bq24250"
+ * "ti,bq24251"
  * "ti,bq24257"
-- reg:integer, i2c address of the device.
+- reg: integer, i2c address of the device.
+- interrupt-parent: Should be the phandle for the interrupt controller. Use in
+conjunction with "interrupts".
+- interrupts: Interrupt mapping for GPIO IRQ (configure for both edges). Use in
+conjunction with "interrupt-parent".
 - ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
-- ti,charge-current:  integer, maximum charging current in uA.
-- ti,termination-current:  integer, charge will be terminated when current in
-  constant-voltage phase drops below this value (in 
uA).
+- ti,charge-current: integer, maximum charging current in uA.
+- ti,termination-current: integer, charge will be terminated when current in
+constant-voltage phase drops below this value (in uA).
+
+Optional properties:
+- pg-gpios: GPIO used for connecting the bq2425x device PG (Power Good) pin.
+This pin is not available on all devices however it should be used if
+possible as this is the recommended way to obtain the charger's input PG
+state. If this pin is not specified a software-based approach for PG
+detection is used.
+- ti,current-limit: The maximum current to be drawn from the charger's input
+(in uA). If this property is not specified a USB D+/D- signal based charger
+type detection is used (if available) and the input limit current is set
+accordingly. If the D+/D- based detection is not available on a given 
device
+a default of 500,000 is used (=500mA).
+- ti,ovp-voltage: Configures the over voltage protection voltage (in uV). If
+not specified a default of 6,5000,000 (=6.5V) is used.
+- ti,in-dpm-voltage: Configures the threshold input voltage for the dynamic
+power path management (in uV). If not specified a default of 4,360,000
+(=4.36V) is used.
 
 Example:
 
 bq24257 {
compatible = "ti,bq24257";
reg = <0x6a>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <16 IRQ_TYPE_EDGE_BOTH>;
+
+   pg-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
 
ti,battery-regulation-voltage = <420>;
ti,charge-current = <100>;
ti,termination-current = <5>;
 };
+
+Example:
+
+bq24250 {
+   compatible = "ti,bq24250";
+   reg = <0x6a>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <16 IRQ_TYPE_EDGE_BOTH>;
+
+   ti,battery-regulation-voltage = <420>;
+   ti,charge-current = <50>;
+   ti,termination-current = <5>;
+   ti,current-limit = <90>;
+   ti,ovp-voltage = <950>;
+   ti,in-dpm-voltage = <444>;
+};
-- 
1.9.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 v6 11/14] power: bq24257: Allow input current limit sysfs access

[Andreas Dannenberg]

This patch allows reading and writing of the input current limit through
the power supply's input_current_limit sysfs property. This allows
userspace to see what charger was detected (if the D+/D- USB signal-
based charger type detection is enabled) and to re-configure the maximum
current drawn from the external supply at runtime based on system-level
knowledge or user input. Note that upon charger disconnection and
re-connection the limit configured through firmware becomes active again
(or the D+/D- USB signal-based charger detection will be run again).

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 83 +++--
 1 file changed, 79 insertions(+), 4 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 146ef8b..b029fdf 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -267,6 +267,47 @@ enum bq24257_fault {
FAULT_INPUT_LDO_LOW,
 };
 
+static int bq24257_get_input_current_limit(struct bq24257_device *bq,
+  union power_supply_propval *val)
+{
+   int ret;
+
+   ret = bq24257_field_read(bq, F_IILIMIT);
+   if (ret < 0)
+   return ret;
+
+   /*
+* The "External ILIM" and "Production & Test" modes are not exposed
+* through this driver and not being covered by the lookup table.
+* Should such a mode have become active let's return an error rather
+* than exceeding the bounds of the lookup table and returning
+* garbage.
+*/
+   if (ret >= BQ24257_IILIMIT_MAP_SIZE)
+   return -ENODATA;
+
+   val->intval = bq24257_iilimit_map[ret];
+
+   return 0;
+}
+
+static int bq24257_set_input_current_limit(struct bq24257_device *bq,
+   const union power_supply_propval *val)
+{
+   /*
+* Address the case where the user manually sets an input current limit
+* while the charger auto-detection mechanism is is active. In this
+* case we want to abort and go straight to the user-specified value.
+*/
+   if (bq->iilimit_autoset_enable)
+   cancel_delayed_work_sync(&bq->iilimit_setup_work);
+
+   return bq24257_field_write(bq, F_IILIMIT,
+  bq24257_find_idx(val->intval,
+   bq24257_iilimit_map,
+   BQ24257_IILIMIT_MAP_SIZE));
+}
+
 static int bq24257_power_supply_get_property(struct power_supply *psy,
 enum power_supply_property psp,
 union power_supply_propval *val)
@@ -351,6 +392,9 @@ static int bq24257_power_supply_get_property(struct 
power_supply *psy,
val->intval = bq24257_iterm_map[bq->init_data.iterm];
break;
 
+   case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+   return bq24257_get_input_current_limit(bq, val);
+
default:
return -EINVAL;
}
@@ -358,6 +402,31 @@ static int bq24257_power_supply_get_property(struct 
power_supply *psy,
return 0;
 }
 
+static int bq24257_power_supply_set_property(struct power_supply *psy,
+   enum power_supply_property prop,
+   const union power_supply_propval *val)
+{
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+
+   switch (prop) {
+   case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+   return bq24257_set_input_current_limit(bq, val);
+   default:
+   return -EINVAL;
+   }
+}
+
+static int bq24257_power_supply_property_is_writeable(struct power_supply *psy,
+   enum power_supply_property psp)
+{
+   switch (psp) {
+   case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static int bq24257_get_chip_state(struct bq24257_device *bq,
  struct bq24257_state *state)
 {
@@ -559,11 +628,14 @@ static void bq24257_handle_state_change(struct 
bq24257_device *bq,
ret = bq24257_field_write(bq, F_DPDM_EN, 1);
if (ret < 0)
goto error;
-   /* reset input current limit */
-   ret = bq24257_field_write(bq, F_IILIMIT, IILIMIT_500);
-   if (ret < 0)
-   goto error;
}
+   /*
+* When power is removed always return to the default input
+* current limit as configured during probe.
+*/
+   ret = bq24257_field_write(bq, F_IILIMIT, bq->init_data.iilimit);
+   if (ret < 0)
+   goto

[PATCH v6 02/14] power: bq24257: Remove IRQ config through stat-gpios

[Andreas Dannenberg]

At the time the driver was written GpioInt resources in ACPI were not
passed to the driver in client->irq, as opposed to DT enumeration. To
accommodate this use case, a "stat-gpios" property was introduced to
allow configuring the IRQ.

However this issue with ACPI was fixed in commit "845c877 i2c / ACPI:
Assign IRQ for devices that have GpioInt automatically" and makes this
workaround no longer necessary, hence we can remove the support for the
"stat-gpios" property and the associated code from the bq24257 driver.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 28 
 1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 5859bc7..69b53d0 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -36,7 +36,6 @@
 #define BQ24257_REG_7  0x06
 
 #define BQ24257_MANUFACTURER   "Texas Instruments"
-#define BQ24257_STAT_IRQ   "stat"
 #define BQ24257_PG_GPIO"pg"
 
 #define BQ24257_ILIM_SET_DELAY 1000/* msec */
@@ -606,19 +605,6 @@ static int bq24257_power_supply_init(struct bq24257_device 
*bq)
return 0;
 }
 
-static int bq24257_irq_probe(struct bq24257_device *bq)
-{
-   struct gpio_desc *stat_irq;
-
-   stat_irq = devm_gpiod_get_index(bq->dev, BQ24257_STAT_IRQ, 0, GPIOD_IN);
-   if (IS_ERR(stat_irq)) {
-   dev_err(bq->dev, "could not probe stat_irq pin\n");
-   return PTR_ERR(stat_irq);
-   }
-
-   return gpiod_to_irq(stat_irq);
-}
-
 static int bq24257_pg_gpio_probe(struct bq24257_device *bq)
 {
bq->pg = devm_gpiod_get_index(bq->dev, BQ24257_PG_GPIO, 0, GPIOD_IN);
@@ -740,21 +726,15 @@ static int bq24257_probe(struct i2c_client *client,
return ret;
}
 
-   if (client->irq <= 0)
-   client->irq = bq24257_irq_probe(bq);
-
-   if (client->irq < 0) {
-   dev_err(dev, "no irq resource found\n");
-   return client->irq;
-   }
-
ret = devm_request_threaded_irq(dev, client->irq, NULL,
bq24257_irq_handler_thread,
IRQF_TRIGGER_FALLING |
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
-   BQ24257_STAT_IRQ, bq);
-   if (ret)
+   "bq24257", bq);
+   if (ret) {
+   dev_err(dev, "Failed to request IRQ #%d\n", client->irq);
return ret;
+   }
 
ret = bq24257_power_supply_init(bq);
if (ret < 0)
-- 
1.9.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 v6 03/14] power: bq24257: Streamline input current limit setup

[Andreas Dannenberg]

The maximum amount of input current the charger should draw is dependent
on the power supply and should only be (re-)configured when the power
supply gets connected and disconnected. However the driver was also
lowering the bq24257's input current limit setting to 500mA when the
battery was removed and restored the previous setting according to the
power supply capabilities when the battery was reconnected although
these events are not impacting the amount of power that can be drawn
from the supply. Furthermore, a re-configuration of the input current
limit to 500mA when the battery gets disconnected is actually dangerous
if the limit was set higher previously and the system draws more than
500mA in which case the system voltage would be reduced in order to
maintain 500mA which could result in the system getting too low of a
supply to maintain operation. Last but not least the mechanism itself
used for battery re-connection detection did not work in corner cases
such as when the device's input current loop becomes active and the
bq24257 device clears its battery fault error resulting in incorrectly
reporting that the battery got reconnected.

This patches removes the impact the battery removal/insertion has on the
input current limit configured for the bq24257 and simplifies the
associated handler routine.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 69b53d0..d8939dc 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -448,14 +448,13 @@ static void bq24257_handle_state_change(struct 
bq24257_device *bq,
 {
int ret;
struct bq24257_state old_state;
-   bool reset_iilimit = false;
-   bool config_iilimit = false;
 
mutex_lock(&bq->lock);
old_state = bq->state;
mutex_unlock(&bq->lock);
 
-   if (!new_state->power_good) {/* power removed */
+   if (!new_state->power_good) {
+   dev_dbg(bq->dev, "Power removed\n");
cancel_delayed_work_sync(&bq->iilimit_setup_work);
 
/* activate D+/D- port detection algorithm */
@@ -463,26 +462,20 @@ static void bq24257_handle_state_change(struct 
bq24257_device *bq,
if (ret < 0)
goto error;
 
-   reset_iilimit = true;
-   } else if (!old_state.power_good) { /* power inserted */
-   config_iilimit = true;
-   } else if (new_state->fault == FAULT_NO_BAT) { /* battery removed */
-   cancel_delayed_work_sync(&bq->iilimit_setup_work);
-
-   reset_iilimit = true;
-   } else if (old_state.fault == FAULT_NO_BAT) {/* battery connected */
-   config_iilimit = true;
-   } else if (new_state->fault == FAULT_TIMER) { /* safety timer expired */
-   dev_err(bq->dev, "Safety timer expired! Battery dead?\n");
-   }
-
-   if (reset_iilimit) {
+   /* reset input current limit */
ret = bq24257_field_write(bq, F_IILIMIT, IILIMIT_500);
if (ret < 0)
goto error;
-   } else if (config_iilimit) {
-   schedule_delayed_work(&bq->iilimit_setup_work,
+   } else if (!old_state.power_good) {
+   dev_dbg(bq->dev, "Power inserted\n");
+   if (bq->iilimit_autoset_enable)
+   /* configure input current limit */
+   schedule_delayed_work(&bq->iilimit_setup_work,
  msecs_to_jiffies(BQ24257_ILIM_SET_DELAY));
+   } else if (new_state->fault == FAULT_NO_BAT) {
+   dev_warn(bq->dev, "Battery removed\n");
+   } else if (new_state->fault == FAULT_TIMER) {
+   dev_err(bq->dev, "Safety timer expired! Battery dead?\n");
}
 
return;
-- 
1.9.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 v6 00/14] power: bq24257: Add support for bq24250/bq24251

[Andreas Dannenberg]

This patch series extends the driver to also support bq24250/bq24251.

The bq24250/251/257 devices have a very similar feature set and are
virtually identical from a control register point of view so it made
sense to extend the existing driver rather than submitting a new driver.
In addition to the new device support the driver is also extended to
allow access to some device features previously hidden. Basic and
potentially dangerous charger config parameters affecting the actual
charging of the Li-Ion battery are only configurable through firmware
rather than sysfs properties. However some newly introduced properties
are exposed through sysfs properties as access to them may be desired
from userspace. For example, it is now possible to manually configure
the maximum current drawn from the input source to accommodate different
chargers (0.5A, 1.5A, 2.0A and so on) based on system knowledge a
userspace application may have rather than rely on the auto-detection
mechanism that may not work in all possible scenarios.

Note that most patches have dependencies on other patches in the series.

v6:
- Removed the ability to configure the IRQ through "stat-gpios"
- Allow re-configuring the input_current_limit via sysfs also when
  charger auto-detection is enabled
- Use gpiod interface for initialization as a platform device (nice
  GPIO setup simplification)
- Document all newly introduced sysfs nodes
- Streamlined/fixed/simplified charger state handling as it relates
  to battery removal/insertion and the associated handling of the
  input current limit setting
- Minor simplifications/cleanup
- Rebased onto git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-
  power-supply.git (branch "next") and completely retested

v5:
- Added patch to use the managed version of power supply register which
  also fixes a code flow issue that was introduced
- Minor fixes / consistency cleanup (Krzysztof's feedback)

v4:
- Removed configurability of the safety timer multiplier through DT

v3:
- Dropped the driver/symbol rename patch from v2 due to anticipated
  issues with upcoming bq2425x family additions
- Reverted additional mutex coverage for I2C access due to regmap
  built-in mutex protection being sufficient
- Removed support for trickle charging due to being a rare/uncommon
  use case
- Fixed most checkpatch.pl --strict alignment issues (except where
  the line length would exceed 80 chars)
- Fixed an issue with how the return value of gpio_to_desc() was
  handled
- Fixed an issue with the definition of bq24257_of_match[]
- Reordered the patch series to put the DT doc changes to the
  beginning

v2:
- Aligned DT bindings better with existing "ti,*" charger bindings
- Dropped patch that improperly reported a missing battery as a dead
  battery
- Fixed (hopefully, that is -- still waiting for my test platform)
  issue with how the private ACPI driver_data used to identify which
  bq2425x device to use
- Removed boolean DT/ACPI properties mostly by replacing them with more
  intelligent handling in the driver
- Rework/clarification of DT bindings doc
- Renamed/refactored filenames/symbols from bq24257 to bq2425x to
  better reflect that multiple devices are covered. Despite initial
  hesitation I feel this is a good opportunity for some clean-up as
  the driver is still very new in the Kernel so the change should be
  low risk. This also addresses one of Andrew Davis' feedback items.
  Plus, it makes for a nice alignment with the existing bq2415x_charger
  driver.

v1:
- Initial submission

Andreas Dannenberg (14):
  dt: power: bq24257-charger: Cover additional devices
  power: bq24257: Remove IRQ config through stat-gpios
  power: bq24257: Streamline input current limit setup
  power: bq24257: Add basic support for bq24250/bq24251
  power: bq24257: Add bit definition for temp sense enable
  power: bq24257: Allow manual setting of input current limit
  power: bq24257: Add SW-based approach for Power Good determination
  power: bq24257: Use managed power supply register
  power: bq24257: Add over voltage protection setting support
  power: bq24257: Add input DPM voltage threshold setting support
  power: bq24257: Allow input current limit sysfs access
  power: bq24257: Add various device-specific sysfs properties
  power: bq24257: Add platform data based initialization
  Documentation: power: bq24257: Document exported sysfs entries

 Documentation/ABI/testing/sysfs-class-power|  58 +++
 .../devicetree/bindings/power/bq24257.txt  |  53 ++-
 drivers/power/Kconfig  |   5 +-
 drivers/power/bq24257_charger.c| 516 ++---
 include/linux/power/bq24257_charger.h  |  25 +
 5 files changed, 577 insertions(+), 80 deletions(-)
 create mode 100644 include/linux/power/bq24257_charger.h

-- 
1.9.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 

Re: [PATCH v3 1/2] fsl: Add binding for RCPM

[Scott Wood]

On Thu, 2015-09-24 at 21:38 -0500, Wang Dongsheng-B40534 wrote:
> > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > +---
> > > +Required rcpm-wakeup property should be added to a device node if the
> > > device
> > > +can be used as a wakeup source.
> > > +
> > > +  - rcpm-wakeup: The value of the property consists of cells, the 
> > > number of
> > > + cells defined in "fsl,#rcpm-wakeup-cells". The first cell is a 
> > > pointer
> > > + to the rcpm node, the second cell is the bit mask that should be 
> > > set
> > > + in IPPDEXPCR0, and the third cell is for IPPDEXPCR1, and so on.
> > 
> > The phandle should not be included in the cell count.
> > 
> 
> Yes, the first cell "&rcpm" should be in the cell count, right?

No.  None of the other #foo-cells work that way.

-Scott

--
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 v1 1/3] clocksource: rockchip: Make the driver more readability and compatible

[Caesar Wang]

Daniel,

在 2015年09月25日 08:25, Daniel Lezcano 写道:


Hi Caesar,

so thinking a bit more about this patch. I would like to split it into 
two. One fixing the NO_IRQ and another fixing the dsb().


IIUC, the ARMv8 support is not yet ready and dsb() is not necessary as 
a fix for the previous kernel version. However, the timer is used with 
the ARMv7 boards and the NO_IRQ should be merged into tip-urgent.


I already done the fix and I am ready to submit it (for the timer 
keystone also). So I suggest your resend the dsb() fix only.


Regarding the indentation, I prefer you do that in a separate patch by 
cleaning up the macros (if relevant) or send the patch to trivial@




I know the indentation is trivial for this driver, but I just send the 
patch v2.



  -- Daniel

On 09/22/2015 07:15 AM, Caesar Wang wrote:

Hi  Heiko,

在 2015年09月22日 22:00, Heiko Stübner 写道:

Hi Caesar,

Am Freitag, 18. September 2015, 16:51:09 schrieb Caesar Wang:

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.

logs:
...
drivers/clocksource/rockchip_timer.c:156:13: error: 'NO_IRQ' 
undeclared
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at operand 
1 --

`dsb`
...

The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).

NO_IRQ definition is missing for ARM64, since NO_IRQ being -1 is a
legacy thing for ARM - all ARM drivers are supposed to be converted to
use <= 0 or == 0 to detect invalid IRQs, and _eventually_ once all 
users

are gone, NO_IRQ deleted. Modern drivers should _all_ be using !irq to
detect invalid IRQs, and not using NO_IRQ.

Meanwhile, I change a bit to make the code more readability for driver
when I check the code style.

Signed-off-by: Caesar Wang 
---

Changes in v1:
- As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'.

  drivers/clocksource/rockchip_timer.c | 29
+++--
  1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c
b/drivers/clocksource/rockchip_timer.c index bb2c2b0..e1af449 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -17,16 +17,16 @@

  #define TIMER_NAME "rk_timer"

-#define TIMER_LOAD_COUNT0 0x00
-#define TIMER_LOAD_COUNT1 0x04
-#define TIMER_CONTROL_REG 0x10
-#define TIMER_INT_STATUS 0x18
+#define TIMER_LOAD_COUNT00x00
+#define TIMER_LOAD_COUNT10x04
+#define TIMER_CONTROL_REG0x10
+#define TIMER_INT_STATUS0x18

-#define TIMER_DISABLE 0x0
-#define TIMER_ENABLE 0x1
-#define TIMER_MODE_FREE_RUNNING (0 << 1)
-#define TIMER_MODE_USER_DEFINED_COUNT (1 << 1)
-#define TIMER_INT_UNMASK (1 << 2)
+#define TIMER_DISABLE(0 << 0)
+#define TIMER_ENABLE(1 << 0)
+#define TIMER_MODE_FREE_RUNNING(0 << 1)
+#define TIMER_MODE_USER_DEFINED_COUNT(1 << 1)
+#define TIMER_INT_UNMASK(1 << 2)

not sure how Daniel sees this, but those could count as "unrelated
change", as
they have nothing to do with the arm64 build-fixes.


Yep, it's no related to the arm64 uild fixes.
I only make the code more readability for driver.




  struct bc_timer {
  struct clock_event_device ce;
@@ -49,14 +49,14 @@ static inline void __iomem *rk_base(struct
clock_event_device *ce) static inline void rk_timer_disable(struct
clock_event_device *ce) {
  writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
-dsb();
+dsb(sy);
  }

  static inline void rk_timer_enable(struct clock_event_device *ce, 
u32

flags) {
  writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
 rk_base(ce) + TIMER_CONTROL_REG);
-dsb();
+dsb(sy);
  }

  static void rk_timer_update_counter(unsigned long cycles,
@@ -64,13 +64,13 @@ static void rk_timer_update_counter(unsigned long
cycles, {
  writel_relaxed(cycles, rk_base(ce) + TIMER_LOAD_COUNT0);
  writel_relaxed(0, rk_base(ce) + TIMER_LOAD_COUNT1);
-dsb();
+dsb(sy);
  }

  static void rk_timer_interrupt_clear(struct clock_event_device *ce)
  {
  writel_relaxed(1, rk_base(ce) + TIMER_INT_STATUS);
-dsb();
+dsb(sy);
  }

  static inline int rk_timer_set_next_event(unsigned long cycles,
@@ -148,7 +148,7 @@ static void __init rk_timer_init(struct
device_node *np)
bc_timer.freq = clk_get_rate(timer_clk);

  irq = irq_of_parse_and_map(np, 0);
-if (irq == NO_IRQ) {
+if (!irq) {
  pr_err("Failed to map interrupts for '%s'\n", TIMER_NAME);
  return;
  }
@@ -173,4 +173,5 @@ static void __init rk_timer_init(struct
device_node *np)

  clockevents_config_and_register(ce, bc_timer.freq, 1, UINT_MAX);
  }
+

unnecessary addition of a blank line (same reasons as above)


It's the same reason with the above.

CHECK: Please use a blank line after function/struct/union/enum
declarations
#176: FILE: rockchip_timer.c:176:
+}
+CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", 
rk

[PATCH v2 3/4] arm64: Enable the timer on Rockchip architecture

[Caesar Wang]

On the RK3368 SoC, support the APB timers for rockchip platform.

Signed-off-by: Caesar Wang 
---

Changes in v2: None
Changes in v1: None

 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 23800a1..0dae08d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -57,6 +57,7 @@ config ARCH_ROCKCHIP
select ARCH_REQUIRE_GPIOLIB
select PINCTRL
select PINCTRL_ROCKCHIP
+   select ROCKCHIP_TIMER
help
  This enables support for the ARMv8 based Rockchip chipsets,
  like the RK3368.
-- 
1.9.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 v2 1/4] clocksource: rockchip: Make the driver more compatible

[Caesar Wang]

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.

Says:
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand 1 --
`dsb`
...

The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).The "sy" param
is the default which you are allow to omit, so on arm32 dsb()and dsb(sy)
are the same.

Signed-off-by: Caesar Wang 
---

Changes in v2:
- As Heiko/Daniel comments, let's split it into two patch.

Changes in v1:
- As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'.

 drivers/clocksource/rockchip_timer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c 
b/drivers/clocksource/rockchip_timer.c
index bb2c2b0..3ace7ac 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -49,14 +49,14 @@ static inline void __iomem *rk_base(struct 
clock_event_device *ce)
 static inline void rk_timer_disable(struct clock_event_device *ce)
 {
writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
-   dsb();
+   dsb(sy);
 }
 
 static inline void rk_timer_enable(struct clock_event_device *ce, u32 flags)
 {
writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
   rk_base(ce) + TIMER_CONTROL_REG);
-   dsb();
+   dsb(sy);
 }
 
 static void rk_timer_update_counter(unsigned long cycles,
@@ -64,13 +64,13 @@ static void rk_timer_update_counter(unsigned long cycles,
 {
writel_relaxed(cycles, rk_base(ce) + TIMER_LOAD_COUNT0);
writel_relaxed(0, rk_base(ce) + TIMER_LOAD_COUNT1);
-   dsb();
+   dsb(sy);
 }
 
 static void rk_timer_interrupt_clear(struct clock_event_device *ce)
 {
writel_relaxed(1, rk_base(ce) + TIMER_INT_STATUS);
-   dsb();
+   dsb(sy);
 }
 
 static inline int rk_timer_set_next_event(unsigned long cycles,
-- 
1.9.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 v2 2/4] clocksource: rockchip: trivial: Make the driver more readability

[Caesar Wang]

Let's checkstyle to clean up the macros with such trivial details.

Signed-off-by: Caesar Wang 
---

Changes in v2: None
Changes in v1: None

 drivers/clocksource/rockchip_timer.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c 
b/drivers/clocksource/rockchip_timer.c
index 3ace7ac..9ed662a 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -17,16 +17,16 @@
 
 #define TIMER_NAME "rk_timer"
 
-#define TIMER_LOAD_COUNT0 0x00
-#define TIMER_LOAD_COUNT1 0x04
-#define TIMER_CONTROL_REG 0x10
-#define TIMER_INT_STATUS 0x18
+#define TIMER_LOAD_COUNT0  0x00
+#define TIMER_LOAD_COUNT1  0x04
+#define TIMER_CONTROL_REG  0x10
+#define TIMER_INT_STATUS   0x18
 
-#define TIMER_DISABLE 0x0
-#define TIMER_ENABLE 0x1
-#define TIMER_MODE_FREE_RUNNING (0 << 1)
-#define TIMER_MODE_USER_DEFINED_COUNT (1 << 1)
-#define TIMER_INT_UNMASK (1 << 2)
+#define TIMER_DISABLE  0x0
+#define TIMER_ENABLE   0x1
+#define TIMER_MODE_FREE_RUNNING(0 << 1)
+#define TIMER_MODE_USER_DEFINED_COUNT  (1 << 1)
+#define TIMER_INT_UNMASK   (1 << 2)
 
 struct bc_timer {
struct clock_event_device ce;
@@ -173,4 +173,5 @@ static void __init rk_timer_init(struct device_node *np)
 
clockevents_config_and_register(ce, bc_timer.freq, 1, UINT_MAX);
 }
+
 CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", rk_timer_init);
-- 
1.9.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 v2 4/4] arm64: dts: rockchip: Add the needed timer for RK3368 SoC

[Caesar Wang]

There is a need of a broadcast timer in this case to ensure proper
wakeup when the cpus are in sleep mode and a timer expires.

Signed-off-by: Caesar Wang 
---

Changes in v2: None
Changes in v1:
- As the Heiko comments, add the "rockchip,rk3368-timer" for timer.
  Although the 'rockchip,rk3288-timer' is working for RK3368, need to add the
  'rockchip,rk3368-timer' for the rk3368-spec timer in the future.

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a712bea..c4b3870 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -214,6 +214,12 @@
(GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
};
 
+   timer@ff81 {
+   compatible = "rockchip,rk3368-timer", "rockchip,rk3288-timer";
+   reg = <0x0 0xff81 0x0 0x20>;
+   interrupts = ;
+   };
+
xin24m: oscillator {
compatible = "fixed-clock";
clock-frequency = <2400>;
-- 
1.9.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 v2 0/4] Support the timer on RK3368 SoC

[Caesar Wang]

Timer0~11 count up from zero to a programmed value and
generate an interrupt when the count reaches the programmed value.

TIMER0, TIMER1, TIMER2, Timer3, TIMER4 and TIMER5 are in the CPU
subsystem, using timer ch0 ~ ch5 respectively. The timer clock is 24MHz
OSC.

This series are found on RK3368 SoC, verified on rk3368 evb board.


Changes in v2:
- As Heiko/Daniel comments, let's split it into two patch.

Changes in v1:
- As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'.
- As the Heiko comments, add the "rockchip,rk3368-timer" for timer.
  Although the 'rockchip,rk3288-timer' is working for RK3368, need to add the
  'rockchip,rk3368-timer' for the rk3368-spec timer in the future.

Caesar Wang (4):
  clocksource: rockchip: Make the driver more compatible
  clocksource: rockchip: trivial: Make the driver more readability
  arm64: Enable the timer on Rockchip architecture
  arm64: dts: rockchip: Add the needed timer for RK3368 SoC

 arch/arm64/Kconfig.platforms |  1 +
 arch/arm64/boot/dts/rockchip/rk3368.dtsi |  6 ++
 drivers/clocksource/rockchip_timer.c | 27 ++-
 3 files changed, 21 insertions(+), 13 deletions(-)

-- 
1.9.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 0/3] i2c: uniphier: add two I2C controller drivers for UniPhier SoC platform

[Masahiro Yamada]

Hi Wolfram,


Could you have some time for reviewing this series?
Perhaps, after ELCE?


2015-07-30 17:12 GMT+09:00 Masahiro Yamada :
>
> This series adds two I2C controller drivers.
> (they are completely different IPs.)
>
> The first one is a very simple FIFO-less I2C controller,
> which is used on some older UniPhier SoCs.
>
> The other one is higher-performance I2C controller with TX/RX FIFO,
> used on newer UniPhier SoCs.
>
>
>
> Masahiro Yamada (3):
>   i2c: uniphier: add UniPhier FIFO-less I2C driver
>   i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver
>   i2c: uniphier: add bindings for UniPhier I2C controllers
>
>  .../devicetree/bindings/i2c/i2c-uniphier.txt   |  46 ++
>  drivers/i2c/busses/Kconfig |  16 +
>  drivers/i2c/busses/Makefile|   2 +
>  drivers/i2c/busses/i2c-uniphier-f.c| 589 
> +
>  drivers/i2c/busses/i2c-uniphier.c  | 446 
>  5 files changed, 1099 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
>  create mode 100644 drivers/i2c/busses/i2c-uniphier-f.c
>  create mode 100644 drivers/i2c/busses/i2c-uniphier.c
>
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Best Regards
Masahiro Yamada
--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Florian Fainelli]

On 24/09/15 12:17, Russell King - ARM Linux wrote:
> Hi,
> 
> The third version of this series fixes the build error which David
> identified, and drops the broken changes for the Cavium Thunger BGX
> ethernet driver as this driver requires some complex changes to
> resolve the leakage - and this is best done by people who can test
> the driver.
> 
> Compared to v2, the only patch which has changed is patch 6
>   "net: fix phy refcounting in a bunch of drivers"
> 
> I _think_ I've been able to build-test all the drivers touched by
> that patch to some degree now, though several of them needed the
> Kconfig hacked to allow it (not all had || COMPILE_TEST clause on
> their dependencies.)

Tested-by: Florian Fainelli 
Reviewed-by: Florian Fainelli 

Thanks for fixing that.

> 
> Previous cover letters below:
> 
> This is the second version of the series, with the comments David had
> on the first patch fixed up.  Original series description with updated
> diffstat below.
> 
> While looking at the DSA code, I noticed we have a
> of_find_net_device_by_node(), and it looks like users of that are
> similarly buggy - it looks like net/dsa/dsa.c is the only user.  Fix
> that too.
> 
> 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.
> 
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 24 ++
>  drivers/net/ethernet/freescale/gianfar.c   |  6 ++-
>  drivers/net/ethernet/freescale/ucc_geth.c  |  8 +++-
>  drivers/net/ethernet/marvell/mvneta.c  |  2 +
>  drivers/net/ethernet/xilinx/xilinx_emaclite.c  |  2 +
>  drivers/net/phy/fixed_phy.c|  2 +-
>  drivers/net/phy/mdio-mux.c | 19 +---
>  drivers/net/phy/mdio_bus.c | 24 ++
>  drivers/net/phy/phy_device.c   | 62 
> --
>  drivers/of/of_mdio.c   | 27 +--
>  include/linux/phy.h|  6 ++-
>  net/core/net-sysfs.c   |  9 
>  net/dsa/dsa.c  | 41 ++---
>  13 files changed, 181 insertions(+), 51 deletions(-)
> 


-

Re: [PATCH] ARM: dts: move aliases back to .dts in Cygnus

[Florian Fainelli]

On 24/09/15 15:21, Ray Jui wrote:
> Move aliases from bcm-cygnus.dtsi back to individual .dts files. Also
> clean up the chosen node to have the stdout-path using the proper alias
> 
> Signed-off-by: Ray Jui 

Applied to devicetree/next, 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

[PATCH v2 2/5] dt-binding: soc: qcom: Introduce qcom,smp2p binding documentation

[Bjorn Andersson]

Introduce binding documentation for the Qualcomm Shared Memory Point 2 Point
protocol.

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- No longer representing outgoing state as gpio-controller

 .../devicetree/bindings/soc/qcom/qcom,smp2p.txt| 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
new file mode 100644
index ..5cc82b8353d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
@@ -0,0 +1,104 @@
+Qualcomm Shared Memory Point 2 Point binding
+
+The Shared Memory Point to Point (SMP2P) protocol facilitates communication of
+a single 32-bit value between two processors.  Each value has a single writer
+(the local side) and a single reader (the remote side).  Values are uniquely
+identified in the system by the directed edge (local processor ID to remote
+processor ID) and a string identifier.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,smp2p"
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: one entry specifying the smp2p notification interrupt
+
+- qcom,ipc:
+   Usage: required
+   Value type: 
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the remote end of the smp2p edge:
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,smem:
+   Usage: required
+   Value type: 
+   Definition: two identifiers of the inbound and outbound smem items used
+   for this edge
+
+- qcom,local-pid:
+   Usage: required
+   Value type: 
+   Definition: specifies the identfier of the local endpoint of this edge
+
+- qcom,remote-pid:
+   Usage: required
+   Value type: 
+   Definition: specifies the identfier of the remote endpoint of this edge
+
+= SUBNODES
+Each SMP2P pair contain a set of inbound and outbound entries, these are
+described in subnodes of the smp2p device node. The node names are not
+important.
+
+- qcom,entry-name:
+   Usage: required
+   Value type: 
+   Definition: specifies the name of this entry, for inbound entries this
+   will be used to match against the remotely allocated entry
+   and for outbound entries this name is used for allocating
+   entries
+
+- interrupt-controller:
+   Usage: required for incoming entries
+   Value type: 
+   Definition: marks the entry as inbound; the node should be specified
+   as a two cell interrupt-controller as defined in
+   "../interrupt-controller/interrupts.txt"
+   If not specified this node will denote the outgoing entry
+
+- #interrupt-cells:
+   Usage: required for incoming entries
+   Value type: 
+   Definition: must be 2 - denoting the bit in the entry and IRQ flags
+
+- #qcom,state-cells:
+   Usage: required for outgoing entries
+   Value type: 
+   Definition: must be 1 - denoting the bit in the entry
+
+= EXAMPLE
+The following example shows the SMP2P setup with the wireless processor,
+defined from the 8974 apps processor's point-of-view. It encompasses one
+inbound and one outbound entry:
+
+wcnss-smp2p {
+   compatible = "qcom,smp2p";
+   qcom,smem = <431>, <451>;
+
+   interrupts = <0 143 1>;
+
+   qcom,ipc = <&apcs 8 18>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <4>;
+
+   wcnss_smp2p_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+
+   #qcom,state-cells = <1>;
+   };
+
+   wcnss_smp2p_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
-- 
1.8.2.2

--
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 v2 0/5] Qualcomm Shared Memory State Machines

[Bjorn Andersson]

This series implements the two different mechanisms for propagating single bit
state information, used on the various Qualcomm platforms.

The system was traditionally used by the modem and application processor to
convey information about boot progress, power states, error handling and so on.
This was implemented as SMSM, with status bits representing a single local
state.

As the complexity of the SoC grew the state bits array grew and the need for
targeting specific state information at specific remote processors appeared.
SMP2P solves this by having separate shared memory regions per processor-pair.

This state information is e.g. used to convey progress and status of remote
firmware loading. Individual bits maps to various stages of the boot and error
states.

Changed since v1:
- The series moved away from representing outgoing bits as gpios

Bjorn Andersson (5):
  dt-binding: soc: qcom: Add Qualcomm SMSM device tree documentation
  dt-binding: soc: qcom: Introduce qcom,smp2p binding documentation
  soc: qcom: Introduce common SMEM state machine code
  soc: qcom: smsm: Add driver for Qualcomm SMSM
  soc: qcom: smp2p: Qualcomm Shared Memory Point to Point

 .../devicetree/bindings/soc/qcom/qcom,smp2p.txt| 104 
 .../devicetree/bindings/soc/qcom/qcom,smsm.txt | 104 
 drivers/soc/qcom/Kconfig   |  19 +
 drivers/soc/qcom/Makefile  |   3 +
 drivers/soc/qcom/smem_state.c  | 201 +++
 drivers/soc/qcom/smp2p.c   | 578 +++
 drivers/soc/qcom/smsm.c| 625 +
 include/linux/soc/qcom/smem_state.h|  18 +
 8 files changed, 1652 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
 create mode 100644 drivers/soc/qcom/smem_state.c
 create mode 100644 drivers/soc/qcom/smp2p.c
 create mode 100644 drivers/soc/qcom/smsm.c
 create mode 100644 include/linux/soc/qcom/smem_state.h

-- 
1.8.2.2

--
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 v2 1/5] dt-binding: soc: qcom: Add Qualcomm SMSM device tree documentation

[Bjorn Andersson]

This documents a device tree binding for the Qualcomm Shared Memory
State Machine.

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- No longer representing outgoing state as gpio-controller

 .../devicetree/bindings/soc/qcom/qcom,smsm.txt | 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
new file mode 100644
index ..a6634c70850d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
@@ -0,0 +1,104 @@
+Qualcomm Shared Memory State Machine
+
+The Shared Memory State Machine facilitates broadcasting of single bit state
+information between the processors in a Qualcomm SoC. Each processor is
+assigned 32 bits of state that can be modified. A processor can through a
+matrix of bitmaps signal subscription of notifications upon changes to a
+certain bit owned by a certain remote processor.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,smsm"
+
+- qcom,ipc-N:
+   Usage: required
+   Value type: 
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the N:th remote processor
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,local-host:
+   Usage: optional
+   Value type: 
+   Definition: identifier of the local processor in the list of hosts, or
+   in other words specifier of the column in the subscription
+   matrix representing the local processor
+   defaults to host 0
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= SUBNODES
+Each processor's state bits are described by a subnode of the smsm device node.
+Nodes can either be flagged as an interrupt-controller to denote a remote
+processor's state bits or the local processors bits.  The node names are not
+important.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies the offset, in words, of the first bit for this
+   entry
+
+- #qcom,state-cells:
+   Usage: required for local entry
+   Value type: 
+   Definition: must be 1 - denotes bit number
+
+- interrupt-controller:
+   Usage: required for remote entries
+   Value type: 
+   Definition: marks the entry as a interrupt-controller and the state bits
+   to belong to a remote processor
+
+- #interrupt-cells:
+   Usage: required for remote entries
+   Value type: 
+   Definition: must be 2 - denotes bit number and IRQ flags
+
+- interrupts:
+   Usage: required for remote entries
+   Value type: 
+   Definition: one entry specifying remote IRQ used by the remote processor
+   to signal changes of its state bits
+
+
+= EXAMPLE
+The following example shows the SMEM setup for controlling properties of the
+wireless processor, defined from the 8974 apps processor's point-of-view. It
+encompasses one outbound entry and the outgoing interrupt for the wireless
+processor.
+
+smsm {
+   compatible = "qcom,smsm";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   qcom,ipc-3 = <&apcs 8 19>;
+
+   apps_smsm: apps@0 {
+   reg = <0>;
+
+   #qcom,state-cells = <1>;
+   };
+
+   wcnss_smsm: wcnss@7 {
+   reg = <7>;
+   interrupts = <0 144 1>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
-- 
1.8.2.2

--
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] pci-rcar-gen2: add R8A7794 support

[Simon Horman]

On Thu, Sep 24, 2015 at 03:07:21PM -0500, Bjorn Helgaas wrote:
> On Sat, Sep 12, 2015 at 02:06:09AM +0300, Sergei Shtylyov wrote:
> > Add Renesas R8A7794 SoC support to the Renesas R-Car gen2 PCI driver.
> > 
> > Signed-off-by: Sergei Shtylyov 
> 
> Applied with Simon's ack to for-linus for v4.3, thanks!
> 
> I applied this for v4.3 instead of v4.4 because this is new hardware
> and I think the chance of breaking anything is minimal.

Thanks! Your logic for queueing this up for v4.3 sounds
entirely reasonable to me.
--
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] ARM: dts: >: fix address translation for pbias

[Tony Lindgren]

* Kishon Vijay Abraham I  [150904 05:12]:
> "ARM: dts: : add minimal l4 bus
> layout with control module support" moved pbias_regulator dt node
> from being a child node of ocp to be the child node of
> 'syscon'. Since 'syscon' doesn't have the 'ranges' property,
> address translation fails while trying to convert the address
> to resource. Fix it here by populating 'ranges' property in
> syscon dt node.

I'm applying the following version of this with omap3 device
tree booting fixed for MMC.

Regards,

Tony

8<---From 9a5e3f27d1b8ca349b79e8b5fe1874db6f45 Mon Sep 
17 00:00:00 2001
From: Kishon Vijay Abraham I 
Date: Fri, 4 Sep 2015 17:38:24 +0530
Subject: [PATCH] ARM: dts: fix omap2+ address translation for pbias

"ARM: dts: : add minimal l4 bus
layout with control module support" moved pbias_regulator dt node
from being a child node of ocp to be the child node of
'syscon'. Since 'syscon' doesn't have the 'ranges' property,
address translation fails while trying to convert the address
to resource. Fix it here by populating 'ranges' property in
syscon dt node.

Fixes: 72b10ac00eb1 ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support")

Fixes: 7415b0b4c645 ("ARM: dts: omap4: add minimal l4 bus layout
with control module support")

Fixes: ed8509edddeb ("ARM: dts: omap5: add minimal l4 bus
layout with control module support")

Fixes: d919501feffa ("ARM: dts: dra7: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I 
[t...@atomide.com: fixed omap3 pbias to work]
Signed-off-by: Tony Lindgren 

--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -120,6 +120,7 @@
reg = <0x0 0x1400>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x0 0x1400>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -56,6 +56,7 @@
reg = <0x270 0x240>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x270 0x240>;
 
scm_clocks: clocks {
#address-cells = <1>;
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,10 +113,22 @@
};
 
scm_conf: scm_conf@270 {
-   compatible = "syscon";
+   compatible = "syscon", "simple-bus";
reg = <0x270 0x330>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x270 0x330>;
+
+   pbias_regulator: pbias_regulator {
+   compatible = "ti,pbias-omap3", 
"ti,pbias-omap";
+   reg = <0x2b0 0x4>;
+   syscon = <&scm_conf>;
+   pbias_mmc_reg: 
pbias_mmc_omap2430 {
+   regulator-name = 
"pbias_mmc_omap2430";
+   regulator-min-microvolt 
= <180>;
+   regulator-max-microvolt 
= <300>;
+   };
+   };
 
scm_clocks: clocks {
#address-cells = <1>;
@@ -202,17 +214,6 @@
dma-requests = <96>;
};
 
-   pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap3", "ti,pbias-omap";
-   reg = <0x2b0 0x4>;
-   syscon = <&scm_conf>;
-   pbias_mmc_reg: pbias_mmc_omap2430 {
-   regulator-name = "pbias_mmc_omap2430";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <300>;
-   };
-   };
-
gpio1: gpio@4831 {
compatible = "ti,omap3-gpio";
reg = <0x4831 0x200>;
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,7 @@
reg = <0x5a0 0x170>;
   

Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver

[Timur Tabi]

Alexander Popov wrote:

+struct mpc512x_lpbfifo_request {
+   phys_addr_t bus_phys;   /* physical address of some device on LPB */


Is this a phys_addr_t or a dma_addr_t?  It can't be both a physical 
address and a bus address.



+   void *ram_virt; /* virtual address of some region in RAM */
+   u32 size;
+   enum lpb_dev_portsize portsize;
+   enum mpc512x_lpbfifo_req_dir dir;
+   void (*callback)(struct mpc512x_lpbfifo_request *);
+};
+
+int mpc512x_lpbfifo_submit(struct mpc512x_lpbfifo_request *req);
+
  #endif /* __ASM_POWERPC_MPC5121_H__ */
diff --git a/arch/powerpc/platforms/512x/Kconfig 
b/arch/powerpc/platforms/512x/Kconfig
index 48bf38d..f09016f 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -10,6 +10,12 @@ config PPC_MPC512x
select USB_EHCI_BIG_ENDIAN_MMIO if USB_EHCI_HCD
select USB_EHCI_BIG_ENDIAN_DESC if USB_EHCI_HCD

+config MPC512x_LPBFIFO
+   tristate "MPC512x LocalPlus Bus FIFO driver"
+   depends on PPC_MPC512x && MPC512X_DMA
+   help
+ Enable support for Freescale MPC512x LocalPlus Bus FIFO (SCLPC).
+
  config MPC5121_ADS
bool "Freescale MPC5121E ADS"
depends on PPC_MPC512x
diff --git a/arch/powerpc/platforms/512x/Makefile 
b/arch/powerpc/platforms/512x/Makefile
index 0169312..f47d422 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_COMMON_CLK)+= clock-commonclk.o
  obj-y += mpc512x_shared.o
  obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
  obj-$(CONFIG_MPC512x_GENERIC) += mpc512x_generic.o
+obj-$(CONFIG_MPC512x_LPBFIFO)  += mpc512x_lpbfifo.o
  obj-$(CONFIG_PDM360NG)+= pdm360ng.o
diff --git a/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c 
b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
new file mode 100644
index 000..e6f2c6b
--- /dev/null
+++ b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
@@ -0,0 +1,560 @@
+/*
+ * The driver for Freescale MPC512x LocalPlus Bus FIFO
+ * (called SCLPC in the Reference Manual).
+ *
+ * Copyright (C) 2013-2015 Alexander Popov.
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "mpc512x_lpbfifo"
+
+struct cs_range {
+   u32 csnum;
+   u32 base; /* must be zero */
+   u32 addr;
+   u32 size;
+};
+
+static struct lpbfifo_data {
+   spinlock_t lock; /* for protecting lpbfifo_data */
+   phys_addr_t regs_phys;
+   resource_size_t regs_size;
+   struct mpc512x_lpbfifo __iomem *regs;
+   int irq;
+   struct cs_range *cs_ranges;
+   size_t cs_n;
+   struct dma_chan *chan;
+   struct mpc512x_lpbfifo_request *req;
+   dma_addr_t ram_bus_addr;
+   bool wait_lpbfifo_irq;
+   bool wait_lpbfifo_callback;
+} lpbfifo;
+
+/*
+ * A data transfer from RAM to some device on LPB is finished
+ * when both mpc512x_lpbfifo_irq() and mpc512x_lpbfifo_callback()
+ * have been called. We execute the callback registered in
+ * mpc512x_lpbfifo_request just after that.
+ * But for a data transfer from some device on LPB to RAM we don't enable
+ * LPBFIFO interrupt because clearing MPC512X_SCLPC_SUCCESS interrupt flag
+ * automatically disables LPBFIFO reading request to the DMA controller
+ * and the data transfer hangs. So the callback registered in
+ * mpc512x_lpbfifo_request is executed at the end of 
mpc512x_lpbfifo_callback().
+ */
+
+/*
+ * mpc512x_lpbfifo_irq - IRQ handler for LPB FIFO
+ */
+static irqreturn_t mpc512x_lpbfifo_irq(int irq, void *param)
+{
+   struct device *d = (struct device *)param;


Please use the variable name 'dev' instead of 'd', for consistency.


+   struct mpc512x_lpbfifo_request *req = lpbfifo.req;
+   unsigned long flags;
+   u32 status;
+
+   spin_lock_irqsave(&lpbfifo.lock, flags);
+
+   if (!lpbfifo.regs)
+   goto end0;
+
+   if (!req || req->dir == MPC512X_LPBFIFO_REQ_DIR_READ) {
+   dev_err(d, "bogus LPBFIFO IRQ\n");
+   goto end0;
+   }


So this might be an obscure bug.  The code says that "req = lpbfifo.req" 
above.  However, it doesn't know that this block is in a critical 
section, so it will initialize 'req' not on the top line of the 
function, but rather right here.  That means that although you think 
that you're initializing 'req' before the spin_lock_irqsave(), the code 
might actually initialize it after the spin_lock_irqsave().


My suggestion is that you explicitly initialize 'req' after 
spin_lock_irqsave().  Or better yet, don't use 'req' and explicitly 
reference lpbfifo.req every time.



+
+   status = in_be32(&lpbfifo.regs->status);
+   if (status != MPC512X_SCLPC_SUCCESS) {
+   dev_err(d, "DMA transfer between RAM and peripheral fa

Re: [PATCH 1/6] extcon: arizona: Add device binding to enable ADC mode micdet

[Chanwoo Choi]

Hi Charles,

On 2015년 09월 16일 18:56, Charles Keepax wrote:
> Add a simple boolean binding to turn on and off the use of ADC
> microphone detection mode to determine 3/4 pole jack.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/extcon/extcon-arizona.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 4479781..869a920 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1227,6 +1227,9 @@ static int arizona_extcon_device_get_pdata(struct 
> arizona *arizona)
>   pdata->micd_force_micbias = device_property_read_bool(arizona->dev,
>   "wlf,micd-force-micbias");
>  
> + pdata->micd_software_compare = device_property_read_bool(arizona->dev,
> + "wlf,micd-software-compare");
> +
>   return 0;
>  }
>  
> 

Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi

--
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/6] extcon: arizona: Add device binding for the general purpose switch

[Chanwoo Choi]

Hi Charles,

On 2015년 09월 16일 18:56, Charles Keepax wrote:
> The switch is generally used in conjunction with the MICDET clamp to
> suppress pops and clicks associated with jack insertion. This patch adds
> a binding that allows the user to select the mode of operation for this
> switch.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/extcon/extcon-arizona.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 869a920..5b4bc2f 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1230,6 +1230,8 @@ static int arizona_extcon_device_get_pdata(struct 
> arizona *arizona)
>   pdata->micd_software_compare = device_property_read_bool(arizona->dev,
>   "wlf,micd-software-compare");
>  
> + device_property_read_u32(arizona->dev, "wlf,gpsw", &pdata->gpsw);
> +
>   return 0;
>  }
>  
> 

Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi

--
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 4/6] extcon: arizona: Add device binding for second jack detect pin on GPIO5

[Chanwoo Choi]

Hi Charles,

I have one comment.
I think current extcon-arizona.c has the many platform data
so, extcon-arizona.c use the too much if statement to support each feature
for different wolfsonmicro codec. I think it cause the complicated code.

For example,
You may use 'struct of_device_id' as following. You used already this method
on drivers/mfd/arizona-core.c. If you separate the function of each wm 
arizona,
it makes improved readability for extcon-arizona.c and some user will use 
extcon-arizora
more easily.

struct arizona_extcon_data {
void (*init)(...);
void (*irq_handler)(...);
... 
};

struct arizona_extcon_data wm8994_data {
.init = wm8994_extcon_init,
.irq_handler = wm8994_extcon_irq_handler;
...
};

static const struct of_device_id arizona_extcon_dt_match[] = {
{
.compatible = "wm8994-arizona-extcon",
.data = (void *)wm8994_data;
}, {
.compatible = "wm-arizona-extcon",
.data = (void *)wm_data;
}, 
};

I expect that you will revise the arizona-extcon.c driver on next time.

Thanks,
Chanwoo Choi

On 2015년 09월 16일 18:56, Charles Keepax wrote:
> Some Arizona devices have the option to use the GPIO5 pin as a second
> jack detection pin. This patch adds device bindings to specify to the
> driver that it should use this 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 
> Acked-by: Chanwoo Choi 
> ---
>  drivers/extcon/extcon-arizona.c |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index dc1910d..992f80e 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1235,6 +1235,11 @@ static int arizona_extcon_device_get_pdata(struct 
> arizona *arizona)
>  
>   device_property_read_u32(arizona->dev, "wlf,gpsw", &pdata->gpsw);
>  
> + pdata->jd_gpio5 = device_property_read_bool(arizona->dev,
> + "wlf,use-jd-gpio");
> + pdata->jd_gpio5_nopull = device_property_read_bool(arizona->dev,
> + "wlf,use-jd-gpio-nopull");
> +
>   return 0;
>  }
>  
> 

--
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 v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()

[Timur Tabi]

Alexander Popov wrote:

Initialize Freescale MPC512x DMA driver with subsys_initcall()
to allow the depending drivers to call dma_request_slave_channel()
during their probe.

Signed-off-by: Alexander Popov


Is there any way we can use -EPROBEDEFER instead?
--
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 v3 2/3] powerpc/512x: add a device tree binding for LocalPlus Bus FIFO

[Timur Tabi]

Alexander Popov wrote:

+- dma-names: should be "rx-tx";


Why bother, if it can only be one value?
--
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 v1 1/3] clocksource: rockchip: Make the driver more readability and compatible

[Daniel Lezcano]

Hi Caesar,

so thinking a bit more about this patch. I would like to split it into 
two. One fixing the NO_IRQ and another fixing the dsb().


IIUC, the ARMv8 support is not yet ready and dsb() is not necessary as a 
fix for the previous kernel version. However, the timer is used with the 
ARMv7 boards and the NO_IRQ should be merged into tip-urgent.


I already done the fix and I am ready to submit it (for the timer 
keystone also). So I suggest your resend the dsb() fix only.


Regarding the indentation, I prefer you do that in a separate patch by 
cleaning up the macros (if relevant) or send the patch to trivial@


  -- Daniel

On 09/22/2015 07:15 AM, Caesar Wang wrote:

Hi  Heiko,

在 2015年09月22日 22:00, Heiko Stübner 写道:

Hi Caesar,

Am Freitag, 18. September 2015, 16:51:09 schrieb Caesar Wang:

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.

logs:
...
drivers/clocksource/rockchip_timer.c:156:13: error: 'NO_IRQ' undeclared
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand 1 --
`dsb`
...

The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).

NO_IRQ definition is missing for ARM64, since NO_IRQ being -1 is a
legacy thing for ARM - all ARM drivers are supposed to be converted to
use <= 0 or == 0 to detect invalid IRQs, and _eventually_ once all users
are gone, NO_IRQ deleted. Modern drivers should _all_ be using !irq to
detect invalid IRQs, and not using NO_IRQ.

Meanwhile, I change a bit to make the code more readability for driver
when I check the code style.

Signed-off-by: Caesar Wang 
---

Changes in v1:
- As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'.

  drivers/clocksource/rockchip_timer.c | 29
+++--
  1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c
b/drivers/clocksource/rockchip_timer.c index bb2c2b0..e1af449 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -17,16 +17,16 @@

  #define TIMER_NAME "rk_timer"

-#define TIMER_LOAD_COUNT0 0x00
-#define TIMER_LOAD_COUNT1 0x04
-#define TIMER_CONTROL_REG 0x10
-#define TIMER_INT_STATUS 0x18
+#define TIMER_LOAD_COUNT00x00
+#define TIMER_LOAD_COUNT10x04
+#define TIMER_CONTROL_REG0x10
+#define TIMER_INT_STATUS0x18

-#define TIMER_DISABLE 0x0
-#define TIMER_ENABLE 0x1
-#define TIMER_MODE_FREE_RUNNING (0 << 1)
-#define TIMER_MODE_USER_DEFINED_COUNT (1 << 1)
-#define TIMER_INT_UNMASK (1 << 2)
+#define TIMER_DISABLE(0 << 0)
+#define TIMER_ENABLE(1 << 0)
+#define TIMER_MODE_FREE_RUNNING(0 << 1)
+#define TIMER_MODE_USER_DEFINED_COUNT(1 << 1)
+#define TIMER_INT_UNMASK(1 << 2)

not sure how Daniel sees this, but those could count as "unrelated
change", as
they have nothing to do with the arm64 build-fixes.


Yep, it's no related to the arm64 uild fixes.
I only make the code more readability for driver.




  struct bc_timer {
  struct clock_event_device ce;
@@ -49,14 +49,14 @@ static inline void __iomem *rk_base(struct
clock_event_device *ce) static inline void rk_timer_disable(struct
clock_event_device *ce) {
  writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
-dsb();
+dsb(sy);
  }

  static inline void rk_timer_enable(struct clock_event_device *ce, u32
flags) {
  writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
 rk_base(ce) + TIMER_CONTROL_REG);
-dsb();
+dsb(sy);
  }

  static void rk_timer_update_counter(unsigned long cycles,
@@ -64,13 +64,13 @@ static void rk_timer_update_counter(unsigned long
cycles, {
  writel_relaxed(cycles, rk_base(ce) + TIMER_LOAD_COUNT0);
  writel_relaxed(0, rk_base(ce) + TIMER_LOAD_COUNT1);
-dsb();
+dsb(sy);
  }

  static void rk_timer_interrupt_clear(struct clock_event_device *ce)
  {
  writel_relaxed(1, rk_base(ce) + TIMER_INT_STATUS);
-dsb();
+dsb(sy);
  }

  static inline int rk_timer_set_next_event(unsigned long cycles,
@@ -148,7 +148,7 @@ static void __init rk_timer_init(struct
device_node *np)
bc_timer.freq = clk_get_rate(timer_clk);

  irq = irq_of_parse_and_map(np, 0);
-if (irq == NO_IRQ) {
+if (!irq) {
  pr_err("Failed to map interrupts for '%s'\n", TIMER_NAME);
  return;
  }
@@ -173,4 +173,5 @@ static void __init rk_timer_init(struct
device_node *np)

  clockevents_config_and_register(ce, bc_timer.freq, 1, UINT_MAX);
  }
+

unnecessary addition of a blank line (same reasons as above)


It's the same reason with the above.

CHECK: Please use a blank line after function/struct/union/enum
declarations
#176: FILE: rockchip_timer.c:176:
+}
+CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", rk_timer_init);

I know, we can ignore the above warning.
That's a bit better, I thnik.



  CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-tim

[GIT PULL] DeviceTree fixes for 4.3

[Rob Herring]

Hi Linus,

Please pull DT fixes for 4.3. Details below.

Rob

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-fixes-for-4.3

for you to fetch changes up to a13f18f59d2646754cda3662a9e215ff43e7a7d5:

  Documentation: arm: Fix typo in the idle-states bindings examples
(2015-09-24 17:55:32 -0500)


DeviceTree fixes for 4.3:

- Silence bogus warning for of_irq_parse_pci
- Fix typo in ARM idle-states binding doc and dts files
- Various minor binding documentation updates


David Daney (1):
  of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.

Hans de Goede (1):
  devicetree: bindings: Extend the bma180 bindings with bma250 info

Javier Martinez Canillas (1):
  gpio: mention in DT binding doc that -gpio is deprecated

Lorenzo Pieralisi (1):
  Documentation: arm: Fix typo in the idle-states bindings examples

Mark Rutland (1):
  Docs: dt: add #msi-cells to GICv3 ITS binding

Masahiro Yamada (1):
  of: add vendor prefix for Socionext Inc.

Punit Agrawal (2):
  of: thermal: Fix inconsitency between cooling-*-state and cooling-*-level
  of: thermal: Mark cooling-*-level properties optional

 Documentation/devicetree/bindings/arm/gic-v3.txt   |  5 
 .../devicetree/bindings/arm/idle-states.txt|  2 +-
 Documentation/devicetree/bindings/gpio/gpio.txt|  4 +++-
 .../devicetree/bindings/iio/accel/bma180.txt   |  8 +--
 .../devicetree/bindings/thermal/thermal.txt| 27 +++---
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  2 +-
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   |  2 +-
 drivers/of/of_pci_irq.c| 22 +++---
 9 files changed, 46 insertions(+), 27 deletions(-)
--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Russell King - ARM Linux]

On Fri, Sep 25, 2015 at 12:50:33AM +0200, Andrew Lunn wrote:
> > Thanks for testing.  Please could you confirm whether the same behaviour
> > is observed without the patches, just to make absolutely sure that isn't
> > a regression.
> 
> So i tested this now.
> 
> I have two FEC interfaces. One i my main access interface, and the
> second is used by DSA to access switches. With your patches, the
> module Used by count is equal to the number of interfaces which are
> up.
> 
> Without your patches, the count is always 0.

That will be as a result of the MDIO bus module refcounting patch -
"phy: fix mdiobus module safety".  The code prior to that patch was
totally useless and ineffectual - it might as well not even have
been present, because it would never have any effect.  bus_module
would always be NULL in phy_attach_direct().

While my change makes the code start to work as originally intended,
it's still unsafe: there's nothing to stop you manually unbinding the
driver providing the MDIO bus from the struct device.  The driver
will then free the resources it claimed in its probe function, which
may include the MMIO mapping for the MDIO bus accessor functions.

If the accessors are then called, despite keeping the mdio bus, phy,
etc data structures properly refcounted, the kernel will oops when
the (many) MDIO bus drivers hit the free'd MMIO mapping.  This is,
unfortunately, just another pre-existing bug in this code.

To stop that, we need some way to say "this MDIO bus has been removed,
prevent further access" and that needs to be done in a race free way.
Right now, that doesn't exist.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 0/7] tty: serial: msm: Add DMA support and fix bit definitions

[Srinivas Kandagatla]

Hi Ivan,
On 12/09/15 14:02, Ivan T. Ivanov wrote:

Hi,

Following patches add DMA support for UARTDM type of hardware.

Changes have been tested on UARTDM v1.3(APQ8064) and v1.4(APQ8016).

Patches from Gurav were published long ago here[1], I just addressed
remaining comments and coding style issues.

Any comments are welcome.

Looks like Magic Sysrq is broken with this patches.

--srini


Regards,
Ivan

Ivan T. Ivanov (5):
   tty: serial: msm: Fix command Stale Event Enable definition
   tty: serial: msm: Add msm prefix to all driver functions
   tty: serial: msm: Add TX DMA support
   tty: serial: msm: Add RX DMA support
   tty: serial: msm: Remove 115.2 Kbps maximum baud rate limitation

Pramod Gurav (2):
   tty: serial: msm: Add mask value for UART_DM registers
   tty: serial: msm: replaces (1 << x) with BIT(x) macro

[1] http://www.spinics.net/lists/linux-serial/msg16874.html


  .../devicetree/bindings/serial/qcom,msm-uartdm.txt |   6 +
  drivers/tty/serial/msm_serial.c| 616 +++--
  drivers/tty/serial/msm_serial.h|  55 +-
  3 files changed, 604 insertions(+), 73 deletions(-)

--
1.9.1

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


--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Russell King - ARM Linux]

On Thu, Sep 24, 2015 at 03:51:37PM -0700, David Miller wrote:
> From: Andrew Lunn 
> Date: Fri, 25 Sep 2015 00:26:54 +0200
> 
> > On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote:
> >> From: Andrew Lunn 
> >> Date: Thu, 24 Sep 2015 23:57:31 +0200
> >> 
> >> > I built the FEC driver as a module, and it won't unload:
> >> > 
> >> >  kernel:unregister_netdevice: waiting for eth1 to become free. Usage 
> >> > count = 1
> >> > unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> >> > 
> >> > i assume because DSA holds a reference. I've not tried a fully module
> >> > build, DSA has issues with that.
> >> > 
> >> > Tested-by: Andrew Lunn 
> >> 
> >> So, is this a regression?
> > 
> > Sorry, worded that badly. Since DSA is still active, it should not be
> > possible to unload the FEC driver. DSA should have a reference to it,
> > and mdio-mux also should have a reference to the mdio bus of the FEC
> > driver.
> > 
> > As Russell requested, i will re-test without his patches, just to make
> > sure.
> 
> Something needs to hold into the underlying device refcount of a DSA
> blob so that an unload can't even be attempted in that state.

Holding a reference on a struct device does _not_ stop the device
being unbound or the module driving it being removed.  It merely
stops the struct device from being freed before all references have
been dropped.

Devices are always free to be unbound from their bound drivers
irrespective of the struct device refcount.  Even taking a reference
on the module (via try_module_get()) does not stop this.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] net: mdio-octeon: Add PCI driver binding.

[David Miller]

From: David Daney 
Date: Thu, 24 Sep 2015 15:54:30 -0700

> On 09/24/2015 03:50 PM, David Miller wrote:
>> From: David Daney 
>> Date: Thu, 24 Sep 2015 15:45:41 -0700
>>
>>> 2) The OF device tree nodes for PCI devices do not result in the
>>> creation of a platform device.
>>
>> But they are created for the children right?  And that's the one
>> you need them for probing.
>>
>> I'm still not convinced, sorry.
>>
> 
> Let's let this topic rest for a few days.  My original patch was
> defective, so it cannot be merged.  I will sleep on this, try a few
> things and perhaps revisit it if I still think it is advisable.

Ok.
--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Andrew Lunn]

> Thanks for testing.  Please could you confirm whether the same behaviour
> is observed without the patches, just to make absolutely sure that isn't
> a regression.

So i tested this now.

I have two FEC interfaces. One i my main access interface, and the
second is used by DSA to access switches. With your patches, the
module Used by count is equal to the number of interfaces which are
up.

Without your patches, the count is always 0.

When i try to remove the fec module, without your patches, but DSA
still using the interface, i get the same

 kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1

as with your patch. So this is not a regression.

   Andrew
--
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] net: mdio-octeon: Add PCI driver binding.

[David Daney]

On 09/24/2015 03:50 PM, David Miller wrote:

From: David Daney 
Date: Thu, 24 Sep 2015 15:45:41 -0700


2) The OF device tree nodes for PCI devices do not result in the
creation of a platform device.


But they are created for the children right?  And that's the one
you need them for probing.

I'm still not convinced, sorry.



Let's let this topic rest for a few days.  My original patch was 
defective, so it cannot be merged.  I will sleep on this, try a few 
things and perhaps revisit it if I still think it is advisable.


Thanks,
David Daney
--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[David Miller]

From: Andrew Lunn 
Date: Fri, 25 Sep 2015 00:26:54 +0200

> On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote:
>> From: Andrew Lunn 
>> Date: Thu, 24 Sep 2015 23:57:31 +0200
>> 
>> > I built the FEC driver as a module, and it won't unload:
>> > 
>> >  kernel:unregister_netdevice: waiting for eth1 to become free. Usage count 
>> > = 1
>> > unregister_netdevice: waiting for eth1 to become free. Usage count = 1
>> > 
>> > i assume because DSA holds a reference. I've not tried a fully module
>> > build, DSA has issues with that.
>> > 
>> > Tested-by: Andrew Lunn 
>> 
>> So, is this a regression?
> 
> Sorry, worded that badly. Since DSA is still active, it should not be
> possible to unload the FEC driver. DSA should have a reference to it,
> and mdio-mux also should have a reference to the mdio bus of the FEC
> driver.
> 
> As Russell requested, i will re-test without his patches, just to make
> sure.

Something needs to hold into the underlying device refcount of a DSA
blob so that an unload can't even be attempted in that state.
--
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] net: mdio-octeon: Add PCI driver binding.

[David Miller]

From: David Daney 
Date: Thu, 24 Sep 2015 15:45:41 -0700

> 2) The OF device tree nodes for PCI devices do not result in the
> creation of a platform device.

But they are created for the children right?  And that's the one
you need them for probing.

I'm still not convinced, sorry.
--
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] net: mdio-octeon: Add PCI driver binding.

[David Daney]

On 09/24/2015 03:14 PM, David Miller wrote:

From: David Daney 
Date: Thu, 24 Sep 2015 15:04:23 -0700


On 09/24/2015 02:52 PM, David Miller wrote:

From: David Daney 
Date: Tue, 22 Sep 2015 17:41:36 -0700


From: David Daney 

When the Cavium mdio-octeon devices appear in the Thunder family of
arm64 based SoCs, they show up as PCI devices.  Add PCI driver
wrapping so the driver is bound in the standard PCI device scan.

When in this form, a single PCI device may have more than a single
bus, we call this a "nexus" of buses.  The standard firmware
device_for_each_child_node() iterator is used to find the individual
buses underneath the "nexus".

Update the device tree binding documentation for the new PCI driver
binding.

Signed-off-by: David Daney 


This patch breaks the build:


For which architecture?

I tested it on mips and arm64.  I will try x86, as I guess that is
where you tried your test build.


x86-64.


There is, somewhat of, a method behind the madness here.

In order to use MSI-X interrupts, we need a corresponding PCI
device. Now, this driver doesn't currently use interrupts, but other
devices in the SoC do, so they must be PCI devices.


"I need this thing, which isn't needed, therefore I'm making this
change."



That is not the exact argument.  It is really more like this:

1) The firmware is supplying a uniform view of the devices by making 
them all PCI devices.  This is done because:


   a) Devices that use interrupts must be PCI.

   b) Uniformity is good.

2) The OF device tree nodes for PCI devices do not result in the 
creation of a platform device.


3) If there is no platform device, platform device driver binding does 
not occur, and the device is useless to the kernel.


So, we think it is a good change.  I don't really want to argue about 
the  semantics of it being a "needed change".



Sorry, that's not a good argument.

ACPI nodes have names and whatnot as well.

So I haven't heard a compelling argument so far.

So why not just implement this cleanly and using the existing
framework now, and then when you have a legitimate reason for making a
major change to the probing scheme you can do it then.



--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Andrew Lunn]

On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote:
> From: Andrew Lunn 
> Date: Thu, 24 Sep 2015 23:57:31 +0200
> 
> > I built the FEC driver as a module, and it won't unload:
> > 
> >  kernel:unregister_netdevice: waiting for eth1 to become free. Usage count 
> > = 1
> > unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> > 
> > i assume because DSA holds a reference. I've not tried a fully module
> > build, DSA has issues with that.
> > 
> > Tested-by: Andrew Lunn 
> 
> So, is this a regression?

Sorry, worded that badly. Since DSA is still active, it should not be
possible to unload the FEC driver. DSA should have a reference to it,
and mdio-mux also should have a reference to the mdio bus of the FEC
driver.

As Russell requested, i will re-test without his patches, just to make
sure.

Andrew
--
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 1/9] ARM: dts: consolidate aliases for Cygnus dt files

[Ray Jui]

On 9/23/2015 2:48 PM, Florian Fainelli wrote:
> On 23/09/15 14:46, Ray Jui wrote:
>>
>>
>> On 9/23/2015 2:31 PM, Arnd Bergmann wrote:
>>> On Friday 18 September 2015 14:44:54 Ray Jui wrote:
 On 9/18/2015 2:27 PM, Arnd Bergmann wrote:
> On Friday 18 September 2015 14:24:06 Ray Jui wrote:
>
> The SoC has at least four uarts according to this, so it seems unlikely 
> that
> each board really only uses only the fourth one of them and labels it '0'
> on the board. As soon as you get one board that has more than one uart 
> wired
> up, you would need to undo this.
>

 I think Scott might have explained this in the past. uart3 is going to
 be used on all Cygnus boards (including all future boards) because the
 bootrom was designed to use uart3 as console and that won't change.

 Let me know if you still think I need to move this back to the dts.
>>>
>>> I would still like to see them stay in the .dts file, if only for
>>> consistency with other platforms. 
>>>
>>> Also, even if you can guarantee that uart3 is always used for the
>>> console, that doesn't prevent board designers from adding more than
>>> one uart, right?
>>>
>>> Arnd
>>>
>>
>> Okay. Given that this patch series has been merged by Florian, I'll
>> submit another patch to move it back to .dts files.
> 
> You could send me either a replacement patch series (all 9), or an
> individual patch to replace a previous version (e.g; replace v2 with a
> v3), or an incremental one, whatever works for you.
> 
> Thanks!
> 

Hi Florian, I just sent you an incremental patch to move the alias back
to .dts files.

Thanks,

Ray
--
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 RESEND v3 5/9] of_mdio: fix MDIO phy device refcounting

[Rob Herring]

On Thu, Sep 24, 2015 at 2:36 PM, Russell King
 wrote:
> bus_find_device() is defined as:
>
>  * This is similar to the bus_for_each_dev() function above, but it
>  * returns a reference to a device that is 'found' for later use, as
>  * determined by the @match callback.
>
> and it does indeed return a reference-counted pointer to the device:
>
> while ((dev = next_device(&i)))
> if (match(dev, data) && get_device(dev))
> ^^^
> break;
> klist_iter_exit(&i);
> return dev;
>
> What that means is that when we're done with the struct device, we must
> drop that reference.  Neither of_phy_connect() nor of_phy_attach() did
> this when phy_connect_direct() or phy_attach_direct() failed.
>
> With our previous patch, phy_connect_direct() and phy_attach_direct()
> take a new refcount on the phy device when successful, so we can drop
> our local reference immediatley after these functions, whether or not
> they succeeded.
>
> Signed-off-by: Russell King 

Acked-by: Rob Herring 

> ---
>  drivers/of/of_mdio.c | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index 1350fa25cdb0..a87a868fed64 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -197,7 +197,8 @@ static int of_phy_match(struct device *dev, void *phy_np)
>   * of_phy_find_device - Give a PHY node, find the phy_device
>   * @phy_np: Pointer to the phy's device tree node
>   *
> - * Returns a pointer to the phy_device.
> + * If successful, returns a pointer to the phy_device with the embedded
> + * struct device refcount incremented by one, or NULL on failure.
>   */
>  struct phy_device *of_phy_find_device(struct device_node *phy_np)
>  {
> @@ -217,7 +218,9 @@ EXPORT_SYMBOL(of_phy_find_device);
>   * @hndlr: Link state callback for the network device
>   * @iface: PHY data interface type
>   *
> - * Returns a pointer to the phy_device if successful.  NULL otherwise
> + * If successful, returns a pointer to the phy_device with the embedded
> + * struct device refcount incremented by one, or NULL on failure. The
> + * refcount must be dropped by calling phy_disconnect() or phy_detach().
>   */
>  struct phy_device *of_phy_connect(struct net_device *dev,
>   struct device_node *phy_np,
> @@ -225,13 +228,19 @@ struct phy_device *of_phy_connect(struct net_device 
> *dev,
>   phy_interface_t iface)
>  {
> struct phy_device *phy = of_phy_find_device(phy_np);
> +   int ret;
>
> if (!phy)
> return NULL;
>
> phy->dev_flags = flags;
>
> -   return phy_connect_direct(dev, phy, hndlr, iface) ? NULL : phy;
> +   ret = phy_connect_direct(dev, phy, hndlr, iface);
> +
> +   /* refcount is held by phy_connect_direct() on success */
> +   put_device(&phy->dev);
> +
> +   return ret ? NULL : phy;
>  }
>  EXPORT_SYMBOL(of_phy_connect);
>
> @@ -241,17 +250,27 @@ EXPORT_SYMBOL(of_phy_connect);
>   * @phy_np: Node pointer for the PHY
>   * @flags: flags to pass to the PHY
>   * @iface: PHY data interface type
> + *
> + * If successful, returns a pointer to the phy_device with the embedded
> + * struct device refcount incremented by one, or NULL on failure. The
> + * refcount must be dropped by calling phy_disconnect() or phy_detach().
>   */
>  struct phy_device *of_phy_attach(struct net_device *dev,
>  struct device_node *phy_np, u32 flags,
>  phy_interface_t iface)
>  {
> struct phy_device *phy = of_phy_find_device(phy_np);
> +   int ret;
>
> if (!phy)
> return NULL;
>
> -   return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
> +   ret = phy_attach_direct(dev, phy, flags, iface);
> +
> +   /* refcount is held by phy_attach_direct() on success */
> +   put_device(&phy->dev);
> +
> +   return ret ? NULL : phy;
>  }
>  EXPORT_SYMBOL(of_phy_attach);
>
> --
> 2.1.0
>
--
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] ARM: dts: move aliases back to .dts in Cygnus

[Ray Jui]

Move aliases from bcm-cygnus.dtsi back to individual .dts files. Also
clean up the chosen node to have the stdout-path using the proper alias

Signed-off-by: Ray Jui 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 4 
 arch/arm/boot/dts/bcm911360k.dts  | 7 +--
 arch/arm/boot/dts/bcm958300k.dts  | 7 +--
 arch/arm/boot/dts/bcm958305k.dts  | 7 +--
 4 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index b5f9f34..2778533 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -41,10 +41,6 @@
model = "Broadcom Cygnus SoC";
interrupt-parent = <&gic>;
 
-   aliases {
-   serial0 = &uart3;
-   };
-
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/bcm911360k.dts b/arch/arm/boot/dts/bcm911360k.dts
index 814011c..091c73a 100644
--- a/arch/arm/boot/dts/bcm911360k.dts
+++ b/arch/arm/boot/dts/bcm911360k.dts
@@ -38,9 +38,12 @@
model = "Cygnus SVK (BCM911360K)";
compatible = "brcm,bcm11360", "brcm,cygnus";
 
+   aliases {
+   serial0 = &uart3;
+   };
+
chosen {
-   stdout-path = &uart3;
-   bootargs = "console=ttyS0,115200";
+   stdout-path = "serial0:115200n8";
};
 };
 
diff --git a/arch/arm/boot/dts/bcm958300k.dts b/arch/arm/boot/dts/bcm958300k.dts
index 2e31581..b4a1392 100644
--- a/arch/arm/boot/dts/bcm958300k.dts
+++ b/arch/arm/boot/dts/bcm958300k.dts
@@ -39,9 +39,12 @@
model = "Cygnus SVK (BCM958300K)";
compatible = "brcm,bcm58300", "brcm,cygnus";
 
+   aliases {
+   serial0 = &uart3;
+   };
+
chosen {
-   stdout-path = &uart3;
-   bootargs = "console=ttyS0,115200";
+   stdout-path = "serial0:115200n8";
};
 };
 
diff --git a/arch/arm/boot/dts/bcm958305k.dts b/arch/arm/boot/dts/bcm958305k.dts
index 288a637..3378683 100644
--- a/arch/arm/boot/dts/bcm958305k.dts
+++ b/arch/arm/boot/dts/bcm958305k.dts
@@ -39,9 +39,12 @@
model = "Cygnus Wireless Audio (BCM958305K)";
compatible = "brcm,bcm58305", "brcm,cygnus";
 
+   aliases {
+   serial0 = &uart3;
+   };
+
chosen {
-   stdout-path = &uart3;
-   bootargs = "console=ttyS0,115200";
+   stdout-path = "serial0:115200n8";
};
 };
 
-- 
1.9.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: [PATCHv3 0/2] Add support for tps65217 charger

[Sebastian Reichel]

Hi,

On Thu, Sep 24, 2015 at 09:44:19PM +0200, Enric Balletbo i Serra wrote:
> The following series add initial support for tps65217 battery charger.

Thanks, queued.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH] net: mdio-octeon: Add PCI driver binding.

[David Miller]

From: David Daney 
Date: Thu, 24 Sep 2015 15:12:03 -0700

> Sorry for the breakage, I will fix it and resubmit.

Don't bother, I told you that using PCI probing is unacceptable.
--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[David Miller]

From: Andrew Lunn 
Date: Thu, 24 Sep 2015 23:57:31 +0200

> I built the FEC driver as a module, and it won't unload:
> 
>  kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> 
> i assume because DSA holds a reference. I've not tried a fully module
> build, DSA has issues with that.
> 
> Tested-by: Andrew Lunn 

So, is this a regression?

Please don't provide a "Tested-by: " tag is you encounter a new
problem which could have been introduced by the changes in question.
That _REALLY_ screws everything up for me.

Thank.
--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Russell King - ARM Linux]

On Thu, Sep 24, 2015 at 11:57:31PM +0200, Andrew Lunn wrote:
> Hi Russell
> 
> I tested both of these with my board. It is a Freescale Vybrid, using
> the FEC ethernet driver, and i have three switches attached, using
> mdio-mux to give three mdio busses.
> 
> No obvious regressions, my board boots, the switches are all present
> and correct. I built the FEC driver as a module, and it won't unload:
> 
>  kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> 
> i assume because DSA holds a reference. I've not tried a fully module
> build, DSA has issues with that.
> 
> Tested-by: Andrew Lunn 

Thanks for testing.  Please could you confirm whether the same behaviour
is observed without the patches, just to make absolutely sure that isn't
a regression.

However, I think you are correct - I'm unable to locate where in the
DSA code:
- dst->master_dev's dev_hold() is undone (hence a reference left)
- dst is freed - dsa_probe() allocates it using kzalloc(), but
  dsa_remove() and it's children don't free this structure.

There's no notifier which detects whether the underlying device has
gone away - it registers a netdev notifier (dsa_slave_netdevice_event)
but this only deals with slave devices, not the master device.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] net: mdio-octeon: Add PCI driver binding.

[David Miller]

From: David Daney 
Date: Thu, 24 Sep 2015 15:04:23 -0700

> On 09/24/2015 02:52 PM, David Miller wrote:
>> From: David Daney 
>> Date: Tue, 22 Sep 2015 17:41:36 -0700
>>
>>> From: David Daney 
>>>
>>> When the Cavium mdio-octeon devices appear in the Thunder family of
>>> arm64 based SoCs, they show up as PCI devices.  Add PCI driver
>>> wrapping so the driver is bound in the standard PCI device scan.
>>>
>>> When in this form, a single PCI device may have more than a single
>>> bus, we call this a "nexus" of buses.  The standard firmware
>>> device_for_each_child_node() iterator is used to find the individual
>>> buses underneath the "nexus".
>>>
>>> Update the device tree binding documentation for the new PCI driver
>>> binding.
>>>
>>> Signed-off-by: David Daney 
>>
>> This patch breaks the build:
> 
> For which architecture?
> 
> I tested it on mips and arm64.  I will try x86, as I guess that is
> where you tried your test build.

x86-64.

> There is, somewhat of, a method behind the madness here.
> 
> In order to use MSI-X interrupts, we need a corresponding PCI
> device. Now, this driver doesn't currently use interrupts, but other
> devices in the SoC do, so they must be PCI devices.

"I need this thing, which isn't needed, therefore I'm making this
change."

Sorry, that's not a good argument.

ACPI nodes have names and whatnot as well.

So I haven't heard a compelling argument so far.

So why not just implement this cleanly and using the existing
framework now, and then when you have a legitimate reason for making a
major change to the probing scheme you can do it then.
--
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] net: mdio-octeon: Add PCI driver binding.

[David Daney]

On 09/24/2015 03:04 PM, David Daney wrote:

On 09/24/2015 02:52 PM, David Miller wrote:

From: David Daney 
Date: Tue, 22 Sep 2015 17:41:36 -0700


From: David Daney 

When the Cavium mdio-octeon devices appear in the Thunder family of
arm64 based SoCs, they show up as PCI devices.  Add PCI driver
wrapping so the driver is bound in the standard PCI device scan.

When in this form, a single PCI device may have more than a single
bus, we call this a "nexus" of buses.  The standard firmware
device_for_each_child_node() iterator is used to find the individual
buses underneath the "nexus".

Update the device tree binding documentation for the new PCI driver
binding.

Signed-off-by: David Daney 


This patch breaks the build:


For which architecture?

I tested it on mips and arm64.  I will try x86, as I guess that is where
you tried your test build.




   CC [M]  drivers/net/phy/mdio-octeon.o
In file included from drivers/net/phy/mdio-octeon.c:13:0:
include/linux/module.h:128:27: error: redefinition of ‘__inittest’
   static inline initcall_t __inittest(void)  \



OK, I reproduced this failure.  It happens with a module build only.

Sorry for the breakage, I will fix it and resubmit.

David Daney


 ^

[...]



And frankly I'm not sure I like this change anyways.  If the OF nodes
are there, simply add code to match on those OF nodes.

This is better than assuming what sits underneath a PCI node, without
any checks for the 'name' or 'compatible' properties at all.  That's
what they are there for afterall.


There is, somewhat of, a method behind the madness here.

In order to use MSI-X interrupts, we need a corresponding PCI device.
Now, this driver doesn't currently use interrupts, but other devices in
the SoC do, so they must be PCI devices.

The idea is to have the type of all drivers uniformly be PCI, rather
than a random mix of PCI and platform, and then switch them back and
forth as PCI features are/are-not used in the driver.

Also we need to consider ACPI firmware in addition to OF device tree.

David Daney



--
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] gpio:pca953x: add mechanism to simulate open drain outputs

[Linus Walleij]

On Wed, Sep 23, 2015 at 11:13 AM, H. Nikolaus Schaller
 wrote:

> 1. add a DT property to specify the list of GPIO pins that are to become
>"open drain"
> 2. if a pin is configured as "open drain", set value by either outputting a
>"0" (low level) or switching to input (high impedance)
>
> Tested on OMAP5 uEVM with TCA6424 and some LEDs connected to 5V.
>
> Signed-off-by: H. Nikolaus Schaller 

I understand the approach, but this is the wrong way to do it.
Instead of indicating that a pin on the pin controller should be
open drain, the *consumer* specifying its gpios = <> should
do this.

I just sent a patch adding the bindings because Tony Lindgren
and Grygorii Strashko approached me similar problems so let's
begin with the bindings.

Implementing it in the kernel requires some elaboration and it's
going to be more complicated than this local approach, but it
will be more generic and reusable so that is what we need to do.

Yours,
Linus Walleij
--
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 v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Andrew Lunn]

...

> While looking at the DSA code, I noticed we have a
> of_find_net_device_by_node(), and it looks like users of that are
> similarly buggy - it looks like net/dsa/dsa.c is the only user.  Fix
> that too.

...
 
> The mdiobus code also suffered from the same kind of leak, but thankfully
> this only happened in one place - the mdio-mux code.

Hi Russell

I tested both of these with my board. It is a Freescale Vybrid, using
the FEC ethernet driver, and i have three switches attached, using
mdio-mux to give three mdio busses.

No obvious regressions, my board boots, the switches are all present
and correct. I built the FEC driver as a module, and it won't unload:

 kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1
unregister_netdevice: waiting for eth1 to become free. Usage count = 1

i assume because DSA holds a reference. I've not tried a fully module
build, DSA has issues with that.

Tested-by: Andrew Lunn 

Thanks
Andrew
--
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] net: mdio-octeon: Add PCI driver binding.

[David Daney]

On 09/24/2015 02:52 PM, David Miller wrote:

From: David Daney 
Date: Tue, 22 Sep 2015 17:41:36 -0700


From: David Daney 

When the Cavium mdio-octeon devices appear in the Thunder family of
arm64 based SoCs, they show up as PCI devices.  Add PCI driver
wrapping so the driver is bound in the standard PCI device scan.

When in this form, a single PCI device may have more than a single
bus, we call this a "nexus" of buses.  The standard firmware
device_for_each_child_node() iterator is used to find the individual
buses underneath the "nexus".

Update the device tree binding documentation for the new PCI driver
binding.

Signed-off-by: David Daney 


This patch breaks the build:


For which architecture?

I tested it on mips and arm64.  I will try x86, as I guess that is where 
you tried your test build.





   CC [M]  drivers/net/phy/mdio-octeon.o
In file included from drivers/net/phy/mdio-octeon.c:13:0:
include/linux/module.h:128:27: error: redefinition of ‘__inittest’
   static inline initcall_t __inittest(void)  \
^

[...]



And frankly I'm not sure I like this change anyways.  If the OF nodes
are there, simply add code to match on those OF nodes.

This is better than assuming what sits underneath a PCI node, without
any checks for the 'name' or 'compatible' properties at all.  That's
what they are there for afterall.


There is, somewhat of, a method behind the madness here.

In order to use MSI-X interrupts, we need a corresponding PCI device. 
Now, this driver doesn't currently use interrupts, but other devices in 
the SoC do, so they must be PCI devices.


The idea is to have the type of all drivers uniformly be PCI, rather 
than a random mix of PCI and platform, and then switch them back and 
forth as PCI features are/are-not used in the driver.


Also we need to consider ACPI firmware in addition to OF device tree.

David Daney

--
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] Docs/kernel-parameters: Add earlycon devicetree usage

[Jonathan Corbet]

On Mon, 14 Sep 2015 19:54:07 -0500
Scott Wood  wrote:

> This form of the earlycon parameter was added by commit fb11ffe74c794a5
> ("of/fdt: add FDT serial scanning for earlycon") without documentation.

Applied to the docs tree, thanks.

jon
--
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] net: mdio-octeon: Add PCI driver binding.

[David Miller]

From: David Daney 
Date: Tue, 22 Sep 2015 17:41:36 -0700

> From: David Daney 
> 
> When the Cavium mdio-octeon devices appear in the Thunder family of
> arm64 based SoCs, they show up as PCI devices.  Add PCI driver
> wrapping so the driver is bound in the standard PCI device scan.
> 
> When in this form, a single PCI device may have more than a single
> bus, we call this a "nexus" of buses.  The standard firmware
> device_for_each_child_node() iterator is used to find the individual
> buses underneath the "nexus".
> 
> Update the device tree binding documentation for the new PCI driver
> binding.
> 
> Signed-off-by: David Daney 

This patch breaks the build:

  CC [M]  drivers/net/phy/mdio-octeon.o
In file included from drivers/net/phy/mdio-octeon.c:13:0:
include/linux/module.h:128:27: error: redefinition of ‘__inittest’
  static inline initcall_t __inittest(void)  \
   ^
include/linux/device.h:1321:1: note: in expansion of macro ‘module_init’
 module_init(__driver##_init); \
 ^
include/linux/pci.h:1192:2: note: in expansion of macro ‘module_driver’
  module_driver(__pci_driver, pci_register_driver, \
  ^
drivers/net/phy/mdio-octeon.c:513:1: note: in expansion of macro 
‘module_pci_driver’
 module_pci_driver(thunder_mdiobus_driver);
 ^
include/linux/module.h:128:27: note: previous definition of ‘__inittest’ was 
here
  static inline initcall_t __inittest(void)  \
   ^
include/linux/device.h:1321:1: note: in expansion of macro ‘module_init’
 module_init(__driver##_init); \
 ^
include/linux/platform_device.h:222:2: note: in expansion of macro 
‘module_driver’
  module_driver(__platform_driver, platform_driver_register, \
  ^
drivers/net/phy/mdio-octeon.c:373:1: note: in expansion of macro 
‘module_platform_driver’
 module_platform_driver(octeon_mdiobus_driver);
 ^
include/linux/module.h:130:6: error: redefinition of ‘init_module’
  int init_module(void) __attribute__((alias(#initfn)));
  ^
include/linux/device.h:1321:1: note: in expansion of macro ‘module_init’
 module_init(__driver##_init); \
 ^
include/linux/pci.h:1192:2: note: in expansion of macro ‘module_driver’
  module_driver(__pci_driver, pci_register_driver, \
  ^
drivers/net/phy/mdio-octeon.c:513:1: note: in expansion of macro 
‘module_pci_driver’
 module_pci_driver(thunder_mdiobus_driver);
 ^
include/linux/module.h:130:6: note: previous definition of ‘init_module’ was 
here
  int init_module(void) __attribute__((alias(#initfn)));
  ^
include/linux/device.h:1321:1: note: in expansion of macro ‘module_init’
 module_init(__driver##_init); \
 ^
include/linux/platform_device.h:222:2: note: in expansion of macro 
‘module_driver’
  module_driver(__platform_driver, platform_driver_register, \
  ^
drivers/net/phy/mdio-octeon.c:373:1: note: in expansion of macro 
‘module_platform_driver’
 module_platform_driver(octeon_mdiobus_driver);
 ^
include/linux/module.h:134:27: error: redefinition of ‘__exittest’
  static inline exitcall_t __exittest(void)  \
   ^
include/linux/device.h:1326:1: note: in expansion of macro ‘module_exit’
 module_exit(__driver##_exit);
 ^
include/linux/pci.h:1192:2: note: in expansion of macro ‘module_driver’
  module_driver(__pci_driver, pci_register_driver, \
  ^
drivers/net/phy/mdio-octeon.c:513:1: note: in expansion of macro 
‘module_pci_driver’
 module_pci_driver(thunder_mdiobus_driver);
 ^
include/linux/module.h:134:27: note: previous definition of ‘__exittest’ was 
here
  static inline exitcall_t __exittest(void)  \
   ^
include/linux/device.h:1326:1: note: in expansion of macro ‘module_exit’
 module_exit(__driver##_exit);
 ^
include/linux/platform_device.h:222:2: note: in expansion of macro 
‘module_driver’
  module_driver(__platform_driver, platform_driver_register, \
  ^
drivers/net/phy/mdio-octeon.c:373:1: note: in expansion of macro 
‘module_platform_driver’
 module_platform_driver(octeon_mdiobus_driver);
 ^
include/linux/module.h:136:7: error: redefinition of ‘cleanup_module’
  void cleanup_module(void) __attribute__((alias(#exitfn)));
   ^
include/linux/device.h:1326:1: note: in expansion of macro ‘module_exit’
 module_exit(__driver##_exit);
 ^
include/linux/pci.h:1192:2: note: in expansion of macro ‘module_driver’
  module_driver(__pci_driver, pci_register_driver, \
  ^
drivers/net/phy/mdio-octeon.c:513:1: note: in expansion of macro 
‘module_pci_driver’
 module_pci_driver(thunder_mdiobus_driver);
 ^
include/linux/module.h:136:7: note: previous definition of ‘cleanup_module’ was 
here
  void cleanup_module(void) __attribute__((alias(#exitfn)));
   ^
include/linux/device.h:1326:1: note: in expansion of macro ‘module_exit’
 module_exit(__driver##_exit);
 ^
include/linux/platform_device.h:222:2: note: in expansion of macro 
‘module_driver’
  module_driver(__platform_driver, platform_driver_register, \
  ^
drivers/net/phy/mdio-octeon.c:373:1: note: in expansion of macro 
‘module_platform_driver’
 module_platform_d

Re: [PATCH v11 3/4] add FPGA manager core

[Pavel Machek]

Hi!

> > Of course, the maintainer gets the last word regardless of what anyone
> > else thinks.
> > 
> > Generally, minimal code is better.  Trying to future proof code is a
> > waste of time because you can't predict what will happen in the future.
> > It's way more likely that some pointer you never expected to be NULL
> > will be NULL instead of the few checked at the beginning of a function.
> > Adding useless code uses RAM and makes the function slower.  It's a bit
> > confusing for users as well because they will wonder when the NULL check
> > is used.  A lot of times this sort of error handling is a bit fake and
> > what I mean is that it looks correct but the system will just crash in a
> > later function.
> > 
> > Also especially with a simple NULL dereferences like this theoretical
> > one, it's better to just get the oops.  It kills the module but you get
> > a good message in the log and it's normally straight forward to debug.
> > 
> > We spent a surprising amount of time discussing useless code.  I made
> > someone redo a patch yesterday because they had incomplete error
> > handling for a situation which could never happen.
> 
> Thanks for the discussion.
> 
> Interesting.  The amount of code bloat here compiles down to about two
> machine instructions (in two places).  Actually a little more since I should
> be using IS_ERR_OR_NULL.  But the main question is whether I should do
> it at all.
> 
> The behaviour I should drive here is that the user will do their own error
> checking.  After they get a pointer to a FPGA manager using
> of_fpga_mgr_get(), they should check it and not assume that
> fpga_mgr_firmware_load() will do it for them, i.e.
> 
>   mgr = of_fpga_mgr_get(mgr_node);
>   if (IS_ERR(mgr))
>   return PTR_ERR(mgr);
>   fpga_mgr_firmware_load(mgr, flags, path);
> 
> I could take out these NULL pointer checks and it won't hurt anything unless
> someone is just using the functions badly, in which case: kablooey.

2 instructions is not that bad, do whatever is easier for you. These
patches received enough bikeshed painting.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Mark Rutland]

On Thu, Aug 27, 2015 at 12:44:20PM +0100, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   39 +
>  drivers/pci/host/Kconfig   |9 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pci-xilinx-nwl.c  | 1038 
> 
>  4 files changed, 1087 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pci-xilinx-nwl.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
> b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> new file mode 100644
> index 000..c554d6b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> @@ -0,0 +1,39 @@
> +* Xilinx NWL PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- compatible: Should contain "xlnx,nwl-pcie-2.11"
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> +   interrupt source. The value must be 1.

This isn't in the example, and I cna't see why/how you would use this.

> +- reg: Should contain Bridge, PCIe Controller registers location and length

You need to define reg-names, given the example and driver rely on it.

> +- device_type: must be "pci"
> +- interrupts: Should contain NWL PCIe interrupt

You need to define interrupt-names, given the example and driver rely on it.

> +- ranges: ranges for the PCI memory regions (I/O space region is not
> +   supported by hardware)
> +   Please refer to the standard PCI bus binding document for a more
> +   detailed explanation
> +
> +Optional properties:
> +- xlnx,msi-fifo: To enable MSI FIFO mode

Why is this in the binding?

When should or shouldn't I set this?

I take it the root complex is its own MSI controller?

> +
> +Example:
> +
> +nwl_pcie: pcie@fd0e {
> +   compatible = "xlnx,nwl-pcie-2.11";
> +   #address-cells = <3>;
> +   #size-cells = <2>;
> +   #interrupt-cells = <1>;
> +   device_type = "pci";
> +   interrupt-parent = <&gic>;
> +   interrupts = < 0 118 4
> +  0 116 4
> +  0 115 4  // MSI_1 [63...32]
> +  0 114 4 >;   // MSI_0 [31...0]

Nit: please bracket list entires individually (that also applies to reg).

> +   interrupt-names = "misc", "intx", "msi_1", "msi_0";
> +   reg = <0x0 0xfd0e 0x1000
> +  0x0 0xfd48 0x1000
> +  0x0 0xE000 0x100>;
> +   reg-names = "breg", "pcireg", "cfg";
> +   ranges = <0x0200 0x 0xE100 0x 0xE100 0 
> 0x0F00>;
> +};

Thanks,
Mark.
--
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 v5 1/4] leds: netxbig: add device tree binding

[Jacek Anaszewski]

Hi Simon,

On 09/24/2015 03:32 PM, Simon Guinot wrote:

On Thu, Sep 24, 2015 at 02:19:56PM +0200, Jacek Anaszewski wrote:

Hi Simon,


Hi Jacek,

Thanks again for the review. Please see my comments below.



On 09/22/2015 10:24 AM, Simon Guinot wrote:

This patch adds device tree support for the netxbig LEDs.

This also introduces a additionnal DT binding for the GPIO extension bus
(netxbig-gpio-ext) used to configure the LEDs. Since this bus could also
be used to control other devices, then it seems more suitable to have it
in a separate DT binding.

Signed-off-by: Simon Guinot 
Acked-by: Linus Walleij 
---
  .../devicetree/bindings/gpio/netxbig-gpio-ext.txt  |  22 ++
  .../devicetree/bindings/leds/leds-netxbig.txt  |  92 +++
  drivers/leds/leds-netxbig.c| 265 +++--
  include/dt-bindings/leds/leds-netxbig.h|  18 ++
  .../linux/platform_data/leds-kirkwood-netxbig.h|   1 +
  5 files changed, 376 insertions(+), 22 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
  create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
  create mode 100644 include/dt-bindings/leds/leds-netxbig.h

Changes for v2:
- Check timer mode value retrieved from DT.
- In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
   timer delay values from DT with function of_property_read_u32_index.
   Instead, use a temporary u32 variable. This allows to silence a static
   checker warning.
- Make timer property optional in the binding documentation. It is now
   aligned with the driver code.

Changes for v3:
- Fix pointer usage with the temporary u32 variable while calling
   of_property_read_u32_index.

Changes for v4:
- In DT binding document netxbig-gpio-ext.txt, detail byte order for
   registers and latch mechanism for "enable-gpio".
- In leds-netxbig.c, add some error messages.
- In leds-netxbig.c, fix some "sizeof" style issues.
- In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
   of_property_read_string() calls after the error-prone checks.
- Add some Acked-by.

Changes for v5:
- Rename DT property "bright-max" into the more common "max-brightness".
- Make use of the "max-brightness" DT property. Instead of counting the
   data pins of the GPIO extension bus, use "max-brightness" to get the
   maximum brightness level.


...


@@ -333,7 +339,7 @@ create_netxbig_led(struct platform_device *pdev,
led_dat->mode_addr = template->mode_addr;
led_dat->mode_val = template->mode_val;
led_dat->bright_addr = template->bright_addr;
-   led_dat->bright_max = (1 << pdata->gpio_ext->num_data) - 1;
+   led_dat->bright_max = template->bright_max;


Could you explain please, why in netxbig_led_set() led_dat->bright_max
is multiplied by the brightness value to be set as shown below?


void netxbig_led_set(struct led_classdev *led_cdev,
  enum led_brightness value)
{
...
 if (set_brightness) {
 bright_val = DIV_ROUND_UP(value * led_dat->bright_max,
   LED_FULL);
 gpio_ext_set_value(led_dat->gpio_ext,
led_dat->bright_addr, bright_val);
 }
...
}


Hardware values for brightness levels are in a range 0 to bright_max
(with bright_max = 7).
Software values for brightness levels are in a range 0 to 255.

Here, we are simply converting a software brightness value into an
hardware one. And the resulting value can be written directly into the
CPLD hardware bright register via the gpio-ext bus.


This conversion isn't required, as max_brightness property was
introduced to allow overriding LED_FULL value. I know that this is
in this form for a long time in this driver, just aside note.


+   led = leds;
+   for_each_child_of_node(np, child) {
+   const char *string;
+   int *mode_val;
+   int num_modes;
+
+   if (of_property_read_u32(child, "mode-addr",
+&led->mode_addr))
+   return -EINVAL;


Since for_each_child_of_node uses of_get_next_child underneath,
the user is responsible for releasing current child in case
they are going to break the iteration. In other words you
need to execute of_node_put(child) then. Assigning error codes
to ret and following it with "goto exit_for_each" would do here,
where exit_for_each is defined as follows:

exit_for_each:
of_node_put(child);
return ret;


OK, good caught. I'll do that for the next version. Note that a bunch of
other LED drivers are needing a such fix too.


Right, but this is not an urgent issue since AFAICT no LED class driver
depends on CONFIG_OF_DYNAMIC, which turns of node ref counting on.
Nonetheless it shouldn't discourage us from producing new code free
of the potential issues, we are aware of.

--
Best Regards,
Jacek Anaszewski
--
To unsubscribe fro

[PATCH v5 7/7] pinctrl: freescale: imx: imx7d iomuxc-lpsr devicetree bindings

[Adrian Alonso]

Add iomuxc-lpsr devicetree bindings documentation
Provide documentation context as well an example on
pheriperals that could use pad from either iomuxc controller
supported by iMX7D SoC

Signed-off-by: Adrian Alonso 
---
Changes for V2: New patch on imx7d iomuxc-lpsr patch series
Changes for V3: Add shared input select register notes
Changes for V4: Resend
Changes for V5:
- Fix spell error
- Remove references of SHARE_INPUT_SELECT_REG flag

 .../bindings/pinctrl/fsl,imx7d-pinctrl.txt | 63 +-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
index 8bbf25d..aae069f 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
@@ -1,16 +1,42 @@
 * Freescale i.MX7 Dual IOMUX Controller
 
+iMX7D supports two iomuxc controllers, fsl,imx7d-iomuxc controller is similar
+as previous iMX SoC generation and fsl,imx7d-iomuxc-lpsr which provides low
+power state retention capabilities on gpios that are part of iomuxc-lpsr
+(GPIO1_IO7..GPIO1_IO0). While iomuxc-lpsr provides its own set of registers for
+mux and pad control settings, it shares the input select register from main
+iomuxc controller for daisy chain settings, the fsl,input-sel property extends
+fsl,imx-pinctrl driver to support iomuxc-lpsr controller.
+
+iomuxc_lpsr: iomuxc-lpsr@302c {
+   compatible = "fsl,imx7d-iomuxc-lpsr";
+   reg = <0x302c 0x1>;
+   fsl,input-sel = <&iomuxc>;
+};
+
+iomuxc: iomuxc@3033 {
+   compatible = "fsl,imx7d-iomuxc";
+   reg = <0x3033 0x1>;
+};
+
+Pheriparials using pads from iomuxc-lpsr support low state retention power
+state, under LPSR mode GPIO's state of pads are retain.
+
 Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
 and usage.
 
 Required properties:
-- compatible: "fsl,imx7d-iomuxc"
+- compatible: "fsl,imx7d-iomuxc" for main IOMUXC controller, or
+  "fsl,imx7d-iomuxc-lpsr" for Low Power State Retention IOMUXC controller.
 - fsl,pins: each entry consists of 6 integers and represents the mux and config
   setting for one pin.  The first 5 integers  are specified using a PIN_FUNC_ID macro, which can be found in
   imx7d-pinfunc.h under device tree source folder.  The last integer CONFIG is
   the pad setting value like pull-up on this pin.  Please refer to i.MX7 Dual
   Reference Manual for detailed CONFIG settings.
+- fsl,input-sel: required property for iomuxc-lpsr controller, this property is
+  a phandle for main iomuxc controller which shares the input select register 
for
+  daisy chain settings.
 
 CONFIG bits definition:
 PAD_CTL_PUS_100K_DOWN   (0 << 5)
@@ -25,3 +51,38 @@ PAD_CTL_DSE_X1  (0 << 0)
 PAD_CTL_DSE_X2  (1 << 0)
 PAD_CTL_DSE_X3  (2 << 0)
 PAD_CTL_DSE_X4  (3 << 0)
+
+Examples:
+While iomuxc-lpsr is intended to be used by dedicated peripherals to take
+advantages of LPSR power mode, is also possible that an IP to use pads from
+any of the iomux controllers. For example the I2C1 IP can use SCL pad from
+iomuxc-lpsr controller and SDA pad from iomuxc controller as:
+
+i2c1: i2c@30a2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>;
+   status = "okay";
+};
+
+iomuxc-lpsr@302c {
+   compatible = "fsl,imx7d-iomuxc-lpsr";
+   reg = <0x302c 0x1>;
+   fsl,input-sel = <&iomuxc>;
+
+   pinctrl_i2c1_1: i2c1grp-1 {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x407f
+   >;
+   };
+};
+
+iomuxc@3033 {
+   compatible = "fsl,imx7d-iomuxc";
+   reg = <0x3033 0x1>;
+
+   pinctrl_i2c1_2: i2c1grp-2 {
+   fsl,pins = <
+   MX7D_PAD_I2C1_SCL__I2C1_SCL 0x407f
+   >;
+   };
+};
-- 
2.1.4

--
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 v5 4/7] pinctrl: freescale: imx: allow mux_reg offset zero

[Adrian Alonso]

Allow mux_reg offset zero to be a valid pin_id, on imx7d
mux_conf reg offset is zero for iomuxc-lspr controller

Signed-off-by: Adrian Alonso 
---
Changes for V2: Resend
Changes for V3: Resend
Changes for V4: Simplify pin_id assigment when ZERO_OFFSET_VALID is set
Changes for V5:
- Drop patch pinctrl: freescale: imx: add ZERO_OFFSET_VALID flag
- Allow mux_reg ZERO OFFSET as pin_id

 drivers/pinctrl/freescale/pinctrl-imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
b/drivers/pinctrl/freescale/pinctrl-imx.c
index b9c6deb..23348d8 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -550,7 +550,7 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
conf_reg = -1;
}
 
-   pin_id = mux_reg ? mux_reg / 4 : conf_reg / 4;
+   pin_id = (mux_reg != -1) ? mux_reg / 4 : conf_reg / 4;
pin_reg = &info->pin_regs[pin_id];
pin->pin = pin_id;
grp->pin_ids[i] = pin_id;
-- 
2.1.4

--
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 v5 1/7] pinctrl: freescale: imx: fix system crash if enable two pinctl instances

[Adrian Alonso]

From: Robin Gong 

Fix system chrash caused by groups whose number is smaller than the number
of groups of the last pinctl instance which is not initialized.

iMX7D supports two iomux controllers (iomuxc-lpsr and iomuxc) on probing
the second instance (iomuxc) the chrash below occurs.

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.2.0-next-20150901-6-gebfa43c 
(aalonso@bluefly)
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7)
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasin 
instruction cache
[0.00] Machine model: Freescale i.MX7 SabreSD Board
[0.661012] [<802a6cb0>] (strcmp) from [<802cc80c>] 
(imx_dt_node_to_map+0x58/0x208)
[0.668879] [<802cc80c>] (imx_dt_node_to_map) from [<802cbe24>] 
(pinctrl_dt_to_map+0x174/0x2b0)
[0.677654] [<802cbe24>] (pinctrl_dt_to_map) from [<802c8f18>] 
(pinctrl_get+0x100/0x424)
[0.685878] [<802c8f18>] (pinctrl_get) from [<802c9510>] 
(pinctrl_register+0x26c/0x480)
[0.694104] [<802c9510>] (pinctrl_register) from [<802ccf3c>] 
(imx_pinctrl_probe+0x580/0x6e8)
[0.702706] [<802ccf3c>] (imx_pinctrl_probe) from [<80351b58>] 
(platform_drv_probe+0x44/0xa4)
[0.711455] [<80351b58>] (platform_drv_probe) from [<803503ec>] 
(driver_probe_device+0x174/0x2b4)
[0.720405] [<803503ec>] (driver_probe_device) from [<803505fc>] 
(__driver_attach+0x8c/0x90)
[0.728982] [<803505fc>] (__driver_attach) from [<8034e930>] 
(bus_for_each_dev+0x6c/0xa0)
[0.737381] [<8034e930>] (bus_for_each_dev) from [<8034fb88>] 
(bus_add_driver+0x148/0x1f0)
[0.745804] [<8034fb88>] (bus_add_driver) from [<80350c00>] 
(driver_register+0x78/0xf8)
[0.753880] [<80350c00>] (driver_register) from [<800097d0>] 
(do_one_initcall+0x8c/0x1d4)
[0.762282] [<800097d0>] (do_one_initcall) from [<80987dac>] 
(kernel_init_freeable+0x144/0x1e4)
[0.771061] [<80987dac>] (kernel_init_freeable) from [<806d9c7c>] 
(kernel_init+0x8/0xe8)
[0.779285] [<806d9c7c>] (kernel_init) from [<8000f628>] 
(ret_from_fork+0x14/0x2c)
[0.786981] Code: e352 e5e32001 1afb e12fff1e (e4d03001)

Signed-off-by: Robin Gong 
Signed-off-by: Adrian Alonso 
---
Chages for V2:
- Reorder patch series
- Add platform boot up information on kernel error
- Move gpr_index to imx_pinctrl_soc_info
Changes for V3:
- Rename grp_index to group_index
Changes for V4: Resend
Changes for V5: Resend

 drivers/pinctrl/freescale/pinctrl-imx.c | 3 +--
 drivers/pinctrl/freescale/pinctrl-imx.h | 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
b/drivers/pinctrl/freescale/pinctrl-imx.c
index d7b98ba..b9c6deb 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -580,7 +580,6 @@ static int imx_pinctrl_parse_functions(struct device_node 
*np,
struct device_node *child;
struct imx_pmx_func *func;
struct imx_pin_group *grp;
-   static u32 grp_index;
u32 i = 0;
 
dev_dbg(info->dev, "parse function(%d): %s\n", index, np->name);
@@ -599,7 +598,7 @@ static int imx_pinctrl_parse_functions(struct device_node 
*np,
 
for_each_child_of_node(np, child) {
func->groups[i] = child->name;
-   grp = &info->groups[grp_index++];
+   grp = &info->groups[info->group_index++];
imx_pinctrl_parse_groups(child, grp, info, i++);
}
 
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h 
b/drivers/pinctrl/freescale/pinctrl-imx.h
index 49e55d3..2a5fe72 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.h
+++ b/drivers/pinctrl/freescale/pinctrl-imx.h
@@ -78,6 +78,7 @@ struct imx_pinctrl_soc_info {
struct imx_pin_reg *pin_regs;
struct imx_pin_group *groups;
unsigned int ngroups;
+   unsigned int group_index;
struct imx_pmx_func *functions;
unsigned int nfunctions;
unsigned int flags;
-- 
2.1.4

--
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 v5 6/7] pinctrl: freescale: imx7d: support iomux lpsr controller

[Adrian Alonso]

iMX7D has two iomuxc controllers, iomuxc controller similar as
previous iMX SoC generation and iomuxc-lpsr which provides low
power state rentetion capabilities on gpios that are part of
iomuxc-lpsr

Add iomuxc-lpsr gpio group id's

Signed-off-by: Adrian Alonso 
---
Changes for V2: Add imx7d_lpsr_pads enums
Changes for V3: Resend
Changes for V4: Resend
Changes for V5: Remove flags SHARE_INPUT_SELECT_REG and
 ZERO_OFFSET_VALID.

 drivers/pinctrl/freescale/pinctrl-imx7d.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx7d.c 
b/drivers/pinctrl/freescale/pinctrl-imx7d.c
index 1fa7530..e901907 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx7d.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx7d.c
@@ -174,6 +174,17 @@ enum imx7d_pads {
MX7D_PAD_ENET1_COL = 154,
 };
 
+enum imx7d_lpsr_pads {
+   MX7D_PAD_GPIO1_IO00 = 0,
+   MX7D_PAD_GPIO1_IO01 = 1,
+   MX7D_PAD_GPIO1_IO02 = 2,
+   MX7D_PAD_GPIO1_IO03 = 3,
+   MX7D_PAD_GPIO1_IO04 = 4,
+   MX7D_PAD_GPIO1_IO05 = 5,
+   MX7D_PAD_GPIO1_IO06 = 6,
+   MX7D_PAD_GPIO1_IO07 = 7,
+};
+
 /* Pad names for the pinmux subsystem */
 static const struct pinctrl_pin_desc imx7d_pinctrl_pads[] = {
IMX_PINCTRL_PIN(MX7D_PAD_RESERVE0),
@@ -333,13 +344,31 @@ static const struct pinctrl_pin_desc imx7d_pinctrl_pads[] 
= {
IMX_PINCTRL_PIN(MX7D_PAD_ENET1_COL),
 };
 
+/* Pad names for the pinmux subsystem */
+static const struct pinctrl_pin_desc imx7d_lpsr_pinctrl_pads[] = {
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO00),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO01),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO02),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO03),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO04),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO05),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO06),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO07),
+};
+
 static struct imx_pinctrl_soc_info imx7d_pinctrl_info = {
.pins = imx7d_pinctrl_pads,
.npins = ARRAY_SIZE(imx7d_pinctrl_pads),
 };
 
+static struct imx_pinctrl_soc_info imx7d_lpsr_pinctrl_info = {
+   .pins = imx7d_lpsr_pinctrl_pads,
+   .npins = ARRAY_SIZE(imx7d_lpsr_pinctrl_pads),
+};
+
 static struct of_device_id imx7d_pinctrl_of_match[] = {
{ .compatible = "fsl,imx7d-iomuxc", .data = &imx7d_pinctrl_info, },
+   { .compatible = "fsl,imx7d-iomuxc-lpsr", .data = 
&imx7d_lpsr_pinctrl_info },
{ /* sentinel */ }
 };
 
-- 
2.1.4

--
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 v5 5/7] pinctrl: freescale: imx: add shared input select reg support

[Adrian Alonso]

- Add shared input select register support
- imx7d has two iomux controllers iomuxc and iomuxc-lpsr
  which share select_input register for daisy chain settings

Signed-off-by: Adrian Alonso 
---
Changes for V2: Resend
Changes for V3:
- Use of_parse_phandle instead of of_get_child_by_name to get input select
  base register address
Changes for V4: Resend
Changes for V5:
- Remove SHARE_INPUT_SELECT_REG flag
- Use fsl,input-sel to check if shared input select register support is used

 drivers/pinctrl/freescale/pinctrl-imx.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
b/drivers/pinctrl/freescale/pinctrl-imx.c
index 23348d8..c7946fa 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,7 @@ struct imx_pinctrl {
struct device *dev;
struct pinctrl_dev *pctl;
void __iomem *base;
+   void __iomem *input_sel_base;
const struct imx_pinctrl_soc_info *info;
 };
 
@@ -254,7 +256,12 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev, 
unsigned selector,
 * Regular select input register can never be at offset
 * 0, and we only print register value for regular case.
 */
-   writel(pin->input_val, ipctl->base + pin->input_reg);
+   if (ipctl->input_sel_base)
+   writel(pin->input_val, ipctl->input_sel_base +
+   pin->input_reg);
+   else
+   writel(pin->input_val, ipctl->base +
+   pin->input_reg);
dev_dbg(ipctl->dev,
"==>select_input: offset 0x%x val 0x%x\n",
pin->input_reg, pin->input_val);
@@ -682,6 +689,8 @@ static int imx_pinctrl_probe_dt(struct platform_device 
*pdev,
 int imx_pinctrl_probe(struct platform_device *pdev,
  struct imx_pinctrl_soc_info *info)
 {
+   struct device_node *dev_np = pdev->dev.of_node;
+   struct device_node *np;
struct imx_pinctrl *ipctl;
struct resource *res;
int ret, i;
@@ -712,6 +721,23 @@ int imx_pinctrl_probe(struct platform_device *pdev,
if (IS_ERR(ipctl->base))
return PTR_ERR(ipctl->base);
 
+   if (of_property_read_bool(dev_np, "fsl,input-sel")) {
+   np = of_parse_phandle(dev_np, "fsl,input-sel", 0);
+   if (np) {
+   ipctl->input_sel_base = of_iomap(np, 0);
+   if (IS_ERR(ipctl->input_sel_base)) {
+   of_node_put(np);
+   dev_err(&pdev->dev,
+   "iomuxc input select base address not 
found\n");
+   return PTR_ERR(ipctl->input_sel_base);
+   }
+   } else {
+   dev_err(&pdev->dev, "iomuxc fsl,input-sel property not 
found\n");
+   return -EINVAL;
+   }
+   of_node_put(np);
+   }
+
imx_pinctrl_desc.name = dev_name(&pdev->dev);
imx_pinctrl_desc.pins = info->pins;
imx_pinctrl_desc.npins = info->npins;
-- 
2.1.4

--
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 v5 2/7] ARM: dts: imx: imx7d add iomuxc lpsr device node

[Adrian Alonso]

Add device tree node to support iomuxc-lpsr controller, fsl,iput-sel
phandle allows to get input select register base address which is
shared from main iomuxc controller.

Signed-off-by: Adrian Alonso 
---
Changes for V2: Resend
Changes for V3: Add phandle to get input select register base address
Changes for V4: Resend
Changes for V5: Rename property to fsl,input-sel

 arch/arm/boot/dts/imx7d.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 15c2193..92ef0a9 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -446,6 +446,12 @@
status = "disabled";
};
 
+   iomuxc_lpsr: iomuxc-lpsr@302c {
+   compatible = "fsl,imx7d-iomuxc-lpsr";
+   reg = <0x302c 0x1>;
+   fsl,input-sel = <&iomuxc>;
+   };
+
gpt1: gpt@302d {
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x302d 0x1>;
-- 
2.1.4

--
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 v5 3/7] ARM: dts: imx: imx7d-sbd add iomuxc-lpsr hoggrp-2 pads

[Adrian Alonso]

Add imx7d-sdb iomuxc-lpsr hoggrp-2 default pads settings

Signed-off-by: Adrian Alonso 
---
Changes for V2: Resend
Changes for V3: Resend
Changes for V4: Resend
Changes for V5: Resend

 arch/arm/boot/dts/imx7d-sdb.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 8059458..c8a178c 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -419,3 +419,18 @@
 
};
 };
+
+&iomuxc_lpsr {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_hog_2>;
+
+   imx7d-sdb {
+   pinctrl_hog_2: hoggrp-2 {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO05__GPIO1_IO50x14
+   MX7D_PAD_GPIO1_IO07__GPIO1_IO70x59
+   MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
+   >;
+   };
+   };
+};
-- 
2.1.4

--
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 v11 3/4] add FPGA manager core

[atull]

On Thu, 24 Sep 2015, Dan Carpenter wrote:

> Of course, the maintainer gets the last word regardless of what anyone
> else thinks.
> 
> Generally, minimal code is better.  Trying to future proof code is a
> waste of time because you can't predict what will happen in the future.
> It's way more likely that some pointer you never expected to be NULL
> will be NULL instead of the few checked at the beginning of a function.
> Adding useless code uses RAM and makes the function slower.  It's a bit
> confusing for users as well because they will wonder when the NULL check
> is used.  A lot of times this sort of error handling is a bit fake and
> what I mean is that it looks correct but the system will just crash in a
> later function.
> 
> Also especially with a simple NULL dereferences like this theoretical
> one, it's better to just get the oops.  It kills the module but you get
> a good message in the log and it's normally straight forward to debug.
> 
> We spent a surprising amount of time discussing useless code.  I made
> someone redo a patch yesterday because they had incomplete error
> handling for a situation which could never happen.
> 
> regards,
> dan carpenter
> 
> 

Thanks for the discussion.

Interesting.  The amount of code bloat here compiles down to about two
machine instructions (in two places).  Actually a little more since I should
be using IS_ERR_OR_NULL.  But the main question is whether I should do
it at all.

The behaviour I should drive here is that the user will do their own error
checking.  After they get a pointer to a FPGA manager using
of_fpga_mgr_get(), they should check it and not assume that
fpga_mgr_firmware_load() will do it for them, i.e.

mgr = of_fpga_mgr_get(mgr_node);
if (IS_ERR(mgr))
return PTR_ERR(mgr);
fpga_mgr_firmware_load(mgr, flags, path);

I could take out these NULL pointer checks and it won't hurt anything unless
someone is just using the functions badly, in which case: kablooey.

Alan
--
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 v11 3/4] add FPGA manager core

[atull]

On Wed, 23 Sep 2015, Josh Cartwright wrote:

> On Wed, Sep 23, 2015 at 12:10:13PM -0500, atull wrote:
> > On Tue, 22 Sep 2015, Josh Cartwright wrote:
> [..]
> > > > +struct fpga_manager *of_fpga_mgr_get(struct device_node *node)
> > > > +{
> > > > +   struct fpga_manager *mgr;
> > > > +   struct device *dev;
> > > > +
> > > > +   if (!node)
> > > > +   return ERR_PTR(-EINVAL);
> > > > +
> > > > +   dev = class_find_device(fpga_mgr_class, NULL, node,
> > > > +   fpga_mgr_of_node_match);
> > > > +   if (!dev)
> > > > +   return ERR_PTR(-ENODEV);
> > > > +
> > > > +   mgr = to_fpga_manager(dev);
> > > > +   put_device(dev);
> > > 
> > > Who's ensuring the FPGA manager device's lifetime between _get and _put?
> > 
> > Well... get_device and put_device are not sufficient?
> 
> Sorry if I was too opaque.
> 
> You've just put_device()'d the only reference to the device you had
> here, so nothing is preventing from the device from being ripped away
> while it's being used.
> 
> You should remove the put_device() call here, and add a corresponding
> put_device() in fpga_mgr_put().
> 
> The module refcounting is also a bit strange, as you are
> acquiring/releasing a reference to THIS_MODULE, but you also should care
> about the lower-level driver's module refcount.
> 

Good call.  Thanks for the clarification.  I'll have something more robust
in v12.

> [..]
> > > > +   dt_label = of_get_property(mgr->dev.of_node, "label", NULL);
> > > > +   if (dt_label)
> > > > +   ret = dev_set_name(&mgr->dev, "%s", dt_label);
> > > > +   else
> > > > +   ret = dev_set_name(&mgr->dev, "fpga%d", id);
> > > 
> > > I'm wondering if an alias {} node is better for this.
> > 
> > I could look into that.  Is there an example of that you particularly
> > like for this?
> 
> Look at i2c's usage of the of_alias_*() functions.

OK yes, will use that in the next version.

Thanks for the review,
Alan

> 
>   Josh
> 
--
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 1/3] drivers: power: twl4030_charger: fix link problems when building as module

[Sebastian Reichel]

Hi,

On Thu, Sep 24, 2015 at 09:09:15PM +0200, Belisko Marek wrote:
> On Tue, Sep 22, 2015 at 11:29 PM, Sebastian Reichel  wrote:
> > On Tue, Sep 22, 2015 at 10:19:29PM +0200, Marek Belisko wrote:
> >> If either twl4030_charger or twl4030_madc is configured as MODULE,
> >> we get build (link) errors.
> >>
> >> To solve, the direct call of twl4030_get_madc_conversion() is replaced
> >> by a call to iio_read_channel_processed().
> >>
> >> Signed-off-by: H. Nikolaus Schaller 
> >> Signed-off-by: Marek Belisko 
> >> ---
> >> changes from V1: added missing iio_channel_release + document and add new 
> >> DT bindings
> >
> > That was fast :) Patchset looks fine to me except for one last
> > thing: Let's make the iio-channel optional, so that old DT blobs
> > are still supported. Also the IS_REACHABLE(CONFIG_TWL4030_MADC)
> > check can be removed, it should no longer be needed with
> > iio_read_channel_processed().
> OK I updated driver code to pass when 'vac' property isn't found in
> DT. Should I mark it also
> in DT bindings or keep it as it was in v2? Thanks.

Move it from "Required properties:" to "Optional properties:". Maybe
stating, that the feature does not work, if it's not provided.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH] pci-rcar-gen2: add R8A7794 support

[Bjorn Helgaas]

On Sat, Sep 12, 2015 at 02:06:09AM +0300, Sergei Shtylyov wrote:
> Add Renesas R8A7794 SoC support to the Renesas R-Car gen2 PCI driver.
> 
> Signed-off-by: Sergei Shtylyov 

Applied with Simon's ack to for-linus for v4.3, thanks!

I applied this for v4.3 instead of v4.4 because this is new hardware
and I think the chance of breaking anything is minimal.

> ---
> The patch is against the 'next' branch of Bjorn Helgaas' 'pci.git' repo.
> 
>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt |3 ++-
>  drivers/pci/host/pci-rcar-gen2.c|1 +
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> Index: pci/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> ===
> --- pci.orig/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ pci/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -7,7 +7,8 @@ OHCI and EHCI controllers.
>  
>  Required properties:
>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> -   "renesas,pci-r8a7791" for the R8A7791 SoC.
> +   "renesas,pci-r8a7791" for the R8A7791 SoC;
> +   "renesas,pci-r8a7794" for the R8A7794 SoC.
>  - reg:   A list of physical regions to access the device: the first is
>   the operational registers for the OHCI/EHCI controllers and the
>   second is for the bridge configuration and control registers.
> Index: pci/drivers/pci/host/pci-rcar-gen2.c
> ===
> --- pci.orig/drivers/pci/host/pci-rcar-gen2.c
> +++ pci/drivers/pci/host/pci-rcar-gen2.c
> @@ -362,6 +362,7 @@ static int rcar_pci_probe(struct platfor
>  static struct of_device_id rcar_pci_of_match[] = {
>   { .compatible = "renesas,pci-r8a7790", },
>   { .compatible = "renesas,pci-r8a7791", },
> + { .compatible = "renesas,pci-r8a7794", },
>   { },
>  };
>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bjorn Helgaas]

Hi Bharat,

I'm resending this since you sent a ping three days after I responded,
so I don't know whether you got this the first time around.

DMARC got turned on for mail coming from @google.com, which apparently
caused some email providers to drop it.  I switched to sending from
helg...@kernel.org to avoid that problem.

Bjorn

On Fri, Sep 18, 2015 at 03:37:36PM -0500, Bjorn Helgaas wrote:
> Hi Bharat,
> 
> On Thu, Aug 27, 2015 at 05:14:20PM +0530, Bharat Kumar Gogada wrote:
> > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> > diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> > index 140d66f..0f3a789 100644
> > --- a/drivers/pci/host/Makefile
> > +++ b/drivers/pci/host/Makefile
> > @@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
> >  obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
> >  obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
> >  obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
> > +obj-$(CONFIG_PCI_XILINX_NWL) += pci-xilinx-nwl.o
> 
> The other Xilinx driver uses "CONFIG_PCIE_*" and "pcie-xilinx.o".  Please
> use "pcie" similarly for this driver.
> 
> > +/**
> > + * struct nwl_msi - MSI information
> > + *
> > + * @chip: MSI controller
> > + * @used: Declare Bitmap for MSI
> > + * @domain: IRQ domain pointer
> > + * @pages: MSI pages
> > + * @lock: mutex lock
> > + * @irq_msi0: msi0 interrupt number
> > + * @irq_msi1: msi1 interrupt number
> 
> Please put these short comments inside the struct definition, on the same
> line as the element they describe.  It's needlessly repetitive to do it
> separately.
> 
> > + */
> > +struct nwl_msi {
> > +   struct msi_controller chip;
> > +   DECLARE_BITMAP(used, INT_PCI_MSI_NR);
> > +   struct irq_domain *domain;
> > +   unsigned long pages;
> > +   struct mutex lock;
> > +   int irq_msi0;
> > +   int irq_msi1;
> > +};
> 
> > +static inline bool nwl_pcie_is_link_up(struct nwl_pcie *pcie, u32 
> > check_bit)
> 
> Please name this "nwl_pcie_link_up" so it's consistent with most others
> (xilinx_pcie_link_is_up() is an exception).  I'm not sure the "check_bit"
> argument is really an improvement, since it makes the code a bit ugly and
> more different from other drivers than it would otherwise be.
> 
> > +{
> > +   unsigned int status = -EINVAL;
> > +
> > +   if (check_bit == PCIE_USER_LINKUP)
> > +   status = (readl(pcie->pcireg_base + PS_LINKUP_OFFSET) &
> > + PCIE_PHY_LINKUP_BIT) ? 1 : 0;
> > +   else if (check_bit == PHY_RDY_LINKUP)
> > +   status = (readl(pcie->pcireg_base + PS_LINKUP_OFFSET) &
> > + PHY_RDY_LINKUP_BIT) ? 1 : 0;
> > +   return status;
> > +}
> 
> > +static int nwl_setup_sspl(struct nwl_pcie *pcie)
> > +{
> > +   unsigned int status;
> > +   int check = 0;
> > +
> > +   do {
> > +   status = nwl_bridge_readl(pcie, TX_PCIE_MSG) & MSG_BUSY_BIT;
> > +   if (!status) {
> > +   /*
> > +* Generate the TLP message for a single EP
> > +* [TODO] Add a multi-endpoint code
> > +*/
> > +   nwl_bridge_writel(pcie, 0x0,
> > + TX_PCIE_MSG + TX_PCIE_MSG_CNTL);
> > +   nwl_bridge_writel(pcie, 0x0,
> > + TX_PCIE_MSG + TX_PCIE_MSG_SPEC_LO);
> > +   nwl_bridge_writel(pcie, 0x0,
> > + TX_PCIE_MSG + TX_PCIE_MSG_SPEC_HI);
> > +   nwl_bridge_writel(pcie, 0x0,
> > + TX_PCIE_MSG + TX_PCIE_MSG_DATA);
> > +   /* Pattern to generate SSLP TLP */
> > +   nwl_bridge_writel(pcie, PATTRN_SSLP_TLP,
> > + TX_PCIE_MSG + TX_PCIE_MSG_CNTL);
> > +   nwl_bridge_writel(pcie, RANDOM_DIGIT,
> > + TX_PCIE_MSG + TX_PCIE_MSG_DATA);
> > +   nwl_bridge_writel(pcie, nwl_bridge_readl(pcie,
> > + TX_PCIE_MSG) | 0x1, TX_PCIE_MSG);
> > +   status = 0;
> > +   do {
> > +   status = nwl_bridge_readl(pcie, TX_PCIE_MSG) &
> > + MSG_DONE_BIT;
> > +   if (!status && (check < 1)) {
> > +   mdelay(1);
> > +   check++;
> > +   } else {
> > +   return false;
> > +   }
> > +
> > +   } while (!status);
> > +   status = nwl_bridge_readl(pcie, TX_PCIE_MSG)
> > + & MSG_DONE_STATUS_BIT;
> > +   }
> > +   } while (status);
> > +
> > +   return true;
> 
> This function is defined to return "int."  It should not return "true" or
> "false."
> 
> I'm really confused about 

[PATCHv3 1/2] devicetree: Add TPS65217 charger binding.

[Enric Balletbo i Serra]

The TPS65217 charger is a subnode of the TPS65217 MFD.

Signed-off-by: Enric Balletbo i Serra 
---
 .../devicetree/bindings/power_supply/tps65217_charger.txt| 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/tps65217_charger.txt

diff --git 
a/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt 
b/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt
new file mode 100644
index 000..98d131a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt
@@ -0,0 +1,12 @@
+TPS65217 Charger
+
+Required Properties:
+-compatible: "ti,tps65217-charger"
+
+This node is a subnode of the tps65217 PMIC.
+
+Example:
+
+   tps65217-charger {
+   compatible = "ti,tps65090-charger";
+   };
-- 
2.1.0

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

[PATCHv3 2/2] power_supply: Add support for tps65217-charger.

[Enric Balletbo i Serra]

This patch adds support for the tps65217 charger driver. This driver is
responsible for controlling the charger aspect of the tps65217 mfd.
Currently, this mainly consists of turning on and off the charger, but
some other features of the charger can be supported through this driver.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/power/Kconfig|   7 ++
 drivers/power/Makefile   |   1 +
 drivers/power/tps65217_charger.c | 264 +++
 3 files changed, 272 insertions(+)
 create mode 100644 drivers/power/tps65217_charger.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index f8758d6..57fdc80 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -434,6 +434,13 @@ config CHARGER_TPS65090
 Say Y here to enable support for battery charging with TPS65090
 PMIC chips.
 
+config CHARGER_TPS65217
+   tristate "TPS65217 battery charger driver"
+   depends on MFD_TPS65217
+   help
+Say Y here to enable support for battery charging with TPS65217
+PMIC chips.
+
 config BATTERY_GAUGE_LTC2941
tristate "LTC2941/LTC2943 Battery Gauge Driver"
depends on I2C
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 5752ce8..c1409b3 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o
 obj-$(CONFIG_POWER_AVS)+= avs/
 obj-$(CONFIG_CHARGER_SMB347)   += smb347-charger.o
 obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
+obj-$(CONFIG_CHARGER_TPS65217) += tps65217_charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
 obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
 obj-$(CONFIG_AXP288_CHARGER)   += axp288_charger.o
diff --git a/drivers/power/tps65217_charger.c b/drivers/power/tps65217_charger.c
new file mode 100644
index 000..d9f5673
--- /dev/null
+++ b/drivers/power/tps65217_charger.c
@@ -0,0 +1,264 @@
+/*
+ * Battery charger driver for TI's tps65217
+ *
+ * Copyright (c) 2015, Collabora Ltd.
+
+ * 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 .
+ */
+
+/*
+ * Battery charger driver for TI's tps65217
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define POLL_INTERVAL  (HZ * 2)
+
+struct tps65217_charger {
+   struct tps65217 *tps;
+   struct device *dev;
+   struct power_supply *ac;
+
+   int ac_online;
+   int prev_ac_online;
+
+   struct task_struct  *poll_task;
+};
+
+static enum power_supply_property tps65217_ac_props[] = {
+   POWER_SUPPLY_PROP_ONLINE,
+};
+
+static int tps65217_config_charger(struct tps65217_charger *charger)
+{
+   int ret;
+
+   dev_dbg(charger->dev, "%s\n", __func__);
+
+   /*
+* tps65217 rev. G, p. 31 (see p. 32 for NTC schematic)
+*
+* The device can be configured to support a 100k NTC (B = 3960) by
+* setting the the NTC_TYPE bit in register CHGCONFIG1 to 1. However it
+* is not recommended to do so. In sleep mode, the charger continues
+* charging the battery, but all register values are reset to default
+* values. Therefore, the charger would get the wrong temperature
+* information. If 100k NTC setting is required, please contact the
+* factory.
+*
+* ATTENTION, conflicting information, from p. 46
+*
+* NTC TYPE (for battery temperature measurement)
+*   0 – 100k (curve 1, B = 3960)
+*   1 – 10k  (curve 2, B = 3480) (default on reset)
+*
+*/
+   ret = tps65217_clear_bits(charger->tps, TPS65217_REG_CHGCONFIG1,
+ TPS65217_CHGCONFIG1_NTC_TYPE,
+ TPS65217_PROTECT_NONE);
+   if (ret) {
+   dev_err(charger->dev,
+   "failed to set 100k NTC setting: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int tps65217_enable_charging(struct tps65217_charger *charger)
+{
+   int ret;
+
+   /* charger already enabled */
+   if (charger->ac_online)
+   return 0;
+
+   dev_dbg(charger->dev, "%s: enable charging\n", __func__);
+   ret = tps65217_set_bits(charger->tps, TPS65217_REG_CHGCONFIG1,
+   TPS65217_CHGCONFIG1_CHG_EN,

[PATCHv3 0/2] Add support for tps65217 charger

[Enric Balletbo i Serra]

Hi all,

The following series add initial support for tps65217 battery charger.

Changes since v2:
  - Requested by Sebastian Reichel
- Assign prev_ac_online to ac_online is no longer needed at this place.
- Remove power_supply_unregistersince it wouldb be called by managed 
resources.

Changes since v1:
  - Requested by Sebastian Reichel
- Set prev_ac_online at the beginning of the tps56217_charger_irq()
- Use devm_power_supply_register call.
  - Fix style problems reported by checkpatch.pl --strict

Best regards,

Enric Balletbo i Serra (2):
  devicetree: Add TPS65217 charger binding.
  power_supply: Add support for tps65217-charger.

 .../bindings/power_supply/tps65217_charger.txt |  12 +
 drivers/power/Kconfig  |   7 +
 drivers/power/Makefile |   1 +
 drivers/power/tps65217_charger.c   | 264 +
 4 files changed, 284 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/tps65217_charger.txt
 create mode 100644 drivers/power/tps65217_charger.c

-- 
2.1.0

--
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 RESEND v3 9/9] net: fix net_device refcounting

[Russell King]

of_find_net_device_by_node() uses class_find_device() internally to
lookup the corresponding network device.  class_find_device() returns
a reference to the embedded struct device, with its refcount
incremented.

Add a comment to the definition in net/core/net-sysfs.c indicating the
need to drop this refcount, and fix the DSA code to drop this refcount
when the OF-generated platform data is cleaned up and freed.  Also
arrange for the ref to be dropped when handling errors.

Signed-off-by: Russell King 
---
 net/core/net-sysfs.c | 9 +
 net/dsa/dsa.c| 5 -
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index b279077c3089..805a95a48107 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1481,6 +1481,15 @@ static int of_dev_node_match(struct device *dev, const 
void *data)
return ret == 0 ? dev->of_node == data : ret;
 }
 
+/*
+ * of_find_net_device_by_node - lookup the net device for the device node
+ * @np: OF device node
+ *
+ * Looks up the net_device structure corresponding with the device node.
+ * If successful, returns a pointer to the net_device with the embedded
+ * struct device refcount incremented by one, or NULL on failure. The
+ * refcount must be dropped when done with the net_device.
+ */
 struct net_device *of_find_net_device_by_node(struct device_node *np)
 {
struct device *dev;
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index bf4ba15fb780..c59fa5d9c22c 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -679,7 +679,7 @@ static int dsa_of_probe(struct device *dev)
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd) {
ret = -ENOMEM;
-   goto out_put_mdio;
+   goto out_put_ethernet;
}
 
dev->platform_data = pd;
@@ -773,6 +773,8 @@ static int dsa_of_probe(struct device *dev)
 out_free:
kfree(pd);
dev->platform_data = NULL;
+out_put_ethernet:
+   put_device(ðernet_dev->dev);
 out_put_mdio:
put_device(&mdio_bus->dev);
return ret;
@@ -786,6 +788,7 @@ static void dsa_of_remove(struct device *dev)
return;
 
dsa_of_free_platform_data(pd);
+   put_device(&pd->of_netdev->dev);
kfree(pd);
 }
 #else
-- 
2.1.0

--
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 RESEND v3 4/9] phy: add proper phy struct device refcounting

[Russell King]

Take a refcount on the phy struct device when the phy device is attached
to a network device, and drop it after it's detached.  This ensures that
a refcount is held on the phy device while the device is being used by
a network device, thereby preventing the phy_device from being
unexpectedly kfree()'d by phy_device_release().

Signed-off-by: Russell King 
---
 drivers/net/phy/phy_device.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 03adf328f49b..97a4f52addac 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -578,6 +578,7 @@ EXPORT_SYMBOL(phy_init_hw);
  * generic driver is used.  The phy_device is given a ptr to
  * the attaching device, and given a callback for link status
  * change.  The phy_device is returned to the attaching driver.
+ * This function takes a reference on the phy device.
  */
 int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
  u32 flags, phy_interface_t interface)
@@ -591,6 +592,8 @@ int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
return -EIO;
}
 
+   get_device(d);
+
/* Assume that if there is no driver, that it doesn't
 * exist, and we should use the genphy driver.
 */
@@ -636,6 +639,7 @@ int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
return err;
 
 error:
+   put_device(d);
module_put(bus->owner);
return err;
 }
@@ -679,6 +683,9 @@ EXPORT_SYMBOL(phy_attach);
 /**
  * phy_detach - detach a PHY device from its network device
  * @phydev: target phy_device struct
+ *
+ * This detaches the phy device from its network device and the phy
+ * driver, and drops the reference count taken in phy_attach_direct().
  */
 void phy_detach(struct phy_device *phydev)
 {
@@ -701,8 +708,13 @@ void phy_detach(struct phy_device *phydev)
}
}
 
+   /*
+* The phydev might go away on the put_device() below, so avoid
+* a use-after-free bug by reading the underlying bus first.
+*/
bus = phydev->bus;
 
+   put_device(&phydev->dev);
module_put(bus->owner);
 }
 EXPORT_SYMBOL(phy_detach);
-- 
2.1.0

--
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 RESEND v3 5/9] of_mdio: fix MDIO phy device refcounting

[Russell King]

bus_find_device() is defined as:

 * This is similar to the bus_for_each_dev() function above, but it
 * returns a reference to a device that is 'found' for later use, as
 * determined by the @match callback.

and it does indeed return a reference-counted pointer to the device:

while ((dev = next_device(&i)))
if (match(dev, data) && get_device(dev))
^^^
break;
klist_iter_exit(&i);
return dev;

What that means is that when we're done with the struct device, we must
drop that reference.  Neither of_phy_connect() nor of_phy_attach() did
this when phy_connect_direct() or phy_attach_direct() failed.

With our previous patch, phy_connect_direct() and phy_attach_direct()
take a new refcount on the phy device when successful, so we can drop
our local reference immediatley after these functions, whether or not
they succeeded.

Signed-off-by: Russell King 
---
 drivers/of/of_mdio.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 1350fa25cdb0..a87a868fed64 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -197,7 +197,8 @@ static int of_phy_match(struct device *dev, void *phy_np)
  * of_phy_find_device - Give a PHY node, find the phy_device
  * @phy_np: Pointer to the phy's device tree node
  *
- * Returns a pointer to the phy_device.
+ * If successful, returns a pointer to the phy_device with the embedded
+ * struct device refcount incremented by one, or NULL on failure.
  */
 struct phy_device *of_phy_find_device(struct device_node *phy_np)
 {
@@ -217,7 +218,9 @@ EXPORT_SYMBOL(of_phy_find_device);
  * @hndlr: Link state callback for the network device
  * @iface: PHY data interface type
  *
- * Returns a pointer to the phy_device if successful.  NULL otherwise
+ * If successful, returns a pointer to the phy_device with the embedded
+ * struct device refcount incremented by one, or NULL on failure. The
+ * refcount must be dropped by calling phy_disconnect() or phy_detach().
  */
 struct phy_device *of_phy_connect(struct net_device *dev,
  struct device_node *phy_np,
@@ -225,13 +228,19 @@ struct phy_device *of_phy_connect(struct net_device *dev,
  phy_interface_t iface)
 {
struct phy_device *phy = of_phy_find_device(phy_np);
+   int ret;
 
if (!phy)
return NULL;
 
phy->dev_flags = flags;
 
-   return phy_connect_direct(dev, phy, hndlr, iface) ? NULL : phy;
+   ret = phy_connect_direct(dev, phy, hndlr, iface);
+
+   /* refcount is held by phy_connect_direct() on success */
+   put_device(&phy->dev);
+
+   return ret ? NULL : phy;
 }
 EXPORT_SYMBOL(of_phy_connect);
 
@@ -241,17 +250,27 @@ EXPORT_SYMBOL(of_phy_connect);
  * @phy_np: Node pointer for the PHY
  * @flags: flags to pass to the PHY
  * @iface: PHY data interface type
+ *
+ * If successful, returns a pointer to the phy_device with the embedded
+ * struct device refcount incremented by one, or NULL on failure. The
+ * refcount must be dropped by calling phy_disconnect() or phy_detach().
  */
 struct phy_device *of_phy_attach(struct net_device *dev,
 struct device_node *phy_np, u32 flags,
 phy_interface_t iface)
 {
struct phy_device *phy = of_phy_find_device(phy_np);
+   int ret;
 
if (!phy)
return NULL;
 
-   return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
+   ret = phy_attach_direct(dev, phy, flags, iface);
+
+   /* refcount is held by phy_attach_direct() on success */
+   put_device(&phy->dev);
+
+   return ret ? NULL : phy;
 }
 EXPORT_SYMBOL(of_phy_attach);
 
-- 
2.1.0

--
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 RESEND v3 3/9] phy: fix mdiobus module safety

[Russell King]

Re-implement the mdiobus module refcounting to ensure that we actually
ensure that the mdiobus module code does not go away while we might call
into it.

The old scheme using bus->dev.driver was buggy, because bus->dev is a
class device which never has a struct device_driver associated with it,
and hence the associated code trying to obtain a refcount did nothing
useful.

Instead, take the approach that other subsystems do: pass the module
when calling mdiobus_register(), and record that in the mii_bus struct.
When we need to increment the module use count in the phy code, use
this stored pointer.  When the phy is deteched, drop the module
refcount, remembering that the phy device might go away at that point.

This doesn't stop the mii_bus going away while there are in-use phys -
it merely stops the underlying code vanishing.

Signed-off-by: Russell King 
---
 drivers/net/phy/mdio_bus.c   |  5 +++--
 drivers/net/phy/phy_device.c | 32 ++--
 include/linux/phy.h  |  5 -
 3 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 67553e13bd36..992406624b7c 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -244,7 +244,7 @@ static inline void of_mdiobus_link_phydev(struct mii_bus 
*mdio,
  *
  * Returns 0 on success or < 0 on error.
  */
-int mdiobus_register(struct mii_bus *bus)
+int __mdiobus_register(struct mii_bus *bus, struct module *owner)
 {
int i, err;
 
@@ -255,6 +255,7 @@ int mdiobus_register(struct mii_bus *bus)
BUG_ON(bus->state != MDIOBUS_ALLOCATED &&
   bus->state != MDIOBUS_UNREGISTERED);
 
+   bus->owner = owner;
bus->dev.parent = bus->parent;
bus->dev.class = &mdio_bus_class;
bus->dev.groups = NULL;
@@ -296,7 +297,7 @@ int mdiobus_register(struct mii_bus *bus)
device_del(&bus->dev);
return err;
 }
-EXPORT_SYMBOL(mdiobus_register);
+EXPORT_SYMBOL(__mdiobus_register);
 
 void mdiobus_unregister(struct mii_bus *bus)
 {
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c0f211127274..03adf328f49b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -582,10 +582,15 @@ EXPORT_SYMBOL(phy_init_hw);
 int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
  u32 flags, phy_interface_t interface)
 {
+   struct mii_bus *bus = phydev->bus;
struct device *d = &phydev->dev;
-   struct module *bus_module;
int err;
 
+   if (!try_module_get(bus->owner)) {
+   dev_err(&dev->dev, "failed to get the bus module\n");
+   return -EIO;
+   }
+
/* Assume that if there is no driver, that it doesn't
 * exist, and we should use the genphy driver.
 */
@@ -600,20 +605,13 @@ int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
err = device_bind_driver(d);
 
if (err)
-   return err;
+   goto error;
}
 
if (phydev->attached_dev) {
dev_err(&dev->dev, "PHY already attached\n");
-   return -EBUSY;
-   }
-
-   /* Increment the bus module reference count */
-   bus_module = phydev->bus->dev.driver ?
-phydev->bus->dev.driver->owner : NULL;
-   if (!try_module_get(bus_module)) {
-   dev_err(&dev->dev, "failed to get the bus module\n");
-   return -EIO;
+   err = -EBUSY;
+   goto error;
}
 
phydev->attached_dev = dev;
@@ -636,6 +634,10 @@ int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
phy_resume(phydev);
 
return err;
+
+error:
+   module_put(bus->owner);
+   return err;
 }
 EXPORT_SYMBOL(phy_attach_direct);
 
@@ -680,11 +682,9 @@ EXPORT_SYMBOL(phy_attach);
  */
 void phy_detach(struct phy_device *phydev)
 {
+   struct mii_bus *bus;
int i;
 
-   if (phydev->bus->dev.driver)
-   module_put(phydev->bus->dev.driver->owner);
-
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
phy_suspend(phydev);
@@ -700,6 +700,10 @@ void phy_detach(struct phy_device *phydev)
break;
}
}
+
+   bus = phydev->bus;
+
+   module_put(bus->owner);
 }
 EXPORT_SYMBOL(phy_detach);
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 962387a192f1..11bce44f6d65 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -153,6 +154,7 @@ struct sk_buff;
  * PHYs should register using this structure
  */
 struct mii_bus {
+   struct module *owner;
const char *name;
char id[MII_BUS_ID_SIZE];
void *priv;
@@ -198,7 +200,8 @@ static inline struct mii_

[PATCH RESEND v3 6/9] net: fix phy refcounting in a bunch of drivers

[Russell King]

of_phy_find_device() increments the phy struct device refcount, which
we need to properly balance.  Add code to network drivers using this
function to ensure that the struct device refcount is correctly
balanced.

For xgene, looking back in the history, we should be able to use
of_phy_connect() with a zero flags argument for the DT case as this is
how the driver used to operate prior to de7b5b3d790a ("net: eth: xgene:
change APM X-Gene SoC platform ethernet to support ACPI").

This leaves the Cavium Thunder BGX unfixed; fixing this driver is a
complicated task, one which the maintainers need to be involved with.

Signed-off-by: Russell King 
---
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 24 
 drivers/net/ethernet/freescale/gianfar.c   |  3 +++
 drivers/net/ethernet/freescale/ucc_geth.c  |  8 +++-
 drivers/net/ethernet/marvell/mvneta.c  |  2 ++
 drivers/net/ethernet/xilinx/xilinx_emaclite.c  |  2 ++
 5 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index cfa37041ab71..c4bb8027b3fb 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -689,16 +689,24 @@ static int xgene_enet_phy_connect(struct net_device *ndev)
netdev_dbg(ndev, "No phy-handle found in DT\n");
return -ENODEV;
}
-   pdata->phy_dev = of_phy_find_device(phy_np);
-   }
 
-   phy_dev = pdata->phy_dev;
+   phy_dev = of_phy_connect(ndev, phy_np, &xgene_enet_adjust_link,
+0, pdata->phy_mode);
+   if (!phy_dev) {
+   netdev_err(ndev, "Could not connect to PHY\n");
+   return -ENODEV;
+   }
+
+   pdata->phy_dev = phy_dev;
+   } else {
+   phy_dev = pdata->phy_dev;
 
-   if (!phy_dev ||
-   phy_connect_direct(ndev, phy_dev, &xgene_enet_adjust_link,
-  pdata->phy_mode)) {
-   netdev_err(ndev, "Could not connect to PHY\n");
-   return  -ENODEV;
+   if (!phy_dev ||
+   phy_connect_direct(ndev, phy_dev, &xgene_enet_adjust_link,
+  pdata->phy_mode)) {
+   netdev_err(ndev, "Could not connect to PHY\n");
+   return  -ENODEV;
+   }
}
 
pdata->phy_speed = SPEED_UNKNOWN;
diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index 4b69d061d90f..65a16086faec 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1702,6 +1702,7 @@ static void gfar_configure_serdes(struct net_device *dev)
tbiphy = of_phy_find_device(priv->tbi_node);
if (!tbiphy) {
dev_err(&dev->dev, "error: Could not get TBI device\n");
+   put_device(&tbiphy->dev);
return;
}
 
@@ -1723,6 +1724,8 @@ static void gfar_configure_serdes(struct net_device *dev)
phy_write(tbiphy, MII_BMCR,
  BMCR_ANENABLE | BMCR_ANRESTART | BMCR_FULLDPLX |
  BMCR_SPEED1000);
+
+   put_device(&tbiphy->dev);
 }
 
 static int __gfar_is_rx_idle(struct gfar_private *priv)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c 
b/drivers/net/ethernet/freescale/ucc_geth.c
index 4dd40e057f40..650f7888e32b 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -1384,6 +1384,8 @@ static int adjust_enet_interface(struct ucc_geth_private 
*ugeth)
value = phy_read(tbiphy, ENET_TBI_MII_CR);
value &= ~0x1000;   /* Turn off autonegotiation */
phy_write(tbiphy, ENET_TBI_MII_CR, value);
+
+   put_device(&tbiphy->dev);
}
 
init_check_frame_length_mode(ug_info->lengthCheckRx, &ug_regs->maccfg2);
@@ -1702,8 +1704,10 @@ static void uec_configure_serdes(struct net_device *dev)
 * everything for us?  Resetting it takes the link down and requires
 * several seconds for it to come back.
 */
-   if (phy_read(tbiphy, ENET_TBI_MII_SR) & TBISR_LSTATUS)
+   if (phy_read(tbiphy, ENET_TBI_MII_SR) & TBISR_LSTATUS) {
+   put_device(&tbiphy->dev);
return;
+   }
 
/* Single clk mode, mii mode off(for serdes communication) */
phy_write(tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
@@ -1711,6 +1715,8 @@ static void uec_configure_serdes(struct net_device *dev)
phy_write(tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
 
phy_write(tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
+
+   put_device(&tbiphy->dev);
 }
 
 /* Configure the PHY for dev.
diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/

[PATCH RESEND v3 8/9] phy: add phy_device_remove()

[Russell King]

Add a phy_device_remove() function to complement phy_device_register(),
which undoes the effects of phy_device_register() by removing the phy
device from visibility, but not freeing it.

This allows these details to be moved out of the mdio bus code into
the phy code where this action belongs.

Signed-off-by: Russell King 
---
 drivers/net/ethernet/freescale/gianfar.c |  5 +++--
 drivers/net/phy/mdio_bus.c   | 15 ++-
 drivers/net/phy/phy_device.c | 18 ++
 include/linux/phy.h  |  1 +
 4 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index 65a16086faec..903211df3288 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1702,7 +1702,6 @@ static void gfar_configure_serdes(struct net_device *dev)
tbiphy = of_phy_find_device(priv->tbi_node);
if (!tbiphy) {
dev_err(&dev->dev, "error: Could not get TBI device\n");
-   put_device(&tbiphy->dev);
return;
}
 
@@ -1711,8 +1710,10 @@ static void gfar_configure_serdes(struct net_device *dev)
 * everything for us?  Resetting it takes the link down and requires
 * several seconds for it to come back.
 */
-   if (phy_read(tbiphy, MII_BMSR) & BMSR_LSTATUS)
+   if (phy_read(tbiphy, MII_BMSR) & BMSR_LSTATUS) {
+   put_device(&tbiphy->dev);
return;
+   }
 
/* Single clk mode, mii mode off(for serdes communication) */
phy_write(tbiphy, MII_TBICON, TBICON_CLK_SELECT);
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 992406624b7c..c340e412b38f 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -291,8 +291,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module 
*owner)
 
 error:
while (--i >= 0) {
-   if (bus->phy_map[i])
-   device_unregister(&bus->phy_map[i]->dev);
+   struct phy_device *phydev = bus->phy_map[i];
+   if (phydev) {
+   phy_device_remove(phydev);
+   phy_device_free(phydev);
+   }
}
device_del(&bus->dev);
return err;
@@ -307,9 +310,11 @@ void mdiobus_unregister(struct mii_bus *bus)
bus->state = MDIOBUS_UNREGISTERED;
 
for (i = 0; i < PHY_MAX_ADDR; i++) {
-   if (bus->phy_map[i])
-   device_unregister(&bus->phy_map[i]->dev);
-   bus->phy_map[i] = NULL;
+   struct phy_device *phydev = bus->phy_map[i];
+   if (phydev) {
+   phy_device_remove(phydev);
+   phy_device_free(phydev);
+   }
}
device_del(&bus->dev);
 }
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 97a4f52addac..f761288abe66 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -384,6 +384,24 @@ int phy_device_register(struct phy_device *phydev)
 EXPORT_SYMBOL(phy_device_register);
 
 /**
+ * phy_device_remove - Remove a previously registered phy device from the MDIO 
bus
+ * @phydev: phy_device structure to remove
+ *
+ * This doesn't free the phy_device itself, it merely reverses the effects
+ * of phy_device_register(). Use phy_device_free() to free the device
+ * after calling this function.
+ */
+void phy_device_remove(struct phy_device *phydev)
+{
+   struct mii_bus *bus = phydev->bus;
+   int addr = phydev->addr;
+
+   device_del(&phydev->dev);
+   bus->phy_map[addr] = NULL;
+}
+EXPORT_SYMBOL(phy_device_remove);
+
+/**
  * phy_find_first - finds the first PHY device on the bus
  * @bus: the target MII bus
  */
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 11bce44f6d65..4a4e3a092337 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -745,6 +745,7 @@ struct phy_device *phy_device_create(struct mii_bus *bus, 
int addr, int phy_id,
 struct phy_c45_device_ids *c45_ids);
 struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
 int phy_device_register(struct phy_device *phy);
+void phy_device_remove(struct phy_device *phydev);
 int phy_init_hw(struct phy_device *phydev);
 int phy_suspend(struct phy_device *phydev);
 int phy_resume(struct phy_device *phydev);
-- 
2.1.0

--
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 RESEND v3 7/9] phy: fixed-phy: properly validate phy in fixed_phy_update_state()

[Russell King]

Validate that the phy_device passed into fixed_phy_update_state() is a
fixed-phy device before walking the list of phys for a fixed phy at the
same address.

Signed-off-by: Russell King 
---
 drivers/net/phy/fixed_phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index fb1299c6326e..e23bf5b90e17 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -220,7 +220,7 @@ int fixed_phy_update_state(struct phy_device *phydev,
struct fixed_mdio_bus *fmb = &platform_fmb;
struct fixed_phy *fp;
 
-   if (!phydev || !phydev->bus)
+   if (!phydev || phydev->bus != fmb->mii_bus)
return -EINVAL;
 
list_for_each_entry(fp, &fmb->phys, node) {
-- 
2.1.0

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