Re: [PATCH] staging: ks7010: fix ks_wlan_start_xmit()'s return type

On Wed, Apr 25, 2018 at 06:44:38PM +0200, Janusz Lisiecki wrote: > Maybe inside ks_wlan_start_xmit, instead of "return 0;", there should be > "return NETDEV_TX_OK;" and "return NETDEV_TX_BUSY;" otherwise. It is just > suggestion. I see, yes. However, since: 1) this sort of change is really

[PATCH net-next v2 3/7] dt-bindings: net: add DT bindings for Microsemi Ocelot Switch

DT bindings for the Ethernet switch found on Microsemi Ocelot platforms. Cc: Rob Herring Cc: James Hogan Signed-off-by: Alexandre Belloni --- .../devicetree/bindings/net/mscc-ocelot.txt | 82 +++ 1 file changed, 82 insertions(+) create mode 100644

[PATCH net-next v2 2/7] net: mscc: Add MDIO driver

Add a driver for the Microsemi MII Management controller (MIIM) found on Microsemi SoCs. On Ocelot, there are two controllers, one is connected to the internal PHYs, the other one can communicate with external PHYs. Signed-off-by: Alexandre Belloni ---

[PATCH net-next v2 2/7] net: mscc: Add MDIO driver

Add a driver for the Microsemi MII Management controller (MIIM) found on Microsemi SoCs. On Ocelot, there are two controllers, one is connected to the internal PHYs, the other one can communicate with external PHYs. Signed-off-by: Alexandre Belloni --- drivers/net/phy/Kconfig | 7 ++

[RFC PATCH manpages] clock_getres.2: document CLOCK_MONOTONIC suspend behavior

Considering that user-space expects CLOCK_MONOTONIC not to account time during which system is suspended, explicitly document this behavior as ABI. Signed-off-by: Mathieu Desnoyers CC: Michael Kerrisk CC: Thomas Gleixner

[RFC PATCH manpages] clock_getres.2: document CLOCK_MONOTONIC suspend behavior

Considering that user-space expects CLOCK_MONOTONIC not to account time during which system is suspended, explicitly document this behavior as ABI. Signed-off-by: Mathieu Desnoyers CC: Michael Kerrisk CC: Thomas Gleixner CC: John Stultz CC: Stephen Boyd CC: Linus Torvalds ---

Re: [PATCH v6] fs: dax: Adding new return type vm_fault_t

On Tue, Apr 24, 2018 at 10:17:51PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. >

Re: [PATCH v6] fs: dax: Adding new return type vm_fault_t

On Tue, Apr 24, 2018 at 10:17:51PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. >

Re: [PATCH 1/8] drm: bridge: Add support for static image formats

Hi Jacopo, On Thursday, 26 April 2018 21:40:56 EEST jacopo mondi wrote: > On Mon, Apr 23, 2018 at 12:27:39PM +0300, Laurent Pinchart wrote: > > On Thursday, 19 April 2018 12:31:02 EEST Jacopo Mondi wrote: > >> Add support for storing image format information in DRM bridges with > >> associated

Re: [PATCH 1/8] drm: bridge: Add support for static image formats

Hi Jacopo, On Thursday, 26 April 2018 21:40:56 EEST jacopo mondi wrote: > On Mon, Apr 23, 2018 at 12:27:39PM +0300, Laurent Pinchart wrote: > > On Thursday, 19 April 2018 12:31:02 EEST Jacopo Mondi wrote: > >> Add support for storing image format information in DRM bridges with > >> associated

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

Thanks Lorenzo for pulling out the old thread. So just to make sure my understanding is correct from the discussion on that thread, below is not a preferred approach. "If CPUs are marked as disabled in the devicetree, make sure they do not exist in the system CPU information and CPU topology

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

Thanks Lorenzo for pulling out the old thread. So just to make sure my understanding is correct from the discussion on that thread, below is not a preferred approach. "If CPUs are marked as disabled in the devicetree, make sure they do not exist in the system CPU information and CPU topology

Re: [PATCH 2/7] genirq/msi: Limit level-triggered MSI to platform devices

On Mon, 23 Apr 2018, Marc Zyngier wrote: > Nobody would be insane enough to try and use level triggered > MSIs on PCI, but let's make sure it doesn't happen. Also, > let's mandate that the irqchip backing the platform MSI domain > is providing an irq_set_type method (or the whole thing would > be

Re: [PATCH 2/7] genirq/msi: Limit level-triggered MSI to platform devices

On Mon, 23 Apr 2018, Marc Zyngier wrote: > Nobody would be insane enough to try and use level triggered > MSIs on PCI, but let's make sure it doesn't happen. Also, > let's mandate that the irqchip backing the platform MSI domain > is providing an irq_set_type method (or the whole thing would > be

[PATCH] nvme: change order of qid and cmdid in completion trace

Keith reported that command submission and command completion tracepoints have the order of the cmdid and qid fileds swapped. While it isn't easily possible to change the command submission tracepoint, as there is a regression test parsing it in blktests we can swap the command completion

[PATCH] nvme: change order of qid and cmdid in completion trace

Keith reported that command submission and command completion tracepoints have the order of the cmdid and qid fileds swapped. While it isn't easily possible to change the command submission tracepoint, as there is a regression test parsing it in blktests we can swap the command completion

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 03:36:14PM -0400, Mikulas Patocka wrote: > People on this list argue "this should be a kernel parameter". How about making it a writeable attribute, so it's easy to turn on/off after boot. Then you can keep it deterministic, userspace can play with the attribute at random

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 03:36:14PM -0400, Mikulas Patocka wrote: > People on this list argue "this should be a kernel parameter". How about making it a writeable attribute, so it's easy to turn on/off after boot. Then you can keep it deterministic, userspace can play with the attribute at random

[tip:x86/urgent] x86/cpu/intel: Add missing TLB cpuid values

Commit-ID: b837913fc2d9061bf9b8c0dd6bf2d24e2f98b84a Gitweb: https://git.kernel.org/tip/b837913fc2d9061bf9b8c0dd6bf2d24e2f98b84a Author: jacek.tom...@poczta.fm AuthorDate: Tue, 24 Apr 2018 00:14:25 +0800 Committer: Thomas Gleixner CommitDate:

[tip:x86/urgent] x86/cpu/intel: Add missing TLB cpuid values

Commit-ID: b837913fc2d9061bf9b8c0dd6bf2d24e2f98b84a Gitweb: https://git.kernel.org/tip/b837913fc2d9061bf9b8c0dd6bf2d24e2f98b84a Author: jacek.tom...@poczta.fm AuthorDate: Tue, 24 Apr 2018 00:14:25 +0800 Committer: Thomas Gleixner CommitDate: Thu, 26 Apr 2018 21:42:44 +0200

Re: [tip:x86/urgent] x86/cpu/intel: Add missing TLB cpuid values

On Thu, 26 Apr 2018, Thomas Gleixner wrote: > On Fri, 27 Apr 2018, Jacek Tomaka wrote: > > > Hi Thomas, > > > > Looks like the patch has lost a coma after 128. > > + { 0x6c, TLB_DATA_2M_4M, 128 " TLB_DATA 2 MByte or 4 > > MByte pages, 8-way associative" }, > > should be : > > +

Re: [tip:x86/urgent] x86/cpu/intel: Add missing TLB cpuid values

On Thu, 26 Apr 2018, Thomas Gleixner wrote: > On Fri, 27 Apr 2018, Jacek Tomaka wrote: > > > Hi Thomas, > > > > Looks like the patch has lost a coma after 128. > > + { 0x6c, TLB_DATA_2M_4M, 128 " TLB_DATA 2 MByte or 4 > > MByte pages, 8-way associative" }, > > should be : > > +

Re: [PATCH] dt-bindings: staging: remove a couple of ADC bindings

Hello, On Thu, 26 Apr 2018 11:02:55 +0530, Viresh Kumar wrote: > @Thomas: Do you guys use this ? > > On 25-04-18, 20:57, Rob Herring wrote: > > Remove LPC32xx and SPEAr ADC bindings in staging. They have not been > > touched since 2012. > > > > Cc: Roland Stigge > > Cc:

Re: [PATCH] dt-bindings: staging: remove a couple of ADC bindings

Hello, On Thu, 26 Apr 2018 11:02:55 +0530, Viresh Kumar wrote: > @Thomas: Do you guys use this ? > > On 25-04-18, 20:57, Rob Herring wrote: > > Remove LPC32xx and SPEAr ADC bindings in staging. They have not been > > touched since 2012. > > > > Cc: Roland Stigge > > Cc: Stefan Roese > > Cc:

Re: [tip:x86/urgent] x86/cpu/intel: Add missing TLB cpuid values

On Fri, 27 Apr 2018, Jacek Tomaka wrote: > Hi Thomas, > > Looks like the patch has lost a coma after 128. > + { 0x6c, TLB_DATA_2M_4M, 128 " TLB_DATA 2 MByte or 4 > MByte pages, 8-way associative" }, > should be : > + { 0x6c, TLB_DATA_2M_4M, 128, " TLB_DATA 2

Re: [tip:x86/urgent] x86/cpu/intel: Add missing TLB cpuid values

On Fri, 27 Apr 2018, Jacek Tomaka wrote: > Hi Thomas, > > Looks like the patch has lost a coma after 128. > + { 0x6c, TLB_DATA_2M_4M, 128 " TLB_DATA 2 MByte or 4 > MByte pages, 8-way associative" }, > should be : > + { 0x6c, TLB_DATA_2M_4M, 128, " TLB_DATA 2

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > On Thu, Apr 26, 2018 at 02:54:26PM -0400, Mikulas Patocka wrote: > > > > > > On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > > > > > On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > > > > IIUC debug kernels mainly exist so

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > On Thu, Apr 26, 2018 at 02:54:26PM -0400, Mikulas Patocka wrote: > > > > > > On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > > > > > On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > > > > IIUC debug kernels mainly exist so

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

On Thu, Apr 26, 2018 at 12:56 AM, Krzysztof Kozlowski wrote: > On Thu, Apr 26, 2018 at 2:40 AM, Grant Grundler wrote: >> On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski >> wrote: >>> >>> commit

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

On Thu, Apr 26, 2018 at 12:56 AM, Krzysztof Kozlowski wrote: > On Thu, Apr 26, 2018 at 2:40 AM, Grant Grundler wrote: >> On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski >> wrote: >>> >>> commit 90841047a01b452cc8c3f9b990698b264143334a upstream >>> >>> This linksys dongle by default comes

BUG: /proc/kcore does not export direct-mapped memory on arm64 (and presumably some other architectures)

While testing /proc/kcore as the live memory source for the crash utility, it fails on arm64. The failure on arm64 occurs because only the vmalloc/module space segments are exported in PT_LOAD segments, and it's missing all of the PT_LOAD segments for the generic unity-mapped regions of

BUG: /proc/kcore does not export direct-mapped memory on arm64 (and presumably some other architectures)

While testing /proc/kcore as the live memory source for the crash utility, it fails on arm64. The failure on arm64 occurs because only the vmalloc/module space segments are exported in PT_LOAD segments, and it's missing all of the PT_LOAD segments for the generic unity-mapped regions of

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

On Thu 26-04-18 11:19:33, Eric W. Biederman wrote: > Michal Hocko writes: > > > I've had a patch to remove owner few years back. It needed some work > > to finish but maybe that would be a better than try to make > > non-scalable thing suck less. > > I have a question. Would

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

On Thu 26-04-18 11:19:33, Eric W. Biederman wrote: > Michal Hocko writes: > > > I've had a patch to remove owner few years back. It needed some work > > to finish but maybe that would be a better than try to make > > non-scalable thing suck less. > > I have a question. Would it be reasonable

Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration

On 04/26/2018 10:16 PM, Dmitry Torokhov wrote: On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote: On 04/23/2018 09:53 PM, Dmitry Torokhov wrote: On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote: On 04/19/2018 02:25 PM, Juergen Gross wrote: On

Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration

On 04/26/2018 10:16 PM, Dmitry Torokhov wrote: On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote: On 04/23/2018 09:53 PM, Dmitry Torokhov wrote: On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote: On 04/19/2018 02:25 PM, Juergen Gross wrote: On

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 08:17:34AM -0700, Sultan Alsawaf wrote: > > Hmm, can you let the boot hang for a while? It should continue after > > a few minutes if you wait long enough, but wait a minute or two, then > > give it entropy so the boot can continue. Then can you use > > "systemd-analyze

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 08:17:34AM -0700, Sultan Alsawaf wrote: > > Hmm, can you let the boot hang for a while? It should continue after > > a few minutes if you wait long enough, but wait a minute or two, then > > give it entropy so the boot can continue. Then can you use > > "systemd-analyze

Re: [PATCH] proc: use #pragma once

On Thu, Apr 26, 2018 at 03:33:04AM -0700, Christoph Hellwig wrote: > On Thu, Apr 26, 2018 at 12:26:29PM +0200, David Sterba wrote: > > There are about 20k header files, none of them has #pragma once. > > Updating that will bring many unnesessry git commits. > > > > I doubt that one more define in

Re: [PATCH RESEND] firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1()

change has been picked up for v4.18, as you can see here: > https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git/log/?h=for-next Hello Björn, I just looked at today's linux-next tag: next-20180426. I didn't bother to check Andy's tree. Andy's for-next branch is included in linu

Re: [PATCH] proc: use #pragma once

On Thu, Apr 26, 2018 at 03:33:04AM -0700, Christoph Hellwig wrote: > On Thu, Apr 26, 2018 at 12:26:29PM +0200, David Sterba wrote: > > There are about 20k header files, none of them has #pragma once. > > Updating that will bring many unnesessry git commits. > > > > I doubt that one more define in

Re: [PATCH RESEND] firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1()

change has been picked up for v4.18, as you can see here: > https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git/log/?h=for-next Hello Björn, I just looked at today's linux-next tag: next-20180426. I didn't bother to check Andy's tree. Andy's for-next branch is included in linu

Re: [PATCH] proc: use #pragma once

On Thu, Apr 26, 2018 at 12:26:29PM +0200, David Sterba wrote: > On Wed, Apr 25, 2018 at 11:55:31PM +0300, Alexey Dobriyan wrote: > > On Tue, Apr 24, 2018 at 06:54:09AM -0700, Christoph Hellwig wrote: > > > On Tue, Apr 24, 2018 at 12:35:34AM +0300, Alexey Dobriyan wrote: > > > > Bring /proc into

Re: [PATCH] proc: use #pragma once

On Thu, Apr 26, 2018 at 12:26:29PM +0200, David Sterba wrote: > On Wed, Apr 25, 2018 at 11:55:31PM +0300, Alexey Dobriyan wrote: > > On Tue, Apr 24, 2018 at 06:54:09AM -0700, Christoph Hellwig wrote: > > > On Tue, Apr 24, 2018 at 12:35:34AM +0300, Alexey Dobriyan wrote: > > > > Bring /proc into

Re: [PATCH] Revert "ata: ahci-platform: add reset control support"

Hello, On Wed, Apr 18, 2018 at 10:36:47AM +0200, Thierry Reding wrote: > I see that you've applied this to your for-next branch. However, this is > a fix that needs to go into v4.17 because that's where the regression > was introduced. Is there any way you can promote this to a fixes branch?

Re: [PATCH] Revert "ata: ahci-platform: add reset control support"

Hello, On Wed, Apr 18, 2018 at 10:36:47AM +0200, Thierry Reding wrote: > I see that you've applied this to your for-next branch. However, this is > a fix that needs to go into v4.17 because that's where the regression > was introduced. Is there any way you can promote this to a fixes branch?

Re: [PATCH 20/61] input: keyboard: simplify getting .drvdata

Hi Wolfram, On Thu, Apr 19, 2018 at 04:05:50PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. I consider the fact that platform device's driver data is accessible via device driver data being

Re: [PATCH 20/61] input: keyboard: simplify getting .drvdata

Hi Wolfram, On Thu, Apr 19, 2018 at 04:05:50PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. I consider the fact that platform device's driver data is accessible via device driver data being

Re: [PATCH 2/2] blkcg: init root blkcg_gq under lock

Hello, On Thu, Apr 19, 2018 at 12:06:09PM +0800, Jiang Biao wrote: > The initializing of q->root_blkg is currently outside of queue lock > and rcu, so the blkg may be destroied before the initializing, which > may cause dangling/null references. On the other side, the destroys > of blkg are

Re: [PATCH 2/2] blkcg: init root blkcg_gq under lock

Hello, On Thu, Apr 19, 2018 at 12:06:09PM +0800, Jiang Biao wrote: > The initializing of q->root_blkg is currently outside of queue lock > and rcu, so the blkg may be destroied before the initializing, which > may cause dangling/null references. On the other side, the destroys > of blkg are

Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration

On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote: > On 04/23/2018 09:53 PM, Dmitry Torokhov wrote: > > On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote: > > > On 04/19/2018 02:25 PM, Juergen Gross wrote: > > > > On 18/04/18 17:04, Oleksandr

Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration

On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote: > On 04/23/2018 09:53 PM, Dmitry Torokhov wrote: > > On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote: > > > On 04/19/2018 02:25 PM, Juergen Gross wrote: > > > > On 18/04/18 17:04, Oleksandr

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

> "James" == James Bottomley writes: James> On Wed, 2018-04-25 at 19:00 -0400, Mikulas Patocka wrote: >> >> On Wed, 25 Apr 2018, James Bottomley wrote: >> >> > > > Do we really need the new config option?  This could just be >> > > > manually  tunable

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

> "James" == James Bottomley writes: James> On Wed, 2018-04-25 at 19:00 -0400, Mikulas Patocka wrote: >> >> On Wed, 25 Apr 2018, James Bottomley wrote: >> >> > > > Do we really need the new config option?  This could just be >> > > > manually  tunable via fault injection IIUC. >> > >  >> >

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 02:54:26PM -0400, Mikulas Patocka wrote: > > > On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > > > On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > > > IIUC debug kernels mainly exist so people who experience e.g. memory > > > > corruption can try

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 02:54:26PM -0400, Mikulas Patocka wrote: > > > On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > > > On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > > > IIUC debug kernels mainly exist so people who experience e.g. memory > > > > corruption can try

Re: [PATCH] USB: serial: option: adding support for ublox R410M

On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote: > On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote: > > On 4/26/2018 23:12, Johan Hovold wrote: > > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote: > > > > On 4/26/2018 18:39, Lars Melin wrote: > > > > > On 4/26/2018

Re: [PATCH] USB: serial: option: adding support for ublox R410M

On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote: > On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote: > > On 4/26/2018 23:12, Johan Hovold wrote: > > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote: > > > > On 4/26/2018 18:39, Lars Melin wrote: > > > > > On 4/26/2018

Re: [PATCH] mm: sections are not offlined during memory hotremove

On Thu 26-04-18 21:11:11, Michal Hocko wrote: > On Thu 26-04-18 11:58:34, Pavel Tatashin wrote: > > Memory hotplug, and hotremove operate with per-block granularity. If > > machine has large amount of memory (more than 64G), the size of memory > > block can span multiple sections. By mistake,

Re: [PATCH] mm: sections are not offlined during memory hotremove

On Thu 26-04-18 21:11:11, Michal Hocko wrote: > On Thu 26-04-18 11:58:34, Pavel Tatashin wrote: > > Memory hotplug, and hotremove operate with per-block granularity. If > > machine has large amount of memory (more than 64G), the size of memory > > block can span multiple sections. By mistake,

Re: [PATCH] mm: sections are not offlined during memory hotremove

On Thu 26-04-18 11:58:34, Pavel Tatashin wrote: > Memory hotplug, and hotremove operate with per-block granularity. If > machine has large amount of memory (more than 64G), the size of memory > block can span multiple sections. By mistake, during hotremove we set > only the first section to

Re: [PATCH] mm: sections are not offlined during memory hotremove

On Thu 26-04-18 11:58:34, Pavel Tatashin wrote: > Memory hotplug, and hotremove operate with per-block granularity. If > machine has large amount of memory (more than 64G), the size of memory > block can span multiple sections. By mistake, during hotremove we set > only the first section to

[PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0

Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc. Reported-by: Geert Uytterhoeven Signed-off-by: Jacopo Mondi --- arch/arm/boot/dts/r8a7740.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git

[PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0

Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc. Reported-by: Geert Uytterhoeven Signed-off-by: Jacopo Mondi --- arch/arm/boot/dts/r8a7740.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi index

[PATCH v2 1/2] dt-bindings: media: renesas-ceu: Add R-Mobile R8A7740

Add R-Mobile A1 R8A7740 SoC to the list of compatible values for the CEU unit. Signed-off-by: Jacopo Mondi --- Documentation/devicetree/bindings/media/renesas,ceu.txt | 7 --- drivers/media/platform/renesas-ceu.c| 1 + 2 files changed, 5

[PATCH v2 1/2] dt-bindings: media: renesas-ceu: Add R-Mobile R8A7740

Add R-Mobile A1 R8A7740 SoC to the list of compatible values for the CEU unit. Signed-off-by: Jacopo Mondi --- Documentation/devicetree/bindings/media/renesas,ceu.txt | 7 --- drivers/media/platform/renesas-ceu.c| 1 + 2 files changed, 5 insertions(+), 3 deletions(-)

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 02:58:08PM -0400, Mikulas Patocka wrote: > > > On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > > > How do you make sure QA tests a specific corner case? Add it to > > the test plan :) > > BTW. how many "lines of code" of corporate bureaucracy would that take? :-) It's

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 02:58:08PM -0400, Mikulas Patocka wrote: > > > On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > > > How do you make sure QA tests a specific corner case? Add it to > > the test plan :) > > BTW. how many "lines of code" of corporate bureaucracy would that take? :-) It's

[PATCH v2 0/2]

Hello, this small series add R-Mobile A1 R8A7740 to the list of CEU supported SoCs, and adds the CEU node to r8a7740.dtsi. All the information on CEU clocks, power domains and memory regions have been deducted from the now-deleted board file: arch/arm/mach-shmobile/board-armadillo800eva.c

[PATCH v2 0/2]

Hello, this small series add R-Mobile A1 R8A7740 to the list of CEU supported SoCs, and adds the CEU node to r8a7740.dtsi. All the information on CEU clocks, power domains and memory regions have been deducted from the now-deleted board file: arch/arm/mach-shmobile/board-armadillo800eva.c

Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, 25 Apr 2018, Mikulas Patocka wrote: > Do you want this? It deletes slab_order and replaces it with the > "minimize_waste" logic directly. Well yes that looks better. Now we need to make it easy to read and less complicated. Maybe try to keep as much as possible of the old code and also

Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, 25 Apr 2018, Mikulas Patocka wrote: > Do you want this? It deletes slab_order and replaces it with the > "minimize_waste" logic directly. Well yes that looks better. Now we need to make it easy to read and less complicated. Maybe try to keep as much as possible of the old code and also

Re: [PATCH 4/7] sched/core: uclamp: add utilization clamping to the CPU controller

Hello, Joel. On Sat, Apr 21, 2018 at 02:08:30PM -0700, Joel Fernandes wrote: > Actually no, its not about overloading them. What's Patrick is > defining here is a property/attribute. What that attribute is used for > (the algorithms that use it) are a different topic. Like, it can be > used by

Re: [PATCH 4/7] sched/core: uclamp: add utilization clamping to the CPU controller

Hello, Joel. On Sat, Apr 21, 2018 at 02:08:30PM -0700, Joel Fernandes wrote: > Actually no, its not about overloading them. What's Patrick is > defining here is a property/attribute. What that attribute is used for > (the algorithms that use it) are a different topic. Like, it can be > used by

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > How do you make sure QA tests a specific corner case? Add it to > the test plan :) BTW. how many "lines of code" of corporate bureaucracy would that take? :-) > I don't speak for Red Hat, etc. > > -- > MST Mikulas

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > How do you make sure QA tests a specific corner case? Add it to > the test plan :) BTW. how many "lines of code" of corporate bureaucracy would that take? :-) > I don't speak for Red Hat, etc. > > -- > MST Mikulas

Re: [PATCH v8 07/13] drivers: base cacheinfo: Add support for ACPI based firmware tables

Hi, On 04/26/2018 06:05 AM, Sudeep Holla wrote: On 26/04/18 00:31, Jeremy Linton wrote: Call ACPI cache parsing routines from base cacheinfo code if ACPI is enable. Also stub out cache_setup_acpi() so that individual architectures can enable ACPI topology parsing. [...] +#ifndef

Re: [PATCH v8 07/13] drivers: base cacheinfo: Add support for ACPI based firmware tables

Hi, On 04/26/2018 06:05 AM, Sudeep Holla wrote: On 26/04/18 00:31, Jeremy Linton wrote: Call ACPI cache parsing routines from base cacheinfo code if ACPI is enable. Also stub out cache_setup_acpi() so that individual architectures can enable ACPI topology parsing. [...] +#ifndef

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > > IIUC debug kernels mainly exist so people who experience e.g. memory > > > corruption can try and debug the failure. In this case, CONFIG_DEBUG_SG > > > will *already* catch a

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > > IIUC debug kernels mainly exist so people who experience e.g. memory > > > corruption can try and debug the failure. In this case, CONFIG_DEBUG_SG > > > will *already* catch a

Re: [PATCH v2] memcg: writeback: use memcg->cgwb_list directly

On Sun, Apr 22, 2018 at 10:09:33PM +0800, Wang Long wrote: > mem_cgroup_cgwb_list is a very simple wrapper and it will > never be used outside of code under CONFIG_CGROUP_WRITEBACK. > so use memcg->cgwb_list directly. > > Reviewed-by: Jan Kara > Signed-off-by: Wang Long

Re: [PATCH v2] memcg: writeback: use memcg->cgwb_list directly

On Sun, Apr 22, 2018 at 10:09:33PM +0800, Wang Long wrote: > mem_cgroup_cgwb_list is a very simple wrapper and it will > never be used outside of code under CONFIG_CGROUP_WRITEBACK. > so use memcg->cgwb_list directly. > > Reviewed-by: Jan Kara > Signed-off-by: Wang Long Acked-by: Tejun Heo

Re: [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver

On 26/04/2018 18:46:23+0200, Sebastian Andrzej Siewior wrote: > On 2018-04-18 12:51:37 [+0200], Alexandre Belloni wrote: > > Hi, > > Hi, > > please keep on Cc if you intend to repost this. > Sure, I'll do. > > This series gets back on the TCB drivers rework. It introduces a new driver > > to

Re: [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver

On 26/04/2018 18:46:23+0200, Sebastian Andrzej Siewior wrote: > On 2018-04-18 12:51:37 [+0200], Alexandre Belloni wrote: > > Hi, > > Hi, > > please keep on Cc if you intend to repost this. > Sure, I'll do. > > This series gets back on the TCB drivers rework. It introduces a new driver > > to

Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, 25 Apr 2018, Mikulas Patocka wrote: > > > > Could yo move that logic into slab_order()? It does something awfully > > similar. > > But slab_order (and its caller) limits the order to "max_order" and we > want more. > > Perhaps slab_order should be dropped and calculate_order totally >

Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, 25 Apr 2018, Mikulas Patocka wrote: > > > > Could yo move that logic into slab_order()? It does something awfully > > similar. > > But slab_order (and its caller) limits the order to "max_order" and we > want more. > > Perhaps slab_order should be dropped and calculate_order totally >

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > IIUC debug kernels mainly exist so people who experience e.g. memory > > corruption can try and debug the failure. In this case, CONFIG_DEBUG_SG > > will *already* catch a failure early. Nothing special needs to be done. > > The

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > IIUC debug kernels mainly exist so people who experience e.g. memory > > corruption can try and debug the failure. In this case, CONFIG_DEBUG_SG > > will *already* catch a failure early. Nothing special needs to be done. > > The

[GIT PULL] hwmon fixes for v4.17-rc3

Hi Linus, Please pull hwmon fixes for Linux v4.17-rc3 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.17-rc3 Thanks, Guenter -- The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e: Linux 4.17-rc2

[GIT PULL] hwmon fixes for v4.17-rc3

Hi Linus, Please pull hwmon fixes for Linux v4.17-rc3 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.17-rc3 Thanks, Guenter -- The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e: Linux 4.17-rc2

[PATCH v2 1/2] spi: bcm-qspi: Avoid setting MSPI_CDRAM_PCS for spi-nor master

Added fix for probing of spi-nor device non-zero chip selects. Set MSPI_CDRAM_PCS (peripheral chip select) with spi master for MSPI controller and not for MSPI/BSPI spi-nor master controller. Ensure setting of cs bit in chip select register on chip select change. Fixes: fa236a7ef24048 ("spi:

[PATCH v2 0/2] spi: bcm-qspi: Fix spi-nor chip select logic for BSPI

When using the spi-nor master controller always verify the chip select bit in the cs register. Also do not use CDRAM PCS bit in BSPI mode. Additionally make sure to enable/disable BSPI_MAST_N_BOOT_CTRL while using BSPI mode. V2 changes: - Added "Fixes:" tag to 1/2 and 2/2 patches Kamal Dasu (2):

[PATCH v2 1/2] spi: bcm-qspi: Avoid setting MSPI_CDRAM_PCS for spi-nor master

Added fix for probing of spi-nor device non-zero chip selects. Set MSPI_CDRAM_PCS (peripheral chip select) with spi master for MSPI controller and not for MSPI/BSPI spi-nor master controller. Ensure setting of cs bit in chip select register on chip select change. Fixes: fa236a7ef24048 ("spi:

[PATCH v2 0/2] spi: bcm-qspi: Fix spi-nor chip select logic for BSPI

When using the spi-nor master controller always verify the chip select bit in the cs register. Also do not use CDRAM PCS bit in BSPI mode. Additionally make sure to enable/disable BSPI_MAST_N_BOOT_CTRL while using BSPI mode. V2 changes: - Added "Fixes:" tag to 1/2 and 2/2 patches Kamal Dasu (2):

[PATCH v2 2/2] spi: bcm-qspi: Always read and set BSPI_MAST_N_BOOT_CTRL

Always confirm the BSPI_MAST_N_BOOT_CTRL bit when enabling or disabling BSPI transfers. Fixes: 4e3b2d236fe00 ("spi: bcm-qspi: Add BSPI spi-nor flash controller driver") Signed-off-by: Kamal Dasu --- drivers/spi/spi-bcm-qspi.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH v2 2/2] spi: bcm-qspi: Always read and set BSPI_MAST_N_BOOT_CTRL

Always confirm the BSPI_MAST_N_BOOT_CTRL bit when enabling or disabling BSPI transfers. Fixes: 4e3b2d236fe00 ("spi: bcm-qspi: Add BSPI spi-nor flash controller driver") Signed-off-by: Kamal Dasu --- drivers/spi/spi-bcm-qspi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[V4 PATCH] perf parse-events: Specially handle uncore event alias in small groups

From: Kan Liang Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000 # time counts unit events 1.000447342

[V4 PATCH] perf parse-events: Specially handle uncore event alias in small groups

From: Kan Liang Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000 # time counts unit events 1.000447342unc_m_cas_count.all

Re: [PATCH] libata: Apply NOLPM quirk for SAMSUNG MZMPC128HBFU-000MV SSD

On Tue, Apr 24, 2018 at 11:19:07AM +0200, Hans de Goede wrote: > Kevin Shanahan reports the following repeating errors when using LPM, > causing long delays accessing the disk: > > Apr 23 10:21:43 link kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr > 0x5 action 0x6 frozen > Apr 23

Re: [PATCH] libata: Apply NOLPM quirk for SAMSUNG MZMPC128HBFU-000MV SSD

On Tue, Apr 24, 2018 at 11:19:07AM +0200, Hans de Goede wrote: > Kevin Shanahan reports the following repeating errors when using LPM, > causing long delays accessing the disk: > > Apr 23 10:21:43 link kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr > 0x5 action 0x6 frozen > Apr 23

<    3   4   5   6   7   8   9   10   11   12   >