Re: [alsa-devel] [PATCH 00/11] Add AXD Audio Processing IP driver

[Vinod Koul]

On Tue, Oct 28, 2014 at 01:18:28PM +, Qais Yousef wrote:
> On 10/28/2014 11:55 AM, Clemens Ladisch wrote:
> >Qais Yousef wrote:
> >>AXD Audio Processing IP performs audio decoding, encoding, mixing, 
> >>equalisation,
> >>synchronisation and playback.
> >What exactly do you mean with "synchronisation" and "playback"?
> 
> Synchronisation refers to accurate audio playout relative to a master
> clock source including compensation of drift between the master clock
> source and the playout clock of the audio hardware. Hence allowing
> synchronised audio playout across multiple independent devices.
> 
> Playback simple refers to the fact that AXD is capable of managing audio
> playout hardware like I2S and SPDIF interfaces.
> 
> 
> >>It doesn't fit in alsa subsystem but I Cced them to confirm.
> >... because those two words sound like something that a sound card could do.
> 
> The problem mainly stems from the fact that we take a variety of
> compressed audio as input and we could perform audio encoding. The
> problem with the compressed audio is that the range of decoders and
> configuration supported in alsa is limited and there's no support for
FWIW ALSA does not support decoders. The compressed ALSA API allows you to
encode or decode your conent on a DSP, it provides API for that

If you have an additional need for a decoder or an encoder which is not
listed, feel free to send a patch!
The most important point is frameowrk is there for thsi so you need to use
that and add whatever is not supported

> taking raw pcm and producing compressed output. I'm not an expert on
> alsa but when I looked it looked like there's more infra structure
> required.
I disagree. You can use alsa PCM device to send pcm data and then use alsa
compressed device to take back the compressed content. The two devices need
to be "connected" using DPCM and DAPM frameowork availble. It should work
with little or no changes

> 
> The following not supported points from 
> Documentation/sound/alsa/compress_offload.txt affect us:
> 
> - Volume control/routing is not handled by this API. Devices exposing a
>   compressed data interface will be considered as regular ALSA devices;
>   volume changes and routing information will be provided with regular
>   ALSA kcontrols.
And why can't you use ALSA kcontrols for volume??
> 
> - Embedded audio effects. Such effects should be enabled in the same
>   manner, no matter if the input was PCM or compressed.
Again why can't you use ALSA kcontrol for effects, be it PCM or compressed
progarmming an EQ thru alsa kcontrol remains same
> 
> - Encoding/decoding acceleration is not supported as mentioned
>   above. 
Wrong on this count

> It is possible to route the output of a decoder to a capture
>   stream, or even implement transcoding capabilities. This routing
>   would be enabled with ALSA kcontrols.
Yes and it should work

> >>I added it to drivers/char as this is the best location I could think of at 
> >>the
> >>moment.
> >drivers/misc?
> 
> Yeah could do if there's consensus.
NAK for that, this should be an ALSA driver

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

Re: [PATCH RESEND V4 0/9] Tegra xHCI support

[Alexandre Courbot]

On Wed, Oct 29, 2014 at 7:27 AM, Andrew Bresticker
 wrote:
> This series adds support for xHCI on NVIDIA Tegra SoCs.  This includes:
>  - patches 1 and 2: adding a driver for the mailbox used to communicate
>with the xHCI controller's firmware,
>  - patches 3 and 4: extending the XUSB pad controller driver to support
>the USB PHY types (UTMI, HSIC, and USB3),
>  - patches 5 and 6: adding a xHCI host-controller driver, and
>  - patches 7, 8, and 9: updating the relevant DT files.
>
> The PHY and host drivers have compile-time dependencies on the mailbox
> driver, and the host driver has compile-time dependencies on the PHY
> driver.  It is probably best if these all get merged through the Tegra
> tree.  This series still needs ACKs from the relevant maintainers for
> the mailbox and xHCI host drivers and their device-tree bindings.
>
> Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
> USB3.0 memory sticks and ethernet dongles using controller firmware
> recently posted by Andrew Chew [0].
>
> Based on v3.18-rc2.  All other dependencies (xHCI modules and mailbox
> series) have been merged.

I do not feel comfortable enough with xHCI to give a reviewed-by tag,
but FWIW I have found nothing wrong with these patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC V5 3/3] arm64:add bitrev.h file to support rbit instruction

[Wang, Yalin]

This patch add bitrev.h file to support rbit instruction,
so that we can do bitrev operation by hardware.
Signed-off-by: Yalin Wang 
---
 arch/arm64/Kconfig  |  1 +
 arch/arm64/include/asm/bitrev.h | 28 
 2 files changed, 29 insertions(+)
 create mode 100644 arch/arm64/include/asm/bitrev.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..b1ec1dd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -35,6 +35,7 @@ config ARM64
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL
+   select HAVE_ARCH_BITREVERSE
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
diff --git a/arch/arm64/include/asm/bitrev.h b/arch/arm64/include/asm/bitrev.h
new file mode 100644
index 000..292a5de
--- /dev/null
+++ b/arch/arm64/include/asm/bitrev.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_ARM64_BITREV_H
+#define __ASM_ARM64_BITREV_H
+
+static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
+{
+   if (__builtin_constant_p(x)) {
+   x = (x >> 16) | (x << 16);
+   x = ((x & 0xFF00FF00) >> 8) | ((x & 0x00FF00FF) << 8);
+   x = ((x & 0xF0F0F0F0) >> 4) | ((x & 0x0F0F0F0F) << 4);
+   x = ((x & 0x) >> 2) | ((x & 0x) << 2);
+   return ((x & 0x) >> 1) | ((x & 0x) << 1);
+   }
+   __asm__ ("rbit %w0, %w1" : "=r" (x) : "r" (x));
+   return x;
+}
+
+static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
+{
+   return __arch_bitrev32((u32)x) >> 16;
+}
+
+static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
+{
+   return __arch_bitrev32((u32)x) >> 24;
+}
+
+#endif
+
-- 
2.1.1

[RFC V5 2/3] arm:add bitrev.h file to support rbit instruction

[Wang, Yalin]

This patch add bitrev.h file to support rbit instruction,
so that we can do bitrev operation by hardware.
Signed-off-by: Yalin Wang 
---
 arch/arm/Kconfig  |  1 +
 arch/arm/include/asm/bitrev.h | 28 
 2 files changed, 29 insertions(+)
 create mode 100644 arch/arm/include/asm/bitrev.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89c4b5c..be92b3b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -28,6 +28,7 @@ config ARM
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
+   select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7)
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
diff --git a/arch/arm/include/asm/bitrev.h b/arch/arm/include/asm/bitrev.h
new file mode 100644
index 000..c21a5f4
--- /dev/null
+++ b/arch/arm/include/asm/bitrev.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_ARM_BITREV_H
+#define __ASM_ARM_BITREV_H
+
+static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
+{
+   if (__builtin_constant_p(x)) {
+   x = (x >> 16) | (x << 16);
+   x = ((x & 0xFF00FF00) >> 8) | ((x & 0x00FF00FF) << 8);
+   x = ((x & 0xF0F0F0F0) >> 4) | ((x & 0x0F0F0F0F) << 4);
+   x = ((x & 0x) >> 2) | ((x & 0x) << 2);
+   return ((x & 0x) >> 1) | ((x & 0x) << 1);
+   }
+   __asm__ ("rbit %0, %1" : "=r" (x) : "r" (x));
+   return x;
+}
+
+static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
+{
+   return __arch_bitrev32((u32)x) >> 16;
+}
+
+static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
+{
+   return __arch_bitrev32((u32)x) >> 24;
+}
+
+#endif
+
-- 
2.1.1

[RFC V5 1/3] add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction

[Wang, Yalin]

this change add CONFIG_HAVE_ARCH_BITREVERSE config option,
so that we can use arm/arm64 rbit instruction to do bitrev operation
by hardware.

Change bitrev16() bitrev32() to be inline function,
don't need export symbol for these tiny functions.

Signed-off-by: Yalin Wang 
---
 include/linux/bitrev.h | 21 ++---
 lib/Kconfig|  9 +
 lib/bitrev.c   | 17 ++---
 3 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/include/linux/bitrev.h b/include/linux/bitrev.h
index 7ffe03f..413c52c 100644
--- a/include/linux/bitrev.h
+++ b/include/linux/bitrev.h
@@ -3,14 +3,29 @@
 
 #include 
 
-extern u8 const byte_rev_table[256];
+#ifdef CONFIG_HAVE_ARCH_BITREVERSE
+#include 
+
+#define bitrev32 __arch_bitrev32
+#define bitrev16 __arch_bitrev16
+#define bitrev8 __arch_bitrev8
 
+#else
+extern u8 const byte_rev_table[256];
 static inline u8 bitrev8(u8 byte)
 {
return byte_rev_table[byte];
 }
 
-extern u16 bitrev16(u16 in);
-extern u32 bitrev32(u32 in);
+static inline u16 bitrev16(u16 x)
+{
+   return (bitrev8(x & 0xff) << 8) | bitrev8(x >> 8);
+}
+
+static inline u32 bitrev32(u32 x)
+{
+   return (bitrev16(x & 0x) << 16) | bitrev16(x >> 16);
+}
 
+#endif /* CONFIG_HAVE_ARCH_BITREVERSE */
 #endif /* _LINUX_BITREV_H */
diff --git a/lib/Kconfig b/lib/Kconfig
index 54cf309..cd177ca 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -13,6 +13,15 @@ config RAID6_PQ
 config BITREVERSE
tristate
 
+config HAVE_ARCH_BITREVERSE
+   boolean
+   default n
+   depends on BITREVERSE
+   help
+ This option provides an config for the architecture which have 
instruction
+ can do bitreverse operation, we use the hardware instruction if the 
architecture
+ have this capability.
+
 config RATIONAL
boolean
 
diff --git a/lib/bitrev.c b/lib/bitrev.c
index 3956203..40ffda9 100644
--- a/lib/bitrev.c
+++ b/lib/bitrev.c
@@ -1,3 +1,4 @@
+#ifndef CONFIG_HAVE_ARCH_BITREVERSE
 #include 
 #include 
 #include 
@@ -42,18 +43,4 @@ const u8 byte_rev_table[256] = {
 };
 EXPORT_SYMBOL_GPL(byte_rev_table);
 
-u16 bitrev16(u16 x)
-{
-   return (bitrev8(x & 0xff) << 8) | bitrev8(x >> 8);
-}
-EXPORT_SYMBOL(bitrev16);
-
-/**
- * bitrev32 - reverse the order of bits in a u32 value
- * @x: value to be bit-reversed
- */
-u32 bitrev32(u32 x)
-{
-   return (bitrev16(x & 0x) << 16) | bitrev16(x >> 16);
-}
-EXPORT_SYMBOL(bitrev32);
+#endif /* CONFIG_HAVE_ARCH_BITREVERSE */
-- 
2.1.1

[PATCH 2/3] ARM: mediatek: Add I2C node for mt8135 and mt8127

[Xudong Chen]

Add I2C node to mt8135.dtsi and mt8127.dtsi

Signed-off-by: Xudong Chen 
---
 arch/arm/boot/dts/mt8127.dtsi | 27 +++
 arch/arm/boot/dts/mt8135.dtsi | 51 +++
 2 files changed, 78 insertions(+)

diff --git a/arch/arm/boot/dts/mt8127.dtsi b/arch/arm/boot/dts/mt8127.dtsi
index 25c9f69..60d7685e 100644
--- a/arch/arm/boot/dts/mt8127.dtsi
+++ b/arch/arm/boot/dts/mt8127.dtsi
@@ -89,5 +89,32 @@
  <0 0x10214000 0 0x2000>,
  <0 0x10216000 0 0x2000>;
};
+
+   i2c0: i2c@11007000 {
+   compatible = "mediatek,mt8127-i2c",
+   "mediatek,mt6577-i2c";
+   reg = <0 0x11007000 0 0x70>,
+   <0 0x11000200 0 0x80>;
+   interrupts = ;
+   mediatek,have-dcm;
+   };
+
+   i2c1: i2c@11008000 {
+   compatible = "mediatek,mt8127-i2c",
+   "mediatek,mt6577-i2c";
+   reg = <0 0x11008000 0 0x70>,
+   <0 0x11000280 0 0x80>;
+   interrupts = ;
+   mediatek,have-dcm;
+   };
+
+   i2c2: i2c@11009000 {
+   compatible = "mediatek,mt8127-i2c",
+   "mediatek,mt6577-i2c";
+   reg = <0 0x11009000 0 0x70>,
+   <0 0x11000300 0 0x80>;
+   interrupts = ;
+   mediatek,have-dcm;
+   };
};
 };
diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
index 221ce09..1fbfc92 100644
--- a/arch/arm/boot/dts/mt8135.dtsi
+++ b/arch/arm/boot/dts/mt8135.dtsi
@@ -119,7 +119,58 @@
  <0 0x1020C000 0 0x1000>;
gpio-controller;
#gpio-cells = <2>;
+
+   i2c0_pins_a: i2c0@0 {
+   mediatek,pins = ,
+   ;
+   };
+
+   i2c1_pins_a: i2c1@0 {
+   mediatek,pins = ,
+   ;
+   };
+
+   i2c2_pins_a: i2c2@0 {
+   mediatek,pins = ,
+   ;
+   };
+
+   i2c3_pins_a: i2c3@0 {
+   mediatek,pins = ,
+   ;
+   };
};
 
+   i2c0: i2c@1100d000 {
+   compatible = "mediatek,mt8135-i2c",
+   "mediatek,mt6577-i2c";
+   reg = <0 0x1100d000 0 0x70>,
+   <0 0x11000300 0 0x80>;
+   interrupts = ;
+   };
+
+   i2c1: i2c@1100e000 {
+   compatible = "mediatek,mt8135-i2c",
+   "mediatek,mt6577-i2c";
+   reg = <0 0x1100e000 0 0x70>,
+   <0 0x11000380 0 0x80>;
+   interrupts = ;
+   };
+
+   i2c2: i2c@1100f000 {
+   compatible = "mediatek,mt8135-i2c",
+   "mediatek,mt6577-i2c";
+   reg = <0 0x1100f000 0 0x70>,
+   <0 0x11000400 0 0x80>;
+   interrupts = ;
+   };
+
+   i2c3: i2c@1101 {
+   compatible = "mediatek,mt8135-i2c",
+   "mediatek,mt6577-i2c";
+   reg = <0 0x1101 0 0x70>,
+   <0 0x11000480 0 0x80>;
+   interrupts = ;
+   };
};
 };
-- 
1.8.1.1.dirty

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

[PATCH 1/3] dt-bindings: Add I2C bindings for mt65xx/mt81xx.

[Xudong Chen]

Add devicetree bindings for Mediatek Soc I2C driver.

Signed-off-by: Xudong Chen 
---
 .../devicetree/bindings/i2c/i2c-mt6577.txt | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
new file mode 100644
index 000..b4012c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -0,0 +1,37 @@
+* Mediatek's I2C controller
+
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+  - compatible: value should be either of the following.
+  (a) "mtk,mt6577-i2c", for i2c compatible with mt6577 i2c.
+  (b) "mtk,mt8127-i2c", for i2c compatible with mt8127 i2c.
+  (c) "mtk,mt8135-i2c", for i2c compatible with mt8135 i2c.
+  - reg: physical base address of the controller and dma base, length of 
memory mapped
+region.
+  - interrupts: interrupt number to the cpu.
+  - clock-div: the fixed value for frequency divider of clock source in i2c 
module.
+Each IC may be different.
+  - clocks: clock name from clock manager
+  - clock-names: clock name used in i2c driver probe
+
+Optional properties:
+  - clock-frequency: Frequency in Hz of the bus when transfer, the default 
value is 10.
+  - mediatek,have-pmic: platform can control i2c form special pmic side.
+  - mediatek,have-dcm: platform has DCM(hardware digital clock manager) 
property.
+  - mediatek,use-push-pull: IO use push-pull mode.
+
+Example:
+
+   i2c0: i2c@1100d000 {
+   compatible = "mediatek,mt6577-i2c";
+   reg = <0x1100d000 0x70>,
+ <0x11000300 0x80>;
+   interrupts = ;
+   clock-frequency = <10>;
+   mediatek,have-pmic;
+   clock-div = <16>;
+   clocks = <_ck>, <_dma_ck>;
+   clock-names = "main", "dma";
+   };
+
-- 
1.8.1.1.dirty

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

[PATCH 3/3] I2C: mediatek: Add driver for MediaTek I2C controller

[Xudong Chen]

The mediatek SoCs have I2C controller that handle I2C transfer.
This patch include common I2C bus driver.
This driver is compatible with I2C controller on mt65xx/mt81xx.

Signed-off-by: Xudong Chen 
Change-Id: Icc17e326b9df46a226d536956e103f17b0382b6e
---
 drivers/i2c/busses/Kconfig  |   9 +
 drivers/i2c/busses/Makefile |   1 +
 drivers/i2c/busses/i2c-mt65xx.c | 728 
 3 files changed, 738 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-mt65xx.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 917c358..0d7d0a4 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -564,6 +564,15 @@ config I2C_MPC
  This driver can also be built as a module.  If so, the module
  will be called i2c-mpc.
 
+config I2C_MT65XX
+   tristate "MediaTek I2C adapter"
+   depends on ARCH_MEDIATEK
+   help
+ This selects the MediaTek(R) Integrated Inter Circuit bus driver
+ for MT65xx and MT81xx.
+ If you want to use MediaTek(R) I2C interface, say Y or M here.
+ If unsure, say N.
+
 config I2C_MV64XXX
tristate "Marvell mv64xxx I2C Controller"
depends on MV64X60 || PLAT_ORION || ARCH_SUNXI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 78d56c5..7a9f0f3 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_I2C_IMX) += i2c-imx.o
 obj-$(CONFIG_I2C_IOP3XX)   += i2c-iop3xx.o
 obj-$(CONFIG_I2C_KEMPLD)   += i2c-kempld.o
 obj-$(CONFIG_I2C_MPC)  += i2c-mpc.o
+obj-$(CONFIG_I2C_MT65XX)   += i2c-mt65xx.o
 obj-$(CONFIG_I2C_MV64XXX)  += i2c-mv64xxx.o
 obj-$(CONFIG_I2C_MXS)  += i2c-mxs.o
 obj-$(CONFIG_I2C_NOMADIK)  += i2c-nomadik.o
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
new file mode 100644
index 000..8730153
--- /dev/null
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -0,0 +1,728 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Xudong.chen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define I2C_HS_NACKERR (1 << 2)
+#define I2C_ACKERR (1 << 1)
+#define I2C_TRANSAC_COMP   (1 << 0)
+#define I2C_TRANSAC_START  (1 << 0)
+#define I2C_TIMING_STEP_DIV_MASK   (0x3f << 0)
+#define I2C_TIMING_SAMPLE_COUNT_MASK   (0x7 << 0)
+#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8)
+#define I2C_TIMING_DATA_READ_MASK  (0x7 << 12)
+#define I2C_DCM_DISABLE0x
+#define I2C_IO_CONFIG_OPEN_DRAIN   0x0003
+#define I2C_IO_CONFIG_PUSH_PULL0x
+#define I2C_SOFT_RST   0x0001
+#define I2C_FIFO_ADDR_CLR  0x0001
+#define I2C_DELAY_LEN  0x0002
+#define I2C_ST_START_CON   0x8001
+#define I2C_FS_START_CON   0x1800
+#define I2C_TIME_CLR_VALUE 0x
+#define I2C_TIME_DEFAULT_VALUE 0x0003
+#define I2C_WRRD_TRANAC_VALUE  0x0002
+#define I2C_RD_TRANAC_VALUE0x0001
+
+
+
+#define I2C_DMA_CON_TX 0x
+#define I2C_DMA_CON_RX 0x0001
+#define I2C_DMA_START_EN   0x0001
+#define I2C_DMA_INT_FLAG_NONE  0x
+#define I2C_DMA_CLR_FLAG   0x
+
+#define I2C_DEFAUT_SPEED   10  /* hz */
+#define MAX_FS_MODE_SPEED  40
+#define MAX_HS_MODE_SPEED  340
+#define MAX_DMA_TRANS_SIZE 255
+#define MAX_WRRD_TRANS_SIZE32
+#define MAX_SAMPLE_CNT_DIV 8
+#define MAX_STEP_CNT_DIV   64
+#define MAX_HS_STEP_CNT_DIV8
+
+#define I2C_CONTROL_RS  (0x1 << 1)
+#define I2C_CONTROL_DMA_EN  (0x1 << 2)
+#define I2C_CONTROL_CLK_EXT_EN  (0x1 << 3)
+#define I2C_CONTROL_DIR_CHANGE  (0x1 << 4)
+#define I2C_CONTROL_ACKERR_DET_EN   (0x1 << 5)
+#define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
+#define I2C_CONTROL_WRAPPER (0x1 << 0)
+
+#define I2C_DRV_NAME   "mt-i2c"
+
+enum DMA_REGS_OFFSET {
+   OFFSET_INT_FLAG = 0x0,
+   OFFSET_INT_EN = 0x04,
+   OFFSET_EN = 0x08,
+   OFFSET_CON = 0x18,
+   OFFSET_TX_MEM_ADDR = 0x1c,
+   OFFSET_RX_MEM_ADDR = 0x20,
+   OFFSET_TX_LEN = 0x24,
+   

[PATCH 0/3] ARM: mediatek: Add driver for Mediatek I2C controller

[Xudong Chen]

This driver is based on 3.18-rc1 & Hongzhou's gpio patch.

MTK I2C HW has some limitation.
1. If the i2c_msg number is more than one, STOP will be issued instead of
RS(Repeat Start) between each message.
Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..."

2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD
mode the Repeat Start will be issued between 2 messages.
In this driver if 2 messages is first write then read, the driver will
combine 2 messages using Write-Read mode so the RS will be issued between
the 2 messages.
Ex: W/R/R, driver will combine first W/R and then R.
The data series will be:
"START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR +
DATA + STOP".

3. Due to HW limitation, in this version the max transfer data length is 255
in one message. If want to transfer more than 255 bytes, HW needs the SW
driver to split the data. Take 600 bytes for example, the data need to be
divided into 3 parts 255 + 255 + 90. The data series will be:
"START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR +  DATA_90 + STOP"
instead of "START + ADDR + DATA_900 + STOP".
We haven't implement this yet, we will do this in the separate patch.

MT8135 can control I2C pins on PMIC(MT6397) by setting the i2c registers in
MT8135 side. In this case, driver should set OFFSET_PATH_DIR bit first, the
operation on other registers are still the same.

Xudong Chen (3):
  dt-bindings: Add I2C bindings for mt65xx/mt81xx.
  ARM: mediatek: Add I2C node for mt8135 and mt8127
  I2C: mediatek: Add driver for MediaTek I2C controller

 .../devicetree/bindings/i2c/i2c-mt6577.txt |  37 ++
 arch/arm/boot/dts/mt8127.dtsi  |  27 +
 arch/arm/boot/dts/mt8135.dtsi  |  51 ++
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-mt65xx.c| 728 +
 6 files changed, 853 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
 create mode 100644 drivers/i2c/busses/i2c-mt65xx.c

--
1.8.1.1.dirty

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

Re: [PATCH 1/2] Xen: Delay remapping memory of pv-domain

[Juergen Gross]

On 10/29/2014 06:30 AM, Juergen Gross wrote:

On 10/28/2014 06:34 PM, David Vrabel wrote:

Can these patches be split up?  They're hard to review as-is.  e.g., the
changes to page allocation look they could be split out.

On 27/10/14 14:52, Juergen Gross wrote:

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.


How does this impact Matt Rushton's recent change to ensure the
relocated frames are contiguous?


It is simplifying it. :-)

The relocated frames are in the same sequence as before, just at
another location. As the remapping is done later, I don't have to be
careful not to cross a p2m leaf page boundary (allocating a new leaf
page is no problem now).



The change was "xen/setup: Remap Xen Identity Mapped RAM" (4fbb67e3c87).


+/* Update kernel mapping */
+if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn <<
PAGE_SHIFT),
+ mfn_pte(mfn, PAGE_KERNEL), 0)) {
+WARN(1, "Failed to update kernel mapping for mfn=%ld
pfn=%ld\n",
+  mfn, pfn);
+return 0;


I think you need to check if this is a PFN for a high page before
updating the mapping.


Really? I'm not aware of having removed such a check. If it is really
necessary it must have been missing before...


Wait, now I see my fault: by doing the remapping later I've skipped the
highmem check during adding the memory to the system. Okay, I'll update
the patch.


Juergen

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

RE: [RFC V4 1/3] add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction

[Wang, Yalin]

> From: Joe Perches [mailto:j...@perches.com]
> > We also change byte_rev_table[] to be static, to make sure no drivers
> > can access it directly.
> 
> You break the build with this patch.
> 
> You can't do this until the users of the table are converted.
> 
> So far, they are not.
> 
> I submitted patches for these uses, but those patches are not yet applied.
> 
> Please make sure the dependencies for your patches are explicitly stated.
> 
Oh,  byte_rev_table[] must be extern,
Otherwise, bitrev8() can't access it ,
I will change it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 0/3] staging: ion: enable pool shrinking in page unit

[Gioh Kim]

Hello,

Current pool shrinking is not page unit, block unit.
But shrinker returns the pool size in page unit,
so it is confused.

And there is no way to control pool size and shrink pool directly.

I have 3 patches like followings.

1. Patch 1/3: make pool be shrinked by page unit
This patch shrinks pool in page unit.

2. Patch 2/3: limit pool size
This patch specifies pool size limit via debugfs.
The default value of limit is 0.
cat /sys/kernel/debug/ion/heaps/system_limit returns 0.
If you want to create 4 pools and limit each pool by 10MB,
you can write 40MB(=41943040) at system_limit debugfs file
like following:
echo 41943040 > /sys/kernel/debug/ion/heaps/system_limit

2. Patch 3/3: enable debugfs to shrink page directly
This patch enables debugfs to specify shrink amount.
For instance, this shrinks all pages in every pool.
echo 0 > /sys/kernel/debug/ion/heaps/system_shrink
And this shrinks 300-pages from entire pool.
echo 30 > /sys/kernel/debug/ion/heaps/system_shrink
It try to shrink high-order pool first because high-order pages is necessary
more than low-order when the system has low memory.

This patchset is based on linux-next-20141023.


Gioh Kim (3):
  staging: ion: shrink page-pool by page unit
  staging: ion: limit pool size
  staging: ion: debugfs to shrink pool

 drivers/staging/android/ion/ion.c |   62 -
 drivers/staging/android/ion/ion_page_pool.c   |   32 -
 drivers/staging/android/ion/ion_system_heap.c |   20 ++--
 3 files changed, 75 insertions(+), 39 deletions(-)

-- 
1.7.9.5

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

[PATCHv2 2/3] staging: ion: limit pool size

[Gioh Kim]

This patch limits pool size by page unit.
And enable a debugfs file to set limit.

Change-Id: Idaef4daa69084e8ec0844ecefc6738afeab79ccb
Signed-off-by: Gioh Kim 
---
 drivers/staging/android/ion/ion.c |   31 +
 drivers/staging/android/ion/ion_page_pool.c   |   24 +++
 drivers/staging/android/ion/ion_system_heap.c |2 +-
 3 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 290d4d2..036e29b 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1501,6 +1501,25 @@ DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, 
debug_shrink_get,
debug_shrink_set, "%llu\n");
 #endif
 
+extern int pool_limit;
+extern const int num_orders;
+
+static int debug_limit_set(void *data, u64 val)
+{
+/* val is kb unit, pool_limit is for page limit of individual pool */
+pool_limit = (int)(val / PAGE_SIZE) / num_orders;
+return 0;
+}
+
+static int debug_limit_get(void *data, u64 *val)
+{
+*val = pool_limit * PAGE_SIZE * num_orders;
+return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(debug_limit_fops, debug_limit_get,
+debug_limit_set, "%llu\n");
+
 void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
 {
struct dentry *debug_file;
@@ -1549,6 +1568,18 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
pr_err("Failed to create heap shrinker debugfs at 
%s/%s\n",
path, debug_name);
}
+
+   snprintf(debug_name, 64, "%s_limit", heap->name);
+debug_file = debugfs_create_file(
+debug_name, 0644, dev->heaps_debug_root, heap,
+_limit_fops);
+if (!debug_file) {
+char buf[256], *path;
+
+path = dentry_path(dev->heaps_debug_root, buf, 256);
+pr_err("Failed to create heap shrinker debugfs at 
%s/%s\n",
+  path, debug_name);
+}
}
 #endif
up_write(>lock);
diff --git a/drivers/staging/android/ion/ion_page_pool.c 
b/drivers/staging/android/ion/ion_page_pool.c
index 165152f..15d1ac8 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "ion_priv.h"
 
 static void *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
@@ -41,8 +42,21 @@ static void ion_page_pool_free_pages(struct ion_page_pool 
*pool,
__free_pages(page, pool->order);
 }
 
+static int ion_page_pool_total(struct ion_page_pool *pool, bool high)
+{
+   int count = pool->low_count;
+
+   if (high)
+   count += pool->high_count;
+
+   return count << pool->order;
+}
+
 static int ion_page_pool_add(struct ion_page_pool *pool, struct page *page)
 {
+   if (CONFIG_ION_POOL_LIMIT && ion_page_pool_total(pool, 1) > POOL_LIMIT)
+   return 1;
+
mutex_lock(>mutex);
if (PageHighMem(page)) {
list_add_tail(>lru, >high_items);
@@ -103,16 +117,6 @@ void ion_page_pool_free(struct ion_page_pool *pool, struct 
page *page)
ion_page_pool_free_pages(pool, page);
 }
 
-static int ion_page_pool_total(struct ion_page_pool *pool, bool high)
-{
-   int count = pool->low_count;
-
-   if (high)
-   count += pool->high_count;
-
-   return count << pool->order;
-}
-
 int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t gfp_mask,
int nr_to_scan)
 {
diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index 0ba8aaf..d6c0acd 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -30,7 +30,7 @@ static gfp_t high_order_gfp_flags = (GFP_HIGHUSER | 
__GFP_ZERO | __GFP_NOWARN |
 __GFP_NORETRY) & ~__GFP_WAIT;
 static gfp_t low_order_gfp_flags  = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN);
 static const unsigned int orders[] = {4, 3, 2, 0};
-static const int num_orders = ARRAY_SIZE(orders);
+const int num_orders = ARRAY_SIZE(orders);
 static int order_to_index(unsigned int order)
 {
int i;
-- 
1.7.9.5

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

[PATCHv2 3/3] staging: ion: debugfs to shrink pool

[Gioh Kim]

This patch enables debugfs files /sys/kernel/debug/ion/heaps/system_shrink
,which was commented out, to shrink pool or get pool size
Reading the file returns pool size and writing occurs to shrink pool.

Signed-off-by: Gioh Kim 
---
 drivers/staging/android/ion/ion.c   |   31 +++
 drivers/staging/android/ion/ion_page_pool.c |5 -
 2 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 036e29b..4879076 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1463,43 +1463,29 @@ static const struct file_operations debug_heap_fops = {
.release = single_release,
 };
 
-#ifdef DEBUG_HEAP_SHRINKER
 static int debug_shrink_set(void *data, u64 val)
 {
struct ion_heap *heap = data;
-   struct shrink_control sc;
int objs;
 
-   sc.gfp_mask = -1;
-   sc.nr_to_scan = 0;
-
-   if (!val)
-   return 0;
-
-   objs = heap->shrinker.shrink(>shrinker, );
-   sc.nr_to_scan = objs;
+   if (val)
+   objs = val;
+   else
+   objs = heap->ops->shrink(heap, __GFP_HIGHMEM, 0);
 
-   heap->shrinker.shrink(>shrinker, );
+   (void)heap->ops->shrink(heap, __GFP_HIGHMEM, objs);
return 0;
 }
 
 static int debug_shrink_get(void *data, u64 *val)
 {
struct ion_heap *heap = data;
-   struct shrink_control sc;
-   int objs;
-
-   sc.gfp_mask = -1;
-   sc.nr_to_scan = 0;
-
-   objs = heap->shrinker.shrink(>shrinker, );
-   *val = objs;
+   *val = heap->ops->shrink(heap, __GFP_HIGHMEM, 0);
return 0;
 }
 
 DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
-#endif
 
 extern int pool_limit;
 extern const int num_orders;
@@ -1553,8 +1539,7 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
path, heap->name);
}
 
-#ifdef DEBUG_HEAP_SHRINKER
-   if (heap->shrinker.shrink) {
+   if (heap->ops->shrink) {
char debug_name[64];
 
snprintf(debug_name, 64, "%s_shrink", heap->name);
@@ -1581,7 +1566,7 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
   path, debug_name);
 }
}
-#endif
+
up_write(>lock);
 }
 
diff --git a/drivers/staging/android/ion/ion_page_pool.c 
b/drivers/staging/android/ion/ion_page_pool.c
index 15d1ac8..c473c2a 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -25,6 +25,9 @@
 #include 
 #include "ion_priv.h"
 
+/* limit number of pages each pool can have */
+int pool_limit;
+
 static void *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
 {
struct page *page = alloc_pages(pool->gfp_mask, pool->order);
@@ -54,7 +57,7 @@ static int ion_page_pool_total(struct ion_page_pool *pool, 
bool high)
 
 static int ion_page_pool_add(struct ion_page_pool *pool, struct page *page)
 {
-   if (CONFIG_ION_POOL_LIMIT && ion_page_pool_total(pool, 1) > POOL_LIMIT)
+   if (pool_limit && ion_page_pool_total(pool, 1) > pool_limit)
return 1;
 
mutex_lock(>mutex);
-- 
1.7.9.5

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

[PATCHv2 1/3] staging: ion: shrink page-pool by page unit

[Gioh Kim]

This patch shrink page-pool by page unit.

Shrinker usually get the pool size with the pool-scanner
and pass the size to the pool-counter to shrink entire pool.
But the pool-scanner is working in block unit.
and pool-counter page unit.
So it is confused.

Change-Id: If25c693c09f6ebd14c87809feddb72f9058e8308
Signed-off-by: Gioh Kim 
---
 drivers/staging/android/ion/ion_page_pool.c   |5 +++--
 drivers/staging/android/ion/ion_system_heap.c |   18 +++---
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ion/ion_page_pool.c 
b/drivers/staging/android/ion/ion_page_pool.c
index 5864f3d..165152f 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -116,7 +116,7 @@ static int ion_page_pool_total(struct ion_page_pool *pool, 
bool high)
 int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t gfp_mask,
int nr_to_scan)
 {
-   int freed;
+   int freed = 0;
bool high;
 
if (current_is_kswapd())
@@ -127,7 +127,7 @@ int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t 
gfp_mask,
if (nr_to_scan == 0)
return ion_page_pool_total(pool, high);
 
-   for (freed = 0; freed < nr_to_scan; freed++) {
+   while (freed <= nr_to_scan) {
struct page *page;
 
mutex_lock(>mutex);
@@ -141,6 +141,7 @@ int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t 
gfp_mask,
}
mutex_unlock(>mutex);
ion_page_pool_free_pages(pool, page);
+   freed += (1 << pool->order);
}
 
return freed;
diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index da2a63c..0ba8aaf 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -29,7 +29,7 @@
 static gfp_t high_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN |
 __GFP_NORETRY) & ~__GFP_WAIT;
 static gfp_t low_order_gfp_flags  = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN);
-static const unsigned int orders[] = {8, 4, 0};
+static const unsigned int orders[] = {8, 6, 4, 0};
 static const int num_orders = ARRAY_SIZE(orders);
 static int order_to_index(unsigned int order)
 {
@@ -212,14 +212,26 @@ static int ion_system_heap_shrink(struct ion_heap *heap, 
gfp_t gfp_mask,
 {
struct ion_system_heap *sys_heap;
int nr_total = 0;
-   int i;
+   int i, nr_freed;
+   int only_scan = 0;
 
sys_heap = container_of(heap, struct ion_system_heap, heap);
 
+   if (!nr_to_scan)
+   only_scan = 1;
+
for (i = 0; i < num_orders; i++) {
struct ion_page_pool *pool = sys_heap->pools[i];
 
-   nr_total += ion_page_pool_shrink(pool, gfp_mask, nr_to_scan);
+   nr_freed = ion_page_pool_shrink(pool, gfp_mask, nr_to_scan);
+   nr_total += nr_freed;
+
+   if (!only_scan) {
+   nr_to_scan -= nr_freed;
+   /* shrink completed */
+   if (nr_to_scan <= 0)
+   break;
+   }
}
 
return nr_total;
-- 
1.7.9.5

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

Re: [PATCH 1/2] Xen: Delay remapping memory of pv-domain

[Juergen Gross]

On 10/28/2014 06:34 PM, David Vrabel wrote:

Can these patches be split up?  They're hard to review as-is.  e.g., the
changes to page allocation look they could be split out.

On 27/10/14 14:52, Juergen Gross wrote:

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.


How does this impact Matt Rushton's recent change to ensure the
relocated frames are contiguous?


It is simplifying it. :-)

The relocated frames are in the same sequence as before, just at
another location. As the remapping is done later, I don't have to be
careful not to cross a p2m leaf page boundary (allocating a new leaf
page is no problem now).



The change was "xen/setup: Remap Xen Identity Mapped RAM" (4fbb67e3c87).


+   /* Update kernel mapping */
+   if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT),
+mfn_pte(mfn, PAGE_KERNEL), 0)) {
+   WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n",
+ mfn, pfn);
+   return 0;


I think you need to check if this is a PFN for a high page before
updating the mapping.


Really? I'm not aware of having removed such a check. If it is really
necessary it must have been missing before...


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

Re: [PATCH v2] staging: skein: skein_api.c: removed space before ','

[Sudip Mukherjee]

On Tue, Oct 28, 2014 at 09:07:00PM +0100, Mikael Svantesson wrote:
> Signed-off-by: Mikael Svantesson 
still the same problem.

ERROR: patch seems to be corrupt (line wrapped?)


> ---
>  drivers/staging/skein/skein_api.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/skein/skein_api.c 
> b/drivers/staging/skein/skein_api.c
> index 6e700ee..5bfce07 100644
> --- a/drivers/staging/skein/skein_api.c
> +++ b/drivers/staging/skein/skein_api.c
> @@ -31,7 +31,7 @@ int skein_ctx_prepare(struct skein_ctx *ctx, enum 
> skein_size size)
>  {
>   skein_assert_ret(ctx && size, SKEIN_FAIL);
>  -memset(ctx , 0, sizeof(struct skein_ctx));
> + memset(ctx, 0, sizeof(struct skein_ctx));
>   ctx->skein_size = size;
>   return SKEIN_SUCCESS;
> -- 
> 2.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC V4 1/3] add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction

[Joe Perches]

On Wed, 2014-10-29 at 13:14 +0800, Wang, Yalin wrote:
> this change add CONFIG_HAVE_ARCH_BITREVERSE config option,
> so that we can use arm/arm64 rbit instruction to do bitrev operation
> by hardware.

> We also change byte_rev_table[] to be static,
> to make sure no drivers can access it directly.

You break the build with this patch.

You can't do this until the users of the table
are converted.

So far, they are not.

I submitted patches for these uses, but those patches
are not yet applied.

Please make sure the dependencies for your patches
are explicitly stated.


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

RE: [RFC V2] arm/arm64:add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction

[Wang, Yalin]

> From: Rob Herring [mailto:robherri...@gmail.com]
> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index
> >> 9532f8d..263c28c 100644
> >> --- a/arch/arm64/Kconfig
> >> +++ b/arch/arm64/Kconfig
> >> @@ -36,6 +36,7 @@ config ARM64
> >>   select HARDIRQS_SW_RESEND
> >>   select HAVE_ARCH_AUDITSYSCALL
> >>   select HAVE_ARCH_JUMP_LABEL
> >> + select HAVE_ARCH_BITREVERSE
> >>   select HAVE_ARCH_KGDB
> >>   select HAVE_ARCH_TRACEHOOK
> >>   select HAVE_BPF_JIT
> 
> The kconfig lists should be sorted.
> 
> Rob

Got it ,
Thanks for your remind.

Re: Machine crashes right *after* ~successful resume

[Yinghai Lu]

On Tue, Oct 28, 2014 at 4:34 PM, Wilmer van der Gaast  wrote:
>
> I've run the commands twice, once before and once after a single
> suspend+resume cycle. Small difference and only before that cycle:
>
> ruby:~/crashit# diff -u lspcixx-*
> --- lspcixx-nopatch.txt 2014-10-28 23:26:08.679690828 +
> +++ lspcixx-patched.txt 2014-10-28 23:10:05.391896757 +
> @@ -92,10 +92,10 @@
>  2f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  310: 00 00 00 00 1b 36 3a 74 00 00 14 14 31 17 42 00
> -320: 5b 60 09 00 00 20 00 0a 08 10 b8 04 07 00 d5 0c
> +320: 5b 60 09 00 00 20 00 0a 90 10 b8 04 8f 00 5d 0d
>  330: 16 00 00 28 bc b5 bc 4a 00 00 00 00 74 4c 85 00
> -340: 33 03 33 00 64 03 3f 00 30 00 0c 00 f8 07 d5 00
> -350: fe 07 dd 00 01 00 08 00 00 00 00 00 00 00 00 00
> +340: 33 03 33 00 64 03 3f 00 30 00 0c 00 f8 07 5d 00
> +350: fe 07 65 00 01 00 08 00 00 00 00 00 00 00 00 00
>  360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> (Diff is in the Intel device, not the ITE one.)
>

That is strange.

Anyway please try attached patched on top of 3.17.

Thanks

Yinghai
---
 drivers/pci/pci.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6/drivers/pci/pci.c
===
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -1265,6 +1265,8 @@ static void pci_enable_bridge(struct pci
 	pci_set_master(dev);
 }
 
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ITE, 0x8892, pci_enable_bridge);
+
 static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
 {
 	struct pci_dev *bridge;

[RFC V4 3/3] arm64:add bitrev.h file to support rbit instruction

[Wang, Yalin]

This patch add bitrev.h file to support rbit instruction,
so that we can do bitrev operation by hardware.
Signed-off-by: Yalin Wang 
---
 arch/arm64/Kconfig  |  1 +
 arch/arm64/include/asm/bitrev.h | 28 
 2 files changed, 29 insertions(+)
 create mode 100644 arch/arm64/include/asm/bitrev.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..b1ec1dd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -35,6 +35,7 @@ config ARM64
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL
+   select HAVE_ARCH_BITREVERSE
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
diff --git a/arch/arm64/include/asm/bitrev.h b/arch/arm64/include/asm/bitrev.h
new file mode 100644
index 000..292a5de
--- /dev/null
+++ b/arch/arm64/include/asm/bitrev.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_ARM64_BITREV_H
+#define __ASM_ARM64_BITREV_H
+
+static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
+{
+   if (__builtin_constant_p(x)) {
+   x = (x >> 16) | (x << 16);
+   x = ((x & 0xFF00FF00) >> 8) | ((x & 0x00FF00FF) << 8);
+   x = ((x & 0xF0F0F0F0) >> 4) | ((x & 0x0F0F0F0F) << 4);
+   x = ((x & 0x) >> 2) | ((x & 0x) << 2);
+   return ((x & 0x) >> 1) | ((x & 0x) << 1);
+   }
+   __asm__ ("rbit %w0, %w1" : "=r" (x) : "r" (x));
+   return x;
+}
+
+static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
+{
+   return __arch_bitrev32((u32)x) >> 16;
+}
+
+static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
+{
+   return __arch_bitrev32((u32)x) >> 24;
+}
+
+#endif
+
-- 
2.1.1

[RFC V4 2/3] arm:add bitrev.h file to support rbit instruction

[Wang, Yalin]

This patch add bitrev.h file to support rbit instruction,
so that we can do bitrev operation by hardware.
Signed-off-by: Yalin Wang 
---
 arch/arm/Kconfig  |  1 +
 arch/arm/include/asm/bitrev.h | 28 
 2 files changed, 29 insertions(+)
 create mode 100644 arch/arm/include/asm/bitrev.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89c4b5c..be92b3b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -28,6 +28,7 @@ config ARM
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
+   select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7)
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
diff --git a/arch/arm/include/asm/bitrev.h b/arch/arm/include/asm/bitrev.h
new file mode 100644
index 000..c21a5f4
--- /dev/null
+++ b/arch/arm/include/asm/bitrev.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_ARM_BITREV_H
+#define __ASM_ARM_BITREV_H
+
+static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
+{
+   if (__builtin_constant_p(x)) {
+   x = (x >> 16) | (x << 16);
+   x = ((x & 0xFF00FF00) >> 8) | ((x & 0x00FF00FF) << 8);
+   x = ((x & 0xF0F0F0F0) >> 4) | ((x & 0x0F0F0F0F) << 4);
+   x = ((x & 0x) >> 2) | ((x & 0x) << 2);
+   return ((x & 0x) >> 1) | ((x & 0x) << 1);
+   }
+   __asm__ ("rbit %0, %1" : "=r" (x) : "r" (x));
+   return x;
+}
+
+static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
+{
+   return __arch_bitrev32((u32)x) >> 16;
+}
+
+static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
+{
+   return __arch_bitrev32((u32)x) >> 24;
+}
+
+#endif
+
-- 
2.1.1

RE: [PATCH] mmc:core: fix hs400 timing selection

[유한경]

Hi

I have read the specifications document to answer your question.
It is better, I think, the host controller is changed into DDR50 mode when
to change the eMMC bus mode into DDR50
There will no problem because the no data line will be used in DDR50 mode
during the transition to HS400.


So we drop this patch

Sorry for confusing. Thanks for the helpful response.

-Original Message-
From: Jaehoon Chung [mailto:jh80.ch...@samsung.com] 
Sent: Wednesday, October 29, 2014 11:05 AM
To: 유한경; 'Jaehoon Chung'; 'Chanho Min'; 'Chris Ball'; 'Ulf Hansson';
'Seungwon Jeon'
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 'HyoJun Im';
gunho@lge.com; 'CPGS'
Subject: Re: [PATCH] mmc:core: fix hs400 timing selection

Hi,

On 10/29/2014 08:52 AM, 유한경 wrote:
> Hi I'm Hankyung Yu
> 
> I will answer instead Chanho Min
> 
> After mmc_set_timing(card->host, MMC_TIMING_MMC_HS);
> 
> Host controller set to SDR transfer
> 
> so is to change to a DDR transfer mode.

As commit message was mentioned, I have checked the JEDEC v5.01 spec(6.6.5).
There is no mention that mode needs to change to DDR mode.

And i know HS400 mode is only support the 8bit buswidth.
If HS200 mode was set to 4bit buswidth, is HS400 working fine?

Best Regards,
Jaehoon Chung

> 
> 
> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: Tuesday, October 28, 2014 1:38 PM
> To: Chanho Min; Chris Ball; Ulf Hansson; Seungwon Jeon; Jaehoon Chung
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; HyoJun 
> Im; gunho@lge.com; Hankyung Yu; CPGS
> Subject: Re: [PATCH] mmc:core: fix hs400 timing selection
> 
> Hi, Chanho.
> 
> On 10/22/2014 11:55 AM, Chanho Min wrote:
>> According to JEDEC v5.01 spec (6.6.5), In order to switch to HS400 
>> mode, host should perform the following steps.
>>
>>  1. HS200 mode selection completed
>>  2. Set HS_TIMING to 0x01(High Speed)  3. Host changes frequency to 
>> =< 52MHz  4. Set the bus width to DDR 8bit (CMD6)  5. Host may read 
>> Driver Strength (CMD8)  6. Set HS_TIMING to 0x03 (HS400)
>>
>> In current implementation, the order of 2 and 3 is reversed.
>> The HS_TIMING field should be set to 0x1 before the clock frequency 
>> is set to a value not greater than 52 MHz. Otherwise, Initialization 
>> of timing can be failed. Also, the host contoller's UHS timing mode 
>> should be set to DDR50 after the bus width is set to DDR 8bit.
>>
>> Signed-off-by: Hankyung Yu 
>> Signed-off-by: Chanho Min 
>> ---
>>  drivers/mmc/core/mmc.c |   13 ++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index
>> a301a78..52f78e0 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1061,9 +1061,6 @@ static int mmc_select_hs400(struct mmc_card *card)
>>   * Before switching to dual data rate operation for HS400,
>>   * it is required to convert from HS200 mode to HS mode.
>>   */
>> -mmc_set_timing(card->host, MMC_TIMING_MMC_HS);
>> -mmc_set_bus_speed(card);
>> -
>>  err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> EXT_CSD_HS_TIMING, EXT_CSD_TIMING_HS,
>> card->ext_csd.generic_cmd6_time, @@ -1074,6
> +1071,14 @@ static
>> int mmc_select_hs400(struct mmc_card *card)
>>  return err;
>>  }
>>  
>> +/*
>> + * According to JEDEC v5.01 spec (6.6.5), Clock frequency should
>> + * be set to a value not greater than 52MHz after the HS_TIMING
>> + * field is set to 0x1.
>> + */
>> +mmc_set_timing(card->host, MMC_TIMING_MMC_HS);
>> +mmc_set_bus_speed(card);
>> +
>>  err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>>   EXT_CSD_BUS_WIDTH,
>>   EXT_CSD_DDR_BUS_WIDTH_8,
>> @@ -1084,6 +1089,8 @@ static int mmc_select_hs400(struct mmc_card *card)
>>  return err;
>>  }
>>  
>> +mmc_set_timing(card->host, MMC_TIMING_MMC_DDR52);
>> +
> 
> I didn't know why timing is set to ddr50.
> 
> Best Regards,
> Jaehoon Chung
> 
>>  err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> EXT_CSD_HS_TIMING, EXT_CSD_TIMING_HS400,
>> card->ext_csd.generic_cmd6_time,
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 
> in the body of a message to majord...@vger.kernel.org More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html
> 

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

[RFC V4 1/3] add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction

[Wang, Yalin]

this change add CONFIG_HAVE_ARCH_BITREVERSE config option,
so that we can use arm/arm64 rbit instruction to do bitrev operation
by hardware.

We also change byte_rev_table[] to be static,
to make sure no drivers can access it directly.

Change bitrev16() bitrev32() to be inline function,
don't need export symbol for these tiny functions.

Signed-off-by: Yalin Wang 
---
 include/linux/bitrev.h | 21 ++---
 lib/Kconfig|  9 +
 lib/bitrev.c   | 19 +++
 3 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/include/linux/bitrev.h b/include/linux/bitrev.h
index 7ffe03f..fa2682c 100644
--- a/include/linux/bitrev.h
+++ b/include/linux/bitrev.h
@@ -3,14 +3,29 @@
 
 #include 
 
-extern u8 const byte_rev_table[256];
+#ifdef CONFIG_HAVE_ARCH_BITREVERSE
+#include 
+
+#define bitrev32 __arch_bitrev32
+#define bitrev16 __arch_bitrev16
+#define bitrev8 __arch_bitrev8
+
+#else
 
 static inline u8 bitrev8(u8 byte)
 {
return byte_rev_table[byte];
 }
 
-extern u16 bitrev16(u16 in);
-extern u32 bitrev32(u32 in);
+static inline u16 bitrev16(u16 x)
+{
+   return (bitrev8(x & 0xff) << 8) | bitrev8(x >> 8);
+}
+
+static inline u32 bitrev32(u32 x)
+{
+   return (bitrev16(x & 0x) << 16) | bitrev16(x >> 16);
+}
 
+#endif /* CONFIG_HAVE_ARCH_BITREVERSE */
 #endif /* _LINUX_BITREV_H */
diff --git a/lib/Kconfig b/lib/Kconfig
index 54cf309..cd177ca 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -13,6 +13,15 @@ config RAID6_PQ
 config BITREVERSE
tristate
 
+config HAVE_ARCH_BITREVERSE
+   boolean
+   default n
+   depends on BITREVERSE
+   help
+ This option provides an config for the architecture which have 
instruction
+ can do bitreverse operation, we use the hardware instruction if the 
architecture
+ have this capability.
+
 config RATIONAL
boolean
 
diff --git a/lib/bitrev.c b/lib/bitrev.c
index 3956203..ba13610 100644
--- a/lib/bitrev.c
+++ b/lib/bitrev.c
@@ -1,3 +1,4 @@
+#ifndef CONFIG_HAVE_ARCH_BITREVERSE
 #include 
 #include 
 #include 
@@ -6,7 +7,7 @@ MODULE_AUTHOR("Akinobu Mita ");
 MODULE_DESCRIPTION("Bit ordering reversal functions");
 MODULE_LICENSE("GPL");
 
-const u8 byte_rev_table[256] = {
+const static u8 byte_rev_table[256] = {
0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8,
@@ -42,18 +43,4 @@ const u8 byte_rev_table[256] = {
 };
 EXPORT_SYMBOL_GPL(byte_rev_table);
 
-u16 bitrev16(u16 x)
-{
-   return (bitrev8(x & 0xff) << 8) | bitrev8(x >> 8);
-}
-EXPORT_SYMBOL(bitrev16);
-
-/**
- * bitrev32 - reverse the order of bits in a u32 value
- * @x: value to be bit-reversed
- */
-u32 bitrev32(u32 x)
-{
-   return (bitrev16(x & 0x) << 16) | bitrev16(x >> 16);
-}
-EXPORT_SYMBOL(bitrev32);
+#endif /* CONFIG_HAVE_ARCH_BITREVERSE */
-- 
2.1.1

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 2/3] introduce probe_slab_address()

[Kirill Tkhai]

В Вт, 28/10/2014 в 21:12 +0100, Oleg Nesterov пишет:
> On 10/28, Oleg Nesterov wrote:
> >
> > On 10/28, Kirill Tkhai wrote:
> > >
> > > Yes, probe_kernel_read() is in [1/3], but it's not the same as
> > > __probe_kernel_read() for blackfin, for example.
> > >
> > > It's defined as
> > >
> > > long __weak probe_kernel_read(void *dst, const void *src, size_t size)
> > > __attribute__((alias("__probe_kernel_read")));
> > >
> > > But blackfin's probe_kernel_read() redefines this __weak function,
> > > isn't it? Didn't get_freepointer_safe() use to call architecture's
> > > probe_kernel_read() before?
> >
> > I _think_ that __probe_kernel_read(slab_ddr) should be fine.
> >
> > Yes, an architecture may want to reimplement probe_kernel_read() to
> > allow to safely access the special areas, or special addresses.
> >
> > But again, in this case we know that this address points to the
> > "normal" kernel memory, __copy_from_user_inatomic() should work fine.
> 
> OTOH, perhaps probe_kernel_address() should use probe_kernel_read(), not
> __probe_kernel_read(). But currently it just calls __copy_inatomic() so
> 1/3 follows this logic.

Ok, thanks for the explanation, Oleg.

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

Re: [sched] [ INFO: suspicious RCU usage. ]

[Kirill Tkhai]

Thanks, Fengguang.

I've suggested this patch https://lkml.org/lkml/2014/10/28/41.

В Вт, 28/10/2014 в 22:27 +0800, Fengguang Wu пишет:
> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/urgent
> commit f6a2b544517d33f6a1e428567bda96fd859ce1c9
> Author: Kirill Tkhai 
> AuthorDate: Mon Oct 27 14:18:25 2014 +0400
> Commit: Peter Zijlstra 
> CommitDate: Mon Oct 27 13:23:31 2014 +0100
> 
> sched: Fix race between task_group and sched_task_group
> 
> The race may happen when somebody is changing task_group of a forking 
> task.
> Child's cgroup is the same as parent's after dup_task_struct() (there just
> memory copying). Also, cfs_rq and rt_rq are the same as parent's.
> 
> But if parent changes its task_group before it's called 
> cgroup_post_fork(),
> we do not reflect this situation on child. Child's cfs_rq and rt_rq remain
> the same, while child's task_group changes in cgroup_post_fork().
> 
> To fix this we introduce fork() method, which calls sched_move_task() 
> directly.
> This function changes sched_task_group on appropriate (also its logic has
> no problem with freshly created tasks, so we shouldn't introduce something
> special; we are able just to use it).
> 
> Possibly, this decides the Burke Libbey's problem: 
> https://lkml.org/lkml/2014/10/24/456
> 
> Signed-off-by: Kirill Tkhai 
> Signed-off-by: Peter Zijlstra (Intel) 
> Link: http://lkml.kernel.org/r/1414405105.19914.169.camel@tkhai
> 
> +---+---+++
> |   | v3.18-rc2 | f6a2b54451 | 8e5859c73b |
> +---+---+++
> | boot_successes| 200   | 0  | 0  |
> | boot_failures | 1 | 20 | 11 |
> | BUG:kernel_boot_hang  | 1 |||
> | INFO:suspicious_RCU_usage | 0 | 20 | 11 |
> | backtrace:do_fork | 0 | 20 | 11 |
> +---+---+++
> 
> [0.060187] 
> [0.060500] ===
> [0.060500] ===
> [0.061307] [ INFO: suspicious RCU usage. ]
> [0.061307] [ INFO: suspicious RCU usage. ]
> [0.062109] 3.18.0-rc2-gf6a2b54 #404 Not tainted
> [0.062109] 3.18.0-rc2-gf6a2b54 #404 Not tainted
> [0.063049] ---
> 
> git bisect start 8e5859c73b9f4560441a23eba899bb24c82e 
> 522e980064c24d3dd9859e9375e17417496567cf --
> git bisect  bad 259820751fd17a4b49098429c68c2c0adfd1c9ed  # 21:11  0- 
>  2  Merge branch 'sched/core'
> git bisect  bad 8c64bf8de891aa51e916b51a3f7992321ec19b63  # 21:15  0- 
>  1  Merge branch 'sched/urgent'
> git bisect  bad fd457f2bafdc4e367d1814ac395035a35980783f  # 21:27  0- 
>  7  sched/fair: Care divide error in update_task_scan_period()
> git bisect  bad fb5b330f079e243dcc831e9a3d65b9b9fbbed7f8  # 21:36  0- 
>  1  sched/deadline: don't replenish from a !SCHED_DEADLINE entity
> git bisect  bad f6a2b544517d33f6a1e428567bda96fd859ce1c9  # 21:41  0- 
>  2  sched: Fix race between task_group and sched_task_group
> # first bad commit: [f6a2b544517d33f6a1e428567bda96fd859ce1c9] sched: Fix 
> race between task_group and sched_task_group
> git bisect good cac7f2429872d3733dc3f9915857b1691da2eb2f  # 21:58 60+ 
>  1  Linux 3.18-rc2
> git bisect  bad 8e5859c73b9f4560441a23eba899bb24c82e  # 22:00  0- 
> 11  Merge branch 'sched/wait'
> git bisect good cac7f2429872d3733dc3f9915857b1691da2eb2f  # 22:05 60+ 
>  1  Linux 3.18-rc2
> git bisect good 7a891e6323e963f3301e44bdeee734028e34d390  # 22:14 60+ 
>  0  Add linux-next specific files for 20141027
> 
> 
> This script may reproduce the error.
> 
> 
> #!/bin/bash
> 
> kernel=$1
> initrd=quantal-core-x86_64.cgz
> 
> wget --no-clobber 
> https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
> 
> kvm=(
>   qemu-system-x86_64
>   -cpu kvm64
>   -enable-kvm
>   -kernel $kernel
>   -initrd $initrd
>   -m 320
>   -smp 2
>   -net nic,vlan=1,model=e1000
>   -net user,vlan=1
>   -boot order=nc
>   -no-reboot
>   -watchdog i6300esb
>   -rtc base=localtime
>   -serial stdio
>   -display none
>   -monitor null 
> )
> 
> append=(
>   hung_task_panic=1
>   earlyprintk=ttyS0,115200
>   debug
>   apic=debug
>   sysrq_always_enabled
>   rcupdate.rcu_cpu_stall_timeout=100
>   panic=-1
>   softlockup_panic=1
>   nmi_watchdog=panic
>   oops=panic
>   load_ramdisk=2
>   prompt_ramdisk=0
>   console=ttyS0,115200

Re: [GIT PULL] Fix for Integrity subsystem null pointer deref

[Andy Lutomirski]

On Tue, Oct 28, 2014 at 8:55 PM, James Morris  wrote:
> These changes fix a bug in xattr handling, where the evm and ima
> inode_setxattr() functions do not check for empty xattrs being passed from
> userspace (leading to user-triggerable null pointer dereferences).
>
> Please pull.
>
>
> The following changes since commit 9f76628da20f96a179ca62b504886f99ecc29223:
>
>   Merge branch 'for-3.18' of git://linux-nfs.org/~bfields/linux (2014-10-28 
> 13:32:06 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
> for-linus
>
> Dmitry Kasatkin (2):
>   ima: check xattr value length and type in the ima_inode_setxattr()

I haven't read this one, but:

>   evm: check xattr value length and type in evm_inode_setxattr()

const struct evm_ima_xattr_data *xattr_data = xattr_value;
- if ((strcmp(xattr_name, XATTR_NAME_EVM) == 0)
- && (xattr_data->type == EVM_XATTR_HMAC))
- return -EPERM;
+ if (strcmp(xattr_name, XATTR_NAME_EVM) == 0) {
+ if (!xattr_value_len)
+ return -EINVAL;
+ if (xattr_data->type != EVM_IMA_XATTR_DIGSIG)
+ return -EPERM;
+ }

Huh?  (Sorry about severe whitespace damage.)

Shouldn't there be something like if (xattr_value_len < sizeof(struct
evm_ima_xattr_data)) return -EINVAL?

--Andy

>
> James Morris (1):
>   Merge branch 'for-linus' of 
> git://git.kernel.org/.../zohar/linux-integrity into for-linus
>
>  security/integrity/evm/evm_main.c |9 ++---
>  security/integrity/ima/ima_appraise.c |2 ++
>  security/integrity/integrity.h|1 +
>  3 files changed, 9 insertions(+), 3 deletions(-)



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

[PATCH 4/4] f2fs: revisit inline_data to avoid data races and potential bugs

[Jaegeuk Kim]

This patch simplifies the inline_data usage with the following rule.
1. inline_data is set during the file creation.
2. If new data is requested to be written ranges out of inline_data,
 f2fs converts that inode permanently.
3. There is no cases which converts non-inline_data inode to inline_data.
4. The inline_data flag should be changed under inode page lock.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c  |  89 +++---
 fs/f2fs/f2fs.h  |  24 +-
 fs/f2fs/file.c  | 105 --
 fs/f2fs/inline.c| 194 +++-
 fs/f2fs/inode.c |   1 +
 fs/f2fs/namei.c |   3 +
 include/linux/f2fs_fs.h |   1 +
 7 files changed, 210 insertions(+), 207 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index e3788bd..ceee1a6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -737,14 +737,14 @@ int f2fs_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
 static int f2fs_read_data_page(struct file *file, struct page *page)
 {
struct inode *inode = page->mapping->host;
-   int ret;
+   int ret = -EAGAIN;
 
trace_f2fs_readpage(page, DATA);
 
/* If the file has inline data, try to read it directly */
if (f2fs_has_inline_data(inode))
ret = f2fs_read_inline_data(inode, page);
-   else
+   if (ret == -EAGAIN)
ret = mpage_readpage(page, get_data_block);
 
return ret;
@@ -856,10 +856,11 @@ write:
else if (has_not_enough_free_secs(sbi, 0))
goto redirty_out;
 
+   err = -EAGAIN;
f2fs_lock_op(sbi);
-   if (f2fs_has_inline_data(inode) || f2fs_may_inline(inode))
-   err = f2fs_write_inline_data(inode, page, offset);
-   else
+   if (f2fs_has_inline_data(inode))
+   err = f2fs_write_inline_data(inode, page);
+   if (err == -EAGAIN)
err = do_write_data_page(page, );
f2fs_unlock_op(sbi);
 done:
@@ -957,24 +958,14 @@ static int f2fs_write_begin(struct file *file, struct 
address_space *mapping,
 
f2fs_balance_fs(sbi);
 repeat:
-   err = f2fs_convert_inline_data(inode, pos + len, NULL);
-   if (err)
-   goto fail;
-
page = grab_cache_page_write_begin(mapping, index, flags);
if (!page) {
err = -ENOMEM;
goto fail;
}
 
-   /* to avoid latency during memory pressure */
-   unlock_page(page);
-
*pagep = page;
 
-   if (f2fs_has_inline_data(inode) && (pos + len) <= MAX_INLINE_DATA)
-   goto inline_data;
-
f2fs_lock_op(sbi);
 
/* check inline_data */
@@ -982,32 +973,42 @@ repeat:
if (IS_ERR(ipage))
goto unlock_fail;
 
+   set_new_dnode(, inode, ipage, ipage, 0);
+
if (f2fs_has_inline_data(inode)) {
-   f2fs_put_page(ipage, 1);
-   f2fs_unlock_op(sbi);
-   f2fs_put_page(page, 0);
-   goto repeat;
+   if (pos + len <= MAX_INLINE_DATA) {
+   read_inline_data(page, ipage);
+   set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
+   sync_inode_page();
+   goto put_next;
+   } else if (page->index == 0) {
+   err = f2fs_convert_inline_page(, page);
+   if (err)
+   goto unlock_fail;
+   } else {
+   struct page *p = grab_cache_page(inode->i_mapping, 0);
+   if (!p) {
+   err = -ENOMEM;
+   goto unlock_fail;
+   }
+   err = f2fs_convert_inline_page(, p);
+   f2fs_put_page(p, 1);
+   if (err)
+   goto unlock_fail;
+   }
}
-
-   set_new_dnode(, inode, ipage, NULL, 0);
err = f2fs_reserve_block(, index);
if (err)
goto unlock_fail;
+put_next:
f2fs_put_dnode();
f2fs_unlock_op(sbi);
 
-inline_data:
-   lock_page(page);
-   if (unlikely(page->mapping != mapping)) {
-   f2fs_put_page(page, 1);
-   goto repeat;
-   }
-
-   f2fs_wait_on_page_writeback(page, DATA);
-
if ((len == PAGE_CACHE_SIZE) || PageUptodate(page))
return 0;
 
+   f2fs_wait_on_page_writeback(page, DATA);
+
if ((pos & PAGE_CACHE_MASK) >= i_size_read(inode)) {
unsigned start = pos & (PAGE_CACHE_SIZE - 1);
unsigned end = start + len;
@@ -1017,13 +1018,7 @@ inline_data:
goto out;
}
 
-   if (f2fs_has_inline_data(inode)) {
-   err = f2fs_read_inline_data(inode, page);
-   if (err) {
-   page_cache_release(page);
-   goto 

[PATCH 2/4] f2fs: flush_dcache_page for inline data

[Jaegeuk Kim]

When reading inline data, we should call flush_dcache_page.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/inline.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index d9daf76..d6677d6 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -57,6 +57,7 @@ int f2fs_read_inline_data(struct inode *inode, struct page 
*page)
src_addr = inline_data_addr(ipage);
dst_addr = kmap_atomic(page);
memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
+   flush_dcache_page(page);
kunmap_atomic(dst_addr);
f2fs_put_page(ipage, 1);
 out:
-- 
2.1.1

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

[PATCH 3/4] f2fs: do not discard data protected by the previous checkpoint

[Jaegeuk Kim]

We should not discard any data protected by the previous checkpoint all
the time.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index d391a59..06dda73 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -517,7 +517,7 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi, 
struct cp_control *cpc)
 
/* SIT_VBLOCK_MAP_SIZE should be multiple of sizeof(unsigned long) */
for (i = 0; i < entries; i++)
-   dmap[i] = (cur_map[i] ^ ckpt_map[i]) & ckpt_map[i];
+   dmap[i] = ~(cur_map[i] | ckpt_map[i]);
 
while (force || SM_I(sbi)->nr_discards <= SM_I(sbi)->max_discards) {
start = __find_rev_next_bit(dmap, max_blocks, end + 1);
-- 
2.1.1

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

[PATCH 1/4] f2fs: call write_checkpoint under disabled gc

[Jaegeuk Kim]

During the write_checkpoint, we should avoid f2fs_gc trigger to avoid any
filesystem consistency.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 21ccc48..d391a59 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1046,7 +1046,9 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct 
fstrim_range *range)
cpc.trim_minlen = range->minlen >> sbi->log_blocksize;
 
/* do checkpoint to issue discard commands safely */
+   mutex_lock(>gc_mutex);
write_checkpoint(sbi, );
+   mutex_unlock(>gc_mutex);
 out:
range->len = cpc.trimmed << sbi->log_blocksize;
return 0;
-- 
2.1.1

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

[RFC] stating: ion: use hot page first in pool

[Gioh Kim]

Hello,

I found that ion insert freed-page at the tail of list
and extract at the head.

I think it is good for cache to use the most recently used page
but these pages in pool are not cached memory.
So I'm not sure using hot page is better or not in this case.

What do you think about using hot page first?

-- 8< -

>From 14c8455cc80628e56a27ace9603d29e5056835b5 Mon Sep 17 00:00:00 2001
From: Gioh Kim 
Date: Wed, 29 Oct 2014 13:44:28 +0900
Subject: [PATCH] staging: ion: use hot-page first

A page near the head is hot for cache.
This patch makes pool use hot page first.

Signed-off-by: Gioh Kim 
---
 drivers/staging/android/ion/ion_page_pool.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_page_pool.c 
b/drivers/staging/android/ion/ion_page_pool.c
index 5864f3d..3d6ac4f 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -45,10 +45,10 @@ static int ion_page_pool_add(struct ion_page_pool *pool, 
struct page *page)
 {
mutex_lock(>mutex);
if (PageHighMem(page)) {
-   list_add_tail(>lru, >high_items);
+   list_add(>lru, >high_items);
pool->high_count++;
} else {
-   list_add_tail(>lru, >low_items);
+   list_add(>lru, >low_items);
pool->low_count++;
}
mutex_unlock(>mutex);
--
1.7.9.5

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

Re: [PATCH RFC v2 1/8] pinctrl: Add driver for Zynq

[Lothar Waßmann]

Hi,

Sören Brinkmann wrote:
> On Tue, 2014-10-28 at 04:16PM +0100, Lothar Waßmann wrote:
> > Hi,
> > 
> > Soren Brinkmann wrote:
> > > Signed-off-by: Soren Brinkmann 
> > > ---
> > > changes since RFC:
> > >  - use syscon/regmap to access registers in SLCR space
> > >  - add pinctrl to zc702 DT
> > >  - rebase to 3.18: rename enable -> set_mux
> > >  - add kernel-doc
> > >  - support pinconf
> > >- supported attributes
> > >  - pin-bias: pull up, tristate, disable
> > >  - slew-rate: 0 == slow, 1 == fast; generic pinconf does not display
> > >argument
> > > 
> > [...]
> > > +struct zynq_pctrl_group zynq_pctrl_groups[] = {
> > > + DEFINE_ZYNQ_PINCTRL_GRP(ethernet0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(ethernet1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(mdio0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(mdio1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(qspi0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(qspi1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(qspi_fbclk),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(qspi_cs1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(spi0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(spi0_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(spi0_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(spi1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(spi1_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(spi1_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(spi1_3),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio0_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio0_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio1_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio1_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio1_3),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio0_emio_wp),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio0_emio_cd),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio1_emio_wp),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(sdio1_emio_cd),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(smc0_nor),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(smc0_nor_cs1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(smc0_nor_addr25),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(smc0_nand),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_3),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_4),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_5),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_6),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_7),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_8),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_9),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can0_10),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_3),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_4),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_5),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_6),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_7),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_8),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_9),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_10),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(can1_11),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_3),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_4),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_5),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_6),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_7),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_8),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_9),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart0_10),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_3),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_4),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_5),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_6),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_7),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_8),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_9),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_10),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(uart1_11),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_3),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_4),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_5),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_6),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_7),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_8),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_9),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c0_10),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_3),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_4),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_5),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_6),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_7),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_8),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_9),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(i2c1_10),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(ttc0_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(ttc0_1),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(ttc0_2),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(ttc1_0),
> > > + DEFINE_ZYNQ_PINCTRL_GRP(ttc1_1),
> > > + 

Re: [PATCH V3 1/2] mm: Update generic gup implementation to handle hugepage directory

[Michael Ellerman]

On Tue, 2014-10-28 at 10:44 +, Steve Capper wrote:
> On Mon, Oct 27, 2014 at 06:32:41PM -0700, Andrew Morton wrote:
> > On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman  
> > wrote:
> > 
> > > On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote:
> > > > On Sat, 25 Oct 2014 16:14:19 +0530 "Aneesh Kumar K.V" 
> > > >  wrote:
> > > > 
> > > > > Update generic gup implementation with powerpc specific details.
> > > > > On powerpc at pmd level we can have hugepte, normal pmd pointer
> > > > > or a pointer to the hugepage directory.
> > > > 
> > > > I grabbed these.  It would be better if they were merged into the 
> > > > powerpc
> > > > tree where they'll get more testing than in linux-next alone.
> > >  
> > > Fine by me. Can I get an ack from you and/or someone else on CC?
> > 
> > Only arm and arm64 use this code.  Steve, could you please look it over
> > and check that arm is still happy?
> 
> Hi Andrew,
> I've tested it and posted some comments on it.
> 
> If the arch/arm and arch/arm64 changes are removed and a comment about
> an assumption made by the new gup_huge_pte code is added then I'm happy.

OK thanks Steve.

Aneesh can you do those changes and resend and I'll put it in powerpc next.

cheers


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

Re: [PATCH v2] ARM: dts: rockchip: use internal pull-up resistors on I2C busses

[Doug Anderson]

Julien,

On Tue, Oct 28, 2014 at 3:36 AM, Julien CHAUVEAU
 wrote:
> According to the I2C bus specification, it is required to use pull-up 
> resistors
> on the clock and data lines. Probing the I2C busses with i2cdetect results in
> bad results when no devices are connected and no external resistors are used.
>
> This patch configures the I2C busses to use the internal pull-up resistors
> on the RK3066, RK3188 and RK3288 Rockchip processors. It should also be noted
> that these default pull settings match the original configuration on these 
> SoCs.
>
> Below is the results of using i2cdetect on a I2C bus with no devices connected
> before (1) and after (2) applying this patch.
>
> (1) root@localhost:~# i2cdetect -y 3
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
> 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
> 30: -- -- -- -- -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x81, state: 2
> -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 2
> -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 2
> -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
> -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
> -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
> ...
>
> (2) root@localhost:~# i2cdetect -y 3
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> Signed-off-by: Julien CHAUVEAU 
> ---
> Changes since v1:
> - fix the rk3066a pull settings (only available is pull_none/pull_default)
> - remove the warnings in the results of i2cdetect
>
>  arch/arm/boot/dts/rk3066a.dtsi | 20 ++--
>  arch/arm/boot/dts/rk3188.dtsi  | 20 ++--
>  arch/arm/boot/dts/rk3288.dtsi  | 24 
>  3 files changed, 32 insertions(+), 32 deletions(-)

I won't NAK this change myself, but I have to say I'm not a huge fan.
On exynos boards the i2c has pulls by default, so there is precedent
for what you're proposing at least.

...but I'll also say that most sane boards have external pulls on i2c
and don't rely on the internal pulls.  If you've got a board where the
internal pull works well enough (lucky you!) then I think you should
override the pinctrl for just that board.

You are arguing that the internal pull "can't hurt".  I have past
experience that shows that not to be the case.  Here's an old change
for the Samsung ARM Chromebook:

https://chromium-review.googlesource.com/#/c/26607/

You probably can't dig into the bug link due to permissions, but I can
paste some of that in:

---

On Daisy / Snow we've got a NXP HDMI level converter on i2c2.  That
part has its own internal pullups.

Ideally it shouldn't hurt for us to also have the exynos's (weak) 400K
pullups on for the line too.  But according to our EE, we're just
barely within spec and so turning off the exynos pullups makes sense.

Specifically, the problem is the data line when the external HDMI
device is driving low.  The NXP chip doesn't manage to drive the data
line all the way low.  Measured on one board:
* If exynos has pullup: "low" is 560mV
* If exynos has no pull: "low" is 518mV
* If exynos has pulldown: "low" is 490mV

Low should really be 0, but exynos allows .3*VDD (or 540mV).


We should disable pullups in both the kernel and in U-Boot.  There's
even a chance that we'd want to enable pulldowns.


Note that to read EDID at all you need to also remove the strong
external pullups.

---

I did put your patch in my rk3288 board and it booted up OK, but I'm
not setup to test HDMI right now.

In v1 I think Addy said he was having trouble with HDMI and the
internal pulls on some board, so maybe he had a similar experience to
mine on snow.

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

Re: [PATCH] Input: max77693-haptic - fix potential overflow

[Chanwoo Choi]

On 10/29/2014 01:43 AM, Dmitry Torokhov wrote:
> Expression haptic->pwm_dev->period * haptic->magnitude is of type 'unsigned
> int' and may overflow. We need to convert one of the operands to u64 before
> multiplying, instead of casting result (potentially overflown) to u64.
> 
> Reported by Coverity: CID 1248753
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/input/misc/max77693-haptic.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/misc/max77693-haptic.c 
> b/drivers/input/misc/max77693-haptic.c
> index 7b1fde9..ef6a9d6 100644
> --- a/drivers/input/misc/max77693-haptic.c
> +++ b/drivers/input/misc/max77693-haptic.c
> @@ -194,7 +194,7 @@ static int max77693_haptic_play_effect(struct input_dev 
> *dev, void *data,
>  struct ff_effect *effect)
>  {
>   struct max77693_haptic *haptic = input_get_drvdata(dev);
> - uint64_t period_mag_multi;
> + u64 period_mag_multi;
>  
>   haptic->magnitude = effect->u.rumble.strong_magnitude;
>   if (!haptic->magnitude)
> @@ -205,8 +205,7 @@ static int max77693_haptic_play_effect(struct input_dev 
> *dev, void *data,
>* The formula to convert magnitude to pwm_duty as follows:
>* - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0x)
>*/
> - period_mag_multi = (int64_t)(haptic->pwm_dev->period *
> - haptic->magnitude);
> + period_mag_multi = (u64)haptic->pwm_dev->period * haptic->magnitude;
>   haptic->pwm_duty = (unsigned int)(period_mag_multi >>
>   MAX_MAGNITUDE_SHIFT);
>  
> 

Looks good to me.

Reviewed-by: Chanwoo Choi 

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

Re: [PATCH] mm: Avoid overlap the fixmap area on i386

[Minfei Huang]

On 10/28/14 at 08:14pm, H. Peter Anvin wrote:
> On 10/28/2014 10:29 AM, Thomas Gleixner wrote:
> > On Tue, 28 Oct 2014, H. Peter Anvin wrote:
> >> On 10/28/2014 04:06 AM, Thomas Gleixner wrote:
> 
>  The available address we can use is lower than FIXADDR_BOOT_START. So
>  We will set the kmap boundary below the FIXADDR_BOOT_START, if configure
>  the high memory.
> 
>  If we configure the high memory, the vmalloc reserve area should end
>  up to PKMAP_BASE, otherwise should end up to FIXADDR_BOOT_START.
> >>>
> >>> Which is not really a problem, because the FIXADDR_BOOT area is only
> >>> used during boot for early_ioremap() and it's unused when ioremap() is
> >>> functional. vmalloc becomes available after early boot so the
> >>> FIXADDR_BOOT area is available for reuse.
> >>>
> >>
> >> Given the very limited address space available on i386, it would be
> >> extremely undesirable to not reuse address space when possible.
> > 
> > Fair enough. Then we should do that for the highmem=y case as well.
> > 
> 
> It is probably even more important for highmem=y...
> 
>   -hpa

Agree. Maybe we can overlap the early_ioremap fix address to re-use
it. Virtual address is more precious on i386, especially when turn on the
high memory.

I will post an patch to fix it.

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

[PATCH 01/02] staging:lustre:lnet:selftest: fix sparse warnings

[Anton Saraev]

Fix sparse warnings: symbol X was not declared. Should it be static?
Some functions used only in files where they are declared. They can
be static.

Signed-off-by: Anton Saraev 
---
 drivers/staging/lustre/lnet/selftest/conctl.c| 34 
 drivers/staging/lustre/lnet/selftest/conrpc.c| 20 +-
 drivers/staging/lustre/lnet/selftest/framework.c | 50 
 drivers/staging/lustre/lnet/selftest/module.c|  6 +--
 drivers/staging/lustre/lnet/selftest/rpc.c   | 34 
 drivers/staging/lustre/lnet/selftest/timer.c |  8 ++--
 6 files changed, 76 insertions(+), 76 deletions(-)

diff --git a/drivers/staging/lustre/lnet/selftest/conctl.c 
b/drivers/staging/lustre/lnet/selftest/conctl.c
index ae7b0fc..5bc6153 100644
--- a/drivers/staging/lustre/lnet/selftest/conctl.c
+++ b/drivers/staging/lustre/lnet/selftest/conctl.c
@@ -45,7 +45,7 @@
 #include "../../include/linux/lnet/lnetst.h"
 #include "console.h"
 
-int
+static int
 lst_session_new_ioctl(lstio_session_new_args_t *args)
 {
char  *name;
@@ -82,7 +82,7 @@ lst_session_new_ioctl(lstio_session_new_args_t *args)
return rc;
 }
 
-int
+static int
 lst_session_end_ioctl(lstio_session_end_args_t *args)
 {
if (args->lstio_ses_key != console_session.ses_key)
@@ -91,7 +91,7 @@ lst_session_end_ioctl(lstio_session_end_args_t *args)
return lstcon_session_end();
 }
 
-int
+static int
 lst_session_info_ioctl(lstio_session_info_args_t *args)
 {
/* no checking of key */
@@ -113,7 +113,7 @@ lst_session_info_ioctl(lstio_session_info_args_t *args)
   args->lstio_ses_nmlen);
 }
 
-int
+static int
 lst_debug_ioctl(lstio_debug_args_t *args)
 {
char   *name   = NULL;
@@ -194,7 +194,7 @@ out:
return rc;
 }
 
-int
+static int
 lst_group_add_ioctl(lstio_group_add_args_t *args)
 {
char   *name;
@@ -228,7 +228,7 @@ lst_group_add_ioctl(lstio_group_add_args_t *args)
return rc;
 }
 
-int
+static int
 lst_group_del_ioctl(lstio_group_del_args_t *args)
 {
int rc;
@@ -262,7 +262,7 @@ lst_group_del_ioctl(lstio_group_del_args_t *args)
return rc;
 }
 
-int
+static int
 lst_group_update_ioctl(lstio_group_update_args_t *args)
 {
int rc;
@@ -320,7 +320,7 @@ lst_group_update_ioctl(lstio_group_update_args_t *args)
return rc;
 }
 
-int
+static int
 lst_nodes_add_ioctl(lstio_group_nodes_args_t *args)
 {
unsigned feats;
@@ -365,7 +365,7 @@ lst_nodes_add_ioctl(lstio_group_nodes_args_t *args)
return rc;
 }
 
-int
+static int
 lst_group_list_ioctl(lstio_group_list_args_t *args)
 {
if (args->lstio_grp_key != console_session.ses_key)
@@ -382,7 +382,7 @@ lst_group_list_ioctl(lstio_group_list_args_t *args)
  args->lstio_grp_namep);
 }
 
-int
+static int
 lst_group_info_ioctl(lstio_group_info_args_t *args)
 {
char   *name;
@@ -446,7 +446,7 @@ lst_group_info_ioctl(lstio_group_info_args_t *args)
return 0;
 }
 
-int
+static int
 lst_batch_add_ioctl(lstio_batch_add_args_t *args)
 {
int  rc;
@@ -480,7 +480,7 @@ lst_batch_add_ioctl(lstio_batch_add_args_t *args)
return rc;
 }
 
-int
+static int
 lst_batch_run_ioctl(lstio_batch_run_args_t *args)
 {
int  rc;
@@ -515,7 +515,7 @@ lst_batch_run_ioctl(lstio_batch_run_args_t *args)
return rc;
 }
 
-int
+static int
 lst_batch_stop_ioctl(lstio_batch_stop_args_t *args)
 {
int  rc;
@@ -551,7 +551,7 @@ lst_batch_stop_ioctl(lstio_batch_stop_args_t *args)
return rc;
 }
 
-int
+static int
 lst_batch_query_ioctl(lstio_batch_query_args_t *args)
 {
char   *name;
@@ -593,7 +593,7 @@ lst_batch_query_ioctl(lstio_batch_query_args_t *args)
return rc;
 }
 
-int
+static int
 lst_batch_list_ioctl(lstio_batch_list_args_t *args)
 {
if (args->lstio_bat_key != console_session.ses_key)
@@ -610,7 +610,7 @@ lst_batch_list_ioctl(lstio_batch_list_args_t *args)
  args->lstio_bat_namep);
 }
 
-int
+static int
 lst_batch_info_ioctl(lstio_batch_info_args_t *args)
 {
char   *name;
@@ -675,7 +675,7 @@ lst_batch_info_ioctl(lstio_batch_info_args_t *args)
return rc;
 }
 
-int
+static int
 lst_stat_query_ioctl(lstio_stat_args_t *args)
 {
int  rc;
diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.c 
b/drivers/staging/lustre/lnet/selftest/conrpc.c
index a3a60d6..b0d 100644
--- a/drivers/staging/lustre/lnet/selftest/conrpc.c
+++ b/drivers/staging/lustre/lnet/selftest/conrpc.c
@@ -88,7 +88,7 @@ lstcon_rpc_done(srpc_client_rpc_t *rpc)
spin_unlock(>crpc_lock);
 }
 
-int
+static int
 lstcon_rpc_init(lstcon_node_t *nd, int service, unsigned feats,
int bulk_npg, int bulk_len, int embedded, lstcon_rpc_t *crpc)
 {
@@ -113,7 +113,7 @@ lstcon_rpc_init(lstcon_node_t *nd, int service, unsigned 
feats,
return 0;
 }
 
-int
+static int
 

[PATCH 02/02] staging:lustre:lnet:selftest: remove unused function

[Anton Saraev]

Function lnet_selftest_structure_assertion is never used and can
be removed.

Signed-off-by: Anton Saraev 
---
 drivers/staging/lustre/lnet/selftest/module.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/staging/lustre/lnet/selftest/module.c 
b/drivers/staging/lustre/lnet/selftest/module.c
index 718663f..92520c2 100644
--- a/drivers/staging/lustre/lnet/selftest/module.c
+++ b/drivers/staging/lustre/lnet/selftest/module.c
@@ -90,17 +90,6 @@ lnet_selftest_fini(void)
return;
 }
 
-static void
-lnet_selftest_structure_assertion(void)
-{
-   CLASSERT(sizeof(srpc_msg_t) == 160);
-   CLASSERT(sizeof(srpc_test_reqst_t) == 70);
-   CLASSERT(offsetof(srpc_msg_t, msg_body.tes_reqst.tsr_concur) == 72);
-   CLASSERT(offsetof(srpc_msg_t, msg_body.tes_reqst.tsr_ndest) == 78);
-   CLASSERT(sizeof(srpc_stat_reply_t) == 136);
-   CLASSERT(sizeof(srpc_stat_reqst_t) == 28);
-}
-
 static int
 lnet_selftest_init(void)
 {
-- 
1.9.1

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

[PATCH 00/02] staging:lustre:lnet:selftest: fix sparse warnings

[Anton Saraev]

Patch fix simple sparse warnings: make functions static and remove
unused code. I'm doing only little testing: module was loaded properly,
output of lst without real server is the same as before.

Anton Saraev (2):
  staging:lustre:lnet:selftest: fix sparse warnings
  staging:lustre:lnet:selftest: remove unused function

 drivers/staging/lustre/lnet/selftest/conctl.c| 34 
 drivers/staging/lustre/lnet/selftest/conrpc.c| 20 +-
 drivers/staging/lustre/lnet/selftest/framework.c | 50 
 drivers/staging/lustre/lnet/selftest/module.c| 15 +--
 drivers/staging/lustre/lnet/selftest/rpc.c   | 34 
 drivers/staging/lustre/lnet/selftest/timer.c |  8 ++--
 6 files changed, 75 insertions(+), 86 deletions(-)

-- 
1.9.1

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

linux-next: Tree for Oct 29

[Stephen Rothwell]

Hi all,

Changes since 20141028:

The usb-gadget-fixes tree gained a build failure so I used the version
from next-20141028.

The net-next tree gained a conflict against the net tree.

The bluetooth tree lost its build failure.

The pinctrl tree lost its build failure.

Non-merge commits (relative to Linus' tree): 2294
 2027 files changed, 59475 insertions(+), 62762 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 227 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (9f76628da20f Merge branch 'for-3.18' of 
git://linux-nfs.org/~bfields/linux)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (178c3dfe853a ARM: fix some printk formats)
Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/fixes (eb01d4c2388c cxl: Fix PSL error due to 
duplicate segment table entries)
Merging sparc/master (c20ce79303c7 sparc: Hook up bpf system call.)
Merging net/master (068301f2be36 Merge branch 'cdc-ether')
Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes')
Merging sound-current/for-linus (317168d0c766 ALSA: pcm: Zero-clear reserved 
fields of PCM status ioctl in compat mode)
Merging pci-current/for-linus (c302d35eac32 Revert duplicate "PCI: pciehp: 
Prevent NULL dereference during probe")
Merging wireless/master (99c814066e75 Merge tag 'mac80211-for-john-2014-10-23' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging driver-core.current/driver-core-linus (cac7f2429872 Linux 3.18-rc2)
Merging tty.current/tty-linus (cac7f2429872 Linux 3.18-rc2)
Merging usb.current/usb-linus (9680b60ed79e usb: chipidea: Fix oops when 
removing the ci_hdrc module)
Merging usb-gadget-fixes/fixes (9f2104db1295 usb: dwc2: gadget: fix calls to 
phy control functions in suspend/resume code)
$ git reset --hard HEAD^
Merging next-20141028 version of usb-gadget-fixes
Merging usb-serial-fixes/usb-linus (7f2719f0003d usb: serial: ftdi_sio: add 
"bricked" FTDI device PID)
Merging staging.current/staging-linus (7e74783a9db7 Merge tag 
'iio-fixes-for-3.18a' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (cac7f2429872 Linux 3.18-rc2)
Merging input-current/for-linus (185af4d6668e Input: psmouse - remove unneeded 
check in psmouse_reconnect())
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (09adc8789c4e crypto: qat - Enforce valid numa 
configuration)
Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL 
dereference in selftest removal code)
Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip reading when we start to 
remove the device)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/

[PATCH 02/11] irqchip: brcmstb-l2: Eliminate dependency on ARM code

[Kevin Cernekee]

The irq-brcmstb-l2 driver has a single dependency on the ARM code, the
do_bad_IRQ macro.  Expand this macro in-place so that the driver can be
built on non-ARM platforms.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-brcmstb-l2.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index c15c840..c9bdf20 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,8 +31,6 @@
 #include 
 #include 
 
-#include 
-
 #include "irqchip.h"
 
 /* Register offsets in the L2 interrupt controller */
@@ -63,7 +62,9 @@ static void brcmstb_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
~(__raw_readl(b->base + CPU_MASK_STATUS));
 
if (status == 0) {
-   do_bad_IRQ(irq, desc);
+   raw_spin_lock(>lock);
+   handle_bad_irq(irq, desc);
+   raw_spin_unlock(>lock);
goto out;
}
 
-- 
2.1.1

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

[PATCH 05/11] irqchip: bcm7120-l2: Make sure all register accesses use base+offset

[Kevin Cernekee]

A couple of accesses to IRQEN (base+0x00) just used "base" directly, so
they would break if IRQEN ever became nonzero.  Make sure that all
reads/writes specify the register offset constant.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 49d8f3d..6472b71 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -66,10 +66,10 @@ static void bcm7120_l2_intc_suspend(struct irq_data *d)
 
irq_gc_lock(gc);
/* Save the current mask and the interrupt forward mask */
-   b->saved_mask = __raw_readl(b->base) | b->irq_fwd_mask;
+   b->saved_mask = __raw_readl(b->base + IRQEN) | b->irq_fwd_mask;
if (b->can_wake) {
reg = b->saved_mask | gc->wake_active;
-   __raw_writel(reg, b->base);
+   __raw_writel(reg, b->base + IRQEN);
}
irq_gc_unlock(gc);
 }
@@ -81,7 +81,7 @@ static void bcm7120_l2_intc_resume(struct irq_data *d)
 
/* Restore the saved mask */
irq_gc_lock(gc);
-   __raw_writel(b->saved_mask, b->base);
+   __raw_writel(b->saved_mask, b->base + IRQEN);
irq_gc_unlock(gc);
 }
 
-- 
2.1.1

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

[PATCH 06/11] irqchip: bcm7120-l2: Use irq_reg_* accessors

[Kevin Cernekee]

This keeps things consistent between the "core" bcm7120-l2 driver and the
helpers in generic-chip.c.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 6472b71..f041992 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -48,7 +48,7 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
 
chained_irq_enter(chip, desc);
 
-   status = __raw_readl(b->base + IRQSTAT);
+   status = irq_reg_readl(b->base + IRQSTAT);
do {
irq = ffs(status) - 1;
status &= ~(1 << irq);
@@ -66,10 +66,10 @@ static void bcm7120_l2_intc_suspend(struct irq_data *d)
 
irq_gc_lock(gc);
/* Save the current mask and the interrupt forward mask */
-   b->saved_mask = __raw_readl(b->base + IRQEN) | b->irq_fwd_mask;
+   b->saved_mask = irq_reg_readl(b->base + IRQEN) | b->irq_fwd_mask;
if (b->can_wake) {
reg = b->saved_mask | gc->wake_active;
-   __raw_writel(reg, b->base + IRQEN);
+   irq_reg_writel(reg, b->base + IRQEN);
}
irq_gc_unlock(gc);
 }
@@ -81,7 +81,7 @@ static void bcm7120_l2_intc_resume(struct irq_data *d)
 
/* Restore the saved mask */
irq_gc_lock(gc);
-   __raw_writel(b->saved_mask, b->base + IRQEN);
+   irq_reg_writel(b->saved_mask, b->base + IRQEN);
irq_gc_unlock(gc);
 }
 
@@ -133,7 +133,7 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
/* Enable all interrupt specified in the interrupt forward mask and have
 * the other disabled
 */
-   __raw_writel(data->irq_fwd_mask, data->base + IRQEN);
+   irq_reg_writel(data->irq_fwd_mask, data->base + IRQEN);
 
num_parent_irqs = of_irq_count(dn);
if (num_parent_irqs <= 0) {
-- 
2.1.1

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

[PATCH 03/11] irqchip: bcm7120-l2: Eliminate bad IRQ check

[Kevin Cernekee]

This check may be prone to race conditions, e.g.

1) Some external event (e.g. GPIO level) causes an IRQ to become pending
2) Peripheral asserts the L2 IRQ
3) CPU takes an interrupt
4) The event from #1 goes away
5) bcm7120_l2_intc_irq_handle() reads back a 0 status

Unlike the hardware supported by brcmstb-l2, the bcm7120-l2 controller
does not latch the IRQ status.  Bits can change if the inputs to the
controller change.  Also, do_bad_IRQ() is an ARM-specific macro.

So let's just nuke it.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index b9f4fb8..49d8f3d 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -27,8 +27,6 @@
 
 #include "irqchip.h"
 
-#include 
-
 /* Register offset in the L2 interrupt controller */
 #define IRQEN  0x00
 #define IRQSTAT0x04
@@ -51,19 +49,12 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
chained_irq_enter(chip, desc);
 
status = __raw_readl(b->base + IRQSTAT);
-
-   if (status == 0) {
-   do_bad_IRQ(irq, desc);
-   goto out;
-   }
-
do {
irq = ffs(status) - 1;
status &= ~(1 << irq);
generic_handle_irq(irq_find_mapping(b->domain, irq));
} while (status);
 
-out:
chained_irq_exit(chip, desc);
 }
 
-- 
2.1.1

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

[PATCH 04/11] irqchip: Remove ARM dependency for bcm7120-l2 and brcmstb-l2

[Kevin Cernekee]

This can compile for MIPS (or anything else) now.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 6f0e80b..6a03c65 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -53,7 +53,6 @@ config ATMEL_AIC5_IRQ
 
 config BRCMSTB_L2_IRQ
bool
-   depends on ARM
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
-- 
2.1.1

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

[PATCH 08/11] irqchip: bcm7120-l2: Fix missing nibble in gc->unused mask

[Kevin Cernekee]

This mask should have been 0x_, not 0x0fff_.

The change should not have an effect on current users (STB) because bits
31:27 are unused.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index f041992..e9331f8 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -171,7 +171,7 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
}
 
gc = irq_get_domain_generic_chip(data->domain, 0);
-   gc->unused = 0xfff & ~data->irq_map_mask;
+   gc->unused = 0x & ~data->irq_map_mask;
gc->reg_base = data->base;
gc->private = data;
ct = gc->chip_types;
-- 
2.1.1

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

[PATCH 09/11] irqchip: bcm7120-l2: Use gc->mask_cache to simplify suspend/resume functions

[Kevin Cernekee]

The cached value already incorporates irq_fwd_mask, and was saved the
last time an IRQ was enabled/disabled.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index e9331f8..c76c9ad 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -37,7 +37,6 @@ struct bcm7120_l2_intc_data {
bool can_wake;
u32 irq_fwd_mask;
u32 irq_map_mask;
-   u32 saved_mask;
 };
 
 static void bcm7120_l2_intc_irq_handle(unsigned int irq, struct irq_desc *desc)
@@ -62,14 +61,11 @@ static void bcm7120_l2_intc_suspend(struct irq_data *d)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct bcm7120_l2_intc_data *b = gc->private;
-   u32 reg;
 
irq_gc_lock(gc);
-   /* Save the current mask and the interrupt forward mask */
-   b->saved_mask = irq_reg_readl(b->base + IRQEN) | b->irq_fwd_mask;
if (b->can_wake) {
-   reg = b->saved_mask | gc->wake_active;
-   irq_reg_writel(reg, b->base + IRQEN);
+   irq_reg_writel(gc->mask_cache | gc->wake_active,
+  b->base + IRQEN);
}
irq_gc_unlock(gc);
 }
@@ -77,11 +73,10 @@ static void bcm7120_l2_intc_suspend(struct irq_data *d)
 static void bcm7120_l2_intc_resume(struct irq_data *d)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-   struct bcm7120_l2_intc_data *b = gc->private;
 
/* Restore the saved mask */
irq_gc_lock(gc);
-   irq_reg_writel(b->saved_mask, b->base + IRQEN);
+   irq_reg_writel(gc->mask_cache, b->base + IRQEN);
irq_gc_unlock(gc);
 }
 
-- 
2.1.1

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

[PATCH 11/11] irqchip: Decouple bcm7120-l2 from brcmstb-l2

[Kevin Cernekee]

Some chips, such as BCM6328, only require the former driver.  Some
BCM7xxx STB configurations only require the latter driver.  Treat them
as two separate entities, and update the mach-bcm dependencies to
reflect the change.

Signed-off-by: Kevin Cernekee 
---
 arch/arm/mach-bcm/Kconfig| 1 +
 drivers/irqchip/Kconfig  | 5 +
 drivers/irqchip/Makefile | 4 ++--
 drivers/irqchip/irq-bcm7120-l2.c | 2 +-
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 2abad74..bf47eb0 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -125,6 +125,7 @@ config ARCH_BRCMSTB
select HAVE_ARM_ARCH_TIMER
select BRCMSTB_GISB_ARB
select BRCMSTB_L2_IRQ
+   select BCM7120_L2_IRQ
help
  Say Y if you intend to run the kernel on a Broadcom ARM-based STB
  chipset.
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 6a03c65..2d52b07 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -51,6 +51,11 @@ config ATMEL_AIC5_IRQ
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
 
+config BCM7120_L2_IRQ
+   bool
+   select GENERIC_IRQ_CHIP
+   select IRQ_DOMAIN
+
 config BRCMSTB_L2_IRQ
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 173bb5f..f0909d0 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -35,6 +35,6 @@ obj-$(CONFIG_TB10X_IRQC)  += irq-tb10x.o
 obj-$(CONFIG_XTENSA)   += irq-xtensa-pic.o
 obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
 obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
-obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o \
-  irq-bcm7120-l2.o
+obj-$(CONFIG_BCM7120_L2_IRQ)   += irq-bcm7120-l2.o
+obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o
 obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 734fece..91065b9 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -247,5 +247,5 @@ out_unmap:
kfree(data);
return ret;
 }
-IRQCHIP_DECLARE(brcmstb_l2_intc, "brcm,bcm7120-l2-intc",
+IRQCHIP_DECLARE(bcm7120_l2_intc, "brcm,bcm7120-l2-intc",
bcm7120_l2_intc_of_init);
-- 
2.1.1

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

[PATCH 07/11] irqchip: brcmstb-l2: Use irq_reg_* accessors

[Kevin Cernekee]

This change was just made on bcm7120-l2, so let's keep things consistent
between the two drivers.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-brcmstb-l2.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index c9bdf20..8b82b86 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -58,8 +58,8 @@ static void brcmstb_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
 
chained_irq_enter(chip, desc);
 
-   status = __raw_readl(b->base + CPU_STATUS) &
-   ~(__raw_readl(b->base + CPU_MASK_STATUS));
+   status = irq_reg_readl(b->base + CPU_STATUS) &
+   ~(irq_reg_readl(b->base + CPU_MASK_STATUS));
 
if (status == 0) {
raw_spin_lock(>lock);
@@ -71,7 +71,7 @@ static void brcmstb_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
do {
irq = ffs(status) - 1;
/* ack at our level */
-   __raw_writel(1 << irq, b->base + CPU_CLEAR);
+   irq_reg_writel(1 << irq, b->base + CPU_CLEAR);
status &= ~(1 << irq);
generic_handle_irq(irq_find_mapping(b->domain, irq));
} while (status);
@@ -86,12 +86,12 @@ static void brcmstb_l2_intc_suspend(struct irq_data *d)
 
irq_gc_lock(gc);
/* Save the current mask */
-   b->saved_mask = __raw_readl(b->base + CPU_MASK_STATUS);
+   b->saved_mask = irq_reg_readl(b->base + CPU_MASK_STATUS);
 
if (b->can_wake) {
/* Program the wakeup mask */
-   __raw_writel(~gc->wake_active, b->base + CPU_MASK_SET);
-   __raw_writel(gc->wake_active, b->base + CPU_MASK_CLEAR);
+   irq_reg_writel(~gc->wake_active, b->base + CPU_MASK_SET);
+   irq_reg_writel(gc->wake_active, b->base + CPU_MASK_CLEAR);
}
irq_gc_unlock(gc);
 }
@@ -103,11 +103,11 @@ static void brcmstb_l2_intc_resume(struct irq_data *d)
 
irq_gc_lock(gc);
/* Clear unmasked non-wakeup interrupts */
-   __raw_writel(~b->saved_mask & ~gc->wake_active, b->base + CPU_CLEAR);
+   irq_reg_writel(~b->saved_mask & ~gc->wake_active, b->base + CPU_CLEAR);
 
/* Restore the saved mask */
-   __raw_writel(b->saved_mask, b->base + CPU_MASK_SET);
-   __raw_writel(~b->saved_mask, b->base + CPU_MASK_CLEAR);
+   irq_reg_writel(b->saved_mask, b->base + CPU_MASK_SET);
+   irq_reg_writel(~b->saved_mask, b->base + CPU_MASK_CLEAR);
irq_gc_unlock(gc);
 }
 
@@ -132,8 +132,8 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
}
 
/* Disable all interrupts by default */
-   __raw_writel(0x, data->base + CPU_MASK_SET);
-   __raw_writel(0x, data->base + CPU_CLEAR);
+   irq_reg_writel(0x, data->base + CPU_MASK_SET);
+   irq_reg_writel(0x, data->base + CPU_CLEAR);
 
data->parent_irq = irq_of_parse_and_map(np, 0);
if (data->parent_irq < 0) {
-- 
2.1.1

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

[PATCH 01/11] irqchip: Allow irq_reg_{readl,writel} to use __raw_{readl_writel}

[Kevin Cernekee]

On big-endian systems readl/writel may perform an unwanted endian swap,
breaking generic-chip.c.  Let the platform code opt to use the __raw_
variants by selecting RAW_IRQ_ACCESSORS.

This is required in order for bcm3384 to use GENERIC_IRQ_CHIP.  Several
existing irqchip drivers also use the __raw_ accessors directly, so it
is a reasonably common requirement.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/Kconfig |  3 +++
 include/linux/irq.h | 13 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b21f12f..6f0e80b 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -2,6 +2,9 @@ config IRQCHIP
def_bool y
depends on OF_IRQ
 
+config RAW_IRQ_ACCESSORS
+   bool
+
 config ARM_GIC
bool
select IRQ_DOMAIN
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 03f48d9..ed1ea8a 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -639,6 +639,17 @@ void arch_teardown_hwirq(unsigned int irq);
 void irq_init_desc(unsigned int irq);
 #endif
 
+#ifdef CONFIG_RAW_IRQ_ACCESSORS
+
+#ifndef irq_reg_writel
+# define irq_reg_writel(val, addr) __raw_writel(val, addr)
+#endif
+#ifndef irq_reg_readl
+# define irq_reg_readl(addr)   __raw_readl(addr)
+#endif
+
+#else
+
 #ifndef irq_reg_writel
 # define irq_reg_writel(val, addr) writel(val, addr)
 #endif
@@ -646,6 +657,8 @@ void irq_init_desc(unsigned int irq);
 # define irq_reg_readl(addr)   readl(addr)
 #endif
 
+#endif
+
 /**
  * struct irq_chip_regs - register offsets for struct irq_gci
  * @enable:Enable register offset to reg_base
-- 
2.1.1

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

[PATCH 10/11] irqchip: bcm7120-l2: Extend driver to support 64+ bit controllers

[Kevin Cernekee]

Most implementations of the bcm7120-l2 controller only have a single
32-bit enable word + 32-bit status word.  But some instances have added
more enable/status pairs in order to support 64+ IRQs (which are all
ORed into one parent IRQ input).  Make the following changes to allow
the driver to support this:

 - Extend DT bindings so that multiple words can be specified for the
   reg property, various masks, etc.

 - Add loops to the probe/handle functions to deal with each word
   separately

 - Allocate 1 generic-chip for every 32 IRQs, so we can still use the
   clr/set helper functions

 - Update the documentation

Signed-off-by: Kevin Cernekee 
---
 .../interrupt-controller/brcm,bcm7120-l2-intc.txt  |  26 ++--
 drivers/irqchip/irq-bcm7120-l2.c   | 146 ++---
 2 files changed, 114 insertions(+), 58 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
index ff812a8..bae1f21 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
@@ -13,7 +13,12 @@ Such an interrupt controller has the following hardware 
design:
   or if they will output an interrupt signal at this 2nd level interrupt
   controller, in particular for UARTs
 
-- not all 32-bits within the interrupt controller actually map to an interrupt
+- typically has one 32-bit enable word and one 32-bit status word, but on
+  some hardware may have more than one enable/status pair
+
+- no atomic set/clear operations
+
+- not all bits within the interrupt controller actually map to an interrupt
 
 The typical hardware layout for this controller is represented below:
 
@@ -48,7 +53,9 @@ The typical hardware layout for this controller is 
represented below:
 Required properties:
 
 - compatible: should be "brcm,bcm7120-l2-intc"
-- reg: specifies the base physical address and size of the registers
+- reg: specifies the base physical address and size of the registers;
+  multiple pairs may be specified, with the first pair handling IRQ offsets
+  0..31 and the second pair handling 32..63
 - interrupt-controller: identifies the node as an interrupt controller
 - #interrupt-cells: specifies the number of cells needed to encode an interrupt
   source, should be 1.
@@ -59,18 +66,21 @@ Required properties:
 - brcm,int-map-mask: 32-bits bit mask describing how many and which interrupts
   are wired to this 2nd level interrupt controller, and how they match their
   respective interrupt parents. Should match exactly the number of interrupts
-  specified in the 'interrupts' property.
+  specified in the 'interrupts' property, multiplied by the number of
+  enable/status register pairs implemented by this controller.  For
+  multiple parent IRQs with multiple enable/status words, this looks like:
+  
 
 Optional properties:
 
 - brcm,irq-can-wake: if present, this means the L2 controller can be used as a
   wakeup source for system suspend/resume.
 
-- brcm,int-fwd-mask: if present, a 32-bits bit mask to configure for the
-  interrupts which have a mux gate, typically UARTs. Setting these bits will
-  make their respective interrupts outputs bypass this 2nd level interrupt
-  controller completely, it completely transparent for the interrupt controller
-  parent
+- brcm,int-fwd-mask: if present, a bit mask to configure the interrupts which
+  have a mux gate, typically UARTs. Setting these bits will make their
+  respective interrupt outputs bypass this 2nd level interrupt controller
+  completely; it is completely transparent for the interrupt controller
+  parent. This should have one 32-bit word per enable/status pair.
 
 Example:
 
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index c76c9ad..734fece 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "irqchip.h"
@@ -31,28 +32,43 @@
 #define IRQEN  0x00
 #define IRQSTAT0x04
 
+#define MAX_WORDS  4
+#define IRQS_PER_WORD  32
+
 struct bcm7120_l2_intc_data {
-   void __iomem *base;
+   unsigned int n_words;
+   void __iomem *base[MAX_WORDS];
struct irq_domain *domain;
bool can_wake;
-   u32 irq_fwd_mask;
-   u32 irq_map_mask;
+   u32 irq_fwd_mask[MAX_WORDS];
+   u32 irq_map_mask[MAX_WORDS];
 };
 
 static void bcm7120_l2_intc_irq_handle(unsigned int irq, struct irq_desc *desc)
 {
struct bcm7120_l2_intc_data *b = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
-   u32 status;
+   unsigned int idx;
 
chained_irq_enter(chip, desc);
 
-   status = irq_reg_readl(b->base + IRQSTAT);
-   do {
-   irq = ffs(status) - 1;
-   

[GIT PULL] Fix for Integrity subsystem null pointer deref

[James Morris]

These changes fix a bug in xattr handling, where the evm and ima 
inode_setxattr() functions do not check for empty xattrs being passed from 
userspace (leading to user-triggerable null pointer dereferences).

Please pull.


The following changes since commit 9f76628da20f96a179ca62b504886f99ecc29223:

  Merge branch 'for-3.18' of git://linux-nfs.org/~bfields/linux (2014-10-28 
13:32:06 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus

Dmitry Kasatkin (2):
  ima: check xattr value length and type in the ima_inode_setxattr()
  evm: check xattr value length and type in evm_inode_setxattr()

James Morris (1):
  Merge branch 'for-linus' of 
git://git.kernel.org/.../zohar/linux-integrity into for-linus

 security/integrity/evm/evm_main.c |9 ++---
 security/integrity/ima/ima_appraise.c |2 ++
 security/integrity/integrity.h|1 +
 3 files changed, 9 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] audio: sai: Add Power Management support

[Alison Wang]

This patch adds Power Management support for SAI.
Activate regmap cache with REGCACHE_RBTREE, and use
regmap cache code to save and restore registers in
suspend and resume. The Transmit Control Register
(TCSR) and Receive Control Register(RCSR) should
be volatile registers.

Signed-off-by: Alison Wang 
---
 sound/soc/fsl/fsl_sai.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 7eeb1dd..c7dd953 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -509,9 +509,11 @@ static bool fsl_sai_readable_reg(struct device *dev, 
unsigned int reg)
 static bool fsl_sai_volatile_reg(struct device *dev, unsigned int reg)
 {
switch (reg) {
+   case FSL_SAI_TCSR:
case FSL_SAI_TFR:
-   case FSL_SAI_RFR:
case FSL_SAI_TDR:
+   case FSL_SAI_RCSR:
+   case FSL_SAI_RFR:
case FSL_SAI_RDR:
return true;
default:
@@ -553,6 +555,7 @@ static const struct regmap_config fsl_sai_regmap_config = {
.readable_reg = fsl_sai_readable_reg,
.volatile_reg = fsl_sai_volatile_reg,
.writeable_reg = fsl_sai_writeable_reg,
+   .cache_type = REGCACHE_RBTREE,
 };
 
 static int fsl_sai_probe(struct platform_device *pdev)
@@ -668,6 +671,33 @@ static int fsl_sai_probe(struct platform_device *pdev)
SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int fsl_sai_suspend(struct device *dev)
+{
+   struct fsl_sai *sai = dev_get_drvdata(dev);
+
+   regcache_cache_only(sai->regmap, true);
+   regcache_mark_dirty(sai->regmap);
+
+   return 0;
+}
+
+static int fsl_sai_resume(struct device *dev)
+{
+   struct fsl_sai *sai = dev_get_drvdata(dev);
+
+   /* Restore all registers */
+   regcache_cache_only(sai->regmap, false);
+   regcache_sync(sai->regmap);
+
+   return 0;
+};
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops fsl_sai_pm = {
+   SET_SYSTEM_SLEEP_PM_OPS(fsl_sai_suspend, fsl_sai_resume)
+};
+
 static const struct of_device_id fsl_sai_ids[] = {
{ .compatible = "fsl,vf610-sai", },
{ .compatible = "fsl,imx6sx-sai", },
@@ -680,6 +710,7 @@ static struct platform_driver fsl_sai_driver = {
.name = "fsl-sai",
.owner = THIS_MODULE,
.of_match_table = fsl_sai_ids,
+   .pm = _sai_pm,
},
 };
 module_platform_driver(fsl_sai_driver);
-- 
2.1.0.27.g96db324

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

[PATCH v2 2/2] ACPI/EC: Fix a regression caused by conflict firmware behavior between Samsung and Acer.

[Lv Zheng]

It is reported that Samsung laptops that need to poll events are broken by
the following commit:
 Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT 
isn't set

The behaviors of the 2 vendor firmwares are conflict:
1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware
 automatically sets SCI_EVT as long as there is event queued up.
2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware
returns 0 when there is no event queued up.

This patch is a quick fix to distinguish the behaviors to make Acer
behavior only effective for Acer EC firmware so that the breakages on
Samsung EC firmware can be avoided.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-and-tested-by: Ortwin Gl¨¹ck 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 31b699f..5f9b74b 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -126,6 +126,7 @@ static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
 static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
 static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT scan */
 static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs acpi_ec_clear() on boot/resume */
+static int EC_FLAGS_QUERY_HANDSHAKE; /* Needs QR_EC issued when SCI_EVT set */
 
 /* --
  *   Transaction Management
@@ -236,13 +237,8 @@ static bool advance_transaction(struct acpi_ec *ec)
}
return wakeup;
} else {
-   /*
-* There is firmware refusing to respond QR_EC when SCI_EVT
-* is not set, for which case, we complete the QR_EC
-* without issuing it to the firmware.
-* https://bugzilla.kernel.org/show_bug.cgi?id=86211
-*/
-   if (!(status & ACPI_EC_FLAG_SCI) &&
+   if (EC_FLAGS_QUERY_HANDSHAKE &&
+   !(status & ACPI_EC_FLAG_SCI) &&
(t->command == ACPI_EC_COMMAND_QUERY)) {
t->flags |= ACPI_EC_COMMAND_POLL;
t->rdata[t->ri++] = 0x00;
@@ -1012,6 +1008,18 @@ static int ec_enlarge_storm_threshold(const struct 
dmi_system_id *id)
 }
 
 /*
+ * Acer EC firmware refuses to respond QR_EC when SCI_EVT is not set, for
+ * which case, we complete the QR_EC without issuing it to the firmware.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=86211
+ */
+static int ec_flag_query_handshake(const struct dmi_system_id *id)
+{
+   pr_debug("Detected the EC firmware requiring QR_EC issued when SCI_EVT 
set\n");
+   EC_FLAGS_QUERY_HANDSHAKE = 1;
+   return 0;
+}
+
+/*
  * On some hardware it is necessary to clear events accumulated by the EC 
during
  * sleep. These ECs stop reporting GPEs until they are manually polled, if too
  * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
@@ -1085,6 +1093,9 @@ static struct dmi_system_id ec_dmi_table[] __initdata = {
{
ec_clear_on_resume, "Samsung hardware", {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL},
+   {
+   ec_flag_query_handshake, "Acer hardware", {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"), }, NULL},
{},
 };
 
-- 
1.7.10

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

[PATCH v2 0/2] ACPI/EC: Fix regressions on Samsung hardware.

[Lv Zheng]

It is reported that the Samsung EC firmware behaves differently than Acer
EC firmware. And then previous 2 commits that fix Acer issues have broken
Samsung hardware.

This patchset fixes the regressions.

Lv Zheng (2):
  Revert "ACPI / EC: Add support to disallow QR_EC to be issued before
completing previous QR_EC"
  ACPI/EC: Fix a regression caused by conflict firmware behavior
between Samsung and Acer.

 drivers/acpi/ec.c |   31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

-- 
1.7.10

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

[PATCH v2 1/2] Revert "ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC"

[Lv Zheng]

It is reported that the following commit breaks Samsung hardware:
 Commit: 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4.
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued before
  completing previous QR_EC

Which means the Samsung behavior conflicts with the Acer behavior.

1. Samsung may behave like:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ] SCI_EVT set
  write QR_EC
  read event
   [ -event 1 ] SCI_EVT clear
   Without the above commit, Samsung can work:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ] SCI_EVT set
  write QR_EC
  CAN prepare next QR_EC as SCI_EVT=1
  read event
   [ -event 1 ] SCI_EVT clear
  write QR_EC
  read event
   [ -event 2 ] SCI_EVT clear
   With the above commit, Samsung cannot work:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ] SCI_EVT set
  write QR_EC
  read event
   [ -event 1 ] SCI_EVT clear
  CANNOT prepare next QR_EC as SCI_EVT=0
2. Acer may behave like:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ]
  write QR_EC
  read event
   [ -event 1 ] SCI_EVT clear
   [ +event 2 ] SCI_EVT set
   Without the above commit, Acer cannot work when there is only 1 event:
   [ +event 1 ] SCI_EVT set
  write QR_EC
  can prepared next QR_EC as SCI_EVT=1
  read event
   [ -event 1 ] SCI_EVT clear
  CANNOT write QR_EC as SCI_EVT=0
   With the above commit, Acer can work:
   [ +event 1 ] SCI_EVT set
   [ +event 2 ]
  write QR_EC
  read event
   [ -event 1 ] SCI_EVT set
  can prepare next QR_EC because SCI_EVT=0
  CAN write QR_EC as SCI_EVT=1

Since Acer can also work with only the following commit applied:
 Commit: 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when
  SCI_EVT isn't set
We can revert the above commit.

This reverts commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4.

Conflicts:

drivers/acpi/ec.c

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-and-tested-by: Ortwin Gl¨¹ck 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 3d304ff..31b699f 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -334,13 +334,13 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec 
*ec,
pr_debug("* Command(%s) started *\n",
 acpi_ec_cmd_string(t->command));
start_transaction(ec);
-   spin_unlock_irqrestore(>lock, tmp);
-   ret = ec_poll(ec);
-   spin_lock_irqsave(>lock, tmp);
if (ec->curr->command == ACPI_EC_COMMAND_QUERY) {
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
pr_debug("* Event stopped *\n");
}
+   spin_unlock_irqrestore(>lock, tmp);
+   ret = ec_poll(ec);
+   spin_lock_irqsave(>lock, tmp);
pr_debug("* Command(%s) stopped *\n",
 acpi_ec_cmd_string(t->command));
ec->curr = NULL;
-- 
1.7.10

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

Re: [PATCH v7 0/7] usb: add support for the generic PHY framework

[Peter Chen]

On Tue, Oct 28, 2014 at 05:35:34PM +0100, Antoine Tenart wrote:
> The series can be found at:
> git://git.free-electrons.com:users/antoine-tenart/linux.git usb-phy
> 
> Changes since v6:
>   - rebased on top of v3.18-rc2
> 
> Changes since v5:
> - rebased on the latest version of Sergei's series[1]
> - fixed one modifiaction made in the wrong patch
> 
> Changes since v4:
> - reworked the PHY handling in ci_hdrc_probe()
> - fixed a rebase error
> 
> Changes since v3:
> - moved phy_exit() after phy_power_on()
> - fixed the PHY handling in ci_hdrc_probe()
> - some little fixes
> 
> Changes since v2:
> - rebased the series on top of v3.17-rc1
> - switched to devm_phy_get() to handle non DT cases
> - moved usb_otg into the ci_hdrc structure
> 
> Changes since v1:
> - rebased the series on top of [2] (generic PHY support for HCD)
> - split s/phy/usb_phy/ renaming and generic PHY support in separate
>   patches
> 
> [1] https://www.mail-archive.com/linux-usb%40vger.kernel.org/msg48068.html
> 
> Antoine Tenart (7):
>   usb: move the OTG state from the USB PHY to the OTG structure
>   usb: rename phy to usb_phy in OTG
>   usb: add support to the generic PHY framework in OTG
>   usb: allow to supply the PHY in the drivers when using HCD
>   usb: rename transceiver and phy to usb_phy in ChipIdea
>   usb: chipidea: move usb_otg into struct ci_hdrc
>   usb: chipidea: add support to the generic PHY framework in ChipIdea
> 
>  drivers/phy/phy-omap-usb2.c | 14 ++
>  drivers/usb/chipidea/ci.h   |  8 +++-
>  drivers/usb/chipidea/ci_hdrc_imx.c  |  2 +-
>  drivers/usb/chipidea/ci_hdrc_msm.c  |  8 ++--
>  drivers/usb/chipidea/core.c | 89 ++
>  drivers/usb/chipidea/debug.c|  2 +-
>  drivers/usb/chipidea/host.c | 10 ++--
>  drivers/usb/chipidea/otg_fsm.c  | 30 +---
>  drivers/usb/chipidea/udc.c  |  4 +-
>  drivers/usb/common/usb-otg-fsm.c|  8 ++--
>  drivers/usb/core/hcd.c  |  7 +--
>  drivers/usb/host/ohci-omap.c|  2 +-
>  drivers/usb/musb/am35x.c| 28 +--
>  drivers/usb/musb/blackfin.c | 18 +++
>  drivers/usb/musb/da8xx.c| 28 +--
>  drivers/usb/musb/davinci.c  | 18 +++
>  drivers/usb/musb/musb_core.c| 94 ++--
>  drivers/usb/musb/musb_dsps.c| 26 +-
>  drivers/usb/musb/musb_gadget.c  | 36 +++---
>  drivers/usb/musb/musb_host.c|  8 ++--
>  drivers/usb/musb/musb_virthub.c | 22 -
>  drivers/usb/musb/omap2430.c | 30 ++--
>  drivers/usb/musb/tusb6010.c | 40 
>  drivers/usb/musb/ux500.c| 10 ++--
>  drivers/usb/phy/phy-ab8500-usb.c| 16 +++
>  drivers/usb/phy/phy-fsl-usb.c   | 23 -
>  drivers/usb/phy/phy-generic.c   |  6 +--
>  drivers/usb/phy/phy-gpio-vbus-usb.c | 14 +++---
>  drivers/usb/phy/phy-isp1301-omap.c  | 10 ++--
>  drivers/usb/phy/phy-msm-usb.c   | 95 
> +++--
>  drivers/usb/phy/phy-mv-usb.c| 50 +--
>  drivers/usb/phy/phy-tahvo.c |  8 ++--
>  drivers/usb/phy/phy-ulpi.c  |  6 +--
>  include/linux/usb/chipidea.h|  4 +-
>  include/linux/usb/otg.h |  7 ++-
>  include/linux/usb/phy.h |  1 -
>  36 files changed, 420 insertions(+), 362 deletions(-)
> 
> -- 
> 1.9.1
> 

Tested the whole patch set at imx6 hardware, and you can add
my Acked-by to the last three chipidea patches.

I hope your patch-set can be queued soon, since I find the rebase
error with my next tree, I can put your patches on the top.

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

Re: [RFC V2] arm/arm64:add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction

[Rob Herring]

On Mon, Oct 27, 2014 at 2:46 PM, Joe Perches  wrote:
> On Mon, 2014-10-27 at 14:37 +0800, Wang, Yalin wrote:
>> this change add CONFIG_HAVE_ARCH_BITREVERSE config option,
>> so that we can use arm/arm64 rbit instruction to do bitrev operation
>> by hardware.

I don't see the original patch in my inbox, so replying here.

>>
>> Signed-off-by: Yalin Wang 
>> ---
>>  arch/arm/Kconfig|  1 +
>>  arch/arm/include/asm/bitrev.h   | 21 +
>>  arch/arm64/Kconfig  |  1 +
>>  arch/arm64/include/asm/bitrev.h | 21 +
>>  include/linux/bitrev.h  |  9 +
>>  lib/Kconfig |  9 +
>>  lib/bitrev.c|  2 ++
>>  7 files changed, 64 insertions(+)
>>  create mode 100644 arch/arm/include/asm/bitrev.h
>>  create mode 100644 arch/arm64/include/asm/bitrev.h
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 89c4b5c..426cbcc 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -16,6 +16,7 @@ config ARM
>>   select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
>>   select GENERIC_ALLOCATOR
>>   select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
>> + select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7)
>>   select GENERIC_CLOCKEVENTS_BROADCAST if SMP
>>   select GENERIC_IDLE_POLL_SETUP
>>   select GENERIC_IRQ_PROBE

[...]

>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 9532f8d..263c28c 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -36,6 +36,7 @@ config ARM64
>>   select HARDIRQS_SW_RESEND
>>   select HAVE_ARCH_AUDITSYSCALL
>>   select HAVE_ARCH_JUMP_LABEL
>> + select HAVE_ARCH_BITREVERSE
>>   select HAVE_ARCH_KGDB
>>   select HAVE_ARCH_TRACEHOOK
>>   select HAVE_BPF_JIT

The kconfig lists should be sorted.

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

Re: [PATCH] Input: max77693-haptic - fix potential overflow

[Jaewon Kim]

Hi Dmitry,

2014년 10월 29일 01:43에 Dmitry Torokhov 이(가) 쓴 글:

Expression haptic->pwm_dev->period * haptic->magnitude is of type 'unsigned
int' and may overflow. We need to convert one of the operands to u64 before
multiplying, instead of casting result (potentially overflown) to u64.

Reported by Coverity: CID 1248753

Signed-off-by: Dmitry Torokhov 
---
  drivers/input/misc/max77693-haptic.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/max77693-haptic.c 
b/drivers/input/misc/max77693-haptic.c
index 7b1fde9..ef6a9d6 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -194,7 +194,7 @@ static int max77693_haptic_play_effect(struct input_dev 
*dev, void *data,
   struct ff_effect *effect)
  {
struct max77693_haptic *haptic = input_get_drvdata(dev);
-   uint64_t period_mag_multi;
+   u64 period_mag_multi;
  
  	haptic->magnitude = effect->u.rumble.strong_magnitude;

if (!haptic->magnitude)
@@ -205,8 +205,7 @@ static int max77693_haptic_play_effect(struct input_dev 
*dev, void *data,
 * The formula to convert magnitude to pwm_duty as follows:
 * - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0x)
 */
-   period_mag_multi = (int64_t)(haptic->pwm_dev->period *
-   haptic->magnitude);
+   period_mag_multi = (u64)haptic->pwm_dev->period * haptic->magnitude;
haptic->pwm_duty = (unsigned int)(period_mag_multi >>
MAX_MAGNITUDE_SHIFT);
  



There was casting miss in multiplying.
Thanks.

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

Re: [PATCH] sched: Fix race between task_group and sched_task_group

[Kirill Tkhai]

On 29.10.2014 01:52, Oleg Nesterov wrote:
> On 10/28, Kirill Tkhai wrote:
>>
>> Shouldn't we do that in separate patch? How about this?
> 
> Up to Peter, but I think a separate patch is fine.
> 
>> [PATCH]sched: Remove lockdep check in sched_move_task()
>>
>> sched_move_task() is the only interface to change sched_task_group:
>> cpu_cgrp_subsys methods and autogroup_move_group() use it.
> 
> Yes, but...
> 
>> Everything is synchronized by task_rq_lock(), so cpu_cgroup_attach()
>> is ordered with other users of sched_move_task(). This means we do
>> no need RCU here: if we've dereferenced a tg here, the .attach method
>> hasn't been called for it yet.
>>
>> Thus, we should pass "true" to task_css_check() to silence lockdep
>> warnings.
> 
> In theory, I am not sure.
> 
> However, I never really understood this code and today I forgot everything,
> please correct me.
> 
>> @@ -7403,8 +7403,12 @@ void sched_move_task(struct task_struct *tsk)
>>  if (unlikely(running))
>>  put_prev_task(rq, tsk);
>>
>> -tg = container_of(task_css_check(tsk, cpu_cgrp_id,
>> -lockdep_is_held(>sighand->siglock)),
>> +/*
>> + * All callers are synchronized by task_rq_lock(); we do not use RCU
>> + * which is pointless here. Thus, we pass "true" to task_css_check()
>> + * to prevent lockdep warnings.
>> + */
>> +tg = container_of(task_css_check(tsk, cpu_cgrp_id, true),
>>struct task_group, css);
> 
> Why this can't race with cgroup_task_migrate() if it is called by
> cgroup_post_fork() ?

It can race, but which problem is there? The only thing is
cgroup_post_fork()'s or ss->attach()'s call of sched_move_task() will be
NOOP.

cgroup_migrate_add_src()

  cgroup_task_migrate()
cgroup_post_fork();
rcu_assign_pointer(tsk->cgroups, new_cset);
  sched_move_task();
  css->ss->attach(css, );

sched_move_task();

cgroup_migrate_finish()

> And cgroup_task_migrate() can free ->cgroups via call_rcu(). Of course,
> in practice raw_spin_lock_irq() should also act as rcu_read_lock(), but
> we should not rely on implementation details.

Do you mean cgroup_task_migrate()->put_css_set_locked()? It's not
possible there, because old_cset->refcount is lager than 1. We increment
it in cgroup_migrate_add_src() and real freeing happens in
cgroup_migrate_finish(). These functions are around task_migrate(), they
are pair brackets.

> task_group = tsk->cgroups[cpu_cgrp_id] can't go away because yes, if we
> race with migrate then ->attach() was not called. But it seems that in
> theory it is not safe to dereference tsk->cgroups.

old_cset can't be freed in cgroup_task_migrate(), so we can safely
dereference it. If we've got old_cset in
cgroup_post_fork()->sched_move_task(), the right sched_task_group will
be installed by attach->sched_move_task().

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

[PATCH net 1/3] r8152: clear SELECTIVE_SUSPEND when autoresuming

[Hayes Wang]

The flag of SELECTIVE_SUSPEND should be cleared when autoresuming.
Otherwise, when the system suspend and resume occur, it may have
the wrong flow.

Besides, because the flag of SELECTIVE_SUSPEND couldn't be used
to check if the hw enables the relative feature, it should alwayes
be disabled in close().

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e3d84c3..a17ca58 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2955,10 +2955,7 @@ static int rtl8152_close(struct net_device *netdev)
 * be disable when autoresume occurs, because the
 * netif_running() would be false.
 */
-   if (test_bit(SELECTIVE_SUSPEND, >flags)) {
-   rtl_runtime_suspend_enable(tp, false);
-   clear_bit(SELECTIVE_SUSPEND, >flags);
-   }
+   rtl_runtime_suspend_enable(tp, false);
 
tasklet_disable(>tl);
tp->rtl_ops.down(tp);
@@ -3253,6 +3250,8 @@ static int rtl8152_resume(struct usb_interface *intf)
set_bit(WORK_ENABLE, >flags);
}
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
+   } else if (test_bit(SELECTIVE_SUSPEND, >flags)) {
+   clear_bit(SELECTIVE_SUSPEND, >flags);
}
 
mutex_unlock(>control);
-- 
1.9.3

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

[PATCH net 3/3] r8152: check WORK_ENABLE in suspend function

[Hayes Wang]

Avoid unnecessary behavior when autosuspend occurs during open().
The relative processes should only be run after finishing open().

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f224231..ca3c5d5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3207,7 +3207,7 @@ static int rtl8152_suspend(struct usb_interface *intf, 
pm_message_t message)
netif_device_detach(netdev);
}
 
-   if (netif_running(netdev)) {
+   if (netif_running(netdev) && test_bit(WORK_ENABLE, >flags)) {
clear_bit(WORK_ENABLE, >flags);
usb_kill_urb(tp->intr_urb);
tasklet_disable(>tl);
-- 
1.9.3

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

[PATCH net 0/3] r8152: patches for autosuspend

[Hayes Wang]

There are unexpected processes when enabling autosuspend.
These patches are used to fix them.

Hayes Wang (3):
  r8152: clear SELECTIVE_SUSPEND when autoresuming
  r8152: reset tp->speed before autoresuming in open function
  r8152: check WORK_ENABLE in suspend function

 drivers/net/usb/r8152.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

-- 
1.9.3

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

[PATCH net 2/3] r8152: reset tp->speed before autoresuming in open function

[Hayes Wang]

If (tp->speed & LINK_STATUS) is not zero, the rtl8152_resume()
would call rtl_start_rx() before enabling the tx/rx. Avoid this
by resetting it to zero.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a17ca58..f224231 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2891,6 +2891,9 @@ static int rtl8152_open(struct net_device *netdev)
if (res)
goto out;
 
+   /* set speed to 0 to avoid autoresume try to submit rx */
+   tp->speed = 0;
+
res = usb_autopm_get_interface(tp->intf);
if (res < 0) {
free_all_mem(tp);
@@ -2904,6 +2907,8 @@ static int rtl8152_open(struct net_device *netdev)
clear_bit(WORK_ENABLE, >flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(>schedule);
+
+   /* disable the tx/rx, if the workqueue has enabled them. */
if (tp->speed & LINK_STATUS)
tp->rtl_ops.disable(tp);
}
-- 
1.9.3

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

RE: [PATCH] 6fire: Convert byte_rev_table uses to bitrev8

[Wang, Yalin]

> From: Joe Perches [mailto:j...@perches.com]
> > I think the most safe way is change byte_rev_table[] to be satic, So
> > that no driver can access it directly, The build error can remind the
> > developer if they use byte_rev_table[] Directly .
> 
> You can do that with your later patch, but the existing uses _must_ be
> converted first so you don't break the build.
> 
> 
Yeah, I agree with you,
I will add this into my later patch.

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

Re: [PATCH] mm: Avoid overlap the fixmap area on i386

[H. Peter Anvin]

On 10/28/2014 10:29 AM, Thomas Gleixner wrote:
> On Tue, 28 Oct 2014, H. Peter Anvin wrote:
>> On 10/28/2014 04:06 AM, Thomas Gleixner wrote:

 The available address we can use is lower than FIXADDR_BOOT_START. So
 We will set the kmap boundary below the FIXADDR_BOOT_START, if configure
 the high memory.

 If we configure the high memory, the vmalloc reserve area should end
 up to PKMAP_BASE, otherwise should end up to FIXADDR_BOOT_START.
>>>
>>> Which is not really a problem, because the FIXADDR_BOOT area is only
>>> used during boot for early_ioremap() and it's unused when ioremap() is
>>> functional. vmalloc becomes available after early boot so the
>>> FIXADDR_BOOT area is available for reuse.
>>>
>>
>> Given the very limited address space available on i386, it would be
>> extremely undesirable to not reuse address space when possible.
> 
> Fair enough. Then we should do that for the highmem=y case as well.
> 

It is probably even more important for highmem=y...

-hpa


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

Re: [PATCH 2/5] perf, x86, uncore: Add Haswell-EP uncore support

[Andi Kleen]

> 
> yes. removing line 'hswep_uncore_sbox' also worked as workaround.
> You have an idea what's going on?

Not yet. I don't see it on my own systems, so it's something that's
different on yours.

> I suspect other folks will see the same crash when E5 v3
> become more widespread.

I guess we can disable the sbox for now. 

-Andi
> 

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

RE: [PATCH v1 1/3] firmware loader: Introduce new API - request_firmware_abort()

[Kweh, Hock Leong]

> -Original Message-
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Monday, October 27, 2014 12:00 AM
> 
> You can call fw_lookup_buf() directly, otherwise feel free to add:
> 
> Acked-by: Ming Lei 
> 

Hi Ming Lei,

The fw_lookup_buf() is defined inside the conditional preprocessor directive 
for CONFIG_PM_SLEEP.
Since the request_firmware_abort() may not only be used in PM_SLEEP, could I 
move the fw_lookup_buf()
out from the CONFIG_PM_SLEEP block if we want to call fw_lookup_buf() instead 
of __fw_lookup_buf()?

Thanks.


Regards,
Wilson
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] 6fire: Convert byte_rev_table uses to bitrev8

[Joe Perches]

On Wed, 2014-10-29 at 10:42 +0800, Wang, Yalin wrote:
> > Use the inline function instead of directly indexing the array.
> > This allows some architectures with hardware instructions for bit reversals
> > to eliminate the array.
[]
> > On Sun, 2014-10-26 at 23:46 -0700, Joe Perches wrote:
> > > On Mon, 2014-10-27 at 14:37 +0800, Wang, Yalin wrote:
> > > > this change add CONFIG_HAVE_ARCH_BITREVERSE config option, so that
> > > > we can use arm/arm64 rbit instruction to do bitrev operation by
> > > > hardware.
[]
> I think the most safe way is change byte_rev_table[] to be satic,
> So that no driver can access it directly,
> The build error can remind the developer if they use byte_rev_table[]
> Directly .

You can do that with your later patch, but the
existing uses _must_ be converted first so you
don't break the build.



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

Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO

[Michael Ellerman]

On Tue, 2014-10-28 at 13:29 -0700, Randy Dunlap wrote:
> On 10/27/14 06:13, Tomi Valkeinen wrote:
> > I also think the 'depends on BACKLIGHT_CLASS_DEVICE ||
> > BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds
> > like a hack to me =).
> 
> It does exactly what is needed and it is used in many places in kernel
> Kconfig files.

Is there any reason you can't do:

  depends on BACKLIGHT_CLASS_DEVICE != m

cheers


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

Re: [PATCH 02/11 V2] radeon: evergreen: Fix probable mask then right shift defect

[Michel Dänzer]

On 28.10.2014 23:06, Alex Deucher wrote:

On Mon, Oct 27, 2014 at 10:14 AM, Joe Perches  wrote:

Precedence of & and >> is not the same and is not left to right.
shift has higher precedence and should be done after the mask.

Add parentheses around the mask.

Use the already #defined values instead of hardcoding.

Signed-off-by: Joe Perches 
---

I think this should be NUM_SHADER_ENGINES_SHIFT?


(Joe can't type)

exactly right, thanks Michel


Applied with a compile fix.


Joe, in the future please make sure your patches compile before 
submitting them.



--
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v15 2/5] dt-bindings: document Rockchip thermal

[Caesar Wang]

在 2014年10月29日 07:46, Dmitry Torokhov 写道:

On Tue, Oct 28, 2014 at 04:51:24PM +0800, Caesar Wang wrote:

This add the necessary binding documentation for the thermal
found on Rockchip SoCs

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 

Reviewed-by: Dmitry Torokhov 


Added.

Thank you!



---
  .../bindings/thermal/rockchip-thermal.txt  | 62 ++
  1 file changed, 62 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000..fc30e1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,62 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible : "rockchip,rk3288-tsadc"
+- reg : physical base address of the controller and length of memory mapped
+   region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier format
+  depends on the interrupt controller.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Shall be "tsadc" for the converter-clock, and "apb_pclk" for
+   the peripheral clock.
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+- hw-shut-temp : The hardware-controlled shutdown temperature value.
+- tsadc-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
+- tsadc-tshut-polarity : The hardware-controlled active polarity 0:LOW 1:HIGH.
+
+Exiample:
+tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3288-tsadc";
+   reg = <0xff28 0x100>;
+   interrupts = ;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_out>;
+   #thermal-sensor-cells = <1>;
+   hw-shut-temp = <125000>;
+   tsadc-tshut-mode = <0>;
+   tsadc-tshut-polarity = <0>;
+};
+
+Example: referring to thermal sensors:
+thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <1>;
+
+   trips {
+   cpu_alert0: cpu_alert {
+   temperature = <8>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_crit: cpu_crit {
+   temperature = <12>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device =
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+};
--
1.9.1




--
Best regards,
Caesar


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

Re: [PATCH v15 1/5] thermal: rockchip: add driver for thermal

[Caesar Wang]

Dmitry,

Fixed and sent in patch v16.

在 2014年10月29日 07:46, Dmitry Torokhov 写道:

Hi Caesar,

On Tue, Oct 28, 2014 at 04:51:23PM +0800, Caesar Wang wrote:

Thermal is TS-ADC Controller module supports
user-defined mode and automatic mode.

User-defined mode refers,TSADC all the control signals entirely by
software writing to register for direct control.

Automaic mode refers to the module automatically poll TSADC output,
and the results were checked.If you find that the temperature High
in a period of time,an interrupt is generated to the processor
down-measures taken;If the temperature over a period of time High,
the resulting TSHUT gave CRU module,let it reset the entire chip,
or via GPIO give PMIC.

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 

There are couple more nits below, once they are fixed you can add:

Reviewed-by: Dmitry Torokhov 

Fixed.
added.


---
  drivers/thermal/Kconfig|   9 +
  drivers/thermal/Makefile   |   1 +
  drivers/thermal/rockchip_thermal.c | 705 +
  3 files changed, 715 insertions(+)
  create mode 100644 drivers/thermal/rockchip_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index ef5587f..5efcf73 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -133,6 +133,15 @@ config SPEAR_THERMAL
  Enable this to plug the SPEAr thermal sensor driver into the Linux
  thermal framework.
  
+config ROCKCHIP_THERMAL

+   tristate "Rockchip thermal driver"
+   depends on ARCH_ROCKCHIP
+   help
+ Rockchip thermal driver provides support for Temperature sensor
+ ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
+ trip point. Cpufreq is used as the cooling device and will throttle
+ CPUs when the Temperature crosses the passive trip point.
+
  config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 31e232f..21da0a8 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -19,6 +19,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
  
  # platform thermal drivers

  obj-$(CONFIG_SPEAR_THERMAL)   += spear_thermal.o
+obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
  obj-$(CONFIG_RCAR_THERMAL)+= rcar_thermal.o
  obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
  obj-y += samsung/
diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
new file mode 100644
index 000..d6965fb
--- /dev/null
+++ b/drivers/thermal/rockchip_thermal.c
@@ -0,0 +1,705 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * If the temperature over a period of time High,
+ * the resulting TSHUT gave CRU module,let it reset the entire chip,
+ * or via GPIO give PMIC.
+ */
+enum tshut_mode {
+   TSHUT_MODE_CRU = 0,
+   TSHUT_MODE_GPIO,
+};
+
+/**
+ * the system Temperature Sensors tshut(tshut) polarity
+ * the bit 8 is tshut polarity.
+ * 0: low active, 1: high active
+ */
+enum tshut_polarity {
+   TSHUT_LOW_ACTIVE = 0,
+   TSHUT_HIGH_ACTIVE,
+};
+
+/**
+ * The system has three Temperature Sensors.  channel 0 is reserved,
+ * channel 1 is for CPU, and channel 2 is for GPU.
+ */
+enum sensor_id {
+   SENSOR_CPU = 1,
+   SENSOR_GPU,
+};
+
+struct rockchip_tsadc_chip {
+   long hw_shut_temp;
+   enum tshut_mode tshut_mode;
+   enum tshut_polarity tshut_polarity;
+
+   /* Chip-wide methods */
+   void (*initialize)(void __iomem *reg, enum tshut_polarity p,
+  unsigned long clk_rate);
+   void (*irq_ack)(void __iomem *reg);
+   void (*control)(void __iomem *reg, bool on);
+
+   /* Per-sensor methods */
+   int (*get_temp)(int chn, void __iomem *reg, long *temp);
+   void (*set_alarm_temp)(int chn, void __iomem *reg, long temp);
+   void (*set_tshut_temp)(int chn, void __iomem *reg, long temp);
+   void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m);
+};
+
+struct rockchip_thermal_sensor {
+   struct rockchip_thermal_data *thermal;
+   struct thermal_zone_device *tzd;
+   enum sensor_id id;
+};
+
+#define NUM_SENSORS2 /* Ignore unused sensor 0 */
+
+struct rockchip_thermal_data {
+   const struct rockchip_tsadc_chip 

Re: [PATCH] configfs: Implement binary attributes (v3)

[Greg Kroah-Hartman]

On Tue, Oct 28, 2014 at 10:30:32PM +0200, Pantelis Antoniou wrote:
> ConfigFS lacked binary attributes up until now. This patch
> introduces support for binary attributes in a somewhat similar
> manner of sysfs binary attributes albeit with changes that
> fit the configfs usage model.
> 
> Problems that configfs binary attributes fix are everything that
> requires a binary blob as part of the configuration of a resource,
> such as bitstream loading for FPGAs, DTBs for dynamically created
> devices etc.

What's wrong with using the firmware interface for this instead?

What driver/subsystem wants to use configfs binary files?  Having a user
for this api is essential if you want it to be merged.

thanks,

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

RE: [RFC V3] arm/arm64:add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction

[Wang, Yalin]

> From: Will Deacon [mailto:will.dea...@arm.com]
> Yup, sorry, I didn't realise this patch covered both architectures. It
> would probably be a good idea to split it into 3 parts: a core part, then
> the two architectural bits.
> 
> Will

Ok ,
I will split the patch into three parts,
And send again .

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

linux-next: build warning after merge of the pm tree

[Stephen Rothwell]

Hi Rafael,

After merging the pm tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/of/base.c: In function 'of_property_read_string_array':
drivers/of/base.c:1472:1: warning: control reaches end of non-void function 
[-Wreturn-type]
 }
 ^

Introduced by commit ef23586751cd ("Driver core: Unified device
properties interface for platform firmware").  Please don't ignore new
warnings ...

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpvb5VHSRxiD.pgp
Description: OpenPGP digital signature

Re: [PATCH 00/11] Add AXD Audio Processing IP driver

[Greg Kroah-Hartman]

On Tue, Oct 28, 2014 at 03:05:16PM +, Qais Yousef wrote:
> On 10/28/2014 02:13 PM, Greg Kroah-Hartman wrote:
> >On Tue, Oct 28, 2014 at 01:18:28PM +, Qais Yousef wrote:
> >>On 10/28/2014 11:55 AM, Clemens Ladisch wrote:
> >>>Qais Yousef wrote:
> AXD Audio Processing IP performs audio decoding, encoding, mixing, 
> equalisation,
> synchronisation and playback.
> >>>What exactly do you mean with "synchronisation" and "playback"?
> >>Synchronisation refers to accurate audio playout relative to a master
> >>clock source including compensation of drift between the master clock
> >>source and the playout clock of the audio hardware. Hence allowing
> >>synchronised audio playout across multiple independent devices.
> >>
> >>Playback simple refers to the fact that AXD is capable of managing audio
> >>playout hardware like I2S and SPDIF interfaces.
> >>
> >>
> It doesn't fit in alsa subsystem but I Cced them to confirm.
> >>>... because those two words sound like something that a sound card could 
> >>>do.
> >>The problem mainly stems from the fact that we take a variety of
> >>compressed audio as input and we could perform audio encoding. The
> >>problem with the compressed audio is that the range of decoders and
> >>configuration supported in alsa is limited and there's no support for
> >>taking raw pcm and producing compressed output. I'm not an expert on
> >>alsa but when I looked it looked like there's more infra structure
> >>required.
> >>
> >>The following not supported points from 
> >>Documentation/sound/alsa/compress_offload.txt affect us:
> >>
> >>- Volume control/routing is not handled by this API. Devices exposing a
> >>   compressed data interface will be considered as regular ALSA devices;
> >>   volume changes and routing information will be provided with regular
> >>   ALSA kcontrols.
> >>
> >>- Embedded audio effects. Such effects should be enabled in the same
> >>   manner, no matter if the input was PCM or compressed.
> >>
> >>- Encoding/decoding acceleration is not supported as mentioned
> >>   above. It is possible to route the output of a decoder to a capture
> >>   stream, or even implement transcoding capabilities. This routing
> >>   would be enabled with ALSA kcontrols.
> >So instead you created a one-off api just for this hardware?  Ick, no,
> >please work with the audio developers to incorporate it into the
> >standard Linux audio apis so that everyone can benifit and not require
> >special userspace programs to drive this hardware.
> >
> >thanks,
> >
> >greg k-h
> 
> OK. I'll wait to hear from alsa developers to see the extent of work
> required. I can't see it being trivial though. Would it be possible for this
> to be accepted into staging until this is resolved?

If you are willing to abide by the staging rules:
- incremental patches only doing one thing at a time
- never break the build
- constantly moving forward to getting merged (i.e. no new
  features being added)

I think it will be easier for you to do the work outside of the tree as
you are going to be changing the API, which is not going to be easy to
do in an incremental patch series.

And yes, this isn't going to be a trivial amount of work, sorry.

thanks,

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

Re: overlayfs: "filesystem of lowerdir is not supported" on cdrom

[Tim Tassonis]

On 10/28/2014 11:54 PM, Al Viro wrote:
> On Tue, Oct 28, 2014 at 09:13:13PM +, Al Viro wrote:
> 
>>
>> We probably ought to split the normal (case-sensitive, no joliet shite) case
>> out and leave it with NULL ->s_d_op, but that'll need to be done carefully,
>> or isofs_cmp() will blow up on us.
> 
> See if vfs.git#for-linus works for you.
> 

Yes, works for me! Could mount the overlayfs, remove a file, add a file
and modify a file. Not the definive stress-test I guess, but it's a start...

Took only the following two commits:

f643ff550afbc82a2bc7026f4a6d64427e4fbc9

5b71ecfa78271d5c576f17156ed8a53981c1ecb

Kind regards
Tim

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

Re: [PATCH 2/2] cpufreq: Guard against not-yet-initialized policies in cpufreq_cpu_get

[Greg KH]

On Tue, Oct 28, 2014 at 04:26:48PM +0100, Tomeu Vizoso wrote:
> There's a substantial window of opportunity from the time the policy objects
> are created until they are initialized, causing this:
> 
> [4.651435] [ cut here ]
> [4.651453] WARNING: CPU: 1 PID: 64 at include/linux/kref.h:47 
> kobject_get+0x64/0x70()
> [4.651463] Modules linked in:
> [4.651473] CPU: 1 PID: 64 Comm: irq/77-tegra-ac Not tainted 
> 3.18.0-rc1-next-20141027ccu-00049-g21a0041 #248
> [4.651497] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [4.651505] [] (show_stack) from [] 
> (dump_stack+0x98/0xd8)
> [4.651515] [] (dump_stack) from [] 
> (warn_slowpath_common+0x70/0x8c)
> [4.651522] [] (warn_slowpath_common) from [] 
> (warn_slowpath_null+0x1c/0x24)
> [4.651530] [] (warn_slowpath_null) from [] 
> (kobject_get+0x64/0x70)
> [4.651539] [] (kobject_get) from [] 
> (cpufreq_cpu_get+0x88/0xc8)
> [4.651547] [] (cpufreq_cpu_get) from [] 
> (cpufreq_get+0xc/0x64)
> [4.651555] [] (cpufreq_get) from [] 
> (actmon_thread_isr+0x140/0x1a4)
> [4.651563] [] (actmon_thread_isr) from [] 
> (irq_thread_fn+0x1c/0x40)
> [4.651570] [] (irq_thread_fn) from [] 
> (irq_thread+0x134/0x174)
> [4.651579] [] (irq_thread) from [] (kthread+0xdc/0xf4)
> [4.651587] [] (kthread) from [] 
> (ret_from_fork+0x14/0x3c)
> [4.651591] ---[ end trace 7f6a15d1272e6ef3 ]---
> 
> This commit checks that the policy object has been initialized already before
> trying to ref it.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
>  drivers/cpufreq/cpufreq.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 644b54e..37cd6c9 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -214,8 +214,12 @@ struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
>   if (cpufreq_driver) {
>   /* get the CPU */
>   policy = per_cpu(cpufreq_cpu_data, cpu);
> - if (policy)
> - kobject_get(>kobj);
> + if (policy) {
> + if (!kobject_initialized(>kobj))
> + policy = NULL;
> + else
> + kobject_get(>kobj);
> + }

Something else is going on here, sorry, this isn't the correct fix, as
you are using kobjects incorrectly if this ever happens...

thanks,

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

Re: [PATCH 1/2] kobject: Add kobject_initialized() function

[Greg Kroah-Hartman]

On Tue, Oct 28, 2014 at 04:26:47PM +0100, Tomeu Vizoso wrote:
> To be used by users of kobject to tell when one hasn't been initialized yet.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
>  include/linux/kobject.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index 2d61b90..6bb5a92 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -88,6 +88,11 @@ static inline const char *kobject_name(const struct 
> kobject *kobj)
>   return kobj->name;
>  }
>  
> +static inline bool kobject_initialized(const struct kobject *kobj)
> +{
> + return kobj->state_initialized;
> +}

Ick, no.  Why would you ever need this?  You "own" the kobject, and you
better know if you initialized it or not.  If not, you should fix your
use of a kobject.

And why are you even using a kobject at all?

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

RE: [PATCH] 6fire: Convert byte_rev_table uses to bitrev8

[Wang, Yalin]

> Use the inline function instead of directly indexing the array.
> 
> This allows some architectures with hardware instructions for bit reversals
> to eliminate the array.
> 
> Signed-off-by: Joe Perches 
> ---
> On Sun, 2014-10-26 at 23:46 -0700, Joe Perches wrote:
> > On Mon, 2014-10-27 at 14:37 +0800, Wang, Yalin wrote:
> > > this change add CONFIG_HAVE_ARCH_BITREVERSE config option, so that
> > > we can use arm/arm64 rbit instruction to do bitrev operation by
> > > hardware.
> []
> > > diff --git a/include/linux/bitrev.h b/include/linux/bitrev.h index
> > > 7ffe03f..ef5b2bb 100644
> > > --- a/include/linux/bitrev.h
> > > +++ b/include/linux/bitrev.h
> > > @@ -3,6 +3,14 @@
> > >
> > >  #include 
> > >
> > > +#ifdef CONFIG_HAVE_ARCH_BITREVERSE
> > > +#include 
> > > +
> > > +#define bitrev32 __arch_bitrev32
> > > +#define bitrev16 __arch_bitrev16
> > > +#define bitrev8 __arch_bitrev8
> > > +
> > > +#else
> > >  extern u8 const byte_rev_table[256];
> 
>  sound/usb/6fire/firmware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/usb/6fire/firmware.c b/sound/usb/6fire/firmware.c index
> 3b02e54..62c25e7 100644
> --- a/sound/usb/6fire/firmware.c
> +++ b/sound/usb/6fire/firmware.c
> @@ -316,7 +316,7 @@ static int usb6fire_fw_fpga_upload(
> 
>   while (c != end) {
>   for (i = 0; c != end && i < FPGA_BUFSIZE; i++, c++)
> - buffer[i] = byte_rev_table[(u8) *c];
> + buffer[i] = bitrev8((u8)*c);
> 
>   ret = usb6fire_fw_fpga_write(device, buffer, i);
>   if (ret < 0) {
> 
I think the most safe way is change byte_rev_table[] to be satic,
So that no driver can access it directly,
The build error can remind the developer if they use byte_rev_table[]
Directly .

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

[PATCH v16 0/5] Rockchip soc thermal driver

[Caesar Wang]

This series patchs tested on rk3288 SDK board and pinky-v1,v2 board.
I believe the driver can be used on the rk3288-evb board.

Add this driver, The system will shutdown when
the thermal temperture over 120C.If for some reason we are unable to
shut it down in orderly fashion (kernel is stuck holding a lock or similar)
then hardware will reset it.

Changes in v16:
* address comments from Dmitry Torokhov.
- add thermal->chip->control(thermal->regs, false) in remove()
- adjust TSHUT in resume().

Changes in v15:
* address comments from Dmitry Torokhov.
- enable TSHUT move into rk_tsadcv2_tshut_temp().
- drop the id argument in rk_tsadcv2_control().

Changes in v14:
* address comments from Dmitry Torokhov.
- adjust-alarm-rate-depending-on-clock.
- 0001-rockchip-thermal-do-not-register-cpufreq-cooling-dev.

Changes in v13:
- add cooling-maps for cpu-thermal.
- put tshut polarity in device tree.

Changes in v12:
* address comments from Dmitry Torokhov and Vladimir Zapolskiy.
- split-sensor-handling.
- rename-rockchip_tsadc_platform_data.

Changes in v11:
* address comments from Vladimir Zapolskiy.
- fix cpufreq_cooling_unregister() to put in correct position.
- fix "data->chn",at least can get valid Tsensor temp.

Changes in v10:
* address comments from Doug Anderson.
- fix TSHUT polarity,ensure support TSHUT.
- add the decription for rk_tsadcv2_initialize().

Changes in v9:
* address comments from Dmitry Torokhov.
- fix some style be defined
- remove some unused code.
- clk_disable_unprepare->clk_disable in suspend()

Changes in v8:
* address comments from Dmitry Torokhov and Doug Anderson.
- add three Teperture Sensors.
- support CRU and GPIO reset chip.
- rename rk3xxx-cpu-thermal.dtsi as rk3288-thermal.dtsi
- alarm-temp via set_trips() callback
- remove "reset-gpios"

Changes in v7:
- fix get data->clk=0 when in probe() function.
- fix some style code.
- modify dts,main add rk3xxx-cpu-thermal.dtsi

Changes in v6:
* address comments from Tomeu Vizoso.
- use thermal's generic framework.

Changes in v5:
* address comments from Eduardo Valentin,rui.zhang and Heiko Stubner:
- with BIT() macro
- manage clocks in suspend/resume.
- license is fixed as GPLv2.
- #include "thermal_core.h"->#include 
- use the generic trip-points.the hw-shut-temp isn't generic 
trip-points.
- The method of binding and unbinding be fixed.
- The pin-name tsadc->otp_out

Changes in v4:
* address comments from Jonathan Cameron,huangtao and zhaoyifeng:
- this series thermal driver still be put in driver/thermal/
- modify the thermal driver description.

Changes in v3:(add dts configure)
* address comments from Dmitry Torokhov and Arnd Bergmann:
- fix clock-names in rockchip-thermal.txt
- remove rockchip_thermal_control() in rockchip_set_mode()
- fix some code style.
- add dts configure.

Changes in v2:
* address comments from Heiko Stubner:
- fix dt-bindings in rockchip-thermal.txt
- remove Author mark
- rename TSADC_XXX->TSADCV2_XXX,it eill ready to merge compatible other 
SoCs.
- fix a identation
- remove clk_set_rate(),it's no necessary.
- fix the SIMPLE_DEV_PM_OPS() function  style.

Caesar Wang (5):
  thermal: rockchip: add driver for thermal
  dt-bindings: document Rockchip thermal
  ARM: dts: add RK3288 Thermal data
  ARM: dts: add main Thermal info to rk3288
  ARM: dts: enable Thermal on rk3288-evb board

 .../bindings/thermal/rockchip-thermal.txt  |  45 ++
 arch/arm/boot/dts/rk3288-evb.dtsi  |   5 +
 arch/arm/boot/dts/rk3288-thermal.dtsi  |  58 ++
 arch/arm/boot/dts/rk3288.dtsi  |  23 +
 drivers/thermal/Kconfig|   9 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/rockchip_thermal.c | 628 +
 7 files changed, 769 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
 create mode 100644 arch/arm/boot/dts/rk3288-thermal.dtsi
 create mode 100644 drivers/thermal/rockchip_thermal.c

-- 
1.9.1


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

[PATCH v16 3/5] ARM: dts: add RK3288 Thermal data

[Caesar Wang]

This patch changes a dtsi file to contain the thermal data
on RK3288 and later SoCs. This data will
enable a thermal shutdown over 120C.

Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 arch/arm/boot/dts/rk3288-thermal.dtsi | 65 +++
 1 file changed, 65 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3288-thermal.dtsi

diff --git a/arch/arm/boot/dts/rk3288-thermal.dtsi 
b/arch/arm/boot/dts/rk3288-thermal.dtsi
new file mode 100644
index 000..2a018dc
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-thermal.dtsi
@@ -0,0 +1,65 @@
+/*
+ * Device Tree Source for RK3288 SoC thermal
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include 
+
+reserve_thermal: reserve_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <   0>;
+
+};
+
+cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <   1>;
+
+   trips {
+   cpu_alert0: cpu_alert0 {
+   temperature = <8>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_crit: cpu_crit {
+   temperature = <12>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device =
+   < THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+};
+
+gpu_thermal: gpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <   2>;
+
+   trips {
+   gpu_crit: gpu_crit {
+   temperature = <12>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+};
-- 
1.9.1


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

[PATCH v16 2/5] dt-bindings: document Rockchip thermal

[Caesar Wang]

This add the necessary binding documentation for the thermal
found on Rockchip SoCs

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 .../bindings/thermal/rockchip-thermal.txt  | 62 ++
 1 file changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000..3061982
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,62 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible : "rockchip,rk3288-tsadc"
+- reg : physical base address of the controller and length of memory mapped
+   region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier format
+  depends on the interrupt controller.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Shall be "tsadc" for the converter-clock, and "apb_pclk" for
+   the peripheral clock.
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+- hw-shut-temp : The hardware-controlled shutdown temperature value.
+- tsadc-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
+- tsadc-tshut-polarity : The hardware-controlled active polarity 0:LOW 1:HIGH.
+
+Exiample:
+tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3288-tsadc";
+   reg = <0xff28 0x100>;
+   interrupts = ;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_out>;
+   #thermal-sensor-cells = <1>;
+   hw-shut-temp = <125000>;
+   tsadc-tshut-mode = <0>;
+   tsadc-tshut-polarity = <0>;
+};
+
+Example: referring to thermal sensors:
+thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <   1>;
+
+   trips {
+   cpu_alert0: cpu_alert {
+   temperature = <8>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_crit: cpu_crit {
+   temperature = <12>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device =
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+};
-- 
1.9.1


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

[PATCH v16 5/5] ARM: dts: enable Thermal on rk3288-evb board

[Caesar Wang]

when a thermal temperature over TSHUT.Default to via
CRU reset the entire chip on rk3288-evb Board,
TSHUT is low active on rk3288-evb board.

Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 arch/arm/boot/dts/rk3288-evb.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index cb83cea..fb70523 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -148,6 +148,12 @@
status = "okay";
 };
 
+ {
+   tsadc-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */
+   tsadc-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */
+   status = "okay";
+};
+
  {
backlight {
bl_en: bl-en {
-- 
1.9.1


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

[PATCH v16 4/5] ARM: dts: add main Thermal info to rk3288

[Caesar Wang]

This patch is depend on rk3288-thermal.dtsi,or
it will compile error.

If for some reason we are unable to shut it down
in orderly fashion (kernel is stuck holding a lock or
similar), then hardware TSHUT will reset it.

If the temperature over a period of time High,over 125C
the resulting TSHUT gave CRU module,let it reset
the entire chip,or via GPIO give PMIC.

Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 arch/arm/boot/dts/rk3288.dtsi | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index cb18bb4..85855a6 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -66,6 +67,7 @@
 216000  90
 126000  90
>;
+   #cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
};
@@ -346,6 +348,23 @@
status = "disabled";
};
 
+   thermal-zones {
+   #include "rk3288-thermal.dtsi"
+   };
+
+   tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3288-tsadc";
+   reg = <0xff28 0x100>;
+   interrupts = ;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_out>;
+   #thermal-sensor-cells = <1>;
+   hw-shut-temp = <125000>;
+   status = "disabled";
+   };
+
usb_host0_ehci: usb@ff50 {
compatible = "generic-ehci";
reg = <0xff50 0x100>;
@@ -965,6 +984,12 @@
};
};
 
+   tsadc {
+   otp_out: otp-out {
+   rockchip,pins = <0 10 RK_FUNC_1 
_pull_none>;
+   };
+   };
+
pwm0 {
pwm0_pin: pwm0-pin {
rockchip,pins = <7 0 RK_FUNC_1 _pull_none>;
-- 
1.9.1


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

[PATCH v16 1/5] thermal: rockchip: add driver for thermal

[Caesar Wang]

Thermal is TS-ADC Controller module supports
user-defined mode and automatic mode.

User-defined mode refers,TSADC all the control signals entirely by
software writing to register for direct control.

Automaic mode refers to the module automatically poll TSADC output,
and the results were checked.If you find that the temperature High
in a period of time,an interrupt is generated to the processor
down-measures taken;If the temperature over a period of time High,
the resulting TSHUT gave CRU module,let it reset the entire chip,
or via GPIO give PMIC.

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
Reviewed-by: Dmitry Torokhov 
---
 drivers/thermal/Kconfig|   9 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/rockchip_thermal.c | 709 +
 3 files changed, 719 insertions(+)
 create mode 100644 drivers/thermal/rockchip_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index ef5587f..5efcf73 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -133,6 +133,15 @@ config SPEAR_THERMAL
  Enable this to plug the SPEAr thermal sensor driver into the Linux
  thermal framework.
 
+config ROCKCHIP_THERMAL
+   tristate "Rockchip thermal driver"
+   depends on ARCH_ROCKCHIP
+   help
+ Rockchip thermal driver provides support for Temperature sensor
+ ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
+ trip point. Cpufreq is used as the cooling device and will throttle
+ CPUs when the Temperature crosses the passive trip point.
+
 config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 31e232f..21da0a8 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -19,6 +19,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
 
 # platform thermal drivers
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
 obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
 obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
 obj-y  += samsung/
diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
new file mode 100644
index 000..1d47131
--- /dev/null
+++ b/drivers/thermal/rockchip_thermal.c
@@ -0,0 +1,709 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * If the temperature over a period of time High,
+ * the resulting TSHUT gave CRU module,let it reset the entire chip,
+ * or via GPIO give PMIC.
+ */
+enum tshut_mode {
+   TSHUT_MODE_CRU = 0,
+   TSHUT_MODE_GPIO,
+};
+
+/**
+ * the system Temperature Sensors tshut(tshut) polarity
+ * the bit 8 is tshut polarity.
+ * 0: low active, 1: high active
+ */
+enum tshut_polarity {
+   TSHUT_LOW_ACTIVE = 0,
+   TSHUT_HIGH_ACTIVE,
+};
+
+/**
+ * The system has three Temperature Sensors.  channel 0 is reserved,
+ * channel 1 is for CPU, and channel 2 is for GPU.
+ */
+enum sensor_id {
+   SENSOR_CPU = 1,
+   SENSOR_GPU,
+};
+
+struct rockchip_tsadc_chip {
+   long hw_shut_temp;
+   enum tshut_mode tshut_mode;
+   enum tshut_polarity tshut_polarity;
+
+   /* Chip-wide methods */
+   void (*initialize)(void __iomem *reg, enum tshut_polarity p,
+  unsigned long clk_rate);
+   void (*irq_ack)(void __iomem *reg);
+   void (*control)(void __iomem *reg, bool on);
+
+   /* Per-sensor methods */
+   int (*get_temp)(int chn, void __iomem *reg, long *temp);
+   void (*set_alarm_temp)(int chn, void __iomem *reg, long temp);
+   void (*set_tshut_temp)(int chn, void __iomem *reg, long temp);
+   void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m);
+};
+
+struct rockchip_thermal_sensor {
+   struct rockchip_thermal_data *thermal;
+   struct thermal_zone_device *tzd;
+   enum sensor_id id;
+};
+
+#define NUM_SENSORS2 /* Ignore unused sensor 0 */
+
+struct rockchip_thermal_data {
+   const struct rockchip_tsadc_chip *chip;
+   struct platform_device *pdev;
+
+   struct rockchip_thermal_sensor sensors[NUM_SENSORS];
+
+   struct clk *clk;
+   struct clk *pclk;
+
+   void __iomem *regs;
+
+   unsigned long clk_rate;
+
+   long hw_shut_temp;
+   

Re: [PATCH 1/5] phy: sun4i: add support for USB phy0

[Chen-Yu Tsai]

On Wed, Oct 29, 2014 at 5:47 AM, Maxime Ripard
 wrote:
> Hi Roman,
>
> Thanks for your patches
>
> On Mon, Oct 27, 2014 at 10:43:01PM +0100, Roman Byshko wrote:
>> The driver for sun4i USB phys currently supports
>> only phy1 and phy2 which are used for USB host
>> controllers. This patch adds support for USB phy0,
>> which is used by the musb hdrc USB controller.
>
> Like Andreas already pointed out, your signed-off-by is missing from
> all your patches.
>
>> ---
>>  drivers/phy/phy-sun4i-usb.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
>> index 0baf5ef..a24728b 100644
>> --- a/drivers/phy/phy-sun4i-usb.c
>> +++ b/drivers/phy/phy-sun4i-usb.c
>> @@ -157,6 +157,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>>   return ret;
>>   }
>>
>> + /* Regulation 45 ohms */
>> + if (phy->index == 0)
>> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>
> What is this code supposed to do?
>
> Some define for this bit and/or a better comment would be nice.

>From Allwinner's sources: "Enable/Disable USB res45 Calibration"

which I think refers to the internal 45 ohm termination resistors
for the USB data lines. But I'm not an expert on USB hardware.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter

[RR]

On Mon, Oct 27, 2014 at 9:00 PM, Linus Walleij  wrote:
> On Thu, Oct 9, 2014 at 1:46 AM, RR  wrote:
>> On Wed, Oct 8, 2014 at 12:18 AM, Alexandre Courbot  wrote:
>>> On Wed, Oct 8, 2014 at 4:09 PM, Muthu Mani  wrote:
>
> > +static int cy_gpio_direction_output(struct gpio_chip *chip,
> > +   unsigned offset, int value) {
> > +   return 0;
> > +}
>
> If that chip is capable of both output and input, shouldn't these 
> functions be
> implemented? I think this has already been pointed out in a previous 
> version
> but you did not reply.

 Thanks for your inputs.

 Only the GPIOs which are configured to be output GPIO can be set.
>>>
>>> In that case cy_gpio_set() should return an error for GPIOs which are
>>> not configured as outputs. Is that guaranteed by the current
>>> implementation?
>>>
 The set operation would fail trying to set the input or unconfigured GPIOs.
 In this version of driver, this support is not added, it can be introduced 
 in future versions.
 I will add a TODO note in the code.
>>>
>>> Argh, no TODO please. Actual code that will turn this code into a
>>> solid driver that can be merged.
>>
>> Does a driver targeted for a custom device has to implement every
>> functionality in the 1st version ?
>
> When you post a driver to the GPIO maintainers it is *NOT* tageted
> at a consumer device, it is targeted at the kernel community and
> upstream maintainers.

Totally agree. What I was conveying the patch has not modified
any "core" kernel function and is specific to a device thus will not
affect system.

>
> Of course you can deliver add-on patches out-of-tree to your
> customers, it's generally a bad idea for the long term and maintenance
> of your driver, but it's your pick.

AFAIR In the recent past xHCI or gadget core or musb or dw3
patches were added in increments. May be my analogy is incorrect and
I am ignorant of some philosophy here.

Sincerely I somehow was not convinced basic functionality is missing
as referred in the review comment.We have tested the driver for most of
the functionality of our DVK and is working perfectly.

Moreover currently we do not expect an user to set gpio direction as
it involves vendor specific usb control commands.

Having said that we have taken the feedback and working to close this.

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

[PATCH] mmc: atmel-mci: add pm runtime support

[Wenyou Yang]

Signed-off-by: Wenyou Yang 
---
 drivers/mmc/host/atmel-mci.c |  116 ++
 1 file changed, 94 insertions(+), 22 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 0b9ddf8..e9d32d0 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -37,6 +37,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -44,6 +46,8 @@
 
 #include "atmel-mci-regs.h"
 
+#define AUTOSUSPEND_DELAY  50
+
 #define ATMCI_DATA_ERROR_FLAGS (ATMCI_DCRCE | ATMCI_DTOE | ATMCI_OVRE | 
ATMCI_UNRE)
 #define ATMCI_DMA_THRESHOLD16
 
@@ -386,20 +390,19 @@ static int atmci_regs_show(struct seq_file *s, void *v)
if (!buf)
return -ENOMEM;
 
+   pm_runtime_get_sync(>pdev->dev);
+
/*
 * Grab a more or less consistent snapshot. Note that we're
 * not disabling interrupts, so IMR and SR may not be
 * consistent.
 */
-   ret = clk_prepare_enable(host->mck);
-   if (ret)
-   goto out;
-
spin_lock_bh(>lock);
memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
spin_unlock_bh(>lock);
 
-   clk_disable_unprepare(host->mck);
+   pm_runtime_mark_last_busy(>pdev->dev);
+   pm_runtime_put_autosuspend(>pdev->dev);
 
seq_printf(s, "MR:\t0x%08x%s%s ",
buf[ATMCI_MR / 4],
@@ -449,7 +452,6 @@ static int atmci_regs_show(struct seq_file *s, void *v)
val & ATMCI_CFG_LSYNC ? " LSYNC" : "");
}
 
-out:
kfree(buf);
 
return ret;
@@ -1252,6 +1254,8 @@ static void atmci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
WARN_ON(slot->mrq);
dev_dbg(>pdev->dev, "MRQ: cmd %u\n", mrq->cmd->opcode);
 
+   pm_runtime_get_sync(>pdev->dev);
+
/*
 * We may "know" the card is gone even though there's still an
 * electrical connection. If so, we really need to communicate
@@ -1281,7 +1285,8 @@ static void atmci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
struct atmel_mci_slot   *slot = mmc_priv(mmc);
struct atmel_mci*host = slot->host;
unsigned inti;
-   boolunprepare_clk;
+
+   pm_runtime_get_sync(>pdev->dev);
 
slot->sdc_reg &= ~ATMCI_SDCBUS_MASK;
switch (ios->bus_width) {
@@ -1297,13 +1302,8 @@ static void atmci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
unsigned int clock_min = ~0U;
u32 clkdiv;
 
-   clk_prepare(host->mck);
-   unprepare_clk = true;
-
spin_lock_bh(>lock);
if (!host->mode_reg) {
-   clk_enable(host->mck);
-   unprepare_clk = false;
atmci_writel(host, ATMCI_CR, ATMCI_CR_SWRST);
atmci_writel(host, ATMCI_CR, ATMCI_CR_MCIEN);
if (host->caps.has_cfg_reg)
@@ -1371,8 +1371,6 @@ static void atmci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
} else {
bool any_slot_active = false;
 
-   unprepare_clk = false;
-
spin_lock_bh(>lock);
slot->clock = 0;
for (i = 0; i < ATMCI_MAX_NR_SLOTS; i++) {
@@ -1385,17 +1383,12 @@ static void atmci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
atmci_writel(host, ATMCI_CR, ATMCI_CR_MCIDIS);
if (host->mode_reg) {
atmci_readl(host, ATMCI_MR);
-   clk_disable(host->mck);
-   unprepare_clk = true;
}
host->mode_reg = 0;
}
spin_unlock_bh(>lock);
}
 
-   if (unprepare_clk)
-   clk_unprepare(host->mck);
-
switch (ios->power_mode) {
case MMC_POWER_OFF:
if (!IS_ERR(mmc->supply.vmmc))
@@ -1421,6 +1414,9 @@ static void atmci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
 */
break;
}
+
+   pm_runtime_mark_last_busy(>pdev->dev);
+   pm_runtime_put_autosuspend(>pdev->dev);
 }
 
 static int atmci_get_ro(struct mmc_host *mmc)
@@ -1512,6 +1508,9 @@ static void atmci_request_end(struct atmel_mci *host, 
struct mmc_request *mrq)
spin_unlock(>lock);
mmc_request_done(prev_mmc, mrq);
spin_lock(>lock);
+
+   pm_runtime_mark_last_busy(>pdev->dev);
+   pm_runtime_put_autosuspend(>pdev->dev);
 }
 
 static void atmci_command_complete(struct atmel_mci *host,
@@ -2417,7 +2416,6 @@ static int __init atmci_probe(struct platform_device 
*pdev)
 
atmci_writel(host, ATMCI_CR, ATMCI_CR_SWRST);
host->bus_hz = clk_get_rate(host->mck);
-   clk_disable_unprepare(host->mck);
 
host->mapbase = regs->start;
 
@@ -2449,6 

Re: [PATCH 2/2] x86, mce: support memory error recovery for both UCNA and Deferred error in machine_check_poll

[Chen Yucong]

On Mon, 2014-10-27 at 23:10 +, Luck, Tony wrote:
> + m->mcgstatus |= (MCG_STATUS_MCIP|MCG_STATUS_RIPV);
> + severity = mce_severity(m, mca_cfg.tolerant, NULL);
> 
> This seems a big hack to make mce_severity() work when called from
> CMCI context (when MCG_STATUS register is not set).  It would also
> be confusing as the subsequent logged entries would show MCIP and RIPV
> bits set in the mcg_status.
> 
> If someone can think of a less hacky way to do this, that would be good. 
> Otherwise
> the code needs a comment, and should reset m->mcg_status to avoid making logs
> that have incorrect data.
> 
Hi all,

At the suggestion of Tony, this patch add a comment, and restore m->mcgstatus 
to avoid
making logs that have incorrect data.

thx!
cyc

From: Chen Yucong 

Signed-off-by: Chen Yucong 
---
 arch/x86/kernel/cpu/mcheck/mce.c |   64 --
 1 file changed, 62 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index fdc422e..d285d26 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -575,6 +575,56 @@ static void mce_read_aux(struct mce *m, int i)
}
 }
 
+static bool mem_deferred_error(struct mce *m)
+{
+   int severity;
+   u8 mcgs = m->mcgstatus & 0xff;
+   struct cpuinfo_x86 *c = _cpu_data;
+
+   /*
+* mce_severity is specific to machine check exception, and it will
+* check MCIP/EIPV/RIPV bits. In order to get pass the check, we need
+* to set MCIP and RIPV.
+*/
+   m->mcgstatus |= (MCG_STATUS_MCIP|MCG_STATUS_RIPV);
+   severity = mce_severity(m, mca_cfg.tolerant, NULL);
+
+   /* restore the original value of m->mcgstatus */
+   m->mcgstatus = (m->mcgstatus & ~0xff) | mcgs;
+
+   if (c->x86_vendor == X86_VENDOR_AMD) {
+   /*
+* AMD BKDGs - Machine Check Error Codes
+*
+* Bit 8 of ErrCode[15:0] of MCi_STATUS is used for indicating
+* a memory-specific error. Note that this field encodes info-
+* rmation about memory-hierarchy level involved in the error.
+*/
+   if (severity == MCE_DEFERRED_SEVERITY)
+   return  (m->status & 0xff00) == BIT(8);
+   } else if (c->x86_vendor == X86_VENDOR_INTEL) {
+   /*
+* Intel SDM Volume 3B - 15.9.2 Compound Error Codes
+*
+* Bit 7 of the MCACOD field of IA32_MCi_STATUS is used for
+* indicating a memory error. Bit 8 is used for indicating a
+* cache hierarchy error. The combination of bit 2 and bit 3
+* is used for indicating a `generic' cache hierarchy error
+* But we can't just blindly check the above bits, because if
+* bit 11 is set, then it is a bus/interconnect error - and
+* either way the above bits just gives more detail on what
+* bus/interconnect error happened. Note that bit 12 can be
+* ignored, as it's the "filter" bit.
+*/
+   if (severity == MCE_UCNA_SEVERITY)
+   return (m->status & 0xef80) == BIT(7) ||
+  (m->status & 0xef00) == BIT(8) ||
+  (m->status & 0xeffc) == 0xc;
+   }
+
+   return false;
+}
+
 DEFINE_PER_CPU(unsigned, mce_poll_count);
 
 /*
@@ -630,6 +680,16 @@ void machine_check_poll(enum mcp_flags flags, mce_banks_t 
*b)
 
if (!(flags & MCP_TIMESTAMP))
m.tsc = 0;
+
+   /*
+* In the cases where we don't have a valid address after all,
+* do not add it into the ring buffer.
+*/
+   if (mem_deferred_error() && (m.status & MCI_STATUS_ADDRV)) {
+   mce_ring_add(m.addr >> PAGE_SHIFT);
+   mce_schedule_work();
+   }
+
/*
 * Don't get the IP here because it's unlikely to
 * have anything to do with the actual error location.
@@ -1098,8 +1158,8 @@ void do_machine_check(struct pt_regs *regs, long 
error_code)
severity = mce_severity(, cfg->tolerant, NULL);
 
/*
-* When machine check was for corrected handler don't touch,
-* unless we're panicing.
+* When machine check was for corrected/deferred handler don't
+* touch, unless we're panicing.
 */
if ((severity == MCE_KEEP_SEVERITY ||
 severity == MCE_UCNA_SEVERITY) && !no_way_out)
-- 
1.7.10.4



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

Re: [PATCH tip/core/rcu 0/2] Signal-related changes for 3.19

[Pranith Kumar]

On Tue, Oct 28, 2014 at 6:13 PM, Paul E. McKenney
 wrote:
> Hello!
>
> This series updates RCU handling in signals:
>
> 1.  Prevents a possible very long RCU read-side critical section
> in kill_pid_info().
>
> 2.  Explain why the "obviously buggy" freeing of sighand by
> __cleanup_sighand() without an RCU grace period really isn't
> buggy, courtesy of Oleg Nesterov.


Reviewed-by: Pranith Kumar 

>
> Thanx, Paul
>
> 
>
>  b/kernel/fork.c   |5 -
>  b/kernel/signal.c |   42 +-
>  2 files changed, 29 insertions(+), 18 deletions(-)
>



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

Re: non-Multiplatform APE6EVM broken in v3.18-rc1

[Simon Horman]

[ CC Sudeep Holla, Daniel Lezcano, LKML ]

On Wed, Oct 29, 2014 at 09:12:58AM +0900, Simon Horman wrote:
> On Tue, Oct 28, 2014 at 10:32:32AM +0100, Geert Uytterhoeven wrote:
> > Hi Simon,
> > 
> > On Tue, Oct 28, 2014 at 10:23 AM, Simon Horman  wrote:
> > > On Tue, Oct 28, 2014 at 08:59:28AM +0100, Geert Uytterhoeven wrote:
> > >> On Tue, Oct 28, 2014 at 1:41 AM, Simon Horman  wrote:
> > >> > I have noticed that there appears to be a regression between v3.17 and
> > >> > v3.18-rc1 such that non-multiplatform APE6EVM (ape6evm_defconfig) no 
> > >> > longer
> > >> > boots.  This appears to be the case using both reference DT 
> > >> > (MACH_APE6EVM)
> > >>
> > >> How does it manifest itself?
> > >> If you don't get any console output, have you tried my early debug patch?
> > >
> > > IIRC, there was no console output.
> > > I have not tried any out-of tree debug code :)
> > 
> > Perhaps it should just move in-tree?
> 
> Yes, perhaps it should :)
> 
> Regardless, I will try to give it a spin and report back.

Thanks that seems to work well on the ape6evm.

It seems that the boot stops here:

...
smsc911x smsc911x eth0: MAC Address: 00:08:f7:00:02:4b
rcar_thermal rcar_thermal: Runtime PM disabled, clock forced on.
rcar_thermal rcar_thermal: 3 sensor probed
sh_mobile_sdhi sh_mobile_sdhi.0: Runtime PM disabled, clock forced on.
sh_mobile_sdhi sh_mobile_sdhi.0: No vqmmc regulator found

I re-ran my bisection and this time the following showed up as the culprit.

I suspect that the initialisation of mmcif, which is usually the next
device to be initialised, sleeps and never wakes up because the timer is
disabled.

commit c387f07e6205cc13f57c1def5f885bf0a20e1c2d
Author: Sudeep Holla 
Date:   Mon Sep 29 01:50:05 2014 +0200

clocksource: arm_arch_timer: Discard unavailable timers correctly

Currently we wait until both cp15 and mem timers are probed if we
have both timer device nodes present in the device tree without
checking if the device is actually available. If one of the timer
device node present is disabled, the system locks up on the boot
as no timer gets registered.

This patch adds the check for the availability of the timer device
so that unavailable timers are discarded correctly. It also adds
the missing of_node_put.

Signed-off-by: Sudeep Holla 
Reviewed-by: Stephen Boyd 
Acked-by: Mark Rutland 
Signed-off-by: Daniel Lezcano 

diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 5163ec1..7e267e3 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -616,17 +616,29 @@ static const struct of_device_id 
arch_timer_mem_of_match[] __initconst = {
{},
 };
 
+static bool __init
+arch_timer_probed(int type, const struct of_device_id *matches)
+{
+   struct device_node *dn;
+   bool probed = false;
+
+   dn = of_find_matching_node(NULL, matches);
+   if (dn && of_device_is_available(dn) && (arch_timers_present & type))
+   probed = true;
+   of_node_put(dn);
+
+   return probed;
+}
+
 static void __init arch_timer_common_init(void)
 {
unsigned mask = ARCH_CP15_TIMER | ARCH_MEM_TIMER;
 
/* Wait until both nodes are probed if we have two timers */
if ((arch_timers_present & mask) != mask) {
-   if (of_find_matching_node(NULL, arch_timer_mem_of_match) &&
-   !(arch_timers_present & ARCH_MEM_TIMER))
+   if (!arch_timer_probed(ARCH_MEM_TIMER, arch_timer_mem_of_match))
return;
-   if (of_find_matching_node(NULL, arch_timer_of_match) &&
-   !(arch_timers_present & ARCH_CP15_TIMER))
+   if (!arch_timer_probed(ARCH_CP15_TIMER, arch_timer_of_match))
return;
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc:core: fix hs400 timing selection

[Jaehoon Chung]

Hi,

On 10/29/2014 08:52 AM, 유한경 wrote:
> Hi I'm Hankyung Yu
> 
> I will answer instead Chanho Min
> 
> After mmc_set_timing(card->host, MMC_TIMING_MMC_HS); 
> 
> Host controller set to SDR transfer
> 
> so is to change to a DDR transfer mode.

As commit message was mentioned, I have checked the JEDEC v5.01 spec(6.6.5).
There is no mention that mode needs to change to DDR mode.

And i know HS400 mode is only support the 8bit buswidth.
If HS200 mode was set to 4bit buswidth, is HS400 working fine?

Best Regards,
Jaehoon Chung

> 
> 
> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com] 
> Sent: Tuesday, October 28, 2014 1:38 PM
> To: Chanho Min; Chris Ball; Ulf Hansson; Seungwon Jeon; Jaehoon Chung
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; HyoJun Im;
> gunho@lge.com; Hankyung Yu; CPGS
> Subject: Re: [PATCH] mmc:core: fix hs400 timing selection
> 
> Hi, Chanho.
> 
> On 10/22/2014 11:55 AM, Chanho Min wrote:
>> According to JEDEC v5.01 spec (6.6.5), In order to switch to HS400 
>> mode, host should perform the following steps.
>>
>>  1. HS200 mode selection completed
>>  2. Set HS_TIMING to 0x01(High Speed)
>>  3. Host changes frequency to =< 52MHz  4. Set the bus width to DDR 
>> 8bit (CMD6)  5. Host may read Driver Strength (CMD8)  6. Set HS_TIMING 
>> to 0x03 (HS400)
>>
>> In current implementation, the order of 2 and 3 is reversed.
>> The HS_TIMING field should be set to 0x1 before the clock frequency is 
>> set to a value not greater than 52 MHz. Otherwise, Initialization of 
>> timing can be failed. Also, the host contoller's UHS timing mode 
>> should be set to DDR50 after the bus width is set to DDR 8bit.
>>
>> Signed-off-by: Hankyung Yu 
>> Signed-off-by: Chanho Min 
>> ---
>>  drivers/mmc/core/mmc.c |   13 ++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 
>> a301a78..52f78e0 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1061,9 +1061,6 @@ static int mmc_select_hs400(struct mmc_card *card)
>>   * Before switching to dual data rate operation for HS400,
>>   * it is required to convert from HS200 mode to HS mode.
>>   */
>> -mmc_set_timing(card->host, MMC_TIMING_MMC_HS);
>> -mmc_set_bus_speed(card);
>> -
>>  err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> EXT_CSD_HS_TIMING, EXT_CSD_TIMING_HS,
>> card->ext_csd.generic_cmd6_time, @@ -1074,6
> +1071,14 @@ static 
>> int mmc_select_hs400(struct mmc_card *card)
>>  return err;
>>  }
>>  
>> +/*
>> + * According to JEDEC v5.01 spec (6.6.5), Clock frequency should
>> + * be set to a value not greater than 52MHz after the HS_TIMING
>> + * field is set to 0x1.
>> + */
>> +mmc_set_timing(card->host, MMC_TIMING_MMC_HS);
>> +mmc_set_bus_speed(card);
>> +
>>  err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>>   EXT_CSD_BUS_WIDTH,
>>   EXT_CSD_DDR_BUS_WIDTH_8,
>> @@ -1084,6 +1089,8 @@ static int mmc_select_hs400(struct mmc_card *card)
>>  return err;
>>  }
>>  
>> +mmc_set_timing(card->host, MMC_TIMING_MMC_DDR52);
>> +
> 
> I didn't know why timing is set to ddr50.
> 
> Best Regards,
> Jaehoon Chung
> 
>>  err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> EXT_CSD_HS_TIMING, EXT_CSD_TIMING_HS400,
>> card->ext_csd.generic_cmd6_time,
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

Re: [PATCH v3 34/47] acpi: Register power-off handler with kernel power-off handler

[Guenter Roeck]

On 10/28/2014 04:10 PM, Rafael J. Wysocki wrote:

On Monday, October 27, 2014 07:10:26 PM Guenter Roeck wrote:

On 10/27/2014 05:26 PM, Rafael J. Wysocki wrote:

On Monday, October 27, 2014 08:55:41 AM Guenter Roeck wrote:

Register with kernel power-off handler instead of setting pm_power_off
directly. Register with high priority to reflect that the driver explicitly
overrides existing power-off handlers.


Well, I'm still rather unconvinced that notifiers are particularly suitable for
this purpose.

Specifically ->



Fine.


Cc: Rafael J. Wysocki 
Cc: Len Brown 
Signed-off-by: Guenter Roeck 
---
v3:
- Replace poweroff in all newly introduced variables and in text
with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
- Replace acpi: with ACPI: in log message
v2:
- Use define to specify poweroff handler priority
- Use pr_warn instead of pr_err

   drivers/acpi/sleep.c | 15 +--
   1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 05a31b5..7875b92 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -16,6 +16,8 @@
   #include 
   #include 
   #include 
+#include 
+#include 
   #include 
   #include 
   #include 
@@ -827,14 +829,22 @@ static void acpi_power_off_prepare(void)
acpi_disable_all_gpes();
   }

-static void acpi_power_off(void)
+static int acpi_power_off(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
   {


-> Is there any reason why any notifier in the new chain would use the
second argument for anything meaningful?  And the third argument for
that matter?


/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
printk(KERN_DEBUG "%s called\n", __func__);
local_irq_disable();
acpi_enter_sleep_state(ACPI_STATE_S5);
+
+   return NOTIFY_DONE;


Also is there any reason for any notifier in the new chain to return anything
different from NOTIFY_DONE and if so, then what happens when anything else
is returned?



As mentioned earlier, notifiers just come handy. That is all.

Having said that, I don't have a strong opinion either way. If you want me
to implement a priority based callback handler with a single argument,
just let me know and I'll be happy to implement it. It is not worth arguing
about.

Would something like

struct power_off_block {
void (*power_off_call)(struct power_off_block *);
struct power_off_block __rcu *next;
int priority;
};

for the data structure be acceptable ? The power-off handler code would then
be something like

static void acpi_power_off(struct power_off_block *this)
{
}

ie quite similar to the current power-off handler code, with an added argument.
The API would, except for the structure argument, pretty much stay the same.


That's better in my view.

You could also get rid of the priority if you had something like

struct power_off_block *power_off_list[MAX_LEVEL];

and then made your power_off_block registration pass the level as the
second argument.

I also would use struct list_head instead of the next pointer, because the
list manipulation would be trivial then (and the above would become
struct list_head power_off_list[MAX_LEVEL];) and the callers would only
need to do

static struct power_off_block my_power_off_block = {
.power_off_call = my_routine,
};

and then something like

register_power_off_block(_power_off_block, );

which would be just list_add_tail(>node, _off_list[]) plus
some bounds checking etc.  To avoid open coding stuff.

That would allow me to avoid arbitrary gaps in the priority space too and
if more levels need to be added over time, that should be easy to do too if
an enum is used to define them.

But if you prefer to use a unidirectional list and keep the priority in
struct power_off_block, I'm fine with that too.


I prefer a unidirectional list. It is not as if we expect dozens of 
registrations;
in most cases there will be one, rarely two and even more rarely three.


[Dynamic allocation of memory for the struct power_off_block things is worth
considering too IMHO, so that users can simply pass the name of the routine
and the level to the registration function, like:

ret = register_power_off_call(my_routine, );
if (ret)
complain;

The unregistration would be somewhat less straightforward then, but I'm not
sure if unregistration is necessary at all in this case.]



Problem with dynamic memory allocation is that some callers don't have
the memory subsystem initialized when registering the poweroff function.
That was my initial implementation, and it got me some unexpected crashes.

Thanks,
Guenter

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

Re: [PATCH V2 1/5] sched: idle: cpuidle: Check the latency req before idle

[Preeti U Murthy]

On 10/29/2014 12:29 AM, Daniel Lezcano wrote:
> On 10/28/2014 04:51 AM, Preeti Murthy wrote:
>> Hi Daniel,
>>
>> On Thu, Oct 23, 2014 at 2:31 PM, Daniel Lezcano
>>  wrote:
>>> When the pmqos latency requirement is set to zero that means "poll in
>>> all the
>>> cases".
>>>
>>> That is correctly implemented on x86 but not on the other archs.
>>>
>>> As how is written the code, if the latency request is zero, the
>>> governor will
>>> return zero, so corresponding, for x86, to the poll function, but for
>>> the
>>> others arch the default idle function. For example, on ARM this is
>>> wait-for-
>>> interrupt with a latency of '1', so violating the constraint.
>>
>> This is not true actually. On PowerPC the idle state 0 has an
>> exit_latency of 0.
>>
>>>
>>> In order to fix that, do the latency requirement check *before*
>>> calling the
>>> cpuidle framework in order to jump to the poll function without entering
>>> cpuidle. That has several benefits:
>>
>> Doing so actually hurts on PowerPC. Because the idle loop defined for
>> idle state 0 is different from what cpu_relax() does in cpu_idle_loop().
>> The spinning is more power efficient in the former case. Moreover we
>> also set
>> certain register values which indicate an idle cpu. The ppc_runlatch bits
>> do precisely this. These register values are being read by some user
>> space
>> tools.  So we will end up breaking them with this patch
>>
>> My suggestion is very well keep the latency requirement check in
>> kernel/sched/idle.c
>> like your doing in this patch. But before jumping to cpu_idle_loop
>> verify if the
>> idle state 0 has an exit_latency > 0 in addition to your check on the
>> latency_req == 0.
>> If not, you can fall through to the regular path of calling into the
>> cpuidle driver.
>> The scheduler can query the cpuidle_driver structure anyway.
>>
>> What do you think?
> 
> Thanks for reviewing the patch and spotting this.
> 
> Wouldn't make sense to create:
> 
> void __weak_cpu_idle_poll(void) ?
> 
> and override it with your specific poll function ?
> 

No this would become ugly as far as I can see. A weak function has to be
defined under arch/* code. We will either need to duplicate the idle
loop that we already have in the drivers or point the weak function to
the first idle state defined by our driver. Both of which is not
desirable (calling into the driver from arch code is ugly). Another
reason why I don't like the idea of a weak function is that if you have
missed looking at a specific driver and they have an idle loop with
features similar to on powerpc, you will have to spot it yourself and
include the arch specific cpu_idle_poll() for them.

But by having a check on the exit_latency, you are claiming that since
the driver's 0th idle state is no better than the generic idle loop in
cases of 0 latency req, we are better off calling the latter, which
looks reasonable. That way you don't have to bother about worsening the
idle loop behavior on any other driver.

Regards
Preeti U Murthy

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

Crude Oil Exploration

[Adel Salman]

Good day,
I have an oil exportation proposition contract for you.If you don't mind,
reply my email for full details of contract proposal.

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

Re: [PATCH v2 10/10] power/reset: brcmstb: Register with kernel restart handler

[Brian Norris]

On Tue, Sep 30, 2014 at 10:48:36AM -0700, Guenter Roeck wrote:
> Register with kernel restart handler instead of setting arm_pm_restart 
> directly.
> 
> Cc: Marc Carino 
> Cc: Brian Norris 
> Signed-off-by: Guenter Roeck 

Tested on top of linux-next:

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

Re: [PATCH V2 3/5] cpuidle: idle: menu: Don't reflect when a state selection failed

[Preeti U Murthy]

On 10/28/2014 11:58 PM, Daniel Lezcano wrote:
> On 10/28/2014 08:01 AM, Preeti Murthy wrote:
>> On Thu, Oct 23, 2014 at 2:31 PM, Daniel Lezcano
>>  wrote:
>>> In the current code, the check to reflect or not the outcoming state
>>> is done
>>> against the idle state which has been chosen and its value.
>>>
>>> Instead of doing a check in each of the reflect functions, just don't
>>> call reflect
>>> if something went wrong in the idle path.
>>>
>>> Signed-off-by: Daniel Lezcano 
>>> Acked-by: Nicolas Pitre 
>>> ---
>>>   drivers/cpuidle/governors/ladder.c | 3 +--
>>>   drivers/cpuidle/governors/menu.c   | 4 +---
>>>   kernel/sched/idle.c| 3 ++-
>>>   3 files changed, 4 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/cpuidle/governors/ladder.c
>>> b/drivers/cpuidle/governors/ladder.c
>>> index fb396d6..c0b36a8 100644
>>> --- a/drivers/cpuidle/governors/ladder.c
>>> +++ b/drivers/cpuidle/governors/ladder.c
>>> @@ -165,8 +165,7 @@ static int ladder_enable_device(struct
>>> cpuidle_driver *drv,
>>>   static void ladder_reflect(struct cpuidle_device *dev, int index)
>>>   {
>>>  struct ladder_device *ldev = &__get_cpu_var(ladder_devices);
>>> -   if (index > 0)
>>> -   ldev->last_state_idx = index;
>>> +   ldev->last_state_idx = index;
>>>   }
>>>
>>>   static struct cpuidle_governor ladder_governor = {
>>> diff --git a/drivers/cpuidle/governors/menu.c
>>> b/drivers/cpuidle/governors/menu.c
>>> index a17515f..3907301 100644
>>> --- a/drivers/cpuidle/governors/menu.c
>>> +++ b/drivers/cpuidle/governors/menu.c
>>> @@ -365,9 +365,7 @@ static int menu_select(struct cpuidle_driver
>>> *drv, struct cpuidle_device *dev,
>>>   static void menu_reflect(struct cpuidle_device *dev, int index)
>>>   {
>>>  struct menu_device *data = &__get_cpu_var(menu_devices);
>>> -   data->last_state_idx = index;
>>> -   if (index >= 0)
>>> -   data->needs_update = 1;
>>> +   data->needs_update = 1;
>>
>> Why is the last_state_idx not getting updated ?
> 
> Oups, right. This is missing.
> 
> Thanks for pointing this out.
> 
> By the way, I don't think a back end driver is changing the selected
> state currently and I am not sure this is desirable since we want to
> trust the state we are going (as a best effort). So if the 'enter'
> function does not change the index, that means the last_state_idx has
> not to be changed since it has been assigned in the 'select' function.

Hmm Right. So you might want to remove the last_state_idx update in
ladder_reflect() also?

Regards
Preeti U Murthy
> 
> 
> 

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