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=-3.7 required=3.0 tests=BAYES_00, 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 95789C433E0 for ; Thu, 4 Feb 2021 11:07:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 68A5564F5E for ; Thu, 4 Feb 2021 11:07:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235518AbhBDLHE (ORCPT ); Thu, 4 Feb 2021 06:07:04 -0500 Received: from mslow2.mail.gandi.net ([217.70.178.242]:60701 "EHLO mslow2.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235575AbhBDLHC (ORCPT ); Thu, 4 Feb 2021 06:07:02 -0500 Received: from relay9-d.mail.gandi.net (unknown [217.70.183.199]) by mslow2.mail.gandi.net (Postfix) with ESMTP id 305E53C0DA8; Thu, 4 Feb 2021 10:59:00 +0000 (UTC) X-Originating-IP: 86.202.109.140 Received: from localhost (lfbn-lyo-1-13-140.w86-202.abo.wanadoo.fr [86.202.109.140]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 36493FF80B; Thu, 4 Feb 2021 10:57:53 +0000 (UTC) Date: Thu, 4 Feb 2021 11:57:52 +0100 From: Alexandre Belloni To: Hans de Goede Cc: Daniel Vetter , Patrik Jakobsson , Andy Shevchenko , "open list:REAL TIME CLOCK (RTC) SUBSYSTEM" , Alessandro Zummo , Wim Van Sebroeck , Mark Gross , LINUX-WATCHDOG , "open list:GPIO SUBSYSTEM" , dri-devel , Platform Driver , Bartosz Golaszewski , Andy Shevchenko , Guenter Roeck Subject: Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1 Message-ID: <20210204105752.GA3940374@piout.net> References: <797cf4ac-ffdc-e73e-cb58-d027beb6e3b4@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <797cf4ac-ffdc-e73e-cb58-d027beb6e3b4@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-watchdog@vger.kernel.org On 04/02/2021 11:50:03+0100, Hans de Goede wrote: > Hi, > > On 2/4/21 11:36 AM, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 11:19 AM Patrik Jakobsson > > wrote: > >> > >> On Wed, Feb 3, 2021 at 1:00 PM Andy Shevchenko > >> wrote: > >>> > >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > >>> wrote: > >>>> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > >>>> wrote: > >>>>> > >>>>> Hi guys, > >>>>> > >>>>> This is first part of Intel MID outdated platforms removal. It's collected into > >>>>> immutable branch with a given tag, please pull to yours subsystems. > >>>> > >>>> Hi Andy, > >>>> Do you plan on eventually removing X86_INTEL_MID completely? If so, > >>>> then I should probably start looking at removing the corresponding > >>>> parts in GMA500. > >>> > >>> I have noticed new commits in DRM against GMA500 and it seems now in a > >>> conflict with my immutable branch. Are you sure you don't forget to > >>> pull it? > >> > >> Hi Andy, sorry I missed pulling the immutable branch before taking the > >> gma500 medfield removal. I was unsure how to do that through drm-misc > >> and it's tools so I got sidetracked. What would be the correct way to > >> fix this? > > > > Imo Linus can resolve this, it's pretty trivial, as long as both pull > > requests point it out to him. > > The removal of older Intel platforms touches a number of subsystem trees, > the idea about the IM branch was that all subsystem-trees would merge that. > > I can certainly point out the problem in the pdx86 pull-req to Linus, > but the GPIO pull-req also contains a merge of the IM branch as will > the x86/tip and rtc pull-reqs I believe. We can add a remark to all > the pull-reqs about the issue I guess ? > FWIW, I'm not going to merge the PR in the rtc tree because it is a simple removal and doesn't have any conflicts. > But it might be better to still merge the branch into drm-misc-next and > resolve the conflict there. I think that should avoid Linus seeing it ? > Linus doesn't mind seeing and solving conflicts. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com