Re: [PATCH v4 02/14] mfd: wcd9335: add support to wcd9335 core

2018-10-24 Thread Lee Jones
On Sun, 16 Sep 2018, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC,
> It has mulitple blocks like Soundwire controller, codec,
> Codec processing engine, ClassH controller, interrupt mux.
> It supports both I2S/I2C and SLIMbus audio interfaces.
> 
> This patch adds support to SLIMbus audio interface.
> 
> Signed-off-by: Srinivas Kandagatla 
> Reviewed-by: Vinod Koul 
> ---
>  drivers/mfd/Kconfig   |  13 +
>  drivers/mfd/Makefile  |   4 +
>  drivers/mfd/wcd9335-core.c| 316 +
>  include/linux/mfd/wcd9335/registers.h | 640 
> ++
>  include/linux/mfd/wcd9335/wcd9335.h   |  45 +++
>  5 files changed, 1018 insertions(+)
>  create mode 100644 drivers/mfd/wcd9335-core.c
>  create mode 100644 include/linux/mfd/wcd9335/registers.h
>  create mode 100644 include/linux/mfd/wcd9335/wcd9335.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 11841f4..a7bff87 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1807,6 +1807,19 @@ config MFD_WM97xx
> support for the WM97xx, in order to use the actual functionaltiy of
> the device other drivers must be enabled.
>  
> +config MFD_WCD9335_SLIM
> + tristate "Qualcomm WCD9335 with SLIMbus"
> + select MFD_CORE
> + select REGMAP_IRQ
> + select REGMAP_SLIMBUS
> + depends on SLIMBUS
> + help
> +   The WCD9335 is a standalone Hi-Fi audio CODEC IC, supports Qualcomm
> +   Technologies, Inc. (QTI) multimedia solutions, including the MSM8996,
> +   MSM8976, and MSM8956 chipsets. It has in-build Soundwire controller,
> +   interrupt mux. It supports both I2S/I2C and SLIMbus audio interfaces.
> +   This option selects SLIMbus audio interface.
> +
>  config MFD_STW481X
>   tristate "Support for ST Microelectronics STw481x"
>   depends on I2C && (ARCH_NOMADIK || COMPILE_TEST)
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 5856a94..9d0b98d 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -56,6 +56,10 @@ endif
>  ifeq ($(CONFIG_MFD_CS47L24),y)
>  obj-$(CONFIG_MFD_ARIZONA)+= cs47l24-tables.o
>  endif
> +
> +obj-$(CONFIG_MFD_WCD9335_SLIM)   += wcd9335.o
> +wcd9335-objs := wcd9335-core.o
> +
>  obj-$(CONFIG_MFD_WM8400) += wm8400-core.o
>  wm831x-objs  := wm831x-core.o wm831x-irq.o wm831x-otp.o
>  wm831x-objs  += wm831x-auxadc.o
> diff --git a/drivers/mfd/wcd9335-core.c b/drivers/mfd/wcd9335-core.c
> new file mode 100644
> index 000..81ec0fc
> --- /dev/null
> +++ b/drivers/mfd/wcd9335-core.c
> @@ -0,0 +1,316 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018, Linaro Limited
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define WCD9335_SLIM_INTERFACE_DEVICE_INDEX  0
> +
> +static const struct mfd_cell wcd9335_devices[] = {
> + { .name = "wcd9335-codec", },
> +};

Any news on other devices?

> +static const struct regmap_range_cfg wcd9335_ranges[] = {
> + {
> + .name = "WCD9335",
> + .range_min =  0x0,
> + .range_max =  WCD9335_MAX_REGISTER,
> + .selector_reg = WCD9335_REG(0x0, 0),
> + .selector_mask = 0xff,
> + .selector_shift = 0,
> + .window_start = 0x0,
> + .window_len = 0x1000,
> + },
> +};
> +
> +static bool wcd9335_is_volatile_register(struct device *dev, unsigned int 
> reg)
> +{
> + switch (reg) {
> + case WCD9335_INTR_PIN1_STATUS0...WCD9335_INTR_PIN2_CLEAR3:
> + case WCD9335_ANA_MBHC_RESULT_3:
> + case WCD9335_ANA_MBHC_RESULT_2:
> + case WCD9335_ANA_MBHC_RESULT_1:
> + case WCD9335_ANA_MBHC_MECH:
> + case WCD9335_ANA_MBHC_ELECT:
> + case WCD9335_ANA_MBHC_ZDET:
> + case WCD9335_ANA_MICB2:
> + case WCD9335_ANA_RCO:
> + case WCD9335_ANA_BIAS:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static struct regmap_config wcd9335_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 8,
> + .cache_type = REGCACHE_RBTREE,
> + .max_register = WCD9335_MAX_REGISTER,
> + .can_multi_write = true,
> + .ranges = wcd9335_ranges,
> + .num_ranges = ARRAY_SIZE(wcd9335_ranges),
> + .volatile_reg = wcd9335_is_volatile_register,
> +};
> +
> +static const struct regmap_range_cfg wcd9335_interface_ranges[] = {
> + {
> + .name = "WCD9335-Interface",
> + .range_min =  0x0,
> + .range_max = WCD9335_REG(0, 0x7ff),
> + .selector_reg = WCD9335_REG(0, 0x0),
> + .selector_mask = 0xff,
> + .selector_shift = 0,
> + .window_start = 0x0,
> + .window_len = 0x1000,
> + }

Re: [PATCH 4/5] spi: lpspi: enable runtime pm for lpspi

2018-10-24 Thread kbuild test robot
Hi Clark,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on spi/for-next]
[also build test ERROR on next-20181019]
[cannot apply to v4.19]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Clark-Wang/spi-lpspi-Add-slave-mode-support-for-imx7ulp/20181024-125200
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_transfer_one':
   drivers/spi/spi-fsl-lpspi.c:399:8: error: implicit declaration of function 
'fsl_lpspi_txfifo_empty'; did you mean 'fsl_lpspi_set_cmd'? 
[-Werror=implicit-function-declaration]
 ret = fsl_lpspi_txfifo_empty(fsl_lpspi);
   ^~
   fsl_lpspi_set_cmd
   drivers/spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_suspend':
   drivers/spi/spi-fsl-lpspi.c:622:2: error: implicit declaration of function 
'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
 pinctrl_pm_select_sleep_state(dev);
 ^
   drivers/spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_resume':
>> drivers/spi/spi-fsl-lpspi.c:637:2: error: implicit declaration of function 
>> 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration]
 pinctrl_pm_select_default_state(dev);
 ^~~
   cc1: some warnings being treated as errors

vim +/pinctrl_pm_select_default_state +637 drivers/spi/spi-fsl-lpspi.c

   626  
   627  static int fsl_lpspi_resume(struct device *dev)
   628  {
   629  int ret;
   630  
   631  ret = pm_runtime_force_resume(dev);
   632  if (ret) {
   633  dev_err(dev, "Error in resume: %d\n", ret);
   634  return ret;
   635  }
   636  
 > 637  pinctrl_pm_select_default_state(dev);
   638  
   639  return 0;
   640  }
   641  #endif /* CONFIG_PM_SLEEP */
   642  

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


.config.gz
Description: application/gzip


Re: [PATCH V9 21/21] csky: support dword access for get_user_size()

2018-10-24 Thread Arnd Bergmann
On Thu, Oct 18, 2018 at 9:57 AM Guo Ren  wrote:
>
> On Thu, Oct 18, 2018 at 10:34:00AM +0200, Arnd Bergmann wrote:
> > On Thu, Oct 18, 2018 at 5:41 AM Guo Ren  wrote:
> > >
> > > On Wed, Oct 17, 2018 at 05:44:17PM +0200, Arnd Bergmann wrote:
> > > > On Tue, Oct 16, 2018 at 5:33 AM Guo Ren  wrote:
> > > > >
> > > > > Support dword access for get_user_size and redesign put_user_size with
> > > > > the same style of get_user_size. It's Ok to use xxx_user_asm_common 
> > > > > for
> > > > > all size of variable with ldb, ldh, ldw, ld.d
> > > > >
> > > > > ld.d rx, (addr, 0) could "rx <= addr" "and r(x+1) <= addr+4" and this 
> > > > > also
> > > > > follow abiv2 gcc ABI for dword access.
> > > >
> > > > Are you sure this is correct for this?
> > > >
> > > > static inline u32 get_64_to_32(__u64 __user *p)
> > > > {
> > > >   u32 ret;
> > > >   get_user(ret, p);
> > > >   return ret;
> > > > }
> > > >
> > > > If I read __get_user_asm_common() right, the ld.d would overwrite
> > > > two registers, but the caller only expects one, so it clobbers one
> > > > that might be in use.
> > > Ah... BUG! I only consider the get_user(u64, u64 *) :P
> > >
> > > Change to:
> > > case 8: \
> > > __get_user_asm_dword((x), ptr, "ld.d", retval); \
> > > break;
> > >
> > > #define __get_user_asm_dword(x, ptr, err)   \
> > > do {\
> > > u64 tmp;\
> > > __get_user_asm_common(tmp, ptr, "ld.d", err);   \
> > > x = typeof(x) tmp;  \
> > > } while(0)
> > >
> > > #define __put_user_asm_dword(x, ptr, err)   \
> > > do {\
> > > u64 tmp = (u64) x;  \
> > > __put_user_asm_common(tmp, ptr, "st.d", err);   \
> > > } while(0)
> > >
> >
> > I think this will cause warnings for code that passes a pointer.
> >
> > The 64-bit __get_user() is really hard, and most 32-bit architectures don't
> > implement it at all. If you really want to add it, have a look at what
> > x86 and arm do. IIRC they both use __builtin_choose_expr(),
> Thx for the tips and I'll drop the patch first for the upstream.
>
> I want to implement it because of make allmodconfig and
> drivers/android/binder.c need it. I'll learn __builtin_choose_expr()
> and prepare patch next.

I think we should fix binder.c instead. Many other architectures
have the same problem.

  Arnd


[PATCH] mmc: sdhci: Conver sdhci_allocate_bounce_buffer() to return void

2018-10-24 Thread Chunyan Zhang
The function sdhci_allocate_bounce_buffer() always return zero at
present, so there's no need to have a return value, that will also make
error path easier.

CC: Linus Walleij 
Signed-off-by: Chunyan Zhang 
---
 drivers/mmc/host/sdhci.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1b3fbd9..e94f4aa 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3408,7 +3408,7 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, 
u32 *caps, u32 *caps1)
 }
 EXPORT_SYMBOL_GPL(__sdhci_read_caps);
 
-static int sdhci_allocate_bounce_buffer(struct sdhci_host *host)
+static void sdhci_allocate_bounce_buffer(struct sdhci_host *host)
 {
struct mmc_host *mmc = host->mmc;
unsigned int max_blocks;
@@ -3446,7 +3446,7 @@ static int sdhci_allocate_bounce_buffer(struct sdhci_host 
*host)
 * Exiting with zero here makes sure we proceed with
 * mmc->max_segs == 1.
 */
-   return 0;
+   return;
}
 
host->bounce_addr = dma_map_single(mmc->parent,
@@ -3456,7 +3456,7 @@ static int sdhci_allocate_bounce_buffer(struct sdhci_host 
*host)
ret = dma_mapping_error(mmc->parent, host->bounce_addr);
if (ret)
/* Again fall back to max_segs == 1 */
-   return 0;
+   return;
host->bounce_buffer_size = bounce_size;
 
/* Lie about this since we're bouncing */
@@ -3466,8 +3466,6 @@ static int sdhci_allocate_bounce_buffer(struct sdhci_host 
*host)
 
pr_info("%s bounce up to %u segments into one, max segment size %u 
bytes\n",
mmc_hostname(mmc), max_blocks, bounce_size);
-
-   return 0;
 }
 
 int sdhci_setup_host(struct sdhci_host *host)
@@ -3987,12 +3985,9 @@ int sdhci_setup_host(struct sdhci_host *host)
 */
mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 
65535;
 
-   if (mmc->max_segs == 1) {
+   if (mmc->max_segs == 1)
/* This may alter mmc->*_blk_* parameters */
-   ret = sdhci_allocate_bounce_buffer(host);
-   if (ret)
-   return ret;
-   }
+   sdhci_allocate_bounce_buffer(host);
 
return 0;
 
-- 
2.7.4



Re: [PATCH] thermal: add ratelimited thermal and power logging

2018-10-24 Thread Viresh Kumar
On 22-10-18, 14:29, Ross Zwisler wrote:
> From: Ricky Liang 
> 
> Add thermal logs in devfreq_cooling and cpu_cooling.

Why should we add them ?

> Also add logging to
> power_allocator when it starts to control power.
> 
> These changes can lead to excessive log spam when running up against
> thermal limits, so have this logging ratelimited to allow only 1 log each
> 30 seconds from each of those subsystems.

What's the use of these logs when we are going to print them only once every 30
seconds ?

I recently extended thermal sysfs support to share more stats.

commit 8ea229511e06 ("thermal: Add cooling device's statistics in sysfs")

Will that be helpful in your case ?

Otherwise we should probably add trace points instead.

-- 
viresh


[PATCH v2 0/3] Add Bitstream configuration support for ZynqMP

2018-10-24 Thread Nava kishore Manne
This series of patches are created On top of the
below repo.
//git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
BRANCH: next/drivers. 

Nava kishore Manne (3):
  firmware: xilinx: Add fpga API's
  dt-bindings: fpga: Add bindings for ZynqMP fpga driver
  fpga manager: Adding FPGA Manager support for Xilinx zynqmp

 .../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt   |  13 ++
 drivers/firmware/xilinx/zynqmp.c  |  46 +
 drivers/fpga/Kconfig  |   9 +
 drivers/fpga/Makefile |   1 +
 drivers/fpga/zynqmp-fpga.c| 165 ++
 include/linux/firmware/xlnx-zynqmp.h  |  12 ++
 6 files changed, 246 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
 create mode 100644 drivers/fpga/zynqmp-fpga.c

-- 
2.18.0



Re: [PATCH v2 0/9] of: fix compatible-child-node lookups

2018-10-24 Thread Johan Hovold
On Tue, Oct 23, 2018 at 01:32:56PM -0500, Rob Herring wrote:
> On Tue, Oct 23, 2018 at 4:21 AM Johan Hovold  wrote:
> >
> > Hi Rob,
> >
> > On Tue, Sep 04, 2018 at 03:05:57PM +0200, Johan Hovold wrote:

> > > I think Rob will be picking up any patches that remain by the end of the
> > > release cycle for 4.20.
> >
> > So far only Ulf has picked up the mmc patch below directly, so if you
> > could take the rest through your tree for -rc1 that would be great.
> 
> Thanks for the reminder, though before the merge window opened would
> have been better. I've applied all but the mtd patch.

Yeah, sorry about that, this slipped my mind. Thanks for picking them
up.

Johan


[PATCH v2 1/3] firmware: xilinx: Add fpga API's

2018-10-24 Thread Nava kishore Manne
This Patch Adds fpga API's to support the Bitstream loading
by using firmware interface.

Signed-off-by: Nava kishore Manne 
---
This patch depends on the below series of patches
https://lkml.org/lkml/2018/9/12/983
Which is got integrated into the below upstream repo.
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/tree/drivers/firmware/xilinx?h=for-next

Changes for v2:
-Added Firmware FPGA Manager flags As suggested by
 Moritz.
Changes for v1:
-None.

Changes for RFC-V2:
-New Patch.

 drivers/firmware/xilinx/zynqmp.c | 46 
 include/linux/firmware/xlnx-zynqmp.h | 12 
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2eca8b..4a5919448198 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -428,6 +428,50 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32 
*parent_id)
return ret;
 }
 
+/**
+ * zynqmp_pm_fpga_load - Perform the fpga load
+ * @address:   Address to write to
+ * @size:  pl bitstream size
+ * @flags:
+ * BIT(0) - Bit-stream type.
+ *  0 - Full Bitstream.
+ *  1 - Partial Bitstream.
+ *
+ * This function provides access to pmufw. To transfer
+ * the required bitstream into PL.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_fpga_load(const u64 address, const u32 size,
+  const u32 flags)
+{
+   return zynqmp_pm_invoke_fn(PM_FPGA_LOAD, lower_32_bits(address),
+  upper_32_bits(address), size, flags, NULL);
+}
+
+/**
+ * zynqmp_pm_fpga_get_status - Read value from PCAP status register
+ * @value: Value to read
+ *
+ * This function provides access to the xilfpga library to get
+ * the PCAP status
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_fpga_get_status(u32 *value)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!value)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_FPGA_GET_STATUS, 0, 0, 0, 0, ret_payload);
+   *value = ret_payload[1];
+
+   return ret;
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -440,6 +484,8 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_getrate = zynqmp_pm_clock_getrate,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
+   .fpga_load = zynqmp_pm_fpga_load,
+   .fpga_get_status = zynqmp_pm_fpga_get_status,
 };
 
 /**
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130431e6..0f900b48e1be 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -32,8 +32,18 @@
 /* Number of 32bits values in payload */
 #define PAYLOAD_ARG_CNT4U
 
+/*
+ * Firmware FPGA Manager flags
+ * XILINX_ZYNQMP_PM_FPGA_PARTIAL: FPGA partial reconfiguration
+ */
+#define XILINX_ZYNQMP_PM_FPGA_PARTIAL  BIT(0)
+
+
+
 enum pm_api_id {
PM_GET_API_VERSION = 1,
+   PM_FPGA_LOAD = 22,
+   PM_FPGA_GET_STATUS,
PM_QUERY_DATA = 35,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
@@ -89,6 +99,8 @@ struct zynqmp_pm_query_data {
 
 struct zynqmp_eemi_ops {
int (*get_api_version)(u32 *version);
+   int (*fpga_load)(const u64 address, const u32 size, const u32 flags);
+   int (*fpga_get_status)(u32 *value);
int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
int (*clock_enable)(u32 clock_id);
int (*clock_disable)(u32 clock_id);
-- 
2.18.0



[PATCH v3 5/7] net: ethernet: stmmac: dwmac-sun8i: use xxxsetbits_le32

2018-10-24 Thread Corentin Labbe
This patch convert dwmac-sun8i driver to use all xxxsetbits_le32 functions.

Signed-off-by: Corentin Labbe 
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 62 +--
 1 file changed, 16 insertions(+), 46 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index f9a61f90cfbc..74067a59af50 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "stmmac.h"
 #include "stmmac_platform.h"
@@ -342,50 +343,30 @@ static void sun8i_dwmac_disable_dma_irq(void __iomem 
*ioaddr, u32 chan)
 
 static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
 {
-   u32 v;
-
-   v = readl(ioaddr + EMAC_TX_CTL1);
-   v |= EMAC_TX_DMA_START;
-   v |= EMAC_TX_DMA_EN;
-   writel(v, ioaddr + EMAC_TX_CTL1);
+   setbits_le32(ioaddr + EMAC_TX_CTL1,
+EMAC_TX_DMA_START | EMAC_TX_DMA_EN);
 }
 
 static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
 {
-   u32 v;
-
-   v = readl(ioaddr + EMAC_TX_CTL1);
-   v |= EMAC_TX_DMA_START;
-   v |= EMAC_TX_DMA_EN;
-   writel(v, ioaddr + EMAC_TX_CTL1);
+   setbits_le32(ioaddr + EMAC_TX_CTL1,
+EMAC_TX_DMA_START | EMAC_TX_DMA_EN);
 }
 
 static void sun8i_dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
 {
-   u32 v;
-
-   v = readl(ioaddr + EMAC_TX_CTL1);
-   v &= ~EMAC_TX_DMA_EN;
-   writel(v, ioaddr + EMAC_TX_CTL1);
+   clrbits_le32(ioaddr + EMAC_TX_CTL1, EMAC_TX_DMA_EN);
 }
 
 static void sun8i_dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
 {
-   u32 v;
-
-   v = readl(ioaddr + EMAC_RX_CTL1);
-   v |= EMAC_RX_DMA_START;
-   v |= EMAC_RX_DMA_EN;
-   writel(v, ioaddr + EMAC_RX_CTL1);
+   setbits_le32(ioaddr + EMAC_RX_CTL1,
+EMAC_RX_DMA_START | EMAC_RX_DMA_EN);
 }
 
 static void sun8i_dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
 {
-   u32 v;
-
-   v = readl(ioaddr + EMAC_RX_CTL1);
-   v &= ~EMAC_RX_DMA_EN;
-   writel(v, ioaddr + EMAC_RX_CTL1);
+   clrbits_le32(ioaddr + EMAC_RX_CTL1, EMAC_RX_DMA_EN);
 }
 
 static int sun8i_dwmac_dma_interrupt(void __iomem *ioaddr,
@@ -578,7 +559,6 @@ static void sun8i_dwmac_set_umac_addr(struct 
mac_device_info *hw,
  unsigned int reg_n)
 {
void __iomem *ioaddr = hw->pcsr;
-   u32 v;
 
if (!addr) {
writel(0, ioaddr + EMAC_MACADDR_HI(reg_n));
@@ -588,9 +568,8 @@ static void sun8i_dwmac_set_umac_addr(struct 
mac_device_info *hw,
stmmac_set_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
EMAC_MACADDR_LO(reg_n));
if (reg_n > 0) {
-   v = readl(ioaddr + EMAC_MACADDR_HI(reg_n));
-   v |= MAC_ADDR_TYPE_DST;
-   writel(v, ioaddr + EMAC_MACADDR_HI(reg_n));
+   setbits_le32(ioaddr + EMAC_MACADDR_HI(reg_n),
+MAC_ADDR_TYPE_DST);
}
 }
 
@@ -608,11 +587,8 @@ static void sun8i_dwmac_get_umac_addr(struct 
mac_device_info *hw,
 static int sun8i_dwmac_rx_ipc_enable(struct mac_device_info *hw)
 {
void __iomem *ioaddr = hw->pcsr;
-   u32 v;
 
-   v = readl(ioaddr + EMAC_RX_CTL0);
-   v |= EMAC_RX_DO_CRC;
-   writel(v, ioaddr + EMAC_RX_CTL0);
+   setbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_DO_CRC);
 
return 1;
 }
@@ -662,21 +638,15 @@ static void sun8i_dwmac_flow_ctrl(struct mac_device_info 
*hw,
  unsigned int pause_time, u32 tx_cnt)
 {
void __iomem *ioaddr = hw->pcsr;
-   u32 v;
 
-   v = readl(ioaddr + EMAC_RX_CTL0);
if (fc == FLOW_AUTO)
-   v |= EMAC_RX_FLOW_CTL_EN;
+   setbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_FLOW_CTL_EN);
else
-   v &= ~EMAC_RX_FLOW_CTL_EN;
-   writel(v, ioaddr + EMAC_RX_CTL0);
-
-   v = readl(ioaddr + EMAC_TX_FLOW_CTL);
+   clrbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_FLOW_CTL_EN);
if (fc == FLOW_AUTO)
-   v |= EMAC_TX_FLOW_CTL_EN;
+   setbits_le32(ioaddr + EMAC_TX_FLOW_CTL, EMAC_TX_FLOW_CTL_EN);
else
-   v &= ~EMAC_TX_FLOW_CTL_EN;
-   writel(v, ioaddr + EMAC_TX_FLOW_CTL);
+   clrbits_le32(ioaddr + EMAC_TX_FLOW_CTL, EMAC_TX_FLOW_CTL_EN);
 }
 
 static int sun8i_dwmac_reset(struct stmmac_priv *priv)
-- 
2.18.1



[PATCH v3 1/7] powerpc: rename setbits32/clrbits32 to setbits_be32/clrbits_be32

2018-10-24 Thread Corentin Labbe
Since setbits32/clrbits32 work on be32, it's better to remove ambiguity on
the used data type.

Signed-off-by: Corentin Labbe 
---
 arch/powerpc/include/asm/fsl_lbc.h|  2 +-
 arch/powerpc/include/asm/io.h |  4 +-
 arch/powerpc/platforms/44x/canyonlands.c  |  4 +-
 arch/powerpc/platforms/4xx/gpio.c | 28 +++
 arch/powerpc/platforms/512x/pdm360ng.c|  6 +-
 arch/powerpc/platforms/52xx/mpc52xx_common.c  |  6 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 12 +--
 arch/powerpc/platforms/82xx/ep8248e.c |  2 +-
 arch/powerpc/platforms/82xx/km82xx.c  |  6 +-
 arch/powerpc/platforms/82xx/mpc8272_ads.c | 10 +--
 arch/powerpc/platforms/82xx/pq2.c |  2 +-
 arch/powerpc/platforms/82xx/pq2ads-pci-pic.c  |  4 +-
 arch/powerpc/platforms/82xx/pq2fads.c | 10 +--
 arch/powerpc/platforms/83xx/km83xx.c  |  6 +-
 arch/powerpc/platforms/83xx/mpc836x_mds.c |  2 +-
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |  2 +-
 arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c  |  4 +-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  2 +-
 arch/powerpc/platforms/85xx/p1022_ds.c|  6 +-
 arch/powerpc/platforms/85xx/p1022_rdk.c   |  6 +-
 arch/powerpc/platforms/85xx/t1042rdb_diu.c|  6 +-
 arch/powerpc/platforms/85xx/twr_p102x.c   |  2 +-
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c|  6 +-
 arch/powerpc/platforms/8xx/adder875.c |  2 +-
 arch/powerpc/platforms/8xx/m8xx_setup.c   |  4 +-
 arch/powerpc/platforms/8xx/mpc86xads_setup.c  |  4 +-
 arch/powerpc/platforms/8xx/mpc885ads_setup.c  | 28 +++
 .../platforms/embedded6xx/flipper-pic.c   |  6 +-
 arch/powerpc/platforms/embedded6xx/hlwd-pic.c |  8 +-
 arch/powerpc/platforms/embedded6xx/wii.c  | 12 +--
 arch/powerpc/sysdev/cpm1.c| 26 +++
 arch/powerpc/sysdev/cpm2.c| 16 ++--
 arch/powerpc/sysdev/cpm_common.c  |  4 +-
 arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 16 ++--
 arch/powerpc/sysdev/fsl_lbc.c |  2 +-
 arch/powerpc/sysdev/fsl_pci.c | 12 +--
 arch/powerpc/sysdev/fsl_pmc.c |  2 +-
 arch/powerpc/sysdev/fsl_rcpm.c| 74 +--
 arch/powerpc/sysdev/fsl_rio.c |  4 +-
 arch/powerpc/sysdev/fsl_rmu.c |  9 ++-
 arch/powerpc/sysdev/mpic_timer.c  | 12 +--
 41 files changed, 190 insertions(+), 189 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_lbc.h 
b/arch/powerpc/include/asm/fsl_lbc.h
index c7240a024b96..4d6a56b48a28 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -276,7 +276,7 @@ static inline void fsl_upm_start_pattern(struct fsl_upm 
*upm, u8 pat_offset)
  */
 static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
 {
-   clrbits32(upm->mxmr, MxMR_OP_RP);
+   clrbits_be32(upm->mxmr, MxMR_OP_RP);
 
while (in_be32(upm->mxmr) & MxMR_OP_RP)
cpu_relax();
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 0a034519957d..bc2fc014fd4f 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -882,8 +882,8 @@ static inline void * bus_to_virt(unsigned long address)
 #endif /* CONFIG_PPC32 */
 
 /* access ports */
-#define setbits32(_addr, _v) out_be32((_addr), in_be32(_addr) |  (_v))
-#define clrbits32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
+#define setbits_be32(_addr, _v) out_be32((_addr), in_be32(_addr) |  (_v))
+#define clrbits_be32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
 
 #define setbits16(_addr, _v) out_be16((_addr), in_be16(_addr) |  (_v))
 #define clrbits16(_addr, _v) out_be16((_addr), in_be16(_addr) & ~(_v))
diff --git a/arch/powerpc/platforms/44x/canyonlands.c 
b/arch/powerpc/platforms/44x/canyonlands.c
index 157f4ce46386..6aeb4ca64d09 100644
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -113,8 +113,8 @@ static int __init ppc460ex_canyonlands_fixup(void)
 * USB2HStop and gpio19 will be USB2DStop. For more details refer to
 * table 34-7 of PPC460EX user manual.
 */
-   setbits32((vaddr + GPIO0_OSRH), 0x4200);
-   setbits32((vaddr + GPIO0_TSRH), 0x4200);
+   setbits_be32((vaddr + GPIO0_OSRH), 0x4200);
+   setbits_be32((vaddr + GPIO0_TSRH), 0x4200);
 err_gpio:
iounmap(vaddr);
 err_bcsr:
diff --git a/arch/powerpc/platforms/4xx/gpio.c 
b/arch/powerpc/platforms/4xx/gpio.c
index 2238e369cde4..8436da0617fd 100644
--- a/arch/powerpc/platforms/4xx/gpio.c
+++ b/arch/powerpc/platforms/4xx/gpio.c
@@ -82,9 +82,9 @@ __ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, 
int val)
struct ppc4xx_gpio __iomem *regs = mm_gc->regs;
 
if (val)
-   setbits32(®s->or, GPIO_MASK(gpio));
+   setbits_be32(®s->or, GPIO_MASK(gpio));
else
-   clrbits32(®s->or

[PATCH v3 2/7] include: add setbits_leXX/clrbits_leXX/clrsetbits_leXX in linux/setbits.h

2018-10-24 Thread Corentin Labbe
This patch adds setbits_le32/clrbits_le32/clrsetbits_le32 and
setbits_le64/clrbits_le64/clrsetbits_le64 in linux/setbits.h header.

Signed-off-by: Corentin Labbe 
---
 include/linux/setbits.h | 84 +
 1 file changed, 84 insertions(+)
 create mode 100644 include/linux/setbits.h

diff --git a/include/linux/setbits.h b/include/linux/setbits.h
new file mode 100644
index ..c82faf8d7fe4
--- /dev/null
+++ b/include/linux/setbits.h
@@ -0,0 +1,84 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_SETBITS_H
+#define __LINUX_SETBITS_H
+
+#include 
+
+#define __setbits(rfn, wfn, addr, set) wfn((rfn(addr) | (set)), addr)
+#define __clrbits(rfn, wfn, addr, mask) wfn((rfn(addr) & ~(mask)), addr)
+#define __clrsetbits(rfn, wfn, addr, mask, set) wfn(((rfn(addr) & ~(mask)) | 
(set)), addr)
+#define __setclrbits(rfn, wfn, addr, mask, set) wfn(((rfn(addr) | (set)) & 
~(mask)), addr)
+
+#ifndef setbits_le32
+#define setbits_le32(addr, set) __setbits(readl, writel, addr, set)
+#endif
+#ifndef setbits_le32_relaxed
+#define setbits_le32_relaxed(addr, set) __setbits(readl_relaxed, 
writel_relaxed, \
+  addr, set)
+#endif
+
+#ifndef clrbits_le32
+#define clrbits_le32(addr, mask) __clrbits(readl, writel, addr, mask)
+#endif
+#ifndef clrbits_le32_relaxed
+#define clrbits_le32_relaxed(addr, mask) __clrbits(readl_relaxed, 
writel_relaxed, \
+   addr, mask)
+#endif
+
+#ifndef clrsetbits_le32
+#define clrsetbits_le32(addr, mask, set) __clrsetbits(readl, writel, addr, 
mask, set)
+#endif
+#ifndef clrsetbits_le32_relaxed
+#define clrsetbits_le32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \
+  writel_relaxed, \
+  addr, mask, set)
+#endif
+
+#ifndef setclrbits_le32
+#define setclrbits_le32(addr, mask, set) __setclrbits(readl, writel, addr, 
mask, set)
+#endif
+#ifndef setclrbits_le32_relaxed
+#define setclrbits_le32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \
+  writel_relaxed, \
+  addr, mask, set)
+#endif
+
+/* We cannot use CONFIG_64BIT as some x86 drivers use non-atomicwriteq() */
+#if defined(writeq) && defined(readq)
+#ifndef setbits_le64
+#define setbits_le64(addr, set) __setbits(readq, writeq, addr, set)
+#endif
+#ifndef setbits_le64_relaxed
+#define setbits_le64_relaxed(addr, set) __setbits(readq_relaxed, 
writeq_relaxed, \
+  addr, set)
+#endif
+
+#ifndef clrbits_le64
+#define clrbits_le64(addr, mask) __clrbits(readq, writeq, addr, mask)
+#endif
+#ifndef clrbits_le64_relaxed
+#define clrbits_le64_relaxed(addr, mask) __clrbits(readq_relaxed, 
writeq_relaxed, \
+   addr, mask)
+#endif
+
+#ifndef clrsetbits_le64
+#define clrsetbits_le64(addr, mask, set) __clrsetbits(readq, writeq, addr, 
mask, set)
+#endif
+#ifndef clrsetbits_le64_relaxed
+#define clrsetbits_le64_relaxed(addr, mask, set) __clrsetbits(readq_relaxed, \
+  writeq_relaxed, \
+  addr, mask, set)
+#endif
+
+#ifndef setclrbits_le64
+#define setclrbits_le64(addr, mask, set) __setclrbits(readq, writeq, addr, 
mask, set)
+#endif
+#ifndef setclrbits_le64_relaxed
+#define setclrbits_le64_relaxed(addr, mask, set) __setclrbits(readq_relaxed, \
+  writeq_relaxed, \
+  addr, mask, set)
+#endif
+
+#endif /* writeq/readq */
+
+#endif /* __LINUX_SETBITS_H */
-- 
2.18.1



[PATCH v3 6/7] drm: meson: use xxxsetbits_le32

2018-10-24 Thread Corentin Labbe
This patch convert meson DRM driver to use all xxxsetbits_le32 functions.

Signed-off-by: Corentin Labbe 
Reviewed-by: Neil Armstrong 
Tested-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c  | 14 +++---
 drivers/gpu/drm/meson/meson_dw_hdmi.c   | 33 +++--
 drivers/gpu/drm/meson/meson_plane.c | 13 ++---
 drivers/gpu/drm/meson/meson_registers.h |  3 --
 drivers/gpu/drm/meson/meson_venc.c  | 13 ++---
 drivers/gpu/drm/meson/meson_venc_cvbs.c |  4 +-
 drivers/gpu/drm/meson/meson_viu.c   | 65 +
 drivers/gpu/drm/meson/meson_vpp.c   | 22 -
 8 files changed, 86 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index 05520202c967..98f17ddd6b00 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -98,8 +99,8 @@ static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
writel(crtc_state->mode.hdisplay,
   priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
 
-   writel_bits_relaxed(VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE,
-   priv->io_base + _REG(VPP_MISC));
+   clrsetbits_le32_relaxed(priv->io_base + _REG(VPP_MISC),
+   VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE);
 
priv->viu.osd1_enabled = true;
 }
@@ -114,8 +115,8 @@ static void meson_crtc_atomic_disable(struct drm_crtc *crtc,
priv->viu.osd1_commit = false;
 
/* Disable VPP Postblend */
-   writel_bits_relaxed(VPP_POSTBLEND_ENABLE, 0,
-   priv->io_base + _REG(VPP_MISC));
+   clrsetbits_le32_relaxed(priv->io_base + _REG(VPP_MISC),
+   VPP_POSTBLEND_ENABLE, 0);
 
if (crtc->state->event && !crtc->state->active) {
spin_lock_irq(&crtc->dev->event_lock);
@@ -199,8 +200,9 @@ void meson_crtc_irq(struct meson_drm *priv)
   MESON_CANVAS_BLKMODE_LINEAR);
 
/* Enable OSD1 */
-   writel_bits_relaxed(VPP_OSD1_POSTBLEND, VPP_OSD1_POSTBLEND,
-   priv->io_base + _REG(VPP_MISC));
+   clrsetbits_le32_relaxed(priv->io_base + _REG(VPP_MISC),
+   VPP_OSD1_POSTBLEND,
+   VPP_OSD1_POSTBLEND);
 
priv->viu.osd1_commit = false;
}
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index df7247cd93f9..99a136209e15 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -427,10 +428,10 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
*data,
writel_relaxed(0, priv->io_base + _REG(ENCP_VIDEO_EN));
 
/* Temporary Disable HDMI video stream to HDMI-TX */
-   writel_bits_relaxed(0x3, 0,
-   priv->io_base + _REG(VPU_HDMI_SETTING));
-   writel_bits_relaxed(0xf << 8, 0,
-   priv->io_base + _REG(VPU_HDMI_SETTING));
+   clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING), 0x3,
+   0);
+   clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING),
+   0xf << 8, 0);
 
/* Re-Enable VENC video stream */
if (priv->venc.hdmi_use_enci)
@@ -439,16 +440,16 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
*data,
writel_relaxed(1, priv->io_base + _REG(ENCP_VIDEO_EN));
 
/* Push back HDMI clock settings */
-   writel_bits_relaxed(0xf << 8, wr_clk & (0xf << 8),
-   priv->io_base + _REG(VPU_HDMI_SETTING));
+   clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING),
+   0xf << 8, wr_clk & (0xf << 8));
 
/* Enable and Select HDMI video source for HDMI-TX */
if (priv->venc.hdmi_use_enci)
-   writel_bits_relaxed(0x3, MESON_VENC_SOURCE_ENCI,
-   priv->io_base + _REG(VPU_HDMI_SETTING));
+   clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING),
+   0x3, MESON_VENC_SOURCE_ENCI);
else
-   writel_bits_relaxed(0x3, MESON_VENC_SOURCE_ENCP,
-   priv->io_base + _REG(VPU_HDMI_SETTING));
+   clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING),
+   0x3, MESON_VENC_SOURCE_ENCP);
 
return 0;
 }
@@ -632,8 +633,8 @@ static void meson_venc_hdmi_encoder_disable(struct 
drm_encoder *encoder)
 
DRM_DEBUG_DRIVER("\n");
 
-   writel_bits_relaxed(0x3, 0,
-   priv->io_base + _REG(VPU_HDMI_SETT

[PATCH v3 0/7] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64

2018-10-24 Thread Corentin Labbe
Hello

This patchset adds a new set of functions which are open-coded in lot of
place.
Basicly the pattern is always the same, "read, modify a bit, write"
some driver and the powerpc arch already have thoses pattern them as functions. 
(like ahci_sunxi.c or dwmac-meson8b)

The first patch rename some powerpc functions for being consistent with
the new name convention.

The second patch adds the header with all setbits functions.

The third patch is a try to implement a coccinelle semantic patch to
find all place where xxxbits function could be used.
It should not be merged since it is un-finalized.
For the moment, the "add setbits.h header" is not working and need a future
coccinelle version.

The four last patch are example of some drivers conversion.
Thoses patchs give an example of the reduction of code won by using xxxbits32.

I would like to thanks Julia Lawall for her help on the coccinelle
patch.

Note that I dont know which maintainer will take the linux/setbits.h include 
patch.

Regards

Changes since v2:
- Fixed patch title
- Fixed style problems
- shorted macro arguments name

Changes since v1:
- renamed LE functions to _leXX
- updated coccinnelle patch with JLawall's comments

Corentin Labbe (7):
  powerpc: rename setbits32/clrbits32 to setbits_be32/clrbits_be32
  include: add setbits_leXX/clrbits_leXX/clrsetbits_leXX in
linux/setbits.h
  coccinelle: add xxxsetbits_leXX converting spatch
  ata: ahci_sunxi: use xxxsetbitsi_le32 functions
  net: ethernet: stmmac: dwmac-sun8i: use xxxsetbits_le32
  drm: meson: use xxxsetbits_le32
  net: stmmac: dwmac-meson8b: use xxxsetbits_le32

 arch/powerpc/include/asm/fsl_lbc.h|   2 +-
 arch/powerpc/include/asm/io.h |   4 +-
 arch/powerpc/platforms/44x/canyonlands.c  |   4 +-
 arch/powerpc/platforms/4xx/gpio.c |  28 +-
 arch/powerpc/platforms/512x/pdm360ng.c|   6 +-
 arch/powerpc/platforms/52xx/mpc52xx_common.c  |   6 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c |  12 +-
 arch/powerpc/platforms/82xx/ep8248e.c |   2 +-
 arch/powerpc/platforms/82xx/km82xx.c  |   6 +-
 arch/powerpc/platforms/82xx/mpc8272_ads.c |  10 +-
 arch/powerpc/platforms/82xx/pq2.c |   2 +-
 arch/powerpc/platforms/82xx/pq2ads-pci-pic.c  |   4 +-
 arch/powerpc/platforms/82xx/pq2fads.c |  10 +-
 arch/powerpc/platforms/83xx/km83xx.c  |   6 +-
 arch/powerpc/platforms/83xx/mpc836x_mds.c |   2 +-
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |   2 +-
 arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c  |   4 +-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |   2 +-
 arch/powerpc/platforms/85xx/p1022_ds.c|   6 +-
 arch/powerpc/platforms/85xx/p1022_rdk.c   |   6 +-
 arch/powerpc/platforms/85xx/t1042rdb_diu.c|   6 +-
 arch/powerpc/platforms/85xx/twr_p102x.c   |   2 +-
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c|   6 +-
 arch/powerpc/platforms/8xx/adder875.c |   2 +-
 arch/powerpc/platforms/8xx/m8xx_setup.c   |   4 +-
 arch/powerpc/platforms/8xx/mpc86xads_setup.c  |   4 +-
 arch/powerpc/platforms/8xx/mpc885ads_setup.c  |  28 +-
 .../platforms/embedded6xx/flipper-pic.c   |   6 +-
 arch/powerpc/platforms/embedded6xx/hlwd-pic.c |   8 +-
 arch/powerpc/platforms/embedded6xx/wii.c  |  12 +-
 arch/powerpc/sysdev/cpm1.c|  26 +-
 arch/powerpc/sysdev/cpm2.c|  16 +-
 arch/powerpc/sysdev/cpm_common.c  |   4 +-
 arch/powerpc/sysdev/fsl_85xx_l2ctlr.c |  16 +-
 arch/powerpc/sysdev/fsl_lbc.c |   2 +-
 arch/powerpc/sysdev/fsl_pci.c |  12 +-
 arch/powerpc/sysdev/fsl_pmc.c |   2 +-
 arch/powerpc/sysdev/fsl_rcpm.c|  74 +--
 arch/powerpc/sysdev/fsl_rio.c |   4 +-
 arch/powerpc/sysdev/fsl_rmu.c |   9 +-
 arch/powerpc/sysdev/mpic_timer.c  |  12 +-
 drivers/ata/ahci_sunxi.c  |  62 +--
 drivers/gpu/drm/meson/meson_crtc.c|  14 +-
 drivers/gpu/drm/meson/meson_dw_hdmi.c |  33 +-
 drivers/gpu/drm/meson/meson_plane.c   |  13 +-
 drivers/gpu/drm/meson/meson_registers.h   |   3 -
 drivers/gpu/drm/meson/meson_venc.c|  13 +-
 drivers/gpu/drm/meson/meson_venc_cvbs.c   |   4 +-
 drivers/gpu/drm/meson/meson_viu.c |  65 +--
 drivers/gpu/drm/meson/meson_vpp.c |  22 +-
 .../ethernet/stmicro/stmmac/dwmac-meson8b.c   |  56 +-
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c |  62 +--
 include/linux/setbits.h   |  84 +++
 scripts/add_new_include_in_source.py  |  61 +++
 scripts/coccinelle/misc/setbits32.cocci   | 487 ++
 .../coccinelle/misc/setbits32_relaxed.cocci   | 487 ++
 scripts/coccinelle/misc/setbits64.cocci   | 487 ++
 scripts/coccinelle/misc/setbits_dev.cocci | 235 +
 58 files changed, 2172 insertions(+), 395 deletions(-)
 create mode 1

[PATCH v2 2/3] dt-bindings: fpga: Add bindings for ZynqMP fpga driver

2018-10-24 Thread Nava kishore Manne
Add documentation to describe Xilinx ZynqMP fpga driver
bindings.

Signed-off-by: Nava kishore Manne 
---
Changes for v2:
-Removed "" separators.
Changes for v1:
-Created a Seperate(New) DT binding file as
 suggested by Rob.

Changes for RFC-V2:
-Moved pcap node as a child to firwmare
 node as suggested by Rob.

 .../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt

diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt 
b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
new file mode 100644
index ..1f6f58872311
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
@@ -0,0 +1,13 @@
+Device Tree zynqmp-fpga bindings for the Zynq Ultrascale+ MPSoC controlled
+using ZynqMP SoC firmware interface
+For Bitstream configuration on ZynqMp Soc uses processor configuration
+port(PCAP) to configure the programmable logic(PL) through PS by using
+FW interface.
+
+Required properties:
+- compatible: should contain "xlnx,zynqmp-pcap-fpga"
+
+Example:
+   zynqmp_pcap: pcap {
+   compatible = "xlnx,zynqmp-pcap-fpga";
+   };
-- 
2.18.0



[PATCH v2 3/3] fpga manager: Adding FPGA Manager support for Xilinx zynqmp

2018-10-24 Thread Nava kishore Manne
This patch adds FPGA Manager support for the Xilinx
ZynqMP chip.

Signed-off-by: Nava kishore Manne 
---
Changes for v2:
-Fixed some minor coding issues as suggested by
 Moritz

Changes for v1:
-None.

Changes for RFC-V2:
-Updated the Fpga Mgr registrations call's
 to 4.18

 drivers/fpga/Kconfig   |   9 ++
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/zynqmp-fpga.c | 165 +
 3 files changed, 175 insertions(+)
 create mode 100644 drivers/fpga/zynqmp-fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 1ebcef4bab5b..38eed4f9d6e9 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -56,6 +56,15 @@ config FPGA_MGR_ZYNQ_FPGA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
+config FPGA_MGR_ZYNQMP_FPGA
+   tristate "Xilinx Zynqmp FPGA"
+   depends on ARCH_ZYNQMP || COMPILE_TEST
+   help
+ FPGA manager driver support for Xilinx ZynqMP FPGAs.
+ This driver uses the processor configuration port(PCAP)
+ to configure the programmable logic(PL) through PS
+ on ZynqMP SoC.
+
 config FPGA_MGR_XILINX_SPI
tristate "Xilinx Configuration over Slave Serial (SPI)"
depends on SPI
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 7a2d73ba7122..3488ebbaee46 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)+= socfpga-a10.o
 obj-$(CONFIG_FPGA_MGR_TS73XX)  += ts73xx-fpga.o
 obj-$(CONFIG_FPGA_MGR_XILINX_SPI)  += xilinx-spi.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
+obj-$(CONFIG_FPGA_MGR_ZYNQMP_FPGA) += zynqmp-fpga.o
 obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
 obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT)+= altera-pr-ip-core-plat.o
 
diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c
new file mode 100644
index ..3c8fb28ef4ce
--- /dev/null
+++ b/drivers/fpga/zynqmp-fpga.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Constant Definitions */
+#define IXR_FPGA_DONE_MASK 0X0008U
+
+/**
+ * struct zynqmp_fpga_priv - Private data structure
+ * @dev:   Device data structure
+ * @flags: flags which is used to identify the bitfile type
+ */
+struct zynqmp_fpga_priv {
+   struct device *dev;
+   u32 flags;
+};
+
+static int zynqmp_fpga_ops_write_init(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
+ const char *buf, size_t size)
+{
+   struct zynqmp_fpga_priv *priv;
+
+   priv = mgr->priv;
+   priv->flags = info->flags;
+
+   return 0;
+}
+
+static int zynqmp_fpga_ops_write(struct fpga_manager *mgr,
+const char *buf, size_t size)
+{
+   const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+   struct zynqmp_fpga_priv *priv;
+   dma_addr_t dma_addr;
+   u32 eemi_flags = 0;
+   char *kbuf;
+   int ret;
+
+   if (!eemi_ops || !eemi_ops->fpga_load)
+   return -ENXIO;
+
+   priv = mgr->priv;
+
+   kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr, GFP_KERNEL);
+   if (!kbuf)
+   return -ENOMEM;
+
+   memcpy(kbuf, buf, size);
+
+   wmb(); /* ensure all writes are done before initiate FW call */
+
+   if (priv->flags & FPGA_MGR_PARTIAL_RECONFIG)
+   eemi_flags |= XILINX_ZYNQMP_PM_FPGA_PARTIAL;
+
+   ret = eemi_ops->fpga_load(dma_addr, size, eemi_flags);
+
+   dma_free_coherent(priv->dev, size, kbuf, dma_addr);
+
+   return ret;
+}
+
+static int zynqmp_fpga_ops_write_complete(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+   return 0;
+}
+
+static enum fpga_mgr_states zynqmp_fpga_ops_state(struct fpga_manager *mgr)
+{
+   const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+   u32 status;
+
+   if (!eemi_ops || !eemi_ops->fpga_get_status)
+   return FPGA_MGR_STATE_UNKNOWN;
+
+   eemi_ops->fpga_get_status(&status);
+   if (status & IXR_FPGA_DONE_MASK)
+   return FPGA_MGR_STATE_OPERATING;
+
+   return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static const struct fpga_manager_ops zynqmp_fpga_ops = {
+   .state = zynqmp_fpga_ops_state,
+   .write_init = zynqmp_fpga_ops_write_init,
+   .write = zynqmp_fpga_ops_write,
+   .write_complete = zynqmp_fpga_ops_write_complete,
+};
+
+static int zynqmp_fpga_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct zynqmp_fpga_priv *priv;
+   struct fpga_manager *mgr;
+   int err, ret;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KE

Re: [GIT PULL] Additional firmware files for CA0132 HD-audio codec

2018-10-24 Thread Takashi Iwai
On Wed, 10 Oct 2018 19:49:23 +0200,
Connor McAdams wrote:
> 
> The following changes since commit c6b6265d718d118e28e1ce8f91769aa886b54c94:
> 
>   Merge tag 'iwlwifi-fw-2018-10-03' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware 
> (2018-10-08 09:23:53 -0400)
> 
> are available in the git repository at:
> 
>   g...@github.com:Conmanx360/linux-firmware.git 
> 
> for you to fetch changes up to cd8899323352e772c5989230f35b1c494e0ab196:
> 
>   linux-firmware: Add new firmware for Creative CA0132 HD-Audio Codec 
> (2018-10-09 14:41:12 -0400)
> 
> 
> These are additional firmware files for CA0132 based sound cards.
> 
> Creative has given me permission through email to send these to the 
> linux-firmware repository under the same license as the previous ca0132 
> firmware. I asked my contact if they would sign-off on it, but they said 
> to go ahead and submit it and that if there was any issue to contact 
> them. 
> 
> If you need to contact them, or if there's more info needed, let me know
> and I can get see what I can do.
> 
> Connor McAdams (1):
>   linux-firmware: Add new firmware for Creative CA0132 HD-Audio Codec
> 
>  WHENCE|   2 ++
>  ctefx-desktop.bin | Bin 0 -> 655856 bytes
>  ctefx-r3di.bin| Bin 0 -> 655816 bytes
>  3 files changed, 2 insertions(+)
>  create mode 100644 ctefx-desktop.bin
>  create mode 100644 ctefx-r3di.bin

Please can anyone take a look at this pull request?

It's mandatory for the CA0132-based cards that are now supported
better in the upstream kernel tree.


Thanks!

Takashi


Re: HH DL585 warm boot fail (old)

2018-10-24 Thread Meelis Roos

Would you mind opening a report at https://bugzilla.kernel.org?  I'm
not sure if anybody will be able to do anything about this, but it's
always possible.


Submitted now, https://bugzilla.kernel.org/show_bug.cgi?id=201503



A complete dmesg log and "sudo lspci -vv" output from a successful
boot would be a good start.  And if you have a screenshot of the
failure, that would help, too.  You can use the "ignore_loglevel"
kernel parameter to make sure we see everything on the console.


Added.


 Does
this machine have an iLO?  If so, it may have logs that could be
useful if this is related to some sort of bus error.


Nothing in the ILO logs.

--
Meelis Roos 


[PATCH v2] zynq-fpga: Only route PR via PCAP when required

2018-10-24 Thread Mike Looijmans
The Xilinx Zynq FPGA driver takes ownership of the PR interface, making
it impossible to use the ICAP interface for partial reconfiguration.

This patch changes the driver to only activate PR over PCAP while the
device is actively being accessed by the driver for programming.

This allows both PCAP and ICAP interfaces to be used for PR.

Signed-off-by: Mike Looijmans 
Reviewed-by: Moritz Fischer 
---
v2: Move the register setting in between the clock enable/disable

 drivers/fpga/zynq-fpga.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
index 3110e00..ff3a427 100644
--- a/drivers/fpga/zynq-fpga.c
+++ b/drivers/fpga/zynq-fpga.c
@@ -501,6 +501,10 @@ static int zynq_fpga_ops_write_complete(struct 
fpga_manager *mgr,
if (err)
return err;
 
+   /* Release 'PR' control back to the ICAP */
+   zynq_fpga_write(priv, CTRL_OFFSET,
+   zynq_fpga_read(priv, CTRL_OFFSET) & ~CTRL_PCAP_PR_MASK);
+
err = zynq_fpga_poll_timeout(priv, INT_STS_OFFSET, intr_status,
 intr_status & IXR_PCFG_DONE_MASK,
 INIT_POLL_DELAY,
-- 
1.9.1



Re: [PATCH V5 1/4] kvm: remove redundant reserved page check

2018-10-24 Thread Yi Zhang
On 2018-09-08 at 02:03:28 +0800, Zhang Yi wrote:
> PageReserved() is already checked inside kvm_is_reserved_pfn(),
> remove it from kvm_set_pfn_dirty().
> 
> Signed-off-by: Zhang Yi 
> Signed-off-by: Zhang Yu 
> Reviewed-by: David Hildenbrand 
> Acked-by: Pankaj Gupta 
> ---
>  virt/kvm/kvm_main.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 8b47507f..c44c406 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1690,12 +1690,8 @@ EXPORT_SYMBOL_GPL(kvm_release_pfn_dirty);
>  
>  void kvm_set_pfn_dirty(kvm_pfn_t pfn)
>  {
> - if (!kvm_is_reserved_pfn(pfn)) {
> - struct page *page = pfn_to_page(pfn);
> -
> - if (!PageReserved(page))
> - SetPageDirty(page);
> - }
> + if (!kvm_is_reserved_pfn(pfn))
> + SetPageDirty(pfn_to_page(pfn));
>  }
>  EXPORT_SYMBOL_GPL(kvm_set_pfn_dirty);
>  
> -- 
> 2.7.4
>
Hi Paolo,
We will remove the reserved flag in dax pages, then patch 2[3,4]/4 is
unnecessary,  can we queue this 1/4 to next merge? 

Thank you very much.
Yi


Re: [RFC][PATCH v2 04/10] ext2: use common file type conversion

2018-10-24 Thread Amir Goldstein
On Wed, Oct 24, 2018 at 9:50 AM Amir Goldstein  wrote:
>
> On Tue, Oct 23, 2018 at 11:19 PM Phillip Potter  wrote:
> >
> > Deduplicate the ext2 file type conversion implementation.
> >
> > Original patch by Amir Goldstein.
> >
> > v2:
> > - Rebased against Linux 4.19 by Phillip Potter
> > - This version does not remove EXT2_FT_x enum from fs/ext2/ext2.h,
> >   as these values are now used in compile-time checks added by
> >   Phillip Potter to make sure they remain the same as FT_x values
> >
> > v1:
> > - Initial implementation
> >
>
> Same comments as how to apply a patch and about changelog as patch 1.
> Won't repeat for other patches.
>
> I think it would be also good to mention there is a lurking bug if code
> ever tries to access ext2_type_by_mode[S_IFMT] because on-disk
> data is corrupted.

So my old notes on the alleged ext2 bug:
https://marc.info/?l=linux-fsdevel&m=14824386620&w=2

>
> > Signed-off-by: Phillip Potter 
> > ---
> >  fs/ext2/dir.c | 51 ++-
> >  1 file changed, 22 insertions(+), 29 deletions(-)
> >
> > diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
> > index 3b8114def693..420d4b9e8980 100644
> > --- a/fs/ext2/dir.c
> > +++ b/fs/ext2/dir.c
> > @@ -252,33 +252,10 @@ ext2_validate_entry(char *base, unsigned offset, 
> > unsigned mask)
> > return (char *)p - base;
> >  }
> >
> > -static unsigned char ext2_filetype_table[EXT2_FT_MAX] = {
> > -   [EXT2_FT_UNKNOWN]   = DT_UNKNOWN,
> > -   [EXT2_FT_REG_FILE]  = DT_REG,
> > -   [EXT2_FT_DIR]   = DT_DIR,
> > -   [EXT2_FT_CHRDEV]= DT_CHR,
> > -   [EXT2_FT_BLKDEV]= DT_BLK,
> > -   [EXT2_FT_FIFO]  = DT_FIFO,
> > -   [EXT2_FT_SOCK]  = DT_SOCK,
> > -   [EXT2_FT_SYMLINK]   = DT_LNK,
> > -};
> > -
> > -#define S_SHIFT 12
> > -static unsigned char ext2_type_by_mode[S_IFMT >> S_SHIFT] = {
> > -   [S_IFREG >> S_SHIFT]= EXT2_FT_REG_FILE,
> > -   [S_IFDIR >> S_SHIFT]= EXT2_FT_DIR,
> > -   [S_IFCHR >> S_SHIFT]= EXT2_FT_CHRDEV,
> > -   [S_IFBLK >> S_SHIFT]= EXT2_FT_BLKDEV,
> > -   [S_IFIFO >> S_SHIFT]= EXT2_FT_FIFO,
> > -   [S_IFSOCK >> S_SHIFT]   = EXT2_FT_SOCK,
> > -   [S_IFLNK >> S_SHIFT]= EXT2_FT_SYMLINK,
> > -};
> > -
> >  static inline void ext2_set_de_type(ext2_dirent *de, struct inode *inode)
> >  {
> > -   umode_t mode = inode->i_mode;
> > if (EXT2_HAS_INCOMPAT_FEATURE(inode->i_sb, 
> > EXT2_FEATURE_INCOMPAT_FILETYPE))
> > -   de->file_type = ext2_type_by_mode[(mode & S_IFMT)>>S_SHIFT];
> > +   de->file_type = fs_umode_to_ftype(inode->i_mode);
> > else
> > de->file_type = 0;
> >  }
> > @@ -293,14 +270,14 @@ ext2_readdir(struct file *file, struct dir_context 
> > *ctx)
> > unsigned long n = pos >> PAGE_SHIFT;
> > unsigned long npages = dir_pages(inode);
> > unsigned chunk_mask = ~(ext2_chunk_size(inode)-1);
> > -   unsigned char *types = NULL;
> > bool need_revalidate = !inode_eq_iversion(inode, file->f_version);
> > +   bool has_filetype;
> >
> > if (pos > inode->i_size - EXT2_DIR_REC_LEN(1))
> > return 0;
> >
> > -   if (EXT2_HAS_INCOMPAT_FEATURE(sb, EXT2_FEATURE_INCOMPAT_FILETYPE))
> > -   types = ext2_filetype_table;
> > +   has_filetype =
> > +   EXT2_HAS_INCOMPAT_FEATURE(sb, 
> > EXT2_FEATURE_INCOMPAT_FILETYPE);
> >
> > for ( ; n < npages; n++, offset = 0) {
> > char *kaddr, *limit;
> > @@ -335,8 +312,24 @@ ext2_readdir(struct file *file, struct dir_context 
> > *ctx)
> > if (de->inode) {
> > unsigned char d_type = DT_UNKNOWN;
> >
> > -   if (types && de->file_type < EXT2_FT_MAX)
> > -   d_type = types[de->file_type];
> > +   /*
> > +* compile-time asserts that generic FT_x 
> > types
> > +* still match EXT2_FT_x types - no need to 
> > list
> > +* for other functions as well as build will
> > +* fail either way

Please remove the part about "no need to list for other functions..."
Imagine how kernel code would look like if every call to BUILD_BUG_ON()
would have a comment explaining how BUILD_BUG_ON() works...

Thanks,
Amir.


[PATCH V2 1/5] spi: lpspi: Add slave mode support for imx7ulp

2018-10-24 Thread Clark Wang
Add SPI slave mode support for imx7ulp, in PIO mode.

Add "spi-slave" attribute in spi node of dts file to boot.

For now, slave has to send the message which is same as the length of
message master sent.

Wire connection:
GND, SCK, MISO(to MISO of slave), MOSI(to MOSI of slave), SCS

Signed-off-by: Xiaoning Wang 
---
V2:
 - No changes.
---
 drivers/spi/spi-fsl-lpspi.c | 209 
 1 file changed, 139 insertions(+), 70 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 51670976faa3..86cb38d98a39 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -3,6 +3,7 @@
 // Freescale i.MX7ULP LPSPI driver
 //
 // Copyright 2016 Freescale Semiconductor, Inc.
+// Copyright 2018 NXP
 
 #include 
 #include 
@@ -54,6 +55,7 @@
 #define IER_RDIE   BIT(1)
 #define IER_TDIE   BIT(0)
 #define CFGR1_PCSCFG   BIT(27)
+#define CFGR1_PINCFG   (BIT(24)|BIT(25))
 #define CFGR1_PCSPOL   BIT(8)
 #define CFGR1_NOSTALL  BIT(3)
 #define CFGR1_MASTER   BIT(0)
@@ -79,6 +81,7 @@ struct fsl_lpspi_data {
struct device *dev;
void __iomem *base;
struct clk *clk;
+   bool is_slave;
 
void *rx_buf;
const void *tx_buf;
@@ -86,11 +89,14 @@ struct fsl_lpspi_data {
void (*rx)(struct fsl_lpspi_data *);
 
u32 remain;
+   u8 watermark;
u8 txfifosize;
u8 rxfifosize;
 
struct lpspi_config config;
struct completion xfer_done;
+
+   bool slave_aborted;
 };
 
 static const struct of_device_id fsl_lpspi_dt_ids[] = {
@@ -137,16 +143,18 @@ static void fsl_lpspi_intctrl(struct fsl_lpspi_data 
*fsl_lpspi,
writel(enable, fsl_lpspi->base + IMX7ULP_IER);
 }
 
-static int lpspi_prepare_xfer_hardware(struct spi_master *master)
+static int lpspi_prepare_xfer_hardware(struct spi_controller *controller)
 {
-   struct fsl_lpspi_data *fsl_lpspi = spi_master_get_devdata(master);
+   struct fsl_lpspi_data *fsl_lpspi =
+   spi_controller_get_devdata(controller);
 
return clk_prepare_enable(fsl_lpspi->clk);
 }
 
-static int lpspi_unprepare_xfer_hardware(struct spi_master *master)
+static int lpspi_unprepare_xfer_hardware(struct spi_controller *controller)
 {
-   struct fsl_lpspi_data *fsl_lpspi = spi_master_get_devdata(master);
+   struct fsl_lpspi_data *fsl_lpspi =
+   spi_controller_get_devdata(controller);
 
clk_disable_unprepare(fsl_lpspi->clk);
 
@@ -202,22 +210,26 @@ static void fsl_lpspi_set_cmd(struct fsl_lpspi_data 
*fsl_lpspi,
 {
u32 temp = 0;
 
-   temp |= fsl_lpspi->config.bpw - 1;
-   temp |= fsl_lpspi->config.prescale << 27;
-   temp |= (fsl_lpspi->config.mode & 0x3) << 30;
-   temp |= (fsl_lpspi->config.chip_select & 0x3) << 24;
-
-   /*
-* Set TCR_CONT will keep SS asserted after current transfer.
-* For the first transfer, clear TCR_CONTC to assert SS.
-* For subsequent transfer, set TCR_CONTC to keep SS asserted.
-*/
-   temp |= TCR_CONT;
-   if (is_first_xfer)
-   temp &= ~TCR_CONTC;
-   else
-   temp |= TCR_CONTC;
-
+   if (!fsl_lpspi->is_slave) {
+   temp |= fsl_lpspi->config.bpw - 1;
+   temp |= fsl_lpspi->config.prescale << 27;
+   temp |= (fsl_lpspi->config.mode & 0x3) << 30;
+   temp |= (fsl_lpspi->config.chip_select & 0x3) << 24;
+
+   /*
+* Set TCR_CONT will keep SS asserted after current transfer.
+* For the first transfer, clear TCR_CONTC to assert SS.
+* For subsequent transfer, set TCR_CONTC to keep SS asserted.
+*/
+   temp |= TCR_CONT;
+   if (is_first_xfer)
+   temp &= ~TCR_CONTC;
+   else
+   temp |= TCR_CONTC;
+   } else {
+   temp |= fsl_lpspi->config.bpw - 1;
+   temp |= (fsl_lpspi->config.mode & 0x3) << 30;
+   }
writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
 
dev_dbg(fsl_lpspi->dev, "TCR=0x%x\n", temp);
@@ -227,7 +239,7 @@ static void fsl_lpspi_set_watermark(struct fsl_lpspi_data 
*fsl_lpspi)
 {
u32 temp;
 
-   temp = fsl_lpspi->txfifosize >> 1 | (fsl_lpspi->rxfifosize >> 1) << 16;
+   temp = fsl_lpspi->watermark >> 1 | (fsl_lpspi->watermark >> 1) << 16;
 
writel(temp, fsl_lpspi->base + IMX7ULP_FCR);
 
@@ -253,7 +265,8 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data 
*fsl_lpspi)
if (prescale == 8 && scldiv >= 256)
return -EINVAL;
 
-   writel(scldiv, fsl_lpspi->base + IMX7ULP_CCR);
+   writel(scldiv | (scldiv << 8) | ((scldiv >> 1) << 16),
+   fsl_lpspi->base + IMX7ULP_CCR);
 
dev_dbg(fsl_lpspi->dev, "perclk=%d, speed=%d, prescale =%d, 
scldiv=%d\n",
perclk_rate, config.speed_hz

Re: [PATCH v3 4/7] ata: ahci_sunxi: use xxxsetbitsi_le32 functions

2018-10-24 Thread Sergei Shtylyov

Hello!

   Typo in the subject: s/xxxsetbitsi/xxxsetbits/.

On 24.10.2018 10:35, Corentin Labbe wrote:


This patch converts ahci_sunxi to use xxxsetbits_le32 functions

Signed-off-by: Corentin Labbe 

[...]

MBR, Sergei



[PATCH V2 2/5] spi: lpspi: Improve the stability of lpspi data transmission

2018-10-24 Thread Clark Wang
Use SR_TDF to judge if need send data, and SR_FCF to judge if
transmission end to replace the waiting after transmission end. This
waiting has no actual meaning, for the real end will set the FCF
flag.

Resolved an issue that could cause a transmission timeout when
transferring large amounts of data.

After making these changes, there is no need to use
fsl_lpspi_txfifo_empty(), so remove it.

Signed-off-by: Xiaoning Wang 
---
V2:
 - Sorry for my negligence.
   Fix an issue which happened when I split the patch from my work git
   tree. Forgot to delete fsl_lpspi_txfifo_empty() code.
---
 drivers/spi/spi-fsl-lpspi.c | 63 +
 1 file changed, 21 insertions(+), 42 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 86cb38d98a39..79a3d4a82628 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -49,9 +49,11 @@
 #define CR_RST BIT(1)
 #define CR_MEN BIT(0)
 #define SR_TCF BIT(10)
+#define SR_FCF BIT(9)
 #define SR_RDF BIT(1)
 #define SR_TDF BIT(0)
 #define IER_TCIE   BIT(10)
+#define IER_FCIE   BIT(9)
 #define IER_RDIE   BIT(1)
 #define IER_TDIE   BIT(0)
 #define CFGR1_PCSCFG   BIT(27)
@@ -161,28 +163,10 @@ static int lpspi_unprepare_xfer_hardware(struct 
spi_controller *controller)
return 0;
 }
 
-static int fsl_lpspi_txfifo_empty(struct fsl_lpspi_data *fsl_lpspi)
-{
-   u32 txcnt;
-   unsigned long orig_jiffies = jiffies;
-
-   do {
-   txcnt = readl(fsl_lpspi->base + IMX7ULP_FSR) & 0xff;
-
-   if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
-   dev_dbg(fsl_lpspi->dev, "txfifo empty timeout\n");
-   return -ETIMEDOUT;
-   }
-   cond_resched();
-
-   } while (txcnt);
-
-   return 0;
-}
-
 static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data *fsl_lpspi)
 {
u8 txfifo_cnt;
+   u32 temp;
 
txfifo_cnt = readl(fsl_lpspi->base + IMX7ULP_FSR) & 0xff;
 
@@ -193,9 +177,15 @@ static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data 
*fsl_lpspi)
txfifo_cnt++;
}
 
-   if (!fsl_lpspi->remain && (txfifo_cnt < fsl_lpspi->txfifosize))
-   writel(0, fsl_lpspi->base + IMX7ULP_TDR);
-   else
+   if (txfifo_cnt < fsl_lpspi->txfifosize) {
+   if (!fsl_lpspi->is_slave) {
+   temp = readl(fsl_lpspi->base + IMX7ULP_TCR);
+   temp &= ~TCR_CONTC;
+   writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
+   }
+
+   fsl_lpspi_intctrl(fsl_lpspi, IER_FCIE);
+   } else
fsl_lpspi_intctrl(fsl_lpspi, IER_TDIE);
 }
 
@@ -394,12 +384,6 @@ static int fsl_lpspi_transfer_one(struct spi_controller 
*controller,
if (ret)
return ret;
 
-   ret = fsl_lpspi_txfifo_empty(fsl_lpspi);
-   if (ret)
-   return ret;
-
-   fsl_lpspi_read_rx_fifo(fsl_lpspi);
-
return 0;
 }
 
@@ -411,7 +395,6 @@ static int fsl_lpspi_transfer_one_msg(struct spi_controller 
*controller,
struct spi_device *spi = msg->spi;
struct spi_transfer *xfer;
bool is_first_xfer = true;
-   u32 temp;
int ret = 0;
 
msg->status = 0;
@@ -431,13 +414,6 @@ static int fsl_lpspi_transfer_one_msg(struct 
spi_controller *controller,
}
 
 complete:
-   if (!fsl_lpspi->is_slave) {
-   /* de-assert SS, then finalize current message */
-   temp = readl(fsl_lpspi->base + IMX7ULP_TCR);
-   temp &= ~TCR_CONTC;
-   writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
-   }
-
msg->status = ret;
spi_finalize_current_message(controller);
 
@@ -446,20 +422,23 @@ static int fsl_lpspi_transfer_one_msg(struct 
spi_controller *controller,
 
 static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
 {
+   u32 temp_SR, temp_IER;
struct fsl_lpspi_data *fsl_lpspi = dev_id;
-   u32 temp;
 
+   temp_IER = readl(fsl_lpspi->base + IMX7ULP_IER);
fsl_lpspi_intctrl(fsl_lpspi, 0);
-   temp = readl(fsl_lpspi->base + IMX7ULP_SR);
+   temp_SR = readl(fsl_lpspi->base + IMX7ULP_SR);
 
fsl_lpspi_read_rx_fifo(fsl_lpspi);
 
-   if (temp & SR_TDF) {
+   if ((temp_SR & SR_TDF) && (temp_IER & IER_TDIE)) {
fsl_lpspi_write_tx_fifo(fsl_lpspi);
+   return IRQ_HANDLED;
+   }
 
-   if (!fsl_lpspi->remain)
-   complete(&fsl_lpspi->xfer_done);
-
+   if (temp_SR & SR_FCF && (temp_IER & IER_FCIE)) {
+   writel(SR_FCF, fsl_lpspi->base + IMX7ULP_SR);
+   complete(&fsl_lpspi->xfer_done);
return IRQ_HANDLED;
}
 
-- 
2.17.1



[PATCH V2 3/5] spi: lpspi: Add 8qm/qxp support for lpspi

2018-10-24 Thread Clark Wang
Add both ipg and per clock for lpspi to support i.MX8QM/QXP boards.

Signed-off-by: Xiaoning Wang 
---
V2:
 - No changes.
---
 drivers/spi/spi-fsl-lpspi.c | 52 +
 1 file changed, 41 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 79a3d4a82628..b51746c2de00 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -82,7 +82,8 @@ struct lpspi_config {
 struct fsl_lpspi_data {
struct device *dev;
void __iomem *base;
-   struct clk *clk;
+   struct clk *clk_ipg;
+   struct clk *clk_per;
bool is_slave;
 
void *rx_buf;
@@ -149,8 +150,19 @@ static int lpspi_prepare_xfer_hardware(struct 
spi_controller *controller)
 {
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
+   int ret;
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_per);
+   if (ret) {
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+   return ret;
+   }
 
-   return clk_prepare_enable(fsl_lpspi->clk);
+   return 0;
 }
 
 static int lpspi_unprepare_xfer_hardware(struct spi_controller *controller)
@@ -158,7 +170,8 @@ static int lpspi_unprepare_xfer_hardware(struct 
spi_controller *controller)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
 
-   clk_disable_unprepare(fsl_lpspi->clk);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+   clk_disable_unprepare(fsl_lpspi->clk_per);
 
return 0;
 }
@@ -242,7 +255,7 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data 
*fsl_lpspi)
unsigned int perclk_rate, scldiv;
u8 prescale;
 
-   perclk_rate = clk_get_rate(fsl_lpspi->clk);
+   perclk_rate = clk_get_rate(fsl_lpspi->clk_per);
for (prescale = 0; prescale < 8; prescale++) {
scldiv = perclk_rate /
 (clkdivs[prescale] * config.speed_hz) - 2;
@@ -504,15 +517,30 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
goto out_controller_put;
}
 
-   fsl_lpspi->clk = devm_clk_get(&pdev->dev, "ipg");
-   if (IS_ERR(fsl_lpspi->clk)) {
-   ret = PTR_ERR(fsl_lpspi->clk);
+   fsl_lpspi->clk_per = devm_clk_get(&pdev->dev, "per");
+   if (IS_ERR(fsl_lpspi->clk_per)) {
+   ret = PTR_ERR(fsl_lpspi->clk_per);
+   goto out_controller_put;
+   }
+
+   fsl_lpspi->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
+   if (IS_ERR(fsl_lpspi->clk_ipg)) {
+   ret = PTR_ERR(fsl_lpspi->clk_ipg);
+   goto out_controller_put;
+   }
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+   if (ret) {
+   dev_err(&pdev->dev,
+   "can't enable lpspi ipg clock, ret=%d\n", ret);
goto out_controller_put;
}
 
-   ret = clk_prepare_enable(fsl_lpspi->clk);
+   ret = clk_prepare_enable(fsl_lpspi->clk_per);
if (ret) {
-   dev_err(&pdev->dev, "can't enable lpspi clock, ret=%d\n", ret);
+   dev_err(&pdev->dev,
+   "can't enable lpspi per clock, ret=%d\n", ret);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
goto out_controller_put;
}
 
@@ -520,7 +548,8 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi->txfifosize = 1 << (temp & 0x0f);
fsl_lpspi->rxfifosize = 1 << ((temp >> 8) & 0x0f);
 
-   clk_disable_unprepare(fsl_lpspi->clk);
+   clk_disable_unprepare(fsl_lpspi->clk_per);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
 
ret = devm_spi_register_controller(&pdev->dev, controller);
if (ret < 0) {
@@ -542,7 +571,8 @@ static int fsl_lpspi_remove(struct platform_device *pdev)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
 
-   clk_disable_unprepare(fsl_lpspi->clk);
+   clk_disable_unprepare(fsl_lpspi->clk_per);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
 
return 0;
 }
-- 
2.17.1



[PATCH V2 5/5] spi: lpspi: CLK pin becomes low when CR_RST=1

2018-10-24 Thread Clark Wang
Remove Reset operation in fsl_lpspi_config(). This RST may cause both CLK
and CS pins go from high to low level under cs-gpio mode.
Add fsl_lpspi_reset() function after one message transfer to clear all
flags in use.

Signed-off-by: Xiaoning Wang 
Reviewed-by: Fugang Duan 
---
V2:
 - Wrong place to remove fsl_lpspi_txfifo_empty() code when I split patch
   from my work git tree Although the final code which after applying all
   these five patches is correct.
---
 drivers/spi/spi-fsl-lpspi.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 1be29daa9f92..3a7fe1c83aaa 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -282,10 +282,6 @@ static int fsl_lpspi_config(struct fsl_lpspi_data 
*fsl_lpspi)
u32 temp;
int ret;
 
-   temp = CR_RST;
-   writel(temp, fsl_lpspi->base + IMX7ULP_CR);
-   writel(0, fsl_lpspi->base + IMX7ULP_CR);
-
if (!fsl_lpspi->is_slave) {
ret = fsl_lpspi_set_bitrate(fsl_lpspi);
if (ret)
@@ -376,6 +372,21 @@ static int fsl_lpspi_wait_for_completion(struct 
spi_controller *controller)
return 0;
 }
 
+static int fsl_lpspi_reset(struct fsl_lpspi_data *fsl_lpspi)
+{
+   u32 temp;
+
+   /* W1C for all flags in SR */
+   temp = 0x3F << 8;
+   writel(temp, fsl_lpspi->base + IMX7ULP_SR);
+
+   /* Clear FIFO and disable module */
+   temp = CR_RRF | CR_RTF;
+   writel(temp, fsl_lpspi->base + IMX7ULP_CR);
+
+   return 0;
+}
+
 static int fsl_lpspi_transfer_one(struct spi_controller *controller,
  struct spi_device *spi,
  struct spi_transfer *t)
@@ -397,6 +408,8 @@ static int fsl_lpspi_transfer_one(struct spi_controller 
*controller,
if (ret)
return ret;
 
+   fsl_lpspi_reset(fsl_lpspi);
+
return 0;
 }
 
-- 
2.17.1



[PATCH V2 4/5] spi: lpspi: enable runtime pm for lpspi

2018-10-24 Thread Clark Wang
Enable the runtime pm for lpspi module

BuildInfo:
- U-Boot 2018.03-imx_4.14.y

Signed-off-by: Han Xu 
Reviewed-by: Frank Li 
Signed-off-by: Xiaoning Wang 
---
V2:
 - Add pinctrl/consumer.h include to fix the Warning error: implicit
   declaration of function 'pinctrl_pm_select_sleep_state'.
---
 drivers/spi/spi-fsl-lpspi.c | 117 
 1 file changed, 92 insertions(+), 25 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index b51746c2de00..1be29daa9f92 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -16,7 +16,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +26,8 @@
 
 #define DRIVER_NAME "fsl_lpspi"
 
+#define FSL_LPSPI_RPM_TIMEOUT 50 /* 50ms */
+
 /* i.MX7ULP LPSPI registers */
 #define IMX7ULP_VERID  0x0
 #define IMX7ULP_PARAM  0x4
@@ -152,13 +156,9 @@ static int lpspi_prepare_xfer_hardware(struct 
spi_controller *controller)
spi_controller_get_devdata(controller);
int ret;
 
-   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
-   if (ret)
-   return ret;
-
-   ret = clk_prepare_enable(fsl_lpspi->clk_per);
-   if (ret) {
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+   ret = pm_runtime_get_sync(fsl_lpspi->dev);
+   if (ret < 0) {
+   dev_err(fsl_lpspi->dev, "failed to enable clock\n");
return ret;
}
 
@@ -170,8 +170,8 @@ static int lpspi_unprepare_xfer_hardware(struct 
spi_controller *controller)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
 
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
-   clk_disable_unprepare(fsl_lpspi->clk_per);
+   pm_runtime_mark_last_busy(fsl_lpspi->dev);
+   pm_runtime_put_autosuspend(fsl_lpspi->dev);
 
return 0;
 }
@@ -458,6 +458,45 @@ static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
return IRQ_NONE;
 }
 
+int fsl_lpspi_runtime_resume(struct device *dev)
+{
+   struct fsl_lpspi_data *fsl_lpspi = dev_get_drvdata(dev);
+   int ret;
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_per);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+   if (ret) {
+   clk_disable_unprepare(fsl_lpspi->clk_per);
+   return ret;
+   }
+
+   return 0;
+}
+
+int fsl_lpspi_runtime_suspend(struct device *dev)
+{
+   struct fsl_lpspi_data *fsl_lpspi = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(fsl_lpspi->clk_per);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+
+   return 0;
+}
+
+static int fsl_lpspi_init_rpm(struct fsl_lpspi_data *fsl_lpspi)
+{
+   struct device *dev = fsl_lpspi->dev;
+
+   pm_runtime_enable(dev);
+   pm_runtime_set_autosuspend_delay(dev, FSL_LPSPI_RPM_TIMEOUT);
+   pm_runtime_use_autosuspend(dev);
+
+   return 0;
+}
+
 static int fsl_lpspi_probe(struct platform_device *pdev)
 {
struct fsl_lpspi_data *fsl_lpspi;
@@ -483,6 +522,7 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
 
fsl_lpspi = spi_controller_get_devdata(controller);
fsl_lpspi->dev = &pdev->dev;
+   dev_set_drvdata(&pdev->dev, fsl_lpspi);
fsl_lpspi->is_slave = of_property_read_bool((&pdev->dev)->of_node,
"spi-slave");
 
@@ -529,28 +569,21 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
goto out_controller_put;
}
 
-   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
-   if (ret) {
-   dev_err(&pdev->dev,
-   "can't enable lpspi ipg clock, ret=%d\n", ret);
+   /* enable the clock */
+   ret = fsl_lpspi_init_rpm(fsl_lpspi);
+   if (ret)
goto out_controller_put;
-   }
 
-   ret = clk_prepare_enable(fsl_lpspi->clk_per);
-   if (ret) {
-   dev_err(&pdev->dev,
-   "can't enable lpspi per clock, ret=%d\n", ret);
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
-   goto out_controller_put;
+   ret = pm_runtime_get_sync(fsl_lpspi->dev);
+   if (ret < 0) {
+   dev_err(fsl_lpspi->dev, "failed to enable clock\n");
+   return ret;
}
 
temp = readl(fsl_lpspi->base + IMX7ULP_PARAM);
fsl_lpspi->txfifosize = 1 << (temp & 0x0f);
fsl_lpspi->rxfifosize = 1 << ((temp >> 8) & 0x0f);
 
-   clk_disable_unprepare(fsl_lpspi->clk_per);
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
-
ret = devm_spi_register_controller(&pdev->dev, controller);
if (ret < 0) {
dev_err(&pdev->dev, "spi_register_controller error.\n");
@@ -571,16 +604,50 @@ static int fsl_lpspi_remove(struct platform_device *pdev)
struct fsl_lpspi_data *fsl_lpspi =

[PATCH] mmc: sdhci: Convert sdhci_allocate_bounce_buffer() to return void

2018-10-24 Thread Chunyan Zhang
The function sdhci_allocate_bounce_buffer() always return zero at
present, so there's no need to have a return value, that will also make
error path easier.

CC: Linus Walleij 
Signed-off-by: Chunyan Zhang 
---
 drivers/mmc/host/sdhci.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1b3fbd9..e94f4aa 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3408,7 +3408,7 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, 
u32 *caps, u32 *caps1)
 }
 EXPORT_SYMBOL_GPL(__sdhci_read_caps);
 
-static int sdhci_allocate_bounce_buffer(struct sdhci_host *host)
+static void sdhci_allocate_bounce_buffer(struct sdhci_host *host)
 {
struct mmc_host *mmc = host->mmc;
unsigned int max_blocks;
@@ -3446,7 +3446,7 @@ static int sdhci_allocate_bounce_buffer(struct sdhci_host 
*host)
 * Exiting with zero here makes sure we proceed with
 * mmc->max_segs == 1.
 */
-   return 0;
+   return;
}
 
host->bounce_addr = dma_map_single(mmc->parent,
@@ -3456,7 +3456,7 @@ static int sdhci_allocate_bounce_buffer(struct sdhci_host 
*host)
ret = dma_mapping_error(mmc->parent, host->bounce_addr);
if (ret)
/* Again fall back to max_segs == 1 */
-   return 0;
+   return;
host->bounce_buffer_size = bounce_size;
 
/* Lie about this since we're bouncing */
@@ -3466,8 +3466,6 @@ static int sdhci_allocate_bounce_buffer(struct sdhci_host 
*host)
 
pr_info("%s bounce up to %u segments into one, max segment size %u 
bytes\n",
mmc_hostname(mmc), max_blocks, bounce_size);
-
-   return 0;
 }
 
 int sdhci_setup_host(struct sdhci_host *host)
@@ -3987,12 +3985,9 @@ int sdhci_setup_host(struct sdhci_host *host)
 */
mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 
65535;
 
-   if (mmc->max_segs == 1) {
+   if (mmc->max_segs == 1)
/* This may alter mmc->*_blk_* parameters */
-   ret = sdhci_allocate_bounce_buffer(host);
-   if (ret)
-   return ret;
-   }
+   sdhci_allocate_bounce_buffer(host);
 
return 0;
 
-- 
2.7.4



[PATCH v13 00/12] Intel Processor Trace virtualization enabling

2018-10-24 Thread Luwei Kang
>From V12
 - Refine the title and description of patch 1~3. -- Thomas Gleixner
 - Rename the function of validate the capabilities of Intel PT. -- Thomas 
Gleixner
 - Add more description of Intel PT work mode. -- Alexander Shishkin

>From V11:
 - In patch 3, arguments caps vs. cap is not good. Spell second one out. -- 
Thomas Gleixner

>From V10: (This version don't have code change)
 - move the patch 5 in version 9 to patch 3 (reorder patch 5) -- Alexander 
Shishkin
 - refind the patch description of patch 5 (add new capability for Intel PT) -- 
Alexander Shishkin
 - CC all the maintainers, reviewers and submitters in each patch of this patch 
set -- Alexander Shishkin

>From V9:
 - remove redundant initialize for "ctl_bitmask" in patch 9;
 - do some changes for patch's description.

>From V8:
 - move macro definition MSR_IA32_RTIT_ADDR_RANGE from msr-index.h to 
intel_pt.h;
 - initialize the RTIT_CTL bitmask to ~0ULL.

>From V7:
 - remove host only mode since it can be emulated by perf code;
 - merge patch 8 and 9 to make code and data in the same patch;
 - rename __pt_cap_get() to pt_cap_decode();
 - other minor change.

>From V6:
 - split pathes 1~2 to four separate patches (these patches do 2 things) and 
add more descriptions.

>From V5:
 - rename the function from pt_cap_get_ex() to __pt_cap_get();
 - replace the most of function from vmx_pt_supported() to "pt_mode == 
PT_MODE_HOST_GUEST"(or !=).

>From V4:
 - add data check when setting the value of MSR_IA32_RTIT_CTL;
 - Invoke new interface to set the intercept of MSRs read/write after "MSR 
bitmap per-vcpu" patches.

>From V3:
 - change default mode to SYSTEM mode;
 - add a new patch to move PT out of scattered features;
 - add a new fucntion kvm_get_pt_addr_cnt() to get the number of address ranges;
 - add a new function vmx_set_rtit_ctl() to set the value of guest RTIT_CTL, 
GUEST_IA32_RTIT_CTL and MSRs intercept.

>From v2:
 - replace *_PT_SUPPRESS_PIP to *_PT_CONCEAL_PIP;
 - clean SECONDARY_EXEC_PT_USE_GPA, VM_EXIT_CLEAR_IA32_RTIT_CTL and 
VM_ENTRY_LOAD_IA32_RTIT_CTL in SYSTEM mode. These bits must be all set or all 
clean;
 - move processor tracing out of scattered features;
 - add a new function to enable/disable intercept MSRs read/write;
 - add all Intel PT MSRs read/write and disable intercept when PT is enabled in 
guest;
 - disable Intel PT and enable intercept MSRs when L1 guest VMXON;
 - performance optimization.
   In Host only mode. we just need to save host RTIT_CTL before vm-entry and 
restore host RTIT_CTL after vm-exit;
   In HOST_GUEST mode. we need to save and restore all MSRs only when PT has 
enabled in guest.
 - use XSAVES/XRESTORES implement context switch.
   Haven't implementation in this version and still in debuging. will make a 
separate patch work on this.

>From v1:
 - remove guest-only mode because guest-only mode can be covered by host-guest 
mode;
 - always set "use GPA for processor tracing" in secondary execution control if 
it can be;
 - trap RTIT_CTL read/write. Forbid write this msr when VMXON in L1 hypervisor.

Chao Peng (7):
  perf/x86/intel/pt: Move Intel PT MSRs bit defines to global header
  perf/x86/intel/pt: Export pt_cap_get()
  KVM: x86: Add Intel PT virtualization work mode
  KVM: x86: Add Intel Processor Trace cpuid emulation
  KVM: x86: Add Intel PT context switch for each vcpu
  KVM: x86: Implement Intel PT MSRs read/write emulation
  KVM: x86: Set intercept for Intel PT MSRs read/write

Luwei Kang (5):
  perf/x86/intel/pt: Introduce intel_pt_validate_cap()
  perf/x86/intel/pt: Add new bit definitions for PT MSRs
  perf/x86/intel/pt: add new capability for Intel PT
  KVM: x86: Introduce a function to initialize the PT configuration
  KVM: x86: Disable Intel PT when VMXON in L1 guest

 arch/x86/events/intel/pt.c   |  60 +++---
 arch/x86/events/intel/pt.h   |  58 -
 arch/x86/include/asm/intel_pt.h  |  39 
 arch/x86/include/asm/kvm_host.h  |   1 +
 arch/x86/include/asm/msr-index.h |  37 
 arch/x86/include/asm/vmx.h   |   8 +
 arch/x86/kvm/cpuid.c |  22 +-
 arch/x86/kvm/svm.c   |   6 +
 arch/x86/kvm/vmx.c   | 446 ++-
 arch/x86/kvm/x86.c   |  33 ++-
 10 files changed, 620 insertions(+), 90 deletions(-)

-- 
1.8.3.1



[PATCH v13 02/12] perf/x86/intel/pt: Export pt_cap_get()

2018-10-24 Thread Luwei Kang
From: Chao Peng 

pt_cap_get() is required by the upcoming PT support in KVM guests.

Export it and move the capabilites enum to a global header.

As a global functions, "pt_*" is already used for ptrace and
other things, so it makes sense to use "intel_pt_*" as a prefix.

Acked-by: Song Liu 
Signed-off-by: Chao Peng 
Signed-off-by: Luwei Kang 
---
 arch/x86/events/intel/pt.c  | 49 ++---
 arch/x86/events/intel/pt.h  | 21 --
 arch/x86/include/asm/intel_pt.h | 23 +++
 3 files changed, 49 insertions(+), 44 deletions(-)

diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 8d016ce..309bb1d 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -75,7 +75,7 @@
PT_CAP(psb_periods, 1, CPUID_EBX, 0x),
 };
 
-static u32 pt_cap_get(enum pt_capabilities cap)
+u32 intel_pt_validate_hw_cap(enum pt_capabilities cap)
 {
struct pt_cap_desc *cd = &pt_caps[cap];
u32 c = pt_pmu.caps[cd->leaf * PT_CPUID_REGS_NUM + cd->reg];
@@ -83,6 +83,7 @@ static u32 pt_cap_get(enum pt_capabilities cap)
 
return (c & cd->mask) >> shift;
 }
+EXPORT_SYMBOL_GPL(intel_pt_validate_hw_cap);
 
 static ssize_t pt_cap_show(struct device *cdev,
   struct device_attribute *attr,
@@ -92,7 +93,7 @@ static ssize_t pt_cap_show(struct device *cdev,
container_of(attr, struct dev_ext_attribute, attr);
enum pt_capabilities cap = (long)ea->var;
 
-   return snprintf(buf, PAGE_SIZE, "%x\n", pt_cap_get(cap));
+   return snprintf(buf, PAGE_SIZE, "%x\n", intel_pt_validate_hw_cap(cap));
 }
 
 static struct attribute_group pt_cap_group = {
@@ -310,16 +311,16 @@ static bool pt_event_valid(struct perf_event *event)
return false;
 
if (config & RTIT_CTL_CYC_PSB) {
-   if (!pt_cap_get(PT_CAP_psb_cyc))
+   if (!intel_pt_validate_hw_cap(PT_CAP_psb_cyc))
return false;
 
-   allowed = pt_cap_get(PT_CAP_psb_periods);
+   allowed = intel_pt_validate_hw_cap(PT_CAP_psb_periods);
requested = (config & RTIT_CTL_PSB_FREQ) >>
RTIT_CTL_PSB_FREQ_OFFSET;
if (requested && (!(allowed & BIT(requested
return false;
 
-   allowed = pt_cap_get(PT_CAP_cycle_thresholds);
+   allowed = intel_pt_validate_hw_cap(PT_CAP_cycle_thresholds);
requested = (config & RTIT_CTL_CYC_THRESH) >>
RTIT_CTL_CYC_THRESH_OFFSET;
if (requested && (!(allowed & BIT(requested
@@ -334,10 +335,10 @@ static bool pt_event_valid(struct perf_event *event)
 * Spec says that setting mtc period bits while mtc bit in
 * CPUID is 0 will #GP, so better safe than sorry.
 */
-   if (!pt_cap_get(PT_CAP_mtc))
+   if (!intel_pt_validate_hw_cap(PT_CAP_mtc))
return false;
 
-   allowed = pt_cap_get(PT_CAP_mtc_periods);
+   allowed = intel_pt_validate_hw_cap(PT_CAP_mtc_periods);
if (!allowed)
return false;
 
@@ -349,11 +350,11 @@ static bool pt_event_valid(struct perf_event *event)
}
 
if (config & RTIT_CTL_PWR_EVT_EN &&
-   !pt_cap_get(PT_CAP_power_event_trace))
+   !intel_pt_validate_hw_cap(PT_CAP_power_event_trace))
return false;
 
if (config & RTIT_CTL_PTW) {
-   if (!pt_cap_get(PT_CAP_ptwrite))
+   if (!intel_pt_validate_hw_cap(PT_CAP_ptwrite))
return false;
 
/* FUPonPTW without PTW doesn't make sense */
@@ -598,7 +599,7 @@ static struct topa *topa_alloc(int cpu, gfp_t gfp)
 * In case of singe-entry ToPA, always put the self-referencing END
 * link as the 2nd entry in the table
 */
-   if (!pt_cap_get(PT_CAP_topa_multiple_entries)) {
+   if (!intel_pt_validate_hw_cap(PT_CAP_topa_multiple_entries)) {
TOPA_ENTRY(topa, 1)->base = topa->phys >> TOPA_SHIFT;
TOPA_ENTRY(topa, 1)->end = 1;
}
@@ -638,7 +639,7 @@ static void topa_insert_table(struct pt_buffer *buf, struct 
topa *topa)
topa->offset = last->offset + last->size;
buf->last = topa;
 
-   if (!pt_cap_get(PT_CAP_topa_multiple_entries))
+   if (!intel_pt_validate_hw_cap(PT_CAP_topa_multiple_entries))
return;
 
BUG_ON(last->last != TENTS_PER_PAGE - 1);
@@ -654,7 +655,7 @@ static void topa_insert_table(struct pt_buffer *buf, struct 
topa *topa)
 static bool topa_table_full(struct topa *topa)
 {
/* single-entry ToPA is a special case */
-   if (!pt_cap_get(PT_CAP_topa_multiple_entries))
+   if (!intel_pt_validate_hw_cap(PT_CAP_topa_multiple_entries))
return !!topa->last;
 

[PATCH v13 05/12] perf/x86/intel/pt: add new capability for Intel PT

2018-10-24 Thread Luwei Kang
This adds support for "output to Trace Transport subsystem"
capability of Intel PT. It means that PT can output its
trace to an MMIO address range rather than system memory buffer.

Acked-by: Song Liu 
Signed-off-by: Luwei Kang 
---
 arch/x86/events/intel/pt.c  | 1 +
 arch/x86/include/asm/intel_pt.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 53e481a..9597ea6 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -68,6 +68,7 @@
PT_CAP(topa_output, 0, CPUID_ECX, BIT(0)),
PT_CAP(topa_multiple_entries,   0, CPUID_ECX, BIT(1)),
PT_CAP(single_range_output, 0, CPUID_ECX, BIT(2)),
+   PT_CAP(output_subsys,   0, CPUID_ECX, BIT(3)),
PT_CAP(payloads_lip,0, CPUID_ECX, BIT(31)),
PT_CAP(num_address_ranges,  1, CPUID_EAX, 0x3),
PT_CAP(mtc_periods, 1, CPUID_EAX, 0x),
diff --git a/arch/x86/include/asm/intel_pt.h b/arch/x86/include/asm/intel_pt.h
index 00f4afb..634f99b 100644
--- a/arch/x86/include/asm/intel_pt.h
+++ b/arch/x86/include/asm/intel_pt.h
@@ -16,6 +16,7 @@ enum pt_capabilities {
PT_CAP_topa_output,
PT_CAP_topa_multiple_entries,
PT_CAP_single_range_output,
+   PT_CAP_output_subsys,
PT_CAP_payloads_lip,
PT_CAP_num_address_ranges,
PT_CAP_mtc_periods,
-- 
1.8.3.1



[PATCH v13 04/12] perf/x86/intel/pt: Add new bit definitions for PT MSRs

2018-10-24 Thread Luwei Kang
Add bit definitions for Intel PT MSRs to support trace output
directed to the memeory subsystem and holds a count if packet
bytes that have been sent out.

These are required by the upcoming PT support in KVM guests
for MSRs read/write emulation.

Signed-off-by: Luwei Kang 
---
 arch/x86/include/asm/msr-index.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index d3a9eb9..107818e3 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -126,6 +126,7 @@
 #define RTIT_CTL_USR   BIT(3)
 #define RTIT_CTL_PWR_EVT_ENBIT(4)
 #define RTIT_CTL_FUP_ON_PTWBIT(5)
+#define RTIT_CTL_FABRIC_EN BIT(6)
 #define RTIT_CTL_CR3EN BIT(7)
 #define RTIT_CTL_TOPA  BIT(8)
 #define RTIT_CTL_MTC_ENBIT(9)
@@ -154,6 +155,8 @@
 #define RTIT_STATUS_BUFFOVFBIT(3)
 #define RTIT_STATUS_ERROR  BIT(4)
 #define RTIT_STATUS_STOPPEDBIT(5)
+#define RTIT_STATUS_BYTECNT_OFFSET 32
+#define RTIT_STATUS_BYTECNT(0x1ull << 
RTIT_STATUS_BYTECNT_OFFSET)
 #define MSR_IA32_RTIT_ADDR0_A  0x0580
 #define MSR_IA32_RTIT_ADDR0_B  0x0581
 #define MSR_IA32_RTIT_ADDR1_A  0x0582
-- 
1.8.3.1



[PATCH v13 03/12] perf/x86/intel/pt: Introduce intel_pt_validate_cap()

2018-10-24 Thread Luwei Kang
intel_pt_validate_hw_cap() validates whether a given PT capability is
supported by the hardware. It checks the PT capability array which
reflects the capabilities of the hardware on which the code is executed.

For setting up PT for KVM guests this is not correct as the capability
array for the guest can be different from the host array.

Provide a new function to check against a given capability array.

Acked-by: Song Liu 
Signed-off-by: Luwei Kang 
---
 arch/x86/events/intel/pt.c  | 12 +---
 arch/x86/include/asm/intel_pt.h |  2 ++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 309bb1d..53e481a 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -75,14 +75,20 @@
PT_CAP(psb_periods, 1, CPUID_EBX, 0x),
 };
 
-u32 intel_pt_validate_hw_cap(enum pt_capabilities cap)
+u32 intel_pt_validate_cap(u32 *caps, enum pt_capabilities capability)
 {
-   struct pt_cap_desc *cd = &pt_caps[cap];
-   u32 c = pt_pmu.caps[cd->leaf * PT_CPUID_REGS_NUM + cd->reg];
+   struct pt_cap_desc *cd = &pt_caps[capability];
+   u32 c = caps[cd->leaf * PT_CPUID_REGS_NUM + cd->reg];
unsigned int shift = __ffs(cd->mask);
 
return (c & cd->mask) >> shift;
 }
+EXPORT_SYMBOL_GPL(intel_pt_validate_cap);
+
+u32 intel_pt_validate_hw_cap(enum pt_capabilities cap)
+{
+   return intel_pt_validate_cap(pt_pmu.caps, cap);
+}
 EXPORT_SYMBOL_GPL(intel_pt_validate_hw_cap);
 
 static ssize_t pt_cap_show(struct device *cdev,
diff --git a/arch/x86/include/asm/intel_pt.h b/arch/x86/include/asm/intel_pt.h
index fa4b4fd..00f4afb 100644
--- a/arch/x86/include/asm/intel_pt.h
+++ b/arch/x86/include/asm/intel_pt.h
@@ -26,9 +26,11 @@ enum pt_capabilities {
 #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_CPU_SUP_INTEL)
 void cpu_emergency_stop_pt(void);
 extern u32 intel_pt_validate_hw_cap(enum pt_capabilities cap);
+extern u32 intel_pt_validate_cap(u32 *caps, enum pt_capabilities cap);
 #else
 static inline void cpu_emergency_stop_pt(void) {}
 static inline u32 intel_pt_validate_hw_cap(enum pt_capabilities cap) { return 
0; }
+static inline u32 intel_pt_validate_cap(u32 *caps, enum pt_capabilities 
capability) { return 0; }
 #endif
 
 #endif /* _ASM_X86_INTEL_PT_H */
-- 
1.8.3.1



[PATCH v13 01/12] perf/x86/intel/pt: Move Intel PT MSRs bit defines to global header

2018-10-24 Thread Luwei Kang
From: Chao Peng 

The Intel Processor Trace (PT) MSR bit defines are in a private
header. The upcoming support for PT virtualization requires these defines
to be accessible from KVM code.

Move them to the global MSR header file.

Reviewed-by: Thomas Gleixner 
Signed-off-by: Chao Peng 
Signed-off-by: Luwei Kang 
---
 arch/x86/events/intel/pt.h   | 37 -
 arch/x86/include/asm/msr-index.h | 33 +
 2 files changed, 33 insertions(+), 37 deletions(-)

diff --git a/arch/x86/events/intel/pt.h b/arch/x86/events/intel/pt.h
index 0eb41d0..0050ca1 100644
--- a/arch/x86/events/intel/pt.h
+++ b/arch/x86/events/intel/pt.h
@@ -20,43 +20,6 @@
 #define __INTEL_PT_H__
 
 /*
- * PT MSR bit definitions
- */
-#define RTIT_CTL_TRACEEN   BIT(0)
-#define RTIT_CTL_CYCLEACC  BIT(1)
-#define RTIT_CTL_OSBIT(2)
-#define RTIT_CTL_USR   BIT(3)
-#define RTIT_CTL_PWR_EVT_ENBIT(4)
-#define RTIT_CTL_FUP_ON_PTWBIT(5)
-#define RTIT_CTL_CR3EN BIT(7)
-#define RTIT_CTL_TOPA  BIT(8)
-#define RTIT_CTL_MTC_ENBIT(9)
-#define RTIT_CTL_TSC_ENBIT(10)
-#define RTIT_CTL_DISRETC   BIT(11)
-#define RTIT_CTL_PTW_ENBIT(12)
-#define RTIT_CTL_BRANCH_EN BIT(13)
-#define RTIT_CTL_MTC_RANGE_OFFSET  14
-#define RTIT_CTL_MTC_RANGE (0x0full << RTIT_CTL_MTC_RANGE_OFFSET)
-#define RTIT_CTL_CYC_THRESH_OFFSET 19
-#define RTIT_CTL_CYC_THRESH(0x0full << RTIT_CTL_CYC_THRESH_OFFSET)
-#define RTIT_CTL_PSB_FREQ_OFFSET   24
-#define RTIT_CTL_PSB_FREQ  (0x0full << 
RTIT_CTL_PSB_FREQ_OFFSET)
-#define RTIT_CTL_ADDR0_OFFSET  32
-#define RTIT_CTL_ADDR0 (0x0full << RTIT_CTL_ADDR0_OFFSET)
-#define RTIT_CTL_ADDR1_OFFSET  36
-#define RTIT_CTL_ADDR1 (0x0full << RTIT_CTL_ADDR1_OFFSET)
-#define RTIT_CTL_ADDR2_OFFSET  40
-#define RTIT_CTL_ADDR2 (0x0full << RTIT_CTL_ADDR2_OFFSET)
-#define RTIT_CTL_ADDR3_OFFSET  44
-#define RTIT_CTL_ADDR3 (0x0full << RTIT_CTL_ADDR3_OFFSET)
-#define RTIT_STATUS_FILTEREN   BIT(0)
-#define RTIT_STATUS_CONTEXTEN  BIT(1)
-#define RTIT_STATUS_TRIGGEREN  BIT(2)
-#define RTIT_STATUS_BUFFOVFBIT(3)
-#define RTIT_STATUS_ERROR  BIT(4)
-#define RTIT_STATUS_STOPPEDBIT(5)
-
-/*
  * Single-entry ToPA: when this close to region boundary, switch
  * buffers to avoid losing data.
  */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 4731f0c..d3a9eb9 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -120,7 +120,40 @@
 #define MSR_PEBS_LD_LAT_THRESHOLD  0x03f6
 
 #define MSR_IA32_RTIT_CTL  0x0570
+#define RTIT_CTL_TRACEEN   BIT(0)
+#define RTIT_CTL_CYCLEACC  BIT(1)
+#define RTIT_CTL_OSBIT(2)
+#define RTIT_CTL_USR   BIT(3)
+#define RTIT_CTL_PWR_EVT_ENBIT(4)
+#define RTIT_CTL_FUP_ON_PTWBIT(5)
+#define RTIT_CTL_CR3EN BIT(7)
+#define RTIT_CTL_TOPA  BIT(8)
+#define RTIT_CTL_MTC_ENBIT(9)
+#define RTIT_CTL_TSC_ENBIT(10)
+#define RTIT_CTL_DISRETC   BIT(11)
+#define RTIT_CTL_PTW_ENBIT(12)
+#define RTIT_CTL_BRANCH_EN BIT(13)
+#define RTIT_CTL_MTC_RANGE_OFFSET  14
+#define RTIT_CTL_MTC_RANGE (0x0full << RTIT_CTL_MTC_RANGE_OFFSET)
+#define RTIT_CTL_CYC_THRESH_OFFSET 19
+#define RTIT_CTL_CYC_THRESH(0x0full << RTIT_CTL_CYC_THRESH_OFFSET)
+#define RTIT_CTL_PSB_FREQ_OFFSET   24
+#define RTIT_CTL_PSB_FREQ  (0x0full << RTIT_CTL_PSB_FREQ_OFFSET)
+#define RTIT_CTL_ADDR0_OFFSET  32
+#define RTIT_CTL_ADDR0 (0x0full << RTIT_CTL_ADDR0_OFFSET)
+#define RTIT_CTL_ADDR1_OFFSET  36
+#define RTIT_CTL_ADDR1 (0x0full << RTIT_CTL_ADDR1_OFFSET)
+#define RTIT_CTL_ADDR2_OFFSET  40
+#define RTIT_CTL_ADDR2 (0x0full << RTIT_CTL_ADDR2_OFFSET)
+#define RTIT_CTL_ADDR3_OFFSET  44
+#define RTIT_CTL_ADDR3 (0x0full << RTIT_CTL_ADDR3_OFFSET)
 #define MSR_IA32_RTIT_STATUS   0x0571
+#define RTIT_STATUS_FILTEREN   BIT(0)
+#define RTIT_STATUS_CONTEXTEN  BIT(1)
+#define RTIT_STATUS_TRIGGEREN  BIT(2)
+#define RTIT_STATUS_BUFFOVFBIT(3)
+#define RTIT_STATUS_ERROR  BIT(4)
+#define RTIT_STATUS_STOPPEDBIT(5)
 #define MSR_IA32_RTIT_ADDR0_A  0x0580
 #define MSR_IA32_RTIT_ADDR0_B  0x0581
 #define MSR_IA32_RTIT_ADDR1_A  0x0582
-- 
1.8.3.1



[PATCH v13 12/12] KVM: x86: Disable Intel PT when VMXON in L1 guest

2018-10-24 Thread Luwei Kang
Currently, Intel Processor Trace do not support tracing in L1 guest
VMX operation(IA32_VMX_MISC[bit 14] is 0). As mentioned in SDM,
on these type of processors, execution of the VMXON instruction will
clears IA32_RTIT_CTL.TraceEn and any attempt to write IA32_RTIT_CTL
causes a general-protection exception (#GP).

Signed-off-by: Luwei Kang 
---
 arch/x86/kvm/vmx.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ed247dd..5001049 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4556,7 +4556,8 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
break;
case MSR_IA32_RTIT_CTL:
if ((pt_mode != PT_MODE_HOST_GUEST) ||
-   vmx_rtit_ctl_check(vcpu, data))
+   vmx_rtit_ctl_check(vcpu, data) ||
+   vmx->nested.vmxon)
return 1;
vmcs_write64(GUEST_IA32_RTIT_CTL, data);
pt_set_intercept_for_msr(vmx, !(data & RTIT_CTL_TRACEEN));
@@ -8760,6 +8761,11 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
if (ret)
return ret;
 
+   if (pt_mode == PT_MODE_HOST_GUEST) {
+   vmx->pt_desc.guest.ctl = 0;
+   pt_set_intercept_for_msr(vmx, 1);
+   }
+
return nested_vmx_succeed(vcpu);
 }
 
-- 
1.8.3.1



[PATCH v13 08/12] KVM: x86: Add Intel PT context switch for each vcpu

2018-10-24 Thread Luwei Kang
From: Chao Peng 

Load/Store Intel Processor Trace register in context switch.
MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS.
In Host-Guest mode, we need load/resore PT MSRs only when PT
is enabled in guest.

Signed-off-by: Chao Peng 
Signed-off-by: Luwei Kang 
---
 arch/x86/include/asm/intel_pt.h |  2 +
 arch/x86/kvm/vmx.c  | 94 +
 2 files changed, 96 insertions(+)

diff --git a/arch/x86/include/asm/intel_pt.h b/arch/x86/include/asm/intel_pt.h
index 4727584..eabbdbc 100644
--- a/arch/x86/include/asm/intel_pt.h
+++ b/arch/x86/include/asm/intel_pt.h
@@ -8,6 +8,8 @@
 #define PT_MODE_SYSTEM 0
 #define PT_MODE_HOST_GUEST 1
 
+#define RTIT_ADDR_RANGE4
+
 enum pt_capabilities {
PT_CAP_max_subleaf = 0,
PT_CAP_cr3_filtering,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 692154c..d8480a6 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -978,6 +978,24 @@ struct vmx_msrs {
struct vmx_msr_entryval[NR_AUTOLOAD_MSRS];
 };
 
+struct pt_ctx {
+   u64 ctl;
+   u64 status;
+   u64 output_base;
+   u64 output_mask;
+   u64 cr3_match;
+   u64 addr_a[RTIT_ADDR_RANGE];
+   u64 addr_b[RTIT_ADDR_RANGE];
+};
+
+struct pt_desc {
+   u64 ctl_bitmask;
+   u32 addr_range;
+   u32 caps[PT_CPUID_REGS_NUM * PT_CPUID_LEAVES];
+   struct pt_ctx host;
+   struct pt_ctx guest;
+};
+
 struct vcpu_vmx {
struct kvm_vcpu   vcpu;
unsigned long host_rsp;
@@ -1071,6 +1089,8 @@ struct vcpu_vmx {
u64 msr_ia32_feature_control;
u64 msr_ia32_feature_control_valid_bits;
u64 ept_pointer;
+
+   struct pt_desc pt_desc;
 };
 
 enum segment_cache_field {
@@ -2899,6 +2919,69 @@ static unsigned long segment_base(u16 selector)
 }
 #endif
 
+static inline void pt_load_msr(struct pt_ctx *ctx, u32 addr_range)
+{
+   u32 i;
+
+   wrmsrl(MSR_IA32_RTIT_STATUS, ctx->status);
+   wrmsrl(MSR_IA32_RTIT_OUTPUT_BASE, ctx->output_base);
+   wrmsrl(MSR_IA32_RTIT_OUTPUT_MASK, ctx->output_mask);
+   wrmsrl(MSR_IA32_RTIT_CR3_MATCH, ctx->cr3_match);
+   for (i = 0; i < addr_range; i++) {
+   wrmsrl(MSR_IA32_RTIT_ADDR0_A + i * 2, ctx->addr_a[i]);
+   wrmsrl(MSR_IA32_RTIT_ADDR0_B + i * 2, ctx->addr_b[i]);
+   }
+}
+
+static inline void pt_save_msr(struct pt_ctx *ctx, u32 addr_range)
+{
+   u32 i;
+
+   rdmsrl(MSR_IA32_RTIT_STATUS, ctx->status);
+   rdmsrl(MSR_IA32_RTIT_OUTPUT_BASE, ctx->output_base);
+   rdmsrl(MSR_IA32_RTIT_OUTPUT_MASK, ctx->output_mask);
+   rdmsrl(MSR_IA32_RTIT_CR3_MATCH, ctx->cr3_match);
+   for (i = 0; i < addr_range; i++) {
+   rdmsrl(MSR_IA32_RTIT_ADDR0_A + i * 2, ctx->addr_a[i]);
+   rdmsrl(MSR_IA32_RTIT_ADDR0_B + i * 2, ctx->addr_b[i]);
+   }
+}
+
+static void pt_guest_enter(struct vcpu_vmx *vmx)
+{
+   if (pt_mode == PT_MODE_SYSTEM)
+   return;
+
+   /* Save host state before VM entry */
+   rdmsrl(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl);
+
+   /*
+* Set guest state of MSR_IA32_RTIT_CTL MSR (PT will be disabled
+* on VM entry when it has been disabled in guest before).
+*/
+   vmcs_write64(GUEST_IA32_RTIT_CTL, vmx->pt_desc.guest.ctl);
+
+   if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) {
+   wrmsrl(MSR_IA32_RTIT_CTL, 0);
+   pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.addr_range);
+   pt_load_msr(&vmx->pt_desc.guest, vmx->pt_desc.addr_range);
+   }
+}
+
+static void pt_guest_exit(struct vcpu_vmx *vmx)
+{
+   if (pt_mode == PT_MODE_SYSTEM)
+   return;
+
+   if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) {
+   pt_save_msr(&vmx->pt_desc.guest, vmx->pt_desc.addr_range);
+   pt_load_msr(&vmx->pt_desc.host, vmx->pt_desc.addr_range);
+   }
+
+   /* Reload host state (IA32_RTIT_CTL will be cleared on VM exit). */
+   wrmsrl(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl);
+}
+
 static void vmx_prepare_switch_to_guest(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -6749,6 +6832,13 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx)
 
if (cpu_has_vmx_encls_vmexit())
vmcs_write64(ENCLS_EXITING_BITMAP, -1ull);
+
+   if (pt_mode == PT_MODE_HOST_GUEST) {
+   memset(&vmx->pt_desc, 0, sizeof(vmx->pt_desc));
+   /* Bit[6~0] are forced to 1, writes are ignored. */
+   vmx->pt_desc.guest.output_mask = 0x7F;
+   vmcs_write64(GUEST_IA32_RTIT_CTL, 0);
+   }
 }
 
 static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
@@ -11260,6 +11350,8 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
vcpu->arch.pkru != vmx->host_pkru)
__write_pkru(vcpu->arch.pkru);
 
+   pt_guest_enter(vmx);
+
atomic_switch_perf_msrs(vmx);
 

[PATCH v13 06/12] KVM: x86: Add Intel PT virtualization work mode

2018-10-24 Thread Luwei Kang
From: Chao Peng 

Intel Processor Trace virtualization can be work in one
of 2 possible modes:

a. System-Wide mode (default):
   When the host configures Intel PT to collect trace packets
   of the entire system, it can leave the relevant VMX controls
   clear to allow VMX-specific packets to provide information
   across VMX transitions.
   KVM guest will not aware this feature in this mode and both
   host and KVM guest trace will output to host buffer.

b. Host-Guest mode:
   Host can configure trace-packet generation while in
   VMX non-root operation for guests and root operation
   for native executing normally.
   Intel PT will be exposed to KVM guest in this mode, and
   the trace output to respective buffer of host and guest.
   In this mode, tht status of PT will be saved and disabled
   before VM-entry and restored after VM-exit if trace
   a virtual machine.

Signed-off-by: Chao Peng 
Signed-off-by: Luwei Kang 
---
 arch/x86/include/asm/intel_pt.h  |  3 ++
 arch/x86/include/asm/msr-index.h |  1 +
 arch/x86/include/asm/vmx.h   |  8 +
 arch/x86/kvm/vmx.c   | 68 +---
 4 files changed, 76 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/intel_pt.h b/arch/x86/include/asm/intel_pt.h
index 634f99b..4727584 100644
--- a/arch/x86/include/asm/intel_pt.h
+++ b/arch/x86/include/asm/intel_pt.h
@@ -5,6 +5,9 @@
 #define PT_CPUID_LEAVES2
 #define PT_CPUID_REGS_NUM  4 /* number of regsters (eax, ebx, ecx, edx) */
 
+#define PT_MODE_SYSTEM 0
+#define PT_MODE_HOST_GUEST 1
+
 enum pt_capabilities {
PT_CAP_max_subleaf = 0,
PT_CAP_cr3_filtering,
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 107818e3..f51579d 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -805,6 +805,7 @@
 #define VMX_BASIC_INOUT0x0040LLU
 
 /* MSR_IA32_VMX_MISC bits */
+#define MSR_IA32_VMX_MISC_INTEL_PT (1ULL << 14)
 #define MSR_IA32_VMX_MISC_VMWRITE_SHADOW_RO_FIELDS (1ULL << 29)
 #define MSR_IA32_VMX_MISC_PREEMPTION_TIMER_SCALE   0x1F
 /* AMD-V MSRs */
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index ade0f15..b99710c 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -77,7 +77,9 @@
 #define SECONDARY_EXEC_ENCLS_EXITING   0x8000
 #define SECONDARY_EXEC_RDSEED_EXITING  0x0001
 #define SECONDARY_EXEC_ENABLE_PML   0x0002
+#define SECONDARY_EXEC_PT_CONCEAL_VMX  0x0008
 #define SECONDARY_EXEC_XSAVES  0x0010
+#define SECONDARY_EXEC_PT_USE_GPA  0x0100
 #define SECONDARY_EXEC_TSC_SCALING  0x0200
 
 #define PIN_BASED_EXT_INTR_MASK 0x0001
@@ -98,6 +100,8 @@
 #define VM_EXIT_LOAD_IA32_EFER  0x0020
 #define VM_EXIT_SAVE_VMX_PREEMPTION_TIMER   0x0040
 #define VM_EXIT_CLEAR_BNDCFGS   0x0080
+#define VM_EXIT_PT_CONCEAL_PIP 0x0100
+#define VM_EXIT_CLEAR_IA32_RTIT_CTL0x0200
 
 #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR  0x00036dff
 
@@ -109,6 +113,8 @@
 #define VM_ENTRY_LOAD_IA32_PAT 0x4000
 #define VM_ENTRY_LOAD_IA32_EFER 0x8000
 #define VM_ENTRY_LOAD_BNDCFGS   0x0001
+#define VM_ENTRY_PT_CONCEAL_PIP0x0002
+#define VM_ENTRY_LOAD_IA32_RTIT_CTL0x0004
 
 #define VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR 0x11ff
 
@@ -240,6 +246,8 @@ enum vmcs_field {
GUEST_PDPTR3_HIGH   = 0x2811,
GUEST_BNDCFGS   = 0x2812,
GUEST_BNDCFGS_HIGH  = 0x2813,
+   GUEST_IA32_RTIT_CTL = 0x2814,
+   GUEST_IA32_RTIT_CTL_HIGH= 0x2815,
HOST_IA32_PAT   = 0x2c00,
HOST_IA32_PAT_HIGH  = 0x2c01,
HOST_IA32_EFER  = 0x2c02,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 641a65b..c4c4b76 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "trace.h"
 #include "pmu.h"
@@ -190,6 +191,10 @@
 static unsigned int ple_window_max= KVM_VMX_DEFAULT_PLE_WINDOW_MAX;
 module_param(ple_window_max, uint, 0444);
 
+/* Default is SYSTEM mode. */
+static int __read_mostly pt_mode = PT_MODE_SYSTEM;
+module_param(pt_mode, int, S_IRUGO);
+
 extern const ulong vmx_return;
 extern const ulong vmx_early_consistency_check_return;
 
@@ -1955,6 +1960,20 @@ static bool vmx_umip_emulated(void)
SECONDARY_EXEC_DESC;
 }
 
+static inline bool cpu_has_vmx_intel_pt(void)
+{
+   u64 vmx_msr;
+
+   rdmsrl(MSR_IA32_VMX_MISC, vmx_msr);
+   return !!(vmx_msr & MSR_IA32_VMX_MISC_INTEL_PT);
+}
+
+static inline bool cpu_has_vmx_pt_use

[PATCH v13 09/12] KVM: x86: Introduce a function to initialize the PT configuration

2018-10-24 Thread Luwei Kang
Initialize the Intel PT configuration when cpuid update.
Include cpuid inforamtion, rtit_ctl bit mask and the number of
address ranges.

Signed-off-by: Luwei Kang 
---
 arch/x86/kvm/vmx.c | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d8480a6..2697618 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -11921,6 +11921,75 @@ static void nested_vmx_entry_exit_ctls_update(struct 
kvm_vcpu *vcpu)
}
 }
 
+static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
+{
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
+   struct kvm_cpuid_entry2 *best = NULL;
+   int i;
+
+   for (i = 0; i < PT_CPUID_LEAVES; i++) {
+   best = kvm_find_cpuid_entry(vcpu, 0x14, i);
+   if (!best)
+   return;
+   vmx->pt_desc.caps[CPUID_EAX + i*PT_CPUID_REGS_NUM] = best->eax;
+   vmx->pt_desc.caps[CPUID_EBX + i*PT_CPUID_REGS_NUM] = best->ebx;
+   vmx->pt_desc.caps[CPUID_ECX + i*PT_CPUID_REGS_NUM] = best->ecx;
+   vmx->pt_desc.caps[CPUID_EDX + i*PT_CPUID_REGS_NUM] = best->edx;
+   }
+
+   /* Get the number of configurable Address Ranges for filtering */
+   vmx->pt_desc.addr_range = intel_pt_validate_cap(vmx->pt_desc.caps,
+   PT_CAP_num_address_ranges);
+
+   /* Initialize and clear the no dependency bits */
+   vmx->pt_desc.ctl_bitmask = ~(RTIT_CTL_TRACEEN | RTIT_CTL_OS |
+   RTIT_CTL_USR | RTIT_CTL_TSC_EN | RTIT_CTL_DISRETC);
+
+   /*
+* If CPUID.(EAX=14H,ECX=0):EBX[0]=1 CR3Filter can be set otherwise
+* will inject an #GP
+*/
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_cr3_filtering))
+   vmx->pt_desc.ctl_bitmask &= ~RTIT_CTL_CR3EN;
+
+   /*
+* If CPUID.(EAX=14H,ECX=0):EBX[1]=1 CYCEn, CycThresh and
+* PSBFreq can be set
+*/
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_psb_cyc))
+   vmx->pt_desc.ctl_bitmask &= ~(RTIT_CTL_CYCLEACC |
+   RTIT_CTL_CYC_THRESH | RTIT_CTL_PSB_FREQ);
+
+   /*
+* If CPUID.(EAX=14H,ECX=0):EBX[3]=1 MTCEn BranchEn and
+* MTCFreq can be set
+*/
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_mtc))
+   vmx->pt_desc.ctl_bitmask &= ~(RTIT_CTL_MTC_EN |
+   RTIT_CTL_BRANCH_EN | RTIT_CTL_MTC_RANGE);
+
+   /* If CPUID.(EAX=14H,ECX=0):EBX[4]=1 FUPonPTW and PTWEn can be set */
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_ptwrite))
+   vmx->pt_desc.ctl_bitmask &= ~(RTIT_CTL_FUP_ON_PTW |
+   RTIT_CTL_PTW_EN);
+
+   /* If CPUID.(EAX=14H,ECX=0):EBX[5]=1 PwrEvEn can be set */
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_power_event_trace))
+   vmx->pt_desc.ctl_bitmask &= ~RTIT_CTL_PWR_EVT_EN;
+
+   /* If CPUID.(EAX=14H,ECX=0):ECX[0]=1 ToPA can be set */
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_topa_output))
+   vmx->pt_desc.ctl_bitmask &= ~RTIT_CTL_TOPA;
+
+   /* If CPUID.(EAX=14H,ECX=0):ECX[3]=1 FabircEn can be set */
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_output_subsys))
+   vmx->pt_desc.ctl_bitmask &= ~RTIT_CTL_FABRIC_EN;
+
+   /* unmask address range configure area */
+   for (i = 0; i < vmx->pt_desc.addr_range; i++)
+   vmx->pt_desc.ctl_bitmask &= ~(0xf << (32 + i * 4));
+}
+
 static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -11941,6 +12010,10 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
nested_vmx_cr_fixed1_bits_update(vcpu);
nested_vmx_entry_exit_ctls_update(vcpu);
}
+
+   if (boot_cpu_has(X86_FEATURE_INTEL_PT) &&
+   guest_cpuid_has(vcpu, X86_FEATURE_INTEL_PT))
+   update_intel_pt_cfg(vcpu);
 }
 
 static void vmx_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2 *entry)
-- 
1.8.3.1



[PATCH v13 11/12] KVM: x86: Set intercept for Intel PT MSRs read/write

2018-10-24 Thread Luwei Kang
From: Chao Peng 

To save performance overhead, disable intercept Intel PT MSRs
read/write when Intel PT is enabled in guest.
MSR_IA32_RTIT_CTL is an exception that will always be intercepted.

Signed-off-by: Chao Peng 
Signed-off-by: Luwei Kang 
---
 arch/x86/kvm/vmx.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index a568d49..ed247dd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1333,6 +1333,7 @@ static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 
*vmcs12,
 static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
 static void __always_inline vmx_disable_intercept_for_msr(unsigned long 
*msr_bitmap,
  u32 msr, int type);
+static void pt_set_intercept_for_msr(struct vcpu_vmx *vmx, bool flag);
 
 static DEFINE_PER_CPU(struct vmcs *, vmxarea);
 static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
@@ -4558,6 +4559,7 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
vmx_rtit_ctl_check(vcpu, data))
return 1;
vmcs_write64(GUEST_IA32_RTIT_CTL, data);
+   pt_set_intercept_for_msr(vmx, !(data & RTIT_CTL_TRACEEN));
vmx->pt_desc.guest.ctl = data;
break;
case MSR_IA32_RTIT_STATUS:
@@ -6414,6 +6416,27 @@ static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu)
vmx->msr_bitmap_mode = mode;
 }
 
+static void pt_set_intercept_for_msr(struct vcpu_vmx *vmx, bool flag)
+{
+   unsigned long *msr_bitmap = vmx->vmcs01.msr_bitmap;
+   u32 i;
+
+   vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_RTIT_STATUS,
+   MSR_TYPE_RW, flag);
+   vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_RTIT_OUTPUT_BASE,
+   MSR_TYPE_RW, flag);
+   vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_RTIT_OUTPUT_MASK,
+   MSR_TYPE_RW, flag);
+   vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_RTIT_CR3_MATCH,
+   MSR_TYPE_RW, flag);
+   for (i = 0; i < vmx->pt_desc.addr_range; i++) {
+   vmx_set_intercept_for_msr(msr_bitmap,
+   MSR_IA32_RTIT_ADDR0_A + i * 2, MSR_TYPE_RW, flag);
+   vmx_set_intercept_for_msr(msr_bitmap,
+   MSR_IA32_RTIT_ADDR0_B + i * 2, MSR_TYPE_RW, flag);
+   }
+}
+
 static bool vmx_get_enable_apicv(struct kvm_vcpu *vcpu)
 {
return enable_apicv;
-- 
1.8.3.1



[PATCH v13 10/12] KVM: x86: Implement Intel PT MSRs read/write emulation

2018-10-24 Thread Luwei Kang
From: Chao Peng 

This patch implement Intel Processor Trace MSRs read/write
emulation.
Intel PT MSRs read/write need to be emulated when Intel PT
MSRs is intercepted in guest and during live migration.

Signed-off-by: Chao Peng 
Signed-off-by: Luwei Kang 
---
 arch/x86/include/asm/intel_pt.h |   8 ++
 arch/x86/kvm/vmx.c  | 176 
 arch/x86/kvm/x86.c  |  33 +++-
 3 files changed, 216 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/intel_pt.h b/arch/x86/include/asm/intel_pt.h
index eabbdbc..a1c2080 100644
--- a/arch/x86/include/asm/intel_pt.h
+++ b/arch/x86/include/asm/intel_pt.h
@@ -10,6 +10,14 @@
 
 #define RTIT_ADDR_RANGE4
 
+#define MSR_IA32_RTIT_STATUS_MASK (~(RTIT_STATUS_FILTEREN | \
+   RTIT_STATUS_CONTEXTEN | RTIT_STATUS_TRIGGEREN | \
+   RTIT_STATUS_ERROR | RTIT_STATUS_STOPPED | \
+   RTIT_STATUS_BYTECNT))
+
+#define MSR_IA32_RTIT_OUTPUT_BASE_MASK \
+   (~((1UL << cpuid_query_maxphyaddr(vcpu)) - 1) | 0x7f)
+
 enum pt_capabilities {
PT_CAP_max_subleaf = 0,
PT_CAP_cr3_filtering,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 2697618..a568d49 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3350,6 +3350,79 @@ static void vmx_set_interrupt_shadow(struct kvm_vcpu 
*vcpu, int mask)
vmcs_write32(GUEST_INTERRUPTIBILITY_INFO, interruptibility);
 }
 
+static int vmx_rtit_ctl_check(struct kvm_vcpu *vcpu, u64 data)
+{
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
+   unsigned long value;
+
+   /*
+* Any MSR write that attempts to change bits marked reserved will
+* case a #GP fault.
+*/
+   if (data & vmx->pt_desc.ctl_bitmask)
+   return 1;
+
+   /*
+* Any attempt to modify IA32_RTIT_CTL while TraceEn is set will
+* result in a #GP unless the same write also clears TraceEn.
+*/
+   if ((vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) &&
+   ((vmx->pt_desc.guest.ctl ^ data) & ~RTIT_CTL_TRACEEN))
+   return 1;
+
+   /*
+* WRMSR to IA32_RTIT_CTL that sets TraceEn but clears this bit
+* and FabricEn would cause #GP, if
+* CPUID.(EAX=14H, ECX=0):ECX.SNGLRGNOUT[bit 2] = 0
+*/
+   if ((data & RTIT_CTL_TRACEEN) && !(data & RTIT_CTL_TOPA) &&
+   !(data & RTIT_CTL_FABRIC_EN) &&
+   !intel_pt_validate_cap(vmx->pt_desc.caps,
+   PT_CAP_single_range_output))
+   return 1;
+
+   /*
+* MTCFreq, CycThresh and PSBFreq encodings check, any MSR write that
+* utilize encodings marked reserved will casue a #GP fault.
+*/
+   value = intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_mtc_periods);
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_mtc) &&
+   !test_bit((data & RTIT_CTL_MTC_RANGE) >>
+   RTIT_CTL_MTC_RANGE_OFFSET, &value))
+   return 1;
+   value = intel_pt_validate_cap(vmx->pt_desc.caps,
+   PT_CAP_cycle_thresholds);
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_psb_cyc) &&
+   !test_bit((data & RTIT_CTL_CYC_THRESH) >>
+   RTIT_CTL_CYC_THRESH_OFFSET, &value))
+   return 1;
+   value = intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_psb_periods);
+   if (intel_pt_validate_cap(vmx->pt_desc.caps, PT_CAP_psb_cyc) &&
+   !test_bit((data & RTIT_CTL_PSB_FREQ) >>
+   RTIT_CTL_PSB_FREQ_OFFSET, &value))
+   return 1;
+
+   /*
+* If ADDRx_CFG is reserved or the encodings is >2 will
+* cause a #GP fault.
+*/
+   value = (data & RTIT_CTL_ADDR0) >> RTIT_CTL_ADDR0_OFFSET;
+   if ((value && (vmx->pt_desc.addr_range < 1)) || (value > 2))
+   return 1;
+   value = (data & RTIT_CTL_ADDR1) >> RTIT_CTL_ADDR1_OFFSET;
+   if ((value && (vmx->pt_desc.addr_range < 2)) || (value > 2))
+   return 1;
+   value = (data & RTIT_CTL_ADDR2) >> RTIT_CTL_ADDR2_OFFSET;
+   if ((value && (vmx->pt_desc.addr_range < 3)) || (value > 2))
+   return 1;
+   value = (data & RTIT_CTL_ADDR3) >> RTIT_CTL_ADDR3_OFFSET;
+   if ((value && (vmx->pt_desc.addr_range < 4)) || (value > 2))
+   return 1;
+
+   return 0;
+}
+
+
 static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
 {
unsigned long rip;
@@ -4186,6 +4259,7 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
struct shared_msr_entry *msr;
+   u32 index;
 
switch (msr_info->index) {
 #ifdef CONFIG_X86_64
@@ -4250,6 +4324,52 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
return

[PATCH v13 07/12] KVM: x86: Add Intel Processor Trace cpuid emulation

2018-10-24 Thread Luwei Kang
From: Chao Peng 

Expose Intel Processor Trace to guest only when
the PT works in Host-Guest mode.

Signed-off-by: Chao Peng 
Signed-off-by: Luwei Kang 
---
 arch/x86/include/asm/kvm_host.h |  1 +
 arch/x86/kvm/cpuid.c| 22 --
 arch/x86/kvm/svm.c  |  6 ++
 arch/x86/kvm/vmx.c  |  6 ++
 4 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 55e51ff..9ab7ac0 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1105,6 +1105,7 @@ struct kvm_x86_ops {
bool (*mpx_supported)(void);
bool (*xsaves_supported)(void);
bool (*umip_emulated)(void);
+   bool (*pt_supported)(void);
 
int (*check_nested_events)(struct kvm_vcpu *vcpu, bool external_intr);
void (*request_immediate_exit)(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 7bcfa61..05b8fb4 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -337,6 +337,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
unsigned f_mpx = kvm_mpx_supported() ? F(MPX) : 0;
unsigned f_xsaves = kvm_x86_ops->xsaves_supported() ? F(XSAVES) : 0;
unsigned f_umip = kvm_x86_ops->umip_emulated() ? F(UMIP) : 0;
+   unsigned f_intel_pt = kvm_x86_ops->pt_supported() ? F(INTEL_PT) : 0;
 
/* cpuid 1.edx */
const u32 kvm_cpuid_1_edx_x86_features =
@@ -395,7 +396,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
F(BMI2) | F(ERMS) | f_invpcid | F(RTM) | f_mpx | F(RDSEED) |
F(ADX) | F(SMAP) | F(AVX512IFMA) | F(AVX512F) | F(AVX512PF) |
F(AVX512ER) | F(AVX512CD) | F(CLFLUSHOPT) | F(CLWB) | 
F(AVX512DQ) |
-   F(SHA_NI) | F(AVX512BW) | F(AVX512VL);
+   F(SHA_NI) | F(AVX512BW) | F(AVX512VL) | f_intel_pt;
 
/* cpuid 0xD.1.eax */
const u32 kvm_cpuid_D_1_eax_x86_features =
@@ -426,7 +427,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
 
switch (function) {
case 0:
-   entry->eax = min(entry->eax, (u32)0xd);
+   entry->eax = min(entry->eax, (u32)(f_intel_pt ? 0x14 : 0xd));
break;
case 1:
entry->edx &= kvm_cpuid_1_edx_x86_features;
@@ -603,6 +604,23 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
}
break;
}
+   /* Intel PT */
+   case 0x14: {
+   int t, times = entry->eax;
+
+   if (!f_intel_pt)
+   break;
+
+   entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
+   for (t = 1; t <= times; ++t) {
+   if (*nent >= maxnent)
+   goto out;
+   do_cpuid_1_ent(&entry[t], function, t);
+   entry[t].flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
+   ++*nent;
+   }
+   break;
+   }
case KVM_CPUID_SIGNATURE: {
static const char signature[12] = "KVMKVMKVM\0\0";
const u32 *sigptr = (const u32 *)signature;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f416f5c7..6e8a61b 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5904,6 +5904,11 @@ static bool svm_umip_emulated(void)
return false;
 }
 
+static bool svm_pt_supported(void)
+{
+   return false;
+}
+
 static bool svm_has_wbinvd_exit(void)
 {
return true;
@@ -7139,6 +7144,7 @@ static int nested_enable_evmcs(struct kvm_vcpu *vcpu,
.mpx_supported = svm_mpx_supported,
.xsaves_supported = svm_xsaves_supported,
.umip_emulated = svm_umip_emulated,
+   .pt_supported = svm_pt_supported,
 
.set_supported_cpuid = svm_set_supported_cpuid,
 
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c4c4b76..692154c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -11013,6 +11013,11 @@ static bool vmx_xsaves_supported(void)
SECONDARY_EXEC_XSAVES;
 }
 
+static bool vmx_pt_supported(void)
+{
+   return (pt_mode == PT_MODE_HOST_GUEST);
+}
+
 static void vmx_recover_nmi_blocking(struct vcpu_vmx *vmx)
 {
u32 exit_intr_info;
@@ -15127,6 +15132,7 @@ static int vmx_set_nested_state(struct kvm_vcpu *vcpu,
.mpx_supported = vmx_mpx_supported,
.xsaves_supported = vmx_xsaves_supported,
.umip_emulated = vmx_umip_emulated,
+   .pt_supported = vmx_pt_supported,
 
.check_nested_events = vmx_check_nested_events,
.request_immediate_exit = vmx_request_immediate_exit,
-- 
1.8.3.1



Re: [alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay

2018-10-24 Thread Mike Brady
Hi Kirill. Thanks for your comments.

> On 22 Oct 2018, at 23:25, Kirill Marinushkin  wrote:
> 
> AFAIU, this patch is wrong. Please correct me, maybe I misunderstand 
> something.
> 
>> The problem that this patch seeks to resolve is that when userland asks for
>> the delay
> 
> The userspace asks not for delay, but for the pointer.

The call in question is snd_pcm_delay. I presume this delay is calculated from 
knowledge of the stream position “pos", the period (buffer?) number (and 
period/buffer size) and the snd_pcm_runtime structure’s “delay" field 
(“runtime->delay”).

> You modify the function, which is called `snd_bcm2835_pcm_pointer`. Here you 
> are
> supposed to increase `alsa_stream->pos` with the proper offset. Instead, you
> imitate a delay, but in fact the delay is not increased.
> 
> So, the proper solution should be to fix the reported pointer.

I think there is a difficulty with this. The “pos” pointer looks to have to be 
modulo the buffer size. This causes a problem, as I see it, in that if the 
calculated (pos + interpolated delay in bytes) is longer than the buffer size, 
it must be wrapped, but AFAIK we are unable to increment a buffer index used in 
the snd_pcm_delay calculation. Hence the calculation of the actual position 
would be wrong. This is why the snd_pcm_runtime delay field is used. On 
reflection, BTW, the patch assumes that the field's original value was zero — 
that can be rectified.

> As a result,
> userspace will recieve the correct delay, instead of these crazy 10 ms.

Just to point out that with the proposed patch, it appears that the correct 
delay is being reported, (apart, possibly, from any delay originally set in the 
snd_pcm_delay field, as mentioned above).

All the best,
Mike

> FYI, there is
>> a discussion of the effects of a downstream equivalent of this suggested 
>> patch
>> at:
>> https://github.com/raspberrypi/firmware/issues/1026#issuecomment-415746016.
> 
> Thank you for the link, it clarified for me what you try to achieve.
> 
> On 10/22/18 21:17, Mike Brady wrote:
>> When the BCM2835 audio output is used, userspace sees a jitter up to 10ms
>> in the audio position, aka "delay" -- the number of frames that must
>> be output before a new frame would be played.
>> Make this a bit nicer for userspace by interpolating the position
>> using the CPU clock.
>> The overhead is small -- an extra ktime_get() every time a GPU message
>> is sent -- and another call and a few calculations whenever the delay
>> is sought from userland.
>> At 48,000 frames per second, i.e. approximately 20 microseconds per
>> frame, it would take a clock inaccuracy of
>> 20 microseconds in 10 milliseconds -- 2,000 parts per million --
>> to result in an inaccurate estimate, whereas
>> crystal- or resonator-based clocks typically have an
>> inaccuracy of 10s to 100s of parts per million.
>> 
>> Signed-off-by: Mike Brady 
>> ---
>> Changes in v2 -- remove inappropriate addition of SNDRV_PCM_INFO_BATCH flag
>> 
>> .../vc04_services/bcm2835-audio/bcm2835-pcm.c | 20 +++
>> .../vc04_services/bcm2835-audio/bcm2835.h |  1 +
>> 2 files changed, 21 insertions(+)
>> 
>> diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c 
>> b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
>> index e66da11af5cf..9053b996cada 100644
>> --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
>> +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
>> @@ -74,6 +74,7 @@ void bcm2835_playback_fifo(struct bcm2835_alsa_stream 
>> *alsa_stream,
>>  atomic_set(&alsa_stream->pos, pos);
>> 
>>  alsa_stream->period_offset += bytes;
>> +alsa_stream->interpolate_start = ktime_get();
>>  if (alsa_stream->period_offset >= alsa_stream->period_size) {
>>  alsa_stream->period_offset %= alsa_stream->period_size;
>>  snd_pcm_period_elapsed(substream);
>> @@ -243,6 +244,7 @@ static int snd_bcm2835_pcm_prepare(struct 
>> snd_pcm_substream *substream)
>>  atomic_set(&alsa_stream->pos, 0);
>>  alsa_stream->period_offset = 0;
>>  alsa_stream->draining = false;
>> +alsa_stream->interpolate_start = ktime_get();
>> 
>>  return 0;
>> }
>> @@ -292,6 +294,24 @@ snd_bcm2835_pcm_pointer(struct snd_pcm_substream 
>> *substream)
>> {
>>  struct snd_pcm_runtime *runtime = substream->runtime;
>>  struct bcm2835_alsa_stream *alsa_stream = runtime->private_data;
>> +ktime_t now = ktime_get();
>> +
>> +/* Give userspace better delay reporting by interpolating between GPU
>> + * notifications, assuming audio speed is close enough to the clock
>> + * used for ktime
>> + */
>> +
>> +if ((ktime_to_ns(alsa_stream->interpolate_start)) &&
>> +(ktime_compare(alsa_stream->interpolate_start, now) < 0)) {
>> +u64 interval =
>> +(ktime_to_ns(ktime_sub(now,
>> +alsa_stream->interpolate_start)));
>> +u64 frames_output_in_in

Re: [RFC][PATCH v3 01/10] fs: common implementation of file type

2018-10-24 Thread Phillip Potter
On Wed, Oct 24, 2018 at 09:16:20AM +0300, Amir Goldstein wrote:
> On Tue, Oct 23, 2018 at 11:19 PM Phillip Potter  wrote:
> >
> > Many file systems use a copy&paste implementation
> > of dirent to on-disk file type conversions.
> >
> > Create a common implementation to be used by file systems
> > with some useful conversion helpers to reduce open coded
> > file type conversions in file system code.
> >
> > Original patch written by Amir Goldstein.
> 
> Looks good.
> I guess you used 'git apply' or just 'patch'
> What you usually do when applying someone else mostly unchanged
> patches is use 'git am -s -3' so you preserve the original author and
> original commit message including the Signed-of-by line.
> You can edit your patch by hand to change the From: line to change the
> author and add
> Signed-off-by: Amir Goldstein 
> (you sign below me as you changed the patch last)
> 

Dear Amir,

Yes, I applied each patch manually to my tree, fixed it up where needed,
then after rebuilding and testing each one I committed it and regenerated
each patch. Thank you very much for your advice, I will take it into
account and make the necessary changes. In the meantime, do I add other
tags in the order they are received also (such as Reviewed-by:) and am
I safe to add these in when I re-send the patches with the changes you
and others have suggested (or would that offend people that have
offered the tags)?

Regards,
Phil


Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.

2018-10-24 Thread Michal Hocko
On Tue 23-10-18 23:26:16, Joe Perches wrote:
> On Wed, 2018-10-24 at 08:15 +0200, Michal Hocko wrote:
> > On Wed 24-10-18 10:47:52, Arun KS wrote:
> > > On 2018-10-24 01:34, Kees Cook wrote:
> > [...]
> > > > Thank you -- I was struggling to figure out the best way to reply to
> > > > this. :)
> > > I'm sorry for the trouble caused. Sent the email using,
> > > git send-email  --to-cmd="scripts/get_maintainer.pl -i"
> > > 0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch
> > > 
> > > Is this not a recommended approach?
> > 
> > Not really for tree wide mechanical changes. It is much more preferrable
> > IMHO to only CC people who should review the intention of the change
> > rather than each and every maintainer whose code is going to be changed.
> > This is a case by case thing of course but as soon as you see a giant CC
> > list from get_maintainer.pl then you should try to think twice to use
> > it. If not sure, just ask on the mailing list.
> 
> Generally, it's better to use scripts to control
> the --to-cmd and --cc-cmd options.

I would argue that it is better to use a common sense much more than
scripts.

-- 
Michal Hocko
SUSE Labs


[PATCH 4/4] kvm, vmx: remove manually coded vmx instructions

2018-10-24 Thread Julian Stecklina
So far the VMX code relied on manually assembled VMX instructions. This
was apparently done to ensure compatibility with old binutils. VMX
instructions were introduced with binutils 2.19 and the kernel currently
requires binutils 2.20.

Remove the manually assembled versions and replace them with the proper
inline assembly. This improves code generation (and source code
readability).

According to the bloat-o-meter this change removes ~1300 bytes from the
text segment.

Signed-off-by: Julian Stecklina 
Reviewed-by: Jan H. Schönherr 
Reviewed-by: Konrad Jan Miller 
Reviewed-by: Razvan-Alin Ghitulete 
---
 arch/x86/include/asm/virtext.h |  2 +-
 arch/x86/include/asm/vmx.h | 13 -
 arch/x86/kvm/vmx.c | 39 ++-
 3 files changed, 19 insertions(+), 35 deletions(-)

diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index 0116b2e..c5395b3 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -40,7 +40,7 @@ static inline int cpu_has_vmx(void)
  */
 static inline void cpu_vmxoff(void)
 {
-   asm volatile (ASM_VMX_VMXOFF : : : "cc");
+   asm volatile ("vmxoff" : : : "cc");
cr4_clear_bits(X86_CR4_VMXE);
 }
 
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 9527ba5..ade0f15 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -503,19 +503,6 @@ enum vmcs_field {
 
 #define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfffbc000ul
 
-
-#define ASM_VMX_VMCLEAR_RAX   ".byte 0x66, 0x0f, 0xc7, 0x30"
-#define ASM_VMX_VMLAUNCH  ".byte 0x0f, 0x01, 0xc2"
-#define ASM_VMX_VMRESUME  ".byte 0x0f, 0x01, 0xc3"
-#define ASM_VMX_VMPTRLD_RAX   ".byte 0x0f, 0xc7, 0x30"
-#define ASM_VMX_VMREAD_RDX_RAX".byte 0x0f, 0x78, 0xd0"
-#define ASM_VMX_VMWRITE_RAX_RDX   ".byte 0x0f, 0x79, 0xd0"
-#define ASM_VMX_VMWRITE_RSP_RDX   ".byte 0x0f, 0x79, 0xd4"
-#define ASM_VMX_VMXOFF".byte 0x0f, 0x01, 0xc4"
-#define ASM_VMX_VMXON_RAX ".byte 0xf3, 0x0f, 0xc7, 0x30"
-#define ASM_VMX_INVEPT   ".byte 0x66, 0x0f, 0x38, 0x80, 0x08"
-#define ASM_VMX_INVVPID  ".byte 0x66, 0x0f, 0x38, 0x81, 0x08"
-
 struct vmx_msr_entry {
u32 index;
u32 reserved;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 82cfb909..bbbdccb 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2077,7 +2077,7 @@ static int __find_msr_index(struct vcpu_vmx *vmx, u32 msr)
return -1;
 }
 
-static inline void __invvpid(int ext, u16 vpid, gva_t gva)
+static inline void __invvpid(long ext, u16 vpid, gva_t gva)
 {
struct {
u64 vpid : 16;
@@ -2086,21 +2086,21 @@ static inline void __invvpid(int ext, u16 vpid, gva_t 
gva)
} operand = { vpid, 0, gva };
bool error;
 
-   asm volatile (__ex(ASM_VMX_INVVPID) CC_SET(na)
- : CC_OUT(na) (error) : "a"(&operand), "c"(ext)
+   asm volatile ("invvpid %1, %2" CC_SET(na)
+ : CC_OUT(na) (error) : "m"(operand), "r"(ext)
  : "memory");
BUG_ON(error);
 }
 
-static inline void __invept(int ext, u64 eptp, gpa_t gpa)
+static inline void __invept(long ext, u64 eptp, gpa_t gpa)
 {
struct {
u64 eptp, gpa;
} operand = {eptp, gpa};
bool error;
 
-   asm volatile (__ex(ASM_VMX_INVEPT) CC_SET(na)
- : CC_OUT(na) (error) : "a" (&operand), "c" (ext)
+   asm volatile ("invept %1, %2" CC_SET(na)
+ : CC_OUT(na) (error) : "m" (operand), "r" (ext)
  : "memory");
BUG_ON(error);
 }
@@ -2120,8 +2120,8 @@ static void vmcs_clear(struct vmcs *vmcs)
u64 phys_addr = __pa(vmcs);
bool error;
 
-   asm volatile (__ex(ASM_VMX_VMCLEAR_RAX) CC_SET(na)
- : CC_OUT(na) (error) : "a"(&phys_addr), "m"(phys_addr)
+   asm volatile ("vmclear %1" CC_SET(na)
+ : CC_OUT(na) (error) : "m"(phys_addr)
  : "memory");
if (unlikely(error))
printk(KERN_ERR "kvm: vmclear fail: %p/%llx\n",
@@ -2145,8 +2145,8 @@ static void vmcs_load(struct vmcs *vmcs)
if (static_branch_unlikely(&enable_evmcs))
return evmcs_load(phys_addr);
 
-   asm volatile (__ex(ASM_VMX_VMPTRLD_RAX) CC_SET(na)
- : CC_OUT(na) (error) : "a"(&phys_addr), "m"(phys_addr)
+   asm volatile ("vmptrld %1" CC_SET(na)
+ : CC_OUT(na) (error) : "m"(phys_addr)
  : "memory");
if (unlikely(error))
printk(KERN_ERR "kvm: vmptrld %p/%llx failed\n",
@@ -2323,8 +2323,7 @@ static __always_inline unsigned long 
__vmcs_readl(unsigned long field)
 {
unsigned long value;
 
-   asm volatile (__ex_clear(ASM_VMX_VMREAD_RDX_RAX, "%0")
- : "=a"(value) : "d"(field) : "cc");
+   asm volatile ("vmread %1, %0" 

[PATCH 3/4] kvm, vmx: fix __invvpid style

2018-10-24 Thread Julian Stecklina
The code violated the coding style. Fixed by using tabs instead of
spaces. There are only whitespace changes here.

Signed-off-by: Julian Stecklina 
Reviewed-by: Jan H. Schönherr 
Reviewed-by: Konrad Jan Miller 
---
 arch/x86/kvm/vmx.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9225099..82cfb909 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2079,17 +2079,17 @@ static int __find_msr_index(struct vcpu_vmx *vmx, u32 
msr)
 
 static inline void __invvpid(int ext, u16 vpid, gva_t gva)
 {
-struct {
-   u64 vpid : 16;
-   u64 rsvd : 48;
-   u64 gva;
-} operand = { vpid, 0, gva };
-bool error;
-
-asm volatile (__ex(ASM_VMX_INVVPID) CC_SET(na)
- : CC_OUT(na) (error) : "a"(&operand), "c"(ext)
- : "memory");
-BUG_ON(error);
+   struct {
+   u64 vpid : 16;
+   u64 rsvd : 48;
+   u64 gva;
+   } operand = { vpid, 0, gva };
+   bool error;
+
+   asm volatile (__ex(ASM_VMX_INVVPID) CC_SET(na)
+ : CC_OUT(na) (error) : "a"(&operand), "c"(ext)
+ : "memory");
+   BUG_ON(error);
 }
 
 static inline void __invept(int ext, u64 eptp, gpa_t gpa)
-- 
2.7.4



Re: [PATCH] thermal: qoriq: add multiple sensors support

2018-10-24 Thread Daniel Lezcano
On 24/10/2018 04:48, Andy Tang wrote:
> Hi Daniel,
> 
>> -Original Message-
>> From: Daniel Lezcano 
>> Sent: 2018年10月16日 19:21
>> To: Andy Tang ; rui.zh...@intel.com
>> Cc: edubez...@gmail.com; linux...@vger.kernel.org;
>> linux-kernel@vger.kernel.org; Rob Herring 
>> Subject: Re: [PATCH] thermal: qoriq: add multiple sensors support
>>
>> The current code is reading the DT in order to get the sensor id
>> and initialize it. IOW, the DT gives the sensors to use.
>>
>> IMO, it would be more self contained if the driver initializes all
>> the sensors without taking care of the DT and let the of- code to
>> do the binding when the thermal zone, no ?
> [Andy] could you please explain more about this way? I am not sure
> how
 to implement it.
> But one thing is for sure: we must get the sensor IDs explicitly so
> that we can enable them by the following command:
>> tmu_write(qdata,
> sites | TMR_ME | TMR_ALPF, &qdata->regs->tmr);

 What I meant is about code separation between the driver itself and
 the of-thermal code.

 The code above re-inspect the DT to find out the sensor ids in order
 to enable them and somehow this is not wrong but breaks the self
 encapsulation of the driver. I was suggesting if it isn't possible to
 enable all the sensors without taking care of digging into the DT.
>>>
>>> [Andy] I don't want to re-parse the DT here too. But I have to.
>>> This driver will be used by all our SOCs with different sensor IDs and
>> number.
>>> For example: there are 2 sensors on ls1088a platform with ID 0 and 1.
>>> While on ls1043a there are 6 sensors with ID 0, 1, 2, 3, 4, 5.
>>> If we don't scan the DT we would not know how many sensors it is and
>>> what are the sensor's IDs, unless we hardcode it in driver.
>>
>> Yes, you are not the only one in this situation IMO and the drivers
>> supporting multiple sensors are increasing, so this will repeat again and
>> again.
>>
>> That could be hardcoded in the driver by using the compatible string but it
>> will be nicer if we can fix that in the DT.
>>
>> [Cc'ing Rob]
>>
>> What is missing is a description of the sensors id in the temperature
>> device node. We have the  with 0 or 1 telling if
>> there is one or several sensors but we can't specify which sensor ids we
>> have. The only alternative is to parse the thermal zones to found out which
>> sensors are in use and use them to initialize the driver, an approach which
>> breaks the self-encapsulation: the of-thermal framework is the one in
>> charge of doing the link between the thermal zone and a sensor id.
>>
>> Is it acceptable to add the list of the sensors id in the temp device node, 
>> so
>> the driver can initialize these sensors without parsing the thermal zone in
>> the DT ?
>>
> Have you got any conclusion yet?
> When can I send the next version of this patch?


Let's give an opportunity to Rob to answer.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



[PATCH 1/4] kvm, vmx: move CR2 context switch out of assembly path

2018-10-24 Thread Julian Stecklina
The VM entry/exit path is a giant inline assembly statement. Simplify it
by doing CR2 context switching in plain C. Move CR2 restore behind IBRS
clearing, so we reduce the amount of code we execute with IBRS on.

Signed-off-by: Julian Stecklina 
Reviewed-by: Jan H. Schönherr 
Reviewed-by: Konrad Jan Miller 
---
 arch/x86/kvm/vmx.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e665aa7..93562d5 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10728,6 +10728,9 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
evmcs_rsp = static_branch_unlikely(&enable_evmcs) ?
(unsigned long)¤t_evmcs->host_rsp : 0;
 
+   if (read_cr2() != vcpu->arch.cr2)
+   write_cr2(vcpu->arch.cr2);
+
if (static_branch_unlikely(&vmx_l1d_should_flush))
vmx_l1d_flush(vcpu);
 
@@ -10747,13 +10750,6 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
"2: \n\t"
__ex(ASM_VMX_VMWRITE_RSP_RDX) "\n\t"
"1: \n\t"
-   /* Reload cr2 if changed */
-   "mov %c[cr2](%0), %%" _ASM_AX " \n\t"
-   "mov %%cr2, %%" _ASM_DX " \n\t"
-   "cmp %%" _ASM_AX ", %%" _ASM_DX " \n\t"
-   "je 3f \n\t"
-   "mov %%" _ASM_AX", %%cr2 \n\t"
-   "3: \n\t"
/* Check if vmlaunch of vmresume is needed */
"cmpl $0, %c[launched](%0) \n\t"
/* Load guest registers.  Don't clobber flags. */
@@ -10810,8 +10806,6 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
"xor %%r14d, %%r14d \n\t"
"xor %%r15d, %%r15d \n\t"
 #endif
-   "mov %%cr2, %%" _ASM_AX "   \n\t"
-   "mov %%" _ASM_AX ", %c[cr2](%0) \n\t"
 
"xor %%eax, %%eax \n\t"
"xor %%ebx, %%ebx \n\t"
@@ -10843,7 +10837,6 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
[r14]"i"(offsetof(struct vcpu_vmx, 
vcpu.arch.regs[VCPU_REGS_R14])),
[r15]"i"(offsetof(struct vcpu_vmx, 
vcpu.arch.regs[VCPU_REGS_R15])),
 #endif
-   [cr2]"i"(offsetof(struct vcpu_vmx, vcpu.arch.cr2)),
[wordsize]"i"(sizeof(ulong))
  : "cc", "memory"
 #ifdef CONFIG_X86_64
@@ -10877,6 +10870,8 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
/* Eliminate branch target predictions from guest mode */
vmexit_fill_RSB();
 
+   vcpu->arch.cr2 = read_cr2();
+
/* All fields are clean at this point */
if (static_branch_unlikely(&enable_evmcs))
current_evmcs->hv_clean_fields |=
-- 
2.7.4



[PATCH 2/4] kvm, vmx: move register clearing out of assembly path

2018-10-24 Thread Julian Stecklina
Split the security related register clearing out of the large inline
assembly VM entry path. This results in two slightly less complicated
inline assembly statements, where it is clearer what each one does.

Signed-off-by: Julian Stecklina 
Reviewed-by: Jan H. Schönherr 
Reviewed-by: Konrad Jan Miller 
---
 arch/x86/kvm/vmx.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 93562d5..9225099 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10797,20 +10797,7 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
"mov %%r13, %c[r13](%0) \n\t"
"mov %%r14, %c[r14](%0) \n\t"
"mov %%r15, %c[r15](%0) \n\t"
-   "xor %%r8d,  %%r8d \n\t"
-   "xor %%r9d,  %%r9d \n\t"
-   "xor %%r10d, %%r10d \n\t"
-   "xor %%r11d, %%r11d \n\t"
-   "xor %%r12d, %%r12d \n\t"
-   "xor %%r13d, %%r13d \n\t"
-   "xor %%r14d, %%r14d \n\t"
-   "xor %%r15d, %%r15d \n\t"
 #endif
-
-   "xor %%eax, %%eax \n\t"
-   "xor %%ebx, %%ebx \n\t"
-   "xor %%esi, %%esi \n\t"
-   "xor %%edi, %%edi \n\t"
"pop  %%" _ASM_BP "; pop  %%" _ASM_DX " \n\t"
".pushsection .rodata \n\t"
".global vmx_return \n\t"
@@ -10847,6 +10834,26 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
 #endif
  );
 
+   /* Don't let guest register values survive. */
+   asm volatile (
+   ""
+#ifdef CONFIG_X86_64
+   "xor %%r8d,  %%r8d \n\t"
+   "xor %%r9d,  %%r9d \n\t"
+   "xor %%r10d, %%r10d \n\t"
+   "xor %%r11d, %%r11d \n\t"
+   "xor %%r12d, %%r12d \n\t"
+   "xor %%r13d, %%r13d \n\t"
+   "xor %%r14d, %%r14d \n\t"
+   "xor %%r15d, %%r15d \n\t"
+#endif
+   :: "a" (0), "b" (0), "S" (0), "D" (0)
+   : "cc"
+#ifdef CONFIG_X86_64
+ , "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15"
+#endif
+   );
+
/*
 * We do not use IBRS in the kernel. If this vCPU has used the
 * SPEC_CTRL MSR it may have left it on; save the value and
-- 
2.7.4



Re: [PATCH v15 1/2] leds: core: Introduce LED pattern trigger

2018-10-24 Thread Pavel Machek
Hi!

> > +
> > +   The gradual dimming format of the software pattern values 
> > should be:
> > +   "brightness_1 duration_1 brightness_2 duration_2 brightness_3
> > +   duration_3 ...". For example:
> > +
> > +   echo 0 1000 255 2000 > pattern
> > +
> > +   It will make the LED go gradually from zero-intensity to max 
> > (255)
> > +   intensity in 1000 milliseconds, then back to zero intensity in 
> > 2000
> > +   milliseconds:
> > +
> > +   LED brightness
> > +   ^
> > +   255-|   / \/ \/
> > +   |  /\ /\ /
> > +   | /   \  /   \  /
> > +   |/  \   /  \   /
> > + 0-|   / \/ \/
> > +   +---0123456> time (s)
> > +

Ok, so I got around to testing this.

echo "0 1000 10 2550 0 1000 0 100" > pattern

makes expected pattern [  .-xXx-.  ].

But when I do

echo "0 1000 10 2550 0 1000" > pattern

I only get expected pattern on the first iteration, then I get
[Xx-.   ].

I'm using led-controller:flash on nokia n900 (so everything in
software).

> OK, let's abide by constant update interval for now.
> 
> Thank you for your work on this patch set throughout
> all these months. We will have -rc8, so one week of testing
> before sending upstream should be enough.
> 
> Patch set applied to the for-next branch of linux-leds.git.

Thanks!
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v15 1/2] leds: core: Introduce LED pattern trigger

2018-10-24 Thread Pavel Machek
Hi!

> > OK, let's abide by constant update interval for now.
> >
> > Thank you for your work on this patch set throughout
> > all these months. We will have -rc8, so one week of testing
> > before sending upstream should be enough.
> >
> > Patch set applied to the for-next branch of linux-leds.git.
> 
> Thanks Jacek and Pavel, you are so patient and always give me lots of
> help there. Glad to co-work with you, thanks again.

Thanks for patience, too. I'm pretty sure pattern trigger will be
useful in future.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v2] [PATCH] KEYS: trusted: fix -Wvarags warning

2018-10-24 Thread Jarkko Sakkinen

On Mon, 22 Oct 2018, ndesaulni...@google.com wrote:

Fixes the warning reported by Clang:
security/keys/trusted.c:146:17: warning: passing an object that
undergoes default
 argument promotion to 'va_start' has undefined behavior [-Wvarargs]
   va_start(argp, h3);
  ^
security/keys/trusted.c:126:37: note: parameter of type 'unsigned
char' is declared here
unsigned char *h2, unsigned char h3, ...)
  ^
Specifically, it seems that both the C90 (4.8.1.1) and C11 (7.16.1.4)
standards explicitly call this out as undefined behavior:

The parameter parmN is the identifier of the rightmost parameter in
the variable parameter list in the function definition (the one just
before the ...). If the parameter parmN is declared with ... or with a
type that is not compatible with the type that results after
application of the default argument promotions, the behavior is
undefined.

Link: https://github.com/ClangBuiltLinux/linux/issues/41
Link: https://www.eskimo.com/~scs/cclass/int/sx11c.html
Suggested-by: David Laight 
Suggested-by: Denis Kenzior 
Suggested-by: James Bottomley 
Suggested-by: Nathan Chancellor 
Signed-off-by: Nick Desaulniers 


Reviewed-by: Jarkko Sakkinen 

/Jarkko


Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.

2018-10-24 Thread Joe Perches
On Wed, 2018-10-24 at 10:23 +0200, Michal Hocko wrote:
> On Tue 23-10-18 23:26:16, Joe Perches wrote:
> > On Wed, 2018-10-24 at 08:15 +0200, Michal Hocko wrote:
> > > On Wed 24-10-18 10:47:52, Arun KS wrote:
> > > > On 2018-10-24 01:34, Kees Cook wrote:
> > > [...]
> > > > > Thank you -- I was struggling to figure out the best way to reply to
> > > > > this. :)
> > > > I'm sorry for the trouble caused. Sent the email using,
> > > > git send-email  --to-cmd="scripts/get_maintainer.pl -i"
> > > > 0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch
> > > > 
> > > > Is this not a recommended approach?
> > > 
> > > Not really for tree wide mechanical changes. It is much more preferrable
> > > IMHO to only CC people who should review the intention of the change
> > > rather than each and every maintainer whose code is going to be changed.
> > > This is a case by case thing of course but as soon as you see a giant CC
> > > list from get_maintainer.pl then you should try to think twice to use
> > > it. If not sure, just ask on the mailing list.
> > 
> > Generally, it's better to use scripts to control
> > the --to-cmd and --cc-cmd options.
> 
> I would argue that it is better to use a common sense much more than
> scripts.

Common sense isn't common.

Perhaps you could describe some guidelines you
use to determine what you think is sensible to
send patches to maintainers and reviewers and
appropriate mailing lists.

Then compare those to the rules in the scripts
I suggested.

My suggestions:

o send to all top-level listed maintainers and
  reviewers in MAINTAINERS for the specific files
  in a patch
o cc all maintainers and reviewers that are upstream
  paths for the files in a patch
o cc all the upstream mailing lists for the files
  in the patch.
o do not generally use git-history to exclude authors
  of patches like drive-by/whitespace cleanups

Other advanced possibilities for patches that
modify specific and perhaps complex logic blocks:

o cc the people that are not maintainers that
  have modified the specific blocks or functions





Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver

2018-10-24 Thread Stephen Boyd
Quoting Jianxin Pan (2018-10-23 23:29:24)
> On 2018/10/19 1:13, Stephen Boyd wrote:
> > Quoting Jianxin Pan (2018-10-17 22:07:25)
> [...]
> >> diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c
> >> new file mode 100644
> >> index 000..e3f
> >> --- /dev/null
> >> +++ b/drivers/clk/meson/mmc-clkc.c
> >> @@ -0,0 +1,296 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> +/*
> >> + * Amlogic Meson MMC Sub Clock Controller Driver
> >> + *
> >> + * Copyright (c) 2017 Baylibre SAS.
> >> + * Author: Jerome Brunet 
> >> + *
> >> + * Copyright (c) 2018 Amlogic, inc.
> >> + * Author: Yixun Lan 
> >> + */
> >> +
> >> +#include 
> > 
> > clk-provider.h instead of clk.h?>
> Maybe we need to keep clk.h
> devm_clk_get() is called in mmc_clkc_register_mux() to get parent in from DTS.
> I'm sorry to miss this in previous reply.

OK. But also include clk-provider.h if provider APIs are being used
here.



Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

2018-10-24 Thread Laura Abbott

On 10/21/2018 02:20 PM, NeilBrown wrote:




I call on the community to consider what *does* need to be said, about
conduct, to people outside the community and who have recently joined.
What is the document that you would have liked to have read as you were
starting out?  It is all too long ago for me to remember clearly, and so
much has changed.



I joined much more recently than many and what I would have wanted
then is an interesting question. I probably would _not_ have wanted
a code of conduct when I first started working in open source. I also
said things in my younger years I regret and probably wouldn't have
said if I was held to a higher standard of conduct. Younger me frequently
put up with behavior I wouldn't tolerate today. Younger me also
greatly benefited from the experience of other kernel developers
giving me firm feedback in a helpful way and saying no to bad approaches.
I don't believe I would have continued if I hadn't been given that
feedback in a useful way.

Today, I think the code of conduct is a very important addition to
the community. It's a stronger assertion that the kernel community
is committed to raising the bar for behavior. I have no concern about
patch review or quality dropping because most maintainers demonstrate
every day that they can give effective feedback. We're all going to
screw that up sometimes and the Code of Conduct reminds us to do our
best. Most issues that arise can be resolved with a private e-mail
going "you might want to rethink your wording there."

What the Code of Conduct also provides is confidence that more serious
community issues such as harassment not related to patch
review can be handled. It spells out certain behaviors that won't
be tolerated and explains how those problems will be dealt with.
Will those problems actually be handled appropriately when the time
comes? I can't actually say for sure, but the kernel community works
on trust so I guess I have to trust that it will. I really hope I never
have to report harassment but I'm glad there's a process in place.

Thanks,
Laura


Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver

2018-10-24 Thread Jianxin Pan
On 2018/10/24 16:47, Stephen Boyd wrote:
> Quoting Jianxin Pan (2018-10-23 23:29:24)
>> On 2018/10/19 1:13, Stephen Boyd wrote:
>>> Quoting Jianxin Pan (2018-10-17 22:07:25)
>> [...]
 diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c
 new file mode 100644
 index 000..e3f
 --- /dev/null
 +++ b/drivers/clk/meson/mmc-clkc.c
 @@ -0,0 +1,296 @@
 +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 +/*
 + * Amlogic Meson MMC Sub Clock Controller Driver
 + *
 + * Copyright (c) 2017 Baylibre SAS.
 + * Author: Jerome Brunet 
 + *
 + * Copyright (c) 2018 Amlogic, inc.
 + * Author: Yixun Lan 
 + */
 +
 +#include 
>>>
>>> clk-provider.h instead of clk.h?>
>> Maybe we need to keep clk.h
>> devm_clk_get() is called in mmc_clkc_register_mux() to get parent in from 
>> DTS.
>> I'm sorry to miss this in previous reply.
> 
> OK. But also include clk-provider.h if provider APIs are being used
> here.
OK. I will add it. Thank you.
> 
> .
> 



[GIT pull] timekeeping upates for 4.20

2018-10-24 Thread Thomas Gleixner
Linus,

please pull the latest timers-core-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
timers-core-for-linus

The timers and timekeeping departement provides:

 - Another large y2038 update with further preparations for providing the
   y2038 safe timespecs closer to the syscalls.

 - An overhaul of the SHCMT clocksource driver

 - SPDX license identifier updates

 - Small cleanups and fixes all over the place

Thanks,

tglx

-->
Arnd Bergmann (14):
  y2038: remove unused time interfaces
  y2038: make do_gettimeofday() and get_seconds() inline
  y2038: globally rename compat_time to old_time32
  y2038: Remove newstat family from default syscall set
  y2038: Remove stat64 family from default syscall set
  asm-generic: Move common compat types to asm-generic/compat.h
  asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro
  asm-generic: Remove empty asm/unistd.h
  y2038: Change sys_utimensat() to use __kernel_timespec
  y2038: Compile utimes()/futimesat() conditionally
  y2038: utimes: Rework #ifdef guards for compat syscalls
  y2038: sched: Change sched_rr_get_interval to use __kernel_timespec
  y2038: socket: Change recvmmsg to use __kernel_timespec
  y2038: signal: Change rt_sigtimedwait to use __kernel_timespec

Daniel Lezcano (2):
  clocksource/drivers: Unify the names to timer-* format
  clocksource: Remove obsolete CLOCKSOURCE_OF_DECLARE

Dinh Nguyen (1):
  clocksource/drivers/dw_apb: Add reset control

Guenter Roeck (1):
  RISC-V: Request newstat syscalls

Kuninori Morimoto (4):
  clocksource/drivers/renesas-ostm: Convert to SPDX identifiers
  clocksource/drivers/sh_cmt: Convert to SPDX identifiers
  clocksource/drivers/sh_mtu2: Convert to SPDX identifiers
  clocksource/drivers/sh_tmu: Convert to SPDX identifiers

Peng Hao (2):
  tick/broadcast: Remove redundant check
  tick/sched : Remove redundant cpu_online() check

Rob Herring (1):
  clocksource: Convert to using %pOFn instead of device_node.name

Sergei Shtylyov (5):
  clocksource/drivers/sh_cmt: Fixup for 64-bit machines
  clocksource/drivers/sh_cmt: Fix clocksource width for 32-bit machines
  clocksource/drivers/sh_cmt: Properly line-wrap sh_cmt_of_table[] 
initializer
  dt-bindings: timer: renesas: cmt: document R-Car gen3 support
  clocksource/drivers/sh_cmt: Add R-Car gen3 support

kbuild test robot (1):
  y2038: __get_old_timespec32() can be static


 .../devicetree/bindings/timer/renesas,cmt.txt  |   7 ++
 MAINTAINERS|  10 +-
 arch/alpha/include/asm/unistd.h|   2 +
 arch/arc/include/uapi/asm/unistd.h |   1 +
 arch/arm/include/asm/unistd.h  |   4 +-
 arch/arm64/include/asm/compat.h|  26 +
 arch/arm64/include/asm/stat.h  |   2 +-
 arch/arm64/include/asm/unistd.h|   2 +-
 arch/arm64/include/uapi/asm/unistd.h   |   1 +
 arch/c6x/include/uapi/asm/unistd.h |   1 +
 arch/h8300/include/uapi/asm/unistd.h   |   1 +
 arch/hexagon/include/uapi/asm/unistd.h |   1 +
 arch/ia64/include/asm/unistd.h |   3 +
 arch/m68k/include/asm/unistd.h |   2 +-
 arch/microblaze/include/asm/unistd.h   |   2 +-
 arch/mips/include/asm/compat.h |  28 +-
 arch/mips/include/asm/unistd.h |   3 +-
 arch/mips/kernel/binfmt_elfn32.c   |  14 +--
 arch/mips/kernel/binfmt_elfo32.c   |  14 +--
 arch/nds32/include/uapi/asm/unistd.h   |   1 +
 arch/nios2/include/uapi/asm/unistd.h   |   1 +
 arch/openrisc/include/uapi/asm/unistd.h|   1 +
 arch/parisc/include/asm/compat.h   |  24 +
 arch/parisc/include/asm/unistd.h   |   3 +-
 arch/powerpc/include/asm/compat.h  |  24 +
 arch/powerpc/include/asm/unistd.h  |   3 +-
 arch/powerpc/kernel/asm-offsets.c  |   8 +-
 arch/powerpc/oprofile/backtrace.c  |   2 +-
 arch/riscv/include/asm/unistd.h|   1 +
 arch/s390/include/asm/compat.h |  18 +---
 arch/s390/include/asm/unistd.h |   3 +-
 arch/sh/include/asm/unistd.h   |   2 +-
 arch/sparc/include/asm/compat.h|  25 +
 arch/sparc/include/asm/unistd.h|   3 +-
 arch/unicore32/include/uapi/asm/unistd.h   |   1 +
 arch/x86/include/asm/compat.h  |  19 +---
 arch/x86/include/asm/unistd.h  |   3 +-
 arch/xtensa/include/asm/unistd.h   |   2 +-
 drivers/clocksource/Makefile   |  26 ++---
 drivers/clocksource/asm9260_timer.c

Re: [PATCH v3 2/9] dt-bindings: ti-lmu: Remove LM3697

2018-10-24 Thread Pavel Machek
On Fri 2018-10-19 07:58:12, Tony Lindgren wrote:
> * Dan Murphy  [181019 11:42]:
> > On 10/18/2018 05:10 PM, Pavel Machek wrote:
> > > 
> > > Now... this is what I've suggested before. If you don't agree, you may
> > > want to contact Tony Lindgren, IIRC he works for TI, too, and might be
> > > willing to help.
> >
> > I will ping Tony just to close the loop.  I will be posting v4 today after 
> > making the changes.
> > I was hoping to have some code review prior to posting v4 but have not 
> > received any comments so
> > v4 will just be a patch rearrangement.
> 
> I guess not much to ping here though as I know little about these
> chips :) As long as Rob is happy with the binding changes I'll be
> happy too.

Well, question is more "how to make Rob happy". I see v4 is out, let
me comment on that.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v2] sched/core: Don't mix isolcpus and housekeeping CPUs

2018-10-24 Thread Mel Gorman
On Wed, Oct 24, 2018 at 08:32:49AM +0530, Srikar Dronamraju wrote:
> Load balancer and NUMA balancer are not suppose to work on isolcpus.
> 
> Currently when setting sched affinity, there are no checks to see if the
> requested cpumask has CPUs from both isolcpus and housekeeping CPUs.
> 
> If user passes a mix of isolcpus and housekeeping CPUs, then
> NUMA balancer can pick a isolcpu to schedule.
> With this change, if a combination of isolcpus and housekeeping CPUs are
> provided, then we restrict ourselves to housekeeping CPUs.
> 
> For example: System with 32 CPUs
> $ grep -o "isolcpus=[,,1-9]*" /proc/cmdline
> isolcpus=1,5,9,13
> $ grep -i cpus_allowed /proc/$$/status
> Cpus_allowed:   
> Cpus_allowed_list:  0,2-4,6-8,10-12,14-31
> 
> Running "perf bench numa mem --no-data_rand_walk -p 4 -t 8 -G 0 -P 3072
> -T 0 -l 50 -c -s 1000" which  calls sched_setaffinity to all CPUs in
> system.
> 

Forgive my naivety, but is it wrong for a process to bind to both isolated
CPUs and housekeeping CPUs? It would certainly be a bit odd because the
application is asking for some protection but no guarantees are given
and the application is not made aware via an error code that there is a
problem. Asking the application to parse dmesg hoping to find the right
error message is going to be fragile.

Would it be more appropriate to fail sched_setaffinity when there is a
mix of isolated and housekeeping CPUs? In that case, an info message in
dmesg may be appropriate as it'll likely be a once-off configuration
error that's obvious due to an application failure. Alternatively,
should NUMA balancing ignore isolated CPUs? The latter seems unusual as
the application has specified a mask that allows those CPUs and it's not
clear why NUMA balancing should ignore them. If anything, an application
that wants to avoid all interference should also be using memory policies
to bind to nodes so it behaves predictably with respect to access latencies
(presumably if an application cannot tolerate kernel threads interfering
then it also cannot tolerate remote access latencies) or disabling NUMA
balancing entirely to avoid incurring minor faults.

Thanks.

-- 
Mel Gorman
SUSE Labs


Re: [PATCH v5 2/3] clk: meson: add DT documentation for emmc clock controller

2018-10-24 Thread Jerome Brunet
On Thu, 2018-10-18 at 13:07 +0800, Jianxin Pan wrote:
> From: Yixun Lan 
> 
> Document the MMC sub clock controller driver, the potential consumer
> of this driver is MMC or NAND. Also add four clock bindings IDs which
> provided by this driver.
> 
> Reviewed-by: Rob Herring 
> Signed-off-by: Yixun Lan 
> Signed-off-by: Jianxin Pan 
> ---
>  .../devicetree/bindings/clock/amlogic,mmc-clkc.txt | 31 
> ++
>  include/dt-bindings/clock/amlogic,mmc-clkc.h   | 17 
>  2 files changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
>  create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt 
> b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
> new file mode 100644
> index 000..9e6d343
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
> @@ -0,0 +1,31 @@
> +* Amlogic MMC Sub Clock Controller Driver
> +
> +The Amlogic MMC clock controller generates and supplies clock to support
> +MMC and NAND controller
> +
> +Required Properties:
> +
> +- compatible: should be:
> + "amlogic,gx-mmc-clkc"
> + "amlogic,axg-mmc-clkc"
> +
> +- #clock-cells: should be 1.
> +- clocks: phandles to clocks corresponding to the clock-names property
> +- clock-names: list of parent clock names
> + - "clkin0", "clkin1"
> +
> +Parent node should have the following properties :
> +- compatible: "amlogic,axg-mmc-clkc", "syscon".
> +- reg: base address and size of the MMC control register space.

I get why Stephen is confused by your description, I am too. The example
contradict the documentation.

The  documentation above says that the parent node should be a syscon with the
mmc register space.

But your example shows this in the node itself.

> +
> +Example: Clock controller node:
> +
> +sd_mmc_c_clkc: clock-controller@7000 {
> + compatible = "amlogic,axg-mmc-clkc", "syscon";
> + reg = <0x0 0x7000 0x0 0x4>;
> + #clock-cells = <1>;
> +
> + clock-names = "clkin0", "clkin1";
> + clocks = <&clkc CLKID_SD_MMC_C_CLK0>,
> +  <&clkc CLKID_FCLK_DIV2>;
> +};
> diff --git a/include/dt-bindings/clock/amlogic,mmc-clkc.h 
> b/include/dt-bindings/clock/amlogic,mmc-clkc.h
> new file mode 100644
> index 000..162b949
> --- /dev/null
> +++ b/include/dt-bindings/clock/amlogic,mmc-clkc.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
> +/*
> + * Meson MMC sub clock tree IDs
> + *
> + * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
> + * Author: Yixun Lan 
> + */
> +
> +#ifndef __MMC_CLKC_H
> +#define __MMC_CLKC_H
> +
> +#define CLKID_MMC_DIV1
> +#define CLKID_MMC_PHASE_CORE 2
> +#define CLKID_MMC_PHASE_TX   3
> +#define CLKID_MMC_PHASE_RX   4
> +
> +#endif




Re: [PATCH v3 0/7] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64

2018-10-24 Thread Russell King - ARM Linux
On Wed, Oct 24, 2018 at 07:35:46AM +, Corentin Labbe wrote:
> This patchset adds a new set of functions which are open-coded in lot of
> place.
> Basicly the pattern is always the same, "read, modify a bit, write"
> some driver and the powerpc arch already have thoses pattern them as 
> functions. (like ahci_sunxi.c or dwmac-meson8b)

The advantage of them being open-coded is that it's _obvious_ to the
reviewer that there is a read-modify-write going on which, in a multi-
threaded environment, may need some locking (so it should trigger a
review of the locking around that code.)

With it hidden inside a helper which has no locking itself, it becomes
much easier to pass over in review, which means that races are much
more likely to go unspotted - and that is bad news.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up


Re: [PATCH v5 1/3] clk: meson: add emmc sub clock phase delay driver

2018-10-24 Thread Jerome Brunet
On Thu, 2018-10-18 at 13:07 +0800, Jianxin Pan wrote:
> From: Yixun Lan 
> 
> Export the emmc sub clock phase delay ops which will be used
> by the emmc sub clock driver itself.
> 
> Signed-off-by: Yixun Lan 
> Signed-off-by: Jianxin Pan 
> ---
>  drivers/clk/meson/Makefile  |  2 +-
>  drivers/clk/meson/clk-phase-delay.c | 79 
> +
>  drivers/clk/meson/clkc.h| 13 ++
>  3 files changed, 93 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/meson/clk-phase-delay.c
> 
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index 72ec8c4..39ce566 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for Meson specific clk
>  #
>  
> -obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o
> +obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o 
> clk-phase-delay.o
>  obj-$(CONFIG_COMMON_CLK_AMLOGIC_AUDIO)   += clk-triphase.o sclk-div.o
>  obj-$(CONFIG_COMMON_CLK_MESON_AO) += meson-aoclk.o
>  obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
> diff --git a/drivers/clk/meson/clk-phase-delay.c 
> b/drivers/clk/meson/clk-phase-delay.c
> new file mode 100644
> index 000..b9573a7
> --- /dev/null
> +++ b/drivers/clk/meson/clk-phase-delay.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Amlogic Meson MMC Sub Clock Controller Driver
> + *
> + * Copyright (c) 2017 Baylibre SAS.
> + * Author: Jerome Brunet 
> + *
> + * Copyright (c) 2018 Amlogic, inc.
> + * Author: Yixun Lan 
> + */
> +
> +#include 
> +#include "clkc.h"
> +
> +static int meson_clk_phase_delay_get_phase(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_clk_phase_delay_data *ph =
> + meson_clk_get_phase_delay_data(clk);
> + unsigned long period_ps, p, d;
> + int degrees;
> + u32 val;
> +
> + regmap_read(clk->map, ph->phase.reg_off, &val);
> + p = PARM_GET(ph->phase.width, ph->phase.shift, val);

there is an helper for this: meson_parm_read()

> + degrees = p * 360 / (1 << (ph->phase.width));
> +
> + period_ps = DIV_ROUND_UP((unsigned long)NSEC_PER_SEC * 1000,
> +  clk_hw_get_rate(hw));
> +
> + d = PARM_GET(ph->delay.width, ph->delay.shift, val);
> + degrees += d * ph->delay_step_ps * 360 / period_ps;
> + degrees %= 360;
> +
> + return degrees;
> +}
> +
> +static void meson_clk_apply_phase_delay(struct clk_regmap *clk,
> + unsigned int phase,
> + unsigned int delay)

This helper function is a bit overkill.
simply call meson_parm_write() twice in meson_clk_phase_delay_set_phase().

> +{
> + struct meson_clk_phase_delay_data *ph = clk->data;
> + u32 val;
> +
> + regmap_read(clk->map, ph->delay.reg_off, &val);
> + val = PARM_SET(ph->phase.width, ph->phase.shift, val, phase);
> + val = PARM_SET(ph->delay.width, ph->delay.shift, val, delay);
> + regmap_write(clk->map, ph->delay.reg_off, val);
> +}
> +
> +static int meson_clk_phase_delay_set_phase(struct clk_hw *hw, int degrees)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_clk_phase_delay_data *ph =
> + meson_clk_get_phase_delay_data(clk);
> + unsigned long period_ps, d = 0, r;
> + u64 p;
> +
> + p = degrees % 360;
> + period_ps = DIV_ROUND_UP((unsigned long)NSEC_PER_SEC * 1000,
> +  clk_hw_get_rate(hw));
> +
> + /* First compute the phase index (p), the remainder (r) is the
> +  * part we'll try to acheive using the delays (d).
> +  */
> + r = do_div(p, 360 / (1 << (ph->phase.width)));
> + d = DIV_ROUND_CLOSEST(r * period_ps,
> +   360 * ph->delay_step_ps);
> + d = min(d, PMASK(ph->delay.width));
> +
> + meson_clk_apply_phase_delay(clk, p, d);
> + return 0;
> +}
> +
> +const struct clk_ops meson_clk_phase_delay_ops = {
> + .get_phase = meson_clk_phase_delay_get_phase,
> + .set_phase = meson_clk_phase_delay_set_phase,
> +};
> +EXPORT_SYMBOL_GPL(meson_clk_phase_delay_ops);
> diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
> index 6b96d55..3309d78 100644
> --- a/drivers/clk/meson/clkc.h
> +++ b/drivers/clk/meson/clkc.h
> @@ -105,6 +105,18 @@ struct clk_regmap _name = {  
> \
>   },  \
>  };
>  
> +struct meson_clk_phase_delay_data {
> + struct parm phase;
> + struct parm delay;
> + unsigned intdelay_step_ps;
> +};
> +
> +static inline struct meson_clk_phase_delay_data *
> +meson_clk_get_phase_delay_data(struct clk_regmap *clk)
> +{
> + return (struct meson_clk_phase_delay_data *)clk->data;
> +}
> +
>  /* clk_ops */
>  extern const struct cl

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

2018-10-24 Thread Jarkko Sakkinen

On Tue, 23 Oct 2018, Winkler, Tomas wrote:

To  the  out  label we jump after we are  done with locality and cmd
read() before we jump to locality 'locality'.  We will need to add
another variable to check If cmd_ready() was called or not in order to
get rid of the extran label, it's not internally tracked so far.


I think this is fine.

Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 

I tested this by assigning rc error code instead of requesting locality
in addition of testig unchanged code.

/Jarkko


RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

2018-10-24 Thread Winkler, Tomas
> 
> On Tue, 23 Oct 2018, Winkler, Tomas wrote:
> > To  the  out  label we jump after we are  done with locality and cmd
> > read() before we jump to locality 'locality'.  We will need to add
> > another variable to check If cmd_ready() was called or not in order to
> > get rid of the extran label, it's not internally tracked so far.
> 
> I think this is fine.
> 
> Reviewed-by: Jarkko Sakkinen 
> Tested-by: Jarkko Sakkinen 
> 
> I tested this by assigning rc error code instead of requesting locality in
> addition of testig unchanged code.
> 
Great
Thanks
Tomas 


Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver

2018-10-24 Thread Jerome Brunet
On Fri, 2018-10-19 at 11:03 -0700, Stephen Boyd wrote:
> Quoting Jianxin Pan (2018-10-19 09:12:53)
> > On 2018/10/19 1:13, Stephen Boyd wrote:
> > > Quoting Jianxin Pan (2018-10-17 22:07:25)
> > > > diff --git a/drivers/clk/meson/clk-regmap.c 
> > > > b/drivers/clk/meson/clk-regmap.c
> > > > index 305ee30..f96314d 100644
> > > > --- a/drivers/clk/meson/clk-regmap.c
> > > > +++ b/drivers/clk/meson/clk-regmap.c
> > > > @@ -113,8 +113,25 @@ static int clk_regmap_div_set_rate(struct clk_hw 
> > > > *hw, unsigned long rate,
> > > >   clk_div_mask(div->width) << 
> > > > div->shift, val);
> > > >  };
> > > >  
> > > > -/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
> > > > +static void clk_regmap_div_init(struct clk_hw *hw)
> > > > +{
> > > > +   struct clk_regmap *clk = to_clk_regmap(hw);
> > > > +   struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
> > > > +   unsigned int val;
> > > > +   int ret;
> > > > +
> > > > +   ret = regmap_read(clk->map, div->offset, &val);
> > > > +   if (ret)
> > > > +   return;
> > > >  
> > > > +   val &= (clk_div_mask(div->width) << div->shift);
> > > > +   if (!val)
> > > > +   regmap_update_bits(clk->map, div->offset,
> > > > +  clk_div_mask(div->width) << 
> > > > div->shift,
> > > > +  clk_div_mask(div->width));
> > > > +}
> > > > +
> > > > +/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
> > > 
> > > We should add a patch to rename the symbol for qcom, i.e.
> > > qcom_clk_regmap_div_ro_ops, and then any symbols in this directory
> > > should be meson_clk_regmap_div_ro_ops.
> > 
> > "/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */"
> > This comment is not introduced in this patch.
> > I followed the naming style in this file and add 
> > clk_regmap_divider_with_init_ops.
> > 
> > @Jerome, What's your suggestion about this?
> 
> Yes you don't need to fix anything in this series. Just saying that in
> the future we should work on cleaning this up.


Well, first, I wonder why such a change ends up in a patch that is supposed to
add a controller.

If such a change was really required to implement a generic div (which I doubt)
it would need to be in separate with clear explanation.

Stephen,
I agree at some point we should squash the different regmap implementations and
provide generic (enough) implementation. There is not only qcom and meson, some
other controllers are redefining regmap ops and I bet driver outside of
drivers/clk/* could use a generic implementation as well.





[GIT pull] irq updates for 4.20

2018-10-24 Thread Thomas Gleixner
Linus,

please pull the latest irq-core-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus

The interrupt brigade came up with the following updates:

  - Driver for the Marvell System Error Interrupt machinery

  - Overhaul of the GIC-V3 ITS driver

  - Small updates and fixes all over the place

The EFI parts of it are required to support GIC-V3 ITS working accross
kexec.

Thanks,

tglx

-->
Ard Biesheuvel (3):
  efi: honour memory reservations passed via a linux specific config table
  efi/arm: libstub: add a root memreserve config table
  efi: add API to reserve memory persistently across kexec reboot

Biju Das (1):
  dt-bindings: irqchip: renesas-irqc: Document r8a7744 support

Geert Uytterhoeven (2):
  dt-bindings: irqchip: renesas-irqc: Document R-Car E3 support
  genirq: Fix grammar s/an /a /

Julien Thierry (2):
  irqchip/gic-v3: Remove acknowledge loop
  irqchip/gic: Unify GIC priority definitions

Lina Iyer (1):
  irqchip/pdc: Setup all edge interrupts as rising edge at GIC

Lukas Wunner (1):
  genirq: Fix race on spurious interrupt detection

Marc Zyngier (13):
  genirq/debugfs: Reset domain debugfs_file on removal of the debugfs file
  genirq/debugfs: Reinstate full OF path for domain name
  irqchip/gic-v3-its: Change initialization ordering for LPIs
  irqchip/gic-v3-its: Simplify LPI_PENDBASE_SZ usage
  irqchip/gic-v3-its: Split property table clearing from allocation
  irqchip/gic-v3-its: Move pending table allocation to init time
  irqchip/gic-v3-its: Keep track of property table's PA and VA
  irqchip/gic-v3-its: Allow use of pre-programmed LPI tables
  irqchip/gic-v3-its: Use pre-programmed redistributor tables with kdump 
kernels
  irqchip/gic-v3-its: Check that all RDs have the same property table
  irqchip/gic-v3-its: Register LPI tables with EFI config table
  irqchip/gic-v3-its: Allow use of LPI tables in reserved memory
  genirq/msi: Allow creation of a tree-based irqdomain for platform-msi

Miquel Raynal (10):
  dt-bindings/interrupt-controller: Fix Marvell ICU length in the example
  irqchip/irq-mvebu-icu: Fix wrong private data retrieval
  irqchip/irq-mvebu-icu: Clarify the reset operation of configured 
interrupts
  irqchip/irq-mvebu-icu: Disociate ICU and NSR
  irqchip/irq-mvebu-icu: Support ICU subnodes
  irqchip/irq-mvebu-sei: Add new driver for Marvell SEI
  arm64: marvell: Enable SEI driver
  irqchip/irq-mvebu-icu: Add support for System Error Interrupts (SEI)
  dt-bindings/interrupt-controller: Update Marvell ICU bindings
  dt-bindings/interrupt-controller: Add documentation for Marvell SEI 
controller

Yangtao Li (1):
  softirq: Fix typo in __do_softirq() comments


 .../bindings/interrupt-controller/marvell,icu.txt  |  85 +++-
 .../bindings/interrupt-controller/marvell,sei.txt  |  36 ++
 .../bindings/interrupt-controller/renesas,irqc.txt |   5 +-
 arch/arm64/Kconfig.platforms   |   1 +
 drivers/base/platform-msi.c|  14 +-
 drivers/firmware/efi/efi.c |  59 ++-
 drivers/firmware/efi/libstub/arm-stub.c|  27 ++
 drivers/irqchip/Kconfig|   3 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-gic-v3-its.c   | 249 +++---
 drivers/irqchip/irq-gic-v3.c   |  85 ++--
 drivers/irqchip/irq-mvebu-icu.c| 253 +++---
 drivers/irqchip/irq-mvebu-sei.c| 507 +
 drivers/irqchip/qcom-pdc.c |   1 +
 include/linux/efi.h|   9 +
 include/linux/interrupt.h  |   2 +-
 include/linux/irqchip/arm-gic-common.h |   6 +
 include/linux/irqchip/arm-gic-v3.h |   4 +-
 include/linux/irqchip/arm-gic.h|   5 -
 include/linux/irqdomain.h  |   1 +
 include/linux/msi.h|  17 +-
 kernel/irq/irqdomain.c |   5 +-
 kernel/irq/manage.c|   8 +-
 kernel/softirq.c   |   6 +-
 24 files changed, 1187 insertions(+), 202 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
 create mode 100644 drivers/irqchip/irq-mvebu-sei.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt 
b/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
index aa8bf2ec8905..1c94a57a661e 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
@@ -5,6 +5,8 @@ The Marvell ICU (Interrupt Consolidation Unit) controller is
 responsib

Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver

2018-10-24 Thread Jerome Brunet
On Thu, 2018-10-18 at 13:07 +0800, Jianxin Pan wrote:
> From: Yixun Lan 
> 
> The patch will add a MMC clock controller driver which used by MMC or NAND,
> It provide a mux and divider clock, and three phase clocks - core, tx, tx.
> 
> Two clocks are provided as the parent of MMC clock controller from
> upper layer clock controller - eg "amlogic,axg-clkc" in AXG platform.
> 
> To specify which clock the MMC or NAND driver may consume,
> the preprocessor macros in the dt-bindings/clock/amlogic,mmc-clkc.h header
> can be used in the device tree sources.
> 
> Signed-off-by: Yixun Lan 
> Signed-off-by: Jianxin Pan 
> ---
>  drivers/clk/meson/Kconfig  |  10 ++
>  drivers/clk/meson/Makefile |   1 +
>  drivers/clk/meson/clk-regmap.c |  27 +++-
>  drivers/clk/meson/clk-regmap.h |   1 +
>  drivers/clk/meson/mmc-clkc.c   | 296 
> +
>  5 files changed, 334 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/meson/mmc-clkc.c
> 
> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
> index efaa70f..8b8ccbc 100644
> --- a/drivers/clk/meson/Kconfig
> +++ b/drivers/clk/meson/Kconfig
> @@ -15,6 +15,16 @@ config COMMON_CLK_MESON_AO
>   select COMMON_CLK_REGMAP_MESON
>   select RESET_CONTROLLER
>  
> +config COMMON_CLK_MMC_MESON
> + tristate "Meson MMC Sub Clock Controller Driver"
> + depends on COMMON_CLK_AMLOGIC

COMMON_CLK_AMLOGIC is not something that is manually enabled
You should select it, not depends on it. Have a look at how it is done for the
other controller (like in v4.19)

> + select MFD_SYSCON
> + select REGMAP

this is already selected by COMMON_CLK_AMLOGIC, please drop this.

> + help
> +   Support for the MMC sub clock controller on Amlogic Meson Platform,
> +   which include S905 (GXBB, GXL), A113D/X (AXG) devices.
> +   Say Y if you want this clock enabled.
> +
>  config COMMON_CLK_REGMAP_MESON
>   bool
>   select REGMAP
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index 39ce566..31c16d5 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -9,4 +9,5 @@ obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
>  obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o gxbb-aoclk-32k.o
>  obj-$(CONFIG_COMMON_CLK_AXG)  += axg.o axg-aoclk.o
>  obj-$(CONFIG_COMMON_CLK_AXG_AUDIO)   += axg-audio.o
> +obj-$(CONFIG_COMMON_CLK_MMC_MESON)   += mmc-clkc.o
>  obj-$(CONFIG_COMMON_CLK_REGMAP_MESON)+= clk-regmap.o
> diff --git a/drivers/clk/meson/clk-regmap.c b/drivers/clk/meson/clk-regmap.c
> index 305ee30..f96314d 100644
> --- a/drivers/clk/meson/clk-regmap.c
> +++ b/drivers/clk/meson/clk-regmap.c
> @@ -113,8 +113,25 @@ static int clk_regmap_div_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> clk_div_mask(div->width) << div->shift, val);
>  };
>  
> -/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
> +static void clk_regmap_div_init(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(clk->map, div->offset, &val);
> + if (ret)
> + return;
>  
> + val &= (clk_div_mask(div->width) << div->shift);
> + if (!val)
> + regmap_update_bits(clk->map, div->offset,
> +clk_div_mask(div->width) << div->shift,
> +clk_div_mask(div->width));

This is wrong for several reasons:
* You should hard code the initial value in the driver.
* If shift is not 0, I doubt this will give the expected result.

> +}

Please drop this. 

> +
> +/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
>  const struct clk_ops clk_regmap_divider_ops = {
>   .recalc_rate = clk_regmap_div_recalc_rate,
>   .round_rate = clk_regmap_div_round_rate,
> @@ -122,6 +139,14 @@ static int clk_regmap_div_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>  };
>  EXPORT_SYMBOL_GPL(clk_regmap_divider_ops);
>  
> +const struct clk_ops clk_regmap_divider_with_init_ops = {
> + .recalc_rate = clk_regmap_div_recalc_rate,
> + .round_rate = clk_regmap_div_round_rate,
> + .set_rate = clk_regmap_div_set_rate,
> + .init = clk_regmap_div_init,
> +};
> +EXPORT_SYMBOL_GPL(clk_regmap_divider_with_init_ops);

... and this.

> +
>  const struct clk_ops clk_regmap_divider_ro_ops = {
>   .recalc_rate = clk_regmap_div_recalc_rate,
>   .round_rate = clk_regmap_div_round_rate,
> diff --git a/drivers/clk/meson/clk-regmap.h b/drivers/clk/meson/clk-regmap.h
> index ed2d434..0ab7d37 100644
> --- a/drivers/clk/meson/clk-regmap.h
> +++ b/drivers/clk/meson/clk-regmap.h
> @@ -109,5 +109,6 @@ struct clk_regmap_mux_data {
>  
>  extern const struct clk_ops clk_regmap_mux_ops;
>  extern const struct clk_ops clk_regmap_mux_ro_ops;
> +extern const struct clk_ops clk_regmap_di

[PATCH V2 3/4] misc/pvpanic: add support to pvpanic device information by using FDT

2018-10-24 Thread Peng Hao
By default, when ACPI tables and FDT coexist for ARM64,
current kernel takes precedence over FDT to get device information.
This patch increases the way to get information through FDT.

Signed-off-by: Peng Hao 
---
 drivers/misc/pvpanic.c | 69 +-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index bcfefdd..e4b2b40 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -2,6 +2,7 @@
  *  pvpanic.c - pvpanic Device Support
  *
  *  Copyright (C) 2013 Fujitsu.
+ *  Copyright (C) 2018 ZTE.
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -25,6 +26,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 MODULE_AUTHOR("Hu Tao ");
 MODULE_DESCRIPTION("pvpanic device driver");
@@ -78,6 +83,37 @@
.priority = 1, /* let this called before broken drm_fb_helper */
 };
 
+static int pvpanic_mmio_probe(struct platform_device *pdev)
+{
+   struct resource *mem;
+
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!mem)
+   return -EINVAL;
+
+   if (!devm_request_mem_region(&pdev->dev, mem->start,
+resource_size(mem), pdev->name))
+   return -EBUSY;
+
+   base = devm_ioremap(&pdev->dev, mem->start,
+   resource_size(mem));
+   if (base == NULL)
+   return -EFAULT;
+
+   atomic_notifier_chain_register(&panic_notifier_list,
+  &pvpanic_panic_nb);
+
+   return 0;
+}
+
+static int pvpanic_mmio_remove(struct platform_device *pdev)
+{
+
+   atomic_notifier_chain_unregister(&panic_notifier_list,
+&pvpanic_panic_nb);
+
+   return 0;
+}
 
 static acpi_status
 pvpanic_walk_resources(struct acpi_resource *res, void *context)
@@ -135,4 +171,35 @@ static int pvpanic_remove(struct acpi_device *device)
return 0;
 }
 
-module_acpi_driver(pvpanic_driver);
+static const struct of_device_id pvpanic_mmio_match[] = {
+   { .compatible = "qemu,pvpanic-mmio", },
+   {},
+};
+
+static struct platform_driver pvpanic_mmio_driver = {
+   .driver = {
+   .name = "pvpanic-mmio",
+   .of_match_table = pvpanic_mmio_match,
+   },
+   .probe = pvpanic_mmio_probe,
+   .remove = pvpanic_mmio_remove,
+};
+
+static int __init pvpanic_mmio_init(void)
+{
+   if (acpi_disabled)
+   return platform_driver_register(&pvpanic_mmio_driver);
+   else
+   return acpi_bus_register_driver(&pvpanic_driver);
+}
+
+static void __exit pvpanic_mmio_exit(void)
+{
+   if (acpi_disabled)
+   platform_driver_unregister(&pvpanic_mmio_driver);
+   else
+   acpi_bus_unregister_driver(&pvpanic_driver);
+}
+
+module_init(pvpanic_mmio_init);
+module_exit(pvpanic_mmio_exit);
-- 
1.8.3.1



[PATCH V2 4/4] misc/pvpanic : pvpanic: add document for pvpanic-mmio DT

2018-10-24 Thread Peng Hao
Signed-off-by: Peng Hao 
---
 .../devicetree/bindings/arm/pvpanic-mmio.txt   | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/pvpanic-mmio.txt

diff --git a/Documentation/devicetree/bindings/arm/pvpanic-mmio.txt 
b/Documentation/devicetree/bindings/arm/pvpanic-mmio.txt
new file mode 100644
index 000..a6bdacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/pvpanic-mmio.txt
@@ -0,0 +1,29 @@
+* QEMU PVPANIC MMIO Configuration bindings for ARM
+
+QEMU's emulation / virtualization targets provide the following PVPANIC
+MMIO Configuration interface on the "virt" machine.
+type:
+
+- a read-write, 16-bit wide data register.
+
+QEMU exposes the data register to guests as memory mapped registers.
+
+Required properties:
+
+- compatible: "qemu,pvpanic-mmio".
+- reg: the MMIO region used by the device.
+  * Bytes 0x0  Write panic event to the reg when guest OS panics.
+  * Bytes 0x1  Reserved.
+
+Example:
+
+/ {
+#size-cells = <0x2>;
+#address-cells = <0x2>;
+
+pvpanic-mmio@906 {
+compatible = "qemu,pvpanic-mmio";
+reg = <0x0 0x906 0x0 0x2>;
+};
+};
+
-- 
1.8.3.1



[PATCH V2 2/4] misc/pvpanic: add MMIO support

2018-10-24 Thread Peng Hao
On some architectures (e.g. arm64), it's preferable to use MMIO, since
this can be used standalone. Add MMIO support to the pvpanic driver.

Signed-off-by: Peng Hao 
---
 drivers/misc/pvpanic.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index fd86dab..bcfefdd 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -43,6 +43,8 @@
 
 static u16 port;
 
+static void __iomem *base;
+
 static struct acpi_driver pvpanic_driver = {
.name = "pvpanic",
.class ="QEMU",
@@ -57,7 +59,10 @@
 static void
 pvpanic_send_event(unsigned int event)
 {
-   outb(event, port);
+   if (port)
+   outb(event, port);
+   else if (base)
+   writeb(event, base);
 }
 
 static int
@@ -77,6 +82,8 @@
 static acpi_status
 pvpanic_walk_resources(struct acpi_resource *res, void *context)
 {
+   struct acpi_resource_fixed_memory32 *fixmem32;
+
switch (res->type) {
case ACPI_RESOURCE_TYPE_END_TAG:
return AE_OK;
@@ -85,6 +92,11 @@
port = res->data.io.minimum;
return AE_OK;
 
+   case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+   fixmem32 = &res->data.fixed_memory32;
+   base = ioremap(fixmem32->address, fixmem32->address_length);
+   return AE_OK;
+
default:
return AE_ERROR;
}
@@ -104,7 +116,7 @@ static int pvpanic_add(struct acpi_device *device)
acpi_walk_resources(device->handle, METHOD_NAME__CRS,
pvpanic_walk_resources, NULL);
 
-   if (!port)
+   if (!port && !base)
return -ENODEV;
 
atomic_notifier_chain_register(&panic_notifier_list,
@@ -118,6 +130,8 @@ static int pvpanic_remove(struct acpi_device *device)
 
atomic_notifier_chain_unregister(&panic_notifier_list,
 &pvpanic_panic_nb);
+   if (base)
+   iounmap(base);
return 0;
 }
 
-- 
1.8.3.1



[PATCH V2 1/4] misc/pvpanic: move pvpanic to misc as common driver

2018-10-24 Thread Peng Hao
move pvpanic.c from drivers/platform/x86 to drivers/misc.
following patches will use pvpanic device in arm64.

Signed-off-by: Peng Hao 
---
 drivers/misc/Kconfig   |   7 +++
 drivers/misc/Makefile  |   1 +
 drivers/misc/pvpanic.c | 124 +
 drivers/platform/Kconfig   |   3 +
 drivers/platform/Makefile  |   1 +
 drivers/platform/x86/Kconfig   |   8 ---
 drivers/platform/x86/Makefile  |   1 -
 drivers/platform/x86/pvpanic.c | 124 -
 8 files changed, 136 insertions(+), 133 deletions(-)
 create mode 100644 drivers/misc/pvpanic.c
 delete mode 100644 drivers/platform/x86/pvpanic.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 5d71300..ca55c94 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -499,6 +499,13 @@ config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
 
+config PVPANIC
+   tristate "pvpanic device support"
+   help
+  This driver provides support for the pvpanic device.  pvpanic is
+  a paravirtualized device provided by QEMU; it lets a virtual machine
+  (guest) communicate panic events to the host.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 20be70c..39dc005 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_ASPEED_LPC_SNOOP)+= aspeed-lpc-snoop.o
 obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
 obj-$(CONFIG_OCXL) += ocxl/
 obj-$(CONFIG_MISC_RTSX)+= cardreader/
+obj-$(CONFIG_PVPANIC)  += pvpanic.o
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
new file mode 100644
index 000..fd86dab
--- /dev/null
+++ b/drivers/misc/pvpanic.c
@@ -0,0 +1,124 @@
+/*
+ *  pvpanic.c - pvpanic Device Support
+ *
+ *  Copyright (C) 2013 Fujitsu.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This 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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  
USA
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("Hu Tao ");
+MODULE_DESCRIPTION("pvpanic device driver");
+MODULE_LICENSE("GPL");
+
+static int pvpanic_add(struct acpi_device *device);
+static int pvpanic_remove(struct acpi_device *device);
+
+static const struct acpi_device_id pvpanic_device_ids[] = {
+   { "QEMU0001", 0 },
+   { "", 0 },
+};
+MODULE_DEVICE_TABLE(acpi, pvpanic_device_ids);
+
+#define PVPANIC_PANICKED   (1 << 0)
+
+static u16 port;
+
+static struct acpi_driver pvpanic_driver = {
+   .name = "pvpanic",
+   .class ="QEMU",
+   .ids =  pvpanic_device_ids,
+   .ops =  {
+   .add =  pvpanic_add,
+   .remove =   pvpanic_remove,
+   },
+   .owner =THIS_MODULE,
+};
+
+static void
+pvpanic_send_event(unsigned int event)
+{
+   outb(event, port);
+}
+
+static int
+pvpanic_panic_notify(struct notifier_block *nb, unsigned long code,
+void *unused)
+{
+   pvpanic_send_event(PVPANIC_PANICKED);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block pvpanic_panic_nb = {
+   .notifier_call = pvpanic_panic_notify,
+   .priority = 1, /* let this called before broken drm_fb_helper */
+};
+
+
+static acpi_status
+pvpanic_walk_resources(struct acpi_resource *res, void *context)
+{
+   switch (res->type) {
+   case ACPI_RESOURCE_TYPE_END_TAG:
+   return AE_OK;
+
+   case ACPI_RESOURCE_TYPE_IO:
+   port = res->data.io.minimum;
+   return AE_OK;
+
+   default:
+   return AE_ERROR;
+   }
+}
+
+static int pvpanic_add(struct acpi_device *device)
+{
+   int ret;
+
+   ret = acpi_bus_get_status(device);
+   if (ret < 0)
+   return ret;
+
+   if (!device->status.enabled || !device->status.functional)
+   return -ENODEV;
+
+   acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+   pvpanic_walk_resources, NULL);
+
+   if (!port)
+   return -ENODEV;
+
+   atomic_notifier_chain_r

Re: [PATCH v4 2/7] dt-bindings: ti-lmu: Modify dt bindings for the LM3697

2018-10-24 Thread Pavel Machek
Hi!

> The LM3697 is a single function LED driver. The single function LED
> driver needs to reside in the LED directory as a dedicated LED driver
> and not as a MFD device.  The device does have common brightness and ramp

So it is single function LED driver. That does not mean it can not
share bindings with the rest. Where the bindings live is not imporant.

> reside in the Documentation/devicetree/bindings/leds directory and follow the
> current LED and general bindings guidelines.

What you forgot to tell us in the changelog:

> +Optional child properties:
> + - runtime-ramp-up-msec: Current ramping from one brightness level to
> + the a higher brightness level.
> + Range from 2048 us - 117.44 s

The other binding uses "ramp-up-msec". Tell us why you are changing this, or
better don't change things needlessly.

We don't want to be using "runtime-ramp-up-msec" for one device and
"ramp-up-msec" for the other.

I'm not sure what other changes you did, and changelog does not tell
me.

> --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> @@ -9,7 +9,6 @@ TI LMU driver supports lighting devices below.
>LM3632   Backlight and regulator
>LM3633   Backlight, LED and fault monitor
>LM3695   Backlight
> -  LM3697   Backlight and fault monitor
>  
>  Required properties:
>- compatible: Should be one of:

NAK. You can use existing binding.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v4 2/2] sched/fair: update scale invariance of PELT

2018-10-24 Thread Vincent Guittot
Hi  Pavan,

On Wed, 24 Oct 2018 at 06:53, Pavan Kondeti  wrote:
>
> Hi Vincent,
>
> Thanks for the detailed explanation.
>
> On Tue, Oct 23, 2018 at 02:15:08PM +0200, Vincent Guittot wrote:
> > Hi Pavan,
> >
> > On Tue, 23 Oct 2018 at 07:59, Pavan Kondeti  wrote:
> > >
> > > Hi Vincent,
> > >
> > > On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> > > >
> > > >  /*
> > > > + * The clock_pelt scales the time to reflect the effective amount of
> > > > + * computation done during the running delta time but then sync back to
> > > > + * clock_task when rq is idle.
> > > > + *
> > > > + *
> > > > + * absolute time   | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|16
> > > > + * @ max capacity  --**---**---
> > > > + * @ half capacity ----
> > > > + * clock pelt  | 1| 2|3|4| 7| 8| 9|   10|   11|14|15|16
> > > > + *
> > > > + */
> > > > +void update_rq_clock_pelt(struct rq *rq, s64 delta)
> > > > +{
> > > > +
> > > > + if (is_idle_task(rq->curr)) {
> > > > + u32 divider = (LOAD_AVG_MAX - 1024 + 
> > > > rq->cfs.avg.period_contrib) << SCHED_CAPACITY_SHIFT;
> > > > + u32 overload = rq->cfs.avg.util_sum + LOAD_AVG_MAX;
> > > > + overload += rq->avg_rt.util_sum;
> > > > + overload += rq->avg_dl.util_sum;
> > > > +
> > > > + /*
> > > > +  * Reflecting some stolen time makes sense only if the 
> > > > idle
> > > > +  * phase would be present at max capacity. As soon as the
> > > > +  * utilization of a rq has reached the maximum value, it 
> > > > is
> > > > +  * considered as an always runnnig rq without idle time to
> > > > +  * steal. This potential idle time is considered as lost 
> > > > in
> > > > +  * this case. We keep track of this lost idle time 
> > > > compare to
> > > > +  * rq's clock_task.
> > > > +  */
> > > > + if (overload >= divider)
> > > > + rq->lost_idle_time += rq_clock_task(rq) - 
> > > > rq->clock_pelt;
> > > > +
> > >
> > > I am trying to understand this better. I believe we run into this 
> > > scenario, when
> > > the frequency is limited due to thermal/userspace constraints. Lets say
> >
> > Yes these are the most common UCs but this can also happen after tasks
> > migration or with a cpufreq governor that doesn't increase OPP fast
> > enough for current utilization.
> >
> > > frequency is limited to Fmax/2. A 50% task at Fmax, becomes 100% running 
> > > at
> > > Fmax/2. The utilization is built up to 100% after several periods.
> > > The clock_pelt runs at 1/2 speed of the clock_task. We are loosing the 
> > > idle time
> > > all along. What happens when the CPU enters idle for a short duration and 
> > > comes
> > > back to run this 100% utilization task?
> >
> > If you are at 100%, we only apply the short idle duration
> >
> > >
> > > If the above block is not present i.e lost_idle_time is not tracked, we
> > > stretch the idle time (since clock_pelt is synced to clock_task) and the
> > > utilization is dropped. Right?
> >
> > yes that 's what would happen. I gives more details below
> >
> > >
> > > With the above block, we don't stretch the idle time. In fact we don't
> > > consider the idle time at all. Because,
> > >
> > > idle_time = now - last_time;
> > >
> > > idle_time = (rq->clock_pelt - rq->lost_idle_time) - last_time
> > > idle_time = (rq->clock_task - rq_clock_task + rq->clock_pelt_old) - 
> > > last_time
> > > idle_time = rq->clock_pelt_old - last_time
> > >
> > > The last time is nothing but the last snapshot of the rq->clock_pelt when 
> > > the
> > > task entered sleep due to which CPU entered idle.
> >
> > The condition for dropping this idle time is quite important. This
> > only happens when the utilization reaches max compute capacity of the
> > CPU. Otherwise, the idle time will be fully applied
>
> Right.
>
> rq->lost_idle_time += rq_clock_task(rq) - rq->clock_pelt
>
> This not only tracks the lost idle time due to running slow but also the
> absolute/real sleep time. For example, when the slow running 100% task
> sleeps for 100 msec, are not we ignoring the 100 msec sleep there?
>
> For example a task ran 323 msec at full capacity and sleeps for (1000-323)
> msec. when it wakes up the utilization is dropped. If the same task runs
> for 626 msec at the half capacity and sleeps for (1000-626), should not
> drop the utilization by taking (1000-626) sleep time into account. I
> understand that why we don't strech idle time to (1000-323) but it is not
> clear to me why we completely drop the idle time.

So this should not happen.
I' m going to update the way I track lost idle time  and move it out
of update_rq_clock_pelt() and only do the test when entering idle
This is even better as it simplifies update_rq_clock_pelt() and
reduces the number of tests for lost idle time

Than

Re: KASAN: slab-out-of-bounds Read in string (2)

2018-10-24 Thread Dan Carpenter
Hi Amir,

Thanks so much for this idea.

On Fri, Sep 28, 2018 at 08:39:15PM +0300, Amir Goldstein wrote:
> On Fri, Sep 28, 2018 at 5:55 PM Dmitry Vyukov  wrote:
> >
> > On Fri, Sep 28, 2018 at 4:45 PM, syzbot
> >  wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:c127e59bee3e Merge tag 'for_v4.19-rc6' of 
> > > git://git.kernel..
> > > git tree:   upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=13b2f32a40
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=376cea2b0ef340db3dd4
> > > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+376cea2b0ef340db3...@syzkaller.appspotmail.com
> >
> > I guess this is overlayfs rather than printk. +overlayfs maintainers
> > In future syzbot will avoid attributing crashes to printk, because I
> > think it's not the first time crashes are mis-attributed to printk:
> > https://github.com/google/syzkaller/commit/41e4b32952f4590341ae872db0abf819b4004713
> >
> >
> > > RDX:  RSI:  RDI: 2140
> > > RBP: 0072bf00 R08:  R09: 
> > > R10:  R11: 0246 R12: 7f0e714a76d4
> > > R13: 004c32cb R14: 004d4ef0 R15: 0004
> > > ==
> > > BUG: KASAN: slab-out-of-bounds in string+0x298/0x2d0 lib/vsprintf.c:604
> > > Read of size 1 at addr 8801c36c66ba by task syz-executor2/27811
> > >
> > > CPU: 0 PID: 27811 Comm: syz-executor2 Not tainted 4.19.0-rc5+ #36
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > >  __dump_stack lib/dump_stack.c:77 [inline]
> > >  dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
> > >  print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> > >  kasan_report_error mm/kasan/report.c:354 [inline]
> > >  kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> > >  __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
> > >  string+0x298/0x2d0 lib/vsprintf.c:604
> > >  vsnprintf+0x48e/0x1b60 lib/vsprintf.c:2293
> > >  vscnprintf+0x2d/0x80 lib/vsprintf.c:2396
> > >  vprintk_store+0x43/0x510 kernel/printk/printk.c:1847
> > >  vprintk_emit+0x1c1/0x930 kernel/printk/printk.c:1905
> > >  vprintk_default+0x28/0x30 kernel/printk/printk.c:1963
> > >  vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
> > >  printk+0xa7/0xcf kernel/printk/printk.c:1996
> > >  ovl_lookup_index.cold.15+0xe8/0x1f8 fs/overlayfs/namei.c:689
> 
> Doh!
> I used %*s instead of %.s
> Look how common this mistake is! and I only checked under fs/
> 
> [CC: Dan Carpenter and other fs maintainers]
> Idea for static code analyzers:
> A variable named *len* is probably not what someone wants to describe
> the width of %*s field and in most cases I found were %*s is used correctly
> the string value is a compiler constant (often "").
> 
> Thanks,
> Amir.
> 
> ---
> diff --git a/fs/coda/dir.c b/fs/coda/dir.c
> index 00876ddadb43..23ee5de8b4be 100644
> --- a/fs/coda/dir.c
> +++ b/fs/coda/dir.c
> @@ -47,7 +47,7 @@ static struct dentry *coda_lookup(struct inode *dir,
> struct dentry *entry, unsig
> int type = 0;
> 
> if (length > CODA_MAXNAMLEN) {
> -   pr_err("name too long: lookup, %s (%*s)\n",
> +   pr_err("name too long: lookup, %s (%.*s)\n",

This isn't the right fix because "length" is invalid.

>coda_i2s(dir), (int)length, name);
> return ERR_PTR(-ENAMETOOLONG);
> }
> diff --git a/fs/lockd/host.c b/fs/lockd/host.c
> index d35cd6be0675..93fb7cf0b92b 100644
> --- a/fs/lockd/host.c
> +++ b/fs/lockd/host.c
> @@ -341,7 +341,7 @@ struct nlm_host *nlmsvc_lookup_host(const struct
> svc_rqst *rqstp,
> };
> struct lockd_net *ln = net_generic(net, lockd_net_id);
> 
> -   dprintk("lockd: %s(host='%*s', vers=%u, proto=%s)\n", __func__,
> +   dprintk("lockd: %s(host='%.*s', vers=%u, proto=%s)\n", __func__,
> (int)hostname_len, hostname, rqstp->rq_vers,
> (rqstp->rq_prot == IPPROTO_UDP ? "udp" : "tcp"));
> 

Why wasn't this one applied?  It looks correct to me.  The rest seem to
have been fixed already.

I did find one other bug in wireless and I CC'd you on that.  I'm going
to do a little bit more testing on the check and then push it soon.
Thanks again!

regards,
dan carpenter



Re: [PATCH v4 1/7] leds: add TI LMU backlight driver

2018-10-24 Thread Pavel Machek
On Tue 2018-10-23 12:06:17, Dan Murphy wrote:
> From: Pavel Machek 
> 
> This adds backlight support for the following TI LMU
> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
> 
> It controls LEDs on Droid 4
> smartphone, including keyboard and screen backlights.
> 
> Signed-off-by: Milo Kim 
> [add LED subsystem support for keyboard backlight and rework DT
> binding according to Rob Herrings feedback]
> Signed-off-by: Sebastian Reichel 
> [remove backlight subsystem support for now]
> Signed-off-by: Pavel Machek 

This is not correct way to sign off a patch.

What is worse, this is very different from patch I submitted; this
misses imporant parts while my patch was complete.

I already submitted better patch for both the driver and device tree
bindings. Can we go back and apply that?

Then you can add your changes on top of that, if they actually make
the situation better.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [RFC][PATCH v3 01/10] fs: common implementation of file type

2018-10-24 Thread Amir Goldstein
On Wed, Oct 24, 2018 at 11:21 AM Phillip Potter  wrote:
>
> On Wed, Oct 24, 2018 at 09:16:20AM +0300, Amir Goldstein wrote:
> > On Tue, Oct 23, 2018 at 11:19 PM Phillip Potter  
> > wrote:
> > >
> > > Many file systems use a copy&paste implementation
> > > of dirent to on-disk file type conversions.
> > >
> > > Create a common implementation to be used by file systems
> > > with some useful conversion helpers to reduce open coded
> > > file type conversions in file system code.
> > >
> > > Original patch written by Amir Goldstein.
> >
> > Looks good.
> > I guess you used 'git apply' or just 'patch'
> > What you usually do when applying someone else mostly unchanged
> > patches is use 'git am -s -3' so you preserve the original author and
> > original commit message including the Signed-of-by line.
> > You can edit your patch by hand to change the From: line to change the
> > author and add
> > Signed-off-by: Amir Goldstein 
> > (you sign below me as you changed the patch last)
> >
>
> Dear Amir,
>
> Yes, I applied each patch manually to my tree, fixed it up where needed,
> then after rebuilding and testing each one I committed it and regenerated
> each patch. Thank you very much for your advice, I will take it into
> account and make the necessary changes. In the meantime, do I add other
> tags in the order they are received also (such as Reviewed-by:) and am
> I safe to add these in when I re-send the patches with the changes you
> and others have suggested (or would that offend people that have
> offered the tags)?
>

Reviewed-by before of after Signed-off-by.
I prefer Signed-off-by last which conceptually covers the entire patch,
the commit message including all the review tags that you may have added.

Some developers add Reviewed-by after Signed-off-by signifying the
order that things happened, so choose your own preference.

As a reviewer, and I speak only for myself, if I offered my Reviewed-by
I expect it to be removed if a future revision of the patch has changed
so I have an indication of patches that I need to re-review.
But if the patch changed very lightly, like small edits to commit message
and code nits in general, that would not invalidate my review.
When in doubt, you can always explicitly ask the reviewer.

Thanks,
Amir.


Kernel Build error with gcc 9

2018-10-24 Thread damian
Hello all,

i know GCC 9 is currently in deployment progress. But i tried to build a
kernel 4.19RC8 with gcc 9 and i got the following error message:

Kernel: arch/x86/boot/bzImage is ready  (#1)
ERROR: "__popcountdi2" 
[drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined!
ERROR: "__popcountdi2" [drivers/net/ethernet/broadcom/bnx2x/bnx2x.ko] undefined!
/home/damian/kernel/linux/scripts/Makefile.modpost:92: die Regel für Ziel 
„__modpost“ scheiterte
make[2]: *** [__modpost] Fehler 1

with gcc 8 it works fine.
 
Any suggestion what could be the cause ?

Best regards
Damian


Re: [PATCH v4 5/7] dt-bindings: ti-lmu: Modify dt bindings for the LM3633

2018-10-24 Thread Pavel Machek
On Tue 2018-10-23 12:06:21, Dan Murphy wrote:
> The LM3633 is a single function LED driver. The single function LED
> driver needs to reside in the LED directory as a dedicated LED driver
> and not as a MFD device.  The device does have common brightness and ramp
> features and those can be accomodated by a TI LMU framework.
> 
> The LM3633 dt binding needs to be moved from the ti-lmu.txt and a dedicated
> LED dt binding needs to be added.  The new LM3633 LED dt binding will then
> reside in the Documentation/devicetree/bindings/leds directory and follow the
> current LED and general bindings guidelines.

What?

>  .../devicetree/bindings/leds/leds-lm3633.txt  | 102 ++
>  .../devicetree/bindings/mfd/ti-lmu.txt|  48 -
>  2 files changed, 102 insertions(+), 48 deletions(-)
>  create mode 100644
>  Documentation/devicetree/bindings/leds/leds-lm3633.txt

> index 920f910be4e9..573e88578d3d 100644
> --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> @@ -7,7 +7,6 @@ TI LMU driver supports lighting devices below.
>LM3532   Backlight
>LM3631   Backlight and regulator
>LM3632   Backlight and regulator
> -  LM3633   Backlight, LED and fault monitor
>LM3695   Backlight

Are you seriously proposing to take one binding and split it into 6
copy&pasted ones?

That's not the way we do development. NAK.

We don't want to have copy & pasted code. We also don't want to have
copy & pasted bindings. Nor changelogs, for that matter.

Thank you,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [RFC][PATCH v3 01/10] fs: common implementation of file type

2018-10-24 Thread Phillip Potter
On Wed, Oct 24, 2018 at 12:20:14PM +0300, Amir Goldstein wrote:
> On Wed, Oct 24, 2018 at 11:21 AM Phillip Potter  wrote:
> > Dear Amir,
> >
> > Yes, I applied each patch manually to my tree, fixed it up where needed,
> > then after rebuilding and testing each one I committed it and regenerated
> > each patch. Thank you very much for your advice, I will take it into
> > account and make the necessary changes. In the meantime, do I add other
> > tags in the order they are received also (such as Reviewed-by:) and am
> > I safe to add these in when I re-send the patches with the changes you
> > and others have suggested (or would that offend people that have
> > offered the tags)?
> >
> 
> Reviewed-by before of after Signed-off-by.
> I prefer Signed-off-by last which conceptually covers the entire patch,
> the commit message including all the review tags that you may have added.
> 
> Some developers add Reviewed-by after Signed-off-by signifying the
> order that things happened, so choose your own preference.
> 
> As a reviewer, and I speak only for myself, if I offered my Reviewed-by
> I expect it to be removed if a future revision of the patch has changed
> so I have an indication of patches that I need to re-review.
> But if the patch changed very lightly, like small edits to commit message
> and code nits in general, that would not invalidate my review.
> When in doubt, you can always explicitly ask the reviewer.
> 
> Thanks,
> Amir.

Dear Amir,

Thanks - I am just going to fix up the commit messages as you suggested
using git am etc. The content of the patches themselves will not change
(until further feedback is received).

Regards,
Phil


[PATCH] spi: uniphier: fix incorrect property items

2018-10-24 Thread Keiji Hayashibara
This commit fixes incorrect property because it was different
from the actual.
The parameters of '#address-cells' and '#size-cells' were removed,
and 'interrupts', 'pinctrl-names' and 'pinctrl-0' were added.

Fixes: 4dcd5c2781f3 ("spi: add DT bindings for UniPhier SPI controller")
Signed-off-by: Keiji Hayashibara 
---
 Documentation/devicetree/bindings/spi/spi-uniphier.txt | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-uniphier.txt 
b/Documentation/devicetree/bindings/spi/spi-uniphier.txt
index 504a4ec..b04e66a 100644
--- a/Documentation/devicetree/bindings/spi/spi-uniphier.txt
+++ b/Documentation/devicetree/bindings/spi/spi-uniphier.txt
@@ -5,18 +5,20 @@ UniPhier SoCs have SCSSI which supports SPI single channel.
 Required properties:
  - compatible: should be "socionext,uniphier-scssi"
  - reg: address and length of the spi master registers
- - #address-cells: must be <1>, see spi-bus.txt
- - #size-cells: must be <0>, see spi-bus.txt
- - clocks: A phandle to the clock for the device.
- - resets: A phandle to the reset control for the device.
+ - interrupts: a single interrupt specifier
+ - pinctrl-names: should be "default"
+ - pinctrl-0: pin control state for the default mode
+ - clocks: a phandle to the clock for the device
+ - resets: a phandle to the reset control for the device
 
 Example:
 
 spi0: spi@54006000 {
compatible = "socionext,uniphier-scssi";
reg = <0x54006000 0x100>;
-   #address-cells = <1>;
-   #size-cells = <0>;
+   interrupts = <0 39 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_spi0>;
clocks = <&peri_clk 11>;
resets = <&peri_rst 11>;
 };
-- 
2.7.4



Re: KASAN: slab-out-of-bounds Read in string (2)

2018-10-24 Thread Amir Goldstein
> > diff --git a/fs/lockd/host.c b/fs/lockd/host.c
> > index d35cd6be0675..93fb7cf0b92b 100644
> > --- a/fs/lockd/host.c
> > +++ b/fs/lockd/host.c
> > @@ -341,7 +341,7 @@ struct nlm_host *nlmsvc_lookup_host(const struct
> > svc_rqst *rqstp,
> > };
> > struct lockd_net *ln = net_generic(net, lockd_net_id);
> >
> > -   dprintk("lockd: %s(host='%*s', vers=%u, proto=%s)\n", __func__,
> > +   dprintk("lockd: %s(host='%.*s', vers=%u, proto=%s)\n", __func__,
> > (int)hostname_len, hostname, rqstp->rq_vers,
> > (rqstp->rq_prot == IPPROTO_UDP ? "udp" : "tcp"));
> >
>
> Why wasn't this one applied?  It looks correct to me.  The rest seem to
> have been fixed already.
>

I did not send this patch to Jeff.
Jeff was CC'ed on the patch I sent to Miklos
and Miklos decided to only take the overlayfs bits:
https://marc.info/?l=linux-unionfs&m=153847248625015&w=2

So I guess it has fallen between the cracks.
Feel free to send a patch to Jeff.

Thanks,
Amir.


Re: [PATCH] xen: remove redundant 'default n' from Kconfig

2018-10-24 Thread Juergen Gross
On 16/10/2018 16:33, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
> 
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") the Kconfig behavior is the same
> regardless of 'default n' being present or not:
> 
> ...
> One side effect of (and the main motivation for) this change is making
> the following two definitions behave exactly the same:
> 
> config FOO
> bool
> 
> config FOO
> bool
> default n
> 
> With this change, neither of these will generate a
> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
> That might make it clearer to people that a bare 'default n' is
> redundant.
> ...
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz 

Pushed to xen.tip for-linus-4.20a


Juergen


Re: [PATCH 1/1] nds32: Power management for nds32

2018-10-24 Thread Nick Hu
Hi Pavel,

On Wed, Oct 24, 2018 at 02:51:17PM +0800, Pavel Machek wrote:
> On Wed 2018-10-24 11:40:07, Nickhu wrote:
> > There are three sleep states in nds32:
> > suspend to idle,
> > suspend to standby,
> > suspend to ram
> > 
> > In suspend to ram, we use the 'standby' instruction to emulate
> > power management device to hang the system util wakeup source
> > send wakeup events to break the loop.
> > 
> > First, we push the general purpose registers and system registers
> > to stack. Second, we translate stack pointer to physical address
> > and store to memory to save the stack pointer. Third, after write
> > back and invalid the cache we hang in 'standby' intruction.
> > When wakeup source trigger wake up events, the loop will be break
> > and resume the system.
> > 
> > Signed-off-by: Nickhu 
> 
> Is "Nickhu" complete name?
>
Oh, Nick Hu is my complete name.
I will fix it.
Thanks!
 
> > diff --git a/arch/nds32/kernel/pm.c b/arch/nds32/kernel/pm.c
> > new file mode 100644
> > index ..e1eaf3bac709
> > --- /dev/null
> > +++ b/arch/nds32/kernel/pm.c
> > @@ -0,0 +1,91 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2008-2017 Andes Technology Corporation
> > +
> > +/*
> > + * nds32 Power Management Routines
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License.
> > + *
> > + *  Abstract:
> > + *
> > + *This program is for nds32 power management routines.
> > + *
> > + */
> 
> I'd get rid of "abstract" here, repeating GPL twice and "nds32 power
> management routines" twice does not make much sense either.
> 
Ok, I will get rid of it.

> > @@ -0,0 +1,129 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (C) 2017 Andes Technology Corporation */
> > +
> > +#include
> 
> Missing space.
> 
> > +static int nointc_set_wake(struct irq_data *data, unsigned int on)
> > +{
> > +   unsigned long int_mask = __nds32__mfsr(NDS32_SR_INT_MASK);
> > +   static bool is_bit_1[NR_IRQS] = {false};
> > +   u32 bit = 1 << data->hwirq;
> > +
> > +   if (on) {
> > +   if (int_mask & bit)
> > +   is_bit_1[data->hwirq] = true;
> > +   else
> > +   is_bit_1[data->hwirq] = false;
> > +
> > +   int_mask |= bit;
> > +   wake_mask |= bit;
> > +   } else {
> > +   if (!is_bit_1[data->hwirq])
> > +   int_mask &= ~bit;
> > +
> > +   wake_mask &= ~bit;
> > +   is_bit_1[data->hwirq] = false;
> > +   }
> 
> Can we get rid of "is_bit_1" array here, and use normal bit operations
> on another variable here?
>
Do you mean like this:

 static int nointc_set_wake(struct irq_data *data, unsigned int on)  {
unsigned long int_mask = __nds32__mfsr(NDS32_SR_INT_MASK);
static unsigned long irq_orig_bit = 0;
u32 bit = 1 << data->hwirq;

if (on) {
if (int_mask & bit)
__assign_bit(data->hwirq, &irq_orig_bit, true);
else
__assign_bit(data->hwirq, &irq_orig_bit, false);
 
__assign_bit(data->hwirq, &int_mask, true);
__assign_bit(data->hwirq, &wake_mask, true);

} else {
if (!(irq_orig_bit & bit))
__assign_bit(data->hwirq, &int_mask, false);

__assign_bit(data->hwirq, &wake_mask, false);
__assign_bit(data->hwirq, &irq_orig_bit, false);
}

__nds32__mtsr_dsb(int_mask, NDS32_SR_INT_MASK);
 
return 0;
 }

> Thanks,
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Thank your for quick reply,
Nick Hu.


Re: [RFC][PATCH v3 01/10] fs: common implementation of file type

2018-10-24 Thread Amir Goldstein
On Wed, Oct 24, 2018 at 12:31 PM Phillip Potter  wrote:
>
> On Wed, Oct 24, 2018 at 12:20:14PM +0300, Amir Goldstein wrote:
> > On Wed, Oct 24, 2018 at 11:21 AM Phillip Potter  
> > wrote:
> > > Dear Amir,
> > >
> > > Yes, I applied each patch manually to my tree, fixed it up where needed,
> > > then after rebuilding and testing each one I committed it and regenerated
> > > each patch. Thank you very much for your advice, I will take it into
> > > account and make the necessary changes. In the meantime, do I add other
> > > tags in the order they are received also (such as Reviewed-by:) and am
> > > I safe to add these in when I re-send the patches with the changes you
> > > and others have suggested (or would that offend people that have
> > > offered the tags)?
> > >
> >
> > Reviewed-by before of after Signed-off-by.
> > I prefer Signed-off-by last which conceptually covers the entire patch,
> > the commit message including all the review tags that you may have added.
> >
> > Some developers add Reviewed-by after Signed-off-by signifying the
> > order that things happened, so choose your own preference.
> >
> > As a reviewer, and I speak only for myself, if I offered my Reviewed-by
> > I expect it to be removed if a future revision of the patch has changed
> > so I have an indication of patches that I need to re-review.
> > But if the patch changed very lightly, like small edits to commit message
> > and code nits in general, that would not invalidate my review.
> > When in doubt, you can always explicitly ask the reviewer.
> >
> > Thanks,
> > Amir.
>
> Dear Amir,
>
> Thanks - I am just going to fix up the commit messages as you suggested
> using git am etc. The content of the patches themselves will not change
> (until further feedback is received).
>

Well, I did request to change some content (the location and the comment
above BUILD_BUG_ON section) which is relevant for several patches.
However, so far affected patched did not get any Reviewed-by.

Thanks,
Amir.


Re: [PATCH 1/1] nds32: Power management for nds32

2018-10-24 Thread Pavel Machek
Hi!

> > Can we get rid of "is_bit_1" array here, and use normal bit operations
> > on another variable here?
> >
> Do you mean like this:
> 
>  static int nointc_set_wake(struct irq_data *data, unsigned int on)  {
> unsigned long int_mask = __nds32__mfsr(NDS32_SR_INT_MASK);
> static unsigned long irq_orig_bit = 0;
> u32 bit = 1 << data->hwirq;
> 
> if (on) {
> if (int_mask & bit)
> __assign_bit(data->hwirq, &irq_orig_bit, true);
> else
> __assign_bit(data->hwirq, &irq_orig_bit, false);
>  
> __assign_bit(data->hwirq, &int_mask, true);
> __assign_bit(data->hwirq, &wake_mask, true);
> 
> } else {
> if (!(irq_orig_bit & bit))
> __assign_bit(data->hwirq, &int_mask, false);
> 
> __assign_bit(data->hwirq, &wake_mask, false);
> __assign_bit(data->hwirq, &irq_orig_bit, false);
> }
> 
> __nds32__mtsr_dsb(int_mask, NDS32_SR_INT_MASK);
>  
> return 0;

Yes, that is better. You don't need = 0 on static variable
afaict. (And may want to put it out of a function so it stands out). 

You can add my Acked-by on resulting patch.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v2] sched/core: Don't mix isolcpus and housekeeping CPUs

2018-10-24 Thread Srikar Dronamraju
* Mel Gorman  [2018-10-24 09:56:36]:

> On Wed, Oct 24, 2018 at 08:32:49AM +0530, Srikar Dronamraju wrote:
> It would certainly be a bit odd because the
> application is asking for some protection but no guarantees are given
> and the application is not made aware via an error code that there is a
> problem. Asking the application to parse dmesg hoping to find the right
> error message is going to be fragile.

Its a actually a good question.
What should we be doing if a mix of isolcpus and housekeeping (aka
non-isolcpus) is given in the mask.

Right now as you pointed, there is no easy way for the application to know
which are the non-isolcpus to set its affinity. cpusets effective_cpus and
cpus_allowed both will contain isolcpus too.

> Would it be more appropriate to fail sched_setaffinity when there is a
> mix of isolated and housekeeping CPUs? In that case, an info message in
> dmesg may be appropriate as it'll likely be a once-off configuration
> error that's obvious due to an application failure.

I was looking at option of returning an error in that case. However our
own perf bench numa cant handle it. We can be sure that there will other
tools who could have coded that way and may start failing. So I am not sure
if thats a good option. Previously they would *seem* to be working.

Thats why I have taken an option of correcting within the kernel.

> Alternatively,
> should NUMA balancing ignore isolated CPUs? The latter seems unusual as
> the application has specified a mask that allows those CPUs and it's not
> clear why NUMA balancing should ignore them. If anything, an application
> that wants to avoid all interference should also be using memory policies
> to bind to nodes so it behaves predictably with respect to access latencies
> (presumably if an application cannot tolerate kernel threads interfering
> then it also cannot tolerate remote access latencies) or disabling NUMA
> balancing entirely to avoid incurring minor faults.
> 

The numa balancing is doing the right thing because if the application has
the mask specified, then we should allow the application to run.

The problem happens when the unbound application starts to run on the isolcpu,
regular load balancing will no more work. If another task is bound on the
isolcpu, and other cpus in the node are free, this task will still contend
with task bound to the isolcpus. (Unless numa affinity of the unbound thread
changes).

Also isocpus are suppose to run only those tasks that are bound to it.
So we are kind of breaking that rule.

-- 
Thanks and Regards
Srikar Dronamraju



Re: [PATCH 3/3] i2c:ocores: add polling interface

2018-10-24 Thread Federico Vaga
On Sunday, October 21, 2018 4:39:07 PM CEST Peter Korsgaard wrote:
> On Mon, Jun 25, 2018 at 6:14 PM Federico Vaga  wrote:
> > This driver assumes that an interrupt line is always available for
> > the I2C master. This is not always the case and this patch adds support
> > for a polling version based on workqueue.
> 
> It probably makes sense to make it the switch between irq/irqless mode
> dynamic to support the upcoming master_xfer_irqless logic.
> 
> > Signed-off-by: Federico Vaga 
> > ---
> > 
> >  drivers/i2c/busses/i2c-ocores.c | 94
> >  ++--- 1 file changed, 79
> >  insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-ocores.c
> > b/drivers/i2c/busses/i2c-ocores.c index 274d6eb22a2c..0dad1a512ef5 100644
> > --- a/drivers/i2c/busses/i2c-ocores.c
> > +++ b/drivers/i2c/busses/i2c-ocores.c
> > @@ -13,6 +13,7 @@
> > 
> >   */
> >  
> >  #include 
> > 
> > +#include 
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > @@ -26,14 +27,19 @@
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > +#include 
> > +
> > +#define OCORES_FLAG_POLL BIT(0)
> > 
> >  struct ocores_i2c {
> >  
> > void __iomem *base;
> > u32 reg_shift;
> > u32 reg_io_width;
> > 
> > +   unsigned long flags;
> > 
> > wait_queue_head_t wait;
> > struct i2c_adapter adap;
> > struct i2c_msg *msg;
> > 
> > +   struct work_struct xfer_work;
> > 
> > int pos;
> > int nmsgs;
> > int state; /* see STATE_ */
> > 
> > @@ -166,8 +172,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8
> > stat)> 
> > oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
> > return;
> > 
> > }
> > 
> > -   } else
> > +   } else {
> > 
> > msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
> > 
> > +   }
> 
> This looks unrelated to $SUBJECT.

Do you prefer a different patch just for styling?

> 
> > /* end of msg? */
> > if (i2c->pos == msg->len) {
> > 
> > @@ -232,6 +239,50 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
> > 
> > return IRQ_HANDLED;
> >  
> >  }
> > 
> > +
> > +/**
> > + * It waits until is possible to process some data
> 
> Please don't use "It waits ..", but rather "wait until ..". Same for
> the other function comments.

ok

> > + * @i2c: ocores I2C device instance
> > + *
> > + * This is used when the device is in polling mode (interrupts disabled).
> > + * It sleeps for the time necessary to send 8bits (one transfer over
> > + * the I2C bus), then it permanently ping the ip-core until is possible
> > + * to process data. The idea is that we sleep for most of the time at the
> > + * beginning because we are sure that the ip-core is not ready yet.
> > + */
> > +static void ocores_poll_wait(struct ocores_i2c *i2c)
> > +{
> > +   int sleep_min = (8/i2c->bus_clock_khz) * 1000; /* us for 8bits */
> > +   u8 loop_on;
> > +
> > +   usleep_range(sleep_min, sleep_min + 10);
> 
> Where does this 10 come from?

It's true, it's just a random number. It can be zero as well, and we ask the 
system to just sleep for that amount of time. 

(1) usleep_range(sleep_min, sleep_min);

I noticed that it is a common practice to just put numbers that sounds 
correct, indeed there are many random numbers (not commented at least, so they 
are random numbers for the reader) in drivers/i2c/busses when they use this 
function.

This magic number can be also something like:
 
(2) usleep_range(sleep_min, sleep_min * 1.10);

to give a 10% (again random choice) extra margin before starting to actively 
poll.

But I agree that random numbers are not good. So I'm ok with option (1). I did 
not try it, but I think is fine to give a zero delta (delta=max-min=0).

> 
> > +   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR)
> > +   loop_on = OCI2C_STAT_BUSY;
> > +   else
> > +   loop_on = OCI2C_STAT_TIP;
> > +   while (oc_getreg(i2c, OCI2C_STATUS) & loop_on)
> > +   ;
> 
> How would an I2C transmission timeout be handled here?

There is the assumption that the hardware is alive and what we read from 
oc_getreg() is correct. With this assumption, when there is a timeout this 
will happen:
1. STOP command (previous patch)
2. both TIP and BUSY will become zero at some point and we get out from the 
loop

I can see now that there are cases when it may loop forever: for example if 
the device is broken and it does answer always with 0x: we should not 
break the host as well :)

I can fix this.
 
> > +}
> > +
> > +
> > +/**
> > + * It implements the polling logic
> > + * @work: work instance descriptor
> > + *
> > + * Here we try to re-use as much as possible from the IRQ logic
> > + */
> > +static void ocores_work(struct work_struct *work)
> > +{
> > +   struct ocores_i2c *i2c = container_of(work,
> > +   

Re: [PATCH] fpga: altera_cvp: restrict registration to CvP enabled devices

2018-10-24 Thread Moritz Fischer
Hi Anatolij, Andreas,

On Tue, Oct 23, 2018 at 06:46:47PM +, Andreas Puhm wrote:
> Hi Anatolij,
> 
> > The CvP docs says that on some FPGAs (e.g. Arria 10) the assertion of CVP
> > status can take up to 500ms. However it is not clear whether this delay
> > might be required after peripheral image configuration and after PCIe
> > link activation. The diagram describing configuration sequence suggests
> > that CVP_EN should be polled until it is asserted. I can imaging the
> > situation that this bit is still not asserted when the device is being
> > probed. Maybe we should better defer device probing if CVP_EN bit is
> > cleared? When deferred probing fails again and sufficient period for
> > CVP_EN bit assertion elapsed, then stop deferred probing and return
> > -ENODEV?
> > 
> > Thanks,
> > 
> > Anatolij
> 
> Anatolij, thank you for your feedback.
> 
> My rationale behind the patch is as follows:
> 
> The CVP_EN is part of the Hard PCIe IP core configuration,
> and therefore, has a defined and static value right from "the start".
> 
> Remark in [1, fig 12]
> " For high density devices such as Intel Cyclone 10 GX, 
> it may be necessary to wait up to 500 ms for the CvP
> status register bit assertion."
> According to [2] the Cyclone 10 GX devices achieve proper operation
> within 100 ms (via the PCIe IP core and CvP).
> 
> I think (and here the documentation is a bit lacking), 
> that this remark is valid only for other bits of the status register,
> e.g., CVP_CONFIG_DONE or USERMODE.
> I also think, that the 500 ms delay is calculated from peripheral + core 
> image programming
> and that the time for peripheral image programming is far lower than that 
> (i.e., low enough to allow PCI enumeration).
> 
> But if this actually means that it can take up to 500 ms to program the 
> peripheral image, 
> than such FPGAs would have different problems.
> I.e., missing the deadline for PCI enumeration. 
> This would need a solution outside of the scope of the
> altera_cvp module (e.g., soft-reset to re-start enumeration with a stable 
> system).
> 
> Bottom line: 
> The CVP_EN should be deemed stable when altera_cvp is called, 
> if not, 
> the programming of the Intel/Altera FPGA and PCIe IP core has not been 
> completed in time
> for the enumeration of the PCI device. Hence it would be questionable or, 
> more likely, would not
> have completed successfully in the first place, i.e., altera_cvp would not 
> have been called.

Yeah I think this makes sense. If your config space isn't up on boot you
would run into issues. I agree the docs are soemwhat vague here. Maybe Matthew 
or Alan can shoot
an email to their HW folks internally to clarify?

Thanks,
Moritz


Re: [RFC][PATCH v3 01/10] fs: common implementation of file type

2018-10-24 Thread Phillip Potter
On Wed, Oct 24, 2018 at 12:44:50PM +0300, Amir Goldstein wrote:
> On Wed, Oct 24, 2018 at 12:31 PM Phillip Potter  wrote:
> >
> > On Wed, Oct 24, 2018 at 12:20:14PM +0300, Amir Goldstein wrote:
> > > On Wed, Oct 24, 2018 at 11:21 AM Phillip Potter  
> > > wrote:
> > > > Dear Amir,
> > > >
> > > > Yes, I applied each patch manually to my tree, fixed it up where needed,
> > > > then after rebuilding and testing each one I committed it and 
> > > > regenerated
> > > > each patch. Thank you very much for your advice, I will take it into
> > > > account and make the necessary changes. In the meantime, do I add other
> > > > tags in the order they are received also (such as Reviewed-by:) and am
> > > > I safe to add these in when I re-send the patches with the changes you
> > > > and others have suggested (or would that offend people that have
> > > > offered the tags)?
> > > >
> > >
> > > Reviewed-by before of after Signed-off-by.
> > > I prefer Signed-off-by last which conceptually covers the entire patch,
> > > the commit message including all the review tags that you may have added.
> > >
> > > Some developers add Reviewed-by after Signed-off-by signifying the
> > > order that things happened, so choose your own preference.
> > >
> > > As a reviewer, and I speak only for myself, if I offered my Reviewed-by
> > > I expect it to be removed if a future revision of the patch has changed
> > > so I have an indication of patches that I need to re-review.
> > > But if the patch changed very lightly, like small edits to commit message
> > > and code nits in general, that would not invalidate my review.
> > > When in doubt, you can always explicitly ask the reviewer.
> > >
> > > Thanks,
> > > Amir.
> >
> > Dear Amir,
> >
> > Thanks - I am just going to fix up the commit messages as you suggested
> > using git am etc. The content of the patches themselves will not change
> > (until further feedback is received).
> >
> 
> Well, I did request to change some content (the location and the comment
> above BUILD_BUG_ON section) which is relevant for several patches.
> However, so far affected patched did not get any Reviewed-by.
> 
> Thanks,
> Amir.

Sorry, I missed that bit at the end, was too keen to click through to the
note about the alleged ext2 bug :-) I will make sure those changes are made
as well. By location do you mean the location of the v3, v2, etc. stuff and
your point about including it in the main [0/10] message rather than the
patches themselves? Again, thank you for your feedback and for being patient
with me, I really do appreciate it.

Regards,
Phil


Re: [PATCH] mmc: sdhci-pci: Try "cd" for card-detect lookup before using NULL

2018-10-24 Thread Andy Shevchenko
On Mon, Oct 22, 2018 at 04:34:55PM -0700, Rajat Jain wrote:
> On Fri, Oct 19, 2018 at 2:13 AM Andy Shevchenko
>  wrote:
> > On Fri, Oct 19, 2018 at 12:53 AM Rajat Jain  wrote:

> > > across other users of this API (other MMC host controller drivers).
> >
> > > if (slot->cd_idx >= 0) {
> > > -   ret = mmc_gpiod_request_cd(host->mmc, NULL, slot->cd_idx,
> > > +   ret = mmc_gpiod_request_cd(host->mmc, "cd", slot->cd_idx,
> > >slot->cd_override_level, 0, 
> > > NULL);
> >
> > Yes.
> >
> > > +   if (ret && ret != -EPROBE_DEFER)
> > > +   ret = mmc_gpiod_request_cd(host->mmc, NULL,
> > > +  slot->cd_idx,
> > > +  
> > > slot->cd_override_level,
> > > +  0, NULL);
> >
> > And no. Instead of this part you need to provide an ACPI GPIO mapping table.
> 
> Sure, I am willing to do so, and I tried earlier too. However, certain
> doubts arose in my mind when I tried that and I posted my questions
> earlier (https://lkml.org/lkml/2018/9/28/507) but couldn't elicit any
> response. Unfortunately I still do not have answers. My primary
> questions are:
> 
> 1) - It seems that 1 SDHCI device may support multiple slots (looking
> at the code). It is not clear to me if they could share card detect
> interrupts, or should have separate ones? 

This is more likely question to HW engineers of your platform with a caveat
that there should be a way to distinguish exact slot in which card is being
inserted.

> Also, the driver may not
> really know? 

I think in such case the bug in HW design and / or driver.

> So should I add 1 or two pins using the
> devm_acpi_dev_add_driver_gpios().

This depends on the above, e.g. HW design, ACPI tables.

> Is some one familiar with SDHC
> driver can answer these questions, it shall be great.

Actually above questions better to ask in linux-mmc mailing list, which by the
fact is in Cc list already. So, wait for someone to clarify.


> 2) I'm not really sure what should I set "active_low" to? Isn't this
> something that should be specified by platform / ACPI too, and driver
> should just be able to say say choose whatever the ACPI says?
> 
> struct acpi_gpio_params {
> unsigned int crs_entry_index;
> unsigned int line_index;
> bool active_low;
> };


ACPI specification misses this property, that's why we have it in the
structure. In your case it should be provided by _DSD and thus be consistent
with the hardcoded values.

> Since I do not understand the above two issues, and thus I chose the
> safest path and not disturb the current code so as not to cause any
> regressions.

As far as I can see in the above it is disturbing the current code more than
needed.

> 
> Please let me know, and I'm happy to re-spin my patch.

-- 
With Best Regards,
Andy Shevchenko




Re: [PATCH v2] sched/core: Don't mix isolcpus and housekeeping CPUs

2018-10-24 Thread Peter Zijlstra
On Wed, Oct 24, 2018 at 08:32:49AM +0530, Srikar Dronamraju wrote:
> Load balancer and NUMA balancer are not suppose to work on isolcpus.
> 
> Currently when setting sched affinity, there are no checks to see if the
> requested cpumask has CPUs from both isolcpus and housekeeping CPUs.
> 
> If user passes a mix of isolcpus and housekeeping CPUs, then
> NUMA balancer can pick a isolcpu to schedule.
> With this change, if a combination of isolcpus and housekeeping CPUs are
> provided, then we restrict ourselves to housekeeping CPUs.

I'm still not liking this much. This adds more special cases for
isolcpus. Also, I don't believe in correcting silly users; give 'em rope
and show them how to tie the knot.

Where does the numa balancer pick the 'wrong' CPU?

task_numa_migrate() checks to see if the task is currently part of a
SD_NUMA domain, otherwise it doesn't do anything. This means your
housekeeping mask spans multiple nodes to begin with, right?

But after that we seem to ignore the sched domains entirely;
task_numa_find_cpu() only tests cpus_allowed.

It appears to me the for_each_online_node() iteration in
task_numa_migrate() needs an addition test to see if the selected node
has any CPUs in the relevant sched_domain _at_all_.

A little something like the below -- except we also need to do something
about cpus_active_mask. Not been near a compiler.

---
 kernel/sched/fair.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ee271bb661cc..287ef7f0203b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1497,6 +1497,8 @@ struct task_numa_env {
struct task_struct *best_task;
long best_imp;
int best_cpu;
+
+   cpumask_var_t cpus;
 };
 
 static void task_numa_assign(struct task_numa_env *env,
@@ -1704,7 +1706,7 @@ static void task_numa_find_cpu(struct task_numa_env *env,
 */
maymove = !load_too_imbalanced(src_load, dst_load, env);
 
-   for_each_cpu(cpu, cpumask_of_node(env->dst_nid)) {
+   for_each_cpu_and(cpu, cpumask_of_node(env->dst_nid), env->cpus) {
/* Skip this CPU if the source task cannot migrate */
if (!cpumask_test_cpu(cpu, &env->p->cpus_allowed))
continue;
@@ -1734,6 +1736,9 @@ static int task_numa_migrate(struct task_struct *p)
int nid, ret, dist;
long taskimp, groupimp;
 
+   if (!alloc_cpumask_var(&env.cpus, GFP_KERNEL))
+   return -ENOMEM;
+
/*
 * Pick the lowest SD_NUMA domain, as that would have the smallest
 * imbalance and would be the first to start moving tasks about.
@@ -1744,20 +1749,23 @@ static int task_numa_migrate(struct task_struct *p)
 */
rcu_read_lock();
sd = rcu_dereference(per_cpu(sd_numa, env.src_cpu));
-   if (sd)
-   env.imbalance_pct = 100 + (sd->imbalance_pct - 100) / 2;
-   rcu_read_unlock();
-
/*
 * Cpusets can break the scheduler domain tree into smaller
 * balance domains, some of which do not cross NUMA boundaries.
 * Tasks that are "trapped" in such domains cannot be migrated
 * elsewhere, so there is no point in (re)trying.
 */
-   if (unlikely(!sd)) {
+   if (!sd) {
sched_setnuma(p, task_node(p));
-   return -EINVAL;
+   rcu_read_unlock();
+   ret = -EINVAL;
+   goto out;
}
+   env.imbalance_pct = 100 + (sd->imbalance_pct - 100) / 2;
+   while (sd->parent)
+   sd = sd->parent;
+   cpumask_copy(env.cpus, sched_domain_span(sd));
+   rcu_read_unlock();
 
env.dst_nid = p->numa_preferred_nid;
dist = env.dist = node_distance(env.src_nid, env.dst_nid);
@@ -1783,6 +1791,9 @@ static int task_numa_migrate(struct task_struct *p)
if (nid == env.src_nid || nid == p->numa_preferred_nid)
continue;
 
+   if (!cpumask_intersects(cpumask_of_node(nid), env.cpus))
+   continue;
+
dist = node_distance(env.src_nid, env.dst_nid);
if (sched_numa_topology_type == NUMA_BACKPLANE &&
dist != env.dist) {
@@ -1822,8 +1833,10 @@ static int task_numa_migrate(struct task_struct *p)
}
 
/* No better CPU than the current one was found. */
-   if (env.best_cpu == -1)
-   return -EAGAIN;
+   if (env.best_cpu == -1) {
+   ret = -EAGAIN;
+   goto out;
+   }
 
best_rq = cpu_rq(env.best_cpu);
if (env.best_task == NULL) {
@@ -1831,7 +1844,7 @@ static int task_numa_migrate(struct task_struct *p)
WRITE_ONCE(best_rq->numa_migrate_on, 0);
if (ret != 0)
trace_sched_stick_numa(p, env.src_cpu, env

Re: [RFC][PATCH v3 01/10] fs: common implementation of file type

2018-10-24 Thread Amir Goldstein
On Wed, Oct 24, 2018 at 12:56 PM Phillip Potter  wrote:
>
> On Wed, Oct 24, 2018 at 12:44:50PM +0300, Amir Goldstein wrote:
...
> > Well, I did request to change some content (the location and the comment
> > above BUILD_BUG_ON section) which is relevant for several patches.
> > However, so far affected patched did not get any Reviewed-by.
> >
> > Thanks,
> > Amir.
>
> Sorry, I missed that bit at the end, was too keen to click through to the
> note about the alleged ext2 bug :-) I will make sure those changes are made
> as well. By location do you mean the location of the v3, v2, etc. stuff and
> your point about including it in the main [0/10] message rather than the
> patches themselves? Again, thank you for your feedback and for being patient
> with me, I really do appreciate it.
>

By location I meant place BUILD_BUG_ON() at the beginning of
ext2_set_de_type() and not nested inside inner scope of ext2_readdir().
And find similar appropriate places for other patches.

And one more thing for next posting - LKML is probably a too wide forum for
this filesystems cleanup series.

Cheers,
Amir.


[PATCH v5] printk: Add line-buffered printk() API.

2018-10-24 Thread Tetsuo Handa
Sometimes we want to print a whole line without being disturbed by
concurrent printk() from interrupts and/or other threads, for printk()
which does not end with '\n' can be disturbed.

Since mixed printk() output makes it hard to interpret, this patch
introduces API for line-buffered printk() output (so that we can make
sure that printk() ends with '\n').

Since functions introduced by this patch are merely wrapping
printk()/vprintk() calls in order to minimize possibility of using
"struct cont", it is safe to replace printk()/vprintk() with this API.
Since we want to remove "struct cont" eventually, we will try to remove
both "implicit printk() users who are expecting KERN_CONT behavior" and
"explicit pr_cont()/printk(KERN_CONT) users". Therefore, converting to
this API is recommended.

After this patch, we will consider how we can add context identifier to
each line of printk() output (so that we can group multiple lines into
one block when parsing). Therefore, if converting to this API does not
fit for some reason, you might be able to consider converting to multiple
printk() calls which end with '\n'.

Details:

  A structure named "struct printk_buffer" is introduced for buffering
  up to LOG_LINE_MAX bytes of printk() output which did not end with '\n'.

  get_printk_buffer() tries to assign a "struct printk_buffer" from
  statically preallocated array. get_printk_buffer() returns NULL if
  all "struct printk_buffer" are in use, but the caller does not need to
  check for NULL.

  put_printk_buffer() flushes and releases the "struct printk_buffer".
  put_printk_buffer() must match corresponding get_printk_buffer() as with
  rcu_read_unlock() must match corresponding rcu_read_lock().

  Three functions vprintk_buffered(), printk_buffered() and
  flush_printk_buffer() are provided for using "struct printk_buffer".
  These are like vfprintf(), fprintf(), fflush() except that these receive
  "struct printk_buffer *" for the first argument.

  vprintk_buffered() and printk_buffered() behave like vprintk() and
  printk() respectively if "struct printk_buffer *" argument is NULL.
  flush_printk_buffer() and put_printk_buffer() become no-op if
  "struct printk_buffer *" argument is NULL. Therefore, the caller of
  get_printk_buffer() does not need to check for NULL.

How to use this API:

  (1) Call get_printk_buffer() and acquire "struct printk_buffer *".

  (2) Rewrite printk() calls in the following way. The "ptr" is
  "struct printk_buffer *" obtained in step (1).

  printk(fmt, ...) => printk_buffered(ptr, fmt, ...)
  vprintk(fmt, args)   => vprintk_buffered(ptr, fmt, args)
  pr_emerg(fmt, ...)   => bpr_emerg(ptr, fmt, ...)
  pr_alert(fmt, ...)   => bpr_alert(ptr, fmt, ...)
  pr_crit(fmt, ...)=> bpr_crit(ptr, fmt, ...)
  pr_err(fmt, ...) => bpr_err(ptr, fmt, ...)
  pr_warning(fmt, ...) => bpr_warning(ptr, fmt, ...)
  pr_warn(fmt, ...)=> bpr_warn(ptr, fmt, ...)
  pr_notice(fmt, ...)  => bpr_notice(ptr, fmt, ...)
  pr_info(fmt, ...)=> bpr_info(ptr, fmt, ...)
  pr_cont(fmt, ...)=> bpr_cont(ptr, fmt, ...)

  (3) Release "struct printk_buffer" by calling put_printk_buffer().

Note that since "struct printk_buffer" buffers only up to one line, there
is no need to rewrite if it is known that the "struct printk_buffer" is
empty and printk() ends with '\n'.

  Good example:

printk("Hello ");=>  buf = get_printk_buffer();
pr_cont("world.\n"); printk_buffered(buf, "Hello ");
 printk_buffered(buf, "world.\n");
 put_printk_buffer(buf);

  Pointless example:

printk("Hello\n");   =>  buf = get_printk_buffer();
printk("World.\n");  printk_buffered(buf, "Hello\n");
 printk_buffered(buf, "World.\n");
 put_printk_buffer(buf);

Somebody might forget to call put_printk_buffer(). For those who want to
debug why all buffers are in use, CONFIG_DEBUG_PRINTK_BUFFERED option is
available. This option reports when/where get_printk_buffer() was called
and put_printk_buffer() is not yet called.

Note that bpr_devel() and bpr_debug() are not defined. This is
because pr_devel()/pr_debug() should not be followed by pr_cont()
because pr_devel()/pr_debug() are conditionally enabled; output from
pr_devel()/pr_debug() should always end with '\n'.

Previous version was proposed at
https://lkml.kernel.org/r/1539405580-4569-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
 .

Signed-off-by: Tetsuo Handa 
---
 include/linux/printk.h  |  38 ++
 kernel/printk/Makefile  |   2 +-
 kernel/printk/printk_buffered.c | 279 
 lib/Kconfig.debug   |   8 ++
 4 files changed, 326 insertions(+), 1 deletion(-)
 create mode 100644 kernel/printk/printk_buffered.c

diff --git a/include/linux/printk.h b/include/linux/printk.h
index cf3eccf..3b18a7e 100644
--- a/include/linux/pri

Re: [PATCH v13 08/12] KVM: x86: Add Intel PT context switch for each vcpu

2018-10-24 Thread Alexander Shishkin
Luwei Kang  writes:

> +static void pt_guest_enter(struct vcpu_vmx *vmx)
> +{
> + if (pt_mode == PT_MODE_SYSTEM)
> + return;
> +
> + /* Save host state before VM entry */
> + rdmsrl(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl);
> +
> + /*
> +  * Set guest state of MSR_IA32_RTIT_CTL MSR (PT will be disabled
> +  * on VM entry when it has been disabled in guest before).
> +  */
> + vmcs_write64(GUEST_IA32_RTIT_CTL, vmx->pt_desc.guest.ctl);
> +
> + if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) {
> + wrmsrl(MSR_IA32_RTIT_CTL, 0);
> + pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.addr_range);
> + pt_load_msr(&vmx->pt_desc.guest, vmx->pt_desc.addr_range);
> + }
> +}

>From my side this is still a NAK, because [1].

[1] https://marc.info/?l=kvm&m=153847567226248&w=2

Thanks,
--
Alex


Re: [PATCH v2 2/3] leds: upboard: Add LED support

2018-10-24 Thread Andy Shevchenko
On Tue, Oct 23, 2018 at 12:23:13PM -0700, Joe Perches wrote:
> On Tue, 2018-10-23 at 20:50 +0200, Jacek Anaszewski wrote:
> > > diff --git a/drivers/leds/leds-upboard.c b/drivers/leds/leds-upboard.c
> > > new file mode 100644
> > > index 000..34a6973
> > > --- /dev/null
> > > +++ b/drivers/leds/leds-upboard.c
> > > @@ -0,0 +1,104 @@
> []
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > 
> > The last include should go first to keep alphabetical order.
> 
> There is no accepted single kernel style for #include
> file ordering.

There is a rule of (subtly) better maintenance.
If you need to add / remove some header later in a (long) list of unordered
list, it would be error prone.

Just run `make includecheck` and see the result.

I personally fixed some header duplications and removal of init.h in unsorted
lists, which have been missed by some reasons.

> drivers/leds does not use a single style nor is this
> particular variant documented anywhere to my knowledge.

Neither does kernel in general.
But kernel is evolving and styles also. When you do such statement consider to
divide by a time period when certain code was pushed to upstream.

> Until such a time when either a local preferred style
> document or a treewide preferred style exists, please
> stop asking people to modify #include ordering for
> various styles like reverse christmas tree by length,
> alphabetic ordering, or other individual styles.

Why? It makes a sense to ask for new code (and even for patches against old one 
in some cases).

> My preferred style would always have kernel.h first
> as that may help with precompiled headers and overall
> kernel compilation time one day.

How ordering would screw this up?

-- 
With Best Regards,
Andy Shevchenko




[PATCH v2 0/1] nds32: Power management

2018-10-24 Thread Nick Hu
This commit is power management porting for nds32.

Changes in V2:
1. Fix the my complete name "Nickhu" to "Nick Hu".

2. Fix missing space in 'arch/nds32/kernel/sleep.S'.

3. Use normal bit operations to replace the array
'is_bit_1' in 'drivers/irqchip/irq-ativic32.c'.

Nick Hu (1):
  nds32: Power management for nds32

 arch/nds32/Kconfig   |  10 +++
 arch/nds32/include/asm/suspend.h |  11 +++
 arch/nds32/kernel/Makefile   |   2 +-
 arch/nds32/kernel/pm.c   |  79 +++
 arch/nds32/kernel/sleep.S| 129 +++
 drivers/irqchip/irq-ativic32.c   |  31 
 6 files changed, 261 insertions(+), 1 deletion(-)
 create mode 100644 arch/nds32/include/asm/suspend.h
 create mode 100644 arch/nds32/kernel/pm.c
 create mode 100644 arch/nds32/kernel/sleep.S

-- 
2.17.0



[PATCH v2 1/1] nds32: Power management for nds32

2018-10-24 Thread Nick Hu
There are three sleep states in nds32:
suspend to idle,
suspend to standby,
suspend to ram

In suspend to ram, we use the 'standby' instruction to emulate
power management device to hang the system util wakeup source
send wakeup events to break the loop.

First, we push the general purpose registers and system registers
to stack. Second, we translate stack pointer to physical address
and store to memory to save the stack pointer. Third, after write
back and invalid the cache we hang in 'standby' intruction.
When wakeup source trigger wake up events, the loop will be break
and resume the system.

Signed-off-by: Nick Hu 
Acked-by: Pavel Machek 
---
 arch/nds32/Kconfig   |  10 +++
 arch/nds32/include/asm/suspend.h |  11 +++
 arch/nds32/kernel/Makefile   |   2 +-
 arch/nds32/kernel/pm.c   |  79 +++
 arch/nds32/kernel/sleep.S| 129 +++
 drivers/irqchip/irq-ativic32.c   |  31 
 6 files changed, 261 insertions(+), 1 deletion(-)
 create mode 100644 arch/nds32/include/asm/suspend.h
 create mode 100644 arch/nds32/kernel/pm.c
 create mode 100644 arch/nds32/kernel/sleep.S

diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index dd448d431f5a..8e2c5ac6acd1 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -95,3 +95,13 @@ endmenu
 menu "Kernel Features"
 source "kernel/Kconfig.hz"
 endmenu
+
+menu "Power management options"
+config SYS_SUPPORTS_APM_EMULATION
+   bool
+
+config ARCH_SUSPEND_POSSIBLE
+   def_bool y
+
+source "kernel/power/Kconfig"
+endmenu
diff --git a/arch/nds32/include/asm/suspend.h b/arch/nds32/include/asm/suspend.h
new file mode 100644
index ..6ed2418af1ac
--- /dev/null
+++ b/arch/nds32/include/asm/suspend.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+// Copyright (C) 2008-2017 Andes Technology Corporation
+
+#ifndef __ASM_NDS32_SUSPEND_H
+#define __ASM_NDS32_SUSPEND_H
+
+extern void suspend2ram(void);
+extern void cpu_resume(void);
+extern unsigned long wake_mask;
+
+#endif
diff --git a/arch/nds32/kernel/Makefile b/arch/nds32/kernel/Makefile
index f52bd2744f50..8d62f2ecb1ab 100644
--- a/arch/nds32/kernel/Makefile
+++ b/arch/nds32/kernel/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_STACKTRACE)  += stacktrace.o
 obj-$(CONFIG_OF)   += devtree.o
 obj-$(CONFIG_CACHE_L2) += atl2c.o
 obj-$(CONFIG_PERF_EVENTS) += perf_event_cpu.o
-
+obj-$(CONFIG_PM)   += pm.o sleep.o
 extra-y := head.o vmlinux.lds
 
 obj-y  += vdso/
diff --git a/arch/nds32/kernel/pm.c b/arch/nds32/kernel/pm.c
new file mode 100644
index ..6989560abf4e
--- /dev/null
+++ b/arch/nds32/kernel/pm.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2008-2017 Andes Technology Corporation
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+unsigned int resume_addr;
+unsigned int *phy_addr_sp_tmp;
+
+static void nds32_suspend2ram(void)
+{
+   pgd_t *pgdv;
+   pud_t *pudv;
+   pmd_t *pmdv;
+   pte_t *ptev;
+
+   pgdv = (pgd_t *)__va((__nds32__mfsr(NDS32_SR_L1_PPTB) &
+   L1_PPTB_mskBASE)) + pgd_index((unsigned int)cpu_resume);
+
+   pudv = pud_offset(pgdv, (unsigned int)cpu_resume);
+   pmdv = pmd_offset(pudv, (unsigned int)cpu_resume);
+   ptev = pte_offset_map(pmdv, (unsigned int)cpu_resume);
+
+   resume_addr = ((*ptev) & TLB_DATA_mskPPN)
+   | ((unsigned int)cpu_resume & 0x0fff);
+
+   suspend2ram();
+}
+
+static void nds32_suspend_cpu(void)
+{
+   while (!(__nds32__mfsr(NDS32_SR_INT_PEND) & wake_mask))
+   __asm__ volatile ("standby no_wake_grant\n\t");
+}
+
+static int nds32_pm_valid(suspend_state_t state)
+{
+   switch (state) {
+   case PM_SUSPEND_ON:
+   case PM_SUSPEND_STANDBY:
+   case PM_SUSPEND_MEM:
+   return 1;
+   default:
+   return 0;
+   }
+}
+
+static int nds32_pm_enter(suspend_state_t state)
+{
+   pr_debug("%s:state:%d\n", __func__, state);
+   switch (state) {
+   case PM_SUSPEND_STANDBY:
+   nds32_suspend_cpu();
+   return 0;
+   case PM_SUSPEND_MEM:
+   nds32_suspend2ram();
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+static const struct platform_suspend_ops nds32_pm_ops = {
+   .valid = nds32_pm_valid,
+   .enter = nds32_pm_enter,
+};
+
+static int __init nds32_pm_init(void)
+{
+   pr_debug("Enter %s\n", __func__);
+   suspend_set_ops(&nds32_pm_ops);
+   return 0;
+}
+late_initcall(nds32_pm_init);
diff --git a/arch/nds32/kernel/sleep.S b/arch/nds32/kernel/sleep.S
new file mode 100644
index ..60c64bfbc901
--- /dev/null
+++ b/arch/nds32/kernel/sleep.S
@@ -0,0 +1,129 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2017 Andes Technology Corporation */
+
+#include 
+
+.data
+.global sp_t

Re: [PATCH v2] sched/core: Don't mix isolcpus and housekeeping CPUs

2018-10-24 Thread Peter Zijlstra
On Wed, Oct 24, 2018 at 03:16:46PM +0530, Srikar Dronamraju wrote:
> * Mel Gorman  [2018-10-24 09:56:36]:
> 
> > On Wed, Oct 24, 2018 at 08:32:49AM +0530, Srikar Dronamraju wrote:
> > It would certainly be a bit odd because the
> > application is asking for some protection but no guarantees are given
> > and the application is not made aware via an error code that there is a
> > problem. Asking the application to parse dmesg hoping to find the right
> > error message is going to be fragile.
> 
> Its a actually a good question.
> What should we be doing if a mix of isolcpus and housekeeping (aka
> non-isolcpus) is given in the mask.
> 
> Right now as you pointed, there is no easy way for the application to know
> which are the non-isolcpus to set its affinity. cpusets effective_cpus and
> cpus_allowed both will contain isolcpus too.

The easy option is to not use isolcpus :-) It is a horrifically bad
interface.


Re: [PATCH v1] soc/tegra: pmc: Drop locking from tegra_powergate_is_powered()

2018-10-24 Thread Jon Hunter


On 21/10/2018 19:36, Dmitry Osipenko wrote:
> This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
> and machine (Tegra30) booted with SMP=n or all secondary CPU's are put
> offline. Locking isn't needed because it protects atomic operation.
> 
> # echo 0 | tee /sys/devices/system/cpu/cpu[1-3]/online
> 
> BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:254
> in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C
> 4.18.0-next-20180821-00180-gc3ebb6544e44-dirty #823
> Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
> [] (show_stack) from [] (dump_stack+0x94/0xa8)
> [] (dump_stack) from [] (___might_sleep+0x13c/0x174)
> [] (___might_sleep) from [] (__might_sleep+0x70/0xa8)
> [] (__might_sleep) from [] (mutex_lock+0x2c/0x70)
> [] (mutex_lock) from [] 
> (tegra_powergate_is_powered+0x44/0xa8)
> [] (tegra_powergate_is_powered) from [] 
> (tegra30_cpu_rail_off_ready+0x30/0x74)
> [] (tegra30_cpu_rail_off_ready) from [] 
> (tegra30_idle_lp2+0xa0/0x108)
> [] (tegra30_idle_lp2) from [] 
> (cpuidle_enter_state+0x140/0x540)
> [] (cpuidle_enter_state) from [] (cpuidle_enter+0x40/0x4c)
> [] (cpuidle_enter) from [] (call_cpuidle+0x30/0x48)
> [] (call_cpuidle) from [] (do_idle+0x238/0x28c)
> [] (do_idle) from [] (cpu_startup_entry+0x28/0x2c)
> [] (cpu_startup_entry) from [] (rest_init+0xd8/0xdc)
> [] (rest_init) from [] (start_kernel+0x41c/0x430)
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/soc/tegra/pmc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
> index 1fa840e3d930..1714cd818d69 100644
> --- a/drivers/soc/tegra/pmc.c
> +++ b/drivers/soc/tegra/pmc.c
> @@ -543,9 +543,7 @@ int tegra_powergate_is_powered(unsigned int id)
>   if (!tegra_powergate_is_valid(id))
>   return -EINVAL;
>  
> - mutex_lock(&pmc->powergates_lock);
>   status = tegra_powergate_state(id);
> - mutex_unlock(&pmc->powergates_lock);
>  
>   return status;

Can we just ...

return tegra_powergate_state(id);

Cheers
Jon

-- 
nvpublic


Re: [PATCH v2 2/3] leds: upboard: Add LED support

2018-10-24 Thread Joe Perches
On Wed, 2018-10-24 at 13:13 +0300, Andy Shevchenko wrote:
> On Tue, Oct 23, 2018 at 12:23:13PM -0700, Joe Perches wrote:
> > Until such a time when either a local preferred style
> > document or a treewide preferred style exists, please
> > stop asking people to modify #include ordering for
> > various styles like reverse christmas tree by length,
> > alphabetic ordering, or other individual styles.
> 
> Why? It makes a sense to ask for new code (and even for patches against old 
> one in some cases).

It's just a nit and frequently impossible to require as
ordering dependencies between include files do exist.

> > My preferred style would always have kernel.h first
> > as that may help with precompiled headers and overall
> > kernel compilation time one day.
> 
> How ordering would screw this up?

gcc has many limits on the use of precompiled headers.

https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

Precompiled headers are often shared by multiple
compilation units and precompilation can be stopped
after a specific header.




[PATCH V1] ARM: dts: sabreauto: Remove reg property from fixed regulator

2018-10-24 Thread Joakim Zhang
Remove reg property from fixed regulator as upstream has no longer
needed this property.

Signed-off-by: Joakim Zhang 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 53 ++--
 1 file changed, 22 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index a6dc5c42c632..a10f0ad0bfb1 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -75,39 +75,30 @@
};
};
 
-   regulators {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <0>;
+   reg_audio: regulator-audio {
+   compatible = "regulator-fixed";
+   regulator-name = "cs42888_supply";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
 
-   reg_audio: regulator@0 {
-   compatible = "regulator-fixed";
-   reg = <0>;
-   regulator-name = "cs42888_supply";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
+   reg_usb_h1_vbus: regulator-usb-h1-vbus {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_h1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&max7310_b 7 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 
-   reg_usb_h1_vbus: regulator@1 {
-   compatible = "regulator-fixed";
-   reg = <1>;
-   regulator-name = "usb_h1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   gpio = <&max7310_b 7 GPIO_ACTIVE_HIGH>;
-   enable-active-high;
-   };
-
-   reg_usb_otg_vbus: regulator@2 {
-   compatible = "regulator-fixed";
-   reg = <2>;
-   regulator-name = "usb_otg_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   gpio = <&max7310_c 1 GPIO_ACTIVE_HIGH>;
-   enable-active-high;
-   };
+   reg_usb_otg_vbus: regulator-usb-otg-vbus {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_otg_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&max7310_c 1 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
};
 
sound-cs42888 {
-- 
2.17.1



  1   2   3   4   5   >