after hot remove a pcie deivce with pci_dn having pnp_php driver attached,
pci rescan with echo 1 > /sys/bus/pci/rescan could fail with error
message like:
pci 0020:0e:00.0: BAR 0: assigned [mem 0x3fe80182-0x3fe80182
64bit]
nvme nvme1: pci function 0020:0e:00.0
nvme 0020:0e:00.0
Hi all,
After merging the mm tree, today's linux-next build (powerpc allyesconfig)
produced this warning:
arch/powerpc/kernel/swsusp_64.c:14:6: warning: no previous prototype for
'do_after_copyback' [-Wmissing-prototypes]
14 | void do_after_copyback(void)
| ^
On Tue Nov 28, 2023 at 10:59 AM AEST, Michael Ellerman wrote:
> Christophe Leroy writes:
> > Le 27/11/2023 à 19:39, Timothy Pearson a écrit :
> >> Just wanted to check back and see if this patch was going to be
> >> queued up soon? We're still having to work around / advertise the
> >> data
Christophe Leroy writes:
> Le 27/11/2023 à 19:39, Timothy Pearson a écrit :
>> Just wanted to check back and see if this patch was going to be
>> queued up soon? We're still having to work around / advertise the
>> data destruction issues the underlying bug is causing on e.g. Debian
>> Stable.
>
);
}
#ifdef CONFIG_PCI_IOV
---
base-commit: 0d555b57ee660d8a871781c0eebf006e855e918d
change-id: 20231127-rtas-pci-rw-config-20a5610f2d35
Best regards,
--
Nathan Lynch
Timothy Pearson writes:
> Just wanted to check back and see if this patch was going to be queued
> up soon? We're still having to work around / advertise the data
> destruction issues the underlying bug is causing on e.g. Debian
> Stable.
Yeah I'll apply it this week, so it will be in rc4.
I
On Wed, 2023-11-22 at 13:48 +0100, Christian Brauner wrote:
> Ever since the evenfd type was introduced back in 2007 in commit
s/evenfd/eventfd/
> e1ad7468c77d ("signal/timer/event: eventfd core") the
> eventfd_signal()
> function only ever passed 1 as a value for @n. There's no point in
>
In the opal_prd_range_is_valid function within opal-prd.c,
error handling was missing for the of_get_address call.
This patch adds necessary error checking, ensuring that the
function gracefully handles scenarios where of_get_address fails.
Signed-off-by: Haoran Liu
---
Naresh Kamboju writes:
> Following Powerpc maple_defconfig and other builds failed with gcc-13 / 8
> and clang toolchains on Linux next-20231127 tag.
>
> build:
> * gcc-8-cell_defconfig
> * gcc-8-maple_defconfig
> * gcc-8-tinyconfig
> * gcc-13-t
Hi,
Le 27/11/2023 à 19:39, Timothy Pearson a écrit :
> Just wanted to check back and see if this patch was going to be queued up
> soon? We're still having to work around / advertise the data destruction
> issues the underlying bug is causing on e.g. Debian Stable.
>
Has any agreement been
> > >
> > > > With regards to future directions that likely won't work for loosening
> > > > it:
> > > > Unfortunately, the .rmeta format itself is not stable, so I wouldn't
> > > > want to
> > > > teach genksyms to open it up and split out the pieces for specific
> > > > functions.
> > > >
Just wanted to check back and see if this patch was going to be queued up soon?
We're still having to work around / advertise the data destruction issues the
underlying bug is causing on e.g. Debian Stable.
Thanks!
On Wed, 22 Nov 2023 15:44:19 -0700, Rob Herring wrote:
> Drop unneeded quotes over simple string values to fix a soon to be
> enabled yamllint warning:
>
> [error] string value is redundantly quoted with any quotes (quoted-strings)
>
> Signed-off-by: Rob Herring
> ---
>
On Mon, 27 Nov 2023 at 02:27, Christian Brauner wrote:
>
> So I've picked up your patch (vfs.misc). It's clever alright so thanks
> for the comments in there otherwise I would've stared at this for far
> too long.
Note that I should probably have commented on one other thing: that
whole "just
Acked-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Em Mon, Nov 27, 2023 at 11:12:57AM +, James Clark escreveu:
> On 23/11/2023 16:02, Athira Rajeev wrote:
> > Add rule in new Makefile "tests/Makefile.tests" for running
> > shellcheck on shell test scripts. This automates below shellcheck
> > into the build.
> Seems to work really well. I also
On Mon, Nov 27, 2023 at 11:57:18AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> The following commit is also in the powerpc tree as a different commit
> (but the same patch):
>
> aa46b225ebbf ("tty: hvc: hvc_opal: Convert to platform remove callback
> returning void")
>
> This is commit
>
>
Haren Myneni writes:
> Move the RTAS delay sleep code to new rtas_busy_sleep(). It can
> be called from HCALL delay code that needs to support both usleep()
> or msleep() depends on delay value.
While there may be some future utility in factoring out the code that
handles extended delay
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on
The ps3fb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-dev@lists.ozlabs.org
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
On 23/11/23 9:31 pm, Athira Rajeev wrote:
Running "perf list" on powerpc fails with segfault
as below:
./perf list
Segmentation fault (core dumped)
This happens because of duplicate events in the json list.
The powerpc Json event list contains some event with same
event name, but
Hello,
On Mon, Nov 27, 2023 at 10:00:58PM +1100, Michael Ellerman wrote:
> Stephen Rothwell writes:
> > Hi all,
> >
> > Today's linux-next merge of the tty tree got a conflict in:
> >
> > drivers/tty/hvc/hvc_console.h
> >
> > between commit:
> >
> > c9e38dc90e1c ("tty: hvc: Make hvc_remove()
The IPR driver has a routine to check whether it's running on certain
CPU versions and if so whether the adapter is supported on that CPU.
But none of the CPUs it checks for are supported by Linux anymore.
The most recent CPU it checks for is Power4+ which was removed in commit
471d7ff8b51b
On 11/2/23 16:46, Paolo Bonzini wrote:
> On Thu, Nov 2, 2023 at 4:38 PM Sean Christopherson wrote:
>> Actually, looking that this again, there's not actually a hard dependency on
>> THP.
>> A THP-enabled kernel _probably_ gives a higher probability of using
>> hugepages,
>> but mostly because
On 23/11/2023 16:02, Athira Rajeev wrote:
> Add rule in new Makefile "tests/Makefile.tests" for running
> shellcheck on shell test scripts. This automates below shellcheck
> into the build.
>
Seems to work really well. I also tested it on Ubuntu, and checked
NO_SHELLCHECK, cleaning and with
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the tty tree got a conflict in:
>
> drivers/tty/hvc/hvc_console.h
>
> between commit:
>
> c9e38dc90e1c ("tty: hvc: Make hvc_remove() return no value")
>
> from the powerpc tree and commit:
>
> 7f30c19caf94 ("tty: hvc: Make
> So that nobody else would waste any time on this, attached is a new
> attempt. This time actually tested *after* the changes.
So I've picked up your patch (vfs.misc). It's clever alright so thanks
for the comments in there otherwise I would've stared at this for far
too long.
It's a little
Following Powerpc maple_defconfig and other builds failed with gcc-13 / 8
and clang toolchains on Linux next-20231127 tag.
build:
* gcc-8-cell_defconfig
* gcc-8-maple_defconfig
* gcc-8-tinyconfig
* gcc-13-tinyconfig
* gcc-13-cell_defconfig
* gcc-13-maple_defconfig
> I took a look at the code generation, and honestly, I think we're
> better off just making __fget_files_rcu() have special logic for this
> all, and not use __get_file_rcu().
My initial massaging of the patch did that btw. Then I sat there
wondering whether it would matter if we just made it
On 23. 11. 23, 21:19, Greg KH wrote:
On Tue, Nov 21, 2023 at 10:22:41AM +0100, Jiri Slaby (SUSE) wrote:
This is a series to fix/clean up some obvious issues I revealed during
u8+size_t conversions (to be posted later).
I applied most of these except the last few, as I think you were going
to
VAS allocate, modify and deallocate HCALLs returns
H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC for busy
delay and expects OS to reissue HCALL after that delay. But using
msleep() will often sleep at least 20 msecs even though the
hypervisor expects to reissue these HCALLs after 1 or
Move the RTAS delay sleep code to new rtas_busy_sleep(). It can
be called from HCALL delay code that needs to support both usleep()
or msleep() depends on delay value.
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/rtas.h | 1 +
arch/powerpc/kernel/rtas.c | 56
33 matches
Mail list logo
