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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74583C433FE for ; Thu, 13 Oct 2022 13:00:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229800AbiJMNAB (ORCPT ); Thu, 13 Oct 2022 09:00:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229556AbiJMNAA (ORCPT ); Thu, 13 Oct 2022 09:00:00 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4502303EA for ; Thu, 13 Oct 2022 05:59:58 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id bv10so2718189wrb.4 for ; Thu, 13 Oct 2022 05:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=6fGrxMBOLuz/ufum7iLzYyW7+BeCUbMtinCuje5Qnek=; b=DDrg6gRNN+qdSFLktuGPe6miLLWo+FuSK7tmXGvcxzwEWl7EOc3azdJ9UyOh6FVCTP TWZ6G2PN+tILhovLGjrqwCbPE7iaWPKnBNdJYFB13D7CH/wGS7ZuaVXfV1ngFWozXv2K zz8WTWpujszYbJhtDEDk+Oz7PP3dcoMka4qvGpADe9folHcBfkmoJCTuzz6lsAXqBNfT 7inuvWjNVpbHZ5LP+bMy6YrhzpYc3KtgRLb+RbPToZJpOyJI45oSngd7QHUp/aeDGMSk da7DD4PNiGARh+RI85rh85RBiZf8+85ZmGZyKDgd8boOgMlD3HtlacfhdGJv1fshZLB5 Ascg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6fGrxMBOLuz/ufum7iLzYyW7+BeCUbMtinCuje5Qnek=; b=u4UgCfd7yPfNPM48LVVRPZAGW03/jQZ3H+VHN15ceJkwYrZEckv3KCVVKL5Y7rQWgU tJoyvVPQozUYQh/b+eH+TAe+5SFKjD45VbkD9m58aFjrLCMTjRjENgt3kBPx7mMcVK3m ly+pIXwmzLLdctylhNDRgZnX+zzQVlCLbSjcCSehv1btA/Y5zWu6g8O8bdhxBBYGB17G akTmdG0GpfQ+bZVZ2D5nFvkNogDAL5PvAP/EQBKzzPJssfXBsKCAH++wUr5oOcasfKm6 HKwvmiZGtwoFMzEmdSC3KtSg0OCHlSIiwv+ap+6THczUQssUjPOqdWpSyPAKtBsTc22V qaKA== X-Gm-Message-State: ACrzQf0xi3r1fbsRCfn4zvKHX7MvzfTL9bIeDiOPdWlIYL81ZfoAq0W9 SZV6AxCNpCFln/cynxN+9f4WuQ== X-Google-Smtp-Source: AMsMyM4R9UBvK2aOVuodBoSAKW6fTfehJPe8G1obMNxLSJk0gLOU1bkCanq3VMsPRApZPcX2cW1RDg== X-Received: by 2002:a05:6000:168c:b0:231:7950:1114 with SMTP id y12-20020a056000168c00b0023179501114mr7941495wrd.484.1665665997291; Thu, 13 Oct 2022 05:59:57 -0700 (PDT) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id x4-20020adff644000000b0022afbd02c69sm2010424wrp.56.2022.10.13.05.59.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Oct 2022 05:59:56 -0700 (PDT) Date: Thu, 13 Oct 2022 13:59:55 +0100 From: Daniel Thompson To: Dmitry Torokhov Cc: Linus Walleij , Bartosz Golaszewski , linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, Andy Shevchenko , linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org Subject: Re: [PATCH 2/7] gpiolib: of: consolidate simple renames into a single quirk Message-ID: References: <20221011-gpiolib-quirks-v1-0-e01d9d3e7b29@gmail.com> <20221011-gpiolib-quirks-v1-2-e01d9d3e7b29@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Wed, Oct 12, 2022 at 12:20:50PM -0700, Dmitry Torokhov wrote: > On Wed, Oct 12, 2022 at 11:12:03AM +0100, Daniel Thompson wrote: > > On Tue, Oct 11, 2022 at 03:19:30PM -0700, Dmitry Torokhov wrote: > > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > > > index cef4f6634125..619aae0c5476 100644 > > > @@ -365,127 +365,83 @@ struct gpio_desc *gpiod_get_from_of_node(const struct device_node *node, > > > +static struct gpio_desc *of_find_gpio_rename(struct device_node *np, > > > const char *con_id, > > > unsigned int idx, > > > enum of_gpio_flags *of_flags) > > > { > > > + static const struct of_rename_gpio { > > > + const char *con_id; > > > + const char *legacy_id; /* NULL - same as con_id */ > > > + const char *compatible; /* NULL - don't check */ > > > > "don't check" doesn't seem desirable. It's not too big a deal here > > because everything affected has a vendor prefix (meaning incorrect > > matching is unlikely). Should there be a comment about the general care > > needed for a NULL compatible? There were certainly a lot of compatibles affected by this translation and given the structure of the drivers it is a tough code review to be sure you have picked up *all* of them! > I'll add the wording that NULL is only acceptable if property has a > vendor prefi, Will that be OK? Otherwise I'll have to add a lot of > entries for Arizona and Madera. > > > > > > > > + } gpios[] = { > > > +#if IS_ENABLED(CONFIG_MFD_ARIZONA) > > > + { "wlf,reset", NULL, NULL }, > > > > CONFIG_REGULATOR_ARIZONA_LDO1 is better guard for this con id. > > Are you sure? I see reset handling happening in > drivers/mfd/arizona-core.c independently of regulator code... Looks like I grepped for the wrong string so I was completely wrong here... and in two different ways! Firstly I'm wrong about replacing the guard. Existing guard is correct! Secondly, I didn't notice until now that wm8804 also uses the "wlf,reset" and it is a little odd that the wm8804 driver will accept or refuse a misspelled binding based whether the kernel has enabled the arizona drivers. Overall I can live with the code we have today but this makes me wonder if the comment discussed above should be stronger. Something like: "the NULL compatible code is used there to support legacy entries in the table; try to avoid adding new NULL entries". Daniel.