[v3,0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h

As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
its content is being used solely internally to SPI subsystem
(PXA2xx drivers). Hence this refactoring series with the additional
win of getting rid of legacy documentation.

Note, that we have the only user of a single plain integer field
in the entire kernel for that. Switching to software nodes does not
diminish any of type checking as we only pass an integer.

On top of that it includes the previously sent "spi: pxa2xx: Cleanup
(part 2)" series that makes effort to clean up even more things.

Changelog v3:
- added new patches that were previously sent separately
  (20240403171550.1074644-1-andriy.shevchenko@linux.intel.com)
- extended cover letter a bit to explain that the replacement is
  not worse than the current approach
- v2: 20240327193138.2385910-1-andriy.shevchenko@linux.intel.com

Changelog v2:
- dropped applied patches
- added patch to amend dependencies (Mark)
- amended the second patch accordingly (Mark)
- elaborated purpose of the patch 6 in the commit message (Mark)
- v1: 20240326181027.1418989-1-andriy.shevchenko@linux.intel.com

Cc: Arnd Bergmann <arnd@arndb.de>

Andy Shevchenko (9):
  spi: pxa2xx: Allow number of chip select pins to be read from property
  spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
  spi: pxa2xx: Move contents of linux/spi/pxa2xx_spi.h to a local one
  spi: pxa2xx: Remove outdated documentation
  spi: pxa2xx: Don't use "proxy" headers
  spi: pxa2xx: Drop struct pxa2xx_spi_chip
  spi: pxa2xx: Remove DMA parameters from struct chip_data
  spi: pxa2xx: Remove timeout field from struct chip_data
  spi: pxa2xx: Don't provide struct chip_data for others

 Documentation/spi/pxa2xx.rst   | 208 ---------------------------------
 arch/arm/mach-pxa/spitz.c      |  25 ++--
 drivers/spi/Kconfig            |   3 +-
 drivers/spi/spi-pxa2xx-dma.c   |  38 ++----
 drivers/spi/spi-pxa2xx-pci.c   |  10 +-
 drivers/spi/spi-pxa2xx.c       |  94 +++++----------
 drivers/spi/spi-pxa2xx.h       |  42 +++----
 include/linux/spi/pxa2xx_spi.h |  48 --------
 8 files changed, 87 insertions(+), 381 deletions(-)
 delete mode 100644 Documentation/spi/pxa2xx.rst
 delete mode 100644 include/linux/spi/pxa2xx_spi.h

On Wed, Apr 17, 2024 at 01:54:27PM +0300, Andy Shevchenko wrote:
> As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
> its content is being used solely internally to SPI subsystem
> (PXA2xx drivers). Hence this refactoring series with the additional
> win of getting rid of legacy documentation.
> 
> Note, that we have the only user of a single plain integer field
> in the entire kernel for that. Switching to software nodes does not
> diminish any of type checking as we only pass an integer.
> 
> On top of that it includes the previously sent "spi: pxa2xx: Cleanup
> (part 2)" series that makes effort to clean up even more things.

Any chance to have a fresh look at this?

On Thu, Apr 25, 2024 at 02:40:29PM +0300, Andy Shevchenko wrote:

> Any chance to have a fresh look at this?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.

On Wed, 17 Apr 2024 13:54:27 +0300, Andy Shevchenko wrote:
> As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
> its content is being used solely internally to SPI subsystem
> (PXA2xx drivers). Hence this refactoring series with the additional
> win of getting rid of legacy documentation.
> 
> Note, that we have the only user of a single plain integer field
> in the entire kernel for that. Switching to software nodes does not
> diminish any of type checking as we only pass an integer.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/9] spi: pxa2xx: Allow number of chip select pins to be read from property
      commit: 2c547549ac69380bb03b495c5ef3dbc03c9c7a48
[2/9] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
      commit: 11346db50616698b04da44a62d4fac17d9227a62
[3/9] spi: pxa2xx: Move contents of linux/spi/pxa2xx_spi.h to a local one
      commit: 2a45166938f145294b73445b0af997b3100f02b4
[4/9] spi: pxa2xx: Remove outdated documentation
      commit: 2d069c11e8229e9f380af0c3bffe4b95cd2cf9ec
[5/9] spi: pxa2xx: Don't use "proxy" headers
      commit: 4091770969bffba9dcb071b81d4010331d4dbee7
[6/9] spi: pxa2xx: Drop struct pxa2xx_spi_chip
      commit: 513525e99898a722b365ceda6c5a2e4c83adda89
[7/9] spi: pxa2xx: Remove DMA parameters from struct chip_data
      commit: 5c5de36d04cd848587f21c0c872682476d5df8e5
[8/9] spi: pxa2xx: Remove timeout field from struct chip_data
      commit: 35bf074b1d4b252d04540acc7256e4ebee5b2dd5
[9/9] spi: pxa2xx: Don't provide struct chip_data for others
      commit: b5ec3986da5d928e4fd9ed24b5d367c4b420f1d4

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark