From: "José Expósito" <jose.exposito89@gmail.com>
To: Benjamin Tissoires <bentiss@kernel.org>
Cc: jikos@kernel.org, benjamin.tissoires@redhat.com,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] HID: uclogic: Store firmware name in params
Date: Fri, 22 Mar 2024 11:06:13 +0100 [thread overview]
Message-ID: <Zf1YFQh-S6_21Hwx@fedora> (raw)
In-Reply-To: <dadh7jtdpdf3iahcgxdaqadpc6k6gnaz6gatxycxpd4u2atl7a@2f4vzqwzt7n3>
Hi Benjamin,
Thanks a lot for the quick review :)
On Thu, Mar 21, 2024 at 04:01:06PM +0100, Benjamin Tissoires wrote:
>
> Hi José,
>
> On Mar 21 2024, José Expósito wrote:
> > A future patch will need to access the firmware name to expose it to
> > userspace via sysfs.
> >
> > Store it in `uclogic_params->fw_name`.
> >
> > Signed-off-by: José Expósito <jose.exposito89@gmail.com>
> > ---
> > drivers/hid/hid-uclogic-params.c | 14 +++++++-------
> > drivers/hid/hid-uclogic-params.h | 5 +++++
> > 2 files changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/hid/hid-uclogic-params.c b/drivers/hid/hid-uclogic-params.c
> > index 9859dad36495..79ec3eb80f84 100644
> > --- a/drivers/hid/hid-uclogic-params.c
> > +++ b/drivers/hid/hid-uclogic-params.c
> > @@ -121,6 +121,7 @@ void uclogic_params_hid_dbg(const struct hid_device *hdev,
> > params->invalid ? "true" : "false");
> > hid_dbg(hdev, ".desc_ptr = %p\n", params->desc_ptr);
> > hid_dbg(hdev, ".desc_size = %u\n", params->desc_size);
> > + hid_dbg(hdev, ".fw_name = %s\n", params->fw_name);
> > hid_dbg(hdev, ".pen = {\n");
> > uclogic_params_pen_hid_dbg(hdev, ¶ms->pen);
> > hid_dbg(hdev, "\t}\n");
> > @@ -652,6 +653,7 @@ void uclogic_params_cleanup(struct uclogic_params *params)
> > if (!params->invalid) {
> > size_t i;
> > kfree(params->desc_ptr);
> > + kfree(params->fw_name);
> > uclogic_params_pen_cleanup(¶ms->pen);
> > for (i = 0; i < ARRAY_SIZE(params->frame_list); i++)
> > uclogic_params_frame_cleanup(¶ms->frame_list[i]);
> > @@ -837,7 +839,6 @@ static int uclogic_params_huion_init(struct uclogic_params *params,
> > /* The resulting parameters (noop) */
> > struct uclogic_params p = {0, };
> > static const char transition_ver[] = "HUION_T153_160607";
> > - char *ver_ptr = NULL;
> > const size_t ver_len = sizeof(transition_ver) + 1;
> > __u8 *params_ptr = NULL;
> > size_t params_len = 0;
> > @@ -870,14 +871,14 @@ static int uclogic_params_huion_init(struct uclogic_params *params,
> > }
> >
> > /* Try to get firmware version */
> > - ver_ptr = kzalloc(ver_len, GFP_KERNEL);
> > - if (ver_ptr == NULL) {
> > + p.fw_name = kzalloc(ver_len, GFP_KERNEL);
> > + if (!p.fw_name) {
> > rc = -ENOMEM;
> > goto cleanup;
> > }
> > - rc = usb_string(udev, 201, ver_ptr, ver_len);
> > + rc = usb_string(udev, 201, p.fw_name, ver_len);
> > if (rc == -EPIPE) {
> > - *ver_ptr = '\0';
> > + *p.fw_name = '\0';
> > } else if (rc < 0) {
> > hid_err(hdev,
> > "failed retrieving Huion firmware version: %d\n", rc);
> > @@ -885,7 +886,7 @@ static int uclogic_params_huion_init(struct uclogic_params *params,
> > }
> >
> > /* If this is a transition firmware */
> > - if (strcmp(ver_ptr, transition_ver) == 0) {
> > + if (strcmp(p.fw_name, transition_ver) == 0) {
> > hid_dbg(hdev,
> > "transition firmware detected, not probing pen v2 parameters\n");
> > } else {
> > @@ -1028,7 +1029,6 @@ static int uclogic_params_huion_init(struct uclogic_params *params,
> > rc = 0;
> > cleanup:
> > kfree(params_ptr);
> > - kfree(ver_ptr);
> > uclogic_params_cleanup(&p);
> > return rc;
> > }
> > diff --git a/drivers/hid/hid-uclogic-params.h b/drivers/hid/hid-uclogic-params.h
> > index d6ffadb2f601..412c916770f5 100644
> > --- a/drivers/hid/hid-uclogic-params.h
> > +++ b/drivers/hid/hid-uclogic-params.h
> > @@ -232,6 +232,11 @@ struct uclogic_params {
> > * List of event hooks.
> > */
> > struct uclogic_raw_event_hook *event_hooks;
> > + /*
> > + * Firmware name, exposed to userspace via sysfs as it is used to
> > + * identify the tablet.
> > + */
> > + char *fw_name;
>
> I can't remember if this was on the table or not, but any reasons to not
> use hid->uniq[64] field instead of a custom sysfs?
> If there is already a value, we could just append the firmware version
> with a colon (:) separator.
>
> The main reason would be to not export a new sysfs specifically for this
> driver, but it would also allow HID-BPF to have access to the value and
> thus allow to detect if the device works with the given bpf program.
That's a very good point.
I tested with some tablets and for HUION, the uniq field is empty.
Other vendors just put garbage there. In fact, we override it in
tablets with battery to avoid a crash [1].
So, it'll be fine to just override the garbage in that field with
an actual unique ID. Sent v2 with the sugested change [2].
Thanks,
Jose
[1] https://github.com/JoseExposito/linux/commit/9845a1304a06805c3193c58283ca428c32c14fa7#diff-b3e9836cea703e50e8febb1f09b86f92833200e7bda4c9c1ea5a1d8b569b01dbR1257-R1262
[2] https://lore.kernel.org/linux-input/20240322100210.107152-1-jose.exposito89@gmail.com/T/
> Cheers,
> Benjamin
>
> > };
> >
> > /* Driver data */
> > --
> > 2.44.0
> >
next prev parent reply other threads:[~2024-03-22 10:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 14:38 [PATCH 0/2] Expose firmware name to identify tablets in libwacom José Expósito
2024-03-21 14:38 ` [PATCH 1/2] HID: uclogic: Store firmware name in params José Expósito
2024-03-21 15:01 ` Benjamin Tissoires
2024-03-22 10:06 ` José Expósito [this message]
2024-03-21 14:38 ` [PATCH 2/2] HID: uclogic: Expose firmware name via sysfs José Expósito
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=Zf1YFQh-S6_21Hwx@fedora \
--to=jose.exposito89@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=bentiss@kernel.org \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.