From: Lukas Wunner <lukas@wunner.de>
To: Mario Limonciello <mario.limonciello@dell.com>
Cc: dvhart@infradead.org, LKML <linux-kernel@vger.kernel.org>,
platform-driver-x86@vger.kernel.org,
Richard Hughes <hughsient@gmail.com>,
Yehezkel Bernat <yehezkelshb@gmail.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH v3] Add driver to force WMI Thunderbolt controller power status
Date: Wed, 13 Sep 2017 19:20:24 +0200 [thread overview]
Message-ID: <20170913172024.GA8782@wunner.de> (raw)
In-Reply-To: <1504884191-16528-1-git-send-email-mario.limonciello@dell.com>
Sorry, late to the party.
On Fri, Sep 08, 2017 at 10:23:11AM -0500, Mario Limonciello wrote:
> + mode = hex_to_bin(buf[0]);
> + if (mode == 0 || mode == 1) {
> + status = wmi_evaluate_method(INTEL_WMI_THUNDERBOLT_GUID, 0, 1,
> + &input, NULL);
> + if (ACPI_FAILURE(status)) {
> + pr_err("intel-wmi-thunderbolt: failed setting %s\n",
> + buf);
> + return -ENODEV;
> + }
> + } else {
> + pr_err("intel-wmi-thunderbolt: unsupported mode: %d", mode);
> + }
> + return count;
> +}
Seems odd to allow user space to fill the log by writing invalid data
to sysfs, likewise that success is returned in the else case.
I'd drop both pr_err() and return -EINVAL in the else case.
> +static const struct wmi_device_id intel_wmi_thunderbolt_id_table[] = {
> + { .guid_string = INTEL_WMI_THUNDERBOLT_GUID },
> + { },
> +};
I'm not familiar with WMI, but don't you need a MODULE_DEVICE_TABLE here?
How does user space know which module to load upon receiving the uevent?
Thanks,
Lukas
next prev parent reply other threads:[~2017-09-13 17:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 15:23 [PATCH v3] Add driver to force WMI Thunderbolt controller power status Mario Limonciello
2017-09-09 7:09 ` Mika Westerberg
2017-09-09 18:39 ` Yehezkel Bernat
2017-09-11 21:44 ` Darren Hart
2017-09-12 19:19 ` Mario.Limonciello
2017-09-13 17:20 ` Lukas Wunner [this message]
2017-09-14 6:42 ` Mario.Limonciello
2017-09-14 9:14 ` Lukas Wunner
2017-09-14 14:52 ` Mario.Limonciello
2017-09-14 14:59 ` Mika Westerberg
2017-09-14 15:05 ` Mika Westerberg
2017-09-15 7:44 ` Lukas Wunner
2017-09-15 16:34 ` Mario.Limonciello
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=20170913172024.GA8782@wunner.de \
--to=lukas@wunner.de \
--cc=dvhart@infradead.org \
--cc=hughsient@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@dell.com \
--cc=mika.westerberg@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=yehezkelshb@gmail.com \
/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