Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3630077iog; Tue, 21 Jun 2022 02:44:12 -0700 (PDT) X-Google-Smtp-Source: AGRyM1saaIlyUTYrdrLHWKAyrUF1NNiOrO08e8BkDCnwFFbRjeBNIpjFHNQazQ+LSfoF/ApmqRfM X-Received: by 2002:a17:906:7488:b0:722:d6af:eaf0 with SMTP id e8-20020a170906748800b00722d6afeaf0mr4925616ejl.708.1655804652414; Tue, 21 Jun 2022 02:44:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655804652; cv=none; d=google.com; s=arc-20160816; b=QDQ6lAwYjEpw9gq173dFxYzEG4CT0HPP8NeXCyzdjwsRW9LybbsO0i+pFWRwnUsay1 6J435IGqvvrUga63meK+Su4Df2sSp8Gc8A1oFSxJSMT5soZCP1u1A5h5pRHIDYHeLUIH dYYuEAsJdNCvLaf6iPlYobmdPWMz03rlib573sa1Lhyxll6lx5t9j+/K8pl/Fn3h5ma5 EjAf0d44egNKXYb7RGhM2TPo3eIiee5KCBsyPbEPvDu3i9ZQ6cstyFntyWb62Zg0+hX+ TS6BTSNekVsHX/eIXOHFPdIrHkJ2C+A2tdPJ7z+JNWLdfi4Xn5YmzhwnNxLqerTuhbil uG2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=yO9ZPtHQWlDG8pJW5AjR6r/iVBmTjGfBSQKVmAjwZYM=; b=VlC4Ndg0yoo57mB9gf+oU2UWhNyRPneVko5YSf3v1iYyO3hEHZBO4OYmhPmXGOleG8 rzffN/+WHwseOD5pUHaYoqnK/v9eg/rcyDsyO47vpDr33DMaKT8aW35tOvT56bHXUaCV beRKMOBJjEnSJU1ShPx4nUWuO2ftg1vXJrqGPlEt04SXvnSMhSX0bU+GOv8TaRwFwLt2 oi2oh3utZKVzqRxUKKWHoYDsFGxhAEvbYw48u+IpCxN6ezF+Z5Aej3IhTtnmkGLHqfdq CEOvucXlKuxoN17VxrvXF3sbWx+j7YHSW7uPjF0Z2uP/2VIgWgUxNZESDY3t5VwiCc8U Zo3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=MiT9YSgq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id rv14-20020a17090710ce00b00707ad2d64edsi9440379ejb.98.2022.06.21.02.43.46; Tue, 21 Jun 2022 02:44:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=MiT9YSgq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S1349239AbiFUJlf (ORCPT + 99 others); Tue, 21 Jun 2022 05:41:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349280AbiFUJlG (ORCPT ); Tue, 21 Jun 2022 05:41:06 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1AB027CE9; Tue, 21 Jun 2022 02:40:49 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id v1so26181519ejg.13; Tue, 21 Jun 2022 02:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yO9ZPtHQWlDG8pJW5AjR6r/iVBmTjGfBSQKVmAjwZYM=; b=MiT9YSgqAyyHbC2NgSFHcI9mU0I4SmbelZoevB0+h8amRGfyUTmMrWazwaITPEHarp ymKzl2T79u9M7zLSooXOXyVg4z58w0poQeJaq3PyZdrpSWwinByRfTzDd3MJMVKc+Jh1 HrosNpkC9SLF6USdA/ZDhAg0uPAMPxz5wZw22PnS/SvBpuDabh76flqB27+QDjuz85Rk kVWCot5G6uKY0ebmYx0cAKxiYNCgHV9fAO4fsWARBr5Cz29I6Pl4NDihgDbx49z6TXgM upDr6OeHbZyVU5E1CaDMSJLWT9I584x/Nsc/beJSY8ZvpOWxhrcr5L3ty9BdiC7iyRCj 44Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yO9ZPtHQWlDG8pJW5AjR6r/iVBmTjGfBSQKVmAjwZYM=; b=72p+hfbAgG0q3Zjoubg9e7dxYmKz6XT/m4ZYB8SpB5k7Axv5yzirZUYKo/gIAHUAr6 M48BoTxiyxnh/0XpdYZOFvNB2bQKzs8Jxnk4J/c8qDKJy6rcRON2NYuVmar6bI69/uZF vs9YqRY99x4rq8O1v8e/CIKt7E5jgH4JHII/r/qDM5fnn9GmVfFTLWD2IfBH1CmSgzJ+ TLPP6BDlmVz4JJXkZhpmxmVPQIvgnKW1B3798qzij+/xeQj8ak/doY7hPBOtHX6GP7Ad vPpUlDO4AUZgCbEXQgKavNK3up5/SW4Qai2Z3jY/AHGFVdVszHUdXYlO3B6lMvISqxn9 5HhA== X-Gm-Message-State: AJIora9yyA5F6lyThrVuvIJ6ouKgRvrOB6BNGTaL+v8nML4v6GVGTa6f WyPgTV/0SIVp/Mc3fsET2Vdrvx1wwNstAJaonq8= X-Received: by 2002:a17:907:72c7:b0:722:e5af:f666 with SMTP id du7-20020a17090772c700b00722e5aff666mr1301982ejc.44.1655804448287; Tue, 21 Jun 2022 02:40:48 -0700 (PDT) MIME-Version: 1.0 References: <20220620200644.1961936-1-aidanmacdonald.0x0@gmail.com> <20220620200644.1961936-21-aidanmacdonald.0x0@gmail.com> In-Reply-To: <20220620200644.1961936-21-aidanmacdonald.0x0@gmail.com> From: Andy Shevchenko Date: Tue, 21 Jun 2022 11:40:12 +0200 Message-ID: Subject: Re: [PATCH 20/49] regmap-irq: Fix inverted handling of unmask registers To: Aidan MacDonald Cc: Mark Brown , Andy Gross , Bjorn Andersson , Srinivas Kandagatla , Banajit Goswami , Greg Kroah-Hartman , "Rafael J. Wysocki" , Chanwoo Choi , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , MyungJoo Ham , Michael Walle , Linus Walleij , Bartosz Golaszewski , Thomas Gleixner , Marc Zyngier , Lee Jones , Manivannan Sadhasivam , Cristian Ciocaltea , Chen-Yu Tsai , tharvey@gateworks.com, rjones@gateworks.com, Matti Vaittinen , orsonzhai@gmail.com, baolin.wang7@gmail.com, zhang.lyra@gmail.com, Jernej Skrabec , Samuel Holland , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Linux Kernel Mailing List , "open list:GPIO SUBSYSTEM" , linux-actions@lists.infradead.org, linux-arm-msm , linux-arm Mailing List , linux-sunxi@lists.linux.dev, ALSA Development Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 20, 2022 at 10:08 PM Aidan MacDonald wrote: > > To me "unmask" suggests that we write 1s to the register when > an interrupt is enabled. This also makes sense because it's the > opposite of what the "mask" register does (write 1s to disable > an interrupt). > > But regmap-irq does the opposite: for a disabled interrupt, it > writes 1s to "unmask" and 0s to "mask". This is surprising and > deviates from the usual way mask registers are handled. > > Additionally, mask_invert didn't interact with unmask registers > properly -- it caused them to be ignored entirely. > > Fix this by making mask and unmask registers orthogonal, using > the following behavior: > > * Mask registers are written with 1s for disabled interrupts. > * Unmask registers are written with 1s for enabled interrupts. > > This behavior supports both normal or inverted mask registers > and separate set/clear registers via different combinations of > mask_base/unmask_base. The mask_invert flag is made redundant, > since an inverted mask register can be described more directly > as an unmask register. > > To cope with existing drivers that rely on the old "backward" > behavior, check for the broken_mask_unmask flag and swap the > roles of mask/unmask registers. This is a compatibility measure > which can be dropped once the drivers are updated to use the > new, more consistent behavior. ... > + if (ret != 0) if (ret) > + dev_err(d->map->dev, "Failed to sync masks in %x\n", > + reg); ... > + if (ret != 0) Ditto. > + dev_err(d->map->dev, "Failed to sync masks in %x\n", ... > + /* > + * Swap role of mask_base and unmask_base if mask bits are inverted. the roles > + * > + * Historically, chips that specify both mask_base and unmask_base > + * got inverted mask behavior; this was arguably a bug in regmap-irq > + * and there was no way to get the normal, non-inverted behavior. > + * Those chips will set the broken_mask_unmask flag. They don't set > + * mask_invert so there is no need to worry about interactions with > + * that flag. > + */ Reading this comment perhaps the code needs a validator part that will issue a WARN_ON / dev_warn() / etc in case where the above is not satisfied? ... > + if (ret != 0) { if (ret) > + dev_err(map->dev, "Failed to set masks in 0x%x: %d\n", > + reg, ret); ... > + if (ret != 0) { Ditto. > + dev_err(map->dev, "Failed to set masks in 0x%x: %d\n", > + reg, ret); -- With Best Regards, Andy Shevchenko