[PATCH] KVM: VMX: add encapsulation kvm_vcpu_pi_need_handle

[Peng Hao]

use kvm_vcpu_pi_need_handle encapsulation simply coede

Signed-off-by: Peng Hao 
---
 arch/x86/kvm/vmx.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4253ade..26b99f4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -559,6 +559,13 @@ static inline int pi_test_sn(struct pi_desc *pi_desc)
(unsigned long *)&pi_desc->control);
 }
 
+static inline bool kvm_vcpu_pi_need_handle(struct kvm_vcpu *vcpu)
+{
+   return kvm_arch_has_assigned_device(vcpu->kvm) &&
+   irq_remapping_cap(IRQ_POSTING_CAP)  &&
+   kvm_vcpu_apicv_active(vcpu);
+}
+
 struct vcpu_vmx {
struct kvm_vcpu   vcpu;
unsigned long host_rsp;
@@ -2202,9 +2209,7 @@ static void vmx_vcpu_pi_load(struct kvm_vcpu *vcpu, int 
cpu)
struct pi_desc old, new;
unsigned int dest;
 
-   if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
-   !irq_remapping_cap(IRQ_POSTING_CAP)  ||
-   !kvm_vcpu_apicv_active(vcpu))
+   if (!kvm_vcpu_pi_need_handle(vcpu))
return;
 
do {
@@ -2323,9 +2328,7 @@ static void vmx_vcpu_pi_put(struct kvm_vcpu *vcpu)
 {
struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
 
-   if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
-   !irq_remapping_cap(IRQ_POSTING_CAP)  ||
-   !kvm_vcpu_apicv_active(vcpu))
+   if (!kvm_vcpu_pi_need_handle(vcpu))
return;
 
/* Set SN when the vCPU is preempted */
@@ -11691,9 +11694,7 @@ static int pi_pre_block(struct kvm_vcpu *vcpu)
struct pi_desc old, new;
struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
 
-   if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
-   !irq_remapping_cap(IRQ_POSTING_CAP)  ||
-   !kvm_vcpu_apicv_active(vcpu))
+   if (!kvm_vcpu_pi_need_handle(vcpu))
return 0;
 
vcpu->pre_pcpu = vcpu->cpu;
@@ -11769,9 +11770,7 @@ static void pi_post_block(struct kvm_vcpu *vcpu)
unsigned int dest;
unsigned long flags;
 
-   if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
-   !irq_remapping_cap(IRQ_POSTING_CAP)  ||
-   !kvm_vcpu_apicv_active(vcpu))
+   if (!kvm_vcpu_pi_need_handle(vcpu))
return;
 
do {
@@ -11831,9 +11830,7 @@ static int vmx_update_pi_irte(struct kvm *kvm, unsigned 
int host_irq,
struct vcpu_data vcpu_info;
int idx, ret = -EINVAL;
 
-   if (!kvm_arch_has_assigned_device(kvm) ||
-   !irq_remapping_cap(IRQ_POSTING_CAP) ||
-   !kvm_vcpu_apicv_active(kvm->vcpus[0]))
+   if (!kvm_vcpu_pi_need_handle(kvm->vcpus[0]))
return 0;
 
idx = srcu_read_lock(&kvm->irq_srcu);
-- 
1.8.3.1

Re: [PATCH] staging:rtl8188eu:hal Fix wrong comparison to False

[Dan Carpenter]

On Thu, Sep 21, 2017 at 11:09:55AM +0530, Janani Sankara Babu wrote:
> This patch solves the warning "Using comparison to false is error prone"

Out of curiosity, which tool complains about that?

regards,
dan carpenter

[PATCH] tee: ACPI support for optee driver

[Mayuresh Chitale]

This patch modifies the optee driver to add support for parsing
the conduit method from an ACPI node.

Signed-off-by: Mayuresh Chitale 
---
 drivers/tee/optee/core.c | 112 ---
 1 file changed, 77 insertions(+), 35 deletions(-)

diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 58169e5..8b15c49 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -14,6 +14,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,7 @@
 #include "optee_smc.h"
 
 #define DRIVER_NAME "optee"
+#define OPTEE_DEVICE "\\_SB.OPTE"
 
 #define OPTEE_SHM_NUM_PRIV_PAGES   1
 
@@ -425,29 +427,87 @@ static void optee_smccc_hvc(unsigned long a0, unsigned 
long a1,
arm_smccc_hvc(a0, a1, a2, a3, a4, a5, a6, a7, res);
 }
 
-static optee_invoke_fn *get_invoke_func(struct device_node *np)
+static const struct of_device_id optee_match[] = {
+   { .compatible = "linaro,optee-tz" },
+   {},
+};
+
+#ifdef CONFIG_ACPI
+static const char *get_invoke_str_acpi(void)
 {
-   const char *method;
+   struct acpi_device_info *info;
+   const union acpi_object *obj;
+   struct acpi_device *adev;
+   acpi_status status;
+   acpi_handle handle;
 
-   pr_info("probing for conduit method from DT.\n");
+   status = acpi_get_handle(ACPI_ROOT_OBJECT, OPTEE_DEVICE, &handle);
+   if (ACPI_FAILURE(status))
+   return NULL;
 
-   if (of_property_read_string(np, "method", &method)) {
+   status = acpi_get_object_info(handle, &info);
+   if (ACPI_FAILURE(status) || !(info->valid & ACPI_VALID_HID))
+   return NULL;
+
+   if (acpi_bus_get_device(handle, &adev))
+   return NULL;
+
+   if (acpi_dev_get_property(adev, "method",
+   ACPI_TYPE_ANY, &obj))
+   return NULL;
+
+   return obj->string.pointer;
+}
+#endif
+
+static const char *get_invoke_str_of(void)
+{
+   struct device_node *fw_np;
+   const char *method = NULL;
+   struct device_node *np;
+
+   /* Node is supposed to be below /firmware */
+   fw_np = of_find_node_by_name(NULL, "firmware");
+   if (!fw_np)
+   return NULL;
+
+   np = of_find_matching_node(fw_np, optee_match);
+   of_node_put(fw_np);
+   if (!np)
+   return NULL;
+
+   pr_info("probing for conduit method from DT.\n");
+   if (of_property_read_string(np, "method", &method))
pr_warn("missing \"method\" property\n");
-   return ERR_PTR(-ENXIO);
-   }
 
-   if (!strcmp("hvc", method))
-   return optee_smccc_hvc;
-   else if (!strcmp("smc", method))
-   return optee_smccc_smc;
+   of_node_put(np);
+   return method;
+}
+
+static optee_invoke_fn *get_invoke_func(void)
+{
+   const char *method;
+
+#ifdef CONFIG_ACPI
+   if (!acpi_disabled)
+   method = get_invoke_str_acpi();
+   else
+#endif
+   method = get_invoke_str_of();
+
+   if (method) {
+   if (!strcmp("hvc", method))
+   return optee_smccc_hvc;
+   else if (!strcmp("smc", method))
+   return optee_smccc_smc;
+   }
 
pr_warn("invalid \"method\" property: %s\n", method);
return ERR_PTR(-EINVAL);
 }
 
-static struct optee *optee_probe(struct device_node *np)
+static struct optee *optee_probe(optee_invoke_fn *invoke_fn)
 {
-   optee_invoke_fn *invoke_fn;
struct tee_shm_pool *pool;
struct optee *optee = NULL;
void *memremaped_shm = NULL;
@@ -455,10 +515,6 @@ static struct optee *optee_probe(struct device_node *np)
u32 sec_caps;
int rc;
 
-   invoke_fn = get_invoke_func(np);
-   if (IS_ERR(invoke_fn))
-   return (void *)invoke_fn;
-
if (!optee_msg_api_uid_is_optee_api(invoke_fn)) {
pr_warn("api uid mismatch\n");
return ERR_PTR(-EINVAL);
@@ -570,32 +626,18 @@ static void optee_remove(struct optee *optee)
kfree(optee);
 }
 
-static const struct of_device_id optee_match[] = {
-   { .compatible = "linaro,optee-tz" },
-   {},
-};
-
 static struct optee *optee_svc;
 
 static int __init optee_driver_init(void)
 {
-   struct device_node *fw_np;
-   struct device_node *np;
+   optee_invoke_fn *invoke_fn;
struct optee *optee;
 
-   /* Node is supposed to be below /firmware */
-   fw_np = of_find_node_by_name(NULL, "firmware");
-   if (!fw_np)
-   return -ENODEV;
-
-   np = of_find_matching_node(fw_np, optee_match);
-   of_node_put(fw_np);
-   if (!np)
-   return -ENODEV;
-
-   optee = optee_probe(np);
-   of_node_put(np);
+   invoke_fn = get_invoke_func();
+   if (IS_ERR(invoke_fn))
+   return PTR_ERR(invoke_fn);
 
+   optee = optee_probe(invoke_fn)

Re: [PATCH] staging:rtl8188eu Remove unnecessary {} braces in

[Dan Carpenter]

On Thu, Sep 21, 2017 at 12:18:04PM +0530, Janani Sankara Babu wrote:
> --- a/drivers/staging/rtl8188eu/hal/phy.c
> +++ b/drivers/staging/rtl8188eu/hal/phy.c
> @@ -728,9 +728,9 @@ static void patha_fill_iqk(struct adapter *adapt, bool 
> iqkok, s32 result[][8],
>   u32 oldval_0, x, tx0_a, reg;
>   s32 y, tx0_c;
>  
> - if (final_candidate == 0xFF) {
> + if (final_candidate == 0xFF)
>   return;
> - } else if (iqkok) {
> + else if (iqkok) {

No.  These ones stay.  Your change would introduce a new checkpatch.pl
warning if you ran it against the patched file.  The rule here is that
if one side of the if else has curly braces then both sides get them.

regards,
dan carpenter

Re: [PATCH -next v2] mtd: nand: Add support for Toshiba BENAND (Built-in ECC NAND)

[Boris Brezillon]

On Thu, 21 Sep 2017 14:32:02 +0900
KOBAYASHI Yoshitake  wrote:

> This patch enables support for Toshiba BENAND.
> The current implementation does not support vondor specific command

   ^ vendor

> TOSHIBA_NAND_CMD_ECC_STATUS. I would like to add the command, when
> the exec_op() [1] infrastructure is implemented.

It's not a good idea to reference a branch that is likely to disappear
in a commit message. Just say that you can't properly support the
TOSHIBA_NAND_CMD_ECC_STATUS operation right and that it might be
addressed in the future.

> 
> [1] https://github.com/bbrezillon/linux/commits/nand/exec_op1
> 
> Changelog[v2]:
> Rewrite to adapt the mtd "separate vendor specific code from
> core" cleanup process that based on comments from the following
> discussion.
> http://patchwork.ozlabs.org/patch/767191/

I know it's different for each subsystem, but for MTD, we don't put
changelogs in the commit message.

> 
> Signed-off-by: KOBAYASHI Yoshitake 
> ---

Move the changelog here.

>  drivers/mtd/nand/nand_toshiba.c | 100 
> 
>  1 file changed, 100 insertions(+)
> 
> diff --git a/drivers/mtd/nand/nand_toshiba.c b/drivers/mtd/nand/nand_toshiba.c
> index 57df857..7a99bbe 100644
> --- a/drivers/mtd/nand/nand_toshiba.c
> +++ b/drivers/mtd/nand/nand_toshiba.c
> @@ -17,6 +17,72 @@
>  
>  #include 
>  
> +/* ECC Status Read Command for BENAND */
> +#define TOSHIBA_NAND_CMD_ECC_STATUS  0x7A
> +
> +/* Recommended to rewrite for BENAND */
> +#define TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED  BIT(3)
> +
> +static int toshiba_nand_benand_status_chk(struct mtd_info *mtd,
> +   struct nand_chip *chip)
> +{
> + unsigned int max_bitflips = 0;
> + u8 status;
> +
> + /* Check Read Status */
> + chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
> + status = chip->read_byte(mtd);
> +
> + /*
> +  * TOSHIBA_NAND_CMD_ECC_STATUS is vendor specific command.
> +  * We will rewrite this code, after the ->exec_op() infrastructure
> +  * is implemented

Missing period at the end of your sentence. And again, I would not name
the future stuff here. Just say that currently you have no way to send
arbitrary sequences of CMD+ADDR+DATA cycles and thus cannot support this
custom TOSHIBA_NAND_CMD_ECC_STATUS operation. 

> +  * Now, we set max_bitflips mtd->bitflip_threshold.

   For now,

> +  */
> + if (status & NAND_STATUS_FAIL) {
> + /* uncorrectable */
> + mtd->ecc_stats.failed++;
> + } else if (status & TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED) {
> + /* correctable */
> + max_bitflips = mtd->bitflip_threshold;
> + mtd->ecc_stats.corrected += max_bitflips;
> + }

Is this working correctly when you read more than one ECC chunk? The
ECC step size is 512 bytes and the page is bigger than that, which means
you have more than one ECC chunk per page. What happens to the
NAND_STATUS_FAIL flag if the first chunk is uncorrectable but
following ones are correctable (or do not contain bitflips at all)? 

> +
> + return max_bitflips;
> +}
> +
> +static int
> +toshiba_nand_read_page_benand(struct mtd_info *mtd,
> +   struct nand_chip *chip, uint8_t *buf,
> +   int oob_required, int page)
> +{
> + unsigned int max_bitflips = 0;
> +
> + chip->ecc.read_page_raw(mtd, chip, buf, oob_required, page);

Call nand_read_page_raw() directly.

> + max_bitflips = toshiba_nand_benand_status_chk(mtd, chip);

return toshiba_nand_benand_status_chk(mtd, chip);

> +
> + return max_bitflips;
> +}
> +
> +static int
> +toshiba_nand_read_subpage_benand(struct mtd_info *mtd,
> +  struct nand_chip *chip, uint32_t data_offs,
> +  uint32_t readlen, uint8_t *bufpoi, int page)
> +{
> + uint8_t *p;
> + unsigned int max_bitflips = 0;
> +
> + if (data_offs != 0)
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, data_offs, -1);
> +
> + p = bufpoi + data_offs;
> + chip->read_buf(mtd, p, readlen);
> +
> + max_bitflips = toshiba_nand_benand_status_chk(mtd, chip);

return toshiba_nand_benand_status_chk(mtd, chip);

> +
> + return max_bitflips;
> +}
> +
>  static void toshiba_nand_decode_id(struct nand_chip *chip)
>  {
>   struct mtd_info *mtd = nand_to_mtd(chip);
> @@ -39,9 +105,43 @@ static void toshiba_nand_decode_id(struct nand_chip *chip)
>  
>  static int toshiba_nand_init(struct nand_chip *chip)
>  {
> + struct mtd_info *mtd = nand_to_mtd(chip);
> +
>   if (nand_is_slc(chip))
>   chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
>  
> + if (nand_is_slc(chip) && (chip->id.data[4] & 0x80)) {
> + /* BENAND */
> +
> + /*
> +  * We can't disable the internal ECC engine, the user
> +  * has to use on-

Re: [PATCH 1/2] uio: dt-bindings: document binding for uio-pdrv-genirq

[Greg KH]

On Thu, Sep 21, 2017 at 12:53:25PM +1200, Chris Packham wrote:
> Signed-off-by: Chris Packham 

I can't take patches without any changelog text, sorry.

thanks,

greg k-h

Re: I/O hangs after resuming from suspend-to-ram

[Martin Steigerwald]

Ming Lei - 21.09.17, 06:20:
> On Mon, Aug 28, 2017 at 03:10:35PM +0200, Martin Steigerwald wrote:
> > Ming Lei - 28.08.17, 20:58:
> > > On Sun, Aug 27, 2017 at 09:43:52AM +0200, Oleksandr Natalenko wrote:
> > > > Hi.
> > > > 
> > > > Here is disk setup for QEMU VM:
> > > > 
> > > > ===
> > > > [root@archmq ~]# smartctl -i /dev/sda
> > > > …
> > > > Device Model: QEMU HARDDISK
> > > > Serial Number:QM1
> > > > Firmware Version: 2.5+
> > > > User Capacity:4,294,967,296 bytes [4.29 GB]
> > > > Sector Size:  512 bytes logical/physical
> > > > Device is:Not in smartctl database [for details use: -P
> > > > showall]
> > > > ATA Version is:   ATA/ATAPI-7, ATA/ATAPI-5 published, ANSI NCITS
> > > > 340-2000
> > > > Local Time is:Sun Aug 27 09:31:54 2017 CEST
> > > > SMART support is: Available - device has SMART capability.
> > > > SMART support is: Enabled
> > > > 
> > > > [root@archmq ~]# lsblk
> > > > NAMEMAJ:MIN RM  SIZE RO TYPE   MOUNTPOINT
> > > > sda   8:004G  0 disk
> > > > `-sda18:104G  0 part
> > > > 
> > > >   `-md0   9:004G  0 raid10
> > > >   
> > > > `-system253:004G  0 crypt
> > > > 
> > > >   |-system-boot 253:10  512M  0 lvm/boot
> > > >   |-system-swap 253:20  512M  0 lvm[SWAP]
> > > >   
> > > >   `-system-root 253:303G  0 lvm/
> > > > 
> > > > sdb   8:16   04G  0 disk
> > > > `-sdb18:17   04G  0 part
> > > > 
> > > >   `-md0   9:004G  0 raid10
> > > >   
> > > > `-system253:004G  0 crypt
> > > > 
> > > >   |-system-boot 253:10  512M  0 lvm/boot
> > > >   |-system-swap 253:20  512M  0 lvm[SWAP]
> > > >   
> > > >   `-system-root 253:303G  0 lvm/
> > > > 
> > > > sr0  11:01 1024M  0 rom
> > > > 
> > > > [root@archmq ~]# mdadm --misc --detail /dev/md0
> > > > 
> > > > /dev/md0:
> > > > Version : 1.2
> > > >   
> > > >   Creation Time : Sat Jul 29 16:37:05 2017
> > > >   
> > > >  Raid Level : raid10
> > > >  Array Size : 4191232 (4.00 GiB 4.29 GB)
> > > >   
> > > >   Used Dev Size : 4191232 (4.00 GiB 4.29 GB)
> > > >   
> > > >Raid Devices : 2
> > > >   
> > > >   Total Devices : 2
> > > >   
> > > > Persistence : Superblock is persistent
> > > > 
> > > > Update Time : Sun Aug 27 09:30:33 2017
> > > > 
> > > >   State : clean
> > > >  
> > > >  Active Devices : 2
> > > > 
> > > > Working Devices : 2
> > > > 
> > > >  Failed Devices : 0
> > > >  
> > > >   Spare Devices : 0
> > > >   
> > > >  Layout : far=2
> > > >  
> > > >  Chunk Size : 512K
> > > >  
> > > >Name : archiso:0
> > > >UUID : 43f4be59:c8d2fa0a:a94acdff:1c7f2f4e
> > > >  
> > > >  Events : 485
> > > > 
> > > > Number   Major   Minor   RaidDevice State
> > > > 
> > > >0   810  active sync   /dev/sda1
> > > >1   8   171  active sync   /dev/sdb1
> > > > 
> > > > ===
> > > > 
> > > > In words: 2 virtual disks, RAID10 setup with far-2 layout, LUKS on it,
> > > > then
> > > > LVM, then ext4 for boot, swap and btrfs for /.
> > > > 
> > > > I couldn't reproduce the issue with single disk without RAID.
> > > 
> > > Could you verify if the following patch fixes your issue?
> 
> Yes, the patch should address this kind of issue, not related
> with RAID specially, and the latest version can be found in the
> following link:
> 
>   https://marc.info/?l=linux-block&m=150579298505484&w=2

Thank you.

So if I understand already I can just add

https://github.com/ming1/linux/tree/my_v4.13-safe-scsi-quiesce_V5_for_test

as an remote and go from there.

Thanks,
-- 
Martin

Re: usb/core: slab-out-of-bounds read in cdc_parse_cdc_header

[Greg Kroah-Hartman]

On Wed, Sep 20, 2017 at 04:45:08PM +0200, Andrey Konovalov wrote:
> Hi!
> 
> I've got the following crash while fuzzing the kernel with syzkaller.
> 
> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
> 
> It looks like cdc_parse_cdc_header() doesn't validate buflen before
> accessing buffer[1], buffer[2] and so on. The only check present is
> while (buflen > 0).

Ugh, you are right, let me go work on a patch, thanks for the report...

Re: I/O hangs after resuming from suspend-to-ram

[Martin Steigerwald]

Martin Steigerwald - 21.09.17, 09:30:
> Ming Lei - 21.09.17, 06:20:
> > On Mon, Aug 28, 2017 at 03:10:35PM +0200, Martin Steigerwald wrote:
> > > Ming Lei - 28.08.17, 20:58:
> > > > On Sun, Aug 27, 2017 at 09:43:52AM +0200, Oleksandr Natalenko wrote:
> > > > > Hi.
> > > > > 
> > > > > Here is disk setup for QEMU VM:
> > > > > 
> > > > > ===
> > > > > [root@archmq ~]# smartctl -i /dev/sda
> > > > > …
> > > > > Device Model: QEMU HARDDISK
> > > > > Serial Number:QM1
> > > > > Firmware Version: 2.5+
> > > > > User Capacity:4,294,967,296 bytes [4.29 GB]
> > > > > Sector Size:  512 bytes logical/physical
> > > > > Device is:Not in smartctl database [for details use: -P
> > > > > showall]
> > > > > ATA Version is:   ATA/ATAPI-7, ATA/ATAPI-5 published, ANSI NCITS
> > > > > 340-2000
> > > > > Local Time is:Sun Aug 27 09:31:54 2017 CEST
> > > > > SMART support is: Available - device has SMART capability.
> > > > > SMART support is: Enabled
> > > > > 
> > > > > [root@archmq ~]# lsblk
> > > > > NAMEMAJ:MIN RM  SIZE RO TYPE   MOUNTPOINT
> > > > > sda   8:004G  0 disk
> > > > > `-sda18:104G  0 part
> > > > > 
> > > > >   `-md0   9:004G  0 raid10
> > > > >   
> > > > > `-system253:004G  0 crypt
> > > > > 
> > > > >   |-system-boot 253:10  512M  0 lvm/boot
> > > > >   |-system-swap 253:20  512M  0 lvm[SWAP]
> > > > >   
> > > > >   `-system-root 253:303G  0 lvm/
> > > > > 
> > > > > sdb   8:16   04G  0 disk
> > > > > `-sdb18:17   04G  0 part
> > > > > 
> > > > >   `-md0   9:004G  0 raid10
> > > > >   
> > > > > `-system253:004G  0 crypt
> > > > > 
> > > > >   |-system-boot 253:10  512M  0 lvm/boot
> > > > >   |-system-swap 253:20  512M  0 lvm[SWAP]
> > > > >   
> > > > >   `-system-root 253:303G  0 lvm/
> > > > > 
> > > > > sr0  11:01 1024M  0 rom
> > > > > 
> > > > > [root@archmq ~]# mdadm --misc --detail /dev/md0
> > > > > 
> > > > > /dev/md0:
> > > > > Version : 1.2
> > > > >   
> > > > >   Creation Time : Sat Jul 29 16:37:05 2017
> > > > >   
> > > > >  Raid Level : raid10
> > > > >  Array Size : 4191232 (4.00 GiB 4.29 GB)
> > > > >   
> > > > >   Used Dev Size : 4191232 (4.00 GiB 4.29 GB)
> > > > >   
> > > > >Raid Devices : 2
> > > > >   
> > > > >   Total Devices : 2
> > > > >   
> > > > > Persistence : Superblock is persistent
> > > > > 
> > > > > Update Time : Sun Aug 27 09:30:33 2017
> > > > > 
> > > > >   State : clean
> > > > >  
> > > > >  Active Devices : 2
> > > > > 
> > > > > Working Devices : 2
> > > > > 
> > > > >  Failed Devices : 0
> > > > >  
> > > > >   Spare Devices : 0
> > > > >   
> > > > >  Layout : far=2
> > > > >  
> > > > >  Chunk Size : 512K
> > > > >  
> > > > >Name : archiso:0
> > > > >UUID : 43f4be59:c8d2fa0a:a94acdff:1c7f2f4e
> > > > >  
> > > > >  Events : 485
> > > > > 
> > > > > Number   Major   Minor   RaidDevice State
> > > > > 
> > > > >0   810  active sync   /dev/sda1
> > > > >1   8   171  active sync   /dev/sdb1
> > > > > 
> > > > > ===
> > > > > 
> > > > > In words: 2 virtual disks, RAID10 setup with far-2 layout, LUKS on
> > > > > it,
> > > > > then
> > > > > LVM, then ext4 for boot, swap and btrfs for /.
> > > > > 
> > > > > I couldn't reproduce the issue with single disk without RAID.
> > > > 
> > > > Could you verify if the following patch fixes your issue?
> > 
> > Yes, the patch should address this kind of issue, not related
> > with RAID specially, and the latest version can be found in the
> > 
> > following link:
> > https://marc.info/?l=linux-block&m=150579298505484&w=2
> 
> Thank you.
> 
> So if I understand already I can just add
> 
> https://github.com/ming1/linux/tree/my_v4.13-safe-scsi-quiesce_V5_for_test
> 
> as an remote and go from there.

https://github.com/ming1/linux/tree/my_v4.13-safe-scsi-quiesce_V5_for_test

and checkout my_v4.13-safe-scsi-quiesce_V5_for_test branch of course.

-- 
Martin

Re: [PATCH v2 18/31] scsi/aic7xxx: Clean up timer usage

[Hannes Reinecke]

On 09/21/2017 01:27 AM, Kees Cook wrote:
> stat_timer only ever assigns the same function and data, so consolidate to
> a setup_timer() call and drop everything else used to pass things around.
> 
> reset_timer is unused; remove it.
> 
> Cc: Hannes Reinecke 
> Cc: "James E.J. Bottomley" 
> Cc: "Martin K. Petersen" 
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Kees Cook 
> ---
>  drivers/scsi/aic7xxx/aic79xx.h  |  5 +
>  drivers/scsi/aic7xxx/aic79xx_core.c | 29 -
>  2 files changed, 9 insertions(+), 25 deletions(-)
> Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.com  +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v3 03/10] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc

[Dave Young]

Hi AKASHI,
On 09/15/17 at 07:59pm, AKASHI Takahiro wrote:
> arch_kexec_kernel_*() and arch_kimage_file_post_load_cleanup can now be
> duplicated among some architectures, so let's factor them out.
> 
> Signed-off-by: AKASHI Takahiro 
> Cc: Dave Young 
> Cc: Vivek Goyal 
> Cc: Baoquan He 
> Cc: Michael Ellerman 
> Cc: Thiago Jung Bauermann 
> ---
>  arch/powerpc/include/asm/kexec.h|  4 ++
>  arch/powerpc/kernel/machine_kexec_file_64.c | 36 ++
>  arch/x86/kernel/machine_kexec_64.c  | 59 
> +
>  include/linux/kexec.h   | 26 ++---
>  kernel/kexec_file.c | 52 +++--
>  5 files changed, 70 insertions(+), 107 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/kexec.h 
> b/arch/powerpc/include/asm/kexec.h
> index 25668bc8cb2a..50810d24e38f 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -94,6 +94,10 @@ static inline bool kdump_in_progress(void)
>  #ifdef CONFIG_KEXEC_FILE
>  extern struct kexec_file_ops kexec_elf64_ops;
>  
> +#define arch_kexec_kernel_image_probe arch_kexec_kernel_image_probe
> +int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> +   unsigned long buf_len);
> +
>  #ifdef CONFIG_IMA_KEXEC
>  #define ARCH_HAS_KIMAGE_ARCH
>  
> diff --git a/arch/powerpc/kernel/machine_kexec_file_64.c 
> b/arch/powerpc/kernel/machine_kexec_file_64.c
> index 992c0d258e5d..5b7c4a3fbb50 100644
> --- a/arch/powerpc/kernel/machine_kexec_file_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_file_64.c
> @@ -31,8 +31,9 @@
>  
>  #define SLAVE_CODE_SIZE  256
>  
> -static struct kexec_file_ops *kexec_file_loaders[] = {
> +struct kexec_file_ops *kexec_file_loaders[] = {
>   &kexec_elf64_ops,
> + NULL
>  };
>  
>  int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> @@ -45,38 +46,7 @@ int arch_kexec_kernel_image_probe(struct kimage *image, 
> void *buf,
>   if (image->type == KEXEC_TYPE_CRASH)
>   return -ENOTSUPP;
>  
> - for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
> - fops = kexec_file_loaders[i];
> - if (!fops || !fops->probe)
> - continue;
> -
> - ret = fops->probe(buf, buf_len);
> - if (!ret) {
> - image->fops = fops;
> - return ret;
> - }
> - }
> -
> - return ret;
> -}
> -
> -void *arch_kexec_kernel_image_load(struct kimage *image)
> -{
> - if (!image->fops || !image->fops->load)
> - return ERR_PTR(-ENOEXEC);
> -
> - return image->fops->load(image, image->kernel_buf,
> -  image->kernel_buf_len, image->initrd_buf,
> -  image->initrd_buf_len, image->cmdline_buf,
> -  image->cmdline_buf_len);
> -}
> -
> -int arch_kimage_file_post_load_cleanup(struct kimage *image)
> -{
> - if (!image->fops || !image->fops->cleanup)
> - return 0;
> -
> - return image->fops->cleanup(image->image_loader_data);
> + return kexec_kernel_image_probe(image, buf, buf_len);
>  }
>  
>  /**
> diff --git a/arch/x86/kernel/machine_kexec_64.c 
> b/arch/x86/kernel/machine_kexec_64.c
> index cb0a30473c23..f4df8315d001 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -30,8 +30,9 @@
>  #include 
>  
>  #ifdef CONFIG_KEXEC_FILE
> -static struct kexec_file_ops *kexec_file_loaders[] = {
> +struct kexec_file_ops *kexec_file_loaders[] = {
>   &kexec_bzImage64_ops,
> + NULL
>  };
>  #endif
>  
> @@ -361,62 +362,6 @@ void arch_crash_save_vmcoreinfo(void)
>  /* arch-dependent functionality related to kexec file-based syscall */
>  
>  #ifdef CONFIG_KEXEC_FILE
> -int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> -   unsigned long buf_len)
> -{
> - int i, ret = -ENOEXEC;
> - struct kexec_file_ops *fops;
> -
> - for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
> - fops = kexec_file_loaders[i];
> - if (!fops || !fops->probe)
> - continue;
> -
> - ret = fops->probe(buf, buf_len);
> - if (!ret) {
> - image->fops = fops;
> - return ret;
> - }
> - }
> -
> - return ret;
> -}
> -
> -void *arch_kexec_kernel_image_load(struct kimage *image)
> -{
> - vfree(image->arch.elf_headers);
> - image->arch.elf_headers = NULL;
> -
> - if (!image->fops || !image->fops->load)
> - return ERR_PTR(-ENOEXEC);
> -
> - return image->fops->load(image, image->kernel_buf,
> -  image->kernel_buf_len, image->initrd_buf,
> -  image->initrd_buf_len, image->cmdline_buf,
> -  image->cmdline_buf

[PATCH] i2c: piix4: Disable completely the IMC during SMBUS_BLOCK_DATA

[Ricardo Ribalda Delgado]

SMBUS_BLOCK_DATA transactions might fail due to a race condition with
the IMC, even when the IMC semaphore is used.

This bug has been reported and confirmed by AMD, who suggested as a
solution an IMC firmware upgrade (obtained via BIOS update) and
disabling the IMC during SMBUS_BLOCK_DATA transactions.

Even without the IMC upgrade, the smbus is much more stable with this
patch.

Tested on a Bettong-alike board.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/i2c/busses/i2c-piix4.c | 89 ++
 1 file changed, 82 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 0ecdb47a23ab..3b8a5eaad956 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -85,6 +85,8 @@
 /* SB800 constants */
 #define SB800_PIIX4_SMB_IDX0xcd6
 
+#define IMC_SMB_IDX0x3e
+
 /*
  * SB800 port is selected by bits 2:1 of the smb_en register (0x2c)
  * or the smb_sel register (0x2e), depending on bit 0 of register 0x2f.
@@ -160,6 +162,8 @@ struct i2c_piix4_adapdata {
/* SB800 */
bool sb800_main;
u8 port;/* Port number, shifted */
+
+   bool notify_imc;
 };
 
 static int piix4_setup(struct pci_dev *PIIX4_dev,
@@ -572,6 +576,50 @@ static s32 piix4_access(struct i2c_adapter * adap, u16 
addr,
return 0;
 }
 
+static uint8_t piix4_imc_read(uint8_t idx)
+{
+   outb_p(idx, IMC_SMB_IDX);
+   return inb_p(IMC_SMB_IDX + 1);
+}
+
+static void piix4_imc_write(uint8_t idx, uint8_t value)
+{
+   outb_p(idx, IMC_SMB_IDX);
+   outb_p(value, IMC_SMB_IDX + 1);
+}
+
+int piix4_imc_sleep(void)
+{
+   int timeout = MAX_TIMEOUT;
+
+   piix4_imc_write(0x82, 0x00);
+   piix4_imc_write(0x83, 0xB4);
+   piix4_imc_write(0x80, 0x96);
+
+   while (timeout--) {
+   if (piix4_imc_read(0x82) == 0xfa)
+   return 0;
+   usleep_range(1000, 2000);
+   }
+
+   return -ETIMEDOUT;
+}
+
+void piix4_imc_wakeup(void)
+{
+   int timeout = MAX_TIMEOUT;
+
+   piix4_imc_write(0x82, 0x00);
+   piix4_imc_write(0x83, 0xB5);
+   piix4_imc_write(0x80, 0x96);
+
+   while (timeout--) {
+   if (piix4_imc_read(0x82) == 0xfa)
+   break;
+   usleep_range(1000, 2000);
+   }
+}
+
 /*
  * Handles access to multiple SMBus ports on the SB800.
  * The port is selected by bits 2:1 of the smb_en register (0x2c).
@@ -586,7 +634,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
 {
struct i2c_piix4_adapdata *adapdata = i2c_get_adapdata(adap);
unsigned short piix4_smba = adapdata->smba;
-   int retries = MAX_TIMEOUT;
+   int retries = adapdata->notify_imc ? MAX_TIMEOUT * 2 : MAX_TIMEOUT;
int smbslvcnt;
u8 smba_en_lo;
u8 port;
@@ -612,6 +660,15 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, 
u16 addr,
return -EBUSY;
}
 
+   /* Block data transfers require disabling the imc */
+   if ((size == I2C_SMBUS_BLOCK_DATA) && adapdata->notify_imc)
+   /* If IMC communication fails do not retry*/
+   if (piix4_imc_sleep()) {
+   dev_warn(&adap->dev,
+"Failed to communicate with the IMC, enable it 
and/or upgrade your BIOS.\n");
+   adapdata->notify_imc = false;
+   }
+
outb_p(piix4_port_sel_sb800, SB800_PIIX4_SMB_IDX);
smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
 
@@ -628,6 +685,9 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
/* Release the semaphore */
outb_p(smbslvcnt | 0x20, SMBSLVCNT);
 
+   if ((size == I2C_SMBUS_BLOCK_DATA) && adapdata->notify_imc)
+   piix4_imc_wakeup();
+
mutex_unlock(&piix4_mutex_sb800);
 
return retval;
@@ -679,7 +739,7 @@ static struct i2c_adapter 
*piix4_main_adapters[PIIX4_MAX_ADAPTERS];
 static struct i2c_adapter *piix4_aux_adapter;
 
 static int piix4_add_adapter(struct pci_dev *dev, unsigned short smba,
-bool sb800_main, u8 port,
+bool sb800_main, u8 port, bool notify_imc,
 const char *name, struct i2c_adapter **padap)
 {
struct i2c_adapter *adap;
@@ -707,6 +767,7 @@ static int piix4_add_adapter(struct pci_dev *dev, unsigned 
short smba,
adapdata->smba = smba;
adapdata->sb800_main = sb800_main;
adapdata->port = port << 1;
+   adapdata->notify_imc = notify_imc;
 
/* set up the sysfs linkage to our parent device */
adap->dev.parent = &dev->dev;
@@ -728,14 +789,15 @@ static int piix4_add_adapter(struct pci_dev *dev, 
unsigned short smba,
return 0;
 }
 
-static int piix4_add_adapters_sb800(struct pci_dev *dev, unsigned short smba)
+static int piix4_add_adapters_sb800(struct pc

Re: [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

[Sergey Senozhatsky]

On (09/20/17 11:24), Joe Perches wrote:
> On Wed, 2017-09-20 at 19:53 +0200, Helge Deller wrote:
[..]
> > Is it worth to mention, that it's still needed in older kernels?
> > Just in case some patch get's backported.

good question.

> I think probably not.
> 
> There are relatively few references and
> modifications are unlikely to be backported.

I tend to agree.

unlikely anyone backports printk message updates. I have quickly glanced
through stable-4.9 and haven't seen such backports. well, may be there
are some.

can tweak the warning a bit, probably. e.g. "if you are planning to
backport your change to kernels older than 4.14 then ignore this
warning". but not sure if it's worth it.

-ss

Re: [PATCH] android: binder: fix type mismatch warning

[Greg Kroah-Hartman]

On Wed, Sep 20, 2017 at 01:37:45PM +, Arnd Bergmann wrote:
> On Wed, Sep 20, 2017 at 12:24 PM, Martijn Coenen  wrote:
> > On Wed, Sep 20, 2017 at 11:58 AM, Arnd Bergmann  wrote:
> >>
> >> - Since you say there are existing users of recent 32-bit Android
> >>   including Oreo, I also think that removing support for the v7 ABI
> >>   is no longer an option. I only made that suggestion under the
> >>   assumption that there is no user space requiring that. Linux
> >>   has no real way of "deprecating" an existing ABI, either it is
> >>   currently used and has to stay around, or it is not used at all
> >>   and can be removed without anybody noticing.
> >
> > I don't know of any Android devices shipping with 4.14 - we don't even
> > have a common tree for 4.14 (4.9 is the latest). So I don't think
> > we're hurting anyone in the Android ecosystem if we remove v7 from
> > 4.14. From what I know, it's extremely rare for an Android device to
> > change their kernel version after a device ships, but even if someone
> > hypothetically did update their Android device to use 4.14, they can
> > pretty easily switch the build-time config option. I understand that
> > this is against Linux' philosophy around not breaking userspace, I
> > just want to point out that I think from an Android POV, removing v7
> > from 4.14 is not an issue. I'm not sure if that is good enough.
> 
> I'm not really worried about shipping Android products, for those
> there is no big problem using the compile-time option as they build
> everything together.
> 
> The case that gets interesting is a any kind of user that wants to
> run an Android application on a regular Linux box without
> using virtual machines or emulation, e.g. a an app developer,
> or a user that wants to run some Android app on their desktop
> using anbox.
> 
> This obviously requires enabling the module, but it should not
> require enabling an option to support one version of the user
> space while breaking another version.

To be fair, lots of people, including myself, have always said, "never
run binder on a system that is not a 'real' Android system" for a
variety of good reasons, including security issues.

Now around the 4.10 or so kernel release, most of those issues were
resolved, and with 4.14, all of those have been taken care of (that I
know of), so this should be allowed.  But given that no one has done it
in the past (or should have), I don't know how hard you want to support
"older" situations at all.

> >> If we end up doing a runtime switch between the ABIs instead,
> >> I see two ways of doing that:
> >>
> >> The easiest implementation would make it a module parameter:
> >> Since there is only one instance of the binder in any given
> >> system, and presumably all processes talking to it have to use
> >> the same ABI, this should be sufficient. The main downside is
> >> that it prevents us from having incompatible versions per
> >> namespace if we ever get a containerized version of binder.
> >
> > Namespace support for binder is currently being investigated, but I'm
> > not sure we'd ever have a system where we want to mix v7 and v8. There
> > really is no good reason to use v7 anymore (even on 32-bit mahcines),
> > we just should have removed it from our userspace a lot earlier.
> 
> The only possible reason for v7 is backwards compatibility. I agree
> we don't need a single machine (or container) to support a mix of
> v7 and v8 applications, but I can see someone using a v7 based
> chroot user space today to keep running that in a container in the
> future while using another container for an updated image.
> 
> This is clearly a corner case that we could decide to ignore, it
> just feels like a bit of a hack.

I think it's a corner case that no one will actually run into at all.

Remember, it's only libbinder that is touching the binder device node,
not random applications, so it's not a matter of an application in a
container, but rather, a whole "system" there.  And running whole
"systems" in different containers is not really viable from what I can
tell (but I could be wrong.)

> >> The correct way to do it would be to unify the two versions of
> >> the ABI so they can be used interchangeably: any 32-bit
> >> process would start out with the v7 interface and a 64-bit
> >> process would start out with the v8 interface
> >
> > This wouldn't work with the current implementation - if a 32-bit and
> > 64-bit process communicate, then userspace would make wrong
> > assumptions about the sizes of transactions. Or is this what you're
> > proposing to fix?
> 
> The scenario I had in mind is like this:
> 
> - Any 64-bit process would use the v8 ABI all the time. When the binder
>   device has been opened by a 64-bit process already, this forces
>   all other processes opening it to also use v8.
> 
> - An existing 32-bit process would keep using the v7 ABI, but as long
>   as the the v7 interface is in use, no other process may use the v8 ABI.
>   This wou

Re: [PATCH] tee: ACPI support for optee driver

[Hanjun Guo]

On 2017/9/21 15:12, Mayuresh Chitale wrote:
> This patch modifies the optee driver to add support for parsing
> the conduit method from an ACPI node.

Sorry I didn't involve this earlier, but I think this is a wrong
approach, in ACPI 5.1+ spec, there is a bit in FADT table which
indicates PSCI using SMC or HVC, please see ACPI 6.2 [1],
Table 5-37 Fixed ACPI Description Table ARM Boot Architecture Flags.

Can we just use that to get the conduit method for optee driver too?

[1]: http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf

Thanks
Hanjun

Re: [PATCH 2/2] uio: add default compatible string to uio_pdrv_genirq

[Andy Shevchenko]

On Thu, Sep 21, 2017 at 3:53 AM, Chris Packham
 wrote:


> -module_param_string(of_id, uio_of_genirq_match[0].compatible, 128, 0);
> +module_param_string(of_id, uio_of_genirq_match[1].compatible, 128, );

0 ->  looks like bogus checkpatch warning.

-- 
With Best Regards,
Andy Shevchenko

Re: Possible gcc 4.8.5 bug about RELOC_HIDE marcro

[Mikael Pettersson]

Jia He writes:
 > I tried to build kernel 4.14-rc1 on a arm64 server in distro centos 7.3. 
 > The gcc version is 4.8.5

I have no input on the specifics of the issue, but please note that gcc-4.8
is no longer supported or maintained by upstream.  Even gcc-4.9 is EOL, and
gcc-5 will be EOL:d inn a week or so.  Also I'll note that gcc-4.8 is still
fairly early wrt to arm64 support, so bugs may be expected.

In short, please retry with gcc-6.4 or gcc-7.2.

[PATCH 0/3] EDAC: Handle return value of kasprintf

[Arvind Yadav]

kasprintf() can fail here and we must check its return value.

Arvind Yadav (3):
  [PATCH 1/3] EDAC: i7core: Handle return value of kasprintf
  [PATCH 2/3] EDAC: sb_edac: Handle return value of kasprintf
  [PATCH 3/3] EDAC: skx_edac: Handle return value of kasprintf

 drivers/edac/i7core_edac.c | 6 ++
 drivers/edac/sb_edac.c | 4 
 drivers/edac/skx_edac.c| 6 ++
 3 files changed, 16 insertions(+)

-- 
1.9.1

[PATCH 3/3] EDAC: skx_edac: Handle return value of kasprintf

[Arvind Yadav]

kasprintf() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/edac/skx_edac.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/edac/skx_edac.c b/drivers/edac/skx_edac.c
index 16dea97..a7b25bb 100644
--- a/drivers/edac/skx_edac.c
+++ b/drivers/edac/skx_edac.c
@@ -466,6 +466,11 @@ static int skx_register_mci(struct skx_imc *imc)
 
mci->ctl_name = kasprintf(GFP_KERNEL, "Skylake Socket#%d IMC#%d",
  imc->node_id, imc->lmc);
+   if (!mci->ctl_name) {
+   rc = -ENOMEM;
+   goto fail0;
+   }
+
mci->mtype_cap = MEM_FLAG_DDR4;
mci->edac_ctl_cap = EDAC_FLAG_NONE;
mci->edac_cap = EDAC_FLAG_NONE;
@@ -491,6 +496,7 @@ static int skx_register_mci(struct skx_imc *imc)
 
 fail:
kfree(mci->ctl_name);
+fail0:
edac_mc_free(mci);
imc->mci = NULL;
return rc;
-- 
1.9.1

[PATCH 2/3] EDAC: sb_edac: Handle return value of kasprintf

[Arvind Yadav]

kasprintf() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/edac/sb_edac.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index dc05916..2b9e831 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -3286,6 +3286,10 @@ static int sbridge_register_mci(struct sbridge_dev 
*sbridge_dev, enum type type)
pvt->sbridge_dev->source_id, pvt->sbridge_dev->dom);
break;
}
+   if (!mci->ctl_name) {
+   rc = -ENOMEM;
+   goto fail0;
+   }
 
/* Get dimm basic config and the memory layout */
rc = get_dimm_config(mci);
-- 
1.9.1

[PATCH 1/3] EDAC: i7core: Handle return value of kasprintf

[Arvind Yadav]

kasprintf() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/edac/i7core_edac.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index c16c3b9..054f361 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -2161,6 +2161,11 @@ static int i7core_register_mci(struct i7core_dev 
*i7core_dev)
mci->mod_name = "i7core_edac.c";
mci->ctl_name = kasprintf(GFP_KERNEL, "i7 core #%d",
  i7core_dev->socket);
+   if (!mci->ctl_name) {
+   rc = -ENOMEM;
+   goto fail1;
+   }
+
mci->dev_name = pci_name(i7core_dev->pdev[0]);
mci->ctl_page_to_phys = NULL;
 
@@ -2214,6 +2219,7 @@ static int i7core_register_mci(struct i7core_dev 
*i7core_dev)
 
 fail0:
kfree(mci->ctl_name);
+fail1:
edac_mc_free(mci);
i7core_dev->mci = NULL;
return rc;
-- 
1.9.1

Re: [PATCH] tee: ACPI support for optee driver

[Mayuresh Chitale]

On Thu, Sep 21, 2017 at 1:15 PM, Hanjun Guo  wrote:
> On 2017/9/21 15:12, Mayuresh Chitale wrote:
>> This patch modifies the optee driver to add support for parsing
>> the conduit method from an ACPI node.
>
> Sorry I didn't involve this earlier, but I think this is a wrong
> approach, in ACPI 5.1+ spec, there is a bit in FADT table which
> indicates PSCI using SMC or HVC, please see ACPI 6.2 [1],
> Table 5-37 Fixed ACPI Description Table ARM Boot Architecture Flags.
>
> Can we just use that to get the conduit method for optee driver too?
Thanks for the comment. I will check it out.
>
> [1]: http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
>
> Thanks
> Hanjun
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

[gengdongjiu]

Hi James

On 2017/9/14 21:00, James Morse wrote:
> Hi gengdongjiu,

> user-space can choose whether to use SEA or SEI, it doesn't have to choose the
> same notification type that firmware used, which in turn doesn't have to be 
> the
> same as that used by the CPU to notify firmware.
> 
> The choice only matters because these notifications hang on an existing pieces
> of the Arm-architecture, so the notification can only add to the 
> architecturally
> defined meaning. (i.e. You can only send an SEA for something that can already
> be described as a synchronous external abort).
> 
> Once we get to user-space, for memory_failure() notifications, (which so far 
> is
> all we are talking about here), the only thing that could matter is whether 
> the
> guest hit a PG_hwpoison page as a stage2 fault. These can be described as
> Synchronous-External-Abort.
> 
> The Synchronous-External-Abort/SError-Interrupt distinction matters for the 
> CPU
> because it can't always make an error synchronous. For memory_failure()
> notifications to a KVM guest we really can do this, and we already have this
> behaviour for free. An example:
> 
> A guest touches some hardware:poisoned memory, for whatever reason the CPU 
> can't
> put the world back together to make this a synchronous exception, so it 
> reports
> it to firmware as an SError-interrupt.
> Linux gets an APEI notification and memory_failure() causes the affected page 
> to
> be unmapped from the guest's stage2, and SIGBUS_MCEERR_AO sent to user-space.
> 
> Qemu/kvmtool can now notify the guest with an IRQ or POLLed notification. AO->
> action optional, probably asynchronous.
> 
> But in our example it wasn't really asynchronous, that was just a property of
> the original CPU->firmware notification. What happens? The guest vcpu is 
> re-run,
> it re-runs the same instructions (this was a contained error so KVM's ELR 
> points
> at/before the instruction that steps in the problem). This time KVM takes a
> stage2 fault, which the mm code will refuse to fixup because the relevant page
> was marked as PG_hwpoision by memory_failure(). KVM signals Qemu/kvmtool with
> SIGBUS_MCEERR_AR. Now Qemu/kvmtool can notify the guest using SEA.

CC Achin

I have some personal opinion, if you think it is not right, hope you can point 
out.

Synchronous External Abort and SError Interrupt are hardware exception(hardware 
concept), which is independent of software notification,
in armv8 without RAS, the two concepts already exist. In the APEI spec, in 
order to better describe the two exceptions, so use SEA and SEI notification to 
stand for them.

SEA notification stands for Synchronous External Abort, so may be it is not 
only a notification, it also stands for a hardware error type.
SEI notification stands for SError Interrupt, so may be it is not only a 
notification, it also stands for a hardware error type.

In the OS, it has different handling flow to the two exception(two 
notification):
when the guest OS running, if the hardware generates a Synchronous External 
Abort, we told the guest OS this error is SError Interrupt instead of 
Synchronous External Abort.
guest OS uses SEI notification handling flow to deal with it, I am not sure 
whether it will have problem, because the true hardware exception is 
Synchronous External Abort,
but software treats it as SError interrupt to handle.

In the mainline code, it does not have SEI notification support, the reason I 
think it is because of the error address record by firmware is not 
accurate(SError Interrupt is asynchronous exception).
so if treat a hardware Synchronous External Abort as SError interrupt(SEI). The 
default OS behavior for SEI is PANIC, that is to say, when hardware triggers a 
Synchronous External Abort(SEA), if guest
treat it as SError interrupt(SEI), the OS will be panic. in fact, it can be 
recoverable instead of Panic.

I ever added a patch to support the SEI notification, but not sure whether it 
is can be accepted by open source, until now, not receive response.

Re: [PATCH 4/4] ALSA: emu10k1: Cocci spatch "alloc_cast"

[Takashi Iwai]

On Thu, 21 Sep 2017 08:33:46 +0200,
Thomas Meyer wrote:
> 
> Remove casting the values returned by memory allocation functions like
> kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc."
> Found by coccinelle spatch "api/alloc/alloc_cast.cocci"
> 
> Signed-off-by: Thomas Meyer 

No, this cast is still required because it has __user annotation.
It's not about compiler warning but about sparse.


thanks,

Takashi

Re: [PATCH v4 0/4] Add STM32 DMAMUX support

[Pierre Yves MORDRET]

Hello

Gentle ping for driver review since DT Bindings have been acked by Rob Herring.

Thanks
Py

On 09/07/2017 01:52 PM, Pierre-Yves MORDRET wrote:
> This patchset adds support for the STM32 DMA multiplexer.
> It allows to map any peripheral DMA request to any channel of the product
> DMAs.
> This IP has been introduced with STM32H7 SoC.
> 
> ---
>  Version history:
> v4:
> * Add multi-master ability for STM32 DMAMUX
> * Get rid of st,dmamux property and custom API between STM32
>   DMAMUX and DMA. Bindings has changed.
>   DMAMUX will read DMA masters from Device Tree from now on.
>   Merely one DMAMUX node is needed now.
> * Only STM32 DMA are allowed to be connected onto DMAMUX
> * channelID is computed locally within the driver and crafted in
>   dma_psec to be passed toward DMA master.
>   DMAMUX router sorts out which DMA master will serve the
>   request automatically.
> * This version forbids the use of DMA in standalone and DMAMUX at
>   the same time : all clients need to be connected either on DMA
>   or DMAMUX ; no mix up
> v3:
> * change compatible to st,stm32h7-dmamux to be mode Soc specific
> * add verbosity in dma-cells
> ---
> 
> Pierre-Yves MORDRET (4):
>   dt-bindings: Document the STM32 DMAMUX bindings
>   dmaengine: Add STM32 DMAMUX driver
>   dt-bindings: stm32-dma: add a property to handle STM32 DMAMUX
>   ARM: configs: stm32: Add MDMA support in STM32 defconfig
> 
>  .../devicetree/bindings/dma/stm32-dma.txt  |   4 +-
>  .../devicetree/bindings/dma/stm32-dmamux.txt   |  84 ++
>  arch/arm/configs/stm32_defconfig   |   1 +
>  drivers/dma/Kconfig|   9 +
>  drivers/dma/Makefile   |   1 +
>  drivers/dma/stm32-dmamux.c | 321 
> +
>  6 files changed, 419 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>  create mode 100644 drivers/dma/stm32-dmamux.c
> 

[PATCH] xen: support 52 bit physical addresses in pv guests

[Juergen Gross]

Physical addresses on processors supporting 5 level paging can be up to
52 bits wide. For a Xen pv guest running on such a machine those
physical addresses have to be supported in order to be able to use any
memory on the machine even if the guest itself does not support 5 level
paging.

So when reading/writing a MFN from/to a pte don't use the kernel's
PTE_PFN_MASK but a new XEN_PTE_MFN_MASK allowing full 40 bit wide MFNs.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/xen/page.h | 11 ++-
 arch/x86/xen/mmu_pv.c   |  4 ++--
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 07b6531813c4..bcb8b193c8d1 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -26,6 +26,15 @@ typedef struct xpaddr {
phys_addr_t paddr;
 } xpaddr_t;
 
+#ifdef CONFIG_X86_64
+#define XEN_PHYSICAL_MASK  ((1UL << 52) - 1)
+#else
+#define XEN_PHYSICAL_MASK  __PHYSICAL_MASK
+#endif
+
+#define XEN_PTE_MFN_MASK   ((pteval_t)(((signed long)PAGE_MASK) & \
+   XEN_PHYSICAL_MASK))
+
 #define XMADDR(x)  ((xmaddr_t) { .maddr = (x) })
 #define XPADDR(x)  ((xpaddr_t) { .paddr = (x) })
 
@@ -277,7 +286,7 @@ static inline unsigned long bfn_to_local_pfn(unsigned long 
mfn)
 
 static inline unsigned long pte_mfn(pte_t pte)
 {
-   return (pte.pte & PTE_PFN_MASK) >> PAGE_SHIFT;
+   return (pte.pte & XEN_PTE_MFN_MASK) >> PAGE_SHIFT;
 }
 
 static inline pte_t mfn_pte(unsigned long page_nr, pgprot_t pgprot)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 509f560bd0c6..958d36d776d9 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -315,7 +315,7 @@ void xen_ptep_modify_prot_commit(struct mm_struct *mm, 
unsigned long addr,
 static pteval_t pte_mfn_to_pfn(pteval_t val)
 {
if (val & _PAGE_PRESENT) {
-   unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
+   unsigned long mfn = (val & XEN_PTE_MFN_MASK) >> PAGE_SHIFT;
unsigned long pfn = mfn_to_pfn(mfn);
 
pteval_t flags = val & PTE_FLAGS_MASK;
@@ -1740,7 +1740,7 @@ static unsigned long __init m2p(phys_addr_t maddr)
 {
phys_addr_t paddr;
 
-   maddr &= PTE_PFN_MASK;
+   maddr &= XEN_PTE_MFN_MASK;
paddr = mfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;
 
return paddr;
-- 
2.12.3

Re: [PATCH v4 0/4] Add STM32 MDMA driver

[Pierre Yves MORDRET]

Hello,

Gentle ping for driver review submitted on August 25th.

Thanks
Regards

On 08/25/2017 04:31 PM, Pierre-Yves MORDRET wrote:
> This patchset adds support for the STM32 MDMA controller.
> The Master Direct memory access (MDMA) provides high-speed data transfer
> between memory and memory or between peripherals and memory.
> Contrary to STM32 DMA, the STM32 MDMA controller supports hardware LLI and
> uses a larger integrated FIFO (128 vs 16 bytes)
> ---
>   Version history:
>  v4:
>  * Add safe getter/setter macros
>  * forbid DMA preparation in cyclic mode yet
>  * Optimize burst and memory width for memcpy
>  * replace of_property_xx by device_property_xx
>  v3:
>  * Update header template
>  * Unsigned expression compared with zero
>  * Rework stm32_mdma_get_max_width
>  * moved to src/dst case where they are used in set_xfer
>  * Change of_property_* with device_property_*
>  * Add dev_warn whether default value is used
>  * Indentation
>  * Add MODULE_*
>  v2:
>  * change compatible into st,stm32h7-mdma to be more SoC specific
>  * Add MDMA support in DT for H7
>  * Add MDMA support in STM32 defconfig
> ---
> Pierre-Yves MORDRET (4):
>   dt-bindings: Document the STM32 MDMA bindings
>   dmaengine: Add STM32 MDMA driver
>   ARM: dts: stm32: Add MDMA support for STM32H743 SoC
>   ARM: configs: stm32: Add MDMA support in STM32 defconfig
> 
>  .../devicetree/bindings/dma/stm32-mdma.txt |   94 ++
>  arch/arm/boot/dts/stm32h743.dtsi   |   10 +
>  arch/arm/configs/stm32_defconfig   |1 +
>  drivers/dma/Kconfig|   12 +
>  drivers/dma/Makefile   |1 +
>  drivers/dma/stm32-mdma.c   | 1618 
> 
>  6 files changed, 1736 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-mdma.txt
>  create mode 100644 drivers/dma/stm32-mdma.c
> 

Re: usb/core: slab-out-of-bounds read in cdc_parse_cdc_header

[Greg Kroah-Hartman]

On Thu, Sep 21, 2017 at 09:31:54AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Sep 20, 2017 at 04:45:08PM +0200, Andrey Konovalov wrote:
> > Hi!
> > 
> > I've got the following crash while fuzzing the kernel with syzkaller.
> > 
> > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
> > 
> > It looks like cdc_parse_cdc_header() doesn't validate buflen before
> > accessing buffer[1], buffer[2] and so on. The only check present is
> > while (buflen > 0).
> 
> Ugh, you are right, let me go work on a patch, thanks for the report...

Here's a first cut at a fix for this.  I think this should solve it, but
it's early and my coffee has not fully kicked in...

thanks,

greg k-h
-

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 4c38ea41ae96..028feaf01aa5 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -2069,6 +2069,10 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header 
*hdr,
elength = 1;
goto next_desc;
}
+   if ((buflen < elength) || (elength < 2)) {
+   dev_err(&intf->dev, "invalid descriptor buffer 
length\n");
+   break;
+   }
if (buffer[1] != USB_DT_CS_INTERFACE) {
dev_err(&intf->dev, "skipping garbage\n");
goto next_desc;

Re: [PATCH v2 00/12] x86/crypto: Fix RBP usage in several crypto .S files

[Herbert Xu]

On Mon, Sep 18, 2017 at 02:41:59PM -0500, Josh Poimboeuf wrote:
> v2:
> - fix performance issues in sha256-avx2-asm.S and sha512-avx2-asm.S
>   (Eric)
> 
> Many of the x86 crypto functions use RBP as a temporary register.  This
> breaks frame pointer convention, and breaks stack traces when unwinding
> from an interrupt in the crypto code.
> 
> Convert most* of them to leave RBP alone.
> 
> These pass the crypto boot tests for me.  Any further testing would be
> appreciated!
> 
> [*] There are still a few crypto files left that need fixing, but the
> fixes weren't trivial and nobody reported unwinder warnings about
> them yet, so I'm skipping them for now.
> 
> Josh Poimboeuf (12):

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: talitos - fix hashing

[Herbert Xu]

On Wed, Sep 13, 2017 at 12:44:57PM +0200, Christophe Leroy wrote:
> md5sum on some files gives wrong result
> 
> Exemple:
> 
> With the md5sum from libkcapi:
> c15115c05bad51113f81bdaee735dd09  test
> 
> With the original md5sum:
> bbdf41d80ba7e8b2b7be3a0772be76cb  test
> 
> This patch fixes this issue
> 
> Signed-off-by: Christophe Leroy 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: inside-secure - fix gcc-4.9 warnings

[Herbert Xu]

On Tue, Sep 12, 2017 at 12:12:16PM +0200, Arnd Bergmann wrote:
> All older compiler versions up to gcc-4.9 produce these
> harmless warnings:
> 
> drivers/crypto/inside-secure/safexcel_cipher.c:389:9: warning: missing braces 
> around initializer [-Wmissing-braces]
> drivers/crypto/inside-secure/safexcel_cipher.c:389:9: warning: (near 
> initialization for ‘result.completion’) [-Wmissing-braces]
> drivers/crypto/inside-secure/safexcel_hash.c:422:9: warning: missing braces 
> around initializer [-Wmissing-braces]
> drivers/crypto/inside-secure/safexcel_hash.c:422:9: warning: (near 
> initialization for ‘result.completion’) [-Wmissing-braces]
> 
> This changes the syntax to something that works on all versions
> without warnings.
> 
> Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto 
> engine driver")
> Signed-off-by: Arnd Bergmann 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [v4,0/3] Workaround for bus/slot reset on Cavium cn8xxx root ports

[Jan Glauber]

On Wed, Sep 20, 2017 at 12:09:12PM -0600, Alex Williamson wrote:
> On Tue, 12 Sep 2017 02:40:49 -0700
> Vadim Lomovtsev  wrote:
> 
> > Hi all,
> > 
> > Are there any updates on this ?
> > Comments/objections/acks/nacks ?
> > 
> > WBBR,
> > Vadim
> > 
> > On Fri, Sep 08, 2017 at 10:10:30AM +0200, Jan Glauber wrote:
> > > Using vfio-pci on a combination of cn8xxx and some PCI devices results in
> > > a kernel panic. This is triggered by issuing a bus or a slot reset
> > > on the PCI device.
> > > 
> > > With this series both checks indicate that the reset is not possible
> > > preventing the kernel panic.
> > > 
> > > David Daney (2):
> > >   PCI: Allow PCI_DEV_FLAGS_NO_BUS_RESET to be used on bus device
> > >   PCI: Avoid bus reset for Cavium cn8xxx root ports
> > > 
> > > Jan Glauber (1):
> > >   PCI: Avoid slot reset if bus reset is not possible
> > > 
> > >  drivers/pci/pci.c| 8 
> > >  drivers/pci/quirks.c | 8 
> > >  2 files changed, 16 insertions(+)  
> 
> 
> Looks ok to me, for series:
> 
> Reviewed-by: Alex Williamson 

Thanks for the review. And also for being patient with my iterations.

> I am curious why we're happy targeting this quirk at a single device ID
> while at the same time trying to expand the ACS quirk to a notable
> fraction of the Cavium PCI device ID address space.  Thanks,

David, please correct me if I'm wrong but I think this problem only
exists on cn88xx (device id 0xa100) but not on cn81xx/cn83xx (0xa200,
0xa300). I've seen the bridge causing the problem only on cn88xx.

--Jan

Re: [PATCH] crypto: talitos - Don't provide setkey for non hmac hashing algs.

[Herbert Xu]

On Tue, Sep 12, 2017 at 11:03:39AM +0200, Christophe Leroy wrote:
> Today, md5sum fails with error -ENOKEY because a setkey
> function is set for non hmac hashing algs, see strace output below:
> 
> mmap(NULL, 378880, PROT_READ, MAP_SHARED, 6, 0) = 0x77f5
> accept(3, 0, NULL)  = 7
> vmsplice(5, 
> [{"bin/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
> 378880}], 1, SPLICE_F_MORE|SPLICE_F_GIFT) = 262144
> splice(4, NULL, 7, NULL, 262144, SPLICE_F_MORE) = -1 ENOKEY (Required key not 
> available)
> write(2, "Generation of hash for file kcap"..., 50) = 50
> munmap(0x77f5, 378880)  = 0
> 
> This patch ensures that setkey() function is set only
> for hmac hashing.
> 
> Signed-off-by: Christophe Leroy 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: talitos - fix sha224

[Herbert Xu]

On Wed, Sep 13, 2017 at 12:44:51PM +0200, Christophe Leroy wrote:
> Kernel crypto tests report the following error at startup
> 
> [2.752626] alg: hash: Test 4 failed for sha224-talitos
> [2.757907] : 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0
> 0010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22
> 
> This patch fixes it
> 
> Signed-off-by: Christophe Leroy 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[git pull] drm fixes for v4.14-rc2

[Dave Airlie]

Hi Linus,

I've ended up on unplanned + planned leave this week, but there were
some fixes I decided to dequeue, some amdkfd bits missed the next pull
but they are pretty trivial, so I included them.

I'm not sure I'll see much else for rc2, lots of people are at XDC.

Dave.

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.14-rc2

for you to fetch changes up to 56eac98b8a0bbb72132340dbfedc912c68c4bd56:

  Merge tag 'exynos-drm-fixes-for-v4.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-fixes (2017-09-21 08:02:39 +1000)


amdkfd, i915 and exynos fixes


Arnd Bergmann (1):
  drm: exynos: include linux/irq.h

Changbin Du (1):
  drm/i915/gvt: Fix incorrect PCI BARs reporting

Chris Wilson (1):
  drm/i915: Remove unused 'in_vbl' from i915_get_crtc_scanoutpos()

Christophe JAILLET (1):
  drm/i915: Fix an error handling in 'intel_framebuffer_init()'

Dave Airlie (3):
  Merge tag 'drm-amdkfd-next-2017-09-02' of
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2017-09-20' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.14-rc1' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Himanshu Jha (1):
  drm/amdkfd: remove memset before memcpy

Lee, Shawn C (2):
  drm/i915/bxt: set min brightness from VBT
  drm/i915/cnp: set min brightness from VBT

Maciej Purski (1):
  drm/exynos/hdmi: Fix unsafe list iteration

Marek Szyprowski (2):
  drm/exynos: Fix locking in the suspend/resume paths
  drm/exynos: Fix suspend/resume support

Mikko Rapeli (1):
  uapi linux/kfd_ioctl.h: only use __u32 and __u64

Oded Gabbay (1):
  drm/amdkfd: pass queue's mqd when destroying mqd

Uma Shankar (1):
  Revert "drm/i915/bxt: Disable device ready before shutdown command"

 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |   2 +-
 .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |   1 -
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  |   1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  36 ++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |  20 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h  |  10 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  14 +-
 drivers/gpu/drm/i915/gvt/cfg_space.c   | 113 ++
 drivers/gpu/drm/i915/i915_irq.c|   3 -
 drivers/gpu/drm/i915/intel_display.c   |   2 +-
 drivers/gpu/drm/i915/intel_dsi.c   |  11 --
 drivers/gpu/drm/i915/intel_panel.c |   4 +
 include/uapi/linux/kfd_ioctl.h | 172 ++---
 14 files changed, 195 insertions(+), 195 deletions(-)

Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang

[Dmitry Vyukov]

On Wed, Sep 20, 2017 at 11:19 PM, Andy Lutomirski  wrote:
>>> On Wed, Sep 20, 2017 at 08:01:02PM +0200, Dmitry Vyukov wrote:
 On Wed, Sep 20, 2017 at 7:46 PM, H. Peter Anvin  wrote:
> On 09/20/17 10:38, Dmitry Vyukov wrote:
>
> I think we need just the frame itself and RSP pointing below this
> frame. If we don't have a frame, CALL instruction will smash whatever
> RSP happens to point to. Compiler doesn't have to setup RSP to point
> below used part of stack in leaf functions.
>

 In the kernel it does.  Redzoning is not allowed in the kernel, because
 interrupts or exceptions would also smash the redzone.
>>>
>>> I see... But it's the same for user-space signals, the first thing a
>>> signal should do is to skip the redzone. I guess interrupt handlers
>>> should switch to interrupt stack which avoids smashing redzone
>>> altogether. Do you mean nested interrupts/exceptions in interrupts?
>>> In my experience frames in leaf functions can have pretty large
>>> performance penalty. Wonder if we have we considered changing
>>> interrupt/exception handlers to avoid smashing redzones and disable
>>> leaf frames?
>>
>> Currently, on x86-64, I believe all exceptions have their own dedicated
>> stacks in the kernel, but IRQs still come in on the task's kernel stack.
>>
>> Andy, do you know if there's a reason why IRQs don't use a dedicated IST
>> stack?
>>
>
> Because IST is awful due to recursion issues.  We immediately switch to an 
> IRQ stack, though.
>
> If the kernel wanted a redzone, it would have to use IST for everything, 
> which would entail a bunch of unpleasant hackery.

Thanks.

I guess it must be finite recursion, because we could not handle
infinite with finite stack. I thing that solves it is simply:

sub $256, %rsp
... do stuff ...
add $256, %rsp

Don't know if it's applicable to interrupts or not.

Re: [media] s2255drv: Adjust 13 checks for null pointers

[SF Markus Elfring]

>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
> 
> You've been told several times that this stuff doesn't work.

This functionality might not exactly work in the way that you expect so far.


> Try applying this patch with `git am` and you'll see why.

I find that these extra message fields work in the way that was designed
by the Git software developers.

elfring@Sonne:~/Projekte/Linux/next-patched> LANG=C git checkout -b 
next_deletion_of_oom_messages_in_s2255drv_test_20170921 
next_deletion_of_oom_messages-20170905 && LANG=C git am '../[PATCH 2_5] [media] 
s2255drv: Adjust 13 checks for null pointers.eml'
Switched to a new branch 
'next_deletion_of_oom_messages_in_s2255drv_test_20170921'
Applying: s2255drv: Adjust 13 checks for null pointers


Would you like to clarify corresponding concerns any more?

Regards,
Markus

Re: [PATCH 02/16] hyper-v: trace vmbus_on_message()

[Vitaly Kuznetsov]

Steven Rostedt  writes:

> On Wed, 20 Sep 2017 19:21:53 +0200
> Vitaly Kuznetsov  wrote:
>
>> diff --git a/drivers/hv/hv_trace.h b/drivers/hv/hv_trace.h
>> index 9a29ef55477d..72911dfc9682 100644
>> --- a/drivers/hv/hv_trace.h
>> +++ b/drivers/hv/hv_trace.h
>> @@ -14,6 +14,14 @@ TRACE_EVENT(vmbus_on_msg_dpc,
>>  TP_printk("message %u received", __entry->msgtype)
>>  );
>>  
>> +TRACE_EVENT(vmbus_on_message,
>> +TP_PROTO(const struct vmbus_channel_message_header *hdr),
>> +TP_ARGS(hdr),
>> +TP_STRUCT__entry(__field(unsigned int, msgtype)),
>> +TP_fast_assign(__entry->msgtype = hdr->msgtype),
>> +TP_printk("processing message %u", __entry->msgtype)
>> +);
>
> Whenever you have two trace events with everything the same but the
> TP_printk(), you can save a little space by using DEFINE_EVENT_PRINT()
>
> DECLARE_EVENT_CLASS(vmbus_hdr_msg,
>   TP_PROTO(const struct vmbus_channel_message_header *hdr),
>   TP_ARGS(hdr),
>   TP_STRUCT__entry(__field(unsigned int, msgtype),
>   TP_fast_assign(__entry->msg = hdr->msgtype;),
>   TP_printk("msgtype=%d", __entry->msgtype)
> );
>
> DEFINE_EVENT_PRINT(vmbus_hdr_msg, vmbus_on_msg_dpc,
>   TP_PROTO(const struct vmbus_channel_message_header *hdr),
>   TP_ARGS(hdr),
>   TP_printk("message %u received", __entry->msgtype));
>
> DEFINE_EVENT_PRINT(vmbus_hdr_msg, vmbus_on_message,
>   TP_PROTO(const struct vmbus_channel_message_header *hdr),
>   TP_ARGS(hdr),
>   TP_printk("processing message %u", __entry->msgtype));
>
> This will use the same functions required to save and record the
> message but will use a different function to output it to the trace.

Oh, thanks! This seems to be useful for
vmbus_on_msg_dpc/vmbus_on_message only as all the rest needs to parse
different structures. Will use it in v2.

-- 
  Vitaly

[GIT PULL] mtd: Fixes for 4.14-rc2

[Boris Brezillon]

Hello Linus,

Here is my fixes PR for 4.14-rc2.

Regards,

Boris

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/mtd/fixes-for-4.14-rc2

for you to fetch changes up to 73600b619bf8b9803a0610624a0e11f5ed8f761e:

  mtd: nand: remove unused blockmask variable (2017-09-18 14:51:02 +0200)


SPI NOR:
 * Fix the SFDP parsing code (bugs reported by Geert Uytterhoeven)

NAND:
 * Fix a resource leak in the lpc32xx_mlc driver
 * Fix a build warning in the core


Boris Brezillon (1):
  mtd: spi-nor: Check consistency of the memory size extracted from the SFDP

Christophe JAILLET (1):
  mtd: nand: lpc32xx_mlc: Fix an error handling path in lpc32xx_nand_probe()

Corentin Labbe (1):
  mtd: nand: remove unused blockmask variable

Cyrille Pitchen (1):
  mtd: spi-nor: fix DMA unsafe buffer issue in spi_nor_read_sfdp()

 drivers/mtd/nand/lpc32xx_mlc.c |  3 ++-
 drivers/mtd/nand/nand_base.c   |  3 +--
 drivers/mtd/spi-nor/spi-nor.c  | 45 
++---
 3 files changed, 45 insertions(+), 6 deletions(-)

Re: [PATCH] KVM: VMX: add encapsulation kvm_vcpu_pi_need_handle

[Longpeng (Mike)]

Hi Peng,

There are two bugs in current code and Paolo already fixed them, please see:
https://www.spinics.net/lists/kvm/msg150896.html

-- 
Regards,
Longpeng(Mike)

On 2017/9/21 23:14, Peng Hao wrote:

> use kvm_vcpu_pi_need_handle encapsulation simply coede
> 
> Signed-off-by: Peng Hao 
> ---
>  arch/x86/kvm/vmx.c | 27 ---
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 4253ade..26b99f4 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -559,6 +559,13 @@ static inline int pi_test_sn(struct pi_desc *pi_desc)
>   (unsigned long *)&pi_desc->control);
>  }
>  
> +static inline bool kvm_vcpu_pi_need_handle(struct kvm_vcpu *vcpu)
> +{
> + return kvm_arch_has_assigned_device(vcpu->kvm) &&
> + irq_remapping_cap(IRQ_POSTING_CAP)  &&
> + kvm_vcpu_apicv_active(vcpu);
> +}
> +
>  struct vcpu_vmx {
>   struct kvm_vcpu   vcpu;
>   unsigned long host_rsp;
> @@ -2202,9 +2209,7 @@ static void vmx_vcpu_pi_load(struct kvm_vcpu *vcpu, int 
> cpu)
>   struct pi_desc old, new;
>   unsigned int dest;
>  
> - if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
> - !irq_remapping_cap(IRQ_POSTING_CAP)  ||
> - !kvm_vcpu_apicv_active(vcpu))
> + if (!kvm_vcpu_pi_need_handle(vcpu))
>   return;
>  
>   do {
> @@ -2323,9 +2328,7 @@ static void vmx_vcpu_pi_put(struct kvm_vcpu *vcpu)
>  {
>   struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
>  
> - if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
> - !irq_remapping_cap(IRQ_POSTING_CAP)  ||
> - !kvm_vcpu_apicv_active(vcpu))
> + if (!kvm_vcpu_pi_need_handle(vcpu))
>   return;
>  
>   /* Set SN when the vCPU is preempted */
> @@ -11691,9 +11694,7 @@ static int pi_pre_block(struct kvm_vcpu *vcpu)
>   struct pi_desc old, new;
>   struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
>  
> - if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
> - !irq_remapping_cap(IRQ_POSTING_CAP)  ||
> - !kvm_vcpu_apicv_active(vcpu))
> + if (!kvm_vcpu_pi_need_handle(vcpu))
>   return 0;
>  
>   vcpu->pre_pcpu = vcpu->cpu;
> @@ -11769,9 +11770,7 @@ static void pi_post_block(struct kvm_vcpu *vcpu)
>   unsigned int dest;
>   unsigned long flags;
>  
> - if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
> - !irq_remapping_cap(IRQ_POSTING_CAP)  ||
> - !kvm_vcpu_apicv_active(vcpu))
> + if (!kvm_vcpu_pi_need_handle(vcpu))
>   return;
>  
>   do {
> @@ -11831,9 +11830,7 @@ static int vmx_update_pi_irte(struct kvm *kvm, 
> unsigned int host_irq,
>   struct vcpu_data vcpu_info;
>   int idx, ret = -EINVAL;
>  
> - if (!kvm_arch_has_assigned_device(kvm) ||
> - !irq_remapping_cap(IRQ_POSTING_CAP) ||
> - !kvm_vcpu_apicv_active(kvm->vcpus[0]))
> + if (!kvm_vcpu_pi_need_handle(kvm->vcpus[0]))
>   return 0;
>  
>   idx = srcu_read_lock(&kvm->irq_srcu);


-- 
Regards,
Longpeng(Mike)

Re: [PATCH 2/2] mm: oom: show unreclaimable slab info when kernel panic

[David Rientjes]

On Thu, 21 Sep 2017, Yang Shi wrote:

> Kernel may panic when oom happens without killable process sometimes it
> is caused by huge unreclaimable slabs used by kernel.
> 
> Although kdump could help debug such problem, however, kdump is not
> available on all architectures and it might be malfunction sometime.
> And, since kernel already panic it is worthy capturing such information
> in dmesg to aid touble shooting.
> 
> Print out unreclaimable slab info (used size and total size) which
> actual memory usage is not zero (num_objs * size != 0) when panic_on_oom is 
> set
> or no killable process. Since such information is just showed when kernel
> panic, so it will not lead too verbose message for normal oom.
> 
> The output looks like:
> 
> Unreclaimable slab info:
> Name  Used  Total
> rpc_buffers   31KB 31KB
> rpc_tasks  7KB  7KB
> ebitmap_node1964KB   1964KB
> avtab_node  5024KB   5024KB
> xfs_buf 1402KB   1402KB
> xfs_ili  134KB134KB
> xfs_efi_item 115KB115KB
> xfs_efd_item 115KB115KB
> xfs_buf_item 134KB134KB
> xfs_log_item_desc342KB342KB
> xfs_trans   1412KB   1412KB
> xfs_ifork212KB212KB
> 
> Signed-off-by: Yang Shi 
> ---
>  mm/oom_kill.c|  3 +++
>  mm/slab.h|  8 
>  mm/slab_common.c | 26 ++
>  3 files changed, 37 insertions(+)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 99736e0..bd48d34 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -43,6 +43,7 @@
>  
>  #include 
>  #include "internal.h"
> +#include "slab.h"
>  
>  #define CREATE_TRACE_POINTS
>  #include 
> @@ -960,6 +961,7 @@ static void check_panic_on_oom(struct oom_control *oc,
>   if (is_sysrq_oom(oc))
>   return;
>   dump_header(oc, NULL);
> + dump_unreclaimable_slab();
>   panic("Out of memory: %s panic_on_oom is enabled\n",
>   sysctl_panic_on_oom == 2 ? "compulsory" : "system-wide");
>  }
> @@ -1044,6 +1046,7 @@ bool out_of_memory(struct oom_control *oc)
>   /* Found nothing?!?! Either we hang forever, or we panic. */
>   if (!oc->chosen && !is_sysrq_oom(oc) && !is_memcg_oom(oc)) {
>   dump_header(oc, NULL);
> + dump_unreclaimable_slab();
>   panic("Out of memory and no killable processes...\n");
>   }
>   if (oc->chosen && oc->chosen != (void *)-1UL) {
> diff --git a/mm/slab.h b/mm/slab.h
> index 0733628..734a92d 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -505,6 +505,14 @@ static inline struct kmem_cache_node *get_node(struct 
> kmem_cache *s, int node)
>  void memcg_slab_stop(struct seq_file *m, void *p);
>  int memcg_slab_show(struct seq_file *m, void *p);
>  
> +#ifdef CONFIG_SLABINFO
> +void dump_unreclaimable_slab(void);
> +#else
> +void dump_unreclaimable_slab(void);

This won't compile when CONFIG_SLABINFO is disabled.

static inline void dump_unreclaimable_slab(void)
{
}

when CONFIG_SLABINFO=n.

> +{
> +}
> +#endif
> +
>  void ___cache_free(struct kmem_cache *cache, void *x, unsigned long addr);
>  
>  #ifdef CONFIG_SLAB_FREELIST_RANDOM
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 904a83b..90d9de3 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1272,6 +1272,32 @@ static int slab_show(struct seq_file *m, void *p)
>   return 0;
>  }
>  
> +void dump_unreclaimable_slab(void)
> +{
> + struct kmem_cache *s;
> + struct slabinfo sinfo;
> +
> + pr_info("Unreclaimable slab info:\n");
> + pr_info("Name  Used  Total\n");
> +
> + /*
> +  * Here acquiring slab_mutex is unnecessary since we don't prefer to
> +  * get sleep in oom path right before kernel panic, and avoid race 
> condition.
> +  * Since it is already oom, so there should be not any big allocation
> +  * which could change the statistics significantly.

The statistics themselves aren't protected by slab_mutex, it protects the 
iteration of the list.  I would suggest still taking the mutex here unless 
there's a reason to avoid it.

> +  */
> + list_for_each_entry(s, &slab_caches, list) {
> + if (!is_root_cache(s))
> + continue;

if (!(s->flags & SLAB_RECLAIM_ACCOUNT))
continue;

No need to do the memset or get_slabinfo() if it's reclaimable, so just 
short-circuit it early in that case.

> +
> + memset(&sinfo, 0, sizeof(sinfo));
> + get_slabinfo(s, &sinfo);
> +
> + if (!(s->flags & SLAB_RECLAIM_ACCOUNT) && sinfo.num_objs > 0)
> + pr_info("%-17s %10luKB %10luKB\n", cache_name(s), 
> (sinfo.active_objs * s->size) / 1024, (sinfo.num_objs * s->size) / 1024);
> + }
> +}
> +
>  #if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
>  void *memcg_slab_start(struct seq

Re: [PATCH 9/9 v2] usb: usb251xb: Use GPIO descriptor consumer interface

[Greg KH]

On Sat, Sep 16, 2017 at 01:42:20PM +0300, Serge Semin wrote:
> diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
> index 71994b883..c2dd9742f 100644
> --- a/drivers/usb/misc/usb251xb.c
> +++ b/drivers/usb/misc/usb251xb.c
> @@ -3,6 +3,7 @@
>   * Configuration via SMBus.
>   *
>   * Copyright (c) 2017 SKIDATA AG
> + * Copyright (c) 2017 T-platforms

Again, no, please consult with your corporate lawyers why this isn't ok.

greg k-h

[RFC] [Resend] Another Para-Virtualization page recycler -- Code details, Trap-less way to return free pages to kernel

[XaviLi]

We raised a topic about PPR (Per Page Recycler) and thank to Jan Kiszka for 
advises. We are here to break up patch codes and explain the code in detail. 
There are too many things to explain in one topic. We would like to do it part 
by part. Content of original mails and patches can be found below in the end.

1.  Why another page recycler?

Freed memory always be returned to kernel in groups. User mode applications use 
munmap when the freed chunk is accumulated to be big enough. In VM world, 
balloon driver is triggered when free memory is worth to be collected. PPR 
offers a way to make a reclaim for each free-able page because it cost less CPU 
and trap-less.

The APPs or VMs release any uncopied pages to kernel instead of reserve them 
means we can use memory more efficiently. We start test from virtual machine 
scenario because the effect here is most obvious. In our experiment we can run 
516 VMs with PPR ,in contrast to 60+ without PPR. This issue is also work for 
normal applications. Here we call VM or applications as APP for simple.

2.  Basic Method:

Let begin with a question. Is it possible for APPs to set a “freed” mark at the 
beginning bytes of the page. Whether Kernel can take a glance and know it is 
reclaim-able? It is NOT possible because the memory-content is arbitrary. No 
particular value can be reserved to stand for “reclaim-able”. We let the first 
bytes of freed pages indicate the location of freed page pointer pool. Pointers 
in which are the reliable proofs of page being free-able. A wrong indicator 
leads to unproper pointer and doesn’t cause any further trouble. We call this 
method “PIP” (Pointer Indicator Pair). 

In some case pages-content are scanned periodically. One example is page 
deduplication. If we can find the page recycle-able at the beginning bytes, 
then the rest job can be saved. PPR work alone is very cheap and can win both 
CPU and memory when work with other scanners. The cost and test result can be 
found in the original mails below.

3.  Code Break Up:

The APP side:
Page Free hook: virt_mark_page_release() (page_reclaim_guest.c)
The free-page hook is called when a page is going to be freed. It just marks 
the beginning of the page as an indicator. Allocate the position of pointer 
from the pool and set the pointer to point the freed page. So that the page can 
be recycled in seconds. The allocation is quite simple because we can assume 
the pool is big enough and reclaim can happen in time to avoid the head catchup 
the tail in most cases. The pool is big but not consume much memory. Because 
when it is empty and zeroed, it can be shrunk by page-deduplication.

int virt_mark_page_release(struct page *page)
{
int pool_id ;
unsigned long long alloc_id;
unsigned long long state;
unsigned long long idx ;
volatile struct virt_release_mark *mark ;
unsigned long long time_begin = 0;
if(!guest_mem_pool)
{
clear_page_content((void*)page);
set_guest_page_clear_ok();
return -1;
}
if(!pone_page_reclaim_enable)
{
reset_guest_page_clear_ok();
return -1;
}
time_begin = rdtsc_ordered();
pool_id = guest_mem_pool->pool_id;
/*share memory pool alloc a position,the default content is 0*/
alloc_id = atomic64_add_return(1,(atomic64_t*)&guest_mem_pool->alloc_idx)-1;
idx = alloc_id%guest_mem_pool->desc_max;
state = guest_mem_pool->desc[idx];

mark = get_page_content((void*)page);
if(0 == state)
{
/*the reclaim identification store on the share mem position,using  
gfn*/
if(0 != 
atomic64_cmpxchg((atomic64_t*)&guest_mem_pool->desc[idx],0,page_to_pfn(page)))
{
/*if the alloced position used by another thread,release mark 
invalid*/
pool_id = guest_mem_pool->pool_max  +1;
idx = guest_mem_pool->desc_max +1;

//atomic64_add(1,(atomic64_t*)&guest_mem_pool->mark_release_err_conflict);

}
else
{
//atomic64_add(1,(atomic64_t*)&guest_mem_pool->mark_release_ok);
}
/*write release mark on the beginning of the release page*/
mark->pool_id = pool_id;
mark->alloc_id = idx;
barrier();
mark->desc = guest_mem_pool->mem_ind;
barrier();
put_page_content((void*)mark);
PONE_TIMEPOINT_SET(page_reclaim_free_ok , rdtsc_ordered()- time_begin);
return 0;
}
else
{
/*alloced position used by another thread,release mark invalid*/
mark->pool_id = guest_mem_pool->pool_max +1;
mark->alloc_id = guest_mem_pool->desc_max +1;
barrier();
mark->desc = guest_mem_pool->mem_ind;
barrier();
put_page_content((void*)mark);
}
//atomic64_add(1,(atomic64_t*)&guest_mem_pool->mark_release_err_state);
PONE_TIMEPOINT_SET(page_reclaim_free_fail , rdtsc_ordered()- time_begin);
return -1;
}

Page Allocation hook: virt_mark_pa

Re: [PATCH CFT 0/4] VT-d PI fixes

[Longpeng (Mike)]

Hi Paolo,

We have backported the first three patches and have tested for about 20 days, it
works fine.

So could you consider to merge this series ?

-- 
Regards,
Longpeng(Mike)

On 2017/7/11 17:16, Gonglei (Arei) wrote:

> 
> 
>> -Original Message-
>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
>> Behalf Of Paolo Bonzini
>> Sent: Tuesday, July 11, 2017 4:56 PM
>> To: Gonglei (Arei)
>> Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org; longpeng;
>> Huangweidong (C); wangxin (U); Radim Krčmář
>> Subject: Re: [PATCH CFT 0/4] VT-d PI fixes
>>
>> On 07/06/2017 11:33, Gonglei (Arei) wrote:
>>> We are testing your patch, but maybe need some time to report
>>> the results because it's not an inevitable problem.
>>>
>>> Meanwhile we also try to find a possible scenario of non-hotplugging to
>>> explain the double-add warnings.
>>
>> Hi Lei,
>>
>> do you have any updates?  
> 
> Dear Paolo,
> 
> Thanks for kicking me :) 
> 
> TBH, thinking about the reliability of productive project (we use kvm-4.4),
> we applied the patch you used in fedora pastebin, and
> the bug seems gone after one month's testing.
> 
> diff --git a/source/x86/vmx.c b/source/x86/vmx.c
> index 79012cf..efc611f 100644
> --- a/source/x86/vmx.c
> +++ b/source/x86/vmx.c
> @@ -11036,8 +11036,9 @@ static void pi_post_block(struct kvm_vcpu *vcpu)
> unsigned int dest;
> unsigned long flags;
>  
> -   if (!kvm_arch_has_assigned_device(vcpu->kvm) ||
> -   !irq_remapping_cap(IRQ_POSTING_CAP))
> +   if ((vcpu->pre_pcpu == -1) &&
> +   (!kvm_arch_has_assigned_device(vcpu->kvm) ||
> +   !irq_remapping_cap(IRQ_POSTING_CAP)))
> return;
> 
>> I would like to get at least the first three
>> patches in 4.13.
>>
> I think they are okay to me for upstream.
> 
> Thanks,
> -Gonglei
> 
> .
> 


-- 
Regards,
Longpeng(Mike)

[PATCH v4 5/7] soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap

[sean.wang]

From: Sean Wang 

Add MediaTek MT6380 regulator becoming one of PMIC wrapper slave
and also add extra new regmap_config of 32-bit mode for MT6380
since old regmap_config of 16-bit mode can't be fit into the need.

Signed-off-by: Chenglin Xu 
Signed-off-by: Chen Zhong 
Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 9c6d855..5e3a41b 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -501,6 +501,7 @@ struct pmic_wrapper;
 struct pwrap_slv_type {
const u32 *dew_regs;
enum pmic_type type;
+   const struct regmap_config *regmap;
/* pwrap operations are highly associated with the PMIC types,
 * so the pointers added increases flexibility allowing determination
 * which type is used by the detection through device tree.
@@ -1109,7 +1110,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
*dev_id)
return IRQ_HANDLED;
 }
 
-static const struct regmap_config pwrap_regmap_config = {
+static const struct regmap_config pwrap_regmap_config16 = {
.reg_bits = 16,
.val_bits = 16,
.reg_stride = 2,
@@ -1118,9 +1119,19 @@ static const struct regmap_config pwrap_regmap_config = {
.max_register = 0x,
 };
 
+static const struct regmap_config pwrap_regmap_config32 = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .reg_read = pwrap_regmap_read,
+   .reg_write = pwrap_regmap_write,
+   .max_register = 0x,
+};
+
 static const struct pwrap_slv_type pmic_mt6323 = {
.dew_regs = mt6323_regs,
.type = PMIC_MT6323,
+   .regmap = &pwrap_regmap_config16,
.pwrap_read = pwrap_read16,
.pwrap_write = pwrap_write16,
 };
@@ -1128,6 +1139,7 @@ static const struct pwrap_slv_type pmic_mt6323 = {
 static const struct pwrap_slv_type pmic_mt6380 = {
.dew_regs = NULL,
.type = PMIC_MT6380,
+   .regmap = &pwrap_regmap_config32,
.pwrap_read = pwrap_read32,
.pwrap_write = pwrap_write32,
 };
@@ -1135,6 +1147,7 @@ static const struct pwrap_slv_type pmic_mt6380 = {
 static const struct pwrap_slv_type pmic_mt6397 = {
.dew_regs = mt6397_regs,
.type = PMIC_MT6397,
+   .regmap = &pwrap_regmap_config16,
.pwrap_read = pwrap_read16,
.pwrap_write = pwrap_write16,
 };
@@ -1144,9 +1157,15 @@ static const struct of_device_id of_slave_match_tbl[] = {
.compatible = "mediatek,mt6323",
.data = &pmic_mt6323,
}, {
+   /* The MT6380 slave device is directly pointed to the regulator
+* device which is different from the cases MT6323 and MT6397
+* where they're one kind of MFDs.
+*/
+   .compatible = "mediatek,mt6380-regulator",
+   .data = &pmic_mt6380,
+   }, {
.compatible = "mediatek,mt6397",
.data = &pmic_mt6397,
-   }, {
/* sentinel */
}
 };
@@ -1325,7 +1344,7 @@ static int pwrap_probe(struct platform_device *pdev)
if (ret)
goto err_out2;
 
-   wrp->regmap = devm_regmap_init(wrp->dev, NULL, wrp, 
&pwrap_regmap_config);
+   wrp->regmap = devm_regmap_init(wrp->dev, NULL, wrp, wrp->slave->regmap);
if (IS_ERR(wrp->regmap)) {
ret = PTR_ERR(wrp->regmap);
goto err_out2;
-- 
2.7.4

[PATCH v4 7/7] soc: mediatek: pwrap: fixup warnings from coding style

[sean.wang]

From: Sean Wang 

fixup those warnings such as lines over 80 words and parenthesis
alignment which would be complained by checkpatch.pl.

Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 567d038..2d13cf6 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -1057,7 +1057,8 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
/* wait for cipher data ready@PMIC */
ret = pwrap_wait_for_state(wrp, pwrap_is_pmic_cipher_ready);
if (ret) {
-   dev_err(wrp->dev, "timeout waiting for cipher data 
ready@PMIC\n");
+   dev_err(wrp->dev,
+   "timeout waiting for cipher data ready@PMIC\n");
return ret;
}
 
@@ -1458,23 +1459,27 @@ static int pwrap_probe(struct platform_device *pdev)
if (IS_ERR(wrp->bridge_base))
return PTR_ERR(wrp->bridge_base);
 
-   wrp->rstc_bridge = devm_reset_control_get(wrp->dev, 
"pwrap-bridge");
+   wrp->rstc_bridge = devm_reset_control_get(wrp->dev,
+ "pwrap-bridge");
if (IS_ERR(wrp->rstc_bridge)) {
ret = PTR_ERR(wrp->rstc_bridge);
-   dev_dbg(wrp->dev, "cannot get pwrap-bridge reset: 
%d\n", ret);
+   dev_dbg(wrp->dev,
+   "cannot get pwrap-bridge reset: %d\n", ret);
return ret;
}
}
 
wrp->clk_spi = devm_clk_get(wrp->dev, "spi");
if (IS_ERR(wrp->clk_spi)) {
-   dev_dbg(wrp->dev, "failed to get clock: %ld\n", 
PTR_ERR(wrp->clk_spi));
+   dev_dbg(wrp->dev, "failed to get clock: %ld\n",
+   PTR_ERR(wrp->clk_spi));
return PTR_ERR(wrp->clk_spi);
}
 
wrp->clk_wrap = devm_clk_get(wrp->dev, "wrap");
if (IS_ERR(wrp->clk_wrap)) {
-   dev_dbg(wrp->dev, "failed to get clock: %ld\n", 
PTR_ERR(wrp->clk_wrap));
+   dev_dbg(wrp->dev, "failed to get clock: %ld\n",
+   PTR_ERR(wrp->clk_wrap));
return PTR_ERR(wrp->clk_wrap);
}
 
@@ -1519,8 +1524,9 @@ static int pwrap_probe(struct platform_device *pdev)
pwrap_writel(wrp, wrp->master->int_en_all, PWRAP_INT_EN);
 
irq = platform_get_irq(pdev, 0);
-   ret = devm_request_irq(wrp->dev, irq, pwrap_interrupt, 
IRQF_TRIGGER_HIGH,
-   "mt-pmic-pwrap", wrp);
+   ret = devm_request_irq(wrp->dev, irq, pwrap_interrupt,
+  IRQF_TRIGGER_HIGH,
+  "mt-pmic-pwrap", wrp);
if (ret)
goto err_out2;
 
-- 
2.7.4

[PATCH v4 0/7] Add PMIC support to MediaTek MT7622 SoC

[sean.wang]

From: Sean Wang 

Changes since v3
- rebase into Linux 4.14-rc1
- removed those patches already applied

Changes since v2:
- for patch 1/2, enhance the document as the suggestions from v2.
- for patch 3, constify the table with struct regulator_ops, also fix that
regulator doesn't have modesetting facilities it just shouldn't have the ops
and finally fix copy+paste mistake in warranty disclaimer.
- for patch 7/8, sort the things added for MT7622/MT6380 alphabetically.

Chenglin Xu (1):
  soc: mediatek: pwrap: add support for MT7622 SoC

Sean Wang (6):
  dt-bindings: arm: mediatek: add MT7622 string to the PMIC wrapper doc
  soc: mediatek: pwrap: add pwrap_read32 for reading in 32-bit mode
  soc: mediatek: pwrap: add pwrap_write32 for writing in 32-bit mode
  soc: mediatek: pwrap: update pwrap_init without slave programming
  soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap
  soc: mediatek: pwrap: fixup warnings from coding style

 .../devicetree/bindings/soc/mediatek/pwrap.txt |   1 +
 drivers/soc/mediatek/mtk-pmic-wrap.c   | 417 ++---
 2 files changed, 362 insertions(+), 56 deletions(-)

-- 
2.7.4

[PATCH v4 2/7] soc: mediatek: pwrap: add pwrap_read32 for reading in 32-bit mode

[sean.wang]

From: Sean Wang 

Some regulators such as MediaTek MT6380 has to be read in 32-bit mode.
So the patch adds pwrap_read32, rename old pwrap_read into pwrap_read16
and one function pointer is introduced for increasing flexibility allowing
the determination which mode is used by the pwrap slave detection through
device tree.

Signed-off-by: Chenglin Xu 
Signed-off-by: Chen Zhong 
Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 54 +++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index c204838..db55f13 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -487,6 +487,7 @@ static int mt8135_regs[] = {
 
 enum pmic_type {
PMIC_MT6323,
+   PMIC_MT6380,
PMIC_MT6397,
 };
 
@@ -496,9 +497,15 @@ enum pwrap_type {
PWRAP_MT8173,
 };
 
+struct pmic_wrapper;
 struct pwrap_slv_type {
const u32 *dew_regs;
enum pmic_type type;
+   /* pwrap operations are highly associated with the PMIC types,
+* so the pointers added increases flexibility allowing determination
+* which type is used by the detection through device tree.
+*/
+   int (*pwrap_read)(struct pmic_wrapper *wrp, u32 adr, u32 *rdata);
 };
 
 struct pmic_wrapper {
@@ -609,7 +616,7 @@ static int pwrap_write(struct pmic_wrapper *wrp, u32 adr, 
u32 wdata)
return 0;
 }
 
-static int pwrap_read(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
+static int pwrap_read16(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
 {
int ret;
 
@@ -632,6 +639,39 @@ static int pwrap_read(struct pmic_wrapper *wrp, u32 adr, 
u32 *rdata)
return 0;
 }
 
+static int pwrap_read32(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
+{
+   int ret, msb;
+
+   *rdata = 0;
+   for (msb = 0; msb < 2; msb++) {
+   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
+   if (ret) {
+   pwrap_leave_fsm_vldclr(wrp);
+   return ret;
+   }
+
+   pwrap_writel(wrp, ((msb << 30) | (adr << 16)),
+PWRAP_WACS2_CMD);
+
+   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_vldclr);
+   if (ret)
+   return ret;
+
+   *rdata += (PWRAP_GET_WACS_RDATA(pwrap_readl(wrp,
+  PWRAP_WACS2_RDATA)) << (16 * msb));
+
+   pwrap_writel(wrp, 1, PWRAP_WACS2_VLDCLR);
+   }
+
+   return 0;
+}
+
+static int pwrap_read(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
+{
+   return wrp->slave->pwrap_read(wrp, adr, rdata);
+}
+
 static int pwrap_regmap_read(void *context, u32 adr, u32 *rdata)
 {
return pwrap_read(context, adr, rdata);
@@ -752,6 +792,8 @@ static int pwrap_mt2701_init_reg_clock(struct pmic_wrapper 
*wrp)
pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
break;
+   default:
+   break;
}
 
return 0;
@@ -815,6 +857,8 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_EN],
0x1);
break;
+   default:
+   break;
}
 
/* wait for cipher data ready@AP */
@@ -1035,11 +1079,19 @@ static const struct regmap_config pwrap_regmap_config = 
{
 static const struct pwrap_slv_type pmic_mt6323 = {
.dew_regs = mt6323_regs,
.type = PMIC_MT6323,
+   .pwrap_read = pwrap_read16,
+};
+
+static const struct pwrap_slv_type pmic_mt6380 = {
+   .dew_regs = NULL,
+   .type = PMIC_MT6380,
+   .pwrap_read = pwrap_read32,
 };
 
 static const struct pwrap_slv_type pmic_mt6397 = {
.dew_regs = mt6397_regs,
.type = PMIC_MT6397,
+   .pwrap_read = pwrap_read16,
 };
 
 static const struct of_device_id of_slave_match_tbl[] = {
-- 
2.7.4

[PATCH v4 6/7] soc: mediatek: pwrap: add support for MT7622 SoC

[sean.wang]

From: Chenglin Xu 

Add the registers, callbacks and data structures required to make the
PMIC wrapper work on MT7622.

Signed-off-by: Chenglin Xu 
Signed-off-by: Chen Zhong 
Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 180 +++
 1 file changed, 180 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 5e3a41b..567d038 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -208,6 +208,36 @@ enum pwrap_regs {
PWRAP_ADC_RDATA_ADDR1,
PWRAP_ADC_RDATA_ADDR2,
 
+   /* MT7622 only regs */
+   PWRAP_EINT_STA0_ADR,
+   PWRAP_EINT_STA1_ADR,
+   PWRAP_STA,
+   PWRAP_CLR,
+   PWRAP_DVFS_ADR8,
+   PWRAP_DVFS_WDATA8,
+   PWRAP_DVFS_ADR9,
+   PWRAP_DVFS_WDATA9,
+   PWRAP_DVFS_ADR10,
+   PWRAP_DVFS_WDATA10,
+   PWRAP_DVFS_ADR11,
+   PWRAP_DVFS_WDATA11,
+   PWRAP_DVFS_ADR12,
+   PWRAP_DVFS_WDATA12,
+   PWRAP_DVFS_ADR13,
+   PWRAP_DVFS_WDATA13,
+   PWRAP_DVFS_ADR14,
+   PWRAP_DVFS_WDATA14,
+   PWRAP_DVFS_ADR15,
+   PWRAP_DVFS_WDATA15,
+   PWRAP_EXT_CK,
+   PWRAP_ADC_RDATA_ADDR,
+   PWRAP_GPS_STA,
+   PWRAP_SW_RST,
+   PWRAP_DVFS_STEP_CTRL0,
+   PWRAP_DVFS_STEP_CTRL1,
+   PWRAP_DVFS_STEP_CTRL2,
+   PWRAP_SPI2_CTRL,
+
/* MT8135 only regs */
PWRAP_CSHEXT,
PWRAP_EVENT_IN_EN,
@@ -330,6 +360,118 @@ static int mt2701_regs[] = {
[PWRAP_ADC_RDATA_ADDR2] =   0x154,
 };
 
+static int mt7622_regs[] = {
+   [PWRAP_MUX_SEL] =   0x0,
+   [PWRAP_WRAP_EN] =   0x4,
+   [PWRAP_DIO_EN] =0x8,
+   [PWRAP_SIDLY] = 0xC,
+   [PWRAP_RDDMY] = 0x10,
+   [PWRAP_SI_CK_CON] = 0x14,
+   [PWRAP_CSHEXT_WRITE] =  0x18,
+   [PWRAP_CSHEXT_READ] =   0x1C,
+   [PWRAP_CSLEXT_START] =  0x20,
+   [PWRAP_CSLEXT_END] =0x24,
+   [PWRAP_STAUPD_PRD] =0x28,
+   [PWRAP_STAUPD_GRPEN] =  0x2C,
+   [PWRAP_EINT_STA0_ADR] = 0x30,
+   [PWRAP_EINT_STA1_ADR] = 0x34,
+   [PWRAP_STA] =   0x38,
+   [PWRAP_CLR] =   0x3C,
+   [PWRAP_STAUPD_MAN_TRIG] =   0x40,
+   [PWRAP_STAUPD_STA] =0x44,
+   [PWRAP_WRAP_STA] =  0x48,
+   [PWRAP_HARB_INIT] = 0x4C,
+   [PWRAP_HARB_HPRIO] =0x50,
+   [PWRAP_HIPRIO_ARB_EN] = 0x54,
+   [PWRAP_HARB_STA0] = 0x58,
+   [PWRAP_HARB_STA1] = 0x5C,
+   [PWRAP_MAN_EN] =0x60,
+   [PWRAP_MAN_CMD] =   0x64,
+   [PWRAP_MAN_RDATA] = 0x68,
+   [PWRAP_MAN_VLDCLR] =0x6C,
+   [PWRAP_WACS0_EN] =  0x70,
+   [PWRAP_INIT_DONE0] =0x74,
+   [PWRAP_WACS0_CMD] = 0x78,
+   [PWRAP_WACS0_RDATA] =   0x7C,
+   [PWRAP_WACS0_VLDCLR] =  0x80,
+   [PWRAP_WACS1_EN] =  0x84,
+   [PWRAP_INIT_DONE1] =0x88,
+   [PWRAP_WACS1_CMD] = 0x8C,
+   [PWRAP_WACS1_RDATA] =   0x90,
+   [PWRAP_WACS1_VLDCLR] =  0x94,
+   [PWRAP_WACS2_EN] =  0x98,
+   [PWRAP_INIT_DONE2] =0x9C,
+   [PWRAP_WACS2_CMD] = 0xA0,
+   [PWRAP_WACS2_RDATA] =   0xA4,
+   [PWRAP_WACS2_VLDCLR] =  0xA8,
+   [PWRAP_INT_EN] =0xAC,
+   [PWRAP_INT_FLG_RAW] =   0xB0,
+   [PWRAP_INT_FLG] =   0xB4,
+   [PWRAP_INT_CLR] =   0xB8,
+   [PWRAP_SIG_ADR] =   0xBC,
+   [PWRAP_SIG_MODE] =  0xC0,
+   [PWRAP_SIG_VALUE] = 0xC4,
+   [PWRAP_SIG_ERRVAL] =0xC8,
+   [PWRAP_CRC_EN] =0xCC,
+   [PWRAP_TIMER_EN] =  0xD0,
+   [PWRAP_TIMER_STA] = 0xD4,
+   [PWRAP_WDT_UNIT] =  0xD8,
+   [PWRAP_WDT_SRC_EN] =0xDC,
+   [PWRAP_WDT_FLG] =   0xE0,
+   [PWRAP_DEBUG_INT_SEL] = 0xE4,
+   [PWRAP_DVFS_ADR0] = 0xE8,
+   [PWRAP_DVFS_WDATA0] =   0xEC,
+   [PWRAP_DVFS_ADR1] = 0xF0,
+   [PWRAP_DVFS_WDATA1] =   0xF4,
+   [PWRAP_DVFS_ADR2] = 0xF8,
+   [PWRAP_DVFS_WDATA2] =   0xFC,
+   [PWRAP_DVFS_ADR3] = 0x100,
+   [PWRAP_DVFS_WDATA3] =   0x104,
+   [PWRAP_DVFS_ADR4] = 0x108,
+   [PWRAP_DVFS_WDATA4] =   0x10C,
+   [PWRAP_DVFS_ADR5] = 0x110,
+   [PWRAP_DVFS_WDATA5] =   0x114,
+   [PWRAP_DVFS_ADR6] = 0x118,
+   [PWRAP_DVFS_WDATA6] =   0x11C,
+   [PWRAP_DVFS_ADR7] = 0x120,
+   [PWRAP_DVFS_

Re: [v8 0/4] cgroup-aware OOM killer

[David Rientjes]

On Wed, 20 Sep 2017, Roman Gushchin wrote:

> > It's actually much more complex because in our environment we'd need an 
> > "activity manager" with CAP_SYS_RESOURCE to control oom priorities of user 
> > subcontainers when today it need only be concerned with top-level memory 
> > cgroups.  Users can create their own hierarchies with their own oom 
> > priorities at will, it doesn't alter the selection heuristic for another 
> > other user running on the same system and gives them full control over the 
> > selection in their own subtree.  We shouldn't need to have a system-wide 
> > daemon with CAP_SYS_RESOURCE be required to manage subcontainers when 
> > nothing else requires it.  I believe it's also much easier to document: 
> > oom_priority is considered for all sibling cgroups at each level of the 
> > hierarchy and the cgroup with the lowest priority value gets iterated.
> 
> I do agree actually. System-wide OOM priorities make no sense.
> 
> Always compare sibling cgroups, either by priority or size, seems to be
> simple, clear and powerful enough for all reasonable use cases. Am I right,
> that it's exactly what you've used internally? This is a perfect confirmation,
> I believe.
> 

We've used it for at least four years, I added my Tested-by to your patch, 
we would convert to your implementation if it is merged upstream, and I 
would enthusiastically support your patch if you would integrate it back 
into your series.

[PATCH v4 4/7] soc: mediatek: pwrap: update pwrap_init without slave programming

[sean.wang]

From: Sean Wang 

pwrap initialization is highly associated with the base SoC, so
update here for allowing pwrap_init without slave program which would be
used to those PMICs without extra encryption on bus such as MT6380.

Signed-off-by: Chenglin Xu 
Signed-off-by: Chen Zhong 
Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 91 +---
 1 file changed, 54 insertions(+), 37 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 27d7ccc..9c6d855 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -531,6 +531,7 @@ struct pmic_wrapper_type {
u32 spi_w;
u32 wdt_src;
int has_bridge:1;
+   int slv_program:1;
int (*init_reg_clock)(struct pmic_wrapper *wrp);
int (*init_soc_specific)(struct pmic_wrapper *wrp);
 };
@@ -999,9 +1000,12 @@ static int pwrap_init(struct pmic_wrapper *wrp)
}
 
/* Reset SPI slave */
-   ret = pwrap_reset_spislave(wrp);
-   if (ret)
-   return ret;
+
+   if (wrp->master->slv_program) {
+   ret = pwrap_reset_spislave(wrp);
+   if (ret)
+   return ret;
+   }
 
pwrap_writel(wrp, 1, PWRAP_WRAP_EN);
 
@@ -1013,45 +1017,52 @@ static int pwrap_init(struct pmic_wrapper *wrp)
if (ret)
return ret;
 
-   /* Setup serial input delay */
-   ret = pwrap_init_sidly(wrp);
-   if (ret)
-   return ret;
+   if (wrp->master->slv_program) {
+   /* Setup serial input delay */
+   ret = pwrap_init_sidly(wrp);
+   if (ret)
+   return ret;
 
-   /* Enable dual IO mode */
-   pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_DIO_EN], 1);
+   /* Enable dual IO mode */
+   pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_DIO_EN], 1);
 
-   /* Check IDLE & INIT_DONE in advance */
-   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle_and_sync_idle);
-   if (ret) {
-   dev_err(wrp->dev, "%s fail, ret=%d\n", __func__, ret);
-   return ret;
-   }
+   /* Check IDLE & INIT_DONE in advance */
+   ret = pwrap_wait_for_state(wrp,
+  pwrap_is_fsm_idle_and_sync_idle);
+   if (ret) {
+   dev_err(wrp->dev, "%s fail, ret=%d\n", __func__, ret);
+   return ret;
+   }
 
-   pwrap_writel(wrp, 1, PWRAP_DIO_EN);
+   pwrap_writel(wrp, 1, PWRAP_DIO_EN);
 
-   /* Read Test */
-   pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_READ_TEST], &rdata);
-   if (rdata != PWRAP_DEW_READ_TEST_VAL) {
-   dev_err(wrp->dev, "Read test failed after switch to DIO mode: 
0x%04x != 0x%04x\n",
+   /* Read Test */
+   pwrap_read(wrp,
+  wrp->slave->dew_regs[PWRAP_DEW_READ_TEST], &rdata);
+   if (rdata != PWRAP_DEW_READ_TEST_VAL) {
+   dev_err(wrp->dev,
+   "Read failed on DIO mode: 0x%04x!=0x%04x\n",
PWRAP_DEW_READ_TEST_VAL, rdata);
-   return -EFAULT;
-   }
-
-   /* Enable encryption */
-   ret = pwrap_init_cipher(wrp);
-   if (ret)
-   return ret;
+   return -EFAULT;
+   }
 
-   /* Signature checking - using CRC */
-   if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_EN], 0x1))
-   return -EFAULT;
+   /* Enable encryption */
+   ret = pwrap_init_cipher(wrp);
+   if (ret)
+   return ret;
 
-   pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
-   pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
-   pwrap_writel(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_VAL],
-PWRAP_SIG_ADR);
-   pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
+   /* Signature checking - using CRC */
+   if (pwrap_write(wrp,
+   wrp->slave->dew_regs[PWRAP_DEW_CRC_EN], 0x1))
+   return -EFAULT;
+
+   pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
+   pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
+   pwrap_writel(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_VAL],
+PWRAP_SIG_ADR);
+   pwrap_writel(wrp,
+wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
+   }
 
if (wrp->master->type == PWRAP_MT8135)
pwrap_writel(wrp, 0x7, PWRAP_RRARB_EN);
@@ -1059,8 +1070,11 @@ static int pwrap_init(struct pmic_wrapper *wrp)
pwrap_writel(wrp, 0x1, PWRAP_WACS0_EN);
pwrap_writel(wrp, 0x1, PWRAP_WACS1_EN);
pwrap_writel(wrp, 0x1, PWRAP_WACS2_EN);
-   pwrap_writel(wrp, 0x5,

[PATCH v4 1/7] dt-bindings: arm: mediatek: add MT7622 string to the PMIC wrapper doc

[sean.wang]

From: Sean Wang 

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

diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt 
b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
index 107700d..bd97f22 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
@@ -19,6 +19,7 @@ IP Pairing
 Required properties in pwrap device node.
 - compatible:
"mediatek,mt2701-pwrap" for MT2701/7623 SoCs
+   "mediatek,mt7622-pwrap" for MT7622 SoCs
"mediatek,mt8135-pwrap" for MT8135 SoCs
"mediatek,mt8173-pwrap" for MT8173 SoCs
 - interrupts: IRQ for pwrap in SOC
-- 
2.7.4

[PATCH v4 3/7] soc: mediatek: pwrap: add pwrap_write32 for writing in 32-bit mode

[sean.wang]

From: Sean Wang 

Some regulators such as MediaTek MT6380 also has to be written in
32-bit mode. So the patch adds pwrap_write32, rename old pwrap_write
into pwrap_write16 and one additional function pointer is introduced
for increasing flexibility allowing the determination which mode is
used by the pwrap slave detection through device tree.

Signed-off-by: Chenglin Xu 
Signed-off-by: Chen Zhong 
Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 63 +++-
 1 file changed, 47 insertions(+), 16 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index db55f13..27d7ccc 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -506,6 +506,7 @@ struct pwrap_slv_type {
 * which type is used by the detection through device tree.
 */
int (*pwrap_read)(struct pmic_wrapper *wrp, u32 adr, u32 *rdata);
+   int (*pwrap_write)(struct pmic_wrapper *wrp, u32 adr, u32 wdata);
 };
 
 struct pmic_wrapper {
@@ -600,22 +601,6 @@ static int pwrap_wait_for_state(struct pmic_wrapper *wrp,
} while (1);
 }
 
-static int pwrap_write(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
-{
-   int ret;
-
-   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
-   if (ret) {
-   pwrap_leave_fsm_vldclr(wrp);
-   return ret;
-   }
-
-   pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
-   PWRAP_WACS2_CMD);
-
-   return 0;
-}
-
 static int pwrap_read16(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
 {
int ret;
@@ -672,6 +657,49 @@ static int pwrap_read(struct pmic_wrapper *wrp, u32 adr, 
u32 *rdata)
return wrp->slave->pwrap_read(wrp, adr, rdata);
 }
 
+static int pwrap_write16(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
+{
+   int ret;
+
+   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
+   if (ret) {
+   pwrap_leave_fsm_vldclr(wrp);
+   return ret;
+   }
+
+   pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
+PWRAP_WACS2_CMD);
+
+   return 0;
+}
+
+static int pwrap_write32(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
+{
+   int ret, msb, rdata;
+
+   for (msb = 0; msb < 2; msb++) {
+   ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
+   if (ret) {
+   pwrap_leave_fsm_vldclr(wrp);
+   return ret;
+   }
+
+   pwrap_writel(wrp, (1 << 31) | (msb << 30) | (adr << 16) |
+((wdata >> (msb * 16)) & 0x),
+PWRAP_WACS2_CMD);
+
+   if (!msb)
+   pwrap_read(wrp, adr, &rdata);
+   }
+
+   return 0;
+}
+
+static int pwrap_write(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
+{
+   return wrp->slave->pwrap_write(wrp, adr, wdata);
+}
+
 static int pwrap_regmap_read(void *context, u32 adr, u32 *rdata)
 {
return pwrap_read(context, adr, rdata);
@@ -1080,18 +1108,21 @@ static const struct pwrap_slv_type pmic_mt6323 = {
.dew_regs = mt6323_regs,
.type = PMIC_MT6323,
.pwrap_read = pwrap_read16,
+   .pwrap_write = pwrap_write16,
 };
 
 static const struct pwrap_slv_type pmic_mt6380 = {
.dew_regs = NULL,
.type = PMIC_MT6380,
.pwrap_read = pwrap_read32,
+   .pwrap_write = pwrap_write32,
 };
 
 static const struct pwrap_slv_type pmic_mt6397 = {
.dew_regs = mt6397_regs,
.type = PMIC_MT6397,
.pwrap_read = pwrap_read16,
+   .pwrap_write = pwrap_write16,
 };
 
 static const struct of_device_id of_slave_match_tbl[] = {
-- 
2.7.4

Re: [v8 0/4] cgroup-aware OOM killer

[David Rientjes]

On Mon, 18 Sep 2017, Roman Gushchin wrote:

> > As said in other email. We can make priorities hierarchical (in the same
> > sense as hard limit or others) so that children cannot override their
> > parent.
> 
> You mean they can set the knob to any value, but parent's value is enforced,
> if it's greater than child's value?
> 
> If so, this sounds logical to me. Then we have size-based comparison and
> priority-based comparison with similar rules, and all use cases are covered.
> 
> Ok, can we stick with this design?
> Then I'll return oom_priorities in place, and post a (hopefully) final 
> version.
> 

I just want to make sure that we are going with your original 
implementation here: that oom_priority is only effective for compare 
sibling memory cgroups and nothing beyond that.  The value alone has no 
relationship to any ancestor.  We can't set oom_priority based on the 
priorities of any other memory cgroups other than our own siblings because 
we have no control over how those change.

Re: Possible gcc 4.8.5 bug about RELOC_HIDE marcro

[Jia He]

Thanks Mikael

It is a known gcc bug, please see 
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00790.html



Cheers,

Jusitn(Jia He)


在 9/21/2017 3:53 PM, Mikael Pettersson Wrote:

Jia He writes:
  > I tried to build kernel 4.14-rc1 on a arm64 server in distro centos 7.3.
  > The gcc version is 4.8.5

I have no input on the specifics of the issue, but please note that gcc-4.8
is no longer supported or maintained by upstream.  Even gcc-4.9 is EOL, and
gcc-5 will be EOL:d inn a week or so.  Also I'll note that gcc-4.8 is still
fairly early wrt to arm64 support, so bugs may be expected.

In short, please retry with gcc-6.4 or gcc-7.2.

Re: usb/media/cx231xx: null-ptr-deref in cx231xx_usb_probe

[Johan Hovold]

On Wed, Sep 20, 2017 at 08:54:08PM +0200, Andrey Konovalov wrote:
> Hi!
> 
> I've got the following report while fuzzing the kernel with syzkaller.
> 
> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
> 
> The null-ptr-deref happens on assoc_desc->bFirstInterface, where
> assoc_desc = udev->actconfig->intf_assoc[0]. There seems to be no
> check that the device actually contains an Interface Association
> Descriptor.

That is indeed a bug; I'll respond to this mail with a fix.

Thanks,
Johan

Re: [PATCH v4] PCI: quirks: update Cavium ThunderX ACS quirk implementation

[Vadim Lomovtsev]

On Wed, Sep 20, 2017 at 10:31:51AM -0600, Alex Williamson wrote:
> On Mon, 18 Sep 2017 01:48:01 -0700
> Vadim Lomovtsev  wrote:
> 
> > This commit makes Cavium PCI ACS quirk applicable only to Cavium
> > ThunderX (CN81/83/88XX) PCIE Root Ports which has limited PCI capabilities
> > in terms of no ACS support advertisement. However, the RTL internally
> > implements similar protection as if ACS had completion/request redirection,
> > upstream forwarding and validation features enabled.
> > 
> > Current quirk implementation doesn't take into account PCIERCs which
> > also needs to be quirked. So the pci device id check mask is updated
> > and check of device ID moved into separate function.
> > 
> > Signed-off-by: Vadim Lomovtsev 
> > ---
> > v1  : put device check into separate function and extend it to all
> >   Cavium PCIERC/PCCBR devices;
> > v1 -> v2: update match function in order to filter only ThunderX 
> > devices by device
> >   ids to properly filter CN8XXX devices, update subject & 
> > description with
> >   ACS register info (rejected by maillist due to triple X in 
> > subject);
> > v2 -> v3: update subject: remove CN8XXX from subject line, replace it 
> > with ThunderX;
> > v3 -> v4: update ACS mask (remove TB and TD bits), update commit 
> > message (remove
> >   ACS register printout);
> > 
> >  drivers/pci/quirks.c | 26 --
> >  1 file changed, 16 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index a4d3361..e6b904a 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -4211,20 +4211,26 @@ static int pci_quirk_amd_sb_acs(struct pci_dev 
> > *dev, u16 acs_flags)
> >  #endif
> >  }
> >  
> > -static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 acs_flags)
> > +/*
> > + * Cavium devices matching this quirk do not perform peer-to-peer
> > + * with other functions, allowing masking out these bits as if they
> > + * were unimplemented in the ACS capability.
> 
> nit,

put this down for later use..

> the description here still steals too much from the multifunction
> quirk.

description was just moved (and  needs to be rewrited) since the orignal idea 
was
just to extend quirk for all ThunderX family which has that limitation.

Would the following be more suitable here:

"The Cavium downstream ports doesn't advertise their ACS capability registers.
However, the RTL internally implements similar protection as if ACS had 
completion redirection,
forwarding and validation features enabled." ?

> Multifunction devices can often support ACS with unimplemented
> capabilities, which indicate that the device does not support the
> behavior described by that capability bit. However, downstream ports
> are required to implement certain ACS capabilities if they implement
> ACS at all.  So the code is actually asserting that the hardware
> implements *and* enables equivalent ACS functionality for these flags.

Yes it is. The hardware doesn't advertise ACS caps which is desing limitation,
however it implements similar functionality to ACS provided flags which allows 
code to assert this.

> 
> > + */
> > +#define CAVIUM_CN8XXX_ACS_FLAGS (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_SV | 
> > PCI_ACS_UF)
> > +
> > +static __inline__  bool pci_quirk_cavium_acs_match(struct pci_dev *dev)
> >  {
> > -   /*
> > -* Cavium devices matching this quirk do not perform peer-to-peer
> > -* with other functions, allowing masking out these bits as if they
> > -* were unimplemented in the ACS capability.
> > -*/
> > -   acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
> > -  PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
> > +   return (pci_is_pcie(dev) &&
> > +   (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) &&
> > +   ((dev->device & 0xf800) == 0xa000));
> 
> That's effectively 2k device IDs, 0xa000-0xa7ff that you and Cavium are
> vouching for ACS equivalent isolation.  How many of these actually
> exist?  The PCI IDs database gets really sparse after the first 64
> entries.  Internally are these device IDs allocated to programs based on
> the same ASICs or is this just a slightly more restricted crystal ball
> (ie. wishful thinking)?  Thanks,

The latter; this represents 8 SoCs, the lower 8 bits of the DEVID are used
to indicate which subdevice is used within the SoC.

Vadim

> 
> Alex
> 
> > +}
> >  
> > -   if (!((dev->device >= 0xa000) && (dev->device <= 0xa0ff)))
> > +static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 acs_flags)
> > +{
> > +   if (!pci_quirk_cavium_acs_match(dev))
> > return -ENOTTY;
> >  
> > -   return acs_flags ? 0 : 1;
> > +   return acs_flags & ~(CAVIUM_CN8XXX_ACS_FLAGS) ? 0 : 1;
> >  }
> >  
> >  static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
> 

[PATCH] [media] cx231xx-cards: fix NULL-deref on missing association descriptor

[Johan Hovold]

Make sure to check that we actually have an Interface Association
Descriptor before dereferencing it during probe to avoid dereferencing a
NULL-pointer.

Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Cc: stable  # 2.6.30
Cc: Sri Deevi 
Reported-by: Andrey Konovalov 
Signed-off-by: Johan Hovold 
---
 drivers/media/usb/cx231xx/cx231xx-cards.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index e0daa9b6c2a0..9b742d569fb5 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1684,7 +1684,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
nr = dev->devno;
 
assoc_desc = udev->actconfig->intf_assoc[0];
-   if (assoc_desc->bFirstInterface != ifnum) {
+   if (!assoc_desc || assoc_desc->bFirstInterface != ifnum) {
dev_err(d, "Not found matching IAD interface\n");
retval = -ENODEV;
goto err_if;
-- 
2.14.1

Re: [PATCH 2/2] mfd: intel-lpss: switch to suspend_late()/resume_early()

[Lee Jones]

On Thu, 21 Sep 2017, Rafael J. Wysocki wrote:

> On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain  wrote:
> > Ref: https://lkml.org/lkml/2017/9/19/649
> >
> > The intel-lpss hosts the designware i2c controller device, which
> > needs to be up and running until all its i2c child devices have
> > suspended (child devices need to be accessible over i2c until
> > suspend_late() has been called for all those devices).
> >
> > So lets delay the resetting of the controller until suspend_late().
> > I thought of renaming function to say *_late / *_early but that
> > might cause confusion since the same function is also used for runtime
> > suspend/resume.
> >
> > Fixes: 0b471aaa0e1a ("Put I2C and SPI controllers into reset state on 
> > suspend")
> > Signed-off-by: Rajat Jain 
> > ---
> >  drivers/mfd/intel-lpss.h | 7 +--
> >  1 file changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/drivers/mfd/intel-lpss.h b/drivers/mfd/intel-lpss.h
> > index 694116630ffa..865bbeaaf00c 100644
> > --- a/drivers/mfd/intel-lpss.h
> > +++ b/drivers/mfd/intel-lpss.h
> > @@ -38,12 +38,7 @@ int intel_lpss_resume(struct device *dev);
> >  #ifdef CONFIG_PM_SLEEP
> >  #define INTEL_LPSS_SLEEP_PM_OPS\
> > .prepare = intel_lpss_prepare,  \
> > -   .suspend = intel_lpss_suspend,  \
> > -   .resume = intel_lpss_resume,\
> > -   .freeze = intel_lpss_suspend,   \
> > -   .thaw = intel_lpss_resume,  \
> > -   .poweroff = intel_lpss_suspend, \
> > -   .restore = intel_lpss_resume,
> > +   SET_LATE_SYSTEM_SLEEP_PM_OPS(intel_lpss_suspend, intel_lpss_resume)
> >  #else
> >  #define INTEL_LPSS_SLEEP_PM_OPS
> >  #endif
> 
> So I sent this exact patch several days ago:
> https://patchwork.kernel.org/patch/9939809/

You did?  Any reason you didn't send it to me?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH] soc: mediatek: place Kconfig for all SoC driver under menu

[sean.wang]

From: Sean Wang 

Add cleanup for placing all Kconfig for all MediaTek SoC drivers under
the independent menu as other SoCs vendor usually did.

Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 609bb34..a2fcd7f 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -1,6 +1,8 @@
 #
 # MediaTek SoC drivers
 #
+menu "MediaTek SoC drivers"
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
depends on ARCH_MEDIATEK || COMPILE_TEST
@@ -30,3 +32,5 @@ config MTK_SCPSYS
help
  Say yes here to add support for the MediaTek SCPSYS power domain
  driver.
+
+endmenu
-- 
2.7.4

Re: shared/298 lockdep splat?

[Byungchul Park]

On Thu, Sep 21, 2017 at 08:22:56AM +1000, Dave Chinner wrote:
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.14.0-rc1-fixes #1 Tainted: GW  
> > --
> > loop0/31693 is trying to acquire lock:
> >  (&(&ip->i_mmaplock)->mr_lock){}, at: [] 
> > xfs_ilock+0x23c/0x330 [xfs]
> > 
> > but now in release context of a crosslock acquired at the following:
> >  ((complete)&ret.event){+.+.}, at: [] 
> > submit_bio_wait+0x7f/0xb0
> > 
> > which lock already depends on the new lock.
> > 
> > 
> > the existing dependency chain (in reverse order) is:
> > 
> > -> #2 ((complete)&ret.event){+.+.}:
> >lock_acquire+0xab/0x200
> >wait_for_completion_io+0x4e/0x1a0
> >submit_bio_wait+0x7f/0xb0
> >blkdev_issue_zeroout+0x71/0xa0
> >xfs_bmapi_convert_unwritten+0x11f/0x1d0 [xfs]
> >xfs_bmapi_write+0x374/0x11f0 [xfs]
> >xfs_iomap_write_direct+0x2ac/0x430 [xfs]
> >xfs_file_iomap_begin+0x20d/0xd50 [xfs]
> >iomap_apply+0x43/0xe0
> >dax_iomap_rw+0x89/0xf0
> >xfs_file_dax_write+0xcc/0x220 [xfs]
> >xfs_file_write_iter+0xf0/0x130 [xfs]
> >__vfs_write+0xd9/0x150
> >vfs_write+0xc8/0x1c0
> >SyS_write+0x45/0xa0
> >entry_SYSCALL_64_fastpath+0x1f/0xbe
> 
> This is on the lower filesystem - it's a write() syscall on a DAX
> enable filesystem. Locking in this case is:
> 
> Context   functionlock
> Lower filesystem  xfs_file_dax_write  XFS_IOLOCK_EXCL
> Lower filesystem  xfs_file_iomap_beginXFS_ILOCK_EXCL
> Lower filesystem/
>lower blkdev   submit_bio_wait wait for dax block
>   device IO completion
> 
> Which gives: IOLOCK -> &xfs_nondir_ilock_class -> IO completion
> 
> In the lower filesystem.
> 
> > -> #1 (&xfs_nondir_ilock_class){}:
> >lock_acquire+0xab/0x200
> >down_write_nested+0x4a/0xb0
> >xfs_ilock+0x263/0x330 [xfs]
> >xfs_setattr_size+0x152/0x370 [xfs]
> >xfs_vn_setattr+0x6b/0x90 [xfs]
> >notify_change+0x27d/0x3f0
> >do_truncate+0x5b/0x90
> >path_openat+0x237/0xa90
> >do_filp_open+0x8a/0xf0
> >do_sys_open+0x11c/0x1f0
> >entry_SYSCALL_64_fastpath+0x1f/0xbe
> 
> Context   functionlock
> Lower filesystem  xfs_vn_setattr  XFS_IOLOCK_EXCL
> Lower filesystem  xfs_vn_setattr  XFS_MMAPLOCK_EXCL
> Lower filesystem  xfs_setattr_sizeXFS_ILOCK_EXCL
> 
> Which gives: IOLOCK -> MMAPLOCK -> &xfs_nondir_ilock_class
> 
> i.e.: IOLOCK -> MMAPLOCK -> &xfs_nondir_ilock_class -> IO completion
> 
> In the lower filesystem.
> 
> > 
> > -> #0 (&(&ip->i_mmaplock)->mr_lock){}:
> >up_write+0x1c/0x40
> >xfs_iunlock+0x1d0/0x310 [xfs]
> >xfs_file_fallocate+0x8a/0x310 [xfs]
> >loop_queue_work+0xb7/0x8d0
> >kthread_worker_fn+0xb9/0x1f0
> 
> Context   functionlock
> Lower filesystem  xfs_file_fallocate  XFS_IOLOCK_EXCL
> Lower filesystem  xfs_file_fallocate  XFS_MMAPLOCK_EXCL
> [Lower filesystem whatever falloc calls   XFS_ILOCK_EXCL]
> Upper filesystem/
>Upper blkd loop_queue_work blk_mq_complete_request
> 
> This is clearer when the reported stack is looked at:
> 
> > lock_commit_crosslock+0x3e9/0x5c0
> > complete+0x24/0x60
> > blk_update_request+0xc2/0x3e0
> > blk_mq_end_request+0x18/0x80
> > __blk_mq_complete_request+0x9f/0x170
> > loop_queue_work+0x51/0x8d0
> > kthread_worker_fn+0xb9/0x1f0
> > kthread+0x148/0x180
> > ret_from_fork+0x2a/0x40
> 
> So this is reporting as:
> 
> > Chain exists of:
> >   &(&ip->i_mmaplock)->mr_lock --> &xfs_nondir_ilock_class --> 
> > (complete)&ret.event
> >
> >  Possible unsafe locking scenario by crosslock:
> >
> >CPU0CPU1
> >
> >   lock(&xfs_nondir_ilock_class);
> >   lock((complete)&ret.event);
> >lock(&(&ip->i_mmaplock)->mr_lock);
> >unlock((complete)&ret.event);
> >
> >*** DEADLOCK ***
> 
> Which effectively means:
> 
>   IO completion -> XFS_MMAPLOCK_EXCL .
> 
> The thing is, this IO completion has nothing to do with the lower
> filesystem - it's the IO completion for the filesystem on the loop
> device (the upper filesystem) and is not in any way related to the
> IO completion from the dax device the lower filesystem is waiting
> on.
> 
> IOWs, this is a false positive.
> 
> Peter, this is the sort of false positive I mentioned were likely to
> occur without some serious work to annotate the IO stack to prevent
> them.  We can nest multiple layers of IO completions and locking in
> the IO stack via things like loop and

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

[Zhiyong Tao]

On Thu, 2017-08-03 at 10:00 +0800, Yingjoe Chen wrote:
> On Wed, 2017-08-02 at 14:03 +0800, Zhiyong Tao wrote:
> > On Tue, 2017-08-01 at 17:14 +0800, Yingjoe Chen wrote:
> > > 
> > > Hi Zhiyong,
> > > 
> > > 
> > > 
> > > On Mon, 2017-07-31 at 16:22 +0800, Zhiyong Tao wrote:
> > > <...>
> > > > 3)Add "spec_dir_set" and "spec_dir_get" in "mtk_pinctrl_devdata".
> > > > 4)Change "spec_dir_set" and add "spec_dir_get" in "pinctrl-mt2701.c"
> > > >   and "pinctrl-mtk-common.c".
> > > 
> > > I think these deserve another patch.
> > > Please also explain why we need this.
> > 
> > ==> ok, I will separate it in another patch in the next version.
> > Because we should control another gpio base register for gpio16 and 17
> > in mt2712 E1. It is special for the direction control in gpio16 and
> > gpio17.
> > > 
> > > 
> > > > 5)Change "port_mask" from "7" to "6" for EINT.
> > > 
> > > I'm assuming this is a bug fix for mt2701?
> > > If yes, this should be a separate patch.
> > 
> > ==> yes, it is a bug fix for mt2701. When I use EINT bothe edge triggle,
> > offset can't get the offset address which offset address is 1/3/5/7.
> > I will separate it in another patch in the next version.
> > > 
> > > > 6)Remove generic pull config condition in "mtk_pconf_set_pull_select".
> > > > 7)Change "arg" to "MTK_PUPD_SET_R1R0_00" of "mtk_pconf_set_pull_select".
> > > 
> > > Why we need to change arg?
> > 
> > ==> to parse the "bias-disable" property in dts for special pins.
> > 
> > > 
> > > 
> > > > 
> > > > Signed-off-by: Zhiyong Tao 
> > > > ---
> > > >  drivers/pinctrl/mediatek/Kconfig  |8 +
> > > >  drivers/pinctrl/mediatek/Makefile |1 +
> > > >  drivers/pinctrl/mediatek/pinctrl-mt2701.c |   21 +-
> > > >  drivers/pinctrl/mediatek/pinctrl-mt2712.c |  670 +
> > > >  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   16 +-
> > > >  drivers/pinctrl/mediatek/pinctrl-mtk-common.h |   44 +-
> > > >  drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1858 
> > > > +
> > > >  7 files changed, 2586 insertions(+), 32 deletions(-)
> > > >  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
> > > >  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> > > > 
> > > 
> > > <...>
> > > 
> > > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2701.c 
> > > > b/drivers/pinctrl/mediatek/pinctrl-mt2701.c
> > > > index f86f3b3..4a43f5c 100644
> > > > --- a/drivers/pinctrl/mediatek/pinctrl-mt2701.c
> > > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt2701.c
> > > > @@ -503,10 +503,26 @@ static void mt2701_spec_pinmux_set(struct regmap 
> > > > *reg, unsigned int pin,
> > > > regmap_update_bits(reg, mt2701_spec_pinmux[i].offset, mask, 
> > > > value);
> > > >  }
> > > >  
> > > > -static void mt2701_spec_dir_set(unsigned int *reg_addr, unsigned int 
> > > > pin)
> > > > +static int mt2701_spec_dir_set(struct mtk_pinctrl *pctl,
> > > > +   unsigned int *reg_addr,
> > > > +   unsigned int pin,
> > > > +   bool input)
> > > >  {
> > > > if (pin > 175)
> > > > *reg_addr += 0x10;
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > > +static int mt2701_spec_dir_get(struct mtk_pinctrl *pctl,
> > > > +   unsigned int *reg_addr,
> > > > +   unsigned int pin,
> > > > +   bool input)
> > > 
> > > incorrect prototype?
> > > 
> > > > +{
> > > > +   if (pin > 175)
> > > > +   *reg_addr += 0x10;
> > > > +
> > > > +   return 0;
> > > >  }
> > > >  
> > > >  static const struct mtk_pinctrl_devdata mt2701_pinctrl_data = {
> > > > @@ -520,6 +536,7 @@ static void mt2701_spec_dir_set(unsigned int 
> > > > *reg_addr, unsigned int pin)
> > > > .spec_ies_smt_set = mt2701_ies_smt_set,
> > > > .spec_pinmux_set = mt2701_spec_pinmux_set,
> > > > .spec_dir_set = mt2701_spec_dir_set,
> > > > +   .spec_dir_get = mt2701_spec_dir_get,
> > > > .dir_offset = 0x,
> > > > .pullen_offset = 0x0150,
> > > > .pullsel_offset = 0x0280,
> > > > @@ -551,7 +568,7 @@ static void mt2701_spec_dir_set(unsigned int 
> > > > *reg_addr, unsigned int pin)
> > > > .dbnc_ctrl = 0x500,
> > > > .dbnc_set  = 0x600,
> > > > .dbnc_clr  = 0x700,
> > > > -   .port_mask = 6,
> > > > +   .port_mask = 7,
> > > > .ports = 6,
> > > > },
> > > > .ap_num = 169,
> > > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c 
> > > > b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> > > > new file mode 100644
> > > > index 000..c933b75
> > > > --- /dev/null
> > > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> > > 
> > > <...>
> > > 
> > > > +
> > > > +static int mt2712_spec_dir_set(struct mtk_pinctrl *pctl,
> > > > +   

Re: [PATCH V5 1/4] soc: brcmstb: Add Product ID and Family ID helper functions

[Kishon Vijay Abraham I]

Hi,

On Saturday 02 September 2017 07:45 AM, Florian Fainelli wrote:
> 
> 
> On 08/25/2017 10:51 AM, Al Cooper wrote:
>> Signed-off-by: Al Cooper 
> 
> Acked-by: Florian Fainelli 

I get the following checkpatch warning
CHECK: Macro argument reuse 'reg' - possible side-effects?
#110: FILE: include/linux/soc/brcmstb/brcmstb.h:4:
+#define BRCM_ID(reg)   ((u32)reg >> 28 ? (u32)reg >> 16 : (u32)reg >> 8)

Can you fix it and resend. While at that also add commmit log.

Thanks
Kishon

> 
>> ---
>>  drivers/soc/bcm/brcmstb/common.c| 12 
>>  include/linux/soc/brcmstb/brcmstb.h | 10 ++
>>  2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/soc/bcm/brcmstb/common.c 
>> b/drivers/soc/bcm/brcmstb/common.c
>> index b6195fd..184dbf5 100644
>> --- a/drivers/soc/bcm/brcmstb/common.c
>> +++ b/drivers/soc/bcm/brcmstb/common.c
>> @@ -40,6 +40,18 @@ bool soc_is_brcmstb(void)
>>  return of_match_node(brcmstb_machine_match, root) != NULL;
>>  }
>>  
>> +u32 brcmstb_get_family_id(void)
>> +{
>> +return family_id;
>> +}
>> +EXPORT_SYMBOL(brcmstb_get_family_id);
>> +
>> +u32 brcmstb_get_product_id(void)
>> +{
>> +return product_id;
>> +}
>> +EXPORT_SYMBOL(brcmstb_get_product_id);
>> +
>>  static const struct of_device_id sun_top_ctrl_match[] = {
>>  { .compatible = "brcm,bcm7125-sun-top-ctrl", },
>>  { .compatible = "brcm,bcm7346-sun-top-ctrl", },
>> diff --git a/include/linux/soc/brcmstb/brcmstb.h 
>> b/include/linux/soc/brcmstb/brcmstb.h
>> index 337ce41..23e4dc9 100644
>> --- a/include/linux/soc/brcmstb/brcmstb.h
>> +++ b/include/linux/soc/brcmstb/brcmstb.h
>> @@ -1,10 +1,20 @@
>>  #ifndef __BRCMSTB_SOC_H
>>  #define __BRCMSTB_SOC_H
>>  
>> +#define BRCM_ID(reg)((u32)reg >> 28 ? (u32)reg >> 16 : (u32)reg >> 
>> 8)
>> +#define BRCM_REV(reg)   ((u32)reg & 0xff)
>> +
>>  /*
>>   * Bus Interface Unit control register setup, must happen early during boot,
>>   * before SMP is brought up, called by machine entry point.
>>   */
>>  void brcmstb_biuctrl_init(void);
>>  
>> +/*
>> + * Helper functions for getting family or product id from the
>> + * SoC driver.
>> + */
>> +u32 brcmstb_get_family_id(void);
>> +u32 brcmstb_get_product_id(void);
>> +
>>  #endif /* __BRCMSTB_SOC_H */
>>
> 

Re: [PATCH] rtc: interface: set the next alarm event appropriately

[Alexandre Belloni]

Hi,

On 21/09/2017 at 14:45:17 +0800, YiPing Xu wrote:
> 
> 
> On 2017/9/20 17:16, Alexandre Belloni wrote:
> > Hi,
> > 
> > On 20/09/2017 at 11:22:31 +0800, Xu Yiping wrote:
> > > From: Xu YiPing  
> > > 
> > > After commit 2b2f5ff00f63 ("rtc: interface: ignore expired timers when
> > > enqueuing new timers"), the rtc_timer_enqueue will not reprogram the RTC
> > > when there is any non-expired timers in the timerqueue. If we set a
> > > RTC_TIMER between now and the next non-expired timers, it won't go into
> > > effect in time.
> > > 
> > > So, besides ignoring the expired timers, we should take the next effect
> > > timer into account, and reprogram the RTC timer appropriately.
> > > 
> > 
> > Can you try this patch instead? I think it solves this issue:
> > http://patchwork.ozlabs.org/patch/792482/
> 
>We've tested this patch, it works too.
> 
>Will it be merged into the main tree?
> 

Yes, I will send it as a fix for 4.14.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 0/4] numa, iommu/smmu: IOMMU/SMMU driver optimization for NUMA systems

[Ganapatrao Kulkarni]

Adding numa aware memory allocations used for iommu dma allocation and
memory allocated for SMMU stream tables, page walk tables and command queues.

With this patch, iperf testing on ThunderX2, with 40G NIC card on
NODE 1 PCI shown same performance(around 30% improvement) as NODE 0.

Ganapatrao Kulkarni (4):
  mm: move function alloc_pages_exact_nid out of __meminit
  numa, iommu/io-pgtable-arm: Use NUMA aware memory allocation for smmu
translation tables
  iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and
comamnd queues
  iommu/dma, numa: Use NUMA aware memory allocations in
__iommu_dma_alloc_pages

 drivers/iommu/arm-smmu-v3.c| 57 +-
 drivers/iommu/dma-iommu.c  | 17 +++--
 drivers/iommu/io-pgtable-arm.c |  4 ++-
 include/linux/gfp.h|  2 +-
 mm/page_alloc.c|  3 ++-
 5 files changed, 67 insertions(+), 16 deletions(-)

-- 
2.9.4

[PATCH 2/4] numa, iommu/io-pgtable-arm: Use NUMA aware memory allocation for smmu translation tables

[Ganapatrao Kulkarni]

function __arm_lpae_alloc_pages is used to allcoated memory for smmu
translation tables. updating function to allocate memory/pages
from the proximity domain of SMMU device.

Signed-off-by: Ganapatrao Kulkarni 
---
 drivers/iommu/io-pgtable-arm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index e8018a3..f6d01f6 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -215,8 +215,10 @@ static void *__arm_lpae_alloc_pages(size_t size, gfp_t gfp,
 {
struct device *dev = cfg->iommu_dev;
dma_addr_t dma;
-   void *pages = alloc_pages_exact(size, gfp | __GFP_ZERO);
+   void *pages;
 
+   pages = alloc_pages_exact_nid(dev_to_node(dev), size,
+   gfp | __GFP_ZERO);
if (!pages)
return NULL;
 
-- 
2.9.4

[PATCH 1/4] mm: move function alloc_pages_exact_nid out of __meminit

[Ganapatrao Kulkarni]

This function can be used on NUMA systems in place of alloc_pages_exact
Adding code to export and to remove __meminit section tagging.

Signed-off-by: Ganapatrao Kulkarni 
---
 include/linux/gfp.h | 2 +-
 mm/page_alloc.c | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index f780718..a4bd234 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -528,7 +528,7 @@ extern unsigned long get_zeroed_page(gfp_t gfp_mask);
 
 void *alloc_pages_exact(size_t size, gfp_t gfp_mask);
 void free_pages_exact(void *virt, size_t size);
-void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask);
+void *alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask);
 
 #define __get_free_page(gfp_mask) \
__get_free_pages((gfp_mask), 0)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c841af8..7975870 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4442,7 +4442,7 @@ EXPORT_SYMBOL(alloc_pages_exact);
  * Like alloc_pages_exact(), but try to allocate on node nid first before 
falling
  * back.
  */
-void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask)
+void *alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask)
 {
unsigned int order = get_order(size);
struct page *p = alloc_pages_node(nid, gfp_mask, order);
@@ -4450,6 +4450,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t 
size, gfp_t gfp_mask)
return NULL;
return make_alloc_exact((unsigned long)page_address(p), order, size);
 }
+EXPORT_SYMBOL(alloc_pages_exact_nid);
 
 /**
  * free_pages_exact - release memory allocated via alloc_pages_exact()
-- 
2.9.4

[PATCH 4/4] iommu/dma, numa: Use NUMA aware memory allocations in __iommu_dma_alloc_pages

[Ganapatrao Kulkarni]

Change function __iommu_dma_alloc_pages to allocate memory/pages
for dma from respective device numa node.

Signed-off-by: Ganapatrao Kulkarni 
---
 drivers/iommu/dma-iommu.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe..0626b58 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -428,20 +428,21 @@ static void __iommu_dma_free_pages(struct page **pages, 
int count)
kvfree(pages);
 }
 
-static struct page **__iommu_dma_alloc_pages(unsigned int count,
-   unsigned long order_mask, gfp_t gfp)
+static struct page **__iommu_dma_alloc_pages(struct device *dev,
+   unsigned int count, unsigned long order_mask, gfp_t gfp)
 {
struct page **pages;
unsigned int i = 0, array_size = count * sizeof(*pages);
+   int numa_node = dev_to_node(dev);
 
order_mask &= (2U << MAX_ORDER) - 1;
if (!order_mask)
return NULL;
 
if (array_size <= PAGE_SIZE)
-   pages = kzalloc(array_size, GFP_KERNEL);
+   pages = kzalloc_node(array_size, GFP_KERNEL, numa_node);
else
-   pages = vzalloc(array_size);
+   pages = vzalloc_node(array_size, numa_node);
if (!pages)
return NULL;
 
@@ -462,8 +463,9 @@ static struct page **__iommu_dma_alloc_pages(unsigned int 
count,
unsigned int order = __fls(order_mask);
 
order_size = 1U << order;
-   page = alloc_pages((order_mask - order_size) ?
-  gfp | __GFP_NORETRY : gfp, order);
+   page = alloc_pages_node(numa_node,
+   (order_mask - order_size) ?
+  gfp | __GFP_NORETRY : gfp, order);
if (!page)
continue;
if (!order)
@@ -548,7 +550,8 @@ struct page **iommu_dma_alloc(struct device *dev, size_t 
size, gfp_t gfp,
alloc_sizes = min_size;
 
count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   pages = __iommu_dma_alloc_pages(count, alloc_sizes >> PAGE_SHIFT, gfp);
+   pages = __iommu_dma_alloc_pages(dev, count, alloc_sizes >> PAGE_SHIFT,
+   gfp);
if (!pages)
return NULL;
 
-- 
2.9.4

[PATCH] soc: mediatek: turn MTK_PMIC_WRAP into visible symbols

[sean.wang]

From: Sean Wang 

MTK_PMIC_WRAP is the basic and required configuration for those various
MediaTek PMICs, so turning MTK_PMIC_WRAP into visible symbols easily
allows users tending to have the enablement for those PMICs.

Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index a2fcd7f..d513629 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -15,7 +15,7 @@ config MTK_INFRACFG
 config MTK_PMIC_WRAP
tristate "MediaTek PMIC Wrapper Support"
depends on ARCH_MEDIATEK
-   depends on RESET_CONTROLLER
+   select RESET_CONTROLLER
select REGMAP
help
  Say yes here to add support for MediaTek PMIC Wrapper found
-- 
2.7.4

[PATCH 3/4] iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and comamnd queues

[Ganapatrao Kulkarni]

Introduce smmu_alloc_coherent and smmu_free_coherent functions to
allocate/free dma coherent memory from NUMA node associated with SMMU.
Replace all calls of dmam_alloc_coherent with smmu_alloc_coherent
for SMMU stream tables and command queues.

Signed-off-by: Ganapatrao Kulkarni 
---
 drivers/iommu/arm-smmu-v3.c | 57 -
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..bc4ba1f 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1158,6 +1158,50 @@ static void arm_smmu_init_bypass_stes(u64 *strtab, 
unsigned int nent)
}
 }
 
+static void *smmu_alloc_coherent(struct arm_smmu_device *smmu, size_t size,
+   dma_addr_t *dma_handle, gfp_t gfp)
+{
+   struct device *dev = smmu->dev;
+   void *pages;
+   dma_addr_t dma;
+   int numa_node = dev_to_node(dev);
+
+   pages = alloc_pages_exact_nid(numa_node, size, gfp | __GFP_ZERO);
+   if (!pages)
+   return NULL;
+
+   if (!(smmu->features & ARM_SMMU_FEAT_COHERENCY)) {
+   dma = dma_map_single(dev, pages, size, DMA_TO_DEVICE);
+   if (dma_mapping_error(dev, dma))
+   goto out_free;
+   /*
+* We depend on the SMMU being able to work with any physical
+* address directly, so if the DMA layer suggests otherwise by
+* translating or truncating them, that bodes very badly...
+*/
+   if (dma != virt_to_phys(pages))
+   goto out_unmap;
+   }
+
+   *dma_handle = (dma_addr_t)virt_to_phys(pages);
+   return pages;
+
+out_unmap:
+   dev_err(dev, "Cannot accommodate DMA translation for IOMMU page 
tables\n");
+   dma_unmap_single(dev, dma, size, DMA_TO_DEVICE);
+out_free:
+   free_pages_exact(pages, size);
+   return NULL;
+}
+
+static void smmu_free_coherent(struct arm_smmu_device *smmu, size_t size,
+   void *pages, dma_addr_t dma_handle)
+{
+   if (!(smmu->features & ARM_SMMU_FEAT_COHERENCY))
+   dma_unmap_single(smmu->dev, dma_handle, size, DMA_TO_DEVICE);
+   free_pages_exact(pages, size);
+}
+
 static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
 {
size_t size;
@@ -1172,7 +1216,7 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device 
*smmu, u32 sid)
strtab = &cfg->strtab[(sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_DWORDS];
 
desc->span = STRTAB_SPLIT + 1;
-   desc->l2ptr = dmam_alloc_coherent(smmu->dev, size, &desc->l2ptr_dma,
+   desc->l2ptr = smmu_alloc_coherent(smmu, size, &desc->l2ptr_dma,
  GFP_KERNEL | __GFP_ZERO);
if (!desc->l2ptr) {
dev_err(smmu->dev,
@@ -1487,7 +1531,7 @@ static void arm_smmu_domain_free(struct iommu_domain 
*domain)
struct arm_smmu_s1_cfg *cfg = &smmu_domain->s1_cfg;
 
if (cfg->cdptr) {
-   dmam_free_coherent(smmu_domain->smmu->dev,
+   smmu_free_coherent(smmu,
   CTXDESC_CD_DWORDS << 3,
   cfg->cdptr,
   cfg->cdptr_dma);
@@ -1515,7 +1559,7 @@ static int arm_smmu_domain_finalise_s1(struct 
arm_smmu_domain *smmu_domain,
if (asid < 0)
return asid;
 
-   cfg->cdptr = dmam_alloc_coherent(smmu->dev, CTXDESC_CD_DWORDS << 3,
+   cfg->cdptr = smmu_alloc_coherent(smmu, CTXDESC_CD_DWORDS << 3,
 &cfg->cdptr_dma,
 GFP_KERNEL | __GFP_ZERO);
if (!cfg->cdptr) {
@@ -1984,7 +2028,7 @@ static int arm_smmu_init_one_queue(struct arm_smmu_device 
*smmu,
 {
size_t qsz = ((1 << q->max_n_shift) * dwords) << 3;
 
-   q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma, GFP_KERNEL);
+   q->base = smmu_alloc_coherent(smmu, qsz, &q->base_dma, GFP_KERNEL);
if (!q->base) {
dev_err(smmu->dev, "failed to allocate queue (0x%zx bytes)\n",
qsz);
@@ -2069,7 +2113,7 @@ static int arm_smmu_init_strtab_2lvl(struct 
arm_smmu_device *smmu)
 size, smmu->sid_bits);
 
l1size = cfg->num_l1_ents * (STRTAB_L1_DESC_DWORDS << 3);
-   strtab = dmam_alloc_coherent(smmu->dev, l1size, &cfg->strtab_dma,
+   strtab = smmu_alloc_coherent(smmu, l1size, &cfg->strtab_dma,
 GFP_KERNEL | __GFP_ZERO);
if (!strtab) {
dev_err(smmu->dev,
@@ -2097,8 +2141,9 @@ static int arm_smmu_init_strtab_linear(struct 
arm_smmu_device *smmu)
u32 size;
struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
 
+
size = (1 << smmu->sid_bits) * (STRTAB_STE_DWORDS << 3);
-   strtab = dmam_al

Re: [PATCH V8 00/14] mmc: Add Command Queue support

[Ulf Hansson]

On 13 September 2017 at 13:40, Adrian Hunter  wrote:
> Hi
>
> Here is V8 of the hardware command queue patches without the software
> command queue patches, now using blk-mq and now with blk-mq support for
> non-CQE I/O.
>
> After the unacceptable debacle of the last release cycle, I expect an
> immediate response to these patches.
>
> HW CMDQ offers 25% - 50% better random multi-threaded I/O.  I see a slight
> 2% drop in sequential read speed but no change to sequential write.
>
> Non-CQE blk-mq showed a 3% decrease in sequential read performance.  This
> seemed to be coming from the inferior latency of running work items compared
> with a dedicated thread.  Hacking blk-mq workqueue to be unbound reduced the
> performance degradation from 3% to 1%.
>
> While we should look at changing blk-mq to give better workqueue performance,
> a bigger gain is likely to be made by adding a new host API to enable the
> next already-prepared request to be issued directly from within ->done()
> callback of the current request.

Adrian, I am reviewing this series, however let me comment on each
change individually.

I have also run some test on my ux500 board and enabling the blkmq
path via the new MMC Kconfig option. My idea was to run some iozone
comparisons between the legacy path and the new blkmq path, but I just
couldn't get to that point because of the following errors.

I am using a Kingston 4GB SDHC card, which is detected and mounted
nicely. However, when I decide to do some writes to the card I get the
following errors.

root@ME:/mnt/sdcard dd if=/dev/zero of=testfile bs=8192 count=5000 conv=fsync
[  463.714294] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  464.722656] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  466.081481] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  467.111236] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  468.669647] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  469.685699] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  471.043334] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  472.052337] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  473.342651] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  474.323760] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  475.544769] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  476.539031] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  477.748474] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[  478.724182] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!

I haven't yet got the point of investigating this any further, and
unfortunate I have a busy schedule with traveling next week. I will do
my best to look into this as soon as I can.

Perhaps you have some ideas?

Kind regards
Uffe

>
>
> Changes since V7:
> Re-based
>   mmc: core: Introduce host claiming by context
> Slightly simplified
>   mmc: core: Add parameter use_blk_mq
> New patch.
>   mmc: core: Remove unnecessary host claim
> New patch.
>   mmc: core: Export mmc_start_bkops()
> New patch.
>   mmc: core: Export mmc_start_request()
> New patch.
>   mmc: block: Add CQE and blk-mq support
> Add blk-mq support for non_CQE requests
>
> Changes since V6:
>   mmc: core: Introduce host claiming by context
> New patch.
>   mmc: core: Move mmc_start_areq() declaration
> Dropped because it has been applied
>   mmc: block: Fix block status codes
> Dropped because it has been applied
>   mmc: host: Add CQE interface
> Dropped because it has been applied
>   mmc: core: Turn off CQE before sending commands
> Dropped because it has been applied
>   mmc: block: Factor out mmc_setup_queue()
> New patch.
>   mmc: block: Add CQE support
> Drop legacy support and add blk-mq support
>
> Changes since V5:
> Re-based
>   mmc: core: Add mmc_retune_hold_now()
> Dropped because it has been applied
>   mmc: core: Add members to mmc_request and mmc_data for CQE's
> Dropped because it has been applied
>   mmc: core: Move mmc_start_areq() declaration
> New patch at Ulf's request
>   mmc: block: Fix block status codes
> Another un-related patch
>   mmc: host: Add CQE interface
> Move recovery_notifier() callback to struct mmc_request
>   mmc: core: Add support for handling CQE requests
> Roll __mmc_cqe_request_done() into mmc_cqe_request_done()
> Move function declarations requested by Ulf
>   mmc: core: Remove unused MMC_CAP2_PACKED_CMD
> Dropped because it has been applied
>   mmc: block: Add CQE support
> Add explanation to commit message
> Adjustment for changed recovery_notifier() callback
>   mmc: cqhci: support for command queue enabled host
>  

[PATCH BUGFIX/IMPROVEMENT 0/4] block, bfq: series of fixes of bugs affecting service guarantees

[Paolo Valente]

Hi,
the first patch in this series fixes a bug that causes bfq to fail to
guarantee a high responsiveness on some drives, if there is heavy
random read+write I/O in the background. More precisely, such a
failure allowed this bug to be found [1], but the bug may well cause
other yet unreported anomalies.

This fix uncovered other bugs that were concealed by the fixed bug,
for rather subtle reasons. These further bugs caused similar
responsiveness failures, but with sequential reaad+write workloads in
the background. The remaining three patches fix these further bugs.

The sum of these fixes makes responsiveness much stabler with BFQ. In
the presence of write hogs, it is however still impossible for an I/O
scheduler to guarantee perfect responsiveness in any circustance,
because of throttling issues in the virtual-memory management
subsystem, and in other higher-level components.

Thanks,
Paolo

[1] Background I/O Type: Random - Background I/O mix: Reads and writes
- Application to start: LibreOffice Writer in
http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.13-IO-Laptop


Paolo Valente (4):
  block, bfq: fix wrong init of saved start time for weight raising
  block, bfq: check and switch back to interactive wr also on queue
split
  block, bfq: let early-merged queues be weight-raised on split too
  block, bfq: decrease burst size when queues in burst exit

 block/bfq-iosched.c | 169 +++-
 1 file changed, 102 insertions(+), 67 deletions(-)

--
2.10.0

[PATCH BUGFIX/IMPROVEMENT 3/4] block, bfq: let early-merged queues be weight-raised on split too

[Paolo Valente]

A just-created bfq_queue, say Q, may happen to be merged with another
bfq_queue on the very first invocation of the function
__bfq_insert_request. In such a case, even if Q would clearly deserve
interactive weight raising (as it has just been created), the function
bfq_add_request does not make it to be invoked for Q, and thus to
activate weight raising for Q. As a consequence, when the state of Q
is saved for a possible future restore, after a split of Q from the
other bfq_queue(s), such a state happens to be (unjustly)
non-weight-raised. Then the bfq_queue will not enjoy any weight
raising on the split, even if should still be in an interactive
weight-raising period when the split occurs.

This commit solves this problem as follows, for a just-created
bfq_queue that is being early-merged: it stores directly, in the saved
state of the bfq_queue, the weight-raising state that would have been
assigned to the bfq_queue if not early-merged.

Signed-off-by: Paolo Valente 
Tested-by: Angelo Ruocco 
Tested-by: Mirko Montanari 
Tested-by: Oleksandr Natalenko 
---
 block/bfq-iosched.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 33b63bc..115747f 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2061,10 +2061,27 @@ static void bfq_bfqq_save_state(struct bfq_queue *bfqq)
bic->saved_IO_bound = bfq_bfqq_IO_bound(bfqq);
bic->saved_in_large_burst = bfq_bfqq_in_large_burst(bfqq);
bic->was_in_burst_list = !hlist_unhashed(&bfqq->burst_list_node);
-   bic->saved_wr_coeff = bfqq->wr_coeff;
-   bic->saved_wr_start_at_switch_to_srt = bfqq->wr_start_at_switch_to_srt;
-   bic->saved_last_wr_start_finish = bfqq->last_wr_start_finish;
-   bic->saved_wr_cur_max_time = bfqq->wr_cur_max_time;
+   if (unlikely(bfq_bfqq_just_created(bfqq) &&
+!bfq_bfqq_in_large_burst(bfqq))) {
+   /*
+* bfqq being merged right after being created: bfqq
+* would have deserved interactive weight raising, but
+* did not make it to be set in a weight-raised state,
+* because of this early merge. Store directly the
+* weight-raising state that would have been assigned
+* to bfqq, so that to avoid that bfqq unjustly fails
+* to enjoy weight raising if split soon.
+*/
+   bic->saved_wr_coeff = bfqq->bfqd->bfq_wr_coeff;
+   bic->saved_wr_cur_max_time = bfq_wr_duration(bfqq->bfqd);
+   bic->saved_last_wr_start_finish = jiffies;
+   } else {
+   bic->saved_wr_coeff = bfqq->wr_coeff;
+   bic->saved_wr_start_at_switch_to_srt =
+   bfqq->wr_start_at_switch_to_srt;
+   bic->saved_last_wr_start_finish = bfqq->last_wr_start_finish;
+   bic->saved_wr_cur_max_time = bfqq->wr_cur_max_time;
+   }
 }
 
 static void
@@ -4150,7 +4167,6 @@ static void __bfq_insert_request(struct bfq_data *bfqd, 
struct request *rq)
new_bfqq->allocated++;
bfqq->allocated--;
new_bfqq->ref++;
-   bfq_clear_bfqq_just_created(bfqq);
/*
 * If the bic associated with the process
 * issuing this request still points to bfqq
@@ -4162,6 +4178,8 @@ static void __bfq_insert_request(struct bfq_data *bfqd, 
struct request *rq)
if (bic_to_bfqq(RQ_BIC(rq), 1) == bfqq)
bfq_merge_bfqqs(bfqd, RQ_BIC(rq),
bfqq, new_bfqq);
+
+   bfq_clear_bfqq_just_created(bfqq);
/*
 * rq is about to be enqueued into new_bfqq,
 * release rq reference on bfqq
-- 
2.10.0

[PATCH BUGFIX/IMPROVEMENT 4/4] block, bfq: decrease burst size when queues in burst exit

[Paolo Valente]

If many queues belonging to the same group happen to be created
shortly after each other, then the concurrent processes associated
with these queues have typically a common goal, and they get it done
as soon as possible if not hampered by device idling.  Examples are
processes spawned by git grep, or by systemd during boot. As for
device idling, this mechanism is currently necessary for weight
raising to succeed in its goal: privileging I/O.  In view of these
facts, BFQ does not provide the above queues with either weight
raising or device idling.

On the other hand, a burst of queue creations may be caused also by
the start-up of a complex application. In this case, these queues need
usually to be served one after the other, and as quickly as possible,
to maximise responsiveness. Therefore, in this case the best strategy
is to weight-raise all the queues created during the burst, i.e., the
exact opposite of the strategy for the above case.

To distinguish between the two cases, BFQ uses an empirical burst-size
threshold, found through extensive tests and monitoring of daily
usage. Only large bursts, i.e., burst with a size above this
threshold, are considered as generated by a high number of parallel
processes. In this respect, upstart-based boot proved to be rather
hard to detect as generating a large burst of queue creations, because
with upstart most of the queues created in a burst exit *before* the
next queues in the same burst are created. To address this issue, I
changed the burst-detection mechanism so as to not decrease the size
of the current burst even if one of the queues in the burst is
eliminated.

Unfortunately, this missing decrease causes false positives on very
fast systems: on the start-up of a complex application, such as
libreoffice writer, so many queues are created, served and exited
shortly after each other, that a large burst of queue creations is
wrongly detected as occurring. These false positives just disappear if
the size of a burst is decreased when one of the queues in the burst
exits. This commit restores the missing burst-size decrease, relying
of the fact that upstart is apparently unlikely to be used on systems
running this and future versions of the kernel.

Signed-off-by: Paolo Valente 
Signed-off-by: Mauro Andreolini 
Signed-off-by: Angelo Ruocco 
Tested-by: Mirko Montanari 
Tested-by: Oleksandr Natalenko 
---
 block/bfq-iosched.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 115747f..70f9177 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -3725,16 +3725,10 @@ void bfq_put_queue(struct bfq_queue *bfqq)
if (bfqq->ref)
return;
 
-   if (bfq_bfqq_sync(bfqq))
-   /*
-* The fact that this queue is being destroyed does not
-* invalidate the fact that this queue may have been
-* activated during the current burst. As a consequence,
-* although the queue does not exist anymore, and hence
-* needs to be removed from the burst list if there,
-* the burst size has not to be decremented.
-*/
+   if (bfq_bfqq_sync(bfqq) && !hlist_unhashed(&bfqq->burst_list_node)) {
hlist_del_init(&bfqq->burst_list_node);
+   bfqq->bfqd->burst_size--;
+   }
 
kmem_cache_free(bfq_pool, bfqq);
 #ifdef CONFIG_BFQ_GROUP_IOSCHED
-- 
2.10.0

[PATCH BUGFIX/IMPROVEMENT 1/4] block, bfq: fix wrong init of saved start time for weight raising

[Paolo Valente]

This commit fixes a bug that causes bfq to fail to guarantee a high
responsiveness on some drives, if there is heavy random read+write I/O
in the background. More precisely, such a failure allowed this bug to
be found [1], but the bug may well cause other yet unreported
anomalies.

BFQ raises the weight of the bfq_queues associated with soft real-time
applications, to privilege the I/O, and thus reduce latency, for these
applications. This mechanism is named soft-real-time weight raising in
BFQ. A soft real-time period may happen to be nested into an
interactive weight raising period, i.e., it may happen that, when a
bfq_queue switches to a soft real-time weight-raised state, the
bfq_queue is already being weight-raised because deemed interactive
too. In this case, BFQ saves in a special variable
wr_start_at_switch_to_srt, the time instant when the interactive
weight-raising period started for the bfq_queue, i.e., the time
instant when BFQ started to deem the bfq_queue interactive. This value
is then used to check whether the interactive weight-raising period
would still be in progress when the soft real-time weight-raising
period ends.  If so, interactive weight raising is restored for the
bfq_queue. This restore is useful, in particular, because it prevents
bfq_queues from losing their interactive weight raising prematurely,
as a consequence of spurious, short-lived soft real-time
weight-raising periods caused by wrong detections as soft real-time.

If, instead, a bfq_queue switches to soft-real-time weight raising
while it *is not* already in an interactive weight-raising period,
then the variable wr_start_at_switch_to_srt has no meaning during the
following soft real-time weight-raising period. Unfortunately the
handling of this case is wrong in BFQ: not only the variable is not
flagged somehow as meaningless, but it is also set to the time when
the switch to soft real-time weight-raising occurs. This may cause an
interactive weight-raising period to be considered mistakenly as still
in progress, and thus a spurious interactive weight-raising period to
start for the bfq_queue, at the end of the soft-real-time
weight-raising period. In particular the spurious interactive
weight-raising period will be considered as still in progress, if the
soft-real-time weight-raising period does not last very long. The
bfq_queue will then be wrongly privileged and, if I/O bound, will
unjustly steal bandwidth to truly interactive or soft real-time
bfq_queues, harming responsiveness and low latency.

This commit fixes this issue by just setting wr_start_at_switch_to_srt
to minus infinity (farthest past time instant according to jiffies
macros): when the soft-real-time weight-raising period ends, certainly
no interactive weight-raising period will be considered as still in
progress.

[1] Background I/O Type: Random - Background I/O mix: Reads and writes
- Application to start: LibreOffice Writer in
http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.13-IO-Laptop

Signed-off-by: Paolo Valente 
Signed-off-by: Angelo Ruocco 
Tested-by: Oleksandr Natalenko 
Tested-by: Lee Tibbert 
Tested-by: Mirko Montanari 
---
 block/bfq-iosched.c | 50 +++---
 1 file changed, 31 insertions(+), 19 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index a4783da..c25955c 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -1202,6 +1202,24 @@ static unsigned int bfq_wr_duration(struct bfq_data 
*bfqd)
return dur;
 }
 
+/*
+ * Return the farthest future time instant according to jiffies
+ * macros.
+ */
+static unsigned long bfq_greatest_from_now(void)
+{
+   return jiffies + MAX_JIFFY_OFFSET;
+}
+
+/*
+ * Return the farthest past time instant according to jiffies
+ * macros.
+ */
+static unsigned long bfq_smallest_from_now(void)
+{
+   return jiffies - MAX_JIFFY_OFFSET;
+}
+
 static void bfq_update_bfqq_wr_on_rq_arrival(struct bfq_data *bfqd,
 struct bfq_queue *bfqq,
 unsigned int old_wr_coeff,
@@ -1216,7 +1234,19 @@ static void bfq_update_bfqq_wr_on_rq_arrival(struct 
bfq_data *bfqd,
bfqq->wr_coeff = bfqd->bfq_wr_coeff;
bfqq->wr_cur_max_time = bfq_wr_duration(bfqd);
} else {
-   bfqq->wr_start_at_switch_to_srt = jiffies;
+   /*
+* No interactive weight raising in progress
+* here: assign minus infinity to
+* wr_start_at_switch_to_srt, to make sure
+* that, at the end of the soft-real-time
+* weight raising periods that is starting
+* now, no interactive weight-raising period
+* may be wrongly considered as still in
+* progress (and thus actually started by
+  

[PATCH BUGFIX/IMPROVEMENT 2/4] block, bfq: check and switch back to interactive wr also on queue split

[Paolo Valente]

As already explained in the message of commit "block, bfq: fix
wrong init of saved start time for weight raising", if a soft
real-time weight-raising period happens to be nested in a larger
interactive weight-raising period, then BFQ restores the interactive
weight raising at the end of the soft real-time weight raising. In
particular, BFQ checks whether the latter has ended only on request
dispatches.

Unfortunately, the above scheme fails to restore interactive weight
raising in the following corner case: if a bfq_queue, say Q,
1) Is merged with another bfq_queue while it is in a nested soft
real-time weight-raising period. The weight-raising state of Q is
then saved, and not considered any longer until a split occurs.
2) Is split from the other bfq_queue(s) at a time instant when its
soft real-time weight raising is already finished.
On the split, while resuming the previous, soft real-time
weight-raised state of the bfq_queue Q, BFQ checks whether the
current soft real-time weight-raising period is actually over. If so,
BFQ switches weight raising off for Q, *without* checking whether the
soft real-time period was actually nested in a non-yet-finished
interactive weight-raising period.

This commit addresses this issue by adding the above missing check in
bfq_queue splits, and restoring interactive weight raising if needed.

Signed-off-by: Paolo Valente 
Tested-by: Angelo Ruocco 
Tested-by: Mirko Montanari 
Tested-by: Oleksandr Natalenko 
---
 block/bfq-iosched.c | 87 ++---
 1 file changed, 49 insertions(+), 38 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index c25955c..33b63bc 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -724,6 +724,44 @@ static void bfq_updated_next_req(struct bfq_data *bfqd,
}
 }
 
+static unsigned int bfq_wr_duration(struct bfq_data *bfqd)
+{
+   u64 dur;
+
+   if (bfqd->bfq_wr_max_time > 0)
+   return bfqd->bfq_wr_max_time;
+
+   dur = bfqd->RT_prod;
+   do_div(dur, bfqd->peak_rate);
+
+   /*
+* Limit duration between 3 and 13 seconds. Tests show that
+* higher values than 13 seconds often yield the opposite of
+* the desired result, i.e., worsen responsiveness by letting
+* non-interactive and non-soft-real-time applications
+* preserve weight raising for a too long time interval.
+*
+* On the other end, lower values than 3 seconds make it
+* difficult for most interactive tasks to complete their jobs
+* before weight-raising finishes.
+*/
+   if (dur > msecs_to_jiffies(13000))
+   dur = msecs_to_jiffies(13000);
+   else if (dur < msecs_to_jiffies(3000))
+   dur = msecs_to_jiffies(3000);
+
+   return dur;
+}
+
+/* switch back from soft real-time to interactive weight raising */
+static void switch_back_to_interactive_wr(struct bfq_queue *bfqq,
+ struct bfq_data *bfqd)
+{
+   bfqq->wr_coeff = bfqd->bfq_wr_coeff;
+   bfqq->wr_cur_max_time = bfq_wr_duration(bfqd);
+   bfqq->last_wr_start_finish = bfqq->wr_start_at_switch_to_srt;
+}
+
 static void
 bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct bfq_data *bfqd,
  struct bfq_io_cq *bic, bool bfq_already_existing)
@@ -750,10 +788,16 @@ bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct 
bfq_data *bfqd,
if (bfqq->wr_coeff > 1 && (bfq_bfqq_in_large_burst(bfqq) ||
time_is_before_jiffies(bfqq->last_wr_start_finish +
   bfqq->wr_cur_max_time))) {
-   bfq_log_bfqq(bfqq->bfqd, bfqq,
-   "resume state: switching off wr");
-
-   bfqq->wr_coeff = 1;
+   if (bfqq->wr_cur_max_time == bfqd->bfq_wr_rt_max_time &&
+   !bfq_bfqq_in_large_burst(bfqq) &&
+   time_is_after_eq_jiffies(bfqq->wr_start_at_switch_to_srt +
+bfq_wr_duration(bfqd))) {
+   switch_back_to_interactive_wr(bfqq, bfqd);
+   } else {
+   bfqq->wr_coeff = 1;
+   bfq_log_bfqq(bfqq->bfqd, bfqq,
+"resume state: switching off wr");
+   }
}
 
/* make sure weight will be updated, however we got here */
@@ -1173,35 +1217,6 @@ static bool bfq_bfqq_update_budg_for_activation(struct 
bfq_data *bfqd,
return wr_or_deserves_wr;
 }
 
-static unsigned int bfq_wr_duration(struct bfq_data *bfqd)
-{
-   u64 dur;
-
-   if (bfqd->bfq_wr_max_time > 0)
-   return bfqd->bfq_wr_max_time;
-
-   dur = bfqd->RT_prod;
-   do_div(dur, bfqd->peak_rate);
-
-   /*
-* Limit duration between 3 and 13 seconds. Tests show that
-* higher values than 13 seconds often yield the opposite of
-* the desired result, i.e., worsen responsiv

Product Enquiry

[Carol Merck]

Dear Sir,

We recently visited your website and we are interested in your models, We will 
like to make an order from your list of products. However, we would like to see 
your company's latest catalogs with the; minimum order quantity, delivery 
time/FOB, payment terms etc. Official order placement will follow as soon as 
possible. 

Awaiting your prompt reply.


Thanks and best regards,

Carol Merck
Purchasing Manager

Re: [PATCH v2 5/9] mtd: nand: atmel: Report PMECC failures as errors

[Romain Izard]

2017-09-18 12:00 GMT+02:00 Boris Brezillon :
> Hi Romain,
>
> On Fri, 15 Sep 2017 16:04:07 +0200
> Romain Izard  wrote:
>
>> It is not normal for the PMECC to fail when trying to fix ECC errors.
>> Report these cases as errors.
>
> I'm not sure we want to have ECC error messages at this level. ECC
> errors are rather unusual but not impossible, and sometimes it's even
> not a real error (I'm thinking of bitflips in erased pages for
> example, which are not necessarily detected/fixed in hardware).
>
> If we decide to print error messages when unfixable bitflips are
> detected, it should be done in the nand-controller driver (somewhere
> along those lines [1]).
>
> Regards,
>
> Boris
>
> [1]http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/atmel/nand-controller.c#L827
>
>>
>> Signed-off-by: Romain Izard 
>> ---
>>  drivers/mtd/nand/atmel/pmecc.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/atmel/pmecc.c b/drivers/mtd/nand/atmel/pmecc.c
>> index 8d1208f38025..2a23f1ff945f 100644
>> --- a/drivers/mtd/nand/atmel/pmecc.c
>> +++ b/drivers/mtd/nand/atmel/pmecc.c
>> @@ -687,6 +687,8 @@ static int atmel_pmecc_err_location(struct 
>> atmel_pmecc_user *user)
>>* Number of roots does not match the degree of smu
>>* unable to correct error.
>>*/
>> + dev_err(pmecc->dev,
>> + "PMECC: Impossible to calculate error location.\n");
>>   return -EBADMSG;
>>  }
>>
>> @@ -729,7 +731,7 @@ int atmel_pmecc_correct_sector(struct atmel_pmecc_user 
>> *user, int sector,
>>   ptr = ecc + byte - sectorsize;
>>   area = "ECC";
>>   } else {
>> - dev_dbg(pmecc->dev,
>> + dev_err(pmecc->dev,
>>   "Invalid errpos value (%d, max is %d)\n",
>>   errpos, (sectorsize + eccbytes) * 8);
>>   return -EINVAL;
>

Ok, I will drop this patch.

Re: [media] s2255drv: Adjust 13 checks for null pointers

[Dan Carpenter]

On Thu, Sep 21, 2017 at 10:12:56AM +0200, SF Markus Elfring wrote:
> >> MIME-Version: 1.0
> >> Content-Type: text/plain; charset=UTF-8
> >> Content-Transfer-Encoding: 8bit
> >>
> > 
> > You've been told several times that this stuff doesn't work.
> 
> This functionality might not exactly work in the way that you expect so far.
> 
> 
> > Try applying this patch with `git am` and you'll see why.
> 
> I find that these extra message fields work in the way that was designed
> by the Git software developers.
> 
> elfring@Sonne:~/Projekte/Linux/next-patched> LANG=C git checkout -b 
> next_deletion_of_oom_messages_in_s2255drv_test_20170921 
> next_deletion_of_oom_messages-20170905 && LANG=C git am '../[PATCH 2_5] 
> [media] s2255drv: Adjust 13 checks for null pointers.eml'
> Switched to a new branch 
> 'next_deletion_of_oom_messages_in_s2255drv_test_20170921'
> Applying: s2255drv: Adjust 13 checks for null pointers
> 
> 
> Would you like to clarify corresponding concerns any more?
> 

Look at the `git log` and it just copies those lines:

commit 2a47170a824697783d8c2d28355a806f075c76e4 (HEAD)
Author: Markus Elfring 
Date:   Wed Sep 20 16:46:19 2017 +0200

s2255drv: Adjust 13 checks for null pointers

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script “checkpatch.pl” pointed information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.


regards,
dan carpenter

[patch v9 0/4] JTAG driver introduction

[Oleksandr Shamray]

When a need raise up to use JTAG interface for system's devices
programming or CPU debugging, usually the user layer
application implements jtag protocol by bit-bang or using a 
proprietary connection to vendor hardware.
This method can be slow and not generic.
 
We propose to implement general JTAG interface and infrastructure
to communicate with user layer application. In such way, we can
have the standard JTAG interface core part and separation from
specific HW implementation.
This allow new capability to debug the CPU or program system's 
device via BMC without additional devices nor cost. 

This patch purpose is to add JTAG master core infrastructure by 
defining new JTAG class and provide generic JTAG interface
to allow hardware specific drivers to connect this interface.
This will enable all JTAG drivers to use the common interface
part and will have separate for hardware implementation.

The JTAG (Joint Test Action Group) core driver provides minimal generic
JTAG interface, which can be used by hardware specific JTAG master
controllers. By providing common interface for the JTAG controllers,
user space device programing is hardware independent.
 
Modern SoC which in use for embedded system' equipped with
internal JTAG master interface.
This interface is used for programming and debugging system's
hardware components, like CPLD, FPGA, CPU, voltage and
industrial controllers.
Firmware for such devices can be upgraded through JTAG interface during
Runtime. The JTAG standard support for multiple devices programming,
is in case their lines are daisy-chained together.

For example, systems which equipped with host CPU, BMC SoC or/and 
number of programmable devices are capable to connect a pin and
select system components dynamically for programming and debugging,
This is using by the BMC which is equipped with internal SoC master
controller.
For example:

BMC JTAG master --> pin selected to CPLDs chain for programming (filed
upgrade, production) 
BMC JTAG master --> pin selected to voltage monitors for programming 
(field upgrade, production) 
BMC JTAG master --> pin selected to host CPU (on-site debugging 
and developers debugging)

For example, we can have application in user space which using calls
to JTAG driver executes CPLD programming directly from SVF file
 
The JTAG standard (IEEE 1149.1) defines the next connector pins:
- TDI (Test Data In);
- TDO (Test Data Out);
- TCK (Test Clock);
- TMS (Test Mode Select);
- TRST (Test Reset) (Optional);

The SoC equipped with JTAG master controller, performs
device programming on command or vector level. For example
a file in a standard SVF (Serial Vector Format) that contains
boundary scan vectors, can be used by sending each vector
to the JTAG interface and the JTAG controller will execute
the programming.

Initial version provides the system calls set for:
- SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
  number of clocks.

SoC which are not equipped with JTAG master interface, can be built
on top of JTAG core driver infrastructure, by applying bit-banging of
TDI, TDO, TCK and TMS pins within the hardware specific driver.

Oleksandr Shamray (4):
  drivers: jtag: Add JTAG core driver
  drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master
driver
  Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx
families JTAG master driver
  Documentation: jtag: Add ABI documentation

 Documentation/ABI/testing/jatg-cdev|   27 +
 .../devicetree/bindings/jtag/aspeed-jtag.txt   |   18 +
 Documentation/ioctl/ioctl-number.txt   |2 +
 MAINTAINERS|   10 +
 drivers/Kconfig|2 +
 drivers/Makefile   |1 +
 drivers/jtag/Kconfig   |   29 +
 drivers/jtag/Makefile  |2 +
 drivers/jtag/jtag-aspeed.c |  771 
 drivers/jtag/jtag.c|  298 
 include/linux/jtag.h   |   48 ++
 include/uapi/linux/jtag.h  |  115 +++
 12 files changed, 1323 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/jatg-cdev
 create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
 create mode 100644 drivers/jtag/Kconfig
 create mode 100644 drivers/jtag/Makefile
 create mode 100644 drivers/jtag/jtag-aspeed.c
 create mode 100644 drivers/jtag/jtag.c
 create mode 100644 include/linux/jtag.h
 create mode 100644 include/uapi/linux/jtag.h

[patch v9 1/4] drivers: jtag: Add JTAG core driver

[Oleksandr Shamray]

Initial patch for JTAG driver
JTAG class driver provide infrastructure to support hardware/software
JTAG platform drivers. It provide user layer API interface for flashing
and debugging external devices which equipped with JTAG interface
using standard transactions.

Driver exposes set of IOCTL to user space for:
- XFER:
- SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
  number of clocks).
- SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency.

Driver core provides set of internal APIs for allocation and
registration:
- jtag_register;
- jtag_unregister;
- jtag_alloc;
- jtag_free;

Platform driver on registration with jtag-core creates the next
entry in dev folder:
/dev/jtagX

Signed-off-by: Oleksandr Shamray 
Signed-off-by: Jiri Pirko 
---
V8->v9
Comments pointed by Arnd Bergmann 
- use get_user() instead of __get_user().
- change jtag->open type from int to atomic_t
- remove spinlock on jtg_open
- remove mutex on jtag_register
- add unregister_chrdev_region on jtag_init err
- add unregister_chrdev_region on jtag_exit
- remove unnecessary pointer casts
- add *data parameter to xfer function prototype

v7->v8
Comments pointed by Moritz Fischer 
- Fix misspelling s/friver/driver

v6->v7
Notifications from kbuild test robot 
- Remove include asm/types.h from jtag.h
- Add include  to jtag.c

v5->v6
v4->v5

v3->v4
Comments pointed by Arnd Bergmann 
- change transaction pointer tdio type  to __u64
- change internal status type from enum to __u32
- reorder jtag_xfer members to avoid the implied padding
- add __packed attribute to jtag_xfer and jtag_run_test_idle

v2->v3
Notifications from kbuild test robot 
- Change include path to  in jtag.h

v1->v2
Comments pointed by Greg KH 
- Change license type from GPLv2/BSD to GPLv2
- Change type of variables which crossed user/kernel to __type
- Remove "default n" from Kconfig

Comments pointed by Andrew Lunn 
- Change list_add_tail in jtag_unregister to list_del

Comments pointed by Neil Armstrong 
- Add SPDX-License-Identifier instead of license text

Comments pointed by Arnd Bergmann 
- Change __copy_to_user to memdup_user
- Change __put_user to put_user
- Change type of variables to __type for compatible 32 and 64-bit systems
- Add check for maximum xfer data size
- Change lookup data mechanism to get jtag data from inode
- Add .compat_ioctl to file ops
- Add mem alignment for jtag priv data

Comments pointed by Tobias Klauser 
- Change function names to avoid match with variable types
- Fix description for jtag_ru_test_idle in uapi jtag.h
- Fix misprints IDEL/IDLE, trough/through
---
 Documentation/ioctl/ioctl-number.txt |2 +
 MAINTAINERS  |8 +
 drivers/Kconfig  |2 +
 drivers/Makefile |1 +
 drivers/jtag/Kconfig |   16 ++
 drivers/jtag/Makefile|1 +
 drivers/jtag/jtag.c  |  298 ++
 include/linux/jtag.h |   48 ++
 include/uapi/linux/jtag.h|  115 +
 9 files changed, 491 insertions(+), 0 deletions(-)
 create mode 100644 drivers/jtag/Kconfig
 create mode 100644 drivers/jtag/Makefile
 create mode 100644 drivers/jtag/jtag.c
 create mode 100644 include/linux/jtag.h
 create mode 100644 include/uapi/linux/jtag.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 3e3fdae..1af2508 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -321,6 +321,8 @@ Code  Seq#(hex) Include FileComments
 0xB0   all RATIO devices   in development:

 0xB1   00-1F   PPPoX   
+0xB2   00-0f   linux/jtag.hJTAG driver
+   
 0xB3   00  linux/mmc/ioctl.h
 0xB4   00-0F   linux/gpio.h
 0xB5   00-0F   uapi/linux/rpmsg.h  

diff --git a/MAINTAINERS b/MAINTAINERS
index 205d397..141aeaf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7292,6 +7292,14 @@ L:   linux-ser...@vger.kernel.org
 S: Maintained
 F: drivers/tty/serial/jsm/
 
+JTAG SUBSYSTEM
+M: Oleksandr Shamray 
+M: Vadim Pasternak 
+S: Maintained
+F: include/linux/jtag.h
+F: include/uapi/linux/jtag.h
+F: drivers/jtag/
+
 K10TEMP HARDWARE MONITORING DRIVER
 M: Clemens Ladisch 
 L: linux-hw...@vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 505c676..2214678 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -208,4 +208,6 @@ source "drivers/tee/Kconfig"
 
 source "drivers/mux/Kconfig"
 
+source "drivers/jtag/Kconfig"
+
 endmenu
diff 

[patch v9 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

[Oleksandr Shamray]

Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.

Driver implements the following jtag ops:
- freq_get;
- freq_set;
- status_get;
- idle;
- xfer;

It has been tested on Mellanox system with BMC equipped with
Aspeed 2520 SoC for programming CPLD devices.

Signed-off-by: Oleksandr Shamray 
Signed-off-by: Jiri Pirko 
Acked-by: Arnd Bergmann 
---
V8->v9
Comments pointed by Arnd Bergmann 
- add *data parameter to xfer function prototype

v7->v8
Comments pointed by Joel Stanley 
- aspeed_jtag_init replace goto to return;
- change input variables type from __u32 to u32
  in functios freq_get, freq_set, status_get
- change sm_ variables type from char to u8
- in jatg_init add disable clocks on error case
- remove release_mem_region on error case
- remove devm_free_irq on jtag_deinit
- Fix misspelling Disabe/Disable
- Change compatible string to ast2400 and ast2000

v6->v7
Notifications from kbuild test robot 
- Add include  to jtag-asapeed.c

v5->v6
v4->v5
Comments pointed by Arnd Bergmann 
- Added HAS_IOMEM dependence in Kconfig to avoid
  "undefined reference to `devm_ioremap_resource'" error,
  because in some arch this not supported

v3->v4
Comments pointed by Arnd Bergmann 
- change transaction pointer tdio type  to __u64
- change internal status type from enum to __u32

v2->v3

v1->v2
Comments pointed by Greg KH 
- change license type from GPLv2/BSD to GPLv2

Comments pointed by Neil Armstrong 
- Add clk_prepare_enable/clk_disable_unprepare in clock init/deinit
- Change .compatible to soc-specific compatible names
  aspeed,aspeed4000-jtag/aspeed5000-jtag
- Added dt-bindings

Comments pointed by Arnd Bergmann 
- Reorder functions and removed the forward declarations
- Add static const qualifier to state machine states transitions
- Change .compatible to soc-specific compatible names
  aspeed,aspeed4000-jtag/aspeed5000-jtag
- Add dt-bindings

Comments pointed by Randy Dunlap 
- Change module name jtag-aspeed in description in Kconfig

Comments pointed by kbuild test robot 
- Remove invalid include 
- add resource_size instead of calculation
---
 drivers/jtag/Kconfig   |   13 +
 drivers/jtag/Makefile  |1 +
 drivers/jtag/jtag-aspeed.c |  771 
 3 files changed, 785 insertions(+), 0 deletions(-)
 create mode 100644 drivers/jtag/jtag-aspeed.c

diff --git a/drivers/jtag/Kconfig b/drivers/jtag/Kconfig
index 0fad1a3..098beb0 100644
--- a/drivers/jtag/Kconfig
+++ b/drivers/jtag/Kconfig
@@ -14,3 +14,16 @@ menuconfig JTAG
 
  To compile this driver as a module, choose M here: the module will
  be called jtag.
+
+menuconfig JTAG_ASPEED
+   tristate "Aspeed SoC JTAG controller support"
+   depends on JTAG && HAS_IOMEM
+   ---help---
+ This provides a support for Aspeed JTAG device, equipped on
+ Aspeed SoC 24xx and 25xx families. Drivers allows programming
+ of hardware devices, connected to SoC through the JTAG interface.
+
+ If you want this support, you should say Y here.
+
+ To compile this driver as a module, choose M here: the module will
+ be called jtag-aspeed.
diff --git a/drivers/jtag/Makefile b/drivers/jtag/Makefile
index af37493..04a855e 100644
--- a/drivers/jtag/Makefile
+++ b/drivers/jtag/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_JTAG) += jtag.o
+obj-$(CONFIG_JTAG_ASPEED)  += jtag-aspeed.o
diff --git a/drivers/jtag/jtag-aspeed.c b/drivers/jtag/jtag-aspeed.c
new file mode 100644
index 000..a8dd4f9
--- /dev/null
+++ b/drivers/jtag/jtag-aspeed.c
@@ -0,0 +1,771 @@
+/*
+ * drivers/jtag/jtag.c
+ *
+ * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2017 Oleksandr Shamray 
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ASPEED_JTAG_DATA   0x00
+#define ASPEED_JTAG_INST   0x04
+#define ASPEED_JTAG_CTRL   0x08
+#define ASPEED_JTAG_ISR0x0C
+#define ASPEED_JTAG_SW 0x10
+#define ASPEED_JTAG_TCK0x14
+#define ASPEED_JTAG_EC 0x18
+
+#define ASPEED_JTAG_DATA_MSB   0x01
+#define ASPEED_JTAG_DATA_CHUNK_SIZE0x20
+
+/* ASPEED_JTAG_CTRL: Engine Control */
+#define ASPEED_JTAG_CTL_ENG_EN BIT(31)
+#define ASPEED_JTAG_CTL_ENG_OUT_EN BIT(30)
+#define ASPEED_JTAG_CTL_FORCE_TMS  BIT(29)
+#define ASPEED_JTAG_CTL_INST_LEN(x)((x) << 20)
+#define ASPEED_JTAG_CTL_LASPEED_INST   BIT(17)
+#define ASPEED_JTAG_CTL_INST_ENBIT(16)
+#define ASPEED_JTAG_CTL_DR_UPDATE  BIT(10)
+#define ASPEED_JTAG_CTL_DATA_LEN(x)((x) << 4)
+#define ASPEED_JTAG_CTL_LASPEED_DATA   BIT(1)
+#define ASPEED_JTAG_CTL_DATA_ENBIT(0)
+
+/* ASPEED_JTAG_ISR : Interrupt status and enable */
+#define ASPEED_JTAG_ISR_INST_PAUSE   

[patch v9 3/4] Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver

[Oleksandr Shamray]

It has been tested on Mellanox system with BMC equipped with
Aspeed 2520 SoC for programming CPLD devices.

Signed-off-by: Oleksandr Shamray 
Signed-off-by: Jiri Pirko 
Acked-by: Rob Herring 
---
v8->v9
v7->v8
Comments pointed by pointed by Joel Stanley 
- Change compatible string to ast2400 and ast2000

V6->v7
Comments pointed by Tobias Klauser 
 - Fix spell "Doccumentation" -> "Documentation"

v5->v6
Comments pointed by Tobias Klauser 
- Small nit: s/documentation/Documentation/

v4->v5

V3->v4
Comments pointed by Rob Herring 
- delete unnecessary "status" and "reg-shift" descriptions in
  bndings file

v2->v3
Comments pointed by Rob Herring 
- split Aspeed jtag driver and binding to sepatrate patches
- delete unnecessary "status" and "reg-shift" descriptions in
  bndings file
---
 .../devicetree/bindings/jtag/aspeed-jtag.txt   |   18 ++
 MAINTAINERS|1 +
 2 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt

diff --git a/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt 
b/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
new file mode 100644
index 000..8cfc610
--- /dev/null
+++ b/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
@@ -0,0 +1,18 @@
+Aspeed JTAG driver for ast2400 and ast2500 SoC
+
+Required properties:
+- compatible:  Should be one of
+  - "aspeed,ast2400-jtag"
+  - "aspeed,ast2500-jtag"
+- reg  contains the offset and length of the JTAG memory
+   region
+- clocks   root clock of bus, should reference the APB clock
+- interrupts   should contain JTAG controller interrupt
+
+Example:
+jtag: jtag@1e6e4000 {
+   compatible = "aspeed,ast2500-jtag";
+   reg = <0x1e6e4000 0x1c>;
+   clocks = <&clk_apb>;
+   interrupts = <43>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 141aeaf..bfdfa94 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7299,6 +7299,7 @@ S:Maintained
 F: include/linux/jtag.h
 F: include/uapi/linux/jtag.h
 F: drivers/jtag/
+F: Documentation/devicetree/bindings/jtag/
 
 K10TEMP HARDWARE MONITORING DRIVER
 M: Clemens Ladisch 
-- 
1.7.1

[patch v9 4/4] Documentation: jtag: Add ABI documentation

[Oleksandr Shamray]

Added document that describe the ABI for JTAG class drivrer

Signed-off-by: Oleksandr Shamray 
---
v8->v9
v7->v8
v6->v7
Comments pointed by Pavel Machek 
- Added jtag-cdev documentation to Documentation/ABI/testing folder
---
 Documentation/ABI/testing/jatg-cdev |   27 +++
 MAINTAINERS |1 +
 2 files changed, 28 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/jatg-cdev

diff --git a/Documentation/ABI/testing/jatg-cdev 
b/Documentation/ABI/testing/jatg-cdev
new file mode 100644
index 000..14a3610
--- /dev/null
+++ b/Documentation/ABI/testing/jatg-cdev
@@ -0,0 +1,27 @@
+What:  /dev/jtag[0-9]+
+Date:  September 2017
+KernelVersion: 4.14
+Contact:   oleksan...@mellanox.com
+Description:
+   The character device files /dev/jtag* are the interface
+   between JTAG master interfase and userspace.
+
+   The ioctl(2)-based ABI is defined and documented in
+   [include/uapi].
+
+   The following file operations are supported:
+
+   open(2)
+   The argument flag currently support only one access
+   mode O_RDWR.
+
+   ioctl(2)
+   Initiate various actions.
+   See the inline documentation in [include/uapi]
+   for descriptions of all ioctls.
+
+   close(2)
+   Stops and free up the I/O contexts that was associated
+   with the file descriptor.
+
+Users: TBD
\ No newline at end of file
diff --git a/MAINTAINERS b/MAINTAINERS
index bfdfa94..dfcf49c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7300,6 +7300,7 @@ F:include/linux/jtag.h
 F: include/uapi/linux/jtag.h
 F: drivers/jtag/
 F: Documentation/devicetree/bindings/jtag/
+F: Documentation/ABI/testing/jtag-cdev
 
 K10TEMP HARDWARE MONITORING DRIVER
 M: Clemens Ladisch 
-- 
1.7.1

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

[Johannes Stezenbach]

On Thu, Sep 21, 2017 at 02:39:30AM +0200, Rafael J. Wysocki wrote:
> On Wed, Sep 20, 2017 at 6:27 PM, Johannes Stezenbach  wrote:
> >
> >  E.g. an audio codec could keep running
> > while the i2c bus used to program its registers can be runtime suspended.
> > If this is correct I think it would be useful to spell it out explicitly
> > in the documentation.
> 
> That's because the i2c bus uses the ignore_children flag that allows
> it to override the general rules. :-)

Ah!  I was looking at Documentation/driver-api/pm only (which is
changed by your patch), but this is documented in Documentation/power
(and obviously I hadn't checked the code, shame on me).

> direct_complete has nothing to do with this.

Oh?  Reading again, do I get this right:

1. simple method: always call pm_runtime_resume() in ->suspend(),
   then suspend the driver again
2. optimization: if pm_runtime_suspended(), the driver's ->suspend()
   can possibly do nothing if conditions permit, otherwise it calls
   pm_runtime_resume() and then suspends
3. optimization: tell pm core to skip ->suspend() via return value
   from ->prepare() which sets direct_complete

...and your patch only deals with 1 and 2.

Sorry to hijack your thread for side discussion, it was
inadvertant due to my lack of understanding.


> First off, the PM core does check the direct_complete flag in
> __device_suspend() and does more-or-less what you are saying.
> 
> However, that flag is initialized in device_prepare() with the help of
> the ->suspend() return value, because whether or not it makes sense to

you mean ->prepare(), right?

> set that flag depends on some conditions that may change between
> consecutive system suspend-resume cycles in general and need to be
> checked in advance before setting it.
> 
> HTH

It does, however the question remains *why* it needs to check
it in ->prepare() and not right before calling ->suspend().
Using ->prepare() for the purpose seems wrong since it traverses
the hierarchy in the "wrong" order.  Only right before
calling ->suspend() the driver knows if its current state
allows it to skip any further actions for suspend, because
suspending children or other users may cause pm_runtime_resume()
for it.  (In the back of my head I have the scenario of
bug #196861, some completely different driver uses
i2c via ACPI OpRegion during its suspend.)


Thanks,
Johannes

Re: [PATCH v3 10/31] befs: Define usercopy region in befs_inode_cache slab cache

[Luis de Bethencourt]

On 09/20/2017 09:45 PM, Kees Cook wrote:

From: David Windsor 

befs symlink pathnames, stored in struct befs_inode_info.i_data.symlink
and therefore contained in the befs_inode_cache slab cache, need to be
copied to/from userspace.

cache object allocation:
 fs/befs/linuxvfs.c:
 befs_alloc_inode(...):
 ...
 bi = kmem_cache_alloc(befs_inode_cachep, GFP_KERNEL);
 ...
 return &bi->vfs_inode;

 befs_iget(...):
 ...
 strlcpy(befs_ino->i_data.symlink, raw_inode->data.symlink,
 BEFS_SYMLINK_LEN);
 ...
 inode->i_link = befs_ino->i_data.symlink;

example usage trace:
 readlink_copy+0x43/0x70
 vfs_readlink+0x62/0x110
 SyS_readlinkat+0x100/0x130

 fs/namei.c:
 readlink_copy(..., link):
 ...
 copy_to_user(..., link, len);

 (inlined in vfs_readlink)
 generic_readlink(dentry, ...):
 struct inode *inode = d_inode(dentry);
 const char *link = inode->i_link;
 ...
 readlink_copy(..., link);

In support of usercopy hardening, this patch defines a region in the
befs_inode_cache slab cache in which userspace copy operations are
allowed.

This region is known as the slab cache's usercopy region. Slab caches can
now check that each copy operation involving cache-managed memory falls
entirely within the slab's usercopy region.

This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
whitelisting code in the last public patch of grsecurity/PaX based on my
understanding of the code. Changes or omissions from the original code are
mine and don't reflect the original grsecurity/PaX code.

Signed-off-by: David Windsor 
[kees: adjust commit log, provide usage trace]
Cc: Luis de Bethencourt 
Cc: Salah Triki 
Signed-off-by: Kees Cook 
Acked-by: Luis de Bethencourt 
---
  fs/befs/linuxvfs.c | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
index a92355cc453b..e5dcd26003dc 100644
--- a/fs/befs/linuxvfs.c
+++ b/fs/befs/linuxvfs.c
@@ -444,11 +444,15 @@ static struct inode *befs_iget(struct super_block *sb, 
unsigned long ino)
  static int __init
  befs_init_inodecache(void)
  {
-   befs_inode_cachep = kmem_cache_create("befs_inode_cache",
- sizeof (struct befs_inode_info),
- 0, (SLAB_RECLAIM_ACCOUNT|
-   SLAB_MEM_SPREAD|SLAB_ACCOUNT),
- init_once);
+   befs_inode_cachep = kmem_cache_create_usercopy("befs_inode_cache",
+   sizeof(struct befs_inode_info), 0,
+   (SLAB_RECLAIM_ACCOUNT|SLAB_MEM_SPREAD|
+   SLAB_ACCOUNT),
+   offsetof(struct befs_inode_info,
+   i_data.symlink),
+   sizeof_field(struct befs_inode_info,
+   i_data.symlink),
+   init_once);
if (befs_inode_cachep == NULL)
return -ENOMEM;
  



No changes in the befs patch in v3. It goes without saying I continue to 
Ack this.


Thanks Kees and David,
Luis

[PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

[Christophe Leroy]

On powerpc, RODATA_TEST fails with message the following messages:

[6.199505] Freeing unused kernel memory: 528K
[6.203935] rodata_test: test data was not read only

This is because GCC allocates it to .data section:

c0695034 g O .data  0004 rodata_test_data

Since commit 056b9d8a76924 ("mm: remove rodata_test_data export,
add pr_fmt"), rodata_test_data is used only inside rodata_test.c
By declaring it static, it gets properly allocated into .rodata
section instead of .data:

c04df710 l O .rodata0004 rodata_test_data

Signed-off-by: Christophe Leroy 
---
 mm/rodata_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/rodata_test.c b/mm/rodata_test.c
index 6bb4deb12e78..d908c8769b48 100644
--- a/mm/rodata_test.c
+++ b/mm/rodata_test.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 
-const int rodata_test_data = 0xC3;
+static const int rodata_test_data = 0xC3;
 
 void rodata_test(void)
 {
-- 
2.13.3

Re: [RFC][PATCH v2 6/7] symbol lookup: use new kernel and module dereference functions

[Sergey Senozhatsky]

On (09/21/17 01:29), Sergey Senozhatsky wrote:
[..]
> + %pS versatile_init+0x0/0x110
> + %ps versatile_init
>   %pF versatile_init+0x0/0x110
>   %pf versatile_init
> - %pS versatile_init+0x0/0x110
>   %pSRversatile_init+0x9/0x110
>   (with __builtin_extract_return_addr() translation)
> - %ps versatile_init
>   %pB prev_fn_of_versatile_init+0x88/0x88
>  
> -The ``F`` and ``f`` specifiers are for printing function pointers,
> -for example, f->func, &gettimeofday. They have the same result as
> -``S`` and ``s`` specifiers. But they do an extra conversion on
> -ia64, ppc64 and parisc64 architectures where the function pointers
> -are actually function descriptors.
> -
>  The ``S`` and ``s`` specifiers can be used for printing symbols
>  from direct addresses, for example, __builtin_return_address(0),
>  (void *)regs->ip. They result in the symbol name with (``S``) or
>  without (``s``) offsets. If KALLSYMS are disabled then the symbol
>  address is printed instead.
>  
> +Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
> +and thus deprecated.

JFI,

I have updated this part. it's probably too early to completely
wipe out pF/pf info.

the updated Doc goes like this:

+Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
+and thus deprecated. We have ``F`` and ``f`` because on ia64, ppc64 and
+parisc64 function pointers are indirect and, in fact, are function
+descriptors, which require additional dereferencing before we can lookup
+the symbol. As of now, ``S`` and ``s`` perform dereferencing on those
+platforms (when needed), so ``F`` and ``f`` exist for compatibility
+reasons only.

-ss

Re: [RESEND RFC PATCH 0/7] sun8i H3 HDMI glue driver for DW HDMI

[Jose Abreu]

Hi Jernej,

On 20-09-2017 21:01, Jernej Skrabec wrote:
> [added media mailing list due to CEC question]
>
> This patch series adds a HDMI glue driver for Allwinner H3 SoC. For now, only
> video and CEC functionality is supported. Audio needs more tweaks.
>
> Series is based on the H3 DE2 patch series available on mailing list:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_linux-2Darm-2Dkernel_2017-2DAugust_522697.html&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=coyfcQKSr2asrHcaCeWFmAP_9nkFkRK8s7Uw5bmVei4&s=JCFaMXK1MmZ3jE745_YcqZhZkaqtc6UapGfSSapcz_s&e=
>  
> (ignore patches marked with [NOT FOR REVIEW NOW] tag)
>
> Patch 1 adds support for polling plug detection since custom PHY used here
> doesn't support HPD interrupt.
>
> Patch 2 enables overflow workaround for v1.32a. This HDMI controller exhibits
> same issues as HDMI controller used in iMX6 SoCs.
>
> Patch 3 adds CLK_SET_RATE_PARENT to hdmi clock.
>
> Patch 4 adds dt bindings documentation.
>
> Patch 5 adds actual H3 HDMI glue driver.
>
> Patch 6 and 7 add HDMI node to DT and enable it where needed.
>
> Allwinner used DW HDMI controller in a non standard way:
> - register offsets obfuscation layer, which can fortunately be turned off
> - register read lock, which has to be disabled by magic number
> - custom PHY, which have to be initialized before DW HDMI controller
> - non standard clocks
> - no HPD interrupt
>
> Because of that, I have two questions:
> - Since HPD have to be polled, is it enough just to enable poll mode? I'm
>   mainly concerned about invalidating CEC address here.

You mean you get no interrupt when HPD status changes? Hans can
answer this better but then you will need to invalidate the cec
physical address yourself because right now its invalidated in
the dw-hdmi irq handler (see dw_hdmi_irq()).

> - PHY has to be initialized before DW HDMI controller to disable offset
>   obfuscation and read lock among other things. This means that all clocks 
> have
>   to be enabled in glue driver. This poses a problem, since when using
>   component model, dw-hdmi bridge uses drvdata for it's own private data and
>   prevents glue layer to pass a pointer to unbind function, where clocks 
> should
>   be disabled. I noticed same issue in meson DW HDMI glue driver, where clocks
>   are also not disabled when unbind callback is called. I noticed that when H3
>   SoC is shutdown, HDMI output is still enabled and lastest image is shown on
>   monitor until it is unplugged from power supply. Is there any simple 
> solution
>   to this?

I don't know if you can use an empty platform device created with
platform_device_alloc(). Perhaps it would be better fix this in
the dw-hdmi driver. I see two solutions:

- Either you return the dw-hdmi private structure in the bind
callback, store it and pass it in the unbind
- Or, you pass your own private data to the dw-hdmi bind, the
dw-hdmi stores it and you just create a public function in the
dw-hdmi driver called like dw_hdmi_get_auxdata(struct device
*dev) which returns your private data.

I think first option is nice, maybe anyone else can suggest
something better?

Best regards,
Jose Miguel Abreu

>
> Chen-Yu,
> TL Lim was unable to obtain any answer from Allwinner about HDMI clocks. I 
> think
> it is safe to assume that divider in HDMI clock doesn't have any effect.
>
> Branch based on linux-next from 1. September with integrated patches is
> available here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jernejsk_linux-2D1_tree_h3-5Fhdmi-5Frfc&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=coyfcQKSr2asrHcaCeWFmAP_9nkFkRK8s7Uw5bmVei4&s=lDAnd3egsc2sxqVM-Ya_Me9ozWXKWvxxvsdV3Jn3vpA&e=
>  
>
> Some additonal info about H3 HDMI:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__linux-2Dsunxi.org_DWC-5FHDMI-5FController&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=coyfcQKSr2asrHcaCeWFmAP_9nkFkRK8s7Uw5bmVei4&s=d9iEgk23RCLJL4oXJ4kkt6NyYK90_vFy0mCD3WauJDk&e=
>  
>
> Thanks to Jens Kuske, who figured out that it is actually DW HDMI controller
> and mapped scrambled register offsets to original ones.
>
> Icenowy Zheng (1):
>   ARM: sun8i: h3: Add DesignWare HDMI controller node
>
> Jernej Skrabec (6):
>   drm: bridge: Enable polling hpd event in dw_hdmi
>   drm: bridge: Enable workaround in dw_hdmi for v1.32a
>   clk: sunxi: Add CLK_SET_RATE_PARENT flag for H3 HDMI clock
>   dt-bindings: Document Allwinner DWC HDMI TX node
>   drm: sun4i: Add a glue for the DesignWare HDMI controller in H3
>   ARM: sun8i: h3: Enable HDMI output on H3 boards
>
>  .../bindings/display/sunxi/sun4i-drm.txt   | 158 ++-
>  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  33 ++
>  arch/arm/boot/dts/sun8i-h3-beelink-x2.dts  |  33 ++
>  arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts   |  33 ++
>  arch/arm/boot/dts/sun8i-h3-orangepi-2.

[PATCH net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging

[Egil Hjelmeland]

Prepare for next patch:
Move tag setup from lan9303_separate_ports() to new function
lan9303_setup_tagging()

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 42 +-
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 07355db2ad81..bba875e114e7 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -157,6 +157,7 @@
 # define LAN9303_SWE_PORT_MIRROR_ENABLE_RX_MIRRORING BIT(1)
 # define LAN9303_SWE_PORT_MIRROR_ENABLE_TX_MIRRORING BIT(0)
 #define LAN9303_SWE_INGRESS_PORT_TYPE 0x1847
+#define  LAN9303_SWE_INGRESS_PORT_TYPE_VLAN 3
 #define LAN9303_BM_CFG 0x1c00
 #define LAN9303_BM_EGRSS_PORT_TYPE 0x1c0c
 # define LAN9303_BM_EGRSS_PORT_TYPE_SPECIAL_TAG_PORT2 (BIT(17) | BIT(16))
@@ -510,11 +511,30 @@ static int lan9303_enable_processing_port(struct lan9303 
*chip,
LAN9303_MAC_TX_CFG_X_TX_ENABLE);
 }
 
+/* forward special tagged packets from port 0 to port 1 *or* port 2 */
+static int lan9303_setup_tagging(struct lan9303 *chip)
+{
+   int ret;
+   /* enable defining the destination port via special VLAN tagging
+* for port 0
+*/
+   ret = lan9303_write_switch_reg(chip, LAN9303_SWE_INGRESS_PORT_TYPE,
+  LAN9303_SWE_INGRESS_PORT_TYPE_VLAN);
+   if (ret)
+   return ret;
+
+   /* tag incoming packets at port 1 and 2 on their way to port 0 to be
+* able to discover their source port
+*/
+   return lan9303_write_switch_reg(
+   chip, LAN9303_BM_EGRSS_PORT_TYPE,
+   LAN9303_BM_EGRSS_PORT_TYPE_SPECIAL_TAG_PORT0);
+}
+
 /* We want a special working switch:
  * - do not forward packets between port 1 and 2
  * - forward everything from port 1 to port 0
  * - forward everything from port 2 to port 0
- * - forward special tagged packets from port 0 to port 1 *or* port 2
  */
 static int lan9303_separate_ports(struct lan9303 *chip)
 {
@@ -529,22 +549,6 @@ static int lan9303_separate_ports(struct lan9303 *chip)
if (ret)
return ret;
 
-   /* enable defining the destination port via special VLAN tagging
-* for port 0
-*/
-   ret = lan9303_write_switch_reg(chip, LAN9303_SWE_INGRESS_PORT_TYPE,
-  0x03);
-   if (ret)
-   return ret;
-
-   /* tag incoming packets at port 1 and 2 on their way to port 0 to be
-* able to discover their source port
-*/
-   ret = lan9303_write_switch_reg(chip, LAN9303_BM_EGRSS_PORT_TYPE,
-   LAN9303_BM_EGRSS_PORT_TYPE_SPECIAL_TAG_PORT0);
-   if (ret)
-   return ret;
-
/* prevent port 1 and 2 from forwarding packets by their own */
return lan9303_write_switch_reg(chip, LAN9303_SWE_PORT_STATE,
LAN9303_SWE_PORT_STATE_FORWARDING_PORT0 |
@@ -644,6 +648,10 @@ static int lan9303_setup(struct dsa_switch *ds)
return -EINVAL;
}
 
+   ret = lan9303_setup_tagging(chip);
+   if (ret)
+   dev_err(chip->dev, "failed to setup port tagging %d\n", ret);
+
ret = lan9303_separate_ports(chip);
if (ret)
dev_err(chip->dev, "failed to separate ports %d\n", ret);
-- 
2.11.0

[PATCH net-next 0/2] lan9303: Add basic offloading of unicast traffic

[Egil Hjelmeland]

This series add basic offloading of unicast traffic to the lan9303
DSA driver.

Comments welcome!

Egil Hjelmeland (2):
  net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging
  net: dsa: lan9303: Add basic offloading of unicast traffic

 drivers/net/dsa/lan9303-core.c | 130 +++--
 drivers/net/dsa/lan9303.h  |   1 +
 2 files changed, 114 insertions(+), 17 deletions(-)

-- 
2.11.0

Re: [PATCH V5 0/4] Add Broadcom STB USB phy driver

[Kishon Vijay Abraham I]

Hi Florian,

On Thursday 21 September 2017 04:07 AM, Florian Fainelli wrote:
> Hi Kishon,
> 
> On 09/15/2017 04:49 PM, Florian Fainelli wrote:
>> On September 4, 2017 11:11:47 PM PDT, Kishon Vijay Abraham I  
>> wrote:
>>> Florian,
>>>
>>> On Saturday 02 September 2017 07:46 AM, Florian Fainelli wrote:


 On 08/25/2017 10:51 AM, Al Cooper wrote:
> Add a new USB Phy driver for Broadcom STB SoCs. This driver
> supports Broadcom STB ARM SoCs. This driver in
> combination with the Broadcom STB ohci, ehci and xhci
> drivers will enable USB1.1, USB2.0 and USB3.0 support.
> This Phy driver also supports the Broadcom BDC gadget
> driver.

 Thanks Al! Kishon, feel free to merge everything through your tree
>>> there
 should not be any conflicts with drivers/soc/bcm/brcmstb/common.c and
 include/linux/soc/brcmstb/brcmstb.h.
>>>
>>> I'll start merging once 4.14 -rc1 is tagged.
>>
>> OK, does not that mean we will be missing this driver in 4.14? I suppose 
>> that's fine. Thanks!
> 
> Gentle ping, v4.14-rc1 is now out, can you let us know if this patch
> series is good with you? Thanks!

Thank you for reminding. Actually the patch series has quite a few "CHECK"
checkpatch warnings. Can that be fixed before merging it?

Thanks
Kishon

Re: MADV_FREE is broken

[Artem Savkov]

On Wed, Sep 20, 2017 at 03:37:33PM -0700, Shaohua Li wrote:
> On Wed, Sep 20, 2017 at 11:01:47AM +0200, Artem Savkov wrote:
> > Hi All,
> > 
> > We recently started noticing madvise09[1] test from ltp failing strangely. 
> > The
> > test does the following: maps 32 pages, sets MADV_FREE for the range it got,
> > dirties 2 of the pages, creates memory pressure and check that nondirty 
> > pages
> > are free. The test hanged while accessing the last 4 pages(29-32) of 
> > madvised
> > range at line 121 [2]. Any other process (gdb/cat) accessing those pages
> > would also hang as would rebooting the machine. It doesn't trigger any debug
> > warnings or kasan.
> > 
> > The issue bisected to "802a3a92ad7a mm: reclaim MADV_FREE pages" (so 4.12 
> > and
> > up are affected).
> > 
> > I did some poking around and found out that the "bad" pages had SwapBacked 
> > flag
> > set in shrink_page_list() which confused it a lot. It looks like
> > mark_page_lazyfree() only calls lru_lazyfree_fn() when the pagevec is full
> > (that is in batches of 14) and never drains the rest (so last four in 
> > madvise09
> > case).
> > 
> > The patch below greatly reduces the failure rate, but doesn't fix it
> > completely, it still shows up with the same symptoms (hanging trying to 
> > access
> > last 4 pages) after a bunch of retries.
> > 
> > [1] 
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise09.c
> > [2] 
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise09.c#L121
> > 
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 21261ff0466f..a0b868e8b7d2 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -453,6 +453,7 @@ static void madvise_free_page_range(struct mmu_gather 
> > *tlb,
> >  
> > tlb_start_vma(tlb, vma);
> > walk_page_range(addr, end, &free_walk);
> > +   lru_add_drain();
> > tlb_end_vma(tlb, vma);
> >  }
> 
> Looks there is a race between clear pte dirty bit and clear SwapBacked bit.
> draining the vect helps a little, but not sufficient. If SwapBacked is set, we
> could add the page to swapcache, but since we the page isn't dirty, we don't
> write the page out. This could cause data corruption. There is another place 
> we
> wrongly clear SwapBacked bit. Below is a test patch which seems to fix the
> issue, please give a try.

Ran it for quite some time and it does seem to fix the issue.

> diff --git a/mm/swap.c b/mm/swap.c
> index 62d96b8..5c58257 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -575,7 +575,7 @@ static void lru_lazyfree_fn(struct page *page, struct 
> lruvec *lruvec,
>   void *arg)
>  {
>   if (PageLRU(page) && PageAnon(page) && PageSwapBacked(page) &&
> - !PageUnevictable(page)) {
> + !PageSwapCache(page) && !PageUnevictable(page)) {
>   bool active = PageActive(page);
>  
>   del_page_from_lru_list(page, lruvec,

Shouldn't the same check be added to mark_page_lazyfree()?

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 13d711d..be1c98e 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -980,6 +980,7 @@ static unsigned long shrink_page_list(struct list_head 
> *page_list,
>   int may_enter_fs;
>   enum page_references references = PAGEREF_RECLAIM_CLEAN;
>   bool dirty, writeback;
> + bool new_added_swapcache = false;
>  
>   cond_resched();
>  
> @@ -1165,6 +1166,7 @@ static unsigned long shrink_page_list(struct list_head 
> *page_list,
>  
>   /* Adding to swap updated mapping */
>   mapping = page_mapping(page);
> + new_added_swapcache = true;
>   }
>   } else if (unlikely(PageTransHuge(page))) {
>   /* Split file THP */
> @@ -1185,6 +1187,10 @@ static unsigned long shrink_page_list(struct list_head 
> *page_list,
>   nr_unmap_fail++;
>   goto activate_locked;
>   }
> + /* race with MADV_FREE */
> + if (PageAnon(page) && !PageDirty(page) &&
> + PageSwapBacked(page) && new_added_swapcache)
> + set_page_dirty(page);
>   }
>  
>   if (PageDirty(page)) {

-- 
Regards,
  Artem

Re: [RESEND PATCH v5 10/16] ARM: dts: zynq: Add generic compatible string for I2C EEPROM

[Javier Martinez Canillas]

Hello Michal,

On Thu, Aug 24, 2017 at 3:44 PM, Michal Simek  wrote:

[snip]

>
> Ok. Applied to
> https://github.com/Xilinx/linux-xlnx/commits/zynq/dt
>
> Will wait if something else pop up.
>

I see the patch applied to that repository but I don't see it in
neither mainline nor linux-next.

> Arnd: If you want to take this directly, feel free to do it.
>
> Thanks,
> Michal

Best regards,
Javier

[PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of unicast traffic

[Egil Hjelmeland]

When both user ports are joined to the same bridge, the normal
HW MAC learning is enabled. This means that unicast traffic is forwarded
in HW.

If one of the user ports leave the bridge,
the ports goes back to the initial separated operation.

Port separation relies on disabled HW MAC learning. Hence the condition
that both ports must join same bridge.

Add brigde methods port_bridge_join, port_bridge_leave and
port_stp_state_set.

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 88 ++
 drivers/net/dsa/lan9303.h  |  1 +
 2 files changed, 89 insertions(+)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index bba875e114e7..76112674fe6a 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "lan9303.h"
 
@@ -146,6 +147,7 @@
 # define LAN9303_SWE_PORT_STATE_FORWARDING_PORT0 (0)
 # define LAN9303_SWE_PORT_STATE_LEARNING_PORT0 BIT(1)
 # define LAN9303_SWE_PORT_STATE_BLOCKING_PORT0 BIT(0)
+# define LAN9303_SWE_PORT_STATE_DISABLED_PORT0 (3)
 #define LAN9303_SWE_PORT_MIRROR 0x1846
 # define LAN9303_SWE_PORT_MIRROR_SNIFF_ALL BIT(8)
 # define LAN9303_SWE_PORT_MIRROR_SNIFFER_PORT2 BIT(7)
@@ -431,6 +433,20 @@ static int lan9303_read_switch_reg(struct lan9303 *chip, 
u16 regnum, u32 *val)
return ret;
 }
 
+static int lan9303_write_switch_reg_mask(
+   struct lan9303 *chip, u16 regnum, u32 val, u32 mask)
+{
+   int ret;
+   u32 reg;
+
+   ret = lan9303_read_switch_reg(chip, regnum, ®);
+   if (ret)
+   return ret;
+   reg = (reg & ~mask) | val;
+
+   return lan9303_write_switch_reg(chip, regnum, reg);
+}
+
 static int lan9303_write_switch_port(struct lan9303 *chip, int port,
 u16 regnum, u32 val)
 {
@@ -556,6 +572,12 @@ static int lan9303_separate_ports(struct lan9303 *chip)
LAN9303_SWE_PORT_STATE_BLOCKING_PORT2);
 }
 
+static void lan9303_bridge_ports(struct lan9303 *chip)
+{
+   /* ports bridged: remove mirroring */
+   lan9303_write_switch_reg(chip, LAN9303_SWE_PORT_MIRROR, 0);
+}
+
 static int lan9303_handle_reset(struct lan9303 *chip)
 {
if (!chip->reset_gpio)
@@ -844,6 +866,69 @@ static void lan9303_port_disable(struct dsa_switch *ds, 
int port,
}
 }
 
+static int lan9303_port_bridge_join(struct dsa_switch *ds, int port,
+   struct net_device *br)
+{
+   struct lan9303 *chip = ds->priv;
+
+   dev_dbg(chip->dev, "%s(port %d)\n", __func__, port);
+   if (ds->ports[1].bridge_dev ==  ds->ports[2].bridge_dev) {
+   lan9303_bridge_ports(chip);
+   chip->is_bridged = true;  /* unleash stp_state_set() */
+   }
+
+   return 0;
+}
+
+static void lan9303_port_bridge_leave(struct dsa_switch *ds, int port,
+ struct net_device *br)
+{
+   struct lan9303 *chip = ds->priv;
+
+   dev_dbg(chip->dev, "%s(port %d)\n", __func__, port);
+   if (chip->is_bridged) {
+   lan9303_separate_ports(chip);
+   chip->is_bridged = false;
+   }
+}
+
+static void lan9303_port_stp_state_set(struct dsa_switch *ds, int port,
+  u8 state)
+{
+   int portmask, portstate;
+   struct lan9303 *chip = ds->priv;
+
+   dev_dbg(chip->dev, "%s(port %d, state %d)\n",
+   __func__, port, state);
+   if (!chip->is_bridged)
+   return; /* touching SWE_PORT_STATE will break port separation */
+
+   switch (state) {
+   case BR_STATE_DISABLED:
+   portstate = LAN9303_SWE_PORT_STATE_DISABLED_PORT0;
+   break;
+   case BR_STATE_BLOCKING:
+   case BR_STATE_LISTENING:
+   portstate = LAN9303_SWE_PORT_STATE_BLOCKING_PORT0;
+   break;
+   case BR_STATE_LEARNING:
+   portstate = LAN9303_SWE_PORT_STATE_LEARNING_PORT0;
+   break;
+   case BR_STATE_FORWARDING:
+   portstate = LAN9303_SWE_PORT_STATE_FORWARDING_PORT0;
+   break;
+   default:
+   portstate = LAN9303_SWE_PORT_STATE_DISABLED_PORT0;
+   dev_err(chip->dev, "unknown stp state: port %d, state %d\n",
+   port, state);
+   }
+
+   portmask = 0x3 << (port * 2);
+   portstate <<= (port * 2);
+   lan9303_write_switch_reg_mask(chip, LAN9303_SWE_PORT_STATE,
+ portstate, portmask);
+}
+
 static const struct dsa_switch_ops lan9303_switch_ops = {
.get_tag_protocol = lan9303_get_tag_protocol,
.setup = lan9303_setup,
@@ -855,6 +940,9 @@ static const struct dsa_switch_ops lan9303_switch_ops = {
.get_sset_count = lan9303_get_sset_count,
.port_enable = lan9303_port_enable,
.port_disable = lan9303_port_disable,
+   .port

Re: [PATCH] bitfield.h: remove 32bit from FIELD_GET comment block

[Jakub Kicinski]

On Thu, 21 Sep 2017 00:39:35 +0900, Masahiro Yamada wrote:
> I do not see anything that restricts this macro to 32 bit width.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Jakub Kicinski 

Looks like a leftover from v1 of the code, thanks for cleaning it up!

Re: [PATCH CFT 0/4] VT-d PI fixes

[Paolo Bonzini]

On 21/09/2017 10:23, Longpeng (Mike) wrote:
> Hi Paolo,
> 
> We have backported the first three patches and have tested for about 20 days, 
> it
> works fine.
> 
> So could you consider to merge this series ?

Yes, thanks very much!!

Paolo

Re: [PATCH V8 08/14] mmc: core: Add parameter use_blk_mq

[Ulf Hansson]

On 13 September 2017 at 13:40, Adrian Hunter  wrote:
> Until mmc has blk-mq support fully implemented and tested, add a
> parameter use_blk_mq, default to false unless config option MMC_MQ_DEFAULT
> is selected.
>
> Signed-off-by: Adrian Hunter 
> ---
>  drivers/mmc/Kconfig  | 11 +++
>  drivers/mmc/core/core.c  |  7 +++
>  drivers/mmc/core/core.h  |  2 ++
>  drivers/mmc/core/host.c  |  2 ++
>  drivers/mmc/core/host.h  |  4 
>  include/linux/mmc/host.h |  1 +
>  6 files changed, 27 insertions(+)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index ec21388311db..98202934bd29 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -12,6 +12,17 @@ menuconfig MMC
>   If you want MMC/SD/SDIO support, you should say Y here and
>   also to your specific host controller driver.
>
> +config MMC_MQ_DEFAULT
> +   bool "MMC: use blk-mq I/O path by default"
> +   depends on MMC && BLOCK
> +   ---help---
> + This option enables the new blk-mq based I/O path for MMC block
> + devices by default.  With the option the mmc_core.use_blk_mq
> + module/boot option defaults to Y, without it to N, but it can
> + still be overridden either way.
> +
> + If unsure say N.
> +
>  if MMC

I asume the goal of adding this option is to enable us to move slowly
forward. In general that might be a good idea, however for this
particular case I am not sure.

The main reason is simply that I find it unlikely that people and
distributions will actually go in and change the default value, so in
the end we will just be adding new code, which isn't really going to
be much tested. That's what happened in scsi case.

As I also stated earlier, I do worry about the maintenance of the mmc
block device code, and this approach make it worse, at least short
term.

To me, the scsi case is also different, because the mq support was
added long time ago and at that point one could worry a bit of
maturity of the blkmq in general, that I assume have been sorted out
by know.

>
>  source "drivers/mmc/core/Kconfig"
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index ef2d8aa1e7d2..3638ed4f0f9e 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -66,6 +66,13 @@
>  bool use_spi_crc = 1;
>  module_param(use_spi_crc, bool, 0);
>
> +#ifdef CONFIG_MMC_MQ_DEFAULT
> +bool mmc_use_blk_mq = true;
> +#else
> +bool mmc_use_blk_mq = false;
> +#endif
> +module_param_named(use_blk_mq, mmc_use_blk_mq, bool, S_IWUSR | S_IRUGO);
> +
>  static int mmc_schedule_delayed_work(struct delayed_work *work,
>  unsigned long delay)
>  {
> diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
> index e941342ed450..535539a9e7eb 100644
> --- a/drivers/mmc/core/core.h
> +++ b/drivers/mmc/core/core.h
> @@ -35,6 +35,8 @@ struct mmc_bus_ops {
> int (*reset)(struct mmc_host *);
>  };
>
> +extern bool mmc_use_blk_mq;
> +
>  void mmc_attach_bus(struct mmc_host *host, const struct mmc_bus_ops *ops);
>  void mmc_detach_bus(struct mmc_host *host);
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index ad88deb2e8f3..b624dbb6cd15 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -398,6 +398,8 @@ struct mmc_host *mmc_alloc_host(int extra, struct device 
> *dev)
> host->max_blk_size = 512;
> host->max_blk_count = PAGE_SIZE / 512;
>
> +   host->use_blk_mq = mmc_use_blk_mq;
> +
> return host;
>  }
>
> diff --git a/drivers/mmc/core/host.h b/drivers/mmc/core/host.h
> index 77d6f60d1bf9..170fe5947087 100644
> --- a/drivers/mmc/core/host.h
> +++ b/drivers/mmc/core/host.h
> @@ -69,6 +69,10 @@ static inline bool mmc_card_hs400es(struct mmc_card *card)
> return card->host->ios.enhanced_strobe;
>  }
>
> +static inline bool mmc_host_use_blk_mq(struct mmc_host *host)
> +{
> +   return host->use_blk_mq;
> +}
>
>  #endif
>
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 54b0463443bd..5d1bd10991f7 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -378,6 +378,7 @@ struct mmc_host {
> unsigned intdoing_retune:1; /* re-tuning in progress */
> unsigned intretune_now:1;   /* do re-tuning at next req */
> unsigned intretune_paused:1; /* re-tuning is temporarily 
> disabled */
> +   unsigned intuse_blk_mq:1;   /* use blk-mq */
>
> int rescan_disable; /* disable card detection */
> int rescan_entered; /* used with nonremovable 
> devices */
> --
> 1.9.1
>

Kind regards
Uffe

Re: [PATCH v1 3/4] arm: dts: mt7623: add display related nodes

[Ryder Lee]

On Tue, 2017-09-19 at 23:26 +0800, CK Hu wrote:
> Hi, Ryder:
> 
> Some comment inline.
> 
> On Tue, 2017-09-19 at 14:27 +0800, Ryder Lee wrote:
> > This patch adds the device nodes for the display function block.
> > Also, we add some missing pin macros in mt7623-pinfunc.h.
> > 
> > Signed-off-by: Ryder Lee 
> > CC: Linus Walleij 
> > Acked-by: Linus Walleij 
> > ---
> >  arch/arm/boot/dts/mt7623.dtsi | 210 
> > ++
> >  arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts |  41 -
> >  include/dt-bindings/pinctrl/mt7623-pinfunc.h  |  12 ++
> >  3 files changed, 261 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> > index 9ec3767..e11e5e7 100644
> > --- a/arch/arm/boot/dts/mt7623.dtsi
> > +++ b/arch/arm/boot/dts/mt7623.dtsi
> > @@ -20,6 +20,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include "skeleton64.dtsi"
> > @@ -28,6 +29,11 @@
> > compatible = "mediatek,mt7623";
> > interrupt-parent = <&sysirq>;
> >  
> > +   aliases {
> > +   rdma0 = &rdma0;
> > +   rdma1 = &rdma1;
> 
> For display, are these two aliases enough?

Yes, this part is the same as mt2701.

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

> > +   };
> > +

...
> > +   wdma@14009000 {
> > +   compatible = "mediatek,mt7623-disp-wdma",
> > +"mediatek,mt2701-disp-wdma";
> 
> There is neither "mediatek,mt7623-disp-wdma" nor
> "mediatek,mt2701-disp-wdma" in driver, do you really need this device
> node?

Okay, I will remove it.

> > +   reg = <0 0x14009000 0 0x1000>;
> > +   interrupts = ;
> > +   clocks = <&mmsys CLK_MM_DISP_WDMA>;
> > +   iommus = <&iommu MT2701_M4U_PORT_DISP_WDMA>;
> > +   mediatek,larb = <&larb0>;
> > +   };
> > +
> > +   bls: bls@1400a000 {
> > +   compatible = "mediatek,mt7623-disp-pwm",
> > +"mediatek,mt2701-disp-pwm";
> > +   reg = <0 0x1400a000 0 0x1000>;
> > +   #pwm-cells = <2>;
> > +   clocks = <&mmsys CLK_MM_MDP_BLS_26M>,
> > +<&mmsys CLK_MM_DISP_BLS>;
> > +   clock-names = "main", "mm";
> > +   status = "disabled";
> > +   };
> > +
> > +   color@1400b000 {
> 
> color: color@1400b000 {

Okay.
> > +   compatible = "mediatek,mt7623-disp-color",
> > +"mediatek,mt2701-disp-color";
> > +   reg = <0 0x1400b000 0 0x1000>;
> > +   interrupts = ;
> > +   clocks = <&mmsys CLK_MM_DISP_COLOR>;
> > +   };
> > +

Re: [PATCH V8 00/14] mmc: Add Command Queue support

[Adrian Hunter]

On 21/09/17 12:01, Ulf Hansson wrote:
> On 13 September 2017 at 13:40, Adrian Hunter  wrote:
>> Hi
>>
>> Here is V8 of the hardware command queue patches without the software
>> command queue patches, now using blk-mq and now with blk-mq support for
>> non-CQE I/O.
>>
>> After the unacceptable debacle of the last release cycle, I expect an
>> immediate response to these patches.
>>
>> HW CMDQ offers 25% - 50% better random multi-threaded I/O.  I see a slight
>> 2% drop in sequential read speed but no change to sequential write.
>>
>> Non-CQE blk-mq showed a 3% decrease in sequential read performance.  This
>> seemed to be coming from the inferior latency of running work items compared
>> with a dedicated thread.  Hacking blk-mq workqueue to be unbound reduced the
>> performance degradation from 3% to 1%.
>>
>> While we should look at changing blk-mq to give better workqueue performance,
>> a bigger gain is likely to be made by adding a new host API to enable the
>> next already-prepared request to be issued directly from within ->done()
>> callback of the current request.
> 
> Adrian, I am reviewing this series, however let me comment on each
> change individually.
> 
> I have also run some test on my ux500 board and enabling the blkmq
> path via the new MMC Kconfig option. My idea was to run some iozone
> comparisons between the legacy path and the new blkmq path, but I just
> couldn't get to that point because of the following errors.
> 
> I am using a Kingston 4GB SDHC card, which is detected and mounted
> nicely. However, when I decide to do some writes to the card I get the
> following errors.
> 
> root@ME:/mnt/sdcard dd if=/dev/zero of=testfile bs=8192 count=5000 conv=fsync
> [  463.714294] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  464.722656] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  466.081481] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  467.111236] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  468.669647] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  469.685699] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  471.043334] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  472.052337] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  473.342651] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  474.323760] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  475.544769] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  476.539031] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  477.748474] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> [  478.724182] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
> 
> I haven't yet got the point of investigating this any further, and
> unfortunate I have a busy schedule with traveling next week. I will do
> my best to look into this as soon as I can.
> 
> Perhaps you have some ideas?

The behaviour depends on whether you have MMC_CAP_WAIT_WHILE_BUSY. Try
changing that and see if it makes a difference.