Re: [PATCH v3 0/9] RISC-V SBI debug console extension support

Hello: This series was applied to riscv/linux.git (fixes) by Anup Patel : On Fri, 20 Oct 2023 12:51:31 +0530 you wrote: > The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines > SBI debug console (DBCN) extension which replaces the legacy SBI v0.1 > functions

Re: [PATCH v3 0/9] RISC-V SBI debug console extension support

On Fri, Oct 20, 2023 at 12:51 PM Anup Patel wrote: > > The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines > SBI debug console (DBCN) extension which replaces the legacy SBI v0.1 > functions sbi_console_putchar() and sbi_console_getchar(). > (Refer v2.0-rc5 at

[PATCH v3 0/9] RISC-V SBI debug console extension support

The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines SBI debug console (DBCN) extension which replaces the legacy SBI v0.1 functions sbi_console_putchar() and sbi_console_getchar(). (Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases) This series

Re: [PATCH v3 0/9] video: screen_info cleanups

On Tue, Oct 10, 2023 at 01:48:07PM +0200, Daniel Vetter wrote: > On Mon, Oct 09, 2023 at 11:18:36PM +0200, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > v3 changelog > > > > No real changes, just rebased for context changes, and picked up the Acks. > > > > This now conflicts with the

Re: [PATCH v3 0/9] video: screen_info cleanups

On Mon, Oct 09, 2023 at 11:18:36PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > v3 changelog > > No real changes, just rebased for context changes, and picked up the Acks. > > This now conflicts with the ia64 removal and introduces one new dependency > on IA64, but that is harmless

[PATCH v3 0/9] video: screen_info cleanups

From: Arnd Bergmann v3 changelog No real changes, just rebased for context changes, and picked up the Acks. This now conflicts with the ia64 removal and introduces one new dependency on IA64, but that is harmless and trivial to deal with later. Link:

[RFC PATCH v3 0/9] Add audio support in v4l2 framework

Audio signal processing also has the requirement for memory to memory similar as Video. This asrc memory to memory (memory ->asrc->memory) case is a non real time use case. User fills the input buffer to the asrc module, after conversion, then asrc sends back the output buffer to user. So it is

Re: [PATCH v3 0/9] Cleanup/Optimise KUAP (v3)

On Tue, 11 Jul 2023 17:59:12 +0200, Christophe Leroy wrote: > This series is cleaning up a bit KUAP in preparation of using objtool > to validate UACCESS. > > There are two main changes in this series: > > 1/ Simplification of KUAP on book3s/32 > > [...] Applied to powerpc/next. [1/9]

[PATCH v3 0/9] Cleanup/Optimise KUAP (v3)

This series is cleaning up a bit KUAP in preparation of using objtool to validate UACCESS. There are two main changes in this series: 1/ Simplification of KUAP on book3s/32 2/ Using ASM features on 32 bits and booke as suggested by Nic. Those changes will be required for objtool UACCESS

Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support

Le 05/07/2023 à 05:04, Zhang, Rui a écrit : Hi, Laurent, I want to test this patch set and found that it does not apply on top of latest usptream git, because of some changes in this merge window, so better rebase. Hi Rui, Thanks for your interest for this series. The latest Thomas's changes

Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support

Hi, Laurent, I want to test this patch set and found that it does not apply on top of latest usptream git, because of some changes in this merge window, so better rebase. thanks, rui On Thu, 2023-06-29 at 16:31 +0200, Laurent Dufour wrote: > I'm taking over the series Michael sent previously

Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support

Le 30/06/2023 à 15:32, Sachin Sant a écrit : On 29-Jun-2023, at 8:01 PM, Laurent Dufour wrote: I'm taking over the series Michael sent previously [1] which is smartly reviewing the initial series I sent [2]. This series is addressing the comments sent by Thomas and me on the Michael's

Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support

> On 29-Jun-2023, at 8:01 PM, Laurent Dufour wrote: > > I'm taking over the series Michael sent previously [1] which is smartly > reviewing the initial series I sent [2]. This series is addressing the > comments sent by Thomas and me on the Michael's one. > > Here is a short introduction to

[PATCH v3 0/9] Introduce SMT level and add PowerPC support

I'm taking over the series Michael sent previously [1] which is smartly reviewing the initial series I sent [2]. This series is addressing the comments sent by Thomas and me on the Michael's one. Here is a short introduction to the issue this series is addressing: When a new CPU is added, the

Re: [PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

Ping. Gentle reminder On 11/5/22 1:20 AM, Zhuo Chen wrote: Hi Bjorn, a gentle reminder. Thanks and regards. On 9/28/22 6:59 PM, Zhuo Chen wrote: Hello. Here comes patch v3, which contains some fixes and optimizations of aer api usage. The v1 and v2 can be found on the mailing list. v3:

Re: [PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

Hi Bjorn, a gentle reminder. Thanks and regards. On 9/28/22 6:59 PM, Zhuo Chen wrote: Hello. Here comes patch v3, which contains some fixes and optimizations of aer api usage. The v1 and v2 can be found on the mailing list. v3: - Modifications to comments proposed by Sathyanarayanan. Remove

Re: [External] Re: [PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

On 9/28/22 7:06 PM, Serge Semin wrote: On Wed, Sep 28, 2022 at 06:59:37PM +0800, Zhuo Chen wrote: Hello. Here comes patch v3, which contains some fixes and optimizations of aer api usage. The v1 and v2 can be found on the mailing list. v3: - Modifications to comments proposed by

Re: [PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

On Wed, Sep 28, 2022 at 06:59:37PM +0800, Zhuo Chen wrote: > Hello. > > Here comes patch v3, which contains some fixes and optimizations of > aer api usage. The v1 and v2 can be found on the mailing list. > > v3: > - Modifications to comments proposed by Sathyanarayanan. > Remove >

[PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

Hello. Here comes patch v3, which contains some fixes and optimizations of aer api usage. The v1 and v2 can be found on the mailing list. v3: - Modifications to comments proposed by Sathyanarayanan. Remove pci_aer_clear_nonfatal_status() call in NTB and improve commit log. v2: -

[PATCH v3 0/9] sections: Unify kernel sections range check and use

There are three head files(kallsyms.h, kernel.h and sections.h) which include the kernel sections range check, let's make some cleanup and unify them. 1. cleanup arch specific text/data check and fix address boundary check in kallsyms.h 2. make all the basic/core kernel range check function

Re: [PATCH v3 0/9] powerpc: fast interrupt exit bug and misc fixes

On Wed, 30 Jun 2021 17:46:12 +1000, Nicholas Piggin wrote: > This is a bunch of fixes for powerpc next, mostly a nasty hole in fast > interrupt exit code found by Sachin and some other bits along the way > while looking at it. > > Since v2: > - Fixed 64e patch 3 to really set

[PATCH v3 0/9] powerpc: fast interrupt exit bug and misc fixes

This is a bunch of fixes for powerpc next, mostly a nasty hole in fast interrupt exit code found by Sachin and some other bits along the way while looking at it. Since v2: - Fixed 64e patch 3 to really set exit_must_hard_disable. - Reworded some changelogs. Since v1: - Fixed a bisection compile

[PATCH v3 0/9] Remove DISCONTIGMEM memory model

From: Mike Rapoport Hi, SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a (long) while ago. The last architectures that used DISCONTIGMEM were updated to use other memory models in v5.11 and it is about the time to entirely remove DISCONTIGMEM from the kernel. This set

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

On Wed, 31 Mar 2021 16:45:05 +0200, Cédric Le Goater wrote: > ipistorm [*] can be used to benchmark the raw interrupt rate of an > interrupt controller by measuring the number of IPIs a system can > sustain. When applied to the XIVE interrupt controller of POWER9 and > POWER10 systems, a

Re: [PATCH v3 0/9] Speedup mremap on ppc64

"Aneesh Kumar K.V" writes: > This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires > the platform to support updating higher-level page tables without > updating page table entries. This also needs to invalidate the Page Walk > Cache on architecture supporting the same. > >

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

On 4/1/21 2:45 PM, Greg Kurz wrote: > On Thu, 1 Apr 2021 11:18:10 +0200 > Cédric Le Goater wrote: > >> Hello, >> >> On 4/1/21 10:04 AM, Greg Kurz wrote: >>> On Wed, 31 Mar 2021 16:45:05 +0200 >>> Cédric Le Goater wrote: >>> Hello, ipistorm [*] can be used to benchmark the

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

On Thu, 1 Apr 2021 11:18:10 +0200 Cédric Le Goater wrote: > Hello, > > On 4/1/21 10:04 AM, Greg Kurz wrote: > > On Wed, 31 Mar 2021 16:45:05 +0200 > > Cédric Le Goater wrote: > > > >> > >> Hello, > >> > >> ipistorm [*] can be used to benchmark the raw interrupt rate of an > >> interrupt

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

Hello, On 4/1/21 10:04 AM, Greg Kurz wrote: > On Wed, 31 Mar 2021 16:45:05 +0200 > Cédric Le Goater wrote: > >> >> Hello, >> >> ipistorm [*] can be used to benchmark the raw interrupt rate of an >> interrupt controller by measuring the number of IPIs a system can >> sustain. When applied to the

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

Hello, On 3/31/21 4:45 PM, Cédric Le Goater wrote: > > Hello, > > ipistorm [*] can be used to benchmark the raw interrupt rate of an > interrupt controller by measuring the number of IPIs a system can > sustain. When applied to the XIVE interrupt controller of POWER9 and > POWER10 systems, a

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

On Wed, 31 Mar 2021 16:45:05 +0200 Cédric Le Goater wrote: > > Hello, > > ipistorm [*] can be used to benchmark the raw interrupt rate of an > interrupt controller by measuring the number of IPIs a system can > sustain. When applied to the XIVE interrupt controller of POWER9 and > POWER10

[PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

Hello, ipistorm [*] can be used to benchmark the raw interrupt rate of an interrupt controller by measuring the number of IPIs a system can sustain. When applied to the XIVE interrupt controller of POWER9 and POWER10 systems, a significant drop of the interrupt rate can be observed when

[PATCH v3 0/9] Speedup mremap on ppc64

This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires the platform to support updating higher-level page tables without updating page table entries. This also needs to invalidate the Page Walk Cache on architecture supporting the same. Changes from v2: * switch from using

[PATCH v3 0/9] powerpc/watchpoint: Enable 2nd DAWR on baremetal and powervm

Last series[1] was to add basic infrastructure support for more than one watchpoint on Book3S powerpc. This series actually enables the 2nd DAWR for baremetal and powervm. Kvm guest is still not supported. v2:

Re: [PATCH v3 0/9] crypto/nx: Enable GZIP engine and provide userpace API

On Tue, 2020-03-17 at 00:04 +1100, Daniel Axtens wrote: > Hi Haren, > > If I understand correctly, to test these, I need to apply both this > series and your VAS userspace page fault handling series - is that > right? Daniel, Yes, This patch series enables GZIP engine and provides user space

Re: [PATCH v3 0/9] crypto/nx: Enable GZIP engine and provide userpace API

Hi Haren, If I understand correctly, to test these, I need to apply both this series and your VAS userspace page fault handling series - is that right? Kind regards, Daniel > Power9 processor supports Virtual Accelerator Switchboard (VAS) which > allows kernel and userspace to send compression

[PATCH v3 0/9] crypto/nx: Enable GZIP engine and provide userpace API

Power9 processor supports Virtual Accelerator Switchboard (VAS) which allows kernel and userspace to send compression requests to Nest Accelerator (NX) directly. The NX unit comprises of 2 842 compression engines and 1 GZIP engine. Linux kernel already has 842 compression support on kernel. This

[PATCH v3 0/9]

Hi all, Here is v3, addressing feedback from v2 to do with debug logging. It includes a new patch from Oliver O'Halloran (patch 7) and two additional patches based on it. See those patches for details. Cover letter: This patch set adds support for EEH recovery of hot plugged devices on pSeries

[PATCH v3 0/9] Provide vcpu dispatch statistics

Changes since v2: - Moved most prototypes to asm/lppaca.h instead of asm/plpar_wrappers.h - Patch 4/9 changed to use rwlocks for guarding DTL buffer usage across debugfs and the new vcpudispatch_stats. - Patch 6/9 has been updated to address breakage of the vphn selftest under

[PATCH v3 0/9] kvmppc: Paravirtualize KVM to support ultravisor

POWER platforms that supports the Protected Execution Facility (PEF) introduce features that combine hardware facilities and firmware to enable secure virtual machines. That includes a new processor mode (ultravisor mode) and the ultravisor firmware. In PEF enabled systems, the ultravisor

[PATCH v3 0/9] Devicetree build consolidation

This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the

[PATCH v3 0/9] powerpc: Modernize unhandled signals message

Hi, everyone. This series was inspired by the need to modernize and display more informative messages about unhandled signals. The "unhandled signal NN" is not very informative. We thought it would be helpful adding a human-readable message describing what the signal number means, printing the

[PATCH v3 0/9] powerpc/pkeys: fixes to pkeys

Assortment of fixes to pkey to match its behavior to that on x86. Patch 1 makes pkey consumable in multithreaded applications. Patch 2 Deny, by default, permissions on all unallocated keys. Patch 3 pkey allocation/free must not change pkey registers. Patch 4 fixes fork to inherit the key

Re: [PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

Tyrel Datwyler writes: > On 12/03/2017 09:13 PM, Michael Ellerman wrote: >> Nathan Fontenot writes: >> >>> This patch set provides a series of updates to de-couple the LMB >>> information provided in the device tree property from the device

Re: [PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

On 02/14/2018 03:30 PM, Tyrel Datwyler wrote: > On 12/03/2017 09:13 PM, Michael Ellerman wrote: >> Nathan Fontenot writes: >> >>> This patch set provides a series of updates to de-couple the LMB >>> information provided in the device tree property from the device >>>

Re: [PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

On 12/03/2017 09:13 PM, Michael Ellerman wrote: > Nathan Fontenot writes: > >> This patch set provides a series of updates to de-couple the LMB >> information provided in the device tree property from the device >> tree property format. This eases the ability to support

Re: [PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

Nathan Fontenot writes: > This patch set provides a series of updates to de-couple the LMB > information provided in the device tree property from the device > tree property format. This eases the ability to support a new > format for the dynamic memory property,

[PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

This patch set provides a series of updates to de-couple the LMB information provided in the device tree property from the device tree property format. This eases the ability to support a new format for the dynamic memory property, ibm,dynamic-memory-v2. This series of patches consolidates the

Re: [PATCH V3 0/9] cpufreq: transition-latency cleanups

On Wednesday, July 19, 2017 03:42:40 PM Viresh Kumar wrote: > Hi Rafael, > > This series tries to cleanup the code around transition-latency and its > users. Some of the old legacy code, which may not make much sense now, > is dropped as well. And some code consolidation is also done across >

[PATCH V3 0/9] cpufreq: transition-latency cleanups

Hi Rafael, This series tries to cleanup the code around transition-latency and its users. Some of the old legacy code, which may not make much sense now, is dropped as well. And some code consolidation is also done across governors. Based of: v4.13-rc1 Tested on: ARM64 Hikey board. I have

[PATCH v3 0/9] Enable STRICT_KERNEL_RWX

Enable STRICT_KERNEL_RWX for PPC64/BOOK3S These patches enable RX mappings of kernel text. rodata is mapped RX as well as a trade-off, there are more details in the patch description As a prerequisite for R/O text, patch_instruction is moved over to using a separate mapping that allows write to

[PATCH v3 0/9] ima: carry the measurement list across kexec

The TPM PCRs are only reset on a hard reboot. In order to validate a TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list of the running kernel must be saved and then restored on the subsequent boot, possibly of a different architecture. The existing securityfs

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

Am Freitag, 24 Juni 2016, 08:33:24 schrieb Balbir Singh: > On 24/06/16 02:44, Thiago Jung Bauermann wrote: > > Sorry, I still don't understand your concern. What kind of cheating? > > Which values? If it's the values in the event log, there's no need to > > trust the old kernel. The new kernel

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

On 24/06/16 02:44, Thiago Jung Bauermann wrote: > Am Donnerstag, 23 Juni 2016, 09:57:51 schrieb Balbir Singh: >> On 23/06/16 03:02, Thiago Jung Bauermann wrote: > 3. have IMA pass-on its event log (where integrity measurements are > >registered) accross kexec to the second

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

Am Donnerstag, 23 Juni 2016, 09:57:51 schrieb Balbir Singh: > On 23/06/16 03:02, Thiago Jung Bauermann wrote: > >>> 3. have IMA pass-on its event log (where integrity measurements are > >>> > >>>registered) accross kexec to the second kernel, so that the event > >>>history is preserved. >

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

On 23/06/16 03:02, Thiago Jung Bauermann wrote: > Hello Balbir, > Hi Thiago >>> 3. have IMA pass-on its event log (where integrity measurements are >>> >>>registered) accross kexec to the second kernel, so that the event >>>history is preserved. >> >> OK.. and this is safe? Do both the

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

Hello Balbir, Am Mittwoch, 22 Juni 2016, 23:29:46 schrieb Balbir Singh: > On Tue, 21 Jun 2016 16:48:32 -0300 > Thiago Jung Bauermann wrote: > > This patch series implements the kexec_file_load system call on > > PowerPC. > > > > This system call moves the reading of

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

On Tue, 21 Jun 2016 16:48:32 -0300 Thiago Jung Bauermann wrote: > Hello, > > This patch series implements the kexec_file_load system call on > PowerPC. > > This system call moves the reading of the kernel, initrd and the > device tree from the userspace kexec tool

[PATCH v3 0/9] kexec_file_load implementation for PowerPC

Hello, This patch series implements the kexec_file_load system call on PowerPC. This system call moves the reading of the kernel, initrd and the device tree from the userspace kexec tool to the kernel. This is needed if you want to do one or both of the following: 1. only allow loading of

[PATCH v3 0/9] powerpc/powernv/cpuidle: Add support for POWER ISA v3 idle states

POWER ISA v3 defines a new idle processor core mechanism. In summary, a) new instruction named stop is added. This instruction replaces instructions like nap, sleep, rvwinkle. b) new per thread SPR named PSSCR is added which controls the behavior of stop instruction.

[PATCH v3 0/9] FP/VEC/VSX switching optimisations

Cover-letter for V1 of the series is at https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-November/136350.html Cover-letter for V2 of the series is at https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138054.html Changes in V3: Addressed review comments from Michael Neuling - Made

[PATCH v3 0/9] KVM: PPC: Book3S HV: Optimize wakeup VCPU from H_IPI

When the VCPU target of an H_IPI hypercall is not running in the guest, we need to do a kick VCPU (wake the VCPU thread) to make it runnable. The real-mode version of the H_IPI hypercall cannot do this because it involves waking a sleeping thread. Thus the hcall returns H_TOO_HARD which forces a

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

From: Florian Fainelli Date: Thu, 24 Sep 2015 18:39:56 -0700 > On 24/09/15 12:17, Russell King - ARM Linux wrote: >> Hi, >> >> The third version of this series fixes the build error which David >> identified, and drops the broken changes for the Cavium Thunger BGX >>

[PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

Hi, The third version of this series fixes the build error which David identified, and drops the broken changes for the Cavium Thunger BGX ethernet driver as this driver requires some complex changes to resolve the leakage - and this is best done by people who can test the driver. Compared to

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

> Thanks for testing. Please could you confirm whether the same behaviour > is observed without the patches, just to make absolutely sure that isn't > a regression. So i tested this now. I have two FEC interfaces. One i my main access interface, and the second is used by DSA to access switches.

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

On Thu, Sep 24, 2015 at 03:51:37PM -0700, David Miller wrote: > From: Andrew Lunn > Date: Fri, 25 Sep 2015 00:26:54 +0200 > > > On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote: > >> From: Andrew Lunn > >> Date: Thu, 24 Sep 2015 23:57:31 +0200 > >> >

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

... > While looking at the DSA code, I noticed we have a > of_find_net_device_by_node(), and it looks like users of that are > similarly buggy - it looks like net/dsa/dsa.c is the only user. Fix > that too. ... > The mdiobus code also suffered from the same kind of leak, but thankfully > this

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

From: Andrew Lunn Date: Thu, 24 Sep 2015 23:57:31 +0200 > I built the FEC driver as a module, and it won't unload: > > kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1 > unregister_netdevice: waiting for eth1 to become free. Usage count = 1 > > i

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote: > From: Andrew Lunn > Date: Thu, 24 Sep 2015 23:57:31 +0200 > > > I built the FEC driver as a module, and it won't unload: > > > > kernel:unregister_netdevice: waiting for eth1 to become free. Usage count > > = 1 >

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

On Fri, Sep 25, 2015 at 12:50:33AM +0200, Andrew Lunn wrote: > > Thanks for testing. Please could you confirm whether the same behaviour > > is observed without the patches, just to make absolutely sure that isn't > > a regression. > > So i tested this now. > > I have two FEC interfaces. One i

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

On 24/09/15 12:17, Russell King - ARM Linux wrote: > Hi, > > The third version of this series fixes the build error which David > identified, and drops the broken changes for the Cavium Thunger BGX > ethernet driver as this driver requires some complex changes to > resolve the leakage - and this

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

On Thu, Sep 24, 2015 at 11:57:31PM +0200, Andrew Lunn wrote: > Hi Russell > > I tested both of these with my board. It is a Freescale Vybrid, using > the FEC ethernet driver, and i have three switches attached, using > mdio-mux to give three mdio busses. > > No obvious regressions, my board

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

From: Andrew Lunn Date: Fri, 25 Sep 2015 00:26:54 +0200 > On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote: >> From: Andrew Lunn >> Date: Thu, 24 Sep 2015 23:57:31 +0200 >> >> > I built the FEC driver as a module, and it won't unload: >> > >> >

Re: [Xen-devel] [PATCH v3 0/9] Use correctly the Xen memory terminologies

On 07/08/15 17:34, Julien Grall wrote: Hi all, This patch series aims to use the memory terminologies described in include/xen/mm.h [1] for Linux xen code. Applied to for-linus-4.3, thanks. David ___ Linuxppc-dev mailing list

[PATCH v3 0/9] Use correctly the Xen memory terminologies

Hi all, This patch series aims to use the memory terminologies described in include/xen/mm.h [1] for Linux xen code. The differences from v2 is minor but I resent it because my 64K series depends on this series. Linux is using mistakenly MFN when GFN is meant, I suspect this is because the

[PATCH V3 0/9] VF EEH on Power8

This patchset enables EEH on SRIOV VFs. The general idea is to create proper VF edev and VF PE and handle them properly. Different from the Bus PE, VF PE just contain one VF. This introduces the difference of EEH error handling on a VF PE. Generally, it has several differences. First, the VF's

[PATCH v3 0/9] powerpc: kill PPC_OF

Hi Michael, Finally I got all the acks for these patches. The following two patches in v2 were merged into next now. 213dce3c17a6 (tty: kconfig: remove the superfluous dependency on PPC_OF) f4e074f20cad (mmc: kconfig: replace PPC_OF with PPC) So we may have dependency issue if

[PATCH v3 0/9] Fixes for common mistakes w/ for_each_process and task-mm

Hi all, This is another resend of several task-mm fixes, the bugs I found during LMK code audit. Architectures were traverse the tasklist in an unsafe manner, plus there are a few cases of unsafe access to task-mm in general. There were no objections on the previous resend, and the final words

Re: [PATCH v3 0/9] fsldma: lockup fixes

Hi Ira, I've successfully tested this version on P2020RDB, with 10 threads per channel, 10 iterations per thread. Tested-by: Felix Radensky fe...@embedded-sol.com Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

[PATCH v3 0/9] fsldma: lockup fixes

Hello everyone, I've been chasing random infrequent controller lockups in the fsldma driver for a long time. I finally managed to find the problem and fix it. I'm not quite sure about the exact sequence of events which causes the race condition, but it is related to using the hardware registers

[PATCH v3 0/9] wireless: Use macros from wireless.h

Create a IW_HANDLER macro for iw_handler array entries in wireless.h Use the wireless.h macros in various wireless files Use starting index define SIOCIWFIRST where appropriate Remove local #defines of IW_IOCTL Remove STD_IW_HANDLER macro in orinoco, use IW_HANDLER instead Joe Perches (9):

[PATCH v3 0/9] Add MPC837x generic support and MPC837xE MDS support

The patch series has been re-built to apply on the latest Linus' HEAD after pulling Paul's for-2.6.24. All comments on list are addressed. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev