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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2BFD5C31E40 for ; Fri, 9 Aug 2019 14:19:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0B12621773 for ; Fri, 9 Aug 2019 14:19:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407075AbfHIOTC convert rfc822-to-8bit (ORCPT ); Fri, 9 Aug 2019 10:19:02 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:41937 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726342AbfHIOTB (ORCPT ); Fri, 9 Aug 2019 10:19:01 -0400 Received: by mail-qk1-f194.google.com with SMTP id g17so1058726qkk.8; Fri, 09 Aug 2019 07:19:00 -0700 (PDT) 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:content-transfer-encoding; bh=TEfOzDxFX7gDpnqMzrlBGrH3Syt9gXqMdj4yqEybIZo=; b=QXHfe+5F2OOhd2CElNQM4DMdlNJ4IJl8fINRHiW3jKlocffCMbvetrzZAqZj73zlmj KWvFoVIYkOHvDj1DaYKbfsuCvroIUYFb3KL+M9mkFDlElbx/WQrXDrEmoD9TEU4aBY4V KOYSTDW4jBYl1Q1ouhbunaHKhuxt1uFwhly4aynTDR3/pFoatrZAGcllqAX3imwjf7rg Zvptpq+bditHfN3KQpZl7biqacUzCNzWVHXcWNc47zgDNuTW5Ddvc7FolbuGOSKoYWHe U95f/JthiUb4jQ8Awib8m4ByohBD8ZbF9S/ymEA2OIxhbWwKX69SfaGeAtETxlf7AIPX 4bTg== X-Gm-Message-State: APjAAAULwbc9OKX1TGlOPd/2K493GXivn5Vz3PzAouoEWlMHdClUpahm 1/NNzHwi7xx3joyV/qXpaBZpTVA/KRvGrriqZOs= X-Google-Smtp-Source: APXvYqwdOIIhs7aYJbryOrEuz/1xQSAZBUfsTj7jxd0qGAmaTDwXDUSNUG1kGVNfZ5fjxOBFSW0skDDZmykp0YbSLSg= X-Received: by 2002:a37:984:: with SMTP id 126mr12380366qkj.3.1565360340175; Fri, 09 Aug 2019 07:19:00 -0700 (PDT) MIME-Version: 1.0 References: <20190731195713.3150463-1-arnd@arndb.de> <20190731195713.3150463-6-arnd@arndb.de> In-Reply-To: From: Arnd Bergmann Date: Fri, 9 Aug 2019 16:18:43 +0200 Message-ID: Subject: Re: [PATCH 05/14] gpio: lpc32xx: allow building on non-lpc32xx targets To: Bartosz Golaszewski Cc: soc@kernel.org, arm-soc , Vladimir Zapolskiy , Sylvain Lemieux , Russell King , Gregory Clement , Linus Walleij , Jason Cooper , Andrew Lunn , Sebastian Hesselbarth , "David S. Miller" , Greg Kroah-Hartman , Alan Stern , Guenter Roeck , linux-gpio , netdev , linux-serial@vger.kernel.org, USB list , LINUXWATCHDOG , Lee Jones , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Mon, Aug 5, 2019 at 10:28 AM Bartosz Golaszewski wrote: > > pt., 2 sie 2019 o 13:20 Arnd Bergmann napisał(a): > > > > On Fri, Aug 2, 2019 at 9:10 AM Bartosz Golaszewski > > wrote: > > > > -#include > > > > -#include > > > > +#define _GPREG(x) (x) > > > > > > What purpose does this macro serve? > > > > > > > > > > > #define LPC32XX_GPIO_P3_INP_STATE _GPREG(0x000) > > > > #define LPC32XX_GPIO_P3_OUTP_SET _GPREG(0x004) > > > > In the existing code base, this macro converts a register offset to > > an __iomem pointer for a gpio register. I changed the definition of the > > macro here to keep the number of changes down, but I it's just > > as easy to remove it if you prefer. > > Could you just add a comment so that it's clear at first glance? I ended up removing the macro. With the change to keep the reg_base as a struct member, this ends up being a relatively small change, and it's more straightforward that way. > > > > @@ -167,14 +166,26 @@ struct lpc32xx_gpio_chip { > > > > struct gpio_regs *gpio_grp; > > > > }; > > > > > > > > +void __iomem *gpio_reg_base; > > > > > > Any reason why this can't be made part of struct lpc32xx_gpio_chip? > > > > It could be, but it's the same for each instance, and not known until > > probe() time, so the same pointer would need to be copied into each > > instance that is otherwise read-only. > > > > Let me know if you'd prefer me to rework these two things or leave > > them as they are. > > I would prefer not to have global state in the driver, let's just > store the pointer in the data passed to gpiochip_add_data(). Ok, done. Arnd