Hi Joe,
[...]
> Ideally, the additional newline check below this would use sysfs_emit_at
>
> drivers/pci/pci.c- /*
> drivers/pci/pci.c: * When set by the command line,
> resource_alignment_param will not
> drivers/pci/pci.c- * have a trailing line feed, which is ugly. So
>
On Sat, 2021-05-15 at 05:24 +, Krzysztof Wilczyński wrote:
> The sysfs_emit() and sysfs_emit_at() functions were introduced to make
> it less ambiguous which function is preferred when writing to the output
> buffer in a device attribute's "show" callback [1].
>
> Convert the PCI sysfs object
On Sat, 2021-05-15 at 05:24 +, Krzysztof Wilczyński wrote:
> The sysfs_emit() and sysfs_emit_at() functions were introduced to make
> it less ambiguous which function is preferred when writing to the output
> buffer in a device attribute's "show" callback [1].
>
> Convert the PCI sysfs object
Hello,
[...]
> Reviewed-by: Logan Gunthorpe
Please disregard this "Reviewed-by" from Logan for this version, as I've
forgotten to remove it before sending v2 after pulling patches using b4.
Apologies.
Krzysztof
Only expose the value of the "driver_override" variable through the
corresponding sysfs object when a value is actually set.
Signed-off-by: Krzysztof Wilczyński
---
drivers/pci/pci-sysfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c
At the moment, when the value of the "devspec" sysfs object is read from
the user space there will be no newline present, and the utilities such
as the "cat" command won't display the result of the read correctly in
a shell, as the trailing newline is currently missing.
To fix this, append a
The value of the "resource_alignment" can be specified using a kernel
command-line argument (using the "pci=resource_alignment=") or through
the corresponding sysfs object under the /sys/bus/pci path.
Currently, when the value is set via the kernel command-line argument,
and then subsequently
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to
On Fri, May 14, 2021 at 02:42:00PM -0700, Andrew Morton wrote:
> On Fri, 14 May 2021 11:08:53 + (UTC) Christophe Leroy
> wrote:
>
> > When PUD and/or PMD are folded, those functions are useless
> > and we now have a stub in linux/pgtable.h
>
> OK, help me out here please. What patch does
randconfig-a004-20210514
x86_64 randconfig-a003-20210514
x86_64 randconfig-a001-20210514
x86_64 randconfig-a005-20210514
x86_64 randconfig-a002-20210514
x86_64 randconfig-a006-20210514
i386
-20210514
x86_64 randconfig-a003-20210514
x86_64 randconfig-a001-20210514
x86_64 randconfig-a005-20210514
x86_64 randconfig-a002-20210514
x86_64 randconfig-a006-20210514
i386 randconfig-a003-20210514
i386
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210514
i386 randconfig-a001-20210514
i386
On 5/14/2021 8:12 AM, Ondrej Mosnacek wrote:
> On Wed, May 12, 2021 at 7:12 PM Casey Schaufler
> wrote:
>> On 5/12/2021 9:44 AM, Ondrej Mosnacek wrote:
>>> On Wed, May 12, 2021 at 6:18 PM Casey Schaufler
>>> wrote:
On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote:
> On Sat, May 8, 2021 at
On 5/14/21 12:22 PM, Linus Torvalds wrote:
> On Fri, May 14, 2021 at 11:52 AM Vineet Gupta
> wrote:
>> Wasn't the new zlib code slated for 5.14. I don't see it in your master yet
> You're right, I never actually committed it, since it was specific to
> ARC and -O3
Well, not really, the issue
https://bugzilla.kernel.org/show_bug.cgi?id=213069
Bug ID: 213069
Summary: kernel BUG at
arch/powerpc/include/asm/book3s/64/hash-4k.h:147!
Oops: Exception in kernel mode, sig: 5 [#1]
Product: Platform Specific/Hardware
On 5/14/21 10:32 AM, Linus Torvalds wrote:
> On Fri, May 14, 2021 at 3:02 AM Arnd Bergmann wrote:
>> I've included this version in the asm-generic tree for 5.14 already,
>> addressing the few issues that were pointed out in the RFC. If there
>> are any remaining problems, I hope those can be
hvterm_raw_put_chars() calls hvc_put_chars(), which may return -EAGAIN
when the underlying hcall returns a "busy" status, but udbg_hvc_putc()
doesn't handle this. When using xmon on a PowerVM guest, this can
result in incomplete or garbled output when printing relatively large
amounts of data
On Fri, 14 May 2021 11:08:53 + (UTC) Christophe Leroy
wrote:
> When PUD and/or PMD are folded, those functions are useless
> and we now have a stub in linux/pgtable.h
OK, help me out here please. What patch does this fix?
On 5/14/21 4:10 AM, YueHaibing wrote:
dlpar_memory_remove() is never used, so can be removed.
Signed-off-by: YueHaibing
---
Reviewed-by: Daniel Henrique Barboza
arch/powerpc/platforms/pseries/hotplug-memory.c | 4
1 file changed, 4 deletions(-)
diff --git
On Fri, Apr 30 2021 at 10:03, Cédric Le Goater wrote:
CC: +Marc
> PCI MSI interrupt numbers are now mapped in a PCI-MSI domain but the
> underlying calls handling the passthrough of the interrupt in the
> guest need a number in the XIVE IRQ domain.
>
> Use the IRQ data mapped in the XIVE IRQ
On Fri, Apr 30 2021 at 10:04, Cédric Le Goater wrote:
> The HW IRQ numbers generated by the PCI MSI layer can be quite large
> on a pSeries machine when running under the IBM Hypervisor and they
> appear as negative. Use '%u' to show them correctly.
>
> Cc: Thomas Gleixner
> Signed-off-by: Cédric
On Fri, Apr 30 2021 at 10:03, Cédric Le Goater wrote:
> The MSI affinity is automanaged and it can be set before starting the
> associated IRQ.
>
> ( Should we simply remove the irqd_is_started() test ? )
If the hardware can handle it properly.
But see:
cffb717ceb8e ("powerpc/xive: Ensure
On Fri, May 14, 2021 at 12:45 PM Vineet Gupta
wrote:
>
> Well, not really, the issue manifested in ARC O3 testing, but I showed
> the problem existed for arm64 gcc too.
.. but not with a supported kernel configuration.
> > So in fact it's not even queued up for 5.14 due to this all, I just
On Wed, May 05, 2021 at 10:07:29PM +1000, Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Mon, May 03, 2021 at 01:37:57PM +0200, Andreas Schwab wrote:
> >> Should this add a tag to the module vermagic?
> >
> > Would the modues link even if the vermagic was not changed?
>
> Most modules
On Fri, May 14, 2021 at 7:32 PM Linus Torvalds
wrote:
>
> On Fri, May 14, 2021 at 3:02 AM Arnd Bergmann wrote:
> >
> > I've included this version in the asm-generic tree for 5.14 already,
> > addressing the few issues that were pointed out in the RFC. If there
> > are any remaining problems, I
On Fri, May 14, 2021 at 11:52 AM Vineet Gupta
wrote:
>
> Wasn't the new zlib code slated for 5.14. I don't see it in your master yet
You're right, I never actually committed it, since it was specific to
ARC and -O3 and I wasn't entirely happy with the amount of testing it
got (with Heiko
On Fri, May 14, 2021 at 3:02 AM Arnd Bergmann wrote:
>
> I've included this version in the asm-generic tree for 5.14 already,
> addressing the few issues that were pointed out in the RFC. If there
> are any remaining problems, I hope those can be addressed as follow-up
> patches.
This continues
Log buffer entries that are too long for dump_log_buf()'s small
local buffer are:
* silently discarded when a single-line entry is too long;
kmsg_dump_get_line() returns true but sets to 0.
* silently truncated to the last fitting new line when a multi-line
entry is too long, e.g. register
On Wed, May 12, 2021 at 7:12 PM Casey Schaufler wrote:
>
> On 5/12/2021 9:44 AM, Ondrej Mosnacek wrote:
> > On Wed, May 12, 2021 at 6:18 PM Casey Schaufler
> > wrote:
> >> On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote:
> >>> On Sat, May 8, 2021 at 12:17 AM Casey Schaufler
> >>> wrote:
> On
_switch() saves and restores ALTIVEC and SPE status.
For altivec this is redundant with what __switch_to() does with
save_sprs() and restore_sprs() and giveup_all() before
calling _switch().
Add support for SPI in save_sprs() and restore_sprs() and
remove things from _switch().
Signed-off-by:
On Fri, May 14, 2021 at 1:48 PM Segher Boessenkool
wrote:
> On Fri, May 14, 2021 at 12:00:53PM +0200, Arnd Bergmann wrote:
> > Little-endian POWER7 kernels disable
> > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS because that is not supported on
> > the hardware, but the kernel still uses direct
Hi Arnd,
On Fri, May 14, 2021 at 12:00:53PM +0200, Arnd Bergmann wrote:
> Little-endian POWER7 kernels disable
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS because that is not supported on
> the hardware, but the kernel still uses direct load/store for explicti
> get_unaligned()/put_unaligned().
>
>
On Thu, May 13, 2021 at 05:56:14PM +0530, kajoljain wrote:
> But yes the current read/add/del functions are not adding value. We
> could add an arch/platform specific function which could handle the
> capturing of the counter data and do the rest of the operation here,
> is this approach better?
On Wed, May 05, 2021 at 09:38:49PM +0200, Christophe JAILLET wrote:
> 'rc' is known to be 0 here.
> Initialize 'rc' with the expected error code before using it.
>
> While at it, avoid the affectation of 'rc' in a 'if' to make things more
> obvious and linux style.
>
> Fixes: f204e0b8ce ("cxl:
On Sat, May 08, 2021 at 11:14:55AM +0800, Bixuan Cui wrote:
> This patch adds missing MODULE_DEVICE_TABLE definition which generates
> correct modalias for automatic loading of this driver when it is built
> as an external module.
>
> Reported-by: Hulk Robot
> Signed-off-by: Bixuan Cui
> ---
>
When PUD and/or PMD are folded, those functions are useless
and we now have a stub in linux/pgtable.h
Reported-by: Naresh Kamboju
Signed-off-by: Christophe Leroy
---
arch/arm64/mm/mmu.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git
The LKFT build system detected these build warnings and errors.
Regressions found on parisc:
- build/gcc-9-defconfig
- build/gcc-9-tinyconfig
- build/gcc-10-allnoconfig
- build/gcc-10-tinyconfig
- build/gcc-9-allnoconfig
- build/gcc-10-defconfig
make --silent --keep-going --jobs=8
From: Arnd Bergmann
Little-endian POWER7 kernels disable
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS because that is not supported on
the hardware, but the kernel still uses direct load/store for explicti
get_unaligned()/put_unaligned().
I assume this is a mistake that leads to power7 having to trap
From: Arnd Bergmann
The get_unaligned()/put_unaligned() helpers are traditionally architecture
specific, with the two main variants being the "access-ok.h" version
that assumes unaligned pointer accesses always work on a particular
architecture, and the "le-struct.h" version that casts the data
Hi!
On Fri, May 14, 2021 at 11:42:32AM +0900, Masahiro Yamada wrote:
> In my best guess, the reason why powerpc adding the endian flag to CPP
> is this line in arch/powerpc/kernel/vdso64/vdso64.lds.S
>
> #ifdef __LITTLE_ENDIAN__
> OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle",
interrupt_exit_user_prepare() and interrupt_exit_kernel_prepare()
get msr as second parameter from ASM. Use it instead of reading
it again.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/interrupt.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
Last part of interrupt_exit_user_prepare() and syscall_exit_prepare()
are identical.
Create a __interrupt_exit_user_prepare() function that is called by
both.
Note that it replaces a local_irq_save(flags) by local_irq_disable().
This is similar because the flags are never used. On ppc 8xx it is
Hi All,
The RC1 of kernel 5.13 doesn't boot in a virtual e5500 QEMU machine with
KVM HV anymore. I see in the serial console that the uImage doesn't
load. I use the following QEMU command for booting:
qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel
uImage-5.13 -drive
dlpar_memory_remove() is never used, so can be removed.
Signed-off-by: YueHaibing
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index
Le 23/04/2021 à 12:26, Quentin Monnet a écrit :
2021-04-23 09:19 UTC+0200 ~ Christophe Leroy
[...]
I finally managed to cross compile bpftool with libbpf, libopcodes,
readline, ncurses, libcap, libz and all needed stuff. Was not easy but I
made it.
Libcap is optional and bpftool does
55 matches
Mail list logo
