Am 14.08.19 um 15:09 schrieb Ben Whitten: > On Wed, 14 Aug 2019 at 11:01, Mark Brown <broo...@kernel.org> wrote: >> >> On Tue, Aug 13, 2019 at 10:22:51PM +0100, Ben Whitten wrote: >> >>> @@ -1489,10 +1489,11 @@ static int _regmap_raw_write_impl(struct regmap >>> *map, unsigned int reg, >>> WARN_ON(!map->bus); >>> >>> /* Check for unwritable registers before we start */ >>> - for (i = 0; i < val_len / map->format.val_bytes; i++) >>> - if (!regmap_writeable(map, >>> - reg + regmap_get_offset(map, i))) >>> - return -EINVAL; >>> + if (!regmap_writeable_noinc(map, reg)) >>> + for (i = 0; i < val_len / map->format.val_bytes; i++) >>> + if (!regmap_writeable(map, >>> + reg + regmap_get_offset(map, i))) >>> + return -EINVAL; >> >> This feels like we're getting ourselves confused about nonincrementing >> registers and probably have other breakage somewhere else - we're >> already checking for nonincrementability in regmap_write_noinc(), and >> here we're only checking if the first register in the block has that >> property which might blow up on us if there's a register in the middle >> of the block that is nonincrementable. If we're going to check this >> here I think we should check on every register, but this is >> _raw_write_impl() which is part of the call path for implementing >> regmap_noinc_write() so checking here will break the API purpose >> designed for nonincrementing writes. > > So it appeared that the last patch in this area for validating a register > block [1] broke the regmap_noinc_write use case.
Then please add a Fixes: header to your commit message, so that it gets backported to all affected upstream and downstream trees. Thanks, Andreas > Because regmap_noinc_write calls _regmap_raw_write and in > turn hits the _regmap_raw_write_impl, the val_len is the depth of the > one register to write to and not a block of registers which is assumed > by the previous check. By inserting a check that the first (and only) > register is a noinc one allows me to start writing to my FIFO again. > > I'm all for an alternative solution though if there is a cleaner approach. > > Kind regards, > Ben > > [1] https://lore.kernel.org/patchwork/patch/1057184/ > -- SUSE Linux GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)