[PATCH v2] eeprom: idt_89hpesx: Support both ACPI and OF probing

From: Huy Duong Allow the idt_89hpesx driver to get information from child nodes from both OF and ACPI by using more generic fwnode_property_read*() functions. Below is an example of instantiating idt_89hpesx driver via ACPI Table: Device(IDT0) { Name(_HID, "PRP0001")

[PATCH v2] eeprom: idt_89hpesx: Support both ACPI and OF probing

From: Huy Duong Allow the idt_89hpesx driver to get information from child nodes from both OF and ACPI by using more generic fwnode_property_read*() functions. Below is an example of instantiating idt_89hpesx driver via ACPI Table: Device(IDT0) { Name(_HID, "PRP0001") Name(_CID, "PRP0001")

答复: [PATCH v8 2/2] mmc: dw_mmc-k3: add sd support for hi3660

Hi, Ulf Thank you very much for your advice. 1. Version history is really great information, however it doesn't belong inside the change log itsefl. Instead add "---" and a newline here, then put it all below that. 【LiWei】OK，I will fix it; 2. We have an API, mmc_regulator_set_vqmmc(), that you

答复: [PATCH v8 2/2] mmc: dw_mmc-k3: add sd support for hi3660

Hi, Ulf Thank you very much for your advice. 1. Version history is really great information, however it doesn't belong inside the change log itsefl. Instead add "---" and a newline here, then put it all below that. 【LiWei】OK，I will fix it; 2. We have an API, mmc_regulator_set_vqmmc(), that you

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

On Wed, Aug 09, 2017 at 01:40:01AM +, Casey Leedom wrote: > | From: Bjorn Helgaas > | Sent: Tuesday, August 8, 2017 4:22 PM > | > | This needs to include a link to the Intel spec > | >

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

On Wed, Aug 09, 2017 at 01:40:01AM +, Casey Leedom wrote: > | From: Bjorn Helgaas > | Sent: Tuesday, August 8, 2017 4:22 PM > | > | This needs to include a link to the Intel spec > | >

Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression

On 08/08, Minchan Kim wrote: >On Mon, Aug 07, 2017 at 10:51:00PM -0700, Nadav Amit wrote: >> Nadav Amit wrote: >> >> > Minchan Kim wrote: >> > >> >> Hi, >> >> >> >> On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote: >> >>> Greeting, >>

Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression

On 08/08, Minchan Kim wrote: >On Mon, Aug 07, 2017 at 10:51:00PM -0700, Nadav Amit wrote: >> Nadav Amit wrote: >> >> > Minchan Kim wrote: >> > >> >> Hi, >> >> >> >> On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote: >> >>> Greeting, >> >>> >> >>> FYI, we noticed a -19.3%

[PATCH 2/3] security: keys: Replace time_t with time64_t for struct key_preparsed_payload

The 'struct key_preparsed_payload' will use 'time_t' which we will try to remove in the kernel, since 'time_t' is not year 2038 safe on 32bits systems. Thus this patch replaces 'time_t' with 'time64_t' which is year 2038 safe on 32 bits system for 'struct key_preparsed_payload', moreover we

[PATCH 2/3] security: keys: Replace time_t with time64_t for struct key_preparsed_payload

The 'struct key_preparsed_payload' will use 'time_t' which we will try to remove in the kernel, since 'time_t' is not year 2038 safe on 32bits systems. Thus this patch replaces 'time_t' with 'time64_t' which is year 2038 safe on 32 bits system for 'struct key_preparsed_payload', moreover we

[PATCH 1/3] security: keys: Replace time_t/timespec with time64_t

The 'struct key' will use 'time_t' which we try to remove in the kernel, since 'time_t' is not year 2038 safe on 32bit systems. Also the 'struct keyring_search_context' will use 'timespec' type to record current time, which is also not year 2038 safe on 32bit systems. Thus this patch replaces

[PATCH 1/3] security: keys: Replace time_t/timespec with time64_t

The 'struct key' will use 'time_t' which we try to remove in the kernel, since 'time_t' is not year 2038 safe on 32bit systems. Also the 'struct keyring_search_context' will use 'timespec' type to record current time, which is also not year 2038 safe on 32bit systems. Thus this patch replaces

[PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type

Since the 'expiry' variable of 'struct key_preparsed_payload' has been changed to 'time64_t' type, which is year 2038 safe on 32bits system. In net/rxrpc subsystem, we need convert 'u32' type to 'time64_t' type when copying ticket expires time to 'prep->expiry', then this patch introduces two

[PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type

Since the 'expiry' variable of 'struct key_preparsed_payload' has been changed to 'time64_t' type, which is year 2038 safe on 32bits system. In net/rxrpc subsystem, we need convert 'u32' type to 'time64_t' type when copying ticket expires time to 'prep->expiry', then this patch introduces two

[PATCH 0/3] Fix y2038 issues for security/keys subsystem

Since 'time_t', 'timeval' and 'timespec' types are not year 2038 safe on 32 bits system, this patchset tries to fix this issues for security/keys subsystem and net/rxrpc subsystem which is connected with security/keys subsystem. Baolin Wang (3): security: keys: Replace time_t/timespec with

[PATCH 0/3] Fix y2038 issues for security/keys subsystem

Since 'time_t', 'timeval' and 'timespec' types are not year 2038 safe on 32 bits system, this patchset tries to fix this issues for security/keys subsystem and net/rxrpc subsystem which is connected with security/keys subsystem. Baolin Wang (3): security: keys: Replace time_t/timespec with

[PATCH v3] scheduler: enhancement to show_state_filter and SysRq

Sometimes we want to get tasks in TASK_RUNNING sepcifically, instead of dump all tasks. For example, when the loadavg are high, we want to dump tasks in TASK_RUNNING and TASK_UNINTERRUPTIBLE, which contribute to system load. But mostly there're lots of tasks in Sleep state, which occupies almost

[PATCH v3] scheduler: enhancement to show_state_filter and SysRq

Sometimes we want to get tasks in TASK_RUNNING sepcifically, instead of dump all tasks. For example, when the loadavg are high, we want to dump tasks in TASK_RUNNING and TASK_UNINTERRUPTIBLE, which contribute to system load. But mostly there're lots of tasks in Sleep state, which occupies almost

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

On Tue, Aug 08, 2017 at 07:31:22PM -0700, Matthew Wilcox wrote: > On Wed, Aug 09, 2017 at 10:51:13AM +0900, Minchan Kim wrote: > > On Tue, Aug 08, 2017 at 06:29:04AM -0700, Matthew Wilcox wrote: > > > On Tue, Aug 08, 2017 at 05:49:59AM -0700, Matthew Wilcox wrote: > > > > + struct bio sbio;

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

On Tue, Aug 08, 2017 at 07:31:22PM -0700, Matthew Wilcox wrote: > On Wed, Aug 09, 2017 at 10:51:13AM +0900, Minchan Kim wrote: > > On Tue, Aug 08, 2017 at 06:29:04AM -0700, Matthew Wilcox wrote: > > > On Tue, Aug 08, 2017 at 05:49:59AM -0700, Matthew Wilcox wrote: > > > > + struct bio sbio;

Re: kernel panic on null pointer on page->mem_cgroup

Yes, the BUG_ON(!page_count(page)) fired for me as well. On Tue, Aug 8, 2017 at 9:44 PM, Jaegeuk Kim wrote: > On 08/08, Johannes Weiner wrote: >> On Tue, Aug 08, 2017 at 03:13:42PM -0400, Brad Bolen wrote: >> > On Tue, Aug 8, 2017 at 1:37 PM, Johannes Weiner

Re: kernel panic on null pointer on page->mem_cgroup

Yes, the BUG_ON(!page_count(page)) fired for me as well. On Tue, Aug 8, 2017 at 9:44 PM, Jaegeuk Kim wrote: > On 08/08, Johannes Weiner wrote: >> On Tue, Aug 08, 2017 at 03:13:42PM -0400, Brad Bolen wrote: >> > On Tue, Aug 8, 2017 at 1:37 PM, Johannes Weiner wrote: >> > > On Tue, Aug 08, 2017

Re: [PATCH net] Revert "vhost: cache used event for better performance"

On 2017年07月30日 14:26, K. Den wrote: On Wed, 2017-07-26 at 19:08 +0300, Michael S. Tsirkin wrote: On Wed, Jul 26, 2017 at 09:37:15PM +0800, Jason Wang wrote: On 2017年07月26日 21:18, Jason Wang wrote: On 2017年07月26日 20:57, Michael S. Tsirkin wrote: On Wed, Jul 26, 2017 at 04:03:17PM +0800,

Re: [PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common

Hi, On 08/08/2017 02:14 PM, Felipe Balbi wrote: > Hi, > > Lu Baolu writes: >>> Lu Baolu writes: The component u_serial provides a glue layer between TTY layer and a USB gadget device needed to provide a basic serial port

Re: [PATCH net] Revert "vhost: cache used event for better performance"

On 2017年07月30日 14:26, K. Den wrote: On Wed, 2017-07-26 at 19:08 +0300, Michael S. Tsirkin wrote: On Wed, Jul 26, 2017 at 09:37:15PM +0800, Jason Wang wrote: On 2017年07月26日 21:18, Jason Wang wrote: On 2017年07月26日 20:57, Michael S. Tsirkin wrote: On Wed, Jul 26, 2017 at 04:03:17PM +0800,

Re: [PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common

Hi, On 08/08/2017 02:14 PM, Felipe Balbi wrote: > Hi, > > Lu Baolu writes: >>> Lu Baolu writes: The component u_serial provides a glue layer between TTY layer and a USB gadget device needed to provide a basic serial port functionality. Currently, u_serial sits under

RE: [PATCH v10 4/4] irqchip/qeic: remove PPCisms for QEIC

On Tue 8/8/2017 6:05 PM, Michael Ellerman wrote: > -Original Message- > From: Michael Ellerman [mailto:m...@ellerman.id.au] > Sent: Tuesday, August 08, 2017 6:05 PM > To: Qiang Zhao ; t...@linutronix.de > Cc: o...@buserror.net;

RE: [PATCH v10 4/4] irqchip/qeic: remove PPCisms for QEIC

On Tue 8/8/2017 6:05 PM, Michael Ellerman wrote: > -Original Message- > From: Michael Ellerman [mailto:m...@ellerman.id.au] > Sent: Tuesday, August 08, 2017 6:05 PM > To: Qiang Zhao ; t...@linutronix.de > Cc: o...@buserror.net; linuxppc-...@lists.ozlabs.org; Xiaobo Xie > ;

[PATCH v2] usb: dwc2: skip L2 state of hcd if work in device mode

The gadget may fail to enqueue request if the controller has enter L2 state. This patch prevent enter L2 state in hcd driver if the controller works in device mode. Change in v2:None, resend to addition maintainer Meng Dongyang (1): usb: dwc2: skip L2 state of hcd if controller work in device

[PATCH v2] usb: dwc2: skip L2 state of hcd if work in device mode

The gadget may fail to enqueue request if the controller has enter L2 state. This patch prevent enter L2 state in hcd driver if the controller works in device mode. Change in v2:None, resend to addition maintainer Meng Dongyang (1): usb: dwc2: skip L2 state of hcd if controller work in device

[PATCH v2] usb: dwc2: skip L2 state of hcd if controller work in device mode

In the case hcd autosuspend is enabled, the hcd will enter L2 state if no device connected. But if the controller works in otg mode, the gadget driver still works in L0 state if connected with host. This may result in transfer fail when gadget enqueue new request but the hcd driver has set the

[PATCH v2] usb: dwc2: skip L2 state of hcd if controller work in device mode

In the case hcd autosuspend is enabled, the hcd will enter L2 state if no device connected. But if the controller works in otg mode, the gadget driver still works in L0 state if connected with host. This may result in transfer fail when gadget enqueue new request but the hcd driver has set the

Re: [PATCH v9 2/4] PCI: Disable PCIe Relaxed Ordering if unsupported

On Sat, Aug 05, 2017 at 03:15:11PM +0800, Ding Tianhong wrote: > When bit4 is set in the PCIe Device Control register, it indicates > whether the device is permitted to use relaxed ordering. > On some platforms using relaxed ordering can have performance issues or > due to erratum can cause

Re: [PATCH v9 2/4] PCI: Disable PCIe Relaxed Ordering if unsupported

On Sat, Aug 05, 2017 at 03:15:11PM +0800, Ding Tianhong wrote: > When bit4 is set in the PCIe Device Control register, it indicates > whether the device is permitted to use relaxed ordering. > On some platforms using relaxed ordering can have performance issues or > due to erratum can cause

[PATCH v9 00/12] rk808: Add RK805 support

change in v9: PATCH V9 1/12: (1) fix spelling issue: s/Chip/chip/ (2) add: Acked-for-MFD-by: Lee Jones PATCH V9 2/12 ~ 12/12: they are applied and no changes, so I don't resend them. change in v8: PATCH V8 1/12: add: Signed-off-by: Joseph Chen

[PATCH v9 01/12] mfd: rk808: fix up the chip id get failed

From: Elaine Zhang the rk8xx chip id is: ((MSB << 8) | LSB) & 0xfff0 Signed-off-by: Elaine Zhang Signed-off-by: Joseph Chen Acked-for-MFD-by: Lee Jones --- drivers/mfd/rk808.c | 21

[PATCH v9 00/12] rk808: Add RK805 support

change in v9: PATCH V9 1/12: (1) fix spelling issue: s/Chip/chip/ (2) add: Acked-for-MFD-by: Lee Jones PATCH V9 2/12 ~ 12/12: they are applied and no changes, so I don't resend them. change in v8: PATCH V8 1/12: add: Signed-off-by: Joseph Chen PATCH V8 2/12: add: Signed-off-by:

[PATCH v9 01/12] mfd: rk808: fix up the chip id get failed

From: Elaine Zhang the rk8xx chip id is: ((MSB << 8) | LSB) & 0xfff0 Signed-off-by: Elaine Zhang Signed-off-by: Joseph Chen Acked-for-MFD-by: Lee Jones --- drivers/mfd/rk808.c | 21 +++-- include/linux/mfd/rk808.h | 1 + 2 files changed, 16 insertions(+), 6

[PATCH v2] Add rk805 node for rk3328-evb.dts

change in v2: add some sort of commit message. Joseph Chen (1): arm64: dts: rockchip: add rk805 node for rk3328-evb arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 137 1 file changed, 137 insertions(+) -- 1.9.1

[PATCH v2] Add rk805 node for rk3328-evb.dts

change in v2: add some sort of commit message. Joseph Chen (1): arm64: dts: rockchip: add rk805 node for rk3328-evb arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 137 1 file changed, 137 insertions(+) -- 1.9.1

[PATCH v2] arm64: dts: rockchip: add rk805 node for rk3328-evb

RK805 consists of 4 DCDCs, 3 LDOs. It's different from RK808 and RK818 that there are 2 output only GPIOs, we should add properties "gpio-controller" and "gpio-cells = <2>". Signed-off-by: Joseph Chen --- arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 137

Re: [v2] hwmon: adt7475: constify attribute_group structures

On Mon, Aug 07, 2017 at 03:06:29PM +0530, Arvind Yadav wrote: > attribute_group are not supposed to change at runtime. All functions > working with attribute_group provided by work with > const attribute_group. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

[PATCH v2] arm64: dts: rockchip: add rk805 node for rk3328-evb

RK805 consists of 4 DCDCs, 3 LDOs. It's different from RK808 and RK818 that there are 2 output only GPIOs, we should add properties "gpio-controller" and "gpio-cells = <2>". Signed-off-by: Joseph Chen --- arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 137 1 file

Re: [v2] hwmon: adt7475: constify attribute_group structures

On Mon, Aug 07, 2017 at 03:06:29PM +0530, Arvind Yadav wrote: > attribute_group are not supposed to change at runtime. All functions > working with attribute_group provided by work with > const attribute_group. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav Kind of

Re: [8/9, v2] hwmon: (core) constify thermal_zone_of_device_ops structures

On Tue, Aug 08, 2017 at 05:09:02PM +0200, Julia Lawall wrote: > The thermal_zone_of_device_ops structure is only passed as the fourth > argument to devm_thermal_zone_of_sensor_register, which is declared > as const. Thus the thermal_zone_of_device_ops structure itself can > be const. > > Done

Re: [8/9, v2] hwmon: (core) constify thermal_zone_of_device_ops structures

On Tue, Aug 08, 2017 at 05:09:02PM +0200, Julia Lawall wrote: > The thermal_zone_of_device_ops structure is only passed as the fourth > argument to devm_thermal_zone_of_sensor_register, which is declared > as const. Thus the thermal_zone_of_device_ops structure itself can > be const. > > Done

[PATCH] ARM: dts: ls1021a: Add support for QSPI with ls1021a SoC

Add QSPI node support, and this function is disabled by default This setting could be overwritten in board-level definitions Signed-off-by: SZ Lin --- arch/arm/boot/dts/ls1021a.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git

Re: [9/9, v2] hwmon: (scpi) constify thermal_zone_of_device_ops structures

On Tue, Aug 08, 2017 at 05:09:03PM +0200, Julia Lawall wrote: > The thermal_zone_of_device_ops structure is only passed as the fourth > argument to devm_thermal_zone_of_sensor_register, which is declared > as const. Thus the thermal_zone_of_device_ops structure itself can > be const. > > Done

[PATCH] ARM: dts: ls1021a: Add support for QSPI with ls1021a SoC

Add QSPI node support, and this function is disabled by default This setting could be overwritten in board-level definitions Signed-off-by: SZ Lin --- arch/arm/boot/dts/ls1021a.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/ls1021a.dtsi

Re: [9/9, v2] hwmon: (scpi) constify thermal_zone_of_device_ops structures

On Tue, Aug 08, 2017 at 05:09:03PM +0200, Julia Lawall wrote: > The thermal_zone_of_device_ops structure is only passed as the fourth > argument to devm_thermal_zone_of_sensor_register, which is declared > as const. Thus the thermal_zone_of_device_ops structure itself can > be const. > > Done

Re: [PATCH] mm: Revert x86_64 and arm64 ELF_ET_DYN_BASE base

On Tue, Aug 8, 2017 at 2:34 AM, Will Deacon wrote: > On Mon, Aug 07, 2017 at 01:15:42PM -0700, Kees Cook wrote: >> Moving the x86_64 and arm64 PIE base from 0x4000 to 0x0001 >> broke AddressSanitizer. This is a partial revert of: >> >> commit eab09532d400

Re: [PATCH] mm: Revert x86_64 and arm64 ELF_ET_DYN_BASE base

On Tue, Aug 8, 2017 at 2:34 AM, Will Deacon wrote: > On Mon, Aug 07, 2017 at 01:15:42PM -0700, Kees Cook wrote: >> Moving the x86_64 and arm64 PIE base from 0x4000 to 0x0001 >> broke AddressSanitizer. This is a partial revert of: >> >> commit eab09532d400 ("binfmt_elf: use

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

On Tue, Aug 08, 2017 at 06:29:04AM -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 05:49:59AM -0700, Matthew Wilcox wrote: > > + struct bio sbio; > > + struct bio_vec sbvec; > > ... this needs to be sbvec[nr_pages], of course. > > > - bio = mpage_alloc(bdev, blocks[0] <<

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

On Tue, Aug 08, 2017 at 06:29:04AM -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 05:49:59AM -0700, Matthew Wilcox wrote: > > + struct bio sbio; > > + struct bio_vec sbvec; > > ... this needs to be sbvec[nr_pages], of course. > > > - bio = mpage_alloc(bdev, blocks[0] <<

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: > On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown) > wrote: >> >> >> On 2017/7/26 19:08, Joerg Roedel wrote: >>> Hi Robin. >>> >>> On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote: Hi all,

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: > On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown) > wrote: >> >> >> On 2017/7/26 19:08, Joerg Roedel wrote: >>> Hi Robin. >>> >>> On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote: Hi all, In the wake of the ARM SMMU

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

Hi Matthew, On Tue, Aug 08, 2017 at 05:49:59AM -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 03:50:20PM +0900, Minchan Kim wrote: > > There is no need to use dynamic bio allocation for BDI_CAP_SYNC > > devices. They can with on-stack-bio without concern about waiting > > bio allocation

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

Hi Matthew, On Tue, Aug 08, 2017 at 05:49:59AM -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 03:50:20PM +0900, Minchan Kim wrote: > > There is no need to use dynamic bio allocation for BDI_CAP_SYNC > > devices. They can with on-stack-bio without concern about waiting > > bio allocation

Re: [PATCH 16/16] perf tools: Add support for SPF events

On 08/08/2017 08:05 PM, Laurent Dufour wrote: > Add support for the new speculative faults events. > > Signed-off-by: Laurent Dufour > --- > tools/include/uapi/linux/perf_event.h | 2 ++ > tools/perf/util/evsel.c | 2 ++ > tools/perf/util/parse-events.c

Re: [PATCH 16/16] perf tools: Add support for SPF events

On 08/08/2017 08:05 PM, Laurent Dufour wrote: > Add support for the new speculative faults events. > > Signed-off-by: Laurent Dufour > --- > tools/include/uapi/linux/perf_event.h | 2 ++ > tools/perf/util/evsel.c | 2 ++ > tools/perf/util/parse-events.c| 8 >

Re: kernel panic on null pointer on page->mem_cgroup

On 08/08, Johannes Weiner wrote: > On Tue, Aug 08, 2017 at 03:13:42PM -0400, Brad Bolen wrote: > > On Tue, Aug 8, 2017 at 1:37 PM, Johannes Weiner wrote: > > > On Tue, Aug 08, 2017 at 09:56:01AM -0700, Jaegeuk Kim wrote: > > >> On 08/08, Johannes Weiner wrote: > > >> > Hi

Re: kernel panic on null pointer on page->mem_cgroup

On 08/08, Johannes Weiner wrote: > On Tue, Aug 08, 2017 at 03:13:42PM -0400, Brad Bolen wrote: > > On Tue, Aug 8, 2017 at 1:37 PM, Johannes Weiner wrote: > > > On Tue, Aug 08, 2017 at 09:56:01AM -0700, Jaegeuk Kim wrote: > > >> On 08/08, Johannes Weiner wrote: > > >> > Hi Jaegeuk and Bradley, > >

Re: [PATCH 4/4] dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file

On Tue, 2017-08-08 at 17:44 +0530, Kishon Vijay Abraham I wrote: > Chunfeng > > On Thursday 03 August 2017 03:50 PM, Chunfeng Yun wrote: > > hi, > > > > I made a mistake, please ignore the patches with Change-Id, very sorry > > No problem. However can you resend the series after fixing all

Re: [PATCH] block: Fix warning when I/O elevator is changed as request_queue is being removed

Hi David, On Wed, Aug 9, 2017 at 2:13 AM, David Jeffery wrote: > On 08/07/2017 07:53 PM, Ming Lei wrote: >> On Tue, Aug 8, 2017 at 3:38 AM, David Jeffery wrote: > >>> >>> Signed-off-by: David Jeffery >>> --- >>> block/blk-sysfs.c

Re: [PATCH 4/4] dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file

On Tue, 2017-08-08 at 17:44 +0530, Kishon Vijay Abraham I wrote: > Chunfeng > > On Thursday 03 August 2017 03:50 PM, Chunfeng Yun wrote: > > hi, > > > > I made a mistake, please ignore the patches with Change-Id, very sorry > > No problem. However can you resend the series after fixing all

Re: [PATCH] block: Fix warning when I/O elevator is changed as request_queue is being removed

Hi David, On Wed, Aug 9, 2017 at 2:13 AM, David Jeffery wrote: > On 08/07/2017 07:53 PM, Ming Lei wrote: >> On Tue, Aug 8, 2017 at 3:38 AM, David Jeffery wrote: > >>> >>> Signed-off-by: David Jeffery >>> --- >>> block/blk-sysfs.c |2 ++ >>> block/elevator.c |4 >>> 2 files

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Bjorn Helgaas | Sent: Tuesday, August 8, 2017 4:22 PM | | This needs to include a link to the Intel spec | (https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf, | sec 3.9.1). In the commit message or as a

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Bjorn Helgaas | Sent: Tuesday, August 8, 2017 4:22 PM | | This needs to include a link to the Intel spec | (https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf, | sec 3.9.1). In the commit message or as a comment? Regardless, I

[PATCH v2 2/2] sched/debug: intruduce task_state_to_char helper function

Now we have more than one place to get the task state, so intruduce task_state_to_char helper to save some code. No function changed. Signed-off-by: Xie XiuQi --- include/linux/sched.h | 13 + kernel/sched/core.c | 15 --- kernel/sched/debug.c |

[PATCH v2 2/2] sched/debug: intruduce task_state_to_char helper function

Now we have more than one place to get the task state, so intruduce task_state_to_char helper to save some code. No function changed. Signed-off-by: Xie XiuQi --- include/linux/sched.h | 13 + kernel/sched/core.c | 15 --- kernel/sched/debug.c | 10 +++--- 3

[PATCH v2 0/2] sched/debug: show task state on /proc/sched_debug

Currently, we print the runnable task in /proc/sched_debug, but there is no task state information. We don't know which task is in runqueue, and which task is in sleep. For the convenience of debugging, in this patch, we add task state in runnable task list, like this: runnable tasks: S

[PATCH v2 1/2] sched/debug: show task state on /proc/sched_debug

Currently, we print the runnable task in /proc/sched_debug, but there is no task state information. We don't know which task is in runqueue, and which task is in sleep. For the convenience of debugging, in this patch, we add task state in runnable task list, like this: runnable tasks: S

[PATCH v2 0/2] sched/debug: show task state on /proc/sched_debug

Currently, we print the runnable task in /proc/sched_debug, but there is no task state information. We don't know which task is in runqueue, and which task is in sleep. For the convenience of debugging, in this patch, we add task state in runnable task list, like this: runnable tasks: S

[PATCH v2 1/2] sched/debug: show task state on /proc/sched_debug

Currently, we print the runnable task in /proc/sched_debug, but there is no task state information. We don't know which task is in runqueue, and which task is in sleep. For the convenience of debugging, in this patch, we add task state in runnable task list, like this: runnable tasks: S

Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression

On 08/08, Minchan Kim wrote: >On Mon, Aug 07, 2017 at 10:51:00PM -0700, Nadav Amit wrote: >> Nadav Amit wrote: >> >> > Minchan Kim wrote: >> > >> >> Hi, >> >> >> >> On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote: >> >>> Greeting, >>

Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression

On 08/08, Minchan Kim wrote: >On Mon, Aug 07, 2017 at 10:51:00PM -0700, Nadav Amit wrote: >> Nadav Amit wrote: >> >> > Minchan Kim wrote: >> > >> >> Hi, >> >> >> >> On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote: >> >>> Greeting, >> >>> >> >>> FYI, we noticed a -19.3%

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

Hi all, On Mon, 31 Jul 2017 15:02:27 +1000 Stephen Rothwell wrote: > > After merging the staging tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/staging/media/atomisp/i2c/imx/imx.c:1087:12: warning: > 'imx_vcm_power_up' defined

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

Hi all, On Mon, 31 Jul 2017 15:02:27 +1000 Stephen Rothwell wrote: > > After merging the staging tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/staging/media/atomisp/i2c/imx/imx.c:1087:12: warning: > 'imx_vcm_power_up' defined but not used

Re: [PATCH 2/2] sched/debug: intruduce task_state_to_char helper function

drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Xie-XiuQi/sched-debug-show-task-state-on-proc-sched_debug/20170808-135825 > config: i386-randconfig-x019-201732 (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160

Re: [PATCH 2/2] sched/debug: intruduce task_state_to_char helper function

drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Xie-XiuQi/sched-debug-show-task-state-on-proc-sched_debug/20170808-135825 > config: i386-randconfig-x019-201732 (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160

Re: [PATCH net-next] net: dsa: lan9303: Only allocate 3 ports

From: Egil Hjelmeland Date: Tue, 8 Aug 2017 00:22:21 +0200 > Save 2628 bytes on arm eabi by allocate only the required 3 ports. > > Now that ds->num_ports is correct: In net/dsa/tag_lan9303.c > eliminate duplicate LAN9303_MAX_PORTS, use ds->num_ports. > (Matching the

Re: [PATCH net-next] net: dsa: lan9303: Only allocate 3 ports

From: Egil Hjelmeland Date: Tue, 8 Aug 2017 00:22:21 +0200 > Save 2628 bytes on arm eabi by allocate only the required 3 ports. > > Now that ds->num_ports is correct: In net/dsa/tag_lan9303.c > eliminate duplicate LAN9303_MAX_PORTS, use ds->num_ports. > (Matching the pattern of other

Re: [PATCH 1/1] f2fs: merge equivalent flags F2FS_GET_BLOCK_[READ|DIO]

On 2017/8/8 19:41, Sun Qiuyang wrote: > > >> On 2017/8/8 18:27, sunqiuyang wrote: >>> From: Qiuyang Sun >>> >>> Currently, the two flags F2FS_GET_BLOCK_[READ|DIO] are totally equivalent >>> and can be used interchangably in all scenarios they are involved in. This >>>

Re: [PATCH 1/1] f2fs: merge equivalent flags F2FS_GET_BLOCK_[READ|DIO]

On 2017/8/8 19:41, Sun Qiuyang wrote: > > >> On 2017/8/8 18:27, sunqiuyang wrote: >>> From: Qiuyang Sun >>> >>> Currently, the two flags F2FS_GET_BLOCK_[READ|DIO] are totally equivalent >>> and can be used interchangably in all scenarios they are involved in. This >>> patch deletes

Re: [PATCH net-next v2 1/2] bpf: Move check_uarg_tail_zero() upward

From: Mickaël Salaün Date: Mon, 7 Aug 2017 20:45:19 +0200 > The function check_uarg_tail_zero() may be useful for other part of the > code in the syscall.c file. Move this function at the beginning of the > file. > > Signed-off-by: Mickaël Salaün >

Re: [PATCH net-next v2 1/2] bpf: Move check_uarg_tail_zero() upward

From: Mickaël Salaün Date: Mon, 7 Aug 2017 20:45:19 +0200 > The function check_uarg_tail_zero() may be useful for other part of the > code in the syscall.c file. Move this function at the beginning of the > file. > > Signed-off-by: Mickaël Salaün > Acked-by: Daniel Borkmann Applied.

Re: [PATCH net-next v2 2/2] bpf: Extend check_uarg_tail_zero() checks

From: Mickaël Salaün Date: Mon, 7 Aug 2017 20:45:20 +0200 > The function check_uarg_tail_zero() was created from bpf(2) for > BPF_OBJ_GET_INFO_BY_FD without taking the access_ok() nor the PAGE_SIZE > checks. Make this checks more generally available while unlikely to be >

Re: [PATCH net-next v2 2/2] bpf: Extend check_uarg_tail_zero() checks

From: Mickaël Salaün Date: Mon, 7 Aug 2017 20:45:20 +0200 > The function check_uarg_tail_zero() was created from bpf(2) for > BPF_OBJ_GET_INFO_BY_FD without taking the access_ok() nor the PAGE_SIZE > checks. Make this checks more generally available while unlikely to be > triggered, extend the

Re: [PATCH] net: dsa: mediatek: add adjust link support for user ports

From: John Crispin Date: Mon, 7 Aug 2017 16:20:49 +0200 > Manually adjust the port settings of user ports once PHY polling has > completed. This patch extends the adjust_link callback to configure the > per port PMCR register, applying the proper values polled from the PHY. >

Re: [PATCH] net: dsa: mediatek: add adjust link support for user ports

From: John Crispin Date: Mon, 7 Aug 2017 16:20:49 +0200 > Manually adjust the port settings of user ports once PHY polling has > completed. This patch extends the adjust_link callback to configure the > per port PMCR register, applying the proper values polled from the PHY. > Without this patch

Re: [regression] wake on lan no longer works in 4.13-rc3. was Re: Linux 4.13: Reported regressions as of Sunday, 2017-08-06

On Tuesday, August 8, 2017 11:00:53 AM CEST Pavel Machek wrote: > Hi! > > Perhaps you should get regressi...@kernel.org alias, or something like that? > > > As always: Are you aware of any other regressions? Then please let me > > know. For details see http://bit.ly/lnxregtrackid And please tell

Re: [regression] wake on lan no longer works in 4.13-rc3. was Re: Linux 4.13: Reported regressions as of Sunday, 2017-08-06

On Tuesday, August 8, 2017 11:00:53 AM CEST Pavel Machek wrote: > Hi! > > Perhaps you should get regressi...@kernel.org alias, or something like that? > > > As always: Are you aware of any other regressions? Then please let me > > know. For details see http://bit.ly/lnxregtrackid And please tell

Re: [PATCH] acpi: apei: fix GHES estatus iteration

On Tuesday, August 8, 2017 6:32:20 PM CEST Will Deacon wrote: > On Thu, Aug 03, 2017 at 03:32:25PM -0600, Tyler Baicar wrote: > > Currently iterating through the GHES estatus blocks does not > > take into account the new generic data v3 structure size. This > > can result in garbage non-standard

Re: [PATCH] acpi: apei: fix GHES estatus iteration

On Tuesday, August 8, 2017 6:32:20 PM CEST Will Deacon wrote: > On Thu, Aug 03, 2017 at 03:32:25PM -0600, Tyler Baicar wrote: > > Currently iterating through the GHES estatus blocks does not > > take into account the new generic data v3 structure size. This > > can result in garbage non-standard

Re: [PATCH] KVM: X86: expand ->arch.apic_arb_prio to u64

On 2017/8/8 21:57, Paolo Bonzini wrote: > On 08/08/2017 15:50, Longpeng (Mike) wrote: >> >> >> On 2017/8/8 21:08, Paolo Bonzini wrote: >> >>> On 08/08/2017 13:37, Longpeng(Mike) wrote: Currently 'apic_arb_prio' is int32_t, it's too short for long time running. In our environment, it

Re: [PATCH] KVM: X86: expand ->arch.apic_arb_prio to u64

On 2017/8/8 21:57, Paolo Bonzini wrote: > On 08/08/2017 15:50, Longpeng (Mike) wrote: >> >> >> On 2017/8/8 21:08, Paolo Bonzini wrote: >> >>> On 08/08/2017 13:37, Longpeng(Mike) wrote: Currently 'apic_arb_prio' is int32_t, it's too short for long time running. In our environment, it

[PATCH V9 2/2] PCI: display not responding message while device is unreachable

Adding a print statement into pci_bus_read_dev_vendor_id() so that user observes the progress of device polling instead of silently waiting for timeout to be reached. Signed-off-by: Sinan Kaya --- drivers/pci/probe.c | 8 +++- 1 file changed, 7 insertions(+), 1

[PATCH V9 2/2] PCI: display not responding message while device is unreachable

Adding a print statement into pci_bus_read_dev_vendor_id() so that user observes the progress of device polling instead of silently waiting for timeout to be reached. Signed-off-by: Sinan Kaya --- drivers/pci/probe.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

[PATCH V9 1/2] PCI: handle CRS returned by device after FLR

Sporadic reset issues have been observed with Intel 750 NVMe drive by writing to the reset file in sysfs in a loop. The sequence of events observed is as follows: - perform a Function Level Reset (FLR) - sleep up to 1000ms total - read ~0 from PCI_COMMAND - warn that the device didn't return from

[PATCH V9 1/2] PCI: handle CRS returned by device after FLR

Sporadic reset issues have been observed with Intel 750 NVMe drive by writing to the reset file in sysfs in a loop. The sequence of events observed is as follows: - perform a Function Level Reset (FLR) - sleep up to 1000ms total - read ~0 from PCI_COMMAND - warn that the device didn't return from

<    1   2   3   4   5   6   7   8   9   10   >