Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 18/04/17 02:04 PM, Ilia Mirkin wrote: > On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: >> On 17/04/17 03:43 PM, Ilia Mirkin wrote: >>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: > However, I totally agree with Alex that someone

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 18/04/17 02:04 PM, Ilia Mirkin wrote: > On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: >> On 17/04/17 03:43 PM, Ilia Mirkin wrote: >>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: > However, I totally agree with Alex that someone with a BE machine > should review the

Re: [PATCH v2 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board

On 17.04.2017 08:02, Hoegeun Kwon wrote: > This patch supports TM2e panel and the panel has 1600x2560 resolution > in 5.65" physical. > > This identify panel type with compatibility string, also invoke > display mode that matches the type. So add the check code for s6e3ha2 > compatibility and

Re: [PATCH v2 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board

On 17.04.2017 08:02, Hoegeun Kwon wrote: > This patch supports TM2e panel and the panel has 1600x2560 resolution > in 5.65" physical. > > This identify panel type with compatibility string, also invoke > display mode that matches the type. So add the check code for s6e3ha2 > compatibility and

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

On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote: > Hi Greg, > > After merging the staging tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > make[7]: *** No rule to make target >

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

On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote: > Hi Greg, > > After merging the staging tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > make[7]: *** No rule to make target >

linux-next: build failure after merge of the staging tree

Hi all, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .change_virtual_intf =

linux-next: build failure after merge of the staging tree

Hi all, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .change_virtual_intf =

Re: [PATCH v2 1/3] dt-bindings: Add support for samsung s6e3hf2 panel

On 17.04.2017 08:02, Hoegeun Kwon wrote: > The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected > using MIPI-DSI interfaces. > > The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a > panel similar to the s6e3ha2. So add the compatible string and > comments. > >

Re: [PATCH v2 1/3] dt-bindings: Add support for samsung s6e3hf2 panel

On 17.04.2017 08:02, Hoegeun Kwon wrote: > The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected > using MIPI-DSI interfaces. > > The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a > panel similar to the s6e3ha2. So add the compatible string and > comments. > >

Linux 3.12.73

I'm announcing the release of the 3.12.73 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web

Linux 3.12.73

I'm announcing the release of the 3.12.73 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area during boot process and those virtually mapped areas are never unmapped. So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing existing vmlist entries and prevent those areas from being removed from the

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area during boot process and those virtually mapped areas are never unmapped. So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing existing vmlist entries and prevent those areas from being removed from the

Re: [PATCH] powerpc/mm: some cleanup of do_page_fault()

Christophe Leroy writes: > This patch is a bunch of small cleanups of the do_page_fault() > function: > 1/ Function store_updates_sp() checks whether the faulting > instruction is a store updating r1. Therefore we can limit its calls > to stores exceptions > 2/ Only the

Re: [PATCH] powerpc/mm: some cleanup of do_page_fault()

Christophe Leroy writes: > This patch is a bunch of small cleanups of the do_page_fault() > function: > 1/ Function store_updates_sp() checks whether the faulting > instruction is a store updating r1. Therefore we can limit its calls > to stores exceptions > 2/ Only the get_user() in

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote: > Is it ? Again, you create a "concept" the user may have no idea about, > "p2pmem memory". So now any kind of memory buffer on a device can could > be use for p2p but also potentially a bunch of other things becomes > special and called

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote: > Is it ? Again, you create a "concept" the user may have no idea about, > "p2pmem memory". So now any kind of memory buffer on a device can could > be use for p2p but also potentially a bunch of other things becomes > special and called

Re: [PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64

On Mon, Apr 17, 2017 at 07:57:36PM +0800, Icenowy Zheng wrote: > Allwinner A64 have a RSB controller like the one on A23/A33 SoCs. > > Add it and its pinmux. > > Signed-off-by: Icenowy Zheng > Acked-by: Chen-Yu Tsai Applied, thanks! Maxime -- Maxime Ripard,

Re: [PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64

On Mon, Apr 17, 2017 at 07:57:36PM +0800, Icenowy Zheng wrote: > Allwinner A64 have a RSB controller like the one on A23/A33 SoCs. > > Add it and its pinmux. > > Signed-off-by: Icenowy Zheng > Acked-by: Chen-Yu Tsai Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and

Re: [PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU

On Mon, Apr 17, 2017 at 06:34:49PM +0800, Icenowy Zheng wrote: > The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible. > > Fix it by changing it to the correct H3 compatible. > > Signed-off-by: Icenowy Zheng Applied, thanks Maxime -- Maxime Ripard, Free Electrons

Re: [PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU

On Mon, Apr 17, 2017 at 06:34:49PM +0800, Icenowy Zheng wrote: > The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible. > > Fix it by changing it to the correct H3 compatible. > > Signed-off-by: Icenowy Zheng Applied, thanks Maxime -- Maxime Ripard, Free Electrons Embedded Linux

Re: [PATCH] arm64: dts: allwinner: pine64: Add remaining UART aliases

On Fri, Apr 14, 2017 at 09:08:04PM +0200, Andreas Färber wrote: > Enabling uart2 node currently leads to a /dev/ttyS1 device, with ttyS0..4 > always present, causing confusion on the user's part. > > dtc cannot resolve an overlay's reference for strings, only for > phandles, so it would need to

Re: [PATCH] arm64: dts: allwinner: pine64: Add remaining UART aliases

On Fri, Apr 14, 2017 at 09:08:04PM +0200, Andreas Färber wrote: > Enabling uart2 node currently leads to a /dev/ttyS1 device, with ttyS0..4 > always present, causing confusion on the user's part. > > dtc cannot resolve an overlay's reference for strings, only for > phandles, so it would need to

Re: [PATCH] arm64: dts: allwinner: a64: Add UART2 pin nodes

On Fri, Apr 14, 2017 at 07:13:20PM +0200, Andreas Färber wrote: > UART2 is exposed on the Pi connector of Pine64. Make a pinctrl node > available at the SoC level, to simplify enabling UART2 via DT overlay. > > Signed-off-by: Andreas Färber Applied, thanks! Could you also

Re: [PATCH] arm64: dts: allwinner: a64: Add UART2 pin nodes

On Fri, Apr 14, 2017 at 07:13:20PM +0200, Andreas Färber wrote: > UART2 is exposed on the Pi connector of Pine64. Make a pinctrl node > available at the SoC level, to simplify enabling UART2 via DT overlay. > > Signed-off-by: Andreas Färber Applied, thanks! Could you also create the node in

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: make[7]: *** No rule to make target 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o', needed by

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: make[7]: *** No rule to make target 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o', needed by

[PATCH V3] mm/madvise: Move up the behavior parameter validation

The madvise_behavior_valid() function should be called before acting upon the behavior parameter. Hence move up the function. This also includes MADV_SOFT_OFFLINE and MADV_HWPOISON options as valid behavior parameter for the system call madvise(). Signed-off-by: Anshuman Khandual

[PATCH V3] mm/madvise: Move up the behavior parameter validation

The madvise_behavior_valid() function should be called before acting upon the behavior parameter. Hence move up the function. This also includes MADV_SOFT_OFFLINE and MADV_HWPOISON options as valid behavior parameter for the system call madvise(). Signed-off-by: Anshuman Khandual --- Changes in

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 11:04 AM, Dan Williams wrote: >> Yes, in this scheme, it needs an additional p2pmem child. Why is that an >> issue? It certainly makes it a lot easier for the user to understand the >> p2pmem memory in the system (through the sysfs tree) and reason about >> the topology and when to

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 11:04 AM, Dan Williams wrote: >> Yes, in this scheme, it needs an additional p2pmem child. Why is that an >> issue? It certainly makes it a lot easier for the user to understand the >> p2pmem memory in the system (through the sysfs tree) and reason about >> the topology and when to

[PATCH] RTC: Add functionality to read/write rtc scratch registers

From: Russ Dill Many RTCs provide scratch registers that are maintained so long as the RTC has power. Provide a generic method to access these registers. Signed-off-by: Russ Dill Signed-off-by: Keerthy --- drivers/rtc/interface.c | 50

[PATCH] RTC: Add functionality to read/write rtc scratch registers

From: Russ Dill Many RTCs provide scratch registers that are maintained so long as the RTC has power. Provide a generic method to access these registers. Signed-off-by: Russ Dill Signed-off-by: Keerthy --- drivers/rtc/interface.c | 50 +

[PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

This patch adds a quirk to disable USB 2.0 MAC linestate check during HS transmit. Refer the dwc3 databook, we can use it for some special platforms if the linestate not reflect the expected line state(J) during transmission. When use this quirk, the controller implements a fixed 40-bit

[PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

This patch adds a quirk to disable USB 2.0 MAC linestate check during HS transmit. Refer the dwc3 databook, we can use it for some special platforms if the linestate not reflect the expected line state(J) during transmission. When use this quirk, the controller implements a fixed 40-bit

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

On 17-04-17, 18:40, Rafael J. Wysocki wrote: > On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote: > > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote: > > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki : > > > > On Monday, April 10, 2017 02:51:35 PM

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

On 17-04-17, 18:40, Rafael J. Wysocki wrote: > On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote: > > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote: > > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki : > > > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote: > > >

[PATCH V3] PM / OPP: Use - instead of @ for DT entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

[PATCH V3] PM / OPP: Use - instead of @ for DT entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

[PATCH] clk: Add functions to save and restore clock/dpll context en-masse

From: Russ Dill The clock/dpll registers are in the WKUP power domain. Under both RTC-only suspend and hibernation, these registers are lost. Hence save/restore them accordingly. Signed-off-by: Russ Dill Signed-off-by: Keerthy ---

[PATCH] clk: Add functions to save and restore clock/dpll context en-masse

From: Russ Dill The clock/dpll registers are in the WKUP power domain. Under both RTC-only suspend and hibernation, these registers are lost. Hence save/restore them accordingly. Signed-off-by: Russ Dill Signed-off-by: Keerthy --- drivers/clk/clk.c| 70

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: > On 17/04/17 03:43 PM, Ilia Mirkin wrote: >> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: However, I totally agree with Alex that someone with a BE machine should review the whole

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: > On 17/04/17 03:43 PM, Ilia Mirkin wrote: >> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: However, I totally agree with Alex that someone with a BE machine should review the whole stack before we could be confident with

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

Hi Huang, On Fri, Apr 07, 2017 at 02:49:01PM +0800, Huang, Ying wrote: > From: Huang Ying > > To reduce the lock contention of swap_info_struct->lock when freeing > swap entry. The freed swap entries will be collected in a per-CPU > buffer firstly, and be really freed

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

Hi Huang, On Fri, Apr 07, 2017 at 02:49:01PM +0800, Huang, Ying wrote: > From: Huang Ying > > To reduce the lock contention of swap_info_struct->lock when freeing > swap entry. The freed swap entries will be collected in a per-CPU > buffer firstly, and be really freed later in batch. During

Re: [PATCH 4.10 00/29] 4.10.11-stable review

On Mon, Apr 17, 2017 at 12:25:38PM -0600, Shuah Khan wrote: > On 04/16/2017 02:04 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.11 release. > > There are 29 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.10 00/29] 4.10.11-stable review

On Mon, Apr 17, 2017 at 12:25:38PM -0600, Shuah Khan wrote: > On 04/16/2017 02:04 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.11 release. > > There are 29 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 3.18 000/145] 3.18.49-stable review

On Mon, Apr 17, 2017 at 12:18:19PM -0600, Shuah Khan wrote: > On 04/16/2017 04:48 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.49 release. > > There are 145 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 3.18 000/145] 3.18.49-stable review

On Mon, Apr 17, 2017 at 12:18:19PM -0600, Shuah Khan wrote: > On 04/16/2017 04:48 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.49 release. > > There are 145 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf

On Mon, Apr 17, 2017 at 05:00:50PM -0300, Marcelo Ricardo Leitner wrote: > > > Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu: > > 3.18-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Marcelo Ricardo Leitner

Re: [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf

On Mon, Apr 17, 2017 at 05:00:50PM -0300, Marcelo Ricardo Leitner wrote: > > > Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu: > > 3.18-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Marcelo Ricardo Leitner > > > > > > [

Re: [PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

On Tue, Apr 18, 2017 at 06:14:11AM +0200, Greg KH wrote: > On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote: > > Swap string in the dev_warn() call with __func__ argument, instead of > > explicitly calling the function name in the string: > > > > WARNING: Prefer using "%s",

Re: [PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

On Tue, Apr 18, 2017 at 06:14:11AM +0200, Greg KH wrote: > On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote: > > Swap string in the dev_warn() call with __func__ argument, instead of > > explicitly calling the function name in the string: > > > > WARNING: Prefer using "%s",

Re: [PATCH] ACPICA: Export mutex functions

On 04/17/2017 04:53 PM, Zheng, Lv wrote: Hi, From: Guenter Roeck [mailto:li...@roeck-us.net] Subject: Re: [PATCH] ACPICA: Export mutex functions On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote: On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck wrote: On

Re: [PATCH] ACPICA: Export mutex functions

On 04/17/2017 04:53 PM, Zheng, Lv wrote: Hi, From: Guenter Roeck [mailto:li...@roeck-us.net] Subject: Re: [PATCH] ACPICA: Export mutex functions On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote: On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck wrote: On Mon, Apr 17, 2017 at

[PATCH v6 1/2] thermal: core: Allow orderly_poweroff to be called only once

thermal_zone_device_check --> thermal_zone_device_update --> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff The above sequence happens every 250/500 mS based on the configuration. The orderly_poweroff function is getting called every 250/500 mS. With a full fledged file system

[PATCH v6 1/2] thermal: core: Allow orderly_poweroff to be called only once

thermal_zone_device_check --> thermal_zone_device_update --> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff The above sequence happens every 250/500 mS based on the configuration. The orderly_poweroff function is getting called every 250/500 mS. With a full fledged file system

[PATCH v6 2/2] thermal: core: Add a back up thermal shutdown mechanism

orderly_poweroff is triggered when a graceful shutdown of system is desired. This may be used in many critical states of the kernel such as when subsystems detects conditions such as critical temperature conditions. However, in certain conditions in system boot up sequences like those in the

[PATCH v6 2/2] thermal: core: Add a back up thermal shutdown mechanism

orderly_poweroff is triggered when a graceful shutdown of system is desired. This may be used in many critical states of the kernel such as when subsystems detects conditions such as critical temperature conditions. However, in certain conditions in system boot up sequences like those in the

Re: [PATCH 2/2 v2] char: misc: use octal permissions for the proc entry

On Mon, Apr 17, 2017 at 08:22:57PM +0200, Martin Kaiser wrote: > Set the permissions for /proc/misc to 0444 explicitly. At the moment, > we're using 0 and have proc_create_data() convert this to 0444. > This fixes a checkpatch warning. > > Signed-off-by: Martin Kaiser > --- >

Re: [PATCH 2/2 v2] char: misc: use octal permissions for the proc entry

On Mon, Apr 17, 2017 at 08:22:57PM +0200, Martin Kaiser wrote: > Set the permissions for /proc/misc to 0444 explicitly. At the moment, > we're using 0 and have proc_create_data() convert this to 0444. > This fixes a checkpatch warning. > > Signed-off-by: Martin Kaiser > --- > v2: >separate

Re: [PATCH 1/4] added SECURITY_TIOCSTI_RESTRICT kernel config

On 04/17/2017 02:50 AM, Greg KH wrote: On Mon, Apr 17, 2017 at 02:07:03AM -0400, Matt Brown wrote: adding the kernel config SECURITY_TIOCSTI_RESTRICT in order to allow the user to restrict unprivileged command injection using TIOCSTI tty ioctls "unpriviledged command injection"? That sounds

Re: [PATCH 1/4] added SECURITY_TIOCSTI_RESTRICT kernel config

On 04/17/2017 02:50 AM, Greg KH wrote: On Mon, Apr 17, 2017 at 02:07:03AM -0400, Matt Brown wrote: adding the kernel config SECURITY_TIOCSTI_RESTRICT in order to allow the user to restrict unprivileged command injection using TIOCSTI tty ioctls "unpriviledged command injection"? That sounds

Re: [PATCH v5 0/3] vfio/type1: Synchronous locked page accounting

On Mon, Apr 17, 2017 at 04:37:38PM -0600, Alex Williamson wrote: > v5: > - patch 1/ Use bool* to cleanup vfio_lock_acct() callers; sorry > we cannot re-test CAP_IPC_LOCK for all callers > - patch 2/ Re-add pr_warn, add Kirti's R-b > - patch 3/ NEW, analyzing impact of

Re: [PATCH v5 0/3] vfio/type1: Synchronous locked page accounting

On Mon, Apr 17, 2017 at 04:37:38PM -0600, Alex Williamson wrote: > v5: > - patch 1/ Use bool* to cleanup vfio_lock_acct() callers; sorry > we cannot re-test CAP_IPC_LOCK for all callers > - patch 2/ Re-add pr_warn, add Kirti's R-b > - patch 3/ NEW, analyzing impact of

Re: [PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote: > Swap string in the dev_warn() call with __func__ argument, instead of > explicitly calling the function name in the string: > > WARNING: Prefer using "%s", __func__ to embedded function names > #417: FILE:

Re: [PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote: > Swap string in the dev_warn() call with __func__ argument, instead of > explicitly calling the function name in the string: > > WARNING: Prefer using "%s", __func__ to embedded function names > #417: FILE:

Re: [PATCH v5 2/2] thermal: core: Add a back up thermal shutdown mechanism

On Monday 17 April 2017 10:46 PM, Eduardo Valentin wrote: > On Sat, Apr 15, 2017 at 08:38:29AM +0530, Keerthy wrote: >> orderly_poweroff is triggered when a graceful shutdown >> of system is desired. This may be used in many critical states of the >> kernel such as when subsystems detects

Re: [PATCH v5 2/2] thermal: core: Add a back up thermal shutdown mechanism

On Monday 17 April 2017 10:46 PM, Eduardo Valentin wrote: > On Sat, Apr 15, 2017 at 08:38:29AM +0530, Keerthy wrote: >> orderly_poweroff is triggered when a graceful shutdown >> of system is desired. This may be used in many critical states of the >> kernel such as when subsystems detects

Re: [PATCH v2] efi: Config options to assign versions in the PE-COFF header

On Mon, Apr 17, 2017 at 11:09:38AM -0700, Roy Franz (HPE) wrote: > On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin wrote: > > On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote: > >> On 13 April 2017 at 04:58, Gary Lin wrote: > >> > This commit adds the new

Re: [PATCH v2] efi: Config options to assign versions in the PE-COFF header

On Mon, Apr 17, 2017 at 11:09:38AM -0700, Roy Franz (HPE) wrote: > On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin wrote: > > On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote: > >> On 13 April 2017 at 04:58, Gary Lin wrote: > >> > This commit adds the new config options to allow the

Re: cgroup: avoid attaching a cgroup root to two different superblocks

On Mon, Apr 17, 2017 at 06:41:38PM +0800, Zefan Li wrote: > On 2017/4/15 7:32, Andrei Vagin wrote: > > On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote: > >> Hello, > >> > >> One of our CRIU tests hangs with this patch. > >> > >> Steps to reproduce: > >> curl -o cgroupns.c > >>

Re: cgroup: avoid attaching a cgroup root to two different superblocks

On Mon, Apr 17, 2017 at 06:41:38PM +0800, Zefan Li wrote: > On 2017/4/15 7:32, Andrei Vagin wrote: > > On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote: > >> Hello, > >> > >> One of our CRIU tests hangs with this patch. > >> > >> Steps to reproduce: > >> curl -o cgroupns.c > >>

[PATCH] usb: dwc3: add disable u2mac linestate check quirk

This patch adds a quirk to disable USB 2.0 MAC linestate check during HS transmit. Refer the dwc3 databook, we can use it for some special platforms if the linestate not reflect the expected line state(J) during transmission. When use this quirk, the controller implements a fixed 40-bit

[PATCH] usb: dwc3: add disable u2mac linestate check quirk

This patch adds a quirk to disable USB 2.0 MAC linestate check during HS transmit. Refer the dwc3 databook, we can use it for some special platforms if the linestate not reflect the expected line state(J) during transmission. When use this quirk, the controller implements a fixed 40-bit

[PATCH] Input: xpad - do not suggest writing to Dominic

Do not recommend people write to Dominic, rather everyone should be using linux-input mailing list. Signed-off-by: Dmitry Torokhov --- Documentation/input/devices/xpad.rst | 6 -- 1 file changed, 6 deletions(-) diff --git a/Documentation/input/devices/xpad.rst

[PATCH] Input: xpad - do not suggest writing to Dominic

Do not recommend people write to Dominic, rather everyone should be using linux-input mailing list. Signed-off-by: Dmitry Torokhov --- Documentation/input/devices/xpad.rst | 6 -- 1 file changed, 6 deletions(-) diff --git a/Documentation/input/devices/xpad.rst

Re: [PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

kbuild test robot writes: > Hi Aneesh, > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.11-rc7 next-20170413] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

kbuild test robot writes: > Hi Aneesh, > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.11-rc7 next-20170413] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH] usb: Make sure usb/phy/of gets built-in

On 04/13/17 05:33, Alexey Brodkin wrote: > DWC3 driver uses of_usb_get_phy_mode() which is > implemented in drivers/usb/phy/of.c and in bare minimal > configuration it might not be pulled in kernel binary. > > In case of ARC or ARM this could be easily reproduced with > "allnodefconfig"

Re: [PATCH] usb: Make sure usb/phy/of gets built-in

On 04/13/17 05:33, Alexey Brodkin wrote: > DWC3 driver uses of_usb_get_phy_mode() which is > implemented in drivers/usb/phy/of.c and in bare minimal > configuration it might not be pulled in kernel binary. > > In case of ARC or ARM this could be easily reproduced with > "allnodefconfig"

Re: [PATCH 2/4] input: xpad.rst: Don't use literal blocks inside footnotes

On Mon, Apr 17, 2017 at 09:46:14AM -0300, Mauro Carvalho Chehab wrote: > Unfortunately, Sphinx (or LaTeX) can't handle literal blocks > inside footnotes. So, just use normal text for the two > literal code-blocks that documents the output of > /sys/kernel/debug/usb/devices for xpad devices. > >

Re: [PATCH 2/4] input: xpad.rst: Don't use literal blocks inside footnotes

On Mon, Apr 17, 2017 at 09:46:14AM -0300, Mauro Carvalho Chehab wrote: > Unfortunately, Sphinx (or LaTeX) can't handle literal blocks > inside footnotes. So, just use normal text for the two > literal code-blocks that documents the output of > /sys/kernel/debug/usb/devices for xpad devices. > >

Re: [PATCH 1/4] input: xpad.rst: usb/devices is now at /sys/kernel/debug/

On Mon, Apr 17, 2017 at 09:46:13AM -0300, Mauro Carvalho Chehab wrote: > The /proc/bus/usb/devices got moved to sysfs. It is now > sitting at: > /sys/kernel/debug/usb/devices > > Signed-off-by: Mauro Carvalho Chehab Applied, thank you. > --- >

Re: [PATCH 1/4] input: xpad.rst: usb/devices is now at /sys/kernel/debug/

On Mon, Apr 17, 2017 at 09:46:13AM -0300, Mauro Carvalho Chehab wrote: > The /proc/bus/usb/devices got moved to sysfs. It is now > sitting at: > /sys/kernel/debug/usb/devices > > Signed-off-by: Mauro Carvalho Chehab Applied, thank you. > --- >

Re: [PATCH 3/4] input: xpad.rst: proc/bus/usb was renamed to dev/bus/usb

Hi Mauro, On Mon, Apr 17, 2017 at 09:46:15AM -0300, Mauro Carvalho Chehab wrote: > xpad.rst requests a dump of the USB description, as found > on the USB character device. When we got rid of usbfs, > its location change. Update it. I have not heard from Dom ever so I think the best option is to

Re: [PATCH 3/4] input: xpad.rst: proc/bus/usb was renamed to dev/bus/usb

Hi Mauro, On Mon, Apr 17, 2017 at 09:46:15AM -0300, Mauro Carvalho Chehab wrote: > xpad.rst requests a dump of the USB description, as found > on the USB character device. When we got rid of usbfs, > its location change. Update it. I have not heard from Dom ever so I think the best option is to

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

On 2017年04月17日 07:19, Michael S. Tsirkin wrote: Applications that consume a batch of entries in one go can benefit from ability to return some of them back into the ring. Add an API for that - assuming there's space. If there's no space naturally we can't do this and have to drop entries, but

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

On 2017年04月17日 07:19, Michael S. Tsirkin wrote: Applications that consume a batch of entries in one go can benefit from ability to return some of them back into the ring. Add an API for that - assuming there's space. If there's no space naturally we can't do this and have to drop entries, but

linux-next: build failure after merge of the block tree

Hi all, After merging the block tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/block/nbd.c: In function 'nbd_genl_connect': drivers/block/nbd.c:1662:10: error: too few arguments to function 'nla_parse_nested' ret = nla_parse_nested(socks, NBD_SOCK_MAX,

linux-next: build failure after merge of the block tree

Hi all, After merging the block tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/block/nbd.c: In function 'nbd_genl_connect': drivers/block/nbd.c:1662:10: error: too few arguments to function 'nla_parse_nested' ret = nla_parse_nested(socks, NBD_SOCK_MAX,

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

On Mon, Apr 17, 2017 at 03:32:20PM -0600, Alex Williamson wrote: > On Tue, 18 Apr 2017 01:02:12 +0530 > Kirti Wankhede wrote: > > > On 4/18/2017 12:49 AM, Alex Williamson wrote: > > > On Tue, 18 Apr 2017 00:35:06 +0530 > > > Kirti Wankhede wrote: > >

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

On Mon, Apr 17, 2017 at 03:32:20PM -0600, Alex Williamson wrote: > On Tue, 18 Apr 2017 01:02:12 +0530 > Kirti Wankhede wrote: > > > On 4/18/2017 12:49 AM, Alex Williamson wrote: > > > On Tue, 18 Apr 2017 00:35:06 +0530 > > > Kirti Wankhede wrote: > > > > > >> On 4/17/2017 8:02 PM, Alex

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 17/04/17 03:43 PM, Ilia Mirkin wrote: > On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: >>> However, I totally agree with Alex that someone with a BE machine >>> should review the whole stack before we could be confident with anything. >> >> Here's what I'm confident

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 17/04/17 03:43 PM, Ilia Mirkin wrote: > On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: >>> However, I totally agree with Alex that someone with a BE machine >>> should review the whole stack before we could be confident with anything. >> >> Here's what I'm confident about:

[RFC] using #pragma push_macro and pop_macro

There is an argument for using these #pragmas for pr_fmt. gcc/clang/icc all support push_macro and pop_macro pragmas. As far as I can tell, these compilers are the only ones used to compile the kernel. Anyone have any objection to using these pragmas? On Tue, 2017-04-18 at 05:02 +0800, kbuild

[RFC] using #pragma push_macro and pop_macro

There is an argument for using these #pragmas for pr_fmt. gcc/clang/icc all support push_macro and pop_macro pragmas. As far as I can tell, these compilers are the only ones used to compile the kernel. Anyone have any objection to using these pragmas? On Tue, 2017-04-18 at 05:02 +0800, kbuild

Re: [PATCH 1/3] zram: fix operator precedence to get offset

On Tue, Apr 18, 2017 at 10:53:10AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (04/18/17 08:53), Minchan Kim wrote: > > On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote: > > > Hello Minchan, > > > > > > On (04/17/17 11:14), Minchan Kim wrote: > > > > On Mon, Apr 17, 2017

Re: [PATCH 1/3] zram: fix operator precedence to get offset

On Tue, Apr 18, 2017 at 10:53:10AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (04/18/17 08:53), Minchan Kim wrote: > > On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote: > > > Hello Minchan, > > > > > > On (04/17/17 11:14), Minchan Kim wrote: > > > > On Mon, Apr 17, 2017

  1   2   3   4   5   6   7   8   9   10   >