[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f85367bb-566e-43d6-b405-b896c49c9aa7@broadcom.com>
Date: Thu, 31 Jul 2025 09:43:18 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Adrian Hunter <adrian.hunter@...el.com>,
Kamal Dasu <kamal.dasu@...adcom.com>, andersson@...nel.org,
baolin.wang@...ux.alibaba.com, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, ulf.hansson@...aro.org
Cc: bcm-kernel-feedback-list@...adcom.com, linux-remoteproc@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCH 0/4] mmc: sdhci-brcmstb: rpmb sharing by claiming host for
TZOS
On 7/28/25 02:11, Adrian Hunter wrote:
> On 11/07/2025 18:42, Kamal Dasu wrote:
>> This patch adds support to claim host for TZOS RPMB access and synchronized
>> access to the controller hardware using hwspinlock framework.
>> To achieve this Linux OS and the secure TZOS make use of:
>> - shared hardware semaphore register
>> - a set of SDIO shared work registers and
>> - IPI interrupt registers
>>
>> The currently running OS that needs access to the controller puts itself in its
>> slot of work register and if its next in line it can try to grab the hardware
>> semaphore and complete its mmc requests. The shared work registers indicate next
>> in queue to access the controller, and current agent in the queue. Next agent
>> queue state is changed under the hwspinlock is owned by the current OS accessing
>> the controller hardware before release the semaphore, send and receive IPI
>> interrupts between linux and secure world are used to indicate completion of
>> transaction to the waiting OS. TZOS has its own RPMB driver which accesses
>> partition when it wants to read/write RPMB frames. Current implementation
>> assumes Linux and TZOS as the two work agents.
>>
>> This patchset is an alternative method to initial RFC patch:
>> [PATCH RFC 0/3] mmc: sdhci-brcmstb: Add rpmb sharing support
>> https://lkml.org/lkml/2025/2/6/1711
>
> Does it address Ulf's comments? i.e.
>
> https://lore.kernel.org/all/CAPDyKFrCjo8gGnxmXWP6V39N+b1o62VQH9zwMUNb2_+D3-qrdw@mail.gmail.com/
If you are referring to the fact that Linux is the exclusive owner of
the eMMC controller, then no, that is still not what is being done here,
but we did respond as to why this is done that way, and there was no
subsequent question or comments on my respond to Ulf:
https://lore.kernel.org/all/6328fe8d-c4ea-4945-b6ba-d994403121b5@broadcom.com/
--
Florian
Powered by blists - more mailing lists