Le 15/03/2024 à 03:57, Benjamin Gray a écrit :
> As we are patching instructions, we can assume the length is a multiple
> of 4 and the destination address is aligned.
>
> Atomicity of patching a prefixed instruction is not a concern, as the
> original implementation doesn't provide it anyway.
Le 15/03/2024 à 03:57, Benjamin Gray a écrit :
> The patching page set up as a writable alias may be in quadrant 1
> (userspace) if the temporary mm path is used. This causes sanitiser
> failures if so. Sanitiser failures also occur on the non-mm path
> because the plain memset family is instrume
On Thu, 2024-03-14 at 00:17 -0400, Nayna Jain wrote:
> usleep_range() function takes input time and range in usec. However,
> currently it is assumed in msec in the function
> plpks_confirm_object_flushed().
>
> Fix the total polling time for the object flushing from 5msec to
> 5sec.
>
> Reported
Also supersedes
https://lore.kernel.org/all/20240213043638.168048-1-bg...@linux.ibm.com/
The existing patching alias page setup and teardown sections can be
simplified to make use of the new open_patch_window() abstraction.
This eliminates the _mm variants of the helpers, consumers no longer
need to check mm_patch_enabled(), and consumers no longer need to worry
about synchronization
The code patching capabilities have grown, and the specific quirks for
setting up and tearing down the patching window are getting duplicated.
This commit introduces an abstraction for working with this patching
window. It defines open_patch_window() to set up the writable alias
page, and close_pa
As we are patching instructions, we can assume the length is a multiple
of 4 and the destination address is aligned.
Atomicity of patching a prefixed instruction is not a concern, as the
original implementation doesn't provide it anyway.
Signed-off-by: Benjamin Gray
---
arch/powerpc/lib/code-pa
The patching page set up as a writable alias may be in quadrant 1
(userspace) if the temporary mm path is used. This causes sanitiser
failures if so. Sanitiser failures also occur on the non-mm path
because the plain memset family is instrumented, and KASAN treats the
patching window as poisoned.
patch_instructions() introduces new behaviour with a couple of
variations. Test each case of
* a repeated 32-bit instruction,
* a repeated 64-bit instruction (ppc64), and
* a copied sequence of instructions
for both on a single page and when it crosses a page boundary.
Signed-off-by: Benja
On Wed, 2024-03-13 at 11:30 +, Christophe Leroy wrote:
>
>
> Le 13/03/2024 à 05:21, Rohan McLure a écrit :
> > In the new set_ptes() API, set_pte_at() (a special case of
> > set_ptes())
> > is intended to be instrumented by the page table check facility.
> > There
> > are however several othe
On 3/14/24 10:10 AM, Dave Hansen wrote:
On 3/14/24 09:45, John Baldwin wrote:
On 3/14/24 8:37 AM, Dave Hansen wrote:
On 3/14/24 04:23, Vignesh Balasubramanian wrote:
Add a new .note section containing type, size, offset and flags of
every xfeature that is present.
Mechanically, I'd much rath
On 3/14/24 8:37 AM, Dave Hansen wrote:
On 3/14/24 04:23, Vignesh Balasubramanian wrote:
But this patch series depends on heuristics based on the total XSAVE
register set size and the XCR0 mask to infer the layouts of the
various register blocks for core dumps, and hence, is not a foolproof
mecha
On 3/14/24 8:37 AM, Dave Hansen wrote:
On 3/14/24 04:23, Vignesh Balasubramanian wrote:
Add a new .note section containing type, size, offset and flags of
every xfeature that is present.
Mechanically, I'd much rather have all of that info in the cover letter
in the actual changelog instead.
I
> -Original Message-
> From: Vignesh Balasubramanian
> Sent: Donnerstag, 14. März 2024 12:23
> To: linux-ker...@vger.kernel.org; linux-toolcha...@vger.kernel.org
> Cc: m...@ellerman.id.au; npig...@gmail.com; christophe.le...@csgroup.eu;
> aneesh.ku...@kernel.org; naveen.n@linux.ibm.com
On Thu, Mar 14, 2024 at 07:37:13AM -0700, Guenter Roeck wrote:
> On 3/14/24 06:36, Geert Uytterhoeven wrote:
> > Hi Günter,
> >
> > On Tue, Mar 12, 2024 at 6:03 PM Guenter Roeck wrote:
> > > Some unit tests intentionally trigger warning backtraces by passing bad
> > > parameters to kernel API fun
Add a new .note section containing type, size, offset and flags of
every xfeature that is present.
This information will be used by the debuggers to understand the XSAVE
layout of the machine where the core file is dumped, and to read XSAVE
registers, especially during cross-platform debugging.
C
This patch proposes to add an extra .note section in the corefile to dump the
CPUID information of a machine. This is being done to solve the issue of tools
like the debuggers having to deal with coredumps from machines with varying
XSAVE layouts in spite of having the same XCR0 bits. The new pr
Hi Vignesh,
Vignesh Balasubramanian writes:
> Add a new .note section containing type, size, offset and flags of
> every xfeature that is present.
>
> This information will be used by the debuggers to understand the XSAVE
> layout of the machine where the core file is dumped, and to read XSAVE
>
On Thu, 14 Mar 2024 09:57:57 -0700
Alison Schofield wrote:
> On Fri, Feb 23, 2024 at 12:56:34PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > [
> >This is a treewide change. I will likely re-create this patch again in
> >the second week of the merge window of
[+cc Greg, Jeff -- ancient history, I know, sorry!]
On Tue, Feb 06, 2024 at 03:57:15PM +0200, Ilpo Järvinen wrote:
> Both AER and DPC RP PIO provide TLP Header Log registers (PCIe r6.1
> secs 7.8.4 & 7.9.14) to convey error diagnostics but the struct is
> named after AER as the struct aer_header_l
On 3/14/24 09:45, John Baldwin wrote:
> On 3/14/24 8:37 AM, Dave Hansen wrote:
>> On 3/14/24 04:23, Vignesh Balasubramanian wrote:
>>> Add a new .note section containing type, size, offset and flags of
>>> every xfeature that is present.
>>
>> Mechanically, I'd much rather have all of that info in
On Fri, Feb 23, 2024 at 12:56:34PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.9 and submit it then. Hoping
>to keep the conflicts that it will c
On 3/14/24 09:29, Borislav Petkov wrote:
>
>> That argument breaks down a bit on the flags though:
>>
>> xc.xfeat_flags = xstate_flags[i];
>>
>> Because it comes _directly_ from CPUID with zero filtering:
>>
>> cpuid_count(XSTATE_CPUID, i, &eax, &ebx, &ecx, &edx);
>> ...
>> xst
On Thu, Mar 14, 2024 at 04:25:44PM +, Willgerodt, Felix wrote:
> I am wondering if it wouldn't be easier for everyone if corefiles would just
> contain space for all possible XSAVE components?
You mean we should shuffle out from the kernel 8K of AMX state even if
nothing uses it or the machine
On Thu, Mar 14, 2024 at 09:19:15AM -0700, Dave Hansen wrote:
> Are you envisioning an *XSAVE* state component that's not described by
> CPUID?
I want to be prepared. You can imagine some of the short cuts and
corners cutting hw guys would do so I'd want to be prepared there and
not tie this to CPU
On 3/14/24 09:08, Borislav Petkov wrote:
> On Thu, Mar 14, 2024 at 08:37:09AM -0700, Dave Hansen wrote:
>> This is pretty close to just a raw dump of the XSAVE CPUID leaves.
>> Rather than come up with an XSAVE-specific ABI that depends on CPUID
>> *ANYWAY* (because it dumps the "flags" register ak
On Thu, Mar 14, 2024 at 08:37:09AM -0700, Dave Hansen wrote:
> This is pretty close to just a raw dump of the XSAVE CPUID leaves.
> Rather than come up with an XSAVE-specific ABI that depends on CPUID
> *ANYWAY* (because it dumps the "flags" register aka. ECX), maybe we
> should just bite the bulle
On Thu, Mar 14, 2024 at 04:53:28PM +0530, Vignesh Balasubramanian wrote:
> Add a new .note section containing type, size, offset and flags of
> every xfeature that is present.
>
> This information will be used by the debuggers to understand the XSAVE
> layout of the machine where the core file is
On 3/14/24 08:31, Christophe Leroy wrote:
Le 14/03/2024 à 16:21, Guenter Roeck a écrit :
On Wed, Nov 15, 2023 at 03:39:43PM +0100, Herve Codina wrote:
The QMC HDLC driver provides support for HDLC using the QMC (QUICC
Multichannel Controller) to transfer the HDLC data.
Signed-off-by: Herve C
On 3/14/24 04:23, Vignesh Balasubramanian wrote:
> Add a new .note section containing type, size, offset and flags of
> every xfeature that is present.
Mechanically, I'd much rather have all of that info in the cover letter
in the actual changelog instead.
I'd also love to see a practical example
Le 14/03/2024 à 16:21, Guenter Roeck a écrit :
> On Wed, Nov 15, 2023 at 03:39:43PM +0100, Herve Codina wrote:
>> The QMC HDLC driver provides support for HDLC using the QMC (QUICC
>> Multichannel Controller) to transfer the HDLC data.
>>
>> Signed-off-by: Herve Codina
>> Reviewed-by: Christophe
On 3/14/24 08:02, Maxime Ripard wrote:
On Thu, Mar 14, 2024 at 07:37:13AM -0700, Guenter Roeck wrote:
On 3/14/24 06:36, Geert Uytterhoeven wrote:
Hi Günter,
On Tue, Mar 12, 2024 at 6:03 PM Guenter Roeck wrote:
Some unit tests intentionally trigger warning backtraces by passing bad
parameters
On Wed, Nov 15, 2023 at 03:39:43PM +0100, Herve Codina wrote:
> The QMC HDLC driver provides support for HDLC using the QMC (QUICC
> Multichannel Controller) to transfer the HDLC data.
>
> Signed-off-by: Herve Codina
> Reviewed-by: Christophe Leroy
> Acked-by: Jakub Kicinski
> ---
[ ... ]
> +
On 3/14/24 06:36, Geert Uytterhoeven wrote:
Hi Günter,
On Tue, Mar 12, 2024 at 6:03 PM Guenter Roeck wrote:
Some unit tests intentionally trigger warning backtraces by passing bad
parameters to kernel API functions. Such unit tests typically check the
return value from such calls, not the exis
This happens especially if this driver is built-in, but SDMA driver
is configured as module.
Signed-off-by: Alexander Stein
---
sound/soc/fsl/fsl_ssi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index ab6ec1974807..4ca
On Thu, Mar 14, 2024 at 08:56:59AM +, Christophe Leroy wrote:
>
>
> Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> > From: Peter Xu
> >
> > This API is not used anymore, drop it for the whole tree.
> >
> > Signed-off-by: Peter Xu
> > ---
> > arch/arm/mm/Makefile
On 3/14/24 00:57, Geert Uytterhoeven wrote:
Hi Günter,
On Tue, Mar 12, 2024 at 6:06 PM Guenter Roeck wrote:
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to th
On Fri, Mar 08, 2024 at 03:11:38PM +, Luis Machado wrote:
> On 2/28/24 16:10, Tobias Huschle wrote:
> >
> > Questions:
> > 1. The kworker getting its negative lag occurs in the following scenario
> >- kworker and a cgroup are supposed to execute on the same CPU
> >- one task within the
Hi Günter,
On Tue, Mar 12, 2024 at 6:03 PM Guenter Roeck wrote:
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
>
> Such
On 3/14/24 04:45, George Stark wrote:
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no own
Le 14/03/2024 à 13:53, Peter Xu a écrit :
> On Thu, Mar 14, 2024 at 08:45:34AM +, Christophe Leroy wrote:
>>
>>
>> Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
>>> From: Peter Xu
>>>
>>> PowerPC book3s 4K mostly has the same definition on both, except pXd_huge()
>>> constantly returns
On Thu, Mar 14, 2024 at 08:50:20AM +, Christophe Leroy wrote:
>
>
> Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> > From: Peter Xu
> >
> > Now after we're sure all pXd_huge() definitions are the same as pXd_leaf(),
> > reuse it. Luckily, pXd_huge() isn't widely used.
> >
> > Signed
On Thu, Mar 14, 2024 at 08:45:34AM +, Christophe Leroy wrote:
>
>
> Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> > From: Peter Xu
> >
> > PowerPC book3s 4K mostly has the same definition on both, except pXd_huge()
> > constantly returns 0 for hash MMUs. As Michael Ellerman pointed
The fsl_qmc_driver does not compile as module:
error: ‘qmc_hdlc_driver’ undeclared here (not in a function);
405 | MODULE_DEVICE_TABLE(of, qmc_hdlc_driver);
| ^~~
Fix the typo.
Fixes: b40f00ecd463 ("net: wan: Add support for QMC HDLC")
Reported-by
Herve Codina writes:
> Hi Michael,
>
> On Thu, 14 Mar 2024 10:05:37 +1100
> Michael Ellerman wrote:
>
>> Hi Herve,
>>
>> Herve Codina writes:
> ..
>> This breaks when building as a module (eg. ppc32_allmodconfig):
>>
>> In file included from ../include/linux/device/driver.h:21,
>>
On Thu, 14 Mar 2024 11:45:23 +0300
George Stark wrote:
> Using of devm API leads to a certain order of releasing resources.
> So all dependent resources which are not devm-wrapped should be deleted
> with respect to devm-release order. Mutex is one of such objects that
> often is bound to other r
On Thu, Mar 14, 2024 at 10:46 AM George Stark wrote:
>
> This patch series fixes the problem of devm_led_classdev_register misusing.
>
> The basic problem is described in [1]. Shortly when
> devm_led_classdev_register()
> is used then led_classdev_unregister() called after driver's remove()
> ca
On Thu, Mar 14, 2024 at 10:46 AM George Stark wrote:
>
> This driver wants to keep its LEDs state after module is removed
> and implemented it in its own way. LED subsystem supports dedicated
> flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
> instead of custom implementation.
So
On Thu, Mar 14, 2024 at 10:46 AM George Stark wrote:
>
> Using of devm API leads to a certain order of releasing resources.
> So all dependent resources which are not devm-wrapped should be deleted
> with respect to devm-release order. Mutex is one of such objects that
> often is bound to other re
Le 14/03/2024 à 09:45, George Stark a écrit :
> Using of devm API leads to a certain order of releasing resources.
> So all dependent resources which are not devm-wrapped should be deleted
> with respect to devm-release order. Mutex is one of such objects that
> often is bound to other resources
Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> From: Peter Xu
>
> This API is not used anymore, drop it for the whole tree.
>
> Signed-off-by: Peter Xu
> ---
> arch/arm/mm/Makefile | 1 -
> arch/arm/mm/hugetlbpage.c | 29 -
Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> From: Peter Xu
>
> Now after we're sure all pXd_huge() definitions are the same as pXd_leaf(),
> reuse it. Luckily, pXd_huge() isn't widely used.
>
> Signed-off-by: Peter Xu
> ---
> arch/arm/include/asm/pgtable-3level.h | 2 +-
> arch/a
This driver wants to keep its LEDs state after module is removed
and implemented it in its own way. LED subsystem supports dedicated
flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
instead of custom implementation.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c | 23
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remov
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remov
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no own devm wrapping.
Since mutex_destroy() actu
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
This patch series fixes the problem of devm_led_classdev_register misusing.
The basic problem is described in [1]. Shortly when devm_led_classdev_register()
is used then led_classdev_unregister() called after driver's remove() callback.
led_classdev_unregister() calls driver's brightness_set callb
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> From: Peter Xu
>
> PowerPC book3s 4K mostly has the same definition on both, except pXd_huge()
> constantly returns 0 for hash MMUs. As Michael Ellerman pointed out [1],
> it is safe to check _PAGE_PTE on hash MMUs, as the bit will never be
Hi Günter,
On Tue, Mar 12, 2024 at 6:06 PM Guenter Roeck wrote:
> Add name of functions triggering warning backtraces to the __bug_table
> object section to enable support for suppressing WARNING backtraces.
>
> To limit image size impact, the pointer to the function name is only added
> to the _
"core_init_notifier" flag is set by the glue drivers requiring refclk from
the host to complete the DWC core initialization. Also, those drivers will
send a notification to the EPF drivers once the initialization is fully
completed using the pci_epc_init_notify() API. Only then, the EPF drivers
wil
Currently, dw_pcie_ep_init_registers() API is directly called by the glue
drivers requiring active refclk from host. But for the other drivers, it is
getting called implicitly by dw_pcie_ep_init(). This is due to the fact
that this API initializes DWC EP specific registers and that requires an
acti
The goal of the dw_pcie_ep_init_complete() API is to initialize the DWC
specific registers post registering the controller with the EP framework.
But the naming doesn't reflect its functionality and causes confusion. So,
let's rename it to dw_pcie_ep_init_registers() to make it clear that it
initi
For DWC glue drivers supporting PERST# (currently Qcom and Tegra194), some
of the DWC resources like eDMA should be cleaned up during the PERST#
assert time.
So let's introduce a dw_pcie_ep_cleanup() API that could be called by these
drivers to cleanup the DWC specific resources. Currently, it jus
dw_pcie_ep_exit() API is undoing what the dw_pcie_ep_init() API has done
already (at least partly). But the API name dw_pcie_ep_exit() is not quite
reflecting that. So let's rename it to dw_pcie_ep_deinit() to make the
purpose of this API clear. This also aligns with the DWC host driver.
Reviewed-
deinit() callback was solely introduced for the pcie-rcar-gen4 driver where
it is used to do platform specific resource deallocation. And this callback
is called right at the end of the dw_pcie_ep_exit() API. So it doesn't
matter whether it is called within or outside of dw_pcie_ep_exit() API.
So
All of the APIs are missing the Kernel-doc comments. Hence, add them.
Reviewed-by: Frank Li
Signed-off-by: Manivannan Sadhasivam
---
drivers/pci/controller/dwc/pcie-designware-ep.c | 78 +
1 file changed, 78 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-des
The DWC glue drivers requiring an active reference clock from the PCIe host
for initializing their PCIe EP core, set a flag called 'core_init_notifier'
to let DWC driver know that these drivers need a special attention during
initialization. In these drivers, access to the hw registers (like DBI)
b
Hello,
This series is the continuation of previous work by Vidya Sagar [1] to fix the
issues related to accessing DBI register space before completing the core
initialization in some EP platforms like Tegra194/234 and Qcom EP.
Since Vidya is busy, I took over the series based on his consent (off-
On Fri, Mar 08, 2024 at 11:22:52AM +0100, Niklas Cassel wrote:
> On Fri, Mar 08, 2024 at 03:19:47PM +0530, Manivannan Sadhasivam wrote:
> > > > > > @@ -467,6 +467,13 @@ static int dra7xx_add_pcie_ep(struct
> > > > > > dra7xx_pcie *dra7xx,
> > > > > > return ret;
> > > > > > }
> > >
On Tue, 12 Mar 2024 at 22:33, Guenter Roeck wrote:
> This series is based on the RFC patch and subsequent discussion at
> https://patchwork.kernel.org/project/linux-kselftest/patch/02546e59-1afe-4b08-ba81-d94f3b691c9a@moroto.mountain/
> and offers a more comprehensive solution of the problem di
Hi Michael,
On Thu, 14 Mar 2024 10:05:37 +1100
Michael Ellerman wrote:
> Hi Herve,
>
> Herve Codina writes:
...
> This breaks when building as a module (eg. ppc32_allmodconfig):
>
> In file included from ../include/linux/device/driver.h:21,
>from ../include/linux/device.
76 matches
Mail list logo
