.../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
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
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 >
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
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
© 2016 - 2025 Red Hat, Inc.