00 {
> - compatible = "inside-secure,safexcel-eip97";
> + compatible = "inside-secure,safexcel-eip97ies";
> reg = <0x9 0x2>;
> interrupts =
; - compatible = "inside-secure,safexcel-eip197";
> + compatible = "inside-secure,safexcel-eip197b";
> reg = <0x80 0x20>;
> interrupts = ,
>
Hi Herbert,
On sam., mars 24 2018, Herbert Xu wrote:
> On Tue, Mar 13, 2018 at 05:48:39PM +0100, Gregory CLEMENT wrote:
>> Hi,
>>
>> This short series fixes the way the clocks are used for the SafeXcel
>> EIP-197 controller embedded in the Marvell Armada 7K/8K SoCs
which is aim for v4.17 as well
as the last patch.
Thanks,
Gregory
Gregory CLEMENT (3):
crypto: inside-secure - fix clock management
crypto: inside-secure - improve clock initialization
crypto: inside-secure - fix clock resource by adding a register clock
.../bindings/crypto/inside-secure
;)
cc: sta...@vger.kernel.org
Signed-off-by: Gregory CLEMENT
---
drivers/crypto/inside-secure/safexcel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/inside-secure/safexcel.c
b/drivers/crypto/inside-secure/safexcel.c
index 384b4ceb37f0..09adeaa0da6b 100644
--- a/driv
).
Signed-off-by: Gregory CLEMENT
---
drivers/crypto/inside-secure/safexcel.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/inside-secure/safexcel.c
b/drivers/crypto/inside-secure/safexcel.c
index 09adeaa0da6b..cbcb5d9f17bd 100644
--- a/drivers/crypto
On Armada 7K/8K we need to explicitly enable the register clock. This
clock is optional because not all the SoCs using this IP need it but at
least for Armada 7K/8K it is actually mandatory.
The binding documentation is updated accordingly.
Signed-off-by: Gregory CLEMENT
---
.../bindings
On Armada 7K/8K we need to explicitly enable the register clock. This
clock is optional because not all the SoCs using this IP need it but at
least for Armada 7K/8K it is actually mandatory.
The binding documentation is updating accordingly.
Signed-off-by: Gregory CLEMENT
---
Documentation
clk_disable_unprepare() already checks that the clock pointer is valid.
No need to test it before calling it.
Signed-off-by: Gregory CLEMENT
---
drivers/char/hw_random/omap-rng.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b
driver was wrong.
Thanks to this fix, it would be possible to fix the clock driver
without introducing a regression.
The first patch is just a small cleanup found when I wrote the main
patch.
Gregory CLEMENT (2):
hwrng: omap - Remove useless test before clk_disable_unprepare
hwrng: omap - Fix
be Not tainted
> 4.15.0-rc7-arm64 #1 Debian 4.15~rc7-1~exp1
> [ 140.012717] Hardware name: Marvell Armada 8040 MacchiatoBin/Armada
> 8040 MacchiatoBin, BIOS EDK II Dec 12 2017
> [ 140.012721] pstate: 4005 (nZcv daif -PAN -UAO)
> [ 140.012725] pc : __do_softirq+0xb0/0x334
> [ 140.012729] lr : irq_exit+0xc0/0xf0
> [ 140.012731] sp : 08003ed0
> [ 140.012733] x29: 08003ed0 x28: 0282
> [ 140.012739] x27: x26: 08004000
> [ 140.012744] x25: 0800 x24: 3d049fa31000
> [ 140.012749] x23: 09e93770 x22:
> [ 140.012754] x21: x20: 0003
>
> Message from syslogd@debian at Jan 9 09:58:21 ...
> kernel:[ 140.005535] watchdog: BUG: soft lockup - CPU#0 stuck for
> 22s! [modprobe:543]
> [ 140.012759] x19: 3d049fa31000 x18: 0014
> [ 140.012764] x17: 000e x16: 0007
> [ 140.012769] x15: 0001 x14:
> [ 140.012774] x13: 0033 x12:
> [ 140.012779] x11: 3d049f672150 x10: 0177
> [ 140.012784] x9 : 3d049f672158 x8 :
> [ 140.012789] x7 : 0004 x6 : a6e967d8
> [ 140.012794] x5 : 00ff x4 : 362f
> [ 140.012799] x3 : 3d049fef9980 x2 : a1aee0539000
> [ 140.012804] x1 : 3d049fef9980 x0 :
> [ 140.012809] Call trace:
> [ 140.012813] __do_softirq+0xb0/0x334
> [ 140.012816] irq_exit+0xc0/0xf0
> [ 140.012819] __handle_domain_irq+0x6c/0xc0
> [ 140.012822] gic_handle_irq+0x60/0xb0
> [ 140.012824] el1_irq+0xb0/0x140
> [ 140.012828] _raw_spin_unlock_irqrestore+0x2c/0x38
> [ 140.012831] __setup_irq+0x548/0x7f8
> [ 140.012834] request_threaded_irq+0xf0/0x1b0
> [ 140.012838] devm_request_threaded_irq+0x80/0xf8
> [ 140.012846] omap_rng_probe+0x1f4/0x418 [omap_rng]
> [ 140.012849] platform_drv_probe+0x60/0xc0
> [ 140.012853] driver_probe_device+0x33c/0x4a0
> [ 140.012857] __driver_attach+0xdc/0x128
> [ 140.012860] bus_for_each_dev+0x78/0xd8
> [ 140.012864] driver_attach+0x30/0x40
> [ 140.012867] bus_add_driver+0x218/0x2b8
> [ 140.012871] driver_register+0x6c/0x118
> [ 140.012874] __platform_driver_register+0x54/0x60
> [ 140.012879] omap_rng_driver_init+0x20/0x1000 [omap_rng]
> [ 140.012882] do_one_initcall+0x58/0x168
> [ 140.012886] do_init_module+0x64/0x1d8
> [ 140.012890] load_module.isra.36+0x20e0/0x26a8
> [ 140.012894] SyS_finit_module+0x100/0x120
> [ 140.012896] el0_svc_naked+0x20/0x24
> [ 142.049544] mmc0: Switching to 3.3V signalling voltage failed
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@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
ld. And finally we
> remove the old driver.
> These patches have to be applied in this order to make things
> bisectable, so, if this series is accepted it will have to go through
> a single tree (either ARM or crypto).
For the whole series
Acked-by: Gregory CLEMENT
And I am OK for this ser
"ring2", "ring3", "eip";
> clocks = <&cps_syscon0 1 26>;
> + dma-mask = <0xff 0x>;
> status = "disabled";
> };
> };
> --
> 2.9.4
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
,
>,
>,
> --
> 2.9.4
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
rch/arm64/configs/defconfig
> @@ -519,6 +519,7 @@ CONFIG_MEMTEST=y
> CONFIG_SECURITY=y
> CONFIG_CRYPTO_ECHAINIV=y
> CONFIG_CRYPTO_ANSI_CPRNG=y
> +CONFIG_CRYPTO_DEV_SAFEXCEL=m
> CONFIG_ARM64_CRYPTO=y
> CONFIG_CRYPTO_SHA1_ARM64_CE=y
> CONFIG_CRYPTO_SHA2_ARM64_CE=y
> -
ot;;
> +};
> +
> /* CON5 on CP1 expansion */
> &cps_pcie2 {
> status = "okay";
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
m64/boot/dts/marvell/armada-7040-db.dts
> @@ -171,3 +171,7 @@
> phy = <&phy1>;
> phy-mode = "rgmii-id";
> };
> +
> +&cpm_crypto {
> + status = "okay";
> +};
> --
> 2.11.0
>
--
Gregory Clement, Free Electron
> + ,
> + ,
> + ,
> + ,
> + ;
> + interrupt-names = "mem", "ring0",
ts: enable the crypto engine on the Armada 8040 DB
>> arm64: defconfig: enable the Safexcel crypto engine as a module
>
> I have no problems with the crypto bits.
Does it means that you agree that I apply the arm-soc related patches
(from 4 to 7) to my mvebu trees?
Thanks,
Greg
st_op(engine, &creq->op_tmpl);
> - memcpy_toio(engine->sram, &creq->op_tmpl, sizeof(creq->op_tmpl));
> -
> if (creq->cache_ptr)
> memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFSET,
> creq->cache, creq->
4
>>
>> Should be 3 and not 4: TDMA_TYPE is an enum, not a bit field.
>
> Ok
>
>>
>> Sometime it's better to offend the < 80 characters rule than doing
>> funky stuff ;).
>
> I just wanted to make checkpatch happy :D
In th
ce this driver has been merged.
Now that the driver has been merged do you plan submitting the DT support
soon?
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubs
vast majority of platforms, this is OK. It's only if you have 4 GB
> of RAM or more that it causes problem. And then we switch to
> mv_mbus_dram_info_nooverlap() as part of the -rc cycle.
>
> (2) is probably easier. Herbert, what do you think?
>
> Thomas
>
--
Hi Thomas, Boris,
On 27/05/2015 13:23, Thomas Petazzoni wrote:
> Dear Gregory CLEMENT,
>
> On Wed, 27 May 2015 12:20:49 +0200, Gregory CLEMENT wrote:
>
>> But is it really depending of the board itself?
>> I see that the first lines are the same on all the dts, I just re
On 26/05/2015 10:59, Boris Brezillon wrote:
> On Mon, 25 May 2015 17:10:37 +0200
> Gregory CLEMENT wrote:
>
>> Hi Boris,
>>
>> On 22/05/2015 15:34, Boris Brezillon wrote:
>>> Enable the crypto IP on armada-xp-gp.
>>>
>>> Signed-off-by: Bor
tible = "marvell,orion-crypto";
> + compatible = "marvell,kirkwood-crypto";
> reg = ,
> ;
> reg-names = "regs", "sram";
>
--
Gregory Clement
update the binding
documentation by adding that the clock is optional for armada-370-crypto.
But for this patch:
Acked-by: Gregory CLEMENT
And as for the other one I will wait for that the driver will be merged before
applying it.
Thanks,
Gregory
> +
Hi Boris,
On 22/05/2015 15:33, Boris Brezillon wrote:
> Add crypto related nodes to armada-xp.dtsi.
>
> Signed-off-by: Boris Brezillon
>From the point of view of the mvebu it looks OK:
Acked-by: Gregory CLEMENT
But of course, I will wait for that the driver will be merged before
0xf111 0x1>;
As the crypto engine really depend on the SoC itself and not of the board,
what about updating the dts of the other board using an Armada XP?
Thanks,
Gregory
>
> devbus-bootcs {
> status = "okay";
>
--
Greg
On 17/04/2015 17:49, Maxime Ripard wrote:
> On Fri, Apr 17, 2015 at 05:01:55PM +0200, Gregory CLEMENT wrote:
>> On 17/04/2015 16:50, Maxime Ripard wrote:
>>> On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote:
>>>> Hi Maxime,
>>>>
>
On 17/04/2015 16:50, Maxime Ripard wrote:
> On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote:
>> Hi Maxime,
>>
>> On 17/04/2015 16:32, Maxime Ripard wrote:
>>> On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote:
>>>> Hi Grego
Hi Maxime,
On 17/04/2015 16:32, Maxime Ripard wrote:
> On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote:
>> Hi Gregory,
>>
>> On Fri, 17 Apr 2015 15:01:01 +0200
>> Gregory CLEMENT wrote:
>>
>>> Hi Boris,
>>>
>>> On 17/04
map_resource() in the new driver, so if the old one
is already loaded the memory region will be already hold and the new
driver will simply fail during the probe. So for this part it is OK.
However, the old driver doesn't try to reserve the region, it directly
uses an ioremap(). So if the new driv
iver on the "old" marvell
SoCs (especially kirkwood and dove). If we go to this path, then the best
solution
would be to still update all the the dts, and modifying the old driver to be
able to
use the new binding: for my point of view the only adaptation should be related
to the SRAM.
34 matches
Mail list logo
