Commit Graph

21 Commits

Author SHA1 Message Date
Wojciech Macek
c0f1c1f8ff Fix SHA256 usage on older CESA versions
Adding SHA256 support to Marvell crypto driver resulted in regression
for older SoC's, not capable of handling this mode in hardware.

Submitted by:          Emeric Poupon <emeric.poupon@stormshield.eu>
Obtained from:         Stormshield
Sponsored by:          Stormshield
Reviewed by:           zbb
Differential revision: https://reviews.freebsd.org/D9215
2017-01-25 10:25:59 +00:00
Wojciech Macek
81526b839f Use SoC ID - based detection in CESA
This commit introduces following changes in order to get rid of
ifdef's from all around the driver.
* Introduce sc_soc_id field in cesa_softc structure - this value is
  obtained in cesa_attach() anyway, so make use of it.
* Replace ifdefs with SoC ID checks.
* Perform PM control status only for relevant SoC's.

Submitted by:          Marcin Wojtas <mw@semihalf.com>
Obtained from:         Semihalf
Sponsored by:          Stormshield
Reviewed by:           zbb
Differential revision: https://reviews.freebsd.org/D9247
2017-01-25 10:22:07 +00:00
Wojciech Macek
76b73da7ae Add misssing Armada38x ID's in CESA attach
Marvell Armada 38x is supported in 3 variants,
so take all into consideration in crypto driver
attach routine.

Submitted by:          Marcin Wojtas <mw@semihalf.com>
Obtained from:         Semihalf
Sponsored by:          Stormshield
Reviewed by:           zbb
Differential revision: https://reviews.freebsd.org/D9248
2017-01-25 06:11:07 +00:00
Zbigniew Bodek
2cf4c169db Use proper interface for FDT parsing and memory mapping in CESA
Improvements after r301220.
Bus space methods are not called so simple pmap_mapdev will suffice.
Use OF_getencprop to get buffer with already converted endianess.

Pointed out by: ian
Submitted by:   Michal Stanek <mst@semihalf.com>
Obtained from:  Semihalf
2016-06-03 18:54:16 +00:00
Zbigniew Bodek
c247b3ca67 Add support for CESA on Armada38x
Changes:
- added new SoC ID in CESA attach
- allowed crypto driver IDs other than 0
- added CESA nodes to Armada38x .dts files
- enabled required devices in kernconf

Submitted by:	Michal Stanek <mst@semihalf.com>
Obtained from:	Semihalf
Sponsored by:	Stormshield
Differential revision:	https://reviews.freebsd.org/D6220
2016-06-02 18:41:33 +00:00
Zbigniew Bodek
b07df6e5a9 Add HMAC-SHA256 support in CESA
Only HMAC-SHA256 is added as it is the only SHA-2 variant supported by
cryptodev. It is not possible to register hardware support for other
algorithms in the family including regular non-keyed SHA256.

Submitted by:	Michal Stanek <mst@semihalf.com>
Obtained from:	Semihalf
Sponsored by:	Stormshield
Differential revision:	https://reviews.freebsd.org/D6219
2016-06-02 18:39:33 +00:00
Zbigniew Bodek
1e964f8a52 Truncate HMAC output only if requested by the client
The output of HMAC was previously truncated to 12 bytes. This was only
correct in case of one particular crypto client - the new version of IPSEC.
Fix by taking into account the cri_mlen field in cryptoini session request
filled in by the client.

Submitted by:	Michal Stanek <mst@semihalf.com>
Obtained from:	Semihalf
Sponsored by:	Stormshield
Differential revision:	https://reviews.freebsd.org/D6218
2016-06-02 18:37:50 +00:00
Zbigniew Bodek
22c7a03178 Split CESA memory resource into TDMA and CESA regs
TDMA and CESA registers are placed in different ranges of memory. Split
memory resource in DTS to reflect that. This change is needed to support
multiple CESA nodes as otherwise the ranges of different nodes would
overlap.

In consequence, CESA_WRITE and CESA_READ macros have been split depending
on which range of registers is accessed. Offsets for CESA registers have
been modified as the base address has changed.

Submitted by:	Michal Stanek <mst@semihalf.com>
Obtained from:	Semihalf
Sponsored by:	Stormshield
Differential revision:	https://reviews.freebsd.org/D6217
2016-06-02 18:35:35 +00:00
Zbigniew Bodek
5188e3cca6 Map CESA SRAM memory in driver attach for Armada38x
On other platforms with CESA accelerator the SRAM memory is mapped in
early init before driver is attached. This method only works correctly
with mappings no smaller than L1 section size (1MB). There may be more
SRAM blocks and they may have smaller sizes than 1MB as is the case
for Armada38x. Instead, map SRAM memory with bus_space_map() in CESA
driver attach. Note that we can no longer assume that VA == PA for the
SRAM.

Submitted by:	Michal Stanek <mst@semihalf.com
Obtained from:	Semihalf
Sponsored by:	Stormshield
Differential revision:	https://reviews.freebsd.org/D6215
2016-06-02 18:31:36 +00:00
Pedro F. Giffuni
453130d9bf sys/dev: minor spelling fixes.
Most affect comments, very few have user-visible effects.
2016-05-03 03:41:25 +00:00
Andrew Turner
a43760692b Make the fdt_get_mem_regions memsize argument optional. It's only used in
by a few callers.

Sponsored by:	ABT Systems Ltd
2016-03-01 09:45:27 +00:00
Wojciech Macek
e571e15cb0 Fix fdt_get_mem_regions() to work with 64-bit addresses
Use u_long instead of uint32_t variables to avoid overflow
    in case of PA space bigger than 32-bit.

Obtained from:         Semihalf
Submitted by:          Michal Stanek <mst@semihalf.com>
Sponsored by:          Annapurna Labs
Approved by:           cognet (mentor)
Reviewed by:           andrew, br, wma
Differential revision: https://reviews.freebsd.org/D5393
2016-02-29 09:22:39 +00:00
Ian Lepore
add35ed5b8 Follow r261352 by updating all drivers which are children of simplebus
to check the status property in their probe routines.

Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352.  Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.

Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.
2014-02-02 19:17:28 +00:00
Eitan Adler
c8aef31d30 Similar to the (1 << 31) case it is not defined to do (2 << 30). 2013-11-30 22:16:37 +00:00
Randall Stewart
6f1dba186e Opps, my kirkwood fix for the dreamplug missed this. 2013-10-29 11:28:11 +00:00
Luiz Otavio O Souza
09b2544b71 Remove all the instances of '#undef DEBUG' from kernel.
Suggested by:	rpaulo
Approved by:	adrian (mentor)
2013-10-25 18:38:44 +00:00
Grzegorz Bernacki
99eef68204 Move initialization of CESA decoding windows from common section
to driver specific files.

- window initialization is done during device attach
- CESA TDMA decoding windows values are set based on DTS,
 not copied from CPU registers
- remove unnecessary virtual mapping
- update dts file

Obtained from: Semihalf
2013-05-06 13:34:36 +00:00
Hiroki Sato
c8953e1273 Add support for Marvell 88F6282.
Sponsored by:	Plat'Home, Co.,Ltd.
2012-07-28 21:56:24 +00:00
Scott Long
6ac6f295b0 Final pass at having devices use their bus parent for dma tags. The
remaining drivers that haven't been converted have various problems or
complexities that will be dealt with later.  This list includes:

hptrr, hptmv, hpt27xx - device aggregation across multiple parents
drm - want to talk to the maintainer first
tsec, sec - Openfirmware devices, not sure if changes are warranted
fatm - Done except for unused testing code
usb - want to talk to the maintainer first
ce, cp, ctau, cx - Significant driver changes needed to convey parent info

There are also devices tucked into architecture subtrees that I'll leave
for the respective maintainers to deal with.
2012-03-12 19:29:35 +00:00
Marius Strobl
4b7ec27007 - There's no need to overwrite the default device method with the default
one. Interestingly, these are actually the default for quite some time
  (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
  since r52045) but even recently added device drivers do this unnecessarily.
  Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
  Discussed with: jhb
- Also while at it, use __FBSDID.
2011-11-22 21:28:20 +00:00
Rafal Jaworowski
8817e1bffe Initial version of cesa(4) driver for Marvell crypto engine and security
accelerator.

The following algorithms and schemes are supported:
 - 3DES, AES, DES
 - MD5, SHA1

Obtained from:	Semihalf
Written by:	Piotr Ziecik
2011-11-19 16:30:06 +00:00