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: <77b76efa-60fe-4629-8828-5a56b254a92b@amd.com>
Date: Tue, 16 Sep 2025 10:57:24 +0200
From: Christian König <christian.koenig@....com>
To: Jani Nikula <jani.nikula@...ux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>, Andi Shyti <andi.shyti@...nel.org>
Cc: 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 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.

Regards,
Christian.

> 
> BR,
> Jani.
>