[PATCH v4 2/2] of: Add unit tests for applying overlays

From: Frank Rowand Existing overlay unit tests examine individual pieces of the overlay code. The new tests target the entire process of applying an overlay. Signed-off-by: Frank Rowand --- There are checkpatch warnings. I have reviewed them and feel they can be ignored. drivers/of/fdt.c

[PATCH v4 0/2] of: Add unit tests for applying overlays

From: Frank Rowand Existing overlay unit tests examine individual pieces of the overlay code. The new tests target the entire process of applying an overlay. Changes from v3: - make subject line of patch 1 more generic Changes from v2: - of_private.h: move __unflatten_device_tree() outside

Re: [tip:x86/boot] x86/boot/e820: Basic cleanup of e820.c

On Tue, Apr 11, 2017 at 12:37 AM, tip-bot for Ingo Molnar wrote: > Commit-ID: 640e1b38b00550990cecd809021cd37716e45922 > Gitweb: http://git.kernel.org/tip/640e1b38b00550990cecd809021cd37716e45922 > Author: Ingo Molnar > AuthorDate: Sat, 28 Jan 2017

Re: [tip:x86/boot] x86/boot/e820: Basic cleanup of e820.c

On Tue, Apr 11, 2017 at 12:37 AM, tip-bot for Ingo Molnar wrote: > Commit-ID: 640e1b38b00550990cecd809021cd37716e45922 > Gitweb: http://git.kernel.org/tip/640e1b38b00550990cecd809021cd37716e45922 > Author: Ingo Molnar > AuthorDate: Sat, 28 Jan 2017 11:13:08 +0100 > Committer: Ingo

Re: [PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

On 04/25/2017 04:53 PM, Eric Anholt wrote: > Cygnus has a single AMAC controller connected to the B53 switch with 2 > PHYs. On the BCM911360_EP platform, those two PHYs are connected to > the external ethernet jacks. > > Signed-off-by: Eric Anholt > Reviewed-by: Florian

Re: [PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

On 04/25/2017 04:53 PM, Eric Anholt wrote: > Cygnus has a single AMAC controller connected to the B53 switch with 2 > PHYs. On the BCM911360_EP platform, those two PHYs are connected to > the external ethernet jacks. > > Signed-off-by: Eric Anholt > Reviewed-by: Florian Fainelli > --- > > v2:

[PATCH] driver core: platform: fix race condition with driver_override

The driver_override implementation is susceptible to race condition when different threads are reading vs storing a different driver override. Add locking to avoid race condition. Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'") Cc: sta...@vger.kernel.org

[PATCH] driver core: platform: fix race condition with driver_override

The driver_override implementation is susceptible to race condition when different threads are reading vs storing a different driver override. Add locking to avoid race condition. Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'") Cc: sta...@vger.kernel.org

[PATCH v2 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

Cygnus is a small family of SoCs, of which we currently have devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the same as 58xx, just requiring a tiny bit of setup that was previously missing. Signed-off-by: Eric Anholt Reviewed-by: Florian Fainelli

[PATCH v2 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

Cygnus is a small family of SoCs, of which we currently have devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the same as 58xx, just requiring a tiny bit of setup that was previously missing. Signed-off-by: Eric Anholt Reviewed-by: Florian Fainelli --- v2: Reorder the entry in

[PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

Cygnus has a single AMAC controller connected to the B53 switch with 2 PHYs. On the BCM911360_EP platform, those two PHYs are connected to the external ethernet jacks. Signed-off-by: Eric Anholt Reviewed-by: Florian Fainelli --- v2: Call the node

[PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

Cygnus has a single AMAC controller connected to the B53 switch with 2 PHYs. On the BCM911360_EP platform, those two PHYs are connected to the external ethernet jacks. Signed-off-by: Eric Anholt Reviewed-by: Florian Fainelli --- v2: Call the node "switch", just call the ports "port"

Re: [RESEND][PATCH V2 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver

On 04/26/2017 12:31 AM, Mark Brown wrote: > On Tue, Apr 25, 2017 at 08:32:10PM +0200, Marek Vasut wrote: >> Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC. >> This block supports three voltage monitors, VD18, VD25, VD33 for the >> 1V8, 2V5, 3V3 voltage rails and a single

Re: [RESEND][PATCH V2 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver

On 04/26/2017 12:31 AM, Mark Brown wrote: > On Tue, Apr 25, 2017 at 08:32:10PM +0200, Marek Vasut wrote: >> Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC. >> This block supports three voltage monitors, VD18, VD25, VD33 for the >> 1V8, 2V5, 3V3 voltage rails and a single

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

On Tue, Apr 25, 2017 at 04:27:51PM +0200, Laurent Dufour wrote: > When page are poisoned, they should be uncharged from the root memory > cgroup. > > This is required to avoid a BUG raised when the page is onlined back: > BUG: Bad page state in process mem-on-off-test pfn:7ae3b >

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

On Tue, Apr 25, 2017 at 04:27:51PM +0200, Laurent Dufour wrote: > When page are poisoned, they should be uncharged from the root memory > cgroup. > > This is required to avoid a BUG raised when the page is onlined back: > BUG: Bad page state in process mem-on-off-test pfn:7ae3b >

Re: [PATCH] pmem: fix a NULL pointer BUG in nd_pmem_notify

On Tue, 2017-04-25 at 16:07 -0700, Dan Williams wrote: > On Tue, Apr 25, 2017 at 4:04 PM, Toshi Kani > wrote: > > The following BUG was observed when nd_pmem_notify() was called > > for a BTT device.  The use of a pmem_device pointer is not valid > > with BTT. > > > >  BUG:

Re: [PATCH] pmem: fix a NULL pointer BUG in nd_pmem_notify

On Tue, 2017-04-25 at 16:07 -0700, Dan Williams wrote: > On Tue, Apr 25, 2017 at 4:04 PM, Toshi Kani > wrote: > > The following BUG was observed when nd_pmem_notify() was called > > for a BTT device.  The use of a pmem_device pointer is not valid > > with BTT. > > > >  BUG: unable to handle

Re: [PATCH] trace-cmd: Fix a warning about incompatible pointer type of load_plugin()

On Mon, 24 Apr 2017 22:43:31 +0900 Taeung Song wrote: > Currently the return type of load_plugin() in plugin_python.c is void type, > but it is different from the argument type of trace_util_load_plugins(). > So fix it for the below warning. > >

Re: [PATCH] trace-cmd: Fix a warning about incompatible pointer type of load_plugin()

On Mon, 24 Apr 2017 22:43:31 +0900 Taeung Song wrote: > Currently the return type of load_plugin() in plugin_python.c is void type, > but it is different from the argument type of trace_util_load_plugins(). > So fix it for the below warning. > >

Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver

On Tue 25 Apr 10:13 PDT 2017, Rob Herring wrote: > On Mon, Apr 24, 2017 at 6:05 PM, Bjorn Andersson > wrote: > > On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote: [..] > >> Splitting things between common and private seems like a good direction. > >> > > > > But the

Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver

On Tue 25 Apr 10:13 PDT 2017, Rob Herring wrote: > On Mon, Apr 24, 2017 at 6:05 PM, Bjorn Andersson > wrote: > > On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote: [..] > >> Splitting things between common and private seems like a good direction. > >> > > > > But the pattern of amending the common

Re: [PATCH] drivers: input: joystick: Add PSX (Play Station 1/2) pad with SPI driver.

please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/AZO/drivers-input-joystick-Add-PSX-Play-Station-1-2-pad-with-SPI-driver/20170425-182329 > base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next > config:

Re: [PATCH] drivers: input: joystick: Add PSX (Play Station 1/2) pad with SPI driver.

> help improve the system] > > url: > https://github.com/0day-ci/linux/commits/AZO/drivers-input-joystick-Add-PSX-Play-Station-1-2-pad-with-SPI-driver/20170425-182329 > base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next > config: i386-allmodconfig (a

Re: [PATCH] pmem: fix a NULL pointer BUG in nd_pmem_notify

On Tue, Apr 25, 2017 at 4:04 PM, Toshi Kani wrote: > The following BUG was observed when nd_pmem_notify() was called > for a BTT device. The use of a pmem_device pointer is not valid > with BTT. > > BUG: unable to handle kernel NULL pointer dereference at 0030 >

Re: [PATCH 4/5] trace-cmd: fix argument parsing minor BUG

On Sun, 23 Apr 2017 12:22:57 +0200 Federico Vaga wrote: > For some reason the list command does not use anymore `getopt()` > to parse the arguments, instead it uses a custum implementation. > > During this change [5da0eff trace-cmd: Add regex for listing of events] >

Re: [PATCH] pmem: fix a NULL pointer BUG in nd_pmem_notify

On Tue, Apr 25, 2017 at 4:04 PM, Toshi Kani wrote: > The following BUG was observed when nd_pmem_notify() was called > for a BTT device. The use of a pmem_device pointer is not valid > with BTT. > > BUG: unable to handle kernel NULL pointer dereference at 0030 > IP:

Re: [PATCH 4/5] trace-cmd: fix argument parsing minor BUG

On Sun, 23 Apr 2017 12:22:57 +0200 Federico Vaga wrote: > For some reason the list command does not use anymore `getopt()` > to parse the arguments, instead it uses a custum implementation. > > During this change [5da0eff trace-cmd: Add regex for listing of events] > the variable `optind` has

[PATCH] pmem: fix a NULL pointer BUG in nd_pmem_notify

The following BUG was observed when nd_pmem_notify() was called for a BTT device. The use of a pmem_device pointer is not valid with BTT. BUG: unable to handle kernel NULL pointer dereference at 0030 IP: nd_pmem_notify+0x30/0xf0 [nd_pmem] Call Trace: nd_device_notify+0x40/0x50

[PATCH] pmem: fix a NULL pointer BUG in nd_pmem_notify

The following BUG was observed when nd_pmem_notify() was called for a BTT device. The use of a pmem_device pointer is not valid with BTT. BUG: unable to handle kernel NULL pointer dereference at 0030 IP: nd_pmem_notify+0x30/0xf0 [nd_pmem] Call Trace: nd_device_notify+0x40/0x50

Re: [PATCH 2/2] dax: fix data corruption due to stale mmap reads

On Tue, Apr 25, 2017 at 01:10:43PM +0200, Jan Kara wrote: <> > Hum, but now thinking more about it I have hard time figuring out why write > vs fault cannot actually still race: > > CPU1 - write(2) CPU2 - read fault > >

Re: [PATCH 2/2] dax: fix data corruption due to stale mmap reads

On Tue, Apr 25, 2017 at 01:10:43PM +0200, Jan Kara wrote: <> > Hum, but now thinking more about it I have hard time figuring out why write > vs fault cannot actually still race: > > CPU1 - write(2) CPU2 - read fault > >

Re: [PATCH] libnvdimm: fix phys_addr for nvdimm_clear_poison

On Tue, Apr 25, 2017 at 3:22 PM, Vishal Verma wrote: > On 04/25, Kani, Toshimitsu wrote: >> On Tue, 2017-04-25 at 15:44 -0600, Vishal Verma wrote: >> > On 04/25, Toshi Kani wrote: > [...] >> > >> > Should we be using nsio->res.start here or nsio->addr ? >> >> nsio->addr

Re: [PATCH] libnvdimm: fix phys_addr for nvdimm_clear_poison

On Tue, Apr 25, 2017 at 3:22 PM, Vishal Verma wrote: > On 04/25, Kani, Toshimitsu wrote: >> On Tue, 2017-04-25 at 15:44 -0600, Vishal Verma wrote: >> > On 04/25, Toshi Kani wrote: > [...] >> > >> > Should we be using nsio->res.start here or nsio->addr ? >> >> nsio->addr is a virtual address. We

[PATCH v2 1/2] x86, asm: Add suffix macro for GEN_*_RMWcc()

The coming x86 refcount protection needs to be able to add trailing instructions to the GEN_*_RMWcc() operations. This extracts the difference between the goto/non-goto cases so the helper macros can be defined outside the #ifdef cases. Additionally adds argument naming to the resulting asm for

[PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection

This protection is a modified version of the x86 PAX_REFCOUNT implementation from PaX/grsecurity. This speeds up the refcount_t API by duplicating the existing atomic_t implementation with a single instruction added to detect if the refcount has wrapped past INT_MAX (or below 0) resulting in a

[PATCH v2 1/2] x86, asm: Add suffix macro for GEN_*_RMWcc()

The coming x86 refcount protection needs to be able to add trailing instructions to the GEN_*_RMWcc() operations. This extracts the difference between the goto/non-goto cases so the helper macros can be defined outside the #ifdef cases. Additionally adds argument naming to the resulting asm for

[PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection

This protection is a modified version of the x86 PAX_REFCOUNT implementation from PaX/grsecurity. This speeds up the refcount_t API by duplicating the existing atomic_t implementation with a single instruction added to detect if the refcount has wrapped past INT_MAX (or below 0) resulting in a

[PATCH v2 0/2] x86, refcount: Implement fast refcount overflow

This protection is a modified version of the x86 PAX_REFCOUNT implementation from PaX/grsecurity. This speeds up the refcount_t API by duplicating the existing atomic_t implementation with a single instruction added to detect if the refcount has wrapped past INT_MAX (or below 0) resulting in a

[PATCH v2 0/2] x86, refcount: Implement fast refcount overflow

This protection is a modified version of the x86 PAX_REFCOUNT implementation from PaX/grsecurity. This speeds up the refcount_t API by duplicating the existing atomic_t implementation with a single instruction added to detect if the refcount has wrapped past INT_MAX (or below 0) resulting in a

Re: [PATCH] drm/nouveau: Add support for clockgating on Fermi+

Hi Lyude, thanks for the great work. Just a view comments inline. 2017-04-25 20:38 GMT+02:00 Lyude : > This adds support for enabling automatic clockgating on nvidia GPUs for > Fermi and later generations. This saves a little bit of power, bringing > my fermi GPU's power

Re: [PATCH] drm/nouveau: Add support for clockgating on Fermi+

Hi Lyude, thanks for the great work. Just a view comments inline. 2017-04-25 20:38 GMT+02:00 Lyude : > This adds support for enabling automatic clockgating on nvidia GPUs for > Fermi and later generations. This saves a little bit of power, bringing > my fermi GPU's power consumption from ~28.3W

[PATCH v2] kbuild: clang: add -no-integrated-as to KBUILD_[AC]FLAGS

From: Michael Davidson The Linux Kernel relies on GCC's acceptance of inline assembly as an opaque object which will not have any validation performed on the content. The current behaviour in LLVM is to perform validation of the contents by means of parsing the input if the MC

[PATCH v2] kbuild: clang: add -no-integrated-as to KBUILD_[AC]FLAGS

From: Michael Davidson The Linux Kernel relies on GCC's acceptance of inline assembly as an opaque object which will not have any validation performed on the content. The current behaviour in LLVM is to perform validation of the contents by means of parsing the input if the MC layer can handle

Re: TREE_SRCU slows hotplug by factor ~16

On Mon, Apr 24, 2017 at 09:24:42AM -0700, Paul E. McKenney wrote: > On Mon, Apr 24, 2017 at 09:35:03AM +0200, Mike Galbraith wrote: > > On Sun, 2017-04-23 at 23:22 -0700, Paul E. McKenney wrote: > > > > > Could you please collect an ftrace (or whatever) showing the timestamp > > > sequence of

[PATCH 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli

Re: TREE_SRCU slows hotplug by factor ~16

On Mon, Apr 24, 2017 at 09:24:42AM -0700, Paul E. McKenney wrote: > On Mon, Apr 24, 2017 at 09:35:03AM +0200, Mike Galbraith wrote: > > On Sun, 2017-04-23 at 23:22 -0700, Paul E. McKenney wrote: > > > > > Could you please collect an ftrace (or whatever) showing the timestamp > > > sequence of

[PATCH 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli

Re: [PATCH 0/3] ARM/ARM64: silence large module first time allocation

On 04/25/2017 03:33 PM, Florian Fainelli wrote: > With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation > done from module space will fail, produce a general OOM allocation and also a > vmap warning. The second allocation from vmalloc space may or may not be > successful,

[PATCH 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli

Re: [PATCH 0/3] ARM/ARM64: silence large module first time allocation

On 04/25/2017 03:33 PM, Florian Fainelli wrote: > With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation > done from module space will fail, produce a general OOM allocation and also a > vmap warning. The second allocation from vmalloc space may or may not be > successful,

[PATCH 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli ---

[PATCH 2/2] mm: Silence vmap() allocation failures based on caller gfp_flags

If the caller has set __GFP_NOWARN don't print the following message: vmap allocation for size 15736832 failed: use vmalloc= to increase size. This can happen with the ARM/Linux module loader built with CONFIG_ARM_MODULE_PLTS=y which does a first attempt at loading a large module from module

[PATCH 1/2] ARM: Silence non PLT allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case, since that scares people out. Signed-off-by: Florian

[PATCH 2/2] mm: Silence vmap() allocation failures based on caller gfp_flags

If the caller has set __GFP_NOWARN don't print the following message: vmap allocation for size 15736832 failed: use vmalloc= to increase size. This can happen with the ARM/Linux module loader built with CONFIG_ARM_MODULE_PLTS=y which does a first attempt at loading a large module from module

[PATCH 1/2] ARM: Silence non PLT allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case, since that scares people out. Signed-off-by: Florian

[PATCH 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

If the caller has set __GFP_NOWARN don't print the following message: vmap allocation for size 15736832 failed: use vmalloc= to increase size. This can happen with the ARM/Linux module loader built with CONFIG_ARM_MODULE_PLTS=y which does a first attempt at loading a large module from module

[PATCH 1/2] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli

[PATCH 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

If the caller has set __GFP_NOWARN don't print the following message: vmap allocation for size 15736832 failed: use vmalloc= to increase size. This can happen with the ARM/Linux module loader built with CONFIG_ARM_MODULE_PLTS=y which does a first attempt at loading a large module from module

[PATCH 1/2] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli ---

[PATCH 0/3] ARM/ARM64: silence large module first time allocation

With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation done from module space will fail, produce a general OOM allocation and also a vmap warning. The second allocation from vmalloc space may or may not be successful, but is actually the one we are interested about in these

[PATCH 0/3] ARM/ARM64: silence large module first time allocation

With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation done from module space will fail, produce a general OOM allocation and also a vmap warning. The second allocation from vmalloc space may or may not be successful, but is actually the one we are interested about in these

Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

On Mon 2017-04-24 20:05:59, David Lin wrote: > Hi Jacek, > > On Mon, Apr 24, 2017 at 12:59 PM, Jacek Anaszewski > wrote: > > > > Hi David, > > > > Thanks for the patch. > > > > Unfortunately we cannot switch to using hr timers just like that > > without introducing

Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

On Mon 2017-04-24 20:05:59, David Lin wrote: > Hi Jacek, > > On Mon, Apr 24, 2017 at 12:59 PM, Jacek Anaszewski > wrote: > > > > Hi David, > > > > Thanks for the patch. > > > > Unfortunately we cannot switch to using hr timers just like that > > without introducing side effects for many devices.

Re: [resend PATCH v2 00/33] dax: introduce dax_operations

On Fri, Apr 21, 2017 at 6:06 PM, Dan Williams wrote: > [ adding akpm, sfr, and jens ] > > I applied this series and pushed it out for the nvdimm.git branch that > gets auto pulled into -next. The set is still awaiting acks from > device-mapper, ext4, xfs, and vfs (for

Re: [resend PATCH v2 00/33] dax: introduce dax_operations

On Fri, Apr 21, 2017 at 6:06 PM, Dan Williams wrote: > [ adding akpm, sfr, and jens ] > > I applied this series and pushed it out for the nvdimm.git branch that > gets auto pulled into -next. The set is still awaiting acks from > device-mapper, ext4, xfs, and vfs (for the copy_from_iter_ops,

Re: [RESEND][PATCH V2 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver

On Tue, Apr 25, 2017 at 08:32:10PM +0200, Marek Vasut wrote: > Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC. > This block supports three voltage monitors, VD18, VD25, VD33 for the > 1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the > DVFS rail. Please do

Re: [RESEND][PATCH V2 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver

On Tue, Apr 25, 2017 at 08:32:10PM +0200, Marek Vasut wrote: > Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC. > This block supports three voltage monitors, VD18, VD25, VD33 for the > 1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the > DVFS rail. Please do

Re: [PATCH] drivers: input: joystick: Add PSX (Play Station 1/2) pad with SPI driver.

-2-pad-with-SPI-driver/20170425-182329 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386

Re: [PATCH] drivers: input: joystick: Add PSX (Play Station 1/2) pad with SPI driver.

-2-pad-with-SPI-driver/20170425-182329 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386

Re: [PATCH] libnvdimm: fix phys_addr for nvdimm_clear_poison

On 04/25, Kani, Toshimitsu wrote: > On Tue, 2017-04-25 at 15:44 -0600, Vishal Verma wrote: > > On 04/25, Toshi Kani wrote: [...] > > > > Should we be using nsio->res.start here or nsio->addr ? > > nsio->addr is a virtual address. We need to pass the physical address > of this range. I see -

Re: [PATCH] libnvdimm: fix phys_addr for nvdimm_clear_poison

On 04/25, Kani, Toshimitsu wrote: > On Tue, 2017-04-25 at 15:44 -0600, Vishal Verma wrote: > > On 04/25, Toshi Kani wrote: [...] > > > > Should we be using nsio->res.start here or nsio->addr ? > > nsio->addr is a virtual address. We need to pass the physical address > of this range. I see -

Re: linux-next: build failure after merge of the nvdimm tree

On Mon, Apr 24, 2017 at 1:39 AM, Al Viro wrote: > On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote: >> Hi Dan, >> >> After merging the nvdimm tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> drivers/nvdimm/x86.c: In function

Re: linux-next: build failure after merge of the nvdimm tree

On Mon, Apr 24, 2017 at 1:39 AM, Al Viro wrote: > On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote: >> Hi Dan, >> >> After merging the nvdimm tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> drivers/nvdimm/x86.c: In function 'pmem_from_user': >>

Re: [PATCH] drivers: input: joystick: Add PSX (Play Station 1/2) pad with SPI driver.

-2-pad-with-SPI-driver/20170425-182329 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next config: mn10300-allyesconfig (attached as .config) compiler: am33_2.0-linux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin

Re: [PATCH] drivers: input: joystick: Add PSX (Play Station 1/2) pad with SPI driver.

-2-pad-with-SPI-driver/20170425-182329 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next config: mn10300-allyesconfig (attached as .config) compiler: am33_2.0-linux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin

Re: [PATCH 1/2] pinctrl: rockchip: remove unneeded (void *) casts in of_match_table

Hi, Am Mittwoch, 26. April 2017, 06:34:22 CEST schrieb Masahiro Yamada: > of_device_id::data is an opaque pointer. No explicit cast is needed. > > Signed-off-by: Masahiro Yamada > --- > > drivers/pinctrl/pinctrl-rockchip.c | 20 ++-- > 1 file

Re: [PATCH 1/2] pinctrl: rockchip: remove unneeded (void *) casts in of_match_table

Hi, Am Mittwoch, 26. April 2017, 06:34:22 CEST schrieb Masahiro Yamada: > of_device_id::data is an opaque pointer. No explicit cast is needed. > > Signed-off-by: Masahiro Yamada > --- > > drivers/pinctrl/pinctrl-rockchip.c | 20 ++-- > 1 file changed, 10 insertions(+), 10

Re: [PATCH -mm] mm, swap: Fix swap space leak in error path of swap_free_entries()

On Tue, 2017-04-25 at 14:37 -0700, Andrew Morton wrote: > On Fri, 21 Apr 2017 20:47:39 +0800 "Huang, Ying" wrote: > > > > > From: Huang Ying > > > > In swapcache_free_entries(), if swap_info_get_cont() return NULL, > > something wrong occurs for the

Re: [PATCH -mm] mm, swap: Fix swap space leak in error path of swap_free_entries()

On Tue, 2017-04-25 at 14:37 -0700, Andrew Morton wrote: > On Fri, 21 Apr 2017 20:47:39 +0800 "Huang, Ying" wrote: > > > > > From: Huang Ying > > > > In swapcache_free_entries(), if swap_info_get_cont() return NULL, > > something wrong occurs for the swap entry.  But we should still > >

Re: [PATCH v2 1/2] of: support dtc compiler flags for overlays

2017-04-25 8:05 GMT+09:00 : > From: Frank Rowand > > The dtc compiler version that adds initial support was available > in 4.11-rc1. Add the ability to set the dtc compiler flags needed > by overlays. > > Signed-off-by: Frank Rowand

Re: [PATCH v2 1/2] of: support dtc compiler flags for overlays

2017-04-25 8:05 GMT+09:00 : > From: Frank Rowand > > The dtc compiler version that adds initial support was available > in 4.11-rc1. Add the ability to set the dtc compiler flags needed > by overlays. > > Signed-off-by: Frank Rowand > --- I know your motivation for 1/2 is overlay, but this

Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type

On Wed, Apr 26, 2017 at 12:37 AM, Jérémy Lefaure wrote: > On Tue, 25 Apr 2017 00:47:41 +0300 > Andy Shevchenko wrote: > Ok I get it. But changing the format can break the userland tool > anyway, can't it ? For example if a userland tool

Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type

On Wed, Apr 26, 2017 at 12:37 AM, Jérémy Lefaure wrote: > On Tue, 25 Apr 2017 00:47:41 +0300 > Andy Shevchenko wrote: > Ok I get it. But changing the format can break the userland tool > anyway, can't it ? For example if a userland tool expects the value 75, > it won't read it properpy in BCD.

Re: [PATCH] x86: kvm: Avoid guest page table walk when gpa_available is set

I also wanted to avoid adding yet another variable but we can't depend on cr2 parameters passed into x86_emulate_instruction(). The x86_emulate_instruction() function is called from two places: 1) handling the page-fault. pf_interception [svm.c] kvm_mmu_page_fault [mmu.c]

Re: [PATCH] x86: kvm: Avoid guest page table walk when gpa_available is set

I also wanted to avoid adding yet another variable but we can't depend on cr2 parameters passed into x86_emulate_instruction(). The x86_emulate_instruction() function is called from two places: 1) handling the page-fault. pf_interception [svm.c] kvm_mmu_page_fault [mmu.c]

Re: [PATCH] libnvdimm: fix phys_addr for nvdimm_clear_poison

On Tue, 2017-04-25 at 15:44 -0600, Vishal Verma wrote: > On 04/25, Toshi Kani wrote: > > nvdimm_clear_poison() expects a physical address, not an offset. > > Fix nsio_rw_bytes() to call nvdimm_clear_poison() with a physical > > address. > > Good catch! > > > > > Signed-off-by: Toshi Kani

Re: [PATCH] libnvdimm: fix phys_addr for nvdimm_clear_poison

On Tue, 2017-04-25 at 15:44 -0600, Vishal Verma wrote: > On 04/25, Toshi Kani wrote: > > nvdimm_clear_poison() expects a physical address, not an offset. > > Fix nsio_rw_bytes() to call nvdimm_clear_poison() with a physical > > address. > > Good catch! > > > > > Signed-off-by: Toshi Kani > >

Re: [PATCH v8 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

Le 25/04/2017 à 22:25, Marek Vasut a écrit : > On 04/25/2017 10:08 PM, Cyrille Pitchen wrote: >> From: Cyrille Pitchen >> >> This patch changes the prototype of spi_nor_scan(): its 3rd parameter >> is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the

Re: [PATCH v8 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

Le 25/04/2017 à 22:25, Marek Vasut a écrit : > On 04/25/2017 10:08 PM, Cyrille Pitchen wrote: >> From: Cyrille Pitchen >> >> This patch changes the prototype of spi_nor_scan(): its 3rd parameter >> is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor >> framework about the

[PATCH] f2fs: introduce valid_ipu_blkaddr to clean up

This patch introduces valid_ipu_blkaddr to clean up checking block address for inplace-update. Signed-off-by: Jaegeuk Kim --- fs/f2fs/data.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index

Re: [PATCH -mm -v10 3/3] mm, THP, swap: Enable THP swap optimization only if has compound map

On Tue, Apr 25, 2017 at 08:56:58PM +0800, Huang, Ying wrote: > From: Huang Ying > > If there is no compound map for a THP (Transparent Huge Page), it is > possible that the map count of some sub-pages of the THP is 0. So it > is better to split the THP before swapping out.

[PATCH] f2fs: introduce valid_ipu_blkaddr to clean up

This patch introduces valid_ipu_blkaddr to clean up checking block address for inplace-update. Signed-off-by: Jaegeuk Kim --- fs/f2fs/data.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index b2992dbdd11e..c2b98e44c5f3

Re: [PATCH -mm -v10 3/3] mm, THP, swap: Enable THP swap optimization only if has compound map

On Tue, Apr 25, 2017 at 08:56:58PM +0800, Huang, Ying wrote: > From: Huang Ying > > If there is no compound map for a THP (Transparent Huge Page), it is > possible that the map count of some sub-pages of the THP is 0. So it > is better to split the THP before swapping out. In this way, the >

Re: [PATCH] libnvdimm: fix phys_addr for nvdimm_clear_poison

On 04/25, Toshi Kani wrote: > nvdimm_clear_poison() expects a physical address, not an offset. > Fix nsio_rw_bytes() to call nvdimm_clear_poison() with a physical > address. Good catch! > > Signed-off-by: Toshi Kani > Cc: Dan Williams > Cc: Dave

Re: [PATCH] libnvdimm: fix phys_addr for nvdimm_clear_poison

On 04/25, Toshi Kani wrote: > nvdimm_clear_poison() expects a physical address, not an offset. > Fix nsio_rw_bytes() to call nvdimm_clear_poison() with a physical > address. Good catch! > > Signed-off-by: Toshi Kani > Cc: Dan Williams > Cc: Dave Jiang > Cc: Vishal Verma > --- >

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, Apr 25, 2017 at 11:21 PM, One Thousand Gnomes wrote: >> Really? By "pty", are you referring to the master? If so, as far as I know, >> to go from the slave to the master, you need one of: >> >> - ptrace access to a process that already has an FD to the master,

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, Apr 25, 2017 at 11:21 PM, One Thousand Gnomes wrote: >> Really? By "pty", are you referring to the master? If so, as far as I know, >> to go from the slave to the master, you need one of: >> >> - ptrace access to a process that already has an FD to the master, via >>ptrace() or so

[PATCH] Prevent timer value 0 for MWAITX

This patch prevents the value 0 from being used for the MWAITX timer. Newer hardware has uncovered a bug in the software implementation of using MWAITX for the delay function. A value of 0 for the timer is meant to indicate that a timeout will not be used to exit MWAITX. On newer hardware this

[PATCH] Prevent timer value 0 for MWAITX

This patch prevents the value 0 from being used for the MWAITX timer. Newer hardware has uncovered a bug in the software implementation of using MWAITX for the delay function. A value of 0 for the timer is meant to indicate that a timeout will not be used to exit MWAITX. On newer hardware this

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