From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: platform-driver-x86@vger.kernel.org,
Hans de Goede <hansg@kernel.org>,
Jorge Lopez <jorge.lopez2@hp.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] platform/x86: hp-bioscfg: Use more common code in hp_init_bios_package_attribute()
Date: Fri, 3 Jul 2026 13:32:20 +0300 (EEST) [thread overview]
Message-ID: <2bbdf3e8-e763-69cb-b481-31505b7d8e64@linux.intel.com> (raw)
In-Reply-To: <b81acc89-c91f-46d9-b6de-5367b6cf94f4@web.de>
On Wed, 1 Jul 2026, Markus Elfring wrote:
> >> Use an existing label once more so that a bit of common code can be better
> >> reused at the end of this function implementation.
> >>
> >> This issue was detected by using the Coccinelle software.
> >
> > This patch leaves me quite unimpressed of Coccinelle's abilities.
>
> The intention of this development tool is not to impress you with a possible
> source code transformation.
That's exactly in the heart of the problem.
I'm not interested in seeing patches that focus on "source code
transformation" but patches that actually improve things. I don't want to
be the person who has to differentiate those out of all "source code
transformations" coccinelle can be automated to do. The person doing that
differentiation should be the submitter (in this case, you), which clearly
didn't happen here.
You stated: "this issue" so what exactly is the issue coccinelle found
for you? Is it "issue" at all? I don't think it is. Instead, there seems
to be another issue with this code but that was not found by neither
coccinelle nor you. The former doesn't surprise me because understanding
code is not within coccinelle's capabilities.
I suppose you'll once again deflect and suggest lets write another
non-intelligent transformation for coccinelle (which will have its own
false positives like this particular source code transformation did have).
But that would entirely miss my point, which is:
You should really look through and understand all the code related to the
change suggested by coccinelle before considering the change for
submission.
That being said, you can write just as many coccinelle transformations you
want and more, but please only send those results from them which actually
improve things to the kernel development lists. In the other cases, figure
out what is the correct way to address the root issue which is not
necessarily the one that matches that suggested by coccinelle. If you want
to write more transformations for them, again up to you, but then you'll
have another set of false positives to weed out.
> >> +++ b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.c
> >> @@ -692,8 +692,7 @@ static int hp_init_bios_package_attribute(enum hp_wmi_data_type attr_type,
> >> if (ret) {
> >> pr_debug("Failed to populate integer package data. Error [0%0x]\n",
> >> ret);
> >> - kfree(str_value);
> >> - return ret;
> >> + goto pack_attr_exit;
>
> Another source code search approach pointed implementation details out
> for further development considerations.
>
>
> > If a call fails, it's expected to handle cleanup itself --- which is
> > exactly what hp_convert_hexstr_to_str() appears to be doing (by not
> > writing into *str until it's committed to returning 0). So why is
> > this kfree() necessary in the first place?!?
>
> Would any contributors like to adjust background information accordingly?
For the other two points, your intent has totally eluded me so I cannot
comment on those point. Please rephrase.
--
i.
prev parent reply other threads:[~2026-07-03 10:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 19:54 [PATCH] platform/x86: hp-bioscfg: Use more common code in hp_init_bios_package_attribute() Markus Elfring
2026-07-01 11:53 ` Ilpo Järvinen
2026-07-01 17:53 ` Markus Elfring
2026-07-03 10:32 ` Ilpo Järvinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2bbdf3e8-e763-69cb-b481-31505b7d8e64@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Markus.Elfring@web.de \
--cc=hansg@kernel.org \
--cc=jorge.lopez2@hp.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox