Re: [PATCH v2 2/3] [media] mceusb: Reword messages referring to "urb"

[Sean Young <sean@mess.org>]

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