From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 01079C5AE5A for ; Wed, 28 Aug 2024 14:46:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:CC:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aUrm7aKU6rJTEbmYz0DPEIq5CpO6UYunkMXEy01mW9k=; b=p3OvZpBtDkUZ86xEdIMGoJ8JxH hYUXzVIaR642tes6gp+jAkXe/z2ABbhSJs4OIQSnfSWlj6zXL/04MFavqoD3M0rnaJadAV5CyITlQ dseM3KsDMvQ5rxPgLS/sKfMjOy4x2xABFjVI/kI3ctU6EOiyykyVD03cGKzQgfcHzR5guL3GLyjX+ 7UhDeI/ddA7edCnAT0WppFUPAMTBvYPBeZUAIm3VXQq7648uH+RDrW2ihGRTfm1AbwIDRv+LkPnUQ nsXPJ1UTkhZuEnFycSuTQmfIsSe8HbCxI/FeMqaUQKCwsVjVPeclj4LM3kYxFw3Zlfp4PWrLGBlgC P0MsS9jQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjJwG-0000000FoVq-27m4; Wed, 28 Aug 2024 14:46:24 +0000 Received: from lelv0142.ext.ti.com ([198.47.23.249]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjJv3-0000000Fo20-3mKI for linux-arm-kernel@lists.infradead.org; Wed, 28 Aug 2024 14:45:11 +0000 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 47SEiY6v109709; Wed, 28 Aug 2024 09:44:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1724856275; bh=aUrm7aKU6rJTEbmYz0DPEIq5CpO6UYunkMXEy01mW9k=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=qAg5yiO767p5Yrh5FL1j5u2ex16QTwVxkRaqO2WQ/mPDfAAlWzuqRy7Wkm1sADFdD S3CN1lT24XAO8zeJl3cWLYgSod5UP1Exp4lYeMX8RZVdh1qFLZmSOVkc2ZIxpCg2GM vg7aXCRZX89Kv4Lnk/d7jLjqHCv/oolfJ2uiVgyk= Received: from DFLE109.ent.ti.com (dfle109.ent.ti.com [10.64.6.30]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 47SEiYt6052329 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 28 Aug 2024 09:44:34 -0500 Received: from DFLE109.ent.ti.com (10.64.6.30) by DFLE109.ent.ti.com (10.64.6.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Wed, 28 Aug 2024 09:44:34 -0500 Received: from lelvsmtp6.itg.ti.com (10.180.75.249) by DFLE109.ent.ti.com (10.64.6.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Wed, 28 Aug 2024 09:44:34 -0500 Received: from localhost (uda0133052.dhcp.ti.com [128.247.81.232]) by lelvsmtp6.itg.ti.com (8.15.2/8.15.2) with ESMTP id 47SEiYdB105480; Wed, 28 Aug 2024 09:44:34 -0500 Date: Wed, 28 Aug 2024 09:44:34 -0500 From: Nishanth Menon To: Mark Brown CC: Arnd Bergmann , Lee Jones , , , , , , Jan Dakinevich Subject: Re: [PATCH] mfd: syscon: Set max_register_is_0 when syscon points to a single register Message-ID: <20240828144434.oydsgflsqy5vibxe@sapling> References: <20240828121008.3066002-1-nm@ti.com> <20240828133229.67bej3utpgrmzr3p@retired> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240828_074510_182602_7EEEC6A7 X-CRM114-Status: GOOD ( 23.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Mark, On 15:27-20240828, Mark Brown wrote: > On Wed, Aug 28, 2024 at 08:32:29AM -0500, Nishanth Menon wrote: > > On 13:57-20240828, Mark Brown wrote: > > > On Wed, Aug 28, 2024 at 07:10:08AM -0500, Nishanth Menon wrote: > > > > > Fixes: 0ec74ad3c157 ("regmap: rework ->max_register handling") > > > > In what sense is this a fix? > > > The max_register was 0x0 was clearly a corner case. The fix done for > > remap should have cleaned up the users of max_register to maintain the > > behavior. That is just my opinion. > > No, apart from the fact that catching all possible regmap users would be > rather hard it's entirely optional for regmaps to specify a maxium > register. Fair enough, I can drop the 'Fixes' tag. [...] > Like I say specifying a maximum register is entirely optional, not I understand max_register is entirely optional as documented in include/linux/regmap.h and I understand why max_register_is_0 exists - the patch does NOT try to revert the valid feature in regmap. > everyone wants that feature and if you don't use the debugfs interface > or the flat cache it doesn't *super* matter. With 0 as default it's > always going to be awkward to describe a maximum register of 0 while > allowing that to be optional, fortunately very few devices have a single > register. yeah, unfortunately I have to deal with a few of them :( This is a patch for syscon, not regmap. I am a bit confused as to what objection beyond the "Fixes" usage (which I can drop in a respin) you may have here, will appreciate if you are NAKing the patch and on what rationale. I understand that regmap considers the max_register usage entirely optional, but syscon does already use it (my patch doesn't introduce it). I am just getting syscon to catchup to what regmap already provides. Side effect of leaving the current syscon code as is creating bad results that should can be trivially caught (and could have saved me a couple of hours of early morning head scratching today[1]). I think the regmap checks are valuable, and should be consistent in usage by syscon. And I think the checks are valuable for programmers from mistakenly introducing bad code. [1] Already pointed out in diffstat https://lore.kernel.org/all/20240828131601.6sxvnwpcsb36tz4m@eloquent/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D