[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19507b60-ef03-4fac-96dc-f8700f74c0e1@oss.qualcomm.com>
Date: Sat, 28 Jun 2025 16:00:51 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Komal Bajaj <komal.bajaj@....qualcomm.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org,
Souradeep Chowdhury <quic_schowdhu@...cinc.com>
Subject: Re: [PATCH v2] usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through
secure calls
On 6/28/25 7:44 AM, Dmitry Baryshkov wrote:
> On Fri, Jun 27, 2025 at 06:21:31PM +0530, Komal Bajaj wrote:
>> EUD_MODE_MANAGER2 register is mapped to a memory region that is marked
>> as read-only for HLOS, enforcing access restrictions that prohibit
>> direct memory-mapped writes via writel().
>>
>> Attempts to write to this region from HLOS can result in silent failures
>> or memory access violations, particularly when toggling EUD (Embedded
>> USB Debugger) state. To ensure secure register access, modify the driver
>> to use qcom_scm_io_writel(), which routes the write operation to Qualcomm
>> Secure Channel Monitor (SCM). SCM has the necessary permissions to access
>> protected memory regions, enabling reliable control over EUD state.
>>
>> SC7280, the only user of EUD is also affected, indicating that this could
>> never have worked on a properly fused device.
>
> Most likely SC7280 Chrome platforms were fused differently or used a
> different configuration of the TZ.
They were not fused for production, as I understand
> The question is whether there can be other platforms (e.g. SC7180 Chrome
> or SDM845 Cheeza prototypes) which should use direct register access
> instead of going through the SCM.
TF-A currently needs an update to the SCM MMIO R/W address whitelist,
but in any case, a write from !TZ is not going to be accepted by the
hardware
Konrad
Powered by blists - more mailing lists