On Wed Nov 6, 2024 at 4:50 PM EET, Rob Herring wrote:
> On Thu, Jul 18, 2024 at 11:01 AM Jarkko Sakkinen
> wrote:
> >
> > On Thu Jul 18, 2024 at 5:57 PM EEST, Rob Herring wrote:
> > > On Wed, Jul 17, 2024 at 6:14 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > On Wed Jul 17, 2024 at 3:08 PM EES
On Wed Nov 6, 2024 at 8:17 PM EET, Jarkko Sakkinen wrote:
> > Whatever happened to this? Can you please apply my patch if you don't
> > have the time for further rework.
>
> Sorry unintentional.
>
> I applied with
>
> -static void __iomem * atmel_get_base_addr(unsigned long *base, int
> *region_si
On 2024-11-06 3:02 p.m., Oliver Upton wrote:
> On Wed, Nov 06, 2024 at 11:03:10AM -0500, Liang, Kan wrote:
>>> +static unsigned long common_misc_flags(struct pt_regs *regs)
>>> +{
>>> + if (regs->flags & PERF_EFLAGS_EXACT)
>>> + return PERF_RECORD_MISC_EXACT_IP;
>>> +
>>> + return
On 2024-11-06 2:53 p.m., Oliver Upton wrote:
> On Wed, Nov 06, 2024 at 11:07:53AM -0500, Liang, Kan wrote:
>>> +#ifndef perf_arch_guest_misc_flags
>>> +static inline unsigned long perf_arch_guest_misc_flags(struct pt_regs
>>> *regs)
>>> +{
>>> + unsigned long guest_state = perf_guest_state();
On Wed, Nov 06, 2024 at 03:33:30PM -0500, Liang, Kan wrote:
> On 2024-11-06 3:02 p.m., Oliver Upton wrote:
> > On Wed, Nov 06, 2024 at 11:03:10AM -0500, Liang, Kan wrote:
> >>> +static unsigned long common_misc_flags(struct pt_regs *regs)
> >>> +{
> >>> + if (regs->flags & PERF_EFLAGS_EXACT)
> >>>
On Wed, Nov 06, 2024 at 11:07:53AM -0500, Liang, Kan wrote:
> > +#ifndef perf_arch_guest_misc_flags
> > +static inline unsigned long perf_arch_guest_misc_flags(struct pt_regs
> > *regs)
> > +{
> > + unsigned long guest_state = perf_guest_state();
> > +
> > + if (guest_state & PERF_GUEST_USER)
On Wed, Nov 06, 2024 at 11:03:10AM -0500, Liang, Kan wrote:
> > +static unsigned long common_misc_flags(struct pt_regs *regs)
> > +{
> > + if (regs->flags & PERF_EFLAGS_EXACT)
> > + return PERF_RECORD_MISC_EXACT_IP;
> > +
> > + return 0;
> > +}
> > +
> > +unsigned long perf_arch_guest
Hello,
> Several drivers need to dynamically calculate the size of an binary
> attribute. Currently this is done by assigning attr->size from the
> is_bin_visible() callback.
>
> This has drawbacks:
> * It is not documented.
> * A single attribute can be instantiated multiple times, overwriting t
https://bugzilla.kernel.org/show_bug.cgi?id=219472
Bug ID: 219472
Summary: float point load and store
Product: Platform Specific/Hardware
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
The current implementation of pcie_do_recovery() assumes that the
recovery process is executed on the device that detected the error.
However, the DPC driver currently passes the error port that experienced
the DPC event to pcie_do_recovery().
Use the SOURCE ID register to correctly identify the d
The AER driver has historically avoided reading the configuration space of an
endpoint or RCiEP that reported a fatal error, considering the link to that
device unreliable. Consequently, when a fatal error occurs, the AER and DPC
drivers do not report specific error types, resulting in logs like:
On Thu, Jul 18, 2024 at 11:01 AM Jarkko Sakkinen wrote:
>
> On Thu Jul 18, 2024 at 5:57 PM EEST, Rob Herring wrote:
> > On Wed, Jul 17, 2024 at 6:14 AM Jarkko Sakkinen
> > wrote:
> > >
> > > On Wed Jul 17, 2024 at 3:08 PM EEST, Jarkko Sakkinen wrote:
> > > > On Tue Jul 2, 2024 at 7:10 PM EEST, R
A hwcap feature bit is passed to cpu_has_feature, resulting in testing
for CPU_FTR_MMCRA instead of the 3.1 platform revision.
Fixes: c954b252dee9 ("crypto: powerpc/p10-aes-gcm - Register modules as SIMD")
Reported-by: Nicolai Stange
Signed-off-by: Michal Suchanek
---
arch/powerpc/crypto/aes-gc
On Wed, Nov 06, 2024 at 05:03:39PM +0800, Shuai Xue wrote:
> The AER driver has historically avoided reading the configuration space of an
> endpoint or RCiEP that reported a fatal error, considering the link to that
> device unreliable. Consequently, when a fatal error occurs, the AER and DPC
> dr
On 2024-11-05 2:56 p.m., Colton Lewis wrote:
> Break the assignment logic for misc flags into their own respective
> functions to reduce the complexity of the nested logic.
>
> Signed-off-by: Colton Lewis
> Reviewed-by: Oliver Upton
> ---
> arch/x86/events/core.c| 31
On 2024-11-05 2:56 p.m., Colton Lewis wrote:
> Previously any PMU overflow interrupt that fired while a VCPU was
> loaded was recorded as a guest event whether it truly was or not. This
> resulted in nonsense perf recordings that did not honor
> perf_event_attr.exclude_guest and recorded guest I
Lukas Bulwahn writes:
> From: Lukas Bulwahn
>
> Commit 62f8f307c80e ("powerpc/64: Remove maple platform") removes the
> PPC_MAPLE config as a consequence of the platform’s removal.
>
> The config definition of HW_RANDOM_AMD refers to this removed config option
> in its dependencies.
>
> Remove th
On Wed, 6 Nov 2024 14:04:14 +1100
Stephen Rothwell wrote:
> Hi all,
>
> After merging the ftrace tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/ftrace.h:23,
> from include/linux/kvm_host.h:32,
>
Hi Christophe and Segher,
On Wed, Nov 06, 2024 at 07:37:52AM -0600, Segher Boessenkool wrote:
> On Wed, Nov 06, 2024 at 09:55:58AM +0100, Christophe Leroy wrote:
> > Le 30/10/2024 à 19:41, Nathan Chancellor a écrit :
> > >Under certain conditions, the 64-bit '-mstack-protector-guard' flags may
> >
Starting with Ubuntu 24.04, building the selftests with the big endian
compiler (which defaults to 32-bit) fails with errors:
stack_expansion_ldst.c:178:37: error: format '%lx' expects argument
of type 'long unsigned int', but argument 2 has type 'rlim_t' {aka 'long long
unsigned int'}
subp
Fix some tests which weren't returning an error code from main.
Although these tests only ever return success, they can still fail if
they time out and the harness kills them. If that happens they still
return success to the shell, which is incorrect and confuses the higher
level error reporting.
Currently the mitigation patching test errors out if the kernel is
tainted prior to the test running.
That causes the test to fail unnecessarily if some other test has caused
the kernel to be tainted, or if a proprietary or force module is loaded
for example.
Instead just warn if the kernel is ta
From: Lukas Bulwahn
Commit 62f8f307c80e ("powerpc/64: Remove maple platform") removes the
PPC_MAPLE config as a consequence of the platform’s removal.
The config definition of HW_RANDOM_AMD refers to this removed config option
in its dependencies.
Remove the reference to the removed config opti
Le 30/10/2024 à 19:41, Nathan Chancellor a écrit :
Under certain conditions, the 64-bit '-mstack-protector-guard' flags may
end up in the 32-bit vDSO flags, resulting in build failures due to the
structure of clang's argument parsing of the stack protector options,
which validates the argument
Hi!
On Wed, Nov 06, 2024 at 09:55:58AM +0100, Christophe Leroy wrote:
> Le 30/10/2024 à 19:41, Nathan Chancellor a écrit :
> >Under certain conditions, the 64-bit '-mstack-protector-guard' flags may
> >end up in the 32-bit vDSO flags, resulting in build failures due to the
> >structure of clang's
The count_stcx_fail test runs for close to or just over 2 minutes, which
means it sometimes times out.
That's overkill for a test that just demonstrates some PMU counters
are working. Drop the 64 billion instruction case, to lower the runtime
to ~30s.
Signed-off-by: Michael Ellerman
---
tools/t
The AER driver has historically avoided reading the configuration space of an
endpoint or RCiEP that reported a fatal error, considering the link to that
device unreliable. Consequently, when a fatal error occurs, the AER and DPC
drivers do not report specific error types, resulting in logs like:
Hi Michael,
Le 07/09/2024 à 17:40, Christophe Leroy a écrit :
After the following powerpc commits, all calls to set_memory_...()
functions check returned value.
- Commit 8f17bd2f4196 ("powerpc: Handle error in mark_rodata_ro() and
mark_initmem_nx()")
- Commit f7f18e30b468 ("powerpc/kprobes: Hand
Christophe Leroy writes:
> Hi Michael,
>
> Le 07/09/2024 à 17:40, Christophe Leroy a écrit :
>> After the following powerpc commits, all calls to set_memory_...()
>> functions check returned value.
>> - Commit 8f17bd2f4196 ("powerpc: Handle error in mark_rodata_ro() and
>> mark_initmem_nx()")
>> -
Each of the powerpc selftests runs with a timeout of 2 minutes by
default (see tools/testing/selftests/powerpc/harness.c).
But when tests are run with run_kselftest.sh it uses a timeout of 45
seconds, meaning some tests run OK standalone but fail when run with the
test runner.
So tell run_kselfte
Hello Michael and Hari,
On 05/11/24 13:46, Michael Ellerman wrote:
Hi Sourabh,
Sourabh Jain writes:
From: Hari Bathini
Memory for passing additional parameters to fadump capture kernel
is allocated during subsys_initcall level, using memblock. But
as slab is already available by this time,
ps3_setup_uhc_device() is only called from ps3_setup_ehci_device() and
ps3_setup_ohci_device(), which are both marked __init. Hence replace
the former's __ref marker by __init.
Note that before commit bd721ea73e1f9655 ("treewide: replace obsolete
_refok by __ref"), the function was marked __init_
The header files linux/mem_encrypt.h is included twice in svm.c,
so one inclusion of each can be removed.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=11750
Signed-off-by: Yang Li
---
arch/powerpc/platforms/pseries/svm.c | 1 -
1 file changed, 1 deletion(-)
d
在 2024/11/7 00:39, Keith Busch 写道:
On Wed, Nov 06, 2024 at 05:03:39PM +0800, Shuai Xue wrote:
+int aer_get_device_fatal_error_info(struct pci_dev *dev, struct aer_err_info
*info)
+{
+ int type = pci_pcie_type(dev);
+ int aer = dev->aer_cap;
+ u32 aercc;
+
+ pci_info(d
在 2024/11/7 00:02, Bjorn Helgaas 写道:
On Wed, Nov 06, 2024 at 05:03:39PM +0800, Shuai Xue wrote:
The AER driver has historically avoided reading the configuration space of an
endpoint or RCiEP that reported a fatal error, considering the link to that
device unreliable. Consequently, when a fat
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Mon, 4 Nov 2024 13:01:23 -0800 you wrote:
> Also added a small fix for NVMEM mac addresses.
>
> This was tested as working on a Watchguard T10 device.
>
> Rosen Penev (4):
> net: ucc_geth: use devm for kmemdu
On Tue, Nov 05, 2024 at 12:47:18PM +0800, Luming Yu wrote:
> On Fri, Oct 25, 2024 at 10:50:05AM +0800, Luming Yu wrote:
> > On Thu, Oct 24, 2024 at 04:43:04PM +0800, Luming Yu wrote:
> > > On Wed, Oct 23, 2024 at 12:53:47PM +1100, Michael Ellerman wrote:
> > > > "虞陆铭" writes:
> > > > >>Le 12/10/20
Gautam Menghani writes:
> Running a L2 vCPU (see [1] for terminology) with LPCR_MER bit set and no
> pending interrupts results in that L2 vCPU getting an infinite flood of
> spurious interrupts. The 'if check' in kvmhv_run_single_vcpu() sets the
> LPCR_MER bit if there are pending interrupts.
>
The PE Reset State "0" obtained from RTAS calls
ibm_read_slot_reset_[state|state2] indicates that
the Reset is deactivated and the PE is not in the MMIO
Stopped or DMA Stopped state.
With PE Reset State "0", the MMIO and DMA is allowed for
the PE. The function pseries_eeh_get_state() is currently
This small patch series fixes documentation issues in devicetree bindings,
specifically addressing repeated words and trailing whitespace found using
checkpatch.pl script. No functional changes are included.
Patch 1 fixes repeated words in various binding documents, while patch 2
removes trailing
Fix unintentional word repetitions in devicetree binding documentation:
- usb.txt: Fix repeated "two"
- mvebu-devbus.txt: Fix repeated "from"
- gpio.txt: Fix repeated "Both"
- pinctrl-bindings.txt: Fix repeated "device"
- cavium/bootbus.txt: Fix repeated "one"
These issues were identified using th
Remove trailing whitespace from devicetree binding documentation files:
- regulator/regulator-max77620.txt
- interrupt-controller/nvidia,tegra20-ictlr.txt
- interrupt-controller/msi.txt
No functional changes. Issues detected using checkpatch.pl script.
Signed-off-by: Abhinav Saxena
---
.../devi
> On 5 Nov 2024, at 2:14 AM, Ian Rogers wrote:
>
> On Sun, Nov 3, 2024 at 8:17 PM Athira Rajeev
> wrote:
>>
>>
>>
>>> On 30 Oct 2024, at 5:29 AM, Namhyung Kim wrote:
>>>
>>> Hello,
>>>
>>> On Tue, Oct 22, 2024 at 07:31:56PM +0530, Athira Rajeev wrote:
The "Simple expression parser"
On Wed, 6 Nov 2024 at 05:02, Steven Rostedt wrote:
>
> This fix looks fine to me. How should we handle this when we send our pull
> requests to Linus? I may forgot about this issue, and it also matters who's
> tree goes first.
So just mention the issue in the pull request - preferably on both
sid
arc allnoconfiggcc-14.2.0
arc allyesconfigclang-20
arc axs101_defconfiggcc-14.2.0
archsdk_defconfiggcc-14.2.0
arc randconfig-001-20241106gcc-14.2.0
allnoconfiggcc-14.2.0
arc allyesconfigclang-20
arc axs101_defconfiggcc-14.2.0
archsdk_defconfiggcc-14.2.0
arc randconfig-001-20241106gcc-14.2.0
arc
On Thu, Nov 07, 2024 at 05:05:13AM +0900, Krzysztof Wilczyński wrote:
> Hello,
>
> > Several drivers need to dynamically calculate the size of an binary
> > attribute. Currently this is done by assigning attr->size from the
> > is_bin_visible() callback.
> >
> > This has drawbacks:
> > * It is no
The termno parameter is defined as an unsigned int
in hvc_opal_probe function,So when it output should
be modified to %u format.
Signed-off-by: liujing
diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index 095c33ad10f8..1d2e7f2ce088 100644
--- a/drivers/tty/hvc/hvc_opal.c
On 07. 11. 24, 8:47, Jiri Slaby wrote:
On 07. 11. 24, 8:33, liujing wrote:
The termno parameter is defined as an unsigned int
in hvc_opal_probe(), So the output format should be %u instead of %d.
Signed-off-by: liujing
---
v1 -> V2: Modified the description of commit.
Yet, this is a v2, but
On 07. 11. 24, 8:33, liujing wrote:
The termno parameter is defined as an unsigned int
in hvc_opal_probe(), So the output format should be %u instead of %d.
Signed-off-by: liujing
---
v1 -> V2: Modified the description of commit.
diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_o
From: Hari Bathini
Memory for passing additional parameters to fadump capture kernel
is allocated during subsys_initcall level, using memblock. But
as slab is already available by this time, allocation happens via
the buddy allocator. This may work for radix MMU but is likely to
fail in most case
The param area is a memory region where the kernel places additional
command-line arguments for fadump kernel. Currently, the param memory
area is reserved in fadump kernel if it is above boot_mem_top. However,
it should be reserved if it is below boot_mem_top because the fadump
kernel already rese
On 07. 11. 24, 6:47, liujing wrote:
The termno parameter is defined as an unsigned int
in hvc_opal_probe function,
"The termno parameter is defined as an unsigned int in hvc_opal_probe()."
We place () after function names, then "function" is not needed.
> So when it output should be modified
On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> If booted against an old kernel, it will
> behave as though there is no modversions information.
Huh? This I don't get. If you have the new libkmod and boot
an old kernel, that should just not break becauase well, long
symbols we
Also please fix the subject. See:
git log --oneline drivers/tty/hvc/hvc_opal.c
On 07. 11. 24, 8:10, Jiri Slaby wrote:
On 07. 11. 24, 6:47, liujing wrote:
The termno parameter is defined as an unsigned int
in hvc_opal_probe function,
"The termno parameter is defined as an unsigned int in hvc_o
The termno parameter is defined as an unsigned int
in hvc_opal_probe(), So the output format should be %u instead of %d.
Signed-off-by: liujing
---
v1 -> V2: Modified the description of commit.
diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index 095c33ad10f8..1d2e7f2ce08
While OpenFirmware originally allowed walking parent nodes and default
root values for #address-cells and #size-cells, FDT has long required
explicit values. It's been a warning in dtc for the root node since the
beginning (2005) and for any parent node since 2007. Of course, not all
FDT uses dtc,
>
> > If booted against an old kernel, it will
> > behave as though there is no modversions information.
>
> Huh? This I don't get. If you have the new libkmod and boot
> an old kernel, that should just not break becauase well, long
> symbols were not ever supported properly anyway, so no regressio
Hi!
On Wed, Nov 06, 2024 at 08:21:14AM -0700, Nathan Chancellor wrote:
> > (r2 is the default for -m32, r13 is the default for -m64, it appears
> > that clang does not implement this option at all, it simply checks if
> > you set the default, and explodes if not).
>
> Not sure that I would say it
On Wed, Nov 6, 2024 at 12:19 PM Jarkko Sakkinen wrote:
>
> On Wed Nov 6, 2024 at 8:17 PM EET, Jarkko Sakkinen wrote:
> > > Whatever happened to this? Can you please apply my patch if you don't
> > > have the time for further rework.
> >
> > Sorry unintentional.
> >
> > I applied with
> >
> > -stat
On Wed Nov 6, 2024 at 8:32 PM EET, Rob Herring wrote:
> On Wed, Nov 6, 2024 at 12:19 PM Jarkko Sakkinen wrote:
> >
> > On Wed Nov 6, 2024 at 8:17 PM EET, Jarkko Sakkinen wrote:
> > > > Whatever happened to this? Can you please apply my patch if you don't
> > > > have the time for further rework.
>
Simplify the cell_iommu_get_fixed_address() dma-ranges parsing to use the
for_each_of_range() iterator.
Signed-off-by: Rob Herring (Arm)
---
arch/powerpc/platforms/cell/iommu.c | 49 ++---
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/platfo
Simplify the ppc44x PCI dma-ranges parsing to use the for_each_of_range()
iterator.
Signed-off-by: Rob Herring (Arm)
---
arch/powerpc/platforms/44x/pci.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/44x/pci.c b/arch/powerpc/p
On Wed, Nov 06, 2024 at 05:03:39PM +0800, Shuai Xue wrote:
> +int aer_get_device_fatal_error_info(struct pci_dev *dev, struct aer_err_info
> *info)
> +{
> + int type = pci_pcie_type(dev);
> + int aer = dev->aer_cap;
> + u32 aercc;
> +
> + pci_info(dev, "type :%d\n", type);
> +
> +
Am 03.11.24 um 18:03 schrieb Thomas Weißschuh:
Several drivers need to dynamically calculate the size of an binary
attribute. Currently this is done by assigning attr->size from the
is_bin_visible() callback.
Hi,
i really like your idea of introducing this new callback, it will be very
useful
65 matches
Mail list logo
