Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Date:   Wed, 1 Nov 2023 16:20:08 -0400
From:   Ben Wolsieffer <ben.wolsieffer@hefring.com>
To:     Mark Brown <broonie@kernel.org>
Cc:     linux-kernel@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Ben Whitten <ben.whitten@gmail.com>
Subject: Re: [PATCH] regmap: prevent noinc writes from clobbering cache
Message-ID: <ZUKy-ETSbM7yNvNK@dell-precision-5540>
References: <20231101142926.2722603-2-ben.wolsieffer@hefring.com>
 <b0e8c9f5-7aff-4adc-b5bc-d61c6107c07f@sirena.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b0e8c9f5-7aff-4adc-b5bc-d61c6107c07f@sirena.org.uk>
Precedence: bulk

Hi Mark,

On Wed, Nov 01, 2023 at 05:05:39PM +0000, Mark Brown wrote:
> On Wed, Nov 01, 2023 at 10:29:27AM -0400, Ben Wolsieffer wrote:
> > Currently, noinc writes are cached as if they were standard incrementing
> > writes, overwriting unrelated register values in the cache. Instead, we
> > want to cache the last value written to the register, as is done in the
> > accelerated noinc handler (regmap_noinc_readwrite).
> 
> Could you please add a kunit test for this?

I started to look into this, but it is not currently possible to test
noinc behavior with regmap_[raw_]ram. The same bulk write operation is
used by both incrementing and non-incrementing writes, and the difference
in behavior is due to how the hardware handles the bulk write to a
particular register.

To test this behavior, regmap_raw_ram (raw because it supports bulk
writes) would have to be told that certain of its registers should
implement noinc semantics.

Is this something I should implement?

Thanks, Ben