linux-kernel - Re: [PATCH 3/4] media: platform: mtk-mdp3: Remove mask parameter from MM_REG

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: <01020191db30ab48-f8d1ad5b-7468-4675-a11d-46b1df659e32-000000@eu-west-1.amazonses.com>
Date: Tue, 10 Sep 2024 09:08:05 +0000
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Nícolas F. R. A. Prado <nfraprado@...labora.com>, 
	Mauro Carvalho Chehab <mchehab@...nel.org>, 
	Matthias Brugger <matthias.bgg@...il.com>
Cc: kernel@...labora.com, linux-media@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 3/4] media: platform: mtk-mdp3: Remove mask parameter from
 MM_REG_WRITE macro

Il 23/08/24 23:31, Nícolas F. R. A. Prado ha scritto:
> There are two macros to issue a cmdq write: MM_REG_WRITE_MASK and
> MM_REG_WRITE, but confusingly, both of them take a mask parameter. The
> difference is that MM_REG_WRITE additionally checks whether the mask
> passed in contains the register mask, in which case, the 0xffffffff mask
> is passed to cmdq_pkt_write_mask(), effectively disregarding the mask
> and calling cmdq_pkt_write() as an optimization.
> 
> Move that optimization to the MM_REG_WRITE_MASK macro and make
> MM_REG_WRITE the variant that doesn't take a mask, directly calling to
> cmdq_pkt_write().
> 
> Change the call sites to MM_REG_WRITE whenever a mask wasn't necessary
> (ie 0xffffffff or a <register>_MASK was passed as mask) and in other
> cases to MM_REG_WRITE_MASK.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>