diff mbox series

[v2,2/6] crypto: atmel-ecc: add support for ACPI probing on non-AT91 platforms

Message ID 20190524162651.28189-3-ard.biesheuvel@linaro.org
State Accepted
Commit 3c756aa346dfac5ae6b7fe81cb1c6380a20b1e41
Headers show
Series crypto - wire up Atmel SHA204A as RNG in DT and ACPI mode | expand

Commit Message

Ard Biesheuvel May 24, 2019, 4:26 p.m. UTC
The Atmel/Microchip EC508A is a I2C device that could be wired into
any platform, and is being used on the Linaro/96boards Secure96
mezzanine adapter. This means it could be found on any platform, even
on ones that use ACPI enumeration (via PRP0001 devices). So update the
code to enable this use case.

This involves tweaking the bus rate discovery code to take ACPI probing
into account, which records the maximum bus rate as a property of the
slave device. For the atmel-ecc code, this means that the effective bus
rate should never exceed the maximum rate, unless we are dealing with
buggy firmware. Nonetheless, let's just use the existing plumbing to
discover the bus rate and keep the existing logic intact.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

---
 drivers/crypto/Kconfig     |  1 -
 drivers/crypto/atmel-ecc.c | 13 ++++++++-----
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.20.1

Comments

Linus Walleij May 24, 2019, 9:52 p.m. UTC | #1
On Fri, May 24, 2019 at 6:27 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:

> The Atmel/Microchip EC508A is a I2C device that could be wired into

> any platform, and is being used on the Linaro/96boards Secure96

> mezzanine adapter. This means it could be found on any platform, even

> on ones that use ACPI enumeration (via PRP0001 devices). So update the

> code to enable this use case.

>

> This involves tweaking the bus rate discovery code to take ACPI probing

> into account, which records the maximum bus rate as a property of the

> slave device. For the atmel-ecc code, this means that the effective bus

> rate should never exceed the maximum rate, unless we are dealing with

> buggy firmware. Nonetheless, let's just use the existing plumbing to

> discover the bus rate and keep the existing logic intact.

>

> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>


Looks good to me.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>


Yours,
Linus Walleij
diff mbox series

Patch

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 0af08081e305..97ec8107eeef 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -522,7 +522,6 @@  config CRYPTO_DEV_ATMEL_SHA
 
 config CRYPTO_DEV_ATMEL_ECC
 	tristate "Support for Microchip / Atmel ECC hw accelerator"
-	depends on ARCH_AT91 || COMPILE_TEST
 	depends on I2C
 	select CRYPTO_ECDH
 	select CRC16
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index ba00e4563ca0..5705348f540f 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -657,11 +657,14 @@  static int atmel_ecc_probe(struct i2c_client *client,
 		return -ENODEV;
 	}
 
-	ret = of_property_read_u32(client->adapter->dev.of_node,
-				   "clock-frequency", &bus_clk_rate);
-	if (ret) {
-		dev_err(dev, "of: failed to read clock-frequency property\n");
-		return ret;
+	clk_rate = i2c_acpi_find_bus_speed(&client->adapter->dev);
+	if (!clk_rate) {
+		ret = device_property_read_u32(&client->adapter->dev,
+					       "clock-frequency", &bus_clk_rate);
+		if (ret) {
+			dev_err(dev, "failed to read clock-frequency property\n");
+			return ret;
+		}
 	}
 
 	if (bus_clk_rate > 1000000L) {