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=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 48AB1C433FF for ; Mon, 5 Aug 2019 08:28:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 21D3B2067D for ; Mon, 5 Aug 2019 08:28:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20150623.gappssmtp.com header.i=@baylibre-com.20150623.gappssmtp.com header.b="gn0LHf8E" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727826AbfHEI2A (ORCPT ); Mon, 5 Aug 2019 04:28:00 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:40560 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727791AbfHEI2A (ORCPT ); Mon, 5 Aug 2019 04:28:00 -0400 Received: by mail-ot1-f68.google.com with SMTP id l15so27201662oth.7 for ; Mon, 05 Aug 2019 01:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qvG85uu+23wc3aOz56jKz9zl98RKrlFXnI9v0RdgYHY=; b=gn0LHf8ENoBGwjVAUPWk1trAn5THo247jg8e6zjlOG+W0AiNseHCflLSx/XH7Kcfy9 2wSOMmbwOPfMbBjkX6M2RQupJ/NbQ7i1OeZV4x0b7UaMTogOPcjGAh2WD4/Wzn3oFz+S s68do0KW/i5W4PVQKdwoTVYuoajMggDI1ujveZBBQeM1XkbfxbcpVORGDNzhN6D90l0s nchBa36BsovaPAw4h8M0gY9GSFJmJ6RPIM5M8O2TBp8svyqdG+/Z77FGfO1gxNobnwjE Hl6bo1835l7C2TEp1ARt072yPf+OHySWwJSl6kUR7uAp3M2jEwLs21KSIEzQgcwZEeFx EIwg== 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=qvG85uu+23wc3aOz56jKz9zl98RKrlFXnI9v0RdgYHY=; b=HB+qqDNifkY6z5dV7SS74IcjsayU0UFWUnsS1VDwC9c6L7SYq6r+uRWHQ4qLI97ahs dk+KuhcRhfgmrWesioOWhms9zv8rWu9ad9OM2ErH4HhLDdQIiKxmjBKLMMa2LOy8atbV BbeBDag62b0Is6TuPZTVgIvRjRsGXEHohFQ+Tkm/wBHg6f9n5rvjlPSeRM6h0LpGWLQT T5evWYxKtgzVnabc0QEvnJYkw/jaNezBjMLczJC7MVtVLe3U4DbgtApyPiXAK+rod3/i f2bpRk5ATgZsqtEemx9w2onqc62N8VcWe5dtFdQiPtS3EQ+JKSRJOSgLXMFUwT/pvQPS /p9A== X-Gm-Message-State: APjAAAWZkQdwpYwPCVWUK3TpQT4d2y95N9bOCCc4jH0n+l/Oui8rt756 j7C9tcF2Wxi1JngQVUOKFeUT1opTDW+3MnQR9fZ7pw== X-Google-Smtp-Source: APXvYqyHiFzcWgwMSYIdyYbnaCWSjRwGweIT3RKPv1xwORdpLKUPWaLHXzDYxYbuZLEk4t8xeoYAy31E8HbSzjuIfD4= X-Received: by 2002:a9d:2969:: with SMTP id d96mr115002880otb.85.1564993679131; Mon, 05 Aug 2019 01:27:59 -0700 (PDT) MIME-Version: 1.0 References: <20190731195713.3150463-1-arnd@arndb.de> <20190731195713.3150463-6-arnd@arndb.de> In-Reply-To: From: Bartosz Golaszewski Date: Mon, 5 Aug 2019 10:27:48 +0200 Message-ID: Subject: Re: [PATCH 05/14] gpio: lpc32xx: allow building on non-lpc32xx targets To: Arnd Bergmann 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: quoted-printable Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org pt., 2 sie 2019 o 13:20 Arnd Bergmann napisa=C5=82(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? > > > > @@ -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(). Bart > > > > +static inline u32 gpreg_read(unsigned long offset) > > > > Here and elsewhere: could you please keep the lpc32xx_gpio prefix for > > all symbols? > > Sure. > > Arnd