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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aMhzougLzpfw2wWw@intel.com>
Date: Mon, 15 Sep 2025 16:14:26 -0400
From: Rodrigo Vivi <rodrigo.vivi@...el.com>
To: Andi Shyti <andi.shyti@...nel.org>
CC: Jani Nikula <jani.nikula@...ux.intel.com>, Ilpo
 Järvinen <ilpo.jarvinen@...ux.intel.com>,
	<linux-pci@...r.kernel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Krzysztof
 Wilczyński <kw@...ux.com>, Christian
 König <christian.koenig@....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 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.

> 
> Andi