Hi Kai,
On 2024/4/23 19:50, Huang, Kai wrote:
On Tue, 2024-04-23 at 17:25 +0800, 朱伯君(杰铭) wrote:
EDMM's ioctl()s support batch operations, which may be
time-consuming. Try to explicitly give up the CPU at
the every end of "for loop" in
sgx_enclave_{ modify_types | restrict_permissions |
On Wed, Apr 24, 2024 at 08:44:10AM +0800, Jason Wang wrote:
> On Tue, Apr 23, 2024 at 4:42 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Apr 23, 2024 at 11:09:59AM +0800, Jason Wang wrote:
> > > On Tue, Apr 23, 2024 at 4:05 AM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Thu, Apr 18, 2024
On Wed, Apr 24, 2024 at 6:06 AM Xinghui Li wrote:
>
> There is one typo in drivers/gpu/drm/qxl/qxl_gem.c's comment, which
> 'acess' should be 'access'. So fix it.
>
> Signed-off-by: Xinghui Li
> ---
> drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
PSC controller has a limitation that it can only power-up the second
core when the first core is in ON state. Power-state for core0 should be
equal to or higher than core1.
Therefore, prevent core1 from powering up before core0 during the start
process from sysfs. Similarly, prevent core0 from
On Wed, Apr 24, 2024 at 2:23 PM Florent Revest wrote:
>
> On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google)
> wrote:
> >
> > From: Masami Hiramatsu (Google)
> >
> > To clarify what will be expected on ftrace_regs, add a comment to the
> > architecture independent definition of the
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Aren-Moynihan/dt-bindings-iio-light-stk33xx-add-vdd-and-leda-regulators/20240424-064250
base: https://git.kernel.org
From: Apurva Nandan
PSC controller has a limitation that it can only power-up the second core
when the first core is in ON state. Power-state for core0 should be equal
to or higher than core1, else the kernel is seen hanging during rproc
loading.
Make the powering up of cores sequential, by
PSC controller has a limitation that it can only power-up the second core
when the first core is in ON state. Power-state for core0 should be equal
to or higher than core1, else the kernel is seen hanging during rproc
loading.
Make the powering up of cores sequential, by waiting for the current
Il 24/04/24 05:03, Olivia Wen ha scritto:
Integrate the imgsys core architecture driver for image processing on
the MT8188 platform.
Signed-off-by: Olivia Wen
This should be reordered before introducing the 8188 scp core 1 support commit,
but let's check with Mathieu before sending a v4.
Il 24/04/24 05:03, Olivia Wen ha scritto:
The SCP on different chips will require different DRAM sizes and IPI
shared buffer sizes based on varying requirements.
Signed-off-by: Olivia Wen
Reviewed-by: AngeloGioacchino Del Regno
Il 24/04/24 05:03, Olivia Wen ha scritto:
MT8188 SCP has two RISC-V cores which is similar to MT8195 but without
L1TCM. We've added MT8188-specific functions to configure L1TCM in
multicore setups.
Signed-off-by: Olivia Wen
Reviewed-by: AngeloGioacchino Del Regno
Il 24/04/24 12:02, AngeloGioacchino Del Regno ha scritto:
Il 24/04/24 05:03, Olivia Wen ha scritto:
Integrate the imgsys core architecture driver for image processing on
the MT8188 platform.
Signed-off-by: Olivia Wen
This should be reordered before introducing the 8188 scp core 1 support
On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote:
> On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan wrote:
> >
> > From: Ondrej Jirman
> >
> > VDD power input can be used to completely power off the chip during
> > system suspend. Do so if available.
>
> ...
>
> > ret =
On Wed Apr 24, 2024 at 10:02 AM EEST, Jarkko Sakkinen wrote:
> On Wed Apr 24, 2024 at 9:46 AM EEST, Bojun Zhu wrote:
> > Based on the the discussion among you, Jarkko and Reinette,
> > I will keep the need_resched() and wrap the logic in using sgx_resched(),
> > as suggested by Jarkko.
>
> Sounds
Hi Jarkko,
> On Apr 24, 2024, at 18:42, Jarkko Sakkinen wrote:
>
> On Wed Apr 24, 2024 at 10:02 AM EEST, Jarkko Sakkinen wrote:
>> On Wed Apr 24, 2024 at 9:46 AM EEST, Bojun Zhu wrote:
>>> Based on the the discussion among you, Jarkko and Reinette,
>>> I will keep the need_resched() and wrap
On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google)
wrote:
>
> From: Masami Hiramatsu (Google)
>
> To clarify what will be expected on ftrace_regs, add a comment to the
> architecture independent definition of the ftrace_regs.
>
> Signed-off-by: Masami Hiramatsu (Google)
> Acked-by: Mark
Neat! :) I had a look at mostly the "high level" part (fprobe and
arm64 specific bits) and this seems to be in a good state to me.
Thanks for all that work, that is quite a refactoring :)
On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google)
wrote:
>
> Hi,
>
> Here is the 9th version of the
On Wed, 24 Apr 2024 15:19:24 +0200
Florent Revest wrote:
> On Wed, Apr 24, 2024 at 2:23 PM Florent Revest wrote:
> >
> > On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google)
> > wrote:
> > >
> > > From: Masami Hiramatsu (Google)
> > >
> > > To clarify what will be expected on
On Wed, Apr 24, 2024 at 3:59 PM Ondřej Jirman wrote:
> On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote:
> > On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan
> > wrote:
...
> > > ret = stk3310_init(indio_dev);
> > > if (ret < 0)
> > > - return ret;
> >
Add "else" case for default tcm mode to silent following static check:
zynqmp_r5_cluster_init()
error: uninitialized symbol 'tcm_mode'.
Fixes: a6b974b40f94 ("drivers: remoteproc: xlnx: Add Versal and Versal-NET
support")
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
Hi Jarkko
On Tue, 16 Apr 2024 11:08:11 -0500, Jarkko Sakkinen
wrote:
On Tue Apr 16, 2024 at 5:54 PM EEST, Haitao Huang wrote:
I did declare the configs in the config file but I missed it in my patch
as stated earlier. IIUC, that would not cause this error though.
Maybe I should exit with
On 22.04.24 22:53, Guillaume Morin wrote:
On 22 Apr 20:59, David Hildenbrand wrote:
The benefit - to me - is very clear. People do use hugetlb mappings to
run code in production environments. The perf benefits are there for some
workloads. Intel has published a whitepaper about it etc.
Uprobes
Hi David,
Thanks for your quick response.
On Wed, Apr 24, 2024 at 05:26:39PM +0200, David Hildenbrand wrote:
>
> I gave it some more thought, and I think we are still missing something (I
> wish PFNMAP/MIXEDMAP wouldn't be that hard).
>
> > +
> > +/*
> > + * +--+ pgoff == 0
> >
ng mboxes instead of qcom,ipc
soc: qcom: smsm: Support using mailbox interface
.../devicetree/bindings/soc/qcom/qcom,smsm.yaml| 48
drivers/soc/qcom/smsm.c| 51 +++++-
2 files changed, 90 insertions(+), 9 deletions(-)
---
base-commit: ed30a4a51bb196781c8058073ea720133a65596f
change-id: 20240424-smsm-mbox-0666f35eae44
Best regards,
--
Luca Weiss
The qcom,ipc-N properties are essentially providing a reference to a
mailbox, so allow using the mboxes property to do the same in a more
structured way.
Since multiple SMSM hosts are supported, we need to be able to provide
the correct mailbox for each host. The old qcom,ipc-N properties map to
On Wed Apr 24, 2024 at 8:44 PM EEST, Jarkko Sakkinen wrote:
> On Wed Apr 24, 2024 at 2:50 PM EEST, Bojun Zhu wrote:
> > I still have some questions:
> >
> > It seems that the variable "ret" is set to 0 if there is **some** EPC pages
> > have been
> > added when interrupted by signal(Supposed
On 4/24/24 18:23, Luca Weiss wrote:
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
On Mittwoch, 24. April 2024 18:23:53 MESZ Luca Weiss wrote:
> The first patch is for removing a bogus error warning I've noticed while
> developing this on msm8226 - there the patches are also coming later for
> this SoC since apcs is getting hooked up to cpufreq there also.
>
> Apart from usages
On Wed, Apr 24, 2024 at 06:23:53PM +0200, Luca Weiss wrote:
> The first patch is for removing a bogus error warning I've noticed while
> developing this on msm8226 - there the patches are also coming later for
> this SoC since apcs is getting hooked up to cpufreq there also.
>
> Apart from usages
On Wed, Apr 24, 2024 at 7:14 PM Ondřej Jirman wrote:
> On Wed, Apr 24, 2024 at 06:20:41PM GMT, Andy Shevchenko wrote:
> > On Wed, Apr 24, 2024 at 3:59 PM Ondřej Jirman wrote:
> > > On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote:
> > > > On Wed, Apr 24, 2024 at 1:41 AM Aren
On 24.04.24 22:44, Guillaume Morin wrote:
On 24 Apr 22:09, David Hildenbrand wrote:
Let me try to see if we can get this done cleaner.
One ugly part (in general here) is the custom page replacement in the
registration part.
We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing
On Wed, Apr 24, 2024 at 06:20:41PM GMT, Andy Shevchenko wrote:
> On Wed, Apr 24, 2024 at 3:59 PM Ondřej Jirman wrote:
> > On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote:
> > > On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan
> > > wrote:
>
> ...
>
> > > > ret =
On 4/24/24 18:24, Luca Weiss wrote:
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8994.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
When the mailbox driver has not probed yet, skip printing the error
message since it's just going to confuse users.
Signed-off-by: Luca Weiss
---
drivers/rpmsg/qcom_smd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8939.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
The first patch is for removing a bogus error warning I've noticed while
developing this on msm8226 - there the patches are also coming later for
this SoC since apcs is getting hooked up to cpufreq there also.
Apart from usages from the qcom,smsm driver (patches coming!) all other
usages of the
On 4/24/24 19:21, Luca Weiss wrote:
Add support for using the mbox interface instead of manually writing to
the syscon. With this change the driver will attempt to get the mailbox
first, and if that fails it will fall back to the existing way of using
qcom,ipc-* properties and converting to
On 24.04.24 22:31, Vincent Donnefort wrote:
Hi David,
Thanks for your quick response.
On Wed, Apr 24, 2024 at 05:26:39PM +0200, David Hildenbrand wrote:
I gave it some more thought, and I think we are still missing something (I
wish PFNMAP/MIXEDMAP wouldn't be that hard).
+
+/*
+ *
On Wed, Apr 24, 2024 at 12:04:54PM +0200, AngeloGioacchino Del Regno wrote:
> Il 24/04/24 12:02, AngeloGioacchino Del Regno ha scritto:
> > Il 24/04/24 05:03, Olivia Wen ha scritto:
> > > Integrate the imgsys core architecture driver for image processing on
> > > the MT8188 platform.
> > >
> > >
On Wed, Apr 24, 2024 at 06:23:54PM +0200, Luca Weiss wrote:
> When the mailbox driver has not probed yet, skip printing the error
> message since it's just going to confuse users.
>
> Signed-off-by: Luca Weiss
> ---
> drivers/rpmsg/qcom_smd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1
On Wed Apr 24, 2024 at 2:50 PM EEST, Bojun Zhu wrote:
> I still have some questions:
>
> It seems that the variable "ret" is set to 0 if there is **some** EPC pages
> have been
> added when interrupted by signal(Supposed that sgx_encl_add_page()
> always returns successfully).
Ah, ok.
On Wed, Apr 24, 2024 at 08:31:27PM GMT, Andy Shevchenko wrote:
> On Wed, Apr 24, 2024 at 7:14 PM Ondřej Jirman wrote:
> > On Wed, Apr 24, 2024 at 06:20:41PM GMT, Andy Shevchenko wrote:
> > > On Wed, Apr 24, 2024 at 3:59 PM Ondřej Jirman wrote:
> > > > On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy
On 4/24/24 18:23, Luca Weiss wrote:
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
On 4/24/24 18:23, Luca Weiss wrote:
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
On 4/24/24 18:23, Luca Weiss wrote:
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
On 4/24/24 18:23, Luca Weiss wrote:
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
On 24 Apr 22:09, David Hildenbrand wrote:
> > > Let me try to see if we can get this done cleaner.
> > >
> > > One ugly part (in general here) is the custom page replacement in the
> > > registration part.
> > >
> > > We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing
> > >
From: Duje Mihanović
Add driver for the MPMU controller block on Marvell's PXA1908 SoC. The
driver is incomplete, currently only supporting the fixed PLL1; dynamic
PLLs 2-4 and CPU/DDR/AXI clock support is missing.
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/Makefile | 2 +-
From: Duje Mihanović
Add driver for the APMU controller block found on Marvell's PXA1908 SoC.
This driver is incomplete, lacking support for (at least) GPU, VPU, DSI
and CCIC (camera related) clocks.
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/Makefile | 2 +-
From: Duje Mihanović
Add ARCH_MMP configuration option for Marvell PXA1908 SoC.
Signed-off-by: Duje Mihanović
---
arch/arm64/Kconfig.platforms | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index
From: Duje Mihanović
Add DTS for Marvell PXA1908 SoC and Samsung Galaxy Core Prime Value
Edition LTE, a smartphone based on said SoC.
Signed-off-by: Duje Mihanović
---
arch/arm64/boot/dts/marvell/Makefile | 3 +
.../dts/marvell/pxa1908-samsung-coreprimevelte.dts | 328
From: Duje Mihanović
Add dt binding for the Marvell PXA1908 SoC.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Duje Mihanović
---
Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
From: Duje Mihanović
Add driver for the APBCP controller block found on Marvell's PXA1908
SoC.
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/Makefile| 2 +-
drivers/clk/mmp/clk-pxa1908-apbcp.c | 84 +
2 files changed, 85 insertions(+), 1
From: Duje Mihanović
Add driver for the APBC controller block found on Marvell's PXA1908 SoC.
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk-pxa1908-apbc.c | 131 +
2 files changed, 132 insertions(+), 1
Hello,
This series adds initial support for the Marvell PXA1908 SoC and
"samsung,coreprimevelte", a smartphone using the SoC.
USB works and the phone can boot a rootfs from an SD card, but there are
some warnings in the dmesg:
During SMP initialization:
[0.006519] CPU features: SANITY
From: Duje Mihanović
Add the "marvell,pxa1908-padconf" compatible to allow migrating to a
separate pinctrl driver later.
Reviewed-by: Rob Herring
Acked-by: Linus Walleij
Signed-off-by: Duje Mihanović
---
Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml | 4
1 file changed,
From: Andy Shevchenko
The struct mmp_clk_factor_tbl repeats the generic struct u32_fract.
Kill the custom one and use the generic one instead.
Signed-off-by: Andy Shevchenko
Tested-by: Duje Mihanović
Reviewed-by: Linus Walleij
Reviewed-by: Stephen Boyd
Signed-off-by: Duje Mihanović
---
From: Duje Mihanović
Add the "marvell,pxa1908-padconf" compatible to allow migrating to a
separate pinctrl driver later.
Acked-by: Linus Walleij
Signed-off-by: Duje Mihanović
---
drivers/pinctrl/pinctrl-single.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Duje Mihanović
Add dt bindings and documentation for the Marvell PXA1908 clock
controller.
Reviewed-by: Conor Dooley
Reviewed-by: Stephen Boyd
Signed-off-by: Duje Mihanović
---
.../devicetree/bindings/clock/marvell,pxa1908.yaml | 48
From: Duje Mihanović
Add myself as the maintainer for Marvell PXA1908 SoC support.
Signed-off-by: Duje Mihanović
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ebf03f5f0619..5d48ac9801df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
On Wed, 24 Apr 2024 14:06:09 -0500, Andrew Davis wrote:
> From: Hari Nagalla
>
> K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
> The remote processor's life cycle management and IPC mechanisms are
> similar across the R5F and M4F cores from remote processor driver
> point
I gave it some more thought, and I think we are still missing something
(I wish PFNMAP/MIXEDMAP wouldn't be that hard).
+
+/*
+ * +--+ pgoff == 0
+ * | meta page |
+ * +--+ pgoff == 1
+ * | subbuffer 0 |
+ * | |
+ * +--+
Add support for using the mbox interface instead of manually writing to
the syscon. With this change the driver will attempt to get the mailbox
first, and if that fails it will fall back to the existing way of using
qcom,ipc-* properties and converting to syscon.
Signed-off-by: Luca Weiss
---
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC
From: Hari Nagalla
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and
From: Hari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is
Hello all,
This is the continuation of the M4F RProc support series from here[0].
I'm helping out with the upstream task for Hari and so this version(v8)
is a little different than the previous(v7) postings[0]. Most notable
change I've introduced being the patches factoring out common support
From: Jason Xing
It relies on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
Reviewed-by: Matthieu Baerts (NGI0)
---
net/mptcp/protocol.h | 27
From: Jason Xing
Since we have mapped every mptcp reset reason definition in enum
sk_rst_reason, introducing a new helper can cover some missing places
where we have already set the subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNSPEC.
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
objpool_push() and objpool_pop() are very performance-critical functions
and can be called very frequently in kretprobe triggering path.
As such, it makes sense to allow compiler to inline them completely to
eliminate function calls overhead. Luckily, their logic is quite well
isolated and
Profiling shows that calling nr_possible_cpus() in objpool_pop() takes
a noticeable amount of CPU (when profiled on 80-core machine), as we
need to recalculate number of set bits in a CPU bit mask. This number
can't change, so there is no point in paying the price for recalculating
it. As such,
Improve objpool (used heavily in kretprobe hot path) performance with two
improvements:
- inlining performance critical objpool_push()/objpool_pop() operations;
- avoiding re-calculating relatively expensive nr_possible_cpus().
These opportunities were found when benchmarking and profiling
The warning described on patch "tracing: Increase PERF_MAX_TRACE_SIZE to
handle Sentinel1 and docker together" can be triggered with a perf probe on
do_execve with a large path. As PATH_MAX is larger than PERF_MAX_TRACE_SIZE
(2048 before the patch), the warning will trigger.
The fix was included
From: "Robin H. Johnson"
commit a90afe8d020da9298c98fddb19b7a6372e2feb45 upstream.
If the perf buffer isn't large enough, provide a hint about how large it
needs to be for whatever is running.
Link: https://lkml.kernel.org/r/20210831043723.13481-1-robb...@gentoo.org
Signed-off-by: Robin H.
From: "Robin H. Johnson"
commit e531e90b5ab0f7ce5ff298e165214c1aec6ed187 upstream.
Running endpoint security solutions like Sentinel1 that use perf-based
tracing heavily lead to this repeated dump complaining about dockerd.
The default value of 2048 is nowhere near not large enough.
Using the
From: "Robin H. Johnson"
commit e531e90b5ab0f7ce5ff298e165214c1aec6ed187 upstream.
Running endpoint security solutions like Sentinel1 that use perf-based
tracing heavily lead to this repeated dump complaining about dockerd.
The default value of 2048 is nowhere near not large enough.
Using the
On Sun, Apr 21, 2024 at 04:22:32PM +0200, Ismael Luceno wrote:
> It was observed in the wild that pairs of consecutive packets would leave
> the IPVS with the same wrong checksum, and the issue only went away when
> disabling GSO.
>
> IPVS needs to avoid computing the SCTP checksum when using
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
Acked-by: Matthieu Baerts (NGI0)
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
Acked-by: Matthieu Baerts (NGI0)
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset()).
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1)
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we can finally display the corresponding item in enum sk_reset_reason
instead of reinventing new reset reasons. This patch replaces all
the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
At the lowest level, rethook-based kretprobes on x86-64 architecture go
through arch_rethoook_trampoline() function, manually written in
assembly, which calls into a simple arch_rethook_trampoline_callback()
function, written in C, and only doing a few straightforward field
assignments, before
On Wed, Apr 24, 2024 at 02:16:06AM +0300, Andy Shevchenko wrote:
> On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan wrote:
> >
> > From: Ondrej Jirman
> >
> > VDD power input can be used to completely power off the chip during
> > system suspend. Do so if available.
>
> ...
>
> > ret =
On Wed, Apr 24, 2024 at 5:51 PM Michael S. Tsirkin wrote:
>
> On Wed, Apr 24, 2024 at 08:44:10AM +0800, Jason Wang wrote:
> > On Tue, Apr 23, 2024 at 4:42 PM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Apr 23, 2024 at 11:09:59AM +0800, Jason Wang wrote:
> > > > On Tue, Apr 23, 2024 at 4:05 AM
Hi Aren,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Aren-Moynihan/dt-bindings-iio-light-stk33xx-add-vdd-and-leda-regulators/20240424-064250
base: https
On Wed Apr 24, 2024 at 10:42 PM EEST, Haitao Huang wrote:
> Hi Jarkko
> On Tue, 16 Apr 2024 11:08:11 -0500, Jarkko Sakkinen
> wrote:
>
> > On Tue Apr 16, 2024 at 5:54 PM EEST, Haitao Huang wrote:
> >> I did declare the configs in the config file but I missed it in my patch
> >> as stated
There is one typo in drivers/gpu/drm/qxl/qxl_gem.c's comment, which
'acess' should be 'access'. So fix it.
Signed-off-by: Xinghui Li
---
drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_gem.c
Puranjay Mohan writes:
> This commit replaces riscv's support for FTRACE_WITH_REGS with support
> for FTRACE_WITH_ARGS. This is required for the ongoing effort to stop
> relying on stop_machine() for RISCV's implementation of ftrace.
>
> The main relevant benefit that this change will bring for
Protection domain mapper is a QMI service providing mapping between
'protection domains' and services supported / allowed in these domains.
For example such mapping is required for loading of the WiFi firmware or
for properly starting up the UCSI / altmode / battery manager support.
The existing
If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr->lock.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Tested-by: Neil Armstrong #
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was started but the corresponding
directory is mounted
1 - 100 of 104 matches
Mail list logo
