can_id built wrongly from received bytes

[as19git67]

I replaced the mcp251x driver with this one and saw that the can_id (extended frame) no more are the same as they were with the stock driver that comes with the linux kernel sources (3.12.35 - raspberry pi).
I could not figure out why the extra shift by 11 bits is necessary.
I also did not check whether the can_id is used correctly when sending messages with extended frames.

A patch would be:
--- mcp2515a/mcp2515a.c 2015-02-26 16:09:16.486369756 +0100
+++ mcp2515a.c 2015-02-26 16:08:10.137055884 +0100
@@ -775,11 +775,11 @@
CAN_RTR_FLAG : 0)
/* the extended Address - top 2 bits */
| ((data[MCP2515_MSG_SIDL]&MCP2515_MSG_SIDL_EMASK)

•                           << (2*8+11))
  

•                           << (2_8))
                  /_ the extended Address EXTH */
  

•                   | (data[MCP2515_MSG_EIDH] << (1*8+11))
  

•                   | (data[MCP2515_MSG_EIDH] << (1_8))
                  /_ the extended Address EXTL */
  

•                   | (data[MCP2515_MSG_EIDL] << (0*8+11))
  

•                   | (data[MCP2515_MSG_EIDL] << (0_8))
                  ;
  } else {
          frame->can_id =
  

  @@ -790,8 +790,8 @@
  }
  /_ and add the standard header */
  frame->can_id |=

•           (data[MCP2515_MSG_SIDH] << 3)
  

•           | (data[MCP2515_MSG_SIDL] >> 5)
  

•           (((data[MCP2515_MSG_SIDH] << 3)
  

•           | (data[MCP2515_MSG_SIDL] >> 5)) << 18)
          ;
  /\* get data length */
  frame->can_dlc = get_can_dlc(
  

[msperl]

I think that the logic is copied from one of the other drivers, so it must have been there...
Will look into that...

[msperl]

1843246 fixes that hopefully...
this may mean that the TX portion does not work properly either (but I have not checked that yet)...