1. 16 6月, 2017 3 次提交
    • J
      networking: add and use skb_put_u8() · 634fef61
      Johannes Berg 提交于
      Joe and Bjørn suggested that it'd be nicer to not have the
      cast in the fairly common case of doing
      	*(u8 *)skb_put(skb, 1) = c;
      
      Add skb_put_u8() for this case, and use it across the code,
      using the following spatch:
      
          @@
          expression SKB, C, S;
          typedef u8;
          identifier fn = {skb_put};
          fresh identifier fn2 = fn ## "_u8";
          @@
          - *(u8 *)fn(SKB, S) = C;
          + fn2(SKB, C);
      
      Note that due to the "S", the spatch isn't perfect, it should
      have checked that S is 1, but there's also places that use a
      sizeof expression like sizeof(var) or sizeof(u8) etc. Turns
      out that nobody ever did something like
      	*(u8 *)skb_put(skb, 2) = c;
      
      which would be wrong anyway since the second byte wouldn't be
      initialized.
      Suggested-by: NJoe Perches <joe@perches.com>
      Suggested-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      634fef61
    • J
      networking: make skb_push & __skb_push return void pointers · d58ff351
      Johannes Berg 提交于
      It seems like a historic accident that these return unsigned char *,
      and in many places that means casts are required, more often than not.
      
      Make these functions return void * and remove all the casts across
      the tree, adding a (u8 *) cast only where the unsigned char pointer
      was used directly, all done with the following spatch:
      
          @@
          expression SKB, LEN;
          typedef u8;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - *(fn(SKB, LEN))
          + *(u8 *)fn(SKB, LEN)
      
          @@
          expression E, SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          type T;
          @@
          - E = ((T *)(fn(SKB, LEN)))
          + E = fn(SKB, LEN)
      
          @@
          expression SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - fn(SKB, LEN)[0]
          + *(u8 *)fn(SKB, LEN)
      
      Note that the last part there converts from push(...)[0] to the
      more idiomatic *(u8 *)push(...).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d58ff351
    • J
      networking: make skb_put & friends return void pointers · 4df864c1
      Johannes Berg 提交于
      It seems like a historic accident that these return unsigned char *,
      and in many places that means casts are required, more often than not.
      
      Make these functions (skb_put, __skb_put and pskb_put) return void *
      and remove all the casts across the tree, adding a (u8 *) cast only
      where the unsigned char pointer was used directly, all done with the
      following spatch:
      
          @@
          expression SKB, LEN;
          typedef u8;
          identifier fn = { skb_put, __skb_put };
          @@
          - *(fn(SKB, LEN))
          + *(u8 *)fn(SKB, LEN)
      
          @@
          expression E, SKB, LEN;
          identifier fn = { skb_put, __skb_put };
          type T;
          @@
          - E = ((T *)(fn(SKB, LEN)))
          + E = fn(SKB, LEN)
      
      which actually doesn't cover pskb_put since there are only three
      users overall.
      
      A handful of stragglers were converted manually, notably a macro in
      drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
      instances in net/bluetooth/hci_sock.c. In the former file, I also
      had to fix one whitespace problem spatch introduced.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4df864c1
  2. 06 7月, 2016 1 次提交
  3. 23 7月, 2014 1 次提交
    • M
      NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooks · bf30a67c
      Mark A. Greer 提交于
      The digital layer of the NFC subsystem currently
      supports a 'tg_listen_mdaa' driver hook that supports
      devices that can do mode detection and automatic
      anticollision.  However, there are some devices that
      can do mode detection but not automatic anitcollision
      so add the 'tg_listen_md' hook to support those devices.
      
      In order for the digital layer to get the RF technology
      detected by the device from the driver, add the
      'tg_get_rf_tech' hook.  It is only valid to call this
      hook immediately after a successful call to 'tg_listen_md'.
      
      CC: Thierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      bf30a67c
  4. 21 7月, 2014 2 次提交
  5. 26 5月, 2014 1 次提交
  6. 20 5月, 2014 2 次提交
  7. 22 4月, 2014 1 次提交
  8. 17 2月, 2014 3 次提交
  9. 25 9月, 2013 9 次提交
    • T
      NFC: digital: Fix sens_res endiannes handling · 13292c9a
      Thierry Escande 提交于
      This was triggered by the following sparse warning:
      
      net/nfc/digital_technology.c:272:20: sparse: cast to restricted __be16
      
      The SENS_RES response must be treated as __le16 with the first byte
      received as LSB and the second one as MSB. This is the way neard
      handles it in the sens_res field of the nfc_target structure which is
      treated as u16 in cpu endianness. So le16_to_cpu() is used on the
      received SENS_RES instead of memcpy'ing it.
      
      SENS_RES test macros have also been fixed accordingly.
      Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      13292c9a
    • F
      NFC: digital: digital_tg_send_sensf_res() can be static · 180106bd
      Fengguang Wu 提交于
      Fixes sparse hint:
      
      net/nfc/digital_technology.c:640:5: sparse: symbol 'digital_tg_send_sensf_res'
      was not declared. Should it be static?
      
      Cc: Thierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      180106bd
    • S
      NFC: digital: Add newline to pr_* calls · 26042530
      Samuel Ortiz 提交于
      We do not add the newline to the pr_fmt macro, in order to give more
      flexibility to the caller and to keep the logging style consistent with
      the rest of the NFC and kernel code.
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      26042530
    • S
      NFC: digital: Remove PR_ERR and PR_DBG macros · c5da0e4a
      Samuel Ortiz 提交于
      They can be replaced by the standard pr_err and pr_debug one after
      defining the right pr_fmt macro.
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      c5da0e4a
    • T
      NFC Digital: Add target NFC-DEP support · 1c7a4c24
      Thierry Escande 提交于
      This adds support for NFC-DEP target mode for NFC-A and NFC-F
      technologies.
      
      If the driver provides it, the stack uses an automatic mode for
      technology detection and automatic anti-collision. Otherwise the stack
      tries to use non-automatic synchronization and listens for SENS_REQ and
      SENSF_REQ commands.
      
      The detection, activation, and data exchange procedures work exactly
      the same way as in initiator mode, as described in the previous
      commits, except that the digital stack waits for commands and sends
      responses back to the peer device.
      Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      1c7a4c24
    • T
      NFC Digital: Add initiator NFC-DEP support · 7d0911c0
      Thierry Escande 提交于
      This adds support for NFC-DEP protocol in initiator mode for NFC-A and
      NFC-F technologies.
      
      When a target is detected, the process flow is as follow:
      
      For NFC-A technology:
      1 - The digital stack receives a SEL_RES as the reply of the SEL_REQ
          command.
      2   - If b7 of SEL_RES is set, the peer device is configure for NFC-DEP
            protocol. NFC core is notified through nfc_targets_found().
            Execution continues at step 4.
      3   - Otherwise, it's a tag and the NFC core is notified. Detection
            ends.
      4 - The digital stacks sends an ATR_REQ command containing a randomly
          generated NFCID3 and the general bytes obtained from the LLCP layer
          of NFC core.
      
      For NFC-F technology:
      1 - The digital stack receives a SENSF_RES as the reply of the
          SENSF_REQ command.
      2   - If B1 and B2 of NFCID2 are 0x01 and 0xFE respectively, the peer
            device is configured for NFC-DEP protocol. NFC core is notified
            through nfc_targets_found(). Execution continues at step 4.
      3   - Otherwise it's a type 3 tag. NFC core is notified. Detection
            ends.
      4 - The digital stacks sends an ATR_REQ command containing the NFC-F
          NFCID2 as NFCID3 and the general bytes obtained from the LLCP layer
          of NFC core.
      
      For both technologies:
      5 - The digital stacks receives the ATR_RES response containing the
          NFCID3 and the general bytes of the peer device.
      6 - The digital stack notifies NFC core that the DEP link is up through
          nfc_dep_link_up().
      7 - The NFC core performs data exchange through tm_transceive().
      8 - The digital stack sends a DEP_REQ command containing an I PDU with
          the data from NFC core.
      9 - The digital stack receives a DEP_RES command
      10  - If the DEP_RES response contains a supervisor PDU with timeout
            extension request (RTOX) the digital stack sends a DEP_REQ
            command containing a supervisor PDU acknowledging the RTOX
            request. The execution continues at step 9.
      11  - If the DEP_RES response contains an I PDU, the response data is
            passed back to NFC core through the response callback. The
            execution continues at step 8.
      Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      7d0911c0
    • T
      NFC Digital: Add NFC-F technology support · 8c0695e4
      Thierry Escande 提交于
      This adds polling support for NFC-F technology at 212 kbits/s and 424
      kbits/s. A user space application like neard can send type 3 tag
      commands through the NFC core.
      
      Process flow for NFC-F detection is as follow:
      
      1 - The digital stack sends the SENSF_REQ command to the NFC device.
      2 - A peer device replies with a SENSF_RES response.
      3   - The digital stack notifies the NFC core of the presence of a
            target in the operation field and passes the target NFCID2.
      
      This also adds support for CRC calculation of type CRC-F. The CRC
      calculation is handled by the digital stack if the NFC device doesn't
      support it.
      Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      8c0695e4
    • T
      NFC Digital: Add NFC-A technology support · 2c66daec
      Thierry Escande 提交于
      This adds support for NFC-A technology at 106 kbits/s. The stack can
      detect tags of type 1 and 2. There is no support for collision
      detection. Tags can be read and written by using a user space
      application or a daemon like neard.
      
      The flow of polling operations for NFC-A detection is as follow:
      
      1 - The digital stack sends the SENS_REQ command to the NFC device.
      2 - The NFC device receives a SENS_RES response from a peer device and
          passes it to the digital stack.
      3   - If the SENS_RES response identifies a type 1 tag, detection ends.
            NFC core is notified through nfc_targets_found().
      4   - Otherwise, the digital stack sets the cascade level of NFCID1 to
            CL1 and sends the SDD_REQ command.
      5 - The digital stack selects SEL_CMD and SEL_PAR according to the
          cascade level and sends the SDD_REQ command.
      4 - The digital stack receives a SDD_RES response for the cascade level
          passed in the SDD_REQ command.
      5 - The digital stack analyses (part of) NFCID1 and verify BCC.
      6 - The digital stack sends the SEL_REQ command with the NFCID1
          received in the SDD_RES.
      6 - The peer device replies with a SEL_RES response
      7   - Detection ends if NFCID1 is complete. NFC core notified of new
            target by nfc_targets_found().
      8   - If NFCID1 is not complete, the cascade level is incremented (up
            to and including CL3) and the execution continues at step 5 to
            get the remaining bytes of NFCID1.
      
      Once target detection is done, type 1 and 2 tag commands must be
      handled by a user space application (i.e neard) through the NFC core.
      Responses for type 1 tag are returned directly to user space via NFC
      core.
      Responses of type 2 commands are handled differently. The digital stack
      doesn't analyse the type of commands sent through im_transceive() and
      must differentiate valid responses from error ones.
      The response process flow is as follow:
      
      1 - If the response length is 16 bytes, it is a valid response of a
          READ command. the packet is returned to the NFC core through the
          callback passed to im_transceive(). Processing stops.
      2 - If the response is 1 byte long and is a ACK byte (0x0A), it is a
          valid response of a WRITE command for example. First packet byte
          is set to 0 for no-error and passed back to the NFC core.
          Processing stops.
      3 - Any other response is treated as an error and -EIO error code is
          returned to the NFC core through the response callback.
      
      Moreover, since the driver can't differentiate success response from a
      NACK response, the digital stack has to handle CRC calculation.
      
      Thus, this patch also adds support for CRC calculation. If the driver
      doesn't handle it, the digital stack will calculate CRC and will add it
      to sent frames. CRC will also be checked and removed from received
      frames. Pointers to the correct CRC calculation functions are stored in
      the digital stack device structure when a target is detected. This
      avoids the need to check the current target type for every call to
      im_transceive() and for every response received from a peer device.
      Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      2c66daec
    • T
      NFC Digital: Implement driver commands mechanism · 59ee2361
      Thierry Escande 提交于
      This implements the mechanism used to send commands to the driver in
      initiator mode through in_send_cmd().
      
      Commands are serialized and sent to the driver by using a work item
      on the system workqueue. Responses are handled asynchronously by
      another work item. Once the digital stack receives the response through
      the command_complete callback, the next command is sent to the driver.
      
      This also implements the polling mechanism. It's handled by a work item
      cycling on all supported protocols. The start poll command for a given
      protocol is sent to the driver using the mechanism described above.
      The process continues until a peer is discovered or stop_poll is
      called. This patch implements the poll function for NFC-A that sends a
      SENS_REQ command and waits for the SENS_RES response.
      Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      59ee2361