dt-bindings: rng: add generic bindings for MediaTek SoCs

PATCH In review [email protected] 2 participants 8 messages May 31, 2017 – Jun 7, 2017 1 message not in the archive

Subsystems (5)

Device tree bindings Arm MediaTek Crypto API Hardware random number generator core +1 more subsystems

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

[email protected]

author maintainer

2017-05-31 18:44 UTC #1 lore raw

PATCH 1/4 dt-bindings: rng: add generic bindings for MediaTek SoCs

From: Sean Wang <[email protected]>

Add the generic binding for allowing the support of RNG on MediaTek SoCs such as MT7622.

Signed-off-by Sean Wang <[email protected]>

---
 Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Documentation/devicetree/bindings/rng/mtk-rng.txt +2 -1

index a6d62a2..0772913 100644
@@ -2,7 +2,8 @@ Device-Tree bindings for Mediatek random number generator
 found in Mediatek SoC family
 
 Required properties:
-- compatible	    : Should be "mediatek,mt7623-rng"
+- compatible	    : Should be "mediatek,generic-rng" or
+				"mediatek,mt7623-rng".
 - clocks	    : list of clock specifiers, corresponding to
 		      entries in clock-names property;
 - clock-names	    : Should contain "rng" entries;

Signature · 1 line

1.9.1

Matthias Brugger

maintainer

2017-06-06 11:07 UTC #2 lore raw

Quoted 15 lines · sean.wang at mediatek.com

From: Sean Wang <[email protected]>
Add the generic binding for allowing the support of RNG on MediaTek SoCs such as MT7622.
Signed-off-by Sean Wang <[email protected]>
---
  Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/rng/mtk-rng.txt +0 -0
index a6d62a2..0772913 100644

Documentation/devicetree/bindings/rng/mtk-rng.txt Device-Tree bindings for Mediatek random number generator · line 6

Quoted 6 lines

Documentation/devicetree/bindings/rng/mtk-rng.txt +2 -1

@@ -2,7 +2,8 @@ Device-Tree bindings for Mediatek random number generator
  found in Mediatek SoC family
 
  Required properties:
-- compatible	    : Should be "mediatek,mt7623-rng"
+- compatible	    : Should be "mediatek,generic-rng" or
+				"mediatek,mt7623-rng".

What does generic-rng mean. Is it for all mt7xxx, or also for mt6xxx and mt8xxx based SoCs? I think we should stick with SoC specific bindings, as we don't know if Mediatek won't publish a new IP block next year which is differnet.

Just in case we should add a binding for the actual SoC + a fallback. For example.
- compatible " Should be

	"mediatek,mt7622-rng", 	"mediatek,mt7623-rng" for SoC mt7622
	"mediatek,mt7623-rng" for SoC mt7623

This will also eliminate the need of adding mt6722-rng to the driver, as it will use mt7623-rng as fallback. If in the future we realize that mt7622-rng has a extra feature/bug, we can still work around it, without breaking the bindings.

Makes sense?

Regards,
Matthias

Quoted 4 lines

Documentation/devicetree/bindings/rng/mtk-rng.txt +0 -0

  - clocks	    : list of clock specifiers, corresponding to
  		      entries in clock-names property;
  - clock-names	    : Should contain "rng" entries;

Sean Wang

author maintainer

2017-06-07 13:20 UTC #3 lore raw

Quoted 19 lines · Matthias Brugger

Quoted 17 lines · sean.wang at mediatek.com
From: Sean Wang <[email protected]>
Add the generic binding for allowing the support of RNG on MediaTek SoCs such as MT7622.
Signed-off-by Sean Wang <[email protected]>
---
  Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/rng/mtk-rng.txt +0 -0
index a6d62a2..0772913 100644
@@ -2,7 +2,8 @@ Device-Tree bindings for Mediatek random number generator
  found in Mediatek SoC family
 

Quoted 10 lines

Documentation/devicetree/bindings/rng/mtk-rng.txt Device-Tree bindings for Mediatek random number generator · line 6
Quoted 4 lines
Documentation/devicetree/bindings/rng/mtk-rng.txt +2 -1
  Required properties:
-- compatible	    : Should be "mediatek,mt7623-rng"
+- compatible	    : Should be "mediatek,generic-rng" or
+				"mediatek,mt7623-rng".
What does generic-rng mean. Is it for all mt7xxx, or also for mt6xxx and mt8xxx based SoCs? I think we should stick with SoC specific bindings, as we don't know if Mediatek won't publish a new IP block next year which is differnet.

Yes, what I mean is generic-rng can be applied to all platform MediaTek provides.

Quoted 11 lines

Just in case we should add a binding for the actual SoC + a fallback. For example.
- compatible " Should be
	"mediatek,mt7622-rng", 	"mediatek,mt7623-rng" for SoC mt7622
	"mediatek,mt7623-rng" for SoC mt7623
This will also eliminate the need of adding mt6722-rng to the driver, as it will use mt7623-rng as fallback. If in the future we realize that mt7622-rng has a extra feature/bug, we can still work around it, without breaking the bindings.

I knew the fallback rules you said here because I saw them being used in many drivers such as sysirq and uart driver, such kind of basic drivers.

These drivers are basic enough, various following chipsets almost fall back into the oldest one. So the clues let me think the hardware interface shouldn't have too much differences among them.

If there is string used like generic-uart or generic-sysirq, it can stop we blindly add new string into the binding document when a new platform is introduced.

And they easily allows users unfamiliar MediaTek platform (they didn't know what the oldest MediaTek chipset is) pick up the right compatible string to start bring up the new platform.

The specific one can be added after new feature required is added or critical hardware bug is found. Otherwise the generic one can fit all generic needs for those.

Those are only opinions, if you don't like it, I still can accept the original way as you suggest :)

Quoted 9 lines

Makes sense?
Regards,
Matthias
Quoted 4 lines
Documentation/devicetree/bindings/rng/mtk-rng.txt +0 -0
  - clocks	    : list of clock specifiers, corresponding to
  		      entries in clock-names property;
  - clock-names	    : Should contain "rng" entries;

Matthias Brugger

maintainer

2017-06-07 13:25 UTC #4 lore raw

Quoted 62 lines · Sean Wang

Quoted 19 lines · Matthias Brugger
Quoted 17 lines · sean.wang at mediatek.com
From: Sean Wang <[email protected]>
Add the generic binding for allowing the support of RNG on MediaTek SoCs such as MT7622.
Signed-off-by Sean Wang <[email protected]>
---
   Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/rng/mtk-rng.txt +0 -0
index a6d62a2..0772913 100644
@@ -2,7 +2,8 @@ Device-Tree bindings for Mediatek random number generator
   found in Mediatek SoC family
 
Quoted 10 lines
Documentation/devicetree/bindings/rng/mtk-rng.txt Device-Tree bindings for Mediatek random number generator · line 6
Quoted 4 lines
Documentation/devicetree/bindings/rng/mtk-rng.txt +2 -1
   Required properties:
-- compatible	    : Should be "mediatek,mt7623-rng"
+- compatible	    : Should be "mediatek,generic-rng" or
+				"mediatek,mt7623-rng".
What does generic-rng mean. Is it for all mt7xxx, or also for mt6xxx and mt8xxx based SoCs? I think we should stick with SoC specific bindings, as we don't know if Mediatek won't publish a new IP block next year which is differnet.
Yes, what I mean is generic-rng can be applied to all platform MediaTek provides.
Quoted 11 lines
Just in case we should add a binding for the actual SoC + a fallback. For example.
- compatible " Should be
	"mediatek,mt7622-rng", 	"mediatek,mt7623-rng" for SoC mt7622
	"mediatek,mt7623-rng" for SoC mt7623
This will also eliminate the need of adding mt6722-rng to the driver, as it will use mt7623-rng as fallback. If in the future we realize that mt7622-rng has a extra feature/bug, we can still work around it, without breaking the bindings.
I knew the fallback rules you said here because I saw them being used in many drivers such as sysirq and uart driver, such kind of basic drivers.
These drivers are basic enough, various following chipsets almost fall back into the oldest one. So the clues let me think the hardware interface shouldn't have too much differences among them.
If there is string used like generic-uart or generic-sysirq, it can stop we blindly add new string into the binding document when a new platform is introduced.
And they easily allows users unfamiliar MediaTek platform (they didn't know what the oldest MediaTek chipset is) pick up the right compatible string to start bring up the new platform.

Quoted 7 lines

The specific one can be added after new feature required is added or critical hardware bug is found. Otherwise the generic one can fit all generic needs for those.
Those are only opinions, if you don't like it, I still can accept the original way as you suggest :)

I can see your reasoning, but the device tree maintainers prefer to have the bindings updated for a new SoC. As I mentioned before, just imagine next year Mediatek changes the IP block and from now on, it uses the new device in all SoCs. In 5 years we would have a binding which states 'generic' although it is not compatible with any SoC of the last So

So please keep with the bindings as done up to now.

Best regards,
Matthias

Quoted 12 lines

Quoted 10 lines
Makes sense?
Regards,
Matthias
Quoted 4 lines
Documentation/devicetree/bindings/rng/mtk-rng.txt +0 -0
   - clocks	    : list of clock specifiers, corresponding to
   		      entries in clock-names property;
   - clock-names	    : Should contain "rng" entries;

Sean Wang

author maintainer

2017-06-07 14:48 UTC #5 lore raw

Quoted 72 lines · Matthias Brugger

Quoted 62 lines · Sean Wang
Quoted 19 lines · Matthias Brugger
Quoted 17 lines · sean.wang at mediatek.com
From: Sean Wang <[email protected]>
Add the generic binding for allowing the support of RNG on MediaTek SoCs such as MT7622.
Signed-off-by Sean Wang <[email protected]>
---
   Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/rng/mtk-rng.txt +0 -0
index a6d62a2..0772913 100644
@@ -2,7 +2,8 @@ Device-Tree bindings for Mediatek random number generator
   found in Mediatek SoC family
 
Quoted 10 lines
Documentation/devicetree/bindings/rng/mtk-rng.txt Device-Tree bindings for Mediatek random number generator · line 6
Quoted 4 lines
Documentation/devicetree/bindings/rng/mtk-rng.txt +2 -1
   Required properties:
-- compatible	    : Should be "mediatek,mt7623-rng"
+- compatible	    : Should be "mediatek,generic-rng" or
+				"mediatek,mt7623-rng".
What does generic-rng mean. Is it for all mt7xxx, or also for mt6xxx and mt8xxx based SoCs? I think we should stick with SoC specific bindings, as we don't know if Mediatek won't publish a new IP block next year which is differnet.
Yes, what I mean is generic-rng can be applied to all platform MediaTek provides.
Quoted 11 lines
Just in case we should add a binding for the actual SoC + a fallback. For example.
- compatible " Should be
	"mediatek,mt7622-rng", 	"mediatek,mt7623-rng" for SoC mt7622
	"mediatek,mt7623-rng" for SoC mt7623
This will also eliminate the need of adding mt6722-rng to the driver, as it will use mt7623-rng as fallback. If in the future we realize that mt7622-rng has a extra feature/bug, we can still work around it, without breaking the bindings.
I knew the fallback rules you said here because I saw them being used in many drivers such as sysirq and uart driver, such kind of basic drivers.
These drivers are basic enough, various following chipsets almost fall back into the oldest one. So the clues let me think the hardware interface shouldn't have too much differences among them.
If there is string used like generic-uart or generic-sysirq, it can stop we blindly add new string into the binding document when a new platform is introduced.
And they easily allows users unfamiliar MediaTek platform (they didn't know what the oldest MediaTek chipset is) pick up the right compatible string to start bring up the new platform.
Quoted 7 lines
The specific one can be added after new feature required is added or critical hardware bug is found. Otherwise the generic one can fit all generic needs for those.
Those are only opinions, if you don't like it, I still can accept the original way as you suggest :)

Quoted 7 lines

I can see your reasoning, but the device tree maintainers prefer to have the bindings updated for a new SoC. As I mentioned before, just imagine next year Mediatek changes the IP block and from now on, it uses the new device in all SoCs. In 5 years we would have a binding which states 'generic' although it is not compatible with any SoC of the last So
So please keep with the bindings as done up to now.

Understood, I'll follow up.

And that also reminds me that all missing bindings need to be added for each driver on the MT7623 which can fall back to other existing SoCs.

Thank you a lot

Sean

Quoted 16 lines

Best regards,
Matthias
Quoted 12 lines
Quoted 10 lines
Makes sense?
Regards,
Matthias
Quoted 4 lines
Documentation/devicetree/bindings/rng/mtk-rng.txt +0 -0
   - clocks	    : list of clock specifiers, corresponding to
   		      entries in clock-names property;
   - clock-names	    : Should contain "rng" entries;

[email protected]

author maintainer

2017-05-31 18:44 UTC #6 lore raw

PATCH 2/4 hwrng: mtk - add support for MT7622 SoC

In reply to a message not in the archive

From: Sean Wang <[email protected]>

Add "mediatek,generic-rng" allowing most of RNG on MediaTek SoCs to be compatible with the driver including MT7622 SoC.

Signed-off-by Sean Wang <[email protected]>

---
 drivers/char/hw_random/mtk-rng.c | 1 +
 1 file changed, 1 insertion(+)

drivers/char/hw_random/mtk-rng.c +1 -0

index df8eb54..3a1e1f1 100644
@@ -148,6 +148,7 @@ static int mtk_rng_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id mtk_rng_match[] = {
+	{ .compatible = "mediatek,generic-rng" },
 	{ .compatible = "mediatek,mt7623-rng" },
 	{},
 };

Signature · 1 line

1.9.1

[email protected]

author maintainer

2017-05-31 18:44 UTC #7 lore raw

PATCH 3/4 hwrng: mtk - add runtime PM support

In reply to a message not in the archive

From: Sean Wang <[email protected]>

Add runtime PM support. There will be the benefit on SoCs where the clock to the RNG used can be shutdown.

Signed-off-by Sean Wang <[email protected]>

---
 drivers/char/hw_random/mtk-rng.c | 42 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

drivers/char/hw_random/mtk-rng.c +42 -0

index 3a1e1f1..59ded4e 100644
@@ -25,6 +25,10 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+/* Runtime PM autosuspend timeout: */
+#define RNG_AUTOSUSPEND_TIMEOUT		100
 
 #define USEC_POLL			2
 #define TIMEOUT_POLL			20

@@ -90,6 +94,8 @@ static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
 	struct mtk_rng *priv = to_mtk_rng(rng);
 	int retval = 0;
 
+	pm_runtime_get_sync((struct device *)priv->rng.priv);
+
 	while (max >= sizeof(u32)) {
 		if (!mtk_rng_wait_ready(rng, wait))
 			break;

@@ -100,6 +106,9 @@ static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
 		max -= sizeof(u32);
 	}
 
+	pm_runtime_mark_last_busy((struct device *)priv->rng.priv);
+	pm_runtime_put_sync_autosuspend((struct device *)priv->rng.priv);
+
 	return retval || !wait ? retval : -EIO;
 }

@@ -120,9 +129,12 @@ static int mtk_rng_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	priv->rng.name = pdev->name;
+#ifndef CONFIG_PM
 	priv->rng.init = mtk_rng_init;
 	priv->rng.cleanup = mtk_rng_cleanup;
+#endif
 	priv->rng.read = mtk_rng_read;
+	priv->rng.priv = (unsigned long)&pdev->dev;
 
 	priv->clk = devm_clk_get(&pdev->dev, "rng");
 	if (IS_ERR(priv->clk)) {

@@ -142,11 +154,40 @@ static int mtk_rng_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	dev_set_drvdata(&pdev->dev, priv);
+	pm_runtime_set_autosuspend_delay(&pdev->dev, RNG_AUTOSUSPEND_TIMEOUT);
+	pm_runtime_use_autosuspend(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
 	dev_info(&pdev->dev, "registered RNG driver\n");
 
 	return 0;
 }
 
+#ifdef CONFIG_PM
+static int mtk_rng_runtime_suspend(struct device *dev)
+{
+	struct mtk_rng *priv = dev_get_drvdata(dev);
+
+	mtk_rng_cleanup(&priv->rng);
+
+	return 0;
+}
+
+static int mtk_rng_runtime_resume(struct device *dev)
+{
+	struct mtk_rng *priv = dev_get_drvdata(dev);
+
+	return mtk_rng_init(&priv->rng);
+}
+
+static UNIVERSAL_DEV_PM_OPS(mtk_rng_pm_ops, mtk_rng_runtime_suspend,
+			    mtk_rng_runtime_resume, NULL);
+#define MTK_RNG_PM_OPS (&mtk_rng_pm_ops)
+#else	/* CONFIG_PM */
+#define MTK_RNG_PM_OPS NULL
+#endif	/* CONFIG_PM */
+
 static const struct of_device_id mtk_rng_match[] = {
 	{ .compatible = "mediatek,generic-rng" },
 	{ .compatible = "mediatek,mt7623-rng" },

@@ -158,6 +199,7 @@ static int mtk_rng_probe(struct platform_device *pdev)
 	.probe          = mtk_rng_probe,
 	.driver = {
 		.name = MTK_RNG_DEV,
+		.pm = MTK_RNG_PM_OPS,
 		.of_match_table = mtk_rng_match,
 	},
 };

Signature · 1 line

1.9.1

[email protected]

author maintainer

2017-05-31 18:44 UTC #8 lore raw

PATCH 4/4 MAINTAINERS: add entry for MediaTek Random Number Generator

In reply to a message not in the archive

From: Sean Wang <[email protected]>

I work for MediaTek on maintaining the MediaTek RNG driver for the existing SoCs and adding support for the following SoCs.

Signed-off-by Sean Wang <[email protected]>

---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

MAINTAINERS +5 -0

index cf86519..da473d0 100644
@@ -8262,6 +8262,11 @@ L:	linux-wireless at vger.kernel.org
 S:	Maintained
 F:	drivers/net/wireless/mediatek/mt7601u/
 
+MEDIATEK RANDOM NUMBER GENERATOR SUPPORT
+M:      Sean Wang <[email protected]>
+S:      Maintained
+F:      drivers/char/hw_random/mtk-rng.c
+
 MEGACHIPS STDPXXXX-GE-B850V3-FW LVDS/DP++ BRIDGES
 M:	Peter Senna Tschudin <[email protected]>
 M:	Martin Donnelly <[email protected]>

Signature · 1 line

1.9.1