linux-kernel - Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aMmKsOD5erCHLAY3@intel.com>
Date: Tue, 16 Sep 2025 12:05:04 -0400
From: Rodrigo Vivi <rodrigo.vivi@...el.com>
To: Christian König <christian.koenig@....com>
CC: Jani Nikula <jani.nikula@...ux.intel.com>, Andi Shyti
	<andi.shyti@...nel.org>, Ilpo Järvinen
	<ilpo.jarvinen@...ux.intel.com>, <linux-pci@...r.kernel.org>, Bjorn Helgaas
	<bhelgaas@...gle.com>, Krzysztof Wilczyński <kw@...ux.com>,
	Michał Winiarski <michal.winiarski@...el.com>, Alex Deucher
	<alexander.deucher@....com>, <amd-gfx@...ts.freedesktop.org>, David Airlie
	<airlied@...il.com>, <dri-devel@...ts.freedesktop.org>,
	<intel-gfx@...ts.freedesktop.org>, <intel-xe@...ts.freedesktop.org>, "Joonas
 Lahtinen" <joonas.lahtinen@...ux.intel.com>, Lucas De Marchi
	<lucas.demarchi@...el.com>, Simona Vetter <simona@...ll.ch>, Tvrtko Ursulin
	<tursulin@...ulin.net>, ?UTF-8?q?Thomas=20Hellstr=C3=B6m?=
	<thomas.hellstrom@...ux.intel.com>, "Michael J . Ruhl" <mjruhl@...ana.ai>,
	<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v2 06/11] drm/i915/gt: Use pci_rebar_size_supported()

On Tue, Sep 16, 2025 at 10:57:24AM +0200, Christian König wrote:
> On 16.09.25 10:12, Jani Nikula wrote:
> > On Mon, 15 Sep 2025, Rodrigo Vivi <rodrigo.vivi@...el.com> wrote:
> >> On Mon, Sep 15, 2025 at 07:24:10PM +0200, Andi Shyti wrote:
> >>> Hi,
> >>>
> >>> On Mon, Sep 15, 2025 at 03:42:23PM +0300, Jani Nikula wrote:
> >>>> On Mon, 15 Sep 2025, Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com> wrote:
> >>>>> PCI core provides pci_rebar_size_supported() that helps in checking if
> >>>>> a BAR Size is supported for the BAR or not. Use it in
> >>>>> i915_resize_lmem_bar() to simplify code.
> >>>>>
> >>>>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> >>>>> Acked-by: Christian König <christian.koenig@....com>
> >>>>
> >>>> Reviewed-by: Jani Nikula <jani.nikula@...el.com>
> >>>>
> >>>> and
> >>>>
> >>>> Acked-by: Jani Nikula <jani.nikula@...el.com>
> >>>
> >>> Just for some random noise on commit log's bureaucracy: why do we
> >>> need both Ack and R-b? I think R-b covers Ack making it
> >>> redundant. Right?
> >>
> >> reviewed-by is a more formal attestation of the entries in the
> >> submitting-patches doc, saying that he carefully reviewed the work.
> >>
> >> acked by is to state that from the maintainer perspective of that file
> >> the file can be merged through any tree.
> >>
> >> in the drm trees nowdays our tooling is enforcing acked-by tag if
> >> the patch is touching domains outside that drm branch itself.
> >>
> >> if a committer tries to push a patch without ack from the maintainer
> >> of that domain it will be blocked.
> >>
> >> So I believe it is a good idea to keep a separation of the meaning.
> >> Carrying a technical review of the patch in question doesn't necessarily
> >> mean that you, as maintainer, is okay of getting that patch merged
> >> through other trees.
> > 
> > Yes, all of the above. I just wanted to be explicit to avoid the
> > follow-up questions "thanks for the review, but is it okay to merge via
> > pci" or "thanks for the ack, but does this need review also", and move
> > on from this whole thread. (Which is a nice cleanup, btw, thanks.)
> 
> Mhm, that's a really good point.
> 
> My understanding of an Acked-by by a maintainer is also "go a head and merge it through your tree", but I think we never formally documented that.
> 
> At least I can't find any reference to that in the "When to use Acked-by:, Cc:, and Co-developed-by:" section of Documentation/process/submitting-patches.rst.

"Acked-by: is also less formal than Reviewed-by:. For instance, maintainers may
use it to signify that they are OK with a patch landing, but they may not have reviewed it..."

perhaps we should simply

s/patch landing/patch landing through any other tree/

> 
> Regards,
> Christian.
> 
> > 
> > BR,
> > Jani.
> > 
>