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.jarvi...@linux.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.jarvi...@linux.intel.com> > > > Acked-by: Christian König <christian.koe...@amd.com> > > > > Reviewed-by: Jani Nikula <jani.nik...@intel.com> > > > > and > > > > Acked-by: Jani Nikula <jani.nik...@intel.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
