On 05/27/2016 05:11 AM, Baolin Wang wrote:
+/*
+ * Map a bio to scatterlist, return number of sg entries setup. Caller must
+ * make sure sg can hold bio segments entries.
+ */
+int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist)
+{
+
On 05/27/2016 05:11 AM, Baolin Wang wrote:
In dm-crypt, it need to map one bio to scatterlist for improving the
hardware engine encryption efficiency. Thus this patch introduces the
blk_bio_map_sg() function to map one bio with scatterlists.
For avoiding the duplicated code in __blk_bios_map_sg(
Two patches to add support for the Araneus Alea I USB RNG to the
chaoskey driver. The first simply includes the Alea I as a device,
the second fixes an issue with the timeout on the first read.
Bob Ham (2):
hwrng: chaoskey - Add support for Araneus Alea I USB RNG
hwrng: chaoskey - Fix URB war
The first read on an Alea takes about 1.8 seconds, more than the
timeout value waiting for the read. As a consequence, later URB reuse
causes the warning given below. To avoid this, we increase the wait
time for the first read on the Alea.
[ 78.293247] WARNING: CPU: 3 PID: 1892 at drivers/usb/
Adds support for the Araneus Alea I USB hardware Random Number
Generator which is interfaced with in exactly the same way as the
Altus Metrum ChaosKey. We just add the appropriate device ID and
modify the config help text.
Signed-off-by: Bob Ham
---
drivers/usb/misc/Kconfig| 11 ++-
On 3 June 2016 at 18:09, Herbert Xu wrote:
> On Fri, Jun 03, 2016 at 05:23:59PM +0800, Baolin Wang wrote:
>>
>> Assuming one 64K size bio coming, we can map the whole bio with one sg
>> table in crypt_convert_bulk_block() function. But if we send this bulk
>> request to crypto layer, we should div
On Fri, Jun 03, 2016 at 08:42:31AM +0200, Stephan Mueller wrote:
>
> Herbert, when using crypto_spawn_*, is there a flag set by the crypto API
> that
> the to-be-instantiated cipher is invoked by the kernel crypto API instead of
> by a user? I would assume that the INTERNAL flag could be of rele
On Fri, Jun 03, 2016 at 05:23:59PM +0800, Baolin Wang wrote:
>
> Assuming one 64K size bio coming, we can map the whole bio with one sg
> table in crypt_convert_bulk_block() function. But if we send this bulk
> request to crypto layer, we should divide the bulk request into small
> requests, and ea
On 3 June 2016 at 16:21, Herbert Xu wrote:
> On Fri, Jun 03, 2016 at 04:15:28PM +0800, Baolin Wang wrote:
>>
>> Suppose the cbc(aes) algorithm, which can not be handled through bulk
>> interface, it need to map the data sector by sector.
>> If we also handle the cbc(aes) algorithm with bulk interf
Hello
I have some minor comments below
> +config HW_RANDOM_MESON
> + tristate "Amlogic Meson Random Number Generator support"
> + depends on HW_RANDOM && ARCH_MESON
Perhaps you could change to:
depends on HW_RANDOM
depends on ARCH_MESON || COMPILE_TEST
> +
> +static int meson_rng_read(s
Add support for the Amlogic Meson SoCs hardware random generator.
Signed-off-by: Neil Armstrong
---
drivers/char/hw_random/Kconfig | 13
drivers/char/hw_random/Makefile| 1 +
drivers/char/hw_random/meson-rng.c | 128 +
3 files changed, 142 inse
Add support for the Amlogic Meson SoCs Hardware Random generator as a hw_random
char driver.
The generator is a single 32bit wide register.
Also adds the Meson GXBB SoC DTSI node and corresponding DT bindings.
Neil Armstrong (3):
char: hw_random: Add Amlogic Meson Hardware Random Generator
dt
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/rng/amlogic,meson-rng.txt | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 832815d..8353621 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g
On Fri, Jun 03, 2016 at 04:15:28PM +0800, Baolin Wang wrote:
>
> Suppose the cbc(aes) algorithm, which can not be handled through bulk
> interface, it need to map the data sector by sector.
> If we also handle the cbc(aes) algorithm with bulk interface, we need
> to divide the sg table into sectors
On 3 June 2016 at 15:54, Herbert Xu wrote:
> On Fri, Jun 03, 2016 at 03:10:31PM +0800, Baolin Wang wrote:
>> On 3 June 2016 at 14:51, Herbert Xu wrote:
>> > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote:
>> >>
>> >> If we move the IV generation into the crypto API, we also can not
>
On Fri, Jun 03, 2016 at 03:10:31PM +0800, Baolin Wang wrote:
> On 3 June 2016 at 14:51, Herbert Xu wrote:
> > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote:
> >>
> >> If we move the IV generation into the crypto API, we also can not
> >> handle every algorithm with the bulk interface
On 3 June 2016 at 14:51, Herbert Xu wrote:
> On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote:
>>
>> If we move the IV generation into the crypto API, we also can not
>> handle every algorithm with the bulk interface. Cause we also need to
>> use different methods to map one whole bio o
18 matches
Mail list logo
