Re: [PATCH 4/8] rc-core: don't throw away protocol information

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em Sat, 25 Aug 2012 23:47:08 +0200
David Härdeman <david@hardeman.nu> escreveu:


Pathes 1 to 3 are OK. Applied, thanks!

...

> +#define RC_SCANCODE_UNKNOWN(x) (x)
> +#define RC_SCANCODE_OTHER(x) (x)
> +#define RC_SCANCODE_NEC(addr, cmd) (((addr) << 8) | (cmd))
> +#define RC_SCANCODE_NECX(addr, cmd) (((addr) << 8) | (cmd))
> +#define RC_SCANCODE_NEC32(data) ((data) & 0xffffffff)
> +#define RC_SCANCODE_RC5(sys, cmd) (((sys) << 8) | (cmd))
> +#define RC_SCANCODE_RC5_SZ(sys, cmd) (((sys) << 8) | (cmd))
> +#define RC_SCANCODE_RC6_0(sys, cmd) (((sys) << 8) | (cmd))
> +#define RC_SCANCODE_RC6_6A(vendor, sys, cmd) (((vendor) << 16) | ((sys) << 8) | (cmd))


Huh? You're defining the same code for NEC, NECX, RC5, ...

Why? It seems better to have one macro for (up to) 16 bit protocols,
and another one for the two 32 bit ones.

Btw, on several drivers, you're using the wrong macro name. It doesn't seem
fine to miss-use it.

For example, see the generic I2C driver: several of the remote controllers
there are NEC[1]. Yet, you're using there the RC5 variant.

[1] Currently, they're using "other" because we don't have that IR's or the
devices that use it here, in order to make it scan the full NEC (or NEC
variant) code.

-- 
Regards,
Mauro