From: "Filipe Laíns" <lains@archlinux.org>
To: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] HID: logitech-hidpp: add support for Unified Battery (1004) feature
Date: Fri, 08 Jan 2021 15:01:53 +0000 [thread overview]
Message-ID: <d65b0829d31ed6eb15f69b8771718d38a56a2502.camel@archlinux.org> (raw)
In-Reply-To: <nycvar.YFH.7.76.2101081554190.13752@cbobk.fhfr.pm>
[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]
On Fri, 2021-01-08 at 15:55 +0100, Jiri Kosina wrote:
> On Fri, 8 Jan 2021, Filipe Laíns wrote:
> > The problem here is that hidpp20_query_battery_info_1004() does not set
> > battery voltage, it is also the battery level. The best alternative Ican
> > think
> > of is replacing the 1000/1004 with slightly mangled HID++ feature names,
> > like we
> > do on the other feature function. The drawback here is that I think that
> > could
> > get confusing quickly.
> >
> > hidpp20_batterylevel_query_battery_info()
> > hidpp20_unifiedbattery_query_battery_info()
> >
> > Note that this does not provide *that* much more information than the
> > feature
> > number, though it is probably the best option. What do you think?
>
> Alright, what a mess :) Would it perhaps help if there is at least a short
> comment preceding the function definition, noting what the constants
> actually are?
Yeah :head_scratch:
There is a header comment at the start of each feature section, which I think
does a good job pointing this out. IMO the problem with the naming is more for
people who see its usage in other parts of the code, but I guess that is C for
you right? Names don't scale well with code quantity :P
/* -------------------------------------------------------------------------- */
/* 0x1000: Battery level status */
/* -------------------------------------------------------------------------- */
/* -------------------------------------------------------------------------- */
/* 0x1004: Unified battery */
/* -------------------------------------------------------------------------- */
> > > Could you please use standard kernel commenting style here?
> >
> > Oops, sorry. Will do :)
>
> Thanks,
>
Cheers,
Filipe Laíns
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-01-08 15:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 18:29 [PATCH] HID: logitech-hidpp: add support for Unified Battery (1004) feature lains
2021-01-06 9:34 ` Bastien Nocera
2021-01-06 18:48 ` Filipe Laíns
2021-01-06 19:17 ` Bastien Nocera
2021-01-08 13:44 ` Jiri Kosina
2021-01-08 14:53 ` Filipe Laíns
2021-01-08 14:55 ` Jiri Kosina
2021-01-08 15:01 ` Filipe Laíns [this message]
2021-01-18 10:02 ` Jiri Kosina
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=d65b0829d31ed6eb15f69b8771718d38a56a2502.camel@archlinux.org \
--to=lains@archlinux.org \
--cc=benjamin.tissoires@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).