linux-toradex.git/drivers/base/regmap, branch v3.14.57

regmap: debugfs: Don't bother actually printing when calculating max length

2015-10-22T21:39:20+00:00

commit 176fc2d5770a0990eebff903ba680d2edd32e718 upstream.

The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.

Reported-by: Rasmus Villemoes 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: debugfs: Ensure we don't underflow when printing access masks

2015-10-22T21:39:20+00:00

commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 upstream.

If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.

Reported-by: Rasmus Villemoes 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

regmap: regcache-rbtree: Clean new present bits on present bitmap resize

2015-09-13T16:10:51+00:00

commit 8ef9724bf9718af81cfc5132253372f79c71b7e2 upstream.

When inserting a new register into a block, the present bit map size is
increased using krealloc. krealloc does not clear the additionally
allocated memory, leaving it filled with random values. Result is that
some registers are considered cached even though this is not the case.

Fix the problem by clearing the additionally allocated memory. Also, if
the bitmap size does not increase, do not reallocate the bitmap at all
to reduce overhead.

Fixes: 3f4ff561bc88 ("regmap: rbtree: Make cache_present bitmap per node")
Signed-off-by: Guenter Roeck 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: Fix possible shift overflow in regmap_field_init()

2015-08-03T16:29:51+00:00

commit 921cc29473a0d7c109105c1876ddb432f4a4be7d upstream.

The way the mask is generated in regmap_field_init() is wrong.
Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift
overflow while calculating the mask field.

On some 32 bits architectures, such as x86, the generated mask is 0,
instead of the expected 0xffffffff.

This patch uses GENMASK() to fix the problem, as this macro is already safe
regarding shift overflow.

Signed-off-by: Maxime Coquelin 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: Fix regmap_bulk_read in BE mode

2015-08-03T16:29:51+00:00

commit 15b8d2c41fe5839582029f65c5f7004db451cc2b upstream.

In big endian mode regmap_bulk_read gives incorrect data
for byte reads.

This is because memcpy of a single byte from an address
after full word read gives different results when
endianness differs. ie. we get little-end in LE and big-end in BE.

Signed-off-by: Arun Chandran 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: regcache-rbtree: Fix present bitmap resize

2015-04-13T12:02:59+00:00

commit 328f494d95aac8bd4896aea2328bc281053bcb71 upstream.

When inserting a new register into a block at the lower end the present
bitmap is currently shifted into the wrong direction. The effect of this is
that the bitmap becomes corrupted and registers which are present might be
reported as not present and vice versa.

Fix this by shifting left rather than right.

Fixes: 472fdec7380c("regmap: rbtree: Reduce number of nodes, take 2")
Reported-by: Daniel Baluta 
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: fix kernel hang on regmap_bulk_write with zero val_count.

2014-11-21T17:23:06+00:00

Fixes commit 2f06fa04cf35da5c24481da3ac84a2900d0b99c3 which was an
incorrect backported version of commit
d6b41cb06044a7d895db82bdd54f6e4219970510 upstream.

If val_count is zero we return -EINVAL with map->lock_arg locked, which
will deadlock the kernel next time we try to acquire this lock.

This was introduced by f5942dd ("regmap: fix possible ZERO_SIZE_PTR pointer
dereferencing error.") which improperly back-ported d6b41cb0.

This issue was found during review of Ubuntu Trusty 3.13.0-40.68 kernel to
prepare Ksplice rebootless updates.

Fixes: f5942dd ("regmap: fix possible ZERO_SIZE_PTR pointer dereferencing error.")
Signed-off-by: Quentin Casasnovas 
Signed-off-by: Greg Kroah-Hartman

regmap: fix possible ZERO_SIZE_PTR pointer dereferencing error.

2014-10-30T16:38:20+00:00

commit d6b41cb06044a7d895db82bdd54f6e4219970510 upstream.

Since we cannot make sure the 'val_count' will always be none zero
here, and then if it equals to zero, the kmemdup() will return
ZERO_SIZE_PTR, which equals to ((void *)16).

So this patch fix this with just doing the zero check before calling
kmemdup().

Signed-off-by: Xiubo Li 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: fix NULL pointer dereference in _regmap_write/read

2014-10-30T16:38:20+00:00

commit 5336be8416a71b5568d2cf54a2f2066abe9f2a53 upstream.

If LOG_DEVICE is defined and map->dev is NULL it will lead to NULL
pointer dereference. This patch fixes this issue by adding check for
dev->NULL in all such places in regmap.c

Signed-off-by: Pankaj Dubey 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: debugfs: fix possbile NULL pointer dereference

2014-10-30T16:38:20+00:00

commit 2c98e0c1cc6b8e86f1978286c3d4e0769ee9d733 upstream.

If 'map->dev' is NULL and there will lead dev_name() to be NULL pointer
dereference. So before dev_name(), we need to have check of the map->dev
pionter.

We also should make sure that the 'name' pointer shouldn't be NULL for
debugfs_create_dir(). So here using one default "dummy" debugfs name when
the 'name' pointer and 'map->dev' are both NULL.

Signed-off-by: Xiubo Li 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman