[PATCH 1/2] mm: extract common code for calculating total memory size

Total memory size is needed by unreclaimable slub oom to check if significant memory is used by a single slab. But, the caculation work is done in show_mem(), so extracting the common code in order to share with others. Signed-off-by: Yang Shi --- include/linux/mm.h | 25

[PATCH 1/2] mm: extract common code for calculating total memory size

Total memory size is needed by unreclaimable slub oom to check if significant memory is used by a single slab. But, the caculation work is done in show_mem(), so extracting the common code in order to share with others. Signed-off-by: Yang Shi --- include/linux/mm.h | 25

Re: [PATCH] Hugetlb pages rss accounting is incorrect in /proc//smaps

On Wed, Oct 25, 2017 at 08:55:27AM +0200, Michal Hocko wrote: > [CCing Naoya] > > On Tue 24-10-17 16:56:08, Prakash Sangappa wrote: > > Resident set size(Rss) accounting of hugetlb pages is not done > > currently in /proc//smaps. The pmap command reads rss from > > this file and so it shows Rss

Re: [PATCH] Hugetlb pages rss accounting is incorrect in /proc//smaps

On Wed, Oct 25, 2017 at 08:55:27AM +0200, Michal Hocko wrote: > [CCing Naoya] > > On Tue 24-10-17 16:56:08, Prakash Sangappa wrote: > > Resident set size(Rss) accounting of hugetlb pages is not done > > currently in /proc//smaps. The pmap command reads rss from > > this file and so it shows Rss

[PATCH char-misc 1/1] Hyper-V: Remove x86-isms from architecture independent Hyper-V drivers

From: Michael Kelley hv_is_hypercall_page_setup() is used to check if Hyper-V is initialized, but a 'hypercall page' is an x86 implementation detail that isn't necessarily present on other architectures. Rename to the architecture independent hv_is_hyperv_initialized().

[PATCH char-misc 1/1] Hyper-V: Remove x86-isms from architecture independent Hyper-V drivers

From: Michael Kelley hv_is_hypercall_page_setup() is used to check if Hyper-V is initialized, but a 'hypercall page' is an x86 implementation detail that isn't necessarily present on other architectures. Rename to the architecture independent hv_is_hyperv_initialized(). Use this function

Re: [PATCH] PCI: rework error checking in the reset path

On Wed, 25 Oct 2017 17:10:46 -0500 Bjorn Helgaas wrote: > On Wed, Oct 25, 2017 at 11:28:05PM +0200, Alex Williamson wrote: > > On Wed, 25 Oct 2017 08:45:11 -0500 > > Bjorn Helgaas wrote: > > > > > [+cc Alex] > > > > > > On Mon, Oct 23, 2017 at

Re: [PATCH] PCI: rework error checking in the reset path

On Wed, 25 Oct 2017 17:10:46 -0500 Bjorn Helgaas wrote: > On Wed, Oct 25, 2017 at 11:28:05PM +0200, Alex Williamson wrote: > > On Wed, 25 Oct 2017 08:45:11 -0500 > > Bjorn Helgaas wrote: > > > > > [+cc Alex] > > > > > > On Mon, Oct 23, 2017 at 05:36:48PM -0400, Sinan Kaya wrote: > > > >

[PATCH] PREEMPT_RT: sched/rr, sched/fair: defer CFS scheduler put_prev_task()

Defer calling put_prev_task() on a CFS task_struct when there is a pending RT task to run. Instead wait until the next pick_next_task_fair() and do the work there. The put_prev_task() call for a SCHED_OTHER task is currently a source of non determinism in the latency of scheduling a SCHED_FIFO

[PATCH] PREEMPT_RT: sched/rr, sched/fair: defer CFS scheduler put_prev_task()

Defer calling put_prev_task() on a CFS task_struct when there is a pending RT task to run. Instead wait until the next pick_next_task_fair() and do the work there. The put_prev_task() call for a SCHED_OTHER task is currently a source of non determinism in the latency of scheduling a SCHED_FIFO

Re: [PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

Hi Shuah, For MFC patch, you can delete the "dev" variable since it's not being used anymore and results in a compile warning. - struct s5p_mfc_dev *dev = ctx->dev; Cheers, Marian On Thu, Oct 26, 2017 at 7:54 AM, Shuah Khan wrote: > On 10/06/2017 03:30 PM, Shuah Khan

Re: [PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

Hi Shuah, For MFC patch, you can delete the "dev" variable since it's not being used anymore and results in a compile warning. - struct s5p_mfc_dev *dev = ctx->dev; Cheers, Marian On Thu, Oct 26, 2017 at 7:54 AM, Shuah Khan wrote: > On 10/06/2017 03:30 PM, Shuah Khan wrote: >> This patch

Re: [PATCH v7] printk: hash addresses printed with %p

On Wed, Oct 25, 2017 at 06:00:21AM +0200, Jason A. Donenfeld wrote: > On Wed, Oct 25, 2017 at 5:49 AM, Tobin C. Harding wrote: > > static_branch_disable(_ptr_secret) : Doesn't sleep, just atomic read > > and set and maybe a WARN_ONCE. > > Are you sure about that? I just looked

Re: [PATCH v7] printk: hash addresses printed with %p

On Wed, Oct 25, 2017 at 06:00:21AM +0200, Jason A. Donenfeld wrote: > On Wed, Oct 25, 2017 at 5:49 AM, Tobin C. Harding wrote: > > static_branch_disable(_ptr_secret) : Doesn't sleep, just atomic read > > and set and maybe a WARN_ONCE. > > Are you sure about that? I just looked myself, and though

Re: Fixing CVE-2017-15361

Am 25. Oktober 2017 20:53:49 MESZ schrieb Jarkko Sakkinen : >On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: >> On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen >> wrote: >> > I'm implementing a fix for

Re: Fixing CVE-2017-15361

Am 25. Oktober 2017 20:53:49 MESZ schrieb Jarkko Sakkinen : >On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: >> On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen >> wrote: >> > I'm implementing a fix for CVE-2017-15361 that simply blacklists >> > vulnerable FW versions. I think

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

> I found that genalloc is very slow for large chunk sizes because > bitmap_find_next_zero_area has to grind through that entire bitmap. > Hence, I recommend avoiding genalloc for large chunk sizes. Thanks for the feedback Daniel! We have been doing 16GiB without any noticeable issues. > I'm

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

> I found that genalloc is very slow for large chunk sizes because > bitmap_find_next_zero_area has to grind through that entire bitmap. > Hence, I recommend avoiding genalloc for large chunk sizes. Thanks for the feedback Daniel! We have been doing 16GiB without any noticeable issues. > I'm

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board election results 2017

Hello, On Wednesday, 25 October 2017 19:47:10 EEST H. Peter Anvin wrote: > The TAB elections are now complete. Thank you to all the candidates for > putting their names forward. > > With 73 ballots cast, the top 5 candidates received: > > Steve Rostedt 58 > Jonathan Corbet

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board election results 2017

Hello, On Wednesday, 25 October 2017 19:47:10 EEST H. Peter Anvin wrote: > The TAB elections are now complete. Thank you to all the candidates for > putting their names forward. > > With 73 ballots cast, the top 5 candidates received: > > Steve Rostedt 58 > Jonathan Corbet

Re: [PATCH v7] printk: hash addresses printed with %p

On Wed, Oct 25, 2017 at 09:02:34PM +0200, Rasmus Villemoes wrote: > On 25 October 2017 at 01:57, Tobin C. Harding wrote: > > On Tue, Oct 24, 2017 at 09:25:20PM +0200, Rasmus Villemoes wrote: > >> > >> I haven't followed the discussion too closely, but has it been > >> considered to

Re: [PATCH v7] printk: hash addresses printed with %p

On Wed, Oct 25, 2017 at 09:02:34PM +0200, Rasmus Villemoes wrote: > On 25 October 2017 at 01:57, Tobin C. Harding wrote: > > On Tue, Oct 24, 2017 at 09:25:20PM +0200, Rasmus Villemoes wrote: > >> > >> I haven't followed the discussion too closely, but has it been > >> considered to exempt NULL

RE: [PATCH] MIPS: Boston: Fix earlycon baud rate selection

Hi Matt, On Tuesday, October 17, 2017 at 6:28 AM Matt Redfearn wrote: > During set up of the early console, the earlycon driver will attempt to > configure a baud rate, if one is set in the earlycon structure. > Previously, of_setup_earlycon left this field as 0, ignoring any baud > rate selected

RE: [PATCH] MIPS: Boston: Fix earlycon baud rate selection

Hi Matt, On Tuesday, October 17, 2017 at 6:28 AM Matt Redfearn wrote: > During set up of the early console, the earlycon driver will attempt to > configure a baud rate, if one is set in the earlycon structure. > Previously, of_setup_earlycon left this field as 0, ignoring any baud > rate selected

Re: Parental Leave and IOMMU Maintenance

-smmu/updates' of git://git.kernel.org/.../will/linux into iommu/arm/smmu iommu/amd: Fix alloc_irq_index() increment Merge branches 'vfio/fixes', 'vfio/platform', 'iommu/arm/smmu' and 'iommu/updates' into next-20171025 Alexey Kardashevskiy (1): vfio/spapr: Add cond_resched() for huge update

Re: Parental Leave and IOMMU Maintenance

org/.../will/linux into iommu/arm/smmu iommu/amd: Fix alloc_irq_index() increment Merge branches 'vfio/fixes', 'vfio/platform', 'iommu/arm/smmu' and 'iommu/updates' into next-20171025 Alexey Kardashevskiy (1): vfio/spapr: Add cond_resched() for huge updates Anup Patel (1):

Re: [PATCH] PCI: rework error checking in the reset path

On Wed, Oct 25, 2017 at 11:28:05PM +0200, Alex Williamson wrote: > On Wed, 25 Oct 2017 08:45:11 -0500 > Bjorn Helgaas wrote: > > > [+cc Alex] > > > > On Mon, Oct 23, 2017 at 05:36:48PM -0400, Sinan Kaya wrote: > > > The return codes from various reset types are not

Re: [PATCH] PCI: rework error checking in the reset path

On Wed, Oct 25, 2017 at 11:28:05PM +0200, Alex Williamson wrote: > On Wed, 25 Oct 2017 08:45:11 -0500 > Bjorn Helgaas wrote: > > > [+cc Alex] > > > > On Mon, Oct 23, 2017 at 05:36:48PM -0400, Sinan Kaya wrote: > > > The return codes from various reset types are not consistent. The code is > > >

[PATCH V2] perf script: add script to profile and resolve physical mem type

From: Kan Liang There could be different types of memory in the system. E.g normal System Memory, Persistent Memory. To understand how the workload maps to those memories, it's important to know the I/O statistics of them. Perf can collect physical addresses, but those are

[PATCH V2] perf script: add script to profile and resolve physical mem type

From: Kan Liang There could be different types of memory in the system. E.g normal System Memory, Persistent Memory. To understand how the workload maps to those memories, it's important to know the I/O statistics of them. Perf can collect physical addresses, but those are raw data. It still

Re: [prefix=PATCH] drivers: pmbus: core: Prevent calling pmbus_set_page with negative page

On Wed, Oct 25, 2017 at 04:23:01PM -0500, Eddie James wrote: > > > On 10/25/2017 04:12 PM, Guenter Roeck wrote: > >On Wed, Oct 25, 2017 at 02:52:53PM -0500, Eddie James wrote: > >>From: "Edward A. James" > >> > >>For devices with word data registers, the pmbus core may call

Re: [prefix=PATCH] drivers: pmbus: core: Prevent calling pmbus_set_page with negative page

On Wed, Oct 25, 2017 at 04:23:01PM -0500, Eddie James wrote: > > > On 10/25/2017 04:12 PM, Guenter Roeck wrote: > >On Wed, Oct 25, 2017 at 02:52:53PM -0500, Eddie James wrote: > >>From: "Edward A. James" > >> > >>For devices with word data registers, the pmbus core may call read/write > >>word

[PATCH net-next 1/9] net: bcmgenet: correct bad merge

As noted in the net-next submission for GENETv5 support [1], there were merge conflicts with an earlier net submission [2] that had not yet found its way to the net-next repository. Unfortunately, when the branches were merged the conflicts were not correctly resolved. This commit attempts to

[PATCH net-next 1/9] net: bcmgenet: correct bad merge

As noted in the net-next submission for GENETv5 support [1], there were merge conflicts with an earlier net submission [2] that had not yet found its way to the net-next repository. Unfortunately, when the branches were merged the conflicts were not correctly resolved. This commit attempts to

[PATCH net-next 2/9] net: bcmgenet: prevent duplicate calls of bcmgenet_dma_teardown

When bcmgenet_dma_teardown is called from bcmgenet_fini_dma it ends up getting called twice from the bcmgenet_close and bcmgenet_suspend functions (once directly and once inside the bcmgenet_fini_dma call). This commit removes the call from bcmgenet_fini_dma and ensures that bcmgenet_dma_teardown

[PATCH net-next 2/9] net: bcmgenet: prevent duplicate calls of bcmgenet_dma_teardown

When bcmgenet_dma_teardown is called from bcmgenet_fini_dma it ends up getting called twice from the bcmgenet_close and bcmgenet_suspend functions (once directly and once inside the bcmgenet_fini_dma call). This commit removes the call from bcmgenet_fini_dma and ensures that bcmgenet_dma_teardown

[PATCH net-next 5/9] net: bcmgenet: cleanup ring interrupt masking and unmasking

Since the NAPI interrupts are basically ignored when NAPI is disabled we don't need to mask them within the functions bcmgenet_disable_tx_napi() and bcmgenet_disable_rx_napi(). So wait until all NAPI instances are disabled and mask all of the bcmgenet driver interrupts together in

[PATCH net-next 3/9] net: bcmgenet: enable loopback during UniMAC sw_reset

It is necessary for the UniMAC to be clocked at least 5 cycles while the sw_reset is asserted to ensure a clean reset. It was discovered that this condition was not being met when connected to an external RGMII PHY that disabled the Rx clock in the Power Save state. This commit modifies the

[PATCH net-next 5/9] net: bcmgenet: cleanup ring interrupt masking and unmasking

Since the NAPI interrupts are basically ignored when NAPI is disabled we don't need to mask them within the functions bcmgenet_disable_tx_napi() and bcmgenet_disable_rx_napi(). So wait until all NAPI instances are disabled and mask all of the bcmgenet driver interrupts together in

[PATCH net-next 3/9] net: bcmgenet: enable loopback during UniMAC sw_reset

It is necessary for the UniMAC to be clocked at least 5 cycles while the sw_reset is asserted to ensure a clean reset. It was discovered that this condition was not being met when connected to an external RGMII PHY that disabled the Rx clock in the Power Save state. This commit modifies the

[PATCH net-next 6/9] net: bcmgenet: rework bcmgenet_netif_start and bcmgenet_netif_stop

This commit consolidates more common functionality from bcmgenet_close and bcmgenet_suspend into bcmgenet_netif_stop and modifies the start and stop sequences to better suit the design of the GENET hardware. Signed-off-by: Doug Berger ---

[PATCH net-next 6/9] net: bcmgenet: rework bcmgenet_netif_start and bcmgenet_netif_stop

This commit consolidates more common functionality from bcmgenet_close and bcmgenet_suspend into bcmgenet_netif_stop and modifies the start and stop sequences to better suit the design of the GENET hardware. Signed-off-by: Doug Berger --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 49

[PATCH net-next 9/9] net: bcmgenet: use dev->phydev instead of priv->phydev

Now that the software reset of the PHY has been removed it is no longer necessary to retain a private pointer to the phydev for use when the PHY is detached (which isn't generally safe anyway). The driver now uses the phydev member attached to the net_device. For ethtool commands that have a PHY

[PATCH net-next 9/9] net: bcmgenet: use dev->phydev instead of priv->phydev

Now that the software reset of the PHY has been removed it is no longer necessary to retain a private pointer to the phydev for use when the PHY is detached (which isn't generally safe anyway). The driver now uses the phydev member attached to the net_device. For ethtool commands that have a PHY

[PATCH net-next 8/9] Revert "net: bcmgenet: Software reset EPHY after power on"

With commit f7d72996e222 ("net: bcmgenet: enable loopback during UniMAC sw_reset") it is no longer necessary to force the software reset of the internal EPHY before resetting the UniMAC to ensure a clean reset. Therefore this commit reverts commit 5dbebbb44a6a ("net: bcmgenet: Software reset EPHY

[PATCH net-next 8/9] Revert "net: bcmgenet: Software reset EPHY after power on"

With commit f7d72996e222 ("net: bcmgenet: enable loopback during UniMAC sw_reset") it is no longer necessary to force the software reset of the internal EPHY before resetting the UniMAC to ensure a clean reset. Therefore this commit reverts commit 5dbebbb44a6a ("net: bcmgenet: Software reset EPHY

[PATCH net-next 7/9] net: bcmgenet: relax lock constraints to reduce IRQ latency

Since the ring locks are not used in a hard IRQ context it is often not necessary to disable global IRQs while waiting on a lock. Using less restrictive lock and unlock calls improves the real-time responsiveness of the system. Signed-off-by: Doug Berger ---

[PATCH net-next 7/9] net: bcmgenet: relax lock constraints to reduce IRQ latency

Since the ring locks are not used in a hard IRQ context it is often not necessary to disable global IRQs while waiting on a lock. Using less restrictive lock and unlock calls improves the real-time responsiveness of the system. Signed-off-by: Doug Berger ---

[PATCH net-next 0/9] net: bcmgenet: start/stop sequence refinement

This commit set is the result of an investigation into an issue that occurred when bringing the interface up and down repeatedly with an external 100BASE-T PHY. In some cases the MAC would experience mass receive packet duplication that could in rare cases lead to a stall from overflow. The fix

[PATCH net-next 0/9] net: bcmgenet: start/stop sequence refinement

This commit set is the result of an investigation into an issue that occurred when bringing the interface up and down repeatedly with an external 100BASE-T PHY. In some cases the MAC would experience mass receive packet duplication that could in rare cases lead to a stall from overflow. The fix

[PATCH net-next 4/9] net: bcmgenet: move NAPI initialization to ring initialization

Since each ring has its own NAPI instance it might as well be initialized along with the other ring context. Signed-off-by: Doug Berger --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 42 +- 1 file changed, 8 insertions(+), 34 deletions(-) diff

[PATCH net-next 4/9] net: bcmgenet: move NAPI initialization to ring initialization

Since each ring has its own NAPI instance it might as well be initialized along with the other ring context. Signed-off-by: Doug Berger --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 42 +- 1 file changed, 8 insertions(+), 34 deletions(-) diff --git

[PATCH 2/3] usb: phy: remove phy-msm-usb.c

No Qualcomm SoC requires the "phy-msm-usb.c" USB phy driver support any more, so remove the code. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross ---

[PATCH 2/3] usb: phy: remove phy-msm-usb.c

No Qualcomm SoC requires the "phy-msm-usb.c" USB phy driver support any more, so remove the code. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross --- drivers/usb/phy/Makefile |1 - drivers/usb/phy/phy-msm-usb.c | 2085

[PATCH 0/3] usb: remove some unused code

This series deletes some Qualcomm USB code is no longer needed by any Qualcomm hardware. -Alex Alex Elder (3): usb: host: remove ehci-msm.c usb: phy: remove phy-msm-usb.c usb: phy: remove phy-qcom-8x16-usb.c drivers/usb/host/Makefile |

[PATCH 0/3] usb: remove some unused code

This series deletes some Qualcomm USB code is no longer needed by any Qualcomm hardware. -Alex Alex Elder (3): usb: host: remove ehci-msm.c usb: phy: remove phy-msm-usb.c usb: phy: remove phy-qcom-8x16-usb.c drivers/usb/host/Makefile |

[PATCH 3/3] usb: phy: remove phy-qcom-8x16-usb.c

No Qualcomm SoC requires the "phy-qcom-8x16-usb.c" USB phy driver support any more, so remove the code. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross

[PATCH 1/3] usb: host: remove ehci-msm.c

No Qualcomm SoC requires the "ehci-msm.c" code any more. So remove it. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross --- drivers/usb/host/Makefile

[PATCH 3/3] usb: phy: remove phy-qcom-8x16-usb.c

No Qualcomm SoC requires the "phy-qcom-8x16-usb.c" USB phy driver support any more, so remove the code. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross --- drivers/usb/phy/Makefile| 1 - drivers/usb/phy/phy-qcom-8x16-usb.c |

[PATCH 1/3] usb: host: remove ehci-msm.c

No Qualcomm SoC requires the "ehci-msm.c" code any more. So remove it. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross --- drivers/usb/host/Makefile | 1 - drivers/usb/host/ehci-msm.c | 265

Re: [fstests PATCH v3] generic: add test for DAX MAP_SYNC support

On Wed, Oct 25, 2017 at 02:47:04PM -0600, Ross Zwisler wrote: > Add a test that exercises DAX's new MAP_SYNC flag. > > This test creates a file and writes to it via an mmap(), but never syncs > via fsync/msync. This process is tracked via dm-log-writes, then replayed. > > If MAP_SYNC is working

Re: [fstests PATCH v3] generic: add test for DAX MAP_SYNC support

On Wed, Oct 25, 2017 at 02:47:04PM -0600, Ross Zwisler wrote: > Add a test that exercises DAX's new MAP_SYNC flag. > > This test creates a file and writes to it via an mmap(), but never syncs > via fsync/msync. This process is tracked via dm-log-writes, then replayed. > > If MAP_SYNC is working

Re: [PATCH 0/9] Assorted cleanups for staging/.../lustre/ldlm/ldlm_flock.c

On Tue, Oct 24 2017, James Simmons wrote: >> This file contains quite a bit of dead code and unused variables. >> This patch series cleans it up in various ways. >> It should change behaviour at all, just code >> readability/maintainabilty. >> >> I sent the back in July but got not response,

Re: [PATCH 0/9] Assorted cleanups for staging/.../lustre/ldlm/ldlm_flock.c

On Tue, Oct 24 2017, James Simmons wrote: >> This file contains quite a bit of dead code and unused variables. >> This patch series cleans it up in various ways. >> It should change behaviour at all, just code >> readability/maintainabilty. >> >> I sent the back in July but got not response,

Re: [PATCH] iommu/amd: remove unused variable flush_addr

On Sun, 22 Oct 2017 13:49:45 +0200 Colin King wrote: > From: Colin Ian King > > Variable flush_addr is being assigned but is never read; it > is redundant and can be removed. Cleans up the clang warning: > > drivers/iommu/amd_iommu.c:2388:2:

[PATCH 1/3] arm64: defconfig: remove CONFIG_USB_EHCI_MSM

No Qualcomm SoC requires the "ehci-msm.c" code any more. So remove the code, and remove the config option from the arm64 defconfig. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy

Re: [PATCH] cgroup: reorder flexible array members of struct cgroup_root

Hi Tejun, El Sat, Oct 21, 2017 at 08:32:53AM -0700 Tejun Heo ha dit: > Hello, Nick. > > On Fri, Oct 20, 2017 at 12:15:55AM -0700, Nick Desaulniers wrote: > > > This is silly tho. We know the the root group embedded there won't > > > have any ancestor_ids. > > > > Sure, but struct cgroup_root

Re: [PATCH] iommu/amd: remove unused variable flush_addr

On Sun, 22 Oct 2017 13:49:45 +0200 Colin King wrote: > From: Colin Ian King > > Variable flush_addr is being assigned but is never read; it > is redundant and can be removed. Cleans up the clang warning: > > drivers/iommu/amd_iommu.c:2388:2: warning: Value stored to 'flush_addr' > is never

[PATCH 1/3] arm64: defconfig: remove CONFIG_USB_EHCI_MSM

No Qualcomm SoC requires the "ehci-msm.c" code any more. So remove the code, and remove the config option from the arm64 defconfig. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross --- arch/arm64/configs/defconfig | 1 - 1 file changed, 1

Re: [PATCH] cgroup: reorder flexible array members of struct cgroup_root

Hi Tejun, El Sat, Oct 21, 2017 at 08:32:53AM -0700 Tejun Heo ha dit: > Hello, Nick. > > On Fri, Oct 20, 2017 at 12:15:55AM -0700, Nick Desaulniers wrote: > > > This is silly tho. We know the the root group embedded there won't > > > have any ancestor_ids. > > > > Sure, but struct cgroup_root

[PATCH 3/3] arm64: defconfig: remove CONFIG_USB_QCOM_8X16_PHY

No Qualcomm SoC requires the "phy-qcom-8x16-usb.c" USB phy driver support any more. Remove the code, and remove the config option from the arm64 defconfig. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson

[PATCH 3/3] arm64: defconfig: remove CONFIG_USB_QCOM_8X16_PHY

No Qualcomm SoC requires the "phy-qcom-8x16-usb.c" USB phy driver support any more. Remove the code, and remove the config option from the arm64 defconfig. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross --- arch/arm64/configs/defconfig |

[PATCH 2/3] arm64: defconfig: remove CONFIG_USB_MSM_OTG

No Qualcomm SoC requires the "phy-msm-usb.c" USB phy driver support any more. Remove the code, and remove the config option from the arm64 defconfig. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson

[PATCH 2/3] arm64: defconfig: remove CONFIG_USB_MSM_OTG

No Qualcomm SoC requires the "phy-msm-usb.c" USB phy driver support any more. Remove the code, and remove the config option from the arm64 defconfig. Suggested-by: Stephen Boyd Signed-off-by: Alex Elder Acked-by: Bjorn Andersson Acked-by: Andy Gross --- arch/arm64/configs/defconfig | 1 - 1

[PATCH 0/3] arm64: defconfig: remove some Qualcomm USB options

This series deletes three config options related to USB on Qualcomm SoCs from the arm64 "defconfig". The code enabled by the options is no longer needed by any Qualcomm hardware. -Alex Alex Elder (3): arm64: defconfig: remove CONFIG_USB_EHCI_MSM

[PATCH 0/3] arm64: defconfig: remove some Qualcomm USB options

This series deletes three config options related to USB on Qualcomm SoCs from the arm64 "defconfig". The code enabled by the options is no longer needed by any Qualcomm hardware. -Alex Alex Elder (3): arm64: defconfig: remove CONFIG_USB_EHCI_MSM

Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another

Hi, On Wed, Oct 25, 2017 at 02:28:07PM -0700, Tony Lindgren wrote: > Also try booting with mem=512M@0x8000 or 256M or 768M. Maybe the > memory is different size or partially broken? Yeah, some early N950s may have only 512 MB. A.

Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another

Hi, On Wed, Oct 25, 2017 at 02:28:07PM -0700, Tony Lindgren wrote: > Also try booting with mem=512M@0x8000 or 256M or 768M. Maybe the > memory is different size or partially broken? Yeah, some early N950s may have only 512 MB. A.

Re: [PATCH] PCI: rework error checking in the reset path

On 10/25/2017 5:28 PM, Alex Williamson wrote: >> Previously, we only tried the next reset method if one method failed >> with -ENOTTY. With this patch, we'll try the next reset method if one >> method fails for any reason, not just -ENOTTY. > Hmm, I thought the return codes were pretty

Re: [PATCH] PCI: rework error checking in the reset path

On 10/25/2017 5:28 PM, Alex Williamson wrote: >> Previously, we only tried the next reset method if one method failed >> with -ENOTTY. With this patch, we'll try the next reset method if one >> method fails for any reason, not just -ENOTTY. > Hmm, I thought the return codes were pretty

Re: Sluggish AT91 I2C driver causes SMBus timeouts

Hi Ludovic, On 2017-10-17 09:58, Ludovic Desroches wrote: > Hi Peter, > > On Fri, Oct 13, 2017 at 05:01:04PM +0200, Peter Rosin wrote: >> On 2017-10-13 15:29, Alan Cox wrote: >>> On Thu, 12 Oct 2017 13:35:17 +0200 >>> Peter Rosin wrote: >>> Hi! I have encountered

Re: Sluggish AT91 I2C driver causes SMBus timeouts

Hi Ludovic, On 2017-10-17 09:58, Ludovic Desroches wrote: > Hi Peter, > > On Fri, Oct 13, 2017 at 05:01:04PM +0200, Peter Rosin wrote: >> On 2017-10-13 15:29, Alan Cox wrote: >>> On Thu, 12 Oct 2017 13:35:17 +0200 >>> Peter Rosin wrote: >>> Hi! I have encountered an "interesting"

Re: [PATCH v10] vfio: platform: reset: Add Broadcom FlexRM reset module

On Wed, 25 Oct 2017 11:19:21 +0530 Anup Patel wrote: > On Tue, Oct 3, 2017 at 10:57 AM, Anup Patel wrote: > > This patch adds Broadcom FlexRM low-level reset for > > VFIO platform. > > > > It will do the following: > > 1. Disable/Deactivate each

Re: [PATCH v10] vfio: platform: reset: Add Broadcom FlexRM reset module

On Wed, 25 Oct 2017 11:19:21 +0530 Anup Patel wrote: > On Tue, Oct 3, 2017 at 10:57 AM, Anup Patel wrote: > > This patch adds Broadcom FlexRM low-level reset for > > VFIO platform. > > > > It will do the following: > > 1. Disable/Deactivate each FlexRM ring > > 2. Flush each FlexRM ring > > > >

Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another

* Pavel Machek [171025 13:36]: > Hi! > > ...hardware should be identical. 3.5.3-nemo kernel seems to work on > both. 4.13-rc2 with display and clock patches boots on phone "S", but > does not on phone "P"; nothing nothing is received on serial port. > > There is some difference in

Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another

* Pavel Machek [171025 13:36]: > Hi! > > ...hardware should be identical. 3.5.3-nemo kernel seems to work on > both. 4.13-rc2 with display and clock patches boots on phone "S", but > does not on phone "P"; nothing nothing is received on serial port. > > There is some difference in the

Re: [PATCH] PCI: rework error checking in the reset path

On Wed, 25 Oct 2017 08:45:11 -0500 Bjorn Helgaas wrote: > [+cc Alex] > > On Mon, Oct 23, 2017 at 05:36:48PM -0400, Sinan Kaya wrote: > > The return codes from various reset types are not consistent. The code is > > assuming that all reset types will return -ENOTTY when

Re: [PATCH] PCI: rework error checking in the reset path

On Wed, 25 Oct 2017 08:45:11 -0500 Bjorn Helgaas wrote: > [+cc Alex] > > On Mon, Oct 23, 2017 at 05:36:48PM -0400, Sinan Kaya wrote: > > The return codes from various reset types are not consistent. The code is > > assuming that all reset types will return -ENOTTY when things go wrong. > >

Re: [PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

On 10/06/2017 03:30 PM, Shuah Khan wrote: > This patch series fixes inefficiencies and lock contention in the request > firmware paths. > > Shuah Khan (2): > media: s5p-mfc: check for firmware allocation before requesting > firmware > media: s5p-mfc: fix lock confection -

Re: [PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

On 10/06/2017 03:30 PM, Shuah Khan wrote: > This patch series fixes inefficiencies and lock contention in the request > firmware paths. > > Shuah Khan (2): > media: s5p-mfc: check for firmware allocation before requesting > firmware > media: s5p-mfc: fix lock confection -

Re: [prefix=PATCH] drivers: pmbus: core: Prevent calling pmbus_set_page with negative page

On 10/25/2017 04:12 PM, Guenter Roeck wrote: On Wed, Oct 25, 2017 at 02:52:53PM -0500, Eddie James wrote: From: "Edward A. James" For devices with word data registers, the pmbus core may call read/write word data functions with a page value of -1, in order to perform the

Re: [prefix=PATCH] drivers: pmbus: core: Prevent calling pmbus_set_page with negative page

On 10/25/2017 04:12 PM, Guenter Roeck wrote: On Wed, Oct 25, 2017 at 02:52:53PM -0500, Eddie James wrote: From: "Edward A. James" For devices with word data registers, the pmbus core may call read/write word data functions with a page value of -1, in order to perform the operation without

Re: [PATCH] Audit: remove unused audit_log_secctx function

On Tue, Oct 24, 2017 at 9:52 PM, Casey Schaufler wrote: > The function audit_log_secctx() is unused in the upstream kernel. > All it does is wrap another function that doesn't need wrapping. > It claims to give you the SELinux context, but that is not true if > you are

Re: [PATCH] Audit: remove unused audit_log_secctx function

On Tue, Oct 24, 2017 at 9:52 PM, Casey Schaufler wrote: > The function audit_log_secctx() is unused in the upstream kernel. > All it does is wrap another function that doesn't need wrapping. > It claims to give you the SELinux context, but that is not true if > you are using a different security

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On Wed, Oct 25, 2017 at 09:00:57PM +0200, Michal Hocko wrote: > On Wed 25-10-17 14:11:06, Johannes Weiner wrote: > > "Safe" is a vague term, and it doesn't make much sense to me in this > > situation. The OOM behavior should be predictable and consistent. > > > > Yes, global might in the rarest

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On Wed, Oct 25, 2017 at 09:00:57PM +0200, Michal Hocko wrote: > On Wed 25-10-17 14:11:06, Johannes Weiner wrote: > > "Safe" is a vague term, and it doesn't make much sense to me in this > > situation. The OOM behavior should be predictable and consistent. > > > > Yes, global might in the rarest

Re: [prefix=PATCH] drivers: pmbus: core: Prevent calling pmbus_set_page with negative page

On Wed, Oct 25, 2017 at 02:52:53PM -0500, Eddie James wrote: > From: "Edward A. James" > > For devices with word data registers, the pmbus core may call read/write > word data functions with a page value of -1, in order to perform the > operation without setting the page.

Re: [prefix=PATCH] drivers: pmbus: core: Prevent calling pmbus_set_page with negative page

On Wed, Oct 25, 2017 at 02:52:53PM -0500, Eddie James wrote: > From: "Edward A. James" > > For devices with word data registers, the pmbus core may call read/write > word data functions with a page value of -1, in order to perform the > operation without setting the page. However, the read/write

Re: [PATCH v6 03/12] arm64: dts: mt8173: remove "mediatek,mt8135-mmc" from mmc nodes

On 16 October 2017 at 03:46, Chaotian Jing wrote: > devicetree bindings has been updated to support multi-platforms, > so that each platform has its owns compatible name. > And, this compatible name may used in driver to distinguish with > other platform. > >

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

On Wed, Oct 25, 2017 at 4:16 PM, Bjorn Helgaas wrote: > On Wed, Oct 25, 2017 at 11:40:47AM -0700, Scott Branden wrote: >> Hi Bjorn, >> >> >> On 17-10-25 10:23 AM, Bjorn Helgaas wrote: >> >[+cc Ray, Scott, Jon] >> > >> >On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan

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