Thread (1 message) 1 message, 1 author, 2016-02-05

marvell_cesa fails to register on kirkwood (88F6282)

From: Gregory CLEMENT <hidden>
Date: 2016-02-05 16:28:42

Hi,

+cc Arnaud
 
 On ven., f?vr. 05 2016, Gregory CLEMENT [off-list ref] wrote:
Hi JM,
 
 On ven., f?vr. 05 2016, JM [off-list ref] wrote:
quoted
On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
[off-list ref] wrote:
quoted
Hi JM,

 On ven., f?vr. 05 2016, JM [off-list ref] wrote:
quoted
On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
[off-list ref] wrote:
quoted
Jan, Andrew

On Fri, 5 Feb 2016 10:02:46 +0100
Andrew Lunn [off-list ref] wrote:
quoted
On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
quoted
Hi,

I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
in the following way:

modprobe marvell_cesa allhwsupport=1
dmesg | tail -n 1
[ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12

or:

modprobe marvell_cesa
dmesg | tail -n 1
[ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524

With kernel 4.3 it would fail with error -22 on that hardware. There
are scattered reports from other users experiencing the same issue
(1,2,3)

I wonder if this is a result of an invalid definition of the
crypto-sram in the dts of this SoC, or perhaps some other problem
(PEBKAC included).
Hi Jan

Do you have SRAM enabled in your kernel configuration. The
mvebu_v5_defconfig does not have it, which is a bug really.
Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
Anyway, I also think this error is related to the SRAM (not sure why the
driver is not able to get the SRAM though).

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168


--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Hi,

Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
the complete .config here: http://pastebin.com/40eKMJqE

If there is anything I can do to help squish this bug, please let me
know.
How do you get your dts?
it seems that you generated it from your dtb (or from /proc).

I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
but the resulting dts is too different for an easy comparison.

Could you also provide your dtb, maybe by using the same dtc with the
option -s I will manage to get the something easier to compare.
quoted
Yes, I simply used dtc -I fs /proc/device-tree to obtain the dts.

Here is the relevant .dtb file : http://heap.ovh/files/kirkwood-ts219-6282.dtb
OK so this dtb is exacly the one from the mainline. As most of the CESU
stuff is set in te dtis, we will be able to compare it on the other
kirkwood based board.

Gregory
So with the help of Boris we checked the ranges propreties, the reg
property and the clock too. Everyting seems OK.

Arnaud,

as you are the on who tested the cesa on kirkwood, do you remember if
you needed to add specific Kconfig or to made some change in the dts?

Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help