Em Sat, 25 Aug 2012 23:47:08 +0200 David Härdeman <david@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
