marvell_cesa fails to register on kirkwood (88F6282)

marvell_cesa fails to register on kirkwood (88F6282)

[JM]

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).

I can provide SSH access to the affected device if needed.

Best regards,
Jan

[1] http://archlinuxarm.org/forum/viewtopic.php?f=53&t=9249&start=30#p49373
[2] http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1003189&sid=43aea81e160fffefe21c7bd64e2de958
[3] http://forum.doozan.com/read.php?2,12096,24409#msg-24409

marvell_cesa fails to register on kirkwood (88F6282)

[Andrew Lunn]

On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
> 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.

	   Andrew

marvell_cesa fails to register on kirkwood (88F6282)

[Boris Brezillon]

Jan, Andrew

On Fri, 5 Feb 2016 10:02:46 +0100
Andrew Lunn <andrew@lunn.ch> wrote:

> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
> > 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

marvell_cesa fails to register on kirkwood (88F6282)

[JM]

On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> Jan, Andrew
>
> On Fri, 5 Feb 2016 10:02:46 +0100
> Andrew Lunn <andrew@lunn.ch> wrote:
>
>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>> > 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.

Best regards,
Jan

marvell_cesa fails to register on kirkwood (88F6282)

[Gregory CLEMENT]

Hi JM,
 
 On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:

> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
>> Jan, Andrew
>>
>> On Fri, 5 Feb 2016 10:02:46 +0100
>> Andrew Lunn <andrew@lunn.ch> wrote:
>>
>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>> > 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.

Gregory


>
> Best regards,
> Jan
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

marvell_cesa fails to register on kirkwood (88F6282)

[JM]

On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi JM,
>
>  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>
>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>> <boris.brezillon@free-electrons.com> wrote:
>>> Jan, Andrew
>>>
>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>> Andrew Lunn <andrew@lunn.ch> wrote:
>>>
>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>> > 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.
>
> Gregory
>
>
>>
>> Best regards,
>> Jan
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

Hi,

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

Best regards,
Jan

marvell_cesa fails to register on kirkwood (88F6282)

[Gregory CLEMENT]

Hi JM,
 
 On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:

> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>> Hi JM,
>>
>>  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>>
>>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>>> <boris.brezillon@free-electrons.com> wrote:
>>>> Jan, Andrew
>>>>
>>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>>> Andrew Lunn <andrew@lunn.ch> wrote:
>>>>
>>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>>> > 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.
>

> 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

> Best regards,
> Jan

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

marvell_cesa fails to register on kirkwood (88F6282)

[Gregory CLEMENT]

Hi,

+cc Arnaud
 
 On ven., f?vr. 05 2016, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi JM,
>  
>  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>
>> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
>> <gregory.clement@free-electrons.com> wrote:
>>> Hi JM,
>>>
>>>  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>>>
>>>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>>>> <boris.brezillon@free-electrons.com> wrote:
>>>>> Jan, Andrew
>>>>>
>>>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>>>> Andrew Lunn <andrew@lunn.ch> wrote:
>>>>>
>>>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>>>> > 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.
>>
>
>> 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

marvell_cesa fails to register on kirkwood (88F6282)

[Arnaud Ebalard]

Hi guys,

Gregory CLEMENT <gregory.clement@free-electrons.com> writes:

> Hi,
>
> +cc Arnaud
>  
>  On ven., f?vr. 05 2016, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
>> Hi JM,
>>  
>>  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>>
>>> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
>>> <gregory.clement@free-electrons.com> wrote:
>>>> Hi JM,
>>>>
>>>>  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>>>>
>>>>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>>>>> <boris.brezillon@free-electrons.com> wrote:
>>>>>> Jan, Andrew
>>>>>>
>>>>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>>>>> Andrew Lunn <andrew@lunn.ch> wrote:
>>>>>>
>>>>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>>>>> > 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.
>>>
>>
>>> 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?

Here is the result I get on my ReadyNAS Duo v2 (88F6282, see below) w/ a
stock 4.4 kernel I just cross-compiled w/ a gcc 4.9.2. The kernel has no
modules and uses an appended DTB (u-boot on the platform is pretyy old):

root at mood:~# dmesg | grep -i cesa
[    3.306135] marvell-cesa f1030000.crypto: CESA device successfully registered

root at mood:~# uname -a
Linux mood 4.4.0.duov2 #1 Fri Feb 5 21:11:25 CET 2016 armv5tel GNU/Linux

root at mood:~# cat /proc/cpuinfo 
processor       : 0
model name      : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1594.16
Features        : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell Kirkwood (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

I'll try and do the same now w/ CESA support compiled as module to see
what I get. I'll keep you posted.

As a side note, a simple grep on the .config file you provided at
http://pastebin.com/40eKMJqE makes me wonder why it has some
grsec options residue. Did you test on a stock 4.4 kernel or on
something w/ additional patches? If the latter, could you check what a
stock kernel gives?

Cheers,

a+

marvell_cesa fails to register on kirkwood (88F6282)

[Arnaud Ebalard]

Hi,

> I'll try and do the same now w/ CESA support compiled as module to see
> what I get. I'll keep you posted.

root at mood:~# insmod /tmp/marvell-cesa.ko 
[  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered

root at mood:~# uname -a
Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux

root at mood:~# zcat /proc/config.gz | grep -i CESA
# CONFIG_CRYPTO_DEV_MV_CESA is not set
CONFIG_CRYPTO_DEV_MARVELL_CESA=m

Cheers,

a+

ps: my config is temporarily at http://natisbad.org/config-duov2-cesa

marvell_cesa fails to register on kirkwood (88F6282)

[JM]

On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno@natisbad.org> wrote:
> Hi,
>
>> I'll try and do the same now w/ CESA support compiled as module to see
>> what I get. I'll keep you posted.
>
> root at mood:~# insmod /tmp/marvell-cesa.ko
> [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
>
> root at mood:~# uname -a
> Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
>
> root at mood:~# zcat /proc/config.gz | grep -i CESA
> # CONFIG_CRYPTO_DEV_MV_CESA is not set
> CONFIG_CRYPTO_DEV_MARVELL_CESA=m
>
> Cheers,
>
> a+
>
> ps: my config is temporarily at http://natisbad.org/config-duov2-cesa

I've built a vanilla 4.4.1 kernel image without any debian-specific
patches but using the same oldconfig
(http://heap.ovh/files/config-4.4.1.vanilla).

# uname -a
Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux

# modprobe marvell_cesa allhwsupport=1

# dmesg | tail -n1
[  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12

The dtb hasn't changed:
# diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical

I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1

Perhaps I am missing something obvious? I suppose the next step would
be to build a minimal kernel based on the config for the duov2?

Best regards,
Jan

marvell_cesa fails to register on kirkwood (88F6282)

[Arnaud Ebalard]

Hi,

JM <fijam@archlinux.us> writes:

> On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno@natisbad.org> wrote:
>> Hi,
>>
>>> I'll try and do the same now w/ CESA support compiled as module to see
>>> what I get. I'll keep you posted.
>>
>> root at mood:~# insmod /tmp/marvell-cesa.ko
>> [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
>>
>> root at mood:~# uname -a
>> Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
>>
>> root at mood:~# zcat /proc/config.gz | grep -i CESA
>> # CONFIG_CRYPTO_DEV_MV_CESA is not set
>> CONFIG_CRYPTO_DEV_MARVELL_CESA=m
>>
>> Cheers,
>>
>> a+
>>
>> ps: my config is temporarily at http://natisbad.org/config-duov2-cesa
>
> I've built a vanilla 4.4.1 kernel image without any debian-specific
> patches but using the same oldconfig
> (http://heap.ovh/files/config-4.4.1.vanilla).
>
> # uname -a
> Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux
>
> # modprobe marvell_cesa allhwsupport=1
>
> # dmesg | tail -n1
> [  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12
>
> The dtb hasn't changed:
> # diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
> Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical
>
> I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
> and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1
>
> Perhaps I am missing something obvious? I suppose the next step would
> be to build a minimal kernel based on the config for the duov2?

I must confess your problem is interesting ;-)

I did a diff between your .config and mine for the Duo v2 and then tried
to enable/disable the most promising options you had and the one I had
not but I cannot reproduce the what you get, i.e. marvell_cesa module
always loads as expectec. 

So, I also think the best path would be to use my Duo v2 file w/ your dtb
and run it on your device.

Last (unrelated) remark/question: looking at the .dts for your ts219, I
noticed one thing I am curious about:

        memory {
                device_type = "memory";
                reg = <0x00000000 0x20000000>;
        };

        ...

        ocp at f1000000 {
                pinctrl: pin-controller at 10000 {

                        pinctrl-0 = <&pmx_ram_size &pmx_board_id>;
                        pinctrl-names = "default";

                        pmx_ram_size: pmx-ram-size {
                                /* RAM: 0: 256 MB, 1: 512 MB */
                                marvell,pins = "mpp36";
                                marvell,function = "gpio";
                        };

It seems 512MB are declared for all TS219 devices but the level
available on mpp36 provides the real amount of RAM in the device.
Who/What is expected to do the adjustment on platform w/ only 256MB, if
any?

Cheers,

a+

marvell_cesa fails to register on kirkwood (88F6282)

[Russell King - ARM Linux]

On Sat, Feb 06, 2016 at 04:14:49PM +0100, JM wrote:
> On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno@natisbad.org> wrote:
> > Hi,
> >
> >> I'll try and do the same now w/ CESA support compiled as module to see
> >> what I get. I'll keep you posted.
> >
> > root at mood:~# insmod /tmp/marvell-cesa.ko
> > [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
> >
> > root at mood:~# uname -a
> > Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
> >
> > root at mood:~# zcat /proc/config.gz | grep -i CESA
> > # CONFIG_CRYPTO_DEV_MV_CESA is not set
> > CONFIG_CRYPTO_DEV_MARVELL_CESA=m
> >
> > Cheers,
> >
> > a+
> >
> > ps: my config is temporarily at http://natisbad.org/config-duov2-cesa
> 
> I've built a vanilla 4.4.1 kernel image without any debian-specific
> patches but using the same oldconfig
> (http://heap.ovh/files/config-4.4.1.vanilla).
> 
> # uname -a
> Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux
> 
> # modprobe marvell_cesa allhwsupport=1
> 
> # dmesg | tail -n1
> [  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12
> 
> The dtb hasn't changed:
> # diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
> Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical
> 
> I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
> and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1
> 
> Perhaps I am missing something obvious? I suppose the next step would
> be to build a minimal kernel based on the config for the duov2?

As you have built your own kernel, may I suggest that you add some
debug code into mv_cesa_dev_dma_init(), mv_cesa_get_sram(), and
mv_cesa_probe() to print which of the many locations that returns
-ENOMEM is triggering the above error.

In passing, I notice that:

        cesa->regs = devm_ioremap_resource(dev, res);
        if (IS_ERR(cesa->regs))
                return -ENOMEM;

is wrong.  devm_ioremap_resource() returns an errno-encoded pointer
which should be used to report the error number.  This should be:

        cesa->regs = devm_ioremap_resource(dev, res);
        if (IS_ERR(cesa->regs))
                return PTR_ERR(cesa->regs);

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

marvell_cesa fails to register on kirkwood (88F6282)

[JM]

I have rebuilt the kernel again, trying to get close to Arnaud's Duov2
config, and amazingly, it works!

$ dmesg | grep -i cesa
[    8.158636] marvell-cesa f1030000.crypto: CESA device successfully registered

I have all the goodies in /proc/crypto as well.

So apparently the bug lurks somewhere in the difference between:

http://heap.ovh/files/config-4.4.1.vanilla <- debian's config
http://heap.ovh/files/config-kirkwood-new <- duov2-like config

I could try to narrow it down, but I can only build natively, and I am
quite clueless as to where to start, so it would take some time...

Best regards,
Jan

On Mon, Feb 8, 2016 at 6:23 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Feb 06, 2016 at 04:14:49PM +0100, JM wrote:
>> On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno@natisbad.org> wrote:
>> > Hi,
>> >
>> >> I'll try and do the same now w/ CESA support compiled as module to see
>> >> what I get. I'll keep you posted.
>> >
>> > root at mood:~# insmod /tmp/marvell-cesa.ko
>> > [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
>> >
>> > root at mood:~# uname -a
>> > Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
>> >
>> > root at mood:~# zcat /proc/config.gz | grep -i CESA
>> > # CONFIG_CRYPTO_DEV_MV_CESA is not set
>> > CONFIG_CRYPTO_DEV_MARVELL_CESA=m
>> >
>> > Cheers,
>> >
>> > a+
>> >
>> > ps: my config is temporarily at http://natisbad.org/config-duov2-cesa
>>
>> I've built a vanilla 4.4.1 kernel image without any debian-specific
>> patches but using the same oldconfig
>> (http://heap.ovh/files/config-4.4.1.vanilla).
>>
>> # uname -a
>> Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux
>>
>> # modprobe marvell_cesa allhwsupport=1
>>
>> # dmesg | tail -n1
>> [  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12
>>
>> The dtb hasn't changed:
>> # diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
>> Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical
>>
>> I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
>> and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1
>>
>> Perhaps I am missing something obvious? I suppose the next step would
>> be to build a minimal kernel based on the config for the duov2?
>
> As you have built your own kernel, may I suggest that you add some
> debug code into mv_cesa_dev_dma_init(), mv_cesa_get_sram(), and
> mv_cesa_probe() to print which of the many locations that returns
> -ENOMEM is triggering the above error.
>
> In passing, I notice that:
>
>         cesa->regs = devm_ioremap_resource(dev, res);
>         if (IS_ERR(cesa->regs))
>                 return -ENOMEM;
>
> is wrong.  devm_ioremap_resource() returns an errno-encoded pointer
> which should be used to report the error number.  This should be:
>
>         cesa->regs = devm_ioremap_resource(dev, res);
>         if (IS_ERR(cesa->regs))
>                 return PTR_ERR(cesa->regs);
>
> --
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

marvell_cesa fails to register on kirkwood (88F6282)

[JM]

On Sun, Feb 14, 2016 at 1:09 AM, JM <fijam@archlinux.us> wrote:
> I have rebuilt the kernel again, trying to get close to Arnaud's Duov2
> config, and amazingly, it works!
>
> $ dmesg | grep -i cesa
> [    8.158636] marvell-cesa f1030000.crypto: CESA device successfully registered
>
> I have all the goodies in /proc/crypto as well.
>
> So apparently the bug lurks somewhere in the difference between:
>
> http://heap.ovh/files/config-4.4.1.vanilla <- debian's config
> http://heap.ovh/files/config-kirkwood-new <- duov2-like config
>
> I could try to narrow it down, but I can only build natively, and I am
> quite clueless as to where to start, so it would take some time...
>
> Best regards,
> Jan
>
> On Mon, Feb 8, 2016 at 6:23 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Feb 06, 2016 at 04:14:49PM +0100, JM wrote:
>>> On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno@natisbad.org> wrote:
>>> > Hi,
>>> >
>>> >> I'll try and do the same now w/ CESA support compiled as module to see
>>> >> what I get. I'll keep you posted.
>>> >
>>> > root at mood:~# insmod /tmp/marvell-cesa.ko
>>> > [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
>>> >
>>> > root at mood:~# uname -a
>>> > Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
>>> >
>>> > root at mood:~# zcat /proc/config.gz | grep -i CESA
>>> > # CONFIG_CRYPTO_DEV_MV_CESA is not set
>>> > CONFIG_CRYPTO_DEV_MARVELL_CESA=m
>>> >
>>> > Cheers,
>>> >
>>> > a+
>>> >
>>> > ps: my config is temporarily at http://natisbad.org/config-duov2-cesa
>>>
>>> I've built a vanilla 4.4.1 kernel image without any debian-specific
>>> patches but using the same oldconfig
>>> (http://heap.ovh/files/config-4.4.1.vanilla).
>>>
>>> # uname -a
>>> Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux
>>>
>>> # modprobe marvell_cesa allhwsupport=1
>>>
>>> # dmesg | tail -n1
>>> [  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12
>>>
>>> The dtb hasn't changed:
>>> # diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
>>> Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical
>>>
>>> I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
>>> and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1
>>>
>>> Perhaps I am missing something obvious? I suppose the next step would
>>> be to build a minimal kernel based on the config for the duov2?
>>
>> As you have built your own kernel, may I suggest that you add some
>> debug code into mv_cesa_dev_dma_init(), mv_cesa_get_sram(), and
>> mv_cesa_probe() to print which of the many locations that returns
>> -ENOMEM is triggering the above error.
>>
>> In passing, I notice that:
>>
>>         cesa->regs = devm_ioremap_resource(dev, res);
>>         if (IS_ERR(cesa->regs))
>>                 return -ENOMEM;
>>
>> is wrong.  devm_ioremap_resource() returns an errno-encoded pointer
>> which should be used to report the error number.  This should be:
>>
>>         cesa->regs = devm_ioremap_resource(dev, res);
>>         if (IS_ERR(cesa->regs))
>>                 return PTR_ERR(cesa->regs);
>>
>> --
>> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
>> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
>> according to speedtest.net.

I have made some progress on this, apparently there is some weird
interaction between the old and new cesa modules.

# diff /boot/config-4.4.0-1-marvell /boot/config-4.4.6.test2
35c35
< CONFIG_LOCALVERSION=""
---
> CONFIG_LOCALVERSION=".test2"
6196c6196
< CONFIG_CRYPTO_DEV_MV_CESA=m
---
> # CONFIG_CRYPTO_DEV_MV_CESA is not set

Building the kernel with only the new marvell_cesa module is in fact
sufficient for having it register successfully:

dmesg | grep -i cesa
[    8.056151] marvell-cesa f1030000.crypto: CESA device successfully registered

With the default debian config [1] both mv_cesa and marvell_cesa are
built as modules. During boot, mv_cesa is registered first, but
marvell_cesa also silently loads (nothing in dmesg) and appears in
lsmod.

Doing rmmod mv_cesa; rmmod marvell_cesa; modprobe marvell_cesa
allhwsupport=1; dmesg | tail -n 1 results in the previously described:

[  920.383498] marvell-cesa: probe of f1030000.crypto failed with error -12


I tried to blacklist mv_cesa by adding the following to /etc/modprobe.d/local :
blacklist mv_cesa
install mv_cesa /bin/false

However, after rebuilding initramfs, reflashing and rebooting, both
mv_cesa and marvell_cesa (silently) still get loaded... I have no
explanation for that, maybe it's a userspace or PEBKAC problem.
I hope this will point you in the right direction as to this weird issue.

Best regards,
Jan

1. https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/config/config?id=42fd34bcd1d54c7bc8d9783479990041f46efa8e
+
https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/config/armel/config.marvell?id=42fd34bcd1d54c7bc8d9783479990041f46efa8e

marvell_cesa fails to register on kirkwood (88F6282)

[JM]

On Fri, Feb 5, 2016 at 9:41 PM, Arnaud Ebalard <arno@natisbad.org> wrote:
> Hi guys,
>
> Gregory CLEMENT <gregory.clement@free-electrons.com> writes:
>
>> Hi,
>>
>> +cc Arnaud
>>
>>  On ven., f?vr. 05 2016, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>>
>>> Hi JM,
>>>
>>>  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>>>
>>>> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
>>>> <gregory.clement@free-electrons.com> wrote:
>>>>> Hi JM,
>>>>>
>>>>>  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>>>>>
>>>>>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>>>>>> <boris.brezillon@free-electrons.com> wrote:
>>>>>>> Jan, Andrew
>>>>>>>
>>>>>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>>>>>> Andrew Lunn <andrew@lunn.ch> wrote:
>>>>>>>
>>>>>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>>>>>> > 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.
>>>>
>>>
>>>> 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?
>
> Here is the result I get on my ReadyNAS Duo v2 (88F6282, see below) w/ a
> stock 4.4 kernel I just cross-compiled w/ a gcc 4.9.2. The kernel has no
> modules and uses an appended DTB (u-boot on the platform is pretyy old):
>
> root at mood:~# dmesg | grep -i cesa
> [    3.306135] marvell-cesa f1030000.crypto: CESA device successfully registered
>
> root at mood:~# uname -a
> Linux mood 4.4.0.duov2 #1 Fri Feb 5 21:11:25 CET 2016 armv5tel GNU/Linux
>
> root at mood:~# cat /proc/cpuinfo
> processor       : 0
> model name      : Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS        : 1594.16
> Features        : swp half thumb fastmult edsp
> CPU implementer : 0x56
> CPU architecture: 5TE
> CPU variant     : 0x2
> CPU part        : 0x131
> CPU revision    : 1
>
> Hardware        : Marvell Kirkwood (Flattened Device Tree)
> Revision        : 0000
> Serial          : 0000000000000000
>
> I'll try and do the same now w/ CESA support compiled as module to see
> what I get. I'll keep you posted.
>
> As a side note, a simple grep on the .config file you provided at
> http://pastebin.com/40eKMJqE makes me wonder why it has some
> grsec options residue. Did you test on a stock 4.4 kernel or on
> something w/ additional patches? If the latter, could you check what a
> stock kernel gives?
>
> Cheers,
>
> a+

Thanks for the reply. Your cpuinfo is exactly the same as mine. I am
using the kernel as shipped by Debian (4.4 from experimental). I was
directed from a Debian ARM mailing list to report to upstream, but
perhaps it is a distribution-specific bug. I will try to build a
vanilla kernel, although that will take me some time (no
cross-compilation environment at hand). I will keep you posted.

Best regards,
Jan

marvell_cesa fails to register on kirkwood (88F6282)

[Boris Brezillon]

On Fri, 5 Feb 2016 17:01:45 +0100
JM <fijam@archlinux.us> wrote:

> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
> > Hi JM,
> >
> >  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
> >
> >> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
> >> <boris.brezillon@free-electrons.com> wrote:
> >>> Jan, Andrew
> >>>
> >>> On Fri, 5 Feb 2016 10:02:46 +0100
> >>> Andrew Lunn <andrew@lunn.ch> wrote:
> >>>
> >>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
> >>>> > 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.
> >
> > Gregory
> >
> >
> >>
> >> Best regards,
> >> Jan
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> > --
> > Gregory Clement, Free Electrons
> > Kernel, drivers, real-time and embedded Linux
> > development, consulting, training and support.
> > http://free-electrons.com
> 
> Hi,
> 
> 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

Can you try to apply this patch [1], and let me know where it fails?

[1]http://code.bulix.org/qnuq8m-90700




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

marvell_cesa fails to register on kirkwood (88F6282)

[JM]

On Fri, Feb 5, 2016 at 5:28 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Fri, 5 Feb 2016 17:01:45 +0100
> JM <fijam@archlinux.us> wrote:
>
>> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
>> <gregory.clement@free-electrons.com> wrote:
>> > Hi JM,
>> >
>> >  On ven., f?vr. 05 2016, JM <fijam@archlinux.us> wrote:
>> >
>> >> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>> >> <boris.brezillon@free-electrons.com> wrote:
>> >>> Jan, Andrew
>> >>>
>> >>> On Fri, 5 Feb 2016 10:02:46 +0100
>> >>> Andrew Lunn <andrew@lunn.ch> wrote:
>> >>>
>> >>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>> >>>> > 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.
>> >
>> > Gregory
>> >
>> >
>> >>
>> >> Best regards,
>> >> Jan
>> >>
>> >> _______________________________________________
>> >> linux-arm-kernel mailing list
>> >> linux-arm-kernel at lists.infradead.org
>> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >
>> > --
>> > Gregory Clement, Free Electrons
>> > Kernel, drivers, real-time and embedded Linux
>> > development, consulting, training and support.
>> > http://free-electrons.com
>>
>> Hi,
>>
>> 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
>
> Can you try to apply this patch [1], and let me know where it fails?
>
> [1]http://code.bulix.org/qnuq8m-90700
>
>
>
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Hello again,

With the patch applied (I had to add struct device *dev = cesa->dev;
under static int mv_cesa_get_sram or I'd get error: ?dev? undeclared
during compilation, hope that's correct)
I am getting the following:

[53595.279886] marvell-cesa f1030000.crypto: failed get SRAM region
[53595.289485] marvell-cesa: probe of f1030000.crypto failed with error -12

Best regards,
Jan

marvell_cesa fails to register on kirkwood (88F6282)

[Fabio Estevam]

On Fri, Feb 5, 2016 at 3:01 AM, JM <fijam@archlinux.us> wrote:
> 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

It seems like this is the similar issue I saw with the sahara driver.

Could you try a fix like this?
http://www.spinics.net/lists/linux-crypto/msg18393.html

marvell_cesa fails to register on kirkwood (88F6282)

[Boris Brezillon]

On Fri, 5 Feb 2016 13:58:23 -0200
Fabio Estevam <festevam@gmail.com> wrote:

> On Fri, Feb 5, 2016 at 3:01 AM, JM <fijam@archlinux.us> wrote:
> > 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
> 
> It seems like this is the similar issue I saw with the sahara driver.
> 
> Could you try a fix like this?
> http://www.spinics.net/lists/linux-crypto/msg18393.html

Hm, this should be fixed in 4.4, and Jan reports an ENOMEM error not
EINVAL (note that getting ENOTSUPP if allhwsupport is not set to 1 is
expected).

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