RE: [PATCH 0/9] Enable dw-mmc multi-card support
So far I saw one comment (an ACK) on PATCH 1/9. There seems no comments on other patches yet. Ulf, (or other maintainers), any comments or suggestions how to move forward for this patch series? Thanks, Liming -Original Message- From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Liming Sun Sent: Friday, October 6, 2017 3:21 PM To: Ulf Hansson ; Rob Herring ; Mark Rutland ; Jaehoon Chung ; Kukjin Kim ; Krzysztof Kozlowski Cc: Liming Sun ; linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org Subject: [PATCH 0/9] Enable dw-mmc multi-card support This series of commits enables the multi-card support for the dw-mmc controller. It includes two parts as below. The first part (patches 1-7) reverts the series of recent commits that removed the multi-card support with comments saying there was no such use case in the real world. Actually this feature is being used in Mellanox Bluefield SoC and has been requested by customers. The second part (patches 8-9) fixes the DesignWare multi-card support according to the dw-mmc databook (synnopsys: DesignWare Cores Mobile Storage Host Databook, 2.70a). It has changes to set the card number into the CMD register to multiplex requests to different cards when working in SD_MMC_CEATA mode, set the CTYPE / CLKENA / CDTHRCTL registers properly according to the spec, and parse the per-card configuration to match the Linux Documentation (bindings/mmc/synopsys-dw-mshc.txt). Liming Sun (9): Revert "Documentation: dw-mshc: deprecate num-slots" Revert "mmc: dw_mmc: remove the unnecessary slot variable" Revert "mmc: dw_mmc: use the 'slot' instead of 'cur_slot'" Revert "mmc: dw_mmc: remove the 'id' arguments about functions relevant to slot" Revert "mmc: dw_mmc: change the array of slots" Revert "mmc: dw_mmc: remove the loop about finding slots" Revert "mmc: dw_mmc: deprecated the "num-slots" property" mmc: dw_mmc: Support two SD_MMC_CE-ATA cards mmc: dw_mmc: Parse slot-specific configuration .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 16 +- drivers/mmc/host/dw_mmc-exynos.c | 4 +- drivers/mmc/host/dw_mmc.c | 277 - drivers/mmc/host/dw_mmc.h | 17 +- 4 files changed, 236 insertions(+), 78 deletions(-) -- 1.8.3.1
RE: [PATCH 0/9] Enable dw-mmc multi-card support
>> Hrm it's so unlucky that your patchset comes a little late. As your >> patch 8 and 9 said, you need them to fix problem for multi-card support, so >> definitely there was no such use case, and even the code was buggy to >> support it right? That makes the code hard to read and maintain, so we >> decide to remove it. Thanks for the feedback. Yes, earlier the multi-card support was buggy indeed. We spent some time to debug it and got it working. >> Havn'e check the databook for details yet, but I think it's ok to >> re-introduce multi-slot support if a real user benefits from it. But you >> need a new patch to silent the log "num-slots property not found, assuming 1 >> slot is available" as we removed all the num-slots from DT at that time. The " num-slots property not found..." log message has already been removed by 8a629d26f back in 2016. Looks like we're good on this one. In dw_mci_probe (), it has code to check pdata->num_slots. If 0, the host->num_slots will be set to 1. So the logic of setting default num_slots seems already there. But correct me if I am wrong. Thanks, Liming -Original Message- From: Shawn Lin [mailto:shawn@rock-chips.com] Sent: Monday, October 16, 2017 9:36 PM To: Liming Sun ; Jaehoon Chung Cc: Ulf Hansson ; Rob Herring ; Mark Rutland ; Kukjin Kim ; Krzysztof Kozlowski ; shawn@rock-chips.com; linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org Subject: Re: [PATCH 0/9] Enable dw-mmc multi-card support On 2017/10/7 3:21, Liming Sun wrote: > This series of commits enables the multi-card support for the dw-mmc > controller. It includes two parts as below. > > The first part (patches 1-7) reverts the series of recent commits that > removed the multi-card support with comments saying there was no such > use case in the real world. Actually this feature is being used in > Mellanox Bluefield SoC and has been requested by customers. Hrm it's so unlucky that your patchset comes a little late. As your patch 8 and 9 said, you need them to fix problem for multi-card support, so definitely there was no such use case, and even the code was buggy to support it right? That makes the code hard to read and maintain, so we decide to remove it. > > The second part (patches 8-9) fixes the DesignWare multi-card support > according to the dw-mmc databook (synnopsys: DesignWare Cores Mobile > Storage Host Databook, 2.70a). It has changes to set the card number > into the CMD register to multiplex requests to different cards when > working in SD_MMC_CEATA mode, set the CTYPE / CLKENA / CDTHRCTL > registers properly according to the spec, and parse the per-card > configuration to match the Linux Documentation > (bindings/mmc/synopsys-dw-mshc.txt). Havn'e check the databook for details yet, but I think it's ok to re-introduce multi-slot support if a real user benefits from it. But you need a new patch to silent the log "num-slots property not found, assuming 1 slot is available" as we removed all the num-slots from DT at that time. > > Liming Sun (9): >Revert "Documentation: dw-mshc: deprecate num-slots" >Revert "mmc: dw_mmc: remove the unnecessary slot variable" >Revert "mmc: dw_mmc: use the 'slot' instead of 'cur_slot'" >Revert "mmc: dw_mmc: remove the 'id' arguments about functions > relevant to slot" >Revert "mmc: dw_mmc: change the array of slots" >Revert "mmc: dw_mmc: remove the loop about finding slots" >Revert "mmc: dw_mmc: deprecated the "num-slots" property" >mmc: dw_mmc: Support two SD_MMC_CE-ATA cards >mmc: dw_mmc: Parse slot-specific configuration > > .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 16 +- > drivers/mmc/host/dw_mmc-exynos.c | 4 +- > drivers/mmc/host/dw_mmc.c | 277 > - > drivers/mmc/host/dw_mmc.h | 17 +- > 4 files changed, 236 insertions(+), 78 deletions(-) >
[PATCH v1 1/1] mmc: core: control EXT_CSD_CACHE_CTRL from device tree
Currently the EXT_CSD_CACHE_CTRL register is controlled by API
mmc_card_broken_hpi(), which only works for the quirks settings.
This commit enhances it to use card->ext_csd.hpi instead. This
flag works for both the quirks and the broken-hpi configuration
in the device tree.
Signed-off-by: Liming Sun
---
drivers/mmc/core/mmc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index bc1bd2c..2f2b65c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1791,8 +1791,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
* If cache size is higher than 0, this indicates
* the existence of cache and it can be turned on.
*/
- if (!mmc_card_broken_hpi(card) &&
- card->ext_csd.cache_size > 0) {
+ if (card->ext_csd.hpi && card->ext_csd.cache_size > 0) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_CACHE_CTRL, 1,
card->ext_csd.generic_cmd6_time);
--
1.8.3.1
RE: [PATCH v1 1/1] mmc: core: control EXT_CSD_CACHE_CTRL from device tree
Thanks for the comment. Yes, I actually have the same question.
The change here is to fix a condition based on the existing code. Probably a
better fix is to get rid of the 'connection'...
-Original Message-
From: Alex Lemberg
Sent: Tuesday, December 4, 2018 11:27 AM
To: Liming Sun ; Ulf Hansson ;
Jaehoon Chung ; David Woods ;
Shawn Lin
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/1] mmc: core: control EXT_CSD_CACHE_CTRL from device
tree
Hi,
On 11/20/18, 10:07 PM, "linux-mmc-ow...@vger.kernel.org on behalf of Liming
Sun" wrote:
Currently the EXT_CSD_CACHE_CTRL register is controlled by API
mmc_card_broken_hpi(), which only works for the quirks settings.
This commit enhances it to use card->ext_csd.hpi instead. This
flag works for both the quirks and the broken-hpi configuration
in the device tree.
Signed-off-by: Liming Sun
---
drivers/mmc/core/mmc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index bc1bd2c..2f2b65c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1791,8 +1791,7 @@ static int mmc_init_card(struct mmc_host *host, u32
ocr,
* If cache size is higher than 0, this indicates
* the existence of cache and it can be turned on.
*/
- if (!mmc_card_broken_hpi(card) &&
- card->ext_csd.cache_size > 0) {
+ if (card->ext_csd.hpi && card->ext_csd.cache_size > 0) {
Any reason for making a connection between HPI and Cache in current driver
implementation?
BTW, I missed it before, but the previous commit making this connection - is
also doesn't make any sense.
Although by the spec FLUSH_CACHE is interruptible command, I don't think we
should prevent devices with no HPI support, using the Cache.
Please correct me if I wrong, but the current driver implementation allows to
send HPI for BKOPS and Sanitize (on timeout error) commands only - so why we
should limit the FLUSH_CACHE command?
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_CACHE_CTRL, 1,
card->ext_csd.generic_cmd6_time);
--
1.8.3.1
[PATCH v1 1/1] mmc: dw_mmc-bluefield: simplify the probe() function
This commit removes the unnecessary of-node check since the
dw_mci_bluefield_match[] structure has only one entry.
Signed-off-by: Liming Sun
---
drivers/mmc/host/dw_mmc-bluefield.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
index 54c3fbb..ed8f225 100644
--- a/drivers/mmc/host/dw_mmc-bluefield.c
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -52,16 +52,7 @@ static void dw_mci_bluefield_set_ios(struct dw_mci *host,
struct mmc_ios *ios)
static int dw_mci_bluefield_probe(struct platform_device *pdev)
{
- const struct dw_mci_drv_data *drv_data = NULL;
- const struct of_device_id *match;
-
- if (pdev->dev.of_node) {
- match = of_match_node(dw_mci_bluefield_match,
- pdev->dev.of_node);
- drv_data = match->data;
- }
-
- return dw_mci_pltfm_register(pdev, drv_data);
+ return dw_mci_pltfm_register(pdev, &bluefield_drv_data);
}
static struct platform_driver dw_mci_bluefield_pltfm_driver = {
--
1.8.3.1
[PATCH v3 1/3] mmc: dw_mmc-bluefield: Add driver extension
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Signed-off-by: Liming Sun
---
drivers/mmc/host/Kconfig| 9 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/dw_mmc-bluefield.c | 72 +
3 files changed, 82 insertions(+)
create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c..26ac6b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -717,6 +717,15 @@ config MMC_DW_K3
Synopsys DesignWare Memory Card Interface driver. Select this option
for platforms based on Hisilicon K3 SoC's.
+config MMC_DW_BLUEFIELD
+ tristate "BlueField specific extensions for Synopsys DW Memory Card
Interface"
+ depends on MMC_DW
+ select MMC_DW_PLTFM
+ help
+ This selects support for Mellanox BlueField SoC specific extensions to
+ the Synopsys DesignWare Memory Card Interface driver. Select this
+ option for platforms based on Mellanox BlueField SoC's.
+
config MMC_DW_PCI
tristate "Synopsys Designware MCI support on PCI bus"
depends on MMC_DW && PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 6aead24..267b3f1 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-k3.o
obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o
+obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
new file mode 100644
index 000..12067b1
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Mellanox Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ u32 regs;
+
+ /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT. */
+ regs = mci_readl(host, UHS_REG_EXT);
+ regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
+ mci_writel(host, UHS_REG_EXT, regs);
+}
+
+static const struct dw_mci_drv_data bluefield_drv_data = {
+ .set_ios= dw_mci_bluefield_set_ios
+};
+
+static const struct of_device_id dw_mci_bluefield_match[] = {
+ { .compatible = "mellanox,bluefield-dw-mshc",
+ .data = &bluefield_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_bluefield_match);
+
+static int dw_mci_bluefield_probe(struct platform_device *pdev)
+{
+ const struct dw_mci_drv_data *drv_data = NULL;
+ const struct of_device_id *match;
+
+ if (pdev->dev.of_node) {
+ match = of_match_node(dw_mci_bluefield_match,
+ pdev->dev.of_node);
+ drv_data = match->data;
+ }
+
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_bluefield_pltfm_driver = {
+ .probe = dw_mci_bluefield_probe,
+ .remove = dw_mci_pltfm_remove,
+ .driver = {
+ .name = "dwmmc_bluefield",
+ .of_match_table = dw_mci_bluefield_match,
+ .pm = &dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_bluefield_pltfm_driver);
+
+MODULE_DESCRIPTION("BlueField DW Multimedia Card driver");
+MODULE_AUTHOR("Mellanox Technologies");
+MODULE_LICENSE("GPL v2");
--
1.8.3.1
[PATCH v3 2/3] dt-bindings: mmc: Add binding for BlueField SoC
This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
extension on Mellanox BlueField SoC platform.
Signed-off-by: Liming Sun
---
.../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
new file mode 100644
index 000..ee0dd61
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
@@ -0,0 +1,29 @@
+* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
+ Mobile Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
+specific extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+ - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
+specific extensions.
+
+Example:
+
+ /* Mellanox Bluefield SoC MMC */
+ dwmmc0@4,0 {
+ compatible = "mellanox,bluefield-dw-mshc";
+ reg = <4 0x8000 0x400>;
+ interrupts = <32>;
+ fifo-depth = <0x100>;
+ clock-frequency = <2400>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ };
--
1.8.3.1
[PATCH v3 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver
This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index ecf6137..43464ab 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_K3=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_DW_BLUEFIELD=y CONFIG_MMC_SUNXI=y CONFIG_MMC_BCM2835=y CONFIG_MMC_SDHCI_XENON=y -- 1.8.3.1
RE: [PATCH v2 2/3] Documentation: bluefield-dw-mshc: add DT description
Thanks. Updated in v3 2/3.
- Liming
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, April 27, 2018 3:51 PM
> To: Liming Sun
> Cc: Ulf Hansson ; Mark Rutland
> ; Jaehoon Chung ;
> Catalin Marinas ; Will Deacon
> ; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 2/3] Documentation: bluefield-dw-mshc: add DT
> description
>
> On Mon, Apr 23, 2018 at 11:32:21AM -0400, Liming Sun wrote:
> > This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
> > extension on Mellanox BlueField SoC platform.
>
> "dt-bindings: mmc: " is preferred subject prefix.
>
> >
> > Signed-off-by: Liming Sun
> > ---
> > .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29
> ++
> > 1 file changed, 29 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-
> dw-mshc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-
> mshc.txt b/Documentation/devicetree/bindings/mmc/bluefield-dw-
> mshc.txt
> > new file mode 100644
> > index 000..ee0dd61
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
> > @@ -0,0 +1,29 @@
> > +* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
> > + Mobile Storage Host Controller
> > +
> > +Read synopsys-dw-mshc.txt for more details
> > +
> > +The Synopsys designware mobile storage host controller is used to
> interface
> > +a SoC with storage medium such as eMMC or SD/MMC cards. This file
> documents
> > +differences between the core Synopsys dw mshc controller properties
> described
> > +by synopsys-dw-mshc.txt and the properties used by the Mellanox
> Bluefield SoC
> > +specific extensions to the Synopsys Designware Mobile Storage Host
> Controller.
> > +
> > +Required Properties:
> > +
> > +* compatible: should be one of the following.
> > + - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield
> SoC
> > +specific extensions.
> > +
> > +Example:
> > +
> > + /* Mellanox Bluefield SoC MMC */
> > + dwmmc0@4,0 {
>
> mmc@...
>
> Doesn't look like a correct unit-address either.
>
> > + compatible = "mellanox,bluefield-dw-mshc";
> > + reg = <4 0x8000 0x400>;
> > + interrupts = <32>;
> > + fifo-depth = <0x100>;
> > + clock-frequency = <2400>;
> > + bus-width = <8>;
> > + cap-mmc-highspeed;
> > + };
> > --
> > 1.8.3.1
> >
[PATCH v4 1/3] mmc: dw_mmc-bluefield: Add driver extension
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Signed-off-by: Liming Sun
---
drivers/mmc/host/Kconfig| 9 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/dw_mmc-bluefield.c | 72 +
3 files changed, 82 insertions(+)
create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c..26ac6b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -717,6 +717,15 @@ config MMC_DW_K3
Synopsys DesignWare Memory Card Interface driver. Select this option
for platforms based on Hisilicon K3 SoC's.
+config MMC_DW_BLUEFIELD
+ tristate "BlueField specific extensions for Synopsys DW Memory Card
Interface"
+ depends on MMC_DW
+ select MMC_DW_PLTFM
+ help
+ This selects support for Mellanox BlueField SoC specific extensions to
+ the Synopsys DesignWare Memory Card Interface driver. Select this
+ option for platforms based on Mellanox BlueField SoC's.
+
config MMC_DW_PCI
tristate "Synopsys Designware MCI support on PCI bus"
depends on MMC_DW && PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 6aead24..267b3f1 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-k3.o
obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o
+obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
new file mode 100644
index 000..12067b1
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Mellanox Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ u32 regs;
+
+ /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT. */
+ regs = mci_readl(host, UHS_REG_EXT);
+ regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
+ mci_writel(host, UHS_REG_EXT, regs);
+}
+
+static const struct dw_mci_drv_data bluefield_drv_data = {
+ .set_ios= dw_mci_bluefield_set_ios
+};
+
+static const struct of_device_id dw_mci_bluefield_match[] = {
+ { .compatible = "mellanox,bluefield-dw-mshc",
+ .data = &bluefield_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_bluefield_match);
+
+static int dw_mci_bluefield_probe(struct platform_device *pdev)
+{
+ const struct dw_mci_drv_data *drv_data = NULL;
+ const struct of_device_id *match;
+
+ if (pdev->dev.of_node) {
+ match = of_match_node(dw_mci_bluefield_match,
+ pdev->dev.of_node);
+ drv_data = match->data;
+ }
+
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_bluefield_pltfm_driver = {
+ .probe = dw_mci_bluefield_probe,
+ .remove = dw_mci_pltfm_remove,
+ .driver = {
+ .name = "dwmmc_bluefield",
+ .of_match_table = dw_mci_bluefield_match,
+ .pm = &dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_bluefield_pltfm_driver);
+
+MODULE_DESCRIPTION("BlueField DW Multimedia Card driver");
+MODULE_AUTHOR("Mellanox Technologies");
+MODULE_LICENSE("GPL v2");
--
1.8.3.1
[PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC
This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
extension on Mellanox BlueField SoC platform.
Signed-off-by: Liming Sun
---
.../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
new file mode 100644
index 000..75bd844d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
@@ -0,0 +1,29 @@
+* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
+ Mobile Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
+specific extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+ - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
+specific extensions.
+
+Example:
+
+ /* Mellanox Bluefield SoC MMC */
+ mmc@0x6008000 {
+ compatible = "mellanox,bluefield-dw-mshc";
+ reg = <0x6008000 0x400>;
+ interrupts = <32>;
+ fifo-depth = <0x100>;
+ clock-frequency = <2400>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ };
--
1.8.3.1
RE: [PATCH v3 2/3] dt-bindings: mmc: Add binding for BlueField SoC
Sorry, my mistake. I missed the last one in the v3 comments.
Fixed it in v4 2/3.
Thanks,
Liming
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, May 1, 2018 8:48 AM
> To: Liming Sun
> Cc: Ulf Hansson ; Mark Rutland
> ; Jaehoon Chung ;
> Catalin Marinas ; Will Deacon
> ; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 2/3] dt-bindings: mmc: Add binding for BlueField SoC
>
> On Mon, Apr 30, 2018 at 10:51:07AM -0400, Liming Sun wrote:
> > This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
> > extension on Mellanox BlueField SoC platform.
> >
> > Signed-off-by: Liming Sun
> > ---
> > .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29
> ++
> > 1 file changed, 29 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-
> dw-mshc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-
> mshc.txt b/Documentation/devicetree/bindings/mmc/bluefield-dw-
> mshc.txt
> > new file mode 100644
> > index 000..ee0dd61
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
> > @@ -0,0 +1,29 @@
> > +* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
> > + Mobile Storage Host Controller
> > +
> > +Read synopsys-dw-mshc.txt for more details
> > +
> > +The Synopsys designware mobile storage host controller is used to
> interface
> > +a SoC with storage medium such as eMMC or SD/MMC cards. This file
> documents
> > +differences between the core Synopsys dw mshc controller properties
> described
> > +by synopsys-dw-mshc.txt and the properties used by the Mellanox
> Bluefield SoC
> > +specific extensions to the Synopsys Designware Mobile Storage Host
> Controller.
> > +
> > +Required Properties:
> > +
> > +* compatible: should be one of the following.
> > + - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield
> SoC
> > +specific extensions.
> > +
> > +Example:
> > +
> > + /* Mellanox Bluefield SoC MMC */
> > + dwmmc0@4,0 {
>
> Still the same issues.
>
> mmc@...
>
> And the unit-address looks wrong.
>
> > + compatible = "mellanox,bluefield-dw-mshc";
> > + reg = <4 0x8000 0x400>;
> > + interrupts = <32>;
> > + fifo-depth = <0x100>;
> > + clock-frequency = <2400>;
> > + bus-width = <8>;
> > + cap-mmc-highspeed;
> > + };
> > --
> > 1.8.3.1
> >
[PATCH v4 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver
This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index ecf6137..43464ab 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_K3=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_DW_BLUEFIELD=y CONFIG_MMC_SUNXI=y CONFIG_MMC_BCM2835=y CONFIG_MMC_SDHCI_XENON=y -- 1.8.3.1
[PATCH v5 1/3] mmc: dw_mmc-bluefield: Add driver extension
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Cc: sta...@kernel.org
Signed-off-by: Liming Sun
Reviewed-by: David Woods
---
drivers/mmc/host/Kconfig| 9 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/dw_mmc-bluefield.c | 72 +
3 files changed, 82 insertions(+)
create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c..26ac6b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -717,6 +717,15 @@ config MMC_DW_K3
Synopsys DesignWare Memory Card Interface driver. Select this option
for platforms based on Hisilicon K3 SoC's.
+config MMC_DW_BLUEFIELD
+ tristate "BlueField specific extensions for Synopsys DW Memory Card
Interface"
+ depends on MMC_DW
+ select MMC_DW_PLTFM
+ help
+ This selects support for Mellanox BlueField SoC specific extensions to
+ the Synopsys DesignWare Memory Card Interface driver. Select this
+ option for platforms based on Mellanox BlueField SoC's.
+
config MMC_DW_PCI
tristate "Synopsys Designware MCI support on PCI bus"
depends on MMC_DW && PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 6aead24..267b3f1 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-k3.o
obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o
+obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
new file mode 100644
index 000..12067b1
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Mellanox Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ u32 regs;
+
+ /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT. */
+ regs = mci_readl(host, UHS_REG_EXT);
+ regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
+ mci_writel(host, UHS_REG_EXT, regs);
+}
+
+static const struct dw_mci_drv_data bluefield_drv_data = {
+ .set_ios= dw_mci_bluefield_set_ios
+};
+
+static const struct of_device_id dw_mci_bluefield_match[] = {
+ { .compatible = "mellanox,bluefield-dw-mshc",
+ .data = &bluefield_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_bluefield_match);
+
+static int dw_mci_bluefield_probe(struct platform_device *pdev)
+{
+ const struct dw_mci_drv_data *drv_data = NULL;
+ const struct of_device_id *match;
+
+ if (pdev->dev.of_node) {
+ match = of_match_node(dw_mci_bluefield_match,
+ pdev->dev.of_node);
+ drv_data = match->data;
+ }
+
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_bluefield_pltfm_driver = {
+ .probe = dw_mci_bluefield_probe,
+ .remove = dw_mci_pltfm_remove,
+ .driver = {
+ .name = "dwmmc_bluefield",
+ .of_match_table = dw_mci_bluefield_match,
+ .pm = &dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_bluefield_pltfm_driver);
+
+MODULE_DESCRIPTION("BlueField DW Multimedia Card driver");
+MODULE_AUTHOR("Mellanox Technologies");
+MODULE_LICENSE("GPL v2");
--
1.8.3.1
[PATCH v5 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver
This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Cc: sta...@kernel.org Signed-off-by: Liming Sun Reviewed-by: David Woods --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index ecf6137..43464ab 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_K3=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_DW_BLUEFIELD=y CONFIG_MMC_SUNXI=y CONFIG_MMC_BCM2835=y CONFIG_MMC_SDHCI_XENON=y -- 1.8.3.1
[PATCH v5 2/3] dt-bindings: mmc: Add binding for BlueField SoC
This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
extension on Mellanox BlueField SoC platform.
Cc: sta...@kernel.org
Signed-off-by: Liming Sun
Reviewed-by: David Woods
Reviewed-by: Rob Herring
---
.../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
new file mode 100644
index 000..b0f0999
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
@@ -0,0 +1,29 @@
+* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
+ Mobile Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
+specific extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+ - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
+specific extensions.
+
+Example:
+
+ /* Mellanox Bluefield SoC MMC */
+ mmc@6008000 {
+ compatible = "mellanox,bluefield-dw-mshc";
+ reg = <0x6008000 0x400>;
+ interrupts = <32>;
+ fifo-depth = <0x100>;
+ clock-frequency = <2400>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ };
--
1.8.3.1
RE: [PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC
Thanks! Updated in v5 2/3.
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, May 1, 2018 12:25 PM
> To: Liming Sun
> Cc: Ulf Hansson ; Mark Rutland
> ; Jaehoon Chung ;
> Catalin Marinas ; Will Deacon
> ; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC
>
> On Tue, May 01, 2018 at 10:32:34AM -0400, Liming Sun wrote:
> > This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
> > extension on Mellanox BlueField SoC platform.
> >
> > Signed-off-by: Liming Sun
> > ---
> > .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29
> ++
> > 1 file changed, 29 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-
> dw-mshc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-
> mshc.txt b/Documentation/devicetree/bindings/mmc/bluefield-dw-
> mshc.txt
> > new file mode 100644
> > index 000..75bd844d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
> > @@ -0,0 +1,29 @@
> > +* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
> > + Mobile Storage Host Controller
> > +
> > +Read synopsys-dw-mshc.txt for more details
> > +
> > +The Synopsys designware mobile storage host controller is used to
> interface
> > +a SoC with storage medium such as eMMC or SD/MMC cards. This file
> documents
> > +differences between the core Synopsys dw mshc controller properties
> described
> > +by synopsys-dw-mshc.txt and the properties used by the Mellanox
> Bluefield SoC
> > +specific extensions to the Synopsys Designware Mobile Storage Host
> Controller.
> > +
> > +Required Properties:
> > +
> > +* compatible: should be one of the following.
> > + - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield
> SoC
> > +specific extensions.
> > +
> > +Example:
> > +
> > + /* Mellanox Bluefield SoC MMC */
> > + mmc@0x6008000 {
>
> Drop the '0x'.
>
> Building your dtb with 'W=1' will warn on this.
>
> With that,
>
> Reviewed-by: Rob Herring
>
> > + compatible = "mellanox,bluefield-dw-mshc";
> > + reg = <0x6008000 0x400>;
> > + interrupts = <32>;
> > + fifo-depth = <0x100>;
> > + clock-frequency = <2400>;
> > + bus-width = <8>;
> > + cap-mmc-highspeed;
> > + };
> > --
> > 1.8.3.1
> >
RE: [PATCH v5 1/3] mmc: dw_mmc-bluefield: Add driver extension
Please see response inline.
Thanks,
Liming
> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Tuesday, May 1, 2018 9:02 PM
> To: Liming Sun ; Mark Rutland
> ; Jaehoon Chung ;
> Catalin Marinas ; Will Deacon
>
> Cc: Ulf Hansson ; Rob Herring
> ; shawn@rock-chips.com; linux-
> m...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; sta...@kernel.org
> Subject: Re: [PATCH v5 1/3] mmc: dw_mmc-bluefield: Add driver extension
>
> On 2018/5/2 2:19, Liming Sun wrote:
> > This commit adds extension to the dw_mmc driver for Mellanox BlueField
> > SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
> > this SoC.
> >
> > Cc: sta...@kernel.org
>
> Why?
[Liming] This is recommended value from HW team. Without this setting, the eMMC
controller and cards can be found in Linux, but not stable. Writing to it could
caused
CRC error.
>
> > Signed-off-by: Liming Sun
> > Reviewed-by: David Woods
> > ---
> > drivers/mmc/host/Kconfig| 9 +
> > drivers/mmc/host/Makefile | 1 +
> > drivers/mmc/host/dw_mmc-bluefield.c | 72
> +
> > 3 files changed, 82 insertions(+)
> > create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 9589f9c..26ac6b5 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -717,6 +717,15 @@ config MMC_DW_K3
> > Synopsys DesignWare Memory Card Interface driver. Select this
> option
> > for platforms based on Hisilicon K3 SoC's.
> >
> > +config MMC_DW_BLUEFIELD
>
> And did you have feedback of my comment in V2？
> http://lists-archives.com/linux-kernel/29104830-mmc-dw_mmc-bluefield-
> add-driver-extension.html
>
> > + tristate "BlueField specific extensions for Synopsys DW Memory Card
> Interface"
> > + depends on MMC_DW
> > + select MMC_DW_PLTFM
> > + help
> > + This selects support for Mellanox BlueField SoC specific extensions
> to
> > + the Synopsys DesignWare Memory Card Interface driver. Select this
> > + option for platforms based on Mellanox BlueField SoC's.
> > +
> > config MMC_DW_PCI
> > tristate "Synopsys Designware MCI support on PCI bus"
> > depends on MMC_DW && PCI
> > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> > index 6aead24..267b3f1 100644
> > --- a/drivers/mmc/host/Makefile
> > +++ b/drivers/mmc/host/Makefile
> > @@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-
> k3.o
> > obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
> > obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
> > obj-$(CONFIG_MMC_DW_ZX) += dw_mmc-zx.o
> > +obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
> > obj-$(CONFIG_MMC_SH_MMCIF)+= sh_mmcif.o
> > obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
> > obj-$(CONFIG_MMC_VUB300) += vub300.o
> > diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
> b/drivers/mmc/host/dw_mmc-bluefield.c
> > new file mode 100644
> > index 000..12067b1
> > --- /dev/null
> > +++ b/drivers/mmc/host/dw_mmc-bluefield.c
> > @@ -0,0 +1,72 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 Mellanox Technologies.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "dw_mmc.h"
> > +#include "dw_mmc-pltfm.h"
> > +
> > +static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct
> mmc_ios *ios)
> > +{
> > + u32 regs;
> > +
> > + /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT.
> */
> > + regs = mci_readl(host, UHS_REG_EXT);
> > + regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
> > + mci_writel(host, UHS_REG_EXT, regs);
> > +}
> > +
> > +static const struct dw_mci_drv_data bluefield_drv_data = {
> > + .set_ios= dw_mci_bluefield_set_ios
> > +};
> > +
> > +static const s
RE: [PATCH v9] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy for the comments. Please see the responses below.
I'll also post the v10 patch after this email.
Regards,
Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Wednesday, February 13, 2019 1:11 PM
> To: Liming Sun
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: Re: [PATCH v9] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> On Wed, Feb 13, 2019 at 3:27 PM Liming Sun wrote:
> >
> > This commit adds the TmFifo platform driver for Mellanox BlueField
> > Soc. TmFifo is a shared FIFO which enables external host machine
> > to exchange data with the SoC via USB or PCIe. The driver is based
> > on virtio framework and has console and network access enabled.
>
> Thanks for an update, my comments below.
>
> Again, to Mellanox: guys, please, establish internal mailing list for
> review and don't come with such quality of code.
Yes, the patch went through internal review. I updated the
Reviewed-by section of the commit message.
>
> Next time I would like to see Reviewed-by from Mellanox people I know,
> like Vadim or Leon.
>
> > +config MLXBF_TMFIFO
> > + tristate "Mellanox BlueField SoC TmFifo platform driver"
>
> > + depends on ARM64 && ACPI && VIRTIO_CONSOLE && VIRTIO_NET
>
> Split this to three logical parts.
Updated in v10.
>
> > + help
> > + Say y here to enable TmFifo support. The TmFifo driver provides
> > + platform driver support for the TmFifo which supports console
> > + and networking based on the virtio framework.
>
> > obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
> > obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
> > +obj-$(CONFIG_MLXBF_TMFIFO) += mlxbf-tmfifo.o
>
> I would suggest to keep it sorted.
Updated in v10.
>
> > +#define MLXBF_TMFIFO_TX_DATA 0x0
>
> I suggest to use same fixed format for offsets.
> Here, for example, 0x00 would be better.
>
> > +#define MLXBF_TMFIFO_TX_STS__COUNT_RMASK 0x1ff
> > +#define MLXBF_TMFIFO_TX_STS__COUNT_MASK 0x1ff
>
> #include
> ...
> GENMASK()
Updated in v10.
>
> > +#define MLXBF_TMFIFO_TX_CTL__LWM_RMASK 0xff
> > +#define MLXBF_TMFIFO_TX_CTL__LWM_MASK 0xff
>
> > +#define MLXBF_TMFIFO_TX_CTL__HWM_RMASK 0xff
> > +#define MLXBF_TMFIFO_TX_CTL__HWM_MASK 0xff00
>
> > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RMASK 0x1ff
> > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_MASK 0x1ffULL
>
> GENMASK() / GENMASK_ULL()
Updated in v10.
>
> > +#define MLXBF_TMFIFO_RX_STS__COUNT_RMASK 0x1ff
> > +#define MLXBF_TMFIFO_RX_STS__COUNT_MASK 0x1ff
>
> GENMASK()
Updated in v10.
>
> > +#define MLXBF_TMFIFO_RX_CTL__LWM_RMASK 0xff
> > +#define MLXBF_TMFIFO_RX_CTL__LWM_MASK 0xff
>
> > +#define MLXBF_TMFIFO_RX_CTL__HWM_RMASK 0xff
> > +#define MLXBF_TMFIFO_RX_CTL__HWM_MASK 0xff00
>
> > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK 0x1ff
> > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_MASK 0x1ffULL
>
> Ditto.
Updated in v10.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Do you need all of them?
Cleaned up quite a few and updated in v10.
>
> > +#define MLXBF_TMFIFO_VRING_SIZE1024
>
> SZ_1K ?
Updated in v10.
>
> > +/* Console Tx buffer size. */
> > +#define MLXBF_TMFIFO_CONS_TX_BUF_SIZE (32 * 1024)
>
> SZ_32K ?
Updated in v10.
>
> > +/* House-keeping timer interval. */
> > +static int mlxbf_tmfifo_timer_interval = HZ / 10;
>
> > +/* Global lock. */
>
> Noise. Either explain what it protects, or remove.
Removed in v10.
>
> > +static DEFINE_MUTEX(mlxbf_tmfifo_lock);
>
> > +/* Struct declaration. */
>
> Noise.
Removed in v10.
>
> > +/* Structure to maintain the ring state. */
> > +struct mlxbf_tmfifo_vring {
> > + void *va; /* virtual address */
> > + dma_addr_t dma; /* dma address */
> > + struct virtqueue *vq;
[PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v9->v10: Fixes for comments from Andy: - Use devm_ioremap_resource() instead of devm_ioremap(). - Use kernel-doc comments. - Keep Makefile contents sorted. - Use same fixed format for offsets. - Use SZ_1K/SZ_32K instead of 1024/23*1024. - Remove unnecessary comments. - Use one style for max numbers. - More comments for mlxbf_tmfifo_vdev and mlxbf_tmfifo_data_64bit. - Use globally defined MTU instead of new definition. - Remove forward declaration of mlxbf_tmfifo_remove(). - Remove PAGE_ALIGN() for dma_alloc_coherent)(). - Remove the cast of "struct vring *". - Check return result of test_and_set_bit(). - Add a macro mlxbt_vdev_to_tmfifo(). - Several other minor coding style comments. Comment not applied: - "Shouldn't be rather helper in EFI lib in kernel" Looks like efi.get_variable() is the way I found in the kernel tree. - "this one is not protected anyhow? Potential race condition" In mlxbf_tmfifo_console_tx(), the spin-lock is used to protect the 'tx_buf' only, not the FIFO writes. So there is no race condition. - "Is __packed needed in mlxbf_tmfifo_msg_hdr". Yes, it is needed to make sure the structure is 8 bytes. Fixes for comments from Vadim: - Use tab in mlxbf-tmfifo-regs.h - Use kernel-doc comments for struct mlxbf_tmfifo_msg_hdr and mlxbf_tmfifo_irq_info as well. - Use _MAX instead of _CNT in the macro definition to be consistent. - Fix the MODULE_LICENSE. - Use BIT_ULL() instead of BIT(). - Remove argument of 'avail' for mlxbf_tmfifo_rxtx_header() and mlxbf_tmfifo_rxtx_word() - Revise logic in mlxbf_tmfifo_rxtx_one_desc() to remove the WARN_ON(). - Change "union mlxbf_tmfifo_u64 u" to "union mlxbf_tmfifo_u64 buf" in mlxbf_tmfifo_rxtx_word(). - Change date type of vring_change from 'int' to 'bool'. - Remove the blank lines after Signed-off. - Don’t use declaration in the middle. - Make the network header initialization in some more elegant way. - Change label done to mlxbf_tmfifo_desc_done. - Remove some unnecessary comments, and several other misc coding style comments. - Simplify code logic in mlxbf_tmfifo_virtio_notify() New changes by Liming: - Simplify the Rx/Tx function arguments to make it more readable. v8->v9: Fixes for comments from Andy: - Use modern devm_xxx() API instead. Fixes for comments from Vadim: - Split the Rx/Tx function into smaller funcitons. - File name, copyright information. - Function and variable name conversion. - Local variable and indent coding styles. - Remove unnecessary 'inline' declarations. - Use devm_xxx() APIs. - Move the efi_char16_t MAC address definition to global. - Fix warnings reported by 'checkpatch --strict'. - Fix warnings reported by 'make CF="-D__CHECK_ENDIAN__"'. - Change select VIRTIO_xxx to depends on VIRTIO_ in Kconfig. - Merge mlxbf_tmfifo_vdev_tx_buf_push() and mlxbf_tmfifo_vdev_tx_buf_pop(). - Add union to avoid casting between __le64 and u64. - Several other misc coding style comments. New changes by Liming: - Removed the DT binding documentation since only ACPI is supported for now by UEFI on the SoC. v8: Re-submit under drivers/platform/mellanox for the target-side platform driver only. v7: Added host side drivers into the same patch set. v5~v6: Coding style fix. v1~v4: Initial version for directory drivers/soc/mellanox. --- drivers/platform/mellanox/Kconfig | 12 +- drivers/platform/mellanox/Makefile|1 + drivers/platform/mellanox/mlxbf-tmfifo-regs.h | 63 ++ drivers/platform/mellanox/mlxbf-tmfifo.c | 1342 + 4 files changed, 1417 insertions(+), 1 deletion(-) create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo-regs.h create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo.c diff --git a/drivers/platform/mellanox/Kconfig b/drivers/platform/mellanox/Kconfig index cd8a908..530fe7e 100644 --- a/drivers/platform/mellanox/Kconfig +++ b/drivers/platform/mellanox/Kconfig @@ -5,7 +5,7 @@ menuconfig MELLANOX_PLATFORM bool "Platform support for Mellanox hardware" - depends on X86 || ARM || COMPILE_TEST + depends on X86 || ARM || ARM64 || COMPILE_TEST ---help--- Say Y here to get to see options for platform support for Mellanox systems. This option alon
[PATCH v8 0/2] TmFifo platform driver for Mellanox BlueField SoC
This patch series implements the device side platform driver support for the TmFifo on Mellanox BlueField SoC. TmFifo is part of the RShim component. It provides FIFOs to communicate with external host machine via USB or PCIe (SmartNic case). External host machine has driver to access the RShim component as well, which is not covered in this patch series. This patch series was submitted to drivers/soc in previous versions. This version (v8) re-submit it to drivers/platform according to the received comments / suggestions. Patch v8 1/2 has changes according to some comments from Vadim Pasternak during Mellanox internal review. Patch v8 2/2 was reviewed by Rob Herring before, but might need a second look since the location of the driver code is moved. Liming Sun (2): platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc dt-bindings: soc: Add TmFifo binding for Mellanox BlueField SoC .../devicetree/bindings/soc/mellanox/tmfifo.txt| 23 + drivers/platform/mellanox/Kconfig | 13 +- drivers/platform/mellanox/Makefile |1 + drivers/platform/mellanox/mlxbf-tmfifo-regs.h | 67 + drivers/platform/mellanox/mlxbf-tmfifo.c | 1289 5 files changed, 1392 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo-regs.h create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo.c -- 1.8.3.1
[PATCH v8 2/2] dt-bindings: soc: Add TmFifo binding for Mellanox BlueField SoC
Add devicetree bindings for the TmFifo which is found on Mellanox
BlueField SoCs.
Reviewed-by: Rob Herring
Reviewed-by: David Woods
Signed-off-by: Liming Sun
---
.../devicetree/bindings/soc/mellanox/tmfifo.txt| 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
diff --git a/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
b/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
new file mode 100644
index 000..8a13fa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
@@ -0,0 +1,23 @@
+* Mellanox BlueField SoC TmFifo
+
+BlueField TmFifo provides a shared FIFO between the target and the
+external host machine, which can be accessed by external host via
+USB or PCIe. In the current tmfifo driver, this FIFO has been demuxed
+to implement virtual console and network interface based on the virtio
+framework.
+
+Required properties:
+
+- compatible: Should be "mellanox,bf-tmfifo"
+- reg: Physical base address and length of Rx/Tx block
+- interrupts: The interrupt number of Rx low water mark, Rx high water mark
+ Tx low water mark, Tx high water mark respectively.
+
+Example:
+
+tmfifo@800a20 {
+ compatible = "mellanox,bf-tmfifo";
+ reg = <0x00800a20 0x0018
+ 0x00800a40 0x0018>;
+ interrupts = <41, 42, 43, 44>;
+};
--
1.8.3.1
[PATCH v8 1/2] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: David Woods Signed-off-by: Liming Sun --- drivers/platform/mellanox/Kconfig | 13 +- drivers/platform/mellanox/Makefile|1 + drivers/platform/mellanox/mlxbf-tmfifo-regs.h | 67 ++ drivers/platform/mellanox/mlxbf-tmfifo.c | 1289 + 4 files changed, 1369 insertions(+), 1 deletion(-) create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo-regs.h create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo.c diff --git a/drivers/platform/mellanox/Kconfig b/drivers/platform/mellanox/Kconfig index cd8a908..a565070 100644 --- a/drivers/platform/mellanox/Kconfig +++ b/drivers/platform/mellanox/Kconfig @@ -5,7 +5,7 @@ menuconfig MELLANOX_PLATFORM bool "Platform support for Mellanox hardware" - depends on X86 || ARM || COMPILE_TEST + depends on X86 || ARM || ARM64 || COMPILE_TEST ---help--- Say Y here to get to see options for platform support for Mellanox systems. This option alone does not add any kernel code. @@ -34,4 +34,15 @@ config MLXREG_IO to system resets operation, system reset causes monitoring and some kinds of mux selection. +config MLXBF_TMFIFO + tristate "Mellanox BlueField SoC TmFifo platform driver" + depends on ARM64 + default m + select VIRTIO_CONSOLE + select VIRTIO_NET + help + Say y here to enable TmFifo support. The TmFifo driver provides + platform driver support for the TmFifo which supports console + and networking based on the virtio framework. + endif # MELLANOX_PLATFORM diff --git a/drivers/platform/mellanox/Makefile b/drivers/platform/mellanox/Makefile index 57074d9c..f0c061d 100644 --- a/drivers/platform/mellanox/Makefile +++ b/drivers/platform/mellanox/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o +obj-$(CONFIG_MLXBF_TMFIFO) += mlxbf-tmfifo.o diff --git a/drivers/platform/mellanox/mlxbf-tmfifo-regs.h b/drivers/platform/mellanox/mlxbf-tmfifo-regs.h new file mode 100644 index 000..90c9c2cf --- /dev/null +++ b/drivers/platform/mellanox/mlxbf-tmfifo-regs.h @@ -0,0 +1,67 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2019, Mellanox Technologies. All rights reserved. + */ + +#ifndef __MLXBF_TMFIFO_REGS_H__ +#define __MLXBF_TMFIFO_REGS_H__ + +#include + +#define MLXBF_TMFIFO_TX_DATA 0x0 + +#define MLXBF_TMFIFO_TX_STS 0x8 +#define MLXBF_TMFIFO_TX_STS__LENGTH 0x0001 +#define MLXBF_TMFIFO_TX_STS__COUNT_SHIFT 0 +#define MLXBF_TMFIFO_TX_STS__COUNT_WIDTH 9 +#define MLXBF_TMFIFO_TX_STS__COUNT_RESET_VAL 0 +#define MLXBF_TMFIFO_TX_STS__COUNT_RMASK 0x1ff +#define MLXBF_TMFIFO_TX_STS__COUNT_MASK 0x1ff + +#define MLXBF_TMFIFO_TX_CTL 0x10 +#define MLXBF_TMFIFO_TX_CTL__LENGTH 0x0001 +#define MLXBF_TMFIFO_TX_CTL__LWM_SHIFT 0 +#define MLXBF_TMFIFO_TX_CTL__LWM_WIDTH 8 +#define MLXBF_TMFIFO_TX_CTL__LWM_RESET_VAL 128 +#define MLXBF_TMFIFO_TX_CTL__LWM_RMASK 0xff +#define MLXBF_TMFIFO_TX_CTL__LWM_MASK 0xff +#define MLXBF_TMFIFO_TX_CTL__HWM_SHIFT 8 +#define MLXBF_TMFIFO_TX_CTL__HWM_WIDTH 8 +#define MLXBF_TMFIFO_TX_CTL__HWM_RESET_VAL 128 +#define MLXBF_TMFIFO_TX_CTL__HWM_RMASK 0xff +#define MLXBF_TMFIFO_TX_CTL__HWM_MASK 0xff00 +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_SHIFT 32 +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_WIDTH 9 +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RESET_VAL 256 +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RMASK 0x1ff +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_MASK 0x1ffULL + +#define MLXBF_TMFIFO_RX_DATA 0x0 + +#define MLXBF_TMFIFO_RX_STS 0x8 +#define MLXBF_TMFIFO_RX_STS__LENGTH 0x0001 +#define MLXBF_TMFIFO_RX_STS__COUNT_SHIFT 0 +#define MLXBF_TMFIFO_RX_STS__COUNT_WIDTH 9 +#define MLXBF_TMFIFO_RX_STS__COUNT_RESET_VAL 0 +#define MLXBF_TMFIFO_RX_STS__COUNT_RMASK 0x1ff +#define MLXBF_TMFIFO_RX_STS__COUNT_MASK 0x1ff + +#define MLXBF_TMFIFO_RX_CTL 0x10 +#define MLXBF_TMFIFO_RX_CTL__LENGTH 0x0001 +#define MLXBF_TMFIFO_RX_CTL__LWM_SHIFT 0 +#define MLXBF_TMFIFO_RX_CTL__LWM_WIDTH 8 +#define MLXBF_TMFIFO_RX_CTL__LWM_RESET_VAL 128 +#define MLXBF_TMFIFO_RX_CTL__LWM_RMASK 0xff +#define MLXBF_TMFIFO_RX_CTL__LWM_MASK 0xff +#define MLXBF_TMFIFO_RX_CTL__HWM_SHIFT 8 +#define MLXBF_TMFIFO_RX_CTL__HWM_WIDTH 8 +#define MLXBF_TMFIFO_RX_CTL__HWM_RESET_VAL 128 +#define MLXBF_TMFIFO_RX_CTL__HWM_RMASK 0xff +#define MLXBF_TMFIFO_RX_CTL__HWM_MASK 0xff00 +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_SHIFT 32 +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_WIDTH 9 +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RESET_VAL 256 +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK 0x1ff +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_MASK 0x1ff0
[PATCH v11] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v11->v11: rebase & resend, no new changes v10->v11: Fixes for comments from Andy: - Use GENMASK_ULL() instead of GENMASK() in mlxbf-tmfifo-regs.h - Removed the cpu_to_le64()/le64_to_cpu() conversion since readq()/writeq() already takes care of it. - Remove the "if (irq)" check in mlxbf_tmfifo_disable_irqs(). - Add "u32 count" temp variable in mlxbf_tmfifo_get_tx_avail(). - Clean up mlxbf_tmfifo_get_cfg_mac(), use ETH_ALEN instead of value 6. - Change the tx_buf to use Linux existing 'struct circ_buf'. Comment not applied: - "Change macro mlxbf_vdev_to_tmfifo() to one line" Couldn't fit in one line with 80 chracters - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" This is SoC, the device won't be closed or detached. The only case is when the driver is unloaded. So it appears ok to use devm_kzalloc() since it's allocated during probe() and released during module unload. Comments from Vadim: OK v9->v10: Fixes for comments from Andy: - Use devm_ioremap_resource() instead of devm_ioremap(). - Use kernel-doc comments. - Keep Makefile contents sorted. - Use same fixed format for offsets. - Use SZ_1K/SZ_32K instead of 1024/23*1024. - Remove unnecessary comments. - Use one style for max numbers. - More comments for mlxbf_tmfifo_vdev and mlxbf_tmfifo_data_64bit. - Use globally defined MTU instead of new definition. - Remove forward declaration of mlxbf_tmfifo_remove(). - Remove PAGE_ALIGN() for dma_alloc_coherent)(). - Remove the cast of "struct vring *". - Check return result of test_and_set_bit(). - Add a macro mlxbt_vdev_to_tmfifo(). - Several other minor coding style comments. Comment not applied: - "Shouldn't be rather helper in EFI lib in kernel" Looks like efi.get_variable() is the way I found in the kernel tree. - "this one is not protected anyhow? Potential race condition" In mlxbf_tmfifo_console_tx(), the spin-lock is used to protect the 'tx_buf' only, not the FIFO writes. So there is no race condition. - "Is __packed needed in mlxbf_tmfifo_msg_hdr". Yes, it is needed to make sure the structure is 8 bytes. Fixes for comments from Vadim: - Use tab in mlxbf-tmfifo-regs.h - Use kernel-doc comments for struct mlxbf_tmfifo_msg_hdr and mlxbf_tmfifo_irq_info as well. - Use _MAX instead of _CNT in the macro definition to be consistent. - Fix the MODULE_LICENSE. - Use BIT_ULL() instead of BIT(). - Remove argument of 'avail' for mlxbf_tmfifo_rxtx_header() and mlxbf_tmfifo_rxtx_word() - Revise logic in mlxbf_tmfifo_rxtx_one_desc() to remove the WARN_ON(). - Change "union mlxbf_tmfifo_u64 u" to "union mlxbf_tmfifo_u64 buf" in mlxbf_tmfifo_rxtx_word(). - Change date type of vring_change from 'int' to 'bool'. - Remove the blank lines after Signed-off. - Don’t use declaration in the middle. - Make the network header initialization in some more elegant way. - Change label done to mlxbf_tmfifo_desc_done. - Remove some unnecessary comments, and several other misc coding style comments. - Simplify code logic in mlxbf_tmfifo_virtio_notify() New changes by Liming: - Simplify the Rx/Tx function arguments to make it more readable. v8->v9: Fixes for comments from Andy: - Use modern devm_xxx() API instead. Fixes for comments from Vadim: - Split the Rx/Tx function into smaller funcitons. - File name, copyright information. - Function and variable name conversion. - Local variable and indent coding styles. - Remove unnecessary 'inline' declarations. - Use devm_xxx() APIs. - Move the efi_char16_t MAC address definition to global. - Fix warnings reported by 'checkpatch --strict'. - Fix warnings reported by 'make CF="-D__CHECK_ENDIAN__"'. - Change select VIRTIO_xxx to depends on VIRTIO_ in Kconfig. - Merge mlxbf_tmfifo_vdev_tx_buf_push() and mlxbf_tmfifo_vdev_tx_buf_pop(). - Add union to avoid casting between __le64 and u64. - Several other misc coding style comments. New changes by Liming: - Removed the DT binding documentation since only ACPI is supported for now by UEFI on the SoC. v8: Re-submit under drivers/platform/mellanox for the target-side platform driver only. v7: Added host
RE: [PATCH v2] mmc: sdhci-of-dwcmshc: add ACPI support for BlueField-3 SoC
Uffe,
Can I confirm whether you meant the 'master' branch or some other branch?
I did a rebase of master and didn't see Shawn Lin's changes in the
sdhci-of-dwcmshc.c
Thanks,
Liming
> -Original Message-
> From: Ulf Hansson
> Sent: Friday, March 19, 2021 10:12 AM
> To: Liming Sun
> Cc: Adrian Hunter ; Khalil Blaiech
> ; linux-mmc ; Linux
> Kernel Mailing List
> Subject: Re: [PATCH v2] mmc: sdhci-of-dwcmshc: add ACPI support for
> BlueField-3 SoC
>
> On Wed, 17 Mar 2021 at 00:20, Liming Sun wrote:
> >
> > This commit adds ACPI support in the sdhci-of-dwcmshc driver for
> > BlueField-3 SoC. It has changes to only use the clock hierarchy
> > for Deviec Tree since the clk is not supported by ACPI. Instead,
> > ACPI can define 'clock-frequency' which is parsed by existing
> > sdhci_get_property(). This clock value will be returned in function
> > dwcmshc_get_max_clock().
> >
> > Signed-off-by: Liming Sun
> > Reviewed-by: Khalil Blaiech
>
> Liming, can you please rebase and repost a new version. It seems like
> Shawn Lin's patch that added rockchip platform support causes the
> conflict.
>
> Kind regards
> Uffe
>
>
> > ---
> > v1->v2:
> >Changes for comments from Adrian Hunter :
> >- Make changes in sdhci-of-dwcmshc instead.
> > v1: Initial version which was done in sdhci-acpi.c
> > ---
> > drivers/mmc/host/sdhci-of-dwcmshc.c | 50
> ++---
> > 1 file changed, 36 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
> b/drivers/mmc/host/sdhci-of-dwcmshc.c
> > index 59d8d96..bf5037a 100644
> > --- a/drivers/mmc/host/sdhci-of-dwcmshc.c
> > +++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
> > @@ -7,6 +7,7 @@
> > * Author: Jisheng Zhang
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -51,6 +52,16 @@ static void dwcmshc_adma_write_desc(struct
> sdhci_host *host, void **desc,
> > sdhci_adma_write_desc(host, desc, addr, len, cmd);
> > }
> >
> > +static unsigned int dwcmshc_get_max_clock(struct sdhci_host *host)
> > +{
> > + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > +
> > + if (pltfm_host->clk)
> > + return sdhci_pltfm_clk_get_max_clock(host);
> > + else
> > + return pltfm_host->clock;
> > +}
> > +
> > static void dwcmshc_check_auto_cmd23(struct mmc_host *mmc,
> > struct mmc_request *mrq)
> > {
> > @@ -104,7 +115,7 @@ static void dwcmshc_set_uhs_signaling(struct
> sdhci_host *host,
> > .set_clock = sdhci_set_clock,
> > .set_bus_width = sdhci_set_bus_width,
> > .set_uhs_signaling = dwcmshc_set_uhs_signaling,
> > - .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> > + .get_max_clock = dwcmshc_get_max_clock,
> > .reset = sdhci_reset,
> > .adma_write_desc= dwcmshc_adma_write_desc,
> > };
> > @@ -117,6 +128,7 @@ static void dwcmshc_set_uhs_signaling(struct
> sdhci_host *host,
> >
> > static int dwcmshc_probe(struct platform_device *pdev)
> > {
> > + struct device *dev = &pdev->dev;
> > struct sdhci_pltfm_host *pltfm_host;
> > struct sdhci_host *host;
> > struct dwcmshc_priv *priv;
> > @@ -131,7 +143,7 @@ static int dwcmshc_probe(struct platform_device
> *pdev)
> > /*
> > * extra adma table cnt for cross 128M boundary handling.
> > */
> > - extra = DIV_ROUND_UP_ULL(dma_get_required_mask(&pdev->dev),
> SZ_128M);
> > + extra = DIV_ROUND_UP_ULL(dma_get_required_mask(dev), SZ_128M);
> > if (extra > SDHCI_MAX_SEGS)
> > extra = SDHCI_MAX_SEGS;
> > host->adma_table_cnt += extra;
> > @@ -139,19 +151,21 @@ static int dwcmshc_probe(struct platform_device
> *pdev)
> > pltfm_host = sdhci_priv(host);
> > priv = sdhci_pltfm_priv(pltfm_host);
> >
> > - pltfm_host->clk = devm_clk_get(&pdev->dev, "core");
> > - if (IS_ERR(pltfm_host->clk)) {
> > - err = PTR_ERR(pltfm_host->clk);
> > - dev_err(&pdev->dev, "failed to get core clk: %d\n", err);
> > - goto free_pltfm;
> > + if (dev->of_node) {
> > + pl
[PATCH v3] mmc: sdhci-of-dwcmshc: add ACPI support for BlueField-3 SoC
This commit adds ACPI support in the sdhci-of-dwcmshc driver for
BlueField-3 SoC. It has changes to only use the clock hierarchy
for Deviec Tree since the clk is not supported by ACPI. Instead,
ACPI can define 'clock-frequency' which is parsed by existing
sdhci_get_property(). This clock value will be returned in function
dwcmshc_get_max_clock().
Signed-off-by: Liming Sun
Reviewed-by: Khalil Blaiech
---
v2->v3:
Rebase to mmc next.
v1->v2:
Changes for comments from Adrian Hunter :
- Make changes in sdhci-of-dwcmshc instead.
v1: Initial version which was done in sdhci-acpi.c
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 50 ++---
1 file changed, 36 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
b/drivers/mmc/host/sdhci-of-dwcmshc.c
index 0687368..1113a56 100644
--- a/drivers/mmc/host/sdhci-of-dwcmshc.c
+++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
@@ -7,6 +7,7 @@
* Author: Jisheng Zhang
*/
+#include
#include
#include
#include
@@ -94,6 +95,16 @@ static void dwcmshc_adma_write_desc(struct sdhci_host *host,
void **desc,
sdhci_adma_write_desc(host, desc, addr, len, cmd);
}
+static unsigned int dwcmshc_get_max_clock(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+ if (pltfm_host->clk)
+ return sdhci_pltfm_clk_get_max_clock(host);
+ else
+ return pltfm_host->clock;
+}
+
static void dwcmshc_check_auto_cmd23(struct mmc_host *mmc,
struct mmc_request *mrq)
{
@@ -248,7 +259,7 @@ static void dwcmshc_rk3568_set_clock(struct sdhci_host
*host, unsigned int clock
.set_clock = sdhci_set_clock,
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = dwcmshc_set_uhs_signaling,
- .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .get_max_clock = dwcmshc_get_max_clock,
.reset = sdhci_reset,
.adma_write_desc= dwcmshc_adma_write_desc,
};
@@ -323,8 +334,16 @@ static int dwcmshc_rk3568_init(struct sdhci_host *host,
struct dwcmshc_priv *dwc
};
MODULE_DEVICE_TABLE(of, sdhci_dwcmshc_dt_ids);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id sdhci_dwcmshc_acpi_ids[] = {
+ { .id = "MLNXBF30" },
+ {}
+};
+#endif
+
static int dwcmshc_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_host *host;
struct dwcmshc_priv *priv;
@@ -347,7 +366,7 @@ static int dwcmshc_probe(struct platform_device *pdev)
/*
* extra adma table cnt for cross 128M boundary handling.
*/
- extra = DIV_ROUND_UP_ULL(dma_get_required_mask(&pdev->dev), SZ_128M);
+ extra = DIV_ROUND_UP_ULL(dma_get_required_mask(dev), SZ_128M);
if (extra > SDHCI_MAX_SEGS)
extra = SDHCI_MAX_SEGS;
host->adma_table_cnt += extra;
@@ -355,19 +374,21 @@ static int dwcmshc_probe(struct platform_device *pdev)
pltfm_host = sdhci_priv(host);
priv = sdhci_pltfm_priv(pltfm_host);
- pltfm_host->clk = devm_clk_get(&pdev->dev, "core");
- if (IS_ERR(pltfm_host->clk)) {
- err = PTR_ERR(pltfm_host->clk);
- dev_err(&pdev->dev, "failed to get core clk: %d\n", err);
- goto free_pltfm;
- }
- err = clk_prepare_enable(pltfm_host->clk);
- if (err)
- goto free_pltfm;
+ if (dev->of_node) {
+ pltfm_host->clk = devm_clk_get(dev, "core");
+ if (IS_ERR(pltfm_host->clk)) {
+ err = PTR_ERR(pltfm_host->clk);
+ dev_err(dev, "failed to get core clk: %d\n", err);
+ goto free_pltfm;
+ }
+ err = clk_prepare_enable(pltfm_host->clk);
+ if (err)
+ goto free_pltfm;
- priv->bus_clk = devm_clk_get(&pdev->dev, "bus");
- if (!IS_ERR(priv->bus_clk))
- clk_prepare_enable(priv->bus_clk);
+ priv->bus_clk = devm_clk_get(dev, "bus");
+ if (!IS_ERR(priv->bus_clk))
+ clk_prepare_enable(priv->bus_clk);
+ }
err = mmc_of_parse(host->mmc);
if (err)
@@ -489,6 +510,7 @@ static int dwcmshc_resume(struct device *dev)
.name = "sdhci-dwcmshc",
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
.of_match_table = sdhci_dwcmshc_dt_ids,
+ .acpi_match_table = ACPI_PTR(sdhci_dwcmshc_acpi_ids),
.pm = &dwcmshc_pmops,
},
.probe = dwcmshc_probe,
--
1.8.3.1
RE: [PATCH v2] mmc: sdhci-of-dwcmshc: add ACPI support for BlueField-3 SoC
> -Original Message- > From: Ulf Hansson > Sent: Monday, March 22, 2021 5:51 AM > To: Liming Sun > Cc: Adrian Hunter ; Khalil Blaiech > ; linux-mmc ; Linux > Kernel Mailing List > Subject: Re: [PATCH v2] mmc: sdhci-of-dwcmshc: add ACPI support for > BlueField-3 SoC > > On Fri, 19 Mar 2021 at 21:23, Liming Sun wrote: > > > > Uffe, > > > > Can I confirm whether you meant the 'master' branch or some other > branch? > > I did a rebase of master and didn't see Shawn Lin's changes in the sdhci-of- > dwcmshc.c > > git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next Thanks! Rebased and posted v3. > > [...] > > Kind regards > Uffe
RE: [PATCH v1 1/1] mmc: sdhci-acpi: Add support for NVIDIA BlueField-3 SoC
Thanks Adrian. Yes, I did consider adding this ACPI support into
sdhci-of-dwcmshc.c, but not sure which one is the preferred way.
Is this (sdhci-of-dwcmshc.c) what you recommend? I'll post the revised changes
in patch v2.
> -Original Message-
> From: Adrian Hunter
> Sent: Monday, March 15, 2021 4:34 AM
> To: Liming Sun ; Ulf Hansson ;
> Khalil Blaiech
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v1 1/1] mmc: sdhci-acpi: Add support for NVIDIA
> BlueField-3 SoC
>
> On 12/03/21 3:48 pm, Liming Sun wrote:
> > This commit adds ACPI support for the BlueField-3 SoC which uses
> > the DWC_mshc eMMC controller. The boundary check logic in static
> > function dwcmshc_adma_write_desc() comes from sdhci-of-dwcmshc.c.
>
> Did you consider adding ACPI support to sdhci-of-dwcmshc.c ?
> Other drivers have taken that approach, see sdhci-xenon.c or sdhci-iproc.c
>
> >
> > Signed-off-by: Liming Sun
> > Reviewed-by: Khalil Blaiech
> > ---
> > drivers/mmc/host/sdhci-acpi.c | 64
> +++
> > 1 file changed, 64 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
> > index 54205e3..6448e94e 100644
> > --- a/drivers/mmc/host/sdhci-acpi.c
> > +++ b/drivers/mmc/host/sdhci-acpi.c
> > @@ -716,6 +716,68 @@ static int sdhci_acpi_emmc_amd_probe_slot(struct
> platform_device *pdev,
> > .priv_size = sizeof(struct amd_sdhci_host),
> > };
> >
> > +/* Check DMA address/length boundary. */
> > +static inline bool dwcmshc_adma_boundary_ok(dma_addr_t addr, int len)
> > +{
> > + return (addr | (SZ_128M - 1)) == ((addr + len - 1) | (SZ_128M - 1));
> > +}
> > +
> > +/*
> > + * If DMA addr spans 128MB boundary, we split the DMA transfer into two
> > + * so that each DMA transfer doesn't exceed the boundary.
> > + */
> > +static void dwcmshc_adma_write_desc(struct sdhci_host *host, void
> **desc,
> > + dma_addr_t addr, int len, unsigned int cmd)
> > +{
> > + int tmplen, offset;
> > +
> > + if (likely(!len || dwcmshc_adma_boundary_ok(addr, len))) {
> > + sdhci_adma_write_desc(host, desc, addr, len, cmd);
> > + return;
> > + }
> > +
> > + offset = addr & (SZ_128M - 1);
> > + tmplen = SZ_128M - offset;
> > + sdhci_adma_write_desc(host, desc, addr, tmplen, cmd);
> > +
> > + addr += tmplen;
> > + len -= tmplen;
> > + sdhci_adma_write_desc(host, desc, addr, len, cmd);
> > +}
> > +
> > +static int sdhci_acpi_emmc_nvda_bf_probe_slot(struct platform_device
> *pdev,
> > + struct acpi_device *adev)
> > +{
> > + struct sdhci_acpi_host *c = platform_get_drvdata(pdev);
> > + struct sdhci_host *host = c->host;
> > + u32 extra;
> > +
> > + /* Extra adma table cnt for cross 128M boundary handling. */
> > + extra = DIV_ROUND_UP_ULL(dma_get_required_mask(&pdev->dev),
> SZ_128M);
> > + extra = min(extra, (u32)SDHCI_MAX_SEGS);
> > + host->adma_table_cnt += extra;
> > +
> > + return 0;
> > +}
> > +
> > +static const struct sdhci_ops sdhci_acpi_ops_nvda_bf = {
> > + .set_clock = sdhci_set_clock,
> > + .set_bus_width = sdhci_set_bus_width,
> > + .set_uhs_signaling = sdhci_set_uhs_signaling,
> > + .reset = sdhci_reset,
> > + .adma_write_desc= dwcmshc_adma_write_desc,
> > +};
> > +
> > +static const struct sdhci_acpi_chip sdhci_acpi_chip_nvda_bf = {
> > + .ops = &sdhci_acpi_ops_nvda_bf,
> > +};
> > +
> > +static const struct sdhci_acpi_slot sdhci_acpi_slot_nvda_bf_emmc = {
> > + .chip = &sdhci_acpi_chip_nvda_bf,
> > + .caps = MMC_CAP_8_BIT_DATA |
> MMC_CAP_NONREMOVABLE,
> > + .probe_slot = sdhci_acpi_emmc_nvda_bf_probe_slot,
> > +};
> > +
> > struct sdhci_acpi_uid_slot {
> > const char *hid;
> > const char *uid;
> > @@ -740,6 +802,7 @@ struct sdhci_acpi_uid_slot {
> > { "QCOM8051", NULL, &sdhci_acpi_slot_qcom_sd_3v },
> > { "QCOM8052", NULL, &sdhci_acpi_slot_qcom_sd },
> > { "AMDI0040", NULL, &sdhci_acpi_slot_amd_emmc },
> > + { "MLNXBF30", NULL, &sdhci_acpi_slot_nvda_bf_emmc },
> > { },
> > };
> >
> > @@ -757,6 +820,7 @@ struct sdhci_acpi_uid_slot {
> > { "QCOM8051" },
> > { "QCOM8052" },
> > { "AMDI0040" },
> > + { "MLNXBF30" },
> > { },
> > };
> > MODULE_DEVICE_TABLE(acpi, sdhci_acpi_ids);
> >
[PATCH v2] mmc: sdhci-of-dwcmshc: add ACPI support for BlueField-3 SoC
This commit adds ACPI support in the sdhci-of-dwcmshc driver for
BlueField-3 SoC. It has changes to only use the clock hierarchy
for Deviec Tree since the clk is not supported by ACPI. Instead,
ACPI can define 'clock-frequency' which is parsed by existing
sdhci_get_property(). This clock value will be returned in function
dwcmshc_get_max_clock().
Signed-off-by: Liming Sun
Reviewed-by: Khalil Blaiech
---
v1->v2:
Changes for comments from Adrian Hunter :
- Make changes in sdhci-of-dwcmshc instead.
v1: Initial version which was done in sdhci-acpi.c
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 50 ++---
1 file changed, 36 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
b/drivers/mmc/host/sdhci-of-dwcmshc.c
index 59d8d96..bf5037a 100644
--- a/drivers/mmc/host/sdhci-of-dwcmshc.c
+++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
@@ -7,6 +7,7 @@
* Author: Jisheng Zhang
*/
+#include
#include
#include
#include
@@ -51,6 +52,16 @@ static void dwcmshc_adma_write_desc(struct sdhci_host *host,
void **desc,
sdhci_adma_write_desc(host, desc, addr, len, cmd);
}
+static unsigned int dwcmshc_get_max_clock(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+ if (pltfm_host->clk)
+ return sdhci_pltfm_clk_get_max_clock(host);
+ else
+ return pltfm_host->clock;
+}
+
static void dwcmshc_check_auto_cmd23(struct mmc_host *mmc,
struct mmc_request *mrq)
{
@@ -104,7 +115,7 @@ static void dwcmshc_set_uhs_signaling(struct sdhci_host
*host,
.set_clock = sdhci_set_clock,
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = dwcmshc_set_uhs_signaling,
- .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .get_max_clock = dwcmshc_get_max_clock,
.reset = sdhci_reset,
.adma_write_desc= dwcmshc_adma_write_desc,
};
@@ -117,6 +128,7 @@ static void dwcmshc_set_uhs_signaling(struct sdhci_host
*host,
static int dwcmshc_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_host *host;
struct dwcmshc_priv *priv;
@@ -131,7 +143,7 @@ static int dwcmshc_probe(struct platform_device *pdev)
/*
* extra adma table cnt for cross 128M boundary handling.
*/
- extra = DIV_ROUND_UP_ULL(dma_get_required_mask(&pdev->dev), SZ_128M);
+ extra = DIV_ROUND_UP_ULL(dma_get_required_mask(dev), SZ_128M);
if (extra > SDHCI_MAX_SEGS)
extra = SDHCI_MAX_SEGS;
host->adma_table_cnt += extra;
@@ -139,19 +151,21 @@ static int dwcmshc_probe(struct platform_device *pdev)
pltfm_host = sdhci_priv(host);
priv = sdhci_pltfm_priv(pltfm_host);
- pltfm_host->clk = devm_clk_get(&pdev->dev, "core");
- if (IS_ERR(pltfm_host->clk)) {
- err = PTR_ERR(pltfm_host->clk);
- dev_err(&pdev->dev, "failed to get core clk: %d\n", err);
- goto free_pltfm;
+ if (dev->of_node) {
+ pltfm_host->clk = devm_clk_get(dev, "core");
+ if (IS_ERR(pltfm_host->clk)) {
+ err = PTR_ERR(pltfm_host->clk);
+ dev_err(dev, "failed to get core clk: %d\n", err);
+ goto free_pltfm;
+ }
+ err = clk_prepare_enable(pltfm_host->clk);
+ if (err)
+ goto free_pltfm;
+
+ priv->bus_clk = devm_clk_get(dev, "bus");
+ if (!IS_ERR(priv->bus_clk))
+ clk_prepare_enable(priv->bus_clk);
}
- err = clk_prepare_enable(pltfm_host->clk);
- if (err)
- goto free_pltfm;
-
- priv->bus_clk = devm_clk_get(&pdev->dev, "bus");
- if (!IS_ERR(priv->bus_clk))
- clk_prepare_enable(priv->bus_clk);
err = mmc_of_parse(host->mmc);
if (err)
@@ -239,11 +253,19 @@ static int dwcmshc_resume(struct device *dev)
};
MODULE_DEVICE_TABLE(of, sdhci_dwcmshc_dt_ids);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id sdhci_dwcmshc_acpi_ids[] = {
+ { .id = "MLNXBF30" },
+ {}
+};
+#endif
+
static struct platform_driver sdhci_dwcmshc_driver = {
.driver = {
.name = "sdhci-dwcmshc",
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
.of_match_table = sdhci_dwcmshc_dt_ids,
+ .acpi_match_table = ACPI_PTR(sdhci_dwcmshc_acpi_ids),
.pm = &dwcmshc_pmops,
},
.probe = dwcmshc_probe,
--
1.8.3.1
RE: [PATCH v1 1/1] mmc: sdhci-acpi: Add support for NVIDIA BlueField-3 SoC
> -Original Message- > From: Adrian Hunter > Sent: Monday, March 15, 2021 3:20 PM > To: Liming Sun ; Khalil Blaiech ; > Ulf Hansson > Cc: linux-...@vger.kernel.org; Linux Kernel Mailing List ker...@vger.kernel.org> > Subject: Re: [PATCH v1 1/1] mmc: sdhci-acpi: Add support for NVIDIA > BlueField-3 SoC > > On 15/03/21 7:00 pm, Liming Sun wrote: > > Thanks Adrian. Yes, I did consider adding this ACPI support into sdhci-of- > dwcmshc.c, but not sure which one is the preferred way. > > Is this (sdhci-of-dwcmshc.c) what you recommend? I'll post the revised > changes in patch v2. > > Yes, that is generally preferred I think. Thanks Adrian. Posted "[PATCH v2] mmc: sdhci-of-dwcmshc: add ACPI support for BlueField-3 SoC" for this change.
[PATCH v1 1/1] mmc: sdhci-acpi: Add support for NVIDIA BlueField-3 SoC
This commit adds ACPI support for the BlueField-3 SoC which uses
the DWC_mshc eMMC controller. The boundary check logic in static
function dwcmshc_adma_write_desc() comes from sdhci-of-dwcmshc.c.
Signed-off-by: Liming Sun
Reviewed-by: Khalil Blaiech
---
drivers/mmc/host/sdhci-acpi.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 54205e3..6448e94e 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -716,6 +716,68 @@ static int sdhci_acpi_emmc_amd_probe_slot(struct
platform_device *pdev,
.priv_size = sizeof(struct amd_sdhci_host),
};
+/* Check DMA address/length boundary. */
+static inline bool dwcmshc_adma_boundary_ok(dma_addr_t addr, int len)
+{
+ return (addr | (SZ_128M - 1)) == ((addr + len - 1) | (SZ_128M - 1));
+}
+
+/*
+ * If DMA addr spans 128MB boundary, we split the DMA transfer into two
+ * so that each DMA transfer doesn't exceed the boundary.
+ */
+static void dwcmshc_adma_write_desc(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd)
+{
+ int tmplen, offset;
+
+ if (likely(!len || dwcmshc_adma_boundary_ok(addr, len))) {
+ sdhci_adma_write_desc(host, desc, addr, len, cmd);
+ return;
+ }
+
+ offset = addr & (SZ_128M - 1);
+ tmplen = SZ_128M - offset;
+ sdhci_adma_write_desc(host, desc, addr, tmplen, cmd);
+
+ addr += tmplen;
+ len -= tmplen;
+ sdhci_adma_write_desc(host, desc, addr, len, cmd);
+}
+
+static int sdhci_acpi_emmc_nvda_bf_probe_slot(struct platform_device *pdev,
+ struct acpi_device *adev)
+{
+ struct sdhci_acpi_host *c = platform_get_drvdata(pdev);
+ struct sdhci_host *host = c->host;
+ u32 extra;
+
+ /* Extra adma table cnt for cross 128M boundary handling. */
+ extra = DIV_ROUND_UP_ULL(dma_get_required_mask(&pdev->dev), SZ_128M);
+ extra = min(extra, (u32)SDHCI_MAX_SEGS);
+ host->adma_table_cnt += extra;
+
+ return 0;
+}
+
+static const struct sdhci_ops sdhci_acpi_ops_nvda_bf = {
+ .set_clock = sdhci_set_clock,
+ .set_bus_width = sdhci_set_bus_width,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
+ .reset = sdhci_reset,
+ .adma_write_desc= dwcmshc_adma_write_desc,
+};
+
+static const struct sdhci_acpi_chip sdhci_acpi_chip_nvda_bf = {
+ .ops = &sdhci_acpi_ops_nvda_bf,
+};
+
+static const struct sdhci_acpi_slot sdhci_acpi_slot_nvda_bf_emmc = {
+ .chip = &sdhci_acpi_chip_nvda_bf,
+ .caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
+ .probe_slot = sdhci_acpi_emmc_nvda_bf_probe_slot,
+};
+
struct sdhci_acpi_uid_slot {
const char *hid;
const char *uid;
@@ -740,6 +802,7 @@ struct sdhci_acpi_uid_slot {
{ "QCOM8051", NULL, &sdhci_acpi_slot_qcom_sd_3v },
{ "QCOM8052", NULL, &sdhci_acpi_slot_qcom_sd },
{ "AMDI0040", NULL, &sdhci_acpi_slot_amd_emmc },
+ { "MLNXBF30", NULL, &sdhci_acpi_slot_nvda_bf_emmc },
{ },
};
@@ -757,6 +820,7 @@ struct sdhci_acpi_uid_slot {
{ "QCOM8051" },
{ "QCOM8052" },
{ "AMDI0040" },
+ { "MLNXBF30" },
{ },
};
MODULE_DEVICE_TABLE(acpi, sdhci_acpi_ids);
--
1.8.3.1
[PATCH v6 1/2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
This commit adds the bootctl platform driver for Mellanox BlueField
Soc, which queries secure state and controls the eMMC boot partition
swapping by sending SMC calls to ATF running at EL3.
Below are the sequences of typical use case.
1. User requests boot partition swapping, which could be on-demand or
during boot-image upgrade via UEFI capsule;
2. This bootctl driver handles the request and sends SMC call
to ATF. ATF programs register BREADCRUMB0 which has value
preserved during warm reset. It also programs eMMC to swap
the boot partition;
3. After software reset (rebooting), ATF BL1 (BootRom) checks
register BREADCRUMB0 and enable watchdog if configured;
4. If booting fails, the watchdog timer will trigger rebooting.
In such case, ATF Boot ROM will switch the boot partition
back to the previous one. This is a robust feature and used
to prevent failure during boot partition upgrade.
Reviewed-by: Vadim Pasternak
Signed-off-by: Liming Sun
---
v5->v6:
Fixes for comments from Mark:
- Changed to use device attributes (DEVICE_ATTR_xx) instead of
driver attributes (DRIVER_ATTR_xx) for the exported sysfs
attributes.
Comments from Arnd:
- "drivers/platform/mellanox/ would be a good place for drivers
running on a host platform with a bluefield accelerator card as
an add-on, but as I understand, this is a driver that actually
just runs in Linux on the bluefield itself, so it should go in a
different place."
It seems hard to find another better place to move this code. This
directory name appears like a natual fit (if we don't want to use
new directory drivers/soc/mellanox instead). Also it is guarded by
'depends on ARM64' in the Kconfig. So I leave it here for now
unless we have strong opinion to move it to other places.
v4->v5:
Fixes for comments from Andy:
- Added ABI documentation;
- Remove the extra 'const' in mlxbf_bootctl_svc_uuid_str definition;
- Remove the mlxbf_bootctl_smc_call0() MACRO to use function
call directly;
- Return more descriptive string ('invalid action') in
mlxbf_bootctl_reset_action_to_string();
- Check return value of the mlxbf_bootctl_smc() in function
post_reset_wdog_show() and reset_action_show();
- Revise the sprintf() line in reset_action_show() into one line;
- Move the 'action = ' assignment out of the declarations
in reset_action_store() and check return value of
mlxbf_bootctl_reset_action_to_val() in this function;
- Removed Redundant parens in reset_action_store();
- Check return code of the smc_call in second_reset_action_show(),
merge the 'name = ' assignment into the sprintf() directly;
- Move the 'action = ' assignment out of the declaration block
in second_reset_action_store();
- Remove redundant blank line and parents in lifecycle_state_show();
- Split declaration and assignment in secure_boot_fuse_state_show();
- use BIT() in secure_boot_fuse_state_show() and simplify code in
this function to split the logic of message choice and flag flip;
Also removed the 'key !=0 ' check since it's not needed;
- Added comma in mlxbf_bootctl_attr_group definition.
- Removed un-needed '& 0xFF' logic in mlxbf_bootctl_guid_match();
- Use temp variable for the result of the smc call in
mlxbf_bootctl_probe();
- Use dev_warn() instead of dev_err() in mlxbf_bootctl_probe();
- Removed the ACPI_PTR usage in the mlxbf_bootctl_driver definition;
Fixes for comments from Vadim:
- Move mlxbf-bootctl.o to the top of the Makefile;
- Fix to use the 'ret' value instead of another mlxbf_bootctl_smc() call;
- Fix the 'declaration inside the block' in secure_boot_fuse_state_show();
- Use ATTRIBUTE_GROUPS() for the attribute definition;
- Use single line for a comment in mlxbf-bootctl.h
- Use KernelVersion 5.3 instead of 5.2.2 in the ABI doc;
- Use common utility function for the show and store of reset_action
and second_reset_action.
New changes:
- Rename mlxbf_bootctl_smc_call1() to mlxbf_bootctl_smc() to
shorten the name so some statement could be make into one line;
- Fixed the MODULE_LICENSE();
- Added more comments in secure_boot_fuse_state_show();
v4: Update Kconfig for the dependency on ACPI.
Fixed a typo which caused build error for kernel module.
v2->v3:
Fixes for comments from Andy:
- More coding style fixes;
- Revised the uuid matching code.
v2: Fix the Kconfig and coding styles, propagate errors to caller.
v1: Initial version.
---
drivers/platform/mellanox/Kconfig | 12 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxbf-bootctl.c | 321 ++
drivers/platform/mellan
[PATCH v6 2/2] platform/mellanox/mlxbf-bootctl: Add the ABI definitions
This commit adds the ABI definitions exposed to userspace for the platform/mellanox/mlxbf-bootctl driver. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v5->v6: Fixes for comments from Mark: - Changed to use device attributes (DEVICE_ATTR_xx) instead of driver attributes (DRIVER_ATTR_xx) for the exported sysfs attributes. --- .../ABI/testing/sysfs-platform-mellanox-bootctl| 58 ++ MAINTAINERS| 1 + 2 files changed, 59 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-mellanox-bootctl diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl new file mode 100644 index 000..b60a46e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl @@ -0,0 +1,58 @@ +What: /sys/bus/platform/devices/MLNXBF04:00/driver/lifecycle_state +Date: Oct 2019 +KernelVersion: 5.4 +Contact: "Liming Sun " +Description: + The Life-cycle state of the SoC, which could be one of the + following values. + Production - Production state and can be updated to secure + GA Secured - Secure chip and not able to change state + GA Non-Secured - Non-Secure chip and not able to change state + RMA - Return Merchandise Authorization + +What: /sys/bus/platform/devices/MLNXBF04:00/driver/post_reset_wdog +Date: Oct 2019 +KernelVersion: 5.4 +Contact: "Liming Sun " +Description: + The watchdog setting in seconds for the next booting. It's used + to reboot the chip and recover it to the old state if the new + boot partition fails. + +What: /sys/bus/platform/devices/MLNXBF04:00/driver/reset_action +Date: Oct 2019 +KernelVersion: 5.4 +Contact: "Liming Sun " +Description: + The source of the boot stream for the next reset. It could be + one of the following values. + external - boot from external source (USB or PCIe) + emmc - boot from the onchip eMMC + emmc_legacy - boot from the onchip eMMC in legacy (slow) mode + +What: /sys/bus/platform/devices/MLNXBF04:00/driver/second_reset_action +Date: Oct 2019 +KernelVersion: 5.4 +Contact: "Liming Sun " +Description: + Update the source of the boot stream after next reset. It could + be one of the following values and will be applied after next + reset. + external - boot from external source (USB or PCIe) + emmc - boot from the onchip eMMC + emmc_legacy - boot from the onchip eMMC in legacy (slow) mode + swap_emmc - swap the primary / secondary boot partition + none - cancel the action + +What: /sys/bus/platform/devices/MLNXBF04:00/driver/secure_boot_fuse_state +Date: Oct 2019 +KernelVersion: 5.4 +Contact: "Liming Sun " +Description: + The state of eFuse versions with the following values. + InUse - burnt, valid and currently in use + Used - burnt and valid + Free - not burnt and free to use + Skipped - not burnt but not free (skipped) + Wasted - burnt and invalid + Invalid - not burnt but marked as valid (error state). diff --git a/MAINTAINERS b/MAINTAINERS index 55199ef..c2ff283 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10435,6 +10435,7 @@ M: Darren Hart M: Vadim Pasternak L: platform-driver-...@vger.kernel.org S: Supported +F: Documentation/ABI/testing/sysfs-platform-mellanox-bootctl F: drivers/platform/mellanox/ F: include/linux/platform_data/mlxreg.h -- 1.8.3.1
RE: [PATCH v9] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy. Please see my response and questions on some of the comments below.
Regards,
Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Wednesday, February 13, 2019 1:11 PM
> To: Liming Sun
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: Re: [PATCH v9] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> On Wed, Feb 13, 2019 at 3:27 PM Liming Sun wrote:
> >
> ...
>
> > +/* Use a union struction for 64-bit little/big endian. */
>
> What does this mean?
>
> > +union mlxbf_tmfifo_data_64bit {
> > + u64 data;
> > + __le64 data_le;
> > +};
The purpose is to send 8 bytes into the FIFO without data casting in writeq().
Below is the example with the cast.
u64 data = 0x1234;
__le64 data_le;
data_le = cpu_to_le64(data)
writeq(*(u64 *)&data_le, fifo->tx_base + MLXBF_TMFIFO_TX_DATA);
Below is the alternative trying to use union to avoid the cast.
mlxbf_tmfifo_data_64bit u;
u.data = 0x1234;
u. data_le = cpu_to_le64(u.data);
writeq(u.data_le, fifo->tx_base + MLXBF_TMFIFO_TX_DATA);
Which way might be better or any other suggestions?
> > +
> > +/* Message header used to demux data in the TmFifo. */
> > +union mlxbf_tmfifo_msg_hdr {
> > + struct {
> > + u8 type;/* message type */
> > + __be16 len; /* payload length */
> > + u8 unused[5]; /* reserved, set to 0 */
> > + } __packed;
>
> It's already packed. No?
The '__packed' is needed here. Without it the compiler will make the
structure size exceeding 8 bytes which is not desired.
>...
> > + if (vdev_id == VIRTIO_ID_CONSOLE)
>
> > + tm_vdev->tx_buf = devm_kmalloc(dev,
> > +
> > MLXBF_TMFIFO_CONS_TX_BUF_SIZE,
> > + GFP_KERNEL);
>
> Are you sure devm_ suits here?
The 'tx_buf' are normal buffer to hold the console output.
It seems ok to use devm_kmalloc so it could automatically freed
on driver detach. Please correct me if I am wrong.
>>...
> > +
> > + fifo->tx_base = devm_ioremap(&pdev->dev, tx_res->start,
> > +resource_size(tx_res));
> > + if (!fifo->tx_base)
> > + return -ENOMEM;
>
> Switch to devm_ioremap_resource().
> However, I think you probably need memremap().
This is device registers accessed by arm64 core.
In arm64/include/asm/io.h, several apis are defined the same.
#define ioremap(addr, size) __ioremap((addr), (size),
__pgprot(PROT_DEVICE_nGnRE))
#define ioremap_nocache(addr, size) __ioremap((addr), (size),
__pgprot(PROT_DEVICE_nGnRE))
#define ioremap_wt(addr, size) __ioremap((addr), (size),
__pgprot(PROT_DEVICE_nGnRE))
How about using devm_ioremap_nocache()?
It could take advantage of the devm_xx() api.
>...
> Is it correct?
>
> --
> With Best Regards,
> Andy Shevchenko
[PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
This commit adds the bootctl platform driver for Mellanox BlueField
Soc, which controls the eMMC boot partition swapping and related
watchdog configuration.
Reviewed-by: David Woods
Signed-off-by: Liming Sun
---
drivers/platform/mellanox/Kconfig | 15 +-
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxbf-bootctl.c | 317 ++
drivers/platform/mellanox/mlxbf-bootctl.h | 108 ++
4 files changed, 440 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.c
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.h
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index cd8a908..580901f 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -5,7 +5,7 @@
menuconfig MELLANOX_PLATFORM
bool "Platform support for Mellanox hardware"
- depends on X86 || ARM || COMPILE_TEST
+ depends on X86 || ARM || ARM64 || COMPILE_TEST
---help---
Say Y here to get to see options for platform support for
Mellanox systems. This option alone does not add any kernel code.
@@ -34,4 +34,17 @@ config MLXREG_IO
to system resets operation, system reset causes monitoring and some
kinds of mux selection.
+config MLXBF_BOOTCTL
+ tristate "Mellanox BlueField Firmware Boot Control driver"
+ depends on ARM64
+ default m
+ help
+ The Mellanox BlueField firmware implements functionality to
+ request swapping the primary and alternate eMMC boot
+ partition, and to set up a watchdog that can undo that swap
+ if the system does not boot up correctly. This driver
+ provides sysfs access to the firmware, to be used in
+ conjunction with the eMMC device driver to do any necessary
+ initial swap of the boot partition.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 57074d9c..76b0370 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -5,3 +5,4 @@
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
+obj-$(CONFIG_MLXBF_BOOTCTL)+= mlxbf-bootctl.o
diff --git a/drivers/platform/mellanox/mlxbf-bootctl.c
b/drivers/platform/mellanox/mlxbf-bootctl.c
new file mode 100644
index 000..90a655b
--- /dev/null
+++ b/drivers/platform/mellanox/mlxbf-bootctl.c
@@ -0,0 +1,317 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox boot control driver
+ * This driver provides a sysfs interface for systems management
+ * software to manage reset-time actions.
+ *
+ * Copyright (C) 2019 Mellanox Technologies
+ */
+
+#include
+#include
+#include
+#include
+#include "mlxbf-bootctl.h"
+
+#define MLXBF_BOOTCTL_DRIVER_NAME "mlxbf-bootctl"
+#define MLXBF_BOOTCTL_DRIVER_VERSION "1.2"
+#define MLXBF_BOOTCTL_DRIVER_DESCRIPTION "Mellanox boot control driver"
+
+#define MLXBF_BOOTCTL_SB_MODE_SECURE_MASK 0x03
+#define MLXBF_BOOTCTL_SB_MODE_TEST_MASK0x0c
+
+#define MLXBF_SB_KEY_NUM 4
+
+struct mlxbf_bootctl_name {
+ int value;
+ const char name[12];
+};
+
+static struct mlxbf_bootctl_name boot_names[] = {
+ { MLXBF_BOOTCTL_EXTERNAL, "external" },
+ { MLXBF_BOOTCTL_EMMC, "emmc" },
+ { MLNX_BOOTCTL_SWAP_EMMC, "swap_emmc" },
+ { MLXBF_BOOTCTL_EMMC_LEGACY,"emmc_legacy" },
+ { MLXBF_BOOTCTL_NONE, "none" },
+ { -1, "" }
+};
+
+static char mlxbf_bootctl_lifecycle_states[][16] = {
+ [0] = "soft_non_secure",
+ [1] = "secure",
+ [2] = "hard_non_secure",
+ [3] = "rma",
+};
+
+/* The SMC calls in question are atomic, so we don't have to lock here. */
+static int mlxbf_bootctl_smc_call1(unsigned int smc_op, int smc_arg)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(smc_op, smc_arg, 0, 0, 0, 0, 0, 0, &res);
+
+ return res.a0;
+}
+
+/* Syntactic sugar to avoid having to specify an unused argument. */
+#define mlxbf_bootctl_smc_call0(smc_op) mlxbf_bootctl_smc_call1(smc_op, 0)
+
+static int reset_action_to_val(const char *action, size_t len)
+{
+ struct mlxbf_bootctl_name *bn;
+
+ /* Accept string either with or without a newline terminator */
+ if (action[len-1] == '\n')
+ --len;
+
+ for (bn = boot_names; bn->value >= 0; ++bn)
+ if (strncmp(bn->name, action, len) == 0)
+ break;
+
+ return bn->value;
+}
+
+static const char *reset_action_to_string(int action)
+{
[PATCH v1 1/1] mmc: dw_mmc-bluefield: : Fix the license information
The SPDX license identifier and the boiler plate text are
contradicting. Only the SPDX license identifier is needed. The
other one is removed.
Fixes: 86958dcc5ad7 ("mmc: dw_mmc-bluefield: Add driver extension")
Cc: sta...@vger.kernel.org
Reviewed-by: David Woods
Signed-off-by: Liming Sun
---
drivers/mmc/host/dw_mmc-bluefield.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
index ed8f225..aa38b1a 100644
--- a/drivers/mmc/host/dw_mmc-bluefield.c
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -1,11 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) 2018 Mellanox Technologies.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
*/
#include
--
1.8.3.1
[PATCH v4] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
This commit adds the bootctl platform driver for Mellanox BlueField
Soc, which controls the eMMC boot partition swapping and sends SMC
calls to ATF running at exception level EL3 to program some system
register. This register is only accessible in secure code and is
used to enable the watchdog after reboot.
Below are the sequences of a typical use case.
1. User-space tool upgrades one eMMC boot partition and requests
the boot partition swapping;
2. The bootctl driver handles such request and sends SMC call
to ATF. ATF programs register BREADCRUMB0 which has value
preserved during software reset. It also programs eMMC to
swap the boot partition;
3. After software reset (rebooting), ATF BL1 (BootRom) checks
register BREADCRUMB0 to enable watchdog if configured;
4. If booting fails, the watchdog timer will trigger rebooting.
In such case, ATF BootRom will switch the boot partition
to the previous one.
Signed-off-by: Liming Sun
---
v4: Update Kconfig for the dependency on ACPI.
Fixed a typo which caused build error for kernel module.
v3: More coding style fixes, revised the uuid matching code.
v2: Fix the Kconfig and coding styles, propagate errors to caller.
v1: Initial version.
---
drivers/platform/mellanox/Kconfig | 14 +-
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxbf-bootctl.c | 307 ++
drivers/platform/mellanox/mlxbf-bootctl.h | 108 +++
4 files changed, 429 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.c
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.h
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index cd8a908..92bda11 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -5,7 +5,7 @@
menuconfig MELLANOX_PLATFORM
bool "Platform support for Mellanox hardware"
- depends on X86 || ARM || COMPILE_TEST
+ depends on X86 || ARM || ARM64 || COMPILE_TEST
---help---
Say Y here to get to see options for platform support for
Mellanox systems. This option alone does not add any kernel code.
@@ -34,4 +34,16 @@ config MLXREG_IO
to system resets operation, system reset causes monitoring and some
kinds of mux selection.
+config MLXBF_BOOTCTL
+ tristate "Mellanox BlueField Firmware Boot Control driver"
+ depends on ARM64 && ACPI
+ help
+ The Mellanox BlueField firmware implements functionality to
+ request swapping the primary and alternate eMMC boot
+ partition, and to set up a watchdog that can undo that swap
+ if the system does not boot up correctly. This driver
+ provides sysfs access to the firmware, to be used in
+ conjunction with the eMMC device driver to do any necessary
+ initial swap of the boot partition.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 57074d9c..76b0370 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -5,3 +5,4 @@
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
+obj-$(CONFIG_MLXBF_BOOTCTL)+= mlxbf-bootctl.o
diff --git a/drivers/platform/mellanox/mlxbf-bootctl.c
b/drivers/platform/mellanox/mlxbf-bootctl.c
new file mode 100644
index 000..01298ce
--- /dev/null
+++ b/drivers/platform/mellanox/mlxbf-bootctl.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox boot control driver
+ * This driver provides a sysfs interface for systems management
+ * software to manage reset-time actions.
+ *
+ * Copyright (C) 2019 Mellanox Technologies
+ */
+
+#include
+#include
+#include
+#include
+#include "mlxbf-bootctl.h"
+
+#define MLXBF_BOOTCTL_SB_SECURE_MASK 0x03
+#define MLXBF_BOOTCTL_SB_TEST_MASK 0x0c
+
+#define MLXBF_SB_KEY_NUM 4
+
+/* UUID used to probe ATF service. */
+static const char * const mlxbf_bootctl_svc_uuid_str =
+ "89c036b4-e7d7-11e6-8797-001aca00bfc4";
+
+struct mlxbf_bootctl_name {
+ u32 value;
+ const char *name;
+};
+
+static struct mlxbf_bootctl_name boot_names[] = {
+ { MLXBF_BOOTCTL_EXTERNAL, "external" },
+ { MLXBF_BOOTCTL_EMMC, "emmc" },
+ { MLNX_BOOTCTL_SWAP_EMMC, "swap_emmc" },
+ { MLXBF_BOOTCTL_EMMC_LEGACY,"emmc_legacy" },
+ { MLXBF_BOOTCTL_NONE, "none" },
+};
+
+static const char * const mlxbf_bootctl_lifecycle_states[] = {
+ [0] = "soft_non_secure",
+ [1] = "secure",
+ [2] = "hard_non_secure",
+ [3] = "rma",
+};
+
+/* The SMC calls in question are atomi
RE: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
Thanks for the information!
Patch v4 1/1 has been posted to solve these issues.
Best regards,
Liming
> -Original Message-
> From: kbuild test robot
> Sent: Friday, February 1, 2019 12:17 AM
> To: Liming Sun
> Cc: kbuild-...@01.org; Andy Shevchenko ; Darren Hart
> ; Vadim Pasternak
> ; David Woods ; Liming Sun
> ; platform-driver-
> x...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for
> Mellanox BlueField Soc
>
> Hi Liming,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v5.0-rc4 next-20190131]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Liming-Sun/platform-mellanox-Add-bootctl-driver-for-Mellanox-BlueField-
> Soc/20190201-104657
> config: arm64-allmodconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=8.2.0 make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
>drivers/platform/mellanox/mlxbf-bootctl.c:260:36: error: array type has
> incomplete element type 'struct acpi_device_id'
> static const struct acpi_device_id mlxbf_bootctl_acpi_ids[] = {
>^~
>In file included from include/linux/module.h:18,
> from drivers/platform/mellanox/mlxbf-bootctl.c:12:
> >> drivers/platform/mellanox/mlxbf-bootctl.c:314:20: error: expected ',' or
> >> ';' before 'DRIVER_DESCRIPTION'
> MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
>^~
>include/linux/moduleparam.h:24:26: note: in definition of macro
> '__MODULE_INFO'
> = __stringify(tag) "=" info
> ^~~~
>include/linux/module.h:208:42: note: in expansion of macro 'MODULE_INFO'
> #define MODULE_DESCRIPTION(_description) MODULE_INFO(description,
> _description)
> ^~~
>drivers/platform/mellanox/mlxbf-bootctl.c:314:1: note: in expansion of
> macro 'MODULE_DESCRIPTION'
> MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
> ^~
>
> vim +314 drivers/platform/mellanox/mlxbf-bootctl.c
>
>259
> > 260static const struct acpi_device_id mlxbf_bootctl_acpi_ids[] = {
>261{"MLNXBF04", 0},
>262{},
>263};
>264
>265MODULE_DEVICE_TABLE(acpi, mlxbf_bootctl_acpi_ids);
>266
>267static int mlxbf_bootctl_probe(struct platform_device *pdev)
>268{
>269struct arm_smccc_res res;
>270
>271/*
>272 * Ensure we have the UUID we expect for this service.
>273 * Note that the functionality we want is present in
> the first
>274 * released version of this service, so we don't check
> the version.
>275 */
>276arm_smccc_smc(MLXBF_BOOTCTL_SIP_SVC_UID, 0, 0, 0, 0, 0,
> 0, 0, &res);
>277if (res.a0 != 0x89c036b4 || res.a1 != 0x11e6e7d7 ||
>278res.a2 != 0x1a009787 || res.a3 != 0xc4bf00ca)
>279return -ENODEV;
>280
>281/*
>282 * When watchdog is used, it sets boot mode to
> MLXBF_BOOTCTL_SWAP_EMMC
>283 * in case of boot failures. However it doesn't clear
> the state if there
>284 * is no failure. Restore the default boot mode here to
> avoid any
>285 * unnecessary boot partition swapping.
>286 */
>287if
> (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_RESET_ACTION,
>288MLXBF_BOOTCTL_EMMC) < 0)
>289pr_err("Unable to reset the EMMC boot mode\n");
>290
>291pr_info("%s (version %s)\n",
> MLXBF_BOOTCTL_DRIVER_DESCRIPTION,
>292MLXBF_BOOTCTL_DRIVER_VERSION);
>293
>294return 0;
>295}
>296
>297static int mlxbf_boo
RE: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
Mark,
Thanks for the comments. I'll try to describe the SoC boot flow as below.
a) The SoC has a Boot ROM, which is ATF BL1; It's the entry point of HW reset.
b) The SoC has two eMMC boot partitions, which contains the rest of ATF images
(BL2/BL31/...) and the UEFI image. These two boot partitions are NOT for
Linux
or Linux file systems. Anything related to Linux are actually stored in eMMC
user
partitions (including the Linux 'boot' partition).
c) Depends on the eMMC configuration, one of the above boot partitions is
primary, the other one is secondary.
d) During HW reset, HW will move the boot stream from the primary boot
partition into some BOOT FIFO. The Boot ROM (ATF BL1) will poll the
BOOT FIFO to load ATF BL2. Later on ATF BL2 will load ATF BL31 and
the UEFI image. ATF images are loaded into SRAM and UEFI are loaded
into DRAM.
e) The rest are all standard behavior once the logic is passed into UEFI.
The purpose of this commit is to control the above step b & c for safe upgrade
and fallback if anything bad happens. It's a lower level operation than UEFI.
The ACPI here is just used to auto-load the driver, nothing else. Once the
driver
is loaded, it exposes sysfs to userspace tools. Essentially, all the driver
does is
proxying the SMC calls into ATF, since user-space doesn't have the permission
to do SMC call itself.
Thanks,
Liming
> -Original Message-
> From: Mark Rutland
> Sent: Wednesday, May 22, 2019 9:35 AM
> To: Liming Sun
> Cc: Andy Shevchenko ; Darren Hart ;
> Vadim Pasternak ; David
> Woods ; platform-driver-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; ard.biesheu...@linaro.org
> Subject: Re: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for
> Mellanox BlueField Soc
>
> Hi Liming,
>
> On Fri, May 17, 2019 at 01:49:04PM -0400, Liming Sun wrote:
> > This commit adds the bootctl platform driver for Mellanox BlueField
> > Soc, which controls the eMMC boot partition swapping and sends SMC
> > calls to ATF running at exception level EL3 to program some system
> > register. This register is persistent during warm reset and is only
> > accessible in secure code which is used to enable the watchdog after
> > reboot.
>
> I'm concerned by this. AFAICT this part must boot using EFI (in order
> for the ACPI bits to work), and these interfaces significantly overlap
> with or contradict the UEFI specification w.r.t. boot management.
>
> How exactly does this SoC boot?
>
> How do these interfaces interact with the regular UEFI bootflow?
>
> Thanks,
> Mark.
>
> >
> > Below are the sequences of typical use case.
> >
> > 1. User-space tool upgrades one eMMC boot partition and requests
> > the boot partition swapping;
> >
> > 2. The bootctl driver handles this request and sends SMC call
> > to ATF. ATF programs register BREADCRUMB0 which has value
> > preserved during warm reset. It also programs eMMC to swap
> > the boot partition;
> >
> > 3. After software reset (rebooting), ATF BL1 (BootRom) checks
> > register BREADCRUMB0 to enable watchdog if configured;
> >
> > 4. If booting fails, the watchdog timer will trigger rebooting.
> > In such case, ATF Boot ROM will switch the boot partition
> > back to the previous one.
> >
> > Reviewed-by: Vadim Pasternak
> > Signed-off-by: Liming Sun
> > ---
> > v4->v5:
> > Fixes for comments from Andy:
> > - Added ABI documentation;
> > - Remove the extra 'const' in mlxbf_bootctl_svc_uuid_str definition;
> > - Remove the mlxbf_bootctl_smc_call0() MACRO to use function
> > call directly;
> > - Return more descriptive string ('invalid action') in
> > mlxbf_bootctl_reset_action_to_string();
> > - Check return value of the mlxbf_bootctl_smc() in function
> > post_reset_wdog_show() and reset_action_show();
> > - Revise the sprintf() line in reset_action_show() into one line;
> > - Move the 'action = ' assignment out of the declarations
> > in reset_action_store() and check return value of
> > mlxbf_bootctl_reset_action_to_val() in this function;
> > - Removed Redundant parens in reset_action_store();
> > - Check return code of the smc_call in second_reset_action_show(),
> > merge the 'name = ' assignment into the sprintf() directly;
> > - Move the 'action = ' assignment out of the declaration block
> > in second_reset_action_store();
> > - Remove redundant blank line and parents in lifecycle_state_show();
> > - Split declarati
RE: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
Thanks Arnd for the comments! Please also see my response below.
> -Original Message-
> From: Arnd Bergmann
> Sent: Tuesday, May 21, 2019 3:59 AM
> To: Liming Sun
> Cc: Greg KH ; Andy Shevchenko
> ; Darren Hart ; Vadim
> Pasternak ; David Woods ;
> platform-driver-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for
> Mellanox BlueField Soc
>
> On Mon, May 20, 2019 at 10:44 PM Liming Sun wrote:
> > > -Original Message-
> > > From: Greg KH
> > > Sent: Monday, May 20, 2019 3:12 PM
> > > To: Liming Sun
> > > Cc: Andy Shevchenko ; Darren Hart
> > > ; Vadim Pasternak ;
> David
> > > Woods ; platform-driver-...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for
> > > Mellanox BlueField Soc
> > >
> > > On Mon, May 20, 2019 at 06:07:44PM +, Liming Sun wrote:
> > > > > > +static struct platform_driver mlxbf_bootctl_driver = {
> > > > > > + .probe = mlxbf_bootctl_probe,
> > > > > > + .driver = {
> > > > > > + .name = "mlxbf-bootctl",
> > > > > > + .groups = mlxbf_bootctl_groups,
> > > > > > + .acpi_match_table = mlxbf_bootctl_acpi_ids,
> > > > >
> > > > > Why is an acpi driver a platform driver? Isn't there a "real" acpi
> > > > > driver interface you should be tieing into instead?
> > > > >
> > > > > Only use a platform driver as an absolute last resort. I don't think
> > > > > that is the case here.
> > > >
> > > > The driver is trying to configure boot-swapping and display secure
> > > > state,
> > > > and is defined/initiated in ACPI table in UEFI. It seems a little hard
> > > > to
> > > > categorize this driver to any existing subsystem. Any suggestion
> > > > where it might be a better fit (like drivers/misc, drivers/firmware,
> > > > etc)?
> > > > Please correct me if I misunderstand the comments. Thanks!.
> > >
> > > The comment was asking why an acpi driver is a platform driver, but then
> > > I went and looked now at a bunch of acpi drivers, and they all are
> > > platform drivers :(
> > >
> > > Anyway, drivers/acpi/ seems like the best place for this file, right?
> >
> > My understanding is that the "drivers/acpi" is mainly for the acpi common
> > code.
> > The vendor or platform specific drivers are spread in other various
> > directories,
> > most of which are 'platform' drivers.
>
> It depends on how closely you are following the acpi specification.
> If you just implement access to a standard ACPI feature, or you have
> added your interface to the ACPI specification, then the driver
> should work on any system that supports this feature.
>
> > For this driver, we didn't find better sub-component for it, thus put it
> > under
> > 'drivers/platform/mellanox' which is vendor specific driver by its name.
>
> drivers/platform/mellanox/ would be a good place for drivers running on
> a host platform with a bluefield accelerator card as an add-on, but as I
> understand, this is a driver that actually just runs in Linux on the bluefield
> itself, so it should go in a different place.
Yes, the driver is actually running on the bluefield itself.
So looks like we'll need to find another location for it.
>
> We use drivers/soc/ for things that are specific to one SoC, and that
> are typically used by other drivers, but that don't have (and should not
> have) a generic abstraction, which probably is not the case here either.
I did a 'grep' for 'module_platform_driver' and 'DEVICE_ATTR' under
drivers/soc, and found quite some under drivers/soc. This 'bootctl' driver
is SoC specific and tries to control the low-level boot partition (not
Linux related). Please also see my response to Mark's comments about
the SoC boot flow. Probably the 'drivers/soc' would be better fit for
this driver? Please advise.
>
> What we do have in drivers/power/reset is a couple of drivers that
> set the "reboot reason", communicating that to the firmware for the
> next boot, using the reboot_mode_register() interface. I don't
> know too much about that interface, but maybe you can use that
> instead of adding another sysfs interface?
I checked the history of the 'reboot_mode'. Looks like it tries to
control how Linux boots, which is different than what this commit
does. This commit tries to control how ATF/UEFI boots, not how
Linux boots.
>
> If you have a complex firmware on the system that you can talk
> to, there is also drivers/firmware/ as another option to put
> abstractions into.
I feel like 'drivers/soc' migh be better fit. We could certainly try
drivers/firmware/ and abstractions if you think 'drivers/soc' is not
a good option.
>
> Arnd
RE: [PATCH v5 2/2] platform/mellanox/mlxbf-bootctl: Add the ABI definitions
Thanks Greg for the comments! Please see my response inline. Regards, - Liming > -Original Message- > From: Greg Kroah-Hartman > Sent: Friday, May 17, 2019 1:59 PM > To: Liming Sun > Cc: Andy Shevchenko ; Darren Hart ; > Vadim Pasternak ; David > Woods ; platform-driver-...@vger.kernel.org; > linux-kernel@vger.kernel.org; David S. Miller > ; Mauro Carvalho Chehab ; > Jonathan Cameron > ; Nicolas Ferre ; > Paul E. McKenney > Subject: Re: [PATCH v5 2/2] platform/mellanox/mlxbf-bootctl: Add the ABI > definitions > > On Fri, May 17, 2019 at 01:49:05PM -0400, Liming Sun wrote: > > This commit adds the ABI definitions exposed to userspace for > > the platform/mellanox/mlxbf-bootctl driver. > > > > Reviewed-by: Vadim Pasternak > > Signed-off-by: Liming Sun > > --- > > .../ABI/testing/sysfs-platform-mellanox-bootctl| 58 > > ++ > > MAINTAINERS| 1 + > > 2 files changed, 59 insertions(+) > > create mode 100644 > > Documentation/ABI/testing/sysfs-platform-mellanox-bootctl > > > > diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl > > b/Documentation/ABI/testing/sysfs-platform-mellanox- > bootctl > > new file mode 100644 > > index 000..19a14db > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl > > @@ -0,0 +1,58 @@ > > +What: /sys/bus/platform/drivers/mlxbf-bootctl/lifecycle_state > > +Date: May 2019 > > +KernelVersion: 5.3 > > +Contact: "Liming Sun " > > +Description: > > + The Life-cycle state of the SoC, which could be one of the > > + following values. > > + Production - Production state and can be updated to secure > > + GA Secured - Secure chip and not able to change state > > + GA Non-Secured - Non-Secure chip and not able to change state > > + RMA - Return Merchandise Authorization > > A "driver" does not have a lifecycle state, a "device" does. > > You are putting all of these attributes in the wrong place. Put them on > your device please, not the driver. driver-specific attributes are > _VERY_ rare, and only for things that can modify/show for all devices > attached to that driver. This driver is running on the ARM processor of the SoC. The 'device' is the SoC itself. That's to say, there is only one device here attached to the driver and the driver state will also be the device state. This interface has been used by user-space applications for a couple of releases. It'll be great if it could stay in such way for compatibility. Please advise if this is strongly preferred to move them under devices. > > thanks, > > greg k-h
RE: [PATCH v5 2/2] platform/mellanox/mlxbf-bootctl: Add the ABI definitions
Please see response inline. > -Original Message- > From: Greg Kroah-Hartman > Sent: Saturday, May 18, 2019 2:35 AM > To: Liming Sun > Cc: Andy Shevchenko ; Darren Hart ; > Vadim Pasternak ; David > Woods ; platform-driver-...@vger.kernel.org; > linux-kernel@vger.kernel.org; David S. Miller > ; Mauro Carvalho Chehab ; > Jonathan Cameron > ; Nicolas Ferre ; > Paul E. McKenney > Subject: Re: [PATCH v5 2/2] platform/mellanox/mlxbf-bootctl: Add the ABI > definitions > > On Fri, May 17, 2019 at 08:36:53PM +, Liming Sun wrote: > > Thanks Greg for the comments! Please see my response inline. > > > > Regards, > > - Liming > > > > > -Original Message----- > > > From: Greg Kroah-Hartman > > > Sent: Friday, May 17, 2019 1:59 PM > > > To: Liming Sun > > > Cc: Andy Shevchenko ; Darren Hart > > > ; Vadim Pasternak ; > David > > > Woods ; platform-driver-...@vger.kernel.org; > > > linux-kernel@vger.kernel.org; David S. Miller > > > ; Mauro Carvalho Chehab > > > ; Jonathan Cameron > > > ; Nicolas Ferre > > > ; Paul E. McKenney > > > Subject: Re: [PATCH v5 2/2] platform/mellanox/mlxbf-bootctl: Add the ABI > > > definitions > > > > > > On Fri, May 17, 2019 at 01:49:05PM -0400, Liming Sun wrote: > > > > This commit adds the ABI definitions exposed to userspace for > > > > the platform/mellanox/mlxbf-bootctl driver. > > > > > > > > Reviewed-by: Vadim Pasternak > > > > Signed-off-by: Liming Sun > > > > --- > > > > .../ABI/testing/sysfs-platform-mellanox-bootctl| 58 > > > > ++ > > > > MAINTAINERS| 1 + > > > > 2 files changed, 59 insertions(+) > > > > create mode 100644 > > > > Documentation/ABI/testing/sysfs-platform-mellanox-bootctl > > > > > > > > diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl > > > > b/Documentation/ABI/testing/sysfs-platform-mellanox- > > > bootctl > > > > new file mode 100644 > > > > index 000..19a14db > > > > --- /dev/null > > > > +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl > > > > @@ -0,0 +1,58 @@ > > > > +What: /sys/bus/platform/drivers/mlxbf-bootctl/lifecycle_state > > > > +Date: May 2019 > > > > +KernelVersion: 5.3 > > > > +Contact: "Liming Sun " > > > > +Description: > > > > + The Life-cycle state of the SoC, which could be one of > > > > the > > > > + following values. > > > > + Production - Production state and can be updated to > > > > secure > > > > + GA Secured - Secure chip and not able to change state > > > > + GA Non-Secured - Non-Secure chip and not able to > > > > change state > > > > + RMA - Return Merchandise Authorization > > > > > > A "driver" does not have a lifecycle state, a "device" does. > > > > > > You are putting all of these attributes in the wrong place. Put them on > > > your device please, not the driver. driver-specific attributes are > > > _VERY_ rare, and only for things that can modify/show for all devices > > > attached to that driver. > > > > This driver is running on the ARM processor of the SoC. The 'device' is > > the SoC itself. That's to say, there is only one device here attached to > > the driver and the driver state will also be the device state. > > That might be true today, but maybe not tomorrow :) > > Anyway, again, this is device state, not driver state. Yes, I agree. I discussed with the team and will move these attributes under device (since they could be all considered as device state). > > > This interface has been used by user-space applications for a couple of > > releases. It'll be great if it could stay in such way for compatibility. > > Please > > advise if this is strongly preferred to move them under devices. > > So this is code that is already in the tree, and is just now being > documented? What .c file(s) is this referring to? This code is not in the kernel tree yet. It has been in Mellanox BlueField SW packages for a couple of releases and is trying to be up-streamed now. > > As for "comptability", sysfs is made such that if a file is not present, > userspace should be able to survive, that is why it is > one-value-per-file. What tool is using this, and where is the source > for it? The latest 2.0 code can be found at link https://github.com/Mellanox/mlxbf-bootctl/tree/2.0 In file mlxbf-bootctl.c, currently it uses the 'drivers' path as sysfs path. #define SYS_PATH "/sys/bus/platform/drivers/mlx-bootctl". We could update it to support both paths. > > thanks, > > greg k-h
RE: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
> -Original Message-
> From: Greg KH
> Sent: Monday, May 20, 2019 11:57 AM
> To: Liming Sun
> Cc: Andy Shevchenko ; Darren Hart ;
> Vadim Pasternak ; David
> Woods ; platform-driver-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for
> Mellanox BlueField Soc
>
> On Fri, May 17, 2019 at 01:49:04PM -0400, Liming Sun wrote:
> > This commit adds the bootctl platform driver for Mellanox BlueField
> > Soc, which controls the eMMC boot partition swapping and sends SMC
> > calls to ATF running at exception level EL3 to program some system
> > register. This register is persistent during warm reset and is only
> > accessible in secure code which is used to enable the watchdog after
> > reboot.
> >
> > Below are the sequences of typical use case.
> >
> > 1. User-space tool upgrades one eMMC boot partition and requests
> > the boot partition swapping;
> >
> > 2. The bootctl driver handles this request and sends SMC call
> > to ATF. ATF programs register BREADCRUMB0 which has value
> > preserved during warm reset. It also programs eMMC to swap
> > the boot partition;
> >
> > 3. After software reset (rebooting), ATF BL1 (BootRom) checks
> > register BREADCRUMB0 to enable watchdog if configured;
> >
> > 4. If booting fails, the watchdog timer will trigger rebooting.
> > In such case, ATF Boot ROM will switch the boot partition
> > back to the previous one.
> >
> > Reviewed-by: Vadim Pasternak
> > Signed-off-by: Liming Sun
> > ---
> > v4->v5:
> > Fixes for comments from Andy:
> > - Added ABI documentation;
> > - Remove the extra 'const' in mlxbf_bootctl_svc_uuid_str definition;
> > - Remove the mlxbf_bootctl_smc_call0() MACRO to use function
> > call directly;
> > - Return more descriptive string ('invalid action') in
> > mlxbf_bootctl_reset_action_to_string();
> > - Check return value of the mlxbf_bootctl_smc() in function
> > post_reset_wdog_show() and reset_action_show();
> > - Revise the sprintf() line in reset_action_show() into one line;
> > - Move the 'action = ' assignment out of the declarations
> > in reset_action_store() and check return value of
> > mlxbf_bootctl_reset_action_to_val() in this function;
> > - Removed Redundant parens in reset_action_store();
> > - Check return code of the smc_call in second_reset_action_show(),
> > merge the 'name = ' assignment into the sprintf() directly;
> > - Move the 'action = ' assignment out of the declaration block
> > in second_reset_action_store();
> > - Remove redundant blank line and parents in lifecycle_state_show();
> > - Split declaration and assignment in secure_boot_fuse_state_show();
> > - use BIT() in secure_boot_fuse_state_show() and simplify code in
> > this function to split the logic of message choice and flag flip;
> > Also removed the 'key !=0 ' check since it's not needed;
> > - Added comma in mlxbf_bootctl_attr_group definition.
> > - Removed un-needed '& 0xFF' logic in mlxbf_bootctl_guid_match();
> > - Use temp variable for the result of the smc call in
> > mlxbf_bootctl_probe();
> > - Use dev_warn() instead of dev_err() in mlxbf_bootctl_probe();
> > - Removed the ACPI_PTR usage in the mlxbf_bootctl_driver definition;
> > Fixes for comments from Vadim:
> > - Move mlxbf-bootctl.o to the top of the Makefile;
> > - Fix to use the 'ret' value instead of another mlxbf_bootctl_smc()
> > call;
> > - Fix the 'declaration inside the block' in
> > secure_boot_fuse_state_show();
> > - Use ATTRIBUTE_GROUPS() for the attribute definition;
> > - Use single line for a comment in mlxbf-bootctl.h
> > - Use KernelVersion 5.3 instead of 5.2.2 in the ABI doc;
> > - Use common utility function for the show and store of reset_action
> > and second_reset_action.
> > New changes:
> > - Rename mlxbf_bootctl_smc_call1() to mlxbf_bootctl_smc() to
> > shorten the name so some statement could be make into one line;
> > - Fixed the MODULE_LICENSE();
> > - Added more comments in secure_boot_fuse_state_show();
> > v4: Update Kconfig for the dependency on ACPI.
> > Fixed a typo which caused build error for kernel module.
> > v2->v3:
> > Fixes for comments
RE: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
> -Original Message-
> From: Greg KH
> Sent: Monday, May 20, 2019 3:12 PM
> To: Liming Sun
> Cc: Andy Shevchenko ; Darren Hart ;
> Vadim Pasternak ; David
> Woods ; platform-driver-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 1/2] platform/mellanox: Add bootctl driver for
> Mellanox BlueField Soc
>
> On Mon, May 20, 2019 at 06:07:44PM +, Liming Sun wrote:
> > > > +static struct platform_driver mlxbf_bootctl_driver = {
> > > > + .probe = mlxbf_bootctl_probe,
> > > > + .driver = {
> > > > + .name = "mlxbf-bootctl",
> > > > + .groups = mlxbf_bootctl_groups,
> > > > + .acpi_match_table = mlxbf_bootctl_acpi_ids,
> > >
> > > Why is an acpi driver a platform driver? Isn't there a "real" acpi
> > > driver interface you should be tieing into instead?
> > >
> > > Only use a platform driver as an absolute last resort. I don't think
> > > that is the case here.
> >
> > The driver is trying to configure boot-swapping and display secure state,
> > and is defined/initiated in ACPI table in UEFI. It seems a little hard to
> > categorize this driver to any existing subsystem. Any suggestion
> > where it might be a better fit (like drivers/misc, drivers/firmware, etc)?
> > Please correct me if I misunderstand the comments. Thanks!.
>
> The comment was asking why an acpi driver is a platform driver, but then
> I went and looked now at a bunch of acpi drivers, and they all are
> platform drivers :(
>
> Anyway, drivers/acpi/ seems like the best place for this file, right?
My understanding is that the "drivers/acpi" is mainly for the acpi common code.
The vendor or platform specific drivers are spread in other various directories,
most of which are 'platform' drivers.
For this driver, we didn't find better sub-component for it, thus put it under
'drivers/platform/mellanox' which is vendor specific driver by its name.
>
> thanks,
>
> greg k-h
[PATCH v13] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v12->v13: Rebase and resubmit (no new changes). v11->v12: Fixed the two unsolved comments from v11. - "Change macro mlxbf_vdev_to_tmfifo() to one line" Done. Seems not hard. - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" Yes, understand the comment now. The tmfifo is fixed, but the vdev is dynamic. Use kzalloc() instead, and free the device in the release callback which is the right place for it. v10->v11: Fixes for comments from Andy: - Use GENMASK_ULL() instead of GENMASK() in mlxbf-tmfifo-regs.h - Removed the cpu_to_le64()/le64_to_cpu() conversion since readq()/writeq() already takes care of it. - Remove the "if (irq)" check in mlxbf_tmfifo_disable_irqs(). - Add "u32 count" temp variable in mlxbf_tmfifo_get_tx_avail(). - Clean up mlxbf_tmfifo_get_cfg_mac(), use ETH_ALEN instead of value 6. - Change the tx_buf to use Linux existing 'struct circ_buf'. Comment not applied: - "Change macro mlxbf_vdev_to_tmfifo() to one line" Couldn't fit in one line with 80 chracters - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" This is SoC, the device won't be closed or detached. The only case is when the driver is unloaded. So it appears ok to use devm_kzalloc() since it's allocated during probe() and released during module unload. Comments from Vadim: OK v9->v10: Fixes for comments from Andy: - Use devm_ioremap_resource() instead of devm_ioremap(). - Use kernel-doc comments. - Keep Makefile contents sorted. - Use same fixed format for offsets. - Use SZ_1K/SZ_32K instead of 1024/23*1024. - Remove unnecessary comments. - Use one style for max numbers. - More comments for mlxbf_tmfifo_vdev and mlxbf_tmfifo_data_64bit. - Use globally defined MTU instead of new definition. - Remove forward declaration of mlxbf_tmfifo_remove(). - Remove PAGE_ALIGN() for dma_alloc_coherent)(). - Remove the cast of "struct vring *". - Check return result of test_and_set_bit(). - Add a macro mlxbt_vdev_to_tmfifo(). - Several other minor coding style comments. Comment not applied: - "Shouldn't be rather helper in EFI lib in kernel" Looks like efi.get_variable() is the way I found in the kernel tree. - "this one is not protected anyhow? Potential race condition" In mlxbf_tmfifo_console_tx(), the spin-lock is used to protect the 'tx_buf' only, not the FIFO writes. So there is no race condition. - "Is __packed needed in mlxbf_tmfifo_msg_hdr". Yes, it is needed to make sure the structure is 8 bytes. Fixes for comments from Vadim: - Use tab in mlxbf-tmfifo-regs.h - Use kernel-doc comments for struct mlxbf_tmfifo_msg_hdr and mlxbf_tmfifo_irq_info as well. - Use _MAX instead of _CNT in the macro definition to be consistent. - Fix the MODULE_LICENSE. - Use BIT_ULL() instead of BIT(). - Remove argument of 'avail' for mlxbf_tmfifo_rxtx_header() and mlxbf_tmfifo_rxtx_word() - Revise logic in mlxbf_tmfifo_rxtx_one_desc() to remove the WARN_ON(). - Change "union mlxbf_tmfifo_u64 u" to "union mlxbf_tmfifo_u64 buf" in mlxbf_tmfifo_rxtx_word(). - Change date type of vring_change from 'int' to 'bool'. - Remove the blank lines after Signed-off. - Don’t use declaration in the middle. - Make the network header initialization in some more elegant way. - Change label done to mlxbf_tmfifo_desc_done. - Remove some unnecessary comments, and several other misc coding style comments. - Simplify code logic in mlxbf_tmfifo_virtio_notify() New changes by Liming: - Simplify the Rx/Tx function arguments to make it more readable. v8->v9: Fixes for comments from Andy: - Use modern devm_xxx() API instead. Fixes for comments from Vadim: - Split the Rx/Tx function into smaller funcitons. - File name, copyright information. - Function and variable name conversion. - Local variable and indent coding styles. - Remove unnecessary 'inline' declarations. - Use devm_xxx() APIs. - Move the efi_char16_t MAC address definition to global. - Fix warnings reported by 'checkpatch --strict'. - Fix warnings reported by 'make CF="-D__CHECK_ENDIAN__"'. - Change select VIRTIO_xxx to depends on V
RE: [PATCH v13] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy! I'll address the comments in v14.
Some question for the comment below:
> > + size = vring_size(vring->num, vring->align);
> > + va = dma_alloc_coherent(dev->parent, size, &dma,
> > GFP_KERNEL);
> > + if (!va) {
>
> > + dev_err(dev->parent, "dma_alloc_coherent failed\n");
> > I don't see how this will free the allocated entries.
> I think I told about this either.
When an error is returned, all the allocated entries will be released by the
in the caller context by calling mlxbf_tmfifo_free_vrings(), like the logic
below.
Or do you prefer releasing the entries in mlxbf_tmfifo_alloc_vrings() instead?
1073 if (mlxbf_tmfifo_alloc_vrings(fifo, tm_vdev)) {
1074 dev_err(dev, "unable to allocate vring\n");
1075 ret = -ENOMEM;
1076 goto vdev_fail;
1077 }
...
1097 vdev_fail:
1098 mlxbf_tmfifo_free_vrings(fifo, tm_vdev);
Regards,
Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Friday, April 5, 2019 11:44 AM
> To: Liming Sun
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: Re: [PATCH v13] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> On Thu, Apr 4, 2019 at 10:36 PM Liming Sun wrote:
> > This commit adds the TmFifo platform driver for Mellanox BlueField
> > Soc. TmFifo is a shared FIFO which enables external host machine
> > to exchange data with the SoC via USB or PCIe. The driver is based
> > on virtio framework and has console and network access enabled.
>
> Thanks for an update. Almost good.
> My comments below.
>
> Meanwhile I pushed this to my review and testing queue, thanks!
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Perhaps blank line here. Would be more clear that this is utilizing
> virtio framework.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> > +/**
> > + * mlxbf_tmfifo_msg_hdr - Structure of the TmFifo message header
> > + * @type: message type
> > + * @len: payload length
> > + * @u: 64-bit union data
> > + */
> > +union mlxbf_tmfifo_msg_hdr {
> > + struct {
> > + u8 type;
> > + __be16 len;
> > + u8 unused[5];
> > + } __packed;
> > + u64 data;
>
> I'm not sure I understand how you can distinguish which field of union to use?
> Isn't here some type missed?
>
> > +};
>
> > +static u8 mlxbf_tmfifo_net_default_mac[ETH_ALEN] = {
>
> > + 0x00, 0x1A, 0xCA, 0xFF, 0xFF, 0x01};
>
> This should be two lines.
>
> > +/* Supported virtio-net features. */
> > +#define MLXBF_TMFIFO_NET_FEATURES (BIT_ULL(VIRTIO_NET_F_MTU) | \
> > +BIT_ULL(VIRTIO_NET_F_STATUS) | \
> > +BIT_ULL(VIRTIO_NET_F_MAC))
>
> Better to write as
>
> #define FOO \
> (BIT(x) | BIT(y) ...)
>
> I think I told this earlier?
>
> > +/* Allocate vrings for the fifo. */
>
> fifo -> FIFO (and check all occurrences)
>
> > +static int mlxbf_tmfifo_alloc_vrings(struct mlxbf_tmfifo *fifo,
> > +struct mlxbf_tmfifo_vdev *tm_vdev)
> > +{
> > + struct mlxbf_tmfifo_vring *vring;
> > + struct device *dev;
> > + dma_addr_t dma;
> > + int i, size;
> > + void *va;
> > +
> > + for (i = 0; i < ARRAY_SIZE(tm_vdev->vrings); i++) {
> > + vring = &tm_vdev->vrings[i];
> > + vring->fifo = fifo;
> > + vring->num = MLXBF_TMFIFO_VRING_SIZE;
> > + vring->align = SMP_CACHE_BYTES;
> > + vring->index = i;
> > + vring->vdev_id = tm_vdev->vdev.id.device;
> > + dev = &tm_vdev->vdev.dev;
> > +
> > + size = vring_size(vring->num, vring->align);
> > + va = dma_alloc_coherent(dev->parent, size, &dma,
> > GFP_KERNEL);
> > + if (!va) {
>
> > + dev_err(dev->parent, "dma_alloc_coherent failed\n");
>
> I don't see how this will free the allocated entries.
> I think I told about this eithe
[PATCH v14] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v13->v14: Fixes for comments from Andy: - Add a blank line to separate the virtio header files; - Update the comment for 'union mlxbf_tmfifo_msg_hdr' to be more clear how this union is used; - Update the 'mlxbf_tmfifo_net_default_mac[ETH_ALEN]' definition to be two lines; - Reformat macro MLXBF_TMFIFO_NET_FEATURES to put the definition in a seperate line; - Update all 'fifo' to 'FIFO' in the comments; - Update mlxbf_tmfifo_alloc_vrings() to specifically release the allocated entries in case of failures, so the logic looks more clear. In the caller function the mlxbf_tmfifo_free_vrings() might be called again in case of other failures, which is ok since the 'va' pointer will be set to NULL once released; - Update mlxbf_tmfifo_timer() to change the first statement to one line; - Update one memcpy() to ether_addr_copy() in mlxbf_tmfifo_get_cfg_mac(); - Remove 'fifo->pdev' since it is really not needed; - Define temporary variable to update the mlxbf_tmfifo_create_vdev() statement into single line. New changes by Liming: - Reorder the logic a little bit in mlxbf_tmfifo_timer(). Previously it has logic like "!a || !b" while the '!b' will not be evaluated if '!a' is true. It was changed to this way during review, but is actually not the desired behavior since both bits need to be tested/set in fifo->pend_events. This issue was found during verification which caused extra delays for Tx packets. v12->v13: Rebase and resubmit (no new changes). v11->v12: Fixed the two unsolved comments from v11. - "Change macro mlxbf_vdev_to_tmfifo() to one line" Done. Seems not hard. - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" Yes, understand the comment now. The tmfifo is fixed, but the vdev is dynamic. Use kzalloc() instead, and free the device in the release callback which is the right place for it. v10->v11: Fixes for comments from Andy: - Use GENMASK_ULL() instead of GENMASK() in mlxbf-tmfifo-regs.h - Removed the cpu_to_le64()/le64_to_cpu() conversion since readq()/writeq() already takes care of it. - Remove the "if (irq)" check in mlxbf_tmfifo_disable_irqs(). - Add "u32 count" temp variable in mlxbf_tmfifo_get_tx_avail(). - Clean up mlxbf_tmfifo_get_cfg_mac(), use ETH_ALEN instead of value 6. - Change the tx_buf to use Linux existing 'struct circ_buf'. Comment not applied: - "Change macro mlxbf_vdev_to_tmfifo() to one line" Couldn't fit in one line with 80 chracters - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" This is SoC, the device won't be closed or detached. The only case is when the driver is unloaded. So it appears ok to use devm_kzalloc() since it's allocated during probe() and released during module unload. Comments from Vadim: OK v9->v10: Fixes for comments from Andy: - Use devm_ioremap_resource() instead of devm_ioremap(). - Use kernel-doc comments. - Keep Makefile contents sorted. - Use same fixed format for offsets. - Use SZ_1K/SZ_32K instead of 1024/23*1024. - Remove unnecessary comments. - Use one style for max numbers. - More comments for mlxbf_tmfifo_vdev and mlxbf_tmfifo_data_64bit. - Use globally defined MTU instead of new definition. - Remove forward declaration of mlxbf_tmfifo_remove(). - Remove PAGE_ALIGN() for dma_alloc_coherent)(). - Remove the cast of "struct vring *". - Check return result of test_and_set_bit(). - Add a macro mlxbt_vdev_to_tmfifo(). - Several other minor coding style comments. Comment not applied: - "Shouldn't be rather helper in EFI lib in kernel" Looks like efi.get_variable() is the way I found in the kernel tree. - "this one is not protected anyhow? Potential race condition" In mlxbf_tmfifo_console_tx(), the spin-lock is used to protect the 'tx_buf' only, not the FIFO writes. So there is no race condition. - "Is __packed needed in mlxbf_tmfifo_msg_hdr". Yes, it is needed to make sure the structure is 8 bytes. Fixes for comments from Vadim: - Use tab in mlxbf-tmfifo-regs.h - Use kernel-doc comments for struct mlxbf_tmfifo_msg_hdr and mlxbf_tmfifo_irq_info
Re: [PATCH v13] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy! I just posted v14, which addresses all the comments you mentioned
below for v13.
Regards,
Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Friday, April 5, 2019 11:44 AM
> To: Liming Sun
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: Re: [PATCH v13] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> On Thu, Apr 4, 2019 at 10:36 PM Liming Sun wrote:
> > This commit adds the TmFifo platform driver for Mellanox BlueField
> > Soc. TmFifo is a shared FIFO which enables external host machine
> > to exchange data with the SoC via USB or PCIe. The driver is based
> > on virtio framework and has console and network access enabled.
>
> Thanks for an update. Almost good.
> My comments below.
>
> Meanwhile I pushed this to my review and testing queue, thanks!
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Perhaps blank line here. Would be more clear that this is utilizing
> virtio framework.
Updated in v14.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> > +/**
> > + * mlxbf_tmfifo_msg_hdr - Structure of the TmFifo message header
> > + * @type: message type
> > + * @len: payload length
> > + * @u: 64-bit union data
> > + */
> > +union mlxbf_tmfifo_msg_hdr {
> > + struct {
> > + u8 type;
> > + __be16 len;
> > + u8 unused[5];
> > + } __packed;
> > + u64 data;
>
> I'm not sure I understand how you can distinguish which field of union to use?
> Isn't here some type missed?
Updated the comment in v14.
This message header is a union of struct and u64 data.
The 'struct' has
type and length field which are used to encode & decode the message.
The 'data' field is used to read/write the message header from/to the FIFO.
>
> > +};
>
> > +static u8 mlxbf_tmfifo_net_default_mac[ETH_ALEN] = {
>
> > + 0x00, 0x1A, 0xCA, 0xFF, 0xFF, 0x01};
>
> This should be two lines.
Updated in v14.
>
> > +/* Supported virtio-net features. */
> > +#define MLXBF_TMFIFO_NET_FEATURES (BIT_ULL(VIRTIO_NET_F_MTU) | \
> > +BIT_ULL(VIRTIO_NET_F_STATUS) | \
> > +BIT_ULL(VIRTIO_NET_F_MAC))
>
> Better to write as
>
> #define FOO \
> (BIT(x) | BIT(y) ...)
>
> I think I told this earlier?
Updated in v14.
>
> > +/* Allocate vrings for the fifo. */
>
> fifo -> FIFO (and check all occurrences)
Updated in v14.
>
> > +static int mlxbf_tmfifo_alloc_vrings(struct mlxbf_tmfifo *fifo,
> > +struct mlxbf_tmfifo_vdev *tm_vdev)
> > +{
> > + struct mlxbf_tmfifo_vring *vring;
> > + struct device *dev;
> > + dma_addr_t dma;
> > + int i, size;
> > + void *va;
> > +
> > + for (i = 0; i < ARRAY_SIZE(tm_vdev->vrings); i++) {
> > + vring = &tm_vdev->vrings[i];
> > + vring->fifo = fifo;
> > + vring->num = MLXBF_TMFIFO_VRING_SIZE;
> > + vring->align = SMP_CACHE_BYTES;
> > + vring->index = i;
> > + vring->vdev_id = tm_vdev->vdev.id.device;
> > + dev = &tm_vdev->vdev.dev;
> > +
> > + size = vring_size(vring->num, vring->align);
> > + va = dma_alloc_coherent(dev->parent, size, &dma,
> > GFP_KERNEL);
> > + if (!va) {
>
> > + dev_err(dev->parent, "dma_alloc_coherent failed\n");
>
> I don't see how this will free the allocated entries.
> I think I told about this either.
Updated in v14.
It's not a memory leak since the caller will release them
in case of failures. I added one line in this function to
call the mlxbf_tmfifo_free_vrings() to be more clear.
>
> > + return -ENOMEM;
> > + }
> > +
> > + vring->va = va;
> > + vring->dma = dma;
> > + }
> > +
> > + return 0;
> > +}
>
> > +/* House-keeping timer. */
> > +static void mlxbf_tmfifo_timer(struct timer_list *arg)
> > +{
>
> > + struct mlxbf_tmf
[PATCH v12] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v11->v12: Fixed the two unsolved comments from v11. - "Change macro mlxbf_vdev_to_tmfifo() to one line" Done. Seems not hard. - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" Yes, understand the comment now. The tmfifo is fixed, but the vdev is dynamic. Use kzalloc() instead, and free the device in the release callback which is the right place for it. v10->v11: Fixes for comments from Andy: - Use GENMASK_ULL() instead of GENMASK() in mlxbf-tmfifo-regs.h - Removed the cpu_to_le64()/le64_to_cpu() conversion since readq()/writeq() already takes care of it. - Remove the "if (irq)" check in mlxbf_tmfifo_disable_irqs(). - Add "u32 count" temp variable in mlxbf_tmfifo_get_tx_avail(). - Clean up mlxbf_tmfifo_get_cfg_mac(), use ETH_ALEN instead of value 6. - Change the tx_buf to use Linux existing 'struct circ_buf'. Comment not applied: - "Change macro mlxbf_vdev_to_tmfifo() to one line" Couldn't fit in one line with 80 chracters - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" This is SoC, the device won't be closed or detached. The only case is when the driver is unloaded. So it appears ok to use devm_kzalloc() since it's allocated during probe() and released during module unload. Comments from Vadim: OK v9->v10: Fixes for comments from Andy: - Use devm_ioremap_resource() instead of devm_ioremap(). - Use kernel-doc comments. - Keep Makefile contents sorted. - Use same fixed format for offsets. - Use SZ_1K/SZ_32K instead of 1024/23*1024. - Remove unnecessary comments. - Use one style for max numbers. - More comments for mlxbf_tmfifo_vdev and mlxbf_tmfifo_data_64bit. - Use globally defined MTU instead of new definition. - Remove forward declaration of mlxbf_tmfifo_remove(). - Remove PAGE_ALIGN() for dma_alloc_coherent)(). - Remove the cast of "struct vring *". - Check return result of test_and_set_bit(). - Add a macro mlxbt_vdev_to_tmfifo(). - Several other minor coding style comments. Comment not applied: - "Shouldn't be rather helper in EFI lib in kernel" Looks like efi.get_variable() is the way I found in the kernel tree. - "this one is not protected anyhow? Potential race condition" In mlxbf_tmfifo_console_tx(), the spin-lock is used to protect the 'tx_buf' only, not the FIFO writes. So there is no race condition. - "Is __packed needed in mlxbf_tmfifo_msg_hdr". Yes, it is needed to make sure the structure is 8 bytes. Fixes for comments from Vadim: - Use tab in mlxbf-tmfifo-regs.h - Use kernel-doc comments for struct mlxbf_tmfifo_msg_hdr and mlxbf_tmfifo_irq_info as well. - Use _MAX instead of _CNT in the macro definition to be consistent. - Fix the MODULE_LICENSE. - Use BIT_ULL() instead of BIT(). - Remove argument of 'avail' for mlxbf_tmfifo_rxtx_header() and mlxbf_tmfifo_rxtx_word() - Revise logic in mlxbf_tmfifo_rxtx_one_desc() to remove the WARN_ON(). - Change "union mlxbf_tmfifo_u64 u" to "union mlxbf_tmfifo_u64 buf" in mlxbf_tmfifo_rxtx_word(). - Change date type of vring_change from 'int' to 'bool'. - Remove the blank lines after Signed-off. - Don’t use declaration in the middle. - Make the network header initialization in some more elegant way. - Change label done to mlxbf_tmfifo_desc_done. - Remove some unnecessary comments, and several other misc coding style comments. - Simplify code logic in mlxbf_tmfifo_virtio_notify() New changes by Liming: - Simplify the Rx/Tx function arguments to make it more readable. v8->v9: Fixes for comments from Andy: - Use modern devm_xxx() API instead. Fixes for comments from Vadim: - Split the Rx/Tx function into smaller funcitons. - File name, copyright information. - Function and variable name conversion. - Local variable and indent coding styles. - Remove unnecessary 'inline' declarations. - Use devm_xxx() APIs. - Move the efi_char16_t MAC address definition to global. - Fix warnings reported by 'checkpatch --strict'. - Fix warnings reported by 'make CF="-D__CHECK_ENDIAN__"'. - Change select VIRTIO_xxx to depends on VIRTIO_ in Kconfig. - Merge mlxbf_tmfifo_vdev_tx_buf_push()
[PATCH v16] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v15->v16: Rebase and resubmit (no new changes). v14->v15: Fixes for comments from Andy: - Remove the 'union' definition of mlxbf_tmfifo_msg_hdr and use on-the-fly conversion when sending the 8-byte message header into the FIFO; - Update comment of mlxbf_tmfifo_msg_hdr explaining why '__be16' is needed for the 'len' field. The SoC sends data stream into the FIFO and the other side reads it. The byte order of the data stream (byte-stream) stays the same. The 'len' field is encoded into network byte order so upper-level applications in external host machine with different endianness could decode it. This implementation was verified over USB with an external PPC host machine running in big-endian mode. - Move the 'dev_err()' line to the end of the block in function mlxbf_tmfifo_alloc_vrings(); - Remove the 'irq_info->index < MLXBF_TM_MAX_IRQ' check in mlxbf_tmfifo_irq_handler() since it's unnecessary; - Remove the 'if (desc_head)' check in mlxbf_tmfifo_release_pending_pkt() since function mlxbf_tmfifo_get_pkt_len() is already NULL-aware; - Adjust the testing order of 'if (!(vring->index & BIT(0)))' in bool mlxbf_tmfifo_virtio_notify() to test the positive case 'if (vring->index & BIT(0))' first; - Add '(u64)offset' conversion in mlxbf_tmfifo_virtio_get() to avoid 32-bit length addition overflow; - Update the 'efi.get_variable' statement into single line in mlxbf_tmfifo_get_cfg_mac(); - Use new helper devm_platform_ioremap_resource() to replace 'platform_get_resource() + devm_ioremap_resource()' in mlxbf_tmfifo_probe(); v13->v14: Fixes for comments from Andy: - Add a blank line to separate the virtio header files; - Update the comment for 'union mlxbf_tmfifo_msg_hdr' to be more clear how this union is used; - Update the 'mlxbf_tmfifo_net_default_mac[ETH_ALEN]' definition to be two lines; - Reformat macro MLXBF_TMFIFO_NET_FEATURES to put the definition in a seperate line; - Update all 'fifo' to 'FIFO' in the comments; - Update mlxbf_tmfifo_alloc_vrings() to specifically release the allocated entries in case of failures, so the logic looks more clear. In the caller function the mlxbf_tmfifo_free_vrings() might be called again in case of other failures, which is ok since the 'va' pointer will be set to NULL once released; - Update mlxbf_tmfifo_timer() to change the first statement to one line; - Update one memcpy() to ether_addr_copy() in mlxbf_tmfifo_get_cfg_mac(); - Remove 'fifo->pdev' since it is really not needed; - Define temporary variable to update the mlxbf_tmfifo_create_vdev() statement into single line. New changes by Liming: - Reorder the logic a little bit in mlxbf_tmfifo_timer(). Previously it has logic like "!a || !b" while the '!b' will not be evaluated if '!a' is true. It was changed to this way during review, but is actually not the desired behavior since both bits need to be tested/set in fifo->pend_events. This issue was found during verification which caused extra delays for Tx packets. v12->v13: Rebase and resubmit (no new changes). v11->v12: Fixed the two unsolved comments from v11. - "Change macro mlxbf_vdev_to_tmfifo() to one line" Done. Seems not hard. - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" Yes, understand the comment now. The tmfifo is fixed, but the vdev is dynamic. Use kzalloc() instead, and free the device in the release callback which is the right place for it. v10->v11: Fixes for comments from Andy: - Use GENMASK_ULL() instead of GENMASK() in mlxbf-tmfifo-regs.h - Removed the cpu_to_le64()/le64_to_cpu() conversion since readq()/writeq() already takes care of it. - Remove the "if (irq)" check in mlxbf_tmfifo_disable_irqs(). - Add "u32 count" temp variable in mlxbf_tmfifo_get_tx_avail(). - Clean up mlxbf_tmfifo_get_cfg_mac(), use ETH_ALEN instead of value 6. - Change the tx_buf to use Linux existing 'struct circ_buf'. Comment not applied: - "Change macro mlxbf_vdev_to_tmfifo() to one line" Couldn't fit in one line with 80 c
[PATCH v11] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v10->v11: Fixes for comments from Andy: - Use GENMASK_ULL() instead of GENMASK() in mlxbf-tmfifo-regs.h - Removed the cpu_to_le64()/le64_to_cpu() conversion since readq()/writeq() already takes care of it. - Remove the "if (irq)" check in mlxbf_tmfifo_disable_irqs(). - Add "u32 count" temp variable in mlxbf_tmfifo_get_tx_avail(). - Clean up mlxbf_tmfifo_get_cfg_mac(), use ETH_ALEN instead of value 6. - Change the tx_buf to use Linux existing 'struct circ_buf'. Comment not applied: - "Change macro mlxbf_vdev_to_tmfifo() to one line" Couldn't fit in one line with 80 chracters - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" This is SoC, the device won't be closed or detached. The only case is when the driver is unloaded. So it appears ok to use devm_kzalloc() since it's allocated during probe() and released during module unload. Comments from Vadim: OK v9->v10: Fixes for comments from Andy: - Use devm_ioremap_resource() instead of devm_ioremap(). - Use kernel-doc comments. - Keep Makefile contents sorted. - Use same fixed format for offsets. - Use SZ_1K/SZ_32K instead of 1024/23*1024. - Remove unnecessary comments. - Use one style for max numbers. - More comments for mlxbf_tmfifo_vdev and mlxbf_tmfifo_data_64bit. - Use globally defined MTU instead of new definition. - Remove forward declaration of mlxbf_tmfifo_remove(). - Remove PAGE_ALIGN() for dma_alloc_coherent)(). - Remove the cast of "struct vring *". - Check return result of test_and_set_bit(). - Add a macro mlxbt_vdev_to_tmfifo(). - Several other minor coding style comments. Comment not applied: - "Shouldn't be rather helper in EFI lib in kernel" Looks like efi.get_variable() is the way I found in the kernel tree. - "this one is not protected anyhow? Potential race condition" In mlxbf_tmfifo_console_tx(), the spin-lock is used to protect the 'tx_buf' only, not the FIFO writes. So there is no race condition. - "Is __packed needed in mlxbf_tmfifo_msg_hdr". Yes, it is needed to make sure the structure is 8 bytes. Fixes for comments from Vadim: - Use tab in mlxbf-tmfifo-regs.h - Use kernel-doc comments for struct mlxbf_tmfifo_msg_hdr and mlxbf_tmfifo_irq_info as well. - Use _MAX instead of _CNT in the macro definition to be consistent. - Fix the MODULE_LICENSE. - Use BIT_ULL() instead of BIT(). - Remove argument of 'avail' for mlxbf_tmfifo_rxtx_header() and mlxbf_tmfifo_rxtx_word() - Revise logic in mlxbf_tmfifo_rxtx_one_desc() to remove the WARN_ON(). - Change "union mlxbf_tmfifo_u64 u" to "union mlxbf_tmfifo_u64 buf" in mlxbf_tmfifo_rxtx_word(). - Change date type of vring_change from 'int' to 'bool'. - Remove the blank lines after Signed-off. - Don’t use declaration in the middle. - Make the network header initialization in some more elegant way. - Change label done to mlxbf_tmfifo_desc_done. - Remove some unnecessary comments, and several other misc coding style comments. - Simplify code logic in mlxbf_tmfifo_virtio_notify() New changes by Liming: - Simplify the Rx/Tx function arguments to make it more readable. v8->v9: Fixes for comments from Andy: - Use modern devm_xxx() API instead. Fixes for comments from Vadim: - Split the Rx/Tx function into smaller funcitons. - File name, copyright information. - Function and variable name conversion. - Local variable and indent coding styles. - Remove unnecessary 'inline' declarations. - Use devm_xxx() APIs. - Move the efi_char16_t MAC address definition to global. - Fix warnings reported by 'checkpatch --strict'. - Fix warnings reported by 'make CF="-D__CHECK_ENDIAN__"'. - Change select VIRTIO_xxx to depends on VIRTIO_ in Kconfig. - Merge mlxbf_tmfifo_vdev_tx_buf_push() and mlxbf_tmfifo_vdev_tx_buf_pop(). - Add union to avoid casting between __le64 and u64. - Several other misc coding style comments. New changes by Liming: - Removed the DT binding documentation since only ACPI is supported for now by UEFI on the SoC. v8: Re-submit under drivers/platform/mellanox for the target-side platform driver only. v7: Added host side drivers into the same patch set. v5~v6: Codi
RE: [PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Andy, The v11 has been posted. Thanks! Liming > -Original Message- > From: Liming Sun > Sent: Wednesday, March 6, 2019 3:01 PM > To: 'Andy Shevchenko' > Cc: David Woods ; Andy Shevchenko ; > Darren Hart ; Vadim > Pasternak ; Linux Kernel Mailing List > ; Platform Driver x...@vger.kernel.org> > Subject: RE: [PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox > BlueField Soc > > Thanks Andy! Please see my response below. If no further comments, I'll try > to post v11 after more testing. > > Regards, > Liming > > > -Original Message- > > From: Andy Shevchenko > > Sent: Tuesday, March 5, 2019 10:34 AM > > To: Liming Sun > > Cc: David Woods ; Andy Shevchenko > > ; Darren Hart ; Vadim > > Pasternak ; Linux Kernel Mailing List > > ; Platform Driver > x...@vger.kernel.org> > > Subject: Re: [PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox > > BlueField Soc > > > > On Thu, Feb 28, 2019 at 5:51 PM Liming Sun wrote: > > > > > > This commit adds the TmFifo platform driver for Mellanox BlueField > > > Soc. TmFifo is a shared FIFO which enables external host machine > > > to exchange data with the SoC via USB or PCIe. The driver is based > > > on virtio framework and has console and network access enabled. > > > > Thank you for an update. > > > > Unfortunately more work is needed. My comments below. > > > > > +#define MLXBF_TMFIFO_TX_STS__COUNT_RMASK GENMASK(8, 0) > > > +#define MLXBF_TMFIFO_TX_STS__COUNT_MASK > > > GENMASK(8, 0) > > > > > +#define MLXBF_TMFIFO_TX_CTL__LWM_RMASK GENMASK(7, 0) > > > +#define MLXBF_TMFIFO_TX_CTL__LWM_MASK GENMASK(7, 0) > > > > > +#define MLXBF_TMFIFO_TX_CTL__HWM_RMASK GENMASK(7, 0) > > > +#define MLXBF_TMFIFO_TX_CTL__HWM_MASK GENMASK(15, 8) > > > > > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RMASK GENMASK(8, 0) > > > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_MASK GENMASK_ULL(40, > > > 32) > > > > > +#define MLXBF_TMFIFO_RX_STS__COUNT_RMASK GENMASK(8, 0) > > > +#define MLXBF_TMFIFO_RX_STS__COUNT_MASK > > > GENMASK(8, 0) > > > > > +#define MLXBF_TMFIFO_RX_CTL__LWM_RMASK GENMASK(7, 0) > > > +#define MLXBF_TMFIFO_RX_CTL__LWM_MASK GENMASK(7, 0) > > > > > +#define MLXBF_TMFIFO_RX_CTL__HWM_RMASK GENMASK(7, 0) > > > +#define MLXBF_TMFIFO_RX_CTL__HWM_MASK GENMASK(15, 8) > > > > > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK GENMASK(8, 0) > > > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_MASK GENMASK_ULL(40, > > > 32) > > > > Since two of them have _ULL suffix I'm wondering if you have checked > > for side effects on the rest, i.e. if you operate with 64-bit variable > > and use something like ~MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK, it may > > give you interesting results. > > The running system on the SoC is arm64 where BITS_PER_LONG and > BITS_PER_LONG_LONG have the same value. In such case, the two macros appears > to be the same. But you're right, I should use GENMASK_ULL() to be consistent > and more correctly, just in case the "CONFIG_64BIT" is not defined somehow. > > Will update it in v11. > > > > > > +#define MLXBF_TMFIFO_TIMER_INTERVAL(HZ / 10) > > > > > +/** > > > + * mlxbf_tmfifo_u64 - Union of 64-bit data > > > + * @data - 64-bit data in host byte order > > > + * @data_le - 64-bit data in little-endian byte order > > > + * > > > + * It's expected to send 64-bit little-endian value (__le64) into the > > > TmFifo. > > > + * readq() and writeq() expect u64 instead. A union structure is used > > > here > > > + * to workaround the explicit casting usage like writeq(*(u64 > > > *)&data_le). > > > + */ > > > > How do you know what readq()/writeq() does with the data? Is it on all > > architectures? > > How the endianess conversion affects the actual data? > > The SoC runs arm64 and supports little endian for now. The FIFO has two sides, > one side is the SoC, the other side is extern host machine which could > access the FIFO via USB or PCIe. The rule is that the 'byte stream' will > keep the same when one side write 8 bytes and the other side reads > the 8 bytes.
[PATCH v9] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Signed-off-by: Liming Sun --- v9: Fix coding styles. Adjust code to use devm_xxx() APIs. Removed the DT binding documentation since only ACPI is supported for now by UEFI on the SoC. v8: Re-submit under drivers/platform/mellanox with target-size platform driver only. v7: Added host side drivers into the same patch set. v5~v6: Coding style fix. v1~v4: Initial version for directory drivers/soc/mellanox. --- drivers/platform/mellanox/Kconfig | 10 +- drivers/platform/mellanox/Makefile|1 + drivers/platform/mellanox/mlxbf-tmfifo-regs.h | 67 ++ drivers/platform/mellanox/mlxbf-tmfifo.c | 1361 + 4 files changed, 1438 insertions(+), 1 deletion(-) create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo-regs.h create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo.c diff --git a/drivers/platform/mellanox/Kconfig b/drivers/platform/mellanox/Kconfig index cd8a908..6feceb1 100644 --- a/drivers/platform/mellanox/Kconfig +++ b/drivers/platform/mellanox/Kconfig @@ -5,7 +5,7 @@ menuconfig MELLANOX_PLATFORM bool "Platform support for Mellanox hardware" - depends on X86 || ARM || COMPILE_TEST + depends on X86 || ARM || ARM64 || COMPILE_TEST ---help--- Say Y here to get to see options for platform support for Mellanox systems. This option alone does not add any kernel code. @@ -34,4 +34,12 @@ config MLXREG_IO to system resets operation, system reset causes monitoring and some kinds of mux selection. +config MLXBF_TMFIFO + tristate "Mellanox BlueField SoC TmFifo platform driver" + depends on ARM64 && ACPI && VIRTIO_CONSOLE && VIRTIO_NET + help + Say y here to enable TmFifo support. The TmFifo driver provides + platform driver support for the TmFifo which supports console + and networking based on the virtio framework. + endif # MELLANOX_PLATFORM diff --git a/drivers/platform/mellanox/Makefile b/drivers/platform/mellanox/Makefile index 57074d9c..f0c061d 100644 --- a/drivers/platform/mellanox/Makefile +++ b/drivers/platform/mellanox/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o +obj-$(CONFIG_MLXBF_TMFIFO) += mlxbf-tmfifo.o diff --git a/drivers/platform/mellanox/mlxbf-tmfifo-regs.h b/drivers/platform/mellanox/mlxbf-tmfifo-regs.h new file mode 100644 index 000..90c9c2cf --- /dev/null +++ b/drivers/platform/mellanox/mlxbf-tmfifo-regs.h @@ -0,0 +1,67 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2019, Mellanox Technologies. All rights reserved. + */ + +#ifndef __MLXBF_TMFIFO_REGS_H__ +#define __MLXBF_TMFIFO_REGS_H__ + +#include + +#define MLXBF_TMFIFO_TX_DATA 0x0 + +#define MLXBF_TMFIFO_TX_STS 0x8 +#define MLXBF_TMFIFO_TX_STS__LENGTH 0x0001 +#define MLXBF_TMFIFO_TX_STS__COUNT_SHIFT 0 +#define MLXBF_TMFIFO_TX_STS__COUNT_WIDTH 9 +#define MLXBF_TMFIFO_TX_STS__COUNT_RESET_VAL 0 +#define MLXBF_TMFIFO_TX_STS__COUNT_RMASK 0x1ff +#define MLXBF_TMFIFO_TX_STS__COUNT_MASK 0x1ff + +#define MLXBF_TMFIFO_TX_CTL 0x10 +#define MLXBF_TMFIFO_TX_CTL__LENGTH 0x0001 +#define MLXBF_TMFIFO_TX_CTL__LWM_SHIFT 0 +#define MLXBF_TMFIFO_TX_CTL__LWM_WIDTH 8 +#define MLXBF_TMFIFO_TX_CTL__LWM_RESET_VAL 128 +#define MLXBF_TMFIFO_TX_CTL__LWM_RMASK 0xff +#define MLXBF_TMFIFO_TX_CTL__LWM_MASK 0xff +#define MLXBF_TMFIFO_TX_CTL__HWM_SHIFT 8 +#define MLXBF_TMFIFO_TX_CTL__HWM_WIDTH 8 +#define MLXBF_TMFIFO_TX_CTL__HWM_RESET_VAL 128 +#define MLXBF_TMFIFO_TX_CTL__HWM_RMASK 0xff +#define MLXBF_TMFIFO_TX_CTL__HWM_MASK 0xff00 +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_SHIFT 32 +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_WIDTH 9 +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RESET_VAL 256 +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RMASK 0x1ff +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_MASK 0x1ffULL + +#define MLXBF_TMFIFO_RX_DATA 0x0 + +#define MLXBF_TMFIFO_RX_STS 0x8 +#define MLXBF_TMFIFO_RX_STS__LENGTH 0x0001 +#define MLXBF_TMFIFO_RX_STS__COUNT_SHIFT 0 +#define MLXBF_TMFIFO_RX_STS__COUNT_WIDTH 9 +#define MLXBF_TMFIFO_RX_STS__COUNT_RESET_VAL 0 +#define MLXBF_TMFIFO_RX_STS__COUNT_RMASK 0x1ff +#define MLXBF_TMFIFO_RX_STS__COUNT_MASK 0x1ff + +#define MLXBF_TMFIFO_RX_CTL 0x10 +#define MLXBF_TMFIFO_RX_CTL__LENGTH 0x0001 +#define MLXBF_TMFIFO_RX_CTL__LWM_SHIFT 0 +#define MLXBF_TMFIFO_RX_CTL__LWM_WIDTH 8 +#define MLXBF_TMFIFO_RX_CTL__LWM_RESET_VAL 128 +#define MLXBF_TMFIFO_RX_CTL__LWM_RMASK 0xff +#define MLXBF_TMFIFO_RX_CTL__LWM_MASK 0xff +#define MLXBF_TMFIFO_RX_CTL__HWM_SHIFT 8 +#define MLXBF_TMFIFO_RX_CTL__HWM_WIDTH 8 +#define MLXBF_TMFIFO_RX_CTL__HWM_RESET_VAL 128
RE: [PATCH v8 1/2] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy. Sorry I had email issue earlier today. Not sure the reply was sent out or not. So sent another one just in case... v9 of this patch has been posted to address the 'devm_' comment. It also has the coding-style changes according to the comments I got for another patch. Regards, Liming > -Original Message- > From: Andy Shevchenko > Sent: Tuesday, January 29, 2019 5:07 PM > To: Liming Sun > Cc: Rob Herring ; Mark Rutland ; > Arnd Bergmann ; David Woods > ; Andy Shevchenko ; Darren Hart > ; Vadim Pasternak > ; devicetree ; Linux Kernel > Mailing List ; > Platform Driver > Subject: Re: [PATCH v8 1/2] platform/mellanox: Add TmFifo driver for Mellanox > BlueField Soc > > On Mon, Jan 28, 2019 at 7:28 PM Liming Sun wrote: > > > > This commit adds the TmFifo platform driver for Mellanox BlueField > > Soc. TmFifo is a shared FIFO which enables external host machine > > to exchange data with the SoC via USB or PCIe. The driver is based > > on virtio framework and has console and network access enabled. > > > > Reviewed-by: David Woods > > Signed-off-by: Liming Sun > > > Please, go through this series taking into account review I just did > for your another patch. > > On top of that, see recent (for few years I think) drivers what modern > APIs they are using, e.g. devm_. > > -- > With Best Regards, > Andy Shevchenko
RE: [PATCH v9] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy. We actually had some internal reviews as you mentioned.
I'll try to solve the comments and update the 'Reviewed-by' in next revision.
Regards,
Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Wednesday, February 13, 2019 1:11 PM
> To: Liming Sun
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: Re: [PATCH v9] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> On Wed, Feb 13, 2019 at 3:27 PM Liming Sun wrote:
> >
> > This commit adds the TmFifo platform driver for Mellanox BlueField
> > Soc. TmFifo is a shared FIFO which enables external host machine
> > to exchange data with the SoC via USB or PCIe. The driver is based
> > on virtio framework and has console and network access enabled.
>
> Thanks for an update, my comments below.
>
> Again, to Mellanox: guys, please, establish internal mailing list for
> review and don't come with such quality of code.
>
> Next time I would like to see Reviewed-by from Mellanox people I know,
> like Vadim or Leon.
>
> > +config MLXBF_TMFIFO
> > + tristate "Mellanox BlueField SoC TmFifo platform driver"
>
> > + depends on ARM64 && ACPI && VIRTIO_CONSOLE && VIRTIO_NET
>
> Split this to three logical parts.
>
> > + help
> > + Say y here to enable TmFifo support. The TmFifo driver provides
> > + platform driver support for the TmFifo which supports console
> > + and networking based on the virtio framework.
>
> > obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
> > obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
> > +obj-$(CONFIG_MLXBF_TMFIFO) += mlxbf-tmfifo.o
>
> I would suggest to keep it sorted.
>
> > +#define MLXBF_TMFIFO_TX_DATA 0x0
>
> I suggest to use same fixed format for offsets.
> Here, for example, 0x00 would be better.
>
> > +#define MLXBF_TMFIFO_TX_STS__COUNT_RMASK 0x1ff
> > +#define MLXBF_TMFIFO_TX_STS__COUNT_MASK 0x1ff
>
> #include
> ...
> GENMASK()
>
> > +#define MLXBF_TMFIFO_TX_CTL__LWM_RMASK 0xff
> > +#define MLXBF_TMFIFO_TX_CTL__LWM_MASK 0xff
>
> > +#define MLXBF_TMFIFO_TX_CTL__HWM_RMASK 0xff
> > +#define MLXBF_TMFIFO_TX_CTL__HWM_MASK 0xff00
>
> > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RMASK 0x1ff
> > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_MASK 0x1ffULL
>
> GENMASK() / GENMASK_ULL()
>
> > +#define MLXBF_TMFIFO_RX_STS__COUNT_RMASK 0x1ff
> > +#define MLXBF_TMFIFO_RX_STS__COUNT_MASK 0x1ff
>
> GENMASK()
>
> > +#define MLXBF_TMFIFO_RX_CTL__LWM_RMASK 0xff
> > +#define MLXBF_TMFIFO_RX_CTL__LWM_MASK 0xff
>
> > +#define MLXBF_TMFIFO_RX_CTL__HWM_RMASK 0xff
> > +#define MLXBF_TMFIFO_RX_CTL__HWM_MASK 0xff00
>
> > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK 0x1ff
> > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_MASK 0x1ffULL
>
> Ditto.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Do you need all of them?
>
> > +#define MLXBF_TMFIFO_VRING_SIZE1024
>
> SZ_1K ?
>
> > +/* Console Tx buffer size. */
> > +#define MLXBF_TMFIFO_CONS_TX_BUF_SIZE (32 * 1024)
>
> SZ_32K ?
>
> > +/* House-keeping timer interval. */
> > +static int mlxbf_tmfifo_timer_interval = HZ / 10;
>
> > +/* Global lock. */
>
> Noise. Either explain what it protects, or remove.
>
> > +static DEFINE_MUTEX(mlxbf_tmfifo_lock);
>
> > +/* Struct declaration. */
>
> Noise.
>
> > +/* Structure to maintain the ring state. */
> > +struct mlxbf_tmfifo_vring {
> > + void *va; /* virtual address */
> > + dma_addr_t dma; /* dma address */
> > + struct virtqueue *vq; /* virtqueue pointer */
> > + struct vring_desc *desc;/* current desc */
> > + struct vring_desc *desc_head; /* current desc head */
> > + int cur_len;/* processed len in current des
RE: [PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy! Please see my response below. If no further comments, I'll try to
post v11 after more testing.
Regards,
Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Tuesday, March 5, 2019 10:34 AM
> To: Liming Sun
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: Re: [PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> On Thu, Feb 28, 2019 at 5:51 PM Liming Sun wrote:
> >
> > This commit adds the TmFifo platform driver for Mellanox BlueField
> > Soc. TmFifo is a shared FIFO which enables external host machine
> > to exchange data with the SoC via USB or PCIe. The driver is based
> > on virtio framework and has console and network access enabled.
>
> Thank you for an update.
>
> Unfortunately more work is needed. My comments below.
>
> > +#define MLXBF_TMFIFO_TX_STS__COUNT_RMASK GENMASK(8, 0)
> > +#define MLXBF_TMFIFO_TX_STS__COUNT_MASKGENMASK(8,
> > 0)
>
> > +#define MLXBF_TMFIFO_TX_CTL__LWM_RMASK GENMASK(7, 0)
> > +#define MLXBF_TMFIFO_TX_CTL__LWM_MASK GENMASK(7, 0)
>
> > +#define MLXBF_TMFIFO_TX_CTL__HWM_RMASK GENMASK(7, 0)
> > +#define MLXBF_TMFIFO_TX_CTL__HWM_MASK GENMASK(15, 8)
>
> > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RMASK GENMASK(8, 0)
> > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_MASK GENMASK_ULL(40, 32)
>
> > +#define MLXBF_TMFIFO_RX_STS__COUNT_RMASK GENMASK(8, 0)
> > +#define MLXBF_TMFIFO_RX_STS__COUNT_MASKGENMASK(8,
> > 0)
>
> > +#define MLXBF_TMFIFO_RX_CTL__LWM_RMASK GENMASK(7, 0)
> > +#define MLXBF_TMFIFO_RX_CTL__LWM_MASK GENMASK(7, 0)
>
> > +#define MLXBF_TMFIFO_RX_CTL__HWM_RMASK GENMASK(7, 0)
> > +#define MLXBF_TMFIFO_RX_CTL__HWM_MASK GENMASK(15, 8)
>
> > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK GENMASK(8, 0)
> > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_MASK GENMASK_ULL(40, 32)
>
> Since two of them have _ULL suffix I'm wondering if you have checked
> for side effects on the rest, i.e. if you operate with 64-bit variable
> and use something like ~MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK, it may
> give you interesting results.
The running system on the SoC is arm64 where BITS_PER_LONG and
BITS_PER_LONG_LONG have the same value. In such case, the two macros appears
to be the same. But you're right, I should use GENMASK_ULL() to be consistent
and more correctly, just in case the "CONFIG_64BIT" is not defined somehow.
Will update it in v11.
>
> > +#define MLXBF_TMFIFO_TIMER_INTERVAL(HZ / 10)
>
> > +/**
> > + * mlxbf_tmfifo_u64 - Union of 64-bit data
> > + * @data - 64-bit data in host byte order
> > + * @data_le - 64-bit data in little-endian byte order
> > + *
> > + * It's expected to send 64-bit little-endian value (__le64) into the
> > TmFifo.
> > + * readq() and writeq() expect u64 instead. A union structure is used here
> > + * to workaround the explicit casting usage like writeq(*(u64 *)&data_le).
> > + */
>
> How do you know what readq()/writeq() does with the data? Is it on all
> architectures?
> How the endianess conversion affects the actual data?
The SoC runs arm64 and supports little endian for now. The FIFO has two sides,
one side is the SoC, the other side is extern host machine which could
access the FIFO via USB or PCIe. The rule is that the 'byte stream' will
keep the same when one side write 8 bytes and the other side reads
the 8 bytes. So as long as both sides have agreement on the byte-order
it should be fine.
After double check the arm64 readq()/writeq() implementation, it appears
that these APIs already does cpu_to_le64() and le64_to_cpu()
conversion. There's actually no need to make another conversion
(and shouldn't do it). I'll remove these conversions in v11. The code will
look much cleaner.
>
> > +union mlxbf_tmfifo_u64 {
> > + u64 data;
> > + __le64 data_le;
> > +};
>
> > +/*
> > + * Default MAC.
> > + * This MAC address will be read from EFI persistent variable if
> > configured.
> > + * It can also be reconfigured with standard Linux tools.
> > + */
> > +static u8 mlxbf_tmfifo_net_default_mac[6] = {
> > + 0x00, 0x1A, 0xCA, 0xFF, 0xFF, 0x01};
>
> > +#define mlxbf_vdev_to_tmfifo(dev) \
> > + container_of(dev, struct ml
RE: [PATCH v7 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver
Thanks! I'll try to send this one to arm soc. Best regards, Liming > -Original Message- > From: Ulf Hansson [mailto:ulf.hans...@linaro.org] > Sent: Monday, May 21, 2018 7:36 AM > To: Liming Sun > Cc: Rob Herring ; Mark Rutland > ; Jaehoon Chung ; > Catalin Marinas ; Will Deacon > ; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; Linux Kernel Mailing List ker...@vger.kernel.org> > Subject: Re: [PATCH v7 3/3] arm64: defconfig: Enable dw_mmc-bluefield > driver > > On 8 May 2018 at 20:46, Liming Sun wrote: > > This patch updates arm64 defconfig to enable dw_mmc-bluefield, > > which is a driver extension of Synopsys Designware MMC for the > > Mellanox BlueField Soc. > > > > Signed-off-by: Liming Sun > > Reviewed-by: David Woods > > I have applied the other parts in the series, but not this one as it's > probably better it goes via arm soc. > > I can take it, but then I need an ack from arm64 folkz... > > Kind regards > Uffe > > > --- > > arch/arm64/configs/defconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > > index ecf6137..43464ab 100644 > > --- a/arch/arm64/configs/defconfig > > +++ b/arch/arm64/configs/defconfig > > @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y > > CONFIG_MMC_DW_EXYNOS=y > > CONFIG_MMC_DW_K3=y > > CONFIG_MMC_DW_ROCKCHIP=y > > +CONFIG_MMC_DW_BLUEFIELD=y > > CONFIG_MMC_SUNXI=y > > CONFIG_MMC_BCM2835=y > > CONFIG_MMC_SDHCI_XENON=y > > -- > > 1.8.3.1 > >
RE: [PATCH 1/2] mmc: dw_mmc-bluefield: Add driver extension
Thanks Uffe. I'll submit patch 2 as suggested.
Best regards,
Liming
> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Monday, April 23, 2018 5:32 AM
> To: Liming Sun
> Cc: Rob Herring ; Mark Rutland
> ; Jaehoon Chung ;
> Catalin Marinas ; Will Deacon
> ; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; Linux Kernel Mailing List ker...@vger.kernel.org>
> Subject: Re: [PATCH 1/2] mmc: dw_mmc-bluefield: Add driver extension
>
> On 20 April 2018 at 19:32, Liming Sun wrote:
> > This commit adds extension to the dw_mmc driver for Mellanox BlueField
> > SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
> > this SoC.
> >
> > Signed-off-by: Liming Sun
> > ---
> > .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 +
>
> Please move changes to DT docs into a separate patch.
>
> Otherwise this looks good to me.
>
> Kind regards
> Uffe
>
> > drivers/mmc/host/Kconfig | 9 +++
> > drivers/mmc/host/Makefile | 1 +
> > drivers/mmc/host/dw_mmc-bluefield.c| 72
> ++
> > 4 files changed, 111 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-
> dw-mshc.txt
> > create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-
> mshc.txt b/Documentation/devicetree/bindings/mmc/bluefield-dw-
> mshc.txt
> > new file mode 100644
> > index 000..ee0dd61
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
> > @@ -0,0 +1,29 @@
> > +* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
> > + Mobile Storage Host Controller
> > +
> > +Read synopsys-dw-mshc.txt for more details
> > +
> > +The Synopsys designware mobile storage host controller is used to
> interface
> > +a SoC with storage medium such as eMMC or SD/MMC cards. This file
> documents
> > +differences between the core Synopsys dw mshc controller properties
> described
> > +by synopsys-dw-mshc.txt and the properties used by the Mellanox
> Bluefield SoC
> > +specific extensions to the Synopsys Designware Mobile Storage Host
> Controller.
> > +
> > +Required Properties:
> > +
> > +* compatible: should be one of the following.
> > + - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield
> SoC
> > +specific extensions.
> > +
> > +Example:
> > +
> > + /* Mellanox Bluefield SoC MMC */
> > + dwmmc0@4,0 {
> > + compatible = "mellanox,bluefield-dw-mshc";
> > + reg = <4 0x8000 0x400>;
> > + interrupts = <32>;
> > + fifo-depth = <0x100>;
> > + clock-frequency = <2400>;
> > + bus-width = <8>;
> > + cap-mmc-highspeed;
> > + };
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 9589f9c..26ac6b5 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -717,6 +717,15 @@ config MMC_DW_K3
> > Synopsys DesignWare Memory Card Interface driver. Select this
> option
> > for platforms based on Hisilicon K3 SoC's.
> >
> > +config MMC_DW_BLUEFIELD
> > + tristate "BlueField specific extensions for Synopsys DW Memory Card
> Interface"
> > + depends on MMC_DW
> > + select MMC_DW_PLTFM
> > + help
> > + This selects support for Mellanox BlueField SoC specific
> > extensions to
> > + the Synopsys DesignWare Memory Card Interface driver. Select this
> > + option for platforms based on Mellanox BlueField SoC's.
> > +
> > config MMC_DW_PCI
> > tristate "Synopsys Designware MCI support on PCI bus"
> > depends on MMC_DW && PCI
> > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> > index 6aead24..267b3f1 100644
> > --- a/drivers/mmc/host/Makefile
> > +++ b/drivers/mmc/host/Makefile
> > @@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-
> k3.o
> > obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
> > obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
> > obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o
> > +obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
> > obj-$(CONFIG_MMC_SH_MMCIF) +=
[PATCH v2 1/3] mmc: dw_mmc-bluefield: Add driver extension
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Signed-off-by: Liming Sun
---
drivers/mmc/host/Kconfig| 9 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/dw_mmc-bluefield.c | 72 +
3 files changed, 82 insertions(+)
create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c..26ac6b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -717,6 +717,15 @@ config MMC_DW_K3
Synopsys DesignWare Memory Card Interface driver. Select this option
for platforms based on Hisilicon K3 SoC's.
+config MMC_DW_BLUEFIELD
+ tristate "BlueField specific extensions for Synopsys DW Memory Card
Interface"
+ depends on MMC_DW
+ select MMC_DW_PLTFM
+ help
+ This selects support for Mellanox BlueField SoC specific extensions to
+ the Synopsys DesignWare Memory Card Interface driver. Select this
+ option for platforms based on Mellanox BlueField SoC's.
+
config MMC_DW_PCI
tristate "Synopsys Designware MCI support on PCI bus"
depends on MMC_DW && PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 6aead24..267b3f1 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-k3.o
obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o
+obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
new file mode 100644
index 000..12067b1
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Mellanox Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ u32 regs;
+
+ /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT. */
+ regs = mci_readl(host, UHS_REG_EXT);
+ regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
+ mci_writel(host, UHS_REG_EXT, regs);
+}
+
+static const struct dw_mci_drv_data bluefield_drv_data = {
+ .set_ios= dw_mci_bluefield_set_ios
+};
+
+static const struct of_device_id dw_mci_bluefield_match[] = {
+ { .compatible = "mellanox,bluefield-dw-mshc",
+ .data = &bluefield_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_bluefield_match);
+
+static int dw_mci_bluefield_probe(struct platform_device *pdev)
+{
+ const struct dw_mci_drv_data *drv_data = NULL;
+ const struct of_device_id *match;
+
+ if (pdev->dev.of_node) {
+ match = of_match_node(dw_mci_bluefield_match,
+ pdev->dev.of_node);
+ drv_data = match->data;
+ }
+
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_bluefield_pltfm_driver = {
+ .probe = dw_mci_bluefield_probe,
+ .remove = dw_mci_pltfm_remove,
+ .driver = {
+ .name = "dwmmc_bluefield",
+ .of_match_table = dw_mci_bluefield_match,
+ .pm = &dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_bluefield_pltfm_driver);
+
+MODULE_DESCRIPTION("BlueField DW Multimedia Card driver");
+MODULE_AUTHOR("Mellanox Technologies");
+MODULE_LICENSE("GPL v2");
--
1.8.3.1
[PATCH v2 2/3] Documentation: bluefield-dw-mshc: add DT description
This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
extension on Mellanox BlueField SoC platform.
Signed-off-by: Liming Sun
---
.../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
new file mode 100644
index 000..ee0dd61
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
@@ -0,0 +1,29 @@
+* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
+ Mobile Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
+specific extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+ - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
+specific extensions.
+
+Example:
+
+ /* Mellanox Bluefield SoC MMC */
+ dwmmc0@4,0 {
+ compatible = "mellanox,bluefield-dw-mshc";
+ reg = <4 0x8000 0x400>;
+ interrupts = <32>;
+ fifo-depth = <0x100>;
+ clock-frequency = <2400>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ };
--
1.8.3.1
[PATCH v2 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver
This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index ecf6137..43464ab 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_K3=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_DW_BLUEFIELD=y CONFIG_MMC_SUNXI=y CONFIG_MMC_BCM2835=y CONFIG_MMC_SDHCI_XENON=y -- 1.8.3.1
RE: [PATCH v5 1/3] mmc: dw_mmc-bluefield: Add driver extension
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Shawn Lin > Sent: Thursday, May 3, 2018 3:25 AM > To: Liming Sun ; Mark Rutland > ; Jaehoon Chung ; > Catalin Marinas ; Will Deacon > > Cc: shawn@rock-chips.com; Ulf Hansson ; Rob > Herring ; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v5 1/3] mmc: dw_mmc-bluefield: Add driver extension > > > On 2018/5/2 20:45, Liming Sun wrote: > > Please see response inline. > > > > Thanks, > > Liming > > > >> -Original Message- > >> From: Shawn Lin [mailto:shawn@rock-chips.com] > >> Sent: Tuesday, May 1, 2018 9:02 PM > >> To: Liming Sun ; Mark Rutland > >> ; Jaehoon Chung ; > >> Catalin Marinas ; Will Deacon > >> > >> Cc: Ulf Hansson ; Rob Herring > >> ; shawn@rock-chips.com; linux- > >> m...@vger.kernel.org; devicet...@vger.kernel.org; linux- > >> ker...@vger.kernel.org; sta...@kernel.org > >> Subject: Re: [PATCH v5 1/3] mmc: dw_mmc-bluefield: Add driver > extension > >> > >> On 2018/5/2 2:19, Liming Sun wrote: > >>> This commit adds extension to the dw_mmc driver for Mellanox > BlueField > >>> SoC. It updates the UHS_REG_EXT register to bring up the eMMC card > on > >>> this SoC. > >>> > >>> Cc: sta...@kernel.org > >> > >> Why? > > > > [Liming] This is recommended value from HW team. Without this setting, > the eMMC > > controller and cards can be found in Linux, but not stable. Writing to it > > could > caused > > CRC error. > > Well, I refered to the "Cc: sta...@kernel.org" in the commit msg. [Liming] Sorry, a typo. I meant "sta...@vger.kernel.org". Will update it in v6. Thanks! > > > > >> > >>> Signed-off-by: Liming Sun > >>> Reviewed-by: David Woods > >>> --- > >>>drivers/mmc/host/Kconfig| 9 + > >>>drivers/mmc/host/Makefile | 1 + > >>>drivers/mmc/host/dw_mmc-bluefield.c | 72 > >> + > >>>3 files changed, 82 insertions(+) > >>>create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c > >>> > >>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > >>> index 9589f9c..26ac6b5 100644 > >>> --- a/drivers/mmc/host/Kconfig > >>> +++ b/drivers/mmc/host/Kconfig > >>> @@ -717,6 +717,15 @@ config MMC_DW_K3 > >>> Synopsys DesignWare Memory Card Interface driver. Select this > >> option > >>> for platforms based on Hisilicon K3 SoC's. > >>> > >>> +config MMC_DW_BLUEFIELD > >> > >> And did you have feedback of my comment in V2？ > >> http://lists-archives.com/linux-kernel/29104830-mmc-dw_mmc- > bluefield- > >> add-driver-extension.html > >> > >>> + tristate "BlueField specific extensions for Synopsys DW Memory Card > >> Interface" > >>> + depends on MMC_DW > >>> + select MMC_DW_PLTFM > >>> + help > >>> + This selects support for Mellanox BlueField SoC specific extensions > >> to > >>> + the Synopsys DesignWare Memory Card Interface driver. Select this > >>> + option for platforms based on Mellanox BlueField SoC's. > >>> + > >>>config MMC_DW_PCI > >>> tristate "Synopsys Designware MCI support on PCI bus" > >>> depends on MMC_DW && PCI > >>> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile > >>> index 6aead24..267b3f1 100644 > >>> --- a/drivers/mmc/host/Makefile > >>> +++ b/drivers/mmc/host/Makefile > >>> @@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += > dw_mmc- > >> k3.o > >>>obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o > >>>obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o > >>>obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o > >>> +obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o > >>>obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o > >>>obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o > >>>obj-$(CONFIG_MMC_VUB300) += vub300.o > >>> diff --git a/drivers/mmc/host/dw_mmc-bluefield.c > >&
[PATCH v6 1/3] mmc: dw_mmc-bluefield: Add driver extension
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Signed-off-by: Liming Sun
Reviewed-by: David Woods
---
drivers/mmc/host/Kconfig| 9
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/dw_mmc-bluefield.c | 87 +
3 files changed, 97 insertions(+)
create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c..26ac6b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -717,6 +717,15 @@ config MMC_DW_K3
Synopsys DesignWare Memory Card Interface driver. Select this option
for platforms based on Hisilicon K3 SoC's.
+config MMC_DW_BLUEFIELD
+ tristate "BlueField specific extensions for Synopsys DW Memory Card
Interface"
+ depends on MMC_DW
+ select MMC_DW_PLTFM
+ help
+ This selects support for Mellanox BlueField SoC specific extensions to
+ the Synopsys DesignWare Memory Card Interface driver. Select this
+ option for platforms based on Mellanox BlueField SoC's.
+
config MMC_DW_PCI
tristate "Synopsys Designware MCI support on PCI bus"
depends on MMC_DW && PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 6aead24..267b3f1 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-k3.o
obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o
+obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
new file mode 100644
index 000..21db031
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Mellanox Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+#define UHS_REG_EXT_SAMPLE_WIDTH 7
+#define UHS_REG_EXT_SAMPLE_SHIFT 16
+#define UHS_REG_EXT_DRIVE_WIDTH7
+#define UHS_REG_EXT_DRIVE_SHIFT23
+
+#define BLUEFIELD_UHS_REG_EXT_SAMPLE 2
+#define BLUEFIELD_UHS_REG_EXT_DRIVE4
+
+#define SET_REG_FIELD(reg, value, width, shift) \
+ ((reg) = (((reg) & ~(((1 << (width)) - 1) << (shift))) | \
+ ((value) << (shift
+
+static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ u32 reg;
+
+ /* Update the Drive and Sample fields in register UHS_REG_EXT. */
+ reg = mci_readl(host, UHS_REG_EXT);
+ SET_REG_FIELD(reg, BLUEFIELD_UHS_REG_EXT_SAMPLE,
+ UHS_REG_EXT_SAMPLE_WIDTH, UHS_REG_EXT_SAMPLE_SHIFT);
+ SET_REG_FIELD(reg, BLUEFIELD_UHS_REG_EXT_DRIVE,
+ UHS_REG_EXT_DRIVE_WIDTH, UHS_REG_EXT_DRIVE_SHIFT);
+ mci_writel(host, UHS_REG_EXT, reg);
+}
+
+static const struct dw_mci_drv_data bluefield_drv_data = {
+ .set_ios= dw_mci_bluefield_set_ios
+};
+
+static const struct of_device_id dw_mci_bluefield_match[] = {
+ { .compatible = "mellanox,bluefield-dw-mshc",
+ .data = &bluefield_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_bluefield_match);
+
+static int dw_mci_bluefield_probe(struct platform_device *pdev)
+{
+ const struct dw_mci_drv_data *drv_data = NULL;
+ const struct of_device_id *match;
+
+ if (pdev->dev.of_node) {
+ match = of_match_node(dw_mci_bluefield_match,
+ pdev->dev.of_node);
+ drv_data = match->data;
+ }
+
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_bluefield_pltfm_driver = {
+ .probe = dw_mci_bluefield_probe,
+ .remove = dw_mci_pltfm_remove,
+ .driver = {
+ .name = "dwmmc_bluefield",
+ .of_match_table = dw_mci_bluefield_match,
+ .pm = &dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_bluefield_pltfm_driver);
+
+MODULE_DESCRIPTION("BlueField DW Multimedia Card driver");
+MODULE_AUTHOR("Mellanox Technologies");
+MODULE_LICENSE("GPL v2");
--
1.8.3.1
[PATCH v6 2/3] dt-bindings: mmc: Add binding for BlueField SoC
This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
extension on Mellanox BlueField SoC platform.
Signed-off-by: Liming Sun
Reviewed-by: David Woods
Reviewed-by: Rob Herring
---
.../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
new file mode 100644
index 000..b0f0999
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
@@ -0,0 +1,29 @@
+* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
+ Mobile Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
+specific extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+ - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
+specific extensions.
+
+Example:
+
+ /* Mellanox Bluefield SoC MMC */
+ mmc@6008000 {
+ compatible = "mellanox,bluefield-dw-mshc";
+ reg = <0x6008000 0x400>;
+ interrupts = <32>;
+ fifo-depth = <0x100>;
+ clock-frequency = <2400>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ };
--
1.8.3.1
[PATCH v6 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver
This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun Reviewed-by: David Woods --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index ecf6137..43464ab 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_K3=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_DW_BLUEFIELD=y CONFIG_MMC_SUNXI=y CONFIG_MMC_BCM2835=y CONFIG_MMC_SDHCI_XENON=y -- 1.8.3.1
RE: [PATCH v5 1/3] mmc: dw_mmc-bluefield: Add driver extension
Thanks. Updated in v6. Removed the "Cc: sta...@kernel.org" which is a typo.
Will do it later for stable branch. Also addressed the comment to use MACROs in
patch 1/3.
> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: Wednesday, May 2, 2018 4:17 AM
> To: Liming Sun ; Ulf Hansson
> ; Rob Herring ; Mark
> Rutland ; Catalin Marinas
> ; Will Deacon
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; sta...@kernel.org
> Subject: Re: [PATCH v5 1/3] mmc: dw_mmc-bluefield: Add driver extension
>
> Hi,
>
> On 05/02/2018 03:19 AM, Liming Sun wrote:
> > This commit adds extension to the dw_mmc driver for Mellanox BlueField
> > SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
> > this SoC.
>
> Could you heck Shawn's comments? And add the minor comment.
>
> >
> > Cc: sta...@kernel.org
> > Signed-off-by: Liming Sun
> > Reviewed-by: David Woods
> > ---
> > drivers/mmc/host/Kconfig| 9 +
> > drivers/mmc/host/Makefile | 1 +
> > drivers/mmc/host/dw_mmc-bluefield.c | 72
> +
> > 3 files changed, 82 insertions(+)
> > create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 9589f9c..26ac6b5 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -717,6 +717,15 @@ config MMC_DW_K3
> > Synopsys DesignWare Memory Card Interface driver. Select this
> option
> > for platforms based on Hisilicon K3 SoC's.
> >
> > +config MMC_DW_BLUEFIELD
> > + tristate "BlueField specific extensions for Synopsys DW Memory Card
> Interface"
> > + depends on MMC_DW
> > + select MMC_DW_PLTFM
> > + help
> > + This selects support for Mellanox BlueField SoC specific extensions
> to
> > + the Synopsys DesignWare Memory Card Interface driver. Select this
> > + option for platforms based on Mellanox BlueField SoC's.
> > +
> > config MMC_DW_PCI
> > tristate "Synopsys Designware MCI support on PCI bus"
> > depends on MMC_DW && PCI
> > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> > index 6aead24..267b3f1 100644
> > --- a/drivers/mmc/host/Makefile
> > +++ b/drivers/mmc/host/Makefile
> > @@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-
> k3.o
> > obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
> > obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
> > obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o
> > +obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
> > obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
> > obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
> > obj-$(CONFIG_MMC_VUB300) += vub300.o
> > diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
> b/drivers/mmc/host/dw_mmc-bluefield.c
> > new file mode 100644
> > index 000..12067b1
> > --- /dev/null
> > +++ b/drivers/mmc/host/dw_mmc-bluefield.c
> > @@ -0,0 +1,72 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 Mellanox Technologies.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "dw_mmc.h"
> > +#include "dw_mmc-pltfm.h"
> > +
> > +static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct
> mmc_ios *ios)
> > +{
> > + u32 regs;
> > +
> > + /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT.
> */
> > + regs = mci_readl(host, UHS_REG_EXT);
> > + regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
>
> I want to use the macro. Not (4 << 23)..
>
> > + mci_writel(host, UHS_REG_EXT, regs);
> > +}
> > +
> > +static const struct dw_mci_drv_data bluefield_drv_data = {
> > + .set_ios= dw_mci_bluefield_set_ios
> > +};
> > +
> > +static const struct of_device_id dw_mci_bluefield_match[] = {
> > + { .compatible = "mellanox,bluefield-dw-mshc",
> > +
[PATCH 1/2] mmc: dw_mmc-bluefield: Add driver extension
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Signed-off-by: Liming Sun
---
.../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 +
drivers/mmc/host/Kconfig | 9 +++
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/dw_mmc-bluefield.c| 72 ++
4 files changed, 111 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
new file mode 100644
index 000..ee0dd61
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
@@ -0,0 +1,29 @@
+* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
+ Mobile Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
+specific extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+ - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
+specific extensions.
+
+Example:
+
+ /* Mellanox Bluefield SoC MMC */
+ dwmmc0@4,0 {
+ compatible = "mellanox,bluefield-dw-mshc";
+ reg = <4 0x8000 0x400>;
+ interrupts = <32>;
+ fifo-depth = <0x100>;
+ clock-frequency = <2400>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c..26ac6b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -717,6 +717,15 @@ config MMC_DW_K3
Synopsys DesignWare Memory Card Interface driver. Select this option
for platforms based on Hisilicon K3 SoC's.
+config MMC_DW_BLUEFIELD
+ tristate "BlueField specific extensions for Synopsys DW Memory Card
Interface"
+ depends on MMC_DW
+ select MMC_DW_PLTFM
+ help
+ This selects support for Mellanox BlueField SoC specific extensions to
+ the Synopsys DesignWare Memory Card Interface driver. Select this
+ option for platforms based on Mellanox BlueField SoC's.
+
config MMC_DW_PCI
tristate "Synopsys Designware MCI support on PCI bus"
depends on MMC_DW && PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 6aead24..267b3f1 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-k3.o
obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
obj-$(CONFIG_MMC_DW_ZX)+= dw_mmc-zx.o
+obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
new file mode 100644
index 000..12067b1
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Mellanox Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ u32 regs;
+
+ /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT. */
+ regs = mci_readl(host, UHS_REG_EXT);
+ regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
+ mci_writel(host, UHS_REG_EXT, regs);
+}
+
+static const struct dw_mci_drv_data bluefield_drv_data = {
+ .set_ios= dw_mci_bluefield_set_ios
+};
+
+static const struct of_device_id dw_mci_bluefield_match[] = {
+ { .compatible = "mellanox,bluefield-dw-mshc",
+ .data = &bluefield_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_bluefield_match);
+
+static int dw_mci_bl
[PATCH 2/2] arm64: defconfig: Enable dw_mmc-bluefield driver
This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index ecf6137..43464ab 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_K3=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_DW_BLUEFIELD=y CONFIG_MMC_SUNXI=y CONFIG_MMC_BCM2835=y CONFIG_MMC_SDHCI_XENON=y -- 1.8.3.1
RE: [PATCH v2 1/3] mmc: dw_mmc-bluefield: Add driver extension
Sorry Shawn, somehow I missed this comment...
Will update it in v7 soon.
> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Monday, April 23, 2018 9:11 PM
> To: Liming Sun
> Cc: Ulf Hansson ; Rob Herring
> ; Mark Rutland ; Jaehoon
> Chung ; Catalin Marinas
> ; Will Deacon ;
> shawn@rock-chips.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] mmc: dw_mmc-bluefield: Add driver extension
>
> Hi Liming,
>
> On 2018/4/23 23:32, Liming Sun wrote:
> > This commit adds extension to the dw_mmc driver for Mellanox BlueField
> > SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
> > this SoC.
> >
> > Signed-off-by: Liming Sun
> > ---
> > drivers/mmc/host/Kconfig| 9 +
> > drivers/mmc/host/Makefile | 1 +
> > drivers/mmc/host/dw_mmc-bluefield.c | 72
> +
> > 3 files changed, 82 insertions(+)
> > create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 9589f9c..26ac6b5 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -717,6 +717,15 @@ config MMC_DW_K3
> > Synopsys DesignWare Memory Card Interface driver. Select this
> option
> > for platforms based on Hisilicon K3 SoC's.
> >
> > +config MMC_DW_BLUEFIELD
> > + tristate "BlueField specific extensions for Synopsys DW Memory Card
> Interface"
> > + depends on MMC_DW
> > + select MMC_DW_PLTFM
> > + help
> > + This selects support for Mellanox BlueField SoC specific extensions
> to
> > + the Synopsys DesignWare Memory Card Interface driver. Select this
> > + option for platforms based on Mellanox BlueField SoC's.
> > +
>
> It'd better to keep the order, so you could place it before
> MMC_DW_EXYNOS.
>
> > config MMC_DW_PCI
> > tristate "Synopsys Designware MCI support on PCI bus"
> > depends on MMC_DW && PCI
> > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> > index 6aead24..267b3f1 100644
> > --- a/drivers/mmc/host/Makefile
> > +++ b/drivers/mmc/host/Makefile
> > @@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-
> k3.o
> > obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
> > obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
> > obj-$(CONFIG_MMC_DW_ZX) += dw_mmc-zx.o
> > +obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
>
> Ditto.
>
> > obj-$(CONFIG_MMC_SH_MMCIF)+= sh_mmcif.o
> > obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
> > obj-$(CONFIG_MMC_VUB300) += vub300.o
> > diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
> b/drivers/mmc/host/dw_mmc-bluefield.c
> > new file mode 100644
> > index 000..12067b1
> > --- /dev/null
> > +++ b/drivers/mmc/host/dw_mmc-bluefield.c
> > @@ -0,0 +1,72 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 Mellanox Technologies.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
>
> Ditto.
>
> > +#include "dw_mmc.h"
> > +#include "dw_mmc-pltfm.h"
> > +
> > +static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct
> mmc_ios *ios)
> > +{
> > + u32 regs;
> > +
> > + /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT.
> */
> > + regs = mci_readl(host, UHS_REG_EXT);
> > + regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
>
> GENMASK woule be more readable IMHO.
>
> > + mci_writel(host, UHS_REG_EXT, regs);
> > +}
> > +
> > +static const struct dw_mci_drv_data bluefield_drv_data = {
> > + .set_ios= dw_mci_bluefield_set_ios
> > +};
> > +
> > +static const struct of_device_id dw_mci_bluefield_match[] = {
> > + { .compatible = "mellanox,bluefield-dw-mshc",
> > + .data = &bluefield_drv_data },
&g
[PATCH v7 1/3] mmc: dw_mmc-bluefield: Add driver extension
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Signed-off-by: Liming Sun
Reviewed-by: David Woods
---
drivers/mmc/host/Kconfig| 9 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/dw_mmc-bluefield.c | 81 +
3 files changed, 91 insertions(+)
create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c..7784f76 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -690,6 +690,15 @@ config MMC_DW_PLTFM
If unsure, say Y.
+config MMC_DW_BLUEFIELD
+ tristate "BlueField specific extensions for Synopsys DW Memory Card
Interface"
+ depends on MMC_DW
+ select MMC_DW_PLTFM
+ help
+ This selects support for Mellanox BlueField SoC specific extensions to
+ the Synopsys DesignWare Memory Card Interface driver. Select this
+ option for platforms based on Mellanox BlueField SoC's.
+
config MMC_DW_EXYNOS
tristate "Exynos specific extensions for Synopsys DW Memory Card
Interface"
depends on MMC_DW
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 6aead24..85dc132 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -49,6 +49,7 @@ thunderx-mmc-objs := cavium.o cavium-thunderx.o
obj-$(CONFIG_MMC_CAVIUM_THUNDERX) += thunderx-mmc.o
obj-$(CONFIG_MMC_DW) += dw_mmc.o
obj-$(CONFIG_MMC_DW_PLTFM) += dw_mmc-pltfm.o
+obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
obj-$(CONFIG_MMC_DW_EXYNOS)+= dw_mmc-exynos.o
obj-$(CONFIG_MMC_DW_HI3798CV200) += dw_mmc-hi3798cv200.o
obj-$(CONFIG_MMC_DW_K3)+= dw_mmc-k3.o
diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
b/drivers/mmc/host/dw_mmc-bluefield.c
new file mode 100644
index 000..54c3fbb
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-bluefield.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Mellanox Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+#define UHS_REG_EXT_SAMPLE_MASKGENMASK(22, 16)
+#define UHS_REG_EXT_DRIVE_MASK GENMASK(29, 23)
+#define BLUEFIELD_UHS_REG_EXT_SAMPLE 2
+#define BLUEFIELD_UHS_REG_EXT_DRIVE4
+
+static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ u32 reg;
+
+ /* Update the Drive and Sample fields in register UHS_REG_EXT. */
+ reg = mci_readl(host, UHS_REG_EXT);
+ reg &= ~UHS_REG_EXT_SAMPLE_MASK;
+ reg |= FIELD_PREP(UHS_REG_EXT_SAMPLE_MASK,
+ BLUEFIELD_UHS_REG_EXT_SAMPLE);
+ reg &= ~UHS_REG_EXT_DRIVE_MASK;
+ reg |= FIELD_PREP(UHS_REG_EXT_DRIVE_MASK, BLUEFIELD_UHS_REG_EXT_DRIVE);
+ mci_writel(host, UHS_REG_EXT, reg);
+}
+
+static const struct dw_mci_drv_data bluefield_drv_data = {
+ .set_ios= dw_mci_bluefield_set_ios
+};
+
+static const struct of_device_id dw_mci_bluefield_match[] = {
+ { .compatible = "mellanox,bluefield-dw-mshc",
+ .data = &bluefield_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_bluefield_match);
+
+static int dw_mci_bluefield_probe(struct platform_device *pdev)
+{
+ const struct dw_mci_drv_data *drv_data = NULL;
+ const struct of_device_id *match;
+
+ if (pdev->dev.of_node) {
+ match = of_match_node(dw_mci_bluefield_match,
+ pdev->dev.of_node);
+ drv_data = match->data;
+ }
+
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_bluefield_pltfm_driver = {
+ .probe = dw_mci_bluefield_probe,
+ .remove = dw_mci_pltfm_remove,
+ .driver = {
+ .name = "dwmmc_bluefield",
+ .of_match_table = dw_mci_bluefield_match,
+ .pm = &dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_bluefield_pltfm_driver);
+
+MODULE_DESCRIPTION("BlueField DW Multimedia Card driver");
+MODULE_AUTHOR("Mellanox Technologies");
+MODULE_LICENSE("GPL v2");
--
1.8.3.1
[PATCH v7 2/3] dt-bindings: mmc: Add binding for BlueField SoC
This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver
extension on Mellanox BlueField SoC platform.
Signed-off-by: Liming Sun
Reviewed-by: David Woods
Reviewed-by: Rob Herring
---
.../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
new file mode 100644
index 000..b0f0999
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
@@ -0,0 +1,29 @@
+* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
+ Mobile Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
+specific extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+ - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
+specific extensions.
+
+Example:
+
+ /* Mellanox Bluefield SoC MMC */
+ mmc@6008000 {
+ compatible = "mellanox,bluefield-dw-mshc";
+ reg = <0x6008000 0x400>;
+ interrupts = <32>;
+ fifo-depth = <0x100>;
+ clock-frequency = <2400>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ };
--
1.8.3.1
[PATCH v7 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver
This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun Reviewed-by: David Woods --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index ecf6137..43464ab 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -487,6 +487,7 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_K3=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_DW_BLUEFIELD=y CONFIG_MMC_SUNXI=y CONFIG_MMC_BCM2835=y CONFIG_MMC_SDHCI_XENON=y -- 1.8.3.1
RE: [PATCH v2 1/3] mmc: dw_mmc-bluefield: Add driver extension
Thanks Shawn. Patch v7 has been sent out to address these comments.
> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Monday, April 23, 2018 9:11 PM
> To: Liming Sun
> Cc: Ulf Hansson ; Rob Herring
> ; Mark Rutland ; Jaehoon
> Chung ; Catalin Marinas
> ; Will Deacon ;
> shawn@rock-chips.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] mmc: dw_mmc-bluefield: Add driver extension
>
> Hi Liming,
>
> On 2018/4/23 23:32, Liming Sun wrote:
> > This commit adds extension to the dw_mmc driver for Mellanox BlueField
> > SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
> > this SoC.
> >
> > Signed-off-by: Liming Sun
> > ---
> > drivers/mmc/host/Kconfig| 9 +
> > drivers/mmc/host/Makefile | 1 +
> > drivers/mmc/host/dw_mmc-bluefield.c | 72
> +
> > 3 files changed, 82 insertions(+)
> > create mode 100644 drivers/mmc/host/dw_mmc-bluefield.c
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 9589f9c..26ac6b5 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -717,6 +717,15 @@ config MMC_DW_K3
> > Synopsys DesignWare Memory Card Interface driver. Select this
> option
> > for platforms based on Hisilicon K3 SoC's.
> >
> > +config MMC_DW_BLUEFIELD
> > + tristate "BlueField specific extensions for Synopsys DW Memory Card
> Interface"
> > + depends on MMC_DW
> > + select MMC_DW_PLTFM
> > + help
> > + This selects support for Mellanox BlueField SoC specific extensions
> to
> > + the Synopsys DesignWare Memory Card Interface driver. Select this
> > + option for platforms based on Mellanox BlueField SoC's.
> > +
>
> It'd better to keep the order, so you could place it before
> MMC_DW_EXYNOS.
Updated in v7 1/3.
>
> > config MMC_DW_PCI
> > tristate "Synopsys Designware MCI support on PCI bus"
> > depends on MMC_DW && PCI
> > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> > index 6aead24..267b3f1 100644
> > --- a/drivers/mmc/host/Makefile
> > +++ b/drivers/mmc/host/Makefile
> > @@ -55,6 +55,7 @@ obj-$(CONFIG_MMC_DW_K3) += dw_mmc-
> k3.o
> > obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
> > obj-$(CONFIG_MMC_DW_ROCKCHIP) += dw_mmc-rockchip.o
> > obj-$(CONFIG_MMC_DW_ZX) += dw_mmc-zx.o
> > +obj-$(CONFIG_MMC_DW_BLUEFIELD) += dw_mmc-bluefield.o
>
> Ditto.
Updated in v7 1/3.
>
> > obj-$(CONFIG_MMC_SH_MMCIF)+= sh_mmcif.o
> > obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
> > obj-$(CONFIG_MMC_VUB300) += vub300.o
> > diff --git a/drivers/mmc/host/dw_mmc-bluefield.c
> b/drivers/mmc/host/dw_mmc-bluefield.c
> > new file mode 100644
> > index 000..12067b1
> > --- /dev/null
> > +++ b/drivers/mmc/host/dw_mmc-bluefield.c
> > @@ -0,0 +1,72 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 Mellanox Technologies.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
>
> Ditto.
Updated in v7 1/3.
>
> > +#include "dw_mmc.h"
> > +#include "dw_mmc-pltfm.h"
> > +
> > +static void dw_mci_bluefield_set_ios(struct dw_mci *host, struct
> mmc_ios *ios)
> > +{
> > + u32 regs;
> > +
> > + /* Set drive=4 (bit 29:23) and sample=2 (bit 22:16) in UHS_REG_EXT.
> */
> > + regs = mci_readl(host, UHS_REG_EXT);
> > + regs = (regs & ~0x3F10 & ~0x7F) | (4 << 23) | (2 << 16);
>
> GENMASK woule be more readable IMHO.
Updated in v7 1/3.
>
> > + mci_writel(host, UHS_REG_EXT, regs);
> > +}
> > +
> > +static const struct dw_mci_drv_data bluefield_drv_data = {
> > + .set_ios= dw_mci_bluefield_set_ios
> > +};
> > +
> > +static const struct of_device_id dw_mci_bluefield_match[] = {
> > + { .compatible = "mellanox,bluefield-dw-mshc",
> >
[PATCH v5 1/2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
This commit adds the bootctl platform driver for Mellanox BlueField
Soc, which controls the eMMC boot partition swapping and sends SMC
calls to ATF running at exception level EL3 to program some system
register. This register is persistent during warm reset and is only
accessible in secure code which is used to enable the watchdog after
reboot.
Below are the sequences of typical use case.
1. User-space tool upgrades one eMMC boot partition and requests
the boot partition swapping;
2. The bootctl driver handles this request and sends SMC call
to ATF. ATF programs register BREADCRUMB0 which has value
preserved during warm reset. It also programs eMMC to swap
the boot partition;
3. After software reset (rebooting), ATF BL1 (BootRom) checks
register BREADCRUMB0 to enable watchdog if configured;
4. If booting fails, the watchdog timer will trigger rebooting.
In such case, ATF Boot ROM will switch the boot partition
back to the previous one.
Reviewed-by: Vadim Pasternak
Signed-off-by: Liming Sun
---
v4->v5:
Fixes for comments from Andy:
- Added ABI documentation;
- Remove the extra 'const' in mlxbf_bootctl_svc_uuid_str definition;
- Remove the mlxbf_bootctl_smc_call0() MACRO to use function
call directly;
- Return more descriptive string ('invalid action') in
mlxbf_bootctl_reset_action_to_string();
- Check return value of the mlxbf_bootctl_smc() in function
post_reset_wdog_show() and reset_action_show();
- Revise the sprintf() line in reset_action_show() into one line;
- Move the 'action = ' assignment out of the declarations
in reset_action_store() and check return value of
mlxbf_bootctl_reset_action_to_val() in this function;
- Removed Redundant parens in reset_action_store();
- Check return code of the smc_call in second_reset_action_show(),
merge the 'name = ' assignment into the sprintf() directly;
- Move the 'action = ' assignment out of the declaration block
in second_reset_action_store();
- Remove redundant blank line and parents in lifecycle_state_show();
- Split declaration and assignment in secure_boot_fuse_state_show();
- use BIT() in secure_boot_fuse_state_show() and simplify code in
this function to split the logic of message choice and flag flip;
Also removed the 'key !=0 ' check since it's not needed;
- Added comma in mlxbf_bootctl_attr_group definition.
- Removed un-needed '& 0xFF' logic in mlxbf_bootctl_guid_match();
- Use temp variable for the result of the smc call in
mlxbf_bootctl_probe();
- Use dev_warn() instead of dev_err() in mlxbf_bootctl_probe();
- Removed the ACPI_PTR usage in the mlxbf_bootctl_driver definition;
Fixes for comments from Vadim:
- Move mlxbf-bootctl.o to the top of the Makefile;
- Fix to use the 'ret' value instead of another mlxbf_bootctl_smc() call;
- Fix the 'declaration inside the block' in secure_boot_fuse_state_show();
- Use ATTRIBUTE_GROUPS() for the attribute definition;
- Use single line for a comment in mlxbf-bootctl.h
- Use KernelVersion 5.3 instead of 5.2.2 in the ABI doc;
- Use common utility function for the show and store of reset_action
and second_reset_action.
New changes:
- Rename mlxbf_bootctl_smc_call1() to mlxbf_bootctl_smc() to
shorten the name so some statement could be make into one line;
- Fixed the MODULE_LICENSE();
- Added more comments in secure_boot_fuse_state_show();
v4: Update Kconfig for the dependency on ACPI.
Fixed a typo which caused build error for kernel module.
v2->v3:
Fixes for comments from Andy:
- More coding style fixes;
- Revised the uuid matching code.
v2: Fix the Kconfig and coding styles, propagate errors to caller.
v1: Initial version.
---
drivers/platform/mellanox/Kconfig | 12 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxbf-bootctl.c | 311 ++
drivers/platform/mellanox/mlxbf-bootctl.h | 103 ++
4 files changed, 427 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.c
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.h
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 530fe7e..386336d 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -44,4 +44,16 @@ config MLXBF_TMFIFO
platform driver support for the TmFifo which supports console
and networking based on the virtio framework.
+config MLXBF_BOOTCTL
+ tristate "Mellanox BlueField Firmware Boot Control driver"
+ depends on ARM64
+ depends on ACPI
+ help
+ The Mellanox BlueField firmware implements functionality to
+ request swapping the p
[PATCH v5 2/2] platform/mellanox/mlxbf-bootctl: Add the ABI definitions
This commit adds the ABI definitions exposed to userspace for the platform/mellanox/mlxbf-bootctl driver. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- .../ABI/testing/sysfs-platform-mellanox-bootctl| 58 ++ MAINTAINERS| 1 + 2 files changed, 59 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-mellanox-bootctl diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl new file mode 100644 index 000..19a14db --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl @@ -0,0 +1,58 @@ +What: /sys/bus/platform/drivers/mlxbf-bootctl/lifecycle_state +Date: May 2019 +KernelVersion: 5.3 +Contact: "Liming Sun " +Description: + The Life-cycle state of the SoC, which could be one of the + following values. + Production - Production state and can be updated to secure + GA Secured - Secure chip and not able to change state + GA Non-Secured - Non-Secure chip and not able to change state + RMA - Return Merchandise Authorization + +What: /sys/bus/platform/drivers/mlxbf-bootctl/post_reset_wdog +Date: May 2019 +KernelVersion: 5.3 +Contact: "Liming Sun " +Description: + The watchdog setting in seconds for the next booting. It's used + to reboot the chip and recover it to the old state if the new + boot partition fails. + +What: /sys/bus/platform/drivers/mlxbf-bootctl/reset_action +Date: May 2019 +KernelVersion: 5.3 +Contact: "Liming Sun " +Description: + The source of the boot stream for the next reset. It could be + one of the following values. + external - boot from external source (USB or PCIe) + emmc - boot from the onchip eMMC + emmc_legacy - boot from the onchip eMMC in legacy (slow) mode + +What: /sys/bus/platform/drivers/mlxbf-bootctl/second_reset_action +Date: May 2019 +KernelVersion: 5.3 +Contact: "Liming Sun " +Description: + Update the source of the boot stream after next reset. It could + be one of the following values and will be applied after next + reset. + external - boot from external source (USB or PCIe) + emmc - boot from the onchip eMMC + emmc_legacy - boot from the onchip eMMC in legacy (slow) mode + swap_emmc - swap the primary / secondary boot partition + none - cancel the action + +What: /sys/bus/platform/drivers/mlxbf-bootctl/secure_boot_fuse_state +Date: May 2019 +KernelVersion: 5.3 +Contact: "Liming Sun " +Description: + The state of eFuse versions with the following values. + InUse - burnt, valid and currently in use + Used - burnt and valid + Free - not burnt and free to use + Skipped - not burnt but not free (skipped) + Wasted - burnt and invalid + Invalid - not burnt but marked as valid (error state). diff --git a/MAINTAINERS b/MAINTAINERS index fb9f9d7..8a9d9ce 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10018,6 +10018,7 @@ M: Darren Hart M: Vadim Pasternak L: platform-driver-...@vger.kernel.org S: Supported +F: Documentation/ABI/testing/sysfs-platform-mellanox-bootctl F: drivers/platform/mellanox/ F: include/linux/platform_data/mlxreg.h -- 1.8.3.1
RE: [PATCH v4] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
Thanks Andy!
v5 has been posted to address all the comments. You could also see the detailed
response below.
Regards,
Liming
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Andy Shevchenko
> Sent: Tuesday, February 5, 2019 12:22 PM
> To: Liming Sun
> Cc: Andy Shevchenko ; Darren Hart ;
> Vadim Pasternak ; David
> Woods ; Platform Driver
> ; Linux Kernel Mailing List ker...@vger.kernel.org>
> Subject: Re: [PATCH v4] platform/mellanox: Add bootctl driver for Mellanox
> BlueField Soc
>
> On Fri, Feb 1, 2019 at 10:47 PM Liming Sun wrote:
>
> Thanks for an update, my comments below.
>
> (To Mellanox kernel developer team: guys, perhaps you need to
> establish a few rounds of internal review before sending the stuff
> outside)
Yes, we did internal review on v5 and updated the 'Reviewed-by'.
>
> First of all, I didn't find ABI documentation for interface this patch
> introduces.
> Must be added.
Added in v5.
>
> > +/* UUID used to probe ATF service. */
> > +static const char * const mlxbf_bootctl_svc_uuid_str =
> > + "89c036b4-e7d7-11e6-8797-001aca00bfc4";
>
> static const char *..._str = ...;
Updated in v5.
>
> > +/* Syntactic sugar to avoid having to specify an unused argument. */
> > +#define mlxbf_bootctl_smc_call0(smc_op) mlxbf_bootctl_smc_call1(smc_op, 0)
>
> No.
> Please, do it explicitly.
Updated in v5. Renamed mlxbf_bootctl_smc_call1() to mlxbf_bootctl_smc().
>
> > +static const char *mlxbf_bootctl_reset_action_to_string(int action)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(boot_names); i++)
> > + if (boot_names[i].value == action)
> > + return boot_names[i].name;
> > +
>
> > + return "";
>
> Hmm...
> Shouldn't be more descriptive?
Updated in v5 to return "invalid action" in such case.
>
> > +}
>
> > +static ssize_t post_reset_wdog_show(struct device_driver *drv, char *buf)
> > +{
> > + return sprintf(buf, "%d\n",
> > + mlxbf_bootctl_smc_call0(MLXBF_BOOTCTL_GET_POST_RESET_WDOG));
>
> What if call return negative error?
Fixed in v5 to check this return value.
>
> > +}
>
> > +static ssize_t reset_action_show(struct device_driver *drv, char *buf)
> > +{
> > + int action;
> > +
> > + action = mlxbf_bootctl_smc_call0(MLXBF_BOOTCTL_GET_RESET_ACTION);
>
> What if action goes negative?
Fixed in v5 to check this return value.
>
> > + return sprintf(buf, "%s\n",
> > + mlxbf_bootctl_reset_action_to_string(action));
>
> Wouldn't be one line?
Updated in v5 (one line).
>
> > +}
>
> > +static ssize_t reset_action_store(struct device_driver *drv,
> > + const char *buf, size_t count)
> > +{
>
> > + int ret, action = mlxbf_bootctl_reset_action_to_val(buf);
>
> This should be like
> int action;
> int ret;
>
> action = ...;
> if (action ...)
Updated in v5.
>
>
> > + if (action == MLXBF_BOOTCTL_INVALID || action == MLXBF_BOOTCTL_NONE)
> > + return -EINVAL;
>
> The mlxbf_bootctl_reset_action_to_val() has to return a proper Linux error
> code.
> After this code should be modified to something like
>
> if (action < 0)
> return action;
Updated in v5.
>
> > +
> > + ret = (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_RESET_ACTION,
> > action));
>
> Redundant parens.
Fixed in v5.
>
> > + if (ret < 0)
> > + return ret;
> > +
> > + return count;
> > +}
> > +
> > +static ssize_t second_reset_action_show(struct device_driver *drv, char
> > *buf)
> > +{
> > + int action;
> > + const char *name;
> > +
> > + action =
> > mlxbf_bootctl_smc_call0(MLXBF_BOOTCTL_GET_SECOND_RESET_ACTION);
>
> What if action is negative?
Updated in v5.
>
> > + name = mlxbf_bootctl_reset_action_to_string(action);
> > +
> > + return sprintf(buf, "%s\n", name);
>
> return sprintf(... _to_string(...));
> ?
Updated in v5 as suggested.
>
> > +}
> > +
> > +static ssize_t second_reset_action_store(struct device_driver *drv,
> > +const char *buf, size_t count)
> > +{
>
> > + int ret, action = mlxbf_bootctl_reset_action_to_val(buf);
>
> int action;
> int ret;
>
&g
RE: [PATCH v14] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy! I'll try to post v15 to address these comments this weekend.
(Please also see responses to each comments below).
> -Original Message-
> From: Andy Shevchenko
> Sent: Thursday, April 11, 2019 10:10 AM
> To: Liming Sun
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: Re: [PATCH v14] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> On Sun, Apr 7, 2019 at 5:03 AM Liming Sun wrote:
> >
> > This commit adds the TmFifo platform driver for Mellanox BlueField
> > Soc. TmFifo is a shared FIFO which enables external host machine
> > to exchange data with the SoC via USB or PCIe. The driver is based
> > on virtio framework and has console and network access enabled.
>
> Thanks for an update, my comments below.
Thanks for the comments!
>
> > +/**
> > + * mlxbf_tmfifo_vdev - Structure of the TmFifo virtual device
> > + * @vdev: virtio device, in which the vdev.id.device field has the
> > + *VIRTIO_ID_xxx id to distinguish the virtual device.
> > + * @status: status of the device
> > + * @features: supported features of the device
> > + * @vrings: array of tmfifo vrings of this device
> > + * @config.cons: virtual console config -
> > + * select if vdev.id.device is VIRTIO_ID_CONSOLE
> > + * @config.net: virtual network config -
> > + * select if vdev.id.device is VIRTIO_ID_NET
> > + * @tx_buf: tx buffer used to buffer data before writing into the FIFO
> > + */
> > +struct mlxbf_tmfifo_vdev {
> > + struct virtio_device vdev;
> > + u8 status;
> > + u64 features;
> > + struct mlxbf_tmfifo_vring vrings[MLXBF_TMFIFO_VRING_MAX];
> > + union {
> > + struct virtio_console_config cons;
> > + struct virtio_net_config net;
> > + } config;
> > + struct circ_buf tx_buf;
> > +};
>
> (1)
>
> > +/**
> > + * mlxbf_tmfifo_msg_hdr - Structure of the TmFifo message header
> > + * @type: message type
> > + * @len: payload length
> > + * @data: 64-bit data used to write the message header into the TmFifo
> > register.
> > + *
> > + * This message header is a union of struct and u64 data. The 'struct' has
> > + * type and length field which are used to encode & decode the message. The
> > + * 'data' field is used to read/write the message header from/to the FIFO.
> > + */
> > +union mlxbf_tmfifo_msg_hdr {
> > + struct {
> > + u8 type;
> > + __be16 len;
> > + u8 unused[5];
> > + } __packed;
> > + u64 data;
> > +};
>
> This union misses a type. See, for example, above structure (1) where
> union is used correctly.
This union seems causing confusion. I'll try to remove the union in v15
and "construct this on-the-fly" just like you mentioned in another email.
So instead of " writeq(hdr.data, ...)" we could simply do
"writeq(*(u64 *)&hdr, ...)", thus no need for a union.
>
> > +/* Allocate vrings for the FIFO. */
> > +static int mlxbf_tmfifo_alloc_vrings(struct mlxbf_tmfifo *fifo,
> > +struct mlxbf_tmfifo_vdev *tm_vdev)
> > +{
> > + struct mlxbf_tmfifo_vring *vring;
> > + struct device *dev;
> > + dma_addr_t dma;
> > + int i, size;
> > + void *va;
> > +
> > + for (i = 0; i < ARRAY_SIZE(tm_vdev->vrings); i++) {
> > + vring = &tm_vdev->vrings[i];
> > + vring->fifo = fifo;
> > + vring->num = MLXBF_TMFIFO_VRING_SIZE;
> > + vring->align = SMP_CACHE_BYTES;
> > + vring->index = i;
> > + vring->vdev_id = tm_vdev->vdev.id.device;
> > + dev = &tm_vdev->vdev.dev;
> > +
> > + size = vring_size(vring->num, vring->align);
> > + va = dma_alloc_coherent(dev->parent, size, &dma,
> > GFP_KERNEL);
> > + if (!va) {
>
> > + dev_err(dev->parent, "dma_alloc_coherent failed\n");
> > + mlxbf_tmfifo_free_vrings(fifo, tm_vdev);
>
> First do things, then report about what has been done.
Will update it in v15.
>
> > + return -ENOMEM;
> > + }
> > +
> > + vring->va = va;
>
RE: [PATCH v13] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Thanks Andy. Please see my response below for this email as well.
- Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Thursday, April 11, 2019 10:13 AM
> To: Liming Sun
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: Re: [PATCH v13] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> On Sun, Apr 7, 2019 at 5:05 AM Liming Sun wrote:
>
> > > > + * mlxbf_tmfifo_msg_hdr - Structure of the TmFifo message header
> > > > + * @type: message type
> > > > + * @len: payload length
> > > > + * @u: 64-bit union data
> > > > + */
> > > > +union mlxbf_tmfifo_msg_hdr {
> > > > + struct {
> > > > + u8 type;
> > > > + __be16 len;
> > > > + u8 unused[5];
> > > > + } __packed;
> > > > + u64 data;
> > >
> > > I'm not sure I understand how you can distinguish which field of union to
> > > use?
> > > Isn't here some type missed?
> >
> > Updated the comment in v14.
> >
> > This message header is a union of struct and u64 data.
> > The 'struct' has
> > type and length field which are used to encode & decode the message.
> > The 'data' field is used to read/write the message header from/to the FIFO.
>
> Something fishy here.
>
> You are using a structure of data which you would like to write with
> one call? Perhaps you need to construct this on-the-fly.
Looks like "union causes confusion".
I will update it in v15 to construct it on-the-fly as suggested.
> Moreover, the __be memeber is used in a data which is written as LE.
> This needs more explanation.
Will update the comment for it in v15. Below are some explanation for it.
The 'LE' is for the low-level mmio transport layer. The SoC sends data stream
into the FIFO, the other side read it. The byte-order of the data stream keeps
the same when the other side reads it. The "__be16" is for the driver or
application on both sides to agree on how to decode the 'length'.
For example, the SoC side (little endian) sends a message with
8-byte message header "01 02 03 04 05 06 07 08" into the FIFO. The other
side (assuming big endian host machine using USB bulk transfer) reads the
same byte-stream and try to decode it with the mlxbf_tmfifo_msg_hdr.
Without the "__be16" conversion, the SoC side will think
"type=1, length=0x0302" while the big endian host-side will think
"type=1, length=0x0203".
>
> --
> With Best Regards,
> Andy Shevchenko
[PATCH v15] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v14->v15: Fixes for comments from Andy: - Remove the 'union' definition of mlxbf_tmfifo_msg_hdr and use on-the-fly conversion when sending the 8-byte message header into the FIFO; - Update comment of mlxbf_tmfifo_msg_hdr explaining why '__be16' is needed for the 'len' field. The SoC sends data stream into the FIFO and the other side reads it. The byte order of the data stream (byte-stream) stays the same. The 'len' field is encoded into network byte order so external host machine with different endianness could decode it. The implementation has been verified over USB with an external PPC host machine running in big-endian mode. - Move the 'dev_err()' line to the end of the block in function mlxbf_tmfifo_alloc_vrings(); - Remove the 'irq_info->index < MLXBF_TM_MAX_IRQ' check in mlxbf_tmfifo_irq_handler() since it's unnecessary; - Remove the 'if (desc_head)' check in mlxbf_tmfifo_release_pending_pkt() since function mlxbf_tmfifo_get_pkt_len() is already NULL-aware; - Adjust the testing order of 'if (!(vring->index & BIT(0)))' in bool mlxbf_tmfifo_virtio_notify() to test the positive case 'if (vring->index & BIT(0))' first; - Add '(u64)offset' conversion in mlxbf_tmfifo_virtio_get() to avoid 32-bit length addition overflow; - Update the 'efi.get_variable' statement into single line in mlxbf_tmfifo_get_cfg_mac(); - Use new helper devm_platform_ioremap_resource() to replace 'platform_get_resource() + devm_ioremap_resource()' in mlxbf_tmfifo_probe(); v13->v14: Fixes for comments from Andy: - Add a blank line to separate the virtio header files; - Update the comment for 'union mlxbf_tmfifo_msg_hdr' to be more clear how this union is used; - Update the 'mlxbf_tmfifo_net_default_mac[ETH_ALEN]' definition to be two lines; - Reformat macro MLXBF_TMFIFO_NET_FEATURES to put the definition in a seperate line; - Update all 'fifo' to 'FIFO' in the comments; - Update mlxbf_tmfifo_alloc_vrings() to specifically release the allocated entries in case of failures, so the logic looks more clear. In the caller function the mlxbf_tmfifo_free_vrings() might be called again in case of other failures, which is ok since the 'va' pointer will be set to NULL once released; - Update mlxbf_tmfifo_timer() to change the first statement to one line; - Update one memcpy() to ether_addr_copy() in mlxbf_tmfifo_get_cfg_mac(); - Remove 'fifo->pdev' since it is really not needed; - Define temporary variable to update the mlxbf_tmfifo_create_vdev() statement into single line. New changes by Liming: - Reorder the logic a little bit in mlxbf_tmfifo_timer(). Previously it has logic like "!a || !b" while the '!b' will not be evaluated if '!a' is true. It was changed to this way during review, but is actually not the desired behavior since both bits need to be tested/set in fifo->pend_events. This issue was found during verification which caused extra delays for Tx packets. v12->v13: Rebase and resubmit (no new changes). v11->v12: Fixed the two unsolved comments from v11. - "Change macro mlxbf_vdev_to_tmfifo() to one line" Done. Seems not hard. - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" Yes, understand the comment now. The tmfifo is fixed, but the vdev is dynamic. Use kzalloc() instead, and free the device in the release callback which is the right place for it. v10->v11: Fixes for comments from Andy: - Use GENMASK_ULL() instead of GENMASK() in mlxbf-tmfifo-regs.h - Removed the cpu_to_le64()/le64_to_cpu() conversion since readq()/writeq() already takes care of it. - Remove the "if (irq)" check in mlxbf_tmfifo_disable_irqs(). - Add "u32 count" temp variable in mlxbf_tmfifo_get_tx_avail(). - Clean up mlxbf_tmfifo_get_cfg_mac(), use ETH_ALEN instead of value 6. - Change the tx_buf to use Linux existing 'struct circ_buf'. Comment not applied: - "Change macro mlxbf_vdev_to_tmfifo() to one line" Couldn't fit in one line with 80 chracters - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzal
RE: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
Thanks Andy for the comments! Please also see my response inline.
I do have a question about the "return value shadow an error" comment. Could
you help take a look if I understand it correctly?
Regards,
Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Tuesday, January 29, 2019 5:03 PM
> To: Liming Sun
> Cc: Andy Shevchenko ; Darren Hart ;
> Vadim Pasternak ; David
> Woods ; Platform Driver
> ; Linux Kernel Mailing List ker...@vger.kernel.org>
> Subject: Re: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for
> Mellanox BlueField Soc
>
> On Tue, Jan 29, 2019 at 10:59 PM Liming Sun wrote:
> >
> > This commit adds the bootctl platform driver for Mellanox BlueField
> > Soc, which controls the eMMC boot partition swapping and related
> > watchdog configuration.
>
> Thanks for the patch.
>
> My comments below.
>
> First of all, is it a real watchdog with a driver? I think watchdog in
> that case should be set up through standard watchdog facilities.
This is not a watchdog driver itself. Instead, it provides interface to
user-space and use ARM SMC calls to ATF to configure registers and
watchdog. I'll update the commit message in v2 to clarify it.
>
> > Reviewed-by: David Woods
>
> As for Mellanox team I would recommend to take this review as few
> basics of kernel programming style and some standard practices.
Thanks!
>
> > Signed-off-by: Liming Sun
>
> > +config MLXBF_BOOTCTL
> > + tristate "Mellanox BlueField Firmware Boot Control driver"
> > + depends on ARM64
>
> > + default m
>
> Why? What would happen if user chooses n?
Will remove the " default m" in v2.
>
> > + help
> > + The Mellanox BlueField firmware implements functionality to
> > + request swapping the primary and alternate eMMC boot
> > + partition, and to set up a watchdog that can undo that swap
> > + if the system does not boot up correctly. This driver
> > + provides sysfs access to the firmware, to be used in
> > + conjunction with the eMMC device driver to do any necessary
> > + initial swap of the boot partition.
>
> > +struct mlxbf_bootctl_name {
> > + int value;
> > + const char name[12];
>
> Can't we do simple
>
> const char *name;
>
> ?
>
> Why do we need the limitation. Why is it hard coded like this?
I don't see any reason to hardcode it. Will update it in v2 as suggested.
>
> > +};
> > +
> > +static struct mlxbf_bootctl_name boot_names[] = {
> > + { MLXBF_BOOTCTL_EXTERNAL, "external" },
> > + { MLXBF_BOOTCTL_EMMC, "emmc" },
> > + { MLNX_BOOTCTL_SWAP_EMMC, "swap_emmc" },
> > + { MLXBF_BOOTCTL_EMMC_LEGACY,"emmc_legacy" },
> > + { MLXBF_BOOTCTL_NONE, "none" },
>
> > + { -1, "" }
>
> -1 is usually a bad idea for terminator. It's not in align with many
> other structures which require terminator.
Will update in v2 to remove the terminator and use ARRAY_SIZE()
to loop it instead.
>
> > +};
>
> > +
> > +static char mlxbf_bootctl_lifecycle_states[][16] = {
>
> static const char * const ... ?
Will update it in v2.
>
> > + [0] = "soft_non_secure",
> > + [1] = "secure",
> > + [2] = "hard_non_secure",
> > + [3] = "rma",
> > +};
>
> > +/* Syntactic sugar to avoid having to specify an unused argument. */
> > +#define mlxbf_bootctl_smc_call0(smc_op) mlxbf_bootctl_smc_call1(smc_op, 0)
> > +
> > +static int reset_action_to_val(const char *action, size_t len)
> > +{
> > + struct mlxbf_bootctl_name *bn;
> > +
>
> > + /* Accept string either with or without a newline terminator */
> > + if (action[len-1] == '\n')
> > + --len;
>
> For a long time we have sysfs_streq() API.
Thanks, will update it in v2.
>
> > +
> > + for (bn = boot_names; bn->value >= 0; ++bn)
> > + if (strncmp(bn->name, action, len) == 0)
> > + break;
> > +
> > + return bn->value;
> > +}
>
> > +static ssize_t post_reset_wdog_store(struct device_driver *drv,
> > +const char *buf, size_t count)
> > +{
> > + int err;
> > +
RE: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
Thanks Vadim. Please see my response and questions below.
Regards,
Liming
> -Original Message-
> From: Vadim Pasternak
> Sent: Wednesday, January 30, 2019 1:24 AM
> To: Andy Shevchenko ; Liming Sun
>
> Cc: Andy Shevchenko ; Darren Hart ;
> David Woods ; Platform
> Driver ; Linux Kernel Mailing List
>
> Subject: RE: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for
> Mellanox BlueField Soc
>
>
> [...]
>
> Please, be consistent with naming convention.
> All the above should have same prefix as others routines.
I fixed reset_action_to_val() and reset_action_to_string() and will update
them in v2.
Other static functions like xxx_show() and xxx_store() are actually defined
by kernel macro DRIVER_ATTR_RW(name) and DRIVER_ATTR_RO(name),
where the 'name' are attribute names which will be displayed in sysfs.
In order to use "mlx_bf_" prefix for the functions, the same prefix will need
to be added to the attribute name as well, which seems unusual in sysfs.
So probably I could leave those xxx_show() and xxx_store() attribute functions
as it is?
>
> >
> > > +static ssize_t post_reset_wdog_store(struct device_driver *drv,
> > > +const char *buf, size_t count) {
> > > + int err;
> > > + unsigned long watchdog;
> > > +
> > > + err = kstrtoul(buf, 10, &watchdog);
> > > + if (err)
> > > + return err;
> > > +
> >
> > > + if (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_POST_RESET_WDOG,
> > > + watchdog) < 0)
> > > + return -EINVAL;
> >
> > If that call returns an error it shouldn't be shadowed here.
> >
> > > +
> > > + return count;
> > > +}
> > > +
> > > +static ssize_t reset_action_show(struct device_driver *drv, char
> > > +*buf) {
> >
> > > + return sprintf(buf, "%s\n", reset_action_to_string(
> > > +
> > > + mlxbf_bootctl_smc_call0(MLXBF_BOOTCTL_GET_RESET_ACTION)));
> >
> > Wouldn't be easy to parse this as
> >
> > int action = ...call0();
> > return sprintf(...);
> >
> > ?
> >
> > (int is an arbitrary type here, choose one that suits)
> >
> > > +}
> > > +
> > > +static ssize_t reset_action_store(struct device_driver *drv,
> > > + const char *buf, size_t count) {
> > > + int action = reset_action_to_val(buf, count);
> > > +
> >
> > > + if (action < 0 || action == MLXBF_BOOTCTL_NONE)
> > > + return -EINVAL;
> >
> > Don't shadow an error.
> >
> > > +
> > > + if (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_RESET_ACTION,
> > action) < 0)
> > > + return -EINVAL;
> >
> > Same.
> >
> > > +
> > > + return count;
> > > +}
> > > +
> > > +static ssize_t second_reset_action_show(struct device_driver *drv,
> > > +char *buf) {
> >
> > > + return sprintf(buf, "%s\n", reset_action_to_string(
> > > + mlxbf_bootctl_smc_call0(
> > > + MLXBF_BOOTCTL_GET_SECOND_RESET_ACTION)));
> >
> > Use temp variable.
> >
> > > +}
> > > +
> > > +static ssize_t second_reset_action_store(struct device_driver *drv,
> > > +const char *buf, size_t
> > > +count) {
> > > + int action = reset_action_to_val(buf, count);
> > > +
> > > + if (action < 0)
> > > + return -EINVAL;
> >
> > Don't shadow an error.
> >
> > > +
> > > + if
> > (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_SECOND_RESET_ACTION,
> > > + action) < 0)
> > > + return -EINVAL;
> >
> > Same.
> >
> > > +
> > > + return count;
> > > +}
> > > +
> > > +static ssize_t lifecycle_state_show(struct device_driver *drv, char
> > > +*buf) {
> >
> > > + int lc_state = mlxbf_bootctl_smc_call1(
> > > + MLXBF_BOOTCTL_GET_TBB_FUSE_STATUS,
> > > + MLXBF_BOOTCTL_FUSE_STATUS_LIFECYCLE);
> >
> > Split it as
> >
> > int ...;
> >
> > ... = call1();
> > if (...)
> >
> > > +
> > >
[PATCH v2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
This commit adds the bootctl platform driver for Mellanox BlueField
Soc, which controls the eMMC boot partition swapping and sends SMC
calls to ATF running at exception level EL3 to program some system
register. This register is only accessible in secure code and is
used to enable the watchdog after reboot.
Below are the sequences of a typical use case.
1. User-space tool upgrades one eMMC boot partition and requests
the boot partition swapping;
2. The bootctl driver handles such request and sends SMC call
to ATF. ATF programs register BREADCRUMB0 which has value
preserved during software reset. It also programs eMMC to
swap the boot partition;
3. After software reset (rebooting), ATF BL1 (BootRom) checks
register BREADCRUMB0 to enable watchdog if configured;
4. If booting fails, the watchdog timer will trigger rebooting.
In such case, ATF BootRom will switch the boot partition
to the previous one.
Reviewed-by: David Woods
Signed-off-by: Liming Sun
---
drivers/platform/mellanox/Kconfig | 14 +-
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxbf-bootctl.c | 306 ++
drivers/platform/mellanox/mlxbf-bootctl.h | 108 +++
4 files changed, 428 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.c
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.h
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index cd8a908..e3c6a5e 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -5,7 +5,7 @@
menuconfig MELLANOX_PLATFORM
bool "Platform support for Mellanox hardware"
- depends on X86 || ARM || COMPILE_TEST
+ depends on X86 || ARM || ARM64 || COMPILE_TEST
---help---
Say Y here to get to see options for platform support for
Mellanox systems. This option alone does not add any kernel code.
@@ -34,4 +34,16 @@ config MLXREG_IO
to system resets operation, system reset causes monitoring and some
kinds of mux selection.
+config MLXBF_BOOTCTL
+ tristate "Mellanox BlueField Firmware Boot Control driver"
+ depends on ARM64
+ help
+ The Mellanox BlueField firmware implements functionality to
+ request swapping the primary and alternate eMMC boot
+ partition, and to set up a watchdog that can undo that swap
+ if the system does not boot up correctly. This driver
+ provides sysfs access to the firmware, to be used in
+ conjunction with the eMMC device driver to do any necessary
+ initial swap of the boot partition.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 57074d9c..76b0370 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -5,3 +5,4 @@
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
+obj-$(CONFIG_MLXBF_BOOTCTL)+= mlxbf-bootctl.o
diff --git a/drivers/platform/mellanox/mlxbf-bootctl.c
b/drivers/platform/mellanox/mlxbf-bootctl.c
new file mode 100644
index 000..7efa535
--- /dev/null
+++ b/drivers/platform/mellanox/mlxbf-bootctl.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox boot control driver
+ * This driver provides a sysfs interface for systems management
+ * software to manage reset-time actions.
+ *
+ * Copyright (C) 2019 Mellanox Technologies
+ */
+
+#include
+#include
+#include
+#include
+#include "mlxbf-bootctl.h"
+
+#define MLXBF_BOOTCTL_DRIVER_NAME "mlxbf-bootctl"
+#define MLXBF_BOOTCTL_DRIVER_DESCRIPTION "Mellanox boot control driver"
+
+#define MLXBF_BOOTCTL_SB_SECURE_MASK 0x03
+#define MLXBF_BOOTCTL_SB_TEST_MASK 0x0c
+
+#define MLXBF_SB_KEY_NUM 4
+
+/* UUID used to probe ATF service. */
+static const char * const mlxbf_bootctl_svc_uuid_str =
+ "89c036b4-e7d7-11e6-8797-001aca00bfc4";
+
+/*
+ * UUID structure used to match the returned value from ATF in
+ * four 32-bit words. No need to do endian conversion here.
+ */
+union mlxbf_bootctl_uuid {
+ guid_t guid;
+ u32 words[4];
+};
+
+struct mlxbf_bootctl_name {
+ u32 value;
+ const char *name;
+};
+
+static struct mlxbf_bootctl_name boot_names[] = {
+ { MLXBF_BOOTCTL_EXTERNAL, "external" },
+ { MLXBF_BOOTCTL_EMMC, "emmc" },
+ { MLNX_BOOTCTL_SWAP_EMMC, "swap_emmc" },
+ { MLXBF_BOOTCTL_EMMC_LEGACY,"emmc_legacy" },
+ { MLXBF_BOOTCTL_NONE, "none" },
+};
+
+static const char * const mlxbf_bootctl_lifecycle_states[] = {
+ [0] = "soft_non_secure",
+ [1] = "secure&quo
RE: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
Thanks! v2 has been posted trying to solve all the comments. Please also see response inline. Regards, Liming > -Original Message- > From: Andy Shevchenko > Sent: Wednesday, January 30, 2019 4:17 PM > To: Liming Sun > Cc: Andy Shevchenko ; Darren Hart ; > Vadim Pasternak ; David > Woods ; Platform Driver > ; Linux Kernel Mailing List ker...@vger.kernel.org> > Subject: Re: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for > Mellanox BlueField Soc > > On Wed, Jan 30, 2019 at 10:47 PM Liming Sun wrote: > > > > First of all, is it a real watchdog with a driver? I think watchdog in > > > that case should be set up through standard watchdog facilities. > > > > This is not a watchdog driver itself. Instead, it provides interface to > > user-space and use ARM SMC calls to ATF to configure registers and > > watchdog. I'll update the commit message in v2 to clarify it. > > Hmm... For example Intel MID platforms have SCU (system controller > unit) that provides a watchdog facility. In the kernel we have a > watchdog driver for that. > Can't you do similar for your case? The process might be different than what's done on the BlueField SoC. After the boot-partition swapping, the ARM watchdog is not started right away. It is started during next rebooting by the ATF BL1 code (which is the Boot ROM code than couldn't change). The Boot-ROM checks some register value which is preserved during rebooting, and knows that a boot-partition swapping is in process, thus enable the watchdog timer if configured. At this time, no UEFI or Linux is running, just the boot ROM code at the very beginning. I'll add the sequence of such use case in the commit message of v2. > > > > > + if (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_POST_RESET_WDOG, > > > > + watchdog) < 0) > > > > + return -EINVAL; > > > > > > If that call returns an error it shouldn't be shadowed here. > > > > Not sure I understand this comment correctly or not. > > This function is defined by DRIVER_ATTR_RW(), which appears to expect > > ssize_t or an error code as return value according to other examples I saw. > > What is returned by mlx...call1() should be propagated to the actual caller. > Same comment for all similar cases. Make sense! Thanks for the explanation. Updated it in v2. > > > > > + lc_state &= (MLXBF_BOOTCTL_SB_MODE_TEST_MASK | > > > > +MLXBF_BOOTCTL_SB_MODE_SECURE_MASK); > > > > > > Better to split like > > > > > > xxx = > > > (A | B); > > > > It seems hard to do "(A | B);" within 80 characters plus the indents. > > Repeating myself, it's still better than your variant for readability. Done. Managed to shorten the variable name a little bit. Updated it in v2. > > > > > + if (res.a0 != 0x89c036b4 || res.a1 != 0x11e6e7d7 || > > > > + res.a2 != 0x1a009787 || res.a3 != 0xc4bf00ca) > > > > > > What is this?! > > > > > > Can you use UUID API? > > > > Yes, it is UUID comparison. The SMC call returns four 'unsigned long' from > > ATF > > to represent the UUID. There seems no existing APIs in uapi/linux/uuid.h to > > compare such special format. How about replacing it with comment and MACROs > > instead of the hardcoded values to make it more readable? > > Should be no magic numbers involved inside the function at the end. > Use descriptive definitions and I still recommend to give a look at > UUID API how it can be utilized here. > (hint: Thunderbolt hw is operating with integers, though driver uses > UUID API at the end) > Updated in v2. Now it should look better :) > -- > With Best Regards, > Andy Shevchenko
RE: [PATCH v2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
Please see my response inline. Will provide v3 once I solve the comments.
Thanks,
Liming
> -Original Message-
> From: Andy Shevchenko
> Sent: Thursday, January 31, 2019 12:02 PM
> To: Liming Sun
> Cc: Andy Shevchenko ; Darren Hart ;
> Vadim Pasternak ; David
> Woods ; Platform Driver
> ; Linux Kernel Mailing List ker...@vger.kernel.org>
> Subject: Re: [PATCH v2] platform/mellanox: Add bootctl driver for Mellanox
> BlueField Soc
>
> On Thu, Jan 31, 2019 at 6:53 PM Liming Sun wrote:
> >
> > This commit adds the bootctl platform driver for Mellanox BlueField
> > Soc, which controls the eMMC boot partition swapping and sends SMC
> > calls to ATF running at exception level EL3 to program some system
> > register. This register is only accessible in secure code and is
> > used to enable the watchdog after reboot.
> >
> > Below are the sequences of a typical use case.
> >
> > 1. User-space tool upgrades one eMMC boot partition and requests
> > the boot partition swapping;
> >
> > 2. The bootctl driver handles such request and sends SMC call
> > to ATF. ATF programs register BREADCRUMB0 which has value
> > preserved during software reset. It also programs eMMC to
> > swap the boot partition;
> >
> > 3. After software reset (rebooting), ATF BL1 (BootRom) checks
> > register BREADCRUMB0 to enable watchdog if configured;
> >
> > 4. If booting fails, the watchdog timer will trigger rebooting.
> > In such case, ATF BootRom will switch the boot partition
> > to the previous one.
>
> Thanks for an update. My comments below.
>
>
> > Reviewed-by: David Woods
>
> I'm not sure I see this guy to review v2. Of course if you consider
> all changes minor, you may leave this tag.
He sits besides me for internal review. I'll try to ask him to send
comments to the mailing list.
>
> > Signed-off-by: Liming Sun
> > ---
>
> Here should be a changelog what had been done in new version.
Will provide changelog in the v3 email.
Or please correct me if you meant adding changelog in the code or
cover letter.
> > +/* UUID used to probe ATF service. */
>
> > +static const char * const mlxbf_bootctl_svc_uuid_str =
> > + "89c036b4-e7d7-11e6-8797-001aca00bfc4";
>
> static const char *xxx = ...;
Will update it in v3.
>
> > +/*
> > + * UUID structure used to match the returned value from ATF in
> > + * four 32-bit words. No need to do endian conversion here.
> > + */
> > +union mlxbf_bootctl_uuid {
> > + guid_t guid;
> > + u32 words[4];
> > +};
>
> I'm not sure it's the best you can do. instead of using union, better
> to use conversion from and to corresponding uuid type.
I'll try to figure out another way without the union to compare the
uuid directly using uuid api. Will update it in v3.
>
> The rest I will comment on v3.
>
> --
> With Best Regards,
> Andy Shevchenko
RE: [PATCH v2] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
v3 has been posted with Changelog added.
Thanks!
Liming
> -Original Message-
> From: Liming Sun
> Sent: Thursday, January 31, 2019 12:18 PM
> To: 'Andy Shevchenko'
> Cc: Andy Shevchenko ; Darren Hart ;
> Vadim Pasternak ; David
> Woods ; Platform Driver
> ; Linux Kernel Mailing List ker...@vger.kernel.org>
> Subject: RE: [PATCH v2] platform/mellanox: Add bootctl driver for Mellanox
> BlueField Soc
>
> Please see my response inline. Will provide v3 once I solve the comments.
>
> Thanks,
> Liming
>
> > -Original Message-
> > From: Andy Shevchenko
> > Sent: Thursday, January 31, 2019 12:02 PM
> > To: Liming Sun
> > Cc: Andy Shevchenko ; Darren Hart
> > ; Vadim Pasternak ;
> David
> > Woods ; Platform Driver
> > ; Linux Kernel Mailing List > ker...@vger.kernel.org>
> > Subject: Re: [PATCH v2] platform/mellanox: Add bootctl driver for Mellanox
> > BlueField Soc
> >
> > On Thu, Jan 31, 2019 at 6:53 PM Liming Sun wrote:
> > >
> > > This commit adds the bootctl platform driver for Mellanox BlueField
> > > Soc, which controls the eMMC boot partition swapping and sends SMC
> > > calls to ATF running at exception level EL3 to program some system
> > > register. This register is only accessible in secure code and is
> > > used to enable the watchdog after reboot.
> > >
> > > Below are the sequences of a typical use case.
> > >
> > > 1. User-space tool upgrades one eMMC boot partition and requests
> > > the boot partition swapping;
> > >
> > > 2. The bootctl driver handles such request and sends SMC call
> > > to ATF. ATF programs register BREADCRUMB0 which has value
> > > preserved during software reset. It also programs eMMC to
> > > swap the boot partition;
> > >
> > > 3. After software reset (rebooting), ATF BL1 (BootRom) checks
> > > register BREADCRUMB0 to enable watchdog if configured;
> > >
> > > 4. If booting fails, the watchdog timer will trigger rebooting.
> > > In such case, ATF BootRom will switch the boot partition
> > > to the previous one.
> >
> > Thanks for an update. My comments below.
> >
> >
> > > Reviewed-by: David Woods
> >
> > I'm not sure I see this guy to review v2. Of course if you consider
> > all changes minor, you may leave this tag.
>
> He sits besides me for internal review. I'll try to ask him to send
> comments to the mailing list.
>
> >
> > > Signed-off-by: Liming Sun
> > > ---
> >
> > Here should be a changelog what had been done in new version.
>
> Will provide changelog in the v3 email.
> Or please correct me if you meant adding changelog in the code or
> cover letter.
>
> > > +/* UUID used to probe ATF service. */
> >
> > > +static const char * const mlxbf_bootctl_svc_uuid_str =
> > > + "89c036b4-e7d7-11e6-8797-001aca00bfc4";
> >
> > static const char *xxx = ...;
>
> Will update it in v3.
>
> >
> > > +/*
> > > + * UUID structure used to match the returned value from ATF in
> > > + * four 32-bit words. No need to do endian conversion here.
> > > + */
> > > +union mlxbf_bootctl_uuid {
> > > + guid_t guid;
> > > + u32 words[4];
> > > +};
> >
> > I'm not sure it's the best you can do. instead of using union, better
> > to use conversion from and to corresponding uuid type.
>
> I'll try to figure out another way without the union to compare the
> uuid directly using uuid api. Will update it in v3.
>
> >
> > The rest I will comment on v3.
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
[PATCH v3] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
This commit adds the bootctl platform driver for Mellanox BlueField
Soc, which controls the eMMC boot partition swapping and sends SMC
calls to ATF running at exception level EL3 to program some system
register. This register is only accessible in secure code and is
used to enable the watchdog after reboot.
Below are the sequences of a typical use case.
1. User-space tool upgrades one eMMC boot partition and requests
the boot partition swapping;
2. The bootctl driver handles such request and sends SMC call
to ATF. ATF programs register BREADCRUMB0 which has value
preserved during software reset. It also programs eMMC to
swap the boot partition;
3. After software reset (rebooting), ATF BL1 (BootRom) checks
register BREADCRUMB0 to enable watchdog if configured;
4. If booting fails, the watchdog timer will trigger rebooting.
In such case, ATF BootRom will switch the boot partition
to the previous one.
Signed-off-by: Liming Sun
---
v3: More coding style fixes, revised the uuid matching code.
v2: Fix the Kconfig and coding styles, propagate errors to caller.
v1: Initial version.
---
drivers/platform/mellanox/Kconfig | 14 +-
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxbf-bootctl.c | 310 ++
drivers/platform/mellanox/mlxbf-bootctl.h | 108 +++
4 files changed, 432 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.c
create mode 100644 drivers/platform/mellanox/mlxbf-bootctl.h
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index cd8a908..e3c6a5e 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -5,7 +5,7 @@
menuconfig MELLANOX_PLATFORM
bool "Platform support for Mellanox hardware"
- depends on X86 || ARM || COMPILE_TEST
+ depends on X86 || ARM || ARM64 || COMPILE_TEST
---help---
Say Y here to get to see options for platform support for
Mellanox systems. This option alone does not add any kernel code.
@@ -34,4 +34,16 @@ config MLXREG_IO
to system resets operation, system reset causes monitoring and some
kinds of mux selection.
+config MLXBF_BOOTCTL
+ tristate "Mellanox BlueField Firmware Boot Control driver"
+ depends on ARM64
+ help
+ The Mellanox BlueField firmware implements functionality to
+ request swapping the primary and alternate eMMC boot
+ partition, and to set up a watchdog that can undo that swap
+ if the system does not boot up correctly. This driver
+ provides sysfs access to the firmware, to be used in
+ conjunction with the eMMC device driver to do any necessary
+ initial swap of the boot partition.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 57074d9c..76b0370 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -5,3 +5,4 @@
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
+obj-$(CONFIG_MLXBF_BOOTCTL)+= mlxbf-bootctl.o
diff --git a/drivers/platform/mellanox/mlxbf-bootctl.c
b/drivers/platform/mellanox/mlxbf-bootctl.c
new file mode 100644
index 000..4c049a0
--- /dev/null
+++ b/drivers/platform/mellanox/mlxbf-bootctl.c
@@ -0,0 +1,310 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox boot control driver
+ * This driver provides a sysfs interface for systems management
+ * software to manage reset-time actions.
+ *
+ * Copyright (C) 2019 Mellanox Technologies
+ */
+
+#include
+#include
+#include
+#include
+#include "mlxbf-bootctl.h"
+
+#define MLXBF_BOOTCTL_DRIVER_NAME "mlxbf-bootctl"
+#define MLXBF_BOOTCTL_DRIVER_DESCRIPTION "Mellanox boot control driver"
+
+#define MLXBF_BOOTCTL_SB_SECURE_MASK 0x03
+#define MLXBF_BOOTCTL_SB_TEST_MASK 0x0c
+
+#define MLXBF_SB_KEY_NUM 4
+
+/* UUID used to probe ATF service. */
+static const char * const mlxbf_bootctl_svc_uuid_str =
+ "89c036b4-e7d7-11e6-8797-001aca00bfc4";
+
+struct mlxbf_bootctl_name {
+ u32 value;
+ const char *name;
+};
+
+static struct mlxbf_bootctl_name boot_names[] = {
+ { MLXBF_BOOTCTL_EXTERNAL, "external" },
+ { MLXBF_BOOTCTL_EMMC, "emmc" },
+ { MLNX_BOOTCTL_SWAP_EMMC, "swap_emmc" },
+ { MLXBF_BOOTCTL_EMMC_LEGACY,"emmc_legacy" },
+ { MLXBF_BOOTCTL_NONE, "none" },
+};
+
+static const char * const mlxbf_bootctl_lifecycle_states[] = {
+ [0] = "soft_non_secure",
+ [1] = "secure",
+ [2] = "hard_non_secure",
+ [3] = "rma",
[PATCH 0/9] Enable dw-mmc multi-card support
This series of commits enables the multi-card support for the dw-mmc controller. It includes two parts as below. The first part (patches 1-7) reverts the series of recent commits that removed the multi-card support with comments saying there was no such use case in the real world. Actually this feature is being used in Mellanox Bluefield SoC and has been requested by customers. The second part (patches 8-9) fixes the DesignWare multi-card support according to the dw-mmc databook (synnopsys: DesignWare Cores Mobile Storage Host Databook, 2.70a). It has changes to set the card number into the CMD register to multiplex requests to different cards when working in SD_MMC_CEATA mode, set the CTYPE / CLKENA / CDTHRCTL registers properly according to the spec, and parse the per-card configuration to match the Linux Documentation (bindings/mmc/synopsys-dw-mshc.txt). Liming Sun (9): Revert "Documentation: dw-mshc: deprecate num-slots" Revert "mmc: dw_mmc: remove the unnecessary slot variable" Revert "mmc: dw_mmc: use the 'slot' instead of 'cur_slot'" Revert "mmc: dw_mmc: remove the 'id' arguments about functions relevant to slot" Revert "mmc: dw_mmc: change the array of slots" Revert "mmc: dw_mmc: remove the loop about finding slots" Revert "mmc: dw_mmc: deprecated the "num-slots" property" mmc: dw_mmc: Support two SD_MMC_CE-ATA cards mmc: dw_mmc: Parse slot-specific configuration .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 16 +- drivers/mmc/host/dw_mmc-exynos.c | 4 +- drivers/mmc/host/dw_mmc.c | 277 - drivers/mmc/host/dw_mmc.h | 17 +- 4 files changed, 236 insertions(+), 78 deletions(-) -- 1.8.3.1
[PATCH 3/9] Revert "mmc: dw_mmc: use the 'slot' instead of 'cur_slot'"
This reverts commit 42f989c002f235557e3a03feac3b2f16b17d53f6.
The Mellanox BlueField SoC requires multiple slot dw-mmc support.
Signed-off-by: Liming Sun
---
drivers/mmc/host/dw_mmc-exynos.c | 4 ++--
drivers/mmc/host/dw_mmc.c| 33 +
drivers/mmc/host/dw_mmc.h| 3 +++
3 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 3502679..25691cc 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -157,8 +157,8 @@ static void dw_mci_exynos_set_clksel_timing(struct dw_mci
*host, u32 timing)
* HOLD register should be bypassed in case there is no phase shift
* applied on CMD/DATA that is sent to the card.
*/
- if (!SDMMC_CLKSEL_GET_DRV_WD3(clksel) && host->slot)
- set_bit(DW_MMC_CARD_NO_USE_HOLD, &host->slot->flags);
+ if (!SDMMC_CLKSEL_GET_DRV_WD3(clksel) && host->cur_slot)
+ set_bit(DW_MMC_CARD_NO_USE_HOLD, &host->cur_slot->flags);
}
#ifdef CONFIG_PM
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index c9f81db..62c0791 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -392,7 +392,7 @@ static u32 dw_mci_prep_stop_abort(struct dw_mci *host,
struct mmc_command *cmd)
cmdr = stop->opcode | SDMMC_CMD_STOP |
SDMMC_CMD_RESP_CRC | SDMMC_CMD_RESP_EXP;
- if (!test_bit(DW_MMC_CARD_NO_USE_HOLD, &host->slot->flags))
+ if (!test_bit(DW_MMC_CARD_NO_USE_HOLD, &host->cur_slot->flags))
cmdr |= SDMMC_CMD_USE_HOLD_REG;
return cmdr;
@@ -499,7 +499,7 @@ static void dw_mci_dmac_complete_dma(void *arg)
if ((host->use_dma == TRANS_MODE_EDMAC) &&
data && (data->flags & MMC_DATA_READ))
/* Invalidate cache after read */
- dma_sync_sg_for_cpu(mmc_dev(host->slot->mmc),
+ dma_sync_sg_for_cpu(mmc_dev(host->cur_slot->mmc),
data->sg,
data->sg_len,
DMA_FROM_DEVICE);
@@ -839,7 +839,7 @@ static int dw_mci_edmac_start_dma(struct dw_mci *host,
/* Flush cache before write */
if (host->data->flags & MMC_DATA_WRITE)
- dma_sync_sg_for_device(mmc_dev(host->slot->mmc), sgl,
+ dma_sync_sg_for_device(mmc_dev(host->cur_slot->mmc), sgl,
sg_elems, DMA_TO_DEVICE);
dma_async_issue_pending(host->dms->ch);
@@ -1301,6 +1301,7 @@ static void __dw_mci_start_request(struct dw_mci *host,
mrq = slot->mrq;
+ host->cur_slot = slot;
host->mrq = mrq;
host->pending_events = 0;
@@ -1781,7 +1782,7 @@ static bool dw_mci_reset(struct dw_mci *host)
ciu_out:
/* After a CTRL reset we need to have CIU set clock registers */
- mci_send_cmd(host->slot, SDMMC_CMD_UPD_CLK, 0);
+ mci_send_cmd(host->cur_slot, SDMMC_CMD_UPD_CLK, 0);
return ret;
}
@@ -1808,11 +1809,11 @@ static void dw_mci_request_end(struct dw_mci *host,
struct mmc_request *mrq)
__acquires(&host->lock)
{
struct dw_mci_slot *slot;
- struct mmc_host *prev_mmc = host->slot->mmc;
+ struct mmc_host *prev_mmc = host->cur_slot->mmc;
WARN_ON(host->cmd || host->data);
- host->slot->mrq = NULL;
+ host->cur_slot->mrq = NULL;
host->mrq = NULL;
if (!list_empty(&host->queue)) {
slot = list_entry(host->queue.next,
@@ -1962,7 +1963,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
err = dw_mci_command_complete(host, cmd);
if (cmd == mrq->sbc && !err) {
prev_state = state = STATE_SENDING_CMD;
- __dw_mci_start_request(host, host->slot,
+ __dw_mci_start_request(host, host->cur_slot,
mrq->cmd);
goto unlock;
}
@@ -3308,9 +3309,9 @@ int dw_mci_runtime_suspend(struct device *dev)
clk_disable_unprepare(host->ciu_clk);
- if (host->slot &&
- (mmc_can_gpio_cd(host->slot->mmc) ||
-!mmc_card_is_removable(host->slot->mmc)))
+ if (host->cur_slot &&
+ (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+!mmc_card_is_removable(host->cur_slot->mmc)))
clk_disable_unprepare(host->biu_clk);
return 0;
@@ -3323,9 +3324,9 @@ int dw_mci_runtime_resume(struct device *dev)
struct dw_m
[PATCH 1/9] Revert "Documentation: dw-mshc: deprecate num-slots"
This reverts commit 3f5b4b79d4c0fa71fd7d74c2a44bbc0869c04c9b.
The Mellanox BlueField SoC requires multiple slot dw-mmc support.
Signed-off-by: Liming Sun
---
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index ef3e5f1..9cb55ca 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -12,12 +12,12 @@ Required Properties:
* #address-cells: should be 1.
* #size-cells: should be 0.
-# Slots (DEPRECATED): The slot specific information are contained within
- child-nodes with each child-node representing a supported slot. There should
- be atleast one child node representing a card slot. The name of the child
node
- representing the slot is recommended to be slot@n where n is the unique
number
- of the slot connected to the controller. The following are optional
properties
- which can be included in the slot child node.
+# Slots: The slot specific information are contained within child-nodes with
+ each child-node representing a supported slot. There should be atleast one
+ child node representing a card slot. The name of the child node representing
+ the slot is recommended to be slot@n where n is the unique number of the slot
+ connected to the controller. The following are optional properties which
+ can be included in the slot child node.
* reg: specifies the physical slot number. The valid values of this
property is 0 to (num-slots -1), where num-slots is the value
@@ -63,7 +63,7 @@ Optional properties:
clock(cclk_out). If it's not specified, max is 200MHZ and min is 400KHz by
default.
(Use the "max-frequency" instead of "clock-freq-min-max".)
-* num-slots (DEPRECATED): specifies the number of slots supported by the
controller.
+* num-slots: specifies the number of slots supported by the controller.
The number of physical slots actually used could be equal or less than the
value specified by num-slots. If this property is not specified, the value
of num-slot property is assumed to be 1.
@@ -124,6 +124,7 @@ board specific portions as listed below.
dwmmc0@1220 {
clock-frequency = <4>;
clock-freq-min-max = <40 2>;
+ num-slots = <1>;
broken-cd;
fifo-depth = <0x80>;
card-detect-delay = <200>;
@@ -138,6 +139,7 @@ board specific portions as listed below.
dwmmc0@1220 {
clock-frequency = <4>;
clock-freq-min-max = <40 2>;
+ num-slots = <1>;
broken-cd;
fifo-depth = <0x80>;
card-detect-delay = <200>;
--
1.8.3.1
[PATCH 2/9] Revert "mmc: dw_mmc: remove the unnecessary slot variable"
This reverts commit e47c0b96678c5fd731c125dca677880e06d6394c.
The Mellanox BlueField SoC requires multiple slot dw-mmc support.
Signed-off-by: Liming Sun
---
drivers/mmc/host/dw_mmc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 860313b..c9f81db 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3040,15 +3040,17 @@ static void dw_mci_enable_cd(struct dw_mci *host)
{
unsigned long irqflags;
u32 temp;
+ struct dw_mci_slot *slot;
/*
* No need for CD if all slots have a non-error GPIO
* as well as broken card detection is found.
*/
- if (host->slot->mmc->caps & MMC_CAP_NEEDS_POLL)
+ slot = host->slot;
+ if (slot->mmc->caps & MMC_CAP_NEEDS_POLL)
return;
- if (mmc_gpio_get_cd(host->slot->mmc) < 0) {
+ if (mmc_gpio_get_cd(slot->mmc) < 0) {
spin_lock_irqsave(&host->irq_lock, irqflags);
temp = mci_readl(host, INTMASK);
temp |= SDMMC_INT_CD;
@@ -3319,6 +3321,7 @@ int dw_mci_runtime_resume(struct device *dev)
{
int ret = 0;
struct dw_mci *host = dev_get_drvdata(dev);
+ struct dw_mci_slot *slot = host->slot;
if (host->slot &&
(mmc_can_gpio_cd(host->slot->mmc) ||
@@ -3358,11 +3361,11 @@ int dw_mci_runtime_resume(struct device *dev)
mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE);
- if (host->slot->mmc->pm_flags & MMC_PM_KEEP_POWER)
- dw_mci_set_ios(host->slot->mmc, &host->slot->mmc->ios);
+ if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER)
+ dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
/* Force setup bus to guarantee available clock output */
- dw_mci_setup_bus(host->slot, true);
+ dw_mci_setup_bus(slot, true);
/* Now that slots are all setup, we can enable card detect */
dw_mci_enable_cd(host);
--
1.8.3.1
[PATCH 7/9] Revert "mmc: dw_mmc: deprecated the "num-slots" property"
This reverts commit d30a8f7bdf6498e47bd3a6f31e5028f239deb208.
The Mellanox BlueField SoC requires multiple slot dw-mmc support.
Signed-off-by: Liming Sun
---
drivers/mmc/host/dw_mmc.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ef36e05..150cd05 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3018,8 +3018,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci
*host)
}
/* find out number of slots supported */
- if (!device_property_read_u32(dev, "num-slots", &pdata->num_slots))
- dev_info(dev, "'num-slots' was deprecated.\n");
+ device_property_read_u32(dev, "num-slots", &pdata->num_slots);
if (device_property_read_u32(dev, "fifo-depth", &pdata->fifo_depth))
dev_info(dev,
@@ -3252,12 +3251,18 @@ int dw_mci_probe(struct dw_mci *host)
if (ret)
goto err_dmaunmap;
- /*
-* Even though dwmmc IP is provided the multiple slots,
-* there is no use case in mmc subsystem.
-* dwmmc host controller needs to initialize the one slot per an IP.
-*/
- host->num_slots = 1;
+ if (host->pdata->num_slots)
+ host->num_slots = host->pdata->num_slots;
+ else
+ host->num_slots = 1;
+
+ if (host->num_slots < 1 ||
+ host->num_slots > SDMMC_GET_SLOT_NUM(mci_readl(host, HCON))) {
+ dev_err(host->dev,
+ "Platform data must supply correct num_slots.\n");
+ ret = -ENODEV;
+ goto err_clk_ciu;
+ }
/*
* Enable interrupts for command done, data over, data empty,
--
1.8.3.1
[PATCH 9/9] mmc: dw_mmc: Parse slot-specific configuration
This commit adds code to parse the child-nodes for slot specific
configuration in the dw_mmc host driver according to
linux/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
This change is needed when the cards have different configuration
like the 'bus-width'.
Signed-off-by: Liming Sun
Reviewed-by: Chris Metcalf
---
drivers/mmc/host/dw_mmc.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a3188c2..9d870db 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2766,6 +2766,39 @@ static irqreturn_t dw_mci_interrupt(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+static void mmc_parse_slot_cfg(struct mmc_host *mmc)
+{
+ struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct fwnode_handle *child;
+ u32 bus_width, id;
+
+ /* Find the node for this card. */
+ device_for_each_child_node(mmc->parent, child) {
+ if (!fwnode_property_read_u32(child, "reg", &id) &&
+ id == slot->id)
+ break;
+ }
+
+ if (!child)
+ return;
+
+ if (!fwnode_property_read_u32(child, "bus-width", &bus_width)) {
+ switch (bus_width) {
+ case 8:
+ mmc->caps |= MMC_CAP_8_BIT_DATA;
+ /* Hosts capable of 8-bit can also do 4 bits. */
+ case 4:
+ mmc->caps |= MMC_CAP_4_BIT_DATA;
+ break;
+ default:
+ break;
+ }
+ }
+
+ if (fwnode_property_read_bool(child, "disable-wp"))
+ mmc->caps2 |= MMC_CAP2_NO_WRITE_PROTECT;
+}
+
static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
{
struct mmc_host *mmc;
@@ -2830,10 +2863,14 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
if (host->pdata->caps2)
mmc->caps2 = host->pdata->caps2;
+ /* Parse common configuration. */
ret = mmc_of_parse(mmc);
if (ret)
goto err_host_allocated;
+ /* Check per-slot configuration. */
+ mmc_parse_slot_cfg(mmc);
+
/* Process SDIO IRQs through the sdio_irq_work. */
if (mmc->caps & MMC_CAP_SDIO_IRQ)
mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;
--
1.8.3.1
[PATCH 4/9] Revert "mmc: dw_mmc: remove the 'id' arguments about functions relevant to slot"
This reverts commit e4a65ef7687b6aaf36bedb497d3fd1480163d2d5.
The Mellanox BlueField SoC requires multiple slot dw-mmc support.
Signed-off-by: Liming Sun
---
drivers/mmc/host/dw_mmc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 62c0791..a4356d6 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2709,7 +2709,7 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int dw_mci_init_slot(struct dw_mci *host)
+static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
{
struct mmc_host *mmc;
struct dw_mci_slot *slot;
@@ -2722,8 +2722,8 @@ static int dw_mci_init_slot(struct dw_mci *host)
return -ENOMEM;
slot = mmc_priv(mmc);
- slot->id = 0;
- slot->sdio_id = host->sdio_id0 + slot->id;
+ slot->id = id;
+ slot->sdio_id = host->sdio_id0 + id;
slot->mmc = mmc;
slot->host = host;
host->slot = slot;
@@ -2822,7 +2822,7 @@ static int dw_mci_init_slot(struct dw_mci *host)
return ret;
}
-static void dw_mci_cleanup_slot(struct dw_mci_slot *slot)
+static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
{
/* Debugfs stuff is cleaned up by mmc core */
mmc_remove_host(slot->mmc);
@@ -3245,7 +3245,7 @@ int dw_mci_probe(struct dw_mci *host)
host->irq, width, fifo_size);
/* We need at least one slot to succeed */
- ret = dw_mci_init_slot(host);
+ ret = dw_mci_init_slot(host, 0);
if (ret) {
dev_dbg(host->dev, "slot %d init failed\n", i);
goto err_dmaunmap;
@@ -3275,9 +3275,11 @@ int dw_mci_probe(struct dw_mci *host)
void dw_mci_remove(struct dw_mci *host)
{
- dev_dbg(host->dev, "remove slot\n");
+ int i = 0;
+
+ dev_dbg(host->dev, "remove slot %d\n", i);
if (host->slot)
- dw_mci_cleanup_slot(host->slot);
+ dw_mci_cleanup_slot(host->slot, i);
mci_writel(host, RINTSTS, 0x);
mci_writel(host, INTMASK, 0); /* disable all mmc interrupt first */
--
1.8.3.1
[PATCH 5/9] Revert "mmc: dw_mmc: change the array of slots"
This reverts commit b23475faed77f6a9016013c8db6b4707466e74a8.
The Mellanox BlueField SoC requires multiple slot dw-mmc support.
Signed-off-by: Liming Sun
---
drivers/mmc/host/dw_mmc.c | 21 -
drivers/mmc/host/dw_mmc.h | 4 +++-
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a4356d6..d11b8d7 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2582,7 +2582,8 @@ static void dw_mci_cmd_interrupt(struct dw_mci *host, u32
status)
static void dw_mci_handle_cd(struct dw_mci *host)
{
- struct dw_mci_slot *slot = host->slot;
+ int i = 0;
+ struct dw_mci_slot *slot = host->slot[i];
if (slot->mmc->ops->card_event)
slot->mmc->ops->card_event(slot->mmc);
@@ -2594,7 +2595,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
{
struct dw_mci *host = dev_id;
u32 pending;
- struct dw_mci_slot *slot = host->slot;
+ int i = 0;
+ struct dw_mci_slot *slot = host->slot[i];
pending = mci_readl(host, MINTSTS); /* read-only mask reg */
@@ -2726,7 +2728,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
slot->sdio_id = host->sdio_id0 + id;
slot->mmc = mmc;
slot->host = host;
- host->slot = slot;
+ host->slot[id] = slot;
mmc->ops = &dw_mci_ops;
if (device_property_read_u32_array(host->dev, "clock-freq-min-max",
@@ -2826,7 +2828,7 @@ static void dw_mci_cleanup_slot(struct dw_mci_slot *slot,
unsigned int id)
{
/* Debugfs stuff is cleaned up by mmc core */
mmc_remove_host(slot->mmc);
- slot->host->slot = NULL;
+ slot->host->slot[id] = NULL;
mmc_free_host(slot->mmc);
}
@@ -3041,13 +3043,14 @@ static void dw_mci_enable_cd(struct dw_mci *host)
{
unsigned long irqflags;
u32 temp;
+ int i = 0;
struct dw_mci_slot *slot;
/*
* No need for CD if all slots have a non-error GPIO
* as well as broken card detection is found.
*/
- slot = host->slot;
+ slot = host->slot[i];
if (slot->mmc->caps & MMC_CAP_NEEDS_POLL)
return;
@@ -3278,8 +3281,8 @@ void dw_mci_remove(struct dw_mci *host)
int i = 0;
dev_dbg(host->dev, "remove slot %d\n", i);
- if (host->slot)
- dw_mci_cleanup_slot(host->slot, i);
+ if (host->slot[i])
+ dw_mci_cleanup_slot(host->slot[i], i);
mci_writel(host, RINTSTS, 0x);
mci_writel(host, INTMASK, 0); /* disable all mmc interrupt first */
@@ -3322,9 +3325,9 @@ int dw_mci_runtime_suspend(struct device *dev)
int dw_mci_runtime_resume(struct device *dev)
{
- int ret = 0;
+ int i = 0, ret = 0;
struct dw_mci *host = dev_get_drvdata(dev);
- struct dw_mci_slot *slot = host->slot;
+ struct dw_mci_slot *slot = host->slot[i];
if (host->cur_slot &&
(mmc_can_gpio_cd(host->cur_slot->mmc) ||
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 20a956e..e62cafc 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -20,6 +20,8 @@
#include
#include
+#define MAX_MCI_SLOTS 2
+
enum dw_mci_state {
STATE_IDLE = 0,
STATE_SENDING_CMD,
@@ -214,7 +216,7 @@ struct dw_mci {
void*priv;
struct clk *biu_clk;
struct clk *ciu_clk;
- struct dw_mci_slot *slot;
+ struct dw_mci_slot *slot[MAX_MCI_SLOTS];
/* FIFO push and pull */
int fifo_depth;
--
1.8.3.1
[PATCH 6/9] Revert "mmc: dw_mmc: remove the loop about finding slots"
This reverts commit 58870241a67453be7dc9ab368d5a0cdc9c404616.
The Mellanox BlueField SoC requires multiple slot dw-mmc support.
Signed-off-by: Liming Sun
---
drivers/mmc/host/dw_mmc.c | 115 +++---
1 file changed, 79 insertions(+), 36 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index d11b8d7..ef36e05 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2582,21 +2582,26 @@ static void dw_mci_cmd_interrupt(struct dw_mci *host,
u32 status)
static void dw_mci_handle_cd(struct dw_mci *host)
{
- int i = 0;
- struct dw_mci_slot *slot = host->slot[i];
+ int i;
+
+ for (i = 0; i < host->num_slots; i++) {
+ struct dw_mci_slot *slot = host->slot[i];
+
+ if (!slot)
+ continue;
- if (slot->mmc->ops->card_event)
- slot->mmc->ops->card_event(slot->mmc);
- mmc_detect_change(slot->mmc,
- msecs_to_jiffies(host->pdata->detect_delay_ms));
+ if (slot->mmc->ops->card_event)
+ slot->mmc->ops->card_event(slot->mmc);
+ mmc_detect_change(slot->mmc,
+ msecs_to_jiffies(host->pdata->detect_delay_ms));
+ }
}
static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
{
struct dw_mci *host = dev_id;
u32 pending;
- int i = 0;
- struct dw_mci_slot *slot = host->slot[i];
+ int i;
pending = mci_readl(host, MINTSTS); /* read-only mask reg */
@@ -2675,11 +2680,19 @@ static irqreturn_t dw_mci_interrupt(int irq, void
*dev_id)
dw_mci_handle_cd(host);
}
- if (pending & SDMMC_INT_SDIO(slot->sdio_id)) {
- mci_writel(host, RINTSTS,
- SDMMC_INT_SDIO(slot->sdio_id));
- __dw_mci_enable_sdio_irq(slot, 0);
- sdio_signal_irq(slot->mmc);
+ /* Handle SDIO Interrupts */
+ for (i = 0; i < host->num_slots; i++) {
+ struct dw_mci_slot *slot = host->slot[i];
+
+ if (!slot)
+ continue;
+
+ if (pending & SDMMC_INT_SDIO(slot->sdio_id)) {
+ mci_writel(host, RINTSTS,
+ SDMMC_INT_SDIO(slot->sdio_id));
+ __dw_mci_enable_sdio_irq(slot, 0);
+ sdio_signal_irq(slot->mmc);
+ }
}
}
@@ -3043,24 +3056,29 @@ static void dw_mci_enable_cd(struct dw_mci *host)
{
unsigned long irqflags;
u32 temp;
- int i = 0;
+ int i;
struct dw_mci_slot *slot;
/*
* No need for CD if all slots have a non-error GPIO
* as well as broken card detection is found.
*/
- slot = host->slot[i];
- if (slot->mmc->caps & MMC_CAP_NEEDS_POLL)
- return;
+ for (i = 0; i < host->num_slots; i++) {
+ slot = host->slot[i];
+ if (slot->mmc->caps & MMC_CAP_NEEDS_POLL)
+ return;
- if (mmc_gpio_get_cd(slot->mmc) < 0) {
- spin_lock_irqsave(&host->irq_lock, irqflags);
- temp = mci_readl(host, INTMASK);
- temp |= SDMMC_INT_CD;
- mci_writel(host, INTMASK, temp);
- spin_unlock_irqrestore(&host->irq_lock, irqflags);
+ if (mmc_gpio_get_cd(slot->mmc) < 0)
+ break;
}
+ if (i == host->num_slots)
+ return;
+
+ spin_lock_irqsave(&host->irq_lock, irqflags);
+ temp = mci_readl(host, INTMASK);
+ temp |= SDMMC_INT_CD;
+ mci_writel(host, INTMASK, temp);
+ spin_unlock_irqrestore(&host->irq_lock, irqflags);
}
int dw_mci_probe(struct dw_mci *host)
@@ -3068,6 +3086,7 @@ int dw_mci_probe(struct dw_mci *host)
const struct dw_mci_drv_data *drv_data = host->drv_data;
int width, i, ret = 0;
u32 fifo_size;
+ int init_slots = 0;
if (!host->pdata) {
host->pdata = dw_mci_parse_dt(host);
@@ -3234,6 +3253,13 @@ int dw_mci_probe(struct dw_mci *host)
goto err_dmaunmap;
/*
+* Even though dwmmc IP is provided the multiple slots,
+* there is no use case in mmc subsystem.
+* dwmmc host controller needs to initialize the one slot per an IP.
+*/
+ host->num_slots = 1;
+
+ /*
* Enable interrupts for command done, data over, data empty,
* receive ready and error such as transmit, receive timeou
[PATCH 8/9] mmc: dw_mmc: Support two SD_MMC_CE-ATA cards
The dw_mmc controller supports two cards, but the current
driver only supports one card. The issue was found on a system
with two SD_MMC_CE-ATA cards. In such case, none of the cards
could come up when both are enabled.
According to the DesignWare Cores Mobile Storage Host Databook,
DW-MMC supports MMC-Ver3.3-only mode and SD_MMC_CE-ATA mode. In
the latter case, the memory cards are connected in a star topology
where each card has its own bus. In this case, the 'card-number'
in several registers needs to be set so the demux logic of the
controller can send the command or data to only the selected
card. This logic doesn't seem to be fully implemented in the
current dw-mmc driver.
This commit has the following changes to solve the two-card issue.
- Set the CTYPE register for multi-card case;
- Set the CLKENA register for multi-card case;
- Set the 'slot_num' field in CMD register;
- Program the CDTHRCTL register for the SD_MMC_CE-ATA mode which
is mentioned as a must in the databook for version 270a.
Signed-off-by: Liming Sun
Reviewed-by: Chris Metcalf
---
drivers/mmc/host/dw_mmc.c | 75 ++-
drivers/mmc/host/dw_mmc.h | 10 +++
2 files changed, 71 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 150cd05..a3188c2 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -251,11 +251,36 @@ static bool dw_mci_ctrl_reset(struct dw_mci *host, u32
reset)
return true;
}
-static void dw_mci_wait_while_busy(struct dw_mci *host, u32 cmd_flags)
+static void dw_mci_wait_while_busy(struct dw_mci *host, u32 cmd_flags,
+ struct dw_mci_slot *slot)
{
u32 status;
/*
+* Only one memory card should be selected at a time for command or data
+* transfer. For example, when a data transfer from a card occurs, a new
+* command should not be sent to another card; within the same card, a
+* new command is allowed to read the status, or to stop or abort the
+* current data transfer.
+*/
+ status = mci_readl(host, CMD);
+ if (SDMMC_GET_CARD_NUM(status) != slot->id) {
+ /* Check the last command of the other card. */
+ if (readl_poll_timeout_atomic(host->regs + SDMMC_CMD,
+ status,
+ !(status & SDMMC_CMD_START),
+ 10, 500 * USEC_PER_MSEC))
+ dev_err(host->dev, "CMD busy; trying anyway\n");
+
+ /* Check the busy state of the other card. */
+ if (readl_poll_timeout_atomic(host->regs + SDMMC_STATUS,
+ status,
+ !(status & SDMMC_STATUS_BUSY),
+ 10, 500 * USEC_PER_MSEC))
+ dev_err(host->dev, "STATUS busy; trying anyway\n");
+ }
+
+ /*
* Databook says that before issuing a new data transfer command
* we need to check to see if the card is busy. Data transfer commands
* all have SDMMC_CMD_PRV_DAT_WAIT set, so we'll key off that.
@@ -280,8 +305,9 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd,
u32 arg)
mci_writel(host, CMDARG, arg);
wmb(); /* drain writebuffer */
- dw_mci_wait_while_busy(host, cmd);
- mci_writel(host, CMD, SDMMC_CMD_START | cmd);
+ dw_mci_wait_while_busy(host, cmd, slot);
+ mci_writel(host, CMD, SDMMC_CMD_START | cmd |
+ SDMMC_CMD_CARD_NUM(slot->id));
if (readl_poll_timeout_atomic(host->regs + SDMMC_CMD, cmd_status,
!(cmd_status & SDMMC_CMD_START),
@@ -423,13 +449,14 @@ static void dw_mci_start_command(struct dw_mci *host,
mci_writel(host, CMDARG, cmd->arg);
wmb(); /* drain writebuffer */
- dw_mci_wait_while_busy(host, cmd_flags);
+ dw_mci_wait_while_busy(host, cmd_flags, host->cur_slot);
/* response expected command only */
if (cmd_flags & SDMMC_CMD_RESP_EXP)
dw_mci_set_cto(host);
- mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START);
+ mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START |
+ SDMMC_CMD_CARD_NUM(host->cur_slot->id));
}
static inline void send_stop_abort(struct dw_mci *host, struct mmc_data *data)
@@ -1069,7 +1096,9 @@ static void dw_mci_ctrl_thld(struct dw_mci *host, struct
mmc_data *data)
enable = SDMMC_CARD_RD_THR_EN;
if (host->timing != MMC_TIMING_MMC_HS200 &&
- host->timing != MMC_TIMING_UHS_SDR104)
+ host->timing != MMC_TIMING_UHS_SDR104 &&
+ (host->timing !
RE: [PATCH 0/9] Enable dw-mmc multi-card support
Thanks Jaehoon. Please also see my response inline.
- Liming
> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: Friday, October 20, 2017 10:06 AM
> To: Liming Sun ; Shawn Lin chips.com>
> Cc: Ulf Hansson ; Rob Herring
> ; Mark Rutland ; Kukjin Kim
> ; Krzysztof Kozlowski ; linux-
> m...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> samsung-...@vger.kernel.org; Chris Metcalf
> Subject: Re: [PATCH 0/9] Enable dw-mmc multi-card support
>
> Sorry for late this..
>
> On 10/18/2017 12:52 AM, Liming Sun wrote:
> >>> Hrm it's so unlucky that your patchset comes a little late. As your
> >>> patch
> 8 and 9 said, you need them to fix problem for multi-card support, so
> definitely there was no such use case, and even the code was buggy to
> support it right? That makes the code hard to read and maintain, so we
> decide to remove it.
> >
> > Thanks for the feedback. Yes, earlier the multi-card support was buggy
> indeed. We spent some time to debug it and got it working.
> >
> >>> Havn'e check the databook for details yet, but I think it's ok to re-
> introduce multi-slot support if a real user benefits from it. But you need a
> new patch to silent the log "num-slots property not found, assuming 1 slot is
> available" as we removed all the num-slots from DT at that time.
> >
> > The " num-slots property not found..." log message has already been
> removed by 8a629d26f back in 2016. Looks like we're good on this one. In
> dw_mci_probe (), it has code to check pdata->num_slots. If 0, the host-
> >num_slots will be set to 1. So the logic of setting default num_slots seems
> already there. But correct me if I am wrong.
> >
> > Thanks,
> > Liming
> >
> > -Original Message-
> > From: Shawn Lin [mailto:shawn@rock-chips.com]
> > Sent: Monday, October 16, 2017 9:36 PM
> > To: Liming Sun ; Jaehoon Chung
> >
> > Cc: Ulf Hansson ; Rob Herring
> > ; Mark Rutland ; Kukjin
> Kim
> > ; Krzysztof Kozlowski ;
> > shawn@rock-chips.com; linux-...@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org;
> > linux-samsung-...@vger.kernel.org
> > Subject: Re: [PATCH 0/9] Enable dw-mmc multi-card support
> >
> >
> > On 2017/10/7 3:21, Liming Sun wrote:
> >> This series of commits enables the multi-card support for the dw-mmc
> >> controller. It includes two parts as below.
> >>
> >> The first part (patches 1-7) reverts the series of recent commits
> >> that removed the multi-card support with comments saying there was no
> >> such use case in the real world. Actually this feature is being used
> >> in Mellanox Bluefield SoC and has been requested by customers.
> >
> > Hrm it's so unlucky that your patchset comes a little late. As your
> > patch 8
> and 9 said, you need them to fix problem for multi-card support, so definitely
> there was no such use case, and even the code was buggy to support it right?
> That makes the code hard to read and maintain, so we decide to remove it.
>
> Hmm..
> Well, if i missed your reply for my removing patch, it's my fault..but i
> didn't
> see any reply..
> At that time, we didn't see any usage and also now...
[Liming] It is definitely not anybody's fault. My apology that I should have
made it very clear.
This is a new SoC which uses two eMMC cards. This feature has been requested by
customer.
We made it working with patches, then realized that the support for the 2nd
card was removed recently from upstream kernel.
To avoid reinventing the wheel, a better approach appears to bring back the
changes.
>
> Are there any patches for using multi slot?
> e,g) device-tree file or your own driver
[Liming] Patch 9/8 and 9/9 are the changes to fix the multi-slot support.
We follow the original
"Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt" for device
configuration.
There is no device-tree patches since there is no changes to any of the
documentation syntax.
Just in case you might be interested, below is the ACPI table we used to
include the two slots. It's defined according to synopsys-dw-mshc.txt and seems
working.
Device (MMC0) {
Name (_HID, "PRP0001")
Name (_UID, Zero)
Name (_CCA, 1)
Name (_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0x6008000, 0x400)
Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 64 }
})
// C
