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

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

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

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

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

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

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

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

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

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,

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

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,

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

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:

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

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 |

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

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

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

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

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

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

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

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

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

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 *

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

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,

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

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 > he

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

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 +++

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

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 +++

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [PATCH] cifs: hide unused functions

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

Re: [PATCH] cifs: hide unused functions

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

> > > > 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. >

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

> > > > 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. >

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

[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=nex

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

[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=nex

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

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

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

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

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

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

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

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

[no subject]

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

[no subject]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

  1   2   3   4   5   6   7   8   9   10   >