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

On 2017/6/29 12:29, h...@zytor.com wrote: > On June 28, 2017 7:12:04 PM PDT, zhong jiang wrote: >> On 2017/6/29 5:43, h...@zytor.com wrote: >>> On June 27, 2017 9:35:10 PM PDT, zhong jiang >> wrote: Hi, Ingo Thank you for the comment.

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

On 2017/6/29 12:29, h...@zytor.com wrote: > On June 28, 2017 7:12:04 PM PDT, zhong jiang wrote: >> On 2017/6/29 5:43, h...@zytor.com wrote: >>> On June 27, 2017 9:35:10 PM PDT, zhong jiang >> wrote: Hi, Ingo Thank you for the comment. On 2017/6/22 0:40, Ingo Molnar wrote:

[PATCH] net: freescale: gianfar : constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 19057 392 0 194494bf9

[PATCH] net: freescale: gianfar : constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 19057 392 0 194494bf9

Re: [PATCH] thermal/intel_powerclamp: add const to thermal_cooling_device_ops structure

On Thu, Jun 29, 2017 at 11:02 AM, Zhang Rui wrote: > On Thu, 2017-06-29 at 10:41 +0530, Bhumika Goyal wrote: >> On Thu, Jun 29, 2017 at 8:30 AM, Zhang Rui >> wrote: >> > >> > On Wed, 2017-06-21 at 12:39 +0530, Bhumika Goyal wrote: >> > > >> > > Declare

Re: [PATCH] thermal/intel_powerclamp: add const to thermal_cooling_device_ops structure

On Thu, Jun 29, 2017 at 11:02 AM, Zhang Rui wrote: > On Thu, 2017-06-29 at 10:41 +0530, Bhumika Goyal wrote: >> On Thu, Jun 29, 2017 at 8:30 AM, Zhang Rui >> wrote: >> > >> > On Wed, 2017-06-21 at 12:39 +0530, Bhumika Goyal wrote: >> > > >> > > Declare thermal_cooling_device_ops structure as

[PATCH] net: smc91x: constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 18709 401 0 191104aa6

Re: [PATCH v1] xen/input: add multi-touch support

ping On 06/23/2017 09:09 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Extend xen_kbdfront to provide multi-touch support to unprivileged domains. Signed-off-by: Oleksandr Andrushchenko --- Changes since

Re: [PATCH v1] xen/input: add multi-touch support

ping On 06/23/2017 09:09 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Extend xen_kbdfront to provide multi-touch support to unprivileged domains. Signed-off-by: Oleksandr Andrushchenko --- Changes since initial: - use input_set_capability instead of setting flags

[PATCH] net: smc91x: constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 18709 401 0 191104aa6

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

ping On 2017/6/22 20:15, Ding Tianhong wrote: > Some devices have problems with Transaction Layer Packets with the Relaxed > Ordering Attribute set. This patch set adds a new PCIe Device Flag, > PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known > devices with Relaxed

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

ping On 2017/6/22 20:15, Ding Tianhong wrote: > Some devices have problems with Transaction Layer Packets with the Relaxed > Ordering Attribute set. This patch set adds a new PCIe Device Flag, > PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known > devices with Relaxed

[PATCH] net: ibm: ibmveth: constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 154261256 0 16682412a

[PATCH] net: ibm: ibmveth: constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 154261256 0 16682412a

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

Hi Alexandre, After merging the rtc tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: drivers/rtc/rtc-brcmstb-waketimer.c: In function 'brcmstb_waketmr_settime': drivers/rtc/rtc-brcmstb-waketimer.c:142:6: warning: unused variable 'ret' [-Wunused-variable] int ret;

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

Hi Alexandre, After merging the rtc tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: drivers/rtc/rtc-brcmstb-waketimer.c: In function 'brcmstb_waketmr_settime': drivers/rtc/rtc-brcmstb-waketimer.c:142:6: warning: unused variable 'ret' [-Wunused-variable] int ret;

Re: [PATCH] ib_isert: prevent NULL pointer dereference in isert_login_recv_done()

Just tested this patch, I wasn't able to reproduce the NULL pointer dereference or any other bugs, so this fix seems safe enough to me. Tested-by: Andrea Righi Can you test just the one liner fix below? @@ -1452,7 +1452,7 @@ isert_login_recv_done(struct ib_cq

Re: [PATCH] ib_isert: prevent NULL pointer dereference in isert_login_recv_done()

Just tested this patch, I wasn't able to reproduce the NULL pointer dereference or any other bugs, so this fix seems safe enough to me. Tested-by: Andrea Righi Can you test just the one liner fix below? @@ -1452,7 +1452,7 @@ isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc) {

linux-next: manual merge of the kspp tree with the file-locks tree

Hi Kees, Today's linux-next merge of the kspp tree got a conflict in: include/linux/fs.h between commit: 1844a66c1c89 ("fs: new infrastructure for writeback error handling and reporting") from the file-locks tree and commit: 3abc2b3fcf5c ("randstruct: Mark various structs for

linux-next: manual merge of the kspp tree with the file-locks tree

Hi Kees, Today's linux-next merge of the kspp tree got a conflict in: include/linux/fs.h between commit: 1844a66c1c89 ("fs: new infrastructure for writeback error handling and reporting") from the file-locks tree and commit: 3abc2b3fcf5c ("randstruct: Mark various structs for

Re: [PATCH] thermal/intel_powerclamp: add const to thermal_cooling_device_ops structure

On Thu, 2017-06-29 at 10:41 +0530, Bhumika Goyal wrote: > On Thu, Jun 29, 2017 at 8:30 AM, Zhang Rui > wrote: > > > > On Wed, 2017-06-21 at 12:39 +0530, Bhumika Goyal wrote: > > > > > > Declare thermal_cooling_device_ops structure as const as it is > > > only > > > passed >

Re: [PATCH] thermal/intel_powerclamp: add const to thermal_cooling_device_ops structure

On Thu, 2017-06-29 at 10:41 +0530, Bhumika Goyal wrote: > On Thu, Jun 29, 2017 at 8:30 AM, Zhang Rui > wrote: > > > > On Wed, 2017-06-21 at 12:39 +0530, Bhumika Goyal wrote: > > > > > > Declare thermal_cooling_device_ops structure as const as it is > > > only > > > passed > > > as an argument

[PATCH] usb: dwc3: pci: constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2707 456 03163 c5b

[PATCH] usb: dwc3: pci: constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2707 456 03163 c5b

[PATCH V2 3/4] intel_pstate: Ignore scheduler cpufreq callbacks on remote CPUs

From: Steve Muckle In preparation for the scheduler cpufreq callback happening on remote CPUs, check for this case in intel_pstate which currently requires the callback run on the local CPU. Such callbacks are ignored for now. Signed-off-by: Steve Muckle

[PATCH V2 1/4] cpufreq: schedutil: Process remote callback for shared policies

This patch updates the schedutil governor to process cpufreq utilization update hooks called for remote CPUs (i.e. For updates to the runqueue of other non-local CPUs). For now, we only support remote callbacks for CPUs which share their cpufreq policy with the local CPU. It may not be worth

[PATCH V2 1/4] cpufreq: schedutil: Process remote callback for shared policies

This patch updates the schedutil governor to process cpufreq utilization update hooks called for remote CPUs (i.e. For updates to the runqueue of other non-local CPUs). For now, we only support remote callbacks for CPUs which share their cpufreq policy with the local CPU. It may not be worth

[PATCH V2 3/4] intel_pstate: Ignore scheduler cpufreq callbacks on remote CPUs

From: Steve Muckle In preparation for the scheduler cpufreq callback happening on remote CPUs, check for this case in intel_pstate which currently requires the callback run on the local CPU. Such callbacks are ignored for now. Signed-off-by: Steve Muckle Signed-off-by: Viresh Kumar ---

[PATCH V2 2/4] cpufreq: governor: Process remote callback for shared policies

This patch updates the legacy governors (ondemand/conservative) to process cpufreq utilization update hooks to be called for remote CPUs (i.e. For updates to the runqueue of other non-local CPUs). Based on initial work from Steve Muckle. Signed-off-by: Viresh Kumar ---

[PATCH V2 4/4] sched: cpufreq: Enable remote sched cpufreq callbacks

Now that all clients properly support (or ignore) remote scheduler cpufreq callbacks, remove the restriction that such callbacks only be made on the local CPU. Also remove cpufreq_update_this_cpu() as all its users are migrated to use cpufreq_update_util() instead. Based on initial work from

[PATCH V2 2/4] cpufreq: governor: Process remote callback for shared policies

This patch updates the legacy governors (ondemand/conservative) to process cpufreq utilization update hooks to be called for remote CPUs (i.e. For updates to the runqueue of other non-local CPUs). Based on initial work from Steve Muckle. Signed-off-by: Viresh Kumar ---

[PATCH V2 4/4] sched: cpufreq: Enable remote sched cpufreq callbacks

Now that all clients properly support (or ignore) remote scheduler cpufreq callbacks, remove the restriction that such callbacks only be made on the local CPU. Also remove cpufreq_update_this_cpu() as all its users are migrated to use cpufreq_update_util() instead. Based on initial work from

[PATCH V2 0/4] sched: cpufreq: Allow remote callbacks

Hi, Here is the second version of this series. The first [1] version was sent several months back. With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into schedutil are only made from the scheduler if the

[PATCH V2 0/4] sched: cpufreq: Allow remote callbacks

Hi, Here is the second version of this series. The first [1] version was sent several months back. With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into schedutil are only made from the scheduler if the

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

On Wed, 28 Jun 2017, Ondrej Zary wrote: > > Now read seems to work on non-DTC chips. Writes continue in PDMA after > disconnect but there's a corruption - one 128 B block missing on > disconnect. > > On DTC, the log is spammed with errors like this: > sd 2:0:1:0: [sdb] tag#0

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

On Wed, 28 Jun 2017, Ondrej Zary wrote: > > Now read seems to work on non-DTC chips. Writes continue in PDMA after > disconnect but there's a corruption - one 128 B block missing on > disconnect. > > On DTC, the log is spammed with errors like this: > sd 2:0:1:0: [sdb] tag#0

[PATCH v5 6/6] g_NCR5380: Use unambiguous terminology for PDMA send and receive

The word "read" may be used to mean "DMA read operation" or "SCSI READ command", though a READ command implies writing to memory. Signed-off-by: Finn Thain --- drivers/scsi/g_NCR5380.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH v5 6/6] g_NCR5380: Use unambiguous terminology for PDMA send and receive

The word "read" may be used to mean "DMA read operation" or "SCSI READ command", though a READ command implies writing to memory. Signed-off-by: Finn Thain --- drivers/scsi/g_NCR5380.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/g_NCR5380.c

[linux-next][PATCH] usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys

commit f54edb539c116 ("usb: dwc3: core: initialize ULPI before trying to get the PHY") moved call to dwc3_core_get_phy() from dwc3_probe() to dwc3_core_init() after dwc3_core_soft_reset(). But dwc3_core_soft_reset() calls phy_init(), therefore dwc3_core_get_phy() needs to be called before

[linux-next][PATCH] usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys

commit f54edb539c116 ("usb: dwc3: core: initialize ULPI before trying to get the PHY") moved call to dwc3_core_get_phy() from dwc3_probe() to dwc3_core_init() after dwc3_core_soft_reset(). But dwc3_core_soft_reset() calls phy_init(), therefore dwc3_core_get_phy() needs to be called before

[PATCH v5 2/6] 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 v5 2/6] 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 v5 1/6] 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 v5 3/6] g_NCR5380: Cleanup comments and whitespace

Signed-off-by: Finn Thain --- drivers/scsi/g_NCR5380.c | 61 ++-- 1 file changed, 28 insertions(+), 33 deletions(-) diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c index 911a4300ea51..dedaed2d16e4 100644

[PATCH v5 4/6] g_NCR5380: Limit PDMA send to 512 B to avoid data 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 v5 1/6] 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 v5 3/6] g_NCR5380: Cleanup comments and whitespace

Signed-off-by: Finn Thain --- drivers/scsi/g_NCR5380.c | 61 ++-- 1 file changed, 28 insertions(+), 33 deletions(-) diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c index 911a4300ea51..dedaed2d16e4 100644 --- a/drivers/scsi/g_NCR5380.c

[PATCH v5 4/6] g_NCR5380: Limit PDMA send to 512 B to avoid data 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 v5 5/6] 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 v5 5/6] 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 v5 0/6] 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 v5 0/6] 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.

Re: [PATCH] acpi: thermal: honor "mode" sysfs file setting

On Thu, 2017-06-29 at 00:14 +0200, Rafael J. Wysocki wrote: > On Thursday, June 22, 2017 02:45:42 PM Enric Balletbo i Serra wrote: > > > > From: Sameer Nanda > > > > Under each thermal zone there is a file called "mode". Writing > > enabled > > or disabled to this file

Re: [PATCH] acpi: thermal: honor "mode" sysfs file setting

On Thu, 2017-06-29 at 00:14 +0200, Rafael J. Wysocki wrote: > On Thursday, June 22, 2017 02:45:42 PM Enric Balletbo i Serra wrote: > > > > From: Sameer Nanda > > > > Under each thermal zone there is a file called "mode". Writing > > enabled > > or disabled to this file allows a given thermal

Re: [PATCH 2/2] drm/msm: gpu: call qcom_mdt interfaces only for ARCH_QCOM

On Tue 20 Jun 13:16 PDT 2017, Arnd Bergmann wrote: > When compile-testing for something other than ARCH_QCOM, > we run into a link error: > > drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_hw_init': > a5xx_gpu.c:(.text.a5xx_hw_init+0x600): undefined reference to > `qcom_mdt_get_size'

Re: [PATCH 2/2] drm/msm: gpu: call qcom_mdt interfaces only for ARCH_QCOM

On Tue 20 Jun 13:16 PDT 2017, Arnd Bergmann wrote: > When compile-testing for something other than ARCH_QCOM, > we run into a link error: > > drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_hw_init': > a5xx_gpu.c:(.text.a5xx_hw_init+0x600): undefined reference to > `qcom_mdt_get_size'

[PATCH] ASoC: rsnd: constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 8172 920 090922384

Re: [PATCH] thermal/intel_powerclamp: add const to thermal_cooling_device_ops structure

On Thu, Jun 29, 2017 at 8:30 AM, Zhang Rui wrote: > On Wed, 2017-06-21 at 12:39 +0530, Bhumika Goyal wrote: >> Declare thermal_cooling_device_ops structure as const as it is only >> passed >> as an argument to the function thermal_cooling_device_register and >> this >>

[PATCH] ASoC: rsnd: constify dev_pm_ops structures.

dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by work with const dev_pm_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 8172 920 090922384

Re: [PATCH] thermal/intel_powerclamp: add const to thermal_cooling_device_ops structure

On Thu, Jun 29, 2017 at 8:30 AM, Zhang Rui wrote: > On Wed, 2017-06-21 at 12:39 +0530, Bhumika Goyal wrote: >> Declare thermal_cooling_device_ops structure as const as it is only >> passed >> as an argument to the function thermal_cooling_device_register and >> this >> argument is of type const.

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

Hi James, This has now migrated to the scsi tree. On Wed, 28 Jun 2017 15:55:10 +1000 Stephen Rothwell wrote: > > After merging the scsi-mkp tree, today's linux-next build > (powerpc_ppc64_defconfig) produced these warnings: > > In file included from

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

Hi James, This has now migrated to the scsi tree. On Wed, 28 Jun 2017 15:55:10 +1000 Stephen Rothwell wrote: > > 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, >

Re: [PATCH 1/2] drm/msm: gpu: don't abuse dma_alloc for non-DMA allocations

On Tue 20 Jun 13:16 PDT 2017, Arnd Bergmann wrote: > In zap_shader_load_mdt(), we pass a pointer to a phys_addr_t > into dmam_alloc_coherent, which the compiler warns about: > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'zap_shader_load_mdt': >

Re: [PATCH 1/2] drm/msm: gpu: don't abuse dma_alloc for non-DMA allocations

On Tue 20 Jun 13:16 PDT 2017, Arnd Bergmann wrote: > In zap_shader_load_mdt(), we pass a pointer to a phys_addr_t > into dmam_alloc_coherent, which the compiler warns about: > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'zap_shader_load_mdt': >

Re: [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.

On 06/28/2017 01:28 AM, Eric Anholt wrote: When a mipi_dsi_host is registered, the DT is walked to find any child nodes with compatible strings. Those get registered as DSI devices, and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes. There is one special case

Re: [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.

On 06/28/2017 01:28 AM, Eric Anholt wrote: When a mipi_dsi_host is registered, the DT is walked to find any child nodes with compatible strings. Those get registered as DSI devices, and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes. There is one special case

Re: [ANNOUNCE] v4.11.7-rt3

On Thu, 2017-06-29 at 04:55 +0200, Mike Galbraith wrote: > > cpus_allowed became cpus_mask.  Anything (crash.. hohum, yet again) > that rummages around in the kernels gizzard will have to adapt. (wrt crash: nope, it doesn't care for a change)

Re: [ANNOUNCE] v4.11.7-rt3

On Thu, 2017-06-29 at 04:55 +0200, Mike Galbraith wrote: > > cpus_allowed became cpus_mask.  Anything (crash.. hohum, yet again) > that rummages around in the kernels gizzard will have to adapt. (wrt crash: nope, it doesn't care for a change)

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

[add linux-xfs to cc] On Thu, Jun 29, 2017 at 04:37:14AM +, William Koh wrote: > On 6/28/17, 7:32 PM, "Andreas Dilger" wrote: > > On Jun 28, 2017, at 4:06 PM, Kyungchan Koh wrote: > > > > In fs/ext4/super.c, the function ext4_nfs_get_inode

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

[add linux-xfs to cc] On Thu, Jun 29, 2017 at 04:37:14AM +, William Koh wrote: > On 6/28/17, 7:32 PM, "Andreas Dilger" wrote: > > On Jun 28, 2017, at 4:06 PM, Kyungchan Koh wrote: > > > > In fs/ext4/super.c, the function ext4_nfs_get_inode takes as input > > "generation"

[PATCH] staging: lustre: lnet: remove dead code

Remove code which was permanently disabled with ifdefs. This also resolves the following checkpatch warning which was triggered by the dead code: WARNING: space prohibited before semicolon Signed-off-by: Dmitriy Cherkasov ---

[PATCH] staging: lustre: lnet: remove dead code

Remove code which was permanently disabled with ifdefs. This also resolves the following checkpatch warning which was triggered by the dead code: WARNING: space prohibited before semicolon Signed-off-by: Dmitriy Cherkasov --- drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h | 6 -- 1

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

On 29 June 2017 01:57:19 CEST, "Gustavo A. R. Silva" wrote: --- 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

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

On 29 June 2017 01:57:19 CEST, "Gustavo A. R. Silva" wrote: --- 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 *

linux-next: manual merge of the usb tree with the uuid tree

Hi Greg, Today's linux-next merge of the usb tree got a conflict in: drivers/usb/misc/ucsi.c between commit: 94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()") from the uuid tree and commit: 8243edf44152 ("usb: typec: ucsi: Add ACPI driver") from the usb tree.

linux-next: manual merge of the usb tree with the uuid tree

Hi Greg, Today's linux-next merge of the usb tree got a conflict in: drivers/usb/misc/ucsi.c between commit: 94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()") from the uuid tree and commit: 8243edf44152 ("usb: typec: ucsi: Add ACPI driver") from the usb tree.

Re: [linux-sunxi] Re: [PATCH v3 2/3] dt-bindings: input: Add R_LRADC support for A83T

2017-06-28 1:36 GMT+08:00 Maxime Ripard : > Hi, > > On Tue, Jun 27, 2017 at 11:29:10PM +0800, icen...@aosc.io wrote: >> Maxime, here's another problem: if we have already a GP LRADC driver, >> how can we tell the kernel to use it as IIO ADC rather than keys? > >

Re: [linux-sunxi] Re: [PATCH v3 2/3] dt-bindings: input: Add R_LRADC support for A83T

2017-06-28 1:36 GMT+08:00 Maxime Ripard : > Hi, > > On Tue, Jun 27, 2017 at 11:29:10PM +0800, icen...@aosc.io wrote: >> Maxime, here's another problem: if we have already a GP LRADC driver, >> how can we tell the kernel to use it as IIO ADC rather than keys? > > The GPADC IIO driver is not for the

Re: [PATCH v6 5/6] arm64: dts: Add ipq8074 SoC and HK01 board support

On Fri 09 Jun 02:41 PDT 2017, Varadarajan Narayanan wrote: > diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts > b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts [..] > + > + chosen { > + bootargs = "root=/dev/ram0 rw init=/init"; As far as I know you can omit both root= and

Re: [PATCH v6 5/6] arm64: dts: Add ipq8074 SoC and HK01 board support

On Fri 09 Jun 02:41 PDT 2017, Varadarajan Narayanan wrote: > diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts > b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts [..] > + > + chosen { > + bootargs = "root=/dev/ram0 rw init=/init"; As far as I know you can omit both root= and

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

On 6/28/17, 7:32 PM, "Andreas Dilger" wrote: On Jun 28, 2017, at 4:06 PM, Kyungchan Koh wrote: > > In fs/ext4/super.c, the function ext4_nfs_get_inode takes as input > "generation" that can be used to specify the generation of the inode to

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

On 6/28/17, 7:32 PM, "Andreas Dilger" wrote: On Jun 28, 2017, at 4:06 PM, Kyungchan Koh wrote: > > In fs/ext4/super.c, the function ext4_nfs_get_inode takes as input > "generation" that can be used to specify the generation of the inode to > be returned. When 0 is given as

Re: [PATCH v3 2/3] dt-bindings: input: Add R_LRADC support for A83T

2017-06-28 1:31 GMT+08:00 Maxime Ripard : > On Tue, Jun 27, 2017 at 11:18:17PM +0800, Ziping Chen wrote: >> 2017-06-27 1:15 GMT+08:00 Maxime Ripard : >> > Hi, >> > >> > On Sat, Jun 24, 2017 at 10:45:14AM +0800, Ziping Chen wrote:

Re: [PATCH v3 2/3] dt-bindings: input: Add R_LRADC support for A83T

2017-06-28 1:31 GMT+08:00 Maxime Ripard : > On Tue, Jun 27, 2017 at 11:18:17PM +0800, Ziping Chen wrote: >> 2017-06-27 1:15 GMT+08:00 Maxime Ripard : >> > Hi, >> > >> > On Sat, Jun 24, 2017 at 10:45:14AM +0800, Ziping Chen wrote: >> >> From: Ziping Chen >> >> >> >> Allwinner A83T SoC has a low

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

On June 28, 2017 7:12:04 PM PDT, zhong jiang wrote: >On 2017/6/29 5:43, h...@zytor.com wrote: >> On June 27, 2017 9:35:10 PM PDT, zhong jiang >wrote: >>> Hi, Ingo >>> >>> Thank you for the comment. >>> On 2017/6/22 0:40, Ingo Molnar wrote: *

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

On June 28, 2017 7:12:04 PM PDT, zhong jiang wrote: >On 2017/6/29 5:43, h...@zytor.com wrote: >> On June 27, 2017 9:35:10 PM PDT, zhong jiang >wrote: >>> Hi, Ingo >>> >>> Thank you for the comment. >>> On 2017/6/22 0:40, Ingo Molnar wrote: * zhong jiang wrote: > when shift

Re: [PATCH v6 6/6] arm64: defconfig: Enable qcom ipq8074 clock and pinctrl

On Fri 09 Jun 02:41 PDT 2017, Varadarajan Narayanan wrote: > From: Abhishek Sahu > > These configs are required for booting kernel in qcom > ipq8074 boards. > > Signed-off-by: Abhishek Sahu > Signed-off-by: Varadarajan Narayanan

Re: [PATCH v6 6/6] arm64: defconfig: Enable qcom ipq8074 clock and pinctrl

On Fri 09 Jun 02:41 PDT 2017, Varadarajan Narayanan wrote: > From: Abhishek Sahu > > These configs are required for booting kernel in qcom > ipq8074 boards. > > Signed-off-by: Abhishek Sahu > Signed-off-by: Varadarajan Narayanan Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH v6 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Fri 09 Jun 02:41 PDT 2017, Varadarajan Narayanan wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for ipq8074. > > Acked-by: Rob Herring (bindings) > Signed-off-by: Manoharan Vijaya Raghavan > Signed-off-by:

Re: [PATCH v6 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Fri 09 Jun 02:41 PDT 2017, Varadarajan Narayanan wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for ipq8074. > > Acked-by: Rob Herring (bindings) > Signed-off-by: Manoharan Vijaya Raghavan > Signed-off-by: Varadarajan Narayanan Sorry for the

Re: [PATCH] cpufreq: Find transition latency dynamically

On 02-06-17, 16:59, Viresh Kumar wrote: > The transition_latency_ns represents the maximum time it can take for > the hardware to switch from/to any frequency for a CPU. > > The transition_latency_ns is used currently for two purposes: > > o To check if the hardware latency is over the maximum

Re: [PATCH] cpufreq: Find transition latency dynamically

On 02-06-17, 16:59, Viresh Kumar wrote: > The transition_latency_ns represents the maximum time it can take for > the hardware to switch from/to any frequency for a CPU. > > The transition_latency_ns is used currently for two purposes: > > o To check if the hardware latency is over the maximum

[PATCH] hashtable: remove repeated phrase from a comment

"in a rcu enabled hashtable" is repeated twice in a comment. Signed-off-by: Jakub Kicinski --- I'm not sure who would take this :S include/linux/hashtable.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h

[PATCH] hashtable: remove repeated phrase from a comment

"in a rcu enabled hashtable" is repeated twice in a comment. Signed-off-by: Jakub Kicinski --- I'm not sure who would take this :S include/linux/hashtable.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h index 661e5c2a8e2a..082dc1bd0801

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

On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote: > IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers > warning if it happns, since commit 04c848d39879 ("genirq: Warn when > IRQ_NOAUTOEN is used with shared interrupts"). And this is the case for > OMAP DWC 3

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

On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote: > IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers > warning if it happns, since commit 04c848d39879 ("genirq: Warn when > IRQ_NOAUTOEN is used with shared interrupts"). And this is the case for > OMAP DWC 3

Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection

Hi Kees, 在 2017/5/31 5:39, Kees Cook 写道: This protection is a modified version of the x86 PAX_REFCOUNT defense from PaX/grsecurity. This speeds up the refcount_t API by duplicating the existing atomic_t implementation with a single instruction added to detect if the refcount has wrapped past

Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection

Hi Kees, 在 2017/5/31 5:39, Kees Cook 写道: This protection is a modified version of the x86 PAX_REFCOUNT defense from PaX/grsecurity. This speeds up the refcount_t API by duplicating the existing atomic_t implementation with a single instruction added to detect if the refcount has wrapped past

[PATCH] aic7xxx: fix firmware build with O=path

Building firmware with O=path was apparently broken in aic7 for ever. Message of the previous commit to the Makefile (from 2008) mentions this unfortunate state of affairs already. Fix this, mostly to make randconfig builds more reliable. Signed-off-by: Jakub Kicinski

[PATCH] aic7xxx: fix firmware build with O=path

Building firmware with O=path was apparently broken in aic7 for ever. Message of the previous commit to the Makefile (from 2008) mentions this unfortunate state of affairs already. Fix this, mostly to make randconfig builds more reliable. Signed-off-by: Jakub Kicinski ---

  1   2   3   4   5   6   7   8   9   10   >