send the patches soon. I'm sure there will be lots of comments :)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
ICU driver, and changes the Device Tree to refer
to the ICU interrupt instead.
Therefore, I don't think the binding should reference anything else
than the usual info about the interrupts property.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Ke
ave already been merged by Grégory are wrong for
the same reason and should be fixed.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
interrupts = | IRQ_TYPE_LEVEL_HIGH)>,
Now that I look into this, does it makes sense for an interrupt to be
both an edge interrupt and a level interrupt at the same time? This
looks odd.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and
clock.
It is worth mentioning that the actual driver implementation simply
makes the clock optional in all cases, without looking at the
compatible to figure out if the clock must be there or not. But that's
just the current driver implementation. The Device Tree binding
specification can be mo
t indicated
it's actually only required for some compatible strings.
This commit fixes that, by explicitly stating that the clocks property
is only required with the inside-secure,safexcel-eip76 compatible
string.
Fixes: 52060836f79 ("dt-bindings: omap-rng: Document SafeXcel IP-76 devi
it is in fact
"Optional": some SoCs do not require a clock for this IP block.
Fixes: 52060836f79 ("dt-bindings: omap-rng: Document SafeXcel IP-76 device
variant")
Cc:
Signed-off-by: Thomas Petazzoni
---
Documentation/devicetree/bindings/rng/omap_rng.txt | 3 +++
1 file ch
es that by making the register access *after* enabling
the clock.
This issue was found by the kernelci.org testing effort.
Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76
found in Armada 8K")
Cc:
Signed-off-by: Thomas Petazzoni
---
drivers/char/hw_random/omap-r
The omap-rng driver currently uses of_clk_get() to get a reference to
the clock, but never releases that reference. This commit fixes that by
using devm_clk_get() instead.
Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76
found in Armada 8K")
Cc:
Signed-off-
g: omap - Add device variant for SafeXcel IP-76
found in Armada 8K")
Cc:
Signed-off-by: Thomas Petazzoni
---
drivers/char/hw_random/omap-rng.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng
Hello,
This small patch series brings a few fixes and improvements to the
omap_rng driver. The first fix is particularly important, as it fixes
using the driver built as a module on SoCs that require a clock for
the IP to work properly.
Thanks,
Thomas
Thomas Petazzoni (4):
hwrng: omap
omap_rng_probe()
directly.
Moreover, we make sure to bail out if we can't enable the clock. Indeed,
while the clock is optional, if a clock is present, we really want to
succeed in enabling it. And we fix the error message to fit on one line,
so that it is grep-friendly.
Signed-off-by: T
first in the series, to make
it clear that they are the two fixes that are important to merge for
the 4.8 release cycle.
> crypto: marvell - Don't hardcode block size in mv_cesa_ahash_cache_req
>
> Thomas Petazzoni (4):
> crypto: marvell: be explicit about destination in m
aud Ebalard
Cc: Herbert Xu
Cc: Russell King
Signed-off-by: Thomas Petazzoni
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..d3f47f5c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6555,6 +6555,13 @@ M: Guenter Roeck
S:
ryone who's ever touched a driver with as little as a spelling
> fix in a git commit is abhorrent.
Agreed. I myself never used get_maintainer.pl for this reason :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.co
er:1/12=8%,authored:1/12=8%,removed_lines:1/12=8%)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to maj
es of mv_cesa_queue_req() are
fixed to use this new helper function.
Reported-by: Vincent Donnefort
Fixes: db509a45339fd ("crypto: marvell/cesa - add TDMA support")
Cc: # v4.2+
Signed-off-by: Thomas Petazzoni
---
drivers/crypto/marvell/cesa.h | 27 +++
drivers/crypto/m
2/ We temporarily revert back to using mv_mbus_dram_info(). For the
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
rk on the other boards.
Of course, we need at least one tested board for each SoC, however.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe lin
ranges +=
in .dts, we simply decided to always put:
ranges =
in the .dts.
It does create some duplication, but that's the best we could do with
the existing DT infrastructure.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android
't take a reference to it from your crypto driver. The kernel will
disable it at the end of the boot. Check if crypto still works or not,
and you'll get your answer :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.
> > Is DMA support for mv_cesa still developed?
On our (Free Electrons) side, we haven't started working on the crypto
unit for Armada 370/XP/375/38x, so it's not a driver for which we have
followed the recent developments. However, it might appear on our
TODO-list at some point in the fut
22 matches
Mail list logo
