On Sun, 29 Oct 2023 at 02:07, Steven Rostedt wrote:
>
> From: "Steven Rostedt (Google)"
>
> The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
> is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
> and access to the ei->dentry needs to be done, it sh
On Sat, 28 Oct 2023 16:46:50 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
> is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
> and access to the ei->dentry needs to be done,
From: Masami Hiramatsu (Google)
Check the number of probe target symbols in the target module when
the module is loaded. If the probe is not on the unique name symbols
in the module, it will be rejected at that point.
Note that the symbol which has a unique name in the target module,
it will be
Switch to using OBJ_obj2txt() to calculate and print the pkcs7
signature hash name. This eliminates the need to duplicate libcrypto
NID to name mapping, detect SM3 openssl compile-time support, and
enables using any hashes that openssl and kernel know about. For
example SHA3 are being added for v6.
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set under the eventfs_mutex.
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set under the eventfs_mutex.
Hi!
> With the driver for ktd2026 recently applied to linux-leds[1], the LED
> can be enabled on longcheer l8910 and l9100.
Please make sure sysfs name is consistent with notification LED on
other phones, as documented by well-known-leds.txt.
Best regards,
On 27/10/2023 16:20, Luca Weiss wrote:
> Add the node for the ADSP found on the SC7280 SoC, using standard
> Qualcomm firmware.
>
> The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4
> yupik.dtsi since the other areas also seem to match that file there,
> though I cannot be sure
On 27/10/2023 16:20, Luca Weiss wrote:
> Add the node for the ADSP found on the SC7280 SoC, using standard
> Qualcomm firmware.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 27/10/2023 16:20, Luca Weiss wrote:
> Add the compatibles and constraints for the ADSP, CDSP and WPSS found on
> the SC7280 SoC.
>
> Signed-off-by: Luca Weiss
> ---
> .../bindings/remoteproc/qcom,sc7180-pas.yaml| 21
> +
> 1 file changed, 21 insertions(+)
Reviewe
On 27/10/2023 16:20, Luca Weiss wrote:
> The bindings for sc7280-mpss-pas neither expects a second reg nor a
> reg-names property, which is only required by the sc7280-mss-pil
> bindings.
>
> Move it to sc7280-herobrine-lte-sku.dtsi, the only place where that
> other compatible is used.
>
> Signe
On 27/10/2023 16:20, Luca Weiss wrote:
> The power domains for MPSS on SC7280 are actually named CX and MSS, and
> not CX and MX. Adjust the name which also aligns the bindings with the
> dts and fixes validation.
>
> Fixes: 8bb92d6fd0b3 ("dt-bindings: remoteproc: qcom,sc7180-pas: split into
> se
12 matches
Mail list logo