RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups

[Thomas Gleixner]

On Mon, 17 Jul 2017, Liang, Kan wrote:
> There are three proposed patches so far.
> Patch 1: The patch as above which speed up the hrtimer.
> Patch 2: Thomas's first proposal.
> https://patchwork.kernel.org/patch/9803033/
> https://patchwork.kernel.org/patch/9805903/
> Patch 3: my original proposal which increase the NMI watchdog timeout by 3X
> https://patchwork.kernel.org/patch/9802053/
> 
> According to our test, only patch 3 works well.
> The other two patches will hang the system eventually.
> For patch 1, the system hang after running our test case for ~1 hour.
> For patch 2, the system hang in running the overnight test.
> There is no error message shown when the system hang. So I don't know the
> root cause yet.

That doesn't make sense. What's the exact test procedure?

> BTW: We set 1 to watchdog_thresh when we did the test.
> It's believed that can speed up the failure.

Believe is not really a technical measure

Thanks,

tglx

Re: [PATCH 12/14] qcom: mtd: nand: change register offset defines with enums

[Abhishek Sahu]

On 2017-07-04 15:25, Archit Taneja wrote:

On 06/29/2017 12:46 PM, Abhishek Sahu wrote:

The current driver defines the register offset with preprocessor
macro which is defined crossponding to NAND controller version
1.4.0. This patch changes these macro with enumeration. It also
adds mapping array which contains controller register offsets for
each register offset enumeration. This mapping array will be
referenced before each register read and writes, where the register
offset enumeration is being replaced with actual register offsets.

Signed-off-by: Abhishek Sahu 
---
  drivers/mtd/nand/qcom_nandc.c | 136 
+++---

  1 file changed, 89 insertions(+), 47 deletions(-)

diff --git a/drivers/mtd/nand/qcom_nandc.c 
b/drivers/mtd/nand/qcom_nandc.c

index 6d749b6..24750e6 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -24,43 +24,6 @@
  #include 
  #include 

-/* NANDc reg offsets */
-#defineNAND_FLASH_CMD  0x00
-#defineNAND_ADDR0  0x04
-#defineNAND_ADDR1  0x08
-#defineNAND_FLASH_CHIP_SELECT  0x0c
-#defineNAND_EXEC_CMD   0x10
-#defineNAND_FLASH_STATUS   0x14
-#defineNAND_BUFFER_STATUS  0x18
-#defineNAND_DEV0_CFG0  0x20
-#defineNAND_DEV0_CFG1  0x24
-#defineNAND_DEV0_ECC_CFG   0x28
-#defineNAND_DEV1_ECC_CFG   0x2c
-#defineNAND_DEV1_CFG0  0x30
-#defineNAND_DEV1_CFG1  0x34
-#defineNAND_READ_ID0x40
-#defineNAND_READ_STATUS0x44
-#defineNAND_DEV_CMD0   0xa0
-#defineNAND_DEV_CMD1   0xa4
-#defineNAND_DEV_CMD2   0xa8
-#defineNAND_DEV_CMD_VLD0xac
-#defineSFLASHC_BURST_CFG   0xe0
-#defineNAND_ERASED_CW_DETECT_CFG   0xe8
-#defineNAND_ERASED_CW_DETECT_STATUS0xec
-#defineNAND_EBI2_ECC_BUF_CFG   0xf0
-#defineFLASH_BUF_ACC   0x100
-
-#defineNAND_CTRL   0xf00
-#defineNAND_VERSION0xf08
-#defineNAND_READ_LOCATION_00xf20
-#defineNAND_READ_LOCATION_10xf24
-#defineNAND_READ_LOCATION_20xf28
-#defineNAND_READ_LOCATION_30xf2c
-
-/* dummy register offsets, used by write_reg_dma */
-#defineNAND_DEV_CMD1_RESTORE   0xdead
-#defineNAND_DEV_CMD_VLD_RESTORE0xbeef
-
  /* NAND_FLASH_CMD bits */
  #define   PAGE_ACCBIT(4)
  #define   LAST_PAGE   BIT(5)
@@ -204,6 +167,44 @@
  #define QPIC_PER_CW_MAX_CMD_SGL   (32)
  #define QPIC_PER_CW_MAX_DATA_SGL  (8)

+/* NANDc reg offsets enumeration */
+enum {
+   NAND_FLASH_CMD,
+   NAND_ADDR0,
+   NAND_ADDR1,
+   NAND_FLASH_CHIP_SELECT,
+   NAND_EXEC_CMD,
+   NAND_FLASH_STATUS,
+   NAND_BUFFER_STATUS,
+   NAND_DEV0_CFG0,
+   NAND_DEV0_CFG1,
+   NAND_DEV0_ECC_CFG,
+   NAND_DEV1_ECC_CFG,
+   NAND_DEV1_CFG0,
+   NAND_DEV1_CFG1,
+   NAND_READ_ID,
+   NAND_READ_STATUS,
+   NAND_DEV_CMD0,
+   NAND_DEV_CMD1,
+   NAND_DEV_CMD2,
+   NAND_DEV_CMD_VLD,
+   SFLASHC_BURST_CFG,
+   NAND_ERASED_CW_DETECT_CFG,
+   NAND_ERASED_CW_DETECT_STATUS,
+   NAND_EBI2_ECC_BUF_CFG,
+   FLASH_BUF_ACC,
+   NAND_CTRL,
+   NAND_VERSION,
+   NAND_READ_LOCATION_0,
+   NAND_READ_LOCATION_1,
+   NAND_READ_LOCATION_2,
+   NAND_READ_LOCATION_3,
+
+   /* dummy register offsets, used by write_reg_dma */
+   NAND_DEV_CMD1_RESTORE,
+   NAND_DEV_CMD_VLD_RESTORE,
+};
+
  /*
   * This data type corresponds to the BAM transaction which will be 
used for all

   * NAND transfers.
@@ -326,6 +327,7 @@ struct nandc_regs {
   *bam dma
   * @max_cwperpage:maximum qpic codeword required. calcualted
   *from all nand device pagesize
+ * @regs_offsets:  register offset mapping array
   */
  struct qcom_nand_controller {
struct nand_hw_control controller;
@@ -371,6 +373,7 @@ struct qcom_nand_controller {

u32 cmd1, vld;
u32 ecc_modes;
+   const u32 *regs_offsets;


minor quirk:

s/regs_offsets/reg_offsets



 Sure. I will fix this in v2.


  };

  /*
@@ -434,6 +437,40 @@ struct qcom_nand_driver_data {
bool dma_bam_enabled;
  };

+/* Mapping table which contains the actual register offsets */
+static const u32 regs_offsets[] = {
+   [NAND_FLASH_CMD] = 0x00,
+   [NAND_ADDR0] = 0x04,
+   [NAND_ADDR1] = 0x08,
+   [NAND_FLASH_CHIP_SELECT] = 0x0c,
+   

Re: [PATCH v5 1/2] clk: gate: expose clk_gate_ops::is_enabled

[Gabriel FERNANDEZ]

Hi Stephen,


On 07/14/2017 08:52 PM, kbuild test robot wrote:
> Hi Gabriel,
>
> [auto build test ERROR on clk/clk-next]
> [also build test ERROR on v4.12 next-20170714]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/gabriel-fernandez-st-com/clk-stm32h7-Add-stm32h743-clock-driver/20170714-170518
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> config: arm-lpc32xx_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
>  wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
>  chmod +x ~/bin/make.cross
>  # save the attached .config to linux build tree
>  make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
>>> drivers/clk/nxp/clk-lpc32xx.c:906:12: error: static declaration of 
>>> 'clk_gate_is_enabled' follows non-static declaration
>  static int clk_gate_is_enabled(struct clk_hw *hw)
> ^~~
> In file included from drivers/clk/nxp/clk-lpc32xx.c:13:0:
> include/linux/clk-provider.h:346:5: note: previous declaration of 
> 'clk_gate_is_enabled' was here
>  int clk_gate_is_enabled(struct clk_hw *hw);
>  ^~~
>
> vim +/clk_gate_is_enabled +906 drivers/clk/nxp/clk-lpc32xx.c
>
> f7c82a60 Vladimir Zapolskiy 2015-12-06  905
> f7c82a60 Vladimir Zapolskiy 2015-12-06 @906  static int 
> clk_gate_is_enabled(struct clk_hw *hw)
> f7c82a60 Vladimir Zapolskiy 2015-12-06  907  {
> f7c82a60 Vladimir Zapolskiy 2015-12-06  908   struct lpc32xx_clk_gate *clk = 
> to_lpc32xx_gate(hw);
> f7c82a60 Vladimir Zapolskiy 2015-12-06  909   u32 val;
> f7c82a60 Vladimir Zapolskiy 2015-12-06  910   bool is_set;
> f7c82a60 Vladimir Zapolskiy 2015-12-06  911
> f7c82a60 Vladimir Zapolskiy 2015-12-06  912   regmap_read(clk_regmap, 
> clk->reg, );
> f7c82a60 Vladimir Zapolskiy 2015-12-06  913   is_set = val & 
> BIT(clk->bit_idx);
> f7c82a60 Vladimir Zapolskiy 2015-12-06  914
> f7c82a60 Vladimir Zapolskiy 2015-12-06  915   return (clk->flags & 
> CLK_GATE_SET_TO_DISABLE ? !is_set : is_set);
> f7c82a60 Vladimir Zapolskiy 2015-12-06  916  }
> f7c82a60 Vladimir Zapolskiy 2015-12-06  917  
> EXPORT_SYMBOL_GPL(__clk_gate_is_enabled);
>
>
> :: The code at line 906 was first introduced by commit
> :: f7c82a60ba26c2f003662bcb2cff131021c1e828 clk: lpc32xx: add common 
> clock framework driver
>
> :: TO: Vladimir Zapolskiy 
> :: CC: Michael Turquette 
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Rename 'clk_gate_is_enabled' into'__clk_gate_is_enabled' from clk-gate.c 
file, is it a good solution for you ?

i could add also EXPORT_SYMBOL_GPL(__clk_gate_is_enabled) if you are ok.


Best Regards
Gabriel

[PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

[Caesar Wang]

This patch adds the MALI's power-model to set the IPA model to be used
for power management.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index a461e47..b616e6b 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -37,6 +37,18 @@ Optional properties:
 - operating-points-v2 : Refer to 
Documentation/devicetree/bindings/power/opp.txt
   for details.
 
+- power_model : Sets power model parameters. Note that this model was designed 
for the Juno
+   platform, and may not be suitable for other platforms. A 
structure containing :
+   - compatible: Should be arm,mali-simple-power-model
+   - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied
+ by v^2*f to calculate the dynamic power consumption.
+   - static-coefficient: Coefficient, in uW/V^3, which is multiplied by
+ v^3 to calculate the static power consumption.
+   - ts: An array containing coefficients for the temperature scaling
+ factor. This is used to scale the static power by a factor of
+ tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0],
+ and T = temperature in degrees.
+   - thermal-zone: A string identifying the thermal zone used for the GPU
 
 Example for a Mali-T760:
 
-- 
2.7.4

[PATCH v2 5/5] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Caesar Wang]

As RK3399 had used the Power allocator thermal governor by default,
enabled this to manage thermals by dynamically allocating and limiting
power to devices.

Also, this patch supported the dynamic-power-coefficient/sustainable_power
and GPU's power model for needed parameters with thermal IPA.

The Thermal power allocator governor works optimatly with two passive trip
points, for the better performance we will use the trip-point0 with 70
degree above which the governor control starts operating and trip-point1
with 85 degree is the target temperature by controlling.

Signed-off-by: Caesar Wang 

---

Changes in v2:
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++-
 1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 77d67cb..6d8a5eb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -147,7 +147,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
 
cpu_b1: cpu@101 {
@@ -156,7 +156,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
};
 
@@ -690,24 +690,25 @@
};
 
thermal_zones: thermal-zones {
-   cpu_thermal: cpu {
+   soc_thermal: soc-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
+   sustainable-power = <1000>;
 
thermal-sensors = < 0>;
 
trips {
-   cpu_alert0: cpu_alert0 {
+   threshold: trip-point0 {
temperature = <7>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_alert1: cpu_alert1 {
-   temperature = <75000>;
+   target: trip-point1 {
+   temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_crit: cpu_crit {
+   soc_crit: soc-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -716,45 +717,31 @@
 
cooling-maps {
map0 {
-   trip = <_alert0>;
+   trip = <>;
cooling-device =
-   <_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
map1 {
-   trip = <_alert1>;
+   trip = <>;
cooling-device =
-   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
<_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <1024>;
+   };
+   map2 {
+   trip = <>;
+   cooling-device =
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
};
};
 
-   gpu_thermal: gpu {
+   gpu_thermal: gpu-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
 
thermal-sensors = < 1>;
-
-   trips {
-   gpu_alert0: gpu_alert0 {
-   temperature = <75000>;
-   

Re: [PATCH 0/5] Add a script to check for Sphinx install requirements

[Markus Heiser]

> Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab 
> :
> 
> [1] There's an unrelated bug with the Kernel's sphinx extension
> kimage: when parsing GraphViz graphs, it uses "-Tpdf" argument,
> in order to generate a PDF image. That doesn't work on some
> distros, as GraphViz doesn't support PDF images. 
> 

Hmm .. http://www.graphviz.org/content/output-formats#dpdf

Is it a problem of the GraphViz version?

See http://www.graphviz.org/News.php ..

  """New Release 2.32 (1 August 2013)

 ... In addition, if the poppler library is available, Graphviz
 can now use PDF files as images."""

I suppose that 2.32 is in your distro .. it's from 2013

It seems, that the graphiz homepage is not up to date. I found 
the repo at github. There is a issue about PDF

  https://github.com/ellson/graphviz/issues/1180

So I guess graphviz is compiled without HAVE_PANGOCAIRO in your
distros?

-- Markus --

[PATCH v2 4/5] arm64: dts: rockchip: enable the GPU for RK3399-GRU

[Caesar Wang]

This patch enables the gpu and adds the mali-supply power for RK3399-GRU
devices.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 90259cf..d48e98b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -595,6 +595,11 @@
status = "okay";
 };
 
+ {
+   mali-supply = <_gpu>;
+   status = "okay";
+};
+
 ap_i2c_mic:  {
status = "okay";
 
-- 
2.7.4

Re: [PATCH v2 1/3] mux: Add mux_control_get_optional() API

[Peter Rosin]

Generally looks like I imagined, but there are a few nits and some
things that I'd like to do differently. Comments inline. Thanks!

On 2017-07-14 23:40, Stephen Boyd wrote:
> Sometimes drivers only use muxes under certain scenarios. For
> example, the chipidea usb controller may be connected to a usb
> switch on some platforms, and connected directly to a usb port on
> others. The driver won't know one way or the other though, so add
> a mux_control_get_optional() API that allows the driver to
> differentiate errors getting the mux from there not being a mux
> for the driver to use at all.
> 
> Cc: Jonathan Cameron 
> Cc: Philipp Zabel 
> Signed-off-by: Stephen Boyd 
> ---
>  Documentation/driver-model/devres.txt |  1 +
>  drivers/mux/mux-core.c| 98 
> ---
>  include/linux/mux/consumer.h  |  4 ++
>  3 files changed, 83 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/driver-model/devres.txt 
> b/Documentation/driver-model/devres.txt
> index 30e04f7a690d..4fdd3e63ff8b 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -342,6 +342,7 @@ MUX
>devm_mux_chip_alloc()
>devm_mux_chip_register()
>devm_mux_control_get()
> +  devm_mux_control_get_optional()
>  
>  PER-CPU MEM
>devm_alloc_percpu()
> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
> index 90b8995f07cb..a0e5bf16f02f 100644
> --- a/drivers/mux/mux-core.c
> +++ b/drivers/mux/mux-core.c
> @@ -289,6 +289,9 @@ EXPORT_SYMBOL_GPL(devm_mux_chip_register);
>   */
>  unsigned int mux_control_states(struct mux_control *mux)
>  {
> + if (!mux)
> + return 0;
> +

I don't think this is appropriate. For this function, it might be ok,
but...

>   return mux->states;
>  }
>  EXPORT_SYMBOL_GPL(mux_control_states);
> @@ -338,6 +341,9 @@ int mux_control_select(struct mux_control *mux, unsigned 
> int state)
>  {
>   int ret;
>  
> + if (!mux)
> + return 0;
> +

...here and for other cases below it's very odd to return "ok", when
-EINVAL or something seems much more appropriate. And if -EINVAL is
returned here, the benefit of returning fake values for anything
pretty much falls apart.

I simply don't like it, and prefer if the consumer code is arranged
to not call the mux functions when the optional get() does not find
the mux.

>   ret = down_killable(>lock);
>   if (ret < 0)
>   return ret;
> @@ -370,6 +376,9 @@ int mux_control_try_select(struct mux_control *mux, 
> unsigned int state)
>  {
>   int ret;
>  
> + if (!mux)
> + return 0;
> +
>   if (down_trylock(>lock))
>   return -EBUSY;
>  
> @@ -398,6 +407,9 @@ int mux_control_deselect(struct mux_control *mux)
>  {
>   int ret = 0;
>  
> + if (!mux)
> + return 0;
> +
>   if (mux->idle_state != MUX_IDLE_AS_IS &&
>   mux->idle_state != mux->cached_state)
>   ret = mux_control_set(mux, mux->idle_state);
> @@ -422,14 +434,8 @@ static struct mux_chip *of_find_mux_chip_by_node(struct 
> device_node *np)
>   return dev ? to_mux_chip(dev) : NULL;
>  }
>  
> -/**
> - * mux_control_get() - Get the mux-control for a device.
> - * @dev: The device that needs a mux-control.
> - * @mux_name: The name identifying the mux-control.
> - *
> - * Return: A pointer to the mux-control, or an ERR_PTR with a negative errno.
> - */
> -struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
> +struct mux_control *
> +__mux_control_get(struct device *dev, const char *mux_name, bool optional)
>  {
>   struct device_node *np = dev->of_node;
>   struct of_phandle_args args;
> @@ -441,6 +447,8 @@ struct mux_control *mux_control_get(struct device *dev, 
> const char *mux_name)
>   if (mux_name) {
>   index = of_property_match_string(np, "mux-control-names",
>mux_name);
> + if (index == -EINVAL && optional)
> + return NULL;

What about -ENODATA? And if an optional mux is found here, but lookup
fails later in e.g. the of_parse_phandle_with_args call, then I think
an error should be returned. Because that seems like an indication that
DT specifies that there *should* be a mux, but then there isn't one.

>   if (index < 0) {
>   dev_err(dev, "mux controller '%s' not found\n",
>   mux_name);
> @@ -451,6 +459,8 @@ struct mux_control *mux_control_get(struct device *dev, 
> const char *mux_name)
>   ret = of_parse_phandle_with_args(np,
>"mux-controls", "#mux-control-cells",
>index, );
> + if (ret == -ENOENT && optional)
> + return NULL;
>   if (ret) {
>   dev_err(dev, "%s: failed to get mux-control 

Re: [PATCH] EDAC: remove unnecessary static in edac_fake_inject_write()

[Borislav Petkov]

On Tue, Jul 04, 2017 at 04:44:40PM -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variable _type_.
> Such variable is initialized before being used,
> on every execution path throughout the function.
> The static has no benefit and, removing it reduces
> the code size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> 
> @bad exists@
> position p;
> identifier x;
> type T;
> @@
> 
> static T x@p;
> ...
> x = <+...x...+>
> 
> @@
> identifier x;
> expression e;
> type T;
> position p != bad.p;
> @@
> 
> -static
>  T x@p;
>  ... when != x
>  when strict
> ?x = e;

So the fix is ok but I don't understand Coccinelle to be able to judge
whether the above patch is fine or not. If it is, it probably should be
put somewhere in scripts/coccinelle/ so that others can use it too so
that they can catch such useless uses of static too.

Lemme add the Coccinelle ML to CC.

(Leaving in the rest for reference.)

> In the following log you can see the difference in the code size and,
> also a significant difference in bss segment. This log is the output
> of the size command, before and after the code change:
> 
> before:
>textdata bss dec hex filename
>2966 920 1284014 fae drivers/edac/debugfs.o
> 
> after:
>text data bssdec hex filename
>2961 832  643857 f11 drivers/edac/debugfs.o
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/edac/debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/edac/debugfs.c b/drivers/edac/debugfs.c
> index 92dbb7e..ba0af49 100644
> --- a/drivers/edac/debugfs.c
> +++ b/drivers/edac/debugfs.c
> @@ -8,7 +8,7 @@ static ssize_t edac_fake_inject_write(struct file *file,
>  {
>   struct device *dev = file->private_data;
>   struct mem_ctl_info *mci = to_mci(dev);
> - static enum hw_event_mc_err_type type;
> + enum hw_event_mc_err_type type;
>   u16 errcount = mci->fake_inject_count;
>  
>   if (!errcount)
> -- 
> 2.5.0
> 

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH v2] mm/vmalloc: terminate searching since one node found

[zijun_hu]

On 07/17/2017 04:07 PM, Zhaoyang Huang wrote:
> It is no need to find the very beginning of the area within
> alloc_vmap_area, which can be done by judging each node during the process
> 
> For current approach, the worst case is that the starting node which be found
> for searching the 'vmap_area_list' is close to the 'vstart', while the final
> available one is round to the tail(especially for the left branch).
> This commit have the list searching start at the first available node, which
> will save the time of walking the rb tree'(1)' and walking the list(2).
> 
>   vmap_area_root
>   /  \
>  tmp_next U
> /   (1)
>   tmp
>/
>  ...
>   /
> first(current approach)
> 
> vmap_area_list->...->first->...->tmp->tmp_next

the original code can ensure the following two points :
A, the result vamp_area has the lowest available address in the range [vstart, 
vend)
B, it can maintain the cached vamp_area node rightly which can speedup relative 
allocation
i suspect this patch maybe destroy the above two points 
> (2)
> 
> Signed-off-by: Zhaoyang Huang 
> ---
>  mm/vmalloc.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 34a1c3e..f833e07 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -459,9 +459,16 @@ static struct vmap_area *alloc_vmap_area(unsigned
> long size,
> 
> while (n) {
> struct vmap_area *tmp;
> +   struct vmap_area *tmp_next;
> tmp = rb_entry(n, struct vmap_area, rb_node);
> +   tmp_next = list_next_entry(tmp, list);
> if (tmp->va_end >= addr) {
> first = tmp;
> +   if (ALIGN(tmp->va_end, align) + size
> +   < tmp_next->va_start) {
> +   addr = ALIGN(tmp->va_end, align);
> +   goto found;
> +   }
is the aim vamp_area the lowest available one if the goto occurs ?
it will bypass the latter cached vamp_area info  cached_hole_size update 
possibly if the goto occurs
> if (tmp->va_start <= addr)
> break;
> n = n->rb_left;
> --
> 1.9.1
> 

Re: [PATCH 02/18] drm/sun4i: Add if statement instead of depends on

[Maxime Ripard]

On Fri, Jul 14, 2017 at 11:09:07AM +0800, Chen-Yu Tsai wrote:
> On Thu, Jul 13, 2017 at 10:12 PM, Maxime Ripard
>  wrote:
> > The depends on relationship is obvious, and using an if statement will
> > propagate it to every option without the need for each and every one of
> > them to define it.
> >
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.

[Chanwoo Choi]

Hi Enric,

When I tried to apply this patch, error happened as following:
(based on v4.13-rc1)

Applying: extcon: cros-ec: Add extcon-cros-ec driver to support display out.
error: patch failed: include/linux/mfd/cros_ec_commands.h:285
error: include/linux/mfd/cros_ec_commands.h: patch does not apply

Is it based on v4.13-rc1?


On 2017년 07월 17일 16:37, Enric Balletbo i Serra wrote:
> From: Benson Leung 
> 
> This is the driver for the USB Type C cable detection mechanism
> built into the ChromeOS Embedded Controller on systems that
> have USB Type-C ports.
> 
> At present, this allows for the presence of display out, but in
> future, it may also be used to notify host and device type cables
> and the presence of power.
> 
> Signed-off-by: Benson Leung 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Chanwoo Choi 
> Acked-by: Lee Jones 
> ---
> Changes since v2:
>  - Rebase on top of v4.13-rc1
> Changes since v1:
>  Requested by Chanwoo Choi
>  - Rename files changing _ for -
>  - Remove the unneeded blank line on bottom of header.
>  - Remove kobject.h and cros_ec_commands.h includes.
>  - Remove the debug message as is not necessary.
>  - Use the tab for indentation instead of space for if sentence.
>  - Define each variable on different lines when the variables should be
>initialized.
>  - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now.
>  - Add one blank line to split out between state and property setting.
>  - Add the author information (header and module)
> 
>  Enric Balletbo
>  - As Rob suggested to rename the compatible name to something indicating that
>is USB Type C related I also renamed the file names, extcon-cros-ec ->
>extcon-usbc-cros-ec, I think it's more clear.
> 
>  drivers/extcon/Kconfig   |   7 +
>  drivers/extcon/Makefile  |   1 +
>  drivers/extcon/extcon-usbc-cros-ec.c | 415 
> +++
>  include/linux/mfd/cros_ec_commands.h |  75 +++
>  4 files changed, 498 insertions(+)
>  create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c
> 
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6d50071..a7bca42 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -150,4 +150,11 @@ config EXTCON_USB_GPIO
> Say Y here to enable GPIO based USB cable detection extcon support.
> Used typically if GPIO is used for USB ID pin detection.
>  
> +config EXTCON_USBC_CROS_EC
> + tristate "ChromeOS Embedded Controller EXTCON support"
> + depends on MFD_CROS_EC
> + help
> +   Say Y here to enable USB Type C cable detection extcon support when
> +   using Chrome OS EC based USB Type-C ports.
> +
>  endif
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index ecfa958..a73624e 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -20,3 +20,4 @@ obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += 
> extcon-qcom-spmi-misc.o
>  obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
>  obj-$(CONFIG_EXTCON_SM5502)  += extcon-sm5502.o
>  obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o
> +obj-$(CONFIG_EXTCON_USBC_CROS_EC) += extcon-usbc-cros-ec.o
> diff --git a/drivers/extcon/extcon-usbc-cros-ec.c 
> b/drivers/extcon/extcon-usbc-cros-ec.c
> new file mode 100644
> index 000..e759ed4
> --- /dev/null
> +++ b/drivers/extcon/extcon-usbc-cros-ec.c
> @@ -0,0 +1,415 @@
> +/**
> + * drivers/extcon/extcon-usbc-cros-ec - ChromeOS Embedded Controller extcon
> + *
> + * Copyright (C) 2017 Google, Inc
> + * Author: Benson Leung 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct cros_ec_extcon_info {
> + struct device *dev;
> + struct extcon_dev *edev;
> +
> + int port_id;
> +
> + struct cros_ec_device *ec;
> +
> + struct notifier_block notifier;
> +
> + bool dp; /* DisplayPort enabled */
> + bool mux; /* SuperSpeed (usb3) enabled */
> + unsigned int power_type;
> +};
> +
> +static const unsigned int usb_type_c_cable[] = {
> + EXTCON_DISP_DP,
> + EXTCON_NONE,
> +};
> +
> +/**
> + * cros_ec_pd_command() - Send a command to the EC.
> + * @info: pointer to struct cros_ec_extcon_info
> + * @command: EC command
> + * @version: EC command version
> + * @outdata: EC command output data
> + * 

Re: [PATCH v6 2/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver

[Maxime Ripard]

Hi,

On Fri, Jul 14, 2017 at 05:49:24PM +0300, Priit Laes wrote:
> Introduce a clock controller driver for sun4i A10 and sun7i A20
> series SoCs.
> 
> Signed-off-by: Priit Laes 
> ---
>  drivers/clk/sunxi-ng/Kconfig  |   13 +-
>  drivers/clk/sunxi-ng/Makefile |1 +-
>  drivers/clk/sunxi-ng/ccu-sun4i-a10.c  | 1454 ++-
>  drivers/clk/sunxi-ng/ccu-sun4i-a10.h  |   61 +-
>  include/dt-bindings/clock/sun4i-a10-ccu.h |  200 +++-
>  include/dt-bindings/clock/sun7i-a20-ccu.h |   53 +-
>  include/dt-bindings/reset/sun4i-a10-ccu.h |   69 +-
>  7 files changed, 1851 insertions(+)
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun4i-a10.c
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun4i-a10.h
>  create mode 100644 include/dt-bindings/clock/sun4i-a10-ccu.h
>  create mode 100644 include/dt-bindings/clock/sun7i-a20-ccu.h
>  create mode 100644 include/dt-bindings/reset/sun4i-a10-ccu.h
> 
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> index 7342928..1b5cea9 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -11,6 +11,19 @@ config SUN50I_A64_CCU
>   default ARM64 && ARCH_SUNXI
>   depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>  
> +config SUNXI_A10_CCU
> + bool "Support for the Allwinner A10/A20 CCU"
> + select SUNXI_CCU_DIV
> + select SUNXI_CCU_MULT
> + select SUNXI_CCU_NK
> + select SUNXI_CCU_NKM
> + select SUNXI_CCU_NM
> + select SUNXI_CCU_MP
> + select SUNXI_CCU_PHASE
> + default MACH_SUN4I
> + default MACH_SUN7I
> + depends on MACH_SUN4I || MACH_SUN7I || COMPILE_TEST

I'm a bit late on this one, but I agree with Olliver, it should be
called SUN4I_A10. This is what we do for all the other symbols (and it
should be ordered as such).

> +
>  config SUN5I_CCU
>   bool "Support for the Allwinner sun5i family CCM"
>   default MACH_SUN5I
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
> index 0c45fa5..01e958c 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -21,6 +21,7 @@ lib-$(CONFIG_SUNXI_CCU) += ccu_mp.o
>  obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
>  obj-$(CONFIG_SUN5I_CCU)  += ccu-sun5i.o
>  obj-$(CONFIG_SUN6I_A31_CCU)  += ccu-sun6i-a31.o
> +obj-$(CONFIG_SUNXI_A10_CCU)  += ccu-sun4i-a10.o

The ordering is wrong here too.

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

[Michal Hocko]

On Sun 16-07-17 19:59:51, Tetsuo Handa wrote:
> Since the whole memory reclaim path has never been designed to handle the
> scheduling priority inversions, those locations which are assuming that
> execution of some code path shall eventually complete without using
> synchronization mechanisms can get stuck (livelock) due to scheduling
> priority inversions, for CPU time is not guaranteed to be yielded to some
> thread doing such code path.
> 
> mutex_trylock() in __alloc_pages_may_oom() (waiting for oom_lock) and
> schedule_timeout_killable(1) in out_of_memory() (already held oom_lock) is
> one of such locations, and it was demonstrated using artificial stressing
> that the system gets stuck effectively forever because SCHED_IDLE priority
> thread is unable to resume execution at schedule_timeout_killable(1) if
> a lot of !SCHED_IDLE priority threads are wasting CPU time [1].

I do not understand this. All the contending tasks will go and sleep for
1s. How can they preempt the lock holder?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.

[Enric Balletbo Serra]

Hi,

2017-07-17 10:54 GMT+02:00 Chanwoo Choi :
> Hi Enric,
>
> When I tried to apply this patch, error happened as following:
> (based on v4.13-rc1)
>
> Applying: extcon: cros-ec: Add extcon-cros-ec driver to support display out.
> error: patch failed: include/linux/mfd/cros_ec_commands.h:285
> error: include/linux/mfd/cros_ec_commands.h: patch does not apply
>

Very sorry about that, I had another patch that touched this file and
I forget to invert the sequence, first apply these patches then the
others. Let me fix that and resend again in few minutes, Very sorry
for the noise.

> Is it based on v4.13-rc1?
>
>
> On 2017년 07월 17일 16:37, Enric Balletbo i Serra wrote:
>> From: Benson Leung 
>>
>> This is the driver for the USB Type C cable detection mechanism
>> built into the ChromeOS Embedded Controller on systems that
>> have USB Type-C ports.
>>
>> At present, this allows for the presence of display out, but in
>> future, it may also be used to notify host and device type cables
>> and the presence of power.
>>
>> Signed-off-by: Benson Leung 
>> Signed-off-by: Enric Balletbo i Serra 
>> Acked-by: Chanwoo Choi 
>> Acked-by: Lee Jones 
>> ---
>> Changes since v2:
>>  - Rebase on top of v4.13-rc1
>> Changes since v1:
>>  Requested by Chanwoo Choi
>>  - Rename files changing _ for -
>>  - Remove the unneeded blank line on bottom of header.
>>  - Remove kobject.h and cros_ec_commands.h includes.
>>  - Remove the debug message as is not necessary.
>>  - Use the tab for indentation instead of space for if sentence.
>>  - Define each variable on different lines when the variables should be
>>initialized.
>>  - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now.
>>  - Add one blank line to split out between state and property setting.
>>  - Add the author information (header and module)
>>
>>  Enric Balletbo
>>  - As Rob suggested to rename the compatible name to something indicating 
>> that
>>is USB Type C related I also renamed the file names, extcon-cros-ec ->
>>extcon-usbc-cros-ec, I think it's more clear.
>>
>>  drivers/extcon/Kconfig   |   7 +
>>  drivers/extcon/Makefile  |   1 +
>>  drivers/extcon/extcon-usbc-cros-ec.c | 415 
>> +++
>>  include/linux/mfd/cros_ec_commands.h |  75 +++
>>  4 files changed, 498 insertions(+)
>>  create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c
>>
>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
>> index 6d50071..a7bca42 100644
>> --- a/drivers/extcon/Kconfig
>> +++ b/drivers/extcon/Kconfig
>> @@ -150,4 +150,11 @@ config EXTCON_USB_GPIO
>> Say Y here to enable GPIO based USB cable detection extcon support.
>> Used typically if GPIO is used for USB ID pin detection.
>>
>> +config EXTCON_USBC_CROS_EC
>> + tristate "ChromeOS Embedded Controller EXTCON support"
>> + depends on MFD_CROS_EC
>> + help
>> +   Say Y here to enable USB Type C cable detection extcon support when
>> +   using Chrome OS EC based USB Type-C ports.
>> +
>>  endif
>> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
>> index ecfa958..a73624e 100644
>> --- a/drivers/extcon/Makefile
>> +++ b/drivers/extcon/Makefile
>> @@ -20,3 +20,4 @@ obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += 
>> extcon-qcom-spmi-misc.o
>>  obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
>>  obj-$(CONFIG_EXTCON_SM5502)  += extcon-sm5502.o
>>  obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o
>> +obj-$(CONFIG_EXTCON_USBC_CROS_EC) += extcon-usbc-cros-ec.o
>> diff --git a/drivers/extcon/extcon-usbc-cros-ec.c 
>> b/drivers/extcon/extcon-usbc-cros-ec.c
>> new file mode 100644
>> index 000..e759ed4
>> --- /dev/null
>> +++ b/drivers/extcon/extcon-usbc-cros-ec.c
>> @@ -0,0 +1,415 @@
>> +/**
>> + * drivers/extcon/extcon-usbc-cros-ec - ChromeOS Embedded Controller extcon
>> + *
>> + * Copyright (C) 2017 Google, Inc
>> + * Author: Benson Leung 
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct cros_ec_extcon_info {
>> + struct device *dev;
>> + struct extcon_dev *edev;
>> +
>> + int port_id;
>> +
>> + struct cros_ec_device *ec;
>> +
>> + struct notifier_block notifier;
>> +
>> + bool dp; /* DisplayPort enabled */
>> 

Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock

[Maxime Ripard]

Hi Mark,

On Thu, Jul 13, 2017 at 05:01:42PM +0100, Mark Brown wrote:
> On Thu, Jul 13, 2017 at 04:12:56PM +0200, Maxime Ripard wrote:
> 
> > This might be problematic if the clock to enable is stored in another node.
> > Let's add a function that allows to attach a clock that has already been
> > retrieved to a regmap in order to fix this.
> 
> What is the use case for this?

This is useful when the clock you want to be handled by the regmap is
not described in the device node that probed the driver, but one of
its subnode, or an another node entirely.

We're in the latter case, where we have two controllers in the DT, but
are driven by the same driver. We'll create two regmaps, but one will
not have the proper of_node used to retrieve the clock.

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

[Maxime Ripard]

On Fri, Jul 14, 2017 at 02:42:55PM +0800, Chen-Yu Tsai wrote:
> The register for the "new timing mode" also has bit fields for setting
> output and sample timing phases. According to comments in Allwinner's
> BSP kernel, the default values are good enough.
> 
> Keep the default values already in the hardware when setting new timing
> mode, instead of overwriting the whole register.
> 
> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
> controllers")
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Thanks!
Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH 6/9] mm, page_alloc: simplify zonelist initialization

[Michal Hocko]

On Mon 17-07-17 09:58:04, Mel Gorman wrote:
> On Mon, Jul 17, 2017 at 10:19:42AM +0200, Michal Hocko wrote:
> > On Mon 17-07-17 09:07:23, Mel Gorman wrote:
> > > On Mon, Jul 17, 2017 at 08:06:40AM +0200, Michal Hocko wrote:
> > > > On Fri 14-07-17 15:18:23, Mel Gorman wrote:
> > > > > Fairly sure that's not what you meant.
> > > > > 
> > > > > 
> > > > > > pg_data_t *node = NODE_DATA(node_order[i]);
> > > > > >  
> > > > > > -   zoneref_idx = build_zonelists_node(node, zonelist, 
> > > > > > zoneref_idx);
> > > > > > +   nr_zones = build_zonelists_node(node, zonelist, 
> > > > > > nr_zones);
> > > > > 
> > > > > I meant converting build_zonelists_node and passing in _zones and
> > > > > returning false when an empty node is encountered. In this context,
> > > > > it's also not about zones, it really is nr_zonerefs. Rename nr_zones 
> > > > > in
> > > > > build_zonelists_node as well.
> > > > 
> > > > hmm, why don't we rather make it zonerefs based then. Something
> > > > like the following?
> > > 
> > > Works for me.
> > 
> > Should I fold it to the patch or make it a patch on its own?
> 
> I have no strong feelings either way but if it was folded then the
> overall naming should be easier to follow (at least for me).

OK, I will fold it in then. Unless there are more issues/feedback to
address I will repost the full series in few days.

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 03/11] clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock

[Maxime Ripard]

Hi,

On Fri, Jul 14, 2017 at 02:42:54PM +0800, Chen-Yu Tsai wrote:
> The MMC2 clock supports a new timing mode. When the new mode is active,
> the output clock rate is halved.
> 
> This patch sets the feature flag for the new timing mode, and adds
> a pre-divider based on the mode bit.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 38 
> +++
>  1 file changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c 
> b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
> index 947f9f6e05d2..ee6688e9b361 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
> @@ -418,14 +418,36 @@ static SUNXI_CCU_PHASE(mmc1_sample_clk, "mmc1-sample", 
> "mmc1",
>  static SUNXI_CCU_PHASE(mmc1_output_clk, "mmc1-output", "mmc1",
>  0x08c, 8, 3, 0);
>  
> -/* TODO Support MMC2 clock's new timing mode. */
> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mod0_default_parents,
> -   0x090,
> -   0, 4, /* M */
> -   16, 2,/* P */
> -   24, 2,/* mux */
> -   BIT(31),  /* gate */
> -   0);
> +/*
> + * MMC2 supports both old and new timing modes. When the new timing
> + * mode is active, the output clock rate is halved by two. Here we
> + * treat it as a variable pre-divider. Note that the pre-divider is
> + * _not_ included in the possible factors during a set clock rate
> + * operation. It is only read out.
> + */
> +static const struct ccu_mux_var_prediv mmc2_new_timing_predivs[] = {
> + { .index = 0, .shift = 30, .width = 1 },
> + { .index = 1, .shift = 30, .width = 1 },
> +};
> +static struct ccu_mp mmc2_clk = {
> + .enable = BIT(31),
> + .m  = _SUNXI_CCU_DIV(0, 4),
> + .p  = _SUNXI_CCU_DIV(16, 2),
> + .mux= {
> + .shift  = 24,
> + .width  = 2,
> + .var_predivs= mmc2_new_timing_predivs,
> + .n_var_predivs  = ARRAY_SIZE(mmc2_new_timing_predivs),
> + },
> + .common = {
> + .reg= 0x090,
> + .features   = CCU_FEATURE_MMC_TIMING_SWITCH,
> + .hw.init= CLK_HW_INIT_PARENTS("mmc2",
> +   mod0_default_parents,
> +   _mp_ops,
> +   CLK_GET_RATE_NOCACHE),
> + },
> +};

Treating the new bit seems a bit of a hack to me. It only works
because we're not evaluating the various pre-dividers during a
determine_rate (and set_rate), but it might change in the future, and
we will break all our eMMC controllers then.

Since they're quite special, I was thinking about creating a new MMC
clock type? We're going to use it on a number of SoCs, and we'll be
able to model it properly, without crippling the regular and generic
MP clocks.

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCHv2 0/6] Motorola Droid 4 Audio Support

[Tony Lindgren]

* Sebastian Reichel  [170712 08:19]:
>  * Switch from simple-audio-card to audio-graph-card

Gave this a quick try against v4.13-rc1 with SND_AUDIO_GRAPH_CARD
enabled as a loadable module. However loading it oopses for me,
see below. Maybe some dependencies are missing?

Regards,

Tony

8< 
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
in_atomic(): 1, irqs_disabled(): 128, pid: 1590, name: modprobe
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last  enabled at (0): [<  (null)>]   (null)
hardirqs last disabled at (0): [] copy_process.part.5+0x2c4/0x1ac8
softirqs last  enabled at (0): [] copy_process.part.5+0x2c4/0x1ac8
softirqs last disabled at (0): [<  (null)>]   (null)
CPU: 0 PID: 1590 Comm: modprobe Tainted: GW   4.13.0-rc1+ #126
Hardware name: Generic OMAP4 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xac/0xe0)
[] (dump_stack) from [] (___might_sleep+0x228/0x2ac)
[] (___might_sleep) from [] (__mutex_lock+0x28/0x9fc)
[] (__mutex_lock) from [] (mutex_lock_nested+0x1c/0x24)
[] (mutex_lock_nested) from [] (kernfs_remove+0x18/0x30)
[] (kernfs_remove) from [] (kobject_del+0x14/0x44)
[] (kobject_del) from [] (kobject_put+0x114/0x224)
[] (kobject_put) from [] (of_get_next_parent+0x2c/0x4c)
[] (of_get_next_parent) from [] 
(of_graph_get_port_parent+0x10/0x70)
[] (of_graph_get_port_parent) from [] 
(asoc_simple_card_parse_graph_dai+0x98/0xe0 [snd_soc_simple_card_utils])
[] (asoc_simple_card_parse_graph_dai [snd_soc_simple_card_utils]) 
from [] (asoc_graph_card_probe+0x200/0x444 [snd_soc_audio_graph_card])
[] (asoc_graph_card_probe [snd_soc_audio_graph_card]) from 
[] (platform_drv_probe+0x50/0xb0)
[] (platform_drv_probe) from [] 
(driver_probe_device+0x33c/0x478)
[] (driver_probe_device) from [] 
(__driver_attach+0xe8/0x110)
[] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0)
[] (bus_for_each_dev) from [] (bus_add_driver+0x198/0x270)
[] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[] (driver_register) from [] (do_one_initcall+0x3c/0x170)
[] (do_one_initcall) from [] (do_init_module+0x5c/0x1e0)
[] (do_init_module) from [] (load_module+0x1270/0x14ec)
[] (load_module) from [] (SyS_finit_module+0xa8/0xec)
[] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x1c)
OF: ERROR: Bad of_node_put() on 
/ocp/spi@48098000/pmic@0/audio-codec/port@0/endpoint

Re: [PATCH] PCI: dwc: designware: test PCIE_ATU_ENABLE bit to check enabled or not

[Joao Pinto]

Hi,

Às 11:35 AM de 7/13/2017, Jisheng Zhang escreveu:
> The ATU CTRL2 register is 32 bit, besides the enable bit, other bits
> may also be set. To check whether the ATU is enabled or not, we should
> test the enable it.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/pci/dwc/pcie-designware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 0e03af279259..6bf0b409050a 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -177,7 +177,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
> index, int type,
>*/
>   for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
>   val = dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
> - if (val == PCIE_ATU_ENABLE)
> + if (val & PCIE_ATU_ENABLE)
>   return;
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
> 
Make sense, turn it more accurate. Thanks!

Acked-by: Joao Pinto 

Re: [PATCH] printk: modify console_unlock with printk-safe macros

[Sergey Senozhatsky]

On (07/15/17 18:36), Pierre Kuo wrote:
[..]
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index fc47863..21557cc 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2194,8 +2194,7 @@ void console_unlock(void)
>   size_t ext_len = 0;
>   size_t len;
>  
> - printk_safe_enter_irqsave(flags);
> - raw_spin_lock(_lock);
> + logbuf_lock_irqsave(flags);
>   if (seen_seq != log_next_seq) {
>   wake_klogd = true;
>   seen_seq = log_next_seq;
> @@ -2267,8 +2266,7 @@ void console_unlock(void)
>*/
>   raw_spin_lock(_lock);
>   retry = console_seq != log_next_seq;
> - raw_spin_unlock(_lock);
> - printk_safe_exit_irqrestore(flags);
> + logbuf_unlock_irqrestore(flags);
>  
>   if (retry && console_trylock())
>   goto again;

I did it that particular way for a reason - console_unlock() does a
bunch of tricks: unlocking logbuf in the middle of printing loop,
breaking out of loop with local IRQs disabled, re-taking the logbuf
after the loop still will local IRQs disabled, etc. etc. I didn't
want to (and still don't) mix-in logbuf macros; we do things that
macros don't cover anyway. sorry, I don't agree that the patch
improves readability.

-ss

Re: [PATCH 3/5] sphinx-pre-install: use a requirements file

[Mauro Carvalho Chehab]

Em Mon, 17 Jul 2017 08:00:07 +0200
Markus Heiser  escreveu:

> > Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab 
> > :
> > 
> > Instead of using 3 commands to install a virtualenv, use
> > a single one, reading the requirements from this file:
> > 
> > Documentation/sphinx/requirements.txt
> > 
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> Hi Mauro,
> 
> I get a ..
> 
>  fatal: sha1 information is lacking or useless 
> (Documentation/doc-guide/sphinx.rst)
> 
> and  I miss the Documentation/doc-guide/sphinx.rst file in this patch.
> 
> Did it only happened to me?

Sorry, I forgot to mention. This patch depends on the patch series I
posted before adding information about the Sphinx install procedures:

[PATCH v2 0/6] Better document Sphinx install instructions

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1444295.html


Thanks,
Mauro

[PATCH] x86/microcode: Document the three loading methods

[Borislav Petkov]

From: Borislav Petkov 

Paul Menzel  asked recently how to load microcode
on a system and I realized that we don't really have all the methods
written down somewhere. Do that, so people can go and look them up.

Signed-off-by: Borislav Petkov 
---
 Documentation/x86/early-microcode.txt |  70 --
 Documentation/x86/microcode.txt   | 133 ++
 2 files changed, 133 insertions(+), 70 deletions(-)
 delete mode 100644 Documentation/x86/early-microcode.txt
 create mode 100644 Documentation/x86/microcode.txt

diff --git a/Documentation/x86/early-microcode.txt 
b/Documentation/x86/early-microcode.txt
deleted file mode 100644
index 07749e7f3d50..
--- a/Documentation/x86/early-microcode.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Early load microcode
-
-By Fenghua Yu 
-
-Kernel can update microcode in early phase of boot time. Loading microcode 
early
-can fix CPU issues before they are observed during kernel boot time.
-
-Microcode is stored in an initrd file. The microcode is read from the initrd
-file and loaded to CPUs during boot time.
-
-The format of the combined initrd image is microcode in cpio format followed by
-the initrd image (maybe compressed). Kernel parses the combined initrd image
-during boot time. The microcode file in cpio name space is:
-on Intel: kernel/x86/microcode/GenuineIntel.bin
-on AMD  : kernel/x86/microcode/AuthenticAMD.bin
-
-During BSP boot (before SMP starts), if the kernel finds the microcode file in
-the initrd file, it parses the microcode and saves matching microcode in 
memory.
-If matching microcode is found, it will be uploaded in BSP and later on in all
-APs.
-
-The cached microcode patch is applied when CPUs resume from a sleep state.
-
-There are two legacy user space interfaces to load microcode, either through
-/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file
-in sysfs.
-
-In addition to these two legacy methods, the early loading method described
-here is the third method with which microcode can be uploaded to a system's
-CPUs.
-
-The following example script shows how to generate a new combined initrd file 
in
-/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and
-original initrd image /boot/initrd-3.5.0.img.
-
-mkdir initrd
-cd initrd
-mkdir -p kernel/x86/microcode
-cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin)
-find . | cpio -o -H newc >../ucode.cpio
-cd ..
-cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img
-
-Builtin microcode
-=
-
-We can also load builtin microcode supplied through the regular firmware
-builtin method CONFIG_FIRMWARE_IN_KERNEL. Only 64-bit is currently
-supported.
-
-Here's an example:
-
-CONFIG_FIRMWARE_IN_KERNEL=y
-CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin"
-CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
-
-This basically means, you have the following tree structure locally:
-
-/lib/firmware/
-|-- amd-ucode
-...
-|   |-- microcode_amd_fam15h.bin
-...
-|-- intel-ucode
-...
-|   |-- 06-3a-09
-...
-
-so that the build system can find those files and integrate them into
-the final kernel image. The early loader finds them and applies them.
diff --git a/Documentation/x86/microcode.txt b/Documentation/x86/microcode.txt
new file mode 100644
index ..6ab130c6ca45
--- /dev/null
+++ b/Documentation/x86/microcode.txt
@@ -0,0 +1,133 @@
+   The Linux Microcode Loader
+
+Authors: Fenghua Yu 
+Borislav Petkov 
+
+The kernel has a x86 microcode loading facility which is supposed to
+provide microcode loading methods in the OS. Potential use cases are
+updating the microcode on platforms beyond the OEM EOL support, and
+updating the microcode on long-running systems without rebooting.
+
+The loader supports three loading methods:
+
+1. Early load microcode
+===
+
+The kernel can update microcode very early during boot. Loading
+microcode early can fix CPU issues before they are observed during
+kernel boot time.
+
+The microcode is stored in an initrd file. During boot, it is read from
+it and loaded into the CPU cores.
+
+The format of the combined initrd image is microcode in cpio format
+followed by the initrd image (possibly compressed). The loader parses
+the combined initrd image during boot.
+
+The microcode files in cpio name space are:
+
+on Intel: kernel/x86/microcode/GenuineIntel.bin
+on AMD  : kernel/x86/microcode/AuthenticAMD.bin
+
+During BSP (BootStrapping Processor) boot (pre-SMP), the kernel
+scans the microcode file in the initrd. If microcode matching the
+CPU is found, it will be applied in the BSP and later on in all APs
+(Application Processors).
+
+The loader also saves the matching microcode for the CPU in memory.
+Thus, the cached microcode patch is applied when CPUs resume 

Re: Droid 4 boot failure due to 422580c3cea7 (mm/oom_kill.c: add tracepoints for oom reaper-related events)

[Sebastian Reichel]

Hi,

On Sun, Jul 16, 2017 at 10:59:42PM -0700, Tony Lindgren wrote:
> * Roman Gushchin  [170716 05:55]:
> > On Fri, Jul 14, 2017 at 07:23:43PM +0200, Sebastian Reichel wrote:
> > > On Fri, Jul 14, 2017 at 02:12:21PM +, Roman Gushchin wrote:
> > > > > On 14 Jul 2017, at 14:43, Sebastian Reichel 
> > > > >  wrote:
> > > > > I just bisected another issue breaking boot on Droid 4. My
> > > > > bisect points to 422580c3cea7 (mm/oom_kill.c: add tracepoints
> > > > > for oom reaper-related events). It do not see any message
> > > > > printed to UART (with earlyprintk) once that commit is part
> > > > > of my image. Kernel config is below.
> > > 
> > > > This is really interesting, because this patch adds few
> > > > tracepoints and all of them are called from the oom code, which is
> > > > hopefully not a part of the boot process.
> > > > 
> > > > Can you, please, confirm, that it can be reproduced with some
> > > > confidence? If so, can you, please, eliminate the tracepoints
> > > > calls and try to reproduce the boot failure?
> > > 
> > > I can boot 9967468c0a10 ("Merge branch 'akpm' (patches from
> > > Andrew)") after adding
> > > 
> > >  - http://git.kernel.org/tip/19d39a3810e7032f311ef83effdac40339b9d022
> > >(another issue, that breaks Droid 4 boot)
> > >  - a git revert of 422580c3cea7
> > > 
> > > OTOH there are strange problems. Using da16dd9785f8 + above
> > > two commits also works. Using b5e16170f59b + above commits
> > > does not work and bisection ended up in the merge commit.
> > 
> > Hi, Sebastian!
> > 
> > As commit 422580c3cea7 hasn't added any code, which is executed
> > during the boot process, I could imagine only two options:
> > 1) Added code/data occasionally broke some alignment/size contraints.
> > 2) There is another instable bug, which compromised bisect results.
> > 
> > Unfortunately, I can't help you with reproducing, because I haven't
> > necessary hardware.
> > 
> > Can you, please, try some older known to be good revision with
> > the 422580c3cea7 patch applied?
> 
> Sebastian, for me droid 4 boots just fine with v4.13-rc1 +
> 19d39a3810e if that helps. So that's with commit 422580c3cea7.

v4.13-rc1 + 19d39a3810e was also broken for me. I just disabled
some unused bits in my .config and now the kernel boots with
(with 422580c3cea7 that is). Maybe I hit some maximum image size
limit for Droid 4?

Anyways it looks like 422580c3cea7 is not the actual problem
and merely reveals some other problem.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v1 1/2] ACPI / boot: Correct address space of __acpi_map_table()

[Hanjun Guo]

On 2017/7/8 23:50, Andy Shevchenko wrote:
> Sparse complains about wrong address space used in __acpi_map_table()
> and in __acpi_unmap_table().
>
> arch/x86/kernel/acpi/boot.c:127:29: warning: incorrect type in return 
> expression (different address spaces)
> arch/x86/kernel/acpi/boot.c:127:29:expected char *
> arch/x86/kernel/acpi/boot.c:127:29:got void [noderef] *
> arch/x86/kernel/acpi/boot.c:135:23: warning: incorrect type in argument 1 
> (different address spaces)
> arch/x86/kernel/acpi/boot.c:135:23:expected void [noderef] *addr
> arch/x86/kernel/acpi/boot.c:135:23:got char *map
>
> Correct address space to be in align of type of returned and passed
> parameter.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/kernel/acpi/boot.c | 4 ++--
>  include/linux/acpi.h| 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 6d534af94761..ac9bb564f004 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -118,7 +118,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = 
> {
>   * This is just a simple wrapper around early_ioremap(),
>   * with sanity checks for phys == 0 and size == 0.
>   */
> -char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size)
>  {
>  
>   if (!phys || !size)
> @@ -127,7 +127,7 @@ char *__init __acpi_map_table(unsigned long phys, 
> unsigned long size)
>   return early_ioremap(phys, size);
>  }
>  
> -void __init __acpi_unmap_table(char *map, unsigned long size)
> +void __init __acpi_unmap_table(void __iomem *map, unsigned long size)
>  {
>   if (!map || !size)
>   return;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 99f96df83dd8..17cb57a533bb 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -224,8 +224,8 @@ struct acpi_subtable_proc {
>   int count;
>  };
>  
> -char * __acpi_map_table (unsigned long phys_addr, unsigned long size);
> -void __acpi_unmap_table(char *map, unsigned long size);
> +void __iomem *__acpi_map_table(unsigned long phys_addr, unsigned long size);
> +void __acpi_unmap_table(void __iomem *map, unsigned long size);

This breaks ACPI compile on ARM64 as ARM64 has its definition for those
two functions, I see patches in linux-next already, should I add a patch on top
to fix it, or this patch should be respined?

Thanks
Hanjun

[PATCH v2 2/5] ACPI / boot: Correct address space of __acpi_map_table()

[Andy Shevchenko]

Sparse complains about wrong address space used in __acpi_map_table()
and in __acpi_unmap_table().

arch/x86/kernel/acpi/boot.c:127:29: warning: incorrect type in return 
expression (different address spaces)
arch/x86/kernel/acpi/boot.c:127:29:expected char *
arch/x86/kernel/acpi/boot.c:127:29:got void [noderef] *
arch/x86/kernel/acpi/boot.c:135:23: warning: incorrect type in argument 1 
(different address spaces)
arch/x86/kernel/acpi/boot.c:135:23:expected void [noderef] *addr
arch/x86/kernel/acpi/boot.c:135:23:got char *map

Correct address space to be in align of type of returned and passed
parameter.

Signed-off-by: Andy Shevchenko 
---
 arch/arm64/kernel/acpi.c| 4 ++--
 arch/ia64/kernel/acpi.c | 4 ++--
 arch/x86/kernel/acpi/boot.c | 4 ++--
 include/linux/acpi.h| 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index e25c11e727fe..b3162715ed78 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -95,7 +95,7 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
  */
-char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size)
 {
if (!size)
return NULL;
@@ -103,7 +103,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned 
long size)
return early_memremap(phys, size);
 }
 
-void __init __acpi_unmap_table(char *map, unsigned long size)
+void __init __acpi_unmap_table(void __iomem *map, unsigned long size)
 {
if (!map || !size)
return;
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 7508c306aa9e..b9388cc283bc 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -159,12 +159,12 @@ int acpi_request_vector(u32 int_type)
return vector;
 }
 
-char *__init __acpi_map_table(unsigned long phys_addr, unsigned long size)
+void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size)
 {
return __va(phys_addr);
 }
 
-void __init __acpi_unmap_table(char *map, unsigned long size)
+void __init __acpi_unmap_table(void __iomem *map, unsigned long size)
 {
 }
 
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 09ddb3cd627a..6d5b1346268a 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -118,7 +118,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
  * This is just a simple wrapper around early_ioremap(),
  * with sanity checks for phys == 0 and size == 0.
  */
-char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size)
 {
 
if (!phys || !size)
@@ -127,7 +127,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned 
long size)
return early_ioremap(phys, size);
 }
 
-void __init __acpi_unmap_table(char *map, unsigned long size)
+void __init __acpi_unmap_table(void __iomem *map, unsigned long size)
 {
if (!map || !size)
return;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index c749eef1daa1..3848b56fcd83 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -228,8 +228,8 @@ struct acpi_subtable_proc {
int count;
 };
 
-char * __acpi_map_table (unsigned long phys_addr, unsigned long size);
-void __acpi_unmap_table(char *map, unsigned long size);
+void __iomem *__acpi_map_table(unsigned long phys_addr, unsigned long size);
+void __acpi_unmap_table(void __iomem *map, unsigned long size);
 int early_acpi_boot_init(void);
 int acpi_boot_init (void);
 void acpi_boot_table_init (void);
-- 
2.11.0

[PATCH v2 5/5] ACPI / boot: Don't handle SCI on HW reduced platforms

[Andy Shevchenko]

WIP

Signed-off-by: Andy Shevchenko 
---
 arch/x86/kernel/acpi/boot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 71c0feae60a4..4413cc2f7c3c 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1184,7 +1184,7 @@ static int __init acpi_parse_madt_ioapic_entries(void)
 * If BIOS did not supply an INT_SRC_OVR for the SCI
 * pretend we got one so we can set the SCI flags.
 */
-   if (!acpi_sci_override_gsi)
+   if (!acpi_sci_override_gsi && !acpi_gbl_reduced_hardware)
acpi_sci_ioapic_setup(acpi_gbl_FADT.sci_interrupt, 0, 0,
  acpi_gbl_FADT.sci_interrupt);
 
-- 
2.11.0

[PATCH v2 1/5] ACPI / boot: Don't define unused variables

[Andy Shevchenko]

Some code in acpi_parse_x2apic() conditionally compiled, though parts of
it are being used in any case. This annoys gcc.

arch/x86/kernel/acpi/boot.c: In function ‘acpi_parse_x2apic’:
arch/x86/kernel/acpi/boot.c:203:5: warning: variable ‘enabled’ set but not used 
[-Wunused-but-set-variable]
  u8 enabled;
 ^~~
arch/x86/kernel/acpi/boot.c:202:6: warning: variable ‘apic_id’ set but not used 
[-Wunused-but-set-variable]
  int apic_id;
  ^~~

Re-arrange the code to avoid compiling unused variables.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/kernel/acpi/boot.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 6bb680671088..09ddb3cd627a 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -199,8 +199,10 @@ static int __init
 acpi_parse_x2apic(struct acpi_subtable_header *header, const unsigned long end)
 {
struct acpi_madt_local_x2apic *processor = NULL;
+#ifdef CONFIG_X86_X2APIC
int apic_id;
u8 enabled;
+#endif
 
processor = (struct acpi_madt_local_x2apic *)header;
 
@@ -209,9 +211,10 @@ acpi_parse_x2apic(struct acpi_subtable_header *header, 
const unsigned long end)
 
acpi_table_print_madt_entry(header);
 
+#ifdef CONFIG_X86_X2APIC
apic_id = processor->local_apic_id;
enabled = processor->lapic_flags & ACPI_MADT_ENABLED;
-#ifdef CONFIG_X86_X2APIC
+
/*
 * We need to register disabled CPU as well to permit
 * counting disabled CPUs. This allows us to size
-- 
2.11.0

[PATCH v2 0/5] ACPI / boot: Few amendments

[Andy Shevchenko]

This series does few amendments to architectural ACPI code related to
boot, in particularly to arch/x86/kernel/acpi/boot.c.

First two patches are amendments to satisfy compiler and static analyzer
(the order is changed from first version which had been applied; in case
of partial update first patch is already in tree).

Third patch might be useful on platforms when debugging *PIC related
code path to see how many legacy IRQs are registered.

Fourth and fifth patches are preparation for some interesting
implementation of ACPI HW reduced platforms (note, this does not mean
it's against specification, patch 5 actually about following
specification).

Fifth patch might be subject to additional discussions.

In v2:
- fix function declarations in ia64 and arm64 as well (Hanjun)
- add three more patches

Andy Shevchenko (5):
  ACPI / boot: Don't define unused variables
  ACPI / boot: Correct address space of __acpi_map_table()
  ACPI / boot: Add number of legacy IRQs to debug output
  ACPI / boot: Not all platform require acpi_reduced_hw_init()
  ACPI / boot: Don't handle SCI on HW reduced platforms

 arch/arm64/kernel/acpi.c|  4 ++--
 arch/ia64/kernel/acpi.c |  4 ++--
 arch/x86/kernel/acpi/boot.c | 15 +--
 include/linux/acpi.h|  7 +--
 4 files changed, 18 insertions(+), 12 deletions(-)

-- 
2.11.0

[PATCH v2 4/5] ACPI / boot: Not all platform require acpi_reduced_hw_init()

[Andy Shevchenko]

Some platform might take care of legacy devices on theirs own.
Let's allow them to do that by exporting a weak function.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/kernel/acpi/boot.c | 2 +-
 include/linux/acpi.h| 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0186d3bae610..71c0feae60a4 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1348,7 +1348,7 @@ static int __init dmi_ignore_irq0_timer_override(const 
struct dmi_system_id *d)
  *
  * We initialize the Hardware-reduced ACPI model here:
  */
-static void __init acpi_reduced_hw_init(void)
+void __init __weak acpi_reduced_hw_init(void)
 {
if (acpi_gbl_reduced_hardware) {
/*
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 3848b56fcd83..3ef30a7b5444 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -230,6 +230,8 @@ struct acpi_subtable_proc {
 
 void __iomem *__acpi_map_table(unsigned long phys_addr, unsigned long size);
 void __acpi_unmap_table(void __iomem *map, unsigned long size);
+
+void acpi_reduced_hw_init(void);
 int early_acpi_boot_init(void);
 int acpi_boot_init (void);
 void acpi_boot_table_init (void);
@@ -682,6 +684,7 @@ static inline struct device 
*acpi_get_first_physical_node(struct acpi_device *ad
 static inline void acpi_early_init(void) { }
 static inline void acpi_subsystem_init(void) { }
 
+static inline void acpi_reduced_hw_init(void) { }
 static inline int early_acpi_boot_init(void)
 {
return 0;
-- 
2.11.0

[PATCH v2 3/5] ACPI / boot: Add number of legacy IRQs to debug output

[Andy Shevchenko]

Sometimes it's useful to have when mp_config_acpi_legacy_irqs() is called.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/kernel/acpi/boot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 6d5b1346268a..0186d3bae610 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1078,7 +1078,7 @@ static void __init mp_config_acpi_legacy_irqs(void)
mp_bus_id_to_type[MP_ISA_BUS] = MP_BUS_ISA;
 #endif
set_bit(MP_ISA_BUS, mp_bus_not_pci);
-   pr_debug("Bus #%d is ISA\n", MP_ISA_BUS);
+   pr_debug("Bus #%d is ISA (nIRQs: %d)\n", MP_ISA_BUS, nr_legacy_irqs());
 
/*
 * Use the default configuration for the IRQs 0-15.  Unless
-- 
2.11.0

[PATCH] perf probe: Fix build failure for get_target_map()

[Ravi Bangoria]

Commit 801bc8193463 ("perf probe: Allow placing uprobes in
alternate namespaces.") is causing a build failure on powerpc:

  error: incompatible type for argument 2 of 'get_target_map'
  map = get_target_map(pev->target, pev->uprobes);
^~~

Fix it by changing parameters of get_target_map().

Fixes: 801bc8193463 ("perf probe: Allow placing uprobes in alternate 
namespaces.")
Signed-off-by: Ravi Bangoria 
---
 tools/perf/arch/powerpc/util/sym-handling.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index bf9a259..9c4e23d 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -126,7 +126,7 @@ void arch__post_process_probe_trace_events(struct 
perf_probe_event *pev,
struct rb_node *tmp;
int i = 0;
 
-   map = get_target_map(pev->target, pev->uprobes);
+   map = get_target_map(pev->target, pev->nsi, pev->uprobes);
if (!map || map__load(map) < 0)
return;
 
-- 
2.1.4

[PATCH v3 08/23] media: camss: Add CSID files

[Todor Tomov]

These files control the CSID modules which handle the protocol and application
layer of the CSI2 receivers.

Signed-off-by: Todor Tomov 
---
 .../media/platform/qcom/camss-8x16/camss-csid.c| 1073 
 .../media/platform/qcom/camss-8x16/camss-csid.h|   82 ++
 2 files changed, 1155 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-csid.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-csid.h

diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csid.c 
b/drivers/media/platform/qcom/camss-8x16/camss-csid.c
new file mode 100644
index 000..2bf3415
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/camss-csid.c
@@ -0,0 +1,1073 @@
+/*
+ * camss-csid.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSID Module
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "camss-csid.h"
+#include "camss.h"
+
+#define MSM_CSID_NAME "msm_csid"
+
+#define CAMSS_CSID_HW_VERSION  0x0
+#define CAMSS_CSID_CORE_CTRL_0 0x004
+#define CAMSS_CSID_CORE_CTRL_1 0x008
+#define CAMSS_CSID_RST_CMD 0x00c
+#define CAMSS_CSID_CID_LUT_VC_n(n) (0x010 + 0x4 * (n))
+#define CAMSS_CSID_CID_n_CFG(n)(0x020 + 0x4 * (n))
+#define CAMSS_CSID_IRQ_CLEAR_CMD   0x060
+#define CAMSS_CSID_IRQ_MASK0x064
+#define CAMSS_CSID_IRQ_STATUS  0x068
+#define CAMSS_CSID_TG_CTRL 0x0a0
+#define CAMSS_CSID_TG_VC_CFG   0x0a4
+#define CAMSS_CSID_TG_VC_CFG_H_BLANKING0x3ff
+#define CAMSS_CSID_TG_VC_CFG_V_BLANKING0x7f
+#define CAMSS_CSID_TG_DT_n_CGG_0(n)(0x0ac + 0xc * (n))
+#define CAMSS_CSID_TG_DT_n_CGG_1(n)(0x0b0 + 0xc * (n))
+#define CAMSS_CSID_TG_DT_n_CGG_2(n)(0x0b4 + 0xc * (n))
+
+#define DATA_TYPE_EMBEDDED_DATA_8BIT   0x12
+#define DATA_TYPE_YUV422_8BIT  0x1e
+#define DATA_TYPE_RAW_6BIT 0x28
+#define DATA_TYPE_RAW_8BIT 0x2a
+#define DATA_TYPE_RAW_10BIT0x2b
+#define DATA_TYPE_RAW_12BIT0x2c
+
+#define DECODE_FORMAT_UNCOMPRESSED_6_BIT   0x0
+#define DECODE_FORMAT_UNCOMPRESSED_8_BIT   0x1
+#define DECODE_FORMAT_UNCOMPRESSED_10_BIT  0x2
+#define DECODE_FORMAT_UNCOMPRESSED_12_BIT  0x3
+
+#define CSID_RESET_TIMEOUT_MS 500
+
+static const struct {
+   u32 code;
+   u32 uncompressed;
+   u8 data_type;
+   u8 decode_format;
+   u8 uncompr_bpp;
+} csid_input_fmts[] = {
+   {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   16
+   },
+   {
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   16
+   },
+   {
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   16
+   },
+   {
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   16
+   },
+   {
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8
+   },
+   {
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8
+   },
+   {
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8
+   },
+   {
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8
+   },
+   {
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   DATA_TYPE_RAW_10BIT,
+   DECODE_FORMAT_UNCOMPRESSED_10_BIT,
+

[PATCH v3 09/23] media: camss: Add ISPIF files

[Todor Tomov]

These files control the ISPIF module which handles the routing of the data
streams from the CSIDs to the inputs of the VFE.

Signed-off-by: Todor Tomov 
---
 .../media/platform/qcom/camss-8x16/camss-ispif.c   | 1127 
 .../media/platform/qcom/camss-8x16/camss-ispif.h   |   85 ++
 2 files changed, 1212 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-ispif.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-ispif.h

diff --git a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c 
b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
new file mode 100644
index 000..cc32085
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
@@ -0,0 +1,1127 @@
+/*
+ * camss-ispif.c
+ *
+ * Qualcomm MSM Camera Subsystem - ISPIF Module
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "camss-ispif.h"
+#include "camss.h"
+
+#define MSM_ISPIF_NAME "msm_ispif"
+
+#define ispif_line_array(ptr_line) \
+   ((const struct ispif_line (*)[]) &(ptr_line[-(ptr_line->id)]))
+
+#define to_ispif(ptr_line) \
+   container_of(ispif_line_array(ptr_line), struct ispif_device, ptr_line)
+
+#define ISPIF_RST_CMD_00x008
+#define ISPIF_IRQ_GLOBAL_CLEAR_CMD 0x01c
+#define ISPIF_VFE_m_CTRL_0(m)  (0x200 + 0x200 * (m))
+#define ISPIF_VFE_m_CTRL_0_PIX0_LINE_BUF_EN(1 << 6)
+#define ISPIF_VFE_m_IRQ_MASK_0(m)  (0x208 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_MASK_0_PIX0_ENABLE 0x1249
+#define ISPIF_VFE_m_IRQ_MASK_0_PIX0_MASK   0x1fff
+#define ISPIF_VFE_m_IRQ_MASK_0_RDI0_ENABLE 0x02492000
+#define ISPIF_VFE_m_IRQ_MASK_0_RDI0_MASK   0x03ffe000
+#define ISPIF_VFE_m_IRQ_MASK_1(m)  (0x20c + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_MASK_1_PIX1_ENABLE 0x1249
+#define ISPIF_VFE_m_IRQ_MASK_1_PIX1_MASK   0x1fff
+#define ISPIF_VFE_m_IRQ_MASK_1_RDI1_ENABLE 0x02492000
+#define ISPIF_VFE_m_IRQ_MASK_1_RDI1_MASK   0x03ffe000
+#define ISPIF_VFE_m_IRQ_MASK_2(m)  (0x210 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_MASK_2_RDI2_ENABLE 0x1249
+#define ISPIF_VFE_m_IRQ_MASK_2_RDI2_MASK   0x1fff
+#define ISPIF_VFE_m_IRQ_STATUS_0(m)(0x21c + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW (1 << 12)
+#define ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW (1 << 25)
+#define ISPIF_VFE_m_IRQ_STATUS_1(m)(0x220 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW (1 << 12)
+#define ISPIF_VFE_m_IRQ_STATUS_1_RDI1_OVERFLOW (1 << 25)
+#define ISPIF_VFE_m_IRQ_STATUS_2(m)(0x224 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_STATUS_2_RDI2_OVERFLOW (1 << 12)
+#define ISPIF_VFE_m_IRQ_CLEAR_0(m) (0x230 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_CLEAR_1(m) (0x234 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_CLEAR_2(m) (0x238 + 0x200 * (m))
+#define ISPIF_VFE_m_INTF_INPUT_SEL(m)  (0x244 + 0x200 * (m))
+#define ISPIF_VFE_m_INTF_CMD_0(m)  (0x248 + 0x200 * (m))
+#define ISPIF_VFE_m_INTF_CMD_1(m)  (0x24c + 0x200 * (m))
+#define ISPIF_VFE_m_PIX_INTF_n_CID_MASK(m, n)  \
+   (0x254 + 0x200 * (m) + 0x4 * (n))
+#define ISPIF_VFE_m_RDI_INTF_n_CID_MASK(m, n)  \
+   (0x264 + 0x200 * (m) + 0x4 * (n))
+#define ISPIF_VFE_m_PIX_INTF_n_STATUS(m, n)\
+   (0x2c0 + 0x200 * (m) + 0x4 * (n))
+#define ISPIF_VFE_m_RDI_INTF_n_STATUS(m, n)\
+   (0x2d0 + 0x200 * (m) + 0x4 * (n))
+
+#define CSI_PIX_CLK_MUX_SEL0x000
+#define CSI_RDI_CLK_MUX_SEL0x008
+
+#define ISPIF_TIMEOUT_SLEEP_US 1000
+#define ISPIF_TIMEOUT_ALL_US   100
+#define ISPIF_RESET_TIMEOUT_MS 500
+
+enum ispif_intf_cmd {
+   CMD_DISABLE_FRAME_BOUNDARY = 0x0,
+   CMD_ENABLE_FRAME_BOUNDARY = 0x1,
+   CMD_DISABLE_IMMEDIATELY = 0x2,
+   CMD_ALL_DISABLE_IMMEDIATELY = 0x,
+   CMD_ALL_NO_CHANGE = 0x,
+};
+
+static const u32 ispif_formats[] = {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   

[PATCH v3 11/23] media: camss: Add files which handle the video device nodes

[Todor Tomov]

These files handle the video device nodes of the camss driver.

Signed-off-by: Todor Tomov 
---
 .../media/platform/qcom/camss-8x16/camss-video.c   | 627 +
 .../media/platform/qcom/camss-8x16/camss-video.h   |  66 +++
 2 files changed, 693 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-video.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-video.h

diff --git a/drivers/media/platform/qcom/camss-8x16/camss-video.c 
b/drivers/media/platform/qcom/camss-8x16/camss-video.c
new file mode 100644
index 000..29483a4
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/camss-video.c
@@ -0,0 +1,627 @@
+/*
+ * camss-video.c
+ *
+ * Qualcomm MSM Camera Subsystem - V4L2 device node
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "camss-video.h"
+#include "camss.h"
+
+/*
+ * struct format_info - ISP media bus format information
+ * @code: V4L2 media bus format code
+ * @pixelformat: V4L2 pixel format FCC identifier
+ * @bpp: Bits per pixel when stored in memory
+ */
+static const struct format_info {
+   u32 code;
+   u32 pixelformat;
+   unsigned int bpp;
+} formats[] = {
+   { MEDIA_BUS_FMT_UYVY8_2X8, V4L2_PIX_FMT_UYVY, 16 },
+   { MEDIA_BUS_FMT_VYUY8_2X8, V4L2_PIX_FMT_VYUY, 16 },
+   { MEDIA_BUS_FMT_YUYV8_2X8, V4L2_PIX_FMT_YUYV, 16 },
+   { MEDIA_BUS_FMT_YVYU8_2X8, V4L2_PIX_FMT_YVYU, 16 },
+   { MEDIA_BUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8 },
+   { MEDIA_BUS_FMT_SGBRG8_1X8, V4L2_PIX_FMT_SGBRG8, 8 },
+   { MEDIA_BUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8 },
+   { MEDIA_BUS_FMT_SRGGB8_1X8, V4L2_PIX_FMT_SRGGB8, 8 },
+   { MEDIA_BUS_FMT_SBGGR10_1X10, V4L2_PIX_FMT_SBGGR10P, 10 },
+   { MEDIA_BUS_FMT_SGBRG10_1X10, V4L2_PIX_FMT_SGBRG10P, 10 },
+   { MEDIA_BUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10P, 10 },
+   { MEDIA_BUS_FMT_SRGGB10_1X10, V4L2_PIX_FMT_SRGGB10P, 10 },
+   { MEDIA_BUS_FMT_SBGGR12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 },
+   { MEDIA_BUS_FMT_SGBRG12_1X12, V4L2_PIX_FMT_SGBRG12P, 12 },
+   { MEDIA_BUS_FMT_SGRBG12_1X12, V4L2_PIX_FMT_SGRBG12P, 12 },
+   { MEDIA_BUS_FMT_SRGGB12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 }
+};
+
+/* 
-
+ * Helper functions
+ */
+
+/*
+ * video_mbus_to_pix_mp - Convert v4l2_mbus_framefmt to v4l2_pix_format_mplane
+ * @mbus: v4l2_mbus_framefmt format (input)
+ * @pix: v4l2_pix_format_mplane format (output)
+ *
+ * Fill the output pix structure with information from the input mbus format.
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static unsigned int video_mbus_to_pix_mp(const struct v4l2_mbus_framefmt *mbus,
+struct v4l2_pix_format_mplane *pix)
+{
+   unsigned int i;
+   u32 bytesperline;
+
+   memset(pix, 0, sizeof(*pix));
+   v4l2_fill_pix_format_mplane(pix, mbus);
+
+   for (i = 0; i < ARRAY_SIZE(formats); ++i) {
+   if (formats[i].code == mbus->code)
+   break;
+   }
+
+   if (WARN_ON(i == ARRAY_SIZE(formats)))
+   return -EINVAL;
+
+   pix->pixelformat = formats[i].pixelformat;
+   pix->num_planes = 1;
+   bytesperline = pix->width * formats[i].bpp / 8;
+   bytesperline = ALIGN(bytesperline, 8);
+   pix->plane_fmt[0].bytesperline = bytesperline;
+   pix->plane_fmt[0].sizeimage = bytesperline * pix->height;
+
+   return 0;
+}
+
+static struct v4l2_subdev *video_remote_subdev(struct camss_video *video,
+  u32 *pad)
+{
+   struct media_pad *remote;
+
+   remote = media_entity_remote_pad(>pad);
+
+   if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
+   return NULL;
+
+   if (pad)
+   *pad = remote->index;
+
+   return media_entity_to_v4l2_subdev(remote->entity);
+}
+
+static int video_get_subdev_format(struct camss_video *video,
+  struct v4l2_format *format)
+{
+   struct v4l2_subdev_format fmt;
+   struct v4l2_subdev *subdev;
+   u32 pad;
+   int ret;
+
+   subdev = video_remote_subdev(video, );
+   if (subdev == NULL)
+   return -EINVAL;
+
+   fmt.pad = pad;
+   fmt.which = 

[PATCH v3 10/23] media: camss: Add VFE files

[Todor Tomov]

These files control the VFE module. The VFE has different input interfaces.
The PIX input interface feeds the input data to an image processing pipeline.
Three RDI input interfaces bypass the image processing pipeline. The VFE also
contains the AXI bus interface which writes the output data to memory.

RDI interfaces are supported in this version. PIX interface is not supported.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 1913 
 drivers/media/platform/qcom/camss-8x16/camss-vfe.h |  114 ++
 2 files changed, 2027 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-vfe.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-vfe.h

diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c 
b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
new file mode 100644
index 000..b6dd29b
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
@@ -0,0 +1,1913 @@
+/*
+ * camss-vfe.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE Module
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "camss-vfe.h"
+#include "camss.h"
+
+#define MSM_VFE_NAME "msm_vfe"
+
+#define vfe_line_array(ptr_line)   \
+   ((const struct vfe_line (*)[]) &(ptr_line[-(ptr_line->id)]))
+
+#define to_vfe(ptr_line)   \
+   container_of(vfe_line_array(ptr_line), struct vfe_device, ptr_line)
+
+#define VFE_0_HW_VERSION   0x000
+
+#define VFE_0_GLOBAL_RESET_CMD 0x00c
+#define VFE_0_GLOBAL_RESET_CMD_CORE(1 << 0)
+#define VFE_0_GLOBAL_RESET_CMD_CAMIF   (1 << 1)
+#define VFE_0_GLOBAL_RESET_CMD_BUS (1 << 2)
+#define VFE_0_GLOBAL_RESET_CMD_BUS_BDG (1 << 3)
+#define VFE_0_GLOBAL_RESET_CMD_REGISTER(1 << 4)
+#define VFE_0_GLOBAL_RESET_CMD_TIMER   (1 << 5)
+#define VFE_0_GLOBAL_RESET_CMD_PM  (1 << 6)
+#define VFE_0_GLOBAL_RESET_CMD_BUS_MISR(1 << 7)
+#define VFE_0_GLOBAL_RESET_CMD_TESTGEN (1 << 8)
+
+#define VFE_0_IRQ_CMD  0x024
+#define VFE_0_IRQ_CMD_GLOBAL_CLEAR (1 << 0)
+
+#define VFE_0_IRQ_MASK_0   0x028
+#define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)(1 << ((n) + 5))
+#define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n)   (1 << ((n) + 8))
+#define VFE_0_IRQ_MASK_0_RESET_ACK (1 << 31)
+#define VFE_0_IRQ_MASK_1   0x02c
+#define VFE_0_IRQ_MASK_1_VIOLATION (1 << 7)
+#define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK  (1 << 8)
+#define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n)(1 << ((n) + 9))
+
+#define VFE_0_IRQ_CLEAR_0  0x030
+#define VFE_0_IRQ_CLEAR_1  0x034
+
+#define VFE_0_IRQ_STATUS_0 0x038
+#define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)  (1 << ((n) + 5))
+#define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8))
+#define VFE_0_IRQ_STATUS_0_RESET_ACK   (1 << 31)
+#define VFE_0_IRQ_STATUS_1 0x03c
+#define VFE_0_IRQ_STATUS_1_VIOLATION   (1 << 7)
+#define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACK(1 << 8)
+
+#define VFE_0_VIOLATION_STATUS 0x48
+
+#define VFE_0_BUS_CMD  0x4c
+#define VFE_0_BUS_CMD_Mx_RLD_CMD(x)(1 << (x))
+
+#define VFE_0_BUS_CFG  0x050
+
+#define VFE_0_BUS_XBAR_CFG_x(x)(0x58 + 0x4 * ((x) / 2))
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT 8
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI0  5
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI1  6
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI2  7
+
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG(n) (0x06c + 0x24 * (n))
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_WR_PATH_SHIFT  0
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_FRM_BASED_SHIFT1
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_PING_ADDR(n)   (0x070 + 0x24 * (n))
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_PONG_ADDR(n)   (0x074 + 0x24 * (n))
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG(n)(0x078 + 0x24 * 
(n))
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG_FRM_DROP_PER_SHIFT2
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG_FRM_DROP_PER_MASK (0x1F << 2)
+
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_UB_CFG(n)  (0x07c + 

[PATCH v3 14/23] camss: vfe: Format conversion support using PIX interface

[Todor Tomov]

Use VFE PIX input interface and do format conversion in VFE.

Supported input format is UYVY (single plane YUV 4:2:2) and
its different sample order variations.

Supported output formats are:
- NV12/NV21 (two plane YUV 4:2:0)
- NV16/NV61 (two plane YUV 4:2:2)

Signed-off-by: Todor Tomov 
---
 .../media/platform/qcom/camss-8x16/camss-ispif.c   |   2 +
 drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 673 ++---
 drivers/media/platform/qcom/camss-8x16/camss-vfe.h |  13 +-
 .../media/platform/qcom/camss-8x16/camss-video.c   | 332 +++---
 .../media/platform/qcom/camss-8x16/camss-video.h   |   8 +-
 5 files changed, 875 insertions(+), 153 deletions(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c 
b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
index cc32085..04918c0 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
+++ b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
@@ -969,6 +969,8 @@ static enum ispif_intf ispif_get_intf(enum vfe_line_id 
line_id)
return RDI1;
case (VFE_LINE_RDI2):
return RDI2;
+   case (VFE_LINE_PIX):
+   return PIX0;
default:
return RDI0;
}
diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c 
b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
index b6dd29b..bef0209 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -52,29 +53,53 @@
 #define VFE_0_GLOBAL_RESET_CMD_BUS_MISR(1 << 7)
 #define VFE_0_GLOBAL_RESET_CMD_TESTGEN (1 << 8)
 
+#define VFE_0_MODULE_CFG   0x018
+#define VFE_0_MODULE_CFG_DEMUX (1 << 2)
+#define VFE_0_MODULE_CFG_CHROMA_UPSAMPLE   (1 << 3)
+#define VFE_0_MODULE_CFG_SCALE_ENC (1 << 23)
+
+#define VFE_0_CORE_CFG 0x01c
+#define VFE_0_CORE_CFG_PIXEL_PATTERN_YCBYCR0x4
+#define VFE_0_CORE_CFG_PIXEL_PATTERN_YCRYCB0x5
+#define VFE_0_CORE_CFG_PIXEL_PATTERN_CBYCRY0x6
+#define VFE_0_CORE_CFG_PIXEL_PATTERN_CRYCBY0x7
+
 #define VFE_0_IRQ_CMD  0x024
 #define VFE_0_IRQ_CMD_GLOBAL_CLEAR (1 << 0)
 
 #define VFE_0_IRQ_MASK_0   0x028
+#define VFE_0_IRQ_MASK_0_CAMIF_SOF (1 << 0)
+#define VFE_0_IRQ_MASK_0_CAMIF_EOF (1 << 1)
 #define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)(1 << ((n) + 5))
+#define VFE_0_IRQ_MASK_0_line_n_REG_UPDATE(n)  \
+   ((n) == VFE_LINE_PIX ? (1 << 4) : VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n))
 #define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n)   (1 << ((n) + 8))
+#define VFE_0_IRQ_MASK_0_IMAGE_COMPOSITE_DONE_n(n) (1 << ((n) + 25))
 #define VFE_0_IRQ_MASK_0_RESET_ACK (1 << 31)
 #define VFE_0_IRQ_MASK_1   0x02c
+#define VFE_0_IRQ_MASK_1_CAMIF_ERROR   (1 << 0)
 #define VFE_0_IRQ_MASK_1_VIOLATION (1 << 7)
 #define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK  (1 << 8)
 #define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n)(1 << ((n) + 9))
+#define VFE_0_IRQ_MASK_1_RDIn_SOF(n)   (1 << ((n) + 29))
 
 #define VFE_0_IRQ_CLEAR_0  0x030
 #define VFE_0_IRQ_CLEAR_1  0x034
 
 #define VFE_0_IRQ_STATUS_0 0x038
+#define VFE_0_IRQ_STATUS_0_CAMIF_SOF   (1 << 0)
 #define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)  (1 << ((n) + 5))
+#define VFE_0_IRQ_STATUS_0_line_n_REG_UPDATE(n)\
+   ((n) == VFE_LINE_PIX ? (1 << 4) : VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n))
 #define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8))
+#define VFE_0_IRQ_STATUS_0_IMAGE_COMPOSITE_DONE_n(n)   (1 << ((n) + 25))
 #define VFE_0_IRQ_STATUS_0_RESET_ACK   (1 << 31)
 #define VFE_0_IRQ_STATUS_1 0x03c
 #define VFE_0_IRQ_STATUS_1_VIOLATION   (1 << 7)
 #define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACK(1 << 8)
+#define VFE_0_IRQ_STATUS_1_RDIn_SOF(n) (1 << ((n) + 29))
 
+#define VFE_0_IRQ_COMPOSITE_MASK_0 0x40
 #define VFE_0_VIOLATION_STATUS 0x48
 
 #define VFE_0_BUS_CMD  0x4c
@@ -83,7 +108,10 @@
 #define VFE_0_BUS_CFG  0x050
 
 #define VFE_0_BUS_XBAR_CFG_x(x)(0x58 + 0x4 * ((x) / 2))
+#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN  (1 << 1)
+#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA(0x3 << 4)
 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT 8
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_LUMA  0
 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI0  5
 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI1  6
 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI2  7
@@ -99,6 +127,8 @@
 
 #define 

Re: [PATCHv4 1/4] mfd: da9052: fix manual ADC read after timed out read

[Lee Jones]

On Fri, 30 Jun 2017, Sebastian Reichel wrote:

> It is possible that under heavy system load, the counter in the completion
> struct, used for waiting for end of AD conversion, gets incremented twice.
> To make sure the driver recovers from this situation, the completion struct
> should be reinitialized.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/mfd/da9052-core.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks.

> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index a88c2065d8ab..977418ca9117 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -386,6 +386,8 @@ int da9052_adc_manual_read(struct da9052 *da9052, 
> unsigned char channel)
>  
>   mutex_lock(>auxadc_lock);
>  
> + reinit_completion(>done);
> +
>   /* Channel gets activated on enabling the Conversion bit */
>   mux_sel = chan_mux[channel] | DA9052_ADC_MAN_MAN_CONV;
>  

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

[PATCH 08/15] kernel: convert ring_buffer.aux_refcount from atomic_t to refcount_t

[Elena Reshetova]

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Suggested-by: Kees Cook 
Reviewed-by: David Windsor 
Reviewed-by: Hans Liljestrand 
Signed-off-by: Elena Reshetova 
---
 kernel/events/core.c| 2 +-
 kernel/events/internal.h| 2 +-
 kernel/events/ring_buffer.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 9147397..072327e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5124,7 +5124,7 @@ static void perf_mmap_close(struct vm_area_struct *vma)
 
/* this has to be the last one */
rb_free_aux(rb);
-   WARN_ON_ONCE(atomic_read(>aux_refcount));
+   WARN_ON_ONCE(refcount_read(>aux_refcount));
 
mutex_unlock(>mmap_mutex);
}
diff --git a/kernel/events/internal.h b/kernel/events/internal.h
index b8e6fdf..fb55716 100644
--- a/kernel/events/internal.h
+++ b/kernel/events/internal.h
@@ -48,7 +48,7 @@ struct ring_buffer {
atomic_taux_mmap_count;
unsigned long   aux_mmap_locked;
void(*free_aux)(void *);
-   atomic_taux_refcount;
+   refcount_t  aux_refcount;
void**aux_pages;
void*aux_priv;
 
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index 3353572..ba12fd2 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -357,7 +357,7 @@ void *perf_aux_output_begin(struct perf_output_handle 
*handle,
if (!atomic_read(>aux_mmap_count))
goto err;
 
-   if (!atomic_inc_not_zero(>aux_refcount))
+   if (!refcount_inc_not_zero(>aux_refcount))
goto err;
 
/*
@@ -648,7 +648,7 @@ int rb_alloc_aux(struct ring_buffer *rb, struct perf_event 
*event,
 * we keep a refcount here to make sure either of the two can
 * reference them safely.
 */
-   atomic_set(>aux_refcount, 1);
+   refcount_set(>aux_refcount, 1);
 
rb->aux_overwrite = overwrite;
rb->aux_watermark = watermark;
@@ -667,7 +667,7 @@ int rb_alloc_aux(struct ring_buffer *rb, struct perf_event 
*event,
 
 void rb_free_aux(struct ring_buffer *rb)
 {
-   if (atomic_dec_and_test(>aux_refcount))
+   if (refcount_dec_and_test(>aux_refcount))
__rb_free_aux(rb);
 }
 
-- 
2.7.4

Re: [PATCHv4 3/4] dt-bindings: mfd: da9052: support TSI as ADC

[Lee Jones]

On Fri, 30 Jun 2017, Sebastian Reichel wrote:

> DA9052 allows using the touchscreen input pins as general purpose
> analogue input pin by wiring analogue inputs to X+, X-, Y+ and Y-
> and providing a reference voltage at TSIREF pin.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  Documentation/devicetree/bindings/mfd/da9052-i2c.txt | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt 
> b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> index 9554292dc6cb..57fa74e65664 100644
> --- a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> @@ -4,6 +4,14 @@ Required properties:
>  - compatible : Should be "dlg,da9052", "dlg,da9053-aa",
>"dlg,da9053-ab", or "dlg,da9053-bb"
>  
> +Optional properties:
> +- dlg,tsi-as-adc : Boolean, if set the X+, X-, Y+, Y- touchscreen
> +input lines are used as general purpose analogue
> + input.
> +- tsiref-supply: Phandle to the regulator, which provides the reference
> + voltage for the TSIREF pin. Must be provided when the
> +  touchscreen pins are used for ADC purposes.
> +

DT Ack please.

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

Re: [PATCH 1/2] tee.txt: standardize document format

[Jens Wiklander]

On Wed, Jul 12, 2017 at 10:35:04AM -0300, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different format. Some
> doesn't even have titles!
> 
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
> 
> - adjust identation of titles;
> - mark ascii artwork as a literal block;
> - adjust references.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Looks good to me. In case you're taking it by some other route:
Acked-by: Jens Wiklander 

Please let me know if you'd like me to pick it up.

--
Thanks,
Jens

Re: [PATCH] printk: modify console_unlock with printk-safe macros

[pierre kuo]

hi Sergey and Andy:
> On (07/15/17 18:36), Pierre Kuo wrote:
> [..]
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index fc47863..21557cc 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -2194,8 +2194,7 @@ void console_unlock(void)
>>   size_t ext_len = 0;
>>   size_t len;
>>
>> - printk_safe_enter_irqsave(flags);
>> - raw_spin_lock(_lock);
>> + logbuf_lock_irqsave(flags);
>>   if (seen_seq != log_next_seq) {
>>   wake_klogd = true;
>>   seen_seq = log_next_seq;
>> @@ -2267,8 +2266,7 @@ void console_unlock(void)
>>*/
>>   raw_spin_lock(_lock);
>>   retry = console_seq != log_next_seq;
>> - raw_spin_unlock(_lock);
>> - printk_safe_exit_irqrestore(flags);
>> + logbuf_unlock_irqrestore(flags);
>>
>>   if (retry && console_trylock())
>>   goto again;
>
> I did it that particular way for a reason - console_unlock() does a
> bunch of tricks: unlocking logbuf in the middle of printing loop,
> breaking out of loop with local IRQs disabled, re-taking the logbuf
> after the loop still will local IRQs disabled, etc. etc. I didn't
> want to (and still don't) mix-in logbuf macros; we do things that
> macros don't cover anyway. sorry, I don't agree that the patch
> improves readability.
Got ur points and appreciate for your illustration. ^^
Thanks a lot,

Re: [PATCH 0/2] use correct values for startup time bits for AXP22X/AXP8XX PEKs

[Quentin Schulz]

Hi all,

On 17/07/2017 11:53, Quentin Schulz wrote:
> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> AXP809 and AXP813 PEK have different values for startup time bits from
> the AXP20X PEK (which are currently used for all the aforementioned PMICs).
> 
> This patch series adds support for platform_device_id to axp20x-pek driver
> to support different startup time bits depending on PMIC's variant and set
> the correct platform_device_id in the mfd.
> 
> This has been tested on AXP813. To perform the test, modify the value of
> startup and/or shutdown of the pek in sysfs. Press the button soldered to
> PEK input of the AXP the amount of time you set in sysfs. The PMIC shuts
> down the board without needing to unplug any power supply. Press PEK button
> the amount of time you set in sysfs for startup and the PMIC will start the
> board. Note that the time bits are obivoulsy hardware reset to their
> default when you unplug all power supplies from the board.
> 

I forgot to add that it depends on this patch series (particularly the
third patch (3/6) "mfd: axp20x: Add support for AXP813 PMIC") from
Chen-Yu:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1428284.html

Quentin

> Thanks,
> Quentin
> 
> Quentin Schulz (2):
>   Input: axp20x-pek: add support for AXP221 PEK
>   mfd: axp20x: use correct platform device id for many PEK
> 
>  drivers/input/misc/axp20x-pek.c | 62 
> ++---
>  drivers/mfd/axp20x.c| 12 
>  2 files changed, 58 insertions(+), 16 deletions(-)
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [RFC PATCH] ARM: dts: stm32: change pinctrl bindings definition

[Arnd Bergmann]

On Mon, Jul 17, 2017 at 1:00 PM, Alexandre TORGUE
 wrote:
> blabla
>
> Signed-off-by: Alexandre TORGUE 

You may want to provide a little more detail here ;-)

 Arnd

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

[Sricharan R]

Hi,

On 7/15/2017 1:09 AM, Rob Clark wrote:
> On Fri, Jul 14, 2017 at 3:36 PM, Will Deacon  wrote:
>> On Fri, Jul 14, 2017 at 03:34:42PM -0400, Rob Clark wrote:
>>> On Fri, Jul 14, 2017 at 3:01 PM, Will Deacon  wrote:
 On Fri, Jul 14, 2017 at 02:25:45PM -0400, Rob Clark wrote:
> On Fri, Jul 14, 2017 at 2:06 PM, Will Deacon  wrote:
>> On Fri, Jul 14, 2017 at 01:42:13PM -0400, Rob Clark wrote:
>>> On Fri, Jul 14, 2017 at 1:07 PM, Will Deacon  
>>> wrote:
 On Thu, Jul 13, 2017 at 10:55:10AM -0400, Rob Clark wrote:
> On Thu, Jul 13, 2017 at 9:53 AM, Sricharan R 
>  wrote:
>> Hi,
>>
>> On 7/13/2017 5:20 PM, Rob Clark wrote:
>>> On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R 
>>>  wrote:
 Hi Vivek,

 On 7/13/2017 10:43 AM, Vivek Gautam wrote:
> Hi Stephen,
>
>
> On 07/13/2017 04:24 AM, Stephen Boyd wrote:
>> On 07/06, Vivek Gautam wrote:
>>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct 
>>> iommu_domain *domain, unsigned long iova,
>>>   static size_t arm_smmu_unmap(struct iommu_domain *domain, 
>>> unsigned long iova,
>>>size_t size)
>>>   {
>>> -struct io_pgtable_ops *ops = 
>>> to_smmu_domain(domain)->pgtbl_ops;
>>> +struct arm_smmu_domain *smmu_domain = 
>>> to_smmu_domain(domain);
>>> +struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
>>> +size_t ret;
>>> if (!ops)
>>>   return 0;
>>>   -return ops->unmap(ops, iova, size);
>>> +pm_runtime_get_sync(smmu_domain->smmu->dev);
>> Can these map/unmap ops be called from an atomic context? I seem
>> to recall that being a problem before.
>
> That's something which was dropped in the following patch merged 
> in master:
> 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock
>
> Looks like we don't  need locks here anymore?

  Apart from the locking, wonder why a explicit pm_runtime is needed
  from unmap. Somehow looks like some path in the master using that
  should have enabled the pm ?

>>>
>>> Yes, there are a bunch of scenarios where unmap can happen with
>>> disabled master (but not in atomic context).  On the gpu side we
>>> opportunistically keep a buffer mapping until the buffer is freed
>>> (which can happen after gpu is disabled).  Likewise, v4l2 won't 
>>> unmap
>>> an exported dmabuf while some other driver holds a reference to it
>>> (which can be dropped when the v4l2 device is suspended).
>>>
>>> Since unmap triggers tbl flush which touches iommu regs, the iommu
>>> driver *definitely* needs a pm_runtime_get_sync().
>>
>>  Ok, with that being the case, there are two things here,
>>
>>  1) If the device links are still intact at these places where unmap 
>> is called,
>> then pm_runtime from the master would setup the all the clocks. 
>> That would
>> avoid reintroducing the locking indirectly here.
>>
>>  2) If not, then doing it here is the only way. But for both cases, 
>> since
>> the unmap can be called from atomic context, resume handler here 
>> should
>> avoid doing clk_prepare_enable , instead move the clk_prepare to 
>> the init.
>>
>
> I do kinda like the approach Marek suggested.. of deferring the tlb
> flush until resume.  I'm wondering if we could combine that with
> putting the mmu in a stalled state when we suspend (and not resume the
> mmu until after the pending tlb flush)?

 I'm not sure that a stalled state is what we're after here, because we 
 need
 to take care to prevent any table walks if we've freed the underlying 
 pages.
 What we could try to do is disable the SMMU (put into global bypass) 
 and
 invalidate the TLB when performing a suspend operation, then we just 
 ignore
 invalidation whilst the clocks are stopped and, on resume, enable the 
 SMMU
 again.
>>>
>>> wouldn't stalled just block any memory transactions by device(s) using
>>> the context bank?  Putting it in bypass isn't really a good thing if
>>> there is any chance the device can sneak in a memory access before
>>> we've taking it back out of bypass (ie. 

Re: [PATCH 4/6] ARM: vexpress_defconfig: Cleanup from non-existing options

[Liviu Dudau]

On Mon, Jul 17, 2017 at 07:49:54AM +0200, Krzysztof Kozlowski wrote:
> ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30 ("ARM: vexpress:
> Remove non-DT code").
> 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Liviu Dudau 

Thanks for the cleanup!

Best regards,
Liviu

> ---
>  arch/arm/configs/vexpress_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/configs/vexpress_defconfig 
> b/arch/arm/configs/vexpress_defconfig
> index 0fa0ed577b15..edae1c58fe80 100644
> --- a/arch/arm/configs/vexpress_defconfig
> +++ b/arch/arm/configs/vexpress_defconfig
> @@ -19,7 +19,6 @@ CONFIG_MODULE_UNLOAD=y
>  # CONFIG_IOSCHED_DEADLINE is not set
>  # CONFIG_IOSCHED_CFQ is not set
>  CONFIG_ARCH_VEXPRESS=y
> -CONFIG_ARCH_VEXPRESS_CA9X4=y
>  CONFIG_ARCH_VEXPRESS_DCSCB=y
>  CONFIG_ARCH_VEXPRESS_TC2_PM=y
>  # CONFIG_SWP_EMULATE is not set
> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

Re: [PATCH 04/22] scsi: fusion: fix string overflow warning

[Arnd Bergmann]

On Mon, Jul 17, 2017 at 11:17 AM, David Laight  wrote:
> From: Arnd Bergmann
>> Sent: 14 July 2017 13:07
>> gcc points out a theorerical string overflow:
>>
>> drivers/message/fusion/mptbase.c: In function 'mpt_detach':
>> drivers/message/fusion/mptbase.c:2103:17: error: '%s' directive writing up 
>> to 31 bytes into a region
>> of size 28 [-Werror=format-overflow=]
>> sprintf(pname, MPT_PROCFS_MPTBASEDIR "/%s/summary", ioc->name);
>>^
>> drivers/message/fusion/mptbase.c:2103:2: note: 'sprintf' output between 13 
>> and 44 bytes into a
>> destination of size 32
>>
>> We can simply double the size of the local buffer here to be on the
>> safe side.
>
> I think I'd change it to snprintf() as well.
> Saves any worries if ioc->name isn't '\0' terminated.

Ok, fair enough, I'll send a new version right away.

  Arnd

Re: [PATCH 2/2] usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB controller

[Mathias Nyman]

On 10.07.2017 18:52, Marc Zyngier wrote:

The Renesas uPD72020x XHCI controller seems to suffer from a
really annoying bug, where it may retain some of its DMA programming
across a XHCI reset, and despite the driver correctly programming new
DMA addresses. This is visible if the device has been using 64bit DMA
addresses, and is then switched to using 32bit DMA addresses. The top
32bits of the address (now zero) are ignored are replaced by the 32bit
from the *previous* programming. Sticking with 64bit DMA always works,
but doesn't seem very appropriate.

A PCI reset of the device restores the normal functionnality, which
is done at probe time. Unfortunately, this has to be done before
any quirk has been discovered, hence the intrusive nature of the fix.

Signed-off-by: Marc Zyngier 
---
  drivers/usb/host/pci-quirks.c | 20 
  drivers/usb/host/pci-quirks.h |  1 +
  drivers/usb/host/xhci-pci.c   |  7 +++
  3 files changed, 28 insertions(+)



Acked-by: Mathias Nyman 

[PATCH 6/7] dt-bindings: pci: qcom: Add support for IPQ8074

[Varadarajan Narayanan]

Add support for the IPQ8074 PCIe controller.  IPQ8074 supports Gen 1/2, one
lane, two PCIe root complex with support for MSI and legacy interrupts, and
it conforms to PCI Express Base 2.1 specification.

Signed-off-by: Varadarajan Narayanan 
---
 .../devicetree/bindings/pci/qcom,pcie.txt  | 67 ++
 1 file changed, 67 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt 
b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
index 9d418b7..643bcc2 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -9,6 +9,7 @@
- "qcom,pcie-apq8084" for apq8084
- "qcom,pcie-msm8996" for msm8996 or apq8096
- "qcom,pcie-ipq4019" for ipq4019
+   - "qcom,pcie-ipq8074" for ipq8074
 
 - reg:
Usage: required
@@ -261,3 +262,69 @@
pinctrl-0 = <_pins_default>;
pinctrl-names = "default";
};
+
+* Example for ipq8074
+   pcie0: pci@2000 {
+   compatible = "qcom,pcie-ipq8074";
+   reg =  <0x2000 0xf1d
+   0x2F20 0xa8
+   0x8 0x2000
+   0x2010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   phys = <_0>;
+   phy-names = "pciephy";
+
+   ranges = <0x8100 0 0x2020 0x2020
+ 0 0x0010   /* downstream I/O */
+ 0x8200 0 0x2030 0x2030
+ 0 0x00d0>; /* non-prefetchable memory */
+
+   interrupts = <0 52 0>;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 75
+IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 78
+IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 79
+IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 83
+IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+   clocks =< GCC_SYS_NOC_PCIE0_AXI_CLK>,
+   < GCC_PCIE0_AXI_M_CLK>,
+   < GCC_PCIE0_AXI_S_CLK>,
+   < GCC_PCIE0_AHB_CLK>,
+   < GCC_PCIE0_AUX_CLK>;
+   clock-names =   "sys_noc",
+   "axi_m",
+   "axi_s",
+   "ahb",
+   "aux";
+
+   resets = < GCC_PCIE0_PIPE_ARES>,
+< GCC_PCIE0_SLEEP_ARES>,
+< GCC_PCIE0_CORE_STICKY_ARES>,
+< GCC_PCIE0_AXI_MASTER_ARES>,
+< GCC_PCIE0_AXI_SLAVE_ARES>,
+< GCC_PCIE0_AHB_ARES>,
+< GCC_PCIE0_AXI_MASTER_STICKY_ARES>;
+   reset-names = "pipe",
+ "sleep",
+ "sticky",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "axi_m_sticky";
+
+   perst-gpio = < 58 1>;
+   status = "disabled";
+   };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

[Varadarajan Narayanan]

Add support for the IPQ8074 PCIe controller.  IPQ8074 supports
Gen 1/2, one lane, two PCIe root complex with support for MSI and
legacy interrupts, and it conforms to PCI Express Base 2.1
specification.

The core init is the similar to the existing SoC, however the
clocks and reset lines differ.

Signed-off-by: smuthayy 
Signed-off-by: Varadarajan Narayanan 
---
 drivers/pci/dwc/pcie-qcom.c | 259 
 1 file changed, 259 insertions(+)

diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
index d15657d..c1fa356 100644
--- a/drivers/pci/dwc/pcie-qcom.c
+++ b/drivers/pci/dwc/pcie-qcom.c
@@ -37,6 +37,20 @@
 #include "pcie-designware.h"
 
 #define PCIE20_PARF_SYS_CTRL   0x00
+#define MST_WAKEUP_EN  BIT(13)
+#define SLV_WAKEUP_EN  BIT(12)
+#define MSTR_ACLK_CGC_DIS  BIT(10)
+#define SLV_ACLK_CGC_DIS   BIT(9)
+#define CORE_CLK_CGC_DIS   BIT(6)
+#define AUX_PWR_DETBIT(4)
+#define L23_CLK_RMV_DISBIT(2)
+#define L1_CLK_RMV_DIS BIT(1)
+
+#define PCIE20_COMMAND_STATUS  0x04
+#define CMD_BME_VAL0x4
+#define PCIE20_DEVICE_CONTROL2_STATUS2 0x98
+#define PCIE_CAP_CPL_TIMEOUT_DISABLE   0x10
+
 #define PCIE20_PARF_PHY_CTRL   0x40
 #define PCIE20_PARF_PHY_REFCLK 0x4C
 #define PCIE20_PARF_DBI_BASE_ADDR  0x168
@@ -58,9 +72,22 @@
 #define CFG_BRIDGE_SB_INIT BIT(0)
 
 #define PCIE20_CAP 0x70
+#define PCIE20_CAP_LINK_CAPABILITIES   (PCIE20_CAP + 0xC)
+#define PCIE20_CAP_LINK_1  (PCIE20_CAP + 0x14)
+#define PCIE_CAP_LINK1_VAL 0x2fd7f
+
+#define PCIE20_PARF_Q2A_FLUSH  0x1AC
+
+#define PCIE20_MISC_CONTROL_1_REG  0x8BC
+#define DBI_RO_WR_EN   1
 
 #define PERST_DELAY_US 1000
 
+#define AXI_CLK_RATE   2
+
+#define PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE 0x358
+#define SLV_ADDR_SPACE_SZ   0x1000
+
 struct qcom_pcie_resources_v0 {
struct clk *iface_clk;
struct clk *core_clk;
@@ -110,11 +137,26 @@ struct qcom_pcie_resources_v3 {
struct reset_control *phy_ahb_reset;
 };
 
+struct qphy_reset {
+   struct reset_control*rst;
+   char*name;
+};
+
+struct qcom_pcie_resources_v4 {
+   struct clk *sys_noc_clk;
+   struct clk *axi_m_clk;
+   struct clk *axi_s_clk;
+   struct clk *ahb_clk;
+   struct clk *aux_clk;
+   struct qphy_reset rst[7];
+};
+
 union qcom_pcie_resources {
struct qcom_pcie_resources_v0 v0;
struct qcom_pcie_resources_v1 v1;
struct qcom_pcie_resources_v2 v2;
struct qcom_pcie_resources_v3 v3;
+   struct qcom_pcie_resources_v4 v4;
 };
 
 struct qcom_pcie;
@@ -139,6 +181,16 @@ struct qcom_pcie {
 
 #define to_qcom_pcie(x)dev_get_drvdata((x)->dev)
 
+static inline void
+writel_masked(void __iomem *addr, u32 clear_mask, u32 set_mask)
+{
+   u32 val = readl(addr);
+
+   val &= ~clear_mask;
+   val |= set_mask;
+   writel(val, addr);
+}
+
 static void qcom_ep_reset_assert(struct qcom_pcie *pcie)
 {
gpiod_set_value(pcie->reset, 1);
@@ -884,6 +936,205 @@ static int qcom_pcie_init_v3(struct qcom_pcie *pcie)
return ret;
 }
 
+static int qcom_pcie_get_resources_v4(struct qcom_pcie *pcie)
+{
+   struct qcom_pcie_resources_v4 *res = >res.v4;
+   struct dw_pcie *pci = pcie->pci;
+   struct device *dev = pci->dev;
+   int i;
+
+   res->sys_noc_clk = devm_clk_get(dev, "sys_noc");
+   if (IS_ERR(res->sys_noc_clk))
+   return PTR_ERR(res->sys_noc_clk);
+
+   res->axi_m_clk = devm_clk_get(dev, "axi_m");
+   if (IS_ERR(res->axi_m_clk))
+   return PTR_ERR(res->axi_m_clk);
+
+   res->axi_s_clk = devm_clk_get(dev, "axi_s");
+   if (IS_ERR(res->axi_s_clk))
+   return PTR_ERR(res->axi_s_clk);
+
+   res->ahb_clk = devm_clk_get(dev, "ahb");
+   if (IS_ERR(res->ahb_clk))
+   return PTR_ERR(res->ahb_clk);
+
+   res->aux_clk = devm_clk_get(dev, "aux");
+   if (IS_ERR(res->aux_clk))
+   return PTR_ERR(res->aux_clk);
+
+   res->rst[0].name = "axi_m";
+   res->rst[1].name = "axi_s";
+   res->rst[2].name = "pipe";
+   res->rst[3].name = "axi_m_sticky";
+   res->rst[4].name = "sticky";
+   res->rst[5].name = "ahb";
+   res->rst[6].name = "sleep";
+
+   for (i = 0; i < ARRAY_SIZE(res->rst); i++) {
+   res->rst[i].rst = devm_reset_control_get(dev, res->rst[i].name);
+   if (IS_ERR(res->rst[i].rst))
+  

[PATCH 3/7] phy: qcom-qmp: Fix phy pipe clock name

[Varadarajan Narayanan]

Presently, the phy pipe clock's name is assumed to be either
usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the
phy lane's number). However, this will not work if an SoC has
more than one instance of the phy. Hence, instead of assuming
the name of the clock, fetch it from the DT.

Signed-off-by: Varadarajan Narayanan 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 78ca628..97020ec 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -925,20 +925,13 @@ static int qcom_qmp_phy_clk_init(struct device *dev)
  *clk  |   +---+   |   +-+
  * +---+
  */
-static int phy_pipe_clk_register(struct qcom_qmp *qmp, int id)
+static int phy_pipe_clk_register(struct qcom_qmp *qmp, const char *clk_name)
 {
-   char name[24];
struct clk_fixed_rate *fixed;
struct clk_init_data init = { };
 
-   switch (qmp->cfg->type) {
-   case PHY_TYPE_USB3:
-   snprintf(name, sizeof(name), "usb3_phy_pipe_clk_src");
-   break;
-   case PHY_TYPE_PCIE:
-   snprintf(name, sizeof(name), "pcie_%d_pipe_clk_src", id);
-   break;
-   default:
+   if ((qmp->cfg->type != PHY_TYPE_USB3) &&
+   (qmp->cfg->type != PHY_TYPE_PCIE)) {
/* not all phys register pipe clocks, so return success */
return 0;
}
@@ -947,7 +940,7 @@ static int phy_pipe_clk_register(struct qcom_qmp *qmp, int 
id)
if (!fixed)
return -ENOMEM;
 
-   init.name = name;
+   init.name = clk_name;
init.ops = _fixed_rate_ops;
 
/* controllers using QMP phys use 125MHz pipe clock interface */
@@ -1110,6 +1103,8 @@ static int qcom_qmp_phy_probe(struct platform_device 
*pdev)
 
id = 0;
for_each_available_child_of_node(dev->of_node, child) {
+   const char *clk_name;
+
/* Create per-lane phy */
ret = qcom_qmp_phy_create(dev, child, id);
if (ret) {
@@ -1118,11 +1113,20 @@ static int qcom_qmp_phy_probe(struct platform_device 
*pdev)
return ret;
}
 
+   ret = of_property_read_string(child, "clock-output-names",
+   _name);
+   if (ret) {
+   dev_err(dev,
+   "failed to get clock-output-names for lane%d 
phy, %d\n",
+   id, ret);
+   return ret;
+   }
+
/*
 * Register the pipe clock provided by phy.
 * See function description to see details of this pipe clock.
 */
-   ret = phy_pipe_clk_register(qmp, id);
+   ret = phy_pipe_clk_register(qmp, clk_name);
if (ret) {
dev_err(qmp->dev,
"failed to register pipe clock source\n");
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 5/7] phy: qcom-qmp: Add support for IPQ8074

[Varadarajan Narayanan]

Add definitions required to enable QMP phy support for IPQ8074.

Signed-off-by: smuthayy 
Signed-off-by: Varadarajan Narayanan 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 135 
 1 file changed, 135 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 000ad1c..9019f66 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -59,6 +59,7 @@
 #define QSERDES_COM_PLL_RCTRL_MODE10x088
 #define QSERDES_COM_PLL_CCTRL_MODE00x090
 #define QSERDES_COM_PLL_CCTRL_MODE10x094
+#define QSERDES_COM_BIAS_EN_CTRL_BY_PSM0x0a8
 #define QSERDES_COM_SYSCLK_EN_SEL  0x0ac
 #define QSERDES_COM_RESETSM_CNTRL  0x0b4
 #define QSERDES_COM_RESTRIM_CTRL   0x0bc
@@ -143,6 +144,11 @@
 #define QPHY_LOCK_DETECT_CONFIG3   0x88
 #define QPHY_PWRUP_RESET_DLY_TIME_AUXCLK   0xa0
 #define QPHY_LP_WAKEUP_DLY_TIME_AUXCLK 0xa4
+#define QPHY_PLL_LOCK_CHK_DLY_TIME_AUXCLK_LSB  0x1A8
+#define QPHY_OSC_DTCT_ACTIONS  0x1AC
+#define QPHY_RX_SIGDET_LVL 0x1D8
+#define QPHY_L1SS_WAKEUP_DLY_TIME_AUXCLK_LSB   0x1DC
+#define QPHY_L1SS_WAKEUP_DLY_TIME_AUXCLK_MSB   0x1E0
 
 /* QPHY_SW_RESET bit */
 #define SW_RESET   BIT(0)
@@ -224,6 +230,17 @@ enum qphy_reg_layout {
[QPHY_PCS_READY_STATUS] = 0x174,
 };
 
+static const unsigned int ipq8074_pciephy_regs_layout[] = {
+   [QPHY_COM_SW_RESET] = 0x800,
+   [QPHY_COM_POWER_DOWN_CONTROL]   = 0x804,
+   [QPHY_COM_START_CONTROL]= 0x808,
+   [QPHY_COM_PCS_READY_STATUS] = QPHY_REG_INVAL,
+   [QPHY_PLL_LOCK_CHK_DLY_TIME]= 0xa8,
+   [QPHY_SW_RESET] = 0x00,
+   [QPHY_START_CTRL]   = 0x08,
+   [QPHY_PCS_READY_STATUS] = 0x174,
+};
+
 static const unsigned int usb3phy_regs_layout[] = {
[QPHY_FLL_CNTRL1]   = 0xc0,
[QPHY_FLL_CNTRL2]   = 0xc4,
@@ -582,6 +599,121 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.mask_pcs_ready = PHYSTATUS,
 };
 
+static const struct qmp_phy_init_tbl ipq8074_pcie_serdes_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x18),
+   QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
+   QMP_PHY_INIT_CFG(QSERDES_COM_BG_TRIM, 0xf),
+   QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP_EN, 0x1),
+   QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_MAP, 0x0),
+   QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER1, 0x1f),
+   QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER2, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_COM_CMN_CONFIG, 0x6),
+   QMP_PHY_INIT_CFG(QSERDES_COM_PLL_IVCO, 0xf),
+   QMP_PHY_INIT_CFG(QSERDES_COM_HSCLK_SEL, 0x0),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SVS_MODE_CLK_SEL, 0x1),
+   QMP_PHY_INIT_CFG(QSERDES_COM_CORE_CLK_EN, 0x20),
+   QMP_PHY_INIT_CFG(QSERDES_COM_CORECLK_DIV, 0xa),
+   QMP_PHY_INIT_CFG(QSERDES_COM_RESETSM_CNTRL, 0x20),
+   QMP_PHY_INIT_CFG(QSERDES_COM_BG_TIMER, 0xa),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SYSCLK_EN_SEL, 0xa),
+   QMP_PHY_INIT_CFG(QSERDES_COM_DEC_START_MODE0, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_COM_DIV_FRAC_START3_MODE0, 0x3),
+   QMP_PHY_INIT_CFG(QSERDES_COM_DIV_FRAC_START2_MODE0, 0x55),
+   QMP_PHY_INIT_CFG(QSERDES_COM_DIV_FRAC_START1_MODE0, 0x55),
+   QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP3_MODE0, 0x0),
+   QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP2_MODE0, 0xD),
+   QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP1_MODE0, 0xD04),
+   QMP_PHY_INIT_CFG(QSERDES_COM_CLK_SELECT, 0x33),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SYS_CLK_CTRL, 0x2),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SYSCLK_BUF_ENABLE, 0x1f),
+   QMP_PHY_INIT_CFG(QSERDES_COM_CP_CTRL_MODE0, 0xb),
+   QMP_PHY_INIT_CFG(QSERDES_COM_PLL_RCTRL_MODE0, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_COM_PLL_CCTRL_MODE0, 0x28),
+   QMP_PHY_INIT_CFG(QSERDES_COM_INTEGLOOP_GAIN1_MODE0, 0x0),
+   QMP_PHY_INIT_CFG(QSERDES_COM_INTEGLOOP_GAIN0_MODE0, 0x80),
+   QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CTRL_BY_PSM, 0x1),
+   QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_CTRL, 0xa),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SSC_EN_CENTER, 0x1),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SSC_PER1, 0x31),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SSC_PER2, 0x1),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SSC_ADJ_PER1, 0x2),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SSC_ADJ_PER2, 0x0),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SSC_STEP_SIZE1, 0x2f),
+   QMP_PHY_INIT_CFG(QSERDES_COM_SSC_STEP_SIZE2, 0x19),
+   QMP_PHY_INIT_CFG(QSERDES_COM_CLK_EP_DIV, 0x19),
+   QMP_PHY_INIT_CFG(QSERDES_RX_SIGDET_CNTRL, 0x7),
+};
+
+static const struct 

[PATCH 1/7] dt-bindings: phy: qmp: Add output-clock-names

[Varadarajan Narayanan]

The phy outputs a clock that will act as the parent for
the phy's pipe clock. Add the name of this clock to the
lane's DT node.

Signed-off-by: Varadarajan Narayanan 
---
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index e11c563..5d7a51f 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -60,6 +60,8 @@ Required properties for child node:
   one for each entry in clock-names.
  - clock-names: Must contain following for pcie and usb qmp phys:
 "pipe" for pipe clock specific to each lane.
+ - clock-output-names: Name of the phy clock that will be the parent for
+  the above pipe clock.
 
  - resets: a list of phandles and reset controller specifier pairs,
   one for each entry in reset-names.
@@ -96,6 +98,7 @@ Example:
 
clocks = < GCC_PCIE_0_PIPE_CLK>;
clock-names = "pipe0";
+   clock-output-names = "pcie_0_pipe_clk_src";
resets = < GCC_PCIE_0_PHY_BCR>;
reset-names = "lane0";
};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 0/7] Add support for IPQ8074 PCIe phy and controller

[Varadarajan Narayanan]

Add definitions required to enable QMP phy support for IPQ8074.

Add support for the IPQ8074 PCIe controller.  IPQ8074 supports
Gen 1/2, one lane, two PCIe root complex with support for MSI and
legacy interrupts, and it conforms to PCI Express Base 2.1
specification.

Varadarajan Narayanan (7):
  dt-bindings: phy: qmp: Add output-clock-names
  dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074
  phy: qcom-qmp: Fix phy pipe clock name
  phy: qcom-qmp: Handle unavailable registers
  phy: qcom-qmp: Add support for IPQ8074
  dt-bindings: pci: qcom: Add support for IPQ8074
  PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

 .../devicetree/bindings/pci/qcom,pcie.txt  |  67 ++
 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  31 +++
 drivers/pci/dwc/pcie-qcom.c| 259 +
 drivers/phy/qualcomm/phy-qcom-qmp.c| 186 +--
 4 files changed, 522 insertions(+), 21 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 2/7] dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074

[Varadarajan Narayanan]

IPQ8074 uses QMP phy controller that provides support to PCIe and
USB. Adding dt binding information for the same.

Signed-off-by: Varadarajan Narayanan 
---
 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index 5d7a51f..80d766b 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -6,6 +6,7 @@ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
 
 Required properties:
  - compatible: compatible list, contains:
+  "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074
   "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
   "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
 
@@ -107,3 +108,30 @@ Example:
...
...
};
+
+   phy@86000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x86000 0x1000>;
+
+   #clock-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   resets = < GCC_PCIE0_PHY_BCR>,
+< GCC_PCIE0PHY_PHY_BCR>;
+   reset-names = "phy",
+ "phy_phy";
+
+   status = "ok";
+
+   pciephy_0: lane@86000 {
+   reg = <0x86200 0x130>,
+   <0x86400 0x200>,
+   <0x86800 0x1f8>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE0_PIPE_CLK>;
+   clock-names = "pipe0";
+   clock-output-names = "pcie20_phy0_pipe_clk";
+   };
+   };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] mfd: Fix potential NULL pointer dereference

[Lee Jones]

On Wed, 05 Jul 2017, Christophe JAILLET wrote:

> if 'max8998_i2c_parse_dt_pdata() fails (when out of memory), a NULL
> pointer dereference will occur in the error handling code.
> 
> Return directly instead.
> 
> Fixes: ee999fb3f17f("mfd: max8998: Add support for Device Tree")
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/mfd/max8998.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c
> index 4c33b8063bc3..b1d3f70782d9 100644
> --- a/drivers/mfd/max8998.c
> +++ b/drivers/mfd/max8998.c
> @@ -192,10 +192,8 @@ static int max8998_i2c_probe(struct i2c_client *i2c,
>  
>   if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node) {
>   pdata = max8998_i2c_parse_dt_pdata(>dev);
> - if (IS_ERR(pdata)) {
> - ret = PTR_ERR(pdata);
> - goto err;
> - }
> + if (IS_ERR(pdata))
> + return PTR_ERR(pdata);
>   }
>  
>   i2c_set_clientdata(i2c, max8998);

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

Re: [PATCH V8 1/6] PM / Domains: Add support to select performance-state of domains

[Ulf Hansson]

On 21 June 2017 at 09:10, Viresh Kumar  wrote:
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are identified by positive
> integer values, a lower value represents lower performance state.
>
> This patch adds a new genpd API: pm_genpd_update_performance_state().
> The caller passes the affected device and the frequency representing its
> next DVFS state.
>
> The power domains get two new callbacks:
>
> - get_performance_state(): This is called by the genpd core to retrieve
>   the performance state (integer value) corresponding to a target
>   frequency for the device. This state is used by the genpd core to find
>   the highest requested state by all the devices powered by a domain.

Please clarify this a bit more.

I guess what you want to say is that genpd aggregates all requested
performance state of all its devices and its subdomains, to be able to
set a correct (highest requested) performance state.

Moreover, could you perhaps explain a bit on *when* this callback
becomes invoked.

>
> - set_performance_state(): The highest state retrieved from above
>   interface is then passed to this callback to finally program the
>   performance state of the power domain.

When will this callback be invoked?

What happens when a power domain gets powered off and then on. Is the
performance state restored? Please elaborate a bit on this.

>
> The power domains can avoid supplying these callbacks, if they don't
> support setting performance-states.
>
> A power domain may have only get_performance_state() callback, if it
> doesn't have the capability of changing the performance state itself but
> someone in its parent hierarchy has.
>
> A power domain may have only set_performance_state(), if it doesn't have
> any direct devices below it but subdomains. And so the
> get_performance_state() will never get called from the core.
>

It seems like the ->get_perfomance_state() is a device specific
callback, while the ->set_performance_state() is a genpd domain
callback.

I am wondering whether we should try to improve the names of the
callbacks to reflect this.

> The more common case would be to have both the callbacks set.
>
> Another API, pm_genpd_has_performance_state(), is also added to let
> other parts of the kernel check if the power domain of a device supports
> performance-states or not. This could have been done from

I think a better name of this function is:
dev_pm_genpd_has_performance_state(). What do you think?

We might even want to decide to explicitly stay using the terminology
"DVFS" instead. In such case, perhaps converting the names of the
callbacks/API to use "dvfs" instead. For the API added here, maybe
dev_pm_genpd_can_dvfs().

> pm_genpd_update_performance_state() as well, but that routine gets
> called every time we do DVFS for the device and it wouldn't be optimal
> in that case.

So pm_genpd_update_performance_state() is also a new API added in
$subject patch. But there is no information about it in the changelog,
besides the above. Please add that.

Moreover, perhaps we should rename the function to dev_pm_genpd_set_dvfs()

>
> Note that, the performance level as returned by
> ->get_performance_state() for the parent domain of a device is used for
> all domains in parent hierarchy.

Please clarify a bit on this. What exactly does this mean?

>
> Tested-by: Rajendra Nayak 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/base/power/domain.c | 223 
> 
>  include/linux/pm_domain.h   |  22 +
>  2 files changed, 245 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 71c95ad808d5..d506be9ff1f7 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -466,6 +466,229 @@ static int genpd_dev_pm_qos_notifier(struct 
> notifier_block *nb,
> return NOTIFY_DONE;
>  }
>
> +/*
> + * Returns true if anyone in genpd's parent hierarchy has
> + * set_performance_state() set.
> + */
> +static bool genpd_has_set_performance_state(struct generic_pm_domain *genpd)
> +{

So this function will be become in-directly called by generic drivers
that supports DVFS of the genpd for their devices.

I think the data you validate here would be better to be pre-validated
at pm_genpd_init() and at pm_genpd_add|remove_subdomain() and the
result stored in a variable in the genpd struct. Especially when a
subdomain is added, that is a point when you can verify the
*_performance_state() callbacks, and thus make sure it's a correct
setup from the topology point of view.

> +   struct gpd_link *link;
> +
> +   if (genpd->set_performance_state)
> +   return true;
> +
> +   list_for_each_entry(link, >slave_links, slave_node) {
> +   if (genpd_has_set_performance_state(link->master))
> +   return true;
> +

Re: [PATCH] staging: unisys: visorbus: constify attribute_group structures.

[Greg KH]

On Mon, Jul 17, 2017 at 05:43:14PM +0530, Arvind Yadav wrote:
> Hi Greg,
> 
> 
> On Monday 17 July 2017 04:15 PM, Greg KH wrote:
> > On Mon, Jul 17, 2017 at 02:55:37PM +0530, Arvind Yadav wrote:
> > > attribute_groups are not supposed to change at runtime. All functions
> > > working with attribute_groups provided by  work
> > > with const attribute_group. So mark the non-const structs as const.
> > > 
> > > Signed-off-by: Arvind Yadav 
> > > ---
> > >   drivers/staging/unisys/visorbus/visorbus_main.c | 4 ++--
> > >   drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
> > >   2 files changed, 3 insertions(+), 3 deletions(-)
> > Why not just use the ATTRIBUTE_GROUPS() macro for these?  Or is there
> > something that is preventing that?
> Yes, we can use. if we are only initializing '.attrs'.
> ATTRIBUTE_GROUPS() will not work if we will initialize other member of
> attribute_group like 'bin_attrs', 'is_visible', and  'name'.

That means you should redo this patch :)

Also, your changelog text had a typo, it is "attribute_group", not
"attribute_groups".

thanks,

greg k-h

Re: Regression with suspicious RCU usage splats with cpu_pm change

[Paul E. McKenney]

On Sun, Jul 16, 2017 at 11:08:07PM -0700, Tony Lindgren wrote:
> * Alex Shi  [170716 16:25]:
> > I reused the rcu_irq_enter_irqson() from RCU_NONIDLE to avoid this issue. 
> > It works fine.
> > 
> > Tony, Could you like to give a tested-by if this patch works for you.
> 
> Yeah that keeps things booting for me with no splats so:
> 
> Tested-by: Tony Lindgren 
> 
> In general, it seems we're missing the knowledge in Linux kernel
> of when the entire system is idle. Right now it seems that only
> cpuidle_coupled knows that?
> 
> We could probably simplify things by adding some PM state for
> entire system idle. Then cpuidle code and timer code could use
> that to test when it's safe to do whatever the SoC needs to do
> to enter deeper power states.
> 
> If we already have something like that, please do let me know :)

Well, we used to have CONFIG_NO_HZ_FULL_SYSIDLE, which detected
full-system idle lazily so as to avoid scalability bottlenecks.
https://lwn.net/Articles/558284/

No one was using it, so I removed it last merge window.  The
patch that removed it is at sysidle.2017.05.11a, which can
probably still be reverted cleanly.  Or just use v4.11 or earlier.

Thanx, Paul

Re: [PATCH 14/22] [media] usbvision-i2c: fix format overflow warning

[Hans Verkuil]

On 17/07/17 14:57, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 2:53 PM, Hans Verkuil  wrote:
>> On 14/07/17 14:07, Arnd Bergmann wrote:
>>> gcc-7 notices that we copy a fixed length string into another
>>> string of the same size, with additional characters:
>>>
>>> drivers/media/usb/usbvision/usbvision-i2c.c: In function 
>>> 'usbvision_i2c_register':
>>> drivers/media/usb/usbvision/usbvision-i2c.c:190:36: error: '%d' directive 
>>> writing between 1 and 11 bytes into a region of size between 0 and 47 
>>> [-Werror=format-overflow=]
>>>   sprintf(usbvision->i2c_adap.name, "%s-%d-%s", i2c_adap_template.name,
>>> ^~
>>> drivers/media/usb/usbvision/usbvision-i2c.c:190:2: note: 'sprintf' output 
>>> between 4 and 76 bytes into a destination of size 48
>>>
>>> We know this is fine as the template name is always "usbvision", so
>>> we can easily avoid the warning by using this as the format string
>>> directly.
>>
>> Hmm, how about replacing sprintf by snprintf? That feels a lot safer (this 
>> is very
>> old code, it's not surprising it is still using sprintf).
> 
> With snprintf(), you will still get a -Wformat-truncation warning. One
> of my patches
> disables that warning by default, but Mauro likes build-testing with
> "make W=1", so
> it would still show up then.
> 
> However, we can do both: replace the string and use snprintf().

Yes please!

Regards,

Hans

[PATCH] Staging: vt6655: Fixing coding style warnings

[Simo Koskinen]

Removes following warnings found by checkpatch.pl script:

WARNING: Prefer using '"%s...", __func__' to using 'xxx',
this function's name, in a string

Signed-off-by: Simo Koskinen 
---
 drivers/staging/vt6655/card.c | 6 +++---
 drivers/staging/vt6655/mac.c  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
index f5db2b3..14034e3 100644
--- a/drivers/staging/vt6655/card.c
+++ b/drivers/staging/vt6655/card.c
@@ -649,19 +649,19 @@ static unsigned short CARDwGetOFDMControlRate(struct 
vnt_private *priv,
pr_debug("BASIC RATE: %X\n", priv->basic_rates);
 
if (!CARDbIsOFDMinBasicRate((void *)priv)) {
-   pr_debug("CARDwGetOFDMControlRate:(NO OFDM) %d\n", wRateIdx);
+   pr_debug("%s:(NO OFDM) %d\n", __func__, wRateIdx);
if (wRateIdx > RATE_24M)
wRateIdx = RATE_24M;
return wRateIdx;
}
while (ui > RATE_11M) {
if (priv->basic_rates & ((u32)0x1 << ui)) {
-   pr_debug("CARDwGetOFDMControlRate : %d\n", ui);
+   pr_debug("%s : %d\n", __func__, ui);
return (unsigned short)ui;
}
ui--;
}
-   pr_debug("CARDwGetOFDMControlRate: 6M\n");
+   pr_debug("%s: 6M\n", __func__);
return (unsigned short)RATE_24M;
 }
 
diff --git a/drivers/staging/vt6655/mac.c b/drivers/staging/vt6655/mac.c
index 4aaa99b..f7550b2 100644
--- a/drivers/staging/vt6655/mac.c
+++ b/drivers/staging/vt6655/mac.c
@@ -809,7 +809,7 @@ void MACvSetKeyEntry(struct vnt_private *priv, unsigned 
short wKeyCtl,
if (byLocalID <= 1)
return;
 
-   pr_debug("MACvSetKeyEntry\n");
+   pr_debug("%s\n", __func__);
offset = MISCFIFO_KEYETRY0;
offset += (uEntryIdx * MISCFIFO_KEYENTRYSIZE);
 
-- 
2.7.4

Re: [PATCHv2] staging: iio: adc: add missing of_node references to iio_dev

[Lars-Peter Clausen]

Hi,

The patch seems to be reverted?

Also should this part in the IIO core take care of automatically setting the
of_node of the IIO device? As far as I can see we don't have to initialize
it manually.

/* If the calling driver did not initialize of_node, do it here */
if (!indio_dev->dev.of_node && indio_dev->dev.parent)
indio_dev->dev.of_node = indio_dev->dev.parent->of_node;

- Lars

On 07/17/2017 02:34 PM, Hari Prasath wrote:
> Adding missing indio_dev->dev.of_node references to allow iio consumers
> to access the device channels.
> 
> Signed-off-by: Hari Prasath 
> ---
>   v2: Wrong from mail ID in first version of patch
> ---
>  drivers/staging/iio/adc/ad7192.c | 1 -
>  drivers/staging/iio/adc/ad7780.c | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/adc/ad7192.c 
> b/drivers/staging/iio/adc/ad7192.c
> index 78308a5..d11c6de 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -668,7 +668,6 @@ static int ad7192_probe(struct spi_device *spi)
>   spi_set_drvdata(spi, indio_dev);
>   st->devid = spi_get_device_id(spi)->driver_data;
>   indio_dev->dev.parent = >dev;
> - indio_dev->dev.of_node = spi->dev.of_node;
>   indio_dev->name = spi_get_device_id(spi)->name;
>   indio_dev->modes = INDIO_DIRECT_MODE;
>  
> diff --git a/drivers/staging/iio/adc/ad7780.c 
> b/drivers/staging/iio/adc/ad7780.c
> index e38d2ab9..dec3ba6 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -195,7 +195,6 @@ static int ad7780_probe(struct spi_device *spi)
>   spi_set_drvdata(spi, indio_dev);
>  
>   indio_dev->dev.parent = >dev;
> - indio_dev->dev.of_node = spi->dev.of_node;
>   indio_dev->name = spi_get_device_id(spi)->name;
>   indio_dev->modes = INDIO_DIRECT_MODE;
>   indio_dev->channels = >chip_info->channel;
> 

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Li, Aubrey]

On 2017/7/14 12:05, Paul E. McKenney wrote:
>
> More specifically: rcu_needs_cpu(), rcu_prepare_for_idle(),
> rcu_cleanup_after_idle(), rcu_eqs_enter(), rcu_eqs_enter_common(),
> rcu_dynticks_eqs_enter(), do_nocb_deferred_wakeup(),
> rcu_dynticks_task_enter(), rcu_eqs_exit(), rcu_eqs_exit_common(),
> rcu_dynticks_task_exit(), rcu_dynticks_eqs_exit().
>
> The first three (rcu_needs_cpu(), rcu_prepare_for_idle(), and
> rcu_cleanup_after_idle()) should not be significant unless you have
> CONFIG_RCU_FAST_NO_HZ=y.  If you do, it would be interesting to learn
> how often invoke_rcu_core() is invoked from rcu_prepare_for_idle()
> and rcu_cleanup_after_idle(), as this can raise softirq.  Also
> rcu_accelerate_cbs() and rcu_try_advance_all_cbs().
>
> Knowing which of these is causing the most trouble might help me
> reduce the overhead in the current idle path.

I measured two cases, nothing notable found.

The one is CONFIG_NO_HZ_IDLE=y, so the following function is just empty.

rcu_prepare_for_idle(): NULL
rcu_cleanup_after_idle():   NULL
do_nocb_deferred_wakeup():  NULL
rcu_dynticks_task_enter():  NULL
rcu_dynticks_task_exit():   NULL

And the following functions are traced separately, for each function I
traced 3 times by intel_PT, for each time the sampling period is 1-second.
num means the times the function is invoked in 1-second. (min, max, avg) is
the function duration, the unit is nano-second. 

rcu_needs_cpu():
1) num: 6110min: 3  max: 564avg: 17.0
2) num: 16535   min: 3  max: 683avg: 18.0
3) num: 8815min: 3  max: 394avg: 20.0

rcu_eqs_enter():
1) num: 7956min: 17 max: 656avg: 32.0
2) num: 9170min: 17 max: 1075   avg: 35.0
3) num: 8604min: 17 max: 859avg: 29.0

rcu_eqs_enter_common():
1) num: 14676   min: 15 max: 620avg: 28.0
2) num: 11180   min: 15 max: 795avg: 30.0
3) num: 11484   min: 15 max: 725avg: 29.0

rcu_dynticks_eqs_enter():
1) num: 11035   min: 10 max: 580avg: 17.0
2) num: 15518   min: 10 max: 456avg: 16.0
3) num: 15320   min: 10 max: 454avg: 19.0

rcu_eqs_exit():
1) num: 11080   min: 14 max: 893avg: 23.0
2) num: 13526   min: 14 max: 640avg: 23.0
3) num: 12534   min: 14 max: 630avg: 22.0

rcu_eqs_exit_common():
1) num: 18002   min: 12 max: 553avg: 17.0
2) num: 10570   min: 11 max: 485avg: 17.0
3) num: 13628   min: 11 max: 567avg: 16.0

rcu_dynticks_eqs_exit():
1) num: 11195   min: 11 max: 436avg: 16.0
2) num: 11808   min: 10 max: 506avg: 16.0
3) num: 8132min: 10 max: 546avg: 15.0

==

The other case is CONFIG_NO_HZ_FULL, I also enabled the required config to make
all the functions not empty.

rcu_needs_cpu():
1) num: 8530min: 5  max: 770avg: 13.0
2) num: 9965min: 5  max: 518avg: 12.0
3) num: 12503   min: 5  max: 755avg: 16.0

rcu_prepare_for_idle():
1) num: 11662   min: 5  max: 684avg: 9.0
2) num: 15294   min: 5  max: 676avg: 9.0
3) num: 14332   min: 5  max: 524avg: 9.0

rcu_cleanup_after_idle():
1) num: 13584   min: 4  max: 657avg: 6.0
2) num: 9102min: 4  max: 529avg: 5.0
3) num: 10648   min: 4  max: 471avg: 6.0

rcu_eqs_enter():
1) num: 14222   min: 26 max: 745avg: 54.0
2) num: 12502   min: 26 max: 650avg: 53.0
3) num: 11834   min: 26 max: 863avg: 52.0

rcu_eqs_enter_common():
1) num: 16792   min: 24 max: 973avg: 43.0
2) num: 19755   min: 24 max: 898avg: 45.0
3) num: 8167min: 24 max: 722avg: 42.0

rcu_dynticks_eqs_enter():
1) num: 11605   min: 10 max: 532avg: 14.0
2) num: 10438   min: 9  max: 554avg: 14.0
3) num: 19816   min: 9  max: 701avg: 14.0

do_nocb_deferred_wakeup():
1) num: 15348   min: 1  max: 459avg: 3.0
2) num: 12822   min: 1  max: 564avg: 4.0
3) num: 8272min: 0  max: 458avg: 3.0

rcu_dynticks_task_enter():
1) num: 6358min: 1  max: 268avg: 1.0
2) num: 11128   min: 1  max: 360avg: 1.0
3) num: 20516   min: 1  max: 214avg: 1.0

rcu_eqs_exit():
1) num: 16117   min: 20 max: 782avg: 43.0
2) num: 11042   min: 20 max: 775avg: 47.0
3) num: 16499   min: 20 max: 752avg: 46.0

rcu_eqs_exit_common():
1) num: 12584   min: 17 max: 703avg: 28.0
2) num: 17412   min: 17 max: 759avg: 28.0
3) num: 16733   min: 17 max: 798avg: 29.0

rcu_dynticks_task_exit():
1) num: 11730   min: 1  max: 528avg: 4.0
2) num: 18840   min: 1  max: 581avg: 5.0
3) num: 9815min: 1  max: 381avg: 4.0

rcu_dynticks_eqs_exit():
1) num: 10902   min: 9  max: 557avg: 13.0
2) num: 19474   min: 9  max: 563avg: 13.0
3) num: 11865   min: 9  max: 672avg: 12.0

Please let me know if there is some data not reasonable, I can revisit again.

[PATCH v2 3/5] ACPI / boot: Add number of legacy IRQs to debug output

[Andy Shevchenko]

Sometimes it's useful to have when mp_config_acpi_legacy_irqs() is called.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/kernel/acpi/boot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 6d5b1346268a..0186d3bae610 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1078,7 +1078,7 @@ static void __init mp_config_acpi_legacy_irqs(void)
mp_bus_id_to_type[MP_ISA_BUS] = MP_BUS_ISA;
 #endif
set_bit(MP_ISA_BUS, mp_bus_not_pci);
-   pr_debug("Bus #%d is ISA\n", MP_ISA_BUS);
+   pr_debug("Bus #%d is ISA (nIRQs: %d)\n", MP_ISA_BUS, nr_legacy_irqs());
 
/*
 * Use the default configuration for the IRQs 0-15.  Unless
-- 
2.11.0

[PATCH] [PING] Fix TIOCGPTPEER ioctl definition

[Gleb Fotengauer-Malinovskiy]

This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
because it doesn't copy anything from/to userspace to access the
argument.

Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl")
Signed-off-by: Gleb Fotengauer-Malinovskiy 
Acked-by: Aleksa Sarai 
Acked-by: Arnd Bergmann 
---
 arch/alpha/include/uapi/asm/ioctls.h   | 2 +-
 arch/mips/include/uapi/asm/ioctls.h| 2 +-
 arch/parisc/include/uapi/asm/ioctls.h  | 2 +-
 arch/powerpc/include/uapi/asm/ioctls.h | 2 +-
 arch/sh/include/uapi/asm/ioctls.h  | 2 +-
 arch/sparc/include/uapi/asm/ioctls.h   | 2 +-
 arch/xtensa/include/uapi/asm/ioctls.h  | 2 +-
 include/uapi/asm-generic/ioctls.h  | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/ioctls.h 
b/arch/alpha/include/uapi/asm/ioctls.h
index ff67b8373bf7..1cd7dc7d4870 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -100,7 +100,7 @@
 #define TIOCGPKT   _IOR('T', 0x38, int) /* Get packet mode state */
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
-#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
+#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
 
 #define TIOCSERCONFIG  0x5453
 #define TIOCSERGWILD   0x5454
diff --git a/arch/mips/include/uapi/asm/ioctls.h 
b/arch/mips/include/uapi/asm/ioctls.h
index 68e19b689a00..1609cb0907ac 100644
--- a/arch/mips/include/uapi/asm/ioctls.h
+++ b/arch/mips/include/uapi/asm/ioctls.h
@@ -91,7 +91,7 @@
 #define TIOCGPKT   _IOR('T', 0x38, int) /* Get packet mode state */
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
-#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
+#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
 
 /* I hope the range from 0x5480 on is free ... */
 #define TIOCSCTTY  0x5480  /* become controlling tty */
diff --git a/arch/parisc/include/uapi/asm/ioctls.h 
b/arch/parisc/include/uapi/asm/ioctls.h
index 674c68a5bbd0..d0e3321403be 100644
--- a/arch/parisc/include/uapi/asm/ioctls.h
+++ b/arch/parisc/include/uapi/asm/ioctls.h
@@ -60,7 +60,7 @@
 #define TIOCGPKT   _IOR('T', 0x38, int) /* Get packet mode state */
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
-#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
+#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
 
 #define FIONCLEX   0x5450  /* these numbers need to be adjusted. */
 #define FIOCLEX0x5451
diff --git a/arch/powerpc/include/uapi/asm/ioctls.h 
b/arch/powerpc/include/uapi/asm/ioctls.h
index bfd609a3e928..e3b10469f787 100644
--- a/arch/powerpc/include/uapi/asm/ioctls.h
+++ b/arch/powerpc/include/uapi/asm/ioctls.h
@@ -100,7 +100,7 @@
 #define TIOCGPKT   _IOR('T', 0x38, int) /* Get packet mode state */
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
-#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
+#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
 
 #define TIOCSERCONFIG  0x5453
 #define TIOCSERGWILD   0x5454
diff --git a/arch/sh/include/uapi/asm/ioctls.h 
b/arch/sh/include/uapi/asm/ioctls.h
index eec7901e9e65..787bac9f67da 100644
--- a/arch/sh/include/uapi/asm/ioctls.h
+++ b/arch/sh/include/uapi/asm/ioctls.h
@@ -93,7 +93,7 @@
 #define TIOCGPKT   _IOR('T', 0x38, int) /* Get packet mode state */
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
-#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
+#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
 
 #define TIOCSERCONFIG  _IO('T', 83) /* 0x5453 */
 #define TIOCSERGWILD   _IOR('T', 84,  int) /* 0x5454 */
diff --git a/arch/sparc/include/uapi/asm/ioctls.h 
b/arch/sparc/include/uapi/asm/ioctls.h
index 6d27398632ea..f5df72b93bb2 100644
--- a/arch/sparc/include/uapi/asm/ioctls.h
+++ b/arch/sparc/include/uapi/asm/ioctls.h
@@ -88,7 +88,7 @@
 #define TIOCGPTN   _IOR('t', 134, unsigned int) /* Get Pty Number */
 #define TIOCSPTLCK _IOW('t', 135, int) /* Lock/unlock PTY */
 #define TIOCSIG_IOW('t', 136, int) /* Generate signal on Pty 
slave */
-#define TIOCGPTPEER_IOR('t', 137, int) /* Safely open the slave */
+#define TIOCGPTPEER_IO('t', 137) /* Safely open the slave */
 
 /* Little f */
 #define FIOCLEX_IO('f', 1)
diff --git a/arch/xtensa/include/uapi/asm/ioctls.h 
b/arch/xtensa/include/uapi/asm/ioctls.h
index 98b004e24e85..47d82c09be7b 

[PATCH v2 2/5] ACPI / boot: Correct address space of __acpi_map_table()

[Andy Shevchenko]

Sparse complains about wrong address space used in __acpi_map_table()
and in __acpi_unmap_table().

arch/x86/kernel/acpi/boot.c:127:29: warning: incorrect type in return 
expression (different address spaces)
arch/x86/kernel/acpi/boot.c:127:29:expected char *
arch/x86/kernel/acpi/boot.c:127:29:got void [noderef] *
arch/x86/kernel/acpi/boot.c:135:23: warning: incorrect type in argument 1 
(different address spaces)
arch/x86/kernel/acpi/boot.c:135:23:expected void [noderef] *addr
arch/x86/kernel/acpi/boot.c:135:23:got char *map

Correct address space to be in align of type of returned and passed
parameter.

Signed-off-by: Andy Shevchenko 
---
 arch/arm64/kernel/acpi.c| 4 ++--
 arch/ia64/kernel/acpi.c | 4 ++--
 arch/x86/kernel/acpi/boot.c | 4 ++--
 include/linux/acpi.h| 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index e25c11e727fe..b3162715ed78 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -95,7 +95,7 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
  */
-char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size)
 {
if (!size)
return NULL;
@@ -103,7 +103,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned 
long size)
return early_memremap(phys, size);
 }
 
-void __init __acpi_unmap_table(char *map, unsigned long size)
+void __init __acpi_unmap_table(void __iomem *map, unsigned long size)
 {
if (!map || !size)
return;
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 7508c306aa9e..b9388cc283bc 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -159,12 +159,12 @@ int acpi_request_vector(u32 int_type)
return vector;
 }
 
-char *__init __acpi_map_table(unsigned long phys_addr, unsigned long size)
+void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size)
 {
return __va(phys_addr);
 }
 
-void __init __acpi_unmap_table(char *map, unsigned long size)
+void __init __acpi_unmap_table(void __iomem *map, unsigned long size)
 {
 }
 
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 09ddb3cd627a..6d5b1346268a 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -118,7 +118,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
  * This is just a simple wrapper around early_ioremap(),
  * with sanity checks for phys == 0 and size == 0.
  */
-char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size)
 {
 
if (!phys || !size)
@@ -127,7 +127,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned 
long size)
return early_ioremap(phys, size);
 }
 
-void __init __acpi_unmap_table(char *map, unsigned long size)
+void __init __acpi_unmap_table(void __iomem *map, unsigned long size)
 {
if (!map || !size)
return;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index c749eef1daa1..3848b56fcd83 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -228,8 +228,8 @@ struct acpi_subtable_proc {
int count;
 };
 
-char * __acpi_map_table (unsigned long phys_addr, unsigned long size);
-void __acpi_unmap_table(char *map, unsigned long size);
+void __iomem *__acpi_map_table(unsigned long phys_addr, unsigned long size);
+void __acpi_unmap_table(void __iomem *map, unsigned long size);
 int early_acpi_boot_init(void);
 int acpi_boot_init (void);
 void acpi_boot_table_init (void);
-- 
2.11.0

[Resend, PATCH v2 0/5] ACPI / boot: Few amendments

[Andy Shevchenko]

This series does few amendments to architectural ACPI code related to
boot, in particularly to arch/x86/kernel/acpi/boot.c.

First two patches are amendments to satisfy compiler and static analyzer
(the order is changed from first version which had been applied; in case
 of partial update first patch is already in tree).

Third patch might be useful on platforms when debugging *PIC related
code path to see how many legacy IRQs are registered.

Fourth and fifth patches are preparation for some interesting
implementation of ACPI HW reduced platforms (note, this does not mean
it's against specification, patch 5 actually about following
specification).

Fifth patch might be subject to additional discussions.

In v2:
- fix function declarations in ia64 and arm64 as well (Hanjun)
- add three more patches

Andy Shevchenko (5):
  ACPI / boot: Don't define unused variables
  ACPI / boot: Correct address space of __acpi_map_table()
  ACPI / boot: Add number of legacy IRQs to debug output
  ACPI / boot: Not all platform require acpi_reduced_hw_init()
  ACPI / boot: Don't handle SCI on HW reduced platforms

 arch/arm64/kernel/acpi.c|  4 ++--
 arch/ia64/kernel/acpi.c |  4 ++--
 arch/x86/kernel/acpi/boot.c | 15 +--
 include/linux/acpi.h|  7 +--
 4 files changed, 18 insertions(+), 12 deletions(-)

-- 
2.11.0

Re: [PATCH 2/2] mfd: intel_soc_pmic: Differentiate between Bay and Cherry Trail CRC variants

[Lee Jones]

On Sat, 01 Jul 2017, Hans de Goede wrote:

> Both Bay and Cherry Trail devices may be used together with a Crystal Cove
> PMIC. Each platform has its own variant of the PMIC, which both use the
> same ACPI HID, but they are not 100% compatible.
> 
> This commits makes the intel_soc_pmic_core code check the _HRV of the
> ACPI-firmware-node and selects intel_soc_pmic_config_byt_crc resp.
> intel_soc_pmic_config_cht_crc based on this.
> 
> This fixes the Bay Trail specific ACPI OpRegion code causing problems
> on Cherry Trail devices. Specifically this was causing the external
> microsd slot on a Dell Venue 8 5855 (Cherry Trail version) to not work
> and the eMMC to become unreliable and throw lots of errors.
> 
> Reported-and-tested-by: russianneuromancer 

Real names only please.

What is the name of this reporter/tester?

> Signed-off-by: Hans de Goede 
> ---
>  drivers/mfd/Kconfig   |  4 ++--
>  drivers/mfd/intel_soc_pmic_core.c | 34 --
>  2 files changed, 30 insertions(+), 8 deletions(-)

Code looks okay though:

For my own reference:
  Acked-for-MFD-by: Lee Jones 
  
-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/2] mfd: intel_soc_pmic: Export separate mfd-cell configs for BYT and CHT

[Lee Jones]

On Sat, 01 Jul 2017, Hans de Goede wrote:

> Both Bay and Cherry Trail devices may be used together with a Crystal Cove
> PMIC. Each platform has its own variant of the PMIC, which both use the
> same ACPI HID, but they are not 100% compatible.
> 
> Looking at the android x86 kernel sources where most of the Crystal Cove
> code comes from, it talks about "Valley View", "Bay Trail" and / or BYT
> without ever mentioning Cherry Trail, with the exception of the regulator
> driver. The Asus Zenfone-2 kernel code has 2 regulator drivers, one
> for Crystal Cove and one for what it calls Crystal Cove Plus. The
> Crystal Cove Plus regulator driver is the only one to mention Cherry
> Trail and that driver uses different register addresses then the
> normal (Bay Trail) Crystal Cove regulator driver, showing that at
> least the regulator register addresses are different.
> 
> The GPIO code should work on both, and the PWM code is known to work on
> both and is necessary for backlight control on some Cherry Trail devices.
> 
> Testing has shown that the ACPI OpRegion code otoh is causing problems
> on Cherry Trail devices, which is not surprising as it deals with the
> regulators and those have different register addresses on CHT.
> 
> Specifically the ACPI OpRegion code causes the external microsd slot on
> a Dell Venue 8 5855 (Cherry Trail version) to not work and the eMMC to
> become unreliable and throw lots of errors.
> 
> This commit replaces the single mfd_cell array currently used for Crystal
> Cove with 2 separate arrays, one for the Bay Trail variant and one for
> the Cherry Trail variant, note that the Cherry Trail version of the array
> only contains gpio and pwm cells. The PMIC OpRegion cell is deliberately
> not included and drivers for the other cells in the Bay Trail cell array
> were never upstreamed.
> 
> Reported-and-tested-by: russianneuromancer 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/mfd/intel_soc_pmic_core.c |  2 +-
>  drivers/mfd/intel_soc_pmic_core.h |  3 ++-
>  drivers/mfd/intel_soc_pmic_crc.c  | 27 +++
>  3 files changed, 26 insertions(+), 6 deletions(-)

For my own reference:
  Acked-for-MFD-by: Lee Jones 
  
-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/2] thermal: int340x: constify attribute_group structures.

[Arvind Yadav]

Hi Andy,


On Monday 17 July 2017 04:11 PM, Andy Shevchenko wrote:

On Mon, 2017-07-17 at 16:04 +0530, Arvind Yadav wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.


I hope you did compile test it.

I have compiled it. If we will see  
"int sysfs_create_group(struct kobject *kobj,  const struct 
attribute_group *grp)" and
"void sysfs_remove_group(struct kobject *kobj, const struct 
attribute_group *grp);"
Here, passing parameter attribute_group are constant. So I have 
changed non-const as const.


~arvind



File size before:
text   data bss dec hex 
filename
1687592   02279 8e7 
int3400_thermal.o

File size After adding 'const':
text   data bss dec hex 
filename
1751528   02279 8e7 
int3400_thermal.o

Signed-off-by: Arvind Yadav 
---
  drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c
b/drivers/thermal/int340x_thermal/int3400_thermal.c
index a9ec94e..b2ffbed 100644
--- a/drivers/thermal/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
@@ -104,7 +104,7 @@ static ssize_t current_uuid_store(struct device
*dev,
NULL
  };
  
-static struct attribute_group uuid_attribute_group = {

+static const struct attribute_group uuid_attribute_group = {
.attrs = uuid_attrs,
.name = "uuids"
  };

Re: [PATCH] mfd: intel_soc_pmic_chtwc: Turn Kconfig option into a bool

[Lee Jones]

On Fri, 23 Jun 2017, Hans de Goede wrote:

> The PMIC provides ACPI OpRegions which must be available for other
> drivers' PS0 / PS3 methods early-on as such it must be builtin as the
> Kconfig help text already states.
> 
> Somehow its Kconfig option ended up being a tristate though, this fixes
> this.
> 
> Signed-off-by: Hans de Goede 
> ---
> Note, feel free to squash this in the original commit if you wish

Looks like the original commit is yet to be accepted.

Please ensure it's squashed in and resubmit.

> ---
>  drivers/mfd/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 8533cb46a875..be962d128f31 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -476,7 +476,7 @@ config INTEL_SOC_PMIC_BXTWC
> on these systems.
>  
>  config INTEL_SOC_PMIC_CHTWC
> - tristate "Support for Intel Cherry Trail Whiskey Cove PMIC"
> + bool "Support for Intel Cherry Trail Whiskey Cove PMIC"
>   depends on ACPI && HAS_IOMEM && I2C=y && COMMON_CLK
>   depends on X86 || COMPILE_TEST
>   select MFD_CORE

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

Re: [PATCH v2] kbuild: trivial cleanups on the comments

[Masahiro Yamada]

Hi Cao,


2017-07-16 19:12 GMT+09:00 Cao jin :
> index 61f87a9..f0a4ada 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -85,8 +85,8 @@ TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword 
> $(KBUILD_EXTMOD))/)
>
>  # try-run
>  # Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
> -# Exit code chooses option. "$$TMP" is can be used as temporary file and
> -# is automatically cleaned up.
> +# Exit code chooses option. "$$TMP" serves as temporary file and is
> +# automatically cleaned up.


I am not a native speaker, but I think "file" is countable.

Maybe, is "as a temporary file" even better?




> diff --git a/scripts/basic/Makefile b/scripts/basic/Makefile
> index ec10d93..edd983f 100644
> --- a/scripts/basic/Makefile
> +++ b/scripts/basic/Makefile
> @@ -1,5 +1,5 @@
>  ###
> -# Makefile.basic lists the most basic programs used during the build process.
> +# scripts/basic/Makefile lists the most basic programs used during the build 
> process.

This change is correct, but this line will exceed 80 cols limit.

Wrap the lines, or reword like "This Makefile lists ..."

Either will do.



>  # The programs listed herein are what are needed to do the basic stuff,
>  # such as fix file dependencies.
>  # This initial step is needed to avoid files to be recompiled






-- 
Best Regards
Masahiro Yamada

[PATCH] sphinx-pre-install: check for the need of graphviz-gd

[Mauro Carvalho Chehab]

On newer versions of graphviz, it is needed to install a separate
package for PDF support.

Signed-off-by: Mauro Carvalho Chehab 
---

This patch depends on a previous patch series I sent yesterday. This,
together with the other pending patches are available at:


https://git.linuxtv.org/mchehab/experimental.git/log/?h=sphinx_install_v2


 scripts/sphinx-pre-install | 9 +
 1 file changed, 9 insertions(+)

diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index 230d9cc7ee1d..817241c674d3 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -285,6 +285,10 @@ sub give_redhat_hints()
"xelatex"   => "texlive-xetex-bin",
);
 
+   my @fedora26_opt_pkgs = (
+   "graphviz-gd",  # Fedora 26: needed for PDF support
+   );
+
my @fedora_tex_pkgs = (
"texlive-collection-fontsrecommended",
"texlive-collection-latex",
@@ -293,6 +297,11 @@ sub give_redhat_hints()
"dejavu-sans-mono-fonts",
);
 
+   my $release;
+
+   $release = $1 if ($system_release =~ /Fedora\s+release\s+(\d+)/);
+
+   check_rpm_missing(\@fedora26_opt_pkgs, 1) if ($pdf && $release >= 26);
check_rpm_missing(\@fedora_tex_pkgs, 1) if ($pdf);
check_missing_tex(1) if ($pdf);
check_missing(\%map);
-- 
2.13.3

[PATCH v2] Input: adxl34x - fix gcc-7 -Wint-in-bool-context warning

[Arnd Bergmann]

FIFO_MODE is an macro expression with a '<<' operator, which
gcc points out could be misread as a '<':

drivers/input/misc/adxl34x.c: In function 'adxl34x_probe':
drivers/input/misc/adxl34x.c:799:36: error: '<<' in boolean context, did you 
mean '<' ? [-Werror=int-in-bool-context]

This converts the test to an explicit comparison with FIFO_BYPASS,
making it clearer to gcc and the reader what is intended.

Fixes: e27c729219ad ("Input: add driver for ADXL345/346 Digital Accelerometers")
Signed-off-by: Arnd Bergmann 
---
v2: use FIFO_BYPASS instead of 0

 drivers/input/misc/adxl34x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/adxl34x.c b/drivers/input/misc/adxl34x.c
index 2b2d02f408bb..a3e79bf5a04b 100644
--- a/drivers/input/misc/adxl34x.c
+++ b/drivers/input/misc/adxl34x.c
@@ -796,7 +796,7 @@ struct adxl34x *adxl34x_probe(struct device *dev, int irq,
 
if (pdata->watermark) {
ac->int_mask |= WATERMARK;
-   if (!FIFO_MODE(pdata->fifo_mode))
+   if (FIFO_MODE(pdata->fifo_mode) == FIFO_BYPASS)
ac->pdata.fifo_mode |= FIFO_STREAM;
} else {
ac->int_mask |= DATA_READY;
-- 
2.9.0

Re: [PATCH] mfd: max8925-i2c: remove unnecessary static in max8925_probe()

[Lee Jones]

On Tue, 04 Jul 2017, Gustavo A. R. Silva wrote:

> Remove unnecessary static on local variable _chip_.
> Such variable is initialized before being used,
> on every execution path throughout the function.
> The static has no benefit and, removing it reduces
> the code size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> 
> @bad exists@
> position p;
> identifier x;
> type T;
> @@
> 
> static T x@p;
> ...
> x = <+...x...+>
> 
> @@
> identifier x;
> expression e;
> type T;
> position p != bad.p;
> @@
> 
> -static
>  T x@p;
>  ... when != x
>  when strict
> ?x = e;
> 
> In the following log you can see the difference in the code size and,
> also a significant difference in the bss segment. This log is the output
> of the size command, before and after the code change:
> 
> before:
>text  data bss dec hex filename
>4188  1336 12856521614 drivers/mfd/max8925-i2c.o
> 
> after:
>text  data bss dec hex filename
>4135  1280  6454791567 drivers/mfd/max8925-i2c.o
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/mfd/max8925-i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

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

[PATCH 4/7] phy: qcom-qmp: Handle unavailable registers

[Varadarajan Narayanan]

In some implementations of the QMP phy, some registers might not
be present. Provide a way identify such registers and not access
those registers.

Signed-off-by: Varadarajan Narayanan 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 97020ec..000ad1c 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -187,6 +187,8 @@ struct qmp_phy_init_tbl {
.in_layout = 1, \
}
 
+#define QPHY_REG_INVAL 0xu
+
 /* set of registers with offsets different per-PHY */
 enum qphy_reg_layout {
/* Common block control registers */
@@ -676,15 +678,18 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
qphy_setbits(serdes, cfg->regs[QPHY_COM_START_CONTROL],
 SERDES_START | PCS_START);
 
-   status = serdes + cfg->regs[QPHY_COM_PCS_READY_STATUS];
-   mask = cfg->mask_com_pcs_ready;
-
-   ret = readl_poll_timeout(status, val, (val & mask), 10,
-PHY_INIT_COMPLETE_TIMEOUT);
-   if (ret) {
-   dev_err(qmp->dev,
-   "phy common block init timed-out\n");
-   goto err_com_init;
+   if (cfg->regs[QPHY_COM_PCS_READY_STATUS] != QPHY_REG_INVAL) {
+   status = serdes + cfg->regs[QPHY_COM_PCS_READY_STATUS];
+   mask = cfg->mask_com_pcs_ready;
+
+   ret = readl_poll_timeout(status, val, (val & mask), 10,
+PHY_INIT_COMPLETE_TIMEOUT);
+   if (ret) {
+   dev_err(qmp->dev,
+   "%s: phy common block init timed-out\n",
+   __func__);
+   goto err_com_init;
+   }
}
}
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 00/15] perf tools: Fix attr tests

[Jiri Olsa]

On Mon, Jul 03, 2017 at 04:50:15PM +0200, Jiri Olsa wrote:
> hi,
> attr tests have been broken for some time now. Updating
> the data files plus some other processing fixes.
> 
> It's also available in here:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/attr_test

hi,
just noticed that this got removed from your branch.. anything wrong with that?

thanks,
jirka

> 
> thanks,
> jirka
> ---
>  tools/perf/perf.h|  
> 1 +
>  tools/perf/tests/attr.c  | 
> 12 +++-
>  tools/perf/tests/attr.py | 
> 50 +-
>  tools/perf/tests/attr/base-record|  
> 8 
>  tools/perf/tests/attr/base-stat  |  
> 4 ++--
>  tools/perf/tests/attr/test-record-C0 |  
> 1 +
>  tools/perf/tests/attr/test-record-basic  |  
> 1 +
>  tools/perf/tests/attr/test-record-branch-any |  
> 2 +-
>  tools/perf/tests/attr/test-record-branch-filter-any  |  
> 2 +-
>  tools/perf/tests/attr/test-record-branch-filter-any_call |  
> 2 +-
>  tools/perf/tests/attr/test-record-branch-filter-any_ret  |  
> 2 +-
>  tools/perf/tests/attr/test-record-branch-filter-hv   |  
> 2 +-
>  tools/perf/tests/attr/test-record-branch-filter-ind_call |  
> 2 +-
>  tools/perf/tests/attr/test-record-branch-filter-k|  
> 2 +-
>  tools/perf/tests/attr/test-record-branch-filter-u|  
> 2 +-
>  tools/perf/tests/attr/test-record-count  |  
> 1 +
>  tools/perf/tests/attr/test-record-data   |  
> 3 +--
>  tools/perf/tests/attr/test-record-freq   |  
> 1 +
>  tools/perf/tests/attr/test-record-graph-default  |  
> 1 +
>  tools/perf/tests/attr/test-record-graph-dwarf|  
> 4 +++-
>  tools/perf/tests/attr/test-record-graph-fp   |  
> 1 +
>  tools/perf/tests/attr/test-record-group  |  
> 2 ++
>  tools/perf/tests/attr/test-record-group-sampling |  
> 3 ++-
>  tools/perf/tests/attr/test-record-group1 |  
> 2 ++
>  tools/perf/tests/attr/{test-record-no-delay => test-record-no-buffering} |  
> 4 ++--
>  tools/perf/tests/attr/test-record-no-inherit |  
> 1 +
>  tools/perf/tests/attr/test-record-no-samples |  
> 1 +
>  tools/perf/tests/attr/test-record-period |  
> 1 +
>  tools/perf/tests/attr/test-record-raw|  
> 2 +-
>  tools/perf/tests/attr/test-stat-C0   |  
> 4 ++--
>  tools/perf/tests/attr/test-stat-default  |  
> 2 ++
>  tools/perf/tests/attr/test-stat-detailed-1   |  
> 2 ++
>  tools/perf/tests/attr/test-stat-detailed-2   |  
> 3 +++
>  tools/perf/tests/attr/test-stat-detailed-3   |  
> 5 +
>  tools/perf/util/evsel.c  |  
> 8 +++-
>  35 files changed, 98 insertions(+), 46 deletions(-)

RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups

[Liang, Kan]

> 
> On Mon, 17 Jul 2017, Liang, Kan wrote:
> > There are three proposed patches so far.
> > Patch 1: The patch as above which speed up the hrtimer.
> > Patch 2: Thomas's first proposal.
> > https://patchwork.kernel.org/patch/9803033/
> > https://patchwork.kernel.org/patch/9805903/
> > Patch 3: my original proposal which increase the NMI watchdog timeout
> > by 3X https://patchwork.kernel.org/patch/9802053/
> >
> > According to our test, only patch 3 works well.
> > The other two patches will hang the system eventually.
> > For patch 1, the system hang after running our test case for ~1 hour.
> > For patch 2, the system hang in running the overnight test.
> > There is no error message shown when the system hang. So I don't know
> > the root cause yet.
> 
> That doesn't make sense. What's the exact test procedure?

I don't know the exact test procedure. The test case is from our customer.
I only know that the test case makes calls into the x11 libs.

> 
> > BTW: We set 1 to watchdog_thresh when we did the test.
> > It's believed that can speed up the failure.
> 
> Believe is not really a technical measure
> 

1 is a valid value for watchdog_thresh.
It was set through the standard proc interface.
/proc/sys/kernel/watchdog_thresh
It should not impacts the final test result.

Thanks,
Kan

[PATCH v2] staging: iio: adc: add missing of_node references to iio_dev

[Hari Prasath]

Adding missing indio_dev->dev.of_node references to allow iio consumers
to access the device channels.

Signed-off-by: Hari Prasath 
---
v2: Wrong from email ID in first version of patch

---
 drivers/staging/iio/adc/ad7192.c | 1 +
 drivers/staging/iio/adc/ad7780.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index d11c6de..78308a5 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -668,6 +668,7 @@ static int ad7192_probe(struct spi_device *spi)
spi_set_drvdata(spi, indio_dev);
st->devid = spi_get_device_id(spi)->driver_data;
indio_dev->dev.parent = >dev;
+   indio_dev->dev.of_node = spi->dev.of_node;
indio_dev->name = spi_get_device_id(spi)->name;
indio_dev->modes = INDIO_DIRECT_MODE;
 
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index dec3ba6..e38d2ab9 100644
--- a/drivers/staging/iio/adc/ad7780.c
+++ b/drivers/staging/iio/adc/ad7780.c
@@ -195,6 +195,7 @@ static int ad7780_probe(struct spi_device *spi)
spi_set_drvdata(spi, indio_dev);
 
indio_dev->dev.parent = >dev;
+   indio_dev->dev.of_node = spi->dev.of_node;
indio_dev->name = spi_get_device_id(spi)->name;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->channels = >chip_info->channel;
-- 
2.10.0.GIT

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

[Sricharan R]

Hi,

On 7/17/2017 5:16 PM, Sricharan R wrote:
> Hi,
> 
> On 7/15/2017 1:09 AM, Rob Clark wrote:
>> On Fri, Jul 14, 2017 at 3:36 PM, Will Deacon  wrote:
>>> On Fri, Jul 14, 2017 at 03:34:42PM -0400, Rob Clark wrote:
 On Fri, Jul 14, 2017 at 3:01 PM, Will Deacon  wrote:
> On Fri, Jul 14, 2017 at 02:25:45PM -0400, Rob Clark wrote:
>> On Fri, Jul 14, 2017 at 2:06 PM, Will Deacon  wrote:
>>> On Fri, Jul 14, 2017 at 01:42:13PM -0400, Rob Clark wrote:
 On Fri, Jul 14, 2017 at 1:07 PM, Will Deacon  
 wrote:
> On Thu, Jul 13, 2017 at 10:55:10AM -0400, Rob Clark wrote:
>> On Thu, Jul 13, 2017 at 9:53 AM, Sricharan R 
>>  wrote:
>>> Hi,
>>>
>>> On 7/13/2017 5:20 PM, Rob Clark wrote:
 On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R 
  wrote:
> Hi Vivek,
>
> On 7/13/2017 10:43 AM, Vivek Gautam wrote:
>> Hi Stephen,
>>
>>
>> On 07/13/2017 04:24 AM, Stephen Boyd wrote:
>>> On 07/06, Vivek Gautam wrote:
 @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct 
 iommu_domain *domain, unsigned long iova,
   static size_t arm_smmu_unmap(struct iommu_domain *domain, 
 unsigned long iova,
size_t size)
   {
 -struct io_pgtable_ops *ops = 
 to_smmu_domain(domain)->pgtbl_ops;
 +struct arm_smmu_domain *smmu_domain = 
 to_smmu_domain(domain);
 +struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
 +size_t ret;
 if (!ops)
   return 0;
   -return ops->unmap(ops, iova, size);
 +pm_runtime_get_sync(smmu_domain->smmu->dev);
>>> Can these map/unmap ops be called from an atomic context? I seem
>>> to recall that being a problem before.
>>
>> That's something which was dropped in the following patch merged 
>> in master:
>> 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock
>>
>> Looks like we don't  need locks here anymore?
>
>  Apart from the locking, wonder why a explicit pm_runtime is 
> needed
>  from unmap. Somehow looks like some path in the master using that
>  should have enabled the pm ?
>

 Yes, there are a bunch of scenarios where unmap can happen with
 disabled master (but not in atomic context).  On the gpu side we
 opportunistically keep a buffer mapping until the buffer is freed
 (which can happen after gpu is disabled).  Likewise, v4l2 won't 
 unmap
 an exported dmabuf while some other driver holds a reference to it
 (which can be dropped when the v4l2 device is suspended).

 Since unmap triggers tbl flush which touches iommu regs, the iommu
 driver *definitely* needs a pm_runtime_get_sync().
>>>
>>>  Ok, with that being the case, there are two things here,
>>>
>>>  1) If the device links are still intact at these places where 
>>> unmap is called,
>>> then pm_runtime from the master would setup the all the clocks. 
>>> That would
>>> avoid reintroducing the locking indirectly here.
>>>
>>>  2) If not, then doing it here is the only way. But for both cases, 
>>> since
>>> the unmap can be called from atomic context, resume handler 
>>> here should
>>> avoid doing clk_prepare_enable , instead move the clk_prepare 
>>> to the init.
>>>
>>
>> I do kinda like the approach Marek suggested.. of deferring the tlb
>> flush until resume.  I'm wondering if we could combine that with
>> putting the mmu in a stalled state when we suspend (and not resume 
>> the
>> mmu until after the pending tlb flush)?
>
> I'm not sure that a stalled state is what we're after here, because 
> we need
> to take care to prevent any table walks if we've freed the underlying 
> pages.
> What we could try to do is disable the SMMU (put into global bypass) 
> and
> invalidate the TLB when performing a suspend operation, then we just 
> ignore
> invalidation whilst the clocks are stopped and, on resume, enable the 
> SMMU
> again.

 wouldn't stalled just block any memory transactions by device(s) using
 the context 

Re: [PATCH v1] staging: rts5208: Change fixed function names with "%s: ", __func__

[Greg KH]

On Fri, Jul 14, 2017 at 07:38:43PM +0530, Gaurav Pathak wrote:
> staging: rts5208: Refactored code to avoid few defects.

That's the subject line, why repeat it here?

Please put a "real" description of the patch here.

> 
> Signed-off-by: Gaurav Pathak 
> ---
> Hi, Gaurav hope this text appaers in the email, and i put it at the right 
> place in patch.

You did, but why are you writing to yourself?

thanks,

greg k-h

[PATCH net-next 2/5] virtio-net: pack headroom into ctx for mergeable buffer

[Jason Wang]

Pack headroom into ctx, then during XDP set, we could know the size of
headroom and copy if needed. This is required for avoiding reset on
XDP.

Signed-off-by: Jason Wang 
---
 drivers/net/virtio_net.c | 29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 1f8c15c..8fae9a8 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -270,6 +270,23 @@ static void skb_xmit_done(struct virtqueue *vq)
netif_wake_subqueue(vi->dev, vq2txq(vq));
 }
 
+#define MRG_CTX_HEADER_SHIFT 22
+static void *mergeable_len_to_ctx(unsigned int truesize,
+ unsigned int headroom)
+{
+   return (void *)(unsigned long)((headroom << MRG_CTX_HEADER_SHIFT) | 
truesize);
+}
+
+static unsigned int mergeable_ctx_to_headroom(void *mrg_ctx)
+{
+   return (unsigned long)mrg_ctx >> MRG_CTX_HEADER_SHIFT;
+}
+
+static unsigned int mergeable_ctx_to_truesize(void *mrg_ctx)
+{
+   return (unsigned long)mrg_ctx & ((1 << MRG_CTX_HEADER_SHIFT) - 1);
+}
+
 /* Called from bottom half context */
 static struct sk_buff *page_to_skb(struct virtnet_info *vi,
   struct receive_queue *rq,
@@ -639,13 +656,14 @@ static struct sk_buff *receive_mergeable(struct 
net_device *dev,
}
rcu_read_unlock();
 
-   if (unlikely(len > (unsigned long)ctx)) {
+   truesize = mergeable_ctx_to_truesize(ctx);
+   if (unlikely(len > truesize)) {
pr_debug("%s: rx error: len %u exceeds truesize %lu\n",
 dev->name, len, (unsigned long)ctx);
dev->stats.rx_length_errors++;
goto err_skb;
}
-   truesize = (unsigned long)ctx;
+
head_skb = page_to_skb(vi, rq, page, offset, len, truesize);
curr_skb = head_skb;
 
@@ -665,13 +683,14 @@ static struct sk_buff *receive_mergeable(struct 
net_device *dev,
}
 
page = virt_to_head_page(buf);
-   if (unlikely(len > (unsigned long)ctx)) {
+
+   truesize = mergeable_ctx_to_truesize(ctx);
+   if (unlikely(len > truesize)) {
pr_debug("%s: rx error: len %u exceeds truesize %lu\n",
 dev->name, len, (unsigned long)ctx);
dev->stats.rx_length_errors++;
goto err_skb;
}
-   truesize = (unsigned long)ctx;
 
num_skb_frags = skb_shinfo(curr_skb)->nr_frags;
if (unlikely(num_skb_frags == MAX_SKB_FRAGS)) {
@@ -889,7 +908,7 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi,
 
buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset;
buf += headroom; /* advance address leaving hole at front of pkt */
-   ctx = (void *)(unsigned long)len;
+   ctx = mergeable_len_to_ctx(len, headroom);
get_page(alloc_frag->page);
alloc_frag->offset += len + headroom;
hole = alloc_frag->size - alloc_frag->offset;
-- 
2.7.4

Re: [PATCH] perf probe: Fix build failure for get_target_map()

[Arnaldo Carvalho de Melo]

Em Mon, Jul 17, 2017 at 04:02:22PM +0530, Ravi Bangoria escreveu:
> Commit 801bc8193463 ("perf probe: Allow placing uprobes in
> alternate namespaces.") is causing a build failure on powerpc:
> 
>   error: incompatible type for argument 2 of 'get_target_map'
>   map = get_target_map(pev->target, pev->uprobes);
> ^~~
> 
> Fix it by changing parameters of get_target_map().

Thanks, since this hasn't made it to Ingo I'll fold this into the patch
where the problem was introduced, adding credits to you, leaving a Link
to this message, so that we don't lose bisection in this area on
powerpc.

- Arnaldo
 
> Fixes: 801bc8193463 ("perf probe: Allow placing uprobes in alternate 
> namespaces.")
> Signed-off-by: Ravi Bangoria 
> ---
>  tools/perf/arch/powerpc/util/sym-handling.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
> b/tools/perf/arch/powerpc/util/sym-handling.c
> index bf9a259..9c4e23d 100644
> --- a/tools/perf/arch/powerpc/util/sym-handling.c
> +++ b/tools/perf/arch/powerpc/util/sym-handling.c
> @@ -126,7 +126,7 @@ void arch__post_process_probe_trace_events(struct 
> perf_probe_event *pev,
>   struct rb_node *tmp;
>   int i = 0;
>  
> - map = get_target_map(pev->target, pev->uprobes);
> + map = get_target_map(pev->target, pev->nsi, pev->uprobes);
>   if (!map || map__load(map) < 0)
>   return;
>  
> -- 
> 2.1.4

Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings

[kbuild test robot]

Hi Chen-Yu,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc1]
[cannot apply to robh/for-next clk/clk-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chen-Yu-Tsai/ARM-sun8i-a83t-Add-support-for-MMC-controllers/20170715-071008
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

>> ERROR: "sunxi_ccu_set_mmc_timing_mode" [drivers/mmc/host/sunxi-mmc.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] PCI: dwc: designware: make dw_pcie_prog_*_atu_unroll() static

[Carlos Palminha]

Helper functions dw_pcie_prog_*_atu_unroll don't need to be in global scope,
so make it static.

Cleans up sparse warnings:
- symbol 'dw_pcie_prog_outbound_atu_unroll' was not declared. Should it be 
static?
- symbol 'dw_pcie_prog_inbound_atu_unroll' was not declared. Should it be 
static?

Signed-off-by: Carlos Palminha 
---
Patch made against linux-next tree, tag next-20170714

 drivers/pci/dwc/pcie-designware.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 0e03af279259..48d6d0712ea8 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -107,7 +107,7 @@ static void dw_pcie_writel_ob_unroll(struct dw_pcie *pci, 
u32 index, u32 reg,
dw_pcie_writel_dbi(pci, offset + reg, val);
 }

-void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index, int type,
+static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index, 
int type,
  u64 cpu_addr, u64 pci_addr, u32 size)
 {
u32 retries, val;
@@ -200,7 +200,7 @@ static void dw_pcie_writel_ib_unroll(struct dw_pcie *pci, 
u32 index, u32 reg,
dw_pcie_writel_dbi(pci, offset + reg, val);
 }

-int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index, int bar,
+static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index, int 
bar,
u64 cpu_addr, enum dw_pcie_as_type as_type)
 {
int type;
--
2.11.0

[PATCH 05/15] kernel: convert task_struct.stack_refcount from atomic_t to refcount_t

[Elena Reshetova]

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Suggested-by: Kees Cook 
Reviewed-by: David Windsor 
Reviewed-by: Hans Liljestrand 
Signed-off-by: Elena Reshetova 
---
 include/linux/init_task.h| 3 ++-
 include/linux/sched.h| 2 +-
 include/linux/sched/task_stack.h | 2 +-
 kernel/fork.c| 6 +++---
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 7ba3fca..8be9369 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -214,7 +215,7 @@ extern struct cred init_cred;
 #ifdef CONFIG_THREAD_INFO_IN_TASK
 # define INIT_TASK_TI(tsk) \
.thread_info = INIT_THREAD_INFO(tsk),   \
-   .stack_refcount = ATOMIC_INIT(1),
+   .stack_refcount = REFCOUNT_INIT(1),
 #else
 # define INIT_TASK_TI(tsk)
 #endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 9380e44..bd49917 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1078,7 +1078,7 @@ struct task_struct {
 #endif
 #ifdef CONFIG_THREAD_INFO_IN_TASK
/* A live task holds one reference: */
-   atomic_tstack_refcount;
+   refcount_t  stack_refcount;
 #endif
 #ifdef CONFIG_LIVEPATCH
int patch_state;
diff --git a/include/linux/sched/task_stack.h b/include/linux/sched/task_stack.h
index df6ea66..aab3809 100644
--- a/include/linux/sched/task_stack.h
+++ b/include/linux/sched/task_stack.h
@@ -60,7 +60,7 @@ static inline unsigned long *end_of_stack(struct task_struct 
*p)
 #ifdef CONFIG_THREAD_INFO_IN_TASK
 static inline void *try_get_task_stack(struct task_struct *tsk)
 {
-   return atomic_inc_not_zero(>stack_refcount) ?
+   return refcount_inc_not_zero(>stack_refcount) ?
task_stack_page(tsk) : NULL;
 }
 
diff --git a/kernel/fork.c b/kernel/fork.c
index cfd8a42..6fd6be0 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -354,7 +354,7 @@ static void release_task_stack(struct task_struct *tsk)
 #ifdef CONFIG_THREAD_INFO_IN_TASK
 void put_task_stack(struct task_struct *tsk)
 {
-   if (atomic_dec_and_test(>stack_refcount))
+   if (refcount_dec_and_test(>stack_refcount))
release_task_stack(tsk);
 }
 #endif
@@ -372,7 +372,7 @@ void free_task(struct task_struct *tsk)
 * If the task had a separate stack allocation, it should be gone
 * by now.
 */
-   WARN_ON_ONCE(atomic_read(>stack_refcount) != 0);
+   WARN_ON_ONCE(refcount_read(>stack_refcount) != 0);
 #endif
rt_mutex_debug_task_free(tsk);
ftrace_graph_exit_task(tsk);
@@ -532,7 +532,7 @@ static struct task_struct *dup_task_struct(struct 
task_struct *orig, int node)
tsk->stack_vm_area = stack_vm_area;
 #endif
 #ifdef CONFIG_THREAD_INFO_IN_TASK
-   atomic_set(>stack_refcount, 1);
+   refcount_set(>stack_refcount, 1);
 #endif
 
if (err)
-- 
2.7.4

[RFC PATCH] ARM: dts: stm32: change pinctrl bindings definition

[Alexandre TORGUE]

blabla

Signed-off-by: Alexandre TORGUE 

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index a8113dc..4bb2b4f 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -47,7 +47,7 @@
 
 #include "skeleton.dtsi"
 #include "armv7-m.dtsi"
-#include 
+#include 
 #include 
 #include 
 
@@ -687,35 +687,35 @@
 
usart1_pins_a: usart1@0 {
pins1 {
-   pinmux = ;
+   pinmux = ; /* 
USART1_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
-   pinmux = 
;
+   pinmux = ; 
/* USART1_RX */
bias-disable;
};
};
 
usart3_pins_a: usart3@0 {
pins1 {
-   pinmux = 
;
+   pinmux = ; 
/* USART3_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
-   pinmux = 
;
+   pinmux = ; 
/* USART3_RX */
bias-disable;
};
};
 
usbotg_fs_pins_a: usbotg_fs@0 {
pins {
-   pinmux = 
,
-
,
-
;
+   pinmux = , 
/* OTG_FS_ID */
+, 
/* OTG_FS_DM */
+; 
/* OTG_FS_DP */
bias-disable;
drive-push-pull;
slew-rate = <2>;
@@ -724,9 +724,9 @@
 
usbotg_fs_pins_b: usbotg_fs@1 {
pins {
-   pinmux = 
,
-
,
-
;
+   pinmux = , 
/* OTG_HS_ID */
+, 
/* OTG_HS_DM */
+; 
/* OTG_HS_DP */
bias-disable;
drive-push-pull;
slew-rate = <2>;
@@ -735,18 +735,18 @@
 
usbotg_hs_pins_a: usbotg_hs@0 {
pins {
-   pinmux = 
,
-
,
-
,
-
,
-
,
-
,
-
,
-
,
-
,
-
,
-
,
-
;
+   pinmux = , 
/* OTG_HS_ULPI_NXT*/
+, 
/* OTG_HS_ULPI_DIR */
+, 
/* OTG_HS_ULPI_STP */
+, 
/* OTG_HS_ULPI_CK */
+, 
/* OTG_HS_ULPI_D0 */
+, 
/* OTG_HS_ULPI_D1 */
+, 
/* OTG_HS_ULPI_D2 */
+, 
/* OTG_HS_ULPI_D3 */
+, 
/* OTG_HS_ULPI_D4 */
+ 

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

[Gerd Hoffmann]

  Hi,

> No need of flag here. If vGPU driver is not loaded in the guest,
> there
> is no surface being managed by vGPU, in that case this size will be
> zero.

Ok, we certainly have the same situation with intel.  When the guest
driver is not loaded (yet) there is no valid surface.

We should cleanly define what the ioctl should do in that case, so all
drivers behave the same way.

I'd suggest that all fields defining the surface (drm_format, width,
height, stride, size) should be set to zero in that case.

cheers,
  Gerd

[RESEND PATCH v1] i2c: mediatek: send i2c master code at 400k

[Jun Gao]

From: Jun Gao 

The speed of sending i2c master code in high-speed mode depends on
source clock, clock-div and TIMING register. The source clock and
clock-div of different SoC are not all the same. In order to send
i2c master code at 400k in high-speed mode, a appropriate value
should be set to TIMING register for a certain source clock and
clock-div.

Signed-off-by: Jun Gao 
---
 drivers/i2c/busses/i2c-mt65xx.c | 65 +
 1 file changed, 46 insertions(+), 19 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 45d6171..9bedf0b 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -50,7 +50,6 @@
 #define I2C_FS_START_CON   0x1800
 #define I2C_TIME_CLR_VALUE 0x
 #define I2C_TIME_DEFAULT_VALUE 0x0003
-#define I2C_FS_TIME_INIT_VALUE 0x1303
 #define I2C_WRRD_TRANAC_VALUE  0x0002
 #define I2C_RD_TRANAC_VALUE0x0001
 
@@ -154,6 +153,7 @@ struct mtk_i2c {
bool use_push_pull; /* IO config push-pull mode */
 
u16 irq_stat;   /* interrupt status */
+   unsigned int clk_src_div;
unsigned int speed_hz;  /* The speed in transfer */
enum mtk_trans_op op;
u16 timing_reg;
@@ -285,23 +285,20 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
  * less than or equal to i2c->speed_hz. The calculation try to get
  * sample_cnt and step_cn
  */
-static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk,
-unsigned int clock_div)
+static int mtk_i2c_calculate_speed(struct mtk_i2c *i2c, unsigned int clk_src,
+  unsigned int target_speed,
+  unsigned int *timing_step_cnt,
+  unsigned int *timing_sample_cnt)
 {
-   unsigned int clk_src;
unsigned int step_cnt;
unsigned int sample_cnt;
unsigned int max_step_cnt;
-   unsigned int target_speed;
unsigned int base_sample_cnt = MAX_SAMPLE_CNT_DIV;
unsigned int base_step_cnt;
unsigned int opt_div;
unsigned int best_mul;
unsigned int cnt_mul;
 
-   clk_src = parent_clk / clock_div;
-   target_speed = i2c->speed_hz;
-
if (target_speed > MAX_HS_MODE_SPEED)
target_speed = MAX_HS_MODE_SPEED;
 
@@ -347,16 +344,48 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, 
unsigned int parent_clk,
return -EINVAL;
}
 
-   step_cnt--;
-   sample_cnt--;
+   *timing_step_cnt = step_cnt - 1;
+   *timing_sample_cnt = sample_cnt - 1;
+
+   return 0;
+}
+
+static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk)
+{
+   unsigned int clk_src;
+   unsigned int step_cnt;
+   unsigned int sample_cnt;
+   unsigned int target_speed;
+   int ret;
+
+   clk_src = parent_clk / i2c->clk_src_div;
+   target_speed = i2c->speed_hz;
 
if (target_speed > MAX_FS_MODE_SPEED) {
+   /* Set master code speed register */
+   ret = mtk_i2c_calculate_speed(i2c, clk_src, MAX_FS_MODE_SPEED,
+ _cnt, _cnt);
+   if (ret < 0)
+   return ret;
+
+   i2c->timing_reg = (sample_cnt << 8) | step_cnt;
+
/* Set the high speed mode register */
-   i2c->timing_reg = I2C_FS_TIME_INIT_VALUE;
+   ret = mtk_i2c_calculate_speed(i2c, clk_src, target_speed,
+ _cnt, _cnt);
+   if (ret < 0)
+   return ret;
+
i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE |
(sample_cnt << 12) | (step_cnt << 8);
} else {
-   i2c->timing_reg = (sample_cnt << 8) | (step_cnt << 0);
+   ret = mtk_i2c_calculate_speed(i2c, clk_src, target_speed,
+ _cnt, _cnt);
+   if (ret < 0)
+   return ret;
+
+   i2c->timing_reg = (sample_cnt << 8) | step_cnt;
+
/* Disable the high speed transaction */
i2c->high_speed_reg = I2C_TIME_CLR_VALUE;
}
@@ -647,8 +676,7 @@ static u32 mtk_i2c_functionality(struct i2c_adapter *adap)
.functionality = mtk_i2c_functionality,
 };
 
-static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c,
-   unsigned int *clk_src_div)
+static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c)
 {
int ret;
 
@@ -656,11 +684,11 @@ static int mtk_i2c_parse_dt(struct device_node *np, 
struct mtk_i2c *i2c,
if (ret < 0)
i2c->speed_hz = I2C_DEFAULT_SPEED;
 
-   ret = of_property_read_u32(np, "clock-div", clk_src_div);
+   ret = 

[RFC PATCH] ARM: dts: stm32: change pinctrl bindings definition

[Alexandre TORGUE]

Initially each pin was declared in "include/dt-bindings/stm32f429-pinfunc.h"
and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX).
Since this approach was approved, the number of supported MCU has
increased (STM32F429/STM32F469/STM32f746/STM32H743). To avoid to add a new
file in "include/dt-bindings" each time a new STM32 SOC arrives I propose
a new approach which consist to use a macro to define pin muxing in device
tree. All STM32 DT will use the common macro to define pinmux. Furthermore, it
will make easy maintenance and integration of new SOC.

To check that patch generate same dtb than befrore I used dtc binary to 
(re)generate dts files
(before and after apply the series).
Example on stm32f469-disco:

./scripts/dtc/dtc -I dtb -O dts -o stm32f469-disco-after.dts
stm32f469-disco-after.dtb

./scripts/dtc/dtc -I dtb -O dts -o stm32f469-disco-before.dts
stm32f469-disco-before.dtb

Then diff -u stm32f469-disco-before.dts stm32f469-disco-after.dts

Regards
Alex

Alexandre TORGUE (1):
  ARM: dts: stm32: change pinctrl bindings definition

 arch/arm/boot/dts/stm32f429.dtsi|  176 ++--
 include/dt-bindings/pinctrl/stm32-pinfunc.h |   61 ++
 include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1239 ---
 3 files changed, 149 insertions(+), 1327 deletions(-)
 create mode 100644 include/dt-bindings/pinctrl/stm32-pinfunc.h
 delete mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

-- 
1.9.1

Re: Droid 4 boot failure due to 422580c3cea7 (mm/oom_kill.c: add tracepoints for oom reaper-related events)

[Sebastian Reichel]

[dropping people from Cc]

Hi,

On Mon, Jul 17, 2017 at 03:19:28AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel  [170717 02:52]:
> > On Sun, Jul 16, 2017 at 10:59:42PM -0700, Tony Lindgren wrote:
> > > Sebastian, for me droid 4 boots just fine with v4.13-rc1 +
> > > 19d39a3810e if that helps. So that's with commit 422580c3cea7.
> > 
> > v4.13-rc1 + 19d39a3810e was also broken for me. I just disabled
> > some unused bits in my .config and now the kernel boots with
> > (with 422580c3cea7 that is). Maybe I hit some maximum image size
> > limit for Droid 4?
> > 
> > Anyways it looks like 422580c3cea7 is not the actual problem
> > and merely reveals some other problem.
> 
> OK. Maybe check kexec --image-size configuration if you have
> a huge static kernel?

I still use the IMGSIZE=26214400 from your kexec wrapper for
Droid 4, which should be 25MB. With the updated .config my
image looks like this:

$ ls -lh arch/arm/boot/*Image
-rwxr-xr-x 1 sre sre  17M Jul 17 12:44 arch/arm/boot/Image
-rwxr-xr-x 1 sre sre 7.2M Jul 17 12:44 arch/arm/boot/zImage

Unfortunately I did not check size before I dropped the config
options. I don't think I removed 8M of config options, but who
knows.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 1/3] PCI: dwc: Handle host_init failures

[Joao Pinto]

Hi Bjorn Andersson,

Às 7:39 AM de 7/16/2017, Bjorn Andersson escreveu:
> In several dwc based drivers host_init can fail, so make sure to
> propagate and handle this to avoid continuing operation of a driver or
> hardware in an invalid state.
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/pci/dwc/pci-dra7xx.c   |  4 +++-
>  drivers/pci/dwc/pci-exynos.c   |  4 +++-
>  drivers/pci/dwc/pci-imx6.c |  4 +++-
>  drivers/pci/dwc/pci-keystone.c |  4 +++-
>  drivers/pci/dwc/pci-layerscape.c   | 14 ++
>  drivers/pci/dwc/pcie-armada8k.c|  4 +++-
>  drivers/pci/dwc/pcie-artpec6.c |  4 +++-
>  drivers/pci/dwc/pcie-designware-host.c |  7 +--
>  drivers/pci/dwc/pcie-designware-plat.c |  4 +++-
>  drivers/pci/dwc/pcie-designware.h  |  2 +-
>  drivers/pci/dwc/pcie-kirin.c   |  4 +++-
>  drivers/pci/dwc/pcie-qcom.c|  6 --
>  drivers/pci/dwc/pcie-spear13xx.c   |  4 +++-
>  13 files changed, 47 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index f2fc5f47064e..e8c13bb76169 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -195,7 +195,7 @@ static void dra7xx_pcie_enable_interrupts(struct 
> dra7xx_pcie *dra7xx)
>   dra7xx_pcie_enable_msi_interrupts(dra7xx);
>  }
>  
> -static void dra7xx_pcie_host_init(struct pcie_port *pp)
> +static int dra7xx_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
> @@ -206,6 +206,8 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
>   dw_pcie_wait_for_link(pci);
>   dw_pcie_msi_init(pp);
>   dra7xx_pcie_enable_interrupts(dra7xx);
> +
> + return 0;
>  }
>  
>  static const struct dw_pcie_host_ops dra7xx_pcie_host_ops = {
> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
> index c78c06552590..f77f872e8b78 100644
> --- a/drivers/pci/dwc/pci-exynos.c
> +++ b/drivers/pci/dwc/pci-exynos.c
> @@ -581,13 +581,15 @@ static int exynos_pcie_link_up(struct dw_pcie *pci)
>   return 0;
>  }
>  
> -static void exynos_pcie_host_init(struct pcie_port *pp)
> +static int exynos_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct exynos_pcie *ep = to_exynos_pcie(pci);
>  
>   exynos_pcie_establish_link(ep);
>   exynos_pcie_enable_interrupts(ep);
> +
> + return 0;
>  }
>  
>  static const struct dw_pcie_host_ops exynos_pcie_host_ops = {
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index bf5c3616e344..20aae4469ee4 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -636,7 +636,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie 
> *imx6_pcie)
>   return ret;
>  }
>  
> -static void imx6_pcie_host_init(struct pcie_port *pp)
> +static int imx6_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct imx6_pcie *imx6_pcie = to_imx6_pcie(pci);
> @@ -649,6 +649,8 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
>  
>   if (IS_ENABLED(CONFIG_PCI_MSI))
>   dw_pcie_msi_init(pp);
> +
> + return 0;
>  }
>  
>  static int imx6_pcie_link_up(struct dw_pcie *pci)
> diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c
> index 4783cec1f78d..3ad3f8aa27b0 100644
> --- a/drivers/pci/dwc/pci-keystone.c
> +++ b/drivers/pci/dwc/pci-keystone.c
> @@ -261,7 +261,7 @@ static int keystone_pcie_fault(unsigned long addr, 
> unsigned int fsr,
>   return 0;
>  }
>  
> -static void __init ks_pcie_host_init(struct pcie_port *pp)
> +static int __init ks_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct keystone_pcie *ks_pcie = to_keystone_pcie(pci);
> @@ -289,6 +289,8 @@ static void __init ks_pcie_host_init(struct pcie_port *pp)
>*/
>   hook_fault_code(17, keystone_pcie_fault, SIGBUS, 0,
>   "Asynchronous external abort");
> +
> + return 0;
>  }
>  
>  static const struct dw_pcie_host_ops keystone_pcie_host_ops = {
> diff --git a/drivers/pci/dwc/pci-layerscape.c 
> b/drivers/pci/dwc/pci-layerscape.c
> index fd861289ad8b..7581490f007c 100644
> --- a/drivers/pci/dwc/pci-layerscape.c
> +++ b/drivers/pci/dwc/pci-layerscape.c
> @@ -108,31 +108,35 @@ static int ls1021_pcie_link_up(struct dw_pcie *pci)
>   return 1;
>  }
>  
> -static void ls1021_pcie_host_init(struct pcie_port *pp)
> +static int ls1021_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct ls_pcie *pcie = to_ls_pcie(pci);
>   struct device *dev = pci->dev;
>   u32 index[2];
> + int ret;
>  
>   pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node,
>  

Re: [PATCH] perf/x86/intel: Fix debug_store reset field for freq events

[Jiri Olsa]

On Fri, Jul 14, 2017 at 10:22:49AM -0700, Andi Kleen wrote:
> Jiri Olsa  writes:
> >
> > Setting the reset field to 0 for freq events.
> 
> Looks good to me.
> 
> Reviewed-by: Andi Kleen 
> 
> BTW I suspect there's a related bug that
> 
> perf record -e '{cycles:pp,branches}:S' ..
> 
> would enable multi record PEBS, even though it shouldn't because
> we need the PMI to read the other events.

there's PERF_SAMPLE_READ om cycles's sample_type for this example
so it won't pass the x86_pmu::free_running_flags filter

also PERF_SAMPLE_TIME and PERF_SAMPLE_PERIOD will be set
in your example which will prevent that, but those
could be unset via record's '-c ' and '--no-timestamp'

jirka

Re: [PATCH v4 0/3] some fixups for MediaTek cpufreq driver

[Rafael J. Wysocki]

On Monday, July 17, 2017 01:05:43 PM Viresh Kumar wrote:
> On 17-07-17, 14:16, Sean Wang wrote:
> > Hi, Viresh
> > 
> > I missed to add Acks from Rob for patch 2 and 3 since we sent out almost
> > at the same time. Do I need to resend again for this or the series is
> > okay for you?
> 
> Looks like you missed including Rafael for this series (He is the one
> who applies these patches).
> 
> I will let him answer for this.
> 
> 

Please respin with all of the applicable tags.

I haven't been following all of the discussions on this that closely.

Thanks,
Rafael

Re: [Patch v5 12/12] Documention: v4l: Documentation for HEVC CIDs

[Smitha T Murthy]

On Fri, 2017-07-07 at 17:59 +0300, Stanimir Varbanov wrote:
> Hi,
> 
> On 06/19/2017 08:10 AM, Smitha T Murthy wrote:
> > Added V4l2 controls for HEVC encoder
> > 
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  Documentation/media/uapi/v4l/extended-controls.rst | 364 
> > +
> >  1 file changed, 364 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> > b/Documentation/media/uapi/v4l/extended-controls.rst
> > index abb1057..7767c70 100644
> > --- a/Documentation/media/uapi/v4l/extended-controls.rst
> > +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> > @@ -1960,6 +1960,370 @@ enum v4l2_vp8_golden_frame_sel -
> >  1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> >  
> >  
> 
> 
> 
> > +``V4L2_CID_MPEG_VIDEO_HEVC_PROFILE``
> > +(enum)
> > +
> > +enum v4l2_mpeg_video_hevc_profile -
> > +Select the desired profile for HEVC encoder.
> > +
> > +.. raw:: latex
> > +
> > +\begin{adjustbox}{width=\columnwidth}
> > +
> > +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> > +
> > +.. flat-table::
> > +:header-rows:  0
> > +:stub-columns: 0
> > +
> > +* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN``
> > +  - Main profile.
> 
> MAIN10?
> 
No just MAIN.

> > +* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE``
> > +  - Main still picture profile.
> > +
> > +.. raw:: latex
> > +
> > +\end{adjustbox}
> > +
> > +
> 
> 
> 
> > +MFC 10.10 MPEG Controls
> > +---
> > +
> > +The following MPEG class controls deal with MPEG decoding and encoding
> > +settings that are specific to the Multi Format Codec 10.10 device present
> > +in the S5P and Exynos family of SoCs by Samsung.
> > +
> > +
> > +.. _mfc1010-control-id:
> > +
> > +MFC 10.10 Control IDs
> > +^
> > +
> > +``V4L2_CID_MPEG_MFC10_VIDEO_HEVC_REF_NUMBER_FOR_PFRAMES (integer)``
> > +Selects number of P reference pictures required for HEVC encoder.
> > +P-Frame can use 1 or 2 frames for reference.
> > +
> > +``V4L2_CID_MPEG_MFC10_VIDEO_HEVC_PREPEND_SPSPPS_TO_IDR (integer)``
> > +Indicates whether to generate SPS and PPS at every IDR. Setting it to 0
> > +disables generating SPS and PPS at every IDR. Setting it to one enables
> > +generating SPS and PPS at every IDR.
> > +
> 
> I'm not sure those two should be driver specific, have to check does
> venus driver has similar controls.
> 
Yes please check and let me know if you have similar controls, I will
move it out.
> > +
> >  .. _camera-controls:
> >  
> >  Camera Control Reference
> > 
> 

Re: [PATCH] Documentation: dt: chosen property for kaslr-seed

[Mark Rutland]

On Sun, Jul 16, 2017 at 05:42:25PM +0100, Ard Biesheuvel wrote:
> On 16 July 2017 at 03:13, Kees Cook  wrote:
> > On Sat, Jul 15, 2017 at 5:42 AM, Ard Biesheuvel
> >  wrote:
> >> (+ Mark, Will, Catalin)
> >>
> >> On 15 July 2017 at 01:38, Kees Cook  wrote:
> >>> Document then /chosen/kaslr-seed property (and its interaction with the
> >>> EFI_RNG_PROTOCOL API).
> >>>
> >>> Signed-off-by: Kees Cook 
> >>> ---
> >>>  Documentation/devicetree/bindings/chosen.txt | 22 --
> >>>  1 file changed, 20 insertions(+), 2 deletions(-)
> >>
> >> For the textual changes:
> >>
> >> Acked-by: Ard Biesheuvel 
> >>
> >> *However*, documenting the /chosen/kaslr-seed property promotes it
> >> from a stub<->kernel private interface to an external ABI between the
> >> kernel and the bootloader, and we need to reach agreement on whether
> >> doing so is desirable first IMHO.
> >
> > Oh! I thought that was the point (having a bootloader provide kaslr
> > entropy). And that in the EFI case, it was the stub doing it.
> 
> It was the opposite, actually,  The /chosen node is the most
> appropriate way for the EFI stub to communicate a seed value to the
> kernel proper, given how it is needed extremely early in the boot.
> (Using UEFI config tables like we do for the /dev/random seed is not
> possible for this)
> 
> So as a side effect, other bootloaders can use the same mechanism. I'm
> fine with that, but it needs to be an explicit decision by the
> maintainers imo.

I was under the impression that we'd already assumed other bootloaders could
set this, so I don't have a problem promoting this to a defined public
interface.

I guess we just need Will and Catalin to agree.

FWIW:

Acked-by: Mark Rutland 

As an aside, we might want to make a split between /chosen properties which are
Linux-specific (e.g. this), and those which are somewhat generic (e.g.
stdout-path), since other OSs may/should respect those generic ones.

Mark.

[PATCH 0/3] arcpgu: Fixes and improvements

[Jose Abreu]

Hi all,

Two fixes and an improvement for arcpgu. I've sent this patches in separate
but I've now collected them all to ease the review.

Best regards,
Jose Miguel Abreu

Jose Abreu (3):
  drm: arcpgu: Fix mmap() callback
  drm: arcpgu: Fix module unload
  drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback

Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 

 drivers/gpu/drm/arc/arcpgu_crtc.c |  7 ---
 drivers/gpu/drm/arc/arcpgu_drv.c  | 26 ++
 2 files changed, 6 insertions(+), 27 deletions(-)

-- 
1.9.1

[PATCH 1/3] drm: arcpgu: Fix mmap() callback

[Jose Abreu]

Now that ARC properly supports DMA mmap() we can use the standard
CMA helper to map dumb buffers. This makes ARC PGU works with
standard DRM consumer applications like, for example, mpv/mplayer
via DRM. While at it, use the DEFINE_DRM_GEM_CMA_FOPS() helper.

This fixes the use of dumb buffers.

Signed-off-by: Jose Abreu 
Fixes: 0c4250e7b15e ("drm: Add support of ARC PGU display controller")
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 24 +---
 1 file changed, 1 insertion(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 3e43a5d..20ab68f 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -48,29 +48,7 @@ static void arcpgu_setup_mode_config(struct drm_device *drm)
drm->mode_config.funcs = _drm_modecfg_funcs;
 }
 
-static int arcpgu_gem_mmap(struct file *filp, struct vm_area_struct *vma)
-{
-   int ret;
-
-   ret = drm_gem_mmap(filp, vma);
-   if (ret)
-   return ret;
-
-   vma->vm_page_prot = pgprot_noncached(vm_get_page_prot(vma->vm_flags));
-   return 0;
-}
-
-static const struct file_operations arcpgu_drm_ops = {
-   .owner = THIS_MODULE,
-   .open = drm_open,
-   .release = drm_release,
-   .unlocked_ioctl = drm_ioctl,
-   .compat_ioctl = drm_compat_ioctl,
-   .poll = drm_poll,
-   .read = drm_read,
-   .llseek = no_llseek,
-   .mmap = arcpgu_gem_mmap,
-};
+DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
 
 static void arcpgu_lastclose(struct drm_device *drm)
 {
-- 
1.9.1

[PATCH 3/3] drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback

[Jose Abreu]

Currently we expect that clock driver produces the exact same value
as we are requiring. There can, and will, be some deviation
however so we need to take that into account instead of just
rejecting the mode.

According to the HDMI spec we have a max of +-0.5% for the pixel clock
frequency deviation. Lets take that into an advantage and use it to
calculate how much deviation we can support.

Signed-off-by: Jose Abreu 
Acked-by: Alexey Brodkin 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 1859dd3..55c5d5b 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -69,12 +69,13 @@ static enum drm_mode_status arc_pgu_crtc_mode_valid(struct 
drm_crtc *crtc,
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
long rate, clk_rate = mode->clock * 1000;
+   long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */
 
rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return MODE_NOCLOCK;
+   if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0))
+   return MODE_OK;
 
-   return MODE_OK;
+   return MODE_NOCLOCK;
 }
 
 static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
-- 
1.9.1