Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp4135812pxb; Tue, 10 Nov 2020 08:45:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJwfD3WcUXawtCX1IT4DRqOTflL5dmlWemTnQWYn1KHiVXWzIeSOnOj07qYc22bPFF4b8W5A X-Received: by 2002:a17:906:903:: with SMTP id i3mr4943216ejd.218.1605026744531; Tue, 10 Nov 2020 08:45:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605026744; cv=none; d=google.com; s=arc-20160816; b=i0KIYu2NSQplwc4O8v6fu4WAVoh8rvoIF5oow6Z/r6uBs9Dm20wgiAU1quEEfcTVIo I8Nj4D1LWww9Mj7MP7nYyyhJZxRxV6KsUMLaihqt8N5oqfB4CEpNS7MKymsD+zDqvBn/ wy/1iPvNd4l/95FxJciZuOc5LWTQGrli9coG7Snh5j/5CyB7BSoZeMANJ1VeX2EC7KaG 6Nq4hsLhkEf9NkfXL8Dgsj6+3trc5Bh8OJjok8s/LyaXaGMAC5rDzR08E2eX+8LXB5vv oljd1niCutQhaKJSz3SMO4Gpzz66RsEfXj9aHM1g4UorAd6POFemwge9qk5IujRMKdmA yKew== 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=MtX8JBV+6E2KPNfEwP024+o67AmbZzvL6k7scU6NL6E=; b=aGJoCNZb9DjJnZsfevmeQ5ZDaSsa+IBUC5VuBIMN3xTV2/RiWPGBCO8sRM1luKtF2X F4XXRwRY0t9A2BGD9owluHsMGYB1t8oNCFJcyHR/+rOfYtZPnQJCFP0Iyh/mx2aH1A7H jis2alFVxPzU1dec6Cjrcn2XdB2tlJhdFYoZ3F8uS06ziNT+XZJ8kKGjpsvYoUFAdtQz u6cQ7gSm18KzNx4os6m/8fLWuAUk9hWDgMC2b6N1sBmMPG/9JOupjCxn2FeUWXXuJGuF M+bUsyYXTePA8ZxjvH5fByMHY3gLSR/ZJ2M4DKnRQaTYXSsPt7ddZLL8eqZ+7bhzpbRj e2QA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="aV/2m0HU"; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p13si10004123edy.436.2020.11.10.08.45.21; Tue, 10 Nov 2020 08:45:44 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b="aV/2m0HU"; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730368AbgKJQnr (ORCPT + 99 others); Tue, 10 Nov 2020 11:43:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730108AbgKJQnq (ORCPT ); Tue, 10 Nov 2020 11:43:46 -0500 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AB41C0613D1; Tue, 10 Nov 2020 08:43:46 -0800 (PST) Received: by mail-pg1-x541.google.com with SMTP id r10so10650377pgb.10; Tue, 10 Nov 2020 08:43:46 -0800 (PST) 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=MtX8JBV+6E2KPNfEwP024+o67AmbZzvL6k7scU6NL6E=; b=aV/2m0HUb9BtspOkCa/H2S/4r3YPFYdGVb7jOS3UzKeSMtUquIbS35o5tj+QVbjKph caekWBeb0OhnIPdtgJpRL6IsefC29Lj9jpDKehAJS3X60VvAKtKeULu7VLRAAu1bbGwx 0CNTZqredRmEAlNdytm8IXrukC6njouoGM4sBOsSos7622O28evxMydxybBCS39/0qOR KNBtXgpLxLR2juK3+iezU+yUOGRdOQn5WNL0jIOF3dtB5KtenK3qf12/NotuYC8TT6H2 LoY0IUsA5YlA3YAUoHwEEmoV1LSBM10xRgoBZ5YUxKOxJKMf8YNnzueCyn12FSF1ZmnI veSA== 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=MtX8JBV+6E2KPNfEwP024+o67AmbZzvL6k7scU6NL6E=; b=ZG79949G9pl+5ZOTjHIZdPNfGfSXBZZLMdBKalTOyPjnTXOZStEYhcaJhzzwbF4LtC 8FF13kFphrM19nbqaFfos2magoIbMuFFd0rgs3ZlP3bQH+UJNV/2BfFeB+Y3avauDUSI MQD7B0ptyq4q18bIPAn2e91Ja+hlT7mjYjyGnMu0txUg2IBvPUD1JKgnffJ5p+fnKs5Z zUjdMcITGns7rHp4zq2qXp88RR9qb7BfEdY0RjXtWIgpG5xAh6RI47XvPUCNUNkNxOHd 8CrZzcuPTMpZPM2DHe43KCD8mnbkVW8be8eKNohB0AG/bxUrZOkH8PkdmeESYpUlOG8f L1Sw== X-Gm-Message-State: AOAM5316WppSPMt9HDdmadN6P2U/DjLKrvYwqNl05VqNfbmlGSeZMADW HuzAcccKxEorBlMtprxK5hrl56Po3+B8ezt3h/g= X-Received: by 2002:a62:7c95:0:b029:18c:5002:a1ab with SMTP id x143-20020a627c950000b029018c5002a1abmr2608866pfc.40.1605026625724; Tue, 10 Nov 2020 08:43:45 -0800 (PST) MIME-Version: 1.0 References: <20201110145552.23024-1-brgl@bgdev.pl> <20201110145552.23024-7-brgl@bgdev.pl> <20201110150447.GW4077@smile.fi.intel.com> <20201110151022.GY4077@smile.fi.intel.com> <20201110161225.GZ4077@smile.fi.intel.com> In-Reply-To: From: Andy Shevchenko Date: Tue, 10 Nov 2020 18:44:34 +0200 Message-ID: Subject: Re: [PATCH v4 6/7] gpio: exar: switch to using regmap To: Bartosz Golaszewski Cc: Andy Shevchenko , Bartosz Golaszewski , Linus Walleij , Jan Kiszka , David Laight , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 10, 2020 at 6:37 PM Bartosz Golaszewski wrote: > On Tue, Nov 10, 2020 at 5:17 PM Andy Shevchenko > wrote: ... > > > > > > +static const struct regmap_config exar_regmap_config = { > > > > > > + .name = "exar-gpio", > > > > > > + .reg_bits = 16, > > > > > > > > > > As per previous version comment. > > > > > > > > > > Hold on, the registers are 16-bit wide, but their halves are sparsed! > > > > > So, I guess 8 and 8 with helpers to get hi and lo parts are essential. > > > > > > > > > > > > > > > TABLE 5: DEVICE CONFIGURATION REGISTERS SHOWN IN BYTE ALIGNMENT > > > > > > > > > > > + .val_bits = 8, > > > > > > +}; > > > > > > > > > > This is basically represents two banks out of 6 8-bit registers each. > > > > > > > > ...which makes me wonder if gpio-regmap can be utilized here... > > > > > > > > > > But the address width won't affect the actuall accessing of 8 bits > > > registers in an mmio regmap. Internally the mmio regmap does pretty > > > much the same thing the previous driver did: call readb()/writeb() on > > > 8-bit "chunks" of the banks. > > > > It will affect reg dump in debugfs. I would really narrow down the register > > address space in the config, otherwise that debugfs facility will screw up a > > lot of things. > > > > So, and to be on pedantic side... > > > > "The Device Configuration Registers and the two individual UART Configuration > > Registers of the XR17V352 occupy 2K of PCI bus memory address space." > > > > 11 seems the correct value for the address width. > > I take it as a typo and assume you meant 16. So the patch should be > correct and your review tag is good to go? It's not a typo. But thinking again. This is basically done in regmap to support serial buses. Here we have MMIO pretty much with 32-bit or 64-bit address accesses. I didn't dig into regmap implementation to understand the consequences of changing this to the different values (it seems like rather offset, and in this case 11 is a correct one, not a typo, and regmap is okay with that). But I would rather ask Jan to actually mount debugfs and dump registers and see if it screws up the UART (because it may go all over important registers), that's why I think this configuration is still missing some strict rules about what addresses (offsets) driver may or may not access. -- With Best Regards, Andy Shevchenko