Re: [PATCH net 0/3] dpaa_eth: a couple of fixes

From: Madalin Bucur Date: Thu, 15 Dec 2016 15:13:03 +0200 > This patch set introduces big endian accessors in the dpaa_eth driver > making sure accesses to the QBMan HW are correct on little endian > platforms. Removing a redundant Kconfig dependency on FSL_SOC. > Adding

Re: [PATCH net 0/3] dpaa_eth: a couple of fixes

From: Madalin Bucur Date: Thu, 15 Dec 2016 15:13:03 +0200 > This patch set introduces big endian accessors in the dpaa_eth driver > making sure accesses to the QBMan HW are correct on little endian > platforms. Removing a redundant Kconfig dependency on FSL_SOC. > Adding myself as maintainer of

[RFC][PATCH] spinlock_debug: report spinlock lockup from unlock

There is a race window between the point when __spin_lock_debug() detects spinlock lockup and the time when CPU that caused the lockup receives its backtrace interrupt. Before __spin_lock_debug() triggers all_cpu_backtrace() it calls spin_dump() to printk() the current state of the lock and CPU

[RFC][PATCH] spinlock_debug: report spinlock lockup from unlock

There is a race window between the point when __spin_lock_debug() detects spinlock lockup and the time when CPU that caused the lockup receives its backtrace interrupt. Before __spin_lock_debug() triggers all_cpu_backtrace() it calls spin_dump() to printk() the current state of the lock and CPU

Re: [PATCH 1/5] irda: irproc.c: Remove unneeded linux/miscdevice.h include

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:46 +0100 > irproc.c does not use any miscdevice so this patch remove this > unnecessary inclusion. > > Signed-off-by: Corentin Labbe Applied.

Re: [PATCH 3/5] irnet: ppp: move IRNET_MINOR to include/linux/miscdevice.h

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:48 +0100 > This patch move the define for IRNET_MINOR to include/linux/miscdevice.h > It is better that all minor number definitions are in the same place. > > Signed-off-by: Corentin Labbe

Re: [PATCH 2/5] irda: irnet: Move linux/miscdevice.h include

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:47 +0100 > The only use of miscdevice is irda_ppp so no need to include > linux/miscdevice.h for all irda files. > This patch move the linux/miscdevice.h include to irnet_ppp.h > > Signed-off-by: Corentin Labbe

Re: [PATCH 1/5] irda: irproc.c: Remove unneeded linux/miscdevice.h include

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:46 +0100 > irproc.c does not use any miscdevice so this patch remove this > unnecessary inclusion. > > Signed-off-by: Corentin Labbe Applied.

Re: [PATCH 3/5] irnet: ppp: move IRNET_MINOR to include/linux/miscdevice.h

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:48 +0100 > This patch move the define for IRNET_MINOR to include/linux/miscdevice.h > It is better that all minor number definitions are in the same place. > > Signed-off-by: Corentin Labbe Applied.

Re: [PATCH 2/5] irda: irnet: Move linux/miscdevice.h include

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:47 +0100 > The only use of miscdevice is irda_ppp so no need to include > linux/miscdevice.h for all irda files. > This patch move the linux/miscdevice.h include to irnet_ppp.h > > Signed-off-by: Corentin Labbe Applied.

Re: [PATCH 4/5] irda: irnet: Remove unused IRNET_MAJOR define

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:49 +0100 > The IRNET_MAJOR define is not used, so this patch remove it. > > Signed-off-by: Corentin Labbe Applied.

Re: [PATCH 5/5] irda: irnet: add member name to the miscdevice declaration

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:50 +0100 > Since the struct miscdevice have many members, it is dangerous to init > it without members name relying only on member order. > > This patch add member name to the init declaration. > > Signed-off-by:

Re: [PATCH 4/5] irda: irnet: Remove unused IRNET_MAJOR define

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:49 +0100 > The IRNET_MAJOR define is not used, so this patch remove it. > > Signed-off-by: Corentin Labbe Applied.

Re: [PATCH 5/5] irda: irnet: add member name to the miscdevice declaration

From: Corentin Labbe Date: Thu, 15 Dec 2016 11:42:50 +0100 > Since the struct miscdevice have many members, it is dangerous to init > it without members name relying only on member order. > > This patch add member name to the init declaration. > > Signed-off-by: Corentin Labbe Applied.

Re: [PATCH] x86/floppy: use designated initializers

* Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from grsecurity. >

Re: [PATCH] x86/floppy: use designated initializers

* Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from grsecurity. > > Signed-off-by: Kees

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> As far as half-siphash is concerned, it occurs to me that the main > problem will be those users who need to guarantee that output can't be > guessed over a long period of time. For example, if you have a > long-running process, then the output needs to remain unguessable over > potentially

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> As far as half-siphash is concerned, it occurs to me that the main > problem will be those users who need to guarantee that output can't be > guessed over a long period of time. For example, if you have a > long-running process, then the output needs to remain unguessable over > potentially

Re: [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs

Hi Quentin, On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote: > The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the > VBUS power supply for both max current and min voltage supplied. This > series of patch adds the possibility to set these limits from sysfs. > >

Re: [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs

Hi Quentin, On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote: > The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the > VBUS power supply for both max current and min voltage supplied. This > series of patch adds the possibility to set these limits from sysfs. > >

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: > >> - Ted, Andy Lutorminski and I will try to figure out a construction of > >> get_random_long() that we all like. We don't have to find the most optimal solution right away; we can approach this incrementally, after all. So

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: > >> - Ted, Andy Lutorminski and I will try to figure out a construction of > >> get_random_long() that we all like. We don't have to find the most optimal solution right away; we can approach this incrementally, after all. So

Re: [PATCH v3] net: macb: Added PCI wrapper for Platform Driver.

From: Bartosz Folta Date: Wed, 14 Dec 2016 06:39:15 + > There are hardware PCI implementations of Cadence GEM network > controller. This patch will allow to use such hardware with reuse of > existing Platform Driver. > > Signed-off-by: Bartosz Folta

Re: [PATCH v3] net: macb: Added PCI wrapper for Platform Driver.

From: Bartosz Folta Date: Wed, 14 Dec 2016 06:39:15 + > There are hardware PCI implementations of Cadence GEM network > controller. This patch will allow to use such hardware with reuse of > existing Platform Driver. > > Signed-off-by: Bartosz Folta > --- > Changed in v3: > Fixed

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

To follow up on my comments that your benchmark results were peculiar, here's my benchmark code. It just computes the hash of all n*(n+1)/2 possible non-empty substrings of a buffer of n (called "max" below) bytes. "cpb" is "cycles per byte". (The average length is (n+2)/3, c.f.

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

To follow up on my comments that your benchmark results were peculiar, here's my benchmark code. It just computes the hash of all n*(n+1)/2 possible non-empty substrings of a buffer of n (called "max" below) bytes. "cpb" is "cycles per byte". (The average length is (n+2)/3, c.f.

Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

Hey guys, Chanwoo Choi wrote: > Hi Lin, > > 2016-11-24 18:54 GMT+09:00 Chanwoo Choi : >> Hi Lin, >> >> On 2016년 11월 24일 18:28, Chanwoo Choi wrote: >>> Hi Lin, >>> >>> On 2016년 11월 24일 17:34, hl wrote: Hi Chanwoo Choi, On 2016年11月24日 16:16, Chanwoo Choi

Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

Hey guys, Chanwoo Choi wrote: > Hi Lin, > > 2016-11-24 18:54 GMT+09:00 Chanwoo Choi : >> Hi Lin, >> >> On 2016년 11월 24일 18:28, Chanwoo Choi wrote: >>> Hi Lin, >>> >>> On 2016년 11월 24일 17:34, hl wrote: Hi Chanwoo Choi, On 2016年11月24日 16:16, Chanwoo Choi wrote: > Hi Lin,

Re: [PATCH v3 2/2] mfd: axp20x: Fix axp288 volatile ranges

On Sat, Dec 17, 2016 at 4:09 AM, Hans de Goede wrote: > The axp288 pmic has a lot more volatile registers then we were > listing in axp288_volatile_ranges, fix this. > > Signed-off-by: Hans de Goede Acked-by: Chen-Yu Tsai FYI, if you're

Re: [PATCH v3 2/2] mfd: axp20x: Fix axp288 volatile ranges

On Sat, Dec 17, 2016 at 4:09 AM, Hans de Goede wrote: > The axp288 pmic has a lot more volatile registers then we were > listing in axp288_volatile_ranges, fix this. > > Signed-off-by: Hans de Goede Acked-by: Chen-Yu Tsai FYI, if you're going to add support for the battery charger detection

Re: [PATCH v3 1/2] mfd: axp20x: Add a few missing defines for AXP288 specific registers

On Sat, Dec 17, 2016 at 4:09 AM, Hans de Goede wrote: > Add defines for the AXP288_POWER_REASON and AXP288_RT_BATT_V_H and > AXP288_RT_BATT_V_L and AXP288_BC_* registers. While at it also move the > AXP288_TS_ADC_H-AXP288_GP_ADC_L defines, which for some reason where > in a

Re: [PATCH v3 1/2] mfd: axp20x: Add a few missing defines for AXP288 specific registers

On Sat, Dec 17, 2016 at 4:09 AM, Hans de Goede wrote: > Add defines for the AXP288_POWER_REASON and AXP288_RT_BATT_V_H and > AXP288_RT_BATT_V_L and AXP288_BC_* registers. While at it also move the > AXP288_TS_ADC_H-AXP288_GP_ADC_L defines, which for some reason where > in a different place,

Re: [PATCH v2 2/2] mfd: axp20x: Fix axp288 volatile ranges

On Thu, Dec 15, 2016 at 10:07 PM, Hans de Goede wrote: > The axp288 pmic has a lot more volatile registers then we were > listing in axp288_volatile_ranges, fix this. > > Signed-off-by: Hans de Goede Acked-by: Chen-Yu Tsai

Re: [PATCH v2 2/2] mfd: axp20x: Fix axp288 volatile ranges

On Thu, Dec 15, 2016 at 10:07 PM, Hans de Goede wrote: > The axp288 pmic has a lot more volatile registers then we were > listing in axp288_volatile_ranges, fix this. > > Signed-off-by: Hans de Goede Acked-by: Chen-Yu Tsai

Re: [PATCH v2 1/2] mfd: axp20x: Add a few missing defines for AXP288 specific registers

On Thu, Dec 15, 2016 at 10:07 PM, Hans de Goede wrote: > Add defines for the AXP288_POWER_REASON and AXP288_RT_BATT_V_H and > AXP288_RT_BATT_V_L registers. While at it also move the > AXP288_TS_ADC_H-AXP288_GP_ADC_L defines, which for some reason where > in a different place,

Re: [PATCH v2 1/2] mfd: axp20x: Add a few missing defines for AXP288 specific registers

On Thu, Dec 15, 2016 at 10:07 PM, Hans de Goede wrote: > Add defines for the AXP288_POWER_REASON and AXP288_RT_BATT_V_H and > AXP288_RT_BATT_V_L registers. While at it also move the > AXP288_TS_ADC_H-AXP288_GP_ADC_L defines, which for some reason where > in a different place, together with the

Re: [PATCH v3] power: supply: bq24735-charger: optionally poll the ac-detect gpio

Hi, On Thu, Dec 15, 2016 at 10:28:46AM +0100, Peter Rosin wrote: > If the ac-detect gpio does not support interrupts, provide a fallback > to poll the gpio at a configurable interval. > > Signed-off-by: Peter Rosin Thanks for your patch. We are currently in the merge window

Re: [PATCH v3] power: supply: bq24735-charger: optionally poll the ac-detect gpio

Hi, On Thu, Dec 15, 2016 at 10:28:46AM +0100, Peter Rosin wrote: > If the ac-detect gpio does not support interrupts, provide a fallback > to poll the gpio at a configurable interval. > > Signed-off-by: Peter Rosin Thanks for your patch. We are currently in the merge window and your patch will

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> diff --git a/lib/test_siphash.c b/lib/test_siphash.c > new file mode 100644 > index ..93549e4e22c5 > --- /dev/null > +++ b/lib/test_siphash.c > @@ -0,0 +1,83 @@ > +/* Test cases for siphash.c > + * > + * Copyright (C) 2016 Jason A. Donenfeld . All Rights > Reserved.

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> diff --git a/lib/test_siphash.c b/lib/test_siphash.c > new file mode 100644 > index ..93549e4e22c5 > --- /dev/null > +++ b/lib/test_siphash.c > @@ -0,0 +1,83 @@ > +/* Test cases for siphash.c > + * > + * Copyright (C) 2016 Jason A. Donenfeld . All Rights > Reserved. > + * > + * This

Re: [PATCH v4] dt-bindings: power: supply: bq24735: reverse the polarity of ac-detect

Hi, On Fri, Dec 16, 2016 at 10:44:00AM +0100, Peter Rosin wrote: > The ACOK pin on the bq24735 is active-high, of course meaning that when > AC is OK the pin is high. However, all Tegra dts files have incorrectly > specified active-high even though the signal is inverted on the Tegra > boards.

Re: [PATCH v4] dt-bindings: power: supply: bq24735: reverse the polarity of ac-detect

Hi, On Fri, Dec 16, 2016 at 10:44:00AM +0100, Peter Rosin wrote: > The ACOK pin on the bq24735 is active-high, of course meaning that when > AC is OK the pin is high. However, all Tegra dts files have incorrectly > specified active-high even though the signal is inverted on the Tegra > boards.

Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

Hi Lin, 2016-11-24 18:54 GMT+09:00 Chanwoo Choi : > Hi Lin, > > On 2016년 11월 24일 18:28, Chanwoo Choi wrote: >> Hi Lin, >> >> On 2016년 11월 24일 17:34, hl wrote: >>> Hi Chanwoo Choi, >>> >>> >>> On 2016年11月24日 16:16, Chanwoo Choi wrote: Hi Lin, On 2016년 11월 24일

Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

Hi Lin, 2016-11-24 18:54 GMT+09:00 Chanwoo Choi : > Hi Lin, > > On 2016년 11월 24일 18:28, Chanwoo Choi wrote: >> Hi Lin, >> >> On 2016년 11월 24일 17:34, hl wrote: >>> Hi Chanwoo Choi, >>> >>> >>> On 2016年11月24日 16:16, Chanwoo Choi wrote: Hi Lin, On 2016년 11월 24일 16:34, hl wrote: >

Re: OOM: Better, but still there on

On 2016/12/17 21:59, Nils Holland wrote: > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote: >> mount -t tracefs none /debug/trace >> echo 1 > /debug/trace/events/vmscan/enable >> cat /debug/trace/trace_pipe > trace.log >> >> should help >> [...] > > No problem! I enabled writing the

Re: OOM: Better, but still there on

On 2016/12/17 21:59, Nils Holland wrote: > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote: >> mount -t tracefs none /debug/trace >> echo 1 > /debug/trace/events/vmscan/enable >> cat /debug/trace/trace_pipe > trace.log >> >> should help >> [...] > > No problem! I enabled writing the

[PATCH v3 7/7] thunderbolt: Runtime suspend NHI when idle

Runtime suspend the NHI when no Thunderbolt devices have been plugged in for 10 sec (user-configurable via autosuspend_delay_ms in sysfs). The NHI is not able to detect plug events while suspended, it relies on the GPE handler to resume it on hotplug. After the NHI resumes, it takes about 700 ms

[PATCH v3 7/7] thunderbolt: Runtime suspend NHI when idle

Runtime suspend the NHI when no Thunderbolt devices have been plugged in for 10 sec (user-configurable via autosuspend_delay_ms in sysfs). The NHI is not able to detect plug events while suspended, it relies on the GPE handler to resume it on hotplug. After the NHI resumes, it takes about 700 ms

[PATCH v3 5/7] PM: Make requirements of dev_pm_domain_set() more precise

Since commit 989561de9b51 ("PM / Domains: add setter for dev.pm_domain") a PM domain may only be assigned to unbound devices. The motivation was not made explicit in the changelog other than "in the general case that can cause problems and also [...] we can simplify code quite a bit if we can

[PATCH v3 6/7] thunderbolt: Power down controller when idle

Document and implement Apple's ACPI-based (but nonstandard) pm mechanism for Thunderbolt. Briefly, an ACPI method provided by Apple is used to cut power to the controller. A GPE is enabled while the controller is powered down which sideband-signals a plug event, whereupon we reinstate power

[PATCH v3 4/7] Revert "PM / Runtime: Remove the exported function pm_children_suspended()"

This reverts commit 62006c1702b3b1be0c0726949e0ee0ea2326be9c which removed pm_children_suspended() because it had only a single caller. We're about to add a second caller, so establish the status quo ante. Cc: Ulf Hansson Cc: Rafael J. Wysocki

[PATCH v3 6/7] thunderbolt: Power down controller when idle

Document and implement Apple's ACPI-based (but nonstandard) pm mechanism for Thunderbolt. Briefly, an ACPI method provided by Apple is used to cut power to the controller. A GPE is enabled while the controller is powered down which sideband-signals a plug event, whereupon we reinstate power

[PATCH v3 4/7] Revert "PM / Runtime: Remove the exported function pm_children_suspended()"

This reverts commit 62006c1702b3b1be0c0726949e0ee0ea2326be9c which removed pm_children_suspended() because it had only a single caller. We're about to add a second caller, so establish the status quo ante. Cc: Ulf Hansson Cc: Rafael J. Wysocki Signed-off-by: Lukas Wunner ---

[PATCH v3 5/7] PM: Make requirements of dev_pm_domain_set() more precise

Since commit 989561de9b51 ("PM / Domains: add setter for dev.pm_domain") a PM domain may only be assigned to unbound devices. The motivation was not made explicit in the changelog other than "in the general case that can cause problems and also [...] we can simplify code quite a bit if we can

[PATCH v3 1/7] PCI: Recognize Thunderbolt devices

We're about to allow runtime PM on Thunderbolt ports in pci_bridge_d3_possible() and unblock runtime PM for Thunderbolt host hotplug ports in pci_dev_check_d3cold(). In both cases we need to uniquely identify if a PCI device belongs to a Thunderbolt controller. We also have the need to detect

[PATCH v3 1/7] PCI: Recognize Thunderbolt devices

We're about to allow runtime PM on Thunderbolt ports in pci_bridge_d3_possible() and unblock runtime PM for Thunderbolt host hotplug ports in pci_dev_check_d3cold(). In both cases we need to uniquely identify if a PCI device belongs to a Thunderbolt controller. We also have the need to detect

[PATCH v3 2/7] PCI: Allow runtime PM on Thunderbolt ports

Currently PCIe ports are only allowed to go to D3 if the BIOS is dated 2015 or newer to avoid potential issues with old chipsets. However for Thunderbolt we know that even the oldest controller, Light Ridge (2010), is able to suspend its ports to D3 just fine. We're about to add runtime PM for

[PATCH v3 3/7] PCI: Don't block runtime PM for Thunderbolt host hotplug ports

Hotplug ports generally block their parents from suspending to D3hot as otherwise their interrupts couldn't be delivered. An exception are Thunderbolt host controllers: They have a separate GPIO pin to side-band signal plug events even if the controller is powered down or its parent ports are

[PATCH v3 2/7] PCI: Allow runtime PM on Thunderbolt ports

Currently PCIe ports are only allowed to go to D3 if the BIOS is dated 2015 or newer to avoid potential issues with old chipsets. However for Thunderbolt we know that even the oldest controller, Light Ridge (2010), is able to suspend its ports to D3 just fine. We're about to add runtime PM for

[PATCH v3 3/7] PCI: Don't block runtime PM for Thunderbolt host hotplug ports

Hotplug ports generally block their parents from suspending to D3hot as otherwise their interrupts couldn't be delivered. An exception are Thunderbolt host controllers: They have a separate GPIO pin to side-band signal plug events even if the controller is powered down or its parent ports are

[PATCH v3 0/7] Runtime PM for Thunderbolt on Macs

Power down Thunderbolt controllers on Macs when nothing is plugged in to save around 2W per controller. Apple provides an ACPI-based (but nonstandard) mechanism to cut power and signal hotplug during powerdown. The usual way to implement such nonstandard mechanisms seems to be a struct

[PATCH v3 0/7] Runtime PM for Thunderbolt on Macs

Power down Thunderbolt controllers on Macs when nothing is plugged in to save around 2W per controller. Apple provides an ACPI-based (but nonstandard) mechanism to cut power and signal hotplug during powerdown. The usual way to implement such nonstandard mechanisms seems to be a struct

Re: [PATCH] rbtree: use designated initializers

On Fri, Dec 16, 2016 at 05:02:53PM -0800, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from

Re: [PATCH] rbtree: use designated initializers

On Fri, Dec 16, 2016 at 05:02:53PM -0800, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On Sat, Dec 17, 2016 at 3:33 AM, Stephen Boyd wrote: > On 12/15, Pierre-Louis Bossart wrote: >>Clients use devm_clk_get() with a "pmc_plt_clk_" >> argument. > > This is the problem. Clients should be calling clk_get() like: > > clk_get(dev, "signal name in

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On Sat, Dec 17, 2016 at 3:33 AM, Stephen Boyd wrote: > On 12/15, Pierre-Louis Bossart wrote: >>Clients use devm_clk_get() with a "pmc_plt_clk_" >> argument. > > This is the problem. Clients should be calling clk_get() like: > > clk_get(dev, "signal name in datasheet") > > where the first

Re: [PATCH -v4 02/10] futex: Add missing error handling to FUTEX_REQUEUE_PI

On Fri, Dec 16, 2016 at 04:06:39PM -0800, Darren Hart wrote: > On Tue, Dec 13, 2016 at 09:36:40AM +0100, Peter Zijlstra wrote: > > Thomas spotted that fixup_pi_state_owner() can return errors and we > > fail to unlock the rt_mutex in that case. > > > > We handled this explicitly before Patch

Re: [PATCH -v4 02/10] futex: Add missing error handling to FUTEX_REQUEUE_PI

On Fri, Dec 16, 2016 at 04:06:39PM -0800, Darren Hart wrote: > On Tue, Dec 13, 2016 at 09:36:40AM +0100, Peter Zijlstra wrote: > > Thomas spotted that fixup_pi_state_owner() can return errors and we > > fail to unlock the rt_mutex in that case. > > > > We handled this explicitly before Patch

Re: [PATCH -v4 00/10] FUTEX_UNLOCK_PI wobbles

On Fri, Dec 16, 2016 at 03:31:40PM -0800, Darren Hart wrote: > On Tue, Dec 13, 2016 at 09:36:38AM +0100, Peter Zijlstra wrote: > > That way, when we drop hb->lock to wait, futex and rt_mutex wait state is > > consistent. > > > > > > In any case, it passes our inadequate testing. > > It passed

Re: [PATCH -v4 00/10] FUTEX_UNLOCK_PI wobbles

On Fri, Dec 16, 2016 at 03:31:40PM -0800, Darren Hart wrote: > On Tue, Dec 13, 2016 at 09:36:38AM +0100, Peter Zijlstra wrote: > > That way, when we drop hb->lock to wait, futex and rt_mutex wait state is > > consistent. > > > > > > In any case, it passes our inadequate testing. > > It passed

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

On Fri, Dec 16, 2016 at 02:17:25PM +0100, Nicolai Hähnle wrote: > On 06.12.2016 16:25, Peter Zijlstra wrote: > >On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: > > > >>@@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, > >>unsigned int subclass, > >>

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

On Fri, Dec 16, 2016 at 02:17:25PM +0100, Nicolai Hähnle wrote: > On 06.12.2016 16:25, Peter Zijlstra wrote: > >On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: > > > >>@@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, > >>unsigned int subclass, > >>

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Matthew Wilcox > From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > > This sounds good. I think there may still be a lot of users that never > > allocate more than a handful of IDAs, making a 128 byte allocation still > > somewhat excessive. One thing I considered was (exactly as

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Matthew Wilcox > From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > > This sounds good. I think there may still be a lot of users that never > > allocate more than a handful of IDAs, making a 128 byte allocation still > > somewhat excessive. One thing I considered was (exactly as

[PATCH] livepatch: fixup klp-convert tool integration

I've found some minor problems, this patch fixes: * save cmd_ld_ko_o into .module.cmd, if_changed_rule doesn't do that * fix bashisms for debian where /bin/sh is a symlink to /bin/dash * rename rule_link_module to rule_ld_ko_o, otherwise arg-check inside if_changed_rule compares cmd_link_module

[PATCH] livepatch: fixup klp-convert tool integration

I've found some minor problems, this patch fixes: * save cmd_ld_ko_o into .module.cmd, if_changed_rule doesn't do that * fix bashisms for debian where /bin/sh is a symlink to /bin/dash * rename rule_link_module to rule_ld_ko_o, otherwise arg-check inside if_changed_rule compares cmd_link_module

MAC address in wl1251 NVS data (Was: Re: wl1251 NVS calibration data format)

> On Sat, Dec 17, 2016 at 12:14:50PM +0100, Pali Rohár wrote: > > > [1] http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt > > In that description is something about STA mac address: > > 019 02 //length > > 01a 6d //STA_ADDR_L Register Address. (STA MAC > >

MAC address in wl1251 NVS data (Was: Re: wl1251 NVS calibration data format)

> On Sat, Dec 17, 2016 at 12:14:50PM +0100, Pali Rohár wrote: > > > [1] http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt > > In that description is something about STA mac address: > > 019 02 //length > > 01a 6d //STA_ADDR_L Register Address. (STA MAC > >

Re: OOM: Better, but still there on

On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote: > On Fri 16-12-16 19:47:00, Nils Holland wrote: > > > > Dec 16 18:56:24 boerne.fritz.box kernel: Purging GPU memory, 37 pages > > freed, 10219 pages still pinned. > > Dec 16 18:56:29 boerne.fritz.box kernel: kthreadd invoked

Re: OOM: Better, but still there on

On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote: > On Fri 16-12-16 19:47:00, Nils Holland wrote: > > > > Dec 16 18:56:24 boerne.fritz.box kernel: Purging GPU memory, 37 pages > > freed, 10219 pages still pinned. > > Dec 16 18:56:29 boerne.fritz.box kernel: kthreadd invoked

Re: [PATCH 1/2] dt-bindings: usb: add DT binding for s3c2410 USB device controller

On Tue, Dec 13, 2016 at 12:59:15PM -0600, Rob Herring wrote: > > +Samsung S3C2410 and compatible USB device controller > > + > > +Required properties: > > + - compatible: Should be one of the following > > + "samsung,s3c2410-udc" > > + "samsung,s3c2440-udc" > > + - reg: address

Re: [PATCH 1/2] dt-bindings: usb: add DT binding for s3c2410 USB device controller

On Tue, Dec 13, 2016 at 12:59:15PM -0600, Rob Herring wrote: > > +Samsung S3C2410 and compatible USB device controller > > + > > +Required properties: > > + - compatible: Should be one of the following > > + "samsung,s3c2410-udc" > > + "samsung,s3c2440-udc" > > + - reg: address

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

BTW, here's some SipHash code I wrote for Linux a while ago. My target application was ext4 directory hashing, resulting in different implementation choices, although I still think that a rolled-up implementation like this is reasonable. Reducing I-cache impact speeds up the calling code. One

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

BTW, here's some SipHash code I wrote for Linux a while ago. My target application was ext4 directory hashing, resulting in different implementation choices, although I still think that a rolled-up implementation like this is reasonable. Reducing I-cache impact speeds up the calling code. One

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote: > > On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > > > Use 52 bits for 'pfn', 12 bits for 'length', when the

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote: > > On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > > > Use 52 bits for 'pfn', 12 bits for 'length', when the

Re: netfilter regression causes lost pings "operation not permitted"

Trevor Cordes wrote: Sorry for late reply. > On 2016-12-07 Trevor Cordes wrote: > > Bisected down to: > > 870190a9ec9075205c0fa795a09fa931694a3ff1 > > 7c9664351980aaa6a4b8837a314360b3a4ad382a > > Oh! I forgot to mention the most important point: iptable_nat module > MUST

Re: netfilter regression causes lost pings "operation not permitted"

Trevor Cordes wrote: Sorry for late reply. > On 2016-12-07 Trevor Cordes wrote: > > Bisected down to: > > 870190a9ec9075205c0fa795a09fa931694a3ff1 > > 7c9664351980aaa6a4b8837a314360b3a4ad382a > > Oh! I forgot to mention the most important point: iptable_nat module > MUST be loaded for the bug

Re: wl1251 NVS calibration data format

Hi, On Sat, Dec 17, 2016 at 12:14:50PM +0100, Pali Rohár wrote: > On Saturday 17 December 2016 10:37:05 Sebastian Reichel wrote: > > On Fri, Dec 16, 2016 at 12:01:48PM +0100, Pali Rohár wrote: > > > Hi! Do you know format of wl1251 NVS calibration data file? > > > > > > I found that there is

Re: wl1251 NVS calibration data format

Hi, On Sat, Dec 17, 2016 at 12:14:50PM +0100, Pali Rohár wrote: > On Saturday 17 December 2016 10:37:05 Sebastian Reichel wrote: > > On Fri, Dec 16, 2016 at 12:01:48PM +0100, Pali Rohár wrote: > > > Hi! Do you know format of wl1251 NVS calibration data file? > > > > > > I found that there is

Re: [PATCH] staging: android: ion: return -ENOMEM in ion_cma_heap allocation failure

2016-12-14 1:04 GMT+09:00 Laura Abbott : > On 12/08/2016 09:05 PM, Jaewon Kim wrote: >> Initial Commit 349c9e138551 ("gpu: ion: add CMA heap") returns -1 in >> allocation >> failure. The returned value is passed up to userspace through ioctl. So user >> can >> misunderstand

Re: [PATCH] staging: android: ion: return -ENOMEM in ion_cma_heap allocation failure

2016-12-14 1:04 GMT+09:00 Laura Abbott : > On 12/08/2016 09:05 PM, Jaewon Kim wrote: >> Initial Commit 349c9e138551 ("gpu: ion: add CMA heap") returns -1 in >> allocation >> failure. The returned value is passed up to userspace through ioctl. So user >> can >> misunderstand error reason as

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On Fri, Dec 16, 2016 at 01:12:21AM +, Li, Liang Z wrote: > > There still exist the case if the MAX_ORDER is configured to a large > > value, e.g. 36 for a system with huge amount of memory, then there is only > 28 bits left for the pfn, which is not enough. > > Not related to the balloon

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On Fri, Dec 16, 2016 at 01:12:21AM +, Li, Liang Z wrote: > > There still exist the case if the MAX_ORDER is configured to a large > > value, e.g. 36 for a system with huge amount of memory, then there is only > 28 bits left for the pfn, which is not enough. > > Not related to the balloon

[tip:x86/urgent] x86/mpx: Move bd_addr to mm_context_t

Commit-ID: cb02de96ec724b84373488dd349e53897ab432f5 Gitweb: http://git.kernel.org/tip/cb02de96ec724b84373488dd349e53897ab432f5 Author: Mark Rutland AuthorDate: Fri, 16 Dec 2016 12:40:55 + Committer: Thomas Gleixner CommitDate: Sat, 17 Dec

[tip:x86/urgent] x86/mpx: Move bd_addr to mm_context_t

Commit-ID: cb02de96ec724b84373488dd349e53897ab432f5 Gitweb: http://git.kernel.org/tip/cb02de96ec724b84373488dd349e53897ab432f5 Author: Mark Rutland AuthorDate: Fri, 16 Dec 2016 12:40:55 + Committer: Thomas Gleixner CommitDate: Sat, 17 Dec 2016 12:29:56 +0100 x86/mpx: Move bd_addr

Re: [PATCH 32/60] block: implement sp version of bvec iterator helpers

Hi Guys, On Sat, Oct 29, 2016 at 7:06 PM, kbuild test robot wrote: > Hi Ming, Thanks for the report! > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.9-rc2 next-20161028] > [if your patch is applied to the wrong git tree, please drop us a note to >

Re: [PATCH 32/60] block: implement sp version of bvec iterator helpers

Hi Guys, On Sat, Oct 29, 2016 at 7:06 PM, kbuild test robot wrote: > Hi Ming, Thanks for the report! > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.9-rc2 next-20161028] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On 2016-12-16 23:00:27 [+0100], Arnd Bergmann wrote: > On Friday, December 16, 2016 6:00:43 PM CET Sebastian Andrzej Siewior wrote: > > On 2016-12-16 11:56:21 [+0100], Arnd Bergmann wrote: > > > The original gcc-4.3 release was in early 2008. If we decide to still > > > support that, we probably

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On 2016-12-16 23:00:27 [+0100], Arnd Bergmann wrote: > On Friday, December 16, 2016 6:00:43 PM CET Sebastian Andrzej Siewior wrote: > > On 2016-12-16 11:56:21 [+0100], Arnd Bergmann wrote: > > > The original gcc-4.3 release was in early 2008. If we decide to still > > > support that, we probably

<    1   2   3   4   >