Le 17/05/2024 à 16:27, Oscar Salvador a écrit :
> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
>> This series reimplements hugepages with hugepd on powerpc 8xx.
>>
>> Unlike most architectures, powerpc 8xx HW requires a two-level
>> pagetable topology for all page sizes. So a
On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> This series reimplements hugepages with hugepd on powerpc 8xx.
>
> Unlike most architectures, powerpc 8xx HW requires a two-level
> pagetable topology for all page sizes. So a leaf PMD-contig approach
> is not feasible as such.
>
On Tue, Apr 16, 2024 at 10:58:33AM +, Christophe Leroy wrote:
>
>
> Le 15/04/2024 à 21:12, Christophe Leroy a écrit :
> >
> >
> > Le 12/04/2024 à 16:30, Peter Xu a écrit :
> >> On Fri, Apr 12, 2024 at 02:08:03PM +, Christophe Leroy wrote:
> >>>
> >>>
> >>> Le 11/04/2024 à 18:15, Peter X
Le 15/04/2024 à 21:12, Christophe Leroy a écrit :
>
>
> Le 12/04/2024 à 16:30, Peter Xu a écrit :
>> On Fri, Apr 12, 2024 at 02:08:03PM +, Christophe Leroy wrote:
>>>
>>>
>>> Le 11/04/2024 à 18:15, Peter Xu a écrit :
On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
Le 12/04/2024 à 16:30, Peter Xu a écrit :
> On Fri, Apr 12, 2024 at 02:08:03PM +, Christophe Leroy wrote:
>>
>>
>> Le 11/04/2024 à 18:15, Peter Xu a écrit :
>>> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wro
On Fri, Apr 12, 2024 at 02:08:03PM +, Christophe Leroy wrote:
>
>
> Le 11/04/2024 à 18:15, Peter Xu a écrit :
> > On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
> >> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> >>> This series reimplements hugepages wi
Le 11/04/2024 à 18:15, Peter Xu a écrit :
> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
>> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
>>> This series reimplements hugepages with hugepd on powerpc 8xx.
>>>
>>> Unlike most architectures, powerpc 8xx HW re
On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> > This series reimplements hugepages with hugepd on powerpc 8xx.
> >
> > Unlike most architectures, powerpc 8xx HW requires a two-level
> > pagetable topology for
On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> This series reimplements hugepages with hugepd on powerpc 8xx.
>
> Unlike most architectures, powerpc 8xx HW requires a two-level
> pagetable topology for all page sizes. So a leaf PMD-contig approach
> is not feasible as such.
>
This series reimplements hugepages with hugepd on powerpc 8xx.
Unlike most architectures, powerpc 8xx HW requires a two-level
pagetable topology for all page sizes. So a leaf PMD-contig approach
is not feasible as such.
Possible sizes are 4k, 16k, 512k and 8M.
First level (PGD/PMD) covers 4M per
On Sat, Nov 25, 2023 at 03:47:41AM +0300, George Stark wrote:
> On 11/24/23 18:28, Andy Shevchenko wrote:
> > On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> > > Lots of drivers use devm_led_classdev_register() to register their led
> > > objects
> > > and let the kernel free those
On Sat, 25 Nov 2023 03:47:41 +0300
George Stark wrote:
> Hello Andy
>
> Thanks for the review.
>
> On 11/24/23 18:28, Andy Shevchenko wrote:
> > On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> >> Lots of drivers use devm_led_classdev_register() to register their led
> >> obje
Hello Andy
Thanks for the review.
On 11/24/23 18:28, Andy Shevchenko wrote:
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the kernel free those leds at the driver's remove stage.
It can lead
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> Lots of drivers use devm_led_classdev_register() to register their led objects
> and let the kernel free those leds at the driver's remove stage.
> It can lead to a problem due to led_classdev_unregister()
> implementation calls led_se
On Sat, Nov 4, 2023 at 9:17 AM George Stark wrote:
>
> Hello Andy
>
> Could you please take a look at this patch series?
>
> I've just found your post on habr about devres API misusing and I think
> this is just another case.
Just had a look, sorry for the delay.
By quickly reading it seems to be
Le 10/11/2023 à 02:38, Daniel Walker a écrit :
> This release is an up-rev of the v5 patches. No additional features have
> been added. Some changes were mode to function names and some changes to
> Kconfig dependencies. Also updated the config conversion for mips.
>
> There are a number of peop
On Fri, 10 Nov 2023 02:22:27 + "Daniel Walker (danielwa)"
wrote:
> On Thu, Nov 09, 2023 at 05:51:42PM -0800, Andrew Morton wrote:
> > On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> >
> > > This release is an up-rev of the v5 patches. No additional features have
> > > been added.
On Thu, Nov 09, 2023 at 05:51:42PM -0800, Andrew Morton wrote:
> On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
>
> > This release is an up-rev of the v5 patches. No additional features have
> > been added. Some changes were mode to function names and some changes to
> > Kconfig dependen
On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> This release is an up-rev of the v5 patches. No additional features have
> been added. Some changes were mode to function names and some changes to
> Kconfig dependencies. Also updated the config conversion for mips.
>
> There are a numbe
This release is an up-rev of the v5 patches. No additional features have
been added. Some changes were mode to function names and some changes to
Kconfig dependencies. Also updated the config conversion for mips.
There are a number of people who have expressed interest in these
patches either by a
Le 25/10/2023 à 15:07, George Stark a écrit :
> Lots of drivers use devm_led_classdev_register() to register their led objects
> and let the kernel free those leds at the driver's remove stage.
> It can lead to a problem due to led_classdev_unregister()
> implementation calls led_set_brightness()
Hello Andy
Could you please take a look at this patch series?
I've just found your post on habr about devres API misusing and I think
this is just another case.
On 10/25/23 16:07, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the k
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the kernel free those leds at the driver's remove stage.
It can lead to a problem due to led_classdev_unregister()
implementation calls led_set_brightness() to turn off the led.
led_set_brightness() may call one
Continue converting drivers to the new interface. Introduce
ops->blocked_domain to hold the global static BLOCKED domain and convert
all drivers supporting BLOCKED to use it.
This makes it trivial for dart and iommufd to convert over to
domain_alloc_paging().
There are six drivers remaining:
dri
From: Joel Granados
What?
These commits remove the sentinel element (last empty element) from the
sysctl arrays of all the files under the "arch/" directory that use a
sysctl array for registration. The merging of the preparation patches
(in https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil
On Mon, 06 Mar 2023 15:33:39 -0600, Nathan Lynch wrote:
> Proposed changes for the RTAS subsystem and client code.
>
> Fixes that are subject to backporting are at the front of the queue,
> followed by documentation and cleanups, with enhancements at the end.
>
> Noteworthy changes:
> * Change sy
This patch series contains cleanups for fsl_uli1575 driver.
This patch series is prerequisity for another patch series:
"powerpc/85xx: p2020: Create one unified machine description"
Christophe Leroy (1):
powerpc/fsl_uli1575: Misc cleanup
Pali Rohár (7):
powerpc/85xx: mpc85xx_ds: Simplify mpc
On Mon, 06 Mar 2023 15:33:39 -0600, Nathan Lynch wrote:
> Proposed changes for the RTAS subsystem and client code.
>
> Fixes that are subject to backporting are at the front of the queue,
> followed by documentation and cleanups, with enhancements at the end.
>
> Noteworthy changes:
> * Change sy
Proposed changes for the RTAS subsystem and client code.
Fixes that are subject to backporting are at the front of the queue,
followed by documentation and cleanups, with enhancements at the end.
Noteworthy changes:
* Change sys_rtas() to consume -2/990x statuses instead of returning
them to us
The way copy_thread works, particularly with kernel threads and kernel
created user threads is a bit muddled and confusing. This series tries
to straighten things out a bit.
Thanks,
Nick
Nicholas Piggin (8):
powerpc: copy_thread remove unused pkey code
powerpc: copy_thread make ret_from_fork
On Mon, Sep 26, 2022 at 05:52:18PM -0500, Rob Herring wrote:
> On Thu, Sep 22, 2022 at 4:15 PM Daniel Gimpelevich
> wrote:
> >
> > On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> > [snip]
> > > > As recently as last mon
On Thu, Sep 22, 2022 at 02:15:44PM -0700, Daniel Gimpelevich wrote:
> On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> [snip]
> > > As recently as last month, someone's patch to add such support was
> > > rejected for this
On Thu, Sep 22, 2022 at 4:15 PM Daniel Gimpelevich
wrote:
>
> On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> [snip]
> > > As recently as last month, someone's patch to add such support was
> > > rejected for this reason
On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
[snip]
> > As recently as last month, someone's patch to add such support was
> > rejected for this reason [1].
> >
> > --Sean
> >
> > [1]
> > https://lore.kernel.org/linux-ar
On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
>
>
>
> On 9/22/22 4:53 PM, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
> >>
> >>
> >>
> >> For an arm64 platform (after rebasing):
> >>
> >> Tested-by: Sean Anderson
> >
> > Maybe I'
On 9/22/22 4:53 PM, Daniel Walker wrote:
> On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
>>
>>
>>
>> For an arm64 platform (after rebasing):
>>
>> Tested-by: Sean Anderson
>
> Maybe I'll re-submit it.
>
> Daniel
>
There's still no way to extend the command line on ARM6
On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
>
>
>
> For an arm64 platform (after rebasing):
>
> Tested-by: Sean Anderson
Maybe I'll re-submit it.
Daniel
On 4/16/21 12:09 AM, Daniel Walker wrote:
>
> v4 release changes
>
> * Updated insert-sys-cert tool to change command line symbols after
> compilation.
>
> This tool is used to release binary kernels internally to companies
> and then later insert certificates for each product b
From: Guo Ren
This macro isn't used in Linux, now. Delete in include/linux/sched.h
and arch's include/asm. This would confuse people who are
implementing the COMPAT feature for architecture.
Guo Ren (8):
sched: Remove unused TASK_SIZE_OF
sched: x86: Remove unused TASK_SIZE_OF
sched: sparc:
Le 24/11/2021 à 14:40, Christophe Leroy a écrit :
Le 24/11/2021 à 14:21, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
This series converts powerpc to default topdown mmap layout.
powerpc provides its own arch_get_unmapped_area() only whe
Le 24/11/2021 à 14:21, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
This series converts powerpc to default topdown mmap layout.
powerpc provides its own arch_get_unmapped_area() only when
slices are needed, which is only for book3s/64. Fir
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
> This series converts powerpc to default topdown mmap layout.
>
> powerpc provides its own arch_get_unmapped_area() only when
> slices are needed, which is only for book3s/64. First part of
> the series moves slices into book3
This series converts powerpc to default topdown mmap layout.
powerpc provides its own arch_get_unmapped_area() only when
slices are needed, which is only for book3s/64. First part of
the series moves slices into book3s/64 specific directories
and cleans up other subarchitectures.
Then a small mod
This patch series aims at fixing some of the AER error handling issues
we have.
Currently we have the following issues:
- Confusing message in aer_print_error()
- aer_err_info not being initialized completely in DPC path before
we print the AER logs
- A bug [1] in clearing of AER registers
On Tue, 14 Sept 2021 at 15:55, Mark Rutland wrote:
>
> On Tue, Sep 14, 2021 at 02:10:28PM +0200, Ard Biesheuvel wrote:
> > Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> > task_struct") mentions that, along with moving thread_info into
> > task_struct, the cpu field is moved ou
On Tue, Sep 14, 2021 at 02:10:28PM +0200, Ard Biesheuvel wrote:
> Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> task_struct") mentions that, along with moving thread_info into
> task_struct, the cpu field is moved out of the former into the latter,
> but does not explain why.
Le 14/09/2021 à 14:10, Ard Biesheuvel a écrit :
Commit c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") mentions that, along with moving thread_info into
task_struct, the cpu field is moved out of the former into the latter,
but does not explain why.
I think it does ex
Commit c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") mentions that, along with moving thread_info into
task_struct, the cpu field is moved out of the former into the latter,
but does not explain why.
While collaborating with Keith on adding THREAD_INFO_IN_TASK support to
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.
So far this survives about 5 hours of stress testing with a workload
that would trigger it in a few seconds (guest 128 vcpus running ker
On 6/14/21 1:39 PM, Aneesh Kumar K.V wrote:
Form2 associativity adds a much more flexible NUMA topology layout
than what is provided by Form1. This also allows PAPR SCM device
to use better associativity when using the device as DAX KMEM
device. More details can be found in patch x
$ ndctl li
Form2 associativity adds a much more flexible NUMA topology layout
than what is provided by Form1. This also allows PAPR SCM device
to use better associativity when using the device as DAX KMEM
device. More details can be found in patch x
$ ndctl list -N -v
[
{
"dev":"namespace0.0",
"mod
On Thu, May 13, 2021 at 12:02:54PM +0200, Juergen Gross wrote:
> Xen backends of para-virtualized devices can live in dom0 kernel, dom0
> user land, or in a driver domain. This means that a backend might
> reside in a less trusted environment than the Xen core components, so
> a backend should not
Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen guest (it can still
mess up I/O data, but i
v4 release changes
* Updated insert-sys-cert tool to change command line symbols after
compilation.
This tool is used to release binary kernels internally to companies
and then later insert certificates for each product by consumers of
the binary kernel. Cisco uses thi
On Thu, 25 Feb 2021 14:09:58 +1100, Daniel Axtens wrote:
> To support Clang's CFI we need LTO. For LTO, we need to be able to compile
> with the LLVM integrated assembler.
>
> Currently, we can't.
>
> This series gets us a bit closer, but I'm still stuck and I'm hoping
> someone can point me in t
To support Clang's CFI we need LTO. For LTO, we need to be able to compile
with the LLVM integrated assembler.
Currently, we can't.
This series gets us a bit closer, but I'm still stuck and I'm hoping
someone can point me in the right direction.
Patch 1 is a fix that can be merged at any time.
On Sat, 28 Nov 2020 17:07:20 +1000, Nicholas Piggin wrote:
> First patch is a nasty memory scribble introduced by me :( That
> should go into fixes.
>
> The next ones could wait for next merge window. They get things to the
> point where misbehaving or buggy guest isn't so painful for the host,
>
On Sat, 28 Nov 2020 17:07:20 +1000, Nicholas Piggin wrote:
> First patch is a nasty memory scribble introduced by me :( That
> should go into fixes.
>
> The next ones could wait for next merge window. They get things to the
> point where misbehaving or buggy guest isn't so painful for the host,
>
This is a rebase now on top of Arnd's asm-generic tree, which has
reduced most of the fluff from this patch series.
The x86 refactoring is still in the way a bit, I hope to get some
movement on that rather than rebase the main patches off it, because
I think it's a good cleanup. I think it could g
First patch is a nasty memory scribble introduced by me :( That
should go into fixes.
The next ones could wait for next merge window. They get things to the
point where misbehaving or buggy guest isn't so painful for the host,
and also get the guest SLB dumping code working (because the host no
lo
On Thu, 26 Nov 2020 13:38:45 + Lee Jones wrote:
> Resending the stragglers.
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
This set doesn't apply to net-next, please rebase.
Resending the stragglers.
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (8):
net: ethernet: smsc: smc91x: Demote non-conformant kernel function
header
net: xen-netback: xenbus
As reported by Anton, there is a large penalty to signal handling
performance on radix systems using KUAP. The signal handling code
performs many user access operations, each of which needs to switch the
KUAP permissions bit to open and then close user access. This involves a
costly 'mtspr' operati
> > > >
> > > > Commit 12cc923f1ccc ("tasklet: Introduce new initialization
> > > > API")' introduced a new tasklet initialization API. This series
> > > > converts all the scsi drivers to use the new tasklet_setup() API
> > >
> > > I've got to say I agree with Jens, this was a silly obfuscation:
>
On Mon, 2020-08-17 at 12:28 -0700, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 07:41:58AM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> > > From: Allen Pais
> > >
> > > Commit 12cc923f1ccc ("tasklet: Introduce new initialization
> > > API")' introduced a
On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> From: Allen Pais
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the scsi drivers to use the new tasklet_setup() API
I've got to say I agree wi
On Mon, Aug 17, 2020 at 07:41:58AM -0700, James Bottomley wrote:
> On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> > From: Allen Pais
> >
> > Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> > introduced a new tasklet initialization API. This series converts
> > all th
From: Allen Pais
Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
introduced a new tasklet initialization API. This series converts
all the scsi drivers to use the new tasklet_setup() API
Allen Pais (8):
scsi: aic94xx: convert tasklets to use new tasklet_setup() API
scsi:
On Sun, 31 May 2020 09:17:03 +1000, Finn Thain wrote:
> The adb-iop driver was never finished. Some deficiencies have become
> apparent over the years. For example,
>
> - Mouse and/or keyboard may stop working if used together
>
> - SRQ autopoll list cannot be changed
>
> [...]
Applied to pow
Gentle ping.
On Sat, Jun 27, 2020 at 05:34:45PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
This series adds an option to use queued spinlocks for powerpc, and
makes it the default for the Book3S-64 subarch.
This effort starts with the generic code so it's very simple but
still very performant. There are optimisations that can be made to
slowpaths, but I think it's better to attack those
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote:
> Bolarinwa Olayemi Saheed (8):
> IB/hfi1: Convert PCIBIOS_* errors to generic -E* errors
> IB/hfi1: Convert PCIBIOS_* errors to generic -E* errors
Applied to rdma for-next thanks
Jason
On Sat, Jun 27, 2020 at 5:35 PM Mike Rapoport wrote:
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
> and enable use of the generic functions where
> appropri
On Sat, Jun 27, 2020 at 05:34:45PM +0300, Mike Rapoport wrote:
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
> and enable use of the generic functions where
From: Mike Rapoport
Hi,
Most architectures have very similar versions of pXd_alloc_one() and
pXd_free_one() for intermediate levels of page table.
These patches add generic versions of these functions in
and enable use of the generic functions where
appropriate.
In addition, functions declare
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote:
> From: Bolarinwa Olayemi Saheed
>
>
> PATCH 1/8 to 7/8:
> PCIBIOS_ error codes have positive values and they are passed down the
> call heirarchy from accessors. For functions which are meant to return
> only a negative v
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote:
> From: Bolarinwa Olayemi Saheed
>
>
> PATCH 1/8 to 7/8:
> PCIBIOS_ error codes have positive values and they are passed down the
> call heirarchy from accessors. For functions which are meant to return
> only a negative v
From: Bolarinwa Olayemi Saheed
PATCH 1/8 to 7/8:
PCIBIOS_ error codes have positive values and they are passed down the
call heirarchy from accessors. For functions which are meant to return
only a negative value on failure, passing on this value is a bug.
To mitigate this, call pcibios_err_to_e
The adb-iop driver was never finished. Some deficiencies have become
apparent over the years. For example,
- Mouse and/or keyboard may stop working if used together
- SRQ autopoll list cannot be changed
- Some bugs were found by inspection
This patch series contains fixes for the known bugs
On 4/16/20 8:59 AM, Luis Chamberlain wrote:
On Tue, Apr 14, 2020 at 02:42:54PM +0200, Emanuele Giuseppe Esposito wrote:
This series of patches introduce wrappers for functions,
arguments simplification in functions calls and most importantly
groups duplicated code in a single header, simplefs
On Tue, Apr 14, 2020 at 02:42:54PM +0200, Emanuele Giuseppe Esposito wrote:
> This series of patches introduce wrappers for functions,
> arguments simplification in functions calls and most importantly
> groups duplicated code in a single header, simplefs, to avoid redundancy
> in the linux fs, esp
This series of patches introduce wrappers for functions,
arguments simplification in functions calls and most importantly
groups duplicated code in a single header, simplefs, to avoid redundancy
in the linux fs, especially debugfs and tracefs.
Signed-off-by: Emanuele Giuseppe Esposito
Emanuele G
The hv_24×7 feature in IBM® POWER9™ processor-based servers provide the
facility to continuously collect large numbers of hardware performance
metrics efficiently and accurately.
First patch of the patchset fix inconsistent results we are getting when
we run multiple 24x7 events.
Patchset adds js
The purpose of this series is to accelerate IRQ entry by
avoiding unneccessary trampoline functions like call_do_irq()
and call_do_softirq() and by switching to IRQ stack
immediately in the exception handler.
For now, it is an RFC as it is still a bit messy.
Please provide feedback and I'll impro
I've gone through the remaining uses of time_t etc and come up with a
set of 90 patches of varying complexity and importance, to the point
of being able to remove the old time_t/timeval/timespec from the kernel
headers completely.
This set includes the eight patches that I think should be merged
r
Hi all,
this series attempts to address some issues we found while bringing up
the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
up of this discussion:
https://lkml.org/lkml/2019/7/17/476
The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
only address the
These are all likely copy/paste defects where the field size of the
'copied to' array is incorrect.
Each patch in this series is independent.
Joe Perches (8):
Input: synaptics: Fix misuse of strlcpy
leds: as3645a: Fix misuse of strlcpy
media: m2m-deinterlace: Fix misuse of strscpy
media:
This series adds a new procfs file /proc/powerpc/vcpudispatch_stats for
providing statistics around how the LPAR processors are dispatched by
the POWER Hypervisor, in a shared LPAR environment. Patch 6/8 has more
details on how the statistics are gathered.
An example output:
$ sudo cat /pro
On 04/14/2019 08:41 PM, Sam Bobroff wrote:
> On Thu, Apr 11, 2019 at 05:55:33PM -0700, Tyrel Datwyler wrote:
>> On 03/19/2019 07:58 PM, Sam Bobroff wrote:
>>> Hi all,
>>>
>>> This patch set adds support for EEH recovery of hot plugged devices on
>>> pSeries
>>> machines. Specifically, devices disc
On Thu, Apr 11, 2019 at 05:55:33PM -0700, Tyrel Datwyler wrote:
> On 03/19/2019 07:58 PM, Sam Bobroff wrote:
> > Hi all,
> >
> > This patch set adds support for EEH recovery of hot plugged devices on
> > pSeries
> > machines. Specifically, devices discovered by PCI rescanning using
> > /sys/bus/p
On 03/19/2019 07:58 PM, Sam Bobroff wrote:
> Hi all,
>
> 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 hotplugged by QEMU's device_add
> command. (pSe
Hi Al,
Here's a set of patches that converts the mount_single()-using filesystems
to use the new fs_context struct. There may be prerequisite commits in the
branch detailed below.
(1) Add a new keying to vfs_get_super() that indicates that
->reconfigure() should be called instead of (*fi
Hi all,
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 hotplugged by QEMU's device_add
command. (pSeries doesn't currently use slot power control for hotpl
On Fri, 2018-12-07 at 14:43 +1100, Suraj Jitindar Singh wrote:
> This patch series allows for emulated devices to be passed through to
> nested
> guests, irrespective of at which level the device is being emulated.
>
> Note that the emulated device must be using dma, not virtio.
>
> For example,
This patch series allows for emulated devices to be passed through to nested
guests, irrespective of at which level the device is being emulated.
Note that the emulated device must be using dma, not virtio.
For example, passing through an emulated e1000:
1. Emulate the device at L(n) for L(n+1)
On Mon, Oct 29, 2018 at 10:29:15AM +, Will Deacon wrote:
> On Wed, Oct 24, 2018 at 10:07:32AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Oct 24, 2018 at 11:57:44AM +0300, Maksym Kokhan wrote:
> > > Do you mean, that you haven't seen patch for ARM, which I sent on
> > > September 27 alon
On Wed, Oct 24, 2018 at 10:07:32AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 24, 2018 at 11:57:44AM +0300, Maksym Kokhan wrote:
> > Do you mean, that you haven't seen patch for ARM, which I sent on
> > September 27 along with cover and patch 1? It is strange, because
> > you was the one
On Wed, Oct 24, 2018 at 11:57:44AM +0300, Maksym Kokhan wrote:
> Do you mean, that you haven't seen patch for ARM, which I sent on
> September 27 along with cover and patch 1? It is strange, because
> you was the one from recipients. If so, you can see this patch here:
> https://lore.kernel.org/pat
Do you mean, that you haven't seen patch for ARM, which I sent on
September 27 along with cover and patch 1? It is strange, because
you was the one from recipients. If so, you can see this patch here:
https://lore.kernel.org/patchwork/patch/992779/
On Tue, Oct 23, 2018 at 5:48 PM Russell King - ARM
On Tue, Oct 23, 2018 at 05:43:18PM +0300, Maksym Kokhan wrote:
> We still have no response to patches for x86, arm, arm64 and powerpc.
> Is current generic command line implementation appropriate for these
> architectures?
> Is it possible to merge these patches in the current form (for x86,
> arm,
1 - 100 of 386 matches
Mail list logo
