> On Tue, Jan 9, 2024 at 9:58 AM Chancel Liu wrote:
> >
> > Add compatible string "fsl,imx95-micfil" for i.MX95 platform.
> >
> > Signed-off-by: Chancel Liu
> > ---
> > .../devicetree/bindings/sound/fsl,micfil.yaml | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
>
On Tue, Jan 09, 2024 at 04:55:51PM +0900, Chancel Liu wrote:
> Add compatible string "fsl,imx95-micfil" for i.MX95 platform.
>
> Signed-off-by: Chancel Liu
> ---
> .../devicetree/bindings/sound/fsl,micfil.yaml | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff
On Tue, Jan 09, 2024 at 03:16:30PM -0700, Nathan Chancellor wrote:
> reviews.llvm.org was LLVM's Phabricator instances for code review. It
> has been abandoned in favor of GitHub pull requests. While the majority
> of links in the kernel sources still work because of the work Fangrui
> has done tur
On Tue, Jan 09, 2024 at 12:39:36PM -0600, Segher Boessenkool wrote:
> On Tue, Jan 09, 2024 at 03:15:35PM +, Christophe Leroy wrote:
> > > CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
> > > endif
> > > endif
> > > -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium
All supported compilers today (gcc v5.1+ and clang v11+) have support for
-mcmodel=medium. As such, NO_MINIMAL_TOC is no longer being set. Remove
NO_MINIMAL_TOC as well as the fallback to -mminimal-toc.
Reviewed-by: Christophe Leroy
Signed-off-by: Naveen N Rao
---
v2: Drop the call to cc-option
On Wed, 27 Dec 2023 17:42:00 PST (-0800), samuel.holl...@sifive.com wrote:
This is motivated by the amdgpu DRM driver, which needs floating-point
code to support recent hardware. That code is not performance-critical,
so only provide a minimal non-preemptible implementation for now.
Signed-off-b
(cc Muchun)
On Wed, 10 Jan 2024 14:03:35 +0530 Donet Tom
wrote:
> The kernel sefltest mm/hugepage-vmemmap fails on architectures
> which has different page size other than 4K. In hugepage-vmemmap
> page size used is 4k so the pfn calculation will go wrong on systems
> which has different page si
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 h
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 h
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 h
Hello,
this series converts all drivers below drivers/macintosh to use
.remove_new(). See commit 5c5a7680e67b ("platform: Provide a remove
callback that returns no value") for an extended explanation and the
eventual goal. The TL;DR; is to make it harder for driver authors to
leak resources withou
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 h
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 h
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 h
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 h
The kernel sefltest mm/hugepage-vmemmap fails on architectures
which has different page size other than 4K. In hugepage-vmemmap
page size used is 4k so the pfn calculation will go wrong on systems
which has different page size .The length of MAP_HUGETLB memory must
be hugepage aligned but in hugepa
On Wed, Nov 8, 2023 at 2:01 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The prototype was hidden in an #ifdef on x86, which causes a warning:
>
> kernel/irq_work.c:72:13: error: no previous prototype for
> 'arch_irq_work_raise' [-Werror=missing-prototypes]
This issue is now present upstre
On Wed, Jan 10, 2024, at 10:03, Geert Uytterhoeven wrote:
> On Wed, Nov 8, 2023 at 2:01 PM Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> The prototype was hidden in an #ifdef on x86, which causes a warning:
>>
>> kernel/irq_work.c:72:13: error: no previous prototype for
>> 'arch_irq_work_rai
When a PCI device is Dynamically added, LPAR OOPS with NULL pointer
exception.
Complete stack is as below
[ 211.239206] BUG: Kernel NULL pointer dereference on read at 0x0030
[ 211.239210] Faulting instruction address: 0xc06bbe5c
[ 211.239214] Oops: Kernel access of bad area, sig:
On Tue, Jan 09, 2024 at 03:16:28PM -0700, Nathan Chancellor wrote:
> This series updates all instances of LLVM Phabricator and Bugzilla links
> to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue
> shortlinks respectively.
>
> I split up the Phabricator patch into BPF selftests
> On Jan 10, 2024, at 23:53, Andrew Morton wrote:
>
> (cc Muchun)
> On Wed, 10 Jan 2024 14:03:35 +0530 Donet Tom
> wrote:
>
>> The kernel sefltest mm/hugepage-vmemmap fails on architectures
>> which has different page size other than 4K. In hugepage-vmemmap
>> page size used is 4k so the pf
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 suggests OS reissue these HCALLs after 1 or 10ms
On 1/9/24 2:16 PM, Nathan Chancellor wrote:
reviews.llvm.org was LLVM's Phabricator instances for code review. It
has been abandoned in favor of GitHub pull requests. While the majority
of links in the kernel sources still work because of the work Fangrui
has done turning the dynamic Phabricato
23 matches
Mail list logo
