[PATCH] usbip: vhci_hcd: print correct info in default case

[Pei Zhang]

In this switch-case logical, 2 cases will goes to default case.
The default log should exclude the upper 2 cases.

Signed-off-by: Pei Zhang 
---
 drivers/usb/usbip/vhci_hcd.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 0585078..b0057ac 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -406,7 +406,9 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
 
/* FALLTHROUGH */
default:
-   usbip_dbg_vhci_rh(" SetPortFeature: default %d\n",
+   if (wValue != USB_PORT_FEAT_SUSPEND &&
+   wValue != USB_PORT_FEAT_RESET)
+   usbip_dbg_vhci_rh(" SetPortFeature: default 
%d\n",
  wValue);
dum->port_status[rhport] |= (1 << wValue);
break;
-- 
2.7.4

Re: linux-next: build failure after merge of the printk tree

[Sergey Senozhatsky]

Hello,

On (12/06/17 14:23), Stephen Rothwell wrote:
> Hi Petr,
> 
> After merging the printk tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
> 
> lib/vsprintf.o: In function `pointer':
> vsprintf.c:(.text+0x2260): undefined reference to 
> `dereference_symbol_descriptor'
> 
> Caused by commit
> 
>   b77929215209 ("symbol lookup: introduce dereference_symbol_descriptor()")
> 
> I have reverted that commit for today.


thanks. will fix it.

-ss

In kernel power management domain_pm created for async schedules

[Vikas Bansal]

If there is a driver in system which starts creating async schedules just after 
resume (Same as our case, in which we faced issue). Then async_synchronize_full 
API in PM cores starts waiting for completion of async schedules created by 
that driver (Even though those are in a domain). Because of this kernel resume 
time is increased (We faces the same issue) and whole system is delayed. 
This problem can be solved by creating is domain for async schedules in PM core 
(As we solved in our case). Below patch is for solving this problem.


>From b8ea152eed6eef3b53275e7dd240a4d2124e9d4d Mon Sep 17 00:00:00 2001
From: Anuj Gupta 
Date: Tue, 5 Dec 2017 21:34:49 -0800
Subject: [PATCH] Added domain_pm to PM core


Signed-off-by: Vikas Bansal 
---
 drivers/base/power/main.c |   25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index db2f044..2d19dfb 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -39,6 +39,7 @@
 #include "power.h"
 
 typedef int (*pm_callback_t)(struct device *);
+ASYNC_DOMAIN(domain_pm);
 
 /*
  * The entries in the dpm_list list are in a depth first order, simply
@@ -615,7 +616,7 @@ void dpm_noirq_resume_devices(pm_message_t state)
reinit_completion(>power.completion);
if (is_async(dev)) {
get_device(dev);
-   async_schedule(async_resume_noirq, dev);
+   async_schedule_domain(async_resume_noirq, dev, 
_pm);
}
}
 
@@ -641,7 +642,7 @@ void dpm_noirq_resume_devices(pm_message_t state)
put_device(dev);
}
mutex_unlock(_list_mtx);
-   async_synchronize_full();
+   async_synchronize_full_domain(_pm);
dpm_show_time(starttime, state, 0, "noirq");
trace_suspend_resume(TPS("dpm_resume_noirq"), state.event, false);
 }
@@ -755,7 +756,7 @@ void dpm_resume_early(pm_message_t state)
reinit_completion(>power.completion);
if (is_async(dev)) {
get_device(dev);
-   async_schedule(async_resume_early, dev);
+   async_schedule_domain(async_resume_early, dev, 
_pm);
}
}
 
@@ -780,7 +781,7 @@ void dpm_resume_early(pm_message_t state)
put_device(dev);
}
mutex_unlock(_list_mtx);
-   async_synchronize_full();
+   async_synchronize_full_domain(_pm);
dpm_show_time(starttime, state, 0, "early");
trace_suspend_resume(TPS("dpm_resume_early"), state.event, false);
 }
@@ -919,7 +920,7 @@ void dpm_resume(pm_message_t state)
reinit_completion(>power.completion);
if (is_async(dev)) {
get_device(dev);
-   async_schedule(async_resume, dev);
+   async_schedule_domain(async_resume, dev, _pm);
}
}
 
@@ -946,7 +947,7 @@ void dpm_resume(pm_message_t state)
put_device(dev);
}
mutex_unlock(_list_mtx);
-   async_synchronize_full();
+   async_synchronize_full_domain(_pm);
dpm_show_time(starttime, state, 0, NULL);
 
cpufreq_resume();
@@ -1156,7 +1157,7 @@ static int device_suspend_noirq(struct device *dev)
 
if (is_async(dev)) {
get_device(dev);
-   async_schedule(async_suspend_noirq, dev);
+   async_schedule_domain(async_suspend_noirq, dev, _pm);
return 0;
}
return __device_suspend_noirq(dev, pm_transition, false);
@@ -1202,7 +1203,7 @@ int dpm_noirq_suspend_devices(pm_message_t state)
break;
}
mutex_unlock(_list_mtx);
-   async_synchronize_full();
+   async_synchronize_full_domain(_pm);
if (!error)
error = async_error;
 
@@ -1316,7 +1317,7 @@ static int device_suspend_late(struct device *dev)
 
if (is_async(dev)) {
get_device(dev);
-   async_schedule(async_suspend_late, dev);
+   async_schedule_domain(async_suspend_late, dev, _pm);
return 0;
}
 
@@ -1361,7 +1362,7 @@ int dpm_suspend_late(pm_message_t state)
break;
}
mutex_unlock(_list_mtx);
-   async_synchronize_full();
+   async_synchronize_full_domain(_pm);
if (!error)
error = async_error;
if (error) {
@@ -1576,7 +1577,7 @@ static int device_suspend(struct device *dev)
 
if (is_async(dev)) {
get_device(dev);
-   async_schedule(async_suspend, dev);
+   async_schedule_domain(async_suspend, dev, _pm);
return 0;
}
 
@@ -1622,7 +1623,7 @@ int dpm_suspend(pm_message_t state)
break;
}

RE: [PATCH] [linux][master][v1] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

[Dhaval Rajeshbhai Shah]

Hi Arnd,

Replies inline.

-Original Message-
From: arndbergm...@gmail.com [mailto:arndbergm...@gmail.com] On Behalf Of Arnd 
Bergmann
Sent: Tuesday, December 05, 2017 5:32 AM
To: Dhaval Rajeshbhai Shah 
Cc: gregkh ; Linux Kernel Mailing List 
; Michal Simek ; Hyun 
Kwon 
Subject: Re: [PATCH] [linux][master][v1] misc: Add Xilinx ZYNQMP VCU logicoreIP 
init driver

On Tue, Dec 5, 2017 at 1:38 PM, Dhaval Rajeshbhai Shah  wrote:
> From: arndbergm...@gmail.com [mailto:arndbergm...@gmail.com] On Behalf 
> Of Arnd Bergmann
> Sent: Tuesday, December 05, 2017 4:19 AM
> To: Dhaval Rajeshbhai Shah 
> Cc: gregkh ; Linux Kernel Mailing List 
> ; Michal Simek 
> ; Hyun Kwon ; Dhaval 
> Rajeshbhai Shah 
> Subject: Re: [PATCH] [linux][master][v1] misc: Add Xilinx ZYNQMP VCU 
> logicoreIP init driver
>
> On Tue, Dec 5, 2017 at 12:43 PM, Dhaval Shah  wrote:
>> Xilinx ZYNQMP VCU Init driver is based on the new LogiCoreIP design 
>> created. This driver will provide the api which can be used by the 
>> encoder and decoder driver to get the configured value.
>>
>> Signed-off-by: Dhaval Shah 
>
> Can you explain what a "VCU" is and why there is no existing subsystem for it?
>
> [Dhaval] : This VCU means Video codec unit. Here, this driver is for the 
> logicoreIP and not the VCU which is created to support the PS and PL 
> isolation and to provide the clock related information. So this is not a VCU 
> driver and but just a intermediate driver which supports logicoreIP. That's 
> why no subsystem for this.

What are PS and PL then?
[Dhaval ] :  PS is the Processing system. PL is the Programmable logic. There 
are few register in the logicoreIP which provides the isolation between this 
two in the chip. 

> If this is the "video codec unit", I'd suggest moving it to 
> drivers/media/platform and sending the patch to the 
> linux-me...@vger.kernel.org list instead.
> [Dhaval] : This is not the Video codec unit but the driver to provide the 
> support the IP created for the PS and PL isolation and clock related 
> information. That why I have placed this under the "drivers/misc/".

Is the driver useful without a codec driver then? (I assume this will be 
answered when you explain PS and PL). If not, just put it in the same directory 
as the codec.
[Dhaval ] : Yes. Driver is useful without a codec driver as well. No dependency 
on the Codec driver.

   Arnd

Re: [PATCH] usb: dwc2: Fix TxFIFOn sizes and total TxFIFO size issues

[John Youn]

On 11/30/2017 12:16 AM, Minas Harutyunyan wrote:
> In host mode reading from DPTXSIZn returning invalid value in
> dwc2_check_param_tx_fifo_sizes function.
>
> In total TxFIFO size calculations unnecessarily reducing by ep_info.
> hw->total_fifo_size can be fully allocated for FIFO's.
>
> Added num_dev_in_eps member in dwc2_hw_params structure to save number
> of IN EPs.
>
> Added g_tx_fifo_size array in dwc2_hw_params structure to store power
> on reset values of DPTXSIZn registers in forced device mode.
>
> Updated dwc2_hsotg_tx_fifo_count() function to get TxFIFO count from
> num_dev_in_eps.
>
> Updated dwc2_get_dev_hwparams() function to store DPTXFSIZn in
> g_tx_fifo_size array.
>
> dwc2_get_host/dev_hwparams() functions call moved after num_dev_in_eps
> set from hwcfg4.
>
> Modified dwc2_check_param_tx_fifo_sizes() function to check TxFIFOn
> sizes based on g_tx_fifo_size array.
>
> Removed ep_info subtraction during calculation of tx_addr_max in
> dwc2_hsotg_tx_fifo_total_depth() function. Also removed
> dwc2_hsotg_ep_info_size() function as no more need.
>
> Signed-off-by: Gevorg Sahakyan 
> Signed-off-by: Minas Harutyunyan 
> ---
>  drivers/usb/dwc2/core.h   |  4 
>  drivers/usb/dwc2/gadget.c | 42 ++
>  drivers/usb/dwc2/params.c | 29 +++--
>  3 files changed, 25 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 8367d4f985c1..686e9b5527dd 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -532,6 +532,7 @@ struct dwc2_core_params {
>   *   2 - Internal DMA
>   * @power_optimized Are power optimizations enabled?
>   * @num_dev_ep  Number of device endpoints available
> + * @num_dev_in_eps  Number of device IN endpoints available
>   * @num_dev_perio_in_ep Number of device periodic IN endpoints
>   *  available
>   * @dev_token_q_depth   Device Mode IN Token Sequence Learning Queue
> @@ -560,6 +561,7 @@ struct dwc2_core_params {
>   *   2 - 8 or 16 bits
>   * @snpsid: Value from SNPSID register
>   * @dev_ep_dirs:Direction of device endpoints (GHWCFG1)
> + * @g_tx_fifo_size[] Power-on values of TxFIFO sizes
>   */
>  struct dwc2_hw_params {
>   unsigned op_mode:3;
> @@ -581,12 +583,14 @@ struct dwc2_hw_params {
>   unsigned fs_phy_type:2;
>   unsigned i2c_enable:1;
>   unsigned num_dev_ep:4;
> + unsigned num_dev_in_eps : 4;
>   unsigned num_dev_perio_in_ep:4;
>   unsigned total_fifo_size:16;
>   unsigned power_optimized:1;
>   unsigned utmi_phy_data_width:2;
>   u32 snpsid;
>   u32 dev_ep_dirs;
> + u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
>  };
>
>  /* Size of control and EP0 buffers */
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 0d8e09ccb59c..55950baae437 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -198,55 +198,18 @@ int dwc2_hsotg_tx_fifo_count(struct dwc2_hsotg *hsotg)
>  {
>   if (hsotg->hw_params.en_multiple_tx_fifo)
>   /* In dedicated FIFO mode we need count of IN EPs */
> - return (dwc2_readl(hsotg->regs + GHWCFG4)  &
> - GHWCFG4_NUM_IN_EPS_MASK) >> GHWCFG4_NUM_IN_EPS_SHIFT;
> + return hsotg->hw_params.num_dev_in_eps;
>   else
>   /* In shared FIFO mode we need count of Periodic IN EPs */
>   return hsotg->hw_params.num_dev_perio_in_ep;
>  }
>
> -/**
> - * dwc2_hsotg_ep_info_size - return Endpoint Info Control block size in 
> DWORDs
> - */
> -static int dwc2_hsotg_ep_info_size(struct dwc2_hsotg *hsotg)
> -{
> - int val = 0;
> - int i;
> - u32 ep_dirs;
> -
> - /*
> -  * Don't need additional space for ep info control registers in
> -  * slave mode.
> -  */
> - if (!using_dma(hsotg)) {
> - dev_dbg(hsotg->dev, "Buffer DMA ep info size 0\n");
> - return 0;
> - }
> -
> - /*
> -  * Buffer DMA mode - 1 location per endpoit
> -  * Descriptor DMA mode - 4 locations per endpoint
> -  */
> - ep_dirs = hsotg->hw_params.dev_ep_dirs;
> -
> - for (i = 0; i <= hsotg->hw_params.num_dev_ep; i++) {
> - val += ep_dirs & 3 ? 1 : 2;
> - ep_dirs >>= 2;
> - }
> -
> - if (using_desc_dma(hsotg))
> - val = val * 4;
> -
> - return val;
> -}
> -
>  /**
>   * dwc2_hsotg_tx_fifo_total_depth - return total FIFO depth available for
>   * device mode TX FIFOs
>   */
>  int dwc2_hsotg_tx_fifo_total_depth(struct dwc2_hsotg *hsotg)
>  {
> - int ep_info_size;
>   int addr;
>   int tx_addr_max;
>   u32 np_tx_fifo_size;
> @@ -255,8 +218,7 @@ int dwc2_hsotg_tx_fifo_total_depth(struct dwc2_hsotg 
> *hsotg)
>   hsotg->params.g_np_tx_fifo_size);
>
>   /* Get Endpoint Info 

drivers/nvme/target/fcloop.c:1080:9: warning: 'tport' may be used uninitialized in this function

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   328b4ed93b69a6f2083d52f31a240a09e5de386a
commit: fddc9923c6d41de9fe7b1f323a3cece53e046c88 nvme-fcloop: fix port deletes 
and callbacks
date:   2 months ago
config: i386-randconfig-h1-12061225 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout fddc9923c6d41de9fe7b1f323a3cece53e046c88
# save the attached .config to linux build tree
make ARCH=i386 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/nvme/target/fcloop.c: In function 'fcloop_delete_target_port':
>> drivers/nvme/target/fcloop.c:1080:9: warning: 'tport' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 return nvmet_fc_unregister_targetport(tport->targetport);
^
   drivers/nvme/target/fcloop.c:1088:23: note: 'tport' was declared here
 struct fcloop_tport *tport;
  ^

vim +/tport +1080 drivers/nvme/target/fcloop.c

  1073  
  1074  static int
  1075  __targetport_unreg(struct fcloop_nport *nport, struct fcloop_tport 
*tport)
  1076  {
  1077  if (!tport)
  1078  return -EALREADY;
  1079  
> 1080  return nvmet_fc_unregister_targetport(tport->targetport);
  1081  }
  1082  

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


.config.gz
Description: application/gzip

[PATCH] xen-netback: Fix logging message with spurious period after newline

[Joe Perches]

Using a period after a newline causes bad output.

Signed-off-by: Joe Perches 
---
 drivers/net/xen-netback/interface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index d6dff347f896..78ebe494fef0 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -186,7 +186,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
/* Obtain the queue to be used to transmit this packet */
index = skb_get_queue_mapping(skb);
if (index >= num_queues) {
-   pr_warn_ratelimited("Invalid queue %hu for packet on interface 
%s\n.",
+   pr_warn_ratelimited("Invalid queue %hu for packet on interface 
%s\n",
index, vif->dev->name);
index %= num_queues;
}
-- 
2.15.0

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Wed, Dec 06, 2017 at 07:49:49AM +0100, Greg Kroah-Hartman wrote:
> Don't fall down the trap of running code for the sake of running code
> (i.e. like that web site that starts with a P) that doesn't actually
> test anything that actually matters.

I forgot to add:

Especially when there are already so many tests out there that _do_
matter that are not getting run on the stable kernels today.

[PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

Add the official SAMA5D2 Peripheral Touch Controller Evaluation
Kit board.

Signed-off-by: Ludovic Desroches 
---

Changes:
- v2:
  - remove memory node
  - use SPDX-License-Identifier

arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 402 ++
 2 files changed, 403 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 043d7c720d0c..ed60582eb1da 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
 dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d27_som1_ek.dtb \
+   at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
at91-tse850-3.dtb \
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
new file mode 100644
index ..89ad23a7f92d
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -0,0 +1,402 @@
+/*
+ * at91-sama5d2_ptc_ek.dts - Device Tree file for SAMA5D2 PTC EK board
+ *
+ *  Copyright (C) 2017 Microchip/Atmel,
+ *   2017 Wenyou Yang 
+ *   2017 Ludovic Desroches 
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR X11)
+ */
+/dts-v1/;
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include 
+#include 
+
+/ {
+   model = "Atmel SAMA5D2 PTC EK";
+   compatible = "atmel,sama5d2-ptc_ek", "atmel,sama5d2", "atmel,sama5";
+
+   aliases {
+   serial0 = 
+   i2c0= 
+   i2c1= 
+   i2c2= 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <2400>;
+   };
+   };
+
+   ahb {
+   usb0: gadget@30 {
+   atmel,vbus-gpio = < PIN_PA27 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usba_vbus>;
+   status = "okay";
+   };
+
+   usb1: ohci@40 {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PB12 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+   };
+
+   usb2: ehci@50 {
+   status = "okay";
+   };
+
+   ebi: ebi@1000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_nand_default>;
+   status = "okay"; /* conflicts with sdmmc1 and qspi0 */
+
+   nand_controller: nand-controller {
+   status = "okay";
+
+   nand@3 {
+   reg = <0x3 0x0 0x2>;
+   atmel,rb = <0>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   label = "atmel_nand";
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   at91bootstrap@0 {
+   label = "bootstrap";
+   reg = <0x0 0x4>;
+   };
+
+   bootloader@4 {
+   label = "bootloader";
+   reg = <0x4 0xc>;
+   };
+
+   bootloaderenv@0x10 {
+   label = "bootloader 
env";
+   reg = <0x10 
0x4>;
+   };
+
+   bootloaderenvred@0x14 {
+   label = "bootloader env 
redundant";
+  

RE: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support

[Chen, Kenji]

https://pcisig.com/sites/default/files/specification_documents/ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf
Pls also check My Intel Doc# 545845 for the bits fields description.

-Original Message-
From: Bjorn Helgaas [mailto:helg...@kernel.org] 
Sent: Wednesday, December 6, 2017 3:41 AM
To: linux-...@vger.kernel.org
Cc: Chen, Kenji ; Thierry Reding ; 
Manikanta Maddireddy ; David Daney 
; Krishna Kishore ; 
linux-kernel@vger.kernel.org; Vidya Sagar ; Julia Lawall 
; linux-te...@vger.kernel.org; Patrick Georgi 
; Rajat Jain ; Yinghai Lu 
; Stefan Reinauer ; Duncan 
Laurie 
Subject: Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support

On Sat, Dec 02, 2017 at 03:45:38PM -0600, Bjorn Helgaas wrote:
> The PCIe active link power state is L0.  ASPM defines two low-power
> states: L0s and L1.  The L1 PM Substates feature defines two 
> additional low-power states: L1.1 and L2.2.
> 
> The L1.2 state may have substantial entry/exit latency.  Downstream 
> devices can use the Latency Tolerance Reporting (LTR) feature to 
> report how much latency they can tolerate.  The L1 PM Substates 
> capability includes a programmable L1.2 threshold register.  If the 
> downstream devices can tolerate the latency indicated by the 
> threshold, L1.2 may be used.
> 
> If LTR is not enabled, the L1.2 threshold is ignored and L1.2 can be 
> used whenever it is enabled and CLKREQ# is de-asserted.  Linux 
> currently never enables LTR, but firmware may have done so.
> 
> The current L1 PM substates support in Linux sets the L1.2 threshold 
> to a fixed value (163.84us) copied from coreboot [1].  I don't know 
> where that value came from, and it is incorrect for some platforms, 
> e.g., Tegra [2].
> 
> These patches change that so we calculate the L1.2 threshold based on 
> values reported by the hardware, and we enable LTR whenever possible.
> 
> This is all just my understanding from reading the spec.  I'd be glad 
> to be corrected if I'm going wrong.
> 
> I'm particularly puzzled about the coreboot code in
> pciexp_L1_substate_commit() that sets LTR_L1.2_THRESHOLD:
> 
> + pcie_update_cfg(root, root_cap + 0x08, ~0xe3ff,
> + (1 << 21) | (1 << 23) | (1 << 30));
> 
> This is writing the L1 PM Substates Control 1 register, but the shifts 
> don't match up with any of the fields in the register, so this is an 
> awfully funny way to write the threshold.
> 
> [1] 
> https://mail.coreboot.org/pipermail/coreboot-gerrit/2015-March/021134.
> html [2] 
> https://lkml.kernel.org/r/1510492674-12786-1-git-send-email-vidyas@nvi
> dia.com
> 
> ---
> 
> Bjorn Helgaas (2):
>   PCI/ASPM: Calculate LTR_L1.2_THRESHOLD from device characteristics
>   PCI/ASPM: Enable Latency Tolerance Reporting when supported
> 
> 
>  drivers/pci/pcie/aspm.c |   71 
> +++
>  drivers/pci/probe.c |   33 ++
>  include/linux/pci.h |2 +
>  3 files changed, 82 insertions(+), 24 deletions(-)

I applied these with Vidya's Reviewed-by to pci/aspm for v4.16.

I'd still really like to hear from the coreboot folks about the rationale for 
the current coreboot code.  You folks are in a much better position to actually 
understand the hardware details.

Bjorn

Re: [PATCH v4 00/73] XArray version 4

[Dave Chinner]

On Tue, Dec 05, 2017 at 06:05:15PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> > On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > > From: Matthew Wilcox 
> > > 
> > > I looked through some notes and decided this was version 4 of the XArray.
> > > Last posted two weeks ago, this version includes a *lot* of changes.
> > > I'd like to thank Dave Chinner for his feedback, encouragement and
> > > distracting ideas for improvement, which I'll get to once this is merged.
> > 
> > BTW, you need to fix the "To:" line on your patchbombs:
> > 
> > > To: unlisted-recipients: ;, no To-header on input 
> > > <@gmail-pop.l.google.com> 
> > 
> > This bad email address getting quoted to the cc line makes some MTAs
> > very unhappy.
> 
> I know :-(  I was unhappy when I realised what I'd done.
> 
> https://marc.info/?l=git=151252237912266=2
> 
> > I'll give this a quick burn this afternoon and see what catches fire...
> 
> All of the things ... 0day gave me a 90% chance of hanging in one
> configuration.  Need to drill down on it more and find out what stupid
> thing I've done wrong this time.

Yup, Bad Stuff happened on boot:

[   24.548039] INFO: rcu_preempt detected stalls on CPUs/tasks:
[   24.548978]  1-...!: (0 ticks this GP) idle=688/0/0 softirq=143/143 fqs=0
[   24.549926]  5-...!: (0 ticks this GP) idle=db8/0/0 softirq=120/120 fqs=0
[   24.550864]  6-...!: (0 ticks this GP) idle=d58/0/0 softirq=111/111 fqs=0
[   24.551802]  8-...!: (5 GPs behind) idle=514/0/0 softirq=189/189 fqs=0
[   24.552722]  10-...!: (84 GPs behind) idle=ac0/0/0 softirq=80/80 fqs=0
[   24.553617]  11-...!: (8 GPs behind) idle=cfc/0/0 softirq=95/95 fqs=0
[   24.554496]  13-...!: (8 GPs behind) idle=b0c/0/0 softirq=82/82 fqs=0
[   24.555382]  14-...!: (38 GPs behind) idle=a7c/0/0 softirq=93/93 fqs=0
[   24.556305]  15-...!: (4 GPs behind) idle=b18/0/0 softirq=88/88 fqs=0
[   24.557190]  (detected by 9, t=5252 jiffies, g=-178, c=-179, q=994)
[   24.558051] Sending NMI from CPU 9 to CPUs 1:
[   24.558703] NMI backtrace for cpu 1 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.559654] Sending NMI from CPU 9 to CPUs 5:
[   24.559675] NMI backtrace for cpu 5 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.560654] Sending NMI from CPU 9 to CPUs 6:
[   24.560689] NMI backtrace for cpu 6 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.561655] Sending NMI from CPU 9 to CPUs 8:
[   24.561701] NMI backtrace for cpu 8 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.562654] Sending NMI from CPU 9 to CPUs 10:
[   24.562675] NMI backtrace for cpu 10 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.563653] Sending NMI from CPU 9 to CPUs 11:
[   24.563669] NMI backtrace for cpu 11 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.564653] Sending NMI from CPU 9 to CPUs 13:
[   24.564670] NMI backtrace for cpu 13 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.565652] Sending NMI from CPU 9 to CPUs 14:
[   24.565674] NMI backtrace for cpu 14 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.566652] Sending NMI from CPU 9 to CPUs 15:
[   24.59] NMI backtrace for cpu 15 skipped: idling at 
native_safe_halt+0x2/0x10
[   24.567653] rcu_preempt kthread starved for 5256 jiffies! 
g18446744073709551438 c18446744073709551437 f0x0 RCU_GP_WAIT_FQS(3) 
->state=0x402 ->7
[   24.567654] rcu_preempt I15128 9  2 0x8000
[   24.567660] Call Trace:
[   24.567679]  ? __schedule+0x289/0x880
[   24.567681]  schedule+0x2f/0x90
[   24.567682]  schedule_timeout+0x152/0x370
[   24.567686]  ? __next_timer_interrupt+0xc0/0xc0
[   24.567689]  rcu_gp_kthread+0x561/0x880
[   24.567691]  ? force_qs_rnp+0x1a0/0x1a0
[   24.567693]  kthread+0x111/0x130
[   24.567695]  ? __kthread_create_worker+0x120/0x120
[   24.567697]  ret_from_fork+0x24/0x30
[   44.064092] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kswapd0:854]
[   44.065920] CPU: 0 PID: 854 Comm: kswapd0 Not tainted 4.15.0-rc2-dgc #228
[   44.067769] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   44.070030] RIP: 0010:smp_call_function_single+0xce/0x100
[   44.071521] RSP: :c90001d2fb20 EFLAGS: 0202 ORIG_RAX: 
ff11
[   44.073592] RAX:  RBX: 88013ab515c8 RCX: c9000350bb20
[   44.075560] RDX: 0001 RSI: c90001d2fb20 RDI: c90001d2fb20
[   44.077531] RBP: c90001d2fb50 R08: 0007 R09: 0080
[   44.079483] R10: c90001d2fb78 R11: c90001d2fb30 R12: c90001d2fc10
[   44.081465] R13: ea000449fc78 R14: ea000449fc58 R15: 88013ba36c40
[   44.083434] FS:  () GS:88013fc0() 
knlGS:
[   44.085683] CS:  0010 DS:  ES:  CR0: 80050033
[   44.087276] CR2: 7f1ad65f2260 CR3: 02009001 CR4: 000606f0
[   44.089228] Call Trace:
[   44.089942]  ? 

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

[Dave Chinner]

On Tue, Dec 05, 2017 at 06:02:08PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 12:36:48PM +1100, Dave Chinner wrote:
> > > - if (radix_tree_preload(GFP_NOFS))
> > > - return -ENOMEM;
> > > -
> > >   INIT_LIST_HEAD(>list_node);
> > >   elem->key = key;
> > >  
> > > - spin_lock(>lock);
> > > - error = radix_tree_insert(>store, key, elem);
> > > - radix_tree_preload_end();
> > > - if (!error)
> > > - _xfs_mru_cache_list_insert(mru, elem);
> > > - spin_unlock(>lock);
> > > + do {
> > > + xas_lock();
> > > + xas_store(, elem);
> > > + error = xas_error();
> > > + if (!error)
> > > + _xfs_mru_cache_list_insert(mru, elem);
> > > + xas_unlock();
> > > + } while (xas_nomem(, GFP_NOFS));
> > 
> > Ok, so why does this have a retry loop on ENOMEM despite the
> > existing code handling that error? And why put such a loop in this
> > code and not any of the other XFS code that used
> > radix_tree_preload() and is arguably much more important to avoid
> > ENOMEM on insert (e.g. the inode cache)?
> 
> If we need more nodes in the tree, xas_store() will try to allocate them
> with GFP_NOWAIT | __GFP_NOWARN.  If that fails, it signals it in xas_error().
> xas_nomem() will notice that we're in an ENOMEM situation, and allocate
> a node using your preferred GFP flags (NOIO in your case).  Then we retry,
> guaranteeing forward progress. [1]
> 
> The other conversions use the normal API instead of the advanced API, so
> all of this gets hidden away.  For example, the inode cache does this:
> 
> +   curr = xa_cmpxchg(>pag_ici_xa, agino, NULL, ip, GFP_NOFS);
> 
> and xa_cmpxchg internally does:
> 
> do {
> xa_lock_irqsave(xa, flags);
> curr = xas_create();
> if (curr == old)
> xas_store(, entry);
> xa_unlock_irqrestore(xa, flags);
> } while (xas_nomem(, gfp));

Ah, OK, that's not obvious from the code changes. :/

However, it's probably overkill for XFS. In all the cases, when we
insert there should be no entry in the tree - the
radix tree insert error handling code there was simply catching
"should never happen" cases and handling it without crashing.

Now that I've looked at this, I have to say that having a return
value of NULL meaning "success" is quite counter-intuitive. That's
going to fire my "that looks so wrong" detector every time I look at
the code and notice it's erroring out on a non-null return value
that isn't a PTR_ERR case

Also, there's no need for irqsave/restore() locking contexts here as
we never access these caches from interrupt contexts. That's just
going to be extra overhead, especially on workloads that run 10^6
inodes inodes through the cache every second. That's a problem
caused by driving the locks into the XA structure and then needing
to support callers that require irq safety

> > Also, I really don't like the pattern of using xa_lock()/xa_unlock()
> > to protect access to an external structure. i.e. the mru->lock
> > context is protecting multiple fields and operations in the MRU
> > structure, not just the radix tree operations. Turning that around
> > so that a larger XFS structure and algorithm is now protected by an
> > opaque internal lock from generic storage structure the forms part
> > of the larger structure seems like a bad design pattern to me...
> 
> It's the design pattern I've always intended to use.  Naturally, the
> xfs radix trees weren't my initial target; it was the page cache, and
> the page cache does the same thing; uses the tree_lock to protect both
> the radix tree and several other fields in that same data structure.
> 
> I'm open to argument on this though ... particularly if you have a better
> design pattern in mind!

I don't mind structures having internal locking - I have a problem
with leaking them into contexts outside the structure they protect.
That way lies madness - you can't change the internal locking in
future because of external dependencies, and the moment you need
something different externally we've got to go back to an external
lock anyway.

This is demonstrated by the way you converted the XFS dquot tree -
you didn't replace the dquot tree lock with the internal xa_lock
because it's a mutex and we have to sleep holding it. IOWs, we've
added another layer of locking here, not simplified the code.

What I really see here is that  we have inconsistent locking
patterns w.r.t. XA stores inside XFS - some have an external mutex
to cover a wider scope, some use xa_lock/xa_unlock to span multiple
operations, some directly access the internal xa lock via direct
spin_lock/unlock(...xa_lock) calls and non-locking XA call variants.
In some places you remove explicit rcu_read_lock() calls because the
internal xa_lock implies RCU, but in other places we still need them
because we have to protect the objects the tree points to, not just
the tree

IOWs, there's no 

[PATCH v4] mmap.2: MAP_FIXED updated documentation

[john . hubbard]

From: John Hubbard 

Previously, MAP_FIXED was "discouraged", due to portability
issues with the fixed address. In fact, there are other, more
serious issues. Also, alignment requirements were a bit vague.
So:

-- Expand the documentation to discuss the hazards in
   enough detail to allow avoiding them.

-- Mention the upcoming MAP_FIXED_SAFE flag.

-- Enhance the alignment requirement slightly.

Some of the wording is lifted from Matthew Wilcox's review
(the "Portability issues" section). The alignment requirements
section uses Cyril Hrubis' wording, with light editing applied.

Suggested-by: Matthew Wilcox 
Suggested-by: Cyril Hrubis 
Signed-off-by: John Hubbard 
---

Changes since v3:

-- Removed the "how to use this safely" part, and
   the SHMLBA part, both as a result of Michal Hocko's
   review.

-- A few tiny wording fixes, at the not-quite-typo level.

Changes since v2:

-- Fixed up the "how to use safely" example, in response
   to Mike Rapoport's review.

-- Changed the alignment requirement from system page
   size, to SHMLBA. This was inspired by (but not yet
   recommended by) Cyril Hrubis' review.

-- Formatting: underlined /proc//maps 

Changes since v1:

-- Covered topics recommended by Matthew Wilcox
   and Jann Horn, in their recent review: the hazards
   of overwriting pre-exising mappings, and some notes
   about how to use MAP_FIXED safely.

-- Rewrote the commit description accordingly.

 man2/mmap.2 | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/man2/mmap.2 b/man2/mmap.2
index 385f3bfd5..56b05cff1 100644
--- a/man2/mmap.2
+++ b/man2/mmap.2
@@ -212,8 +212,9 @@ Don't interpret
 .I addr
 as a hint: place the mapping at exactly that address.
 .I addr
-must be a multiple of the page size.
-If the memory region specified by
+must be suitably aligned: for most architectures a multiple of page
+size is sufficient; however, some architectures may impose additional
+restrictions. If the memory region specified by
 .I addr
 and
 .I len
@@ -222,8 +223,39 @@ part of the existing mapping(s) will be discarded.
 If the specified address cannot be used,
 .BR mmap ()
 will fail.
-Because requiring a fixed address for a mapping is less portable,
-the use of this option is discouraged.
+.IP
+This option is extremely hazardous (when used on its own) and moderately
+non-portable.
+.IP
+Portability issues: a process's memory map may change significantly from one
+run to the next, depending on library versions, kernel versions and random
+numbers.
+.IP
+Hazards: this option forcibly removes pre-existing mappings, making it easy
+for a multi-threaded process to corrupt its own address space.
+.IP
+For example, thread A looks through
+.I /proc//maps
+and locates an available
+address range, while thread B simultaneously acquires part or all of that same
+address range. Thread A then calls mmap(MAP_FIXED), effectively overwriting
+the mapping that thread B created.
+.IP
+Thread B need not create a mapping directly; simply making a library call
+that, internally, uses
+.I dlopen(3)
+to load some other shared library, will
+suffice. The dlopen(3) call will map the library into the process's address
+space. Furthermore, almost any library call may be implemented using this
+technique.
+Examples include brk(2), malloc(3), pthread_create(3), and the PAM libraries
+(http://www.linux-pam.org).
+.IP
+Newer kernels
+(Linux 4.16 and later) have a
+.B MAP_FIXED_SAFE
+option that avoids the corruption problem; if available, MAP_FIXED_SAFE
+should be preferred over MAP_FIXED.
 .TP
 .B MAP_GROWSDOWN
 This flag is used for stacks.
-- 
2.15.1

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

[Michael Ellerman]

Michal Hocko  writes:

> On Wed 29-11-17 14:25:36, Kees Cook wrote:
>> On Wed, Nov 29, 2017 at 6:42 AM, Michal Hocko  wrote:
>> > The first patch introduced MAP_FIXED_SAFE which enforces the given
>> > address but unlike MAP_FIXED it fails with ENOMEM if the given range
>> > conflicts with an existing one. The flag is introduced as a completely
>> 
>> I still think this name should be better. "SAFE" doesn't say what it's
>> safe from...

Yes exactly.

> It is safe in a sense it doesn't perform any address space dangerous
> operations. mmap is _inherently_ about the address space so the context
> should be kind of clear.

So now you have to define what "dangerous" means.

>> MAP_FIXED_UNIQUE
>> MAP_FIXED_ONCE
>> MAP_FIXED_FRESH
>
> Well, I can open a poll for the best name, but none of those you are
> proposing sound much better to me. Yeah, naming sucks...

I think Kees and I both previously suggested MAP_NO_CLOBBER for the
modifier.

So the obvious option for this would be MAP_FIXED_NO_CLOBBER.

Which is a bit longer sure, but says more or less exactly what it does.

cheers

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

[Michael Ellerman]

Cyril Hrubis  writes:

> Hi!
>> > MAP_FIXED_UNIQUE
>> > MAP_FIXED_ONCE
>> > MAP_FIXED_FRESH
>> 
>> Well, I can open a poll for the best name, but none of those you are
>> proposing sound much better to me. Yeah, naming sucks...
>
> Given that MAP_FIXED replaces the previous mapping MAP_FIXED_NOREPLACE
> would probably be a best fit.

Yeah that could work.

I prefer "no clobber" as I just suggested, because the existing
MAP_FIXED doesn't politely "replace" a mapping, it destroys the current
one - which you or another thread may be using - and clobbers it with
the new one.

cheers

Re: [PATCH] driver-core: platform: Avoid to return IRQ 0 in platform_get_irq()

[Arvind Yadav]

Hi Dmitry,


On Tuesday 05 December 2017 11:50 PM, Dmitry Torokhov wrote:

On Tue, Dec 05, 2017 at 11:41:52PM +0530, Arvind Yadav wrote:

Function platform_get_irq() can return 0. Which means NO_IRQ.
So this change will not allow to return 0.

This change is help to use platform_get_irq() without this,

val = platform_get_irq();
if (val <= 0)
ret = val ? val : -ENODEV;

Signed-off-by: Arvind Yadav 

You need to audit the drivers and make sure you are not breaking them
with this. I believe at least i2c designware controller on certain
boards has DEFINE_RES_IRQ(0) which will be broken by this patch.

Yes, you are right. Few driver is using  DEFINE_RES_IRQ(0).
Example:
drivers/mfd/intel-lpss.c
static const struct resource intel_lpss_dev_resources[] = {
DEFINE_RES_MEM_NAMED(LPSS_DEV_OFFSET, LPSS_DEV_SIZE, "lpss_dev"),
DEFINE_RES_MEM_NAMED(LPSS_PRIV_OFFSET, LPSS_PRIV_SIZE, 
"lpss_priv"),

DEFINE_RES_IRQ(0),
};
There's a bunch of platforms in the kernel that still use IRQ0. They can 
suffer because

of this change. I should have mark this patch for testing.



---
  drivers/base/platform.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c203fb9..7b3079c 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -127,7 +127,7 @@ int platform_get_irq(struct platform_device *dev, unsigned 
int num)
irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS);
}
  
-	return r ? r->start : -ENXIO;

+   return r && r->start ? r->start : -ENXIO;
  #endif
  }
  EXPORT_SYMBOL_GPL(platform_get_irq);
--
2.7.4


Thanks.


Thanks,

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Greg KH]

On Tue, Dec 05, 2017 at 03:01:42PM -0800, Laura Abbott wrote:
> On 12/02/2017 07:53 AM, Greg KH wrote:
> > > This is one of the item in the TODO list before been able to unstage ION
> > > which is my real need.
> > Why does it matter where in the tree this code is?  Don't go adding new
> > things to it that are not needed.  Who needs this?  What userspace code
> > wants this type of multiple ion devices?
> > 
> 
> Requirements came in from several places to split /dev/ion -> /dev/ion0
> and /dev/ion1 so that security policy (i.e. selinux) could be used to
> protect access to certain heaps. I wanted the ABI to be settled before
> trying to move out of staging, hence the line in the TODO list about
> doing the split.

Ok, but we should have some way of testing it works, right?  :)

[PATCH] usb: xhci: fix TDS for MTK xHCI1.1

[Chunfeng Yun]

For MTK's xHCI 1.0 or latter, TD size is the number of max
packet sized packets remaining in the TD, not including
this TRB (following spec).

For MTK's xHCI 0.96 and older, TD size is the number of max
packet sized packets remaining in the TD, including this TRB
(not following spec).

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-ring.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index c239c68..0619869 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3108,7 +3108,7 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int 
transferred,
 {
u32 maxp, total_packet_count;
 
-   /* MTK xHCI is mostly 0.97 but contains some features from 1.0 */
+   /* MTK xHCI 0.96 contains some features from 1.0 */
if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
return ((td_total_len - transferred) >> 10);
 
@@ -3117,8 +3117,8 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int 
transferred,
trb_buff_len == td_total_len)
return 0;
 
-   /* for MTK xHCI, TD size doesn't include this TRB */
-   if (xhci->quirks & XHCI_MTK_HOST)
+   /* for MTK xHCI 0.96, TD size include this TRB, but not in 1.x */
+   if ((xhci->quirks & XHCI_MTK_HOST) && (xhci->hci_version < 0x100))
trb_buff_len = 0;
 
maxp = usb_endpoint_maxp(>ep->desc);
-- 
1.9.1

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

[Matthew Wilcox]

On Tue, Dec 05, 2017 at 08:54:35PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 03:51:44PM +1100, Michael Ellerman wrote:
> > Cyril Hrubis  writes:
> > 
> > > Hi!
> > >> > MAP_FIXED_UNIQUE
> > >> > MAP_FIXED_ONCE
> > >> > MAP_FIXED_FRESH
> > >> 
> > >> Well, I can open a poll for the best name, but none of those you are
> > >> proposing sound much better to me. Yeah, naming sucks...
> > >
> > > Given that MAP_FIXED replaces the previous mapping MAP_FIXED_NOREPLACE
> > > would probably be a best fit.
> > 
> > Yeah that could work.
> > 
> > I prefer "no clobber" as I just suggested, because the existing
> > MAP_FIXED doesn't politely "replace" a mapping, it destroys the current
> > one - which you or another thread may be using - and clobbers it with
> > the new one.
> 
> It's longer than MAP_FIXED_WEAK :-P
> 
> You'd have to be pretty darn strong to clobber an existing mapping.

I think we're thinking about this all wrong.  We shouldn't document it as
"This is a variant of MAP_FIXED".  We should document it as "Here's an
alternative to MAP_FIXED".

So, just like we currently say "exactly one of MAP_SHARED or MAP_PRIVATE",
we could add a new paragraph saying "at most one of MAP_FIXED or
MAP_REQUIRED" and "any of the following values".

Now, we should implement MAP_REQUIRED as having each architecture
define _MAP_NOT_A_HINT, and then #define MAP_REQUIRED (MAP_FIXED |
_MAP_NOT_A_HINT), but that's not information to confuse users with.

Also, that lets us add a third option at some point that is Yet Another
Way to interpret the 'addr' argument, by having MAP_FIXED clear and
_MAP_NOT_A_HINT set.

I'm not set on MAP_REQUIRED.  I came up with some awful names
(MAP_TODDLER, MAP_TANTRUM, MAP_ULTIMATUM, MAP_BOSS, MAP_PROGRAM_MANAGER,
etc).  But I think we should drop FIXED from the middle of the name.

[PATCH] Input: include "linux/gpio/consumer.h" header file.

[Anthony Kim]

An error occurred during compile because there is no header file
at x86 configure.

Signed-off-by: Anthony Kim 
---
 drivers/input/touchscreen/hideep.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/touchscreen/hideep.c 
b/drivers/input/touchscreen/hideep.c
index fc080a7..037da00 100644
--- a/drivers/input/touchscreen/hideep.c
+++ b/drivers/input/touchscreen/hideep.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.4

Re: [PATCH v4 00/73] XArray version 4

[Dave Chinner]

On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> I looked through some notes and decided this was version 4 of the XArray.
> Last posted two weeks ago, this version includes a *lot* of changes.
> I'd like to thank Dave Chinner for his feedback, encouragement and
> distracting ideas for improvement, which I'll get to once this is merged.

BTW, you need to fix the "To:" line on your patchbombs:

> To: unlisted-recipients: ;, no To-header on input <@gmail-pop.l.google.com> 

This bad email address getting quoted to the cc line makes some MTAs
very unhappy.

> 
> Highlights:
>  - Over 2000 words of documentation in patch 8!  And lots more kernel-doc.
>  - The page cache is now fully converted to the XArray.
>  - Many more tests in the test-suite.
> 
> This patch set is not for applying.  0day is still reporting problems,
> and I'd feel bad for eating someone's data.  These patches apply on top
> of a set of prepatory patches which just aren't interesting.  If you
> want to see the patches applied to a tree, I suggest pulling my git tree:
> http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/xarray-2017-12-04
> I also left out the idr_preload removals.  They're still in the git tree,
> but I'm not looking for feedback on them.

I'll give this a quick burn this afternoon and see what catches fire...

Cheers,

Dave.

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

Re: [LKP] [lkp-robot] [fs/locks] 52306e882f: stress-ng.lockofd.ops_per_sec -11% regression

[Lu, Aaron]

On Tue, 2017-12-05 at 06:01 -0500, Jeff Layton wrote:
> On Tue, 2017-12-05 at 13:57 +0800, Aaron Lu wrote:
> > On Wed, Nov 08, 2017 at 03:22:33PM +0800, Aaron Lu wrote:
> > > On Thu, Sep 28, 2017 at 04:02:23PM +0800, kernel test robot wrote:
> > > > 
> > > > Greeting,
> > > > 
> > > > FYI, we noticed a -11% regression of stress-ng.lockofd.ops_per_sec due 
> > > > to commit:
> > > > 
> > > > 
> > > > commit: 52306e882f77d3fd73f91435c41373d634acc5d2 ("fs/locks: Use 
> > > > allocation rather than the stack in fcntl_getlk()")
> > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > > 
> > > It's been a while, I wonder what do you think of this regression?
> > > 
> > > The test stresses byte-range locks AFAICS and since the commit uses
> > > dynamic allocation instead of stack for the 'struct file_lock', it sounds
> > > natural the performance regressed for this test.
> > > 
> > > Now the question is, do we care about the performance regression here?
> > 
> > Appreciated it if you can share your opinion on this, thanks.
> > 
> > Regards,
> > Aaron
> >  
> 
> Sorry I missed your earlier mail about this. My feeling is to not worry

Never mind :)

> about it. struct file_lock is rather large, so putting it on the stack
> was always a bit dangerous, and F_GETLK is a rather uncommon operation
> anyway.
> 
> That said, if there are real-world workloads that have regressed because
> of this patch, I'm definitely open to backing it out.
> 
> Does anyone else have opinions on the matter?

Your comments makes sense to me, thanks for the reply.

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

[Dave Chinner]

On Tue, Dec 05, 2017 at 04:41:58PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> This eliminates a call to radix_tree_preload().

.

>  void
> @@ -431,24 +424,24 @@ xfs_mru_cache_insert(
>   unsigned long   key,
>   struct xfs_mru_cache_elem *elem)
>  {
> + XA_STATE(xas, >store, key);
>   int error;
>  
>   ASSERT(mru && mru->lists);
>   if (!mru || !mru->lists)
>   return -EINVAL;
>  
> - if (radix_tree_preload(GFP_NOFS))
> - return -ENOMEM;
> -
>   INIT_LIST_HEAD(>list_node);
>   elem->key = key;
>  
> - spin_lock(>lock);
> - error = radix_tree_insert(>store, key, elem);
> - radix_tree_preload_end();
> - if (!error)
> - _xfs_mru_cache_list_insert(mru, elem);
> - spin_unlock(>lock);
> + do {
> + xas_lock();
> + xas_store(, elem);
> + error = xas_error();
> + if (!error)
> + _xfs_mru_cache_list_insert(mru, elem);
> + xas_unlock();
> + } while (xas_nomem(, GFP_NOFS));

Ok, so why does this have a retry loop on ENOMEM despite the
existing code handling that error? And why put such a loop in this
code and not any of the other XFS code that used
radix_tree_preload() and is arguably much more important to avoid
ENOMEM on insert (e.g. the inode cache)?

Also, I really don't like the pattern of using xa_lock()/xa_unlock()
to protect access to an external structure. i.e. the mru->lock
context is protecting multiple fields and operations in the MRU
structure, not just the radix tree operations. Turning that around
so that a larger XFS structure and algorithm is now protected by an
opaque internal lock from generic storage structure the forms part
of the larger structure seems like a bad design pattern to me...

Cheers,

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

RE: [PATCH v4 00/73] XArray version 4

[Matthew Wilcox]

Huh, you've caught a couple of problems that 0day hasn't sent me yet.  Try 
turning on DAX or TRANSPARENT_HUGEPAGE.  Thanks!

> -Original Message-
> From: Dave Chinner [mailto:da...@fromorbit.com]
> Sent: Tuesday, December 5, 2017 8:51 PM
> To: Matthew Wilcox 
> Cc: Matthew Wilcox ; Ross Zwisler
> ; Jens Axboe ; Rehas
> Sachdeva ; linux...@kvack.org; linux-
> fsde...@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net; linux-
> ni...@vger.kernel.org; linux-bt...@vger.kernel.org; linux-...@vger.kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v4 00/73] XArray version 4
> 
> On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> > On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > > From: Matthew Wilcox 
> > >
> > > I looked through some notes and decided this was version 4 of the XArray.
> > > Last posted two weeks ago, this version includes a *lot* of changes.
> > > I'd like to thank Dave Chinner for his feedback, encouragement and
> > > distracting ideas for improvement, which I'll get to once this is merged.
> >
> > BTW, you need to fix the "To:" line on your patchbombs:
> >
> > > To: unlisted-recipients: ;, no To-header on input <@gmail-
> pop.l.google.com>
> >
> > This bad email address getting quoted to the cc line makes some MTAs
> > very unhappy.
> >
> > >
> > > Highlights:
> > >  - Over 2000 words of documentation in patch 8!  And lots more kernel-doc.
> > >  - The page cache is now fully converted to the XArray.
> > >  - Many more tests in the test-suite.
> > >
> > > This patch set is not for applying.  0day is still reporting problems,
> > > and I'd feel bad for eating someone's data.  These patches apply on top
> > > of a set of prepatory patches which just aren't interesting.  If you
> > > want to see the patches applied to a tree, I suggest pulling my git tree:
> > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.infrade
> ad.org%2Fusers%2Fwilly%2Flinux-
> dax.git%2Fshortlog%2Frefs%2Fheads%2Fxarray-2017-12-
> 04=02%7C01%7Cmawilcox%40microsoft.com%7Ca3e721545f8b4b9dff1
> 608d53c4bd42f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
> 81218740341312=IXNZXXLTf964OQ0eLDpJt2LCv%2BGGWFW%2FQd4Kc
> KYu6zo%3D=0
> > > I also left out the idr_preload removals.  They're still in the git tree,
> > > but I'm not looking for feedback on them.
> >
> > I'll give this a quick burn this afternoon and see what catches fire...
> 
> Build warnings/errors:
> 
> .
> lib/radix-tree.c:700:13: warning: ¿radix_tree_free_nodes¿ defined but not used
> [-Wunused-function]
>  static void radix_tree_free_nodes(struct radix_tree_node *node)
> .
> lib/xarray.c: In function ¿xas_max¿:
> lib/xarray.c:291:16: warning: unused variable ¿mask¿
> [-Wunused-variable]
>   unsigned long mask, max = xas->xa_index;
>   ^~~~
> ..
> fs/dax.c: In function ¿grab_mapping_entry¿:
> fs/dax.c:305:2: error: implicit declaration of function ¿xas_set_order¿; did 
> you
> mean ¿xas_set_err¿?  [-Werror=implicit-function-declaration]
>   xas_set_order(, index, size_flag ? PMD_ORDER : 0);
> ^
> scripts/Makefile.build:310: recipe for target 'fs/dax.o' failed
> make[1]: *** [fs/dax.o] Error 1
> 
> -Dave.
> --
> Dave Chinner
> da...@fromorbit.com

Re: [PATCH v4 00/73] XArray version 4

[Dave Chinner]

On Wed, Dec 06, 2017 at 01:53:41AM +, Matthew Wilcox wrote:
> Huh, you've caught a couple of problems that 0day hasn't sent me yet.  Try 
> turning on DAX or TRANSPARENT_HUGEPAGE.  Thanks!

Dax is turned on, CONFIG_TRANSPARENT_HUGEPAGE is not.

Looks like nothing is setting CONFIG_RADIX_TREE_MULTIORDER, which is
what xas_set_order() is hidden under.

Ah, CONFIG_ZONE_DEVICE turns it on, not CONFIG_DAX/CONFIG_FS_DAX.

H.  That seems wrong if it's used in fs/dax.c...

$ grep DAX .config
CONFIG_DAX=y
CONFIG_FS_DAX=y
$ grep ZONE_DEVICE .config
CONFIG_ARCH_HAS_ZONE_DEVICE=y
$

So I have DAX enabled, but not ZONE_DEVICE? Shouldn't DAX be
selecting ZONE_DEVICE, not relying on a user to select both of them
so that stuff works properly? Hmmm - there's no menu option to turn
on zone device, so it's selected by something else?  Oh, HMM turns
on ZONE device. But that is "default y", so should be turned on. But
it's not?  And there's no obvious HMM menu config option, either

What a godawful mess Kconfig has turned into.

I'm just going to enable TRANSPARENT_HUGEPAGE - madness awaits me if
I follow the other path down the rat hole

Ok, it build this time.

-Dave.

> 
> > -Original Message-
> > From: Dave Chinner [mailto:da...@fromorbit.com]
> > Sent: Tuesday, December 5, 2017 8:51 PM
> > To: Matthew Wilcox 
> > Cc: Matthew Wilcox ; Ross Zwisler
> > ; Jens Axboe ; Rehas
> > Sachdeva ; linux...@kvack.org; linux-
> > fsde...@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net; linux-
> > ni...@vger.kernel.org; linux-bt...@vger.kernel.org; 
> > linux-...@vger.kernel.org;
> > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v4 00/73] XArray version 4
> > 
> > On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> > > On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > > > From: Matthew Wilcox 
> > > >
> > > > I looked through some notes and decided this was version 4 of the 
> > > > XArray.
> > > > Last posted two weeks ago, this version includes a *lot* of changes.
> > > > I'd like to thank Dave Chinner for his feedback, encouragement and
> > > > distracting ideas for improvement, which I'll get to once this is 
> > > > merged.
> > >
> > > BTW, you need to fix the "To:" line on your patchbombs:
> > >
> > > > To: unlisted-recipients: ;, no To-header on input <@gmail-
> > pop.l.google.com>
> > >
> > > This bad email address getting quoted to the cc line makes some MTAs
> > > very unhappy.
> > >
> > > >
> > > > Highlights:
> > > >  - Over 2000 words of documentation in patch 8!  And lots more 
> > > > kernel-doc.
> > > >  - The page cache is now fully converted to the XArray.
> > > >  - Many more tests in the test-suite.
> > > >
> > > > This patch set is not for applying.  0day is still reporting problems,
> > > > and I'd feel bad for eating someone's data.  These patches apply on top
> > > > of a set of prepatory patches which just aren't interesting.  If you
> > > > want to see the patches applied to a tree, I suggest pulling my git 
> > > > tree:
> > > >
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.infrade
> > ad.org%2Fusers%2Fwilly%2Flinux-
> > dax.git%2Fshortlog%2Frefs%2Fheads%2Fxarray-2017-12-
> > 04=02%7C01%7Cmawilcox%40microsoft.com%7Ca3e721545f8b4b9dff1
> > 608d53c4bd42f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
> > 81218740341312=IXNZXXLTf964OQ0eLDpJt2LCv%2BGGWFW%2FQd4Kc
> > KYu6zo%3D=0
> > > > I also left out the idr_preload removals.  They're still in the git 
> > > > tree,
> > > > but I'm not looking for feedback on them.
> > >
> > > I'll give this a quick burn this afternoon and see what catches fire...
> > 
> > Build warnings/errors:
> > 
> > .
> > lib/radix-tree.c:700:13: warning: ¿radix_tree_free_nodes¿ defined but not 
> > used
> > [-Wunused-function]
> >  static void radix_tree_free_nodes(struct radix_tree_node *node)
> > .
> > lib/xarray.c: In function ¿xas_max¿:
> > lib/xarray.c:291:16: warning: unused variable ¿mask¿
> > [-Wunused-variable]
> >   unsigned long mask, max = xas->xa_index;
> >   ^~~~
> > ..
> > fs/dax.c: In function ¿grab_mapping_entry¿:
> > fs/dax.c:305:2: error: implicit declaration of function ¿xas_set_order¿; 
> > did you
> > mean ¿xas_set_err¿?  [-Werror=implicit-function-declaration]
> >   xas_set_order(, index, size_flag ? PMD_ORDER : 0);
> > ^
> > scripts/Makefile.build:310: recipe for target 'fs/dax.o' failed
> > make[1]: *** [fs/dax.o] Error 1
> > 
> > -Dave.
> > --
> > Dave Chinner
> > da...@fromorbit.com

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

RE: [PATCHv2 0/2] mtd: m25p80: restore the addressing mode when stop using the flash

[Z.q. Hou]

Hi Cyrille,

Thanks a lot for your comments!

> -Original Message-
> From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
> Sent: 2017年12月6日 4:41
> To: Z.q. Hou ; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org; computersforpe...@gmail.com;
> dw...@infradead.org; boris.brezil...@free-electrons.com;
> marek.va...@gmail.com; rich...@nod.at
> Subject: Re: [PATCHv2 0/2] mtd: m25p80: restore the addressing mode when
> stop using the flash
> 
> Hi Hou,
> 
> Le 05/12/2017 à 06:33, Zhiqiang Hou a écrit :
> > From: Hou Zhiqiang 
> >
> > To be compatible with legacy device, reset the addressing mode to the
> > default mode. Such as Freescale eSPI boot, it copies the images from
> > SPI flash without firing a reset signal previously, so the reboot
> > command will fail without reseting the addressing mode of SPI flash.
> >
> 
> You should put this in one of the commit messages so it explains which issue 
> is
> fixed by your patches.

Agree with you, and will do it in next version.

> 
> Otherwise, your series looks good to me :)
> 
> Best regards,
> 
> Cyrille
> 
> > Hou Zhiqiang (2):
> >   mtd: spi-nor: add an API to restore the status of SPI flash chip
> >   mtd: m25p80: restore the status of SPI flash when stop using it
> >
> >  Documentation/mtd/spi-nor.txt |  3 +++  drivers/mtd/devices/m25p80.c
> > |  9 +  drivers/mtd/spi-nor/spi-nor.c | 10 ++
> >  include/linux/mtd/spi-nor.h   |  6 ++
> >  4 files changed, 28 insertions(+)
> >

Thanks,
Zhiqiang

Re: [PATCH v4 00/73] XArray version 4

[Matthew Wilcox]

On Wed, Dec 06, 2017 at 01:17:52PM +1100, Dave Chinner wrote:
> On Wed, Dec 06, 2017 at 01:53:41AM +, Matthew Wilcox wrote:
> > Huh, you've caught a couple of problems that 0day hasn't sent me yet.  Try 
> > turning on DAX or TRANSPARENT_HUGEPAGE.  Thanks!
> 
> Dax is turned on, CONFIG_TRANSPARENT_HUGEPAGE is not.
> 
> Looks like nothing is setting CONFIG_RADIX_TREE_MULTIORDER, which is
> what xas_set_order() is hidden under.
> 
> Ah, CONFIG_ZONE_DEVICE turns it on, not CONFIG_DAX/CONFIG_FS_DAX.
> 
> H.  That seems wrong if it's used in fs/dax.c...

Yes, it's my mistake for not making xas_set_order available in the
!MULTIORDER case.  I'm working on a fix now.

> What a godawful mess Kconfig has turned into.

I'm not going to argue with that ...

Re: add_wait_queue() (unintentional?) behavior change in v4.13

[Fubo Chen]

On Wed, Nov 29, 2017 at 4:58 PM, Omar Sandoval  wrote:
> diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
> index 98feab7933c7..929ecb7d6b78 100644
> --- a/kernel/sched/wait.c
> +++ b/kernel/sched/wait.c
> @@ -27,7 +27,7 @@ void add_wait_queue(struct wait_queue_head *wq_head, struct 
> wait_queue_entry *wq
>
> wq_entry->flags &= ~WQ_FLAG_EXCLUSIVE;
> spin_lock_irqsave(_head->lock, flags);
> -   __add_wait_queue_entry_tail(wq_head, wq_entry);
> +   __add_wait_queue(wq_head, wq_entry);
> spin_unlock_irqrestore(_head->lock, flags);
>  }
>  EXPORT_SYMBOL(add_wait_queue);

Reviewed-by: Fubo Chen 

Re: [PATCH] writeback: fix comment in __mark_inode_dirty

[wanglong]

Cc: Jens Axboe

> On 5 Dec 2017, at 11:48 PM, t...@kernel.org wrote:
> 
> Hello, Wang.
> 
> On Tue, Dec 05, 2017 at 12:52:54AM -0500, Wang Long wrote:
>> Signed-off-by: Wang Long 
>> ---
>> fs/fs-writeback.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
>> index cea4836..8d477cf 100644
>> --- a/fs/fs-writeback.c
>> +++ b/fs/fs-writeback.c
>> @@ -2209,7 +2209,7 @@ void __mark_inode_dirty(struct inode *inode, int flags)
>>  trace_writeback_dirty_inode_enqueue(inode);
>> 
>>  /*
>> - * If this is the first dirty inode for this bdi,
>> + * If this is the first dirty inode for this wb,
> 
> Acked-by: Tejun Heo 
> 
> This probably should go through the block tree tho.  Please cc Jens
> Axboe.
> 
> Thanks.
> 
> -- 
> tejun

Re: [PATCH v3 0/2] of: overlay: Fix of_overlay_apply() error path

[Frank Rowand]

On 12/05/17 10:27, Geert Uytterhoeven wrote:
>   Hi Pantelis, Rob, Frank,
> 
> Here's a replacement for commit bd80e2555c5c9d45 ("of: overlay: Fix
> cleanup order in of_overlay_apply()"), which was applied by Rob, and
> dropped later.
> 
> The first patch fixes the memory leak reported by Colin.
> The second patch is a replacement for the bad dropped commit, and
> depends on the first patch for proper cleanup.
> 
> All OF unittests pass.
> 
> Thanks!
> 
> Geert Uytterhoeven (2):
>   of: overlay: Fix memory leak in of_overlay_apply() error path
>   of: overlay: Fix (un)locking in of_overlay_apply()
> 
>  drivers/of/overlay.c | 31 +--
>  1 file changed, 13 insertions(+), 18 deletions(-)
> 

Thank you, the code is much improved by these patches.

Reviewed-by: Frank Rowand 

[PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

[Zhiqiang Hou]

From: Hou Zhiqiang 

Restore the status to be compatible with legacy devices.
Take Freescale eSPI boot for example, it copies (in 3 Byte
addressing mode) the RCW and bootloader images from SPI flash
without firing a reset signal previously, so the reboot command
will fail without reseting the addressing mode of SPI flash.
This patch implement .shutdown function to restore the status
in reboot process, and add the same operation to the .remove
function.

Signed-off-by: Hou Zhiqiang 
---
V3:
 - Modified the commit to make this patch specific.

 drivers/mtd/devices/m25p80.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index dbe6a1de2bb8..a4e18f6aaa33 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -307,10 +307,18 @@ static int m25p_remove(struct spi_device *spi)
 {
struct m25p *flash = spi_get_drvdata(spi);
 
+   spi_nor_restore(>spi_nor);
+
/* Clean up MTD stuff. */
return mtd_device_unregister(>spi_nor.mtd);
 }
 
+static void m25p_shutdown(struct spi_device *spi)
+{
+   struct m25p *flash = spi_get_drvdata(spi);
+
+   spi_nor_restore(>spi_nor);
+}
 /*
  * Do NOT add to this array without reading the following:
  *
@@ -386,6 +394,7 @@ static struct spi_driver m25p80_driver = {
.id_table   = m25p_ids,
.probe  = m25p_probe,
.remove = m25p_remove,
+   .shutdown   = m25p_shutdown,
 
/* REVISIT: many of these chips have deep power-down modes, which
 * should clearly be entered on suspend() to minimize power use.
-- 
2.14.1

[PATCHv3 0/2] mtd: m25p80: restore the addressing mode when exiting

[Zhiqiang Hou]

From: Hou Zhiqiang 

Restore the status to be compatible with legacy devices.
Take Freescale eSPI boot for example, it copies (in 3 Byte
addressing mode) the RCW and bootloader images from SPI flash
without firing a reset signal previously, so the reboot command
will fail without reseting the addressing mode of SPI flash.

Hou Zhiqiang (2):
  mtd: spi-nor: add an API to restore the status of SPI flash chip
  mtd: m25p80: restore the status of SPI flash when exiting

 Documentation/mtd/spi-nor.txt |  3 +++
 drivers/mtd/devices/m25p80.c  |  9 +
 drivers/mtd/spi-nor/spi-nor.c | 10 ++
 include/linux/mtd/spi-nor.h   |  6 ++
 4 files changed, 28 insertions(+)

-- 
2.14.1

[PATCHv3 1/2] mtd: spi-nor: add an API to restore the status of SPI flash chip

[Zhiqiang Hou]

From: Hou Zhiqiang 

Add this API to restore the status of SPI flash chip to the default
such as addressing mode, whenever detach the driver from device or
reboot the system.

Signed-off-by: Hou Zhiqiang 
---
V3:
 - no change.

 Documentation/mtd/spi-nor.txt |  3 +++
 drivers/mtd/spi-nor/spi-nor.c | 10 ++
 include/linux/mtd/spi-nor.h   |  6 ++
 3 files changed, 19 insertions(+)

diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt
index 548d6306ebca..da1fbff5a24c 100644
--- a/Documentation/mtd/spi-nor.txt
+++ b/Documentation/mtd/spi-nor.txt
@@ -60,3 +60,6 @@ The main API is spi_nor_scan(). Before you call the hook, a 
driver should
 initialize the necessary fields for spi_nor{}. Please see
 drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c
 when you want to write a new driver for a SPI NOR controller.
+Another API is spi_nor_restore(), this is used to restore the status of SPI
+flash chip such as addressing mode. Call it whenever detach the driver from
+device or reboot the system.
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index bc266f70a15b..4a925378d434 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2713,6 +2713,16 @@ static void spi_nor_resume(struct mtd_info *mtd)
dev_err(dev, "resume() failed\n");
 }
 
+void spi_nor_restore(struct spi_nor *nor)
+{
+   /* restore the addressing mode */
+   if ((nor->addr_width == 4) &&
+   (JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
+   !(nor->info->flags & SPI_NOR_4B_OPCODES))
+   set_4byte(nor, nor->info, 0);
+}
+EXPORT_SYMBOL_GPL(spi_nor_restore);
+
 int spi_nor_scan(struct spi_nor *nor, const char *name,
 const struct spi_nor_hwcaps *hwcaps)
 {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index d0c66a0975cf..0a182c3d0884 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -399,4 +399,10 @@ struct spi_nor_hwcaps {
 int spi_nor_scan(struct spi_nor *nor, const char *name,
 const struct spi_nor_hwcaps *hwcaps);
 
+/*
+ * spi_nor_restore_addr_mode() - restore the status of SPI NOR
+ * @nor:   the spi_nor structure
+ */
+void spi_nor_restore(struct spi_nor *nor);
+
 #endif
-- 
2.14.1

[PATCH v2 3/3] checkpatch: warn for use of %px

[Tobin C. Harding]

Usage of the new %px specifier potentially leaks sensitive
inforamtion. Printing kernel addresses exposes the kernel layout in
memory, this is potentially exploitable. We have tools in the kernel to
help us do the right thing. We can have checkpatch warn developers of
potential dangers of using %px.

Have checkpatch emit a warning for usage of specifier %px.

Signed-off-by: Tobin C. Harding 
Co-developed-by: Joe Perches 
Acked-by: Joe Perches 
---
 scripts/checkpatch.pl | 31 ---
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4534c9a9aefa..6df99d1ebca5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5750,21 +5750,38 @@ sub process {
defined $stat &&
$stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
$1 !~ /^_*volatile_*$/) {
-   my $bad_extension = "";
+   my $specifier;
+   my $extension;
+   my $bad_specifier = "";
+   my $stat_real;
+
my $lc = $stat =~ tr@\n@@;
$lc = $lc + $linenr;
for (my $count = $linenr; $count <= $lc; $count++) {
my $fmt = get_quoted_string($lines[$count - 1], 
raw_line($count, 0));
$fmt =~ s/%%//g;
-   if ($fmt =~ 
/(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGNOx]).)/) {
-   $bad_extension = $1;
-   last;
+
+   while ($fmt =~ /(\%[\*\d\.]*p(\w))/g) {
+   $specifier = $1;
+   $extension = $2;
+   if ($extension !~ 
/[FfSsBKRraEhMmIiUDdgVCbGNOx]/) {
+   $bad_specifier = $specifier;
+   last;
+   }
+   if ($extension eq "x" && 
!defined($stat_real)) {
+   if (!defined($stat_real)) {
+   $stat_real = 
get_stat_real($linenr, $lc);
+   }
+   WARN("VSPRINTF_SPECIFIER_PX",
+"Using vsprintf specifier 
'\%px' potentially exposes the kernel memory layout, if you don't really need 
the address please consider using '\%p'.\n" . "$here\n$stat_real\n");
+   }
}
+
}
-   if ($bad_extension ne "") {
-   my $stat_real = get_stat_real($linenr, $lc);
+   if ($bad_specifier ne "") {
+   $stat_real = get_stat_real($linenr, $lc);
WARN("VSPRINTF_POINTER_EXTENSION",
-"Invalid vsprintf pointer extension 
'$bad_extension'\n" . "$here\n$stat_real\n");
+"Invalid vsprintf pointer extension 
'$bad_specifier'\n" . "$here\n$stat_real\n");
}
}
 
-- 
2.7.4

[PATCH v2 2/3] checkpatch: add sub routine get_stat_here()

[Tobin C. Harding]

checkpatch currently contains duplicate code. We can define a sub
routine and call that instead. This reduces code duplication and line
count.

Add subroutine get_stat_here()

Signed-off-by: Tobin C. Harding 
---
 scripts/checkpatch.pl | 54 +++
 1 file changed, 20 insertions(+), 34 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 5a63aa36300a..4534c9a9aefa 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1623,6 +1623,17 @@ sub get_stat_real {
return $stat_real;
 }
 
+sub get_stat_here {
+   my ($linenr, $cnt, $here) = @_;
+
+   my $herectx = $here . "\n";
+   for (my $n = 0; $n < $cnt; $n++) {
+   $herectx .= raw_line($linenr, $n) . "\n";
+   }
+
+   return $herectx;
+}
+
 sub cat_vet {
my ($vet) = @_;
my ($res, $coded);
@@ -4911,12 +4922,8 @@ sub process {
#print "REST<$rest> dstat<$dstat> ctx<$ctx>\n";
 
$ctx =~ s/\n*$//;
-   my $herectx = $here . "\n";
my $stmt_cnt = statement_rawlines($ctx);
-
-   for (my $n = 0; $n < $stmt_cnt; $n++) {
-   $herectx .= raw_line($linenr, $n) . "\n";
-   }
+   my $herectx = get_stat_here($linenr, $stmt_cnt, $here);
 
if ($dstat ne '' &&
$dstat !~ /^(?:$Ident|-?$Constant),$/ &&
# 10, // foo(),
@@ -4988,12 +4995,9 @@ sub process {
 # check for macros with flow control, but without ## concatenation
 # ## concatenation is commonly a macro that defines a function so ignore those
if ($has_flow_statement && !$has_arg_concat) {
-   my $herectx = $here . "\n";
my $cnt = statement_rawlines($ctx);
+   my $herectx = get_stat_here($linenr, $cnt, 
$here);
 
-   for (my $n = 0; $n < $cnt; $n++) {
-   $herectx .= raw_line($linenr, $n) . 
"\n";
-   }
WARN("MACRO_WITH_FLOW_CONTROL",
 "Macros with flow control statements 
should be avoided\n" . "$herectx");
}
@@ -5033,11 +5037,7 @@ sub process {
 
$ctx =~ s/\n*$//;
my $cnt = statement_rawlines($ctx);
-   my $herectx = $here . "\n";
-
-   for (my $n = 0; $n < $cnt; $n++) {
-   $herectx .= raw_line($linenr, $n) . 
"\n";
-   }
+   my $herectx = get_stat_here($linenr, $cnt, 
$here);
 
if (($stmts =~ tr/;/;/) == 1 &&
$stmts !~ /^\s*(if|while|for|switch)\b/) {
@@ -5051,11 +5051,7 @@ sub process {
} elsif ($dstat =~ /^\+\s*#\s*define\s+$Ident.*;\s*$/) {
$ctx =~ s/\n*$//;
my $cnt = statement_rawlines($ctx);
-   my $herectx = $here . "\n";
-
-   for (my $n = 0; $n < $cnt; $n++) {
-   $herectx .= raw_line($linenr, $n) . 
"\n";
-   }
+   my $herectx = get_stat_here($linenr, $cnt, 
$here);
 
WARN("TRAILING_SEMICOLON",
 "macros should not use a trailing 
semicolon\n" . "$herectx");
@@ -5178,12 +5174,8 @@ sub process {
}
}
if ($level == 0 && $block =~ /^\s*\{/ && !$allowed) {
-   my $herectx = $here . "\n";
my $cnt = statement_rawlines($block);
-
-   for (my $n = 0; $n < $cnt; $n++) {
-   $herectx .= raw_line($linenr, $n) . 
"\n";
-   }
+   my $herectx = get_stat_here($linenr, $cnt, 
$here);
 
WARN("BRACES",
 "braces {} are not necessary for single 
statement blocks\n" . $herectx);
@@ -6026,12 +6018,9 @@ sub process {
}
if ($r1 !~ /^sizeof\b/ && $r2 =~ /^sizeof\s*\S/ &&
!($r1 =~ /^$Constant$/ || $r1 =~ 
/^[A-Z_][A-Z0-9_]*$/)) {
-   my $ctx = '';
-   my $herectx = $here . "\n";
my $cnt = statement_rawlines($stat);
-   for (my $n = 0; $n < $cnt; $n++) {
- 

[PATCH v2 1/3] checkpatch: add sub routine get_stat_real()

[Tobin C. Harding]

checkpatch currently contains duplicate code. We can define a sub
routine and call that instead. This reduces code duplication and line
count.

Add subroutine get_stat_real()

Signed-off-by: Tobin C. Harding 
---
 scripts/checkpatch.pl | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 040aa79e1d9d..5a63aa36300a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1612,6 +1612,17 @@ sub raw_line {
return $line;
 }
 
+sub get_stat_real {
+   my ($linenr, $lc) = @_;
+
+   my $stat_real = raw_line($linenr, 0);
+   for (my $count = $linenr + 1; $count <= $lc; $count++) {
+   $stat_real = $stat_real . "\n" . raw_line($count, 0);
+   }
+
+   return $stat_real;
+}
+
 sub cat_vet {
my ($vet) = @_;
my ($res, $coded);
@@ -5759,10 +5770,7 @@ sub process {
}
}
if ($bad_extension ne "") {
-   my $stat_real = raw_line($linenr, 0);
-   for (my $count = $linenr + 1; $count <= $lc; 
$count++) {
-   $stat_real = $stat_real . "\n" . 
raw_line($count, 0);
-   }
+   my $stat_real = get_stat_real($linenr, $lc);
WARN("VSPRINTF_POINTER_EXTENSION",
 "Invalid vsprintf pointer extension 
'$bad_extension'\n" . "$here\n$stat_real\n");
}
@@ -5877,10 +5885,7 @@ sub process {
 $stat !~ /(?:$Compare)\s*\bsscanf\s*$balanced_parens/)) {
my $lc = $stat =~ tr@\n@@;
$lc = $lc + $linenr;
-   my $stat_real = raw_line($linenr, 0);
-   for (my $count = $linenr + 1; $count <= $lc; $count++) {
-   $stat_real = $stat_real . "\n" . 
raw_line($count, 0);
-   }
+   my $stat_real = get_stat_real($linenr, $lc);
WARN("NAKED_SSCANF",
 "unchecked sscanf return value\n" . 
"$here\n$stat_real\n");
}
@@ -5891,10 +5896,7 @@ sub process {
$line =~ /\bsscanf\b/) {
my $lc = $stat =~ tr@\n@@;
$lc = $lc + $linenr;
-   my $stat_real = raw_line($linenr, 0);
-   for (my $count = $linenr + 1; $count <= $lc; $count++) {
-   $stat_real = $stat_real . "\n" . 
raw_line($count, 0);
-   }
+   my $stat_real = get_stat_real($linenr, $lc);
if ($stat_real =~ 
/\bsscanf\b\s*\(\s*$FuncArg\s*,\s*("[^"]+")/) {
my $format = $6;
my $count = $format =~ tr@%@%@;
@@ -6289,10 +6291,7 @@ sub process {
 
my $lc = $stat =~ tr@\n@@;
$lc = $lc + $linenr;
-   my $stat_real = raw_line($linenr, 0);
-   for (my $count = $linenr + 1; $count <= $lc; 
$count++) {
-   $stat_real = $stat_real . "\n" . 
raw_line($count, 0);
-   }
+   my $stat_real = get_stat_real($linenr, $lc);
 
my $skip_args = "";
if ($arg_pos > 1) {
-- 
2.7.4

[PATCH v2 0/3] checkpatch: warn for use of %px

[Tobin C. Harding]

Patch 1 and 2 are cleanup patches. Each adds a new subroutine to remove
duplicate code.

Patch 3: Make checkpatch emit a warning for usage of specifier %px. 

The initial idea to emit the warning was given on LKML by Andrew Morton,
v1 requested permission to use 'Suggested-by' tag. This version does not
add that tag.

thanks,
Tobin.

v2:
 - change new sub name stat_real() -> get_stat_real()
 - add new sub get_stat_here()
 - (add new sub routines as separate patches)
 - add 'Acked-by' tag for Joe
 - remove 'Suggested-by' tag for Andrew Morton

Tobin C. Harding (3):
  checkpatch: add sub routine get_stat_real()
  checkpatch: add sub routine get_stat_here()
  checkpatch: warn for use of %px

 scripts/checkpatch.pl | 114 +-
 1 file changed, 58 insertions(+), 56 deletions(-)

-- 
2.7.4

RE: [PATCH v6 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Appana Durga Kedareswara Rao]

Hi Mike Looijmans,

Thanks for the review...
Sorry for the long delay in the reply...
Please find comments inline... 


>On 14-01-17 06:35, Kedareswara rao Appana wrote:
>>  When VDMA is configured for more than one frame in the h/w.
>>  For example h/w is configured for n number of frames, user
>>  Submits n number of frames and triggered the DMA using issue_pending API.
>>
>>  In the current driver flow we are submitting one frame at a time,
>>  But we should submit all the n number of frames at one time
>>  As the h/w is configured for n number of frames.
>
>The hardware can always handle a single frame submission, by using the "park"
>bit. This would make a good "cyclic" implementation too (using vdma as
>framebuffer).
>
>It could also handle all cases for "k" frames where n%k==0 (n is a multiple of
>k) by simply replicating the frame pointers.

Agree with your comments will fix it in the next version.
Somehow didn't get enough time to send next version of the patch series.
Will modify the driver as per your comments and will post next version of the 
patch series at the earliest... 

Regards,
Kedar.

linux-next: Tree for Dec 6

[Stephen Rothwell]

Hi all,

Changes since 20171205:

Removed trees: tile (orphaned)
drm-amd-dc (finished with)

The printk tree gained a build failure for which I reverted a commit.

The drm-misc tree gained a build failure due to an interaction with the
drm-intel tree, so I applied a merge fix up patch.

Non-merge commits (relative to Linus' tree): 2719
 3246 files changed, 78978 insertions(+), 39889 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 250 trees (counting Linus' and 40 trees of bug
fix patches pending for the current merge release).

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 (13231caccedf Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging kbuild-current/fixes (4fbd8d194f06 Linux 4.15-rc1)
Merging arc-current/for-curr (329b4130bc5e ARC: Fix detection of dual-issue 
enabled)
Merging arm-current/fixes (3aaf33bebda8 ARM: avoid faulting on qemu)
Merging m68k-current/for-linus (5e387199c17c m68k/defconfig: Update defconfigs 
for v4.14-rc7)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (7e4d4233260b powerpc: Do not assign thread.tidr if 
already assigned)
Merging sparc/master (a0908a1b7d68 Merge branch 'akpm' (patches from Andrew))
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c9d3fe9da094 VSOCK: fix outdated sk_state value in 
hvs_release())
Merging bpf/master (2391f0b4808e Merge tag 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost)
Merging ipsec/master (4ce3dbe397d7 xfrm: Fix xfrm_input() to verify state is 
valid when (encap_type < 0))
Merging netfilter/master (8b1836c4b643 netfilter: conntrack: clamp timeouts to 
INT_MAX)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (5c3de777bdaf brcmfmac: change driver unbind 
order of the sdio function devices)
Merging mac80211/master (72e2c3438ba3 mac80211: tear down RX aggregations first)
Merging sound-current/for-linus (362bca57f5d7 ALSA: pcm: prevent UAF in 
snd_pcm_info)
Merging pci-current/for-linus (4fbd8d194f06 Linux 4.15-rc1)
Merging driver-core.current/driver-core-linus (0946b2fb38fd firmware: cleanup 
FIRMWARE_IN_KERNEL message)
Merging tty.current/tty-linus (c8ec2041f549 MIPS: Add custom serial.h with 
BASE_BAUD override for generic kernel)
Merging usb.current/usb-linus (80e457699a8d usb: xhci: fix panic in 
xhci_free_virt_devices_depth_first)
Merging usb-gadget-fixes/fixes (a3acc696085e usb: f_fs: Force Reserved1=1 in 
OS_DESC_EXT_COMPAT)
Merging usb-serial-fixes/usb-linus (762ff4678e89 USB: serial: usb_debug: add 
new USB device id)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (4fbd8d194f06 Linux 4.15-rc1)
Merging staging.current/staging-linus (e168e9845d95 Merge tag 
'iio-fixes-for-4.15a' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (66bc5df31110 MAINTAINERS: update 
Android driver maintainers.)
Merging input-current/for-li

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

[Alexey Dobriyan]

> more %p grepping [filtering out all `%ps %pf %pb' variants] gives
> a huge number of print outs that potentially can be broken now

Because people who introduce this stupid %p hashing can't be bothered
to actually audit users:

static int show_timer(struct seq_file *m, void *v)
{
...
seq_printf(m, "signal: %d/%p\n",
   timer->sigq->info.si_signo,
   timer->sigq->info.si_value.sival_ptr);

Overall, this %px thing doesn't matter. Developers will quickly learn
than %p gives some useless irreversible values and start using %px
everywhere. Soon someone will use %px in the wrong place and new
non-standard format specifier will be added.

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

[Linus Torvalds]

On Tue, Dec 5, 2017 at 8:19 PM, Alexey Dobriyan  wrote:
> Because people who introduce this stupid %p hashing can't be bothered
> to actually audit users:

I don't see you having offered to audit the 12k+ cases, did you?

So maybe it's easier to just change them all, and then the handful
that breaks can be fixed?

Do you maybe want to re-think that "stupid" comment?

Or are you going to spend the time to audit all those other %p users,
particularly considering that we _know_ a number of them are bad?

Once you've done that, and offered to keep doing it, we can undo the hashing.

I'll be waiting.

 Linus

Re: [PATCH 1/2] mm: introduce MAP_FIXED_SAFE

[Michael Ellerman]

Hi Michal,

Some comments below.

Michal Hocko  writes:

> From: Michal Hocko 
>
> MAP_FIXED is used quite often to enforce mapping at the particular
> range. The main problem of this flag is, however, that it is inherently
> dangerous because it unmaps existing mappings covered by the requested
> range. This can cause silent memory corruptions. Some of them even with
> serious security implications. While the current semantic might be
> really desiderable in many cases there are others which would want to
> enforce the given range but rather see a failure than a silent memory
> corruption on a clashing range. Please note that there is no guarantee
> that a given range is obeyed by the mmap even when it is free - e.g.
> arch specific code is allowed to apply an alignment.

I don't think this last sentence is correct. Or maybe I don't understand
what you're referring to.

If you specifiy MAP_FIXED on a page boundary then the mapping must be
made at that address, I don't think arch code is allowed to add any
extra alignment.

> Introduce a new MAP_FIXED_SAFE flag for mmap to achieve this behavior.
> It has the same semantic as MAP_FIXED wrt. the given address request
> with a single exception that it fails with EEXIST if the requested
> address is already covered by an existing mapping. We still do rely on
> get_unmaped_area to handle all the arch specific MAP_FIXED treatment and
> check for a conflicting vma after it returns.
>
> [fail on clashing range with EEXIST as per Florian Weimer]
> [set MAP_FIXED before round_hint_to_min as per Khalid Aziz]
> Reviewed-by: Khalid Aziz 
> Signed-off-by: Michal Hocko 
> ---
>  arch/alpha/include/uapi/asm/mman.h   |  2 ++
>  arch/mips/include/uapi/asm/mman.h|  2 ++
>  arch/parisc/include/uapi/asm/mman.h  |  2 ++
>  arch/powerpc/include/uapi/asm/mman.h |  1 +
>  arch/sparc/include/uapi/asm/mman.h   |  1 +
>  arch/tile/include/uapi/asm/mman.h|  1 +
>  arch/xtensa/include/uapi/asm/mman.h  |  2 ++
>  include/uapi/asm-generic/mman.h  |  1 +
>  mm/mmap.c| 11 +++
>  9 files changed, 23 insertions(+)
>
> diff --git a/arch/alpha/include/uapi/asm/mman.h 
> b/arch/alpha/include/uapi/asm/mman.h
> index 6bf730063e3f..ef3770262925 100644
> --- a/arch/alpha/include/uapi/asm/mman.h
> +++ b/arch/alpha/include/uapi/asm/mman.h
> @@ -32,6 +32,8 @@
>  #define MAP_STACK0x8 /* give out an address that is best 
> suited for process/thread stacks */
>  #define MAP_HUGETLB  0x10/* create a huge page mapping */
>  
> +#define MAP_FIXED_SAFE   0x20/* MAP_FIXED which doesn't 
> unmap underlying mapping */
> +

Why the new line before MAP_FIXED_SAFE? It should sit with the others.

You're using a different value to other arches here, but that's OK, and
alpha doesn't use asm-generic/mman.h or mman-common.h

> diff --git a/arch/powerpc/include/uapi/asm/mman.h 
> b/arch/powerpc/include/uapi/asm/mman.h
> index e63bc37e33af..3ffd284e7160 100644
> --- a/arch/powerpc/include/uapi/asm/mman.h
> +++ b/arch/powerpc/include/uapi/asm/mman.h
> @@ -29,5 +29,6 @@
>  #define MAP_NONBLOCK 0x1 /* do not block on IO */
>  #define MAP_STACK0x2 /* give out an address that is best 
> suited for process/thread stacks */
>  #define MAP_HUGETLB  0x4 /* create a huge page mapping */
> +#define MAP_FIXED_SAFE   0x80/* MAP_FIXED which doesn't 
> unmap underlying mapping */

Why did you pick 0x80?

I don't see any reason you can't use 0x8000 on powerpc.

 
> diff --git a/arch/sparc/include/uapi/asm/mman.h 
> b/arch/sparc/include/uapi/asm/mman.h
> index 715a2c927e79..0c282c09fae8 100644
> --- a/arch/sparc/include/uapi/asm/mman.h
> +++ b/arch/sparc/include/uapi/asm/mman.h
> @@ -24,6 +24,7 @@
>  #define MAP_NONBLOCK 0x1 /* do not block on IO */
>  #define MAP_STACK0x2 /* give out an address that is best 
> suited for process/thread stacks */
>  #define MAP_HUGETLB  0x4 /* create a huge page mapping */
> +#define MAP_FIXED_SAFE   0x8 /* MAP_FIXED which doesn't 
> unmap underlying mapping */

Using 0x8 on sparc, sparc uses mman-common.h.

> diff --git a/arch/tile/include/uapi/asm/mman.h 
> b/arch/tile/include/uapi/asm/mman.h
> index 9b7add95926b..b212f5fd5345 100644
> --- a/arch/tile/include/uapi/asm/mman.h
> +++ b/arch/tile/include/uapi/asm/mman.h
> @@ -30,6 +30,7 @@
>  #define MAP_DENYWRITE0x0800  /* ETXTBSY */
>  #define MAP_EXECUTABLE   0x1000  /* mark it as an executable */
>  #define MAP_HUGETLB  0x4000  /* create a huge page mapping */
> +#define MAP_FIXED_SAFE   0x8000  /* MAP_FIXED which doesn't 
> unmap underlying mapping */
  
That is the next free flag, but you could also use 0x8 on tile.

tile uses mman-common.h.

> diff --git a/arch/xtensa/include/uapi/asm/mman.h 
> 

Re: [PATCH v2 3/3] net: macb: change GFP_ATOMIC to GFP_KERNEL

[Julia Lawall]

On Tue, 5 Dec 2017, Julia Cartwright wrote:

> Now that the rx_fs_lock is no longer held across allocation, it's safe
> to use GFP_KERNEL for allocating new entries.
>
> This reverts commit 81da3bf6e3f88 ("net: macb: change GFP_KERNEL to
> GFP_ATOMIC").
>
> Cc: Julia Lawall 
> Signed-off-by: Julia Cartwright 

Acked-by: Julia Lawall 


> ---
>  drivers/net/ethernet/cadence/macb_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c 
> b/drivers/net/ethernet/cadence/macb_main.c
> index 758e8b3042b2..234667eaaa92 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -2800,7 +2800,7 @@ static int gem_add_flow_filter(struct net_device 
> *netdev,
>   int ret = -EINVAL;
>   bool added = false;
>
> - newfs = kmalloc(sizeof(*newfs), GFP_ATOMIC);
> + newfs = kmalloc(sizeof(*newfs), GFP_KERNEL);
>   if (newfs == NULL)
>   return -ENOMEM;
>   memcpy(>fs, fs, sizeof(newfs->fs));
> --
> 2.14.2
>
>

Re: [PATCH] usb: core: Fix logging messages with spurious periods after newlines

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 10:22:05PM -0800, Joe Perches wrote:
> Using a period after a newline causes bad output.

Nice catch, how did you find that?

thanks,

greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
> 
> 
> > On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman 
> >  wrote:
> > 
> > On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
> >> 
> >> 
> >>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman 
> >>>  wrote:
> >>> 
> >>> This is the start of the stable review cycle for the 4.14.4 release.
> >>> There are 95 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 Wed Dec  6 16:00:27 UTC 2017.
> >>> 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.14.4-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.14.y
> >>> and the diffstat can be found below.
> >>> 
> >>> thanks,
> >>> 
> >>> greg k-h
> >>> 
> >> 
> >> Compiled, booted and ran the following package unit tests without 
> >> regressions on x86_64
> >> 
> >> boringssl : 
> >>   go test target:0/0/5764/5764/5764 PASS
> >>   ssl_test : 10 pass
> >>   crypto_test : 28 pass
> >> e2fsprogs:
> >>   make check : 340 pass
> >> sqlite
> >>   make test : 143914 pass
> >> drm
> >>   make check : 15 pass
> >>   modetest, drmdevice : pass
> >> alsa-lib
> >>   make check : 2 pass
> >> bluez
> >>   make check : 25 pass
> >> libusb
> >>   stress : 4 pass
> > 
> > How do the above tests stress the kernel?
> 
> Depends entirely on the package in question.
> 
> Sure, of completely no surprise a lot of package unit tests don’t really 
> do much that’s particularly interesting save to the package itself.

Then why run those tests?  Like sqlite, what kernel functionality does
that exercise that ltp does not?

> There are sometimes an interesting subset that drives some amount of work in 
> kernel. 
> That’s the useful stuff.

Is that true with the above list?  If so, why are those types of tests
not part of any kernel test suite that I have seen before?

> Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.  

Nice, does that cover things that is not in LTP?  Should those tests be
added to LTP?

> >  Aren't they just
> > verifications that the source code in the package is correct?
> 
> So if there’s some useful subset, that’s what I’m looking for.
> 
> > I guess it proves something, but have you ever seen the above regress in
> > _any_ kernel release?
> 
> Past regressions make for a good test. 

You are testing past regressions of the userspace code, not the kernel
here.  Why do I care about that?  :)

Don't fall down the trap of running code for the sake of running code
(i.e. like that web site that starts with a P) that doesn't actually
test anything that actually matters.

thanks,

greg k-h

Re: [PATCH] ARM: dts: introduce the sama5d2 ptc ek board

[Ludovic Desroches]

On Tue, Dec 05, 2017 at 07:01:41PM +0200, Baruch Siach wrote:
> Hi Ludovic,
> 
> On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote:
> > Add the official SAMA5D2 Peripheral Touch Controller Evaluation
> > Kit board.
> > 
> > Signed-off-by: Ludovic Desroches 
> > ---
> 
> [...]
> 
> > +   memory {
> > +   reg = <0x2000 0x8>;
> > +   };
> 
> The size value is clearly wrong; you surely don't run on 512KB RAM. You most 
> likely rely on the bootloader to fix the size value. Since sama5d2.dtsi has a 
> memory node already with the same address, you can just drop it from here.
> 

Thanks, fixed in v2.

Ludovic

> baruch
> 
> -- 
>  http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
> =}ooO--U--Ooo{=
>- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

[Matthew Wilcox]

On Wed, Dec 06, 2017 at 12:36:48PM +1100, Dave Chinner wrote:
> > -   if (radix_tree_preload(GFP_NOFS))
> > -   return -ENOMEM;
> > -
> > INIT_LIST_HEAD(>list_node);
> > elem->key = key;
> >  
> > -   spin_lock(>lock);
> > -   error = radix_tree_insert(>store, key, elem);
> > -   radix_tree_preload_end();
> > -   if (!error)
> > -   _xfs_mru_cache_list_insert(mru, elem);
> > -   spin_unlock(>lock);
> > +   do {
> > +   xas_lock();
> > +   xas_store(, elem);
> > +   error = xas_error();
> > +   if (!error)
> > +   _xfs_mru_cache_list_insert(mru, elem);
> > +   xas_unlock();
> > +   } while (xas_nomem(, GFP_NOFS));
> 
> Ok, so why does this have a retry loop on ENOMEM despite the
> existing code handling that error? And why put such a loop in this
> code and not any of the other XFS code that used
> radix_tree_preload() and is arguably much more important to avoid
> ENOMEM on insert (e.g. the inode cache)?

If we need more nodes in the tree, xas_store() will try to allocate them
with GFP_NOWAIT | __GFP_NOWARN.  If that fails, it signals it in xas_error().
xas_nomem() will notice that we're in an ENOMEM situation, and allocate
a node using your preferred GFP flags (NOIO in your case).  Then we retry,
guaranteeing forward progress. [1]

The other conversions use the normal API instead of the advanced API, so
all of this gets hidden away.  For example, the inode cache does this:

+   curr = xa_cmpxchg(>pag_ici_xa, agino, NULL, ip, GFP_NOFS);

and xa_cmpxchg internally does:

do {
xa_lock_irqsave(xa, flags);
curr = xas_create();
if (curr == old)
xas_store(, entry);
xa_unlock_irqrestore(xa, flags);
} while (xas_nomem(, gfp));


> Also, I really don't like the pattern of using xa_lock()/xa_unlock()
> to protect access to an external structure. i.e. the mru->lock
> context is protecting multiple fields and operations in the MRU
> structure, not just the radix tree operations. Turning that around
> so that a larger XFS structure and algorithm is now protected by an
> opaque internal lock from generic storage structure the forms part
> of the larger structure seems like a bad design pattern to me...

It's the design pattern I've always intended to use.  Naturally, the
xfs radix trees weren't my initial target; it was the page cache, and
the page cache does the same thing; uses the tree_lock to protect both
the radix tree and several other fields in that same data structure.

I'm open to argument on this though ... particularly if you have a better
design pattern in mind!

[1] I actually have this documented!  It's in the xas_nomem() kernel-doc:

 * If we need to add new nodes to the XArray, we try to allocate memory
 * with GFP_NOWAIT while holding the lock, which will usually succeed.
 * If it fails, @xas is flagged as needing memory to continue.  The caller
 * should drop the lock and call xas_nomem().  If xas_nomem() succeeds,
 * the caller should retry the operation.
 *
 * Forward progress is guaranteed as one node is allocated here and
 * stored in the xa_state where it will be found by xas_alloc().  More
 * nodes will likely be found in the slab allocator, but we do not tie
 * them up here.
 *
 * Return: true if memory was needed, and was successfully allocated.

Re: [PATCH v4 00/73] XArray version 4

[Matthew Wilcox]

On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox 
> > 
> > I looked through some notes and decided this was version 4 of the XArray.
> > Last posted two weeks ago, this version includes a *lot* of changes.
> > I'd like to thank Dave Chinner for his feedback, encouragement and
> > distracting ideas for improvement, which I'll get to once this is merged.
> 
> BTW, you need to fix the "To:" line on your patchbombs:
> 
> > To: unlisted-recipients: ;, no To-header on input <@gmail-pop.l.google.com> 
> 
> This bad email address getting quoted to the cc line makes some MTAs
> very unhappy.

I know :-(  I was unhappy when I realised what I'd done.

https://marc.info/?l=git=151252237912266=2

> I'll give this a quick burn this afternoon and see what catches fire...

All of the things ... 0day gave me a 90% chance of hanging in one
configuration.  Need to drill down on it more and find out what stupid
thing I've done wrong this time.

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi Rodrigo,

On Tue, 5 Dec 2017 17:21:54 -0800 Rodrigo Vivi  wrote:
>
> I had just written the email for you about this.
> Feel free to ignore that one since you already found the solution
> and sorry for the delay on warning you.

And I should read all my email before responding to earlier ones :-)

-- 
Cheers,
Stephen Rothwell

Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

[David Rientjes]

Hi,

I'd like to understand the synchronization between the oom_reaper's 
unmap_page_range() and exit_mmap().  The latter does not hold 
mm->mmap_sem: it's supposed to be the last thread operating on the mm 
before it is destroyed.

If unmap_page_range() races with unmap_vmas(), we trivially call 
page_remove_rmap() twice on the same page:

BUG: Bad page map in process oom_reaper  pte:63538263 pmd:
addr:7f50cab1d000 vm_flags:08100073 anon_vma:9eea335603f0 mapping:  
(null) index:7f50cab1d
file:  (null) fault:  (null) mmap:  (null) readpage:
  (null)
CPU: 2 PID: 1001 Comm: oom_reaper
Call Trace:
 [] dump_stack+0x4d/0x70
 [] unmap_page_range+0x1068/0x1130
 [] __oom_reap_task_mm+0xd5/0x16b
 [] oom_reaper+0xff/0x14c
 [] kthread+0xc1/0xe0

And there are more examples of badness from an unmap_page_range() racing 
with unmap_vmas().  In this case, MMF_OOM_SKIP is doing two things: (1) 
avoiding additional oom kills until unmap_vmas() returns and (2) avoid the 
oom_reaper working on the mm after unmap_vmas().  In (2), there's nothing 
preventing the oom reaper from calling unmap_page_range() in parallel with 
the final thread doing unmap_vmas() -- we no longer do mmget() to prevent 
exit_mmap() from being called.

I don't think that we can allow the oom reaper's unmap_page_range() to 
race with unmap_vmas().  If we can, what allows this if we don't either 
increment mm->mm_users in the oom reaper or hold mm->mmap_sem for write in 
exit_mmap()?

One way to solve the issue is to have two mm flags: one to indicate the mm 
is entering unmap_vmas(): set the flag, do down_write(>mmap_sem); 
up_write(>mmap_sem), then unmap_vmas().  The oom reaper needs this 
flag clear, not MMF_OOM_SKIP, while holding down_read(>mmap_sem) to be 
allowed to call unmap_page_range().  The oom killer will still defer 
selecting this victim for MMF_OOM_SKIP after unmap_vmas() returns.

The result of that change would be that we do not oom reap from any mm 
entering unmap_vmas(): we let unmap_vmas() do the work itself and avoid 
racing with it.

[PATCH 0/5] perf-probe: Improve probing on versioned symbols

[Masami Hiramatsu]

Hi,

Here is the series for probing on versioned symbols
in libraries. This includes 5 patches to fix the
issues discussed on perf-users ML 
(https://www.spinics.net/lists/linux-perf-users/msg04637.html)

[1/5] Warn if the event name is invalid. This notices
   user that there is internal error which caused by
   unexpected input.
[2/5] Cut off the version suffix when making event name
   from symbol name. This fixes a issue when a wildcard
   hits versioned symbol.
[3/5] Add "__return" suffix to the event name 
   automatically for the return probe, so that user
   can easily identify which event is on function
   return.
[4/5] Find versioned symbol from map without wildcard.
   This allows user to specify a symbol without version
   suffix nor wildcard. Anyway, at this point we have
   no way to specify version suffix, because parser
   recognizes "@" is a separator of "function@file"
   syntax. This is fixed in next patch.
[5/5] Allow user to use backslash-escaped characters
   on command line. This has 2 effects, user can specify
   version suffix directly, and we can use special
   characters in source file.

Thanks,
---

Masami Hiramatsu (5):
  perf-probe: Add warning message if there is unexpected event name
  perf-probe: Cut off the version suffix from event name
  perf-probe: Add __return suffix for return events
  perf-probe: Find versioned symbols from map
  perf-probe: Support escaped character in parser


 tools/perf/arch/powerpc/util/sym-handling.c |8 +++
 tools/perf/util/probe-event.c   |   81 +++
 tools/perf/util/string.c|   46 +++
 tools/perf/util/string2.h   |2 +
 tools/perf/util/symbol.c|5 ++
 tools/perf/util/symbol.h|1 
 6 files changed, 120 insertions(+), 23 deletions(-)

--
Masami Hiramatsu (Linaro Ltd.) 

[PATCH 1/5] perf-probe: Add warning message if there is unexpected event name

[Masami Hiramatsu]

This improve the error message so that user can know
event-name error before writing new events to
kprobe-events interface.

E.g.
   ==
   #./perf probe -x /lib64/libc-2.25.so malloc_get_state*
   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
 Error: Failed to add events.
   ==

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index b7aaf9b2294d..c0067950e56f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2625,6 +2625,14 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
 
 out:
free(nbase);
+
+   /* Final validation */
+   if (ret >= 0 && !is_c_func_name(buf)) {
+   pr_warning("Internal error: \"%s\" is wrong event name.\n",
+  buf);
+   ret = -EINVAL;
+   }
+
return ret;
 }
 

[PATCH] usbip: vhci-hcd: return correct port ENABLE status

[Pei Zhang]

USB system will clear port's ENABLE feature for some USB devices when
vdev is already assigned port address. This cause getPortStatus reports
to system that this device is not enabled, client OS will failed to use
this usb device.

The failure devices include a SAMSUNG SSD storage, and a Logitech webcam.

Signed-off-by: Pei Zhang 
---
 drivers/usb/usbip/vhci_hcd.c | 38 +++---
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index e4cb9f0..7b8cf70 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -350,24 +350,32 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
dum->re_timeout = 0;
}
 
-   if ((dum->port_status[rhport] & (1 << USB_PORT_FEAT_RESET)) !=
-   0 && time_after(jiffies, dum->re_timeout)) {
-   dum->port_status[rhport] |=
-   (1 << USB_PORT_FEAT_C_RESET);
-   dum->port_status[rhport] &=
-   ~(1 << USB_PORT_FEAT_RESET);
-   dum->re_timeout = 0;
-
-   if (dum->vdev[rhport].ud.status ==
-   VDEV_ST_NOTASSIGNED) {
-   usbip_dbg_vhci_rh(
-   " enable rhport %d (status %u)\n",
-   rhport,
-   dum->vdev[rhport].ud.status);
+   if (dum->port_status[rhport] & (1 << USB_PORT_FEAT_RESET)) {
+   if (time_after(jiffies, dum->re_timeout)) {
dum->port_status[rhport] |=
-   USB_PORT_STAT_ENABLE;
+   (1 << USB_PORT_FEAT_C_RESET);
+   dum->port_status[rhport] &=
+   ~(1 << USB_PORT_FEAT_RESET);
+   dum->re_timeout = 0;
+
+   if (dum->vdev[rhport].ud.status ==
+   VDEV_ST_NOTASSIGNED) {
+   usbip_dbg_vhci_rh(
+   " enable rhport %d (status 
%u)\n",
+   rhport,
+   dum->vdev[rhport].ud.status);
+   dum->port_status[rhport] |=
+   USB_PORT_STAT_ENABLE;
+   }
}
+   } else {
+   /* Port would be disabled by clearing FEAT_ENABLE bit,
+* make it enabled here. No more thing should be done. 
*/
+   if (dum->vdev[rhport].ud.status == VDEV_ST_USED)
+   dum->port_status[rhport] |=
+   USB_PORT_STAT_ENABLE;
}
+
((__le16 *) buf)[0] = cpu_to_le16(dum->port_status[rhport]);
((__le16 *) buf)[1] =
cpu_to_le16(dum->port_status[rhport] >> 16);
-- 
2.7.4

[PATCH v3 2/6] iommu/vt-d: Add Intel IOMMU debugfs to show context internals

[Sohil Mehta]

From: Gayatri Kammela 

IOMMU internals states such as root and context can be exported to the
userspace.

Example of such dump in Kabylake:

root@OTC-KBLH-01:~# cat
/sys/kernel/debug/intel_iommu/dmar_translation_struct

IOMMU dmar2:Root Table Addr:4558a3000
 Root tbl entries:
Bus 0 L: 4558aa001 H: 0
 Context table entries for Bus: 0
[entry] DID :B :D .FLow High
[160]   :00:14.00   4558a9001   102
[184]   :00:17.00   400eac001   302
[248]   :00:1f.00   4558af001   202
[251]   :00:1f.03   40070e001   502
[254]   :00:1f.06   4467c9001   602
 Root tbl entries:
Bus 1 L: 3fc8c2001 H: 0
 Context table entries for Bus: 1
[entry] DID :B :D .FLow High
[0] :01:00.00   3fc8c3001   402

Cc: Sohil Mehta 
Cc: Fenghua Yu 
Cc: Ashok Raj 
Signed-off-by: Jacob Pan 
Signed-off-by: Gayatri Kammela 
---

v3: Add a macro for seq file operations 
Change the intel_iommu_ctx file name to dmar_translation_struct

v2: No change

 drivers/iommu/Makefile|   1 +
 drivers/iommu/intel-iommu-debug.c | 152 ++
 drivers/iommu/intel-iommu.c   |   4 +
 3 files changed, 157 insertions(+)
 create mode 100644 drivers/iommu/intel-iommu-debug.c

diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 1fb6958..fdbaf46 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
 obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
 obj-$(CONFIG_DMAR_TABLE) += dmar.o
 obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o
+obj-$(CONFIG_INTEL_IOMMU_DEBUG) += intel-iommu-debug.o
 obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o
 obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
 obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
new file mode 100644
index 000..8ae0c4d
--- /dev/null
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright © 2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * Authors: Gayatri Kammela 
+ *  Jacob Pan 
+ *
+ */
+
+#define pr_fmt(fmt) "INTEL_IOMMU: " fmt
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "irq_remapping.h"
+
+#define TOTAL_BUS_NR (256) /* full bus range 256 */
+#define DEFINE_SHOW_ATTRIBUTE(__name)  \
+static int __name ## _open(struct inode *inode, struct file *file) \
+{  \
+   return single_open(file, __name ## _show, inode->i_private);\
+}  \
+static const struct file_operations __name ## _fops =  \
+{  \
+   .open   = __name ## _open,  \
+   .read   = seq_read, \
+   .llseek = seq_lseek,\
+   .release= single_release,   \
+   .owner  = THIS_MODULE,  \
+}
+
+static void ctx_tbl_entry_show(struct seq_file *m, void *unused,
+  struct intel_iommu *iommu, int bus, bool ext,
+  bool new_ext)
+{
+   struct context_entry *context;
+   int ctx;
+   unsigned long flags;
+
+   seq_printf(m, "%s Context table entries for Bus: %d\n",
+  ext ? "Lower" : "", bus);
+   seq_printf(m, "[entry]\tDID :B :D .F\tLow\t\tHigh\n");
+
+   spin_lock_irqsave(>lock, flags);
+
+   /* Publish either context entries or extended contenxt entries */
+   for (ctx = 0; ctx < (ext ? 128 : 256); ctx++) {
+   context = iommu_context_addr(iommu, bus, ctx, 0);
+   if (!context)
+   goto out;
+   if (context_present(context)) {
+   seq_printf(m, "[%d]\t%04x:%02x:%02x.%02x\t%llx\t%llx\n",
+  ctx, iommu->segment, bus, PCI_SLOT(ctx),
+  PCI_FUNC(ctx), context[0].lo, context[0].hi);
+   }

[PATCH v3 4/6] iommu/vt-d: Add debugfs extension to show register contents

[Sohil Mehta]

From: Gayatri Kammela 

Debugfs extension to dump all the register contents for each IOMMU
device to the user space via debugfs.

example:
root@OTC-KBLH-01:~# cat /sys/kernel/debug/intel_iommu/iommu_regset

DMAR: dmar1: reg_base_addr fed9
Name Offset Contents
VER  0x00   0x0010
CAP  0x08   0x01cc40660462
ECAP 0x10   0x019e2ff0505e
GCMD 0x18   0x
GSTS 0x1c   0xc700
RTADDR   0x20   0x0004558d6800
CCMD 0x28   0x0800
FSTS 0x34   0x
FECTL0x38   0x
FEDATA   0x3c   0xfee0100c4141

Cc: Sohil Mehta 
Cc: Fenghua Yu 
Cc: Jacob Pan 
Cc: Ashok Raj 
Signed-off-by: Gayatri Kammela 
---

v3: Use a macro for seq file operations 
Change the intel_iommu_regset file name to iommu_regset
Add information for MTRR registers

v2: Fix seq_printf formatting

 drivers/iommu/intel-iommu-debug.c | 86 +++
 include/linux/intel-iommu.h   |  2 +
 2 files changed, 88 insertions(+)

diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
index 8e7f5d2..0951d58 100644
--- a/drivers/iommu/intel-iommu-debug.c
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -163,6 +163,84 @@ static int dmar_translation_struct_show(struct seq_file 
*m, void *unused)
 
 DEFINE_SHOW_ATTRIBUTE(dmar_translation_struct);
 
+static int iommu_regset_show(struct seq_file *m, void *unused)
+{
+   struct dmar_drhd_unit *drhd;
+   struct intel_iommu *iommu;
+   unsigned long long base;
+   int i;
+   struct regset {
+   int offset;
+   char *regs;
+   };
+
+   static const struct regset regstr[] = {{DMAR_VER_REG, "VER"},
+  {DMAR_CAP_REG, "CAP"},
+  {DMAR_ECAP_REG, "ECAP"},
+  {DMAR_GCMD_REG, "GCMD"},
+  {DMAR_GSTS_REG, "GSTS"},
+  {DMAR_RTADDR_REG, "RTADDR"},
+  {DMAR_CCMD_REG, "CCMD"},
+  {DMAR_FSTS_REG, "FSTS"},
+  {DMAR_FECTL_REG, "FECTL"},
+  {DMAR_FEDATA_REG, "FEDATA"},
+  {DMAR_FEADDR_REG, "FEADDR"},
+  {DMAR_FEUADDR_REG, "FEUADDR"},
+  {DMAR_AFLOG_REG, "AFLOG"},
+  {DMAR_PMEN_REG, "PMEN"},
+  {DMAR_PLMBASE_REG, "PLMBASE"},
+  {DMAR_PLMLIMIT_REG, "PLMLIMIT"},
+  {DMAR_PHMBASE_REG, "PHMBASE"},
+  {DMAR_PHMLIMIT_REG,  "PHMLIMIT"},
+  {DMAR_IQH_REG, "IQH"},
+  {DMAR_IQT_REG, "IQT"},
+  {DMAR_IQ_SHIFT, "IQ"},
+  {DMAR_IQA_REG, "IQA"},
+  {DMAR_ICS_REG, "ICS"},
+  {DMAR_IRTA_REG, "IRTA"},
+  {DMAR_PQH_REG, "PQH"},
+  {DMAR_PQT_REG, "PQT"},
+  {DMAR_PQA_REG, "PQA"},
+  {DMAR_PRS_REG, "PRS"},
+  {DMAR_PECTL_REG, "PECTL"},
+  {DMAR_PEDATA_REG, "PEDATA"},
+  {DMAR_PEADDR_REG, "PEADDR"},
+  {DMAR_PEUADDR_REG, "PEUADDR"},
+  {DMAR_MTRRCAP_REG, "MTRRCAP"},
+  {DMAR_MTRRDEF_REG, "MTRRDEF"} };
+
+   rcu_read_lock();
+   for_each_active_iommu(iommu, drhd) {
+   if (iommu) {
+   if (!drhd->reg_base_addr) {
+   seq_printf(m, "IOMMU: Invalid base address\n");
+   rcu_read_unlock();
+   return -EINVAL;
+   }
+
+   base = drhd->reg_base_addr;
+   seq_printf(m, "\nDMAR: %s: reg_base_addr %llx\n",
+  iommu->name, base);
+   seq_printf(m, 

[PATCH v3 1/6] iommu/vt-d: Add debugfs support for Intel IOMMU internals

[Sohil Mehta]

From: Gayatri Kammela 

Enable Intel IOMMU debug to export Intel IOMMU internals in debugfs

Cc: Sohil Mehta 
Cc: Fenghua Yu 
Cc: Ashok Raj 
Signed-off-by: Jacob Pan 
Signed-off-by: Gayatri Kammela 
---

v3: No change

v2: No change

 drivers/iommu/Kconfig   | 10 ++
 drivers/iommu/intel-iommu.c | 31 +++
 include/linux/intel-iommu.h | 32 
 include/linux/intel-svm.h   |  2 +-
 4 files changed, 46 insertions(+), 29 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index f3a2134..d7588ee 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -152,6 +152,16 @@ config INTEL_IOMMU
  and include PCI device scope covered by these DMA
  remapping devices.
 
+config INTEL_IOMMU_DEBUG
+   bool "Export Intel IOMMU internals in DebugFS"
+   depends on INTEL_IOMMU && DEBUG_FS
+   default n
+   help
+ IOMMU internal states such as context, PASID tables can be seen via
+ debugfs. Select this option if you want to export these internals.
+
+ Say Y if you need this.
+
 config INTEL_IOMMU_SVM
bool "Support for Shared Virtual Memory with Intel IOMMU"
depends on INTEL_IOMMU && X86
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 6784a05..419a559 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -185,16 +185,6 @@ static int rwbf_quirk;
 static int force_on = 0;
 int intel_iommu_tboot_noforce;
 
-/*
- * 0: Present
- * 1-11: Reserved
- * 12-63: Context Ptr (12 - (haw-1))
- * 64-127: Reserved
- */
-struct root_entry {
-   u64 lo;
-   u64 hi;
-};
 #define ROOT_ENTRY_NR (VTD_PAGE_SIZE/sizeof(struct root_entry))
 
 /*
@@ -220,21 +210,6 @@ static phys_addr_t root_entry_uctp(struct root_entry *re)
 
return re->hi & VTD_PAGE_MASK;
 }
-/*
- * low 64 bits:
- * 0: present
- * 1: fault processing disable
- * 2-3: translation type
- * 12-63: address space root
- * high 64 bits:
- * 0-2: address width
- * 3-6: aval
- * 8-23: domain id
- */
-struct context_entry {
-   u64 lo;
-   u64 hi;
-};
 
 static inline void context_clear_pasid_enable(struct context_entry *context)
 {
@@ -261,7 +236,7 @@ static inline bool __context_present(struct context_entry 
*context)
return (context->lo & 1);
 }
 
-static inline bool context_present(struct context_entry *context)
+bool context_present(struct context_entry *context)
 {
return context_pasid_enabled(context) ?
 __context_present(context) :
@@ -821,7 +796,7 @@ static void domain_update_iommu_cap(struct dmar_domain 
*domain)
domain->iommu_superpage = domain_update_iommu_superpage(NULL);
 }
 
-static inline struct context_entry *iommu_context_addr(struct intel_iommu 
*iommu,
+struct context_entry *iommu_context_addr(struct intel_iommu *iommu,
   u8 bus, u8 devfn, int 
alloc)
 {
struct root_entry *root = >root_entry[bus];
@@ -5200,7 +5175,7 @@ static void intel_iommu_put_resv_regions(struct device 
*dev,
 
 #ifdef CONFIG_INTEL_IOMMU_SVM
 #define MAX_NR_PASID_BITS (20)
-static inline unsigned long intel_iommu_get_pts(struct intel_iommu *iommu)
+unsigned long intel_iommu_get_pts(struct intel_iommu *iommu)
 {
/*
 * Convert ecap_pss to extend context entry pts encoding, also
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 485a5b4..defbc32 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -382,6 +382,33 @@ struct pasid_entry;
 struct pasid_state_entry;
 struct page_req_dsc;
 
+/*
+ * 0: Present
+ * 1-11: Reserved
+ * 12-63: Context Ptr (12 - (haw-1))
+ * 64-127: Reserved
+ */
+struct root_entry {
+   u64 lo;
+   u64 hi;
+};
+
+/*
+ * low 64 bits:
+ * 0: present
+ * 1: fault processing disable
+ * 2-3: translation type
+ * 12-63: address space root
+ * high 64 bits:
+ * 0-2: address width
+ * 3-6: aval
+ * 8-23: domain id
+ */
+struct context_entry {
+   u64 lo;
+   u64 hi;
+};
+
 struct intel_iommu {
void __iomem*reg; /* Pointer to hardware regs, virtual addr */
u64 reg_phys; /* physical address of hw register set */
@@ -487,8 +514,13 @@ struct intel_svm {
 
 extern int intel_iommu_enable_pasid(struct intel_iommu *iommu, struct 
intel_svm_dev *sdev);
 extern struct intel_iommu *intel_svm_device_to_iommu(struct device *dev);
+extern unsigned long intel_iommu_get_pts(struct intel_iommu *iommu);
 #endif
 
 extern const struct attribute_group *intel_iommu_groups[];
+extern void intel_iommu_debugfs_init(void);
+extern bool context_present(struct context_entry *context);
+extern struct context_entry *iommu_context_addr(struct intel_iommu *iommu,
+   

[PATCH v3 3/6] iommu/vt-d: Add Intel IOMMU debugfs to show extended context internals

[Sohil Mehta]

From: Gayatri Kammela 

Debugfs extension to dump internals such as extended context table
entries for each IOMMU to the userspace.

root@OTC-KBLH-01:~# cat
/sys/kernel/debug/intel_iommu/dmar_translation_struct

IOMMU dmar1: Extended Root Table Addr:4558a1800
Extended Root tbl entries:
Bus 0 L: 4558a6001 H: 0
Lower Context table entries for Bus: 0
[entry] DID :B :D .FLow High
[16]:00:02.00   4558a5005   102
Higher Context tbl entries for Bus: 0
[16]:00:02.00   401bc   40140

IOMMU dmar0: Extended Root Table Addr:4558a2800
Extended Root tbl entries:
Bus 0 L: 4016f4001 H: 0
Lower Context table entries for Bus: 0
[entry] DID :B :D .FLow High
[80]:00:0a.00   4016f3a05   102
Higher Context tbl entries for Bus: 0
[80]:00:0a.00   4015c   671b8000

Cc: Sohil Mehta 
Cc: Fenghua Yu 
Cc: Jacob Pan 
Cc: Ashok Raj 
Signed-off-by: Gayatri Kammela 
---

v3: No change

v2: No change

 drivers/iommu/intel-iommu-debug.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
index 8ae0c4d..8e7f5d2 100644
--- a/drivers/iommu/intel-iommu-debug.c
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -46,6 +46,38 @@ static const struct file_operations __name ## _fops =
\
.owner  = THIS_MODULE,  \
 }
 
+#ifdef CONFIG_INTEL_IOMMU_SVM
+static void ext_ctx_tbl_entry_show(struct seq_file *m, void *unused,
+  struct intel_iommu *iommu, int bus, int ctx,
+  struct context_entry *context, bool new_ext)
+{
+   u64 ctx_lo;
+
+   if (new_ext) {
+   seq_printf(m, "Higher Context tbl entries for Bus: %d\n", bus);
+   ctx_lo = context[0].lo;
+
+   if (!(ctx_lo & CONTEXT_PASIDE)) {
+   context[1].hi = (u64)virt_to_phys(
+   iommu->pasid_state_table);
+   context[1].lo = (u64)virt_to_phys(iommu->pasid_table) |
+   intel_iommu_get_pts(iommu);
+   }
+
+   seq_printf(m, "[%d]\t%04x:%02x:%02x.%02x\t%llx\t%llx\n", ctx,
+  iommu->segment, bus, PCI_SLOT(ctx), PCI_FUNC(ctx),
+  context[1].lo, context[1].hi);
+   }
+}
+#else /* CONFIG_INTEL_IOMMU_SVM */
+static void ext_ctx_tbl_entry_show(struct seq_file *m, void *unused,
+  struct intel_iommu *iommu, int bus, int ctx,
+  struct context_entry *context, bool new_ext)
+{
+   return;
+}
+#endif /* CONFIG_INTEL_IOMMU_SVM */
+
 static void ctx_tbl_entry_show(struct seq_file *m, void *unused,
   struct intel_iommu *iommu, int bus, bool ext,
   bool new_ext)
@@ -69,6 +101,9 @@ static void ctx_tbl_entry_show(struct seq_file *m, void 
*unused,
seq_printf(m, "[%d]\t%04x:%02x:%02x.%02x\t%llx\t%llx\n",
   ctx, iommu->segment, bus, PCI_SLOT(ctx),
   PCI_FUNC(ctx), context[0].lo, context[0].hi);
+
+   ext_ctx_tbl_entry_show(m, unused, iommu, bus, ctx,
+  context, new_ext);
}
}
 out:
-- 
2.7.4

[PATCH v3 5/6] iommu/vt-d: Add debugfs extension to show Pasid table contents

[Sohil Mehta]

From: Gayatri Kammela 

Debugfs extension to dump the internals such as pasid table entries for
each IOMMU to the userspace.

Example of such dump in Kabylake:

root@OTC-KBLH-01:~# cat
/sys/kernel/debug/intel_iommu/dmar_translation_struct

IOMMU dmar0: Extended Root Table Addr:4310c4800
Extended Root tbl entries:
Bus 0 L: 3ff5a8001 H: 0
Lower Context table entries for Bus: 0
[entry] DID :B :D .FLow High
[80]:00:0a.00   3ff5a9a05   102
Higher Context tbl entries for Bus: 0
[80]:00:0a.00   4016c   72514000
Pasid Table Addr : 8db2c160
Pasid table entries for domain: 
[Entry] Contents
[0] 26a609801

Cc: Sohil Mehta 
Cc: Fenghua Yu 
Cc: Jacob Pan 
Cc: Ashok Raj 
Signed-off-by: Gayatri Kammela 
---

v3: No change

v2: Fix seq_printf formatting

 drivers/iommu/intel-iommu-debug.c | 32 
 drivers/iommu/intel-svm.c |  8 
 include/linux/intel-svm.h |  8 
 3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
index 0951d58..66a99f5 100644
--- a/drivers/iommu/intel-iommu-debug.c
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -47,6 +47,31 @@ static const struct file_operations __name ## _fops =
\
 }
 
 #ifdef CONFIG_INTEL_IOMMU_SVM
+static void pasid_tbl_entry_show(struct seq_file *m, void *unused,
+struct intel_iommu *iommu)
+{
+   int pasid_size = 0, i;
+
+   if (ecap_pasid(iommu->ecap)) {
+   pasid_size = intel_iommu_get_pts(iommu);
+   seq_printf(m, "Pasid Table Addr : %p\n", iommu->pasid_table);
+
+   if (iommu->pasid_table) {
+   seq_printf(m, "Pasid table entries for domain %d:\n",
+  iommu->segment);
+   seq_printf(m, "[Entry]\t\tContents\n");
+
+   /* Publish the pasid table entries here */
+   for (i = 0; i < pasid_size; i++) {
+   if (!iommu->pasid_table[i].val)
+   continue;
+   seq_printf(m, "[%d]\t\t%04llx\n", i,
+  iommu->pasid_table[i].val);
+   }
+   }
+   }
+}
+
 static void ext_ctx_tbl_entry_show(struct seq_file *m, void *unused,
   struct intel_iommu *iommu, int bus, int ctx,
   struct context_entry *context, bool new_ext)
@@ -70,6 +95,12 @@ static void ext_ctx_tbl_entry_show(struct seq_file *m, void 
*unused,
}
 }
 #else /* CONFIG_INTEL_IOMMU_SVM */
+static void pasid_tbl_entry_show(struct seq_file *m, void *unused,
+struct intel_iommu *iommu)
+{
+   return;
+}
+
 static void ext_ctx_tbl_entry_show(struct seq_file *m, void *unused,
   struct intel_iommu *iommu, int bus, int ctx,
   struct context_entry *context, bool new_ext)
@@ -106,6 +137,7 @@ static void ctx_tbl_entry_show(struct seq_file *m, void 
*unused,
   context, new_ext);
}
}
+   pasid_tbl_entry_show(m, unused, iommu);
 out:
spin_unlock_irqrestore(>lock, flags);
 }
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index f6697e5..2003f23 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -28,14 +28,6 @@
 
 static irqreturn_t prq_event_thread(int irq, void *d);
 
-struct pasid_entry {
-   u64 val;
-};
-
-struct pasid_state_entry {
-   u64 val;
-};
-
 int intel_svm_alloc_pasid_tables(struct intel_iommu *iommu)
 {
struct page *pages;
diff --git a/include/linux/intel-svm.h b/include/linux/intel-svm.h
index 733eaf9..a8abad6 100644
--- a/include/linux/intel-svm.h
+++ b/include/linux/intel-svm.h
@@ -18,6 +18,14 @@
 
 struct device;
 
+struct pasid_entry {
+   u64 val;
+};
+
+struct pasid_state_entry {
+   u64 val;
+};
+
 struct svm_dev_ops {
void (*fault_cb)(struct device *dev, int pasid, u64 address,
 u32 private, int rwxp, int response);
-- 
2.7.4

[PATCH v3 0/6] Intel IOMMU debugfs support

[Sohil Mehta]

Hi all,

This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU
registers, internal context and dumps individual table entries to help debug
Intel IOMMUs.

The first patch does the ground work for the following patches by creating a
new Kconfig option - INTEL_IOMMU_DEBUG. It also reorganizes some Intel IOMMU
data structures. The next five patches add debugfs support for IOMMU context
internals, extended context, register contents, PASID internals, and Interrupt
remapping in that order. The information can be accessed in sysfs at
'/sys/kernel/debug/intel_iommu/'.

Regards,
Sohil

Changes since v2:
 - Added a macro for seq file operations based on recommendation by Andy 
   Shevchenko. The marco can be moved to seq_file.h at a future point
 - Changed the debugfs file names to more relevant ones
 - Added information for MTRR registers in the regset file

Changes since v1:
 - Fixed seq_printf formatting
 - Handled the case when Interrupt remapping is not enabled

Gayatri Kammela (5):
  iommu/vt-d: Add debugfs support for Intel IOMMU internals
  iommu/vt-d: Add Intel IOMMU debugfs to show context internals
  iommu/vt-d: Add Intel IOMMU debugfs to show extended context internals
  iommu/vt-d: Add debugfs extension to show register contents
  iommu/vt-d: Add debugfs extension to show Pasid table contents

Sohil Mehta (1):
  iommu/vt-d: Add debugfs support for Intel IOMMU Interrupt remapping

 drivers/iommu/Kconfig |  10 +
 drivers/iommu/Makefile|   1 +
 drivers/iommu/intel-iommu-debug.c | 417 ++
 drivers/iommu/intel-iommu.c   |  35 +---
 drivers/iommu/intel-svm.c |   8 -
 include/linux/intel-iommu.h   |  34 
 include/linux/intel-svm.h |  10 +-
 7 files changed, 478 insertions(+), 37 deletions(-)
 create mode 100644 drivers/iommu/intel-iommu-debug.c

-- 
2.7.4

[PATCH v3 6/6] iommu/vt-d: Add debugfs support for Intel IOMMU Interrupt remapping

[Sohil Mehta]

Debugfs extension for Intel IOMMU to dump Interrupt remapping table
entries for Interrupt remapping and Interrupt posting.

The file /sys/kernel/debug/intel_iommu/ir_translation_struct provides
detailed information, such as Index, Source Id, Destination Id, Vector
and the raw values for entries with the present bit set, in the format
shown.

Remapped Interrupt supported on IOMMU: dmar5
 IR table address:93e09d54c310
---
 Index  SID  Dest_ID  Vct Raw_value_high   Raw_value_low
 1  3a00 0600 2c  00043a00 062c0009
 1114301 0900 a2  00044301 09a20009

Posted Interrupt supported on IOMMU: dmar5
 IR table address:93e09d54c310

 Index  SID  PDA_high PDA_low  Vct Raw_value_high   Raw_value_low
 4  4300 0010 40c7c880 41  00144300 40c7c88000418001
 5  4300 0010 40c7c880 51  00144300 40c7c88000518001

Cc: Gayatri Kammela 
Cc: Jacob Pan 
Cc: Fenghua Yu 
Cc: Ashok Raj 
Signed-off-by: Sohil Mehta 
---

v3: Use a macro for seq file operations 
Change the intel_iommu_interrupt_remap file name to ir_translation_struct

v2: Handle the case when IR is not enabled. Fix seq_printf formatting

 drivers/iommu/intel-iommu-debug.c | 112 ++
 1 file changed, 112 insertions(+)

diff --git a/drivers/iommu/intel-iommu-debug.c 
b/drivers/iommu/intel-iommu-debug.c
index 66a99f5..8803277 100644
--- a/drivers/iommu/intel-iommu-debug.c
+++ b/drivers/iommu/intel-iommu-debug.c
@@ -12,6 +12,7 @@
  *
  * Authors: Gayatri Kammela 
  *  Jacob Pan 
+ *  Sohil Mehta 
  *
  */
 
@@ -273,6 +274,108 @@ static int iommu_regset_show(struct seq_file *m, void 
*unused)
 
 DEFINE_SHOW_ATTRIBUTE(iommu_regset);
 
+#ifdef CONFIG_IRQ_REMAP
+static void ir_tbl_remap_entry_show(struct seq_file *m, void *unused,
+   struct intel_iommu *iommu)
+{
+   int idx;
+   struct irte *ri_entry;
+
+   /* Print the header only once */
+   seq_printf(m, " Index  SID  Dest_ID  Vct"
+  " Raw_value_high   Raw_value_low\n");
+
+   for (idx = 0; idx < INTR_REMAP_TABLE_ENTRIES; idx++) {
+   ri_entry = >ir_table->base[idx];
+   if (!ri_entry->present || ri_entry->p_pst)
+   continue;
+   seq_printf(m,
+  " %d\t%04x %08x %02x  %016llx %016llx\n",
+  idx, ri_entry->sid,
+  ri_entry->dest_id, ri_entry->vector,
+  ri_entry->high, ri_entry->low);
+   }
+}
+
+static void ir_tbl_posted_entry_show(struct seq_file *m, void *unused,
+struct intel_iommu *iommu)
+{
+   int idx;
+   struct irte *pi_entry;
+
+   /* Print the header only once */
+   seq_printf(m, " Index  SID  PDA_high PDA_low  Vct"
+  " Raw_value_high   Raw_value_low\n");
+
+   for (idx = 0; idx < INTR_REMAP_TABLE_ENTRIES; idx++) {
+   pi_entry = >ir_table->base[idx];
+   if (!pi_entry->present || !pi_entry->p_pst)
+   continue;
+   seq_printf(m,
+  " %d\t%04x %08x %08x %02x  %016llx %016llx\n",
+  idx, pi_entry->sid,
+  pi_entry->pda_h, (pi_entry->pda_l)<<6,
+  pi_entry->vector, pi_entry->high,
+  pi_entry->low);
+   }
+}
+
+/*
+ * For active IOMMUs go through the Interrupt remapping
+ * table and print valid entries in a table format for
+ * Remapped and Posted Interrupts.
+ */
+static int ir_translation_struct_show(struct seq_file *m, void *unused)
+{
+   struct dmar_drhd_unit *drhd;
+   struct intel_iommu *iommu;
+
+   rcu_read_lock();
+   for_each_active_iommu(iommu, drhd) {
+   if (!iommu || !ecap_ir_support(iommu->ecap))
+   continue;
+
+   seq_printf(m,
+  "\nRemapped Interrupt supported on IOMMU: %s\n"
+  " IR table address:%p\n",
+  iommu->name, iommu->ir_table);
+
+   seq_printf(m, "---"
+  "\n");
+
+   if (iommu->ir_table)
+   ir_tbl_remap_entry_show(m, unused, iommu);
+   else
+   seq_printf(m, "Interrupt Remapping is not enabled\n");
+   }
+
+   seq_printf(m, "\n\t\t\t\t\t\t\t\n");
+
+   for_each_active_iommu(iommu, drhd) {
+   if (!iommu || 

Re: [PATCHv4 5/6] symbol lookup: introduce dereference_symbol_descriptor()

[Sergey Senozhatsky]

Hello,

so we got a number of build-error reports [somehow I
thought 0day has compile tested the patches already; well, I
was wrong] basically on congifs that have no KALLSYMS.


Petr, can we replace 0006 with the following patch?

8<--- --- ---

From: Sergey Senozhatsky 
Subject: [PATCH] symbol lookup: introduce dereference_symbol_descriptor()

dereference_symbol_descriptor() invokes appropriate ARCH specific
function descriptor dereference callbacks:
- dereference_kernel_function_descriptor() if the pointer is a
  kernel symbol;

- dereference_module_function_descriptor() if the pointer is a
  module symbol.

This is the last step needed to make '%pS/%ps' smart enough to
handle function descriptor dereference on affected ARCHs and
to retire '%pF/%pf'.

To refresh it:
  Some architectures (ia64, ppc64, parisc64) use an indirect pointer
  for C function pointers - the function pointer points to a function
  descriptor and we need to dereference it to get the actual function
  pointer.

  Function descriptors live in .opd elf section and all affected
  ARCHs (ia64, ppc64, parisc64) handle it properly for kernel and
  modules. So we, technically, can decide if the dereference is
  needed by simply looking at the pointer: if it belongs to .opd
  section then we need to dereference it.

  The kernel and modules have their own .opd sections, obviously,
  that's why we need to split dereference_function_descriptor()
  and use separate kernel and module dereference arch callbacks.

Signed-off-by: Sergey Senozhatsky 
---
 Documentation/printk-formats.txt | 42 ---
 include/linux/kallsyms.h | 53 
 kernel/kallsyms.c| 33 -
 lib/vsprintf.c   |  5 ++--
 4 files changed, 71 insertions(+), 62 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index aa0a776c817a..02745028e909 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -61,41 +61,31 @@ Symbols/Function Pointers
 
 ::
 
-   %pF versatile_init+0x0/0x110
-   %pf versatile_init
-   %pS versatile_init+0x0/0x110
-   %pSRversatile_init+0x9/0x110
+   %pS versatile_init+0x0/0x110
+   %ps versatile_init
+   %pF versatile_init+0x0/0x110
+   %pf versatile_init
+   %pSRversatile_init+0x9/0x110
(with __builtin_extract_return_addr() translation)
-   %ps versatile_init
-   %pB prev_fn_of_versatile_init+0x88/0x88
+   %pB prev_fn_of_versatile_init+0x88/0x88
 
-The ``F`` and ``f`` specifiers are for printing function pointers,
-for example, f->func,  They have the same result as
-``S`` and ``s`` specifiers. But they do an extra conversion on
-ia64, ppc64 and parisc64 architectures where the function pointers
-are actually function descriptors.
+The ``S`` and ``s`` specifiers are used for printing a pointer in symbolic
+format. They result in the symbol name with (``S``) or without (``s``)
+offsets. If KALLSYMS are disabled then the symbol address is printed instead.
 
-The ``S`` and ``s`` specifiers can be used for printing symbols
-from direct addresses, for example, __builtin_return_address(0),
-(void *)regs->ip. They result in the symbol name with (``S``) or
-without (``s``) offsets. If KALLSYMS are disabled then the symbol
-address is printed instead.
+Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
+and thus deprecated. We have ``F`` and ``f`` because on ia64, ppc64 and
+parisc64 function pointers are indirect and, in fact, are function
+descriptors, which require additional dereferencing before we can lookup
+the symbol. As of now, ``S`` and ``s`` perform dereferencing on those
+platforms (when needed), so ``F`` and ``f`` exist for compatibility
+reasons only.
 
 The ``B`` specifier results in the symbol name with offsets and should be
 used when printing stack backtraces. The specifier takes into
 consideration the effect of compiler optimisations which may occur
 when tail-call``s are used and marked with the noreturn GCC attribute.
 
-Examples::
-
-   printk("Going to call: %pF\n", gettimeofday);
-   printk("Going to call: %pF\n", p->func);
-   printk("%s: called from %pS\n", __func__, (void *)_RET_IP_);
-   printk("%s: called from %pS\n", __func__,
-   (void *)__builtin_return_address(0));
-   printk("Faulted at %pS\n", (void *)regs->ip);
-   printk(" %s%pB\n", (reliable ? "" : "? "), (void *)*stack);
-
 Kernel Pointers
 ===
 
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index bd118a6c60cb..1bcfe221e62c 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -9,6 +9,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 #define KSYM_NAME_LEN 128
 #define 

Re: [PATCH v6 2/2] media: i2c: Add the ov7740 image sensor driver

[Yang, Wenyou]

Hi Sakari,


On 2017/12/5 18:45, Sakari Ailus wrote:

Hi Wenyou,

On Mon, Dec 04, 2017 at 02:58:58PM +0800, Wenyou Yang wrote:

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v6:
  - Remove unnecessary #include .
  - Remove unnecessary comments and extra newline.
  - Add const for some structures.
  - Add the check of the return value from regmap_write().
  - Simplify the calling of __v4l2_ctrl_handler_setup().
  - Add the default format initialization function.
  - Integrate the set_power() and enable/disable the clock into
one function.

Changes in v5:
  - Squash the driver and MAINTAINERS entry patches to one.
  - Precede the driver patch with the bindings patch.

Changes in v4:
  - Assign 'val' a initial value to avoid warning: 'val' may be
used uninitialized.
  - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
  - Put the MAINTAINERS change to a separate patch.

Changes in v2:
  - Split off the bindings into a separate patch.
  - Add a new entry to the MAINTAINERS file.

  MAINTAINERS|8 +
  drivers/media/i2c/Kconfig  |8 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov7740.c | 1226 
  4 files changed, 1243 insertions(+)
  create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7a52a66aa991..1de965009b13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
  F:drivers/media/i2c/ov7670.c
  F:Documentation/devicetree/bindings/media/i2c/ov7670.txt
  
+OMNIVISION OV7740 SENSOR DRIVER

+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
  ONENAND FLASH DRIVER
  M:Kyungmin Park 
  L:linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff82915..00b1c4c031d4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
  
+config VIDEO_OV7740

+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
  config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
  obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..42c25277d005
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1226 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */
+#define REG_HAEC 

Re: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device

[Wu Hao]

On Tue, Dec 05, 2017 at 11:00:22AM -0600, Alan Tull wrote:
> On Mon, Dec 4, 2017 at 9:33 PM, Wu Hao  wrote:
> > On Mon, Dec 04, 2017 at 01:46:59PM -0600, Alan Tull wrote:
> >> On Mon, Nov 27, 2017 at 9:15 PM, Wu Hao  wrote:
> >> > On Mon, Nov 27, 2017 at 10:28:04AM +, David Laight wrote:
> >> >> From: Wu Hao
> >> >> > Sent: 27 November 2017 06:42
> >> >> > From: Zhang Yi 
> >> >> >
> >> >> > The Intel FPGA device appears as a PCIe device on the system. This 
> >> >> > patch
> >> >> > implements the basic framework of the driver for Intel PCIe device 
> >> >> > which
> >> >> > is located between CPU and Accelerated Function Units (AFUs), and has
> >> >> > the Device Feature List (DFL) implemented in its MMIO space.
> >> >>
> >> >> This ought to have a better name than 'Intel FPGA'.
> >> >> An fpga can be used for all sorts of things, this looks like
> >> >> a very specific architecture using a common VHDL environment to
> >> >> allow certain types of user VHDL be accessed over PCIe.
> >> >
> >> > Hi David
> >> >
> >> > This patch adds a pcie device driver for Intel FPGA devices which 
> >> > implements
> >> > the DFL, e.g Intel Server Platform with In-package FPGA and Intel FPGA 
> >> > PCIe
> >> > Acceleration Cards. They are pcie devices, and all have DFL implemented 
> >> > in
> >> > the MMIO space, so we would like to use one kernel driver to handle them.
> >> >
> >> > With this full patchset, it just provides user the interfaces to 
> >> > configure
> >> > and access the FPGA accelerators on Intel DFL based FPGA devices. For 
> >> > sure,
> >> > users can develop and build their own logics via tools provided by Intel,
> >> > program them to accelerators on these Intel FPGA devices, and access them
> >> > for their workloads.
> >>
> >> I don't see anything Intel specific here.  This could all be named dfl-*
> >
> > The maybe some device specific things, e.g Intel FPGA devices supported by 
> > this
> > driver always have FME DFL at the beginning on the BAR0 for PF device.
> >
> > But I think this should be the right direction for better code reuse, it 
> > could
> > save efforts for other vendors who want to use DFL and follow the same way.
> >
> > Thanks for the comments. I will rename this driver in the next version.
> 
> Thanks!
> 
> Regarding file names, it seems like the files added to drivers/fpga
> could be uniformly named dfl-*.[ch].  Some are fpga-dfl-*.[ch] while
> other are currently dfl-*.[ch] currently.

Sure, will have all related drivers files renamed to dfl-*.[ch].

Thanks
Hao

> 
> Alan
> 
> >
> > Hao

Re: [PATCH] drm: rcar-du: calculate DPLLCR to be more small jitter

[Kuninori Morimoto]

Hi

I noticed 1 typo, 1 bug on this patch.
I will post v2 patch

> From: Kuninori Morimoto 
> 
> In general, PLL has VCO (= Voltage controlled oscillator),
> one of the very important electronic feature called as "jitter"
> is related to this VCO.
> In academic generalism, VCO should be maximum to be more small jitter.
> In high frequency clock, jitter will be large impact.
> Thus, selecting Hi VCO is general theory.
> 
>fin fvcofout  fclkout
> in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> out
>  +-> |  | |
>  ||
>  +-[1/N]<-+
> 
>   fclkout = fvco / P / FDPLL -- (1)
> 
> In PD, it will loop until fin/M = fvco/P/N
> 
>   fvco = fin * P *  N / M -- (2)
> 
> (1) + (2) indicates, fclkout = fin * N / M / FDPLL
> In this device, N = (n + 1), M = (m + 1), P = 2, thus
> 
>   fout = fin * (n + 1) / (m + 1) / FDPLL
> 
> This is the datasheet formula.
> One note here is that it should be 2000 < fvco < 4096MHz
> To be smaller jitter, fvco should be maximum,
> in other words, N as large as possible, M as small as possible driver
> should select. Here, basically M=1.
> This patch do it.
> 
> Reported-by: HIROSHI INOSE 
> Signed-off-by: Kuninori Morimoto 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 36 
> --
>  1 file changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index b492063..45540fe 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -125,8 +125,40 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc 
> *rcrtc,
>   unsigned int m;
>   unsigned int n;
>  
> - for (n = 39; n < 120; n++) {
> - for (m = 0; m < 4; m++) {
> + /*
> +  *   fin fvcofout   fclkout
> +  * in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> 
> out
> +  *  +-> |  | |
> +  *  ||
> +  *  +-[1/N]<-+
> +  *
> +  *  fclkout = fvco / P / FDPLL -- (1)
> +  *
> +  * fin/M = fvco/P/N
> +  *
> +  *  fvco = fin * P *  N / M -- (2)
> +  *
> +  * (1) + (2) indicates
> +  *
> +  *  fclkout = fin * N / M / FDPLL
> +  *
> +  * NOTES
> +  *  N = (n + 1), M = (m + 1), P = 2
> +  *  2000 < fvco < 4096Mhz
> +  *  Basically M=1
> +  *
> +  * To be small jitter,
> +  * N : as large as possible
> +  * M : as small as possible
> +  */
> + for (m = 0; m < 4; m++) {
> + for (n = 119; n > 40; n--) {
> + unsigned long long fvco = input * 2 * (n + 1) / (m + 1);
> +
> + if ((fvco < 2000) ||
> + (fvco > 409600ll))
> + continue;
> +
>   for (fdpll = 1; fdpll < 32; fdpll++) {
>   unsigned long output;
>  
> -- 
> 1.9.1
> 

Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver

[Katsuhiro Suzuki]

Hello,

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Tuesday, December 5, 2017 9:15 PM
> To: Suzuki, Katsuhiro/鈴木 勝博 
> Cc: alsa-de...@alsa-project.org; Rob Herring ;
> devicet...@vger.kernel.org; Yamada, Masahiro/山田 真弘
> ; Masami Hiramatsu
> ; Jassi Brar ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
> 
> On Tue, Dec 05, 2017 at 01:48:39PM +0900, Katsuhiro Suzuki wrote:
> 
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns.  Doing this makes your messages much
> easier to read and reply to.
> 

Thank you, I set it.


> > > Is there a mux in the SoC here?
> 
> > Sorry for confusing, It's not mux.
> 
> > uniphier_srcport_reset() resets HW SRC (sampling rate converter) block.
> > Audio data out ports of UniPhier audio system have HW SRC.
> 
> Is the SRC just a single block sitting between the DMA and the external
> audio port or is there more going on?  Some of the other code made me
> think the hardware was more flexible than this (all the writing to
> registers with names like RXSEL for example).
> 

This hardware has 2 types of HW SRC. First type sit before audio port and
cannot change routing. I use it in this driver. Second type is like a loopback,
but this block is not used in this driver to simplify the first version.

Type 1:
  Mem -> DMA -> SRC -> Out Port -> External pin
Type 2:
  Mem -> DMA -> SRC -> Out Port -> In Port -> DMA -> Mem


> > > > +#endif /* CONFIG_SND_SOC_UNIPHIER_LD11 */
> 
> > > Why is there an ifdef here?  There's no other conditional code in here,
> > > it seems pointless.
> 
> > This config is used to support or not LD11 SoC.
> > aio-ld11.c is not build and 'uniphier_aio_ldxx_spec' is undefined if this
config is
> disabled.
> >
> > aio-ld11.c defines SoC dependent resources (port, HW ring buffer, DMA ch,
etc.)
> > and fixed settings.
> > I know it's better to move such information into device-tree, but register
areas of
> > UniPhier's audio system is very strange and interleaved. It's hard to split
each
> nodes...
> 
> I'd expect this code to be structured more like a library - have a
> driver that handles the specific IPs then have it call into a shared
> block of code that does the generic bits.  Though in this case the
> device specific bit looks like a couple of tiny data tables so I'm not
> sure it's worth making it conditional or separate at all.
> 

Sorry... I agree your opinion, but I can't imagine the detail.

I think my driver has structure as follows (ex. startup):
  DAI: uniphier_aio_startup()@aio-core.c
  Lib: uniphier_aio_init()@aio-regctrl.c
  SoC specific: uniphier_aio_ld11_spec@aio-ld11.c

Am I wrong? Would you mean split the functions in aio-regctl.[ch] to other
kernel module? I wonder if you could tell me the example from existing
drivers. I'll try to fix my driver like as it.


> > > This looks awfully like compressed audio support...  should there be
> > > integration with the compressed audio API/
> 
> > Thanks, I'll try it. Is there Documentation in
> sound/designes/compress-offload.rst?
> > And best sample is... Intel's driver?
> 
> Yes.
> 
> > (Summary)
> > I think I should fix as follows:
> 
> >   - Split DMA, DAI patches from large one
> >   - Validate parameters in hw_params
> >   - Add description about HW SRC (or fix bad name 'srcport')
> >   - Add comments about uniphier_aiodma_irq()
> >   - Expose clocking and audio routing to userspace, or at the very
> > least machine driver configuration
> >   - Support compress-audio API for S/PDIF
> 
> > and post V2.
> 
> At least.  I do think we need to get to the bottom of how flexible the
> hardware is first though.

Yes, indeed. This hardware is more flexible and complex, but now I (and our
company) don't use it. Of course, I don't want to hide some features of this
hardware from ALSA people. I should try to upstream all features in the future,
I think.


Regards,
--
Katsuhiro Suzuki

Re: Sending 802.1Q packets using AF_PACKET socket on filtered bridge forwards with wrong MAC addresses

[Toshiaki Makita]

Hi,
(CC: Vlad)

On 2017/11/30 7:01, Brandon Carpenter wrote:
> I narrowed the search to a memmove() called from
> skb_reorder_vlan_header() in net/core/skbuff.c.
> 
>> memmove(skb->data - ETH_HLEN, skb->data - skb->mac_len - VLAN_HLEN,
>>2 * ETH_ALEN);
> 
> Calling skb_reset_mac_len() after skb_reset_mac_header() before
> calling br_allowed_ingress() in net/bridge/br_device.c fixes the
> problem.
> 
> diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> index af5b8c87f590..e10131e2f68f 100644
> --- a/net/bridge/br_device.c
> +++ b/net/bridge/br_device.c
> @@ -58,6 +58,7 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct
> net_device *dev)
> BR_INPUT_SKB_CB(skb)->brdev = dev;
> 
> skb_reset_mac_header(skb);
> +   skb_reset_mac_len(skb);
> eth = eth_hdr(skb);
> skb_pull(skb, ETH_HLEN);

Thanks for debugging this problem.
It seems this has been broken since a6e18ff11170 ("vlan: Fix untag
operations of stacked vlans with REORDER_HEADER off").

Unfortunately this does not always work correctly, since in tx path
drivers assume network header to be set to L3 protocol header offset.
Packet socket (packet_snd()) determines network header by
dev_hard_header which is ETH_HLEN in bridge devices, so this works for
packet socket, but with vlan devices on top of bridge device with
tx-vlan hwaccel disabled we get ETH_HLEN + VLAN_HLEN or longer by mac_len.

Since mac_len can be arbitrarily long if we stack vlan devices on bridge
devices, and since we want to untag the outermost tag, using mac_len to
untag in tx path is probably no longer correct.

I'll think deeper about how to fix it.

> I'll put together an official patch  and submit it. Should I use
> another email account? Are my emails being ignored because of that
> stupid disclaimer my employer attaches to my messages (outside my
> control)?
> 
> Brandon
> 

-- 
Toshiaki Makita

[PATCH] usb: core: Fix logging messages with spurious periods after newlines

[Joe Perches]

Using a period after a newline causes bad output.

Miscellanea:

o Coalesce formats too

Signed-off-by: Joe Perches 
---
 drivers/usb/core/driver.c  |  8 
 drivers/usb/core/hub.c | 17 +++--
 drivers/usb/core/message.c |  6 +++---
 3 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 64262a9a8829..d8d7377b5fb8 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -342,8 +342,8 @@ static int usb_probe_interface(struct device *dev)
if (driver->disable_hub_initiated_lpm) {
lpm_disable_error = usb_unlocked_disable_lpm(udev);
if (lpm_disable_error) {
-   dev_err(>dev, "%s Failed to disable LPM for 
driver %s\n.",
-   __func__, driver->name);
+   dev_err(>dev, "%s Failed to disable LPM for 
driver %s\n",
+   __func__, driver->name);
error = lpm_disable_error;
goto err;
}
@@ -537,8 +537,8 @@ int usb_driver_claim_interface(struct usb_driver *driver,
if (driver->disable_hub_initiated_lpm) {
lpm_disable_error = usb_unlocked_disable_lpm(udev);
if (lpm_disable_error) {
-   dev_err(>dev, "%s Failed to disable LPM for 
driver %s\n.",
-   __func__, driver->name);
+   dev_err(>dev, "%s Failed to disable LPM for 
driver %s\n",
+   __func__, driver->name);
return -ENOMEM;
}
}
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index cf7bbcb9a63c..b95855076f43 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1049,12 +1049,10 @@ static void hub_activate(struct usb_hub *hub, enum 
hub_activation_type type)
ret = hcd->driver->update_hub_device(hcd, hdev,
>tt, GFP_NOIO);
if (ret < 0) {
-   dev_err(hub->intfdev, "Host not "
-   "accepting hub info "
-   "update.\n");
-   dev_err(hub->intfdev, "LS/FS devices "
-   "and hubs may not work "
-   "under this hub\n.");
+   dev_err(hub->intfdev,
+   "Host not accepting hub info 
update\n");
+   dev_err(hub->intfdev,
+   "LS/FS devices and hubs may not 
work under this hub\n");
}
}
hub_power_on(hub, true);
@@ -3157,7 +3155,7 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
usb_set_usb2_hardware_lpm(udev, 0);
 
if (usb_disable_ltm(udev)) {
-   dev_err(>dev, "Failed to disable LTM before suspend\n.");
+   dev_err(>dev, "Failed to disable LTM before suspend\n");
status = -ENOMEM;
if (PMSG_IS_AUTO(msg))
goto err_ltm;
@@ -5484,13 +5482,12 @@ static int usb_reset_and_verify_device(struct 
usb_device *udev)
 */
ret = usb_unlocked_disable_lpm(udev);
if (ret) {
-   dev_err(>dev, "%s Failed to disable LPM\n.", __func__);
+   dev_err(>dev, "%s Failed to disable LPM\n", __func__);
goto re_enumerate_no_bos;
}
ret = usb_disable_ltm(udev);
if (ret) {
-   dev_err(>dev, "%s Failed to disable LTM\n.",
-   __func__);
+   dev_err(>dev, "%s Failed to disable LTM\n", __func__);
goto re_enumerate_no_bos;
}
 
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index f836bae1e485..dac4adeec213 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1356,7 +1356,7 @@ int usb_set_interface(struct usb_device *dev, int 
interface, int alternate)
 * so that the xHCI driver can recalculate the U1/U2 timeouts.
 */
if (usb_disable_lpm(dev)) {
-   dev_err(>dev, "%s Failed to disable LPM\n.", __func__);
+   dev_err(>dev, "%s Failed to disable LPM\n", __func__);
mutex_unlock(hcd->bandwidth_mutex);
return -ENOMEM;
}
@@ -1500,7 +1500,7 @@ int usb_reset_configuration(struct usb_device *dev)
 * that the xHCI driver can recalculate the U1/U2 timeouts.
 */
if (usb_disable_lpm(dev)) {
-   dev_err(>dev, "%s Failed to 

Re: [PATCH] bfa: fix access to bfad_im_port_s

[James Bottomley]

On Tue, 2017-11-28 at 16:26 +0100, Johannes Thumshirn wrote:
> Commit 'cd21c605b2cf ("scsi: fc: provide fc_bsg_to_shost() helper")'
> changed access to bfa's 'struct bfad_im_port_s' by using shost_priv()
> instead of shost->hostdata[0].
> 
> This lead to crashes like in the following back-trace:
> 
> task: 880046375300 ti: 8800a2ef8000 task.ti: 8800a2ef8000
> RIP: e030:[]  []
> bfa_fcport_get_attr+0x82/0x260 [bfa]
> RSP: e02b:8800a2efba10  EFLAGS: 00010046
> RAX: 575f415441536432 RBX: 8800a2efba28 RCX: 
> RDX:  RSI: 8800a2efba28 RDI: 880004dc31d8
> RBP: 880004dc31d8 R08:  R09: 0001
> R10: 88011fadc468 R11: 0001 R12: 880004dc31f0
> R13: 0200 R14: 880004dc61d0 R15: 880004947a10
> FS:  7feb1e489700() GS:88011fac()
> knlGS:
> CS:  e033 DS:  ES:  CR0: 8005003b
> CR2: 7ffe14e46c10 CR3: 957b8000 CR4: 0660
> Stack:
>  88001d4da000 880004dc31c0 a048a9df 81e56380
>     
> [] bfad_iocmd_ioc_get_info+0x4f/0x220 [bfa]
> [] bfad_iocmd_handler+0xa00/0xd40 [bfa]
> [] bfad_im_bsg_request+0xee/0x1b0 [bfa]
> [] fc_bsg_dispatch+0x10b/0x1b0 [scsi_transport_fc]
> [] bsg_request_fn+0x11d/0x1c0
> [] __blk_run_queue+0x2f/0x40
> [] blk_execute_rq_nowait+0xa8/0x160
> [] blk_execute_rq+0x77/0x120
> [] bsg_ioctl+0x1b6/0x200
> [] do_vfs_ioctl+0x2cd/0x4a0
> [] SyS_ioctl+0x74/0x80
> [] entry_SYSCALL_64_fastpath+0x12/0x6d
> 
> Fixes: cd21c605b2cf ("scsi: fc: provide fc_bsg_to_shost() helper")
> Signed-off-by: Johannes Thumshirn 
> Cc: Michal Koutný 
> ---
>  drivers/scsi/bfa/bfad_bsg.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/bfa/bfad_bsg.c
> b/drivers/scsi/bfa/bfad_bsg.c
> index 72ca2a2e08e2..09ef68c8225f 100644
> --- a/drivers/scsi/bfa/bfad_bsg.c
> +++ b/drivers/scsi/bfa/bfad_bsg.c
> @@ -3135,7 +3135,8 @@ bfad_im_bsg_vendor_request(struct bsg_job *job)
>   struct fc_bsg_request *bsg_request = job->request;
>   struct fc_bsg_reply *bsg_reply = job->reply;
>   uint32_t vendor_cmd = bsg_request-
> >rqst_data.h_vendor.vendor_cmd[0];
> - struct bfad_im_port_s *im_port =
> shost_priv(fc_bsg_to_shost(job));
> + struct Scsi_Host *shost = fc_bsg_to_shost(job);
> + struct bfad_im_port_s *im_port = shost->hostdata[0];
>   struct bfad_s *bfad = im_port->bfad;
>   void *payload_kbuf;
>   int rc = -EINVAL;
> @@ -3350,7 +3351,8 @@ int
>  bfad_im_bsg_els_ct_request(struct bsg_job *job)
>  {
>   struct bfa_bsg_data *bsg_data;
> - struct bfad_im_port_s *im_port =
> shost_priv(fc_bsg_to_shost(job));
> + struct Scsi_Host *shost = fc_bsg_to_shost(job);
> + struct bfad_im_port_s *im_port = shost->hostdata[0];
>   struct bfad_s *bfad = im_port->bfad;
>   bfa_bsg_fcpt_t *bsg_fcpt;
>   struct bfad_fcxp*drv_fcxp;

OK, so we had a linux next failure with this:

After merging the scsi tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

drivers/scsi/bfa/bfad_bsg.c: In function 'bfad_im_bsg_vendor_request':
drivers/scsi/bfa/bfad_bsg.c:3137:35: warning: initialization makes pointer 
from integer without a cast [-Wint-conversion]
  struct bfad_im_port_s *im_port = shost->hostdata[0];
   ^
drivers/scsi/bfa/bfad_bsg.c: In function 'bfad_im_bsg_els_ct_request':
drivers/scsi/bfa/bfad_bsg.c:3353:35: warning: initialization makes pointer 
from integer without a cast [-Wint-conversion]
  struct bfad_im_port_s *im_port = shost->hostdata[0];
   ^

Introduced by commit

  45349821ab3a ("scsi: bfa: fix access to bfad_im_port_s")

-- 
Cheers,
Stephen Rothwell

The reason is you should be using shost_priv(shost) not shost->hostdata[0].

James

Re: [PATCH] usb: dwc2: add optional usb ecc reset bit

[John Youn]

On 11/01/2017 08:35 AM, Dinh Nguyen wrote:
> The dwc2 USB controller in Stratix10 has an additional ECC reset bit that
> needs to get de-asserted in order for the controller to work properly.
>
> Signed-off-by: Dinh Nguyen 
> ---
>  drivers/usb/dwc2/core.h |  1 +
>  drivers/usb/dwc2/platform.c | 10 ++
>  2 files changed, 11 insertions(+)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 8367d4f9..a4b5f4e 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -920,6 +920,7 @@ struct dwc2_hsotg {
>   int irq;
>   struct clk *clk;
>   struct reset_control *reset;
> + struct reset_control *reset_ecc;
>
>   unsigned int queuing_high_bandwidth:1;
>   unsigned int srp_success:1;
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index daf0d37..d466e03 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -220,6 +220,15 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg 
> *hsotg)
>
>   reset_control_deassert(hsotg->reset);
>
> + hsotg->reset_ecc = devm_reset_control_get_optional(hsotg->dev, 
> "dwc2-ecc");
> + if (IS_ERR(hsotg->reset_ecc)) {
> + ret = PTR_ERR(hsotg->reset_ecc);
> + dev_err(hsotg->dev, "error getting reset control for ecc %d\n", 
> ret);
> + return ret;
> + }
> +
> + reset_control_deassert(hsotg->reset_ecc);
> +
>   /* Set default UTMI width */
>   hsotg->phyif = GUSBCFG_PHYIF16;
>
> @@ -318,6 +327,7 @@ static int dwc2_driver_remove(struct platform_device *dev)
>   dwc2_lowlevel_hw_disable(hsotg);
>
>   reset_control_assert(hsotg->reset);
> + reset_control_assert(hsotg->reset_ecc);
>
>   return 0;
>  }
>

Acked-by: John Youn 

John

[PATCH] doc: convert printk-formats.txt to rst

[Tobin C. Harding]

Documentation/printk-formats.txt is a candidate for conversion to
ReStructuredText format. Some effort has already been made to do this
conversion even thought the suffix is currently .txt

Changes required to complete conversion

- Add double backticks where needed.
- Add entry to Documentation/index.rst
- Use flat-table instead of ASCII table.
- Fix minor grammatical errors.
- Capitalize headers and correctly order heading adornments.
- Use 'Passed by reference' uniformly.
- Update pointer documentation around %px specifier.
- Fix erroneous double backticks (to commas).
- Simplify documentation for kobject.
- Convert lib/vsnprintf.c function docs to use kernel-docs and
  include in Documentation/printk-formats.rst

Signed-off-by: Tobin C. Harding 
---

The last two need special reviewing please. In particular the conversion
of kernel-docs in vsnprintf.c attempt was made to reduce documentation
duplication with comments in the source code being simplified in order
to be suitable for inclusion in Documentation/printk-formats.rst

I used -M when formatting the patch. If you don't like the diff with
this flag just holla.

thanks,
Tobin.

 Documentation/index.rst|  10 +
 .../{printk-formats.txt => printk-formats.rst} | 295 -
 lib/vsprintf.c | 160 +--
 3 files changed, 235 insertions(+), 230 deletions(-)
 rename Documentation/{printk-formats.txt => printk-formats.rst} (61%)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index cb7f1ba5b3b1..83ace60efbe7 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -87,6 +87,16 @@ implementation.
 
sh/index
 
+Miscellaneous documentation
+---
+
+These guides contain general information useful when writing kernel code.
+
+.. toctree::
+   :maxdepth: 1
+
+   printk-formats
+
 Korean translations
 ---
 
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.rst
similarity index 61%
rename from Documentation/printk-formats.txt
rename to Documentation/printk-formats.rst
index aa0a776c817a..51449d213748 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.rst
@@ -1,6 +1,6 @@
-=
-How to get printk format specifiers right
-=
+=
+How to Get ``printk`` Format Specifiers Right
+=
 
 :Author: Randy Dunlap 
 :Author: Andrew Murray 
@@ -8,56 +8,91 @@ How to get printk format specifiers right
 Integer types
 =
 
-::
+For printing integer types, we have the following format specifiers:
+   
+   .. flat-table:: 
+  :widths: 2 2
+
+  * - **Type**
+   - **Specifier**
+
+  * - ``int``
+- ``%d`` or ``%x``
+
+  * - ``unsigned int``
+   - ``%u`` or ``%x``
+
+  * - ``long``
+   - ``%ld`` or ``%lx``
+
+  * - ``unsigned long``
+   - ``%lu`` or ``%lx``
+
+  * - ``long long``
+   - ``%lld`` or ``%llx``
 
-   If variable is of Type, use printk format specifier:
-   
-   int %d or %x
-   unsigned int%u or %x
-   long%ld or %lx
-   unsigned long   %lu or %lx
-   long long   %lld or %llx
-   unsigned long long  %llu or %llx
-   size_t  %zu or %zx
-   ssize_t %zd or %zx
-   s32 %d or %x
-   u32 %u or %x
-   s64 %lld or %llx
-   u64 %llu or %llx
-
-If  is dependent on a config option for its size (e.g., ``sector_t``,
+  * - ``unsigned long long``
+   - ``%llu`` or ``%llx``
+
+  * - ``size_t``
+   - ``%zu`` or ``%zx``
+
+  * - ``ssize_t``
+   - ``%zd`` or ``%zx``
+
+  * - ``s32``
+   - ``%d`` or ``%x``
+
+  * - ``u32``
+   - ``%u`` or ``%x``
+
+  * - ``s64``
+   - ``%lld`` or ``%llx``
+
+  * - ``u64``
+   - ``%llu`` or ``%llx``
+
+
+If  is dependent on a config option for its size (e.g., ``sector_t``,
 ``blkcnt_t``) or is architecture-dependent for its size (e.g., ``tcflag_t``),
 use a format specifier of its largest possible type and explicitly cast to it.
 
 Example::
 
-   printk("test: sector number/total blocks: %llu/%llu\n",
-   (unsigned long long)sector, (unsigned long long)blockcount);
+   printk("test: total blocks: %llu\n", (unsigned long long)blockcount);
 
-Reminder: ``sizeof()`` result is of type ``size_t``.
+Reminder: ``sizeof()`` returns type ``size_t``.
 
-The kernel's printf does not 

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

[Sergey Senozhatsky]

Hello,

On (12/05/17 13:22), Linus Torvalds wrote:
[..]
> It's not like those hex numbers were really helping people anyway.
> We've turned off most of them on x86 oops reports long ago (and
> entirely independently of the pointer hashing). Having stared at a lot
> of oopses in my time, the only hex numbers that tend to be really
> relevant are (a) the register contents (which aren't %p anyway), and
> things like the faulting address (which is not, and never has been, %p
> on x86, but might be on some other architecture).

I see some %p-s being used in _supposedly_ important output,
like arch/x86/mm/fault.c

show_fault_oops(struct pt_regs *regs, unsigned long error_code,
unsigned long address)
...
printk(KERN_CONT " at %p\n", (void *) address);
printk(KERN_ALERT "IP: %pS\n", (void *)regs->ip);


a quick %p grep gives me the following list:

arch/arm/mm/fault.c:pr_alert("pgd = %p\n", mm->pgd);
arch/arm64/mm/fault.c:  pr_alert("%s pgtable: %luk pages, %u-bit VAs, pgd = 
%p\n",
arch/arm64/mm/fault.c:  pr_info_ratelimited("%s[%d]: %s exception: 
pc=%p sp=%p\n",
arch/m68k/mm/fault.c:   pr_debug("send_fault_sig: %p,%d,%d\n", siginfo.si_addr,
arch/m68k/mm/fault.c:   pr_cont(" at virtual address %p\n", 
siginfo.si_addr);
arch/m68k/mm/fault.c:   pr_debug("do page fault:\nregs->sr=%#x, regs->pc=%#lx, 
address=%#lx, %ld, %p\n",
arch/microblaze/mm/fault.c: pr_emerg("Page fault in user mode with 
faulthandler_disabled(), mm = %p\n",
arch/mn10300/mm/fault.c:printk(KERN_DEBUG "pgd entry %p: %016Lx\n",
arch/mn10300/mm/fault.c:printk(KERN_DEBUG "pmd entry %p: %016Lx\n",
arch/mn10300/mm/fault.c:printk(KERN_DEBUG "pte entry %p: %016Lx\n",
arch/mn10300/mm/fault.c:printk(KERN_DEBUG "--- 
do_page_fault(%p,%s:%04lx,%08lx)\n",
arch/powerpc/mm/fault.c:   " mm=%p\n",
arch/sh/mm/fault.c: printk(KERN_ALERT "pgd = %p\n", pgd);
arch/unicore32/mm/fault.c:  printk(KERN_ALERT "pgd = %p\n", mm->pgd);
arch/x86/mm/fault.c:printk(KERN_CONT " at %p\n", (void *) address);
arch/x86/mm/fault.c:printk(KERN_ALERT "IP: %pS\n", (void *)regs->ip);
arch/x86/mm/fault.c:printk("%s%s[%d]: segfault at %lx ip %p sp %p error 
%lx",


or is it OK to show hashes instead of pgd or pmd pointers?

-ss

Re: [PATCH] scripts/faddr2line: extend usage on generic arch

[Liu, Changcheng]

On 22:30 Tue 05 Dec, Richard Weinberger wrote:
> On Tue, Nov 21, 2017 at 10:29 AM, Liu, Changcheng
>  wrote:
> > fadd2line script should use the binary tool
> > used for the target system.
> >
> > Signed-off-by: Liu Changcheng 
> >
> > diff --git a/scripts/faddr2line b/scripts/faddr2line
> > index 1f5ce95..39e07d8 100755
> > --- a/scripts/faddr2line
> > +++ b/scripts/faddr2line
> > @@ -44,9 +44,16 @@
> >  set -o errexit
> >  set -o nounset
> >
> > +READELF="${CROSS_COMPILE}readelf"
> > +ADDR2LINE="${CROSS_COMPILE}addr2line"
> > +SIZE="${CROSS_COMPILE}size"
> > +NM="${CROSS_COMPILE}nm"
> 
> How is this supposed to work when not cross compiling?
> When CROSS_COMPILE is not set this script will terminate because of
> the "set -o nounset" bash setting...

[Changcheng]:@Richard. Thx for your check. I've sent the fix patch to
resolve the unbound variable error.

> 
> -- 
> Thanks,
> //richard

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

[Sergey Senozhatsky]

On (12/05/17 17:59), Linus Torvalds wrote:
[..]
> On Tue, Dec 5, 2017 at 5:36 PM, Sergey Senozhatsky
>  wrote:
> > I see some %p-s being used in _supposedly_ important output,
> > like arch/x86/mm/fault.c
> >
> > show_fault_oops(struct pt_regs *regs, unsigned long error_code,
> > unsigned long address)
> > ...
> > printk(KERN_CONT " at %p\n", (void *) address);
> > printk(KERN_ALERT "IP: %pS\n", (void *)regs->ip);
> 
> So %pS isn't %p, and shows the symbolic name.

sure, agreed. by "some %p-s being used" I meant the grep result,
not just x86 show_fault_oops().


> But yes, that "at %p" should definitely be %px.

more %p grepping [filtering out all `%ps %pf %pb' variants] gives
a huge number of print outs that potentially can be broken now

arch/x86/kernel/kprobes/core.c: printk(KERN_WARNING "Unrecoverable 
kprobe detected at %p.\n",
arch/x86/kernel/kprobes/core.c:"current sp %p does not 
match saved sp %p\n",
arch/x86/kernel/kprobes/core.c: printk(KERN_ERR "Saved 
registers for jprobe %p\n", jp);

arch/x86/kernel/head_32.S:  .asciz "Unknown interrupt or fault at: %p %p 
%p\n"
arch/x86/kernel/irq_32.c:   printk(KERN_DEBUG "CPU %u irqstacks, hard=%p 
soft=%p\n",

arch/x86/kernel/smpboot.c:  pr_debug("Stack at about %p\n", );
arch/x86/kernel/traps.c:printk(KERN_EMERG "BUG: stack guard page was 
hit at %p (stack is %p..%p)\n",


so I'm not in position to suggest the removal of those print outs or to
decide if those are important at all, just saying that that "I'm confused
by pointer values and can't debug" might be more likely that we thought.


> So my gut feel is that those printouts should probably just be
> removed. They have some very old historical reasons: we've printed out
> the page directory pointers (and followed the page tables) since at
> least back in the 1.1.x days. This is from the 1.1.7 patch, back when
> mm/memory.c was all about x86:

I see, thanks.

-ss

Re: [PATCH] ptr_ring: add barriers

[Michael S. Tsirkin]

On Wed, Dec 06, 2017 at 10:31:39AM +0800, Jason Wang wrote:
> 
> 
> On 2017年12月06日 03:29, Michael S. Tsirkin wrote:
> > Users of ptr_ring expect that it's safe to give the
> > data structure a pointer and have it be available
> > to consumers, but that actually requires an smb_wmb
> > or a stronger barrier.
> > 
> > In absence of such barriers and on architectures that reorder writes,
> > consumer might read an un=initialized value from an skb pointer stored
> > in the skb array.  This was observed causing crashes.
> > 
> > To fix, add memory barriers.  The barrier we use is a wmb, the
> > assumption being that producers do not need to read the value so we do
> > not need to order these reads.
> > 
> > Reported-by: George Cherian 
> > Suggested-by: Jason Wang 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> > 
> > George, could you pls report whether this patch fixes
> > the issue for you?
> > 
> > This seems to be needed in stable as well.
> > 
> > 
> > 
> > 
> >   include/linux/ptr_ring.h | 9 +
> >   1 file changed, 9 insertions(+)
> > 
> > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
> > index 37b4bb2..6866df4 100644
> > --- a/include/linux/ptr_ring.h
> > +++ b/include/linux/ptr_ring.h
> > @@ -101,12 +101,18 @@ static inline bool ptr_ring_full_bh(struct ptr_ring 
> > *r)
> >   /* Note: callers invoking this in a loop must use a compiler barrier,
> >* for example cpu_relax(). Callers must hold producer_lock.
> > + * Callers are responsible for making sure pointer that is being queued
> > + * points to a valid data.
> >*/
> >   static inline int __ptr_ring_produce(struct ptr_ring *r, void *ptr)
> >   {
> > if (unlikely(!r->size) || r->queue[r->producer])
> > return -ENOSPC;
> > +   /* Make sure the pointer we are storing points to a valid data. */
> > +   /* Pairs with smp_read_barrier_depends in __ptr_ring_consume. */
> > +   smp_wmb();
> > +
> > r->queue[r->producer++] = ptr;
> > if (unlikely(r->producer >= r->size))
> > r->producer = 0;
> > @@ -275,6 +281,9 @@ static inline void *__ptr_ring_consume(struct ptr_ring 
> > *r)
> > if (ptr)
> > __ptr_ring_discard_one(r);
> > +   /* Make sure anyone accessing data through the pointer is up to date. */
> > +   /* Pairs with smp_wmb in __ptr_ring_produce. */
> > +   smp_read_barrier_depends();
> > return ptr;
> >   }
> 
> I was thinking whether or not it's better to move those to the callers. Then
> we can save lots of barriers in e.g batch consuming.
> 
> Thanks

Batch consumers only do smp_read_barrier_depends which is free on
non-alpha. I suggest we do the simple thing for stable and reserve
optimizations for later.

-- 
MST

[PATCH 2/5] perf-probe: Cut off the version suffix from event name

[Masami Hiramatsu]

Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
automatic generated event name. This fixes wildcard event
adding like below case;

  =
  # perf probe -x /lib64/libc-2.25.so malloc*
  Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
Error: Failed to add events.
  =

This failure was caused by a versioned suffix symbol.
With this fix, perf probe automatically cuts the
suffix after @ as below.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc*
  Added new events:
probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_set_state -aR sleep 1

  =

Signed-off-by: Masami Hiramatsu 
Reported-by: Arnaldo Carvalho de Melo 
Reported-by: bhargavb 
---
 tools/perf/util/probe-event.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index c0067950e56f..74435fb7ab7f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2584,8 +2584,8 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
if (!nbase)
return -ENOMEM;
 
-   /* Cut off the dot suffixes (e.g. .const, .isra)*/
-   p = strchr(nbase, '.');
+   /* Cut off the dot suffixes (e.g. .const, .isra) and version suffixes */
+   p = strpbrk(nbase, ".@");
if (p && p != nbase)
*p = '\0';
 

[PATCH 4/5] perf-probe: Find versioned symbols from map

[Masami Hiramatsu]

Find versioned symbols correctly from map.
Commit d80406453ad4 ("perf symbols: Allow user probes on
versioned symbols") allows user to find default versioned
symbols (with "@@") in map. However, it did not enable
normal versioned symbol (with "@") for perf-probe.
E.g.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc_get_state
  Failed to find symbol malloc_get_state in /usr/lib64/libc-2.25.so
Error: Failed to add events.
  =

This solves above issue by improving perf-probe symbol
search function, as below.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc_get_state
  Added new event:
probe_libc:malloc_get_state (on malloc_get_state in /usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_get_state -aR sleep 1

  # ./perf probe -l
probe_libc:malloc_get_state (on malloc_get_state@GLIBC_2.2.5 in 
/usr/lib64/libc-2.25.so)
  =

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/arch/powerpc/util/sym-handling.c |8 
 tools/perf/util/probe-event.c   |   16 +++-
 tools/perf/util/symbol.c|5 +
 tools/perf/util/symbol.h|1 +
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 9c4e23d8c8ce..a3613c8d97b6 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -64,6 +64,14 @@ int arch__compare_symbol_names_n(const char *namea, const 
char *nameb,
 
return strncmp(namea, nameb, n);
 }
+
+const char *arch__normalize_symbol_name(const char *name)
+{
+   /* Skip over initial dot */
+   if (*name == '.')
+   name++;
+   return name;
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 959c4d2ef455..94acc5846e2a 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2801,16 +2801,30 @@ static int find_probe_functions(struct map *map, char 
*name,
int found = 0;
struct symbol *sym;
struct rb_node *tmp;
+   const char *norm, *ver;
+   char *buf = NULL;
 
if (map__load(map) < 0)
return 0;
 
map__for_each_symbol(map, sym, tmp) {
-   if (strglobmatch(sym->name, name)) {
+   norm = arch__normalize_symbol_name(sym->name);
+   if (!norm)
+   continue;
+
+   /* We don't care about default symbol or not */
+   ver = strchr(norm, '@');
+   if (ver) {
+   buf = strndup(norm, ver - norm);
+   norm = buf;
+   }
+   if (strglobmatch(norm, name)) {
found++;
if (syms && found < probe_conf.max_probes)
syms[found - 1] = sym;
}
+   if (buf)
+   zfree();
}
 
return found;
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 1b67a8639dfe..cc065d4bfafc 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -94,6 +94,11 @@ static int prefix_underscores_count(const char *str)
return tail - str;
 }
 
+const char * __weak arch__normalize_symbol_name(const char *name)
+{
+   return name;
+}
+
 int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
 {
return strcmp(namea, nameb);
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index a4f0075b4e5c..0563f33c1eb3 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -349,6 +349,7 @@ bool elf__needs_adjust_symbols(GElf_Ehdr ehdr);
 void arch__sym_update(struct symbol *s, GElf_Sym *sym);
 #endif
 
+const char *arch__normalize_symbol_name(const char *name);
 #define SYMBOL_A 0
 #define SYMBOL_B 1
 

[PATCH 3/5] perf-probe: Add __return suffix for return events

[Masami Hiramatsu]

Add __return suffix for function return events
automatically. Without this, user have to give --force
option and will see the number suffix for each event
like "function_1", which is not easy to recognize.
Instead, this adds __return suffix to it automatically.
E.g.

  =
  # ./perf probe -x /lib64/libc-2.25.so 'malloc*%return'
  Added new events:
probe_libc:malloc_printerr__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_consolidate__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_check__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_hook_ini__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc__return (on malloc*%return in /usr/lib64/libc-2.25.so)
probe_libc:malloc_trim__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_usable_size__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_stats__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_info__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:mallochook__return (on malloc*%return in /usr/lib64/libc-2.25.so)
probe_libc:malloc_get_state__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_set_state__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_set_state__return -aR sleep 1

  =

Signed-off-by: Masami Hiramatsu 
Reported-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 74435fb7ab7f..959c4d2ef455 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2573,7 +2573,8 @@ int show_perf_probe_events(struct strfilter *filter)
 }
 
 static int get_new_event_name(char *buf, size_t len, const char *base,
- struct strlist *namelist, bool allow_suffix)
+ struct strlist *namelist, bool ret_event,
+ bool allow_suffix)
 {
int i, ret;
char *p, *nbase;
@@ -2590,7 +2591,7 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
*p = '\0';
 
/* Try no suffix number */
-   ret = e_snprintf(buf, len, "%s", nbase);
+   ret = e_snprintf(buf, len, "%s%s", nbase, ret_event ? "__return" : "");
if (ret < 0) {
pr_debug("snprintf() failed: %d\n", ret);
goto out;
@@ -2689,8 +2690,8 @@ static int probe_trace_event__set_name(struct 
probe_trace_event *tev,
group = PERFPROBE_GROUP;
 
/* Get an unused new event name */
-   ret = get_new_event_name(buf, 64, event,
-namelist, allow_suffix);
+   ret = get_new_event_name(buf, 64, event, namelist,
+tev->point.retprobe, allow_suffix);
if (ret < 0)
return ret;
 

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > The series of patches introduce Security Version to EFI stub.
> >
> > Security Version is a monotonically increasing number and designed to
> > prevent the user from loading an insecure kernel accidentally. The
> > bootloader maintains a list of security versions corresponding to
> > different distributions. After fixing a critical vulnerability, the
> > distribution kernel maintainer bumps the "version", and the bootloader
> > updates the list automatically. When the user tries to load a kernel
> > with a lower security version, the bootloader shows a warning prompt
> > to notify the user the potential risk.
> 
> If a distribution releases a kernel with a higher security version and
> that it automatically updated on boot, what happens if that kernel
> contains a different bug that causes it to fail to boot or break
> critical functionality?  At that point, the user's machine would be in
> a state where the higher security version is enforced but the only
> kernel that provides that is broken.  Wouldn't that make a bad
> situation even worse by now requiring manual acceptance of the older
> SV kernel boot physically at the machine?
> 
> I feel like I'm missing a detail here or something.
> 
If the new kernel fails to boot, then the user has to choose the kernel
manually anyway, and there will be an option in the warning prompt to
lower SV.

Since Security Version is meant to be a warning, not a hard block, we
can introduce a timeout to the warning prompt if necessary. The system
still boots, but with a longer boot time.

Gary Lin

> josh
> 
> > For more details: https://github.com/lcp/shim/wiki/Security-Version
> >
> > The original idea is to add a new PE/COFF section to store the data.
> > However, there are some restrictions.
> >
> > 1. For x86, the size limit of the EFI header is 0x200, and a section entry
> >in the section table takes 40 bytes. Currently, the EFI header already
> >occupies the first 0x1da bytes, so there is no room for a new section
> >entry.
> >
> > 2. The MemoryAttributes table sets the attributes of memory pages according
> >to the section flags. For ARM64, the minimal granularity is 4KB, but
> >Security Version only needs a few bytes, and it's pointless to allocate
> >4KB for it.
> >
> > Fortunately, there is a special section defined in PE/COFF: resource
> > section. The only known user of the resource section in UEFI is the HII
> > protocol which fetches data from "HII" directory. For Security Version, a
> > new directory called "LinuxSV" is created and it contains the file offset
> > to the struct of Security Version. The bootloader just follows the
> > resource table to fetch the "version" from the image file.
> >
> > v3:
> > - Move everything to the resource section to be compatible with both
> >   x86 and ARM64
> > v2:
> > - Decrease the size of secdata_offset to 2 bytes since the setup header
> >   is limited to around 32KB.
> > - Restructure the secdata section. The signer is now a null-terminated
> >   string. The type of distro_version changes to u32 in case the distro
> >   uses a long version.
> > - Modify the Kconfig names and add help.
> > - Remove the signer name hack in build.c.
> >
> > Cc: "H. Peter Anvin" 
> > Cc: Thomas Gleixner 
> > Cc: Ard Biesheuvel 
> > Cc: Ingo Molnar 
> > Cc: Matt Fleming 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Joey Lee 
> > Signed-off-by: Gary Lin 
> >
> > Gary Lin (2):
> >   x86/efi: Introduce Security Version to x86
> >   arm64/efi: Introduce Security Version to ARM64
> >
> >  arch/arm64/kernel/efi-header.S | 57 
> > ++
> >  arch/x86/boot/header.S | 55 
> > 
> >  drivers/firmware/efi/Kconfig   | 40 +
> >  3 files changed, 152 insertions(+)
> >
> > --
> > 2.15.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

linux-next: build failure after merge of the printk tree

[Stephen Rothwell]

Hi Petr,

After merging the printk tree, today's linux-next build (x86_64
allnoconfig) failed like this:

lib/vsprintf.o: In function `pointer':
vsprintf.c:(.text+0x2260): undefined reference to 
`dereference_symbol_descriptor'

Caused by commit

  b77929215209 ("symbol lookup: introduce dereference_symbol_descriptor()")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[PATCH 1/3] mmc: sdhci-pci-o2micro: Add hardware tuning for eMMC

[LinuxPatchCommit]

For O2micro/Bayhubtech SD Host DeviceID 8620, eMMC HS200 mode is
working at 1.8v and it uses hardware tuning. The hardware tuning
only needs to send one tuning command instead of multiple tuning
commands with software tuning.

Signed-off-by: ernest.zhang 
---
 drivers/mmc/host/sdhci-pci-o2micro.c | 275 ++-
 1 file changed, 238 insertions(+), 37 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c 
b/drivers/mmc/host/sdhci-pci-o2micro.c
index 14273ca00641..4e4a301a54f5 100644
--- a/drivers/mmc/host/sdhci-pci-o2micro.c
+++ b/drivers/mmc/host/sdhci-pci-o2micro.c
@@ -16,22 +16,223 @@
  */
 
 #include 
-
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "sdhci.h"
 #include "sdhci-pci.h"
 #include "sdhci-pci-o2micro.h"
 
+static void sdhci_o2_start_tuning(struct sdhci_host *host)
+{
+   u16 ctrl;
+
+   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+   ctrl |= SDHCI_CTRL_EXEC_TUNING;
+   if (host->quirks2 & SDHCI_QUIRK2_TUNING_WORK_AROUND)
+   ctrl |= SDHCI_CTRL_TUNED_CLK;
+   sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
+
+   /*
+* As per the Host Controller spec v3.00, tuning command
+* generates Buffer Read Ready interrupt, so enable that.
+*
+* Note: The spec clearly says that when tuning sequence
+* is being performed, the controller does not generate
+* interrupts other than Buffer Read Ready interrupt. But
+* to make sure we don't hit a controller bug, we _only_
+* enable Buffer Read Ready interrupt here.
+*/
+   sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE);
+   sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE);
+}
+
+static void sdhci_o2_end_tuning(struct sdhci_host *host)
+{
+   sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
+   sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+}
+
+static inline bool sdhci_data_line_cmd(struct mmc_command *cmd)
+{
+   return cmd->data || cmd->flags & MMC_RSP_BUSY;
+}
+
+static void sdhci_del_timer(struct sdhci_host *host, struct mmc_request *mrq)
+{
+   if (sdhci_data_line_cmd(mrq->cmd))
+   del_timer(>data_timer);
+   else
+   del_timer(>timer);
+}
+
+static void sdhci_o2_set_tuning_mode(struct sdhci_host *host, bool hw)
+{
+   u16 reg;
+
+   if (hw) {
+   // enable hardware tuning
+   reg = sdhci_readw(host, O2_SD_VENDOR_SETTING);
+   reg &= (~O2_SD_HW_TUNING_ENABLE);
+   sdhci_writew(host, reg, O2_SD_VENDOR_SETTING);
+   } else {
+   reg = sdhci_readw(host, O2_SD_VENDOR_SETTING);
+   reg |= O2_SD_HW_TUNING_ENABLE;
+   sdhci_writew(host, reg, O2_SD_VENDOR_SETTING);
+   }
+}
+
+static u8 data_buf[64];
+
+static void sdhci_o2_send_tuning(struct sdhci_host *host, u32 opcode)
+{
+   struct mmc_command cmd = { };
+   struct mmc_data data = { };
+   struct scatterlist sg;
+   struct mmc_request mrq = { };
+   unsigned long flags;
+   u32 b = host->sdma_boundary;
+   int size = sizeof(data_buf);
+
+   cmd.opcode = opcode;
+   cmd.flags = MMC_RSP_PRESENT | MMC_RSP_OPCODE | MMC_RSP_CRC;
+   cmd.mrq = 
+   mrq.cmd = 
+   mrq.data = 
+   data.blksz = size;
+   data.blocks = 1;
+   data.flags = MMC_DATA_READ;
+
+   data.timeout_ns = 150 * NSEC_PER_MSEC;
+
+   data.sg = 
+   data.sg_len = 1;
+   sg_init_one(, data_buf, size);
+
+   spin_lock_irqsave(>lock, flags);
+
+   sdhci_writew(host, SDHCI_MAKE_BLKSZ(b, 64), SDHCI_BLOCK_SIZE);
+
+   /*
+* The tuning block is sent by the card to the host controller.
+* So we set the TRNS_READ bit in the Transfer Mode register.
+* This also takes care of setting DMA Enable and Multi Block
+* Select in the same register to 0.
+*/
+   sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
+
+   sdhci_send_command(host, );
+
+   host->cmd = NULL;
+
+   sdhci_del_timer(host, );
+
+   host->tuning_done = 0;
+
+   mmiowb();
+   spin_unlock_irqrestore(>lock, flags);
+
+   /* Wait for Buffer Read Ready interrupt */
+   wait_event_timeout(host->buf_ready_int, (host->tuning_done == 1),
+  msecs_to_jiffies(50));
+
+}
+
+static void sdhci_o2_reset_tuning(struct sdhci_host *host)
+{
+   u16 ctrl;
+
+   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+   ctrl &= ~SDHCI_CTRL_TUNED_CLK;
+   ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
+   sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
+}
+
+static void __sdhci_o2_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+
+   int i;
+
+   sdhci_o2_send_tuning(host, MMC_SEND_TUNING_BLOCK_HS200);
+
+   for (i = 0; i < 150; i++) {
+   u16 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+
+   if (!(ctrl 

Re: [PATCH v4 3/3] powerpc/modules: Improve restore_r2() error message

[Michael Ellerman]

Kamalesh Babulal  writes:

> From: Josh Poimboeuf 
>
> Print the function address associated with the restore_r2() error to
> make it easier to debug the problem.
>
> Also clarify the wording a bit.
>
> Before:
>
>   module_64: patch_foo: Expect noop after relocate, got 3c82
>
> After:
>
>   module_64: patch_foo: Expected noop after call, got 7c630034 at 
> netdev_has_upper_dev+0x54/0xb0 [patch_foo]

I renamed noop to nop, as that's the name of the instruction.

cheers

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

[Matthew Wilcox]

On Wed, Dec 06, 2017 at 03:51:44PM +1100, Michael Ellerman wrote:
> Cyril Hrubis  writes:
> 
> > Hi!
> >> > MAP_FIXED_UNIQUE
> >> > MAP_FIXED_ONCE
> >> > MAP_FIXED_FRESH
> >> 
> >> Well, I can open a poll for the best name, but none of those you are
> >> proposing sound much better to me. Yeah, naming sucks...
> >
> > Given that MAP_FIXED replaces the previous mapping MAP_FIXED_NOREPLACE
> > would probably be a best fit.
> 
> Yeah that could work.
> 
> I prefer "no clobber" as I just suggested, because the existing
> MAP_FIXED doesn't politely "replace" a mapping, it destroys the current
> one - which you or another thread may be using - and clobbers it with
> the new one.

It's longer than MAP_FIXED_WEAK :-P

You'd have to be pretty darn strong to clobber an existing mapping.

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

[Matthew Wilcox]

On Tue, Dec 05, 2017 at 08:45:49PM -0800, Matthew Wilcox wrote:
> The dquot code is just going to have to live with the fact that there's
> additional locking going on that it doesn't need.  I'm open to getting
> rid of the irqsafety, but we can't give up the spinlock protection
> without giving up the RCU/lockdep analysis and the ability to move nodes.
> I don't suppose the dquot code can 

Oops, thought I'd finished writing this paragraph.

I don't suppose the dquot code can be restructured to use the xa_lock to
protect, say, qi_dquots?  I suspect not, since you wouldn't know which
of the three xarray locks to use.

Re: possible deadlock in generic_file_write_iter (2)

[Byungchul Park]

On Tue, Dec 05, 2017 at 10:41:50AM +0100, Jan Kara wrote:
> 
> Hello Byungchul,
> 
> On Tue 05-12-17 13:58:09, Byungchul Park wrote:
> > On 12/4/2017 5:33 PM, Jan Kara wrote:
> > >adding Peter and Byungchul to CC since the lockdep report just looks
> > >strange and cross-release seems to be involved. Guys, how did #5 get into
> > >the lock chain and what does put_ucounts() have to do with sb_writers
> > >there? Thanks!
> > 
> > Hello Jan,
> > 
> > In order to get full stack of #5, we have to pass a boot param,
> > "crossrelease_fullstack", to the kernel. Now that it only informs
> > put_ucounts() in the call trace, it's hard to find out what exactly
> > happened at that time, but I can tell #5 shows:
> 
> OK, thanks for the tip.
> 
> > When acquire(sb_writers) in put_ucounts(), it was on the way to
> > complete((completion)) of wait_for_completion() in
> > devtmpfs_create_node().
> > 
> > If acquire(sb_writers) in put_ucounts() is stuck, then
> > wait_for_completion() in devtmpfs_create_node() would be also
> > stuck, since complete() being in the context of acquire(sb_writers)
> > cannot be called.
> 
> But this is something I don't get: There aren't sb_writers anywhere near
> put_ucounts(). So why the heck did lockdep think that sb_writers are
> acquired by put_ucounts()?

I also think it looks so weird. I just record _RET_IP_ or _THIS_IP_ when
acquire(sb_writers). Is it possible to get wrong _RET_IP_ or _THIS_IP_ by
any chance?

> 
>   Honza
> -- 
> Jan Kara 
> SUSE Labs, CR

Re: [PATCH v11 0/6] Add support for Qualcomm A53 CPU clock

[Amit Kucheria]

On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov  wrote:
> This patchset adds support for the A53 CPU clock on MSM8916 platforms
> and allows scaling of the CPU frequency on msm8916 based platforms.

Though it currently needs some additional patches (that'll follow
soon), FWIW, Tested-by: Amit Kucheria 

> Changes since v10 (https://lkml.org/lkml/2017/12/1/577)
> * Addressed Bjorn's comments on APCS clock driver.
> * Picked Acks from Rob and Bjorn.
>
> Changes since v9 (https://lkml.org/lkml/2017/9/21/511)
> * Added the clock properties to the APCS DT node, instead of adding a subnode
> and also replaced patch "mailbox: qcom: Populate APCS child platform devices"
> with "mailbox: qcom: Create APCS child device for clock controller".
> * Dropped patch "mailbox: qcom: Move the apcs struct into a separate header",
> and use dev_get_regmap(dev->parent) in the child driver.
> * Addressed Bjorn's comments on a53-pll and apcs-clk drivers.
> * Added SPDX copyright identifiers.
>
> Changes since v8 (https://lkml.org/lkml/2017/6/23/476)
>  * Converted APCS mailbox driver to use regmap and to populate child
>  platform devices that will handle the rest of the functionality
>  provided by APCS block.
>  * Picked Rob's Ack for the PLL binding.
>  * Changed the APCS binding and put it into a separate patch.
>  * Addressed review comments.
>  * Minor changes.
>
> Changes since v7 (https://lkml.org/lkml/2016/10/31/296)
>  * Add the APCS clock controller to the APCS driver to expose both the
>  mailbox and clock controller functionality as discussed earlier:
>  https://lkml.org/lkml/2016/11/14/860
>  * Changed the a53pll compatible string as suggested by Rob.
>
> Changes since v6 (https://lkml.org/lkml/2016/9/7/347)
>  * Addressed various comments from Stephen Boyd
>
> Changes since v5 (https://lkml.org/lkml/2016/2/1/407)
>  * Rebase to clk-next and update according to the recent API changes.
>
> Changes since v4 (https://lkml.org/lkml/2015/12/14/367)
>  * Convert to builtin drivers as now __clk_lookup() is used
>
> Changes since v3 (https://lkml.org/lkml/2015/8/12/585)
>  * Split driver into two parts - and separate A53 PLL and
>A53 clock controller drivers.
>  * Drop the safe switch hook patch. Add a clock notifier in
>the clock provider to handle switching via safe mux and
>divider configuration.
>
> Changes since v2 (https://lkml.org/lkml/2015/7/24/526)
>  * Drop gpll0_vote patch.
>  * Switch to the new clk_hw_* APIs.
>  * Rebase to the current clk-next.
>
> Changes since v1 (https://lkml.org/lkml/2015/6/12/193)
>  * Drop SR2 PLL patch, as it is already applied.
>  * Add gpll0_vote rate propagation patch.
>  * Update/rebase patches to the current clk-next.
>
> Georgi Djakov (6):
>   mailbox: qcom: Convert APCS IPC driver to use regmap
>   mailbox: qcom: Create APCS child device for clock controller
>   clk: qcom: Add A53 PLL support
>   clk: qcom: Add regmap mux-div clocks support
>   dt-bindings: mailbox: qcom: Document the APCS clock binding
>   clk: qcom: Add APCS clock controller support
>
>  .../devicetree/bindings/clock/qcom,a53pll.txt  |  22 ++
>  .../bindings/mailbox/qcom,apcs-kpss-global.txt |  18 ++
>  drivers/clk/qcom/Kconfig   |  21 ++
>  drivers/clk/qcom/Makefile  |   3 +
>  drivers/clk/qcom/a53-pll.c | 110 ++
>  drivers/clk/qcom/apcs-msm8916.c| 149 ++
>  drivers/clk/qcom/clk-regmap-mux-div.c  | 229 
> +
>  drivers/clk/qcom/clk-regmap-mux-div.h  |  46 +
>  drivers/mailbox/qcom-apcs-ipc-mailbox.c|  35 +++-
>  9 files changed, 628 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53pll.txt
>  create mode 100644 drivers/clk/qcom/a53-pll.c
>  create mode 100644 drivers/clk/qcom/apcs-msm8916.c
>  create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.c
>  create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.h
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] usb: dwc2: host: Don't retry NAKed transactions right away

[John Youn]

On 12/05/2017 08:18 AM, Stefan Wahren wrote:
> Hi Felipe,
> Hi John,
>
>
> Am 30.10.2017 um 18:08 schrieb Douglas Anderson:
>> On rk3288-veyron devices on Chrome OS it was found that plugging in an
>> Arduino-based USB device could cause the system to lockup, especially
>> if the CPU Frequency was at one of the slower operating points (like
>> 100 MHz / 200 MHz).
>>
>> Upon tracing, I found that the following was happening:
>> * The USB device (full speed) was connected to a high speed hub and
>>then to the rk3288.  Thus, we were dealing with split transactions,
>>which is all handled in software on dwc2.
>> * Userspace was initiating a BULK IN transfer
>> * When we sent the SSPLIT (to start the split transaction), we got an
>>ACK.  Good.  Then we issued the CSPLIT.
>> * When we sent the CSPLIT, we got back a NAK.  We immediately (from
>>the interrupt handler) started to retry and sent another SSPLIT.
>> * The device kept NAKing our CSPLIT, so we kept ping-ponging between
>>sending a SSPLIT and a CSPLIT, each time sending from the interrupt
>>handler.
>> * The handling of the interrupts was (because of the low CPU speed and
>>the inefficiency of the dwc2 interrupt handler) was actually taking
>>_longer_ than it took the other side to send the ACK/NAK.  Thus we
>>were _always_ in the USB interrupt routine.
>> * The fact that USB interrupts were always going off was preventing
>>other things from happening in the system.  This included preventing
>>the system from being able to transition to a higher CPU frequency.
>>
>> As I understand it, there is no requirement to retry super quickly
>> after a NAK, we just have to retry sometime in the future.  Thus one
>> solution to the above is to just add a delay between getting a NAK and
>> retrying the transmission.  If this delay is sufficiently long to get
>> out of the interrupt routine then the rest of the system will be able
>> to make forward progress.  Even a 25 us delay would probably be
>> enough, but we'll be extra conservative and try to delay 1 ms (the
>> exact amount depends on HZ and the accuracy of the jiffy and how close
>> the current jiffy is to ticking, but could be as much as 20 ms or as
>> little as 1 ms).
>>
>> Presumably adding a delay like this could impact the USB throughput,
>> so we only add the delay with repeated NAKs.
>>
>> NOTE: Upon further testing of a pl2303 serial adapter, I found that
>> this fix may help with problems there.  Specifically I found that the
>> pl2303 serial adapters tend to respond with a NAK when they have
>> nothing to say and thus we end with this same sequence.
>>
>> Signed-off-by: Douglas Anderson 
>> Cc: sta...@vger.kernel.org
>> Reviewed-by: Julius Werner 
>> Tested-by: Stefan Wahren 
>> ---
>>
>> Changes in v3:
>> - Add tested-by for Stefan Wahren
>> - Sent to Felipe Balbi as candiate to land this.
>> - Add Cc for stable (it's always been broken so go as far is as easy)
>>
>> Changes in v2:
>> - Address 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__crosreview.com_737520=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA=Y_xpJ6Ks0XAK5_bQgmeQEvgKThZtPBQJ3cejNCGfEvM=olyPwyYvn_072esVwYxrCduKOKKJPUgc1YHX-CNhM1s=
>>  feedback
>>
>
> does it need a resend?
>

You can add my acked-by:

Acked-by: John Youn 

Regards,
John

[PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Kuninori Morimoto]

From: Kuninori Morimoto 

In general, PLL has VCO (= Voltage controlled oscillator),
one of the very important electronic feature called as "jitter"
is related to this VCO.
In academic generalism, VCO should be maximum to be more small jitter.
In high frequency clock, jitter will be large impact.
Thus, selecting Hi VCO is general theory.

   fin fvcofout  fclkout
in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> out
 +-> |  | |
 ||
 +-[1/N]<-+

fclkout = fvco / P / FDPLL -- (1)

In PD, it will loop until fin/M = fvco/P/N

fvco = fin * P *  N / M -- (2)

(1) + (2) indicates, fclkout = fin * N / M / FDPLL
In this device, N = (n + 1), M = (m + 1), P = 2, thus

fclkout = fin * (n + 1) / (m + 1) / FDPLL

This is the datasheet formula.
One note here is that it should be 2000 < fvco < 4096MHz
To be smaller jitter, fvco should be maximum,
in other words, N as large as possible, M as small as possible driver
should select. Here, basically M=1.
This patch do it.

Reported-by: HIROSHI INOSE 
Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

 - tidyup typo on git-log "fout" -> "fclkout"
 - tidyup for loop terminate condition 40 -> 38 for n

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 36 --
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index b492063..57479c9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -125,8 +125,40 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc 
*rcrtc,
unsigned int m;
unsigned int n;
 
-   for (n = 39; n < 120; n++) {
-   for (m = 0; m < 4; m++) {
+   /*
+*   fin fvcofout   fclkout
+* in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> 
out
+*  +-> |  | |
+*  ||
+*  +-[1/N]<-+
+*
+*  fclkout = fvco / P / FDPLL -- (1)
+*
+* fin/M = fvco/P/N
+*
+*  fvco = fin * P *  N / M -- (2)
+*
+* (1) + (2) indicates
+*
+*  fclkout = fin * N / M / FDPLL
+*
+* NOTES
+*  N = (n + 1), M = (m + 1), P = 2
+*  2000 < fvco < 4096Mhz
+*  Basically M=1
+*
+* To be small jitter,
+* N : as large as possible
+* M : as small as possible
+*/
+   for (m = 0; m < 4; m++) {
+   for (n = 119; n > 38; n--) {
+   unsigned long long fvco = input * 2 * (n + 1) / (m + 1);
+
+   if ((fvco < 2000) ||
+   (fvco > 409600ll))
+   continue;
+
for (fdpll = 1; fdpll < 32; fdpll++) {
unsigned long output;
 
-- 
1.9.1

Re: In kernel power management domain_pm created for async schedules

[gre...@linuxfoundation.org]

On Wed, Dec 06, 2017 at 05:38:31AM +, Vikas Bansal wrote:
> If there is a driver in system which starts creating async schedules just 
> after resume (Same as our case, in which we faced issue). Then 
> async_synchronize_full API in PM cores starts waiting for completion of async 
> schedules created by that driver (Even though those are in a domain). Because 
> of this kernel resume time is increased (We faces the same issue) and whole 
> system is delayed. 
> This problem can be solved by creating is domain for async schedules in PM 
> core (As we solved in our case). Below patch is for solving this problem.

Please properly line-wrap your changelog text, _AND_ put it in the
changelog itself. Right now you have a patch:

> >From b8ea152eed6eef3b53275e7dd240a4d2124e9d4d Mon Sep 17 00:00:00 2001
> From: Anuj Gupta 
> Date: Tue, 5 Dec 2017 21:34:49 -0800
> Subject: [PATCH] Added domain_pm to PM core
> 
> 
> Signed-off-by: Vikas Bansal 

With no changelog text at all.

Please look at any of the hundreds of patches on the mailing list as an
example of how to properly format this.

Also, you didn't address my review comment I made last time, why not?

thanks,

greg k-h

Re: [PATCH] efi: move some sysfs files to be read-only by root

[Greg Kroah-Hartman]

On Wed, Dec 06, 2017 at 07:50:41AM +1100, Tobin C. Harding wrote:
> On Tue, Dec 05, 2017 at 11:13:43AM +0100, Greg Kroah-Hartman wrote:
> > Thanks to the scripts/leaking_addresses.pl script, it was found that
> > some EFI values should not be readable by non-root users.
> > 
> > So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
> > make this easier, and use it in other places at the same time.
> > 
> > Reported-by: Linus Torvalds 
> > Tested-by: Dave Young 
> > Cc: Matt Fleming 
> > Cc: Ard Biesheuvel 
> > Cc: stable 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > ---
> >  drivers/firmware/efi/efi.c |3 +--
> >  drivers/firmware/efi/esrt.c|   15 ++-
> >  drivers/firmware/efi/runtime-map.c |   10 +-
> >  include/linux/sysfs.h  |5 +
> >  4 files changed, 17 insertions(+), 16 deletions(-)
> > 
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -143,8 +143,7 @@ static ssize_t systab_show(struct kobjec
> > return str - buf;
> >  }
> 
> Greg, do you add the CC's here in the commit log for a technical reason?
> Is it so that future investigation that leads to this commit can see who
> to involve in any further discussion?

They came from the output of scripts/get_maintainer.pl on who I should
be sending the patch to, and who should hopefully review it.

> As an example, for the patch that added the %p hashing should I have
> CC'd Jason A. Donenfeld since he was the brains behind the SipHash
> stuff and gave loads of suggestions/direction?

If you want to.  It's also a good way for me to track who the patch gets
sent to when doing multiple versions of a patch series.  git send-email
picks those up and sends the patch to them as well, making it easier on
the developer instead of having to remember a long --cc= list of
addresses.

thanks,

greg k-h

Re: [PATCH] usb: core: Fix logging messages with spurious periods after newlines

[Joe Perches]

On Wed, 2017-12-06 at 07:27 +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 05, 2017 at 10:22:05PM -0800, Joe Perches wrote:
> > Using a period after a newline causes bad output.
> 
> Nice catch, how did you find that?

$ git grep '\\n\."'

RE: [PATCH net-next v3 4/4] net: fec: add phy_reset_after_clk_enable() support

[Andy Duan]

From: Richard Leitner  Sent: Tuesday, December 05, 2017 9:26 PM
>Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
>the refclk on and off again during operation (according to their datasheet).
>Nonetheless exactly this behaviour was introduced for power saving reasons
>by commit e8fcfcd5684a ("net: fec: optimize the clock management to save
>power").
>Therefore add support for the phy_reset_after_clk_enable function from
>phylib to mitigate this issue.
>
>Generally speaking this issue is only relevant if the ref clk for the PHY is
>generated by the SoC and therefore the PHY is configured to "REF_CLK In
>Mode". In our specific case (PCB) this problem does occur at about every 10th
>to 50th POR of an LAN8710 connected to an i.MX6SOLO SoC. The typical
>symptom of this problem is a "swinging" ethernet link.
>Similar issues were reported by users of the NXP forum:
>   https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F
>%2Fcommunity.nxp.com%2Fthread%2F389902=02%7C01%7Cfugang.du
>an%40nxp.com%7C7f9fee272fc44662c2a108d53be3d1ee%7C686ea1d3bc2b4c6
>fa92cd99c5c301635%7C0%7C0%7C636480772022331090=7RdUsoWVWu
>o1nM5zKwLt7%2F6U3dxgDJtBDGlQCUWC6IM%3D=0
>   https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F
>%2Fcommunity.nxp.com%2Fmessage%2F309354=02%7C01%7Cfugang.d
>uan%40nxp.com%7C7f9fee272fc44662c2a108d53be3d1ee%7C686ea1d3bc2b4
>c6fa92cd99c5c301635%7C0%7C0%7C636480772022331090=D56KilGWD3
>kLABxc0yOI%2B44Y%2FhLfrGtdAvupCEyvI%2BI%3D=0
>With this patch applied the issue didn't occur for at least a few hundret PORs
>of our board.
>
>Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save
>power")
>Signed-off-by: Richard Leitner 
>---
> drivers/net/ethernet/freescale/fec_main.c | 7 +++
> 1 file changed, 7 insertions(+)
>
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index 610573855213..8c3d0fb7db20 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -1862,6 +1862,8 @@ static int fec_enet_clk_enable(struct net_device
>*ndev, bool enable)
>   ret = clk_prepare_enable(fep->clk_ref);
>   if (ret)
>   goto failed_clk_ref;
>+
>+  phy_reset_after_clk_enable(ndev->phydev);
>   } else {
>   clk_disable_unprepare(fep->clk_ahb);
>   clk_disable_unprepare(fep->clk_enet_out);
>@@ -2860,6 +2862,11 @@ fec_enet_open(struct net_device *ndev)
>   if (ret)
>   goto err_enet_mii_probe;
>
>+  /* reset phy if needed here, due to the fact this is the first time we
>+   * have the net_device to phy_driver link
>+   */
>+  phy_reset_after_clk_enable(ndev->phydev);
>+

The patch series look better.
But why does it need to reset phy here since phy already is hard reset after 
clock enable.


>   if (fep->quirks & FEC_QUIRK_ERR006687)
>   imx6q_cpuidle_fec_irqs_used();
>
>--
>2.11.0

Re: [PATCH] SCSI: run queue if SCSI device queue isn't ready and queue is idle

[Ming Lei]

On Wed, Dec 06, 2017 at 12:28:25AM +0800, Ming Lei wrote:
> On Tue, Dec 05, 2017 at 04:08:20PM +, Bart Van Assche wrote:
> > On Tue, 2017-12-05 at 15:52 +0800, Ming Lei wrote:
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index db9556662e27..1816dd8259b3 100644
> > > --- a/drivers/scsi/scsi_lib.c
> > > +++ b/drivers/scsi/scsi_lib.c
> > > @@ -1967,6 +1967,8 @@ static bool scsi_mq_get_budget(struct blk_mq_hw_ctx 
> > > *hctx)
> > >  out_put_device:
> > >   put_device(>sdev_gendev);
> > >  out:
> > > + if (atomic_read(>device_busy) == 0 && !scsi_device_blocked(sdev))
> > > + blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
> > >   return false;
> > >  }
> > 
> > This cannot work since multiple threads can call scsi_mq_get_budget()
> 
> That is exactly the way we are handling these cases before 0df21c86bdbf(scsi:
> implement .get_budget and .put_budget for blk-mq), so if it can't work,
> that is not fault of commit 0df21c86bdbf.
> 
> > concurrently and hence it can happen that none of them sees
> > atomic_read(>device_busy) == 0. BTW, the above patch is something I
> 
> If there is concurrent .get_budget(), one of them will see the counter
> becoming zero finally because each sdev->device_busy is inc/dec
> atomically. Or scsi_dev_queue_ready() return true.
> 
> Anyway, we need this patch to avoid possible regression. If you think
> there are bugs in blk-mq RESTART, just root cause and and fix it.
> 
> > consider as a workaround. Have you considered to fix the root cause and to
> > add blk_mq_sched_mark_restart_hctx() where these are missing, e.g. in 
> > blk_mq_sched_dispatch_requests()? The patch below is not a full solution
> > but resulted in a significant improvement in my tests:
> > 
> > diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> > index 69e3226e66ca..9d86876ec503 100644
> > --- a/block/blk-mq-sched.c
> > +++ b/block/blk-mq-sched.c
> > @@ -226,6 +226,7 @@ void blk_mq_sched_dispatch_requests(struct 
> > blk_mq_hw_ctx *hctx)
> >  * TODO: get more budgets, and dequeue more requests in
> >  * one time.
> >  */
> > +   blk_mq_sched_mark_restart_hctx(hctx);
> > blk_mq_do_dispatch_ctx(hctx);
> > } else {
> > blk_mq_flush_busy_ctxs(hctx, _list);
> 

BTW, this kind of change can't cover scsi_set_blocked() which is
triggered by timeout, scsi dispatch failure. You will see that
easily if you run the SCSI test script I provided in the commit log.

-- 
Ming

[PATCH] perf tools: Fix compiling error in libunwind x86

[Wang Nan]

Fix a compiling error:

 ...
   CC   util/libunwind/x86_32.o
 In file included from util/libunwind/x86_32.c:33:0:
 util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function 
'libunwind__x86_reg_id':
 util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: error: 'EINVAL' 
undeclared (first use in this function)
return -EINVAL;
^
 util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: note: each 
undeclared identifier is reported only once for each function it appears in
 mv: cannot stat 'util/libunwind/.x86_32.o.tmp': No such file or directory
 make[4]: *** [util/libunwind/x86_32.o] Error 1
 make[3]: *** [util] Error 2
 make[2]: *** [libperf-in.o] Error 2
 make[1]: *** [sub-make] Error 2
 make: *** [all] Error 2

It happens when libunwind-x86 feature is detected.

Signed-off-by: Wang Nan 
---
 tools/perf/arch/x86/util/unwind-libunwind.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/x86/util/unwind-libunwind.c 
b/tools/perf/arch/x86/util/unwind-libunwind.c
index 9c917f8..05920e3 100644
--- a/tools/perf/arch/x86/util/unwind-libunwind.c
+++ b/tools/perf/arch/x86/util/unwind-libunwind.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
-#ifndef REMOTE_UNWIND_LIBUNWIND
 #include 
+#ifndef REMOTE_UNWIND_LIBUNWIND
 #include 
 #include "perf_regs.h"
 #include "../../util/unwind.h"
-- 
2.10.1

[PATCH v7 0/2] media: ov7740: Add a V4L2 sensor-level driver

[Wenyou Yang]

Add a Video4Linux2 sensor-level driver for the OmniVision OV7740
VGA camera image sensor.

Changes in v7:
 - Add Acked-by tag.
 - Fix the wrong handle of default register configuration.
 - Add the missed assignment of ov7740->frmsize.

Changes in v6:
 - Remove unnecessary #include .
 - Remove unnecessary comments and extra newline.
 - Add const for some structures.
 - Add the check of the return value from regmap_write().
 - Simplify the calling of __v4l2_ctrl_handler_setup().
 - Add the default format initialization function.
 - Integrate the set_power() and enable/disable the clock into
   one function.

Changes in v5:
 - Squash the driver and MAINTAINERS entry patches to one.
 - Precede the driver patch with the bindings patch.

Changes in v4:
 - Assign 'val' a initial value to avoid warning: 'val' may be
   used uninitialized.
 - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
 - Explicitly document the "remote-endpoint" property.
 - Put the MAINTAINERS change to a separate patch.

Changes in v2:
 - Split off the bindings into a separate patch.
 - Add a new entry to the MAINTAINERS file.

Wenyou Yang (2):
  media: ov7740: Document device tree bindings
  media: i2c: Add the ov7740 image sensor driver

 .../devicetree/bindings/media/i2c/ov7740.txt   |   47 +
 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |8 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7740.c | 1234 
 5 files changed, 1298 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
 create mode 100644 drivers/media/i2c/ov7740.c

-- 
2.15.0

Re: [PATCH 1/2] KVM: x86: fix APIC page invalidation

[Wanpeng Li]

2017-12-01 2:05 GMT+08:00 Radim Krčmář :
> Implementation of the unpinned APIC page didn't update the VMCS address
> cache when invalidation was done through range mmu notifiers.
> This became a problem when the page notifier was removed.
>
> Re-introduce the arch-specific helper and call it from ...range_start.
>
> Fixes: 38b9917350cb ("kvm: vmx: Implement set_apic_access_page_addr")
> Fixes: 369ea8242c0f ("mm/rmap: update to new mmu_notifier semantic v2")
> Signed-off-by: Radim Krčmář 

Tested-by: Wanpeng Li 

I observe the windows 2016 guest hang during boot on a heavy memory
overcommit host, and this commit fixes it.

Regards,
Wanpeng Li

> ---
>  arch/x86/include/asm/kvm_host.h |  3 +++
>  arch/x86/kvm/x86.c  | 14 ++
>  virt/kvm/kvm_main.c |  8 
>  3 files changed, 25 insertions(+)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 977de5fb968b..c16c3f924863 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1435,4 +1435,7 @@ static inline int kvm_cpu_get_apicid(int mps_cpu)
>  #define put_smstate(type, buf, offset, val)  \
> *(type *)((buf) + (offset) - 0x7e00) = val
>
> +void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> +   unsigned long start, unsigned long end);
> +
>  #endif /* _ASM_X86_KVM_HOST_H */
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index eee8e7faf1af..a219974cdb89 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6778,6 +6778,20 @@ static void kvm_vcpu_flush_tlb(struct kvm_vcpu *vcpu)
> kvm_x86_ops->tlb_flush(vcpu);
>  }
>
> +void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> +   unsigned long start, unsigned long end)
> +{
> +   unsigned long apic_address;
> +
> +   /*
> +* The physical address of apic access page is stored in the VMCS.
> +* Update it when it becomes invalid.
> +*/
> +   apic_address = gfn_to_hva(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
> +   if (start <= apic_address && apic_address < end)
> +   kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
> +}
> +
>  void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
>  {
> struct page *page = NULL;
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index c01cff064ec5..b7f4689e373f 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -135,6 +135,11 @@ static void kvm_uevent_notify_change(unsigned int type, 
> struct kvm *kvm);
>  static unsigned long long kvm_createvm_count;
>  static unsigned long long kvm_active_vms;
>
> +__weak void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> +   unsigned long start, unsigned long end)
> +{
> +}
> +
>  bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
>  {
> if (pfn_valid(pfn))
> @@ -360,6 +365,9 @@ static void 
> kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
> kvm_flush_remote_tlbs(kvm);
>
> spin_unlock(>mmu_lock);
> +
> +   kvm_arch_mmu_notifier_invalidate_range(kvm, start, end);
> +
> srcu_read_unlock(>srcu, idx);
>  }
>
> --
> 2.14.2
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

linux-next: build warnings after merge of the scsi tree

[Stephen Rothwell]

Hi James,

After merging the scsi tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

drivers/scsi/bfa/bfad_bsg.c: In function 'bfad_im_bsg_vendor_request':
drivers/scsi/bfa/bfad_bsg.c:3137:35: warning: initialization makes pointer from 
integer without a cast [-Wint-conversion]
  struct bfad_im_port_s *im_port = shost->hostdata[0];
   ^
drivers/scsi/bfa/bfad_bsg.c: In function 'bfad_im_bsg_els_ct_request':
drivers/scsi/bfa/bfad_bsg.c:3353:35: warning: initialization makes pointer from 
integer without a cast [-Wint-conversion]
  struct bfad_im_port_s *im_port = shost->hostdata[0];
   ^

Introduced by commit

  45349821ab3a ("scsi: bfa: fix access to bfad_im_port_s")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

[Chen-Yu Tsai]

On Wed, Dec 6, 2017 at 3:59 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote:
>> On the A64, the MMC module clocks are fixed in the new timing mode,
>> i.e. they do not have a bit to select the mode. These clocks have
>> a 2x divider somewhere between the clock and the MMC module.
>>
>> To be consistent with other SoCs supporting the new timing mode,
>> we model the 2x divider as a fixed post-divider on the MMC module
>> clocks.
>>
>> This patch adds the post-dividers to the MMC clocks.
>>
>> Signed-off-by: Chen-Yu Tsai 
>
> I had a doubt applying that one... sorry.
>
>> ---
>>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 
>> +++
>>  1 file changed, 37 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
>> b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> index 2bb4cabf802f..ee9c12cf3f08 100644
>> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> @@ -400,28 +400,45 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", 
>> mod0_default_parents, 0x080,
>> BIT(31),  /* gate */
>> 0);
>>
>> +/*
>> + * MMC clocks are the new timing mode (see A83T & H3) variety, but without
>> + * the mode switch. This means they have a 2x post divider between the clock
>> + * and the MMC module. This is not documented in the manual, but is taken
>> + * into consideration when setting the mmc module clocks in the BSP kernel.
>> + * Without it, MMC performance is degraded.
>> + *
>> + * We model it here to be consistent with other SoCs supporting this mode.
>> + * The alternative would be to add the 2x multiplier when setting the MMC
>> + * module clock in the MMC driver, just for the A64.
>> + */
>>  static const char * const mmc_default_parents[] = { "osc24M", 
>> "pll-periph0-2x",
>>   "pll-periph1-2x" };
>> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", mmc_default_parents, 
>> 0x088,
>> -   0, 4, /* M */
>> -   16, 2,/* P */
>> -   24, 2,/* mux */
>> -   BIT(31),  /* gate */
>> -   0);
>> -
>> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", mmc_default_parents, 
>> 0x08c,
>> -   0, 4, /* M */
>> -   16, 2,/* P */
>> -   24, 2,/* mux */
>> -   BIT(31),  /* gate */
>> -   0);
>> -
>> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mmc_default_parents, 
>> 0x090,
>> -   0, 4, /* M */
>> -   16, 2,/* P */
>> -   24, 2,/* mux */
>> -   BIT(31),  /* gate */
>> -   0);
>> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc0_clk, "mmc0",
>> +   mmc_default_parents, 0x088,
>> +   0, 4, /* M */
>> +   16, 2,/* P */
>> +   24, 2,/* mux */
>> +   BIT(31),  /* gate */
>> +   2,/* post-div */
>> +   0);
>> +
>> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc1_clk, "mmc1",
>> +   mmc_default_parents, 0x08c,
>> +   0, 4, /* M */
>> +   16, 2,/* P */
>> +   24, 2,/* mux */
>> +   BIT(31),  /* gate */
>> +   2,/* post-div */
>> +   0);
>> +
>
> Are you sure that the divider there for the non-eMMC clocks? Usually,
> the new mode is only here for the eMMC, so we would divide the rate by
> two in the non-eMMC case.

The new mode is there for all MMC controllers. The other two MMC
controllers even have the old/new timing mode switch. In case you
forgot we have ".need_new_timings" set for the A64 compatible.

But to eliminate any doubts or concerns, I've rerun tests for the
micro SD card, instead of the eMMC. And yes the results are the same,
2x improvement (12 MB/s vs 23.7 MB/s).

ChenYu

Re: [PATCH] ptr_ring: add barriers

[Jason Wang]

On 2017年12月06日 03:29, Michael S. Tsirkin wrote:

Users of ptr_ring expect that it's safe to give the
data structure a pointer and have it be available
to consumers, but that actually requires an smb_wmb
or a stronger barrier.

In absence of such barriers and on architectures that reorder writes,
consumer might read an un=initialized value from an skb pointer stored
in the skb array.  This was observed causing crashes.

To fix, add memory barriers.  The barrier we use is a wmb, the
assumption being that producers do not need to read the value so we do
not need to order these reads.

Reported-by: George Cherian 
Suggested-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
---

George, could you pls report whether this patch fixes
the issue for you?

This seems to be needed in stable as well.




  include/linux/ptr_ring.h | 9 +
  1 file changed, 9 insertions(+)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 37b4bb2..6866df4 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -101,12 +101,18 @@ static inline bool ptr_ring_full_bh(struct ptr_ring *r)
  
  /* Note: callers invoking this in a loop must use a compiler barrier,

   * for example cpu_relax(). Callers must hold producer_lock.
+ * Callers are responsible for making sure pointer that is being queued
+ * points to a valid data.
   */
  static inline int __ptr_ring_produce(struct ptr_ring *r, void *ptr)
  {
if (unlikely(!r->size) || r->queue[r->producer])
return -ENOSPC;
  
+	/* Make sure the pointer we are storing points to a valid data. */

+   /* Pairs with smp_read_barrier_depends in __ptr_ring_consume. */
+   smp_wmb();
+
r->queue[r->producer++] = ptr;
if (unlikely(r->producer >= r->size))
r->producer = 0;
@@ -275,6 +281,9 @@ static inline void *__ptr_ring_consume(struct ptr_ring *r)
if (ptr)
__ptr_ring_discard_one(r);
  
+	/* Make sure anyone accessing data through the pointer is up to date. */

+   /* Pairs with smp_wmb in __ptr_ring_produce. */
+   smp_read_barrier_depends();
return ptr;
  }
  


I was thinking whether or not it's better to move those to the callers. 
Then we can save lots of barriers in e.g batch consuming.


Thanks

[PATCH v2 3/3] ARM: dts: imx6sl-evk: Convert from fbdev to drm bindings

[Marco Franchi]

It is preferred to use the panel compatible string rather than passing 
the LCD timing in the device tree.

So pass the "sii,43wvf1g" compatible string which describes the parallel 
LCD.

Also, pass the 'backlight' property as described in 
Documentation/devicetree/bindings/display/panel/simple-panel.txt

Signed-off-by: Marco Franchi 
---
Changes since v1:
-change subject
-change message log
-includes into a set of patches
-fix regulator name and properties
 arch/arm/boot/dts/imx6sl-evk.dts | 48 
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index 645a460..a395de4 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -20,7 +20,7 @@
reg = <0x8000 0x4000>;
};
 
-   backlight {
+   backlight_display: backlight_display {
compatible = "pwm-backlight";
pwms = < 0 500>;
brightness-levels = <0 4 8 16 32 64 128 255>;
@@ -82,6 +82,13 @@
enable-active-high;
};
 
+   reg_lcd_5v: regulator-lcd-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "lcd-5v0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
sound {
compatible = "fsl,imx6sl-evk-wm8962", "fsl,imx-audio-wm8962";
model = "wm8962-audio";
@@ -97,6 +104,19 @@
mux-int-port = <2>;
mux-ext-port = <3>;
};
+
+   panel {
+   compatible = "sii,43wvf1g";
+   backlight = <_display>;
+   dvdd-supply = <_lcd_3v3>;
+   avdd-supply = <_lcd_5v>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
  {
@@ -535,31 +555,11 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_lcd>;
-   lcd-supply = <_lcd_3v3>;
-   display = <>;
status = "okay";
 
-   display0: display0 {
-   bits-per-pixel = <32>;
-   bus-width = <24>;
-
-   display-timings {
-   native-mode = <>;
-   timing0: timing0 {
-   clock-frequency = <3350>;
-   hactive = <800>;
-   vactive = <480>;
-   hback-porch = <89>;
-   hfront-porch = <164>;
-   vback-porch = <23>;
-   vfront-porch = <10>;
-   hsync-len = <10>;
-   vsync-len = <10>;
-   hsync-active = <0>;
-   vsync-active = <0>;
-   de-active = <1>;
-   pixelclk-active = <0>;
-   };
+   port {
+   display_out: endpoint {
+   remote-endpoint = <_in>;
};
};
 };
-- 
2.7.4

[PATCH v2 1/3] ARM: dts: imx6sx-sdb: Convert from fbdev to drm bindings

[Marco Franchi]

It is preferred to use the panel compatible string rather than passing
the LCD timing in the device tree.

So pass the "sii,43wvf1g" compatible string, which describes the parallel 
LCD.

Also pass the 'backlight' property as described in
Documentation/devicetree/bindings/display/panel/simple-panel.txt

Signed-off-by: Marco Franchi 
---
Changes since v1:
-change subject
-change message log
-includes into a set of patches
-rebase to linux-next
-fix regulator name and properties
 arch/arm/boot/dts/imx6sx-sdb.dtsi | 48 +++
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi 
b/arch/arm/boot/dts/imx6sx-sdb.dtsi
index d57a41c..d35aa85 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
@@ -24,7 +24,7 @@
reg = <0x8000 0x4000>;
};
 
-   backlight {
+   backlight_display: backlight-display {
compatible = "pwm-backlight";
pwms = < 0 500>;
brightness-levels = <0 4 8 16 32 64 128 255>;
@@ -129,6 +129,13 @@
enable-active-high;
};
 
+   reg_lcd_5v: regulator-lcd-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "lcd-5v0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
sound {
compatible = "fsl,imx6sx-sdb-wm8962", "fsl,imx-audio-wm8962";
model = "wm8962-audio";
@@ -144,6 +151,19 @@
mux-int-port = <2>;
mux-ext-port = <6>;
};
+
+   panel {
+   compatible = "sii,43wvf1g";
+   backlight = <_display>;
+   dvdd-supply = <_lcd_3v3>;
+   avdd-supply = <_lcd_5v>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
  {
@@ -221,31 +241,11 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_lcd>;
-   lcd-supply = <_lcd_3v3>;
-   display = <>;
status = "okay";
 
-   display0: display0 {
-   bits-per-pixel = <16>;
-   bus-width = <24>;
-
-   display-timings {
-   native-mode = <>;
-   timing0: timing0 {
-   clock-frequency = <3350>;
-   hactive = <800>;
-   vactive = <480>;
-   hback-porch = <89>;
-   hfront-porch = <164>;
-   vback-porch = <23>;
-   vfront-porch = <10>;
-   hsync-len = <10>;
-   vsync-len = <10>;
-   hsync-active = <0>;
-   vsync-active = <0>;
-   de-active = <1>;
-   pixelclk-active = <0>;
-   };
+   port {
+   display_out: endpoint {
+   remote-endpoint = <_in>;
};
};
 };
-- 
2.7.4