IR driver for USB-UIRT device
Subsystems (4)
Sean Young
maintainerv5 cover IR driver for USB-UIRT device
This is a new rc-core driver for the USB-UIRT which you can see here
http://www.usbuirt.com/
This device is supported in lirc, via the usb serial kernel driver. This driver is both for rc-core, which means it can use kernel/BPF decoding ec. Also this implement is superior because it can:
- support learning mode
- setting transmit carrier
- larger transmits using streaming tx command
- Much better latency since it is a kernel driver
Changes since v4:
- Fixed clang warning/uninitialized variable usage
- Some cosmetic changes
Changes since v3:
- Review comments from Johan Hovold
- Do not move the ftdi_sio.h file an copy FTDI_* definitions instead
Changes since v2:
- Fixed race condition is disconnect
- Removed superfluous kmalloc in short tx
Changes since v1:
- Review comments from Oliver Neukum
- Simplified wideband read function
Sean Young (2):
media: rc: new driver for USB-UIRT device
USB: serial: blacklist USB-UIRT when driver is selected
drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/uirt.c | 744 ++++++++++++++++++++++++++++++++++ drivers/usb/serial/ftdi_sio.c | 6 +- 4 files changed, 760 insertions(+), 2 deletions(-) create mode 100644 drivers/media/rc/uirt.c
Signature · 1 line
2.31.1
Sean Young
maintainerPATCH v5 1/2 media: rc: new driver for USB-UIRT device
This device uses an ftdi usb serial port, so this driver has a tiny amount of usb ftdi code. It would be preferable to connect this driver via serdev or line-discipline, but unfortunately neither support hotplugging yet.
--- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/uirt.c | 744 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 756 insertions(+) create mode 100644 drivers/media/rc/uirt.c
drivers/media/rc/Kconfig +11 -0
@@ -471,6 +471,17 @@ config IR_TOY To compile this driver as a module, choose M here: the module will be called ir_toy. +config IR_UIRT + tristate "USB-UIRT" + depends on RC_CORE + depends on USB_ARCH_HAS_HCD + help + Say Y here if you want to use the USB-UIRT. See + http://www.usbuirt.com/ + + To compile this driver as a module, choose M here: the module will be + called uirt. + endif #RC_DEVICES endif #RC_CORE
drivers/media/rc/Makefile +1 -0
@@ -50,3 +50,4 @@ obj-$(CONFIG_IR_SIR) += sir_ir.o obj-$(CONFIG_IR_MTK) += mtk-cir.o obj-$(CONFIG_RC_XBOX_DVD) += xbox_remote.o obj-$(CONFIG_IR_TOY) += ir_toy.o +obj-$(CONFIG_IR_UIRT) += uirt.o
drivers/media/rc/uirt.c new file +744 -0
744 lines not on this page · raw message
Signature · 1 line
2.31.1
Johan Hovold
maintainerRe: [PATCH v5 1/2] media: rc: new driver for USB-UIRT device
Quoted 176 lines · Sean Young
This device uses an ftdi usb serial port, so this driver has a tiny amount of usb ftdi code. It would be preferable to connect this driver via serdev or line-discipline, but unfortunately neither support hotplugging yet.
Signed-off-by Sean Young <[email protected]>--- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/uirt.c | 744 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 756 insertions(+) create mode 100644 drivers/media/rc/uirt.cdrivers/media/rc/Kconfig +11
-0@@ -471,6 +471,17 @@ config IR_TOY To compile this driver as a module, choose M here: the module will be called ir_toy. +config IR_UIRT + tristate "USB-UIRT" + depends on RC_CORE + depends on USB_ARCH_HAS_HCD + help + Say Y here if you want to use the USB-UIRT. See + http://www.usbuirt.com/ + + To compile this driver as a module, choose M here: the module will be + called uirt. + endif #RC_DEVICES endif #RC_COREdrivers/media/rc/Makefile +1
-0@@ -50,3 +50,4 @@ obj-$(CONFIG_IR_SIR) += sir_ir.o obj-$(CONFIG_IR_MTK) += mtk-cir.o obj-$(CONFIG_RC_XBOX_DVD) += xbox_remote.o obj-$(CONFIG_IR_TOY) += ir_toy.o +obj-$(CONFIG_IR_UIRT) += uirt.odrivers/media/rc/uirt.c new file +124
-0@@ -0,0 +1,744 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +/* +* USB-UIRT +* +* Copyright (C) 2021 Sean Young <[email protected]> +* +* See http://www.usbuirt.com/USB-UIRT%20Command%20Protocol.doc +*/ + +#include <linux/completion.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/usb.h> +#include <linux/slab.h> +#include <linux/usb/input.h> + +#include <media/rc-core.h> + +/* Copied from drivers/usb/serial/ftdi_sio.h */ +#define FTDI_SIO_SET_BAUDRATE_REQUEST_TYPE 0x40 +#define FTDI_SIO_SET_BAUDRATE_REQUEST 3 + +#define FTDI_SIO_SET_LATENCY_TIMER_REQUEST FTDI_SIO_SET_LATENCY_TIMER +#define FTDI_SIO_SET_LATENCY_TIMER_REQUEST_TYPE 0x40 + +#define FTDI_SIO_SET_FLOW_CTRL_REQUEST_TYPE 0x40 +#define FTDI_SIO_SET_FLOW_CTRL_REQUEST FTDI_SIO_SET_FLOW_CTRL + +#define FTDI_SIO_SET_FLOW_CTRL 2/* Set flow control register */ +#define FTDI_SIO_SET_LATENCY_TIMER 9/* Set the latency timer */ + +#define FTDI_SIO_RTS_CTS_HS BIT(8) +#define FTDI_RS0_CTS BIT(4) + +static const u8 CMD_GETVERSION [] = {0x23 ,0xdd }; +static const u8 CMD_SETMODERAW [] = {0x21 ,0xdf }; +static const u8 CMD_SETWIDEBAND [] = {0x24 ,0xdc }; + +#define UNIT_US 50 +#define IR_TIMEOUT 12500 +#define MAX_PACKET 64 + +enum cmd_state { +CMD_STATE_GETVERSION , +CMD_STATE_SETMODERAW , +CMD_STATE_SETMODEWIDEBAND , +CMD_STATE_IRDATA , +CMD_STATE_DOTXRAW , +CMD_STATE_STREAMING_TX , +}; + +enum rx_state { +RX_STATE_INTERSPACE_HIGH , +RX_STATE_INTERSPACE_LOW , +RX_STATE_ON_HIGH , +RX_STATE_ON_LOW , +RX_STATE_FREQ_HIGH , +RX_STATE_FREQ_LOW , +RX_STATE_OFF_HIGH , +RX_STATE_OFF_LOW , +}; + +struct uirt { +struct device *dev; +struct usb_device *usbdev; + +struct rc_dev *rc; +struct urb *urb_in, *urb_out; + +u8 *in; +u8 *out; +struct completion cmd_done; +u8 freq; +u8 high; +bool wideband; +u32 last_duration; + +enum cmd_state cmd_state; +enum rx_state rx_state; + +void *tx_buf; +u32 tx_len; + +char phys[64 ]; +}; + +// read IR in raw mode +static void uirt_raw_mode (struct uirt *uirt,u32 offset,u32 len) +{ +uint i, duration; + +for (i = offset; i < len; i++) { +switch (uirt->rx_state) { +case RX_STATE_INTERSPACE_HIGH : + uirt->rx_state =RX_STATE_INTERSPACE_LOW ; +break ; +case RX_STATE_INTERSPACE_LOW : + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +case RX_STATE_ON_HIGH : + duration = uirt->in[i]; +if (duration ==0 ) + duration =1 ; + +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration *UNIT_US , + .pulse = true, + })); + + uirt->rx_state =RX_STATE_OFF_HIGH ; +break ; +case RX_STATE_OFF_HIGH : +if (uirt->in[i] ==0xff ) { +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration =IR_TIMEOUT , + .timeout = true, + })); + uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; +break ; + } + + duration = uirt->in[i]; +if (duration ==0 )
drivers/media/rc/uirt.c line 134
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+ duration =1 ; + +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration *UNIT_US , + .pulse = false, + })); + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +default : +WARN (1 ,"unreachable state" );
This should probably be dev_warn_ratelimited() or similar. Judging from a quick look a malicious device can end up triggering this.
Quoted 94 lines
drivers/media/rc/uirt.c new file +94
-0+ uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; +break ; + } + } + +ir_raw_event_handle (uirt->rc); +} + +// Read IR in wideband mode. The byte stream is delivered in packets, +// and the values which come in two bytes may straddle two packets +static void uirt_wideband (struct uirt *uirt,u32 offset,u32 len) +{ +uint i, duration, carrier, pulses; + +for (i = offset; i < len; i++) { +switch (uirt->rx_state) { +case RX_STATE_INTERSPACE_HIGH : + uirt->rx_state =RX_STATE_INTERSPACE_LOW ; +break ; +case RX_STATE_INTERSPACE_LOW : + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +case RX_STATE_ON_HIGH : + uirt->high = uirt->in[i]; + uirt->rx_state =RX_STATE_ON_LOW ; +break ; +case RX_STATE_ON_LOW : +// duration is in 400ns units + duration = (uirt->high <<8 ) | uirt->in[i]; + uirt->last_duration = duration; +// Convert to microseconds + duration =DIV_ROUND_CLOSEST (duration *2 ,5 ); +if (duration ==0 ) + duration =1 ; +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration, + .pulse = true, + })); + uirt->rx_state =RX_STATE_FREQ_HIGH ; +break ; +case RX_STATE_FREQ_HIGH : +if (uirt->in[i] &0x80 ) { + uirt->high = uirt->in[i] &0x7f ; + uirt->rx_state =RX_STATE_FREQ_LOW ; +break ; + } + + uirt->high =0 ; + fallthrough; +case RX_STATE_FREQ_LOW : + pulses = (uirt->high <<8 ) | uirt->in[i]; +if (pulses && uirt->last_duration) { +dev_dbg (uirt->dev,"carrier duration %u pulses %u" , + uirt->last_duration, pulses); + +// calculate the Hz of pulses in duration 400ns units + carrier =DIV_ROUND_CLOSEST_ULL (pulses *10000000ull , + uirt->last_duration *4 ); +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .carrier = carrier, + .carrier_report = true, + })); + } + uirt->rx_state =RX_STATE_OFF_HIGH ; +break ; +case RX_STATE_OFF_HIGH : +if (uirt->in[i] ==0xff ) { +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration =IR_TIMEOUT , + .timeout = true, + })); + uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; + }else { + uirt->high = uirt->in[i]; + uirt->rx_state =RX_STATE_OFF_LOW ; + } +break ; +case RX_STATE_OFF_LOW : +// Convert 400ns units to microseconds + duration =DIV_ROUND_CLOSEST (((uirt->high <<8 ) | uirt->in[i]) *2 ,5 ); +if (duration ==0 ) + duration =1 ; +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration, + .pulse = false, + })); + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; + } + } + +ir_raw_event_handle (uirt->rc); +} +
drivers/media/rc/uirt.c line 238
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+static void uirt_response (struct uirt *uirt,u32 len) +{ +int offset =2 ; +int i; + +dev_dbg (uirt->dev,"state:%d data: %*phN\n" , uirt->cmd_state, len, uirt->in); + +// Do we have more IR to transmit and is Clear-To-Send set +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX && len >=2 && + uirt->tx_len && uirt->in[0 ] &FTDI_RS0_CTS ) {
Do you really need to handle this manually when you have hardware assisted flow control enabled?
Quoted 26 lines
drivers/media/rc/uirt.c new file +26
-0+u32 len; +int err; + + len =min_t (u32, uirt->tx_len,MAX_PACKET ); + +memcpy (uirt->out, uirt->tx_buf, len); + uirt->urb_out->transfer_buffer_length = len; + + uirt->tx_len -= len; + uirt->tx_buf += len; + + err =usb_submit_urb (uirt->urb_out,GFP_ATOMIC ); +if (err !=0 ) +dev_warn (uirt->dev, +"failed to submit out urb: %d\n" , err); + } + +// if we only have two bytes, it just gives us the serial line status +if (len <=2 ) +return ; + +// We have to assume that the response to a command is at the beginning +// of the packet. There is no way to distinguish IR data from command +// responses other than the position in the byte stream. +switch (uirt->cmd_state) { +case CMD_STATE_GETVERSION :
drivers/media/rc/uirt.c line 274
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+if (len >=10 ) { +// check checksum +u8 checksum =0 ; + +for (i =2 ; i < len; i++) + checksum += uirt->in[i]; + +if (checksum !=0 ) { +dev_err (uirt->dev,"checksum does not match: %*phN\n" , + len, uirt->in);
Should this not be ratelimited too in case you get out of sync?
drivers/media/rc/uirt.c line 279
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+return ; + } + + dev_info(uirt->dev, + "USB-UIRT firmware v%u.%u protocol v%u.%u %04u-%02u-%02u",
Missing '\n' and in a lot of other printks throughout.
Quoted 13 lines
drivers/media/rc/uirt.c new file +13
-0+ uirt->in[2 ], uirt->in[3 ], uirt->in[4 ], uirt->in[5 ], + uirt->in[8] + 2000, uirt->in[7], uirt->in[6]); + +complete (&uirt->cmd_done); + uirt->cmd_state =CMD_STATE_IRDATA ; + offset +=10 ; + } +break ; +case CMD_STATE_DOTXRAW : +case CMD_STATE_STREAMING_TX : +case CMD_STATE_SETMODERAW : +case CMD_STATE_SETMODEWIDEBAND : +if (len >=3 ) {
drivers/media/rc/uirt.c line 302
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+switch (uirt->in[2 ]) { +case 0x20 : +// 0x20 transmitting is expected during streaming tx +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX ) +return ; + +if (uirt->cmd_state ==CMD_STATE_DOTXRAW ) +complete (&uirt->cmd_done); +else +dev_err (uirt->dev,"device transmitting" );
I think most of these printks need to be ratelimited or dev_dbg() since bad input input can trigger them.
Another missing newline, but please fix throughout.
Quoted 101 lines
drivers/media/rc/uirt.c new file +99
-0+break ; +case 0x21 : +if (uirt->tx_len) { +dev_err (uirt->dev,"tx completed with %u left to send" , + uirt->tx_len); + }else { +if (uirt->cmd_state ==CMD_STATE_SETMODERAW ) + uirt->wideband = false; +if (uirt->cmd_state ==CMD_STATE_SETMODEWIDEBAND ) + uirt->wideband = true; + +complete (&uirt->cmd_done); + } +break ; +case 0x80 : +dev_err (uirt->dev,"checksum error" ); +break ; +case 0x81 : +dev_err (uirt->dev,"timeout" ); +break ; +case 0x82 : +dev_err (uirt->dev,"command error" ); +break ; +default : +dev_err (uirt->dev,"unknown response" ); + } + + uirt->cmd_state =CMD_STATE_IRDATA ; + offset +=1 ; + } +default : +break ; + } + +if (uirt->wideband) +uirt_wideband (uirt, offset, len); +else +uirt_raw_mode (uirt, offset, len); +} +static int uirt_command (struct uirt *uirt,const u8 *cmd,u32 cmd_len, +enum cmd_state state) +{ +int err; + +init_completion (&uirt->cmd_done); + + uirt->cmd_state = state; + +memcpy (uirt->out, cmd, cmd_len); + uirt->urb_out->transfer_buffer_length = cmd_len; + + err =usb_submit_urb (uirt->urb_out,GFP_KERNEL ); +if (err !=0 ) { + uirt->cmd_state =CMD_STATE_IRDATA ; +return err; + } + +if (!wait_for_completion_timeout (&uirt->cmd_done, +msecs_to_jiffies (USB_CTRL_SET_TIMEOUT ))) { +usb_kill_urb (uirt->urb_out); + uirt->cmd_state =CMD_STATE_IRDATA ; +return -ETIMEDOUT ; + } + +return 0 ; +} +static int uirt_tx (struct rc_dev *rc,uint *txbuf,uint count) +{ +struct uirt *uirt = rc->priv; +u8 *out; +u32 i, dest, unit_raw, freq, len; +int err; + +// streaming tx does not work for short IR; use non-streaming +// tx for short IR +if (count <=24 ) +return uirt_short_tx (rc, txbuf, count); + + out =kmalloc (count *2 +3 ,GFP_KERNEL ); +if (!out) +return -ENOMEM ; + + out[0 ] =0x25 ;// Streaming Transmit + out[1 ] =0xdb ;// checksum over command (just the previous byte) + out[2 ] = uirt->freq;// carrier frequency + + dest =3 ; + + freq = uirt->freq &0x7f ; + +for (i =0 ; i < count; i++) { +// width = (us / freq) * 2.5 + unit_raw =DIV_ROUND_CLOSEST (txbuf[i] *5 , freq *2 ); + +if (unit_raw ==0 ) + unit_raw =1 ; +else if (unit_raw >127 ) + out[dest++] = (unit_raw >>8 ) |0x80 ; +
drivers/media/rc/uirt.c line 516
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+ out[dest++] = unit_raw; + } + + len =min_t (u32, dest,MAX_PACKET ); + + uirt->tx_buf = out + len; + uirt->tx_len = dest - len; + + err =uirt_command (uirt, out, len,CMD_STATE_STREAMING_TX ); +kfree (out);
This look fragile; are you sure nothing can access uirt_tx->buf (out) after the command returns here?
Quoted 41 lines
drivers/media/rc/uirt.c new file +41
-0+if (err !=0 ) +return err; + +return count; +} + +static int uirt_set_tx_carrier (struct rc_dev *dev,u32 carrier) +{ +struct uirt *uirt = dev->priv; + +if (carrier ==0 ) +// bit 7 must be 1 for unmodulated, lower bits need to +// be something that makes sense for tx + uirt->freq =0xc0 ; +else if (carrier >=20000 && carrier <=500000 ) +// bit 7 must be 0 for modulated + uirt->freq =2500000 / carrier; +else +return -EINVAL ; + +return 0 ; +} + +static int uirt_set_rx_wideband (struct rc_dev *dev,int enable) +{ +struct uirt *uirt = dev->priv; +int err; + +if (enable) + err =uirt_command (uirt,CMD_SETWIDEBAND , +sizeof (CMD_SETWIDEBAND ), +CMD_STATE_SETMODEWIDEBAND ); +else + err =uirt_command (uirt,CMD_SETMODERAW , +sizeof (CMD_SETMODERAW ), +CMD_STATE_SETMODERAW ); + +if (err) { +dev_err (uirt->dev,"set mode command failed: %d\n" , + err); +return err;
drivers/media/rc/uirt.c line 567
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+ } + +return 0 ; +} + +static int init_ftdi (struct usb_device *udev) +{ +int err; + +// set the baud rate
Please mention the rate here too.
Quoted 20 lines
drivers/media/rc/uirt.c new file +20
-0+ err =usb_control_msg (udev,usb_sndctrlpipe (udev,0 ), +FTDI_SIO_SET_BAUDRATE_REQUEST , +FTDI_SIO_SET_BAUDRATE_REQUEST_TYPE , +0x4009 ,0x0001 , +NULL ,0 ,USB_CTRL_SET_TIMEOUT ); +if (err) +return err; + +// enabling rts/cts flow control + err =usb_control_msg (udev,usb_sndctrlpipe (udev,0 ), +FTDI_SIO_SET_FLOW_CTRL_REQUEST , +FTDI_SIO_SET_FLOW_CTRL_REQUEST_TYPE , +0 ,FTDI_SIO_RTS_CTS_HS , +NULL ,0 ,USB_CTRL_SET_TIMEOUT ); +if (err) +return err; + +// Set latency in milliseconds. The USB-UIRT will generate a +// urb every latency milliseconds (IR or not), so this should be +// set as high as possible to reduce interrupts. However, setting
drivers/media/rc/uirt.c line 597
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+// this value too high will mean there is a preceptible delay for +// IR being processed and a key press being registered. +// +// Choose 50ms as a compromise. +return usb_control_msg (udev,usb_sndctrlpipe (udev,0 ), +FTDI_SIO_SET_LATENCY_TIMER_REQUEST , +FTDI_SIO_SET_LATENCY_TIMER_REQUEST_TYPE , +50 ,0 , +NULL ,0 ,USB_CTRL_SET_TIMEOUT ); +}
Johan
Johan Hovold
maintainerRe: [PATCH v5 1/2] media: rc: new driver for USB-UIRT device
Quoted 49 lines · Johan Hovold
Quoted 34 lines · Sean Young
This device uses an ftdi usb serial port, so this driver has a tiny amount of usb ftdi code. It would be preferable to connect this driver via serdev or line-discipline, but unfortunately neither support hotplugging yet.
Signed-off-by Sean Young <[email protected]>---
drivers/media/rc/uirt.c new file +23
-0+struct uirt { +struct device *dev; +struct usb_device *usbdev; + +struct rc_dev *rc; +struct urb *urb_in, *urb_out; + +u8 *in; +u8 *out; +struct completion cmd_done; +u8 freq; +u8 high; +bool wideband; +u32 last_duration; + +enum cmd_state cmd_state; +enum rx_state rx_state; + +void *tx_buf; +u32 tx_len; + +char phys[64 ]; +};drivers/media/rc/uirt.c
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+static void uirt_response (struct uirt *uirt,u32 len) +{ +int offset =2 ; +int i; + +dev_dbg (uirt->dev,"state:%d data: %*phN\n" , uirt->cmd_state, len, uirt->in); + +// Do we have more IR to transmit and is Clear-To-Send set +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX && len >=2 && + uirt->tx_len && uirt->in[0 ] &FTDI_RS0_CTS ) {Do you really need to handle this manually when you have hardware assisted flow control enabled?
Quoted 15 lines
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+u32 len; +int err; + + len =min_t (u32, uirt->tx_len,MAX_PACKET ); +drivers/media/rc/uirt.c line 253
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+memcpy (uirt->out, uirt->tx_buf, len); + uirt->urb_out->transfer_buffer_length = len; + + uirt->tx_len -= len; + uirt->tx_buf += len; + + err =usb_submit_urb (uirt->urb_out,GFP_ATOMIC ); +if (err !=0 ) +dev_warn (uirt->dev, +"failed to submit out urb: %d\n" , err);
Also, this looks entirely broken since you don't have any synchronisation with uirt_command() below which may try to submit the same URB in parallel.
Quoted 75 lines
Quoted 61 lines
drivers/media/rc/uirt.c new file +60
-0+static int uirt_command (struct uirt *uirt,const u8 *cmd,u32 cmd_len, +enum cmd_state state) +{ +int err; + +init_completion (&uirt->cmd_done); + + uirt->cmd_state = state; + +memcpy (uirt->out, cmd, cmd_len); + uirt->urb_out->transfer_buffer_length = cmd_len; + + err =usb_submit_urb (uirt->urb_out,GFP_KERNEL ); +if (err !=0 ) { + uirt->cmd_state =CMD_STATE_IRDATA ; +return err; + } + +if (!wait_for_completion_timeout (&uirt->cmd_done, +msecs_to_jiffies (USB_CTRL_SET_TIMEOUT ))) { +usb_kill_urb (uirt->urb_out); + uirt->cmd_state =CMD_STATE_IRDATA ; +return -ETIMEDOUT ; + } + +return 0 ; +} +static int uirt_tx (struct rc_dev *rc,uint *txbuf,uint count) +{ +struct uirt *uirt = rc->priv; +u8 *out; +u32 i, dest, unit_raw, freq, len; +int err; + +// streaming tx does not work for short IR; use non-streaming +// tx for short IR +if (count <=24 ) +return uirt_short_tx (rc, txbuf, count); + + out =kmalloc (count *2 +3 ,GFP_KERNEL ); +if (!out) +return -ENOMEM ; + + out[0 ] =0x25 ;// Streaming Transmit + out[1 ] =0xdb ;// checksum over command (just the previous byte) + out[2 ] = uirt->freq;// carrier frequency + + dest =3 ; + + freq = uirt->freq &0x7f ; + +for (i =0 ; i < count; i++) { +// width = (us / freq) * 2.5 + unit_raw =DIV_ROUND_CLOSEST (txbuf[i] *5 , freq *2 ); + +if (unit_raw ==0 ) + unit_raw =1 ; +else if (unit_raw >127 ) + out[dest++] = (unit_raw >>8 ) |0x80 ; +drivers/media/rc/uirt.c line 516
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+ out[dest++] = unit_raw; + } + + len =min_t (u32, dest,MAX_PACKET ); + + uirt->tx_buf = out + len; + uirt->tx_len = dest - len; + + err =uirt_command (uirt, out, len,CMD_STATE_STREAMING_TX ); +kfree (out);This look fragile; are you sure nothing can access
uirt_tx->buf(out) after the command returns here?
Quoted 5 lines
drivers/media/rc/uirt.c line 472
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+if (err !=0 ) +return err; + +return count; +}
Johan
Sean Young
maintainerRe: [PATCH v5 1/2] media: rc: new driver for USB-UIRT device
Quoted 61 lines · Johan Hovold
Quoted 60 lines · Johan Hovold
Quoted 34 lines · Sean Young
This device uses an ftdi usb serial port, so this driver has a tiny amount of usb ftdi code. It would be preferable to connect this driver via serdev or line-discipline, but unfortunately neither support hotplugging yet.
Signed-off-by Sean Young <[email protected]>---
drivers/media/rc/uirt.c new file +23
-0+struct uirt { +struct device *dev; +struct usb_device *usbdev; + +struct rc_dev *rc; +struct urb *urb_in, *urb_out; + +u8 *in; +u8 *out; +struct completion cmd_done; +u8 freq; +u8 high; +bool wideband; +u32 last_duration; + +enum cmd_state cmd_state; +enum rx_state rx_state; + +void *tx_buf; +u32 tx_len; + +char phys[64 ]; +};drivers/media/rc/uirt.c
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+static void uirt_response (struct uirt *uirt,u32 len) +{ +int offset =2 ; +int i; + +dev_dbg (uirt->dev,"state:%d data: %*phN\n" , uirt->cmd_state, len, uirt->in); + +// Do we have more IR to transmit and is Clear-To-Send set +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX && len >=2 && + uirt->tx_len && uirt->in[0 ] &FTDI_RS0_CTS ) {Do you really need to handle this manually when you have hardware assisted flow control enabled?
Quoted 11 lines
drivers/media/rc/uirt.c new file +11
-0+u32 len; +int err; + + len =min_t (u32, uirt->tx_len,MAX_PACKET ); + +memcpy (uirt->out, uirt->tx_buf, len); + uirt->urb_out->transfer_buffer_length = len; + + uirt->tx_len -= len; + uirt->tx_buf += len; +
Quoted 8 lines
Quoted 4 lines
drivers/media/rc/uirt.c line 253
Quoted 4 lines
drivers/media/rc/uirt.c new file +4
-0+ err =usb_submit_urb (uirt->urb_out,GFP_ATOMIC ); +if (err !=0 ) +dev_warn (uirt->dev, +"failed to submit out urb: %d\n" , err);Also, this looks entirely broken since you don't have any synchronisation with
uirt_command()below which may try to submit the same URB in parallel.
uirt_command() only gets called via lirc chardev ioctl/write ops; the lirc chardev code does locking for the drivers already. So, if someone does a write to /dev/lirc0 (which means transmit) the mutex is taken, no other writes/ioctls are allowed on /dev/lirc0; the uirt_tx() calls uirt_command() which waits for completion. During this period the code above can be executed, but not after the transmit succeeds or fails (when the lircdev chardev mutex is released, see:
Having said all that this is not evident from code at all. A comment could really help.
Thanks,
Sean
Johan Hovold
maintainerRe: [PATCH v5 1/2] media: rc: new driver for USB-UIRT device
Quoted 79 lines · Sean Young
Quoted 61 lines · Johan Hovold
Quoted 60 lines · Johan Hovold
Quoted 34 lines · Sean Young
This device uses an ftdi usb serial port, so this driver has a tiny amount of usb ftdi code. It would be preferable to connect this driver via serdev or line-discipline, but unfortunately neither support hotplugging yet.
Signed-off-by Sean Young <[email protected]>---
drivers/media/rc/uirt.c new file +23
-0+struct uirt { +struct device *dev; +struct usb_device *usbdev; + +struct rc_dev *rc; +struct urb *urb_in, *urb_out; + +u8 *in; +u8 *out; +struct completion cmd_done; +u8 freq; +u8 high; +bool wideband; +u32 last_duration; + +enum cmd_state cmd_state; +enum rx_state rx_state; + +void *tx_buf; +u32 tx_len; + +char phys[64 ]; +};drivers/media/rc/uirt.c
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+static void uirt_response (struct uirt *uirt,u32 len) +{ +int offset =2 ; +int i; + +dev_dbg (uirt->dev,"state:%d data: %*phN\n" , uirt->cmd_state, len, uirt->in); + +// Do we have more IR to transmit and is Clear-To-Send set +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX && len >=2 && + uirt->tx_len && uirt->in[0 ] &FTDI_RS0_CTS ) {Do you really need to handle this manually when you have hardware assisted flow control enabled?
Quoted 11 lines
drivers/media/rc/uirt.c new file +11
-0+u32 len; +int err; + + len =min_t (u32, uirt->tx_len,MAX_PACKET ); + +memcpy (uirt->out, uirt->tx_buf, len); + uirt->urb_out->transfer_buffer_length = len; + + uirt->tx_len -= len; + uirt->tx_buf += len; +Quoted 8 lines
Quoted 4 lines
drivers/media/rc/uirt.c line 253
Quoted 4 lines
drivers/media/rc/uirt.c new file +4
-0+ err =usb_submit_urb (uirt->urb_out,GFP_ATOMIC ); +if (err !=0 ) +dev_warn (uirt->dev, +"failed to submit out urb: %d\n" , err);Also, this looks entirely broken since you don't have any synchronisation with
uirt_command()below which may try to submit the same URB in parallel.
uirt_command()only gets called via lirc chardev ioctl/write ops; the lirc chardev code does locking for the drivers already. So, if someone does a write to/dev/lirc0(which means transmit) the mutex is taken, no other writes/ioctls are allowed on/dev/lirc0; theuirt_tx()callsuirt_command()which waits for completion. During this period the code above can be executed, but not after the transmit succeeds or fails (when the lircdev chardev mutex is released, see:
Quoted 4 lines
Having said all that this is not evident from code at all. A comment could really help.
My point is that uirt_command() may race with the bulk-in completion handler and uirt_response() which can end up submitting the out urb in parallel with uirt_command() and corrupting the tx state. There only needs to be one ioctl()/write() for this to happen.
Johan
Sean Young
maintainerRe: [PATCH v5 1/2] media: rc: new driver for USB-UIRT device
In reply to Johan HovoldQuoted 182 lines · Johan Hovold
Quoted 181 lines · Sean Young
This device uses an ftdi usb serial port, so this driver has a tiny amount of usb ftdi code. It would be preferable to connect this driver via serdev or line-discipline, but unfortunately neither support hotplugging yet.
Signed-off-by Sean Young <[email protected]>--- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/uirt.c | 744 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 756 insertions(+) create mode 100644 drivers/media/rc/uirt.cdrivers/media/rc/Kconfig +11
-0@@ -471,6 +471,17 @@ config IR_TOY To compile this driver as a module, choose M here: the module will be called ir_toy. +config IR_UIRT + tristate "USB-UIRT" + depends on RC_CORE + depends on USB_ARCH_HAS_HCD + help + Say Y here if you want to use the USB-UIRT. See + http://www.usbuirt.com/ + + To compile this driver as a module, choose M here: the module will be + called uirt. + endif #RC_DEVICES endif #RC_COREdrivers/media/rc/Makefile +1
-0@@ -50,3 +50,4 @@ obj-$(CONFIG_IR_SIR) += sir_ir.o obj-$(CONFIG_IR_MTK) += mtk-cir.o obj-$(CONFIG_RC_XBOX_DVD) += xbox_remote.o obj-$(CONFIG_IR_TOY) += ir_toy.o +obj-$(CONFIG_IR_UIRT) += uirt.odrivers/media/rc/uirt.c new file +129
-0@@ -0,0 +1,744 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +/* +* USB-UIRT +* +* Copyright (C) 2021 Sean Young <[email protected]> +* +* See http://www.usbuirt.com/USB-UIRT%20Command%20Protocol.doc +*/ + +#include <linux/completion.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/usb.h> +#include <linux/slab.h> +#include <linux/usb/input.h> + +#include <media/rc-core.h> + +/* Copied from drivers/usb/serial/ftdi_sio.h */ +#define FTDI_SIO_SET_BAUDRATE_REQUEST_TYPE 0x40 +#define FTDI_SIO_SET_BAUDRATE_REQUEST 3 + +#define FTDI_SIO_SET_LATENCY_TIMER_REQUEST FTDI_SIO_SET_LATENCY_TIMER +#define FTDI_SIO_SET_LATENCY_TIMER_REQUEST_TYPE 0x40 + +#define FTDI_SIO_SET_FLOW_CTRL_REQUEST_TYPE 0x40 +#define FTDI_SIO_SET_FLOW_CTRL_REQUEST FTDI_SIO_SET_FLOW_CTRL + +#define FTDI_SIO_SET_FLOW_CTRL 2/* Set flow control register */ +#define FTDI_SIO_SET_LATENCY_TIMER 9/* Set the latency timer */ + +#define FTDI_SIO_RTS_CTS_HS BIT(8) +#define FTDI_RS0_CTS BIT(4) + +static const u8 CMD_GETVERSION [] = {0x23 ,0xdd }; +static const u8 CMD_SETMODERAW [] = {0x21 ,0xdf }; +static const u8 CMD_SETWIDEBAND [] = {0x24 ,0xdc }; + +#define UNIT_US 50 +#define IR_TIMEOUT 12500 +#define MAX_PACKET 64 + +enum cmd_state { +CMD_STATE_GETVERSION , +CMD_STATE_SETMODERAW , +CMD_STATE_SETMODEWIDEBAND , +CMD_STATE_IRDATA , +CMD_STATE_DOTXRAW , +CMD_STATE_STREAMING_TX , +}; + +enum rx_state { +RX_STATE_INTERSPACE_HIGH , +RX_STATE_INTERSPACE_LOW , +RX_STATE_ON_HIGH , +RX_STATE_ON_LOW , +RX_STATE_FREQ_HIGH , +RX_STATE_FREQ_LOW , +RX_STATE_OFF_HIGH , +RX_STATE_OFF_LOW , +}; + +struct uirt { +struct device *dev; +struct usb_device *usbdev; + +struct rc_dev *rc; +struct urb *urb_in, *urb_out; + +u8 *in; +u8 *out; +struct completion cmd_done; +u8 freq; +u8 high; +bool wideband; +u32 last_duration; + +enum cmd_state cmd_state; +enum rx_state rx_state; + +void *tx_buf; +u32 tx_len; + +char phys[64 ]; +}; + +// read IR in raw mode +static void uirt_raw_mode (struct uirt *uirt,u32 offset,u32 len) +{ +uint i, duration; + +for (i = offset; i < len; i++) { +switch (uirt->rx_state) { +case RX_STATE_INTERSPACE_HIGH : + uirt->rx_state =RX_STATE_INTERSPACE_LOW ; +break ; +case RX_STATE_INTERSPACE_LOW : + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +case RX_STATE_ON_HIGH : + duration = uirt->in[i]; +if (duration ==0 ) + duration =1 ; + +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration *UNIT_US , + .pulse = true, + })); + + uirt->rx_state =RX_STATE_OFF_HIGH ; +break ; +case RX_STATE_OFF_HIGH : +if (uirt->in[i] ==0xff ) { +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration =IR_TIMEOUT , + .timeout = true, + })); + uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; +break ; + } + + duration = uirt->in[i]; +if (duration ==0 ) + duration =1 ; + + ir_raw_event_store(uirt->rc, &((struct ir_raw_event) { + .duration = duration * UNIT_US, + .pulse = false,
Quoted 8 lines
drivers/media/rc/uirt.c line 134
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+ })); + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +default : +WARN (1 ,"unreachable state" );This should probably be
dev_warn_ratelimited()or similar. Judging from a quick look a malicious device can end up triggering this.
Well, the other states can reached only by enabling the wideband receiver and then disabling it again, and then the driver state machine needs to be broken too. Just belt and braces.
Quoted 99 lines
Quoted 99 lines
drivers/media/rc/uirt.c new file +99
-0+ uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; +break ; + } + } + +ir_raw_event_handle (uirt->rc); +} + +// Read IR in wideband mode. The byte stream is delivered in packets, +// and the values which come in two bytes may straddle two packets +static void uirt_wideband (struct uirt *uirt,u32 offset,u32 len) +{ +uint i, duration, carrier, pulses; + +for (i = offset; i < len; i++) { +switch (uirt->rx_state) { +case RX_STATE_INTERSPACE_HIGH : + uirt->rx_state =RX_STATE_INTERSPACE_LOW ; +break ; +case RX_STATE_INTERSPACE_LOW : + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +case RX_STATE_ON_HIGH : + uirt->high = uirt->in[i]; + uirt->rx_state =RX_STATE_ON_LOW ; +break ; +case RX_STATE_ON_LOW : +// duration is in 400ns units + duration = (uirt->high <<8 ) | uirt->in[i]; + uirt->last_duration = duration; +// Convert to microseconds + duration =DIV_ROUND_CLOSEST (duration *2 ,5 ); +if (duration ==0 ) + duration =1 ; +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration, + .pulse = true, + })); + uirt->rx_state =RX_STATE_FREQ_HIGH ; +break ; +case RX_STATE_FREQ_HIGH : +if (uirt->in[i] &0x80 ) { + uirt->high = uirt->in[i] &0x7f ; + uirt->rx_state =RX_STATE_FREQ_LOW ; +break ; + } + + uirt->high =0 ; + fallthrough; +case RX_STATE_FREQ_LOW : + pulses = (uirt->high <<8 ) | uirt->in[i]; +if (pulses && uirt->last_duration) { +dev_dbg (uirt->dev,"carrier duration %u pulses %u" , + uirt->last_duration, pulses); + +// calculate the Hz of pulses in duration 400ns units + carrier =DIV_ROUND_CLOSEST_ULL (pulses *10000000ull , + uirt->last_duration *4 ); +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .carrier = carrier, + .carrier_report = true, + })); + } + uirt->rx_state =RX_STATE_OFF_HIGH ; +break ; +case RX_STATE_OFF_HIGH : +if (uirt->in[i] ==0xff ) { +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration =IR_TIMEOUT , + .timeout = true, + })); + uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; + }else { + uirt->high = uirt->in[i]; + uirt->rx_state =RX_STATE_OFF_LOW ; + } +break ; +case RX_STATE_OFF_LOW : +// Convert 400ns units to microseconds + duration =DIV_ROUND_CLOSEST (((uirt->high <<8 ) | uirt->in[i]) *2 ,5 ); +if (duration ==0 ) + duration =1 ; +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration, + .pulse = false, + })); + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; + } + } + +ir_raw_event_handle (uirt->rc); +} + +static void uirt_response (struct uirt *uirt,u32 len) +{ +int offset =2 ; +int i; +
Quoted 8 lines
drivers/media/rc/uirt.c line 238
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+dev_dbg (uirt->dev,"state:%d data: %*phN\n" , uirt->cmd_state, len, uirt->in); + +// Do we have more IR to transmit and is Clear-To-Send set +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX && len >=2 && + uirt->tx_len && uirt->in[0 ] &FTDI_RS0_CTS ) {Do you really need to handle this manually when you have hardware assisted flow control enabled?
I had not considered this. I'll look into it.
Quoted 30 lines
Quoted 30 lines
drivers/media/rc/uirt.c new file +30
-0+u32 len; +int err; + + len =min_t (u32, uirt->tx_len,MAX_PACKET ); + +memcpy (uirt->out, uirt->tx_buf, len); + uirt->urb_out->transfer_buffer_length = len; + + uirt->tx_len -= len; + uirt->tx_buf += len; + + err =usb_submit_urb (uirt->urb_out,GFP_ATOMIC ); +if (err !=0 ) +dev_warn (uirt->dev, +"failed to submit out urb: %d\n" , err); + } + +// if we only have two bytes, it just gives us the serial line status +if (len <=2 ) +return ; + +// We have to assume that the response to a command is at the beginning +// of the packet. There is no way to distinguish IR data from command +// responses other than the position in the byte stream. +switch (uirt->cmd_state) { +case CMD_STATE_GETVERSION : +if (len >=10 ) { +// check checksum +u8 checksum =0 ; +
Quoted 8 lines
drivers/media/rc/uirt.c line 274
Quoted 6 lines
drivers/media/rc/uirt.c new file +6
-0+for (i =2 ; i < len; i++) + checksum += uirt->in[i]; + +if (checksum !=0 ) { +dev_err (uirt->dev,"checksum does not match: %*phN\n" , + len, uirt->in);Should this not be ratelimited too in case you get out of sync?
The get version command is only issued during probe, so this can only occur once.
Quoted 7 lines
drivers/media/rc/uirt.c line 279
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+return ; + } + + dev_info(uirt->dev, + "USB-UIRT firmware v%u.%u protocol v%u.%u %04u-%02u-%02u",Missing '\n' and in a lot of other printks throughout.
Yes, good point. I'll fix this.
Quoted 18 lines
Quoted 18 lines
drivers/media/rc/uirt.c new file +18
-0+ uirt->in[2 ], uirt->in[3 ], uirt->in[4 ], uirt->in[5 ], + uirt->in[8] + 2000, uirt->in[7], uirt->in[6]); + +complete (&uirt->cmd_done); + uirt->cmd_state =CMD_STATE_IRDATA ; + offset +=10 ; + } +break ; +case CMD_STATE_DOTXRAW : +case CMD_STATE_STREAMING_TX : +case CMD_STATE_SETMODERAW : +case CMD_STATE_SETMODEWIDEBAND : +if (len >=3 ) { +switch (uirt->in[2 ]) { +case 0x20 : +// 0x20 transmitting is expected during streaming tx +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX ) +return ;
Quoted 8 lines
drivers/media/rc/uirt.c line 302
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+ +if (uirt->cmd_state ==CMD_STATE_DOTXRAW ) +complete (&uirt->cmd_done); +else +dev_err (uirt->dev,"device transmitting" );I think most of these printks need to be ratelimited or
dev_dbg()since bad input input can trigger them.
All of these occur only as a response to an user space command, like transmit or switching wideband/narrowband receiver. These command are not issued very often, usually only in response to someone running ir-ctl(1) or so.
Quoted 1 line
Another missing newline, but please fix throughout.
Absolutely.
Quoted 106 lines
Quoted 106 lines
drivers/media/rc/uirt.c new file +104
-0+break ; +case 0x21 : +if (uirt->tx_len) { +dev_err (uirt->dev,"tx completed with %u left to send" , + uirt->tx_len); + }else { +if (uirt->cmd_state ==CMD_STATE_SETMODERAW ) + uirt->wideband = false; +if (uirt->cmd_state ==CMD_STATE_SETMODEWIDEBAND ) + uirt->wideband = true; + +complete (&uirt->cmd_done); + } +break ; +case 0x80 : +dev_err (uirt->dev,"checksum error" ); +break ; +case 0x81 : +dev_err (uirt->dev,"timeout" ); +break ; +case 0x82 : +dev_err (uirt->dev,"command error" ); +break ; +default : +dev_err (uirt->dev,"unknown response" ); + } + + uirt->cmd_state =CMD_STATE_IRDATA ; + offset +=1 ; + } +default : +break ; + } + +if (uirt->wideband) +uirt_wideband (uirt, offset, len); +else +uirt_raw_mode (uirt, offset, len); +} +static int uirt_command (struct uirt *uirt,const u8 *cmd,u32 cmd_len, +enum cmd_state state) +{ +int err; + +init_completion (&uirt->cmd_done); + + uirt->cmd_state = state; + +memcpy (uirt->out, cmd, cmd_len); + uirt->urb_out->transfer_buffer_length = cmd_len; + + err =usb_submit_urb (uirt->urb_out,GFP_KERNEL ); +if (err !=0 ) { + uirt->cmd_state =CMD_STATE_IRDATA ; +return err; + } + +if (!wait_for_completion_timeout (&uirt->cmd_done, +msecs_to_jiffies (USB_CTRL_SET_TIMEOUT ))) { +usb_kill_urb (uirt->urb_out); + uirt->cmd_state =CMD_STATE_IRDATA ; +return -ETIMEDOUT ; + } + +return 0 ; +} +static int uirt_tx (struct rc_dev *rc,uint *txbuf,uint count) +{ +struct uirt *uirt = rc->priv; +u8 *out; +u32 i, dest, unit_raw, freq, len; +int err; + +// streaming tx does not work for short IR; use non-streaming +// tx for short IR +if (count <=24 ) +return uirt_short_tx (rc, txbuf, count); + + out =kmalloc (count *2 +3 ,GFP_KERNEL ); +if (!out) +return -ENOMEM ; + + out[0 ] =0x25 ;// Streaming Transmit + out[1 ] =0xdb ;// checksum over command (just the previous byte) + out[2 ] = uirt->freq;// carrier frequency + + dest =3 ; + + freq = uirt->freq &0x7f ; + +for (i =0 ; i < count; i++) { +// width = (us / freq) * 2.5 + unit_raw =DIV_ROUND_CLOSEST (txbuf[i] *5 , freq *2 ); + +if (unit_raw ==0 ) + unit_raw =1 ; +else if (unit_raw >127 ) + out[dest++] = (unit_raw >>8 ) |0x80 ; + + out[dest++] = unit_raw; + } + + len =min_t (u32, dest,MAX_PACKET ); +
Quoted 8 lines
drivers/media/rc/uirt.c line 516
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+ uirt->tx_buf = out + len; + uirt->tx_len = dest - len; + + err =uirt_command (uirt, out, len,CMD_STATE_STREAMING_TX ); +kfree (out);This look fragile; are you sure nothing can access
uirt_tx->buf(out) after the command returns here?
So the in urb handler may access it, but the state should be reset to CMD_STATE_IRDATA. Having said that, the state is not spinlock protected, so this is racy. Thanks for pointing that out.
Quoted 45 lines
Quoted 45 lines
drivers/media/rc/uirt.c new file +45
-0+if (err !=0 ) +return err; + +return count; +} + +static int uirt_set_tx_carrier (struct rc_dev *dev,u32 carrier) +{ +struct uirt *uirt = dev->priv; + +if (carrier ==0 ) +// bit 7 must be 1 for unmodulated, lower bits need to +// be something that makes sense for tx + uirt->freq =0xc0 ; +else if (carrier >=20000 && carrier <=500000 ) +// bit 7 must be 0 for modulated + uirt->freq =2500000 / carrier; +else +return -EINVAL ; + +return 0 ; +} + +static int uirt_set_rx_wideband (struct rc_dev *dev,int enable) +{ +struct uirt *uirt = dev->priv; +int err; + +if (enable) + err =uirt_command (uirt,CMD_SETWIDEBAND , +sizeof (CMD_SETWIDEBAND ), +CMD_STATE_SETMODEWIDEBAND ); +else + err =uirt_command (uirt,CMD_SETMODERAW , +sizeof (CMD_SETMODERAW ), +CMD_STATE_SETMODERAW ); + +if (err) { +dev_err (uirt->dev,"set mode command failed: %d\n" , + err); +return err; + } + +return 0 ; +}
Quoted 8 lines
drivers/media/rc/uirt.c line 567
Quoted 6 lines
drivers/media/rc/uirt.c new file +6
-0+ +static int init_ftdi (struct usb_device *udev) +{ +int err; + +// set the baud rate Please mention the rate here too.
Ok.
Quoted 24 lines
Quoted 24 lines
drivers/media/rc/uirt.c new file +24
-0+ err =usb_control_msg (udev,usb_sndctrlpipe (udev,0 ), +FTDI_SIO_SET_BAUDRATE_REQUEST , +FTDI_SIO_SET_BAUDRATE_REQUEST_TYPE , +0x4009 ,0x0001 , +NULL ,0 ,USB_CTRL_SET_TIMEOUT ); +if (err) +return err; + +// enabling rts/cts flow control + err =usb_control_msg (udev,usb_sndctrlpipe (udev,0 ), +FTDI_SIO_SET_FLOW_CTRL_REQUEST , +FTDI_SIO_SET_FLOW_CTRL_REQUEST_TYPE , +0 ,FTDI_SIO_RTS_CTS_HS , +NULL ,0 ,USB_CTRL_SET_TIMEOUT ); +if (err) +return err; + +// Set latency in milliseconds. The USB-UIRT will generate a +// urb every latency milliseconds (IR or not), so this should be +// set as high as possible to reduce interrupts. However, setting +// this value too high will mean there is a preceptible delay for +// IR being processed and a key press being registered. +// +// Choose 50ms as a compromise.
Quoted 8 lines
drivers/media/rc/uirt.c line 597
Quoted 6 lines
drivers/media/rc/uirt.c new file +6
-0+return usb_control_msg (udev,usb_sndctrlpipe (udev,0 ), +FTDI_SIO_SET_LATENCY_TIMER_REQUEST , +FTDI_SIO_SET_LATENCY_TIMER_REQUEST_TYPE , +50 ,0 , +NULL ,0 ,USB_CTRL_SET_TIMEOUT ); +}Johan
Thanks for the great review, I'll send out a new version when I'm done.
Sean
Johan Hovold
maintainerRe: [PATCH v5 1/2] media: rc: new driver for USB-UIRT device
Quoted 62 lines · Sean Young
Quoted 52 lines · Johan Hovold
Quoted 51 lines · Sean Young
This device uses an ftdi usb serial port, so this driver has a tiny amount of usb ftdi code. It would be preferable to connect this driver via serdev or line-discipline, but unfortunately neither support hotplugging yet.
Signed-off-by Sean Young <[email protected]>drivers/media/rc/uirt.c new file +42
-0+// read IR in raw mode +static void uirt_raw_mode (struct uirt *uirt,u32 offset,u32 len) +{ +uint i, duration; + +for (i = offset; i < len; i++) { +switch (uirt->rx_state) { +case RX_STATE_INTERSPACE_HIGH : + uirt->rx_state =RX_STATE_INTERSPACE_LOW ; +break ; +case RX_STATE_INTERSPACE_LOW : + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +case RX_STATE_ON_HIGH : + duration = uirt->in[i]; +if (duration ==0 ) + duration =1 ; + +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration *UNIT_US , + .pulse = true, + })); + + uirt->rx_state =RX_STATE_OFF_HIGH ; +break ; +case RX_STATE_OFF_HIGH : +if (uirt->in[i] ==0xff ) { +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration =IR_TIMEOUT , + .timeout = true, + })); + uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; +break ; + } + + duration = uirt->in[i]; +if (duration ==0 ) + duration =1 ; + + ir_raw_event_store(uirt->rc, &((struct ir_raw_event) { + .duration = duration * UNIT_US, + .pulse = false,Quoted 8 lines
drivers/media/rc/uirt.c line 134
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+ })); + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +default : +WARN (1 ,"unreachable state" );This should probably be
dev_warn_ratelimited()or similar. Judging from a quick look a malicious device can end up triggering this.
Quoted 3 lines
Well, the other states can reached only by enabling the wideband receiver and then disabling it again, and then the driver state machine needs to be broken too. Just belt and braces.
Still looks like you can end up here since uirt->wideband isn't updated until you get a reply from the device and the it's device input which drives the uirt->rx_state transitions.
Quoted 149 lines
Quoted 99 lines
Quoted 99 lines
drivers/media/rc/uirt.c new file +99
-0+ uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; +break ; + } + } + +ir_raw_event_handle (uirt->rc); +} + +// Read IR in wideband mode. The byte stream is delivered in packets, +// and the values which come in two bytes may straddle two packets +static void uirt_wideband (struct uirt *uirt,u32 offset,u32 len) +{ +uint i, duration, carrier, pulses; + +for (i = offset; i < len; i++) { +switch (uirt->rx_state) { +case RX_STATE_INTERSPACE_HIGH : + uirt->rx_state =RX_STATE_INTERSPACE_LOW ; +break ; +case RX_STATE_INTERSPACE_LOW : + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +case RX_STATE_ON_HIGH : + uirt->high = uirt->in[i]; + uirt->rx_state =RX_STATE_ON_LOW ; +break ; +case RX_STATE_ON_LOW : +// duration is in 400ns units + duration = (uirt->high <<8 ) | uirt->in[i]; + uirt->last_duration = duration; +// Convert to microseconds + duration =DIV_ROUND_CLOSEST (duration *2 ,5 ); +if (duration ==0 ) + duration =1 ; +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration, + .pulse = true, + })); + uirt->rx_state =RX_STATE_FREQ_HIGH ; +break ; +case RX_STATE_FREQ_HIGH : +if (uirt->in[i] &0x80 ) { + uirt->high = uirt->in[i] &0x7f ; + uirt->rx_state =RX_STATE_FREQ_LOW ; +break ; + } + + uirt->high =0 ; + fallthrough; +case RX_STATE_FREQ_LOW : + pulses = (uirt->high <<8 ) | uirt->in[i]; +if (pulses && uirt->last_duration) { +dev_dbg (uirt->dev,"carrier duration %u pulses %u" , + uirt->last_duration, pulses); + +// calculate the Hz of pulses in duration 400ns units + carrier =DIV_ROUND_CLOSEST_ULL (pulses *10000000ull , + uirt->last_duration *4 ); +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .carrier = carrier, + .carrier_report = true, + })); + } + uirt->rx_state =RX_STATE_OFF_HIGH ; +break ; +case RX_STATE_OFF_HIGH : +if (uirt->in[i] ==0xff ) { +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration =IR_TIMEOUT , + .timeout = true, + })); + uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; + }else { + uirt->high = uirt->in[i]; + uirt->rx_state =RX_STATE_OFF_LOW ; + } +break ; +case RX_STATE_OFF_LOW : +// Convert 400ns units to microseconds + duration =DIV_ROUND_CLOSEST (((uirt->high <<8 ) | uirt->in[i]) *2 ,5 ); +if (duration ==0 ) + duration =1 ; +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration, + .pulse = false, + })); + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; + } + } + +ir_raw_event_handle (uirt->rc); +} + +static void uirt_response (struct uirt *uirt,u32 len) +{ +int offset =2 ; +int i; +Quoted 8 lines
drivers/media/rc/uirt.c line 238
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+dev_dbg (uirt->dev,"state:%d data: %*phN\n" , uirt->cmd_state, len, uirt->in); + +// Do we have more IR to transmit and is Clear-To-Send set +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX && len >=2 && + uirt->tx_len && uirt->in[0 ] &FTDI_RS0_CTS ) {Do you really need to handle this manually when you have hardware assisted flow control enabled?
I had not considered this. I'll look into it.
Quoted 30 lines
Quoted 30 lines
drivers/media/rc/uirt.c new file +30
-0+u32 len; +int err; + + len =min_t (u32, uirt->tx_len,MAX_PACKET ); + +memcpy (uirt->out, uirt->tx_buf, len); + uirt->urb_out->transfer_buffer_length = len; + + uirt->tx_len -= len; + uirt->tx_buf += len; + + err =usb_submit_urb (uirt->urb_out,GFP_ATOMIC ); +if (err !=0 ) +dev_warn (uirt->dev, +"failed to submit out urb: %d\n" , err); + } + +// if we only have two bytes, it just gives us the serial line status +if (len <=2 ) +return ; + +// We have to assume that the response to a command is at the beginning +// of the packet. There is no way to distinguish IR data from command +// responses other than the position in the byte stream. +switch (uirt->cmd_state) { +case CMD_STATE_GETVERSION : +if (len >=10 ) { +// check checksum +u8 checksum =0 ; +Quoted 8 lines
drivers/media/rc/uirt.c line 274
Quoted 6 lines
drivers/media/rc/uirt.c new file +6
-0+for (i =2 ; i < len; i++) + checksum += uirt->in[i]; + +if (checksum !=0 ) { +dev_err (uirt->dev,"checksum does not match: %*phN\n" , + len, uirt->in);Should this not be ratelimited too in case you get out of sync?
Quoted 2 lines
The get version command is only issued during probe, so this can only occur once.
Sure, but you don't update the state in case this check fails so the following packets of IR data could all end up here until the command times out.
Quoted 37 lines
Quoted 7 lines
drivers/media/rc/uirt.c line 279
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+return ; + } + + dev_info(uirt->dev, + "USB-UIRT firmware v%u.%u protocol v%u.%u %04u-%02u-%02u",Missing '\n' and in a lot of other printks throughout.
Yes, good point. I'll fix this.
Quoted 18 lines
Quoted 18 lines
drivers/media/rc/uirt.c new file +18
-0+ uirt->in[2 ], uirt->in[3 ], uirt->in[4 ], uirt->in[5 ], + uirt->in[8] + 2000, uirt->in[7], uirt->in[6]); + +complete (&uirt->cmd_done); + uirt->cmd_state =CMD_STATE_IRDATA ; + offset +=10 ; + } +break ; +case CMD_STATE_DOTXRAW : +case CMD_STATE_STREAMING_TX : +case CMD_STATE_SETMODERAW : +case CMD_STATE_SETMODEWIDEBAND : +if (len >=3 ) { +switch (uirt->in[2 ]) { +case 0x20 : +// 0x20 transmitting is expected during streaming tx +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX ) +return ;Quoted 8 lines
drivers/media/rc/uirt.c line 302
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+ +if (uirt->cmd_state ==CMD_STATE_DOTXRAW ) +complete (&uirt->cmd_done); +else +dev_err (uirt->dev,"device transmitting" );I think most of these printks need to be ratelimited or
dev_dbg()since bad input input can trigger them.
Quoted 3 lines
All of these occur only as a response to an user space command, like transmit or switching wideband/narrowband receiver. These command are not issued very often, usually only in response to someone running ir-ctl(1) or so.
But a broken/malicious device, or if things just get out of sync, could end up triggering these messages repeatedly until the commands time out after five seconds, right?
Quoted 35 lines
Quoted 1 line
Another missing newline, but please fix throughout.
Absolutely.
Quoted 31 lines
Quoted 31 lines
drivers/media/rc/uirt.c new file +31
-0+break ; +case 0x21 : +if (uirt->tx_len) { +dev_err (uirt->dev,"tx completed with %u left to send" , + uirt->tx_len); + }else { +if (uirt->cmd_state ==CMD_STATE_SETMODERAW ) + uirt->wideband = false; +if (uirt->cmd_state ==CMD_STATE_SETMODEWIDEBAND ) + uirt->wideband = true; + +complete (&uirt->cmd_done); + } +break ; +case 0x80 : +dev_err (uirt->dev,"checksum error" ); +break ; +case 0x81 : +dev_err (uirt->dev,"timeout" ); +break ; +case 0x82 : +dev_err (uirt->dev,"command error" ); +break ; +default : +dev_err (uirt->dev,"unknown response" ); + } + + uirt->cmd_state =CMD_STATE_IRDATA ; + offset +=1 ; + } +default :
Quoted 8 lines
Quoted 8 lines
drivers/media/rc/uirt.c line 341
Quoted 8 lines
drivers/media/rc/uirt.c new file +8
-0+break ; + } + +if (uirt->wideband) +uirt_wideband (uirt, offset, len); +else +uirt_raw_mode (uirt, offset, len); +}
Johan
Sean Young
maintainerRe: [PATCH v5 1/2] media: rc: new driver for USB-UIRT device
Quoted 63 lines · Johan Hovold
Quoted 62 lines · Sean Young
Quoted 60 lines · Johan Hovold
Quoted 46 lines · Sean Young
This device uses an ftdi usb serial port, so this driver has a tiny amount of usb ftdi code. It would be preferable to connect this driver via serdev or line-discipline, but unfortunately neither support hotplugging yet.
Signed-off-by Sean Young <[email protected]>drivers/media/rc/uirt.c new file +37
-0+// read IR in raw mode +static void uirt_raw_mode (struct uirt *uirt,u32 offset,u32 len) +{ +uint i, duration; + +for (i = offset; i < len; i++) { +switch (uirt->rx_state) { +case RX_STATE_INTERSPACE_HIGH : + uirt->rx_state =RX_STATE_INTERSPACE_LOW ; +break ; +case RX_STATE_INTERSPACE_LOW : + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +case RX_STATE_ON_HIGH : + duration = uirt->in[i]; +if (duration ==0 ) + duration =1 ; + +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration *UNIT_US , + .pulse = true, + })); + + uirt->rx_state =RX_STATE_OFF_HIGH ; +break ; +case RX_STATE_OFF_HIGH : +if (uirt->in[i] ==0xff ) { +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration =IR_TIMEOUT , + .timeout = true, + })); + uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; +break ; + } + + duration = uirt->in[i]; +if (duration ==0 )drivers/media/rc/uirt.c line 134
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+ duration =1 ; + +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration *UNIT_US , + .pulse = false, + })); + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +default : +WARN (1 ,"unreachable state" );This should probably be
dev_warn_ratelimited()or similar. Judging from a quick look a malicious device can end up triggering this.
Quoted 7 lines
Quoted 3 lines
Well, the other states can reached only by enabling the wideband receiver and then disabling it again, and then the driver state machine needs to be broken too. Just belt and braces.
Still looks like you can end up here since
uirt->widebandisn't updated until you get a reply from the device and the it's device input which drives theuirt->rx_statetransitions.
Right, there is a bug: when switching between wideband/narrowband, the rx_state should be set, once the device confirms that the switch has occurred.
Where uirt->wideband is updated, the following line should be added:
uirt->rx_state = RX_STATE_INTERSPACE_HIGH;
With that line added, the default case should be unreachable.
Quoted 149 lines
Quoted 149 lines
Quoted 99 lines
Quoted 99 lines
drivers/media/rc/uirt.c new file +99
-0+ uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; +break ; + } + } + +ir_raw_event_handle (uirt->rc); +} + +// Read IR in wideband mode. The byte stream is delivered in packets, +// and the values which come in two bytes may straddle two packets +static void uirt_wideband (struct uirt *uirt,u32 offset,u32 len) +{ +uint i, duration, carrier, pulses; + +for (i = offset; i < len; i++) { +switch (uirt->rx_state) { +case RX_STATE_INTERSPACE_HIGH : + uirt->rx_state =RX_STATE_INTERSPACE_LOW ; +break ; +case RX_STATE_INTERSPACE_LOW : + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; +case RX_STATE_ON_HIGH : + uirt->high = uirt->in[i]; + uirt->rx_state =RX_STATE_ON_LOW ; +break ; +case RX_STATE_ON_LOW : +// duration is in 400ns units + duration = (uirt->high <<8 ) | uirt->in[i]; + uirt->last_duration = duration; +// Convert to microseconds + duration =DIV_ROUND_CLOSEST (duration *2 ,5 ); +if (duration ==0 ) + duration =1 ; +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration, + .pulse = true, + })); + uirt->rx_state =RX_STATE_FREQ_HIGH ; +break ; +case RX_STATE_FREQ_HIGH : +if (uirt->in[i] &0x80 ) { + uirt->high = uirt->in[i] &0x7f ; + uirt->rx_state =RX_STATE_FREQ_LOW ; +break ; + } + + uirt->high =0 ; + fallthrough; +case RX_STATE_FREQ_LOW : + pulses = (uirt->high <<8 ) | uirt->in[i]; +if (pulses && uirt->last_duration) { +dev_dbg (uirt->dev,"carrier duration %u pulses %u" , + uirt->last_duration, pulses); + +// calculate the Hz of pulses in duration 400ns units + carrier =DIV_ROUND_CLOSEST_ULL (pulses *10000000ull , + uirt->last_duration *4 ); +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .carrier = carrier, + .carrier_report = true, + })); + } + uirt->rx_state =RX_STATE_OFF_HIGH ; +break ; +case RX_STATE_OFF_HIGH : +if (uirt->in[i] ==0xff ) { +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration =IR_TIMEOUT , + .timeout = true, + })); + uirt->rx_state =RX_STATE_INTERSPACE_HIGH ; + }else { + uirt->high = uirt->in[i]; + uirt->rx_state =RX_STATE_OFF_LOW ; + } +break ; +case RX_STATE_OFF_LOW : +// Convert 400ns units to microseconds + duration =DIV_ROUND_CLOSEST (((uirt->high <<8 ) | uirt->in[i]) *2 ,5 ); +if (duration ==0 ) + duration =1 ; +ir_raw_event_store (uirt->rc, &((struct ir_raw_event ) { + .duration = duration, + .pulse = false, + })); + uirt->rx_state =RX_STATE_ON_HIGH ; +break ; + } + } + +ir_raw_event_handle (uirt->rc); +} + +static void uirt_response (struct uirt *uirt,u32 len) +{ +int offset =2 ; +int i; +Quoted 8 lines
drivers/media/rc/uirt.c line 238
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+dev_dbg (uirt->dev,"state:%d data: %*phN\n" , uirt->cmd_state, len, uirt->in); + +// Do we have more IR to transmit and is Clear-To-Send set +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX && len >=2 && + uirt->tx_len && uirt->in[0 ] &FTDI_RS0_CTS ) {Do you really need to handle this manually when you have hardware assisted flow control enabled?
I had not considered this. I'll look into it.
Quoted 38 lines
Quoted 26 lines
drivers/media/rc/uirt.c new file +26
-0+u32 len; +int err; + + len =min_t (u32, uirt->tx_len,MAX_PACKET ); + +memcpy (uirt->out, uirt->tx_buf, len); + uirt->urb_out->transfer_buffer_length = len; + + uirt->tx_len -= len; + uirt->tx_buf += len; + + err =usb_submit_urb (uirt->urb_out,GFP_ATOMIC ); +if (err !=0 ) +dev_warn (uirt->dev, +"failed to submit out urb: %d\n" , err); + } + +// if we only have two bytes, it just gives us the serial line status +if (len <=2 ) +return ; + +// We have to assume that the response to a command is at the beginning +// of the packet. There is no way to distinguish IR data from command +// responses other than the position in the byte stream. +switch (uirt->cmd_state) { +case CMD_STATE_GETVERSION :drivers/media/rc/uirt.c line 274
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+if (len >=10 ) { +// check checksum +u8 checksum =0 ; + +for (i =2 ; i < len; i++) + checksum += uirt->in[i]; + +if (checksum !=0 ) { +dev_err (uirt->dev,"checksum does not match: %*phN\n" , + len, uirt->in);Should this not be ratelimited too in case you get out of sync?
Quoted 6 lines
Quoted 2 lines
The get version command is only issued during probe, so this can only occur once.
Sure, but you don't update the state in case this check fails so the following packets of IR data could all end up here until the command times out.
Right, that is true. There is an opportunity here of 5 seconds of errors; I'll make the right state change so this can only happen once.
Quoted 37 lines
Quoted 37 lines
Quoted 7 lines
drivers/media/rc/uirt.c line 279
Quoted 5 lines
drivers/media/rc/uirt.c new file +5
-0+return ; + } + + dev_info(uirt->dev, + "USB-UIRT firmware v%u.%u protocol v%u.%u %04u-%02u-%02u",Missing '\n' and in a lot of other printks throughout.
Yes, good point. I'll fix this.
Quoted 26 lines
Quoted 13 lines
drivers/media/rc/uirt.c new file +13
-0+ uirt->in[2 ], uirt->in[3 ], uirt->in[4 ], uirt->in[5 ], + uirt->in[8] + 2000, uirt->in[7], uirt->in[6]); + +complete (&uirt->cmd_done); + uirt->cmd_state =CMD_STATE_IRDATA ; + offset +=10 ; + } +break ; +case CMD_STATE_DOTXRAW : +case CMD_STATE_STREAMING_TX : +case CMD_STATE_SETMODERAW : +case CMD_STATE_SETMODEWIDEBAND : +if (len >=3 ) {drivers/media/rc/uirt.c line 302
Quoted 10 lines
drivers/media/rc/uirt.c new file +10
-0+switch (uirt->in[2 ]) { +case 0x20 : +// 0x20 transmitting is expected during streaming tx +if (uirt->cmd_state ==CMD_STATE_STREAMING_TX ) +return ; + +if (uirt->cmd_state ==CMD_STATE_DOTXRAW ) +complete (&uirt->cmd_done); +else +dev_err (uirt->dev,"device transmitting" );I think most of these printks need to be ratelimited or
dev_dbg()since bad input input can trigger them.
Quoted 7 lines
Quoted 3 lines
All of these occur only as a response to an user space command, like transmit or switching wideband/narrowband receiver. These command are not issued very often, usually only in response to someone running ir-ctl(1) or so.
But a broken/malicious device, or if things just get out of sync, could end up triggering these messages repeatedly until the commands time out after five seconds, right?
Yes, you could get up to 5 seconds of errors. I can make them ratelimited to avoid this problem.
Quoted 37 lines
Quoted 37 lines
Quoted 1 line
Another missing newline, but please fix throughout.
Absolutely.
Quoted 33 lines
Quoted 33 lines
drivers/media/rc/uirt.c new file +33
-0+break ; +case 0x21 : +if (uirt->tx_len) { +dev_err (uirt->dev,"tx completed with %u left to send" , + uirt->tx_len); + }else { +if (uirt->cmd_state ==CMD_STATE_SETMODERAW ) + uirt->wideband = false; +if (uirt->cmd_state ==CMD_STATE_SETMODEWIDEBAND ) + uirt->wideband = true; + +complete (&uirt->cmd_done); + } +break ; +case 0x80 : +dev_err (uirt->dev,"checksum error" ); +break ; +case 0x81 : +dev_err (uirt->dev,"timeout" ); +break ; +case 0x82 : +dev_err (uirt->dev,"command error" ); +break ; +default : +dev_err (uirt->dev,"unknown response" ); + } + + uirt->cmd_state =CMD_STATE_IRDATA ; + offset +=1 ; + } +default : +break ; + }
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
drivers/media/rc/uirt.c line 341
Quoted 6 lines
drivers/media/rc/uirt.c new file +6
-0+ +if (uirt->wideband) +uirt_wideband (uirt, offset, len); +else +uirt_raw_mode (uirt, offset, len); +}Johan
Thanks
Sean
Sean Young
maintainerPATCH v5 2/2 USB: serial: blacklist USB-UIRT when driver is selected
In reply to Sean YoungThe USB-UIRT device has its own driver, so blacklist the fdti driver from using it if the driver has been enabled.
--- drivers/usb/serial/ftdi_sio.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/serial/ftdi_sio.c +4 -2
@@ -106,7 +106,7 @@ static const struct ftdi_sio_quirk ftdi_NDI_device_quirk = { .probe = ftdi_NDI_device_setup, }; -static const struct ftdi_sio_quirk ftdi_USB_UIRT_quirk = { +static __maybe_unused const struct ftdi_sio_quirk ftdi_USB_UIRT_quirk = { .port_probe = ftdi_USB_UIRT_setup, };
@@ -568,8 +568,10 @@ static const struct usb_device_id id_table_combined[] = { { USB_DEVICE(OCT_VID, OCT_DK201_PID) }, { USB_DEVICE(FTDI_VID, FTDI_HE_TIRA1_PID), .driver_info = (kernel_ulong_t)&ftdi_HE_TIRA1_quirk }, +#if !IS_ENABLED(CONFIG_IR_UIRT) { USB_DEVICE(FTDI_VID, FTDI_USB_UIRT_PID), .driver_info = (kernel_ulong_t)&ftdi_USB_UIRT_quirk }, +#endif { USB_DEVICE(FTDI_VID, PROTEGO_SPECIAL_1) }, { USB_DEVICE(FTDI_VID, PROTEGO_R2X0) }, { USB_DEVICE(FTDI_VID, PROTEGO_SPECIAL_3) },
@@ -2281,7 +2283,7 @@ static int ftdi_sio_port_probe(struct usb_serial_port *port)/* Setup for the USB-UIRT device, which requires hardwired * baudrate (38400 gets mapped to 312500) */ /* Called from usbserial:serial_probe */ -static void ftdi_USB_UIRT_setup (struct ftdi_private *priv) +static __maybe_unused void ftdi_USB_UIRT_setup (struct ftdi_private *priv) { priv->flags |=ASYNC_SPD_CUST ; priv->custom_divisor =77 ;
Signature · 1 line
2.31.1
Johan Hovold
maintainerQuoted 10 lines · Sean Young
This is a new rc-core driver for the USB-UIRT which you can see here
http://www.usbuirt.com/This device is supported in lirc, via the usb serial kernel driver. This driver is both for rc-core, which means it can use kernel/BPF decoding ec. Also this implement is superior because it can:
- support learning mode
- setting transmit carrier
- larger transmits using streaming tx command
- Much better latency since it is a kernel driver
A ball-park number to back this claim up would be good here. Your driver sets the ftdi latency timer to 50 ms which adds quite a bit of latency for short packets (e.g. a single key press?) to begin with.
Quoted 6 lines
Changes since v4:
- Fixed clang warning/uninitialized variable usage
- Some cosmetic changesChanges since v3:
- Review comments from Johan Hovold
In the future, please include some details on what changed also when addressing review feedback.
Quoted 14 lines
- Do not move the
ftdi_sio.hfile an copy FTDI_* definitions insteadChanges since v2:
- Fixed race condition is disconnect
- Removed superfluous kmalloc in short txChanges since v1:
- Review comments from Oliver Neukum
- Simplified wideband read functionSean Young (2):
media: rc: new driver for USB-UIRT device
USB: serial: blacklist USB-UIRT when driver is selected
Quoted 6 lines
drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/uirt.c | 744 ++++++++++++++++++++++++++++++++++ drivers/usb/serial/ftdi_sio.c | 6 +- 4 files changed, 760 insertions(+), 2 deletions(-) create mode 100644 drivers/media/rc/uirt.c
Johan
Sean Young
maintainerQuoted 12 lines · Johan Hovold
Quoted 10 lines · Sean Young
This is a new rc-core driver for the USB-UIRT which you can see here
http://www.usbuirt.com/This device is supported in lirc, via the usb serial kernel driver. This driver is both for rc-core, which means it can use kernel/BPF decoding ec. Also this implement is superior because it can:
- support learning mode
- setting transmit carrier
- larger transmits using streaming tx command
- Much better latency since it is a kernel driver
Quoted 3 lines
A ball-park number to back this claim up would be good here. Your driver sets the ftdi latency timer to 50 ms which adds quite a bit of latency for short packets (e.g. a single key press?) to begin with.
Yes, I'll do some measurements. This is based on observations with other in kernel drivers.
Quoted 9 lines
Quoted 6 lines
Changes since v4:
- Fixed clang warning/uninitialized variable usage
- Some cosmetic changesChanges since v3:
- Review comments from Johan HovoldIn the future, please include some details on what changed also when addressing review feedback.
Right, good point. Will do.
Quoted 14 lines
Quoted 14 lines
- Do not move the
ftdi_sio.hfile an copy FTDI_* definitions insteadChanges since v2:
- Fixed race condition is disconnect
- Removed superfluous kmalloc in short txChanges since v1:
- Review comments from Oliver Neukum
- Simplified wideband read functionSean Young (2):
media: rc: new driver for USB-UIRT device
USB: serial: blacklist USB-UIRT when driver is selected
Quoted 8 lines
Quoted 6 lines
drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/uirt.c | 744 ++++++++++++++++++++++++++++++++++ drivers/usb/serial/ftdi_sio.c | 6 +- 4 files changed, 760 insertions(+), 2 deletions(-) create mode 100644 drivers/media/rc/uirt.cJohan
Thanks
Sean