Re: [PATCH] phy: cpcap-usb: Fix missing return statement

On Monday 12 June 2017 01:42 PM, Tony Lindgren wrote: > Commit 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support") > is missing return statement as noted by Colin Ian King > . If the optional pins are not configured, > we just want to return early and not

Re: [PATCH] phy: cpcap-usb: Fix missing return statement

On Monday 12 June 2017 01:42 PM, Tony Lindgren wrote: > Commit 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support") > is missing return statement as noted by Colin Ian King > . If the optional pins are not configured, > we just want to return early and not attempt to configure the pins. >

Re: [PATCH 00/13] block: assorted cleanup for bio splitting and cloning.

On Thu, May 11 2017, NeilBrown wrote: > On Tue, May 02 2017, NeilBrown wrote: > >> This is a revision of my series of patches working >> towards removing the bioset work queues. > > Hi Jens, > could I get some feed-back about your thoughts on this series? > Will you apply it? When? Do I need

Re: [PATCH 00/13] block: assorted cleanup for bio splitting and cloning.

On Thu, May 11 2017, NeilBrown wrote: > On Tue, May 02 2017, NeilBrown wrote: > >> This is a revision of my series of patches working >> towards removing the bioset work queues. > > Hi Jens, > could I get some feed-back about your thoughts on this series? > Will you apply it? When? Do I need

Re: [PATCH v2 0/2] Broadcom Stingray SATA PHY support

On Thursday 08 June 2017 05:01 PM, Srinath Mannam wrote: > This patchset extends the Broadcom SATA PHY driver to add > support for Stingray SATA PHY. > > All patches are based on linux-phy/next > > Changes since v1: > - Rebased patchset on linux-phy/next > merged, thanks! -Kishon > Srinath

Re: [PATCH v2 0/2] Broadcom Stingray SATA PHY support

On Thursday 08 June 2017 05:01 PM, Srinath Mannam wrote: > This patchset extends the Broadcom SATA PHY driver to add > support for Stingray SATA PHY. > > All patches are based on linux-phy/next > > Changes since v1: > - Rebased patchset on linux-phy/next > merged, thanks! -Kishon > Srinath

Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.

On 06/16/2017 02:11 AM, Eric Anholt wrote: If the panel-bridge is being set up after the drm_mode_config_reset(), then the connector's state would never get initialized, and we'd dereference the NULL in the hotplug path. We also need to register the connector, so that userspace can get at it.

Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.

On 06/16/2017 02:11 AM, Eric Anholt wrote: If the panel-bridge is being set up after the drm_mode_config_reset(), then the connector's state would never get initialized, and we'd dereference the NULL in the hotplug path. We also need to register the connector, so that userspace can get at it.

Re: [PATCH v7 16/16] mtd: nand: denali: avoid magic numbers and rename for clarification

2017-06-13 22:45 GMT+09:00 Masahiro Yamada : > Introduce some macros and helpers to avoid magic numbers and > rename macros/functions for clarification. > > - We see '| 2' in several places. This means Data Cycle in MAP11 mode. > The Denali User's Guide says

Re: [PATCH v7 16/16] mtd: nand: denali: avoid magic numbers and rename for clarification

2017-06-13 22:45 GMT+09:00 Masahiro Yamada : > Introduce some macros and helpers to avoid magic numbers and > rename macros/functions for clarification. > > - We see '| 2' in several places. This means Data Cycle in MAP11 mode. > The Denali User's Guide says bit[1:0] of MAP11 is like follows: >

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Peter > Hutterer > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch > exported by ACPI > > On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv wrote: > > Hi, Peter

RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Peter > Hutterer > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch > exported by ACPI > > On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv wrote: > > Hi, Peter

[PATCH v3] staging: wlan-ng: Fix struct definition's and variable type

From: Suniel Mahesh le16_to_cpu() accepts argument of type __le16 and cpu_to_le16() returns an argument of type __le16. This patch fixes: (a) the type of the variable that end's up getting return from cpu_to_le16(). (b) the member types of struct

[PATCH v3] staging: wlan-ng: Fix struct definition's and variable type

From: Suniel Mahesh le16_to_cpu() accepts argument of type __le16 and cpu_to_le16() returns an argument of type __le16. This patch fixes: (a) the type of the variable that end's up getting return from cpu_to_le16(). (b) the member types of struct hfa384x_host_scan_request_data, struct

[PATCH] selftests: lib: Skip tests on missing test modules

With older kernels, printf.sh and bitmap.sh fail because they can't find the respective test modules they are looking for. Add the skip portion on missing the respective test_XXX module. Error out the same way as prime_numbers.sh. Signed-off-by: Sumit Semwal ---

[PATCH] selftests: lib: Skip tests on missing test modules

With older kernels, printf.sh and bitmap.sh fail because they can't find the respective test modules they are looking for. Add the skip portion on missing the respective test_XXX module. Error out the same way as prime_numbers.sh. Signed-off-by: Sumit Semwal ---

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

Hi all, Today's linux-next merge of the uuid tree got conflicts in: drivers/acpi/apei/ghes.c include/uapi/linux/uuid.h between commits: f4dccde3f9b9 ("ras: acpi/apei: cper: add support for generic data v3 structure") 476e4940c251 ("ras: acpi / apei: generate trace event for

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

Hi all, Today's linux-next merge of the uuid tree got conflicts in: drivers/acpi/apei/ghes.c include/uapi/linux/uuid.h between commits: f4dccde3f9b9 ("ras: acpi/apei: cper: add support for generic data v3 structure") 476e4940c251 ("ras: acpi / apei: generate trace event for

Re: [PATCH] ppc64/perf: Fix oops when kthread execs user process

Ravi Bangoria writes: > When a kthread makes a call_usermodehelper() call the steps are: > a. allocates current->mm > b. load_elf_binary() > c. populates current->thread.regs > > While doing this, interrupts are not disabled. If there is a perf > interrupt in

Re: [PATCH] ppc64/perf: Fix oops when kthread execs user process

Ravi Bangoria writes: > When a kthread makes a call_usermodehelper() call the steps are: > a. allocates current->mm > b. load_elf_binary() > c. populates current->thread.regs > > While doing this, interrupts are not disabled. If there is a perf > interrupt in the middle of this process (i.e.

Re: linux-next: build warning after merge of the wireless-drivers tree

Stephen Rothwell writes: > After merging the wireless-drivers tree, today's linux-next build > (x86_64 allmodconfig) produced this warning: > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function > 'brcmf_usb_probe_phase2': >

Re: linux-next: build warning after merge of the wireless-drivers tree

Stephen Rothwell writes: > After merging the wireless-drivers tree, today's linux-next build > (x86_64 allmodconfig) produced this warning: > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function > 'brcmf_usb_probe_phase2': >

[PATCH 2/2] loop: Add PF_LESS_THROTTLE to block/loop device thread.

When a filesystem is mounted from a loop device, writes are throttled by balance_dirty_pages() twice: once when writing to the filesystem and once when the loop_handle_cmd() writes to the backing file. This double-throttling can trigger positive feedback loops that create significant delays. The

[PATCH 2/2] loop: Add PF_LESS_THROTTLE to block/loop device thread.

When a filesystem is mounted from a loop device, writes are throttled by balance_dirty_pages() twice: once when writing to the filesystem and once when the loop_handle_cmd() writes to the backing file. This double-throttling can trigger positive feedback loops that create significant delays. The

[PATCH 0/2] Two fixes for loop devices

Hi Jens, one of these is a resend of a patch I sent a while back. The other is new - loop closes files differently from close() and in a way that can confuse NFS. Thanks, NeilBrown --- NeilBrown (2): loop: use filp_close() rather than fput() loop: Add PF_LESS_THROTTLE to

[PATCH 0/2] Two fixes for loop devices

Hi Jens, one of these is a resend of a patch I sent a while back. The other is new - loop closes files differently from close() and in a way that can confuse NFS. Thanks, NeilBrown --- NeilBrown (2): loop: use filp_close() rather than fput() loop: Add PF_LESS_THROTTLE to

[PATCH 1/2] loop: use filp_close() rather than fput()

When a loop device is being shutdown the backing file is closed with fput(). This is different from how close(2) closes files - it uses filp_close(). The difference is important for filesystems which provide a ->flush file operation such as NFS. NFS assumes a flush will always be called on last

[PATCH 1/2] loop: use filp_close() rather than fput()

When a loop device is being shutdown the backing file is closed with fput(). This is different from how close(2) closes files - it uses filp_close(). The difference is important for filesystems which provide a ->flush file operation such as NFS. NFS assumes a flush will always be called on last

Re: Applied "ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'" to the asoc tree

Le 15/06/2017 à 19:20, Mark Brown a écrit : The patch ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe' has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the

Re: Applied "ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'" to the asoc tree

Le 15/06/2017 à 19:20, Mark Brown a écrit : The patch ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe' has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the

[PATCH] MAINTAINERS: Add an entry for MediaTek PCIe driver

Add MediaTek PCIe driver maintainer entry. Signed-off-by: Ryder Lee --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f7d568b..736648e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9957,6 +9957,14 @@ S:

[PATCH] MAINTAINERS: Add an entry for MediaTek PCIe driver

Add MediaTek PCIe driver maintainer entry. Signed-off-by: Ryder Lee --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f7d568b..736648e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9957,6 +9957,14 @@ S: Supported F:

[PATCH 0/7] fujitsu-laptop: ACPI-related cleanups

In preparation for splitting fujitsu-laptop into two separate modules, I prepared two more cleanup series to minimize the amount of code being moved around. This first series contains all patches that touch ACPI in some way, which is why I am CCing linux-acpi as per Rafael's previous advice.

[PATCH 0/7] fujitsu-laptop: ACPI-related cleanups

In preparation for splitting fujitsu-laptop into two separate modules, I prepared two more cleanup series to minimize the amount of code being moved around. This first series contains all patches that touch ACPI in some way, which is why I am CCing linux-acpi as per Rafael's previous advice.

[PATCH 4/7] platform/x86: fujitsu-laptop: sanitize hotkey input device identification

In the case of brightness-related FUJ02B1 ACPI device, initializing the input device associated with it identically as acpi-video initializes its input device makes sense. However, using the same data for the input device associated with the FUJ02E3 ACPI device makes little sense, because the

[PATCH 5/7] platform/x86: fujitsu-laptop: do not update ACPI device power status

Calling acpi_bus_update_power() for ACPI devices FUJ02B1 and FUJ02E3 is pointless as they are not power manageable (neither _PS0 nor _PR0 is defined for any of them), which causes their power state to be inherited from their parent devices. Given the ACPI paths of these two devices

[PATCH 5/7] platform/x86: fujitsu-laptop: do not update ACPI device power status

Calling acpi_bus_update_power() for ACPI devices FUJ02B1 and FUJ02E3 is pointless as they are not power manageable (neither _PS0 nor _PR0 is defined for any of them), which causes their power state to be inherited from their parent devices. Given the ACPI paths of these two devices

[PATCH 4/7] platform/x86: fujitsu-laptop: sanitize hotkey input device identification

In the case of brightness-related FUJ02B1 ACPI device, initializing the input device associated with it identically as acpi-video initializes its input device makes sense. However, using the same data for the input device associated with the FUJ02E3 ACPI device makes little sense, because the

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

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,

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

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,

[PATCH 2/7] platform/x86: fujitsu-laptop: remove redundant safety checks

Do not check whether the pointer passed to ACPI add callbacks is NULL as it is earlier dereferenced anyway in the bus-level probe callback, acpi_device_probe(). Do not check the value of acpi_disabled in fujitsu_init(), because it is already done by acpi_bus_register_driver(), which is the first

[PATCH 2/7] platform/x86: fujitsu-laptop: remove redundant safety checks

Do not check whether the pointer passed to ACPI add callbacks is NULL as it is earlier dereferenced anyway in the bus-level probe callback, acpi_device_probe(). Do not check the value of acpi_disabled in fujitsu_init(), because it is already done by acpi_bus_register_driver(), which is the first

[PATCH 6/7] platform/x86: fujitsu-laptop: do not evaluate ACPI _INI methods

acpi_ns_initialize_devices(), which is called during system-wide ACPI initialization, already detects and calls all _INI methods belonging to objects present in ACPI tables. There is no need to call these methods again every time the module is loaded because they only initialize status flags and

[PATCH 7/7] platform/x86: fujitsu-laptop: rework debugging

Using a dedicated Kconfig option for enabling debugging means the user may be forced to recompile their kernel in order to gather debugging information, which is inconvenient. Replace custom debugging infrastructure with standard logging functions, taking advantage of dynamic debug. Replace a

[PATCH 6/7] platform/x86: fujitsu-laptop: do not evaluate ACPI _INI methods

acpi_ns_initialize_devices(), which is called during system-wide ACPI initialization, already detects and calls all _INI methods belonging to objects present in ACPI tables. There is no need to call these methods again every time the module is loaded because they only initialize status flags and

[PATCH 7/7] platform/x86: fujitsu-laptop: rework debugging

Using a dedicated Kconfig option for enabling debugging means the user may be forced to recompile their kernel in order to gather debugging information, which is inconvenient. Replace custom debugging infrastructure with standard logging functions, taking advantage of dynamic debug. Replace a

[PATCH 3/7] platform/x86: fujitsu-laptop: use strcpy to set ACPI device names and classes

No formatting is needed when setting ACPI device name and class, so switch to using strcpy() for this purpose. Signed-off-by: Michał Kępień --- drivers/platform/x86/fujitsu-laptop.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git

[PATCH 3/7] platform/x86: fujitsu-laptop: use strcpy to set ACPI device names and classes

No formatting is needed when setting ACPI device name and class, so switch to using strcpy() for this purpose. Signed-off-by: Michał Kępień --- drivers/platform/x86/fujitsu-laptop.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 8:05 PM, Andy Lutomirski wrote: > On Thu, Jun 15, 2017 at 7:17 PM, H.J. Lu wrote: >> On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski wrote: >>> On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu wrote:

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 8:05 PM, Andy Lutomirski wrote: > On Thu, Jun 15, 2017 at 7:17 PM, H.J. Lu wrote: >> On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski wrote: >>> On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu wrote: On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote: > On Thu,

Re: LTS testing with latest kselftests - some failures

Hi Alexander, On 16 June 2017 at 04:35, Alexander Alemayhu wrote: > On Thu, Jun 15, 2017 at 11:26:53PM +0530, Sumit Semwal wrote: >> >> 4. bpf tests: These seem to have build failures in mainline as well - >> I also tried to build kselftest-next, but a simple 'make -C >>

Re: LTS testing with latest kselftests - some failures

Hi Alexander, On 16 June 2017 at 04:35, Alexander Alemayhu wrote: > On Thu, Jun 15, 2017 at 11:26:53PM +0530, Sumit Semwal wrote: >> >> 4. bpf tests: These seem to have build failures in mainline as well - >> I also tried to build kselftest-next, but a simple 'make -C >>

Re: [PATCH v2] perf: libdw support for powerpc [ping]

Works like a charm with Milian's patch. Acked-by: Ravi Bangoria Note: I still see very minor differences between libunwind and libdw. Also, second last function gets repeated two times in every callchain but it can be fixed later on. Otherwise all looks good!

Re: [PATCH v2] perf: libdw support for powerpc [ping]

Works like a charm with Milian's patch. Acked-by: Ravi Bangoria Note: I still see very minor differences between libunwind and libdw. Also, second last function gets repeated two times in every callchain but it can be fixed later on. Otherwise all looks good! Thanks, -Ravi On Thursday 15

Re: [PATCH 11/14] mm, memory_hotplug: do not associate hotadded memory to zones until online

On Mon, May 15, 2017 at 10:58:24AM +0200, Michal Hocko wrote: >From: Michal Hocko > >The current memory hotplug implementation relies on having all the >struct pages associate with a zone/node during the physical hotplug phase

Re: [PATCH 11/14] mm, memory_hotplug: do not associate hotadded memory to zones until online

On Mon, May 15, 2017 at 10:58:24AM +0200, Michal Hocko wrote: >From: Michal Hocko > >The current memory hotplug implementation relies on having all the >struct pages associate with a zone/node during the physical hotplug phase >(arch_add_memory->__add_pages->__add_section->__add_zone). In the

[git pull] drm fixes for 4.12-rc6

Hi Linus, This is the main fixes pull for 4.12-rc6, all pretty normal for this stage, nothing really stands out. The mxsfb one is probably the largest and it's for a black screen boot problem. Dave. The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452: Linux 4.12-rc5

[git pull] drm fixes for 4.12-rc6

Hi Linus, This is the main fixes pull for 4.12-rc6, all pretty normal for this stage, nothing really stands out. The mxsfb one is probably the largest and it's for a black screen boot problem. Dave. The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452: Linux 4.12-rc5

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Tetsuo Handa wrote: > and clarify in your patch that there is no possibility > of waiting for direct/indirect memory allocation inside free_pgtables(), > in addition to fixing the bug above. Oops, this part was wrong, for __oom_reap_task_mm() will give up after waiting for one second because

Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Tetsuo Handa wrote: > and clarify in your patch that there is no possibility > of waiting for direct/indirect memory allocation inside free_pgtables(), > in addition to fixing the bug above. Oops, this part was wrong, for __oom_reap_task_mm() will give up after waiting for one second because

Re: [PATCH v6 7/8] arm64: dts: hikey960: add device node for pmic and regulators

Thanks, Wei. On Fri, Jun 16, 2017 at 3:55 AM, Wei Xu wrote: > Hi Guodong, > > On 2017/6/8 23:08, Guodong Xu wrote: >> From: Wang Xiaoyin >> >> add device node for hi6421 pmic core and hi6421v530 >> voltage regulator,include LDO(1,3,9,11,15,16)

Re: [PATCH v6 7/8] arm64: dts: hikey960: add device node for pmic and regulators

Thanks, Wei. On Fri, Jun 16, 2017 at 3:55 AM, Wei Xu wrote: > Hi Guodong, > > On 2017/6/8 23:08, Guodong Xu wrote: >> From: Wang Xiaoyin >> >> add device node for hi6421 pmic core and hi6421v530 >> voltage regulator,include LDO(1,3,9,11,15,16) >> >> Signed-off-by: Wang Xiaoyin >>

Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c

Hi all, On Fri, 16 Jun 2017 11:13:35 +1000 Stephen Rothwell wrote: > > On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman > wrote: > > > > "Rowand, Frank" writes: > > > > > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem

Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c

Hi all, On Fri, 16 Jun 2017 11:13:35 +1000 Stephen Rothwell wrote: > > On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman > wrote: > > > > "Rowand, Frank" writes: > > > > > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem > > > [mailto:abdha...@linux.vnet.ibm.com] wrote: > > >> > >

Re: [PATCH] autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL

On Fri, 2017-06-16 at 12:13 +1000, NeilBrown wrote: > On Thu, Jun 15 2017, Andrew Morton wrote: > > > On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown wrote: > > > > > > > > If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL > > > ioctl, autofs4_d_automount() will return

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

Hi Kees, On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook wrote: > > I'm so confused -- isn't this in next? All the build tests I did were > against yesterday's -next which includes this from what I can see... It is in next, but gets merged after the kspp tree ... so, this is

Re: [PATCH] autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL

On Fri, 2017-06-16 at 12:13 +1000, NeilBrown wrote: > On Thu, Jun 15 2017, Andrew Morton wrote: > > > On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown wrote: > > > > > > > > If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL > > > ioctl, autofs4_d_automount() will return > > >    

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

Hi Kees, On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook wrote: > > I'm so confused -- isn't this in next? All the build tests I did were > against yesterday's -next which includes this from what I can see... It is in next, but gets merged after the kspp tree ... so, this is when inter-tree

RE: [PATCH net-next v2 0/2] r8152: adjust runtime suspend/resume

David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, June 14, 2017 1:02 AM > > v2: > > For #1, replace GFP_KERNEL with GFP_NOIO for usb_submit_urb(). > > > > v1: > > Improve the flow about runtime suspend/resume and make the code > > easy to read. > > Series applied. Excuse me. I don't

RE: [PATCH net-next v2 0/2] r8152: adjust runtime suspend/resume

David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, June 14, 2017 1:02 AM > > v2: > > For #1, replace GFP_KERNEL with GFP_NOIO for usb_submit_urb(). > > > > v1: > > Improve the flow about runtime suspend/resume and make the code > > easy to read. > > Series applied. Excuse me. I don't

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

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/acpi/apei/ghes.c between commit: d0189b2eef2e ("acpi: apei: handle SEA notification type for ARMv8") from the arm64 tree and commit: 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") from the

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

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/acpi/apei/ghes.c between commit: d0189b2eef2e ("acpi: apei: handle SEA notification type for ARMv8") from the arm64 tree and commit: 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") from the

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

On Thu, Jun 15, 2017 at 7:51 PM, Daniel Micay wrote: > On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote: >> Hi Kees, >> >> After merging the kspp tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> In file included from

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

On Thu, Jun 15, 2017 at 7:51 PM, Daniel Micay wrote: > On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote: >> Hi Kees, >> >> After merging the kspp tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> In file included from include/linux/bitmap.h:8:0, >>

Re: [virtio-dev] Re: [PATCH v11 3/6] virtio-balloon: VIRTIO_BALLOON_F_PAGE_CHUNKS

On Thu, Jun 15, 2017 at 04:10:17PM +0800, Wei Wang wrote: > On 06/14/2017 01:56 AM, Michael S. Tsirkin wrote: > > On Fri, Jun 09, 2017 at 06:41:38PM +0800, Wei Wang wrote: > > > Add a new feature, VIRTIO_BALLOON_F_PAGE_CHUNKS, which enables > > > the transfer of the ballooned (i.e.

Re: [virtio-dev] Re: [PATCH v11 3/6] virtio-balloon: VIRTIO_BALLOON_F_PAGE_CHUNKS

On Thu, Jun 15, 2017 at 04:10:17PM +0800, Wei Wang wrote: > On 06/14/2017 01:56 AM, Michael S. Tsirkin wrote: > > On Fri, Jun 09, 2017 at 06:41:38PM +0800, Wei Wang wrote: > > > Add a new feature, VIRTIO_BALLOON_F_PAGE_CHUNKS, which enables > > > the transfer of the ballooned (i.e.

Re: [PATCH v3 1/3] rtmutex: update rt-mutex-design

Hi Steven & Sebastian, If there are no more comments, could you like to give reviewed-by? :) Regards Alex On 05/25/2017 01:26 PM, Alex Shi wrote: > The rt-mutex-design documents didn't gotten meaningful update from its > first version. Even after owner's pending bit was removed in commit >

Re: [PATCH v3 1/3] rtmutex: update rt-mutex-design

Hi Steven & Sebastian, If there are no more comments, could you like to give reviewed-by? :) Regards Alex On 05/25/2017 01:26 PM, Alex Shi wrote: > The rt-mutex-design documents didn't gotten meaningful update from its > first version. Even after owner's pending bit was removed in commit >

Re: [RFC PATCH] cpu_pm/rt: replace rt rwlock with raw spinlock

It's a serious bug which cause arm/arm64 rt boot failed. Anyone like to give a glance? Thanks Alex On 06/14/2017 09:22 PM, Alex Shi wrote: > This is a quick fix for a bug as 'scheduling while atomic' or > 'scheduling from the idle thread' on arm/arm64. > > On arm/arm64, rwlock

Re: [RFC PATCH] cpu_pm/rt: replace rt rwlock with raw spinlock

It's a serious bug which cause arm/arm64 rt boot failed. Anyone like to give a glance? Thanks Alex On 06/14/2017 09:22 PM, Alex Shi wrote: > This is a quick fix for a bug as 'scheduling while atomic' or > 'scheduling from the idle thread' on arm/arm64. > > On arm/arm64, rwlock

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

On Fri, Jun 16, 2017 at 09:07:57AM +0800, Boqun Feng wrote: > On Thu, Jun 15, 2017 at 10:56:29AM -0700, Paul E. McKenney wrote: > [...] > > > > > > > > FWLIW, I agree. There was a smb_mb() in RT-linux's equivalent of > > > > swait_activate(). > > > > > > > >

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

On Fri, Jun 16, 2017 at 09:07:57AM +0800, Boqun Feng wrote: > On Thu, Jun 15, 2017 at 10:56:29AM -0700, Paul E. McKenney wrote: > [...] > > > > > > > > FWLIW, I agree. There was a smb_mb() in RT-linux's equivalent of > > > > swait_activate(). > > > > > > > >

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Thu, Jun 15, 2017 at 10:12 PM, Alan Stern wrote: > On Thu, 15 Jun 2017, Kai-Heng Feng wrote: > >> On Wed, Jun 14, 2017 at 1:28 AM, Bjorn Helgaas wrote: >> > >> > The lspci output [1] shows: >> > >> > 00:12.0 USB controller: Advanced Micro

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Thu, Jun 15, 2017 at 10:12 PM, Alan Stern wrote: > On Thu, 15 Jun 2017, Kai-Heng Feng wrote: > >> On Wed, Jun 14, 2017 at 1:28 AM, Bjorn Helgaas wrote: >> > >> > The lspci output [1] shows: >> > >> > 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI >> > Controller

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 7:17 PM, H.J. Lu wrote: > On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski wrote: >> On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu wrote: >>> On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote:

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 7:17 PM, H.J. Lu wrote: > On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski wrote: >> On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu wrote: >>> On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote: On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote: > On Thu, Jun 15,

Re: [PATCHv2 3/3] mm: Use updated pmdp_invalidate() inteface to track dirty/accessed bits

Hello, On Thu, Jun 15, 2017 at 05:52:24PM +0300, Kirill A. Shutemov wrote: > This patch uses modifed pmdp_invalidate(), that return previous value of pmd, > to transfer dirty and accessed bits. > > Signed-off-by: Kirill A. Shutemov > --- > fs/proc/task_mmu.c |

Re: [PATCHv2 3/3] mm: Use updated pmdp_invalidate() inteface to track dirty/accessed bits

Hello, On Thu, Jun 15, 2017 at 05:52:24PM +0300, Kirill A. Shutemov wrote: > This patch uses modifed pmdp_invalidate(), that return previous value of pmd, > to transfer dirty and accessed bits. > > Signed-off-by: Kirill A. Shutemov > --- > fs/proc/task_mmu.c | 8 > mm/huge_memory.c

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

> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the > 4.13/scsi-queue and for-next branches. I think that's why Kees didn't > include it but I get he needs to add that. s/get/guess/ Or is that repo supposed to get pulled into next?

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

> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the > 4.13/scsi-queue and for-next branches. I think that's why Kees didn't > include it but I get he needs to add that. s/get/guess/ Or is that repo supposed to get pulled into next?

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

On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote: > Hi Kees, > > After merging the kspp tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from include/linux/bitmap.h:8:0, > from include/linux/cpumask.h:11, >

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

On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote: > Hi Kees, > > After merging the kspp tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from include/linux/bitmap.h:8:0, > from include/linux/cpumask.h:11, >

Re: [PATCH] ppc64/perf: Fix oops when kthread execs user process

Thanks Naveen, On Thursday 15 June 2017 08:57 PM, Naveen N. Rao wrote: > Hmm... are you sure it's the same issue? The above commit only went into > v4.7, which means we weren't able to use --call-graph=dwarf till v4.7. Yes sorry. It's from v4.7 onwards. -Ravi

Re: [PATCH] ppc64/perf: Fix oops when kthread execs user process

Thanks Naveen, On Thursday 15 June 2017 08:57 PM, Naveen N. Rao wrote: > Hmm... are you sure it's the same issue? The above commit only went into > v4.7, which means we weren't able to use --call-graph=dwarf till v4.7. Yes sorry. It's from v4.7 onwards. -Ravi

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 4:37 PM, Dave Hansen wrote: > On 06/15/2017 03:18 PM, Andy Lutomirski wrote: >>> As you pointed out, if you are using XSAVEC's compaction features by >>> leaving bits unset in the requested feature bitmap registers, you have >>> no idea how much data

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 4:37 PM, Dave Hansen wrote: > On 06/15/2017 03:18 PM, Andy Lutomirski wrote: >>> As you pointed out, if you are using XSAVEC's compaction features by >>> leaving bits unset in the requested feature bitmap registers, you have >>> no idea how much data XSAVEC will write,

Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

Hi Matt, [auto build test WARNING on security/next] [also build test WARNING on v4.12-rc5 next-20170615] [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/Matt-Brown/Add-Trusted-Path-Execution

[RFC PATCH] print_tpe_error() can be static

Signed-off-by: Fengguang Wu --- tpe_lsm.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/security/tpe/tpe_lsm.c b/security/tpe/tpe_lsm.c index fda811a..77d2498 100644 --- a/security/tpe/tpe_lsm.c +++ b/security/tpe/tpe_lsm.c @@ -42,7 +42,7

Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

Hi Matt, [auto build test WARNING on security/next] [also build test WARNING on v4.12-rc5 next-20170615] [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/Matt-Brown/Add-Trusted-Path-Execution

[RFC PATCH] print_tpe_error() can be static

Signed-off-by: Fengguang Wu --- tpe_lsm.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/security/tpe/tpe_lsm.c b/security/tpe/tpe_lsm.c index fda811a..77d2498 100644 --- a/security/tpe/tpe_lsm.c +++ b/security/tpe/tpe_lsm.c @@ -42,7 +42,7 @@ static int

  1   2   3   4   5   6   7   8   9   10   >