Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp4053470pxb; Tue, 10 Nov 2020 06:55:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJxFvoJ4rRVVjbknqkmbANLFRkoWxJKDxntibi1goITjDnxjK0rs4LP/wD/7w1U+X0g1Djif X-Received: by 2002:a17:906:b852:: with SMTP id ga18mr21334140ejb.80.1605020106151; Tue, 10 Nov 2020 06:55:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605020106; cv=none; d=google.com; s=arc-20160816; b=TVNiXZ8F9rY+DyrvLvj07QnbCujYebtzcY9hXjXMA6KcXmcHoX1NM84ZEqWyTOIVR3 txymIpr/OeeOC0pW4LzpBfw6zagV27hS+ZKyLTW06oWlJ17m34xceW3OI8UQlTlKx5Vl JdZvF/yAM5FiQBmrmpR3/OoMGkubSoPD410t86u7p2Xeq9xg++en4s4Sb8eKSbzZoJ60 8+kLun+DlKZlS12fah60sSwr74zTXcvegSJm5ztVeuSSo/HdN0/oyWZTE8hWBEhoTICi EB7AeXlwJj7sBTa5VC+2XLuLCQu+p/F7RkAa6QAe9VqW5Dx5jN1ri6wOL4Hswf2NV8gn hOLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=IE2Om/vauf119qKavm9pcpOEyKjAavUxkCMscjn0XvI=; b=04o5xalr3hrvvmUI2BL1K+EULISgEUkbhyAxPqPqh/ZdHXnsxIvbdO1h+YT8PEx0P+ t4aHvZwA+EpONWr12KUmkt7O9JQccJfXtQQQrGdSUlVaUCTNQIGIAlTEmmEXaPUSe7rI /nzb/iuPb/SPnCYNkcM97KRggLU2a1IMyWsusrZ4hnnzkc+yZ3GGhbgPEPJQkgQfxICz qNvCNsN4NzIKS8EYbr2jQQs+aJCO4OL458VkHfyQPC2AXTpC1BcleTpJFIbWR1a5Hlul jEfs/ohr8ENlTNc9zMwKx8FQjyaStu7y00ZuSzbLn6aOY1S8X/0zmzxlL+zvsTj7mdHI fvgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x9si11736523ejc.745.2020.11.10.06.54.42; Tue, 10 Nov 2020 06:55:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731067AbgKJOud (ORCPT + 99 others); Tue, 10 Nov 2020 09:50:33 -0500 Received: from david.siemens.de ([192.35.17.14]:55844 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730200AbgKJOuc (ORCPT ); Tue, 10 Nov 2020 09:50:32 -0500 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 0AAEoEXS011180 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Nov 2020 15:50:14 +0100 Received: from [167.87.33.169] ([167.87.33.169]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 0AAEoCko001593; Tue, 10 Nov 2020 15:50:12 +0100 Subject: Re: [PATCH v3 6/7] gpio: exar: switch to using regmap To: Bartosz Golaszewski , Andy Shevchenko Cc: Bartosz Golaszewski , Linus Walleij , David Laight , linux-gpio , LKML References: <20201110123406.3261-1-brgl@bgdev.pl> <20201110123406.3261-7-brgl@bgdev.pl> <20201110142624.GT4077@smile.fi.intel.com> <20201110142750.GU4077@smile.fi.intel.com> From: Jan Kiszka Message-ID: Date: Tue, 10 Nov 2020 15:50:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10.11.20 15:30, Bartosz Golaszewski wrote: > On Tue, Nov 10, 2020 at 3:26 PM Andy Shevchenko > wrote: >> >> On Tue, Nov 10, 2020 at 04:26:24PM +0200, Andy Shevchenko wrote: >>> On Tue, Nov 10, 2020 at 01:34:05PM +0100, Bartosz Golaszewski wrote: >>>> From: Bartosz Golaszewski >>>> >>>> We can simplify the code in gpio-exar by using regmap. This allows us to >>>> drop the mutex (regmap provides its own locking) and we can also reuse >>>> regmap's bit operations instead of implementing our own update function. >>> >>> ... >>> >>>> + /* >>>> + * We don't need to check the return values of mmio regmap operations (unless >>>> + * the regmap has a clock attached which is not the case here). >>>> + */ >>>> + exar_gpio->regs = devm_regmap_init_mmio(dev, p, &exar_regmap_config); >>>> + if (IS_ERR(exar_gpio->regs)) >>>> + return PTR_ERR(exar_gpio->regs); >>>> >>>> index = ida_alloc(&ida_index, GFP_KERNEL); >>>> - if (index < 0) { >>>> - ret = index; >>>> - goto err_mutex_destroy; >>>> - } >>>> + if (index < 0) >>>> + return index; >>> >>> And below you effectively use p as regmap! >>> That's what renaming of variable regs -> regmap or map can easily reveal. >>> >>> exar_gpio->regs = p; >> >> Jan, if you remove this line, does it help? >> > > Ha! I guess you were right saying that keeping the name is asking for > trouble then. :) > > I think that may be it but address width should still be changed to 16. > Removing the line that Andy found made things work here. And switching to 16 for reg_bits didn't make things worse again. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux