Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • L linux-vs
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • linux-arm
  • linux-vs
  • Repository
Switch branch/tag
  • linux-vs
  • drivers
  • spi
  • spi.c
Find file BlameHistoryPermalink
  • Lukas Wunner's avatar
    spi: Guarantee cacheline alignment of driver-private data · 229e6af1
    Lukas Wunner authored Sep 11, 2019 and Mark Brown's avatar Mark Brown committed Sep 11, 2019
    
    
    __spi_alloc_controller() uses a single allocation to accommodate struct
    spi_controller and the driver-private data, but places the latter behind
    the former.  This order does not guarantee cacheline alignment of the
    driver-private data.  (It does guarantee cacheline alignment of struct
    spi_controller but the structure doesn't make any use of that property.)
    
    Round up struct spi_controller to cacheline size.  A forthcoming commit
    leverages this to grant DMA access to driver-private data of the BCM2835
    SPI master.
    
    An alternative, less economical approach would be to use two allocations.
    
    A third approach consists of reversing the order to conserve memory.
    But Mark Brown is concerned that it may result in a performance penalty
    on architectures that don't like unaligned accesses.
    Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
    Link: https://lore.kernel.org/r/01625b9b26b93417fb09d2c15ad02dfe9cdbbbe5.1568187525.git.lukas@wunner.de
    
    Signed-off-by: Mark Brown's avatarMark Brown <broonie@kernel.org>
    229e6af1