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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BE7A6CE8E83 for ; Thu, 24 Oct 2024 14:38:14 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5097688DB7; Thu, 24 Oct 2024 16:38:08 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=linux.intel.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="jijR2hQ8"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6E37288DDC; Thu, 24 Oct 2024 16:38:07 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id D2B8288995 for ; Thu, 24 Oct 2024 16:38:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=linux.intel.com Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=andriy.shevchenko@linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729780685; x=1761316685; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=fyEu23khubHcKpK77dOth8OTubDWtBofCLrSUvLtlIQ=; b=jijR2hQ8yOzzJ9BuJn55+MT0HvE+dLv39ly6P3lWwXDkBgnqCEEsPmBY 6qNQeFMrVV51pi6q90vg7dPtlAhg4Q+PUEPKHisVNhyFxOYLS+9nZsJCm 6lmzvFBjAav0IQ0ySZroNu1Ex3wofDuONBCrdWq+JQ6kstEnbzixg09hh hWu8Pr+MI/VOnjWrbjVLO9wTeGr5aarOoqXiPLvx0TyeQ6xfYyRu/NUqA cGWGj/BbVSU9aYjUvtQ1Rb/bj/CTfoZ1TVfhwUdh5LyEkZEMD8udzSQ2B j3THOwLWKxTlDA2fPBnL0plmcSR8idlTtn/4Tmf47c/aB99x2LfwPxxdY g==; X-CSE-ConnectionGUID: YHXXgGmhTrS34zZBI7I1eA== X-CSE-MsgGUID: WXpJoHT5TXeqgXUNnbfK3Q== X-IronPort-AV: E=McAfee;i="6700,10204,11222"; a="29574365" X-IronPort-AV: E=Sophos;i="6.11,199,1725346800"; d="scan'208";a="29574365" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2024 07:38:03 -0700 X-CSE-ConnectionGUID: 70n9iDc0QW+Ke949fJS8Rw== X-CSE-MsgGUID: 7EyTGwFESEmxHKzqsMFHJg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,229,1725346800"; d="scan'208";a="81041302" Received: from smile.fi.intel.com ([10.237.72.154]) by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2024 07:38:02 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1t3yyM-00000006bZ2-3FRo; Thu, 24 Oct 2024 17:37:58 +0300 Date: Thu, 24 Oct 2024 17:37:58 +0300 From: Andy Shevchenko To: Tom Rini Cc: Heinrich Schuchardt , Ilias Apalodimas , AKASHI Takahiro , u-boot@lists.denx.de Subject: Re: [PATCH v1 1/1] efi_loader: Mark a function static Message-ID: References: <20241021140546.2969356-1-andriy.shevchenko@linux.intel.com> <5fc1929f-c931-4c14-847b-6ea9333037d5@gmx.de> <5EB571BB-8963-4B47-86EC-1F1C5424D4F1@gmx.de> <20241024141840.GR4959@bill-the-cat> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241024141840.GR4959@bill-the-cat> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On Thu, Oct 24, 2024 at 08:18:40AM -0600, Tom Rini wrote: > On Thu, Oct 24, 2024 at 09:26:14AM +0300, Andy Shevchenko wrote: > > On Thu, Oct 24, 2024 at 07:03:24AM +0200, Heinrich Schuchardt wrote: > > > Am 22. Oktober 2024 15:18:45 MESZ schrieb Andy Shevchenko : > > > >On Tue, Oct 22, 2024 at 08:02:46AM +0200, Heinrich Schuchardt wrote: > > > >> On 10/21/24 16:40, Ilias Apalodimas wrote: > > > >> > On Mon, 21 Oct 2024 at 17:06, Andy Shevchenko > > > >> > wrote: > > > >> > > > > > >> > > efi_bootmgr_release_uridp_resource() is not used anywhere except > > > >> > > the same file where it is defined. Mark it static. > > > >> > > This helps avoiding the compiler warning: > > > >> > > > > > >> > > lib/efi_loader/efi_bootmgr.c:388:14: warning: no previous prototype for ‘efi_bootmgr_release_uridp_resource’ [-Wmissing-prototypes] > > > > > > > >> The function is called efi_bootmgr_release_uridp() since 292a4a4c7b77 > > > >> ("efi_loader: shorten efi_bootmgr_release_uridp_resource()"). > > > > > > > >Thanks! The problem is that U-Boot doesn't have the latest tag (yet) > > > >that includes this change. You can help with managing the conflict. > > > > > > Patches should be based on origin/master (or origin/next once that branch is > > > opened typically after -rc2) and not on tags. > > > > I disagree. The problem with moving target that it's been moving... > > > > The tags are very good to follow and easy to maintain and test and report > > regressions against. What you are suggesting it's like virtually assigning > > tag to very each commit and tell maintainer to cope with this chaos when > > one does something in one "tag" out of 100500 ones and another person in > > another "tag". So, consider tags as stabilisation points, or points of > > stability. Then it's much easier to stick with a few tags that with 100500 > > commits. > > This isn't the linux kernel where there's constant churn. Most of the > time, it doesn't matter at all. Sometimes it does. Then it's a question > of if the custodian wants to do the rebase work themselves, or ask the > submitter to. And since again unlike the kernel almost no one has the > primary job of "work on U-Boot", the threshold for fixup or ask for a > rebase is much lower. I see your point, thanks for elaboration. Although I think even taking it into account the Linux kernel approach makes some process, which is stable (more or less) and understandable by many. I feel uncomfortable to rebase on top of random commit. I also have scripts to update my branches and the proposed approach breaks this badly. So I prefer to stick with my flow. That said, consider the patch as reported problem by me. I will help testing any new tag that will have a respective fix, or fix separately based on the tag, so I won't need a special commits on top of. -- With Best Regards, Andy Shevchenko