mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Filipe Laíns" <lains@archlinux.org>
To: "Kamil Domański" <kamil@domanski.co>, linux-kernel@vger.kernel.org
Cc: Jiri Kosina <jikos@kernel.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Nestor Lopez Casado <nlopezcasad@logitech.com>
Subject: Re: [PATCH v2] HID: logitech-hidpp: add support for Logitech G533 headset
Date: Sat, 04 Jul 2020 15:48:30 +0100	[thread overview]
Message-ID: <908bf287f370a947e60bc7817b395c91c5be63d9.camel@archlinux.org> (raw)
In-Reply-To: <52609283-6d37-9e0e-be24-7df378e4fead@domanski.co>

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On Sat, 2020-07-04 at 02:37 +0200, Kamil Domański wrote:
> Hi Filipe,
> 
> > My main point here is that long means different things in different
> > architectures, and we only want one byte so I would go for u8.
> 
> I used long, because the test_bit macro accepts long and the similar
> function for voltage reading already used long too.
> That will be changed in v3 - see next paragraph.

The compiler can handle these conversions. Explicit is generally better
than implicit, and in cases where the implicit assumptions might break,
explicit is definitely better. We know the data size, so let's use it
:D

> > > +
> > > +	*voltage = get_unaligned_be16(data);
> > > +	isConnected = test_bit(0, &flags);
> > > +	isCharging = test_bit(1, &flags);
> > > +	chargingComplete = test_bit(2, &flags);
> > > +	chargingFault = test_bit(3, &flags);
> > > I don't think this is needed, just do it in the ifs directly.
> > > 
> > > Here I would add a #define for each bit:
> > > 
> > > #define FLAG_ADC_MAP_STATUS_CONNECTED 0
> > > ...
> > > if (data[2] & FLAG_ADC_MAP_STATUS_CONNECTED)
> 
> Yeah, I it will do exactly that for v3, which allows to drop the flag
> variables and avoid using a long.
> 
>  
> > Same thing here. We should see if the device supports the DJ protocol
> > and add it in hid-logitech-dj instead.
> 
> It doesn't seem to be a DJ device. The DJ driver just detects the extra interfaces
> and skips directly to hid_hw_start.

Thanks for looking into this!

Cheers,
Filipe Laíns

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-07-04 14:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <023148f582cc20bef7079508ce417c8ebeb0febb.camel@domanski.co>
2020-06-05 15:15 ` Filipe Laíns
2020-07-04  0:37   ` Kamil Domański
2020-07-04 14:48     ` Filipe Laíns [this message]
2020-06-19  7:19 ` 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=908bf287f370a947e60bc7817b395c91c5be63d9.camel@archlinux.org \
    --to=lains@archlinux.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=jikos@kernel.org \
    --cc=kamil@domanski.co \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nlopezcasad@logitech.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

all inboxes | Powered by JetHome®