Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp483558imm; Fri, 13 Jul 2018 00:36:09 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfsHPmG6G5Rv35PTBmhisCyduK4NWgvnikxigQPwmxT9gelCq2rMzqT5E+8Fj91/+rsF7J3 X-Received: by 2002:a17:902:9302:: with SMTP id bc2-v6mr2506887plb.280.1531467369602; Fri, 13 Jul 2018 00:36:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531467369; cv=none; d=google.com; s=arc-20160816; b=eYW1GMZH8j+o692wBycNFNxbPkBzPIvuQ8L5+fmfYDR6EWIAOIBRm9ATj/PUrUcvgs bCuSPVHSQUVsrFmB2nPY9nF5QGxdhfMjllMXZ300X0pcvzhaqUskRR4tRkei6RXD3cpF 475EE3wEn0hqc7LbyuH3m/+0QCW3SjRhaOgtyBAAvfIRtdOZxXZgdiEGmfRenQpw0WnH 50rBMbHxlWCEeZwWNraP27abl0+BUgRgsnHWh4IV2OPeGE9AM+opft7/8utuqIEhR8W3 8Dy+EIyvabJyhLZod9couXeFXKRHgGa0n//xHfmyEOsJN6ePQILw+WsmytWnogrS0dUs 9Jmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=rHAGnefy7E92VPzrX1VhkpL22y0Cx+XeiZ7CKSrubOE=; b=Jyxkuo7lRrTg6f+wKf7MVrqMm/YGIOwzKmSS5u7pDHbcnjq+tQRQuC5kbN39rrSpNy Gj8BJcXlS9PSMEewMZIj0ikLoz24emE4FBNBrVx7Dn7OVKk3cANPt35N6ZJQo4Xg+6yB nLcAA1pMjqbFY6ZK4kTBmtPcm76V8mjpmOvE9SXlQKX1AirLe5Oh+otpWCNakb2zF7XN ZcD3UFN646QpFbEPuXiHbAKXl2/vzzAwY3p50Pvdek+rKRMlTxo3ZBZyhtGpCGlppQ0e iHCoq/LGbPQMJZjzPmTJivHXEsWlpgmSmz2Lg4jQ3aFACZE4kqufeJtv7WyWC13qZYgi Eq4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Bvq7qf/c"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p21-v6si22752098plq.94.2018.07.13.00.35.53; Fri, 13 Jul 2018 00:36:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Bvq7qf/c"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729768AbeGMHsm (ORCPT + 99 others); Fri, 13 Jul 2018 03:48:42 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:55307 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726748AbeGMHsm (ORCPT ); Fri, 13 Jul 2018 03:48:42 -0400 Received: by mail-it0-f68.google.com with SMTP id 16-v6so10307426itl.5 for ; Fri, 13 Jul 2018 00:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rHAGnefy7E92VPzrX1VhkpL22y0Cx+XeiZ7CKSrubOE=; b=Bvq7qf/cdb9fnt/Dx7eg6uBfUzJAmJZWg1YC6EU7BIyh9+3qU8Z2DMoTLbauMC7E1Q xpm+gP0ISI+e2qhEQp5AWWNmVkn6sNUcR2wXqurAQiSOrK4lkDhD/owPIYIwDk78wgAz 5FEcb5+9Rp6soYiIRggyPKVzoCQfPBOiRPJ3Y= 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=rHAGnefy7E92VPzrX1VhkpL22y0Cx+XeiZ7CKSrubOE=; b=HpQMzRwUnoRU9IkD03T1FO795o2GOJpB9ayhKJkZTpmnDIMK77usMC5qAcYq+mQnZ0 7ne+i1p+XzmrbdDRlHjd7Mbl7O6hwNlrWFIslUhsNZ5smVQ7k3qgDwpgKgXTwkZF7DHE pcLU2CXyzvAqHY5sB18hPepnctwukbBGTKLDYJXzWN/LQjEGDRmtU3dMAyHXrtaBaJCK 4XFvMWlJnuIV07OXWCWHj8rv34BWmgg1co3Qn0ZPk/8EEB8vKjlbUl13D+QEOOUTOI07 REL+/fTXlHRc5D1PcF2yPRfTOiIQxvjVHjDvT7clTmEF4z7pSHRxrBXk/u2YGbL0yO3w azMA== X-Gm-Message-State: AOUpUlEywusCz+/rOfY3zNNuXLklbj5cWNkDFQ/ZhKUDsstgfAmivD1s IhFxUs2u0aLA6RSjdgds3TcwvfydSnmAk7CnCSKdXf+F2iQ= X-Received: by 2002:a24:5004:: with SMTP id m4-v6mr3837350itb.38.1531467318882; Fri, 13 Jul 2018 00:35:18 -0700 (PDT) MIME-Version: 1.0 References: <20180710061112.28736-1-linus.walleij@linaro.org> <5893595.ygSzo8aE2W@z50> In-Reply-To: <5893595.ygSzo8aE2W@z50> From: Linus Walleij Date: Fri, 13 Jul 2018 09:35:06 +0200 Message-ID: Subject: Re: [PATCH v4] regulator: fixed: Convert to use GPIO descriptor only To: Janusz Krzysztofik Cc: Liam Girdwood , Mark Brown , "linux-kernel@vger.kernel.org" , Alexander Shiyan , Haojian Zhuang , Aaro Koskinen , Mike Rapoport , Robert Jarzmik , Philipp Zabel , Daniel Mack , Marc Zyngier , jacopo , Geert Uytterhoeven , Russell King Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 10, 2018 at 7:56 PM Janusz Krzysztofik wrote: > > - .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET, > > This is OK but not enough for clean build of board-ams-delta.c when merged > into current linux-next as one more struct fixed_voltage_config introduced there > recently - keybrd_pwr_config - needs removal of .gpio member (respective lookup > table with NULL function name is already there). > > > @@ -538,6 +546,7 @@ static struct gpiod_lookup_table *ams_delta_gpio_tables[] __initdata = { > > }; > > > > static struct gpiod_lookup_table *late_gpio_tables[] __initdata = { > > + &ams_delta_nreset_gpiod_table, > > That is also OK but may raise a conflict when merged into current linux-next > where late_gpio_tables[] has been removed from board-ams-delta.c and its > content integrated into ams_delta_gpio_tables[]. > > > &ams_delta_lcd_gpio_table, > > &ams_delta_nand_gpio_table, > > }; > > If that makes your life easier, I can prepare a fix for board-ams-delta.c on > top of your patch. In that case you can add my: > Reviewed-by: Janusz Krzysztofik Hm it's a bit of cross-tree conflict going on here I guess. Do you have some idea about how serious the conflicts will be? Is it just one patch to the ARM SoC OMAP tree or several? It's a bit of Mark's pick, there are several ways to go about it: 1. Simply defer this to the next kernel cycle when your change is upstream and avoid all fuzz (totally OK as long as one is not impatient). I'm definately not in a hurry. 2. Mark applies this, conflicts appear in linux-next, you help Stephen to solve it and later on Torvalds has to solve it. Then we need to know how serious the conflicts are. 3. Apply this patch with fixes to the ARM SoC tree. Which makes it hard to pull out so I'm not so sure about that. 4. An immutable branch with the ARM SoC change for Mark to pull before applying this so I can rebase this patch on that. 5. Pick some patch from ARM SoC and apply it *also* to the regulator tree and then this on top so I can rebase the changes and avoid all conflicts. (We do this sometimes as some last resort.) 6. ...? BTW I like your OMAP1 cleanups a lot! Yours, Linus Walleij