The Tegra210 ADX and AMX drivers both keep their "Byte Map N" ALSA
control state as a byte-packed u32 map[] array along with a separate
byte_mask[] bitmap. This is because the control range exposed to
userspace is [0, 256], where 256 is the "disabled" sentinel and
does not fit in a byte, so the two arrays have to be cross-checked
on every get()/put().

This series stores each slot as a u16 holding the user-visible
value directly, turning get_byte_map() into a direct return and
put_byte_map() into a compare-and-store. The hardware-facing packed
RAM word and the IN_BYTE_EN / OUT_BYTE_EN enable masks are computed
on the fly inside each write_map_ram() callback, which is the only
place that needs to know the hardware layout. The byte_mask[] field
is kept in the driver struct but allocated dynamically in probe()
using devm_kcalloc() with soc_data->byte_mask_size, and zeroed +
recomputed on each write_map_ram() call.

There is no userspace-visible ABI change. Control declarations,
ranges, initial values and handling of out-of-range writes is
preserved by treating values outside [0, 255] as disabled (256),
matching previous behavior. As a side effect each patch also fixes
a latent bug in put_byte_map() where an enabled-to-enabled value
change was not persisted.

The packed RAM word construction is also updated to ensure the shift
operates on a u32 value, avoiding potential undefined behavior due
to signed integer promotion.

Addresses TODO comments left in tegra210_{adx,amx}_get_byte_map().

Changes since v2:
 - Move byte_mask allocation back to probe() with devm_kcalloc()
   using soc_data->byte_mask_size; revert write_map_ram() to void
   and runtime_resume() to returning 0. Suggested by Jon Hunter.
 - Fix bits_per_mask: use BITS_PER_TYPE(*byte_mask) instead of the
   incorrect BITS_PER_TYPE(*map) * BITS_PER_BYTE. Reported by
   Mark Brown.
 - Drop <linux/slab.h> include (no longer needed without kfree).

Changes since v1:
 - Use dynamic sizing via soc_data->byte_mask_size instead of
   chip-specific constants. Suggested by Sheetal.
 - Replace magic numbers with TEGRA_{ADX,AMX}_SLOTS_PER_WORD
   and use BITS_PER_BYTE / BITS_PER_TYPE(). Suggested by Sheetal.
 - Add <linux/bits.h> include.

Patch 1/2: ASoC: tegra210_adx: simplify byte map get/put logic
Patch 2/2: ASoC: tegra210_amx: simplify byte map get/put logic

Piyush Patle (2):
  ASoC: tegra210_adx: simplify byte map get/put logic
  ASoC: tegra210_amx: simplify byte map get/put logic

 sound/soc/tegra/tegra210_adx.c | 85 ++++++++++++++++++----------------
 sound/soc/tegra/tegra210_adx.h |  5 +-
 sound/soc/tegra/tegra210_amx.c | 82 ++++++++++++++++----------------
 sound/soc/tegra/tegra210_amx.h |  5 +-
 4 files changed, 96 insertions(+), 81 deletions(-)

-- 
2.43.0

On Sat, 11 Apr 2026 01:35:21 +0530, Piyush Patle wrote:
> ASoC: tegra210: simplify ADX/AMX byte map get/put logic
> 
> The Tegra210 ADX and AMX drivers both keep their "Byte Map N" ALSA
> control state as a byte-packed u32 map[] array along with a separate
> byte_mask[] bitmap. This is because the control range exposed to
> userspace is [0, 256], where 256 is the "disabled" sentinel and
> does not fit in a byte, so the two arrays have to be cross-checked
> on every get()/put().
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2

Thanks!

[1/2] ASoC: tegra210_adx: simplify byte map get/put logic
      https://git.kernel.org/broonie/sound/c/0c1f5e6e7b03
[2/2] ASoC: tegra210_amx: simplify byte map get/put logic
      https://git.kernel.org/broonie/sound/c/445af52d4caa

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

On Sat, Apr 11, 2026 at 1:35 AM Piyush Patle <piyushpatle228@gmail.com> wrote:
>
> The Tegra210 ADX and AMX drivers both keep their "Byte Map N" ALSA
> control state as a byte-packed u32 map[] array along with a separate
> byte_mask[] bitmap. This is because the control range exposed to
> userspace is [0, 256], where 256 is the "disabled" sentinel and
> does not fit in a byte, so the two arrays have to be cross-checked
> on every get()/put().
>
> This series stores each slot as a u16 holding the user-visible
> value directly, turning get_byte_map() into a direct return and
> put_byte_map() into a compare-and-store. The hardware-facing packed
> RAM word and the IN_BYTE_EN / OUT_BYTE_EN enable masks are computed
> on the fly inside each write_map_ram() callback, which is the only
> place that needs to know the hardware layout. The byte_mask[] field
> is kept in the driver struct but allocated dynamically in probe()
> using devm_kcalloc() with soc_data->byte_mask_size, and zeroed +
> recomputed on each write_map_ram() call.
>
> There is no userspace-visible ABI change. Control declarations,
> ranges, initial values and handling of out-of-range writes is
> preserved by treating values outside [0, 255] as disabled (256),
> matching previous behavior. As a side effect each patch also fixes
> a latent bug in put_byte_map() where an enabled-to-enabled value
> change was not persisted.
>
> The packed RAM word construction is also updated to ensure the shift
> operates on a u32 value, avoiding potential undefined behavior due
> to signed integer promotion.
>
> Addresses TODO comments left in tegra210_{adx,amx}_get_byte_map().
>
> Changes since v2:
>  - Move byte_mask allocation back to probe() with devm_kcalloc()
>    using soc_data->byte_mask_size; revert write_map_ram() to void
>    and runtime_resume() to returning 0. Suggested by Jon Hunter.
>  - Fix bits_per_mask: use BITS_PER_TYPE(*byte_mask) instead of the
>    incorrect BITS_PER_TYPE(*map) * BITS_PER_BYTE. Reported by
>    Mark Brown.
>  - Drop <linux/slab.h> include (no longer needed without kfree).
>
> Changes since v1:
>  - Use dynamic sizing via soc_data->byte_mask_size instead of
>    chip-specific constants. Suggested by Sheetal.
>  - Replace magic numbers with TEGRA_{ADX,AMX}_SLOTS_PER_WORD
>    and use BITS_PER_BYTE / BITS_PER_TYPE(). Suggested by Sheetal.
>  - Add <linux/bits.h> include.
>
> Patch 1/2: ASoC: tegra210_adx: simplify byte map get/put logic
> Patch 2/2: ASoC: tegra210_amx: simplify byte map get/put logic
>
> Piyush Patle (2):
>   ASoC: tegra210_adx: simplify byte map get/put logic
>   ASoC: tegra210_amx: simplify byte map get/put logic
>
>  sound/soc/tegra/tegra210_adx.c | 85 ++++++++++++++++++----------------
>  sound/soc/tegra/tegra210_adx.h |  5 +-
>  sound/soc/tegra/tegra210_amx.c | 82 ++++++++++++++++----------------
>  sound/soc/tegra/tegra210_amx.h |  5 +-
>  4 files changed, 96 insertions(+), 81 deletions(-)
>
> --
> 2.43.0
>

Hey
Just a gentle ping on this patch series.

Regards,
Piyush

On Sat, Apr 18, 2026 at 07:06:36PM +0530, Piyush Patle wrote:
> On Sat, Apr 11, 2026 at 1:35 AM Piyush Patle <piyushpatle228@gmail.com> wrote:

> Just a gentle ping on this patch series.

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.