On 02/09/2016 09:41 AM, Manoj Kumar wrote:
>> Yeah, I can see how that is confusing. Since, all three possible valid
>> crq message types have the first bit set I think this was originally a
>> cute hack to grab anything that was likely valid. Then in
>> ibmvscsi_handle_crq() we explicitly match th
Yeah, I can see how that is confusing. Since, all three possible valid
crq message types have the first bit set I think this was originally a
cute hack to grab anything that was likely valid. Then in
ibmvscsi_handle_crq() we explicitly match the full header value in a
switch statement logging anyt
On 02/04/2016 11:55 AM, Manoj Kumar wrote:
> On 2/3/2016 5:28 PM, Tyrel Datwyler wrote:
>> The PAPR defines four valid header values for the first byte of a
>> CRQ message. Namely, an unused/empty message (0x00), a valid
>> command/response entry (0x80), a valid initialization entry (0xC0),
>> and
On 2/3/2016 5:28 PM, Tyrel Datwyler wrote:
The PAPR defines four valid header values for the first byte of a
CRQ message. Namely, an unused/empty message (0x00), a valid
command/response entry (0x80), a valid initialization entry (0xC0),
and a transport event (0xFF). Define these values as enums
On Wed, Feb 03, 2016 at 05:28:30PM -0600, Tyrel Datwyler wrote:
> The PAPR defines four valid header values for the first byte of a
> CRQ message. Namely, an unused/empty message (0x00), a valid
> command/response entry (0x80), a valid initialization entry (0xC0),
> and a transport event (0xFF). De
The PAPR defines four valid header values for the first byte of a
CRQ message. Namely, an unused/empty message (0x00), a valid
command/response entry (0x80), a valid initialization entry (0xC0),
and a transport event (0xFF). Define these values as enums and use
them in the code in place of their ma
