Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

On Wed, Dec 28, 2016 at 12:41 AM, wrote: > On Wed, 28 Dec 2016 00:15:30 +0200, Andy Shevchenko said: >> On Tue, Dec 27, 2016 at 3:51 PM, Pali Rohár wrote: > >> > I have no idea how to do it (properly) outside of i2c-i801.c file. >> >> I doubt we

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

On Wed, Dec 28, 2016 at 12:41 AM, wrote: > On Wed, 28 Dec 2016 00:15:30 +0200, Andy Shevchenko said: >> On Tue, Dec 27, 2016 at 3:51 PM, Pali Rohár wrote: > >> > I have no idea how to do it (properly) outside of i2c-i801.c file. >> >> I doubt we need a single line of code for this. See [1] and

[PATCH 02/18] ACPICA: Hardware: Remove bit_offset masking support

ACPICA commit bc7c5291865e099ce01f345d0265f0eba6997e23 This linuxized ACPICA commit is a back port result of the following Linux commit: Commit c3bc26d4b4e36f0dc458eea8b1f722d8a8d9addd Subject: ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support in acpi_hw_read() The

[PATCH 02/18] ACPICA: Hardware: Remove bit_offset masking support

ACPICA commit bc7c5291865e099ce01f345d0265f0eba6997e23 This linuxized ACPICA commit is a back port result of the following Linux commit: Commit c3bc26d4b4e36f0dc458eea8b1f722d8a8d9addd Subject: ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support in acpi_hw_read() The

Re: [RFC 1/3] abi_spec: basic definitions of constraints, args and syscalls

On Tue, Dec 27, 2016 at 6:23 PM, wrote: > On Mon, Dec 12, 2016 at 11:29:35AM +0100, Dmitry Vyukov wrote: >> On Wed, Nov 23, 2016 at 3:59 PM, wrote: >> > On Mon, Nov 21, 2016 at 03:48:17PM +0100, Dmitry Vyukov wrote: >> > I imagine that

[PATCH 06/18] ACPICA: Macro header: Fix some typos in comments. No functional change

From: Bob Moore ACPICA commit efc97d1d209947d6990ec81a192c6b2589d3e368 Link: https://github.com/acpica/acpica/commit/efc97d1 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acmacros.h | 14

[PATCH 08/18] ACPICA: Linux-specific header: Add support for s390x compilation.

From: Colin Ian King ACPICA commit ecac9504e32d3b501c8cb021afb253b4a83fc82f Adds s390x as a 64-bit architecture. Link: https://github.com/acpica/acpica/commit/ecac9504 Signed-off-by: Colin Ian King Signed-off-by: Bob Moore

[PATCH 08/18] ACPICA: Linux-specific header: Add support for s390x compilation.

From: Colin Ian King ACPICA commit ecac9504e32d3b501c8cb021afb253b4a83fc82f Adds s390x as a 64-bit architecture. Link: https://github.com/acpica/acpica/commit/ecac9504 Signed-off-by: Colin Ian King Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/platform/aclinux.h | 3 ++-

Re: [RFC 1/3] abi_spec: basic definitions of constraints, args and syscalls

On Tue, Dec 27, 2016 at 6:23 PM, wrote: > On Mon, Dec 12, 2016 at 11:29:35AM +0100, Dmitry Vyukov wrote: >> On Wed, Nov 23, 2016 at 3:59 PM, wrote: >> > On Mon, Nov 21, 2016 at 03:48:17PM +0100, Dmitry Vyukov wrote: >> > I imagine that this will be handled by specific logical type handlers

[PATCH 06/18] ACPICA: Macro header: Fix some typos in comments. No functional change

From: Bob Moore ACPICA commit efc97d1d209947d6990ec81a192c6b2589d3e368 Link: https://github.com/acpica/acpica/commit/efc97d1 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acmacros.h | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH 05/18] ACPICA: Hardware: Sort access bit width algorithm

ACPICA commit 365b321a31cb701957c055cae2d2161577147252 GAS can be in register or register region format, so we need to improve our "register" format detection code in order not to regress. Such detection may be still experimental, and is generated according to the current known facts. Lv Zheng.

[PATCH 04/18] ACPICA: Utilities: Add power of two rounding support

ACPICA commit cbb0294649cbd7e8bd6107e4329461a6a7a0d967 This patch adds power of two rounding support up to 32 bits. The result of the shift operations rearching to the boundary of the cpu word is unpredicatable, so 64-bit roundings are not supported in order to make sure no rounded shift-overs.

[PATCH 05/18] ACPICA: Hardware: Sort access bit width algorithm

ACPICA commit 365b321a31cb701957c055cae2d2161577147252 GAS can be in register or register region format, so we need to improve our "register" format detection code in order not to regress. Such detection may be still experimental, and is generated according to the current known facts. Lv Zheng.

[PATCH 04/18] ACPICA: Utilities: Add power of two rounding support

ACPICA commit cbb0294649cbd7e8bd6107e4329461a6a7a0d967 This patch adds power of two rounding support up to 32 bits. The result of the shift operations rearching to the boundary of the cpu word is unpredicatable, so 64-bit roundings are not supported in order to make sure no rounded shift-overs.

[PATCH 16/18] ACPICA: Fix a problem with recent extra support for control method invocations

From: Bob Moore ACPICA commit b7dae343fbb8c392999a66f5e08be5744a5d07e2 This change fixes a problem with the recent support that enables control method invocations as Target operands to many ASL operators. Eliminates errors similar to: Needed type [Reference], found

[PATCH 09/18] ACPICA: MSVC: Fix MSVC6 build issues

ACPICA commit fa0680030a2969e1085563da633713e1c321637c Build environment has changed because of new improvements: 1. New files are split 2. New inclusion order This patch updates MSVC project files accordingly. Linux is not affected by this patch. Link:

[PATCH 16/18] ACPICA: Fix a problem with recent extra support for control method invocations

From: Bob Moore ACPICA commit b7dae343fbb8c392999a66f5e08be5744a5d07e2 This change fixes a problem with the recent support that enables control method invocations as Target operands to many ASL operators. Eliminates errors similar to: Needed type [Reference], found [Processor] Link:

[PATCH 09/18] ACPICA: MSVC: Fix MSVC6 build issues

ACPICA commit fa0680030a2969e1085563da633713e1c321637c Build environment has changed because of new improvements: 1. New files are split 2. New inclusion order This patch updates MSVC project files accordingly. Linux is not affected by this patch. Link:

[PATCH 07/18] ACPICA: Hardware: Add sleep register hooks

ACPICA commit ba665dc8e20d9f7730466a659564dd6c557a6cbc In Linux, para-virtualization implmentation hooks critical register writes to prevent real hardware operations. This increases divergences when the sleep registers are cracked in Linux resident ACPICA. This patch tries to introduce a single

[PATCH 00/18] ACPICA 20161222 Release

The 20161222 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + allyes 2. i386 + allno 3. i386 + default + ACPI_DEBUGGER=y 4. i386 + default +

[PATCH 03/18] ACPICA: Hardware: Add access_width/bit_offset support in acpi_hw_write()

ACPICA commit 1ecab20bbe69a176dfb6da7210fe77aa6b3ad680 This patch adds access_width/bit_offset support in acpi_hw_write(). Lv Zheng. Link: https://github.com/acpica/acpica/commit/1ecab20b Signed-off-by: Lv Zheng Signed-off-by: Bob Moore ---

[PATCH 07/18] ACPICA: Hardware: Add sleep register hooks

ACPICA commit ba665dc8e20d9f7730466a659564dd6c557a6cbc In Linux, para-virtualization implmentation hooks critical register writes to prevent real hardware operations. This increases divergences when the sleep registers are cracked in Linux resident ACPICA. This patch tries to introduce a single

[PATCH 00/18] ACPICA 20161222 Release

The 20161222 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + allyes 2. i386 + allno 3. i386 + default + ACPI_DEBUGGER=y 4. i386 + default +

[PATCH 03/18] ACPICA: Hardware: Add access_width/bit_offset support in acpi_hw_write()

ACPICA commit 1ecab20bbe69a176dfb6da7210fe77aa6b3ad680 This patch adds access_width/bit_offset support in acpi_hw_write(). Lv Zheng. Link: https://github.com/acpica/acpica/commit/1ecab20b Signed-off-by: Lv Zheng Signed-off-by: Bob Moore --- drivers/acpi/acpica/hwregs.c | 62

[PATCH 18/18] ACPICA: Update version to 20161222

From: Bob Moore ACPICA commit 0d5a056877c2e37e0bfce8d262cec339dc8d55fd ACPICA commit 5bea13a9e1eb2a0da99600d181afbc5fa075a9eb Version 20161222 Link: https://github.com/acpica/acpica/commit/0d5a0568 Link: https://github.com/acpica/acpica/commit/5bea13a9 Signed-off-by:

[PATCH 15/18] ACPICA: Parser: Allow method invocations as target operands

From: Bob Moore ACPICA commit a6cca7a4786cdbfd29cea67e84b5b01a8ae6ff1c Method invocations as target operands are allowed as target operands in the ASL grammar. This change implements support for this. Method must return a reference for this to work properly at runtime,

[PATCH 17/18] ACPICA: Parser: Update parse info table for some operators

From: Bob Moore ACPICA commit b90e39948954ff400cff1a3f8effddb67f15460b Operand for deref_of should not have been a term_arg, should be super_name. Rename NAME_OR_REF to SIMPLENAME. Link: https://github.com/acpica/acpica/commit/b90e3994 Signed-off-by: Bob Moore

[PATCH 18/18] ACPICA: Update version to 20161222

From: Bob Moore ACPICA commit 0d5a056877c2e37e0bfce8d262cec339dc8d55fd ACPICA commit 5bea13a9e1eb2a0da99600d181afbc5fa075a9eb Version 20161222 Link: https://github.com/acpica/acpica/commit/0d5a0568 Link: https://github.com/acpica/acpica/commit/5bea13a9 Signed-off-by: Bob Moore Signed-off-by:

[PATCH 15/18] ACPICA: Parser: Allow method invocations as target operands

From: Bob Moore ACPICA commit a6cca7a4786cdbfd29cea67e84b5b01a8ae6ff1c Method invocations as target operands are allowed as target operands in the ASL grammar. This change implements support for this. Method must return a reference for this to work properly at runtime, however. Link:

[PATCH 17/18] ACPICA: Parser: Update parse info table for some operators

From: Bob Moore ACPICA commit b90e39948954ff400cff1a3f8effddb67f15460b Operand for deref_of should not have been a term_arg, should be super_name. Rename NAME_OR_REF to SIMPLENAME. Link: https://github.com/acpica/acpica/commit/b90e3994 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng ---

[PATCH 13/18] ACPICA: Resources: Not a valid resource if buffer length too long

From: Bob Moore ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1 ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e The declared buffer length must be the same as the length of the byte initializer list,

[PATCH 13/18] ACPICA: Resources: Not a valid resource if buffer length too long

From: Bob Moore ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1 ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e The declared buffer length must be the same as the length of the byte initializer list, otherwise not a valid

[PATCH 12/18] ACPICA: Utilities: Update debug output

From: Bob Moore ACPICA commit 082b5b3ee31f74735e166858eeda025288604a5a Enhancement of miscellaneous debug output. Link: https://github.com/acpica/acpica/commit/082b5b3e Signed-off-by: Bob Moore Signed-off-by: Lv Zheng ---

[PATCH 10/18] ACPICA: EFI: Add efihello demo application

ACPICA commit 3fcc59f4755607dd066ac8ef869f0aa95e871b84 This patch adds a demo EFI application for stdin/stdout testing. This utility can be used to narrow down root causes of porting issues. Lv Zheng. Linux is not affected by this patch. Link: https://github.com/acpica/acpica/commit/3fcc59f4

[PATCH 11/18] ACPICA: Disassembler: Add Switch/Case disassembly support

From: "David E. Box" ACPICA commit 0f6cc80e8af519a3c31184367b0a9be7a399cf53 iasl compiles Switch/Case statements into a single iteration While loop with If/Else statements. This patch adds support to recognize this generated compiler output and disassemble it back

[PATCH 12/18] ACPICA: Utilities: Update debug output

From: Bob Moore ACPICA commit 082b5b3ee31f74735e166858eeda025288604a5a Enhancement of miscellaneous debug output. Link: https://github.com/acpica/acpica/commit/082b5b3e Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/utdecode.c | 4 ++--

[PATCH 10/18] ACPICA: EFI: Add efihello demo application

ACPICA commit 3fcc59f4755607dd066ac8ef869f0aa95e871b84 This patch adds a demo EFI application for stdin/stdout testing. This utility can be used to narrow down root causes of porting issues. Lv Zheng. Linux is not affected by this patch. Link: https://github.com/acpica/acpica/commit/3fcc59f4

[PATCH 11/18] ACPICA: Disassembler: Add Switch/Case disassembly support

From: "David E. Box" ACPICA commit 0f6cc80e8af519a3c31184367b0a9be7a399cf53 iasl compiles Switch/Case statements into a single iteration While loop with If/Else statements. This patch adds support to recognize this generated compiler output and disassemble it back to the original Switch

Re: Intel Wireless 7260 failed to work

On Wed, 2016-12-28 at 11:59 +0800, Peter Xu wrote: > On Tue, Dec 27, 2016 at 09:46:55PM +0200, Kalle Valo wrote: > > Peter Xu writes: > > > > > Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well > > > with my wireless card, which is: > > > > > > Intel

Re: Intel Wireless 7260 failed to work

On Wed, 2016-12-28 at 11:59 +0800, Peter Xu wrote: > On Tue, Dec 27, 2016 at 09:46:55PM +0200, Kalle Valo wrote: > > Peter Xu writes: > > > > > Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well > > > with my wireless card, which is: > > > > > > Intel Corporation Wireless

RE: Question regarding power button of Dell XPS13

Hi, Paul > From: Paul Menzel [mailto:pmen...@molgen.mpg.de] > Subject: Question regarding power button of Dell XPS13 > > Dear Linus, dear Len, > > > I heard that you both have a Dell XPS13. I got the “revision” 9360, and > installed Debian Stretch/testing on it with Linux 4.8.15 and Linux

RE: Question regarding power button of Dell XPS13

Hi, Paul > From: Paul Menzel [mailto:pmen...@molgen.mpg.de] > Subject: Question regarding power button of Dell XPS13 > > Dear Linus, dear Len, > > > I heard that you both have a Dell XPS13. I got the “revision” 9360, and > installed Debian Stretch/testing on it with Linux 4.8.15 and Linux

Re: [PATCH] rcu: fix the OOM problem of huge IP abnormal packet traffic

Hi, Paul: I try to debug this problem and found this solution could work well for both problem scene. diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 85c5a88..dbc14a7 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -2172,7 +2172,7 @@ static int

Re: [PATCH] rcu: fix the OOM problem of huge IP abnormal packet traffic

Hi, Paul: I try to debug this problem and found this solution could work well for both problem scene. diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 85c5a88..dbc14a7 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -2172,7 +2172,7 @@ static int

RE: [PATCH v2] net: stmmac: bug fix to synchronize stmmac_open and stmmac_dvr_probe

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, December 28, 2016 12:34 AM > To: Kweh, Hock Leong > Cc: joao.pi...@synopsys.com; peppe.cavall...@st.com; > seraphin.bonna...@st.com; f.faine...@gmail.com; >

RE: [PATCH v2] net: stmmac: bug fix to synchronize stmmac_open and stmmac_dvr_probe

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, December 28, 2016 12:34 AM > To: Kweh, Hock Leong > Cc: joao.pi...@synopsys.com; peppe.cavall...@st.com; > seraphin.bonna...@st.com; f.faine...@gmail.com; > alexandre.tor...@gmail.com;

[PATCH 1/3] arm: dts: mt2701: Sort DT nodes by register address

This patch rearrange MT2701 DT nodes to keep them in ascending order. Signed-off-by: James Liao --- arch/arm/boot/dts/mt2701.dtsi | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/arm/boot/dts/mt2701.dtsi

[PATCH 0/3] Add clock and power domain DT nodes for Mediatek MT2701

This patch series base on v4.10-rc1, include MT2701 power domain and clock DT nodes. An early patch [1] which was not applied in v4.10-rc1 also included in this patch series. [1] https://patchwork.kernel.org/patch/9457625/ James Liao (3): arm: dts: mt2701: Sort DT nodes by register address

[PATCH 1/3] arm: dts: mt2701: Sort DT nodes by register address

This patch rearrange MT2701 DT nodes to keep them in ascending order. Signed-off-by: James Liao --- arch/arm/boot/dts/mt2701.dtsi | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/arm/boot/dts/mt2701.dtsi

[PATCH 0/3] Add clock and power domain DT nodes for Mediatek MT2701

This patch series base on v4.10-rc1, include MT2701 power domain and clock DT nodes. An early patch [1] which was not applied in v4.10-rc1 also included in this patch series. [1] https://patchwork.kernel.org/patch/9457625/ James Liao (3): arm: dts: mt2701: Sort DT nodes by register address

[PATCH 3/3] arm: dts: mt2701: Add power domain controller device node

Add power domain controller node (scpsys) for MT2701. Signed-off-by: James Liao --- arch/arm/boot/dts/mt2701.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi index 150c48d..bdf8954

[PATCH 2/3] arm: dts: mt2701: Add subsystem clock controller device nodes

Add MT2701 subsystem clock controllers, inlcude mmsys, imgsys, vdecsys, hifsys, ethsys and bdpsys. Signed-off-by: James Liao --- arch/arm/boot/dts/mt2701.dtsi | 36 1 file changed, 36 insertions(+) diff --git

[PATCH 3/3] arm: dts: mt2701: Add power domain controller device node

Add power domain controller node (scpsys) for MT2701. Signed-off-by: James Liao --- arch/arm/boot/dts/mt2701.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi index 150c48d..bdf8954 100644 ---

[PATCH 2/3] arm: dts: mt2701: Add subsystem clock controller device nodes

Add MT2701 subsystem clock controllers, inlcude mmsys, imgsys, vdecsys, hifsys, ethsys and bdpsys. Signed-off-by: James Liao --- arch/arm/boot/dts/mt2701.dtsi | 36 1 file changed, 36 insertions(+) diff --git a/arch/arm/boot/dts/mt2701.dtsi

Re: [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy

On Wed, Dec 28, 2016 at 6:43 AM, Stephen Boyd wrote: > On 12/22/2016 08:52 PM, Vivek Gautam wrote: >> + +Optional properties: + - nvmem-cells: a list of phandles to nvmem cells that contain fused + tuning parameters for qusb2 phy, one for each

Re: [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy

On Wed, Dec 28, 2016 at 6:43 AM, Stephen Boyd wrote: > On 12/22/2016 08:52 PM, Vivek Gautam wrote: >> + +Optional properties: + - nvmem-cells: a list of phandles to nvmem cells that contain fused + tuning parameters for qusb2 phy, one for each entry +

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

Hi Pankaj, On 12/28/2016 12:10 PM, Pankaj Dubey wrote: > Hi Jaehoon, > > On 27 December 2016 at 15:48, Jaehoon Chung wrote: >> Dear Alim, >> >> On 12/27/2016 03:34 PM, Alim Akhtar wrote: >>> Hi Jaehoon, >>> >> [snip] Ah. Right..And i'm doing the refactoring to

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

Hi Pankaj, On 12/28/2016 12:10 PM, Pankaj Dubey wrote: > Hi Jaehoon, > > On 27 December 2016 at 15:48, Jaehoon Chung wrote: >> Dear Alim, >> >> On 12/27/2016 03:34 PM, Alim Akhtar wrote: >>> Hi Jaehoon, >>> >> [snip] Ah. Right..And i'm doing the refactoring to reuse the current

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hello, On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote: > Hannes Frederic Sowa wrote: > > On 24.12.2016 00:39, George Spelvin wrote: > > > We just finished discussing why 8 bytes isn't enough. If you only > > > feed back 8 bytes, an attacker who can do 2^64 computation can find it > > >

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hello, On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote: > Hannes Frederic Sowa wrote: > > On 24.12.2016 00:39, George Spelvin wrote: > > > We just finished discussing why 8 bytes isn't enough. If you only > > > feed back 8 bytes, an attacker who can do 2^64 computation can find it > > >

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

Minchan Kim writes: > On Wed, Dec 28, 2016 at 11:31:06AM +0800, Huang, Ying wrote: > > < snip > > >> >>> > Frankly speaking, although I'm huge user of bit_spin_lock(zram/zsmalloc >> >>> > have used it heavily), I don't like swap subsystem uses it. >> >>> > During zram

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

Minchan Kim writes: > On Wed, Dec 28, 2016 at 11:31:06AM +0800, Huang, Ying wrote: > > < snip > > >> >>> > Frankly speaking, although I'm huge user of bit_spin_lock(zram/zsmalloc >> >>> > have used it heavily), I don't like swap subsystem uses it. >> >>> > During zram development, it really

[PATCH] x86: Fix Intel microcode revision detection

early_init_intel() calls sync_core() before rdmsr(MSR_IA32_UCODE_REV), assuming sync_core() is effectively CPUID(eax=1). However the assumption no longer holds since commit c198b121b1a1 ("x86/asm: Rewrite sync_core() to use IRET-to-self"). As a result, kernel fails to detect the revision of

[PATCH] x86: Fix Intel microcode revision detection

early_init_intel() calls sync_core() before rdmsr(MSR_IA32_UCODE_REV), assuming sync_core() is effectively CPUID(eax=1). However the assumption no longer holds since commit c198b121b1a1 ("x86/asm: Rewrite sync_core() to use IRET-to-self"). As a result, kernel fails to detect the revision of

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

On 2016년 12월 27일 19:05, Michal Hocko wrote: > On Mon 26-12-16 13:18:11, Jaewon Kim wrote: >> There was no bitmap API which returns both next zero index and size of zeros >> from that index. >> >> This is helpful to look fragmentation. This is an test code to look size of >> zeros. >> Test

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

On 2016년 12월 27일 19:05, Michal Hocko wrote: > On Mon 26-12-16 13:18:11, Jaewon Kim wrote: >> There was no bitmap API which returns both next zero index and size of zeros >> from that index. >> >> This is helpful to look fragmentation. This is an test code to look size of >> zeros. >> Test

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

On Wed, Dec 28, 2016 at 11:31:06AM +0800, Huang, Ying wrote: < snip > > >>> > Frankly speaking, although I'm huge user of bit_spin_lock(zram/zsmalloc > >>> > have used it heavily), I don't like swap subsystem uses it. > >>> > During zram development, it really hurts debugging due to losing >

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

On Wed, Dec 28, 2016 at 11:31:06AM +0800, Huang, Ying wrote: < snip > > >>> > Frankly speaking, although I'm huge user of bit_spin_lock(zram/zsmalloc > >>> > have used it heavily), I don't like swap subsystem uses it. > >>> > During zram development, it really hurts debugging due to losing >

Re: Intel Wireless 7260 failed to work

On Tue, Dec 27, 2016 at 09:46:55PM +0200, Kalle Valo wrote: > Peter Xu writes: > > > Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well > > with my wireless card, which is: > > > > Intel Corporation Wireless 7260 (rev bb) > > > > Boot message shows that no

Re: Intel Wireless 7260 failed to work

On Tue, Dec 27, 2016 at 09:46:55PM +0200, Kalle Valo wrote: > Peter Xu writes: > > > Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well > > with my wireless card, which is: > > > > Intel Corporation Wireless 7260 (rev bb) > > > > Boot message shows that no suitable firmware

[PATCH] alpha: use generic current.h

Given that the arch does not add its own implementations, simply use the asm-generic/current.h (generic-y) header instead of duplicating code. Signed-off-by: Davidlohr Bueso --- arch/alpha/include/asm/Kbuild| 1 + arch/alpha/include/asm/current.h | 9 - 2 files

[PATCH] alpha: use generic current.h

Given that the arch does not add its own implementations, simply use the asm-generic/current.h (generic-y) header instead of duplicating code. Signed-off-by: Davidlohr Bueso --- arch/alpha/include/asm/Kbuild| 1 + arch/alpha/include/asm/current.h | 9 - 2 files changed, 1

[PATCH] score: remove asm/current.h

... it's already using the generic version anyways, so just drop the file as do the other archs that do not implement their own version of the current macro. Signed-off-by: Davidlohr Bueso --- arch/score/include/asm/Kbuild| 1 + arch/score/include/asm/current.h | 6 -- 2

[PATCH] score: remove asm/current.h

... it's already using the generic version anyways, so just drop the file as do the other archs that do not implement their own version of the current macro. Signed-off-by: Davidlohr Bueso --- arch/score/include/asm/Kbuild| 1 + arch/score/include/asm/current.h | 6 -- 2 files changed,

Re: [PATCH 2/2] mm: add PageWaiters indicating tasks are waiting for a page bit

On Tue, 27 Dec 2016 10:58:59 -0800 Linus Torvalds wrote: > On Tue, Dec 27, 2016 at 3:19 AM, Nicholas Piggin wrote: > > > > Attached is part of a patch I've been mulling over for a while. I > > expect you to hate it, and it does not solve this

Re: [PATCH 2/2] mm: add PageWaiters indicating tasks are waiting for a page bit

On Tue, 27 Dec 2016 10:58:59 -0800 Linus Torvalds wrote: > On Tue, Dec 27, 2016 at 3:19 AM, Nicholas Piggin wrote: > > > > Attached is part of a patch I've been mulling over for a while. I > > expect you to hate it, and it does not solve this problem for x86, > > but I like being able to

Re: Intel Wireless 7260 failed to work

On Tue, Dec 27, 2016 at 10:41:22AM -0600, Larry Finger wrote: > On 12/27/2016 03:17 AM, Peter Xu wrote: > >Hello, > > > >Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well > >with my wireless card, which is: > > > > Intel Corporation Wireless 7260 (rev bb) > > > >Boot message

Re: Intel Wireless 7260 failed to work

On Tue, Dec 27, 2016 at 10:41:22AM -0600, Larry Finger wrote: > On 12/27/2016 03:17 AM, Peter Xu wrote: > >Hello, > > > >Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well > >with my wireless card, which is: > > > > Intel Corporation Wireless 7260 (rev bb) > > > >Boot message

[PATCH] m32r: use generic current.h

Given that the arch does not add its own implementations, simply use the asm-generic/current.h (generic-y) header instead of duplicating code. Signed-off-by: Davidlohr Bueso --- arch/m32r/include/asm/Kbuild| 1 + arch/m32r/include/asm/current.h | 15 --- 2 files

[PATCH] m32r: use generic current.h

Given that the arch does not add its own implementations, simply use the asm-generic/current.h (generic-y) header instead of duplicating code. Signed-off-by: Davidlohr Bueso --- arch/m32r/include/asm/Kbuild| 1 + arch/m32r/include/asm/current.h | 15 --- 2 files changed, 1

[PATCH] parisc: use generic current.h

Given that the arch does not add its own implementations, simply use the asm-generic/current.h (generic-y) header instead of duplicating code. Signed-off-by: Davidlohr Bueso --- arch/parisc/include/asm/Kbuild| 1 + arch/parisc/include/asm/current.h | 15 --- 2

[PATCH] parisc: use generic current.h

Given that the arch does not add its own implementations, simply use the asm-generic/current.h (generic-y) header instead of duplicating code. Signed-off-by: Davidlohr Bueso --- arch/parisc/include/asm/Kbuild| 1 + arch/parisc/include/asm/current.h | 15 --- 2 files changed, 1

[PATCH] cris: use generic current.h

Given that the arch does not add its own implementations, simply use the asm-generic/current.h (generic-y) header instead of duplicating code. Signed-off-by: Davidlohr Bueso --- arch/cris/include/asm/Kbuild| 1 + arch/cris/include/asm/current.h | 15 --- 2 files

[PATCH] cris: use generic current.h

Given that the arch does not add its own implementations, simply use the asm-generic/current.h (generic-y) header instead of duplicating code. Signed-off-by: Davidlohr Bueso --- arch/cris/include/asm/Kbuild| 1 + arch/cris/include/asm/current.h | 15 --- 2 files changed, 1

Re: [PATCH v2 2/8] mm/swap: Add cluster lock

Hi, Jonathan, On Tue, Oct 25, 2016 at 10:05 AM, Huang, Ying wrote: > Hi, Jonathan, > > Thanks for review. > > Jonathan Corbet writes: > >> On Thu, 20 Oct 2016 16:31:41 -0700 >> Tim Chen wrote: >> >>> From: "Huang, Ying"

Re: [PATCH v2 2/8] mm/swap: Add cluster lock

Hi, Jonathan, On Tue, Oct 25, 2016 at 10:05 AM, Huang, Ying wrote: > Hi, Jonathan, > > Thanks for review. > > Jonathan Corbet writes: > >> On Thu, 20 Oct 2016 16:31:41 -0700 >> Tim Chen wrote: >> >>> From: "Huang, Ying" >>> >>> This patch is to reduce the lock contention of

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

"Huang, Ying" writes: > Minchan Kim writes: > >> Hi Huang, >> >> On Wed, Dec 28, 2016 at 09:54:27AM +0800, Huang, Ying wrote: >> >> < snip > >> >>> > The patchset has used several techniqueus to reduce lock contention, for >>> > example, >>> > batching

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

"Huang, Ying" writes: > Minchan Kim writes: > >> Hi Huang, >> >> On Wed, Dec 28, 2016 at 09:54:27AM +0800, Huang, Ying wrote: >> >> < snip > >> >>> > The patchset has used several techniqueus to reduce lock contention, for >>> > example, >>> > batching alloc/free, fine-grained lock and cluster

Re: possible dmar_init_reserved_ranges() error

Hi Bjorn, On Tue, Dec 27, 2016 at 05:44:17PM -0600, Bjorn Helgaas wrote: > > dmar_init_reserved_ranges() > { > ... > for_each_pci_dev(pdev) { > for (i = 0; i < PCI_NUM_RESOURCES; i++) { > r = >resource[i]; > reserve_iova(r) > > But I assume it's possible to

Re: possible dmar_init_reserved_ranges() error

Hi Bjorn, On Tue, Dec 27, 2016 at 05:44:17PM -0600, Bjorn Helgaas wrote: > > dmar_init_reserved_ranges() > { > ... > for_each_pci_dev(pdev) { > for (i = 0; i < PCI_NUM_RESOURCES; i++) { > r = >resource[i]; > reserve_iova(r) > > But I assume it's possible to

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

Minchan Kim writes: > Hi Huang, > > On Wed, Dec 28, 2016 at 09:54:27AM +0800, Huang, Ying wrote: > > < snip > > >> > The patchset has used several techniqueus to reduce lock contention, for >> > example, >> > batching alloc/free, fine-grained lock and cluster distribution to

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

Minchan Kim writes: > Hi Huang, > > On Wed, Dec 28, 2016 at 09:54:27AM +0800, Huang, Ying wrote: > > < snip > > >> > The patchset has used several techniqueus to reduce lock contention, for >> > example, >> > batching alloc/free, fine-grained lock and cluster distribution to avoid >> > cache

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

Hi Bartlomiej, On 27 December 2016 at 19:05, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Friday, December 23, 2016 04:26:27 PM Pankaj Dubey wrote: >> From: Niyas Ahmed S T >> >> Currently Exynos PCIe driver is only supported for Exynos5440

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

Hi Bartlomiej, On 27 December 2016 at 19:05, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Friday, December 23, 2016 04:26:27 PM Pankaj Dubey wrote: >> From: Niyas Ahmed S T >> >> Currently Exynos PCIe driver is only supported for Exynos5440 SoC. >> This patch does refactoring of Exynos PCIe

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

Hi Jaehoon, On 27 December 2016 at 15:48, Jaehoon Chung wrote: > Dear Alim, > > On 12/27/2016 03:34 PM, Alim Akhtar wrote: >> Hi Jaehoon, >> > [snip] >>> >>> Ah. Right..And i'm doing the refactoring to reuse the current pci-exynos.c. >> There is a nice refactoring patch

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

Hi Jaehoon, On 27 December 2016 at 15:48, Jaehoon Chung wrote: > Dear Alim, > > On 12/27/2016 03:34 PM, Alim Akhtar wrote: >> Hi Jaehoon, >> > [snip] >>> >>> Ah. Right..And i'm doing the refactoring to reuse the current pci-exynos.c. >> There is a nice refactoring patch posted by Pankaj recently

Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy

Hi Vivek, On 12/27/2016 02:53 PM, Vivek Gautam wrote: > Hi Jaehoon, > > > On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung > wrote: >> This patch supports to use Generic Phy framework for Exynos PCIe phy. >> When Exynos that supported the pcie want to use the PCIe, >>

Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy

Hi Vivek, On 12/27/2016 02:53 PM, Vivek Gautam wrote: > Hi Jaehoon, > > > On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung > wrote: >> This patch supports to use Generic Phy framework for Exynos PCIe phy. >> When Exynos that supported the pcie want to use the PCIe, >> it needs to control the

Re: vfio/pci: guest error recovery proposal

On 12/16/2016 07:02 AM, Michael S. Tsirkin wrote: > >> 1) We need to do the right thing for the guest, I don't think we >> should be presuming that different reset types are equivalent, >> leaving gaps where we expect the guest/host to do a reset and don't >> follow through on

Re: vfio/pci: guest error recovery proposal

On 12/16/2016 07:02 AM, Michael S. Tsirkin wrote: > >> 1) We need to do the right thing for the guest, I don't think we >> should be presuming that different reset types are equivalent, >> leaving gaps where we expect the guest/host to do a reset and don't >> follow through on

  1   2   3   4   5   6   7   8   >