[PATCH v3 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver

[Robin Murphy]

On 24/04/17 09:57, Antoine Tenart wrote:
> Hi Igal,
> 
> On Mon, Apr 24, 2017 at 08:50:32AM +0000, Igal Liberman wrote:
>> [...]
>>
>>> +	priv->clk = of_clk_get(dev->of_node, 0);
>>> +	if (!IS_ERR(priv->clk)) {
>>> +		ret = clk_prepare_enable(priv->clk);
>>> +		if (ret) {
>>> +			dev_err(dev, "unable to enable clk (%d)\n", ret);
>>> +			return ret;
>>> +		}
>>> +	} else {
>>> +		/* The clock isn't mandatory */
>>> +		if (PTR_ERR(priv->clk) == -EPROBE_DEFER)
>>> +			return -EPROBE_DEFER;
>>> +	}
>>> +
>>> +	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
>>
>> The correct address width of the engine in Marvell SoCs is 40bit.

Is that what the IP block itself is internally limited to, or just how
many bits happen to be wired up externally in the particular Marvell
integrations?

> Oops. I'll update.

If the device itself can handle full 64-bit addresses, then the driver
should reflect that regardless of the integration - describing
integration limitations is the job of the firmware, e.g. with DT
"dma-ranges", assuming they actually matter (typically if the whole SoC
interconnect and physical memory map is the same width then having an
even wider DMA mask doesn't make any difference - 64 bits still just
means "everything").

If it's the case that the IP is configurable and could be synthesised
with various internal address widths, then that might warrant a DT
property to identify the particular configuration if it's not readable
from some ID register, although it may be reasonable in practice to
simply assume the chosen configuration to be sane (i.e. not smaller than
the rest of the system) and that the driver can set the maximal DMA mask
as above.

Robin.

> 
> Thanks!
> Antoine
>