Searched hist:"9 fb9ce392aae0c6654efc42c80e2f6bab88d5fe3" (Results 1 – 3 of 3) sorted by relevance
| /linux/drivers/edac/ |
| H A D | edac_device.h | diff 9fb9ce392aae0c6654efc42c80e2f6bab88d5fe3 Tue Mar 08 14:16:17 CET 2022 Borislav Petkov <bp@suse.de> EDAC/device: Get rid of the silly one-shot memory allocation in edac_device_alloc_ctl_info()
Use boring kzalloc() instead. Add pointers to the different allocated
members in struct edac_device_ctl_info for easier freeing later.
One of the reasons, perhaps, why it was done this way is to be able to
do a single kfree(ctl_info) without having to kfree() the other parts of
the struct too but that is not nearly a sensible reason as to why there
should be this obscure pointer alignment.
There should be no functional changes resulting from this.
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220310095254.1510-4-bp@alien8.de
|
| H A D | edac_device_sysfs.c | diff 9fb9ce392aae0c6654efc42c80e2f6bab88d5fe3 Tue Mar 08 14:16:17 CET 2022 Borislav Petkov <bp@suse.de> EDAC/device: Get rid of the silly one-shot memory allocation in edac_device_alloc_ctl_info()
Use boring kzalloc() instead. Add pointers to the different allocated
members in struct edac_device_ctl_info for easier freeing later.
One of the reasons, perhaps, why it was done this way is to be able to
do a single kfree(ctl_info) without having to kfree() the other parts of
the struct too but that is not nearly a sensible reason as to why there
should be this obscure pointer alignment.
There should be no functional changes resulting from this.
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220310095254.1510-4-bp@alien8.de
|
| H A D | edac_device.c | diff 9fb9ce392aae0c6654efc42c80e2f6bab88d5fe3 Tue Mar 08 14:16:17 CET 2022 Borislav Petkov <bp@suse.de> EDAC/device: Get rid of the silly one-shot memory allocation in edac_device_alloc_ctl_info()
Use boring kzalloc() instead. Add pointers to the different allocated
members in struct edac_device_ctl_info for easier freeing later.
One of the reasons, perhaps, why it was done this way is to be able to
do a single kfree(ctl_info) without having to kfree() the other parts of
the struct too but that is not nearly a sensible reason as to why there
should be this obscure pointer alignment.
There should be no functional changes resulting from this.
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220310095254.1510-4-bp@alien8.de
|