Re: [PATCH v3] Add tw5864 driver

2016-07-10 Thread Hans Verkuil
Hi Andrey,

Thanks for this driver. Some review comments below:

On 07/09/2016 09:46 PM, Andrey Utkin wrote:
> From: Andrey Utkin 
> 
> 
> Changes in v3 since v2:
>  - Kconfig: select VIDEOBUF2_DMA_CONTIG, not SG
>  - drop i2c code as unused
>  - Dropped num_buffers check in queue_setup as suggested by Hans
>  - Drop std autodetect on streaming start as suggested by Hans
>  - Cleanup buf queue on enable_input() failure
>  - Change container_of() to list_entry() where applicable
>  - Changed V4L2_FIELD_NONE to V4L2_FIELD_INTERLACED as suggested
>  - frameinterval rework suggested by Hans
>  - Add enum_framesizes
>  - Report framesize based on std, not input w/h
>  - Add printed warning about known video quality issues
>  - MAINTAINERS: fix path
>  - request_mem_region() -> pci_request_regions()
>  - Rebase onto Hans' "for-v4.8i" branch
>  - Follow changes from patchset "vb2: replace allocation context by device 
> pointer"
> 
> Below log is produced by today's v4l2-compliance from v4l-utils git, and this
> patch based on branch "for-v4.8i" of 
> git://linuxtv.org/hverkuil/media_tree.git .
> Compliance test runs fine.
> 
> checkpatch.pl is happy with this patch except for artifacts_warning which
> produces a bunch of such warnings:
> 
> WARNING: quoted string split across lines
> #155: FILE: drivers/media/pci/tw5864/tw5864-core.c:44:
> +"This driver was developed by Bluecherry LLC by deducing behaviour of 
> original"
> +" manufacturer's driver, from both source code and execution traces.\n"
> 
> I believe I'd better not join all the lines to avoid them looking like
> 
> "Paragraph one.\Paragraph two.\Paragraph three.\n"
> 
>  # v4l2-compliance -d 6 -s
> v4l2-compliance SHA   : 5e74f6a15aa14c01d8319e086d98f33d96a6a04d
> 
> Driver Info:
> Driver name   : tw5864
> Card type : TW5864 Encoder 2
> Bus info  : PCI::06:05.0
> Driver version: 4.7.0
> Capabilities  : 0x8521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video6 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 11 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK (Not Supported)
> 
> Codec ioctls:
> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> 
> Buffer ioctls:
> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> 

Re: [PATCH 3/3] ARM: dts: exynos: correct the rtc compatible value for exynos5

2016-07-10 Thread Krzysztof Kozlowski
On 07/09/2016 11:23 AM, Randy Li wrote:
> Those platforms are reported to use the same rtc IP core
> as exynos3250's.

Insufficient. Exynos4 also has to be updated. Actually all SoC from SoC
family requires rtc src clock. I think S3C6410 also requires it but I
don't have all the data necessary to confirm this.

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 2 +-
>  arch/arm/boot/dts/exynos5.dtsi| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 62f3dcd..cdd69a0 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -208,7 +208,7 @@
>   };
>  
>   rtc: rtc@1007 {
> - compatible = "samsung,s3c6410-rtc";
> + compatible = "samsung,exynos3250-rtc";
>   reg = <0x1007 0x100>;
>   interrupts = <0 73 0>, <0 74 0>;
>   interrupt-parent = <_system_controller>;
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index d5c0f18..71a1ad2 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -88,7 +88,7 @@
>   };
>  
>   rtc: rtc@101E {
> - compatible = "samsung,s3c6410-rtc";
> + compatible = "samsung,exynos3250-rtc";
>   reg = <0x101E 0x100>;
>   interrupts = <0 43 0>, <0 44 0>;
>   status = "disabled";
> 



Re: [PATCH 2/3] rtc: s3c: add device data for samsung,exynos3250-rtc

2016-07-10 Thread Krzysztof Kozlowski
On 07/09/2016 11:23 AM, Randy Li wrote:
> The device data for samsung,exynos3250-rtc and samsung,s3c6410-rtc
> are just have a difference, but keeping using the same device data
> would cause the platform using the other IP core not work.

I cannot understand what you wanted to say here. Please rephrase it.

Why not just reverting a42e6eae457837d6a5925f4926f5ba05ccf44f89?

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  drivers/rtc/rtc-s3c.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index 5dc18ca..e9f6151 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -810,6 +810,18 @@ static struct s3c_rtc_data const s3c6410_rtc_data = {
>   .disable= s3c6410_rtc_disable,
>  };
>  
> +static struct s3c_rtc_data const exynos3250_rtc_data = {
> + .max_user_freq  = 32768,
> + .needs_src_clk  = true,
> + .irq_handler= s3c6410_rtc_irq,
> + .set_freq   = s3c6410_rtc_setfreq,
> + .enable_tick= s3c6410_rtc_enable_tick,
> + .save_tick_cnt  = s3c6410_rtc_save_tick_cnt,
> + .restore_tick_cnt   = s3c6410_rtc_restore_tick_cnt,
> + .enable = s3c24xx_rtc_enable,
> + .disable= s3c6410_rtc_disable,
> +};
> +
>  static const struct of_device_id s3c_rtc_dt_match[] = {
>   {
>   .compatible = "samsung,s3c2410-rtc",
> @@ -825,7 +837,7 @@ static const struct of_device_id s3c_rtc_dt_match[] = {
>   .data = (void *)_rtc_data,
>   }, {
>   .compatible = "samsung,exynos3250-rtc",
> - .data = (void *)_rtc_data,
> + .data = (void *)_rtc_data,
>   },
>   { /* sentinel */ },
>  };
> 



Re: [PATCH 1/3] Revert "drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data"

2016-07-10 Thread Krzysztof Kozlowski
On 07/09/2016 11:23 AM, Randy Li wrote:
> This reverts commit 8792f7772f4f40ffc68bad5f28311205584b734d.
> The s3c6410 rtc don't use rtc_src property, that property is designed
> for Exynos5250 and Exynos5440. The problem reported in the commit
> I mentioned should be fixed in the other way.

... so you break in this commit all the newer platforms because the
rtc_src clock won't be enabled.

Does not look right.

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  drivers/rtc/rtc-s3c.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index d01ad7e..5dc18ca 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -801,7 +801,6 @@ static struct s3c_rtc_data const s3c2443_rtc_data = {
>  
>  static struct s3c_rtc_data const s3c6410_rtc_data = {
>   .max_user_freq  = 32768,
> - .needs_src_clk  = true,
>   .irq_handler= s3c6410_rtc_irq,
>   .set_freq   = s3c6410_rtc_setfreq,
>   .enable_tick= s3c6410_rtc_enable_tick,
> 


Re: [PATCH v2 19/22] usb: chipidea: msm: Handle phy power states

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:10PM -0700, Stephen Boyd wrote:
> The ULPI phy on qcom platforms needs to be initialized and
> powered on after a USB reset and before we toggle the run/stop
> bit. Otherwise, the phy locks up and doesn't work properly. Hook
> the phy initialization into the RESET event and the phy power off
> into the STOPPED event.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 40 
> +++---
>  drivers/usb/chipidea/core.c|  8 ++--
>  drivers/usb/chipidea/host.c|  8 ++--
>  include/linux/usb/chipidea.h   |  2 +-
>  4 files changed, 33 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index ab6a7713ee5c..5c486c15e043 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -75,20 +75,33 @@ static const struct reset_control_ops 
> ci_hdrc_msm_reset_ops = {
>   .reset = ci_hdrc_msm_por_reset,
>  };
>  
> -static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
> +static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->dev->parent;
>   struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
> + int ret;
>  
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> +
> + hw_phymode_configure(ci);
>   if (msm_ci->secondary_phy) {
>   u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
>   val |= HS_PHY_DIG_CLAMP_N;
>   writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
>   }
>  
> + ret = phy_init(ci->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(ci->phy);
> + if (ret) {
> + phy_exit(ci->phy);
> + return ret;
> + }
> +
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
>  
> @@ -108,21 +121,18 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc 
> *ci, unsigned event)
>HSPHY_SESS_VLD_CTRL);
>  
>   }
> -
> - usb_phy_init(ci->usb_phy);
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
> - /*
> -  * Put the phy in non-driving mode. Otherwise host
> -  * may not detect soft-disconnection.
> -  */
> - usb_phy_notify_disconnect(ci->usb_phy, USB_SPEED_UNKNOWN);
> + phy_power_off(ci->phy);
> + phy_exit(ci->phy);
>   break;
>   default:
>   dev_dbg(dev, "unknown ci_hdrc event\n");
>   break;
>   }
> +
> + return 0;
>  }
>  
>  static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> @@ -162,7 +172,6 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
>   struct ci_hdrc_msm *ci;
>   struct platform_device *plat_ci;
> - struct usb_phy *phy;
>   struct clk *clk;
>   struct reset_control *reset;
>   struct resource *res;
> @@ -176,21 +185,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   platform_set_drvdata(pdev, ci);
>  
> - /*
> -  * OTG(PHY) driver takes care of PHY initialization, clock management,
> -  * powering up VBUS, mapping of registers address space and power
> -  * management.
> -  */
> - phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> - if (IS_ERR(phy))
> - return PTR_ERR(phy);
> -
>   ci->pdata.name = "ci_hdrc_msm";
>   ci->pdata.capoffset = DEF_CAPOFFSET;
>   ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
> -   CI_HDRC_OVERRIDE_AHB_BURST;
> +   CI_HDRC_OVERRIDE_AHB_BURST |
> +   CI_HDRC_OVERRIDE_PHY_CONTROL;
>   ci->pdata.notify_event = ci_hdrc_msm_notify_event;
> - ci->pdata.usb_phy = phy;
>  
>   reset = devm_reset_control_get(>dev, "core");
>   if (IS_ERR(reset))
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index f144e1bbcc82..0866c03d66df 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -327,6 +327,7 @@ void hw_phymode_configure(struct ci_hdrc *ci)
>   hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
>   }
>  }
> +EXPORT_SYMBOL_GPL(hw_phymode_configure);
>  
>  /**
>   * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
> @@ -503,9 +504,12 @@ int hw_device_reset(struct ci_hdrc *ci)
>   

Re: [PATCH v2 20/22] usb: chipidea: msm: Be silent on probe defer errors

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:11PM -0700, Stephen Boyd wrote:
> If something fails in ci_hdrc_add_device() due to probe defer, we
> shouldn't print an error message. Be silent in this case as we'll
> try probe again later.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 5c486c15e043..d4cc45f8e65e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -257,8 +257,9 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
>pdev->num_resources, >pdata);
>   if (IS_ERR(plat_ci)) {
> - dev_err(>dev, "ci_hdrc_add_device failed!\n");
>   ret = PTR_ERR(plat_ci);
> + if (ret != -EPROBE_DEFER)
> + dev_err(>dev, "ci_hdrc_add_device failed!\n");
>   goto err_mux;
>   }
>  

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen


Re: [PATCH 0/3] making rtc cores from s3c6410 and exynos3250 both work

2016-07-10 Thread Krzysztof Kozlowski
On 07/09/2016 11:23 AM, Randy Li wrote:
> The 8792f7772f4f40ffc68bad5f28311205584b734d would just make those
> platform using rtc core from exynos3250 work but have a huge 
> effect on those platforms using the rtc core from s3c6410.
> These patches would fix this problem.
> 

Which problem? What huge effect? On which platforms? You didn't describe
it...

Your change breaks the ABI and is not compatible with current bindings
documentation.

Best regards,
Krzysztof

> Randy Li (3):
>   Revert "drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data"
>   rtc: s3c: add device data for samsung,exynos3250-rtc
>   ARM: dts: exynos: correct the rtc compatible value for exynos5
> 
>  arch/arm/boot/dts/exynos3250.dtsi |  2 +-
>  arch/arm/boot/dts/exynos5.dtsi|  2 +-
>  drivers/rtc/rtc-s3c.c | 15 +--
>  3 files changed, 15 insertions(+), 4 deletions(-)
> 



Re: [PATCH v2 18/22] usb: chipidea: msm: Add reset controller for PHY POR bit

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:09PM -0700, Stephen Boyd wrote:
> The MSM chipidea wrapper has two bits that are used to reset the
> first or second phy. Add support for these bits via the reset
> controller framework, so that phy drivers can reset their
> hardware at the right time during initialization.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/Kconfig   |  1 +
>  drivers/usb/chipidea/ci_hdrc_msm.c | 45 
> --
>  2 files changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 4f8c342a8865..488ecdf56bdd 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -2,6 +2,7 @@ config USB_CHIPIDEA
>   tristate "ChipIdea Highspeed Dual Role Controller"
>   depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && 
> !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
>   select EXTCON
> + select RESET_CONTROLLER
>   help
> Say Y here if your system has a dual role high speed USB
> controller based on ChipIdea silicon IP. Currently, only the
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index da2d399acdd2..ab6a7713ee5c 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -31,8 +32,10 @@
>  #define HSPHY_SESS_VLD_CTRL  BIT(25)
>  
>  /* Vendor base starts at 0x200 beyond CI base */
> +#define HS_PHY_CTRL  0x0040
>  #define HS_PHY_SEC_CTRL  0x0078
>  #define HS_PHY_DIG_CLAMP_N   BIT(16)
> +#define HS_PHY_POR_ASSERTBIT(0)
>  
>  struct ci_hdrc_msm {
>   struct platform_device *ci;
> @@ -40,11 +43,38 @@ struct ci_hdrc_msm {
>   struct clk *iface_clk;
>   struct clk *fs_clk;
>   struct ci_hdrc_platform_data pdata;
> + struct reset_controller_dev rcdev;
>   bool secondary_phy;
>   bool hsic;
>   void __iomem *base;
>  };
>  
> +static int
> +ci_hdrc_msm_por_reset(struct reset_controller_dev *r, unsigned long id)
> +{
> + struct ci_hdrc_msm *ci_msm = container_of(r, struct ci_hdrc_msm, rcdev);
> + void __iomem *addr = ci_msm->base;
> + u32 val;
> +
> + if (id)
> + addr += HS_PHY_SEC_CTRL;
> + else
> + addr += HS_PHY_CTRL;
> +
> + val = readl_relaxed(addr);
> + val |= HS_PHY_POR_ASSERT;
> + writel(val, addr);
> + udelay(12);

Does this delay is reference manual defines or experienced value?
Do you need to comment it?

Peter
> + val &= ~HS_PHY_POR_ASSERT;
> + writel(val, addr);
> +
> + return 0;
> +}
> +
> +static const struct reset_control_ops ci_hdrc_msm_reset_ops = {
> + .reset = ci_hdrc_msm_por_reset,
> +};
> +
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->dev->parent;
> @@ -186,10 +216,18 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (!ci->base)
>   return -ENOMEM;
>  
> - ret = clk_prepare_enable(ci->fs_clk);
> + ci->rcdev.owner = THIS_MODULE;
> + ci->rcdev.ops = _hdrc_msm_reset_ops;
> + ci->rcdev.of_node = pdev->dev.of_node;
> + ci->rcdev.nr_resets = 2;
> + ret = reset_controller_register(>rcdev);
>   if (ret)
>   return ret;
>  
> + ret = clk_prepare_enable(ci->fs_clk);
> + if (ret)
> + goto err_fs;
> +
>   reset_control_assert(reset);
>   usleep_range(1, 12000);
>   reset_control_deassert(reset);
> @@ -198,7 +236,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   ret = clk_prepare_enable(ci->core_clk);
>   if (ret)
> - return ret;
> + goto err_fs;
>  
>   ret = clk_prepare_enable(ci->iface_clk);
>   if (ret)
> @@ -236,6 +274,8 @@ err_mux:
>   clk_disable_unprepare(ci->iface_clk);
>  err_iface:
>   clk_disable_unprepare(ci->core_clk);
> +err_fs:
> + reset_controller_unregister(>rcdev);
>   return ret;
>  }
>  
> @@ -247,6 +287,7 @@ static int ci_hdrc_msm_remove(struct platform_device 
> *pdev)
>   ci_hdrc_remove_device(ci->ci);
>   clk_disable_unprepare(ci->iface_clk);
>   clk_disable_unprepare(ci->core_clk);
> + reset_controller_unregister(>rcdev);
>  
>   return 0;
>  }
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen


Re: [PATCH v2 17/22] usb: chipidea: msm: Make platform data driver local instead of global

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:08PM -0700, Stephen Boyd wrote:
> If two devices are probed with this same driver, they'll share
> the same platform data structure, while the chipidea core layer
> writes and modifies it. This can lead to interesting results
> especially if one device is an OTG type chipidea controller and
> another is a host. Let's create a copy of this structure per each
> device instance so that odd things don't happen.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 81437c8cea82..da2d399acdd2 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -39,6 +39,7 @@ struct ci_hdrc_msm {
>   struct clk *core_clk;
>   struct clk *iface_clk;
>   struct clk *fs_clk;
> + struct ci_hdrc_platform_data pdata;
>   bool secondary_phy;
>   bool hsic;
>   void __iomem *base;
> @@ -94,16 +95,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   }
>  }
>  
> -static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
> - .name   = "ci_hdrc_msm",
> - .capoffset  = DEF_CAPOFFSET,
> - .flags  = CI_HDRC_REGS_SHARED |
> -   CI_HDRC_DISABLE_STREAMING |
> -   CI_HDRC_OVERRIDE_AHB_BURST,
> -
> - .notify_event   = ci_hdrc_msm_notify_event,
> -};
> -
>  static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
>  struct platform_device *pdev)
>  {
> @@ -164,7 +155,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(phy))
>   return PTR_ERR(phy);
>  
> - ci_hdrc_msm_platdata.usb_phy = phy;
> + ci->pdata.name = "ci_hdrc_msm";
> + ci->pdata.capoffset = DEF_CAPOFFSET;
> + ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
> +   CI_HDRC_OVERRIDE_AHB_BURST;
> + ci->pdata.notify_event = ci_hdrc_msm_notify_event;
> + ci->pdata.usb_phy = phy;
>  
>   reset = devm_reset_control_get(>dev, "core");
>   if (IS_ERR(reset))
> @@ -221,7 +217,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   of_node_put(ulpi_node);
>  
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
> -  pdev->num_resources, 
> _hdrc_msm_platdata);
> +  pdev->num_resources, >pdata);

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen


[RFC PATCH v2] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()

2016-07-10 Thread jiada_wang
From: Jiada Wang 

Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.

This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().

Signed-off-by: Jiada Wang 
---
 drivers/clk/clk.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..2f930c8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct 
clk_core *core,
if (core->rate == core->new_rate)
return NULL;
 
+   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+   return core;
+
if (core->notifier_count) {
ret = __clk_notify(core, event, core->rate, core->new_rate);
if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (rate == clk_core_get_rate_nolock(core))
return 0;
 
-   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
-   return -EBUSY;
-
/* calculate new rates and get the topmost changed clock */
top = clk_calc_new_rates(core, rate);
if (!top)
-- 
1.7.9.5




Re: [PATCH v2 16/22] usb: chipidea: msm: Restore wrapper settings after reset

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:07PM -0700, Stephen Boyd wrote:
> When the RESET bit is set in the USBCMD register it resets quite
> a few of the wrapper's registers to their reset state. This
> includes the GENCONFIG and GENCONFIG2 registers. Currently this
> is done by the usb phy and ehci-msm drivers writing into the
> controller wrapper's MMIO address space. Let's consolidate the
> register writes into the wrapper driver instead so that we
> clearly split the wrapper from the phys.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 39 
> ++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 7708bee3ff3e..81437c8cea82 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,11 +14,22 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +#define HS_PHY_GENCONFIG 0x009c
> +#define HS_PHY_TXFIFO_IDLE_FORCE_DIS BIT(4)
> +
> +#define HS_PHY_GENCONFIG_2   0x00a0
> +#define HS_PHY_SESS_VLD_CTRL_EN  BIT(7)
> +#define HS_PHY_ULPI_TX_PKT_EN_CLR_FIXBIT(19)
> +
> +#define HSPHY_SESS_VLD_CTRL  BIT(25)
> +

Keep alignment please

Others are ok.

Acked-by: Peter Chen 

>  /* Vendor base starts at 0x200 beyond CI base */
>  #define HS_PHY_SEC_CTRL  0x0078
>  #define HS_PHY_DIG_CLAMP_N   BIT(16)
> @@ -29,6 +40,7 @@ struct ci_hdrc_msm {
>   struct clk *iface_clk;
>   struct clk *fs_clk;
>   bool secondary_phy;
> + bool hsic;
>   void __iomem *base;
>  };
>  
> @@ -48,6 +60,24 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>  
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
> +
> + /* workaround for rx buffer collision issue */
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG,
> + HS_PHY_TXFIFO_IDLE_FORCE_DIS, 0);
> +
> + if (!msm_ci->hsic)
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
> + HS_PHY_ULPI_TX_PKT_EN_CLR_FIX, 0);
> +
> + if (ci->platdata->vbus_extcon.edev) {
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
> + HS_PHY_SESS_VLD_CTRL_EN,
> + HS_PHY_SESS_VLD_CTRL_EN);
> + hw_write(ci, OP_USBCMD, HSPHY_SESS_VLD_CTRL,
> +  HSPHY_SESS_VLD_CTRL);
> +
> + }
> +
>   usb_phy_init(ci->usb_phy);
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> @@ -116,6 +146,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   struct reset_control *reset;
>   struct resource *res;
>   int ret;
> + struct device_node *ulpi_node, *phy_node;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
>  
> @@ -181,6 +212,14 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto err_mux;
>  
> + ulpi_node = of_find_node_by_name(pdev->dev.of_node, "ulpi");
> + if (ulpi_node) {
> + phy_node = of_get_next_available_child(ulpi_node, NULL);
> + ci->hsic = of_device_is_compatible(phy_node, 
> "qcom,usb-hsic-phy");
> + of_node_put(phy_node);
> + }
> + of_node_put(ulpi_node);
> +
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
>pdev->num_resources, 
> _hdrc_msm_platdata);
>   if (IS_ERR(plat_ci)) {
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen


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

2016-07-10 Thread Stephen Rothwell
Hi Mika,

On Mon, 11 Jul 2016 07:48:17 +0300 Mika Westerberg 
 wrote:
>
> Looks like it is the module name (configfs.o) that confuses modpost or
> linker. The below patch fixes it for me.

That makes sense.  Thanks.

-- 
Cheers,
Stephen Rothwell


Re: linux-next: manual merge of the clockevents tree with the arm-soc tree

2016-07-10 Thread Stephen Rothwell
Hi all,

On Thu, 7 Jul 2016 14:12:26 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the clockevents tree got a conflict in:
> 
>   arch/arm/Kconfig
> 
> between commit:
> 
>   c86f51737f8d ("ARM: clps711x: Switch to MULTIPLATFORM")
> 
> from the arm-soc tree and commit:
> 
>   250e46aa3bb3 ("clocksource/drivers/clps_711x: Add the COMPILE_TEST option")
> 
> from the clockevents tree.
> 
> I fixed it up (I used the arm-soc version of this file and then added
> the following merge fix patch) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> From: Stephen Rothwell 
> Date: Thu, 7 Jul 2016 13:59:06 +1000
> Subject: [PATCH] clocksource/drivers/clps_711x: fixup for "ARM: clps711x: 
> Switch to MULTIPLATFORM"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/arm/mach-clps711x/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-clps711x/Kconfig b/arch/arm/mach-clps711x/Kconfig
> index 3b56197ccfd0..dc7c6edeab39 100644
> --- a/arch/arm/mach-clps711x/Kconfig
> +++ b/arch/arm/mach-clps711x/Kconfig
> @@ -3,8 +3,8 @@ menuconfig ARCH_CLPS711X
>   depends on ARCH_MULTI_V4T
>   select ARCH_REQUIRE_GPIOLIB
>   select AUTO_ZRELADDR
> - select CLKSRC_MMIO
>   select CLKSRC_OF
> + select CLPS711X_TIMER
>   select COMMON_CLK
>   select CPU_ARM720T
>   select GENERIC_CLOCKEVENTS
> -- 
> 2.8.1

This merge fix is now applicable to the merge between the arm-soc tree
and the tip tree.

Also, the clockevents tree needs to be cleaned up as all its commits
have been added to the tip tree as different commits (but the same
patches) :-(

-- 
Cheers,
Stephen Rothwell


Re: [PATCH v15 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-07-10 Thread Baolin Wang
Hi Felipe,

On 1 July 2016 at 14:05, Baolin Wang  wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard framework for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger,
> which is pending testing. Moreover there may be other potential users will use
> it in future.
>
> Changes since v14:
>  - Add kernel documentation for struct usb_cahrger.
>  - Remove some redundant WARN() functions.
>
> Changes since v13:
>  - Remove the charger checking in usb_gadget_vbus_draw() function.
>  - Rename some functions in charger.c file.
>  - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v4.8
>
> Changes since v12:
>  - Remove the class and device things.
>  - Link usb charger to udc-core.ko.
>  - Create one "charger" subdirectory which holds all charger-related 
> attributes.
>
> Changes since v11:
>  - Reviewed and tested by Li Jun.
>
> Changes since v10:
>  - Introduce usb_charger_get_state() function to check charger state.
>  - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
>  in case will be issued in atomic context.
>
> Baolin Wang (4):
>   usb: gadget: Introduce the usb charger framework
>   usb: gadget: Support for the usb charger framework
>   usb: gadget: Integrate with the usb gadget supporting for usb charger
>   power: wm831x_power: Support USB charger current limit management
>
>  drivers/power/wm831x_power.c |   69 
>  drivers/usb/gadget/Kconfig   |8 +
>  drivers/usb/gadget/udc/Makefile  |1 +
>  drivers/usb/gadget/udc/charger.c |  738 
> ++
>  drivers/usb/gadget/udc/core.c|   17 +
>  include/linux/mfd/wm831x/pdata.h |3 +
>  include/linux/usb/charger.h  |  183 ++
>  include/linux/usb/gadget.h   |3 +
>  include/uapi/linux/usb/charger.h |   31 ++
>  9 files changed, 1053 insertions(+)
>  create mode 100644 drivers/usb/gadget/udc/charger.c
>  create mode 100644 include/linux/usb/charger.h
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> --
> 1.7.9.5
>

Do you have any other comments about this v15 patchset? If not, could
you please add this version patchset into your 'next' branch? Thanks a
lot.

-- 
Baolin.wang
Best Regards


linux-next: manual merge of the tip tree with the kspp tree

2016-07-10 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kernel/x86_init.c

between commit:

  255303026193 ("x86: apply more __ro_after_init and const")

from the kspp tree and commit:

  1bf8915ae515 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via CPUID")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kernel/x86_init.c
index 111b838db7fe,58b459296e13..
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@@ -91,7 -91,8 +91,8 @@@ struct x86_cpuinit_ops x86_cpuinit = 
  static void default_nmi_init(void) { };
  static int default_i8042_detect(void) { return 1; };
  
 -struct x86_platform_ops x86_platform = {
 +struct x86_platform_ops x86_platform __ro_after_init = {
+   .calibrate_cpu  = native_calibrate_cpu,
.calibrate_tsc  = native_calibrate_tsc,
.get_wallclock  = mach_get_cmos_time,
.set_wallclock  = mach_set_rtc_mmss,


Re: [lkp] [ext4] 5405511e1a: ltp.acl_test01.fail]

2016-07-10 Thread Ye Xiaolong
Hi, Theodore

On Sun, Jul 10, 2016 at 11:15:53PM -0400, Theodore Ts'o wrote:
>On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> https://github.com/0day-ci/linux 
>> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
>> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number of 
>> meta clusters in group")
>
>Hi, many thanks for the report.  One question -- is there some way the
>reporting could be speeded up?  Vegard's patch was sent late on the
>7th, and it looks like it hit the 0day-ci git repo a few hours later
>on the 8th, and was run early in the morning Chinese time.  Was the
>delay until the 11th due to the weekend and the desire to have a human
>sanity check the result?  Is that because there was a concern that
>there would be too many false positives?

Yes, you're right, although we have auto report feature (which has much
less delay) for high confidence errors/regressions detected, we still need
human sanity check for other cases to avoid too many false positives, it
will introduce some delays especially in weekend, sorry for that. We'll
improve our auto report part to cover more sensible cases.

>
>Also, if there was some way the 0day robot report could include a
>In-Reply-To: header to the patch being sent to the mailing list (in
>this case: <577eb740.10...@oracle.com>), it would make this even
>*more* useful.
>

Good point! We'll add this feature later.

Thanks,
Xiaolong

>
>Vegard, I'm guessing you didn't have a chance to test your patch
>before you sent it to the list?
>
>   bit_max = ext4_num_clusters_in_group(sb, i);
>   if ((bit_max >> 3) >= sb->s_blocksize) {
>   ext4_msg(sb, KERN_WARNING, "clusters in "
> "group %u exceeds block size", i);
>   goto failed_mount;
>   }
>
>
>This is the test which is failing, but it will fail by default on
>pretty much all ext4 file systems, since by default there will be
>32768 blocks (clusters) per group, with a 4k block size (and 32768 >>
>3 == 4096).  And in the test that failed, this was a 1k block size
>with 8192 blocks per blocks (and 8192 >> 3 == 1024).
>
>Anyway, as I mentioned before, I'd much rather do very specific sanity
>checking on superblock fields, instead of sanity checking calculated
>values such as ext4_num_clusters_in_group().
>
>Perhaps the easist thing to do is to run e2fsck -n on those file
>systems that are causing problems?
>
>Cheers,
>
>   - Ted


Re: [PATCH v7 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

2016-07-10 Thread David Miller
From: 
Date: Thu, 7 Jul 2016 20:23:30 -0700

> From: Tien Hock Loh 
> 
> This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
> the dwmac is set to sgmii.
> 
> Signed-off-by: Tien Hock Loh 
> Acked-by: Rob Herring 

Applied to net-next, thanks.


Re: [PATCH] spi: spi-ti-qspi: clear wlen field while setting word length.

2016-07-10 Thread Vignesh R
Hi Prahlad,

On Sunday 10 July 2016 01:35 AM, Prahlad V wrote:
> When a word length of 1 byte is selected and writing data of length
> more than QSPI_WLEN_MAX_BYTES, first MAX_BYTES will be transfered
> and remaining will be transfered byte by byte. In that case wlen
> field should be cleared before setting.
> 
> Signed-off-by: Prahlad V 
> ---
>  drivers/spi/spi-ti-qspi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
> index 29ea8d2..6c61f54 100644
> --- a/drivers/spi/spi-ti-qspi.c
> +++ b/drivers/spi/spi-ti-qspi.c
> @@ -276,9 +276,9 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct 
> spi_transfer *t,
>   cmd |= QSPI_WLEN(QSPI_WLEN_MAX_BITS);
>   } else {
>   writeb(*txbuf, qspi->base + QSPI_SPI_DATA_REG);
> - cmd = qspi->cmd | QSPI_WR_SNGL;

qspi->cmd always has WLEN field cleared and set to WLEN = 1 byte (see
ti_qspi_start_transfer_one()). And hence variable 'cmd' will also have
WLEN set to 1 byte.

>   xfer_len = wlen;
> - cmd |= QSPI_WLEN(wlen);
> + cmd = ((qspi->cmd & ~QSPI_WLEN_MASK) |
> +  QSPI_WLEN(wlen));

So, this won't be necessary.

-- 
Regards
Vignesh


Re: [PATCH v3] sched/deadline: remove useless param from setup_new_dl_entity

2016-07-10 Thread Xunlei Pang
On 2016/07/08 at 19:28, Juri Lelli wrote:
> setup_new_dl_entity() takes two parameters, but it only actually uses
> one of them, under a different name, to setup a new dl_entity, after:
>
>  2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity"
>
> as we currently do
>
>  setup_new_dl_entity(>dl, >dl)
>
> However, before Luca's change we were doing
>
>  setup_new_dl_entity(dl_se, pi_se)
>
> in update_dl_entity() for a dl_se->new entity: we were using pi_se's
> parameters (the potential PI donor) for setting up a new entity.
>
> Restore this behaviour (as we want to correctly initialize parameters of
> a boosted task that enters DEADLINE) by removing the useless second
> parameter of setup_new_dl_entity() and retrieving the top waiter
> directly from inside that function.
>
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Steven Rostedt 
> Cc: Luca Abeni 
> Signed-off-by: Juri Lelli 
>
> ---
>  Changes from v2:
>- optimize by calling rt_mutex_get_top_task only if the task is
>  boosted (as suggested by Steve)
>
>  Changes from v1:
>- Steve pointed out that we were actually using the second parameter
>  to permorm initialization
>- Luca confirmed that behavior is slightly changed w.r.t. before his
>  change
>- changelog updated and original behavior restored
> ---
>  kernel/sched/deadline.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index fcb7f0217ff4..7aeb21963d3c 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -346,11 +346,12 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
> task_struct *p,
>   * one, and to (try to!) reconcile itself with its own scheduling
>   * parameters.
>   */
> -static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se,
> -struct sched_dl_entity *pi_se)
> +static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
>  {
>   struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
>   struct rq *rq = rq_of_dl_rq(dl_rq);
> + struct task_struct *pi_task;
> + struct sched_dl_entity *pi_se = dl_se;
>  
>   WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
>  
> @@ -363,6 +364,15 @@ static inline void setup_new_dl_entity(struct 
> sched_dl_entity *dl_se,
>   return;
>  
>   /*
> +  * Use the scheduling parameters of the top pi-waiter task,
> +  * if we have one from which we can inherit a deadline.
> +  */
> + if (dl_se->dl_boosted &&
> + (pi_task = rt_mutex_get_top_task(dl_task_of(dl_se))) &&
> + dl_prio(pi_task->normal_prio))
> + pi_se = _task->dl;
> +
> + /*
>* We use the regular wall clock time to set deadlines in the
>* future; in fact, we must consider execution overheads (time
>* spent on hardirq context, etc.).
> @@ -1721,7 +1731,7 @@ static void switched_from_dl(struct rq *rq, struct 
> task_struct *p)
>  static void switched_to_dl(struct rq *rq, struct task_struct *p)
>  {
>   if (dl_time_before(p->dl.deadline, rq_clock(rq)))
> - setup_new_dl_entity(>dl, >dl);
> + setup_new_dl_entity(>dl);

I'm curious why we even call setup_new_dl_entity() for non-queued cases?
It seems more reasonable to do it when it really gets queued. We can see
that enqueue_task_dl()->update_dl_entity() also has the same update logic
as switched_to_dl().

If so, for already queued and boosted cases, rt_mutex_setprio() will call
enqueue_task() with ENQUEUE_REPLENISH set, so enqueue_dl_entity()
->replenish_dl_entity() will advance p->dl.deadline beforehand, see code:
replenish_dl_entity():
if (dl_se->dl_deadline == 0) {
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
}

IOW, we don't need to handle !dl boosted cases in setup_new_dl_entity().

Regards,
Xunlei

>  
>   if (task_on_rq_queued(p) && rq->curr != p) {
>  #ifdef CONFIG_SMP



Re: [RFT PATCH v5 0/3] Fix preemption timer optimization while nested guests run

2016-07-10 Thread Wanpeng Li
2016-07-08 20:02 GMT+08:00 Paolo Bonzini :
> As mentioned earlier, I don't have a reproducer yet that requires any
> changes beyond Wanpeng's (patch 1)---it's possible of course to write
> a kvm-unit-test testcase but I haven't had time for that yet.
>
> Thanks,
>
> Paolo Bonzini (2):
>   KVM: VMX: reflect broken preemption timer in vmcs_config
>   KVM: nVMX: keep preemption timer enabled during L2 execution

Cool, this patchset works after my testing. Feel free to add my
Tested-by for your two patches. :)

Regards,
Wanpeng Li


[RFC PATCH] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()

2016-07-10 Thread jiada_wang
From: Jiada Wang 

Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.

This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().

Signed-off-by: Jiada Wang 
---
 drivers/clk/clk.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..aa5e4c3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct 
clk_core *core,
if (core->rate == core->new_rate)
return NULL;
 
+   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+   return -EBUSY;
+
if (core->notifier_count) {
ret = __clk_notify(core, event, core->rate, core->new_rate);
if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (rate == clk_core_get_rate_nolock(core))
return 0;
 
-   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
-   return -EBUSY;
-
/* calculate new rates and get the topmost changed clock */
top = clk_calc_new_rates(core, rate);
if (!top)
-- 
1.7.9.5




linux-next: manual merge of the block tree with the f2fs tree

2016-07-10 Thread Stephen Rothwell
Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  fs/f2fs/data.c

between commits:

  19a5f5e2ef37 ("f2fs: drop any block plugging")
  52763a4b7a21 ("f2fs: detect host-managed SMR by feature flag")
  78682f794479 ("f2fs: fix to avoid reading out encrypted data in page cache")

from the f2fs tree and commits:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
  04d328defd06 ("f2fs: use bio op accessors")

from the block tree.

I fixed it up (see below - I am not confident of these fixups, so
please check and let me know if anything else is needed) and can carry
the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/f2fs/data.c
index 20b30162e7b4,8769e8349dff..
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@@ -100,16 -97,11 +100,16 @@@ static struct bio *__bio_alloc(struct f
return bio;
  }
  
- static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
-   struct bio *bio, enum page_type type)
 -static inline void __submit_bio(struct f2fs_sb_info *sbi, struct bio *bio)
++static inline void __submit_bio(struct f2fs_sb_info *sbi, struct bio *bio,
++  enum page_type type)
  {
-   if (!is_read_io(rw)) {
 -  if (!is_read_io(bio_op(bio)))
++  if (!is_read_io(bio_op(bio))) {
atomic_inc(>nr_wb_bios);
 +  if (f2fs_sb_mounted_hmsmr(sbi->sb) &&
 +  current->plug && (type == DATA || type == NODE))
 +  blk_finish_plug(current->plug);
 +  }
-   submit_bio(rw, bio);
+   submit_bio(bio);
  }
  
  static void __submit_merged_bio(struct f2fs_bio_info *io)
@@@ -124,7 -116,9 +124,9 @@@
else
trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
  
-   __submit_bio(io->sbi, fio->rw, io->bio, fio->type);
+   bio_set_op_attrs(io->bio, fio->op, fio->op_flags);
+ 
 -  __submit_bio(io->sbi, io->bio);
++  __submit_bio(io->sbi, io->bio, fio->type);
io->bio = NULL;
  }
  
@@@ -241,8 -237,10 +245,10 @@@ int f2fs_submit_page_bio(struct f2fs_io
bio_put(bio);
return -EFAULT;
}
+   bio->bi_rw = fio->op_flags;
+   bio_set_op_attrs(bio, fio->op, fio->op_flags);
  
-   __submit_bio(fio->sbi, fio->rw, bio, fio->type);
 -  __submit_bio(fio->sbi, bio);
++  __submit_bio(fio->sbi, bio, fio->type);
return 0;
  }
  
@@@ -1080,13 -1057,36 +1087,14 @@@ got_it
 */
if (bio && (last_block_in_bio != block_nr - 1)) {
  submit_and_realloc:
-   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
 -  __submit_bio(F2FS_I_SB(inode), bio);
++  __submit_bio(F2FS_I_SB(inode), bio, DATA);
bio = NULL;
}
if (bio == NULL) {
 -  struct fscrypt_ctx *ctx = NULL;
 -
 -  if (f2fs_encrypted_inode(inode) &&
 -  S_ISREG(inode->i_mode)) {
 -
 -  ctx = fscrypt_get_ctx(inode, GFP_NOFS);
 -  if (IS_ERR(ctx))
 -  goto set_error_page;
 -
 -  /* wait the page to be moved by cleaning */
 -  f2fs_wait_on_encrypted_page_writeback(
 -  F2FS_I_SB(inode), block_nr);
 -  }
 -
 -  bio = bio_alloc(GFP_KERNEL,
 -  min_t(int, nr_pages, BIO_MAX_PAGES));
 -  if (!bio) {
 -  if (ctx)
 -  fscrypt_release_ctx(ctx);
 +  bio = f2fs_grab_bio(inode, block_nr, nr_pages);
 +  if (IS_ERR(bio))
goto set_error_page;
 -  }
 -  bio->bi_bdev = bdev;
 -  bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(block_nr);
 -  bio->bi_end_io = f2fs_read_end_io;
 -  bio->bi_private = ctx;
+   bio_set_op_attrs(bio, REQ_OP_READ, 0);
}
  
if (bio_add_page(bio, page, blocksize, 0) < blocksize)
@@@ -1101,7 -1101,7 +1109,7 @@@ set_error_page
goto next_page;
  confused:
if (bio) {
-   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
 -  __submit_bio(F2FS_I_SB(inode), bio);
++  __submit_bio(F2FS_I_SB(inode), bio, DATA);
   

Re: [PATCH v2 15/22] usb: chipidea: msm: Mux over secondary phy at the right time

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:06PM -0700, Stephen Boyd wrote:
> We need to pick the correct phy at runtime based on how the SoC
> has been wired onto the board. If the secondary phy is used, take
> it out of reset and mux over to it by writing into the TCSR
> register. Make sure to do this on reset too, because this
> register is reset to the default value (primary phy) after the
> RESET bit is set in USBCMD.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 67 
> +++---
>  1 file changed, 62 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 7e870a253f55..7708bee3ff3e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -8,29 +8,44 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +/* Vendor base starts at 0x200 beyond CI base */
> +#define HS_PHY_SEC_CTRL  0x0078
> +#define HS_PHY_DIG_CLAMP_N   BIT(16)
> +

Keep alignment

>  struct ci_hdrc_msm {
>   struct platform_device *ci;
>   struct clk *core_clk;
>   struct clk *iface_clk;
>   struct clk *fs_clk;
> + bool secondary_phy;
> + void __iomem *base;
>  };
>  
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
> - struct device *dev = ci->gadget.dev.parent;
> + struct device *dev = ci->dev->parent;
> + struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
>  
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> + if (msm_ci->secondary_phy) {
> + u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
> + }
> +
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
>   usb_phy_init(ci->usb_phy);
> @@ -59,6 +74,39 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = 
> {
>   .notify_event   = ci_hdrc_msm_notify_event,
>  };
>  
> +static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> +struct platform_device *pdev)
> +{
> + struct regmap *regmap;
> + struct device *dev = >dev;
> + struct of_phandle_args args;
> + u32 val;
> + int ret;
> +
> + ret = of_parse_phandle_with_fixed_args(dev->of_node, "phy-select", 2, 0,
> +);
> + if (ret)
> + return 0;
> +
> + regmap = syscon_node_to_regmap(args.np);
> + of_node_put(args.np);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_write(regmap, args.args[0], args.args[1]);
> + if (ret)
> + return ret;
> +
> + ci->secondary_phy = !!args.args[1];
> + if (ci->secondary_phy) {
> + val = readl_relaxed(ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, ci->base + HS_PHY_SEC_CTRL);
> + }
> +
> + return 0;
> +}
> +
>  static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
>   struct ci_hdrc_msm *ci;
> @@ -66,6 +114,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   struct usb_phy *phy;
>   struct clk *clk;
>   struct reset_control *reset;
> + struct resource *res;
>   int ret;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
> @@ -105,6 +154,11 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   ci->fs_clk = NULL;
>   }
>  
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + ci->base = devm_ioremap_resource(>dev, res);
> + if (!ci->base)
> + return -ENOMEM;
> +
>   ret = clk_prepare_enable(ci->fs_clk);
>   if (ret)
>   return ret;
> @@ -123,9 +177,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto err_iface;
>  
> - plat_ci = ci_hdrc_add_device(>dev,
> - pdev->resource, pdev->num_resources,
> - _hdrc_msm_platdata);
> + ret = ci_hdrc_msm_mux_phy(ci, pdev);
> + if (ret)
> + goto err_mux;
> +
> + plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
> +  pdev->num_resources, 
> _hdrc_msm_platdata);

The above line has not changed.

After fixing above, you can add my ack.

Acked-by: Peter Chen 

-- 

Best Regards,

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

2016-07-10 Thread Mika Westerberg
On Mon, Jul 11, 2016 at 11:46:53AM +1000, Stephen Rothwell wrote:
> Hi Rafael,
> 
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
> ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
> undefined!
> ERROR: "config_item_put" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] undefined!
> ERROR: "config_item_init_type_name" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
> undefined!
> 
> ... and many more ...
> 
> Presumably (maybe?) caused by commit
> 
>   0bf54fcd9504 ("ACPI: add support for configfs")
> 
> though it is not obvious why this should be a problem.

Looks like it is the module name (configfs.o) that confuses modpost or
linker. The below patch fixes it for me.

From: Mika Westerberg 
Subject: [PATCH] ACPI: Rename configfs.c to acpi_configfs.c to prevent link 
error

If we compile ACPI configfs.c as module it will confuse the linker as it
hides symbols from the actual configfs:

Kernel: arch/x86/boot/bzImage is ready  (#1236)
  MODPOST 5739 modules
ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
undefined!
...

Prevent these by renaming the file to acpi_configfs.c instead.

Reported-by: Scott Lawson 
Signed-off-by: Mika Westerberg 
---
 drivers/acpi/Makefile| 2 +-
 drivers/acpi/{configfs.c => acpi_configfs.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/acpi/{configfs.c => acpi_configfs.c} (100%)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 1dc2173ad8d0..f72a83df1cf3 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -99,6 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
 obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
 obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
-obj-$(CONFIG_ACPI_CONFIGFS)+= configfs.o
+obj-$(CONFIG_ACPI_CONFIGFS)+= acpi_configfs.o
 
 video-objs += acpi_video.o video_detect.o
diff --git a/drivers/acpi/configfs.c b/drivers/acpi/acpi_configfs.c
similarity index 100%
rename from drivers/acpi/configfs.c
rename to drivers/acpi/acpi_configfs.c
-- 
2.8.1



Re: [PATCH v2 14/22] usb: chipidea: msm: Add proper clk and reset support

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:05PM -0700, Stephen Boyd wrote:
> The msm chipidea controller uses two main clks, an AHB clk to
> read/write the MMIO registers and a core clk called the system
> clk that drives the controller itself. Add support for these clks
> as they're required in all designs.
> 
> Also add support for an optional third clk that we need to turn
> on to reset the controller and wrapper logic and other
> "housekeeping" things. This clk was removed in later revisions of
> the hardware because the reset methodology no longer required
> clks to be enabled to propagate resets.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 72 
> +++---
>  1 file changed, 68 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index b282a717bf8c..7e870a253f55 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -10,11 +10,20 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +struct ci_hdrc_msm {
> + struct platform_device *ci;
> + struct clk *core_clk;
> + struct clk *iface_clk;
> + struct clk *fs_clk;
> +};
> +
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->gadget.dev.parent;
> @@ -52,11 +61,20 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata 
> = {
>  
>  static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
> + struct ci_hdrc_msm *ci;
>   struct platform_device *plat_ci;
>   struct usb_phy *phy;
> + struct clk *clk;
> + struct reset_control *reset;
> + int ret;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
>  
> + ci = devm_kzalloc(>dev, sizeof(*ci), GFP_KERNEL);
> + if (!ci)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, ci);
> +
>   /*
>* OTG(PHY) driver takes care of PHY initialization, clock management,
>* powering up VBUS, mapping of registers address space and power
> @@ -68,29 +86,75 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   ci_hdrc_msm_platdata.usb_phy = phy;
>  
> + reset = devm_reset_control_get(>dev, "core");
> + if (IS_ERR(reset))
> + return PTR_ERR(reset);
> +
> + ci->core_clk = clk = devm_clk_get(>dev, "core");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ci->iface_clk = clk = devm_clk_get(>dev, "iface");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ci->fs_clk = clk = devm_clk_get(>dev, "fs");
> + if (IS_ERR(clk)) {
> + if (PTR_ERR(clk) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + ci->fs_clk = NULL;
> + }
> +
> + ret = clk_prepare_enable(ci->fs_clk);
> + if (ret)
> + return ret;
> +
> + reset_control_assert(reset);
> + usleep_range(1, 12000);
> + reset_control_deassert(reset);
> +
> + clk_disable_unprepare(ci->fs_clk);
> +
> + ret = clk_prepare_enable(ci->core_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(ci->iface_clk);
> + if (ret)
> + goto err_iface;
> +
>   plat_ci = ci_hdrc_add_device(>dev,
>   pdev->resource, pdev->num_resources,
>   _hdrc_msm_platdata);
>   if (IS_ERR(plat_ci)) {
>   dev_err(>dev, "ci_hdrc_add_device failed!\n");
> - return PTR_ERR(plat_ci);
> + ret = PTR_ERR(plat_ci);
> + goto err_mux;
>   }
>  
> - platform_set_drvdata(pdev, plat_ci);
> + ci->ci = plat_ci;
>  
>   pm_runtime_set_active(>dev);
>   pm_runtime_no_callbacks(>dev);
>   pm_runtime_enable(>dev);
>  
>   return 0;
> +
> +err_mux:
> + clk_disable_unprepare(ci->iface_clk);
> +err_iface:
> + clk_disable_unprepare(ci->core_clk);
> + return ret;
>  }
>  
>  static int ci_hdrc_msm_remove(struct platform_device *pdev)
>  {
> - struct platform_device *plat_ci = platform_get_drvdata(pdev);
> + struct ci_hdrc_msm *ci = platform_get_drvdata(pdev);
>  
>   pm_runtime_disable(>dev);
> - ci_hdrc_remove_device(plat_ci);
> + ci_hdrc_remove_device(ci->ci);
> + clk_disable_unprepare(ci->iface_clk);
> + clk_disable_unprepare(ci->core_clk);
>  
>   return 0;
>  }
> -- 

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen


Re: [PATCH] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder

2016-07-10 Thread Hans Verkuil
Hi Tiffany,

My apologies for the delay, but here is my review at last:

On 05/30/2016 09:52 AM, Tiffany Lin wrote:
> This patch add g/s_selection support for MT8173
> 
> Signed-off-by: Tiffany Lin 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c |   74 
> 
>  1 file changed, 74 insertions(+)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> index 6e72d73..23ef9a1 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -630,6 +630,77 @@ static int vidioc_try_fmt_vid_out_mplane(struct file 
> *file, void *priv,
>   return vidioc_try_fmt(f, fmt);
>  }
>  
> +static int vidioc_venc_g_selection(struct file *file, void *priv,
> +  struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + /* crop means compose for output devices */
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + case V4L2_SEL_TGT_CROP:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE:
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + s->r.top = 0;
> + s->r.left = 0;
> + s->r.width = q_data->visible_width;
> + s->r.height = q_data->visible_height;
> +
> + return 0;
> +}
> +
> +static int vidioc_venc_s_selection(struct file *file, void *priv,
> +  struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + case V4L2_SEL_TGT_CROP:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE:
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + s->r.top = 0;
> + s->r.left = 0;
> + q_data->visible_width = s->r.width;
> + q_data->visible_height = s->r.height;

This makes no sense.

See this page:

https://hverkuil.home.xs4all.nl/spec/media.html#selection-api

For the video output direction (memory -> HW encoder) the data source is
the memory, the data sink is the HW encoder. For the video capture direction
(HW encoder -> memory) the data source is the HW encoder and the data sink
is the memory.

Usually for m2m devices the video output direction may support cropping and
the video capture direction may support composing.

It's not clear what you intend here, especially since you set left and right
to 0. That's not what the selection operation is supposed to do.

Regards,

Hans

> +
> + return 0;
> +}
> +
>  static int vidioc_venc_qbuf(struct file *file, void *priv,
>   struct v4l2_buffer *buf)
>  {
> @@ -688,6 +759,9 @@ const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
>  
>   .vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
>   .vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
> +
> + .vidioc_g_selection = vidioc_venc_g_selection,
> + .vidioc_s_selection = vidioc_venc_s_selection,
>  };
>  
>  static int vb2ops_venc_queue_setup(struct vb2_queue *vq,
> 


Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

2016-07-10 Thread Andy Lutomirski
On Jul 9, 2016 1:37 AM, "Ingo Molnar"  wrote:
>
>
> * Dave Hansen  wrote:
>
> > On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> >
> > > So the question is, what is user-space going to do? Do any glibc patches
> > > exist? How are the user-space library side APIs going to look like?
> >
> > My goal at the moment is to get folks enabled to the point that they can 
> > start
> > modifying apps to use pkeys without having to patch their kernels.
> >  I don't have confidence that we can design good high-level userspace 
> > interfaces
> > without seeing some real apps try to use the low-level ones and seeing how 
> > they
> > struggle.
> >
> > I had some glibc code to do the pkey alloc/free operations, but those aren't
> > necessary if we're doing it in the kernel.  Other than getting the syscall
> > wrappers in place, I don't have any immediate plans to do anything in glibc.
> >
> > Was there something you were expecting to see?
>
> Yeah, so (as you probably guessed!) I'm starting to have second thoughts 
> about the
> complexity of the alloc/free/set/get interface I suggested, and Mel's review
> certainly strengthened that feeling.
>
> I have two worries:
>
> 1)
>
> A technical worry I have is that the 'pkey allocation interface' does not 
> seem to
> be taking the per thread property of pkeys into account - while that property
> would be useful for apps. That is a limitation that seems unjustified.
>
> The reason for this is that we are storing the key allocation bitmap in 
> struct_mm,
> in mm->context.pkey_allocation_map - while we should be storing it in 
> task_struct
> or thread_info.

Huh?  Doesn't this have to be per mm?  Sure, PKRU is per thread, but
the page tables are shared.

> 2)
>
> My main worry is that it appears at this stage that we are still pretty far 
> away
> from completely shadowing the hardware pkey state in the kernel - and without 
> that
> we cannot really force user-space to use the 'proper' APIs. They can just use 
> the
> raw instructions, condition them on a CPUID and be done with it: everything 
> can be
> organized in user-space.
>

My vote would be to keep the allocation mechanism but get rid of pkey_set.

Also, I think the debug poisoning feature is overcomplicated.  Let's
just forbid mprotect_key with an unallocated key.

There are still two issues that I think we need to address, though:

1. Signal delivery shouldn't unconditionally clear PKRU.  That's what
the current patches do, and it's unsafe.  I'd rather set PKRU to the
maximally locked down state on signal delivery (except for the
PROT_EXEC key), although that might cause its own set of problems.

2. When thread A allocates a pkey, how does it lock down thread B?

#2 could be addressed by using fully-locked-down as the initial state
post-exec() and copying the state on clone().  Dave, are there any
cases in practice where one thread would allocate a pkey and want
other threads to immediately have access to the memory with that key?

I find myself wondering whether we should stop using XSAVE for PKRU
sooner rather than later.  If we do anything like the above, we
completely lose the init optimization, and the code would be a good
deal simpler if we switched PKRU directly in switch_to and could
therefore treat it like a normal register everywhere else.

--Andy


Re: [PATCH] arm64: defconfig: Enable more IP blocks for Exynos7 and Exynos5433

2016-07-10 Thread Alim Akhtar

Hi Krzysztof,

On 07/09/2016 01:47 AM, Krzysztof Kozlowski wrote:

Enable more drivers for IP blocks for existing Exynos7 and upcoming
Exynos5433:
1. SPI,
2. Watchdog,
3. USB: DWC3, Exynos EHCI and OHCI,
4. Exynos ADC,
5. Samsung PWM.

These are already used by Exynos7 Espresso board or will be used by
Exynos5433 based board.

Signed-off-by: Krzysztof Kozlowski 


Thanks for posting this patch.

Reviewed-by: Alim Akhtar 


---

If there are no objections, I can take it through Samsung SoC tree.
---
  arch/arm64/configs/defconfig | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c05b8badec2c..fe6d6c34323a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -183,6 +183,7 @@ CONFIG_SPI_ORION=y
  CONFIG_SPI_PL022=y
  CONFIG_SPI_QUP=y
  CONFIG_SPI_SPIDEV=m
+CONFIG_SPI_S3C64XX=y
  CONFIG_SPMI=y
  CONFIG_PINCTRL_SINGLE=y
  CONFIG_PINCTRL_MSM8916=y
@@ -202,6 +203,7 @@ CONFIG_THERMAL_EMULATION=y
  CONFIG_EXYNOS_THERMAL=y
  CONFIG_WATCHDOG=y
  CONFIG_RENESAS_WDT=y
+CONFIG_S3C2410_WATCHDOG=y
  CONFIG_MFD_SPMI_PMIC=y
  CONFIG_MFD_SEC_CORE=y
  CONFIG_MFD_HI655X_PMIC=y
@@ -221,18 +223,22 @@ CONFIG_SOUND=y
  CONFIG_SND=y
  CONFIG_SND_SOC=y
  CONFIG_SND_SOC_RCAR=y
+CONFIG_SND_SOC_SAMSUNG=y
  CONFIG_SND_SOC_AK4613=y
  CONFIG_USB=y
  CONFIG_USB_OTG=y
  CONFIG_USB_XHCI_HCD=y
  CONFIG_USB_XHCI_RCAR=y
+CONFIG_USB_EHCI_EXYNOS=y
  CONFIG_USB_EHCI_HCD=y
  CONFIG_USB_EHCI_MSM=y
  CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_OHCI_EXYNOS=y
  CONFIG_USB_OHCI_HCD=y
  CONFIG_USB_OHCI_HCD_PLATFORM=y
  CONFIG_USB_STORAGE=y
  CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
  CONFIG_USB_CHIPIDEA=y
  CONFIG_USB_CHIPIDEA_UDC=y
  CONFIG_USB_CHIPIDEA_HOST=y
@@ -304,6 +310,10 @@ CONFIG_PHY_HI6220_USB=y
  CONFIG_PHY_XGENE=y
  CONFIG_ARM_SCPI_PROTOCOL=y
  CONFIG_ACPI=y
+CONFIG_IIO=y
+CONFIG_EXYNOS_ADC=y
+CONFIG_PWM=y
+CONFIG_PWM_SAMSUNG=y
  CONFIG_EXT2_FS=y
  CONFIG_EXT3_FS=y
  CONFIG_FANOTIFY=y



Re: [PATCH v3 0/9] Add MT8173 Video Decoder Driver

2016-07-10 Thread tiffany lin
Hi Hans,

On Fri, 2016-07-08 at 13:44 +0200, Hans Verkuil wrote:
> On 07/07/2016 12:16 PM, tiffany lin wrote:
> > Hi Hans,
> > 
> > 
> > On Wed, 2016-07-06 at 15:19 +0200, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> I plan to review this patch series on Friday, but one obvious question is
> >> what the reason for these failures is:
> >>
> >>> Input/Output configuration ioctls:
> >>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> >>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> >>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> >>> test VIDIOC_G/S_EDID: OK (Not Supported)
> >>>
> >>> Control ioctls:
> >>> test VIDIOC_QUERYCTRL/MENU: OK
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(357):
> >>>  g_ctrl returned an error (11)
> >>> test VIDIOC_G/S_CTRL: FAIL
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(579):
> >>>  g_ext_ctrls returned an error (11)
> >>> test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
> > These fails are because VIDIOC_G_CTRL and VIDIOC_G_EXT_CTRLS return
> > V4L2_CID_MIN_BUFFERS_FOR_CAPTURE only when dirver in MTK_STATE_HEADER
> > state, or it will return EAGAIN.
> > This could help user space get correct value, not default value that may
> > changed base on media content.
> 
> OK, I really don't like this. I also looked what the s5p-mfc-dec driver does 
> (the only other
> driver currently implementing this), and that returns -EINVAL.
> 
> My proposal would be to change this. If this information isn't known yet, why 
> not
> just return 0 as the value? The doc would have to be updated and (preferably) 
> also
> the s5p-mfc-dec driver. I've added Samsung devs to the Cc list, let me know 
> what you
> think.
> 
Got it. We will return 0 as the value instead EAGAIN.

> > 
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(721):
> >>>  subscribe event for control 'User Controls' failed
> >>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
> > Driver do not support subscribe event for control 'User Controls' for
> > now.
> > Do we need to support this?
> 
> I don't see why this would fail. It's OK to subscribe to such controls, 
> although
> you'll never get an event.
> 
Got it. I will rerun using latest v4l2-compliance test check this.

> >>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> >>> Standard Controls: 2 Private Controls: 0
> >>>
> >>> Format ioctls:
> >>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> >>> test VIDIOC_G/S_PARM: OK (Not Supported)
> >>> test VIDIOC_G_FBUF: OK (Not Supported)
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-formats.cpp(405):
> >>>  expected EINVAL, but got 11 when getting format for buftype 9
> >>> test VIDIOC_G_FMT: FAIL
> > This is because vidioc_vdec_g_fmt only succeed when context is in
> > MTK_STATE_HEADER state, or user space cannot get correct format data
> > using this function.
> 
> Comparing this to s5p-mfc-dec I see that -EINVAL is returned in that case.
> 
> I am not opposed to using EAGAIN in s5p-mfc-dec as well. Marek, Kamil, what is
> your opinion?
> 
> > 
> >>> test VIDIOC_TRY_FMT: OK (Not Supported)
> >>> test VIDIOC_S_FMT: OK (Not Supported)
> >>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> >>>
> >>> Codec ioctls:
> >>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> >>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> >>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> >>>
> >>> Buffer ioctls:
> >>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(500):
> >>>  q.has_expbuf(node)
> > Our OUTPUT and CAPTURE queue support both VB2_DMABUF and VB2_MMAP, user
> > space can select which to use in runtime.
> > So our driver default support v4l2_m2m_ioctl_expbuf functionality.
> > In v4l2-compliance test, it will check v4l2_m2m_ioctl_expbuf only valid
> > when node->valid_memorytype is V4L2_MEMORY_MMAP.
> > So when go through node->valid_memorytype is V4L2_MEMORY_DMABUF, it
> > fail.
> 
> valid_memorytype should have both MMAP and DMABUF flags.
> 
> But v4l-utils-1.6.0 is way too old to be certain it isn't some 
> v4l2-compliance bug
> that has since been fixed.
> 
Got it. I will rerun using master branch to check this.

best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> > 
> > 
> > best regards,
> > Tiffany
> > 
> > 
> > 
> >>> test VIDIOC_EXPBUF: FAIL
> >>>
> >>>
> >>> Total: 38, Succeeded: 33, Failed: 5, Warnings: 0
> >>
> >> If it is due to a bug in 

Linux 4.7-rc7

2016-07-10 Thread Linus Torvalds
We've had a nicely calm week, which is what I expected - the last rc
really was bigger just due to random timing issues, and not some
worrying pattern about this release cycle. Whew.

Anyway, there's a couple of regressions still being looked at, but
unless anything odd happens, this is going to be the last rc. However,
due to my travel schedule, I won't be doing the final 4.7 next
weekend, and people will have two weeks to report (and fix) any
remaining bugs.

Yeah, that's the ticket. My travel schedule isn't screwing anything
up, instead think of it as you guys getting a BONUS WEEK! Yay!

Ok, my travel schedule probably _is_ screwing somebody's plans up, for
which I apologize in advance. And hey, even that planned delay could
obviously change, if somebody finds some real killer bug. But it
doesn't look all that likely, considering that this hasn't been a
particularly big or scary release cycle.

But do go out and test. The appended shortlog gives the details on the
preceding calm week, but the overview is very normal: two thirds
drivers (networking, sound, gpio, misc), with the rest being pretty
evenly split between arch fixes and "misc" (in this case mostly core
kernel, networking, and ecryptfs). But all of it is pretty small.

 Linus

---

Aaron Campbell (1):
  iommu/vt-d: Fix infinite loop in free_all_cpu_cached_iovas

Ajit Pandey (1):
  ASoC: wm5110: Add missing route from OUT3R to SYSCLK

Alan Cox (1):
  ASoC: Intel: atom: fix missing breaks that would cause the wrong
operation to execute

Alan Stern (1):
  SCSI: fix new bug in scsi_dev_info_list string matching

Alexander Shiyan (1):
  ASoC: fsl_ssi: Fix number of words per frame for I2S-slave mode

Arnd Bergmann (1):
  ASoC: hdmi-codec: select CONFIG_HDMI

Aviv Heller (1):
  bonding: fix enslavement slave link notifications

Bard Liao (2):
  ASoC: rt5670: fix HP Playback Volume control
  ASoC: rt5645: fix reg-2f default value.

Ben Skeggs (1):
  drm/nouveau/disp/sor/gf119: select correct sor when poking
training pattern

Bjørn Mork (1):
  cdc_ncm: workaround for EM7455 "silent" data interface

Bob Copeland (1):
  ALSA: hda - fix read before array start

Bob Liu (1):
  xen-blkfront: save uncompleted reqs in blkfront_resume()

Borislav Petkov (1):
  x86/amd_nb: Fix boot crash on non-AMD systems

Brian King (1):
  ipr: Clear interrupt on croc/crocodile when running with LSI

Bruno Prémont (1):
  qla2xxx: Fix NULL pointer deref in QLA interrupt

Charles Keepax (1):
  ASoC: wm5102: Correct supported channels on trace compressed DAI

Chris J Arges (1):
  ecryptfs: fix spelling mistakes

Christophe JAILLET (1):
  ALSA: echoaudio: Fix memory allocation

Christophe Jaillet (1):
  fsl/fman: fix error handling

Colin Pitrat (1):
  gpio: sch: Fix Oops on module load on Asus Eee PC 1201

Dan Carpenter (1):
  platform/chrome: cros_ec_dev - double fetch bug in ioctl

Daniel Borkmann (1):
  macsec: set actual real device for xmit when !protect_frames

Daniel Jurgens (5):
  net/mlx5: Fix incorrect page count when in internal error
  net/mlx5: Fix wait_vital for VFs and remove fixed sleep
  net/mlx5e: Timeout if SQ doesn't flush during close
  net/mlx5e: Implement ndo_tx_timeout callback
  net/mlx5e: Handle RQ flush in error cases

David Daney (1):
  MIPS: Fix page table corruption on THP permission changes.

David S. Miller (2):
  packet: Use symmetric hash for PACKET_FANOUT_HASH.
  Revert "fsl/fman: fix error handling"

Eric Dumazet (1):
  bonding: prevent out of bound accesses

Fabio Estevam (1):
  ASoC: ak4613: Remove owner assignment from platform_driver

Florian Fainelli (1):
  net: bcmsysport: Device stats are unsigned long

Ganapatrao Kulkarni (1):
  arm64: Enable workaround for Cavium erratum 27456 on thunderx-81xx

Ganesh Goudar (1):
  cxgb4: update latest firmware version supported

Geert Uytterhoeven (2):
  ASoC: wm8940: Enable cache usage to fix crashes on resume
  ASoC: ak4613: Enable cache usage to fix crashes on resume

Haishuang Yan (1):
  geneve: fix max_mtu setting

Huang Rui (2):
  drm/amd/powerplay: fix incorrect voltage table value for polaris10
  drm/amd/powerplay: fix incorrect voltage table value for tonga

Hugh Dickins (1):
  tmpfs: fix regression hang in fallocate undo

James Morse (1):
  arm64: kernel: Save and restore UAO and addr_limit on exception entry

Jan Beulich (4):
  xenbus: don't BUG() on user mode induced condition
  xenbus: don't bail early from xenbus_dev_request_and_reply()
  xenbus: simplify xenbus_dev_request_and_reply()
  xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7

Janusz Krzysztofik (1):
  ASoC: cx20442: set tty->receiver_room in v253_open

Jarod Wilson (1):
  e1000e: keep Rx/Tx HW_VLAN_CTAG in sync

Jeff Mahoney (2):
  Revert "ecryptfs: forbid opening files without mmap handler"
  

RE: [PATCH v2 08/17] libnvdimm: introduce nvdimm_flush() and nvdimm_has_flush()

2016-07-10 Thread Li, Philip


> -Original Message-
> From: Williams, Dan J
> Sent: Sunday, July 10, 2016 1:01 PM
> To: lkp <l...@intel.com>
> Cc: kbuild-...@01.org; linux-nvd...@lists.01.org; linux-fsdevel  fsde...@vger.kernel.org>; Linux ACPI <linux-a...@vger.kernel.org>; Ross
> Zwisler <ross.zwis...@linux.intel.com>; Christoph Hellwig <h...@lst.de>; 
> linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2 08/17] libnvdimm: introduce nvdimm_flush() and
> nvdimm_has_flush()
> 
> On Sat, Jul 9, 2016 at 9:47 PM, kbuild test robot <l...@intel.com> wrote:
> > Hi,
> >
> > [auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
> > [also build test ERROR on next-20160708]
> > [cannot apply to v4.7-rc6]
> > [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/Dan-Williams/replace-
> pcommit-with-ADR-or-directed-flushing/20160710-113558
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-for-next
> > config: i386-randconfig-r0-201628 (attached as .config)
> > compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=i386
> 
> Hi kbuild team,
> 
> Can we add an "i386 allmodconfig" build to the standard "BUILD
> SUCCESS" notification runs?  I had two positive build results on a

Thanks, yes, currently i386 allmodconfig has been covered for all kinds of test 
including
kbiuld on registered repo or LKML patches. If the test is running on a repo for 
its new commits,
a BUILD SUCCESS mail, it will list the current coverage by the time the mail is 
sent out like

m32r   m32104ut_defconfig
m32r mappi3.smp_defconfig
m32r opsput_defconfig
m32r   usrv_defconfig
xtensa   common_defconfig
xtensa  iss_defconfig
i386 allmodconfig
mips   jz4740
mips  allnoconfig

> private branch prior to posting this series, but the i386 runs did not
> build the nvdimm sub-system.
> 
> In any event this report is valid, so thank you for that!
> 
> 
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/nvdimm/region_devs.c: In function 'nvdimm_flush':
> >>> drivers/nvdimm/region_devs.c:887:4: error: implicit declaration of 
> >>> function
> 'writeq' [-Werror=implicit-function-declaration]
> >writeq(1, ndrd->flush_wpq[i][0]);
> >^~
> >cc1: some warnings being treated as errors
> >
> > vim +/writeq +887 drivers/nvdimm/region_devs.c
> >
> >881   * writes to avoid the cache via arch_memcpy_to_pmem().  The
> >882   * final wmb() ensures ordering for the NVDIMM flush write.
> >883   */
> >884  wmb();
> >885  for (i = 0; i < nd_region->ndr_mappings; i++)
> >886  if (ndrd->flush_wpq[i][0])
> >  > 887  writeq(1, ndrd->flush_wpq[i][0]);
> >888  wmb();
> >889  }
> >890  EXPORT_SYMBOL_GPL(nvdimm_flush);
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation



Re: [PATCH 3/3] net: hisilicon: Add Fast Ethernet MAC driver

2016-07-10 Thread Dongpo Li
Hi Arnd,

On 2016/6/28 17:34, Arnd Bergmann wrote:
> On Tuesday, June 28, 2016 5:21:19 PM CEST Dongpo Li wrote:
>> On 2016/6/15 5:20, Arnd Bergmann wrote:
>>> On Tuesday, June 14, 2016 9:17:44 PM CEST Li Dongpo wrote:
 On 2016/6/13 17:06, Arnd Bergmann wrote:
> On Monday, June 13, 2016 2:07:56 PM CEST Dongpo Li wrote:
> You tx function uses BQL to optimize the queue length, and that
> is great. You also check xmit reclaim for rx interrupts, so
> as long as you have both rx and tx traffic, this should work
> great.
>
> However, I notice that you only have a 'tx fifo empty'
> interrupt triggering the napi poll, so I guess on a tx-only
> workload you will always end up pushing packets into the
> queue until BQL throttles tx, and then get the interrupt
> after all packets have been sent, which will cause BQL to
> make the queue longer up to the maximum queue size, and that
> negates the effect of BQL.
>
> Is there any way you can get a tx interrupt earlier than
> this in order to get a more balanced queue, or is it ok
> to just rely on rx packets to come in occasionally, and
> just use the tx fifo empty interrupt as a fallback?
>
 In tx direction, there are only two kinds of interrupts, 'tx fifo empty'
 and 'tx one packet finish'. I didn't use 'tx one packet finish' because
 it would lead to high hardware interrupts rate. This has been verified in
 our chips. It's ok to just use tx fifo empty interrupt.
>>>
>>> I'm not convinced by the explanation, I don't think that has anything
>>> to do with the hardware design, but instead is about the correctness
>>> of the BQL logic with your driver.
>>>
>>> Maybe your xmit function can do something like
>>>
>>>   if (dql_avail(netdev_get_tx_queue(dev, 0)->dql) < 0)
>>>   enable per-packet interrupt
>>>   else
>>>   use only fifo-empty interrupt
>>>
>>> That way, you don't get a lot of interrupts when the system is
>>> in a state of packets being received and sent continuously,
>>> but if you get to the point where your tx queue fills up
>>> and no rx interrupts arrive, you don't have to wait for it
>>> to become completely empty before adding new packets, and
>>> BQL won't keep growing the queue.
>>>
>> Hi, Arnd
>> I tried enable per-packet interrupt when tx queue full in xmit function
>> and disable it in NAPI poll. But the number of interrupts are a little
>> bigger than only using fifo-empty interrupt.
> 
> Right, I'd expect that to be the case, it basically means that the
> algorithm works as expected.
> 
> Just to be sure you didn't have extra interrupts: you only enable the
> per-packet interrupts if interrupts are currently enabled, not in
> NAPI polling mode, right?
> 
Sorry so long to reply to you. I use the per-packet interrupt like this:
In my xmit function,
if (hardware tx fifo is full) {
enable tx per-packet interrupt;
netif_stop_queue(dev);
return NETDEV_TX_BUSY;
}

In interrupt handle function,
if (interrupt is tx per-packet or tx fifo-empty or rx) {
disable tx per-packet interrupt;
napi_schedule(>napi);
}
We disable tx per-packet interrupt anyway because the NAPI poll will reclaim
the tx fifo.
When the NAPI poll completed, it will only enable the tx fifo-empty interrupt
and rx interrupt except the tx per-packet interrupt.

Is this solution okay?

>> The other hand, this is a fast ethernet MAC. Its maximum speed is 100Mbps.
>> This speed is very easily achived and the efficiency of the BQL is not
>> so important. What we focus on is the lower cpu utilization.
>> So I think it is okay to just use the tx fifo empty interrupt.
> 
> BQL is not about efficiency, it's about keeping the latency down, which
> is at least as important for low-throughput devices as it is for faster
> ones. I don't think that disabling BQL here would be the right answer,
> you'd just end up with the maximum TX queue length all the time.
> 
> Your queue length is 12 packets of 1500 bytes, meaning that you have 1.4ms
> of latency at 100mbit/s rate, or 14ms for 10mbit/s. This is much less
> than most, but it's probably still worth using BQL on it.
> 
I spent some time reading some articles and the goal of BQL is more clear to me.
BQL is designed to get the minimum buffer size that will not make hardware 
under starvation.
The goal is to reduce latency without the side effect of throughput.
Thanks for your explanation.

>   Arnd
> 
> .
> 

Regards,
Dongpo

.



Re: [PATCH v2 12/22] usb: chipidea: msm: Rely on core to override AHBBURST

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:03PM -0700, Stephen Boyd wrote:
> The core framework already handles setting this parameter with a
> platform quirk. Add the appropriate flag so that we always set
> AHBBURST to 0. Technically DT should be doing this, but we always
> do it for msm chipidea devices so setting the flag in the driver
> works just as well.

You may need to mention if the platform needs to set value rather
than 0, it needs to "ahb-burst-config" at dts, others are ok.

Acked-by: Peter Chen 

> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 89c1a02d69b5..719b20caf88e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -24,7 +24,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> - writel(0, USB_AHBBURST);
>   /* use AHB transactor, allow posted data writes */
>   writel(0x8, USB_AHBMODE);
>   usb_phy_init(ci->usb_phy);
> @@ -47,7 +46,8 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
>   .name   = "ci_hdrc_msm",
>   .capoffset  = DEF_CAPOFFSET,
>   .flags  = CI_HDRC_REGS_SHARED |
> -   CI_HDRC_DISABLE_STREAMING,
> +   CI_HDRC_DISABLE_STREAMING |
> +   CI_HDRC_OVERRIDE_AHB_BURST,
>  
>   .notify_event   = ci_hdrc_msm_notify_event,
>  };
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen


Re: [lkp] [ACPI / APEI] a3e2acc5e3: kmsg.BERT:Can't_request_iomem_region<#-#>

2016-07-10 Thread Tony Luck
I'm very surprised that there was a BERT table on an Atom machine. More details 
about the machine please. Also BIOS version.

Sent from my iPhone

> On Jul 10, 2016, at 18:43, kernel test robot  wrote:
> 
> 
> FYI, we noticed the following commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit a3e2acc5e37b22b6808a0b8e46887c3577de9c9e ("ACPI / APEI: Add Boot Error 
> Record Table (BERT) support")
> 
> in testcase: locktorture
> with following parameters: runtime=300s
> 
> on test machine: Atom with 8G memory
> 
> caused below changes:
> 
> 
> [   12.317148] BERT: Can't request iomem region 
> .
> 
> 
> 
> To reproduce:
> 
>git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>cd lkp-tests
>bin/lkp install job.yaml  # job file is attached in this email
>bin/lkp run job.yaml
> 
> 
> 
> Thanks,
> Xiaolong
> 
> 
> 


Re: [PATCH v2 11/22] usb: chipidea: msm: Mark device as runtime pm active

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:02PM -0700, Stephen Boyd wrote:
> We're not properly marking the glue layer/wrapper device as
> runtime active, so runtime PM believes that the hardware state is
> inactive when we call pm_runtime_enable() in this driver. This
> causes a problem when the glue layer has a power domain
> associated with it, because runtime PM will go and disable the
> power domain to match the 'inactive' state of the device. Let's
> mark the device as active so that runtime PM doesn't improperly
> power down this device when it's actually active.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 3889809fd0c4..89c1a02d69b5 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -80,6 +80,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   platform_set_drvdata(pdev, plat_ci);
>  
> + pm_runtime_set_active(>dev);
>   pm_runtime_no_callbacks(>dev);
>   pm_runtime_enable(>dev);
>  

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen


Re: [PATCH v4 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

2016-07-10 Thread Dave Young
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
> implementation to find free memory for the purgatory stack.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> ---
>  include/linux/kexec.h |  1 +
>  kernel/kexec_file.c   | 25 -
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index ff5fa7707bd7..803f563df81d 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -174,6 +174,7 @@ struct kexec_buf {
>  int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
>  int (*func)(u64, u64, void *));
>  extern int kexec_add_buffer(struct kexec_buf *kbuf);
> +int kexec_locate_mem_hole(struct kexec_buf *kbuf);
>  #endif /* CONFIG_KEXEC_FILE */
>  
>  struct kimage {
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 82ccfc4ee97e..3125d1689712 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -450,6 +450,23 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
>  }
>  
>  /**
> + * kexec_locate_mem_hole - find free memory for the purgatory or the next 
> kernel
> + * @kbuf:Parameters for the memory search.
> + *
> + * On success, kbuf->mem will have the start address of the memory region 
> found.
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> +{
> + int ret;
> +
> + ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> +
> + return ret == 1 ? 0 : -EADDRNOTAVAIL;
> +}
> +
> +/**
>   * kexec_add_buffer - place a buffer in a kexec segment
>   * @kbuf:Buffer contents and memory parameters.
>   *
> @@ -489,11 +506,9 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
>   kbuf->buf_align = max(kbuf->buf_align, PAGE_SIZE);
>  
>   /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> - if (ret != 1) {
> - /* A suitable memory range could not be found for buffer */
> - return -EADDRNOTAVAIL;
> - }
> + ret = kexec_locate_mem_hole(kbuf);
> + if (ret)
> + return ret;
>  
>   /* Found a suitable memory range */
>   ksegment = >image->segment[kbuf->image->nr_segments];
> -- 
> 1.9.1
> 

Acked-by: Dave Young 

Thanks
Dave


Re: [PATCH v14 3/8] perf tests: Add testcase for auxiliary evlist

2016-07-10 Thread Wangnan (F)



On 2016/7/8 22:48, Jiri Olsa wrote:

On Thu, Jul 07, 2016 at 05:34:44AM +, Wang Nan wrote:

SNIP


ret = TEST_FAIL;
-   err = do_test(evlist, opts.mmap_pages, _count,
+   err = do_test(evlist, aux_evlist, opts.mmap_pages,
+ _sample_count, _sample_count,
  _count);
if (err != TEST_OK)
goto out_delete_evlist;
  
-	if ((sample_count != NR_ITERS) || (comm_count != NR_ITERS)) {

-   pr_err("Unexpected counter: sample_count=%d, comm_count=%d\n",
-  sample_count, comm_count);
+   if (enter_sample_count != exit_sample_count) {
+   pr_err("Unexpected counter: enter_sample_count=%d, 
exit_sample_count=%d\n",
+  enter_sample_count, exit_sample_count);
+   goto out_delete_evlist;
+   }
+
+   if ((exit_sample_count != NR_ITERS) || (comm_count != NR_ITERS)) {
+   pr_err("Unexpected counter: exit_sample_count=%d, 
comm_count=%d\n",
+  exit_sample_count, comm_count);
goto out_delete_evlist;
}
  
-	err = do_test(evlist, 1, _count, _count);

+   err = do_test(evlist, aux_evlist, 1, , , );

why dont you test numbers for 1 page mmap?  seems like the data would fit..
is the purpose just to check if we can map just 1 page?


Data won't fit. 1 page map make sure the buffer is overwritten.

Thank you.


thanks,
jirka





Re: [PATCH v4 2/9] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

2016-07-10 Thread Dave Young
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Adapt all callers to the new function prototype.
> 
> In addition, change the type of kexec_buf.buffer from char * to void *.
> There is no particular reason for it to be a char *, and the change
> allows us to get rid of 3 existing casts to char * in the code.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> ---
>  arch/x86/kernel/crash.c   | 37 
>  arch/x86/kernel/kexec-bzimage64.c | 48 +++--
>  include/linux/kexec.h |  8 +---
>  kernel/kexec_file.c   | 88 
> ++-
>  4 files changed, 87 insertions(+), 94 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ef978d69c22..dc026ea361dc 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -615,9 +615,9 @@ static int determine_backup_region(u64 start, u64 end, 
> void *arg)
>  
>  int crash_load_segments(struct kimage *image)
>  {
> - unsigned long src_start, src_sz, elf_sz;
> - void *elf_addr;
>   int ret;
> + struct kexec_buf kbuf = { .image = image, .buf_min = 0,
> +   .buf_max = ULONG_MAX, .top_down = false };
>  
>   /*
>* Determine and load a segment for backup area. First 640K RAM
> @@ -631,43 +631,44 @@ int crash_load_segments(struct kimage *image)
>   if (ret < 0)
>   return ret;
>  
> - src_start = image->arch.backup_src_start;
> - src_sz = image->arch.backup_src_sz;
> -
>   /* Add backup segment. */
> - if (src_sz) {
> + if (image->arch.backup_src_sz) {
> + kbuf.buffer = _zero_bytes;
> + kbuf.bufsz = sizeof(crash_zero_bytes);
> + kbuf.memsz = image->arch.backup_src_sz;
> + kbuf.buf_align = PAGE_SIZE;
>   /*
>* Ideally there is no source for backup segment. This is
>* copied in purgatory after crash. Just add a zero filled
>* segment for now to make sure checksum logic works fine.
>*/
> - ret = kexec_add_buffer(image, (char *)_zero_bytes,
> -sizeof(crash_zero_bytes), src_sz,
> -PAGE_SIZE, 0, -1, 0,
> ->arch.backup_load_addr);
> + ret = kexec_add_buffer();
>   if (ret)
>   return ret;
> + image->arch.backup_load_addr = kbuf.mem;
>   pr_debug("Loaded backup region at 0x%lx backup_start=0x%lx 
> memsz=0x%lx\n",
> -  image->arch.backup_load_addr, src_start, src_sz);
> +  image->arch.backup_load_addr,
> +  image->arch.backup_src_start, kbuf.memsz);
>   }
>  
>   /* Prepare elf headers and add a segment */
> - ret = prepare_elf_headers(image, _addr, _sz);
> + ret = prepare_elf_headers(image, , );
>   if (ret)
>   return ret;
>  
> - image->arch.elf_headers = elf_addr;
> - image->arch.elf_headers_sz = elf_sz;
> + image->arch.elf_headers = kbuf.buffer;
> + image->arch.elf_headers_sz = kbuf.bufsz;
>  
> - ret = kexec_add_buffer(image, (char *)elf_addr, elf_sz, elf_sz,
> - ELF_CORE_HEADER_ALIGN, 0, -1, 0,
> - >arch.elf_load_addr);
> + kbuf.memsz = kbuf.bufsz;
> + kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> + ret = kexec_add_buffer();
>   if (ret) {
>   vfree((void *)image->arch.elf_headers);
>   return ret;
>   }
> + image->arch.elf_load_addr = kbuf.mem;
>   pr_debug("Loaded ELF headers at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> -  image->arch.elf_load_addr, elf_sz, elf_sz);
> +  image->arch.elf_load_addr, kbuf.bufsz, kbuf.bufsz);
>  
>   return ret;
>  }
> diff --git a/arch/x86/kernel/kexec-bzimage64.c 
> b/arch/x86/kernel/kexec-bzimage64.c
> index f2356bda2b05..4b3a75329fb6 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -331,17 +331,17 @@ static void *bzImage64_load(struct kimage *image, char 
> *kernel,
>  
>   struct setup_header *header;
>   int setup_sects, kern16_size, ret = 0;
> - unsigned long setup_header_size, params_cmdline_sz, params_misc_sz;
> + unsigned long setup_header_size, params_cmdline_sz;
>   struct boot_params *params;
>   unsigned long bootparam_load_addr, kernel_load_addr, initrd_load_addr;
>   unsigned long purgatory_load_addr;
> - unsigned long kernel_bufsz, kernel_memsz, kernel_align;
> - char *kernel_buf;
>   struct bzimage64_data *ldata;
>   struct kexec_entry64_regs 

Re: [PATCH v4 1/9] kexec_file: Allow arch-specific memory walking for kexec_add_buffer

2016-07-10 Thread Dave Young
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Allow architectures to specify a different memory walking function for
> kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but
> PowerPC uses the memblock subsystem.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> ---
>  include/linux/kexec.h   | 29 -
>  kernel/kexec_file.c | 30 ++
>  kernel/kexec_internal.h | 16 
>  3 files changed, 50 insertions(+), 25 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index e8acb2b43dd9..2549a99a748c 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -146,7 +146,34 @@ struct kexec_file_ops {
>   kexec_verify_sig_t *verify_sig;
>  #endif
>  };
> -#endif
> +
> +/**
> + * struct kexec_buf - parameters for finding a place for a buffer in memory
> + * @image:   kexec image in which memory to search.
> + * @buffer:  Contents which will be copied to the allocated memory.
> + * @bufsz:   Size of @buffer.
> + * @mem: On return will have address of the buffer in memory.
> + * @memsz:   Size for the buffer in memory.
> + * @buf_align:   Minimum alignment needed.
> + * @buf_min: The buffer can't be placed below this address.
> + * @buf_max: The buffer can't be placed above this address.
> + * @top_down:Allocate from top of memory.
> + */
> +struct kexec_buf {
> + struct kimage *image;
> + char *buffer;
> + unsigned long bufsz;
> + unsigned long mem;
> + unsigned long memsz;
> + unsigned long buf_align;
> + unsigned long buf_min;
> + unsigned long buf_max;
> + bool top_down;
> +};
> +
> +int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> +int (*func)(u64, u64, void *));
> +#endif /* CONFIG_KEXEC_FILE */
>  
>  struct kimage {
>   kimage_entry_t head;
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 01ab82a40d22..9c0c565a08db 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -428,6 +428,27 @@ static int locate_mem_hole_callback(u64 start, u64 end, 
> void *arg)
>   return locate_mem_hole_bottom_up(start, end, kbuf);
>  }
>  
> +/**
> + * arch_kexec_walk_mem - call func(data) on free memory regions
> + * @kbuf:Context info for the search. Also passed to @func.
> + * @func:Function to call for each memory region.
> + *
> + * Return: The memory walk will stop when func returns a non-zero value
> + * and that value will be returned. If all free regions are visited without
> + * func returning non-zero, then zero will be returned.
> + */
> +int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> +int (*func)(u64, u64, void *))
> +{
> + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> + return walk_iomem_res_desc(crashk_res.desc,
> +IORESOURCE_SYSTEM_RAM | 
> IORESOURCE_BUSY,
> +crashk_res.start, crashk_res.end,
> +kbuf, func);
> + else
> + return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
> +}
> +
>  /*
>   * Helper function for placing a buffer in a kexec segment. This assumes
>   * that kexec_mutex is held.
> @@ -474,14 +495,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer, 
> unsigned long bufsz,
>   kbuf->top_down = top_down;
>  
>   /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - if (image->type == KEXEC_TYPE_CRASH)
> - ret = walk_iomem_res_desc(crashk_res.desc,
> - IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
> - crashk_res.start, crashk_res.end, kbuf,
> - locate_mem_hole_callback);
> - else
> - ret = walk_system_ram_res(0, -1, kbuf,
> -   locate_mem_hole_callback);
> + ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
>   if (ret != 1) {
>   /* A suitable memory range could not be found for buffer */
>   return -EADDRNOTAVAIL;
> diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> index 0a52315d9c62..4cef7e4706b0 100644
> --- a/kernel/kexec_internal.h
> +++ b/kernel/kexec_internal.h
> @@ -20,22 +20,6 @@ struct kexec_sha_region {
>   unsigned long len;
>  };
>  
> -/*
> - * Keeps track of buffer parameters as provided by caller for requesting
> - * memory placement of buffer.
> - */
> -struct kexec_buf {
> - struct kimage *image;
> - char *buffer;
> - unsigned long bufsz;
> - unsigned long mem;
> - unsigned long memsz;
> - unsigned long buf_align;
> - unsigned long buf_min;
> - unsigned long buf_max;
> - bool top_down;  /* allocate from top of memory hole */
> -};
> -
>  void 

linux-next: build failure after merge of the drm-msm tree

2016-07-10 Thread Stephen Rothwell
Hi Rob,

After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .hw_params = msm_hdmi_audio_hw_params,
   ^
drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: note: (near initialization for 
'msm_hdmi_audio_codec_ops.hw_params')
drivers/gpu/drm/msm/hdmi/hdmi.c:524:20: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .audio_shutdown = msm_hdmi_audio_shutdown,
^
drivers/gpu/drm/msm/hdmi/hdmi.c:524:20: note: (near initialization for 
'msm_hdmi_audio_codec_ops.audio_shutdown')

Caused by commit

  bf714255fed7 ("drm: msm: Add ASoC generic hdmi audio codec support.")

interacting with commit

  efc9194bcff8 ("ASoC: hdmi-codec: callback function will be called with 
private data")

from the sound-asoc (and drm) trees.

I have added this merge fix patch for today (dave will need something
like this when he merges your tree):

From: Stephen Rothwell 
Date: Mon, 11 Jul 2016 13:16:23 +1000
Subject: [PATCH] drm: msm: fix up for "ASoC: hdmi-codec: callback function
 will be called with private data"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index aada35547eca..33bf52c6b312 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -438,7 +438,7 @@ static int msm_hdmi_get_gpio(struct device_node *of_node, 
const char *name)
 /*
  * HDMI audio codec callbacks
  */
-static int msm_hdmi_audio_hw_params(struct device *dev,
+static int msm_hdmi_audio_hw_params(struct device *dev, void *data,
struct hdmi_codec_daifmt *daifmt,
struct hdmi_codec_params *params)
 {
@@ -512,7 +512,7 @@ static int msm_hdmi_audio_hw_params(struct device *dev,
return 0;
 }
 
-static void msm_hdmi_audio_shutdown(struct device *dev)
+static void msm_hdmi_audio_shutdown(struct device *dev, void *data)
 {
struct hdmi *hdmi = dev_get_drvdata(dev);
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell


RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-10 Thread Zheng, Lv
Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> Hi,
> 
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never reports lid state. As a proxy layer acting between, ACPI
> button
> > driver is not able to handle all such cases, but need to re-define the
> > usage model of the ACPI lid. That is:
> > 1. It's initial state is not reliable;
> > 2. There may not be open event;
> > 3. Userspace should only take action against the close event which is
> >reliable, always sent after a real lid close.
> > This patch adds documentation of the usage model.
> >
> > Link: https://lkml.org/2016/3/7/460
> > Link: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > Cc: Benjamin Tissoires 
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >
> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
> lid.txt
> > new file mode 100644
> > index 000..7e4f7ed
> > --- /dev/null
> > +++ b/Documentation/acpi/acpi-lid.txt
> > @@ -0,0 +1,62 @@
> > +Usage Model of the ACPI Control Method Lid Device
> > +
> > +Copyright (C) 2016, Intel Corporation
> > +Author: Lv Zheng 
> > +
> > +
> > +Abstract:
> > +
> > +Platforms containing lids convey lid state (open/close) to OSPMs using
> a
> > +control method lid device. To implement this, the AML tables issue
> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> > +changed. The _LID control method for the lid device must be
> implemented to
> > +report the "current" state of the lid as either "opened" or "closed".
> > +
> > +This document describes the restrictions and the expections of the
> Linux
> > +ACPI lid device driver.
> > +
> > +
> > +1. Restrictions of the returning value of the _LID control method
> > +
> > +The _LID control method is described to return the "current" lid state.
> > +However the word of "current" has ambiguity, many AML tables return
> the lid
> > +state upon the last lid notification instead of returning the lid state
> > +upon the last _LID evaluation. There won't be difference when the _LID
> > +control method is evaluated during the runtime, the problem is its
> initial
> > +returning value. When the AML tables implement this control method
> with
> > +cached value, the initial returning value is likely not reliable. There are
> > +simply so many examples always retuning "closed" as initial lid state.
> > +
> > +2. Restrictions of the lid state change notifications
> > +
> > +There are many AML tables never notifying when the lid device state is
> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > +"closed" when the lid state is changed to "closed". This is normally used
> > +to trigger some system power saving operations on Windows. Since it is
> > +fully tested, this notification is reliable for all AML tables.
> > +
> > +3. Expections for the userspace users of the ACPI lid device driver
> > +
> > +The userspace programs should stop relying on
> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> > +used for the validation purpose.
> 
> I'd say: this file actually calls the _LID method described above. And
> given the previous explanation, it is not reliable enough on some
> platforms. So it is strongly advised for user-space program to not
> solely rely on this file to determine the actual lid state.
[Lv Zheng] 
OK.

> 
> > +
> > +New userspace programs should rely on the lid "closed" notification to
> > +trigger some power saving operations and may stop taking actions
> according
> > +to the lid "opened" notification. A new input switch event -
> SW_ACPI_LID is
> > +prepared for the new userspace to implement this ACPI control method
> lid
> > +device specific logics.
> 
> That's not entirely what we discussed before (to prevent regressions):
> - if the device doesn't have reliable LID switch state, then there
> would be the new input event, and so userspace should only rely on
> opened notifications.
> - if the device has reliable switch information, the new input event
> should not be exported and userspace knows that the current input
> switch event is reliable.
> 
> Also, using a new "switch" event is a terrible idea. Switches have a
> state (open/close) and you are using this to forward a single open
> event. So using a switch just allows you to say to userspace you are
> using the "new" LID meaning, but you'll still have to manually reset
> the switch and you will have to document how this 

Re: [PATCH v2 10/22] usb: chipidea: Add support for ULPI PHY bus

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:01PM -0700, Stephen Boyd wrote:
> Some phys for the chipidea controller are controlled via the ULPI
> viewport. Add support for the ULPI bus so that these sorts of
> phys can be probed and read/written automatically without having
> to duplicate the viewport logic in each phy driver.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Cc: Heikki Krogerus 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/Kconfig  |   7 +++
>  drivers/usb/chipidea/Makefile |   1 +
>  drivers/usb/chipidea/ci.h |  22 
>  drivers/usb/chipidea/core.c   |  31 +---
>  drivers/usb/chipidea/ulpi.c   | 113 
> ++
>  5 files changed, 168 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/usb/chipidea/ulpi.c
> 
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 3644a3500b70..4f8c342a8865 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -37,4 +37,11 @@ config USB_CHIPIDEA_HOST
> Say Y here to enable host controller functionality of the
> ChipIdea driver.
>  
> +config USB_CHIPIDEA_ULPI
> + bool "ChipIdea ULPI PHY support"
> + depends on USB_ULPI_BUS=y || USB_ULPI_BUS=USB_CHIPIDEA
> + help
> +   Say Y here if you have a ULPI PHY attached to your ChipIdea
> +   controller.
> +
>  endif
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 518e445476c3..39fca5715ed3 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -4,6 +4,7 @@ ci_hdrc-y := core.o otg.o debug.o
>  ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC)   += udc.o
>  ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)  += host.o
>  ci_hdrc-$(CONFIG_USB_OTG_FSM)+= otg_fsm.o
> +ci_hdrc-$(CONFIG_USB_CHIPIDEA_ULPI)  += ulpi.o
>  
>  # Glue/Bridge layers go here
>  
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 05bc4d631cb9..637dd7675e71 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -18,6 +18,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  
> /**
>   * DEFINE
> @@ -52,6 +54,7 @@ enum ci_hw_regs {
>   OP_ENDPTLISTADDR,
>   OP_TTCTRL,
>   OP_BURSTSIZE,
> + OP_ULPI_VIEWPORT,
>   OP_PORTSC,
>   OP_DEVLC,
>   OP_OTGSC,
> @@ -187,6 +190,8 @@ struct hw_bank {
>   * @test_mode: the selected test mode
>   * @platdata: platform specific information supplied by parent device
>   * @vbus_active: is VBUS active
> + * @ulpi: pointer to ULPI device, if any
> + * @ulpi_ops: ULPI read/write ops for this device
>   * @phy: pointer to PHY, if any
>   * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
>   * @hcd: pointer to usb_hcd for ehci host driver
> @@ -236,6 +241,10 @@ struct ci_hdrc {
>  
>   struct ci_hdrc_platform_data*platdata;
>   int vbus_active;
> +#ifdef CONFIG_USB_CHIPIDEA_ULPI
> + struct ulpi *ulpi;
> + struct ulpi_ops ulpi_ops;
> +#endif
>   struct phy  *phy;
>   /* old usb_phy interface */
>   struct usb_phy  *usb_phy;
> @@ -418,6 +427,17 @@ static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
>  #endif
>  }
>  
> +#if IS_ENABLED(CONFIG_USB_CHIPIDEA_ULPI)
> +int ci_ulpi_init(struct ci_hdrc *ci);
> +void ci_ulpi_exit(struct ci_hdrc *ci);
> +int ci_ulpi_resume(struct ci_hdrc *ci);
> +#else
> +static inline int ci_ulpi_init(struct ci_hdrc *ci) { return 0; }
> +static inline void ci_ulpi_exit(struct ci_hdrc *ci) { }
> +static inline int ci_ulpi_resume(struct ci_hdrc *ci) { return 0; }
> +#endif
> +
> +

One more blank line

>  u32 hw_read_intr_enable(struct ci_hdrc *ci);
>  
>  u32 hw_read_intr_status(struct ci_hdrc *ci);
> @@ -428,6 +448,8 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
>  
>  u8 hw_port_test_get(struct ci_hdrc *ci);
>  
> +void hw_phymode_configure(struct ci_hdrc *ci);
> +
>  void ci_platform_configure(struct ci_hdrc *ci);
>  
>  int dbg_create_files(struct ci_hdrc *ci);
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 532085a096d9..f144e1bbcc82 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -86,6 +86,7 @@ static const u8 ci_regs_nolpm[] = {
>   [OP_ENDPTLISTADDR]  = 0x18U,
>   [OP_TTCTRL] = 0x1CU,
>   [OP_BURSTSIZE]  = 0x20U,
> + [OP_ULPI_VIEWPORT]  = 0x30U,
>   [OP_PORTSC] = 0x44U,
>   [OP_DEVLC]  = 0x84U,
>   [OP_OTGSC]  = 0x64U,
> @@ -110,6 +111,7 @@ static const u8 ci_regs_lpm[] = {
>   [OP_ENDPTLISTADDR]  = 0x18U,
>   [OP_TTCTRL] = 

Re: [lkp] [ext4] 5405511e1a: ltp.acl_test01.fail]

2016-07-10 Thread Theodore Ts'o
On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
> 
> FYI, we noticed the following commit:
> 
> https://github.com/0day-ci/linux 
> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number of 
> meta clusters in group")

Hi, many thanks for the report.  One question -- is there some way the
reporting could be speeded up?  Vegard's patch was sent late on the
7th, and it looks like it hit the 0day-ci git repo a few hours later
on the 8th, and was run early in the morning Chinese time.  Was the
delay until the 11th due to the weekend and the desire to have a human
sanity check the result?  Is that because there was a concern that
there would be too many false positives?

Also, if there was some way the 0day robot report could include a
In-Reply-To: header to the patch being sent to the mailing list (in
this case: <577eb740.10...@oracle.com>), it would make this even
*more* useful.


Vegard, I'm guessing you didn't have a chance to test your patch
before you sent it to the list?

bit_max = ext4_num_clusters_in_group(sb, i);
if ((bit_max >> 3) >= sb->s_blocksize) {
ext4_msg(sb, KERN_WARNING, "clusters in "
  "group %u exceeds block size", i);
goto failed_mount;
}


This is the test which is failing, but it will fail by default on
pretty much all ext4 file systems, since by default there will be
32768 blocks (clusters) per group, with a 4k block size (and 32768 >>
3 == 4096).  And in the test that failed, this was a 1k block size
with 8192 blocks per blocks (and 8192 >> 3 == 1024).

Anyway, as I mentioned before, I'd much rather do very specific sanity
checking on superblock fields, instead of sanity checking calculated
values such as ext4_num_clusters_in_group().

Perhaps the easist thing to do is to run e2fsck -n on those file
systems that are causing problems?

Cheers,

- Ted


[PATCH v3 1/2] dt-bindings: auxadc: Add binding document for Mediatek auxadc.

2016-07-10 Thread Zhiyong Tao
The commit adds the device tree binding documentation for the mediatek
auxadc found on Mediatek MT2701.
Thermal gets auxadc sample data by iio device.
So the commit changes auxadc device tree binding documentation from
/soc/mediatek/auxadc.txt to /iio/adc/mt65xx_auxadc.txt.

Signed-off-by: Zhiyong Tao 
---
 .../devicetree/bindings/iio/adc/mt65xx_auxadc.txt  |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt 
b/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
index 47fcd1b..bc23792 100644
--- a/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
@@ -14,11 +14,11 @@ Required properties:
   - reg: Address range of the AUXADC unit.
   - clocks: Should contain a clock specifier for each entry in clock-names
   - clock-names: Should contain "main".
-  - io-channel-cells: Should be 1, see ../iio-bindings.txt
+  - #io-channel-cells: Should be 1, see ../iio-bindings.txt
 
 Example:
 
-auxadc: auxadc@11001000 {
+auxadc: adc@11001000 {
compatible = "mediatek,mt2701-auxadc";
reg = <0 0x11001000 0 0x1000>;
clocks = < CLK_PERI_AUXADC>;
-- 
1.7.9.5



Re: [RFC] arm64: kexec_file_load support

2016-07-10 Thread Dave Young
On 07/08/16 at 11:48am, Thiago Jung Bauermann wrote:
> Am Donnerstag, 07 Juli 2016, 14:12:45 schrieb Dave Young:
> > If so maybe change a bit from your precious mentioned 7 args proposal like
> > below?
> > 
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> > 
> > struct kexec_fdset {
> > int nr_fd;
> > struct kexec_file_fd fd[0];
> > }
> > 
> > int kexec_file_load(int kernel_fd, int initrd_fd,
> > unsigned long cmdline_len, const char *cmdline_ptr,
> > unsigned long flags, struct kexec_fdset *extra_fds);
> 
> 
> Is there a way for the kernel to distinguish whether the process passed 5 or 
> 6 arguments? How can it know whether extra_fds is a valid argument or just 
> garbage? I think we have to define a new flag KEXEC_FILE_EXTRA_FDS so that 
> the process can signal that it is using the new interface.

Agreed, a new flag is needed.

Thanks
Dave


[PATCH v3 2/2] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

2016-07-10 Thread Zhiyong Tao
Add Mediatek auxadc driver based on iio.
It will register a device in iio and support iio.
So thermal can read auxadc channel to sample data by iio device.
It is tested successfully on mt2701 platform.
Mt8173 and mt6577 platforms are not tested.
But the expectation is compatible.

Signed-off-by: Zhiyong Tao 
---
 drivers/iio/adc/Kconfig |   26 +++---
 drivers/iio/adc/Makefile|2 +-
 drivers/iio/adc/mt6577_auxadc.c |  186 +++
 3 files changed, 104 insertions(+), 110 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 66e9b44..14929fc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -305,6 +305,19 @@ config MCP3422
  This driver can also be built as a module. If so, the module will be
  called mcp3422.
 
+config MEDIATEK_MT6577_AUXADC
+tristate "MediaTek AUXADC driver"
+depends on ARCH_MEDIATEK || COMPILE_TEST
+depends on HAS_IOMEM
+help
+  Say yes here to enable support for MediaTek mt65xx AUXADC.
+
+  The driver supports immediate mode operation to read from one of 
sixteen
+  channels (external or internal).
+
+  This driver can also be built as a module. If so, the module will be
+  called mt6577_auxadc.
+
 config MEN_Z188_ADC
tristate "MEN 16z188 ADC IP Core support"
depends on MCB
@@ -315,19 +328,6 @@ config MEN_Z188_ADC
  This driver can also be built as a module. If so, the module will be
  called men_z188_adc.
 
-config MEDIATEK_MT65XX_AUXADC
-   tristate "MediaTek AUXADC driver"
-   depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_IOMEM
-   help
- Say yes here to enable support for MediaTek mt65xx AUXADC.
-
- The driver supports immediate mode operation to read from one of 
sixteen
- channels (external or internal).
-
- This driver can also be built as a module. If so, the module will be
- called mt6577_auxadc.
-
 config MXS_LRADC
 tristate "Freescale i.MX23/i.MX28 LRADC"
 depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 14a630f..8306347 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -30,8 +30,8 @@ obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
+obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
-obj-$(CONFIG_MEDIATEK_MT65XX_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
 obj-$(CONFIG_NAU7802) += nau7802.o
 obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index a56531a..a853ae8 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -24,80 +24,78 @@
 #include 
 #include 
 
-/* Registers definitions */
-#define MT65XX_AUXADC_CON00x00
-#define MT65XX_AUXADC_CON10x04
-#define MT65XX_AUXADC_CON20x10
-#define MT65XX_AUXADC_STA BIT(0)
+/* Register definitions */
+#define MT6577_AUXADC_CON00x00
+#define MT6577_AUXADC_CON10x04
+#define MT6577_AUXADC_CON20x10
+#define MT6577_AUXADC_STA BIT(0)
 
-#define MT65XX_AUXADC_DAT00x14
-#define MT65XX_AUXADC_RDY0BIT(12)
+#define MT6577_AUXADC_DAT00x14
+#define MT6577_AUXADC_RDY0BIT(12)
 
-#define MT65XX_AUXADC_MISC0x94
-#define MT65XX_AUXADC_PDN_EN  BIT(14)
+#define MT6577_AUXADC_MISC0x94
+#define MT6577_AUXADC_PDN_EN  BIT(14)
 
-#define MT65XX_AUXADC_DAT_MASK0xfff
-#define MT65XX_AUXADC_SLEEP_US1000
-#define MT65XX_AUXADC_TIMEOUT_US  1
-#define MT65XX_AUXADC_POWER_READY_MS  1
-#define MT65XX_AUXADC_SAMPLE_READY_US 25
+#define MT6577_AUXADC_DAT_MASK0xfff
+#define MT6577_AUXADC_SLEEP_US1000
+#define MT6577_AUXADC_TIMEOUT_US  1
+#define MT6577_AUXADC_POWER_READY_MS  1
+#define MT6577_AUXADC_SAMPLE_READY_US 25
 
-struct mt65xx_auxadc_device {
+struct mt6577_auxadc_device {
void __iomem *reg_base;
struct clk *adc_clk;
struct mutex lock;
-   unsigned int power_ready_ms;
-   unsigned int sample_ready_us;
 };
 
-#define MT65XX_AUXADC_CHANNEL(idx) {   \
+#define MT6577_AUXADC_CHANNEL(idx) {   \
.type = IIO_VOLTAGE,\
.indexed = 1,   \
.channel = 

[PATCH v3 0/2] AUXADC: Mediatek auxadc driver

2016-07-10 Thread Zhiyong Tao
This series includes three patches:
1.Change the device tree binding documentation.
2.Add auxadc driver based on linux iio.
3.Add auxadc nodes in the mediatek MT2701 dtsi file.

changes in patch v3:
1).Add '#' before 'io-channel-cells' and change 'auxadc@' to 'adc@' in auxadc 
binding document.
2).Fix CONFIG_MEDIATEK_MT65XX_AUXADC sequence as alphabetical order.
3).Change the prefix 'MT65XX' to 'MT6577' to match auxadc driver name.
4).Remove the delays stored in 'mt6577_auxadc_device' and use the defined delay 
directly.
5).Use '-ETIMEDOUT' instead of '-EINVAL'.
6).Return value directly in 'mt6577_auxadc_read_raw'.
7).Add power off and unprepare clock if 'iio_device_register' failed.
8).Change 'Registers' to 'Register'.

changes in patch v2:
1).Change the file name mt65xx_auxadc.c to mt6577_auxadc.c.
2).Add 'depends on ARCH_MEDIATEK || COMPILE_TEST and HAS_IOMEM' for 
MEDIATEK_MT65XX_AUXADC config.
3).Add check case for return value of 'readl_poll_timeout'.
4).Remove returning 1 and 0 for SCALE and OFFSET. use channel type 
'IIO_CHAN_INFO_PROCESSED' instead of 'IIO_CHAN_INFO_RAW'.
5).Remove 'IIO_CHAN_INFO_OFFSET' and 'IIO_CHAN_INFO_SCALE' in 
'MT65XX_AUXADC_CHANNEL' channel type.
6).Add check case when auxadc power on failure. if auxadc power on failure, 
clk_disable_unprepare should be executed.
7).Put 'platform_set_drvdata' before 'iio_device_register'.
8).Fix coding style and spelling error.

Zhiyong Tao (2):
  dt-bindings: auxadc: Add binding document for Mediatek auxadc.
  iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

 .../devicetree/bindings/iio/adc/mt65xx_auxadc.txt  |4 +-
 drivers/iio/adc/Kconfig|   26 +--
 drivers/iio/adc/Makefile   |2 +-
 drivers/iio/adc/mt6577_auxadc.c|  186 ++--
 4 files changed, 106 insertions(+), 112 deletions(-)



Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900

2016-07-10 Thread Paul Gortmaker
[Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900] On 
11/07/2016 (Mon 10:30) Wan Zongshun wrote:

> 
> 
> On 2016年07月11日 05:56, Paul Gortmaker wrote:
> >On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun  wrote
> >>This driver is to add reset support for nuc900 series,
> >>currently, it only supports nuc970 SoC reset.
> >>
> >>Signed-off-by: Wan Zongshun 
> >>---
> >>  drivers/power/reset/Kconfig|  7 +++
> >>  drivers/power/reset/Makefile   |  1 +
> >>  drivers/power/reset/nuc900-reset.c | 93 
> >> ++
> >>  3 files changed, 101 insertions(+)
> >>  create mode 100644 drivers/power/reset/nuc900-reset.c
> >>
> >>diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> >>index 9bb2622..8c84892 100644
> >>--- a/drivers/power/reset/Kconfig
> >>+++ b/drivers/power/reset/Kconfig
> >>@@ -94,6 +94,13 @@ config POWER_RESET_MSM
> >> help
> >>   Power off and restart support for Qualcomm boards.
> >>
> >>+config POWER_RESET_NUC900
> >>+   bool "Nuc900 restart driver"
> >
> >If this driver is bool and not tristate, then please remove all references
> >to MODULE_ and then the module.h include as well.
> 
> I will remove the following codes in my reset.c driver.
> 
> MODULE_DEVICE_TABLE(of, of_nuc900_reset_match);
> #include 

Thanks -- it is not a specific criticism of your driver, but just a
mistake that we have consistently copied from one driver to the next,
and I hope we can stop doing that with the right reviews.

P.
--

> 
> 
> >
> >Thanks,
> >Paul.
> >--
> >
> >>+   depends on ARCH_W90X900
> >>+   help
> >>+ Power off and restart support for Nuvoton NUC900 family of
> >>+ reference boards.
> >>+
> >>  config POWER_RESET_LTC2952
> >> bool "LTC2952 PowerPath power-off driver"
> >> depends on OF_GPIO
> >>diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> >>index ab7aa86..d4df889 100644
> >>--- a/drivers/power/reset/Makefile
> >>+++ b/drivers/power/reset/Makefile
> >>@@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
> >>  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> >>  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> >>+obj-$(CONFIG_POWER_RESET_NUC900) += nuc900-reset.o
> >>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> >>diff --git a/drivers/power/reset/nuc900-reset.c 
> >>b/drivers/power/reset/nuc900-reset.c
> >>new file mode 100644
> >>index 000..49986b7
> >>--- /dev/null
> >>+++ b/drivers/power/reset/nuc900-reset.c
> >>@@ -0,0 +1,93 @@
> >>+/*
> >>+ * Copyright 2016 Wan Zongshun 
> >>+ *
> >>+ * The code contained herein is licensed under the GNU General Public
> >>+ * License. You may obtain a copy of the GNU General Public License
> >>+ * Version 2 or later at the following locations:
> >>+ *
> >>+ * http://www.opensource.org/licenses/gpl-license.html
> >>+ * http://www.gnu.org/copyleft/gpl.html
> >>+ */
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>
> >
> >[...]
> >
> >___
> >linux-arm-kernel mailing list
> >linux-arm-ker...@lists.infradead.org
> >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> >


Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

2016-07-10 Thread tiffany lin
Hi Hans,

On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote:
> On 05/30/2016 02:29 PM, Tiffany Lin wrote:
> > Add V4L2_PIX_FMT_MT21 documentation
> > 
> > Signed-off-by: Tiffany Lin 
> > ---
> >  Documentation/DocBook/media/v4l/pixfmt.xml |6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> > b/Documentation/DocBook/media/v4l/pixfmt.xml
> > index 5a08aee..d40e0ce 100644
> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is 
> > JPEG data and should be
> >  concatenated to form the JPEG stream. 
> >  
> >   
> > + 
> > +   V4L2_PIX_FMT_MT21
> > +   'MT21'
> > +   Compressed two-planar YVU420 format used by Mediatek MT8173
> > +   codec driver.
> 
> Can you give a few more details? The encoder driver doesn't seem to produce 
> this
> format, so who is creating this? Where is this format documented?
> 

It can be as input format for encoder, MDP and display drivers in our
platform.
This private format is only available in our platform.
So I put it in "Reserved Format Identifiers" sections.


best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> > + 
> > 
> >
> >  
> > 




Re: [PATCH v9 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

2016-07-10 Thread Horng-Shyang Liao
Hi Jan,

On Fri, 2016-07-08 at 12:17 +0200, Jan Lübbe wrote:
> On Do, 2016-06-30 at 15:14 +0800, HS Liao wrote:
> [...]
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8173-gce"
> > +- reg: Address range of the GCE unit
> > +- interrupts: The interrupt signal from the GCE block
> > +- clock: Clocks according to the common clock binding
> > +- clock-names: Must be "gce" to stand for GCE clock
> > +- #mbox-cells: Should be 1
> [...]
> > +   #mbox-cells = <1>;
> [...]
> > +   mediatek,gce = <>;
> > +   mboxes = < 0 1 /* main display with merging wfe */
> > +  1 1>; /* sub display with merging wfe */
> 
> It seems that you use two cells instead of one as you declared above.
> This should be consistent.

Will correct it as 2.

> Also, why do you need an explicit phandle to the gce if you already use
> mailboxes?

"mediatek,gce" should be added to all clients which ask gce to access 
their registers.

"mboxes" should be added to all clients which will communicate with gce
via mailbox.

For example, if mmsys send cmdq tasks to ask gce to write registers of 
mmsys and ovl, mmsys should have "mediatek,gce" and "mboxes", and ovl
should have "mediatek,gce".

I will explain their difference in GCE's device tree document.

> Best regards,
> Jan Lübbe

Thanks,
HS



[PATCH v2] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

2016-07-10 Thread Baolin Wang
Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
attribute, which means it need to align the request buffer's size to an ep's
maxpacketsize.

Thus we add usb_ep_align_maybe() function to check if it is need to align
the request buffer's size to an ep's maxpacketsize.

Signed-off-by: Baolin Wang 
Acked-by: Michal Nazarewicz 
---
Changelog since v1:
 - Remove the in_ep modification.
 - Remove max_t() function.

 drivers/usb/gadget/function/f_midi.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index 58fc199..59f6278 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -359,10 +359,14 @@ static int f_midi_set_alt(struct usb_function *f, 
unsigned intf, unsigned alt)
 
/* allocate a bunch of read buffers and queue them all at once. */
for (i = 0; i < midi->qlen && err == 0; i++) {
-   struct usb_request *req =
-   midi_alloc_ep_req(midi->out_ep,
-   max_t(unsigned, midi->buflen,
-   bulk_out_desc.wMaxPacketSize));
+   struct usb_request *req;
+   unsigned length;
+
+   length = midi->buflen < bulk_out_desc.wMaxPacketSize
+   ? bulk_out_desc.wMaxPacketSize
+   : usb_ep_align_maybe(midi->gadget, midi->out_ep,
+midi->buflen);
+   req = midi_alloc_ep_req(midi->out_ep, length);
if (req == NULL)
return -ENOMEM;
 
-- 
1.7.9.5



[PATCH] xen_pvscsi: reclaim the ring request when mapping data failed

2016-07-10 Thread Bin Wu

During scsi command queueing, if mapping data fails, we need to
reclaim the failed request. Otherwise, the garbage request will
be pushed into the ring for the backend to work.

Signed-off-by: Bin Wu 
---
 drivers/scsi/xen-scsifront.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 9dc8687..655163d 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -565,6 +565,7 @@ static int scsifront_queuecommand(struct Scsi_Host *shost,
 err = map_data_for_request(info, sc, ring_req, shadow);
 if (err < 0) {
 pr_debug("%s: err %d\n", __func__, err);
+info->ring.req_prod_pvt--;
 scsifront_put_rqid(info, rqid);
 scsifront_return(info);
 spin_unlock_irqrestore(shost->host_lock, flags);
--
2.3.2 (Apple Git-55)



PCIe MSI address is not written at pci_enable_msi_range call

2016-07-10 Thread Bharat Kumar Gogada
Hi,

I have a query.
I see that when we use PCI_MSI_IRQ_DOMAIN to handle MSI's, MSI address is not 
being
written in to end point's PCI_MSI_ADDRESS_LO/HI at the call 
pci_enable_msi_range.

Instead it is being written at the time end point requests irq.

Can any one tell the reason why is it handled in this manner ?

Correct me If my observation is wrong.

Thanks & Regards,
Bharat


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.



Re: [PATCH v4 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

2016-07-10 Thread Dave Young
On 07/10/16 at 04:11pm, Michael Ellerman wrote:
> Thiago Jung Bauermann  writes:
> 
> > kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
> > implementation to find free memory for the purgatory stack.
> >
> > Signed-off-by: Thiago Jung Bauermann 
> > Cc: Eric Biederman 
> > Cc: Dave Young 
> 
> Dave are you happy with the first three patches? If so do you mind
> sending an ack?

I reviewed the 3 patches, they look good to me. Will ack after a small test 
today.

> 
> Given the series touches generic code, x86 and powerpc this might be one
> for Andrew to take. Or is there a kexec tree it should go through?

They should go Andrew's tree, but I'm not sure about the powerpc part.

Thanks
Dave


Re: [PATCH] x86: fix rdmsr MSR_PLATFORM_INFO unsafe warning in kvm guest

2016-07-10 Thread Wanpeng Li
Hi Ingo, Thomas,
2016-06-22 9:28 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li 
>
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 
> ex_handler_rdmsr_unsafe+0x6a/0x70
> unchecked MSR access error: RDMSR from 0xce
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc3+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>   81c03ce0 813b3eae 81c03d30
>   81c03d20 81067181 00320001
>  81c03df8 8179676c  81fcd2c0
> Call Trace:
>  dump_stack+0x67/0x99
>  __warn+0xd1/0xf0
>  warn_slowpath_fmt+0x4f/0x60
>  ex_handler_rdmsr_unsafe+0x6a/0x70
>  fixup_exception+0x39/0x50
>  do_general_protection+0x93/0x1b0
>  general_protection+0x22/0x30
>  ? cpu_khz_from_msr+0xd8/0x1c0
>  native_calibrate_cpu+0x30/0x5b0
>  tsc_init+0x2b/0x297
>  x86_late_time_init+0xf/0x11
>  start_kernel+0x398/0x451
>  ? set_init_arg+0x55/0x55
>  x86_64_start_reservations+0x2f/0x31
>  x86_64_start_kernel+0xea/0xed
>
> After commit (fc141535ad8 : "x86 tsc_msr: Extend to include Intel Core
> Architecture"), rdmsr MSR_PLATFORM_INFO is used to get maximum non-turbo

I just saw commit (fc273eeef314c : "x86 tsc_msr: Extend to include
Intel Core Architecture") was merged in tip tree, then this patch is
needed to fix that commit. The bug is reported by LKP several weeks
ago, and kvm maintainer Paolo has already replied "This looks good" to
this patch.

Regards,
Wanpeng Li

> ratio for recent Intel Core Architecture which results in kvm guest rdmsr
> unsafe warning.
>
> As Radim pointed out before:
>
> | MSR_PLATFORM_INFO: Intel changes it from family to family and there is
> | no obvious overlap or default.  If we picked 0 (any other fixed value),
> | then the guest would have to know that 0 doesn't mean that
> | MSR_PLATFORM_INFO returned 0, but that KVM doesn't emulate this MSR and
> | the value cannot be used.  This is very similar to handling a #GP in the
> | guest, but also has a disadvantage, because KVM cannot say that
> | MSR_PLATFORM_INFO is 0.  Simple emulation is not possible.
>
> This patch fix it by using rdmsr_safe to read MSR_PLATFORM_INFO in kvm
> guest in order that #GP can be fixed up, then tsc will be calibrated by
> PIT, HPET etc.
>
> Reported-by: kernel test robot 
> Cc: Len Brown 
> Cc: "Rafael J. Wysocki" 
> Cc: Zhang Rui 
> Cc: Chen Yu 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: jacob.jun@intel.com
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kernel/tsc_msr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
> index e0c2b30..e6e465e 100644
> --- a/arch/x86/kernel/tsc_msr.c
> +++ b/arch/x86/kernel/tsc_msr.c
> @@ -70,7 +70,7 @@ static int match_cpu(u8 family, u8 model)
>   */
>  unsigned long cpu_khz_from_msr(void)
>  {
> -   u32 lo, hi, ratio, freq_id, freq;
> +   u32 lo, hi, freq_id, freq, ratio = 0;
> unsigned long res;
> int cpu_index;
>
> @@ -123,8 +123,8 @@ unsigned long cpu_khz_from_msr(void)
> }
>
>  get_ratio:
> -   rdmsr(MSR_PLATFORM_INFO, lo, hi);
> -   ratio = (lo >> 8) & 0xff;
> +   if (!rdmsr_safe(MSR_PLATFORM_INFO, , ))
> +   ratio = (lo >> 8) & 0xff;
>
>  done:
> /* TSC frequency = maximum resolved freq * maximum resolved bus ratio 
> */
> --
> 1.9.1
>


PCIe MSI address is not written at pci_enable_msi_range call

2016-07-10 Thread Bharat Kumar Gogada
Hi,

I have a query.
I see that when we use PCI_MSI_IRQ_DOMAIN to handle MSI's, MSI address is not 
being
written in to end point's PCI_MSI_ADDRESS_LO/HI at the call 
pci_enable_msi_range.

Instead it is being written at the time end point requests irq.

Can any one tell the reason why is it handled in this manner ?

Correct me If my observation is wrong.

Thanks & Regards,
Bharat


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.



Re: [PATCH v2 09/22] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon

2016-07-10 Thread Peter Chen
On Thu, Jul 07, 2016 at 03:21:00PM -0700, Stephen Boyd wrote:
> Force the OTG state machine to go forward when we're using an
> extcon for vbus detection. In this case, the controller may never
> raise an interrupt for AVVIS, so we need to simulate the event by
> toggling the appropriate OTG fsm bits and kicking the state
> machine again.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
> 
> I think this was rejected last time around but I've kept it in the
> series to continue discussion on how we're supposed to be emulating
> vbus an id pin interrupts and the otgsc register.
> 
>  drivers/usb/chipidea/otg_fsm.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> index de8e22ec3902..aab076fc4d82 100644
> --- a/drivers/usb/chipidea/otg_fsm.c
> +++ b/drivers/usb/chipidea/otg_fsm.c
> @@ -475,6 +475,14 @@ static void ci_otg_drv_vbus(struct otg_fsm *fsm, int on)
>   return;
>   }
>   }
> + /*
> +  * Force state machine forward if we use extcon
> +  * to detect vbus state (i.e. simulate AVVIS event)
> +  */
> + if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
> + fsm->a_vbus_vld = 1;
> + ci_otg_queue_work(ci);
> + }
>   /* Disable data pulse irq */
>   hw_write_otgsc(ci, OTGSC_DPIE, 0);
>  
> @@ -486,6 +494,15 @@ static void ci_otg_drv_vbus(struct otg_fsm *fsm, int on)
>  
>   fsm->a_bus_drop = 1;
>   fsm->a_bus_req = 0;
> + /*
> +  * Force state machine forward if we use extcon
> +  * to detect vbus state (i.e. simulate AVVIS event)
> +  */
> + if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
> + fsm->a_vbus_vld = 0;
> + fsm->b_conn = 0;
> + ci_otg_queue_work(ci);
> + }
>   }
>  }
>  

Well, if we don't have a_valid, we can't know a_vbus_err state at
A device side if vbus is error (eg, less than 4.4v), and B device
will NOT be disconnect if vbus is still larger than BSV.

Do you really need OTG FSM? If you can pass the OTG test described at
Documentation/usb/chipidea.txt, I can accept it, I find the OTG
compliance test does not test ~a_vbus_vld either, see
otgeh_compliance_plan_1_2, ch6.7.12.2 Paths not tested.

-- 

Best Regards,
Peter Chen


linux-next: manual merge of the drm tree with the jc_docs tree

2016-07-10 Thread Stephen Rothwell
Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  Documentation/index.rst

between commit:

  17defc282fe6 ("Documentation: add meta-documentation for Sphinx and 
kernel-doc")

from the jc_docs tree and commit:

  cb597fcea5c2 ("Documentation/gpu: add new gpu.rst converted from DocBook 
gpu.tmpl")

from the drm tree.

I fixed it up (see below - I just put them in alphabetical order ...)
and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/index.rst
index ad07716c73f4,dacc77b43c29..
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@@ -13,8 -13,7 +13,9 @@@ Contents
  .. toctree::
 :maxdepth: 2
  
+gpu/index
 +   kernel-documentation
 +   media/media_uapi
  
  Indices and tables
  ==


Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900

2016-07-10 Thread Wan Zongshun



On 2016年07月11日 05:56, Paul Gortmaker wrote:

On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun  wrote

This driver is to add reset support for nuc900 series,
currently, it only supports nuc970 SoC reset.

Signed-off-by: Wan Zongshun 
---
  drivers/power/reset/Kconfig|  7 +++
  drivers/power/reset/Makefile   |  1 +
  drivers/power/reset/nuc900-reset.c | 93 ++
  3 files changed, 101 insertions(+)
  create mode 100644 drivers/power/reset/nuc900-reset.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 9bb2622..8c84892 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -94,6 +94,13 @@ config POWER_RESET_MSM
 help
   Power off and restart support for Qualcomm boards.

+config POWER_RESET_NUC900
+   bool "Nuc900 restart driver"


If this driver is bool and not tristate, then please remove all references
to MODULE_ and then the module.h include as well.


I will remove the following codes in my reset.c driver.

MODULE_DEVICE_TABLE(of, of_nuc900_reset_match);
#include 




Thanks,
Paul.
--


+   depends on ARCH_W90X900
+   help
+ Power off and restart support for Nuvoton NUC900 family of
+ reference boards.
+
  config POWER_RESET_LTC2952
 bool "LTC2952 PowerPath power-off driver"
 depends on OF_GPIO
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index ab7aa86..d4df889 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
+obj-$(CONFIG_POWER_RESET_NUC900) += nuc900-reset.o
  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
diff --git a/drivers/power/reset/nuc900-reset.c 
b/drivers/power/reset/nuc900-reset.c
new file mode 100644
index 000..49986b7
--- /dev/null
+++ b/drivers/power/reset/nuc900-reset.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 



[...]

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




Re: [PATCH 2/2] net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings

2016-07-10 Thread Florian Fainelli
Le 10/07/2016 15:50, Philippe Reynes a écrit :
> Hi all,
> 
> 
> On 05/07/16 23:40, Ben Hutchings wrote:
>> On Tue, 2016-07-05 at 14:15 -0700, Florian Fainelli wrote:
>>> On 07/05/2016 02:07 PM, Philippe Reynes wrote:
 Hi Florian,

 On 05/07/16 06:30, Florian Fainelli wrote:
> Le 04/07/2016 16:03, David Miller a écrit :
>> From: Philippe Reynes
>> Date: Sun,  3 Jul 2016 17:33:57 +0200
>>
>>> There are two generics functions
>>> phy_ethtool_{get|set}_link_ksettings,
>>> so we can use them instead of defining the same code in the driver.
>>>
>>> Signed-off-by: Philippe Reynes
>>
>> Applied.
>>
>
> The transformation is not equivalent, we lost the checks on
> netif_running() in the process, and those are here for a reason, if
> the
> interface is down and therefore clock gated, MDIO accesses to the PHY
> will simply fail outright and cause bus errors.

 Oh, I see, I've missed this. Sorry for this mistake.
 We should revert this path.
>>>
>>> Well, maybe better than that, actually put the check in the generic
>>> functions, because if the link is down, aka netif_running() returns
>>> false, link parameters cannot be reliably queried and they are invalid.
> 
> In my understanding, if the link is down, the pointer phydev in the
> struct net_device is NULL. So generic functions
> phy_ethtool_{get|set}_link_ksetting
> should return -ENODEV.

This pointer is NULL only when phy_detach() is called typically by
phy_disconnect(), but remains and needs to be valid reference throughout
the entire time the network interface is open regardless of the link state.

One of the reasons why some drivers are checking for the phydev pointer
to be NULL is because you can have one process open the network
interface, attaching to the PHY at some point in that ndo_open, and
another one calling in ethtool_get_settings for instance and this second
process can see a transient state where the PHY device is not yet
attached (aka NULL).

> 
> If I'm wrong, and it everybody agree, I'll send a patch that add a check
> on netif_running.
> 
>> Either the hardware or the driver needs to remember:
>>
>> - Is auto-negotiation enabled
>> - If so, which modes are advertised
>> - If not, which mode is forced
>>
>> And it should still be possible to get or set that information when the
>> interface is down.
> 
> It could be possible to save the set_link_ksettings request if the link
> is down, and apply it when the link become up.
> It also could be possible to save the last state of the link before it
> goes to down, and return it to a get_link_ksettings when the link is down.
> But what happen if the link was never up before the first
> get_link_kettings ?

Humm, sure, I would take a few examples first and see how consistent
they are with allowing these operations while the link is down and move
from there.

Thanks!
-- 
Florian


Re: [PATCH] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

2016-07-10 Thread Baolin Wang
On 8 July 2016 at 21:04, Michal Nazarewicz  wrote:
> On Fri, Jul 08 2016, Baolin Wang wrote:
>> On 7 July 2016 at 20:51, Michal Nazarewicz  wrote:
>>> On Thu, Jul 07 2016, Baolin Wang wrote:
 Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
 attribute, which means it need to align the request buffer's size to an 
 ep's
 maxpacketsize.

 Thus we add usb_ep_align_maybe() function to check if it is need to align
 the request buffer's size to an ep's maxpacketsize.

 Signed-off-by: Baolin Wang 
>>>
>>> Acked-by: Michal Nazarewicz 
>>>
 ---
  drivers/usb/gadget/function/f_midi.c |   18 +++---
  1 file changed, 11 insertions(+), 7 deletions(-)

 diff --git a/drivers/usb/gadget/function/f_midi.c 
 b/drivers/usb/gadget/function/f_midi.c
 index 58fc199..2e3f11e 100644
 --- a/drivers/usb/gadget/function/f_midi.c
 +++ b/drivers/usb/gadget/function/f_midi.c
 @@ -328,7 +328,7 @@ static int f_midi_start_ep(struct f_midi *midi,
  static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned 
 alt)
  {
   struct f_midi *midi = func_to_midi(f);
 - unsigned i;
 + unsigned i, length;
   int err;

   /* we only set alt for MIDIStreaming interface */
 @@ -345,9 +345,11 @@ static int f_midi_set_alt(struct usb_function *f, 
 unsigned intf, unsigned alt)

   /* pre-allocate write usb requests to use on f_midi_transmit. */
   while (kfifo_avail(>in_req_fifo)) {
 - struct usb_request *req =
 - midi_alloc_ep_req(midi->in_ep, midi->buflen);
 + struct usb_request *req;

 + length = usb_ep_align_maybe(midi->gadget, midi->in_ep,
 + midi->buflen);
 + req = midi_alloc_ep_req(midi->in_ep, length);
   if (req == NULL)
   return -ENOMEM;

 @@ -359,10 +361,12 @@ static int f_midi_set_alt(struct usb_function *f, 
 unsigned intf, unsigned alt)

   /* allocate a bunch of read buffers and queue them all at once. */
   for (i = 0; i < midi->qlen && err == 0; i++) {
 - struct usb_request *req =
 - midi_alloc_ep_req(midi->out_ep,
 - max_t(unsigned, midi->buflen,
 - bulk_out_desc.wMaxPacketSize));
 + struct usb_request *req;
 +
 + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
 + midi->buflen);
 + req = midi_alloc_ep_req(midi->out_ep,
 + max_t(unsigned, length, 
 bulk_out_desc.wMaxPacketSize));
>>>
>>> Perhaps:
>>>
>>> +   length = midi->buflen < bulk_out_desc.wMaxPacketSize
>>> +   ? bulk_out_desc.wMaxPacketSize
>>> +   : usb_ep_align_maybe(midi->gadget, midi->out_ep,
>>> +midi->buflen);
>>> +   req = midi_alloc_ep_req(midi->out_ep, length);
>>>
>>> I find it somewhat cleaner.  Up to you.
>>
>> But if the gadget does not requires 'quirk_ep_out_aligned_size', then
>> we also can keep midi->buflen length although midi->buflen <
>> bulk_out_desc.wMaxPacketSize, right? Thanks for your comment.
>
> I don’t know.  That’s not what the original code was doing.  The
> original code was using:
>
> max_t(unsigned, midi->buflen, bulk_out_desc.wMaxPacketSize));

OK.

>
> for some reason.>
>
   if (req == NULL)
   return -ENOMEM;

>>>
>>> --
>>> Best regards
>>> ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
>>> «If at first you don’t succeed, give up skydiving»
>>
>>
>>
>> --
>> Baolin.wang
>> Best Regards
>
> --
> Best regards
> ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
> «If at first you don’t succeed, give up skydiving»



-- 
Baolin.wang
Best Regards


Re: [PATCH] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

2016-07-10 Thread Baolin Wang
On 8 July 2016 at 21:27, Felipe Balbi  wrote:
>
> Hi again,
>
> Felipe Balbi  writes:
>> Michal Nazarewicz  writes:
>>> On Fri, Jul 08 2016, Baolin Wang wrote:
 On 7 July 2016 at 20:51, Michal Nazarewicz  wrote:
> On Thu, Jul 07 2016, Baolin Wang wrote:
>> Some gadget device (such as dwc3 gadget) requires 
>> quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an 
>> ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang 
>
> Acked-by: Michal Nazarewicz 
>
>> ---
>>  drivers/usb/gadget/function/f_midi.c |   18 +++---
>>  1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..2e3f11e 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -328,7 +328,7 @@ static int f_midi_start_ep(struct f_midi *midi,
>>  static int f_midi_set_alt(struct usb_function *f, unsigned intf, 
>> unsigned alt)
>>  {
>>   struct f_midi *midi = func_to_midi(f);
>> - unsigned i;
>> + unsigned i, length;
>>   int err;
>>
>>   /* we only set alt for MIDIStreaming interface */
>> @@ -345,9 +345,11 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* pre-allocate write usb requests to use on f_midi_transmit. */
>>   while (kfifo_avail(>in_req_fifo)) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->in_ep, midi->buflen);
>> + struct usb_request *req;
>>
>> + length = usb_ep_align_maybe(midi->gadget, midi->in_ep,
>> + midi->buflen);
>> + req = midi_alloc_ep_req(midi->in_ep, length);
>>   if (req == NULL)
>>   return -ENOMEM;
>>
>> @@ -359,10 +361,12 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* allocate a bunch of read buffers and queue them all at once. */
>>   for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> +
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>> + req = midi_alloc_ep_req(midi->out_ep,
>> + max_t(unsigned, length, 
>> bulk_out_desc.wMaxPacketSize));
>
> Perhaps:
>
> +   length = midi->buflen < bulk_out_desc.wMaxPacketSize
> +   ? bulk_out_desc.wMaxPacketSize
> +   : usb_ep_align_maybe(midi->gadget, midi->out_ep,
> +midi->buflen);
> +   req = midi_alloc_ep_req(midi->out_ep, length);
>
> I find it somewhat cleaner.  Up to you.

 But if the gadget does not requires 'quirk_ep_out_aligned_size', then
 we also can keep midi->buflen length although midi->buflen <
 bulk_out_desc.wMaxPacketSize, right? Thanks for your comment.
>>>
>>> I don’t know.  That’s not what the original code was doing.  The
>>> original code was using:
>>>
>>> max_t(unsigned, midi->buflen, bulk_out_desc.wMaxPacketSize));
>>>
>>> for some reason.>
>>
>> My take on this is that it's calling max_t() to try and align to
>> wMaxPacketSize. We can see from original commit what was the intent:
>>
>> commit 03d27ade4941076b34c823d63d91dc895731a595
>> Author: Felipe F. Tonello 
>> Date:   Wed Mar 9 19:39:30 2016 +
>>
>> usb: gadget: f_midi: Fixed a bug when buflen was smaller than 
>> wMaxPacketSize
>>
>> buflen by default (256) is smaller than wMaxPacketSize (512) in 
>> high-speed
>> devices.
>>
>> That caused the OUT endpoint to freeze if the host send any data packet 
>> of
>> length greater than 256 bytes.
>>
>> This is an example dump of what happended on that enpoint:
>> HOST:   [DATA][Length=260][...]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> ...
>> HOST:   [PING]
>> DEVICE: [NAK]
>>
>> This patch fixes this problem by setting the minimum usb_request's 
>> buffer size
>>   

Re: [PATCH] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

2016-07-10 Thread Baolin Wang
On 8 July 2016 at 21:21, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>>  drivers/usb/gadget/function/f_midi.c |   18 +++---
>>  1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..2e3f11e 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -328,7 +328,7 @@ static int f_midi_start_ep(struct f_midi *midi,
>>  static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned 
>> alt)
>>  {
>>   struct f_midi *midi = func_to_midi(f);
>> - unsigned i;
>> + unsigned i, length;
>>   int err;
>>
>>   /* we only set alt for MIDIStreaming interface */
>> @@ -345,9 +345,11 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* pre-allocate write usb requests to use on f_midi_transmit. */
>>   while (kfifo_avail(>in_req_fifo)) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->in_ep, midi->buflen);
>> + struct usb_request *req;
>>
>> + length = usb_ep_align_maybe(midi->gadget, midi->in_ep,
>> + midi->buflen);
>
> this is not needed for in_ep, only out_ep, right?

Yes. You are right.

>
>> + req = midi_alloc_ep_req(midi->in_ep, length);
>>   if (req == NULL)
>>   return -ENOMEM;
>>
>> @@ -359,10 +361,12 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* allocate a bunch of read buffers and queue them all at once. */
>>   for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> +
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>
> after calling usb_ep_align_maybe()...
>
>> + req = midi_alloc_ep_req(midi->out_ep,
>> + max_t(unsigned, length, bulk_out_desc.wMaxPacketSize));
>
> ... max_t() is pointless. length will *always* >= wMaxPacketSize.

It is not. If the gadget device dose not require
quirk_ep_out_aligned_size, then the lengh may be <= wMaxPacketSize.

-- 
Baolin.wang
Best Regards


PERSONALE E PRESTITO OFFERTA BUSINESS (APPLICA)

2016-07-10 Thread Pablo
Avete bisogno di un PRESTITO urgente? SE SI DO CONTATTACI PER MAGGIORI 
INFORMAZIONI VIA:(pabloleomonome...@gmail.com)
+4242218484
riguardo
Pablo Leo



Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

2016-07-10 Thread Wan Zongshun



On 2016年07月11日 05:51, Paul Gortmaker wrote:

On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun  wrote:

This patch is to add irqchip driver support for nuc900 plat,
current this driver only supports nuc970 SoC.

Signed-off-by: Wan Zongshun 
---
  arch/arm/mach-w90x900/include/mach/irqs.h |   5 +
  drivers/irqchip/Makefile  |   1 +
  drivers/irqchip/irq-nuc900.c  | 150 ++
  3 files changed, 156 insertions(+)
  create mode 100644 drivers/irqchip/irq-nuc900.c

diff --git a/arch/arm/mach-w90x900/include/mach/irqs.h 
b/arch/arm/mach-w90x900/include/mach/irqs.h
index 9d5cba3..3b035c6 100644
--- a/arch/arm/mach-w90x900/include/mach/irqs.h
+++ b/arch/arm/mach-w90x900/include/mach/irqs.h
@@ -59,7 +59,12 @@
  #define IRQ_KPIW90X900_IRQ(29)
  #define IRQ_P2SGROUP   W90X900_IRQ(30)
  #define IRQ_ADCW90X900_IRQ(31)
+
+#if !defined(CONFIG_SOC_NUC900)
  #define NR_IRQS(IRQ_ADC+1)
+#else
+#define NR_IRQS62
+#endif

  /*for irq group*/

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..9ccd5af8a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)  += irq-pic32-evic.o
  obj-$(CONFIG_MVEBU_ODMI)   += irq-mvebu-odmi.o
  obj-$(CONFIG_LS_SCFG_MSI)  += irq-ls-scfg-msi.o
  obj-$(CONFIG_EZNPS_GIC)+= irq-eznps.o
+obj-$(CONFIG_SOC_NUC970)   += irq-nuc900.o
diff --git a/drivers/irqchip/irq-nuc900.c b/drivers/irqchip/irq-nuc900.c
new file mode 100644
index 000..c4b2e39
--- /dev/null
+++ b/drivers/irqchip/irq-nuc900.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 


Why do you include module.h when I don't see anything modular in
this driver?


Okay, I can delete it.



Paul.
--


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+


[...]

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




Re: [PATCH v2 09/10] Documentation: devicetree: Add dts description for nuc900

2016-07-10 Thread Wan Zongshun



On 2016年07月11日 06:17, Arnd Bergmann wrote:

On Sunday, July 10, 2016 3:42:21 PM CEST Wan Zongshun wrote:

+
+Required properties:
+- compatible : Should be "nuvoton,nuc970-tmr"
+- reg : Address and length of the register set
+- clocks : Reference on the timer input clock
+- interrupts : Reference to the timer interrupt
+
+Example:
+
+tmr@0xb8001000 {


The name should be "timer", not "tmr", and the address should
not contain a leading "0x".


Ok, so all dts addresses has no need contain a leading "0x"?




+   compatible = "nuvoton,nuc970-tmr";
+   reg = <0xb8001000 0x1000>;
+   interrupts = <16>;
+   clocks = < TIMER0_GATE>,
+   < TIMER1_GATE>;
+   clock-names = "timer0", "timer1";
+};


The clocks/clock-names description does not match the example:
you only define a single clock in the required properties, but
have two separate inputs in the example. Please fix one or the
other.


Two clocks are necessary, so I only need modify this description like?

Required properties:
  clocks : Reference on the timer input clock, This list should be 2
   clocks, the order is timer0 , timer1.

Is it ok?



Arnd




linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

2016-07-10 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the wireless-drivers-next tree got a
conflict in:

  drivers/net/wireless/intel/iwlwifi/mvm/scan.c

between commit:

  7947d3e075cd ("mac80211: Add support for beacon report radio measurement")

from the net-next tree and commit:

  69e046423ad7 ("iwlwifi: mvm: change scan timeout to a delayed work")

from the wireless-drivers-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/mvm/scan.c
index 1cac10c5d818,fb25d9e41912..
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@@ -400,9 -396,10 +400,9 @@@ void iwl_mvm_rx_lmac_scan_complete_noti
   iwl_mvm_ebs_status_str(scan_notif->ebs_status));
  
mvm->scan_status &= ~IWL_MVM_SCAN_REGULAR;
 -  ieee80211_scan_completed(mvm->hw,
 -  scan_notif->status == IWL_SCAN_OFFLOAD_ABORTED);
 +  ieee80211_scan_completed(mvm->hw, );
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
-   del_timer(>scan_timer);
+   cancel_delayed_work(>scan_timeout_dwork);
} else {
IWL_ERR(mvm,
"got scan complete notification but no scan is 
running\n");
@@@ -1433,13 -1432,9 +1435,13 @@@ void iwl_mvm_rx_umac_scan_complete_noti
  
/* if the scan is already stopping, we don't need to notify mac80211 */
if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_REGULAR) {
 -  ieee80211_scan_completed(mvm->hw, aborted);
 +  struct cfg80211_scan_info info = {
 +  .aborted = aborted,
 +  };
 +
 +  ieee80211_scan_completed(mvm->hw, );
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
-   del_timer(>scan_timer);
+   cancel_delayed_work(>scan_timeout_dwork);
} else if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_SCHED) {
ieee80211_sched_scan_stopped(mvm->hw);
mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;
@@@ -1644,14 -1630,9 +1646,14 @@@ out
 * to release the scan reference here.
 */
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
-   del_timer(>scan_timer);
+   cancel_delayed_work(>scan_timeout_dwork);
 -  if (notify)
 -  ieee80211_scan_completed(mvm->hw, true);
 +  if (notify) {
 +  struct cfg80211_scan_info info = {
 +  .aborted = true,
 +  };
 +
 +  ieee80211_scan_completed(mvm->hw, );
 +  }
} else if (notify) {
ieee80211_sched_scan_stopped(mvm->hw);
mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;


Re: [PATCH v2 2/9] [media] : v4l: add Mediatek compressed video block format

2016-07-10 Thread tiffany lin
Hi Hans,

On Fri, 2016-07-08 at 12:18 +0200, Hans Verkuil wrote:
> On 05/12/2016 01:24 PM, Tiffany Lin wrote:
> > Add V4L2_PIX_FMT_MT21 format used on MT8173 driver.
> > It is compressed format and need MT8173 MDP driver to transfer to other 
> > standard format.
> > 
> > Signed-off-by: Tiffany Lin 
> > ---
> >  include/uapi/linux/videodev2.h |1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 8f95191..52feea6 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -625,6 +625,7 @@ struct v4l2_pix_format {
> >  #define V4L2_PIX_FMT_Y8I  v4l2_fourcc('Y', '8', 'I', ' ') /* Greyscale 
> > 8-bit L/R interleaved */
> >  #define V4L2_PIX_FMT_Y12I v4l2_fourcc('Y', '1', '2', 'I') /* Greyscale 
> > 12-bit L/R interleaved */
> >  #define V4L2_PIX_FMT_Z16  v4l2_fourcc('Z', '1', '6', ' ') /* Depth 
> > data 16-bit */
> > +#define V4L2_PIX_FMT_MT21 v4l2_fourcc('M', 'T', '2', '1') /* Mediatek 
> > compressed block mode  */
> 
> v4l2-ioctl.c should be modified as well so the correct description string is 
> filled in.
> 
Got it. I will fix this.

best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> >  
> >  /* SDR formats - used only for Software Defined Radio devices */
> >  #define V4L2_SDR_FMT_CU8  v4l2_fourcc('C', 'U', '0', '8') /* IQ u8 
> > */
> > 




Re: Update the maximum depth of C-state from 6 to 9

2016-07-10 Thread baolex.ni
Hi Jon,

This patch is an old one, we have corrected some minor issues on the newer one.
Please only review the newest version from my last mail with this subject
"[PATCH] ACPI: Update the maximum depth of C-state from 6 to 9".
And I also attached it to this mail.

Thanks,
Baole

On 7/11/2016 6:37 AM, Jonathan Corbet wrote:
> On Mon, 4 Jul 2016 09:55:10 +0800
> "baolex.ni"  wrote:
> 
>> Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
>> and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of 
>> C-state.
>> This change is reflected in one place of the kernel-param file,
>> but not in the other place where I suggest changing.
>>
>> Signed-off-by: Chuansheng Liu 
>> Signed-off-by: Baole Ni 
> 
> So why are there two signoffs on a single-line patch?  Which one of you
> is the actual author?
> 
> Thanks,
> 
> jon
> 
From cf5f8aa6885874f6490b11507d3c0c86fa0a11f4 Mon Sep 17 00:00:00 2001
From: Chuansheng Liu 
Date: Mon, 4 Jul 2016 08:52:51 +0800
Subject: [PATCH] Update the maximum depth of C-state from 6 to 9
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of 
C-state.
This change is reflected in one place of the kernel-param file,
but not in the other place where I suggest changing.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 Documentation/kernel-parameters.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c9..a863737 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1661,7 +1661,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
intel_idle.max_cstate=  [KNL,HW,ACPI,X86]
0   disables intel_idle and fall back on acpi_idle.
-   1 to 6  specify maximum depth of C-state.
+   1 to 9  specify maximum depth of C-state.
 
intel_pstate=  [X86]
   disable
-- 
2.8.3



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

2016-07-10 Thread Stephen Rothwell
Hi Rafael,

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

ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
undefined!
ERROR: "config_item_put" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] undefined!
ERROR: "config_item_init_type_name" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
undefined!

... and many more ...

Presumably (maybe?) caused by commit

  0bf54fcd9504 ("ACPI: add support for configfs")

though it is not obvious why this should be a problem.

I have used the version of the pm tree from next-20160708 for today.
-- 
Cheers,
Stephen Rothwell


Re: [PATCH] 8250/fintek: rename IRQ_MODE macro

2016-07-10 Thread Ji-Ze Hong (Peter Hong)

Hi Arnd,

Arnd Bergmann 於 2016/6/27 下午 05:21 寫道:

This renames the newly introduced 'IRQ_MODE' macro to FINTEK_IRQ_MODE.

Signed-off-by: Arnd Bergmann 
Fixes: 4da22f1418cb ("serial: 8250_fintek: fix the mismatched IRQ mode")


Acked-by: Ji-Ze Hong (Peter Hong) 

Thanks for fix the issue.
--
With Best Regards,
Peter Hung


Re: [PATCH 1/7] hwmon: (core) New hwmon registration API

2016-07-10 Thread Guenter Roeck

Hi Jonathan,

On 07/10/2016 08:51 AM, Jonathan Cameron wrote:

On 26/06/16 04:26, Guenter Roeck wrote:

Up to now, each hwmon driver has to implement its own sysfs attributes.
This requires a lot of template code, and distracts from the driver's core
function to read and write chip registers.

To be able to reduce driver complexity, move sensor attribute handling
and thermal zone registration into hwmon core. By using the new API,
driver size is typically reduced by 20-50% depending on driver complexity
and the number of sysfs attributes supported.

With this patch, the new API only supports thermal sensors. Support for
other sensor types will be added with subsequent patches.

Signed-off-by: Guenter Roeck 

Hi Guenter.

Sorry it took me so long to get to this

Anyhow, mostly looks clean, effective and consise to me.
Various bits and pieces inline.  There are a few bits I might (when time
allows) lift over to iio as they are nicer than what we have.

My one lesson learned from IIO is always be wary of space in bitmaps.  We
haven't run out yet but are getting close.  You may end up in a similar
state here a few years down the line.


Yes, I spend a lot of time arguing with myself over u32 vs. u64. I decided
to stick with u32 for now, reasons being that there are multiple number spaces
and that the bit mask is only really used for registration (and thus relatively
easy to change).

More comments inline.


Jonathan

---
  drivers/hwmon/hwmon.c | 485 ++
  include/linux/hwmon.h | 122 +
  2 files changed, 574 insertions(+), 33 deletions(-)

diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index a26c385a435b..9530644ae297 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -12,17 +12,16 @@

  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

-#include 
+#include 
  #include 
  #include 
-#include 
-#include 
-#include 
  #include 
-#include 
-#include 
+#include 
+#include 

Some unconnected changes in this.  Arguably reordering is good and
all but should be in a precursor patch so it's obvious what has
been added or removed here.


Split into a separate patch.


  #include 
+#include 
  #include 
+#include 

  #define HWMON_ID_PREFIX "hwmon"
  #define HWMON_ID_FORMAT HWMON_ID_PREFIX "%d"
@@ -30,9 +29,33 @@
  struct hwmon_device {
const char *name;
struct device dev;
+   const struct hwmon_chip_info *chip;
+
+   struct attribute_group group;
+   const struct attribute_group **groups;
  };
  #define to_hwmon_device(d) container_of(d, struct hwmon_device, dev)

+struct hwmon_device_attribute {
+   struct device_attribute dev_attr;
+   const struct hwmon_ops *ops;
+   enum hwmon_sensor_types type;
+   u32 attr;
+   int index;
+};
+#define to_hwmon_attr(d) \
+   container_of(d, struct hwmon_device_attribute, dev_attr)
+
+/*
+ * Thermal zone information
+ * In addition to the reference to the hwmon device,
+ * also provides the sensor index.
+ */
+struct hwmon_thermal_data {
+   struct hwmon_device *hwdev; /* Reference to hwmon device */
+   int index;  /* sensor index */
+};
+
  static ssize_t
  show_name(struct device *dev, struct device_attribute *attr, char *buf)
  {
@@ -80,25 +103,280 @@ static struct class hwmon_class = {

  static DEFINE_IDA(hwmon_ida);

-/**
- * hwmon_device_register_with_groups - register w/ hwmon
- * @dev: the parent device
- * @name: hwmon name attribute
- * @drvdata: driver data to attach to created device
- * @groups: List of attribute groups to create
- *
- * hwmon_device_unregister() must be called when the device is no
- * longer needed.
- *
- * Returns the pointer to the new device.
- */
-struct device *
-hwmon_device_register_with_groups(struct device *dev, const char *name,
- void *drvdata,
- const struct attribute_group **groups)
+/* Thermal zone handling */
+
+static int hwmon_thermal_get_temp(void *data, int *temp)
+{
+   struct hwmon_thermal_data *tdata = data;
+   struct hwmon_device *hwdev = tdata->hwdev;
+   int ret;
+   long t;
+
+   ret = hwdev->chip->ops->read(>dev, hwmon_temp, hwmon_temp_input,
+tdata->index, );
+   if (ret < 0)
+   return ret;
+
+   *temp = t;
+
+   return 0;
+}
+
+static struct thermal_zone_of_device_ops hwmon_thermal_ops = {
+   .get_temp = hwmon_thermal_get_temp,
+};
+
+static int hwmon_thermal_add_sensor(struct device *dev,
+   struct hwmon_device *hwdev,
+   int index)
+{
+   struct hwmon_thermal_data *tdata;
+
+   tdata = devm_kzalloc(dev, sizeof(*tdata), GFP_KERNEL);
+   if (!tdata)
+   return -ENOMEM;
+
+   tdata->hwdev = hwdev;
+   tdata->index = index;
+
+   devm_thermal_zone_of_sensor_register(>dev, index, tdata,
+ 

Re: [alsa-devel] [PATCH -next v2] ASoC: mediatek: mt2701: fix non static symbol warning

2016-07-10 Thread Garlic Tseng
On Fri, 2016-07-08 at 13:47 +, weiyj...@163.com wrote:
> From: Wei Yongjun 
> 
> Fixes the following sparse warning:
> 
> sound/soc/mediatek/mt2701/mt2701-afe-pcm.c:72:5: warning:
>  symbol 'mt2701_dai_num_to_i2s' was not declared. Should it be static?
> 
> Signed-off-by: Wei Yongjun 

Acked-by: Garlic Tseng 

> ---
>  sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c 
> b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> index 15522c0..34a6123 100644
> --- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> +++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> @@ -69,7 +69,7 @@ static const struct mt2701_afe_rate mt2701_afe_i2s_rates[] 
> = {
>   { .rate = 352800, .regvalue = 24 },
>  };
>  
> -int mt2701_dai_num_to_i2s(struct mtk_base_afe *afe, int num)
> +static int mt2701_dai_num_to_i2s(struct mtk_base_afe *afe, int num)
>  {
>   int val = num - MT2701_IO_I2S;
> 
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel




Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220

2016-07-10 Thread Guodong Xu
On 7 July 2016 at 08:58, John Stultz  wrote:
> On Wed, Jul 6, 2016 at 12:38 AM, Arnd Bergmann  wrote:
>> On Wednesday, July 6, 2016 12:20:15 AM CEST John Stultz wrote:
>>> On Wed, Jul 6, 2016 at 12:04 AM, Olof Johansson  wrote:
>>> > On Tue, Jul 5, 2016 at 11:55 PM, John Stultz  
>>> > wrote:
>>> >> On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson  wrote:
>>> >>> On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote:
>>>  This patchset enables the pl031 RTC on the Hi6220 SoC.
>>> 
>>>  I'd like to submit it to be merged.
>>> 
>>>  Wei has acked the second patch (modulo a whitespace fix which
>>>  I've included in this v3), so it seems like both could go
>>>  through the clk tree.
>>> 
>>>  But Wei also seemed open to pulling in a clk tree branch
>>>  as it goes through arm-soc.
>>> 
>>>  Michael/Stephen: If there's no other objections, could you
>>>  queue the first patch and make it avilable via the branch for
>>>  Wei, or just take both patches?
>>> >>>
>>> >>> I happen to dread these kind of patchsets these days. There's added
>>> >>> dependencies across trees just because a defined name for the clock
>>> >>> number is added to a header file.
>>> >>>
>>> >>> I much prefer to use numerical clocks for one release, and then once
>>> >>> everything is in, switch over to the defines in the DTS.
>>> >>>
>>> >>> That way there are no dependencies, no need to setup a shared branch
>>> >>> for a simple 3-line patch, etc.
>>> >>>
>>> >>> So, mind respinning the DTS piece?
>>> >>
>>> >> Huh..
>>> >
>>> > Sorry if it appeared random, I've complained about it for a while to
>>> > submaintainers.
>>>
>>> No.. I get it, the cross-maintainer shared branch is complex enough to
>>> want to avoid. I figured it would be easier to just take a maintainer
>>> acked patch in via the clk tree, but its not my tree, so I'll leave it
>>> to you maintainers to resolve.
>>
>> The question this raises is why that clock was missed the first time
>> around. I'd suggest whoever owns the clock driver can go through the
>> documentation again and look for others that may have been missed,
>> then send a patch to the driver to add *all* the missing ones for the
>> merge window, and one release later we add the driver depending on
>> previously unknown clocks.
>
> Though this seemingly goes against the otherwise widely recommended
> approach of breaking up patches into small obvious chunks.
>
> And personally, and I don't mean to criticize, but the suggestions
> here (use numerical values, then later rename to macros; add
> everything in one go, then make dts changes a release later) all seem
> like non-optimal workarounds for the fact that adding almost any
> functionality requires cross subsystem-maintainer negotiations (or two
> release steps to get one bit of functionality merged).
>
> It seems like it might even just be clearer to make the
> two-release-steps method the widely broadcast rule (ie: no
> dependencies on in-flight patches for dts changes), so this doesn't
> confuse/dismay new developers.
>
> Anyway... In this case, I don't have the clk documentation, so I'll
> ping Zhangfei to check if there is any other clock values that should

Arnd, John

After checking documentation, I didn't see other clock values that
need to be added.

-Guodong

> be added in the future, but at least for HiKey, while there are still
> a few clk patches remaining in the tree, I don't have any more
> additions to the clk list.
>
> thanks
> -john


Re: Hang due to nfs letting tasks freeze with locked inodes

2016-07-10 Thread Dave Chinner
On Fri, Jul 08, 2016 at 01:05:40PM +, Trond Myklebust wrote:
> > On Jul 8, 2016, at 08:55, Trond Myklebust
> >  wrote:
> >> On Jul 8, 2016, at 08:48, Seth Forshee
> >>  wrote: On Fri, Jul 08, 2016 at
> >> 09:53:30AM +1000, Dave Chinner wrote:
> >>> On Wed, Jul 06, 2016 at 06:07:18PM -0400, Jeff Layton wrote:
>  On Wed, 2016-07-06 at 12:46 -0500, Seth Forshee wrote:
> > We're seeing a hang when freezing a container with an nfs
> > bind mount while running iozone. Two iozone processes were
> > hung with this stack trace.
> > 
> > [] schedule+0x35/0x80 [] schedule_preempt_disabled+0xe/0x10
> > [] __mutex_lock_slowpath+0xb9/0x130 [] mutex_lock+0x1f/0x30
> > [] do_unlinkat+0x12b/0x2d0 [] SyS_unlink+0x16/0x20 []
> > entry_SYSCALL_64_fastpath+0x16/0x71
> > 
> > This seems to be due to another iozone thread frozen during
> > unlink with this stack trace:
> > 
> > [] __refrigerator+0x7a/0x140 []
> > nfs4_handle_exception+0x118/0x130 [nfsv4] []
> > nfs4_proc_remove+0x7d/0xf0 [nfsv4] [] nfs_unlink+0x149/0x350
> > [nfs] [] vfs_unlink+0xf1/0x1a0 [] do_unlinkat+0x279/0x2d0 []
> > SyS_unlink+0x16/0x20 [] entry_SYSCALL_64_fastpath+0x16/0x71
> > 
> > Since nfs is allowing the thread to be frozen with the inode
> > locked it's preventing other threads trying to lock the same
> > inode from freezing. It seems like a bad idea for nfs to be
> > doing this.
> > 
>  
>  Yeah, known problem. Not a simple one to fix though.
> >>> 
> >>> Actually, it is simple to fix.
> >>> 
> >>>  >>> freeze_super(), not sys_sync(), to suspend filesystem
> >>> operations>
> >>> 
> >>> i.e. the VFS blocks new operations from starting, and then
> >>> then the NFS client simply needs to implement ->freeze_fs to
> >>> drain all it's active operations before returning. Problem
> >>> solved.
> >> 
> >> No, this won't solve my problem. We're not doing a full
> >> suspend, rather using a freezer cgroup to freeze a subset of
> >> processes. We don't want to want to fully freeze the
> >> filesystem.
> > 
> > …and therein lies the rub. The whole cgroup freezer stuff
> > assumes that you can safely deactivate a bunch of processes that
> > may or may not hold state in the filesystem. That’s
> > definitely not OK when you hold locks etc that can affect
> > processes that lies outside the cgroup (and/or outside the NFS
> > client itself).

Not just locks, but even just reference counts are bad. e.g. just
being suspended with an active write reference to the superblock
will cause the next filesystem freeze to hang waiting for that
reference to drain. In essence, that's a filesystem-wide DOS vector
for anyone using snapshots

> In case it wasn’t clear, I’m not just talking about VFS
> mutexes here. I’m also talking about all the other stuff, a
> lot of which the kernel has no control over, including POSIX file
> locking, share locks, leases/delegations, etc.

Yeah, freezer base process-granularity suspend just seems like a bad
idea to me...

Cheers,

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


Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

2016-07-10 Thread Al Viro
On Mon, Jul 11, 2016 at 02:01:13AM +0100, Al Viro wrote:
> On Sun, Jul 10, 2016 at 07:14:18PM +0100, James Simmons wrote:
> 
> > [  111.210818]  [] kiblnd_send+0x51d/0x9e0 [ko2iblnd]
> 
> Mea culpa - in kiblnd_send() this
> if (payload_kiov)
> iov_iter_bvec(, ITER_BVEC | WRITE,
> payload_kiov, payload_niov, payload_nob);
> else
> iov_iter_kvec(, ITER_BVEC | WRITE,
> payload_iov, payload_niov, payload_nob);
> should have s/BVEC/KVEC/ in the iov_iter_kvec() arguments.  Cut'n'paste
> braindamage...

PS: That was introduced in the last commit in that pile - "lustre: introduce
lnet_copy_{k,}iov2iter(), kill lnet_copy_{k,}iov2{k,}iov()".


Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

2016-07-10 Thread Al Viro
On Sun, Jul 10, 2016 at 07:14:18PM +0100, James Simmons wrote:

> [  111.210818]  [] kiblnd_send+0x51d/0x9e0 [ko2iblnd]

Mea culpa - in kiblnd_send() this
if (payload_kiov)
iov_iter_bvec(, ITER_BVEC | WRITE,
payload_kiov, payload_niov, payload_nob);
else
iov_iter_kvec(, ITER_BVEC | WRITE,
payload_iov, payload_niov, payload_nob);
should have s/BVEC/KVEC/ in the iov_iter_kvec() arguments.  Cut'n'paste
braindamage...


Re: [PATCH 0/5] hwmon: New hwmon registration API

2016-07-10 Thread Guenter Roeck

Hi Jonathan,

On 07/10/2016 09:00 AM, Jonathan Cameron wrote:

On 26/06/16 04:26, Guenter Roeck wrote:

Up to now, each hwmon driver has to implement its own sysfs attributes.
This requires a lot of template code, and distracts from the driver's
core function to read and write chip registers.

To be able to reduce driver complexity, move sensor attribute handling
and thermal zone registration into the hwmon core. By using the new API,
driver size is typically reduced by 20-50% depending on driver complexity
and the number of sysfs attributes supported.

The first patch of the series introduces the API as well as support
for temperature sensors. Subsequent patches introduce support for
voltage, current, power, energy, humidity, and fan speed sensors.

The series was tested by converting several drivers (lm75, lm90, tmp102,
tmp421, ltc4245) to the new API. Testing was done with with real chips
as well as with the hwmon driver module test code available at
https://github.com/groeck/module-tests.

Some cool stuff hiding in there :)

I've only reviewed 1 and 7 and the intermediate ones are really either
correct or they aren't and they look fine to me.


Thanks a lot for your feedback - it is reassuring that it looks sane to you.



So what's next? (beyond presumably a lot of driver conversions).


Next steps will be to address your comments, re-test, submit a new series,
add to -next after v4.8-rc1 is out, submit the conversions I have done
and add to -next. Then, obviously, only accept new drivers using the
new API.

Not sure if there is anything else we can or want to do do at this time.
Do you have anything in mind ?

Thanks,
Guenter



Re: [PATCH 00/31] Move LRU page reclaim from zones to nodes v8

2016-07-10 Thread Dave Chinner
On Fri, Jul 08, 2016 at 10:52:03AM +0100, Mel Gorman wrote:
> On Fri, Jul 08, 2016 at 09:27:13AM +1000, Dave Chinner wrote:
> > .
> > > This series is not without its hazards. There are at least three areas
> > > that I'm concerned with even though I could not reproduce any problems in
> > > that area.
> > > 
> > > 1. Reclaim/compaction is going to be affected because the amount of 
> > > reclaim is
> > >no longer targetted at a specific zone. Compaction works on a per-zone 
> > > basis
> > >so there is no guarantee that reclaiming a few THP's worth page pages 
> > > will
> > >have a positive impact on compaction success rates.
> > > 
> > > 2. The Slab/LRU reclaim ratio is affected because the frequency the 
> > > shrinkers
> > >are called is now different. This may or may not be a problem but if it
> > >is, it'll be because shrinkers are not called enough and some balancing
> > >is required.
> > 
> > Given that XFS has a much more complex set of shrinkers and has a
> > much more finely tuned balancing between LRU and shrinker reclaim,
> > I'd be interested to see if you get the same results on XFS for the
> > tests you ran on ext4. It might also be worth running some highly
> > concurrent inode cache benchmarks (e.g. the 50-million inode, 16-way
> > concurrent fsmark tests) to see what impact heavy slab cache
> > pressure has on shrinker behaviour and system balance...
> > 
> 
> I had tested XFS with earlier releases and noticed no major problems
> so later releases tested only one filesystem.  Given the changes since,
> a retest is desirable. I've posted the current version of the series but
> I'll queue the tests to run over the weekend. They are quite time consuming
> to run unfortunately.

Understood. I'm not following the patchset all that closely, so I
didn' know you'd already tested XFS.

> On the fsmark configuration, I configured the test to use 4K files
> instead of 0-sized files that normally would be used to stress inode
> creation/deletion. This is to have a mix of page cache and slab
> allocations. Shout if this does not suit your expectations.

Sounds fine. I usually limit that test to 10 million inodes - that's
my "10-4" test.

> Finally, not all the machines I'm using can store 50 million inodes
> of this size. The benchmark has been configured to use as many inodes
> as it estimates will fit in the disk. In all cases, it'll exert memory
> pressure. Unfortunately, the storage is simple so there is no guarantee
> it'll find all problems but that's standard unfortunately.

Yup. But it's really the system balance that matters, and if the
balance is maintained then XFS will optimise the IO patterns to get
decent throughput regardless of the storage (i.e. the 10-4 test
should still run at tens of MB/s on a single spinning disk).

Cheers,

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


Re: [PATCH 5/7] drm/rockchip: dw-mipi: support HPD poll

2016-07-10 Thread Mark yao

On 2016年07月08日 21:52, John Keeping wrote:

On Fri,  8 Jul 2016 17:04:59 +0800, Chris Zhong wrote:


At the first time of bind, there is no any panel attach in mipi. Add a
DRM_CONNECTOR_POLL_HPD porperty to detect the panel status, when panel
probe, the dw_mipi_dsi_host_attach would be called, then mipi-dsi will
trigger a event to notify the drm framework.

Signed-off-by: Chris Zhong 

Can we do something like this instead?  We know that the panel must
always be attached and this has the advantage that the display size will
be known when the framebuffer console loads.

-- >8 --
Subject: [PATCH] drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded

This ensures that the output resolution is known before fbcon loads.

Signed-off-by: John Keeping 
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 6ef5f3be8468..c0499266d116 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1154,10 +1154,17 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
  
  	dsi->dsi_host.ops = _mipi_dsi_host_ops;

dsi->dsi_host.dev = dev;
-   return mipi_dsi_host_register(>dsi_host);
+   ret = mipi_dsi_host_register(>dsi_host);
+   if (!ret && !dsi->panel) {
+   mipi_dsi_host_unregister(>dsi_host);
+   drm_encoder_cleanup(>encoder);
+   drm_connector_cleanup(>connector);
+   ret = -EPROBE_DEFER;


Hi John

Do you verify this patch? I do the similar change before, but found 
panel can't probe.


mipi_dsi_host_register will call device_add, I think the panel probe 
need this.


Seems that mipi panel probe request mipi_dsi_host_register, 
mipi_dsi_host_register request panel on your patch, endless loop.


Thanks.


+   }
  
  err_pllref:

-   clk_disable_unprepare(dsi->pllref_clk);
+   if (ret)
+   clk_disable_unprepare(dsi->pllref_clk);
return ret;
  }
  







--
Mark Yao




Re: [PATCH] mm: migrate: Use bool instead of int for the return value of PageMovable

2016-07-10 Thread Minchan Kim
On Sat, Jul 09, 2016 at 11:55:04PM +0800, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang 
> 
> For pure bool function's return value, bool is a little better more or
> less than int.
> 
> And return boolean result directly, since 'if' statement is also for
> boolean checking, and return boolean result, too.

I just wanted to consistent with other PageXXX flags functions, PageAnon,
PageMappingFlags which returns int rather than bool. Although I agree bool
is natural, I want to be consistent with others rather than breaking at
the moment.

Maybe if you feel it's really helpful, you might be able to handle all
of places I mentioned for better readability and keeping consistency.
But I doubt it's worth.

Thanks.

> 
> Signed-off-by: Chen Gang 

> ---
>  include/linux/migrate.h | 4 ++--
>  mm/compaction.c | 9 +++--
>  2 files changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index ae8d475..0e366f8 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -72,11 +72,11 @@ static inline int migrate_huge_page_move_mapping(struct 
> address_space *mapping,
>  #endif /* CONFIG_MIGRATION */
>  
>  #ifdef CONFIG_COMPACTION
> -extern int PageMovable(struct page *page);
> +extern bool PageMovable(struct page *page);
>  extern void __SetPageMovable(struct page *page, struct address_space 
> *mapping);
>  extern void __ClearPageMovable(struct page *page);
>  #else
> -static inline int PageMovable(struct page *page) { return 0; };
> +static inline bool PageMovable(struct page *page) { return false; };
>  static inline void __SetPageMovable(struct page *page,
>   struct address_space *mapping)
>  {
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 0bd53fb..cfcfe88 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -95,19 +95,16 @@ static inline bool migrate_async_suitable(int migratetype)
>  
>  #ifdef CONFIG_COMPACTION
>  
> -int PageMovable(struct page *page)
> +bool PageMovable(struct page *page)
>  {
>   struct address_space *mapping;
>  
>   VM_BUG_ON_PAGE(!PageLocked(page), page);
>   if (!__PageMovable(page))
> - return 0;
> + return false;
>  
>   mapping = page_mapping(page);
> - if (mapping && mapping->a_ops && mapping->a_ops->isolate_page)
> - return 1;
> -
> - return 0;
> + return mapping && mapping->a_ops && mapping->a_ops->isolate_page;
>  }
>  EXPORT_SYMBOL(PageMovable);
>  
> -- 
> 1.9.3
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 


linux-next: manual merge of the arm64 tree with Linus' tree

2016-07-10 Thread Stephen Rothwell
Hi Catalin,

Today's linux-next merge of the arm64 tree got a conflict in:

  arch/arm64/mm/fault.c

between commit:

  e19a6ee2460b ("arm64: kernel: Save and restore UAO and addr_limit on 
exception entry")

from Linus' tree and commit:

  541ec870ef31 ("arm64: kill ESR_LNX_EXEC")

from the arm64 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/fault.c
index b1166d1e5955,fc5a34a72c6d..
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@@ -279,9 -282,8 +282,9 @@@ static int __kprobes do_page_fault(unsi
mm_flags |= FAULT_FLAG_WRITE;
}
  
-   if (permission_fault(esr) && (addr < USER_DS)) {
+   if (is_permission_fault(esr) && (addr < USER_DS)) {
 -  if (get_fs() == KERNEL_DS)
 +  /* regs->orig_addr_limit may be 0 if we entered from EL0 */
 +  if (regs->orig_addr_limit == KERNEL_DS)
die("Accessing user space memory with fs=KERNEL_DS", 
regs, esr);
  
if (!search_exception_tables(regs->pc))


Re: [PATCH 01/16] gpu: ipu-v3: Add Video Deinterlacer unit

2016-07-10 Thread Paul Gortmaker
On Thu, Jul 7, 2016 at 7:03 PM, Steve Longerbeam  wrote:
> Adds the Video Deinterlacer (VDIC) unit.
>
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/gpu/ipu-v3/Makefile |   2 +-
>  drivers/gpu/ipu-v3/ipu-common.c |  11 ++
>  drivers/gpu/ipu-v3/ipu-prv.h|   6 +
>  drivers/gpu/ipu-v3/ipu-vdi.c| 266 
> 
>  include/video/imx-ipu-v3.h  |  27 
>  5 files changed, 311 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/ipu-v3/ipu-vdi.c
>
> diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile
> index 107ec23..aeba9dc 100644
> --- a/drivers/gpu/ipu-v3/Makefile
> +++ b/drivers/gpu/ipu-v3/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o
>
>  imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \
> -   ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o
> +   ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o ipu-vdi.o
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index 99dcacf..30dc115 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -833,6 +833,14 @@ static int ipu_submodules_init(struct ipu_soc *ipu,
> goto err_ic;
> }
>
> +   ret = ipu_vdi_init(ipu, dev, ipu_base + devtype->vdi_ofs,
> +  IPU_CONF_VDI_EN | IPU_CONF_ISP_EN |
> +  IPU_CONF_IC_INPUT);
> +   if (ret) {
> +   unit = "vdi";
> +   goto err_vdi;
> +   }
> +
> ret = ipu_di_init(ipu, dev, 0, ipu_base + devtype->disp0_ofs,
>   IPU_CONF_DI0_EN, ipu_clk);
> if (ret) {
> @@ -887,6 +895,8 @@ err_dc:
>  err_di_1:
> ipu_di_exit(ipu, 0);
>  err_di_0:
> +   ipu_vdi_exit(ipu);
> +err_vdi:
> ipu_ic_exit(ipu);
>  err_ic:
> ipu_csi_exit(ipu, 1);
> @@ -971,6 +981,7 @@ static void ipu_submodules_exit(struct ipu_soc *ipu)
> ipu_dc_exit(ipu);
> ipu_di_exit(ipu, 1);
> ipu_di_exit(ipu, 0);
> +   ipu_vdi_exit(ipu);
> ipu_ic_exit(ipu);
> ipu_csi_exit(ipu, 1);
> ipu_csi_exit(ipu, 0);
> diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
> index bfb1e8a..845f64c 100644
> --- a/drivers/gpu/ipu-v3/ipu-prv.h
> +++ b/drivers/gpu/ipu-v3/ipu-prv.h
> @@ -138,6 +138,7 @@ struct ipu_dc_priv;
>  struct ipu_dmfc_priv;
>  struct ipu_di;
>  struct ipu_ic_priv;
> +struct ipu_vdi;
>  struct ipu_smfc_priv;
>
>  struct ipu_devtype;
> @@ -169,6 +170,7 @@ struct ipu_soc {
> struct ipu_di   *di_priv[2];
> struct ipu_csi  *csi_priv[2];
> struct ipu_ic_priv  *ic_priv;
> +   struct ipu_vdi  *vdi_priv;
> struct ipu_smfc_priv*smfc_priv;
>  };
>
> @@ -199,6 +201,10 @@ int ipu_ic_init(struct ipu_soc *ipu, struct device *dev,
> unsigned long base, unsigned long tpmem_base);
>  void ipu_ic_exit(struct ipu_soc *ipu);
>
> +int ipu_vdi_init(struct ipu_soc *ipu, struct device *dev,
> +unsigned long base, u32 module);
> +void ipu_vdi_exit(struct ipu_soc *ipu);
> +
>  int ipu_di_init(struct ipu_soc *ipu, struct device *dev, int id,
> unsigned long base, u32 module, struct clk *ipu_clk);
>  void ipu_di_exit(struct ipu_soc *ipu, int id);
> diff --git a/drivers/gpu/ipu-v3/ipu-vdi.c b/drivers/gpu/ipu-v3/ipu-vdi.c
> new file mode 100644
> index 000..1303bcc
> --- /dev/null
> +++ b/drivers/gpu/ipu-v3/ipu-vdi.c
> @@ -0,0 +1,266 @@
> +/*
> + * Copyright (C) 2012 Mentor Graphics Inc.
> + * Copyright (C) 2005-2009 Freescale Semiconductor, Inc.
> + *
> + * 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.
> + */
> +#include 
> +#include 

You have a u32 field in a struct called "modules" but aside from that, I do not
see anything in this code requiring module.h -- did I miss something?

You might want export.h for EXPORT_SYMBOL though.

Paul.
--

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu-prv.h"
> +

[...]


Re: [PATCH] include: mman: Use bool instead of int for the return value of arch_validate_prot

2016-07-10 Thread Dave Hansen
On 07/09/2016 09:29 AM, cheng...@emindsoft.com.cn wrote:
> -static inline int arch_validate_prot(unsigned long prot)
> +static inline bool arch_validate_prot(unsigned long prot)
>  {
>   if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_SAO))
> - return 0;
> - if ((prot & PROT_SAO) && !cpu_has_feature(CPU_FTR_SAO))
> - return 0;
> - return 1;
> + return false;
> + return (prot & PROT_SAO) == 0 || cpu_has_feature(CPU_FTR_SAO);
>  }
>  #define arch_validate_prot(prot) arch_validate_prot(prot)

Please don't do things like this.  They're not obviously correct and
also have no obvious benefit.  You also don't mention why you bothered
to alter the logical structure of these checks.


[PATCH] tmpfs: fix regression hang in fallocate undo

2016-07-10 Thread Hugh Dickins
The well-spotted fallocate undo fix is good in most cases, but not when
fallocate failed on the very first page.  index 0 then passes lend -1
to shmem_undo_range(), and that has two bad effects: (a) that it will
undo every fallocation throughout the file, unrestricted by the current
range; but more importantly (b) it can cause the undo to hang, because
lend -1 is treated as truncation, which makes it keep on retrying until
every page has gone, but those already fully instantiated will never go
away.  Big thank you to xfstests generic/269 which demonstrates this.

Fixes: b9b4bb26af01 ("tmpfs: don't undo fallocate past its last page")
Cc: sta...@vger.kernel.org
Signed-off-by: Hugh Dickins 
---

 mm/shmem.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- 4.7-rc6/mm/shmem.c  2016-06-26 22:02:27.543373427 -0700
+++ linux/mm/shmem.c2016-07-10 15:19:24.0 -0700
@@ -2225,9 +2225,11 @@ static long shmem_fallocate(struct file
error = shmem_getpage(inode, index, , SGP_FALLOC);
if (error) {
/* Remove the !PageUptodate pages we added */
-   shmem_undo_range(inode,
-   (loff_t)start << PAGE_SHIFT,
-   ((loff_t)index << PAGE_SHIFT) - 1, true);
+   if (index > start) {
+   shmem_undo_range(inode,
+   (loff_t)start << PAGE_SHIFT,
+   ((loff_t)index << PAGE_SHIFT) - 1, true);
+   }
goto undone;
}
 


[PATCH] f2fs: return proper error code

2016-07-10 Thread Tiezhu Yang
When the length of file name is more than F2FS_NAME_LEN,
it should return -ENAMETOOLONG.

Signed-off-by: Tiezhu Yang 
---
 fs/f2fs/xattr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 28a5023..b225062 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -364,7 +364,7 @@ int f2fs_getxattr(struct inode *inode, int index, const 
char *name,
 
len = strlen(name);
if (len > F2FS_NAME_LEN)
-   return -ERANGE;
+   return -ENAMETOOLONG;
 
base_addr = read_all_xattrs(inode, ipage);
if (!base_addr)
@@ -458,7 +458,7 @@ static int __f2fs_setxattr(struct inode *inode, int index,
len = strlen(name);
 
if (len > F2FS_NAME_LEN)
-   return -ERANGE;
+   return -ENAMETOOLONG;
 
if (size > MAX_VALUE_LEN(inode))
return -E2BIG;
-- 
1.8.3.1

Re: [PATCH v15 07/10] arm64: kprobes instruction simulation support

2016-07-10 Thread Paul Gortmaker
On Fri, Jul 8, 2016 at 12:35 PM, David Long  wrote:
> From: Sandeepa Prabhu 
>
> Kprobes needs simulation of instructions that cannot be stepped
> from a different memory location, e.g.: those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is implemented using a copy of pt_regs.
>
> The following instruction categories are simulated:
>  - All branching instructions(conditional, register, and immediate)
>  - Literal access instructions(load-literal, adr/adrp)
>
> Conditional execution is limited to branching instructions in
> ARM v8. If conditions at PSTATE do not match the condition fields
> of opcode, the instruction is effectively NOP.
>
> Thanks to Will Cohen for assorted suggested changes.
>
> Signed-off-by: Sandeepa Prabhu 
> Signed-off-by: William Cohen 
> Signed-off-by: David A. Long 
> Acked-by: Masami Hiramatsu 
> ---
>  arch/arm64/include/asm/probes.h  |   5 +-
>  arch/arm64/kernel/insn.c |   1 +
>  arch/arm64/kernel/probes/Makefile|   3 +-
>  arch/arm64/kernel/probes/decode-insn.c   |  33 -
>  arch/arm64/kernel/probes/decode-insn.h   |   1 +
>  arch/arm64/kernel/probes/kprobes.c   |  53 ++--
>  arch/arm64/kernel/probes/simulate-insn.c | 218 
> +++
>  arch/arm64/kernel/probes/simulate-insn.h |  28 
>  8 files changed, 327 insertions(+), 15 deletions(-)
>  create mode 100644 arch/arm64/kernel/probes/simulate-insn.c
>  create mode 100644 arch/arm64/kernel/probes/simulate-insn.h
>
>

[...]

> diff --git a/arch/arm64/kernel/probes/simulate-insn.c 
> b/arch/arm64/kernel/probes/simulate-insn.c
> new file mode 100644
> index 000..429c333
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/simulate-insn.c
> @@ -0,0 +1,218 @@
> +/*
> + * arch/arm64/kernel/probes/simulate-insn.c
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 

Maybe I missed something, but I don't see anything modular about this
code, so why include this?

Paul.
--

> +
> +#include "simulate-insn.h"
> +
> +#define sign_extend(x, signbit)\
> +   ((x) | (0 - ((x) & (1 << (signbit)
> +
> +#define bbl_displacement(insn) \
> +   sign_extend(((insn) & 0x3ff) << 2, 27)
> +
> +#define bcond_displacement(insn)   \
> +   sign_extend(((insn >> 5) & 0x7) << 2, 20)
 > +   disp = ldr_displacement(opcode);
> +   load_addr = (s32 *) (addr + disp);
> +
> +   set_x_reg(regs, xn, *load_addr);
> +
> +   instruction_pointer_set(regs, instruction_pointer(regs) + 4);
> +}


Re: [PATCH 2/2] net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings

2016-07-10 Thread Philippe Reynes

Hi all,


On 05/07/16 23:40, Ben Hutchings wrote:

On Tue, 2016-07-05 at 14:15 -0700, Florian Fainelli wrote:

On 07/05/2016 02:07 PM, Philippe Reynes wrote:

Hi Florian,

On 05/07/16 06:30, Florian Fainelli wrote:

Le 04/07/2016 16:03, David Miller a écrit :

From: Philippe Reynes
Date: Sun,  3 Jul 2016 17:33:57 +0200


There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.

Signed-off-by: Philippe Reynes


Applied.



The transformation is not equivalent, we lost the checks on
netif_running() in the process, and those are here for a reason, if the
interface is down and therefore clock gated, MDIO accesses to the PHY
will simply fail outright and cause bus errors.


Oh, I see, I've missed this. Sorry for this mistake.
We should revert this path.


Well, maybe better than that, actually put the check in the generic
functions, because if the link is down, aka netif_running() returns
false, link parameters cannot be reliably queried and they are invalid.


In my understanding, if the link is down, the pointer phydev in the
struct net_device is NULL. So generic functions 
phy_ethtool_{get|set}_link_ksetting
should return -ENODEV.

If I'm wrong, and it everybody agree, I'll send a patch that add a check
on netif_running.


Either the hardware or the driver needs to remember:

- Is auto-negotiation enabled
- If so, which modes are advertised
- If not, which mode is forced

And it should still be possible to get or set that information when the
interface is down.


It could be possible to save the set_link_ksettings request if the link
is down, and apply it when the link become up.
It also could be possible to save the last state of the link before it
goes to down, and return it to a get_link_ksettings when the link is down.
But what happen if the link was never up before the first get_link_kettings ?

If everybody agree with this, I may send a patch that implement this idea.


Philippe


Re: Update the maximum depth of C-state from 6 to 9

2016-07-10 Thread Jonathan Corbet
On Mon, 4 Jul 2016 09:55:10 +0800
"baolex.ni"  wrote:

> Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
> and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of 
> C-state.
> This change is reflected in one place of the kernel-param file,
> but not in the other place where I suggest changing.
> 
> Signed-off-by: Chuansheng Liu 
> Signed-off-by: Baole Ni 

So why are there two signoffs on a single-line patch?  Which one of you
is the actual author?

Thanks,

jon


Re: [PATCH v2 09/10] Documentation: devicetree: Add dts description for nuc900

2016-07-10 Thread Arnd Bergmann
On Sunday, July 10, 2016 3:42:21 PM CEST Wan Zongshun wrote:
> diff --git 
> a/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,nuc900-soc.txt 
> b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,nuc900-soc.txt
> new file mode 100644
> index 000..0284edf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,nuc900-soc.txt
> @@ -0,0 +1,12 @@
> +. Nuvoton NUC900 series, Soc specific driver binding.
> +
> +Required properties:
> +- compatible : Should be "nuvoton,nuc900-soc"
> +- syscon : Reference to gcr controller.
> +
> +Example:
> +
> +reset {
> +   compatible = "nuvoton,nuc900-soc";
> +   syscon = <>;
> +};

I think this one should be dropped: Instead of modeling the DT based on what
is convenient for the current Linux driver implementation, we only want to
list devices in the dts that are physically present, and the "soc" is really
the sum of all the on-chip devices.

Better change the soc_device driver to bind directly to the "nuvoton,nuc970-gcr"
device.

Arnd


Re: [PATCH v2 09/10] Documentation: devicetree: Add dts description for nuc900

2016-07-10 Thread Arnd Bergmann
On Sunday, July 10, 2016 3:42:21 PM CEST Wan Zongshun wrote:
> +
> +Required properties:
> +- compatible : Should be "nuvoton,nuc970-tmr"
> +- reg : Address and length of the register set
> +- clocks : Reference on the timer input clock
> +- interrupts : Reference to the timer interrupt
> +
> +Example:
> +
> +tmr@0xb8001000 {

The name should be "timer", not "tmr", and the address should
not contain a leading "0x".

> +   compatible = "nuvoton,nuc970-tmr";
> +   reg = <0xb8001000 0x1000>;
> +   interrupts = <16>;
> +   clocks = < TIMER0_GATE>,
> +   < TIMER1_GATE>;
> +   clock-names = "timer0", "timer1";
> +};

The clocks/clock-names description does not match the example:
you only define a single clock in the required properties, but
have two separate inputs in the example. Please fix one or the
other.

Arnd


Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

2016-07-10 Thread Arnd Bergmann
On Sunday, July 10, 2016 3:27:21 PM CEST Wan Zongshun wrote:
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static void __init nuc900_machine_init(void)
> +{
> +   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}


This is the default for .init_machine, so you can leave the function
undefined.

> +static const char *nuc900_dt_compat[] __initconst = {
> +   "nuvoton,nuc970",
> +   NULL,
> +};
> +
> +DT_MACHINE_START(nuc900_dt, "Nuvoton NUC900 (Device Tree Support)")
> +   .init_machine   = nuc900_machine_init,
> +   .dt_compat  = nuc900_dt_compat,
> +MACHINE_END
> 

After that, you can probably remove most of the #include statements.
The file is still needed for now, until you move to ARCH_MULTIPLATFORM,
at which point the entire machine descriptor is redundant.

Arnd


Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900

2016-07-10 Thread Paul Gortmaker
On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun  wrote
> This driver is to add reset support for nuc900 series,
> currently, it only supports nuc970 SoC reset.
>
> Signed-off-by: Wan Zongshun 
> ---
>  drivers/power/reset/Kconfig|  7 +++
>  drivers/power/reset/Makefile   |  1 +
>  drivers/power/reset/nuc900-reset.c | 93 
> ++
>  3 files changed, 101 insertions(+)
>  create mode 100644 drivers/power/reset/nuc900-reset.c
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index 9bb2622..8c84892 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -94,6 +94,13 @@ config POWER_RESET_MSM
> help
>   Power off and restart support for Qualcomm boards.
>
> +config POWER_RESET_NUC900
> +   bool "Nuc900 restart driver"

If this driver is bool and not tristate, then please remove all references
to MODULE_ and then the module.h include as well.

Thanks,
Paul.
--

> +   depends on ARCH_W90X900
> +   help
> + Power off and restart support for Nuvoton NUC900 family of
> + reference boards.
> +
>  config POWER_RESET_LTC2952
> bool "LTC2952 PowerPath power-off driver"
> depends on OF_GPIO
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index ab7aa86..d4df889 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
>  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
>  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
>  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> +obj-$(CONFIG_POWER_RESET_NUC900) += nuc900-reset.o
>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
>  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
>  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> diff --git a/drivers/power/reset/nuc900-reset.c 
> b/drivers/power/reset/nuc900-reset.c
> new file mode 100644
> index 000..49986b7
> --- /dev/null
> +++ b/drivers/power/reset/nuc900-reset.c
> @@ -0,0 +1,93 @@
> +/*
> + * Copyright 2016 Wan Zongshun 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>

[...]


Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

2016-07-10 Thread Paul Gortmaker
On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun  wrote:
> This patch is to add irqchip driver support for nuc900 plat,
> current this driver only supports nuc970 SoC.
>
> Signed-off-by: Wan Zongshun 
> ---
>  arch/arm/mach-w90x900/include/mach/irqs.h |   5 +
>  drivers/irqchip/Makefile  |   1 +
>  drivers/irqchip/irq-nuc900.c  | 150 
> ++
>  3 files changed, 156 insertions(+)
>  create mode 100644 drivers/irqchip/irq-nuc900.c
>
> diff --git a/arch/arm/mach-w90x900/include/mach/irqs.h 
> b/arch/arm/mach-w90x900/include/mach/irqs.h
> index 9d5cba3..3b035c6 100644
> --- a/arch/arm/mach-w90x900/include/mach/irqs.h
> +++ b/arch/arm/mach-w90x900/include/mach/irqs.h
> @@ -59,7 +59,12 @@
>  #define IRQ_KPIW90X900_IRQ(29)
>  #define IRQ_P2SGROUP   W90X900_IRQ(30)
>  #define IRQ_ADCW90X900_IRQ(31)
> +
> +#if !defined(CONFIG_SOC_NUC900)
>  #define NR_IRQS(IRQ_ADC+1)
> +#else
> +#define NR_IRQS62
> +#endif
>
>  /*for irq group*/
>
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 38853a1..9ccd5af8a 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)  += irq-pic32-evic.o
>  obj-$(CONFIG_MVEBU_ODMI)   += irq-mvebu-odmi.o
>  obj-$(CONFIG_LS_SCFG_MSI)  += irq-ls-scfg-msi.o
>  obj-$(CONFIG_EZNPS_GIC)+= irq-eznps.o
> +obj-$(CONFIG_SOC_NUC970)   += irq-nuc900.o
> diff --git a/drivers/irqchip/irq-nuc900.c b/drivers/irqchip/irq-nuc900.c
> new file mode 100644
> index 000..c4b2e39
> --- /dev/null
> +++ b/drivers/irqchip/irq-nuc900.c
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright 2016 Wan Zongshun 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include 

Why do you include module.h when I don't see anything modular in
this driver?

Paul.
--

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +

[...]


[PATCH] dmaengine: pxa_dma: implement device_synchronize

2016-07-10 Thread Robert Jarzmik
Implement the function which wait until a dma channel is stopped to have
a synchronization point.

This also protects the pxad_remove() from races, such as spurious
interrupts while removing the driver, because :
 - as long as there is one dma channel requested, ie. dma_chan_get() but
   no dma_chan_put(), the try_module_get() of dma_chan_get() prevents
   the remove() routine from running
 - when the last channel is released, ie. the last dma_chan_put() is
   called, if there is a running DMA, pxad_synchronize() is called
 - pxad_synchronize() waits for the channel to stop, which in turn
   ensures on pxa architecture that the interrupt cannot be fired anymore

Reported-by: Vinod Koul 
Signed-off-by: Robert Jarzmik 
---
 drivers/dma/pxa_dma.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index e756a30ccba2..cbd96038cfd0 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "dmaengine.h"
@@ -118,6 +119,8 @@ struct pxad_chan {
struct pxad_phy *phy;
struct dma_pool *desc_pool; /* Descriptors pool */
dma_cookie_tbus_error;
+
+   wait_queue_head_t   wq_state;
 };
 
 struct pxad_device {
@@ -572,6 +575,7 @@ static void pxad_launch_chan(struct pxad_chan *chan,
 */
phy_writel(chan->phy, desc->first, DDADR);
phy_enable(chan->phy, chan->misaligned);
+   wake_up(>wq_state);
 }
 
 static void set_updater_desc(struct pxad_desc_sw *sw_desc,
@@ -717,6 +721,7 @@ static irqreturn_t pxad_chan_handler(int irq, void *dev_id)
}
}
spin_unlock_irqrestore(>vc.lock, flags);
+   wake_up(>wq_state);
 
return IRQ_HANDLED;
 }
@@ -1268,6 +1273,14 @@ static enum dma_status pxad_tx_status(struct dma_chan 
*dchan,
return ret;
 }
 
+static void pxad_synchronize(struct dma_chan *dchan)
+{
+   struct pxad_chan *chan = to_pxad_chan(dchan);
+
+   wait_event(chan->wq_state, !is_chan_running(chan));
+   vchan_synchronize(>vc);
+}
+
 static void pxad_free_channels(struct dma_device *dmadev)
 {
struct pxad_chan *c, *cn;
@@ -1372,6 +1385,7 @@ static int pxad_init_dmadev(struct platform_device *op,
pdev->slave.device_tx_status = pxad_tx_status;
pdev->slave.device_issue_pending = pxad_issue_pending;
pdev->slave.device_config = pxad_config;
+   pdev->slave.device_synchronize = pxad_synchronize;
pdev->slave.device_terminate_all = pxad_terminate_all;
 
if (op->dev.coherent_dma_mask)
@@ -1389,6 +1403,7 @@ static int pxad_init_dmadev(struct platform_device *op,
return -ENOMEM;
c->vc.desc_free = pxad_free_desc;
vchan_init(>vc, >slave);
+   init_waitqueue_head(>wq_state);
}
 
return dma_async_device_register(>slave);
-- 
2.1.4



Saudações

2016-07-10 Thread harry . martant
Saudações,
  Eu sou a senhora Annie Ethan de uma empresa de crédito privado 
conhecido como Aspire dinheiro Loan®. Oferecemos todos os tipos de empréstimo a 
taxa de juro de 3%. Se você está na necessidade de empréstimo favor 
contacte-nos com as informações abaixo.
Nome completo:
Gênero:
País:
Endereço:
Montante do empréstimo:
Duração:
Tel:
Aguardamos sua resposta se você estiver interessado
Obrigado,
Annie Ethan


[PATCH 2/2] iio: humidity: hdc100x: remove lock on heater configuration read

2016-07-10 Thread Alison Schofield
The lock around the read (from global data) of the heater configuration
status is not needed.  Move the lock in IIO_CHAN_INFO_RAW case to only
protect the get measurement function.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/humidity/hdc100x.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
index ad5a12a..8195b0c 100644
--- a/drivers/iio/humidity/hdc100x.c
+++ b/drivers/iio/humidity/hdc100x.c
@@ -193,18 +193,18 @@ static int hdc100x_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_RAW: {
int ret;
 
-   mutex_lock(>lock);
if (chan->type == IIO_CURRENT) {
*val = hdc100x_get_heater_status(data);
ret = IIO_VAL_INT;
} else {
+   mutex_lock(>lock);
ret = hdc100x_get_measurement(data, chan);
+   mutex_unlock(>lock);
if (ret >= 0) {
*val = ret;
ret = IIO_VAL_INT;
}
}
-   mutex_unlock(>lock);
return ret;
}
case IIO_CHAN_INFO_INT_TIME:
-- 
2.1.4



[PATCH 1/2] iio: humidity: hdc100x: move lock on config updates to single function

2016-07-10 Thread Alison Schofield
Move the config register locking to the config update function.  This
continues to protect updates to heater and integration times. It puts
the lock in one place, right where it needs to occur.

Add the checkpatch required comment on this lock declaration.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/humidity/hdc100x.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
index a03832a..ad5a12a 100644
--- a/drivers/iio/humidity/hdc100x.c
+++ b/drivers/iio/humidity/hdc100x.c
@@ -31,7 +31,7 @@
 
 struct hdc100x_data {
struct i2c_client *client;
-   struct mutex lock;
+   struct mutex lock;  /* protect config updates & raw measurements */
u16 config;
 
/* integration time of the sensor */
@@ -108,10 +108,12 @@ static int hdc100x_update_config(struct hdc100x_data 
*data, int mask, int val)
int tmp = (~mask & data->config) | val;
int ret;
 
+   mutex_lock(>lock);
ret = i2c_smbus_write_word_swapped(data->client,
HDC100X_REG_CONFIG, tmp);
if (!ret)
data->config = tmp;
+   mutex_unlock(>lock);
 
return ret;
 }
@@ -234,26 +236,20 @@ static int hdc100x_write_raw(struct iio_dev *indio_dev,
 int val, int val2, long mask)
 {
struct hdc100x_data *data = iio_priv(indio_dev);
-   int ret = -EINVAL;
 
switch (mask) {
case IIO_CHAN_INFO_INT_TIME:
if (val != 0)
return -EINVAL;
 
-   mutex_lock(>lock);
-   ret = hdc100x_set_it_time(data, chan->address, val2);
-   mutex_unlock(>lock);
-   return ret;
+   return hdc100x_set_it_time(data, chan->address, val2);
+
case IIO_CHAN_INFO_RAW:
if (chan->type != IIO_CURRENT || val2 != 0)
return -EINVAL;
 
-   mutex_lock(>lock);
-   ret = hdc100x_update_config(data, HDC100X_REG_CONFIG_HEATER_EN,
+   return hdc100x_update_config(data, HDC100X_REG_CONFIG_HEATER_EN,
val ? HDC100X_REG_CONFIG_HEATER_EN : 0);
-   mutex_unlock(>lock);
-   return ret;
default:
return -EINVAL;
}
-- 
2.1.4



[PATCH 0/2] iio: humidity: hdc100x: update driver locking

2016-07-10 Thread Alison Schofield
This patchset intends to tidy up the driver locking. 

The global data lock needs to to protect writes to the configuration
register and single channel reads which can be of temp or humidity.

First patch moves the config register locking to the config update
function.  This continues to protect updates to heater and integration
times. It puts the lock in one place, right where it needs to occur.

Second patch removes the lock on configuration reads of data stored
in global data.  While the write lock prevents two simultaneous writes
(ie. Heater and int_time) to the register, which could return false
success status, the read doesn't have the same issue.  You get the 
status at the moment, at it's guaranteed for that moment only.
This also aligns with drivers non-locking of other reads of global
data configuration status - ie integration time.
  
I believe these changes stand alone as good cleanups to the locking.
Alas, my ulterior motive is to prep it so that I can cleanly apply
the locks for triggered buffer mode.

 
Alison Schofield (2):
  iio: humidity: hdc100x: move lock on config updates to single function
  iio: humidity: hdc100x: remove lock on heater configuration read

 drivers/iio/humidity/hdc100x.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

-- 
2.1.4



Re: [CRIU] Introspecting userns relationships to other namespaces?

2016-07-10 Thread James Bottomley
On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote:
> Andrew Vagin  writes:
> 
> > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote:
> > > "W. Trevor King"  writes:
> > > 
> > > > On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley
> > > > wrote:
> > > > > In theory, we could get nsfs to show this information as an
> > > > > option
> > > > > (just add a show_options entry to the superblock ops), but
> > > > > the
> > > > > problem is that although each namespace has a parent user_ns,
> > > > > there's no way to get it without digging in the namespace
> > > > > specific
> > > > > structure.  Probably we should restructure to move it into
> > > > > ns_common, then we could display it (and enforce all
> > > > > namespaces
> > > > > having owning user_ns) but it would be a reasonably large
> > > > > (but
> > > > > mechanical) change.
> > > > 
> > > > It sounds like everyone is either positive or or neutral on
> > > > this
> > > > groundwork, even if we haven't decided if/how to expose the
> > > > information to userspace.  I'm happy to work up a patch while
> > > > the rest
> > > > of the discussion continues.  I'm also happy to let someone
> > > > else work
> > > > up the patch, if anyone else is chomping at the bit ;).
> > > 
> > > I am dubious on moving all of the user namespace members into
> > > ns_common.
> > > 
> > > I would happy to be proved wrong but I suspect in the cases where
> > > we
> > > actually use that user namespace the code will become uglier. 
> > >  Making
> > > the ordinary uses uglier to make a rare corner case nicer is the
> > > wrong
> > > trade off.
> > > 
> > > But feel free to try it is certainly worth doing if it doesn't
> > > make the
> > > code that uses the user namespaces uglier.
> > 
> > If it's interesting for someone, I have this patch in my tree
> > https://github.com/avagin/linux-task-diag/commit/63b32df68ae8d3a384
> > 2bae42bbcae3468db76d85
> > 
> > I can't say that it makes something uglier.
> 
> I have only skimmed things but overall it looks better than I had
> feared.

It looks about as messy as I feared, but since someone else has done
all the hard work, I'm happy.

> At the same time I really really don't like losing the parent pointer 
> in the user namespace case.  That is seriously obfuscating.

Because it has a slightly different meaning from all other namespaces? 
 If I assume that's what you mean, I think looking at it in a different
way can solve the problem:  The pointer in ns_common is always to the
owning user_ns, so we can label it as such.  Even for a child user_ns,
the owning user_ns is simply the parent.  I think it makes logical
sense to think of all user_ns to namespace relationships as
owning/owned rather than most as owning/owned and some as parent/child.

James

> Eric
> 
> ___
> Containers mailing list
> contain...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
> 



  1   2   3   >