summaryrefslogtreecommitdiff
path: root/drivers/media/rc/ir-rc6-decoder.c
diff options
context:
space:
mode:
authorDavid Härdeman <david@hardeman.nu>2014-04-04 03:31:51 +0400
committerMauro Carvalho Chehab <m.chehab@samsung.com>2014-07-24 04:26:08 +0400
commitaf3a4a9bbeb00df3e42e77240b4cdac5479812f9 (patch)
treec58da3eef556c0122365bd3d0b37243fcf988842 /drivers/media/rc/ir-rc6-decoder.c
parent4dd9bb91bb5dc44e3f8c23c60a0ba432e50d7488 (diff)
downloadlinux-af3a4a9bbeb00df3e42e77240b4cdac5479812f9.tar.xz
[media] dib0700: NEC scancode cleanup
the RC RX packet is defined as: struct dib0700_rc_response { ... u8 not_system; u8 system; ... u8 data; u8 not_data; The NEC protocol transmits in the order: system not_system data not_data Note that the code defines the NEC extended scancode as: scancode = be16_to_cpu(poll_reply->system16) << 8 | poll_reply->data; i.e. scancode = poll_reply->not_system << 16 | poll_reply->system << 8 | poll_reply->data; Which, if the order *is* reversed, would mean that the scancode that gets defined is in reality: scancode = poll_reply->system << 16 | poll_reply->not_system << 8 | poll_reply->data; Which is the same as the order used in drivers/media/rc/ir-nec-decoder.c. This patch changes the code to match my assumption (the generated scancode should, however, not change). [m.chehab@samsung.com: rebased and fixed the decoding error message] Signed-off-by: David Härdeman <david@hardeman.nu> CC: Patrick Boettcher <pboettcher@kernellabs.com> Tested-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Diffstat (limited to 'drivers/media/rc/ir-rc6-decoder.c')
0 files changed, 0 insertions, 0 deletions