Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 9 Apr 2024 11:12:04 +0200 you wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error
Hi Michael,
After checking the definition of modalias in modalias_show(), I think it's
better to keep the
same logic in vio_hotplug(), that's removing the else part in my original
patch shown below.
+ if (dn && (cp = of_get_property(dn, "compatible", NULL))
+
We noticed the following nuisance messages during boot process
[7.120610][ T1060] vio vio: uevent: failed to send synthetic uevent
[7.122281][ T1060] vio 4000: uevent: failed to send synthetic uevent
[7.122304][ T1060] vio 4001: uevent: failed to send synthetic uevent
[7.122324][
On Thu, 2024-04-04 at 06:14 +, Christophe Leroy wrote:
>
>
> Le 04/04/2024 à 06:45, Rohan McLure a écrit :
> > Arbitrary instrumented locations, including syscall handlers, can
> > call
> > arch_local_irq_restore() transitively when KCSAN is enabled, and in
> > turn
> > also
allyesconfig
>>>> and allmodconfig. Tested with next-20240410.
>>
>>
>>
>>> In both cases, the issue is that the toolchain requires runtime support to
>>> convert between `unsigned long long` and `double`, even when hardware FP is
>>> enabled. There
On 2024/4/11 1:28, Alexandre Ghiti wrote:
On 10/04/2024 10:07, Kefeng Wang wrote:
On 2024/4/10 15:32, Alexandre Ghiti wrote:
Hi Kefeng,
On 03/04/2024 10:38, Kefeng Wang wrote:
The access_error() of vma already checked under per-VMA lock, if it
is a bad access, directly handle error, no
Hi Thiago,
On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
> Samuel Holland writes:
>> On 2024-04-10 5:21 PM, Thiago Jung Bauermann wrote:
>>>
>>> Unfortunately this patch causes build failures on arm with allyesconfig
>>> and allmodconfig. Tested wit
Hello Samuel,
Thank you for the quick reply!
Samuel Holland writes:
> On 2024-04-10 5:21 PM, Thiago Jung Bauermann wrote:
>>
>> Unfortunately this patch causes build failures on arm with allyesconfig
>> and allmodconfig. Tested with next-20240410.
>
On Wed, 10 Apr 2024, Michael Ellerman wrote:
> >
> > Could we do something similar, write a message at boottime when the
> > CXL driver gets probed ?
>
> Yeah, I think so.
>
> There's still the problem that people tend not to look at dmesg until
> something breaks, but at least we can try
can also take advantage of the
>> common kernel-mode FPU API and method of adjusting CFLAGS.
>>
>> Acked-by: Alex Deucher
>> Reviewed-by: Christoph Hellwig
>> Signed-off-by: Samuel Holland
>
> Unfortunately this patch causes build failures on arm with allyesconf
of adjusting CFLAGS.
>
> Acked-by: Alex Deucher
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Samuel Holland
Unfortunately this patch causes build failures on arm with allyesconfig
and allmodconfig. Tested with next-20240410.
Error with allyesconfig:
$ make -j 8 \
O=$HOME/.cach
On 4/10/2024 7:33 AM, lizhe wrote:
Hi，
i have already change the definition of exit
in struct cpu_freq_driver in include/linux/cpufreq.h
Again, no top-posting and please use HTML. The patch you sent does not
indicate that include/linux/cpufreq.h has been updated, so maybe you
Hi，
i have already change the definition of exit
in struct cpu_freq_driver in include/linux/cpufreq.h
Lizhe
Thanks
Hi，
I have already tested it, it is functioning properly, Please review.
Lizhe
Thanks
For the exit() callback function returning an int type value.
this leads many driver authors mistakenly believing that error
handling can be performed by returning an error code. However.
the returned value is ignore, and to improve this situation.
it is proposed to modify the return type of the
For the exit() callback function returning an int type value.
this leads many driver authors mistakenly believing that error
handling can be performed by returning an error code. However.
the returned value is ignore, and to improve this situation.
it is proposed to modify the return type of the
On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote:
> Please review! Also feel free to take the KVM patches through the mm
> tree, as I don't expect any conflicts.
It's mainly a KVM thing and the MM changes are small and simple.
I'd say that the KVM tree would be a better home?
On Wed, Apr 10, 2024 at 04:30:41PM +, Christophe Leroy wrote:
>
>
> Le 10/04/2024 à 17:28, Peter Xu a écrit :
> > On Tue, Apr 09, 2024 at 08:43:55PM -0300, Jason Gunthorpe wrote:
> >> On Fri, Apr 05, 2024 at 05:42:44PM -0400, Peter Xu wrote:
> >>> In short, hugetlb mappings shouldn't be
On 10/04/2024 10:07, Kefeng Wang wrote:
On 2024/4/10 15:32, Alexandre Ghiti wrote:
Hi Kefeng,
On 03/04/2024 10:38, Kefeng Wang wrote:
The access_error() of vma already checked under per-VMA lock, if it
is a bad access, directly handle error, no need to retry with mmap_lock
again. Since the
m/
> Signed-off-by: Adrian Hunter
This patch applied on top of today's Linux next-20240410 tag and
build test pass.
Tested-by: Linux Kernel Functional Testing
> ---
> include/asm-generic/bug.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
--
Linaro LKFT
https://lkft.linaro.org
On Wed, Apr 10, 2024 at 11:31 AM Christophe Leroy
wrote:
>
>
>
> Le 10/04/2024 à 17:22, Joel Savitz a écrit :
> > [Vous ne recevez pas souvent de courriers de jsav...@redhat.com. Découvrez
> > pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification
> > ]
> >
> > On Mon, Apr
Le 10/04/2024 à 17:28, Peter Xu a écrit :
> On Tue, Apr 09, 2024 at 08:43:55PM -0300, Jason Gunthorpe wrote:
>> On Fri, Apr 05, 2024 at 05:42:44PM -0400, Peter Xu wrote:
>>> In short, hugetlb mappings shouldn't be special comparing to other huge pXd
>>> and large folio (cont-pXd) mappings for
BUG() does not return, and arch implementations of BUG() use unreachable()
or other non-returning code. However with !CONFIG_BUG, the default
implementation is often used instead, and that does not do that. x86 always
uses its own implementation, but powerpc with !CONFIG_BUG gives a build
error:
Le 10/04/2024 à 17:22, Joel Savitz a écrit :
> [Vous ne recevez pas souvent de courriers de jsav...@redhat.com. Découvrez
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> On Mon, Apr 1, 2024 at 10:17 AM Joel Savitz wrote:
>>
>> On Tue, Mar 26, 2024 at 12:45
On Tue, Apr 09, 2024 at 08:43:55PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 05, 2024 at 05:42:44PM -0400, Peter Xu wrote:
> > In short, hugetlb mappings shouldn't be special comparing to other huge pXd
> > and large folio (cont-pXd) mappings for most of the walkers in my mind, if
> > not all.
> > > out_8(>i2c_reg->i2mod, 0x00);
> > > - out_8(>i2c_reg->i2com, I2COM_MASTER); /* Master mode */
> > > + out_8(>i2c_reg->i2com, I2COM_MASTER); /* Host mode */
> >
> > I2COM_MASTER might be coming from the datasheet.
>
> Maybe we can just drop the comment? The value we write is
On Mon, Apr 1, 2024 at 10:17 AM Joel Savitz wrote:
>
> On Tue, Mar 26, 2024 at 12:45 AM Joel Savitz wrote:
> >
> > On Fri, Mar 8, 2024 at 5:18 AM Aneesh Kumar K.V
> > wrote:
> > >
> > > Joel Savitz writes:
> > >
> > > > On 64-bit powerpc, usage of a non-16MB-aligned value for the mem= kernel
Hi All,
There are no changes since the last post, just a re-send.
v2:
- patch 4: commit message reworded (Heiko)
- patch 5: vtime.h is removed from Kbuild scripts (PowerPC only) (Heiko)
v1:
Please find a small cleanup to vtime_task_switch() wiring.
I split it into smaller patches to allow
__ARCH_HAS_VTIME_TASK_SWITCH macro is not used anymore.
Reviewed-by: Frederic Weisbecker
Acked-by: Heiko Carstens
Acked-by: Nicholas Piggin
Signed-off-by: Alexander Gordeev
---
arch/s390/include/asm/vtime.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/s390/include/asm/vtime.h
Callback arch_vtime_task_switch() is only defined when
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is selected. Yet, the
function prototype forward declaration is present for
CONFIG_VIRT_CPU_ACCOUNTING_GEN variant. Remove it.
Reviewed-by: Frederic Weisbecker
Reviewed-by: Nicholas Piggin
Signed-off-by:
update_timer_sys() and update_timer_mcck() are inlines used for
CPU time accounting from the interrupt and machine-check handlers.
These routines are specific to s390 architecture, but included
via header implicitly. Avoid the extra loop and
include header directly.
Acked-by: Heiko Carstens
There is no architecture-specific code or data left
that generic needs to know about.
Thus, avoid the inclusion of header.
Reviewed-by: Frederic Weisbecker
Acked-by: Nicholas Piggin
Signed-off-by: Alexander Gordeev
---
arch/powerpc/include/asm/Kbuild | 1 -
include/asm-generic/vtime.h |
The generic vtime_task_switch() implementation gets built only
if __ARCH_HAS_VTIME_TASK_SWITCH is not defined, but requires an
architecture to implement arch_vtime_task_switch() callback at
the same time, which is confusing.
Further, arch_vtime_task_switch() is implemented for 32-bit PowerPC
On Wed, Apr 10 2024 at 14:45, Bitao Hu wrote:
> On 2024/4/9 17:58, Thomas Gleixner wrote:
> By the way, what do you think of my reason for using printk() instead of
> pr_crit()? Should I change this part of the code in v13?
Either way is fine. Just put a proper explanation into the change log if
Le 10/04/2024 à 15:42, lizhe a écrit :
>
> Hi，
> I have already tested it, it is functioning properly, Please review.
>
> *Lizhe*
>
> Thanks
>
Please don't top-post, see
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
On Wed, 2024-04-10 at 10:00 +0530, Mahesh Salgaonkar wrote:
> nmi_enter()/nmi_exit() touches per cpu variables which can lead to
> kernel
> crash when invoked during real mode interrupt handling (e.g. early
> HMI/MCE
> interrupt handler) if percpu allocation comes from vmalloc area.
>
> Early
Christophe Leroy writes:
> Le 09/04/2024 à 06:37, Michael Ellerman a écrit :
>> Andrew Donnellan writes:
>>> The cxl driver is no longer actively maintained and we intend to remove it
>>> in a future kernel release. Change its status to obsolete, and update the
>>> sysfs ABI documentation
On Wed, 03 Apr 2024 10:06:18 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Compilers traditionally warn for unused 'static' variables, but not
> if they are constant. The reason here is a custom for C++ programmers
> to define named constants as 'static const' variables in header files
t; Greg also picked it up, it's fbdd90334a6205e8a99d0bc2dfc738ee438f00bc in
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus
> . Both are included in next-20240410. I guess that's not a big problem.
> (And please prevent that the patch is dropped from both trees as
On 2024/4/10 15:32, Alexandre Ghiti wrote:
Hi Kefeng,
On 03/04/2024 10:38, Kefeng Wang wrote:
The access_error() of vma already checked under per-VMA lock, if it
is a bad access, directly handle error, no need to retry with mmap_lock
again. Since the page faut is handled under per-VMA lock,
Hi Kefeng,
On 03/04/2024 10:38, Kefeng Wang wrote:
The access_error() of vma already checked under per-VMA lock, if it
is a bad access, directly handle error, no need to retry with mmap_lock
again. Since the page faut is handled under per-VMA lock, count it as
a vma lock event with
Hi Ahmad,
> -Original Message-
> From: Ahmad Fatoum
> Sent: Tuesday, April 9, 2024 10:58 PM
> To: Kshitiz Varshney ; David Gstir
> ; Mimi Zohar ; James
> Bottomley ; Jarkko Sakkinen ;
> Herbert Xu ; David S. Miller
>
> Cc: linux-...@vger.kernel.org; Gaurav Jain ; Catalin
> Marinas ;
Hi,
On 2024/4/9 17:58, Thomas Gleixner wrote:
This does not apply anymore.
OK, I will update this patch based on the latest kernel code.
Also can you please split this apart to convert kstat_irqs to a struct
with just the count in it and then add the snapshot mechanics on top.
OK, I will
nel/git/gregkh/usb.git usb-linus
. Both are included in next-20240410. I guess that's not a big problem.
(And please prevent that the patch is dropped from both trees as it's
already included in the other :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König
45 matches
Mail list logo
