lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 4 Sep 2023 22:23:47 +0530
From:   Vignesh Viswanathan <quic_viswanat@...cinc.com>
To:     Bjorn Andersson <andersson@...nel.org>
CC:     <agross@...nel.org>, <konrad.dybcio@...aro.org>,
        <mathieu.poirier@...aro.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-remoteproc@...r.kernel.org>,
        <quic_srichara@...cinc.com>, <quic_varada@...cinc.com>,
        <quic_kathirav@...cinc.com>, <quic_devipriy@...cinc.com>,
        <quic_sjaganat@...cinc.com>
Subject: Re: [PATCH] remoteproc: qcom: Add NOTIFY_FATAL event type to SSR
 subdevice



On 7/16/2023 1:50 AM, Bjorn Andersson wrote:
> On Wed, May 03, 2023 at 11:51:46AM +0530, Vignesh Viswanathan wrote:
>> Currently the SSR subdevice notifies the client driver on crash of the
>> rproc from the recovery workqueue using the BEFORE_SHUTDOWN event.
>> However the client driver might be interested to know that the device
>> has crashed immediately to pause any further transactions with the
>> rproc. This calls for an event to be sent to the driver in the IRQ
>> context as soon as the rproc crashes.
>>
> 
> Please make your argumentation more concrete, I can only guess what
> client driver you're referring to.
> 
> You can do this either by spelling out which actual problem you're
> solving, or better yet, include some patches in the series that actually
> uses this interface.
> 

Hi Bjorn,

Apologies for the delay in response.

The client driver in my scenario is a Wi-Fi driver which is continuously
queuing data to the remoteproc and needs to know if remoteproc crashes
as soon as possible to stop queuing further data and also dump some 
debug statistics on the driver side that could potentially help in debug
of why the remoteproc crashed.

Also in the case with upcoming Wi-Fi 7 targets with multi-link 
operation, the driver might need to know that the remoteproc has crashed
instantly to handle some multi-link specific handling.

The ath11k/ath12k WLAN drivers today partially have support for handling
such FATAL notification but it has not been upstreamed yet.

Reference patch: 
https://git.codelinaro.org/clo/qsdk/oss/system/feeds/wlan-open/-/blob/win.wlan_host_opensource.1.0/mac80211/patches/031-ath11k-print-stats-on-crash.patch 
-- event SUBSYS_PREPARE_FOR_FATAL_SHUTDOWN.

Also, Mukesh mentioned earlier that in some MSM targets with PCIe where 
latency cannot be tolerated, a similar downstream patch adds support for 
"early notifier". If this patch is accepted, the early notifier can also 
be replaced to use the same NOTIFY_FATAL event from SSR Subdevice

https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/commit/7583d24de337aa1bf7c375a7da706af9b995b9a1#a840754ebb0e24e88adbf48177e1abd0830b72d2
https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/commit/257de41c63a5a51a081cc7887cdaa4a46e4d1744

Thanks,
Vignesh

> Regards,
> Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ