RE: [PATCH 2/3] rpmsg: Only invoke announce_create for rpdev with endpoints

[Loic PALLARDY]

Hi Bjorn,

> -Original Message-
> From: linux-remoteproc-ow...@vger.kernel.org [mailto:linux-remoteproc-
> ow...@vger.kernel.org] On Behalf Of Bjorn Andersson
> Sent: Tuesday, March 27, 2018 11:07 PM
> To: Ohad Ben-Cohen ; Bjorn Andersson
> 
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> arm-...@vger.kernel.org
> Subject: [PATCH 2/3] rpmsg: Only invoke announce_create for rpdev with
> endpoints
> 
> For special rpmsg devices without a primary endpoint there is nothing to
> announce so don't call the backend announce create function if we didn't
> create an endpoint.
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/rpmsg/rpmsg_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index dffa3aab7178..e85d2691d2cf 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -442,7 +442,7 @@ static int rpmsg_dev_probe(struct device *dev)
>   goto out;
>   }
> 
> - if (rpdev->ops->announce_create)
> + if (ept && rpdev->ops->announce_create)

This check is already part of virtio_rpmsg.c (see line 341)
/* need to tell remote processor's name service about this channel ? */
if (rpdev->announce && rpdev->ept &&
virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {

should it be part of qcom_smd driver too? (but each implementation will 
duplicate checks)
Or may have a generic check in the core including rpdev->announce as well (and 
doing virtio_rpmsg.c clean-up)

Change will become:
if (rpdev->announce && ept && rpdev->ops->announce_create)

Regards,
Loic
>   err = rpdev->ops->announce_create(rpdev);
>  out:
>   return err;
> --
> 2.16.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] s390 patches for the 4.17 merge window #1

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

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

to receive the following updates:

 * Improvements for the spectre defense:
   - The spectre related code is consolidated to a single file nospec-branch.c
   - Automatic enable/disable for the spectre v2 defenses (expoline vs. nobp)
   - Syslog messages for specve v2 are added
   - Enable CONFIG_GENERIC_CPU_VULNERABILITIES and define the attribute
 functions for spectre v1 and v2

 * Add helper macros for assembler alternatives and use them to shorten
   the code in entry.S.

 * Add support for persistent configuration data via the SCLP Store Data
   interface. The H/W interface requires a page table that uses 4K pages
   only, the code to setup such an address space is added as well.

 * Enable virtio GPU emulation in QEMU. To do this the depends statements
   for a few common Kconfig options are modified.

 * Add support for format-3 channel path descriptors and add a binary
   sysfs interface to export the associated utility strings.

 * Add a sysfs attribute to control the IFCC handling in case of constant
   channel errors.

 * The vfio-ccw changes from Cornelia.

 * Bug fixes and cleanups.

There is a trivial merge conflict in drivers/video/console/Kconfig.

Christian Borntraeger (2):
  s390/sclp_tty: enable line mode tty even if there is an ascii console
  s390/defkeymap: fix global init to zero

Claudio Imbrenda (4):
  s390/sclp: clean up, use sccb_mask_t where appropriate
  s390/sclp: generic event mask accessors
  s390/sclp: 32 bit event mask compatibility mode
  s390/sclp: 64 bit event mask

Cornelia Huck (3):
  s390: fix comment for scsw_cmd_is_valid_sctl
  vfio-ccw: update documentation
  vfio-ccw: fence off transport mode

Farhan Ali (3):
  Kconfig : Remove HAS_IOMEM dependency for Graphics support
  s390/char : Rename EBCDIC keymap variables
  s390/setup : enable display support for KVM guest

Harald Freudenberger (1):
  s390/crypto: Fix kernel crash on aes_s390 module remove.

Heiko Carstens (1):
  s390/mm: provide base_asce_alloc() / base_asce_free() helper functions

Julian Wiedmann (6):
  s390: fix typo in irb description
  s390/qdio: simplify math in get_*_buffer_frontier()
  s390/qdio: don't merge ERROR output buffers
  s390/qdio: restrict buffer merging to eligible devices
  s390/qdio: don't retry EQBS after CCQ 96
  s390/qdio: split up CCQ handling for EQBS / SQBS

Martin Schwidefsky (8):
  s390: move nobp parameter functions to nospec-branch.c
  s390: add automatic detection of the spectre defense
  s390: report spectre mitigation via syslog
  s390: add sysfs attributes for spectre
  s390: add assembler macros for CPU alternatives
  s390/entry.S: use assembler alternatives
  s390/lpp: use assembler alternatives for the LPP instruction
  s390/kvm: improve stack frame constants in entry.S

Peter Oberparleiter (1):
  s390/sclp: Add support for Store Data SCLP interface

Sebastian Ott (4):
  s390/cio: fix unbind of io_subchannel_driver
  s390/cio: rename struct channel_path_desc
  s390/chsc: query utility strings via fmt3 channel path descriptor
  s390/cio: add util_string sysfs attribute

Stefan Haberland (3):
  s390/dasd: configurable IFCC handling
  s390/dasd: remove unneeded sanity check
  s390/dasd: set timestamps unconditionally

Vasily Gorbik (4):
  s390/decompressor: discard __ex_table section
  s390: unify linker symbols usage
  s390: set bzImage as default image for packaging
  s390/decompressor: trim uncompressed image head during the build

 Documentation/s390/vfio-ccw.txt |  79 +++--
 arch/s390/Kconfig   |   3 +-
 arch/s390/Makefile  |   8 +-
 arch/s390/boot/compressed/Makefile  |  16 +-
 arch/s390/boot/compressed/head.S|   6 +-
 arch/s390/boot/compressed/misc.c|  10 +-
 arch/s390/boot/compressed/vmlinux.lds.S |   1 +
 arch/s390/crypto/aes_s390.c |   5 +-
 arch/s390/include/asm/alternative-asm.h | 108 ++
 arch/s390/include/asm/ccwdev.h  |   2 +-
 arch/s390/include/asm/chpid.h   |   2 +-
 arch/s390/include/asm/cio.h |   2 +-
 arch/s390/include/asm/cpu_mf.h  |   4 +-
 arch/s390/include/asm/css_chars.h   |   6 +-
 arch/s390/include/asm/nospec-branch.h   |   6 +-
 arch/s390/include/asm/pgalloc.h |   3 +
 arch/s390/include/asm/scsw.h|   4 +-
 arch/s390/include/asm/setup.h   |   2 -
 arch/s390/include/uapi/asm/dasd.h   |  38 ++-
 arch/s390/kernel/Makefile   |   4 +-
 arch/s390/kernel/alternative.c  |  24 +-
 arch/s390/kernel/asm-offsets.c  |   1 +
 arch/s390/kernel/early.c|   4 +-
 arch/s390/kernel/entry.S|  96 ++
 arch/s390/kernel/module.c   |  11 +-
 

Re: general protection fault in try_to_wake_up

[Peter Zijlstra]

On Tue, Apr 03, 2018 at 10:50:03AM +0200, Petr Mladek wrote:
> raw_spin_lock() succeeded here. Therefore lockdep was still working
> at this stage.

What does the success of raw_spin_lock() have to do with lockdep ?

Re: [PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Julia Lawall]

On Tue, 3 Apr 2018, Jani Nikula wrote:

> On Fri, 30 Mar 2018, Colin King  wrote:
> > From: Colin Ian King 
> >
> > Trivial fix to spelling mistake in DRM_ERROR error message text
>
> Thanks for the patch.
>
> Please do consider limiting the distribution in the future,
> though. There's no need to include lkml or even dri-devel for trivial
> patches like this.

It's complex to have to remember the preferences for every subsystem.
Preferences should be expressed in the MAINTAINERS file in some way.
Also, since no one reads lkml, does it hurt to have even trivial patches?

julia

>
> Thanks,
> Jani.
>
> >
> > Signed-off-by: Colin Ian King 
> > ---
> >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index e42a28e3adc5..1df1c91b6ae5 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -1521,7 +1521,7 @@ static int amdgpu_dm_initialize_drm_device(struct 
> > amdgpu_device *adev)
> > break;
> >  #endif
> > default:
> > -   DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
> > +   DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
> > goto fail;
> > }
> >
> > @@ -1715,7 +1715,7 @@ static int dm_early_init(void *handle)
> > break;
> >  #endif
> > default:
> > -   DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
> > +   DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
> > return -EINVAL;
> > }
>
> --
> Jani Nikula, Intel Open Source Technology Center
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Jani Nikula]

On Tue, 03 Apr 2018, Julia Lawall  wrote:
> On Tue, 3 Apr 2018, Jani Nikula wrote:
>> Please do consider limiting the distribution in the future,
>> though. There's no need to include lkml or even dri-devel for trivial
>> patches like this.
>
> It's complex to have to remember the preferences for every subsystem.
> Preferences should be expressed in the MAINTAINERS file in some way.

They are; it's just that get_maintainer.pl has silly defaults. There's
no reason it should include the full chain from the leaf driver to the
subsystem to the LKML by default, with a bunch of authors and commit
signers on top. Especially so for supported drivers. I'm surprised it
doesn't include Linus by default.

> Also, since no one reads lkml, does it hurt to have even trivial patches?

Heh. Let's just say I care more about dri-devel.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 4/8] misc: pci_endpoint_test: Add designware EP entry

[Gustavo Pimentel]

Hi Kishon,

On 02/04/2018 06:36, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote:
>> Adds the designware EP device ID entry to pci_endpoint_test driver table
>> to allow this device to be recognize and handle by the pci_endpoint_test
>> driver.
>>
>> Signed-off-by: Gustavo Pimentel 
>> ---
>>  drivers/misc/pci_endpoint_test.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/misc/pci_endpoint_test.c 
>> b/drivers/misc/pci_endpoint_test.c
>> index 320276f..e80c533 100644
>> --- a/drivers/misc/pci_endpoint_test.c
>> +++ b/drivers/misc/pci_endpoint_test.c
>> @@ -632,6 +632,7 @@ static void pci_endpoint_test_remove(struct pci_dev 
>> *pdev)
>>  static const struct pci_device_id pci_endpoint_test_tbl[] = {
>>  { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
>>  { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
>> +{ PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS, 0xedda) },
> 
> Add device ids to include/linux/pci_ids.h and use the macro here.

Add device id request sent, as soon as I get a positive confirmation from them
I'll change for the macro. It works for you?

> 
> Thanks
> Kishon
> 

Regards,
Gustavo

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

[Marcel Holtmann]

Hi Sean,

> This adds a driver for the MediaTek serial protocol based on H4 protocol,
> which can enable the built-in Bluetooth device inside MT7622 SoC.
> 
> Signed-off-by: Sean Wang 
> ---
> drivers/bluetooth/Kconfig|  12 +
> drivers/bluetooth/Makefile   |   1 +
> drivers/bluetooth/hci_mediatek.c | 499 +++
> drivers/bluetooth/hci_uart.h |   3 +-
> 4 files changed, 514 insertions(+), 1 deletion(-)
> create mode 100644 drivers/bluetooth/hci_mediatek.c
> 
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 010f5f5..851f430 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -104,6 +104,18 @@ config BT_HCIUART_H4
> 
> Say Y here to compile support for HCI UART (H4) protocol.
> 
> +config BT_HCIUART_MEDIATEK
> + tristate "MediaTek protocol support"
> + depends on BT_HCIUART_SERDEV
> + select BT_HCIUART_H4
> + help
> +   The MediaTek protocol based on H4 enables patch firmware download and
> +   configuration. This protocol is required for MediaTek Bluetooth
> +   devices with a serial bus such as BTIF, which can be usually found on
> +   various MediaTek SoCs.
> +
> +   Say Y here to compile support for MediaTek protocol.
> +
> config BT_HCIUART_NOKIA
>   tristate "UART Nokia H4+ protocol support"
>   depends on BT_HCIUART
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index ec16c55..db93c76 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -43,5 +43,6 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL) += hci_intel.o
> hci_uart-$(CONFIG_BT_HCIUART_BCM) += hci_bcm.o
> hci_uart-$(CONFIG_BT_HCIUART_QCA) += hci_qca.o
> hci_uart-$(CONFIG_BT_HCIUART_AG6XX)   += hci_ag6xx.o
> +hci_uart-$(CONFIG_BT_HCIUART_MEDIATEK)  += hci_mediatek.o

we used when available the 3 letter short version of the manufacture. So this 
would be MTK and hci_mtk.o in this case. Not that I care that much.

> hci_uart-$(CONFIG_BT_HCIUART_MRVL)+= hci_mrvl.o
> hci_uart-objs := $(hci_uart-y)
> diff --git a/drivers/bluetooth/hci_mediatek.c 
> b/drivers/bluetooth/hci_mediatek.c
> new file mode 100644
> index 000..7ac1e7a
> --- /dev/null
> +++ b/drivers/bluetooth/hci_mediatek.c
> @@ -0,0 +1,499 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018 MediaTek Inc.
> +
> +/*
> + * Bluetooth HCI Serial driver for MediaTek SoC
> + *
> + * Author: Sean Wang 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "hci_uart.h"
> +
> +#define FIRMWARE_MT7622  "mediatek/mt7622_patch_firmware.bin”

Has this firmware already been submitted to linux-firmware tree?

> +
> +#define MTK_STP_HDR_SIZE 4
> +#define MTK_STP_TLR_SIZE 2
> +#define MTK_WMT_HDR_SIZE 5
> +#define MTK_WMT_CMD_SIZE (MTK_WMT_HDR_SIZE + MTK_STP_HDR_SIZE + \
> +  MTK_STP_TLR_SIZE + HCI_ACL_HDR_SIZE)
> +
> +enum {
> + MTK_WMT_PATCH_DWNLD = 0x1,
> + MTK_WMT_FUNC_CTRL = 0x6,
> + MTK_WMT_RST = 0x7
> +};
> +
> +struct mtk_stp_splitter {
> + u8  pad[6];
> + u8  cursor;
> + u16 dlen;
> +};
> +
> +struct mtk_bt_dev {
> + struct hci_uart hu;
> + struct clk *clk;
> + struct sk_buff *rx_skb;
> + struct sk_buff_head txq;
> + struct completion wmt_cmd;
> + struct mtk_stp_splitter *sp;
> +};
> +
> +struct mtk_stp_hdr {
> + __u8 prefix;
> + __u8 dlen1:4;
> + __u8 type:4;
> + __u8 dlen2:8;
> + __u8 cs;
> +} __packed;
> +
> +struct mtk_wmt_hdr {
> + __u8dir;
> + __u8op;
> + __le16  dlen;
> + __u8flag;
> +} __packed;
> +
> +static void mtk_stp_reset(struct mtk_stp_splitter *sp)
> +{
> + sp->cursor = 2;
> + sp->dlen = 0;
> +}
> +
> +static const unsigned char *
> +mtk_stp_split(struct device *dev, struct mtk_stp_splitter *sp,
> +   const unsigned char *data, int count, int *sz_h4)
> +{
> + struct mtk_stp_hdr *shdr;
> +
> + /* The cursor is reset when all the data of STP is being consumed. */
> + if (!sp->dlen && sp->cursor >= 6)
> + sp->cursor = 0;
> +
> + /* Filling pad until all STP info is obtained. */
> + while (sp->cursor < 6 && count > 0) {
> + sp->pad[sp->cursor] = *data;
> + sp->cursor++;
> + data++;
> + count--;
> + }
> +
> + /* Retrieve STP info and have a sanity check. */
> + if (!sp->dlen && sp->cursor >= 6) {
> + shdr = (struct mtk_stp_hdr *)>pad[2];
> + sp->dlen = shdr->dlen1 << 8 | shdr->dlen2;
> +
> + /* Resync STP when unexpected data is being read. */
> + if (shdr->prefix != 0x80 || sp->dlen > 2048) {
> + dev_err(dev, 

Re: [PATCH v8 25/42] ARM: davinci: dm644x: add new clock init using common clock framework

[Sekhar Nori]

On Friday 16 March 2018 08:22 AM, David Lechner wrote:
> +static struct resource dm644x_pll1_resources[] = {
> + {
> + .start  = DAVINCI_PLL1_BASE,
> + .end= DAVINCI_PLL1_BASE + SZ_4K - 1,

The .end should be DAVINCI_PLL1_BASE + SZ_1K - 1, otherwise it prevents
PLL2 from getting registered.

> + .flags  = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct platform_device dm644x_pll1_device = {
> + .name   = "dm644x-pll1",
> + .id = -1,
> + .resource   = dm644x_pll1_resources,
> + .num_resources  = ARRAY_SIZE(dm644x_pll1_resources),
> +};
> +
> +static struct resource dm644x_pll2_resources[] = {
> + {
> + .start  = DAVINCI_PLL2_BASE,
> + .end= DAVINCI_PLL2_BASE + SZ_4K - 1,

And this too should be fixed, else it prevents the PSC from getting
registered.

> + .flags  = IORESOURCE_MEM,
> + },
> +};

With these fixed, I still had to enable 'clk_ignore_unused' on DM644x
EVM to get to NFS boot. I think root of the problem is that pm_runtime()
APIs are not working in the legacy boot mode.

This can be seen even on the DA850 LCDK in legacy boot. pm_genpd_summary
in debugfs shows all domains are off and there are no devices registered
under the "da850-psc1: emac" domain. NFS mounting still works on the
DA850 LCDK because clk_summary shows enable and prepare count of 4 for
emac. Not sure how that's happening. But on DM644x EVM, the emac clock
enable count is 0.

Still looking at whats going wrong here. I am testing your v8 branch
with clk-davinci branch from clk-next merged to get the fixes Stephen made.

Thanks,
Sekhar

[PATCH] ARM64: dts: meson-axg: enable the eMMC controller

[Yixun Lan]

From: Nan Li 

The IP of eMMC controller in AXG is similiar to Meson-GX series.
Here we add the initial support of the HS200 mode with
clock running at 166MHz (to be safe), since we found some eMMC chip
fail to run at 200MHz due to tunning phase error.

Signed-off-by: Nan Li 
Signed-off-by: Yixun Lan 

---
Hi Kevin
  Please note this patch actually depend on the eMMC driver here [0].
  Still a few problem to solve, to improve the tuning phase driver to make
the clock running at 200MHz, and to further support the HS400 mode.
Anyway, this patch itself is quite independent.

[0] http://lkml.kernel.org/r/20180403100652.41056-1-yixun@amlogic.com
---
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 58 ++
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 81 ++
 2 files changed, 139 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts 
b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 57eedced5a51..f67d4e47e641 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -15,6 +15,44 @@
serial0 = _AO;
serial1 = _A;
};
+
+   vddio_boot: regulator-vddio_boot {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDIO_BOOT";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   vddao_3v3: regulator-vddao_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDAO_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vddio_ao18: regulator-vddio_ao18 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDIO_AO18";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   vcc_3v3: regulator-vcc_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   reset-gpios = < GPIOX_6 GPIO_ACTIVE_LOW>;
+   };
 };
 
  {
@@ -47,3 +85,23 @@
pinctrl-0 = <_z_pins>;
pinctrl-names = "default";
 };
+
+/* emmc storage */
+_emmc_c {
+   status = "okay";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_clk_gate_pins>;
+   pinctrl-names = "default", "clk-gate";
+
+   bus-width = <8>;
+   cap-sd-highspeed;
+   cap-mmc-highspeed;
+   max-frequency = <18000>;
+   non-removable;
+   disable-wp;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+
+   vmmc-supply = <_3v3>;
+   vqmmc-supply = <_boot>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index b58808eb3cc8..52d65643d4b7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -113,6 +113,36 @@
#size-cells = <2>;
ranges;
 
+   apb: apb@ffe0 {
+   compatible = "simple-bus";
+   reg = <0x0 0xffe0 0x0 0x20>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x20>;
+
+   sd_emmc_b: sd@5000 {
+   compatible = "amlogic,meson-axg-mmc";
+   reg = <0x0 0x5000 0x0 0x2000>;
+   interrupts = ;
+   status = "disabled";
+   clocks = < CLKID_SD_EMMC_B>,
+   < CLKID_SD_EMMC_B_CLK0>,
+   < CLKID_FCLK_DIV2>;
+   clock-names = "core", "clkin0", "clkin1";
+   };
+
+   sd_emmc_c: mmc@7000 {
+   compatible = "amlogic,meson-axg-mmc";
+   reg = <0x0 0x7000 0x0 0x2000>;
+   interrupts = ;
+   status = "disabled";
+   clocks = < CLKID_SD_EMMC_C>,
+   < CLKID_SD_EMMC_C_CLK0>,
+   < CLKID_FCLK_DIV2>;
+   clock-names = "core", "clkin0", "clkin1";
+   };
+   };
+
cbus: bus@ffd0 {
compatible = 

Re: [PATCH 4.4 076/134] kprobes/x86: Set kprobes pages read-only

[Greg Kroah-Hartman]

On Mon, Apr 02, 2018 at 03:45:57PM +0900, Masami Hiramatsu wrote:
> On Sun, 01 Apr 2018 17:20:30 +0100
> Ben Hutchings  wrote:
> 
> > On Mon, 2018-03-19 at 19:05 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > > 
> > > --
> > > 
> > > From: Masami Hiramatsu 
> > > 
> > > 
> > > [ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]
> > 
> > This caused a regression in mainline, fixed by:
> > 
> > commit c93f5cf571e7795f97d49ef51b766cf25e328545
> > Author: Masami Hiramatsu 
> > Date:   Thu May 25 19:38:17 2017 +0900
> > 
> > kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
> 
> Thanks Ben,
> Greg, could you please pick above patch too?

Now picked up, thanks.

greg k-h

Re: [PATCH 5/6] spi: sun4i: introduce register set/unset helpers

[Sergey Suloev]

On 04/03/2018 11:14 AM, Maxime Ripard wrote:

On Thu, Mar 29, 2018 at 09:59:06PM +0300, Sergey Suloev wrote:

Two helper functions were added in order to update
registers easily.

Signed-off-by: Sergey Suloev 

I'm not really sure what's easier about this one.

Maxime



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


well, just seems more readable vs doing "read, or, write" every time

What's the priority of the idle task?

[Ferenc Wágner]

Hi,

(Please let me ask my Stackexchange question [1] here as well in the
hope of getting an answer from this board of dedicated experts.)

As explained by several (if somewhat old) articles [2,3,4], the Linux
idle task (PID=0, one per CPU) is run when there are no other tasks to
run. To get the scheduler do this, the idle task must have the lowest
priority reserved for it. That old Documentation/ftrace.txt in the
linked LWN article explicitly says that

> The prio "140" is reserved for the idle task which is the lowest
> priority thread (pid 0).

This makes sense, but under Linux 4.9

# perf record -e sched:sched_switch sleep 1
# perf script
   sleep  6526 [000] 362661.310842: sched:sched_switch: sleep:6526 [120] S ==> 
swapper/0:0 [120]

reports a priority of 120 for swapper/0 (in the closing bracket),
contradicting the above.

How does the Linux scheduler handle the idle task nowadays? The commits
removing the quoted text from ftrace.txt (87d80de28, 294ae4011) didn't
help.

Please Cc me on answers/comments.

Thanks,
Feri.

[1] 
https://unix.stackexchange.com/questions/435089/whats-the-priority-of-the-idle-task
[2] https://superuser.com/a/972581/462180
[3] https://lwn.net/Articles/290277/
[4] 
https://unix.stackexchange.com/questions/361245/what-does-an-idle-cpu-process-do

Re: [GIT PULL] remove in-kernel calls to syscalls

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Mon, Apr 2, 2018 at 12:04 PM, Dominik Brodowski
>  wrote:
> >
> > This patchset removes all in-kernel calls to syscall functions in the
> > kernel with the exception of arch/.
> 
> Ok, this finished off my arch updates for today, I'll probably move on
> to driver pulls tomorrow.
> 
> Anyway, it's in my tree, will push out once my test build finishes.

Thanks!

Dominik, if you submit the x86 ptregs conversion patches in the next 1-2 days 
on 
top of Linus's tree (642e7fd23353), then I can apply them and if they are 
problem-free I can perhaps tempt Linus with a pull request early next week or 
so.

The Spectre angle does make me want those changes as well.

Thanks,

Ingo

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

[Cornelia Huck]

On Wed, 14 Mar 2018 14:25:45 -0400
Tony Krowiak  wrote:

> Introduces a new AP device driver. This device driver
> is built on the VFIO mediated device framework. The framework
> provides sysfs interfaces that facilitate passthrough
> access by guests to devices installed on the linux host.
> 
> The VFIO AP device driver will serve two purposes:
> 
> 1. Provide the interfaces to reserve AP devices for exclusive
>use by KVM guests. This is accomplished by unbinding the
>devices to be reserved for guest usage from the default AP
>device driver and binding them to the VFIO AP device driver.
> 
> 2. Implements the functions, callbacks and sysfs attribute
>interfaces required to create one or more VFIO mediated
>devices each of which will be used to configure the AP
>matrix for a guest and serve as a file descriptor
>for facilitating communication between QEMU and the
>VFIO AP device driver.
> 
> When the VFIO AP device driver is initialized:
> 
> * It registers with the AP bus for control of type 10 (CEX4
>   and newer) AP queue devices. The probe and remove callbacks
>   will be provided to support the binding/unbinding of
>   AP queue devices to/from the VFIO AP device driver.
> 
> * Creates a /sys/devices/vfio-ap/matrix device to hold
>   the APQNs of the AP devices bound to the VFIO
>   AP device driver and serves as the parent of the
>   mediated devices created for each guest.
> 
> Signed-off-by: Tony Krowiak 
> ---
>  MAINTAINERS   |2 +
>  arch/s390/Kconfig |   11 +++
>  drivers/s390/crypto/Makefile  |4 +
>  drivers/s390/crypto/vfio_ap_drv.c |  135 
> +
>  drivers/s390/crypto/vfio_ap_private.h |   22 ++
>  include/uapi/linux/vfio.h |2 +
>  6 files changed, 176 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/s390/crypto/vfio_ap_drv.c
>  create mode 100644 drivers/s390/crypto/vfio_ap_private.h
> 

> diff --git a/drivers/s390/crypto/vfio_ap_drv.c 
> b/drivers/s390/crypto/vfio_ap_drv.c
> new file mode 100644
> index 000..459e595
> --- /dev/null
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -0,0 +1,135 @@
> +/*
> + * VFIO based AP device driver
> + *
> + * Copyright IBM Corp. 2017

Update to 2018?

> + *
> + * Author(s): Tony Krowiak 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "vfio_ap_private.h"
> +
> +#define VFIO_AP_ROOT_NAME "vfio_ap"
> +#define VFIO_AP_DEV_TYPE_NAME "ap_matrix"
> +#define VFIO_AP_DEV_NAME "matrix"
> +
> +MODULE_AUTHOR("IBM Corporation");
> +MODULE_DESCRIPTION("VFIO AP device driver, Copyright IBM Corp. 2017");
> +MODULE_LICENSE("GPL v2");
> +
> +static struct device *vfio_ap_root_device;
> +
> +static struct ap_driver vfio_ap_drv;
> +
> +static struct ap_matrix *ap_matrix;
> +
> +static struct device_type vfio_ap_dev_type = {
> + .name = VFIO_AP_DEV_TYPE_NAME,
> +};
> +
> +/* Only type 10 adapters (CEX4 and later) are supported
> + * by the AP matrix device driver
> + */
> +static struct ap_device_id ap_queue_ids[] = {
> + { .dev_type = AP_DEVICE_TYPE_CEX4,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { .dev_type = AP_DEVICE_TYPE_CEX5,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { .dev_type = AP_DEVICE_TYPE_CEX6,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { /* end of sibling */ },
> +};
> +
> +MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
> +
> +static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
> +{
> + return 0;
> +}
> +
> +static void vfio_ap_matrix_dev_release(struct device *dev)
> +{
> + struct ap_matrix *ap_matrix = dev_get_drvdata(dev);
> +
> + kfree(ap_matrix);
> +}
> +
> +static int vfio_ap_matrix_dev_create(void)
> +{
> + int ret;
> +
> + vfio_ap_root_device = root_device_register(VFIO_AP_ROOT_NAME);
> +
> + ret = IS_ERR(vfio_ap_root_device);
> + if (ret) {

Minor nit: I'd contract that to

if (IS_ERR(vfio_ap_root_device)) {

(you're writing ret in any case)

> + ret = PTR_ERR(vfio_ap_root_device);
> + goto done;
> + }
> +
> + ap_matrix = kzalloc(sizeof(*ap_matrix), GFP_KERNEL);
> + if (!ap_matrix) {
> + ret = -ENOMEM;
> + goto matrix_alloc_err;
> + }
> +
> + ap_matrix->device.type = _ap_dev_type;
> + dev_set_name(_matrix->device, "%s", VFIO_AP_DEV_NAME);
> + ap_matrix->device.parent = vfio_ap_root_device;
> + ap_matrix->device.release = vfio_ap_matrix_dev_release;
> + ap_matrix->device.driver = _ap_drv.driver;
> +
> + ret = device_register(_matrix->device);
> + if (ret)
> + goto matrix_reg_err;
> +
> + goto done;
> +
> +matrix_reg_err:
> + put_device(_matrix->device);
> + kfree(ap_matrix);

The kfree() is wrong: If you called device_register for the embedded
struct device, this needs 

Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

[Michal Hocko]

On Tue 03-04-18 13:54:11, Kirill A. Shutemov wrote:
> On Tue, Apr 03, 2018 at 10:34:51AM +0200, Michal Hocko wrote:
> > On Tue 03-04-18 08:24:06, Naoya Horiguchi wrote:
> > > On Tue, Apr 03, 2018 at 09:59:28AM +0200, Michal Hocko wrote:
> > > > On Tue 03-04-18 13:46:28, Naoya Horiguchi wrote:
> > > > > My testing for the latest kernel supporting thp migration found out an
> > > > > infinite loop in offlining the memory block that is filled with shmem
> > > > > thps.  We can get out of the loop with a signal, but kernel should
> > > > > return with failure in this case.
> > > > >
> > > > > What happens in the loop is that scan_movable_pages() repeats 
> > > > > returning
> > > > > the same pfn without any progress. That's because page migration 
> > > > > always
> > > > > fails for shmem thps.
> > > >
> > > > Why does it fail? Shmem pages should be movable without any issues.
> > > 
> > > .. because try_to_unmap_one() explicitly skips unmapping for migration.
> > > 
> > >   #ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
> > >   /* PMD-mapped THP migration entry */
> > >   if (!pvmw.pte && (flags & TTU_MIGRATION)) {
> > >   VM_BUG_ON_PAGE(PageHuge(page) || 
> > > !PageTransCompound(page), page);
> > >   
> > >   if (!PageAnon(page))
> > >   continue;
> > >   
> > >   set_pmd_migration_entry(, page);
> > >   continue;
> > >   }
> > >   #endif
> > > 
> > > When I implemented this code, I felt hard to work on both of anon thp
> > > and shmem thp at one time, so I separated the proposal into smaller steps.
> > > Shmem uses pagecache so we need some non-trivial effort (including 
> > > testing)
> > > to extend thp migration for shmem. But I think it's a reasonable next 
> > > step.
> > 
> > OK, I see. I have forgot about this part. Please be explicit about that
> > in the changelog. Also the proper fix is to not use movable zone for
> > shmem page THP rather than hack around it in the hotplug specific code
> > IMHO.
> 
> No. We should just split the page before running
> try_to_unmap(TTU_MIGRATION) on the page.

If splitting is a preffered way then I do not have any objection. We
just cannot keep unmovable objects in the zone movable.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/8] bindings: PCI: designware: Example update

[Kishon Vijay Abraham I]

On Tuesday 03 April 2018 04:03 PM, Gustavo Pimentel wrote:
> Hi Kishon,
> 
> On 02/04/2018 06:23, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote:
>>> Changes the IP registers size to accommodate the ATU unroll space.
>>>
>>> Replaces "ctrlreg" reg-name by "dbi" to be coherent with similar drivers.
>>>
>>> Replaces the pcie base address example by a real pcie base address in use.
>>>
>>> Signed-off-by: Gustavo Pimentel 
>>> ---
>>>  Documentation/devicetree/bindings/pci/designware-pcie.txt | 12 ++--
>>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
>>> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>>> index 1da7ade..6300762 100644
>>> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>>> @@ -1,7 +1,8 @@
>>>  * Synopsys DesignWare PCIe interface
>>>  
>>>  Required properties:
>>> -- compatible: should contain "snps,dw-pcie" to identify the core.
>>> +- compatible:
>>> +   "snps,dw-pcie" for RC mode;
>>
>> I think irrespective of RC mode or EP mode, "snps,dw-pcie" can be used to
>> identify the pcie core?
> 
> I guess so. What you suggest? I was just folling the same guideline present
> here: https://lkml.org/lkml/2017/11/3/310

Okay, I think you should have
"snps,dw-pcie-rc", "snps,dw-pcie" for RC mode;

and in the later patch
"snps,dw-pcie-ep", "snps,dw-pcie" for EP mode;

> 
>>>  - reg: Should contain the configuration address space.
>>>  - reg-names: Must be "config" for the PCIe configuration space.
>>>  (The old way of getting the configuration address space from "ranges"
>>> @@ -41,11 +42,11 @@ EP mode:
>>>  
>>>  Example configuration:
>>>  
>>> -   pcie: pcie@d000 {
>>> +   pcie: pcie@dfc0 {
>>> compatible = "snps,dw-pcie";
>>> -   reg = <0xd000 0x1000>, /* Controller registers */
>>> - <0xd000 0x2000>; /* PCI config space */
>>> -   reg-names = "ctrlreg", "config";
>>> +   reg = <0xdfc0 0x302000>, /* IP registers */
>>
>> which version of synopsys IP is this. I think the ideal thing to do here is 
>> to
>> have a separate register space for iATU.
> 
> I also agree with that. The unroll iATU was introduced on Synopsys IP version
> 4.80 and the kernel patch was release on 2016-08-10
> https://patchwork.ozlabs.org/patch/657796/
> However a separate register space for iATU implies some extra code do handle 
> it
> (and of course some tests) that don't fit into this patch series, in my point 
> of
> view. Can this task enter in the backlog in order to be done in another patch
> series?

Yes sure. I think we should also make sure existing binding doesn't break.

Thanks
Kishon

Re: [PATCH 4/8] misc: pci_endpoint_test: Add designware EP entry

[Kishon Vijay Abraham I]

Hi,

On Tuesday 03 April 2018 03:41 PM, Gustavo Pimentel wrote:
> Hi Kishon,
> 
> On 02/04/2018 06:36, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote:
>>> Adds the designware EP device ID entry to pci_endpoint_test driver table
>>> to allow this device to be recognize and handle by the pci_endpoint_test
>>> driver.
>>>
>>> Signed-off-by: Gustavo Pimentel 
>>> ---
>>>  drivers/misc/pci_endpoint_test.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/misc/pci_endpoint_test.c 
>>> b/drivers/misc/pci_endpoint_test.c
>>> index 320276f..e80c533 100644
>>> --- a/drivers/misc/pci_endpoint_test.c
>>> +++ b/drivers/misc/pci_endpoint_test.c
>>> @@ -632,6 +632,7 @@ static void pci_endpoint_test_remove(struct pci_dev 
>>> *pdev)
>>>  static const struct pci_device_id pci_endpoint_test_tbl[] = {
>>> { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
>>> { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
>>> +   { PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS, 0xedda) },
>>
>> Add device ids to include/linux/pci_ids.h and use the macro here.
> 
> Add device id request sent, as soon as I get a positive confirmation from them
> I'll change for the macro. It works for you?

IMO only confirmed device ID's should be used.

Thanks
Kishon

How to get lockref patch merged?

[Andreas Gruenbacher]

Hello,

what's the best way to get the following lockref patch merged? The
maintainers file doesn't list a maintainer. Should we go straight to
Linus? Does one of you want to take it?

We have a gfs2 patch that depends on it.

Thanks,
Andreas

-- Forwarded message --
From: Andreas Gruenbacher 
Date: 29 March 2018 at 14:06
Subject: [PATCH v2 1/2] lockref: Add lockref_put_not_zero
To: cluster-de...@redhat.com
Cc: net...@vger.kernel.org, linux-kernel@vger.kernel.org, NeilBrown
, Thomas Graf , Herbert Xu
, Tom Herbert ,
Andreas Gruenbacher 


Put a lockref unless the lockref is dead or its count would become zero.
This is the same as lockref_put_or_lock except that the lock is never
left held.

Signed-off-by: Andreas Gruenbacher 
---
 include/linux/lockref.h |  1 +
 lib/lockref.c   | 28 
 2 files changed, 29 insertions(+)

diff --git a/include/linux/lockref.h b/include/linux/lockref.h
index 2eac32095113..99f17cc8e163 100644
--- a/include/linux/lockref.h
+++ b/include/linux/lockref.h
@@ -37,6 +37,7 @@ struct lockref {
 extern void lockref_get(struct lockref *);
 extern int lockref_put_return(struct lockref *);
 extern int lockref_get_not_zero(struct lockref *);
+extern int lockref_put_not_zero(struct lockref *);
 extern int lockref_get_or_lock(struct lockref *);
 extern int lockref_put_or_lock(struct lockref *);

diff --git a/lib/lockref.c b/lib/lockref.c
index 47169ed7e964..3d468b53d4c9 100644
--- a/lib/lockref.c
+++ b/lib/lockref.c
@@ -80,6 +80,34 @@ int lockref_get_not_zero(struct lockref *lockref)
 }
 EXPORT_SYMBOL(lockref_get_not_zero);

+/**
+ * lockref_put_not_zero - Decrements count unless count <= 1 before decrement
+ * @lockref: pointer to lockref structure
+ * Return: 1 if count updated successfully or 0 if count would become zero
+ */
+int lockref_put_not_zero(struct lockref *lockref)
+{
+   int retval;
+
+   CMPXCHG_LOOP(
+   new.count--;
+   if (old.count <= 1)
+   return 0;
+   ,
+   return 1;
+   );
+
+   spin_lock(>lock);
+   retval = 0;
+   if (lockref->count > 1) {
+   lockref->count--;
+   retval = 1;
+   }
+   spin_unlock(>lock);
+   return retval;
+}
+EXPORT_SYMBOL(lockref_put_not_zero);
+
 /**
  * lockref_get_or_lock - Increments count unless the count is 0 or dead
  * @lockref: pointer to lockref structure
--
2.14.3

RE: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support

[Razvan Stefanescu]

Hello Andrew,

> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, April 2, 2018 4:45 PM
> To: Ioana Ciornei 
> Cc: Arnd Bergmann ; gregkh
> ; Laurentiu Tudor
> ; Linux Kernel Mailing List  ker...@vger.kernel.org>; Stuart Yoder ; Ruxandra
> Ioana Ciocoi Radulescu ; Razvan Stefanescu
> ; Roy Pledge ;
> Networking 
> Subject: Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
> 
> Hi Ioana
> 
> > The commands listed above are for creating/destroying DPAA2 objects
> > in Management Complex and not for runtime configuration where
> > standard userspace tools are used.
> 
> Please can you explain why this is not just plumbing inside a
> switchdev driver?
> 
> The hardware has a number of physical ports. So on probe, i would
> expect it to create a DPMAC, DPNI, and DPIO for each port, and a linux
> netdev. From then on, standard tools are all that are needed. The
> switchdev driver can create a l2 switch object when the user uses the
> ip link add name br0 type bridge. It can then connect the switch
> object to the DPNI when the user adds an interface to the switch, etc.
> 

I'll chime in as you mentioned switchdev driver. 

DPAA2 offers several object-based abstractions for modeling network
related devices (interfaces, L2 Ethernet switch) or accelerators
(DPSECI - crypto and DPDCEI - compression), the latter not up-streamed yet.
They are modeled using various low-level resources (e.g. queues,
classification tables, physical ports) and have multiple configuration and
interconnectivity options, managed by the Management Complex. 
Resources are limited and they are only used when needed by the objects,
to accommodate more configurations and usage scenarios.
 
Some of the objects have a 1-to-1 correspondence to physical resources
(e.g. DPMACs to physical ports), while others (like DPNIs and DPSW)
can be seen as a collection of the mentioned resources. The types and 
number of such objects are not predetermined.

When the board boots up, none of them exist yet. Restool allows a user to
define the system topology, by providing a way to dynamically create, destroy
and interconnect these objects.

After an object is created, it will be presented on the fsl-mc bus. A driver
is loaded to implement the required kernel interfaces specific to that object
type. Kernel can boot and afterwards the DPAA2 objects are added, as the user
requires.

As you mentioned DPMACs: objects of this type can be connected only to a DPNI
(a network interface like object) or to a DPSW (L2 ethernet switch) port.
Likewise, a DPNI can have only one connection (to a DPMAC, a DPSW port or
another DPNI object).

Here's several examples of valid connection types:
  * DPMAC <> DPNI (standard network i/f corresponding to a physical port)
  * DPMAC <> DPSW (physical port in a switch)
  * DPNI <> DPSW (virtual network interface connected to a switch port)
  * DPNI <> DPNI

In the latter case, the two DPNIs will not be connected to any physical
port, but can be used as a point-to-point connection between two virtual
machines for instance.

So, it is not possible to connect a DPNI to a DPSW after it was connected
to a DPMAC. The DPNI-DPMAC pair would have to be disconnected and
DPMAC will be reconnected to the switch. DPNI interface that is no longer
connected to a DPMAC will be destroyed and any new addition/deletion of
a DPNI/DPMAC interface to the switch port will trigger the entire switch
re-configuration.

Best regards,
Razvan Stefanescu

Re: [PATCH] genirq: only scan the present CPUs

[Peter Zijlstra]

On Tue, Apr 03, 2018 at 12:25:56PM +0200, Thomas Gleixner wrote:
> On Mon, 2 Apr 2018, Li RongQing wrote:
> 
> > lots of application will read /proc/stat, like ps and vmstat, but we
> > find the reading time are spreading on Purley platform which has lots
> > of possible CPUs and interrupt.
> > 
> > To reduce the reading time, only scan the present CPUs, not all possible
> > CPUs, which speeds the reading of /proc/stat 20 times on Purley platform
> > which has 56 present CPUs, and 224 possible CPUs
> 
> Why is BIOS/ACPI telling the kernel that there are 224 possible CPUs unless
> it supports physical CPU hotplug.

BIOS is crap, news at 11. I've got boxes like that too. Use
possible_cpu=$nr if you're bothered by it -- it's what I do.

[PATCH v6 RESEND 1/1] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].

Driver limitations:
 1. Only primary plane without additional properties is supported.
 2. Only one video mode supported which resolution is configured
via XenStore.
 3. All CRTCs operate at fixed frequency of 60Hz.

1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.

2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
  - read connector(s) configuration
  - read buffer allocation mode (backend/frontend)

3. Handle Xen event channels:
  - create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
  - implement event channels interrupt handlers
  - create and destroy event channels with respect to Xen bus state

4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
  - handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
  page directory
  - allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
  - grant references to the required set of pages for the
shared buffer itself
  - implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)

5. Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:

- implement KMS part of the driver with the help of DRM
  simple pipepline helper which is possible due to the fact
  that the para-virtualized driver only supports a single
  (primary) plane:
  - initialize connectors according to XenStore configuration
  - handle frame done events from the backend
  - create and destroy frame buffers and propagate those
to the backend
  - propagate set/reset mode configuration to the backend on display
enable/disable callbacks
  - send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback

- implement virtual connector handling:
  - support only pixel formats suitable for single plane modes
  - make sure the connector is always connected
  - support a single video mode as per para-virtualized driver
configuration

6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment,
namely requirements dictated by the accompanying DRM/(v)GPU drivers
running in both host and guest environments, number of operating
modes of para-virtualized display driver are supported:
 - display buffers can be allocated by either
   frontend driver or backend
 - display buffers can be allocated to be contiguous
   in memory or not

Note! Frontend driver itself has no dependency on contiguous memory for
its operation.

6.1. Buffers allocated by the frontend driver.

The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.

6.1.1. Front driver configured to use GEM CMA helpers
 This use-case is useful when used with accompanying DRM/vGPU driver
 in guest domain which was designed to only work with contiguous
 buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can
 only import contiguous PRIME buffers, thus requiring frontend driver
 to provide such. In order to implement this mode of operation
 para-virtualized frontend driver can be configured to use
 GEM CMA helpers.

6.1.2. Front driver doesn't use GEM CMA
 If accompanying drivers can cope with non-contiguous memory then, to
 lower pressure on CMA subsystem of the kernel, driver can allocate
 buffers from system memory.

Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.

6.2. Buffers allocated by the backend

This mode of operation is run-time configured via guest domain
configuration through XenStore entries.

For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting physically contiguous memory, this allows implementing
zero-copying use-cases.

Note, while using this scenario the 

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

[Sergey Suloev]

On 04/03/2018 02:40 PM, Maxime Ripard wrote:

On Tue, Apr 03, 2018 at 02:08:43PM +0300, Sergey Suloev wrote:

On 04/03/2018 11:10 AM, Maxime Ripard wrote:

On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote:

There is no need to handle 3/4 empty/full interrupts as the maximum
supported transfer length in PIO mode is 64 bytes for sun4i-family
SoCs.

That assumes that you'll be able to treat the FIFO full interrupt and
drain the FIFO before we have the next byte coming in. This would
require a real time system, and we're not in one of them.

AFAIK in SPI protocol we send and receive at the same time.

It depends. The protocol allows it yes, but most devices I've seen can
only operate in half duplex. But it's not really the point.


As soon as the transfer length is <= FIFO depth then it means that
at the moment we get TC interrupt all data for this transfer
sent/received already.

Is your point here that draining FIFO might be a long operation and we can
lose next portion of data ?

My point is that, if you get another interrupt(s) right before the
FIFO full interrupt, that interrupt is going to be masked for as long
as it is needed for the previous handler(s) to execute.

If you're having another byte received while the interrupt is masked,
you're losing data.

Maxime



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


ok, I am going to put back 3/4 full handler then.

[GIT pull] time(r) updates for 4.17

[Thomas Gleixner]

Linus,

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

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

A small set of updates for timers and timekeeping:

 - The most interesting change is the consolidation of clock MONOTONIC and
   clock BOOTTIME. Clock MONOTONIC behaves now exactly like clock BOOTTIME
   and does not longer ignore the time spent in suspend. A new clock
   MONOTONIC_ACTIVE is provived which behaves like clock MONOTONIC in
   kernels before this change. This allows applications to
   programmatically check for the clock MONOTONIC behaviour.

   As discussed in the review thread, this has the potential of breaking
   user space and we might have to revert this. Knock on wood that we can
   avoid that exercise.

 - Updates to the NTP mechanism to improve accuracy

 - A new kernel internal data structure to aid the ongoing Y2038 work.

 - Cleanups and simplifications of the clocksource code.

 - Make the alarmtimer code play nicely with debugobjects.

Thanks,

tglx

-->
Arnd Bergmann (1):
  y2038: Introduce struct __kernel_old_timeval

Baolin Wang (3):
  clocksource: Don't walk the clocksource list for empty override
  clocksource: Use DEVICE_ATTR_RW/RO/WO to define device attributes
  clocksource: Use ATTRIBUTE_GROUPS

Miroslav Lichvar (2):
  timekeeping/ntp: Don't align NTP frequency adjustments to ticks
  timekeeping/ntp: Determine the multiplier directly from NTP tick length

Thomas Gleixner (8):
  timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
  timekeeping: Make the MONOTONIC clock behave like the BOOTTIME clock
  Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
  timekeeping: Remove boot time specific code
  posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
  hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
  tracing: Unify the "boot" and "mono" tracing clocks
  alarmtimer: Init nanosleep alarm timer on stack


 Documentation/trace/ftrace.txt  |  14 +--
 drivers/input/evdev.c   |   7 +-
 include/linux/hrtimer.h |   2 -
 include/linux/time32.h  |   1 +
 include/linux/timekeeper_internal.h |   4 +
 include/linux/timekeeping.h |  37 ++
 include/uapi/linux/time.h   |  13 +++
 kernel/time/alarmtimer.c|  34 --
 kernel/time/clocksource.c   |  66 +--
 kernel/time/hrtimer.c   |  16 +--
 kernel/time/posix-stubs.c   |   2 +
 kernel/time/posix-timers.c  |  26 ++---
 kernel/time/tick-common.c   |  15 +++
 kernel/time/tick-internal.h |   6 +
 kernel/time/tick-sched.c|   9 ++
 kernel/time/time.c  |  12 ++
 kernel/time/timekeeping.c   | 219 +++-
 kernel/time/timekeeping.h   |   1 -
 kernel/trace/trace.c|   2 +-
 19 files changed, 234 insertions(+), 252 deletions(-)

diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index d4601df6e72e..bf89f98bfdb9 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -449,17 +449,9 @@ of ftrace. Here is a list of some of the key files:
which is montonic but is not subject to any rate adjustments
and ticks at the same rate as the hardware clocksource.
 
- boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the
-   fast monotonic clock, but also accounts for time spent in
-   suspend. Since the clock access is designed for use in
-   tracing in the suspend path, some side effects are possible
-   if clock is accessed after the suspend time is accounted before
-   the fast mono clock is updated. In this case, the clock update
-   appears to happen slightly sooner than it normally would have.
-   Also on 32-bit systems, it's possible that the 64-bit boot 
offset
-   sees a partial update. These effects are rare and post
-   processing should be able to handle them. See comments in the
-   ktime_get_boot_fast_ns() function for more information.
+ boot: Same as mono. Used to be a separate clock which accounted
+   for the time spent in suspend while CLOCK_MONOTONIC did
+   not.
 
To set a clock, simply echo the clock name into this file.
 
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index c81c79d01d93..46115a392098 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -31,7 +31,6 @@
 enum evdev_clock_type {
EV_CLK_REAL = 0,
EV_CLK_MONO,
-   EV_CLK_BOOT,
EV_CLK_MAX
 };
 
@@ -198,12 +197,10 @@ static int evdev_set_clk_type(struct evdev_client 
*client, unsigned int clkid)
case CLOCK_REALTIME:
clk_type = EV_CLK_REAL;
break;
+   case 

Re: [PATCH v1] kernel/trace:check the val against the available mem

[Michal Hocko]

On Tue 03-04-18 07:51:58, Steven Rostedt wrote:
> On Tue, 3 Apr 2018 13:06:12 +0200
> Michal Hocko  wrote:
> 
> > > I wonder if I should have the ring buffer allocate groups of pages, to
> > > avoid this. Or try to allocate with NORETRY, one page at a time, and
> > > when that fails, allocate groups of pages with RETRY_MAYFAIL, and that
> > > may keep it from causing an OOM?  
> > 
> > I wonder why it really matters. The interface is root only and we expect
> > some sanity from an admin, right? So allocating such a large ring buffer
> > that it sends the system to the OOM is a sign that the admin should be
> > more careful. Balancing on the OOM edge is always a risk and the result
> > will highly depend on the workload running in parallel.
> 
> This came up because there's scripts or programs that set the size of
> the ring buffer. The complaint was that the application would just set
> the size to something bigger than what was available and cause an OOM
> killing other applications. The final solution is to simply check the
> available memory before allocating the ring buffer:
> 
>   /* Check if the available memory is there first */
>   i = si_mem_available();
>   if (i < nr_pages)
>   return -ENOMEM;
> 
> And it works well.

Except that it doesn't work. si_mem_available is not really suitable for
any allocation estimations. Its only purpose is to provide a very rough
estimation for userspace. Any other use is basically abuse. The
situation can change really quickly. Really it is really hard to be
clever here with the volatility the memory allocations can cause.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

[Lorenzo Pieralisi]

On Mon, Apr 02, 2018 at 09:37:03PM +0200, Niklas Cassel wrote:
> On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> > 
> > On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote:
> > > Since a 64-bit BAR consists of a BAR pair, we need to write to both
> > > BARs in the BAR pair to setup the BAR properly.
> > > 
> > > Signed-off-by: Niklas Cassel 
> > > ---
> > >  drivers/pci/dwc/pcie-designware-ep.c | 11 +--
> > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> > > b/drivers/pci/dwc/pcie-designware-ep.c
> > > index 5a0bb53c795c..571b90f88d84 100644
> > > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > > @@ -138,8 +138,15 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, 
> > > u8 func_no,
> > >   return ret;
> > >  
> > >   dw_pcie_dbi_ro_wr_en(pci);
> > > - dw_pcie_writel_dbi2(pci, reg, size - 1);
> > > - dw_pcie_writel_dbi(pci, reg, flags);
> > > + if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > > + dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
> > > + dw_pcie_writel_dbi(pci, reg, flags);
> > > + dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
> > > + dw_pcie_writel_dbi(pci, reg + 4, 0);
> > > + } else {
> > > + dw_pcie_writel_dbi2(pci, reg, size - 1);
> > > + dw_pcie_writel_dbi(pci, reg, flags);
> > > + }
> > 
> > 
> > I think this should work too?
> > dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
> > dw_pcie_writel_dbi(pci, reg, flags);
> > 
> > if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
> > dw_pcie_writel_dbi(pci, reg + 4, 0);
> > }
> > 
> 
> Hello Kishon,
> 
> I agree, your suggestion is more neat.
> 
> 
> Kishon, please tell me if you insist that the long if-statement
> in pci_epc_set_bar() should be split, since there are 5 different
> conditions. Because imho, having 5 succeeding if-statements isn't
> clearer than having 1 long if-statement.
> 
> If Kishon agrees with me, then the review comment in this mail
> seems to be the only review comment.
> And in that case, perhaps Lorenzo wouldn't mind fixing this up.
> Or perhaps Lorenzo prefers if I reroll the whole patch series?

I updated it myself in my pci/endpoint branch, please have a look, I
can't guarantee we can merge this for this cycle though, I will ask
Bjorn; apologies I could not be online for a while.

Lorenzo

> Kind regards,
> Niklas

Re: [PATCH v2 2/2] io: prevent compiler reordering on the default readX() implementation

[Sinan Kaya]

On 4/3/2018 8:56 AM, Arnd Bergmann wrote:
> On Tue, Apr 3, 2018 at 2:44 PM, Sinan Kaya  wrote:
>> On 4/3/2018 7:13 AM, Arnd Bergmann wrote:
>>> On Tue, Apr 3, 2018 at 12:49 PM, Mark Rutland  wrote:
 Hi,

 On Fri, Mar 30, 2018 at 11:58:13AM -0400, Sinan Kaya wrote:
> The default implementation of mapping readX() to __raw_readX() is wrong.
> readX() has stronger ordering semantics. Compiler is allowed to reorder
> __raw_readX().

 Could you please specify what the compiler is potentially reordering
 __raw_readX() against, and why this would be wrong?

 e.g. do we care about prior normal memory accesses, subsequent normal
 memory accesses, and/or other IO accesses?

 I assume that the asm-generic __raw_{read,write}X() implementations are
 all ordered w.r.t. each other (at least for a specific device).
>>>
>>> I think that is correct: the compiler won't reorder those because of the
>>> 'volatile' pointer dereference, but it can reorder access to a normal
>>> pointer against a __raw_readl()/__raw_writel(), which breaks the scenario
>>> of using writel to trigger a DMA, or using a readl to see if a DMA has
>>> completed.
>>
>> Yes, we are worried about memory update vs. IO update ordering here.
>> That was the reason why barrier() was introduced in this patch. I'll try to
>> clarify that better in the commit text.
>>
>>>
>>> The question is whether we should use a stronger barrier such
>>> as rmb() amd wmb() here rather than a simple compiler barrier.
>>>
>>> I would assume that on complex architectures with write buffers and
>>> out-of-order prefetching, those are required, while on architectures
>>> without those features, the barriers are cheap.
>>
>> That's my reasoning too. I'm trying to follow the x86 example here where 
>> there
>> is a compiler barrier in writeX() and readX() family of functions.
> 
> I think x86 is the special case here because it implicitly guarantees
> the strict ordering in the hardware, as long as the compiler gets it
> right. For the asm-generic version, it may be better to play safe and
> do the safest version, requiring architectures to override that barrier
> if they want to be faster.
> 
> We could use the same macros that riscv has, using __io_br(),
> __io_ar(), __io_bw() and __io_aw() for before/after read/write.

Sure, let me take a stab at it. 

> 
>   Arnd
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH v5 12/13] ARM: sun8i: smp: Add support for A83T

[Chen-Yu Tsai]

On Tue, Apr 3, 2018 at 2:18 PM, Mylène Josserand
 wrote:
> Add the support for A83T.
>
> A83T SoC has an additional register than A80 to handle CPU configurations:
> R_CPUS_CFG. Information about the register comes from Allwinner's BSP
> driver.
> An important difference is the Power Off Gating register for clusters
> which is BIT(4) in case of SUN9I-A80 and BIT(0) in case of SUN8I-A83T.
> There is also a bit swap between sun8i-a83t and sun9i-a80 that must be
> handled.
>
> Signed-off-by: Mylène Josserand 
> ---
>  arch/arm/mach-sunxi/mc_smp.c | 120 
> +--
>  1 file changed, 117 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> index 468a6c46bfc9..72e497dc43ac 100644
> --- a/arch/arm/mach-sunxi/mc_smp.c
> +++ b/arch/arm/mach-sunxi/mc_smp.c
> @@ -55,22 +55,31 @@
>  #define CPUCFG_CX_RST_CTRL_L2_RST  BIT(8)
>  #define CPUCFG_CX_RST_CTRL_CX_RST(n)   BIT(4 + (n))
>  #define CPUCFG_CX_RST_CTRL_CORE_RST(n) BIT(n)
> +#define CPUCFG_CX_RST_CTRL_CORE_RST_ALL(0xf << 0)
>
>  #define PRCM_CPU_PO_RST_CTRL(c)(0x4 + 0x4 * (c))
>  #define PRCM_CPU_PO_RST_CTRL_CORE(n)   BIT(n)
>  #define PRCM_CPU_PO_RST_CTRL_CORE_ALL  0xf
>  #define PRCM_PWROFF_GATING_REG(c)  (0x100 + 0x4 * (c))
> +/* The power off register for clusters are different from a80 and a83t */
> +#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN8I   BIT(0)
>  #define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I   BIT(4)
>  #define PRCM_PWROFF_GATING_REG_CORE(n) BIT(n)
>  #define PRCM_PWR_SWITCH_REG(c, cpu)(0x140 + 0x10 * (c) + 0x4 * (cpu))
>  #define PRCM_CPU_SOFT_ENTRY_REG0x164
>
> +/* R_CPUCFG registers, specific to SUN8I */

You should mention it as A83T specific, since sun8i covers the
entire Cortex-A7-based SoC family.

> +#define R_CPUCFG_CLUSTER_PO_RST_CTRL(c)(0x30 + (c) * 0x4)
> +#define R_CPUCFG_CLUSTER_PO_RST_CTRL_CORE(n)   BIT(n)
> +#define R_CPUCFG_CPU_SOFT_ENTRY_REG0x01a4
> +
>  #define CPU0_SUPPORT_HOTPLUG_MAGIC00xFA50392F
>  #define CPU0_SUPPORT_HOTPLUG_MAGIC10x790DCA3A
>
>  static void __iomem *cpucfg_base;
>  static void __iomem *prcm_base;
>  static void __iomem *sram_b_smp_base;
> +static void __iomem *r_cpucfg_base;
>  static int index;
>
>  /*
> @@ -81,6 +90,7 @@ struct sunxi_mc_smp_nodes {
> struct device_node *prcm_node;
> struct device_node *cpucfg_node;
> struct device_node *sram_node;
> +   struct device_node *r_cpucfg_node;
>  };
>
>  /* This structure holds SoC-specific bits tied to an enable-method string. */
> @@ -94,6 +104,7 @@ extern void sunxi_mc_smp_secondary_startup(void);
>  extern void sunxi_mc_smp_resume(void);
>
>  static int __init sun9i_a80_get_smp_nodes(struct sunxi_mc_smp_nodes *nodes);
> +static int __init sun8i_a83t_get_smp_nodes(struct sunxi_mc_smp_nodes *nodes);
>
>  static const struct sunxi_mc_smp_data sunxi_mc_smp_data[] __initconst = {
> {
> @@ -101,6 +112,11 @@ static const struct sunxi_mc_smp_data 
> sunxi_mc_smp_data[] __initconst = {
> .get_smp_nodes  = sun9i_a80_get_smp_nodes,
> .is_sun9i   = true,
> },
> +   {
> +   .enable_method  = "allwinner,sun8i-a83t-smp",
> +   .get_smp_nodes  = sun8i_a83t_get_smp_nodes,
> +   .is_sun9i   = false,
> +   },
>  };
>
>  static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
> @@ -188,6 +204,16 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned 
> int cluster)
> reg &= ~PRCM_CPU_PO_RST_CTRL_CORE(cpu);
> writel(reg, prcm_base + PRCM_CPU_PO_RST_CTRL(cluster));
>
> +   if (r_cpucfg_base) {

Please check against is_sun9i, since this is A83T specific. My point
is we should be able to see clearly what parts of the code are shared,
and what parts are SoC specific.

> +   /* assert cpu power-on reset */
> +   reg  = readl(r_cpucfg_base +
> +R_CPUCFG_CLUSTER_PO_RST_CTRL(cluster));
> +   reg &= ~(R_CPUCFG_CLUSTER_PO_RST_CTRL_CORE(cpu));
> +   writel(reg, r_cpucfg_base +
> +  R_CPUCFG_CLUSTER_PO_RST_CTRL(cluster));
> +   udelay(10);
> +   }
> +
> /* Cortex-A7: hold L1 reset disable signal low */
> if (!sunxi_core_is_cortex_a15(cpu, cluster)) {
> reg = readl(cpucfg_base + CPUCFG_CX_CTRL_REG0(cluster));
> @@ -211,17 +237,38 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned 
> int cluster)
> /* open power switch */
> sunxi_cpu_power_switch_set(cpu, cluster, true);
>
> +   /* Handle A83T bit swap */
> +   if (!sunxi_mc_smp_data[index].is_sun9i) {
> +   if (cpu == 0)
> +   cpu = 4;
> +   }
> +
> /* clear processor power gate */
> reg = readl(prcm_base + 

Re: [PATCH 2/2] reset: uniphier: add SATA reset control support and change SATA-PHY ID

[Philipp Zabel]

On Tue, 2018-04-03 at 17:35 +0900, Masahiro Yamada wrote:
> 2018-04-03 17:18 GMT+09:00 Philipp Zabel :
> > On Fri, 2018-03-30 at 18:44 +0900, Kunihiko Hayashi wrote:
> > > Add reset lines for SATA controller on UniPhier SoCs.
> > > This adds support for Pro4 and PXs3 in addition to PXs2.
> > > 
> > > And this changes the ID of the reset line for SATA-PHY on PXs2.
> > > Since some SoCs have two controller instances with a common PHY, this 
> > > moves
> > > the ID of SATA-PHY for consistency.
> > > 
> > > Signed-off-by: Kunihiko Hayashi 
> > > ---
> > >  drivers/reset/reset-uniphier.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/reset/reset-uniphier.c 
> > > b/drivers/reset/reset-uniphier.c
> > > index 55ae0f1..90e6caf 100644
> > > --- a/drivers/reset/reset-uniphier.c
> > > +++ b/drivers/reset/reset-uniphier.c
> > > @@ -63,6 +63,9 @@ static const struct uniphier_reset_data 
> > > uniphier_pro4_sys_reset_data[] = {
> > >   UNIPHIER_RESETX(12, 0x2000, 6), /* GIO (Ether, SATA, USB3) 
> > > */
> > >   UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
> > >   UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
> > > + UNIPHIER_RESETX(28, 0x2000, 18),/* SATA0 */
> > > + UNIPHIER_RESETX(29, 0x2004, 18),/* SATA1 */
> > > + UNIPHIER_RESETX(30, 0x2000, 19),/* SATA-PHY */
> > >   UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
> > >   UNIPHIER_RESET_END,
> > >  };
> > > @@ -90,7 +93,7 @@ static const struct uniphier_reset_data 
> > > uniphier_pxs2_sys_reset_data[] = {
> > >   UNIPHIER_RESETX(20, 0x2014, 5), /* USB31-PHY0 */
> > >   UNIPHIER_RESETX(21, 0x2014, 1), /* USB31-PHY1 */
> > >   UNIPHIER_RESETX(28, 0x2014, 12),/* SATA */
> > > - UNIPHIER_RESET(29, 0x2014, 8),  /* SATA-PHY (active high) */
> > > + UNIPHIER_RESET(30, 0x2014, 8),  /* SATA-PHY (active high) */
> > 
> > This is a backwards incompatible change.
> > There is no DT in use that relies on this being 29 ?
> 
> 
> Right.  No user for this reset line ever.

Thank you, I have applied both patches to reset/next.

regards
Philipp

Re: [PATCH v5 10/13] ARM: sun9i: smp: Move structures

[Maxime Ripard]

On Tue, Apr 03, 2018 at 08:18:33AM +0200, Mylène Josserand wrote:
> To prepare the support for sun8i-a83t, move some structures
> at the beginning of the file.
> 
> Signed-off-by: Mylène Josserand 

I'm not quite sure what would be the benefit from that, if it's was
working before, then it would probably work in your case as welle, right?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

[Pavel Machek]

Hi!

> > On Tue, 20 Mar 2018, Ingo Molnar wrote:
> > > * Thomas Gleixner  wrote:
> > > 
> > > > > So I do think we could do more in this area to improve driver 
> > > > > performance, if the 
> > > > > code is correct and if there's actual benchmarks that are showing 
> > > > > real benefits.
> > > > 
> > > > If it's about hotpath performance I'm all for it, but the use case here 
> > > > is
> > > > a debug facility...
> > > > 
> > > > And if we go down that road then we want a AVX based memcpy()
> > > > implementation which is runtime conditional on the feature bit(s) and
> > > > length dependent. Just slapping a readqq() at it and use it in a loop 
> > > > does
> > > > not make any sense.
> > > 
> > > Yeah, so generic memcpy() replacement is only feasible I think if the 
> > > most 
> > > optimistic implementation is actually correct:
> > > 
> > >  - if no preempt disable()/enable() is required
> > > 
> > >  - if direct access to the AVX[2] registers does not disturb legacy FPU 
> > > state in 
> > >any fashion
> > > 
> > >  - if direct access to the AVX[2] registers cannot raise weird exceptions 
> > > or have
> > >weird behavior if the FPU control word is modified to non-standard 
> > > values by 
> > >untrusted user-space
> > > 
> > > If we have to touch the FPU tag or control words then it's probably only 
> > > good for 
> > > a specialized API.
> > 
> > I did not mean to have a general memcpy replacement. Rather something like
> > magic_memcpy() which falls back to memcpy when AVX is not usable or the
> > length does not justify the AVX stuff at all.
> 
> OK, fair enough.
> 
> Note that a generic version might still be worth trying out, if and only if 
> it's 
> safe to access those vector registers directly: modern x86 CPUs will do their 
> non-constant memcpy()s via the common memcpy_erms() function - which could in 
> theory be an easy common point to be (cpufeatures-) patched to an AVX2 
> variant, if 
> size (and alignment, perhaps) is a multiple of 32 bytes or so.

How is AVX2 supposed to help the memcpy speed?

If the copy is small, constant overhead will dominate, and I don't
think AVX2 is going to be win there.

If the copy is big, well, the copy loop will likely run out of L1 and
maybe even out of L2, and at that point speed of the loop does not
matter because memory is slow...?

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


signature.asc
Description: Digital signature

Re: [GIT PULL] x86/build changes for v4.17

[Peter Zijlstra]

On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote:
> On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar  wrote:
> >
> > The biggest change is the forcing of asm-goto support on x86, which 
> > effectively
> > increases the GCC minimum supported version to gcc-4.5 (on x86).
> 
> So my biggest worry isn't gcc-4.5 (anybody who hasn't updated deserves
> to be forced, or can stay with old kernels).
> 
> No, my biggest worry is clang. What's the status there?
> 
> I've pulled this, and honestly, the disaster with
> -fmerge-all-constants makes me think that clang isn't that good a
> compiler choice anyway, but it's sad if this undoes a lot of clang
> work just because of the worries about Spectre and mis-speculated
> branches.

It's not just spectre, I believe you yourself wanted to use asm-goto
somewhere in the x86 code:

  
http://lkml.kernel.org/r/CA+55aFyCp-9Qqjcn9wp=vdp2ko7tfyuumjxvkc75xxu0web...@mail.gmail.com

There was some KVM talk of relying on it here:

  http://lkml.kernel.org/r/6a5f2453-cf51-d491-db54-5f239caa2...@redhat.com

And there's the comment here:

  https://elixir.bootlin.com/linux/v4.16-rc7/source/arch/x86/kvm/emulate.c#L457

As to the suitablility of using clang, there's also this unresolved
issue:

  http://lkml.kernel.org/r/20180321211931.ga111...@google.com

The fact that even without asm-goto they cannot correctly compile a
kernel and have sat on their hands regarding asm-goto for the past 7 odd
years makes me care very little.

And since they need to spin a new version of the compiler with all the
various bugs fixed, they might as well include asm-goto in that and be
done with it.

[PATCH] fs: ufs: Convert ufs_set_de_type to use lookup table

[Phillip Potter]

Modify ufs_set_de_type function in fs/ufs/util.h to use a lookup
table rather than a switch statement, as per the TODO comment.

Signed-off-by: Phillip Potter 
---
 fs/ufs/util.h | 50 ++
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/fs/ufs/util.h b/fs/ufs/util.h
index 1907be6d5808..1edf4c6454e3 100644
--- a/fs/ufs/util.h
+++ b/fs/ufs/util.h
@@ -155,37 +155,31 @@ ufs_set_de_namlen(struct super_block *sb, struct 
ufs_dir_entry *de, u16 value)
 static inline void
 ufs_set_de_type(struct super_block *sb, struct ufs_dir_entry *de, int mode)
 {
+   /* type lookup table, DT_UNKNOWN is default type if no case holds */
+   const int mode_table[] = {
+   DT_UNKNOWN,
+   DT_FIFO,/* mode & S_IFMT == S_IFIFO case */
+   DT_CHR, /* mode & S_IFMT == S_IFCHR case */
+   DT_UNKNOWN,
+   DT_DIR, /* mode & S_IFMT == S_IFDIR case */
+   DT_UNKNOWN,
+   DT_BLK, /* mode & S_IFMT == S_IFBLK case */
+   DT_UNKNOWN,
+   DT_REG, /* mode & S_IFMT == S_IFREG case */
+   DT_UNKNOWN,
+   DT_LNK, /* mode & S_IFMT == S_IFLNK case */
+   DT_UNKNOWN,
+   DT_SOCK,/* mode & S_IFMT == S_IFSOCK case */
+   DT_UNKNOWN,
+   DT_UNKNOWN,
+   DT_UNKNOWN
+   };
+
if ((UFS_SB(sb)->s_flags & UFS_DE_MASK) != UFS_DE_44BSD)
return;
 
-   /*
-* TODO turn this into a table lookup
-*/
-   switch (mode & S_IFMT) {
-   case S_IFSOCK:
-   de->d_u.d_44.d_type = DT_SOCK;
-   break;
-   case S_IFLNK:
-   de->d_u.d_44.d_type = DT_LNK;
-   break;
-   case S_IFREG:
-   de->d_u.d_44.d_type = DT_REG;
-   break;
-   case S_IFBLK:
-   de->d_u.d_44.d_type = DT_BLK;
-   break;
-   case S_IFDIR:
-   de->d_u.d_44.d_type = DT_DIR;
-   break;
-   case S_IFCHR:
-   de->d_u.d_44.d_type = DT_CHR;
-   break;
-   case S_IFIFO:
-   de->d_u.d_44.d_type = DT_FIFO;
-   break;
-   default:
-   de->d_u.d_44.d_type = DT_UNKNOWN;
-   }
+   /* shift (mode & S_IFMT) right 12 bits to index into table */
+   de->d_u.d_44.d_type = mode_table[(mode & S_IFMT) >> 12];
 }
 
 static inline u32
-- 
2.14.3

Re: [PATCH v5 08/13] ARM: sunxi: Add initialization of CNTVOFF

[Maxime Ripard]

On Tue, Apr 03, 2018 at 08:18:31AM +0200, Mylène Josserand wrote:
> Add the initialization of CNTVOFF for sun8i-a83t.
> 
> For boot CPU, Create a new machine that handles this
> function's call in an "init_early" callback.
> For secondary CPUs, add this function into secondary_startup
> assembly entry.
> 
> Signed-off-by: Mylène Josserand 
> ---
>  arch/arm/mach-sunxi/headsmp.S |  1 +
>  arch/arm/mach-sunxi/sunxi.c   | 18 +-
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
> index 79890fbe5613..b586b7cf803a 100644
> --- a/arch/arm/mach-sunxi/headsmp.S
> +++ b/arch/arm/mach-sunxi/headsmp.S
> @@ -71,6 +71,7 @@ ENDPROC(sunxi_mc_smp_cluster_cache_enable)
>  
>  ENTRY(sunxi_mc_smp_secondary_startup)
>   bl  sunxi_mc_smp_cluster_cache_enable
> + bl  smp_init_cntvoff
>   b   secondary_startup
>  ENDPROC(sunxi_mc_smp_secondary_startup)
>  
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index 5e9602ce1573..090784108c0a 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -16,6 +16,7 @@
>  #include 
>  
>  #include 
> +#include 
>  
>  static const char * const sunxi_board_dt_compat[] = {
>   "allwinner,sun4i-a10",
> @@ -62,7 +63,6 @@ MACHINE_END
>  static const char * const sun8i_board_dt_compat[] = {
>   "allwinner,sun8i-a23",
>   "allwinner,sun8i-a33",
> - "allwinner,sun8i-a83t",
>   "allwinner,sun8i-h2-plus",
>   "allwinner,sun8i-h3",
>   "allwinner,sun8i-r40",
> @@ -75,6 +75,22 @@ DT_MACHINE_START(SUN8I_DT, "Allwinner sun8i Family")
>   .dt_compat  = sun8i_board_dt_compat,
>  MACHINE_END
>  
> +void __init sun8i_cntvoff_init(void)
> +{
> + smp_init_cntvoff();

Can't this be moved to the SMP setup code?

> +}
> +
> +static const char * const sun8i_cntvoff_board_dt_compat[] = {
> + "allwinner,sun8i-a83t",
> + NULL,
> +};
> +
> +DT_MACHINE_START(SUN8I_CNTVOFF_DT, "Allwinner sun8i boards needing cntvoff")

All of the SoCs need CNTVOFF, so that doesn't really make sense. Why
not just calling it for what it is: an A83t?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v3] scsi: Introduce sdev_printk_ratelimited to throttle frequent printk

[Jason Yan]

On 2018/4/3 14:04, Wen Yang wrote:

There would be so many same lines printed by frequent printk if one
disk went wrong, like,
[  546.185242] sd 0:1:0:0: rejecting I/O to offline device
[  546.185258] sd 0:1:0:0: rejecting I/O to offline device
[  546.185280] sd 0:1:0:0: rejecting I/O to offline device
[  546.185307] sd 0:1:0:0: rejecting I/O to offline device
[  546.185334] sd 0:1:0:0: rejecting I/O to offline device
[  546.185364] sd 0:1:0:0: rejecting I/O to offline device
[  546.185390] sd 0:1:0:0: rejecting I/O to offline device
[  546.185410] sd 0:1:0:0: rejecting I/O to offline device
For slow serial console, the frequent printk may be blocked for a
long time, and if any spin_lock has been acquired before the printk
like in scsi_request_fn, watchdog could be triggered.

Related disscussion can be found here,
https://bugzilla.kernel.org/show_bug.cgi?id=199003
And Petr brought the idea to throttle the frequent printk, it's
useless to print the same lines frequently after all.

v2: fix some typos
v3: limit the print only for the same device

Suggested-by: Petr Mladek
Suggested-by: Sergey Senozhatsky
Signed-off-by: Wen Yang
Signed-off-by: Jiang Biao
Signed-off-by: Tan Hu
Reviewed-by: Bart Van Assche
CC: BartVanAssche
CC: Petr Mladek
CC: Sergey Senozhatsky
CC: Martin K. Petersen
CC: "James E.J. Bottomley"
CC: Tejun Heo
CC: JasonYan


In my machine it works fine.

Tested-by: Jason Yan 

[PATCH v5 2/3] lib: Rename compiler intrinsic selects to GENERIC_LIB_*

[Matt Redfearn]

When these are included into arch Kconfig files, maintaining
alphabetical ordering of the selects means these get split up. To allow
for keeping things tidier and alphabetical, rename the selects to
GENERIC_LIB_*

Signed-off-by: Matt Redfearn 
Reviewed-by: Palmer Dabbelt 

---

Changes in v5: None
Changes in v4:
Rename Kconfig symbols GENERIC_* -> GENERIC_LIB_*

Changes in v3: None
Changes in v2: None

 arch/riscv/Kconfig |  6 +++---
 lib/Kconfig| 12 ++--
 lib/Makefile   | 12 ++--
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 04807c7f64cc..20185aaaf933 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -104,9 +104,9 @@ config ARCH_RV32I
bool "RV32I"
select CPU_SUPPORTS_32BIT_KERNEL
select 32BIT
-   select GENERIC_ASHLDI3
-   select GENERIC_ASHRDI3
-   select GENERIC_LSHRDI3
+   select GENERIC_LIB_ASHLDI3
+   select GENERIC_LIB_ASHRDI3
+   select GENERIC_LIB_LSHRDI3
 
 config ARCH_RV64I
bool "RV64I"
diff --git a/lib/Kconfig b/lib/Kconfig
index e96089499371..e54ebe00937e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -588,20 +588,20 @@ config STRING_SELFTEST
 
 endmenu
 
-config GENERIC_ASHLDI3
+config GENERIC_LIB_ASHLDI3
bool
 
-config GENERIC_ASHRDI3
+config GENERIC_LIB_ASHRDI3
bool
 
-config GENERIC_LSHRDI3
+config GENERIC_LIB_LSHRDI3
bool
 
-config GENERIC_MULDI3
+config GENERIC_LIB_MULDI3
bool
 
-config GENERIC_CMPDI2
+config GENERIC_LIB_CMPDI2
bool
 
-config GENERIC_UCMPDI2
+config GENERIC_LIB_UCMPDI2
bool
diff --git a/lib/Makefile b/lib/Makefile
index a90d4fcd748f..7425e177f08c 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -253,9 +253,9 @@ obj-$(CONFIG_SBITMAP) += sbitmap.o
 obj-$(CONFIG_PARMAN) += parman.o
 
 # GCC library routines
-obj-$(CONFIG_GENERIC_ASHLDI3) += ashldi3.o
-obj-$(CONFIG_GENERIC_ASHRDI3) += ashrdi3.o
-obj-$(CONFIG_GENERIC_LSHRDI3) += lshrdi3.o
-obj-$(CONFIG_GENERIC_MULDI3) += muldi3.o
-obj-$(CONFIG_GENERIC_CMPDI2) += cmpdi2.o
-obj-$(CONFIG_GENERIC_UCMPDI2) += ucmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_ASHLDI3) += ashldi3.o
+obj-$(CONFIG_GENERIC_LIB_ASHRDI3) += ashrdi3.o
+obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o
+obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o
+obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
-- 
2.7.4

Re: general protection fault in __mem_cgroup_free

[Michal Hocko]

On Tue 03-04-18 11:37:33, Michal Hocko wrote:
> [CC Andrey]
> 
> On Sat 31-03-18 13:47:05, syzbot wrote:
> > Hello,
> > 
> > syzbot hit the following crash on upstream commit
> > 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
> > Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client
> > syzbot dashboard link:
> > https://syzkaller.appspot.com/bug?extid=8a5de3cce7cdc70e9ebe
> > 
> > So far this crash happened 14 times on upstream.
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5578311367393280
> > syzkaller reproducer:
> > https://syzkaller.appspot.com/x/repro.syz?id=5708657048158208
> > Raw console output:
> > https://syzkaller.appspot.com/x/log.txt?id=6693821748346880
> > Kernel config:
> > https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
> > compiler: gcc (GCC) 7.1.1 20170620
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
> > 
> > RBP: 006dcc20 R08: 0002 R09: 3335
> > R10:  R11: 0246 R12: 0030656c69662f2e
> > R13: 7f1747954d80 R14:  R15: 0006
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault:  [#1] SMP KASAN
> > Dumping ftrace buffer:
> >(ftrace buffer empty)
> > Modules linked in:
> > CPU: 0 PID: 4422 Comm: syzkaller101598 Not tainted 4.16.0-rc7+ #372
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:free_mem_cgroup_per_node_info mm/memcontrol.c:4111 [inline]
> > RIP: 0010:__mem_cgroup_free+0x71/0x110 mm/memcontrol.c:4120
> 
> Is this a real bug or a KASAN false positive? The RIP points at
> free_percpu(pn->lruvec_stat_cpu);
> 
> Which can be NULL if we are failing to allocate per-node data in
> mem_cgroup_alloc. You stack unwinder seems to point to
> mem_cgroup_css_alloc->mem_cgroup_free though and that one cannot see
> NULL memcg->nodeinfo[node] AFAICS.
> 
> Even if this is really mem_cgroup_alloc path then calling free_percpu
> with NULL pointer should be OK. Or am I missing something?

Scratch that. The bug is real. We can have memcg->nodeinfo[node] =
NULL from mem_cgroup_alloc. It uses the same failure path as the pcp
allocation failure.

This should fix it. I will send the full patch with proper changelog
shortly
---
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e3d5a0a7917f..0a9c4d5194f3 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4340,6 +4340,9 @@ static void free_mem_cgroup_per_node_info(struct 
mem_cgroup *memcg, int node)
 {
struct mem_cgroup_per_node *pn = memcg->nodeinfo[node];
 
+   if (!pn)
+   return;
+
free_percpu(pn->lruvec_stat_cpu);
kfree(pn);
 }
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 3/6] x86/intel_rdt/mba_sc: Add initialization support

[Thomas Gleixner]

On Thu, 29 Mar 2018, Vikas Shivappa wrote:
> +void setup_ctrlval(struct rdt_resource *r, u32 *dc, u32 *dm)
> +{
> + int i;
> +
> + /*
> +  * Initialize the Control MSRs to having no control.
> +  * For Cache Allocation: Set all bits in cbm
> +  * For Memory Allocation: Set b/w requested to 100%
> +  * and the b/w in MB to U32_MAX
> +  */
> + for (i = 0; i < r->num_closid; i++, dc++, dm++) {
> + *dc = r->membw.bw_byte ? MBA_BW_MAX_MB : r->default_ctrl;
> + *dm = r->default_ctrl;

No! Please stop duct taping your stuff into the existing code. So far the
ctrl value was the same as the value which was actually written into the
MSR. With your new mode you have to split that up into the user supplied
value and the value which gets written into the MSR.

So the right thing to do is to separate the user value and the MSR value
first and independent of the mode. Then the new mode falls into place
naturally because r->default_ctrl and r->default_msrval are set up at mount
time with the values which correspond to the mount mode. 

Thanks,

tglx

[PATCH] display: panel: Add AUO g070vvn01 display support (800x480)

[Lukasz Majewski]

This commit adds support for AUO's 7.0" display.

Signed-off-by: Lukasz Majewski 
---
 .../bindings/display/panel/auo,g070vvn01   | 30 +
 drivers/gpu/drm/panel/panel-simple.c   | 31 ++
 2 files changed, 61 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/auo,g070vvn01

diff --git a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01 
b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
new file mode 100644
index ..bd4017362094
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
@@ -0,0 +1,30 @@
+AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,g070vvn01"
+- backlight: phandle of the backlight device attached to the panel
+- power-supply: single regulator to provide the supply voltage
+
+Required nodes:
+- port: Parallel port mapping to connect this display
+
+This panel needs single power supply voltage. Its backlight is conntrolled
+via PWM signal.
+
+Example:
+
+
+Example device-tree definition when connected to iMX6Q based board
+
+   lcd_panel: lcd-panel {
+   compatible = "auo,g070vvn01";
+   backlight = <_lcd>;
+   bus-format-override = "rgb565";
+   power-supply = <_display>;
+
+   port {
+   lcd_panel_in: endpoint {
+   remote-endpoint = <_display_out>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..62314085b635 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -581,6 +581,34 @@ static const struct panel_desc auo_b133htn01 = {
},
 };
 
+static const struct display_timing auo_g070vvn01_timings = {
+   .pixelclock = { 3330, 34209000, 4500 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 20, 40, 200 },
+   .hback_porch = { 87, 40, 1 },
+   .hsync_len = { 1, 48, 87 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 5, 13, 200 },
+   .vback_porch = { 31, 31, 29 },
+   .vsync_len = { 1, 1, 3 },
+};
+
+static const struct panel_desc auo_g070vvn01 = {
+   .timings = _g070vvn01_timings,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .delay = {
+   .prepare = 200,
+   .enable = 50,
+   .disable = 50,
+   .unprepare = 1000,
+   },
+};
+
 static const struct display_timing auo_g133han01_timings = {
.pixelclock = { 13400, 14120, 14900 },
.hactive = { 1920, 1920, 1920 },
@@ -2049,6 +2077,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = _b133xtn01,
}, {
+   .compatible = "auo,g070vvn01",
+   .data = _g070vvn01,
+   }, {
.compatible = "auo,g133han01",
.data = _g133han01,
}, {
-- 
2.11.0

Re: [PATCH] cpufreq: intel_pstate: Do not include debugfs.h

[Viresh Kumar]

On Fri, Mar 30, 2018 at 3:22 PM, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> The intel_pstate driver doesn't use debugfs any more, so drop
> linux/debugfs.h from the list of included headers in it.
>
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/intel_pstate.c |1 -
>  1 file changed, 1 deletion(-)

Acked-by: Viresh Kumar 

Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

[Kirill A. Shutemov]

On Tue, Apr 03, 2018 at 12:58:15PM +0200, Michal Hocko wrote:
> On Tue 03-04-18 13:54:11, Kirill A. Shutemov wrote:
> > On Tue, Apr 03, 2018 at 10:34:51AM +0200, Michal Hocko wrote:
> > > On Tue 03-04-18 08:24:06, Naoya Horiguchi wrote:
> > > > On Tue, Apr 03, 2018 at 09:59:28AM +0200, Michal Hocko wrote:
> > > > > On Tue 03-04-18 13:46:28, Naoya Horiguchi wrote:
> > > > > > My testing for the latest kernel supporting thp migration found out 
> > > > > > an
> > > > > > infinite loop in offlining the memory block that is filled with 
> > > > > > shmem
> > > > > > thps.  We can get out of the loop with a signal, but kernel should
> > > > > > return with failure in this case.
> > > > > >
> > > > > > What happens in the loop is that scan_movable_pages() repeats 
> > > > > > returning
> > > > > > the same pfn without any progress. That's because page migration 
> > > > > > always
> > > > > > fails for shmem thps.
> > > > >
> > > > > Why does it fail? Shmem pages should be movable without any issues.
> > > > 
> > > > .. because try_to_unmap_one() explicitly skips unmapping for migration.
> > > > 
> > > >   #ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
> > > >   /* PMD-mapped THP migration entry */
> > > >   if (!pvmw.pte && (flags & TTU_MIGRATION)) {
> > > >   VM_BUG_ON_PAGE(PageHuge(page) || 
> > > > !PageTransCompound(page), page);
> > > >   
> > > >   if (!PageAnon(page))
> > > >   continue;
> > > >   
> > > >   set_pmd_migration_entry(, page);
> > > >   continue;
> > > >   }
> > > >   #endif
> > > > 
> > > > When I implemented this code, I felt hard to work on both of anon thp
> > > > and shmem thp at one time, so I separated the proposal into smaller 
> > > > steps.
> > > > Shmem uses pagecache so we need some non-trivial effort (including 
> > > > testing)
> > > > to extend thp migration for shmem. But I think it's a reasonable next 
> > > > step.
> > > 
> > > OK, I see. I have forgot about this part. Please be explicit about that
> > > in the changelog. Also the proper fix is to not use movable zone for
> > > shmem page THP rather than hack around it in the hotplug specific code
> > > IMHO.
> > 
> > No. We should just split the page before running
> > try_to_unmap(TTU_MIGRATION) on the page.
> 
> If splitting is a preffered way then I do not have any objection. We
> just cannot keep unmovable objects in the zone movable.

We had anon-thp in movable zone for ages, long before THP migration was
implemented.

-- 
 Kirill A. Shutemov

Re: general protection fault in __mem_cgroup_free

[Andrey Ryabinin]

On 04/03/2018 01:50 PM, Michal Hocko wrote:
> Here we go
> 
> From 38f0f08a3f9f19c106ae53350e43dc97e2e3a4d8 Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Tue, 3 Apr 2018 12:40:41 +0200
> Subject: [PATCH] memcg: fix per_node_info cleanup
> 
> syzbot has triggered a NULL ptr dereference when allocation fault
> injection enforces a failure and alloc_mem_cgroup_per_node_info
> initializes memcg->nodeinfo only half way through. __mem_cgroup_free
> still tries to free all per-node data and dereferences pn->lruvec_stat_cpu
> unconditioanlly even if the specific per-node data hasn't been
> initialized.
> 
> The bug is quite unlikely to hit because small allocations do not fail
> and we would need quite some numa nodes to make struct mem_cgroup_per_node
> large enough to cross the costly order.
> 
> Reported-by: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com
> Fixes: 00f3ca2c2d66 ("mm: memcontrol: per-lruvec stats infrastructure")
> Signed-off-by: Michal Hocko 

Reviewed-by: Andrey Ryabinin 

> ---
>  mm/memcontrol.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index e3d5a0a7917f..0a9c4d5194f3 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4340,6 +4340,9 @@ static void free_mem_cgroup_per_node_info(struct 
> mem_cgroup *memcg, int node)
>  {
>   struct mem_cgroup_per_node *pn = memcg->nodeinfo[node];
>  
> + if (!pn)
> + return;
> +
>   free_percpu(pn->lruvec_stat_cpu);
>   kfree(pn);
>  }
> 

Re: possible deadlock in skb_queue_tail

[Dmitry Vyukov]

On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai  wrote:
> On 02.04.2018 12:20, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on net-next commit
>> 06b19fe9a6df7aaa423cd8404ebe5ac9ec4b2960 (Sun Apr 1 03:37:33 2018 +)
>> Merge branch 'chelsio-inline-tls'
>> syzbot dashboard link: 
>> https://syzkaller.appspot.com/bug?extid=6b495100f17ca8554ab9
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>> Raw console output: 
>> https://syzkaller.appspot.com/x/log.txt?id=6218830443446272
>> Kernel config: https://syzkaller.appspot.com/x/.config?id=3327544840960562528
>> compiler: gcc (GCC) 7.1.1 20170620
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+6b495100f17ca8554...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for details.
>> If you forward the report, please keep this part and the footer.
>>
>>
>> ==
>> WARNING: possible circular locking dependency detected
>> 4.16.0-rc6+ #290 Not tainted
>> --
>> syz-executor7/20971 is trying to acquire lock:
>>  (_unix_sk_receive_queue_lock_key){+.+.}, at: [<271ef0d8>] 
>> skb_queue_tail+0x26/0x150 net/core/skbuff.c:2899
>>
>> but task is already holding lock:
>>  (&(>lock)->rlock/1){+.+.}, at: [<4e725e14>] 
>> unix_state_double_lock+0x7b/0xb0 net/unix/af_unix.c:1088
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #1 (&(>lock)->rlock/1){+.+.}:
>>_raw_spin_lock_nested+0x28/0x40 kernel/locking/spinlock.c:354
>>sk_diag_dump_icons net/unix/diag.c:82 [inline]
>>sk_diag_fill.isra.4+0xa52/0xfe0 net/unix/diag.c:144
>>sk_diag_dump net/unix/diag.c:178 [inline]
>>unix_diag_dump+0x400/0x4f0 net/unix/diag.c:206
>>netlink_dump+0x492/0xcf0 net/netlink/af_netlink.c:2221
>>__netlink_dump_start+0x4ec/0x710 net/netlink/af_netlink.c:2318
>>netlink_dump_start include/linux/netlink.h:214 [inline]
>>unix_diag_handler_dump+0x3e7/0x750 net/unix/diag.c:307
>>__sock_diag_cmd net/core/sock_diag.c:230 [inline]
>>sock_diag_rcv_msg+0x204/0x360 net/core/sock_diag.c:261
>>netlink_rcv_skb+0x14b/0x380 net/netlink/af_netlink.c:2443
>>sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:272
>>netlink_unicast_kernel net/netlink/af_netlink.c:1307 [inline]
>>netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1333
>>netlink_sendmsg+0xa4a/0xe80 net/netlink/af_netlink.c:1896
>>sock_sendmsg_nosec net/socket.c:629 [inline]
>>sock_sendmsg+0xca/0x110 net/socket.c:639
>>sock_write_iter+0x31a/0x5d0 net/socket.c:908
>>call_write_iter include/linux/fs.h:1782 [inline]
>>new_sync_write fs/read_write.c:469 [inline]
>>__vfs_write+0x684/0x970 fs/read_write.c:482
>>vfs_write+0x189/0x510 fs/read_write.c:544
>>SYSC_write fs/read_write.c:589 [inline]
>>SyS_write+0xef/0x220 fs/read_write.c:581
>>do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>>entry_SYSCALL_64_after_hwframe+0x42/0xb7
>>
>> -> #0 (_unix_sk_receive_queue_lock_key){+.+.}:
>>lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
>>__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>>_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
>>skb_queue_tail+0x26/0x150 net/core/skbuff.c:2899
>>unix_dgram_sendmsg+0xa30/0x1610 net/unix/af_unix.c:1807
>>sock_sendmsg_nosec net/socket.c:629 [inline]
>>sock_sendmsg+0xca/0x110 net/socket.c:639
>>___sys_sendmsg+0x320/0x8b0 net/socket.c:2047
>>__sys_sendmmsg+0x1ee/0x620 net/socket.c:2137
>>SYSC_sendmmsg net/socket.c:2168 [inline]
>>SyS_sendmmsg+0x35/0x60 net/socket.c:2163
>>do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>>entry_SYSCALL_64_after_hwframe+0x42/0xb7
>
> sk_diag_dump_icons() dumps only sockets in TCP_LISTEN state.
> TCP_LISTEN state may be assigned in only place in net/unix/af_unix.c:
> it's unix_listen(). The function is applied to stream and seqpacket
> socket types.
>
> It can't be stream because of the second stack, and seqpacket also can't,
> as I don't think it's possible for gcc to inline unix_seqpacket_sendmsg()
> in the way, we don't see it in the stack.
>
> So, this is looks like false positive result for me.
>
> Kirill

Do you mean that these &(>lock)->rlock/1 referenced in 2 stacks are
always different?

+Ingo for lockdep false positive
Do we need some kind of annotation here?


>> other info that might help us debug this:
>>
>>  Possible unsafe locking scenario:
>>
>>CPU0CPU1
>>
>>   lock(&(>lock)->rlock/1);
>>

Re: [PATCH v3 01/14] KVM: s390: refactor crypto initialization

[Cornelia Huck]

On Thu, 29 Mar 2018 14:57:22 -0400
Tony Krowiak  wrote:

> On 03/26/2018 04:44 AM, Cornelia Huck wrote:
> > On Thu, 15 Mar 2018 15:55:39 +0100
> > Pierre Morel  wrote:
> >  
> >> On 15/03/2018 15:48, Tony Krowiak wrote:  
> >>> On 03/15/2018 08:26 AM, Pierre Morel wrote:  
>  On 14/03/2018 19:25, Tony Krowiak wrote:  
> > diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig
> > index a3dbd45..4ca9077 100644
> > --- a/arch/s390/kvm/Kconfig
> > +++ b/arch/s390/kvm/Kconfig
> > @@ -33,6 +33,7 @@ config KVM
> >select HAVE_KVM_INVALID_WAKEUPS
> >select SRCU
> >select KVM_VFIO
> > +select ZCRYPT  
>  I do not think it is a good solution to *always* enable ZCRYPT
>  when we have KVM.  
> >>> If CONFIG_ZCRYPT is not selected, then the kvm_ap_apxa_installed()
> >>> function will not compile
> >>> because it calls a zcrypt interface. How would you suggest we make
> >>> sure zcrypt interfaces
> >>> used in KVM are built if CONFIG_ZCRYPT is not selected?  
> >> if zcrypt is not configured, I suppose that the KVM code initializaing 
> >> CRYCB
> >> has no use but the function will be called from KVM.
> >> So I would do something like:
> >>
> >> #ifdef ZCRYPT
> >> external definitions.
> >> #else
> >> stubs returning error -ENOZCRYPT (or whatever)
> >> #endif  
> > The kvm code used some kind of detection for crycb before (IIRC it was
> > for the key-wrapping stuff). I assume that usage is independent of
> > zcrypt driver usage in the host?  
> A function in kvm-s390.c was replaced with a call to the function in
> ap_bus.c that was externalized in patch 2/14. This was done to remove
> duplicate code. Since zcrypt is built into the kernel, I didn't think
> it would be a problem, but apparently because of the way zcrypt is
> configured, it is still possible to remove it from the kernel build.

Yes.

> >
> > So, I think that apxa detection function should be used to s390
> > architecture base code and not be conditional on anything.  
> I am convinced that the original function from kvm_s390.c should be
> restored.

That would work as well, but removing the code duplication via moving
to s390 architecture code should not be that bad, either. Leaving the
decision to the respective maintainers.

Re: [PATCH v3 2/6] Disable instrumentation for some code

[Marc Zyngier]

On 02/04/18 13:04, Abbott Liu wrote:
> From: Andrey Ryabinin 
> 
> Disable instrumentation for arch/arm/boot/compressed/*
> ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those
> code won't linkd with kernel image.
> 
> Disable kasan check in the function unwind_pop_register
> because it doesn't matter that kasan checks failed when
> unwind_pop_register read stack memory of task.
> 
> Reviewed-by: Russell King - ARM Linux 
> Reviewed-by: Florian Fainelli 
> Reviewed-by: Marc Zyngier 

Just because I replied to this patch doesn't mean you can stick my
Reviewed-by tag on it. Please drop this tag until I explicitly say that
you can add it (see Documentation/process/submitting-patches.rst,
section 11).

Same goes for patch 1.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 3/4] mm: Add free()

[Matthew Wilcox]

On Tue, Apr 03, 2018 at 10:50:59AM +0200, Pavel Machek wrote:
> > gcc already does some nice optimisations around free().  For example, it
> > can eliminate dead stores:
> 
> Are we comfortable with that optimalization for kernel?
> 
> us: "Hey, let's remove those encryption keys before freeing memory."
> gcc: :-).
> 
> us: "Hey, we want to erase lock magic values not to cause confusion
> later."
> gcc: "I like confusion!"
> 
> Yes, these probably can be fixed by strategic "volatile" and/or
> barriers, but...

Exactly, we should mark those sites explicitly with volatile so that 
they aren't dead stores.

Re: NO_HZ_FULL and tick running within a reasonable amount of time

[Frederic Weisbecker]

On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote:
> Hello!
> 
> I am hitting the following on today's mainline under rcutorture, but
> only on scenarios built with CONFIG_NO_HZ_FULL=y:
> 
> 
> 
> WARNING: CPU: 0 PID: 7 at 
> /home/paulmck/public_git/linux-rcu/kernel/sched/core.c:3124 
> sched_tick_remote+0x113/0x120
> Modules linked in:
> CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 4.16.0+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Ubuntu-1.8.2-1ubuntu1 04/01/2014
> Workqueue: events_unbound sched_tick_remote
> RIP: 0010:sched_tick_remote+0x113/0x120
> RSP: 0018:94d540103e20 EFLAGS: 00010002
> RAX: 00012e9bb357 RBX: 8f95dfd21840 RCX: 001f
> RDX: b2d05e00 RSI:  RDI: 8f95dfd21858
> RBP: 94d540103e48 R08: f6499019 R09: f6499000
> R10: b163d33b R11: a5c8c212 R12: 8f95dfd25518
> R13: 8f95de9e4200 R14: 3402 R15: 8f95dfd21858
> FS:  () GS:8f95dfc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0a015b40 CR3: 1de14000 CR4: 06f0
> Call Trace:
>  process_one_work+0x1d9/0x6a0
>  worker_thread+0x42/0x420
>  kthread+0xf3/0x130
>  ? rescuer_thread+0x340/0x340
>  ? kthread_delayed_work_timer_fn+0x80/0x80
>  ret_from_fork+0x3a/0x50
> Code: ff 48 8b 83 80 0b 00 00 48 85 c0 0f 85 41 ff ff ff e9 45 ff ff ff be ff 
> ff ff ff 4c 89 ff e8 55 44 02 00 85 c0 75 87 0f 0b eb 83 <0f> 0b eb 97 66 0f 
> 1f 84 00 00 00 00 00 41 57 41 56 41 55 41 54
> ---[ end trace fbdcbe529a8ae799 ]--
> 
> 
> 
> The WARN_ON_ONCE() triggering is this guy:
> 
>   delta = rq_clock_task(rq) - curr->se.exec_start;
>   WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3);

Weird. Can you try to print up those values and see how much they drift?

if (WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3))
   printk_once("clock_task: %lld exec_start: %lld\n", 
rq_clock_task(rq), curr->se.exec_start);

> 
> But given that ->se.exec_start is zeroed from time to time, for example,
> in migrate_task_rq_fair(), I am a bit suspicious of this check.
> 
> What am I missing here?
> 
>   Thanx, Paul
> 

Re: [PATCH] selftests/ftrace: fix spelling mistake: "tiggers" -> "triggers"

[Steven Rostedt]

On Tue, 3 Apr 2018 13:07:05 +0300
Dan Carpenter  wrote:

> On Fri, Mar 30, 2018 at 09:51:21AM -0600, Shuah Khan wrote:
> > On 03/29/2018 12:04 PM, Steven Rostedt wrote:  
> > > On Thu, 29 Mar 2018 11:54:28 -0600
> > > Shuah Khan  wrote:
> > >   
> > >> I will pick this up with your Ack Steve, unless you want include
> > >> it in your pull request.  
> > > 
> > > You or Janitors can take it.
> > >   
> > 
> > Okay we can leave it to the Janitors then.
> >  
> 
> There isn't a Janitor tree...
> 

But there is a trivial tree. I guess the confusion was that
kernel-janit...@vger.kernel.org was Cc'd. Where do their work go?

-- Steve

Re: linux-next: manual merge of the selinux tree with the security tree

[Paul Moore]

On Tue, Apr 3, 2018 at 12:43 AM, Stephen Rothwell  wrote:
> Hi Paul,
>
> Today's linux-next merge of the selinux tree got a conflict in:
>
>   include/linux/lsm_hooks.h
>
> between commit:
>
>   22402b0b736d ("security: convert security hooks to use hlist")
>
> from the security tree and commit:
>
>   72e89f50084c ("security: Add support for SCTP security hooks")
>
> from the selinux tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

That looks right, thanks Stephen.

-- 
paul moore
www.paul-moore.com

Re: [PATCH] vhost-net: add limitation of sent packets for tx polling

[Michael S. Tsirkin]

On Tue, Apr 03, 2018 at 08:08:26AM +, haibinzhang(张海斌) wrote:
> handle_tx will delay rx for a long time when tx busy polling udp packets
> with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT
> takes into account only sent-bytes but no single packet length.
> 
> Tests were done between two Virtual Machines using netperf(UDP_STREAM, len=1),
> then another machine pinged the client. Result shows as follow:
> 
> Packet#   Ping-Latency(ms)
>   min avg max
> Origin  3.319  18.489  57.503
> 64  1.643   2.021   2.552
> 128 1.825   2.600   3.224
> 256 1.997   2.710   4.295
> 512*1.860   3.171   4.631
> 10242.002   4.173   9.056
> 20482.257   5.650   9.688
> 40962.093   8.508  15.943
> 
> 512 is selected, which is multi-VRING_SIZE

There's no guarantee vring size is 256.

Could you pls try with a different tx ring size?

I suspect we want:

#define VHOST_NET_PKT_WEIGHT(vq) ((vq)->num * 2)


> and close to VHOST_NET_WEIGHT/MTU.

Puzzled by this part.  Does tweaking MTU change anything?

> To evaluate this change, another tests were done using netperf(RR, TX) between
> two machines with Intel(R) Xeon(R) Gold 6133 CPU @ 2.50GHz. Result as follow
> does not show obvious changes:
> 
> TCP_RR
> 
> size/sessions/+thu%/+normalize%
>1/   1/  -7%/-2%
>1/   4/  +1%/ 0%
>1/   8/  +1%/-2%
>   64/   1/  -6%/ 0%
>   64/   4/   0%/+2%
>   64/   8/   0%/ 0%
>  256/   1/  -3%/-4%
>  256/   4/  +3%/+4%
>  256/   8/  +2%/ 0%
> 
> UDP_RR
> 
> size/sessions/+thu%/+normalize%
>1/   1/  -5%/+1%
>1/   4/  +4%/+1%
>1/   8/  -1%/-1%
>   64/   1/  -2%/-3%
>   64/   4/  -5%/-1%
>   64/   8/   0%/-1%
>  256/   1/  +7%/+1%
>  256/   4/  +1%/+1%
>  256/   8/  +2%/+2%
> 
> TCP_STREAM
> 
> size/sessions/+thu%/+normalize%
>   64/   1/   0%/-3%
>   64/   4/  +3%/-1%
>   64/   8/  +9%/-4%
>  256/   1/  +1%/-4%
>  256/   4/  -1%/-1%
>  256/   8/  +7%/+5%
>  512/   1/  +1%/ 0%
>  512/   4/  +1%/-1%
>  512/   8/  +7%/-5%
> 1024/   1/   0%/-1%
> 1024/   4/  +3%/ 0%
> 1024/   8/  +8%/+5%
> 2048/   1/  +2%/+2%
> 2048/   4/  +1%/ 0%
> 2048/   8/  -2%/ 0%
> 4096/   1/  -2%/ 0%
> 4096/   4/  +2%/ 0%
> 4096/   8/  +9%/-2%
> 
> Signed-off-by: Haibin Zhang 
> Signed-off-by: Yunfang Tai 
> Signed-off-by: Lidong Chen 
> ---
>  drivers/vhost/net.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 8139bc70ad7d..13a23f3f3ea4 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -44,6 +44,10 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy 
> TX;"
>   * Using this limit prevents one virtqueue from starving others. */
>  #define VHOST_NET_WEIGHT 0x8
>  
> +/* Max number of packets transferred before requeueing the job.
> + * Using this limit prevents one virtqueue from starving rx. */
> +#define VHOST_NET_PKT_WEIGHT 512
> +
>  /* MAX number of TX used buffers for outstanding zerocopy */
>  #define VHOST_MAX_PEND 128
>  #define VHOST_GOODCOPY_LEN 256
> @@ -473,6 +477,7 @@ static void handle_tx(struct vhost_net *net)
>   struct socket *sock;
>   struct vhost_net_ubuf_ref *uninitialized_var(ubufs);
>   bool zcopy, zcopy_used;
> + int sent_pkts = 0;
>  
>   mutex_lock(>mutex);
>   sock = vq->private_data;
> @@ -580,7 +585,8 @@ static void handle_tx(struct vhost_net *net)
>   else
>   vhost_zerocopy_signal_used(net, vq);
>   vhost_net_tx_packet(net);
> - if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
> + if (unlikely(total_len >= VHOST_NET_WEIGHT) ||
> + unlikely(++sent_pkts >= VHOST_NET_PKT_WEIGHT)) {
>   vhost_poll_queue(>poll);
>   break;
>   }
> -- 
> 2.12.3
> 

[PATCH] kernel/bpf/syscall: fix warning defined but not used

[Anders Roxell]

There will be a build warning -Wunused-function if CONFIG_CGROUP_BPF
isn't defined, since the only user is inside #ifdef CONFIG_CGROUP_BPF:
kernel/bpf/syscall.c:1229:12: warning: ‘bpf_prog_attach_check_attach_type’
defined but not used [-Wunused-function]
 static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog,
^

Current code moves function bpf_prog_attach_check_attach_type inside
ifdef CONFIG_CGROUP_BPF.

Fixes: 5e43f899b03a ("bpf: Check attach type at prog load time")
Signed-off-by: Anders Roxell 
---
 kernel/bpf/syscall.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 7457f2676c6d..56f49557adda 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1226,18 +1226,6 @@ bpf_prog_load_check_attach_type(enum bpf_prog_type 
prog_type,
}
 }
 
-static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog,
-enum bpf_attach_type attach_type)
-{
-   switch (prog->type) {
-   case BPF_PROG_TYPE_CGROUP_SOCK:
-   case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
-   return attach_type == prog->expected_attach_type ? 0 : -EINVAL;
-   default:
-   return 0;
-   }
-}
-
 /* last field in 'union bpf_attr' used by this command */
 #defineBPF_PROG_LOAD_LAST_FIELD expected_attach_type
 
@@ -1465,6 +1453,18 @@ static int bpf_raw_tracepoint_open(const union bpf_attr 
*attr)
 
 #ifdef CONFIG_CGROUP_BPF
 
+static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog,
+enum bpf_attach_type attach_type)
+{
+   switch (prog->type) {
+   case BPF_PROG_TYPE_CGROUP_SOCK:
+   case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
+   return attach_type == prog->expected_attach_type ? 0 : -EINVAL;
+   default:
+   return 0;
+   }
+}
+
 #define BPF_PROG_ATTACH_LAST_FIELD attach_flags
 
 static int sockmap_get_from_fd(const union bpf_attr *attr,
-- 
2.16.2

Re: [kvmtool PATCH 20/17] kvmtool: arm64: Switch memory layout

[Jean-Philippe Brucker]

Hi Suzuki,

On 27/03/18 14:15, Suzuki K Poulose wrote:
> If the guest wants to use a larger physical address space place
> the RAM at upper half of the address space. Otherwise, it uses the
> default layout.
> 
> Signed-off-by: Suzuki K Poulose 
> ---
>  arm/aarch32/include/kvm/kvm-arch.h |  1 +
>  arm/aarch64/include/kvm/kvm-arch.h | 15 ---
>  arm/include/arm-common/kvm-arch.h  | 11 ++-
>  arm/kvm.c  |  2 +-
>  4 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/arm/aarch32/include/kvm/kvm-arch.h 
> b/arm/aarch32/include/kvm/kvm-arch.h
> index cd31e72..2d62aab 100644
> --- a/arm/aarch32/include/kvm/kvm-arch.h
> +++ b/arm/aarch32/include/kvm/kvm-arch.h
> @@ -4,6 +4,7 @@
>  #define ARM_KERN_OFFSET(...) 0x8000
>  
>  #define ARM_MAX_MEMORY(...)  ARM_LOMAP_MAX_MEMORY

I guess this should now be ARM32_MAX_MEMORY?

Thanks,
Jean

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

[Peter Zijlstra]

On Tue, Apr 03, 2018 at 01:39:08PM +0100, David Howells wrote:
> Peter Zijlstra  wrote:
> 
> > I figured that since there were only a handful of users it wasn't a
> > popular API, also David very much knew of those patches changing it so
> > could easily have pulled in the special tip/sched/wait branch :/
> 
> I'm not sure I could, since I have to base on net-next.  I'm not sure what
> DaveM's policy on that is.
> 
> Also, it might've been better not to simply erase the atomic_t wait API
> immediately, but substitute wrappers for it to be removed one iteration hence.

Yeah, I know, but I really wasn't expecting new users of this thing, it
seemed like quite an exotic API with very limited users.

A well..

Re: [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Nicolas Ferre]

On 31/03/2018 at 10:54, Alexandre Belloni wrote:

On 30/03/2018 at 16:44:20 +0100, Colin King wrote:

From: Colin Ian King 

Trivial fix to spelling mistake in pr_debug message text


Acked-by: Alexandre Belloni 


Acked-by: Nicolas Ferre 

Signed-off-by: Colin Ian King 
---
  sound/soc/atmel/atmel_ssc_dai.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index a1e2c5682dcd..1c7af0ca98ec 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -820,7 +820,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
*substream,
if (ret < 0) {
printk(KERN_WARNING
"atmel_ssc_dai: request_irq failure\n");
-   pr_debug("Atmel_ssc_dai: Stoping clock\n");
+   pr_debug("Atmel_ssc_dai: Stopping clock\n");
clk_disable(ssc_p->ssc->clk);
return ret;
}
--
2.15.1






--
Nicolas Ferre

Re: [PATCH 3/4] mm: Add free()

[Pavel Machek]

Hi!

> > And sure, your free() implementation obviously also has that property,
> > but I'm worried that they might one day decide to warn about the
> > prototype mismatch (actually, I'm surprised it doesn't warn now, given
> > that it obviously pretends to know what free() function I'm calling...),
> > or make some crazy optimization that will break stuff in very subtle ways.
> > 
> > Also, we probably don't want people starting to use free() (or whatever
> > name is chosen) if they do know the kind of memory they're freeing?
> > Maybe it should not be advertised that widely (i.e., in kernel.h).
> 
> All that you've said I see as an advantage, not a disadvantage.
> Maybe I should change the prototype to match the userspace
> free(), although gcc is deliberately lax about the constness of
> function arguments when determining compatibility with builtins.
> See match_builtin_function_types() if you're really curious.
> 
> gcc already does some nice optimisations around free().  For example, it
> can eliminate dead stores:

Are we comfortable with that optimalization for kernel?

us: "Hey, let's remove those encryption keys before freeing memory."
gcc: :-).

us: "Hey, we want to erase lock magic values not to cause confusion
later."
gcc: "I like confusion!"

Yes, these probably can be fixed by strategic "volatile" and/or
barriers, but...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: general protection fault in try_to_wake_up

[Petr Mladek]

On Thu 2018-03-29 09:01:02, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> bcfc1f4554662d8f2429ac8bd96064a59c149754 (Sat Mar 24 16:50:12 2018 +)
> Merge tag 'pinctrl-v4.16-3' of
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=d1fe9b7b917f2715c7d4
> 
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=4649457446551552
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=4909621332410368
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-5034017172441945317
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d1fe9b7b917f2715c...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> IPVS: ftp: loaded support on port[0] = 21
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN

This is already 2nd level fault. I wonder if KASAN or lockdep should
have already been disabled at this point. Adding some more people
into CC.


> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4170 Comm: syz-executor0 Not tainted 4.16.0-rc6+ #1
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__lock_acquire+0x209/0x3e00 kernel/locking/lockdep.c:3320
> RSP: 0018:8801db206f60 EFLAGS: 00010002
> RAX: 078e0401078e0401 RBX:  RCX: 
> RDX: 1100389fe583 RSI:  RDI: 8801c4ff2c18
> RBP: 8801db2072f0 R08: 814d839c R09: 0001
> R10:  R11: 8801c4ff2c10 R12: 
> R13: 0001 R14:  R15: 8801b793c440
> FS:  014fa940() GS:8801db20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 004cb4e0 CR3: 0001b7980002 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  
>  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
>  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>  _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
>  try_to_wake_up+0xbc/0x15f0 kernel/sched/core.c:1989
>  default_wake_function+0x30/0x50 kernel/sched/core.c:3693
>  autoremove_wake_function+0x78/0x350 kernel/sched/wait.c:377
>  __wake_up_common+0x18e/0x780 kernel/sched/wait.c:97
>  __wake_up_common_lock+0x1b4/0x310 kernel/sched/wait.c:125
>  __wake_up+0xe/0x10 kernel/sched/wait.c:149
>  wake_up_klogd_work_func+0x4a/0x70 kernel/printk/printk.c:2869
>  irq_work_run_list+0x184/0x240 kernel/irq_work.c:155
>  irq_work_tick+0x136/0x1a0 kernel/irq_work.c:181
>  update_process_times+0x48/0x60 kernel/time/timer.c:1639
>  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
>  __run_hrtimer kernel/time/hrtimer.c:1349 [inline]
>  __hrtimer_run_queues+0x39c/0xec0 kernel/time/hrtimer.c:1411
>  hrtimer_interrupt+0x2a5/0x6f0 kernel/time/hrtimer.c:1469
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:857
>  
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:778
> [inline]
> RIP: 0010:console_unlock+0xb18/0xfb0 kernel/printk/printk.c:2403
> RSP: 0018:8801b79068d8 EFLAGS: 0293 ORIG_RAX: ff12
> RAX: 8801b793c440 RBX: 0200 RCX: 815a8d6f
> RDX:  RSI: 110036f279af RDI: 0293
> RBP: 8801b7906a40 R08: 110036f20ce9 R09: 
> R10:  R11:  R12: 
> R13:  R14: 83ba15e0 R15: dc00
>  vprintk_emit+0x5c3/0xb90 kernel/printk/printk.c:1907

raw_spin_lock() succeeded here. Therefore lockdep was still working
at this stage.

>  vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
>  vprintk_func+0x57/0xc0 kernel/printk/printk_safe.c:379
>  printk+0xaa/0xca kernel/printk/printk.c:1980
>  kasan_die_handler+0x3d/0x3f arch/x86/mm/kasan_init_64.c:248
>  notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
>  __atomic_notifier_call_chain kernel/notifier.c:183 [inline]
>  atomic_notifier_call_chain+0x77/0x140 kernel/notifier.c:193
>  notify_die+0x18c/0x280 kernel/notifier.c:549

It must have been general protection fault as well.

Best Regards,
Petr

>  

Re: [PATCHv6 1/2] dt-bindings: mfd: motorola-cpcap: document audio-codec

[Pavel Machek]

On Fri 2018-03-30 14:58:23, Sebastian Reichel wrote:
> This adds the DT binding for the audio-codec sub-module found
> inside the Motorola CPCAP PMIC.
> 
> Acked-by: Mark Brown 
> Acked-by: Tony Lindgren 
> Reviewed-by: Rob Herring 
> Acked-for-MFD-by: Lee Jones 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

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


signature.asc
Description: Digital signature

Re: [PATCH] ALSA: hda/realtek: Enable audio line out on ASUS D640SA

[Takashi Iwai]

On Tue, 03 Apr 2018 10:43:02 +0200,
Jian-Hong Pan wrote:
> 
> 2018-04-02 19:29 GMT+08:00 Takashi Iwai :
> >
> > On Mon, 02 Apr 2018 09:33:13 +0200,
> > Jian-Hong Pan wrote:
> > >
> > > This ASUS D640SA desktop whose mother board is D640MB has
> > > - two jacks which are a headphone and a mic on the front panel,
> > > - three jacks which are a mic, a line out and a line in on the rear panel
> > > - one internal speaker.
> > >
> > > If I plug a headphone to the front headphone jack, there will be sound
> > > through the headphone jack, and no sound through the internal speaker.
> > > If I unplug the headphone from the the headphone jack, there will be
> > > sound through the internal speaker.  And always no sound through rear
> > > line out, when I plug a headphone or an externel speaker to the rear
> > > line out jack.
> > >
> > > Besides, I had checked and toggled the Auto-Mute Mode in alsamixer, but
> > > the rear line out still was not working.  Then I checked the sound
> > > settings in GUI, and found there was no "Line Out" could be chosen, only
> > > the "Headphones" and "HDMI/DisplayPort".
> > > However, system does know that there is an "Intel PCH Line Out".
> > >
> > > [   10.089082] snd_hda_codec_realtek hdaudioC0D0: autoconfig for
> > > ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
> > > [   10.089083] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=1
> > > (0x1a/0x0/0x0/0x0/0x0)
> > > [   10.089084] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1
> > > (0x1b/0x0/0x0/0x0/0x0)
> > > [   10.089085] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
> > > [   10.089086] snd_hda_codec_realtek hdaudioC0D0:inputs:
> > > [   10.089087] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
> > > [   10.089088] snd_hda_codec_realtek hdaudioC0D0:  Front Mic=0x19
> > > [   10.089089] snd_hda_codec_realtek hdaudioC0D0:  Line=0x15
> > > [   10.104387] input: HDA Intel PCH Rear Mic as
> > > /devices/pci:00/:00:1f.3/sound/card0/input9
> > > [   10.104416] input: HDA Intel PCH Front Mic as
> > > /devices/pci:00/:00:1f.3/sound/card0/input10
> > > [   10.104441] input: HDA Intel PCH Line as
> > > /devices/pci:00/:00:1f.3/sound/card0/input11
> > > [   10.104467] input: HDA Intel PCH Line Out as
> > > /devices/pci:00/:00:1f.3/sound/card0/input12
> > > [   10.104494] input: HDA Intel PCH Front Headphone as
> > > /devices/pci:00/:00:1f.3/sound/card0/input13
> > >
> > > Consequently, I checked the pin widgets' default configuration values:
> > > - Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
> > > Pin Default 0x01014010: [Jack] Line Out at Ext Rear
> > >
> > > - Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
> > > Pin Default 0x02214030: [Jack] HP Out at Ext Front
> > >
> > > Because the headphone jack (Node ID:0x1b) locates on the desktop's front
> > > panel, not rear panel, I change the headphone jack's configuration from
> > > primary chassis to separate chassis.  So, the configuration value of
> > > Node ID:0x1b should be 0x22214030.
> >
> > This is OK, but...
> >
> > > Additionally, I toggle the Auto-Mute Mode of Realtek codecs to “Speaker
> > > Only” which makes signal outputs through line out jack when the "Line
> > > Out" is chosen in the sound settings.
> >
> > ... this is a matter of taste, and I don't think it good to set a
> > different default from others.  You can change it once and save it via
> > alsactl.
> 
> The default state of Auto-Mute Mode of Realtek codec on this machine is
> "Line Out + Speaker".
> This disallows to output audio signal through the line out jack, even I 
> already
> choose the "Line Out" as the audio output device in the sound settings.
> It means there is no way to use the line out jack in "Line Out + Speaker" 
> state
> of Auto-Mute Mode on this machine.

It's a setup issue by PA, and it's not specific to this device at
all.  If PA wants the independent output, it can change to auto-mute
off by itself.

> To enhance the user experience, especially the new one who first uses Linux,
> changing this machine's Auto-Mute Mode to "Speaker Only" state, which allows
> to output the audio signal through the line out jack, will be the better 
> choice.
> 
> By the way, if the "Headphones" is chosen as the audio output device in the
> sound settings, the audio signal will not output through the line out jack
> automatically.
> 
> Therefore, I think this part of the quirk is still needed on this machine.

Again, this isn't about the machine configuration, but a generic PA
problem.  Fixing it in a device-specific fixup is no right way.


thanks,

Takashi

linux-next: Tree for Apr 3

[Stephen Rothwell]

Hi all,

Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.

Changes since 20180329:

The kbuild tree lost its build failure.

The asm-generic tree gained a conflict against Linus' tree.

The vfs tree still had its build failure for which I reverted a commit.

The pci tree gained conflicts against Linus', the asm-generic and
arm-soc trees.

The net-next tree gained a conflict against the pci tree.

The selinux tree gained a conflict against the security tree.

Non-merge commits (relative to Linus' tree): 9213
 11817 files changed, 430998 insertions(+), 772860 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

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

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (46e0d28bdb8e Merge branch 'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (7928b2cbe55b Linux 4.16-rc1)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (1b8837b61714 ARM: 8750/1: deflate_xip_data.sh: minor 
fixes)
Merging arm64-fixes/for-next/fixes (e21da1c99200 arm64: Relax 
ARM_SMCCC_ARCH_WORKAROUND_1 discovery)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (52396500f97c powerpc/64s: Fix i-side SLB miss bad 
address handler saving nonvolatile GPRs)
Merging sparc/master (9c548bb5823d sparc64: Oracle DAX driver depends on 
SPARC64)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (b5dbc28762fd Merge tag 'kbuild-fixes-v4.16-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging bpf/master (e8a4796ee295 nfp: bpf: fix check of program max insn count)
Merging ipsec/master (9a3fb9fb84cc xfrm: Fix transport mode skb control buffer 
usage.)
Merging netfilter/master (b9fc828debc8 qede: Fix barrier usage after tx 
doorbell write.)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (9b9322db5c5a brcmfmac: Fix check for ISO3166 
code)
Merging mac80211/master (1dfe82ebd7d8 net: fix possible out-of-bound read in 
skb_network_protocol())
Merging rdma-fixes/for-rc (84652aefb347 RDMA/ucma: Introduce safer 
rdma_addr_size() variants)
Merging sound-current/for-linus (903d271a3f83 Merge tag 'asoc-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (fc110ebdd014 PCI: dwc: Fix enumeration end when 
reaching root subordinate)
Merging driver-core.current/driver-core-linus (0c8efd610b58 Linux 4.16-rc5)
Merging tty.current/tty-linus (c698ca527893 Linux 4.16-rc6)
Merging usb.current/usb-linus (c698ca527893 Linux 4.16-rc6)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (86d71233b615 USB: serial: ftdi_sio: add 
support for Harman FirmwareHubEmulator)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)

[PATCH 2/5] kokr/doc: De-emphasize smp_read_barrier_depends

[SeongJae Park]

This commit applies an upstream change, commit 9ad3c143d7d6 ("doc:
De-emphasize smp_read_barrier_depends") to the Korean version document.

Signed-off-by: SeongJae Park 
---
 Documentation/translations/ko_KR/memory-barriers.txt | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index edef154d77b2..44e47c2d33cf 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -1790,7 +1790,7 @@ CPU 메모리 배리어
범용  mb()smp_mb()
쓰기  wmb()   smp_wmb()
읽기  rmb()   smp_rmb()
-   데이터 의존성 read_barrier_depends()  smp_read_barrier_depends()
+   데이터 의존성 READ_ONCE()
 
 
 데이터 의존성 배리어를 제외한 모든 메모리 배리어는 컴파일러 배리어를
@@ -2829,7 +2829,10 @@ CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 
 다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
 액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다.  Alpha 는 가장
 약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
-사용되지 않았을 때에는 그런 조정이 필요하지 않게 했습니다.
+사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
+더 높은 CPU 클락 속도를 가질 수 있게 했습니다.  하지만, Alpha 아키텍쳐 전용
+코드와 READ_ONCE() 매크로 내부에서를 제외하고는 smp_read_barrier_depends() 가
+사용되지 않아야 함을 알아두시기 바랍니다.
 
 
 캐시 일관성 VS DMA
-- 
2.13.0

Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

[Daniel Lezcano]

On 31/03/2018 19:46, Paul Cercueil wrote:
> Le 2018-03-31 10:10, Daniel Lezcano a écrit :
>> On 29/03/2018 16:52, Paul Cercueil wrote:
>>>
>>>
>>> Le mer. 28 mars 2018 à 18:25, Daniel Lezcano 
>>> a écrit :
 On 28/03/2018 17:15, Paul Cercueil wrote:
>  Le 2018-03-24 07:26, Daniel Lezcano a écrit :
>>  On 18/03/2018 00:29, Paul Cercueil wrote:
>>>  This driver will use the TCU (Timer Counter Unit) present on the
>>> Ingenic
>>>  JZ47xx SoCs to provide the kernel with a clocksource and timers.
>>
>>  Please provide a more detailed description about the timer.
>
>  There's a doc file for that :)

 Usually, when there is a new driver I ask for a description in the
 changelog for reference.

>>  Where is the clocksource ?
>
>  Right, there is no clocksource, just timers.
>
>>  I don't see the point of using channel idx and pwm checking here.
>>
>>  There is one clockevent, why create multiple channels ? Can't you
>> stick
>>  to the usual init routine for a timer.
>
>  So the idea is that we use all the TCU channels that won't be used
> for PWM
>  as timers. Hence the PWM checking. Why is this bad?

 It is not bad but arguable. By checking the channels used by the pwm in
 the code, you introduce an adherence between two subsystems even if it
 is just related to the DT parsing part.

 As it is not needed to have more than one timer in the time framework
 (at least with the same characteristics), the pwm channels check is
 pointless. We can assume the author of the DT file is smart enough to
 prevent conflicts and define a pwm and a timer properly instead of
 adding more code complexity.

 In addition, simplifying the code will allow you to use the timer-of
 code and reduce very significantly the init function.
>>>
>>> That's what I had in my V1 and V2, my DT node for the timer-ingenic
>>> driver
>>> had a "timers" property (e.g. "timers = <4 5>;") to select the channels
>>> that
>>> should be used as timers. Then Rob told me I shouldn't do that, and
>>> instead
>>> detect the channels that will be used for PWM.
>>>
>>
>> [ ... ]
>>
>> How do you specify the channels used for PWM ?
> 
> To detect the channels that will be used as PWM I parse the whole
> devicetree
> searching for "pwms" properties; check that the PWM handle is for our
> TCU PWM
> driver; then read the PWM number from there.
> 
> Of course it's hackish, and it only works for devicetree. I preferred the
> method with the "timers" property.

Do you have a DT portion describing that? Eg somewhere in the kernel's
git tree ?

>From what I understood, we can specify the channel for a pwm but not for
a timer, there is certainly something I'm missing.

>>>
>>>  +config INGENIC_TIMER
>>>  +    bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
>>>  +    depends on MACH_INGENIC || COMPILE_TEST
>>
>>  bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if
>> COMPILE_TEST
>>
>>  Remove the depends MACH_INGENIC.
>
>  This driver is not useful on anything else than Ingenic SoCs, why
> should I
>  remove MACH_INGENIC then?

 For COMPILE_TEST on x86.
>>>
>>> Well that's a logical OR right here, so it will work...
>>
>> Right, I missed the second part of the condition. For consistency
>> reason, we don't add a dependency on the platform. The platform will
>> select it. Look the other timer options and you will see there is no
>> MACH deps. I'm trying consolidating all these options to have same
>> format and hopefully factor them out.
> 
> I'm all for factorisation, but what I dislike with not depending on
> MACH_INGENIC, is that the driver now appears in the menuconfig for
> every arch, even if it only applies to one MIPS SoC.

Can you do the following change?

bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if COMPILE_TEST

so it will appear only when the COMPILE_TEST option is set whatever the
platform which is the purpose of this option to increase compile test
coverage.


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 0/5] KVM: x86: hyperv: PV TLB flush for Windows guests

[Roman Kagan]

On Mon, Apr 02, 2018 at 06:10:54PM +0200, Vitaly Kuznetsov wrote:
> This is both a new feature and a bugfix.
> 
> Bugfix description: 
> 
> It was found that Windows 2016 guests on KVM crash when they have > 64
> vCPUs, non-flat topology (>1 core/thread per socket; in case it has >64
> sockets Windows just ignores vCPUs above 64) and Hyper-V enlightenments
> (any) are enabled. The most common error reported is "PAGE FAULT IN
> NONPAGED AREA" but I saw different messages. Apparently, Windows doesn't
> expect to run on a Hyper-V server without PV TLB flush support as there's
> no such Hyper-V servers out there (it's only WS2016 supporting > 64 vCPUs
> AFAIR).
> 
> Adding PV TLB flush support to KVM helps, Windows 2016 guests now boot 
> normally (I tried '-smp 128,sockets=64,cores=1,threads=2' and 
> '-smp 128,sockets=8,cores=16,threads=1' but other topologies should work
> too).
> 
> Feature description:
> 
> PV TLB flush helps a lot when running overcommited. KVM gained support for
> it recently but it is only available for Linux guests. Windows guests use
> emulated Hyper-V interface and PV TLB flush needs to be added there.
> 
> I tested WS2016 guest with 128 vCPUs running on a 12 pCPU server. The test
> was running 64 threads doing 100 mmap()/munmap() for 16384 pages with a
> tiny random nanosleep in between (I used Cygwin. It would be great if
> someone could point me to a good Windows-native TLB trashing test).
> 
> The results are:
> Before:
> real0m44.362s
> user0m1.796s
> sys 6m43.218s
> 
> After:
> real0m24.425s
> user0m1.811s
> sys 0m40.625s
> 
> When running without overcommit (single 12 vCPU guest on 12 pCPU server) the
> results of the same test are very close:
> Before:
> real0m21.237s
> user0m1.531s
> sys 0m19.984s
> 
> After:
> real0m21.082s
> user0m1.546s
> sys 0m20.030s

I vaguely remember Denis Plotnikov (cc-d) did a similar attempt a couple
of years ago.  IIRC the outcome was that win2012r2 (back then) guests
started to also use this mechanism for local tlb flushes via self-IPI,
which led to noticable degradation on certain workloads.

Denis do you have any details to share?

Thanks,
Roman.

Re: [PATCH v2] phy: tegra: Remove self cast in tegra_xusb_port_find_lane

[Thierry Reding]

On Sun, Apr 01, 2018 at 04:04:10AM -0700, Nathan Chancellor wrote:
> Clang warns about casting variables to themselves because it is rarely
> necessary. Removing the cast should not change anything regarding the
> code and silences the warning.
> 
> ../drivers/phy/tegra/xusb.c:421:11: warning: explicitly assigning value
> of variable of type 'const struct tegra_xusb_lane_map *' to itself
> [-Wself-assign]
> for (map = map; map->type; map++) {
>  ~~~ ^ ~~~
> 
> Signed-off-by: Nathan Chancellor 
> ---
> I am not entirely sure if this is the correct solution, especially since
> I don't have the hardware and I am not too familiar with this code. If
> there is a better solution, please let me know.
> 
> Changes from v1 -> v2: Fix spelling error in commit title
> 
>  drivers/phy/tegra/xusb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
> index 63e916d4d069..11aa5902a9ac 100644
> --- a/drivers/phy/tegra/xusb.c
> +++ b/drivers/phy/tegra/xusb.c
> @@ -418,7 +418,7 @@ tegra_xusb_port_find_lane(struct tegra_xusb_port *port,
>  {
>   struct tegra_xusb_lane *lane, *match = ERR_PTR(-ENODEV);
>  
> - for (map = map; map->type; map++) {
> + for (; map->type; map++) {
>   if (port->index != map->port)
>   continue;
>  

An equivalent patch seems to already have been merged. See:

https://patchwork.kernel.org/patch/10072641/

You can avoid duplication of effort such as this by basing any patches
you send on top of a recent linux-next. The above patch, for example,
was added in next-20180223.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: general protection fault in __mem_cgroup_free

[Michal Hocko]

Here we go

>From 38f0f08a3f9f19c106ae53350e43dc97e2e3a4d8 Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Tue, 3 Apr 2018 12:40:41 +0200
Subject: [PATCH] memcg: fix per_node_info cleanup

syzbot has triggered a NULL ptr dereference when allocation fault
injection enforces a failure and alloc_mem_cgroup_per_node_info
initializes memcg->nodeinfo only half way through. __mem_cgroup_free
still tries to free all per-node data and dereferences pn->lruvec_stat_cpu
unconditioanlly even if the specific per-node data hasn't been
initialized.

The bug is quite unlikely to hit because small allocations do not fail
and we would need quite some numa nodes to make struct mem_cgroup_per_node
large enough to cross the costly order.

Reported-by: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com
Fixes: 00f3ca2c2d66 ("mm: memcontrol: per-lruvec stats infrastructure")
Signed-off-by: Michal Hocko 
---
 mm/memcontrol.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e3d5a0a7917f..0a9c4d5194f3 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4340,6 +4340,9 @@ static void free_mem_cgroup_per_node_info(struct 
mem_cgroup *memcg, int node)
 {
struct mem_cgroup_per_node *pn = memcg->nodeinfo[node];
 
+   if (!pn)
+   return;
+
free_percpu(pn->lruvec_stat_cpu);
kfree(pn);
 }
-- 
2.16.3

-- 
Michal Hocko
SUSE Labs

Re: [PATCHv3 7/8] drm/omap: panel-dsi-cm: add rotation support

[Pavel Machek]

On Fri 2018-03-30 19:18:21, Sebastian Reichel wrote:
> From: Sebastian Reichel 
> 
> Add support to inform the DRM subsystem about the orientation
> the display has been mounted to the casing.
> 
> Signed-off-by: Sebastian Reichel 

1-5,7: Reviewed-by: Pavel Machek 

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


signature.asc
Description: Digital signature

Re: [PATCHv3 5/8] dt-bindings: panel: common: document orientation property

[Pavel Machek]

Hi!

> +- rotation: Display rotation in degrees counter clockwise (0,90,180,270).
> +  The following values are possible:
> +
> +0 = The top side of the panel matches the top side of the
> +device's casing (default).

This is still ambiguous for devices such as N900 and Droid4, which can
be used in two modes.

"For phone-like devices that can be used in two orientations, top side
is the one that is pointing up in keyboard-closed, portrait mode."

?


Best regards,
Pavel

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


signature.asc
Description: Digital signature

Re: [PATCH] PM / QoS: mark expected switch fall-throughs

[Pavel Machek]

On Fri 2018-03-30 16:18:44, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Pavel Machek 

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


signature.asc
Description: Digital signature

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

[Andy Shevchenko]

On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > > > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> > > > > > I still think that printing a hex value of the error code is
> > > > > > much
> > > > > > better
> > > > > > than some odd "(efault)".
> > > > > 
> > > > > Do you mean (err:0e)? Google gives rather confusing answers
> > > > > for
> > > > > this.
> > > > 
> > > > More like "(0x)" (we have already more than 512 error code
> > > > numbers.
> > > 
> > > Hmm, I have never seen the error code in this form.
> > 
> > We have limited space to print it and error numbers currently can be
> > up
> > to 0xfff (4095). So, I have no better idea how to squeeze them while
> > thinking that "(efault)" is much harder to parse in case of error
> > pointer.
> 
> But this will not be used instead of address value. It is used in
> situations
> where we print the information that is stored at the address, for
> example,
> string, IP address, dentry name.

We have a lot of API functions which returns:
-ERR_PTR
NULL
struct foo *

There is no guarantee that one of that API won't be used as a supplier
for printf().

You can't dereference ERR_PTR value, but anything else except the actual
error value is worse than value itself...

> 
> > >  Also google gives
> > > rather confusing results when searching, for example for
> > > "(0x000E)".
> > 
> > It's not primarily for google, though yeah, people would google for
> > error messages...
> > 
> > Another question is what the format: decimal versus hex for errors.
> > Maybe just "(-D)"?
> 
> This still looks confusing and google does not help.

...then we have a last option just to print a value as a pointer
address.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v6 RESEND 0/1] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

On 04/03/2018 02:23 PM, Oleksandr Andrushchenko wrote:

Resending with even more checkpatch code-style fixes.

Applied,
thank you!

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

[kbuild test robot]

Hi Sean,

I love your patch! Perhaps something to improve:

[auto build test WARNING on next-20180329]
[also build test WARNING on v4.16]
[cannot apply to linus/master bluetooth/master bluetooth-next/master v4.16 
v4.16-rc7 v4.16-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/add-support-for-Bluetooth-on-MT7622-SoC/20180403-160035
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/bluetooth/hci_mediatek.c:322:5: sparse: symbol 'mtk_recv_frame' was 
>> not declared. Should it be static?
>> drivers/bluetooth/hci_mediatek.c:415:57: sparse: Using plain integer as NULL 
>> pointer

Please review and possibly fold the followup patch.

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

[RFC PATCH] Bluetooth: hci_mediatek: mtk_recv_frame() can be static

[kbuild test robot]

Fixes: 9f2aacacb185 ("Bluetooth: hci_mediatek: Add protocol support for 
MediaTek serial devices")
Signed-off-by: Fengguang Wu 
---
 hci_mediatek.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_mediatek.c b/drivers/bluetooth/hci_mediatek.c
index 7ac1e7aa..ab02b8b 100644
--- a/drivers/bluetooth/hci_mediatek.c
+++ b/drivers/bluetooth/hci_mediatek.c
@@ -319,7 +319,7 @@ static int mtk_close(struct hci_uart *hu)
return 0;
 }
 
-int mtk_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
+static int mtk_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
 {
struct hci_event_hdr *hdr = (void *)skb->data;
struct hci_uart *hu = hci_get_drvdata(hdev);

[PATCH 0/5] MIPS: perf: MT fixes and improvements

[Matt Redfearn]

This series addresses a few issues with how the MIPS performance
counters code supports the hardware multithreading MT ASE.
Firstly, implementations of the MT ASE may implement performance counters
per core or per thread(TC). MIPS Techologies & BMIPS5000 implementations
signal this via a bit in the implmentation specific CONFIG7 register.
Since this register is implementation specific, checking it should be
guarded by a PRID check. This also replaces a bit defined by a magic
number.

Secondly, the code currently uses vpe_id(), defined as
smp_processor_id(), divided by 2, to share core performance counters
between VPEs. This relies on a couple of assumptions of the hardware
implementation to function correctly (always 2 VPEs per core, and the
hardware reading only the least significant bit).

Finally, the method of sharing core performance counters between VPEs is
suboptimal since it does not allow one process running on a VPE to use
all of the performance counters available to it, because the kernel will
reserve half of the coutners for the other VPE even if it may never use
them. This reservation at counter probe is replaced with an allocation
on use strategy.

Tested on a MIPS Creator CI40 (2C2T MIPS InterAptiv with per-TC
counters, though for the purposes of testing the per-TC availability was
hardcoded to allow testing both paths).

Series applies to v4.16-rc7



Matt Redfearn (5):
  MIPS: perf: More robustly probe for the presence of per-tc counters
  MIPS: perf: Use correct VPE ID when setting up VPE tracing
  MIPS: perf: Fix perf with MT counting other threads
  MIPS: perf: Allocate per-core counters on demand
  MIPS: perf: Fold vpe_id() macro into it's one last usage

 arch/mips/include/asm/mipsregs.h |  10 ++
 arch/mips/kernel/perf_event_mipsxx.c | 257 +--
 2 files changed, 162 insertions(+), 105 deletions(-)

-- 
2.7.4

[PATCH 5/5] MIPS: perf: Fold vpe_id() macro into it's one last usage

[Matt Redfearn]

The vpe_id() macro is now used only in mipsxx_pmu_enable_event when
CONFIG_CPU_BMIPS5000 is defined. Fold the one used definition of the
macro into it's usage and remove the now unused definitions.

Signed-off-by: Matt Redfearn 
---

 arch/mips/kernel/perf_event_mipsxx.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/arch/mips/kernel/perf_event_mipsxx.c 
b/arch/mips/kernel/perf_event_mipsxx.c
index bedb0d5ff3f2..44b9090a53cc 100644
--- a/arch/mips/kernel/perf_event_mipsxx.c
+++ b/arch/mips/kernel/perf_event_mipsxx.c
@@ -134,18 +134,6 @@ static int cpu_has_mipsmt_pertccounters;
 static DEFINE_SPINLOCK(core_counters_lock);
 
 static DEFINE_RWLOCK(pmuint_rwlock);
-
-#if defined(CONFIG_CPU_BMIPS5000)
-#define vpe_id()   (cpu_has_mipsmt_pertccounters ? \
-0 : (smp_processor_id() & MIPS_CPUID_TO_COUNTER_MASK))
-#else
-#define vpe_id()   (cpu_has_mipsmt_pertccounters ? \
-0 : cpu_vpe_id(_cpu_data))
-#endif
-
-#else /* !CONFIG_MIPS_PERF_SHARED_TC_COUNTERS */
-#define vpe_id()   0
-
 #endif /* CONFIG_MIPS_PERF_SHARED_TC_COUNTERS */
 
 static void resume_local_counters(void);
@@ -381,8 +369,10 @@ static void mipsxx_pmu_enable_event(struct hw_perf_event 
*evt, int idx)
 
if (IS_ENABLED(CONFIG_CPU_BMIPS5000)) {
/* enable the counter for the calling thread */
-   cpuc->saved_ctrl[idx] |=
-   (1 << (12 + vpe_id())) | BRCM_PERFCTRL_TC;
+   unsigned int vpe_id = cpu_has_mipsmt_pertccounters ? 0 :
+   (smp_processor_id() & MIPS_CPUID_TO_COUNTER_MASK);
+
+   cpuc->saved_ctrl[idx] |= BIT(12 + vpe_id) | BRCM_PERFCTRL_TC;
} else if (range > V) {
/* The counter is processor wide. Set it up to count all TCs. */
pr_debug("Enabling perf counter for all TCs\n");
-- 
2.7.4

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

[David Howells]

Stephen Rothwell  wrote:

> + wait_var_event(>nr_calls, !atomic_read(>nr_calls));

I would prefer == 0 to ! as it's not really a true/false value.

But apart from that, it's looks okay and you can add my Reviewed-by.

David

[PATCH 3/6] dt-bindings: timer: tpm: fix typo of clock name

[Daniel Lezcano]

From: Anson Huang 

The clock name should be ipg instead of igp.

Signed-off-by: Anson Huang 
Reviewed-by: Rob Herring 
Signed-off-by: Daniel Lezcano 
---
 Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt 
b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
index b4aa7dd..f82087b 100644
--- a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
+++ b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
@@ -15,7 +15,7 @@ Required properties:
 - interrupts : Should be the clock event device interrupt.
 - clocks : The clocks provided by the SoC to drive the timer, must contain
an entry for each entry in clock-names.
-- clock-names : Must include the following entries: "igp" and "per".
+- clock-names : Must include the following entries: "ipg" and "per".
 
 Example:
 tpm5: tpm@4026 {
-- 
2.7.4

[PATCH 4/6] clocksource/drivers/imx-tpm: Fix typo of clock name

[Daniel Lezcano]

From: Anson Huang 

The clock name should be ipg instead of igp.

Signed-off-by: Anson Huang 
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/timer-imx-tpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/timer-imx-tpm.c 
b/drivers/clocksource/timer-imx-tpm.c
index 21bffdc..3f97d49 100644
--- a/drivers/clocksource/timer-imx-tpm.c
+++ b/drivers/clocksource/timer-imx-tpm.c
@@ -179,7 +179,7 @@ static int __init tpm_timer_init(struct device_node *np)
ipg = of_clk_get_by_name(np, "ipg");
per = of_clk_get_by_name(np, "per");
if (IS_ERR(ipg) || IS_ERR(per)) {
-   pr_err("tpm: failed to get igp or per clk\n");
+   pr_err("tpm: failed to get ipg or per clk\n");
ret = -ENODEV;
goto err_clk_get;
}
-- 
2.7.4

linux-next on x60: hangs when I request suspend was Re: linux-next on x60: network manager often complains "network is disabled" after resume

[Pavel Machek]

Hi!

I wanted to re-test next (4.16.0-rc7-next-20180329), but that one does
not suspend at all.

I normally suspend by pressing power button in MATE, but that action
currently results in machine hanging.

Pavel


On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > > 
> > > > Broken state.
> > > > 
> > > > pavel@amd:~$ nmcli dev
> > > > DEVICE  TYPE  STATECONNECTION
> > > > eth1ethernet  unavailable  --
> > > > lo  loopback  unmanaged--
> > > > wlan0   wifi  unmanaged--
> > > 
> > > If the state is "unmanaged" on resume, that would indicate a
> > > problem
> > > with sleep/wake and likely not a kernel network device issue.
> > > 
> > > We should probably move this discussion to the NM lists to debug
> > > further.  Before you suspend, run "nmcli gen log level trace" to
> > > turn
> > > on full debug logging, then reproduce the issue, and send a pointer
> > > to
> > > those logs (scrubbed for anything you consider sensitive) to the NM
> > > mailing list.
> > 
> > Hmm :-)
> > 
> > root@amd:/data/pavel# nmcli gen log level trace
> > Error: Unknown log level 'trace'
> 
> What NM version?  'trace' is pretty old (since 1.0 from December 2014)
> so unless you're using a really, really old version of Debian I'd
> expect you'd have it.  Anyway, debug would do.
> 
> > root@amd:/data/pavel# nmcli gen log level help
> > Error: Unknown log level 'help'
> 
> nmcli gen help
> 
> > root@amd:/data/pavel# nmcli gen log level
> > Error: value for 'level' argument is required.
> > root@amd:/data/pavel# nmcli gen log level debug
> 
> This should be OK.
> 
> > root@amd:/data/pavel# cat /var/log/sys/log
> 
> It routes it to whatever the syslog 'daemon' facility logs to (however
> that's configured on your system).  Usually /var/log/messages or
> /var/log/daemon.log or sometimes your distro configures it to
> /var/log/NetworkManager.log.
> 
> Or if you're using a systemd-based distro, it would probably be in the
> systemd journal so "journalctl -b -u NetworkManager"
> 
> > Where do I get the logs? I don't see much in the syslog...
> 
> > And.. It seems that it is "every other suspend". One resume results
> > in
> > broken network, one in working one, one in broken one...
> 
> Does your distro use pm-utils, upower, or systemd for suspend/resume
> handling?
> 
> Dan

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


signature.asc
Description: Digital signature

Re: [PATCH v2 2/4] clk: qcom: Configure the RCGs to a safe source as needed

[Amit Nischal]

On 2018-03-20 06:00, Stephen Boyd wrote:

Quoting Amit Nischal (2018-03-07 23:18:13)
For some root clock generators, there could be child branches which 
are
controlled by an entity other than application processor subsystem. 
For
such RCGs, as per application processor subsystem clock driver, all of 
its
downstream clocks are disabled and RCG is in disabled state but in 
actual

downstream clocks can be left enabled before.


s/actual/reality?

Thanks for the review. I will address this in next patch series.





So in this scenario, when RCG is disabled as per clock driver's point 
of
view and when rate scaling request comes before downstream clock 
enable
request, then RCG fails to update its configuration because in actual 
RCG


s/actual/reality?


I will address this in next patch series.


is on and it expects its new source to alredy in enable state  but in


s/alredy/already be/

I will address this in next patch series.



reality new source is in off state. In order to avoid letting the RCG 
to


s/is in off state/is off/
s/letting/having/

I will address this in next patch series.



go into an invalid state, add support to just cache the rate of RCG 
during


s/just//

I will address this in next patch series.




set_rate(), defer actual RCG configuration update to be done during
clk_enable() as at this point of time, both its new parent and safe 
source

will be already enabled and RCG can safely switch to new parent.

During clk_disable() request, configure it to safe source as both
its parents, safe source and current parent will be enabled and RCG 
can

safely execute a switch. Also add support to have safe configuration
frequency table structure for each shared RCG.

Signed-off-by: Taniya Das 
Signed-off-by: Amit Nischal 
---
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index 2a7489a..205fa34 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -146,6 +146,9 @@ struct clk_dyn_rcg {
  * @hid_width: number of bits in half integer divider
  * @parent_map: map from software's parent index to hardware's 
src_sel field

  * @freq_tbl: frequency table
+ * @current_freq: last cached frequency when using branches with 
shared RCGs
+ * @safe_src_freq_tbl : frequency table of safe source when using 
branches

+ * with shared RCGs
  * @clkr: regmap clock handle
  *
  */
@@ -155,6 +158,8 @@ struct clk_rcg2 {
u8  hid_width;
const struct parent_map *parent_map;
const struct freq_tbl   *freq_tbl;
+   unsigned long   current_freq;
+   const struct freq_tbl   *safe_src_freq_tbl;


Can we store safe_src index instead? And then construct the frequency
table entry on the fly at the call site? I think it would greatly
clarify that we don't really care about the rate of the clk at all.
Instead, all we care about is making sure the mux is set to whatever
source selection can provide an always on signal.


We will address the above in the V3 series of the patch set. We will be
generating the safe frequency table on the fly taking the safe source
frequency index input from the RCG clock.


struct clk_regmap   clkr;
 };

@@ -167,5 +172,6 @@ struct clk_rcg2 {
 extern const struct clk_ops clk_byte2_ops;
 extern const struct clk_ops clk_pixel_ops;
 extern const struct clk_ops clk_gfx3d_ops;
+extern const struct clk_ops clk_rcg2_shared_ops;

 #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index e63db10..a52de54 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -790,3 +790,158 @@ static int clk_gfx3d_set_rate(struct clk_hw *hw, 
unsigned long rate,

.determine_rate = clk_gfx3d_determine_rate,
 };
+
+static unsigned long
+clk_rcg2_shared_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)

+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+
+   if (!__clk_is_enabled(hw->clk)) {
+   if (!rcg->current_freq) {
+   if (!clk_rcg2_get_parent(hw))


This is checking for 0 source selection of parent? So basically if
source is XO selected then return what we know is the XO speed? We
should be able to do that by returning parent_rate though?


+   rcg->current_freq =
+   rcg->safe_src_freq_tbl->freq;
+   else
+   rcg->current_freq =
+   clk_rcg2_recalc_rate(hw, 
parent_rate);

+   }
+
+   return rcg->current_freq;
+   }
+
+   return rcg->current_freq = clk_rcg2_recalc_rate(hw, 
parent_rate);


I don't get this function.

To simplify just return cached rate if it's set and clk is off,
otherwise read the hardware?

if (!__clk_is_enabled(hw->clk) && rcg->current_freq)
return rcg->current_freq;

return clk_rcg2_recalc_rate(hw, 

Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

[Pavel Machek]

Hi!

> > I think I should have the required options enabled... 
> > 
> > CONFIG_SND_OMAP_SOC=y
> > CONFIG_SND_OMAP_SOC_DMIC=y
> > CONFIG_SND_OMAP_SOC_MCBSP=y
> > CONFIG_SND_OMAP_SOC_MCPDM=y
> > CONFIG_SND_OMAP_SOC_HDMI_AUDIO=y
> 
> That's the SoC (OMAP) side.
> 
> > # CONFIG_SND_OMAP_SOC_RX51 is not set
> > # CONFIG_SND_OMAP_SOC_N9 is not set
> > CONFIG_SND_OMAP_SOC_OMAP_TWL4030=y
> > CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=y
> 
> That's not needed (but does not hurt). The Droid 4
> has no TWL companion chip and uses CPCAP instead.

Umm. AFAICT CONFIG_SND_OMAP_SOC_MCBSP=y can not be selected without
selecting one of the other options... right?

Seems like bug in Kconfig.

Pavel

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


signature.asc
Description: Digital signature

Re: [PATCH v5 10/13] ARM: sun9i: smp: Move structures

[Chen-Yu Tsai]

On Tue, Apr 3, 2018 at 4:47 PM, Maxime Ripard  wrote:
> On Tue, Apr 03, 2018 at 08:18:33AM +0200, Mylène Josserand wrote:
>> To prepare the support for sun8i-a83t, move some structures
>> at the beginning of the file.
>>
>> Signed-off-by: Mylène Josserand 
>
> I'm not quite sure what would be the benefit from that, if it's was
> working before, then it would probably work in your case as welle, right?

You should only need to move struct sunxi_mc_smp_data, since you are reading
the is_sun9i field. I suppose you could also get away with adding a global
variable just for that, and not have to store an index or pointer. Then none
of this code movement would be necessary. It would be slightly harder to
understand, but it's still contained within this file, and it has a clear
purpose, so I would call that acceptable.

ChenYu

Re: Regression caused by commit bc976233a872, ethernet r8169 stops working after system S3

[Thomas Gleixner]

On Sat, 31 Mar 2018, Kai-Heng Feng wrote:
> Thomas Gleixner  wrote:
> 
> > On Sat, 31 Mar 2018, Kai-Heng Feng wrote:
> > > A user reported [1] that the Realtek ethernet r8169 stops working after S3
> > > since v4.15-rc6. The issue still exists in Linus' tree:
> > > 
> > > [ 150.877998] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready
> > > [ 150.944101] do_IRQ: 3.37 No irq handler for vector
> > > [ 150.944105] r8169 :01:00.0 enp1s0: link down
> > > [ 150.944180] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready
> > > 
> > > My desktop also has this device, which is also affected by this
> > > regression. So
> > > I did a bisect, and this is the bad commit:
> > > bc976233a872 genirq/msi x86/vector: Prevent reservation mode for non
> > > maskable
> > > MSI
> > > 
> > > After this commit gets reverted, the issue is gone.
> > 
> > Sigh. Can you please apply the debug patch below and provide the output of
> > 
> > # cat /proc/interrupts
> > 
> > and full dmesg after resume.
> 
> Weird. I don't see this issue with this debug patch.

Bah. The patch is broken. New version written with brain awake below.

Thanks,

tglx

8<-
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -134,6 +134,10 @@ static bool migrate_one_irq(struct irq_d
brokeaff = false;
}
 
+   pr_info("IRQ%u: New affinity: %*pbl effective: %*pbl\n",
+   d->irq, cpumask_pr_args(affinity),
+   cpumask_pr_args(irq_data_get_effective_affinity_mask(d)));
+
if (maskchip && chip->irq_unmask)
chip->irq_unmask(d);
 

Re: [PATCH] drm/atmel-hlcdc: add command line option to specify preferred depth

[Daniel Vetter]

On Wed, Mar 28, 2018 at 12:03:39PM +0200, Peter Rosin wrote:
> On 2018-03-28 09:34, Boris Brezillon wrote:
> > Hi Peter,
> > 
> > On Mon, 26 Mar 2018 09:35:02 +0200
> > Peter Rosin  wrote:
> > 
> >> I have an sama5d31-based system with 64MB of memory and a 1920x1080
> >> LVDS display wired for 16-bpp. When I enable legacy fbdev support,
> >> the contiguous memory allocator invariably fails with the order-11
> >> allocation for a 1920x1080@24-bpp buffer (~6MB). But this HW can never
> >> make any good use of RGB888, so that is a wasted attempt anyway that
> >> would also waste precious memory should it succeed.
> >>
> >> Sure, I could rewrite user-space to go directly to KMS etc, and that
> >> makes the (attempted) order-11 allocation go away, replacing it with
> >> one order-10 allocation per application restart for a 1920x1080@16-bpp
> >> buffer (<4MB). But after a few restarts, order-10 allocations start to
> >> fail as well, which is only to be expected AFAIU.
> >>
> >> So, I'd rather not change user-space (which was originally written
> >> to target a smaller display) so that I at the same time get the
> >> benefit of an early pre-allocated fbdev frame-buffer that can be
> >> reused over and over. But to do that I need to tell the driver that
> >> 16-bpp is the preferred depth. Add a module parameter to do just that.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 18 +-
> >>  1 file changed, 17 insertions(+), 1 deletion(-)
> >>
> >> I found some inspiration regarding naming and implementation here:
> >> https://patchwork.kernel.org/patch/9848631/
> >>
> >> I have found no feedback on that patch though, which makes me wonder if
> >> I'm perhaps barking up the wronig tree?
> > 
> > Hm, isn't that something you can already overload with the video=
> > parameter?
> > 
> > video=:[-]
> 
> Heh, you are right...
> 
> > AFAIR,  encodes the color depth, so what is the benefit of adding
> > this new property to overload the default depth?
> 
> ...but hhhmmm, I think I will have to have to encode the display size
> in the bootargs so I will have to use distinct barebox environments
> depending on the panel, but that's no biggie.
> 
> Splendid, please throw away the patch!

I think we could fix the parsing to allow -bpp without the resolution ...
Not sure how to best do that though. Maybe state that 0x0-bpp means to not
change the resolution from the default?
-Daniel

> 
> Cheers,
> Peter
> 
> > Maybe I'm wrong and the default depth param is actually useful, but in
> > this case we should probably make it generic since other drivers seems
> > to need it too, and we might want to attach it to a specific display
> > engine instance.
> > 
> > Thanks,
> > 
> > Boris
> > 
> >>
> >> Cheers,
> >> Peter
> >>
> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> index c1ea5c36b006..f0148627c221 100644
> >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> @@ -29,6 +29,11 @@
> >>  
> >>  #define ATMEL_HLCDC_LAYER_IRQS_OFFSET 8
> >>  
> >> +static int atmel_hlcdc_preferred_depth __read_mostly;
> >> +
> >> +MODULE_PARM_DESC(preferreddepth, "Set preferred bpp");
> >> +module_param_named(preferreddepth, atmel_hlcdc_preferred_depth, int, 
> >> 0400);
> >> +
> >>  static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_at91sam9n12_layers[] = {
> >>{
> >>.name = "base",
> >> @@ -590,6 +595,7 @@ static int atmel_hlcdc_dc_modeset_init(struct 
> >> drm_device *dev)
> >>dev->mode_config.min_height = dc->desc->min_height;
> >>dev->mode_config.max_width = dc->desc->max_width;
> >>dev->mode_config.max_height = dc->desc->max_height;
> >> +  dev->mode_config.preferred_depth = 24;
> >>dev->mode_config.funcs = _config_funcs;
> >>  
> >>return 0;
> >> @@ -658,7 +664,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
> >>  
> >>platform_set_drvdata(pdev, dev);
> >>  
> >> -  drm_fb_cma_fbdev_init(dev, 24, 0);
> >> +  drm_fb_cma_fbdev_init(dev, atmel_hlcdc_preferred_depth, 0);
> >>  
> >>drm_kms_helper_poll_init(dev);
> >>  
> >> @@ -756,6 +762,16 @@ static int atmel_hlcdc_dc_drm_probe(struct 
> >> platform_device *pdev)
> >>struct drm_device *ddev;
> >>int ret;
> >>  
> >> +  switch (atmel_hlcdc_preferred_depth) {
> >> +  case 0: /* driver default */
> >> +  case 8:
> >> +  case 16:
> >> +  case 24:
> >> +  break;
> >> +  default:
> >> +  return -EINVAL;
> >> +  }
> >> +
> >>ddev = drm_dev_alloc(_hlcdc_dc_driver, >dev);
> >>if (IS_ERR(ddev))
> >>return PTR_ERR(ddev);
> > 
> > 
> > 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel 

Re: NO_HZ_FULL and tick running within a reasonable amount of time

[Peter Zijlstra]

On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote:

> The WARN_ON_ONCE() triggering is this guy:
> 
>   delta = rq_clock_task(rq) - curr->se.exec_start;
>   WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3);
> 
> But given that ->se.exec_start is zeroed from time to time, for example,
> in migrate_task_rq_fair(), I am a bit suspicious of this check.
> 
> What am I missing here?

We clear it on migration, but set it when we schedule a task back in.
The above checks that the 'current' task of that CPU had a tick at least
3 seconds ago (to ensure tasks don't go too long without ticks).

The 'current' task is obviously scheduled in and thus must have !0
exec_start time.

Re: [PATCH v4 3/3] MIPS: use generic GCC library routines from lib/

[Matt Redfearn]

On 03/04/18 09:53, James Hogan wrote:

On Thu, Mar 29, 2018 at 11:41:23AM +0100, Matt Redfearn wrote:

This commit removes several generic GCC library routines from
arch/mips/lib/ in favour of similar routines from lib/.



diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index e84e12655fa8..6537e022ef62 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -16,5 +16,4 @@ obj-$(CONFIG_CPU_R3000)   += r3k_dump_tlb.o
  obj-$(CONFIG_CPU_TX39XX)  += r3k_dump_tlb.o
  
  # libgcc-style stuff needed in the kernel

-obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o multi3.o \
-ucmpdi2.o
+obj-y += bswapsi.o bswapdi.o multi3.o


Have you missed deleting the files?


Oops, got lost during the rebase :-/

Thanks,
Matt



Cheers
James

Re: general protection fault in __mem_cgroup_free

[Michal Hocko]

[CC Andrey]

On Sat 31-03-18 13:47:05, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
> Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=8a5de3cce7cdc70e9ebe
> 
> So far this crash happened 14 times on upstream.
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5578311367393280
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5708657048158208
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=6693821748346880
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> RBP: 006dcc20 R08: 0002 R09: 3335
> R10:  R11: 0246 R12: 0030656c69662f2e
> R13: 7f1747954d80 R14:  R15: 0006
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4422 Comm: syzkaller101598 Not tainted 4.16.0-rc7+ #372
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:free_mem_cgroup_per_node_info mm/memcontrol.c:4111 [inline]
> RIP: 0010:__mem_cgroup_free+0x71/0x110 mm/memcontrol.c:4120

Is this a real bug or a KASAN false positive? The RIP points at
free_percpu(pn->lruvec_stat_cpu);

Which can be NULL if we are failing to allocate per-node data in
mem_cgroup_alloc. You stack unwinder seems to point to
mem_cgroup_css_alloc->mem_cgroup_free though and that one cannot see
NULL memcg->nodeinfo[node] AFAICS.

Even if this is really mem_cgroup_alloc path then calling free_percpu
with NULL pointer should be OK. Or am I missing something?

> RSP: 0018:8801accf75a8 EFLAGS: 00010206
> RAX: 0011 RBX:  RCX: 8310cdfd
> RDX:  RSI: 0040 RDI: 0088
> RBP: 8801accf75c8 R08:  R09: 8801accf73a0
> R10:  R11:  R12: 
> R13: 8801ad210d40 R14: dc00 R15: 8801ad210d40
> FS:  7f1747955700() GS:8801db00() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0046 CR3: 0001cb367004 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  mem_cgroup_free mm/memcontrol.c:4128 [inline]
>  mem_cgroup_css_alloc+0x403/0x19c0 mm/memcontrol.c:4239
>  css_create kernel/cgroup/cgroup.c:4729 [inline]
>  cgroup_apply_control_enable+0x44d/0xbc0 kernel/cgroup/cgroup.c:2916
>  cgroup_mkdir+0x56f/0xfc0 kernel/cgroup/cgroup.c:4938
>  kernfs_iop_mkdir+0x153/0x1e0 fs/kernfs/dir.c:1099
>  vfs_mkdir+0x390/0x600 fs/namei.c:3800
>  SYSC_mkdirat fs/namei.c:3823 [inline]
>  SyS_mkdirat+0x22b/0x2b0 fs/namei.c:3807
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x44a0c9
> RSP: 002b:7f1747954d78 EFLAGS: 0246 ORIG_RAX: 0102
> RAX: ffda RBX: 006dcc24 RCX: 0044a0c9
> RDX: 0020 RSI: 2280 RDI: 0005
> RBP: 006dcc20 R08: 0002 R09: 3335
> R10:  R11: 0246 R12: 0030656c69662f2e
> R13: 7f1747954d80 R14:  R15: 0006
> Code: 00 00 48 89 f8 48 c1 e8 03 42 80 3c 30 00 0f 85 99 00 00 00 4f 8b a4
> e5 f0 09 00 00 49 8d bc 24 88 00 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00
> 0f 85 88 00 00 00 49 8b bc 24 88 00 00 00 e8 77
> RIP: free_mem_cgroup_per_node_info mm/memcontrol.c:4111 [inline] RSP:
> 8801accf75a8
> RIP: __mem_cgroup_free+0x71/0x110 mm/memcontrol.c:4120 RSP: 8801accf75a8
> ---[ end trace 57ac07c30502ef78 ]---
> Kernel panic - not syncing: Fatal exception
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Jani Nikula]

On Fri, 30 Mar 2018, Colin King  wrote:
> From: Colin Ian King 
>
> Trivial fix to spelling mistake in DRM_ERROR error message text

Thanks for the patch.

Please do consider limiting the distribution in the future,
though. There's no need to include lkml or even dri-devel for trivial
patches like this.

Thanks,
Jani.

>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e42a28e3adc5..1df1c91b6ae5 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1521,7 +1521,7 @@ static int amdgpu_dm_initialize_drm_device(struct 
> amdgpu_device *adev)
>   break;
>  #endif
>   default:
> - DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
> + DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
>   goto fail;
>   }
>  
> @@ -1715,7 +1715,7 @@ static int dm_early_init(void *handle)
>   break;
>  #endif
>   default:
> - DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
> + DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
>   return -EINVAL;
>   }

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [GIT PULL] x86/build changes for v4.17

[Ingo Molnar]

* Peter Zijlstra  wrote:

> On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote:
> > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar  wrote:
> > >
> > > The biggest change is the forcing of asm-goto support on x86, which 
> > > effectively
> > > increases the GCC minimum supported version to gcc-4.5 (on x86).
> > 
> > So my biggest worry isn't gcc-4.5 (anybody who hasn't updated deserves
> > to be forced, or can stay with old kernels).
> > 
> > No, my biggest worry is clang. What's the status there?
> > 
> > I've pulled this, and honestly, the disaster with
> > -fmerge-all-constants makes me think that clang isn't that good a
> > compiler choice anyway, but it's sad if this undoes a lot of clang
> > work just because of the worries about Spectre and mis-speculated
> > branches.
> 
> It's not just spectre, I believe you yourself wanted to use asm-goto
> somewhere in the x86 code:
> 
>   
> http://lkml.kernel.org/r/CA+55aFyCp-9Qqjcn9wp=vdp2ko7tfyuumjxvkc75xxu0web...@mail.gmail.com
> 
> There was some KVM talk of relying on it here:
> 
>   http://lkml.kernel.org/r/6a5f2453-cf51-d491-db54-5f239caa2...@redhat.com
> 
> And there's the comment here:
> 
>   
> https://elixir.bootlin.com/linux/v4.16-rc7/source/arch/x86/kvm/emulate.c#L457
> 
> As to the suitablility of using clang, there's also this unresolved
> issue:
> 
>   http://lkml.kernel.org/r/20180321211931.ga111...@google.com
> 
> The fact that even without asm-goto they cannot correctly compile a
> kernel and have sat on their hands regarding asm-goto for the past 7 odd
> years makes me care very little.
> 
> And since they need to spin a new version of the compiler with all the
> various bugs fixed, they might as well include asm-goto in that and be
> done with it.

So there's really two questions here:

 - This asm-goto change only impacts x86, is there any production x86 kernel 
being
   built with Clang? I think the Pixel kernel is built with Clang, but that's 
ARM.

 - Is there anyone on the Clang side _actually_ bending metal and working on 
   asm-goto support, with something like very early alpha test patches 
available, 
   etc.? Last I saw the communicated Clang POV was still that they wanted to do 
   something "better" (and incompatible to ...) asm-goto. Has this changed?

If it's being relied on, or if there's actually something firmly planned,
which we could track, then I'd have no problem with reverting this change
and waiting one more kernel cycle or so.

Thanks,

Ingo

Re: [PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Dan Carpenter]

On Tue, Apr 03, 2018 at 11:41:05AM +0200, Julia Lawall wrote:
> 
> 
> On Tue, 3 Apr 2018, Jani Nikula wrote:
> 
> > On Fri, 30 Mar 2018, Colin King  wrote:
> > > From: Colin Ian King 
> > >
> > > Trivial fix to spelling mistake in DRM_ERROR error message text
> >
> > Thanks for the patch.
> >
> > Please do consider limiting the distribution in the future,
> > though. There's no need to include lkml or even dri-devel for trivial
> > patches like this.
> 
> It's complex to have to remember the preferences for every subsystem.
> Preferences should be expressed in the MAINTAINERS file in some way.
> Also, since no one reads lkml, does it hurt to have even trivial patches?

I always tell people not to CC lkml when there is a smaller subsystem
list which can handle it but Linus said my advice was bad.

regards,
dan carpenter

Re: [PATCH] genirq: only scan the present CPUs

[Thomas Gleixner]

On Mon, 2 Apr 2018, Li RongQing wrote:

> lots of application will read /proc/stat, like ps and vmstat, but we
> find the reading time are spreading on Purley platform which has lots
> of possible CPUs and interrupt.
> 
> To reduce the reading time, only scan the present CPUs, not all possible
> CPUs, which speeds the reading of /proc/stat 20 times on Purley platform
> which has 56 present CPUs, and 224 possible CPUs

Why is BIOS/ACPI telling the kernel that there are 224 possible CPUs unless
it supports physical CPU hotplug.

Thanks,

tglx

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

[Sergey Suloev]

On 04/03/2018 11:10 AM, Maxime Ripard wrote:

On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote:

There is no need to handle 3/4 empty/full interrupts as the maximum
supported transfer length in PIO mode is 64 bytes for sun4i-family
SoCs.

That assumes that you'll be able to treat the FIFO full interrupt and
drain the FIFO before we have the next byte coming in. This would
require a real time system, and we're not in one of them.

Maxime



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


so you think we should still handle 3/4 FIFO full ?

Re: [PATCH 1/8] bindings: PCI: designware: Example update

[Gustavo Pimentel]

Hi Kishon,

On 02/04/2018 06:23, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote:
>> Changes the IP registers size to accommodate the ATU unroll space.
>>
>> Replaces "ctrlreg" reg-name by "dbi" to be coherent with similar drivers.
>>
>> Replaces the pcie base address example by a real pcie base address in use.
>>
>> Signed-off-by: Gustavo Pimentel 
>> ---
>>  Documentation/devicetree/bindings/pci/designware-pcie.txt | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
>> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> index 1da7ade..6300762 100644
>> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> @@ -1,7 +1,8 @@
>>  * Synopsys DesignWare PCIe interface
>>  
>>  Required properties:
>> -- compatible: should contain "snps,dw-pcie" to identify the core.
>> +- compatible:
>> +"snps,dw-pcie" for RC mode;
> 
> I think irrespective of RC mode or EP mode, "snps,dw-pcie" can be used to
> identify the pcie core?

I guess so. What you suggest? I was just folling the same guideline present
here: https://lkml.org/lkml/2017/11/3/310

>>  - reg: Should contain the configuration address space.
>>  - reg-names: Must be "config" for the PCIe configuration space.
>>  (The old way of getting the configuration address space from "ranges"
>> @@ -41,11 +42,11 @@ EP mode:
>>  
>>  Example configuration:
>>  
>> -pcie: pcie@d000 {
>> +pcie: pcie@dfc0 {
>>  compatible = "snps,dw-pcie";
>> -reg = <0xd000 0x1000>, /* Controller registers */
>> -  <0xd000 0x2000>; /* PCI config space */
>> -reg-names = "ctrlreg", "config";
>> +reg = <0xdfc0 0x302000>, /* IP registers */
> 
> which version of synopsys IP is this. I think the ideal thing to do here is to
> have a separate register space for iATU.

I also agree with that. The unroll iATU was introduced on Synopsys IP version
4.80 and the kernel patch was release on 2016-08-10
https://patchwork.ozlabs.org/patch/657796/
However a separate register space for iATU implies some extra code do handle it
(and of course some tests) that don't fit into this patch series, in my point of
view. Can this task enter in the backlog in order to be done in another patch
series?

> 
> Thanks
> Kishon
> 

Re: KASAN: use-after-free Read in alloc_pid

[Tetsuo Handa]

On 2018/04/03 12:10, Eric Biggers wrote:
> On Mon, Apr 02, 2018 at 06:00:57PM -0500, Eric W. Biederman wrote:
>> syzbot  writes:
>>
>>> Hello,
>>>
>>> syzbot hit the following crash on upstream commit
>>> 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
>>> Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client
>>> syzbot dashboard link:
>>> https://syzkaller.appspot.com/bug?extid=7a1cff37dbbef9e7ba4c
>>>
>>> So far this crash happened 4 times on upstream.
>>>
>>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> Do you have any of the other traces?  This looks like a something is
>> calling put_pid_ns more than it is calling get_pid_ns causing a
>> reference count mismatch.
>>
>> If this is not: 9ee332d99e4d5a97548943b81c54668450ce641b

Yes, that commit is the trigger. Al wrote patches. Let's check them.

  http://lkml.kernel.org/r/20180402143415.gc30...@zeniv.linux.org.uk
  http://lkml.kernel.org/r/20180403052009.gh30...@zeniv.linux.org.uk

--
struct pid *alloc_pid(struct pid_namespace *ns) {
(...snipped...)
if (unlikely(is_child_reaper(pid))) {
if (pid_ns_prepare_proc(ns)) // ns is freed upon failure.
goto out_free;
}
(...snipped...)
out_free:
spin_lock_irq(_lock);
while (++i <= ns->level) // <= ns is already freed by 
destroy_pid_namespace() explained below.
idr_remove(>idr, (pid->numbers + i)->nr);
(...snipped...)
}
--

--
int pid_ns_prepare_proc(struct pid_namespace *ns) {
  mnt = kern_mount_data(_fs_type, ns) { // <= ns is passed as ns.
mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->name, data) { // <= ns is 
passed as data.
  root = mount_fs(type, SB_KERNMOUNT, name, data) { // <= ns is passed as 
data.
root = type->mount(type, SB_KERNMOUNT, name, data) = // <= ns is passed 
as data.
static struct dentry *proc_mount(struct file_system_type *fs_type, int 
flags, const char *dev_name, void *data) {
  return mount_ns(fs_type, SB_KERNMOUNT, NULL, ns, ns->user_ns, 
proc_fill_super) { // <= ns is passed as ns.
sb = sget_userns(fs_type, ns_test_super, ns_set_super, 
SB_KERNMOUNT, user_ns, ns) { // <= ns is passed as ns.
  err = set(s, data) = // <= ns is passed as data.
  static int ns_set_super(struct super_block *sb, void *data) {
sb->s_fs_info = data; // ns is associated here.
  }
  err = register_shrinker(>s_shrink); // <= fail by fault 
injection.
  deactivate_locked_super(s) {
fs->kill_sb(s) =
static void proc_kill_sb(struct super_block *sb) {
  ns = (struct pid_namespace *)sb->s_fs_info;
  put_pid_ns(ns) { // <= ns is passed as ns
kref_put(>kref, free_pid_ns) { // <= ns refcount 
becomes 0
  destroy_pid_namespace(ns) {
call_rcu(>rcu, delayed_free_pidns) {
  kmem_cache_free(pid_ns_cachep, ns); // <= ns is 
released here after RCU grace period
}
  }
}
  }
}
  }
}
  }
}
  }
}
  }
}
--

>>
>> I could use a few more hints to help narrow down what is going wrong.
>>
>> It would be nice to know what the other 3 crashes looked like and
>> exactly which upstream they were on.
>>
> 
> The other crashes are shown on the syzbot dashboard (link was given in the
> original email).
> 
> Eric
> 

Re: [PATCH v2 2/2] io: prevent compiler reordering on the default readX() implementation

[Arnd Bergmann]

On Tue, Apr 3, 2018 at 12:49 PM, Mark Rutland  wrote:
> Hi,
>
> On Fri, Mar 30, 2018 at 11:58:13AM -0400, Sinan Kaya wrote:
>> The default implementation of mapping readX() to __raw_readX() is wrong.
>> readX() has stronger ordering semantics. Compiler is allowed to reorder
>> __raw_readX().
>
> Could you please specify what the compiler is potentially reordering
> __raw_readX() against, and why this would be wrong?
>
> e.g. do we care about prior normal memory accesses, subsequent normal
> memory accesses, and/or other IO accesses?
>
> I assume that the asm-generic __raw_{read,write}X() implementations are
> all ordered w.r.t. each other (at least for a specific device).

I think that is correct: the compiler won't reorder those because of the
'volatile' pointer dereference, but it can reorder access to a normal
pointer against a __raw_readl()/__raw_writel(), which breaks the scenario
of using writel to trigger a DMA, or using a readl to see if a DMA has
completed.

The question is whether we should use a stronger barrier such
as rmb() amd wmb() here rather than a simple compiler barrier.

I would assume that on complex architectures with write buffers and
out-of-order prefetching, those are required, while on architectures
without those features, the barriers are cheap.

  Arnd

Re: [PATCH v5 08/13] ARM: sunxi: Add initialization of CNTVOFF

[kbuild test robot]

Hi Mylène,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Myl-ne-Josserand/Sunxi-Add-SMP-support-on-A83T/20180403-143751
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
config: arm-arm67 (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   arch/arm/mach-sunxi/sunxi.o: In function `sun8i_cntvoff_init':
>> sunxi.c:(.init.text+0x3c): undefined reference to `smp_init_cntvoff'

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


.config.gz
Description: application/gzip

Re: [PATCH v3 09/14] s390: vfio-ap: sysfs interfaces to configure domains

[Cornelia Huck]

On Wed, 14 Mar 2018 14:25:49 -0400
Tony Krowiak  wrote:

> Provides the sysfs interfaces for assigning AP domains to
> and unassigning AP domains from a mediated matrix device.
> 
> An AP domain ID corresponds to an AP queue index (APQI). For
> each domain assigned to the mediated matrix device, its
> corresponging APQI is stored in an AP queue mask (AQM).
> The bits in the AQM, from most significant to least
> significant bit, correspond to AP domain numbers 0 to 255.
> When a domain is assigned, the bit corresponding to its
> APQI will be set in the AQM. Likewise, when a domain is
> unassigned, the bit corresponding to its APQI will be
> cleared from the AQM.
> 
> The relevant sysfs structures are:
> 
> /sys/devices/vfio_ap
> ... [matrix]
> .. [mdev_supported_types]
> . [vfio_ap-passthrough]
>  [devices]
> ...[$uuid]
> .. assign_domain
> .. unassign_domain
> 
> To assign a domain to the $uuid mediated matrix device,
> write the domain's ID to the assign_domain file. To
> unassign a domain, write the domain's ID to the
> unassign_domain file. The ID is specified using
> conventional semantics: If it begins with 0x, the number
> will be parsed as a hexadecimal (case insensitive) number;
> otherwise, it will be parsed as a decimal number.
> 
> For example, to assign domain 173 (0xad) to the mediated matrix
> device $uuid:
> 
>   echo 173 > assign_domain
> 
>   or
> 
>   echo 0xad > assign_domain
> 
> To unassign domain 173 (0xad):
> 
>   echo 173 > unassign_domain
> 
>   or
> 
>   echo 0xad > unassign_domain
> 
> The assignment will be rejected:
> 
> * If the domain ID exceeds the maximum value for an AP domain:
> 
>   * If the AP Extended Addressing (APXA) facility is installed,
> the max value is 255
> 
>   * Else the max value is 15
> 
> * If no AP adapters have yet been assigned and there are
>   no AP queues reserved by the VFIO AP driver that have an APQN
>   with an APQI matching that of the AP domain number being
>   assigned.
> 
> * If any of the APQNs that can be derived from the intersection
>   of the APQI being assigned and the AP adapter ID (APID) of
>   each of the AP adapters previously assigned can not be matched
>   with an APQN of an AP queue device reserved by the VFIO AP
>   driver.
> 
> Signed-off-by: Tony Krowiak 
> ---
>  arch/s390/include/asm/kvm-ap.h|1 +
>  drivers/s390/crypto/vfio_ap_ops.c |  215 
> -
>  2 files changed, 215 insertions(+), 1 deletions(-)
> 

> diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
> b/drivers/s390/crypto/vfio_ap_ops.c
> index 90512a6..c448835 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -377,10 +377,223 @@ static ssize_t unassign_adapter_store(struct device 
> *dev,
>  }
>  DEVICE_ATTR_WO(unassign_adapter);
>  
> +/**
> + * vfio_ap_validate_queues_for_apqi
> + *
> + * @ap_matrix: the matrix device
> + * @matrix_mdev: the mediated matrix device
> + * @apqi: an AP queue index (APQI) - corresponds to a domain ID
> + *
> + * Verifies that each APQN that is derived from the intersection of @apqi and
> + * each AP adapter ID (APID) corresponding to an AP domain assigned to the
> + * @matrix_mdev matches the APQN of an AP queue reserved by the VFIO AP 
> device
> + * driver.
> + *
> + * Returns 0 if validation succeeds; otherwise, returns an error.
> + */
> +static int vfio_ap_validate_queues_for_apqi(struct ap_matrix *ap_matrix,
> + struct ap_matrix_mdev *matrix_mdev,
> + unsigned long apqi)
> +{
> + int ret;
> + struct vfio_ap_qid_match qid_match;
> + unsigned long apid;
> + struct device_driver *drv = ap_matrix->device.driver;
> +
> + /**
> +  * Examine each APQN with the specified APQI
> +  */
> + for_each_set_bit_inv(apid, matrix_mdev->matrix->apm,
> +  matrix_mdev->matrix->apm_max) {
> + qid_match.qid = AP_MKQID(apid, apqi);
> + qid_match.dev = NULL;
> +
> + ret = driver_for_each_device(drv, NULL, _match,
> +  vfio_ap_queue_match);
> + if (ret)
> + return ret;

Hm, I'm wondering whether jumping out of the outer loop is the correct
thing to do here - and if yes, whether we should log an error?

> +
> + /*
> +  * If the APQN identifies an AP queue that is reserved by the
> +  * VFIO AP device driver, continue processing.
> +  */
> + if (qid_match.dev)
> + continue;
> +
> + pr_err("%s: AP queue %02lx.%04lx not reserved by %s driver",
> +VFIO_AP_MATRIX_MODULE_NAME, apqi, apqi,
> +VFIO_AP_DRV_NAME);
> +
> + return -ENXIO;
> + }
> 

[GIT PULL] EDAC tree for 4.17

[Borislav Petkov]

Hi Linus,

here's this round of EDAC updates. Noteworthy is the NVDIMM support
by Tony Luck.

Please pull,
thanks!

---
The following changes since commit bf8486709ac7fad99e4040dea73fe466c57a4ae1:

  EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL 
(2018-02-23 12:05:37 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_for_4.17

for you to fetch changes up to 6fd052665274b4e7570491ba272f2dbb09cbbcd5:

  EDAC, sb_edac: Remove variable length array usage (2018-03-17 05:24:55 +0100)


* Add NVDIMM support to EDAC (Tony Luck)

* misc fixes


Gustavo A. R. Silva (1):
  EDAC, sb_edac: Remove variable length array usage

Rasmus Villemoes (1):
  EDAC, layerscape: Allow building for LS1021A

Tony Luck (5):
  EDAC: Drop duplicated array of strings for memory type names
  EDAC: Add new memory type for non-volatile DIMMs
  acpi, nfit: Add function to look up nvdimm device and provide SMBIOS 
handle
  firmware, DMI: Add function to look up a handle and return DIMM size
  EDAC, skx_edac: Detect non-volatile DIMMs

 drivers/acpi/nfit/core.c | 27 ++
 drivers/edac/Kconfig |  7 +++--
 drivers/edac/edac_mc.c   | 41 ++-
 drivers/edac/edac_mc_sysfs.c | 26 ++---
 drivers/edac/sb_edac.c   | 12 
 drivers/edac/skx_edac.c  | 67 
 drivers/firmware/dmi_scan.c  | 31 
 include/acpi/nfit.h  | 18 
 include/linux/dmi.h  |  2 ++
 include/linux/edac.h |  3 ++
 10 files changed, 175 insertions(+), 59 deletions(-)
 create mode 100644 include/acpi/nfit.h

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] sched: support dynamiQ cluster

[Vincent Guittot]

Hi Valentin,

On 3 April 2018 at 00:27, Valentin Schneider  wrote:
> Hi,
>
> On 30/03/18 13:34, Vincent Guittot wrote:
>> Hi Morten,
>>
> [..]
>>>
>>> As I see it, the main differences is that ASYM_PACKING attempts to pack
>>> all tasks regardless of task utilization on the higher capacity cpus
>>> whereas the "misfit task" series carefully picks cpus with tasks they
>>> can't handle so we don't risk migrating tasks which are perfectly
>>
>> That's one main difference because misfit task will let middle range
>> load task on little CPUs which will not provide maximum performance.
>> I have put an example below
>>
>>> suitable to for a little cpu to a big cpu unnecessarily. Also it is
>>> based directly on utilization and cpu capacity like the capacity
>>> awareness we already have to deal with big.LITTLE in the wake-up path.
>
> I think that bit is quite important. AFAICT, ASYM_PACKING disregards
> task utilization, it only makes sure that (with your patch) tasks will be
> migrated to big CPUS if those ever go idle (pulls at NEWLY_IDLE balance or
> later on during nohz balance). I didn't see anything related to ASYM_PACKING
> in the wake path.
>
>>> Have to tried taking the misfit patches for a spin on your setup? I
>>> expect them give you the same behaviour as you report above.
>>
>> So I have tried both your tests and mine on both patchset and they
>> provide same results which is somewhat expected as the benches are run
>> for several seconds.
>> In other to highlight the main difference between misfit task and
>> ASYM_PACKING, I have reused your test and reduced the number of
>> max-request for sysbench so that the test duration was in the range of
>> hundreds ms.
>>
>> Hikey960 (emulate dynamiq topology)
>>min avg(stdev)  max
>> misfit 0.0975000.114911(+- 10%)0.138500
>> asym   0.0925000.106072(+-  6%)0.122900
>>
>> In this case, we can see that ASYM_PACKING is doing better( 8%)
>> because it migrates sysbench threads on big core as soon as they are
>> available whereas misfit task has to wait for the utilization to
>> increase above the 80% which takes around 70ms when starting with an
>> utilization that is null
>>
>
> I believe ASYM_PACKING behaves better here because the workload is only
> sysbench threads. As stated above, since task utilization is disregarded, I

It behaves better because it doesn't wait for the task's utilization
to reach a level before assuming the task needs high compute capacity.
The utilization gives an idea of the running time of the task not the
performance level that is needed

> think we could have a scenario where the big CPUs are filled with "small"
> tasks and the LITTLE CPUs hold a few "big" tasks - because what mostly
> matters here is the order in which the tasks spawn, not their utilization -
> which is potentially broken.
>
> There's that bit in *update_sd_pick_busiest()*:
>
> /* No ASYM_PACKING if target CPU is already busy */
> if (env->idle == CPU_NOT_IDLE)
> return true;
>
> So I'm not entirely sure how realistic that scenario is, but I suppose it
> could still happen. Food for thought in any case.
>
> Regards,
> Valentin

Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

[Sergey Senozhatsky]

On (04/02/18 11:21), Maninder Singh wrote:
[..]
> >>  static const char * const backends[] = {
> >>  "lzo",
> >>  #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
> >>  "lz4",
> >> +#if (PAGE_SIZE < (32 * KB))
> >> +"lz4_dyn",
> >> +#endif
> > 
> >This is not the list of supported algorithms. It's the list of
> >recommended algorithms. You can configure zram to use any of
> >available and known to Crypto API algorithms. Including lz4_dyn
> >on PAGE_SIZE > 32K systems.
> > 
> Yes, we want to integrate new compression(lz4_dyn) for ZRAM 
> only if PAGE_SIZE is less than 32KB to get maximum benefit. 
> so we added lz4_dyn to available list of ZRAM compression alhorithms.

Which is not what I was talking about.

You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that
'page should be less than 32KB', which I'm sure will be confusing. And you
rely on lz4_dyn users to do the right thing - namely, to use that 'nice'
`#if (PAGE_SIZE < (32 * KB))'. Apart from that, lz4_dyn supports only data
in up to page_size chunks. Suppose my system has page_size of less than 32K,
so I legitimately can enable lz4_dyn, but suppose that I will use it
somewhere where I don't work with page_size-d chunks. Will I able to just
do tfm->compress(src, sz) on random buffers? The whole thing looks to be
quite fragile.

-ss

Re: [PATCH v1] kernel/trace:check the val against the available mem

[Michal Hocko]

On Tue 03-04-18 08:23:48, Steven Rostedt wrote:
> On Tue, 3 Apr 2018 14:16:14 +0200
> Michal Hocko  wrote:
> 
> > > This came up because there's scripts or programs that set the size of
> > > the ring buffer. The complaint was that the application would just set
> > > the size to something bigger than what was available and cause an OOM
> > > killing other applications. The final solution is to simply check the
> > > available memory before allocating the ring buffer:
> > > 
> > >   /* Check if the available memory is there first */
> > >   i = si_mem_available();
> > >   if (i < nr_pages)
> > >   return -ENOMEM;
> > > 
> > > And it works well.  
> > 
> > Except that it doesn't work. si_mem_available is not really suitable for
> > any allocation estimations. Its only purpose is to provide a very rough
> > estimation for userspace. Any other use is basically abuse. The
> > situation can change really quickly. Really it is really hard to be
> > clever here with the volatility the memory allocations can cause.
> 
> OK, then what do you suggest? Because currently, it appears to work. A
> rough estimate may be good enough.
> 
> If we use NORETRY, then we have those that complain that we do not try
> hard enough to reclaim memory. If we use RETRY_MAYFAIL we have this
> issue of taking up all memory before we get what we want.

Just try to do what admin asks for and trust it will not try to shoot
his foot? I mean there are other ways admin can shoot the machine down.
Being clever is OK if it doesn't add a tricky code. And relying on
si_mem_available is definitely tricky and obscure.

> Perhaps I should try to allocate a large group of pages with
> RETRY_MAYFAIL, and if that fails go back to NORETRY, with the thinking
> that the large allocation may reclaim some memory that would allow the
> NORETRY to succeed with smaller allocations (one page at a time)?

That again relies on a subtle dependencies of the current
implementation. So I would rather ask whether this is something that
really deserves special treatment. If admin asks for a buffer of a
certain size then try to do so. If we get OOM then bad luck you cannot
get large memory buffers for free...
-- 
Michal Hocko
SUSE Labs

[PATCH 3/5] MIPS: perf: Fix perf with MT counting other threads

[Matt Redfearn]

When perf is used in non-system mode, i.e. without specifying CPUs to
count on, check_and_calc_range falls into the case when it sets
M_TC_EN_ALL in the counter config_base. This has the impact of always
counting for all of the threads in a core, even when the user has not
requested it. For example this can be seen with a test program which
executes 30002 instructions and 1 branches running on one VPE and a
busy load on the other VPE in the core. Without this commit, the
expected count is not returned:

taskset 4 dd if=/dev/zero of=/dev/null count=10 & taskset 8 perf
stat -e instructions:u,branches:u ./test_prog

 Performance counter stats for './test_prog':

103235  instructions:u
 17015  branches:u

In order to fix this, remove check_and_calc_range entirely and perform
all of the logic in mipsxx_pmu_enable_event. Since
mipsxx_pmu_enable_event now requires the range of the event, ensure that
it is set by mipspmu_perf_event_encode in the same circumstances as
before (i.e. IS_ENABLED(CONFIG_MIPS_MT_SMP) && num_possible_cpus() > 1).

The logic of mipsxx_pmu_enable_event now becomes:
If the CPU is a BMIPS5000, then use the special vpe_id() implementation
to select which VPE to count.
If the counter has a range greater than a single VPE, i.e. it is a
core-wide counter, then ensure that the counter is set up to count
events from all TCs (though, since this is true by definition, is this
necessary? Just enabling a core-wide counter in the per-VPE case appears
experimentally to return the same counts. This is left in for now as the
logic was present before).
If the event is set up to count a particular CPU (i.e. system mode),
then the VPE ID of that CPU is used for the counter.
Otherwise, the event should be counted on the CPU scheduling this thread
(this was the critical bit missing from the previous implementation) so
the VPE ID of this CPU is used for the counter.

With this commit, the same test as before returns the counts expected:

taskset 4 dd if=/dev/zero of=/dev/null count=10 & taskset 8 perf
stat -e instructions:u,branches:u ./test_prog

 Performance counter stats for './test_prog':

 30002  instructions:u
 1  branches:u

Signed-off-by: Matt Redfearn 
---

 arch/mips/kernel/perf_event_mipsxx.c | 69 +++-
 1 file changed, 29 insertions(+), 40 deletions(-)

diff --git a/arch/mips/kernel/perf_event_mipsxx.c 
b/arch/mips/kernel/perf_event_mipsxx.c
index bb8c6783e9a5..782a1b6c6352 100644
--- a/arch/mips/kernel/perf_event_mipsxx.c
+++ b/arch/mips/kernel/perf_event_mipsxx.c
@@ -325,7 +325,9 @@ static int mipsxx_pmu_alloc_counter(struct cpu_hw_events 
*cpuc,
 
 static void mipsxx_pmu_enable_event(struct hw_perf_event *evt, int idx)
 {
+   struct perf_event *event = container_of(evt, struct perf_event, hw);
struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
+   unsigned int range = evt->event_base >> 24;
 
WARN_ON(idx < 0 || idx >= mipspmu.num_counters);
 
@@ -333,11 +335,30 @@ static void mipsxx_pmu_enable_event(struct hw_perf_event 
*evt, int idx)
(evt->config_base & M_PERFCTL_CONFIG_MASK) |
/* Make sure interrupt enabled. */
MIPS_PERFCTRL_IE;
-   if (IS_ENABLED(CONFIG_CPU_BMIPS5000))
+
+   if (IS_ENABLED(CONFIG_CPU_BMIPS5000)) {
/* enable the counter for the calling thread */
cpuc->saved_ctrl[idx] |=
(1 << (12 + vpe_id())) | BRCM_PERFCTRL_TC;
+   } else if (range > V) {
+   /* The counter is processor wide. Set it up to count all TCs. */
+   pr_debug("Enabling perf counter for all TCs\n");
+   cpuc->saved_ctrl[idx] |= M_TC_EN_ALL;
+   } else {
+   unsigned int cpu, ctrl;
+
+   /*
+* Set up the counter for a particular CPU when event->cpu is
+* a valid CPU number. Otherwise set up the counter for the CPU
+* scheduling this thread.
+*/
+   cpu = (event->cpu >= 0) ? event->cpu : smp_processor_id();
 
+   ctrl = M_PERFCTL_VPEID(cpu_vpe_id(_data[cpu]));
+   ctrl |= M_TC_EN_VPE;
+   cpuc->saved_ctrl[idx] |= ctrl;
+   pr_debug("Enabling perf counter for CPU%d\n", cpu);
+   }
/*
 * We do not actually let the counter run. Leave it until start().
 */
@@ -650,14 +671,13 @@ static unsigned int mipspmu_perf_event_encode(const 
struct mips_perf_event *pev)
  * Top 8 bits for range, next 16 bits for cntr_mask, lowest 8 bits for
  * event_id.
  */
-#ifdef CONFIG_MIPS_MT_SMP
-   return ((unsigned int)pev->range << 24) |
-   (pev->cntr_mask & 0x00) |
-   (pev->event_id & 0xff);
-#else
-   return (pev->cntr_mask & 0x00) |
-   (pev->event_id & 0xff);
-#endif
+   if 

[PATCH 4/5] MIPS: perf: Allocate per-core counters on demand

[Matt Redfearn]

Previously when performance counters are per-core, rather than
per-thread, the number available were divided by 2 on detection, and the
counters used by each thread in a core were "swizzled" to ensure
separation. However, this solution is suboptimal since it relies on a
couple of assumptions:
a) Always having 2 VPEs / core (number of counters was divided by 2)
b) Always having a number of counters implemented in the core that is
   divisible by 2. For instance if an SoC implementation had a single
   counter and 2 VPEs per core, then this logic would fail and no
   performance counters would be available.
The mechanism also does not allow for one VPE in a core using more than
it's allocation of the per-core counters to count multiple events even
though other VPEs may not be using them.

Fix this situation by instead allocating (and releasing) per-core
performance counters when they are requested. This approach removes the
above assumptions and fixes the shortcomings.

In order to do this:
Add additional logic to mipsxx_pmu_alloc_counter() to detect if a
sibling is using a per-core counter, and to allocate a per-core counter
in all sibling CPUs.
Similarly, add a mipsxx_pmu_free_counter() function to release a
per-core counter in all sibling CPUs when it is finished with.
A new spinlock, core_counters_lock, is introduced to ensure exclusivity
when allocating and releasing per-core counters.
Since counters are now allocated per-core on demand, rather than being
reserved per-thread at boot, all of the "swizzling" of counters is
removed.

The upshot is that in an SoC with 2 counters / thread, counters are
reported as:
Performance counters: mips/interAptiv PMU enabled, 2 32-bit counters
available to each CPU, irq 18

Running an instance of a test program on each of 2 threads in a
core, both threads can use their 2 counters to count 2 events:

taskset 4 perf stat -e instructions:u,branches:u ./test_prog & taskset 8
perf stat -e instructions:u,branches:u ./test_prog

 Performance counter stats for './test_prog':

 30002  instructions:u
 1  branches:u

   0.005164264 seconds time elapsed
 Performance counter stats for './test_prog':

 30002  instructions:u
 1  branches:u

   0.006139975 seconds time elapsed

In an SoC with 2 counters / core (which can be forced by setting
cpu_has_mipsmt_pertccounters = 0), counters are reported as:
Performance counters: mips/interAptiv PMU enabled, 2 32-bit counters
available to each core, irq 18

Running an instance of a test program on each of 2 threads in a
core, now only one thread manages to secure the performance counters to
count 2 events. The other thread does not get any counters.

taskset 4 perf stat -e instructions:u,branches:u ./test_prog & taskset 8
perf stat -e instructions:u,branches:u ./test_prog

 Performance counter stats for './test_prog':

instructions:u
branches:u

   0.005179533 seconds time elapsed

 Performance counter stats for './test_prog':

 30002  instructions:u
 1  branches:u

   0.005179467 seconds time elapsed

Signed-off-by: Matt Redfearn 
---

 arch/mips/kernel/perf_event_mipsxx.c | 130 ---
 1 file changed, 88 insertions(+), 42 deletions(-)

diff --git a/arch/mips/kernel/perf_event_mipsxx.c 
b/arch/mips/kernel/perf_event_mipsxx.c
index 782a1b6c6352..bedb0d5ff3f2 100644
--- a/arch/mips/kernel/perf_event_mipsxx.c
+++ b/arch/mips/kernel/perf_event_mipsxx.c
@@ -131,6 +131,8 @@ static struct mips_pmu mipspmu;
 #ifdef CONFIG_MIPS_PERF_SHARED_TC_COUNTERS
 static int cpu_has_mipsmt_pertccounters;
 
+static DEFINE_SPINLOCK(core_counters_lock);
+
 static DEFINE_RWLOCK(pmuint_rwlock);
 
 #if defined(CONFIG_CPU_BMIPS5000)
@@ -141,20 +143,6 @@ static DEFINE_RWLOCK(pmuint_rwlock);
 0 : cpu_vpe_id(_cpu_data))
 #endif
 
-/* Copied from op_model_mipsxx.c */
-static unsigned int vpe_shift(void)
-{
-   if (num_possible_cpus() > 1)
-   return 1;
-
-   return 0;
-}
-
-static unsigned int counters_total_to_per_cpu(unsigned int counters)
-{
-   return counters >> vpe_shift();
-}
-
 #else /* !CONFIG_MIPS_PERF_SHARED_TC_COUNTERS */
 #define vpe_id()   0
 
@@ -165,17 +153,8 @@ static void pause_local_counters(void);
 static irqreturn_t mipsxx_pmu_handle_irq(int, void *);
 static int mipsxx_pmu_handle_shared_irq(void);
 
-static unsigned int mipsxx_pmu_swizzle_perf_idx(unsigned int idx)
-{
-   if (vpe_id() == 1)
-   idx = (idx + 2) & 3;
-   return idx;
-}
-
 static u64 mipsxx_pmu_read_counter(unsigned int idx)
 {
-   idx = mipsxx_pmu_swizzle_perf_idx(idx);
-
switch (idx) {
case 0:
/*
@@ -197,8 +176,6 @@ static u64 mipsxx_pmu_read_counter(unsigned int idx)
 
 static u64 mipsxx_pmu_read_counter_64(unsigned int idx)
 {
-   idx = mipsxx_pmu_swizzle_perf_idx(idx);
-