[PATCH 1/2] rtc: omap: Fix selecting external osc

[Keerthy]

From: Lokesh Vutla 

RTC can be clocked from an external 32KHz oscillator, or from the
Peripheral PLL. The RTC has an internal oscillator buffer to support
direct operation with a crystal.


|   Device  -   |
|   |   |   |
|   | RTCSS |   |
|   -   |   |   |
OSC |<--| RTC   |   |   |   |
|-->| OSC   |---|   |   |
|      ||   |   |
|   |clk|   |
|      ||   |   |
|   | PRCM  |---|   |   |
|   |


The RTC functional clock is sourced by default from the clock derived
from the Peripheral PLL. In order to select source as external osc clk
the following changes needs to be done:
- Enable the RTC OSC (RTC_OSC_REG[4]OSC32K_GZ = 0)
- Enable the clock mux(RTC_OSC_REG[6]K32CLK_EN = 1)
- Select the external clock source (RTC_OSC_REG[3]32KCLK_SEL = 1)

Fixes: 399cf0f63f6f2 ("rtc: omap: Add external clock enabling support")
Signed-off-by: Keerthy 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Dave Gerlach 
---

Boot tested and checked for rtc ticking on am335x-boneblack, am335x-bone
am437x-gp-evm, dra7-evm, dra72-evm.

 drivers/rtc/rtc-omap.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index b04ea9b..dddaa60 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -113,6 +113,7 @@
 /* OMAP_RTC_OSC_REG bit fields: */
 #define OMAP_RTC_OSC_32KCLK_EN BIT(6)
 #define OMAP_RTC_OSC_SEL_32KCLK_SRCBIT(3)
+#define OMAP_RTC_OSC_OSC32K_GZ_DISABLE BIT(4)
 
 /* OMAP_RTC_IRQWAKEEN bit fields: */
 #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEENBIT(1)
@@ -786,8 +787,9 @@ static int omap_rtc_probe(struct platform_device *pdev)
 */
if (rtc->has_ext_clk) {
reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
-   rtc_write(rtc, OMAP_RTC_OSC_REG,
- reg | OMAP_RTC_OSC_SEL_32KCLK_SRC);
+   reg &= ~OMAP_RTC_OSC_OSC32K_GZ_DISABLE;
+   reg |= OMAP_RTC_OSC_32KCLK_EN | OMAP_RTC_OSC_SEL_32KCLK_SRC;
+   rtc_writel(rtc, OMAP_RTC_OSC_REG, reg);
}
 
rtc->type->lock(rtc);
-- 
1.9.1

[PATCH 1/2] rtc: omap: Fix selecting external osc

[Keerthy]

From: Lokesh Vutla 

RTC can be clocked from an external 32KHz oscillator, or from the
Peripheral PLL. The RTC has an internal oscillator buffer to support
direct operation with a crystal.


|   Device  -   |
|   |   |   |
|   | RTCSS |   |
|   -   |   |   |
OSC |<--| RTC   |   |   |   |
|-->| OSC   |---|   |   |
|      ||   |   |
|   |clk|   |
|      ||   |   |
|   | PRCM  |---|   |   |
|   |


The RTC functional clock is sourced by default from the clock derived
from the Peripheral PLL. In order to select source as external osc clk
the following changes needs to be done:
- Enable the RTC OSC (RTC_OSC_REG[4]OSC32K_GZ = 0)
- Enable the clock mux(RTC_OSC_REG[6]K32CLK_EN = 1)
- Select the external clock source (RTC_OSC_REG[3]32KCLK_SEL = 1)

Fixes: 399cf0f63f6f2 ("rtc: omap: Add external clock enabling support")
Signed-off-by: Keerthy 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Dave Gerlach 
---

Boot tested and checked for rtc ticking on am335x-boneblack, am335x-bone
am437x-gp-evm, dra7-evm, dra72-evm.

 drivers/rtc/rtc-omap.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index b04ea9b..dddaa60 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -113,6 +113,7 @@
 /* OMAP_RTC_OSC_REG bit fields: */
 #define OMAP_RTC_OSC_32KCLK_EN BIT(6)
 #define OMAP_RTC_OSC_SEL_32KCLK_SRCBIT(3)
+#define OMAP_RTC_OSC_OSC32K_GZ_DISABLE BIT(4)
 
 /* OMAP_RTC_IRQWAKEEN bit fields: */
 #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEENBIT(1)
@@ -786,8 +787,9 @@ static int omap_rtc_probe(struct platform_device *pdev)
 */
if (rtc->has_ext_clk) {
reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
-   rtc_write(rtc, OMAP_RTC_OSC_REG,
- reg | OMAP_RTC_OSC_SEL_32KCLK_SRC);
+   reg &= ~OMAP_RTC_OSC_OSC32K_GZ_DISABLE;
+   reg |= OMAP_RTC_OSC_32KCLK_EN | OMAP_RTC_OSC_SEL_32KCLK_SRC;
+   rtc_writel(rtc, OMAP_RTC_OSC_REG, reg);
}
 
rtc->type->lock(rtc);
-- 
1.9.1

[PATCH 2/2] rtc: omap: prevent disabling of clock/module during suspend

[Keerthy]

From: Tero Kristo 

If RTC is running from an internal clock source, the RTC module can't
be disabled; otherwise it stops ticking completely. Current suspend
handler implementation disables the clock/module unconditionally,
instead fix this by disabling the clock only if we are running on
external clock source, which is not affected by suspend.

The prevention of disabling the clock must be done via implementing
the runtime_pm handlers for the device, and returning an error code
from the runtime suspend handler; otherwise OMAP core PM will disable
the clocks for the driver.

Signed-off-by: Tero Kristo 
Signed-off-by: Keerthy 
---

Boot tested and checked for rtc ticking on am335x-boneblack, am335x-bone
am437x-gp-evm, dra7-evm, dra72-evm.

 drivers/rtc/rtc-omap.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index dddaa60..51e5244 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -147,6 +147,7 @@ struct omap_rtc {
u8 interrupts_reg;
bool is_pmic_controller;
bool has_ext_clk;
+   bool is_suspending;
const struct omap_rtc_device_type *type;
struct pinctrl_dev *pctldev;
 };
@@ -900,8 +901,7 @@ static int omap_rtc_suspend(struct device *dev)
rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
rtc->type->lock(rtc);
 
-   /* Disable the clock/module */
-   pm_runtime_put_sync(dev);
+   rtc->is_suspending = true;
 
return 0;
 }
@@ -910,9 +910,6 @@ static int omap_rtc_resume(struct device *dev)
 {
struct omap_rtc *rtc = dev_get_drvdata(dev);
 
-   /* Enable the clock/module so that we can access the registers */
-   pm_runtime_get_sync(dev);
-
rtc->type->unlock(rtc);
if (device_may_wakeup(dev))
disable_irq_wake(rtc->irq_alarm);
@@ -920,11 +917,34 @@ static int omap_rtc_resume(struct device *dev)
rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, rtc->interrupts_reg);
rtc->type->lock(rtc);
 
+   rtc->is_suspending = false;
+
return 0;
 }
 #endif
 
-static SIMPLE_DEV_PM_OPS(omap_rtc_pm_ops, omap_rtc_suspend, omap_rtc_resume);
+#ifdef CONFIG_PM
+static int omap_rtc_runtime_suspend(struct device *dev)
+{
+   struct omap_rtc *rtc = dev_get_drvdata(dev);
+
+   if (rtc->is_suspending && !rtc->has_ext_clk)
+   return -EBUSY;
+
+   return 0;
+}
+
+static int omap_rtc_runtime_resume(struct device *dev)
+{
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops omap_rtc_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(omap_rtc_suspend, omap_rtc_resume)
+   SET_RUNTIME_PM_OPS(omap_rtc_runtime_suspend,
+  omap_rtc_runtime_resume, NULL)
+};
 
 static void omap_rtc_shutdown(struct platform_device *pdev)
 {
-- 
1.9.1

[PATCH 2/2] rtc: omap: prevent disabling of clock/module during suspend

[Keerthy]

From: Tero Kristo 

If RTC is running from an internal clock source, the RTC module can't
be disabled; otherwise it stops ticking completely. Current suspend
handler implementation disables the clock/module unconditionally,
instead fix this by disabling the clock only if we are running on
external clock source, which is not affected by suspend.

The prevention of disabling the clock must be done via implementing
the runtime_pm handlers for the device, and returning an error code
from the runtime suspend handler; otherwise OMAP core PM will disable
the clocks for the driver.

Signed-off-by: Tero Kristo 
Signed-off-by: Keerthy 
---

Boot tested and checked for rtc ticking on am335x-boneblack, am335x-bone
am437x-gp-evm, dra7-evm, dra72-evm.

 drivers/rtc/rtc-omap.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index dddaa60..51e5244 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -147,6 +147,7 @@ struct omap_rtc {
u8 interrupts_reg;
bool is_pmic_controller;
bool has_ext_clk;
+   bool is_suspending;
const struct omap_rtc_device_type *type;
struct pinctrl_dev *pctldev;
 };
@@ -900,8 +901,7 @@ static int omap_rtc_suspend(struct device *dev)
rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
rtc->type->lock(rtc);
 
-   /* Disable the clock/module */
-   pm_runtime_put_sync(dev);
+   rtc->is_suspending = true;
 
return 0;
 }
@@ -910,9 +910,6 @@ static int omap_rtc_resume(struct device *dev)
 {
struct omap_rtc *rtc = dev_get_drvdata(dev);
 
-   /* Enable the clock/module so that we can access the registers */
-   pm_runtime_get_sync(dev);
-
rtc->type->unlock(rtc);
if (device_may_wakeup(dev))
disable_irq_wake(rtc->irq_alarm);
@@ -920,11 +917,34 @@ static int omap_rtc_resume(struct device *dev)
rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, rtc->interrupts_reg);
rtc->type->lock(rtc);
 
+   rtc->is_suspending = false;
+
return 0;
 }
 #endif
 
-static SIMPLE_DEV_PM_OPS(omap_rtc_pm_ops, omap_rtc_suspend, omap_rtc_resume);
+#ifdef CONFIG_PM
+static int omap_rtc_runtime_suspend(struct device *dev)
+{
+   struct omap_rtc *rtc = dev_get_drvdata(dev);
+
+   if (rtc->is_suspending && !rtc->has_ext_clk)
+   return -EBUSY;
+
+   return 0;
+}
+
+static int omap_rtc_runtime_resume(struct device *dev)
+{
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops omap_rtc_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(omap_rtc_suspend, omap_rtc_resume)
+   SET_RUNTIME_PM_OPS(omap_rtc_runtime_suspend,
+  omap_rtc_runtime_resume, NULL)
+};
 
 static void omap_rtc_shutdown(struct platform_device *pdev)
 {
-- 
1.9.1

Re: [PATCH] net: avoid uninitialized variable

[zhong jiang]

On 2016/10/27 12:02, Gao Feng wrote:
> On Thu, Oct 27, 2016 at 11:56 AM, zhongjiang  wrote:
>> From: zhong jiang 
>>
>> when I compiler the newest kernel, I hit the following error with
>> Werror=may-uninitalized.
>>
>> net/core/flow_dissector.c: In function ?._skb_flow_dissect?
>> include/uapi/linux/swab.h:100:46: error: ?.lan?.may be used uninitialized in 
>> this function [-Werror=maybe-uninitialized]
>> net/core/flow_dissector.c:248:26: note: ?.lan?.was declared here
>>
>> This adds an additional check for proto to explicitly tell the compiler
>> that vlan pointer have the correct value before it is used.
>>
>> Signed-off-by: zhong jiang 
>> ---
>>  net/core/flow_dissector.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>> index 1a7b80f..a04d9cf 100644
>> --- a/net/core/flow_dissector.c
>> +++ b/net/core/flow_dissector.c
>> @@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>> }
>> case htons(ETH_P_8021AD):
>> case htons(ETH_P_8021Q): {
>> -   const struct vlan_hdr *vlan;
>> +   const struct vlan_hdr *vlan = NULL;
>>
>> if (skb_vlan_tag_present(skb))
>> proto = skb->protocol;
>> @@ -276,7 +276,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>> key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
>> key_vlan->vlan_priority =
>> (skb_vlan_tag_get_prio(skb) >> 
>> VLAN_PRIO_SHIFT);
>> -   } else {
>> +   } else if (proto == cpu_to_be16(ETH_P_8021Q) ||
>> +   proto == 
>> cpu_to_be16(ETH_P_8021AD)) {
>> key_vlan->vlan_id = ntohs(vlan->h_vlan_TCI) &
>> VLAN_VID_MASK;
>> key_vlan->vlan_priority =
>> --
>> 1.8.3.1
>>
> It seems there is one similar patch already.
> You could refer to https://patchwork.kernel.org/patch/9389565/
>
> Regards
> Feng
>
> .
>
 sorry, I doesn't notice that patch.

 Thanks
 zhongjiang 

Re: [PATCH] net: avoid uninitialized variable

[zhong jiang]

On 2016/10/27 12:02, Gao Feng wrote:
> On Thu, Oct 27, 2016 at 11:56 AM, zhongjiang  wrote:
>> From: zhong jiang 
>>
>> when I compiler the newest kernel, I hit the following error with
>> Werror=may-uninitalized.
>>
>> net/core/flow_dissector.c: In function ?._skb_flow_dissect?
>> include/uapi/linux/swab.h:100:46: error: ?.lan?.may be used uninitialized in 
>> this function [-Werror=maybe-uninitialized]
>> net/core/flow_dissector.c:248:26: note: ?.lan?.was declared here
>>
>> This adds an additional check for proto to explicitly tell the compiler
>> that vlan pointer have the correct value before it is used.
>>
>> Signed-off-by: zhong jiang 
>> ---
>>  net/core/flow_dissector.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>> index 1a7b80f..a04d9cf 100644
>> --- a/net/core/flow_dissector.c
>> +++ b/net/core/flow_dissector.c
>> @@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>> }
>> case htons(ETH_P_8021AD):
>> case htons(ETH_P_8021Q): {
>> -   const struct vlan_hdr *vlan;
>> +   const struct vlan_hdr *vlan = NULL;
>>
>> if (skb_vlan_tag_present(skb))
>> proto = skb->protocol;
>> @@ -276,7 +276,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>> key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
>> key_vlan->vlan_priority =
>> (skb_vlan_tag_get_prio(skb) >> 
>> VLAN_PRIO_SHIFT);
>> -   } else {
>> +   } else if (proto == cpu_to_be16(ETH_P_8021Q) ||
>> +   proto == 
>> cpu_to_be16(ETH_P_8021AD)) {
>> key_vlan->vlan_id = ntohs(vlan->h_vlan_TCI) &
>> VLAN_VID_MASK;
>> key_vlan->vlan_priority =
>> --
>> 1.8.3.1
>>
> It seems there is one similar patch already.
> You could refer to https://patchwork.kernel.org/patch/9389565/
>
> Regards
> Feng
>
> .
>
 sorry, I doesn't notice that patch.

 Thanks
 zhongjiang 

stm32-usart.c:undefined reference to `bad_dma_ops'

[kbuild test robot]

Hi Alexandre,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
commit: 3489187204eb75e5635d8836babfd0a18be613f4 serial: stm32: adding dma 
support
date:   5 weeks ago
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3489187204eb75e5635d8836babfd0a18be613f4
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `stm32_serial_remove':
>> stm32-usart.c:(.text+0xdbf3c): undefined reference to `bad_dma_ops'
   stm32-usart.c:(.text+0xdbf44): undefined reference to `bad_dma_ops'
   stm32-usart.c:(.text+0xdbfe0): undefined reference to `bad_dma_ops'
   stm32-usart.c:(.text+0xdbfe8): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfc10): undefined reference to `bad_dma_ops'
   sound/built-in.o:(.text+0xfc14): more undefined references to `bad_dma_ops' 
follow
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfc64): undefined reference to `dma_common_mmap'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfc64): relocation truncated to fit: R_M32R_26_PCREL_RELA against 
undefined symbol `dma_common_mmap'
   sound/built-in.o: In function `cygnus_pcm_preallocate_dma_buffer':
   cygnus-pcm.c:(.text+0x10fff0): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x10fff4): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x110028): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `cygnus_dma_free_dma_buffers':
   cygnus-pcm.c:(.text+0x110128): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x110130): undefined reference to `bad_dma_ops'
   sound/built-in.o:cygnus-pcm.c:(.text+0x1101c8): more undefined references to 
`bad_dma_ops' follow

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


.config.gz
Description: application/gzip

stm32-usart.c:undefined reference to `bad_dma_ops'

[kbuild test robot]

Hi Alexandre,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
commit: 3489187204eb75e5635d8836babfd0a18be613f4 serial: stm32: adding dma 
support
date:   5 weeks ago
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3489187204eb75e5635d8836babfd0a18be613f4
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `stm32_serial_remove':
>> stm32-usart.c:(.text+0xdbf3c): undefined reference to `bad_dma_ops'
   stm32-usart.c:(.text+0xdbf44): undefined reference to `bad_dma_ops'
   stm32-usart.c:(.text+0xdbfe0): undefined reference to `bad_dma_ops'
   stm32-usart.c:(.text+0xdbfe8): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfc10): undefined reference to `bad_dma_ops'
   sound/built-in.o:(.text+0xfc14): more undefined references to `bad_dma_ops' 
follow
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfc64): undefined reference to `dma_common_mmap'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfc64): relocation truncated to fit: R_M32R_26_PCREL_RELA against 
undefined symbol `dma_common_mmap'
   sound/built-in.o: In function `cygnus_pcm_preallocate_dma_buffer':
   cygnus-pcm.c:(.text+0x10fff0): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x10fff4): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x110028): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `cygnus_dma_free_dma_buffers':
   cygnus-pcm.c:(.text+0x110128): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x110130): undefined reference to `bad_dma_ops'
   sound/built-in.o:cygnus-pcm.c:(.text+0x1101c8): more undefined references to 
`bad_dma_ops' follow

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


.config.gz
Description: application/gzip

RE: [PATCH 2/3] usb: dwc3: host: Do not use dma_set_coherent_mask

[Sriram Dash]

>From: Arnd Bergmann [mailto:a...@arndb.de]
>On Tuesday, October 25, 2016 4:26:27 PM CEST Sriram Dash wrote:
>> Do not require dma_set_coherent_mask for hcd
>>
>> Signed-off-by: Arnd Bergmann 
>
>Aside from the comments I had for patch 3, you are doing two different things
>here:
>
>> diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
>> index 89a2f71..4d7439c 100644
>> --- a/drivers/usb/dwc3/dwc3-st.c
>> +++ b/drivers/usb/dwc3/dwc3-st.c
>> @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *pdev)
>>  if (IS_ERR(regmap))
>>  return PTR_ERR(regmap);
>>
>> -dma_set_coherent_mask(dev, dev->coherent_dma_mask);
>>  dwc3_data->dev = dev;
>>  dwc3_data->regmap = regmap;
>>
>
>This one was setting the mask for the device itself (incorrectly), so it can be
>removed along with the dma_coerce_mask_and_coherent() call in
>dwc3_exynos_probe, or as a separate patch. It is an independent cleanup.
>
>> --- a/drivers/usb/chipidea/core.c
>> +++ b/drivers/usb/chipidea/core.c
>> @@ -833,9 +833,6 @@ struct platform_device *ci_hdrc_add_device(struct
>> device *dev,
>>
>> -dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
>>
>>  ret = platform_device_add_resources(pdev, res, nres);
>>  if (ret)
>
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1059,12 +1059,6 @@ static int dwc3_probe(struct platform_device
>> *pdev)
>>
>>  spin_lock_init(>lock);
>>
>> -dma_set_coherent_mask(dev, dev->parent-
>>coherent_dma_mask);
>
>> --- a/drivers/usb/dwc3/host.c
>> +++ b/drivers/usb/dwc3/host.c
>> @@ -72,11 +72,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>>  return -ENOMEM;
>>  }
>>
>> -dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
>> -
>
>These three all set the mask for the *child* devices, as that is no longer 
>needed
>after the change in patch 1/3.
>I'd suggest leaving those changes together with the rest of that patch.
>
>However, it's probably better to split up that patch along the boundaries of 
>the
>drivers, starting with the USB core:
>

Ok. Will do the needful in the next version.

>1/4 usb: separate out sysdev pointer from usb_bus
>2/4 usb: chipidea: use bus->sysdev for DMA configuration
>3/4 usb: xhci: use bus->sysdev for DMA configuration
>4/4 usb: dwc3: use bus->sysdev for DMA configuration
>
>   Arnd

RE: [PATCH 2/3] usb: dwc3: host: Do not use dma_set_coherent_mask

[Sriram Dash]

>From: Arnd Bergmann [mailto:a...@arndb.de]
>On Tuesday, October 25, 2016 4:26:27 PM CEST Sriram Dash wrote:
>> Do not require dma_set_coherent_mask for hcd
>>
>> Signed-off-by: Arnd Bergmann 
>
>Aside from the comments I had for patch 3, you are doing two different things
>here:
>
>> diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
>> index 89a2f71..4d7439c 100644
>> --- a/drivers/usb/dwc3/dwc3-st.c
>> +++ b/drivers/usb/dwc3/dwc3-st.c
>> @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *pdev)
>>  if (IS_ERR(regmap))
>>  return PTR_ERR(regmap);
>>
>> -dma_set_coherent_mask(dev, dev->coherent_dma_mask);
>>  dwc3_data->dev = dev;
>>  dwc3_data->regmap = regmap;
>>
>
>This one was setting the mask for the device itself (incorrectly), so it can be
>removed along with the dma_coerce_mask_and_coherent() call in
>dwc3_exynos_probe, or as a separate patch. It is an independent cleanup.
>
>> --- a/drivers/usb/chipidea/core.c
>> +++ b/drivers/usb/chipidea/core.c
>> @@ -833,9 +833,6 @@ struct platform_device *ci_hdrc_add_device(struct
>> device *dev,
>>
>> -dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
>>
>>  ret = platform_device_add_resources(pdev, res, nres);
>>  if (ret)
>
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1059,12 +1059,6 @@ static int dwc3_probe(struct platform_device
>> *pdev)
>>
>>  spin_lock_init(>lock);
>>
>> -dma_set_coherent_mask(dev, dev->parent-
>>coherent_dma_mask);
>
>> --- a/drivers/usb/dwc3/host.c
>> +++ b/drivers/usb/dwc3/host.c
>> @@ -72,11 +72,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>>  return -ENOMEM;
>>  }
>>
>> -dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
>> -
>
>These three all set the mask for the *child* devices, as that is no longer 
>needed
>after the change in patch 1/3.
>I'd suggest leaving those changes together with the rest of that patch.
>
>However, it's probably better to split up that patch along the boundaries of 
>the
>drivers, starting with the USB core:
>

Ok. Will do the needful in the next version.

>1/4 usb: separate out sysdev pointer from usb_bus
>2/4 usb: chipidea: use bus->sysdev for DMA configuration
>3/4 usb: xhci: use bus->sysdev for DMA configuration
>4/4 usb: dwc3: use bus->sysdev for DMA configuration
>
>   Arnd

Re: [PATCH] pci: Don't set RCB bit in LNKCTL if the upstream bridge hasn't

[Hannes Reinecke]

On 10/26/2016 09:43 PM, Bjorn Helgaas wrote:
> Hi Johannes,
> 
> On Wed, Oct 26, 2016 at 03:53:34PM +0200, Johannes Thumshirn wrote:
>> The Read Completion Boundary bit must only be set on a device or endpoint if
>> it is set on the upstream bridge.
>>
>> Fixes: 7a1562d4f ("PCI: Apply _HPX Link Control settings to all devices with 
>> a link")
> 
> Can you please include a spec citation and a pointer to the bug report?
> 
PCI Express Base Specification 1.1,
section 2.3.1.1. Data Return for Read Requests:

The Read Completion Boundary (RCB) parameter determines the naturally
aligned address boundaries on which a Read Request may be serviced with
multiple Completions
o For a Root Complex, RCB is 64 bytes or 128 bytes
  o This value is reported through a configuration register
(see Section 7.8)
  Note: Bridges and Endpoints may implement a corresponding command
  bit which may be set by system software to indicate the RCB value
  for the Root Complex, allowing the Bridge/Endpoint to optimize its
  behavior when the Root Complex’s RCB is 128 bytes.
o For all other system elements, RCB is 128 bytes

In this particular case the _HPX method was causing the RCB for all PCI
devices to be set to 128 bytes, while the root bridge remained at 64 bytes.
While this is arguably a BIOS bug, earlier linux version (ie without the
mentioned patch) were running fine, so this is actually a regression.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH] pci: Don't set RCB bit in LNKCTL if the upstream bridge hasn't

[Hannes Reinecke]

On 10/26/2016 09:43 PM, Bjorn Helgaas wrote:
> Hi Johannes,
> 
> On Wed, Oct 26, 2016 at 03:53:34PM +0200, Johannes Thumshirn wrote:
>> The Read Completion Boundary bit must only be set on a device or endpoint if
>> it is set on the upstream bridge.
>>
>> Fixes: 7a1562d4f ("PCI: Apply _HPX Link Control settings to all devices with 
>> a link")
> 
> Can you please include a spec citation and a pointer to the bug report?
> 
PCI Express Base Specification 1.1,
section 2.3.1.1. Data Return for Read Requests:

The Read Completion Boundary (RCB) parameter determines the naturally
aligned address boundaries on which a Read Request may be serviced with
multiple Completions
o For a Root Complex, RCB is 64 bytes or 128 bytes
  o This value is reported through a configuration register
(see Section 7.8)
  Note: Bridges and Endpoints may implement a corresponding command
  bit which may be set by system software to indicate the RCB value
  for the Root Complex, allowing the Bridge/Endpoint to optimize its
  behavior when the Root Complex’s RCB is 128 bytes.
o For all other system elements, RCB is 128 bytes

In this particular case the _HPX method was causing the RCB for all PCI
devices to be set to 128 bytes, while the root bridge remained at 64 bytes.
While this is arguably a BIOS bug, earlier linux version (ie without the
mentioned patch) were running fine, so this is actually a regression.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: bio linked list corruption.

[Dave Chinner]

On Tue, Oct 25, 2016 at 08:27:52PM -0400, Dave Jones wrote:
> DaveC: Do these look like real problems, or is this more "looks like
> random memory corruption" ?  It's been a while since I did some stress
> testing on XFS, so these might not be new..
> 
> XFS: Assertion failed: oldlen > newlen, file: fs/xfs/libxfs/xfs_bmap.c, line: 
> 2938
> [ cut here ]
> kernel BUG at fs/xfs/xfs_message.c:113!
> invalid opcode:  [#1] PREEMPT SMP
> CPU: 1 PID: 6227 Comm: trinity-c9 Not tainted 4.9.0-rc1-think+ #6 
> task: 8804f4658040 task.stack: 88050568c000
> RIP: 0010:[] 
>   [] assfail+0x1b/0x20 [xfs]
> RSP: :88050568f9e8  EFLAGS: 00010282
> RAX: ffea RBX: 0046 RCX: 0001
> RDX: ffc0 RSI: 000a RDI: a02fe34d
> RBP: 88050568f9e8 R08:  R09: 
> R10: 000a R11: f000 R12: 88050568fb44
> R13: 00f3 R14: 8804f292bf88 R15: 000e0046
> FS:  7fe2ddfdfb40() GS:88050a00() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fe2dbabd000 CR3: 0004f461f000 CR4: 001406e0
> Stack:
>  88050568fa88  a027ccee  fff9  8804f16fd8b0
>  3ffa  0032  8804f292bf40  4976
>  000e0008  04fd  8804  5107
> Call Trace:
>  [] xfs_bmap_add_extent_hole_delay+0x54e/0x620 [xfs]
>  [] xfs_bmapi_reserve_delalloc+0x2b4/0x400 [xfs]
>  [] xfs_file_iomap_begin_delay.isra.12+0x247/0x3c0 [xfs]
>  [] xfs_file_iomap_begin+0x181/0x270 [xfs]
>  [] iomap_apply+0x53/0x100
>  [] iomap_file_buffered_write+0x6b/0x90

All this iomap code is new, so it's entirely possible that this is a
new bug. The assert failure is indicative that the delalloc extent's
metadata reservation grew when we expected it to stay the same or
shrink.

> XFS: Assertion failed: tp->t_blk_res_used <= tp->t_blk_res, file: 
> fs/xfs/xfs_trans.c, line: 309
...
>  [] xfs_trans_mod_sb+0x241/0x280 [xfs]
>  [] xfs_ag_resv_alloc_extent+0x4f/0xc0 [xfs]
>  [] xfs_alloc_ag_vextent+0x23d/0x300 [xfs]
>  [] xfs_alloc_vextent+0x5fb/0x6d0 [xfs]
>  [] xfs_bmap_btalloc+0x304/0x8e0 [xfs]
>  [] ? xfs_iext_bno_to_ext+0xee/0x170 [xfs]
>  [] xfs_bmap_alloc+0x2b/0x40 [xfs]
>  [] xfs_bmapi_write+0x640/0x1210 [xfs]
>  [] xfs_iomap_write_allocate+0x166/0x350 [xfs]
>  [] xfs_map_blocks+0x1b0/0x260 [xfs]
>  [] xfs_do_writepage+0x23b/0x730 [xfs]

And that's indicative of a delalloc metadata reservation being
being too small and so we're allocating unreserved blocks.

Different symptoms, same underlying cause, I think.

I see the latter assert from time to time in my testing, but it's
not common (maybe once a month) and I've never been able to track it
down.  However, it doesn't affect production systems unless they hit
ENOSPC hard enough that it causes the critical reserve pool to be
exhausted iand so the allocation fails. That's extremely rare -
usually takes a several hundred processes all trying to write as had
as they can concurrently and to all slip through the ENOSPC
detection without the correct metadata reservations and all require
multiple metadata blocks to be allocated durign writeback...

If you've got a way to trigger it quickly and reliably, that would
be helpful...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: bio linked list corruption.

[Dave Chinner]

On Tue, Oct 25, 2016 at 08:27:52PM -0400, Dave Jones wrote:
> DaveC: Do these look like real problems, or is this more "looks like
> random memory corruption" ?  It's been a while since I did some stress
> testing on XFS, so these might not be new..
> 
> XFS: Assertion failed: oldlen > newlen, file: fs/xfs/libxfs/xfs_bmap.c, line: 
> 2938
> [ cut here ]
> kernel BUG at fs/xfs/xfs_message.c:113!
> invalid opcode:  [#1] PREEMPT SMP
> CPU: 1 PID: 6227 Comm: trinity-c9 Not tainted 4.9.0-rc1-think+ #6 
> task: 8804f4658040 task.stack: 88050568c000
> RIP: 0010:[] 
>   [] assfail+0x1b/0x20 [xfs]
> RSP: :88050568f9e8  EFLAGS: 00010282
> RAX: ffea RBX: 0046 RCX: 0001
> RDX: ffc0 RSI: 000a RDI: a02fe34d
> RBP: 88050568f9e8 R08:  R09: 
> R10: 000a R11: f000 R12: 88050568fb44
> R13: 00f3 R14: 8804f292bf88 R15: 000e0046
> FS:  7fe2ddfdfb40() GS:88050a00() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fe2dbabd000 CR3: 0004f461f000 CR4: 001406e0
> Stack:
>  88050568fa88  a027ccee  fff9  8804f16fd8b0
>  3ffa  0032  8804f292bf40  4976
>  000e0008  04fd  8804  5107
> Call Trace:
>  [] xfs_bmap_add_extent_hole_delay+0x54e/0x620 [xfs]
>  [] xfs_bmapi_reserve_delalloc+0x2b4/0x400 [xfs]
>  [] xfs_file_iomap_begin_delay.isra.12+0x247/0x3c0 [xfs]
>  [] xfs_file_iomap_begin+0x181/0x270 [xfs]
>  [] iomap_apply+0x53/0x100
>  [] iomap_file_buffered_write+0x6b/0x90

All this iomap code is new, so it's entirely possible that this is a
new bug. The assert failure is indicative that the delalloc extent's
metadata reservation grew when we expected it to stay the same or
shrink.

> XFS: Assertion failed: tp->t_blk_res_used <= tp->t_blk_res, file: 
> fs/xfs/xfs_trans.c, line: 309
...
>  [] xfs_trans_mod_sb+0x241/0x280 [xfs]
>  [] xfs_ag_resv_alloc_extent+0x4f/0xc0 [xfs]
>  [] xfs_alloc_ag_vextent+0x23d/0x300 [xfs]
>  [] xfs_alloc_vextent+0x5fb/0x6d0 [xfs]
>  [] xfs_bmap_btalloc+0x304/0x8e0 [xfs]
>  [] ? xfs_iext_bno_to_ext+0xee/0x170 [xfs]
>  [] xfs_bmap_alloc+0x2b/0x40 [xfs]
>  [] xfs_bmapi_write+0x640/0x1210 [xfs]
>  [] xfs_iomap_write_allocate+0x166/0x350 [xfs]
>  [] xfs_map_blocks+0x1b0/0x260 [xfs]
>  [] xfs_do_writepage+0x23b/0x730 [xfs]

And that's indicative of a delalloc metadata reservation being
being too small and so we're allocating unreserved blocks.

Different symptoms, same underlying cause, I think.

I see the latter assert from time to time in my testing, but it's
not common (maybe once a month) and I've never been able to track it
down.  However, it doesn't affect production systems unless they hit
ENOSPC hard enough that it causes the critical reserve pool to be
exhausted iand so the allocation fails. That's extremely rare -
usually takes a several hundred processes all trying to write as had
as they can concurrently and to all slip through the ENOSPC
detection without the correct metadata reservations and all require
multiple metadata blocks to be allocated durign writeback...

If you've got a way to trigger it quickly and reliably, that would
be helpful...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: linux-next: Tree for Oct 26 (crypto/acompress.ko)

[Giovanni Cabiddu]

Hi,

On Wed, Oct 26, 2016 at 07:54:00PM -0400, Paul Gortmaker wrote:
> So, no EXPORT_SYMBOL, and any .config which has ACOMP2=m will fail.
I sent a patch for this:
https://patchwork.kernel.org/patch/9396503/

Regards,

--
Giovanni

Re: linux-next: Tree for Oct 26 (crypto/acompress.ko)

[Giovanni Cabiddu]

Hi,

On Wed, Oct 26, 2016 at 07:54:00PM -0400, Paul Gortmaker wrote:
> So, no EXPORT_SYMBOL, and any .config which has ACOMP2=m will fail.
I sent a patch for this:
https://patchwork.kernel.org/patch/9396503/

Regards,

--
Giovanni

Re: [PATCH 4.8 000/140] 4.8.5-stable review

[Greg Kroah-Hartman]

On Wed, Oct 26, 2016 at 02:49:41PM -0700, Guenter Roeck wrote:
> On Wed, Oct 26, 2016 at 02:21:00PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.8.5 release.
> > There are 140 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Oct 28 12:21:58 UTC 2016.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 113 pass: 113 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Great, thanks for testing and letting me know for both of these.

greg k-h

Re: [PATCH 4.8 000/140] 4.8.5-stable review

[Greg Kroah-Hartman]

On Wed, Oct 26, 2016 at 12:44:58PM -0600, Shuah Khan wrote:
> On 10/26/2016 06:21 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.8.5 release.
> > There are 140 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Oct 28 12:21:58 UTC 2016.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.5-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.8.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing both of these and letting me know.

greg k-h

Re: [PATCH 4.8 000/140] 4.8.5-stable review

[Greg Kroah-Hartman]

On Wed, Oct 26, 2016 at 02:49:41PM -0700, Guenter Roeck wrote:
> On Wed, Oct 26, 2016 at 02:21:00PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.8.5 release.
> > There are 140 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Oct 28 12:21:58 UTC 2016.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 113 pass: 113 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Great, thanks for testing and letting me know for both of these.

greg k-h

Re: [PATCH 4.8 000/140] 4.8.5-stable review

[Greg Kroah-Hartman]

On Wed, Oct 26, 2016 at 12:44:58PM -0600, Shuah Khan wrote:
> On 10/26/2016 06:21 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.8.5 release.
> > There are 140 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Oct 28 12:21:58 UTC 2016.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.5-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.8.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing both of these and letting me know.

greg k-h

ATTENZIONE;

[amministratore]

ATTENZIONE;

La cassetta postale ha superato il limite di archiviazione, che è 5 GB come 
definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si 
può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare 
la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti 
informazioni qui di seguito:

nome:
Nome utente:
Password:
Conferma Password:
E-mail:
telefono:

Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi 
posta sarà disabilitato!

Ci dispiace per l'inconvenienza.
Codice di verifica: en:0085362LK.0.2016
Mail Technical Support ©2016

grazie
Sistemi amministratore

ATTENZIONE;

[amministratore]

ATTENZIONE;

La cassetta postale ha superato il limite di archiviazione, che è 5 GB come 
definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si 
può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare 
la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti 
informazioni qui di seguito:

nome:
Nome utente:
Password:
Conferma Password:
E-mail:
telefono:

Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi 
posta sarà disabilitato!

Ci dispiace per l'inconvenienza.
Codice di verifica: en:0085362LK.0.2016
Mail Technical Support ©2016

grazie
Sistemi amministratore

RE: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

[Y.B. Lu]

Hi Scott,


> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Thursday, October 27, 2016 1:06 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian
> Subject: Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> 
> On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new
> > file mode 100644 index 000..b99764c
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,19 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > +   bool "Freescale QorIQ GUTS driver"
> > +   select SOC_BUS
> > +   help
> > +     The global utilities block controls power management, I/O device
> > +     enabling, power-onreset(POR) configuration monitoring, alternate
> > +     function selection for multiplexed signals,and clock control.
> > +     This driver is to manage and access global utilities block.
> > +     Initially only reading SVR and registering soc device are
> > supported.
> > +     Other guts accesses, such as reading RCW, should eventually be
> > moved
> > +     into this driver as well.
> > +
> > +     If you want GUTS driver support, you should say Y here.
> 
> This is user-enablable without dependencies, which means it will break
> some randconfigs.  If this is to be enabled via select then remove the
> text after "bool".

[Lu Yangbo-B47093] Will enable it via select and remove text after 'bool'.
 
> 
> > +/* SoC die attribute definition for QorIQ platform */ static const
> > +struct fsl_soc_die_attr fsl_soc_die[] = { #ifdef CONFIG_PPC
> > +   /*
> > +    * Power Architecture-based SoCs T Series
> > +    */
> > +
> > +   /* Die: T4240, SoC: T4240/T4160/T4080 */
> > +   { .die  = "T4240",
> > +     .svr  = 0x8240,
> > +     .mask = 0xfff0,
> > +   },
> > +   /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> > +   { .die  = "T1040",
> > +     .svr  = 0x8520,
> > +     .mask = 0xfff0,
> > +   },
> > +   /* Die: T2080, SoC: T2080/T2081 */
> > +   { .die  = "T2080",
> > +     .svr  = 0x8530,
> > +     .mask = 0xfff0,
> > +   },
> > +   /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> > +   { .die  = "T1024",
> > +     .svr  = 0x8540,
> > +     .mask = 0xfff0,
> > +   },
> > +#endif /* CONFIG_PPC */
> > +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)
> 
> Will this driver ever be probed on MXC?  Why do we need these ifdefs at
> all?

[Lu Yangbo-B47093] Will remove them. In the previous version, we use too many 
members for soc definition, so I add #ifdef for ARCH. 
CONFIG_ARCH_MXC was for ls1021a.

> 
> 
> > +   /*
> > +    * ARM-based SoCs LS Series
> > +    */
> > +
> > +   /* Die: LS1043A, SoC: LS1043A/LS1023A */
> > +   { .die  = "LS1043A",
> > +     .svr  = 0x8792,
> > +     .mask = 0x,
> > +   },
> > +   /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> > +   { .die  = "LS2080A",
> > +     .svr  = 0x8701,
> > +     .mask = 0xff3f,
> > +   },
> > +   /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> > +   { .die  = "LS1088A",
> > +     .svr  = 0x8703,
> > +     .mask = 0xff3f,
> > +   },
> > +   /* Die: LS1012A, SoC: LS1012A */
> > +   { .die  = "LS1012A",
> > +     .svr  = 0x8704,
> > +     .mask = 0x,
> > +   },
> > +   /* Die: LS1046A, SoC: LS1046A/LS1026A */
> > +   { .die  = "LS1046A",
> > +     .svr  = 0x8707,
> > +     .mask = 0x,
> > +   },
> > +   /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> > +   { .die  = "LS2088A",
> > +     .svr  = 0x8709,
> > +     .mask = 0xff3f,
> > +   },
> > +   /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A
> > +    * Note: Put this die at the end in cause of incorrect
> > identification
> > +    */
> > +   { .die  = "LS1021A",
> > +     .svr  = 0x8700,
> > +     .mask = 0xfff0,
> > +   },
> > +#endif /* CONFIG_ARCH_MXC || CONFIG_ARCH_LAYERSCAPE */
> 
> Instead of relying on ordering, add more bits to the mask so that there's
> no overlap.  I think 0xfff7 would work.

[Lu Yangbo-B47093] Ok, Will do that. Then we add 3 bits of 'Various 
Personalities' field for ls1021a die identification.

> 
> > +out:
> > +   

RE: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

[Y.B. Lu]

Hi Scott,


> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Thursday, October 27, 2016 1:06 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian
> Subject: Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> 
> On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new
> > file mode 100644 index 000..b99764c
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,19 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > +   bool "Freescale QorIQ GUTS driver"
> > +   select SOC_BUS
> > +   help
> > +     The global utilities block controls power management, I/O device
> > +     enabling, power-onreset(POR) configuration monitoring, alternate
> > +     function selection for multiplexed signals,and clock control.
> > +     This driver is to manage and access global utilities block.
> > +     Initially only reading SVR and registering soc device are
> > supported.
> > +     Other guts accesses, such as reading RCW, should eventually be
> > moved
> > +     into this driver as well.
> > +
> > +     If you want GUTS driver support, you should say Y here.
> 
> This is user-enablable without dependencies, which means it will break
> some randconfigs.  If this is to be enabled via select then remove the
> text after "bool".

[Lu Yangbo-B47093] Will enable it via select and remove text after 'bool'.
 
> 
> > +/* SoC die attribute definition for QorIQ platform */ static const
> > +struct fsl_soc_die_attr fsl_soc_die[] = { #ifdef CONFIG_PPC
> > +   /*
> > +    * Power Architecture-based SoCs T Series
> > +    */
> > +
> > +   /* Die: T4240, SoC: T4240/T4160/T4080 */
> > +   { .die  = "T4240",
> > +     .svr  = 0x8240,
> > +     .mask = 0xfff0,
> > +   },
> > +   /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> > +   { .die  = "T1040",
> > +     .svr  = 0x8520,
> > +     .mask = 0xfff0,
> > +   },
> > +   /* Die: T2080, SoC: T2080/T2081 */
> > +   { .die  = "T2080",
> > +     .svr  = 0x8530,
> > +     .mask = 0xfff0,
> > +   },
> > +   /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> > +   { .die  = "T1024",
> > +     .svr  = 0x8540,
> > +     .mask = 0xfff0,
> > +   },
> > +#endif /* CONFIG_PPC */
> > +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)
> 
> Will this driver ever be probed on MXC?  Why do we need these ifdefs at
> all?

[Lu Yangbo-B47093] Will remove them. In the previous version, we use too many 
members for soc definition, so I add #ifdef for ARCH. 
CONFIG_ARCH_MXC was for ls1021a.

> 
> 
> > +   /*
> > +    * ARM-based SoCs LS Series
> > +    */
> > +
> > +   /* Die: LS1043A, SoC: LS1043A/LS1023A */
> > +   { .die  = "LS1043A",
> > +     .svr  = 0x8792,
> > +     .mask = 0x,
> > +   },
> > +   /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> > +   { .die  = "LS2080A",
> > +     .svr  = 0x8701,
> > +     .mask = 0xff3f,
> > +   },
> > +   /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> > +   { .die  = "LS1088A",
> > +     .svr  = 0x8703,
> > +     .mask = 0xff3f,
> > +   },
> > +   /* Die: LS1012A, SoC: LS1012A */
> > +   { .die  = "LS1012A",
> > +     .svr  = 0x8704,
> > +     .mask = 0x,
> > +   },
> > +   /* Die: LS1046A, SoC: LS1046A/LS1026A */
> > +   { .die  = "LS1046A",
> > +     .svr  = 0x8707,
> > +     .mask = 0x,
> > +   },
> > +   /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> > +   { .die  = "LS2088A",
> > +     .svr  = 0x8709,
> > +     .mask = 0xff3f,
> > +   },
> > +   /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A
> > +    * Note: Put this die at the end in cause of incorrect
> > identification
> > +    */
> > +   { .die  = "LS1021A",
> > +     .svr  = 0x8700,
> > +     .mask = 0xfff0,
> > +   },
> > +#endif /* CONFIG_ARCH_MXC || CONFIG_ARCH_LAYERSCAPE */
> 
> Instead of relying on ordering, add more bits to the mask so that there's
> no overlap.  I think 0xfff7 would work.

[Lu Yangbo-B47093] Ok, Will do that. Then we add 3 bits of 'Various 
Personalities' field for ls1021a die identification.

> 
> > +out:
> > +   

Re: [PATCH v2 2/3] use a nocache copy for bvecs and kvecs in copy_from_iter_nocache()

[Ross Zwisler]

On Wed, Oct 26, 2016 at 10:50:20AM -0500, Brian Boylston wrote:
> Update copy_from_iter_nocache() to use memcpy_nocache()
> for bvecs and kvecs.
> 
> Cc: Ross Zwisler 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: 
> Cc: Al Viro 
> Cc: Dan Williams 
> Signed-off-by: Brian Boylston 
> Reviewed-by: Toshi Kani 
> Reported-by: Oliver Moreno 
> ---
>  lib/iov_iter.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 7e3138c..71e4531 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -342,6 +342,13 @@ static void memcpy_from_page(char *to, struct page 
> *page, size_t offset, size_t
>   kunmap_atomic(from);
>  }
>  
> +static void memcpy_from_page_nocache(char *to, struct page *page, size_t 
> offset, size_t len)
> +{
> + char *from = kmap_atomic(page);
> + memcpy_nocache(to, from + offset, len);
> + kunmap_atomic(from);
> +}
> +
>  static void memcpy_to_page(struct page *page, size_t offset, const char 
> *from, size_t len)
>  {
>   char *to = kmap_atomic(page);
> @@ -392,9 +399,10 @@ size_t copy_from_iter_nocache(void *addr, size_t bytes, 
> struct iov_iter *i)
>   iterate_and_advance(i, bytes, v,
>   __copy_from_user_nocache((to += v.iov_len) - v.iov_len,
>v.iov_base, v.iov_len),
> - memcpy_from_page((to += v.bv_len) - v.bv_len, v.bv_page,
> -  v.bv_offset, v.bv_len),
> - memcpy((to += v.iov_len) - v.iov_len, v.iov_base, v.iov_len)
> + memcpy_from_page_nocache((to += v.bv_len) - v.bv_len,
> +  v.bv_page, v.bv_offset, v.bv_len),
> + memcpy_nocache((to += v.iov_len) - v.iov_len,
> +v.iov_base, v.iov_len)
>   )
>  
>   return bytes;
> -- 
> 2.8.3

I generally agree with Boaz's comments to your patch 1 - this feels like yet
another layer where we have indirection based on the architecture.

We already have an arch switch at memcpy_to_pmem() based on whether the
architecture supports the PMEM API.  And we already have
__copy_from_user_nocache(), which based on the architecture can map to either
a non-cached memcpy (x86_32, x86_64), or it can just map to a normal memcpy
via __copy_from_user_inatomic() (this happens in include/linux/uaccss.h, which
I believe is used for all non-x86 architectures).

memcpy_nocache() now does the same thing as __copy_from_user_nocache(), where
we define an uncached memcpy for x86_32 and x86_64, and a normal memcpy
variant for other architectures.  But, weirdly, the x86 version maps to our
to __copy_from_user_nocache(), but it on non-x86 we don't map to
__copy_from_user_nocache() and use its fallback, we provide a new fallback of
our own via a direct call to memcpy()?

And, now in copy_from_iter_nocache() on x86 we call __copy_from_user_nocache()
two different ways: directly, and indirectly through memcpy_nocache() and
memcpy_from_page_nocache()=>memcpy_nocache().

Is there any way to simplify all of this?

All in all I'm on board with doing non-temporal copies in all cases, and I
like the idea behind memcpy_from_page_nocache().  I just think there must be a
way to make it simpler.

Re: [PATCH v2 2/3] use a nocache copy for bvecs and kvecs in copy_from_iter_nocache()

[Ross Zwisler]

On Wed, Oct 26, 2016 at 10:50:20AM -0500, Brian Boylston wrote:
> Update copy_from_iter_nocache() to use memcpy_nocache()
> for bvecs and kvecs.
> 
> Cc: Ross Zwisler 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: 
> Cc: Al Viro 
> Cc: Dan Williams 
> Signed-off-by: Brian Boylston 
> Reviewed-by: Toshi Kani 
> Reported-by: Oliver Moreno 
> ---
>  lib/iov_iter.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 7e3138c..71e4531 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -342,6 +342,13 @@ static void memcpy_from_page(char *to, struct page 
> *page, size_t offset, size_t
>   kunmap_atomic(from);
>  }
>  
> +static void memcpy_from_page_nocache(char *to, struct page *page, size_t 
> offset, size_t len)
> +{
> + char *from = kmap_atomic(page);
> + memcpy_nocache(to, from + offset, len);
> + kunmap_atomic(from);
> +}
> +
>  static void memcpy_to_page(struct page *page, size_t offset, const char 
> *from, size_t len)
>  {
>   char *to = kmap_atomic(page);
> @@ -392,9 +399,10 @@ size_t copy_from_iter_nocache(void *addr, size_t bytes, 
> struct iov_iter *i)
>   iterate_and_advance(i, bytes, v,
>   __copy_from_user_nocache((to += v.iov_len) - v.iov_len,
>v.iov_base, v.iov_len),
> - memcpy_from_page((to += v.bv_len) - v.bv_len, v.bv_page,
> -  v.bv_offset, v.bv_len),
> - memcpy((to += v.iov_len) - v.iov_len, v.iov_base, v.iov_len)
> + memcpy_from_page_nocache((to += v.bv_len) - v.bv_len,
> +  v.bv_page, v.bv_offset, v.bv_len),
> + memcpy_nocache((to += v.iov_len) - v.iov_len,
> +v.iov_base, v.iov_len)
>   )
>  
>   return bytes;
> -- 
> 2.8.3

I generally agree with Boaz's comments to your patch 1 - this feels like yet
another layer where we have indirection based on the architecture.

We already have an arch switch at memcpy_to_pmem() based on whether the
architecture supports the PMEM API.  And we already have
__copy_from_user_nocache(), which based on the architecture can map to either
a non-cached memcpy (x86_32, x86_64), or it can just map to a normal memcpy
via __copy_from_user_inatomic() (this happens in include/linux/uaccss.h, which
I believe is used for all non-x86 architectures).

memcpy_nocache() now does the same thing as __copy_from_user_nocache(), where
we define an uncached memcpy for x86_32 and x86_64, and a normal memcpy
variant for other architectures.  But, weirdly, the x86 version maps to our
to __copy_from_user_nocache(), but it on non-x86 we don't map to
__copy_from_user_nocache() and use its fallback, we provide a new fallback of
our own via a direct call to memcpy()?

And, now in copy_from_iter_nocache() on x86 we call __copy_from_user_nocache()
two different ways: directly, and indirectly through memcpy_nocache() and
memcpy_from_page_nocache()=>memcpy_nocache().

Is there any way to simplify all of this?

All in all I'm on board with doing non-temporal copies in all cases, and I
like the idea behind memcpy_from_page_nocache().  I just think there must be a
way to make it simpler.

[PATCH v6 1/2] x86/msr: Add write msr notrace

[Wanpeng Li]

From: Wanpeng Li 

Add write msr notrace, it will be used by later patch.

Suggested-by: Peter Zijlstra 
Suggested-by: Paolo Bonzini 
Cc: Ingo Molnar 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Paolo Bonzini 
Cc: Borislav Petkov 
Signed-off-by: Wanpeng Li 
---
 arch/x86/include/asm/msr.h | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index b5fee97..eec29a7 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -115,17 +115,29 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
 }
 
 /* Can be uninlined because referenced by paravirt */
-notrace static inline void native_write_msr(unsigned int msr,
+notrace static inline void __native_write_msr_notrace(unsigned int msr,
unsigned low, unsigned high)
 {
asm volatile("1: wrmsr\n"
 "2:\n"
 _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
 : : "c" (msr), "a"(low), "d" (high) : "memory");
+}
+
+/* Can be uninlined because referenced by paravirt */
+notrace static inline void native_write_msr(unsigned int msr,
+   unsigned low, unsigned high)
+{
+   __native_write_msr_notrace(msr, low, high);
if (msr_tracepoint_active(__tracepoint_write_msr))
do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
 }
 
+static inline void wrmsr_notrace(unsigned msr, unsigned low, unsigned high)
+{
+   __native_write_msr_notrace(msr, low, high);
+}
+
 /* Can be uninlined because referenced by paravirt */
 notrace static inline int native_write_msr_safe(unsigned int msr,
unsigned low, unsigned high)
-- 
1.9.1

[PATCH v6 2/2] x86/apic: x2apic write eoi msr notrace

[Wanpeng Li]

From: Wanpeng Li 

| RCU used illegally from idle CPU!
| rcu_scheduler_active = 1, debug_locks = 0
| RCU used illegally from extended quiescent state!
| no locks held by swapper/1/0.
| 
|  [] do_trace_write_msr+0x135/0x140
|  [] native_write_msr+0x20/0x30
|  [] native_apic_msr_eoi_write+0x1d/0x30
|  [] smp_reschedule_interrupt+0x1d/0x30
|  [] reschedule_interrupt+0x96/0xa0

Reschedule interrupt may be called in cpu idle state. This causes lockdep
check warning above.

As Peterz pointed out:

| So now we're making a very frequent interrupt slower because of debug 
| code.
|
| The thing is, many many smp_reschedule_interrupt() invocations don't
| actually execute anything much at all and are only send to tickle the
| return to user path (which does the actual preemption).
| 
| Having to do the whole irq_enter/irq_exit dance just for this unlikely
| debug case totally blows.

This patch converts x2apic write eoi msr to notrace to avoid the debug 
codes splash and reverts irq_enter/irq_exit dance to avoid to make a very 
frequent interrupt slower because of debug code.

Suggested-by: Peter Zijlstra 
Suggested-by: Paolo Bonzini 
Cc: Ingo Molnar 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Paolo Bonzini 
Cc: Borislav Petkov 
Signed-off-by: Wanpeng Li 
---
 arch/x86/include/asm/apic.h | 3 ++-
 arch/x86/kernel/apic/apic.c | 1 +
 arch/x86/kernel/kvm.c   | 4 ++--
 arch/x86/kernel/smp.c   | 2 --
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f5aaf6c..a5a0bcf 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -196,7 +196,7 @@ static inline void native_apic_msr_write(u32 reg, u32 v)
 
 static inline void native_apic_msr_eoi_write(u32 reg, u32 v)
 {
-   wrmsr(APIC_BASE_MSR + (APIC_EOI >> 4), APIC_EOI_ACK, 0);
+   wrmsr_notrace(APIC_BASE_MSR + (APIC_EOI >> 4), APIC_EOI_ACK, 0);
 }
 
 static inline u32 native_apic_msr_read(u32 reg)
@@ -332,6 +332,7 @@ struct apic {
 * on write for EOI.
 */
void (*eoi_write)(u32 reg, u32 v);
+   void (*native_eoi_write)(u32 reg, u32 v);
u64 (*icr_read)(void);
void (*icr_write)(u32 low, u32 high);
void (*wait_icr_idle)(void);
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 88c657b..2686894 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2263,6 +2263,7 @@ void __init apic_set_eoi_write(void (*eoi_write)(u32 reg, 
u32 v))
for (drv = __apicdrivers; drv < __apicdrivers_end; drv++) {
/* Should happen once for each apic */
WARN_ON((*drv)->eoi_write == eoi_write);
+   (*drv)->native_eoi_write = (*drv)->eoi_write;
(*drv)->eoi_write = eoi_write;
}
 }
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index edbbfc8..d230513 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -308,7 +308,7 @@ static void kvm_register_steal_time(void)
 
 static DEFINE_PER_CPU(unsigned long, kvm_apic_eoi) = KVM_PV_EOI_DISABLED;
 
-static void kvm_guest_apic_eoi_write(u32 reg, u32 val)
+notrace static void kvm_guest_apic_eoi_write(u32 reg, u32 val)
 {
/**
 * This relies on __test_and_clear_bit to modify the memory
@@ -319,7 +319,7 @@ static void kvm_guest_apic_eoi_write(u32 reg, u32 val)
 */
if (__test_and_clear_bit(KVM_PV_EOI_BIT, this_cpu_ptr(_apic_eoi)))
return;
-   apic_write(APIC_EOI, APIC_EOI_ACK);
+   apic->native_eoi_write(APIC_EOI, APIC_EOI_ACK);
 }
 
 static void kvm_guest_cpu_init(void)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index c00cb64..68f8cc2 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -261,10 +261,8 @@ static inline void __smp_reschedule_interrupt(void)
 
 __visible void smp_reschedule_interrupt(struct pt_regs *regs)
 {
-   irq_enter();
ack_APIC_irq();
__smp_reschedule_interrupt();
-   irq_exit();
/*
 * KVM uses this interrupt to force a cpu out of guest mode
 */
-- 
1.9.1

[PATCH v6 1/2] x86/msr: Add write msr notrace

[Wanpeng Li]

From: Wanpeng Li 

Add write msr notrace, it will be used by later patch.

Suggested-by: Peter Zijlstra 
Suggested-by: Paolo Bonzini 
Cc: Ingo Molnar 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Paolo Bonzini 
Cc: Borislav Petkov 
Signed-off-by: Wanpeng Li 
---
 arch/x86/include/asm/msr.h | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index b5fee97..eec29a7 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -115,17 +115,29 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
 }
 
 /* Can be uninlined because referenced by paravirt */
-notrace static inline void native_write_msr(unsigned int msr,
+notrace static inline void __native_write_msr_notrace(unsigned int msr,
unsigned low, unsigned high)
 {
asm volatile("1: wrmsr\n"
 "2:\n"
 _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
 : : "c" (msr), "a"(low), "d" (high) : "memory");
+}
+
+/* Can be uninlined because referenced by paravirt */
+notrace static inline void native_write_msr(unsigned int msr,
+   unsigned low, unsigned high)
+{
+   __native_write_msr_notrace(msr, low, high);
if (msr_tracepoint_active(__tracepoint_write_msr))
do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
 }
 
+static inline void wrmsr_notrace(unsigned msr, unsigned low, unsigned high)
+{
+   __native_write_msr_notrace(msr, low, high);
+}
+
 /* Can be uninlined because referenced by paravirt */
 notrace static inline int native_write_msr_safe(unsigned int msr,
unsigned low, unsigned high)
-- 
1.9.1

[PATCH v6 2/2] x86/apic: x2apic write eoi msr notrace

[Wanpeng Li]

From: Wanpeng Li 

| RCU used illegally from idle CPU!
| rcu_scheduler_active = 1, debug_locks = 0
| RCU used illegally from extended quiescent state!
| no locks held by swapper/1/0.
| 
|  [] do_trace_write_msr+0x135/0x140
|  [] native_write_msr+0x20/0x30
|  [] native_apic_msr_eoi_write+0x1d/0x30
|  [] smp_reschedule_interrupt+0x1d/0x30
|  [] reschedule_interrupt+0x96/0xa0

Reschedule interrupt may be called in cpu idle state. This causes lockdep
check warning above.

As Peterz pointed out:

| So now we're making a very frequent interrupt slower because of debug 
| code.
|
| The thing is, many many smp_reschedule_interrupt() invocations don't
| actually execute anything much at all and are only send to tickle the
| return to user path (which does the actual preemption).
| 
| Having to do the whole irq_enter/irq_exit dance just for this unlikely
| debug case totally blows.

This patch converts x2apic write eoi msr to notrace to avoid the debug 
codes splash and reverts irq_enter/irq_exit dance to avoid to make a very 
frequent interrupt slower because of debug code.

Suggested-by: Peter Zijlstra 
Suggested-by: Paolo Bonzini 
Cc: Ingo Molnar 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Paolo Bonzini 
Cc: Borislav Petkov 
Signed-off-by: Wanpeng Li 
---
 arch/x86/include/asm/apic.h | 3 ++-
 arch/x86/kernel/apic/apic.c | 1 +
 arch/x86/kernel/kvm.c   | 4 ++--
 arch/x86/kernel/smp.c   | 2 --
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f5aaf6c..a5a0bcf 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -196,7 +196,7 @@ static inline void native_apic_msr_write(u32 reg, u32 v)
 
 static inline void native_apic_msr_eoi_write(u32 reg, u32 v)
 {
-   wrmsr(APIC_BASE_MSR + (APIC_EOI >> 4), APIC_EOI_ACK, 0);
+   wrmsr_notrace(APIC_BASE_MSR + (APIC_EOI >> 4), APIC_EOI_ACK, 0);
 }
 
 static inline u32 native_apic_msr_read(u32 reg)
@@ -332,6 +332,7 @@ struct apic {
 * on write for EOI.
 */
void (*eoi_write)(u32 reg, u32 v);
+   void (*native_eoi_write)(u32 reg, u32 v);
u64 (*icr_read)(void);
void (*icr_write)(u32 low, u32 high);
void (*wait_icr_idle)(void);
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 88c657b..2686894 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2263,6 +2263,7 @@ void __init apic_set_eoi_write(void (*eoi_write)(u32 reg, 
u32 v))
for (drv = __apicdrivers; drv < __apicdrivers_end; drv++) {
/* Should happen once for each apic */
WARN_ON((*drv)->eoi_write == eoi_write);
+   (*drv)->native_eoi_write = (*drv)->eoi_write;
(*drv)->eoi_write = eoi_write;
}
 }
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index edbbfc8..d230513 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -308,7 +308,7 @@ static void kvm_register_steal_time(void)
 
 static DEFINE_PER_CPU(unsigned long, kvm_apic_eoi) = KVM_PV_EOI_DISABLED;
 
-static void kvm_guest_apic_eoi_write(u32 reg, u32 val)
+notrace static void kvm_guest_apic_eoi_write(u32 reg, u32 val)
 {
/**
 * This relies on __test_and_clear_bit to modify the memory
@@ -319,7 +319,7 @@ static void kvm_guest_apic_eoi_write(u32 reg, u32 val)
 */
if (__test_and_clear_bit(KVM_PV_EOI_BIT, this_cpu_ptr(_apic_eoi)))
return;
-   apic_write(APIC_EOI, APIC_EOI_ACK);
+   apic->native_eoi_write(APIC_EOI, APIC_EOI_ACK);
 }
 
 static void kvm_guest_cpu_init(void)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index c00cb64..68f8cc2 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -261,10 +261,8 @@ static inline void __smp_reschedule_interrupt(void)
 
 __visible void smp_reschedule_interrupt(struct pt_regs *regs)
 {
-   irq_enter();
ack_APIC_irq();
__smp_reschedule_interrupt();
-   irq_exit();
/*
 * KVM uses this interrupt to force a cpu out of guest mode
 */
-- 
1.9.1

Re: [RFC 0/8] Define coherent device memory node

[Anshuman Khandual]

On 10/26/2016 09:32 PM, Jerome Glisse wrote:
> On Wed, Oct 26, 2016 at 04:43:10PM +0530, Anshuman Khandual wrote:
>> On 10/26/2016 12:22 AM, Jerome Glisse wrote:
>>> On Tue, Oct 25, 2016 at 11:01:08PM +0530, Aneesh Kumar K.V wrote:
 Jerome Glisse  writes:

> On Tue, Oct 25, 2016 at 10:29:38AM +0530, Aneesh Kumar K.V wrote:
>> Jerome Glisse  writes:
>>> On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote:
>
> [...]
>
>>> You can take a look at hmm-v13 if you want to see how i do non LRU page
>>> migration. While i put most of the migration code inside hmm_migrate.c 
>>> it
>>> could easily be move to migrate.c without hmm_ prefix.
>>>
>>> There is 2 missing piece with existing migrate code. First is to put 
>>> memory
>>> allocation for destination under control of who call the migrate code. 
>>> Second
>>> is to allow offloading the copy operation to device (ie not use the CPU 
>>> to
>>> copy data).
>>>
>>> I believe same requirement also make sense for platform you are 
>>> targeting.
>>> Thus same code can be use.
>>>
>>> hmm-v13 https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v13
>>>
>>> I haven't posted this patchset yet because we are doing some 
>>> modifications
>>> to the device driver API to accomodate some new features. But the 
>>> ZONE_DEVICE
>>> changes and the overall migration code will stay the same more or less 
>>> (i have
>>> patches that move it to migrate.c and share more code with existing 
>>> migrate
>>> code).
>>>
>>> If you think i missed anything about lru and page cache please point it 
>>> to
>>> me. Because when i audited code for that i didn't see any road block 
>>> with
>>> the few fs i was looking at (ext4, xfs and core page cache code).
>>>
>>
>> The other restriction around ZONE_DEVICE is, it is not a managed zone.
>> That prevents any direct allocation from coherent device by application.
>> ie, we would like to force allocation from coherent device using
>> interface like mbind(MPOL_BIND..) . Is that possible with ZONE_DEVICE ?
>
> To achieve this we rely on device fault code path ie when device take a 
> page fault
> with help of HMM it will use existing memory if any for fault address but 
> if CPU
> page table is empty (and it is not file back vma because of readback) 
> then device
> can directly allocate device memory and HMM will update CPU page table to 
> point to
> newly allocated device memory.
>

 That is ok if the device touch the page first. What if we want the
 allocation touched first by cpu to come from GPU ?. Should we always
 depend on GPU driver to migrate such pages later from system RAM to GPU
 memory ?

>>>
>>> I am not sure what kind of workload would rather have every first CPU 
>>> access for
>>> a range to use device memory. So no my code does not handle that and it is 
>>> pointless
>>> for it as CPU can not access device memory for me.
>>>
>>> That said nothing forbid to add support for ZONE_DEVICE with mbind() like 
>>> syscall.
>>> Thought my personnal preference would still be to avoid use of such generic 
>>> syscall
>>> but have device driver set allocation policy through its own userspace API 
>>> (device
>>> driver could reuse internal of mbind() to achieve the end result).
>>>
>>> I am not saying that eveything you want to do is doable now with HMM but, 
>>> nothing
>>> preclude achieving what you want to achieve using ZONE_DEVICE. I really 
>>> don't think
>>> any of the existing mm mechanism (kswapd, lru, numa, ...) are nice fit and 
>>> can be reuse
>>> with device memory.
>>>
>>> Each device is so different from the other that i don't believe in a one 
>>> API fit all.
>>> The drm GPU subsystem of the kernel is a testimony of how little can be 
>>> share when it
>>> comes to GPU. The only common code is modesetting. Everything that deals 
>>> with how to
>>> use GPU to compute stuff is per device and most of the logic is in 
>>> userspace. So i do
>>> not see any commonality that could be abstracted at syscall level. I would 
>>> rather let
>>> device driver stack (kernel and userspace) take such decision and have the 
>>> higher level
>>> API (OpenCL, Cuda, C++17, ...) expose something that make sense for each of 
>>> them.
>>> Programmer target those high level API and they intend to use the mechanism 
>>> each offer
>>> to manage memory and memory placement. I would say forcing them to use a 
>>> second linux
>>> specific API to achieve the latter is wrong, at lest for now.
>>>
>>> So in the end if the mbind() syscall is done by the userspace side of the 
>>> device driver
>>> then why not just having the device driver communicate this through its own 
>>> kernel
>>> API (which can be much more expressive than 

[PATCH v6 0/2] x86/apic: x2apic write eoi msr notrace

[Wanpeng Li]

| RCU used illegally from idle CPU!
| rcu_scheduler_active = 1, debug_locks = 0
| RCU used illegally from extended quiescent state!
| no locks held by swapper/1/0.
| 
|  [] do_trace_write_msr+0x135/0x140
|  [] native_write_msr+0x20/0x30
|  [] native_apic_msr_eoi_write+0x1d/0x30
|  [] smp_reschedule_interrupt+0x1d/0x30
|  [] reschedule_interrupt+0x96/0xa0

Reschedule interrupt may be called in cpu idle state. This causes lockdep
check warning above.

As Peterz pointed out:

| The thing is, many many smp_reschedule_interrupt() invocations don't
| actually execute anything much at all and are only send to tickle the
| return to user path (which does the actual preemption).
| 
| Having to do the whole irq_enter/irq_exit dance just for this unlikely
| debug case totally blows.

This patchset adds x2apic write eoi msr notrace to avoid the debug codes 
splash and reverts irq_enter/irq_exit dance to avoid to make a very frequent 
interrupt slower because of debug code.

v5 -> v6:
 * split the patch 
 * don't duplicate the inline asm

v4 -> v5:
 * add notrace mark 

v3 -> v4: 
 * add notrace mark 

v2 -> v3:
 * revert irq_enter/irq_exit() since it is merged

v1 -> v2:
 * add write msr notrace to avoid debug codes splash instead of slowdown 
   a very frequent interrupt


Wanpeng Li (2):
  x86/msr: Add write msr notrace
  x86/apic: x2apic write eoi msr notrace

 arch/x86/include/asm/apic.h |  3 ++-
 arch/x86/include/asm/msr.h  | 14 +-
 arch/x86/kernel/apic/apic.c |  1 +
 arch/x86/kernel/kvm.c   |  4 ++--
 arch/x86/kernel/smp.c   |  2 --
 5 files changed, 18 insertions(+), 6 deletions(-)

-- 
1.9.1

Re: [RFC 0/8] Define coherent device memory node

[Anshuman Khandual]

On 10/26/2016 09:32 PM, Jerome Glisse wrote:
> On Wed, Oct 26, 2016 at 04:43:10PM +0530, Anshuman Khandual wrote:
>> On 10/26/2016 12:22 AM, Jerome Glisse wrote:
>>> On Tue, Oct 25, 2016 at 11:01:08PM +0530, Aneesh Kumar K.V wrote:
 Jerome Glisse  writes:

> On Tue, Oct 25, 2016 at 10:29:38AM +0530, Aneesh Kumar K.V wrote:
>> Jerome Glisse  writes:
>>> On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote:
>
> [...]
>
>>> You can take a look at hmm-v13 if you want to see how i do non LRU page
>>> migration. While i put most of the migration code inside hmm_migrate.c 
>>> it
>>> could easily be move to migrate.c without hmm_ prefix.
>>>
>>> There is 2 missing piece with existing migrate code. First is to put 
>>> memory
>>> allocation for destination under control of who call the migrate code. 
>>> Second
>>> is to allow offloading the copy operation to device (ie not use the CPU 
>>> to
>>> copy data).
>>>
>>> I believe same requirement also make sense for platform you are 
>>> targeting.
>>> Thus same code can be use.
>>>
>>> hmm-v13 https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v13
>>>
>>> I haven't posted this patchset yet because we are doing some 
>>> modifications
>>> to the device driver API to accomodate some new features. But the 
>>> ZONE_DEVICE
>>> changes and the overall migration code will stay the same more or less 
>>> (i have
>>> patches that move it to migrate.c and share more code with existing 
>>> migrate
>>> code).
>>>
>>> If you think i missed anything about lru and page cache please point it 
>>> to
>>> me. Because when i audited code for that i didn't see any road block 
>>> with
>>> the few fs i was looking at (ext4, xfs and core page cache code).
>>>
>>
>> The other restriction around ZONE_DEVICE is, it is not a managed zone.
>> That prevents any direct allocation from coherent device by application.
>> ie, we would like to force allocation from coherent device using
>> interface like mbind(MPOL_BIND..) . Is that possible with ZONE_DEVICE ?
>
> To achieve this we rely on device fault code path ie when device take a 
> page fault
> with help of HMM it will use existing memory if any for fault address but 
> if CPU
> page table is empty (and it is not file back vma because of readback) 
> then device
> can directly allocate device memory and HMM will update CPU page table to 
> point to
> newly allocated device memory.
>

 That is ok if the device touch the page first. What if we want the
 allocation touched first by cpu to come from GPU ?. Should we always
 depend on GPU driver to migrate such pages later from system RAM to GPU
 memory ?

>>>
>>> I am not sure what kind of workload would rather have every first CPU 
>>> access for
>>> a range to use device memory. So no my code does not handle that and it is 
>>> pointless
>>> for it as CPU can not access device memory for me.
>>>
>>> That said nothing forbid to add support for ZONE_DEVICE with mbind() like 
>>> syscall.
>>> Thought my personnal preference would still be to avoid use of such generic 
>>> syscall
>>> but have device driver set allocation policy through its own userspace API 
>>> (device
>>> driver could reuse internal of mbind() to achieve the end result).
>>>
>>> I am not saying that eveything you want to do is doable now with HMM but, 
>>> nothing
>>> preclude achieving what you want to achieve using ZONE_DEVICE. I really 
>>> don't think
>>> any of the existing mm mechanism (kswapd, lru, numa, ...) are nice fit and 
>>> can be reuse
>>> with device memory.
>>>
>>> Each device is so different from the other that i don't believe in a one 
>>> API fit all.
>>> The drm GPU subsystem of the kernel is a testimony of how little can be 
>>> share when it
>>> comes to GPU. The only common code is modesetting. Everything that deals 
>>> with how to
>>> use GPU to compute stuff is per device and most of the logic is in 
>>> userspace. So i do
>>> not see any commonality that could be abstracted at syscall level. I would 
>>> rather let
>>> device driver stack (kernel and userspace) take such decision and have the 
>>> higher level
>>> API (OpenCL, Cuda, C++17, ...) expose something that make sense for each of 
>>> them.
>>> Programmer target those high level API and they intend to use the mechanism 
>>> each offer
>>> to manage memory and memory placement. I would say forcing them to use a 
>>> second linux
>>> specific API to achieve the latter is wrong, at lest for now.
>>>
>>> So in the end if the mbind() syscall is done by the userspace side of the 
>>> device driver
>>> then why not just having the device driver communicate this through its own 
>>> kernel
>>> API (which can be much more expressive than what standardize syscall 
>>> offers). I 

[PATCH v6 0/2] x86/apic: x2apic write eoi msr notrace

[Wanpeng Li]

| RCU used illegally from idle CPU!
| rcu_scheduler_active = 1, debug_locks = 0
| RCU used illegally from extended quiescent state!
| no locks held by swapper/1/0.
| 
|  [] do_trace_write_msr+0x135/0x140
|  [] native_write_msr+0x20/0x30
|  [] native_apic_msr_eoi_write+0x1d/0x30
|  [] smp_reschedule_interrupt+0x1d/0x30
|  [] reschedule_interrupt+0x96/0xa0

Reschedule interrupt may be called in cpu idle state. This causes lockdep
check warning above.

As Peterz pointed out:

| The thing is, many many smp_reschedule_interrupt() invocations don't
| actually execute anything much at all and are only send to tickle the
| return to user path (which does the actual preemption).
| 
| Having to do the whole irq_enter/irq_exit dance just for this unlikely
| debug case totally blows.

This patchset adds x2apic write eoi msr notrace to avoid the debug codes 
splash and reverts irq_enter/irq_exit dance to avoid to make a very frequent 
interrupt slower because of debug code.

v5 -> v6:
 * split the patch 
 * don't duplicate the inline asm

v4 -> v5:
 * add notrace mark 

v3 -> v4: 
 * add notrace mark 

v2 -> v3:
 * revert irq_enter/irq_exit() since it is merged

v1 -> v2:
 * add write msr notrace to avoid debug codes splash instead of slowdown 
   a very frequent interrupt


Wanpeng Li (2):
  x86/msr: Add write msr notrace
  x86/apic: x2apic write eoi msr notrace

 arch/x86/include/asm/apic.h |  3 ++-
 arch/x86/include/asm/msr.h  | 14 +-
 arch/x86/kernel/apic/apic.c |  1 +
 arch/x86/kernel/kvm.c   |  4 ++--
 arch/x86/kernel/smp.c   |  2 --
 5 files changed, 18 insertions(+), 6 deletions(-)

-- 
1.9.1

[GIT PULL] Keys fixes

[James Morris]

Please pull these fixes from David Howells:


 (1) Fix a buffer overflow when displaying /proc/keys [CVE-2016-7042].

 (2) Fix broken initialisation in the big_key implementation that can
 result in an oops.

 (3) Make big_key depend on having a random number generator available in
 Kconfig.

---

The following changes since commit 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942:

  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2016-10-24 
21:34:13 -0700)

are available in the git repository at:

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

Artem Savkov (1):
  security/keys: make BIG_KEYS dependent on stdrng.

David Howells (2):
  KEYS: Fix short sprintf buffer in /proc/keys show function
  KEYS: Sort out big_key initialisation

 security/keys/Kconfig   |2 +-
 security/keys/big_key.c |   59 +-
 security/keys/proc.c|2 +-
 3 files changed, 34 insertions(+), 29 deletions(-)

[GIT PULL] Keys fixes

[James Morris]

Please pull these fixes from David Howells:


 (1) Fix a buffer overflow when displaying /proc/keys [CVE-2016-7042].

 (2) Fix broken initialisation in the big_key implementation that can
 result in an oops.

 (3) Make big_key depend on having a random number generator available in
 Kconfig.

---

The following changes since commit 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942:

  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2016-10-24 
21:34:13 -0700)

are available in the git repository at:

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

Artem Savkov (1):
  security/keys: make BIG_KEYS dependent on stdrng.

David Howells (2):
  KEYS: Fix short sprintf buffer in /proc/keys show function
  KEYS: Sort out big_key initialisation

 security/keys/Kconfig   |2 +-
 security/keys/big_key.c |   59 +-
 security/keys/proc.c|2 +-
 3 files changed, 34 insertions(+), 29 deletions(-)

Re: [PATCH] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

[Lukasz Majewski]

Hi Jingoo,

> On Monday, October 24, 2016, Lukasz Majewski wrote:
> > 
> > Hi Jingoo,
> > 
> > > On Saturday, October 22, 2016, Lukasz Majewski wrote:
> > > >
> > > > The commit: a55944ca82d287ca099ca90413af857af9086773 has posed
> > > > some extra
> 
> Please add the 'subject' of patch as below.
> 
> The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> properties when necessary ") has posted some extra.

Ok, I will add such information.

However, I'm more interested in some technical comments regarding
proposed fix.

Could you provide some feedback on the technical side of the patch?

Best regards,
Łukasz Majewski

> 
> Best regards,
> Jingoo Han
> 
> 
> > >
> > > Please add the subject of the patch, in order to let people know
> > > which patch you mention exactly. Please loot at other commits that
> > > fixed bugs or behavior
> > > of other patches.
> > 
> > Thanks for the tip.
> > 
> > The mentioned patch:
> > 
> > commit a55944ca82d287ca099ca90413af857af9086773
> > Author: Liu Ying 
> > Date:   Thu Apr 3 14:48:54 2014 -0700
> > 
> > backlight: update bd state & fb_blank properties when necessary
> > 
> > We don't have to update the state and fb_blank properties of a
> > backlight
> > device every time a blanking or unblanking event comes because
> > they may
> > have already been what we want.  Another thought is that one
> > backlight device may be shared by multiple framebuffers.  The
> > backlight driver should take the backlight device as a resource
> > shared by all the associated framebuffers.
> > 
> > This patch adds some logic to record each framebuffer's
> > backlight usage
> > to determine the backlight device use count and whether the two
> > properties should be updated or not.  To be more specific, only
> > one unblank operation on a certain blanked framebuffer may increase
> > the backlight device's use count by one, while one blank operation
> > on a certain unblanked framebuffer may decrease the use count by
> > one, because
> > the userspace is likely to unblank an unblanked framebuffer or
> > blank a blanked framebuffer.
> > 
> > 
> > Could you provide more feedback regarding provided fix?
> > 
> > Thanks in advance,
> > 
> > Łukasz Majewski
> > 
> > >
> > > > restrictions on blanking and unblanking frame buffer device.
> > > >
> > > > Unfortunately, pwm_bl driver's probe did not initialize members
> > > > of struct backlight_device necessary for further blank/unblank
> > > > operation.
> > > >
> > > > This code in case of initial unblank of backlight device
> > > > (default behaviour) sets use_count to 1 and marks this
> > > > particular backlight device as used by all available fb devices
> > > > (since it is not known during probe how much and which fb
> > > > devices will be assigned).
> > > >
> > > > Without this code, the backlight works properly until one tries
> > > > to blank it manually from sysfs with "echo 1
> > > > > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and
> > > > > use_count were both set to 0, the logic at
> > > > fb_notifier_callback (@backlight.c) thought that we didn't turn
> > > > on (unblanked) the backlight device and refuses to disable
> > > > (blank) it. As a result we see garbage from fb displayed.
> > > >
> > > >
> > > > Signed-off-by: Lukasz Majewski 
> > > > ---
> > > > The patch has been tested on i.MX6q with vanilla 4.7 and 4.8
> > > > kernels. It applies on 4.9-rcX SHA1:
> > > > dcd4693cf47801b7d988ea897519de90dfd25d17.
> > > >
> > > > ---
> > > >  drivers/video/backlight/pwm_bl.c | 10 +-
> > > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > b/drivers/video/backlight/pwm_bl.c
> > > > index 8040fd6..def39e8 100644
> > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > @@ -203,7 +203,7 @@ static int pwm_backlight_probe(struct
> > > > platform_device *pdev)
> > > > struct pwm_bl_data *pb;
> > > > int initial_blank = FB_BLANK_UNBLANK;
> > > > struct pwm_args pargs;
> > > > -   int ret;
> > > > +   int ret, i;
> > > >
> > > > if (!data) {
> > > > ret = pwm_backlight_parse_dt(>dev,
> > > > ); @@ - 349,6 +349,14 @@ static int
> > > > pwm_backlight_probe(struct platform_device *pdev)
> > > >
> > > > bl->props.brightness = data->dft_brightness;
> > > > bl->props.power = initial_blank;
> > > > +
> > > > +   if (initial_blank == FB_BLANK_UNBLANK) {
> > > > +   for (i = 0; i < FB_MAX; i++)
> > > > +   bl->fb_bl_on[i] = true;
> > > > +
> > > > +   bl->use_count = 1;
> > > > +   }
> > > > +
> > > > backlight_update_status(bl);
> > > >
> > > > platform_set_drvdata(pdev, bl);
> > > > --
> > > > 2.1.4
> > >
> > >
> 
> 



pgp_SasqNcJvD.pgp
Description: OpenPGP digital signature

Re: [PATCH] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

[Lukasz Majewski]

Hi Jingoo,

> On Monday, October 24, 2016, Lukasz Majewski wrote:
> > 
> > Hi Jingoo,
> > 
> > > On Saturday, October 22, 2016, Lukasz Majewski wrote:
> > > >
> > > > The commit: a55944ca82d287ca099ca90413af857af9086773 has posed
> > > > some extra
> 
> Please add the 'subject' of patch as below.
> 
> The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> properties when necessary ") has posted some extra.

Ok, I will add such information.

However, I'm more interested in some technical comments regarding
proposed fix.

Could you provide some feedback on the technical side of the patch?

Best regards,
Łukasz Majewski

> 
> Best regards,
> Jingoo Han
> 
> 
> > >
> > > Please add the subject of the patch, in order to let people know
> > > which patch you mention exactly. Please loot at other commits that
> > > fixed bugs or behavior
> > > of other patches.
> > 
> > Thanks for the tip.
> > 
> > The mentioned patch:
> > 
> > commit a55944ca82d287ca099ca90413af857af9086773
> > Author: Liu Ying 
> > Date:   Thu Apr 3 14:48:54 2014 -0700
> > 
> > backlight: update bd state & fb_blank properties when necessary
> > 
> > We don't have to update the state and fb_blank properties of a
> > backlight
> > device every time a blanking or unblanking event comes because
> > they may
> > have already been what we want.  Another thought is that one
> > backlight device may be shared by multiple framebuffers.  The
> > backlight driver should take the backlight device as a resource
> > shared by all the associated framebuffers.
> > 
> > This patch adds some logic to record each framebuffer's
> > backlight usage
> > to determine the backlight device use count and whether the two
> > properties should be updated or not.  To be more specific, only
> > one unblank operation on a certain blanked framebuffer may increase
> > the backlight device's use count by one, while one blank operation
> > on a certain unblanked framebuffer may decrease the use count by
> > one, because
> > the userspace is likely to unblank an unblanked framebuffer or
> > blank a blanked framebuffer.
> > 
> > 
> > Could you provide more feedback regarding provided fix?
> > 
> > Thanks in advance,
> > 
> > Łukasz Majewski
> > 
> > >
> > > > restrictions on blanking and unblanking frame buffer device.
> > > >
> > > > Unfortunately, pwm_bl driver's probe did not initialize members
> > > > of struct backlight_device necessary for further blank/unblank
> > > > operation.
> > > >
> > > > This code in case of initial unblank of backlight device
> > > > (default behaviour) sets use_count to 1 and marks this
> > > > particular backlight device as used by all available fb devices
> > > > (since it is not known during probe how much and which fb
> > > > devices will be assigned).
> > > >
> > > > Without this code, the backlight works properly until one tries
> > > > to blank it manually from sysfs with "echo 1
> > > > > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and
> > > > > use_count were both set to 0, the logic at
> > > > fb_notifier_callback (@backlight.c) thought that we didn't turn
> > > > on (unblanked) the backlight device and refuses to disable
> > > > (blank) it. As a result we see garbage from fb displayed.
> > > >
> > > >
> > > > Signed-off-by: Lukasz Majewski 
> > > > ---
> > > > The patch has been tested on i.MX6q with vanilla 4.7 and 4.8
> > > > kernels. It applies on 4.9-rcX SHA1:
> > > > dcd4693cf47801b7d988ea897519de90dfd25d17.
> > > >
> > > > ---
> > > >  drivers/video/backlight/pwm_bl.c | 10 +-
> > > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > b/drivers/video/backlight/pwm_bl.c
> > > > index 8040fd6..def39e8 100644
> > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > @@ -203,7 +203,7 @@ static int pwm_backlight_probe(struct
> > > > platform_device *pdev)
> > > > struct pwm_bl_data *pb;
> > > > int initial_blank = FB_BLANK_UNBLANK;
> > > > struct pwm_args pargs;
> > > > -   int ret;
> > > > +   int ret, i;
> > > >
> > > > if (!data) {
> > > > ret = pwm_backlight_parse_dt(>dev,
> > > > ); @@ - 349,6 +349,14 @@ static int
> > > > pwm_backlight_probe(struct platform_device *pdev)
> > > >
> > > > bl->props.brightness = data->dft_brightness;
> > > > bl->props.power = initial_blank;
> > > > +
> > > > +   if (initial_blank == FB_BLANK_UNBLANK) {
> > > > +   for (i = 0; i < FB_MAX; i++)
> > > > +   bl->fb_bl_on[i] = true;
> > > > +
> > > > +   bl->use_count = 1;
> > > > +   }
> > > > +
> > > > backlight_update_status(bl);
> > > >
> > > > platform_set_drvdata(pdev, bl);
> > > > --
> > > > 2.1.4
> > >
> > >
> 
> 



pgp_SasqNcJvD.pgp
Description: OpenPGP digital signature

Re: [PATCH] net: avoid uninitialized variable

[Gao Feng]

On Thu, Oct 27, 2016 at 11:56 AM, zhongjiang  wrote:
> From: zhong jiang 
>
> when I compiler the newest kernel, I hit the following error with
> Werror=may-uninitalized.
>
> net/core/flow_dissector.c: In function ?._skb_flow_dissect?
> include/uapi/linux/swab.h:100:46: error: ?.lan?.may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
> net/core/flow_dissector.c:248:26: note: ?.lan?.was declared here
>
> This adds an additional check for proto to explicitly tell the compiler
> that vlan pointer have the correct value before it is used.
>
> Signed-off-by: zhong jiang 
> ---
>  net/core/flow_dissector.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 1a7b80f..a04d9cf 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> }
> case htons(ETH_P_8021AD):
> case htons(ETH_P_8021Q): {
> -   const struct vlan_hdr *vlan;
> +   const struct vlan_hdr *vlan = NULL;
>
> if (skb_vlan_tag_present(skb))
> proto = skb->protocol;
> @@ -276,7 +276,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
> key_vlan->vlan_priority =
> (skb_vlan_tag_get_prio(skb) >> 
> VLAN_PRIO_SHIFT);
> -   } else {
> +   } else if (proto == cpu_to_be16(ETH_P_8021Q) ||
> +   proto == 
> cpu_to_be16(ETH_P_8021AD)) {
> key_vlan->vlan_id = ntohs(vlan->h_vlan_TCI) &
> VLAN_VID_MASK;
> key_vlan->vlan_priority =
> --
> 1.8.3.1
>

It seems there is one similar patch already.
You could refer to https://patchwork.kernel.org/patch/9389565/

Regards
Feng

Re: [PATCH] net: avoid uninitialized variable

[Gao Feng]

On Thu, Oct 27, 2016 at 11:56 AM, zhongjiang  wrote:
> From: zhong jiang 
>
> when I compiler the newest kernel, I hit the following error with
> Werror=may-uninitalized.
>
> net/core/flow_dissector.c: In function ?._skb_flow_dissect?
> include/uapi/linux/swab.h:100:46: error: ?.lan?.may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
> net/core/flow_dissector.c:248:26: note: ?.lan?.was declared here
>
> This adds an additional check for proto to explicitly tell the compiler
> that vlan pointer have the correct value before it is used.
>
> Signed-off-by: zhong jiang 
> ---
>  net/core/flow_dissector.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 1a7b80f..a04d9cf 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> }
> case htons(ETH_P_8021AD):
> case htons(ETH_P_8021Q): {
> -   const struct vlan_hdr *vlan;
> +   const struct vlan_hdr *vlan = NULL;
>
> if (skb_vlan_tag_present(skb))
> proto = skb->protocol;
> @@ -276,7 +276,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
> key_vlan->vlan_priority =
> (skb_vlan_tag_get_prio(skb) >> 
> VLAN_PRIO_SHIFT);
> -   } else {
> +   } else if (proto == cpu_to_be16(ETH_P_8021Q) ||
> +   proto == 
> cpu_to_be16(ETH_P_8021AD)) {
> key_vlan->vlan_id = ntohs(vlan->h_vlan_TCI) &
> VLAN_VID_MASK;
> key_vlan->vlan_priority =
> --
> 1.8.3.1
>

It seems there is one similar patch already.
You could refer to https://patchwork.kernel.org/patch/9389565/

Regards
Feng

[PATCH] net: avoid uninitialized variable

[zhongjiang]

From: zhong jiang 

when I compiler the newest kernel, I hit the following error with
Werror=may-uninitalized.

net/core/flow_dissector.c: In function ?._skb_flow_dissect?
include/uapi/linux/swab.h:100:46: error: ?.lan?.may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
net/core/flow_dissector.c:248:26: note: ?.lan?.was declared here

This adds an additional check for proto to explicitly tell the compiler
that vlan pointer have the correct value before it is used.

Signed-off-by: zhong jiang 
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1a7b80f..a04d9cf 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
}
case htons(ETH_P_8021AD):
case htons(ETH_P_8021Q): {
-   const struct vlan_hdr *vlan;
+   const struct vlan_hdr *vlan = NULL;
 
if (skb_vlan_tag_present(skb))
proto = skb->protocol;
@@ -276,7 +276,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
key_vlan->vlan_priority =
(skb_vlan_tag_get_prio(skb) >> 
VLAN_PRIO_SHIFT);
-   } else {
+   } else if (proto == cpu_to_be16(ETH_P_8021Q) ||
+   proto == 
cpu_to_be16(ETH_P_8021AD)) {
key_vlan->vlan_id = ntohs(vlan->h_vlan_TCI) &
VLAN_VID_MASK;
key_vlan->vlan_priority =
-- 
1.8.3.1

[PATCH] net: avoid uninitialized variable

[zhongjiang]

From: zhong jiang 

when I compiler the newest kernel, I hit the following error with
Werror=may-uninitalized.

net/core/flow_dissector.c: In function ?._skb_flow_dissect?
include/uapi/linux/swab.h:100:46: error: ?.lan?.may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
net/core/flow_dissector.c:248:26: note: ?.lan?.was declared here

This adds an additional check for proto to explicitly tell the compiler
that vlan pointer have the correct value before it is used.

Signed-off-by: zhong jiang 
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1a7b80f..a04d9cf 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
}
case htons(ETH_P_8021AD):
case htons(ETH_P_8021Q): {
-   const struct vlan_hdr *vlan;
+   const struct vlan_hdr *vlan = NULL;
 
if (skb_vlan_tag_present(skb))
proto = skb->protocol;
@@ -276,7 +276,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
key_vlan->vlan_priority =
(skb_vlan_tag_get_prio(skb) >> 
VLAN_PRIO_SHIFT);
-   } else {
+   } else if (proto == cpu_to_be16(ETH_P_8021Q) ||
+   proto == 
cpu_to_be16(ETH_P_8021AD)) {
key_vlan->vlan_id = ntohs(vlan->h_vlan_TCI) &
VLAN_VID_MASK;
key_vlan->vlan_priority =
-- 
1.8.3.1

Re: [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES

[Leizhen (ThunderTown)]

On 2016/10/27 2:36, Will Deacon wrote:
> On Tue, Oct 25, 2016 at 10:59:18AM +0800, Zhen Lei wrote:
>> Some numa nodes may have no memory. For example:
>> 1) a node has no memory bank plugged.
>> 2) a node has no memory bank slots.
>>
>> To ensure percpu variable areas and numa control blocks of the
>> memoryless numa nodes to be allocated from the nearest available node to
>> improve performance, defined node_distance_ready. And make its value to be
>> true immediately after node distances have been initialized.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/Kconfig| 4 
>>  arch/arm64/include/asm/numa.h | 3 +++
>>  arch/arm64/mm/numa.c  | 6 +-
>>  3 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 30398db..648dd13 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -609,6 +609,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>>  def_bool y
>>  depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> +def_bool y
>> +depends on NUMA
> 
> Given that patch 1 and the associated node_distance_ready stuff is all
> an unqualified performance optimisation, is there any merit in just
> enabling HAVE_MEMORYLESS_NODES in Kconfig and then optimising things as
> a separate series when you have numbers to back it up?
HAVE_MEMORYLESS_NODES is also an performance optimisation for memoryless 
scenario.
For example:
node0 is a memoryless node, node1 is the nearest node of node0.
We want to allocate memory from node0, normally memory manager will try node0 
first, then node1.
But we have already kwown that node0 have no memory, so we can tell memory 
manager directly try
node1 first. So HAVE_MEMORYLESS_NODES is used to skip the memoryless nodes, 
don't try them.

So I think the title of this patch is misleading, I will rewrite it in V2.

Or, Do you mean separate it into a new patch?


> 
> Will
> 
> .
> 

Re: [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES

[Leizhen (ThunderTown)]

On 2016/10/27 2:36, Will Deacon wrote:
> On Tue, Oct 25, 2016 at 10:59:18AM +0800, Zhen Lei wrote:
>> Some numa nodes may have no memory. For example:
>> 1) a node has no memory bank plugged.
>> 2) a node has no memory bank slots.
>>
>> To ensure percpu variable areas and numa control blocks of the
>> memoryless numa nodes to be allocated from the nearest available node to
>> improve performance, defined node_distance_ready. And make its value to be
>> true immediately after node distances have been initialized.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/Kconfig| 4 
>>  arch/arm64/include/asm/numa.h | 3 +++
>>  arch/arm64/mm/numa.c  | 6 +-
>>  3 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 30398db..648dd13 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -609,6 +609,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>>  def_bool y
>>  depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> +def_bool y
>> +depends on NUMA
> 
> Given that patch 1 and the associated node_distance_ready stuff is all
> an unqualified performance optimisation, is there any merit in just
> enabling HAVE_MEMORYLESS_NODES in Kconfig and then optimising things as
> a separate series when you have numbers to back it up?
HAVE_MEMORYLESS_NODES is also an performance optimisation for memoryless 
scenario.
For example:
node0 is a memoryless node, node1 is the nearest node of node0.
We want to allocate memory from node0, normally memory manager will try node0 
first, then node1.
But we have already kwown that node0 have no memory, so we can tell memory 
manager directly try
node1 first. So HAVE_MEMORYLESS_NODES is used to skip the memoryless nodes, 
don't try them.

So I think the title of this patch is misleading, I will rewrite it in V2.

Or, Do you mean separate it into a new patch?


> 
> Will
> 
> .
> 

[PATCH V3] mfd: wm8994-core: Don't use managed regulator bulk get API

[Viresh Kumar]

The kernel WARNs and then crashes today if wm8994_device_init() fails
after calling devm_regulator_bulk_get().

That happens because there are multiple devices involved here and the
order in which resources are freed isn't correct.

The regulators are added as children of wm8994->dev.
devm_regulator_bulk_get() receives wm8994->dev as the device, though it
gets the same regulators which were added as children of wm8994->dev
earlier.

During failures, the children are removed first and the core eventually
calls regulator_unregister() for them. As regulator_put() was never done
for them (opposite of devm_regulator_bulk_get()), the kernel WARNs at

WARN_ON(rdev->open_count);

And eventually it crashes from debugfs_remove_recursive().

x--x

 wm8994 3-001a: Device is not a WM8994, ID is 0
 [ cut here ]
 WARNING: CPU: 0 PID: 1 at 
/mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 
regulator_unregister+0xc8/0xd0
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00154-g54fe84cbd50b #41
 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
 [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
 [] (show_stack) from [] (dump_stack+0x88/0x9c)
 [] (dump_stack) from [] (__warn+0xe8/0x100)
 [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
 [] (warn_slowpath_null) from [] 
(regulator_unregister+0xc8/0xd0)
 [] (regulator_unregister) from [] 
(release_nodes+0x16c/0x1dc)
 [] (release_nodes) from [] 
(__device_release_driver+0x8c/0x110)
 [] (__device_release_driver) from [] 
(device_release_driver+0x1c/0x28)
 [] (device_release_driver) from [] 
(bus_remove_device+0xd8/0x104)
 [] (bus_remove_device) from [] (device_del+0x10c/0x218)
 [] (device_del) from [] (platform_device_del+0x1c/0x88)
 [] (platform_device_del) from [] 
(platform_device_unregister+0xc/0x20)
 [] (platform_device_unregister) from [] 
(mfd_remove_devices_fn+0x5c/0x64)
 [] (mfd_remove_devices_fn) from [] 
(device_for_each_child_reverse+0x4c/0x78)
 [] (device_for_each_child_reverse) from [] 
(mfd_remove_devices+0x20/0x30)
 [] (mfd_remove_devices) from [] 
(wm8994_device_init+0x2ac/0x7f0)
 [] (wm8994_device_init) from [] 
(i2c_device_probe+0x178/0x1fc)
 [] (i2c_device_probe) from [] 
(driver_probe_device+0x214/0x2c0)
 [] (driver_probe_device) from [] 
(__driver_attach+0xac/0xb0)
 [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
 [] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
 [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
 [] (driver_register) from [] 
(i2c_register_driver+0x34/0x84)
 [] (i2c_register_driver) from [] 
(do_one_initcall+0x40/0x170)
 [] (do_one_initcall) from [] 
(kernel_init_freeable+0x15c/0x1fc)
 [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
 [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
 ---[ end trace 0919d3d0bc998260 ]---
 [ cut here ]
 WARNING: CPU: 0 PID: 1 at 
/mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 
regulator_unregister+0xc8/0xd0
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW   
4.8.0-rc6-00154-g54fe84cbd50b #41
 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
 [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
 [] (show_stack) from [] (dump_stack+0x88/0x9c)
 [] (dump_stack) from [] (__warn+0xe8/0x100)
 [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
 [] (warn_slowpath_null) from [] 
(regulator_unregister+0xc8/0xd0)
 [] (regulator_unregister) from [] 
(release_nodes+0x16c/0x1dc)
 [] (release_nodes) from [] 
(__device_release_driver+0x8c/0x110)
 [] (__device_release_driver) from [] 
(device_release_driver+0x1c/0x28)
 [] (device_release_driver) from [] 
(bus_remove_device+0xd8/0x104)
 [] (bus_remove_device) from [] (device_del+0x10c/0x218)
 [] (device_del) from [] (platform_device_del+0x1c/0x88)
 wm8994 3-001a: Device is not a WM8994, ID is 0
 [ cut here ]
 WARNING: CPU: 0 PID: 1 at 
/mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 
regulator_unregister+0xc8/0xd0
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00154-g54fe84cbd50b #41
 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
 [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
 [] (show_stack) from [] (dump_stack+0x88/0x9c)
 [] (dump_stack) from [] (__warn+0xe8/0x100)
 [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
 [] (warn_slowpath_null) from [] 
(regulator_unregister+0xc8/0xd0)
 [] (regulator_unregister) from [] 
(release_nodes+0x16c/0x1dc)
 [] (release_nodes) from [] 
(__device_release_driver+0x8c/0x110)
 [] (__device_release_driver) from [] 
(device_release_driver+0x1c/0x28)
 [] (device_release_driver) from [] 
(bus_remove_device+0xd8/0x104)
 [] (bus_remove_device) from [] (device_del+0x10c/0x218)
 [] (device_del) from [] (platform_device_del+0x1c/0x88)
 [] (platform_device_del) from [] 
(platform_device_unregister+0xc/0x20)
 [] (platform_device_unregister) 

[PATCH V3] mfd: wm8994-core: Don't use managed regulator bulk get API

[Viresh Kumar]

The kernel WARNs and then crashes today if wm8994_device_init() fails
after calling devm_regulator_bulk_get().

That happens because there are multiple devices involved here and the
order in which resources are freed isn't correct.

The regulators are added as children of wm8994->dev.
devm_regulator_bulk_get() receives wm8994->dev as the device, though it
gets the same regulators which were added as children of wm8994->dev
earlier.

During failures, the children are removed first and the core eventually
calls regulator_unregister() for them. As regulator_put() was never done
for them (opposite of devm_regulator_bulk_get()), the kernel WARNs at

WARN_ON(rdev->open_count);

And eventually it crashes from debugfs_remove_recursive().

x--x

 wm8994 3-001a: Device is not a WM8994, ID is 0
 [ cut here ]
 WARNING: CPU: 0 PID: 1 at 
/mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 
regulator_unregister+0xc8/0xd0
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00154-g54fe84cbd50b #41
 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
 [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
 [] (show_stack) from [] (dump_stack+0x88/0x9c)
 [] (dump_stack) from [] (__warn+0xe8/0x100)
 [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
 [] (warn_slowpath_null) from [] 
(regulator_unregister+0xc8/0xd0)
 [] (regulator_unregister) from [] 
(release_nodes+0x16c/0x1dc)
 [] (release_nodes) from [] 
(__device_release_driver+0x8c/0x110)
 [] (__device_release_driver) from [] 
(device_release_driver+0x1c/0x28)
 [] (device_release_driver) from [] 
(bus_remove_device+0xd8/0x104)
 [] (bus_remove_device) from [] (device_del+0x10c/0x218)
 [] (device_del) from [] (platform_device_del+0x1c/0x88)
 [] (platform_device_del) from [] 
(platform_device_unregister+0xc/0x20)
 [] (platform_device_unregister) from [] 
(mfd_remove_devices_fn+0x5c/0x64)
 [] (mfd_remove_devices_fn) from [] 
(device_for_each_child_reverse+0x4c/0x78)
 [] (device_for_each_child_reverse) from [] 
(mfd_remove_devices+0x20/0x30)
 [] (mfd_remove_devices) from [] 
(wm8994_device_init+0x2ac/0x7f0)
 [] (wm8994_device_init) from [] 
(i2c_device_probe+0x178/0x1fc)
 [] (i2c_device_probe) from [] 
(driver_probe_device+0x214/0x2c0)
 [] (driver_probe_device) from [] 
(__driver_attach+0xac/0xb0)
 [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
 [] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
 [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
 [] (driver_register) from [] 
(i2c_register_driver+0x34/0x84)
 [] (i2c_register_driver) from [] 
(do_one_initcall+0x40/0x170)
 [] (do_one_initcall) from [] 
(kernel_init_freeable+0x15c/0x1fc)
 [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
 [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
 ---[ end trace 0919d3d0bc998260 ]---
 [ cut here ]
 WARNING: CPU: 0 PID: 1 at 
/mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 
regulator_unregister+0xc8/0xd0
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW   
4.8.0-rc6-00154-g54fe84cbd50b #41
 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
 [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
 [] (show_stack) from [] (dump_stack+0x88/0x9c)
 [] (dump_stack) from [] (__warn+0xe8/0x100)
 [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
 [] (warn_slowpath_null) from [] 
(regulator_unregister+0xc8/0xd0)
 [] (regulator_unregister) from [] 
(release_nodes+0x16c/0x1dc)
 [] (release_nodes) from [] 
(__device_release_driver+0x8c/0x110)
 [] (__device_release_driver) from [] 
(device_release_driver+0x1c/0x28)
 [] (device_release_driver) from [] 
(bus_remove_device+0xd8/0x104)
 [] (bus_remove_device) from [] (device_del+0x10c/0x218)
 [] (device_del) from [] (platform_device_del+0x1c/0x88)
 wm8994 3-001a: Device is not a WM8994, ID is 0
 [ cut here ]
 WARNING: CPU: 0 PID: 1 at 
/mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 
regulator_unregister+0xc8/0xd0
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00154-g54fe84cbd50b #41
 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
 [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
 [] (show_stack) from [] (dump_stack+0x88/0x9c)
 [] (dump_stack) from [] (__warn+0xe8/0x100)
 [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
 [] (warn_slowpath_null) from [] 
(regulator_unregister+0xc8/0xd0)
 [] (regulator_unregister) from [] 
(release_nodes+0x16c/0x1dc)
 [] (release_nodes) from [] 
(__device_release_driver+0x8c/0x110)
 [] (__device_release_driver) from [] 
(device_release_driver+0x1c/0x28)
 [] (device_release_driver) from [] 
(bus_remove_device+0xd8/0x104)
 [] (bus_remove_device) from [] (device_del+0x10c/0x218)
 [] (device_del) from [] (platform_device_del+0x1c/0x88)
 [] (platform_device_del) from [] 
(platform_device_unregister+0xc/0x20)
 [] (platform_device_unregister) 

Re: [PATCH] cpufreq: dt: add Socionext UniPhier SoCs support

[Viresh Kumar]

On 27-10-16, 01:41, Masahiro Yamada wrote:
> Add compatible strings for Pro5, PXs2, LD6b, LD11, LD20 SoCs to use
> the generic cpufreq driver.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/cpufreq/cpufreq-dt-platdev.c | 6 ++
>  1 file changed, 6 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: dt: add Socionext UniPhier SoCs support

[Viresh Kumar]

On 27-10-16, 01:41, Masahiro Yamada wrote:
> Add compatible strings for Pro5, PXs2, LD6b, LD11, LD20 SoCs to use
> the generic cpufreq driver.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/cpufreq/cpufreq-dt-platdev.c | 6 ++
>  1 file changed, 6 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/2] ARM: dts: uniphier: add CPU clocks and OPP table for Pro5 SoC

[Viresh Kumar]

On 27-10-16, 01:37, Masahiro Yamada wrote:
> Add a CPU clock to every CPU node and a CPU OPP table to use the
> generic cpufreq driver.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/arm/boot/dts/uniphier-pro5.dtsi | 74 
> 
>  1 file changed, 74 insertions(+)

For both patches.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/2] ARM: dts: uniphier: add CPU clocks and OPP table for Pro5 SoC

[Viresh Kumar]

On 27-10-16, 01:37, Masahiro Yamada wrote:
> Add a CPU clock to every CPU node and a CPU OPP table to use the
> generic cpufreq driver.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/arm/boot/dts/uniphier-pro5.dtsi | 74 
> 
>  1 file changed, 74 insertions(+)

For both patches.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver

[David Lechner]

On 10/26/2016 10:03 AM, Alexandre Bailon wrote:

From: Petr Kulhavy 

This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver

Signed-off-by: Petr Kulhavy 
Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 210b7e4..bfa571d 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
  * Based on the DaVinci "glue layer" code.
  * Copyright (C) 2005-2006 by Texas Instruments
  *
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy 
+ *
  * This file is part of the Inventra Controller Driver for Linux.
  *
  * The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
 }

+static inline u8 get_vbus_power(struct device *dev)
+{
+   struct regulator *vbus_supply;
+   int current_uA;
+
+   vbus_supply = regulator_get_optional(dev, "vbus");
+   if (IS_ERR(vbus_supply))
+   return 255;
+   current_uA = regulator_get_current_limit(vbus_supply);
+   regulator_put(vbus_supply);
+   if (current_uA <= 0 || current_uA > 51)
+   return 255;
+   return current_uA / 1000 / 2;
+}
+
 static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init   = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask   = DMA_BIT_MASK(32),
 };

+static const struct musb_hdrc_config da8xx_config = {
+   .ram_bits = 10,
+   .num_eps = 5,
+   .multipoint = 1,
+};
+
 static int da8xx_probe(struct platform_device *pdev)
 {
struct resource musb_resources[2];
@@ -465,7 +489,9 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
struct clk  *clk;
+   struct device_node  *np = pdev->dev.of_node;
int ret;
+   struct resource *res;


res is not used anywhere



glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -486,6 +512,18 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev= >dev;
glue->clk= clk;

+   if (IS_ENABLED(CONFIG_OF) && np) {
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   /* FIXME */


Why FIXME? I don't see anything that needs to be fixed here.


+   return -ENOMEM;
+   }
+
+   pdata->config= _config;
+   pdata->mode  = musb_get_mode(>dev);
+   pdata->power = get_vbus_power(>dev);
+   }
+
pdata->platform_ops  = _ops;

glue->usb_phy = usb_phy_generic_register();
@@ -536,11 +574,20 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
 }



Shouldn't you have #ifdef CONFIG_OF here since you are using 
of_match_ptr() below?



+static const struct of_device_id da8xx_id_table[] = {
+   {
+   .compatible = "ti,da830-musb",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);


#endif


+
 static struct platform_driver da8xx_driver = {
.probe  = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name   = "musb-da8xx",
+   .of_match_table = of_match_ptr(da8xx_id_table),
},
 };




Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and 
no vbus-supply.


Tested-By: David Lechner 

Re: [PATCH v2 2/4] usb: musb: core: added helper function for parsing DT

[David Lechner]

On 10/26/2016 10:03 AM, Alexandre Bailon wrote:

From: Petr Kulhavy 

This adds the function musb_get_mode() to get the DT property "dr_mode"

Signed-off-by: Petr Kulhavy 
Acked-by: Sergei Shtylyov 
Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/musb_core.c | 19 +++
 drivers/usb/musb/musb_core.h |  5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..bba07e7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "musb_core.h"
 #include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
 }

+enum musb_mode musb_get_mode(struct device *dev)
+{
+   enum usb_dr_mode mode;
+
+   mode = usb_get_dr_mode(dev);
+   switch (mode) {
+   case USB_DR_MODE_HOST:
+   return MUSB_HOST;
+   case USB_DR_MODE_PERIPHERAL:
+   return MUSB_PERIPHERAL;
+   case USB_DR_MODE_OTG:
+   case USB_DR_MODE_UNKNOWN:
+   default:
+   return MUSB_OTG;
+   }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
 /*-*/

 #ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..a406468 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,9 @@ static inline void musb_platform_post_root_reset_end(struct 
musb *musb)
musb->ops->post_root_reset_end(musb);
 }

+/* gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
 #endif /* __MUSB_CORE_H__ */



Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and 
no vbus-supply.


Tested-By: David Lechner 

Re: [PATCH v2 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver

[David Lechner]

On 10/26/2016 10:03 AM, Alexandre Bailon wrote:

From: Petr Kulhavy 

This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver

Signed-off-by: Petr Kulhavy 
Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 210b7e4..bfa571d 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
  * Based on the DaVinci "glue layer" code.
  * Copyright (C) 2005-2006 by Texas Instruments
  *
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy 
+ *
  * This file is part of the Inventra Controller Driver for Linux.
  *
  * The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
 }

+static inline u8 get_vbus_power(struct device *dev)
+{
+   struct regulator *vbus_supply;
+   int current_uA;
+
+   vbus_supply = regulator_get_optional(dev, "vbus");
+   if (IS_ERR(vbus_supply))
+   return 255;
+   current_uA = regulator_get_current_limit(vbus_supply);
+   regulator_put(vbus_supply);
+   if (current_uA <= 0 || current_uA > 51)
+   return 255;
+   return current_uA / 1000 / 2;
+}
+
 static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init   = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask   = DMA_BIT_MASK(32),
 };

+static const struct musb_hdrc_config da8xx_config = {
+   .ram_bits = 10,
+   .num_eps = 5,
+   .multipoint = 1,
+};
+
 static int da8xx_probe(struct platform_device *pdev)
 {
struct resource musb_resources[2];
@@ -465,7 +489,9 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
struct clk  *clk;
+   struct device_node  *np = pdev->dev.of_node;
int ret;
+   struct resource *res;


res is not used anywhere



glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -486,6 +512,18 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev= >dev;
glue->clk= clk;

+   if (IS_ENABLED(CONFIG_OF) && np) {
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   /* FIXME */


Why FIXME? I don't see anything that needs to be fixed here.


+   return -ENOMEM;
+   }
+
+   pdata->config= _config;
+   pdata->mode  = musb_get_mode(>dev);
+   pdata->power = get_vbus_power(>dev);
+   }
+
pdata->platform_ops  = _ops;

glue->usb_phy = usb_phy_generic_register();
@@ -536,11 +574,20 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
 }



Shouldn't you have #ifdef CONFIG_OF here since you are using 
of_match_ptr() below?



+static const struct of_device_id da8xx_id_table[] = {
+   {
+   .compatible = "ti,da830-musb",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);


#endif


+
 static struct platform_driver da8xx_driver = {
.probe  = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name   = "musb-da8xx",
+   .of_match_table = of_match_ptr(da8xx_id_table),
},
 };




Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and 
no vbus-supply.


Tested-By: David Lechner 

Re: [PATCH v2 2/4] usb: musb: core: added helper function for parsing DT

[David Lechner]

On 10/26/2016 10:03 AM, Alexandre Bailon wrote:

From: Petr Kulhavy 

This adds the function musb_get_mode() to get the DT property "dr_mode"

Signed-off-by: Petr Kulhavy 
Acked-by: Sergei Shtylyov 
Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/musb_core.c | 19 +++
 drivers/usb/musb/musb_core.h |  5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..bba07e7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "musb_core.h"
 #include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
 }

+enum musb_mode musb_get_mode(struct device *dev)
+{
+   enum usb_dr_mode mode;
+
+   mode = usb_get_dr_mode(dev);
+   switch (mode) {
+   case USB_DR_MODE_HOST:
+   return MUSB_HOST;
+   case USB_DR_MODE_PERIPHERAL:
+   return MUSB_PERIPHERAL;
+   case USB_DR_MODE_OTG:
+   case USB_DR_MODE_UNKNOWN:
+   default:
+   return MUSB_OTG;
+   }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
 /*-*/

 #ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..a406468 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,9 @@ static inline void musb_platform_post_root_reset_end(struct 
musb *musb)
musb->ops->post_root_reset_end(musb);
 }

+/* gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
 #endif /* __MUSB_CORE_H__ */



Tested working on LEGO MINDSTORMS EV3 using dr_mode = "peripheral" and 
no vbus-supply.


Tested-By: David Lechner 

linux-next: Tree for Oct 27

[Stephen Rothwell]

Hi all,

There will probably be no linux-next releases next week while I attend
the Kernel Summit.

Changes since 20161026:

The akpm-current tree still had its build failures for which I applied
2 patches.

Non-merge commits (relative to Linus' tree): 2802
 3583 files changed, 220238 insertions(+), 57431 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 (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 245 trees (counting Linus' and 35 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 Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (9fe68cad6e74 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (989cea5c14be kbuild: prevent lib-ksyms.o 
rebuilds)
Merging arc-current/for-curr (e2192b253de8 ARC: module: print pretty section 
names)
Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (09b7e37b18ee powerpc/64: Fix race condition in 
setting lock bit in idle/wakeup code)
Merging sparc/master (a236441bb697 sparc64: Fix illegal relative branches in 
hypervisor patched TLB cross-call code.)
Merging net/master (ecc515d7238f sctp: fix the panic caused by route update)
CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig
Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (7034b566a4e7 netfilter: fix nf_queue handling)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for 
the Venue 8 Pro)
Merging mac80211/master (b4f7f4ad425a mac80211: fix some sphinx warnings)
Merging sound-current/for-linus (9b50898ad96c ALSA: seq: Fix time account 
regression)
Merging pci-current/for-linus (02a1b8f4167e PCI: designware-plat: Update author 
email address)
Merging driver-core.current/driver-core-linus (07d9a380680d Linux 4.9-rc2)
Merging tty.current/tty-linus (1001354ca341 Linux 4.9-rc1)
Merging usb.current/usb-linus (c1aa67729a1d Merge tag 'usb-ci-v4.9-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus)
Merging usb-gadget-fixes/fixes (a1aa8cf6471b Revert "Documentation: devicetree: 
dwc2: Deprecate g-tx-fifo-size")
Merging usb-serial-fixes/usb-linus (07d9a380680d Linux 4.9-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (991d5add50a5 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging phy/fixes (1001354ca341 Linux 4.9-rc1)
Merging staging.current/staging-linus (e866dd8aab76 greybus: fix a leak on 
error in gb_module_create())
Merging char-misc.current/char-misc-linus (cfcc1456e4a2 Merge tag 
'extcon-fixes-for-4.9-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup 
Focaltech code)
Merging crypto-current/master (6d4952d9d9d4 hwrng: core - Don't use a stack 
buffer in add_early_randomness())
Merging ide/master (797cee9

linux-next: Tree for Oct 27

[Stephen Rothwell]

Hi all,

There will probably be no linux-next releases next week while I attend
the Kernel Summit.

Changes since 20161026:

The akpm-current tree still had its build failures for which I applied
2 patches.

Non-merge commits (relative to Linus' tree): 2802
 3583 files changed, 220238 insertions(+), 57431 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 (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 245 trees (counting Linus' and 35 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 Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (9fe68cad6e74 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (989cea5c14be kbuild: prevent lib-ksyms.o 
rebuilds)
Merging arc-current/for-curr (e2192b253de8 ARC: module: print pretty section 
names)
Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (09b7e37b18ee powerpc/64: Fix race condition in 
setting lock bit in idle/wakeup code)
Merging sparc/master (a236441bb697 sparc64: Fix illegal relative branches in 
hypervisor patched TLB cross-call code.)
Merging net/master (ecc515d7238f sctp: fix the panic caused by route update)
CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig
Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (7034b566a4e7 netfilter: fix nf_queue handling)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for 
the Venue 8 Pro)
Merging mac80211/master (b4f7f4ad425a mac80211: fix some sphinx warnings)
Merging sound-current/for-linus (9b50898ad96c ALSA: seq: Fix time account 
regression)
Merging pci-current/for-linus (02a1b8f4167e PCI: designware-plat: Update author 
email address)
Merging driver-core.current/driver-core-linus (07d9a380680d Linux 4.9-rc2)
Merging tty.current/tty-linus (1001354ca341 Linux 4.9-rc1)
Merging usb.current/usb-linus (c1aa67729a1d Merge tag 'usb-ci-v4.9-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus)
Merging usb-gadget-fixes/fixes (a1aa8cf6471b Revert "Documentation: devicetree: 
dwc2: Deprecate g-tx-fifo-size")
Merging usb-serial-fixes/usb-linus (07d9a380680d Linux 4.9-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (991d5add50a5 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging phy/fixes (1001354ca341 Linux 4.9-rc1)
Merging staging.current/staging-linus (e866dd8aab76 greybus: fix a leak on 
error in gb_module_create())
Merging char-misc.current/char-misc-linus (cfcc1456e4a2 Merge tag 
'extcon-fixes-for-4.9-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup 
Focaltech code)
Merging crypto-current/master (6d4952d9d9d4 hwrng: core - Don't use a stack 
buffer in add_early_randomness())
Merging ide/master (797cee9

Re: [PATCH v5] x86/msr: Add write msr notrace to avoid the debug codes splash

[Wanpeng Li]

2016-10-26 19:50 GMT+08:00 Borislav Petkov :
> On Wed, Oct 26, 2016 at 07:35:26PM +0800, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> As Peterz pointed out:
>>
>> | The thing is, many many smp_reschedule_interrupt() invocations don't
>> | actually execute anything much at all and are only send to tickle the
>> | return to user path (which does the actual preemption).
>>
>> This patch add write msr notrace to avoid the debug codes splash.
>>
>> Suggested-by: Peter Zijlstra 
>> Suggested-by: Paolo Bonzini 
>> Cc: Ingo Molnar 
>> Cc: Mike Galbraith 
>> Cc: Peter Zijlstra 
>> Cc: Thomas Gleixner 
>> Cc: Paolo Bonzini 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/include/asm/apic.h |  3 ++-
>>  arch/x86/include/asm/msr.h  | 15 +++
>>  arch/x86/kernel/apic/apic.c |  1 +
>>  arch/x86/kernel/kvm.c   |  4 ++--
>>  arch/x86/kernel/smp.c   |  2 --
>>  5 files changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
>> index f5aaf6c..a5a0bcf 100644
>> --- a/arch/x86/include/asm/apic.h
>> +++ b/arch/x86/include/asm/apic.h
>> @@ -196,7 +196,7 @@ static inline void native_apic_msr_write(u32 reg, u32 v)
>>
>>  static inline void native_apic_msr_eoi_write(u32 reg, u32 v)
>>  {
>> - wrmsr(APIC_BASE_MSR + (APIC_EOI >> 4), APIC_EOI_ACK, 0);
>> + wrmsr_notrace(APIC_BASE_MSR + (APIC_EOI >> 4), APIC_EOI_ACK, 0);
>>  }
>>
>>  static inline u32 native_apic_msr_read(u32 reg)
>> @@ -332,6 +332,7 @@ struct apic {
>>* on write for EOI.
>>*/
>>   void (*eoi_write)(u32 reg, u32 v);
>> + void (*native_eoi_write)(u32 reg, u32 v);
>>   u64 (*icr_read)(void);
>>   void (*icr_write)(u32 low, u32 high);
>>   void (*wait_icr_idle)(void);
>> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
>> index b5fee97..afbb221 100644
>> --- a/arch/x86/include/asm/msr.h
>> +++ b/arch/x86/include/asm/msr.h
>> @@ -127,6 +127,21 @@ notrace static inline void native_write_msr(unsigned 
>> int msr,
>>  }
>>
>>  /* Can be uninlined because referenced by paravirt */
>> +notrace static inline void native_write_msr_notrace(unsigned int msr,
>> + unsigned low, unsigned high)
>> +{
>> + asm volatile("1: wrmsr\n"
>> +  "2:\n"
>> +  _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
>> +  : : "c" (msr), "a"(low), "d" (high) : "memory");
>> +}
>
> Why is this duplicating the inline asm?
>
> This function should be called __native_write_msr_notrace() instead and
> then native_write_msr() should do:
>
> notrace static inline void native_write_msr(unsigned int msr,
> unsigned low, unsigned 
> high)
> {
> __native_write_msr_notrace(msr, low, high);
> if (msr_tracepoint_active(__tracepoint_write_msr))
> do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
> }
>
> This way it is way more clear who calls what.
>
> And this thing should be two patches anyway:
>
> 1. change native_write_msr()
> 2. Add the apic changes.

Thanks for pointing out.

Regards,
Wanpeng Li

Re: [PATCH v5] x86/msr: Add write msr notrace to avoid the debug codes splash

[Wanpeng Li]

2016-10-26 19:50 GMT+08:00 Borislav Petkov :
> On Wed, Oct 26, 2016 at 07:35:26PM +0800, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> As Peterz pointed out:
>>
>> | The thing is, many many smp_reschedule_interrupt() invocations don't
>> | actually execute anything much at all and are only send to tickle the
>> | return to user path (which does the actual preemption).
>>
>> This patch add write msr notrace to avoid the debug codes splash.
>>
>> Suggested-by: Peter Zijlstra 
>> Suggested-by: Paolo Bonzini 
>> Cc: Ingo Molnar 
>> Cc: Mike Galbraith 
>> Cc: Peter Zijlstra 
>> Cc: Thomas Gleixner 
>> Cc: Paolo Bonzini 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/include/asm/apic.h |  3 ++-
>>  arch/x86/include/asm/msr.h  | 15 +++
>>  arch/x86/kernel/apic/apic.c |  1 +
>>  arch/x86/kernel/kvm.c   |  4 ++--
>>  arch/x86/kernel/smp.c   |  2 --
>>  5 files changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
>> index f5aaf6c..a5a0bcf 100644
>> --- a/arch/x86/include/asm/apic.h
>> +++ b/arch/x86/include/asm/apic.h
>> @@ -196,7 +196,7 @@ static inline void native_apic_msr_write(u32 reg, u32 v)
>>
>>  static inline void native_apic_msr_eoi_write(u32 reg, u32 v)
>>  {
>> - wrmsr(APIC_BASE_MSR + (APIC_EOI >> 4), APIC_EOI_ACK, 0);
>> + wrmsr_notrace(APIC_BASE_MSR + (APIC_EOI >> 4), APIC_EOI_ACK, 0);
>>  }
>>
>>  static inline u32 native_apic_msr_read(u32 reg)
>> @@ -332,6 +332,7 @@ struct apic {
>>* on write for EOI.
>>*/
>>   void (*eoi_write)(u32 reg, u32 v);
>> + void (*native_eoi_write)(u32 reg, u32 v);
>>   u64 (*icr_read)(void);
>>   void (*icr_write)(u32 low, u32 high);
>>   void (*wait_icr_idle)(void);
>> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
>> index b5fee97..afbb221 100644
>> --- a/arch/x86/include/asm/msr.h
>> +++ b/arch/x86/include/asm/msr.h
>> @@ -127,6 +127,21 @@ notrace static inline void native_write_msr(unsigned 
>> int msr,
>>  }
>>
>>  /* Can be uninlined because referenced by paravirt */
>> +notrace static inline void native_write_msr_notrace(unsigned int msr,
>> + unsigned low, unsigned high)
>> +{
>> + asm volatile("1: wrmsr\n"
>> +  "2:\n"
>> +  _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
>> +  : : "c" (msr), "a"(low), "d" (high) : "memory");
>> +}
>
> Why is this duplicating the inline asm?
>
> This function should be called __native_write_msr_notrace() instead and
> then native_write_msr() should do:
>
> notrace static inline void native_write_msr(unsigned int msr,
> unsigned low, unsigned 
> high)
> {
> __native_write_msr_notrace(msr, low, high);
> if (msr_tracepoint_active(__tracepoint_write_msr))
> do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
> }
>
> This way it is way more clear who calls what.
>
> And this thing should be two patches anyway:
>
> 1. change native_write_msr()
> 2. Add the apic changes.

Thanks for pointing out.

Regards,
Wanpeng Li

Re: [PATCH v3 1/1] kthread: allocate kthread structure using kmalloc

[Josh Poimboeuf]

On Wed, Oct 26, 2016 at 04:14:00PM +0200, Oleg Nesterov wrote:
> +/*
> + * TODO: kill it and use to_kthread(). But we still need the users
> + * like kthread_stop() which has to sync with the exiting kthread.
> + */
>  static struct kthread *to_live_kthread(struct task_struct *k)

Now that the kthread struct is no longer on the stack, are the
try_get_task_stack() and its corresponding put_task_stack()'s still
needed?

-- 
Josh

Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106

[Peter Hutterer]

On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote:
> struct timeval is not y2038 safe.
> All usage of timeval in the kernel will be replaced by
> y2038 safe structures.
> 
> struct input_event maintains time for each input event.
> Real time timestamps are not ideal for input as this
> time can go backwards as noted in the patch a80b83b7b8
> by John Stultz. Hence, having the input_event.time fields
> only big enough for monotonic and boot times are
> sufficient.
> 
> Leave the original input_event as is. This is to maintain
> backward compatibility with existing userspace interfaces
> that use input_event.
> Introduce a new replacement struct raw_input_event.

general comment here - please don't name it "raw_input_event".
First, when you grep for input_event you want the new ones to show up too,
so a struct input_event_raw would be better here. That also has better
namespacing in general. Second though: the event isn't any more "raw" than
the previous we had.

I can't think of anything better than struct input_event_v2 though.

> This replaces timeval with struct input_timeval. This structure
> maintains time in __kernel_ulong_t or compat_ulong_t to allow
> for architectures to override types as in the case of x32.
> 
> The change requires any userspace utilities reading or writing
> from event nodes to update their reading format to match
> raw_input_event. The changes to the popular libraries will be
> posted along with the kernel changes.
> The driver version is also updated to reflect the change in
> event format.

Doesn't this break *all* of userspace then? I don't see anything to
negotiate the type of input event the kernel gives me. And nothing right now
checks for EVDEV_VERSION, so they all just assume it's a struct
input_event. Best case, if the available events aren't a multiple of
sizeof(struct input_event) userspace will bomb out, but unless that happens,
everyone will just happily read old-style events.

So we need some negotiation what is acceptable. Which also needs to address
the race conditions we're going to get when events start coming in before
the client has announced that it supports the new-style events.

Cheers,
   Peter

> Suggested-by: Arnd Bergmann 
> Signed-off-by: Deepa Dinamani 
> Reviewed-by: Arnd Bergmann 
> ---
>  drivers/input/evdev.c| 20 +--
>  drivers/input/input-compat.c | 29 ++-
>  drivers/input/input-compat.h | 19 +++---
>  drivers/input/misc/uinput.c  |  6 +++---
>  include/linux/uinput.h   |  2 +-
>  include/uapi/linux/input.h   | 47 
> 
>  6 files changed, 88 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index b4e3171..459e3ba 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -60,7 +60,7 @@ struct evdev_client {
>   bool revoked;
>   unsigned long *evmasks[EV_CNT];
>   unsigned int bufsize;
> - struct input_event buffer[];
> + struct raw_input_event buffer[];
>  };
>  
>  static size_t evdev_get_mask_cnt(unsigned int type)
> @@ -113,7 +113,7 @@ static void __evdev_flush_queue(struct evdev_client 
> *client, unsigned int type)
>   unsigned int i, head, num;
>   unsigned int mask = client->bufsize - 1;
>   bool is_report;
> - struct input_event *ev;
> + struct raw_input_event *ev;
>  
>   BUG_ON(type == EV_SYN);
>  
> @@ -155,7 +155,7 @@ static void __evdev_flush_queue(struct evdev_client 
> *client, unsigned int type)
>  
>  static void __evdev_queue_syn_dropped(struct evdev_client *client)
>  {
> - struct input_event ev;
> + struct raw_input_event ev;
>   struct timespec64 ts;
>  
>   switch (client->clk_type) {
> @@ -236,7 +236,7 @@ static int evdev_set_clk_type(struct evdev_client 
> *client, unsigned int clkid)
>  }
>  
>  static void __pass_event(struct evdev_client *client,
> -  const struct input_event *event)
> +  const struct raw_input_event *event)
>  {
>   client->buffer[client->head++] = *event;
>   client->head &= client->bufsize - 1;
> @@ -268,7 +268,7 @@ static void evdev_pass_values(struct evdev_client *client,
>  {
>   struct evdev *evdev = client->evdev;
>   const struct input_value *v;
> - struct input_event event;
> + struct raw_input_event event;
>   struct timespec64 ts;
>   bool wakeup = false;
>  
> @@ -507,7 +507,7 @@ static int evdev_open(struct inode *inode, struct file 
> *file)
>   struct evdev *evdev = container_of(inode->i_cdev, struct evdev, cdev);
>   unsigned int bufsize = evdev_compute_buffer_size(evdev->handle.dev);
>   unsigned int size = sizeof(struct evdev_client) +
> - bufsize * sizeof(struct input_event);
> + bufsize * sizeof(struct raw_input_event);
>   struct evdev_client 

Re: [PATCH v3 1/1] kthread: allocate kthread structure using kmalloc

[Josh Poimboeuf]

On Wed, Oct 26, 2016 at 04:14:00PM +0200, Oleg Nesterov wrote:
> +/*
> + * TODO: kill it and use to_kthread(). But we still need the users
> + * like kthread_stop() which has to sync with the exiting kthread.
> + */
>  static struct kthread *to_live_kthread(struct task_struct *k)

Now that the kthread struct is no longer on the stack, are the
try_get_task_stack() and its corresponding put_task_stack()'s still
needed?

-- 
Josh

Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106

[Peter Hutterer]

On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote:
> struct timeval is not y2038 safe.
> All usage of timeval in the kernel will be replaced by
> y2038 safe structures.
> 
> struct input_event maintains time for each input event.
> Real time timestamps are not ideal for input as this
> time can go backwards as noted in the patch a80b83b7b8
> by John Stultz. Hence, having the input_event.time fields
> only big enough for monotonic and boot times are
> sufficient.
> 
> Leave the original input_event as is. This is to maintain
> backward compatibility with existing userspace interfaces
> that use input_event.
> Introduce a new replacement struct raw_input_event.

general comment here - please don't name it "raw_input_event".
First, when you grep for input_event you want the new ones to show up too,
so a struct input_event_raw would be better here. That also has better
namespacing in general. Second though: the event isn't any more "raw" than
the previous we had.

I can't think of anything better than struct input_event_v2 though.

> This replaces timeval with struct input_timeval. This structure
> maintains time in __kernel_ulong_t or compat_ulong_t to allow
> for architectures to override types as in the case of x32.
> 
> The change requires any userspace utilities reading or writing
> from event nodes to update their reading format to match
> raw_input_event. The changes to the popular libraries will be
> posted along with the kernel changes.
> The driver version is also updated to reflect the change in
> event format.

Doesn't this break *all* of userspace then? I don't see anything to
negotiate the type of input event the kernel gives me. And nothing right now
checks for EVDEV_VERSION, so they all just assume it's a struct
input_event. Best case, if the available events aren't a multiple of
sizeof(struct input_event) userspace will bomb out, but unless that happens,
everyone will just happily read old-style events.

So we need some negotiation what is acceptable. Which also needs to address
the race conditions we're going to get when events start coming in before
the client has announced that it supports the new-style events.

Cheers,
   Peter

> Suggested-by: Arnd Bergmann 
> Signed-off-by: Deepa Dinamani 
> Reviewed-by: Arnd Bergmann 
> ---
>  drivers/input/evdev.c| 20 +--
>  drivers/input/input-compat.c | 29 ++-
>  drivers/input/input-compat.h | 19 +++---
>  drivers/input/misc/uinput.c  |  6 +++---
>  include/linux/uinput.h   |  2 +-
>  include/uapi/linux/input.h   | 47 
> 
>  6 files changed, 88 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index b4e3171..459e3ba 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -60,7 +60,7 @@ struct evdev_client {
>   bool revoked;
>   unsigned long *evmasks[EV_CNT];
>   unsigned int bufsize;
> - struct input_event buffer[];
> + struct raw_input_event buffer[];
>  };
>  
>  static size_t evdev_get_mask_cnt(unsigned int type)
> @@ -113,7 +113,7 @@ static void __evdev_flush_queue(struct evdev_client 
> *client, unsigned int type)
>   unsigned int i, head, num;
>   unsigned int mask = client->bufsize - 1;
>   bool is_report;
> - struct input_event *ev;
> + struct raw_input_event *ev;
>  
>   BUG_ON(type == EV_SYN);
>  
> @@ -155,7 +155,7 @@ static void __evdev_flush_queue(struct evdev_client 
> *client, unsigned int type)
>  
>  static void __evdev_queue_syn_dropped(struct evdev_client *client)
>  {
> - struct input_event ev;
> + struct raw_input_event ev;
>   struct timespec64 ts;
>  
>   switch (client->clk_type) {
> @@ -236,7 +236,7 @@ static int evdev_set_clk_type(struct evdev_client 
> *client, unsigned int clkid)
>  }
>  
>  static void __pass_event(struct evdev_client *client,
> -  const struct input_event *event)
> +  const struct raw_input_event *event)
>  {
>   client->buffer[client->head++] = *event;
>   client->head &= client->bufsize - 1;
> @@ -268,7 +268,7 @@ static void evdev_pass_values(struct evdev_client *client,
>  {
>   struct evdev *evdev = client->evdev;
>   const struct input_value *v;
> - struct input_event event;
> + struct raw_input_event event;
>   struct timespec64 ts;
>   bool wakeup = false;
>  
> @@ -507,7 +507,7 @@ static int evdev_open(struct inode *inode, struct file 
> *file)
>   struct evdev *evdev = container_of(inode->i_cdev, struct evdev, cdev);
>   unsigned int bufsize = evdev_compute_buffer_size(evdev->handle.dev);
>   unsigned int size = sizeof(struct evdev_client) +
> - bufsize * sizeof(struct input_event);
> + bufsize * sizeof(struct raw_input_event);
>   struct evdev_client *client;
>   int error;
>  
> @@ -542,7 +542,7 @@ 

Re: [PATCH 6/8] autofs - use path_is_mountpoint() to fix unreliable d_mountpoint() checks

[Ian Kent]

On Thu, 2016-10-27 at 03:17 +0100, Al Viro wrote:
> On Tue, Oct 11, 2016 at 01:34:18PM +0800, Ian Kent wrote:
> > 
> > +   path = file->f_path;
> > +
> >     /*
> >      * An empty directory in an autofs file system is always a
> >      * mount point. The daemon must have failed to mount this
> > @@ -123,7 +126,7 @@ static int autofs4_dir_open(struct inode *inode, struct
> > file *file)
> >      * it.
> >      */
> >     spin_lock(>lookup_lock);
> > -   if (!d_mountpoint(dentry) && simple_empty(dentry)) {
> > +   if (!path_is_mountpoint() && simple_empty(dentry)) {
> Why not >f_path, provided that you constify that thing properly?

Yep, my bad, as pointed out by Eric.

Patches to fix that and constify a bunch of things will follow.

> 
> > 
> > +   if (rcu_walk) {
> > +   if (!path_is_mountpoint_rcu(path))
> > +   return -EISDIR;
> > +   } else {
> > +   if (!path_is_mountpoint(path))
> > +   return -EISDIR;
> IDGI.  What's the point of _having_ the _rcu() variant, anyway?  Here you
> are probably paying more in terms of i-cache footprint/branch prediction
> than you win on not doing that rcu_read_lock()/rcu_read_unlock()...
> 
> _rcu variants make sense when non-RCU case does something you can't do
> under RCU; here your path_is_mountpoint() is pretty close to being
> rcu_read_lock()+path_is_mountpoint_rcu()+rcu_read_unlock() anyway...

Again, my bad, I'll merge these two and post along with the follow up patches
above.

Thanks Al,
Ian

Re: [PATCH 6/8] autofs - use path_is_mountpoint() to fix unreliable d_mountpoint() checks

[Ian Kent]

On Thu, 2016-10-27 at 03:17 +0100, Al Viro wrote:
> On Tue, Oct 11, 2016 at 01:34:18PM +0800, Ian Kent wrote:
> > 
> > +   path = file->f_path;
> > +
> >     /*
> >      * An empty directory in an autofs file system is always a
> >      * mount point. The daemon must have failed to mount this
> > @@ -123,7 +126,7 @@ static int autofs4_dir_open(struct inode *inode, struct
> > file *file)
> >      * it.
> >      */
> >     spin_lock(>lookup_lock);
> > -   if (!d_mountpoint(dentry) && simple_empty(dentry)) {
> > +   if (!path_is_mountpoint() && simple_empty(dentry)) {
> Why not >f_path, provided that you constify that thing properly?

Yep, my bad, as pointed out by Eric.

Patches to fix that and constify a bunch of things will follow.

> 
> > 
> > +   if (rcu_walk) {
> > +   if (!path_is_mountpoint_rcu(path))
> > +   return -EISDIR;
> > +   } else {
> > +   if (!path_is_mountpoint(path))
> > +   return -EISDIR;
> IDGI.  What's the point of _having_ the _rcu() variant, anyway?  Here you
> are probably paying more in terms of i-cache footprint/branch prediction
> than you win on not doing that rcu_read_lock()/rcu_read_unlock()...
> 
> _rcu variants make sense when non-RCU case does something you can't do
> under RCU; here your path_is_mountpoint() is pretty close to being
> rcu_read_lock()+path_is_mountpoint_rcu()+rcu_read_unlock() anyway...

Again, my bad, I'll merge these two and post along with the follow up patches
above.

Thanks Al,
Ian

Re: [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers

[Wanpeng Li]

2016-10-26 22:01 GMT+08:00 Radim Krčmář :
> 2016-10-26 14:08+0800, Wanpeng Li:
>> 2016-10-26 14:02 GMT+08:00 Wanpeng Li :
>>> 2016-10-25 19:43 GMT+08:00 Radim Krčmář :
 I will have some comments, because it would be nicer if it measured the
 latency ... expected_expiration is not computed correctly.
>>>
>>> It measured the latency from guest programs the clock event device to
>>> interrupt injected to guest after timer fire.
>
> No.  It never computed the time when the timer fires, the test measured
> the duration of the period.
>
> Imagine that the dashed line below is a timeline.  Pipe is idealized
> firing of the periodic timer and caret is the time when the guest read
> time in the interrupt.  The number below caret is the latency.
>
> The period is 7.
>
>  
>  |  |  |  |  |  |  |
>   ^   ^   ^^   ^ ^  ^
>   1   2   31   2 1  1
>
> The test would report "latencies" as:
>
>   1   1   1   -2   1-1  0
>
> because it used now() + period to compute the next expected expiration
>
> Similarly in this case,
>  
>  |  |  |  |  |  |  |
>^  ^  ^  ^  ^  ^
>6  6  6  6  6  6
>
> The latency is always 6, but the test would report
>
>6  0  0  0  0  0
>
> And if we improved the latency by 1, you'd only see the difference in
> the first number. The test measured the duration of the period.

Agreed, thanks for the details. :)

Regards,
Wanpeng Li

Re: [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers

[Wanpeng Li]

2016-10-26 22:01 GMT+08:00 Radim Krčmář :
> 2016-10-26 14:08+0800, Wanpeng Li:
>> 2016-10-26 14:02 GMT+08:00 Wanpeng Li :
>>> 2016-10-25 19:43 GMT+08:00 Radim Krčmář :
 I will have some comments, because it would be nicer if it measured the
 latency ... expected_expiration is not computed correctly.
>>>
>>> It measured the latency from guest programs the clock event device to
>>> interrupt injected to guest after timer fire.
>
> No.  It never computed the time when the timer fires, the test measured
> the duration of the period.
>
> Imagine that the dashed line below is a timeline.  Pipe is idealized
> firing of the periodic timer and caret is the time when the guest read
> time in the interrupt.  The number below caret is the latency.
>
> The period is 7.
>
>  
>  |  |  |  |  |  |  |
>   ^   ^   ^^   ^ ^  ^
>   1   2   31   2 1  1
>
> The test would report "latencies" as:
>
>   1   1   1   -2   1-1  0
>
> because it used now() + period to compute the next expected expiration
>
> Similarly in this case,
>  
>  |  |  |  |  |  |  |
>^  ^  ^  ^  ^  ^
>6  6  6  6  6  6
>
> The latency is always 6, but the test would report
>
>6  0  0  0  0  0
>
> And if we improved the latency by 1, you'd only see the difference in
> the first number. The test measured the duration of the period.

Agreed, thanks for the details. :)

Regards,
Wanpeng Li

Re: [PATCH 1/8] vfs - change d_manage() to take a struct path

[Ian Kent]

On Thu, 2016-10-27 at 03:11 +0100, Al Viro wrote:
> On Fri, Oct 21, 2016 at 07:39:36AM +0800, Ian Kent wrote:
> 
> > 
> > Maybe Al has been too busy to comment, he has been on the Cc from the start.
> That's... a very mild version of what's been going on.  Let's just say that
> the last few weeks had been really interesting.  Not that the shit has
> settled, but there was some slackening in the shitstorm last few days.
> Unlikely to last, I'm afraid, but...
>  
> > 
> > Hopefully this email will prompt a review, Al?
> Aside of the Eric's note re constifying struct path (strongly seconded),
> I'm not sure if expiration-related side of that is correct.  OTOH,
> since the expiration happens from userland...

Sure, I have a follow up series to do the constifying as recommended by Eric and
now yourself.

> 
> How much testing did it get?  I've several test setups involving
> autofs, but they are nowhere near exhaustive and I don't have good
> enough feel of the codebase to slap together something with decent
> coverage...

It got my standard testing.

For that I use a modified version of the autofs Connectathon system.

It's more about testing a wide variety of syntax and map setups and so exercises
a large number of different types of autofs mounts.

It's meant to check normal operation but not so much stress testing even though
it does perform quite a few mounts (around 250-300, not to mention the autofs
mounts themselves).

I have another standard test I call the submount-test and it was originally done
to stress test the most common problem I see, concurrent expire to mount.

I didn't see any problems I couldn't explain in these but I might need to re-
visit the submount-test to see if it is still doing what I want.

OTOH, the pattern of mount and umount I see when the submount-test is run does
look like it is doing what I want but it might not be getting all the way to the
top of the tree of mounts enough times over the course of the test.

So I'm happy with my testing, just not as happy as I could be.

Ian

Re: [PATCH 1/8] vfs - change d_manage() to take a struct path

[Ian Kent]

On Thu, 2016-10-27 at 03:11 +0100, Al Viro wrote:
> On Fri, Oct 21, 2016 at 07:39:36AM +0800, Ian Kent wrote:
> 
> > 
> > Maybe Al has been too busy to comment, he has been on the Cc from the start.
> That's... a very mild version of what's been going on.  Let's just say that
> the last few weeks had been really interesting.  Not that the shit has
> settled, but there was some slackening in the shitstorm last few days.
> Unlikely to last, I'm afraid, but...
>  
> > 
> > Hopefully this email will prompt a review, Al?
> Aside of the Eric's note re constifying struct path (strongly seconded),
> I'm not sure if expiration-related side of that is correct.  OTOH,
> since the expiration happens from userland...

Sure, I have a follow up series to do the constifying as recommended by Eric and
now yourself.

> 
> How much testing did it get?  I've several test setups involving
> autofs, but they are nowhere near exhaustive and I don't have good
> enough feel of the codebase to slap together something with decent
> coverage...

It got my standard testing.

For that I use a modified version of the autofs Connectathon system.

It's more about testing a wide variety of syntax and map setups and so exercises
a large number of different types of autofs mounts.

It's meant to check normal operation but not so much stress testing even though
it does perform quite a few mounts (around 250-300, not to mention the autofs
mounts themselves).

I have another standard test I call the submount-test and it was originally done
to stress test the most common problem I see, concurrent expire to mount.

I didn't see any problems I couldn't explain in these but I might need to re-
visit the submount-test to see if it is still doing what I want.

OTOH, the pattern of mount and umount I see when the submount-test is run does
look like it is doing what I want but it might not be getting all the way to the
top of the tree of mounts enough times over the course of the test.

So I'm happy with my testing, just not as happy as I could be.

Ian

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

[Leizhen (ThunderTown)]

On 2016/10/26 17:31, Michal Hocko wrote:
> On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/10/25 21:23, Michal Hocko wrote:
>>> On Tue 25-10-16 10:59:17, Zhen Lei wrote:
 If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
 actually exist. The percpu variable areas and numa control blocks of that
 memoryless numa nodes need to be allocated from the nearest available
 node to improve performance.

 Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
 specified nid at the first time, but if that allocation failed it will
 directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
 the second time.

 To compatible the above old scene, I use a marco node_distance_ready to
 control it. By default, the marco node_distance_ready is not defined in
 any platforms, the above mentioned functions will work as normal as
 before. Otherwise, they will try the nearest node first.
>>>
>>> I am sorry but it is absolutely unclear to me _what_ is the motivation
>>> of the patch. Is this a performance optimization, correctness issue or
>>> something else? Could you please restate what is the problem, why do you
>>> think it has to be fixed at memblock layer and describe what the actual
>>> fix is please?
>>
>> This is a performance optimization.
> 
> Do you have any numbers to back the improvements?
I have not collected any performance data, but at least in theory, it's 
beneficial and harmless,
except make code looks a bit urly. Because all related functions are actually 
defined as __init,
for example:
phys_addr_t __init memblock_alloc_try_nid(
void * __init memblock_virt_alloc_try_nid(

And all related memory(percpu variables and NODE_DATA) is mostly referred at 
running time.

> 
>> The problem is if some memoryless numa nodes are
>> actually exist, for example: there are total 4 nodes, 0,1,2,3, node 1 has no 
>> memory,
>> and the node distances is as below:
>> -board---
>>  |   |
>> |   |
>>  socket0 socket1
>>/ \ / \
>>   /   \   /   \
>>node0 node1 node2 node3
>> distance[1][0] is nearer than distance[1][2] and distance[1][3]. CPUs on 
>> node1 access
>> the memory of node0 is faster than node2 or node3.
>>
>> Linux defines a lot of percpu variables, each cpu has a copy of it and most 
>> of the time
>> only to access their own percpu area. In this example, we hope the percpu 
>> area of CPUs
>> on node1 allocated from node0. But without these patches, it's not sure that.
> 
> I am not familiar with the percpu allocator much so I might be
> completely missig a point but why cannot this be solved in the percpu
> allocator directly e.g. by using cpu_to_mem which should already be
> memoryless aware.
My test result told me that it can not:
[0.00] Initmem setup node 0 [mem 0x-0x0011]
[0.00] Could not find start_pfn for node 1
[0.00] Initmem setup node 1 [mem 0x-0x]
[0.00] Initmem setup node 2 [mem 0x0012-0x0013]
[0.00] Initmem setup node 3 [mem 0x0014-0x0017]


[   14.801895] NODE_DATA(0) = 0x11e500
[   14.805749] NODE_DATA(1) = 0x11ca00  //(1), see below
[   14.809602] NODE_DATA(2) = 0x13e500
[   14.813455] NODE_DATA(3) = 0x17fffe5480
[   14.817316] cpu 0 on node0: 11fff87638
[   14.821083] cpu 1 on node0: 11fff9c638
[   14.824850] cpu 2 on node0: 11fffb1638
[   14.828616] cpu 3 on node0: 11fffc6638
[   14.832383] cpu 4 on node1: 17fff8a638   //(2), see below
[   14.836149] cpu 5 on node1: 17fff9f638
[   14.839912] cpu 6 on node1: 17fffb4638
[   14.843677] cpu 7 on node1: 17fffc9638
[   14.847444] cpu 8 on node2: 13fffa4638
[   14.851210] cpu 9 on node2: 13fffb9638
[   14.854976] cpu10 on node2: 13fffce638
[   14.858742] cpu11 on node2: 13fffe3638
[   14.862510] cpu12 on node3: 17fff36638
[   14.866276] cpu13 on node3: 17fff4b638
[   14.870042] cpu14 on node3: 17fff60638
[   14.873809] cpu15 on node3: 17fff75638

(1) memblock_alloc_try_nid and with these patches, memory was allocated from 
node0
(2) do the same implementation as X86 and PowerPC, memory was allocated from 
node3:
return  __alloc_bootmem_node(NODE_DATA(nid), size, align, 
__pa(MAX_DMA_ADDRESS));

I'm not sure how about on X86 and PowerPC, here is my test cases. Is anybody 
interested and
have testing environment, can you help me to execute it?

static int tst_numa_002(void)
{
int i;

for (i = 0; i < nr_node_ids; i++)
pr_info("NODE_DATA(%d) = 0x%llx\n", i, 
virt_to_phys(NODE_DATA(i)));

return 0;
}

static int tst_numa_003(void)
{
int cpu;
void __percpu *p;

p = 

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

[Leizhen (ThunderTown)]

On 2016/10/26 17:31, Michal Hocko wrote:
> On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/10/25 21:23, Michal Hocko wrote:
>>> On Tue 25-10-16 10:59:17, Zhen Lei wrote:
 If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
 actually exist. The percpu variable areas and numa control blocks of that
 memoryless numa nodes need to be allocated from the nearest available
 node to improve performance.

 Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
 specified nid at the first time, but if that allocation failed it will
 directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
 the second time.

 To compatible the above old scene, I use a marco node_distance_ready to
 control it. By default, the marco node_distance_ready is not defined in
 any platforms, the above mentioned functions will work as normal as
 before. Otherwise, they will try the nearest node first.
>>>
>>> I am sorry but it is absolutely unclear to me _what_ is the motivation
>>> of the patch. Is this a performance optimization, correctness issue or
>>> something else? Could you please restate what is the problem, why do you
>>> think it has to be fixed at memblock layer and describe what the actual
>>> fix is please?
>>
>> This is a performance optimization.
> 
> Do you have any numbers to back the improvements?
I have not collected any performance data, but at least in theory, it's 
beneficial and harmless,
except make code looks a bit urly. Because all related functions are actually 
defined as __init,
for example:
phys_addr_t __init memblock_alloc_try_nid(
void * __init memblock_virt_alloc_try_nid(

And all related memory(percpu variables and NODE_DATA) is mostly referred at 
running time.

> 
>> The problem is if some memoryless numa nodes are
>> actually exist, for example: there are total 4 nodes, 0,1,2,3, node 1 has no 
>> memory,
>> and the node distances is as below:
>> -board---
>>  |   |
>> |   |
>>  socket0 socket1
>>/ \ / \
>>   /   \   /   \
>>node0 node1 node2 node3
>> distance[1][0] is nearer than distance[1][2] and distance[1][3]. CPUs on 
>> node1 access
>> the memory of node0 is faster than node2 or node3.
>>
>> Linux defines a lot of percpu variables, each cpu has a copy of it and most 
>> of the time
>> only to access their own percpu area. In this example, we hope the percpu 
>> area of CPUs
>> on node1 allocated from node0. But without these patches, it's not sure that.
> 
> I am not familiar with the percpu allocator much so I might be
> completely missig a point but why cannot this be solved in the percpu
> allocator directly e.g. by using cpu_to_mem which should already be
> memoryless aware.
My test result told me that it can not:
[0.00] Initmem setup node 0 [mem 0x-0x0011]
[0.00] Could not find start_pfn for node 1
[0.00] Initmem setup node 1 [mem 0x-0x]
[0.00] Initmem setup node 2 [mem 0x0012-0x0013]
[0.00] Initmem setup node 3 [mem 0x0014-0x0017]


[   14.801895] NODE_DATA(0) = 0x11e500
[   14.805749] NODE_DATA(1) = 0x11ca00  //(1), see below
[   14.809602] NODE_DATA(2) = 0x13e500
[   14.813455] NODE_DATA(3) = 0x17fffe5480
[   14.817316] cpu 0 on node0: 11fff87638
[   14.821083] cpu 1 on node0: 11fff9c638
[   14.824850] cpu 2 on node0: 11fffb1638
[   14.828616] cpu 3 on node0: 11fffc6638
[   14.832383] cpu 4 on node1: 17fff8a638   //(2), see below
[   14.836149] cpu 5 on node1: 17fff9f638
[   14.839912] cpu 6 on node1: 17fffb4638
[   14.843677] cpu 7 on node1: 17fffc9638
[   14.847444] cpu 8 on node2: 13fffa4638
[   14.851210] cpu 9 on node2: 13fffb9638
[   14.854976] cpu10 on node2: 13fffce638
[   14.858742] cpu11 on node2: 13fffe3638
[   14.862510] cpu12 on node3: 17fff36638
[   14.866276] cpu13 on node3: 17fff4b638
[   14.870042] cpu14 on node3: 17fff60638
[   14.873809] cpu15 on node3: 17fff75638

(1) memblock_alloc_try_nid and with these patches, memory was allocated from 
node0
(2) do the same implementation as X86 and PowerPC, memory was allocated from 
node3:
return  __alloc_bootmem_node(NODE_DATA(nid), size, align, 
__pa(MAX_DMA_ADDRESS));

I'm not sure how about on X86 and PowerPC, here is my test cases. Is anybody 
interested and
have testing environment, can you help me to execute it?

static int tst_numa_002(void)
{
int i;

for (i = 0; i < nr_node_ids; i++)
pr_info("NODE_DATA(%d) = 0x%llx\n", i, 
virt_to_phys(NODE_DATA(i)));

return 0;
}

static int tst_numa_003(void)
{
int cpu;
void __percpu *p;

p = 

Re: [PATCH v2 2/5] kconfig: introduce the "suggest" keyword

[Nicolas Pitre]

On Thu, 27 Oct 2016, Paul Bolle wrote:

> On Tue, 2016-10-25 at 22:28 -0400, Nicolas Pitre wrote:
> > Similar to "imply" but with no added restrictions on the target symbol's
> > value. Useful for providing a default value to another symbol.
> > 
> > Suggested by Edward Cree.
> > 
> > Signed-off-by: Nicolas Pitre 
> 
> As far as I can see this series doesn't add a user of "suggest". So I
> see no reason to add it.
> 
> NAK.

Fine.

Given the discussion from the "imply" patch I thought "suggest" could 
become popular. But if/when someone actually wants it then this patch 
could be picked up later.


Nicolas

Re: [PATCH v2 2/5] kconfig: introduce the "suggest" keyword

[Nicolas Pitre]

On Thu, 27 Oct 2016, Paul Bolle wrote:

> On Tue, 2016-10-25 at 22:28 -0400, Nicolas Pitre wrote:
> > Similar to "imply" but with no added restrictions on the target symbol's
> > value. Useful for providing a default value to another symbol.
> > 
> > Suggested by Edward Cree.
> > 
> > Signed-off-by: Nicolas Pitre 
> 
> As far as I can see this series doesn't add a user of "suggest". So I
> see no reason to add it.
> 
> NAK.

Fine.

Given the discussion from the "imply" patch I thought "suggest" could 
become popular. But if/when someone actually wants it then this patch 
could be picked up later.


Nicolas

Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106

[Dmitry Torokhov]

Hi Deepa,

On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote:
> struct timeval is not y2038 safe.
> All usage of timeval in the kernel will be replaced by
> y2038 safe structures.
> 
> struct input_event maintains time for each input event.
> Real time timestamps are not ideal for input as this
> time can go backwards as noted in the patch a80b83b7b8
> by John Stultz. Hence, having the input_event.time fields
> only big enough for monotonic and boot times are
> sufficient.
> 
> Leave the original input_event as is. This is to maintain
> backward compatibility with existing userspace interfaces
> that use input_event.
> Introduce a new replacement struct raw_input_event.
> This replaces timeval with struct input_timeval. This structure
> maintains time in __kernel_ulong_t or compat_ulong_t to allow
> for architectures to override types as in the case of x32.
> 
> The change requires any userspace utilities reading or writing
> from event nodes to update their reading format to match
> raw_input_event. The changes to the popular libraries will be
> posted along with the kernel changes.
> The driver version is also updated to reflect the change in
> event format.

If users are forced to update to adapt to the new event format, should
we consider more radical changes? For example, does it make sense to
send timestamp on every event? Maybe we should only send it once per
event packet (between EV_SYN/SYN_REPORT)? What granularity do we need?
Is there anything else in current protocol that we'd like to change?

Thanks.

-- 
Dmitry

Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106

[Dmitry Torokhov]

Hi Deepa,

On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote:
> struct timeval is not y2038 safe.
> All usage of timeval in the kernel will be replaced by
> y2038 safe structures.
> 
> struct input_event maintains time for each input event.
> Real time timestamps are not ideal for input as this
> time can go backwards as noted in the patch a80b83b7b8
> by John Stultz. Hence, having the input_event.time fields
> only big enough for monotonic and boot times are
> sufficient.
> 
> Leave the original input_event as is. This is to maintain
> backward compatibility with existing userspace interfaces
> that use input_event.
> Introduce a new replacement struct raw_input_event.
> This replaces timeval with struct input_timeval. This structure
> maintains time in __kernel_ulong_t or compat_ulong_t to allow
> for architectures to override types as in the case of x32.
> 
> The change requires any userspace utilities reading or writing
> from event nodes to update their reading format to match
> raw_input_event. The changes to the popular libraries will be
> posted along with the kernel changes.
> The driver version is also updated to reflect the change in
> event format.

If users are forced to update to adapt to the new event format, should
we consider more radical changes? For example, does it make sense to
send timestamp on every event? Maybe we should only send it once per
event packet (between EV_SYN/SYN_REPORT)? What granularity do we need?
Is there anything else in current protocol that we'd like to change?

Thanks.

-- 
Dmitry

[PATCH v4] drm/mediatek: fixed the calc method of data rate per lane

[Jitao Shi]

  Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
mode, those signals will cause h-time larger than normal and reduce FPS.
So need to multiply a coefficient to offset the extra signal's effect.
  coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
 Ths_trail+Ths_exit)/(htotal*bpp/lane_number)

Signed-off-by: Jitao Shi 
---
Chnage since v3:
 - wrapp the commit msg.
 - fix alignment of some lines. 

Change since v2:
 - move phy timing back to dsi_phy_timconfig.

Change since v1:
 - phy_timing2 and phy_timing3 refer clock cycle time.
 - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET 
DA_HS_EXIT.
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |   71 +---
 1 file changed, 49 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..5defe58 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
 #define LD0_WAKEUP_EN  BIT(2)
 
 #define DSI_PHY_TIMECON0   0x110
-#define LPX(0xff << 0)
-#define HS_PRPR(0xff << 8)
-#define HS_ZERO(0xff << 16)
-#define HS_TRAIL   (0xff << 24)
+#define LPX(5 << 0)
+#define HS_PRPR(6 << 8)
+#define HS_ZERO(10 << 16)
+#define HS_TRAIL   (8 << 24)
 
 #define DSI_PHY_TIMECON1   0x114
-#define TA_GO  (0xff << 0)
-#define TA_SURE(0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO  (20 << 0)
+#define TA_SURE(7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)
 
 #define DSI_PHY_TIMECON2   0x118
 #define CONT_DET   (0xff << 0)
@@ -161,20 +161,17 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
u32 mask, u32 data)
 static void dsi_phy_timconfig(struct mtk_dsi *dsi)
 {
u32 timcon0, timcon1, timcon2, timcon3;
-   unsigned int ui, cycle_time;
-   unsigned int lpx;
+   u32 ui, cycle_time;
 
ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
-   lpx = 5;
 
-   timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
-   timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
+   timcon0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+   timcon1 = 4 * LPX | (3 * LPX / 2) << 8 | 5 * LPX << 16 | DA_HS_EXIT;
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
  (NS_TO_CYCLE(0x150, cycle_time) << 16);
-   timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
-  NS_TO_CYCLE(0x40, cycle_time);
+   timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
 
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -202,19 +199,49 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 {
struct device *dev = dsi->dev;
int ret;
+   u64 bit_clock, total_bits;
+   u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
 
if (++dsi->refcount != 1)
return 0;
 
+   switch (dsi->format) {
+   case MIPI_DSI_FMT_RGB565:
+   bit_per_pixel = 16;
+   break;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   bit_per_pixel = 18;
+   break;
+   case MIPI_DSI_FMT_RGB666:
+   case MIPI_DSI_FMT_RGB888:
+   default:
+   bit_per_pixel = 24;
+   break;
+   }
/**
-* data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
-* pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
-* mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
-* we set mipi_ratio is 1.05.
+* data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+* vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+* mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+*+ Thstrail + Ths_exit + Ths_zero) /
+*   (htotal * byte_per_pixel /lane_number)
 */
-   dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+   bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+   htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+dsi->vm.hsync_len;

[PATCH v4] drm/mediatek: fixed the calc method of data rate per lane

[Jitao Shi]

  Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
mode, those signals will cause h-time larger than normal and reduce FPS.
So need to multiply a coefficient to offset the extra signal's effect.
  coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
 Ths_trail+Ths_exit)/(htotal*bpp/lane_number)

Signed-off-by: Jitao Shi 
---
Chnage since v3:
 - wrapp the commit msg.
 - fix alignment of some lines. 

Change since v2:
 - move phy timing back to dsi_phy_timconfig.

Change since v1:
 - phy_timing2 and phy_timing3 refer clock cycle time.
 - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET 
DA_HS_EXIT.
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |   71 +---
 1 file changed, 49 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..5defe58 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
 #define LD0_WAKEUP_EN  BIT(2)
 
 #define DSI_PHY_TIMECON0   0x110
-#define LPX(0xff << 0)
-#define HS_PRPR(0xff << 8)
-#define HS_ZERO(0xff << 16)
-#define HS_TRAIL   (0xff << 24)
+#define LPX(5 << 0)
+#define HS_PRPR(6 << 8)
+#define HS_ZERO(10 << 16)
+#define HS_TRAIL   (8 << 24)
 
 #define DSI_PHY_TIMECON1   0x114
-#define TA_GO  (0xff << 0)
-#define TA_SURE(0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO  (20 << 0)
+#define TA_SURE(7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)
 
 #define DSI_PHY_TIMECON2   0x118
 #define CONT_DET   (0xff << 0)
@@ -161,20 +161,17 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
u32 mask, u32 data)
 static void dsi_phy_timconfig(struct mtk_dsi *dsi)
 {
u32 timcon0, timcon1, timcon2, timcon3;
-   unsigned int ui, cycle_time;
-   unsigned int lpx;
+   u32 ui, cycle_time;
 
ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
-   lpx = 5;
 
-   timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
-   timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
+   timcon0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+   timcon1 = 4 * LPX | (3 * LPX / 2) << 8 | 5 * LPX << 16 | DA_HS_EXIT;
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
  (NS_TO_CYCLE(0x150, cycle_time) << 16);
-   timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
-  NS_TO_CYCLE(0x40, cycle_time);
+   timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
 
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -202,19 +199,49 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 {
struct device *dev = dsi->dev;
int ret;
+   u64 bit_clock, total_bits;
+   u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
 
if (++dsi->refcount != 1)
return 0;
 
+   switch (dsi->format) {
+   case MIPI_DSI_FMT_RGB565:
+   bit_per_pixel = 16;
+   break;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   bit_per_pixel = 18;
+   break;
+   case MIPI_DSI_FMT_RGB666:
+   case MIPI_DSI_FMT_RGB888:
+   default:
+   bit_per_pixel = 24;
+   break;
+   }
/**
-* data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
-* pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
-* mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
-* we set mipi_ratio is 1.05.
+* data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+* vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+* mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+*+ Thstrail + Ths_exit + Ths_zero) /
+*   (htotal * byte_per_pixel /lane_number)
 */
-   dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+   bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+   htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+dsi->vm.hsync_len;
+   htotal_bits = 

Re: [PATCH 6/8] autofs - use path_is_mountpoint() to fix unreliable d_mountpoint() checks

[Al Viro]

On Tue, Oct 11, 2016 at 01:34:18PM +0800, Ian Kent wrote:
> + path = file->f_path;
> +
>   /*
>* An empty directory in an autofs file system is always a
>* mount point. The daemon must have failed to mount this
> @@ -123,7 +126,7 @@ static int autofs4_dir_open(struct inode *inode, struct 
> file *file)
>* it.
>*/
>   spin_lock(>lookup_lock);
> - if (!d_mountpoint(dentry) && simple_empty(dentry)) {
> + if (!path_is_mountpoint() && simple_empty(dentry)) {

Why not >f_path, provided that you constify that thing properly?

> + if (rcu_walk) {
> + if (!path_is_mountpoint_rcu(path))
> + return -EISDIR;
> + } else {
> + if (!path_is_mountpoint(path))
> + return -EISDIR;

IDGI.  What's the point of _having_ the _rcu() variant, anyway?  Here you
are probably paying more in terms of i-cache footprint/branch prediction
than you win on not doing that rcu_read_lock()/rcu_read_unlock()...

_rcu variants make sense when non-RCU case does something you can't do
under RCU; here your path_is_mountpoint() is pretty close to being
rcu_read_lock()+path_is_mountpoint_rcu()+rcu_read_unlock() anyway...

Re: [PATCH 6/8] autofs - use path_is_mountpoint() to fix unreliable d_mountpoint() checks

[Al Viro]

On Tue, Oct 11, 2016 at 01:34:18PM +0800, Ian Kent wrote:
> + path = file->f_path;
> +
>   /*
>* An empty directory in an autofs file system is always a
>* mount point. The daemon must have failed to mount this
> @@ -123,7 +126,7 @@ static int autofs4_dir_open(struct inode *inode, struct 
> file *file)
>* it.
>*/
>   spin_lock(>lookup_lock);
> - if (!d_mountpoint(dentry) && simple_empty(dentry)) {
> + if (!path_is_mountpoint() && simple_empty(dentry)) {

Why not >f_path, provided that you constify that thing properly?

> + if (rcu_walk) {
> + if (!path_is_mountpoint_rcu(path))
> + return -EISDIR;
> + } else {
> + if (!path_is_mountpoint(path))
> + return -EISDIR;

IDGI.  What's the point of _having_ the _rcu() variant, anyway?  Here you
are probably paying more in terms of i-cache footprint/branch prediction
than you win on not doing that rcu_read_lock()/rcu_read_unlock()...

_rcu variants make sense when non-RCU case does something you can't do
under RCU; here your path_is_mountpoint() is pretty close to being
rcu_read_lock()+path_is_mountpoint_rcu()+rcu_read_unlock() anyway...

Re: [PATCH 1/8] vfs - change d_manage() to take a struct path

[Al Viro]

On Fri, Oct 21, 2016 at 07:39:36AM +0800, Ian Kent wrote:

> Maybe Al has been too busy to comment, he has been on the Cc from the start.

That's... a very mild version of what's been going on.  Let's just say that
the last few weeks had been really interesting.  Not that the shit has
settled, but there was some slackening in the shitstorm last few days.
Unlikely to last, I'm afraid, but...
 
> Hopefully this email will prompt a review, Al?

Aside of the Eric's note re constifying struct path (strongly seconded),
I'm not sure if expiration-related side of that is correct.  OTOH,
since the expiration happens from userland...

How much testing did it get?  I've several test setups involving
autofs, but they are nowhere near exhaustive and I don't have good
enough feel of the codebase to slap together something with decent
coverage...

Re: [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers

[Wanpeng Li]

2016-10-26 21:32 GMT+08:00 Radim Krčmář :
> 2016-10-26 14:02+0800, Wanpeng Li:
>> 2016-10-25 19:43 GMT+08:00 Radim Krčmář :
>>> 2016-10-25 07:39+0800, Wanpeng Li:
 2016-10-24 23:27 GMT+08:00 Radim Krčmář :
> 2016-10-24 17:09+0200, Paolo Bonzini:
>> On 24/10/2016 17:03, Radim Krčmář wrote:
> [...]
>>
>> Reviewed-by: Paolo Bonzini 
>>
>> Go ahead, squash it into 5/5 and commit to kvm/queue. :)
>
> Did that, thanks.
>
> Wanpeng, the code is now under your name so please check it and/or
> complain.

 This patch 6/5 incurred regressions.

 - The latency of the periodic mode which is emulated by VMX preemption
 is almost the same as periodic mode which is emulated by hrtimer.
>>>
>>> Hm, what numbers are you getting?
>>
>> The two fixes look good to me. However, the codes which you remove in
>> kvm_lapic_switch_to_hv_timer() results in different numbers.
>
> Which of those two results is closer to the expected duration of the
> period?

The result of w/ remove is more closer to the expected duration.

>
>> w/o removehlt average latency = 2398462
>> w/ remove  hlt average latency = 2403845
>
> Some increase is expected when removing the code, because
> kvm_lapic_switch_to_hv_timer() decreased the period by mistake:
> it called
>
>   now = get_time()
>
> first and then did
>
>   remaining = target - get_time()  // = hrtimer_get_remaining()
>
> but some time has passed in between calls of get_time(), let's call the
> time that passed in between as "delta", so when the function later set
> the new target,
>
>   new_target = now + remaining  // = now + target - (now + delta)
>
> the new_target was "delta" earlier.

Agreed.

>
> 5k cycles is a huge difference, though ...

Yeah, delta can't be as large as 5k cycles.

> You tested the original kvm_lapic_switch_to_hv_timer(), with fixed
> advance_periodic_target_expiration()?

Yes.

>
>>> When I ran the test with the original series, then it actually had worse
>>
>> Did you test this by running my kvm-unit-tests/apic_timer_latency.flat?
>
> Yes, I used numbers from Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz,
> which had TSC calibrated to 2397.223 MHz, so the expected "average
> latency" with with the default 0x10 ns period was
>
>   0x10 * 2.397223 - 0x10 = 1465094.504447

I agree with your remove the logic in kvm_lapic_switch_to_hv_timer()
since it is more closer to the expected "average latency" now.

Regards,
Wanpeng Li

Re: [PATCH 1/8] vfs - change d_manage() to take a struct path

[Al Viro]

On Fri, Oct 21, 2016 at 07:39:36AM +0800, Ian Kent wrote:

> Maybe Al has been too busy to comment, he has been on the Cc from the start.

That's... a very mild version of what's been going on.  Let's just say that
the last few weeks had been really interesting.  Not that the shit has
settled, but there was some slackening in the shitstorm last few days.
Unlikely to last, I'm afraid, but...
 
> Hopefully this email will prompt a review, Al?

Aside of the Eric's note re constifying struct path (strongly seconded),
I'm not sure if expiration-related side of that is correct.  OTOH,
since the expiration happens from userland...

How much testing did it get?  I've several test setups involving
autofs, but they are nowhere near exhaustive and I don't have good
enough feel of the codebase to slap together something with decent
coverage...

Re: [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers

[Wanpeng Li]

2016-10-26 21:32 GMT+08:00 Radim Krčmář :
> 2016-10-26 14:02+0800, Wanpeng Li:
>> 2016-10-25 19:43 GMT+08:00 Radim Krčmář :
>>> 2016-10-25 07:39+0800, Wanpeng Li:
 2016-10-24 23:27 GMT+08:00 Radim Krčmář :
> 2016-10-24 17:09+0200, Paolo Bonzini:
>> On 24/10/2016 17:03, Radim Krčmář wrote:
> [...]
>>
>> Reviewed-by: Paolo Bonzini 
>>
>> Go ahead, squash it into 5/5 and commit to kvm/queue. :)
>
> Did that, thanks.
>
> Wanpeng, the code is now under your name so please check it and/or
> complain.

 This patch 6/5 incurred regressions.

 - The latency of the periodic mode which is emulated by VMX preemption
 is almost the same as periodic mode which is emulated by hrtimer.
>>>
>>> Hm, what numbers are you getting?
>>
>> The two fixes look good to me. However, the codes which you remove in
>> kvm_lapic_switch_to_hv_timer() results in different numbers.
>
> Which of those two results is closer to the expected duration of the
> period?

The result of w/ remove is more closer to the expected duration.

>
>> w/o removehlt average latency = 2398462
>> w/ remove  hlt average latency = 2403845
>
> Some increase is expected when removing the code, because
> kvm_lapic_switch_to_hv_timer() decreased the period by mistake:
> it called
>
>   now = get_time()
>
> first and then did
>
>   remaining = target - get_time()  // = hrtimer_get_remaining()
>
> but some time has passed in between calls of get_time(), let's call the
> time that passed in between as "delta", so when the function later set
> the new target,
>
>   new_target = now + remaining  // = now + target - (now + delta)
>
> the new_target was "delta" earlier.

Agreed.

>
> 5k cycles is a huge difference, though ...

Yeah, delta can't be as large as 5k cycles.

> You tested the original kvm_lapic_switch_to_hv_timer(), with fixed
> advance_periodic_target_expiration()?

Yes.

>
>>> When I ran the test with the original series, then it actually had worse
>>
>> Did you test this by running my kvm-unit-tests/apic_timer_latency.flat?
>
> Yes, I used numbers from Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz,
> which had TSC calibrated to 2397.223 MHz, so the expected "average
> latency" with with the default 0x10 ns period was
>
>   0x10 * 2.397223 - 0x10 = 1465094.504447

I agree with your remove the logic in kvm_lapic_switch_to_hv_timer()
since it is more closer to the expected "average latency" now.

Regards,
Wanpeng Li

Re: [PATCH] USB: OHCI: make ohci-da8xx a separate driver

[David Lechner]

On 10/26/2016 04:08 PM, ahas...@baylibre.com wrote:

From: Manjunath Goudar 

Separate the Davinci OHCI host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM

Signed-off-by: Manjunath Goudar 
[Axel: adapted and rebased, fixed minor comments]
Signed-off-by: Axel Haslam 
---


This is working for me as a module on LEGO MINDSTORMS EV3.

Tested-By: David Lechner 

Re: [PATCH] USB: OHCI: make ohci-da8xx a separate driver

[David Lechner]

On 10/26/2016 04:08 PM, ahas...@baylibre.com wrote:

From: Manjunath Goudar 

Separate the Davinci OHCI host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM

Signed-off-by: Manjunath Goudar 
[Axel: adapted and rebased, fixed minor comments]
Signed-off-by: Axel Haslam 
---


This is working for me as a module on LEGO MINDSTORMS EV3.

Tested-By: David Lechner 

Re: [PATCH v2 00/11] mpt3sas driver Enhancements and

[Martin K. Petersen]

> "Suganath" == Suganath Prabu S  
> writes:

Suganath> Here is the change list: Posting 11 patches for mpt3sas driver
Suganath> enhancements and few fixes.
Suganath>   * Added Device ID's for SAS35 devices and updated MPI
Suganath> Header.
Suganath>   * Support "EEDP Escape flag" for SAS35 devices.
Suganath>   * fixed improper printk statement.
Suganath>   * Regardless of whether RDPQ disabled card is enumerated
Suganath> first or RDPQ enabled card is enumerated first, MSIX
Suganath> vectors depends on the cards capability.
Suganath>   * device_remove_in_progress bit check has been added in
Suganath> IOCTL path. If bit is set, then IOCTL will be failed
Suganath> printing failure message.
Suganath>   * Started using the Atomic Request Descriptors for
Suganath> SAS35 devices.
Suganath>   * For SAS35 devices MSIX vectors are inceased to 128 from
Suganath> 96.
Suganath>   * Fixing Endianness issue.
Suganath>   * Updated driver version to 14.100.00.00 at the end of SAS3
Suganath> changes and updated driver minor version to 14.101.00.00
Suganath> after SAS35 changes.

Applied to 4.10/scsi-queue.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2 00/11] mpt3sas driver Enhancements and

[Martin K. Petersen]

> "Suganath" == Suganath Prabu S  
> writes:

Suganath> Here is the change list: Posting 11 patches for mpt3sas driver
Suganath> enhancements and few fixes.
Suganath>   * Added Device ID's for SAS35 devices and updated MPI
Suganath> Header.
Suganath>   * Support "EEDP Escape flag" for SAS35 devices.
Suganath>   * fixed improper printk statement.
Suganath>   * Regardless of whether RDPQ disabled card is enumerated
Suganath> first or RDPQ enabled card is enumerated first, MSIX
Suganath> vectors depends on the cards capability.
Suganath>   * device_remove_in_progress bit check has been added in
Suganath> IOCTL path. If bit is set, then IOCTL will be failed
Suganath> printing failure message.
Suganath>   * Started using the Atomic Request Descriptors for
Suganath> SAS35 devices.
Suganath>   * For SAS35 devices MSIX vectors are inceased to 128 from
Suganath> 96.
Suganath>   * Fixing Endianness issue.
Suganath>   * Updated driver version to 14.100.00.00 at the end of SAS3
Suganath> changes and updated driver minor version to 14.101.00.00
Suganath> after SAS35 changes.

Applied to 4.10/scsi-queue.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2 2/4] input: evdev: Replace timeval with timespec64

[Peter Hutterer]

On Mon, Oct 17, 2016 at 08:27:31PM -0700, Deepa Dinamani wrote:
> struct timeval is not y2038 safe.
> 
> All references to timeval in the kernel will be replaced
> by y2038 safe structures.
> Replace all references to timeval with y2038 safe
> struct timespec64 here.
> 
> struct input_event will be changed in a different patch.
> 
> Signed-off-by: Deepa Dinamani 
> Reviewed-by: Arnd Bergmann 
> ---
>  drivers/input/evdev.c | 37 +++--
>  1 file changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index e9ae3d5..b4e3171 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -156,15 +156,22 @@ static void __evdev_flush_queue(struct evdev_client 
> *client, unsigned int type)
>  static void __evdev_queue_syn_dropped(struct evdev_client *client)
>  {
>   struct input_event ev;
> - ktime_t time;
> + struct timespec64 ts;
>  
> - time = client->clk_type == EV_CLK_REAL ?
> - ktime_get_real() :
> - client->clk_type == EV_CLK_MONO ?
> - ktime_get() :
> - ktime_get_boottime();
> + switch (client->clk_type) {
> + case EV_CLK_REAL:
> + ktime_get_real_ts64();
> + break;
> + case EV_CLK_MONO:
> + ktime_get_ts64();
> + break;
> + case EV_CLK_BOOT:
> + get_monotonic_boottime64();
> + break;
> + }
>  
> - ev.time = ktime_to_timeval(time);
> + ev.time.tv_sec = ts.tv_sec;
> + ev.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
>   ev.type = EV_SYN;
>   ev.code = SYN_DROPPED;
>   ev.value = 0;
> @@ -257,17 +264,20 @@ static void __pass_event(struct evdev_client *client,
>  
>  static void evdev_pass_values(struct evdev_client *client,
>   const struct input_value *vals, unsigned int count,
> - ktime_t *ev_time)
> + struct timespec64 *ev_time)
>  {
>   struct evdev *evdev = client->evdev;
>   const struct input_value *v;
>   struct input_event event;
> + struct timespec64 ts;
>   bool wakeup = false;
>  
>   if (client->revoked)
>   return;
>  
> - event.time = ktime_to_timeval(ev_time[client->clk_type]);
> + ts = ev_time[client->clk_type];
> + event.time.tv_sec = ts.tv_sec;
> + event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;

you have ktime_get_* helpers below but you don't have one for timespec64 to
struct timeval? That seems like a bug waitig to happen.

Cheers,
   Peter

>  
>   /* Interrupts are disabled, just acquire the lock. */
>   spin_lock(>buffer_lock);
> @@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle,
>  {
>   struct evdev *evdev = handle->private;
>   struct evdev_client *client;
> - ktime_t ev_time[EV_CLK_MAX];
> + struct timespec64 ev_time[EV_CLK_MAX];
>  
> - ev_time[EV_CLK_MONO] = ktime_get();
> - ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
> - ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
> -  TK_OFFS_BOOT);
> + ktime_get_ts64(_time[EV_CLK_MONO]);
> + ktime_get_real_ts64(_time[EV_CLK_REAL]);
> + get_monotonic_boottime64(_time[EV_CLK_BOOT]);
>  
>   rcu_read_lock();
>  
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v2 2/4] input: evdev: Replace timeval with timespec64

[Peter Hutterer]

On Mon, Oct 17, 2016 at 08:27:31PM -0700, Deepa Dinamani wrote:
> struct timeval is not y2038 safe.
> 
> All references to timeval in the kernel will be replaced
> by y2038 safe structures.
> Replace all references to timeval with y2038 safe
> struct timespec64 here.
> 
> struct input_event will be changed in a different patch.
> 
> Signed-off-by: Deepa Dinamani 
> Reviewed-by: Arnd Bergmann 
> ---
>  drivers/input/evdev.c | 37 +++--
>  1 file changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index e9ae3d5..b4e3171 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -156,15 +156,22 @@ static void __evdev_flush_queue(struct evdev_client 
> *client, unsigned int type)
>  static void __evdev_queue_syn_dropped(struct evdev_client *client)
>  {
>   struct input_event ev;
> - ktime_t time;
> + struct timespec64 ts;
>  
> - time = client->clk_type == EV_CLK_REAL ?
> - ktime_get_real() :
> - client->clk_type == EV_CLK_MONO ?
> - ktime_get() :
> - ktime_get_boottime();
> + switch (client->clk_type) {
> + case EV_CLK_REAL:
> + ktime_get_real_ts64();
> + break;
> + case EV_CLK_MONO:
> + ktime_get_ts64();
> + break;
> + case EV_CLK_BOOT:
> + get_monotonic_boottime64();
> + break;
> + }
>  
> - ev.time = ktime_to_timeval(time);
> + ev.time.tv_sec = ts.tv_sec;
> + ev.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
>   ev.type = EV_SYN;
>   ev.code = SYN_DROPPED;
>   ev.value = 0;
> @@ -257,17 +264,20 @@ static void __pass_event(struct evdev_client *client,
>  
>  static void evdev_pass_values(struct evdev_client *client,
>   const struct input_value *vals, unsigned int count,
> - ktime_t *ev_time)
> + struct timespec64 *ev_time)
>  {
>   struct evdev *evdev = client->evdev;
>   const struct input_value *v;
>   struct input_event event;
> + struct timespec64 ts;
>   bool wakeup = false;
>  
>   if (client->revoked)
>   return;
>  
> - event.time = ktime_to_timeval(ev_time[client->clk_type]);
> + ts = ev_time[client->clk_type];
> + event.time.tv_sec = ts.tv_sec;
> + event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;

you have ktime_get_* helpers below but you don't have one for timespec64 to
struct timeval? That seems like a bug waitig to happen.

Cheers,
   Peter

>  
>   /* Interrupts are disabled, just acquire the lock. */
>   spin_lock(>buffer_lock);
> @@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle,
>  {
>   struct evdev *evdev = handle->private;
>   struct evdev_client *client;
> - ktime_t ev_time[EV_CLK_MAX];
> + struct timespec64 ev_time[EV_CLK_MAX];
>  
> - ev_time[EV_CLK_MONO] = ktime_get();
> - ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
> - ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
> -  TK_OFFS_BOOT);
> + ktime_get_ts64(_time[EV_CLK_MONO]);
> + ktime_get_real_ts64(_time[EV_CLK_REAL]);
> + get_monotonic_boottime64(_time[EV_CLK_BOOT]);
>  
>   rcu_read_lock();
>  
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [lkp] [x86/platform/UV] 71854cb812: will-it-scale.per_thread_ops -2.3% regression

[Ye Xiaolong]

On 10/25, Thomas Gleixner wrote:
>On Tue, 25 Oct 2016, kernel test robot wrote:
>> FYI, we noticed a -2.3% regression of will-it-scale.per_thread_ops due to 
>> commit:
>> 
>> commit 71854cb812ec23bfe5f63d52217e6b9e6cb901f5 ("x86/platform/UV: Fix 
>> support for EFI_OLD_MEMMAP after BIOS callback updates")
>> https://github.com/0day-ci/linux 
>> Alex-Thorlton/x86-platform-UV-Fix-support-for-EFI_OLD_MEMMAP-after-BIOS-callback-updates/20161020-095215
>> 
>> in testcase: will-it-scale
>> on test machine: 12 threads Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz with 6G 
>> memory
>
>This is completely bogus. That patch does not even affect anything outside
>of the SGI UV platform. And on your i7 system uv_bios_call() is definitely
>not invoked.

Yes, this is weird, the per_thread_ops change is small and should be run
to run variation, the actual significant change is will-it-scale.time.user_time
-27% decrease, but the patch seems not relevant, we can't interpret it. :(

We've tried to queue the jobs (4 times) for 
71854cb812ec23bfe5f63d52217e6b9e6cb901f5 and v4.9-rc1
with new kconfig (added CONFIG_DEBUG_INFO_REDUCED), and result shows
user_time change is quite stable.


=
compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
  
gcc-6/performance/x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED/debian-x86_64-2016-08-31.cgz/wsm/read2/will-it-scale

commit:
  v4.9-rc1
  71854cb812ec23bfe5f63d52217e6b9e6cb901f5

v4.9-rc1 71854cb812ec23bfe5f63d5221
 -- 
 %stddev %change %stddev
 \  |\
   1670068 ±  0%  -3.8%1606650 ±  1%  will-it-scale.per_thread_ops
  9749 ±  2%   +1328.0% 139222 ±105%  
will-it-scale.time.involuntary_context_switches
981.29 ±  0%  +2.2%   1002 ±  0%  will-it-scale.time.system_time
 81.78 ±  0% -26.9%  59.74 ±  0%  will-it-scale.time.user_time
 32894 ±  0%  -3.1%  31863 ±  2%  vmstat.system.cs
  9749 ±  2%   +1328.0% 139222 ±105%  time.involuntary_context_switches
380917 ±  2% -10.2% 341970 ±  3%  sched_debug.cpu.avg_idle.avg
 89166 ± 33% -73.4%  23731 ± 29%  sched_debug.cpu.avg_idle.min
 16.38 ± 10% -32.3%  11.08 ± 18%  
sched_debug.cpu.nr_uninterruptible.max
  0.29 ±  1% +32.6%   0.38 ±  1%  perf-stat.branch-miss-rate%
 2.897e+09 ±  1% +33.5%  3.867e+09 ±  2%  perf-stat.branch-misses
  10084878 ±  0%  -3.2%9761852 ±  2%  perf-stat.context-switches
  0.00 ±  7%  -9.3%   0.00 ±  1%  perf-stat.dTLB-store-miss-rate%
  33489012 ±  7%  -9.2%   30416429 ±  1%  perf-stat.dTLB-store-misses

Thanks,
Xiaolong
>
>I appreciate your effort, but posting such obviously bogus results does not
>make people more confident in your testing efforts.
>
>Thanks,
>
>   tglx

Re: [lkp] [x86/platform/UV] 71854cb812: will-it-scale.per_thread_ops -2.3% regression

[Ye Xiaolong]

On 10/25, Thomas Gleixner wrote:
>On Tue, 25 Oct 2016, kernel test robot wrote:
>> FYI, we noticed a -2.3% regression of will-it-scale.per_thread_ops due to 
>> commit:
>> 
>> commit 71854cb812ec23bfe5f63d52217e6b9e6cb901f5 ("x86/platform/UV: Fix 
>> support for EFI_OLD_MEMMAP after BIOS callback updates")
>> https://github.com/0day-ci/linux 
>> Alex-Thorlton/x86-platform-UV-Fix-support-for-EFI_OLD_MEMMAP-after-BIOS-callback-updates/20161020-095215
>> 
>> in testcase: will-it-scale
>> on test machine: 12 threads Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz with 6G 
>> memory
>
>This is completely bogus. That patch does not even affect anything outside
>of the SGI UV platform. And on your i7 system uv_bios_call() is definitely
>not invoked.

Yes, this is weird, the per_thread_ops change is small and should be run
to run variation, the actual significant change is will-it-scale.time.user_time
-27% decrease, but the patch seems not relevant, we can't interpret it. :(

We've tried to queue the jobs (4 times) for 
71854cb812ec23bfe5f63d52217e6b9e6cb901f5 and v4.9-rc1
with new kconfig (added CONFIG_DEBUG_INFO_REDUCED), and result shows
user_time change is quite stable.


=
compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
  
gcc-6/performance/x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED/debian-x86_64-2016-08-31.cgz/wsm/read2/will-it-scale

commit:
  v4.9-rc1
  71854cb812ec23bfe5f63d52217e6b9e6cb901f5

v4.9-rc1 71854cb812ec23bfe5f63d5221
 -- 
 %stddev %change %stddev
 \  |\
   1670068 ±  0%  -3.8%1606650 ±  1%  will-it-scale.per_thread_ops
  9749 ±  2%   +1328.0% 139222 ±105%  
will-it-scale.time.involuntary_context_switches
981.29 ±  0%  +2.2%   1002 ±  0%  will-it-scale.time.system_time
 81.78 ±  0% -26.9%  59.74 ±  0%  will-it-scale.time.user_time
 32894 ±  0%  -3.1%  31863 ±  2%  vmstat.system.cs
  9749 ±  2%   +1328.0% 139222 ±105%  time.involuntary_context_switches
380917 ±  2% -10.2% 341970 ±  3%  sched_debug.cpu.avg_idle.avg
 89166 ± 33% -73.4%  23731 ± 29%  sched_debug.cpu.avg_idle.min
 16.38 ± 10% -32.3%  11.08 ± 18%  
sched_debug.cpu.nr_uninterruptible.max
  0.29 ±  1% +32.6%   0.38 ±  1%  perf-stat.branch-miss-rate%
 2.897e+09 ±  1% +33.5%  3.867e+09 ±  2%  perf-stat.branch-misses
  10084878 ±  0%  -3.2%9761852 ±  2%  perf-stat.context-switches
  0.00 ±  7%  -9.3%   0.00 ±  1%  perf-stat.dTLB-store-miss-rate%
  33489012 ±  7%  -9.2%   30416429 ±  1%  perf-stat.dTLB-store-misses

Thanks,
Xiaolong
>
>I appreciate your effort, but posting such obviously bogus results does not
>make people more confident in your testing efforts.
>
>Thanks,
>
>   tglx

cygnus-pcm.c:undefined reference to `bad_dma_ops'

[kbuild test robot]

Hi Mark,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
commit: 3ceeda1cbee9f93bb5537c9b840d1f7e767d7c01 Merge remote-tracking branches 
'asoc/topic/cs53l30', 'asoc/topic/cygnus', 'asoc/topic/da7219' and 
'asoc/topic/davinci' into asoc-next
date:   3 months ago
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3ceeda1cbee9f93bb5537c9b840d1f7e767d7c01
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All errors (new ones prefixed by >>):

   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfcf4): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfcf8): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfd48): undefined reference to `dma_common_mmap'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfd48): relocation truncated to fit: R_M32R_26_PCREL_RELA against 
undefined symbol `dma_common_mmap'
   sound/built-in.o: In function `cygnus_pcm_preallocate_dma_buffer':
>> cygnus-pcm.c:(.text+0x10e94c): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x10e950): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x10e984): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `cygnus_dma_free_dma_buffers':
   cygnus-pcm.c:(.text+0x10ea84): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x10ea8c): undefined reference to `bad_dma_ops'
   sound/built-in.o:cygnus-pcm.c:(.text+0x10eb24): more undefined references to 
`bad_dma_ops' follow

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


.config.gz
Description: application/gzip

cygnus-pcm.c:undefined reference to `bad_dma_ops'

[kbuild test robot]

Hi Mark,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
commit: 3ceeda1cbee9f93bb5537c9b840d1f7e767d7c01 Merge remote-tracking branches 
'asoc/topic/cs53l30', 'asoc/topic/cygnus', 'asoc/topic/da7219' and 
'asoc/topic/davinci' into asoc-next
date:   3 months ago
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3ceeda1cbee9f93bb5537c9b840d1f7e767d7c01
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All errors (new ones prefixed by >>):

   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfcf4): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfcf8): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfd48): undefined reference to `dma_common_mmap'
   sound/built-in.o: In function `snd_pcm_lib_default_mmap':
   (.text+0xfd48): relocation truncated to fit: R_M32R_26_PCREL_RELA against 
undefined symbol `dma_common_mmap'
   sound/built-in.o: In function `cygnus_pcm_preallocate_dma_buffer':
>> cygnus-pcm.c:(.text+0x10e94c): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x10e950): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x10e984): undefined reference to `bad_dma_ops'
   sound/built-in.o: In function `cygnus_dma_free_dma_buffers':
   cygnus-pcm.c:(.text+0x10ea84): undefined reference to `bad_dma_ops'
   cygnus-pcm.c:(.text+0x10ea8c): undefined reference to `bad_dma_ops'
   sound/built-in.o:cygnus-pcm.c:(.text+0x10eb24): more undefined references to 
`bad_dma_ops' follow

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


.config.gz
Description: application/gzip

Re: [PATCH v2 1/4] uinput: Add ioctl for using monotonic/ boot times

[Peter Hutterer]

On Mon, Oct 17, 2016 at 08:27:30PM -0700, Deepa Dinamani wrote:
> struct timeval which is part of struct input_event to
> maintain the event times is not y2038 safe.
> 
> Real time timestamps are also not ideal for input_event
> as this time can go backwards as noted in the patch
> a80b83b7b8 by John Stultz.
> 
> Arnd Bergmann suggested deprecating real time and using
> monotonic or other timers for all input_event times as a
> solution to both the above problems.
> 
> Add a new ioctl to let the user dictate the kind of time
> to be used for input events. This is similar to the evdev
> implementation of the feature. Realtime is still the
> default time. This is to maintain backward compatibility.
> 
> The structure to maintain input events will be changed
> in a different patch.
> 
> Signed-off-by: Deepa Dinamani 
> ---
>  drivers/input/misc/uinput.c | 56 
> -
>  include/linux/uinput.h  |  1 +
>  include/uapi/linux/uinput.h |  3 +++
>  3 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 92595b9..3d75c5a 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -46,11 +46,26 @@ static int uinput_dev_event(struct input_dev *dev,
>   unsigned int type, unsigned int code, int value)
>  {
>   struct uinput_device*udev = input_get_drvdata(dev);
> + struct timespec64   ts;
>  
>   udev->buff[udev->head].type = type;
>   udev->buff[udev->head].code = code;
>   udev->buff[udev->head].value = value;
> - do_gettimeofday(>buff[udev->head].time);
> +
> + switch (udev->clk_type) {
> + case CLOCK_REALTIME:
> + ktime_get_real_ts64();
> + break;
> + case CLOCK_MONOTONIC:
> + ktime_get_ts64();
> + break;
> + case CLOCK_BOOTTIME:
> + get_monotonic_boottime64();
> + break;
> + }

hmm, I'm a bit confused here. This is an in-kernel bit only (passing the
time through uinput events has no effect). So why do we need an ioctl here?
it's an in-kernel decision only anyway and the time in the events sent to
the evdev client should be dictated by what that client sets for the clock
type, right?

Cheers,
   Peter

> +
> + udev->buff[udev->head].time.tv_sec = ts.tv_sec;
> + udev->buff[udev->head].time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
>   udev->head = (udev->head + 1) % UINPUT_BUFFER_SIZE;
>  
>   wake_up_interruptible(>waitq);
> @@ -295,6 +310,7 @@ static int uinput_create_device(struct uinput_device 
> *udev)
>   if (error)
>   goto fail2;
>  
> + udev->clk_type = CLOCK_REALTIME;
>   udev->state = UIST_CREATED;
>  
>   return 0;
> @@ -304,6 +320,38 @@ static int uinput_create_device(struct uinput_device 
> *udev)
>   return error;
>  }
>  
> +static int uinput_set_clk_type(struct uinput_device *udev, unsigned int 
> clkid)
> +{
> + unsigned int clk_type;
> +
> + if (udev->state != UIST_CREATED)
> + return -EINVAL;
> +
> + switch (clkid) {
> + /* Realtime clock is only valid until year 2038.*/
> + case CLOCK_REALTIME:
> + clk_type = CLOCK_REALTIME;
> + break;
> + case CLOCK_MONOTONIC:
> + clk_type = CLOCK_MONOTONIC;
> + break;
> + case CLOCK_BOOTTIME:
> + clk_type = CLOCK_BOOTTIME;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (udev->clk_type != clk_type) {
> + udev->clk_type = clk_type;
> +
> + /* Flush pending events */
> + uinput_flush_requests(udev);
> + }
> +
> + return 0;
> +}
> +
>  static int uinput_open(struct inode *inode, struct file *file)
>  {
>   struct uinput_device *newdev;
> @@ -787,6 +835,7 @@ static long uinput_ioctl_handler(struct file *file, 
> unsigned int cmd,
>   char*phys;
>   const char  *name;
>   unsigned intsize;
> + int clock_id;
>  
>   retval = mutex_lock_interruptible(>mutex);
>   if (retval)
> @@ -817,6 +866,11 @@ static long uinput_ioctl_handler(struct file *file, 
> unsigned int cmd,
>   retval = uinput_dev_setup(udev, p);
>   goto out;
>  
> + case UI_SET_CLOCKID:
> + if (copy_from_user(_id, p, sizeof(unsigned int)))
> + return -EFAULT;
> + return uinput_set_clk_type(udev, clock_id);
> +
>   /* UI_ABS_SETUP is handled in the variable size ioctls */
>  
>   case UI_SET_EVBIT:
> diff --git a/include/linux/uinput.h b/include/linux/uinput.h
> index 75de43d..6527fb7 100644
> --- a/include/linux/uinput.h
> +++ b/include/linux/uinput.h
> @@ -72,6 +72,7 @@ struct uinput_device {
>   unsigned char   

Re: [PATCH v2 1/4] uinput: Add ioctl for using monotonic/ boot times

[Peter Hutterer]

On Mon, Oct 17, 2016 at 08:27:30PM -0700, Deepa Dinamani wrote:
> struct timeval which is part of struct input_event to
> maintain the event times is not y2038 safe.
> 
> Real time timestamps are also not ideal for input_event
> as this time can go backwards as noted in the patch
> a80b83b7b8 by John Stultz.
> 
> Arnd Bergmann suggested deprecating real time and using
> monotonic or other timers for all input_event times as a
> solution to both the above problems.
> 
> Add a new ioctl to let the user dictate the kind of time
> to be used for input events. This is similar to the evdev
> implementation of the feature. Realtime is still the
> default time. This is to maintain backward compatibility.
> 
> The structure to maintain input events will be changed
> in a different patch.
> 
> Signed-off-by: Deepa Dinamani 
> ---
>  drivers/input/misc/uinput.c | 56 
> -
>  include/linux/uinput.h  |  1 +
>  include/uapi/linux/uinput.h |  3 +++
>  3 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 92595b9..3d75c5a 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -46,11 +46,26 @@ static int uinput_dev_event(struct input_dev *dev,
>   unsigned int type, unsigned int code, int value)
>  {
>   struct uinput_device*udev = input_get_drvdata(dev);
> + struct timespec64   ts;
>  
>   udev->buff[udev->head].type = type;
>   udev->buff[udev->head].code = code;
>   udev->buff[udev->head].value = value;
> - do_gettimeofday(>buff[udev->head].time);
> +
> + switch (udev->clk_type) {
> + case CLOCK_REALTIME:
> + ktime_get_real_ts64();
> + break;
> + case CLOCK_MONOTONIC:
> + ktime_get_ts64();
> + break;
> + case CLOCK_BOOTTIME:
> + get_monotonic_boottime64();
> + break;
> + }

hmm, I'm a bit confused here. This is an in-kernel bit only (passing the
time through uinput events has no effect). So why do we need an ioctl here?
it's an in-kernel decision only anyway and the time in the events sent to
the evdev client should be dictated by what that client sets for the clock
type, right?

Cheers,
   Peter

> +
> + udev->buff[udev->head].time.tv_sec = ts.tv_sec;
> + udev->buff[udev->head].time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
>   udev->head = (udev->head + 1) % UINPUT_BUFFER_SIZE;
>  
>   wake_up_interruptible(>waitq);
> @@ -295,6 +310,7 @@ static int uinput_create_device(struct uinput_device 
> *udev)
>   if (error)
>   goto fail2;
>  
> + udev->clk_type = CLOCK_REALTIME;
>   udev->state = UIST_CREATED;
>  
>   return 0;
> @@ -304,6 +320,38 @@ static int uinput_create_device(struct uinput_device 
> *udev)
>   return error;
>  }
>  
> +static int uinput_set_clk_type(struct uinput_device *udev, unsigned int 
> clkid)
> +{
> + unsigned int clk_type;
> +
> + if (udev->state != UIST_CREATED)
> + return -EINVAL;
> +
> + switch (clkid) {
> + /* Realtime clock is only valid until year 2038.*/
> + case CLOCK_REALTIME:
> + clk_type = CLOCK_REALTIME;
> + break;
> + case CLOCK_MONOTONIC:
> + clk_type = CLOCK_MONOTONIC;
> + break;
> + case CLOCK_BOOTTIME:
> + clk_type = CLOCK_BOOTTIME;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (udev->clk_type != clk_type) {
> + udev->clk_type = clk_type;
> +
> + /* Flush pending events */
> + uinput_flush_requests(udev);
> + }
> +
> + return 0;
> +}
> +
>  static int uinput_open(struct inode *inode, struct file *file)
>  {
>   struct uinput_device *newdev;
> @@ -787,6 +835,7 @@ static long uinput_ioctl_handler(struct file *file, 
> unsigned int cmd,
>   char*phys;
>   const char  *name;
>   unsigned intsize;
> + int clock_id;
>  
>   retval = mutex_lock_interruptible(>mutex);
>   if (retval)
> @@ -817,6 +866,11 @@ static long uinput_ioctl_handler(struct file *file, 
> unsigned int cmd,
>   retval = uinput_dev_setup(udev, p);
>   goto out;
>  
> + case UI_SET_CLOCKID:
> + if (copy_from_user(_id, p, sizeof(unsigned int)))
> + return -EFAULT;
> + return uinput_set_clk_type(udev, clock_id);
> +
>   /* UI_ABS_SETUP is handled in the variable size ioctls */
>  
>   case UI_SET_EVBIT:
> diff --git a/include/linux/uinput.h b/include/linux/uinput.h
> index 75de43d..6527fb7 100644
> --- a/include/linux/uinput.h
> +++ b/include/linux/uinput.h
> @@ -72,6 +72,7 @@ struct uinput_device {
>   unsigned char   head;
>   unsigned 

Re: [PATCH] advansys: fix build warning for PCI=n

[Martin K. Petersen]

> "Arnd" == Arnd Bergmann  writes:

Arnd> The advansys probe function tries to handle both ISA and PCI
Arnd> cases, each hidden in an #ifdef when unused. This leads to a
Arnd> warning indicating that when PCI is disabled we could be using
Arnd> uninitialized data:

Arnd> drivers/scsi/advansys.c: In function ‘advansys_board_found’:
Arnd> drivers/scsi/advansys.c:11036:5: error: ‘ret’ may be used
Arnd> uninitialized in this function [-Werror=maybe-uninitialized]
Arnd> drivers/scsi/advansys.c:10928:28: note: ‘ret’ was declared here
Arnd> drivers/scsi/advansys.c:11309:8: error: ‘share_irq’ may be used
Arnd> uninitialized in this function [-Werror=maybe-uninitialized]
Arnd> drivers/scsi/advansys.c:10928:6: note: ‘share_irq’ was declared
Arnd> here

Arnd> This cannot happen in practice because the hardware in question
Arnd> only exists for PCI, but changing the code to just error out here
Arnd> is better for consistency and avoids the warning.

Applied to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] advansys: fix build warning for PCI=n

[Martin K. Petersen]

> "Arnd" == Arnd Bergmann  writes:

Arnd> The advansys probe function tries to handle both ISA and PCI
Arnd> cases, each hidden in an #ifdef when unused. This leads to a
Arnd> warning indicating that when PCI is disabled we could be using
Arnd> uninitialized data:

Arnd> drivers/scsi/advansys.c: In function ‘advansys_board_found’:
Arnd> drivers/scsi/advansys.c:11036:5: error: ‘ret’ may be used
Arnd> uninitialized in this function [-Werror=maybe-uninitialized]
Arnd> drivers/scsi/advansys.c:10928:28: note: ‘ret’ was declared here
Arnd> drivers/scsi/advansys.c:11309:8: error: ‘share_irq’ may be used
Arnd> uninitialized in this function [-Werror=maybe-uninitialized]
Arnd> drivers/scsi/advansys.c:10928:6: note: ‘share_irq’ was declared
Arnd> here

Arnd> This cannot happen in practice because the hardware in question
Arnd> only exists for PCI, but changing the code to just error out here
Arnd> is better for consistency and avoids the warning.

Applied to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

[ANNOUNCE] 3.10.104-rt116

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.10.104-rt116 stable release.


This release is just an update to the new stable 3.10.104 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.10-rt
  Head SHA1: e5719dde12ac3b2f4ac0aabdb911aecff8911966


Or to build 3.10.104-rt116 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.104.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.104-rt116.patch.xz




Enjoy,

-- Steve

[ANNOUNCE] 3.2.83-rt120

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.2.83-rt120 stable release.


This release is just an update to the new stable 3.2.83 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.2-rt
  Head SHA1: 6c96e2352a3f78093f231f256b7eee0995611ba3


Or to build 3.2.83-rt120 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.83.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.83-rt120.patch.xz




Enjoy,

-- Steve

[ANNOUNCE] 3.10.104-rt116

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.10.104-rt116 stable release.


This release is just an update to the new stable 3.10.104 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.10-rt
  Head SHA1: e5719dde12ac3b2f4ac0aabdb911aecff8911966


Or to build 3.10.104-rt116 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.104.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.104-rt116.patch.xz




Enjoy,

-- Steve

[ANNOUNCE] 3.2.83-rt120

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.2.83-rt120 stable release.


This release is just an update to the new stable 3.2.83 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.2-rt
  Head SHA1: 6c96e2352a3f78093f231f256b7eee0995611ba3


Or to build 3.2.83-rt120 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.83.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.83-rt120.patch.xz




Enjoy,

-- Steve