Hello, On Tue, Jun 25, 2019 at 11:01:32AM -0400, A Sun wrote: > On 6/25/2019 6:51 AM, Sean Young wrote: > > On Wed, Jun 19, 2019 at 03:54:21AM -0400, A Sun wrote: > >> > > >> - dev_err(ir->dev, "Error: request urb status = %d (TX HALT)", > >> + dev_err(ir->dev, "Error: tx urb status = %d (TX HALT)", > > > > I am not sure this makes things clearer. Some of the code still refers > > to request, e.g. mce_request_packet. > > > > Since this is an IR device, there is IR TX and RX; however this unrelated > > to that. > > > > There is one urb/endpoint on which commands are sent; on the other, we > > receiver responses and IR data. Calling those TX and RX is not a good > > idea I think. > > The tx urb described is also for IR data TX. > IR TX is one primary function/purpose of the device. > > It happens that the urb/endpoint for IR TX is the same urb/endpoint for > mceusb device commands. The outgoing urb is for command, e.g. get version, set IR Rx timeout, set IR Rx carrier report, set IR wakeup protocol/scancode, resume device after suspend. Not everything is IR Tx. > The same is found for IR data RX. > The urb/endpoint for IR RX is the same urb/endpoint for mceusb device > responses (to commands). The response to get version, how many Tx ports are there etc. Responses to commands and IR data. Not everything is IR Rx here. > > The existing code refers to request and response, and also TX and RX in > > places. The microsoft documentation refers to "command and response" which > > would be consistent with the #define's we have (MCE_CMD_* and MCE_RSP_*). > > > > My intent is to try and better word several of the USB layer messages, > and avoid confusing Microsoft MCE terms in those messages. > > The original "(request) urb" phrases expand to "request USB Request Block" > and "<blank> USB Request Block" which are particularly confusing, and > non-specific, respectively. How about command and response? Sean
