Hi Herbert,
another one, different than the first report
[71972.773115] page:ea0001fabf40 count:0 mapcount:0 mapping:
(null) index:0x0
[71972.773118] flags: 0x1c()
[71972.773119] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
[71972.773140]
Hi Herbert,
here is a reliably producable bug that I triggered while educating my libkcapi
about AIO support.
[70129.671557] page:ea0001361d80 count:0 mapcount:0 mapping:
(null) index:0x0
[70129.671560] flags: 0x1c()
[70129.671562] page dumped because: VM_BUG_ON_PAGE(
> > + ret = clk_set_rate(qce->core_src, 1);
>
> Could you point me from where you got this number?
I got it from codeaurora qce driver:
https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-kk-r1/drivers/crypto/msm/qce50.c#3386
--
To unsubscribe from this list: se
On Wed, Sep 07, 2016 at 04:04:01PM +0300, Stanimir Varbanov wrote:
> Hi Iaroslav,
>
> On 09/03/2016 07:45 PM, Iaroslav Gridin wrote:
> > Without that, QCE performance is about 2x less.
>
> On which platform? The clock rates are per SoC.
Dragonboard 8074. Should clock rate be moved to its DT?
>
So far, this driver was only used for OMAP SoCs. However, if a device
variant is added for an IP block that has nothing to do with the OMAP
platform, the message "OMAP Random Number Generator Ver" is displayed
anyway. Instead of hardcoding "OMAP" into this message, we decide to
only display "Random
So far, this driver only supports up to 64 bits of output data generated
by an RNG. Some IP blocks, like the SafeXcel IP-76 supports up to 128
bits of output data. This commits renames registers descriptions
OUTPUT_L_REG and OUTPUT_H_REG to OUTPUT_0_REG and OUPUT_1_REG,
respectively. It also adds t
This commits adds a device variant for Safexcel,EIP76 found in Marvell
Armada 8k. It defines registers mapping with the good offset and add a
specific initialization function.
Signed-off-by: Romain Perier
---
Changes in v2:
- Call pm_runtime_put_sync from the label err_register. When there is a
This commits add missing fields in the documentation that are used
by the new device variant. It also includes DT example to show how
the variant should be used.
Signed-off-by: Romain Perier
---
Documentation/devicetree/bindings/rng/omap_rng.txt | 14 --
1 file changed, 12 insertions
This commits adds a vendor for the company INSIDE Secure.
See https://www.insidesecure.com, for more details.
Signed-off-by: Romain Perier
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefix
This commits adds the devicetree description of the SafeXcel IP-76 TRNG
found in the two Armada CP110.
Signed-off-by: Romain Perier
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 8
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 8
2 files changed, 16 insert
The ".data_present" and ".data_read" operations are marked as
OBSOLETE in the hwrng API. We have to use the ".read" operation instead.
It makes the driver simpler and removes the need to do a busy loop to
wait until enough data is generated by the IP. We simplify this step by
only checking the stat
The omap-rng driver currently assumes that there will only ever be a
single instance of an RNG device. For this reason, there is a statically
allocated struct hwrng, with a fixed name. However, registering two
struct hwrng with the same isn't accepted by the RNG framework, so we
need to switch to a
The driver omap-rng has a lot of similarity with the IP block SafeXcel
IP-76. A lot of registers are the same and the way that the driver works
is very closed the description of the TRNG EIP76 in its datasheet.
This series refactorize the driver, add support for generating bigger
output random dat
Le 07/09/2016 16:45, PrasannaKumar Muralidharan a écrit :
On 7 September 2016 at 19:53, Romain Perier
wrote:
Hello,
Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit :
Use devm_hwrng_register instead of hwrng_register. It avoids the need
to handle unregistration explicitly from the
In core rng_buffer and rng_fillbuf is allocated in hwrng_register only
once and it is freed during module exit. This patch moves allocating
rng_buffer and rng_fillbuf from hwrng_register to rng core's init. This
avoids checking whether rng_buffer and rng_fillbuf was allocated from
every hwrng_regis
On 7 September 2016 at 19:53, Romain Perier
wrote:
> Hello,
>
>
> Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit :
>>>
>>> Use devm_hwrng_register instead of hwrng_register. It avoids the need
>>> to handle unregistration explicitly from the remove function.
>>>
>>> Signed-off-by: Romain
Hello,
Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit :
Use devm_hwrng_register instead of hwrng_register. It avoids the need
to handle unregistration explicitly from the remove function.
Signed-off-by: Romain Perier
---
drivers/char/hw_random/omap-rng.c | 4 +---
1 file changed, 1
On Mon, Sep 05, 2016 at 12:58:44PM +0100, Ard Biesheuvel wrote:
> The fact that the internal synchrous hash implementation is called
> "ghash" like the publicly visible one is causing the testmgr code
> to misidentify it as an algorithm that requires testing at boottime.
> So rename it to "__ghash"
On Mon, Sep 05, 2016 at 03:06:05PM +0300, Tero Kristo wrote:
>
> Additional request, would it be possible for you to check the rest
> of the series and just ignore patches #2 and #3 for now, the rest
> don't have any dependencies against these and can be applied cleanly
> without.
>
> I would like
On Sat, Sep 03, 2016 at 01:26:40AM +0200, Arnd Bergmann wrote:
> Drivers should not use NO_IRQ, as we are trying to get rid of that.
> In this case, the call to irq_of_parse_and_map() is both wrong
> (as it returns '0' on failure, not NO_IRQ) and unnecessary
> (as platform_get_irq() does the same t
On Sun, Sep 04, 2016 at 11:43:08PM +0530, PrasannaKumar Muralidharan wrote:
> Use devm_ioremap and devm_hwrng_register instead of ioremap and
> hwrng_register. This removes unregistering and error handling code.
>
> Changes in v2:
> Remove hardcoded resource size in ioremap, use resource struct ob
On Fri, Sep 02, 2016 at 11:48:53AM +0200, Quentin Lambert wrote:
> ccp_dmaengine_register used to return with an error code before
> releasing all resource. This patch adds a jump to the appropriate label
> ensuring that the resources are properly released before returning.
>
> This issue was foun
On Thu, Sep 01, 2016 at 02:25:40PM +0100, Ard Biesheuvel wrote:
> Patch #1 fixes a trivial code generation issue on ARM.
>
> Patch #2 and #3 fix the broken GHASH on ARM using the v8 Crypto Extensions
> pmull.64 instructions. The problem seems to be that it is allowed to call
> .import() without .i
On Wed, Aug 31, 2016 at 03:57:55PM +0300, Catalin Vasile wrote:
> -nonce is being loaded using append_load_imm_u32() instead of
> append_load_as_imm() (nonce is a byte array / stream, not a 4-byte
> variable)
> -counter is not being added in big endian format, as mandatated by
> RFC3686 and expecte
On Wed, Aug 31, 2016 at 02:02:56PM +0200, Corentin Labbe wrote:
> Hello
>
> I wanted to use the crypto engine for my Allwinner crypto driver but something
> prevented me to use it: it cannot enqueue hash requests.
> This patch convert crypto engine to permit enqueuing of ahash_requests.
> It also
On Tue, Aug 30, 2016 at 06:56:00PM +0100, Giovanni Cabiddu wrote:
> From: Maksim Lukoshkov
>
> Fix incorrect value of ADF_C3XXX_ACCELERATORS_MASK.
>
> Signed-off-by: Maksim Lukoshkov
> Signed-off-by: Giovanni Cabiddu
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apan
On Mon, Aug 29, 2016 at 10:40:16PM +0530, Arvind Yadav wrote:
> Check return value of of_iomap and handle errors correctly.
>
> Signed-off-by: Arvind Yadav
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/
On Wed, Sep 07, 2016 at 06:44:32PM +0530, PrasannaKumar Muralidharan wrote:
>
> Ah, yes! I can send a revised patch.
> Do you think allocating rng_buffer, rng_fillbuf in module init useful?
> If not there is no point in sending a new patch with fix.
Yes I think it makes sense. Those who want to s
> On Sun, Sep 04, 2016 at 01:59:38PM +0530, PrasannaKumar Muralidharan wrote:
>>
>> @@ -573,6 +557,17 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
>>
>> static int __init hwrng_modinit(void)
>> {
>> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
>> + rng_buffer = kmall
Hi Iaroslav,
On 09/03/2016 07:45 PM, Iaroslav Gridin wrote:
> Without that, QCE performance is about 2x less.
On which platform? The clock rates are per SoC.
>
> Signed-off-by: Iaroslav Gridin
> ---
> drivers/crypto/qce/core.c | 18 +-
> drivers/crypto/qce/core.h | 2 +-
> 2
On Sat, Sep 03, 2016 at 11:29:30AM +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/crypto/caam/ctrl.c:398:5: warning: no previous prototype for
> 'caam_get_era' [-Wmissing-prototypes]
>
> In fact, this function is declared in drivers/crypto/caam/ctrl.h
> and b
On Sun, Sep 04, 2016 at 01:59:38PM +0530, PrasannaKumar Muralidharan wrote:
>
> @@ -573,6 +557,17 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
>
> static int __init hwrng_modinit(void)
> {
> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
> + rng_buffer = kmalloc(rng_
On Sat, Sep 03, 2016 at 07:45:35PM +0300, Iaroslav Gridin wrote:
>
> @@ -247,6 +261,8 @@ err_clks_iface:
> clk_disable_unprepare(qce->iface);
> err_clks_core:
> clk_disable_unprepare(qce->core);
> +err_clks_core_src:
> + clk_disable_unprepare(qce->core_src);
What about qce_crypto_
On Wed, Sep 07, 2016 at 12:08:10AM +0800, Herbert Xu wrote:
>
> > So, should echainiv use a per-context per-cpu array instead that --
> > for simplicity -- gets initialised with random bytes and will be
> > updated as it's now, just not with a single global per-cpu array, but
> > a per-context one?
34 matches
Mail list logo
