Re: [PATCH v2 00/12] regmap-irq cleanups and refactoring

Mark Brown
2022-06-30T17:27:30Z

On Thu, 23 Jun 2022 22:14:08 +0100, Aidan MacDonald wrote:
> This series is an attempt at cleaning up the regmap-irq API in order
> to simplify things and consolidate existing features, while at the
> same time generalizing it to support a wider range of hardware.
>
> There is a new system for IRQ type configuration, some tweaks to
> unmask registers so they're more intuitive and useful, and a new
> callback for calculating register addresses. There's also a few
> minor code cleanups in here.
>
> [...]

Applied to

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

Thanks!

[01/12] regmap-irq: Convert bool bitfields to unsigned int
commit: 445cbd219ac3b8f451153c210aaf97adcbf4bd02
[02/12] regmap-irq: Remove unused type_reg_stride field
commit: 53a1a16dcc972163bd5816192d5d63ae433c9e56
[03/12] regmap-irq: Cleanup sizeof(...) use in memory allocation
commit: cffc2be30288786e242bceb9fedde4dfe6ce442d
[04/12] regmap-irq: Remove an unnecessary restriction on type_in_mask
commit: 610fdd668e6af48fcae7908161d14eee3a95ec92
[05/12] regmap-irq: Remove inappropriate uses of regmap_irq_update_bits()
commit: 6b0c31747722936101d56e71e809bfd7a6a440b7
[06/12] regmap-irq: Remove mask_writeonly and regmap_irq_update_bits()
commit: ad22b3e98f9430896bd4bd8f4fbff4667f02a0c8
[07/12] regmap-irq: Refactor checks for status bulk read support
commit: f7cc5062d6e5ca439708e8403b1a622cca75adf7
[08/12] regmap-irq: Introduce config registers for irq types
commit: faa87ce9196dbb074d75bd4aecb8bacf18f19b4e
[09/12] regmap-irq: Deprecate type registers and virtual registers
commit: 9edd4f5aee8470dcfd0db04005908f61fbfae8e0
[10/12] regmap-irq: Fix inverted handling of unmask registers
commit: e8ffb12e7f065db616a3eba79ff138bececf0825
[11/12] regmap-irq: Add get_irq_reg() callback
commit: bdf9b86cd3adbbcf590ab82b74ab8554534c9b6e
[12/12] regmap-irq: Deprecate the not_fixed_stride flag
commit: 48e014ee9a61e8f4700987b82f7cb1dc3c89fa76

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