driver is loaded first, then the old
one will manage to be loaded too. I think that just adding a
request_region()/release_region() (or converting the ioremap in a
devm_ioremap_resource() in the old driver would be enough.
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time
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 gregory.clem...@free-electrons.com wrote:
Hi Boris,
On 17/04/2015 10:39, Boris Brezillon wrote:
On Fri, 17
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 Gregory,
On Fri, 17 Apr 2015 15:01:01 +0200
Gregory CLEMENT
adaptation should be related
to the SRAM. It will be also needed to find a way to be able to load only one
driver
at a time: either the old or the new, but not both.
However I still wonder if it worth the effort.
Thanks,
Gregory
thx,
Jason.
--
Gregory Clement, Free Electrons
Kernel
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:32, Maxime Ripard wrote:
On Fri, Apr 17, 2015
to
mv_mbus_dram_info_nooverlap() as part of the -rc cycle.
(2) is probably easier. Herbert, what do you think?
Thomas
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
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 remember that
there was a reason
On 26/05/2015 10:59, Boris Brezillon wrote:
On Mon, 25 May 2015 17:10:37 +0200
Gregory CLEMENT gregory.clem...@free-electrons.com wrote:
Hi Boris,
On 22/05/2015 15:34, Boris Brezillon wrote:
Enable the crypto IP on armada-xp-gp.
Signed-off-by: Boris Brezillon boris.brezil...@free
Hi Boris,
On 22/05/2015 15:33, Boris Brezillon wrote:
Add crypto related nodes to armada-xp.dtsi.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
From the point of view of the mvebu it looks OK:
Acked-by: Gregory CLEMENT gregory.clem...@free-electrons.com
But of course, I
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;
--
Gregory Clement, Free Electrons
Kernel
-crypto;
+ compatible = marvell,kirkwood-crypto;
reg = MBUS_ID(0xf0, 0x01) 0x3 0x1,
MBUS_ID(0x03, 0x01) 0 0x800;
reg-names = regs, sram;
--
Gregory Clement, Free Electrons
Kernel, drivers
for armada-370-crypto.
But for this patch:
Acked-by: Gregory CLEMENT gregory.clem...@free-electrons.com
And as for the other one I will wait for that the driver will be merged before
applying it.
Thanks,
Gregory
+ marvell,crypto-srams = crypto_sram
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 unsubscribe from this list: send the line
>> +#define CESA_TDMA_IV 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
writel_relaxed(creq->state[i], engine->regs + CESA_IVDIG(i));
>
> - mv_cesa_adjust_op(engine, >op_tmpl);
> - memcpy_toio(engine->sram, >op_tmpl, sizeof(creq->op_tmpl));
> -
> if (creq->cache_ptr)
> memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFS
Armada 7040 DB
>> arm64: marvell: dts: 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) t
a4 100644
> --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> @@ -171,3 +171,7 @@
> phy = <>;
> phy-mode = "rgmii-id";
> };
> +
> +_crypto {
> + status = "okay";
> +}
interrupt-names = "mem", "ring0", "ring1",
> + "ring2", "ring3", "eip";
> + clocks = <_syscon0 1 26>;
> + status = "disabled";
> + };
> };
>
> cps_pcie0: pcie@f460 {
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
O=y
> CONFIG_CRYPTO_SHA1_ARM64_CE=y
> CONFIG_CRYPTO_SHA2_ARM64_CE=y
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
= "rgmii-id";
> };
>
> +_crypto {
> + status = "okay";
> +};
> +
> /* CON5 on CP1 expansion */
> _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
;;
> - interrupts = - | IRQ_TYPE_LEVEL_HIGH)>,
> + interrupts = ,
> ,
>,
>,
> --
> 2.9.4
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
;, "ring1",
> "ring2", "ring3", "eip";
> clocks = <_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
ct the new driver instead of the old. 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: Gre
-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
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 <gregory.c
).
Signed-off-by: Gregory CLEMENT <gregory.clem...@bootlin.com>
---
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 09adea
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 <gregory.clem...@bootlin.com>
---
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
in
Hi Herbert,
On sam., mars 24 2018, Herbert Xu <herb...@gondor.apana.org.au> 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 emb
clk_disable_unprepare() already checks that the clock pointer is valid.
No need to test it before calling it.
Signed-off-by: Gregory CLEMENT <gregory.clem...@bootlin.com>
---
drivers/char/hw_random/omap-rng.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/driver
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
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 <gregory.c
32 matches
Mail list logo
