Christian König in fact the compiler will very often replace {0} with a memset call. I don't see a problem using {0} for local arrays with primitive types. There should also be no problem with memory alignment. Because the compiler understands it. Using sizeof is also not a good idea. More often everyone also makes mistakes with sizeof. It's best to leave it as is, and there's no errors. Indeed, when using structures and {0}, errors may occur, but I am not aware of errors when using primitive types. I also looked at the amdgpu code and {0} is used in many places. Also from experience malloc+memset is the most dangerous chain, can silently damage memory, causing a bunch of subtle problems, and it is better to replace them with more safe calloc. Such a problem, for example, was recently found by me in fontconfig and it crashed intel quartus. Therefore, where possible, I try to avoid memset.
Regards, Grigory.
ср, 6 апр. 2022 г. в 17:43, Christian König christian.koenig@amd.com:
Am 06.04.22 um 16:26 schrieb Jani Nikula:
On Tue, 05 Apr 2022, Christian König christian.koenig@amd.com wrote:
Am 05.04.22 um 19:36 schrieb Grigory Vasilyev:
Using memset on local arrays before exiting the function is pointless. Compilator will remove this code. Also for local arrays is preferable to use {0} instead of memset. Mistakes are often made when working with memset.
Well actually memset is preferred when working with structures which are given to the hardware parser because {0} won't initialize paddings.
Not that I'd know anything that's going on here... but it sure seems strange to me to be passing unpacked structures where the padding might matter to a "hardware parser".
Well to me it is an absolute miracle why the heck compilers don't initialize paddings.
We had so many ups moments over the years and I really don't see why it should be more optimal to do this.
Anyway, the memset() is used intentionally here and I don't really want to change it. What we could do is removing the second superfluous memset and use sizeof() instead of hard coding the size.
Regards, Christian.
*shrug*
BR, Jani.
So please don't use {0} in any of the atom bios code.
Regards, Christian.
Signed-off-by: Grigory Vasilyev h0tc0d3@gmail.com
drivers/gpu/drm/amd/amdgpu/atom.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c index be9d61bcb8ae..537e48fbbe6b 100644 --- a/drivers/gpu/drm/amd/amdgpu/atom.c +++ b/drivers/gpu/drm/amd/amdgpu/atom.c @@ -1538,11 +1538,9 @@ struct atom_context *amdgpu_atom_parse(struct card_info *card, void *bios) int amdgpu_atom_asic_init(struct atom_context *ctx) { int hwi = CU16(ctx->data_table + ATOM_DATA_FWI_PTR);
- uint32_t ps[16];
- uint32_t ps[16] = {0}; int ret;
- memset(ps, 0, 64);
- ps[0] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFSCLK_PTR)); ps[1] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFMCLK_PTR)); if (!ps[0] || !ps[1])
@@ -1551,10 +1549,6 @@ int amdgpu_atom_asic_init(struct atom_context *ctx) if (!CU16(ctx->cmd_table + 4 + 2 * ATOM_CMD_INIT)) return 1; ret = amdgpu_atom_execute_table(ctx, ATOM_CMD_INIT, ps);
if (ret)
return ret;memset(ps, 0, 64);
return ret; }