[PATCH v3 2/5] [RESEND] [media]: rockchip/rga: v4l2 m2m support

[Jacob Chen]

Rockchip RGA is a separate 2D raster graphic acceleration unit. It
accelerates 2D graphics operations, such as point/line drawing, image
scaling, rotation, BitBLT, alpha blending and image blur/sharpness

The drvier is mostly based on s5p-g2d v4l2 m2m driver
And supports various operations from the rendering pipeline.
 - copy
 - fast solid color fill
 - rotation
 - flip
 - alpha blending

The code in rga-hw.c is used to configure regs accroding to operations
The code in rga-buf.c is used to create (1-Level)mmu table for RGA

Signed-off-by: Jacob Chen 
---
 drivers/media/platform/Kconfig|  11 +
 drivers/media/platform/Makefile   |   2 +
 drivers/media/platform/rockchip-rga/Makefile  |   3 +
 drivers/media/platform/rockchip-rga/rga-buf.c | 141 
 drivers/media/platform/rockchip-rga/rga-hw.c  | 650 +
 drivers/media/platform/rockchip-rga/rga-hw.h  | 437 
 drivers/media/platform/rockchip-rga/rga.c | 987 ++
 drivers/media/platform/rockchip-rga/rga.h | 110 +++
 8 files changed, 2341 insertions(+)
 create mode 100644 drivers/media/platform/rockchip-rga/Makefile
 create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip-rga/rga.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c9106e1..8199bcf 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -411,6 +411,17 @@ config VIDEO_RENESAS_VSP1
  To compile this driver as a module, choose M here: the module
  will be called vsp1.
 
+config VIDEO_ROCKCHIP_RGA
+   tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
+   select VIDEOBUF2_DMA_SG
+   select V4L2_MEM2MEM_DEV
+   default n
+   ---help---
+ This is a v4l2 driver for Rockchip SOC RGA2
+ 2d graphics accelerator.
+
 config VIDEO_TI_VPE
tristate "TI VPE (Video Processing Engine) driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 349ddf6..3bf096f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -54,6 +54,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)  += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1/
 
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA)   += rockchip-rga/
+
 obj-y  += omap/
 
 obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
diff --git a/drivers/media/platform/rockchip-rga/Makefile 
b/drivers/media/platform/rockchip-rga/Makefile
new file mode 100644
index 000..92fe254
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/Makefile
@@ -0,0 +1,3 @@
+rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
+
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c 
b/drivers/media/platform/rockchip-rga/rga-buf.c
new file mode 100644
index 000..b4d28e3
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/rga-buf.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Jacob Chen 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rga-hw.h"
+#include "rga.h"
+
+static int
+rga_queue_setup(struct vb2_queue *vq,
+   unsigned int *nbuffers, unsigned int *nplanes,
+   unsigned int sizes[], struct device *alloc_devs[])
+{
+   struct rga_ctx *ctx = vb2_get_drv_priv(vq);
+   struct rga_frame *f = rga_get_frame(ctx, vq->type);
+
+   if (IS_ERR(f))
+   return PTR_ERR(f);
+
+   sizes[0] = f->size;
+   *nplanes = 1;
+
+   if (*nbuffers == 0)
+   *nbuffers = 1;
+
+   return 0;
+}
+
+static int rga_buf_prepare(struct vb2_buffer *vb)
+{
+   struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+   struct rga_frame *f = rga_get_frame(ctx, vb->vb2_queue->type);
+
+   if (IS_ERR(f))
+   return PTR_ERR(f);
+
+   vb2_set_plane_payload(vb, 0, f->size);
+
+   return 0;
+}
+
+static void rga_buf_queue(struct vb2_buffer *vb)
+{
+   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+   st

RE: [RFC][PATCH] thunderbolt: icm: Ignore mailbox errors in icm_suspend()

[Jamet, Michael]

> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, July 26, 2017 20:05
> To: Mika Westerberg 
> Cc: LKML ; Linux PM  p...@vger.kernel.org>; Andreas Noever ;
> Jamet, Michael ; Greg Kroah-Hartman
> 
> Subject: Re: [RFC][PATCH] thunderbolt: icm: Ignore mailbox errors in
> icm_suspend()
> 
> >
> > Acked-by: Mika Westerberg 

A bit late in the party.
Acked-by: Michael Jamet 
-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH v3 2/5] [RESEND] [media]: rockchip/rga: v4l2 m2m support

[Jacob Chen]

Hi,

2017-07-31 14:51 GMT+08:00 Jacob Chen :
> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> accelerates 2D graphics operations, such as point/line drawing, image
> scaling, rotation, BitBLT, alpha blending and image blur/sharpness
>
> The drvier is mostly based on s5p-g2d v4l2 m2m driver
> And supports various operations from the rendering pipeline.
>  - copy
>  - fast solid color fill
>  - rotation
>  - flip
>  - alpha blending
>
> The code in rga-hw.c is used to configure regs accroding to operations
> The code in rga-buf.c is used to create (1-Level)mmu table for RGA
>
> Signed-off-by: Jacob Chen 
> ---
>  drivers/media/platform/Kconfig|  11 +
>  drivers/media/platform/Makefile   |   2 +
>  drivers/media/platform/rockchip-rga/Makefile  |   3 +
>  drivers/media/platform/rockchip-rga/rga-buf.c | 141 
>  drivers/media/platform/rockchip-rga/rga-hw.c  | 650 +
>  drivers/media/platform/rockchip-rga/rga-hw.h  | 437 
>  drivers/media/platform/rockchip-rga/rga.c | 987 
> ++
>  drivers/media/platform/rockchip-rga/rga.h | 110 +++
>  8 files changed, 2341 insertions(+)
>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c9106e1..8199bcf 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -411,6 +411,17 @@ config VIDEO_RENESAS_VSP1
>   To compile this driver as a module, choose M here: the module
>   will be called vsp1.
>
> +config VIDEO_ROCKCHIP_RGA
> +   tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
> +   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> +   depends on ARCH_ROCKCHIP || COMPILE_TEST
> +   select VIDEOBUF2_DMA_SG
> +   select V4L2_MEM2MEM_DEV
> +   default n
> +   ---help---
> + This is a v4l2 driver for Rockchip SOC RGA2
> + 2d graphics accelerator.
> +
>  config VIDEO_TI_VPE
> tristate "TI VPE (Video Processing Engine) driver"
> depends on VIDEO_DEV && VIDEO_V4L2
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 349ddf6..3bf096f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -54,6 +54,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)  += rcar_fdp1.o
>  obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
>  obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1/
>
> +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA)   += rockchip-rga/
> +
>  obj-y  += omap/
>
>  obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
> diff --git a/drivers/media/platform/rockchip-rga/Makefile 
> b/drivers/media/platform/rockchip-rga/Makefile
> new file mode 100644
> index 000..92fe254
> --- /dev/null
> +++ b/drivers/media/platform/rockchip-rga/Makefile
> @@ -0,0 +1,3 @@
> +rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
> +
> +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
> diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c 
> b/drivers/media/platform/rockchip-rga/rga-buf.c
> new file mode 100644
> index 000..b4d28e3
> --- /dev/null
> +++ b/drivers/media/platform/rockchip-rga/rga-buf.c
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Jacob Chen 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "rga-hw.h"
> +#include "rga.h"
> +
> +static int
> +rga_queue_setup(struct vb2_queue *vq,
> +   unsigned int *nbuffers, unsigned int *nplanes,
> +   unsigned int sizes[], struct device *alloc_devs[])
> +{
> +   struct rga_ctx *ctx = vb2_get_drv_priv(vq);
> +   struct rga_frame *f = rga_get_frame(ctx, vq->type);
> +
> +   if (IS_ERR(f))
> +   return PTR_ERR(f);
> +
> +   sizes[0] = f->size;
> +   *nplanes = 1;
> +
> +   if (*nbuffers == 0)
> +   *nbuffers = 1;
> +
> +   return 0;
> +}
> +
> +static int rga_buf_prepare(struct vb2_buffer *vb)
> +{
> +   struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> +   struct rga_frame 

Re: [linux-sunxi] [PATCH v3 00/12] ASoC: Add I2S support for Allwinner H3 SoCs

[Olliver Schinagl]

Hey Marcus,

On 29-07-17 16:17, codekip...@gmail.com wrote:

From: Marcus Cooper 

Hi All,
please find attached a series of patches to bring i2s support to the
Allwinner H3 SoC. This has been tested with the following setups:

A20 Olimex EVB connected to a pcm5102

But that's not an H3 is it? :)


Orange Pi 2 connected to a uda1380
Orange Pi 2 hdmi audio playback
Pine 64 connected to the audio DAC board

To get i2s working some additional patches are required which will be
delivered later. For now they have been pushed here

https://github.com/codekipper/linux-sunxi/commits/sunxi-audio-h3


Since I want to use i2s on the A20, i'm trying out your patches. It 
would be helpfull if you could point out which patches are missing (and 
if the subject doesn't cover it why those are needed)




I don't own a A33 device which uses the i2s block for the audio codec
so if someone could test against that it would be much appreciated.

I'm also wondering if there is a preferred way of setting the lrclk
size in the dts?..currently it is set to the sample width but for example
the pcm5102a wants it to be 32 bits whatever the sample rate.

Thanks in advance,
CK

---

v3 changes compared to v2 are:
- initial changes to prepare driver for newer SoCs has been broken down
  into smaller patches
- reduce use of regmap fields to where just needed.
- clkdiv expansion will be delivered later.
- defines for H3 variant segregated.
- fixed regmap config issue with SUN8I_I2S_FIFO_TX_REG.


v2 changes compared to v1 are:
 - massive refactoring to remove duplicate code making use of regmap_fields.
 - extending the clock divisors.
 - removed code that should be delivered when we support 20/24bits

---

Marcus Cooper (12):
  ASoC: sun4i-i2s: Extend quirks scope
  ASoC: sun4i-i2s: Add clkdiv offsets to quirks
  ASoC: sun4i-i2s: Add regmap config to quirks
  ASoC: sun4i-i2s: Add TX FIFO offset to quirks
  ASoC: sun4i-i2s: Add regmap fields for channels
  ASoC: sun4i-i2s: Add changes for wss and sr
  ASoC: sun4i-i2s: bclk and lrclk polarity tidyup
  ASoC: sun4i-i2s: Add mclk enable regmap field
  ASoC: sun4i-i2s: Add regmap field to set format
  ASoC: sun4i-i2s: Check for slave select bit
  ASoC: sun4i-i2s: Update global enable with bitmask
  ASoC: sun4i-i2s: Add support for H3

 .../devicetree/bindings/sound/sun4i-i2s.txt|   2 +
 sound/soc/sunxi/sun4i-i2s.c| 460 ++---
 2 files changed, 398 insertions(+), 64 deletions(-)

RE: [PATCH 06/11] usb: renesas_usbhs: constify hc_driver structures

[Yoshihiro Shimoda]

Hi,

> From: Julia Lawall
> Sent: Saturday, July 29, 2017 5:42 AM
> 
> The hc_driver structure is only passed as the first argument to
> usb_create_hcd, which is declared as const.  Thus the hc_driver structure
> itself can be const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Thank you for the patch!

Acked-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

Re: [PATCH] infiniband: avoid overflow warning

[Moni Shoua]

On Mon, Jul 31, 2017 at 9:50 AM, Arnd Bergmann  wrote:
> A sockaddr_in structure on the stack getting passed into rdma_ip2gid
> triggers this warning, since we memcpy into a larger sockaddr_in6
> structure:
>
> In function 'memcpy',
> inlined from 'rdma_ip2gid' at include/rdma/ib_addr.h:175:3,
> inlined from 'addr_event.isra.4.constprop' at 
> drivers/infiniband/core/roce_gid_mgmt.c:693:2,
> inlined from 'inetaddr_event' at 
> drivers/infiniband/core/roce_gid_mgmt.c:716:9:
> include/linux/string.h:305:4: error: call to '__read_overflow2' declared with 
> attribute error: detected read beyond size of object passed as 2nd parameter
>
> The warning seems appropriate here, but the code is also clearly
> correct, so we really just want to shut up this instance of the
> output.
>
> The best way I found so far is to avoid the memcpy() call and instead
> replace it with a struct assignment.
>
> Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified 
> string.h functions")
> Cc: Daniel Micay 
> Cc: Kees Cook 
> Signed-off-by: Arnd Bergmann 
> ---
>  include/rdma/ib_addr.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/rdma/ib_addr.h b/include/rdma/ib_addr.h
> index 7aca12188ef3..ec5008cf5d51 100644
> --- a/include/rdma/ib_addr.h
> +++ b/include/rdma/ib_addr.h
> @@ -172,7 +172,8 @@ static inline int rdma_ip2gid(struct sockaddr *addr, 
> union ib_gid *gid)
>(struct in6_addr *)gid);
> break;
> case AF_INET6:
> -   memcpy(gid->raw, &((struct sockaddr_in6 *)addr)->sin6_addr, 
> 16);
> +   *(struct in6_addr *)&gid->raw =
> +   ((struct sockaddr_in6 *)addr)->sin6_addr;
> break;
> default:
> return -EINVAL;
what happens if you replace 16 with sizeof(struct in6_addr)?

Re: IRQ_ONESHOT expectations vs mask/unmask

[Thomas Gleixner]

Ben,

On Mon, 31 Jul 2017, Benjamin Herrenschmidt wrote:
> I noticed a problem with some powerpc systems with threaded IRQs. I
> hadn't looked at threaded irq in the past so there was a bit of
> discovery involved. That lead to a few questions:
> 
>  - Threaded IRQs rely on IRQF_ONESHOT. Now, is that a flag/feature that
> is generally exposed to drivers even in the non-threaded case, and if
> yes, what core callback are drivers expected to use to "unmask" the
> oneshot interrupt ?

The oneshot flag should not have any effects when the interrupt is
non-threaded. Emphasis on should. I'm not sure whether that's true, will
have a look.

>  - I don't see any provisions for dealing with interrupts lost while
> masked. So on some PICs on powerpc, while we do use "fast EOI", we also
> have a chance of edge interrupts (MSIs) being lost while masked. This
> wasn't a problem until now because we used lazy disabling. However, it
> looks like IRQF_ONESHOT (and thus threaded irqs) rely on masked
> interrupts being latched in HW, otherwise an interrupt might be lost
> between the threaded handler completing and the interrupt being
> unmasked, or am I missing something ?
>
>  - I noticed that other flow handlers (edge, edge_eoi, ...) don't have
> any provision for IRQF_ONESHOT. Isn't that a problem ? Or will the core
> silently swallow subsequent interrupts until the thread has completed
> anyway ? (I might be missing something here).

The only case where IRQF_ONESHOT should have an effect is with level type
interrupts. That's required, because otherwise the hardware interrupt would
fire for ever. Level type interrupts should not need any hardware latching,
we assume that they fire once they are unmasked.

For edge type interrupts we do not mask the interrupt in order not to lose
an interrupt. If the interrupt fires while the thread handler is running,
we mark the thread and once it the handler returns it gets called again.

> Generally, how do you suggest I fix the threaded irq problem for XICS ?

You asked a lot of questions, but you failed to explain the problem for
XICS.

Thanks,

tglx

Re: [PATCH 10/11] greybus: usb: constify hc_driver structures

[Johan Hovold]

On Fri, Jul 28, 2017 at 10:41:57PM +0200, Julia Lawall wrote:
> The hc_driver structure is only passed as the first argument to
> usb_create_hcd, which is declared as const.  Thus the hc_driver structure
> itself can be const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Acked-by: Johan Hovold 

Thanks,
Johan

Re: [PATCH 3/4] clk: sunxi-ng: Make fractional helper less chatty

[Chen-Yu Tsai]

()On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec
 wrote:
> ccu_frac_helper_read_rate() prints some info which is not really
> helpful except during debugging.
>
> Replace printk() with pr_debug().
>
> Signed-off-by: Jernej Skrabec 

Queued as a fix for 4.13 with the following tag:

Fixes: 89a3dfb78707 ("clk: sunxi-ng: Add fractional lib")

The rationale being the previous two patches actually enable
the ccu_frac_helper_read_rate() code path, and we don't want
the users to be annoyed by all the noise.

ChenYu

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

[Christoph Hellwig]

On Mon, Jul 31, 2017 at 07:16:59AM +0900, Minchan Kim wrote:
> rw_page's gain is reducing of dynamic allocation in swap path
> as well as performance gain thorugh avoiding bio allocation.
> And it would be important in memory pressure situation.

There is no need for any dynamic allocation when using the bio
path.  Take a look at __blkdev_direct_IO_simple for an example
that doesn't do any allocations.

[PATCH] Staging: vc04_services: Fix WARN_ON instead of BUG_ON

[janani-sankarababu]

This patch is to replace the use of BUG_ON macro with WARN_ON
inorder to prevent the crashing of the kernel.

Signed-off-by: Janani Sankara Babu 
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index f484bb0..30bc246 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -91,7 +91,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol *kcontrol,
if (mutex_lock_interruptible(&chip->audio_mutex))
return -EINTR;
 
-   BUG_ON(!chip && !(chip->avail_substreams & AVAIL_SUBSTREAMS_MASK));
+   WARN_ON(!chip && !(chip->avail_substreams & AVAIL_SUBSTREAMS_MASK));
 
if (kcontrol->private_value == PCM_PLAYBACK_VOLUME)
ucontrol->value.integer.value[0] = chip2alsa(chip->volume);
-- 
1.9.1

Re: [PATCH v3 0/5] Add Rockchip RGA V4l2 support

[Jacob Chen]

Hi,


2017-07-31 11:07 GMT+08:00 Jacob Chen :
> This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering 
> based 2d graphics acceleration module.
>
> Before, my colleague yakir have write a drm RGA drvier and send it to the 
> lists.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/416769.html
> I have been asked to find a userspace user("compositor") for it, but after 
> some studys, my conclusion is that unlike exynos g2d,
> rockchip rga are not suitable for compositor. Rockchip RGA have a limited 
> MMU, which means it can only hold several buffers in the same time.
> When it was used in compositor, it will waste a lot of time to 
> import/export/flush buffer, resulting in a bad performance.
>
> A few months ago, i saw a discussion in dri-de...@lists.freedesktop.org.
> It remind that we could write a v4l2 m2m RGA driver, since we usually use RGA 
> for streaming purpose.
> https://patches.linaro.org/cover/97727/
>
> I have test this driver with gstreamer v4l2transform plugin and it seems work 
> well.
>
> change in V3:
> - rename the controls.
> - add pm_runtime support.
> - enable node by default.
> - correct spelling in documents.
>
> change in V2:
> - generalize the controls.
> - map buffers (10-50 us) in every cmd-run rather than in buffer-import to 
> avoid get_free_pages failed on
> actively used systems.
> - remove status in dt-bindings examples.
>
> Jacob Chen (5):
>   [media] v4l: add blend modes controls
>   [media]: rockchip/rga: v4l2 m2m support
>   ARM: dts: rockchip: add RGA device node for RK3288
>   ARM: dts: rockchip: add RGA device node for RK3399
>   dt-bindings: Document the Rockchip RGA bindings
>
>  .../devicetree/bindings/media/rockchip-rga.txt |  33 +
>  arch/arm/boot/dts/rk3288.dtsi  |  11 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi   |  11 +
>  drivers/media/platform/Kconfig |  11 +
>  drivers/media/platform/Makefile|   2 +
>  drivers/media/platform/rockchip-rga/Makefile   |   3 +
>  drivers/media/platform/rockchip-rga/rga-buf.c  | 141 +++
>  drivers/media/platform/rockchip-rga/rga-hw.c   | 650 ++
>  drivers/media/platform/rockchip-rga/rga-hw.h   | 437 +
>  drivers/media/platform/rockchip-rga/rga.c  | 987 
> +
>  drivers/media/platform/rockchip-rga/rga.h  | 110 +++
>  drivers/media/v4l2-core/v4l2-ctrls.c   |  20 +-
>  include/uapi/linux/v4l2-controls.h |  16 +-
>  13 files changed, 2430 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
>
> --
> 2.7.4
>

We are going to use this driver in our BSP, and write userspace for it.
Though there are some work needed be done for better use, i'm
satisfied with it at present.
It could be improved through usage.

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Tomi Sarvela]

On 28/07/17 19:26, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 17:50, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 17:13, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 16:15, Thomas Gleixner wrote:

Another question. Is the machine completely dead or not?


Completely dead. Powerled is on, so host isn't shut down.


So that means it does not even power the machine down. That's what I
expected least.


Serial or network if don't give any signs of life.



Patch applies cleanly but still getting the same error:


Sorry for the noise. I'm an idiot trying to do 10 things at once. This
time
it actually compiles and links.

If the machine does still not powerdown with this applied, then please
redo
the 'platform' test and grab the trace for that one.


This patch fixes the issue. Below is the dmesg from the testrun (sorry for
the spam, we're primarily testing i915 issues).


Can you please retrieve the trace data from:

/sys/kernel/debug/tracing/trace

and provide that. The dmesg does not help much.


Right, here you go.


Thanks for providing the data. Just to be sure, that data was from a real
suspend, not the 'platform' test, right?

If so, that does not make any sense at all. The patch merily changes the
enable/resume path and adds the debug trace printks which have no influence
on the disable logic. But you said that the machine does not power off in
the bad case. That does not make any sense at all as the enable logic is
not involved at all in the suspend path.

Did you change anything else compared to the tests before ?


I did check that the problem persisted in linus-HEAD before testing your 
patch. The testing was done in order (reading from console logs I happen 
to still have in one window):


- reboot to patched kernel

[0.00] Linux version 4.13.0-rc2+ (testrunner@elk) (gcc version 
6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)) #5 SMP PREEMPT Fri Jul 28 
17:15:47 EEST 2017
[0.00] Command line: BOOT_IMAGE=/boot/tsa.efi root=/dev/sda1 
console=ttyS0,115200n8 console=tty0 intel_iommu=igfx_off drm.debug=0xe 
nmi_watchdog=panic,auto panic=1 softdog.soft_panic=1 
scsi_mod.use_blk_mq=0 rootwait ro 3


- "real" 15sec suspend test through IGT/piglit and rtcwake

$ ./scripts/run-tests.sh -vt igt@gem_exec_suspend@basic-s3 -x devices

- dmesg to go with suspend

[ 1189.597665] Suspended for 14.825 seconds
[ 1189.597665] Delta way too big! 18446743991837909721 
ts=18446744056274518328 write stamp = 64436608607

   If you just came from a suspend/resume,
   please switch to the trace global clock:
 echo global > /sys/kernel/debug/tracing/trace_clock
[ 1189.597665] [ cut here ]
[ 1189.597665] WARNING: CPU: 0 PID: 1332 at 
kernel/trace/ring_buffer.c:2647 rb_handle_timestamp.isra.32+0x71/0x80
[ 1189.597665] Modules linked in: snd_hda_codec_realtek i915 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core 
coretemp snd_pcm e1000e lpc_ich mei_me ptp mei pps_core
[ 1189.597665] CPU: 0 PID: 1332 Comm: rtcwake Tainted: G U 
4.13.0-rc2+ #5
[ 1189.597665] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT 
PC/3647h, BIOS 786G7 v01.13 07/20/2011

[ 1189.597665] task: 88010dce9880 task.stack: c90c8000
[ 1189.597665] RIP: 0010:rb_handle_timestamp.isra.32+0x71/0x80
[ 1189.597665] RSP: 0018:c90cbab0 EFLAGS: 00010082
[ 1189.597665] RAX: 00e0 RBX: c90cbad0 RCX: 
0004
[ 1189.597665] RDX: 8004 RSI: 0082 RDI: 

[ 1189.597665] RBP: c90cbac0 R08:  R09: 
00e0
[ 1189.597665] R10: c90cbbe0 R11: 000ebc08 R12: 
880117008890
[ 1189.597665] R13: 8801170088b0 R14: 03e8 R15: 
0005
[ 1189.597665] FS:  7f93d957e700() GS:88011bc0() 
knlGS:

[ 1189.597665] CS:  0010 DS:  ES:  CR0: 80050033
[ 1189.597665] CR2: 00f00255b068 CR3: d9063000 CR4: 
000406f0

[ 1189.597665] Call Trace:
[ 1189.597665]  ring_buffer_lock_reserve+0x1fa/0x350
[ 1189.597665]  trace_vbprintk+0xdc/0x260
[ 1189.597665]  ? __irq_disable+0x1b/0xc0
[ 1189.597665]  __trace_bprintk+0x4a/0x60
[ 1189.597665]  ? preempt_count_add+0x9e/0xb0
[ 1189.597665]  __irq_disable+0x3f/0xc0
[ 1189.597665]  irq_disable+0x17/0x20
[ 1189.597665]  __disable_irq_nosync+0x59/0x70
[ 1189.597665]  disable_hardirq+0x11/0x30
[ 1189.597665]  hpet_msi_resume+0x85/0xd0
[ 1189.597665]  clockevents_tick_resume+0x14/0x20
[ 1189.597665]  tick_resume_local+0x32/0x60
[ 1189.597665]  tick_resume+0x13/0x20
[ 1189.597665]  timekeeping_resume+0x149/0x1a0
[ 1189.597665]  syscore_resume+0x4b/0x190
[ 1189.597665]  ? syscore_resume+0x4b/0x190
[ 1189.597665]  suspend_devices_and_enter+0x6b9/0x810
[ 1189.597665]  pm_suspend+0x367/0x540
[ 1189.597665]  state_store+0x7e/0xf0
[ 1189.5976

Re: [PATCH] fs: convert a pile of fsync routines to errseq_t based reporting

[Jan Kara]

On Fri 28-07-17 10:23:21, Jeff Layton wrote:
> From: Jeff Layton 
> 
> This patch converts most of the in-kernel filesystems that do writeback
> out of the pagecache to report errors using the errseq_t-based
> infrastructure that was recently added. This allows them to report
> errors once for each open file description.
> 
> Most filesystems have a fairly straightforward fsync operation. They
> call filemap_write_and_wait_range to write back all of the data and
> wait on it, and then (sometimes) sync out the metadata.
> 
> For those filesystems this is a straightforward conversion from calling
> filemap_write_and_wait_range in their fsync operation to calling
> file_write_and_wait_range.
> 
> Signed-off-by: Jeff Layton 

This all looks rather obvious. Feel free to add:

Acked-by: Jan Kara 

Honza


> ---
>  arch/powerpc/platforms/cell/spufs/file.c   | 2 +-
>  drivers/staging/lustre/lustre/llite/file.c | 2 +-
>  drivers/video/fbdev/core/fb_defio.c| 2 +-
>  fs/9p/vfs_file.c   | 4 ++--
>  fs/affs/file.c | 2 +-
>  fs/afs/write.c | 2 +-
>  fs/cifs/file.c | 4 ++--
>  fs/exofs/file.c| 2 +-
>  fs/f2fs/file.c | 2 +-
>  fs/hfs/inode.c | 2 +-
>  fs/hfsplus/inode.c | 2 +-
>  fs/hostfs/hostfs_kern.c| 2 +-
>  fs/hpfs/file.c | 2 +-
>  fs/jffs2/file.c| 2 +-
>  fs/jfs/file.c  | 2 +-
>  fs/ncpfs/file.c| 2 +-
>  fs/ntfs/dir.c  | 2 +-
>  fs/ntfs/file.c | 2 +-
>  fs/ocfs2/file.c| 2 +-
>  fs/reiserfs/dir.c  | 2 +-
>  fs/reiserfs/file.c | 2 +-
>  fs/ubifs/file.c| 2 +-
>  22 files changed, 24 insertions(+), 24 deletions(-)
> 
> Rolling up all of these conversions into a single patch, as Christoph
> Hellwig suggested. Most of these are not tested, but the conversion
> here is fairly straightforward.
> 
> Any maintainers who object, please let me know and I'll yank that
> part out of this patch.
> 
> diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
> b/arch/powerpc/platforms/cell/spufs/file.c
> index ae2f740a82f1..5ffcdeb1eb17 100644
> --- a/arch/powerpc/platforms/cell/spufs/file.c
> +++ b/arch/powerpc/platforms/cell/spufs/file.c
> @@ -1749,7 +1749,7 @@ static int spufs_mfc_flush(struct file *file, 
> fl_owner_t id)
>  static int spufs_mfc_fsync(struct file *file, loff_t start, loff_t end, int 
> datasync)
>  {
>   struct inode *inode = file_inode(file);
> - int err = filemap_write_and_wait_range(inode->i_mapping, start, end);
> + int err = file_write_and_wait_range(file, start, end);
>   if (!err) {
>   inode_lock(inode);
>   err = spufs_mfc_flush(file, NULL);
> diff --git a/drivers/staging/lustre/lustre/llite/file.c 
> b/drivers/staging/lustre/lustre/llite/file.c
> index ab1c85c1ed38..f7d07735ac66 100644
> --- a/drivers/staging/lustre/lustre/llite/file.c
> +++ b/drivers/staging/lustre/lustre/llite/file.c
> @@ -2364,7 +2364,7 @@ int ll_fsync(struct file *file, loff_t start, loff_t 
> end, int datasync)
>  PFID(ll_inode2fid(inode)), inode);
>   ll_stats_ops_tally(ll_i2sbi(inode), LPROC_LL_FSYNC, 1);
>  
> - rc = filemap_write_and_wait_range(inode->i_mapping, start, end);
> + rc = file_write_and_wait_range(file, start, end);
>   inode_lock(inode);
>  
>   /* catch async errors that were recorded back when async writeback
> diff --git a/drivers/video/fbdev/core/fb_defio.c 
> b/drivers/video/fbdev/core/fb_defio.c
> index 37f69c061210..487d5e336e1b 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -69,7 +69,7 @@ int fb_deferred_io_fsync(struct file *file, loff_t start, 
> loff_t end, int datasy
>  {
>   struct fb_info *info = file->private_data;
>   struct inode *inode = file_inode(file);
> - int err = filemap_write_and_wait_range(inode->i_mapping, start, end);
> + int err = file_write_and_wait_range(file, start, end);
>   if (err)
>   return err;
>  
> diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
> index 3de3b4a89d89..4802d75b3cf7 100644
> --- a/fs/9p/vfs_file.c
> +++ b/fs/9p/vfs_file.c
> @@ -445,7 +445,7 @@ static int v9fs_file_fsync(struct file *filp, loff_t 
> start, loff_t end,
>   struct p9_wstat wstat;
>   int retval;
>  
> - retval = filemap_write_and_wait_range(inode->i_mapping, start, end);
> + retval = file_write_and_wait_range(filp, start, end);
>   if (retval)
>   return retval;
>  
> @@ -468,7 +468,7 @@ int v9fs_file_fsync_dotl(struct file *filp, loff_t start,

Re: [PATCH] infiniband: avoid overflow warning

[Arnd Bergmann]

On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua  wrote:
> On Mon, Jul 31, 2017 at 9:50 AM, Arnd Bergmann  wrote:
>> --- a/include/rdma/ib_addr.h
>> +++ b/include/rdma/ib_addr.h
>> @@ -172,7 +172,8 @@ static inline int rdma_ip2gid(struct sockaddr *addr, 
>> union ib_gid *gid)
>>(struct in6_addr *)gid);
>> break;
>> case AF_INET6:
>> -   memcpy(gid->raw, &((struct sockaddr_in6 *)addr)->sin6_addr, 
>> 16);
>> +   *(struct in6_addr *)&gid->raw =
>> +   ((struct sockaddr_in6 *)addr)->sin6_addr;
>> break;
>> default:
>> return -EINVAL;
> what happens if you replace 16 with sizeof(struct in6_addr)?

Same thing: the problem is that gcc already knows the size of the structure we
pass in here, and it is in fact shorter.

I also tried changing the struct sockaddr pointer to a sockaddr_storage pointer,
without success. Other approaches that do work are:

- mark addr_event() as "noinline" to prevent gcc from seeing the true
size of the
  inetaddr_event stack object in rdma_ip2gid(). I considered this a little ugly.

- change inetaddr_event to put a larger structure on the stack, using
  sockaddr_storage or sockaddr_in6. This would be less efficient.

- define a union of sockaddr_in and sockaddr_in6, and use that as the argument
  to rdma_ip2gid/rdma_gid2ip, and change all callers to use that union type.
  This is probably the cleanest approach as it gets rid of a lot of questionable
  type casts, but it's a relatively large patch and also slightly less
efficient as we have
  to zero more stack storage in some cases.

Arnd

Re: [linux-sunxi] [PATCH] pinctrl: sunxi: rename R_PIO i2c pin function name

[Chen-Yu Tsai]

On Sun, Jul 30, 2017 at 1:36 PM, Icenowy Zheng  wrote:
> The I2C pin functions in R_PIO used to be named "s_twi".
>
> As we usually use the name "i2c" instead of "twi" in the mainline
> kernel, change these names to "s_i2c" for consistency.
>
> The "s_twi" functions are not yet referenced by any device trees in
> mainline kernel so I think it's safe to change the name.
>
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Chen-Yu Tsai 

[PATCH V9 1/3] powernv: powercap: Add support for powercap framework

[Shilpasri G Bhat]

Adds a generic powercap framework to change the system powercap
inband through OPAL-OCC command/response interface.

Signed-off-by: Shilpasri G Bhat 
---
 .../ABI/testing/sysfs-firmware-opal-powercap   |  31 +++
 arch/powerpc/include/asm/opal-api.h|   5 +-
 arch/powerpc/include/asm/opal.h|   4 +
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-powercap.c | 244 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   2 +
 arch/powerpc/platforms/powernv/opal.c  |   4 +
 7 files changed, 290 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-powercap
 create mode 100644 arch/powerpc/platforms/powernv/opal-powercap.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-powercap 
b/Documentation/ABI/testing/sysfs-firmware-opal-powercap
new file mode 100644
index 000..c9b66ec
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-powercap
@@ -0,0 +1,31 @@
+What:  /sys/firmware/opal/powercap
+Date:  August 2017
+Contact:   Linux for PowerPC mailing list 
+Description:   Powercap directory for Powernv (P8, P9) servers
+
+   Each folder in this directory contains a
+   power-cappable component.
+
+What:  /sys/firmware/opal/powercap/system-powercap
+   /sys/firmware/opal/powercap/system-powercap/powercap-min
+   /sys/firmware/opal/powercap/system-powercap/powercap-max
+   /sys/firmware/opal/powercap/system-powercap/powercap-current
+Date:  August 2017
+Contact:   Linux for PowerPC mailing list 
+Description:   System powercap directory and attributes applicable for
+   Powernv (P8, P9) servers
+
+   This directory provides powercap information. It
+   contains below sysfs attributes:
+
+   - powercap-min : This file provides the minimum
+ possible powercap in Watt units
+
+   - powercap-max : This file provides the maximum
+ possible powercap in Watt units
+
+   - powercap-current : This file provides the current
+ powercap set on the system. Writing to this file
+ creates a request for setting a new-powercap. The
+ powercap requested must be between powercap-min
+ and powercap-max.
diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 3130a73..c3e0c4a 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -42,6 +42,7 @@
 #define OPAL_I2C_STOP_ERR  -24
 #define OPAL_XIVE_PROVISIONING -31
 #define OPAL_XIVE_FREE_ACTIVE  -32
+#define OPAL_TIMEOUT   -33
 
 /* API Tokens (in r0) */
 #define OPAL_INVALID_CALL -1
@@ -190,7 +191,9 @@
 #define OPAL_NPU_INIT_CONTEXT  146
 #define OPAL_NPU_DESTROY_CONTEXT   147
 #define OPAL_NPU_MAP_LPAR  148
-#define OPAL_LAST  148
+#define OPAL_GET_POWERCAP  152
+#define OPAL_SET_POWERCAP  153
+#define OPAL_LAST  153
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 588fb1c..ec2087c 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -267,6 +267,8 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int64_t opal_xive_free_irq(uint32_t girq);
 int64_t opal_xive_sync(uint32_t type, uint32_t id);
 int64_t opal_xive_dump(uint32_t type, uint32_t id);
+int opal_get_powercap(u32 handle, int token, u32 *pcap);
+int opal_set_powercap(u32 handle, int token, u32 pcap);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -345,6 +347,8 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 
 void opal_wake_poller(void);
 
+void opal_powercap_init(void);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index b5d98cb..e79f806 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o
+obj-y  += opal-kmsg.o opal-powercap.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-powercap.c 
b/arch/powerpc/platforms/po

[PATCH V9 0/3] powernv : Add support for OPAL-OCC command/response interface

[Shilpasri G Bhat]

In P9, OCC (On-Chip-Controller) supports shared memory based
commad-response interface. Within the shared memory there is an OPAL
command buffer and OCC response buffer that can be used to send
inband commands to OCC. The following commands are supported:

1) Set system powercap
2) Set CPU-GPU power shifting ratio
3) Clear min/max for OCC sensor groups

Changes from V9:
- Fixed return after erroring from mutex_lock_interruptible()
- Added documentation

Shilpasri G Bhat (3):
  powernv: powercap: Add support for powercap framework
  powernv: Add support to set power-shifting-ratio
  powernv: Add support to clear sensor groups data

 .../ABI/testing/sysfs-firmware-opal-powercap   |  31 +++
 Documentation/ABI/testing/sysfs-firmware-opal-psr  |  18 ++
 .../bindings/powerpc/opal/sensor-groups.txt|  23 ++
 arch/powerpc/include/asm/opal-api.h|   8 +-
 arch/powerpc/include/asm/opal.h|   9 +
 arch/powerpc/include/uapi/asm/opal-occ.h   |  23 ++
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-occ.c  | 116 ++
 arch/powerpc/platforms/powernv/opal-powercap.c | 244 +
 arch/powerpc/platforms/powernv/opal-psr.c  | 175 +++
 arch/powerpc/platforms/powernv/opal-wrappers.S |   5 +
 arch/powerpc/platforms/powernv/opal.c  |  10 +
 12 files changed, 662 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-powercap
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-psr
 create mode 100644 
Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt
 create mode 100644 arch/powerpc/include/uapi/asm/opal-occ.h
 create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c
 create mode 100644 arch/powerpc/platforms/powernv/opal-powercap.c
 create mode 100644 arch/powerpc/platforms/powernv/opal-psr.c

-- 
1.8.3.1

[PATCH v5 08/10] arm: dts: mt7623: enable the nand device on the mt7623n nand rfb

[sean.wang]

From: John Crispin 

Enable the nand device and setup pinmux on the mt7632m rfb with nand
support.

Signed-off-by: John Crispin 
Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623n-rfb-nand.dts | 88 ++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623n-rfb-nand.dts 
b/arch/arm/boot/dts/mt7623n-rfb-nand.dts
index ba7d1ab..63ffb78 100644
--- a/arch/arm/boot/dts/mt7623n-rfb-nand.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb-nand.dts
@@ -19,3 +19,91 @@
model = "MediaTek MT7623N NAND reference board";
compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";
 };
+
+&pio {
+   nand_pins_default: nanddefault {
+   pins_dat {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   input-enable;
+   drive-strength = ;
+   bias-pull-up;
+   };
+
+   pins_we {
+   pinmux = ;
+   drive-strength = ;
+   bias-pull-up = ;
+   };
+
+   pins_ale {
+   pinmux = ;
+   drive-strength = ;
+   bias-pull-down = ;
+   };
+   };
+};
+
+&nandc {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&nand_pins_default>;
+   nand@0 {
+   reg = <0>;
+   spare_per_sector = <64>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <12>;
+   nand-ecc-step-size = <1024>;
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "preloader";
+   reg = <0x0 0x4>;
+   };
+
+   partition@4 {
+   label = "uboot";
+   reg = <0x4 0x8>;
+   };
+
+   partition@C {
+   label = "uboot-env";
+   reg = <0xC 0x4>;
+   };
+
+   partition@14 {
+   label = "bootimg";
+   reg = <0x14 0x200>;
+   };
+
+   partition@214 {
+   label = "recovery";
+   reg = <0x214 0x200>;
+   };
+
+   partition@414 {
+   label = "rootfs";
+   reg = <0x414 0x100>;
+   };
+
+   partition@514 {
+   label = "usrdata";
+   reg = <0x514 0x100>;
+   };
+   };
+   };
+};
+
+&bch {
+   status = "okay";
+};
-- 
2.7.4

[PATCH V9 3/3] powernv: Add support to clear sensor groups data

[Shilpasri G Bhat]

Adds support for clearing different sensor groups. OCC inband sensor
groups like CSM, Profiler, Job Scheduler can be cleared using this
driver. The min/max of all sensors belonging to these sensor groups
will be cleared.

Signed-off-by: Shilpasri G Bhat 
---
 .../bindings/powerpc/opal/sensor-groups.txt|  23 
 arch/powerpc/include/asm/opal-api.h|   3 +-
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/include/uapi/asm/opal-occ.h   |  23 
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-occ.c  | 116 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   3 +
 8 files changed, 171 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt
 create mode 100644 arch/powerpc/include/uapi/asm/opal-occ.h
 create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c

diff --git a/Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt 
b/Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt
new file mode 100644
index 000..304b87c
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt
@@ -0,0 +1,23 @@
+IBM OPAL Sensor Groups Binding
+---
+
+Node: /ibm,opal/sensor-groups
+
+Description: Contains sensor groups available in the Powernv P9
+servers. Each child node indicates a sensor group.
+
+- compatible : Should be "ibm,opal-occ-sensor-group"
+
+Each child node contains below properties:
+
+- type : String to indicate the type of sensor-group
+
+- sensor-group-id: Abstract unique identifier provided by firmware of
+  type  which is used for sensor-group
+  operations like clearing the min/max history of all
+  sensors belonging to the group.
+
+- ibm,chip-id : Chip ID
+
+- sensors : Phandle array of child nodes of /ibm,opal/sensor/
+   belonging to this group
diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 92e31fd..0841659 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -195,7 +195,8 @@
 #define OPAL_SET_POWERCAP  153
 #define OPAL_GET_POWER_SHIFT_RATIO 154
 #define OPAL_SET_POWER_SHIFT_RATIO 155
-#define OPAL_LAST  155
+#define OPAL_SENSOR_GROUPS_CLEAR   156
+#define OPAL_LAST  156
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index b9ea77f..a716def 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -271,6 +271,7 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int opal_set_powercap(u32 handle, int token, u32 pcap);
 int opal_get_power_shift_ratio(u32 handle, int token, u32 *psr);
 int opal_set_power_shift_ratio(u32 handle, int token, u32 psr);
+int opal_sensor_groups_clear(u32 group_hndl, int token);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -351,6 +352,7 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 
 void opal_powercap_init(void);
 void opal_psr_init(void);
+int opal_sensor_groups_clear_history(u32 handle);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/powerpc/include/uapi/asm/opal-occ.h 
b/arch/powerpc/include/uapi/asm/opal-occ.h
new file mode 100644
index 000..97c45e2
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/opal-occ.h
@@ -0,0 +1,23 @@
+/*
+ * OPAL OCC command interface
+ * Supported on POWERNV platform
+ *
+ * (C) Copyright IBM 2017
+ *
+ * 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, 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.
+ */
+
+#ifndef _UAPI_ASM_POWERPC_OPAL_OCC_H_
+#define _UAPI_ASM_POWERPC_OPAL_OCC_H_
+
+#define OPAL_OCC_IOCTL_CLEAR_SENSOR_GROUPS _IOR('o', 1, u32)
+
+#endif /* _UAPI_ASM_POWERPC_OPAL_OCC_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index 9ed7d33..f193b33 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o

[PATCH V9 2/3] powernv: Add support to set power-shifting-ratio

[Shilpasri G Bhat]

This patch adds support to set power-shifting-ratio which hints the
firmware how to distribute/throttle power between different entities
in a system (e.g CPU v/s GPU). This ratio is used by OCC for power
capping algorithm.

Signed-off-by: Shilpasri G Bhat 
---
 Documentation/ABI/testing/sysfs-firmware-opal-psr |  18 +++
 arch/powerpc/include/asm/opal-api.h   |   4 +-
 arch/powerpc/include/asm/opal.h   |   3 +
 arch/powerpc/platforms/powernv/Makefile   |   2 +-
 arch/powerpc/platforms/powernv/opal-psr.c | 175 ++
 arch/powerpc/platforms/powernv/opal-wrappers.S|   2 +
 arch/powerpc/platforms/powernv/opal.c |   3 +
 7 files changed, 205 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-psr
 create mode 100644 arch/powerpc/platforms/powernv/opal-psr.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-psr 
b/Documentation/ABI/testing/sysfs-firmware-opal-psr
new file mode 100644
index 000..cc2ece7
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-psr
@@ -0,0 +1,18 @@
+What:  /sys/firmware/opal/psr
+Date:  August 2017
+Contact:   Linux for PowerPC mailing list 
+Description:   Power-Shift-Ratio directory for Powernv P9 servers
+
+   Power-Shift-Ratio allows to provide hints the firmware
+   to shift/throttle power between different entities in
+   the system. Each attribute in this directory indicates
+   a settable PSR.
+
+What:  /sys/firmware/opal/psr/cpu_to_gpu_X
+Date:  August 2017
+Contact:   Linux for PowerPC mailing list 
+Description:   PSR sysfs attributes for Powernv P9 servers
+
+   Power-Shift-Ratio between CPU and GPU for a given chip
+   with chip-id X. This file gives the ratio (0-100)
+   which is used by OCC for power-capping.
diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index c3e0c4a..92e31fd 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -193,7 +193,9 @@
 #define OPAL_NPU_MAP_LPAR  148
 #define OPAL_GET_POWERCAP  152
 #define OPAL_SET_POWERCAP  153
-#define OPAL_LAST  153
+#define OPAL_GET_POWER_SHIFT_RATIO 154
+#define OPAL_SET_POWER_SHIFT_RATIO 155
+#define OPAL_LAST  155
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ec2087c..b9ea77f 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -269,6 +269,8 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int64_t opal_xive_dump(uint32_t type, uint32_t id);
 int opal_get_powercap(u32 handle, int token, u32 *pcap);
 int opal_set_powercap(u32 handle, int token, u32 pcap);
+int opal_get_power_shift_ratio(u32 handle, int token, u32 *psr);
+int opal_set_power_shift_ratio(u32 handle, int token, u32 psr);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -348,6 +350,7 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 void opal_wake_poller(void);
 
 void opal_powercap_init(void);
+void opal_psr_init(void);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index e79f806..9ed7d33 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o opal-powercap.o
+obj-y  += opal-kmsg.o opal-powercap.o opal-psr.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-psr.c 
b/arch/powerpc/platforms/powernv/opal-psr.c
new file mode 100644
index 000..7313b7f
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-psr.c
@@ -0,0 +1,175 @@
+/*
+ * PowerNV OPAL Power-Shift-Ratio interface
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) "opal-psr: " fmt
+
+#include 
+#include 
+#include 
+
+#include 
+
+DEFINE_MUTEX(psr_mutex);
+
+static struct kobject *psr_kobj;
+
+struct psr_attr {
+   u32 handle;
+   struct kobj_attribute att

[PATCH v5 04/10] arm: dts: mt7623: rename mt7623-evb.dts to arch/arm/boot/dts/mt7623n-rfb.dtsi

[sean.wang]

From: Sean Wang 

There are 2 versions of the MT7623 SoC, the one is MT7623N and the other
is MT7623A.  MT7623N is almost identical to MT7623A but has some
additional multimedia features. The reference boards are available as
NAND or MMC and might have a different ethernet setup. In order to reduce
the duplication of devicetree code we add an intermediate dtsi file for
these reference boards. Additionally MediaTek pointed out, that the EVB
is yet another board and the board in question is infact the RFB. Take
this into account while renaming the files.

Signed-off-by: John Crispin 
Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/Makefile  |  2 +-
 arch/arm/boot/dts/mt7623n-rfb-nand.dts  | 21 +
 .../boot/dts/{mt7623-evb.dts => mt7623n-rfb.dtsi}   |  8 +++-
 3 files changed, 25 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/mt7623n-rfb-nand.dts
 rename arch/arm/boot/dts/{mt7623-evb.dts => mt7623n-rfb.dtsi} (87%)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35..f3a2442 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1049,7 +1049,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt6580-evbp1.dtb \
mt6589-aquaris5.dtb \
mt6592-evb.dtb \
-   mt7623-evb.dtb \
+   mt7623n-rfb-nand.dtb \
mt8127-moose.dtb \
mt8135-evbp1.dtb
 dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
diff --git a/arch/arm/boot/dts/mt7623n-rfb-nand.dts 
b/arch/arm/boot/dts/mt7623n-rfb-nand.dts
new file mode 100644
index 000..ba7d1ab
--- /dev/null
+++ b/arch/arm/boot/dts/mt7623n-rfb-nand.dts
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: John Crispin 
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "mt7623n-rfb.dtsi"
+
+/ {
+   model = "MediaTek MT7623N NAND reference board";
+   compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";
+};
diff --git a/arch/arm/boot/dts/mt7623-evb.dts 
b/arch/arm/boot/dts/mt7623n-rfb.dtsi
similarity index 87%
rename from arch/arm/boot/dts/mt7623-evb.dts
rename to arch/arm/boot/dts/mt7623n-rfb.dtsi
index 0686ad7..805ba69 100644
--- a/arch/arm/boot/dts/mt7623-evb.dts
+++ b/arch/arm/boot/dts/mt7623n-rfb.dtsi
@@ -1,6 +1,7 @@
 /*
- * Copyright (c) 2016 MediaTek Inc.
+ * Copyright (c) 2017 MediaTek Inc.
  * Author: John Crispin 
+ *Sean Wang 
  *
  * 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
@@ -17,9 +18,6 @@
 #include "mt6323.dtsi"
 
 / {
-   model = "MediaTek MT7623 evaluation board";
-   compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
-
chosen {
stdout-path = &uart2;
};
@@ -42,7 +40,7 @@
};
};
 
-   memory {
+   memory@8000 {
reg = <0 0x8000 0 0x4000>;
};
 };
-- 
2.7.4

Re: [RFC PATCH 1/4] serial: uartps: Remove console_initcall from the driver

[Michal Simek]

On 21.7.2017 17:47, Sören Brinkmann wrote:
> On Fri, 2017-07-21 at 11:32:24 +0200, Michal Simek wrote:
>> register_console() is called from
>> uart_add_one_port()->uart_configure_port()
>> that's why register_console() is called twice.
>>
>> This patch remove console_initcall to call register_console() only from
>> one location.
>>
>> Also based on my tests cdns_uart_console_setup() is not called
>> from the first register_console() call.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>> I am not quite sure about this because console_initcall is called
>> early but I can see any difference in usage.
>> pl011 is not calling this but others are doing it.
> 
> Doesn't this break early console/printk? I would expect that the UART
> initialization may happen later than console init.

as I said. I can't see any issue with it. Definitely please try.

Thanks,
Michal

[PATCH v5 03/10] arm: dts: mt7623: add mt6323.dtsi file

[sean.wang]

From: John Crispin 

MediaTek produces various PMICs. Which one is used depends on the actual
circuit design. Instead of adding the correct PMIC node to every dts file
we instead add a new intermediate dtsi file which adds the PMIC node. For
those boards with the same PMIC, the intermediate mt6323.dtsi could be
reused to save more redundant nodes created on each board device-tree
files.

Signed-off-by: John Crispin 
Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt6323.dtsi| 241 +++
 arch/arm/boot/dts/mt7623-evb.dts |  29 +
 arch/arm/boot/dts/mt7623.dtsi|   8 +-
 3 files changed, 274 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/boot/dts/mt6323.dtsi

diff --git a/arch/arm/boot/dts/mt6323.dtsi b/arch/arm/boot/dts/mt6323.dtsi
new file mode 100644
index 000..7c783d6
--- /dev/null
+++ b/arch/arm/boot/dts/mt6323.dtsi
@@ -0,0 +1,241 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: John Crispin 
+ *Sean Wang 
+ * 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.
+ */
+
+&pwrap {
+   pmic: mt6323 {
+   compatible = "mediatek,mt6323";
+   interrupt-parent = <&pio>;
+   interrupts = <150 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   mt6323regulator: mt6323regulator{
+   compatible = "mediatek,mt6323-regulator";
+
+   mt6323_vproc_reg: buck_vproc{
+   regulator-name = "vproc";
+   regulator-min-microvolt = < 70>;
+   regulator-max-microvolt = <135>;
+   regulator-ramp-delay = <12500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vsys_reg: buck_vsys{
+   regulator-name = "vsys";
+   regulator-min-microvolt = <140>;
+   regulator-max-microvolt = <2987500>;
+   regulator-ramp-delay = <25000>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vpa_reg: buck_vpa{
+   regulator-name = "vpa";
+   regulator-min-microvolt = < 50>;
+   regulator-max-microvolt = <365>;
+   };
+
+   mt6323_vtcxo_reg: ldo_vtcxo{
+   regulator-name = "vtcxo";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <90>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vcn28_reg: ldo_vcn28{
+   regulator-name = "vcn28";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_vcn33_bt_reg: ldo_vcn33_bt{
+   regulator-name = "vcn33_bt";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <360>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_vcn33_wifi_reg: ldo_vcn33_wifi{
+   regulator-name = "vcn33_wifi";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <360>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_va_reg: ldo_va{
+   regulator-name = "va";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <216>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vcama_reg: ldo_vcama

[PATCH v5 09/10] arm: dts: mt7623: add support for Bananapi R2 (BPI-R2) board

[sean.wang]

From: Sean Wang 

Add support for the Bananapi R2 (BPI-R2) development board from
BIPAI KEJI. Detailed hardware information for BPI-R2 which could be
found on http://www.banana-pi.org/r2.html

The patch added nodes into the SoC-level file mt7623.dtsi such as CPU OPP
table and thermal zone treating CPU as one of cooling devices and also
added nodes into board-level file mt7623n-bananapi-bpi-r2.dts such as
MediaTek GMAC, MT7530 Switch, the crypto engine, USB, IR, I2S, I2C, UART,
SPI, PWM, GPIO keys, GPIO LEDs and PMIC LEDs. As to the other missing
hardware and peripherals, they would be added and integrated continuously.

Signed-off-by: Sean Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/mediatek.txt |   2 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/mt7623.dtsi  | 120 +-
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts  | 443 +
 4 files changed, 561 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index ae011b2..1caa9d2 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -49,6 +49,8 @@ Supported boards:
 - Reference  board for MT7623n with NAND:
 Required root node properties:
   - compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";
+- Bananapi BPI-R2 board:
+  - compatible = "bananapi,bpi-r2", "mediatek,mt7623";
 - MTK mt8127 tablet moose EVB:
 Required root node properties:
   - compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f3a2442..736abbf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1050,6 +1050,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt6589-aquaris5.dtb \
mt6592-evb.dtb \
mt7623n-rfb-nand.dtb \
+   mt7623n-bananapi-bpi-r2.dtb \
mt8127-moose.dtb \
mt8135-evbp1.dtb
 dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 937a550..86cab5c 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -21,12 +21,58 @@
 #include 
 #include 
 #include 
+#include 
 #include "skeleton64.dtsi"
 
 / {
compatible = "mediatek,mt7623";
interrupt-parent = <&sysirq>;
 
+   cpu_opp_table: opp_table {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-9800 {
+   opp-hz = /bits/ 64 <9800>;
+   opp-microvolt = <105>;
+   };
+
+   opp-19800 {
+   opp-hz = /bits/ 64 <19800>;
+   opp-microvolt = <105>;
+   };
+
+   opp-39800 {
+   opp-hz = /bits/ 64 <39800>;
+   opp-microvolt = <105>;
+   };
+
+   opp-59800 {
+   opp-hz = /bits/ 64 <59800>;
+   opp-microvolt = <105>;
+   };
+
+   opp-74750 {
+   opp-hz = /bits/ 64 <74750>;
+   opp-microvolt = <105>;
+   };
+
+   opp-104000 {
+   opp-hz = /bits/ 64 <104000>;
+   opp-microvolt = <115>;
+   };
+
+   opp-119600 {
+   opp-hz = /bits/ 64 <119600>;
+   opp-microvolt = <120>;
+   };
+
+   opp-13 {
+   opp-hz = /bits/ 64 <13>;
+   opp-microvolt = <130>;
+   };
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -36,21 +82,31 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x0>;
+   clocks = <&infracfg CLK_INFRA_CPUSEL>,
+<&apmixedsys CLK_APMIXED_MAINPLL>;
+   clock-names = "cpu", "intermediate";
+   operating-points-v2 = <&cpu_opp_table>;
+   #cooling-cells = <2>;
+   cooling-min-level = <0>;
+   cooling-max-level = <7>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x1>;
+   operating-points-v2 = <&cpu_opp_table>;
};
cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a7";
   

[PATCH v5 07/10] arm: dts: mt7623: enable the usb device on the mt7623n rfb

[sean.wang]

From: John Crispin 

All versions of the mt7623n RFB have an USB port so enable the device.
There is a gpio that gets used to power up the port supply. Add support
for this gpio using the fixed-regulator driver.

Signed-off-by: John Crispin 
Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623n-rfb.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623n-rfb.dtsi 
b/arch/arm/boot/dts/mt7623n-rfb.dtsi
index 5e0dd79..1e95790 100644
--- a/arch/arm/boot/dts/mt7623n-rfb.dtsi
+++ b/arch/arm/boot/dts/mt7623n-rfb.dtsi
@@ -49,6 +49,15 @@
serial1 = &uart1;
serial2 = &uart2;
};
+
+   usb_p1_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&pio 135 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 };
 
 &uart0 {
@@ -72,3 +81,12 @@
vmmc-supply = <&mt6323_vmch_reg>;
vqmmc-supply = <&mt6323_vmc_reg>;
 };
+
+&usb1 {
+   vbus-supply = <&usb_p1_vbus>;
+   status = "okay";
+};
+
+&u3phy1 {
+   status = "okay";
+};
-- 
2.7.4

[PATCH v5 06/10] arm: dts: mt7623: cleanup the mt7623n rfb uart nodes

[sean.wang]

From: John Crispin 

This patch does a cleanup of the uart nodes in the dts file of the RFB. It
adds aliases, enables 2 more uarts and explicitly sets the uart mode of the
console.

Signed-off-by: John Crispin 
Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623n-rfb.dtsi | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/mt7623n-rfb.dtsi 
b/arch/arm/boot/dts/mt7623n-rfb.dtsi
index 805ba69..5e0dd79 100644
--- a/arch/arm/boot/dts/mt7623n-rfb.dtsi
+++ b/arch/arm/boot/dts/mt7623n-rfb.dtsi
@@ -19,7 +19,7 @@
 
 / {
chosen {
-   stdout-path = &uart2;
+   stdout-path = "serial2:115200n8";
};
 
cpus {
@@ -43,6 +43,20 @@
memory@8000 {
reg = <0 0x8000 0 0x4000>;
};
+
+   aliases {
+   serial0 = &uart0;
+   serial1 = &uart1;
+   serial2 = &uart2;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   status = "okay";
 };
 
 &uart2 {
-- 
2.7.4

[PATCH v5 10/10] arm: dts: mt7623: add clock-frequency to CPU nodes

[sean.wang]

From: Sean Wang 

Add clock-frequency property to CPU nodes. Avoids warnings like
[0.001568] /cpus/cpu@0 missing clock-frequency property
[0.001588] /cpus/cpu@1 missing clock-frequency property
[0.001601] /cpus/cpu@2 missing clock-frequency property
[0.001614] /cpus/cpu@3 missing clock-frequency property
at boot time

Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 86cab5c..4ae0ab0 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -89,24 +89,28 @@
#cooling-cells = <2>;
cooling-min-level = <0>;
cooling-max-level = <7>;
+   clock-frequency = <13>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x1>;
operating-points-v2 = <&cpu_opp_table>;
+   clock-frequency = <13>;
};
cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x2>;
operating-points-v2 = <&cpu_opp_table>;
+   clock-frequency = <13>;
};
cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x3>;
operating-points-v2 = <&cpu_opp_table>;
+   clock-frequency = <13>;
};
};
 
-- 
2.7.4

[PATCH v5 02/10] dt-bindings: arm: mediatek: add bindings for mediatek MT7623a SoC Platform

[sean.wang]

From: Sean Wang 

This adds DT binding documentation for Mediatek MT7623a

Signed-off-by: Sean Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/mediatek.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index cab2074..ae011b2 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -14,6 +14,7 @@ compatible: Must contain one of
"mediatek,mt6797"
"mediatek,mt7622"
"mediatek,mt7623" which is referred to MT7623N SoC
+   "mediatek,mt7623a"
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
-- 
2.7.4

Re: A udev rule to serve the change event of ACPI container?

[joeyli]

Hi Michal,

Sorry for my delay...

On Tue, Jul 25, 2017 at 02:48:37PM +0200, Michal Hocko wrote:
> On Mon 24-07-17 17:29:21, Joey Lee wrote:
> > On Mon, Jul 24, 2017 at 10:57:02AM +0200, Michal Hocko wrote:
> > > On Wed 19-07-17 17:09:10, Joey Lee wrote:
> > > > On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote:
> > > [...]
> > > > > The problem I have with this expectation is that userspace will never
> > > > > have a good atomic view of the whole container. So it can only try to
> > > > 
> > > > I agreed!
> > > > 
> > > > Even a userspace application can handle part of offline jobs. It's
> > > > still possible that other kernel/userland compenents are using the
> > > > resource in container.
> > > > 
> > > > > eject and then hope that nobody has onlined part of the container.
> > > > > If you emit offline event to the userspace the cleanup can be done and
> > > > > after the last component goes offline then the eject can be done
> > > > > atomically.
> > > > 
> > > > The thing that we didn't align is how does kernel maintains the flag
> > > > of ejection state on container.
> > > 
> > > Why it cannot be an attribute of the container? The flag would be set
> > > when the eject operation is requested and cleared when either the
> > > operation is successful (all parts offline and eject operation acked
> > > by the BIOS) or it is terminated.
> > >
> > 
> > For the success case, yes, we can clear the flag when the _EJ0 of container
> > is success. But for the fail case, we don't know when the operation is
> > terminated.
> 
> Hmm, this is rather strange. What is the BIOS state in the meantime?
> Let's say it doesn't retry. Does it wait for the OS for ever?
> 

Unfortunately ACPI spec doesn't mention the detail of BIOS behavior for
container hot-removing.

IMHO, if the BIOS doesn't retry, at least it should maintains a timer
to handle the OS layer time out then BIOS resets hardware(turns off
progress light or something else...).

The old BIOS just treats the ejection event as a button event. BIOS
emits 0x103 ejection event to OS after user presses a button or UI.
Then BIOS hopes that OS(either kernel or userland) finishs all jobs,
calls _EJ0 to turn off power, and calls _OST to return state to BIOS.

If the ejection event from BIOS doesn't trigger anything in upper OS
layer, old BIOS can not against this situation unless it has a timer.

> > > [...]
> > > > Base on the above figure, if userspace didn't do anything or it
> > > > just performs part of offline jobs. Then the container's [eject]
> > > > state will be always _SET_ there, and kernel will always check
> > > > the the latest child offline state when any child be offlined
> > > > by userspace.
> > > 
> > > What is a problem about that? The eject is simply in progress until all
> > > is set. Or maybe I just misunderstood.
> > >
> > 
> > I agree, but it's only for success case. For fail case, kernel can not
> > wait forever. Can we?
> 
> Well, this won't consume any additional resources so I wouldn't be all
> that worried. Maybe we can reset the flag as soon as somebody tries to
> online some part of the container?
>

So, the behavior is:

Kernel received ejection event, set _Eject_ flag on container object
  -> Kernel sends offline events to all children devices
-> User space performs cleaning jobs and offlines each child device
  -> Kernel detects all children offlined
-> Kernel removes objects and calls power off(_EJ0)

If anyone onlined one of the children devices in the term of waiting
userland offlines all children, then the _Eject_ flag will be clean
and ejection process will be interrupted. In this situation, administrator
needs to trigger ejection event again. Do you think that the race hurts
anything?

Thanks a lot!
Joey Lee

Re: [PATCH] mm: don't zero ballooned pages

[Wei Wang]

On 07/31/2017 02:55 PM, Michal Hocko wrote:

On Mon 31-07-17 12:13:33, Wei Wang wrote:

Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
shouldn't be given to the host ksmd to scan.

Could you point me where this MADV_DONTNEED is done, please?


Sure. It's done in the hypervisor when the balloon pages are received.

Please see line 40 at
https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c





Therefore, it is not
necessary to zero ballooned pages, which is very time consuming when
the page amount is large. The ongoing fast balloon tests show that the
time to balloon 7G pages is increased from ~491ms to 2.8 seconds with
__GFP_ZERO added. So, this patch removes the flag.

Please make it obvious that this is a revert of bb01b64cfab7
("mm/balloon_compaction.c: enqueue zero page to balloon device").




Ok, will do.

Best,
Wei

[PATCH v5 05/10] ARM: mediatek: add MT7623a smp bringup code

[sean.wang]

From: Sean Wang 

Add support for booting secondary CPUs on MT7623a.

Signed-off-by: Sean Wang 
---
 arch/arm/mach-mediatek/mediatek.c | 2 ++
 arch/arm/mach-mediatek/platsmp.c  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-mediatek/mediatek.c 
b/arch/arm/mach-mediatek/mediatek.c
index c3cf215..6910b4e 100644
--- a/arch/arm/mach-mediatek/mediatek.c
+++ b/arch/arm/mach-mediatek/mediatek.c
@@ -30,6 +30,7 @@ static void __init mediatek_timer_init(void)
 
if (of_machine_is_compatible("mediatek,mt6589") ||
of_machine_is_compatible("mediatek,mt7623") ||
+   of_machine_is_compatible("mediatek,mt7623a") ||
of_machine_is_compatible("mediatek,mt8135") ||
of_machine_is_compatible("mediatek,mt8127")) {
/* turn on GPT6 which ungates arch timer clocks */
@@ -49,6 +50,7 @@ static const char * const mediatek_board_dt_compat[] = {
"mediatek,mt6589",
"mediatek,mt6592",
"mediatek,mt7623",
+   "mediatek,mt7623a",
"mediatek,mt8127",
"mediatek,mt8135",
NULL,
diff --git a/arch/arm/mach-mediatek/platsmp.c b/arch/arm/mach-mediatek/platsmp.c
index 726eb69..27d78c9 100644
--- a/arch/arm/mach-mediatek/platsmp.c
+++ b/arch/arm/mach-mediatek/platsmp.c
@@ -59,6 +59,7 @@ static const struct of_device_id mtk_tz_smp_boot_infos[] 
__initconst = {
 static const struct of_device_id mtk_smp_boot_infos[] __initconst = {
{ .compatible   = "mediatek,mt6589", .data = &mtk_mt6589_boot },
{ .compatible   = "mediatek,mt7623", .data = &mtk_mt7623_boot },
+   { .compatible   = "mediatek,mt7623a", .data = &mtk_mt7623_boot },
 };
 
 static void __iomem *mtk_smp_base;
-- 
2.7.4

[PATCH v5 00/10] arm: dts: extend mt7623 support

[sean.wang]

From: Sean Wang 

Change since v4:
- split mt6323 nodes as the independent item which tends to integration with
  other MediaTek SoCs
- enhanced commit log
- fixed up building warning shown in make dtsb
- added clock-frequency to CPU nodes to avoid warning in boot time
- added more nodes into the SoC-level file mt7623.dtsi such as CPU OPP table
  and thermal zone treating CPU as one of cooling devices
- cleaned up the file mt7623n-bananapi-bpi-r2.dts such as listing nodes in
  alphabetical order

Changes since v3:
- explain in the commit message why this binding is changed
- patches for dt-binding is reordered at the beginning of patch list
- be concise wigh using SPDX-License-Identifier in new dts file

Changes since v2:
- exclude those patch are already queued into v4.11-next/dts32
- exclude those patches already sent in separation
- add mt7623a SoC basic support
- update binding SoC for mt7623n and relevant boards

Changes since v1:
Continue the upstream journey based on the previous John Crispin's good work.
- add fixes for the v1 suggestion
- fix typo in the commit log
- add missing pinctrl bindings for mt7623
- reuse pinctrl driver for mt7623
- enhance existing nodes since the way for binding is changed e.g USB
- add more nodes which already gets support from the latest tree e.g MT7530 DSA
- add the dts file for Bananapi R2 (BPI-R2) board

John Crispin (4):
  arm: dts: mt7623: add mt6323.dtsi file
  arm: dts: mt7623: cleanup the mt7623n rfb uart nodes
  arm: dts: mt7623: enable the usb device on the mt7623n rfb
  arm: dts: mt7623: enable the nand device on the mt7623n nand rfb

Sean Wang (6):
  dt-bindings: arm: mediatek: update for MT7623n SoC and relevant boards
  dt-bindings: arm: mediatek: add bindings for mediatek MT7623a SoC
Platform
  arm: dts: mt7623: rename mt7623-evb.dts to
arch/arm/boot/dts/mt7623n-rfb.dtsi
  ARM: mediatek: add MT7623a smp bringup code
  arm: dts: mt7623: add support for Bananapi R2 (BPI-R2) board
  arm: dts: mt7623: add clock-frequency to CPU nodes

 Documentation/devicetree/bindings/arm/mediatek.txt |  14 +-
 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/mt6323.dtsi  | 241 +++
 arch/arm/boot/dts/mt7623-evb.dts   |  33 --
 arch/arm/boot/dts/mt7623.dtsi  | 132 +-
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts  | 443 +
 arch/arm/boot/dts/mt7623n-rfb-nand.dts | 109 +
 arch/arm/boot/dts/mt7623n-rfb.dtsi |  92 +
 arch/arm/mach-mediatek/mediatek.c  |   2 +
 arch/arm/mach-mediatek/platsmp.c   |   1 +
 10 files changed, 1021 insertions(+), 49 deletions(-)
 create mode 100644 arch/arm/boot/dts/mt6323.dtsi
 delete mode 100644 arch/arm/boot/dts/mt7623-evb.dts
 create mode 100644 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
 create mode 100644 arch/arm/boot/dts/mt7623n-rfb-nand.dts
 create mode 100644 arch/arm/boot/dts/mt7623n-rfb.dtsi

-- 
2.7.4

Re: [PATCH] mm: don't zero ballooned pages

[ZhenweiPi]

on qemu upstream, code in qemu/util/osdep.c

int qemu_madvise(void *addr, size_t len, int advice)

{

if (advice == QEMU_MADV_INVALID) {

errno = EINVAL;

return -1;

}

#if defined(CONFIG_MADVISE)

return madvise(addr, len, advice);

#elif defined(CONFIG_POSIX_MADVISE)

return posix_madvise(addr, len, advice);

#else

errno = EINVAL;

return -1;

#endif

}

Host OS maybe not support MADV_DONTNEED.
And madvise syscall uses more time.


On 07/31/2017 02:55 PM, Michal Hocko wrote:

On Mon 31-07-17 12:13:33, Wei Wang wrote:

Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
shouldn't be given to the host ksmd to scan.

Could you point me where this MADV_DONTNEED is done, please?


Therefore, it is not
necessary to zero ballooned pages, which is very time consuming when
the page amount is large. The ongoing fast balloon tests show that the
time to balloon 7G pages is increased from ~491ms to 2.8 seconds with
__GFP_ZERO added. So, this patch removes the flag.

Please make it obvious that this is a revert of bb01b64cfab7
("mm/balloon_compaction.c: enqueue zero page to balloon device").


Signed-off-by: Wei Wang 
---
  mm/balloon_compaction.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index 9075aa5..b06d9fe 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -24,7 +24,7 @@ struct page *balloon_page_enqueue(struct balloon_dev_info 
*b_dev_info)
  {
unsigned long flags;
struct page *page = alloc_page(balloon_mapping_gfp_mask() |
-   __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO);
+  __GFP_NOMEMALLOC | __GFP_NORETRY);
if (!page)
return NULL;
  
--

2.7.4

[PATCH v5 01/10] dt-bindings: arm: mediatek: update for MT7623n SoC and relevant boards

[sean.wang]

From: Sean Wang 

Because there are two versions of MT7623 SoC that is MT7623a and MT7623n
respectively. So update the part of MT7623n bindings to allow that people
tend to differentiate which MT7623 SoC the boards applies.

And "mediatek,mt7623-evb" can be safely changed to
"mediatek,mt7623n-rfb-nand" because mt7623-evb is a kind of debug board
internally in Mediatek which real users can't get. So instead we should
indicate which variants it belongs to with more specific postfix as the
adding here to let people easily know what board they use.

Signed-off-by: John Crispin 
Signed-off-by: Sean Wang 
---
 Documentation/devicetree/bindings/arm/mediatek.txt | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index da7bd13..cab2074 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -1,7 +1,6 @@
-MediaTek mt65xx, mt67xx & mt81xx Platforms Device Tree Bindings
+MediaTek SoC based Platforms Device Tree Bindings
 
-Boards with a MediaTek mt65xx/mt67xx/mt81xx SoC shall have the
-following property:
+Boards with a MediaTek SoC shall have the following property:
 
 Required root node property:
 
@@ -14,7 +13,7 @@ compatible: Must contain one of
"mediatek,mt6795"
"mediatek,mt6797"
"mediatek,mt7622"
-   "mediatek,mt7623"
+   "mediatek,mt7623" which is referred to MT7623N SoC
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
@@ -46,9 +45,9 @@ Supported boards:
 - Reference board variant 1 for MT7622:
 Required root node properties:
   - compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622";
-- Evaluation board for MT7623:
+- Reference  board for MT7623n with NAND:
 Required root node properties:
-  - compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
+  - compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";
 - MTK mt8127 tablet moose EVB:
 Required root node properties:
   - compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
-- 
2.7.4

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

[Minchan Kim]

On Mon, Jul 31, 2017 at 09:17:07AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 07:16:59AM +0900, Minchan Kim wrote:
> > rw_page's gain is reducing of dynamic allocation in swap path
> > as well as performance gain thorugh avoiding bio allocation.
> > And it would be important in memory pressure situation.
> 
> There is no need for any dynamic allocation when using the bio
> path.  Take a look at __blkdev_direct_IO_simple for an example
> that doesn't do any allocations.

Do you suggest define something special flag(e.g., SWP_INMEMORY)
for in-memory swap to swap_info_struct when swapon time manually
or from bdi_queue_someting automatically?
And depending the flag of swap_info_struct, use the onstack bio
instead of dynamic allocation if the swap device is in-memory?

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

[Christoph Hellwig]

On Mon, Jul 31, 2017 at 04:36:47PM +0900, Minchan Kim wrote:
> Do you suggest define something special flag(e.g., SWP_INMEMORY)
> for in-memory swap to swap_info_struct when swapon time manually
> or from bdi_queue_someting automatically?
> And depending the flag of swap_info_struct, use the onstack bio
> instead of dynamic allocation if the swap device is in-memory?

Currently swap always just does I/O on a single page as far
as I can tell, so it can always just use an on-stack bio and
biovec.

Re: [RFC] drm/fb: Propagate physical display dimensions to fbdev

[Daniel Vetter]

> Sun, Jul 30, 2017 at 11:11 PM, David Lechner  wrote:
> fbdev has a place for the physical width and height of a display. I would
> like to have this information available to userspace. This patch works for me,
> but I have a strong suspicion that this is not the "right way".
>
> Any suggestions on how to get the proper struct drm_display_info here
> rather than assuming the first connector one is valid? I don't see an obvious
> way to do this.

This data can also change at runtime, which means we need to reprobe
it. And as you mention, we need to pick the data of the first
connected connector, not the very first connector the driver has. The
final connector loo in drm_setup_crtcs() would be a good place to do
that I think.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 574af01..ff422da 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1768,8 +1768,14 @@ void drm_fb_helper_fill_var(struct fb_info *info, 
> struct drm_fb_helper *fb_helpe
> info->var.xoffset = 0;
> info->var.yoffset = 0;
> info->var.activate = FB_ACTIVATE_NOW;
> -   info->var.height = -1;
> -   info->var.width = -1;
> +
> +   if (fb_helper->connector_count) {
> +   info->var.height = 
> fb_helper->connector_info[0]->connector->display_info.width_mm;
> +   info->var.width = 
> fb_helper->connector_info[0]->connector->display_info.height_mm;
> +   } else {
> +   info->var.height = -1;
> +   info->var.width = -1;
> +   }
>
> switch (fb->format->depth) {
> case 8:
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 1/5] tracing, mm: Record pfn instead of pointer to struct page

[Vlastimil Babka]

On 04/14/2015 12:14 AM, Arnaldo Carvalho de Melo wrote:
> From: Namhyung Kim 
> 
> The struct page is opaque for userspace tools, so it'd be better to save
> pfn in order to identify page frames.
> 
> The textual output of $debugfs/tracing/trace file remains unchanged and
> only raw (binary) data format is changed - but thanks to libtraceevent,
> userspace tools which deal with the raw data (like perf and trace-cmd)
> can parse the format easily.

Hmm it seems trace-cmd doesn't work that well, at least on current
x86_64 kernel where I noticed it:

 trace-cmd-22020 [003] 105219.542610: mm_page_alloc:[FAILED TO PARSE] 
pfn=0x165cb4 order=0 gfp_flags=29491274 migratetype=1

I'm quite sure it's due to the "page=%p" part, which uses pfn_to_page().
The events/kmem/mm_page_alloc/format file contains this for page:

REC->pfn != -1UL ? (((struct page *)vmemmap_base) + (REC->pfn)) : ((void *)0)

I think userspace can't know vmmemap_base nor the implied sizeof(struct
page) for pointer arithmetic?

On older 4.4-based kernel:

REC->pfn != -1UL ? (((struct page *)(0xea00UL)) + (REC->pfn)) : 
((void *)0)

This also fails to parse, so it must be the struct page part?

I think the problem is, even if ve solve this with some more
preprocessor trickery to make the format file contain only constant
numbers, pfn_to_page() on e.g. sparse memory model without vmmemap is
more complicated than simple arithmetic, and can't be exported in the
format file.

I'm afraid that to support userspace parsing of the trace data, we will
have to store both struct page and pfn... or perhaps give up on reporting
the struct page pointer completely. Thoughts?

> So impact on the userspace will also be
> minimal.
> 
> Signed-off-by: Namhyung Kim 
> Based-on-patch-by: Joonsoo Kim 
> Acked-by: Ingo Molnar 
> Acked-by: Steven Rostedt 
> Cc: David Ahern 
> Cc: Jiri Olsa 
> Cc: Minchan Kim 
> Cc: Peter Zijlstra 
> Cc: linux...@kvack.org
> Link: 
> http://lkml.kernel.org/r/1428298576-9785-3-git-send-email-namhy...@kernel.org
> Signed-off-by: Arnaldo Carvalho de Melo 
> ---
>  include/trace/events/filemap.h |  8 
>  include/trace/events/kmem.h| 42 
> +-
>  include/trace/events/vmscan.h  |  8 
>  3 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/include/trace/events/filemap.h b/include/trace/events/filemap.h
> index 0421f49a20f7..42febb6bc1d5 100644
> --- a/include/trace/events/filemap.h
> +++ b/include/trace/events/filemap.h
> @@ -18,14 +18,14 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
>   TP_ARGS(page),
>  
>   TP_STRUCT__entry(
> - __field(struct page *, page)
> + __field(unsigned long, pfn)
>   __field(unsigned long, i_ino)
>   __field(unsigned long, index)
>   __field(dev_t, s_dev)
>   ),
>  
>   TP_fast_assign(
> - __entry->page = page;
> + __entry->pfn = page_to_pfn(page);
>   __entry->i_ino = page->mapping->host->i_ino;
>   __entry->index = page->index;
>   if (page->mapping->host->i_sb)
> @@ -37,8 +37,8 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
>   TP_printk("dev %d:%d ino %lx page=%p pfn=%lu ofs=%lu",
>   MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
>   __entry->i_ino,
> - __entry->page,
> - page_to_pfn(__entry->page),
> + pfn_to_page(__entry->pfn),
> + __entry->pfn,
>   __entry->index << PAGE_SHIFT)
>  );
>  
> diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> index 4ad10baecd4d..81ea59812117 100644
> --- a/include/trace/events/kmem.h
> +++ b/include/trace/events/kmem.h
> @@ -154,18 +154,18 @@ TRACE_EVENT(mm_page_free,
>   TP_ARGS(page, order),
>  
>   TP_STRUCT__entry(
> - __field(struct page *,  page)
> + __field(unsigned long,  pfn )
>   __field(unsigned int,   order   )
>   ),
>  
>   TP_fast_assign(
> - __entry->page   = page;
> + __entry->pfn= page_to_pfn(page);
>   __entry->order  = order;
>   ),
>  
>   TP_printk("page=%p pfn=%lu order=%d",
> - __entry->page,
> - page_to_pfn(__entry->page),
> + pfn_to_page(__entry->pfn),
> + __entry->pfn,
>   __entry->order)
>  );
>  
> @@ -176,18 +176,18 @@ TRACE_EVENT(mm_page_free_batched,
>   TP_ARGS(page, cold),
>  
>   TP_STRUCT__entry(
> - __field(struct page *,  page)
> + __field(unsigned long,  pfn )
>   __field(int,cold)
>   ),
>  
>   TP_fast_assign(
> - __entry->page   = page;
> + __entry->pfn= page_t

Re: [RFC PATCH 0/4] serial: uartps: Dynamic allocation

[Michal Simek]

On 28.7.2017 20:39, Alan Cox wrote:
> On Fri, 21 Jul 2017 11:32:23 +0200
> Michal Simek  wrote:
> 
>> Hi Alan,
>>
>> this is the initial version before next step which is move
>> uart_register_driver to probe function.
>> I was able to get rid of static array with uart_port structures.
>> It was wired with console which is also fixed.
>> And the next step is the most complicated one handle .nr in uart_driver
>> structure in more generic way.
>>
>> Thanks,
>> Michal
> 
> Sorry for the delay been on jury service

np at all.
Do you have any suggestion how to do the last step?


> 
> Series
> 
> Reviewed-by: Alan Cox 
> 

Thanks,
Michal

Re: [PATCH] mm: don't zero ballooned pages

[Michal Hocko]

On Mon 31-07-17 15:41:49, Wei Wang wrote:
> On 07/31/2017 02:55 PM, Michal Hocko wrote:
> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> >>shouldn't be given to the host ksmd to scan.
> >Could you point me where this MADV_DONTNEED is done, please?
> 
> Sure. It's done in the hypervisor when the balloon pages are received.
> 
> Please see line 40 at
> https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c

Thanks. Are all hypervisors which are using this API doing this?
bb01b64cfab7 doesn't mention the specify hypervisor nor does it mention
any real numbers so I suspect the revert is the right thing to do but
the changelog should mention all those details.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

[Christoph Hellwig]

On Mon, Jul 31, 2017 at 09:42:06AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 04:36:47PM +0900, Minchan Kim wrote:
> > Do you suggest define something special flag(e.g., SWP_INMEMORY)
> > for in-memory swap to swap_info_struct when swapon time manually
> > or from bdi_queue_someting automatically?
> > And depending the flag of swap_info_struct, use the onstack bio
> > instead of dynamic allocation if the swap device is in-memory?
> 
> Currently swap always just does I/O on a single page as far
> as I can tell, so it can always just use an on-stack bio and
> biovec.

That's for synchronous I/O, aka reads of course.  For writes you'll
need to do a dynamic allocation if they are asynchronous.  But yes,
if we want to force certain devices to be synchronous we'll need
a flag for that.

[RESEND][PATCH V10 0/3] powernv : Add support for OPAL-OCC command/response interface

[Shilpasri G Bhat]

In P9, OCC (On-Chip-Controller) supports shared memory based
commad-response interface. Within the shared memory there is an OPAL
command buffer and OCC response buffer that can be used to send
inband commands to OCC. The following commands are supported:

1) Set system powercap
2) Set CPU-GPU power shifting ratio
3) Clear min/max for OCC sensor groups

Changes from V9:
- Fixed return after erroring from mutex_lock_interruptible()
- Added documentation
- [RESEND] Fixed the version number of the patch-set in Subject

Shilpasri G Bhat (3):
  powernv: powercap: Add support for powercap framework
  powernv: Add support to set power-shifting-ratio
  powernv: Add support to clear sensor groups data

 .../ABI/testing/sysfs-firmware-opal-powercap   |  31 +++
 Documentation/ABI/testing/sysfs-firmware-opal-psr  |  18 ++
 .../bindings/powerpc/opal/sensor-groups.txt|  23 ++
 arch/powerpc/include/asm/opal-api.h|   8 +-
 arch/powerpc/include/asm/opal.h|   9 +
 arch/powerpc/include/uapi/asm/opal-occ.h   |  23 ++
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-occ.c  | 116 ++
 arch/powerpc/platforms/powernv/opal-powercap.c | 244 +
 arch/powerpc/platforms/powernv/opal-psr.c  | 175 +++
 arch/powerpc/platforms/powernv/opal-wrappers.S |   5 +
 arch/powerpc/platforms/powernv/opal.c  |  10 +
 12 files changed, 662 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-powercap
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-psr
 create mode 100644 
Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt
 create mode 100644 arch/powerpc/include/uapi/asm/opal-occ.h
 create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c
 create mode 100644 arch/powerpc/platforms/powernv/opal-powercap.c
 create mode 100644 arch/powerpc/platforms/powernv/opal-psr.c

-- 
1.8.3.1

[RESEND][PATCH V10 1/3] powernv: powercap: Add support for powercap framework

[Shilpasri G Bhat]

Adds a generic powercap framework to change the system powercap
inband through OPAL-OCC command/response interface.

Signed-off-by: Shilpasri G Bhat 
---
 .../ABI/testing/sysfs-firmware-opal-powercap   |  31 +++
 arch/powerpc/include/asm/opal-api.h|   5 +-
 arch/powerpc/include/asm/opal.h|   4 +
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-powercap.c | 244 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   2 +
 arch/powerpc/platforms/powernv/opal.c  |   4 +
 7 files changed, 290 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-powercap
 create mode 100644 arch/powerpc/platforms/powernv/opal-powercap.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-powercap 
b/Documentation/ABI/testing/sysfs-firmware-opal-powercap
new file mode 100644
index 000..c9b66ec
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-powercap
@@ -0,0 +1,31 @@
+What:  /sys/firmware/opal/powercap
+Date:  August 2017
+Contact:   Linux for PowerPC mailing list 
+Description:   Powercap directory for Powernv (P8, P9) servers
+
+   Each folder in this directory contains a
+   power-cappable component.
+
+What:  /sys/firmware/opal/powercap/system-powercap
+   /sys/firmware/opal/powercap/system-powercap/powercap-min
+   /sys/firmware/opal/powercap/system-powercap/powercap-max
+   /sys/firmware/opal/powercap/system-powercap/powercap-current
+Date:  August 2017
+Contact:   Linux for PowerPC mailing list 
+Description:   System powercap directory and attributes applicable for
+   Powernv (P8, P9) servers
+
+   This directory provides powercap information. It
+   contains below sysfs attributes:
+
+   - powercap-min : This file provides the minimum
+ possible powercap in Watt units
+
+   - powercap-max : This file provides the maximum
+ possible powercap in Watt units
+
+   - powercap-current : This file provides the current
+ powercap set on the system. Writing to this file
+ creates a request for setting a new-powercap. The
+ powercap requested must be between powercap-min
+ and powercap-max.
diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 3130a73..c3e0c4a 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -42,6 +42,7 @@
 #define OPAL_I2C_STOP_ERR  -24
 #define OPAL_XIVE_PROVISIONING -31
 #define OPAL_XIVE_FREE_ACTIVE  -32
+#define OPAL_TIMEOUT   -33
 
 /* API Tokens (in r0) */
 #define OPAL_INVALID_CALL -1
@@ -190,7 +191,9 @@
 #define OPAL_NPU_INIT_CONTEXT  146
 #define OPAL_NPU_DESTROY_CONTEXT   147
 #define OPAL_NPU_MAP_LPAR  148
-#define OPAL_LAST  148
+#define OPAL_GET_POWERCAP  152
+#define OPAL_SET_POWERCAP  153
+#define OPAL_LAST  153
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 588fb1c..ec2087c 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -267,6 +267,8 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int64_t opal_xive_free_irq(uint32_t girq);
 int64_t opal_xive_sync(uint32_t type, uint32_t id);
 int64_t opal_xive_dump(uint32_t type, uint32_t id);
+int opal_get_powercap(u32 handle, int token, u32 *pcap);
+int opal_set_powercap(u32 handle, int token, u32 pcap);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -345,6 +347,8 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 
 void opal_wake_poller(void);
 
+void opal_powercap_init(void);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index b5d98cb..e79f806 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o
+obj-y  += opal-kmsg.o opal-powercap.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-powercap.c 
b/arch/powerpc/platforms/po

[RESEND][PATCH V10 2/3] powernv: Add support to set power-shifting-ratio

[Shilpasri G Bhat]

This patch adds support to set power-shifting-ratio which hints the
firmware how to distribute/throttle power between different entities
in a system (e.g CPU v/s GPU). This ratio is used by OCC for power
capping algorithm.

Signed-off-by: Shilpasri G Bhat 
---
 Documentation/ABI/testing/sysfs-firmware-opal-psr |  18 +++
 arch/powerpc/include/asm/opal-api.h   |   4 +-
 arch/powerpc/include/asm/opal.h   |   3 +
 arch/powerpc/platforms/powernv/Makefile   |   2 +-
 arch/powerpc/platforms/powernv/opal-psr.c | 175 ++
 arch/powerpc/platforms/powernv/opal-wrappers.S|   2 +
 arch/powerpc/platforms/powernv/opal.c |   3 +
 7 files changed, 205 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-psr
 create mode 100644 arch/powerpc/platforms/powernv/opal-psr.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-psr 
b/Documentation/ABI/testing/sysfs-firmware-opal-psr
new file mode 100644
index 000..cc2ece7
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-psr
@@ -0,0 +1,18 @@
+What:  /sys/firmware/opal/psr
+Date:  August 2017
+Contact:   Linux for PowerPC mailing list 
+Description:   Power-Shift-Ratio directory for Powernv P9 servers
+
+   Power-Shift-Ratio allows to provide hints the firmware
+   to shift/throttle power between different entities in
+   the system. Each attribute in this directory indicates
+   a settable PSR.
+
+What:  /sys/firmware/opal/psr/cpu_to_gpu_X
+Date:  August 2017
+Contact:   Linux for PowerPC mailing list 
+Description:   PSR sysfs attributes for Powernv P9 servers
+
+   Power-Shift-Ratio between CPU and GPU for a given chip
+   with chip-id X. This file gives the ratio (0-100)
+   which is used by OCC for power-capping.
diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index c3e0c4a..92e31fd 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -193,7 +193,9 @@
 #define OPAL_NPU_MAP_LPAR  148
 #define OPAL_GET_POWERCAP  152
 #define OPAL_SET_POWERCAP  153
-#define OPAL_LAST  153
+#define OPAL_GET_POWER_SHIFT_RATIO 154
+#define OPAL_SET_POWER_SHIFT_RATIO 155
+#define OPAL_LAST  155
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ec2087c..b9ea77f 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -269,6 +269,8 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int64_t opal_xive_dump(uint32_t type, uint32_t id);
 int opal_get_powercap(u32 handle, int token, u32 *pcap);
 int opal_set_powercap(u32 handle, int token, u32 pcap);
+int opal_get_power_shift_ratio(u32 handle, int token, u32 *psr);
+int opal_set_power_shift_ratio(u32 handle, int token, u32 psr);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -348,6 +350,7 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 void opal_wake_poller(void);
 
 void opal_powercap_init(void);
+void opal_psr_init(void);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index e79f806..9ed7d33 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o opal-powercap.o
+obj-y  += opal-kmsg.o opal-powercap.o opal-psr.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-psr.c 
b/arch/powerpc/platforms/powernv/opal-psr.c
new file mode 100644
index 000..7313b7f
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-psr.c
@@ -0,0 +1,175 @@
+/*
+ * PowerNV OPAL Power-Shift-Ratio interface
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) "opal-psr: " fmt
+
+#include 
+#include 
+#include 
+
+#include 
+
+DEFINE_MUTEX(psr_mutex);
+
+static struct kobject *psr_kobj;
+
+struct psr_attr {
+   u32 handle;
+   struct kobj_attribute att

[RESEND][PATCH V10 3/3] powernv: Add support to clear sensor groups data

[Shilpasri G Bhat]

Adds support for clearing different sensor groups. OCC inband sensor
groups like CSM, Profiler, Job Scheduler can be cleared using this
driver. The min/max of all sensors belonging to these sensor groups
will be cleared.

Signed-off-by: Shilpasri G Bhat 
---
 .../bindings/powerpc/opal/sensor-groups.txt|  23 
 arch/powerpc/include/asm/opal-api.h|   3 +-
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/include/uapi/asm/opal-occ.h   |  23 
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-occ.c  | 116 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   3 +
 8 files changed, 171 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt
 create mode 100644 arch/powerpc/include/uapi/asm/opal-occ.h
 create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c

diff --git a/Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt 
b/Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt
new file mode 100644
index 000..304b87c
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/opal/sensor-groups.txt
@@ -0,0 +1,23 @@
+IBM OPAL Sensor Groups Binding
+---
+
+Node: /ibm,opal/sensor-groups
+
+Description: Contains sensor groups available in the Powernv P9
+servers. Each child node indicates a sensor group.
+
+- compatible : Should be "ibm,opal-occ-sensor-group"
+
+Each child node contains below properties:
+
+- type : String to indicate the type of sensor-group
+
+- sensor-group-id: Abstract unique identifier provided by firmware of
+  type  which is used for sensor-group
+  operations like clearing the min/max history of all
+  sensors belonging to the group.
+
+- ibm,chip-id : Chip ID
+
+- sensors : Phandle array of child nodes of /ibm,opal/sensor/
+   belonging to this group
diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 92e31fd..0841659 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -195,7 +195,8 @@
 #define OPAL_SET_POWERCAP  153
 #define OPAL_GET_POWER_SHIFT_RATIO 154
 #define OPAL_SET_POWER_SHIFT_RATIO 155
-#define OPAL_LAST  155
+#define OPAL_SENSOR_GROUPS_CLEAR   156
+#define OPAL_LAST  156
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index b9ea77f..a716def 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -271,6 +271,7 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int opal_set_powercap(u32 handle, int token, u32 pcap);
 int opal_get_power_shift_ratio(u32 handle, int token, u32 *psr);
 int opal_set_power_shift_ratio(u32 handle, int token, u32 psr);
+int opal_sensor_groups_clear(u32 group_hndl, int token);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -351,6 +352,7 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 
 void opal_powercap_init(void);
 void opal_psr_init(void);
+int opal_sensor_groups_clear_history(u32 handle);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/powerpc/include/uapi/asm/opal-occ.h 
b/arch/powerpc/include/uapi/asm/opal-occ.h
new file mode 100644
index 000..97c45e2
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/opal-occ.h
@@ -0,0 +1,23 @@
+/*
+ * OPAL OCC command interface
+ * Supported on POWERNV platform
+ *
+ * (C) Copyright IBM 2017
+ *
+ * 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, 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.
+ */
+
+#ifndef _UAPI_ASM_POWERPC_OPAL_OCC_H_
+#define _UAPI_ASM_POWERPC_OPAL_OCC_H_
+
+#define OPAL_OCC_IOCTL_CLEAR_SENSOR_GROUPS _IOR('o', 1, u32)
+
+#endif /* _UAPI_ASM_POWERPC_OPAL_OCC_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index 9ed7d33..f193b33 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Thomas Gleixner]

On Mon, 31 Jul 2017, Tomi Sarvela wrote:
> On 28/07/17 19:26, Thomas Gleixner wrote:
> > Did you change anything else compared to the tests before ?
> 
> I did check that the problem persisted in linus-HEAD before testing your
> patch. The testing was done in order (reading from console logs I happen to
> still have in one window):

What I still do not understand is why this would affect the suspend path in
any way.

Can you remove the previous patch and apply the one below. If it resumes,
please provide the data from the trace buffer again.

Thanks,

tglx

8<--
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -459,3 +459,11 @@ static inline void irq_remove_debugfs_en
 {
 }
 #endif /* CONFIG_GENERIC_IRQ_DEBUGFS */
+
+extern bool irq_suspend_resume;
+
+static inline void irq_trace_state(const char *what, struct irq_desc *desc)
+{
+   trace_printk("%s %d state %08x\n", what, irq_desc_get_irq(desc),
+irqd_get(&desc->irq_data));
+}
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -14,6 +14,8 @@
 
 #include "internals.h"
 
+bool irq_suspend_resume;
+
 bool irq_pm_check_wakeup(struct irq_desc *desc)
 {
if (irqd_is_wakeup_armed(&desc->irq_data)) {
@@ -120,6 +122,7 @@ void suspend_device_irqs(void)
struct irq_desc *desc;
int irq;
 
+   irq_suspend_resume = true;
for_each_irq_desc(irq, desc) {
unsigned long flags;
bool sync;
@@ -127,7 +130,9 @@ void suspend_device_irqs(void)
if (irq_settings_is_nested_thread(desc))
continue;
raw_spin_lock_irqsave(&desc->lock, flags);
+   irq_trace_state("presuspend", desc);
sync = suspend_device_irq(desc);
+   irq_trace_state("postsuspend", desc);
raw_spin_unlock_irqrestore(&desc->lock, flags);
 
if (sync)
@@ -150,8 +155,9 @@ static void resume_irq(struct irq_desc *
/* Pretend that it got disabled ! */
desc->depth++;
irq_state_set_disabled(desc);
-   irq_state_set_masked(desc);
+
 resume:
+   irq_state_set_masked(desc);
desc->istate &= ~IRQS_SUSPENDED;
__enable_irq(desc);
 }
@@ -172,9 +178,14 @@ static void resume_irqs(bool want_early)
continue;
 
raw_spin_lock_irqsave(&desc->lock, flags);
+   irq_trace_state("preresume", desc);
resume_irq(desc);
+   irq_trace_state("postresume", desc);
raw_spin_unlock_irqrestore(&desc->lock, flags);
}
+
+   if (!want_early)
+   irq_suspend_resume = false;
 }
 
 /**

IRQ_ONESHOT expectations vs mask/unmask

[Benjamin Herrenschmidt]

Hi Thomas !

I noticed a problem with some powerpc systems with threaded IRQs. I
hadn't looked at threaded irq in the past so there was a bit of
discovery involved. That lead to a few questions:

 - Threaded IRQs rely on IRQF_ONESHOT. Now, is that a flag/feature that
is generally exposed to drivers even in the non-threaded case, and if
yes, what core callback are drivers expected to use to "unmask" the
oneshot interrupt ?

 - I don't see any provisions for dealing with interrupts lost while
masked. So on some PICs on powerpc, while we do use "fast EOI", we also
have a chance of edge interrupts (MSIs) being lost while masked. This
wasn't a problem until now because we used lazy disabling. However, it
looks like IRQF_ONESHOT (and thus threaded irqs) rely on masked
interrupts being latched in HW, otherwise an interrupt might be lost
between the threaded handler completing and the interrupt being
unmasked, or am I missing something ?

 - I noticed that other flow handlers (edge, edge_eoi, ...) don't have
any provision for IRQF_ONESHOT. Isn't that a problem ? Or will the core
silently swallow subsequent interrupts until the thread has completed
anyway ? (I might be missing something here).

Generally, how do you suggest I fix the threaded irq problem for XICS ?

(For the newer P9 XIVE interrupt controller I can probably fix things
by using a different masking mechanism in HW but for the old XICS,
especially with the hypervisor under the hood, I'm less confident).

I'd rather not write my own flow handler, that's a recipe for missing
fixes going into the generic ones and horrible bitrot...

Cheers,
Ben.

Re: [PATCH v2 net-next 0/4] net: dsa: lan9303: Fix MDIO issues.

[Juergen Borleis]

Hi Egil,

On Sunday 30 July 2017 19:58:52 Egil Hjelmeland wrote:
> This series fix the MDIO interface for the lan9303 DSA driver.
> Bugs found after testing on actual HW.
>
> This series is extracted from the first patch of my first large
> series. Significant changes from that version are:
>  - use mdiobus_write_nested, mdiobus_read_nested.
>  - EXPORT lan9303_indirect_phy_ops
>
> Unfortunately I do not have access to i2c based system for
> testing.

A little bit late - the series is already applied...
I have just tested it on my LAN9303 connected via I2C and my setup still 
works.

Tested-by: Juergen Borleis 

Cheers
Juergen

-- 
Pengutronix e.K.                             | Juergen Borleis             |
Industrial Linux Solutions                   | http://www.pengutronix.de/  |

Re: [PATCH] mm: don't zero ballooned pages

[Michal Hocko]

On Mon 31-07-17 15:41:49, Wei Wang wrote:
> On 07/31/2017 02:55 PM, Michal Hocko wrote:
> >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> >>shouldn't be given to the host ksmd to scan.
> >Could you point me where this MADV_DONTNEED is done, please?
> 
> Sure. It's done in the hypervisor when the balloon pages are received.
> 
> Please see line 40 at
> https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c

And one more thing. I am not familiar with ksm much. But how is
MADV_DONTNEED even helping? This madvise is not sticky - aka it will
unmap the range without leaving any note behind. AFAICS the only way
to have vma scanned is to have VM_MERGEABLE and that is an opt in:
See Documentation/vm/ksm.txt
"
KSM only operates on those areas of address space which an application
has advised to be likely candidates for merging, by using the madvise(2)
system call: int madvise(addr, length, MADV_MERGEABLE).
"

So what exactly is going on here? The original patch looks highly
suspicious as well. If somebody wants to make that memory mergable then
the user of that memory should zero them out.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 00/29] constify scsi pci_device_id.

[Johannes Thumshirn]

On Sun, Jul 30, 2017 at 02:07:09PM +0530, Arvind Yadav wrote:
> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by  work with
> const pci_device_id. So mark the non-const structs as const.

Can't this go all in one patch instead of replicating the same patch 29
times?

Thanks,
Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Tomi Sarvela]

On 31/07/17 10:45, Thomas Gleixner wrote:

On Mon, 31 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 19:26, Thomas Gleixner wrote:

Did you change anything else compared to the tests before ?


I did check that the problem persisted in linus-HEAD before testing your
patch. The testing was done in order (reading from console logs I happen to
still have in one window):


What I still do not understand is why this would affect the suspend path in
any way.

Can you remove the previous patch and apply the one below. If it resumes,
please provide the data from the trace buffer again.


No such luck. ELK hangs in the suspend-test with earlier patch removed, 
this added. Checked again that the power-led is on, no serial output.


Tree not pulled: still testing against the previous head -rc2, not 
current 4.13.0-rc3


Best regards,

Tomi
--
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

Re: [PATCH] futex: split PI support to a file of its own

[Thomas Gleixner]

On Sat, 29 Jul 2017, Nicolas Pitre wrote:

> Split out the priority inheritance support to a file of its own
> to make futex.c much smaller, easier to understand and, hopefully,
> to maintain. This also makes it easy to preserve basic futex support
> and compile out the PI support when RT mutexes are not available.

I can see your motivation to compile out PI support, which is why you
worked on this in the first place.

But I really do not agree with your reasoning about easier to understand
and maintain. I have the dubious pleasure to stare into that code on a
regular base. PI and non PI share a lot of code and it's really not helping
to have two separate files to stare at. That makes following the PI code
even harder than it is already. So I rather like to see that PI code in an
#ifdef block and not split out into its own file.

> Signed-off-by: Nicolas Pitre 

Please provide a diffstat along with the patch next time.

> diff --git a/include/linux/futex.h b/include/linux/futex.h

> +#ifdef CONFIG_FUTEX_PI
> +#include "futex_pi.c"
> +#else
> +#define get_pi_state(...)
> +#define put_pi_state(...)
> +#define refill_pi_state_cache()  false
> +#define lookup_pi_state(...) -ENOSYS
> +#define rt_mutex_start_proxy_lock(...)   -ENOSYS
> +#define requeue_pi_wake_futex(...)
> +#define futex_proxy_trylock_atomic(...)  -ENOSYS
> +#define futex_lock_pi(...)   -ENOSYS
> +#define futex_unlock_pi(...) -ENOSYS
> +#define futex_wait_requeue_pi(...)   -ENOSYS
> +#endif

Bah, no. We use static inlines as stubs whereever it's possible. Using
macros is just a sloppy hackery.

Thanks,

tglx

Re: [PATCH] dmi: mark all struct dmi_system_id instances const

[Jean Delvare]

Hi Christoph,

Sorry for the delay, this patch slipped trough the cracks somehow, I
only noticed it in my mailbox today.

On Mon, 15 May 2017 22:30:56 +0200, Christoph Hellwig wrote:
> ... and __initconst if applicable.
> 
> Based on similar work for an older kernel in the Grsecurity patch.

On the principle I think it is a good idea. I am not sure if pushing it
as a single patch through my dmi tree is the best thing to do, as it
could result in conflicts. The other option is to break it out on a per
subsystem basis. That being said, I just tried to apply this 2.5 months
later and there was no single conflict, so maybe a single patch is fine.

One issue though:

> (...)
> diff --git a/drivers/platform/x86/toshiba-wmi.c 
> b/drivers/platform/x86/toshiba-wmi.c
> index 440528676170..1756ccf69612 100644
> --- a/drivers/platform/x86/toshiba-wmi.c
> +++ b/drivers/platform/x86/toshiba-wmi.c
> @@ -64,7 +64,7 @@ static void toshiba_wmi_notify(u32 value, void *context)
>   kfree(response.pointer);
>  }
>  
> -static struct dmi_system_id toshiba_wmi_dmi_table[] __initdata = {
> +static struct const dmi_system_id toshiba_wmi_dmi_table[] __initconst = {
>   {
>   .ident = "Toshiba laptop",
>   .matches = {

"struct const dmi_system_id" doesn't build, it should be "const struct
dmi_system_id".

I'll fix that up. Also I see a new instance to fix in
drivers/input/touchscreen/htcpen.c, I'll take care of that.

Lastly checkpatch complains about the position of __initconst on 18
instances, I'll fix that as well.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH v3] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

[Vlastimil Babka]

On 07/31/2017 06:01 AM, Dima Zavin wrote:
> In codepaths that use the begin/retry interface for reading
> mems_allowed_seq with irqs disabled, there exists a race condition that
> stalls the patch process after only modifying a subset of the
> static_branch call sites.
> 
> This problem manifested itself as a dead lock in the slub
> allocator, inside get_any_partial. The loop reads
> mems_allowed_seq value (via read_mems_allowed_begin),
> performs the defrag operation, and then verifies the consistency
> of mem_allowed via the read_mems_allowed_retry and the cookie
> returned by xxx_begin. The issue here is that both begin and retry
> first check if cpusets are enabled via cpusets_enabled() static branch.
> This branch can be rewritted dynamically (via cpuset_inc) if a new
> cpuset is created. The x86 jump label code fully synchronizes across
> all CPUs for every entry it rewrites. If it rewrites only one of the
> callsites (specifically the one in read_mems_allowed_retry) and then
> waits for the smp_call_function(do_sync_core) to complete while a CPU is
> inside the begin/retry section with IRQs off and the mems_allowed value
> is changed, we can hang. This is because begin() will always return 0
> (since it wasn't patched yet) while retry() will test the 0 against
> the actual value of the seq counter.
> 
> The fix is to use two different static keys: one for begin
> (pre_enable_key) and one for retry (enable_key). In cpuset_inc(), we
> first bump the pre_enable key to ensure that cpuset_mems_allowed_begin()
> always return a valid seqcount if are enabling cpusets. Similarly,
> when disabling cpusets via cpuset_dec(), we first ensure that callers
> of cpuset_mems_allowed_retry() will start ignoring the seqcount
> value before we let cpuset_mems_allowed_begin() return 0.
> 
> The relevant stack traces of the two stuck threads:
> 
>   CPU: 1 PID: 1415 Comm: mkdir Tainted: G L  4.9.36-00104-g540c51286237 #4
>   Hardware name: Default string Default string/Hardware, BIOS 
> 4.29.1-20170526215256 05/26/2017
>   task: 8817f9c28000 task.stack: c9000ffa4000
>   RIP: smp_call_function_many+0x1f9/0x260
>   Call Trace:
> ? setup_data_read+0xa0/0xa0
> ? ___slab_alloc+0x28b/0x5a0
> smp_call_function+0x3b/0x70
> ? setup_data_read+0xa0/0xa0
> on_each_cpu+0x2f/0x90
> ? ___slab_alloc+0x28a/0x5a0
> ? ___slab_alloc+0x28b/0x5a0
> text_poke_bp+0x87/0xd0
> ? ___slab_alloc+0x28a/0x5a0
> arch_jump_label_transform+0x93/0x100
> __jump_label_update+0x77/0x90
> jump_label_update+0xaa/0xc0
> static_key_slow_inc+0x9e/0xb0
> cpuset_css_online+0x70/0x2e0
> online_css+0x2c/0xa0
> cgroup_apply_control_enable+0x27f/0x3d0
> cgroup_mkdir+0x2b7/0x420
> kernfs_iop_mkdir+0x5a/0x80
> vfs_mkdir+0xf6/0x1a0
> SyS_mkdir+0xb7/0xe0
> entry_SYSCALL_64_fastpath+0x18/0xad
> 
>   ...
> 
>   CPU: 2 PID: 1 Comm: init Tainted: G L  4.9.36-00104-g540c51286237 #4
>   Hardware name: Default string Default string/Hardware, BIOS 
> 4.29.1-20170526215256 05/26/2017
>   task: 8818087c task.stack: c903
>   RIP: int3+0x39/0x70
>   Call Trace:
> <#DB> ? ___slab_alloc+0x28b/0x5a0
>  ? copy_process.part.40+0xf7/0x1de0
> ? __slab_alloc.isra.80+0x54/0x90
> ? copy_process.part.40+0xf7/0x1de0
> ? copy_process.part.40+0xf7/0x1de0
> ? kmem_cache_alloc_node+0x8a/0x280
> ? copy_process.part.40+0xf7/0x1de0
> ? _do_fork+0xe7/0x6c0
> ? _raw_spin_unlock_irq+0x2d/0x60
> ? trace_hardirqs_on_caller+0x136/0x1d0
> ? entry_SYSCALL_64_fastpath+0x5/0xad
> ? do_syscall_64+0x27/0x350
> ? SyS_clone+0x19/0x20
> ? do_syscall_64+0x60/0x350
> ? entry_SYSCALL64_slow_path+0x25/0x25
> 
> Reported-by: Cliff Spradlin 
> Signed-off-by: Dima Zavin 

Looks good. Could you verify it fixes the issue, or was it too hard to
reproduce? Also is this a stable candidate patch, and can you identify
an exact commit hash it fixes?

Acked-by: Vlastimil Babka 

> ---
> 
> v3:
>  - Changed the implementation based on Peter Zijlstra's suggestion. Now
>using two keys for begin/retry instead of hacking the state into the
>cookie.
>  - Rebased and tested on top of v4.13-rc3.
> 
> v4:
>  - Moved the cached cpusets_enabled() state into the cookie, turned
>the cookie into a struct and updated all the other call sites.
>  - Applied on top of v4.12 since one of the callers in page_alloc.c changed.
>Still only tested on v4.9.36 and compile tested against v4.12.
> 
>  include/linux/cpuset.h | 19 +--
>  kernel/cgroup/cpuset.c |  1 +
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
> index 119a3f9604b0..e5a684c04c70 100644
> --- a/include/linux/cpuset.h
> +++ b/include/linux/cpuset.h
> @@ -18,6 +18,19 @@
>  
>  #ifdef CONFIG_CPUSETS
>  
> +/*
> + * Static branch rewrites can happen in an arbitrary order for a given
> + * key. In code paths where we need to loo

[PATCH v2] staging: pi433: Use matching enum types calling rf69_set_packet_format

[Elia Geretto]

This patch fixes the following four warnings found using sparse:

drivers/staging/pi433/pi433_if.c:211:9: warning: mixing different enum types
drivers/staging/pi433/pi433_if.c:211:9: int enum optionOnOff  versus
drivers/staging/pi433/pi433_if.c:211:9: int enum packetFormat
drivers/staging/pi433/pi433_if.c:211:9: warning: mixing different enum types
drivers/staging/pi433/pi433_if.c:211:9: int enum optionOnOff  versus
drivers/staging/pi433/pi433_if.c:211:9: int enum packetFormat
drivers/staging/pi433/pi433_if.c:268:9: warning: mixing different enum types
drivers/staging/pi433/pi433_if.c:268:9: int enum optionOnOff  versus
drivers/staging/pi433/pi433_if.c:268:9: int enum packetFormat
drivers/staging/pi433/pi433_if.c:268:9: warning: mixing different enum types
drivers/staging/pi433/pi433_if.c:268:9: int enum optionOnOff  versus
drivers/staging/pi433/pi433_if.c:268:9: int enum packetFormat

This is done calling the rf69_set_packet_format function using the
appropriate enum for the packetFormat argument.

Signed-off-by: Elia Geretto 
---
Changes in v2:
  - Declare ret at the top of the function.
  - Avoid moving the location of the check in rf69_set_tx_cfg.

 drivers/staging/pi433/pi433_if.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index d9328ce5ec1d..712d2efef195 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -182,6 +182,7 @@ static void *DIO_irq_handler[NUM_DIO] = {
 static int
 rf69_set_rx_cfg(struct pi433_device *dev, struct pi433_rx_cfg *rx_cfg)
 {
+   int ret;
int payload_length;
 
/* receiver config */
@@ -208,7 +209,15 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct 
pi433_rx_cfg *rx_cfg)
{
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, always));
}
-   SET_CHECKED(rf69_set_packet_format  (dev->spi, 
rx_cfg->enable_length_byte));
+   if (rx_cfg->enable_length_byte == optionOn) {
+   ret = rf69_set_packet_format(dev->spi, packetLengthVar);
+   if (ret < 0)
+   return ret;
+   } else {
+   ret = rf69_set_packet_format(dev->spi, packetLengthFix);
+   if (ret < 0)
+   return ret;
+   }
SET_CHECKED(rf69_set_adressFiltering(dev->spi, 
rx_cfg->enable_address_filtering));
SET_CHECKED(rf69_set_crc_enable (dev->spi, rx_cfg->enable_crc));
 
@@ -247,6 +256,8 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct 
pi433_rx_cfg *rx_cfg)
 static int
 rf69_set_tx_cfg(struct pi433_device *dev, struct pi433_tx_cfg *tx_cfg)
 {
+   int ret;
+
SET_CHECKED(rf69_set_frequency  (dev->spi, tx_cfg->frequency));
SET_CHECKED(rf69_set_bit_rate   (dev->spi, tx_cfg->bit_rate));
SET_CHECKED(rf69_set_modulation (dev->spi, tx_cfg->modulation));
@@ -265,7 +276,15 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct 
pi433_tx_cfg *tx_cfg)
SET_CHECKED(rf69_set_preamble_length(dev->spi, 0));
}
SET_CHECKED(rf69_set_sync_enable  (dev->spi, tx_cfg->enable_sync));
-   SET_CHECKED(rf69_set_packet_format(dev->spi, 
tx_cfg->enable_length_byte));
+   if (tx_cfg->enable_length_byte == optionOn) {
+   ret = rf69_set_packet_format(dev->spi, packetLengthVar);
+   if (ret < 0)
+   return ret;
+   } else {
+   ret = rf69_set_packet_format(dev->spi, packetLengthFix);
+   if (ret < 0)
+   return ret;
+   }
SET_CHECKED(rf69_set_crc_enable   (dev->spi, tx_cfg->enable_crc));
 
/* configure sync, if enabled */
-- 
2.13.3

Re: [PATCH] clk: meson: mpll: fix mpll0 fractional part ignored

[Neil Armstrong]

On 07/28/2017 06:32 PM, Jerome Brunet wrote:
> mpll0 clock is special compared to the other mplls. It needs another
> bit (ssen) to be set to activate the fractional part the mpll divider
> 
> Fixes: 007e6e5c5f01 ("clk: meson: mpll: add rw operation")
> Signed-off-by: Jerome Brunet 
> ---
>  drivers/clk/meson/clk-mpll.c | 7 +++
>  drivers/clk/meson/clkc.h | 1 +
>  drivers/clk/meson/gxbb.c | 5 +
>  drivers/clk/meson/meson8b.c  | 5 +
>  4 files changed, 18 insertions(+)
> 
> diff --git a/drivers/clk/meson/clk-mpll.c b/drivers/clk/meson/clk-mpll.c
> index 39eab69fe51a..44a5a535ca63 100644
> --- a/drivers/clk/meson/clk-mpll.c
> +++ b/drivers/clk/meson/clk-mpll.c
> @@ -161,6 +161,13 @@ static int mpll_set_rate(struct clk_hw *hw,
>   reg = PARM_SET(p->width, p->shift, reg, 1);
>   writel(reg, mpll->base + p->reg_off);
>  
> + p = &mpll->ssen;
> + if (p->width != 0) {
> + reg = readl(mpll->base + p->reg_off);
> + reg = PARM_SET(p->width, p->shift, reg, 1);
> + writel(reg, mpll->base + p->reg_off);
> + }
> +
>   p = &mpll->n2;
>   reg = readl(mpll->base + p->reg_off);
>   reg = PARM_SET(p->width, p->shift, reg, n2);
> diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
> index d6feafe8bd6c..1629da9b4141 100644
> --- a/drivers/clk/meson/clkc.h
> +++ b/drivers/clk/meson/clkc.h
> @@ -118,6 +118,7 @@ struct meson_clk_mpll {
>   struct parm sdm_en;
>   struct parm n2;
>   struct parm en;
> + struct parm ssen;
>   spinlock_t *lock;
>  };
>  
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 59a296b119ea..79b195b4df03 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -528,6 +528,11 @@ static struct meson_clk_mpll gxbb_mpll0 = {
>   .shift   = 14,
>   .width   = 1,
>   },
> + .ssen = {
> + .reg_off = HHI_MPLL_CNTL,
> + .shift   = 25,
> + .width   = 1,
> + },
>   .lock = &clk_lock,
>   .hw.init = &(struct clk_init_data){
>   .name = "mpll0",
> diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
> index bb3f1de876b1..6ec512ad2598 100644
> --- a/drivers/clk/meson/meson8b.c
> +++ b/drivers/clk/meson/meson8b.c
> @@ -267,6 +267,11 @@ static struct meson_clk_mpll meson8b_mpll0 = {
>   .shift   = 14,
>   .width   = 1,
>   },
> + .ssen = {
> + .reg_off = HHI_MPLL_CNTL,
> + .shift   = 25,
> + .width   = 1,
> + },
>   .lock = &clk_lock,
>   .hw.init = &(struct clk_init_data){
>   .name = "mpll0",
> 


Applied to clk-meson's fixes/drivers !

Re: [PATCH 04/29] scsi: pm8001: constify pci_device_id.

[Jinpu Wang]

On Sun, Jul 30, 2017 at 10:37 AM, Arvind Yadav
 wrote:
> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by  work with
> const pci_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/scsi/pm8001/pm8001_init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c 
> b/drivers/scsi/pm8001/pm8001_init.c
> index 034b2f7..f2757cc 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -1270,7 +1270,7 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
>  /* update of pci device, vendor id and driver data with
>   * unique value for each of the controller
>   */
> -static struct pci_device_id pm8001_pci_table[] = {
> +static const struct pci_device_id pm8001_pci_table[] = {
> { PCI_VDEVICE(PMC_Sierra, 0x8001), chip_8001 },
> { PCI_VDEVICE(PMC_Sierra, 0x8006), chip_8006 },
> { PCI_VDEVICE(ADAPTEC2, 0x8006), chip_8006 },
> --
> 2.7.4
>

Thanks,
Acked-by: Jack Wang 

-- 
Jack Wang
Linux Kernel Developer

Re: [PATCH v2 4/4] clk: meson: gxbb-aoclk: Add CEC 32k clock

[Neil Armstrong]

Hi,

On 07/29/2017 10:04 AM, Chris Moore wrote:
> Hi,
> 
> Sorry I forgot to reply to all in my previous post :(
> I hope this corrects things.
> 
> Le 28/07/2017 à 11:53, Neil Armstrong a écrit :
> 
> [snip]
> 
>> +static long aoclk_cec_32k_round_rate(struct clk_hw *hw, unsigned long rate,
>> + unsigned long *prate)
>> +{
>> +const struct cec_32k_freq_table *freq = find_cec_32k_freq(rate,
>> +  *prate);
>> +
>> +/* If invalid return first one */
>> +if (!freq)
>> +return freq[0].target_rate;
> 
> Wouldn't this dereference a null pointer (or am I being stupid this morning)?

No, it's me !!
Will fix it in v3...

> 
>> +
>> +return freq->target_rate;
>> +}
>> +
>> +static int aoclk_cec_32k_set_rate(struct clk_hw *hw, unsigned long rate,
>> +  unsigned long parent_rate)
>> +{
>> +const struct cec_32k_freq_table *freq = find_cec_32k_freq(rate,
>> +  parent_rate);
>> +struct aoclk_cec_32k *cec_32k = to_aoclk_cec_32k(hw);
>> +u32 reg = 0;
>> +
>> +if (!freq)
>> +return -EINVAL;
>> +
>> +/* Disable clock */
>> +regmap_update_bits(cec_32k->regmap, AO_RTC_ALT_CLK_CNTL0,
>> +   CLK_CNTL0_IN_GATE_EN | CLK_CNTL0_OUT_GATE_EN, 0);
>> +
>> +if (freq->dualdiv)
>> +reg = CLK_CNTL0_DUALDIV_EN |
>> +  FIELD_PREP(CLK_CNTL0_N1_MASK, freq->n1 - 1) |
>> +  FIELD_PREP(CLK_CNTL0_N2_MASK, freq->n2 - 1);
>> +else
>> +reg = FIELD_PREP(CLK_CNTL0_N1_MASK, freq->n1 - 1);
>> +
> 
> Suggestion:
> 
> +reg = FIELD_PREP(CLK_CNTL0_N1_MASK, freq->n1 - 1);
> +if (freq->dualdiv)
> +reg |= CLK_CNTL0_DUALDIV_EN |
> +   FIELD_PREP(CLK_CNTL0_N2_MASK, freq->n2 - 1);
> 
> is shorter but maybe generates the same code.
> 
>> + regmap_write(cec_32k->regmap, AO_RTC_ALT_CLK_CNTL0, reg);
>> +
>> +if (freq->dualdiv)
>> +reg = FIELD_PREP(CLK_CNTL1_M1_MASK, freq->m1 - 1) |
>> +  FIELD_PREP(CLK_CNTL1_M2_MASK, freq->m2 - 1);
>> +else
>> +reg = FIELD_PREP(CLK_CNTL1_M1_MASK, freq->m1 - 1);
>> +
> 
> Idem:
> 
> +reg = FIELD_PREP(CLK_CNTL1_M1_MASK, freq->m1 - 1);
> +if (freq->dualdiv)
> +reg |= FIELD_PREP(CLK_CNTL1_M2_MASK, freq->m2 - 1);
>

Thanks for the suggestions, I will send a v3 asap.

Neil
> Cheers,
> Chris

Re: [PATCH v3 1/5] [media] v4l: add porter duff blend controls

[Hans Verkuil]

On 07/31/2017 05:07 AM, Jacob Chen wrote:
> At peresent, we don't have a control for Compositing and Blend.
> All drivers are just doing copies while actually many hardwares
> supports more functions.
> 
> So Adding V4L2 controls for Compositing and Blend, used for for
> composting streams.
> 
> The values are based on porter duff operations.
> Defined in below links.
> https://developer.xamarin.com/api/type/Android.Graphics.PorterDuff+Mode/
> 
> Signed-off-by: Jacob Chen 
> Suggested-by: Nicolas Dufresne 
> ---
>  drivers/media/v4l2-core/v4l2-ctrls.c | 20 +++-
>  include/uapi/linux/v4l2-controls.h   | 16 +++-
>  2 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index b9e08e3..561d7d5 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -478,7 +478,21 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>   "Region Grid",
>   NULL,
>   };
> -
> + static const char * const porter_duff_modes[] = {
> + "Source",
> + "Source Top",
> + "Source In",
> + "Source Out",
> + "Source Over",
> + "Destination",
> + "Destination Top",
> + "Destination In",
> + "Destination Out",
> + "Destination Over",
> + "Add",
> + "Clear",
> + NULL
> + };
>  
>   switch (id) {
>   case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> @@ -564,6 +578,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>   return vpx_golden_frame_sel;
>   case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
>   return jpeg_chroma_subsampling;
> + case V4L2_CID_PORTER_DUFF_MODE:
> + return porter_duff_modes;
>   case V4L2_CID_DV_TX_MODE:
>   return dv_tx_mode;
>   case V4L2_CID_DV_TX_RGB_RANGE:
> @@ -886,6 +902,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>   case V4L2_CID_PIXEL_RATE:   return "Pixel Rate";
>   case V4L2_CID_TEST_PATTERN: return "Test Pattern";
>   case V4L2_CID_DEINTERLACING_MODE:   return "Deinterlacing Mode";
> + case V4L2_CID_PORTER_DUFF_MODE: return "PorterDuff Blend Modes";
>  
>   /* DV controls */
>   /* Keep the order of the 'case's the same as in v4l2-controls.h! */
> @@ -1060,6 +1077,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
> v4l2_ctrl_type *type,
>   case V4L2_CID_DV_RX_IT_CONTENT_TYPE:
>   case V4L2_CID_TEST_PATTERN:
>   case V4L2_CID_DEINTERLACING_MODE:
> + case V4L2_CID_PORTER_DUFF_MODE:
>   case V4L2_CID_TUNE_DEEMPHASIS:
>   case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
>   case V4L2_CID_DETECT_MD_MODE:
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index 0d2e1e0..9543b4b 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -893,7 +893,21 @@ enum v4l2_jpeg_chroma_subsampling {
>  #define V4L2_CID_PIXEL_RATE  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
> + 2)
>  #define V4L2_CID_TEST_PATTERN
> (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
>  #define V4L2_CID_DEINTERLACING_MODE  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
> + 4)
> -
> +#define V4L2_CID_PORTER_DUFF_MODE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
> + 5)

I recommend that you add a link to e.g. 
https://en.wikipedia.org/wiki/Alpha_compositing
as a comment here.

> +enum v4l2_porter_duff_mode {
> + V4L2_PORTER_DUFF_SRC= 0,
> + V4L2_PORTER_DUFF_SRCATOP= 1,
> + V4L2_PORTER_DUFF_SRCIN  = 2,
> + V4L2_PORTER_DUFF_SRCOUT = 3,
> + V4L2_PORTER_DUFF_SRCOVER= 4,
> + V4L2_PORTER_DUFF_DST= 5,
> + V4L2_PORTER_DUFF_DSTATOP= 6,
> + V4L2_PORTER_DUFF_DSTIN  = 7,
> + V4L2_PORTER_DUFF_DSTOUT = 8,
> + V4L2_PORTER_DUFF_DSTOVER= 9,
> + V4L2_PORTER_DUFF_ADD= 10,
> + V4L2_PORTER_DUFF_CLEAR  = 11,
> +};
>  
>  /*  DV-class control IDs defined by V4L2 */
>  #define V4L2_CID_DV_CLASS_BASE   (V4L2_CTRL_CLASS_DV | 
> 0x900)
> 

This control also has to be documented in 
Documentation/media/uapi/v4l/extended-controls.rst.

Regards,

Hans

Re: [PATCH 0/2] ARM64: dts: meson-gx: Enable CEC

[Neil Armstrong]

On 07/10/2017 09:56 AM, Neil Armstrong wrote:
> This patchset enables :
>  - Support for the AO domain CEC 32k clock
>  - AO CEC Controller linked with the HDMI controller all HDMI supported boards
> 
> Neil Armstrong (2):
>   ARM64: dts: meson-gx: Add PWR and CRT/RTC nodes and adresses
>   ARM64: dts: meson-gx: Add AO CEC nodes
> 
>  arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |  7 +++
>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi   | 17 
> -
>  arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts  |  7 +++
>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi|  7 +++
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi |  6 ++
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts|  8 +++-
>  .../boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts|  7 +++
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts|  7 +++
>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  |  6 ++
>  arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |  7 +++
>  10 files changed, 77 insertions(+), 2 deletions(-)
> 

Hi Kevin,

This serie will need a re-spin due to a change in the aoclk bindings!

Neil

Re: [PATCH] netfilter: ipvs: Fix space before '[' error.

[Simon Horman]

On Sun, Jul 30, 2017 at 12:29:25PM +0530, Arvind Yadav wrote:
> Fix checkpatch.pl error:
> ERROR: space prohibited before open square bracket '['.
> 
> Signed-off-by: Arvind Yadav 

Thanks, applied for v4.14.

Re: [PATCH] Staging: vc04_services: Fix WARN_ON instead of BUG_ON

[Stefan Wahren]

Am 31.07.2017 um 09:14 schrieb janani-sankarababu:
> This patch is to replace the use of BUG_ON macro with WARN_ON
> inorder to prevent the crashing of the kernel.

Unfortunately it isn't always that simple. checkpatch isn't smart. It's
preferred to handle error cases instead of flooding the kernel log.

>
> Signed-off-by: Janani Sankara Babu 
> ---
>  drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
> b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
> index f484bb0..30bc246 100644
> --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
> +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
> @@ -91,7 +91,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol 
> *kcontrol,
>   if (mutex_lock_interruptible(&chip->audio_mutex))
>   return -EINTR;
>  
> - BUG_ON(!chip && !(chip->avail_substreams & AVAIL_SUBSTREAMS_MASK));
> + WARN_ON(!chip && !(chip->avail_substreams & AVAIL_SUBSTREAMS_MASK));

The complete logic seems strange to me and the statement before didn't
even check for chip.

Regards
Stefan

>  
>   if (kcontrol->private_value == PCM_PLAYBACK_VOLUME)
>   ucontrol->value.integer.value[0] = chip2alsa(chip->volume);

[PATCH 3/3] pinctrl: add mt2712 pinctrl driver

[Zhiyong Tao]

The commit includes changes:
1)Add mt2712 pinctrl driver.
2)Arrange "mtk_pinctrl" before "mtk_pinctrl_devdata"
  in "pinctrl-mtk-common.h".
3)Add "spec_dir_set" and "spec_dir_get" in "mtk_pinctrl_devdata".
4)Change "spec_dir_set" and add "spec_dir_get" in "pinctrl-mt2701.c"
  and "pinctrl-mtk-common.c".
5)Change "port_mask" from "7" to "6" for EINT.
6)Remove generic pull config condition in "mtk_pconf_set_pull_select".
7)Change "arg" to "MTK_PUPD_SET_R1R0_00" of "mtk_pconf_set_pull_select".

Signed-off-by: Zhiyong Tao 
---
 drivers/pinctrl/mediatek/Kconfig  |8 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt2701.c |   21 +-
 drivers/pinctrl/mediatek/pinctrl-mt2712.c |  670 +
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   16 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-common.h |   44 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1858 +
 7 files changed, 2586 insertions(+), 32 deletions(-)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index fac9866..2e7be73 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -31,6 +31,14 @@ config PINCTRL_MT8127
select PINCTRL_MTK
 
 # For ARMv8 SoCs
+
+config PINCTRL_MT2712
+   bool "Mediatek MT2712 pin control"
+   depends on OF
+   depends on ARM64 || COMPILE_TEST
+   default ARM64 && ARCH_MEDIATEK
+   select PINCTRL_MTK
+
 config PINCTRL_MT8173
bool "Mediatek MT8173 pin control"
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index e59c613..26c7435 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -3,6 +3,7 @@ obj-y   += pinctrl-mtk-common.o
 
 # SoC Drivers
 obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
+obj-$(CONFIG_PINCTRL_MT2712)   += pinctrl-mt2712.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
 obj-$(CONFIG_PINCTRL_MT8173)   += pinctrl-mt8173.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2701.c 
b/drivers/pinctrl/mediatek/pinctrl-mt2701.c
index f86f3b3..4a43f5c 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt2701.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt2701.c
@@ -503,10 +503,26 @@ static void mt2701_spec_pinmux_set(struct regmap *reg, 
unsigned int pin,
regmap_update_bits(reg, mt2701_spec_pinmux[i].offset, mask, value);
 }
 
-static void mt2701_spec_dir_set(unsigned int *reg_addr, unsigned int pin)
+static int mt2701_spec_dir_set(struct mtk_pinctrl *pctl,
+   unsigned int *reg_addr,
+   unsigned int pin,
+   bool input)
 {
if (pin > 175)
*reg_addr += 0x10;
+
+   return 0;
+}
+
+static int mt2701_spec_dir_get(struct mtk_pinctrl *pctl,
+   unsigned int *reg_addr,
+   unsigned int pin,
+   bool input)
+{
+   if (pin > 175)
+   *reg_addr += 0x10;
+
+   return 0;
 }
 
 static const struct mtk_pinctrl_devdata mt2701_pinctrl_data = {
@@ -520,6 +536,7 @@ static void mt2701_spec_dir_set(unsigned int *reg_addr, 
unsigned int pin)
.spec_ies_smt_set = mt2701_ies_smt_set,
.spec_pinmux_set = mt2701_spec_pinmux_set,
.spec_dir_set = mt2701_spec_dir_set,
+   .spec_dir_get = mt2701_spec_dir_get,
.dir_offset = 0x,
.pullen_offset = 0x0150,
.pullsel_offset = 0x0280,
@@ -551,7 +568,7 @@ static void mt2701_spec_dir_set(unsigned int *reg_addr, 
unsigned int pin)
.dbnc_ctrl = 0x500,
.dbnc_set  = 0x600,
.dbnc_clr  = 0x700,
-   .port_mask = 6,
+   .port_mask = 7,
.ports = 6,
},
.ap_num = 169,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c 
b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
new file mode 100644
index 000..c933b75
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
@@ -0,0 +1,670 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Hongzhou.Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt2712.h"

[PATCH 0/3] PINCTRL: Mediatek pinctrl driver for mt2712

[Zhiyong Tao]

This series includes three patches:
1.Add mt2712 compatible node in binding document.
2.Add mt2712 pinctrl device node.
3.Add mt2712 pinctrl driver.

Zhiyong Tao (3):
  dt-bindings: pinctrl: mt2712: add binding document
  arm64: dts: mt2712: add pintcrl device node.
  pinctrl: add mt2712 pinctrl driver

 .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |1 +
 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h  | 1014 +++
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi  |   18 +
 drivers/pinctrl/mediatek/Kconfig   |8 +
 drivers/pinctrl/mediatek/Makefile  |1 +
 drivers/pinctrl/mediatek/pinctrl-mt2701.c  |   21 +-
 drivers/pinctrl/mediatek/pinctrl-mt2712.c  |  670 +++
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c  |   16 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-common.h  |   44 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h  | 1858 
 10 files changed, 3619 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h

--
1.9.1

URGENT REPLY FOR MORE DETAILS.

[casimire kere]

Compliment of the day,

I am Mr.Kere Casmire I Have a Business Proposal of $5.3 million For You.
I am aware of the unsafe nature of the internet,
and was compelled to use this medium due to the nature of this project.

I have access to very vital information that can be used to transfer
this huge amount of money.

which may culminate into the investment of the said funds into your
company or any lucrative venture in your country.

If you will like to assist me as a partner then indicate your interest,
after which we shall both discuss the modalities and the sharing percentage.

Upon receipt of your reply on your expression of Interest I will give
you full details,
on how the business will be executed I am open for negotiation.

Thanks for your anticipated cooperation.

Note you might receive this message in your inbox or spam or junk folder,
depends on your web host or server network.

Regards,
Mr.Kere Casmire

[PATCH 2/3] arm64: dts: mt2712: add pintcrl device node.

[Zhiyong Tao]

The commit includes two change:
1)add pintcrl device node for mt2712.
2)add pinfunc file for mt2712.

Signed-off-by: Zhiyong Tao 
---
 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1014 +
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi |   18 +
 2 files changed, 1032 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h

diff --git a/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h 
b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
new file mode 100644
index 000..fe9d7bd
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
@@ -0,0 +1,1014 @@
+/*
+ * Copyright (C) 2015 MediaTek Inc.
+ *
+ * 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.
+ */
+#ifndef __DTS_MT2712_PINFUNC_H
+#define __DTS_MT2712_PINFUNC_H
+
+#include 
+
+#define MT2712_PIN_0_EINT0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define MT2712_PIN_0_EINT0__FUNC_EINT0 (MTK_PIN_NO(0) | 1)
+#define MT2712_PIN_0_EINT0__FUNC_MBIST_DIAG_SCANOUT (MTK_PIN_NO(0) | 2)
+#define MT2712_PIN_0_EINT0__FUNC_DSIA_TE (MTK_PIN_NO(0) | 3)
+#define MT2712_PIN_0_EINT0__FUNC_DIN_D3 (MTK_PIN_NO(0) | 5)
+
+#define MT2712_PIN_1_EINT1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define MT2712_PIN_1_EINT1__FUNC_EINT1 (MTK_PIN_NO(1) | 1)
+#define MT2712_PIN_1_EINT1__FUNC_IR_IN (MTK_PIN_NO(1) | 2)
+#define MT2712_PIN_1_EINT1__FUNC_DSIB_TE (MTK_PIN_NO(1) | 3)
+#define MT2712_PIN_1_EINT1__FUNC_DIN_D4 (MTK_PIN_NO(1) | 5)
+
+#define MT2712_PIN_2_EINT2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define MT2712_PIN_2_EINT2__FUNC_EINT2 (MTK_PIN_NO(2) | 1)
+#define MT2712_PIN_2_EINT2__FUNC_IR_IN (MTK_PIN_NO(2) | 2)
+#define MT2712_PIN_2_EINT2__FUNC_LCM_RST1 (MTK_PIN_NO(2) | 3)
+#define MT2712_PIN_2_EINT2__FUNC_DIN_D5 (MTK_PIN_NO(2) | 5)
+
+#define MT2712_PIN_3_EINT3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define MT2712_PIN_3_EINT3__FUNC_EINT3 (MTK_PIN_NO(3) | 1)
+#define MT2712_PIN_3_EINT3__FUNC_IR_IN (MTK_PIN_NO(3) | 2)
+#define MT2712_PIN_3_EINT3__FUNC_LCM_RST0 (MTK_PIN_NO(3) | 3)
+#define MT2712_PIN_3_EINT3__FUNC_DIN_D6 (MTK_PIN_NO(3) | 5)
+
+#define MT2712_PIN_4_PWM0__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define MT2712_PIN_4_PWM0__FUNC_PWM0 (MTK_PIN_NO(4) | 1)
+#define MT2712_PIN_4_PWM0__FUNC_DISP0_PWM (MTK_PIN_NO(4) | 2)
+#define MT2712_PIN_4_PWM0__FUNC_DISP1_PWM (MTK_PIN_NO(4) | 3)
+#define MT2712_PIN_4_PWM0__FUNC_DIN_CLK (MTK_PIN_NO(4) | 5)
+
+#define MT2712_PIN_5_PWM1__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define MT2712_PIN_5_PWM1__FUNC_PWM1 (MTK_PIN_NO(5) | 1)
+#define MT2712_PIN_5_PWM1__FUNC_DISP1_PWM (MTK_PIN_NO(5) | 2)
+#define MT2712_PIN_5_PWM1__FUNC_DISP0_PWM (MTK_PIN_NO(5) | 3)
+#define MT2712_PIN_5_PWM1__FUNC_DIN_VSYNC (MTK_PIN_NO(5) | 5)
+
+#define MT2712_PIN_6_PWM2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define MT2712_PIN_6_PWM2__FUNC_PWM2 (MTK_PIN_NO(6) | 1)
+#define MT2712_PIN_6_PWM2__FUNC_DISP0_PWM (MTK_PIN_NO(6) | 2)
+#define MT2712_PIN_6_PWM2__FUNC_DISP1_PWM (MTK_PIN_NO(6) | 3)
+#define MT2712_PIN_6_PWM2__FUNC_DIN_HSYNC (MTK_PIN_NO(6) | 5)
+
+#define MT2712_PIN_7_PWM3__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define MT2712_PIN_7_PWM3__FUNC_PWM3 (MTK_PIN_NO(7) | 1)
+#define MT2712_PIN_7_PWM3__FUNC_DISP1_PWM (MTK_PIN_NO(7) | 2)
+#define MT2712_PIN_7_PWM3__FUNC_DISP0_PWM (MTK_PIN_NO(7) | 3)
+#define MT2712_PIN_7_PWM3__FUNC_DIN_D0 (MTK_PIN_NO(7) | 5)
+
+#define MT2712_PIN_8_PWM4__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define MT2712_PIN_8_PWM4__FUNC_PWM4 (MTK_PIN_NO(8) | 1)
+#define MT2712_PIN_8_PWM4__FUNC_DISP0_PWM (MTK_PIN_NO(8) | 2)
+#define MT2712_PIN_8_PWM4__FUNC_DISP1_PWM (MTK_PIN_NO(8) | 3)
+#define MT2712_PIN_8_PWM4__FUNC_DSIA_TE (MTK_PIN_NO(8) | 4)
+#define MT2712_PIN_8_PWM4__FUNC_DIN_D1 (MTK_PIN_NO(8) | 5)
+
+#define MT2712_PIN_9_PWM5__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define MT2712_PIN_9_PWM5__FUNC_PWM5 (MTK_PIN_NO(9) | 1)
+#define MT2712_PIN_9_PWM5__FUNC_DISP1_PWM (MTK_PIN_NO(9) | 2)
+#define MT2712_PIN_9_PWM5__FUNC_DISP0_PWM (MTK_PIN_NO(9) | 3)
+#define MT2712_PIN_9_PWM5__FUNC_DSIB_TE (MTK_PIN_NO(9) | 4)
+#define MT2712_PIN_9_PWM5__FUNC_DIN_D2 (MTK_PIN_NO(9) | 5)
+
+#define MT2712_PIN_10_PWM6__FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
+#define MT2712_PIN_10_PWM6__FUNC_PWM6 (MTK_PIN_NO(10) | 1)
+#define MT2712_PIN_10_PWM6__FUNC_DISP0_PWM (MTK_PIN_NO(10) | 2)
+#define MT2712_PIN_10_PWM6__FUNC_DISP1_PWM (MTK_PIN_NO(10) | 3)
+#define MT2712_PIN_10_PWM6__FUNC_LCM_RST0 (MTK_PIN_NO(10) | 4)
+
+#define MT2712_PIN_11_PWM7__FUNC_GPIO11 (MTK_PIN_NO(11) | 0)
+#define MT2712_PIN_11_PWM7__FUNC_PWM7 (MTK_PIN_NO(11) | 1)
+#define MT2712_PIN_11_PWM7__FUNC_DISP1_PWM (MTK_PIN_NO(11) | 2)
+#define MT2712_PIN_11_PWM7__FUNC_DISP0_PWM (MTK_PIN_NO(11) | 3)
+#define MT2712_PIN_11_PWM7__FUNC_LCM_RST1 (MTK_PIN_

[PATCH 1/3] dt-bindings: pinctrl: mt2712: add binding document

[Zhiyong Tao]

The commit adds mt2712 compatible node in binding document.

Signed-off-by: Zhiyong Tao 
---
 .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
index 17631d0..37d7447 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
@@ -5,6 +5,7 @@ The Mediatek's Pin controller is used to control SoC pins.
 Required properties:
 - compatible: value should be one of the following.
"mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl.
+   "mediatek,mt2712-pinctrl", compatible with mt2712 pinctrl.
"mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
"mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl.
"mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.
-- 
1.7.9.5

Re: [RFC Part1 PATCH v3 10/17] resource: Provide resource struct in resource walk callback

[Borislav Petkov]

On Mon, Jul 24, 2017 at 02:07:50PM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> In prep for a new function that will need additional resource information
> during the resource walk, update the resource walk callback to pass the
> resource structure.  Since the current callback start and end arguments
> are pulled from the resource structure, the callback functions can obtain
> them from the resource structure directly.
> 
> Signed-off-by: Tom Lendacky 
> Signed-off-by: Brijesh Singh 
> ---
>  arch/powerpc/kernel/machine_kexec_file_64.c | 12 +---
>  arch/x86/kernel/crash.c | 18 +-
>  arch/x86/kernel/pmem.c  |  2 +-
>  include/linux/ioport.h  |  4 ++--
>  include/linux/kexec.h   |  2 +-
>  kernel/kexec_file.c |  5 +++--
>  kernel/resource.c   |  9 +
>  7 files changed, 30 insertions(+), 22 deletions(-)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH] drm: adding SDI to drm_connector_enum_list

[Daniel Vetter]

On Fri, Jul 28, 2017 at 09:27:22AM +, Saurabh Singh wrote:
> Hi Daniel,
> 
> Thanks for your reply.
> Currently I am using connector type 'Unknown' , and functionally it serves my 
> need.
> Intention for sending this patch is that userspace tools should recognize SDI 
> drivers as SDI only.
> Also, I see there are number of 'SDI' drivers getting developed 'under the 
> hood' in linux kernel.
> This patch will benefit all of them.

Where are those?

> It will be great if you could consider it.

Well new uabi has very strict merge requirements:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

I'll merge your patch as soon as all the pieces are ready. Just wanted to
warn you that this is a _lot_ of work, and you probably want a really good
reason.

Thanks, Daniel
> 
> Regards,
> Saurabh
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Wednesday, July 26, 2017 8:08 PM
> To: Saurabh Singh 
> Cc: linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org; 
> airl...@linux.ie; Saurabh Singh ; Dinesh Kumar 
> 
> Subject: Re: [PATCH] drm: adding SDI to drm_connector_enum_list
> 
> On Wed, Jul 26, 2017 at 10:22:49AM +0530, Saurabh Sengar wrote:
> > adding SDI to drm connector list
> >
> > Signed-off-by: Saurabh Sengar 
> 
> This is an uapi change, i.e. userspace needs to be updated. Do you _really_ 
> need this? I'd recommend to just use something existing (go with VIRTUAL 
> maybe, not sure).
> 
> Either way, needs to come together with the actual users and userspace side 
> patches. If you really want this.
> -Daniel
> > ---
> >  drivers/gpu/drm/drm_connector.c | 1 +
> >  include/uapi/drm/drm_mode.h | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c index 2db7fb5..ea48ddb 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -86,6 +86,7 @@ static struct drm_conn_prop_enum_list 
> > drm_connector_enum_list[] = {
> >   { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
> >   { DRM_MODE_CONNECTOR_DSI, "DSI" },
> >   { DRM_MODE_CONNECTOR_DPI, "DPI" },
> > + { DRM_MODE_CONNECTOR_SDI, "SDI" },
> >  };
> >
> >  void drm_connector_ida_init(void)
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index df0e350..9b8d204 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -247,6 +247,7 @@ struct drm_mode_get_encoder {
> >  #define DRM_MODE_CONNECTOR_VIRTUAL  15
> >  #define DRM_MODE_CONNECTOR_DSI   16
> >  #define DRM_MODE_CONNECTOR_DPI   17
> > +#define DRM_MODE_CONNECTOR_SDI   18
> >
> >  struct drm_mode_get_connector {
> >
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> 
> 
> 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.
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Thomas Gleixner]

On Mon, 31 Jul 2017, Tomi Sarvela wrote:
> On 31/07/17 10:45, Thomas Gleixner wrote:
> > On Mon, 31 Jul 2017, Tomi Sarvela wrote:
> > > On 28/07/17 19:26, Thomas Gleixner wrote:
> > > > Did you change anything else compared to the tests before ?
> > > 
> > > I did check that the problem persisted in linus-HEAD before testing your
> > > patch. The testing was done in order (reading from console logs I happen
> > > to
> > > still have in one window):
> > 
> > What I still do not understand is why this would affect the suspend path in
> > any way.
> > 
> > Can you remove the previous patch and apply the one below. If it resumes,
> > please provide the data from the trace buffer again.
> 
> No such luck. ELK hangs in the suspend-test with earlier patch removed, this
> added. Checked again that the power-led is on, no serial output.
> 
> Tree not pulled: still testing against the previous head -rc2, not current
> 4.13.0-rc3

Shouldn't make a difference. Can you please try the following:

Offline CPU1 before invoking suspend.

# echo 0 >/sys/devices/system/cpus/cpu1/offline

Thanks,

tglx

Re: [PATCH 3/3] mm/sched: memdelay: memory health interface for systems and workloads

[Peter Zijlstra]

On Sun, Jul 30, 2017 at 11:28:13AM -0400, Johannes Weiner wrote:
> On Sat, Jul 29, 2017 at 11:10:55AM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 27, 2017 at 11:30:10AM -0400, Johannes Weiner wrote:
> > > +static void domain_cpu_update(struct memdelay_domain *md, int cpu,
> > > +   int old, int new)
> > > +{
> > > + enum memdelay_domain_state state;
> > > + struct memdelay_domain_cpu *mdc;
> > > + unsigned long now, delta;
> > > + unsigned long flags;
> > > +
> > > + mdc = per_cpu_ptr(md->mdcs, cpu);
> > > + spin_lock_irqsave(&mdc->lock, flags);
> > 
> > Afaict this is inside scheduler locks, this cannot be a spinlock. Also,
> > do we really want to add more atomics there?
> 
> I think we should be able to get away without an additional lock and
> rely on the rq lock instead. schedule, enqueue, dequeue already hold
> it, memdelay_enter/leave could be added. I need to think about what to
> do with try_to_wake_up in order to get the cpu move accounting inside
> the locked section of ttwu_queue(), but that should be doable too.

So could you start by describing what actual statistics we need? Because
as is the scheduler already does a gazillion stats and why can't re
repurpose some of those?

Re: [PATCH] mm: don't zero ballooned pages

[Wei Wang]

On 07/31/2017 03:43 PM, Michal Hocko wrote:

On Mon 31-07-17 15:41:49, Wei Wang wrote:

On 07/31/2017 02:55 PM, Michal Hocko wrote:

On Mon 31-07-17 12:13:33, Wei Wang wrote:

Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
shouldn't be given to the host ksmd to scan.

Could you point me where this MADV_DONTNEED is done, please?

Sure. It's done in the hypervisor when the balloon pages are received.

Please see line 40 at
https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c

Thanks. Are all hypervisors which are using this API doing this?



The implementation may be different across different hypervisors.
But the underlying concept is the same - they unmap the balloon
pages from the guest and those pages will be given to other guests
or host processes to use.

Regardless of the implementation, I think it is an improper operation
to make the memory KSM mergeable when the memory does not
belong to the guest anymore.


Best,
Wei

[PATCH] ASoC: improve RT5514 dependencies

[Arnd Bergmann]

With SND_SOC_RT5514_SPI=m and SND_SOC_RT5514=y, we get this link error:

sound/soc/codecs/rt5514.o: In function `rt5514_dsp_voice_wake_up_put':
rt5514.c:(.text+0x2068): undefined reference to `rt5514_spi_burst_write'
rt5514.c:(.text+0x20c8): undefined reference to `rt5514_spi_burst_write'

This adds another Kconfig symbol to work around the link error, forcing
the main driver to be a loadable module as well if some other driver
selects the I2C side to be built-in.

Fixes: 2a18483a7fb4 ("ASoC: Intel: Add Kabylake machine driver for RT5514, 
RT5663 and MAX98927")
Signed-off-by: Arnd Bergmann 
---
This can now lead to a configuration with
SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH=y and SND_SOC_RT5514=m. I
don't know if that is a problem or not.

An alternative approach would be to flip the dependency between
rt5514_spi.ko and rt5514.ko and avoid having the rt5514_spi_burst_write
symbol exported.
---
 sound/soc/codecs/Kconfig   | 7 ++-
 sound/soc/intel/Kconfig| 2 +-
 sound/soc/mediatek/Kconfig | 2 +-
 sound/soc/rockchip/Kconfig | 1 -
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 024ddc9938ed..115c6144ca2a 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -117,7 +117,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_RT274 if I2C
select SND_SOC_RT286 if I2C
select SND_SOC_RT298 if I2C
-   select SND_SOC_RT5514 if I2C
+   select SND_SOC_RT5514_I2C if I2C
select SND_SOC_RT5616 if I2C
select SND_SOC_RT5631 if I2C
select SND_SOC_RT5640 if I2C
@@ -738,6 +738,11 @@ config SND_SOC_RT298
 
 config SND_SOC_RT5514
tristate
+   default m if SND_SOC_RT5514_SPI=m
+   default SND_SOC_RT5514_I2C || SND_SOC_RT5514_SPI
+
+config SND_SOC_RT5514_I2C
+   tristate
 
 config SND_SOC_RT5514_SPI
tristate
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index b301bfff1c09..f5ef912190ed 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -259,7 +259,7 @@ config SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH
 select SND_SOC_INTEL_SST
 select SND_SOC_INTEL_SKYLAKE
 select SND_SOC_RT5663
-select SND_SOC_RT5514
+select SND_SOC_RT5514_I2C
 select SND_SOC_MAX98927
 select SND_SOC_HDAC_HDMI
 help
diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
index 5c68797f36c4..6ccf73ae77ca 100644
--- a/sound/soc/mediatek/Kconfig
+++ b/sound/soc/mediatek/Kconfig
@@ -67,7 +67,7 @@ config SND_SOC_MT8173_RT5650_RT5514
tristate "ASoC Audio driver for MT8173 with RT5650 RT5514 codecs"
depends on SND_SOC_MT8173 && I2C
select SND_SOC_RT5645
-   select SND_SOC_RT5514
+   select SND_SOC_RT5514_I2C
help
  This adds ASoC driver for Mediatek MT8173 boards
  with the RT5650 and RT5514 codecs.
diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index c84487805876..c1139aecdfbe 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -65,7 +65,6 @@ config SND_SOC_RK3399_GRU_SOUND
depends on SND_SOC_ROCKCHIP && I2C && GPIOLIB && CLKDEV_LOOKUP && SPI
select SND_SOC_ROCKCHIP_I2S
select SND_SOC_MAX98357A
-   select SND_SOC_RT5514
select SND_SOC_DA7219
select SND_SOC_RT5514_SPI
help
-- 
2.9.0

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Thomas Gleixner]

Rafael,

On Fri, 28 Jul 2017, Tomi Sarvela wrote:
>  rtcwake-1332  [000] d..164.42: suspend_device_irqs:
> presuspend 8 state 00401200
>  rtcwake-1332  [000] d..164.42: __irq_disable: predisable 8
> state 00401200
>  rtcwake-1332  [000] d..164.43: __irq_disable: postdisable 8
> state 00411200
>  rtcwake-1332  [000] d..164.44: suspend_device_irqs:
> postsuspend 8 state 00411200
>  rtcwake-1332  [000] d..164.45: suspend_device_irqs:
> presuspend 9 state 00403300
>  rtcwake-1332  [000] d..164.45: __irq_disable: predisable 9
> state 00403300
>  rtcwake-1332  [000] d..164.46: __irq_disable: postdisable 9
> state 00413300
>  rtcwake-1332  [000] d..164.46: suspend_device_irqs:
> postsuspend 9 state 00413300
>  rtcwake-1332  [000] d..164.47: suspend_device_irqs:

I'm trying to analyze that suspend/resume problem. While staring at the
trace Tomi provided I noticed, that neither the RTC irq nor the ACPI irq
have the wakeup armed bit set, but the system resumes from an RTC
interrupt. That's inconsistent at least, or am I missing something
essential?

Thanks,

tglx

Re: IRQ_ONESHOT expectations vs mask/unmask

[Benjamin Herrenschmidt]

On Mon, 2017-07-31 at 09:09 +0200, Thomas Gleixner wrote:
> Ben,
> 
> On Mon, 31 Jul 2017, Benjamin Herrenschmidt wrote:
> > I noticed a problem with some powerpc systems with threaded IRQs. I
> > hadn't looked at threaded irq in the past so there was a bit of
> > discovery involved. That lead to a few questions:
> > 
> >  - Threaded IRQs rely on IRQF_ONESHOT. Now, is that a flag/feature that
> > is generally exposed to drivers even in the non-threaded case, and if
> > yes, what core callback are drivers expected to use to "unmask" the
> > oneshot interrupt ?
> 
> The oneshot flag should not have any effects when the interrupt is
> non-threaded. Emphasis on should. I'm not sure whether that's true, will
> have a look.
> 
> >  - I don't see any provisions for dealing with interrupts lost while
> > masked. So on some PICs on powerpc, while we do use "fast EOI", we also
> > have a chance of edge interrupts (MSIs) being lost while masked. This
> > wasn't a problem until now because we used lazy disabling. However, it
> > looks like IRQF_ONESHOT (and thus threaded irqs) rely on masked
> > interrupts being latched in HW, otherwise an interrupt might be lost
> > between the threaded handler completing and the interrupt being
> > unmasked, or am I missing something ?
> > 
> >  - I noticed that other flow handlers (edge, edge_eoi, ...) don't have
> > any provision for IRQF_ONESHOT. Isn't that a problem ? Or will the core
> > silently swallow subsequent interrupts until the thread has completed
> > anyway ? (I might be missing something here).
> 
> The only case where IRQF_ONESHOT should have an effect is with level type
> interrupts. That's required, because otherwise the hardware interrupt would
> fire for ever. Level type interrupts should not need any hardware latching,
> we assume that they fire once they are unmasked.
> 
> For edge type interrupts we do not mask the interrupt in order not to lose
> an interrupt. If the interrupt fires while the thread handler is running,
> we mark the thread and once it the handler returns it gets called again.
> 
> > Generally, how do you suggest I fix the threaded irq problem for XICS ?
> 
> You asked a lot of questions, but you failed to explain the problem for
> XICS.

I did but maybe it wasn't clear :-)

"So on some PICs on powerpc, while we do use "fast EOI", we also> >
have a chance of edge interrupts (MSIs) being lost while masked."

Basically, a masked interrupt might get dropped rather than "latched",
so if we use the existing fasteoi handler with IRQF_ONESHOT, we'll
lose them if they occur at the wrong time.

I could use something like the edge_eoi flow handler instead I suppose
but that will *never* lazy disable which is somewhat unfortunate, very
fast paced MSIs benefit from being HW masked if we already recorded
that they occurred.

So what I would need is something along the line of ONESHOT as done in
fasteoi but only for level interrupts.

Cheers,
Ben.

> Thanks,
> 
>   tglx

Re: [PATCH 6/8] dmi: Move memdev_dmi_entry definition to dmi.h (v2)

[Jean Delvare]

Hi Matt, Mauro,

On Thu, 17 Mar 2016 15:18:20 +0100, Jean Delvare wrote:
> On Tue,  8 Mar 2016 10:32:37 -0800, Matt Roper wrote:
> > A couple of the EDAC drivers have a nice memdev_dmi_entry structure for
> > decoding DMI memory device entries.  Move the structure definition to
> > dmi.h so that it can be shared between those drivers and also other
> > parts of the kernel; the i915 graphics driver is going to need to use
> > this structure soon as well.  As part of this move we rename the
> > structure s/memdev_dmi_entry/dmi_entry_memdev/ to ensure it has a proper
> > 'dmi' prefix.
> > 
> > v2:
> >  - Rename structure to dmi_entry_memdev.  (Jean)
> >  - Use __packed instead of __attribute__((__packed__)) for consistency
> >with the rest of the dmi.h header.  (Jean)  
> 
> Looks better. (...)

What happened to this patch? I never received v3. Is it sill needed?

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] mm: don't zero ballooned pages

[Michal Hocko]

On Mon 31-07-17 16:23:26, ZhenweiPi wrote:
> On 07/31/2017 03:51 PM, Michal Hocko wrote:
> 
> >On Mon 31-07-17 15:41:49, Wei Wang wrote:
> >>>On 07/31/2017 02:55 PM, Michal Hocko wrote:
>  >On Mon 31-07-17 12:13:33, Wei Wang wrote:
> > >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and
> > >>shouldn't be given to the host ksmd to scan.
>  >Could you point me where this MADV_DONTNEED is done, please?
> >>>
> >>>Sure. It's done in the hypervisor when the balloon pages are received.
> >>>
> >>>Please see line 40 at
> >>>https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
> >And one more thing. I am not familiar with ksm much. But how is
> >MADV_DONTNEED even helping? This madvise is not sticky - aka it will
> >unmap the range without leaving any note behind. AFAICS the only way
> >to have vma scanned is to have VM_MERGEABLE and that is an opt in:
> >See Documentation/vm/ksm.txt
> >"
> >KSM only operates on those areas of address space which an application
> >has advised to be likely candidates for merging, by using the madvise(2)
> >system call: int madvise(addr, length, MADV_MERGEABLE).
> >"
> >
> >So what exactly is going on here? The original patch looks highly
> >suspicious as well. If somebody wants to make that memory mergable then
> >the user of that memory should zero them out.
> 
> Kernel starts a kthread named "ksmd". ksmd scans the VM_MERGEABLE
> memory, and merge the same pages.(same page means memcmp(page1,
> page2, PAGESIZE) == 0).
> 
> Guest can not use ballooned pages, and these pages will not be accessed
> in a long time. Kswapd on host will swap these pages out and get more
> free memory.
> 
> Rather than swapping, KSM has better performence.  Presently pages in
> the balloon device have random value,  they usually cannot be merged.
> So enqueue zero pages will resolve this problem.
> 
> Because MADV_DONTNEED depends on host os capability and hypervisor capability,
> I prefer to enqueue zero pages to balloon device and made this patch.

So why exactly are we zeroying pages (and pay some cost for that) in
guest when we do not know what host actually does with them?
-- 
Michal Hocko
SUSE Labs

Re: Udpated sys_membarrier() speedup patch, FYI

[Peter Zijlstra]

On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote:
> I remembered that current->mm does not change when switching to a kernel
> task, but my Kernlish is very rusty, or maybe it has changed.

kernel threads do indeed preserve the mm of the old userspace task, but
we track that in ->active_mm. Their ->mm will be NULL.

Re: [PATCH v3 2/5] [media]: rockchip/rga: v4l2 m2m support

[Hans Verkuil]

Hi Jacob,

A quick review below:

On 07/31/2017 05:07 AM, Jacob Chen wrote:
> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> accelerates 2D graphics operations, such as point/line drawing, image
> scaling, rotation, BitBLT, alpha blending and image blur/sharpness
> 
> The drvier is mostly based on s5p-g2d v4l2 m2m driver

drvier -> driver

> And supports various operations from the rendering pipeline.
>  - copy
>  - fast solid color fill
>  - rotation
>  - flip
>  - alpha blending

What other operations are supported by the HW but not (yet?) in this
driver?

> 
> The code in rga-hw.c is used to configure regs accroding to operations

accroding -> according

> The code in rga-buf.c is used to create (1-Level)mmu table for RGA
> The tables is stored in a list, and be removed when buffer is cleanup
> 
> Signed-off-by: Jacob Chen 
> ---
>  drivers/media/platform/Kconfig|  11 +
>  drivers/media/platform/Makefile   |   2 +
>  drivers/media/platform/rockchip-rga/Makefile  |   3 +
>  drivers/media/platform/rockchip-rga/rga-buf.c | 141 
>  drivers/media/platform/rockchip-rga/rga-hw.c  | 650 +
>  drivers/media/platform/rockchip-rga/rga-hw.h  | 437 
>  drivers/media/platform/rockchip-rga/rga.c | 987 
> ++
>  drivers/media/platform/rockchip-rga/rga.h | 110 +++
>  8 files changed, 2341 insertions(+)
>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c9106e1..8199bcf 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -411,6 +411,17 @@ config VIDEO_RENESAS_VSP1
> To compile this driver as a module, choose M here: the module
> will be called vsp1.
>  
> +config VIDEO_ROCKCHIP_RGA
> + tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> + depends on ARCH_ROCKCHIP || COMPILE_TEST
> + select VIDEOBUF2_DMA_SG
> + select V4L2_MEM2MEM_DEV
> + default n
> + ---help---
> +   This is a v4l2 driver for Rockchip SOC RGA2
> +   2d graphics accelerator.
> +
>  config VIDEO_TI_VPE
>   tristate "TI VPE (Video Processing Engine) driver"
>   depends on VIDEO_DEV && VIDEO_V4L2
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 349ddf6..3bf096f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -54,6 +54,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)+= rcar_fdp1.o
>  obj-$(CONFIG_VIDEO_RENESAS_JPU)  += rcar_jpu.o
>  obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
>  
> +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga/
> +
>  obj-y+= omap/
>  
>  obj-$(CONFIG_VIDEO_AM437X_VPFE)  += am437x/
> diff --git a/drivers/media/platform/rockchip-rga/Makefile 
> b/drivers/media/platform/rockchip-rga/Makefile
> new file mode 100644
> index 000..92fe254
> --- /dev/null
> +++ b/drivers/media/platform/rockchip-rga/Makefile
> @@ -0,0 +1,3 @@
> +rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
> +
> +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
> diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c 
> b/drivers/media/platform/rockchip-rga/rga-buf.c
> new file mode 100644
> index 000..b4d28e3
> --- /dev/null
> +++ b/drivers/media/platform/rockchip-rga/rga-buf.c
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd

I think the copyright statement should include a year.

> + * Author: Jacob Chen 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "rga-hw.h"
> +#include "rga.h"
> +
> +static int
> +rga_queue_setup(struct vb2_queue *vq,
> + unsigned int *nbuffers, unsigned int *nplanes,
> + unsigned int sizes[], struct device *alloc_devs[])
> +{
> + struct rga_ctx *ctx = vb2_get_drv_priv(vq);
> + struct rga_frame *f = rga_get_frame(ctx, vq->type);
> +
> + if (IS_ERR(f))
> + return PTR_ERR(f);
> +

Since you are supporting VIDIOC_CREATE_BUFS you need

[PATCH] ipc: optimize semget/shmget/msgget for lots of keys

[Guillaume Knispel]

ipc_findkey() scanned all objects to look for the wanted key. This is
slow when using a high number of keys, for example on an i5 laptop the
following loop took 17 s, with last semget calls taking ~1 ms each.

for (int i = 0, k=0x424242; i < 31900; ++i)
semget(k++, 1, IPC_CREAT | 0600);

This change adds an rhashtable of kern_ipc_perm objects in ipc_ids, so
that one lookup cease to be O(n). The above loop now takes ~10 ms. Each
lookup-only semget() call can take between ~120 ns and a few µs. Rarely,
some creations can take a few dozen of µs.

I also ran 'syscalls-ipc' and 'containers' of ltp 20170516, including
with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB,
CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK,
CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_DEBUG_OBJECTS_RCU_HEAD, and did
not detect any regression (compared to 4.13-rc2, running Ubuntu 16.04.2)
[I did not manage to enable CONFIG_PROVE_RCU]

Signed-off-by: Guillaume Knispel 
Reviewed-by: Marc Pardo 
---
 include/linux/ipc.h   |  3 ++
 include/linux/ipc_namespace.h |  3 ++
 ipc/msg.c | 10 +++--
 ipc/namespace.c   | 20 +++--
 ipc/sem.c | 11 +++--
 ipc/shm.c | 14 +++---
 ipc/util.c| 99 ---
 ipc/util.h| 21 +
 8 files changed, 130 insertions(+), 51 deletions(-)

diff --git a/include/linux/ipc.h b/include/linux/ipc.h
index fadd579..f480f22 100644
--- a/include/linux/ipc.h
+++ b/include/linux/ipc.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #define IPCMNI 32768  /* <= MAX_INT limit for ipc arrays (including sysctl 
changes) */
@@ -21,6 +22,8 @@ struct kern_ipc_perm {
unsigned long   seq;
void*security;
 
+   struct rhash_head khtnode;
+
struct rcu_head rcu;
atomic_t refcount;
 } cacheline_aligned_in_smp __randomize_layout;
diff --git a/include/linux/ipc_namespace.h b/include/linux/ipc_namespace.h
index 65327ee..aea3b81 100644
--- a/include/linux/ipc_namespace.h
+++ b/include/linux/ipc_namespace.h
@@ -7,15 +7,18 @@
 #include 
 #include 
 #include 
+#include 
 
 struct user_namespace;
 
 struct ipc_ids {
int in_use;
unsigned short seq;
+   bool tables_initialized;
struct rw_semaphore rwsem;
struct idr ipcs_idr;
int next_id;
+   struct rhashtable key_ht;
 };
 
 struct ipc_namespace {
diff --git a/ipc/msg.c b/ipc/msg.c
index 5b25e07..f123042 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -1011,7 +1011,7 @@ SYSCALL_DEFINE5(msgrcv, int, msqid, struct msgbuf __user 
*, msgp, size_t, msgsz,
 }
 
 
-void msg_init_ns(struct ipc_namespace *ns)
+int msg_init_ns(struct ipc_namespace *ns)
 {
ns->msg_ctlmax = MSGMAX;
ns->msg_ctlmnb = MSGMNB;
@@ -1019,7 +1019,7 @@ void msg_init_ns(struct ipc_namespace *ns)
 
atomic_set(&ns->msg_bytes, 0);
atomic_set(&ns->msg_hdrs, 0);
-   ipc_init_ids(&ns->ids[IPC_MSG_IDS]);
+   return ipc_init_ids(&ns->ids[IPC_MSG_IDS]);
 }
 
 #ifdef CONFIG_IPC_NS
@@ -1027,6 +1027,7 @@ void msg_exit_ns(struct ipc_namespace *ns)
 {
free_ipcs(ns, &msg_ids(ns), freeque);
idr_destroy(&ns->ids[IPC_MSG_IDS].ipcs_idr);
+   rhashtable_destroy(&ns->ids[IPC_MSG_IDS].key_ht);
 }
 #endif
 
@@ -1057,11 +1058,12 @@ static int sysvipc_msg_proc_show(struct seq_file *s, 
void *it)
 }
 #endif
 
-void __init msg_init(void)
+int __init msg_init(void)
 {
-   msg_init_ns(&init_ipc_ns);
+   const int err = msg_init_ns(&init_ipc_ns);
 
ipc_init_proc_interface("sysvipc/msg",
"   key  msqid perms  cbytes   
qnum lspid lrpid   uid   gid  cuid  cgid  stime  rtime  ctime\n",
IPC_MSG_IDS, sysvipc_msg_proc_show);
+   return err;
 }
diff --git a/ipc/namespace.c b/ipc/namespace.c
index b4d80f9..4130f48 100644
--- a/ipc/namespace.c
+++ b/ipc/namespace.c
@@ -54,16 +54,28 @@ static struct ipc_namespace *create_ipc_ns(struct 
user_namespace *user_ns,
ns->user_ns = get_user_ns(user_ns);
ns->ucounts = ucounts;
 
-   err = mq_init_ns(ns);
+   err = sem_init_ns(ns);
if (err)
goto fail_put;
+   err = msg_init_ns(ns);
+   if (err)
+   goto fail_destroy_sem;
+   err = shm_init_ns(ns);
+   if (err)
+   goto fail_destroy_msg;
 
-   sem_init_ns(ns);
-   msg_init_ns(ns);
-   shm_init_ns(ns);
+   err = mq_init_ns(ns);
+   if (err)
+   goto fail_destroy_shm;
 
return ns;
 
+fail_destroy_shm:
+   shm_exit_ns(ns);
+fail_destroy_msg:
+   msg_exit_ns(ns);
+fail_destroy_sem:
+   sem_exit_ns(ns);
 fail_put:
put_user_ns(ns->user_ns);
ns_free_inum(&ns->ns);
diff --git a/ipc/sem.c b/ipc/sem.c
index 9e70cd7..b13ecfd 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -185,14 +18

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Tomi Sarvela]

On 31/07/17 11:29, Thomas Gleixner wrote:

On Mon, 31 Jul 2017, Tomi Sarvela wrote:

On 31/07/17 10:45, Thomas Gleixner wrote:

On Mon, 31 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 19:26, Thomas Gleixner wrote:

Did you change anything else compared to the tests before ?


I did check that the problem persisted in linus-HEAD before testing your
patch. The testing was done in order (reading from console logs I happen
to
still have in one window):


What I still do not understand is why this would affect the suspend path in
any way.

Can you remove the previous patch and apply the one below. If it resumes,
please provide the data from the trace buffer again.


No such luck. ELK hangs in the suspend-test with earlier patch removed, this
added. Checked again that the power-led is on, no serial output.

Tree not pulled: still testing against the previous head -rc2, not current
4.13.0-rc3


Shouldn't make a difference. Can you please try the following:

Offline CPU1 before invoking suspend.

# echo 0 >/sys/devices/system/cpus/cpu1/offline


Tested with your latest patch (irq_trace_state):

echo 0 >/sys/devices/system/cpu/cpu1/online

./scripts/run-tests.sh -vt igt@gem_exec_suspend@basic-s3 -x devices

No change, no wakey at all.

Tomi
--
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

Re: [RFC PATCH v2 28/38] KVM: arm64: Emulate EL12 register accesses from the virtual EL2

[Christoffer Dall]

On Tue, Jul 18, 2017 at 11:58:54AM -0500, Jintack Lim wrote:
> With HCR_EL2.NV bit set, accesses to EL12 registers in the virtual EL2
> trap to EL2. Handle those traps just like we do for EL1 registers.
> 
> One exception is CNTKCTL_EL12. We don't trap on CNTKCTL_EL1 for non-VHE
> virtual EL2 because we don't have to. However, accessing CNTKCTL_EL12
> will trap since it's one of the EL12 registers controlled by HCR_EL2.NV
> bit.  Therefore, add a handler for it and don't treat it as a
> non-trap-registers when preparing a shadow context.

I'm sorry, I don't remember the details, and I don't understand from
this paragraph what the difference between CNTKCTL_EL12 and the other
EL12 registers is?

> 
> Move EL12 system register macros to a common place to reuse them.
> 
> Signed-off-by: Jintack Lim 
> ---
>  arch/arm64/include/asm/kvm_hyp.h | 24 
>  arch/arm64/include/asm/sysreg.h  | 24 
>  arch/arm64/kvm/context.c |  7 +++
>  arch/arm64/kvm/sys_regs.c| 25 +
>  4 files changed, 56 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_hyp.h 
> b/arch/arm64/include/asm/kvm_hyp.h
> index 4572a9b..353b895 100644
> --- a/arch/arm64/include/asm/kvm_hyp.h
> +++ b/arch/arm64/include/asm/kvm_hyp.h
> @@ -73,30 +73,6 @@
>  #define read_sysreg_el1(r)   read_sysreg_elx(r, _EL1, _EL12)
>  #define write_sysreg_el1(v,r)write_sysreg_elx(v, r, _EL1, _EL12)
>  
> -/* The VHE specific system registers and their encoding */
> -#define sctlr_EL12  sys_reg(3, 5, 1, 0, 0)
> -#define cpacr_EL12  sys_reg(3, 5, 1, 0, 2)
> -#define ttbr0_EL12  sys_reg(3, 5, 2, 0, 0)
> -#define ttbr1_EL12  sys_reg(3, 5, 2, 0, 1)
> -#define tcr_EL12sys_reg(3, 5, 2, 0, 2)
> -#define afsr0_EL12  sys_reg(3, 5, 5, 1, 0)
> -#define afsr1_EL12  sys_reg(3, 5, 5, 1, 1)
> -#define esr_EL12sys_reg(3, 5, 5, 2, 0)
> -#define far_EL12sys_reg(3, 5, 6, 0, 0)
> -#define mair_EL12   sys_reg(3, 5, 10, 2, 0)
> -#define amair_EL12  sys_reg(3, 5, 10, 3, 0)
> -#define vbar_EL12   sys_reg(3, 5, 12, 0, 0)
> -#define contextidr_EL12 sys_reg(3, 5, 13, 0, 1)
> -#define cntkctl_EL12sys_reg(3, 5, 14, 1, 0)
> -#define cntp_tval_EL02  sys_reg(3, 5, 14, 2, 0)
> -#define cntp_ctl_EL02   sys_reg(3, 5, 14, 2, 1)
> -#define cntp_cval_EL02  sys_reg(3, 5, 14, 2, 2)
> -#define cntv_tval_EL02  sys_reg(3, 5, 14, 3, 0)
> -#define cntv_ctl_EL02   sys_reg(3, 5, 14, 3, 1)
> -#define cntv_cval_EL02  sys_reg(3, 5, 14, 3, 2)
> -#define spsr_EL12   sys_reg(3, 5, 4, 0, 0)
> -#define elr_EL12sys_reg(3, 5, 4, 0, 1)
> -
>  /**
>   * hyp_alternate_select - Generates patchable code sequences that are
>   * used to switch between two implementations of a function, depending
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index b01c608..b8d4d0c 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -338,6 +338,30 @@
>  #define SYS_CNTVOFF_EL2  sys_reg(3, 4, 14, 0, 3)
>  #define SYS_CNTHCTL_EL2  sys_reg(3, 4, 14, 1, 0)
>  
> +/* The VHE specific system registers and their encoding */
> +#define sctlr_EL12  sys_reg(3, 5, 1, 0, 0)
> +#define cpacr_EL12  sys_reg(3, 5, 1, 0, 2)
> +#define ttbr0_EL12  sys_reg(3, 5, 2, 0, 0)
> +#define ttbr1_EL12  sys_reg(3, 5, 2, 0, 1)
> +#define tcr_EL12sys_reg(3, 5, 2, 0, 2)
> +#define afsr0_EL12  sys_reg(3, 5, 5, 1, 0)
> +#define afsr1_EL12  sys_reg(3, 5, 5, 1, 1)
> +#define esr_EL12sys_reg(3, 5, 5, 2, 0)
> +#define far_EL12sys_reg(3, 5, 6, 0, 0)
> +#define mair_EL12   sys_reg(3, 5, 10, 2, 0)
> +#define amair_EL12  sys_reg(3, 5, 10, 3, 0)
> +#define vbar_EL12   sys_reg(3, 5, 12, 0, 0)
> +#define contextidr_EL12 sys_reg(3, 5, 13, 0, 1)
> +#define cntkctl_EL12sys_reg(3, 5, 14, 1, 0)
> +#define cntp_tval_EL02  sys_reg(3, 5, 14, 2, 0)
> +#define cntp_ctl_EL02   sys_reg(3, 5, 14, 2, 1)
> +#define cntp_cval_EL02  sys_reg(3, 5, 14, 2, 2)
> +#define cntv_tval_EL02  sys_reg(3, 5, 14, 3, 0)
> +#define cntv_ctl_EL02   sys_reg(3, 5, 14, 3, 1)
> +#define cntv_cval_EL02  sys_reg(3, 5, 14, 3, 2)
> +#define spsr_EL12   sys_reg(3, 5, 4, 0, 0)
> +#define elr_EL12sys_reg(3, 5, 4, 0, 1)
> +
>  #define SYS_SP_EL2   sys_reg(3, 6, 4, 1, 0)
>  
>  /* Common SCTLR_ELx flags. */
> diff --git a/arch/arm64/kvm/context.c b/arch/arm64/kvm/context.c
> index e1bc753..f3d3398 100644
> --- a/arch/arm64/kvm/context.c
> +++ b/arch/arm64/kvm/context.c
> @@ -121,6 +121,13 @@ sta

Re: IRQ_ONESHOT expectations vs mask/unmask

[Thomas Gleixner]

On Mon, 31 Jul 2017, Benjamin Herrenschmidt wrote:
> On Mon, 2017-07-31 at 09:09 +0200, Thomas Gleixner wrote:
> > You asked a lot of questions, but you failed to explain the problem for
> > XICS.
> 
> I did but maybe it wasn't clear :-)
> 
> "So on some PICs on powerpc, while we do use "fast EOI", we also> >
> have a chance of edge interrupts (MSIs) being lost while masked."
> 
> Basically, a masked interrupt might get dropped rather than "latched",
> so if we use the existing fasteoi handler with IRQF_ONESHOT, we'll
> lose them if they occur at the wrong time.
> 
> I could use something like the edge_eoi flow handler instead I suppose
> but that will *never* lazy disable which is somewhat unfortunate, very
> fast paced MSIs benefit from being HW masked if we already recorded
> that they occurred.
> 
> So what I would need is something along the line of ONESHOT as done in
> fasteoi but only for level interrupts.

If that MSI interrupt is using a separate interrupt chip, then the solution
is simple. You just have to add IRQCHIP_ONESHOT_SAFE to chip.flags

Thanks,

tglx

Re: [PATCH] Staging: vc04_services: Fix WARN_ON instead of BUG_ON

[Dan Carpenter]

On Mon, Jul 31, 2017 at 12:44:03PM +0530, janani-sankarababu wrote:
> This patch is to replace the use of BUG_ON macro with WARN_ON
> inorder to prevent the crashing of the kernel.
> 
> Signed-off-by: Janani Sankara Babu 
> ---
>  drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
> b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
> index f484bb0..30bc246 100644
> --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
> +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
> @@ -91,7 +91,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol 
> *kcontrol,
>   if (mutex_lock_interruptible(&chip->audio_mutex))
  ^^
We dereference chip here.

>   return -EINTR;
>  
> - BUG_ON(!chip && !(chip->avail_substreams & AVAIL_SUBSTREAMS_MASK));
> + WARN_ON(!chip && !(chip->avail_substreams & AVAIL_SUBSTREAMS_MASK));
^
Too late.

regards,
dan carpenter

[v4] wlcore: add missing nvs file name info for wilink8

[Reizer, Eyal]

The following commits:
c815fde wlcore: spi: Populate config firmware data
d776fc8 wlcore: sdio: Populate config firmware data

Populated the nvs entry for wilink6 and wilink7 only while it is
still needed for wilink8 as well.
This broke user space backward compatibility when upgrading from older
kernels, as the alternate mac address would not be read from the nvs that
is present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
causing mac address change of the wlan interface.

This patch fix this and update the structure field with the same default
nvs file name that has been used before.

In addition, some distros hold a default wl1271-nvs.bin in the file
system with a bogus mac address (deadbeef...) that for a wl18xx device
also overrides the mac address that is stored inside the device.
Warn users about this bogus mac address and use a random mac instead

Cc: stable 
Signed-off-by: Eyal Reizer 
---
v2->v3: add a check for default deadbeef... mac address and warn about it
v3->v4: use a random TI mac address instead of the bogus one

---
 drivers/net/wireless/ti/wlcore/main.c | 16 
 drivers/net/wireless/ti/wlcore/sdio.c |  1 +
 drivers/net/wireless/ti/wlcore/spi.c  |  1 +
 3 files changed, 18 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 60aaa85..7ce4221 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5961,6 +5961,22 @@ static void wl12xx_derive_mac_addresses(struct wl1271 
*wl, u32 oui, u32 nic)
if (nic + WLCORE_NUM_MAC_ADDRESSES - wl->num_mac_addr > 0xff)
wl1271_warning("NIC part of the MAC address wraps around!");
 
+   if (oui == 0xdeadbe && nic == 0xef) {
+   wl1271_warning("Detected unconfigured mac address in nvs.\n"
+   "Using a random TI mac address instead.\n"
+   "in case of using a wl12xx device, your "
+   "device performance may not be optimized.\n"
+   "Please use the calibrator tool to configure "
+   "your device.\n"
+   "When using a wl18xx device the nvs file can "
+   "be removed as a default mac address is "
+   "stored internally.\n");
+
+   /* Use TI oui and a random nic */
+   oui = 0x080028;
+   nic = get_random_int();
+   }
+
for (i = 0; i < wl->num_mac_addr; i++) {
wl->addresses[i].addr[0] = (u8)(oui >> 16);
wl->addresses[i].addr[1] = (u8)(oui >> 8);
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 2fb3871..f8a1fea 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -230,6 +230,7 @@ static const struct wilink_family_data wl128x_data = {
 static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
.cfg_name = "ti-connectivity/wl18xx-conf.bin",
+   .nvs_name = "ti-connectivity/wl1271-nvs.bin",
 };
 
 static const struct of_device_id wlcore_sdio_of_match_table[] = {
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index fdabb92..62ce54a 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -92,6 +92,7 @@ static const struct wilink_family_data wl128x_data = {
 static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
.cfg_name = "ti-connectivity/wl18xx-conf.bin",
+   .nvs_name = "ti-connectivity/wl1271-nvs.bin",
 };
 
 struct wl12xx_spi_glue {
-- 
2.7.4

[PATCH 1/2] x86/amd: Limit cpu_core_id fixup to families older than F17h

[Borislav Petkov]

From: Suravee Suthikulpanit 

Current cpu_core_id fixup causes downcored F17h configurations to be
incorrect:

  NODE: 0
  processor  0 core id : 0
  processor  1 core id : 1
  processor  2 core id : 2
  processor  3 core id : 4
  processor  4 core id : 5
  processor  5 core id : 0

  NODE: 1
  processor  6 core id : 2
  processor  7 core id : 3
  processor  8 core id : 4
  processor  9 core id : 0
  processor 10 core id : 1
  processor 11 core id : 2

Code that relies on the cpu_core_id, like match_smt(), for example,
which builds the thread siblings masks used by the scheduler, is
mislead.

So, limit the fixup to pre-F17h machines. The new value for cpu_core_id
for F17h and later will represent the CPUID_Fn801E_EBX[CoreId],
which is guaranteed to be unique for each core within a socket.

This way we have:

  NODE: 0
  processor  0 core id : 0
  processor  1 core id : 1
  processor  2 core id : 2
  processor  3 core id : 4
  processor  4 core id : 5
  processor  5 core id : 6

  NODE: 1
  processor  6 core id : 8
  processor  7 core id : 9
  processor  8 core id : 10
  processor  9 core id : 12
  processor 10 core id : 13
  processor 11 core id : 14

Signed-off-by: Suravee Suthikulpanit 
Cc: Yazen Ghannam 
Cc: x86-ml 
Link: 
http://lkml.kernel.org/r/1501009980-2273-1-git-send-email-suravee.suthikulpa...@amd.com
[ Heavily massaged. ]
Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/amd.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 110ca5d2bb87..aa3cf163fd19 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -297,6 +297,22 @@ static int nearby_node(int apicid)
 }
 #endif
 
+/*
+ * Fix up cpu_core_id for pre-F17h systems to be in the
+ * [0 .. cores_per_node - 1] range. Not really needed but
+ * kept so as not to break existing setups.
+ */
+static void legacy_fixup_core_id(struct cpuinfo_x86 *c)
+{
+   u32 cus_per_node;
+
+   if (c->x86 >= 0x17)
+   return;
+
+   cus_per_node = c->x86_max_cores / nodes_per_socket;
+   c->cpu_core_id %= cus_per_node;
+}
+
 /*
  * Fixup core topology information for
  * (1) AMD multi-node processors
@@ -354,15 +370,9 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
} else
return;
 
-   /* fixup multi-node processor information */
if (nodes_per_socket > 1) {
-   u32 cus_per_node;
-
set_cpu_cap(c, X86_FEATURE_AMD_DCM);
-   cus_per_node = c->x86_max_cores / nodes_per_socket;
-
-   /* core id has to be in the [0 .. cores_per_node - 1] range */
-   c->cpu_core_id %= cus_per_node;
+   legacy_fixup_core_id(c);
}
 }
 #endif
-- 
2.14.0.rc0

Re: [PATCH 00/12] constify mmc_host_ops structures

[Ulf Hansson]

On 29 July 2017 at 07:59, Julia Lawall  wrote:
>
> The mmc_host_ops structure is only stored in the ops field of an
> mmc_host structure, which is declared as const.  Thus the mmc_host_ops
> structure itself can be const.
>
> Done with the help of Coccinelle.
>
> ---
>
>  drivers/mmc/host/bcm2835.c |2 +-
>  drivers/mmc/host/davinci_mmc.c |2 +-
>  drivers/mmc/host/moxart-mmc.c  |2 +-
>  drivers/mmc/host/mtk-sd.c  |2 +-
>  drivers/mmc/host/s3cmci.c  |2 +-
>  drivers/mmc/host/sdricoh_cs.c  |2 +-
>  drivers/mmc/host/sh_mmcif.c|2 +-
>  drivers/mmc/host/sunxi-mmc.c   |2 +-
>  drivers/mmc/host/toshsd.c  |2 +-
>  drivers/mmc/host/usdhi6rol0.c  |2 +-
>  drivers/mmc/host/vub300.c  |2 +-
>  drivers/mmc/host/wmt-sdmmc.c   |2 +-
>  12 files changed, 12 insertions(+), 12 deletions(-)


Thanks, applied for next!

Kind regards
Uffe

[PATCH 0/2] x86/amd: Two fixes for downcored machines

[Borislav Petkov]

From: Borislav Petkov 

Hi guys,

here are two fixes for downcored F17h machines. The respective commit
messages explain the situation adequately, IMO. Both tip:x86/cpu stuff.

Please queue,
thanks.

Suravee Suthikulpanit (2):
  x86/amd: Limit cpu_core_id fixup to families older than F17h
  x86/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask

 arch/x86/kernel/cpu/amd.c | 24 +---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 32 ++--
 2 files changed, 35 insertions(+), 21 deletions(-)

-- 
2.14.0.rc0

[PATCH 2/2] x86/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask

[Borislav Petkov]

From: Suravee Suthikulpanit 

For systems with X86_FEATURE_TOPOEXT, current logic uses the APIC ID
to calculate shared_cpu_map. However, APIC IDs are not guaranteed to
be contiguous for cores across different L3s (e.g. family17h system
w/ downcore configuration). This breaks the logic, and results in an
incorrect L3 shared_cpu_map.

Instead, always use the previously calculated cpu_llc_shared_mask of
each CPU to derive the L3 shared_cpu_map.

Signed-off-by: Suravee Suthikulpanit 
Cc: x86-ml 
Link: 
http://lkml.kernel.org/r/1501206755-2396-1-git-send-email-suravee.suthikulpa...@amd.com
Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index c55fb2cb2acc..24f749324c0f 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -811,7 +811,24 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, int 
index,
struct cacheinfo *this_leaf;
int i, sibling;
 
-   if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
+   /*
+* For L3, always use the pre-calculated cpu_llc_shared_mask
+* to derive shared_cpu_map.
+*/
+   if (index == 3) {
+   for_each_cpu(i, cpu_llc_shared_mask(cpu)) {
+   this_cpu_ci = get_cpu_cacheinfo(i);
+   if (!this_cpu_ci->info_list)
+   continue;
+   this_leaf = this_cpu_ci->info_list + index;
+   for_each_cpu(sibling, cpu_llc_shared_mask(cpu)) {
+   if (!cpu_online(sibling))
+   continue;
+   cpumask_set_cpu(sibling,
+   &this_leaf->shared_cpu_map);
+   }
+   }
+   } else if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
unsigned int apicid, nshared, first, last;
 
this_leaf = this_cpu_ci->info_list + index;
@@ -839,19 +856,6 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, int 
index,
&this_leaf->shared_cpu_map);
}
}
-   } else if (index == 3) {
-   for_each_cpu(i, cpu_llc_shared_mask(cpu)) {
-   this_cpu_ci = get_cpu_cacheinfo(i);
-   if (!this_cpu_ci->info_list)
-   continue;
-   this_leaf = this_cpu_ci->info_list + index;
-   for_each_cpu(sibling, cpu_llc_shared_mask(cpu)) {
-   if (!cpu_online(sibling))
-   continue;
-   cpumask_set_cpu(sibling,
-   &this_leaf->shared_cpu_map);
-   }
-   }
} else
return 0;
 
-- 
2.14.0.rc0

Re: [PATCH 00/29] constify scsi pci_device_id.

[Arvind Yadav]

On Monday 31 July 2017 01:26 PM, Johannes Thumshirn wrote:

On Sun, Jul 30, 2017 at 02:07:09PM +0530, Arvind Yadav wrote:

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

Can't this go all in one patch instead of replicating the same patch 29
times?

Yes, We can add all of them in single patch. But other maintainer wants
single single patch. thats why I have send 29 patch. :(

Thanks,
Johannes


~arvind

Re: Udpated sys_membarrier() speedup patch, FYI

[Avi Kivity]

On 07/31/2017 11:37 AM, Peter Zijlstra wrote:

On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote:

I remembered that current->mm does not change when switching to a kernel
task, but my Kernlish is very rusty, or maybe it has changed.

kernel threads do indeed preserve the mm of the old userspace task, but
we track that in ->active_mm. Their ->mm will be NULL.


Gah, I'm so rusty, if I were any rustier I'd be doing bitcoin.

Re: [PATCH 0/4] ACPI: DMA ranges management

[Lorenzo Pieralisi]

On Fri, Jul 28, 2017 at 04:55:36PM +0100, Robin Murphy wrote:
> On 28/07/17 15:09, Lorenzo Pieralisi wrote:
> > On Fri, Jul 28, 2017 at 02:08:01PM +0100, Robin Murphy wrote:
> > 
> > [...]
> > 
> > To ensure that dma_set_mask() and friends actually respect _DMA, would
> > you consider introducing a dma_supported() callback to check the input
> > dma_mask against the FW defined limits? This would end up aggressively
> > clipping the dma_mask to 32-bits for devices like the above if the _DMA
> > limit was less than 64-bits, but that is probably preferable to the
> > controller accessing unintended addresses.
> >
> > Also, how would you feel about adding support for the IORT named_node
> > memory_address_limit field?
> 
>  We will certainly need that for some platform devices, so if you fancy
>  giving it a go before Lorenzo or I get there, feel free!
> >>>
> >>> I can do it for v2 but I would like to understand why using _DMA is
> >>> not good enough for named components - having two bindings describing
> >>> the same thing is not ideal and I'd rather avoid it - if there is
> >>> a reason I am happy to add the necessary code.
> >>
> >> My interpretation of "_DMA is only defined under devices that represent
> >> buses." (ACPI 6.0, section 6.2.4) is that "devices that represent buses"
> >> are those that have other device objects as children.
> > 
> > Well if that was the case we would not be able to use _DMA for
> > eg PNP0A03 PCI host bridges that have no child ACPI devices, which
> > defeats the whole purpose of what I am doing.
> > 
> > The question here is what the _DMA object binding exactly means when
> > it refers to a "bus" and that's something I will figure out (and possibly
> > change) ASAP.
> > 
> >> In other words (excuse my novice pseudo-ASL), this would be valid:
> >>
> >> Scope(_SB)
> >> {
> >>Device (Bus)
> >>{
> >>...
> >>Method (_DMA ... )
> >>Device (Dev1)
> >>{
> >>...
> >>}
> >>}
> >> }
> >>
> >> but this should be invalid:
> >>
> >> Scope(_SB)
> >> {
> >>Device (Dev2)
> >>{
> >>...
> >>Method (_DMA ... )
> >>}
> >> }
> > 
> > Not sure about that (see above) and I agree that's what needs
> > clarification.
> > 
> >> Thus in the case where Dev2 is wired directly to an SMMU input, but
> >> fewer address bits are wired up between the two than both the device and
> >> SMMU interfaces are capable of, memory address limit is enough to
> >> describe that without having to insert a fake "bus" object above it just
> >> to hold the _DMA method.
> > 
> > BTW, how would you describe that in DT ? A "dma-ranges" property in the
> > device DT node right ? Arguably "dma-ranges" was not meant to be used
> > like that either ;-)
> 
> I believe that in real Open Firmware, the full PCI hierarchy is
> described in the device tree - I had assumed that ACPI expected the
> equivalent (i.e. the firmware probes PCI and assigns resources, so
> bridges/endpoints/etc. would be represented in the namespace with
> appropriate _CRS), thus the "bus with invisible children" case would
> only need to apply to DT. In terms of DTspec, it does not say that
> "dma-ranges" cannot be present on nodes without children, but that *is*
> implied of #address-cells and #size cells, so there does exist a similar
> ambiguity about what exactly counts as "a memory-mapped bus whose
> devicetree parent can be accessed from DMA operations originating from
> the bus". Certainly in the current Linux code, of_dma_configure()
> *doesn't* parse "dma-ranges" on leaf nodes (which is an open problem for
> some PCI host bridges in extant FDTs).
> 
> As for the case of straightforward interconnect widths/offsets (rather
> than potentially arbitrary windows), the 'fake bus' notion is already
> alive and well:
> 
> $ git grep 'soc {' arch/arm*/boot/dts
> 
> and the current "dma-ranges" users thankfully have consistent-enough
> topologies that they don't need to get much crazier than that.
> 
> (side note: up at the other end, I'm not entirely convinced that what I
> did for Juno is actually legal either)
> 
> > Long and short of it is: I do not like having two ways of describing
> > the same thing. I agree that the _DMA object usage requires
> > clarifications from a spec point of view but I want to do that before
> > plugging in code that may use bindings inconsistently.
> 
> I'd still argue that they are describing different things, just that one
> (the number of address bits wired up between a device and an SMMU)
> happens to be possible to describe as a subset of the other (an
> arbitrary mapping between two address spaces). The use-cases don't
> entirely overlap either - the information in _DMA is also likely to be
> wanted by non-ECAM PCI host controller drivers to configure their
> inbound windows, irrespective of anything to do with IOMMUs, whereas
> IORT code in hypervis

[PATCH] psci: add CPU_IDLE dependency

[Arnd Bergmann]

I ran into a build error for the psci_checker:

drivers/firmware/psci_checker.o: In function `psci_checker':
psci_checker.c:(.init.text+0x528): undefined reference to `cpuidle_devices'

As far as I can tell, this is simply a very rare combination of options,
but the problem has existed since the code was initially added.
Adding a Kconfig dependency makes it build properly.

Fixes: ea8b1c4a6019 ("drivers: psci: PSCI checker module")
Signed-off-by: Arnd Bergmann 
---
 drivers/firmware/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 6e4ed5a9c6fd..1983e6e0106f 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -10,7 +10,7 @@ config ARM_PSCI_FW
 
 config ARM_PSCI_CHECKER
bool "ARM PSCI checker"
-   depends on ARM_PSCI_FW && HOTPLUG_CPU && !TORTURE_TEST
+   depends on ARM_PSCI_FW && HOTPLUG_CPU && CPU_IDLE && !TORTURE_TEST
help
  Run the PSCI checker during startup. This checks that hotplug and
  suspend operations work correctly when using PSCI.
-- 
2.9.0

[PATCH] staging: pi433: reduce stack size in tx thread

[Arnd Bergmann]

Putting a 900 byte array on the stack is a clearly too much in the
kernel, and sometimes results in warnings like:

drivers/staging/pi433/pi433_if.c: In function 'pi433_tx_thread':
drivers/staging/pi433/pi433_if.c:645:1: error: the frame size of 1028 bytes is 
larger than 1024 bytes [-Werror=frame-larger-than=]

This moves the buffer into the dynamically allocated per-device
structure.

Signed-off-by: Arnd Bergmann 
---
 drivers/staging/pi433/pi433_if.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index ed737f4b1e77..ec9811ae4735 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -92,6 +92,7 @@ struct pi433_device {
struct task_struct  *tx_task_struct;
wait_queue_head_t   tx_wait_queue;
u8  free_in_fifo;
+   charbuffer[MAX_MSG_SIZE];
 
/* rx related values */
struct pi433_rx_cfg rx_cfg;
@@ -471,7 +472,7 @@ pi433_tx_thread(void *data)
struct pi433_device *device = data;
struct spi_device *spi = device->spi; /* needed for SET_CHECKED */
struct pi433_tx_cfg tx_cfg;
-   u8 buffer[MAX_MSG_SIZE];
+   u8 *buffer = device->buffer;
size_t size;
bool   rx_interrupted = false;
intposition, repetitions;
-- 
2.9.0

Re: [PATCH v4 00/06] clocksource: sh_cmt: DT binding rework V4

[Daniel Lezcano]

On 11/07/2017 13:56, Simon Horman wrote:
> On Thu, Nov 24, 2016 at 11:58:43AM +0100, Simon Horman wrote:
>> Hi Magnus,
>>
>> On Mon, Mar 14, 2016 at 11:23:42PM +0900, Magnus Damm wrote:
>>> clocksource: sh_cmt: DT binding rework V4
>>>
>>> [PATCH v4 01/06] devicetree: bindings: Remove sh7372 CMT binding
>>> [PATCH v4 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
>>> [PATCH v4 03/06] devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings
>>> [PATCH v4 04/06] devicetree: bindings: Deprecate property, update example
>>> [PATCH v4 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings
>>> [PATCH v4 06/06] devicetree: bindings: Remove deprecated properties
>>>
>>> Here is the latest and hopefully final take on updating the CMT DT
>>> bindings for R-Car Gen2. In total there are 6 patches that have acks
>>> and are ready to be picked up and merged. Other earlier posted changes
>>> such as driver modification and SoC DTS bits depend on this series.
>>
>> I am wondering what the state of this work is.
>> I see only one minor review comment for this series.
>> It would be great to see it merged.
> 
> Ping

Up.



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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [RFC PATCH v2 29/38] KVM: arm64: Support a VM with VHE considering EL0 of the VHE host

[Christoffer Dall]

On Tue, Jul 18, 2017 at 11:58:55AM -0500, Jintack Lim wrote:

nit: The subject is a little hard to understand.

> On VHE systems, EL0 of the host kernel is considered as a part of 'VHE
> host'; The execution of EL0 is affected by system registers set by the
> VHE kernel including the hypervisor. To emulate this for a VM, we use
> the same set of system registers (i.e. shadow registers) for the virtual
> EL2 and EL0 execution.

when the VM sets HCR_EL2.TGE and HCR_EL2.E2H.

> 
> Note that the assumption so far is that a hypervisor in a VM always runs
> in the virtual EL2, and the exception level change from/to the virtual
> EL2 always goes through the host hypervisor. With VHE support for a VM,
> however, the exception level can be changed from EL0 to virtual EL2
> without trapping to the host hypervisor. So, when returning from the VHE
> host mode, set the vcpu mode depending on the physical exception level.

I think there are two changes in this patch which aren't described
properly in the commit message.

First, on entry to a VM that runs in hypervisor context, virtual EL2 or
EL0 with virtual TGE+E2H, we have to either set the physical CPU mode
to EL1 or EL0, for the two cases respectively, where before we would
only ever run in virtual EL2 and would always choose EL1.

Second, on exit from a VM that runs in hypervisor context, virtual EL2 or
EL0 with virtual TGE+E2H, we can no longer assume that we run in virtual
El2, but must consider the hardware state to understand if the exception
from the VM happened from virtual EL2 or from EL0 in the guest
hypervisor's context.

Maybe that helps.

> 
> Signed-off-by: Jintack Lim 
> ---
>  arch/arm64/kvm/context.c | 36 ++--
>  1 file changed, 22 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm64/kvm/context.c b/arch/arm64/kvm/context.c
> index f3d3398..39bd92d 100644
> --- a/arch/arm64/kvm/context.c
> +++ b/arch/arm64/kvm/context.c
> @@ -150,16 +150,18 @@ static void flush_shadow_special_regs(struct kvm_vcpu 
> *vcpu)
>   struct kvm_cpu_context *ctxt = &vcpu->arch.ctxt;
>  
>   ctxt->hw_pstate = *vcpu_cpsr(vcpu) & ~PSR_MODE_MASK;
> - /*
> -  * We can emulate the guest's configuration of which
> -  * stack pointer to use when executing in virtual EL2 by
> -  * using the equivalent feature in EL1 to point to
> -  * either the EL1 or EL0 stack pointer.
> -  */
> - if ((*vcpu_cpsr(vcpu) & PSR_MODE_MASK) == PSR_MODE_EL2h)
> - ctxt->hw_pstate |= PSR_MODE_EL1h;
> - else
> - ctxt->hw_pstate |= PSR_MODE_EL1t;
> + if (vcpu_mode_el2(vcpu)) {
> + /*
> +  * We can emulate the guest's configuration of which
> +  * stack pointer to use when executing in virtual EL2 by
> +  * using the equivalent feature in EL1 to point to
> +  * either the EL1 or EL0 stack pointer.
> +  */
> + if ((*vcpu_cpsr(vcpu) & PSR_MODE_MASK) == PSR_MODE_EL2h)
> + ctxt->hw_pstate |= PSR_MODE_EL1h;
> + else
> + ctxt->hw_pstate |= PSR_MODE_EL1t;
> + }

This looks funny, because now you don't set a mode unless
vcpu_mode_el2(vcpu) is true, which happens to work because the only
other choice is PSR_MODE_EL0t which happens to be 0.

>  
>   ctxt->hw_sys_regs = ctxt->shadow_sys_regs;
>   ctxt->hw_sp_el1 = vcpu_el2_sreg(vcpu, SP_EL2);
> @@ -182,8 +184,14 @@ static void sync_shadow_special_regs(struct kvm_vcpu 
> *vcpu)
>  {
>   struct kvm_cpu_context *ctxt = &vcpu->arch.ctxt;
>  
> - *vcpu_cpsr(vcpu) &= PSR_MODE_MASK;
> - *vcpu_cpsr(vcpu) |= ctxt->hw_pstate & ~PSR_MODE_MASK;
> + *vcpu_cpsr(vcpu) = ctxt->hw_pstate;
> + *vcpu_cpsr(vcpu) &= ~PSR_MODE_MASK;
> + /* Set vcpu exception level depending on the physical EL */
> + if ((ctxt->hw_pstate & PSR_MODE_MASK) == PSR_MODE_EL0t)
> + *vcpu_cpsr(vcpu) |= PSR_MODE_EL0t;
> + else
> + *vcpu_cpsr(vcpu) |= PSR_MODE_EL2h;
> +

don't you need to distinguish between PSR_MODE_EL2h and PSR_MODE_EL2t
here?



>   vcpu_el2_sreg(vcpu, SP_EL2) = ctxt->hw_sp_el1;
>   vcpu_el2_sreg(vcpu, ELR_EL2) = ctxt->hw_elr_el1;
>   vcpu_el2_sreg(vcpu, SPSR_EL2) = ctxt->hw_spsr_el1;
> @@ -218,7 +226,7 @@ void kvm_arm_setup_shadow_state(struct kvm_vcpu *vcpu)
>  {
>   struct kvm_cpu_context *ctxt = &vcpu->arch.ctxt;
>  
> - if (unlikely(vcpu_mode_el2(vcpu))) {
> + if (unlikely(is_hyp_ctxt(vcpu))) {
>   flush_shadow_special_regs(vcpu);
>   flush_shadow_el1_sysregs(vcpu);
>   flush_shadow_non_trap_el1_state(vcpu);
> @@ -236,7 +244,7 @@ void kvm_arm_setup_shadow_state(struct kvm_vcpu *vcpu)
>   */
>  void kvm_arm_restore_shadow_state(struct kvm_vcpu *vcpu)
>  {
> - if (unlikely(vcpu_mode_el2(vcpu))) {
> + if (unlikely(is_hyp_ctxt(vcpu))) {
>   sync_shadow_special_regs(vcpu);
>   sync_shadow_non_trap_el1_s

Dear Talent

[Blue Sky Studio]

Dear Talented,

I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue Sky Studio a Film 
Corporation Located in the United State, is Soliciting for the Right to use 
Your Photo/Face and Personality as One of the Semi -Major Role/ Character in 
our Upcoming ANIMATED Stereoscope 3D Movie-The Story of Anubis (Anubis 2018) 
The Movie is Currently Filming (In Production) Please Note That There Will Be 
No Auditions, Traveling or Any Special / Professional Acting Skills, Since the 
Production of This Movie Will Be Done with our State of Art Computer 
-Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of 
$620,000.00 USD.For More Information/Understanding.

Talent Scout
Kim Sharma

[PATCH v2] Fix header-name to read state name and adjust column width

[Seeteena Thoufeek]

The names of the idle states in the output of cpupower monitor
command are truncated to 4 characters. Hence, On POWER9, since
the states are named "stop0, stop1, stop2, stop4, stop11",
this output is ambiguous

root:~# cpupower monitor
   |Idle_Stats
 PKG |CORE|CPU | snoo | stop | stop
0|   8|   0|  0.00|  0.00|  2.79
0|   8|   1|  0.00|  0.00| 70.68

In this patch, we modify the output to print the state name
and adjust the column width, that results in a legible output.

root:~#cpupower monitor
  |Idle_Stats
PKG |CORE|CPU |snooze|stop0_li|stop1_li
   0|   8|   0|  0.00|0.00|   60.04
   0|   8|   1|  0.00|0.00|   38.97
   0|   8|   2|  0.00|0.00|0.00
   0|   8|   3|  0.00|0.00|0.00
   0|  12|   4|  0.00|0.00|   99.25
   0|  12|   5|  0.00|0.00|0.00
   0|  12|   6|  0.00|0.00|   99.71
   0|  12|   7|  0.00|0.00|   99.85
   8|2048|   8|  0.00|0.00|   54.66
   8|2048|   9|  0.00|0.00|0.00
   8|2048|  10|  0.00|0.00|0.00
   8|2048|  11|  0.00|0.00|   97.83
   8|2052|  12|  0.00|0.00|0.00
   8|2052|  13|  0.00|0.00|0.00
   8|2052|  14|  0.00|0.00|1.99
   8|2052|  15|  0.00|0.00|   99.87

Tested on POWER8, POWER9 and x86.

Signed-off-by: Seeteena Thoufeek 
---
 .../cpupower/utils/idle_monitor/cpupower-monitor.c | 47 +++---
 .../cpupower/utils/idle_monitor/cpupower-monitor.h |  7 +++-
 2 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c 
b/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c
index 05f953f..cf3a1ad 100644
--- a/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c
+++ b/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c
@@ -21,7 +21,10 @@
 #include "idle_monitor/cpupower-monitor.h"
 #include "idle_monitor/idle_monitors.h"
 #include "helpers/helpers.h"
-
+#define xstr(s) str(s)
+#define str(s) #s
+#define COL_WIDTH_MIN   6
+#define COL_WIDTH_MAX   8
 /* Define pointers to all monitors.  */
 #define DEF(x) & x ## _monitor ,
 struct cpuidle_monitor *all_monitors[] = {
@@ -85,7 +88,7 @@ int fill_string_with_spaces(char *s, int n)
 void print_header(int topology_depth)
 {
int unsigned mon;
-   int state, need_len;
+   int state, need_len, name_len;
cstate_t s;
char buf[128] = "";
int percent_width = 4;
@@ -116,17 +119,19 @@ void print_header(int topology_depth)
for (mon = 0; mon < avail_monitors; mon++) {
if (mon != 0)
printf("|| ");
-   else
-   printf(" ");
for (state = 0; state < monitors[mon]->hw_states_num; state++) {
if (state != 0)
-   printf(" | ");
+   printf("|");
s = monitors[mon]->hw_states[state];
-   sprintf(buf, "%s", s.name);
+   name_len = strlen(s.name);
+   if (name_len <= COL_WIDTH_MIN)
+   percent_width = COL_WIDTH_MIN;
+   else
+   percent_width = COL_WIDTH_MAX;
+   sprintf(buf, "%.*s", percent_width, s.name);
fill_string_with_spaces(buf, percent_width);
printf("%s", buf);
}
-   printf(" ");
}
printf("\n");
 }
@@ -134,11 +139,12 @@ void print_header(int topology_depth)
 
 void print_results(int topology_depth, int cpu)
 {
-   unsigned int mon;
-   int state, ret;
+   unsigned int mon, percent_width, name_len, width;
+   int state, ret, i;
double percent;
unsigned long long result;
cstate_t s;
+   char buf[128] = "";
 
/* Be careful CPUs may got resorted for pkg value do not just use cpu */
if (!bitmask_isbitset(cpus_chosen, cpu_top.core_info[cpu].cpu))
@@ -163,23 +169,34 @@ void print_results(int topology_depth, int cpu)
printf("|");
 
s = monitors[mon]->hw_states[state];
-
+   name_len = strlen(s.name);
+   if (name_len > COL_WIDTH_MIN) {
+   percent_width = COL_WIDTH_MAX;
+   width = percent_width - COL_WIDTH_MIN;
+   fill_string_with_spaces(buf, width);
+   printf("%s", buf);
+   }
if (s.get_count_percent) {
ret = s.get_count_percent(s.id, &percent,
  cpu_top.core_info[cpu].cpu);
if (ret)
-   printf("**");
+   for (i = 0; i < COL_WIDTH_MIN; i++)
+   

RE: [PATCH V5 net-next 2/8] net: hns3: Add support of the HNAE3 framework

[Salil Mehta]

Hi Leon,

> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> ow...@vger.kernel.org] On Behalf Of Leon Romanovsky
> Sent: Sunday, July 30, 2017 10:59 AM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-r...@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH V5 net-next 2/8] net: hns3: Add support of the
> HNAE3 framework
> 
> On Fri, Jul 28, 2017 at 11:26:46PM +0100, Salil Mehta wrote:
> > This patch adds the support of the HNAE3 (Hisilicon Network
> > Acceleration Engine 3) framework support to the HNS3 driver.
> >
> > Framework facilitates clients like ENET(HNS3 Ethernet Driver), RoCE
> > and user-space Ethernet drivers (like ODP etc.) to register with
> HNAE3
> > devices and their associated operations.
> >
> > Signed-off-by: Daode Huang 
> > Signed-off-by: lipeng 
> > Signed-off-by: Salil Mehta 
> > Signed-off-by: Yisen Zhuang 
> > ---
> > Patch V5: Addressed following comments
> >   1. Leon Romanovsky:
> >  https://lkml.org/lkml/2017/7/23/67
> > Patch V4: Addressed following comments
> >   1. Andrew Lunn:
> >  https://lkml.org/lkml/2017/6/17/233
> >  https://lkml.org/lkml/2017/6/18/105
> >   2. Bo Yu:
> >  https://lkml.org/lkml/2017/6/18/112
> >   3. Stephen Hamminger:
> >  https://lkml.org/lkml/2017/6/19/778
> > Patch V3: Addressed below comments
> >   1. Andrew Lunn:
> >  https://lkml.org/lkml/2017/6/13/1025
> > Patch V2: No change
> > Patch V1: Initial Submit
> > ---
> >  drivers/net/ethernet/hisilicon/hns3/hnae3.c | 319
> 
> >  drivers/net/ethernet/hisilicon/hns3/hnae3.h | 444
> 
> >  2 files changed, 763 insertions(+)
> >  create mode 100644 drivers/net/ethernet/hisilicon/hns3/hnae3.c
> >  create mode 100644 drivers/net/ethernet/hisilicon/hns3/hnae3.h
> >
> > diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
> b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
> > new file mode 100644
> > index 000..d28b69d
> > --- /dev/null
> > +++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
> > @@ -0,0 +1,319 @@
> > +/*
> > + * Copyright (c) 2016-2017 Hisilicon Limited.
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "hnae3.h"
> > +
> > +static LIST_HEAD(hnae3_ae_algo_list);
> > +static LIST_HEAD(hnae3_client_list);
> > +static LIST_HEAD(hnae3_ae_dev_list);
> > +
> > +/* we are keeping things simple and using single lock for all the
> > + * list. This is a non-critical code so other updations, if happen
> > + * in parallel, can wait.
> > + */
> > +static DEFINE_MUTEX(hnae3_common_lock);
> > +
> > +static bool hnae3_client_match(enum hnae3_client_type client_type,
> > +  enum hnae3_dev_type dev_type)
> > +{
> > +   if (dev_type == HNAE3_DEV_KNIC) {
> > +   switch (client_type) {
> > +   case HNAE3_CLIENT_KNIC:
> > +   case HNAE3_CLIENT_ROCE:
> > +   return true;
> > +   default:
> > +   return false;
> > +   }
> > +   } else if (dev_type == HNAE3_DEV_UNIC) {
> > +   switch (client_type) {
> > +   case HNAE3_CLIENT_UNIC:
> > +   return true;
> > +   default:
> > +   return false;
> > +   }
> > +   } else {
> > +   return false;
> > +   }
> > +}
> 
> Slightly compact version:
> 
> static bool hnae3_client_match(enum hnae3_client_type client_type,
>  enum hnae3_dev_type dev_type)
> {
>   if (dev_type == HNAE3_DEV_KNIC &&
>   client_type == HNAE3_CLIENT_KNIC || client_type ==
> HNAE3_CLIENT_ROCE)
>   return true;
>   if (dev_type == HNAE3_DEV_UNIC && client_type ==
> HNAE3_CLIENT_UNIC)
>   return true;
>   return false;
> }
Ok will change but I have felt usually with switch code looks more readable.

Thanks
> 
> 
> > +
> > +static int hnae3_match_n_instantiate(struct hnae3_client *client,
> > +struct hnae3_ae_dev *ae_dev,
> > +bool is_reg, bool *matched)
> > +{
> > +   int ret;
> > +
> > +   *matched = false;
> > +
> > +   /* check if this client matches the type of ae_dev */
> > +   if (!(hnae3_client_match(client->type, ae_dev->dev_type) &&
> > + hnae_get_bit(ae_dev->flag, HNAE3_DEV_INITED_B))) {
> > +   return 0;
> > +   }
> > +   /* there is a match of client and dev */
> > +   *matched = true;
> > +
> > +   if (!(ae_dev->ops && ae_dev->ops->init_client_instance &&
> > + ae_dev->ops->uninit_client_instance)) {
> > +   dev_err(