1. 24 5月, 2018 1 次提交
    • N
      ibmvnic: Only do H_EOI for mobility events · 73f9d364
      Nathan Fontenot 提交于
      When enabling the sub-CRQ IRQ a previous update sent a H_EOI prior
      to the enablement to clear any pending interrupts that may be present
      across a partition migration. This fixed a firmware bug where a
      migration could erroneously indicate that a H_EOI was pending.
      
      The H_EOI should only be sent when enabling during a mobility
      event though. Doing so at other time could wrong and can produce
      extra driver output when IRQs are enabled when doing TX completion.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73f9d364
  2. 23 5月, 2018 4 次提交
  3. 19 5月, 2018 2 次提交
  4. 18 5月, 2018 3 次提交
  5. 17 5月, 2018 4 次提交
  6. 15 5月, 2018 2 次提交
  7. 14 5月, 2018 2 次提交
  8. 12 5月, 2018 4 次提交
  9. 11 5月, 2018 12 次提交
  10. 10 5月, 2018 1 次提交
    • J
      nfp: bpf: allow zero-length capabilities · 26aeb9da
      Jakub Kicinski 提交于
      Some BPF capabilities carry no value, they simply indicate feature
      is present.  Our capability parsing loop will exit early if last
      capability is zero-length because it's looking for more than 8 bytes
      of data (8B is our TLV header length).  Allow the last capability to
      be zero-length.
      
      This bug would lead to driver failing to probe with the following error
      if the last capability FW advertises is zero-length:
      
          nfp: BPF capabilities left after parsing, parsed:92 total length:100
          nfp: invalid BPF capabilities at offset:92
      
      Note the "parsed" and "length" values are 8 apart.
      
      No shipping FW runs into this issue, but we can't guarantee that will
      remain the case.
      
      Fixes: 77a844ee ("nfp: bpf: prepare for parsing BPF FW capabilities")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      26aeb9da
  11. 09 5月, 2018 1 次提交
    • H
      r8169: fix powering up RTL8168h · 3148dedf
      Heiner Kallweit 提交于
      Since commit a92a0849 "r8169: improve runtime pm in general and
      suspend unused ports" interfaces w/o link are runtime-suspended after
      10s. On systems where drivers take longer to load this can lead to the
      situation that the interface is runtime-suspended already when it's
      initially brought up.
      This shouldn't be a problem because rtl_open() resumes MAC/PHY.
      However with at least one chip version the interface doesn't properly
      come up, as reported here:
      https://bugzilla.kernel.org/show_bug.cgi?id=199549
      
      The vendor driver uses a delay to give certain chip versions some
      time to resume before starting the PHY configuration. So let's do
      the same. I don't know which chip versions may be affected,
      therefore apply this delay always.
      
      This patch was reported to fix the issue for RTL8168h.
      I was able to reproduce the issue on an Asus H310I-Plus which also
      uses a RTL8168h. Also in my case the patch fixed the issue.
      Reported-by: NSlava Kardakov <ojab@ojab.ru>
      Tested-by: NSlava Kardakov <ojab@ojab.ru>
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3148dedf
  12. 08 5月, 2018 4 次提交