| 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
| ||
|
Date: Mon, 19 Sep 2022 09:58:01 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Dave Airlie <airlied@...hat.com>,
DRI <dri-devel@...ts.freedesktop.org>,
Alex Deucher <alexander.deucher@....com>,
Hamza Mahfooz <hamza.mahfooz@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Nathan Chancellor <nathan@...nel.org>,
Rodrigo Siqueira <Rodrigo.Siqueira@....com>
Subject: Re: linux-next: manual merge of the drm tree with Linus' tree
Hi Stephen,
On Mon, Sep 19, 2022 at 3:07 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
>
> between commit:
>
> 41012d715d5d ("drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage")
>
> from Linus' tree and commit:
>
> a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> index 1cb858dd6ea0,b7fa003ffe06..000000000000
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> @@@ -6610,66 -6497,11 +6497,11 @@@ static double CalculateUrgentLatency
> return ret;
> }
>
> -static void UseMinimumDCFCLK(
> +static noinline_for_stack void UseMinimumDCFCLK(
While this looks like the correct merge resolution, it does mean that
both stack size mitigations are now applied, and probably one of them
can be dropped?
> struct display_mode_lib *mode_lib,
> - int MaxInterDCNTileRepeaters,
> + struct vba_vars_st *v,
> int MaxPrefetchMode,
> - double FinalDRAMClockChangeLatency,
> - double SREnterPlusExitTime,
> - int ReturnBusWidth,
> - int RoundTripPingLatencyCycles,
> - int ReorderingBytes,
> - int PixelChunkSizeInKByte,
> - int MetaChunkSize,
> - bool GPUVMEnable,
> - int GPUVMMaxPageTableLevels,
> - bool HostVMEnable,
> - int NumberOfActivePlanes,
> - double HostVMMinPageSize,
> - int HostVMMaxNonCachedPageTableLevels,
> - bool DynamicMetadataVMEnabled,
> - enum immediate_flip_requirement ImmediateFlipRequirement,
> - bool ProgressiveToInterlaceUnitInOPP,
> - double MaxAveragePercentOfIdealSDPPortBWDisplayCanUseInNormalSystemOperation,
> - double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyPixelMixedWithVMData,
> - double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyVMDataOnly,
> - double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyPixelDataOnly,
> - int VTotal[],
> - int VActive[],
> - int DynamicMetadataTransmittedBytes[],
> - int DynamicMetadataLinesBeforeActiveRequired[],
> - bool Interlace[],
> - double RequiredDPPCLK[][2][DC__NUM_DPP__MAX],
> - double RequiredDISPCLK[][2],
> - double UrgLatency[],
> - unsigned int NoOfDPP[][2][DC__NUM_DPP__MAX],
> - double ProjectedDCFCLKDeepSleep[][2],
> - double MaximumVStartup[][2][DC__NUM_DPP__MAX],
> - double TotalVActivePixelBandwidth[][2],
> - double TotalVActiveCursorBandwidth[][2],
> - double TotalMetaRowBandwidth[][2],
> - double TotalDPTERowBandwidth[][2],
> - unsigned int TotalNumberOfActiveDPP[][2],
> - unsigned int TotalNumberOfDCCActiveDPP[][2],
> - int dpte_group_bytes[],
> - double PrefetchLinesY[][2][DC__NUM_DPP__MAX],
> - double PrefetchLinesC[][2][DC__NUM_DPP__MAX],
> - unsigned int swath_width_luma_ub_all_states[][2][DC__NUM_DPP__MAX],
> - unsigned int swath_width_chroma_ub_all_states[][2][DC__NUM_DPP__MAX],
> - int BytePerPixelY[],
> - int BytePerPixelC[],
> - int HTotal[],
> - double PixelClock[],
> - double PDEAndMetaPTEBytesPerFrame[][2][DC__NUM_DPP__MAX],
> - double DPTEBytesPerRow[][2][DC__NUM_DPP__MAX],
> - double MetaRowBytes[][2][DC__NUM_DPP__MAX],
> - bool DynamicMetadataEnable[],
> - double VActivePixelBandwidth[][2][DC__NUM_DPP__MAX],
> - double VActiveCursorBandwidth[][2][DC__NUM_DPP__MAX],
> - double ReadBandwidthLuma[],
> - double ReadBandwidthChroma[],
> - double DCFCLKPerState[],
> - double DCFCLKState[][2])
> + int ReorderingBytes)
> {
> double NormalEfficiency = 0;
> double PTEEfficiency = 0;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists