1. 03 May, 2016 9 commits
    • Christophe Ricard's avatar
      nfc: st-nci: A APDU_READER_GATE pipe is unexpected on a UICC · 0209e79d
      Christophe Ricard authored
      An APDU_READER_GATE pipe is not expected on a UICC. Be more
      explicit so that an other secure element form factor (SD card)
      does not prompt this message.
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      0209e79d
    • Christophe Ricard's avatar
      nfc: st-nci: Simplify white list building · cde4856e
      Christophe Ricard authored
      Simplify white list Building
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      cde4856e
    • Christophe Ricard's avatar
      nfc: st21nfca: Simplify white list building · d35cb20b
      Christophe Ricard authored
      Simplify white list Building
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      d35cb20b
    • Christophe Ricard's avatar
      nfc: st-nci: set is_ese_present and is_uicc_present properly · 27420fec
      Christophe Ricard authored
      When they're present, set is_ese_present and set is_uicc_present
      to the value describe in their package description.
      
      So far is_ese_present and is_uicc_present was set to true if their
      property was present.
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      27420fec
    • Christophe Ricard's avatar
      nfc: st21nfca: set is_ese_present and is_uicc_present properly · bd9d5232
      Christophe Ricard authored
      When they're present, set is_ese_present and set is_uicc_present
      to the value describe in their package description.
      
      So far is_ese_present and is_uicc_present was set to true if their
      property was present.
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      bd9d5232
    • Christophe Ricard's avatar
      nfc: st21nfca: i2c: Change ST21NFCA_GPIO_NAME_RESET to match DT · 2a196975
      Christophe Ricard authored
      Since
      commit 10cf4899 ("gpiolib: tighten up ACPI legacy gpio lookups")
      
      If _DSD properties are available in an ACPI node, we are not
      allowed to fallback to _CRS data to retrieve gpio properties.
      This was causing us to fail if uicc-present and/or ese-present
      are defined.
      
      To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
      content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
      will look for reset-gpios. In the mean time the ACPI table needs
      to be fixed as follow:
      
      Device (NFC1)
      {
          Name (_ADR, Zero)  // _ADR: Address
          Name (_HID, "SMO2100")  // _HID: Hardware ID
          Name (_CID, "SMO2100")  // _CID: Compatible ID
          Name (_DDN, "SMO NFC")  // _DDN: DOS Device Name
          Name (_UID, One)  // _UID: Unique ID
          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
          {
              Name (SBUF, ResourceTemplate ()
              {
                   I2cSerialBus (0x0008, ControllerInitiated, 400000,
                                 AddressingMode7Bit, "\\_SB.I2C7",
                                 0x00, ResourceConsumer, ,)
                   GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
                            "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
                   {   // Pin list
                       0x0001
                   }
                   GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                           "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
                   {   // Pin list
                       0x0002,
                   }
              })
              Name (_DSD, Package (0x02)
              {
                   ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
                   Package (0x03)
                   {
                       Package (0x02) { "uicc-present", 1 },
                       Package (0x02) { "ese-present", 1 },
                       Package (0x02) { "enable-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
                   }
              })
              Return (SBUF) /* \_SB_.I2C7.NFC1._CRS.SBUF */
          }
          Method (_STA, 0, NotSerialized)  // _STA: Status
          {
              Return (0x0F)
          }
      }
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      2a196975
    • Christophe Ricard's avatar
      nfc: st-nci: spi: Change ST_NCI_GPIO_NAME_RESET to match DT · de72dbc5
      Christophe Ricard authored
      Since
      commit 10cf4899 ("gpiolib: tighten up ACPI legacy gpio lookups")
      
      If _DSD properties are available in an ACPI node, we are not
      allowed to fallback to _CRS data to retrieve gpio properties.
      This was causing us to fail if uicc-present and/or ese-present
      are defined.
      
      To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
      content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
      will look for reset-gpios. In the mean time the ACPI table needs
      to be fixed as follow (Tested on Minnowboard Max):
      
      Device (NFC1)
      {
          Name (_ADR, Zero)  // _ADR: Address
          Name (_HID, "SMO2101")  // _HID: Hardware ID
          Name (_CID, "SMO2101")  // _CID: Compatible ID
          Name (_DDN, "SMO NFC")  // _DDN: DOS Device Name
          Name (_UID, One)  // _UID: Unique ID
          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
          {
              Name (SBUF, ResourceTemplate ()
              {
                   SpiSerialBus (0, PolarityLow, FourWireMode, 8,
                                 ControllerInitiated, 4000000, ClockPolarityLow,
                                 ClockPhaseFirst, "\\_SB.SPI1",
                                 0x00, ResourceConsumer, ,)
                   GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
                            "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
                   {   // Pin list
                       0x0001
                   }
                   GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                           "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
                   {   // Pin list
                       0x0002,
                   }
              })
              Name (_DSD, Package (0x02)
              {
                   ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
                   Package (0x03)
                   {
                       Package (0x02) { "uicc-present", 1 },
                       Package (0x02) { "ese-present", 1 },
                       Package (0x02) { "reset-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
                   }
              })
              Return (SBUF) /* \_SB_.SPI1.NFC1._CRS.SBUF */
          }
          Method (_STA, 0, NotSerialized)  // _STA: Status
          {
              Return (0x0F)
          }
      }
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      de72dbc5
    • Christophe Ricard's avatar
      nfc: st-nci: i2c: Change ST_NCI_GPIO_NAME_RESET to match DT · c1fc9136
      Christophe Ricard authored
      Since
      commit 10cf4899 ("gpiolib: tighten up ACPI legacy gpio lookups")
      
      If _DSD properties are available in an ACPI node, we are not
      allowed to fallback to _CRS data to retrieve gpio properties.
      This was causing us to fail if uicc-present and/or ese-present
      are defined.
      
      To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
      content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
      will look for reset-gpios. In the mean time the ACPI table needs
      to be fixed as follow:
      
      Device (NFC1)
      {
          Name (_ADR, Zero)  // _ADR: Address
          Name (_HID, "SMO2101")  // _HID: Hardware ID
          Name (_CID, "SMO2101")  // _CID: Compatible ID
          Name (_DDN, "SMO NFC")  // _DDN: DOS Device Name
          Name (_UID, One)  // _UID: Unique ID
          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
          {
              Name (SBUF, ResourceTemplate ()
              {
                   I2cSerialBus (0x0008, ControllerInitiated, 400000,
                                 AddressingMode7Bit, "\\_SB.I2C7",
                                 0x00, ResourceConsumer, ,)
                   GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
                            "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
                   {   // Pin list
                       0x0001
                   }
                   GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                           "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
                   {   // Pin list
                       0x0002,
                   }
              })
              Name (_DSD, Package (0x02)
              {
                   ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
                   Package (0x03)
                   {
                       Package (0x02) { "uicc-present", 1 },
                       Package (0x02) { "ese-present", 1 },
                       Package (0x02) { "reset-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
                   }
              })
              Return (SBUF) /* \_SB_.I2C7.NFC1._CRS.SBUF */
          }
          Method (_STA, 0, NotSerialized)  // _STA: Status
          {
              Return (0x0F)
          }
      }
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      c1fc9136
    • Christophe Ricard's avatar
      nfc: st21nfca: Fix static checker warning · b58afe6d
      Christophe Ricard authored
      Fix static checker warning:
      drivers/nfc/st21nfca/i2c.c:530 st21nfca_hci_i2c_acpi_request_resources()
      error: 'gpiod_ena' dereferencing possible ERR_PTR()
      
      Fix so that if no enable gpio can be retrieved an -ENODEV is returned.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: dfa8070d ("nfc: st21nfca: Add support for acpi probing for i2c device.")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      b58afe6d
  2. 01 May, 2016 2 commits
  3. 09 Apr, 2016 6 commits
    • Michael Thalmeier's avatar
      NFC: pn533: add I2C phy driver · dd7bedcd
      Michael Thalmeier authored
      This adds the I2C phy interface for the pn533 driver.
      This way the driver can be used to interact with I2C
      connected pn532 devices.
      Signed-off-by: default avatarMichael Thalmeier <michael.thalmeier@hale.at>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      dd7bedcd
    • Michael Thalmeier's avatar
      NFC: pn533: Separate physical layer from the core implementation · 9815c7cf
      Michael Thalmeier authored
      The driver now has all core stuff isolated in one file, and all
      the hardware link specifics in another. Writing a pn533 driver
      on top of another hardware link is now just a matter of adding a
      new file for that new hardware specifics.
      
      The first user of this separation will be the i2c based pn532
      driver that reuses pn533 core implementation on top of an i2c
      layer.
      Signed-off-by: default avatarMichael Thalmeier <michael.thalmeier@hale.at>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      9815c7cf
    • Michael Thalmeier's avatar
      NFC: pn533: Fix socket deadlock · 37f895d7
      Michael Thalmeier authored
      A deadlock can occur when the NFC raw socket is closed while
      the driver is processing a command.
      
      Following is the call graph of the affected situation:
      
      send data via raw_sock:
      -------------
      rawsock_tx_work
        sock_hold => socket refcnt++
        nfc_data_exchange => cb = rawsock_data_exchange_complete
      
          ops->im_transceive = pn533_transceive => arg->cb = db
                                     = rawsock_data_exchange_complete
      
            pn533_send_data_async => cb = pn533_data_exchange_complete
      
              __pn533_send_async => cmd->complete_cb = cb
                                    = pn533_data_exchange_complete
      
                if_ops->send_frame_async
      
      response:
      --------
      pn533_recv_response
        queue_work(priv->wq, &priv->cmd_complete_work)
      
      pn533_wq_cmd_complete
      
        pn533_send_async_complete
      
          cmd->complete_cb() = pn533_data_exchange_complete()
      
            arg->cb() = rawsock_data_exchange_complete()
      
              sock_put => socket refcnt-- => If the corresponding
                          socket gets closed in the meantime socket
                          will be destructed
      
                sk_free
      
                  __sk_free
      
                    sk->sk_destruct = rawsock_destruct
      
                      nfc_deactivate_target
      
                        ops->deactivate_target = pn533_deactivate_target
      
                          pn533_send_cmd_sync
      
                            pn533_send_cmd_async
      
                              __pn533_send_async
      
                                list_add_tail(&cmd->queue,&dev->cmd_queue)
                                        => add to command list because
                                           a command is currently
                                           processed
      
                              wait_for_completion
                                         => the workqueue thread waits
                                            here because it is the one
                                            processing the commands
                                               => deadlock
      
      To fix the deadlock pn533_deactivate_target is changed to
      issue the PN533_CMD_IN_RELEASE command in async mode. This
      way nothing blocks and the release command is executed after
      the current command.
      Signed-off-by: default avatarMichael Thalmeier <michael.thalmeier@hale.at>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      37f895d7
    • Michael Thalmeier's avatar
      NFC: pn533: Send ATR_REQ only if NFC_PROTO_NFC_DEP bit is set · e997ebbe
      Michael Thalmeier authored
      Currently it is not possible to only poll for passive targets
      with the pn533 driver. To change this ATR_REQ is only sent when
      NFC_PROTO_NFC_DEP is explicitly requested in poll_protocols.
      As most implementations (e.g. neard) poll for all protocols
      that are reported to be supported by the adapter, this should
      not have much of an effect on current implementations.
      Signed-off-by: default avatarMichael Thalmeier <michael.thalmeier@hale.at>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      e997ebbe
    • Eric Dumazet's avatar
      ipv6: fix inet6_lookup_listener() · 03c5b534
      Eric Dumazet authored
      A stupid refactoring bug in inet6_lookup_listener() needs to be fixed
      in order to get proper SO_REUSEPORT behavior.
      
      Fixes: 3b24d854 ("tcp/dccp: do not touch listener sk_refcnt under synflood")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarMaciej Żenczykowski <maze@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03c5b534
    • John Allen's avatar
      ibmvnic: Enable use of multiple tx/rx scrqs · 498cd8e4
      John Allen authored
      Enables the use of multiple transmit and receive scrqs allowing the ibmvnic
      driver to take advantage of multiqueue functionality. To achieve this, the
      driver must implement the process of negotiating the maximum number of
      queues allowed by the server. Initially, the driver will attempt to login
      with the maximum number of tx and rx queues supported by the server. If
      the server fails to allocate the requested number of scrqs, it will return
      partial success in the login response. In this case, we must reinitiate
      the login process from the request capabilities stage and attempt to login
      requesting fewer scrqs.
      Signed-off-by: default avatarJohn Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      498cd8e4
  4. 08 Apr, 2016 23 commits