Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for mbox handle later during rproc start/attach. This also
allows to defer remoteproc driver's probe if mailbox is not probed yet.
Signed-off-by:
From: Masami Hiramatsu (Google)
This cleanup all kprobe events code is not related to the selftest
itself, and it can fail by the reason unrelated to this test.
If the test is successful, the generated events are cleaned up.
And if not, we cannot guarantee that the kprobe events will work
On 18.04.24 08:26, zhenwei pi wrote:
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change is low
OOM: VIRTIO_BALLOON_S_OOM_KILL
trace_pid_list_alloc() checks pid_max against a magic number referencing
an (obsolete) source file when it actually should check against the
capacity of pid_list tree. Turn definition of MAX_PID around -- derive
it from tree parameters and replace references to magic value and
header files with so
On 07/04/2024 11:58, Luca Weiss wrote:
> Set the 'items' correctly for the qcom,halt-regs property and update the
> description to match what it should be.
>
> Signed-off-by: Luca Weiss
> ---
> .../devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml| 6
> +-
> 1 file changed,
Set the 'items' correctly for the qcom,halt-regs property and update the
description to match what it should be.
Signed-off-by: Luca Weiss
---
.../devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml| 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
On Tue, 2 Apr 2024 at 17:47, Konrad Dybcio wrote:
>
> On 31.03.2024 11:10 PM, Dmitry Baryshkov wrote:
> > From: Srinivas Kandagatla
> >
> > The ADSP provides fastrpc/compute capabilities. Enable support for the
> > fastrpc on this DSP.
> >
> > Signed-off-by: Srinivas Kandagatla
> >
On 31.03.2024 11:10 PM, Dmitry Baryshkov wrote:
> From: Srinivas Kandagatla
>
> The ADSP provides fastrpc/compute capabilities. Enable support for the
> fastrpc on this DSP.
>
> Signed-off-by: Srinivas Kandagatla
> Signed-off-by: Dmitry Baryshkov
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi
Fix a small typo in the smatch documentation about the patch submission
process.
Signed-off-by: Javier Carrasco
---
Documentation/submitting-patches.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/submitting-patches.md
b/Documentation/submitting-patches.md
From: Srinivas Kandagatla
The ADSP provides fastrpc/compute capabilities. Enable support for the
fastrpc on this DSP.
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 57 +++
1 file changed, 57
This header no longer used, remove this include.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 8f50ab80e56f4..bde04e3e6d966 100644
---
On 3/19/24 12:25 AM, Krzysztof Kozlowski wrote:
> On 19/03/2024 02:06, Tanmay Shah wrote:
>>
>>
>> On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
>>> On 15/03/2024 22:15, Tanmay Shah wrote:
AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
remoteproc driver
On 19/03/2024 02:06, Tanmay Shah wrote:
>
>
> On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>>> remoteproc driver is mostly compatible with new platforms except few
>>>
On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>> remoteproc driver is mostly compatible with new platforms except few
>> platform specific differences.
>>
>> Versal has same
On 15/03/2024 22:15, Tanmay Shah wrote:
> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
> remoteproc driver is mostly compatible with new platforms except few
> platform specific differences.
>
> Versal has same IP of cortex-R5 cores hence maintained compatible string
AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
remoteproc driver is mostly compatible with new platforms except few
platform specific differences.
Versal has same IP of cortex-R5 cores hence maintained compatible string
same as ZynqMP platform. However, hardcode TCM
Hi Sudeep,
On Thu, Mar 14, 2024 at 03:19:13PM +, Sudeep Holla wrote:
> > The plan for the driver is as follows:
> >
> > Step 1: provide a foundation driver capable of turning the core on/off
> > Step 2: provide mailbox support for comms
> > Step 3: provide FW reload capability
> >
Hi Krzysztof,
On Thu, Mar 14, 2024 at 02:56:53PM +0100, Krzysztof Kozlowski wrote:
> On 14/03/2024 14:49, Abdellatif El Khlifi wrote:
> >> Frankly at the moment I'd be inclined to say it isn't even a remoteproc
> >> binding (or driver) at all, it's a reset controller. Bindings are a
> >>
On Thu, Mar 14, 2024 at 01:49:28PM +, Abdellatif El Khlifi wrote:
> Hi Robin,
>
> > > + firmware-name:
> > > +description: |
> > > + Default name of the firmware to load to the remote processor.
> >
> > So... is loading the firmware image achieved by somehow bitbanging it
> >
On 14/03/2024 14:49, Abdellatif El Khlifi wrote:
>> Frankly at the moment I'd be inclined to say it isn't even a remoteproc
>> binding (or driver) at all, it's a reset controller. Bindings are a contract
>> for describing the hardware, not the current state of Linux driver support -
>> if this
Hi Robin,
> > + firmware-name:
> > +description: |
> > + Default name of the firmware to load to the remote processor.
>
> So... is loading the firmware image achieved by somehow bitbanging it
> through the one reset register, maybe? I find it hard to believe this is a
> complete and
On 2024-03-01 4:42 pm, abdellatif.elkhl...@arm.com wrote:
From: Abdellatif El Khlifi
introduce the bindings for Arm remoteproc support.
Signed-off-by: Abdellatif El Khlifi
---
.../bindings/remoteproc/arm,rproc.yaml| 69 +++
MAINTAINERS
On 3/10/24 12:41, Luca Weiss wrote:
Add the dts for the Xperia Z3 smartphone which is based on Sony's
shinano platform, so at the moment there's little device-specific dts to
add on top of the common parts.
Signed-off-by: Luca Weiss
---
modulo missing makfile, this looks good
On Fri, Feb 9, 2024 at 5:29 PM Oreoluwa Babatunde
wrote:
>
> The unflatten_device_tree() function contains a call to
> memblock_alloc(). This is a problem because this allocation is done
> before any of the reserved memory is set aside in paging_init().
> This means that there is a possibility
On Sonntag, 10. März 2024 12:41:09 CET Luca Weiss wrote:
> Add the dts for the Xperia Z3 smartphone which is based on Sony's
> shinano platform, so at the moment there's little device-specific dts to
> add on top of the common parts.
>
> Signed-off-by: Luca Weiss
> ---
>
Add the dts for the Xperia Z3 smartphone which is based on Sony's
shinano platform, so at the moment there's little device-specific dts to
add on top of the common parts.
Signed-off-by: Luca Weiss
---
.../qcom-msm8974pro-sony-xperia-shinano-leo.dts| 44 ++
1 file
Use tools/build/ makefiles to build rtla, inheriting the benefits of
it. For example, having a proper way to handle dependencies.
rtla is built using perf infra-structure when building inside the
kernel tree.
At this point, rtla diverges from perf in two points: Documentation
and tarball
Hi Krzysztof, Sudeep,
> > > diff --git a/Documentation/devicetree/bindings/remoteproc/arm,rproc.yaml
> > > b/Documentation/devicetree/bindings/remoteproc/arm,rproc.yaml
> > > new file mode 100644
> > > index ..322197158059
> > > --- /dev/null
> > > +++
On Fri, Mar 01, 2024 at 08:30:43PM +0100, Krzysztof Kozlowski wrote:
> On 01/03/2024 17:42, abdellatif.elkhl...@arm.com wrote:
> > From: Abdellatif El Khlifi
> >
> > introduce the bindings for Arm remoteproc support.
> >
> > Signed-off-by: Abdellatif El Khlifi
> > ---
> >
On 01/03/2024 17:42, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> introduce the bindings for Arm remoteproc support.
>
> Signed-off-by: Abdellatif El Khlifi
> ---
> .../bindings/remoteproc/arm,rproc.yaml| 69 +++
> MAINTAINERS
From: Abdellatif El Khlifi
introduce the bindings for Arm remoteproc support.
Signed-off-by: Abdellatif El Khlifi
---
.../bindings/remoteproc/arm,rproc.yaml| 69 +++
MAINTAINERS | 1 +
2 files changed, 70 insertions(+)
create mode
On Sat, 24 Feb 2024 10:12:36 +0100, Krzysztof Kozlowski wrote:
> TI Davinci remoteproc bindings were marked as work-in-progress /
> unstable in 2017 in commit ae67b8007816 ("dt-bindings: remoteproc: Add
> bindings for Davinci DSP processors"). Almost seven years is enough, so
> drop the
On Sat, Feb 24, 2024 at 10:12:36AM +0100, Krzysztof Kozlowski wrote:
> TI Davinci remoteproc bindings were marked as work-in-progress /
> unstable in 2017 in commit ae67b8007816 ("dt-bindings: remoteproc: Add
> bindings for Davinci DSP processors"). Almost seven years is enough, so
> drop the
TI Davinci remoteproc bindings were marked as work-in-progress /
unstable in 2017 in commit ae67b8007816 ("dt-bindings: remoteproc: Add
bindings for Davinci DSP processors"). Almost seven years is enough, so
drop the "unstable" remark and expect usual ABI rules.
Signed-off-by: Krzysztof Kozlowski
On 2/10/24 15:12, Luca Weiss wrote:
Add the power domains CX & GFX found on MSM8974 devices that use PMA8084
instead of the standard PM8841+PM8941 combo.
Signed-off-by: Luca Weiss
---
Same comment as p2, gfx_ao may not make much sense on this
platform
Konrad
Add the power domains CX & GFX found on MSM8974 devices that use PMA8084
instead of the standard PM8841+PM8941 combo.
Signed-off-by: Luca Weiss
---
drivers/pmdomain/qcom/rpmpd.c | 41 +
1 file changed, 41 insertions(+)
diff --git
The unflatten_device_tree() function contains a call to
memblock_alloc(). This is a problem because this allocation is done
before any of the reserved memory is set aside in paging_init().
This means that there is a possibility for memblock to allocate from
any of the memory regions that are
On 1/31/24 15:00, Abel Vesa wrote:
On 24-01-29 17:17:28, Dmitry Baryshkov wrote:
On Mon, 29 Jan 2024 at 15:35, Abel Vesa wrote:
From: Sibi Sankar
The UEFI loads a lite variant of the ADSP firmware to support charging
use cases. The kernel needs to unload and reload it with the firmware
Enable the PBS driver used on e.g. PMI632.
Signed-off-by: Luca Weiss
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index cfa3e00def09..e92a5fd9f660 100644
--- a/arch/arm64/configs/defconfig
+++
On 24-01-29 17:17:28, Dmitry Baryshkov wrote:
> On Mon, 29 Jan 2024 at 15:35, Abel Vesa wrote:
> >
> > From: Sibi Sankar
> >
> > The UEFI loads a lite variant of the ADSP firmware to support charging
> > use cases. The kernel needs to unload and reload it with the firmware
> > that has full
On Mon, 29 Jan 2024 at 15:35, Abel Vesa wrote:
>
> From: Sibi Sankar
>
> The UEFI loads a lite variant of the ADSP firmware to support charging
> use cases. The kernel needs to unload and reload it with the firmware
> that has full feature support for audio. This patch arbitarily shutsdown
> the
From: Sibi Sankar
The UEFI loads a lite variant of the ADSP firmware to support charging
use cases. The kernel needs to unload and reload it with the firmware
that has full feature support for audio. This patch arbitarily shutsdown
the lite firmware before loading the full firmware.
On 1/23/24 22:03, Luca Weiss wrote:
From: Vladimir Lypak
With this reset we can avoid situations like IRQ storms from DSI host
before it even started probing (because boot-loader left DSI IRQs on).
Signed-off-by: Vladimir Lypak
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
From: Vladimir Lypak
With this reset we can avoid situations like IRQ storms from DSI host
before it even started probing (because boot-loader left DSI IRQs on).
Signed-off-by: Vladimir Lypak
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 2 ++
1 file changed, 2
Similar to printk() 'pd' is for print dentry's name, and 'pD' is
for print file's name.
Signed-off-by: Ye Bin
---
Documentation/trace/kprobetrace.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/trace/kprobetrace.rst
b/Documentation/trace/kprobetrace.rst
Follow the updated bindings and use a QCS404-specific compatible for the
HFPLL.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
Randy Dunlap wrote:
>
>
> On 12/21/23 14:32, Ira Weiny wrote:
> > Randy Dunlap wrote:
> >
> > [snip]
> >
> >> @@ -1656,8 +1664,10 @@ static int select_pmem_id(struct nd_regi
> >> /**
> >> * create_namespace_pmem - validate interleave set labelling, retrieve
> >> label0
> >> * @nd_region:
On 12/21/23 14:32, Ira Weiny wrote:
> Randy Dunlap wrote:
>
> [snip]
>
>> @@ -1656,8 +1664,10 @@ static int select_pmem_id(struct nd_regi
>> /**
>> * create_namespace_pmem - validate interleave set labelling, retrieve
>> label0
>> * @nd_region: region with mappings to validate
>> - *
Randy Dunlap wrote:
[snip]
> @@ -1656,8 +1664,10 @@ static int select_pmem_id(struct nd_regi
> /**
> * create_namespace_pmem - validate interleave set labelling, retrieve label0
> * @nd_region: region with mappings to validate
> - * @nspm: target namespace to create
> + * @nd_mapping:
Now that rodata_enabled is always declared, remove #ifdef
and define a single version of strict_kernel_rwx_enabled().
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mmu.h | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu.h
set_memory_ro(), set_memory_nx(), set_memory_x() and other helps
can fail an return an error. In that case the memory might not be
protected as expected and the module loading has to be aborted to
avoid security issues.
Check return value of all calls to set_memory_XX() and handle
error if any.
Via the PMIC GLINK driver we can get info about fuel gauge, charger and
USB connector events. Add the node to the dts and configure USB so that
role switching works.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 46 +-
Even though a previous patch re-added the supplies to the adsp and modem
remoteprocs, due to timing differences in the meantime the remoteprocs
were disabled by default, but the commit re-adding the supplies didn't
enable them.
Enable them now to hopefully properly resolve the fallout now.
Adjust kernel-doc notation to prevent warnings when using -Wall.
namespace_devs.c:76: warning: No description found for return value of
'nd_is_uuid_unique'
namespace_devs.c:343: warning: No description found for return value of
'shrink_dpa_allocation'
namespace_devs.c:668: warning: No
Add type-c node to feature otg function.
Signed-off-by: Jianhua Lu
---
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
Currently, we don't support MODVERSIONS for Rust symbols. For users that
want to use Rust in the kernel but for whom MODVERSIONS is required,
this allows the use of built-in Rust code even with MODVERSIONS enabled.
It may additionally allow code-size reduction by avoiding exporting
symbols that
Hi Wuqiang,
On Thu, 26 Oct 2023 19:05:51 +0800
"wuqiang.matt" wrote:
> On 2023/10/26 16:46, Arnd Bergmann wrote:
> > On Thu, Oct 26, 2023, at 09:39, wuqiang.matt wrote:
> >> arch_cmpxchg[64]_local() are not defined for openrisc. So implement
> >> them with generci_cmpxchg[64]_local, advised by
On 2023/10/26 16:46, Arnd Bergmann wrote:
On Thu, Oct 26, 2023, at 09:39, wuqiang.matt wrote:
arch_cmpxchg[64]_local() are not defined for openrisc. So implement
them with generci_cmpxchg[64]_local, advised by Masami Hiramatsu.
Closes:
On Thu, Oct 26, 2023, at 09:39, wuqiang.matt wrote:
> arch_cmpxchg[64]_local() are not defined for openrisc. So implement
> them with generci_cmpxchg[64]_local, advised by Masami Hiramatsu.
>
> Closes:
>
arch_cmpxchg[64]_local() are not defined for openrisc. So implement
them with generci_cmpxchg[64]_local, advised by Masami Hiramatsu.
Closes:
https://lore.kernel.org/linux-trace-kernel/169824660459.24340.14614817132696360531.stgit@devnote2
Closes:
On Wed, 25 Oct 2023 at 10:43, Neil Armstrong wrote:
>
> Add DSP Peripheral Authentication Service support for the SM8650 platform.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/remoteproc/qcom_q6v5_pas.c | 50
> ++
> 1 file changed, 50 insertions(+)
Add DSP Peripheral Authentication Service support for the SM8650 platform.
Signed-off-by: Neil Armstrong
---
drivers/remoteproc/qcom_q6v5_pas.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
The Orient-Chip OCP96011 is generally compatible with the FSA4480, add a
compatible for it with the fallback on fsa4480.
However the AUX/SBU connections are expected to be swapped compared to
FSA4480, so document this in the data-lanes description.
Signed-off-by: Luca Weiss
---
On 10/11/23 18:33, Luca Weiss wrote:
From: Matti Lehtimäki
Add watchdog for MSM8974 platform.
Signed-off-by: Matti Lehtimäki
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
On 10/11/23 19:02, Luca Weiss wrote:
Add support for this smartphone based on the MSM8926 SoC, codenamed
"memul".
Supported functionality:
* Power & volume buttons
* ADSP
* Magnetometer
* Accelerometer
* Touchscreen
* Vibrator
* Internal storage
* SD card
* Charger
* USB
Signed-off-by: Luca
Add support for this smartphone based on the MSM8926 SoC, codenamed
"memul".
Supported functionality:
* Power & volume buttons
* ADSP
* Magnetometer
* Accelerometer
* Touchscreen
* Vibrator
* Internal storage
* SD card
* Charger
* USB
Signed-off-by: Luca Weiss
---
From: Matti Lehtimäki
Add watchdog for MSM8974 platform.
Signed-off-by: Matti Lehtimäki
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
On Fri Sep 29, 2023 at 3:36 PM CEST, Konrad Dybcio wrote:
>
>
> On 9/29/23 10:01, Luca Weiss wrote:
> > Enable the CCI busses where sensors are connected to.
> >
> > Not covered here is the regulator used for pull-up on the I2C busses.
> > This would be pm8008_l6 (L6P).
> Does it make sense to
On 9/29/23 10:01, Luca Weiss wrote:
Enable the CCI busses where sensors are connected to.
Not covered here is the regulator used for pull-up on the I2C busses.
This would be pm8008_l6 (L6P).
Does it make sense to enable non-functional hw then? Or is it on by default?
Konrad
On 29.09.2023 10:38, Luca Weiss wrote:
> Enable the venus node so that the video encoder/decoder will start
> working.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 29/09/2023 09:38, Luca Weiss wrote:
Enable the venus node so that the video encoder/decoder will start
working.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 5 +
1 file changed, 5 insertions(+)
diff --git
Enable the venus node so that the video encoder/decoder will start
working.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
Enable the CCI busses where sensors are connected to.
Not covered here is the regulator used for pull-up on the I2C busses.
This would be pm8008_l6 (L6P).
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 20
1 file changed, 20
On Wed, 2023-09-27 at 09:15 -0700, Kees Cook wrote:
> On Wed, Sep 27, 2023 at 03:19:16AM +, Justin Stitt wrote:
> > Add the "D:" type which behaves the same as "K:" but will only match
> > content present in a patch file.
> >
> > To illustrate:
> >
> > Imagine this entry in MAINTAINERS:
> >
On Wed, 2023-09-27 at 03:19 +, Justin Stitt wrote:
> Add the "D:" type which behaves the same as "K:" but will only match
> content present in a patch file.
Likely it'd be less aggravating just to document
that K: is only for patches and add a !$file test.
On Wed, Sep 27, 2023 at 03:19:16AM +, Justin Stitt wrote:
> Add the "D:" type which behaves the same as "K:" but will only match
> content present in a patch file.
>
> To illustrate:
>
> Imagine this entry in MAINTAINERS:
>
> NEW REPUBLIC
> M: Han Solo
> W:
On Wed, Sep 27, 2023 at 03:46:30PM +0900, Justin Stitt wrote:
> On Wed, Sep 27, 2023 at 3:14 PM Greg KH wrote:
> >
> > On Wed, Sep 27, 2023 at 03:19:16AM +, Justin Stitt wrote:
> > > Note that folks really shouldn't be using get_maintainer on tree files
> > > anyways [1].
> >
> > That's not
On Wed, Sep 27, 2023 at 3:14 PM Greg KH wrote:
>
> On Wed, Sep 27, 2023 at 03:19:16AM +, Justin Stitt wrote:
> > Note that folks really shouldn't be using get_maintainer on tree files
> > anyways [1].
>
> That's not true, Linus and I use it on a daily basis this way, it's part
> of our normal
On Wed, Sep 27, 2023 at 03:19:16AM +, Justin Stitt wrote:
> Note that folks really shouldn't be using get_maintainer on tree files
> anyways [1].
That's not true, Linus and I use it on a daily basis this way, it's part
of our normal workflow, AND the workflow of the kernel security team.
So
Add the "D:" type which behaves the same as "K:" but will only match
content present in a patch file.
To illustrate:
Imagine this entry in MAINTAINERS:
NEW REPUBLIC
M: Han Solo
W: https://www.jointheresistance.org
D: \bstrncpy\b
Our maintainer, Han, will only be added to the recipients if a
On Tue, 12 Sep 2023 22:58:58 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The function that the kprobe_args_char and kprobes_arg_string attaches to
> for its test has changed its name once again. Now we need to check for
> eventfs_create_dir(), and if it exists, use that,
From: "Steven Rostedt (Google)"
The function that the kprobe_args_char and kprobes_arg_string attaches to
for its test has changed its name once again. Now we need to check for
eventfs_create_dir(), and if it exists, use that, otherwise check for
eventfs_add_dir() and if that exists use that,
On 13.07.23 17:40, Verma, Vishal L wrote:
On Thu, 2023-07-13 at 17:23 +0200, David Hildenbrand wrote:
On 13.07.23 17:15, Verma, Vishal L wrote:
On Thu, 2023-07-13 at 09:23 +0200, David Hildenbrand wrote:
On 13.07.23 08:45, Verma, Vishal L wrote:
I'm taking a shot at implementing the
On Thu, 2023-07-13 at 17:23 +0200, David Hildenbrand wrote:
> On 13.07.23 17:15, Verma, Vishal L wrote:
> > On Thu, 2023-07-13 at 09:23 +0200, David Hildenbrand wrote:
> > > On 13.07.23 08:45, Verma, Vishal L wrote:
> > > >
> > > > I'm taking a shot at implementing the splitting internally in
> >
On 13.07.23 17:15, Verma, Vishal L wrote:
On Thu, 2023-07-13 at 09:23 +0200, David Hildenbrand wrote:
On 13.07.23 08:45, Verma, Vishal L wrote:
I'm taking a shot at implementing the splitting internally in
memory_hotplug.c. The caller (kmem) side does become trivial with this
approach, but
On Thu, 2023-07-13 at 09:23 +0200, David Hildenbrand wrote:
> On 13.07.23 08:45, Verma, Vishal L wrote:
> >
> > I'm taking a shot at implementing the splitting internally in
> > memory_hotplug.c. The caller (kmem) side does become trivial with this
> > approach, but there's a slight complication
On 13.07.23 08:45, Verma, Vishal L wrote:
On Tue, 2023-07-11 at 17:21 +0200, David Hildenbrand wrote:
On 11.07.23 16:30, Aneesh Kumar K.V wrote:
David Hildenbrand writes:
Maybe the better alternative is teach
add_memory_resource()/try_remove_memory() to do that internally.
In the
On Tue, 2023-07-11 at 17:21 +0200, David Hildenbrand wrote:
> On 11.07.23 16:30, Aneesh Kumar K.V wrote:
> > David Hildenbrand writes:
> > >
> > > Maybe the better alternative is teach
> > > add_memory_resource()/try_remove_memory() to do that internally.
> > >
> > > In the
On 11.07.23 16:30, Aneesh Kumar K.V wrote:
David Hildenbrand writes:
On 16.06.23 00:00, Vishal Verma wrote:
With DAX memory regions originating from CXL memory expanders or
NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
on a system without enough 'regular' main
David Hildenbrand writes:
> On 16.06.23 00:00, Vishal Verma wrote:
>> With DAX memory regions originating from CXL memory expanders or
>> NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
>> on a system without enough 'regular' main memory to support the memmap
>> for it.
Hi Vishal,
Vishal Verma writes:
> With DAX memory regions originating from CXL memory expanders or
> NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
> on a system without enough 'regular' main memory to support the memmap
> for it. To avoid this, ensure that all kmem
On 16.06.23 00:00, Vishal Verma wrote:
With DAX memory regions originating from CXL memory expanders or
NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
on a system without enough 'regular' main memory to support the memmap
for it. To avoid this, ensure that all kmem
Vishal Verma writes:
> With DAX memory regions originating from CXL memory expanders or
> NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
> on a system without enough 'regular' main memory to support the memmap
> for it. To avoid this, ensure that all kmem managed
With DAX memory regions originating from CXL memory expanders or
NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
on a system without enough 'regular' main memory to support the memmap
for it. To avoid this, ensure that all kmem managed hotplugged memory is
added with the
On 5/16/23 1:14 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
The security_show() function was made global and __weak at some
point to allow overriding it. The override was removed later, but
it remains global, which causes a warning about the missing
declaration:
From: Arnd Bergmann
The security_show() function was made global and __weak at some
point to allow overriding it. The override was removed later, but
it remains global, which causes a warning about the missing
declaration:
drivers/nvdimm/dimm_devs.c:352:9: error: no previous prototype for
This patch is inspired by Dan's "mm, dax, pmem: Introduce
dev_pagemap_failure()"[1]. With the help of dax_holder and
->notify_failure() mechanism, the pmem driver is able to ask filesystem
(or mapped device) on it to unmap all files in use and notify processes
who are using those files.
Call
On Tue, Sep 20, 2022 at 12:45:19PM +1000, Dave Chinner wrote:
> On Fri, Sep 02, 2022 at 10:36:01AM +, Shiyang Ruan wrote:
> > This patch is inspired by Dan's "mm, dax, pmem: Introduce
> > dev_pagemap_failure()"[1]. With the help of dax_holder and
> > ->notify_failure() mechanism, the pmem
On Fri, Sep 02, 2022 at 10:36:01AM +, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to unmap all
1 - 100 of 36350 matches
Mail list logo
