linux-next: manual merge of the target-updates tree with the scsi tree

[Stephen Rothwell]

Hi Nicholas,

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

  drivers/scsi/qla2xxx/qla_target.c

between commit:

  c5419e2618b9 ("scsi: qla2xxx: Combine Active command arrays.")

from the scsi tree and commit:

  bc1bb269ef7b ("qla2xxx: Fix incorrect tcm_qla2xxx_free_cmd use during TMR 
ABORT")

from the target-updates tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/scsi/qla2xxx/qla_target.c
index 2a0173e5d10e,8f8ece900801..
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@@ -1874,36 -1847,13 +1874,14 @@@ static int __qlt_24xx_handle_abts(struc
struct abts_recv_from_24xx *abts, struct fc_port *sess)
  {
struct qla_hw_data *ha = vha->hw;
-   struct se_session *se_sess = sess->se_sess;
struct qla_tgt_mgmt_cmd *mcmd;
-   struct qla_tgt_cmd *cmd;
-   struct se_cmd *se_cmd;
int rc;
-   bool found_lun = false;
-   unsigned long flags;
  
-   spin_lock_irqsave(_sess->sess_cmd_lock, flags);
-   list_for_each_entry(se_cmd, _sess->sess_cmd_list, se_cmd_list) {
-   if (se_cmd->tag == abts->exchange_addr_to_abort) {
-   found_lun = true;
-   break;
-   }
-   }
-   spin_unlock_irqrestore(_sess->sess_cmd_lock, flags);
- 
-   /* cmd not in LIO lists, look in qla list */
-   if (!found_lun) {
-   if (abort_cmd_for_tag(vha, abts->exchange_addr_to_abort)) {
-   /* send TASK_ABORT response immediately */
-   qlt_24xx_send_abts_resp(ha->base_qpair, abts,
-   FCP_TMF_CMPL, false);
-   return 0;
-   } else {
-   ql_dbg(ql_dbg_tgt_mgt, vha, 0xf081,
-   "unable to find cmd in driver or LIO for tag 
0x%x\n",
-   abts->exchange_addr_to_abort);
-   return -ENOENT;
-   }
+   if (abort_cmd_for_tag(vha, abts->exchange_addr_to_abort)) {
+   /* send TASK_ABORT response immediately */
 -  qlt_24xx_send_abts_resp(vha, abts, FCP_TMF_CMPL, false);
++  qlt_24xx_send_abts_resp(ha->base_qpair, abts,
++  FCP_TMF_CMPL, false);
+   return 0;
}
  
ql_dbg(ql_dbg_tgt_mgt, vha, 0xf00f,
@@@ -1919,14 -1869,16 +1897,18 @@@
}
memset(mcmd, 0, sizeof(*mcmd));
  
 +  cmd = container_of(se_cmd, struct qla_tgt_cmd, se_cmd);
mcmd->sess = sess;
memcpy(>orig_iocb.abts, abts, sizeof(mcmd->orig_iocb.abts));
 -  mcmd->reset_count = vha->hw->chip_reset;
 +  mcmd->reset_count = ha->base_qpair->chip_reset;
mcmd->tmr_func = QLA_TGT_ABTS;
 +  mcmd->qpair = ha->base_qpair;
  
-   rc = ha->tgt.tgt_ops->handle_tmr(mcmd, cmd->unpacked_lun, 
mcmd->tmr_func,
+   /*
+* LUN is looked up by target-core internally based on the passed
+* abts->exchange_addr_to_abort tag.
+*/
+   rc = ha->tgt.tgt_ops->handle_tmr(mcmd, 0, mcmd->tmr_func,
abts->exchange_addr_to_abort);
if (rc != 0) {
ql_dbg(ql_dbg_tgt_mgt, vha, 0xf052,
@@@ -4188,7 -4078,9 +4170,10 @@@ static struct qla_tgt_cmd *qlt_get_tag(
  
cmd = &((struct qla_tgt_cmd *)se_sess->sess_cmd_map)[tag];
memset(cmd, 0, sizeof(struct qla_tgt_cmd));
 +  cmd->cmd_type = TYPE_TGT_CMD;
+ 
+   init_completion(>write_pending_abort_comp);
+ 
memcpy(>atio, atio, sizeof(*atio));
cmd->state = QLA_TGT_STATE_NEW;
cmd->tgt = vha->vha_tgt.qla_tgt;

linux-next: manual merge of the target-updates tree with the scsi tree

[Stephen Rothwell]

Hi Nicholas,

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

  drivers/scsi/qla2xxx/qla_target.c

between commit:

  c5419e2618b9 ("scsi: qla2xxx: Combine Active command arrays.")

from the scsi tree and commit:

  bc1bb269ef7b ("qla2xxx: Fix incorrect tcm_qla2xxx_free_cmd use during TMR 
ABORT")

from the target-updates tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/scsi/qla2xxx/qla_target.c
index 2a0173e5d10e,8f8ece900801..
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@@ -1874,36 -1847,13 +1874,14 @@@ static int __qlt_24xx_handle_abts(struc
struct abts_recv_from_24xx *abts, struct fc_port *sess)
  {
struct qla_hw_data *ha = vha->hw;
-   struct se_session *se_sess = sess->se_sess;
struct qla_tgt_mgmt_cmd *mcmd;
-   struct qla_tgt_cmd *cmd;
-   struct se_cmd *se_cmd;
int rc;
-   bool found_lun = false;
-   unsigned long flags;
  
-   spin_lock_irqsave(_sess->sess_cmd_lock, flags);
-   list_for_each_entry(se_cmd, _sess->sess_cmd_list, se_cmd_list) {
-   if (se_cmd->tag == abts->exchange_addr_to_abort) {
-   found_lun = true;
-   break;
-   }
-   }
-   spin_unlock_irqrestore(_sess->sess_cmd_lock, flags);
- 
-   /* cmd not in LIO lists, look in qla list */
-   if (!found_lun) {
-   if (abort_cmd_for_tag(vha, abts->exchange_addr_to_abort)) {
-   /* send TASK_ABORT response immediately */
-   qlt_24xx_send_abts_resp(ha->base_qpair, abts,
-   FCP_TMF_CMPL, false);
-   return 0;
-   } else {
-   ql_dbg(ql_dbg_tgt_mgt, vha, 0xf081,
-   "unable to find cmd in driver or LIO for tag 
0x%x\n",
-   abts->exchange_addr_to_abort);
-   return -ENOENT;
-   }
+   if (abort_cmd_for_tag(vha, abts->exchange_addr_to_abort)) {
+   /* send TASK_ABORT response immediately */
 -  qlt_24xx_send_abts_resp(vha, abts, FCP_TMF_CMPL, false);
++  qlt_24xx_send_abts_resp(ha->base_qpair, abts,
++  FCP_TMF_CMPL, false);
+   return 0;
}
  
ql_dbg(ql_dbg_tgt_mgt, vha, 0xf00f,
@@@ -1919,14 -1869,16 +1897,18 @@@
}
memset(mcmd, 0, sizeof(*mcmd));
  
 +  cmd = container_of(se_cmd, struct qla_tgt_cmd, se_cmd);
mcmd->sess = sess;
memcpy(>orig_iocb.abts, abts, sizeof(mcmd->orig_iocb.abts));
 -  mcmd->reset_count = vha->hw->chip_reset;
 +  mcmd->reset_count = ha->base_qpair->chip_reset;
mcmd->tmr_func = QLA_TGT_ABTS;
 +  mcmd->qpair = ha->base_qpair;
  
-   rc = ha->tgt.tgt_ops->handle_tmr(mcmd, cmd->unpacked_lun, 
mcmd->tmr_func,
+   /*
+* LUN is looked up by target-core internally based on the passed
+* abts->exchange_addr_to_abort tag.
+*/
+   rc = ha->tgt.tgt_ops->handle_tmr(mcmd, 0, mcmd->tmr_func,
abts->exchange_addr_to_abort);
if (rc != 0) {
ql_dbg(ql_dbg_tgt_mgt, vha, 0xf052,
@@@ -4188,7 -4078,9 +4170,10 @@@ static struct qla_tgt_cmd *qlt_get_tag(
  
cmd = &((struct qla_tgt_cmd *)se_sess->sess_cmd_map)[tag];
memset(cmd, 0, sizeof(struct qla_tgt_cmd));
 +  cmd->cmd_type = TYPE_TGT_CMD;
+ 
+   init_completion(>write_pending_abort_comp);
+ 
memcpy(>atio, atio, sizeof(*atio));
cmd->state = QLA_TGT_STATE_NEW;
cmd->tgt = vha->vha_tgt.qla_tgt;

[linux-next] SMT off triggers WARNING: CPU: 1 PID: 13 at arch/powerpc/kernel/watchdog.c:314 stop_wd_on_cpu+0x54/0xf0

[Abdul Haleem]

Hi,

Today's next-20170630 on powerpc shows warnings in dmesg when SMT is
disabled.

Test: SMT off
kernel: 4.12.0-rc7-next-20170630
Machine: Power 8 Bare-metal
gcc: 4.8.5
config: attached

Steps to recreate
-
1. Boot powerpc machine with today's next kernel.
By default SMT 8 is enabled.
$ ppc64_cpu  --smt
SMT=8

2. Disable SMT
$ ppc64_cpu --smt=off

With above command a WARN_ON(1) is triggered from stop_wd_on_cpu
function in file arch/powerpc/kernel/watchdog.c at line 314

static int stop_wd_on_cpu(unsigned int cpu)
{
if (!cpumask_test_cpu(cpu, _cpus_enabled)) {
>>> WARN_ON(1);
return 0;
}


$ dmesg
WARNING: CPU: 1 PID: 13 at arch/powerpc/kernel/watchdog.c:314 
stop_wd_on_cpu+0x54/0xf0
Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge
stp llc kvm_hv kvm iptable_filter vmx_crypto ipmi_powernv ipmi_devintf
leds_powernv ipmi_msghandler powernv_op_panel powernv_rng led_class
rng_core binfmt_misc nfsd ip_tables x_tables autofs4
CPU: 1 PID: 13 Comm: cpuhp/1 Not tainted
4.12.0-rc7-next-20170630-autotest #1
task: c007f8479200 task.stack: c007f8578000
NIP: c002cbd4 LR: c00dc238 CTR: c002cb80
REGS: c007f857b9b0 TRAP: 0700   Not tainted  
(4.12.0-rc7-next-20170630-autotest)
MSR: 90029033 
  CR: 2428  XER:   
CFAR: c00dc234 SOFTE: 1 
GPR00: c00dc238 c007f857bc30 c1063000 0001
GPR04: 009e   
GPR08: 0001   
GPR12: c002cb80 cfd40580 c0107348 c007fc163d80
GPR16:    
GPR20:    c010ccc0
GPR24: c0f47888 0007fe81  c002cb80
GPR28: 009e  c10a1b80 0001
NIP [c002cbd4] stop_wd_on_cpu+0x54/0xf0
LR [c00dc238] cpuhp_invoke_callback+0x148/0x5b0
Call Trace:
[c007f857bc70] [c00dc238] cpuhp_invoke_callback+0x148/0x5b0
[c007f857bce0] [c00dc818] cpuhp_down_callbacks+0x78/0xf0
[c007f857bd30] [c00dd86c] cpuhp_thread_fun+0x16c/0x180
[c007f857bd60] [c010cf50] smpboot_thread_fn+0x290/0x2a0
[c007f857bdc0] [c01074a0] kthread+0x160/0x1a0
[c007f857be30] [c000bc9c] ret_from_kernel_thread+0x5c/0xc0
Instruction dump:
3d420004 394aeb80 7fa907b4 57e806be 79291f24 f8010010 f821ffc1 7fca4a14 
7cea482a 7ce94436 792a07e1 40820030 <0fe0> 38210040 3860 e8010010 
---[ end trace bc1cf8bfb9c5be6e ]---


-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre


#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 4.10.0-rc2 Kernel Configuration
#
CONFIG_PPC64=y

#
# Processor support
#
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
# CONFIG_POWER7_CPU is not set
CONFIG_POWER8_CPU=y
CONFIG_PPC_BOOK3S=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
# CONFIG_PPC_ICSWX is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_64=y
CONFIG_PPC_RADIX_MMU=y
CONFIG_PPC_MM_SLICES=y
CONFIG_PPC_HAVE_PMU_SUPPORT=y
CONFIG_PPC_PERF_CTRS=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2048
CONFIG_PPC_DOORBELL=y
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_PPC64_BOOT_WRAPPER=y
CONFIG_64BIT=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
CONFIG_PPC=y
CONFIG_GENERIC_CSUM=y
CONFIG_EARLY_PRINTK=y
CONFIG_PANIC_TIMEOUT=180
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_EPAPR_BOOT=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_PPC_EMULATE_SSTEP=y
CONFIG_ZONE_DMA32=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_XZ is not set

[linux-next] SMT off triggers WARNING: CPU: 1 PID: 13 at arch/powerpc/kernel/watchdog.c:314 stop_wd_on_cpu+0x54/0xf0

[Abdul Haleem]

Hi,

Today's next-20170630 on powerpc shows warnings in dmesg when SMT is
disabled.

Test: SMT off
kernel: 4.12.0-rc7-next-20170630
Machine: Power 8 Bare-metal
gcc: 4.8.5
config: attached

Steps to recreate
-
1. Boot powerpc machine with today's next kernel.
By default SMT 8 is enabled.
$ ppc64_cpu  --smt
SMT=8

2. Disable SMT
$ ppc64_cpu --smt=off

With above command a WARN_ON(1) is triggered from stop_wd_on_cpu
function in file arch/powerpc/kernel/watchdog.c at line 314

static int stop_wd_on_cpu(unsigned int cpu)
{
if (!cpumask_test_cpu(cpu, _cpus_enabled)) {
>>> WARN_ON(1);
return 0;
}


$ dmesg
WARNING: CPU: 1 PID: 13 at arch/powerpc/kernel/watchdog.c:314 
stop_wd_on_cpu+0x54/0xf0
Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge
stp llc kvm_hv kvm iptable_filter vmx_crypto ipmi_powernv ipmi_devintf
leds_powernv ipmi_msghandler powernv_op_panel powernv_rng led_class
rng_core binfmt_misc nfsd ip_tables x_tables autofs4
CPU: 1 PID: 13 Comm: cpuhp/1 Not tainted
4.12.0-rc7-next-20170630-autotest #1
task: c007f8479200 task.stack: c007f8578000
NIP: c002cbd4 LR: c00dc238 CTR: c002cb80
REGS: c007f857b9b0 TRAP: 0700   Not tainted  
(4.12.0-rc7-next-20170630-autotest)
MSR: 90029033 
  CR: 2428  XER:   
CFAR: c00dc234 SOFTE: 1 
GPR00: c00dc238 c007f857bc30 c1063000 0001
GPR04: 009e   
GPR08: 0001   
GPR12: c002cb80 cfd40580 c0107348 c007fc163d80
GPR16:    
GPR20:    c010ccc0
GPR24: c0f47888 0007fe81  c002cb80
GPR28: 009e  c10a1b80 0001
NIP [c002cbd4] stop_wd_on_cpu+0x54/0xf0
LR [c00dc238] cpuhp_invoke_callback+0x148/0x5b0
Call Trace:
[c007f857bc70] [c00dc238] cpuhp_invoke_callback+0x148/0x5b0
[c007f857bce0] [c00dc818] cpuhp_down_callbacks+0x78/0xf0
[c007f857bd30] [c00dd86c] cpuhp_thread_fun+0x16c/0x180
[c007f857bd60] [c010cf50] smpboot_thread_fn+0x290/0x2a0
[c007f857bdc0] [c01074a0] kthread+0x160/0x1a0
[c007f857be30] [c000bc9c] ret_from_kernel_thread+0x5c/0xc0
Instruction dump:
3d420004 394aeb80 7fa907b4 57e806be 79291f24 f8010010 f821ffc1 7fca4a14 
7cea482a 7ce94436 792a07e1 40820030 <0fe0> 38210040 3860 e8010010 
---[ end trace bc1cf8bfb9c5be6e ]---


-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre


#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 4.10.0-rc2 Kernel Configuration
#
CONFIG_PPC64=y

#
# Processor support
#
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
# CONFIG_POWER7_CPU is not set
CONFIG_POWER8_CPU=y
CONFIG_PPC_BOOK3S=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
# CONFIG_PPC_ICSWX is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_64=y
CONFIG_PPC_RADIX_MMU=y
CONFIG_PPC_MM_SLICES=y
CONFIG_PPC_HAVE_PMU_SUPPORT=y
CONFIG_PPC_PERF_CTRS=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2048
CONFIG_PPC_DOORBELL=y
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_PPC64_BOOT_WRAPPER=y
CONFIG_64BIT=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
CONFIG_PPC=y
CONFIG_GENERIC_CSUM=y
CONFIG_EARLY_PRINTK=y
CONFIG_PANIC_TIMEOUT=180
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_EPAPR_BOOT=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_PPC_EMULATE_SSTEP=y
CONFIG_ZONE_DMA32=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_XZ is not set
CONFIG_DEFAULT_HOSTNAME="(none)"

[PATCH] PCI: mediatek: Remove unnecessary PCI_REASSIGN_* flags

[Ryder Lee]

The PCI_REASSIGN_ALL_RSRC and PCI_REASSIGN_ALL_BUS flags are not needed,
since we should automatically assign resources if the firmware hasn't done it.

Signed-off-by: Ryder Lee 
---
 drivers/pci/host/pcie-mediatek.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 51c6118..5a9d858 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -478,7 +478,6 @@ static int mtk_pcie_register_host(struct pci_host_bridge 
*host)
struct pci_bus *child;
int err;
 
-   pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
host->busnr = pcie->busn.start;
host->dev.parent = pcie->dev;
host->ops = _pcie_ops;
-- 
1.9.1

[PATCH] PCI: mediatek: Remove unnecessary PCI_REASSIGN_* flags

[Ryder Lee]

The PCI_REASSIGN_ALL_RSRC and PCI_REASSIGN_ALL_BUS flags are not needed,
since we should automatically assign resources if the firmware hasn't done it.

Signed-off-by: Ryder Lee 
---
 drivers/pci/host/pcie-mediatek.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 51c6118..5a9d858 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -478,7 +478,6 @@ static int mtk_pcie_register_host(struct pci_host_bridge 
*host)
struct pci_bus *child;
int err;
 
-   pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
host->busnr = pcie->busn.start;
host->dev.parent = pcie->dev;
host->ops = _pcie_ops;
-- 
1.9.1

[GIT PULL] EDAC queue for 4.13

[Borislav Petkov]

Hi Linus,

please pull the EDAC pile for 4.13. Nothing earth-shattering - just the
normal development flow of cleanups, improvements, fixes and such.

Thanks.

---
The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:

  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

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

for you to fetch changes up to 164c29244d4beb9a105102c42821f4925e4a0c7a:

  EDAC, pnd2: Fix Apollo Lake DIMM detection (2017-06-29 10:37:50 +0200)


* i31200_edac: Add Kabylake support (Jason Baron)

* sb_edac: resolve memory controller detection issues on asymmetric
setups with not all DIMM slots being populated (Tony Luck and Qiuxu Zhuo)

* misc cleanups and fixlets all over


Borislav Petkov (2):
  EDAC, sb_edac: Fix mod_name
  EDAC, sb_edac: Carve out dimm-populating loop

Chris Packham (5):
  EDAC, mv64x60: Fix pdata->name
  EDAC, mv64x60: Replace in_le32()/out_le32() with readl()/writel()
  EDAC, mv64x60: Check driver registration success
  EDAC, mv64x60: Sanity check edac_op_state before registering
  EDAC, altera: Simplify calculation of total memory

Colin Ian King (1):
  EDAC, pnd2: Make function sbi_send() static

Gustavo A. R. Silva (1):
  EDAC, pnd2: Return proper error value from apl_rd_reg()

Jason Baron (1):
  EDAC, ie31200: Add Intel Kaby Lake CPU support

Jérémy Lefaure (1):
  EDAC, i5000, i5400: Fix definition of NRECMEMB register

Qiuxu Zhuo (6):
  EDAC, sb_edac: Classify PCI-IDs by topology
  EDAC, sb_edac: Assign EDAC memory controller per h/w controller
  EDAC, sb_edac: Drop NUM_CHANNELS from 8 back to 4
  EDAC, sb_edac: Check if ECC enabled when at least one DIMM is present
  EDAC, sb_edac: Bump driver version and do some cleanups
  EDAC, sb_edac: Avoid creating SOCK memory controller

Tobias Klauser (1):
  EDAC, altera: Constify irq_domain_ops

Tony Luck (2):
  EDAC, sb_edac: Don't use "Socket#" in the memory controller name
  EDAC, pnd2: Fix Apollo Lake DIMM detection

Vadim Lomovtsev (1):
  EDAC, thunderx: Fix a warning during l2c debugfs node creation

Yazen Ghannam (1):
  EDAC, mce_amd: Fix typo in SMCA error description

 drivers/edac/altera_edac.c   |  26 +-
 drivers/edac/i5000_edac.c|   6 +-
 drivers/edac/i5400_edac.c|   4 +-
 drivers/edac/ie31200_edac.c  |  13 +-
 drivers/edac/mce_amd.c   |   2 +-
 drivers/edac/mv64x60_edac.c  |  88 +++---
 drivers/edac/pnd2_edac.c |  20 +-
 drivers/edac/sb_edac.c   | 682 ---
 drivers/edac/thunderx_edac.c |   2 +-
 9 files changed, 399 insertions(+), 444 deletions(-)

-- 
Regards/Gruss,
Boris.

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

[GIT PULL] EDAC queue for 4.13

[Borislav Petkov]

Hi Linus,

please pull the EDAC pile for 4.13. Nothing earth-shattering - just the
normal development flow of cleanups, improvements, fixes and such.

Thanks.

---
The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:

  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

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

for you to fetch changes up to 164c29244d4beb9a105102c42821f4925e4a0c7a:

  EDAC, pnd2: Fix Apollo Lake DIMM detection (2017-06-29 10:37:50 +0200)


* i31200_edac: Add Kabylake support (Jason Baron)

* sb_edac: resolve memory controller detection issues on asymmetric
setups with not all DIMM slots being populated (Tony Luck and Qiuxu Zhuo)

* misc cleanups and fixlets all over


Borislav Petkov (2):
  EDAC, sb_edac: Fix mod_name
  EDAC, sb_edac: Carve out dimm-populating loop

Chris Packham (5):
  EDAC, mv64x60: Fix pdata->name
  EDAC, mv64x60: Replace in_le32()/out_le32() with readl()/writel()
  EDAC, mv64x60: Check driver registration success
  EDAC, mv64x60: Sanity check edac_op_state before registering
  EDAC, altera: Simplify calculation of total memory

Colin Ian King (1):
  EDAC, pnd2: Make function sbi_send() static

Gustavo A. R. Silva (1):
  EDAC, pnd2: Return proper error value from apl_rd_reg()

Jason Baron (1):
  EDAC, ie31200: Add Intel Kaby Lake CPU support

Jérémy Lefaure (1):
  EDAC, i5000, i5400: Fix definition of NRECMEMB register

Qiuxu Zhuo (6):
  EDAC, sb_edac: Classify PCI-IDs by topology
  EDAC, sb_edac: Assign EDAC memory controller per h/w controller
  EDAC, sb_edac: Drop NUM_CHANNELS from 8 back to 4
  EDAC, sb_edac: Check if ECC enabled when at least one DIMM is present
  EDAC, sb_edac: Bump driver version and do some cleanups
  EDAC, sb_edac: Avoid creating SOCK memory controller

Tobias Klauser (1):
  EDAC, altera: Constify irq_domain_ops

Tony Luck (2):
  EDAC, sb_edac: Don't use "Socket#" in the memory controller name
  EDAC, pnd2: Fix Apollo Lake DIMM detection

Vadim Lomovtsev (1):
  EDAC, thunderx: Fix a warning during l2c debugfs node creation

Yazen Ghannam (1):
  EDAC, mce_amd: Fix typo in SMCA error description

 drivers/edac/altera_edac.c   |  26 +-
 drivers/edac/i5000_edac.c|   6 +-
 drivers/edac/i5400_edac.c|   4 +-
 drivers/edac/ie31200_edac.c  |  13 +-
 drivers/edac/mce_amd.c   |   2 +-
 drivers/edac/mv64x60_edac.c  |  88 +++---
 drivers/edac/pnd2_edac.c |  20 +-
 drivers/edac/sb_edac.c   | 682 ---
 drivers/edac/thunderx_edac.c |   2 +-
 9 files changed, 399 insertions(+), 444 deletions(-)

-- 
Regards/Gruss,
Boris.

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

[PATCH 2/2] selftests: ftrace: Add more verbosity for immediate log

[Masami Hiramatsu]

Add 3-level verbosity for showing traced command log
on console immediately. Since some test cases can cause
kernel pacic if there is a probrem (like regression etc.),
we can not know which command caused the problem without
traced command log. This verbosity (-vvv) solves that
because it shows the log on console immediately. User
can get continuous command/error log.

Note that this is a kind of kernel debug mode, if you
don't see any kernel related issue, you don't need this
verbosity.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/selftests/ftrace/ftracetest |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 290cd42..e3f1521 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -15,6 +15,7 @@ echo "-h|--help  Show help message"
 echo " -k|--keep  Keep passed test logs"
 echo " -v|--verbose Increase verbosity of test messages"
 echo " -vvAlias of -v -v (Show all results in stdout)"
+echo " -vvv   Alias of -v -v -v (Show all commands immediately)"
 echo " -d|--debug Debug mode (trace all shell commands)"
 echo " -l|--logdir  Save logs on the "
 exit $1
@@ -56,9 +57,10 @@ parse_opts() { # opts
   KEEP_LOG=1
   shift 1
 ;;
---verbose|-v|-vv)
+--verbose|-v|-vv|-vvv)
   VERBOSE=$((VERBOSE + 1))
   [ $1 = '-vv' ] && VERBOSE=$((VERBOSE + 1))
+  [ $1 = '-vvv' ] && VERBOSE=$((VERBOSE + 2))
   shift 1
 ;;
 --debug|-d)
@@ -252,7 +254,9 @@ run_test() { # testfile
   testcase $1
   echo "execute$INSTANCE: "$1 > $testlog
   SIG_RESULT=0
-  if [ $VERBOSE -ge 2 ]; then
+  if [ $VERBOSE -ge 3 ]; then
+__run_test $1 | tee -a $testlog 2>&1
+  elif [ $VERBOSE -eq 2 ]; then
 __run_test $1 2>> $testlog | tee -a $testlog
   else
 __run_test $1 >> $testlog 2>&1

[PATCH 2/2] selftests: ftrace: Add more verbosity for immediate log

[Masami Hiramatsu]

Add 3-level verbosity for showing traced command log
on console immediately. Since some test cases can cause
kernel pacic if there is a probrem (like regression etc.),
we can not know which command caused the problem without
traced command log. This verbosity (-vvv) solves that
because it shows the log on console immediately. User
can get continuous command/error log.

Note that this is a kind of kernel debug mode, if you
don't see any kernel related issue, you don't need this
verbosity.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/selftests/ftrace/ftracetest |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 290cd42..e3f1521 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -15,6 +15,7 @@ echo "-h|--help  Show help message"
 echo " -k|--keep  Keep passed test logs"
 echo " -v|--verbose Increase verbosity of test messages"
 echo " -vvAlias of -v -v (Show all results in stdout)"
+echo " -vvv   Alias of -v -v -v (Show all commands immediately)"
 echo " -d|--debug Debug mode (trace all shell commands)"
 echo " -l|--logdir  Save logs on the "
 exit $1
@@ -56,9 +57,10 @@ parse_opts() { # opts
   KEEP_LOG=1
   shift 1
 ;;
---verbose|-v|-vv)
+--verbose|-v|-vv|-vvv)
   VERBOSE=$((VERBOSE + 1))
   [ $1 = '-vv' ] && VERBOSE=$((VERBOSE + 1))
+  [ $1 = '-vvv' ] && VERBOSE=$((VERBOSE + 2))
   shift 1
 ;;
 --debug|-d)
@@ -252,7 +254,9 @@ run_test() { # testfile
   testcase $1
   echo "execute$INSTANCE: "$1 > $testlog
   SIG_RESULT=0
-  if [ $VERBOSE -ge 2 ]; then
+  if [ $VERBOSE -ge 3 ]; then
+__run_test $1 | tee -a $testlog 2>&1
+  elif [ $VERBOSE -eq 2 ]; then
 __run_test $1 2>> $testlog | tee -a $testlog
   else
 __run_test $1 >> $testlog 2>&1

[PATCH 1/2] selftests: ftrace: Do not failure if there is unsupported tests

[Masami Hiramatsu]

Do not return failure exit code (1) for unsupported testcases,
since it is expected for stable kernels.

Previously, ftracetest is expected to run only on current
release for avoiding regressions. However, nowadays we run
it on stable kernels. This means some test cases must return
unsupported result. In such case, we should NOT exit
ftracetest with error status for unsupported results so that
kselftest (upper tests wrapper) shows it passed correctly.

Note that we continue to treat unresolved results as failure,
if test writers would like to notice user that the test result
should be reviewed, they can use exit_unresolved.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/selftests/ftrace/ftracetest |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 14a03ea..290cd42 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -187,7 +187,7 @@ eval_result() { # sigval
 $UNSUPPORTED)
   prlog "  [UNSUPPORTED]"
   UNSUPPORTED_CASES="$UNSUPPORTED_CASES $CASENO"
-  return 1 # this is not a bug, but the result should be reported.
+  return 0 # this is not a bug.
 ;;
 $XFAIL)
   prlog "  [XFAIL]"

[PATCH 1/2] selftests: ftrace: Do not failure if there is unsupported tests

[Masami Hiramatsu]

Do not return failure exit code (1) for unsupported testcases,
since it is expected for stable kernels.

Previously, ftracetest is expected to run only on current
release for avoiding regressions. However, nowadays we run
it on stable kernels. This means some test cases must return
unsupported result. In such case, we should NOT exit
ftracetest with error status for unsupported results so that
kselftest (upper tests wrapper) shows it passed correctly.

Note that we continue to treat unresolved results as failure,
if test writers would like to notice user that the test result
should be reviewed, they can use exit_unresolved.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/selftests/ftrace/ftracetest |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 14a03ea..290cd42 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -187,7 +187,7 @@ eval_result() { # sigval
 $UNSUPPORTED)
   prlog "  [UNSUPPORTED]"
   UNSUPPORTED_CASES="$UNSUPPORTED_CASES $CASENO"
-  return 1 # this is not a bug, but the result should be reported.
+  return 0 # this is not a bug.
 ;;
 $XFAIL)
   prlog "  [XFAIL]"

Re: [PATCH 02/14] qcom: mtd: nand: add and initialize QPIC DMA resources

[Archit Taneja]

On 06/29/2017 12:45 PM, Abhishek Sahu wrote:

1. The QPIC NAND uses 3 BAM channels: command, data tx and
data rx while EBI2 NAND uses only single ADM channel.

2. The EBI2 NAND uses normal register read buffer since this
buffer will be remapped with dma_map_sg. The QPIC NAND will give
register read buffer in command descriptor and the command
descriptor will be mapped with dma_map_sg so the register buffer
should be DMA coherent.


It isn't entirely clear from this commit message why we require
reg_read_buf to be DMA coherent for QPIC NAND. Could you please explain this
better?

Besides Marek's comment to splitting the patch, it looks okay to me.

Thanks,
Archit



Signed-off-by: Abhishek Sahu 
---
  .../devicetree/bindings/mtd/qcom_nandc.txt |  25 +++--
  drivers/mtd/nand/qcom_nandc.c  | 106 -
  2 files changed, 99 insertions(+), 32 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
index 5d0f7ae..87b9a56 100644
--- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -9,15 +9,17 @@ Required properties:
  - clock-names:must contain "core" for the core clock and 
"aon" for the
always on clock
  - dmas:   DMA specifier, consisting of a phandle to the 
ADM DMA
-   controller node and the channel number to be used for
-   NAND. Refer to dma.txt and qcom_adm.txt for more details
-- dma-names:   must be "rxtx"
-- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
-   number specified for the NAND controller on the given
-   platform
-- qcom,data-crci:  must contain the ADM data type CRCI block instance
-   number specified for the NAND controller on the given
-   platform
+   or BAM DMA controller node and the channel number to
+   be used for NAND. Refer to dma.txt, qcom_adm.txt(ADM)
+   and qcom/bam_dma.txt(BAM) for more details
+- dma-names:   "rxtx" - ADM
+   "tx", "rx", "cmd" - BAM
+- qcom,cmd-crci:   Only required for ADM DMA. must contain the ADM command
+   type CRCI block instance number specified for the NAND
+   controller on the given platform.
+- qcom,data-crci:  Only required for ADM DMA. must contain the ADM data
+   type CRCI block instance number specified for the NAND
+   controller on the given platform.
  - #address-cells: <1> - subnodes give the chip-select number
  - #size-cells:<0>
  
@@ -95,6 +97,11 @@ nand@79b {

< GCC_QPIC_AHB_CLK>;
clock-names = "core", "aon";
  
+	dmas = < 0>,

+   < 1>,
+   < 2>;
+   dma-names = "tx", "rx", "cmd";
+
#address-cells = <1>;
#size-cells = <0>;
  
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c

index f55f728..520add9 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -226,6 +226,7 @@ struct nandc_regs {
   *by upper layers directly
   * @buf_size/count/start: markers for chip->read_buf/write_buf functions
   * @reg_read_buf: local buffer for reading back registers via DMA
+ * @reg_read_buf_phys: contains dma address for register read buffer
   * @reg_read_pos: marker for data read in reg_read_buf
   *
   * @regs: a contiguous chunk of memory for DMA register
@@ -249,9 +250,19 @@ struct qcom_nand_controller {
struct clk *core_clk;
struct clk *aon_clk;
  
-	struct dma_chan *chan;

-   unsigned int cmd_crci;
-   unsigned int data_crci;
+   union {
+   struct {
+   struct dma_chan *tx_chan;
+   struct dma_chan *rx_chan;
+   struct dma_chan *cmd_chan;
+   };
+   struct {
+   struct dma_chan *chan;
+   unsigned int cmd_crci;
+   unsigned int data_crci;
+   };
+   };
+
struct list_head desc_list;
  
  	u8		*data_buffer;

@@ -261,6 +272,7 @@ struct qcom_nand_controller {
int buf_start;
  
  	__le32 *reg_read_buf;

+   dma_addr_t reg_read_buf_phys;
int reg_read_pos;
  
  	struct nandc_regs *regs;

@@ -1956,16 +1968,48 @@ static int qcom_nandc_alloc(struct qcom_nand_controller 
*nandc)
if (!nandc->regs)
return -ENOMEM;
  
-	nandc->reg_read_buf = devm_kzalloc(nandc->dev,

-   MAX_REG_RD * sizeof(*nandc->reg_read_buf),
-  

Re: [PATCH 02/14] qcom: mtd: nand: add and initialize QPIC DMA resources

[Archit Taneja]

On 06/29/2017 12:45 PM, Abhishek Sahu wrote:

1. The QPIC NAND uses 3 BAM channels: command, data tx and
data rx while EBI2 NAND uses only single ADM channel.

2. The EBI2 NAND uses normal register read buffer since this
buffer will be remapped with dma_map_sg. The QPIC NAND will give
register read buffer in command descriptor and the command
descriptor will be mapped with dma_map_sg so the register buffer
should be DMA coherent.


It isn't entirely clear from this commit message why we require
reg_read_buf to be DMA coherent for QPIC NAND. Could you please explain this
better?

Besides Marek's comment to splitting the patch, it looks okay to me.

Thanks,
Archit



Signed-off-by: Abhishek Sahu 
---
  .../devicetree/bindings/mtd/qcom_nandc.txt |  25 +++--
  drivers/mtd/nand/qcom_nandc.c  | 106 -
  2 files changed, 99 insertions(+), 32 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
index 5d0f7ae..87b9a56 100644
--- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -9,15 +9,17 @@ Required properties:
  - clock-names:must contain "core" for the core clock and 
"aon" for the
always on clock
  - dmas:   DMA specifier, consisting of a phandle to the 
ADM DMA
-   controller node and the channel number to be used for
-   NAND. Refer to dma.txt and qcom_adm.txt for more details
-- dma-names:   must be "rxtx"
-- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
-   number specified for the NAND controller on the given
-   platform
-- qcom,data-crci:  must contain the ADM data type CRCI block instance
-   number specified for the NAND controller on the given
-   platform
+   or BAM DMA controller node and the channel number to
+   be used for NAND. Refer to dma.txt, qcom_adm.txt(ADM)
+   and qcom/bam_dma.txt(BAM) for more details
+- dma-names:   "rxtx" - ADM
+   "tx", "rx", "cmd" - BAM
+- qcom,cmd-crci:   Only required for ADM DMA. must contain the ADM command
+   type CRCI block instance number specified for the NAND
+   controller on the given platform.
+- qcom,data-crci:  Only required for ADM DMA. must contain the ADM data
+   type CRCI block instance number specified for the NAND
+   controller on the given platform.
  - #address-cells: <1> - subnodes give the chip-select number
  - #size-cells:<0>
  
@@ -95,6 +97,11 @@ nand@79b {

< GCC_QPIC_AHB_CLK>;
clock-names = "core", "aon";
  
+	dmas = < 0>,

+   < 1>,
+   < 2>;
+   dma-names = "tx", "rx", "cmd";
+
#address-cells = <1>;
#size-cells = <0>;
  
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c

index f55f728..520add9 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -226,6 +226,7 @@ struct nandc_regs {
   *by upper layers directly
   * @buf_size/count/start: markers for chip->read_buf/write_buf functions
   * @reg_read_buf: local buffer for reading back registers via DMA
+ * @reg_read_buf_phys: contains dma address for register read buffer
   * @reg_read_pos: marker for data read in reg_read_buf
   *
   * @regs: a contiguous chunk of memory for DMA register
@@ -249,9 +250,19 @@ struct qcom_nand_controller {
struct clk *core_clk;
struct clk *aon_clk;
  
-	struct dma_chan *chan;

-   unsigned int cmd_crci;
-   unsigned int data_crci;
+   union {
+   struct {
+   struct dma_chan *tx_chan;
+   struct dma_chan *rx_chan;
+   struct dma_chan *cmd_chan;
+   };
+   struct {
+   struct dma_chan *chan;
+   unsigned int cmd_crci;
+   unsigned int data_crci;
+   };
+   };
+
struct list_head desc_list;
  
  	u8		*data_buffer;

@@ -261,6 +272,7 @@ struct qcom_nand_controller {
int buf_start;
  
  	__le32 *reg_read_buf;

+   dma_addr_t reg_read_buf_phys;
int reg_read_pos;
  
  	struct nandc_regs *regs;

@@ -1956,16 +1968,48 @@ static int qcom_nandc_alloc(struct qcom_nand_controller 
*nandc)
if (!nandc->regs)
return -ENOMEM;
  
-	nandc->reg_read_buf = devm_kzalloc(nandc->dev,

-   MAX_REG_RD * sizeof(*nandc->reg_read_buf),
- 

RE: [PATCH 3/3] ACPI: EC: Change EC noirq tuning to be an optional behavior

[Zheng, Lv]

Hi, Rafael

> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 3/3] ACPI: EC: Change EC noirq tuning to be an optional 
> behavior
> 
> On Wednesday, June 14, 2017 01:59:24 PM Lv Zheng wrote:
> > According to the bug report, though the busy polling mode can make noirq
> > stages executed faster, it causes abnormal fan blowing in noirq stages.
> >
> > This patch prepares an option so that the automatic busy polling mode
> > switching for noirq stages can be enabled by who wants to tune it, not all
> > users.
> > Noticed that the new global option cannot be changed during noirq stages.
> > There is no need to lock its value changes to sync with polling mode
> > settings switches.
> >
> > For reporters and testers in the thread, as there are too many reporters
> > on the bug link, this patch only picks names from most active commenters.
> > Sorry for the neglet.
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181
> > Reported-by: Tatsuyuki Ishi 
> > Reported-by: Claudio Sacerdoti Coen 
> > Tested-by: Nicolo' 
> > Reported-by: Jens Axboe 
> > Tested-by: Gjorgji Jankovski 
> > Tested-by: Damjan Georgievski 
> > Tested-by: Fernando Chaves 
> > Signed-off-by: Lv Zheng 
> 
> First of all, this seems to be a fix for commit c3a696b6e8f8 (ACPI / EC: Use 
> busy polling
> mode when GPE is not enabled), so there should be a Fixes: tag pointing to 
> that
> one.
> 
> Moreover, if that is just a performance optimization and not a matter of 
> correctness,
> why don't we simply drop acpi_ec_enter/leave_noirq() entirely?
> 
> What is going to break if we do that?

Let me Cc Yu for justification.
I just added busy poll support for suspend/boot according to the root cause 
reported by him.
He should know the end user requirements better than me.

Thanks and best regards
Lv

RE: [PATCH 3/3] ACPI: EC: Change EC noirq tuning to be an optional behavior

[Zheng, Lv]

Hi, Rafael

> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Subject: Re: [PATCH 3/3] ACPI: EC: Change EC noirq tuning to be an optional 
> behavior
> 
> On Wednesday, June 14, 2017 01:59:24 PM Lv Zheng wrote:
> > According to the bug report, though the busy polling mode can make noirq
> > stages executed faster, it causes abnormal fan blowing in noirq stages.
> >
> > This patch prepares an option so that the automatic busy polling mode
> > switching for noirq stages can be enabled by who wants to tune it, not all
> > users.
> > Noticed that the new global option cannot be changed during noirq stages.
> > There is no need to lock its value changes to sync with polling mode
> > settings switches.
> >
> > For reporters and testers in the thread, as there are too many reporters
> > on the bug link, this patch only picks names from most active commenters.
> > Sorry for the neglet.
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181
> > Reported-by: Tatsuyuki Ishi 
> > Reported-by: Claudio Sacerdoti Coen 
> > Tested-by: Nicolo' 
> > Reported-by: Jens Axboe 
> > Tested-by: Gjorgji Jankovski 
> > Tested-by: Damjan Georgievski 
> > Tested-by: Fernando Chaves 
> > Signed-off-by: Lv Zheng 
> 
> First of all, this seems to be a fix for commit c3a696b6e8f8 (ACPI / EC: Use 
> busy polling
> mode when GPE is not enabled), so there should be a Fixes: tag pointing to 
> that
> one.
> 
> Moreover, if that is just a performance optimization and not a matter of 
> correctness,
> why don't we simply drop acpi_ec_enter/leave_noirq() entirely?
> 
> What is going to break if we do that?

Let me Cc Yu for justification.
I just added busy poll support for suspend/boot according to the root cause 
reported by him.
He should know the end user requirements better than me.

Thanks and best regards
Lv

Re: [PATCH V2] dmaengine: qcom_hidma: correct API violation for submit

[Vinod Koul]

On Fri, Jun 30, 2017 at 10:43:05AM -0400, Sinan Kaya wrote:
> Current code is violating the DMA Engine API by putting the submitted
> requests directly into the HW queue. This causes queued transactions
> to be started by another thread as soon as the first one finishes.
> 
> The DMA Engine document clearly states this.
> 
> "dmaengine_submit() will not start the DMA operation".
> 
> Move HW queuing of the requests into the issue_pending() routine
> to comply with API requirements also create a new queued state for
> temporarily holding the requests.
> 
> A descriptor goes through these transitions now.
> 
> free->prepared->queued->active->completed->free
> 
> as opposed to
> 
> free->prepared->active->completed->free

Applied, thanks

-- 
~Vinod

Re: [PATCH V2] dmaengine: qcom_hidma: correct API violation for submit

[Vinod Koul]

On Fri, Jun 30, 2017 at 10:43:05AM -0400, Sinan Kaya wrote:
> Current code is violating the DMA Engine API by putting the submitted
> requests directly into the HW queue. This causes queued transactions
> to be started by another thread as soon as the first one finishes.
> 
> The DMA Engine document clearly states this.
> 
> "dmaengine_submit() will not start the DMA operation".
> 
> Move HW queuing of the requests into the issue_pending() routine
> to comply with API requirements also create a new queued state for
> temporarily holding the requests.
> 
> A descriptor goes through these transitions now.
> 
> free->prepared->queued->active->completed->free
> 
> as opposed to
> 
> free->prepared->active->completed->free

Applied, thanks

-- 
~Vinod

Re: [PATCH v2] X86: don't report PAT on CPUs that don't support it

[Mikulas Patocka]

On Tue, 6 Jun 2017, Mikulas Patocka wrote:

> Hi
> 
> Here I send the second version of the patch. It drops the change from 
> boot_cpu_has(X86_FEATURE_PAT) to this_cpu_has(X86_FEATURE_PAT) (that 
> caused kernel to be unbootable for some people).
> 
> Another change is that setup_arch() calls init_cache_modes() if PAT is 
> disabled, so that init_cache_modes() is always called.
> 
> Mikulas

Is there any progress with this patch? Will you accept it or do you want 
some changes to it?

> From: Mikulas Patocka 
> 
> In the file arch/x86/mm/pat.c, there's a variable __pat_enabled. The
> variable is set to 1 by default and the function pat_init() sets
> __pat_enabled to 0 if the CPU doesn't support PAT.
> 
> However, on AMD K6-3 CPU, the processor initialization code never calls
> pat_init() and so __pat_enabled stays 1 and the function pat_enabled()
> returns true, even though the K6-3 CPU doesn't support PAT.
> 
> The result of this bug is that this warning is produced when attemting to
> start the Xserver and the Xserver doesn't start (fork() returns ENOMEM).
> Another symptom of this bug is that the framebuffer driver doesn't set the
> K6-3 MTRR registers.
> 
> This patch changes pat_enabled() so that it returns true only if pat
> initialization was actually done.
> 
> As Andy Lutomirski suggested, we also need to call init_cache_modes() if
> pat was not initialized, so we call it after mtrr_bp_init()
> (mtrr_bp_init() would or wouldn't call pat_init()). Note that
> init_cache_modes() detects if it was called more than once and does
> nothing in that case.
> 
> x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 
> 0xe400-0xe5ff], got write-combining
> [ cut here ]
> WARNING: CPU: 0 PID: 3891 at arch/x86/mm/pat.c:1020 untrack_pfn+0x5c/0x9f
> Modules linked in: blowfish_generic blowfish_common cbc dm_crypt dm_loop msr 
> configfs cpufreq_userspace cpufreq_powersave cpufreq_ondemand 
> cpufreq_conservative ext4 crc16 jbd2 mbcache hpfs nls_cp852 msdos fat 
> matroxfb_base matroxfb_g450 matroxfb_accel cfbfillrect cfbimgblt cfbcopyarea 
> matroxfb_DAC1064 g450_pll matroxfb_misc floppy snd_usb_audio snd_hwdep 
> snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_rawmidi snd_pcm snd_seq 
> snd_seq_device snd_timer hid_generic snd usbhid hid soundcore powernow_k6 
> pcspkr evdev e1000 ehci_pci uhci_hcd ehci_hcd usbcore usb_common dm_mod 
> pata_it821x unix
> CPU: 0 PID: 3891 Comm: Xorg Not tainted 4.11.0-rc6-test+ #35
> Hardware name: System Manufacturer Product Name/VA-503A, BIOS 4.51 PG 08/02/00
> Call Trace:
>  ? __warn+0xab/0xc0
>  ? untrack_pfn+0x5c/0x9f
>  ? warn_slowpath_null+0xf/0x13
>  ? untrack_pfn+0x5c/0x9f
>  ? unmap_single_vma+0x43/0x66
>  ? unmap_vmas+0x24/0x30
>  ? exit_mmap+0x3c/0xa5
>  ? __mmput+0xf/0x76
>  ? copy_process.part.76+0xb43/0x1129
>  ? _do_fork+0x96/0x177
>  ? do_int80_syscall_32+0x3e/0x4c
>  ? entry_INT80_32+0x2a/0x2a
> ---[ end trace 8726f9d9fa90d702 ]---
> x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 
> 0xe400-0xe5ff], got write-combining
> 
> Signed-off-by: Mikulas Patocka 
> Cc: sta...@vger.kernel.org# v4.2+
> 
> ---
>  arch/x86/include/asm/pat.h |1 +
>  arch/x86/kernel/setup.c|2 ++
>  arch/x86/mm/pat.c  |   10 ++
>  3 files changed, 9 insertions(+), 4 deletions(-)
> 
> Index: linux-stable/arch/x86/mm/pat.c
> ===
> --- linux-stable.orig/arch/x86/mm/pat.c
> +++ linux-stable/arch/x86/mm/pat.c
> @@ -40,7 +40,6 @@
>  static bool boot_cpu_done;
>  
>  static int __read_mostly __pat_enabled = IS_ENABLED(CONFIG_X86_PAT);
> -static void init_cache_modes(void);
>  
>  void pat_disable(const char *reason)
>  {
> @@ -65,9 +64,11 @@ static int __init nopat(char *str)
>  }
>  early_param("nopat", nopat);
>  
> +static bool __read_mostly __pat_initialized = false;
> +
>  bool pat_enabled(void)
>  {
> - return !!__pat_enabled;
> + return __pat_initialized;
>  }
>  EXPORT_SYMBOL_GPL(pat_enabled);
>  
> @@ -225,6 +226,7 @@ static void pat_bsp_init(u64 pat)
>   }
>  
>   wrmsrl(MSR_IA32_CR_PAT, pat);
> + __pat_initialized = true;
>  
>   __init_cache_modes(pat);
>  }
> @@ -242,7 +244,7 @@ static void pat_ap_init(u64 pat)
>   wrmsrl(MSR_IA32_CR_PAT, pat);
>  }
>  
> -static void init_cache_modes(void)
> +void init_cache_modes(void)
>  {
>   u64 pat = 0;
>   static int init_cm_done;
> @@ -306,7 +308,7 @@ void pat_init(void)
>   u64 pat;
>   struct cpuinfo_x86 *c = _cpu_data;
>  
> - if (!pat_enabled()) {
> + if (!__pat_enabled) {
>   init_cache_modes();
>   return;
>   }
> Index: linux-stable/arch/x86/include/asm/pat.h
> ===
> --- linux-stable.orig/arch/x86/include/asm/pat.h
> +++ linux-stable/arch/x86/include/asm/pat.h
> @@ -7,6 

Re: [PATCH v2] X86: don't report PAT on CPUs that don't support it

[Mikulas Patocka]

On Tue, 6 Jun 2017, Mikulas Patocka wrote:

> Hi
> 
> Here I send the second version of the patch. It drops the change from 
> boot_cpu_has(X86_FEATURE_PAT) to this_cpu_has(X86_FEATURE_PAT) (that 
> caused kernel to be unbootable for some people).
> 
> Another change is that setup_arch() calls init_cache_modes() if PAT is 
> disabled, so that init_cache_modes() is always called.
> 
> Mikulas

Is there any progress with this patch? Will you accept it or do you want 
some changes to it?

> From: Mikulas Patocka 
> 
> In the file arch/x86/mm/pat.c, there's a variable __pat_enabled. The
> variable is set to 1 by default and the function pat_init() sets
> __pat_enabled to 0 if the CPU doesn't support PAT.
> 
> However, on AMD K6-3 CPU, the processor initialization code never calls
> pat_init() and so __pat_enabled stays 1 and the function pat_enabled()
> returns true, even though the K6-3 CPU doesn't support PAT.
> 
> The result of this bug is that this warning is produced when attemting to
> start the Xserver and the Xserver doesn't start (fork() returns ENOMEM).
> Another symptom of this bug is that the framebuffer driver doesn't set the
> K6-3 MTRR registers.
> 
> This patch changes pat_enabled() so that it returns true only if pat
> initialization was actually done.
> 
> As Andy Lutomirski suggested, we also need to call init_cache_modes() if
> pat was not initialized, so we call it after mtrr_bp_init()
> (mtrr_bp_init() would or wouldn't call pat_init()). Note that
> init_cache_modes() detects if it was called more than once and does
> nothing in that case.
> 
> x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 
> 0xe400-0xe5ff], got write-combining
> [ cut here ]
> WARNING: CPU: 0 PID: 3891 at arch/x86/mm/pat.c:1020 untrack_pfn+0x5c/0x9f
> Modules linked in: blowfish_generic blowfish_common cbc dm_crypt dm_loop msr 
> configfs cpufreq_userspace cpufreq_powersave cpufreq_ondemand 
> cpufreq_conservative ext4 crc16 jbd2 mbcache hpfs nls_cp852 msdos fat 
> matroxfb_base matroxfb_g450 matroxfb_accel cfbfillrect cfbimgblt cfbcopyarea 
> matroxfb_DAC1064 g450_pll matroxfb_misc floppy snd_usb_audio snd_hwdep 
> snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_rawmidi snd_pcm snd_seq 
> snd_seq_device snd_timer hid_generic snd usbhid hid soundcore powernow_k6 
> pcspkr evdev e1000 ehci_pci uhci_hcd ehci_hcd usbcore usb_common dm_mod 
> pata_it821x unix
> CPU: 0 PID: 3891 Comm: Xorg Not tainted 4.11.0-rc6-test+ #35
> Hardware name: System Manufacturer Product Name/VA-503A, BIOS 4.51 PG 08/02/00
> Call Trace:
>  ? __warn+0xab/0xc0
>  ? untrack_pfn+0x5c/0x9f
>  ? warn_slowpath_null+0xf/0x13
>  ? untrack_pfn+0x5c/0x9f
>  ? unmap_single_vma+0x43/0x66
>  ? unmap_vmas+0x24/0x30
>  ? exit_mmap+0x3c/0xa5
>  ? __mmput+0xf/0x76
>  ? copy_process.part.76+0xb43/0x1129
>  ? _do_fork+0x96/0x177
>  ? do_int80_syscall_32+0x3e/0x4c
>  ? entry_INT80_32+0x2a/0x2a
> ---[ end trace 8726f9d9fa90d702 ]---
> x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 
> 0xe400-0xe5ff], got write-combining
> 
> Signed-off-by: Mikulas Patocka 
> Cc: sta...@vger.kernel.org# v4.2+
> 
> ---
>  arch/x86/include/asm/pat.h |1 +
>  arch/x86/kernel/setup.c|2 ++
>  arch/x86/mm/pat.c  |   10 ++
>  3 files changed, 9 insertions(+), 4 deletions(-)
> 
> Index: linux-stable/arch/x86/mm/pat.c
> ===
> --- linux-stable.orig/arch/x86/mm/pat.c
> +++ linux-stable/arch/x86/mm/pat.c
> @@ -40,7 +40,6 @@
>  static bool boot_cpu_done;
>  
>  static int __read_mostly __pat_enabled = IS_ENABLED(CONFIG_X86_PAT);
> -static void init_cache_modes(void);
>  
>  void pat_disable(const char *reason)
>  {
> @@ -65,9 +64,11 @@ static int __init nopat(char *str)
>  }
>  early_param("nopat", nopat);
>  
> +static bool __read_mostly __pat_initialized = false;
> +
>  bool pat_enabled(void)
>  {
> - return !!__pat_enabled;
> + return __pat_initialized;
>  }
>  EXPORT_SYMBOL_GPL(pat_enabled);
>  
> @@ -225,6 +226,7 @@ static void pat_bsp_init(u64 pat)
>   }
>  
>   wrmsrl(MSR_IA32_CR_PAT, pat);
> + __pat_initialized = true;
>  
>   __init_cache_modes(pat);
>  }
> @@ -242,7 +244,7 @@ static void pat_ap_init(u64 pat)
>   wrmsrl(MSR_IA32_CR_PAT, pat);
>  }
>  
> -static void init_cache_modes(void)
> +void init_cache_modes(void)
>  {
>   u64 pat = 0;
>   static int init_cm_done;
> @@ -306,7 +308,7 @@ void pat_init(void)
>   u64 pat;
>   struct cpuinfo_x86 *c = _cpu_data;
>  
> - if (!pat_enabled()) {
> + if (!__pat_enabled) {
>   init_cache_modes();
>   return;
>   }
> Index: linux-stable/arch/x86/include/asm/pat.h
> ===
> --- linux-stable.orig/arch/x86/include/asm/pat.h
> +++ linux-stable/arch/x86/include/asm/pat.h
> @@ -7,6 +7,7 @@
>  bool pat_enabled(void);
>  void 

Re: [PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Janusz Lisiecki]

W dniu 2017-07-02 o 23:23, Luc Van Oostenryck pisze:

On Sun, Jul 2, 2017 at 10:49 PM, Janusz Lisiecki
 wrote:

W dniu 2017-07-02 o 21:38, Luc Van Oostenryck pisze:


On Sun, Jul 2, 2017 at 4:27 PM, Janusz Lisiecki
 wrote:

This patch fixes the following Sparse warnings in ks_wlan_net.c:
drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted
__le16
Both sides of assignment are u16 so (as 'ap' is local_ap_t type and
'capability' member,
have the same as local 'capabilities' type of u16) 'le16_to_cpu' is not
needed

It could be that it's ap->capability's type that is wrong (not
annotated with __le16).
Isn't it?

Is ap->capability supposed to hold a little-endian value or a native
order value?

-- Luc

As I see in ks_hostif.c all assignments to link_ap_info_t->capability threat
this value as native order (i.e get_ap_information, get_current_ap). As this
is not a structure which comes from HW we can do the way you suggested.
Still, as all other places in code threats this as native order value I
decided to change only one place than many other around to fix Sparse
warning.

Fine, but then please put this explanation in the commit message.
In others words, be very clear that the change is because ap->capability is in
native order and thus the conversion le16_to_cpu() is wrong and must be removed.

-- Luc

Done. I hope my message is more verbose and clear this time.

Pozdrawiam,
Janusz Lisiecki


Pozdrawiam,
Janusz Lisiecki

Re: [PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Janusz Lisiecki]

W dniu 2017-07-02 o 23:23, Luc Van Oostenryck pisze:

On Sun, Jul 2, 2017 at 10:49 PM, Janusz Lisiecki
 wrote:

W dniu 2017-07-02 o 21:38, Luc Van Oostenryck pisze:


On Sun, Jul 2, 2017 at 4:27 PM, Janusz Lisiecki
 wrote:

This patch fixes the following Sparse warnings in ks_wlan_net.c:
drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted
__le16
Both sides of assignment are u16 so (as 'ap' is local_ap_t type and
'capability' member,
have the same as local 'capabilities' type of u16) 'le16_to_cpu' is not
needed

It could be that it's ap->capability's type that is wrong (not
annotated with __le16).
Isn't it?

Is ap->capability supposed to hold a little-endian value or a native
order value?

-- Luc

As I see in ks_hostif.c all assignments to link_ap_info_t->capability threat
this value as native order (i.e get_ap_information, get_current_ap). As this
is not a structure which comes from HW we can do the way you suggested.
Still, as all other places in code threats this as native order value I
decided to change only one place than many other around to fix Sparse
warning.

Fine, but then please put this explanation in the commit message.
In others words, be very clear that the change is because ap->capability is in
native order and thus the conversion le16_to_cpu() is wrong and must be removed.

-- Luc

Done. I hope my message is more verbose and clear this time.

Pozdrawiam,
Janusz Lisiecki


Pozdrawiam,
Janusz Lisiecki

[PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Janusz Lisiecki]

This patch fixes the following Sparse warnings in ks_wlan_net.c:
drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted __le16
link_ap_info_t structure field 'capability' has native order and is used 
everywhere
in the code in such way (i.e get_ap_information, get_current_ap). Both sides of
assignment are u16 (native order) so 'le16_to_cpu' is not needed and wrong.

Signed-off-by: Janusz Lisiecki 
---
 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c 
b/drivers/staging/ks7010/ks_wlan_net.c
index 0c778aa..9a7fbe2 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -1356,7 +1356,7 @@ static inline char *ks_wlan_translate_scan(struct 
net_device *dev,
 
/* Add mode */
iwe.cmd = SIOCGIWMODE;
-   capabilities = le16_to_cpu(ap->capability);
+   capabilities = ap->capability;
if (capabilities & (BSS_CAP_ESS | BSS_CAP_IBSS)) {
if (capabilities & BSS_CAP_ESS)
iwe.u.mode = IW_MODE_INFRA;
-- 
1.9.1

[PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Janusz Lisiecki]

This patch fixes the following Sparse warnings in ks_wlan_net.c:
drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted __le16
link_ap_info_t structure field 'capability' has native order and is used 
everywhere
in the code in such way (i.e get_ap_information, get_current_ap). Both sides of
assignment are u16 (native order) so 'le16_to_cpu' is not needed and wrong.

Signed-off-by: Janusz Lisiecki 
---
 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c 
b/drivers/staging/ks7010/ks_wlan_net.c
index 0c778aa..9a7fbe2 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -1356,7 +1356,7 @@ static inline char *ks_wlan_translate_scan(struct 
net_device *dev,
 
/* Add mode */
iwe.cmd = SIOCGIWMODE;
-   capabilities = le16_to_cpu(ap->capability);
+   capabilities = ap->capability;
if (capabilities & (BSS_CAP_ESS | BSS_CAP_IBSS)) {
if (capabilities & BSS_CAP_ESS)
iwe.u.mode = IW_MODE_INFRA;
-- 
1.9.1

[PATCH 0/1] Fix cast to restricted __le16 in ks7010 driver

[Janusz Lisiecki]

This patch fixes Sparse warining found in ks_wlan_net.c. This seems
to be last of it reported by Sparse for that driver.
link_ap_info_t structure field 'capability' has native order and is
used everywhere in the code in such way (i.e get_ap_information,
get_current_ap), so le16_to_cpu() on it is wrong and must be removed.
As this is not HW related structure we are free to choose its byte
order and it is easier just to remove one wrong casting than rework
all other places to treat it as __le16.

Janusz Lisiecki (1):
  staging: ks7010: Fix warning of cast to restricted __le16 in
ks_wlan_net.c

 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.9.1

[PATCH 0/1] Fix cast to restricted __le16 in ks7010 driver

[Janusz Lisiecki]

This patch fixes Sparse warining found in ks_wlan_net.c. This seems
to be last of it reported by Sparse for that driver.
link_ap_info_t structure field 'capability' has native order and is
used everywhere in the code in such way (i.e get_ap_information,
get_current_ap), so le16_to_cpu() on it is wrong and must be removed.
As this is not HW related structure we are free to choose its byte
order and it is easier just to remove one wrong casting than rework
all other places to treat it as __le16.

Janusz Lisiecki (1):
  staging: ks7010: Fix warning of cast to restricted __le16 in
ks_wlan_net.c

 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.9.1

Re: [PATCH 01/14] qcom: mtd: nand: Add driver data for QPIC DMA

[Archit Taneja]

On 06/29/2017 12:45 PM, Abhishek Sahu wrote:

The current driver only support EBI2 NAND which uses ADM DMA. The
latest QCOM controller supports QPIC NAND which uses BAM DMA. NAND
registers and programming sequence are same for EBI2 and QPIC
NAND so the same driver can support QPIC NAND also by adding the
BAM DMA support. This patch adds the QPIC NAND support in current
NAND driver with compatible string "qcom,qpic-nandc-v1.4.0" and
maps it with different configuration parameter in driver data.

Signed-off-by: Abhishek Sahu 
---
  .../devicetree/bindings/mtd/qcom_nandc.txt | 41 +-
  drivers/mtd/nand/qcom_nandc.c  | 37 ---
  2 files changed, 73 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
index 70dd511..5d0f7ae 100644
--- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -1,7 +1,9 @@
  * Qualcomm NAND controller
  
  Required properties:

-- compatible:  should be "qcom,ipq806x-nand"


Since you're changing the compatible string, could you mention in the commit 
message that
it's okay to do so since there aren't any upstream dtsi files using this 
binding?


+- compatible:  must be one of the following:
+   * "qcom,ebi2-nandc" - EBI2 NAND which uses ADM DMA like IPQ8064.


Are we sure that all EBI2 based NAND controllers would work by this single 
binding?
Should we put a version here too like we've done for QPIC?


+   * "qcom,qpic-nandc-v1.4.0" - QPIC NAND v1.4.0 which uses BAM DMA like 
IPQ4019.
  - reg:MMIO address range
  - clocks: must contain core clock and always on clock
  - clock-names:must contain "core" for the core clock and 
"aon" for the
@@ -84,3 +86,40 @@ nand@1ac0 {
};
};
  };
+
+nand@79b {
+   compatible = "qcom,qpic-nandc-v1.4.0";
+   reg = <0x79b 0x1000>;
+
+   clocks = < GCC_QPIC_CLK>,
+   < GCC_QPIC_AHB_CLK>;
+   clock-names = "core", "aon";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   nandcs@0 {
+   compatible = "qcom,nandcs";
+   reg = <0>;
+
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <8>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "boot-nand";
+   reg = <0 0x58a>;
+   };
+
+   partition@58a {
+   label = "fs-nand";
+   reg = <0x58a 0x400>;
+   };
+   };
+   };
+};
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index 57d483a..f55f728 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved.
   *
   * This software is licensed under the terms of the GNU General Public
   * License version 2, as published by the Free Software Foundation, and
@@ -234,6 +234,8 @@ struct nandc_regs {
   * @cmd1/vld: some fixed controller register values
   * @ecc_modes:supported ECC modes by the current 
controller,
   *initialized via DT match data
+ * @dma_bam_enabled:   flag to tell whether nand controller is using
+ * bam dma
   */
  struct qcom_nand_controller {
struct nand_hw_control controller;
@@ -253,6 +255,7 @@ struct qcom_nand_controller {
struct list_head desc_list;
  
  	u8		*data_buffer;

+   booldma_bam_enabled;
int buf_size;
int buf_count;
int buf_start;
@@ -316,6 +319,17 @@ struct qcom_nand_host {
u32 clrreadstatus;
  };
  
+/*

+ * This data type corresponds to the nand driver data which will be used at
+ * driver probe time
+ * @ecc_modes - ecc mode for nand
+ * @dma_bam_enabled - whether this driver is using bam
+ */
+struct qcom_nand_driver_data {
+   u32 ecc_modes;
+   bool dma_bam_enabled;
+};
+
  static inline struct qcom_nand_host *to_qcom_nand_host(struct nand_chip *chip)
  {
return container_of(chip, struct qcom_nand_host, chip);
@@ -2073,6 +2087,7 @@ static int qcom_nandc_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node, *child;
struct resource *res;
int ret;
+   const struct qcom_nand_driver_data 

Re: [PATCH 01/14] qcom: mtd: nand: Add driver data for QPIC DMA

[Archit Taneja]

On 06/29/2017 12:45 PM, Abhishek Sahu wrote:

The current driver only support EBI2 NAND which uses ADM DMA. The
latest QCOM controller supports QPIC NAND which uses BAM DMA. NAND
registers and programming sequence are same for EBI2 and QPIC
NAND so the same driver can support QPIC NAND also by adding the
BAM DMA support. This patch adds the QPIC NAND support in current
NAND driver with compatible string "qcom,qpic-nandc-v1.4.0" and
maps it with different configuration parameter in driver data.

Signed-off-by: Abhishek Sahu 
---
  .../devicetree/bindings/mtd/qcom_nandc.txt | 41 +-
  drivers/mtd/nand/qcom_nandc.c  | 37 ---
  2 files changed, 73 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
index 70dd511..5d0f7ae 100644
--- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -1,7 +1,9 @@
  * Qualcomm NAND controller
  
  Required properties:

-- compatible:  should be "qcom,ipq806x-nand"


Since you're changing the compatible string, could you mention in the commit 
message that
it's okay to do so since there aren't any upstream dtsi files using this 
binding?


+- compatible:  must be one of the following:
+   * "qcom,ebi2-nandc" - EBI2 NAND which uses ADM DMA like IPQ8064.


Are we sure that all EBI2 based NAND controllers would work by this single 
binding?
Should we put a version here too like we've done for QPIC?


+   * "qcom,qpic-nandc-v1.4.0" - QPIC NAND v1.4.0 which uses BAM DMA like 
IPQ4019.
  - reg:MMIO address range
  - clocks: must contain core clock and always on clock
  - clock-names:must contain "core" for the core clock and 
"aon" for the
@@ -84,3 +86,40 @@ nand@1ac0 {
};
};
  };
+
+nand@79b {
+   compatible = "qcom,qpic-nandc-v1.4.0";
+   reg = <0x79b 0x1000>;
+
+   clocks = < GCC_QPIC_CLK>,
+   < GCC_QPIC_AHB_CLK>;
+   clock-names = "core", "aon";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   nandcs@0 {
+   compatible = "qcom,nandcs";
+   reg = <0>;
+
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <8>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "boot-nand";
+   reg = <0 0x58a>;
+   };
+
+   partition@58a {
+   label = "fs-nand";
+   reg = <0x58a 0x400>;
+   };
+   };
+   };
+};
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index 57d483a..f55f728 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved.
   *
   * This software is licensed under the terms of the GNU General Public
   * License version 2, as published by the Free Software Foundation, and
@@ -234,6 +234,8 @@ struct nandc_regs {
   * @cmd1/vld: some fixed controller register values
   * @ecc_modes:supported ECC modes by the current 
controller,
   *initialized via DT match data
+ * @dma_bam_enabled:   flag to tell whether nand controller is using
+ * bam dma
   */
  struct qcom_nand_controller {
struct nand_hw_control controller;
@@ -253,6 +255,7 @@ struct qcom_nand_controller {
struct list_head desc_list;
  
  	u8		*data_buffer;

+   booldma_bam_enabled;
int buf_size;
int buf_count;
int buf_start;
@@ -316,6 +319,17 @@ struct qcom_nand_host {
u32 clrreadstatus;
  };
  
+/*

+ * This data type corresponds to the nand driver data which will be used at
+ * driver probe time
+ * @ecc_modes - ecc mode for nand
+ * @dma_bam_enabled - whether this driver is using bam
+ */
+struct qcom_nand_driver_data {
+   u32 ecc_modes;
+   bool dma_bam_enabled;
+};
+
  static inline struct qcom_nand_host *to_qcom_nand_host(struct nand_chip *chip)
  {
return container_of(chip, struct qcom_nand_host, chip);
@@ -2073,6 +2087,7 @@ static int qcom_nandc_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node, *child;
struct resource *res;
int ret;
+   const struct qcom_nand_driver_data *driver_data;
  
  	nandc = 

[PATCH v3 3/3] hwmon: ltc2990: support all measurement modes

[Tom Levens]

Updated version of the ltc2990 driver which supports all measurement
modes (current, voltage, temperature) available in the chip.

If devicetree is used, the mode must be specified with the property
"lltc,meas-mode". The format and possible values of the property are
described in the binding.

If devicetree is not used, the mode of the chip will not be configured.
Unless the chip is configured by another source, only the internal
temperature and supply voltage will be measured.

Signed-off-by: Tom Levens 
---
 Documentation/hwmon/ltc2990 |  24 --
 drivers/hwmon/Kconfig   |   7 +-
 drivers/hwmon/ltc2990.c | 196 +---
 3 files changed, 185 insertions(+), 42 deletions(-)

diff --git a/Documentation/hwmon/ltc2990 b/Documentation/hwmon/ltc2990
index c25211e..3ed68f6 100644
--- a/Documentation/hwmon/ltc2990
+++ b/Documentation/hwmon/ltc2990
@@ -8,6 +8,7 @@ Supported chips:
 Datasheet: http://www.linear.com/product/ltc2990
 
 Author: Mike Looijmans 
+Tom Levens 
 
 
 Description
@@ -16,10 +17,8 @@ Description
 LTC2990 is a Quad I2C Voltage, Current and Temperature Monitor.
 The chip's inputs can measure 4 voltages, or two inputs together (1+2 and 3+4)
 can be combined to measure a differential voltage, which is typically used to
-measure current through a series resistor, or a temperature.
-
-This driver currently uses the 2x differential mode only. In order to support
-other modes, the driver will need to be expanded.
+measure current through a series resistor, or a temperature with an external
+diode.
 
 
 Usage Notes
@@ -32,12 +31,19 @@ devices explicitly.
 Sysfs attributes
 
 
+in0_input Voltage at Vcc pin in millivolt (range 2.5V to 5V)
+temp1_input   Internal chip temperature in millidegrees Celcius
+
+A subset of the following attributes are visible, depending on the measurement
+mode of the chip.
+
+in[1-4]_input Voltage at V[1-4] pin in millivolt
+temp2_input   External temperature sensor TR1 in millidegrees Celcius
+temp3_input   External temperature sensor TR2 in millidegrees Celcius
+curr1_input   Current in mA across V1-V2 assuming a 1mOhm sense resistor
+curr2_input   Current in mA across V3-V4 assuming a 1mOhm sense resistor
+
 The "curr*_input" measurements actually report the voltage drop across the
 input pins in microvolts. This is equivalent to the current through a 1mOhm
 sense resistor. Divide the reported value by the actual sense resistor value
 in mOhm to get the actual value.
-
-in0_input Voltage at Vcc pin in millivolt (range 2.5V to 5V)
-temp1_input   Internal chip temperature in millidegrees Celcius
-curr1_input   Current in mA across v1-v2 assuming a 1mOhm sense resistor.
-curr2_input   Current in mA across v3-v4 assuming a 1mOhm sense resistor.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5ef2814..578e5a9 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -709,15 +709,12 @@ config SENSORS_LTC2945
  be called ltc2945.
 
 config SENSORS_LTC2990
-   tristate "Linear Technology LTC2990 (current monitoring mode only)"
+   tristate "Linear Technology LTC2990"
depends on I2C
help
  If you say yes here you get support for Linear Technology LTC2990
  I2C System Monitor. The LTC2990 supports a combination of voltage,
- current and temperature monitoring, but in addition to the Vcc supply
- voltage and chip temperature, this driver currently only supports
- reading two currents by measuring two differential voltages across
- series resistors.
+ current and temperature monitoring.
 
  This driver can also be built as a module. If so, the module will
  be called ltc2990.
diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
index e320d21..32f3a8d 100644
--- a/drivers/hwmon/ltc2990.c
+++ b/drivers/hwmon/ltc2990.c
@@ -5,10 +5,6 @@
  * Author: Mike Looijmans 
  *
  * License: GPLv2
- *
- * This driver assumes the chip is wired as a dual current monitor, and
- * reports the voltage drop across two series resistors. It also reports
- * the chip's internal temperature and Vcc power supply voltage.
  */
 
 #include 
@@ -18,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define LTC2990_STATUS 0x00
 #define LTC2990_CONTROL0x01
@@ -29,35 +26,109 @@
 #define LTC2990_V4_MSB 0x0C
 #define LTC2990_VCC_MSB0x0E
 
-#define LTC2990_CONTROL_KELVIN BIT(7)
-#define LTC2990_CONTROL_SINGLE BIT(6)
-#define LTC2990_CONTROL_MEASURE_ALL(0x3 << 3)
-#define LTC2990_CONTROL_MODE_CURRENT   0x06
-#define LTC2990_CONTROL_MODE_VOLTAGE   0x07
+#define LTC2990_IN0BIT(0)
+#define LTC2990_IN1BIT(1)
+#define LTC2990_IN2BIT(2)
+#define LTC2990_IN3BIT(3)
+#define LTC2990_IN4BIT(4)
+#define LTC2990_CURR1  BIT(5)
+#define LTC2990_CURR2  BIT(6)
+#define 

[PATCH v3 3/3] hwmon: ltc2990: support all measurement modes

[Tom Levens]

Updated version of the ltc2990 driver which supports all measurement
modes (current, voltage, temperature) available in the chip.

If devicetree is used, the mode must be specified with the property
"lltc,meas-mode". The format and possible values of the property are
described in the binding.

If devicetree is not used, the mode of the chip will not be configured.
Unless the chip is configured by another source, only the internal
temperature and supply voltage will be measured.

Signed-off-by: Tom Levens 
---
 Documentation/hwmon/ltc2990 |  24 --
 drivers/hwmon/Kconfig   |   7 +-
 drivers/hwmon/ltc2990.c | 196 +---
 3 files changed, 185 insertions(+), 42 deletions(-)

diff --git a/Documentation/hwmon/ltc2990 b/Documentation/hwmon/ltc2990
index c25211e..3ed68f6 100644
--- a/Documentation/hwmon/ltc2990
+++ b/Documentation/hwmon/ltc2990
@@ -8,6 +8,7 @@ Supported chips:
 Datasheet: http://www.linear.com/product/ltc2990
 
 Author: Mike Looijmans 
+Tom Levens 
 
 
 Description
@@ -16,10 +17,8 @@ Description
 LTC2990 is a Quad I2C Voltage, Current and Temperature Monitor.
 The chip's inputs can measure 4 voltages, or two inputs together (1+2 and 3+4)
 can be combined to measure a differential voltage, which is typically used to
-measure current through a series resistor, or a temperature.
-
-This driver currently uses the 2x differential mode only. In order to support
-other modes, the driver will need to be expanded.
+measure current through a series resistor, or a temperature with an external
+diode.
 
 
 Usage Notes
@@ -32,12 +31,19 @@ devices explicitly.
 Sysfs attributes
 
 
+in0_input Voltage at Vcc pin in millivolt (range 2.5V to 5V)
+temp1_input   Internal chip temperature in millidegrees Celcius
+
+A subset of the following attributes are visible, depending on the measurement
+mode of the chip.
+
+in[1-4]_input Voltage at V[1-4] pin in millivolt
+temp2_input   External temperature sensor TR1 in millidegrees Celcius
+temp3_input   External temperature sensor TR2 in millidegrees Celcius
+curr1_input   Current in mA across V1-V2 assuming a 1mOhm sense resistor
+curr2_input   Current in mA across V3-V4 assuming a 1mOhm sense resistor
+
 The "curr*_input" measurements actually report the voltage drop across the
 input pins in microvolts. This is equivalent to the current through a 1mOhm
 sense resistor. Divide the reported value by the actual sense resistor value
 in mOhm to get the actual value.
-
-in0_input Voltage at Vcc pin in millivolt (range 2.5V to 5V)
-temp1_input   Internal chip temperature in millidegrees Celcius
-curr1_input   Current in mA across v1-v2 assuming a 1mOhm sense resistor.
-curr2_input   Current in mA across v3-v4 assuming a 1mOhm sense resistor.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5ef2814..578e5a9 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -709,15 +709,12 @@ config SENSORS_LTC2945
  be called ltc2945.
 
 config SENSORS_LTC2990
-   tristate "Linear Technology LTC2990 (current monitoring mode only)"
+   tristate "Linear Technology LTC2990"
depends on I2C
help
  If you say yes here you get support for Linear Technology LTC2990
  I2C System Monitor. The LTC2990 supports a combination of voltage,
- current and temperature monitoring, but in addition to the Vcc supply
- voltage and chip temperature, this driver currently only supports
- reading two currents by measuring two differential voltages across
- series resistors.
+ current and temperature monitoring.
 
  This driver can also be built as a module. If so, the module will
  be called ltc2990.
diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
index e320d21..32f3a8d 100644
--- a/drivers/hwmon/ltc2990.c
+++ b/drivers/hwmon/ltc2990.c
@@ -5,10 +5,6 @@
  * Author: Mike Looijmans 
  *
  * License: GPLv2
- *
- * This driver assumes the chip is wired as a dual current monitor, and
- * reports the voltage drop across two series resistors. It also reports
- * the chip's internal temperature and Vcc power supply voltage.
  */
 
 #include 
@@ -18,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define LTC2990_STATUS 0x00
 #define LTC2990_CONTROL0x01
@@ -29,35 +26,109 @@
 #define LTC2990_V4_MSB 0x0C
 #define LTC2990_VCC_MSB0x0E
 
-#define LTC2990_CONTROL_KELVIN BIT(7)
-#define LTC2990_CONTROL_SINGLE BIT(6)
-#define LTC2990_CONTROL_MEASURE_ALL(0x3 << 3)
-#define LTC2990_CONTROL_MODE_CURRENT   0x06
-#define LTC2990_CONTROL_MODE_VOLTAGE   0x07
+#define LTC2990_IN0BIT(0)
+#define LTC2990_IN1BIT(1)
+#define LTC2990_IN2BIT(2)
+#define LTC2990_IN3BIT(3)
+#define LTC2990_IN4BIT(4)
+#define LTC2990_CURR1  BIT(5)
+#define LTC2990_CURR2  BIT(6)
+#define LTC2990_TEMP1  BIT(7)
+#define LTC2990_TEMP2  BIT(8)
+#define LTC2990_TEMP3  BIT(9)

[PATCH v3 2/3] hwmon: ltc2990: add devicetree binding

[Tom Levens]

Add a devicetree binding for the ltc2990 hwmon driver.

Signed-off-by: Tom Levens 
---
 .../devicetree/bindings/hwmon/ltc2990.txt  | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/ltc2990.txt

diff --git a/Documentation/devicetree/bindings/hwmon/ltc2990.txt 
b/Documentation/devicetree/bindings/hwmon/ltc2990.txt
new file mode 100644
index 000..f92f540
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ltc2990.txt
@@ -0,0 +1,36 @@
+ltc2990: Linear Technology LTC2990 power monitor
+
+Required properties:
+- compatible: Must be "lltc,ltc2990"
+- reg: I2C slave address
+- lltc,meas-mode:
+   An array of two integers for configuring the chip measurement mode.
+
+   The first integer defines the bits 2..0 in the control register. In all
+   cases the internal temperature and supply voltage are measured. In
+   addition the following input measurements are enabled per mode:
+
+   0: V1, V2, TR2
+   1: V1-V2, TR2
+   2: V1-V2, V3, V4
+   3: TR1, V3, V4
+   4: TR1, V3-V4
+   5: TR1, TR2
+   6: V1-V2, V3-V4
+   7: V1, V2, V3, V4
+
+   The second integer defines the bits 4..3 in the control register. This
+   allows a subset of the measurements to be enabled:
+
+   0: Internal temperature and supply voltage only
+   1: TR1, V1 or V1-V2 only per mode
+   2: TR2, V3 or V3-V4 only per mode
+   3: All measurements per mode
+
+Example:
+
+ltc2990@4c {
+   compatible = "lltc,ltc2990";
+   reg = <0x4c>;
+   lltc,meas-mode = <7 3>; /* V1, V2, V3, V4 */
+};
-- 
1.8.3.1

[PATCH v3 2/3] hwmon: ltc2990: add devicetree binding

[Tom Levens]

Add a devicetree binding for the ltc2990 hwmon driver.

Signed-off-by: Tom Levens 
---
 .../devicetree/bindings/hwmon/ltc2990.txt  | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/ltc2990.txt

diff --git a/Documentation/devicetree/bindings/hwmon/ltc2990.txt 
b/Documentation/devicetree/bindings/hwmon/ltc2990.txt
new file mode 100644
index 000..f92f540
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ltc2990.txt
@@ -0,0 +1,36 @@
+ltc2990: Linear Technology LTC2990 power monitor
+
+Required properties:
+- compatible: Must be "lltc,ltc2990"
+- reg: I2C slave address
+- lltc,meas-mode:
+   An array of two integers for configuring the chip measurement mode.
+
+   The first integer defines the bits 2..0 in the control register. In all
+   cases the internal temperature and supply voltage are measured. In
+   addition the following input measurements are enabled per mode:
+
+   0: V1, V2, TR2
+   1: V1-V2, TR2
+   2: V1-V2, V3, V4
+   3: TR1, V3, V4
+   4: TR1, V3-V4
+   5: TR1, TR2
+   6: V1-V2, V3-V4
+   7: V1, V2, V3, V4
+
+   The second integer defines the bits 4..3 in the control register. This
+   allows a subset of the measurements to be enabled:
+
+   0: Internal temperature and supply voltage only
+   1: TR1, V1 or V1-V2 only per mode
+   2: TR2, V3 or V3-V4 only per mode
+   3: All measurements per mode
+
+Example:
+
+ltc2990@4c {
+   compatible = "lltc,ltc2990";
+   reg = <0x4c>;
+   lltc,meas-mode = <7 3>; /* V1, V2, V3, V4 */
+};
-- 
1.8.3.1

[PATCH v3 1/3] hwmon: ltc2990: refactor value conversion

[Tom Levens]

Conversion from raw values to signed integers has been refactored using
bitops.h. This also fixes a bug where negative temperatures were
converted incorrectly.

Signed-off-by: Tom Levens 
---
 drivers/hwmon/ltc2990.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
index 8f8fe05..e320d21 100644
--- a/drivers/hwmon/ltc2990.c
+++ b/drivers/hwmon/ltc2990.c
@@ -11,6 +11,7 @@
  * the chip's internal temperature and Vcc power supply voltage.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -34,15 +35,6 @@
 #define LTC2990_CONTROL_MODE_CURRENT   0x06
 #define LTC2990_CONTROL_MODE_VOLTAGE   0x07
 
-/* convert raw register value to sign-extended integer in 16-bit range */
-static int ltc2990_voltage_to_int(int raw)
-{
-   if (raw & BIT(14))
-   return -(0x4000 - (raw & 0x3FFF)) << 2;
-   else
-   return (raw & 0x3FFF) << 2;
-}
-
 /* Return the converted value from the given register in uV or mC */
 static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, int *result)
 {
@@ -55,18 +47,16 @@ static int ltc2990_get_value(struct i2c_client *i2c, u8 
reg, int *result)
switch (reg) {
case LTC2990_TINT_MSB:
/* internal temp, 0.0625 degrees/LSB, 13-bit  */
-   val = (val & 0x1FFF) << 3;
-   *result = (val * 1000) >> 7;
+   *result = sign_extend32(val, 12) * 1000 / 16;
break;
case LTC2990_V1_MSB:
case LTC2990_V3_MSB:
 /* Vx-Vy, 19.42uV/LSB. Depends on mode. */
-   *result = ltc2990_voltage_to_int(val) * 1942 / (4 * 100);
+   *result = sign_extend32(val, 14) * 1942 / 100;
break;
case LTC2990_VCC_MSB:
/* Vcc, 305.18μV/LSB, 2.5V offset */
-   *result = (ltc2990_voltage_to_int(val) * 30518 /
-  (4 * 100 * 1000)) + 2500;
+   *result = sign_extend32(val, 14) * 30518 / (100 * 1000) + 2500;
break;
default:
return -EINVAL; /* won't happen, keep compiler happy */
-- 
1.8.3.1

[PATCH v3 1/3] hwmon: ltc2990: refactor value conversion

[Tom Levens]

Conversion from raw values to signed integers has been refactored using
bitops.h. This also fixes a bug where negative temperatures were
converted incorrectly.

Signed-off-by: Tom Levens 
---
 drivers/hwmon/ltc2990.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
index 8f8fe05..e320d21 100644
--- a/drivers/hwmon/ltc2990.c
+++ b/drivers/hwmon/ltc2990.c
@@ -11,6 +11,7 @@
  * the chip's internal temperature and Vcc power supply voltage.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -34,15 +35,6 @@
 #define LTC2990_CONTROL_MODE_CURRENT   0x06
 #define LTC2990_CONTROL_MODE_VOLTAGE   0x07
 
-/* convert raw register value to sign-extended integer in 16-bit range */
-static int ltc2990_voltage_to_int(int raw)
-{
-   if (raw & BIT(14))
-   return -(0x4000 - (raw & 0x3FFF)) << 2;
-   else
-   return (raw & 0x3FFF) << 2;
-}
-
 /* Return the converted value from the given register in uV or mC */
 static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, int *result)
 {
@@ -55,18 +47,16 @@ static int ltc2990_get_value(struct i2c_client *i2c, u8 
reg, int *result)
switch (reg) {
case LTC2990_TINT_MSB:
/* internal temp, 0.0625 degrees/LSB, 13-bit  */
-   val = (val & 0x1FFF) << 3;
-   *result = (val * 1000) >> 7;
+   *result = sign_extend32(val, 12) * 1000 / 16;
break;
case LTC2990_V1_MSB:
case LTC2990_V3_MSB:
 /* Vx-Vy, 19.42uV/LSB. Depends on mode. */
-   *result = ltc2990_voltage_to_int(val) * 1942 / (4 * 100);
+   *result = sign_extend32(val, 14) * 1942 / 100;
break;
case LTC2990_VCC_MSB:
/* Vcc, 305.18μV/LSB, 2.5V offset */
-   *result = (ltc2990_voltage_to_int(val) * 30518 /
-  (4 * 100 * 1000)) + 2500;
+   *result = sign_extend32(val, 14) * 30518 / (100 * 1000) + 2500;
break;
default:
return -EINVAL; /* won't happen, keep compiler happy */
-- 
1.8.3.1

Re: [linux-next][PATCH] usb: dwc3: omap: remove IRQ_NOAUTOEN used with shared irq

[Vignesh R]

Hi,

On Saturday 01 July 2017 01:04 AM, Strashko, Grygorii wrote:
> 
> 
> On 06/29/2017 01:03 AM, Tony Lindgren wrote:
>> * Vignesh R  [170628 21:21]:
>>>
>>>
>>> On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote:
 IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers
 warning if it happns, since commit 04c848d39879 ("genirq: Warn when
 IRQ_NOAUTOEN is used with shared interrupts"). And this is the case for
 OMAP DWC 3 driver.

 Hence, remove IRQ_NOAUTOEN flag and instead call disable_irq() before
 disabling PM runtime in probe error path handling.
>>>
>>> Or, how about requesting the irq at the end of probe after extcon
>>> registration?
>>
>> Hmm yeah, what prevents the issue that we tried to fix with commit
>> 12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with irq handler
>> in probe")?
> 
> No, I think. There should be the disable_irq() call any way
> before pm_runtime_put_sync(dev);| pm_runtime_disable(dev); -
> once IRQ is requested driver can't know if IRQ handler is running now or not
> unless it will call disable_irq()/free_irq().
> 
> But, I've also thought about moving request_irq() down (seems
> it can be moved even after of_platform_populate()).
> looks like it can be separate patch.
> 

commit 12a7f17fac5b says PM runtime can race with IRQ handler when
deferred probing happening due to extcon, therefore IRQ_NOAUTOEN was set
and disable_irq() call was added. If IRQ handler registration is moved
to a place after of_platform_populate(), then we can be sure that extcon
is registered and there wont be any deferred probe or race with irq
handler and PM runtime. Would disable_irq() still be needed then?

> 
 Fixes: 12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with...")
 Signed-off-by: Grygorii Strashko 
 ---
   drivers/usb/dwc3/dwc3-omap.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
 index 9892650..cd9bef5 100644
 --- a/drivers/usb/dwc3/dwc3-omap.c
 +++ b/drivers/usb/dwc3/dwc3-omap.c
 @@ -512,7 +512,6 @@ static int dwc3_omap_probe(struct platform_device 
 *pdev)
   
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
 -  irq_set_status_flags(omap->irq, IRQ_NOAUTOEN);
ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
dwc3_omap_interrupt_thread, IRQF_SHARED,
"dwc3-omap", omap);
 @@ -533,10 +532,10 @@ static int dwc3_omap_probe(struct platform_device 
 *pdev)
}
   
dwc3_omap_enable_irqs(omap);
 -  enable_irq(omap->irq);
return 0;
   
   err1:
 +  disable_irq(omap->irq);
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
   
> 

-- 
Regards
Vignesh

Re: [linux-next][PATCH] usb: dwc3: omap: remove IRQ_NOAUTOEN used with shared irq

[Vignesh R]

Hi,

On Saturday 01 July 2017 01:04 AM, Strashko, Grygorii wrote:
> 
> 
> On 06/29/2017 01:03 AM, Tony Lindgren wrote:
>> * Vignesh R  [170628 21:21]:
>>>
>>>
>>> On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote:
 IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers
 warning if it happns, since commit 04c848d39879 ("genirq: Warn when
 IRQ_NOAUTOEN is used with shared interrupts"). And this is the case for
 OMAP DWC 3 driver.

 Hence, remove IRQ_NOAUTOEN flag and instead call disable_irq() before
 disabling PM runtime in probe error path handling.
>>>
>>> Or, how about requesting the irq at the end of probe after extcon
>>> registration?
>>
>> Hmm yeah, what prevents the issue that we tried to fix with commit
>> 12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with irq handler
>> in probe")?
> 
> No, I think. There should be the disable_irq() call any way
> before pm_runtime_put_sync(dev);| pm_runtime_disable(dev); -
> once IRQ is requested driver can't know if IRQ handler is running now or not
> unless it will call disable_irq()/free_irq().
> 
> But, I've also thought about moving request_irq() down (seems
> it can be moved even after of_platform_populate()).
> looks like it can be separate patch.
> 

commit 12a7f17fac5b says PM runtime can race with IRQ handler when
deferred probing happening due to extcon, therefore IRQ_NOAUTOEN was set
and disable_irq() call was added. If IRQ handler registration is moved
to a place after of_platform_populate(), then we can be sure that extcon
is registered and there wont be any deferred probe or race with irq
handler and PM runtime. Would disable_irq() still be needed then?

> 
 Fixes: 12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with...")
 Signed-off-by: Grygorii Strashko 
 ---
   drivers/usb/dwc3/dwc3-omap.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
 index 9892650..cd9bef5 100644
 --- a/drivers/usb/dwc3/dwc3-omap.c
 +++ b/drivers/usb/dwc3/dwc3-omap.c
 @@ -512,7 +512,6 @@ static int dwc3_omap_probe(struct platform_device 
 *pdev)
   
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
 -  irq_set_status_flags(omap->irq, IRQ_NOAUTOEN);
ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
dwc3_omap_interrupt_thread, IRQF_SHARED,
"dwc3-omap", omap);
 @@ -533,10 +532,10 @@ static int dwc3_omap_probe(struct platform_device 
 *pdev)
}
   
dwc3_omap_enable_irqs(omap);
 -  enable_irq(omap->irq);
return 0;
   
   err1:
 +  disable_irq(omap->irq);
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
   
> 

-- 
Regards
Vignesh

Re: [PATCH] PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11

[Chen Yu]

Hi,
On Sun, Jul 02, 2017 at 03:59:48PM -0500, Bjorn Helgaas wrote:
> Neither soft poweroff (transition to ACPI power state S5) nor
> suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and
> 11,5.
> 
> The problem is related to the [mem 0x7fa0-0x7fbf] space.  When we
> use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI
> Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn't work
> anymore.
> 
> Linux does a soft poweroff (transition to S5) by writing to PM1_CNT.  The
> theory about why this doesn't work is:
> 
>   - The write to PM1_CNT causes an SMI
>   - The BIOS SMI handler depends on something in
> [mem 0x7fa0-0x7fbf]
>   - When Linux assigns [mem 0x7fa0-0x7fbf] to the 00:1c.0 Port, it
> covers up whatever the SMI handler uses, so the SMI handler no longer
> works correctly
> 
> Reserve the [mem 0x7fa0-0x7fbf] space so we don't assign it to
> anything.
> 
> This is voodoo programming, since we don't know what the real conflict is,
> but we've failed to find the root cause.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
> Tested-by: the...@gmail.com
> Signed-off-by: Bjorn Helgaas 
> Cc: sta...@vger.kernel.org
> Cc: Rafael J. Wysocki 
> Cc: Lukas Wunner 
> Cc: Chen Yu 
> 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 6d52b94f4bb9..20fa7c84109d 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -571,3 +571,35 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0, 
> pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar);
> +
> +/*
> + * Apple MacBook Pro: Avoid [mem 0x7fa0-0x7fbf]
> + *
> + * Using the [mem 0x7fa0-0x7fbf] region, e.g., by assigning it to
> + * the 00:1c.0 Root Port, causes a conflict with [io 0x1804], which is used
> + * for soft poweroff and suspend-to-RAM.
> + *
> + * As far as we know, this is related to the address space, not to the Root
> + * Port itself.  Attaching the quirk to the Root Port is a convenience, but
> + * it could probably also be a standalone DMI quirk.
> + *
> + * https://bugzilla.kernel.org/show_bug.cgi?id=103211
> + */
> +static void quirk_apple_mbp_poweroff(struct pci_dev *pdev)
> +{
> + struct device *dev = >dev;
> + struct resource *res;
> +
> + if ((!dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,4") &&
> +  !dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,5")) ||
> + pdev->bus->number != 0 || pdev->devfn != PCI_DEVFN(0x1c, 0))
> + return;
> +
Not sure why we need to also the bus number of devfn, as there
is only one PCI bridge that would match 0x8c10? according to
https://bugzilla.kernel.org/attachment.cgi?id=210611
am I missing something?
thanks,
Yu
> + res = request_mem_region(0x7fa0, 0x20,
> +  "MacBook Pro poweroff workaround");
> + if (res)
> + dev_info(dev, "claimed %s %pR\n", res->name, res);
> + else
> + dev_info(dev, "can't work around MacBook Pro poweroff issue\n");
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
> quirk_apple_mbp_poweroff);

Re: [PATCH] PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11

[Chen Yu]

Hi,
On Sun, Jul 02, 2017 at 03:59:48PM -0500, Bjorn Helgaas wrote:
> Neither soft poweroff (transition to ACPI power state S5) nor
> suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and
> 11,5.
> 
> The problem is related to the [mem 0x7fa0-0x7fbf] space.  When we
> use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI
> Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn't work
> anymore.
> 
> Linux does a soft poweroff (transition to S5) by writing to PM1_CNT.  The
> theory about why this doesn't work is:
> 
>   - The write to PM1_CNT causes an SMI
>   - The BIOS SMI handler depends on something in
> [mem 0x7fa0-0x7fbf]
>   - When Linux assigns [mem 0x7fa0-0x7fbf] to the 00:1c.0 Port, it
> covers up whatever the SMI handler uses, so the SMI handler no longer
> works correctly
> 
> Reserve the [mem 0x7fa0-0x7fbf] space so we don't assign it to
> anything.
> 
> This is voodoo programming, since we don't know what the real conflict is,
> but we've failed to find the root cause.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
> Tested-by: the...@gmail.com
> Signed-off-by: Bjorn Helgaas 
> Cc: sta...@vger.kernel.org
> Cc: Rafael J. Wysocki 
> Cc: Lukas Wunner 
> Cc: Chen Yu 
> 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 6d52b94f4bb9..20fa7c84109d 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -571,3 +571,35 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0, 
> pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar);
> +
> +/*
> + * Apple MacBook Pro: Avoid [mem 0x7fa0-0x7fbf]
> + *
> + * Using the [mem 0x7fa0-0x7fbf] region, e.g., by assigning it to
> + * the 00:1c.0 Root Port, causes a conflict with [io 0x1804], which is used
> + * for soft poweroff and suspend-to-RAM.
> + *
> + * As far as we know, this is related to the address space, not to the Root
> + * Port itself.  Attaching the quirk to the Root Port is a convenience, but
> + * it could probably also be a standalone DMI quirk.
> + *
> + * https://bugzilla.kernel.org/show_bug.cgi?id=103211
> + */
> +static void quirk_apple_mbp_poweroff(struct pci_dev *pdev)
> +{
> + struct device *dev = >dev;
> + struct resource *res;
> +
> + if ((!dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,4") &&
> +  !dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,5")) ||
> + pdev->bus->number != 0 || pdev->devfn != PCI_DEVFN(0x1c, 0))
> + return;
> +
Not sure why we need to also the bus number of devfn, as there
is only one PCI bridge that would match 0x8c10? according to
https://bugzilla.kernel.org/attachment.cgi?id=210611
am I missing something?
thanks,
Yu
> + res = request_mem_region(0x7fa0, 0x20,
> +  "MacBook Pro poweroff workaround");
> + if (res)
> + dev_info(dev, "claimed %s %pR\n", res->name, res);
> + else
> + dev_info(dev, "can't work around MacBook Pro poweroff issue\n");
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
> quirk_apple_mbp_poweroff);

Re: [PATCH] selftests: ftrace: Use md5sum to take less time of checking logs

[Masami Hiramatsu]

On Fri, 30 Jun 2017 10:53:15 -0600
Shuah Khan  wrote:

> On 06/30/2017 08:49 AM, Steven Rostedt wrote:
> > On Thu, 29 Jun 2017 14:21:41 -0600
> > Shuah Khan  wrote:
> > \
> >> Hi Steve/Masami,
> >>
> >> I tested this patch on my test system running 4.12-rc7 and didn't see any
> >> problems. I am going to leave this in the linux-kselftest next for 
> >> 4.13-rc1.
> >> Please let me if you think I should drop it.
> > 
> > I played a little with it.
> > 
> > Acked-by: Steven Rostedt (VMware) 
> > 
> > -- Steve
> > 
> > 
> 
> Thanks. Applied your Ack now to linux-kselftest next.

Thanks Steve and Shuah!

-- 
Masami Hiramatsu 

Re: [PATCH] selftests: ftrace: Use md5sum to take less time of checking logs

[Masami Hiramatsu]

On Fri, 30 Jun 2017 10:53:15 -0600
Shuah Khan  wrote:

> On 06/30/2017 08:49 AM, Steven Rostedt wrote:
> > On Thu, 29 Jun 2017 14:21:41 -0600
> > Shuah Khan  wrote:
> > \
> >> Hi Steve/Masami,
> >>
> >> I tested this patch on my test system running 4.12-rc7 and didn't see any
> >> problems. I am going to leave this in the linux-kselftest next for 
> >> 4.13-rc1.
> >> Please let me if you think I should drop it.
> > 
> > I played a little with it.
> > 
> > Acked-by: Steven Rostedt (VMware) 
> > 
> > -- Steve
> > 
> > 
> 
> Thanks. Applied your Ack now to linux-kselftest next.

Thanks Steve and Shuah!

-- 
Masami Hiramatsu 

Re: linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

Hi all,

On Mon, 3 Jul 2017 13:56:16 +1000 Stephen Rothwell  
wrote:
>
>  +if (cpu < nr_queues) {
> - map[cpu] = cpu_to_queue_index(nr_queues, cpu, 
> online_mask);
> ++map[cpu] = cpu_to_queue_index(nr_queues, cpu)
>  +} else {
>  +first_sibling = get_first_sibling(cpu);
>  +if (first_sibling == cpu)
> - map[cpu] = cpu_to_queue_index(nr_queues, cpu, 
> online_mask);
> ++map[cpu] = cpu_to_queue_index(nr_queues, cpu)

Clearly, I dropped a couple of semicolons here ... I added them to the
merge resolution.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

Hi all,

On Mon, 3 Jul 2017 13:56:16 +1000 Stephen Rothwell  
wrote:
>
>  +if (cpu < nr_queues) {
> - map[cpu] = cpu_to_queue_index(nr_queues, cpu, 
> online_mask);
> ++map[cpu] = cpu_to_queue_index(nr_queues, cpu)
>  +} else {
>  +first_sibling = get_first_sibling(cpu);
>  +if (first_sibling == cpu)
> - map[cpu] = cpu_to_queue_index(nr_queues, cpu, 
> online_mask);
> ++map[cpu] = cpu_to_queue_index(nr_queues, cpu)

Clearly, I dropped a couple of semicolons here ... I added them to the
merge resolution.

-- 
Cheers,
Stephen Rothwell

[PATCH] powerpc/powernv/idle: Put pnv_cpu_offline behind HOTPLUG_CPU

[Joel Stanley]

In commit 900612315788 ("powerpc/powernv/smp: Add busy-wait loop as fall back
for CPU-Hotplug") the idle code uses generic_check_cpu_restart(), but that
function is not available when CONFIG_HOTPLUG_CPU is disabled.

arch/powerpc/platforms/powernv/idle.c: In function ‘pnv_cpu_offline’:
arch/powerpc/platforms/powernv/idle.c:286:11: error: implicit declaration of
function ‘generic_check_cpu_restart’ [-Werror=implicit-function-declaration]
   while (!generic_check_cpu_restart(cpu)) {
   ^

The callers of pnv_cpu_offline are behind CONFIG_HOTPLUG_CPU, so fix the build
error by putting this code behind the same gard.

Fixes: 900612315788 ("powerpc/powernv/smp: Add busy-wait loop as fall back for 
CPU-Hotplug").
Cc:  # 4.12
Signed-off-by: Joel Stanley 
---
 arch/powerpc/platforms/powernv/idle.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index 445f30a2c5ef..b15d108db216 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -261,6 +261,8 @@ static u64 pnv_deepest_stop_psscr_val;
 static u64 pnv_deepest_stop_psscr_mask;
 static bool deepest_stop_found;
 
+#ifdef CONFIG_HOTPLUG_CPU
+
 /*
  * pnv_cpu_offline: A function that puts the CPU into the deepest
  * available platform idle state on a CPU-Offline.
@@ -294,6 +296,8 @@ unsigned long pnv_cpu_offline(unsigned int cpu)
return srr1;
 }
 
+#endif /* CONFIG_HOTPLUG_CPU */
+
 /*
  * Power ISA 3.0 idle initialization.
  *
-- 
2.13.2

[PATCH] powerpc/powernv/idle: Put pnv_cpu_offline behind HOTPLUG_CPU

[Joel Stanley]

In commit 900612315788 ("powerpc/powernv/smp: Add busy-wait loop as fall back
for CPU-Hotplug") the idle code uses generic_check_cpu_restart(), but that
function is not available when CONFIG_HOTPLUG_CPU is disabled.

arch/powerpc/platforms/powernv/idle.c: In function ‘pnv_cpu_offline’:
arch/powerpc/platforms/powernv/idle.c:286:11: error: implicit declaration of
function ‘generic_check_cpu_restart’ [-Werror=implicit-function-declaration]
   while (!generic_check_cpu_restart(cpu)) {
   ^

The callers of pnv_cpu_offline are behind CONFIG_HOTPLUG_CPU, so fix the build
error by putting this code behind the same gard.

Fixes: 900612315788 ("powerpc/powernv/smp: Add busy-wait loop as fall back for 
CPU-Hotplug").
Cc:  # 4.12
Signed-off-by: Joel Stanley 
---
 arch/powerpc/platforms/powernv/idle.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index 445f30a2c5ef..b15d108db216 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -261,6 +261,8 @@ static u64 pnv_deepest_stop_psscr_val;
 static u64 pnv_deepest_stop_psscr_mask;
 static bool deepest_stop_found;
 
+#ifdef CONFIG_HOTPLUG_CPU
+
 /*
  * pnv_cpu_offline: A function that puts the CPU into the deepest
  * available platform idle state on a CPU-Offline.
@@ -294,6 +296,8 @@ unsigned long pnv_cpu_offline(unsigned int cpu)
return srr1;
 }
 
+#endif /* CONFIG_HOTPLUG_CPU */
+
 /*
  * Power ISA 3.0 idle initialization.
  *
-- 
2.13.2

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

[Stephen Rothwell]

Hi all,

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

  block/blk-mq-cpumap.c

between commit:

  fe631457ff3e ("blk-mq: map all HWQ also in hyperthreaded system")

from the block tree and commit:

  5f042e7cbd9e ("blk-mq: Include all present CPUs in the default queue mapping")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk-mq-cpumap.c
index 2cca4fc43f45,5eaecd40f701..
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@@ -14,15 -14,10 +14,14 @@@
  #include "blk.h"
  #include "blk-mq.h"
  
- static int cpu_to_queue_index(unsigned int nr_queues, const int cpu,
- const struct cpumask *online_mask)
 -static int cpu_to_queue_index(unsigned int nr_cpus, unsigned int nr_queues,
 -const int cpu)
++static int cpu_to_queue_index(unsigned int nr_queues, const int cpu)
  {
 -  return cpu * nr_queues / nr_cpus;
 +  /*
-* Non online CPU will be mapped to queue index 0.
++   * Non present CPU will be mapped to queue index 0.
 +   */
-   if (!cpumask_test_cpu(cpu, online_mask))
++  if (!cpumask_test_cpu(cpu, cpu_present_mask))
 +  return 0;
 +  return cpu % nr_queues;
  }
  
  static int get_first_sibling(unsigned int cpu)
@@@ -40,27 -35,55 +39,26 @@@ int blk_mq_map_queues(struct blk_mq_tag
  {
unsigned int *map = set->mq_map;
unsigned int nr_queues = set->nr_hw_queues;
-   const struct cpumask *online_mask = cpu_online_mask;
 -  unsigned int i, nr_cpus, nr_uniq_cpus, queue, first_sibling;
 -  cpumask_var_t cpus;
 -
 -  if (!alloc_cpumask_var(, GFP_ATOMIC))
 -  return -ENOMEM;
 -
 -  cpumask_clear(cpus);
 -  nr_cpus = nr_uniq_cpus = 0;
 -  for_each_present_cpu(i) {
 -  nr_cpus++;
 -  first_sibling = get_first_sibling(i);
 -  if (!cpumask_test_cpu(first_sibling, cpus))
 -  nr_uniq_cpus++;
 -  cpumask_set_cpu(i, cpus);
 -  }
 -
 -  queue = 0;
 -  for_each_possible_cpu(i) {
 -  if (!cpumask_test_cpu(i, cpu_present_mask)) {
 -  map[i] = 0;
 -  continue;
 -  }
 +  unsigned int cpu, first_sibling;
  
 +  for_each_possible_cpu(cpu) {
/*
 -   * Easy case - we have equal or more hardware queues. Or
 -   * there are no thread siblings to take into account. Do
 -   * 1:1 if enough, or sequential mapping if less.
 +   * First do sequential mapping between CPUs and queues.
 +   * In case we still have CPUs to map, and we have some number of
 +   * threads per cores then map sibling threads to the same queue 
for
 +   * performace optimizations.
 */
 -  if (nr_queues >= nr_cpus || nr_cpus == nr_uniq_cpus) {
 -  map[i] = cpu_to_queue_index(nr_cpus, nr_queues, queue);
 -  queue++;
 -  continue;
 +  if (cpu < nr_queues) {
-   map[cpu] = cpu_to_queue_index(nr_queues, cpu, 
online_mask);
++  map[cpu] = cpu_to_queue_index(nr_queues, cpu)
 +  } else {
 +  first_sibling = get_first_sibling(cpu);
 +  if (first_sibling == cpu)
-   map[cpu] = cpu_to_queue_index(nr_queues, cpu, 
online_mask);
++  map[cpu] = cpu_to_queue_index(nr_queues, cpu)
 +  else
 +  map[cpu] = map[first_sibling];
}
 -
 -  /*
 -   * Less then nr_cpus queues, and we have some number of
 -   * threads per cores. Map sibling threads to the same
 -   * queue.
 -   */
 -  first_sibling = get_first_sibling(i);
 -  if (first_sibling == i) {
 -  map[i] = cpu_to_queue_index(nr_uniq_cpus, nr_queues,
 -  queue);
 -  queue++;
 -  } else
 -  map[i] = map[first_sibling];
}
  
 -  free_cpumask_var(cpus);
return 0;
  }
  EXPORT_SYMBOL_GPL(blk_mq_map_queues);

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

[Stephen Rothwell]

Hi all,

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

  block/blk-mq-cpumap.c

between commit:

  fe631457ff3e ("blk-mq: map all HWQ also in hyperthreaded system")

from the block tree and commit:

  5f042e7cbd9e ("blk-mq: Include all present CPUs in the default queue mapping")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk-mq-cpumap.c
index 2cca4fc43f45,5eaecd40f701..
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@@ -14,15 -14,10 +14,14 @@@
  #include "blk.h"
  #include "blk-mq.h"
  
- static int cpu_to_queue_index(unsigned int nr_queues, const int cpu,
- const struct cpumask *online_mask)
 -static int cpu_to_queue_index(unsigned int nr_cpus, unsigned int nr_queues,
 -const int cpu)
++static int cpu_to_queue_index(unsigned int nr_queues, const int cpu)
  {
 -  return cpu * nr_queues / nr_cpus;
 +  /*
-* Non online CPU will be mapped to queue index 0.
++   * Non present CPU will be mapped to queue index 0.
 +   */
-   if (!cpumask_test_cpu(cpu, online_mask))
++  if (!cpumask_test_cpu(cpu, cpu_present_mask))
 +  return 0;
 +  return cpu % nr_queues;
  }
  
  static int get_first_sibling(unsigned int cpu)
@@@ -40,27 -35,55 +39,26 @@@ int blk_mq_map_queues(struct blk_mq_tag
  {
unsigned int *map = set->mq_map;
unsigned int nr_queues = set->nr_hw_queues;
-   const struct cpumask *online_mask = cpu_online_mask;
 -  unsigned int i, nr_cpus, nr_uniq_cpus, queue, first_sibling;
 -  cpumask_var_t cpus;
 -
 -  if (!alloc_cpumask_var(, GFP_ATOMIC))
 -  return -ENOMEM;
 -
 -  cpumask_clear(cpus);
 -  nr_cpus = nr_uniq_cpus = 0;
 -  for_each_present_cpu(i) {
 -  nr_cpus++;
 -  first_sibling = get_first_sibling(i);
 -  if (!cpumask_test_cpu(first_sibling, cpus))
 -  nr_uniq_cpus++;
 -  cpumask_set_cpu(i, cpus);
 -  }
 -
 -  queue = 0;
 -  for_each_possible_cpu(i) {
 -  if (!cpumask_test_cpu(i, cpu_present_mask)) {
 -  map[i] = 0;
 -  continue;
 -  }
 +  unsigned int cpu, first_sibling;
  
 +  for_each_possible_cpu(cpu) {
/*
 -   * Easy case - we have equal or more hardware queues. Or
 -   * there are no thread siblings to take into account. Do
 -   * 1:1 if enough, or sequential mapping if less.
 +   * First do sequential mapping between CPUs and queues.
 +   * In case we still have CPUs to map, and we have some number of
 +   * threads per cores then map sibling threads to the same queue 
for
 +   * performace optimizations.
 */
 -  if (nr_queues >= nr_cpus || nr_cpus == nr_uniq_cpus) {
 -  map[i] = cpu_to_queue_index(nr_cpus, nr_queues, queue);
 -  queue++;
 -  continue;
 +  if (cpu < nr_queues) {
-   map[cpu] = cpu_to_queue_index(nr_queues, cpu, 
online_mask);
++  map[cpu] = cpu_to_queue_index(nr_queues, cpu)
 +  } else {
 +  first_sibling = get_first_sibling(cpu);
 +  if (first_sibling == cpu)
-   map[cpu] = cpu_to_queue_index(nr_queues, cpu, 
online_mask);
++  map[cpu] = cpu_to_queue_index(nr_queues, cpu)
 +  else
 +  map[cpu] = map[first_sibling];
}
 -
 -  /*
 -   * Less then nr_cpus queues, and we have some number of
 -   * threads per cores. Map sibling threads to the same
 -   * queue.
 -   */
 -  first_sibling = get_first_sibling(i);
 -  if (first_sibling == i) {
 -  map[i] = cpu_to_queue_index(nr_uniq_cpus, nr_queues,
 -  queue);
 -  queue++;
 -  } else
 -  map[i] = map[first_sibling];
}
  
 -  free_cpumask_var(cpus);
return 0;
  }
  EXPORT_SYMBOL_GPL(blk_mq_map_queues);

Re: [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

[Dou Liyang]

Hi Thomas,

At 07/03/2017 03:18 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:


xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus
which initializes interrupt itself.

Touching the intr_mode_init causes unexpected results on the system.

Bypass it in enlighten_pv system.


So that's the wrong patch order then. You broke XEN at some point with your
changes. You need to prevent that breakage upfront not after the fact.


Yes, I have considered to prevent that breakage in the patchset.

Actually, Until the 11th patch, we put the intr_mode_init ahead of
time, which will break XEN.

Before the 11th patch, we just unify the code and do the preparation,
Kernel will do the intr_mode_init like before, which will have no
influence on XEN.

So we put the patch here before 11th patch.

Thanks,

dou.



Thanks,

tglx

Re: [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

[Dou Liyang]

Hi Thomas,

At 07/03/2017 03:18 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:


xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus
which initializes interrupt itself.

Touching the intr_mode_init causes unexpected results on the system.

Bypass it in enlighten_pv system.


So that's the wrong patch order then. You broke XEN at some point with your
changes. You need to prevent that breakage upfront not after the fact.


Yes, I have considered to prevent that breakage in the patchset.

Actually, Until the 11th patch, we put the intr_mode_init ahead of
time, which will break XEN.

Before the 11th patch, we just unify the code and do the preparation,
Kernel will do the intr_mode_init like before, which will have no
influence on XEN.

So we put the patch here before 11th patch.

Thanks,

dou.



Thanks,

tglx

Re: [PATCH v2 2/4] selftests/ftrace: Add a test to probe module functions

[Masami Hiramatsu]

On Mon, 3 Jul 2017 12:27:33 +0900
Masami Hiramatsu  wrote:

> On Thu, 29 Jun 2017 19:05:37 +0530
> "Naveen N. Rao"  wrote:
> 
> > Add a kprobes test to ensure that we are able to add a probe on a
> > module function using 'p :' format, without having to
> > specify a probe name.
> > 
> > Suggested-by: Masami Hiramatsu 
> > Acked-by: Masami Hiramatsu 
> > Signed-off-by: Naveen N. Rao 
> > ---
> >  .../testing/selftests/ftrace/test.d/kprobe/probe_module.tc | 14 
> > ++
> >  1 file changed, 14 insertions(+)
> >  create mode 100644 
> > tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> > 
> > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc 
> > b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> > new file mode 100644
> > index ..ea7657041ba6
> > --- /dev/null
> > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> > @@ -0,0 +1,14 @@
> > +#!/bin/sh
> > +# description: Kprobe dynamic event - probing module
> > +
> > +[ -f kprobe_events ] || exit_unsupported # this is configurable
> > +
> > +echo 0 > events/enable
> > +echo > kprobe_events
> > +export MOD=`lsmod | head -n 2 | tail -n 1 | cut -f1 -d" "`
> > +export FUNC=`grep -m 1 ".* t .*\\[$MOD\\]" /proc/kallsyms | xargs | cut 
> > -f3 -d" "`
> > +[ "x" != "x$MOD" -a "y" != "y$FUNC" ] || exit_untested
> 
> Could you also add below case?
> 
> echo p:probe_$MOD/$FUNC $MOD/$FUNC > kprobe_events 

Oops, it should be something like

echo "p:test_${MOD}_${FUNC} $MOD/$FUNC" > kprobe_events

since we would like to avoid adding new group name for it.

(Adding new group name should be a separated one.)

Thank you,

> 
> This is for "new event with name on module" case, your one is for "new event 
> without name on module (automatic name generation)"
> 
> We should have different test case, because those kicks slightly different 
> parts in kprobe tracer.
> 
> Thank you,
> 
> > +echo p $MOD:$FUNC > kprobe_events
> > +grep $MOD kprobe_events
> > +echo > kprobe_events
> > +clear_trace
> > -- 
> > 2.13.1
> > 
> 
> 
> -- 
> Masami Hiramatsu 


-- 
Masami Hiramatsu 

Re: [PATCH v2 2/4] selftests/ftrace: Add a test to probe module functions

[Masami Hiramatsu]

On Mon, 3 Jul 2017 12:27:33 +0900
Masami Hiramatsu  wrote:

> On Thu, 29 Jun 2017 19:05:37 +0530
> "Naveen N. Rao"  wrote:
> 
> > Add a kprobes test to ensure that we are able to add a probe on a
> > module function using 'p :' format, without having to
> > specify a probe name.
> > 
> > Suggested-by: Masami Hiramatsu 
> > Acked-by: Masami Hiramatsu 
> > Signed-off-by: Naveen N. Rao 
> > ---
> >  .../testing/selftests/ftrace/test.d/kprobe/probe_module.tc | 14 
> > ++
> >  1 file changed, 14 insertions(+)
> >  create mode 100644 
> > tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> > 
> > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc 
> > b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> > new file mode 100644
> > index ..ea7657041ba6
> > --- /dev/null
> > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> > @@ -0,0 +1,14 @@
> > +#!/bin/sh
> > +# description: Kprobe dynamic event - probing module
> > +
> > +[ -f kprobe_events ] || exit_unsupported # this is configurable
> > +
> > +echo 0 > events/enable
> > +echo > kprobe_events
> > +export MOD=`lsmod | head -n 2 | tail -n 1 | cut -f1 -d" "`
> > +export FUNC=`grep -m 1 ".* t .*\\[$MOD\\]" /proc/kallsyms | xargs | cut 
> > -f3 -d" "`
> > +[ "x" != "x$MOD" -a "y" != "y$FUNC" ] || exit_untested
> 
> Could you also add below case?
> 
> echo p:probe_$MOD/$FUNC $MOD/$FUNC > kprobe_events 

Oops, it should be something like

echo "p:test_${MOD}_${FUNC} $MOD/$FUNC" > kprobe_events

since we would like to avoid adding new group name for it.

(Adding new group name should be a separated one.)

Thank you,

> 
> This is for "new event with name on module" case, your one is for "new event 
> without name on module (automatic name generation)"
> 
> We should have different test case, because those kicks slightly different 
> parts in kprobe tracer.
> 
> Thank you,
> 
> > +echo p $MOD:$FUNC > kprobe_events
> > +grep $MOD kprobe_events
> > +echo > kprobe_events
> > +clear_trace
> > -- 
> > 2.13.1
> > 
> 
> 
> -- 
> Masami Hiramatsu 


-- 
Masami Hiramatsu 

RE: [PATCH 1/9] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk support

[A.s. Dong]

> -Original Message-
> From: Stephen Boyd [mailto:sb...@codeaurora.org]
> Sent: Saturday, July 01, 2017 8:56 AM
> To: Dong Aisheng
> Cc: A.s. Dong; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; mturque...@baylibre.com;
> shawn...@kernel.org; Anson Huang; Jacky Bai
> Subject: Re: [PATCH 1/9] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk
> support
> 
> On 06/20, Dong Aisheng wrote:
> > Hi Stephen,
> >
> > On Mon, Jun 19, 2017 at 06:45:12PM -0700, Stephen Boyd wrote:
> > > On 05/15, Dong Aisheng wrote:
> > > > ---
> > > >  drivers/clk/clk-divider.c| 2 ++
> > > >  include/linux/clk-provider.h | 4 
> > > >  2 files changed, 6 insertions(+)
> > > >
> > > > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > > > index 96386ff..f78ba7a 100644
> > > > --- a/drivers/clk/clk-divider.c
> > > > +++ b/drivers/clk/clk-divider.c
> > > > @@ -125,6 +125,8 @@ unsigned long divider_recalc_rate(struct
> > > > clk_hw *hw, unsigned long parent_rate,
> > > >
> > > > div = _get_div(table, val, flags, divider->width);
> > > > if (!div) {
> > > > +   if (flags & CLK_DIVIDER_ZERO_GATE)
> > > > +   return 0;
> > > > WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO),
> > >
> > > Why not use the CLK_DIVIDER_ALLOW_ZERO flag? A clk being off doesn't
> > > mean the rate is 0. The divider is just disabled, so we would
> > > consider the rate as whatever the parent is, which is what this code
> > > does before this patch. Similarly, we don't do anything about gate
> > > clocks and return a rate of 0 when they're disabled.
> > >
> >
> > The semantic of CLK_DIVIDER_ALLOW_ZERO seems a bit different.
> >
> > See below definition:
> > * CLK_DIVIDER_ALLOW_ZERO - Allow zero divisors.  For dividers which
> have
> > *  CLK_DIVIDER_ONE_BASED set, it is possible to end up with a zero
> divisor.
> > *  Some hardware implementations gracefully handle this case and
> allow a
> > *  zero divisor by not modifying their input clock
> > *  (divide by one / bypass).
> >
> > zero divisor is simply as divide by one or bypass which is supported
> > by hardware.
> >
> > But it's not true for this hardware.
> >
> > If we consider the rate as whatever the parent is if divider is zero,
> > we may got an issue like below:
> > e.g.
> > Assuming spll_bus_clk divider is 0x0 and it may be enabled by users
> > directly without setting a rate first.
> >
> > Then the clock tree looks like:
> > ...
> > spll_pfd011   500210526  0 0
> >   spll_pfd_sel  11   500210526  0 0
> > spll_sel   11   500210526  0 0
> >   spll_bus_clk   11   500210526  0 0
> >
> > But the spll_bus_clk clock rate actually is wrong and it's even not
> > enabled, not like CLK_DIVIDER_ALLOW_ZERO which zero divider means
> simply bypass.
> >
> > So for this case, we probably can't simply assume zero divider rate as
> > its parent, it is actually set to 0 in hw, although it's something
> > like gate, but a bit different from gate as the normal gate does not
> > affect divider where you can keep the rate.
> >
> > How would you suggest for this?
> >
> 
> It seems that set_rate() and enable/disable are conflated here.
> From what you describe, it sounds like the clk is considered off when the
> divider value is zero, and it's on when the divider value is non-zero.
> 
> I'd suggest you make it so this clk supports enable/disable and set_rate
> with the same register. Something like, set rate when the clk is disabled
> will cache the rate request and only when the clk is enabled will the
> driver actually program the hardware to have the requested divider value.
> Similarly, when the clk is disabled we'll write a 0 there, but when the
> clk is enabled we'll restore whatever rate (divider) was chosen last.
> 
> It does mean that recalc rate will be sort of odd, because when the clk
> is off it will return 0, and when the clk is on it will return the right
> rate. So to make things work, we'll need to return the cached rate in
> recalc rate when the clk is off and read the hardware when the clk is on.
> Probably an if register ==
> 0 then lookup in cache, otherwise do normal division.
> 

Well, good suggestions to me.
It makes the implementation of this clock type more comprehensive.

It seems we still need keep CLK_DIVIDER_ZERO_GATE to distinguish with others.

The change for recacle_rate may looks like:
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index f78ba7a..7364ac4 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -125,8 +125,9 @@ unsigned long divider_recalc_rate(struct clk_hw *hw, 
unsigned long parent_rate,
 
div = _get_div(table, val, flags, divider->width);
if (!div) {
+   if ((flags & CLK_DIVIDER_ZERO_GATE) && clk_hw_is_enabled(hw))
+  

RE: [PATCH 1/9] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk support

[A.s. Dong]

> -Original Message-
> From: Stephen Boyd [mailto:sb...@codeaurora.org]
> Sent: Saturday, July 01, 2017 8:56 AM
> To: Dong Aisheng
> Cc: A.s. Dong; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; mturque...@baylibre.com;
> shawn...@kernel.org; Anson Huang; Jacky Bai
> Subject: Re: [PATCH 1/9] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk
> support
> 
> On 06/20, Dong Aisheng wrote:
> > Hi Stephen,
> >
> > On Mon, Jun 19, 2017 at 06:45:12PM -0700, Stephen Boyd wrote:
> > > On 05/15, Dong Aisheng wrote:
> > > > ---
> > > >  drivers/clk/clk-divider.c| 2 ++
> > > >  include/linux/clk-provider.h | 4 
> > > >  2 files changed, 6 insertions(+)
> > > >
> > > > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > > > index 96386ff..f78ba7a 100644
> > > > --- a/drivers/clk/clk-divider.c
> > > > +++ b/drivers/clk/clk-divider.c
> > > > @@ -125,6 +125,8 @@ unsigned long divider_recalc_rate(struct
> > > > clk_hw *hw, unsigned long parent_rate,
> > > >
> > > > div = _get_div(table, val, flags, divider->width);
> > > > if (!div) {
> > > > +   if (flags & CLK_DIVIDER_ZERO_GATE)
> > > > +   return 0;
> > > > WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO),
> > >
> > > Why not use the CLK_DIVIDER_ALLOW_ZERO flag? A clk being off doesn't
> > > mean the rate is 0. The divider is just disabled, so we would
> > > consider the rate as whatever the parent is, which is what this code
> > > does before this patch. Similarly, we don't do anything about gate
> > > clocks and return a rate of 0 when they're disabled.
> > >
> >
> > The semantic of CLK_DIVIDER_ALLOW_ZERO seems a bit different.
> >
> > See below definition:
> > * CLK_DIVIDER_ALLOW_ZERO - Allow zero divisors.  For dividers which
> have
> > *  CLK_DIVIDER_ONE_BASED set, it is possible to end up with a zero
> divisor.
> > *  Some hardware implementations gracefully handle this case and
> allow a
> > *  zero divisor by not modifying their input clock
> > *  (divide by one / bypass).
> >
> > zero divisor is simply as divide by one or bypass which is supported
> > by hardware.
> >
> > But it's not true for this hardware.
> >
> > If we consider the rate as whatever the parent is if divider is zero,
> > we may got an issue like below:
> > e.g.
> > Assuming spll_bus_clk divider is 0x0 and it may be enabled by users
> > directly without setting a rate first.
> >
> > Then the clock tree looks like:
> > ...
> > spll_pfd011   500210526  0 0
> >   spll_pfd_sel  11   500210526  0 0
> > spll_sel   11   500210526  0 0
> >   spll_bus_clk   11   500210526  0 0
> >
> > But the spll_bus_clk clock rate actually is wrong and it's even not
> > enabled, not like CLK_DIVIDER_ALLOW_ZERO which zero divider means
> simply bypass.
> >
> > So for this case, we probably can't simply assume zero divider rate as
> > its parent, it is actually set to 0 in hw, although it's something
> > like gate, but a bit different from gate as the normal gate does not
> > affect divider where you can keep the rate.
> >
> > How would you suggest for this?
> >
> 
> It seems that set_rate() and enable/disable are conflated here.
> From what you describe, it sounds like the clk is considered off when the
> divider value is zero, and it's on when the divider value is non-zero.
> 
> I'd suggest you make it so this clk supports enable/disable and set_rate
> with the same register. Something like, set rate when the clk is disabled
> will cache the rate request and only when the clk is enabled will the
> driver actually program the hardware to have the requested divider value.
> Similarly, when the clk is disabled we'll write a 0 there, but when the
> clk is enabled we'll restore whatever rate (divider) was chosen last.
> 
> It does mean that recalc rate will be sort of odd, because when the clk
> is off it will return 0, and when the clk is on it will return the right
> rate. So to make things work, we'll need to return the cached rate in
> recalc rate when the clk is off and read the hardware when the clk is on.
> Probably an if register ==
> 0 then lookup in cache, otherwise do normal division.
> 

Well, good suggestions to me.
It makes the implementation of this clock type more comprehensive.

It seems we still need keep CLK_DIVIDER_ZERO_GATE to distinguish with others.

The change for recacle_rate may looks like:
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index f78ba7a..7364ac4 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -125,8 +125,9 @@ unsigned long divider_recalc_rate(struct clk_hw *hw, 
unsigned long parent_rate,
 
div = _get_div(table, val, flags, divider->width);
if (!div) {
+   if ((flags & CLK_DIVIDER_ZERO_GATE) && clk_hw_is_enabled(hw))
+  

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

[Stephen Rothwell]

Hi Mark,

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

drivers/spi/spi-imx.c: In function 'spi_imx_setupxfer':
drivers/spi/spi-imx.c:1007:16: error: 'config' undeclared (first use in this 
function)
   mask = (1 << config.bpw) - 1;
^

Caused by commit

  a0cc330240c9 ("spi: imx: dynamic burst length adjust for PIO mode")

interacting with commit

  d52345b6cf8e ("spi: imx: put struct spi_imx_config members into driver 
private struct")

I reverted a0cc330240c9 for today.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Mark,

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

drivers/spi/spi-imx.c: In function 'spi_imx_setupxfer':
drivers/spi/spi-imx.c:1007:16: error: 'config' undeclared (first use in this 
function)
   mask = (1 << config.bpw) - 1;
^

Caused by commit

  a0cc330240c9 ("spi: imx: dynamic burst length adjust for PIO mode")

interacting with commit

  d52345b6cf8e ("spi: imx: put struct spi_imx_config members into driver 
private struct")

I reverted a0cc330240c9 for today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 4/4] selftests/ftrace: Add a testcase for kprobe event naming

[Masami Hiramatsu]

On Thu, 29 Jun 2017 19:05:39 +0530
"Naveen N. Rao"  wrote:

> From: Masami Hiramatsu 
> 
> Add a testcase for kprobe event naming. This testcase
> checks whether the kprobe events can automatically ganerate
> its event name on normal function and dot-suffixed function.
> Also it checks whether the kprobe events can correctly
> define new event with given event name and group name.
> 
> Signed-off-by: Masami Hiramatsu 
> [Updated tests to use vfs_read and symbols with '.isra.',
> added check for kprobe_events and a command to clear it on exit]
> Signed-off-by: Naveen N. Rao 
> ---
>  .../ftrace/test.d/kprobe/kprobe_eventname.tc   | 32 
> ++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc 
> b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> new file mode 100644
> index ..182e5a78ef4b
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> @@ -0,0 +1,32 @@
> +#!/bin/sh
> +# description: Kprobe event auto/manual naming
> +
> +[ -f kprobe_events ] || exit_unsupported # this is configurable
> +
> +disable_events
> +echo > kprobe_events
> +
> +:;: "Add an event on function without name" ;:
> +
> +FUNC=`grep " [tT] .*vfs_read$" /proc/kallsyms | tail -n 1 | cut -f 3 -d " "`
> +echo p $FUNC > kprobe_events
> +FUNC_NAME=`echo $FUNC | tr ".:" "_"`
> +test -d events/kprobes/p_${FUNC_NAME}_0 || exit_failure
> +
> +:;: "Add an event on function with new name" ;:
> +
> +echo p:event1 $FUNC > kprobe_events
> +test -d events/kprobes/event1 || exit_failure
> +
> +:;: "Add an event on function with new name and group" ;:
> +
> +echo p:kprobes2/event2 $FUNC > kprobe_events
> +test -d events/kprobes2/event2 || exit_failure
> +
> +:;: "Add an event on dot function without name" ;:
> +
> +FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3 
> -d " "`

Since in some case we may not be able to find the function(e.g. build with old 
gcc or not optimized), we should check this is exist. I suggested to return 
UNRESOLVED for that case instead of FAIL, as below.

FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3 -d 
" "` || exit_unresolved

Thank you,

> +echo p $FUNC > kprobe_events
> +EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:` || 
> exit_failure
> +test -d events/$EVENT || exit_failure
> +echo > kprobe_events
> -- 
> 2.13.1
> 


-- 
Masami Hiramatsu 

Re: [PATCH v2 4/4] selftests/ftrace: Add a testcase for kprobe event naming

[Masami Hiramatsu]

On Thu, 29 Jun 2017 19:05:39 +0530
"Naveen N. Rao"  wrote:

> From: Masami Hiramatsu 
> 
> Add a testcase for kprobe event naming. This testcase
> checks whether the kprobe events can automatically ganerate
> its event name on normal function and dot-suffixed function.
> Also it checks whether the kprobe events can correctly
> define new event with given event name and group name.
> 
> Signed-off-by: Masami Hiramatsu 
> [Updated tests to use vfs_read and symbols with '.isra.',
> added check for kprobe_events and a command to clear it on exit]
> Signed-off-by: Naveen N. Rao 
> ---
>  .../ftrace/test.d/kprobe/kprobe_eventname.tc   | 32 
> ++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc 
> b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> new file mode 100644
> index ..182e5a78ef4b
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> @@ -0,0 +1,32 @@
> +#!/bin/sh
> +# description: Kprobe event auto/manual naming
> +
> +[ -f kprobe_events ] || exit_unsupported # this is configurable
> +
> +disable_events
> +echo > kprobe_events
> +
> +:;: "Add an event on function without name" ;:
> +
> +FUNC=`grep " [tT] .*vfs_read$" /proc/kallsyms | tail -n 1 | cut -f 3 -d " "`
> +echo p $FUNC > kprobe_events
> +FUNC_NAME=`echo $FUNC | tr ".:" "_"`
> +test -d events/kprobes/p_${FUNC_NAME}_0 || exit_failure
> +
> +:;: "Add an event on function with new name" ;:
> +
> +echo p:event1 $FUNC > kprobe_events
> +test -d events/kprobes/event1 || exit_failure
> +
> +:;: "Add an event on function with new name and group" ;:
> +
> +echo p:kprobes2/event2 $FUNC > kprobe_events
> +test -d events/kprobes2/event2 || exit_failure
> +
> +:;: "Add an event on dot function without name" ;:
> +
> +FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3 
> -d " "`

Since in some case we may not be able to find the function(e.g. build with old 
gcc or not optimized), we should check this is exist. I suggested to return 
UNRESOLVED for that case instead of FAIL, as below.

FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3 -d 
" "` || exit_unresolved

Thank you,

> +echo p $FUNC > kprobe_events
> +EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:` || 
> exit_failure
> +test -d events/$EVENT || exit_failure
> +echo > kprobe_events
> -- 
> 2.13.1
> 


-- 
Masami Hiramatsu 

Re: [PATCH v2 3/4] selftests/ftrace: Update multiple kprobes test for powerpc

[Masami Hiramatsu]

On Thu, 29 Jun 2017 19:05:38 +0530
"Naveen N. Rao"  wrote:

> KPROBES_ON_FTRACE is only available on powerpc64le. Update comment to
> clarify this.
> 
> Also, we should use an offset of 8 to ensure that the probe does not
> fall on ftrace location. The current offset of 4 will fall before the
> function local entry point and won't fire, while an offset of 12 or 16
> will fall on ftrace location. Offset 8 is currently guaranteed to not be
> the ftrace location.

OK, looks good to me.

Acked-by: Masami Hiramatsu 

Thanks!

> 
> Signed-off-by: Naveen N. Rao 
> ---
>  tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc 
> b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> index f4d1ff785d67..2a1cb9908746 100644
> --- a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> @@ -2,10 +2,10 @@
>  # description: Register/unregister many kprobe events
>  
>  # ftrace fentry skip size depends on the machine architecture.
> -# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc
> +# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc64le
>  case `uname -m` in
>x86_64|i[3456]86) OFFS=5;;
> -  ppc*) OFFS=4;;
> +  ppc64le) OFFS=8;;
>*) OFFS=0;;
>  esac
>  
> -- 
> 2.13.1
> 


-- 
Masami Hiramatsu 

Re: [PATCH v2 3/4] selftests/ftrace: Update multiple kprobes test for powerpc

[Masami Hiramatsu]

On Thu, 29 Jun 2017 19:05:38 +0530
"Naveen N. Rao"  wrote:

> KPROBES_ON_FTRACE is only available on powerpc64le. Update comment to
> clarify this.
> 
> Also, we should use an offset of 8 to ensure that the probe does not
> fall on ftrace location. The current offset of 4 will fall before the
> function local entry point and won't fire, while an offset of 12 or 16
> will fall on ftrace location. Offset 8 is currently guaranteed to not be
> the ftrace location.

OK, looks good to me.

Acked-by: Masami Hiramatsu 

Thanks!

> 
> Signed-off-by: Naveen N. Rao 
> ---
>  tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc 
> b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> index f4d1ff785d67..2a1cb9908746 100644
> --- a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> @@ -2,10 +2,10 @@
>  # description: Register/unregister many kprobe events
>  
>  # ftrace fentry skip size depends on the machine architecture.
> -# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc
> +# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc64le
>  case `uname -m` in
>x86_64|i[3456]86) OFFS=5;;
> -  ppc*) OFFS=4;;
> +  ppc64le) OFFS=8;;
>*) OFFS=0;;
>  esac
>  
> -- 
> 2.13.1
> 


-- 
Masami Hiramatsu 

Re: [PATCH v5 09/12] x86/init: add intr_mode_init to x86_init_ops

[Dou Liyang]

Hi Thomas,

At 07/03/2017 03:16 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

Add an unconditional x86_init_ops function which defaults to the
standard function and can be overridden by the early platform code.


That changelog describes WHAT the patch does, but not WHY. That's useless
as we can see WHAT the patch does from the patch itself. The WHY is the
really important information.



Understood, I will add the WHY description in the next version.

Thank,

dou.


Thanks,

tglx

Re: [PATCH v5 09/12] x86/init: add intr_mode_init to x86_init_ops

[Dou Liyang]

Hi Thomas,

At 07/03/2017 03:16 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

Add an unconditional x86_init_ops function which defaults to the
standard function and can be overridden by the early platform code.


That changelog describes WHAT the patch does, but not WHY. That's useless
as we can see WHAT the patch does from the patch itself. The WHY is the
really important information.



Understood, I will add the WHY description in the next version.

Thank,

dou.


Thanks,

tglx

Re: [PATCH v2 2/4] selftests/ftrace: Add a test to probe module functions

[Masami Hiramatsu]

On Thu, 29 Jun 2017 19:05:37 +0530
"Naveen N. Rao"  wrote:

> Add a kprobes test to ensure that we are able to add a probe on a
> module function using 'p :' format, without having to
> specify a probe name.
> 
> Suggested-by: Masami Hiramatsu 
> Acked-by: Masami Hiramatsu 
> Signed-off-by: Naveen N. Rao 
> ---
>  .../testing/selftests/ftrace/test.d/kprobe/probe_module.tc | 14 
> ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc 
> b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> new file mode 100644
> index ..ea7657041ba6
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> @@ -0,0 +1,14 @@
> +#!/bin/sh
> +# description: Kprobe dynamic event - probing module
> +
> +[ -f kprobe_events ] || exit_unsupported # this is configurable
> +
> +echo 0 > events/enable
> +echo > kprobe_events
> +export MOD=`lsmod | head -n 2 | tail -n 1 | cut -f1 -d" "`
> +export FUNC=`grep -m 1 ".* t .*\\[$MOD\\]" /proc/kallsyms | xargs | cut -f3 
> -d" "`
> +[ "x" != "x$MOD" -a "y" != "y$FUNC" ] || exit_untested

Could you also add below case?

echo p:probe_$MOD/$FUNC $MOD/$FUNC > kprobe_events 

This is for "new event with name on module" case, your one is for "new event 
without name on module (automatic name generation)"

We should have different test case, because those kicks slightly different 
parts in kprobe tracer.

Thank you,

> +echo p $MOD:$FUNC > kprobe_events
> +grep $MOD kprobe_events
> +echo > kprobe_events
> +clear_trace
> -- 
> 2.13.1
> 


-- 
Masami Hiramatsu 

Re: [PATCH v2 2/4] selftests/ftrace: Add a test to probe module functions

[Masami Hiramatsu]

On Thu, 29 Jun 2017 19:05:37 +0530
"Naveen N. Rao"  wrote:

> Add a kprobes test to ensure that we are able to add a probe on a
> module function using 'p :' format, without having to
> specify a probe name.
> 
> Suggested-by: Masami Hiramatsu 
> Acked-by: Masami Hiramatsu 
> Signed-off-by: Naveen N. Rao 
> ---
>  .../testing/selftests/ftrace/test.d/kprobe/probe_module.tc | 14 
> ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc 
> b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> new file mode 100644
> index ..ea7657041ba6
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/probe_module.tc
> @@ -0,0 +1,14 @@
> +#!/bin/sh
> +# description: Kprobe dynamic event - probing module
> +
> +[ -f kprobe_events ] || exit_unsupported # this is configurable
> +
> +echo 0 > events/enable
> +echo > kprobe_events
> +export MOD=`lsmod | head -n 2 | tail -n 1 | cut -f1 -d" "`
> +export FUNC=`grep -m 1 ".* t .*\\[$MOD\\]" /proc/kallsyms | xargs | cut -f3 
> -d" "`
> +[ "x" != "x$MOD" -a "y" != "y$FUNC" ] || exit_untested

Could you also add below case?

echo p:probe_$MOD/$FUNC $MOD/$FUNC > kprobe_events 

This is for "new event with name on module" case, your one is for "new event 
without name on module (automatic name generation)"

We should have different test case, because those kicks slightly different 
parts in kprobe tracer.

Thank you,

> +echo p $MOD:$FUNC > kprobe_events
> +grep $MOD kprobe_events
> +echo > kprobe_events
> +clear_trace
> -- 
> 2.13.1
> 


-- 
Masami Hiramatsu 

Re: [PATCH v5 08/12] x86/ioapic: Refactor the delay logic in timer_irq_works()

[Dou Liyang]

Hi Thomas,

At 07/03/2017 03:15 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

+static void __init delay_with_tsc(void)
+{
+   unsigned long long start, now;
+   unsigned long ticks = jiffies;


Please make that

   unsigned long end = jiffies + 4;

ticks really means: number of ticks. But that variable is doing something
different.


um, I see. Will use 'end' instead.




+   start = rdtsc();
+
+   /*
+* We don't know the TSC frequency yet, but waiting for
+* 400/HZ TSC cycles is safe:
+* 4 GHz == 10 jiffies
+* 1 GHz == 40 jiffies
+*/
+   do {
+   rep_nop();
+   now = rdtsc();
+   } while ((now - start) < 400UL / HZ &&
+   time_before_eq(jiffies, ticks + 4));
+}
+
+static void __init delay_without_tsc(void)
+{
+   int band = 1;
+   unsigned long ticks = jiffies;


Please sort variables in reverse fir tree order

unsigned long end = jiffies + 4;
int band = 1;



OK, I will.


+
+   /*
+* We don't know any frequency yet, but waiting for
+* 4094000/HZ cycles is safe:
+* 4 GHz == 10 jiffies
+* 1 GHz == 40 jiffies
+* 1 << 1 + 1 << 2 +...+ 1 << 11 = 4094
+*/
+   do {
+   __delay(((1 << band++) * 1000UL) / HZ);


  s/1/1U/



Got it!

Thanks,

dou.



+   } while (band < 12 && time_before_eq(jiffies, ticks + 4));
+}


Thanks,

tglx

Re: [PATCH v5 08/12] x86/ioapic: Refactor the delay logic in timer_irq_works()

[Dou Liyang]

Hi Thomas,

At 07/03/2017 03:15 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

+static void __init delay_with_tsc(void)
+{
+   unsigned long long start, now;
+   unsigned long ticks = jiffies;


Please make that

   unsigned long end = jiffies + 4;

ticks really means: number of ticks. But that variable is doing something
different.


um, I see. Will use 'end' instead.




+   start = rdtsc();
+
+   /*
+* We don't know the TSC frequency yet, but waiting for
+* 400/HZ TSC cycles is safe:
+* 4 GHz == 10 jiffies
+* 1 GHz == 40 jiffies
+*/
+   do {
+   rep_nop();
+   now = rdtsc();
+   } while ((now - start) < 400UL / HZ &&
+   time_before_eq(jiffies, ticks + 4));
+}
+
+static void __init delay_without_tsc(void)
+{
+   int band = 1;
+   unsigned long ticks = jiffies;


Please sort variables in reverse fir tree order

unsigned long end = jiffies + 4;
int band = 1;



OK, I will.


+
+   /*
+* We don't know any frequency yet, but waiting for
+* 4094000/HZ cycles is safe:
+* 4 GHz == 10 jiffies
+* 1 GHz == 40 jiffies
+* 1 << 1 + 1 << 2 +...+ 1 << 11 = 4094
+*/
+   do {
+   __delay(((1 << band++) * 1000UL) / HZ);


  s/1/1U/



Got it!

Thanks,

dou.



+   } while (band < 12 && time_before_eq(jiffies, ticks + 4));
+}


Thanks,

tglx

Re: [RFC PATCH 2/2] kprobes: Allow specifying names for certain blacklisted address ranges

[Masami Hiramatsu]

On Thu, 29 Jun 2017 19:38:38 +0530
"Naveen N. Rao"  wrote:

> This allows us to provide meaningful names for certain address ranges
> that are blacklisted such as those with __kprobes annotation, kernel
> entry text, and so on. For such ranges, using the symbol/function name
> at the start of the range is misleading.
> 
> On a powerpc64le system, before patch:
>   root@ubuntu:/sys/kernel/debug# tail kprobes/blacklist
>   0xc022d500-0xc022d580   print_type_s64
>   0xc022d480-0xc022d500   print_type_s32
>   0xc022d400-0xc022d480   print_type_s16
>   0xc022d380-0xc022d400   print_type_s8
>   0xc022d300-0xc022d380   print_type_u64
>   0xc022d280-0xc022d300   print_type_u32
>   0xc022d200-0xc022d280   print_type_u16
>   0xc022d180-0xc022d200   print_type_u8
>   0xc09ed778-0xc09ed778   __irqentry_text_end
>   0xc000-0xc0008000   start_first_256B
> 
> After patch:
>   root@ubuntu:/sys/kernel/debug# tail kprobes/blacklist
>   0xc022d540-0xc022d5c0   print_type_s64
>   0xc022d4c0-0xc022d540   print_type_s32
>   0xc022d440-0xc022d4c0   print_type_s16
>   0xc022d3c0-0xc022d440   print_type_s8
>   0xc022d340-0xc022d3c0   print_type_u64
>   0xc022d2c0-0xc022d340   print_type_u32
>   0xc022d240-0xc022d2c0   print_type_u16
>   0xc022d1c0-0xc022d240   print_type_u8
>   0xc09ed7b8-0xc09ed7b8   [__kprobes]
>   0xc000-0xc0008000   [__exceptions]

Looks good to me :)

Acked-by: Masami Hiramatsu 

Thanks!

> 
> Signed-off-by: Naveen N. Rao 
> ---
>  arch/arm64/kernel/probes/kprobes.c | 10 +-
>  arch/powerpc/kernel/kprobes.c  |  4 ++--
>  arch/x86/kernel/kprobes/core.c |  4 ++--
>  include/linux/kprobes.h|  3 ++-
>  kernel/kprobes.c   | 17 -
>  5 files changed, 23 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c 
> b/arch/arm64/kernel/probes/kprobes.c
> index 7f453a71b5a8..340325ec97c6 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -544,17 +544,17 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
>  void __init arch_populate_kprobe_blacklist(void)
>  {
>   insert_kprobe_blacklist((unsigned long)__kprobes_text_start,
> - (unsigned long)__kprobes_text_end);
> + (unsigned long)__kprobes_text_end, 
> "[__kprobes]");
>   insert_kprobe_blacklist((unsigned long)__entry_text_start,
> - (unsigned long)__entry_text_end);
> + (unsigned long)__entry_text_end, "[__entry]");
>   insert_kprobe_blacklist((unsigned long)__idmap_text_start,
> - (unsigned long)__idmap_text_end);
> + (unsigned long)__idmap_text_end, "[__idmap]");
>  
>   if (!is_kernel_in_hyp_mode()) {
>   insert_kprobe_blacklist((unsigned long)__hyp_text_start,
> - (unsigned long)__hyp_text_end);
> + (unsigned long)__hyp_text_end, 
> "[__hyp]");
>   insert_kprobe_blacklist((unsigned long)__hyp_idmap_text_start,
> - (unsigned long)__hyp_idmap_text_end);
> + (unsigned long)__hyp_idmap_text_end, 
> "[__hyp_idmap]");
>   }
>  }
>  
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index f707e42b3482..1b873e19d29b 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -52,9 +52,9 @@ int is_current_kprobe_addr(unsigned long addr)
>  void __init arch_populate_kprobe_blacklist(void)
>  {
>   insert_kprobe_blacklist((unsigned long)__kprobes_text_start,
> - (unsigned long)__kprobes_text_end);
> + (unsigned long)__kprobes_text_end, 
> "[__kprobes]");
>   insert_kprobe_blacklist((unsigned long)_stext,
> - (unsigned long)__head_end);
> + (unsigned long)__head_end, "[__exceptions]");
>  }
>  
>  kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 4a5fc04b3e92..20e71d783bcf 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -1144,9 +1144,9 @@ NOKPROBE_SYMBOL(longjmp_break_handler);
>  void __init arch_populate_kprobe_blacklist(void)
>  {
>   insert_kprobe_blacklist((unsigned 

Re: [RFC PATCH 2/2] kprobes: Allow specifying names for certain blacklisted address ranges

[Masami Hiramatsu]

On Thu, 29 Jun 2017 19:38:38 +0530
"Naveen N. Rao"  wrote:

> This allows us to provide meaningful names for certain address ranges
> that are blacklisted such as those with __kprobes annotation, kernel
> entry text, and so on. For such ranges, using the symbol/function name
> at the start of the range is misleading.
> 
> On a powerpc64le system, before patch:
>   root@ubuntu:/sys/kernel/debug# tail kprobes/blacklist
>   0xc022d500-0xc022d580   print_type_s64
>   0xc022d480-0xc022d500   print_type_s32
>   0xc022d400-0xc022d480   print_type_s16
>   0xc022d380-0xc022d400   print_type_s8
>   0xc022d300-0xc022d380   print_type_u64
>   0xc022d280-0xc022d300   print_type_u32
>   0xc022d200-0xc022d280   print_type_u16
>   0xc022d180-0xc022d200   print_type_u8
>   0xc09ed778-0xc09ed778   __irqentry_text_end
>   0xc000-0xc0008000   start_first_256B
> 
> After patch:
>   root@ubuntu:/sys/kernel/debug# tail kprobes/blacklist
>   0xc022d540-0xc022d5c0   print_type_s64
>   0xc022d4c0-0xc022d540   print_type_s32
>   0xc022d440-0xc022d4c0   print_type_s16
>   0xc022d3c0-0xc022d440   print_type_s8
>   0xc022d340-0xc022d3c0   print_type_u64
>   0xc022d2c0-0xc022d340   print_type_u32
>   0xc022d240-0xc022d2c0   print_type_u16
>   0xc022d1c0-0xc022d240   print_type_u8
>   0xc09ed7b8-0xc09ed7b8   [__kprobes]
>   0xc000-0xc0008000   [__exceptions]

Looks good to me :)

Acked-by: Masami Hiramatsu 

Thanks!

> 
> Signed-off-by: Naveen N. Rao 
> ---
>  arch/arm64/kernel/probes/kprobes.c | 10 +-
>  arch/powerpc/kernel/kprobes.c  |  4 ++--
>  arch/x86/kernel/kprobes/core.c |  4 ++--
>  include/linux/kprobes.h|  3 ++-
>  kernel/kprobes.c   | 17 -
>  5 files changed, 23 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c 
> b/arch/arm64/kernel/probes/kprobes.c
> index 7f453a71b5a8..340325ec97c6 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -544,17 +544,17 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
>  void __init arch_populate_kprobe_blacklist(void)
>  {
>   insert_kprobe_blacklist((unsigned long)__kprobes_text_start,
> - (unsigned long)__kprobes_text_end);
> + (unsigned long)__kprobes_text_end, 
> "[__kprobes]");
>   insert_kprobe_blacklist((unsigned long)__entry_text_start,
> - (unsigned long)__entry_text_end);
> + (unsigned long)__entry_text_end, "[__entry]");
>   insert_kprobe_blacklist((unsigned long)__idmap_text_start,
> - (unsigned long)__idmap_text_end);
> + (unsigned long)__idmap_text_end, "[__idmap]");
>  
>   if (!is_kernel_in_hyp_mode()) {
>   insert_kprobe_blacklist((unsigned long)__hyp_text_start,
> - (unsigned long)__hyp_text_end);
> + (unsigned long)__hyp_text_end, 
> "[__hyp]");
>   insert_kprobe_blacklist((unsigned long)__hyp_idmap_text_start,
> - (unsigned long)__hyp_idmap_text_end);
> + (unsigned long)__hyp_idmap_text_end, 
> "[__hyp_idmap]");
>   }
>  }
>  
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index f707e42b3482..1b873e19d29b 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -52,9 +52,9 @@ int is_current_kprobe_addr(unsigned long addr)
>  void __init arch_populate_kprobe_blacklist(void)
>  {
>   insert_kprobe_blacklist((unsigned long)__kprobes_text_start,
> - (unsigned long)__kprobes_text_end);
> + (unsigned long)__kprobes_text_end, 
> "[__kprobes]");
>   insert_kprobe_blacklist((unsigned long)_stext,
> - (unsigned long)__head_end);
> + (unsigned long)__head_end, "[__exceptions]");
>  }
>  
>  kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 4a5fc04b3e92..20e71d783bcf 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -1144,9 +1144,9 @@ NOKPROBE_SYMBOL(longjmp_break_handler);
>  void __init arch_populate_kprobe_blacklist(void)
>  {
>   insert_kprobe_blacklist((unsigned long)__kprobes_text_start,
> - (unsigned 

Re: [RFC PATCH 1/2] kprobes: Simplify kprobe blacklist management

[Masami Hiramatsu]

Hi Naveen,

On Thu, 29 Jun 2017 19:38:37 +0530
"Naveen N. Rao"  wrote:

> Currently, the kprobe blacklist file in debugfs (usually
> /sys/kernel/debug/kprobes/blacklist) does not capture all address
> ranges that are blacklisted. For instance, functions annotated with
> __kprobes (between __kprobes_text_start and __kprobes_text_end) are
> blacklisted on all architectures. Certain architectures have additional
> address ranges that are blacklisted.

Ah, I see. The problem is that the blacklist is not populated for
arch-dependent areas.

> 
> These address ranges are currently prevented from being kprobe'd by
> arch_within_kprobe_blacklist(). Instead, add the relevant address ranges
> to the main kprobe blacklist allowing such address ranges to be
> discovered by userspace.
> 
> With this patch, on powerpc64le, we see 2 additional entries at the end
> of the blacklist:
> root@ubuntu:/sys/kernel/debug# tail kprobes/blacklist
> 0xc022d500-0xc022d580 print_type_s64
> 0xc022d480-0xc022d500 print_type_s32
> 0xc022d400-0xc022d480 print_type_s16
> 0xc022d380-0xc022d400 print_type_s8
> 0xc022d300-0xc022d380 print_type_u64
> 0xc022d280-0xc022d300 print_type_u32
> 0xc022d200-0xc022d280 print_type_u16
> 0xc022d180-0xc022d200 print_type_u8
> 0xc09ed778-0xc09ed778 __irqentry_text_end
> 0xc000-0xc0008000 start_first_256B
> 
> __irqentry_text_end() happens to be at __kprobes_text_start and hence
> figures there. Ditto with start_first_256B(). A subsequent patch helps
> provide meaningful names for such address ranges.
> 

OK, looks good to me :)

Acked-by: Masami Hiramatsu 

Thank you!

> Signed-off-by: Naveen N. Rao 
> ---
>  arch/arm64/kernel/probes/kprobes.c | 31 +-
>  arch/powerpc/kernel/kprobes.c  | 10 +++---
>  arch/x86/kernel/kprobes/core.c | 10 +++---
>  include/linux/kprobes.h|  2 ++
>  kernel/kprobes.c   | 64 
> ++
>  5 files changed, 66 insertions(+), 51 deletions(-)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c 
> b/arch/arm64/kernel/probes/kprobes.c
> index c5c45942fb6e..7f453a71b5a8 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -535,24 +535,27 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
> struct pt_regs *regs)
>  
>  bool arch_within_kprobe_blacklist(unsigned long addr)
>  {
> - if ((addr >= (unsigned long)__kprobes_text_start &&
> - addr < (unsigned long)__kprobes_text_end) ||
> - (addr >= (unsigned long)__entry_text_start &&
> - addr < (unsigned long)__entry_text_end) ||
> - (addr >= (unsigned long)__idmap_text_start &&
> - addr < (unsigned long)__idmap_text_end) ||
> - !!search_exception_tables(addr))
> + if (!!search_exception_tables(addr))
>   return true;
>  
> + return false;
> +}
> +
> +void __init arch_populate_kprobe_blacklist(void)
> +{
> + insert_kprobe_blacklist((unsigned long)__kprobes_text_start,
> + (unsigned long)__kprobes_text_end);
> + insert_kprobe_blacklist((unsigned long)__entry_text_start,
> + (unsigned long)__entry_text_end);
> + insert_kprobe_blacklist((unsigned long)__idmap_text_start,
> + (unsigned long)__idmap_text_end);
> +
>   if (!is_kernel_in_hyp_mode()) {
> - if ((addr >= (unsigned long)__hyp_text_start &&
> - addr < (unsigned long)__hyp_text_end) ||
> - (addr >= (unsigned long)__hyp_idmap_text_start &&
> - addr < (unsigned long)__hyp_idmap_text_end))
> - return true;
> + insert_kprobe_blacklist((unsigned long)__hyp_text_start,
> + (unsigned long)__hyp_text_end);
> + insert_kprobe_blacklist((unsigned long)__hyp_idmap_text_start,
> + (unsigned long)__hyp_idmap_text_end);
>   }
> -
> - return false;
>  }
>  
>  void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 01addfb0ed0a..f707e42b3482 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -49,12 +49,12 @@ int is_current_kprobe_addr(unsigned long addr)
>   return (p && (unsigned long)p->addr == addr) ? 1 : 0;
>  }
>  
> -bool arch_within_kprobe_blacklist(unsigned long addr)
> +void __init arch_populate_kprobe_blacklist(void)
>  {
> - return  (addr >= (unsigned long)__kprobes_text_start &&
> -  addr < (unsigned long)__kprobes_text_end) ||
> - (addr >= (unsigned long)_stext &&
> -  addr < 

Re: [RFC PATCH 1/2] kprobes: Simplify kprobe blacklist management

[Masami Hiramatsu]

Hi Naveen,

On Thu, 29 Jun 2017 19:38:37 +0530
"Naveen N. Rao"  wrote:

> Currently, the kprobe blacklist file in debugfs (usually
> /sys/kernel/debug/kprobes/blacklist) does not capture all address
> ranges that are blacklisted. For instance, functions annotated with
> __kprobes (between __kprobes_text_start and __kprobes_text_end) are
> blacklisted on all architectures. Certain architectures have additional
> address ranges that are blacklisted.

Ah, I see. The problem is that the blacklist is not populated for
arch-dependent areas.

> 
> These address ranges are currently prevented from being kprobe'd by
> arch_within_kprobe_blacklist(). Instead, add the relevant address ranges
> to the main kprobe blacklist allowing such address ranges to be
> discovered by userspace.
> 
> With this patch, on powerpc64le, we see 2 additional entries at the end
> of the blacklist:
> root@ubuntu:/sys/kernel/debug# tail kprobes/blacklist
> 0xc022d500-0xc022d580 print_type_s64
> 0xc022d480-0xc022d500 print_type_s32
> 0xc022d400-0xc022d480 print_type_s16
> 0xc022d380-0xc022d400 print_type_s8
> 0xc022d300-0xc022d380 print_type_u64
> 0xc022d280-0xc022d300 print_type_u32
> 0xc022d200-0xc022d280 print_type_u16
> 0xc022d180-0xc022d200 print_type_u8
> 0xc09ed778-0xc09ed778 __irqentry_text_end
> 0xc000-0xc0008000 start_first_256B
> 
> __irqentry_text_end() happens to be at __kprobes_text_start and hence
> figures there. Ditto with start_first_256B(). A subsequent patch helps
> provide meaningful names for such address ranges.
> 

OK, looks good to me :)

Acked-by: Masami Hiramatsu 

Thank you!

> Signed-off-by: Naveen N. Rao 
> ---
>  arch/arm64/kernel/probes/kprobes.c | 31 +-
>  arch/powerpc/kernel/kprobes.c  | 10 +++---
>  arch/x86/kernel/kprobes/core.c | 10 +++---
>  include/linux/kprobes.h|  2 ++
>  kernel/kprobes.c   | 64 
> ++
>  5 files changed, 66 insertions(+), 51 deletions(-)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c 
> b/arch/arm64/kernel/probes/kprobes.c
> index c5c45942fb6e..7f453a71b5a8 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -535,24 +535,27 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
> struct pt_regs *regs)
>  
>  bool arch_within_kprobe_blacklist(unsigned long addr)
>  {
> - if ((addr >= (unsigned long)__kprobes_text_start &&
> - addr < (unsigned long)__kprobes_text_end) ||
> - (addr >= (unsigned long)__entry_text_start &&
> - addr < (unsigned long)__entry_text_end) ||
> - (addr >= (unsigned long)__idmap_text_start &&
> - addr < (unsigned long)__idmap_text_end) ||
> - !!search_exception_tables(addr))
> + if (!!search_exception_tables(addr))
>   return true;
>  
> + return false;
> +}
> +
> +void __init arch_populate_kprobe_blacklist(void)
> +{
> + insert_kprobe_blacklist((unsigned long)__kprobes_text_start,
> + (unsigned long)__kprobes_text_end);
> + insert_kprobe_blacklist((unsigned long)__entry_text_start,
> + (unsigned long)__entry_text_end);
> + insert_kprobe_blacklist((unsigned long)__idmap_text_start,
> + (unsigned long)__idmap_text_end);
> +
>   if (!is_kernel_in_hyp_mode()) {
> - if ((addr >= (unsigned long)__hyp_text_start &&
> - addr < (unsigned long)__hyp_text_end) ||
> - (addr >= (unsigned long)__hyp_idmap_text_start &&
> - addr < (unsigned long)__hyp_idmap_text_end))
> - return true;
> + insert_kprobe_blacklist((unsigned long)__hyp_text_start,
> + (unsigned long)__hyp_text_end);
> + insert_kprobe_blacklist((unsigned long)__hyp_idmap_text_start,
> + (unsigned long)__hyp_idmap_text_end);
>   }
> -
> - return false;
>  }
>  
>  void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 01addfb0ed0a..f707e42b3482 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -49,12 +49,12 @@ int is_current_kprobe_addr(unsigned long addr)
>   return (p && (unsigned long)p->addr == addr) ? 1 : 0;
>  }
>  
> -bool arch_within_kprobe_blacklist(unsigned long addr)
> +void __init arch_populate_kprobe_blacklist(void)
>  {
> - return  (addr >= (unsigned long)__kprobes_text_start &&
> -  addr < (unsigned long)__kprobes_text_end) ||
> - (addr >= (unsigned long)_stext &&
> -  addr < (unsigned long)__head_end);
> + insert_kprobe_blacklist((unsigned 

RE: [PATCH 4/9] clk: imx: add pllv4 support

[A.s. Dong]

> -Original Message-
> From: Stephen Boyd [mailto:sb...@codeaurora.org]
> Sent: Saturday, July 01, 2017 8:37 AM
> To: Dong Aisheng
> Cc: A.s. Dong; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; mturque...@baylibre.com;
> shawn...@kernel.org; Anson Huang; Jacky Bai
> Subject: Re: [PATCH 4/9] clk: imx: add pllv4 support
> 
> On 06/20, Dong Aisheng wrote:
> > On Mon, Jun 19, 2017 at 06:59:17PM -0700, Stephen Boyd wrote:
> > > On 05/15, Dong Aisheng wrote:
> > > > +
> > > > +   if (clk_pllv4_is_enabled(hw)) {
> > > > +   WARN(1, "clk_pllv4: can't change rate when pll is
> enabled");
> > > > +   return -EINVAL;
> > >
> > > Sad, CLK_SET_RATE_GATE isn't working for you I suppose?
> > >
> >
> > CLK_SET_RATE_GATE can't work in early stage before running
> clk_disable_unused.
> > At that point, the clock tree state is still not consistent with HW.
> > e.g. prepare/enable count is still zero but it's actually enabled due
> > to reset state or bootloader.
> >
> > The code here is adding a double check in case user sets rate in early
> stage.
> >
> > However, probably it could also be moved into clock core as it's not
> > platform dependant behavior?
> >
> 
> Ok. It would be good to fix the core framework to synchronize the
> prepared/enabled state at registration time so we don't need this check
> in the driver.
> 

I will prepare a core fix later and remove these checks first.

Regards
Dong Aisheng

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project

RE: [PATCH 4/9] clk: imx: add pllv4 support

[A.s. Dong]

> -Original Message-
> From: Stephen Boyd [mailto:sb...@codeaurora.org]
> Sent: Saturday, July 01, 2017 8:37 AM
> To: Dong Aisheng
> Cc: A.s. Dong; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; mturque...@baylibre.com;
> shawn...@kernel.org; Anson Huang; Jacky Bai
> Subject: Re: [PATCH 4/9] clk: imx: add pllv4 support
> 
> On 06/20, Dong Aisheng wrote:
> > On Mon, Jun 19, 2017 at 06:59:17PM -0700, Stephen Boyd wrote:
> > > On 05/15, Dong Aisheng wrote:
> > > > +
> > > > +   if (clk_pllv4_is_enabled(hw)) {
> > > > +   WARN(1, "clk_pllv4: can't change rate when pll is
> enabled");
> > > > +   return -EINVAL;
> > >
> > > Sad, CLK_SET_RATE_GATE isn't working for you I suppose?
> > >
> >
> > CLK_SET_RATE_GATE can't work in early stage before running
> clk_disable_unused.
> > At that point, the clock tree state is still not consistent with HW.
> > e.g. prepare/enable count is still zero but it's actually enabled due
> > to reset state or bootloader.
> >
> > The code here is adding a double check in case user sets rate in early
> stage.
> >
> > However, probably it could also be moved into clock core as it's not
> > platform dependant behavior?
> >
> 
> Ok. It would be good to fix the core framework to synchronize the
> prepared/enabled state at registration time so we don't need this check
> in the driver.
> 

I will prepare a core fix later and remove these checks first.

Regards
Dong Aisheng

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project

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

[Stephen Rothwell]

Hi all,

On Fri, 30 Jun 2017 11:51:35 +1000 Stephen Rothwell  
wrote:
>
> On Thu, 29 Jun 2017 02:01:16 + Bard Liao  wrote:
> >  
> > > -Original Message-
> > > From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> > > Sent: Thursday, June 29, 2017 9:54 AM
> > > To: Mark Brown; Liam Girdwood
> > > Cc: Linux-Next Mailing List; Linux Kernel Mailing List; Bard Liao
> > > Subject: linux-next: build failure after merge of the sound-asoc tree
> > > 
> > > Hi all,
> > > 
> > > After merging the sound-asoc tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > sound/soc/codecs/rt5670.c: In function 'rt5670_set_codec_sysclk':
> > > sound/soc/codecs/rt5670.c:2448:57: error: 'codec' undeclared (first use 
> > > in this
> > > function)
> > >   struct rt5670_priv *rt5670 = snd_soc_codec_get_drvdata(codec);
> > >  ^
> > > sound/soc/codecs/rt5670.c:2448:57: note: each undeclared identifier is
> > > reported only once for each function it appears in
> > > sound/soc/codecs/rt5670.c: At top level:
> > > sound/soc/codecs/rt5670.c:2775:16: error: initialization from incompatible
> > > pointer type [-Werror=incompatible-pointer-types]
> > >   .set_sysclk = rt5670_set_codec_sysclk,
> > > ^
> > > sound/soc/codecs/rt5670.c:2775:16: note: (near initialization for
> > > 'soc_codec_dev_rt5670.set_sysclk')
> > > cc1: some warnings being treated as errors
> > > 
> > > Caused by commit
> > > 
> > >   6c28ce3c425e ("ASoC: rt5670: move set_sysclk to codec level")
> > > 
> > > I have used the sound-asoc tree from next-20170628 for today.
> > 
> > Sorry about that. I just sent a patch to fix it. Please check the attached. 
> >  
> 
> I have applied your patch (attached) for today.
> 
> Mark, Liam, please apply.
> 
> Tested-by: Stephen Rothwell 

Ping?

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

On Fri, 30 Jun 2017 11:51:35 +1000 Stephen Rothwell  
wrote:
>
> On Thu, 29 Jun 2017 02:01:16 + Bard Liao  wrote:
> >  
> > > -Original Message-
> > > From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> > > Sent: Thursday, June 29, 2017 9:54 AM
> > > To: Mark Brown; Liam Girdwood
> > > Cc: Linux-Next Mailing List; Linux Kernel Mailing List; Bard Liao
> > > Subject: linux-next: build failure after merge of the sound-asoc tree
> > > 
> > > Hi all,
> > > 
> > > After merging the sound-asoc tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > sound/soc/codecs/rt5670.c: In function 'rt5670_set_codec_sysclk':
> > > sound/soc/codecs/rt5670.c:2448:57: error: 'codec' undeclared (first use 
> > > in this
> > > function)
> > >   struct rt5670_priv *rt5670 = snd_soc_codec_get_drvdata(codec);
> > >  ^
> > > sound/soc/codecs/rt5670.c:2448:57: note: each undeclared identifier is
> > > reported only once for each function it appears in
> > > sound/soc/codecs/rt5670.c: At top level:
> > > sound/soc/codecs/rt5670.c:2775:16: error: initialization from incompatible
> > > pointer type [-Werror=incompatible-pointer-types]
> > >   .set_sysclk = rt5670_set_codec_sysclk,
> > > ^
> > > sound/soc/codecs/rt5670.c:2775:16: note: (near initialization for
> > > 'soc_codec_dev_rt5670.set_sysclk')
> > > cc1: some warnings being treated as errors
> > > 
> > > Caused by commit
> > > 
> > >   6c28ce3c425e ("ASoC: rt5670: move set_sysclk to codec level")
> > > 
> > > I have used the sound-asoc tree from next-20170628 for today.
> > 
> > Sorry about that. I just sent a patch to fix it. Please check the attached. 
> >  
> 
> I have applied your patch (attached) for today.
> 
> Mark, Liam, please apply.
> 
> Tested-by: Stephen Rothwell 

Ping?

-- 
Cheers,
Stephen Rothwell

RE: [PATCH 9/9] clk: imx: add imx7ulp clk driver

[A.s. Dong]

> -Original Message-
> From: Stephen Boyd [mailto:sb...@codeaurora.org]
> Sent: Saturday, July 01, 2017 8:35 AM
> To: A.s. Dong
> Cc: Dong Aisheng; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; mturque...@baylibre.com;
> shawn...@kernel.org; Anson Huang; Jacky Bai
> Subject: Re: [PATCH 9/9] clk: imx: add imx7ulp clk driver
> 
> On 06/21, A.s. Dong wrote:
> > > -Original Message-
> > > From: Stephen Boyd [mailto:sb...@codeaurora.org]
> > > Sent: Wednesday, June 21, 2017 4:42 AM
> > > To: Dong Aisheng
> > > Cc: A.s. Dong; linux-...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > mturque...@baylibre.com; shawn...@kernel.org; Anson Huang; Jacky Bai
> > > Subject: Re: [PATCH 9/9] clk: imx: add imx7ulp clk driver
> > >
> > > On 06/20, Dong Aisheng wrote:
> > > > On Mon, Jun 19, 2017 at 07:01:19PM -0700, Stephen Boyd wrote:
> > > > >
> > > > > Any reason why it can't be a platform driver? If not, please add
> > > > > some comment explaining why.
> > > > >
> > > >
> > > > Timer is using it at early stage. GIC seems not although standard
> > > > binding claim possible clock requirement.
> > > > Others still not sure.
> > > >
> > > > What your suggestion?
> > > > Convert timer to platform driver and make clock as platform driver
> > > > as
> > > well?
> > > >
> > >
> > > The timer can't be a platform driver because it would be too late.
> > > The clock driver could register whatever clks are required for the
> > > timer/GIC in a CLK_OF_DECLARE_DRIVER hook, and then leave the rest
> > > to a platform driver. This way we get some of the device driver
> framework in this code.
> > >
> >
> > Okay, I could try it. Thanks.
> >
> > One thing is that TPM clock has a lot parents and parents having
> > parents, as well as PIT timer. So I may need enable more than half
> > clocks in CLK_OF_DECLARE_DRIVER hook.
> 
> That's fine.
> 
> >
> > BTW, What's benefit to convert into two parts of probe?
> > I'm not quite if I already get it all, can you help clarify it?
> >
> 
> The benefit is that we still get a platform driver and we can associate a
> device pointer with the clock controller eventually.
> Here's a reply I sent yesterday on the same topic:
> 
> Reasons (in no particular order):
> 
>   1. We get a dev pointer to use with clk_hw_register()
> 
>   2. We can handle probe defer if some resource is not available
> 
>   3. Using device model gets us a hook into power management frameworks
>  like runtime PM and system PM for things like suspend and hibernate
> 
>   4. It encourages a single DT node clk controller style binding
>  instead of a single node per clk style binding
> 
>   5. We can use non-DT specific functions like devm_ioremap_resource() to
> map
>  registers and acquire other resources, leading to more portable and
>  generic code
> 
>   6. We may be able to make the device driver a module, which will
>  make distros happy if we don't have to compile in all
>  these clk drivers to the resulting vmlinux (this one doesn't
>  apply here)
> 

Very clear.
Thanks for the great explanation.

Regards
Dong Aisheng

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project

RE: [PATCH 9/9] clk: imx: add imx7ulp clk driver

[A.s. Dong]

> -Original Message-
> From: Stephen Boyd [mailto:sb...@codeaurora.org]
> Sent: Saturday, July 01, 2017 8:35 AM
> To: A.s. Dong
> Cc: Dong Aisheng; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; mturque...@baylibre.com;
> shawn...@kernel.org; Anson Huang; Jacky Bai
> Subject: Re: [PATCH 9/9] clk: imx: add imx7ulp clk driver
> 
> On 06/21, A.s. Dong wrote:
> > > -Original Message-
> > > From: Stephen Boyd [mailto:sb...@codeaurora.org]
> > > Sent: Wednesday, June 21, 2017 4:42 AM
> > > To: Dong Aisheng
> > > Cc: A.s. Dong; linux-...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > mturque...@baylibre.com; shawn...@kernel.org; Anson Huang; Jacky Bai
> > > Subject: Re: [PATCH 9/9] clk: imx: add imx7ulp clk driver
> > >
> > > On 06/20, Dong Aisheng wrote:
> > > > On Mon, Jun 19, 2017 at 07:01:19PM -0700, Stephen Boyd wrote:
> > > > >
> > > > > Any reason why it can't be a platform driver? If not, please add
> > > > > some comment explaining why.
> > > > >
> > > >
> > > > Timer is using it at early stage. GIC seems not although standard
> > > > binding claim possible clock requirement.
> > > > Others still not sure.
> > > >
> > > > What your suggestion?
> > > > Convert timer to platform driver and make clock as platform driver
> > > > as
> > > well?
> > > >
> > >
> > > The timer can't be a platform driver because it would be too late.
> > > The clock driver could register whatever clks are required for the
> > > timer/GIC in a CLK_OF_DECLARE_DRIVER hook, and then leave the rest
> > > to a platform driver. This way we get some of the device driver
> framework in this code.
> > >
> >
> > Okay, I could try it. Thanks.
> >
> > One thing is that TPM clock has a lot parents and parents having
> > parents, as well as PIT timer. So I may need enable more than half
> > clocks in CLK_OF_DECLARE_DRIVER hook.
> 
> That's fine.
> 
> >
> > BTW, What's benefit to convert into two parts of probe?
> > I'm not quite if I already get it all, can you help clarify it?
> >
> 
> The benefit is that we still get a platform driver and we can associate a
> device pointer with the clock controller eventually.
> Here's a reply I sent yesterday on the same topic:
> 
> Reasons (in no particular order):
> 
>   1. We get a dev pointer to use with clk_hw_register()
> 
>   2. We can handle probe defer if some resource is not available
> 
>   3. Using device model gets us a hook into power management frameworks
>  like runtime PM and system PM for things like suspend and hibernate
> 
>   4. It encourages a single DT node clk controller style binding
>  instead of a single node per clk style binding
> 
>   5. We can use non-DT specific functions like devm_ioremap_resource() to
> map
>  registers and acquire other resources, leading to more portable and
>  generic code
> 
>   6. We may be able to make the device driver a module, which will
>  make distros happy if we don't have to compile in all
>  these clk drivers to the resulting vmlinux (this one doesn't
>  apply here)
> 

Very clear.
Thanks for the great explanation.

Regards
Dong Aisheng

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project

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

[Stephen Rothwell]

Hi all,

With the merge window opening, just a reminder that this semantic
conflict still exists.

On Wed, 28 Jun 2017 13:43:10 +1000 Stephen Rothwell  
wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t'
>  static int hidp_session_wake_function(wait_queue_t *wait,
>^
> In file included from include/linux/mmzone.h:9:0,
>  from include/linux/gfp.h:5,
>  from include/linux/kmod.h:22,
>  from include/linux/module.h:13,
>  from net/bluetooth/hidp/core.c:25:
> net/bluetooth/hidp/core.c: In function 'hidp_session_thread':
> net/bluetooth/hidp/core.c:1259:30: error: 'hidp_session_wake_function' 
> undeclared (first use in this function)
>   DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
>   ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
>.func  = function, \
> ^
> net/bluetooth/hidp/core.c:1259:30: note: each undeclared identifier is 
> reported only once for each function it appears in
>   DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
>   ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
>.func  = function, \
> ^
> 
> Caused by commit
> 
>   ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
> 
> interacting with commit
> 
>   5da8e47d849d ("Bluetooth: hidp: fix possible might sleep error in 
> hidp_session_thread")
> 
> from the bluetooth tree.  I should have fixed this up in the merge, sorry.
> I added the following merge fix for today.
> 
> From: Stephen Rothwell 
> Date: Wed, 28 Jun 2017 13:36:04 +1000
> Subject: [PATCH] Bluetooth: hidp: fix for "sched/wait: Rename wait_queue_t =>
>  wait_queue_entry_t"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  net/bluetooth/hidp/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index 472b3907b1b0..002743ea509c 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -1238,7 +1238,7 @@ static void hidp_session_run(struct hidp_session 
> *session)
>   smp_mb__after_atomic();
>  }
>  
> -static int hidp_session_wake_function(wait_queue_t *wait,
> +static int hidp_session_wake_function(wait_queue_entry_t *wait,
> unsigned int mode,
> int sync, void *key)
>  {
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

With the merge window opening, just a reminder that this semantic
conflict still exists.

On Wed, 28 Jun 2017 13:43:10 +1000 Stephen Rothwell  
wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> net/bluetooth/hidp/core.c:1241:39: error: unknown type name 'wait_queue_t'
>  static int hidp_session_wake_function(wait_queue_t *wait,
>^
> In file included from include/linux/mmzone.h:9:0,
>  from include/linux/gfp.h:5,
>  from include/linux/kmod.h:22,
>  from include/linux/module.h:13,
>  from net/bluetooth/hidp/core.c:25:
> net/bluetooth/hidp/core.c: In function 'hidp_session_thread':
> net/bluetooth/hidp/core.c:1259:30: error: 'hidp_session_wake_function' 
> undeclared (first use in this function)
>   DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
>   ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
>.func  = function, \
> ^
> net/bluetooth/hidp/core.c:1259:30: note: each undeclared identifier is 
> reported only once for each function it appears in
>   DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
>   ^
> include/linux/wait.h:954:12: note: in definition of macro 'DEFINE_WAIT_FUNC'
>.func  = function, \
> ^
> 
> Caused by commit
> 
>   ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
> 
> interacting with commit
> 
>   5da8e47d849d ("Bluetooth: hidp: fix possible might sleep error in 
> hidp_session_thread")
> 
> from the bluetooth tree.  I should have fixed this up in the merge, sorry.
> I added the following merge fix for today.
> 
> From: Stephen Rothwell 
> Date: Wed, 28 Jun 2017 13:36:04 +1000
> Subject: [PATCH] Bluetooth: hidp: fix for "sched/wait: Rename wait_queue_t =>
>  wait_queue_entry_t"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  net/bluetooth/hidp/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index 472b3907b1b0..002743ea509c 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -1238,7 +1238,7 @@ static void hidp_session_run(struct hidp_session 
> *session)
>   smp_mb__after_atomic();
>  }
>  
> -static int hidp_session_wake_function(wait_queue_t *wait,
> +static int hidp_session_wake_function(wait_queue_entry_t *wait,
> unsigned int mode,
> int sync, void *key)
>  {
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the jc_docs tree with the kbuild tree

[Stephen Rothwell]

Hi all,

With the merge window opening, just a reminder that this conflict still
exists.

On Mon, 26 Jun 2017 11:13:31 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the jc_docs tree got a conflict in:
> 
>   scripts/kernel-doc-xml-ref
> 
> between commit:
> 
>   cb77f0d623ff ("scripts: Switch to more portable Perl shebang")
> 
> from the kbuild tree and commit:
> 
>   52b3f239bb69 ("Docs: clean up some DocBook loose ends")
> 
> from the jc_docs tree.
> 
> I fixed it up (the latter removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the jc_docs tree with the kbuild tree

[Stephen Rothwell]

Hi all,

With the merge window opening, just a reminder that this conflict still
exists.

On Mon, 26 Jun 2017 11:13:31 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the jc_docs tree got a conflict in:
> 
>   scripts/kernel-doc-xml-ref
> 
> between commit:
> 
>   cb77f0d623ff ("scripts: Switch to more portable Perl shebang")
> 
> from the kbuild tree and commit:
> 
>   52b3f239bb69 ("Docs: clean up some DocBook loose ends")
> 
> from the jc_docs tree.
> 
> I fixed it up (the latter removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

With the merge window opening, just a reminder that this conflict still
exists.

On Mon, 26 Jun 2017 10:51:54 +1000 Stephen Rothwell  
wrote:
>
> Hi Bjorn,
> 
> Today's linux-next merge of the pci tree got a conflict in:
> 
>   drivers/gpu/drm/radeon/radeon_device.c
> 
> between commit:
> 
>   4eb59793cca0 ("drm/radeon: add a PX quirk for another K53TK variant")
> 
> from Linus' tree and commit:
> 
>   22c21de73087 ("drm/radeon: make MacBook Pro d3_delay quirk more generic")
> 
> from the pci tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/radeon/radeon_device.c
> index 0a6444d72000,aecaafbc8417..
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@@ -136,12 -135,6 +135,10 @@@ static struct radeon_px_quirk radeon_px
>* https://bugzilla.kernel.org/show_bug.cgi?id=51381
>*/
>   { PCI_VENDOR_ID_ATI, 0x6840, 0x1043, 0x2122, RADEON_PX_QUIRK_DISABLE_PX 
> },
>  +/* Asus K53TK laptop with AMD A6-3420M APU and Radeon 7670m GPU
>  + * https://bugs.freedesktop.org/show_bug.cgi?id=101491
>  + */
>  +{ PCI_VENDOR_ID_ATI, 0x6741, 0x1043, 0x2122, RADEON_PX_QUIRK_DISABLE_PX 
> },
> - /* macbook pro 8.2 */
> - { PCI_VENDOR_ID_ATI, 0x6741, PCI_VENDOR_ID_APPLE, 0x00e2, 
> RADEON_PX_QUIRK_LONG_WAKEUP },
>   { 0, 0, 0, 0, 0 },
>   };
>   

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

With the merge window opening, just a reminder that this conflict still
exists.

On Mon, 26 Jun 2017 10:51:54 +1000 Stephen Rothwell  
wrote:
>
> Hi Bjorn,
> 
> Today's linux-next merge of the pci tree got a conflict in:
> 
>   drivers/gpu/drm/radeon/radeon_device.c
> 
> between commit:
> 
>   4eb59793cca0 ("drm/radeon: add a PX quirk for another K53TK variant")
> 
> from Linus' tree and commit:
> 
>   22c21de73087 ("drm/radeon: make MacBook Pro d3_delay quirk more generic")
> 
> from the pci tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/radeon/radeon_device.c
> index 0a6444d72000,aecaafbc8417..
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@@ -136,12 -135,6 +135,10 @@@ static struct radeon_px_quirk radeon_px
>* https://bugzilla.kernel.org/show_bug.cgi?id=51381
>*/
>   { PCI_VENDOR_ID_ATI, 0x6840, 0x1043, 0x2122, RADEON_PX_QUIRK_DISABLE_PX 
> },
>  +/* Asus K53TK laptop with AMD A6-3420M APU and Radeon 7670m GPU
>  + * https://bugs.freedesktop.org/show_bug.cgi?id=101491
>  + */
>  +{ PCI_VENDOR_ID_ATI, 0x6741, 0x1043, 0x2122, RADEON_PX_QUIRK_DISABLE_PX 
> },
> - /* macbook pro 8.2 */
> - { PCI_VENDOR_ID_ATI, 0x6741, PCI_VENDOR_ID_APPLE, 0x00e2, 
> RADEON_PX_QUIRK_LONG_WAKEUP },
>   { 0, 0, 0, 0, 0 },
>   };
>   

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the sound-asoc tree with the pm tree

[Stephen Rothwell]

Hi all,

[cc-ing the sound tree maintainer]

With the merge window opening, just a reminder that this conflict
still exists.

On Fri, 23 Jun 2017 12:25:34 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the sound-asoc tree got a conflict in:
> 
>   drivers/of/base.c
> 
> between commit:
> 
>   1df09bc66f9b ("of: Move OF property and graph API from base.c to 
> property.c")
> 
> from the pm tree and commits:
> 
>   4c9c3d595f1b ("of_graph: add of_graph_get_remote_endpoint()")
>   0ef472a973eb ("of_graph: add of_graph_get_port_parent()")
>   ac1e6958d3be ("of_graph: add of_graph_get_endpoint_count()")
> 
> from the sound-asoc tree.
> 
> This pm tree commit appeared briefly in the devicetree tree 9 days ago,
> so I have done the same resolution as I did then.
> 
> I added the merge fix patch below. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
> 
> From: Stephen Rothwell 
> Date: Fri, 23 Jun 2017 12:22:19 +1000
> Subject: [PATCH] of_graph: merge fix up for creating of drivers/of/property.c
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/of/property.c | 60 
> ++-
>  1 file changed, 50 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index c96389b7c6b3..eda50b4be934 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -684,6 +684,41 @@ struct device_node *of_graph_get_endpoint_by_regs(
>  EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
>  
>  /**
> + * of_graph_get_remote_endpoint() - get remote endpoint node
> + * @node: pointer to a local endpoint device_node
> + *
> + * Return: Remote endpoint node associated with remote endpoint node linked
> + *  to @node. Use of_node_put() on it when done.
> + */
> +struct device_node *of_graph_get_remote_endpoint(const struct device_node 
> *node)
> +{
> + /* Get remote endpoint node. */
> + return of_parse_phandle(node, "remote-endpoint", 0);
> +}
> +EXPORT_SYMBOL(of_graph_get_remote_endpoint);
> +
> +/**
> + * of_graph_get_port_parent() - get port's parent node
> + * @node: pointer to a local endpoint device_node
> + *
> + * Return: device node associated with endpoint node linked
> + *  to @node. Use of_node_put() on it when done.
> + */
> +struct device_node *of_graph_get_port_parent(struct device_node *node)
> +{
> + unsigned int depth;
> +
> + /* Walk 3 levels up only if there is 'ports' node. */
> + for (depth = 3; depth && node; depth--) {
> + node = of_get_next_parent(node);
> + if (depth == 2 && of_node_cmp(node->name, "ports"))
> + break;
> + }
> + return node;
> +}
> +EXPORT_SYMBOL(of_graph_get_port_parent);
> +
> +/**
>   * of_graph_get_remote_port_parent() - get remote port's parent node
>   * @node: pointer to a local endpoint device_node
>   *
> @@ -694,18 +729,11 @@ struct device_node *of_graph_get_remote_port_parent(
>  const struct device_node *node)
>  {
>   struct device_node *np;
> - unsigned int depth;
>  
>   /* Get remote endpoint node. */
> - np = of_parse_phandle(node, "remote-endpoint", 0);
> + np = of_graph_get_remote_endpoint(node);
>  
> - /* Walk 3 levels up only if there is 'ports' node. */
> - for (depth = 3; depth && np; depth--) {
> - np = of_get_next_parent(np);
> - if (depth == 2 && of_node_cmp(np->name, "ports"))
> - break;
> - }
> - return np;
> + return of_graph_get_port_parent(np);
>  }
>  EXPORT_SYMBOL(of_graph_get_remote_port_parent);
>  
> @@ -721,13 +749,25 @@ struct device_node *of_graph_get_remote_port(const 
> struct device_node *node)
>   struct device_node *np;
>  
>   /* Get remote endpoint node. */
> - np = of_parse_phandle(node, "remote-endpoint", 0);
> + np = of_graph_get_remote_endpoint(node);
>   if (!np)
>   return NULL;
>   return of_get_next_parent(np);
>  }
>  EXPORT_SYMBOL(of_graph_get_remote_port);
>  
> +int of_graph_get_endpoint_count(const struct device_node *np)
> +{
> + struct device_node *endpoint;
> + int num = 0;
> +
> + for_each_endpoint_of_node(np, endpoint)
> + num++;
> +
> + return num;
> +}
> +EXPORT_SYMBOL(of_graph_get_endpoint_count);
> +
>  /**
>   * of_graph_get_remote_node() - get remote parent device_node for given 
> port/endpoint
>   * @node: pointer to parent device_node containing graph port/endpoint
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the sound-asoc tree with the pm tree

[Stephen Rothwell]

Hi all,

[cc-ing the sound tree maintainer]

With the merge window opening, just a reminder that this conflict
still exists.

On Fri, 23 Jun 2017 12:25:34 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the sound-asoc tree got a conflict in:
> 
>   drivers/of/base.c
> 
> between commit:
> 
>   1df09bc66f9b ("of: Move OF property and graph API from base.c to 
> property.c")
> 
> from the pm tree and commits:
> 
>   4c9c3d595f1b ("of_graph: add of_graph_get_remote_endpoint()")
>   0ef472a973eb ("of_graph: add of_graph_get_port_parent()")
>   ac1e6958d3be ("of_graph: add of_graph_get_endpoint_count()")
> 
> from the sound-asoc tree.
> 
> This pm tree commit appeared briefly in the devicetree tree 9 days ago,
> so I have done the same resolution as I did then.
> 
> I added the merge fix patch below. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
> 
> From: Stephen Rothwell 
> Date: Fri, 23 Jun 2017 12:22:19 +1000
> Subject: [PATCH] of_graph: merge fix up for creating of drivers/of/property.c
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/of/property.c | 60 
> ++-
>  1 file changed, 50 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index c96389b7c6b3..eda50b4be934 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -684,6 +684,41 @@ struct device_node *of_graph_get_endpoint_by_regs(
>  EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
>  
>  /**
> + * of_graph_get_remote_endpoint() - get remote endpoint node
> + * @node: pointer to a local endpoint device_node
> + *
> + * Return: Remote endpoint node associated with remote endpoint node linked
> + *  to @node. Use of_node_put() on it when done.
> + */
> +struct device_node *of_graph_get_remote_endpoint(const struct device_node 
> *node)
> +{
> + /* Get remote endpoint node. */
> + return of_parse_phandle(node, "remote-endpoint", 0);
> +}
> +EXPORT_SYMBOL(of_graph_get_remote_endpoint);
> +
> +/**
> + * of_graph_get_port_parent() - get port's parent node
> + * @node: pointer to a local endpoint device_node
> + *
> + * Return: device node associated with endpoint node linked
> + *  to @node. Use of_node_put() on it when done.
> + */
> +struct device_node *of_graph_get_port_parent(struct device_node *node)
> +{
> + unsigned int depth;
> +
> + /* Walk 3 levels up only if there is 'ports' node. */
> + for (depth = 3; depth && node; depth--) {
> + node = of_get_next_parent(node);
> + if (depth == 2 && of_node_cmp(node->name, "ports"))
> + break;
> + }
> + return node;
> +}
> +EXPORT_SYMBOL(of_graph_get_port_parent);
> +
> +/**
>   * of_graph_get_remote_port_parent() - get remote port's parent node
>   * @node: pointer to a local endpoint device_node
>   *
> @@ -694,18 +729,11 @@ struct device_node *of_graph_get_remote_port_parent(
>  const struct device_node *node)
>  {
>   struct device_node *np;
> - unsigned int depth;
>  
>   /* Get remote endpoint node. */
> - np = of_parse_phandle(node, "remote-endpoint", 0);
> + np = of_graph_get_remote_endpoint(node);
>  
> - /* Walk 3 levels up only if there is 'ports' node. */
> - for (depth = 3; depth && np; depth--) {
> - np = of_get_next_parent(np);
> - if (depth == 2 && of_node_cmp(np->name, "ports"))
> - break;
> - }
> - return np;
> + return of_graph_get_port_parent(np);
>  }
>  EXPORT_SYMBOL(of_graph_get_remote_port_parent);
>  
> @@ -721,13 +749,25 @@ struct device_node *of_graph_get_remote_port(const 
> struct device_node *node)
>   struct device_node *np;
>  
>   /* Get remote endpoint node. */
> - np = of_parse_phandle(node, "remote-endpoint", 0);
> + np = of_graph_get_remote_endpoint(node);
>   if (!np)
>   return NULL;
>   return of_get_next_parent(np);
>  }
>  EXPORT_SYMBOL(of_graph_get_remote_port);
>  
> +int of_graph_get_endpoint_count(const struct device_node *np)
> +{
> + struct device_node *endpoint;
> + int num = 0;
> +
> + for_each_endpoint_of_node(np, endpoint)
> + num++;
> +
> + return num;
> +}
> +EXPORT_SYMBOL(of_graph_get_endpoint_count);
> +
>  /**
>   * of_graph_get_remote_node() - get remote parent device_node for given 
> port/endpoint
>   * @node: pointer to parent device_node containing graph port/endpoint
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Cheers,
Stephen Rothwell

[lkp-robot] [net] 0b7266402f: kernel_BUG_at_mm/slab_common.c

[kernel test robot]

FYI, we noticed the following commit:

commit: 0b7266402fc6ebfa0af7488f34dc113696511fdd ("net: define usercopy region 
in struct proto slab cache")
https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git 
kspp/usercopy-whitelist/20170619

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | dca6814884 | 0b7266402f |
+--+++
| boot_successes   | 16 | 0  |
| boot_failures| 0  | 16 |
| kernel_BUG_at_mm/slab_common.c   | 0  | 16 |
| invalid_opcode:#[##] | 0  | 16 |
| EIP:kmem_cache_create_usercopy   | 0  | 16 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 16 |
+--+++



[   10.025445] kernel BUG at mm/slab_common.c:469!
[   10.026006] invalid opcode:  [#1]
[   10.026337] Modules linked in:
[   10.026613] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.12.0-rc5-00027-g0b72664 #1
[   10.027265] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   10.028150] task: c026e000 task.stack: c027
[   10.028549] EIP: kmem_cache_create_usercopy+0x2d8/0x320
[   10.028993] EFLAGS: 00210203 CPU: 0
[   10.029325] EAX:  EBX: c1db6300 ECX:  EDX: 0001
[   10.029851] ESI: 0498 EDI:  EBP: c0271ed8 ESP: c0271eb0
[   10.030381]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[   10.030834] CR0: 80050033 CR2:  CR3: 01ee8000 CR4: 06f0
[   10.031381] Call Trace:
[   10.031598]  ? __mutex_unlock_slowpath+0xb6/0x3b0
[   10.031998]  proto_register+0x55/0x240
[   10.032326]  sctp_init+0x2f2/0x3bd
[   10.032620]  ? sctp_defaults_init+0x2e8/0x2e8
[   10.032992]  do_one_initcall+0x38/0x1a0
[   10.033349]  ? parse_args+0x1ac/0x2f0
[   10.033668]  ? kernel_init_freeable+0xe2/0x17a
[   10.034049]  kernel_init_freeable+0x102/0x17a
[   10.034438]  ? rest_init+0xb0/0xb0
[   10.034738]  kernel_init+0x10/0x100
[   10.035041]  ? schedule_tail_wrapper+0x9/0x10
[   10.035423]  ret_from_fork+0x19/0x30
[   10.035732] Code: ff ff ff 89 45 08 e9 1d ff ff ff 90 8d b4 26 00 00 00 00 
c7 04 24 00 00 00 00 31 c9 ba 01 00 00 00 b8 c0 5b de c1 e8 78 a6 f9 ff <0f> 0b 
8d b6 00 00 00 00 0f 0b c7 04 24 58 20 c3 c1 e8 1a 7e fd
[   10.037391] EIP: kmem_cache_create_usercopy+0x2d8/0x320 SS:ESP: 0068:c0271eb0
[   10.038029] ---[ end trace 5e68488e73a534a7 ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.12.0-rc5 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# 

[lkp-robot] [net] 0b7266402f: kernel_BUG_at_mm/slab_common.c

[kernel test robot]

FYI, we noticed the following commit:

commit: 0b7266402fc6ebfa0af7488f34dc113696511fdd ("net: define usercopy region 
in struct proto slab cache")
https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git 
kspp/usercopy-whitelist/20170619

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | dca6814884 | 0b7266402f |
+--+++
| boot_successes   | 16 | 0  |
| boot_failures| 0  | 16 |
| kernel_BUG_at_mm/slab_common.c   | 0  | 16 |
| invalid_opcode:#[##] | 0  | 16 |
| EIP:kmem_cache_create_usercopy   | 0  | 16 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 16 |
+--+++



[   10.025445] kernel BUG at mm/slab_common.c:469!
[   10.026006] invalid opcode:  [#1]
[   10.026337] Modules linked in:
[   10.026613] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.12.0-rc5-00027-g0b72664 #1
[   10.027265] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   10.028150] task: c026e000 task.stack: c027
[   10.028549] EIP: kmem_cache_create_usercopy+0x2d8/0x320
[   10.028993] EFLAGS: 00210203 CPU: 0
[   10.029325] EAX:  EBX: c1db6300 ECX:  EDX: 0001
[   10.029851] ESI: 0498 EDI:  EBP: c0271ed8 ESP: c0271eb0
[   10.030381]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[   10.030834] CR0: 80050033 CR2:  CR3: 01ee8000 CR4: 06f0
[   10.031381] Call Trace:
[   10.031598]  ? __mutex_unlock_slowpath+0xb6/0x3b0
[   10.031998]  proto_register+0x55/0x240
[   10.032326]  sctp_init+0x2f2/0x3bd
[   10.032620]  ? sctp_defaults_init+0x2e8/0x2e8
[   10.032992]  do_one_initcall+0x38/0x1a0
[   10.033349]  ? parse_args+0x1ac/0x2f0
[   10.033668]  ? kernel_init_freeable+0xe2/0x17a
[   10.034049]  kernel_init_freeable+0x102/0x17a
[   10.034438]  ? rest_init+0xb0/0xb0
[   10.034738]  kernel_init+0x10/0x100
[   10.035041]  ? schedule_tail_wrapper+0x9/0x10
[   10.035423]  ret_from_fork+0x19/0x30
[   10.035732] Code: ff ff ff 89 45 08 e9 1d ff ff ff 90 8d b4 26 00 00 00 00 
c7 04 24 00 00 00 00 31 c9 ba 01 00 00 00 b8 c0 5b de c1 e8 78 a6 f9 ff <0f> 0b 
8d b6 00 00 00 00 0f 0b c7 04 24 58 20 c3 c1 e8 1a 7e fd
[   10.037391] EIP: kmem_cache_create_usercopy+0x2d8/0x320 SS:ESP: 0068:c0271eb0
[   10.038029] ---[ end trace 5e68488e73a534a7 ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.12.0-rc5 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# 

Re: [PATCH v5 07/12] x86/apic: Unify interrupt mode setup for UP system

[Dou Liyang]

Hi Thomas,

At 07/03/2017 02:19 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

 static inline int apic_force_enable(unsigned long addr)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 0601054..9bf7e95 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1198,6 +1198,10 @@ static int __init apic_intr_mode_select(int *upmode)
}
 #endif

+#ifdef CONFIG_UP_LATE_INIT
+   *upmode = true;
+#endif


This is really wrong. The upmode decision, which is required for calling
apic_bsp_setup() should not happen here, really. As I told you in the
previous patch, use the return code and then you can make further decisions
in apic_intr_mode_init().


Really thanks for your detail explaining, I learned more than i read
from books about the programming skill.



And you do it there w/o any ifdeffery:

static void apic_intr_mode_init(void)
{
bool upmode = IS_ENABLED(CONFIG_UP_LATE_INIT);

switch () {
case :
upmode = true;

}
apic_bsp_setup(upmode);
}


This looks more beautiful than mine.  I will use it in the next version.

Thanks,

dou.



Thanks,

tglx

Re: [PATCH v5 05/12] x86/apic: Unify interrupt mode setup for SMP-capable system

[Dou Liyang]

Hi Thomas,

At 07/03/2017 02:07 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

-static int __init apic_intr_mode_select(void)
+static int __init apic_intr_mode_select(int *upmode)
 {
/* Check kernel option */
if (disable_apic) {
@@ -1206,12 +1208,30 @@ static int __init apic_intr_mode_select(void)
if (!smp_found_config) {
disable_ioapic_support();

-   if (!acpi_lapic)
+   if (!acpi_lapic) {
pr_info("APIC: ACPI MADT or MP tables are not 
detected\n");
+   *upmode = true;


That store and extra argument is pointless.


+
+   return APIC_VIRTUAL_WIRE_NO_CONFIG;


You added an extra return code, which you can use exactly for that purpose
at the callsite.



Actually indeed. Great! Why didn't I think of that?



Aside of that, if you use int * then use numbers, if you use bool then use
true/false. But mixing that is horrible.



Yes, it is, I will remove the 'upmode' argument.


Thanks,

dou.


+   }


Thanks,

tglx

Re: [PATCH v5 05/12] x86/apic: Unify interrupt mode setup for SMP-capable system

[Dou Liyang]

Hi Thomas,

At 07/03/2017 02:07 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

-static int __init apic_intr_mode_select(void)
+static int __init apic_intr_mode_select(int *upmode)
 {
/* Check kernel option */
if (disable_apic) {
@@ -1206,12 +1208,30 @@ static int __init apic_intr_mode_select(void)
if (!smp_found_config) {
disable_ioapic_support();

-   if (!acpi_lapic)
+   if (!acpi_lapic) {
pr_info("APIC: ACPI MADT or MP tables are not 
detected\n");
+   *upmode = true;


That store and extra argument is pointless.


+
+   return APIC_VIRTUAL_WIRE_NO_CONFIG;


You added an extra return code, which you can use exactly for that purpose
at the callsite.



Actually indeed. Great! Why didn't I think of that?



Aside of that, if you use int * then use numbers, if you use bool then use
true/false. But mixing that is horrible.



Yes, it is, I will remove the 'upmode' argument.


Thanks,

dou.


+   }


Thanks,

tglx

Re: [PATCH v5 07/12] x86/apic: Unify interrupt mode setup for UP system

[Dou Liyang]

Hi Thomas,

At 07/03/2017 02:19 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

 static inline int apic_force_enable(unsigned long addr)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 0601054..9bf7e95 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1198,6 +1198,10 @@ static int __init apic_intr_mode_select(int *upmode)
}
 #endif

+#ifdef CONFIG_UP_LATE_INIT
+   *upmode = true;
+#endif


This is really wrong. The upmode decision, which is required for calling
apic_bsp_setup() should not happen here, really. As I told you in the
previous patch, use the return code and then you can make further decisions
in apic_intr_mode_init().


Really thanks for your detail explaining, I learned more than i read
from books about the programming skill.



And you do it there w/o any ifdeffery:

static void apic_intr_mode_init(void)
{
bool upmode = IS_ENABLED(CONFIG_UP_LATE_INIT);

switch () {
case :
upmode = true;

}
apic_bsp_setup(upmode);
}


This looks more beautiful than mine.  I will use it in the next version.

Thanks,

dou.



Thanks,

tglx

linux-next: build warning after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from sound/soc/intel/skylake/skl-debug.c:23:0:
sound/soc/intel/skylake/../common/sst-dsp-priv.h:63:42: warning: 'struct 
sst_pdata' declared inside parameter list
  int (*init)(struct sst_dsp *sst, struct sst_pdata *pdata);
  ^
sound/soc/intel/skylake/../common/sst-dsp-priv.h:63:42: warning: its scope is 
only this definition or declaration, which is probably not what you want

Exposed by commit

  bdd0384a5ada ("ASoC: Intel: Skylake: Add support to read firmware registers")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from sound/soc/intel/skylake/skl-debug.c:23:0:
sound/soc/intel/skylake/../common/sst-dsp-priv.h:63:42: warning: 'struct 
sst_pdata' declared inside parameter list
  int (*init)(struct sst_dsp *sst, struct sst_pdata *pdata);
  ^
sound/soc/intel/skylake/../common/sst-dsp-priv.h:63:42: warning: its scope is 
only this definition or declaration, which is probably not what you want

Exposed by commit

  bdd0384a5ada ("ASoC: Intel: Skylake: Add support to read firmware registers")

-- 
Cheers,
Stephen Rothwell

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

[Randy Li]

On 06/27/2017 11:49 PM, Nicolas Dufresne wrote:

Le mardi 27 juin 2017 à 23:11 +0800, Jacob Chen a écrit :

Hi Nicolas.

2017-06-26 23:49 GMT+08:00 Nicolas Dufresne :


Le lundi 26 juin 2017 à 22:51 +0800, Jacob Chen a écrit :

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

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

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

The code in rga-buf.c is used to create private mmu table for
RGA.
The tables is stored in a list, and be removed when buffer is
cleanup.

Signed-off-by: Jacob Chen 
---
  drivers/media/platform/Kconfig|  11 +
  drivers/media/platform/Makefile   |   2 +
  drivers/media/platform/rockchip-rga/Makefile  |   3 +
  drivers/media/platform/rockchip-rga/rga-buf.c | 176 +
  drivers/media/platform/rockchip-rga/rga-hw.c  | 456 
  drivers/media/platform/rockchip-rga/rga-hw.h  | 434 
  drivers/media/platform/rockchip-rga/rga.c | 979
++
  drivers/media/platform/rockchip-rga/rga.h | 133 
  8 files changed, 2194 insertions(+)
  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
  create mode 100644 drivers/media/platform/rockchip-rga/rga.h



Could be nice to generalize. We could setup a control and fill the
values base on porter duff operations, then drivers can implement a
subset. Right now, there is no generic way for userspace to know if
a
driver is just doing copies with some transformations, or if it can
actually do alpha blending hence used for composting streams. Note
that
I haven't looked at all possibilities, Freescale IMX.6 seems to
have a
similar driver, which has been wrapped in GStreamer with this
proposed
elements:

https://bugzilla.gnome.org/show_bug.cgi?id=772766



Yeah, i also want it use a generic api.
"porter duff operations" looks good, i will look at it.


+#define V4L2_CID_RGA_ALHPA_REG0 (V4L2_CID_USER_BASE | 0x1002)
+#define V4L2_CID_RGA_ALHPA_REG1 (V4L2_CID_USER_BASE | 0x1003)


It's not obvious why there is two CID, and how this differ from
existing V4L2_CID_ALPHA (the global alpha control).


They are used to calculate factors for below formulas.

 dst alpha = Factor1 * src alpha + Factor2 * dst alpha
 dst color = Factor3 * src color + Factor4 * dst color

I have no idea how to generalize it, and there is no upstream
application need it,
so i just simply exposed the reg.

In my memory, it is is used for convert AYUV to ARGB.


Then maybe it's better to just not expose it in the public API in the
initial patch (nothing forces you to enable everything). The idea is
that it can be added later as needed, taking the time to figure-out a
new API or to figure-out how this matches anything that exist.




+
+/* Operation values */
+#define OP_COPY 0
+#define OP_SOLID_FILL 1
+#define OP_ALPHA_BLEND 2
+
+struct rga_frame *rga_get_frame(struct rga_ctx *ctx, enum
v4l2_buf_type type);
+
+/* RGA Buffers Manage Part */
+extern const struct vb2_ops rga_qops;
+void *rga_buf_find_page(struct vb2_buffer *vb);
+void rga_buf_clean(struct rga_ctx *ctx);
+
+/* RGA Hardware Part */
+void rga_write(struct rockchip_rga *rga, u32 reg, u32 value);
+u32 rga_read(struct rockchip_rga *rga, u32 reg);
+void rga_mod(struct rockchip_rga *rga, u32 reg, u32 val, u32
mask);
+void rga_start(struct rockchip_rga *rga);
+void rga_cmd_set(struct rga_ctx *ctx, void *src_mmu_pages, void
*dst_mmu_pages);
+
+#endif


--
Randy Li

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

[Randy Li]

On 06/27/2017 11:49 PM, Nicolas Dufresne wrote:

Le mardi 27 juin 2017 à 23:11 +0800, Jacob Chen a écrit :

Hi Nicolas.

2017-06-26 23:49 GMT+08:00 Nicolas Dufresne :


Le lundi 26 juin 2017 à 22:51 +0800, Jacob Chen a écrit :

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

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

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

The code in rga-buf.c is used to create private mmu table for
RGA.
The tables is stored in a list, and be removed when buffer is
cleanup.

Signed-off-by: Jacob Chen 
---
  drivers/media/platform/Kconfig|  11 +
  drivers/media/platform/Makefile   |   2 +
  drivers/media/platform/rockchip-rga/Makefile  |   3 +
  drivers/media/platform/rockchip-rga/rga-buf.c | 176 +
  drivers/media/platform/rockchip-rga/rga-hw.c  | 456 
  drivers/media/platform/rockchip-rga/rga-hw.h  | 434 
  drivers/media/platform/rockchip-rga/rga.c | 979
++
  drivers/media/platform/rockchip-rga/rga.h | 133 
  8 files changed, 2194 insertions(+)
  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
  create mode 100644 drivers/media/platform/rockchip-rga/rga.h



Could be nice to generalize. We could setup a control and fill the
values base on porter duff operations, then drivers can implement a
subset. Right now, there is no generic way for userspace to know if
a
driver is just doing copies with some transformations, or if it can
actually do alpha blending hence used for composting streams. Note
that
I haven't looked at all possibilities, Freescale IMX.6 seems to
have a
similar driver, which has been wrapped in GStreamer with this
proposed
elements:

https://bugzilla.gnome.org/show_bug.cgi?id=772766



Yeah, i also want it use a generic api.
"porter duff operations" looks good, i will look at it.


+#define V4L2_CID_RGA_ALHPA_REG0 (V4L2_CID_USER_BASE | 0x1002)
+#define V4L2_CID_RGA_ALHPA_REG1 (V4L2_CID_USER_BASE | 0x1003)


It's not obvious why there is two CID, and how this differ from
existing V4L2_CID_ALPHA (the global alpha control).


They are used to calculate factors for below formulas.

 dst alpha = Factor1 * src alpha + Factor2 * dst alpha
 dst color = Factor3 * src color + Factor4 * dst color

I have no idea how to generalize it, and there is no upstream
application need it,
so i just simply exposed the reg.

In my memory, it is is used for convert AYUV to ARGB.


Then maybe it's better to just not expose it in the public API in the
initial patch (nothing forces you to enable everything). The idea is
that it can be added later as needed, taking the time to figure-out a
new API or to figure-out how this matches anything that exist.




+
+/* Operation values */
+#define OP_COPY 0
+#define OP_SOLID_FILL 1
+#define OP_ALPHA_BLEND 2
+
+struct rga_frame *rga_get_frame(struct rga_ctx *ctx, enum
v4l2_buf_type type);
+
+/* RGA Buffers Manage Part */
+extern const struct vb2_ops rga_qops;
+void *rga_buf_find_page(struct vb2_buffer *vb);
+void rga_buf_clean(struct rga_ctx *ctx);
+
+/* RGA Hardware Part */
+void rga_write(struct rockchip_rga *rga, u32 reg, u32 value);
+u32 rga_read(struct rockchip_rga *rga, u32 reg);
+void rga_mod(struct rockchip_rga *rga, u32 reg, u32 val, u32
mask);
+void rga_start(struct rockchip_rga *rga);
+void rga_cmd_set(struct rga_ctx *ctx, void *src_mmu_pages, void
*dst_mmu_pages);
+
+#endif


--
Randy Li

Re: [PATCH v2] mm/zsmalloc: simplify zs_max_alloc_size handling

[Minchan Kim]

Forgot to add Andrew.

On Mon, Jul 03, 2017 at 11:13:12AM +0900, Minchan Kim wrote:
> On Fri, Jun 30, 2017 at 01:48:59PM +0200, Jerome Marchand wrote:
> > Commit 40f9fb8cffc6 ("mm/zsmalloc: support allocating obj with size of
> > ZS_MAX_ALLOC_SIZE") fixes a size calculation error that prevented
> > zsmalloc to allocate an object of the maximal size
> > (ZS_MAX_ALLOC_SIZE). I think however the fix is unneededly
> > complicated.
> > 
> > This patch replaces the dynamic calculation of zs_size_classes at init
> > time by a compile time calculation that uses the DIV_ROUND_UP() macro
> > already used in get_size_class_index().
> > 
> > Signed-off-by: Jerome Marchand 
> Acked-by: Minchan Kim 
> 
> Thanks.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH v2] mm/zsmalloc: simplify zs_max_alloc_size handling

[Minchan Kim]

Forgot to add Andrew.

On Mon, Jul 03, 2017 at 11:13:12AM +0900, Minchan Kim wrote:
> On Fri, Jun 30, 2017 at 01:48:59PM +0200, Jerome Marchand wrote:
> > Commit 40f9fb8cffc6 ("mm/zsmalloc: support allocating obj with size of
> > ZS_MAX_ALLOC_SIZE") fixes a size calculation error that prevented
> > zsmalloc to allocate an object of the maximal size
> > (ZS_MAX_ALLOC_SIZE). I think however the fix is unneededly
> > complicated.
> > 
> > This patch replaces the dynamic calculation of zs_size_classes at init
> > time by a compile time calculation that uses the DIV_ROUND_UP() macro
> > already used in get_size_class_index().
> > 
> > Signed-off-by: Jerome Marchand 
> Acked-by: Minchan Kim 
> 
> Thanks.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH v2] mm/zsmalloc: simplify zs_max_alloc_size handling

[Minchan Kim]

On Fri, Jun 30, 2017 at 01:48:59PM +0200, Jerome Marchand wrote:
> Commit 40f9fb8cffc6 ("mm/zsmalloc: support allocating obj with size of
> ZS_MAX_ALLOC_SIZE") fixes a size calculation error that prevented
> zsmalloc to allocate an object of the maximal size
> (ZS_MAX_ALLOC_SIZE). I think however the fix is unneededly
> complicated.
> 
> This patch replaces the dynamic calculation of zs_size_classes at init
> time by a compile time calculation that uses the DIV_ROUND_UP() macro
> already used in get_size_class_index().
> 
> Signed-off-by: Jerome Marchand 
Acked-by: Minchan Kim 

Thanks.

Re: [PATCH v2] mm/zsmalloc: simplify zs_max_alloc_size handling

[Minchan Kim]

On Fri, Jun 30, 2017 at 01:48:59PM +0200, Jerome Marchand wrote:
> Commit 40f9fb8cffc6 ("mm/zsmalloc: support allocating obj with size of
> ZS_MAX_ALLOC_SIZE") fixes a size calculation error that prevented
> zsmalloc to allocate an object of the maximal size
> (ZS_MAX_ALLOC_SIZE). I think however the fix is unneededly
> complicated.
> 
> This patch replaces the dynamic calculation of zs_size_classes at init
> time by a compile time calculation that uses the DIV_ROUND_UP() macro
> already used in get_size_class_index().
> 
> Signed-off-by: Jerome Marchand 
Acked-by: Minchan Kim 

Thanks.

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

[Stephen Rothwell]

Hi Dave,

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

  drivers/gpu/drm/drm_internal.h

between commits:

  012c6741c6aa ("switch compat_drm_version() to drm_ioctl_kernel()")
  17e3dade62d6 ("switch compat_drm_getunique() to drm_ioctl_kernel()")
  9e92662d01d8 ("switch compat_drm_getclient() to drm_ioctl_kernel()")

from the vfs tree and commit:

  e9083420bbac ("drm: introduce sync objects (v4)")

from the drm tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/drm_internal.h
index 14dfa9c83d1d,5cecc974d2f9..
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@@ -142,7 -143,17 +143,20 @@@ static inline int drm_debugfs_crtc_crc_
  {
return 0;
  }
+ 
  #endif
 +drm_ioctl_t drm_version;
 +drm_ioctl_t drm_getunique;
 +drm_ioctl_t drm_getclient;
+ 
+ /* drm_syncobj.c */
+ void drm_syncobj_open(struct drm_file *file_private);
+ void drm_syncobj_release(struct drm_file *file_private);
+ int drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
+ int drm_syncobj_destroy_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
+ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);

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

[Stephen Rothwell]

Hi Dave,

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

  drivers/gpu/drm/drm_internal.h

between commits:

  012c6741c6aa ("switch compat_drm_version() to drm_ioctl_kernel()")
  17e3dade62d6 ("switch compat_drm_getunique() to drm_ioctl_kernel()")
  9e92662d01d8 ("switch compat_drm_getclient() to drm_ioctl_kernel()")

from the vfs tree and commit:

  e9083420bbac ("drm: introduce sync objects (v4)")

from the drm tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/drm_internal.h
index 14dfa9c83d1d,5cecc974d2f9..
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@@ -142,7 -143,17 +143,20 @@@ static inline int drm_debugfs_crtc_crc_
  {
return 0;
  }
+ 
  #endif
 +drm_ioctl_t drm_version;
 +drm_ioctl_t drm_getunique;
 +drm_ioctl_t drm_getclient;
+ 
+ /* drm_syncobj.c */
+ void drm_syncobj_open(struct drm_file *file_private);
+ void drm_syncobj_release(struct drm_file *file_private);
+ int drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
+ int drm_syncobj_destroy_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
+ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);

Re: [PATCH v5 04/12] x86/apic: Move logical APIC ID away from apic_bsp_setup()

[Dou Liyang]

Hi, Thomas

At 07/03/2017 01:54 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

 /*
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 93f0cda..d6721f0 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1347,8 +1347,11 @@ void __init native_smp_prepare_cpus(unsigned int 
max_cpus)
}

default_setup_apic_routing();
-   cpu0_logical_apicid = apic_bsp_setup(false);
-
+   apic_bsp_setup(false);
+   if (x2apic_mode)
+   cpu0_logical_apicid = apic_read(APIC_LDR);
+   else
+   cpu0_logical_apicid = GET_APIC_LOGICAL_ID(apic_read(APIC_LDR));


Can you please move that into a seperate helper function?



Yes, it will be a separate helper function in the next version.

Thanks,

dou.




/* Setup local timer */
x86_init.timers.setup_percpu_clockev();

--
2.5.5

Re: [PATCH v5 04/12] x86/apic: Move logical APIC ID away from apic_bsp_setup()

[Dou Liyang]

Hi, Thomas

At 07/03/2017 01:54 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

 /*
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 93f0cda..d6721f0 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1347,8 +1347,11 @@ void __init native_smp_prepare_cpus(unsigned int 
max_cpus)
}

default_setup_apic_routing();
-   cpu0_logical_apicid = apic_bsp_setup(false);
-
+   apic_bsp_setup(false);
+   if (x2apic_mode)
+   cpu0_logical_apicid = apic_read(APIC_LDR);
+   else
+   cpu0_logical_apicid = GET_APIC_LOGICAL_ID(apic_read(APIC_LDR));


Can you please move that into a seperate helper function?



Yes, it will be a separate helper function in the next version.

Thanks,

dou.




/* Setup local timer */
x86_init.timers.setup_percpu_clockev();

--
2.5.5