1. 25 Jun, 2013 4 commits
  2. 24 Jun, 2013 3 commits
  3. 20 Jun, 2013 12 commits
  4. 18 Jun, 2013 2 commits
  5. 17 Jun, 2013 5 commits
  6. 15 Jun, 2013 1 commit
    • David Daney's avatar
      smp.h: Use local_irq_{save,restore}() in !SMP version of on_each_cpu(). · f21afc25
      David Daney authored
      Thanks to commit f91eb62f
      
       ("init: scream bloody murder if interrupts
      are enabled too early"), "bloody murder" is now being screamed.
      
      With a MIPS OCTEON config, we use on_each_cpu() in our
      irq_chip.irq_bus_sync_unlock() function.  This gets called in early as a
      result of the time_init() call.  Because the !SMP version of
      on_each_cpu() unconditionally enables irqs, we get:
      
          WARNING: at init/main.c:560 start_kernel+0x250/0x410()
          Interrupts were enabled early
          CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-rc5-Cavium-Octeon+ #801
          Call Trace:
            show_stack+0x68/0x80
            warn_slowpath_common+0x78/0xb0
            warn_slowpath_fmt+0x38/0x48
            start_kernel+0x250/0x410
      
      Suggested fix: Do what we already do in the SMP version of
      on_each_cpu(), and use local_irq_save/local_irq_restore.  Because we
      need a flags variable, make it a static inline to avoid name space
      issues.
      
      [ Change from v1: Convert on_each_cpu to a static inline function, add
        #include <linux/irqflags.h> to avoid build breakage on some files.
      
        on_each_cpu_mask() and on_each_cpu_cond() suffer the same problem as
        on_each_cpu(), but they are not causing !SMP bugs for me, so I will
        defer changing them to a less urgent patch. ]
      Signed-off-by: default avatarDavid Daney <david.daney@cavium.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f21afc25
  7. 14 Jun, 2013 12 commits
    • Pravin B Shelar's avatar
      openvswitch: Fix struct comment. · 45bfa52e
      Pravin B Shelar authored
      
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      45bfa52e
    • Samuel Ortiz's avatar
      NFC: Send netlink events for secure elements additions and removals · 2757c372
      Samuel Ortiz authored
      
      
      When an NFC driver or host controller stack discovers a secure element,
      it will call nfc_add_se(). In order for userspace applications to use
      these secure elements, a netlink event will then be sent with the SE
      index and its type. With that information userspace applications can
      decide wether or not to enable SEs, through their indexes.
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      2757c372
    • Samuel Ortiz's avatar
      NFC: Add secure elements addition and removal API · fed7c25e
      Samuel Ortiz authored
      
      
      This API will allow NFC drivers to add and remove the secure elements
      they know about or detect. Typically this should be called (asynchronously
      or not) from the driver or the host interface stack detect_se hook.
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      fed7c25e
    • Samuel Ortiz's avatar
      NFC: Extend and fix the internal secure element API · 0a946301
      Samuel Ortiz authored
      
      
      Secure elements need to be discovered after enabling the NFC controller.
      This is typically done by the NCI core and the HCI drivers (HCI does not
      specify how to discover SEs, it is left to the specific drivers).
      Also, the SE enable/disable API explicitely takes a SE index as its
      argument.
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      0a946301
    • Samuel Ortiz's avatar
      NFC: Remove the static supported_se field · 0b456c41
      Samuel Ortiz authored
      
      
      Supported secure elements are typically found during a discovery process
      initiated when the NFC controller is up and running. For a given NFC
      chipset there can be many configurations (embedded SE or not, with or
      without a SIM card wired to the NFC controller SWP interface, etc...) and
      thus driver code will never know before hand which SEs are available.
      So we remove this field, it will be replaced by a real SE discovery
      mechanism.
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      0b456c41
    • Samuel Ortiz's avatar
      NFC: pn533: Copy NFCID2 through ATR_REQ · 322bce95
      Samuel Ortiz authored
      
      
      When using NFC-F we should copy the NFCID2 buffer that we got from
      SENSF_RES through the ATR_REQ NFCID3 buffer. Not doing so violates
      NFC Forum digital requirement #189.
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      322bce95
    • Frederic Danis's avatar
      NFC: Add NCI over SPI receive · 391d8a2d
      Frederic Danis authored
      
      
      Before any operation, driver interruption is de-asserted to prevent
      race condition between TX and RX.
      
      Transaction starts by emitting "Direct read" and acknowledged mode
      bytes. Then packet length is read allowing to allocate correct NCI
      socket buffer. After that payload is retrieved.
      
      A delay after the transaction can be added.
      This delay is determined by the driver during nci_spi_allocate_device()
      call and can be 0.
      
      If acknowledged mode is set:
      - CRC of header and payload is checked
      - if frame reception fails (CRC error): NACK is sent
      - if received frame has ACK or NACK flag: unblock nci_spi_send()
      
      Payload is passed to NCI module.
      
      At the end, driver interruption is re asserted.
      Signed-off-by: default avatarFrederic Danis <frederic.danis@linux.intel.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      391d8a2d
    • Frederic Danis's avatar
      NFC: Add NCI over SPI send · ee9596d4
      Frederic Danis authored
      
      
      Before any operation, driver interruption is de-asserted to prevent
      race condition between TX and RX.
      
      The NCI over SPI header is added in front of NCI packet.
      If acknowledged mode is set, CRC-16-CCITT is added to the packet.
      Then the packet is forwarded to SPI module to be sent.
      
      A delay after the transaction is added.
      This delay is determined by the driver during nci_spi_allocate_device()
      call and can be 0.
      
      After data has been sent, driver interruption is re-asserted.
      
      If acknowledged mode is set, nci_spi_send will block until
      acknowledgment is received.
      Signed-off-by: default avatarFrederic Danis <frederic.danis@linux.intel.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      ee9596d4
    • Frederic Danis's avatar
      NFC: Add basic NCI over SPI · 8a00a61b
      Frederic Danis authored
      
      
      The NFC Forum defines a transport interface based on
      Serial Peripheral Interface (SPI) for the NFC Controller
      Interface (NCI).
      
      This module implements the SPI transport of NCI, calling SPI module
      directly to read/write data to NFC controller (NFCC).
      
      NFCC driver should provide functions performing device open and close.
      It should also provide functions asserting/de-asserting interruption
      to prevent TX/RX race conditions.
      NFCC driver can also fix a delay between transactions if needed by
      the hardware.
      Signed-off-by: default avatarFrederic Danis <frederic.danis@linux.intel.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      8a00a61b
    • Rony Efraim's avatar
      net/mlx4: Add VF link state support · 948e306d
      Rony Efraim authored
      
      
      Add support to change the link state of VF (vPort)
      Signed-off-by: default avatarRony Efraim <ronye@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      948e306d
    • Rony Efraim's avatar
      net/core: Add VF link state control · 1d8faf48
      Rony Efraim authored
      
      
      Add netlink directives and ndo entry to allow for controling
      VF link, which can be in one of three states:
      
      Auto - VF link state reflects the PF link state (default)
      
      Up - VF link state is up, traffic from VF to VF works even if
      the actual PF link is down
      
      Down - VF link state is down, no traffic from/to this VF, can be of
      use while configuring the VF
      Signed-off-by: default avatarRony Efraim <ronye@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d8faf48
    • Willem de Bruijn's avatar
      net-rps: fixes for rps flow limit · 5f121b9a
      Willem de Bruijn authored
      
      
      Caught by sparse:
      - __rcu: missing annotation to sd->flow_limit
      - __user: direct access in cpumask_scnprintf
      
      Also
      - add endline character when printing bitmap if room in buffer
      - avoid bucket overflow by reducing FLOW_LIMIT_HISTORY
      
      The last item warrants some explanation. The hashtable buckets are
      subject to overflow if FLOW_LIMIT_HISTORY is larger than or equal
      to bucket size, since all packets may end up in a single bucket. The
      current (rather arbitrary) history value of 256 happens to match the
      buffer size (u8).
      
      As a result, with a single flow, the first 128 packets are accepted
      (correct), the second 128 packets dropped (correct) and then the
      history[] array has filled, so that each subsequent new packet
      causes an increment in the bucket for new_flow plus a decrement
      for old_flow: a steady state.
      
      This is fine if packets are dropped, as the steady state goes away
      as soon as a mix of traffic reappears. But, because the 256th packet
      overflowed the bucket to 0: no packets are dropped.
      
      Instead of explicitly adding an overflow check, this patch changes
      FLOW_LIMIT_HISTORY to never be able to overflow a single bucket.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      (first item)
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f121b9a
  8. 13 Jun, 2013 1 commit