Re: [PATCH V2 2/4] clk: Combine DT binding doc for max77686 and max77802

On 06/16/2016 03:23 PM, Laxman Dewangan wrote: > The clock IP used on the Maxim PMICs max77686 and max77802 are > same. The configuration of clock register is also same except > the number of clocks. > > Define the common DT binding file for the clocks of Maxim PMICs > MAX77686 and MAX77802. For

Re: [PATCH V2 2/4] clk: Combine DT binding doc for max77686 and max77802

On 06/16/2016 03:23 PM, Laxman Dewangan wrote: > The clock IP used on the Maxim PMICs max77686 and max77802 are > same. The configuration of clock register is also same except > the number of clocks. > > Define the common DT binding file for the clocks of Maxim PMICs > MAX77686 and MAX77802. For

Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

Ben Hutchings writes: > When kernel.perf_event_open is set to 3 (or greater), disallow all > access to performance events by users without CAP_SYS_ADMIN. > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that > makes this value the default. So this patch does two

Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

Ben Hutchings writes: > When kernel.perf_event_open is set to 3 (or greater), disallow all > access to performance events by users without CAP_SYS_ADMIN. > Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that > makes this value the default. So this patch does two things, can it then

Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression

On Thu, Jun 16, 2016 at 03:27:44PM -0700, Huang, Ying wrote: > Minchan Kim writes: > > > On Thu, Jun 16, 2016 at 07:52:26AM +0800, Huang, Ying wrote: > >> "Kirill A. Shutemov" writes: > >> > >> > On Tue, Jun 14, 2016 at 05:57:28PM +0900, Minchan Kim

Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression

On Thu, Jun 16, 2016 at 03:27:44PM -0700, Huang, Ying wrote: > Minchan Kim writes: > > > On Thu, Jun 16, 2016 at 07:52:26AM +0800, Huang, Ying wrote: > >> "Kirill A. Shutemov" writes: > >> > >> > On Tue, Jun 14, 2016 at 05:57:28PM +0900, Minchan Kim wrote: > >> >> On Wed, Jun 08, 2016 at

Re: net: stmmac: dwmac-rk: fixes for Wake-on-Lan on RK3288

On 6/16/2016 4:51 PM, Vincent Palatin wrote: Hi Giuseppe, On Thu, Jun 16, 2016 at 6:37 AM, Giuseppe CAVALLARO wrote: Hi Vincent On 6/15/2016 7:04 PM, Vincent Palatin wrote: On Sun, Jun 12, 2016 at 11:46 PM, Giuseppe CAVALLARO wrote: On

Re: [BUG] act_ife: sleeping functions called in atomic context

On Thu, Jun 16, 2016 at 7:14 PM, Cong Wang wrote: > > I think we can just remove that tcf_lock, I am testing a patch now. Please try the attached patch, I will do more tests tomorrow. Thanks! diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c index 658046d..859fb02

Re: net: stmmac: dwmac-rk: fixes for Wake-on-Lan on RK3288

On 6/16/2016 4:51 PM, Vincent Palatin wrote: Hi Giuseppe, On Thu, Jun 16, 2016 at 6:37 AM, Giuseppe CAVALLARO wrote: Hi Vincent On 6/15/2016 7:04 PM, Vincent Palatin wrote: On Sun, Jun 12, 2016 at 11:46 PM, Giuseppe CAVALLARO wrote: On 6/11/2016 3:00 AM, Vincent Palatin wrote: In

Re: [BUG] act_ife: sleeping functions called in atomic context

On Thu, Jun 16, 2016 at 7:14 PM, Cong Wang wrote: > > I think we can just remove that tcf_lock, I am testing a patch now. Please try the attached patch, I will do more tests tomorrow. Thanks! diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c index 658046d..859fb02 100644 ---

Re: [PATCH net-next v5 0/7] vmxnet3: upgrade to version 3

From: Shrikrishna Khare Date: Thu, 16 Jun 2016 10:51:52 -0700 > vmxnet3 emulation has recently added several new features which includes > support for new commands the driver can issue to emulation, change in > descriptor fields etc. This patch series extends the vmxnet3

Re: [PATCH net-next v5 0/7] vmxnet3: upgrade to version 3

From: Shrikrishna Khare Date: Thu, 16 Jun 2016 10:51:52 -0700 > vmxnet3 emulation has recently added several new features which includes > support for new commands the driver can issue to emulation, change in > descriptor fields etc. This patch series extends the vmxnet3 driver to > leverage

Re: [PATCH v3] i2c: designware: Use transfer timeout from ioctl I2C_TIMEOUT

On 06/17/2016 04:46 AM, Weifeng Voon wrote: This allows applications to set the transfer timeout in 10ms increments via ioctl I2C_TIMEOUT. Signed-off-by: Weifeng Voon --- changelog v2: * No code change, just change to a more suitable title changelog v3: * Move

Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock

Hello, On Thu, Jun 16, 2016 at 09:12:32PM -0300, Daniel Bristot de Oliveira wrote: > The use of the irq spin_(un)lock_irq() assumes that the code is always > called with IRQs enabled. But that is not always true in this case, as > we call cgroup_free() in the hard IRQ context, and unconditionally

Re: [PATCH v3] i2c: designware: Use transfer timeout from ioctl I2C_TIMEOUT

On 06/17/2016 04:46 AM, Weifeng Voon wrote: This allows applications to set the transfer timeout in 10ms increments via ioctl I2C_TIMEOUT. Signed-off-by: Weifeng Voon --- changelog v2: * No code change, just change to a more suitable title changelog v3: * Move changelog out of commit log

Re: [PATCH v2] cgroup: disable irqs while holding css_set_lock

Hello, On Thu, Jun 16, 2016 at 09:12:32PM -0300, Daniel Bristot de Oliveira wrote: > The use of the irq spin_(un)lock_irq() assumes that the code is always > called with IRQs enabled. But that is not always true in this case, as > we call cgroup_free() in the hard IRQ context, and unconditionally

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

On 17 June 2016 at 07:13, Kalle Valo wrote: > Rafał Miłecki writes: > >> On 16 June 2016 at 17:10, Kalle Valo wrote: >>> Rafał Miłecki writes: >>> Removing P2P interface is handled by sending a proper request

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

On 17 June 2016 at 07:13, Kalle Valo wrote: > Rafał Miłecki writes: > >> On 16 June 2016 at 17:10, Kalle Valo wrote: >>> Rafał Miłecki writes: >>> Removing P2P interface is handled by sending a proper request to the firmware. On success firmware triggers an event and driver's handler

Re: [PATCH] MADVISE_FREE, THP: Fix madvise_free_huge_pmd return value after splitting

Hi, On Thu, Jun 16, 2016 at 08:03:54PM -0700, Huang, Ying wrote: > From: Huang Ying > > madvise_free_huge_pmd should return 0 if the fallback PTE operations are > required. In madvise_free_huge_pmd, if part pages of THP are discarded, > the THP will be split and fallback

Re: [PATCH] MADVISE_FREE, THP: Fix madvise_free_huge_pmd return value after splitting

Hi, On Thu, Jun 16, 2016 at 08:03:54PM -0700, Huang, Ying wrote: > From: Huang Ying > > madvise_free_huge_pmd should return 0 if the fallback PTE operations are > required. In madvise_free_huge_pmd, if part pages of THP are discarded, > the THP will be split and fallback PTE operations should

[PATCH 2/2] idle_intel: Add Denverton

From: Jacob Pan Denverton is an Intel Atom based micro server which shares the same Goldmont architecture as Broxton. The available C-states on Denverton is a subset of Broxton with only C1, C1e, and C6. Signed-off-by: Jacob Pan

[PATCH 1/2] drivers/idle: make intel_idle.c driver more explicitly non-modular

From: Paul Gortmaker The Kconfig for this driver is currently declared with: config INTEL_IDLE bool "Cpuidle Driver for Intel Processors" ...meaning that it currently is not being built as a module by anyone. This was done in commit

[PATCH 0/2] intel_idle updates

Rafael, Since you've already pulled Dave's intel-family.h intel_idle changes into your tree, please also apply these intel_idle patches to that branch. [PATCH 1/2] drivers/idle: make intel_idle.c driver more explicitly [PATCH 2/2] idle_intel: Add Denverton And if you prefer to use git... The

[PATCH 2/2] idle_intel: Add Denverton

From: Jacob Pan Denverton is an Intel Atom based micro server which shares the same Goldmont architecture as Broxton. The available C-states on Denverton is a subset of Broxton with only C1, C1e, and C6. Signed-off-by: Jacob Pan Signed-off-by: Len Brown --- drivers/idle/intel_idle.c | 35

[PATCH 1/2] drivers/idle: make intel_idle.c driver more explicitly non-modular

From: Paul Gortmaker The Kconfig for this driver is currently declared with: config INTEL_IDLE bool "Cpuidle Driver for Intel Processors" ...meaning that it currently is not being built as a module by anyone. This was done in commit 6ce9cd8669fa1195fdc21643370e34523c7ac988

[PATCH 0/2] intel_idle updates

Rafael, Since you've already pulled Dave's intel-family.h intel_idle changes into your tree, please also apply these intel_idle patches to that branch. [PATCH 1/2] drivers/idle: make intel_idle.c driver more explicitly [PATCH 2/2] idle_intel: Add Denverton And if you prefer to use git... The

[PATCH 02/10] x86 tsc_msr: Identify Intel-specific code

From: Len Brown try_msr_calibrate_tsc() is currently Intel-specific, and should not execute on any other vendor's parts. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH 02/10] x86 tsc_msr: Identify Intel-specific code

From: Len Brown try_msr_calibrate_tsc() is currently Intel-specific, and should not execute on any other vendor's parts. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c index

[PATCH 05/10] x86 tsc_msr: Correct Silvermont reference clock values

From: Len Brown Atom processors use a 19.2 MHz crystal oscillator. Early processors generate 100 MHz via 19.2 MHz * 26 / 5 = 99.84 MHz. Later preocessor generate 100 MHz via 19.2 MHz * 125 / 24 = 100 MHz. Update the Silvermont-based tables accordingly, matching the

[PATCH 06/10] x86 tsc_msr: Add Airmont reference clock values

From: Len Brown per the Intel 64 and IA-32 Architecture Software Developer's Manual... Add the reference clock for Intel Atom Processors Based on the Airmont Microarchitecture. Reported-by: Stephane Gasparini Signed-off-by: Len Brown

[PATCH 01/10] Revert "x86/tsc: Add missing Cherrytrail frequency to the table"

From: Len Brown This reverts commit e2724e9d969294879936daf7833d4adda26c8efc. as it is incomplete, and is replaced by a more complete pach later in this series. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 3 --- 1 file changed, 3

[PATCH 05/10] x86 tsc_msr: Correct Silvermont reference clock values

From: Len Brown Atom processors use a 19.2 MHz crystal oscillator. Early processors generate 100 MHz via 19.2 MHz * 26 / 5 = 99.84 MHz. Later preocessor generate 100 MHz via 19.2 MHz * 125 / 24 = 100 MHz. Update the Silvermont-based tables accordingly, matching the Software Developers Manual.

[PATCH 06/10] x86 tsc_msr: Add Airmont reference clock values

From: Len Brown per the Intel 64 and IA-32 Architecture Software Developer's Manual... Add the reference clock for Intel Atom Processors Based on the Airmont Microarchitecture. Reported-by: Stephane Gasparini Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 5 - 1 file changed,

[PATCH 01/10] Revert "x86/tsc: Add missing Cherrytrail frequency to the table"

From: Len Brown This reverts commit e2724e9d969294879936daf7833d4adda26c8efc. as it is incomplete, and is replaced by a more complete pach later in this series. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH 08/10] x86 tsc_msr: Remove irqoff around MSR-based TSC enumeration

From: Len Brown Remove the irqoff/irqon around MSR-based TSC enumeration, as it is not necessary. Also rename: try_msr_calibrate_tsc() to cpu_khz_from_msr(), as that better describes what the routine does. Signed-off-by: Len Brown ---

[PATCH 07/10] x86 tsc_msr: Extend to include Intel Core Architecture

From: Len Brown tsc_msr is used to quickly and reliably enumerate the CPU/TSC frequencies at boot time For the Intel Atom Architecture. Extend tsc_msr to include recent Intel Core Architecture. As this code discovers BCLK, it also sets lapic_timer_frequency, which allows

[PATCH 08/10] x86 tsc_msr: Remove irqoff around MSR-based TSC enumeration

From: Len Brown Remove the irqoff/irqon around MSR-based TSC enumeration, as it is not necessary. Also rename: try_msr_calibrate_tsc() to cpu_khz_from_msr(), as that better describes what the routine does. Signed-off-by: Len Brown --- arch/x86/include/asm/tsc.h | 3 +-- arch/x86/kernel/tsc.c

[PATCH 07/10] x86 tsc_msr: Extend to include Intel Core Architecture

From: Len Brown tsc_msr is used to quickly and reliably enumerate the CPU/TSC frequencies at boot time For the Intel Atom Architecture. Extend tsc_msr to include recent Intel Core Architecture. As this code discovers BCLK, it also sets lapic_timer_frequency, which allows LAPIC timer

[PATCH 03/10] x86 tsc_msr: Remove debugging messages

From: Len Brown Debugging messages are not necessary after all of the possible hardware failures that never occur. Instead, this code can simply return 0. This code also doesn't need to print in the success case. tsc_init() already prints the TSC frequency, and apic=debug

[PATCH 09/10] x86 tsc: enumerate SKL cpu_khz and tsc_khz via CPUID

From: Len Brown Skylake CPU base-frequency and TSC frequency may differ by up to 2%. Enumerate CPU and TSC frequencies separately, allowing cpu_khz and tsc_khz to differ. The existing CPU frequency calibration mechanism is unchanged. However, CPUID extensions are

[PATCH 03/10] x86 tsc_msr: Remove debugging messages

From: Len Brown Debugging messages are not necessary after all of the possible hardware failures that never occur. Instead, this code can simply return 0. This code also doesn't need to print in the success case. tsc_init() already prints the TSC frequency, and apic=debug is available if

[PATCH 09/10] x86 tsc: enumerate SKL cpu_khz and tsc_khz via CPUID

From: Len Brown Skylake CPU base-frequency and TSC frequency may differ by up to 2%. Enumerate CPU and TSC frequencies separately, allowing cpu_khz and tsc_khz to differ. The existing CPU frequency calibration mechanism is unchanged. However, CPUID extensions are preferred, when available.

[PATCH 10/10] x86 tsc: enumerate BXT tsc_khz via CPUID

From: Len Brown Hard code the BXT crystal clock (aka ART - Always Running Timer) to 19.200 MHz, and use CPUID leaf 0x15 to determine the BXT TSC frequency. Use tsc_khz to sanity check BXT cpu_khz, which can be erroneous in some configurations. Signed-off-by: Bin Gao

[PATCH 0/10] x86/tsc: fast calibration updates

Originally I wrote this series to increase TSC calibration accuracy and speed, but it now it also includes changes that are mandatory for some systems to work correctly. In particular, the Airmont table entires are already being used in products, and some BXT steppings will fail without the check

[PATCH 0/10] x86/tsc: fast calibration updates

Originally I wrote this series to increase TSC calibration accuracy and speed, but it now it also includes changes that are mandatory for some systems to work correctly. In particular, the Airmont table entires are already being used in products, and some BXT steppings will fail without the check

[PATCH 10/10] x86 tsc: enumerate BXT tsc_khz via CPUID

From: Len Brown Hard code the BXT crystal clock (aka ART - Always Running Timer) to 19.200 MHz, and use CPUID leaf 0x15 to determine the BXT TSC frequency. Use tsc_khz to sanity check BXT cpu_khz, which can be erroneous in some configurations. Signed-off-by: Bin Gao [lenb: simplified]

[PATCH 04/10] x86 tsc_msr: Update comments, expand definitions

From: Len Brown Syntax only, no functional change. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 36 ++-- 1 file changed, 10 insertions(+), 26 deletions(-) diff --git a/arch/x86/kernel/tsc_msr.c

[PATCH] tools/perf: Fix the mask in regs_dump__printf

When decoding the perf_regs mask in regs_dump__printf(), we loop through the mask using find_first_bit and find_next_bit functions. And mask is of type "u64". But "u64" is send as a "unsigned long *" to lib functions along with sizeof(). While the exisitng code works fine in most of the case,

[PATCH 04/10] x86 tsc_msr: Update comments, expand definitions

From: Len Brown Syntax only, no functional change. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 36 ++-- 1 file changed, 10 insertions(+), 26 deletions(-) diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c index f7ba44b..4110f72

[PATCH] tools/perf: Fix the mask in regs_dump__printf

When decoding the perf_regs mask in regs_dump__printf(), we loop through the mask using find_first_bit and find_next_bit functions. And mask is of type "u64". But "u64" is send as a "unsigned long *" to lib functions along with sizeof(). While the exisitng code works fine in most of the case,

Re: [RFC PATCH 2/2] KVM: x86: use __kvm_guest_exit

> > static bool vmx_has_high_real_mode_segbase(void) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 7e3041ef050f..cc741b68139c 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -6706,21 +6706,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > >

Re: [RFC PATCH 2/2] KVM: x86: use __kvm_guest_exit

> > static bool vmx_has_high_real_mode_segbase(void) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 7e3041ef050f..cc741b68139c 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -6706,21 +6706,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > >

[PATCH v2] mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()

This patch removes following UBSAN warnings in dw_mci_setup_bus(). UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1102:14 shift exponent 250 is too large for 32-bit type 'unsigned int' Call trace: [] dump_backtrace+0x0/0x380 [] show_stack+0x14/0x20 [] dump_stack+0xe0/0x120

[PATCH v2] mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()

This patch removes following UBSAN warnings in dw_mci_setup_bus(). UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1102:14 shift exponent 250 is too large for 32-bit type 'unsigned int' Call trace: [] dump_backtrace+0x0/0x380 [] show_stack+0x14/0x20 [] dump_stack+0xe0/0x120

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

Rafał Miłecki writes: > On 16 June 2016 at 17:10, Kalle Valo wrote: >> Rafał Miłecki writes: >> >>> Removing P2P interface is handled by sending a proper request to the >>> firmware. On success firmware triggers an event and driver's

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

Rafał Miłecki writes: > On 16 June 2016 at 17:10, Kalle Valo wrote: >> Rafał Miłecki writes: >> >>> Removing P2P interface is handled by sending a proper request to the >>> firmware. On success firmware triggers an event and driver's handler >>> removes a matching interface. >>> >>> However on

Re: [PATCH 4/8] hamradio: baycom: fix old-style declaration

From: Arnd Bergmann Date: Thu, 16 Jun 2016 15:52:11 +0200 > Modern C standards expect the '__inline__' keyword to come before the return > type in a declaration, and we get a warning for this with "make W=1": > > drivers/net/hamradio/baycom_par.c:159:1: error: '__inline__' is not

Re: [PATCH 7/8] net: xfrm: fix old-style declaration

From: Arnd Bergmann Date: Thu, 16 Jun 2016 15:59:25 +0200 > Modern C standards expect the '__inline__' keyword to come before the return > type in a declaration, and we get a couple of warnings for this with "make > W=1" > in the xfrm{4,6}_policy.c files: > >

Re: [PATCH 4/8] hamradio: baycom: fix old-style declaration

From: Arnd Bergmann Date: Thu, 16 Jun 2016 15:52:11 +0200 > Modern C standards expect the '__inline__' keyword to come before the return > type in a declaration, and we get a warning for this with "make W=1": > > drivers/net/hamradio/baycom_par.c:159:1: error: '__inline__' is not at >

Re: [PATCH 7/8] net: xfrm: fix old-style declaration

From: Arnd Bergmann Date: Thu, 16 Jun 2016 15:59:25 +0200 > Modern C standards expect the '__inline__' keyword to come before the return > type in a declaration, and we get a couple of warnings for this with "make > W=1" > in the xfrm{4,6}_policy.c files: > > net/ipv6/xfrm6_policy.c:369:1:

Re: [PATCH 5/8] isdn: eicon: fix old-style declarations

From: Arnd Bergmann Date: Thu, 16 Jun 2016 15:52:12 +0200 > Modern C standards expect the '__inline__' keyword to come before the return > type in a declaration, and we get many warnings for this with "make W=1" > because the eicon driver has this in a header file: > >

Re: [PATCH 6/8] net: gianfar: fix old-style declaration

From: Arnd Bergmann Date: Thu, 16 Jun 2016 15:52:13 +0200 > Modern C standards expect the '__inline__' keyword to come before the return > type in a declaration, and we get a warning for this with "make W=1": > > drivers/net/ethernet/freescale/gianfar.c:2278:1: error: 'inline' is

Re: [PATCH 5/8] isdn: eicon: fix old-style declarations

From: Arnd Bergmann Date: Thu, 16 Jun 2016 15:52:12 +0200 > Modern C standards expect the '__inline__' keyword to come before the return > type in a declaration, and we get many warnings for this with "make W=1" > because the eicon driver has this in a header file: > > eicon/divasmain.c:448:1:

Re: [PATCH 6/8] net: gianfar: fix old-style declaration

From: Arnd Bergmann Date: Thu, 16 Jun 2016 15:52:13 +0200 > Modern C standards expect the '__inline__' keyword to come before the return > type in a declaration, and we get a warning for this with "make W=1": > > drivers/net/ethernet/freescale/gianfar.c:2278:1: error: 'inline' is not at >

[PATCH v3 0/7] max8903: Add device tree support and misc fixes

From: Chris Lapa This patch set adds device tree support for the MAX8903 battery charger. It also cleans up logic with dc_valid, dok and dcm pins as well as fixing up validity checking of gpios. I verified these patches work on a board I have here, which uses the DC power

[PATCH v3 1/7] max8903: adds documentation for device tree bindings.

From: Chris Lapa Signed-off-by: Chris Lapa --- .../devicetree/bindings/power/max8903-charger.txt | 25 ++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/max8903-charger.txt diff --git

[PATCH v3 0/7] max8903: Add device tree support and misc fixes

From: Chris Lapa This patch set adds device tree support for the MAX8903 battery charger. It also cleans up logic with dc_valid, dok and dcm pins as well as fixing up validity checking of gpios. I verified these patches work on a board I have here, which uses the DC power side (not the USB

[PATCH v3 1/7] max8903: adds documentation for device tree bindings.

From: Chris Lapa Signed-off-by: Chris Lapa --- .../devicetree/bindings/power/max8903-charger.txt | 25 ++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/max8903-charger.txt diff --git

[PATCH v3 3/7] max8903: cleans up confusing relationship between dc_valid, dok and dcm.

From: Chris Lapa The max8903_charger.h file indicated that dcm and dok were not optional when dc_valid is set. It makes sense to have dok as a compulsory pin when dc_valid is given. However dcm can be optionally wired to a fixed level especially when the circuit is configured

[PATCH v3 3/7] max8903: cleans up confusing relationship between dc_valid, dok and dcm.

From: Chris Lapa The max8903_charger.h file indicated that dcm and dok were not optional when dc_valid is set. It makes sense to have dok as a compulsory pin when dc_valid is given. However dcm can be optionally wired to a fixed level especially when the circuit is configured for dc power

[PATCH v2 1/2] Crypto: Add SHA-3 hash algorithm

From: Jeff Garzik This patch adds the implementation of SHA3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. Signed-off-by: Jeff

[PATCH v2 2/2] Crypto: Add SHA-3 Test's in tcrypt

Added support for SHA-3 algorithm test's in tcrypt module and related test vectors. Signed-off-by: Raveendra Padasalagi --- crypto/tcrypt.c | 53 ++- crypto/testmgr.c | 40 ++ crypto/testmgr.h | 125

[PATCH v3 7/7] max8903: adds support for initiation via device tree.

From: Chris Lapa Adds support for device tree to setup a max8903 battery charger. DC and USB validity are determined by looking the presence of the dok and uok gpios. Signed-off-by: Chris Lapa --- drivers/power/max8903_charger.c | 217

[PATCH v3 5/7] max8903: removes non zero validity checks on gpios.

From: Chris Lapa Prior to this commit a zero gpio was treated as invalid. Whereas gpio_is_valid() will treat a zero gpio as valid. This commit removes the confusion and explicity uses gpio_is_valid() throughout. Which in turn results in several of the error messages becoming

[PATCH v3 2/7] max8903: store pointer to pdata instead of copying it.

From: Chris Lapa Stores pointer to pdata because it easily allows pdata to reference either platform data or in the future device tree data. Signed-off-by: Chris Lapa --- drivers/power/max8903_charger.c | 20 +--- 1 file changed, 13

[PATCH v3 4/7] max8903: adds requesting of gpios.

From: Chris Lapa This change ensures all gpios are available for the driver to use. Signed-off-by: Chris Lapa --- drivers/power/max8903_charger.c | 79 - 1 file changed, 70 insertions(+), 9 deletions(-) diff --git

[PATCH v2 1/2] Crypto: Add SHA-3 hash algorithm

From: Jeff Garzik This patch adds the implementation of SHA3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. Signed-off-by: Jeff Garzik

[PATCH v2 2/2] Crypto: Add SHA-3 Test's in tcrypt

Added support for SHA-3 algorithm test's in tcrypt module and related test vectors. Signed-off-by: Raveendra Padasalagi --- crypto/tcrypt.c | 53 ++- crypto/testmgr.c | 40 ++ crypto/testmgr.h | 125 +++

[PATCH v3 7/7] max8903: adds support for initiation via device tree.

From: Chris Lapa Adds support for device tree to setup a max8903 battery charger. DC and USB validity are determined by looking the presence of the dok and uok gpios. Signed-off-by: Chris Lapa --- drivers/power/max8903_charger.c | 217 +++- 1 file changed,

[PATCH v3 5/7] max8903: removes non zero validity checks on gpios.

From: Chris Lapa Prior to this commit a zero gpio was treated as invalid. Whereas gpio_is_valid() will treat a zero gpio as valid. This commit removes the confusion and explicity uses gpio_is_valid() throughout. Which in turn results in several of the error messages becoming redundant and thus

[PATCH v3 2/7] max8903: store pointer to pdata instead of copying it.

From: Chris Lapa Stores pointer to pdata because it easily allows pdata to reference either platform data or in the future device tree data. Signed-off-by: Chris Lapa --- drivers/power/max8903_charger.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git

[PATCH v3 4/7] max8903: adds requesting of gpios.

From: Chris Lapa This change ensures all gpios are available for the driver to use. Signed-off-by: Chris Lapa --- drivers/power/max8903_charger.c | 79 - 1 file changed, 70 insertions(+), 9 deletions(-) diff --git a/drivers/power/max8903_charger.c

[PATCH v2 0/2] Add SHA-3 algorithm and test vectors.

This patchset adds the implementation of SHA-3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. This patchset also includes changes in tcrypt module

[PATCH v3 6/7] max8903: remove unnecessary 'out of memory' error message.

From: Chris Lapa Remove the 'out of memory' error message as it is printed by the core. Signed-off-by: Chris Lapa --- drivers/power/max8903_charger.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/power/max8903_charger.c

Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

On 06/16/2016 07:09 PM, Frank Wang wrote: The newer SoCs (rk3366, rk3399) take a different usb-phy IP block than rk3288 and before, and most of phy-related registers are also different from the past, so a new phy driver is required necessarily. Signed-off-by: Frank Wang

[PATCH v2 0/2] Add SHA-3 algorithm and test vectors.

This patchset adds the implementation of SHA-3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. This patchset also includes changes in tcrypt module

[PATCH v3 6/7] max8903: remove unnecessary 'out of memory' error message.

From: Chris Lapa Remove the 'out of memory' error message as it is printed by the core. Signed-off-by: Chris Lapa --- drivers/power/max8903_charger.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c index

Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

On 06/16/2016 07:09 PM, Frank Wang wrote: The newer SoCs (rk3366, rk3399) take a different usb-phy IP block than rk3288 and before, and most of phy-related registers are also different from the past, so a new phy driver is required necessarily. Signed-off-by: Frank Wang Suggested-by: Guenter

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

On 16 June 2016 at 17:10, Kalle Valo wrote: > Rafał Miłecki writes: > >> Removing P2P interface is handled by sending a proper request to the >> firmware. On success firmware triggers an event and driver's handler >> removes a matching interface. >> >>

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

On 16 June 2016 at 17:10, Kalle Valo wrote: > Rafał Miłecki writes: > >> Removing P2P interface is handled by sending a proper request to the >> firmware. On success firmware triggers an event and driver's handler >> removes a matching interface. >> >> However on event timeout we remove

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Fri, Jun 17, 2016 at 12:09:19AM -0400, Oleg Drokin wrote: > So they both do d_drop(), the dentry is now unhashed, and they both > dive into nfs_lookup(). > There eventually they both call > > res = d_splice_alias(inode, dentry); > >And so the first lucky one continues

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Fri, Jun 17, 2016 at 12:09:19AM -0400, Oleg Drokin wrote: > So they both do d_drop(), the dentry is now unhashed, and they both > dive into nfs_lookup(). > There eventually they both call > > res = d_splice_alias(inode, dentry); > >And so the first lucky one continues

linux-next: Tree for Jun 17

Hi all, Changes since 20160616: Non-merge commits (relative to Linus' tree): 3866 3847 files changed, 179431 insertions(+), 67790 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm

linux-next: Tree for Jun 17

Hi all, Changes since 20160616: Non-merge commits (relative to Linus' tree): 3866 3847 files changed, 179431 insertions(+), 67790 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm

Re: [PATCH] zram: use writer semaphores in device attributes store

Hello, On (06/17/16 11:31), Geliang Tang wrote: [..] > Since the device attributes store provides write access. This patch uses > down_write()/up_write() instead of down_read()/up_read() in > mem_used_max_store() and compact_store(). we use ->init_lock not to make attrs exclusive, but to prevent

Re: [PATCH] zram: use writer semaphores in device attributes store

Hello, On (06/17/16 11:31), Geliang Tang wrote: [..] > Since the device attributes store provides write access. This patch uses > down_write()/up_write() instead of down_read()/up_read() in > mem_used_max_store() and compact_store(). we use ->init_lock not to make attrs exclusive, but to prevent

More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

Hello! So I think I finally kind of understand this other d_splice_alias problem I've been having. Imagine that we have a negative dentry in the cache. Now we have two threads that are trying to open this file in parallel, the fs is NFS, so atomic_open is defined, it's not a

More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

Hello! So I think I finally kind of understand this other d_splice_alias problem I've been having. Imagine that we have a negative dentry in the cache. Now we have two threads that are trying to open this file in parallel, the fs is NFS, so atomic_open is defined, it's not a

Re: [PATCH] mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()

Hello Jaehoon, On 2016년 06월 17일 10:30, Jaehoon Chung wrote: > Hi Seung-Woo, > > On 06/10/2016 10:29 AM, Seung-Woo Kim wrote: >> Hi Jaehoon, >> >> On 2016년 06월 09일 21:38, Jaehoon Chung wrote: >>> Hi Seung-Woo, >>> >>> On 06/08/2016 01:07 PM, Seung-Woo Kim wrote: This patch removes following

Re: [PATCH] mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()

Hello Jaehoon, On 2016년 06월 17일 10:30, Jaehoon Chung wrote: > Hi Seung-Woo, > > On 06/10/2016 10:29 AM, Seung-Woo Kim wrote: >> Hi Jaehoon, >> >> On 2016년 06월 09일 21:38, Jaehoon Chung wrote: >>> Hi Seung-Woo, >>> >>> On 06/08/2016 01:07 PM, Seung-Woo Kim wrote: This patch removes following

  1   2   3   4   5   6   7   8   9   10   >