Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1738357ybe; Tue, 3 Sep 2019 02:45:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqz3OZicSAQcm9Yu2CgHDFtZ9QBCgDnC+agIQUu+/awIIZE/L869fR9b4MwAEae3+Z02Jb+H X-Received: by 2002:a63:d84e:: with SMTP id k14mr29449015pgj.234.1567503932749; Tue, 03 Sep 2019 02:45:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567503932; cv=none; d=google.com; s=arc-20160816; b=Vg7nBflPf3RultoEZnYWaqI+5+U05US3MsawqWKxym0j8nlw5UTImx3wvyNnjONkdG TQuPfP258QPo/1sRONy1UgoEFXZKLavwicSbGRR9yjT6UtVvnhJulvOQjWbbeNTNTzpH BrN8dlOjw2Sxh+UA/iIHMnJJCE2xXxX4aulfnx4fi3vsXQfOh7v3UzsW8nOwRH9J6a/1 3S1C94vxRXQGaq5Jks8Kl1p/pwxIDgI27MD/MUG9vp65T88PTYSo2OZad/d7MjuiXJSF denzTEuNtpIOQwzccDhsHxHEzUEn2Eu1uNjG1Yujy1TIBKhT4Cf7+YXStXBH7U1DHOii vm8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0J18E0tZ/M/Swa0MUYxxRnMzuj0KjoIKolLmA5LLu3s=; b=I216KYkTChIz30ne8s3eQRR4vhj4KpYclJBE5XH5U45AQRUyI1Y/YYi4WKNqttKKV7 npIwEpHpc6C0LAeVp6GadvZzuELhbF5vILPPK5V2i9i1Eq7Y3PsFOo1iGnFzpnTCre1V Fg9JtVfvCDv8dcKWh6GF1OALIf2r/CSvp4DTXu2p94VyxrsTm9LvaFKjT8hhG617ou64 jTYM902gEglhRvDH6EGIJYV+b7fBbu/sSnt87syae/xwkM07nF1BqCjFcysD2uZS46E/ azSFdwCk/qkNWAs9beP35Eu8oQqBqk0dsho0sDPJt5NvFlKdXbak61xcsSWEX/fC1pZf ukog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="T/ttRM9O"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4si11930731plr.402.2019.09.03.02.45.15; Tue, 03 Sep 2019 02:45:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="T/ttRM9O"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728308AbfICJnN (ORCPT + 99 others); Tue, 3 Sep 2019 05:43:13 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:36873 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726631AbfICJnN (ORCPT ); Tue, 3 Sep 2019 05:43:13 -0400 Received: by mail-wm1-f66.google.com with SMTP id r195so1133203wme.2 for ; Tue, 03 Sep 2019 02:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0J18E0tZ/M/Swa0MUYxxRnMzuj0KjoIKolLmA5LLu3s=; b=T/ttRM9OHTtfzkq6pm9FFDX4XlOx+nR6jsMAwQPplwFxKY4FU81c6dnzDYIZ6R1a21 w++T6Z0eqyHOMsTFsD8OF4nn2uSESNoTCMsgz+twP5K3GjKvCIHc6FhBWegxMHNh8BWO S8TMW7e7ofYZyWIhFBjiONySFaUBe2/jgzmrBkRP1VoeIAtxf0keoWJDoq72Fs+By48F pVrNR3x05ZIhXKaX6a8bP2zKnkzjXIS87zx78+eGrvUpGJSEi3hcuSlyEr4b1fjanFY/ lwz9LOh8xJgKt3IkJH6yOYhF1xyiO8e/zSGISv2GdfmM3pGc8ZJtL4uULR9pB/jwEdDG 2iAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0J18E0tZ/M/Swa0MUYxxRnMzuj0KjoIKolLmA5LLu3s=; b=SYvuRaRqZkBUH9TycNU78YWiSs9TQgrYbURXAP1hpaa4stANJ4K0SpUUlCPvkuu9fh yKhNwfhH4cxcqvdExr4JOdX7r9AoZpgsqu7s7/pD0oxVKUSDL4GmWGRKy7dwJEKF1wzl lMGboJgNS6Fxn9EsHVevyP556Z/6lFXW4h60jlCWTIYRjoYteINnypFnxMuQs54NPNmC fYPLYXS518p11+tRrvU9CdLI4v2Kly7qoiNK/gEAXbt6uX00dQ6qoJ6yKazD4kaQFnXk +5l+axQr2rlaAKlC03431fGsZzOzoHSzEf+XJaSBj/icUi2WNX+/6jVOXo++ZCu21/Ye Ar8w== X-Gm-Message-State: APjAAAUK6wobg9Wtlcz0H0D3Pu26hqVRlAVmPzNjnyQ2Ly2i/0btoRCZ LZbpeKX/qVxYG6PEDA3FVc/aFbFWPts39Wqk9kzG8sa57t1XmA== X-Received: by 2002:a05:600c:21d1:: with SMTP id x17mr2235442wmj.123.1567503790526; Tue, 03 Sep 2019 02:43:10 -0700 (PDT) MIME-Version: 1.0 References: <20190813212251.12316-1-ben.whitten@gmail.com> <20190814100115.GF4640@sirena.co.uk> <20190814161938.GI4640@sirena.co.uk> In-Reply-To: <20190814161938.GI4640@sirena.co.uk> From: Ben Whitten Date: Tue, 3 Sep 2019 10:42:59 +0100 Message-ID: Subject: Re: [PATCH] regmap: fix writes to non incrementing registers To: Mark Brown Cc: LKML , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Greg Kroah-Hartman , "Rafael J. Wysocki" , nandor.han@vaisala.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Aug 2019 at 17:19, Mark Brown wrote: > > On Wed, Aug 14, 2019 at 02:09:11PM +0100, Ben Whitten wrote: > > > So it appeared that the last patch in this area for validating a register > > block [1] broke the regmap_noinc_write use case. > > Please include human readable descriptions of things like commits and > issues being discussed in e-mail in your mails, this makes them much > easier for humans to read especially when they have no internet access. > I do frequently catch up on my mail on flights or while otherwise > travelling so this is even more pressing for me than just being about > making things a bit easier to read. Sure thing, the patch adds in a call which checks if range of registers is writeable within _regmap_raw_write_impl. This check uses the length of the data given to _regmap_raw_write_impl to determine the range of registers to check from the given starting register. > > 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. > > Like I said if we're checking for nonincrementing registers it shouldn't > just be on the first register, it should be for every address in the > range. Probably accept it if the nonincrementing register is the first > and error otherwise, with some documentation explaining what's going on. I see yes, we don't want to stumble into a noinc register by mistake when writing a register range. You mentioned that we likely have breakage elsewhere, I believe that regmap_noinc_write probably shouldn't ever have been calling _regmap_raw_write. Whilst regmap_noinc_read calls _regmap_raw_read, this function doesn't do any massage and just calls map->bus->read after selecting a page. regmap_raw_write on the other hand is meant for writing blocks to register ranges as these added checks show, and does split work based on page length etc. This splitting up is something that shouldn't apply to the FIFO as it's a deep register. I modified regmap_noinc_write to be much more like the raw_read internals, just select page then attempt a map->bus->gather_write, falling back to linearising if that's not supported. This approach worked at getting writing working into the FIFO. So I would propose that there are two 'Fixes:' patches here, one enhancing the checking when writing a register range to ensure you don't stumble into a noinc register. And one to fix noinc_writes to send data directly to the bus once the page is selected with no splitting up as you would a range. Kind regards, Ben