Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp797478ybl; Wed, 14 Aug 2019 06:10:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqx9EsXjHMPgZkg9+Z7MA1lMpEBJ9Uk6/TTPjMN/X5HxOH/R/usVAvRAFfwLpu/YnnyzAZIv X-Received: by 2002:a63:9245:: with SMTP id s5mr39748524pgn.123.1565788258022; Wed, 14 Aug 2019 06:10:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565788258; cv=none; d=google.com; s=arc-20160816; b=sSt4AqadjNKB8h0uf4Jzo5dv9m7NTXNfTT6C6u6B2Xkf8wfNjYqVjW73rQw25/BoYP CpurZHV0z0UMdQkXOdIPFFhUNcxRcnYgthN+vigeQHWyf+EmCfjM/lt207u9t3ABw46H fswSdXSED7CayzrF8jDaN0QUg2oLeVX2Gp4CE96IbVNHba7Iu7DKVD7bnLxLK/+vI+V8 jc0cCWoU4WIcC5UkwpBRQCgtDbHFTaAYftTM1BkmnR3+Q1Dsw0iBZ8+KNP0VLKEq/jYM SKOgp6AqP1kAzYia00s6CpHVkn1C2FefKAQl6mCKBWKdzE2Gwa84q9PgbZej8/0sT3Dr Me1w== 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=UDLa6zXMAOjQhOfwSq9LjN1EM9IBbq4NVeShp4a46KE=; b=C1MWrJleilGjB6GYnGCP0BDdQVbJiG0E6jmoOaGnzAjmZlWb9YhAsKyFlbU4TeHPm6 NGAemzPmWCJmOKOLCnkx3ViouAnT+Lo1orBGwwD8YTC5hyrgtnXW5/Yj1IJT6Vl9rxNZ SLb9syGnSQmzs+YZpSoMp5NXmknB2+C54vXL/qgBZ40XAaSuVTsPuC+5IEblXZ/f5s10 qrWPnobAXWBqTgj1GUdEq8qZTYweWzygjae+HkV3Nzvf+wmy9gUYbg/izFApQN2Jc0FS UovkU37VdPzOSIF1jvtVAIPAsclbPaFWpy4JCFeywuKMnrbOmEFuTCpA14TjUP7sOevs z5Zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=f75OYjPP; 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 24si65288929pfp.107.2019.08.14.06.10.40; Wed, 14 Aug 2019 06:10:58 -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=f75OYjPP; 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 S1727993AbfHNNJY (ORCPT + 99 others); Wed, 14 Aug 2019 09:09:24 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:36072 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725800AbfHNNJX (ORCPT ); Wed, 14 Aug 2019 09:09:23 -0400 Received: by mail-wm1-f67.google.com with SMTP id g67so4424864wme.1 for ; Wed, 14 Aug 2019 06:09:22 -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=UDLa6zXMAOjQhOfwSq9LjN1EM9IBbq4NVeShp4a46KE=; b=f75OYjPPZqrZUXpIVDLeS6DLx3A+MnbtEpOHyayzqK0y7pDvvQDHb2pPMoFxAWJCrB ufhbdsMKzG+hWZiS6/aPr7uiCVgSq1ZgCZcQC7yiCU1HYAH+KE08GSlO+DgbNQdOdEp9 WkWVjiAyySSx+VTYT3WHZ5/hF1XvD5z0bihtnMnTXlL7WFmgvogaWkUGtX4Rv2qgi3Gu mLCbBqlv+xVSCjhCHawEVff1MG3clE/qBUgXrkbsT5QAlMiC7qTK8W+yQGW5VMMn+CGl qmz1Q2Z1qBPAPgxfjdxLuueZAhR4GdYuZ4j/q9jI0Km84opMLHdDV+9OIiRwwfE3X5ZB OHxQ== 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=UDLa6zXMAOjQhOfwSq9LjN1EM9IBbq4NVeShp4a46KE=; b=br6wKu6EJsMPPiHFvyLd5d6Ix/x9EpCyV6pqKHSygiExSghpr/0ys6XOGXstb9723l JaoBU5ZrGbxbtjgzdZQ7WuqHnFys8/+ntkO3tx7d4IuVFIiJxjl7MH58O7IJnI9Os82y dqt5BDO9GO8GvRhafC4rN0HfwoStlAXhHCVnCyQ38+RBpWBByPzD/7mY1IALsr/Y97wK /TroDPtr4bwLuO+nGyh4pJJtgw0qiZtc0AtiXeqGPBZjXBa+jVTeANJIGQI6IHWRCCal AzahTS0O7u3KjilfLCoY6FgP0Z5LuBQuDisjnh2yFzV1NYsbuFr7ODSNMejjHH8ra4ew iUcQ== X-Gm-Message-State: APjAAAUQDxTMxTUFApiXjbUKjyFeJuUwzIvmsTZz6OVAIxstP7XTf7qR VtAu90oy3LVBOeYlCd5FkCQKQwyIehs6l3qom2IgZfJHihl+27qH X-Received: by 2002:a1c:a481:: with SMTP id n123mr7882793wme.123.1565788162062; Wed, 14 Aug 2019 06:09:22 -0700 (PDT) MIME-Version: 1.0 References: <20190813212251.12316-1-ben.whitten@gmail.com> <20190814100115.GF4640@sirena.co.uk> In-Reply-To: <20190814100115.GF4640@sirena.co.uk> From: Ben Whitten Date: Wed, 14 Aug 2019 14:09:11 +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 11:01, Mark Brown 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. 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/