[v2,00/20] additional driver cleanups

This is another batch of clean ups for the ccree driver.
Mostly comprised of:
- Coding Style fixes
- Move to kernel infrastructure from custom constructs
- Replace macros with static inline functions
- Removal of dead code

Changes from v1:
- Break up patches better to "do one thing" as indicated by GregKH
- Better description for some of the patches
- Better line breakup for code clarity as suggested by Joe Perches

Gilad Ben-Yossef (20):
  staging: ccree: remove spurious blank lines
  staging: ccree: replace bit shift with BIT macro
  staging: ccree: fix longer than 80 chars lines
  staging: ccree: fix operator spacing
  staging: ccree: fix comments formatting
  staging: ccree: add parentheses to macro argument
  staging: ccree: refactor HW command FIFO access
  staging: ccree: remove 48 bit dma addr sim
  staging: ccree: refactor LLI access macros
  staging: ccree: move M/LLI defines to header file
  staging: ccree: remove unused debug macros
  staging: ccree: remove cycle count debug support
  staging: ccree: move request_mgr to generic bitfield ops
  staging: ccree: remove custom bitfield macros
  staging: ccree: remove unused struct
  staging: ccree: use snake_case for hash enums
  staging: ccree: drop no longer used macro
  staging: ccree: remove dead code
  staging: ccree: remove spurious blank line
  staging: ccree: fix wrong whitespace usage

 drivers/staging/ccree/cc_bitops.h        |  35 --
 drivers/staging/ccree/cc_crypto_ctx.h    |  42 +-
 drivers/staging/ccree/cc_hw_queue_defs.h | 752 +++++++++++++-----------
 drivers/staging/ccree/cc_lli_defs.h      |  49 +-
 drivers/staging/ccree/cc_regs.h          |  74 +--
 drivers/staging/ccree/dx_crys_kernel.h   | 308 +++++-----
 drivers/staging/ccree/dx_host.h          | 256 ++++-----
 drivers/staging/ccree/hash_defs.h        |  52 +-
 drivers/staging/ccree/ssi_aead.c         | 953 ++++++++++++++-----------------
 drivers/staging/ccree/ssi_buffer_mgr.c   | 117 +---
 drivers/staging/ccree/ssi_buffer_mgr.h   |  16 -
 drivers/staging/ccree/ssi_cipher.c       | 248 ++++----
 drivers/staging/ccree/ssi_config.h       |   6 -
 drivers/staging/ccree/ssi_driver.c       |   8 -
 drivers/staging/ccree/ssi_driver.h       |  30 +-
 drivers/staging/ccree/ssi_fips_ll.c      | 704 +++++++++++------------
 drivers/staging/ccree/ssi_hash.c         | 895 ++++++++++++++---------------
 drivers/staging/ccree/ssi_ivgen.c        |  80 ++-
 drivers/staging/ccree/ssi_request_mgr.c  | 158 +----
 drivers/staging/ccree/ssi_sram_mgr.c     |   8 +-
 20 files changed, 2144 insertions(+), 2647 deletions(-)
 delete mode 100644 drivers/staging/ccree/cc_bitops.h

-- 
2.1.4

On Thu, 2017-06-01 at 14:02 +0300, Gilad Ben-Yossef wrote:
> Remove spurious blanks lines from cc_crypto_ctx.h file


unrelated trivia:

> diff --git a/drivers/staging/ccree/cc_crypto_ctx.h b/drivers/staging/ccree/cc_crypto_ctx.h

[]
> @@ -208,7 +204,6 @@ struct drv_ctx_generic {

>  	enum drv_crypto_alg alg;

>  } __attribute__((__may_alias__));


Please try to remove the __may_alias__ attribute one day.

On Thu, 2017-06-01 at 04:20 -0700, Joe Perches wrote:
> On Thu, 2017-06-01 at 14:02 +0300, Gilad Ben-Yossef wrote:

> > Remove spurious blanks lines from cc_crypto_ctx.h file

> 

> unrelated trivia:

> 

> > diff --git a/drivers/staging/ccree/cc_crypto_ctx.h b/drivers/staging/ccree/cc_crypto_ctx.h

> 

> []

> > @@ -208,7 +204,6 @@ struct drv_ctx_generic {

> >  	enum drv_crypto_alg alg;

> >  } __attribute__((__may_alias__));

> 

> Please try to remove the __may_alias__ attribute one day.


That might be easy as struct drv_ctx_generic
is not directly used anywhere.

On Sat, Jun 3, 2017 at 11:46 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jun 01, 2017 at 02:02:52PM +0300, Gilad Ben-Yossef wrote:

>> CC_CTX_SIZE was being defined using a hand rolled bit shift operation.

>> Replace with use of BIT macro.

>>

>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>

>> ---

>>  drivers/staging/ccree/cc_crypto_ctx.h | 2 +-

>>  1 file changed, 1 insertion(+), 1 deletion(-)

>

> This patch didn't apply at all, are you sure you are working against the

> correct tree?  I've tried to apply some of this series, but most do not

> work at all...

>


Yes, I did. The patch series was created against your staging/staging-next
at commit ca9280d1f82a7a0165a683dc09f182329ebec352

What I believe might have happened is that you took in Gennadii Altukhov's
and Derek Robson's patch set and mine indeed no longer applies on top of theirs.

> Please rebase against my staging-next branch and resend the ones that do

> work.


Sure, I'll rebase on top of current staging/staging-next and resend
the remaining
patches

Thanks,
Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru