linux-next: build warnings after merge of the scsi-mkp tree

[Stephen Rothwell]

Hi Martin,

After merging the scsi-mkp tree, today's linux-next build
(powerpc_ppc64_defconfig) produced these warnings:

In file included from include/linux/byteorder/big_endian.h:4:0,
 from arch/powerpc/include/uapi/asm/byteorder.h:13,
 from include/asm-generic/bitops/le.h:5,
 from arch/powerpc/include/asm/bitops.h:246,
 from include/linux/bitops.h:36,
 from include/linux/kernel.h:10,
 from include/asm-generic/bug.h:15,
 from arch/powerpc/include/asm/bug.h:127,
 from include/linux/bug.h:4,
 from arch/powerpc/include/asm/mmu.h:125,
 from arch/powerpc/include/asm/lppaca.h:36,
 from arch/powerpc/include/asm/paca.h:21,
 from arch/powerpc/include/asm/current.h:16,
 from include/linux/sched.h:11,
 from include/linux/blkdev.h:4,
 from include/linux/blk-mq.h:4,
 from drivers/scsi/qla2xxx/qla_nvme.h:10,
 from drivers/scsi/qla2xxx/qla_nvme.c:7:
drivers/scsi/qla2xxx/qla_nvme.c: In function 'qla2x00_start_nvme_mq':
include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer 
implicitly truncated to unsigned type [-Woverflow]
 #define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
  ^
include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
 #define cpu_to_le32 __cpu_to_le32
 ^
drivers/scsi/qla2xxx/qla_nvme.c:444:27: note: in expansion of macro 
'cpu_to_le32'
cont_pkt->entry_type = cpu_to_le32(CONTINUE_A64_TYPE);
   ^
drivers/scsi/qla2xxx/qla_nvme.c: At top level:
drivers/scsi/qla2xxx/qla_nvme.c:667:13: warning: 
'qla_nvme_unregister_remote_port' defined but not used [-Wunused-function]
 static void qla_nvme_unregister_remote_port(struct work_struct *work)
 ^
drivers/scsi/qla2xxx/qla_nvme.c:604:12: warning: 'qla_nvme_wait_on_rport_del' 
defined but not used [-Wunused-function]
 static int qla_nvme_wait_on_rport_del(fc_port_t *fcport)
^
drivers/scsi/qla2xxx/qla_nvme.c:634:13: warning: 'qla_nvme_abort_all' defined 
but not used [-Wunused-function]
 static void qla_nvme_abort_all(fc_port_t *fcport)
 ^

Introduced by commit

  e84067d74301 ("scsi: qla2xxx: Add FC-NVMe F/W initialization and transport 
registration")

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the scsi-mkp tree

[Stephen Rothwell]

Hi Martin,

After merging the scsi-mkp tree, today's linux-next build
(powerpc_ppc64_defconfig) produced these warnings:

In file included from include/linux/byteorder/big_endian.h:4:0,
 from arch/powerpc/include/uapi/asm/byteorder.h:13,
 from include/asm-generic/bitops/le.h:5,
 from arch/powerpc/include/asm/bitops.h:246,
 from include/linux/bitops.h:36,
 from include/linux/kernel.h:10,
 from include/asm-generic/bug.h:15,
 from arch/powerpc/include/asm/bug.h:127,
 from include/linux/bug.h:4,
 from arch/powerpc/include/asm/mmu.h:125,
 from arch/powerpc/include/asm/lppaca.h:36,
 from arch/powerpc/include/asm/paca.h:21,
 from arch/powerpc/include/asm/current.h:16,
 from include/linux/sched.h:11,
 from include/linux/blkdev.h:4,
 from include/linux/blk-mq.h:4,
 from drivers/scsi/qla2xxx/qla_nvme.h:10,
 from drivers/scsi/qla2xxx/qla_nvme.c:7:
drivers/scsi/qla2xxx/qla_nvme.c: In function 'qla2x00_start_nvme_mq':
include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer 
implicitly truncated to unsigned type [-Woverflow]
 #define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
  ^
include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
 #define cpu_to_le32 __cpu_to_le32
 ^
drivers/scsi/qla2xxx/qla_nvme.c:444:27: note: in expansion of macro 
'cpu_to_le32'
cont_pkt->entry_type = cpu_to_le32(CONTINUE_A64_TYPE);
   ^
drivers/scsi/qla2xxx/qla_nvme.c: At top level:
drivers/scsi/qla2xxx/qla_nvme.c:667:13: warning: 
'qla_nvme_unregister_remote_port' defined but not used [-Wunused-function]
 static void qla_nvme_unregister_remote_port(struct work_struct *work)
 ^
drivers/scsi/qla2xxx/qla_nvme.c:604:12: warning: 'qla_nvme_wait_on_rport_del' 
defined but not used [-Wunused-function]
 static int qla_nvme_wait_on_rport_del(fc_port_t *fcport)
^
drivers/scsi/qla2xxx/qla_nvme.c:634:13: warning: 'qla_nvme_abort_all' defined 
but not used [-Wunused-function]
 static void qla_nvme_abort_all(fc_port_t *fcport)
 ^

Introduced by commit

  e84067d74301 ("scsi: qla2xxx: Add FC-NVMe F/W initialization and transport 
registration")

-- 
Cheers,
Stephen Rothwell

[PATCH] clocksource: timer-ti-32k: Unmap region obtained by of_iomap.

[Arvind Yadav]

In case of error at init time, rollback iomapping.

Signed-off-by: Arvind Yadav 
---
 drivers/clocksource/timer-ti-32k.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/timer-ti-32k.c 
b/drivers/clocksource/timer-ti-32k.c
index 6240677..658d759 100644
--- a/drivers/clocksource/timer-ti-32k.c
+++ b/drivers/clocksource/timer-ti-32k.c
@@ -116,6 +116,7 @@ static int __init ti_32k_timer_init(struct device_node *np)
ret = clocksource_register_hz(_32k_timer.cs, 32768);
if (ret) {
pr_err("32k_counter: can't register clocksource\n");
+   iounmap(ti_32k_timer.base);
return ret;
}
 
-- 
1.9.1

[PATCH] clocksource: timer-ti-32k: Unmap region obtained by of_iomap.

[Arvind Yadav]

In case of error at init time, rollback iomapping.

Signed-off-by: Arvind Yadav 
---
 drivers/clocksource/timer-ti-32k.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/timer-ti-32k.c 
b/drivers/clocksource/timer-ti-32k.c
index 6240677..658d759 100644
--- a/drivers/clocksource/timer-ti-32k.c
+++ b/drivers/clocksource/timer-ti-32k.c
@@ -116,6 +116,7 @@ static int __init ti_32k_timer_init(struct device_node *np)
ret = clocksource_register_hz(_32k_timer.cs, 32768);
if (ret) {
pr_err("32k_counter: can't register clocksource\n");
+   iounmap(ti_32k_timer.base);
return ret;
}
 
-- 
1.9.1

Re: [PATCH 2/6] drivers: perf: hisi: Add support for HiSilicon SoC uncore PMU driver

[Zhangshaokun]

Hi,

On 2017/6/28 9:49, kbuild test robot wrote:
> Hi Shaokun,
> 
> [auto build test ERROR on next-20170619]
> [also build test ERROR on v4.12-rc7]
> [cannot apply to linus/master linux/master arm64/for-next/core v4.12-rc6 
> v4.12-rc5 v4.12-rc4]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Shaokun-Zhang/Add-HiSilicon-SoC-uncore-Performance-Monitoring-Unit-driver/20170628-070841
> config: x86_64-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/perf/hisilicon/hisi_uncore_pmu.c: In function 
> 'hisi_read_scl_and_ccl_id':
>>> drivers/perf/hisilicon/hisi_uncore_pmu.c:72:10: error: implicit declaration 
>>> of function 'read_cpuid_mpidr' [-Werror=implicit-function-declaration]
>  mpidr = read_cpuid_mpidr();
>  ^~~~
>>> drivers/perf/hisilicon/hisi_uncore_pmu.c:73:14: error: 'MPIDR_MT_BITMASK' 
>>> undeclared (first use in this function)
>  if (mpidr & MPIDR_MT_BITMASK) {
>  ^~~~
>drivers/perf/hisilicon/hisi_uncore_pmu.c:73:14: note: each undeclared 
> identifier is reported only once for each function it appears in
>>> drivers/perf/hisilicon/hisi_uncore_pmu.c:75:14: error: implicit declaration 
>>> of function 'MPIDR_AFFINITY_LEVEL' [-Werror=implicit-function-declaration]
>*scl_id = MPIDR_AFFINITY_LEVEL(mpidr, 3);
>  ^~~~
>cc1: some warnings being treated as errors
> 

Apologies for my modified drivers/perf/Kconfig for HISI_PMU.
It depends on ARM64 and i shall remove COMPILE_TEST to fix it.

Thanks.
Shaokun

> vim +/read_cpuid_mpidr +72 drivers/perf/hisilicon/hisi_uncore_pmu.c
> 
> 66
> 67/* Read Super CPU cluster and CPU cluster ID from MPIDR_EL1 */
> 68void hisi_read_scl_and_ccl_id(u32 *scl_id, u32 *ccl_id)
> 69{
> 70u64 mpidr;
> 71
>   > 72mpidr = read_cpuid_mpidr();
>   > 73if (mpidr & MPIDR_MT_BITMASK) {
> 74if (scl_id)
>   > 75*scl_id = MPIDR_AFFINITY_LEVEL(mpidr, 
> 3);
> 76if (ccl_id)
> 77*ccl_id = MPIDR_AFFINITY_LEVEL(mpidr, 
> 2);
> 78} else {
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 
> 
> 
> ___
> linuxarm mailing list
> linux...@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
> 

Re: [PATCH 2/6] drivers: perf: hisi: Add support for HiSilicon SoC uncore PMU driver

[Zhangshaokun]

Hi,

On 2017/6/28 9:49, kbuild test robot wrote:
> Hi Shaokun,
> 
> [auto build test ERROR on next-20170619]
> [also build test ERROR on v4.12-rc7]
> [cannot apply to linus/master linux/master arm64/for-next/core v4.12-rc6 
> v4.12-rc5 v4.12-rc4]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Shaokun-Zhang/Add-HiSilicon-SoC-uncore-Performance-Monitoring-Unit-driver/20170628-070841
> config: x86_64-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/perf/hisilicon/hisi_uncore_pmu.c: In function 
> 'hisi_read_scl_and_ccl_id':
>>> drivers/perf/hisilicon/hisi_uncore_pmu.c:72:10: error: implicit declaration 
>>> of function 'read_cpuid_mpidr' [-Werror=implicit-function-declaration]
>  mpidr = read_cpuid_mpidr();
>  ^~~~
>>> drivers/perf/hisilicon/hisi_uncore_pmu.c:73:14: error: 'MPIDR_MT_BITMASK' 
>>> undeclared (first use in this function)
>  if (mpidr & MPIDR_MT_BITMASK) {
>  ^~~~
>drivers/perf/hisilicon/hisi_uncore_pmu.c:73:14: note: each undeclared 
> identifier is reported only once for each function it appears in
>>> drivers/perf/hisilicon/hisi_uncore_pmu.c:75:14: error: implicit declaration 
>>> of function 'MPIDR_AFFINITY_LEVEL' [-Werror=implicit-function-declaration]
>*scl_id = MPIDR_AFFINITY_LEVEL(mpidr, 3);
>  ^~~~
>cc1: some warnings being treated as errors
> 

Apologies for my modified drivers/perf/Kconfig for HISI_PMU.
It depends on ARM64 and i shall remove COMPILE_TEST to fix it.

Thanks.
Shaokun

> vim +/read_cpuid_mpidr +72 drivers/perf/hisilicon/hisi_uncore_pmu.c
> 
> 66
> 67/* Read Super CPU cluster and CPU cluster ID from MPIDR_EL1 */
> 68void hisi_read_scl_and_ccl_id(u32 *scl_id, u32 *ccl_id)
> 69{
> 70u64 mpidr;
> 71
>   > 72mpidr = read_cpuid_mpidr();
>   > 73if (mpidr & MPIDR_MT_BITMASK) {
> 74if (scl_id)
>   > 75*scl_id = MPIDR_AFFINITY_LEVEL(mpidr, 
> 3);
> 76if (ccl_id)
> 77*ccl_id = MPIDR_AFFINITY_LEVEL(mpidr, 
> 2);
> 78} else {
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 
> 
> 
> ___
> linuxarm mailing list
> linux...@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
> 

linux-next: build warning after merge of the libata tree

[Stephen Rothwell]

Hi Tejun,

After merging the libata tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/ata/libata-scsi.c: In function 'ata_scsi_var_len_cdb_xlat':
drivers/ata/libata-scsi.c:4194:1: warning: label 'unspprt_sa' defined but not 
used [-Wunused-label]
 unspprt_sa:
 ^

Introduced by commit

  b1ffbf854e08 ("libata: Support for an ATA PASS-THROUGH(32) command.")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the libata tree

[Stephen Rothwell]

Hi Tejun,

After merging the libata tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/ata/libata-scsi.c: In function 'ata_scsi_var_len_cdb_xlat':
drivers/ata/libata-scsi.c:4194:1: warning: label 'unspprt_sa' defined but not 
used [-Wunused-label]
 unspprt_sa:
 ^

Introduced by commit

  b1ffbf854e08 ("libata: Support for an ATA PASS-THROUGH(32) command.")

-- 
Cheers,
Stephen Rothwell

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

[James Morris]

On Tue, 27 Jun 2017, Kees Cook wrote:

> On Mon, Jun 26, 2017 at 8:33 PM, James Morris  wrote:
> > On Mon, 26 Jun 2017, Kees Cook wrote:
> >
> >> >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using 
> >> >> labels")
> >> >> Signed-off-by: Stephen Rothwell 
> >> > Acked-by: John Johansen 
> >>
> >> Hi James,
> >>
> >> Just a ping; this needs to get into -next to avoid build errors.
> >
> > Surely Linus will resolve this when he pulls the trees in?
> 
> It's not a merge glitch, it's a refactoring glitch. John's commit in
> security-next ("apparmor: move path_link mediation to using labels")
> undid an earlier commit 8486adf0d755 ("apparmor: use designated
> initializers") from v4.11. This patch is needed for security-next.
> 

Thanks.

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris

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

[James Morris]

On Tue, 27 Jun 2017, Kees Cook wrote:

> On Mon, Jun 26, 2017 at 8:33 PM, James Morris  wrote:
> > On Mon, 26 Jun 2017, Kees Cook wrote:
> >
> >> >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using 
> >> >> labels")
> >> >> Signed-off-by: Stephen Rothwell 
> >> > Acked-by: John Johansen 
> >>
> >> Hi James,
> >>
> >> Just a ping; this needs to get into -next to avoid build errors.
> >
> > Surely Linus will resolve this when he pulls the trees in?
> 
> It's not a merge glitch, it's a refactoring glitch. John's commit in
> security-next ("apparmor: move path_link mediation to using labels")
> undid an earlier commit 8486adf0d755 ("apparmor: use designated
> initializers") from v4.11. This patch is needed for security-next.
> 

Thanks.

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris

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

[Stephen Rothwell]

Hi all,

On Wed, 28 Jun 2017 15:40:59 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the target-updates tree got a conflict in:
> 
>   drivers/scsi/qla2xxx/qla_target.c
> 
> between commits:
> 
>   f775bd14e44d ("scsi: qla2xxx: Convert 32-bit LUN usage to 64-bit")
>   82de802ad46e ("scsi: qla2xxx: Preparation for Target MQ.")
> 
> from the scsi tree and commit:
> 
>   6b26726af699 ("qla2xxx: Convert QLA_TGT_ABTS to 
> TARGET_SCF_LOOKUP_LUN_FROM_TAG")
> 
> from the target-updates tree.
> 
> I fixed it up (I think - see below) and can carry the fix as

OK, that was no right :-(

I have added the following fix patch as well (I suggest someone provide me with 
the correct fixup for tomorrow, please).

From: Stephen Rothwell 
Date: Wed, 28 Jun 2017 15:44:27 +1000
Subject: [PATCH] qla2xxx: fix up for bad merge fix

Signed-off-by: Stephen Rothwell 
---
 drivers/scsi/qla2xxx/qla_target.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index 9a054439560d..42a3f5be818c 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1875,7 +1875,6 @@ static int __qlt_24xx_handle_abts(struct scsi_qla_host 
*vha,
 {
struct qla_hw_data *ha = vha->hw;
struct qla_tgt_mgmt_cmd *mcmd;
-   struct qla_tgt_cmd *cmd;
int rc;
 
if (abort_cmd_for_tag(vha, abts->exchange_addr_to_abort)) {
@@ -1898,14 +1897,13 @@ static int __qlt_24xx_handle_abts(struct scsi_qla_host 
*vha,
}
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 = 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,
+   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,
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

On Wed, 28 Jun 2017 15:40:59 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the target-updates tree got a conflict in:
> 
>   drivers/scsi/qla2xxx/qla_target.c
> 
> between commits:
> 
>   f775bd14e44d ("scsi: qla2xxx: Convert 32-bit LUN usage to 64-bit")
>   82de802ad46e ("scsi: qla2xxx: Preparation for Target MQ.")
> 
> from the scsi tree and commit:
> 
>   6b26726af699 ("qla2xxx: Convert QLA_TGT_ABTS to 
> TARGET_SCF_LOOKUP_LUN_FROM_TAG")
> 
> from the target-updates tree.
> 
> I fixed it up (I think - see below) and can carry the fix as

OK, that was no right :-(

I have added the following fix patch as well (I suggest someone provide me with 
the correct fixup for tomorrow, please).

From: Stephen Rothwell 
Date: Wed, 28 Jun 2017 15:44:27 +1000
Subject: [PATCH] qla2xxx: fix up for bad merge fix

Signed-off-by: Stephen Rothwell 
---
 drivers/scsi/qla2xxx/qla_target.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index 9a054439560d..42a3f5be818c 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1875,7 +1875,6 @@ static int __qlt_24xx_handle_abts(struct scsi_qla_host 
*vha,
 {
struct qla_hw_data *ha = vha->hw;
struct qla_tgt_mgmt_cmd *mcmd;
-   struct qla_tgt_cmd *cmd;
int rc;
 
if (abort_cmd_for_tag(vha, abts->exchange_addr_to_abort)) {
@@ -1898,14 +1897,13 @@ static int __qlt_24xx_handle_abts(struct scsi_qla_host 
*vha,
}
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 = 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,
+   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,
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

[PATCH v2] drm: tilcdc: tilcdc_tfp410: make of_device_ids const.

[Arvind Yadav]

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

File size before:
   textdata bss dec hex filename
   1496 592   02088 828 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o

File size after constify:
   textdata bss dec hex filename
   1880 176   02056 808 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o

Signed-off-by: Arvind Yadav 
---
Changes in v1:
  Subject was not correct.

 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index aabfad8..236ca1e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -290,8 +290,6 @@ static int tfp410_modeset_init(struct tilcdc_module *mod, 
struct drm_device *dev
  * Device:
  */
 
-static struct of_device_id tfp410_of_match[];
-
 static int tfp410_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
@@ -376,7 +374,7 @@ static int tfp410_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id tfp410_of_match[] = {
+static const struct of_device_id tfp410_of_match[] = {
{ .compatible = "ti,tilcdc,tfp410", },
{ },
 };
-- 
1.9.1

[PATCH v2] drm: tilcdc: tilcdc_tfp410: make of_device_ids const.

[Arvind Yadav]

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

File size before:
   textdata bss dec hex filename
   1496 592   02088 828 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o

File size after constify:
   textdata bss dec hex filename
   1880 176   02056 808 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o

Signed-off-by: Arvind Yadav 
---
Changes in v1:
  Subject was not correct.

 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index aabfad8..236ca1e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -290,8 +290,6 @@ static int tfp410_modeset_init(struct tilcdc_module *mod, 
struct drm_device *dev
  * Device:
  */
 
-static struct of_device_id tfp410_of_match[];
-
 static int tfp410_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
@@ -376,7 +374,7 @@ static int tfp410_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id tfp410_of_match[] = {
+static const struct of_device_id tfp410_of_match[] = {
{ .compatible = "ti,tilcdc,tfp410", },
{ },
 };
-- 
1.9.1

Re: [PATCH 0/3] Enable namespaced file capabilities

[Serge E. Hallyn]

On Fri, Jun 23, 2017 at 10:01:46AM +0300, Amir Goldstein wrote:
> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>  wrote:
> > This series of patches primary goal is to enable file capabilities
> > in user namespaces without affecting the file capabilities that are
> > effective on the host. This is to prevent that any unprivileged user
> > on the host maps his own uid to root in a private namespace, writes
> > the xattr, and executes the file with privilege on the host.
> >
> > We achieve this goal by writing extended attributes with a different
> > name when a user namespace is used. If for example the root user
> > in a user namespace writes the security.capability xattr, the name
> > of the xattr that is actually written is encoded as
> > security.capability@uid=1000 for root mapped to uid 1000 on the host.
> > When listing the xattrs on the host, the existing security.capability
> > as well as the security.capability@uid=1000 will be shown. Inside the
> > namespace only 'security.capability', with the value of
> > security.capability@uid=1000, is visible.
> >
> 
> Am I the only one who thinks that suffix is perhaps not the best grammar
> to use for this namespace?
> xattrs are clearly namespaced by prefix, so it seems right to me to keep
> it that way - define a new special xattr namespace "ns" and only if that
> prefix exists, the @uid suffix will be parsed.
> This could be either  ns.security.capability@uid=1000 or
> ns@uid=1000.security.capability. The latter seems more correct to me,
> because then we will be able to namespace any xattr without having to
> protect from "unprivileged xattr injection", i.e.:
> setfattr -n "user.whatever.foo@uid=0"
> 
> Amir.

Hi Amir,

I was liking the prefix at first, but I'm actually not sure it's worth
it.  THe main advantage would be so that checking for namespace or other
tags could be done always at the same offset simplifying the parser.
But since we will want to only handle namespacing for some tags, and
potentially differently for each task, it won't actually be simpler, I
don't think.

On the other hand we do want to make sure that the syntax we use is
generally usable, so I think simply specifying that >1 tags can each
be separate by '@' should suffice.  So for now we'd only have

security.capability@uid=10

soon we'd hopefully have

security.ima@uid=10

and eventually trusted.blarb@foo=bar

-serge

Re: [PATCH 0/3] Enable namespaced file capabilities

[Serge E. Hallyn]

On Fri, Jun 23, 2017 at 10:01:46AM +0300, Amir Goldstein wrote:
> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>  wrote:
> > This series of patches primary goal is to enable file capabilities
> > in user namespaces without affecting the file capabilities that are
> > effective on the host. This is to prevent that any unprivileged user
> > on the host maps his own uid to root in a private namespace, writes
> > the xattr, and executes the file with privilege on the host.
> >
> > We achieve this goal by writing extended attributes with a different
> > name when a user namespace is used. If for example the root user
> > in a user namespace writes the security.capability xattr, the name
> > of the xattr that is actually written is encoded as
> > security.capability@uid=1000 for root mapped to uid 1000 on the host.
> > When listing the xattrs on the host, the existing security.capability
> > as well as the security.capability@uid=1000 will be shown. Inside the
> > namespace only 'security.capability', with the value of
> > security.capability@uid=1000, is visible.
> >
> 
> Am I the only one who thinks that suffix is perhaps not the best grammar
> to use for this namespace?
> xattrs are clearly namespaced by prefix, so it seems right to me to keep
> it that way - define a new special xattr namespace "ns" and only if that
> prefix exists, the @uid suffix will be parsed.
> This could be either  ns.security.capability@uid=1000 or
> ns@uid=1000.security.capability. The latter seems more correct to me,
> because then we will be able to namespace any xattr without having to
> protect from "unprivileged xattr injection", i.e.:
> setfattr -n "user.whatever.foo@uid=0"
> 
> Amir.

Hi Amir,

I was liking the prefix at first, but I'm actually not sure it's worth
it.  THe main advantage would be so that checking for namespace or other
tags could be done always at the same offset simplifying the parser.
But since we will want to only handle namespacing for some tags, and
potentially differently for each task, it won't actually be simpler, I
don't think.

On the other hand we do want to make sure that the syntax we use is
generally usable, so I think simply specifying that >1 tags can each
be separate by '@' should suffice.  So for now we'd only have

security.capability@uid=10

soon we'd hopefully have

security.ima@uid=10

and eventually trusted.blarb@foo=bar

-serge

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 commits:

  f775bd14e44d ("scsi: qla2xxx: Convert 32-bit LUN usage to 64-bit")
  82de802ad46e ("scsi: qla2xxx: Preparation for Target MQ.")

from the scsi tree and commit:

  6b26726af699 ("qla2xxx: Convert QLA_TGT_ABTS to 
TARGET_SCF_LOOKUP_LUN_FROM_TAG")

from the target-updates 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 drivers/scsi/qla2xxx/qla_target.c
index 2a0173e5d10e,401e245477d4..
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@@ -1874,36 -1847,13 +1874,15 @@@ 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,

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 commits:

  f775bd14e44d ("scsi: qla2xxx: Convert 32-bit LUN usage to 64-bit")
  82de802ad46e ("scsi: qla2xxx: Preparation for Target MQ.")

from the scsi tree and commit:

  6b26726af699 ("qla2xxx: Convert QLA_TGT_ABTS to 
TARGET_SCF_LOOKUP_LUN_FROM_TAG")

from the target-updates 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 drivers/scsi/qla2xxx/qla_target.c
index 2a0173e5d10e,401e245477d4..
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@@ -1874,36 -1847,13 +1874,15 @@@ 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,

[PATCH v2] drm: tilcdc: tilcdc_panel: make of_device_ids const.

[Arvind Yadav]

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

File size before:
   textdata bss dec hex filename
   1531 592   02123 84b drivers/gpu/drm/tilcdc/tilcdc_panel.o

File size after constify:
   textdata bss dec hex filename
   1915 176   02091 82b drivers/gpu/drm/tilcdc/tilcdc_panel.o

Signed-off-by: Arvind Yadav 
---
Changes in v1:
  Subject was not correct.

 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 28c3e2f..2abe7c4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -419,7 +419,7 @@ static int panel_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id panel_of_match[] = {
+static const struct of_device_id panel_of_match[] = {
{ .compatible = "ti,tilcdc,panel", },
{ },
 };
-- 
1.9.1

[PATCH v2] drm: tilcdc: tilcdc_panel: make of_device_ids const.

[Arvind Yadav]

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

File size before:
   textdata bss dec hex filename
   1531 592   02123 84b drivers/gpu/drm/tilcdc/tilcdc_panel.o

File size after constify:
   textdata bss dec hex filename
   1915 176   02091 82b drivers/gpu/drm/tilcdc/tilcdc_panel.o

Signed-off-by: Arvind Yadav 
---
Changes in v1:
  Subject was not correct.

 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 28c3e2f..2abe7c4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -419,7 +419,7 @@ static int panel_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id panel_of_match[] = {
+static const struct of_device_id panel_of_match[] = {
{ .compatible = "ti,tilcdc,panel", },
{ },
 };
-- 
1.9.1

Re: [PATCH BUGFIX V2] block, bfq: update wr_busy_queues if needed on a queue split

[Paolo Valente]

> Il giorno 27 giu 2017, alle ore 20:29, Jens Axboe  ha 
> scritto:
> 
> On 06/27/2017 12:27 PM, Paolo Valente wrote:
>> 
>>> Il giorno 27 giu 2017, alle ore 16:41, Jens Axboe  ha 
>>> scritto:
>>> 
>>> On 06/27/2017 12:09 AM, Paolo Valente wrote:
 
> Il giorno 19 giu 2017, alle ore 13:43, Paolo Valente 
>  ha scritto:
> 
> This commit fixes a bug triggered by a non-trivial sequence of
> events. These events are briefly described in the next two
> paragraphs. The impatiens, or those who are familiar with queue
> merging and splitting, can jump directly to the last paragraph.
> 
> On each I/O-request arrival for a shared bfq_queue, i.e., for a
> bfq_queue that is the result of the merge of two or more bfq_queues,
> BFQ checks whether the shared bfq_queue has become seeky (i.e., if too
> many random I/O requests have arrived for the bfq_queue; if the device
> is non rotational, then random requests must be also small for the
> bfq_queue to be tagged as seeky). If the shared bfq_queue is actually
> detected as seeky, then a split occurs: the bfq I/O context of the
> process that has issued the request is redirected from the shared
> bfq_queue to a new non-shared bfq_queue. As a degenerate case, if the
> shared bfq_queue actually happens to be shared only by one process
> (because of previous splits), then no new bfq_queue is created: the
> state of the shared bfq_queue is just changed from shared to non
> shared.
> 
> Regardless of whether a brand new non-shared bfq_queue is created, or
> the pre-existing shared bfq_queue is just turned into a non-shared
> bfq_queue, several parameters of the non-shared bfq_queue are set
> (restored) to the original values they had when the bfq_queue
> associated with the bfq I/O context of the process (that has just
> issued an I/O request) was merged with the shared bfq_queue. One of
> these parameters is the weight-raising state.
> 
> If, on the split of a shared bfq_queue,
> 1) a pre-existing shared bfq_queue is turned into a non-shared
> bfq_queue;
> 2) the previously shared bfq_queue happens to be busy;
> 3) the weight-raising state of the previously shared bfq_queue happens
> to change;
> the number of weight-raised busy queues changes. The field
> wr_busy_queues must then be updated accordingly, but such an update
> was missing. This commit adds the missing update.
> 
 
 Hi Jens,
 any idea of the possible fate of this fix?
>>> 
>>> I sort of missed this one. It looks trivial enough for 4.12, or we
>>> can defer until 4.13. What do you think?
>>> 
>> 
>> It should actually be something trivial, and hopefully correct,
>> because a further throughput improvement (for BFQ), which depends on
>> this fix, is now working properly, and we didn't see any regression so
>> far.  In addition, since this improvement is virtually ready for
>> submission, further steps may be probably easier if this fix gets in
>> sooner (whatever the luck of the improvement will be).
> 
> OK, let's queue it up for 4.13 then.
> 

My arguments was in favor of 4.12 actually.  Maybe you did mean 4.12
here?

Thanks,
Paolo

> -- 
> Jens Axboe

Re: [PATCH BUGFIX V2] block, bfq: update wr_busy_queues if needed on a queue split

[Paolo Valente]

> Il giorno 27 giu 2017, alle ore 20:29, Jens Axboe  ha 
> scritto:
> 
> On 06/27/2017 12:27 PM, Paolo Valente wrote:
>> 
>>> Il giorno 27 giu 2017, alle ore 16:41, Jens Axboe  ha 
>>> scritto:
>>> 
>>> On 06/27/2017 12:09 AM, Paolo Valente wrote:
 
> Il giorno 19 giu 2017, alle ore 13:43, Paolo Valente 
>  ha scritto:
> 
> This commit fixes a bug triggered by a non-trivial sequence of
> events. These events are briefly described in the next two
> paragraphs. The impatiens, or those who are familiar with queue
> merging and splitting, can jump directly to the last paragraph.
> 
> On each I/O-request arrival for a shared bfq_queue, i.e., for a
> bfq_queue that is the result of the merge of two or more bfq_queues,
> BFQ checks whether the shared bfq_queue has become seeky (i.e., if too
> many random I/O requests have arrived for the bfq_queue; if the device
> is non rotational, then random requests must be also small for the
> bfq_queue to be tagged as seeky). If the shared bfq_queue is actually
> detected as seeky, then a split occurs: the bfq I/O context of the
> process that has issued the request is redirected from the shared
> bfq_queue to a new non-shared bfq_queue. As a degenerate case, if the
> shared bfq_queue actually happens to be shared only by one process
> (because of previous splits), then no new bfq_queue is created: the
> state of the shared bfq_queue is just changed from shared to non
> shared.
> 
> Regardless of whether a brand new non-shared bfq_queue is created, or
> the pre-existing shared bfq_queue is just turned into a non-shared
> bfq_queue, several parameters of the non-shared bfq_queue are set
> (restored) to the original values they had when the bfq_queue
> associated with the bfq I/O context of the process (that has just
> issued an I/O request) was merged with the shared bfq_queue. One of
> these parameters is the weight-raising state.
> 
> If, on the split of a shared bfq_queue,
> 1) a pre-existing shared bfq_queue is turned into a non-shared
> bfq_queue;
> 2) the previously shared bfq_queue happens to be busy;
> 3) the weight-raising state of the previously shared bfq_queue happens
> to change;
> the number of weight-raised busy queues changes. The field
> wr_busy_queues must then be updated accordingly, but such an update
> was missing. This commit adds the missing update.
> 
 
 Hi Jens,
 any idea of the possible fate of this fix?
>>> 
>>> I sort of missed this one. It looks trivial enough for 4.12, or we
>>> can defer until 4.13. What do you think?
>>> 
>> 
>> It should actually be something trivial, and hopefully correct,
>> because a further throughput improvement (for BFQ), which depends on
>> this fix, is now working properly, and we didn't see any regression so
>> far.  In addition, since this improvement is virtually ready for
>> submission, further steps may be probably easier if this fix gets in
>> sooner (whatever the luck of the improvement will be).
> 
> OK, let's queue it up for 4.13 then.
> 

My arguments was in favor of 4.12 actually.  Maybe you did mean 4.12
here?

Thanks,
Paolo

> -- 
> Jens Axboe

Re: [PATCH v3 1/2] spi: rockchip: Set GPIO_SS flag to enable Slave Select with GPIO CS

[Doug Anderson]

Hi,

On Tue, Jun 27, 2017 at 9:38 PM, Jeffy Chen  wrote:
> The rockchip spi still requires slave selection when using GPIO CS.
>
> Signed-off-by: Jeffy Chen 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/spi-rockchip.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
> index bab9b13..52ea160 100644
> --- a/drivers/spi/spi-rockchip.c
> +++ b/drivers/spi/spi-rockchip.c
> @@ -749,6 +749,7 @@ static int rockchip_spi_probe(struct platform_device 
> *pdev)
> master->transfer_one = rockchip_spi_transfer_one;
> master->max_transfer_size = rockchip_spi_max_transfer_size;
> master->handle_err = rockchip_spi_handle_err;
> +   master->flags = SPI_MASTER_GPIO_SS;
>
> rs->dma_tx.ch = dma_request_chan(rs->dev, "tx");
> if (IS_ERR(rs->dma_tx.ch)) {

Reviewed-by: Douglas Anderson 

Re: [PATCH v3 1/2] spi: rockchip: Set GPIO_SS flag to enable Slave Select with GPIO CS

[Doug Anderson]

Hi,

On Tue, Jun 27, 2017 at 9:38 PM, Jeffy Chen  wrote:
> The rockchip spi still requires slave selection when using GPIO CS.
>
> Signed-off-by: Jeffy Chen 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/spi-rockchip.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
> index bab9b13..52ea160 100644
> --- a/drivers/spi/spi-rockchip.c
> +++ b/drivers/spi/spi-rockchip.c
> @@ -749,6 +749,7 @@ static int rockchip_spi_probe(struct platform_device 
> *pdev)
> master->transfer_one = rockchip_spi_transfer_one;
> master->max_transfer_size = rockchip_spi_max_transfer_size;
> master->handle_err = rockchip_spi_handle_err;
> +   master->flags = SPI_MASTER_GPIO_SS;
>
> rs->dma_tx.ch = dma_request_chan(rs->dev, "tx");
> if (IS_ERR(rs->dma_tx.ch)) {

Reviewed-by: Douglas Anderson 

Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region

[Jin, Yao]

Hi Kyle,

I understand your requirement. Sorry I don't know the detail of rr 
debugger, but I guess if it just uses counter overflow to deliver a 
signal, could it set the counter without "exclude_kernel"?


Another consideration is, I'm not sure if the kernel can accurately 
realize that if the interrupt is to trigger sampling or just deliver a 
signal. Userspace may know that but kernel may not.


Anyway let's listen to more comments from community.

Thanks

Jin Yao


On 6/28/2017 12:51 PM, Kyle Huey wrote:

On Tue, Jun 27, 2017 at 7:09 PM, Jin, Yao  wrote:

Hi,

In theory, the PMI interrupts in skid region should be dropped, right?

No, why would they be dropped?

My understanding of the situation is as follows:

There is some time, call it t_0, where the hardware counter overflows.
The PMU triggers an interrupt, but this is not instantaneous.  Call
the time when the interrupt is actually delivered t_1.  Then t_1 - t_0
is the "skid".

Note that if the counter is `exclude_kernel`, then at t_0 the CPU
*must* be running a userspace program.  But by t_1, the CPU may be
doing something else.  Your patch changed things so that if at t_1 the
CPU is in the kernel, then the interrupt is discarded.  But rr has
programmed the counter to deliver a signal on overflow (via F_SETSIG
on the fd returned by perf_event_open).  This change results in the
signal never being delivered, because the interrupt was ignored.
(More accurately, the signal is delivered the *next* time the counter
overflows, which is far past where we wanted to inject our
asynchronous event into our tracee.

It seems to me that it might be reasonable to ignore the interrupt if
the purpose of the interrupt is to trigger sampling of the CPUs
register state.  But if the interrupt will trigger some other
operation, such as a signal on an fd, then there's no reason to drop
it.


For a userspace debugger, is it the only choice that relies on the *skid*
PMI interrupt?

I don't understand this question, but hopefully the above clarified things.

- Kyle


Thanks
Jin Yao


On 6/28/2017 9:01 AM, Kyle Huey wrote:

Sent again with LKML CCd, sorry for the noise.

- Kyle

On Tue, Jun 27, 2017 at 5:38 PM, Kyle Huey  wrote:

cc1582c231ea introduced a regression in v4.12.0-rc5, and appears to be
a candidate for backporting to stable branches.

rr, a userspace record and replay debugger[0], uses the PMU interrupt
to stop a program during replay to inject asynchronous events such as
signals.  We are counting retired conditional branches in userspace
only.  This changeset causes the kernel to drop interrupts on the
floor if, during the PMU interrupt's "skid" region, the CPU enters
kernel mode for whatever reason.  When replaying traces of complex
programs such as Firefox, we intermittently fail to deliver
asynchronous events on time, leading the replay to diverge from the
recorded state.

It seems like this change should, at a bare minimum, be limited to
counters that actually perform sampling of register state when the
interrupt fires.  In our case, with the retired conditional branches
counter restricted to counting userspace events only, it makes no
difference that the PMU interrupt happened to be delivered in the
kernel.

As this makes rr unusable on complex applications and cannot be
efficiently worked around, we would appreciate this being addressed
before 4.12 is finalized, and the regression not being introduced to
stable branches.

Thanks,

- Kyle

[0] http://rr-project.org/

Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region

[Jin, Yao]

Hi Kyle,

I understand your requirement. Sorry I don't know the detail of rr 
debugger, but I guess if it just uses counter overflow to deliver a 
signal, could it set the counter without "exclude_kernel"?


Another consideration is, I'm not sure if the kernel can accurately 
realize that if the interrupt is to trigger sampling or just deliver a 
signal. Userspace may know that but kernel may not.


Anyway let's listen to more comments from community.

Thanks

Jin Yao


On 6/28/2017 12:51 PM, Kyle Huey wrote:

On Tue, Jun 27, 2017 at 7:09 PM, Jin, Yao  wrote:

Hi,

In theory, the PMI interrupts in skid region should be dropped, right?

No, why would they be dropped?

My understanding of the situation is as follows:

There is some time, call it t_0, where the hardware counter overflows.
The PMU triggers an interrupt, but this is not instantaneous.  Call
the time when the interrupt is actually delivered t_1.  Then t_1 - t_0
is the "skid".

Note that if the counter is `exclude_kernel`, then at t_0 the CPU
*must* be running a userspace program.  But by t_1, the CPU may be
doing something else.  Your patch changed things so that if at t_1 the
CPU is in the kernel, then the interrupt is discarded.  But rr has
programmed the counter to deliver a signal on overflow (via F_SETSIG
on the fd returned by perf_event_open).  This change results in the
signal never being delivered, because the interrupt was ignored.
(More accurately, the signal is delivered the *next* time the counter
overflows, which is far past where we wanted to inject our
asynchronous event into our tracee.

It seems to me that it might be reasonable to ignore the interrupt if
the purpose of the interrupt is to trigger sampling of the CPUs
register state.  But if the interrupt will trigger some other
operation, such as a signal on an fd, then there's no reason to drop
it.


For a userspace debugger, is it the only choice that relies on the *skid*
PMI interrupt?

I don't understand this question, but hopefully the above clarified things.

- Kyle


Thanks
Jin Yao


On 6/28/2017 9:01 AM, Kyle Huey wrote:

Sent again with LKML CCd, sorry for the noise.

- Kyle

On Tue, Jun 27, 2017 at 5:38 PM, Kyle Huey  wrote:

cc1582c231ea introduced a regression in v4.12.0-rc5, and appears to be
a candidate for backporting to stable branches.

rr, a userspace record and replay debugger[0], uses the PMU interrupt
to stop a program during replay to inject asynchronous events such as
signals.  We are counting retired conditional branches in userspace
only.  This changeset causes the kernel to drop interrupts on the
floor if, during the PMU interrupt's "skid" region, the CPU enters
kernel mode for whatever reason.  When replaying traces of complex
programs such as Firefox, we intermittently fail to deliver
asynchronous events on time, leading the replay to diverge from the
recorded state.

It seems like this change should, at a bare minimum, be limited to
counters that actually perform sampling of register state when the
interrupt fires.  In our case, with the retired conditional branches
counter restricted to counting userspace events only, it makes no
difference that the PMU interrupt happened to be delivered in the
kernel.

As this makes rr unusable on complex applications and cannot be
efficiently worked around, we would appreciate this being addressed
before 4.12 is finalized, and the regression not being introduced to
stable branches.

Thanks,

- Kyle

[0] http://rr-project.org/

Re: [kernel-sched-cputime] question about probable bug in cputime_adjust()

[Frans Klaver]

On Wed, Jun 28, 2017 at 1:03 AM, Gustavo A. R. Silva
 wrote:
>
> Hello everybody,
>
> While looking into Coverity ID 1371643 I ran into the following piece of
> code at kernel/sched/cputime.c:568:
>
> 568/*
> 569 * Adjust tick based cputime random precision against scheduler runtime
> 570 * accounting.
> 571 *
> 572 * Tick based cputime accounting depend on random scheduling timeslices
> of a
> 573 * task to be interrupted or not by the timer.  Depending on these
> 574 * circumstances, the number of these interrupts may be over or
> 575 * under-optimistic, matching the real user and system cputime with a
> variable
> 576 * precision.
> 577 *
> 578 * Fix this by scaling these tick based values against the total runtime
> 579 * accounted by the CFS scheduler.
> 580 *
> 581 * This code provides the following guarantees:
> 582 *
> 583 *   stime + utime == rtime
> 584 *   stime_i+1 >= stime_i, utime_i+1 >= utime_i
> 585 *
> 586 * Assuming that rtime_i+1 >= rtime_i.
> 587 */
> 588static void cputime_adjust(struct task_cputime *curr,
> 589   struct prev_cputime *prev,
> 590   u64 *ut, u64 *st)
> 591{
> 592u64 rtime, stime, utime;
> 593unsigned long flags;
> 594
> 595/* Serialize concurrent callers such that we can honour our
> guarantees */
> 596raw_spin_lock_irqsave(>lock, flags);
> 597rtime = curr->sum_exec_runtime;
> 598
> 599/*
> 600 * This is possible under two circumstances:
> 601 *  - rtime isn't monotonic after all (a bug);
> 602 *  - we got reordered by the lock.
> 603 *
> 604 * In both cases this acts as a filter such that the rest of the
> code
> 605 * can assume it is monotonic regardless of anything else.
> 606 */
> 607if (prev->stime + prev->utime >= rtime)
> 608goto out;
> 609
> 610stime = curr->stime;
> 611utime = curr->utime;
> 612
> 613/*
> 614 * If either stime or both stime and utime are 0, assume all
> runtime is
> 615 * userspace. Once a task gets some ticks, the monotonicy code at
> 616 * 'update' will ensure things converge to the observed ratio.
> 617 */
> 618if (stime == 0) {
> 619utime = rtime;
> 620goto update;
> 621}
> 622
> 623if (utime == 0) {
> 624stime = rtime;
> 625goto update;
> 626}
> 627
> 628stime = scale_stime(stime, rtime, stime + utime);
> 629
> 630update:
> 631/*
> 632 * Make sure stime doesn't go backwards; this preserves
> monotonicity
> 633 * for utime because rtime is monotonic.
> 634 *
> 635 *  utime_i+1 = rtime_i+1 - stime_i
> 636 *= rtime_i+1 - (rtime_i - utime_i)
> 637 *= (rtime_i+1 - rtime_i) + utime_i
> 638 *>= utime_i
> 639 */
> 640if (stime < prev->stime)
> 641stime = prev->stime;
> 642utime = rtime - stime;
> 643
> 644/*
> 645 * Make sure utime doesn't go backwards; this still preserves
> 646 * monotonicity for stime, analogous argument to above.
> 647 */
> 648if (utime < prev->utime) {
> 649utime = prev->utime;
> 650stime = rtime - utime;
> 651}
> 652
> 653prev->stime = stime;
> 654prev->utime = utime;
> 655out:
> 656*ut = prev->utime;
> 657*st = prev->stime;
> 658raw_spin_unlock_irqrestore(>lock, flags);
> 659}
>
>
> The issue here is that the value assigned to variable utime at line 619 is
> overwritten at line 642, which would make such variable assignment useless.

It isn't completely useless, since utime is used in line 628 to calculate stime.


> But I'm suspicious that such assignment is actually correct and that line
> 642 should be included into the IF block at line 640. Something similar to
> the following patch:
>
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -637,9 +637,10 @@ static void cputime_adjust(struct task_cputime *curr,
>  *= (rtime_i+1 - rtime_i) + utime_i
>  *>= utime_i
>  */
> -   if (stime < prev->stime)
> +   if (stime < prev->stime) {
> stime = prev->stime;
> -   utime = rtime - stime;
> +   utime = rtime - stime;
> +   }
>
>
> If you confirm this, I will send a patch in a full and proper form.
>
> I'd really appreciate your comments.

If you do that, how would you meet the guarantee made in line 583?

Frans

Re: [kernel-sched-cputime] question about probable bug in cputime_adjust()

[Frans Klaver]

On Wed, Jun 28, 2017 at 1:03 AM, Gustavo A. R. Silva
 wrote:
>
> Hello everybody,
>
> While looking into Coverity ID 1371643 I ran into the following piece of
> code at kernel/sched/cputime.c:568:
>
> 568/*
> 569 * Adjust tick based cputime random precision against scheduler runtime
> 570 * accounting.
> 571 *
> 572 * Tick based cputime accounting depend on random scheduling timeslices
> of a
> 573 * task to be interrupted or not by the timer.  Depending on these
> 574 * circumstances, the number of these interrupts may be over or
> 575 * under-optimistic, matching the real user and system cputime with a
> variable
> 576 * precision.
> 577 *
> 578 * Fix this by scaling these tick based values against the total runtime
> 579 * accounted by the CFS scheduler.
> 580 *
> 581 * This code provides the following guarantees:
> 582 *
> 583 *   stime + utime == rtime
> 584 *   stime_i+1 >= stime_i, utime_i+1 >= utime_i
> 585 *
> 586 * Assuming that rtime_i+1 >= rtime_i.
> 587 */
> 588static void cputime_adjust(struct task_cputime *curr,
> 589   struct prev_cputime *prev,
> 590   u64 *ut, u64 *st)
> 591{
> 592u64 rtime, stime, utime;
> 593unsigned long flags;
> 594
> 595/* Serialize concurrent callers such that we can honour our
> guarantees */
> 596raw_spin_lock_irqsave(>lock, flags);
> 597rtime = curr->sum_exec_runtime;
> 598
> 599/*
> 600 * This is possible under two circumstances:
> 601 *  - rtime isn't monotonic after all (a bug);
> 602 *  - we got reordered by the lock.
> 603 *
> 604 * In both cases this acts as a filter such that the rest of the
> code
> 605 * can assume it is monotonic regardless of anything else.
> 606 */
> 607if (prev->stime + prev->utime >= rtime)
> 608goto out;
> 609
> 610stime = curr->stime;
> 611utime = curr->utime;
> 612
> 613/*
> 614 * If either stime or both stime and utime are 0, assume all
> runtime is
> 615 * userspace. Once a task gets some ticks, the monotonicy code at
> 616 * 'update' will ensure things converge to the observed ratio.
> 617 */
> 618if (stime == 0) {
> 619utime = rtime;
> 620goto update;
> 621}
> 622
> 623if (utime == 0) {
> 624stime = rtime;
> 625goto update;
> 626}
> 627
> 628stime = scale_stime(stime, rtime, stime + utime);
> 629
> 630update:
> 631/*
> 632 * Make sure stime doesn't go backwards; this preserves
> monotonicity
> 633 * for utime because rtime is monotonic.
> 634 *
> 635 *  utime_i+1 = rtime_i+1 - stime_i
> 636 *= rtime_i+1 - (rtime_i - utime_i)
> 637 *= (rtime_i+1 - rtime_i) + utime_i
> 638 *>= utime_i
> 639 */
> 640if (stime < prev->stime)
> 641stime = prev->stime;
> 642utime = rtime - stime;
> 643
> 644/*
> 645 * Make sure utime doesn't go backwards; this still preserves
> 646 * monotonicity for stime, analogous argument to above.
> 647 */
> 648if (utime < prev->utime) {
> 649utime = prev->utime;
> 650stime = rtime - utime;
> 651}
> 652
> 653prev->stime = stime;
> 654prev->utime = utime;
> 655out:
> 656*ut = prev->utime;
> 657*st = prev->stime;
> 658raw_spin_unlock_irqrestore(>lock, flags);
> 659}
>
>
> The issue here is that the value assigned to variable utime at line 619 is
> overwritten at line 642, which would make such variable assignment useless.

It isn't completely useless, since utime is used in line 628 to calculate stime.


> But I'm suspicious that such assignment is actually correct and that line
> 642 should be included into the IF block at line 640. Something similar to
> the following patch:
>
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -637,9 +637,10 @@ static void cputime_adjust(struct task_cputime *curr,
>  *= (rtime_i+1 - rtime_i) + utime_i
>  *>= utime_i
>  */
> -   if (stime < prev->stime)
> +   if (stime < prev->stime) {
> stime = prev->stime;
> -   utime = rtime - stime;
> +   utime = rtime - stime;
> +   }
>
>
> If you confirm this, I will send a patch in a full and proper form.
>
> I'd really appreciate your comments.

If you do that, how would you meet the guarantee made in line 583?

Frans

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

[Daniel Vetter]

On Tue, Jun 27, 2017 at 10:51 PM, Jeff Kirsher
 wrote:
> This was submitted and accepted into David Miller's net-next tree.  I can
> see if Dave can pull it into his net tree.  DOes stable need to pick this
> up as well?

Nah if it landed somewhere at least I'm happy, we can carry the fixup
for a while longer locally.

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

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

[Daniel Vetter]

On Tue, Jun 27, 2017 at 10:51 PM, Jeff Kirsher
 wrote:
> This was submitted and accepted into David Miller's net-next tree.  I can
> see if Dave can pull it into his net tree.  DOes stable need to pick this
> up as well?

Nah if it landed somewhere at least I'm happy, we can carry the fixup
for a while longer locally.

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

Re: [PATCH v3 2/2] spi: rockchip: Disable Runtime PM when chip select is asserted

[Doug Anderson]

Jeffy,

On Tue, Jun 27, 2017 at 9:38 PM, Jeffy Chen  wrote:
> The rockchip spi would stop driving pins when runtime suspended, which
> might break slave's xfer(for example cros_ec).
>
> Since we have pullups on those pins, we only need to care about this
> when the CS asserted.
>
> So let's keep the spi alive when chip select is asserted.
>
> Also use pm_runtime_put instead of pm_runtime_put_sync.
>
> Suggested-by: Doug Anderson 
> Signed-off-by: Jeffy Chen 
>
> ---
>
> Changes in v3:
> Store cs states in struct rockchip_spi, and use it to detect cs state
> instead of hw register.
>
> Changes in v2:
> Improve commit message and comments and coding style.
>
>  drivers/spi/spi-rockchip.c | 51 
> +++---
>  1 file changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
> index 52ea160..0b4a52b 100644
> --- a/drivers/spi/spi-rockchip.c
> +++ b/drivers/spi/spi-rockchip.c
> @@ -25,6 +25,11 @@
>
>  #define DRIVER_NAME "rockchip-spi"
>
> +#define ROCKCHIP_SPI_CLR_BITS(reg, bits) \
> +   writel_relaxed(readl_relaxed(reg) & ~(bits), reg)
> +#define ROCKCHIP_SPI_SET_BITS(reg, bits) \
> +   writel_relaxed(readl_relaxed(reg) | (bits), reg)
> +
>  /* SPI register offsets */
>  #define ROCKCHIP_SPI_CTRLR00x
>  #define ROCKCHIP_SPI_CTRLR10x0004
> @@ -149,6 +154,8 @@
>   */
>  #define ROCKCHIP_SPI_MAX_TRANLEN   0x
>
> +#define ROCKCHIP_SPI_MAX_CS_NUM2
> +
>  enum rockchip_ssi_type {
> SSI_MOTO_SPI = 0,
> SSI_TI_SSP,
> @@ -193,6 +200,8 @@ struct rockchip_spi {
> /* protect state */
> spinlock_t lock;
>
> +   bool cs_asserted[ROCKCHIP_SPI_MAX_CS_NUM];
> +
> u32 use_dma;
> struct sg_table tx_sg;
> struct sg_table rx_sg;
> @@ -264,37 +273,29 @@ static inline u32 rx_max(struct rockchip_spi *rs)
>
>  static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
>  {
> -   u32 ser;
> struct spi_master *master = spi->master;
> struct rockchip_spi *rs = spi_master_get_devdata(master);
> +   bool cs_asserted = !enable;
>
> -   pm_runtime_get_sync(rs->dev);
> +   /* Return immediately for no-op */
> +   if (cs_asserted == rs->cs_asserted[spi->chip_select])
> +   return;
>
> -   ser = readl_relaxed(rs->regs + ROCKCHIP_SPI_SER) & SER_MASK;
> +   if (cs_asserted) {
> +   /* Keep things powered as long as CS is asserted */
> +   pm_runtime_get_sync(rs->dev);
>
> -   /*
> -* drivers/spi/spi.c:
> -* static void spi_set_cs(struct spi_device *spi, bool enable)
> -* {
> -*  if (spi->mode & SPI_CS_HIGH)
> -*  enable = !enable;
> -*
> -*  if (spi->cs_gpio >= 0)
> -*  gpio_set_value(spi->cs_gpio, !enable);
> -*  else if (spi->master->set_cs)
> -*  spi->master->set_cs(spi, !enable);
> -* }
> -*
> -* Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
> -*/
> -   if (!enable)
> -   ser |= 1 << spi->chip_select;
> -   else
> -   ser &= ~(1 << spi->chip_select);
> +   ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER,
> + BIT(spi->chip_select));
> +   } else {
> +   ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER,
> + BIT(spi->chip_select));
>
> -   writel_relaxed(ser, rs->regs + ROCKCHIP_SPI_SER);
> +   /* Drop reference from when we first asserted CS */
> +   pm_runtime_put(rs->dev);
> +   }
>
> -   pm_runtime_put_sync(rs->dev);
> +   rs->cs_asserted[spi->chip_select] = cs_asserted;

Looks great!

>  }
>
>  static int rockchip_spi_prepare_message(struct spi_master *master,
> @@ -739,7 +740,7 @@ static int rockchip_spi_probe(struct platform_device 
> *pdev)
> master->auto_runtime_pm = true;
> master->bus_num = pdev->id;
> master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP;
> -   master->num_chipselect = 2;
> +   master->num_chipselect = ROCKCHIP_SPI_MAX_CS_NUM;

Reviewed-by: Douglas Anderson 

Re: [PATCH v3 2/2] spi: rockchip: Disable Runtime PM when chip select is asserted

[Doug Anderson]

Jeffy,

On Tue, Jun 27, 2017 at 9:38 PM, Jeffy Chen  wrote:
> The rockchip spi would stop driving pins when runtime suspended, which
> might break slave's xfer(for example cros_ec).
>
> Since we have pullups on those pins, we only need to care about this
> when the CS asserted.
>
> So let's keep the spi alive when chip select is asserted.
>
> Also use pm_runtime_put instead of pm_runtime_put_sync.
>
> Suggested-by: Doug Anderson 
> Signed-off-by: Jeffy Chen 
>
> ---
>
> Changes in v3:
> Store cs states in struct rockchip_spi, and use it to detect cs state
> instead of hw register.
>
> Changes in v2:
> Improve commit message and comments and coding style.
>
>  drivers/spi/spi-rockchip.c | 51 
> +++---
>  1 file changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
> index 52ea160..0b4a52b 100644
> --- a/drivers/spi/spi-rockchip.c
> +++ b/drivers/spi/spi-rockchip.c
> @@ -25,6 +25,11 @@
>
>  #define DRIVER_NAME "rockchip-spi"
>
> +#define ROCKCHIP_SPI_CLR_BITS(reg, bits) \
> +   writel_relaxed(readl_relaxed(reg) & ~(bits), reg)
> +#define ROCKCHIP_SPI_SET_BITS(reg, bits) \
> +   writel_relaxed(readl_relaxed(reg) | (bits), reg)
> +
>  /* SPI register offsets */
>  #define ROCKCHIP_SPI_CTRLR00x
>  #define ROCKCHIP_SPI_CTRLR10x0004
> @@ -149,6 +154,8 @@
>   */
>  #define ROCKCHIP_SPI_MAX_TRANLEN   0x
>
> +#define ROCKCHIP_SPI_MAX_CS_NUM2
> +
>  enum rockchip_ssi_type {
> SSI_MOTO_SPI = 0,
> SSI_TI_SSP,
> @@ -193,6 +200,8 @@ struct rockchip_spi {
> /* protect state */
> spinlock_t lock;
>
> +   bool cs_asserted[ROCKCHIP_SPI_MAX_CS_NUM];
> +
> u32 use_dma;
> struct sg_table tx_sg;
> struct sg_table rx_sg;
> @@ -264,37 +273,29 @@ static inline u32 rx_max(struct rockchip_spi *rs)
>
>  static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
>  {
> -   u32 ser;
> struct spi_master *master = spi->master;
> struct rockchip_spi *rs = spi_master_get_devdata(master);
> +   bool cs_asserted = !enable;
>
> -   pm_runtime_get_sync(rs->dev);
> +   /* Return immediately for no-op */
> +   if (cs_asserted == rs->cs_asserted[spi->chip_select])
> +   return;
>
> -   ser = readl_relaxed(rs->regs + ROCKCHIP_SPI_SER) & SER_MASK;
> +   if (cs_asserted) {
> +   /* Keep things powered as long as CS is asserted */
> +   pm_runtime_get_sync(rs->dev);
>
> -   /*
> -* drivers/spi/spi.c:
> -* static void spi_set_cs(struct spi_device *spi, bool enable)
> -* {
> -*  if (spi->mode & SPI_CS_HIGH)
> -*  enable = !enable;
> -*
> -*  if (spi->cs_gpio >= 0)
> -*  gpio_set_value(spi->cs_gpio, !enable);
> -*  else if (spi->master->set_cs)
> -*  spi->master->set_cs(spi, !enable);
> -* }
> -*
> -* Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
> -*/
> -   if (!enable)
> -   ser |= 1 << spi->chip_select;
> -   else
> -   ser &= ~(1 << spi->chip_select);
> +   ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER,
> + BIT(spi->chip_select));
> +   } else {
> +   ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER,
> + BIT(spi->chip_select));
>
> -   writel_relaxed(ser, rs->regs + ROCKCHIP_SPI_SER);
> +   /* Drop reference from when we first asserted CS */
> +   pm_runtime_put(rs->dev);
> +   }
>
> -   pm_runtime_put_sync(rs->dev);
> +   rs->cs_asserted[spi->chip_select] = cs_asserted;

Looks great!

>  }
>
>  static int rockchip_spi_prepare_message(struct spi_master *master,
> @@ -739,7 +740,7 @@ static int rockchip_spi_probe(struct platform_device 
> *pdev)
> master->auto_runtime_pm = true;
> master->bus_num = pdev->id;
> master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP;
> -   master->num_chipselect = 2;
> +   master->num_chipselect = ROCKCHIP_SPI_MAX_CS_NUM;

Reviewed-by: Douglas Anderson 

Re: [PATCH] lib/zstd: use div_u64() to let it build on 32-bit

[Nick Terrell]

> Please don't top post.

Sorry about that.

> Which function needs 1KB of stack space? That's quite a lot.

FSE_buildCTable_wksp(), FSE_compress_wksp(), and HUF_readDTableX4()
required over 1 KB of stack space.

> I can see in [1] that there are some on-stack buffers replaced by
> pointers to the workspace. That's good, but I would like to know if
> there's any hidden gem that grags the precious stack space.

I've been hunting down functions that use up the most stack trace and
replacing buffers with pointers to the workspace. I compiled the code
with -Wframe-larger-than=512 and reduced the stack usage of all offending
functions. In the next version of the patch, no function uses more than
400 B of stack space. We'll be porting the changes back upstream as well.

> Hm, I'd suggest to create a version optimized for kernel, eg. expecting
> that 4+ GB buffer will never be used and you can use the most fittin in
> type. This should affect only the function signatures, not the
> algorithm implementation, so porting future zstd changes should be
> straightforward.

If the functions were exposed, then I would agree 100%. However, since
these are internal functions, and the rest of zstd uses size_t to represent
buffer sizes, I think it would be awkward to change just FSE/HUF functions.
I also prefer size_t because it is friendlier to the optimizer, especially
the loop optimizer, since the compiler doesn't have to worry about unsigned
overflow.

On a related note, zstd performs automatic optimizations to improve
compression speed and reduce memory usage when given small sources, which
is the common case in the kernel.

Re: [PATCH] lib/zstd: use div_u64() to let it build on 32-bit

[Nick Terrell]

> Please don't top post.

Sorry about that.

> Which function needs 1KB of stack space? That's quite a lot.

FSE_buildCTable_wksp(), FSE_compress_wksp(), and HUF_readDTableX4()
required over 1 KB of stack space.

> I can see in [1] that there are some on-stack buffers replaced by
> pointers to the workspace. That's good, but I would like to know if
> there's any hidden gem that grags the precious stack space.

I've been hunting down functions that use up the most stack trace and
replacing buffers with pointers to the workspace. I compiled the code
with -Wframe-larger-than=512 and reduced the stack usage of all offending
functions. In the next version of the patch, no function uses more than
400 B of stack space. We'll be porting the changes back upstream as well.

> Hm, I'd suggest to create a version optimized for kernel, eg. expecting
> that 4+ GB buffer will never be used and you can use the most fittin in
> type. This should affect only the function signatures, not the
> algorithm implementation, so porting future zstd changes should be
> straightforward.

If the functions were exposed, then I would agree 100%. However, since
these are internal functions, and the rest of zstd uses size_t to represent
buffer sizes, I think it would be awkward to change just FSE/HUF functions.
I also prefer size_t because it is friendlier to the optimizer, especially
the loop optimizer, since the compiler doesn't have to worry about unsigned
overflow.

On a related note, zstd performs automatic optimizations to improve
compression speed and reduce memory usage when given small sources, which
is the common case in the kernel.

Re: [PATCH 2/3] usb: phy: Add USB charger support

[Baolin Wang]

Hi,

On 28 June 2017 at 10:44, kbuild test robot <l...@intel.com> wrote:
> Hi Baolin,
>
> [auto build test ERROR on balbi-usb/next]
> [also build test ERROR on next-20170627]
> [cannot apply to v4.12-rc7]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Baolin-Wang/include-uapi-usb-Introduce-USB-charger-type-and-state-definition/20170628-093530
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> config: i386-randconfig-x076-06262345 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_set_charger_current':
>>> rt9455_charger.c:(.text+0x1660): multiple definition of 
>>> `usb_phy_set_charger_current'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xad0): first defined 
> here
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_get_charger_current':
>>> rt9455_charger.c:(.text+0x1670): multiple definition of 
>>> `usb_phy_get_charger_current'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xae0): first defined 
> here
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_set_charger_state':
>>> rt9455_charger.c:(.text+0x1680): multiple definition of 
>>> `usb_phy_set_charger_state'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xaf0): first defined 
> here

Sorry for missing "static inline" for these exported functions, will
fix in next version.

-- 
Baolin.wang
Best Regards

Re: [PATCH 2/3] usb: phy: Add USB charger support

[Baolin Wang]

Hi,

On 28 June 2017 at 10:44, kbuild test robot  wrote:
> Hi Baolin,
>
> [auto build test ERROR on balbi-usb/next]
> [also build test ERROR on next-20170627]
> [cannot apply to v4.12-rc7]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Baolin-Wang/include-uapi-usb-Introduce-USB-charger-type-and-state-definition/20170628-093530
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> config: i386-randconfig-x076-06262345 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_set_charger_current':
>>> rt9455_charger.c:(.text+0x1660): multiple definition of 
>>> `usb_phy_set_charger_current'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xad0): first defined 
> here
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_get_charger_current':
>>> rt9455_charger.c:(.text+0x1670): multiple definition of 
>>> `usb_phy_get_charger_current'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xae0): first defined 
> here
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_set_charger_state':
>>> rt9455_charger.c:(.text+0x1680): multiple definition of 
>>> `usb_phy_set_charger_state'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xaf0): first defined 
> here

Sorry for missing "static inline" for these exported functions, will
fix in next version.

-- 
Baolin.wang
Best Regards

Re: [PATCH v4 5/5] g_NCR5380: Re-work PDMA loops

[Finn Thain]

I'm afraid I accidentally introduced a regression into v4 of this patch.
Ondrej, please test the patch below instead. Sorry for the inconvenience.

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index b1e0a08e49c1..98d5360b0c78 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -482,6 +482,30 @@ static void generic_NCR5380_release_resources(struct 
Scsi_Host *instance)
release_mem_region(base, region_size);
 }
 
+/* wait_for_53c80_access - wait for 53C80 registers to become accessible
+ * @hostdata: scsi host private data
+ *
+ * The registers within the 53C80 logic block are inaccessible until
+ * bit 7 in the 53C400 control status register gets asserted.
+ */
+
+static void wait_for_53c80_access(struct NCR5380_hostdata *hostdata)
+{
+   int count = 1;
+
+   do {
+   if (hostdata->board == BOARD_DTC3181E)
+   udelay(4); /* DTC436 chip hangs without this */
+   if (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)
+   return;
+   } while (--count > 0);
+
+   scmd_printk(KERN_ERR, hostdata->connected,
+   "53c80 registers not accessible, device will be reset\n");
+   NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
+   NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
+}
+
 /**
  * generic_NCR5380_pread - pseudo DMA receive
  * @hostdata: scsi host private data
@@ -494,18 +518,22 @@ static void generic_NCR5380_release_resources(struct 
Scsi_Host *instance)
 static inline int generic_NCR5380_pread(struct NCR5380_hostdata *hostdata,
 unsigned char *dst, int len)
 {
-   int blocks = len / 128;
int start = 0;
 
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE | CSR_TRANS_DIR);
-   NCR5380_write(hostdata->c400_blk_cnt, blocks);
-   while (1) {
-   if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
+   NCR5380_write(hostdata->c400_blk_cnt, len / 128);
+
+   while (start < len) {
+   if (NCR5380_poll_politely2(hostdata, hostdata->c400_ctl_status,
+  CSR_HOST_BUF_NOT_RDY, 0,
+  hostdata->c400_ctl_status,
+  CSR_GATED_53C80_IRQ,
+  CSR_GATED_53C80_IRQ, HZ / 64) < 0)
+   break;
+
+   if (NCR5380_read(hostdata->c400_ctl_status) &
+   CSR_GATED_53C80_IRQ)
break;
-   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ)
-   goto out_wait;
-   while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
-   ; /* FIXME - no timeout */
 
if (hostdata->io_port && hostdata->io_width == 2)
insw(hostdata->io_port + hostdata->c400_host_buf,
@@ -518,38 +546,19 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
hostdata->io + NCR53C400_host_buffer, 128);
 
start += 128;
-   blocks--;
-   }
-
-   if (blocks) {
-   while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
-   ; /* FIXME - no timeout */
-
-   if (hostdata->io_port && hostdata->io_width == 2)
-   insw(hostdata->io_port + hostdata->c400_host_buf,
-   dst + start, 64);
-   else if (hostdata->io_port)
-   insb(hostdata->io_port + hostdata->c400_host_buf,
-   dst + start, 128);
-   else
-   memcpy_fromio(dst + start,
-   hostdata->io + NCR53C400_host_buffer, 128);
-
-   start += 128;
-   blocks--;
}
 
-   if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
-   printk("53C400r: no 53C80 gated irq after transfer");
+   hostdata->pdma_residual = NCR5380_read(hostdata->c400_blk_cnt) * 128;
 
-out_wait:
-   hostdata->pdma_residual = len - start;
-
-   /* wait for 53C80 registers to be available */
-   while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
-   ;
+   if (start < len) {
+   /* Detected a 53c80 interrupt (or worse). Reset 53c400 logic. */
+   NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
+   NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
+   } else
+   wait_for_53c80_access(hostdata);
 
-   if (NCR5380_poll_politely(hostdata, BUS_AND_STATUS_REG,
+   if (hostdata->pdma_residual == 0 &&
+   NCR5380_poll_politely(hostdata, BUS_AND_STATUS_REG,
  

Re: [PATCH v4 5/5] g_NCR5380: Re-work PDMA loops

[Finn Thain]

I'm afraid I accidentally introduced a regression into v4 of this patch.
Ondrej, please test the patch below instead. Sorry for the inconvenience.

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index b1e0a08e49c1..98d5360b0c78 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -482,6 +482,30 @@ static void generic_NCR5380_release_resources(struct 
Scsi_Host *instance)
release_mem_region(base, region_size);
 }
 
+/* wait_for_53c80_access - wait for 53C80 registers to become accessible
+ * @hostdata: scsi host private data
+ *
+ * The registers within the 53C80 logic block are inaccessible until
+ * bit 7 in the 53C400 control status register gets asserted.
+ */
+
+static void wait_for_53c80_access(struct NCR5380_hostdata *hostdata)
+{
+   int count = 1;
+
+   do {
+   if (hostdata->board == BOARD_DTC3181E)
+   udelay(4); /* DTC436 chip hangs without this */
+   if (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)
+   return;
+   } while (--count > 0);
+
+   scmd_printk(KERN_ERR, hostdata->connected,
+   "53c80 registers not accessible, device will be reset\n");
+   NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
+   NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
+}
+
 /**
  * generic_NCR5380_pread - pseudo DMA receive
  * @hostdata: scsi host private data
@@ -494,18 +518,22 @@ static void generic_NCR5380_release_resources(struct 
Scsi_Host *instance)
 static inline int generic_NCR5380_pread(struct NCR5380_hostdata *hostdata,
 unsigned char *dst, int len)
 {
-   int blocks = len / 128;
int start = 0;
 
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE | CSR_TRANS_DIR);
-   NCR5380_write(hostdata->c400_blk_cnt, blocks);
-   while (1) {
-   if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
+   NCR5380_write(hostdata->c400_blk_cnt, len / 128);
+
+   while (start < len) {
+   if (NCR5380_poll_politely2(hostdata, hostdata->c400_ctl_status,
+  CSR_HOST_BUF_NOT_RDY, 0,
+  hostdata->c400_ctl_status,
+  CSR_GATED_53C80_IRQ,
+  CSR_GATED_53C80_IRQ, HZ / 64) < 0)
+   break;
+
+   if (NCR5380_read(hostdata->c400_ctl_status) &
+   CSR_GATED_53C80_IRQ)
break;
-   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ)
-   goto out_wait;
-   while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
-   ; /* FIXME - no timeout */
 
if (hostdata->io_port && hostdata->io_width == 2)
insw(hostdata->io_port + hostdata->c400_host_buf,
@@ -518,38 +546,19 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
hostdata->io + NCR53C400_host_buffer, 128);
 
start += 128;
-   blocks--;
-   }
-
-   if (blocks) {
-   while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
-   ; /* FIXME - no timeout */
-
-   if (hostdata->io_port && hostdata->io_width == 2)
-   insw(hostdata->io_port + hostdata->c400_host_buf,
-   dst + start, 64);
-   else if (hostdata->io_port)
-   insb(hostdata->io_port + hostdata->c400_host_buf,
-   dst + start, 128);
-   else
-   memcpy_fromio(dst + start,
-   hostdata->io + NCR53C400_host_buffer, 128);
-
-   start += 128;
-   blocks--;
}
 
-   if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
-   printk("53C400r: no 53C80 gated irq after transfer");
+   hostdata->pdma_residual = NCR5380_read(hostdata->c400_blk_cnt) * 128;
 
-out_wait:
-   hostdata->pdma_residual = len - start;
-
-   /* wait for 53C80 registers to be available */
-   while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
-   ;
+   if (start < len) {
+   /* Detected a 53c80 interrupt (or worse). Reset 53c400 logic. */
+   NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
+   NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
+   } else
+   wait_for_53c80_access(hostdata);
 
-   if (NCR5380_poll_politely(hostdata, BUS_AND_STATUS_REG,
+   if (hostdata->pdma_residual == 0 &&
+   NCR5380_poll_politely(hostdata, BUS_AND_STATUS_REG,
  

Re: [Patch v5 04/12] [media] s5p-mfc: Support MFCv10.10 buffer requirements

[Smitha T Murthy]

On Tue, 2017-06-27 at 22:30 +0200, Kamil Debski wrote:
> Hi,
> 
> Please find my comments inline.
> 
> On 19 June 2017 at 07:10, Smitha T Murthy  wrote:
> > Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> > for MFCv10.10.
> >
> > Signed-off-by: Smitha T Murthy 
> > Reviewed-by: Andrzej Hajda 
> > ---
> >  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   | 19 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 95 
> > +++--
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |  2 +
> >  3 files changed, 95 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> > b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > index 1ca09d6..3f0dab3 100644
> > --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > @@ -32,5 +32,24 @@
> >  #define MFC_VERSION_V100xA0
> >  #define MFC_NUM_PORTS_V10  1
> >
> > +/* MFCv10 codec defines*/
> > +#define S5P_FIMV_CODEC_HEVC_ENC 26
> > +
> > +/* Encoder buffer size for MFC v10.0 */
> > +#define ENC_V100_BASE_SIZE(x, y) \
> > +   (((x + 3) * (y + 3) * 8) \
> > +   +  ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))
> > +
> > +#define ENC_V100_H264_ME_SIZE(x, y) \
> > +   (ENC_V100_BASE_SIZE(x, y) \
> > +   + (DIV_ROUND_UP(x * y, 64) * 32))
> > +
> > +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> > +   (ENC_V100_BASE_SIZE(x, y) \
> > +   + (DIV_ROUND_UP(x * y, 128) * 16))
> > +
> > +#define ENC_V100_VP8_ME_SIZE(x, y) \
> > +   ENC_V100_BASE_SIZE(x, y)
> > +
> >  #endif /*_REGS_MFC_V10_H*/
> >
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > index f1a8c53..83ea733 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > @@ -64,6 +64,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> >  {
> > struct s5p_mfc_dev *dev = ctx->dev;
> > unsigned int mb_width, mb_height;
> > +   unsigned int lcu_width = 0, lcu_height = 0;
> > int ret;
> >
> > mb_width = MB_WIDTH(ctx->img_width);
> > @@ -74,7 +75,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> >   ctx->luma_size, ctx->chroma_size, ctx->mv_size);
> > mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
> > } else if (ctx->type == MFCINST_ENCODER) {
> > -   if (IS_MFCV8_PLUS(dev))
> > +   if (IS_MFCV10(dev)) {IZE_V10  (15 * SZ_1K)
> > +   ctx->tmv_buffer_size = 0;
> 
> It would look much better to surround the above with braces, even
> though it's only a single line.
> 
I will add the braces in the next version.

> > +   } else if (IS_MFCV8_PLUS(dev))
> > ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> > ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, 
> > mb_height),
> > S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> > @@ -82,13 +85,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> > ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> > ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, 
> > mb_height),
> > S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> > -
> > -   ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> > -   S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> > -   S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> > -   ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> > -   S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> > -   S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> > +   if (IS_MFCV10(dev)) {
> > +   lcu_width = enc_lcu_width(ctx->img_width);
> > +   lcu_height = enc_lcu_height(ctx->img_height);
> > +   if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> > +   ctx->luma_dpb_size =
> > +   ALIGN((mb_width * 16), 64)
> > +   * ALIGN((mb_height * 16), 32)
> > +   + 64;
> > +   ctx->chroma_dpb_size =
> > +   ALIGN((mb_width * 16), 64)
> > +   * (mb_height * 8)
> > +   + 64;
> > +   } else {
> > +   ctx->luma_dpb_size =
> > +   ALIGN((lcu_width * 32), 64)
> > +   * ALIGN((lcu_height * 32), 32)
> > 

Re: [Patch v5 04/12] [media] s5p-mfc: Support MFCv10.10 buffer requirements

[Smitha T Murthy]

On Tue, 2017-06-27 at 22:30 +0200, Kamil Debski wrote:
> Hi,
> 
> Please find my comments inline.
> 
> On 19 June 2017 at 07:10, Smitha T Murthy  wrote:
> > Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> > for MFCv10.10.
> >
> > Signed-off-by: Smitha T Murthy 
> > Reviewed-by: Andrzej Hajda 
> > ---
> >  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   | 19 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 95 
> > +++--
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |  2 +
> >  3 files changed, 95 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> > b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > index 1ca09d6..3f0dab3 100644
> > --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > @@ -32,5 +32,24 @@
> >  #define MFC_VERSION_V100xA0
> >  #define MFC_NUM_PORTS_V10  1
> >
> > +/* MFCv10 codec defines*/
> > +#define S5P_FIMV_CODEC_HEVC_ENC 26
> > +
> > +/* Encoder buffer size for MFC v10.0 */
> > +#define ENC_V100_BASE_SIZE(x, y) \
> > +   (((x + 3) * (y + 3) * 8) \
> > +   +  ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))
> > +
> > +#define ENC_V100_H264_ME_SIZE(x, y) \
> > +   (ENC_V100_BASE_SIZE(x, y) \
> > +   + (DIV_ROUND_UP(x * y, 64) * 32))
> > +
> > +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> > +   (ENC_V100_BASE_SIZE(x, y) \
> > +   + (DIV_ROUND_UP(x * y, 128) * 16))
> > +
> > +#define ENC_V100_VP8_ME_SIZE(x, y) \
> > +   ENC_V100_BASE_SIZE(x, y)
> > +
> >  #endif /*_REGS_MFC_V10_H*/
> >
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > index f1a8c53..83ea733 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > @@ -64,6 +64,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> >  {
> > struct s5p_mfc_dev *dev = ctx->dev;
> > unsigned int mb_width, mb_height;
> > +   unsigned int lcu_width = 0, lcu_height = 0;
> > int ret;
> >
> > mb_width = MB_WIDTH(ctx->img_width);
> > @@ -74,7 +75,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> >   ctx->luma_size, ctx->chroma_size, ctx->mv_size);
> > mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
> > } else if (ctx->type == MFCINST_ENCODER) {
> > -   if (IS_MFCV8_PLUS(dev))
> > +   if (IS_MFCV10(dev)) {IZE_V10  (15 * SZ_1K)
> > +   ctx->tmv_buffer_size = 0;
> 
> It would look much better to surround the above with braces, even
> though it's only a single line.
> 
I will add the braces in the next version.

> > +   } else if (IS_MFCV8_PLUS(dev))
> > ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> > ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, 
> > mb_height),
> > S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> > @@ -82,13 +85,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> > ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> > ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, 
> > mb_height),
> > S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> > -
> > -   ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> > -   S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> > -   S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> > -   ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> > -   S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> > -   S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> > +   if (IS_MFCV10(dev)) {
> > +   lcu_width = enc_lcu_width(ctx->img_width);
> > +   lcu_height = enc_lcu_height(ctx->img_height);
> > +   if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> > +   ctx->luma_dpb_size =
> > +   ALIGN((mb_width * 16), 64)
> > +   * ALIGN((mb_height * 16), 32)
> > +   + 64;
> > +   ctx->chroma_dpb_size =
> > +   ALIGN((mb_width * 16), 64)
> > +   * (mb_height * 8)
> > +   + 64;
> > +   } else {
> > +   ctx->luma_dpb_size =
> > +   ALIGN((lcu_width * 32), 64)
> > +   * ALIGN((lcu_height * 32), 32)
> > +   + 64;
> > +  

[PATCH] IB/hns: Fix a potential use after free in 'hns_roce_v1_destroy_qp_work_fn()'

[Christophe JAILLET]

The last 'dev_dbg' call uses 'hr_qp->qpn'. However, 'hr_qp' may have been
freed a few lines above.

In order to fix it, take the value of 'hr_qp->qpn' earlier in the function
and use it instead.

Fixes: d838c481e025 ("IB/hns: Fix the bug when destroy qp")
Signed-off-by: Christophe JAILLET 
---
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c 
b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index 37d5d29597a4..825a0fc2 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -3641,6 +3641,7 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
struct hns_roce_dev *hr_dev;
struct hns_roce_qp *hr_qp;
struct device *dev;
+   unsigned long qpn;
int ret;
 
qp_work_entry = container_of(work, struct hns_roce_qp_work, work);
@@ -3648,8 +3649,9 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
dev = _dev->pdev->dev;
priv = (struct hns_roce_v1_priv *)hr_dev->hw->priv;
hr_qp = qp_work_entry->qp;
+   qpn = hr_qp->qpn;
 
-   dev_dbg(dev, "Schedule destroy QP(0x%lx) work.\n", hr_qp->qpn);
+   dev_dbg(dev, "Schedule destroy QP(0x%lx) work.\n", qpn);
 
qp_work_entry->sche_cnt++;
 
@@ -3660,7 +3662,7 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
 _work_entry->db_wait_stage);
if (ret) {
dev_err(dev, "Check QP(0x%lx) db process status failed!\n",
-   hr_qp->qpn);
+   qpn);
return;
}
 
@@ -3674,7 +3676,7 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
ret = hns_roce_v1_modify_qp(_qp->ibqp, NULL, 0, hr_qp->state,
IB_QPS_RESET);
if (ret) {
-   dev_err(dev, "Modify QP(0x%lx) to RST failed!\n", hr_qp->qpn);
+   dev_err(dev, "Modify QP(0x%lx) to RST failed!\n", qpn);
return;
}
 
@@ -3683,14 +3685,14 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
 
if (hr_qp->ibqp.qp_type == IB_QPT_RC) {
/* RC QP, release QPN */
-   hns_roce_release_range_qp(hr_dev, hr_qp->qpn, 1);
+   hns_roce_release_range_qp(hr_dev, qpn, 1);
kfree(hr_qp);
} else
kfree(hr_to_hr_sqp(hr_qp));
 
kfree(qp_work_entry);
 
-   dev_dbg(dev, "Accomplished destroy QP(0x%lx) work.\n", hr_qp->qpn);
+   dev_dbg(dev, "Accomplished destroy QP(0x%lx) work.\n", qpn);
 }
 
 int hns_roce_v1_destroy_qp(struct ib_qp *ibqp)
-- 
2.11.0

[PATCH] IB/hns: Fix a potential use after free in 'hns_roce_v1_destroy_qp_work_fn()'

[Christophe JAILLET]

The last 'dev_dbg' call uses 'hr_qp->qpn'. However, 'hr_qp' may have been
freed a few lines above.

In order to fix it, take the value of 'hr_qp->qpn' earlier in the function
and use it instead.

Fixes: d838c481e025 ("IB/hns: Fix the bug when destroy qp")
Signed-off-by: Christophe JAILLET 
---
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c 
b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index 37d5d29597a4..825a0fc2 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -3641,6 +3641,7 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
struct hns_roce_dev *hr_dev;
struct hns_roce_qp *hr_qp;
struct device *dev;
+   unsigned long qpn;
int ret;
 
qp_work_entry = container_of(work, struct hns_roce_qp_work, work);
@@ -3648,8 +3649,9 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
dev = _dev->pdev->dev;
priv = (struct hns_roce_v1_priv *)hr_dev->hw->priv;
hr_qp = qp_work_entry->qp;
+   qpn = hr_qp->qpn;
 
-   dev_dbg(dev, "Schedule destroy QP(0x%lx) work.\n", hr_qp->qpn);
+   dev_dbg(dev, "Schedule destroy QP(0x%lx) work.\n", qpn);
 
qp_work_entry->sche_cnt++;
 
@@ -3660,7 +3662,7 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
 _work_entry->db_wait_stage);
if (ret) {
dev_err(dev, "Check QP(0x%lx) db process status failed!\n",
-   hr_qp->qpn);
+   qpn);
return;
}
 
@@ -3674,7 +3676,7 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
ret = hns_roce_v1_modify_qp(_qp->ibqp, NULL, 0, hr_qp->state,
IB_QPS_RESET);
if (ret) {
-   dev_err(dev, "Modify QP(0x%lx) to RST failed!\n", hr_qp->qpn);
+   dev_err(dev, "Modify QP(0x%lx) to RST failed!\n", qpn);
return;
}
 
@@ -3683,14 +3685,14 @@ static void hns_roce_v1_destroy_qp_work_fn(struct 
work_struct *work)
 
if (hr_qp->ibqp.qp_type == IB_QPT_RC) {
/* RC QP, release QPN */
-   hns_roce_release_range_qp(hr_dev, hr_qp->qpn, 1);
+   hns_roce_release_range_qp(hr_dev, qpn, 1);
kfree(hr_qp);
} else
kfree(hr_to_hr_sqp(hr_qp));
 
kfree(qp_work_entry);
 
-   dev_dbg(dev, "Accomplished destroy QP(0x%lx) work.\n", hr_qp->qpn);
+   dev_dbg(dev, "Accomplished destroy QP(0x%lx) work.\n", qpn);
 }
 
 int hns_roce_v1_destroy_qp(struct ib_qp *ibqp)
-- 
2.11.0

[PATCH] drm: tilcdc: tilcdc_panel: fsl_raid: make of_device_ids const.

[Arvind Yadav]

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

File size before:
   textdata bss dec hex filename
   1531 592   02123 84b drivers/gpu/drm/tilcdc/tilcdc_panel.o

File size after constify:
   textdata bss dec hex filename
   1915 176   02091 82b drivers/gpu/drm/tilcdc/tilcdc_panel.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 28c3e2f..2abe7c4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -419,7 +419,7 @@ static int panel_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id panel_of_match[] = {
+static const struct of_device_id panel_of_match[] = {
{ .compatible = "ti,tilcdc,panel", },
{ },
 };
-- 
1.9.1

[PATCH] drm: tilcdc: tilcdc_panel: fsl_raid: make of_device_ids const.

[Arvind Yadav]

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

File size before:
   textdata bss dec hex filename
   1531 592   02123 84b drivers/gpu/drm/tilcdc/tilcdc_panel.o

File size after constify:
   textdata bss dec hex filename
   1915 176   02091 82b drivers/gpu/drm/tilcdc/tilcdc_panel.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 28c3e2f..2abe7c4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -419,7 +419,7 @@ static int panel_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id panel_of_match[] = {
+static const struct of_device_id panel_of_match[] = {
{ .compatible = "ti,tilcdc,panel", },
{ },
 };
-- 
1.9.1

Re: [RFC PATCH] char: misc: Init misc->list in a safe way

[Greg Kroah-Hartman]

On Wed, Jun 28, 2017 at 09:54:32AM +0800, Orson Zhai wrote:
> We found the device is "fm". We highly suspect that fm driver call
> misc_register twice and reinitialize list to make ->pre & ->next
> pointing to himself.
> 
> Meanwhile, we checked fm driver and found nothing obviously wrong in the code.

Do you have a pointer to this driver?  Is it in the kernel tree?

> Consider that this is a crash after 46 hours continuous power-on/off,
> it maybe caused by some special cases we are hard to know for now.

What would cause this driver to want to register/unregister itself?  Is
it "recycling" the misc structure, or creating it new each time?

And what kernel version are you testing here?

> We think it might make some sence to add protection code into
> misc_register() at first.

To protect from "foolish" callers?  Usually we fix the calling code to
not do foolish things. :)

thanks,

greg k-h

Re: [RFC PATCH] char: misc: Init misc->list in a safe way

[Greg Kroah-Hartman]

On Wed, Jun 28, 2017 at 09:54:32AM +0800, Orson Zhai wrote:
> We found the device is "fm". We highly suspect that fm driver call
> misc_register twice and reinitialize list to make ->pre & ->next
> pointing to himself.
> 
> Meanwhile, we checked fm driver and found nothing obviously wrong in the code.

Do you have a pointer to this driver?  Is it in the kernel tree?

> Consider that this is a crash after 46 hours continuous power-on/off,
> it maybe caused by some special cases we are hard to know for now.

What would cause this driver to want to register/unregister itself?  Is
it "recycling" the misc structure, or creating it new each time?

And what kernel version are you testing here?

> We think it might make some sence to add protection code into
> misc_register() at first.

To protect from "foolish" callers?  Usually we fix the calling code to
not do foolish things. :)

thanks,

greg k-h

[PATCH] drm: tilcdc: tilcdc_tfp410: fsl_raid: make of_device_ids const.

[Arvind Yadav]

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

File size before:
   textdata bss dec hex filename
   1496 592   02088 828 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o

File size after constify:
   textdata bss dec hex filename
   1880 176   02056 808 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index aabfad8..236ca1e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -290,8 +290,6 @@ static int tfp410_modeset_init(struct tilcdc_module *mod, 
struct drm_device *dev
  * Device:
  */
 
-static struct of_device_id tfp410_of_match[];
-
 static int tfp410_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
@@ -376,7 +374,7 @@ static int tfp410_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id tfp410_of_match[] = {
+static const struct of_device_id tfp410_of_match[] = {
{ .compatible = "ti,tilcdc,tfp410", },
{ },
 };
-- 
1.9.1

[PATCH] drm: tilcdc: tilcdc_tfp410: fsl_raid: make of_device_ids const.

[Arvind Yadav]

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

File size before:
   textdata bss dec hex filename
   1496 592   02088 828 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o

File size after constify:
   textdata bss dec hex filename
   1880 176   02056 808 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index aabfad8..236ca1e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -290,8 +290,6 @@ static int tfp410_modeset_init(struct tilcdc_module *mod, 
struct drm_device *dev
  * Device:
  */
 
-static struct of_device_id tfp410_of_match[];
-
 static int tfp410_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
@@ -376,7 +374,7 @@ static int tfp410_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id tfp410_of_match[] = {
+static const struct of_device_id tfp410_of_match[] = {
{ .compatible = "ti,tilcdc,tfp410", },
{ },
 };
-- 
1.9.1

Re: [PATCH] cifs: hide unused functions

[Steve French]

merged into cifs-2.6.git for-next

On Tue, Jun 27, 2017 at 10:06 AM, Arnd Bergmann  wrote:
> Some functions are only referenced under an #ifdef, causing a harmless
> warning:
>
> fs/cifs/smb2ops.c:1374:1: error: 'get_smb2_acl' defined but not used 
> [-Werror=unused-function]
>
> We could mark them __maybe_unused or add another #ifdef, I picked
> the second approach here.
>
> Fixes: b3fdda4d1e1b ("cifs: Use smb 2 - 3 and cifsacl mount options getacl 
> functions")
> Signed-off-by: Arnd Bergmann 
> ---
>  fs/cifs/smb2ops.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
> index 06494e11c570..941c40b7a870 100644
> --- a/fs/cifs/smb2ops.c
> +++ b/fs/cifs/smb2ops.c
> @@ -1288,6 +1288,7 @@ smb2_query_symlink(const unsigned int xid, struct 
> cifs_tcon *tcon,
> return rc;
>  }
>
> +#ifdef CONFIG_CIFS_ACL
>  static struct cifs_ntsd *
>  get_smb2_acl_by_fid(struct cifs_sb_info *cifs_sb,
> const struct cifs_fid *cifsfid, u32 *pacllen)
> @@ -1387,7 +1388,7 @@ get_smb2_acl(struct cifs_sb_info *cifs_sb,
> cifsFileInfo_put(open_file);
> return pntsd;
>  }
> -
> +#endif
>
>  static long smb3_zero_range(struct file *file, struct cifs_tcon *tcon,
> loff_t offset, loff_t len, bool keep_size)
> --
> 2.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Steve

Re: [PATCH] cifs: hide unused functions

[Steve French]

merged into cifs-2.6.git for-next

On Tue, Jun 27, 2017 at 10:06 AM, Arnd Bergmann  wrote:
> Some functions are only referenced under an #ifdef, causing a harmless
> warning:
>
> fs/cifs/smb2ops.c:1374:1: error: 'get_smb2_acl' defined but not used 
> [-Werror=unused-function]
>
> We could mark them __maybe_unused or add another #ifdef, I picked
> the second approach here.
>
> Fixes: b3fdda4d1e1b ("cifs: Use smb 2 - 3 and cifsacl mount options getacl 
> functions")
> Signed-off-by: Arnd Bergmann 
> ---
>  fs/cifs/smb2ops.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
> index 06494e11c570..941c40b7a870 100644
> --- a/fs/cifs/smb2ops.c
> +++ b/fs/cifs/smb2ops.c
> @@ -1288,6 +1288,7 @@ smb2_query_symlink(const unsigned int xid, struct 
> cifs_tcon *tcon,
> return rc;
>  }
>
> +#ifdef CONFIG_CIFS_ACL
>  static struct cifs_ntsd *
>  get_smb2_acl_by_fid(struct cifs_sb_info *cifs_sb,
> const struct cifs_fid *cifsfid, u32 *pacllen)
> @@ -1387,7 +1388,7 @@ get_smb2_acl(struct cifs_sb_info *cifs_sb,
> cifsFileInfo_put(open_file);
> return pntsd;
>  }
> -
> +#endif
>
>  static long smb3_zero_range(struct file *file, struct cifs_tcon *tcon,
> loff_t offset, loff_t len, bool keep_size)
> --
> 2.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Steve

[PATCH] soc: mtk-pmic-wrap: make of_device_ids const.

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index a5f1093..1205a671 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -1067,7 +1067,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
*dev_id)
.init_soc_specific = pwrap_mt2701_init_soc_specific,
 };
 
-static struct pmic_wrapper_type pwrap_mt8135 = {
+static const struct pmic_wrapper_type pwrap_mt8135 = {
.regs = mt8135_regs,
.type = PWRAP_MT8135,
.arb_en_all = 0x1ff,
@@ -1079,7 +1079,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
*dev_id)
.init_soc_specific = pwrap_mt8135_init_soc_specific,
 };
 
-static struct pmic_wrapper_type pwrap_mt8173 = {
+static const struct pmic_wrapper_type pwrap_mt8173 = {
.regs = mt8173_regs,
.type = PWRAP_MT8173,
.arb_en_all = 0x3f,
@@ -1091,7 +1091,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
*dev_id)
.init_soc_specific = pwrap_mt8173_init_soc_specific,
 };
 
-static struct of_device_id of_pwrap_match_tbl[] = {
+static const struct of_device_id of_pwrap_match_tbl[] = {
{
.compatible = "mediatek,mt2701-pwrap",
.data = _mt2701,
-- 
1.9.1

[PATCH] soc: mtk-pmic-wrap: make of_device_ids const.

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index a5f1093..1205a671 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -1067,7 +1067,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
*dev_id)
.init_soc_specific = pwrap_mt2701_init_soc_specific,
 };
 
-static struct pmic_wrapper_type pwrap_mt8135 = {
+static const struct pmic_wrapper_type pwrap_mt8135 = {
.regs = mt8135_regs,
.type = PWRAP_MT8135,
.arb_en_all = 0x1ff,
@@ -1079,7 +1079,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
*dev_id)
.init_soc_specific = pwrap_mt8135_init_soc_specific,
 };
 
-static struct pmic_wrapper_type pwrap_mt8173 = {
+static const struct pmic_wrapper_type pwrap_mt8173 = {
.regs = mt8173_regs,
.type = PWRAP_MT8173,
.arb_en_all = 0x3f,
@@ -1091,7 +1091,7 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
*dev_id)
.init_soc_specific = pwrap_mt8173_init_soc_specific,
 };
 
-static struct of_device_id of_pwrap_match_tbl[] = {
+static const struct of_device_id of_pwrap_match_tbl[] = {
{
.compatible = "mediatek,mt2701-pwrap",
.data = _mt2701,
-- 
1.9.1

[PATCH v5] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
Changes in v4:
  Change log was missing.
Changes in v3:
  Change log correction. Added change log below '---'.
Changes in v2:
  Remove useless initialization of retval.

 drivers/usb/host/ohci-pxa27x.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 79efde8f..21c010f 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -274,14 +274,16 @@ static inline void pxa27x_reset_hc(struct pxa27x_ohci 
*pxa_ohci)
 
 static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, struct device *dev)
 {
-   int retval = 0;
+   int retval;
struct pxaohci_platform_data *inf;
uint32_t uhchr;
struct usb_hcd *hcd = dev_get_drvdata(dev);
 
inf = dev_get_platdata(dev);
 
-   clk_prepare_enable(pxa_ohci->clk);
+   retval = clk_prepare_enable(pxa_ohci->clk);
+   if (retval)
+   return retval;
 
pxa27x_reset_hc(pxa_ohci);
 
@@ -296,8 +298,10 @@ static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, 
struct device *dev)
if (inf->init)
retval = inf->init(dev);
 
-   if (retval < 0)
+   if (retval < 0) {
+   clk_disable_unprepare(pxa_ohci->clk);
return retval;
+   }
 
if (cpu_is_pxa3xx())
pxa3xx_u2d_start_hc(>self);
-- 
1.9.1

[PATCH v5] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
Changes in v4:
  Change log was missing.
Changes in v3:
  Change log correction. Added change log below '---'.
Changes in v2:
  Remove useless initialization of retval.

 drivers/usb/host/ohci-pxa27x.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 79efde8f..21c010f 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -274,14 +274,16 @@ static inline void pxa27x_reset_hc(struct pxa27x_ohci 
*pxa_ohci)
 
 static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, struct device *dev)
 {
-   int retval = 0;
+   int retval;
struct pxaohci_platform_data *inf;
uint32_t uhchr;
struct usb_hcd *hcd = dev_get_drvdata(dev);
 
inf = dev_get_platdata(dev);
 
-   clk_prepare_enable(pxa_ohci->clk);
+   retval = clk_prepare_enable(pxa_ohci->clk);
+   if (retval)
+   return retval;
 
pxa27x_reset_hc(pxa_ohci);
 
@@ -296,8 +298,10 @@ static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, 
struct device *dev)
if (inf->init)
retval = inf->init(dev);
 
-   if (retval < 0)
+   if (retval < 0) {
+   clk_disable_unprepare(pxa_ohci->clk);
return retval;
+   }
 
if (cpu_is_pxa3xx())
pxa3xx_u2d_start_hc(>self);
-- 
1.9.1

Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region

[Kyle Huey]

On Tue, Jun 27, 2017 at 7:09 PM, Jin, Yao  wrote:
> Hi,
>
> In theory, the PMI interrupts in skid region should be dropped, right?

No, why would they be dropped?

My understanding of the situation is as follows:

There is some time, call it t_0, where the hardware counter overflows.
The PMU triggers an interrupt, but this is not instantaneous.  Call
the time when the interrupt is actually delivered t_1.  Then t_1 - t_0
is the "skid".

Note that if the counter is `exclude_kernel`, then at t_0 the CPU
*must* be running a userspace program.  But by t_1, the CPU may be
doing something else.  Your patch changed things so that if at t_1 the
CPU is in the kernel, then the interrupt is discarded.  But rr has
programmed the counter to deliver a signal on overflow (via F_SETSIG
on the fd returned by perf_event_open).  This change results in the
signal never being delivered, because the interrupt was ignored.
(More accurately, the signal is delivered the *next* time the counter
overflows, which is far past where we wanted to inject our
asynchronous event into our tracee.

It seems to me that it might be reasonable to ignore the interrupt if
the purpose of the interrupt is to trigger sampling of the CPUs
register state.  But if the interrupt will trigger some other
operation, such as a signal on an fd, then there's no reason to drop
it.

> For a userspace debugger, is it the only choice that relies on the *skid*
> PMI interrupt?

I don't understand this question, but hopefully the above clarified things.

- Kyle

> Thanks
> Jin Yao
>
>
> On 6/28/2017 9:01 AM, Kyle Huey wrote:
>>
>> Sent again with LKML CCd, sorry for the noise.
>>
>> - Kyle
>>
>> On Tue, Jun 27, 2017 at 5:38 PM, Kyle Huey  wrote:
>>>
>>> cc1582c231ea introduced a regression in v4.12.0-rc5, and appears to be
>>> a candidate for backporting to stable branches.
>>>
>>> rr, a userspace record and replay debugger[0], uses the PMU interrupt
>>> to stop a program during replay to inject asynchronous events such as
>>> signals.  We are counting retired conditional branches in userspace
>>> only.  This changeset causes the kernel to drop interrupts on the
>>> floor if, during the PMU interrupt's "skid" region, the CPU enters
>>> kernel mode for whatever reason.  When replaying traces of complex
>>> programs such as Firefox, we intermittently fail to deliver
>>> asynchronous events on time, leading the replay to diverge from the
>>> recorded state.
>>>
>>> It seems like this change should, at a bare minimum, be limited to
>>> counters that actually perform sampling of register state when the
>>> interrupt fires.  In our case, with the retired conditional branches
>>> counter restricted to counting userspace events only, it makes no
>>> difference that the PMU interrupt happened to be delivered in the
>>> kernel.
>>>
>>> As this makes rr unusable on complex applications and cannot be
>>> efficiently worked around, we would appreciate this being addressed
>>> before 4.12 is finalized, and the regression not being introduced to
>>> stable branches.
>>>
>>> Thanks,
>>>
>>> - Kyle
>>>
>>> [0] http://rr-project.org/
>
>

Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region

[Kyle Huey]

On Tue, Jun 27, 2017 at 7:09 PM, Jin, Yao  wrote:
> Hi,
>
> In theory, the PMI interrupts in skid region should be dropped, right?

No, why would they be dropped?

My understanding of the situation is as follows:

There is some time, call it t_0, where the hardware counter overflows.
The PMU triggers an interrupt, but this is not instantaneous.  Call
the time when the interrupt is actually delivered t_1.  Then t_1 - t_0
is the "skid".

Note that if the counter is `exclude_kernel`, then at t_0 the CPU
*must* be running a userspace program.  But by t_1, the CPU may be
doing something else.  Your patch changed things so that if at t_1 the
CPU is in the kernel, then the interrupt is discarded.  But rr has
programmed the counter to deliver a signal on overflow (via F_SETSIG
on the fd returned by perf_event_open).  This change results in the
signal never being delivered, because the interrupt was ignored.
(More accurately, the signal is delivered the *next* time the counter
overflows, which is far past where we wanted to inject our
asynchronous event into our tracee.

It seems to me that it might be reasonable to ignore the interrupt if
the purpose of the interrupt is to trigger sampling of the CPUs
register state.  But if the interrupt will trigger some other
operation, such as a signal on an fd, then there's no reason to drop
it.

> For a userspace debugger, is it the only choice that relies on the *skid*
> PMI interrupt?

I don't understand this question, but hopefully the above clarified things.

- Kyle

> Thanks
> Jin Yao
>
>
> On 6/28/2017 9:01 AM, Kyle Huey wrote:
>>
>> Sent again with LKML CCd, sorry for the noise.
>>
>> - Kyle
>>
>> On Tue, Jun 27, 2017 at 5:38 PM, Kyle Huey  wrote:
>>>
>>> cc1582c231ea introduced a regression in v4.12.0-rc5, and appears to be
>>> a candidate for backporting to stable branches.
>>>
>>> rr, a userspace record and replay debugger[0], uses the PMU interrupt
>>> to stop a program during replay to inject asynchronous events such as
>>> signals.  We are counting retired conditional branches in userspace
>>> only.  This changeset causes the kernel to drop interrupts on the
>>> floor if, during the PMU interrupt's "skid" region, the CPU enters
>>> kernel mode for whatever reason.  When replaying traces of complex
>>> programs such as Firefox, we intermittently fail to deliver
>>> asynchronous events on time, leading the replay to diverge from the
>>> recorded state.
>>>
>>> It seems like this change should, at a bare minimum, be limited to
>>> counters that actually perform sampling of register state when the
>>> interrupt fires.  In our case, with the retired conditional branches
>>> counter restricted to counting userspace events only, it makes no
>>> difference that the PMU interrupt happened to be delivered in the
>>> kernel.
>>>
>>> As this makes rr unusable on complex applications and cannot be
>>> efficiently worked around, we would appreciate this being addressed
>>> before 4.12 is finalized, and the regression not being introduced to
>>> stable branches.
>>>
>>> Thanks,
>>>
>>> - Kyle
>>>
>>> [0] http://rr-project.org/
>
>

Re: 4.12.0-rc5+git: kernel BUG at arch/x86/mm/highmem_32.c:47

[Meelis Roos]

> > > > This is 4.12.0-rc5-00137-ga090bd4ff838 on a dual AthlonMP server tha 
> > > > has 
> > > > been running fine until 4.11.0 included. 4.12.0-rc5-00137-ga090bd4ff838 
> > > > was the first kernel after 4.11 that I tried and the problem happened 
> > > > while compiling next kernel from git.
> > > 
> > > I can't reproduce this in a guest. Can you send .config please?
> > 
> > Here it is.
> 
> Thanks.
> 
> So plain 4.12.0-rc7 booted all the way in the athlon guest here. So I
> either can't reproduce in the guest or I need to try linux-next. Well,
> tomorrow...

It booted on my physical machine too, and trouble happened during 
compilation on both CPUs with make -j2.

On next try it just rebooted.

-- 
Meelis Roos (mr...@linux.ee)

Re: 4.12.0-rc5+git: kernel BUG at arch/x86/mm/highmem_32.c:47

[Meelis Roos]

> > > > This is 4.12.0-rc5-00137-ga090bd4ff838 on a dual AthlonMP server tha 
> > > > has 
> > > > been running fine until 4.11.0 included. 4.12.0-rc5-00137-ga090bd4ff838 
> > > > was the first kernel after 4.11 that I tried and the problem happened 
> > > > while compiling next kernel from git.
> > > 
> > > I can't reproduce this in a guest. Can you send .config please?
> > 
> > Here it is.
> 
> Thanks.
> 
> So plain 4.12.0-rc7 booted all the way in the athlon guest here. So I
> either can't reproduce in the guest or I need to try linux-next. Well,
> tomorrow...

It booted on my physical machine too, and trouble happened during 
compilation on both CPUs with make -j2.

On next try it just rebooted.

-- 
Meelis Roos (mr...@linux.ee)

[PATCH 1/1] xen/blkfront: always allocate grants first from per-queue persistent grants

[Dongli Zhang]

This patch partially reverts 3df0e50 ("xen/blkfront: pseudo support for
multi hardware queues/rings"). The xen-blkfront queue/ring might hang due
to grants allocation failure in the situation when gnttab_free_head is
almost empty while many persistent grants are reserved for this queue/ring.

As persistent grants management was per-queue since 73716df ("xen/blkfront:
make persistent grants pool per-queue"), we should always allocate from
persistent grants first.

Signed-off-by: Dongli Zhang 
---
 drivers/block/xen-blkfront.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 3945963..d2b759f 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -713,6 +713,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
 * existing persistent grants, or if we have to get new grants,
 * as there are not sufficiently many free.
 */
+   bool new_persistent_gnts = false;
struct scatterlist *sg;
int num_sg, max_grefs, num_grant;
 
@@ -724,12 +725,13 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
 */
max_grefs += INDIRECT_GREFS(max_grefs);
 
-   /*
-* We have to reserve 'max_grefs' grants because persistent
-* grants are shared by all rings.
-*/
-   if (max_grefs > 0)
-   if (gnttab_alloc_grant_references(max_grefs, _head) 
< 0) {
+   /* Check if we have enough persistent grants to allocate a requests */
+   if (rinfo->persistent_gnts_c < max_grefs) {
+   new_persistent_gnts = true;
+
+   if (gnttab_alloc_grant_references(
+   max_grefs - rinfo->persistent_gnts_c,
+   _head) < 0) {
gnttab_request_free_callback(
>callback,
blkif_restart_queue_callback,
@@ -737,6 +739,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
max_grefs);
return 1;
}
+   }
 
/* Fill out a communications ring structure. */
id = blkif_ring_get_request(rinfo, req, _req);
@@ -837,7 +840,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
if (unlikely(require_extra_req))
rinfo->shadow[extra_id].req = *extra_ring_req;
 
-   if (max_grefs > 0)
+   if (new_persistent_gnts)
gnttab_free_grant_references(setup.gref_head);
 
return 0;
-- 
2.7.4

[PATCH 1/1] xen/blkfront: always allocate grants first from per-queue persistent grants

[Dongli Zhang]

This patch partially reverts 3df0e50 ("xen/blkfront: pseudo support for
multi hardware queues/rings"). The xen-blkfront queue/ring might hang due
to grants allocation failure in the situation when gnttab_free_head is
almost empty while many persistent grants are reserved for this queue/ring.

As persistent grants management was per-queue since 73716df ("xen/blkfront:
make persistent grants pool per-queue"), we should always allocate from
persistent grants first.

Signed-off-by: Dongli Zhang 
---
 drivers/block/xen-blkfront.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 3945963..d2b759f 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -713,6 +713,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
 * existing persistent grants, or if we have to get new grants,
 * as there are not sufficiently many free.
 */
+   bool new_persistent_gnts = false;
struct scatterlist *sg;
int num_sg, max_grefs, num_grant;
 
@@ -724,12 +725,13 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
 */
max_grefs += INDIRECT_GREFS(max_grefs);
 
-   /*
-* We have to reserve 'max_grefs' grants because persistent
-* grants are shared by all rings.
-*/
-   if (max_grefs > 0)
-   if (gnttab_alloc_grant_references(max_grefs, _head) 
< 0) {
+   /* Check if we have enough persistent grants to allocate a requests */
+   if (rinfo->persistent_gnts_c < max_grefs) {
+   new_persistent_gnts = true;
+
+   if (gnttab_alloc_grant_references(
+   max_grefs - rinfo->persistent_gnts_c,
+   _head) < 0) {
gnttab_request_free_callback(
>callback,
blkif_restart_queue_callback,
@@ -737,6 +739,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
max_grefs);
return 1;
}
+   }
 
/* Fill out a communications ring structure. */
id = blkif_ring_get_request(rinfo, req, _req);
@@ -837,7 +840,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
if (unlikely(require_extra_req))
rinfo->shadow[extra_id].req = *extra_ring_req;
 
-   if (max_grefs > 0)
+   if (new_persistent_gnts)
gnttab_free_grant_references(setup.gref_head);
 
return 0;
-- 
2.7.4

Re: [PATCH] ACPI: nfit: constify *_attribute_group.

[Dan Williams]

On Thu, Jun 22, 2017 at 3:14 AM, Arvind Yadav  wrote:
> File size before:
>textdata bss dec hex filename
>   207921580 994   233665b46 drivers/acpi/nfit/core.o
>
> File size After adding 'const':
>textdata bss dec hex filename
>   209681388 994   233505b36 drivers/acpi/nfit/core.o
>
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/acpi/nfit/core.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Looks good to me, applied.

Re: [PATCH] ACPI: nfit: constify *_attribute_group.

[Dan Williams]

On Thu, Jun 22, 2017 at 3:14 AM, Arvind Yadav  wrote:
> File size before:
>textdata bss dec hex filename
>   207921580 994   233665b46 drivers/acpi/nfit/core.o
>
> File size After adding 'const':
>textdata bss dec hex filename
>   209681388 994   233505b36 drivers/acpi/nfit/core.o
>
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/acpi/nfit/core.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Looks good to me, applied.

Re: [PATCH v2] spi: rockchip: Disable Runtime PM when chip select is asserted

[jeffy]

Hi doug,

thanx for your comments.

On 06/28/2017 03:27 AM, Doug Anderson wrote:

Hi,

On Mon, Jun 26, 2017 at 7:20 PM, Jeffy Chen  wrote:

The rockchip spi would stop driving pins when runtime suspended, which
might break slave's xfer(for example cros_ec).

Since we have pullups on those pins, we only need to care about the CS
asserted case.

So let's keep the spi alive when chip select is asserted for that.

Also change use pm_runtime_put instead of pm_runtime_put_sync.

Suggested-by: Doug Anderson 
Signed-off-by: Jeffy Chen 

---

Changes in v2:
Improve commit message and comments and coding style.

  drivers/spi/spi-rockchip.c | 23 ++-
  1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index acf31f3..ea0edd7 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -264,7 +264,7 @@ static inline u32 rx_max(struct rockchip_spi *rs)

  static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
  {
-   u32 ser;
+   u32 ser, new_ser;
 struct spi_master *master = spi->master;
 struct rockchip_spi *rs = spi_master_get_devdata(master);

@@ -288,13 +288,26 @@ static void rockchip_spi_set_cs(struct spi_device *spi, 
bool enable)
  * Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
  */
 if (!enable)
-   ser |= 1 << spi->chip_select;
+   new_ser = ser | BIT(spi->chip_select);
 else
-   ser &= ~(1 << spi->chip_select);
+   new_ser = ser & ~BIT(spi->chip_select);

-   writel_relaxed(ser, rs->regs + ROCKCHIP_SPI_SER);
+   if (new_ser != ser) {


IMHO it's not a great idea to use the state of the hardware register
here.  Using the state of the hardware register probably works OK, but
it makes me just a little nervous.  If something happened to the state
of the register (someone used /dev/mem to tweak, or the peripherals
got reset, or ...) then you could end up with an unbalanced set of PM
Runtime calls.  I know none of those things are common, but it still
seems less than great to me.

I'd rather we kept track in "struct rockchip_spi" whether we already
called pm_runtime_get_sync().  AKA the following (untested):

bool cs_asserted = !enable;

/* Return immediately for no-op */
if (cs_asserted == rs->cs_asserted)
   return;

/* Keep things powered as long as CS is asserted */
if (cs_asserted) {
   pm_runtime_get_sync(rs->dev);
   rs->cs_asserted = true;
}

ser = ...
...
...

if (!cs_asserted)
   pm_runtime_put(rs->dev);


NOTE: another advantage of storing the state in 'struct rockchip_spi'
is that you can access it without pm_runtime_get_sync().


ok, that make sense :)



+   writel_relaxed(new_ser, rs->regs + ROCKCHIP_SPI_SER);

-   pm_runtime_put_sync(rs->dev);
+   /*
+* The rockchip spi would stop driving all pins when powered
+* down.
+* So hold a runtime PM reference as long as CS is asserted.
+*/
+   if (!enable)
+   return;
+
+   /* Drop reference from when we first asserted CS */
+   pm_runtime_put(rs->dev);
+   }
+
+   pm_runtime_put(rs->dev);


One note is that you should still submit your patch to add
"SPI_MASTER_GPIO_SS" to spi-rockchip.c.  It's important that the SPI
driver see the CS transitions so that it can do the PM Runtime get/put
even when someone uses a GPIO chip select.  Even though the GPIO chip
select will keep state, we don't want the rest of the lines to stop
being driven.

ok, will do.



-Doug

Re: [PATCH v2] spi: rockchip: Disable Runtime PM when chip select is asserted

[jeffy]

Hi doug,

thanx for your comments.

On 06/28/2017 03:27 AM, Doug Anderson wrote:

Hi,

On Mon, Jun 26, 2017 at 7:20 PM, Jeffy Chen  wrote:

The rockchip spi would stop driving pins when runtime suspended, which
might break slave's xfer(for example cros_ec).

Since we have pullups on those pins, we only need to care about the CS
asserted case.

So let's keep the spi alive when chip select is asserted for that.

Also change use pm_runtime_put instead of pm_runtime_put_sync.

Suggested-by: Doug Anderson 
Signed-off-by: Jeffy Chen 

---

Changes in v2:
Improve commit message and comments and coding style.

  drivers/spi/spi-rockchip.c | 23 ++-
  1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index acf31f3..ea0edd7 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -264,7 +264,7 @@ static inline u32 rx_max(struct rockchip_spi *rs)

  static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
  {
-   u32 ser;
+   u32 ser, new_ser;
 struct spi_master *master = spi->master;
 struct rockchip_spi *rs = spi_master_get_devdata(master);

@@ -288,13 +288,26 @@ static void rockchip_spi_set_cs(struct spi_device *spi, 
bool enable)
  * Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
  */
 if (!enable)
-   ser |= 1 << spi->chip_select;
+   new_ser = ser | BIT(spi->chip_select);
 else
-   ser &= ~(1 << spi->chip_select);
+   new_ser = ser & ~BIT(spi->chip_select);

-   writel_relaxed(ser, rs->regs + ROCKCHIP_SPI_SER);
+   if (new_ser != ser) {


IMHO it's not a great idea to use the state of the hardware register
here.  Using the state of the hardware register probably works OK, but
it makes me just a little nervous.  If something happened to the state
of the register (someone used /dev/mem to tweak, or the peripherals
got reset, or ...) then you could end up with an unbalanced set of PM
Runtime calls.  I know none of those things are common, but it still
seems less than great to me.

I'd rather we kept track in "struct rockchip_spi" whether we already
called pm_runtime_get_sync().  AKA the following (untested):

bool cs_asserted = !enable;

/* Return immediately for no-op */
if (cs_asserted == rs->cs_asserted)
   return;

/* Keep things powered as long as CS is asserted */
if (cs_asserted) {
   pm_runtime_get_sync(rs->dev);
   rs->cs_asserted = true;
}

ser = ...
...
...

if (!cs_asserted)
   pm_runtime_put(rs->dev);


NOTE: another advantage of storing the state in 'struct rockchip_spi'
is that you can access it without pm_runtime_get_sync().


ok, that make sense :)



+   writel_relaxed(new_ser, rs->regs + ROCKCHIP_SPI_SER);

-   pm_runtime_put_sync(rs->dev);
+   /*
+* The rockchip spi would stop driving all pins when powered
+* down.
+* So hold a runtime PM reference as long as CS is asserted.
+*/
+   if (!enable)
+   return;
+
+   /* Drop reference from when we first asserted CS */
+   pm_runtime_put(rs->dev);
+   }
+
+   pm_runtime_put(rs->dev);


One note is that you should still submit your patch to add
"SPI_MASTER_GPIO_SS" to spi-rockchip.c.  It's important that the SPI
driver see the CS transitions so that it can do the PM Runtime get/put
even when someone uses a GPIO chip select.  Even though the GPIO chip
select will keep state, we don't want the rest of the lines to stop
being driven.

ok, will do.



-Doug

[PATCH v3 1/2] spi: rockchip: Set GPIO_SS flag to enable Slave Select with GPIO CS

[Jeffy Chen]

The rockchip spi still requires slave selection when using GPIO CS.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 drivers/spi/spi-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index bab9b13..52ea160 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -749,6 +749,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->transfer_one = rockchip_spi_transfer_one;
master->max_transfer_size = rockchip_spi_max_transfer_size;
master->handle_err = rockchip_spi_handle_err;
+   master->flags = SPI_MASTER_GPIO_SS;
 
rs->dma_tx.ch = dma_request_chan(rs->dev, "tx");
if (IS_ERR(rs->dma_tx.ch)) {
-- 
2.1.4

[PATCH v3 1/2] spi: rockchip: Set GPIO_SS flag to enable Slave Select with GPIO CS

[Jeffy Chen]

The rockchip spi still requires slave selection when using GPIO CS.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 drivers/spi/spi-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index bab9b13..52ea160 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -749,6 +749,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->transfer_one = rockchip_spi_transfer_one;
master->max_transfer_size = rockchip_spi_max_transfer_size;
master->handle_err = rockchip_spi_handle_err;
+   master->flags = SPI_MASTER_GPIO_SS;
 
rs->dma_tx.ch = dma_request_chan(rs->dev, "tx");
if (IS_ERR(rs->dma_tx.ch)) {
-- 
2.1.4

[PATCH v3 2/2] spi: rockchip: Disable Runtime PM when chip select is asserted

[Jeffy Chen]

The rockchip spi would stop driving pins when runtime suspended, which
might break slave's xfer(for example cros_ec).

Since we have pullups on those pins, we only need to care about this
when the CS asserted.

So let's keep the spi alive when chip select is asserted.

Also use pm_runtime_put instead of pm_runtime_put_sync.

Suggested-by: Doug Anderson 
Signed-off-by: Jeffy Chen 

---

Changes in v3:
Store cs states in struct rockchip_spi, and use it to detect cs state
instead of hw register.

Changes in v2:
Improve commit message and comments and coding style.

 drivers/spi/spi-rockchip.c | 51 +++---
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 52ea160..0b4a52b 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -25,6 +25,11 @@
 
 #define DRIVER_NAME "rockchip-spi"
 
+#define ROCKCHIP_SPI_CLR_BITS(reg, bits) \
+   writel_relaxed(readl_relaxed(reg) & ~(bits), reg)
+#define ROCKCHIP_SPI_SET_BITS(reg, bits) \
+   writel_relaxed(readl_relaxed(reg) | (bits), reg)
+
 /* SPI register offsets */
 #define ROCKCHIP_SPI_CTRLR00x
 #define ROCKCHIP_SPI_CTRLR10x0004
@@ -149,6 +154,8 @@
  */
 #define ROCKCHIP_SPI_MAX_TRANLEN   0x
 
+#define ROCKCHIP_SPI_MAX_CS_NUM2
+
 enum rockchip_ssi_type {
SSI_MOTO_SPI = 0,
SSI_TI_SSP,
@@ -193,6 +200,8 @@ struct rockchip_spi {
/* protect state */
spinlock_t lock;
 
+   bool cs_asserted[ROCKCHIP_SPI_MAX_CS_NUM];
+
u32 use_dma;
struct sg_table tx_sg;
struct sg_table rx_sg;
@@ -264,37 +273,29 @@ static inline u32 rx_max(struct rockchip_spi *rs)
 
 static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
 {
-   u32 ser;
struct spi_master *master = spi->master;
struct rockchip_spi *rs = spi_master_get_devdata(master);
+   bool cs_asserted = !enable;
 
-   pm_runtime_get_sync(rs->dev);
+   /* Return immediately for no-op */
+   if (cs_asserted == rs->cs_asserted[spi->chip_select])
+   return;
 
-   ser = readl_relaxed(rs->regs + ROCKCHIP_SPI_SER) & SER_MASK;
+   if (cs_asserted) {
+   /* Keep things powered as long as CS is asserted */
+   pm_runtime_get_sync(rs->dev);
 
-   /*
-* drivers/spi/spi.c:
-* static void spi_set_cs(struct spi_device *spi, bool enable)
-* {
-*  if (spi->mode & SPI_CS_HIGH)
-*  enable = !enable;
-*
-*  if (spi->cs_gpio >= 0)
-*  gpio_set_value(spi->cs_gpio, !enable);
-*  else if (spi->master->set_cs)
-*  spi->master->set_cs(spi, !enable);
-* }
-*
-* Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
-*/
-   if (!enable)
-   ser |= 1 << spi->chip_select;
-   else
-   ser &= ~(1 << spi->chip_select);
+   ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER,
+ BIT(spi->chip_select));
+   } else {
+   ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER,
+ BIT(spi->chip_select));
 
-   writel_relaxed(ser, rs->regs + ROCKCHIP_SPI_SER);
+   /* Drop reference from when we first asserted CS */
+   pm_runtime_put(rs->dev);
+   }
 
-   pm_runtime_put_sync(rs->dev);
+   rs->cs_asserted[spi->chip_select] = cs_asserted;
 }
 
 static int rockchip_spi_prepare_message(struct spi_master *master,
@@ -739,7 +740,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->auto_runtime_pm = true;
master->bus_num = pdev->id;
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP;
-   master->num_chipselect = 2;
+   master->num_chipselect = ROCKCHIP_SPI_MAX_CS_NUM;
master->dev.of_node = pdev->dev.of_node;
master->bits_per_word_mask = SPI_BPW_MASK(16) | SPI_BPW_MASK(8);
 
-- 
2.1.4

[PATCH v3 2/2] spi: rockchip: Disable Runtime PM when chip select is asserted

[Jeffy Chen]

The rockchip spi would stop driving pins when runtime suspended, which
might break slave's xfer(for example cros_ec).

Since we have pullups on those pins, we only need to care about this
when the CS asserted.

So let's keep the spi alive when chip select is asserted.

Also use pm_runtime_put instead of pm_runtime_put_sync.

Suggested-by: Doug Anderson 
Signed-off-by: Jeffy Chen 

---

Changes in v3:
Store cs states in struct rockchip_spi, and use it to detect cs state
instead of hw register.

Changes in v2:
Improve commit message and comments and coding style.

 drivers/spi/spi-rockchip.c | 51 +++---
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 52ea160..0b4a52b 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -25,6 +25,11 @@
 
 #define DRIVER_NAME "rockchip-spi"
 
+#define ROCKCHIP_SPI_CLR_BITS(reg, bits) \
+   writel_relaxed(readl_relaxed(reg) & ~(bits), reg)
+#define ROCKCHIP_SPI_SET_BITS(reg, bits) \
+   writel_relaxed(readl_relaxed(reg) | (bits), reg)
+
 /* SPI register offsets */
 #define ROCKCHIP_SPI_CTRLR00x
 #define ROCKCHIP_SPI_CTRLR10x0004
@@ -149,6 +154,8 @@
  */
 #define ROCKCHIP_SPI_MAX_TRANLEN   0x
 
+#define ROCKCHIP_SPI_MAX_CS_NUM2
+
 enum rockchip_ssi_type {
SSI_MOTO_SPI = 0,
SSI_TI_SSP,
@@ -193,6 +200,8 @@ struct rockchip_spi {
/* protect state */
spinlock_t lock;
 
+   bool cs_asserted[ROCKCHIP_SPI_MAX_CS_NUM];
+
u32 use_dma;
struct sg_table tx_sg;
struct sg_table rx_sg;
@@ -264,37 +273,29 @@ static inline u32 rx_max(struct rockchip_spi *rs)
 
 static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
 {
-   u32 ser;
struct spi_master *master = spi->master;
struct rockchip_spi *rs = spi_master_get_devdata(master);
+   bool cs_asserted = !enable;
 
-   pm_runtime_get_sync(rs->dev);
+   /* Return immediately for no-op */
+   if (cs_asserted == rs->cs_asserted[spi->chip_select])
+   return;
 
-   ser = readl_relaxed(rs->regs + ROCKCHIP_SPI_SER) & SER_MASK;
+   if (cs_asserted) {
+   /* Keep things powered as long as CS is asserted */
+   pm_runtime_get_sync(rs->dev);
 
-   /*
-* drivers/spi/spi.c:
-* static void spi_set_cs(struct spi_device *spi, bool enable)
-* {
-*  if (spi->mode & SPI_CS_HIGH)
-*  enable = !enable;
-*
-*  if (spi->cs_gpio >= 0)
-*  gpio_set_value(spi->cs_gpio, !enable);
-*  else if (spi->master->set_cs)
-*  spi->master->set_cs(spi, !enable);
-* }
-*
-* Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
-*/
-   if (!enable)
-   ser |= 1 << spi->chip_select;
-   else
-   ser &= ~(1 << spi->chip_select);
+   ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER,
+ BIT(spi->chip_select));
+   } else {
+   ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER,
+ BIT(spi->chip_select));
 
-   writel_relaxed(ser, rs->regs + ROCKCHIP_SPI_SER);
+   /* Drop reference from when we first asserted CS */
+   pm_runtime_put(rs->dev);
+   }
 
-   pm_runtime_put_sync(rs->dev);
+   rs->cs_asserted[spi->chip_select] = cs_asserted;
 }
 
 static int rockchip_spi_prepare_message(struct spi_master *master,
@@ -739,7 +740,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->auto_runtime_pm = true;
master->bus_num = pdev->id;
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP;
-   master->num_chipselect = 2;
+   master->num_chipselect = ROCKCHIP_SPI_MAX_CS_NUM;
master->dev.of_node = pdev->dev.of_node;
master->bits_per_word_mask = SPI_BPW_MASK(16) | SPI_BPW_MASK(8);
 
-- 
2.1.4

Re: [PATCH] powernv:idle: Clear r12 on wakeup from stop lite

[Nicholas Piggin]

On Wed, 28 Jun 2017 06:46:49 +0530
Akshay Adiga  wrote:

> pnv_wakeup_noloss expects R12 to contain SRR1 value to determine if
> the wakeup reason is an HMI in CHECK_HMI_INTERRUPT.
> 
> When we wakeup with ESL=0, SRR1 will not contain the wakeup reason, so
> there is no point setting R12 to SRR1.
> 
> However, we don't set R12 at all and R12 contains garbage, and still
> being used to check HMI assuming that it had SRR1. causing the
> OPAL msglog to be filled with the following print:
>   HMI: Received HMI interrupt: HMER = 0x0040
> 
> This patch clears R12 after waking up from stop with ESL=EC=0, so that
> we don't accidentally enter the HMI handler in pnv_wakeup_noloss if
> the R12[42:45] corresponds to HMI as wakeup reason.
> 
> Bug existed prior to "commit 9d29250136f6 ("powerpc/64s/idle: Avoid SRR
> usage in idle sleep/wake paths")  but was never hit in practice
> 
> Signed-off-by: Akshay Adiga 
> Fixes: 9d29250136f6 ("powerpc/64s/idle: Avoid SRR usage in idle
> sleep/wake paths")

Thanks guys, appreciate you finding and fixing my bug :)

I think this looks like the best fix. Really minor nitpick but you
could adjust the line widths on the comment slightly (mpe might do
that when merging).

Reviewed-by: Nicholas Piggin 


> ---
>  arch/powerpc/kernel/idle_book3s.S | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/idle_book3s.S 
> b/arch/powerpc/kernel/idle_book3s.S
> index 1ea14b9..34794fd 100644
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -256,6 +256,21 @@ power_enter_stop:
>   bne  .Lhandle_esl_ec_set
>   IDLE_STATE_ENTER_SEQ(PPC_STOP)
>   li  r3,0  /* Since we didn't lose state, return 0 */
> + /*
> +  * pnv_wakeup_noloss expects R12 to contain SRR1 value
> +  * to determine if the wakeup reason is an HMI in
> +  * CHECK_HMI_INTERRUPT.
> +  *
> +  * However, when we wakeup with ESL=0,
> +  * SRR1 will not contain the wakeup reason,
> +  * so there is no point setting R12 to SRR1.
> +  *
> +  * Further, we clear R12 here, so that we
> +  * don't accidentally enter the HMI
> +  * in pnv_wakeup_noloss if the
> +  * R12[42:45] == WAKE_HMI.
> +  */
> + li  r12, 0
>   b   pnv_wakeup_noloss
>  
>  .Lhandle_esl_ec_set:

Re: [PATCH] powernv:idle: Clear r12 on wakeup from stop lite

[Nicholas Piggin]

On Wed, 28 Jun 2017 06:46:49 +0530
Akshay Adiga  wrote:

> pnv_wakeup_noloss expects R12 to contain SRR1 value to determine if
> the wakeup reason is an HMI in CHECK_HMI_INTERRUPT.
> 
> When we wakeup with ESL=0, SRR1 will not contain the wakeup reason, so
> there is no point setting R12 to SRR1.
> 
> However, we don't set R12 at all and R12 contains garbage, and still
> being used to check HMI assuming that it had SRR1. causing the
> OPAL msglog to be filled with the following print:
>   HMI: Received HMI interrupt: HMER = 0x0040
> 
> This patch clears R12 after waking up from stop with ESL=EC=0, so that
> we don't accidentally enter the HMI handler in pnv_wakeup_noloss if
> the R12[42:45] corresponds to HMI as wakeup reason.
> 
> Bug existed prior to "commit 9d29250136f6 ("powerpc/64s/idle: Avoid SRR
> usage in idle sleep/wake paths")  but was never hit in practice
> 
> Signed-off-by: Akshay Adiga 
> Fixes: 9d29250136f6 ("powerpc/64s/idle: Avoid SRR usage in idle
> sleep/wake paths")

Thanks guys, appreciate you finding and fixing my bug :)

I think this looks like the best fix. Really minor nitpick but you
could adjust the line widths on the comment slightly (mpe might do
that when merging).

Reviewed-by: Nicholas Piggin 


> ---
>  arch/powerpc/kernel/idle_book3s.S | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/idle_book3s.S 
> b/arch/powerpc/kernel/idle_book3s.S
> index 1ea14b9..34794fd 100644
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -256,6 +256,21 @@ power_enter_stop:
>   bne  .Lhandle_esl_ec_set
>   IDLE_STATE_ENTER_SEQ(PPC_STOP)
>   li  r3,0  /* Since we didn't lose state, return 0 */
> + /*
> +  * pnv_wakeup_noloss expects R12 to contain SRR1 value
> +  * to determine if the wakeup reason is an HMI in
> +  * CHECK_HMI_INTERRUPT.
> +  *
> +  * However, when we wakeup with ESL=0,
> +  * SRR1 will not contain the wakeup reason,
> +  * so there is no point setting R12 to SRR1.
> +  *
> +  * Further, we clear R12 here, so that we
> +  * don't accidentally enter the HMI
> +  * in pnv_wakeup_noloss if the
> +  * R12[42:45] == WAKE_HMI.
> +  */
> + li  r12, 0
>   b   pnv_wakeup_noloss
>  
>  .Lhandle_esl_ec_set:

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

[zhong jiang]

Hi,  Ingo

Thank you for the comment.
On 2017/6/22 0:40, Ingo Molnar wrote:
> * zhong jiang  wrote:
>
>> when shift expoment is negative, left shift alway zero. therefore, we
>> modify the logic to avoid the warining.
>>
>> Signed-off-by: zhong jiang 
>> ---
>>  arch/x86/include/asm/futex.h | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
>> index b4c1f54..2425fca 100644
>> --- a/arch/x86/include/asm/futex.h
>> +++ b/arch/x86/include/asm/futex.h
>> @@ -49,8 +49,12 @@ static inline int futex_atomic_op_inuser(int encoded_op, 
>> u32 __user *uaddr)
>>  int cmparg = (encoded_op << 20) >> 20;
>>  int oldval = 0, ret, tem;
>>  
>> -if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
>> -oparg = 1 << oparg;
>> +if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
>> +if (oparg >= 0)
>> +oparg = 1 << oparg;
>> +else
>> +oparg = 0;
>> +}
> Could we avoid all these complications by using an unsigned type?
  I think it is not feasible.  a negative shift exponent is likely existence 
and reasonable.
  as the above case,  oparg is a negative is common. 

 I think it can be avoided by following change. 

  diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
index b4c1f54..3205e86 100644
--- a/arch/x86/include/asm/futex.h
+++ b/arch/x86/include/asm/futex.h
@@ -50,7 +50,7 @@ static inline int futex_atomic_op_inuser(int encoded_op, u32 
__user *uaddr)
int oldval = 0, ret, tem;

if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
-   oparg = 1 << oparg;
+   oparg = safe_shift(1, oparg);

if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 069fe79..b4edda3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -190,11 +190,6 @@ char* fb_get_buffer_offset(struct fb_info *info, struct 
fb_pixmap *buf, u32 size

 #ifdef CONFIG_LOGO

-static inline unsigned safe_shift(unsigned d, int n)
-{
-   return n < 0 ? d >> -n : d << n;
-}
-
 static void fb_set_logocmap(struct fb_info *info,
   const struct linux_logo *logo)
 {
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d043ada..f3b8856 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -841,6 +841,10 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
oops_dump_mode) { }
  */
 #define clamp_val(val, lo, hi) clamp_t(typeof(val), val, lo, hi)

+static inline unsigned safe_shift(unsigned d, int n)
+{
+   return n < 0 ? d >> -n : d << n;
+}

Thansk
zhongjiang

> Thanks,
>
>   Ingo
>
> .
>

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

[zhong jiang]

Hi,  Ingo

Thank you for the comment.
On 2017/6/22 0:40, Ingo Molnar wrote:
> * zhong jiang  wrote:
>
>> when shift expoment is negative, left shift alway zero. therefore, we
>> modify the logic to avoid the warining.
>>
>> Signed-off-by: zhong jiang 
>> ---
>>  arch/x86/include/asm/futex.h | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
>> index b4c1f54..2425fca 100644
>> --- a/arch/x86/include/asm/futex.h
>> +++ b/arch/x86/include/asm/futex.h
>> @@ -49,8 +49,12 @@ static inline int futex_atomic_op_inuser(int encoded_op, 
>> u32 __user *uaddr)
>>  int cmparg = (encoded_op << 20) >> 20;
>>  int oldval = 0, ret, tem;
>>  
>> -if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
>> -oparg = 1 << oparg;
>> +if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
>> +if (oparg >= 0)
>> +oparg = 1 << oparg;
>> +else
>> +oparg = 0;
>> +}
> Could we avoid all these complications by using an unsigned type?
  I think it is not feasible.  a negative shift exponent is likely existence 
and reasonable.
  as the above case,  oparg is a negative is common. 

 I think it can be avoided by following change. 

  diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
index b4c1f54..3205e86 100644
--- a/arch/x86/include/asm/futex.h
+++ b/arch/x86/include/asm/futex.h
@@ -50,7 +50,7 @@ static inline int futex_atomic_op_inuser(int encoded_op, u32 
__user *uaddr)
int oldval = 0, ret, tem;

if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
-   oparg = 1 << oparg;
+   oparg = safe_shift(1, oparg);

if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 069fe79..b4edda3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -190,11 +190,6 @@ char* fb_get_buffer_offset(struct fb_info *info, struct 
fb_pixmap *buf, u32 size

 #ifdef CONFIG_LOGO

-static inline unsigned safe_shift(unsigned d, int n)
-{
-   return n < 0 ? d >> -n : d << n;
-}
-
 static void fb_set_logocmap(struct fb_info *info,
   const struct linux_logo *logo)
 {
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d043ada..f3b8856 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -841,6 +841,10 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
oops_dump_mode) { }
  */
 #define clamp_val(val, lo, hi) clamp_t(typeof(val), val, lo, hi)

+static inline unsigned safe_shift(unsigned d, int n)
+{
+   return n < 0 ? d >> -n : d << n;
+}

Thansk
zhongjiang

> Thanks,
>
>   Ingo
>
> .
>

Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

[Kees Cook]

On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan  wrote:
> On 06/27/2017 09:16 AM, Greg KH wrote:
>> On Tue, Jun 27, 2017 at 05:13:59PM +0200, Greg KH wrote:
>>> On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote:
 selftest capabilities test failed on linux mainline and linux-next and
 PASS on linux-4.4.70+
>>>
>>> Odd.  Any chance you can use 'git bisect' to track down the offending
>>> commit?
>>>
>>> Does this also fail on x86 or any other platform you have available?
>>> Let me go try this on my laptop...
>>
>> Ok, Linus's current tree (4.12.0-rc7+) also fails on this.  I'm guessing
>> it's failing, it's hard to understand the output.  If only we had TAP
>> output for this test :)
>
> As far as the output, it isn't bad. Not TAP13 will help make it better.
> The problem seems to with the individual messages error/info. messages
> themselves. This test has the quality of a developer unit test and the
> messages could be improved for non-developer use.
>
> I ran the test on 4.11.8-rc1+ and 4.9.35-rc1 see the same failure.
> It would be difficult to bisect this since it spans multiple releases.
> I am hoping Andy can give us some insight.

I bisected this to:

commit 380cf5ba6b0a0b307f4afb62b186ca801defb203
Author: Andy Lutomirski 
Date:   Thu Jun 23 16:41:05 2016 -0500

fs: Treat foreign mounts as nosuid

I assume the test needs updating, but I bet Andy knows for sure. I can
look into this more closely in the morning.

-Kees

-- 
Kees Cook
Pixel Security

Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

[Kees Cook]

On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan  wrote:
> On 06/27/2017 09:16 AM, Greg KH wrote:
>> On Tue, Jun 27, 2017 at 05:13:59PM +0200, Greg KH wrote:
>>> On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote:
 selftest capabilities test failed on linux mainline and linux-next and
 PASS on linux-4.4.70+
>>>
>>> Odd.  Any chance you can use 'git bisect' to track down the offending
>>> commit?
>>>
>>> Does this also fail on x86 or any other platform you have available?
>>> Let me go try this on my laptop...
>>
>> Ok, Linus's current tree (4.12.0-rc7+) also fails on this.  I'm guessing
>> it's failing, it's hard to understand the output.  If only we had TAP
>> output for this test :)
>
> As far as the output, it isn't bad. Not TAP13 will help make it better.
> The problem seems to with the individual messages error/info. messages
> themselves. This test has the quality of a developer unit test and the
> messages could be improved for non-developer use.
>
> I ran the test on 4.11.8-rc1+ and 4.9.35-rc1 see the same failure.
> It would be difficult to bisect this since it spans multiple releases.
> I am hoping Andy can give us some insight.

I bisected this to:

commit 380cf5ba6b0a0b307f4afb62b186ca801defb203
Author: Andy Lutomirski 
Date:   Thu Jun 23 16:41:05 2016 -0500

fs: Treat foreign mounts as nosuid

I assume the test needs updating, but I bet Andy knows for sure. I can
look into this more closely in the morning.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

[Michał Kępień]

> On Sat, Jun 24, 2017 at 02:25:46AM +0200, Rafael Wysocki wrote:
> > On Wednesday, June 21, 2017 11:15:43 AM Darren Hart wrote:
> > > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote:
> > > > All ACPI device notify callbacks are invoked using acpi_os_execute(),
> > > > which causes the supplied callback to be queued to a static workqueue
> > > > which always executes on CPU 0.  This means that there is no possibility
> > > > for any ACPI device notify callback to be concurrently executed on
> > > > multiple CPUs, which in the case of fujitsu-laptop means that using a
> > > > locked kfifo for handling hotkeys is redundant: as hotkey scancodes are
> > > > only pushed and popped from within acpi_fujitsu_laptop_notify(), no risk
> > > > of concurrent pushing and popping exists.
> > > 
> > > Was the kfifo causing a problem currently or for the migration to separate
> > > modules? Is this purely a simplification?
> > > 
> > > Rafael, the above rationale appears sound to me. Do you have any concerns?
> > 
> > I actually do.
> > 
> > While this is the case today, making the driver code depend on it in a hard 
> > way
> > sort of makes it difficult to change in the future if need be.
> 
> OK, if we aren't guaranteed for this to run on CPU 0 in the future, and this
> will be annoying to debug if it does changes, let's skip the kfifo change.
> 
> I have removed this patch, and fixed up the merge conflicts of the remaining 6
> patches here:
> 
> http://git.infradead.org/linux-platform-drivers-x86.git/shortlog/refs/heads/fujitsu
> 
> Michal / Jonathan, would you please review and let me know if this is what you
> would have done / approve the rebase?

The only issue I can see is that the push/pop debug messages in the last
patch contain the word "buffer" instead of the original "ringbuffer".
The dropped kfifo patch changed the wording from "ringbuffer" to
"buffer" as applying it means there is no ringbuffer any more, but since
it was not applied in the end, I guess the original wording should stay
in place.

The rest looks good to me.

-- 
Best regards,
Michał Kępień

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

[Michał Kępień]

> On Sat, Jun 24, 2017 at 02:25:46AM +0200, Rafael Wysocki wrote:
> > On Wednesday, June 21, 2017 11:15:43 AM Darren Hart wrote:
> > > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote:
> > > > All ACPI device notify callbacks are invoked using acpi_os_execute(),
> > > > which causes the supplied callback to be queued to a static workqueue
> > > > which always executes on CPU 0.  This means that there is no possibility
> > > > for any ACPI device notify callback to be concurrently executed on
> > > > multiple CPUs, which in the case of fujitsu-laptop means that using a
> > > > locked kfifo for handling hotkeys is redundant: as hotkey scancodes are
> > > > only pushed and popped from within acpi_fujitsu_laptop_notify(), no risk
> > > > of concurrent pushing and popping exists.
> > > 
> > > Was the kfifo causing a problem currently or for the migration to separate
> > > modules? Is this purely a simplification?
> > > 
> > > Rafael, the above rationale appears sound to me. Do you have any concerns?
> > 
> > I actually do.
> > 
> > While this is the case today, making the driver code depend on it in a hard 
> > way
> > sort of makes it difficult to change in the future if need be.
> 
> OK, if we aren't guaranteed for this to run on CPU 0 in the future, and this
> will be annoying to debug if it does changes, let's skip the kfifo change.
> 
> I have removed this patch, and fixed up the merge conflicts of the remaining 6
> patches here:
> 
> http://git.infradead.org/linux-platform-drivers-x86.git/shortlog/refs/heads/fujitsu
> 
> Michal / Jonathan, would you please review and let me know if this is what you
> would have done / approve the rebase?

The only issue I can see is that the push/pop debug messages in the last
patch contain the word "buffer" instead of the original "ringbuffer".
The dropped kfifo patch changed the wording from "ringbuffer" to
"buffer" as applying it means there is no ringbuffer any more, but since
it was not applied in the end, I guess the original wording should stay
in place.

The rest looks good to me.

-- 
Best regards,
Michał Kępień

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

[Stephen Rothwell]

Hi jeffy,

On Wed, 28 Jun 2017 12:00:19 +0800 jeffy  wrote:
>
> commit 50816c48997af857d4bab3dca1aba90339705e96
> Author: Ingo Molnar 
> Date:   Sun Mar 5 10:33:16 2017 +0100
> 
>  sched/wait: Standardize internal naming of wait-queue entries
> 
> 
> changed wait_queue_entry_t to struct wait_queue_entry, and also wait to 
> wq_entry, maybe we should do it too?

Sure, but that can be done later.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi jeffy,

On Wed, 28 Jun 2017 12:00:19 +0800 jeffy  wrote:
>
> commit 50816c48997af857d4bab3dca1aba90339705e96
> Author: Ingo Molnar 
> Date:   Sun Mar 5 10:33:16 2017 +0100
> 
>  sched/wait: Standardize internal naming of wait-queue entries
> 
> 
> changed wait_queue_entry_t to struct wait_queue_entry, and also wait to 
> wq_entry, maybe we should do it too?

Sure, but that can be done later.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

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

  drivers/xen/events/events_base.c

between commit:

  ef1c2cc88531 ("xen/events: Add support for effective affinity mask")

from the tip tree and commit:

  c48f64ab4723 ("xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online 
VCPU")

from the xen-tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/xen/events/events_base.c
index 2e567d8433b3,813f1e86a599..
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@@ -1343,12 -1343,8 +1343,12 @@@ static int set_affinity_irq(struct irq_
bool force)
  {
unsigned tcpu = cpumask_first_and(dest, cpu_online_mask);
-   int ret = rebind_irq_to_cpu(data->irq, tcpu);
++  int ret = xen_rebind_evtchn_to_cpu(evtchn_from_irq(data->irq), tcpu);
  
 -  return xen_rebind_evtchn_to_cpu(evtchn_from_irq(data->irq), tcpu);
 +  if (!ret)
 +  irq_data_update_effective_affinity(data, cpumask_of(tcpu));
 +
 +  return ret;
  }
  
  static void enable_dynirq(struct irq_data *data)

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

[Stephen Rothwell]

Hi all,

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

  drivers/xen/events/events_base.c

between commit:

  ef1c2cc88531 ("xen/events: Add support for effective affinity mask")

from the tip tree and commit:

  c48f64ab4723 ("xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online 
VCPU")

from the xen-tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/xen/events/events_base.c
index 2e567d8433b3,813f1e86a599..
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@@ -1343,12 -1343,8 +1343,12 @@@ static int set_affinity_irq(struct irq_
bool force)
  {
unsigned tcpu = cpumask_first_and(dest, cpu_online_mask);
-   int ret = rebind_irq_to_cpu(data->irq, tcpu);
++  int ret = xen_rebind_evtchn_to_cpu(evtchn_from_irq(data->irq), tcpu);
  
 -  return xen_rebind_evtchn_to_cpu(evtchn_from_irq(data->irq), tcpu);
 +  if (!ret)
 +  irq_data_update_effective_affinity(data, cpumask_of(tcpu));
 +
 +  return ret;
  }
  
  static void enable_dynirq(struct irq_data *data)

Re: [PATCH 3/6] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

[Darrick J. Wong]

[add linux-xfs to cc]

FYI this is a discussion of the patch "xfs: map KM_MAYFAIL to
__GFP_RETRY_MAYFAIL" which was last discussed on the xfs list in March
and now is in the -mm tree...

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20170627=43182d82c48fae80d31a9101b6bb06d75cee32c7

On Tue, Jun 27, 2017 at 04:06:54PM +0200, Michal Hocko wrote:
> On Tue 27-06-17 06:47:51, Christoph Hellwig wrote:
> > On Tue, Jun 27, 2017 at 10:49:50AM +0200, Michal Hocko wrote:
> > > Christoph, Darrick
> > > could you have a look at this patch please? Andrew has put it into mmotm
> > > but I definitely do not want it passes your attention.
> > 
> > I don't think what we have to gain from it.  Callsite for KM_MAYFAIL
> > should handler failures, but the current behavior seems to be doing fine
> > too.
> 
> Last time I've asked I didnd't get any reply so let me ask again. Some
> of those allocations seem to be small (e.g. by a random look
> xlog_cil_init allocates struct xfs_cil which is 576B and struct
> xfs_cil_ctx 176B). Those do not fail currently under most conditions and
> it will retry allocation with the OOM killer if there is no progress. As
> you know that failing those is acceptable, wouldn't it be better to
> simply fail them and do not disrupt the system with the oom killer?

I remember the first time I saw this patch, and didn't have much of an
opinion either way -- the current behavior is fine, so why mess around?
I'd just as soon XFS not have to deal with errors if it doesn't have to. :)

But, you've asked again, so I'll be less glib this time.

I took a quick glance at all the MAYFAIL users in XFS.  /Nearly/ all
them seem to be cases either where we're mounting a filesystem or are
collecting memory for some ioctl -- in either case it's not hard to just
fail back out to userspace.  The upcoming online fsck patches use it
heavily, which is fine since we can always fail out to userspace and
tell the admin to go run xfs_repair offline.

The one user that caught my eye was xfs_iflush_cluster, which seems to
want an array of pointers to a cluster's worth of struct xfs_inodes.  On
a 64k block fs with 256 byte pointers I guess that could be ~2k worth of
pointers, but otoh it looks like that's an optimization: If we're going
to flush an inode out to disk we opportunistically scan the inode tree
to see if the adjacent inodes are also ready to flush; if we can't get
the memory for this, then it just backs off to flushing the one inode.

All the callers of MAYFAIL that I found actually /do/ check the return
value and start bailing out... so, uh, I guess I'm fine with it.  At
worst it's easily reverted during -rc if it causes problems.  Anyone
have a stronger objection?

Acked-by: Darrick J. Wong <darrick.w...@oracle.com>

--D

> -- 
> Michal Hocko
> SUSE Labs

Re: [PATCH 3/6] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

[Darrick J. Wong]

[add linux-xfs to cc]

FYI this is a discussion of the patch "xfs: map KM_MAYFAIL to
__GFP_RETRY_MAYFAIL" which was last discussed on the xfs list in March
and now is in the -mm tree...

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20170627=43182d82c48fae80d31a9101b6bb06d75cee32c7

On Tue, Jun 27, 2017 at 04:06:54PM +0200, Michal Hocko wrote:
> On Tue 27-06-17 06:47:51, Christoph Hellwig wrote:
> > On Tue, Jun 27, 2017 at 10:49:50AM +0200, Michal Hocko wrote:
> > > Christoph, Darrick
> > > could you have a look at this patch please? Andrew has put it into mmotm
> > > but I definitely do not want it passes your attention.
> > 
> > I don't think what we have to gain from it.  Callsite for KM_MAYFAIL
> > should handler failures, but the current behavior seems to be doing fine
> > too.
> 
> Last time I've asked I didnd't get any reply so let me ask again. Some
> of those allocations seem to be small (e.g. by a random look
> xlog_cil_init allocates struct xfs_cil which is 576B and struct
> xfs_cil_ctx 176B). Those do not fail currently under most conditions and
> it will retry allocation with the OOM killer if there is no progress. As
> you know that failing those is acceptable, wouldn't it be better to
> simply fail them and do not disrupt the system with the oom killer?

I remember the first time I saw this patch, and didn't have much of an
opinion either way -- the current behavior is fine, so why mess around?
I'd just as soon XFS not have to deal with errors if it doesn't have to. :)

But, you've asked again, so I'll be less glib this time.

I took a quick glance at all the MAYFAIL users in XFS.  /Nearly/ all
them seem to be cases either where we're mounting a filesystem or are
collecting memory for some ioctl -- in either case it's not hard to just
fail back out to userspace.  The upcoming online fsck patches use it
heavily, which is fine since we can always fail out to userspace and
tell the admin to go run xfs_repair offline.

The one user that caught my eye was xfs_iflush_cluster, which seems to
want an array of pointers to a cluster's worth of struct xfs_inodes.  On
a 64k block fs with 256 byte pointers I guess that could be ~2k worth of
pointers, but otoh it looks like that's an optimization: If we're going
to flush an inode out to disk we opportunistically scan the inode tree
to see if the adjacent inodes are also ready to flush; if we can't get
the memory for this, then it just backs off to flushing the one inode.

All the callers of MAYFAIL that I found actually /do/ check the return
value and start bailing out... so, uh, I guess I'm fine with it.  At
worst it's easily reverted during -rc if it causes problems.  Anyone
have a stronger objection?

Acked-by: Darrick J. Wong 

--D

> -- 
> Michal Hocko
> SUSE Labs

Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns

[Viresh Kumar]

On 27-06-17, 18:08, Rafael J. Wysocki wrote:
> On Tue, Jun 27, 2017 at 6:20 AM, Viresh Kumar  wrote:
> > @Rafael: Will it be fine to lower down the value of LATENCY_MULTIPLIER?
> 
> We can do that, but then I think we need to compensate for the change
> in the old governors code or there may be surprises.

Why shouldn't we change the value of LATENCY_MULTIPLIER for old
governors as well? They use the same calculations and the sampling
rate there is also this bad (like rate_limit_us).

If we aren't going to change that for old governors, then we can
create a local version of LATENCY_MULTIPLIER for schedutil I believe.

-- 
viresh

Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns

[Viresh Kumar]

On 27-06-17, 18:08, Rafael J. Wysocki wrote:
> On Tue, Jun 27, 2017 at 6:20 AM, Viresh Kumar  wrote:
> > @Rafael: Will it be fine to lower down the value of LATENCY_MULTIPLIER?
> 
> We can do that, but then I think we need to compensate for the change
> in the old governors code or there may be surprises.

Why shouldn't we change the value of LATENCY_MULTIPLIER for old
governors as well? They use the same calculations and the sampling
rate there is also this bad (like rate_limit_us).

If we aren't going to change that for old governors, then we can
create a local version of LATENCY_MULTIPLIER for schedutil I believe.

-- 
viresh

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

[Finn Thain]

On Tue, 27 Jun 2017, Ondrej Zary wrote:

> On Tuesday 27 June 2017 14:42:29 Finn Thain wrote:
> 
> > > ... it triggers sometimes: the value is 1 instead of 0. As we use 
> > > only 16-bit writes, I don't see how the value could ever be odd. 
> > > Looks like a bug in the chip. The index register corrupts during the 
> > > transfer, not after IRQ or timeout. The same check at beginning of 
> > > pwrite() did not trigger.
> >
> > Are you reading this register at the right moment? Have you tried 
> > waiting for it to reach zero, as in,
> >
> > if (NCR5380_poll_politely(hostdata, 13, 0xff, 0, HZ / 64) < 0)
> > /* printk, reset etc */;
> 
> I have not but will try (expecting that it will not change by itself).
> 

Now that I know that it is the byte at the beginning of the block that 
went missing, I agree that there's no point waiting for the byte count to 
change.

I've included a patch with your 512 B limit in v4.

Thanks.

> > Even if this is a reliable way to detect a short transfer, it would be 
> > nice to know the root cause. But I'm being unrealistic: the DTC436 
> > vendor never responded to my requests for technical documentation.
> 
> According to the data corruption observed, it's not a short transfer. 
> The corruption is always the same: one byte missing at the beginning of 
> a 128 B block. It happens only with slow Quantum LPS 240 drive, not with 
> faster IBM DORS-32160.
> 

-- 

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

[Finn Thain]

On Tue, 27 Jun 2017, Ondrej Zary wrote:

> On Tuesday 27 June 2017 14:42:29 Finn Thain wrote:
> 
> > > ... it triggers sometimes: the value is 1 instead of 0. As we use 
> > > only 16-bit writes, I don't see how the value could ever be odd. 
> > > Looks like a bug in the chip. The index register corrupts during the 
> > > transfer, not after IRQ or timeout. The same check at beginning of 
> > > pwrite() did not trigger.
> >
> > Are you reading this register at the right moment? Have you tried 
> > waiting for it to reach zero, as in,
> >
> > if (NCR5380_poll_politely(hostdata, 13, 0xff, 0, HZ / 64) < 0)
> > /* printk, reset etc */;
> 
> I have not but will try (expecting that it will not change by itself).
> 

Now that I know that it is the byte at the beginning of the block that 
went missing, I agree that there's no point waiting for the byte count to 
change.

I've included a patch with your 512 B limit in v4.

Thanks.

> > Even if this is a reliable way to detect a short transfer, it would be 
> > nice to know the root cause. But I'm being unrealistic: the DTC436 
> > vendor never responded to my requests for technical documentation.
> 
> According to the data corruption observed, it's not a short transfer. 
> The corruption is always the same: one byte missing at the beginning of 
> a 128 B block. It happens only with slow Quantum LPS 240 drive, not with 
> faster IBM DORS-32160.
> 

-- 

[no subject]

[системы администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...776774990..2017
Почты технической поддержки ©2017

спасибо
системы администратор

[no subject]

[системы администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...776774990..2017
Почты технической поддержки ©2017

спасибо
системы администратор

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

[Finn Thain]

On Tue, 27 Jun 2017, Ondrej Zary wrote:

> On Tuesday 27 June 2017 03:49:16 Finn Thain wrote:
> >
> > ... As long as there's no gated IRQ, we poll for buffer readiness 
> > until timeout. And when there is a gated IRQ, we break both the 
> > polling loop and the transfer loop immediately. Your code and mine are 
> > basically in agreement here.
> 
> Yes, it stops transfer when an IRQ arrives. But the host buffer could be 
> ready at the same time. The IRQ can be an "end-of-DMA" IRQ (IIRC DTC 
> chips assert this earlier than 53C400). Or just a disconnect that 
> occured right now but the chip already read a buffer full of data.
> 

The IRQ should not normally arise during the loop. A BASR_END_DMA_TRANSFER 
interrupt could only happen after the loop has finished sending/receiving, 
which is when /EOP becomes active.

The BASR_PHASE_MATCH interrupt could happen during the transfer if the 
target disconnects suddenly.

It is possible that the 53c400 core would assert /EOP upon 
BASR_PHASE_MATCH interrupt, which could then cause the 53c80 to raise a 
BASR_END_DMA_TRANSFER interrupt too. But who knows?

> > > According to my tests, buffer ready signal is most important - if 
> > > there is any data to read/write, do the transfer. If not, only then 
> > > check why - maybe we got an IRQ (that terminated PDMA). Or no IRQ, 
> > > sometimes the wait for buffer ready times out - we need to terminate 
> > > PDMA manually then (reset).
> > >
> > > Then 53C80 registers should become ready.
> >
> > You seem to be saying that we should ignore the IRQ signal if the 
> > buffers have become ready. Maybe so. Can we try simply resetting the 
> > block counter? (I could imagine that the 53c400 core might leave the 
> > 53c80 registers inaccessible unless we keep accessing the buffers in 
> > the 53c400 core until the transfer is done.)
> 
> We can't reset the block counter because 0 means 256 blocks to transfer 
> (page 13 in datasheet).

I forgot about that. How awful.

> Yes, the 53C80 registers seem to become available only when the PDMA 
> transfer ends by either:
> 1. transferring all blocks (block counter decrementing to zero)
> 2. IRQ

I don't think that Gated IRQ is sufficient to make the 53c80 registers 
available again. If it was, you probably wouldn't have seen "switching to 
slow handshake" when you tested my earlier patch series.

> 3. reset
> 

Maybe we need to do the reset whenever IRQ is detected. I'll put this in 
v4. Please try commenting it out, to see what difference that makes.

> > BTW, with regard to your patch, note that this construct is race prone:
> >
> > while (1) { /* monitor IRQ while waiting for host buffer */
> > csr = NCR5380_read(hostdata->c400_ctl_status);
> > if (!(csr & CSR_HOST_BUF_NOT_RDY))
> > break;
> > if (csr & CSR_GATED_53C80_IRQ) {
> > basr = NCR5380_read(BUS_AND_STATUS_REG);
> > if (!(basr & BASR_PHASE_MATCH) ||
> >(basr & BASR_BUSY_ERROR)) {
> > printk("basr=0x%02x csr=0x%02x at start=%d\n", basr, 
> > csr, start);
> > goto out_wait;
> > }
> > }
> > if (retries-- < 1) {
> > shost_printk(KERN_ERR, hostdata->host, "53C400r: host buffer 
> > not ready in
> > time\n"); NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
> > NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
> > goto out_wait;
> > }
> > }
> >
> > This code can "goto out_wait" when !(csr & CSR_HOST_BUF_NOT_RDY). It 
> > depends on timing. This would seem to be contrary to your stated aim.
> >
> > Moreover, this code can also "break" when (csr & CSR_GATED_53C80_IRQ). 
> > That depends on timing too. But this may be an improvement on my code 
> > if it allows the 53c80 registers to become accessible, by allowing the 
> > block counter to be decremented.
> 
> Yes, it continue the transfer even if the IRQ is asserted - as long as 
> the buffer is ready. That's intended.
> 

If we continue to try to send when there is a phase mismatch (i.e. sudden 
disconnection) we'll probably end up with a buffer ready timeout. And we 
may also have trouble calculating the residual correctly.

Hence my version of your patch always breaks out of the transfer loop as 
soon as any Gated IRQ is detected. If that then means a compulsory reset 
of the 53c400 core, I guess I can live with that.

> > The uncertainty here was one of the reasons I reworked this code.
> 
> My version reads CSR only once per loop but that probably does not help 
> at all as the HW state could change anytime. The chip's design seems to 
> be very race-prone.
> 
> > > This is a log from writing 230 MB file using my code with some debug 
> > > prints, on a NCR53C400. No 53C80 timeouts, only disconnects and some 
> > > host buffer timeouts (maybe the drive sometimes just slows down 
> > > without disconnecting?)
> > >
> > > [ 3378.503828] basr=0x10 csr=0xd5 at start=512
> > > [ 3461.257973] w 

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

[Finn Thain]

On Tue, 27 Jun 2017, Ondrej Zary wrote:

> On Tuesday 27 June 2017 03:49:16 Finn Thain wrote:
> >
> > ... As long as there's no gated IRQ, we poll for buffer readiness 
> > until timeout. And when there is a gated IRQ, we break both the 
> > polling loop and the transfer loop immediately. Your code and mine are 
> > basically in agreement here.
> 
> Yes, it stops transfer when an IRQ arrives. But the host buffer could be 
> ready at the same time. The IRQ can be an "end-of-DMA" IRQ (IIRC DTC 
> chips assert this earlier than 53C400). Or just a disconnect that 
> occured right now but the chip already read a buffer full of data.
> 

The IRQ should not normally arise during the loop. A BASR_END_DMA_TRANSFER 
interrupt could only happen after the loop has finished sending/receiving, 
which is when /EOP becomes active.

The BASR_PHASE_MATCH interrupt could happen during the transfer if the 
target disconnects suddenly.

It is possible that the 53c400 core would assert /EOP upon 
BASR_PHASE_MATCH interrupt, which could then cause the 53c80 to raise a 
BASR_END_DMA_TRANSFER interrupt too. But who knows?

> > > According to my tests, buffer ready signal is most important - if 
> > > there is any data to read/write, do the transfer. If not, only then 
> > > check why - maybe we got an IRQ (that terminated PDMA). Or no IRQ, 
> > > sometimes the wait for buffer ready times out - we need to terminate 
> > > PDMA manually then (reset).
> > >
> > > Then 53C80 registers should become ready.
> >
> > You seem to be saying that we should ignore the IRQ signal if the 
> > buffers have become ready. Maybe so. Can we try simply resetting the 
> > block counter? (I could imagine that the 53c400 core might leave the 
> > 53c80 registers inaccessible unless we keep accessing the buffers in 
> > the 53c400 core until the transfer is done.)
> 
> We can't reset the block counter because 0 means 256 blocks to transfer 
> (page 13 in datasheet).

I forgot about that. How awful.

> Yes, the 53C80 registers seem to become available only when the PDMA 
> transfer ends by either:
> 1. transferring all blocks (block counter decrementing to zero)
> 2. IRQ

I don't think that Gated IRQ is sufficient to make the 53c80 registers 
available again. If it was, you probably wouldn't have seen "switching to 
slow handshake" when you tested my earlier patch series.

> 3. reset
> 

Maybe we need to do the reset whenever IRQ is detected. I'll put this in 
v4. Please try commenting it out, to see what difference that makes.

> > BTW, with regard to your patch, note that this construct is race prone:
> >
> > while (1) { /* monitor IRQ while waiting for host buffer */
> > csr = NCR5380_read(hostdata->c400_ctl_status);
> > if (!(csr & CSR_HOST_BUF_NOT_RDY))
> > break;
> > if (csr & CSR_GATED_53C80_IRQ) {
> > basr = NCR5380_read(BUS_AND_STATUS_REG);
> > if (!(basr & BASR_PHASE_MATCH) ||
> >(basr & BASR_BUSY_ERROR)) {
> > printk("basr=0x%02x csr=0x%02x at start=%d\n", basr, 
> > csr, start);
> > goto out_wait;
> > }
> > }
> > if (retries-- < 1) {
> > shost_printk(KERN_ERR, hostdata->host, "53C400r: host buffer 
> > not ready in
> > time\n"); NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
> > NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
> > goto out_wait;
> > }
> > }
> >
> > This code can "goto out_wait" when !(csr & CSR_HOST_BUF_NOT_RDY). It 
> > depends on timing. This would seem to be contrary to your stated aim.
> >
> > Moreover, this code can also "break" when (csr & CSR_GATED_53C80_IRQ). 
> > That depends on timing too. But this may be an improvement on my code 
> > if it allows the 53c80 registers to become accessible, by allowing the 
> > block counter to be decremented.
> 
> Yes, it continue the transfer even if the IRQ is asserted - as long as 
> the buffer is ready. That's intended.
> 

If we continue to try to send when there is a phase mismatch (i.e. sudden 
disconnection) we'll probably end up with a buffer ready timeout. And we 
may also have trouble calculating the residual correctly.

Hence my version of your patch always breaks out of the transfer loop as 
soon as any Gated IRQ is detected. If that then means a compulsory reset 
of the 53c400 core, I guess I can live with that.

> > The uncertainty here was one of the reasons I reworked this code.
> 
> My version reads CSR only once per loop but that probably does not help 
> at all as the HW state could change anytime. The chip's design seems to 
> be very race-prone.
> 
> > > This is a log from writing 230 MB file using my code with some debug 
> > > prints, on a NCR53C400. No 53C80 timeouts, only disconnects and some 
> > > host buffer timeouts (maybe the drive sometimes just slows down 
> > > without disconnecting?)
> > >
> > > [ 3378.503828] basr=0x10 csr=0xd5 at start=512
> > > [ 3461.257973] w 

[PATCH v4 2/5] g_NCR5380: End PDMA transfer correctly on target disconnection

[Finn Thain]

From: Ondrej Zary 

When an IRQ arrives during PDMA transfer, pread() and pwrite() return
without waiting for the 53C80 registers to be ready and this ends up
messing up the chip state. This was observed with SONY CDU-55S which is
slow enough to disconnect during 4096-byte reads.

IRQ during PDMA is not an error so don't return -1. Instead, store the
remaining byte count for use by NCR5380_dma_residual().

[Poll for the BASR_END_DMA_TRANSFER condition rather than remove the
error message -- F.T.]

Signed-off-by: Ondrej Zary 
Signed-off-by: Finn Thain 
---
 drivers/scsi/g_NCR5380.c | 48 +++-
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 14ef4e8c4713..911a4300ea51 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -44,12 +44,13 @@
int c400_ctl_status; \
int c400_blk_cnt; \
int c400_host_buf; \
-   int io_width
+   int io_width; \
+   int pdma_residual
 
 #define NCR5380_dma_xfer_lengeneric_NCR5380_dma_xfer_len
 #define NCR5380_dma_recv_setup  generic_NCR5380_pread
 #define NCR5380_dma_send_setup  generic_NCR5380_pwrite
-#define NCR5380_dma_residualNCR5380_dma_residual_none
+#define NCR5380_dma_residualgeneric_NCR5380_dma_residual
 
 #define NCR5380_intrgeneric_NCR5380_intr
 #define NCR5380_queue_command   generic_NCR5380_queue_command
@@ -500,10 +501,8 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
while (1) {
if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
break;
-   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ) {
-   printk(KERN_ERR "53C400r: Got 53C80_IRQ start=%d, 
blocks=%d\n", start, blocks);
-   return -1;
-   }
+   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ)
+   goto out_wait;
while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
; /* FIXME - no timeout */
 
@@ -542,13 +541,19 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
printk("53C400r: no 53C80 gated irq after transfer");
 
+out_wait:
+   hostdata->pdma_residual = len - start;
+
/* wait for 53C80 registers to be available */
while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
;
 
-   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
-   printk(KERN_ERR "53C400r: no end dma signal\n");
-   
+   if (NCR5380_poll_politely(hostdata, BUS_AND_STATUS_REG,
+ BASR_END_DMA_TRANSFER, BASR_END_DMA_TRANSFER,
+ HZ / 64) < 0)
+   scmd_printk(KERN_ERR, hostdata->connected, "%s: End of DMA 
timeout (%d)\n",
+   __func__, hostdata->pdma_residual);
+
return 0;
 }
 
@@ -571,10 +576,8 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
NCR5380_write(hostdata->c400_blk_cnt, blocks);
while (1) {
-   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ) {
-   printk(KERN_ERR "53C400w: Got 53C80_IRQ start=%d, 
blocks=%d\n", start, blocks);
-   return -1;
-   }
+   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ)
+   goto out_wait;
 
if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
break;
@@ -612,18 +615,24 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
blocks--;
}
 
+out_wait:
+   hostdata->pdma_residual = len - start;
+
/* wait for 53C80 registers to be available */
while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)) {
udelay(4); /* DTC436 chip hangs without this */
/* FIXME - no timeout */
}
 
-   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER)) {
-   printk(KERN_ERR "53C400w: no end dma signal\n");
-   }
-
while (!(NCR5380_read(TARGET_COMMAND_REG) & TCR_LAST_BYTE_SENT))
;   // TIMEOUT
+
+   if (NCR5380_poll_politely(hostdata, BUS_AND_STATUS_REG,
+ BASR_END_DMA_TRANSFER, BASR_END_DMA_TRANSFER,
+ HZ / 64) < 0)
+   scmd_printk(KERN_ERR, hostdata->connected, "%s: End of DMA 
timeout (%d)\n",
+

[PATCH v4 4/5] g_NCR5380: Limit PDMA send to 512 B to avoid random corruption on DTC3181E

[Finn Thain]

From: Ondrej Zary 

The corruption is always the same: one byte missing at the beginning of
a 128 B block. It happens only with slow Quantum LPS 240 drive, not with
faster IBM DORS-32160. It's not clear what causes this. Documentation
for the DTC436 chip has not been made available. Hence this workaround.

Signed-off-by: Finn Thain 
---
 drivers/scsi/g_NCR5380.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 9f18082415c4..b1e0a08e49c1 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -45,7 +45,8 @@
int c400_blk_cnt; \
int c400_host_buf; \
int io_width; \
-   int pdma_residual
+   int pdma_residual; \
+   int board
 
 #define NCR5380_dma_xfer_lengeneric_NCR5380_dma_xfer_len
 #define NCR5380_dma_recv_setup  generic_NCR5380_pread
@@ -316,6 +317,7 @@ static int generic_NCR5380_init_one(struct 
scsi_host_template *tpnt,
}
hostdata = shost_priv(instance);
 
+   hostdata->board = board;
hostdata->io = iomem;
hostdata->region_size = region_size;
 
@@ -644,7 +646,12 @@ static int generic_NCR5380_dma_xfer_len(struct 
NCR5380_hostdata *hostdata,
 
/* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
if (transfersize % 128)
-   transfersize = 0;
+   return 0;
+
+   /* Limit PDMA send to 512 B to avoid random corruption on DTC3181E */
+   if (hostdata->board == BOARD_DTC3181E &&
+   cmd->sc_data_direction == DMA_TO_DEVICE)
+   transfersize = min(cmd->SCp.this_residual, 512);
 
return min(transfersize, DMA_MAX_SIZE);
 }
-- 
2.13.0

[PATCH v4 2/5] g_NCR5380: End PDMA transfer correctly on target disconnection

[Finn Thain]

From: Ondrej Zary 

When an IRQ arrives during PDMA transfer, pread() and pwrite() return
without waiting for the 53C80 registers to be ready and this ends up
messing up the chip state. This was observed with SONY CDU-55S which is
slow enough to disconnect during 4096-byte reads.

IRQ during PDMA is not an error so don't return -1. Instead, store the
remaining byte count for use by NCR5380_dma_residual().

[Poll for the BASR_END_DMA_TRANSFER condition rather than remove the
error message -- F.T.]

Signed-off-by: Ondrej Zary 
Signed-off-by: Finn Thain 
---
 drivers/scsi/g_NCR5380.c | 48 +++-
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 14ef4e8c4713..911a4300ea51 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -44,12 +44,13 @@
int c400_ctl_status; \
int c400_blk_cnt; \
int c400_host_buf; \
-   int io_width
+   int io_width; \
+   int pdma_residual
 
 #define NCR5380_dma_xfer_lengeneric_NCR5380_dma_xfer_len
 #define NCR5380_dma_recv_setup  generic_NCR5380_pread
 #define NCR5380_dma_send_setup  generic_NCR5380_pwrite
-#define NCR5380_dma_residualNCR5380_dma_residual_none
+#define NCR5380_dma_residualgeneric_NCR5380_dma_residual
 
 #define NCR5380_intrgeneric_NCR5380_intr
 #define NCR5380_queue_command   generic_NCR5380_queue_command
@@ -500,10 +501,8 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
while (1) {
if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
break;
-   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ) {
-   printk(KERN_ERR "53C400r: Got 53C80_IRQ start=%d, 
blocks=%d\n", start, blocks);
-   return -1;
-   }
+   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ)
+   goto out_wait;
while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
; /* FIXME - no timeout */
 
@@ -542,13 +541,19 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
printk("53C400r: no 53C80 gated irq after transfer");
 
+out_wait:
+   hostdata->pdma_residual = len - start;
+
/* wait for 53C80 registers to be available */
while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
;
 
-   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
-   printk(KERN_ERR "53C400r: no end dma signal\n");
-   
+   if (NCR5380_poll_politely(hostdata, BUS_AND_STATUS_REG,
+ BASR_END_DMA_TRANSFER, BASR_END_DMA_TRANSFER,
+ HZ / 64) < 0)
+   scmd_printk(KERN_ERR, hostdata->connected, "%s: End of DMA 
timeout (%d)\n",
+   __func__, hostdata->pdma_residual);
+
return 0;
 }
 
@@ -571,10 +576,8 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
NCR5380_write(hostdata->c400_blk_cnt, blocks);
while (1) {
-   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ) {
-   printk(KERN_ERR "53C400w: Got 53C80_IRQ start=%d, 
blocks=%d\n", start, blocks);
-   return -1;
-   }
+   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ)
+   goto out_wait;
 
if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
break;
@@ -612,18 +615,24 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
blocks--;
}
 
+out_wait:
+   hostdata->pdma_residual = len - start;
+
/* wait for 53C80 registers to be available */
while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)) {
udelay(4); /* DTC436 chip hangs without this */
/* FIXME - no timeout */
}
 
-   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER)) {
-   printk(KERN_ERR "53C400w: no end dma signal\n");
-   }
-
while (!(NCR5380_read(TARGET_COMMAND_REG) & TCR_LAST_BYTE_SENT))
;   // TIMEOUT
+
+   if (NCR5380_poll_politely(hostdata, BUS_AND_STATUS_REG,
+ BASR_END_DMA_TRANSFER, BASR_END_DMA_TRANSFER,
+ HZ / 64) < 0)
+   scmd_printk(KERN_ERR, hostdata->connected, "%s: End of DMA 
timeout (%d)\n",
+   __func__, hostdata->pdma_residual);
+
return 0;
 }
 
@@ 

[PATCH v4 4/5] g_NCR5380: Limit PDMA send to 512 B to avoid random corruption on DTC3181E

[Finn Thain]

From: Ondrej Zary 

The corruption is always the same: one byte missing at the beginning of
a 128 B block. It happens only with slow Quantum LPS 240 drive, not with
faster IBM DORS-32160. It's not clear what causes this. Documentation
for the DTC436 chip has not been made available. Hence this workaround.

Signed-off-by: Finn Thain 
---
 drivers/scsi/g_NCR5380.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 9f18082415c4..b1e0a08e49c1 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -45,7 +45,8 @@
int c400_blk_cnt; \
int c400_host_buf; \
int io_width; \
-   int pdma_residual
+   int pdma_residual; \
+   int board
 
 #define NCR5380_dma_xfer_lengeneric_NCR5380_dma_xfer_len
 #define NCR5380_dma_recv_setup  generic_NCR5380_pread
@@ -316,6 +317,7 @@ static int generic_NCR5380_init_one(struct 
scsi_host_template *tpnt,
}
hostdata = shost_priv(instance);
 
+   hostdata->board = board;
hostdata->io = iomem;
hostdata->region_size = region_size;
 
@@ -644,7 +646,12 @@ static int generic_NCR5380_dma_xfer_len(struct 
NCR5380_hostdata *hostdata,
 
/* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
if (transfersize % 128)
-   transfersize = 0;
+   return 0;
+
+   /* Limit PDMA send to 512 B to avoid random corruption on DTC3181E */
+   if (hostdata->board == BOARD_DTC3181E &&
+   cmd->sc_data_direction == DMA_TO_DEVICE)
+   transfersize = min(cmd->SCp.this_residual, 512);
 
return min(transfersize, DMA_MAX_SIZE);
 }
-- 
2.13.0

[PATCH v4 5/5] g_NCR5380: Re-work PDMA loops

[Finn Thain]

From: Ondrej Zary 

The polling loops in pread() and pwrite() can easily become infinite
loops and hang the machine.

On DTC chips, IRQ can arrive late and we miss it because we only check
once. Merge the IRQ check into host buffer wait and add polling limit.

Also place a limit on polling for 53C80 registers accessibility.

[Use NCR5380_poll_politely2() for register polling. Rely on polling for
gated IRQ rather than polling for phase error, like the algorithm in the
datasheet. Calculate residual from block count register instead of the
loop counter. Factor-out common code as wait_for_53c80_access(). -- F.T.]

Signed-off-by: Ondrej Zary 
Signed-off-by: Finn Thain 
---
 drivers/scsi/g_NCR5380.c | 147 ++-
 1 file changed, 69 insertions(+), 78 deletions(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index b1e0a08e49c1..a9e050b65d5f 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -482,6 +482,30 @@ static void generic_NCR5380_release_resources(struct 
Scsi_Host *instance)
release_mem_region(base, region_size);
 }
 
+/* wait_for_53c80_access - wait for 53C80 registers to become accessible
+ * @hostdata: scsi host private data
+ *
+ * The registers within the 53C80 logic block are inaccessible until
+ * bit 7 in the 53C400 control status register gets asserted.
+ */
+
+static void wait_for_53c80_access(struct NCR5380_hostdata *hostdata)
+{
+   int count = 1;
+
+   do {
+   if (hostdata->board == BOARD_DTC3181E)
+   udelay(4); /* DTC436 chip hangs without this */
+   if (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)
+   return;
+   } while (--count > 0);
+
+   scmd_printk(KERN_ERR, hostdata->connected,
+   "53c80 registers not accessible, device will be reset\n");
+   NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
+   NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
+}
+
 /**
  * generic_NCR5380_pread - pseudo DMA receive
  * @hostdata: scsi host private data
@@ -494,18 +518,18 @@ static void generic_NCR5380_release_resources(struct 
Scsi_Host *instance)
 static inline int generic_NCR5380_pread(struct NCR5380_hostdata *hostdata,
 unsigned char *dst, int len)
 {
-   int blocks = len / 128;
int start = 0;
 
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE | CSR_TRANS_DIR);
-   NCR5380_write(hostdata->c400_blk_cnt, blocks);
-   while (1) {
-   if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
+   NCR5380_write(hostdata->c400_blk_cnt, len / 128);
+
+   while (start < len) {
+   if (NCR5380_poll_politely2(hostdata, hostdata->c400_ctl_status,
+  CSR_HOST_BUF_NOT_RDY, 0,
+  hostdata->c400_ctl_status,
+  CSR_GATED_53C80_IRQ,
+  CSR_GATED_53C80_IRQ, HZ / 64) < 0)
break;
-   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ)
-   goto out_wait;
-   while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
-   ; /* FIXME - no timeout */
 
if (hostdata->io_port && hostdata->io_width == 2)
insw(hostdata->io_port + hostdata->c400_host_buf,
@@ -518,38 +542,19 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
hostdata->io + NCR53C400_host_buffer, 128);
 
start += 128;
-   blocks--;
}
 
-   if (blocks) {
-   while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
-   ; /* FIXME - no timeout */
-
-   if (hostdata->io_port && hostdata->io_width == 2)
-   insw(hostdata->io_port + hostdata->c400_host_buf,
-   dst + start, 64);
-   else if (hostdata->io_port)
-   insb(hostdata->io_port + hostdata->c400_host_buf,
-   dst + start, 128);
-   else
-   memcpy_fromio(dst + start,
-   hostdata->io + NCR53C400_host_buffer, 128);
-
-   start += 128;
-   blocks--;
-   }
-
-   if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
-   printk("53C400r: no 53C80 gated irq after transfer");
-
-out_wait:
-   hostdata->pdma_residual = len - start;
+   hostdata->pdma_residual = NCR5380_read(hostdata->c400_blk_cnt) * 128;
 
-   /* wait for 53C80 registers to be available */
-   while 

[PATCH v4 1/5] g_NCR5380: Fix PDMA transfer size

[Finn Thain]

From: Ondrej Zary 

generic_NCR5380_dma_xfer_len() incorrectly uses cmd->transfersize
which causes rescan-scsi-bus and CD-ROM access to hang the system.
Use cmd->SCp.this_residual instead, like other NCR5380 drivers.

Signed-off-by: Ondrej Zary 
Signed-off-by: Finn Thain 
---
 drivers/scsi/g_NCR5380.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 67c8dac321ad..14ef4e8c4713 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -76,6 +76,7 @@
 #define IRQ_AUTO 254
 
 #define MAX_CARDS 8
+#define DMA_MAX_SIZE 32768
 
 /* old-style parameters for compatibility */
 static int ncr_irq = -1;
@@ -629,23 +630,16 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
 static int generic_NCR5380_dma_xfer_len(struct NCR5380_hostdata *hostdata,
 struct scsi_cmnd *cmd)
 {
-   int transfersize = cmd->transfersize;
+   int transfersize = cmd->SCp.this_residual;
 
if (hostdata->flags & FLAG_NO_PSEUDO_DMA)
return 0;
 
-   /* Limit transfers to 32K, for xx400 & xx406
-* pseudoDMA that transfers in 128 bytes blocks.
-*/
-   if (transfersize > 32 * 1024 && cmd->SCp.this_residual &&
-   !(cmd->SCp.this_residual % transfersize))
-   transfersize = 32 * 1024;
-
/* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
if (transfersize % 128)
transfersize = 0;
 
-   return transfersize;
+   return min(transfersize, DMA_MAX_SIZE);
 }
 
 /*
-- 
2.13.0

[PATCH v4 5/5] g_NCR5380: Re-work PDMA loops

[Finn Thain]

From: Ondrej Zary 

The polling loops in pread() and pwrite() can easily become infinite
loops and hang the machine.

On DTC chips, IRQ can arrive late and we miss it because we only check
once. Merge the IRQ check into host buffer wait and add polling limit.

Also place a limit on polling for 53C80 registers accessibility.

[Use NCR5380_poll_politely2() for register polling. Rely on polling for
gated IRQ rather than polling for phase error, like the algorithm in the
datasheet. Calculate residual from block count register instead of the
loop counter. Factor-out common code as wait_for_53c80_access(). -- F.T.]

Signed-off-by: Ondrej Zary 
Signed-off-by: Finn Thain 
---
 drivers/scsi/g_NCR5380.c | 147 ++-
 1 file changed, 69 insertions(+), 78 deletions(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index b1e0a08e49c1..a9e050b65d5f 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -482,6 +482,30 @@ static void generic_NCR5380_release_resources(struct 
Scsi_Host *instance)
release_mem_region(base, region_size);
 }
 
+/* wait_for_53c80_access - wait for 53C80 registers to become accessible
+ * @hostdata: scsi host private data
+ *
+ * The registers within the 53C80 logic block are inaccessible until
+ * bit 7 in the 53C400 control status register gets asserted.
+ */
+
+static void wait_for_53c80_access(struct NCR5380_hostdata *hostdata)
+{
+   int count = 1;
+
+   do {
+   if (hostdata->board == BOARD_DTC3181E)
+   udelay(4); /* DTC436 chip hangs without this */
+   if (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)
+   return;
+   } while (--count > 0);
+
+   scmd_printk(KERN_ERR, hostdata->connected,
+   "53c80 registers not accessible, device will be reset\n");
+   NCR5380_write(hostdata->c400_ctl_status, CSR_RESET);
+   NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
+}
+
 /**
  * generic_NCR5380_pread - pseudo DMA receive
  * @hostdata: scsi host private data
@@ -494,18 +518,18 @@ static void generic_NCR5380_release_resources(struct 
Scsi_Host *instance)
 static inline int generic_NCR5380_pread(struct NCR5380_hostdata *hostdata,
 unsigned char *dst, int len)
 {
-   int blocks = len / 128;
int start = 0;
 
NCR5380_write(hostdata->c400_ctl_status, CSR_BASE | CSR_TRANS_DIR);
-   NCR5380_write(hostdata->c400_blk_cnt, blocks);
-   while (1) {
-   if (NCR5380_read(hostdata->c400_blk_cnt) == 0)
+   NCR5380_write(hostdata->c400_blk_cnt, len / 128);
+
+   while (start < len) {
+   if (NCR5380_poll_politely2(hostdata, hostdata->c400_ctl_status,
+  CSR_HOST_BUF_NOT_RDY, 0,
+  hostdata->c400_ctl_status,
+  CSR_GATED_53C80_IRQ,
+  CSR_GATED_53C80_IRQ, HZ / 64) < 0)
break;
-   if (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_GATED_53C80_IRQ)
-   goto out_wait;
-   while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
-   ; /* FIXME - no timeout */
 
if (hostdata->io_port && hostdata->io_width == 2)
insw(hostdata->io_port + hostdata->c400_host_buf,
@@ -518,38 +542,19 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
hostdata->io + NCR53C400_host_buffer, 128);
 
start += 128;
-   blocks--;
}
 
-   if (blocks) {
-   while (NCR5380_read(hostdata->c400_ctl_status) & 
CSR_HOST_BUF_NOT_RDY)
-   ; /* FIXME - no timeout */
-
-   if (hostdata->io_port && hostdata->io_width == 2)
-   insw(hostdata->io_port + hostdata->c400_host_buf,
-   dst + start, 64);
-   else if (hostdata->io_port)
-   insb(hostdata->io_port + hostdata->c400_host_buf,
-   dst + start, 128);
-   else
-   memcpy_fromio(dst + start,
-   hostdata->io + NCR53C400_host_buffer, 128);
-
-   start += 128;
-   blocks--;
-   }
-
-   if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
-   printk("53C400r: no 53C80 gated irq after transfer");
-
-out_wait:
-   hostdata->pdma_residual = len - start;
+   hostdata->pdma_residual = NCR5380_read(hostdata->c400_blk_cnt) * 128;
 
-   /* wait for 53C80 registers to be available */
-   while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
-   ;
+   if 

[PATCH v4 1/5] g_NCR5380: Fix PDMA transfer size

[Finn Thain]

From: Ondrej Zary 

generic_NCR5380_dma_xfer_len() incorrectly uses cmd->transfersize
which causes rescan-scsi-bus and CD-ROM access to hang the system.
Use cmd->SCp.this_residual instead, like other NCR5380 drivers.

Signed-off-by: Ondrej Zary 
Signed-off-by: Finn Thain 
---
 drivers/scsi/g_NCR5380.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 67c8dac321ad..14ef4e8c4713 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -76,6 +76,7 @@
 #define IRQ_AUTO 254
 
 #define MAX_CARDS 8
+#define DMA_MAX_SIZE 32768
 
 /* old-style parameters for compatibility */
 static int ncr_irq = -1;
@@ -629,23 +630,16 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
 static int generic_NCR5380_dma_xfer_len(struct NCR5380_hostdata *hostdata,
 struct scsi_cmnd *cmd)
 {
-   int transfersize = cmd->transfersize;
+   int transfersize = cmd->SCp.this_residual;
 
if (hostdata->flags & FLAG_NO_PSEUDO_DMA)
return 0;
 
-   /* Limit transfers to 32K, for xx400 & xx406
-* pseudoDMA that transfers in 128 bytes blocks.
-*/
-   if (transfersize > 32 * 1024 && cmd->SCp.this_residual &&
-   !(cmd->SCp.this_residual % transfersize))
-   transfersize = 32 * 1024;
-
/* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */
if (transfersize % 128)
transfersize = 0;
 
-   return transfersize;
+   return min(transfersize, DMA_MAX_SIZE);
 }
 
 /*
-- 
2.13.0

[PATCH v4 0/5] g_NCR5380: PDMA fixes and cleanup

[Finn Thain]

Ondrej, would you please test this new series?

Changed since v1:
- PDMA transfer residual is calculated earlier.
- End of DMA flag check is now polled (if there is any residual).

Changed since v2:
- Bail out of transfer loops when Gated IRQ gets asserted.
- Make udelay conditional on board type.
- Drop sg_tablesize patch due to performance regression.

Changed since v3:
- Add Ondrej's workaround for corrupt WRITE commands on DTC boards.
- Reset the 53c400 logic after any short PDMA transfer.
- Don't fail the transfer if the 53c400 logic got a reset.


Finn Thain (1):
  g_NCR5380: Cleanup comments and whitespace

Ondrej Zary (4):
  g_NCR5380: Fix PDMA transfer size
  g_NCR5380: End PDMA transfer correctly on target disconnection
  g_NCR5380: Limit PDMA send to 512 B to avoid random corruption on
DTC3181E
  g_NCR5380: Re-work PDMA loops

 drivers/scsi/g_NCR5380.c | 239 ---
 1 file changed, 120 insertions(+), 119 deletions(-)

-- 
2.13.0

[PATCH v4 0/5] g_NCR5380: PDMA fixes and cleanup

[Finn Thain]

Ondrej, would you please test this new series?

Changed since v1:
- PDMA transfer residual is calculated earlier.
- End of DMA flag check is now polled (if there is any residual).

Changed since v2:
- Bail out of transfer loops when Gated IRQ gets asserted.
- Make udelay conditional on board type.
- Drop sg_tablesize patch due to performance regression.

Changed since v3:
- Add Ondrej's workaround for corrupt WRITE commands on DTC boards.
- Reset the 53c400 logic after any short PDMA transfer.
- Don't fail the transfer if the 53c400 logic got a reset.


Finn Thain (1):
  g_NCR5380: Cleanup comments and whitespace

Ondrej Zary (4):
  g_NCR5380: Fix PDMA transfer size
  g_NCR5380: End PDMA transfer correctly on target disconnection
  g_NCR5380: Limit PDMA send to 512 B to avoid random corruption on
DTC3181E
  g_NCR5380: Re-work PDMA loops

 drivers/scsi/g_NCR5380.c | 239 ---
 1 file changed, 120 insertions(+), 119 deletions(-)

-- 
2.13.0