linux-kernel - Re: Using regmap_update_bits to update a write only register

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Mar 2015 19:26:42 +0200
From:	Daniel Baluta <daniel.baluta@...il.com>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	Mark Brown <broonie@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Using regmap_update_bits to update a write only register

On Fri, Mar 6, 2015 at 3:27 PM, Daniel Baluta <daniel.baluta@...il.com> wrote:
> On Fri, Mar 6, 2015 at 2:45 PM, Lars-Peter Clausen <lars@...afoo.de> wrote:
>> On 03/06/2015 12:21 PM, Mark Brown wrote:
>>>
>>> On Thu, Mar 05, 2015 at 08:14:14PM +0200, Daniel Baluta wrote:
>>>>
>>>> On Mar 5, 2015 7:54 PM, "Mark Brown" <broonie@...nel.org> wrote:
>>>
>>>
>>>>> Probably, or there's a bug.  What should happen is that if the register
>>>>> default appeared successfully then the read will get statisfied from the
>>>>> cache in the manner you describe - presumably that's gone wrong somehow.
>>>>> Have you set num_reg_defaults?  That's the obvious thing...
>>>
>>>
>>>> Did that. I will have a closer look. Thanks for the answer.
>>>
>>>
>>> OK, the other thing that springs to mind to check is that the register
>>> didn't somehow get marked as volatile.
>
> Checked that! is_volatile_reg returns false for that register.
>
>>>
>>
>> There were some bugs in the past were non-readable register automatically
>> got marked as volatile, this has been fixed though a few months ago. Try to
>> make sure you use the latest upstream version of regmap.
>
> Thanks for pointing this out. I am using 3.19. Changing from
> REGCACHE_RBTREE to REGCACHE_FLAT fixed the problem for me.
>
> I will update my sources and try again with REGCACHE_RBTREE when
> I'll have some time.

You can find the reference code snippet for this problem here:

http://pastebin.com/vxFKqqyV

As you can see at line 45 is the definition for reg_default.

As far as I noticed, this happens if the reg addresses in the array
are not sorted.

I can reproduce the problem with:

static struct reg_default xxx_reg_defaults[] = {
        { XXX_REG_CTRL0,  0x00 },
        { XXX_REG_CTRL1,  0x00 },
        { XXX_REG_STATUS, 0x00 },
};

but, not if the reg default definition is:

static struct reg_default xxx_reg_defaults[] = {
        { XXX_REG_STATUS, 0x00 },
        { XXX_REG_CTRL0,  0x00 },
        { XXX_REG_CTRL1,  0x00 },
  };

Is this normal?

thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/