10 Mar, 2014

2 commits


20 Dec, 2013

1 commit

  • Command "tcrypt sec=1 mode=403" give the follwoing error for Polling
    mode:
    root@am335x-evm:/# insmod tcrypt.ko sec=1 mode=403
    [...]

    [ 346.982754] test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 4352 opers/sec, 17825792 bytes/sec
    [ 347.992661] test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 7095 opers/sec, 29061120 bytes/sec
    [ 349.002667] test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates):
    [ 349.010882] Unable to handle kernel NULL pointer dereference at virtual address 00000000
    [ 349.020037] pgd = ddeac000
    [ 349.022884] [00000000] *pgd=9dcb4831, *pte=00000000, *ppte=00000000
    [ 349.029816] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
    [ 349.035482] Modules linked in: tcrypt(+)
    [ 349.039617] CPU: 0 PID: 1473 Comm: insmod Not tainted 3.12.4-01566-g6279006-dirty #38
    [ 349.047832] task: dda91540 ti: ddcd2000 task.ti: ddcd2000
    [ 349.053517] PC is at omap_sham_xmit_dma+0x6c/0x238
    [ 349.058544] LR is at omap_sham_xmit_dma+0x38/0x238
    [ 349.063570] pc : [] lr : [] psr: 20000013
    [ 349.063570] sp : ddcd3c78 ip : 00000000 fp : 9d8980b8
    [ 349.075610] r10: 00000000 r9 : 00000000 r8 : 00000000
    [ 349.081090] r7 : 00001000 r6 : dd898000 r5 : 00000040 r4 : ddb10550
    [ 349.087935] r3 : 00000004 r2 : 00000010 r1 : 53100080 r0 : 00000000
    [ 349.094783] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
    [ 349.102268] Control: 10c5387d Table: 9deac019 DAC: 00000015
    [ 349.108294] Process insmod (pid: 1473, stack limit = 0xddcd2248)

    [...]

    This is because polling_mode is not enabled for ctx without FLAGS_FINUP.

    For polling mode the bufcnt is made 0 unconditionally. But it should be made 0
    only if it is a final update or a total is not zero(This condition is similar
    to what is done in DMA case). Because of this wrong hashes are produced.

    Fixing the same.

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Herbert Xu

    Lokesh Vutla
     

05 Dec, 2013

1 commit

  • In omap_sham_probe() and omap_sham_remove(), 'dd->dma_lch'
    is released without checking to see if it was successfully
    requested or not. This is a bug and was identified and
    reported by Dan Carpenter here:

    http://www.spinics.net/lists/devicetree/msg11023.html

    Add code to only release 'dd->dma_lch' when its not NULL
    (that is, when it was successfully requested).

    Reported-by: Dan Carpenter
    CC: Joel Fernandes
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     

24 Nov, 2013

1 commit

  • Pull crypto update from Herbert Xu:
    - Made x86 ablk_helper generic for ARM
    - Phase out chainiv in favour of eseqiv (affects IPsec)
    - Fixed aes-cbc IV corruption on s390
    - Added constant-time crypto_memneq which replaces memcmp
    - Fixed aes-ctr in omap-aes
    - Added OMAP3 ROM RNG support
    - Add PRNG support for MSM SoC's
    - Add and use Job Ring API in caam
    - Misc fixes

    [ NOTE! This pull request was sent within the merge window, but Herbert
    has some questionable email sending setup that makes him public enemy
    #1 as far as gmail is concerned. So most of his emails seem to be
    trapped by gmail as spam, resulting in me not seeing them. - Linus ]

    * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (49 commits)
    crypto: s390 - Fix aes-cbc IV corruption
    crypto: omap-aes - Fix CTR mode counter length
    crypto: omap-sham - Add missing modalias
    padata: make the sequence counter an atomic_t
    crypto: caam - Modify the interface layers to use JR API's
    crypto: caam - Add API's to allocate/free Job Rings
    crypto: caam - Add Platform driver for Job Ring
    hwrng: msm - Add PRNG support for MSM SoC's
    ARM: DT: msm: Add Qualcomm's PRNG driver binding document
    crypto: skcipher - Use eseqiv even on UP machines
    crypto: talitos - Simplify key parsing
    crypto: picoxcell - Simplify and harden key parsing
    crypto: ixp4xx - Simplify and harden key parsing
    crypto: authencesn - Simplify key parsing
    crypto: authenc - Export key parsing helper function
    crypto: mv_cesa: remove deprecated IRQF_DISABLED
    hwrng: OMAP3 ROM Random Number Generator support
    crypto: sha256_ssse3 - also test for BMI2
    crypto: mv_cesa - Remove redundant of_match_ptr
    crypto: sahara - Remove redundant of_match_ptr
    ...

    Linus Torvalds
     

30 Oct, 2013

1 commit


24 Oct, 2013

1 commit

  • Replace some instances of of_irq_map_one()/irq_create_of_mapping() and
    of_irq_to_resource() by the simpler equivalent irq_of_parse_and_map().

    Signed-off-by: Thierry Reding
    Acked-by: Rob Herring
    [grant.likely: resolved conflicts with core code renames]
    Signed-off-by: Grant Likely

    Thierry Reding
     

21 Aug, 2013

2 commits

  • Each cycle of SHA512 operates on 32 data words where as
    SHA256 operates on 16 data words. This needs to be updated
    while configuring DMA channels. Doing the same.

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Herbert Xu

    Lokesh Vutla
     
  • For writing input buffer into DATA_IN register current driver
    has the following state machine:
    -> if input buffer < 9 : use fallback driver
    -> else if input buffer < block size : Copy input buffer into data_in regs
    -> else use dma transfer.

    In cases where requesting for DMA channels fails for some reason,
    or channel numbers are not provided in DT or platform data, probe
    also fails. Instead of returning from driver use cpu polling mode.
    In this mode processor polls on INPUT_READY bit and writes data into
    data_in regs when it equals 1. This operation is repeated until the
    length of message.

    Now the state machine looks like:
    -> if input buffer < 9 : use fallback driver
    -> else if input buffer < block size : Copy input buffer into data_in regs
    -> else if dma enabled: use dma transfer
    else use cpu polling mode.

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Herbert Xu

    Lokesh Vutla
     

01 Aug, 2013

4 commits

  • Use devm_kzalloc() to make cleanup paths simpler.

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Herbert Xu

    Lokesh Vutla
     
  • Using devm_request_irq() rather than request_irq().
    So removing free_irq() calls from the probe error
    path and the remove handler.

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Herbert Xu

    Lokesh Vutla
     
  • Add support for the OMAP5 version of the SHAM module
    that is present on OMAP5 and AM43xx SoCs.

    This module is very simialar to OMAP4 version of SHAM module,
    and adds SHA384 SHA512 hardware-accelerated hash functions to it.
    To handle the higher digest size of SHA512, few SHA512_DIGEST_i
    (i=1-16, and first 8 registers are duplicated from SHA_DIGEST_i
    registers) registers are added at the end of register set.
    So adding the above register offsets and module info in pdata.

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Herbert Xu

    Lokesh Vutla
     
  • Adding support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224
    SHA256 that the omap sha module supports.

    In order to add the support
    - Removed hard coded register offsets and passing offsets from pdata
    - Updating Flag offsets so that they can be used for SHA256 and SHA512
    - Adding the algo info.

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Herbert Xu

    Lokesh Vutla
     

24 May, 2013

1 commit


10 Mar, 2013

2 commits

  • module_platform_driver() makes the code simpler by eliminating boilerplate
    code.

    Signed-off-by: Sachin Kamat
    Signed-off-by: Herbert Xu

    Sachin Kamat
     
  • After DMA is complete, the omap_sham_finish_req function is called as
    a part of the done_task tasklet. During this its atomic and any calls
    to pm functions should not assume they wont sleep.

    The patch replaces a call to pm_runtime_put_sync (which can sleep) with
    pm_runtime_put thus fixing a kernel panic observed on AM33xx SoC during
    SHA operation.

    Tested on an AM33xx SoC device (beaglebone board).
    To reproduce the problem, used the tcrypt kernel module as:
    modprobe tcrypt sec=2 mode=403

    Signed-off-by: Joel A Fernandes
    Cc: David S. Miller
    Acked-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Joel A Fernandes
     

26 Feb, 2013

1 commit

  • Pull crypto update from Herbert Xu:
    "Here is the crypto update for 3.9:

    - Added accelerated implementation of crc32 using pclmulqdq.

    - Added test vector for fcrypt.

    - Added support for OMAP4/AM33XX cipher and hash.

    - Fixed loose crypto_user input checks.

    - Misc fixes"

    * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (43 commits)
    crypto: user - ensure user supplied strings are nul-terminated
    crypto: user - fix empty string test in report API
    crypto: user - fix info leaks in report API
    crypto: caam - Added property fsl,sec-era in SEC4.0 device tree binding.
    crypto: use ERR_CAST
    crypto: atmel-aes - adjust duplicate test
    crypto: crc32-pclmul - Kill warning on x86-32
    crypto: x86/twofish - assembler clean-ups: use ENTRY/ENDPROC, localize jump labels
    crypto: x86/sha1 - assembler clean-ups: use ENTRY/ENDPROC
    crypto: x86/serpent - use ENTRY/ENDPROC for assember functions and localize jump targets
    crypto: x86/salsa20 - assembler cleanup, use ENTRY/ENDPROC for assember functions and rename ECRYPT_* to salsa20_*
    crypto: x86/ghash - assembler clean-up: use ENDPROC at end of assember functions
    crypto: x86/crc32c - assembler clean-up: use ENTRY/ENDPROC
    crypto: cast6-avx: use ENTRY()/ENDPROC() for assembler functions
    crypto: cast5-avx: use ENTRY()/ENDPROC() for assembler functions and localize jump targets
    crypto: camellia-x86_64/aes-ni: use ENTRY()/ENDPROC() for assembler functions and localize jump targets
    crypto: blowfish-x86_64: use ENTRY()/ENDPROC() for assembler functions and localize jump targets
    crypto: aesni-intel - add ENDPROC statements for assembler functions
    crypto: x86/aes - assembler clean-ups: use ENTRY/ENDPROC, localize jump targets
    crypto: testmgr - add test vector for fcrypt
    ...

    Linus Torvalds
     

20 Jan, 2013

1 commit


12 Jan, 2013

1 commit

  • We still need to fix up few places for multiplatform support,
    but that can proceed separately. Fix the issue by making the
    problem drivers depends !ARCH_MULTIPLATFORM for now.

    The remaining pieces that are not multiplatform compatible
    for omap2+ SoCs are:

    1. Some drivers are using custom omap_dm_timer calls

    There are two drivers that are directly usign omap hardware
    timers for PWM and DSP clocking: drivers/media/rc/ir-rx51.c and
    drivers/staging/tidspbridge/core/dsp-clock.c. These can be
    fixed for multiplatform by allowing a minimal set of hardware
    timers to be accessed, and for some functionality by using the
    hrtimer framework.

    2. Hardware OMAP4_ERRATA_I688 needs to be fixed up

    This can't be enabled for multiplatform configurations in
    it's current form. It may be possible to fix it up to do
    instruction replacement early on during init. Luckily it
    looks like this errata does not seem to get hit with
    mainline kernel code alone at least currently.

    3. Legacy header needed for omap-sham.c

    Looks like it still needs mach/irqs.h for omap1 that
    does not exist for multiplatform systems. Just ifdef
    it for now.

    4. Mailbox is waiting to get moved to drivers

    Disable it for now to avoid adding a dependency to the
    mailbox patches.

    Cc: Timo Kokkonen
    Cc: Sean Young
    Cc: "Víctor Manuel Jáquez Leal"
    Cc: Laurent Pinchart
    Cc: Mauro Carvalho Chehab
    Cc: Omar Ramirez Luna
    Cc: Herbert Xu
    Cc: Greg Kroah-Hartman
    Cc: Santosh Shilimkar
    Tested-by: Ezequiel Garcia
    [tony@atomide.com: updated to disable mailbox]
    Signed-off-by: Tony Lindgren

    Tony Lindgren
     

05 Jan, 2013

9 commits

  • The OMAP4/AM33xx version of the SHAM crypto module
    supports SHA224 and SHA256 in addition to MD5 and
    SHA1 that the OMAP2 version of the module supports.

    To add this support, use the platform_data introduced
    in an ealier commit to hold the list of algorithms
    supported by the current module. The probe routine
    will use that list to register the correct algorithms.

    Note: The code being integrated is from the TI AM33xx SDK
    and was written by Greg Turner and
    Herman Schuurman (current email unknown) while at TI.

    CC: Greg Turner
    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     
  • Add support for the OMAP4 version of the SHAM module
    that is present on OMAP4 and AM33xx SoCs.

    The modules have several differences including register
    offsets, hardware XORing, and how DMA is triggered.
    To handle these differences, a platform_data structure
    is defined and contains routine pointers, register offsets,
    bit shifts within registers, and flags to indicate whether
    the hardware supports XORing and provides SHA1 results in
    big or little endian. OMAP2/OMAP3-specific routines are
    suffixed with '_omap2' and OMAP4/AM33xx routines are suffixed
    with '_omap4'.

    Note: The code being integrated is from the TI AM33xx SDK
    and was written by Greg Turner and
    Herman Schuurman (current email unknown) while at TI.

    CC: Greg Turner
    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     
  • Use the dma_request_slave_channel_compat() call instead of
    the dma_request_channel() call to request a DMA channel.
    This allows the omap-sham driver use different DMA engines.

    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     
  • Add Device Tree suport to the omap-sham crypto
    driver. Currently, only support for OMAP2 and
    OMAP3 is being added but support for OMAP4 will
    be added in a subsequent patch.

    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     
  • Remove usage of the private OMAP DMA API.
    The dmaengine API will be used instead.

    CC: Russell King
    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     
  • Add code to use the new dmaengine API alongside
    the existing DMA code that uses the private
    OMAP DMA API. The API to use is chosen by
    defining or undefining 'OMAP_SHAM_DMA_PRIVATE'.

    This is a transitional change and the code that uses
    the private DMA API will be removed in an upcoming
    commit.

    CC: Russell King
    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     
  • Add suspend/resume support to the OMAP SHAM driver.

    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     
  • Convert the omap-sham crypto driver to use the
    pm_runtime API instead of the clk API.

    CC: Kevin Hilman
    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     
  • Remove the unnecessary pr_info() call in omap_sham_mod_init().

    CC: Dmitry Kasatkin
    Signed-off-by: Mark A. Greer
    Signed-off-by: Herbert Xu

    Mark A. Greer
     

04 Jan, 2013

1 commit

  • CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
    markings need to be removed.

    This change removes the use of __devinit, __devexit_p, __devinitdata,
    and __devexit from these drivers.

    Based on patches originally written by Bill Pemberton, but redone by me
    in order to handle some of the coding style issues better, by hand.

    Cc: Bill Pemberton
    Cc: Herbert Xu
    Cc: "David S. Miller"
    Cc: Kent Yoder
    Cc: Jamie Iles
    Cc: Kim Phillips
    Cc: Shengzhou Liu
    Cc: Alex Porosanu
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

01 Dec, 2012

1 commit

  • Based on earlier discussions[1] we attempted to find a suitable
    location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
    DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
    to dmaengine is complete.

    Unfortunately that was before I was able to try to test compile
    of the ARM multiplatform builds for omap2+, and the end result
    was not very good.

    So I'm creating yet another all over the place patch to cut the
    last dependency for building omap2+ for ARM multiplatform. After
    this, we have finally removed the driver dependencies to the
    arch/arm code, except for few drivers that are being worked on.

    The other option was to make the path
    to work, but we'd have to add some new header directory to for
    multiplatform builds.

    Or we would have to manually include arch/arm/plat-omap/include
    again from arch/arm/Makefile for omap2+.

    Neither of these alternatives sound appealing as they will
    likely lead addition of various other headers exposed to the
    drivers, which we want to avoid for the multiplatform kernels.

    Since we already have a minimal include/linux/omap-dma.h,
    let's just use that instead and add a note to it to not
    use the custom omap DMA functions any longer where possible.

    Note that converting omap DMA to dmaengine depends on
    dmaengine supporting automatically incrementing the FIFO
    address at the device end, and converting all the remaining
    legacy drivers. So it's going to be few more merge windows.

    [1] https://patchwork.kernel.org/patch/1519591/#

    cc: Russell King
    cc: Kevin Hilman
    cc: "Benoît Cousson"
    cc: Herbert Xu
    cc: "David S. Miller"
    cc: Vinod Koul
    cc: Dan Williams
    cc: Mauro Carvalho Chehab
    cc: Laurent Pinchart
    cc: Guennadi Liakhovetski
    cc: David Woodhouse
    cc: Kyungmin Park
    cc: Greg Kroah-Hartman
    cc: Tomi Valkeinen
    cc: Florian Tobias Schandinat
    cc: Hans Verkuil
    cc: Vaibhav Hiremath
    cc: Lokesh Vutla
    cc: Rusty Russell
    cc: Artem Bityutskiy
    cc: Afzal Mohammed
    cc: linux-crypto@vger.kernel.org
    cc: linux-media@vger.kernel.org
    cc: linux-mtd@lists.infradead.org
    cc: linux-usb@vger.kernel.org
    cc: linux-fbdev@vger.kernel.org
    Acked-by: Felipe Balbi
    Signed-off-by: Tony Lindgren

    Tony Lindgren
     

18 Oct, 2012

1 commit


16 Oct, 2012

2 commits

  • Drivers should not use cpu_is_omap or cpu_class_is_omap macros,
    they should be private to the platform init code. And we'll be
    removing plat/cpu.h and only have a private soc.h for the
    arch/arm/*omap* code.

    This patch is intended as preparation for the core omap changes
    and removes the need to include plat/cpu.h from several drivers.
    This is needed for the ARM common zImage support.

    These changes are OK to do because:

    - omap-rng.c does not need plat/cpu.h

    - omap-aes.c and omap-sham.c get the proper platform_data
    passed to them so they don't need extra checks in the driver

    - omap-dma.c and omap-pcm.c can test the arch locally as
    omap1 and omap2 cannot be compiled together because of
    conflicting compiler flags

    Cc: Deepak Saxena
    Cc: Matt Mackall
    Cc: Herbert Xu
    Cc: David S. Miller
    Cc: Venkatraman S
    Cc: Chris Ball
    Cc: Vinod Koul
    Cc: Dan Williams
    Acked-by: Peter Ujfalusi
    Acked-by: Jarkko Nikula
    Cc: Liam Girdwood
    Cc: Mark Brown
    Cc: linux-crypto@vger.kernel.org
    Cc: linux-mmc@vger.kernel.org
    Cc: alsa-devel@alsa-project.org
    Cc: linux-kernel@vger.kernel.org
    [tony@atomide.com: mmc changes folded in to an earlier patch]
    Signed-off-by: Tony Lindgren

    Tony Lindgren
     
  • Move plat/dma.h to plat-omap/dma-omap.h as part of single
    zImage work

    Signed-off-by: Lokesh Vutla
    Signed-off-by: Tony Lindgren

    Lokesh Vutla
     

13 Jan, 2012

1 commit


30 Jun, 2011

6 commits