This patch series introduces wrapper functions for_each_child_of_node_scoped().
The for_each_child_of_node_scoped() helper provides a scope-based clean-up
functionality to put the device_node automatically, and as such, there is
no need to call of_node_put() directly.
Thus, use this helper to sim
* Shrikanth Hegde [2025-03-14 17:14:56]:
> This is an effort to make the code simpler by making use of lock
> guards which were introduced in [1], which works by using __cleanup
> attributes. More details in v1 cover letter
>
> This series aims mainly at simplifying code around mutex with goto
Hi Sven,
> Hector Martin (3):
> i2c: pasemi: Improve error recovery
> i2c: pasemi: Enable the unjam machine
> i2c: pasemi: Log bus reset causes
>
> Sven Peter (3):
> i2c: pasemi: Use correct bits.h include
> i2c: pasemi: Sort includes alphabetically
I applied in i2c
On Tue, Apr 15, 2025 at 11:37 AM Sven Peter via B4 Relay
wrote:
>
> Hi,
>
> This series adds a few fixes/improvements to the error recovery for
> Apple/PASemi i2c controllers.
> The patches have been in our downstream tree and were originally used
> to debug a rare glitch caused by clock strechtin
Hi,
This series adds a few fixes/improvements to the error recovery for
Apple/PASemi i2c controllers.
The patches have been in our downstream tree and were originally used
to debug a rare glitch caused by clock strechting but are useful in
general. We haven't seen the controller misbehave since ad
This is an effort to make the code simpler by making use of lock
guards which were introduced in [1], which works by using __cleanup
attributes. More details in v1 cover letter
This series aims mainly at simplifying code around mutex with goto
statements. If it makes sense, there are more code si
Commit 0ab97169aa05 ("crash_core: add generic function to do
reservation") added a generic function to reserve crashkernel memory.
So let's use the same function on powerpc and remove the
architecture-specific code that essentially does the same thing.
The generic crashkernel reservation also prov
Several APIs such as rtas_get_indices(), rtas_get_dynamic_sensor(),
rtas_set_dynamic_indicator() and rtas_platform_dump() provided by
librtas library are implemented in user space using rtas syscall
in combination with writable mappings of /dev/mem. But this
implementation is not compatible with sy
For some reason v1 didn't make it to linux-mm; let's see if the problem
persists.
Let's clean up the gfp flags handling, and support __GFP_ZERO, such that we
can finally remove the TODO in memtrace code.
I did some alloc_contig_*() testing with virtio-mem and hugetlb; I did not
test powernv/memtr
On 17/10/2024 10:55 pm, Josh Poimboeuf wrote:
> At least for now, continue to assume mask_user_address() is safe on AMD
> when combined with STAC/CLAC -- as get_user(), put_user() and
> masked_user_access_begin() already do today.
Honestly, I find this a very worrying position to take.
It's one t
At least for now, continue to assume mask_user_address() is safe on AMD
when combined with STAC/CLAC -- as get_user(), put_user() and
masked_user_access_begin() already do today.
v2:
- Separate copy_to_user() and clear_user() changes out into separate patches
- Add masking to __get_user() and __pu
This function is base on the accelerator implementation
for compress API:
https://patchwork.kernel.org/project/alsa-devel/patch/20240731083843.59911-1-pe...@perex.cz/
Audio signal processing also has the requirement for memory to
memory similar as Video.
This asrc memory to memory (memory ->asrc-
On Tue, 21 May 2024 18:40:07 -0700, Sean Christopherson wrote:
> Drop kvm_arch_sched_in() and instead add and use kvm_vcpu.scheduled_out
> to communicate to kvm_arch_vcpu_load() that the vCPU is being scheduling
> back in.
>
> While fiddling with an idea for optimizing state management on AMD CPUs
Replace or drop the legacy header that is subject to remove.
Not all of them were compile-tested, the series might have
hidden compilation errors.
In v3:
- moved aw88399 from the "Remove ..." patch to the "Replace ..." (LKP)
In v2:
- added tags (Kuninori, Charles)
- ripped out TAS2781 (it's a mes
Replace or drop the legacy header that is subject to remove.
Not all of them were compile-tested, the series might have
hidden compilation errors.
In v2:
- added tags (Kuninori, Charles)
- ripped out TAS2781 (it's a mess from GPIO handling perspective)
Andy Shevchenko (6):
ASoC: codecs: Remove
On 22/05/2024 1:40 pm, Sean Christopherson wrote:
Drop kvm_arch_sched_in() and instead add and use kvm_vcpu.scheduled_out
to communicate to kvm_arch_vcpu_load() that the vCPU is being scheduling
back in.
For this series,
Acked-by: Kai Huang
Drop kvm_arch_sched_in() and instead add and use kvm_vcpu.scheduled_out
to communicate to kvm_arch_vcpu_load() that the vCPU is being scheduling
back in.
While fiddling with an idea for optimizing state management on AMD CPUs,
I wanted to skip re-saving certain host state when a vCPU is scheduled
On 5/6/24 12:43 PM, Jason Gunthorpe wrote:
> On Sat, May 04, 2024 at 12:33:53AM +0530, Shivaprasad G Bhat wrote:
>> We have legacy workloads using VFIO in userspace/kvm guests running
>> on downstream distro kernels. We want these workloads to be able to
>> continue running on our arch.
>
> It has
Hi Jason,
On 5/6/24 23:13, Jason Gunthorpe wrote:
On Sat, May 04, 2024 at 12:33:53AM +0530, Shivaprasad G Bhat wrote:
We have legacy workloads using VFIO in userspace/kvm guests running
on downstream distro kernels. We want these workloads to be able to
continue running on our arch.
It has be
On Sat, May 04, 2024 at 12:33:53AM +0530, Shivaprasad G Bhat wrote:
> We have legacy workloads using VFIO in userspace/kvm guests running
> on downstream distro kernels. We want these workloads to be able to
> continue running on our arch.
It has been broken since 2018, I don't find this reasoning
On 5/2/24 06:59, Alexey Kardashevskiy wrote:
On 2/5/24 00:09, Jason Gunthorpe wrote:
On Tue, Apr 30, 2024 at 03:05:34PM -0500, Shivaprasad G Bhat wrote:
RFC v1 was posted here [1]. As I was testing more and fixing the
issues, I realized its clean to have the table_group_ops implemented
the wa
On 2/5/24 00:09, Jason Gunthorpe wrote:
On Tue, Apr 30, 2024 at 03:05:34PM -0500, Shivaprasad G Bhat wrote:
RFC v1 was posted here [1]. As I was testing more and fixing the
issues, I realized its clean to have the table_group_ops implemented
the way it is done on PowerNV and stop 'borrowing'
On Tue, Apr 30, 2024 at 03:05:34PM -0500, Shivaprasad G Bhat wrote:
> RFC v1 was posted here [1]. As I was testing more and fixing the
> issues, I realized its clean to have the table_group_ops implemented
> the way it is done on PowerNV and stop 'borrowing' the DMA windows
> for pSeries.
>
> This
RFC v1 was posted here [1]. As I was testing more and fixing the
issues, I realized its clean to have the table_group_ops implemented
the way it is done on PowerNV and stop 'borrowing' the DMA windows
for pSeries.
This patch-set implements the iommu table_group_ops for pSeries for
VFIO SPAPR TCE s
In function free_area_init_core(), the code calculating
zone->managed_pages and the subtracting dma_reserve from DMA zone looks
very confusing.
>From git history, the code calculating zone->managed_pages was for
zone->present_pages originally. The early rough assignment is for
optimize zone's pcp
Hi,
This series introduces the QMC HDLC support.
Patches were previously sent as part of a full feature series and were
previously reviewed in that context:
"Add support for QMC HDLC, framer infrastructure and PEF2256 framer" [1]
In order to ease the merge, the full feature series has been split
PowerVM systems configured in shared processors mode have some unique
challenges. Some device-tree properties will be missing on a shared
processor. Hence some sched domains may not make sense for shared processor
systems.
Most shared processor systems are over-provisioned. Underlying PowerVM
Hype
On a secure boot enabled PowerVM guest, local and third party code signing
keys are needed to verify signed applications, configuration files, and
kernel modules.
Loading these keys onto either the .secondary_trusted_keys or .ima
keyrings requires the certificates be signed by keys on the
.builtin
fig-cleanup-v2-iter1/-cover-letter.patch
2023-06-16 16:39:42.179877676 +0200
@@ -1,9 +1,33 @@
-From 0456ed568d98ba5bba8148e4f60d769e3c5a6c7a Mon Sep 17 00:00:00 2001
+From bcf4dfab5a64ee691eb5154b1361ed59610c9387 Mon Sep 17 00:00:00 2001
From: Petr Mladek
-Date: Fri, 16 Jun 2023 16:42:07 +0200
-Subject: [PATCH 0/6]
Hi,
this patchset is supposed to replace the last patch in the patchset cleaning
up after introducing the buddy detector, see
https://lore.kernel.org/r/20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@changeid
Changes against v1:
+ Better explained the C-like ordering in the 1st pat
On Wed, Jun 7, 2023 at 3:54 PM Nicholas Piggin wrote:
>
> On Mon Jun 5, 2023 at 4:48 PM AEST, Jordan Niethe wrote:
> > There is existing support for nested guests on powernv hosts however the
> > hcall interface this uses is not support by other PAPR hosts.
>
> I kind of liked it being called nest
On Mon Jun 5, 2023 at 4:48 PM AEST, Jordan Niethe wrote:
> There is existing support for nested guests on powernv hosts however the
> hcall interface this uses is not support by other PAPR hosts.
I kind of liked it being called nested-HV v1 and v2 APIs as short and
to the point, but I suppose that
There is existing support for nested guests on powernv hosts however the
hcall interface this uses is not support by other PAPR hosts. A set of
new hcalls will be added to PAPR to facilitate creating and managing
guests by a regular partition in the following way:
- L1 and L0 negotiate capabilit
This got a positive response so I'll post again. If anything ppc32 gets
complicated by all the ppc64 crud so if Christophe is okay with it then
it can't be too bad.
Thanks,
Nick
Since v1:
- Don't re-order 32-bit prologue.
- Improve Kconfig conditional includes.
- Break out code changes into their
This patch series fixes a number of issues with hotplugging
hvcs devices including memory leaks as well as, the inability
to reconnect to a console device after it has been hot added
back, since it was not getting cleaned up properly on the
hotplug remove path.
Changes since initial version:
- Cha
This patchset was originally published as a part of per-VMA locking [1] and
was split after suggestion that it's viable on its own and to facilitate
the review process. It is now a preprequisite for the next version of per-VMA
lock patchset, which reuses vm_flags modifier functions to lock the VMA
Le 26/09/2022 à 08:43, Benjamin Gray a écrit :
> Implementation of out-of-line static calls for PowerPC 64-bit ELF V2 ABI.
> Static calls patch an indirect branch into a direct branch at runtime.
> Out-of-line specifically has a caller directly call a trampoline, and
> the trampoline gets patched
Implementation of out-of-line static calls for PowerPC 64-bit ELF V2 ABI.
Static calls patch an indirect branch into a direct branch at runtime.
Out-of-line specifically has a caller directly call a trampoline, and
the trampoline gets patched to directly call the target.
Previous version here:
htt
On Wed, 18 May 2022 20:03:27 +1000, Paul Mackerras wrote:
> This patch series implements KASAN on 64-bit POWER with radix MMU,
> such as POWER9 or POWER10. Daniel Axtens posted previous versions of
> these patches, but is no longer working on KASAN, and I have been
> asked to get them ready for in
Le 18/05/2022 à 12:03, Paul Mackerras a écrit :
> This patch series implements KASAN on 64-bit POWER with radix MMU,
> such as POWER9 or POWER10. Daniel Axtens posted previous versions of
> these patches, but is no longer working on KASAN, and I have been
> asked to get them ready for inclusion.
This patch series implements KASAN on 64-bit POWER with radix MMU,
such as POWER9 or POWER10. Daniel Axtens posted previous versions of
these patches, but is no longer working on KASAN, and I have been
asked to get them ready for inclusion.
Because of various technical difficulties, mostly around
On Thu, Dec 16, 2021 at 10:44:20AM +0100, Alexandre Ghiti wrote:
> While bumping from 5.13 to 5.15, I found that a few deleted configs had
> left some pieces here and there: this patchset cleans that.
>
> Changes in v2:
> - Rebase on top of v5.16-rc1
> - Removed patch 6 since Matti said he would t
While bumping from 5.13 to 5.15, I found that a few deleted configs had
left some pieces here and there: this patchset cleans that.
Changes in v2:
- Rebase on top of v5.16-rc1
- Removed patch 6 since Matti said he would take care of that
- Added AB, RB
Alexandre Ghiti (6):
Documentation, arch:
Hello,
On Wed, Dec 08, 2021 at 08:50:54PM -0500, Nayna wrote:
>
> On 11/25/21 13:02, Michal Suchanek wrote:
> > Hello,
>
> Hi Michael,
>
> >
> > This is resend of the KEXEC_SIG patchset.
> >
> > The first patch is new because it'a a cleanup that does not require any
> > change to the module v
On 11/25/21 13:02, Michal Suchanek wrote:
Hello,
Hi Michael,
This is resend of the KEXEC_SIG patchset.
The first patch is new because it'a a cleanup that does not require any
change to the module verification code.
The second patch is the only one that is intended to change any
functiona
Hi Michal,
On Tue, 7 Dec 2021 18:32:21 +0100
Michal Suchánek wrote:
> On Tue, Dec 07, 2021 at 05:10:14PM +0100, Philipp Rudo wrote:
> > Hi Michal,
> >
> > i finally had the time to take a closer look at the series. Except for
> > the nit in patch 4 and my personal preference in patch 6 the code
On Tue, Dec 07, 2021 at 05:10:14PM +0100, Philipp Rudo wrote:
> Hi Michal,
>
> i finally had the time to take a closer look at the series. Except for
> the nit in patch 4 and my personal preference in patch 6 the code looks
> good to me.
>
> What I don't like are the commit messages on the first
Hi Michal,
i finally had the time to take a closer look at the series. Except for
the nit in patch 4 and my personal preference in patch 6 the code looks
good to me.
What I don't like are the commit messages on the first commits. In my
opinion they are so short that they are almost useless. For e
Hello,
On Wed, Dec 01, 2021 at 10:37:47AM +0800, Baoquan He wrote:
> Hi,
>
> On 11/25/21 at 07:02pm, Michal Suchanek wrote:
> > Hello,
> >
> > This is resend of the KEXEC_SIG patchset.
> >
> > The first patch is new because it'a a cleanup that does not require any
> > change to the module verif
Hi,
On 11/25/21 at 07:02pm, Michal Suchanek wrote:
> Hello,
>
> This is resend of the KEXEC_SIG patchset.
>
> The first patch is new because it'a a cleanup that does not require any
> change to the module verification code.
>
> The second patch is the only one that is intended to change any
> f
On Thu, Nov 25, 2021 at 07:02:38PM +0100, Michal Suchanek wrote:
> Hello,
>
> This is resend of the KEXEC_SIG patchset.
>
> The first patch is new because it'a a cleanup that does not require any
> change to the module verification code.
>
> The second patch is the only one that is intended to c
Hello,
This is resend of the KEXEC_SIG patchset.
The first patch is new because it'a a cleanup that does not require any
change to the module verification code.
The second patch is the only one that is intended to change any
functionality.
The rest only deduplicates code but I did not receive a
On Thu, Sep 30, 2021 at 02:20:33PM -0700, Linus Torvalds wrote:
> On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
> >
> > The first patch is a cleanup of numa_distance allocation in arch_numa I've
> > spotted during the conversion.
> > The second patch is a fix for Xen memory freeing on some
On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
>
> The first patch is a cleanup of numa_distance allocation in arch_numa I've
> spotted during the conversion.
> The second patch is a fix for Xen memory freeing on some of the error
> paths.
Well, at least patch 2 looks like something that s
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
I
On Sat, Aug 07, 2021 at 11:26:45AM +0200, Uwe Kleine-König wrote:
> On Fri, Aug 06, 2021 at 04:24:52PM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> > > On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> >
> > > > I looked at all
On Fri, Aug 06, 2021 at 04:24:52PM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> > On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
>
> > > I looked at all the bus_type.probe() methods, it looks like pci_dev is
> > > not the only of
On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> > I looked at all the bus_type.probe() methods, it looks like pci_dev is
> > not the only offender here. At least the following also have a driver
> > pointer in th
Hello Bjorn,
On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 03, 2021 at 12:01:44PM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > changes since v1
> > (https://lore.kernel.org/linux-pci/20210729203740.1377045-1-u.kleine-koe...@pengutronix.de):
> >
> > - New patc
On Tue, Aug 03, 2021 at 12:01:44PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> changes since v1
> (https://lore.kernel.org/linux-pci/20210729203740.1377045-1-u.kleine-koe...@pengutronix.de):
>
> - New patch to simplify drivers/pci/xen-pcifront.c, spotted and
> suggested by Boris Ostrovsky
> -
Hello,
changes since v1
(https://lore.kernel.org/linux-pci/20210729203740.1377045-1-u.kleine-koe...@pengutronix.de):
- New patch to simplify drivers/pci/xen-pcifront.c, spotted and
suggested by Boris Ostrovsky
- Fix a possible NULL pointer dereference I introduced in xen-pcifront.c
- A few whi
On Wed, 16 Jun 2021 10:22:33 +0530 "Aneesh Kumar K.V"
wrote:
> This patch series is split out series from [PATCH v7 00/11] Speedup mremap on
> ppc64
> (https://lore.kernel.org/linux-mm/20210607055131.156184-1-aneesh.ku...@linux.ibm.com)
> dropping ppc64 specific changes.
>
> This patchset is d
On Tue, Jun 15, 2021 at 9:53 PM Aneesh Kumar K.V
wrote:
>
> This patch series is split out series from [PATCH v7 00/11] Speedup mremap on
> ppc64
> (https://lore.kernel.org/linux-mm/20210607055131.156184-1-aneesh.ku...@linux.ibm.com)
> dropping ppc64 specific changes.
Both this and the followup
This patch series is split out series from [PATCH v7 00/11] Speedup mremap on
ppc64
(https://lore.kernel.org/linux-mm/20210607055131.156184-1-aneesh.ku...@linux.ibm.com)
dropping ppc64 specific changes.
This patchset is dependent on
https://lore.kernel.org/linux-mm/20210615110859.320299-1-aneesh.
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.
The patchset does that by switching the page
Hi,
These patches provide generic infrastructure to determine TLB page size from
page table entries alone. Perf will use this (for either data or code address)
to aid in profiling TLB issues.
While most architectures only have page table aligned large pages, some
(notably ARM64, Sparc64 and Power
On 11/17/20 11:16 AM, Tyrel Datwyler wrote:
> Several Management Datagrams (MADs) have been reversioned to add a targetWWPN
> field that is intended to better identify a target over a scsi_id. Further, a
> couple new MADs have been introduced to the protocol to be used for
> negotiation
> of chann
Several Management Datagrams (MADs) have been reversioned to add a targetWWPN
field that is intended to better identify a target over a scsi_id. Further, a
couple new MADs have been introduced to the protocol to be used for negotiation
of channels/hw queues resources when the VIOS is using SLI-4 ca
On Mon, 27 Jul 2020 09:30:34 +0530, Sandipan Das wrote:
> Based on recent bugs found in the pkey infrastructure, this
> improves the test for execute-disabled pkeys and adds a new
> test for detecting inconsistencies with the pkey reported by
> the signal information upon getting a fault.
>
> Prev
On Mon, 29 Jun 2020 11:15:19 + (UTC), Christophe Leroy wrote:
> On book3s32 (hash), exec protection is set per 256Mb segments with NX bit.
> Instead of clearing NX bit on vmalloc space when CONFIG_MODULES is selected,
> allocate modules in a dedicated segment (0xb000-0xbfff by default).
Based on recent bugs found in the pkey infrastructure, this
improves the test for execute-disabled pkeys and adds a new
test for detecting inconsistencies with the pkey reported by
the signal information upon getting a fault.
Previous versions can be found at:
v1:
https://lore.kernel.org/linuxppc
On Wed, 24 Jun 2020 17:00:32 +0530, Balamuruhan S wrote:
> ppc-opcode.h have base instruction encoding wrapped with stringify_in_c()
> for raw encoding to have compatibility. But there are redundant macros for
> base instruction encodings in bpf, instruction emulation test infrastructure
> and powe
v2 is updated to account for feedback from Will, Peter, and
Waiman (thank you), and trims off a couple of RFC and unrelated
patches.
Thanks,
Nick
Nicholas Piggin (6):
powerpc/powernv: must include hvcall.h to get PAPR defines
powerpc/pseries: move some PAPR paravirt functions to their own fil
On book3s32 (hash), exec protection is set per 256Mb segments with NX bit.
Instead of clearing NX bit on vmalloc space when CONFIG_MODULES is selected,
allocate modules in a dedicated segment (0xb000-0xbfff by default).
This allows to keep exec protection on vmalloc space while allowing exe
ppc-opcode.h have base instruction encoding wrapped with stringify_in_c()
for raw encoding to have compatibility. But there are redundant macros for
base instruction encodings in bpf, instruction emulation test infrastructure
and powerpc selftests.
Currently PPC_INST_* macros are used for encoding
There are some devices that only allow 1 DMA window to exist at a time,
and in those cases, a DDW is never created to them, since the default DMA
window keeps using this resource.
LoPAR recommends this procedure:
1. Remove the default DMA window,
2. Query for which configs the DDW can be created,
The TLB flush optimisation (a46cc7a90f: powerpc/mm/radix: Improve TLB/PWC
flushes) may result in random memory corruption. Any concurrent page-table walk
could end up with a Use-after-Free. Even on UP this might give issues, since
mmu_gather is preemptible these days. An interrupt or preempted task
This is a try to implement KASLR for Freescale BookE64 which is based on
my earlier implementation for Freescale BookE32:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=131718
The implementation for Freescale BookE64 is similar as BookE32. One
difference is that Freescale BookE64 s
On Wed, Oct 16, 2019 at 11:44:03PM +0200, Greg Kurz wrote:
> On Fri, 27 Sep 2019 13:53:32 +0200
> Greg Kurz wrote:
>
> > This brings some fixes and allows to start more VMs with an in-kernel
> > XIVE or XICS-on-XIVE device.
> >
> > Changes since v1 (https://patchwork.ozlabs.org/cover/1166099/):
On Fri, 27 Sep 2019 13:53:32 +0200
Greg Kurz wrote:
> This brings some fixes and allows to start more VMs with an in-kernel
> XIVE or XICS-on-XIVE device.
>
> Changes since v1 (https://patchwork.ozlabs.org/cover/1166099/):
> - drop a useless patch
> - add a patch to show VP ids in debugfs
> - up
This brings some fixes and allows to start more VMs with an in-kernel
XIVE or XICS-on-XIVE device.
Changes since v1 (https://patchwork.ozlabs.org/cover/1166099/):
- drop a useless patch
- add a patch to show VP ids in debugfs
- update some changelogs
- fix buggy check in patch 5
- Cc: stable
--
From: Alastair D'Silva
This series addresses a few issues discovered in how we flush caches:
1. Flushes were truncated at 4GB, so larger flushes were incorrect.
2. Flushing the dcache in arch_add_memory was unnecessary
This series also converts much of the cache assembler to C, with the
aim of m
@Andrew: Only patch 1 and 6 changed. The patches are based on the
same state as the previous patches (replace the old ones if possible).
Some further cleanups around memory block devices. Especially, clean up
and simplify walk_memory_range(). Including some other minor cleanups.
Compiled + tested
Hi all,
Here is v2, addressing feedback from v1.
Original cover letter follows, slightly updated for v2:
This patch set adds support for EEH recovery of hot plugged devices on pSeries
machines. Specifically, devices discovered by PCI rescanning using
/sys/bus/pci/rescan, which includes devices h
This small series consists of some small cleanups and simplifications
of the QUICC engine driver, and introduces a new DT binding that makes
it much easier to support other variants of the QUICC engine IP block
that appears in the wild: There's no reason to expect in general that
the number of vali
On Mon, Mar 18, 2019 at 3:49 AM Sudeep Holla wrote:
>
> Hi,
>
> This patchset evolved from the discussion in the thread[0][1]. When we
> wanted to add PTRACE_SYSEMU support to ARM64, we thought instead of
> duplicating what other architectures like x86 and powerpc have done,
> let consolidate the
Hi,
This patchset evolved from the discussion in the thread[0][1]. When we
wanted to add PTRACE_SYSEMU support to ARM64, we thought instead of
duplicating what other architectures like x86 and powerpc have done,
let consolidate the existing support and move it to the core as there's
nothing arch s
This series adds emulation support for some additional ISA 3.0
instructions, most of which are now generated by a recent compiler
(e.g. gcc-8.x) when building the kernel with CONFIG_POWER9_CPU=y.
Changelog:
v1 -> v2:
- Use a conservative approach when using the multiply-add and
darn in
Hi,
These patches simplify some of the early memory allocations by replacing
usage of older memblock APIs with newer and shinier ones.
Quite a few places in the arch/ code allocated memory using a memblock API
that returns a physical address of the allocated area, then converted this
physical add
Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the mem_hotplug_lock. And there are other places where we call
device_online()/device_o
Le 29/08/2018 à 15:13, David Gounaris a écrit :
Here is what has been changed in v2 after the review comments.
v2-0001: Using UCC_MAX_NUM
This one has a warning/check from checkpatch
v2-0002: Unchanged
v2-0003: Changed commit message
v2-0004: Adding fsl,hmask into the dt instead of changi
Here is what has been changed in v2 after the review comments.
v2-0001: Using UCC_MAX_NUM
v2-0002: Unchanged
v2-0003: Changed commit message
v2-0004: Adding fsl,hmask into the dt instead of changing the default value.
v2-0005: Unchanged
v2-0006: Unchanged
Adding robh...@kernel.org for comments re
On Sun, Jun 24, 2018 at 01:02:50AM +1000, Michael Ellerman wrote:
> Ram Pai writes:
> > On Thu, Jun 21, 2018 at 08:28:47PM +1000, Michael Ellerman wrote:
> >> Florian Weimer writes:
> >> > On 06/19/2018 02:40 PM, Michael Ellerman wrote:
> >> >>> I tested the whole series with the new selftests, w
Ram Pai writes:
> On Thu, Jun 21, 2018 at 08:28:47PM +1000, Michael Ellerman wrote:
>> Florian Weimer writes:
>> > On 06/19/2018 02:40 PM, Michael Ellerman wrote:
>> >>> I tested the whole series with the new selftests, with the printamr.c
>> >>> program I posted earlier, and the glibc test for p
On Thu, Jun 21, 2018 at 08:28:47PM +1000, Michael Ellerman wrote:
> Florian Weimer writes:
>
> > On 06/19/2018 02:40 PM, Michael Ellerman wrote:
> >>> I tested the whole series with the new selftests, with the printamr.c
> >>> program I posted earlier, and the glibc test for pkey_alloc &c. The
>
Florian Weimer writes:
> On 06/19/2018 02:40 PM, Michael Ellerman wrote:
>>> I tested the whole series with the new selftests, with the printamr.c
>>> program I posted earlier, and the glibc test for pkey_alloc &c. The
>>> latter required some test fixes, but now passes as well. As far as I
>>>
On 06/19/2018 02:40 PM, Michael Ellerman wrote:
I tested the whole series with the new selftests, with the printamr.c
program I posted earlier, and the glibc test for pkey_alloc &c. The
latter required some test fixes, but now passes as well. As far as I
can tell, everything looks good now.
Te
Florian Weimer writes:
> On 06/14/2018 02:28 AM, Ram Pai wrote:
>> Assortment of fixes to pkey.
>>
>> Patch 1 makes pkey consumable in multithreaded applications.
>>
>> Patch 2 fixes fork behavior to inherit the key attributes.
>>
>> Patch 3 A off-by-one bug made one key unusable. Fixes it.
On 06/14/2018 02:28 AM, Ram Pai wrote:
Assortment of fixes to pkey.
Patch 1 makes pkey consumable in multithreaded applications.
Patch 2 fixes fork behavior to inherit the key attributes.
Patch 3 A off-by-one bug made one key unusable. Fixes it.
Patch 4 Execute-only key is preallocated.
Assortment of fixes to pkey.
Patch 1 makes pkey consumable in multithreaded applications.
Patch 2 fixes fork behavior to inherit the key attributes.
Patch 3 A off-by-one bug made one key unusable. Fixes it.
Patch 4 Execute-only key is preallocated.
Patch 5 Makes pkey-0 less special.
Patc
1 - 100 of 193 matches
Mail list logo
