[PULL] drm-intel-fixes

[Krzysztof Kozlowski]

On 08/08/2024 20:35, Krzysztof Kozlowski wrote:
> On 08/08/2024 10:45, Tvrtko Ursulin wrote:
>>
>> Hi Dave, Sima,
>>
>> A small bunch of fixes for the weekly cycle:
> 
> ...
> 
>>
>> ----------------------------------------------------------------
>> Andi Shyti (2):
>>       drm/i915/gem: Adjust vma offset for framebuffer mmap offset
>>       drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
>>
>> David Gow (2):
>>       drm/i915: Allow evicting to use the requested placement
>>       drm/i915: Attempt to get pages without eviction first
>>
>> Dnyaneshwar Bhadane (1):
>>       drm/i915/display: correct dual pps handling for MTL_PCH+
> 
> Several commits have issues. Look:
> 
>     Signed-off-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
>     Link: https://patchwork.freedesktop.org/patch/msgid ...
>     (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)
>     Signed-off-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> 
> 
> 1. Duplicated committer SoB.
> You added SoB. No need to add two. It does not get stronger. You do not
> change the DCO rules by adding two SoBs. You cannot confirm something
> more or twice. Read DCO one more time...
> 
> 2. Useless cherry pick SHA.
> fatal: bad object 97b6784753da06d9d40232328efc5c5367e53417
> (Tried with repo having several maintainer repos and the linux-next)
> 
> Only you have 97b6784753da06d9d40232328efc5c5367e53417. Maybe few other
> people as well, but all other do not. This does not bring any useful
> information, rather obfuscates public git history.

... and in case you claim that 97b6784753da06d9d40232328efc5c5367e53417
is in drm-next, then your workflow is broken because:
1. You will duplicate the same commit. One in drm-fixes and second in
drm-next. Just use git features, like branches and merges... First you
apply on fixes, then you merge it to next, for example. Or any other
sane way.

2. If you rebase drm-next on top of drm-fixes in some time in the
future, then that cherry-pick SHA will not work and will be totally useless.

so either you create duplicate commits (that's how Intel gets stats?) or
you introduce to git history totally bogus SHAs...

Best regards,
Krzysztof