[PATCH v7 2/6] secure_seq: use SipHash in place of MD5

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, for IPv6, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. For IPv4, we pass the

[PATCH v7 1/6] siphash: add cryptographically secure PRF

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function, or as a general PRF for short input use cases, such as sequence numbers or RNG chaining. For the first

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

On 12/19, Pierre-Louis Bossart wrote: > On 12/17/16 7:57 AM, Andy Shevchenko wrote: > >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

[PATCH v7 2/6] secure_seq: use SipHash in place of MD5

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, for IPv6, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. For IPv4, we pass the

[PATCH 2/2 v2] ARM: i.MX25: add the optional security violation irq

Add the security violation irq as an optional entry to rtc-imxdi's device tree bindings and to i.MX25's dtsi file. Signed-off-by: Martin Kaiser --- v2: - clarify that the security violation interrupt is optional - use the same syntax as everwhere else for lists of interrupt

Re: [PATCH 2/2] net: wireless: fix to uses struct

My previous patch is invalid, I'm sorry. The last patc will be fellow because "regulatory_request" is defined as a "static struct". Signed-off-by: Ozgur Karatas --- net/wireless/reg.c | 10 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 2/2 v2] ARM: i.MX25: add the optional security violation irq

Add the security violation irq as an optional entry to rtc-imxdi's device tree bindings and to i.MX25's dtsi file. Signed-off-by: Martin Kaiser --- v2: - clarify that the security violation interrupt is optional - use the same syntax as everwhere else for lists of interrupt numbers

Re: [PATCH 2/2] net: wireless: fix to uses struct

My previous patch is invalid, I'm sorry. The last patc will be fellow because "regulatory_request" is defined as a "static struct". Signed-off-by: Ozgur Karatas --- net/wireless/reg.c | 10 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/wireless/reg.c

Re: Inlined functions in perf report

On Thu, Dec 22, 2016 at 06:56:28AM +0800, Jin, Yao wrote: > Could you see the inline if you use the addr2line command? For example, > addr2line -e -i I'm sorry, I don't have this profile anymore. I'll try again once we sort out the problems of the DWARF error messages everywhere. /* Steinar */

Re: Inlined functions in perf report

On Thu, Dec 22, 2016 at 06:56:28AM +0800, Jin, Yao wrote: > Could you see the inline if you use the addr2line command? For example, > addr2line -e -i I'm sorry, I don't have this profile anymore. I'll try again once we sort out the problems of the DWARF error messages everywhere. /* Steinar */

[PATCH 1/2 v3] rtc: imxdi: use the security violation interrupt

The DryIce chipset has a dedicated security violation interrupt that is triggered for security violations (if configured to do so). According to the publicly available imx258 reference manual, irq 56 is used for this interrupt. If an irq number is provided for the security violation interrupt,

Re: [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board

On Thu, Dec 22, 2016 at 04:02:35AM +0800, Icenowy Zheng wrote: > Lichee Pi One is a low-cost Allwinner A13-based development board, with > an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard > RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO > headers and two

[PATCH 1/2 v3] rtc: imxdi: use the security violation interrupt

The DryIce chipset has a dedicated security violation interrupt that is triggered for security violations (if configured to do so). According to the publicly available imx258 reference manual, irq 56 is used for this interrupt. If an irq number is provided for the security violation interrupt,

Re: [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board

On Thu, Dec 22, 2016 at 04:02:35AM +0800, Icenowy Zheng wrote: > Lichee Pi One is a low-cost Allwinner A13-based development board, with > an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard > RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO > headers and two

Re: Inlined functions in perf report

Could you see the inline if you use the addr2line command? For example, addr2line -e -i For example, in my case, root@skl:/home/jinyao/skl-ws/perf-dev/lck-2867/test# addr2line -e ./test2 -i 40052d /usr/include/x86_64-linux-gnu/bits/stdio2.h:104

Re: Inlined functions in perf report

Could you see the inline if you use the addr2line command? For example, addr2line -e -i For example, in my case, root@skl:/home/jinyao/skl-ws/perf-dev/lck-2867/test# addr2line -e ./test2 -i 40052d /usr/include/x86_64-linux-gnu/bits/stdio2.h:104

Re: [PATCH 2/2] net: wireless: fix to uses struct

22.12.2016, 00:34, "Paul Bolle" : > On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote: >>  I compiled and didn't to errors. > > Really? I'm very sorry. The "regulatory_request" is defined a static struct. I missed. line: static struct regulatory_request

Re: [PATCH 2/2] net: wireless: fix to uses struct

22.12.2016, 00:34, "Paul Bolle" : > On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote: >>  I compiled and didn't to errors. > > Really? I'm very sorry. The "regulatory_request" is defined a static struct. I missed. line: static struct regulatory_request core_request_world = { I send to

Re: [PATCH 1/3] dt-bindings: add vendor prefix for Lichee Pi

On Thu, Dec 22, 2016 at 04:02:33AM +0800, Icenowy Zheng wrote: > Lichee Pi is a new "Pi"-named development board series. > > Currently available device, Lichee Pi One, is by only one person as > night job, so the device series name is chosen to be the vendor prefix. > > Signed-off-by: Icenowy

Re: [PATCH 1/3] dt-bindings: add vendor prefix for Lichee Pi

On Thu, Dec 22, 2016 at 04:02:33AM +0800, Icenowy Zheng wrote: > Lichee Pi is a new "Pi"-named development board series. > > Currently available device, Lichee Pi One, is by only one person as > night job, so the device series name is chosen to be the vendor prefix. > > Signed-off-by: Icenowy

[PATCH] arm64: Don't trace __switch_to if function graph tracer is enabled

Function graph tracer shows negative time (wrap around) when tracing __switch_to if the nosleep-time trace option is enabled. Time compensation for nosleep-time is done by an ftrace probe on sched_switch. This doesn't work well for the following events (with letters representing timestamps): A -

Re: [PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor

Hi! > Thanks for the update. > > On Wed, Dec 14, 2016 at 01:24:51PM +0100, Pavel Machek wrote: > ... > > +static int et8ek8_set_ctrl(struct v4l2_ctrl *ctrl) > > +{ > > + struct et8ek8_sensor *sensor = > > + container_of(ctrl->handler, struct et8ek8_sensor, ctrl_handler); > > + > > +

Re: [PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor

Hi! > Thanks for the update. > > On Wed, Dec 14, 2016 at 01:24:51PM +0100, Pavel Machek wrote: > ... > > +static int et8ek8_set_ctrl(struct v4l2_ctrl *ctrl) > > +{ > > + struct et8ek8_sensor *sensor = > > + container_of(ctrl->handler, struct et8ek8_sensor, ctrl_handler); > > + > > +

[PATCH] arm64: Don't trace __switch_to if function graph tracer is enabled

Function graph tracer shows negative time (wrap around) when tracing __switch_to if the nosleep-time trace option is enabled. Time compensation for nosleep-time is done by an ftrace probe on sched_switch. This doesn't work well for the following events (with letters representing timestamps): A -

Re: [PATCH 2/2] net: wireless: fix to uses struct

On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote: > I compiled and didn't to errors. Really? $ make net/wireless/reg.o CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h

Re: [PATCH 2/2] net: wireless: fix to uses struct

On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote: > I compiled and didn't to errors. Really? $ make net/wireless/reg.o CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h

Re: [PATCH] x86/efi Fix regression in efi_arch_mem_reserve

On Wed, 21 Dec, at 02:11:38PM, Petr Oros wrote: > Booting on EFI with ESRT table has been stop since commit: > 8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc() > > This is caused by this commit: > 816e761 efi: Allow drivers to reserve boot services forever > > Problem

Re: [PATCH] x86/efi Fix regression in efi_arch_mem_reserve

On Wed, 21 Dec, at 02:11:38PM, Petr Oros wrote: > Booting on EFI with ESRT table has been stop since commit: > 8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc() > > This is caused by this commit: > 816e761 efi: Allow drivers to reserve boot services forever > > Problem

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 11:27 PM, Theodore Ts'o wrote: > And "with enough registers" includes ARM and MIPS, right? So the only > real problem is 32-bit x86, and you're right, at that point, only > people who might care are people who are using a space-radiation > hardened 386 ---

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 11:27 PM, Theodore Ts'o wrote: > And "with enough registers" includes ARM and MIPS, right? So the only > real problem is 32-bit x86, and you're right, at that point, only > people who might care are people who are using a space-radiation > hardened 386 --- and they're not

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote: > SipHash annihilates the competition on 64-bit superscalar hardware. > SipHash dominates the field on 64-bit in-order hardware. > SipHash wins easily on 32-bit hardware *with enough registers*. > On register-starved 32-bit machines,

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote: > SipHash annihilates the competition on 64-bit superscalar hardware. > SipHash dominates the field on 64-bit in-order hardware. > SipHash wins easily on 32-bit hardware *with enough registers*. > On register-starved 32-bit machines,

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Fri, Dec 16, 2016 at 10:59:06AM -0800, Chris Leech wrote: > Thanks Dave, > > I'm hitting a bug at scatterlist.h:140 before I even get any iSCSI > modules loaded (virtio block) so there's something else going on in the > current merge window. I'll keep an eye on it and make sure there's >

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Fri, Dec 16, 2016 at 10:59:06AM -0800, Chris Leech wrote: > Thanks Dave, > > I'm hitting a bug at scatterlist.h:140 before I even get any iSCSI > modules loaded (virtio block) so there's something else going on in the > current merge window. I'll keep an eye on it and make sure there's >

[PATCH 2/2] net: wireless: fix to uses struct

The patch fixed to struct uses in reg.c, I think doesn't need to be use to "struct". There is dataype not have to logical link and each is different definitons. I'm undecided on this patch. I compiled and didn't to errors. Signed-off-by: Ozgur Karatas ---

[PATCH 2/2] net: wireless: fix to uses struct

The patch fixed to struct uses in reg.c, I think doesn't need to be use to "struct". There is dataype not have to logical link and each is different definitons. I'm undecided on this patch. I compiled and didn't to errors. Signed-off-by: Ozgur Karatas --- net/wireless/reg.c | 10

[PATCH 1/2] net: wireless: fixed to checkpatch errors

Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next line. The patch fix to readability and Coding Style. Sİgned-off-by: Ozgur Karatas --- net/wireless/chan.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git

[PATCH 1/2] net: wireless: fixed to checkpatch errors

Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next line. The patch fix to readability and Coding Style. Sİgned-off-by: Ozgur Karatas --- net/wireless/chan.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/wireless/chan.c

[PATCH 2/2] power: supply: bq24735: bring down the noise level

If there is no ti,ac-detect-gpios configured, it is normal to have failed reads of the options register. So, hold back on the log spamming. Signed-off-by: Peter Rosin --- drivers/power/supply/bq24735-charger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/2] power: supply: bq24735: bring down the noise level

If there is no ti,ac-detect-gpios configured, it is normal to have failed reads of the options register. So, hold back on the log spamming. Signed-off-by: Peter Rosin --- drivers/power/supply/bq24735-charger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 0/2] power: supply: bq24735: poll register if no ac-detect gpio

Hi! My patch [1] "power: supply: bq24735-charger: allow chargers to share the ac-detect gpio" is perhaps a bit hard to digest. And while I still think some way of sharing the ac-detect gpio is worthwhile, I thought of another way to solve the problem at hand. Instead of polling a shared gpio,

[PATCH 0/2] power: supply: bq24735: poll register if no ac-detect gpio

Hi! My patch [1] "power: supply: bq24735-charger: allow chargers to share the ac-detect gpio" is perhaps a bit hard to digest. And while I still think some way of sharing the ac-detect gpio is worthwhile, I thought of another way to solve the problem at hand. Instead of polling a shared gpio,

Re: [PATCH] MAINTAINERS: add myself as maintainer of fbdev

On Wed, Dec 21, 2016 at 05:50:05PM +0100, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, December 21, 2016 03:06:55 PM Sudip Mukherjee wrote: > > On Thu, Dec 15, 2016 at 03:45:47PM +0100, Bartlomiej Zolnierkiewicz wrote: > > > I would like to help with fbdev maintenance. I can

Re: [PATCH] MAINTAINERS: add myself as maintainer of fbdev

On Wed, Dec 21, 2016 at 05:50:05PM +0100, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, December 21, 2016 03:06:55 PM Sudip Mukherjee wrote: > > On Thu, Dec 15, 2016 at 03:45:47PM +0100, Bartlomiej Zolnierkiewicz wrote: > > > I would like to help with fbdev maintenance. I can

Re: [GIT pull] x86/cache: Updates for 4.10

On Tue, Dec 13, 2016, Thomas Gleixner wrote: > On Mon, 12 Dec 2016, Linus Torvalds wrote: > On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner wrote: >> It looks pretty self-contained (good), but it also looks majorly >> strange. I will have to think about

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Wed, Dec 21, 2016 at 1:24 PM, Dave Chinner wrote: > On Wed, Dec 21, 2016 at 08:53:46AM -0800, Dan Williams wrote: >> On Tue, Dec 20, 2016 at 4:40 PM, Darrick J. Wong >> wrote: >> > On Mon, Dec 19, 2016 at 05:18:40PM -0800, Dan Williams wrote: >>

Re: [GIT pull] x86/cache: Updates for 4.10

On Tue, Dec 13, 2016, Thomas Gleixner wrote: > On Mon, 12 Dec 2016, Linus Torvalds wrote: > On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner wrote: >> It looks pretty self-contained (good), but it also looks majorly >> strange. I will have to think about this. What are the main/expected >>

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Wed, Dec 21, 2016 at 1:24 PM, Dave Chinner wrote: > On Wed, Dec 21, 2016 at 08:53:46AM -0800, Dan Williams wrote: >> On Tue, Dec 20, 2016 at 4:40 PM, Darrick J. Wong >> wrote: >> > On Mon, Dec 19, 2016 at 05:18:40PM -0800, Dan Williams wrote: >> >> On Mon, Dec 19, 2016 at 5:09 PM, Darrick J.

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote: > > Change livepatch to use a basic per-task consistency model. This is the > > foundation which will eventually enable us to patch those ~10% of > > security patches which change

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote: > > Change livepatch to use a basic per-task consistency model. This is the > > foundation which will eventually enable us to patch those ~10% of > > security patches which change

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Wed, Dec 21, 2016 at 08:53:46AM -0800, Dan Williams wrote: > On Tue, Dec 20, 2016 at 4:40 PM, Darrick J. Wong > wrote: > > On Mon, Dec 19, 2016 at 05:18:40PM -0800, Dan Williams wrote: > >> On Mon, Dec 19, 2016 at 5:09 PM, Darrick J. Wong > >>

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Wed, Dec 21, 2016 at 08:53:46AM -0800, Dan Williams wrote: > On Tue, Dec 20, 2016 at 4:40 PM, Darrick J. Wong > wrote: > > On Mon, Dec 19, 2016 at 05:18:40PM -0800, Dan Williams wrote: > >> On Mon, Dec 19, 2016 at 5:09 PM, Darrick J. Wong > >> wrote: > >> > On Mon, Dec 19, 2016 at 02:11:49PM

Re: Patch to include/linux/kernel.h breaks 3rd party modules.

+++ Valdis Kletnieks [21/12/16 15:42 -0500]: Yes, I know that usually out-of-tree modules are on their own. However, this one may require a rethink.. (Sorry for not catching this sooner, I hadn't tried to deal with the affected module since this patch hit linux-next in next-20161128) commit

Re: Patch to include/linux/kernel.h breaks 3rd party modules.

+++ Valdis Kletnieks [21/12/16 15:42 -0500]: Yes, I know that usually out-of-tree modules are on their own. However, this one may require a rethink.. (Sorry for not catching this sooner, I hadn't tried to deal with the affected module since this patch hit linux-next in next-20161128) commit

Re: [PATCH] at86rf230: Allow slow GPIO pins for "rstn"

Hello. On 21/12/16 19:30, Chris Healy wrote: On Dec 21, 2016 5:11 AM, "Stefan Schmidt" > wrote: Hello. On 19/12/16 00:25, Andrey Smirnov wrote: Driver code never touches "rstn" signal in atomic context, so

Re: [PATCH] at86rf230: Allow slow GPIO pins for "rstn"

Hello. On 21/12/16 19:30, Chris Healy wrote: On Dec 21, 2016 5:11 AM, "Stefan Schmidt" mailto:ste...@osg.samsung.com>> wrote: Hello. On 19/12/16 00:25, Andrey Smirnov wrote: Driver code never touches "rstn" signal in atomic context, so there's no need to

Re: WARNING: CPU: 3 PID: 1568 at kernel/sched/core.c:7738 __might_sleep+0x69/0x7e

On Wed 21-12-16 11:24:47, Cong Wang wrote: > On Wed, Dec 21, 2016 at 2:47 AM, Michal Hocko wrote: > > > > Is there anything I could test? > > I am working on a patchset, will send them for you to test. Meanwhile, > if you could provide me a reproducer, that would help a lot.

Re: WARNING: CPU: 3 PID: 1568 at kernel/sched/core.c:7738 __might_sleep+0x69/0x7e

On Wed 21-12-16 11:24:47, Cong Wang wrote: > On Wed, Dec 21, 2016 at 2:47 AM, Michal Hocko wrote: > > > > Is there anything I could test? > > I am working on a patchset, will send them for you to test. Meanwhile, > if you could provide me a reproducer, that would help a lot. I just boot my kvm

Patch to include/linux/kernel.h breaks 3rd party modules.

Yes, I know that usually out-of-tree modules are on their own. However, this one may require a rethink.. (Sorry for not catching this sooner, I hadn't tried to deal with the affected module since this patch hit linux-next in next-20161128) commit 7fd8329ba502ef76dd91db561c7aed696b2c7720 Author:

Patch to include/linux/kernel.h breaks 3rd party modules.

Yes, I know that usually out-of-tree modules are on their own. However, this one may require a rethink.. (Sorry for not catching this sooner, I hadn't tried to deal with the affected module since this patch hit linux-next in next-20161128) commit 7fd8329ba502ef76dd91db561c7aed696b2c7720 Author:

Re: [PATCH] net: fddi: skfp: use %p format specifier for addresses rather than %x

From: Colin King Date: Wed, 21 Dec 2016 16:03:23 + > From: Colin Ian King > > Trivial fix: Addresses should be printed using the %p format specifier > rather than using %x. > > Signed-off-by: Colin Ian King

Re: [PATCH] net: fddi: skfp: use %p format specifier for addresses rather than %x

From: Colin King Date: Wed, 21 Dec 2016 16:03:23 + > From: Colin Ian King > > Trivial fix: Addresses should be printed using the %p format specifier > rather than using %x. > > Signed-off-by: Colin Ian King Applied.

Re: [PATCH 5/5] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation

Hi, On 12/21/2016 07:49 PM, Pavel Machek wrote: > Hi! > > Milo if sysfs is used can't the old userspace be mapped to use the new > sysfs interface through a wrapper of some sort ? What exactly would be > needed to ensure old userspace will not break? LP5521 and LP5523 have

[PATCH v4 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

The Marvell devices may have many gpio pins, and hence for wakeup on these out-of-band pins, the chip needs to be told which pin is to be used for wakeup, using an hci command. Thus, we read the pin number etc from the device tree node and send a command to the chip. Signed-off-by: Rajat Jain

[PATCH v4 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that can be connected to a gpio on the CPU side, and can be used to wakeup the host out-of-band. This can be useful in situations where the in-band wakeup is not possible or not preferable (e.g. the in-band wakeup may require the USB

[PATCH v4 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

The Marvell devices may have many gpio pins, and hence for wakeup on these out-of-band pins, the chip needs to be told which pin is to be used for wakeup, using an hci command. Thus, we read the pin number etc from the device tree node and send a command to the chip. Signed-off-by: Rajat Jain

[PATCH v4 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that can be connected to a gpio on the CPU side, and can be used to wakeup the host out-of-band. This can be useful in situations where the in-band wakeup is not possible or not preferable (e.g. the in-band wakeup may require the USB

Re: [PATCH 5/5] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation

Hi, On 12/21/2016 07:49 PM, Pavel Machek wrote: > Hi! > > Milo if sysfs is used can't the old userspace be mapped to use the new > sysfs interface through a wrapper of some sort ? What exactly would be > needed to ensure old userspace will not break? LP5521 and LP5523 have

[PATCH v4 1/3] Bluetooth: btusb: Use an error label for error paths

Use a label to remove the repetetive cleanup, for error cases. Signed-off-by: Rajat Jain Reviewed-by: Brian Norris --- v4: same as v3 v3: Added Brian's "Reviewed-by" v2: same as v1 drivers/bluetooth/btusb.c | 19 +-- 1 file

[PATCH v4 1/3] Bluetooth: btusb: Use an error label for error paths

Use a label to remove the repetetive cleanup, for error cases. Signed-off-by: Rajat Jain Reviewed-by: Brian Norris --- v4: same as v3 v3: Added Brian's "Reviewed-by" v2: same as v1 drivers/bluetooth/btusb.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git

[PATCHv2] crypto: testmgr: Use heap buffer for acomp test input

Christopher Covington reported a crash on aarch64 on recent Fedora kernels: kernel BUG at ./include/linux/scatterlist.h:140! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162 Hardware name:

[PATCHv2] crypto: testmgr: Use heap buffer for acomp test input

Christopher Covington reported a crash on aarch64 on recent Fedora kernels: kernel BUG at ./include/linux/scatterlist.h:140! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162 Hardware name:

Re: [patch 10/10] irqchip/armada-xp: Consolidate hotplug state space

On Wed, 21 Dec 2016, Thomas Petazzoni wrote: > On Wed, 21 Dec 2016 20:19:57 +0100, Thomas Gleixner wrote: > > The mpic is either the main interrupt controller or sits behind a GIC. But > > there is no way that both variants are available on the same system. > > By "both variants", you mean the

Re: [patch 10/10] irqchip/armada-xp: Consolidate hotplug state space

On Wed, 21 Dec 2016, Thomas Petazzoni wrote: > On Wed, 21 Dec 2016 20:19:57 +0100, Thomas Gleixner wrote: > > The mpic is either the main interrupt controller or sits behind a GIC. But > > there is no way that both variants are available on the same system. > > By "both variants", you mean the

BUG/panic in ctnetlink_conntrack_event in 4.8.11

Hi all, I've encountered this BUG three times in the last few days, though I must admit I've only captured the trace once so far so I can't be completely certain it was exactly this the last few times. I did not experience this with a 4.7 kernel; it only seemed to start with 4.8. For some

BUG/panic in ctnetlink_conntrack_event in 4.8.11

Hi all, I've encountered this BUG three times in the last few days, though I must admit I've only captured the trace once so far so I can't be completely certain it was exactly this the last few times. I did not experience this with a 4.7 kernel; it only seemed to start with 4.8. For some

Re: [Patch v11 4/5] x86/cpufeature: enable RING3MWAIT for Knights Landing

On Tue, 20 Dec 2016, Grzegorz Andrejczuk wrote: So how am I supposed to know which version of these patches is the right one? Both subject lines are identical. > Enable ring 3 MONITOR/MWAIT for Intel Xeon Phi x200 > codenamed Knights Landing. > > The patch: >From your cover letter:

Re: [Patch v11 4/5] x86/cpufeature: enable RING3MWAIT for Knights Landing

On Tue, 20 Dec 2016, Grzegorz Andrejczuk wrote: So how am I supposed to know which version of these patches is the right one? Both subject lines are identical. > Enable ring 3 MONITOR/MWAIT for Intel Xeon Phi x200 > codenamed Knights Landing. > > The patch: >From your cover letter:

Re: [PATCH v11 1/5] x86/msr: add MSR_MISC_FEATURE_ENABLES and RING3MWAIT bit

On Tue, 20 Dec 2016, Grzegorz Andrejczuk wrote: > > diff --git a/arch/x86/include/asm/msr-index.h > b/arch/x86/include/asm/msr-index.h > index 78f3760..55ffae0 100644 > --- a/arch/x86/include/asm/msr-index.h > +++ b/arch/x86/include/asm/msr-index.h > @@ -539,6 +539,12 @@ > #define

Re: [PATCH v11 1/5] x86/msr: add MSR_MISC_FEATURE_ENABLES and RING3MWAIT bit

On Tue, 20 Dec 2016, Grzegorz Andrejczuk wrote: > > diff --git a/arch/x86/include/asm/msr-index.h > b/arch/x86/include/asm/msr-index.h > index 78f3760..55ffae0 100644 > --- a/arch/x86/include/asm/msr-index.h > +++ b/arch/x86/include/asm/msr-index.h > @@ -539,6 +539,12 @@ > #define

[PATCH 3/3] KVM: nVMX: refactor nested_vmx_entry_failure()

Change recurring pattern leave_guest_mode(vcpu); vmx_load_vmcs01(vcpu); nested_vmx_entry_failure(vcpu, ...); return 1; into return nested_vmx_entry_failure(vcpu, ...) Signed-off-by: Radim Krčmář --- arch/x86/kvm/vmx.c | 46

[PATCH 3/3] KVM: nVMX: refactor nested_vmx_entry_failure()

Change recurring pattern leave_guest_mode(vcpu); vmx_load_vmcs01(vcpu); nested_vmx_entry_failure(vcpu, ...); return 1; into return nested_vmx_entry_failure(vcpu, ...) Signed-off-by: Radim Krčmář --- arch/x86/kvm/vmx.c | 46 -- 1 file

[PATCH 0/3] KVM: nVMX: fix one guest vmcs check and refactor a bunch more

v1: Applies after David's "KVM: nVMX: fix instruction skipping during emulated vm-entry". Radim Krčmář (3): KVM: nVMX: fix handling of invalid host efer KVM: nVMX: colocate guest vmcs checks KVM: nVMX: refactor nested_vmx_entry_failure() arch/x86/kvm/vmx.c | 92

[PATCH 1/3] KVM: nVMX: fix handling of invalid host efer

Host state must be checked before attempting vm entry, which means it throws a different error. Signed-off-by: Radim Krčmář --- arch/x86/kvm/vmx.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/x86/kvm/vmx.c

[PATCH 2/3] KVM: nVMX: colocate guest vmcs checks

Few guest checks were done before entering the guest, for which there is no reason. Having them all in one place will be simpler. Signed-off-by: Radim Krčmář --- arch/x86/kvm/vmx.c | 72 +- 1 file changed, 39

[PATCH 0/3] KVM: nVMX: fix one guest vmcs check and refactor a bunch more

v1: Applies after David's "KVM: nVMX: fix instruction skipping during emulated vm-entry". Radim Krčmář (3): KVM: nVMX: fix handling of invalid host efer KVM: nVMX: colocate guest vmcs checks KVM: nVMX: refactor nested_vmx_entry_failure() arch/x86/kvm/vmx.c | 92

[PATCH 1/3] KVM: nVMX: fix handling of invalid host efer

Host state must be checked before attempting vm entry, which means it throws a different error. Signed-off-by: Radim Krčmář --- arch/x86/kvm/vmx.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c

[PATCH 2/3] KVM: nVMX: colocate guest vmcs checks

Few guest checks were done before entering the guest, for which there is no reason. Having them all in one place will be simpler. Signed-off-by: Radim Krčmář --- arch/x86/kvm/vmx.c | 72 +- 1 file changed, 39 insertions(+), 33 deletions(-)

Re: [patch 10/10] irqchip/armada-xp: Consolidate hotplug state space

Hello, On Wed, 21 Dec 2016 20:19:57 +0100, Thomas Gleixner wrote: > The mpic is either the main interrupt controller or sits behind a GIC. But > there is no way that both variants are available on the same system. By "both variants", you mean the MPIC acting as the main interrupt controller on

Re: [patch 10/10] irqchip/armada-xp: Consolidate hotplug state space

Hello, On Wed, 21 Dec 2016 20:19:57 +0100, Thomas Gleixner wrote: > The mpic is either the main interrupt controller or sits behind a GIC. But > there is no way that both variants are available on the same system. By "both variants", you mean the MPIC acting as the main interrupt controller on

Re: [PATCH 3/3] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

On 12/20/2016 08:52 PM, Joe Perches wrote: > On Tue, 2016-12-20 at 19:53 +0100, Sven Schmidt wrote: >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. >> The kernel module is inspired by the previous work by Chanho Min. >> The updated LZ4 module will not break existing code

Re: [PATCH 3/3] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

On 12/20/2016 08:52 PM, Joe Perches wrote: > On Tue, 2016-12-20 at 19:53 +0100, Sven Schmidt wrote: >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. >> The kernel module is inspired by the previous work by Chanho Min. >> The updated LZ4 module will not break existing code

RE: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

> -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, December 21, 2016 10:03 AM > To: Christoph Hellwig > Cc: Paolo Bonzini ; Roman Kagan > ; Radim Krčmář

RE: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

> -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, December 21, 2016 10:03 AM > To: Christoph Hellwig > Cc: Paolo Bonzini ; Roman Kagan > ; Radim Krčmář ; KY > Srinivasan ; Vitaly Kuznetsov > ; k...@vger.kernel.org; Denis V . Lunev > ;

[PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock

As per the device tree binding the apq8064 scm node requires the core clock to be specified, so add this. Cc: John Stultz Signed-off-by: Bjorn Andersson --- arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff

Re: [RFC][PATCH] make global bitlock waitqueues per-node

On Wed, Dec 21, 2016 at 11:01 AM, Nicholas Piggin wrote: > Peter's patch is less code and in that regard a bit nicer. I tried > going that way once, but I just thought it was a bit too sloppy to > do nicely with wait bit APIs. So I have to admit that when I read through your

[PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock

As per the device tree binding the apq8064 scm node requires the core clock to be specified, so add this. Cc: John Stultz Signed-off-by: Bjorn Andersson --- arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi

Re: [RFC][PATCH] make global bitlock waitqueues per-node

On Wed, Dec 21, 2016 at 11:01 AM, Nicholas Piggin wrote: > Peter's patch is less code and in that regard a bit nicer. I tried > going that way once, but I just thought it was a bit too sloppy to > do nicely with wait bit APIs. So I have to admit that when I read through your and PeterZ's patches

[PATCH 2/5] ARM: dts: qcom: apq8064: Add riva-pil node

Add nodes for the Riva PIL, IRIS RF module, BT and WiFI services exposed by the Riva firmware and the related memory reserve. Also provides pinctrl nodes for devices enabling the riva-pil. Cc: John Stultz Signed-off-by: Bjorn Andersson ---

[PATCH 2/5] ARM: dts: qcom: apq8064: Add riva-pil node

Add nodes for the Riva PIL, IRIS RF module, BT and WiFI services exposed by the Riva firmware and the related memory reserve. Also provides pinctrl nodes for devices enabling the riva-pil. Cc: John Stultz Signed-off-by: Bjorn Andersson --- arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 18

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