[PATCH 0/4] mmc: sdhci-brcmstb: rpmb sharing by claiming host for TZOS

Kamal Dasu posted 4 patches 2 months, 3 weeks ago
There is a newer version of this series
.../hwlock/brcm,brcmstb-hwspinlock.yaml       |  36 +++
.../bindings/mmc/brcm,sdhci-brcmstb.yaml      |  29 ++-
drivers/hwspinlock/Kconfig                    |   9 +
drivers/hwspinlock/Makefile                   |   1 +
drivers/hwspinlock/brcmstb_hwspinlock.c       |  98 +++++++
drivers/mmc/host/sdhci-brcmstb.c              | 243 +++++++++++++++++-
6 files changed, 413 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
create mode 100644 drivers/hwspinlock/brcmstb_hwspinlock.c
[PATCH 0/4] mmc: sdhci-brcmstb: rpmb sharing by claiming host for TZOS
Posted by Kamal Dasu 2 months, 3 weeks ago
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

Kamal Dasu (4):
  dt-bindings: brcmstb-hwspinlock: support for hwspinlock
  hwspinlock: brcmstb hardware semaphore support
  dt-bindings: mmc: add brcmstb share register and hwlocks reference
  mmc: sdhci-brcmstb: rpmb sharing by claiming host for TZOS

 .../hwlock/brcm,brcmstb-hwspinlock.yaml       |  36 +++
 .../bindings/mmc/brcm,sdhci-brcmstb.yaml      |  29 ++-
 drivers/hwspinlock/Kconfig                    |   9 +
 drivers/hwspinlock/Makefile                   |   1 +
 drivers/hwspinlock/brcmstb_hwspinlock.c       |  98 +++++++
 drivers/mmc/host/sdhci-brcmstb.c              | 243 +++++++++++++++++-
 6 files changed, 413 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
 create mode 100644 drivers/hwspinlock/brcmstb_hwspinlock.c

-- 
2.34.1
Re: [PATCH 0/4] mmc: sdhci-brcmstb: rpmb sharing by claiming host for TZOS
Posted by Adrian Hunter 2 months, 1 week ago
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/

> 
> Kamal Dasu (4):
>   dt-bindings: brcmstb-hwspinlock: support for hwspinlock
>   hwspinlock: brcmstb hardware semaphore support
>   dt-bindings: mmc: add brcmstb share register and hwlocks reference
>   mmc: sdhci-brcmstb: rpmb sharing by claiming host for TZOS
> 
>  .../hwlock/brcm,brcmstb-hwspinlock.yaml       |  36 +++
>  .../bindings/mmc/brcm,sdhci-brcmstb.yaml      |  29 ++-
>  drivers/hwspinlock/Kconfig                    |   9 +
>  drivers/hwspinlock/Makefile                   |   1 +
>  drivers/hwspinlock/brcmstb_hwspinlock.c       |  98 +++++++
>  drivers/mmc/host/sdhci-brcmstb.c              | 243 +++++++++++++++++-
>  6 files changed, 413 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
>  create mode 100644 drivers/hwspinlock/brcmstb_hwspinlock.c
>
Re: [PATCH 0/4] mmc: sdhci-brcmstb: rpmb sharing by claiming host for TZOS
Posted by Florian Fainelli 2 months, 1 week ago
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
[PATCH 0/4] mmc: sdhci-brcmstb: rpmb sharing by claiming host for TZOS
Posted by Kamal Dasu 2 months, 3 weeks ago
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.

Kamal Dasu (4):
  dt-bindings: brcmstb-hwspinlock: support for hwspinlock
  hwspinlock: brcmstb hardware semaphore support
  dt-bindings: mmc: add brcmstb share register and hwlocks reference
  mmc: sdhci-brcmstb: rpmb sharing by claiming host for TZOS

 .../hwlock/brcm,brcmstb-hwspinlock.yaml       |  36 +++
 .../bindings/mmc/brcm,sdhci-brcmstb.yaml      |  29 ++-
 drivers/hwspinlock/Kconfig                    |   9 +
 drivers/hwspinlock/Makefile                   |   1 +
 drivers/hwspinlock/brcmstb_hwspinlock.c       |  98 +++++++
 drivers/mmc/host/sdhci-brcmstb.c              | 243 +++++++++++++++++-
 6 files changed, 413 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwlock/brcm,brcmstb-hwspinlock.yaml
 create mode 100644 drivers/hwspinlock/brcmstb_hwspinlock.c

-- 
2.34.1