On 2023/3/17 18:23, srinivas pandruvada wrote:
Hi,
...
...
Hi Srinivas and Hans,
How about folding these three patches into one patch and resend a
v3 patch?
This will get all people together and avoid the previous
embarrassing sitation.
If I understand things correctly then patch 1/3 needs 3/3 to function
correctly, right ?
I would not fold them together, smaller patches are easier to review
/ understand, but maybe change the order and put patch 3/3 first? (so
make it 1/3) ?
That should be correct order. The patch 3/3 should be the first.
Oh, yeah. The memory leak fix 3/3 should be the first. This is more
reasonable.
BTW, I separated this memory leak fix due to that the kernel mainline is
still vulnerable to this memory leak problem.
I can even do that when applying if you agree that is the better
order.
Agree.
Thanks,
Srinivas
Regards,
Hans
---
drivers/platform/x86/intel/tpmi.c | 17 ++++-------------
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/platform/x86/intel/tpmi.c
b/drivers/platform/x86/intel/tpmi.c
index c999732b0f1e..882fe5e4763f 100644
--- a/drivers/platform/x86/intel/tpmi.c
+++ b/drivers/platform/x86/intel/tpmi.c
@@ -215,8 +215,8 @@ static int tpmi_create_device(struct
intel_tpmi_info *tpmi_info,
feature_vsec_dev =
kzalloc(sizeof(*feature_vsec_dev),
GFP_KERNEL);
if (!feature_vsec_dev) {
- ret = -ENOMEM;
- goto free_res;
+ kfree(res);
+ return -ENOMEM;
}
snprintf(feature_id_name, sizeof(feature_id_name),
"tpmi-
%s", name);
@@ -242,17 +242,8 @@ static int tpmi_create_device(struct
intel_tpmi_info *tpmi_info,
* feature_vsec_dev memory is also freed as part of
device
* delete.
*/
- ret = intel_vsec_add_aux(vsec_dev->pcidev, &vsec_dev-
auxdev.dev,
- feature_vsec_dev,
feature_id_name);
- if (ret)
- goto free_res;
-
- return 0;
-
-free_res:
- kfree(res);
-
- return ret;
+ return intel_vsec_add_aux(vsec_dev->pcidev,
&vsec_dev-
auxdev.dev,
+ feature_vsec_dev,
feature_id_name);
}
static int tpmi_create_devices(struct intel_tpmi_info
*tpmi_info)
