Re: ecryptfs: Restore support for both encrypted and unencrypted file names

ping On Tue, Feb 13, 2018 at 02:36:08PM -0800, Guenter Roeck wrote: > Commit 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or > plaintext name") was supposed to fix a situation where two files with > the same name and same inode could be created in ecryptfs. One of those > files had

Re: ecryptfs: Restore support for both encrypted and unencrypted file names

ping On Tue, Feb 13, 2018 at 02:36:08PM -0800, Guenter Roeck wrote: > Commit 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or > plaintext name") was supposed to fix a situation where two files with > the same name and same inode could be created in ecryptfs. One of those > files had

Re: [PATCH] xen/pirq: fix error path cleanup when binding MSIs

On 28/02/18 10:19, Roger Pau Monne wrote: > Current cleanup in the error path of xen_bind_pirq_msi_to_irq is > wrong. First of all there's an off-by-one in the cleanup loop, which > can lead to unbinding wrong IRQs. > > Secondly IRQs not bound won't be freed, thus leaking IRQ numbers. > > Note

Re: [PATCH] xen/pirq: fix error path cleanup when binding MSIs

On 28/02/18 10:19, Roger Pau Monne wrote: > Current cleanup in the error path of xen_bind_pirq_msi_to_irq is > wrong. First of all there's an off-by-one in the cleanup loop, which > can lead to unbinding wrong IRQs. > > Secondly IRQs not bound won't be freed, thus leaking IRQ numbers. > > Note

Re: [PATCH v1 2/4] x86/pci: Re-use new dmi_get_bios_year() helper

On Wed, 28 Feb 2018 11:33:39 +0100, Rafael J. Wysocki wrote: > On Wed, Feb 28, 2018 at 11:29 AM, Andy Shevchenko > wrote: > > I would assume that no BIOS date is related to prehistoric firmwares and > > using _CRS would sound weird on them. > > Careful here.

Re: [PATCH v1 2/4] x86/pci: Re-use new dmi_get_bios_year() helper

On Wed, 28 Feb 2018 11:33:39 +0100, Rafael J. Wysocki wrote: > On Wed, Feb 28, 2018 at 11:29 AM, Andy Shevchenko > wrote: > > I would assume that no BIOS date is related to prehistoric firmwares and > > using _CRS would sound weird on them. > > Careful here. > > You seem to be assuming that

Re: [PATCH] xen-netfront: Fix hang on device removal

On 28/02/18 13:23, Jason Andryuk wrote: > A toolstack may delete the vif frontend and backend xenstore entries > while xen-netfront is in the removal code path. In that case, the > checks for xenbus_read_driver_state would return XenbusStateUnknown, and > xennet_remove would hang indefinitely.

Re: [PATCH] xen-netfront: Fix hang on device removal

On 28/02/18 13:23, Jason Andryuk wrote: > A toolstack may delete the vif frontend and backend xenstore entries > while xen-netfront is in the removal code path. In that case, the > checks for xenbus_read_driver_state would return XenbusStateUnknown, and > xennet_remove would hang indefinitely.

[GIT PULL] xfs: fixes for 4.16-rc4

Hi Linus, Here's the first round of bugfixes for 4.16. It should merge cleanly, but please let me know if it doesn't. --Darrick The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux 4.16-rc1 (2018-02-11 15:04:29 -0800) are available in the git repository at:

[GIT PULL] xfs: fixes for 4.16-rc4

Hi Linus, Here's the first round of bugfixes for 4.16. It should merge cleanly, but please let me know if it doesn't. --Darrick The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux 4.16-rc1 (2018-02-11 15:04:29 -0800) are available in the git repository at:

Re: [PATCH v4 1/4] HID: add driver for Valve Steam Controller

On Wed, Feb 28, 2018 at 8:43 PM, Rodrigo Rivas Costa wrote: > There are two ways to connect the Steam Controller: directly to the USB > or with the USB wireless adapter. Both methods are similar, but the > wireless adapter can connect up to 4 devices at the same

Re: [PATCH v4 1/4] HID: add driver for Valve Steam Controller

On Wed, Feb 28, 2018 at 8:43 PM, Rodrigo Rivas Costa wrote: > There are two ways to connect the Steam Controller: directly to the USB > or with the USB wireless adapter. Both methods are similar, but the > wireless adapter can connect up to 4 devices at the same time. > > The wired device will

Re: [PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

On Mon, Feb 26, 2018 at 03:47:12PM +1100, Stewart Smith wrote: > Akshay Adiga writes: > > commit 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle > > states via stop API.") uses stop-api provided by the firmware to restore > > PSSCR. PSSCR restore

Re: [PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

On Mon, Feb 26, 2018 at 03:47:12PM +1100, Stewart Smith wrote: > Akshay Adiga writes: > > commit 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle > > states via stop API.") uses stop-api provided by the firmware to restore > > PSSCR. PSSCR restore is required for handling special

[RFC PATCH 3/3] tpm: tpm_msleep() with finer granularity improves performance

When 'commit 9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers")' was upstreamed, it replaced the msleep() calls with usleep_range(), but did not change the granularity of the calls. They're still defined in terms of msec. Test results show that refining the

[RFC PATCH 3/3] tpm: tpm_msleep() with finer granularity improves performance

When 'commit 9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers")' was upstreamed, it replaced the msleep() calls with usleep_range(), but did not change the granularity of the calls. They're still defined in terms of msec. Test results show that refining the

[PATCH 2/3] tpm: reduce poll sleep time between send() and recv() in tpm_transmit()

In tpm_transmit, after send(), the code checks for status in a loop with polling every 5msec. It is expected that the tpm might return earlier than 5msec, so it might be adding to unnecessary delay. This patch reduces the polling sleep time from 5msec to 1msec. After this change, performance on

[PATCH 2/3] tpm: reduce poll sleep time between send() and recv() in tpm_transmit()

In tpm_transmit, after send(), the code checks for status in a loop with polling every 5msec. It is expected that the tpm might return earlier than 5msec, so it might be adding to unnecessary delay. This patch reduces the polling sleep time from 5msec to 1msec. After this change, performance on

[PATCH 1/3] tpm: move TPM_POLL_SLEEP from tpm_tis_core.c to tpm.h

This patch moves TPM_POLL_SLEEP from tpm_tis_core.c to tpm.h, renaming it to TPM_TIMEOUT_POLL, to follow the existing enum naming conventions. Signed-off-by: Nayna Jain --- drivers/char/tpm/tpm.h | 3 ++- drivers/char/tpm/tpm_tis_core.c | 10 ++ 2

[PATCH 1/3] tpm: move TPM_POLL_SLEEP from tpm_tis_core.c to tpm.h

This patch moves TPM_POLL_SLEEP from tpm_tis_core.c to tpm.h, renaming it to TPM_TIMEOUT_POLL, to follow the existing enum naming conventions. Signed-off-by: Nayna Jain --- drivers/char/tpm/tpm.h | 3 ++- drivers/char/tpm/tpm_tis_core.c | 10 ++ 2 files changed, 4

[PATCH 3/3] fixdep: do not ignore kconfig.h

kconfig.h was excluded from consideration by fixdep by 6a5be57f0f00 (fixdep: fix extraneous dependencies) to avoid some false positive hits (1) include/config/.h (2) include/config/h.h (3) include/config/foo.h (1) occurred because kconfig.h contains the string CONFIG_ in a comment. However,

[PATCH 3/3] fixdep: do not ignore kconfig.h

kconfig.h was excluded from consideration by fixdep by 6a5be57f0f00 (fixdep: fix extraneous dependencies) to avoid some false positive hits (1) include/config/.h (2) include/config/h.h (3) include/config/foo.h (1) occurred because kconfig.h contains the string CONFIG_ in a comment. However,

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Hi Thomas, On 2/28/2018 10:39 AM, Thomas Gleixner wrote: > On Tue, 27 Feb 2018, Reinette Chatre wrote: >> On 2/27/2018 2:36 AM, Thomas Gleixner wrote: >>> On Mon, 26 Feb 2018, Reinette Chatre wrote: Moving to "exclusive" mode it appears that, when enabled for a resource group, all

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Hi Thomas, On 2/28/2018 10:39 AM, Thomas Gleixner wrote: > On Tue, 27 Feb 2018, Reinette Chatre wrote: >> On 2/27/2018 2:36 AM, Thomas Gleixner wrote: >>> On Mon, 26 Feb 2018, Reinette Chatre wrote: Moving to "exclusive" mode it appears that, when enabled for a resource group, all

[PATCH 1/3] fixdep: remove stale references to uml-config.h

uml-config.h hasn't existed in this decade (87e299e5c750 - x86, um: get rid of uml-config.h). The few remaining UML_CONFIG instances are defined directly in terms of their real CONFIG symbol in common-offsets.h, so unlike when the symbols got defined via a sed script, anything that uses

[PATCH 2/3] fixdep: remove some false CONFIG_ matches

The string CONFIG_ quite often appears after other alphanumerics, meaning that that instance cannot be referencing a Kconfig symbol. Omitting these means make has fewer files to stat() when deciding what needs to be rebuilt - for a defconfig build, this seems to remove about 2% of the (wildcard

[PATCH 1/3] fixdep: remove stale references to uml-config.h

uml-config.h hasn't existed in this decade (87e299e5c750 - x86, um: get rid of uml-config.h). The few remaining UML_CONFIG instances are defined directly in terms of their real CONFIG symbol in common-offsets.h, so unlike when the symbols got defined via a sed script, anything that uses

[PATCH 2/3] fixdep: remove some false CONFIG_ matches

The string CONFIG_ quite often appears after other alphanumerics, meaning that that instance cannot be referencing a Kconfig symbol. Omitting these means make has fewer files to stat() when deciding what needs to be rebuilt - for a defconfig build, this seems to remove about 2% of the (wildcard

Re: [PATCH v1 2/2] drm/panel: Add support for Raydium rm68200 panel driver

On Thu, Feb 08, 2018 at 03:30:26PM +0100, Philippe Cornu wrote: > This patch adds Raydium Semiconductor Corporation rm68200 > 5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode). > > Signed-off-by: Philippe Cornu > --- > drivers/gpu/drm/panel/Kconfig

Re: [PATCH v1 2/2] drm/panel: Add support for Raydium rm68200 panel driver

On Thu, Feb 08, 2018 at 03:30:26PM +0100, Philippe Cornu wrote: > This patch adds Raydium Semiconductor Corporation rm68200 > 5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode). > > Signed-off-by: Philippe Cornu > --- > drivers/gpu/drm/panel/Kconfig | 8 + >

Re: [PATCH v2 07/15] KVM: s390: Interfaces to configure/deconfigure guest's AP matrix

On 02/28/2018 11:15 AM, Pierre Morel wrote: On 27/02/2018 15:28, Tony Krowiak wrote: Provides interfaces to assign AP adapters, usage domains and control domains to a KVM guest. A KVM guest is started by executing the Start Interpretive Execution (SIE) instruction. The SIE state description

Re: [PATCH v2 07/15] KVM: s390: Interfaces to configure/deconfigure guest's AP matrix

On 02/28/2018 11:15 AM, Pierre Morel wrote: On 27/02/2018 15:28, Tony Krowiak wrote: Provides interfaces to assign AP adapters, usage domains and control domains to a KVM guest. A KVM guest is started by executing the Start Interpretive Execution (SIE) instruction. The SIE state description

Re: [PATCH] xfs: Correctly invert xfs_buftarg LRU isolation logic

On Wed, Feb 28, 2018 at 04:49:51PM +0100, Vratislav Bendel wrote: > The function xfs_buftarg_isolate() used by xfs buffer schrinkers > to determine whether a buffer should be isolated and disposed > from LRU list, has inverted logic. > > Excerpt from xfs_buftarg_isolate(): > /* >

Re: [PATCH] xfs: Correctly invert xfs_buftarg LRU isolation logic

On Wed, Feb 28, 2018 at 04:49:51PM +0100, Vratislav Bendel wrote: > The function xfs_buftarg_isolate() used by xfs buffer schrinkers > to determine whether a buffer should be isolated and disposed > from LRU list, has inverted logic. > > Excerpt from xfs_buftarg_isolate(): > /* >

Re: Regression in IPMI on 4.15.6

On 02/28/2018 08:17 AM, Corey Minyard wrote: On 02/28/2018 07:53 AM, Corey Minyard wrote: On 02/27/2018 05:55 PM, Laura Abbott wrote: Hi, Fedora got a bug report of a crash in IPMI on 4.15.6 https://bugzilla.redhat.com/show_bug.cgi?id=1549316 Unfortunately, it's only a screenshot but it's

Re: Regression in IPMI on 4.15.6

On 02/28/2018 08:17 AM, Corey Minyard wrote: On 02/28/2018 07:53 AM, Corey Minyard wrote: On 02/27/2018 05:55 PM, Laura Abbott wrote: Hi, Fedora got a bug report of a crash in IPMI on 4.15.6 https://bugzilla.redhat.com/show_bug.cgi?id=1549316 Unfortunately, it's only a screenshot but it's

Re: [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline

On Wed, 28 Feb 2018, Raj, Ashok wrote: > On Wed, Feb 28, 2018 at 10:11:56AM -0300, Henrique de Moraes Holschuh wrote: > > > Avoid loading microcode if any of the CPUs are offline, and issue a > > > warning. Having different microcode revisions on the system at any time > > > is outright dangerous.

Re: [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline

On Wed, 28 Feb 2018, Raj, Ashok wrote: > On Wed, Feb 28, 2018 at 10:11:56AM -0300, Henrique de Moraes Holschuh wrote: > > > Avoid loading microcode if any of the CPUs are offline, and issue a > > > warning. Having different microcode revisions on the system at any time > > > is outright dangerous.

Re: [PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

On Wed, Feb 28, 2018 at 01:58:53PM -0500, Waiman Long wrote: > On 02/28/2018 01:43 PM, Luis R. Rodriguez wrote: > > On Wed, Feb 28, 2018 at 12:53:40PM -0500, Waiman Long wrote: > >> On 02/27/2018 07:47 PM, Luis R. Rodriguez wrote: > >>> On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote:

Re: [PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

On Wed, Feb 28, 2018 at 01:58:53PM -0500, Waiman Long wrote: > On 02/28/2018 01:43 PM, Luis R. Rodriguez wrote: > > On Wed, Feb 28, 2018 at 12:53:40PM -0500, Waiman Long wrote: > >> On 02/27/2018 07:47 PM, Luis R. Rodriguez wrote: > >>> On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote:

[PATCH v4 1/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

From: Frank Rowand Create a cache of the nodes that contain a phandle property. Use this cache to find the node for a given phandle value instead of scanning the devicetree to find the node. If the phandle value is not found in the cache, of_find_node_by_phandle() will

[PATCH v4 1/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

From: Frank Rowand Create a cache of the nodes that contain a phandle property. Use this cache to find the node for a given phandle value instead of scanning the devicetree to find the node. If the phandle value is not found in the cache, of_find_node_by_phandle() will fall back to the tree

[PATCH v4 2/2] of: add early boot allocation of of_find_node_by_phandle() cache

From: Frank Rowand The initial implementation of the of_find_node_by_phandle() cache allocates the cache using kcalloc(). Add an early boot allocation of the cache so it will be usable during early boot. Switch over to the kcalloc() based cache once normal memory

[PATCH v4 2/2] of: add early boot allocation of of_find_node_by_phandle() cache

From: Frank Rowand The initial implementation of the of_find_node_by_phandle() cache allocates the cache using kcalloc(). Add an early boot allocation of the cache so it will be usable during early boot. Switch over to the kcalloc() based cache once normal memory allocation becomes available.

[PATCH v4 0/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

From: Frank Rowand Create a cache of the nodes that contain a phandle property. Use this cache to find the node for a given phandle value instead of scanning the devicetree to find the node. If the phandle value is not found in the cache, of_find_node_by_phandle() will

[PATCH v4 0/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

From: Frank Rowand Create a cache of the nodes that contain a phandle property. Use this cache to find the node for a given phandle value instead of scanning the devicetree to find the node. If the phandle value is not found in the cache, of_find_node_by_phandle() will fall back to the tree

[tip:x86/urgent] Documentation, x86, resctrl: Make text and sample command match

Commit-ID: 30009746168da0f1f648881f77083c40e226a8a0 Gitweb: https://git.kernel.org/tip/30009746168da0f1f648881f77083c40e226a8a0 Author: Li RongQing AuthorDate: Tue, 27 Feb 2018 14:17:51 +0800 Committer: Thomas Gleixner CommitDate: Wed, 28 Feb

[tip:x86/urgent] Documentation, x86, resctrl: Make text and sample command match

Commit-ID: 30009746168da0f1f648881f77083c40e226a8a0 Gitweb: https://git.kernel.org/tip/30009746168da0f1f648881f77083c40e226a8a0 Author: Li RongQing AuthorDate: Tue, 27 Feb 2018 14:17:51 +0800 Committer: Thomas Gleixner CommitDate: Wed, 28 Feb 2018 19:59:05 +0100 Documentation, x86,

Re: [PATCH net] virtio-net: disable NAPI only when enabled during XDP set

On 02/28/2018 09:22 AM, David Miller wrote: From: Jason Wang Date: Wed, 28 Feb 2018 18:20:04 +0800 We try to disable NAPI to prevent a single XDP TX queue being used by multiple cpus. But we don't check if device is up (NAPI is enabled), this could result stall because of

Re: [PATCH net] virtio-net: disable NAPI only when enabled during XDP set

On 02/28/2018 09:22 AM, David Miller wrote: From: Jason Wang Date: Wed, 28 Feb 2018 18:20:04 +0800 We try to disable NAPI to prevent a single XDP TX queue being used by multiple cpus. But we don't check if device is up (NAPI is enabled), this could result stall because of infinite wait in

[tip:irq/urgent] dt-bindings/irqchip/renesas-irqc: Document R-Car M3-N support

Commit-ID: 7998a4ecc61fbef5547afd379b8953b526709dd2 Gitweb: https://git.kernel.org/tip/7998a4ecc61fbef5547afd379b8953b526709dd2 Author: Geert Uytterhoeven AuthorDate: Mon, 26 Feb 2018 16:25:12 +0100 Committer: Thomas Gleixner CommitDate:

[tip:irq/urgent] dt-bindings/irqchip/renesas-irqc: Document R-Car M3-N support

Commit-ID: 7998a4ecc61fbef5547afd379b8953b526709dd2 Gitweb: https://git.kernel.org/tip/7998a4ecc61fbef5547afd379b8953b526709dd2 Author: Geert Uytterhoeven AuthorDate: Mon, 26 Feb 2018 16:25:12 +0100 Committer: Thomas Gleixner CommitDate: Wed, 28 Feb 2018 19:55:43 +0100

Re: [PATCH] Documentation: Update ncurses package names for menuconfig

On 02/28/2018 09:39 AM, Arvind Prasanna wrote: > Hi Randy: > > On 02/27/2018 10:59 PM, Arvind Prasanna wrote: >> The package name is ncurses-devel for Redhat based distros >> and libncurses-devel for Debian based distros. > > The above lines are part of the commit message and the patch says to

Re: [PATCH] Documentation: Update ncurses package names for menuconfig

On 02/28/2018 09:39 AM, Arvind Prasanna wrote: > Hi Randy: > > On 02/27/2018 10:59 PM, Arvind Prasanna wrote: >> The package name is ncurses-devel for Redhat based distros >> and libncurses-devel for Debian based distros. > > The above lines are part of the commit message and the patch says to

Re: [PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

On 02/28/2018 01:43 PM, Luis R. Rodriguez wrote: > On Wed, Feb 28, 2018 at 12:53:40PM -0500, Waiman Long wrote: >> On 02/27/2018 07:47 PM, Luis R. Rodriguez wrote: >>> On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote: When minimum/maximum values are specified for a sysctl parameter

Re: [PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

On 02/28/2018 01:43 PM, Luis R. Rodriguez wrote: > On Wed, Feb 28, 2018 at 12:53:40PM -0500, Waiman Long wrote: >> On 02/27/2018 07:47 PM, Luis R. Rodriguez wrote: >>> On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote: When minimum/maximum values are specified for a sysctl parameter

Re: [PATCH 3/3] mailbox: sunxi-msgbox: Add a new mailbox driver

On 02/28/18 12:14, Jassi Brar wrote: > On Wed, Feb 28, 2018 at 11:21 PM, Samuel Holland wrote: >> Hi, >> >> On 02/28/18 03:16, Jassi Brar wrote: >>> On Wed, Feb 28, 2018 at 7:57 AM, Samuel Holland wrote: >>> >>> +/* + * The message box

Re: [PATCH 3/3] mailbox: sunxi-msgbox: Add a new mailbox driver

On 02/28/18 12:14, Jassi Brar wrote: > On Wed, Feb 28, 2018 at 11:21 PM, Samuel Holland wrote: >> Hi, >> >> On 02/28/18 03:16, Jassi Brar wrote: >>> On Wed, Feb 28, 2018 at 7:57 AM, Samuel Holland wrote: >>> >>> +/* + * The message box hardware provides 8 unidirectional channels.

Re: [PATCH v3 01/25] dt-bindings: soc: qcom: Add bindings for APR bus

On 22/02/18 10:03, Srinivas Kandagatla wrote: Also the versions of each service are independent to each other. Not sure I follow the last statement. Meaning firmware updates change the services? Sorry for not being clear, so the services like AFE, ASM, ADM have different version numbers for

Re: [PATCH] RDMA/core: reduce IB_POLL_BATCH constant

On Wed, 2018-02-28 at 11:50 +0200, Max Gurtovoy wrote: > > On 2/28/2018 2:21 AM, Bart Van Assche wrote: > > On 02/27/18 14:15, Max Gurtovoy wrote: > > > -static int __ib_process_cq(struct ib_cq *cq, int budget, struct ib_wc > > > *poll_wc) > > > +static int __ib_process_cq(struct ib_cq *cq, int

Re: [PATCH V4 2/2] thermal: imx: add i.MX7 thermal sensor support

On Sat, 2018-02-24 at 16:02 +0800, Anson Huang wrote: > This patch adds i.MX7 thermal sensor support, most > of the i.MX7 thermal sensor functions are same with > i.MX6 except the registers offset/layout, so we move > those registers offset/layout definitions to soc data > structure. > > i.MX7

Re: [PATCH v3 01/25] dt-bindings: soc: qcom: Add bindings for APR bus

On 22/02/18 10:03, Srinivas Kandagatla wrote: Also the versions of each service are independent to each other. Not sure I follow the last statement. Meaning firmware updates change the services? Sorry for not being clear, so the services like AFE, ASM, ADM have different version numbers for

Re: [PATCH] RDMA/core: reduce IB_POLL_BATCH constant

On Wed, 2018-02-28 at 11:50 +0200, Max Gurtovoy wrote: > > On 2/28/2018 2:21 AM, Bart Van Assche wrote: > > On 02/27/18 14:15, Max Gurtovoy wrote: > > > -static int __ib_process_cq(struct ib_cq *cq, int budget, struct ib_wc > > > *poll_wc) > > > +static int __ib_process_cq(struct ib_cq *cq, int

Re: [PATCH V4 2/2] thermal: imx: add i.MX7 thermal sensor support

On Sat, 2018-02-24 at 16:02 +0800, Anson Huang wrote: > This patch adds i.MX7 thermal sensor support, most > of the i.MX7 thermal sensor functions are same with > i.MX6 except the registers offset/layout, so we move > those registers offset/layout definitions to soc data > structure. > > i.MX7

Re: [RFC 2/4] mfd: add Gateworks System Controller core driver

> + dev_err(>dev, ">> 0x%02x %d\n", reg, ret); > + return ret; > + } > + dev_dbg(>dev, ">> 0x%02x=0x%02x (%d)\n", reg, val, retry); > + > +return 0; Hi Tim There appears to be a few spaces vs tabs issues in this file. Andrew

Re: [RFC 2/4] mfd: add Gateworks System Controller core driver

> + dev_err(>dev, ">> 0x%02x %d\n", reg, ret); > + return ret; > + } > + dev_dbg(>dev, ">> 0x%02x=0x%02x (%d)\n", reg, val, retry); > + > +return 0; Hi Tim There appears to be a few spaces vs tabs issues in this file. Andrew

Re: [PATCH v2 07/15] KVM: s390: Interfaces to configure/deconfigure guest's AP matrix

On 02/27/2018 09:28 AM, Tony Krowiak wrote: Provides interfaces to assign AP adapters, usage domains and control domains to a KVM guest. A KVM guest is started by executing the Start Interpretive Execution (SIE) instruction. The SIE state description is a control block that contains the state

Re: [PATCH v2 07/15] KVM: s390: Interfaces to configure/deconfigure guest's AP matrix

On 02/27/2018 09:28 AM, Tony Krowiak wrote: Provides interfaces to assign AP adapters, usage domains and control domains to a KVM guest. A KVM guest is started by executing the Start Interpretive Execution (SIE) instruction. The SIE state description is a control block that contains the state

Re: [RFT 0/7] firmware: enable caching of firmware for reboot optimization

On Wed, Feb 28, 2018 at 08:03:26PM +0200, cantabile wrote: > On 28/02/18 01:20, Luis R. Rodriguez wrote: > > Cantabile, please give these patches a spin and let me know if it fixes > > your reported issue. They depend on other pending patches I have in line > > waiting to be merged so the easiest

Re: [RFT 0/7] firmware: enable caching of firmware for reboot optimization

On Wed, Feb 28, 2018 at 08:03:26PM +0200, cantabile wrote: > On 28/02/18 01:20, Luis R. Rodriguez wrote: > > Cantabile, please give these patches a spin and let me know if it fixes > > your reported issue. They depend on other pending patches I have in line > > waiting to be merged so the easiest

[PATCH v4 3/4] HID: steam: command to check wireless connection

The wireless adaptor does not tell if a device is already connected when steam_probe() is run. Use a command to request the connection status. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 16 1 file changed, 16 insertions(+)

[PATCH v4 4/4] HID: steam: add battery device.

The wireless Steam Controller is battery operated, so add the battery device and power information. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 141 +++- 1 file changed, 140 insertions(+), 1

[PATCH v4 3/4] HID: steam: command to check wireless connection

The wireless adaptor does not tell if a device is already connected when steam_probe() is run. Use a command to request the connection status. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 16 1 file changed, 16 insertions(+) diff --git

[PATCH v4 4/4] HID: steam: add battery device.

The wireless Steam Controller is battery operated, so add the battery device and power information. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 141 +++- 1 file changed, 140 insertions(+), 1 deletion(-) diff --git

[PATCH v4 0/4] new driver for Valve Steam Controller

This patchset implements a driver for Valve Steam Controller, based on a reverse analysis by myself. This is reroll v4, changes since v3: * Add command to check the wireless connection status on probe, without waiting for a message (thanks to Clément Vuchener for the tip). * Removed the

[PATCH v4 2/4] HID: steam: add serial number information.

This device has a feature report to send and receive commands. Use it to get the serial number and set the device's uniq value. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 104 ++-- 1 file changed, 101

[PATCH v4 0/4] new driver for Valve Steam Controller

This patchset implements a driver for Valve Steam Controller, based on a reverse analysis by myself. This is reroll v4, changes since v3: * Add command to check the wireless connection status on probe, without waiting for a message (thanks to Clément Vuchener for the tip). * Removed the

[PATCH v4 2/4] HID: steam: add serial number information.

This device has a feature report to send and receive commands. Use it to get the serial number and set the device's uniq value. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 104 ++-- 1 file changed, 101 insertions(+), 3

[PATCH v4 1/4] HID: add driver for Valve Steam Controller

There are two ways to connect the Steam Controller: directly to the USB or with the USB wireless adapter. Both methods are similar, but the wireless adapter can connect up to 4 devices at the same time. The wired device will appear as 3 interfaces: a virtual mouse, a virtual keyboard and a

[PATCH v4 1/4] HID: add driver for Valve Steam Controller

There are two ways to connect the Steam Controller: directly to the USB or with the USB wireless adapter. Both methods are similar, but the wireless adapter can connect up to 4 devices at the same time. The wired device will appear as 3 interfaces: a virtual mouse, a virtual keyboard and a

Re: [PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

On Wed, Feb 28, 2018 at 12:53:40PM -0500, Waiman Long wrote: > On 02/27/2018 07:47 PM, Luis R. Rodriguez wrote: > > On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote: > >> When minimum/maximum values are specified for a sysctl parameter in > >> the ctl_table structure with

Re: [PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

On Wed, Feb 28, 2018 at 12:53:40PM -0500, Waiman Long wrote: > On 02/27/2018 07:47 PM, Luis R. Rodriguez wrote: > > On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote: > >> When minimum/maximum values are specified for a sysctl parameter in > >> the ctl_table structure with

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

On Wed, 28 Feb 2018, Reinette Chatre wrote: > On 2/28/2018 9:59 AM, Thomas Gleixner wrote: > I hesitated doing something like this because during the review of this > series there was resistance to using sysfs files for multiple values. I > will proceed with your suggestion noting that it is tied

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

On Wed, 28 Feb 2018, Reinette Chatre wrote: > On 2/28/2018 9:59 AM, Thomas Gleixner wrote: > I hesitated doing something like this because during the review of this > series there was resistance to using sysfs files for multiple values. I > will proceed with your suggestion noting that it is tied

Re: [PATCH] rcu: Clean up rcu_init_nohz() by removing unnecessary statements

On Wed, Feb 28, 2018 at 06:04:55PM +0900, Byungchul Park wrote: > Since the commit 44c65ff2e3b0(rcu: Eliminate NOCBs CPU-state Kconfig > options) made nocb-cpus identified only through the rcu_nocbs= boot > parameter, we don't have to care NOCBs CPU-state Kconfig options > anymore, which means now

Re: [PATCH] rcu: Clean up rcu_init_nohz() by removing unnecessary statements

On Wed, Feb 28, 2018 at 06:04:55PM +0900, Byungchul Park wrote: > Since the commit 44c65ff2e3b0(rcu: Eliminate NOCBs CPU-state Kconfig > options) made nocb-cpus identified only through the rcu_nocbs= boot > parameter, we don't have to care NOCBs CPU-state Kconfig options > anymore, which means now

Re: [PATCH v3 08/10] gpio: Add gpio driver for Actions OWL S900 SoC

On Wed, Feb 28, 2018 at 8:14 PM, Manivannan Sadhasivam wrote: > Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers > controlling the gpio shares the same register range with pinctrl block. > > GPIO registers are organized as 6 banks and each

[RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. Signed-off-by:

[RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. Signed-off-by:

Re: [PATCH v3 08/10] gpio: Add gpio driver for Actions OWL S900 SoC

On Wed, Feb 28, 2018 at 8:14 PM, Manivannan Sadhasivam wrote: > Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers > controlling the gpio shares the same register range with pinctrl block. > > GPIO registers are organized as 6 banks and each bank controls the > maximum of 32

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Reinette, On Tue, 27 Feb 2018, Reinette Chatre wrote: > On 2/27/2018 2:36 AM, Thomas Gleixner wrote: > > On Mon, 26 Feb 2018, Reinette Chatre wrote: > >> A change to start us off with could be to initialize the schemata with > >> all the shareable and unused bits set for all domains when a new >

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Reinette, On Tue, 27 Feb 2018, Reinette Chatre wrote: > On 2/27/2018 2:36 AM, Thomas Gleixner wrote: > > On Mon, 26 Feb 2018, Reinette Chatre wrote: > >> A change to start us off with could be to initialize the schemata with > >> all the shareable and unused bits set for all domains when a new >

Re: [PATCH v3 04/10] pinctrl: actions: Add Actions S900 pinctrl driver

On Wed, Feb 28, 2018 at 8:14 PM, Manivannan Sadhasivam wrote: > Add pinctrl driver for Actions Semi S900 SoC. The driver supports > pinctrl, pinmux and pinconf functionalities through a range of registers > common to both gpio driver and pinctrl driver. > >

Re: [PATCH v3 04/10] pinctrl: actions: Add Actions S900 pinctrl driver

On Wed, Feb 28, 2018 at 8:14 PM, Manivannan Sadhasivam wrote: > Add pinctrl driver for Actions Semi S900 SoC. The driver supports > pinctrl, pinmux and pinconf functionalities through a range of registers > common to both gpio driver and pinctrl driver. > > Pinmux functionality is available only

Re: [PATCH v3 01/22] nvmem: Document struct nvmem_config

On Wed, 2018-01-03 at 12:00 -0800, Andrey Smirnov wrote: > Add a simple description of struct nvmem_config and its fields. > > Cc: Srinivas Kandagatla > Cc: Heiko Stuebner > Cc: Masahiro Yamada > Cc: Carlo Caione

Re: [PATCH v3 01/22] nvmem: Document struct nvmem_config

On Wed, 2018-01-03 at 12:00 -0800, Andrey Smirnov wrote: > Add a simple description of struct nvmem_config and its fields. > > Cc: Srinivas Kandagatla > Cc: Heiko Stuebner > Cc: Masahiro Yamada > Cc: Carlo Caione > Cc: Kevin Hilman > Cc: Matthias Brugger > Cc: cphe...@gmail.com > Cc:

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Hi Thomas, On 2/28/2018 9:59 AM, Thomas Gleixner wrote: > On Wed, 28 Feb 2018, Thomas Gleixner wrote: >> On Tue, 27 Feb 2018, Reinette Chatre wrote: >>> On 2/20/2018 9:15 AM, Thomas Gleixner wrote: Let's look at the existing crtl/mon groups which are each represented by a directory

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Hi Thomas, On 2/28/2018 9:59 AM, Thomas Gleixner wrote: > On Wed, 28 Feb 2018, Thomas Gleixner wrote: >> On Tue, 27 Feb 2018, Reinette Chatre wrote: >>> On 2/20/2018 9:15 AM, Thomas Gleixner wrote: Let's look at the existing crtl/mon groups which are each represented by a directory

Re: [RFC PATCH] Randomization of address chosen by mmap.

On Wed, Feb 28, 2018 at 08:13:00PM +0300, Ilya Smith wrote: > > It would be worth spelling out the "not recommended" bit some more > > too: this fragments the mmap space, which has some serious issues on > > smaller address spaces if you get into a situation where you cannot > > allocate a hole

Re: [RFC PATCH] Randomization of address chosen by mmap.

On Wed, Feb 28, 2018 at 08:13:00PM +0300, Ilya Smith wrote: > > It would be worth spelling out the "not recommended" bit some more > > too: this fragments the mmap space, which has some serious issues on > > smaller address spaces if you get into a situation where you cannot > > allocate a hole

<    4   5   6   7   8   9   10   11   12   13   >