1. 15 Nov, 2019 18 commits
  2. 14 Nov, 2019 1 commit
    • Jouni Hogander's avatar
      slcan: Fix memory leak in error path · ed50e160
      Jouni Hogander authored
      
      
      This patch is fixing memory leak reported by Syzkaller:
      
      BUG: memory leak unreferenced object 0xffff888067f65500 (size 4096):
        comm "syz-executor043", pid 454, jiffies 4294759719 (age 11.930s)
        hex dump (first 32 bytes):
          73 6c 63 61 6e 30 00 00 00 00 00 00 00 00 00 00 slcan0..........
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
        backtrace:
          [<00000000a06eec0d>] __kmalloc+0x18b/0x2c0
          [<0000000083306e66>] kvmalloc_node+0x3a/0xc0
          [<000000006ac27f87>] alloc_netdev_mqs+0x17a/0x1080
          [<0000000061a996c9>] slcan_open+0x3ae/0x9a0
          [<000000001226f0f9>] tty_ldisc_open.isra.1+0x76/0xc0
          [<0000000019289631>] tty_set_ldisc+0x28c/0x5f0
          [<000000004de5a617>] tty_ioctl+0x48d/0x1590
          [<00000000daef496f>] do_vfs_ioctl+0x1c7/0x1510
          [<0000000059068dbc>] ksys_ioctl+0x99/0xb0
          [<000000009a6eb334>] __x64_sys_ioctl+0x78/0xb0
          [<0000000053d0332e>] do_syscall_64+0x16f/0x580
          [<0000000021b83b99>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
          [<000000008ea75434>] 0xffffffffffffffff
      
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarJouni Hogander <jouni.hogander@unikie.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      ed50e160
  3. 13 Nov, 2019 4 commits
    • Dan Carpenter's avatar
      net: cdc_ncm: Signedness bug in cdc_ncm_set_dgram_size() · a56dcc6b
      Dan Carpenter authored
      This code is supposed to test for negative error codes and partial
      reads, but because sizeof() is size_t (unsigned) type then negative
      error codes are type promoted to high positive values and the condition
      doesn't work as expected.
      
      Fixes: 332f989a
      
       ("CDC-NCM: handle incomplete transfer of MTU")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a56dcc6b
    • Jouni Hogander's avatar
      slip: Fix memory leak in slip_open error path · 3b5a3997
      Jouni Hogander authored
      
      
      Driver/net/can/slcan.c is derived from slip.c. Memory leak was detected
      by Syzkaller in slcan. Same issue exists in slip.c and this patch is
      addressing the leak in slip.c.
      
      Here is the slcan memory leak trace reported by Syzkaller:
      
      BUG: memory leak unreferenced object 0xffff888067f65500 (size 4096):
        comm "syz-executor043", pid 454, jiffies 4294759719 (age 11.930s)
        hex dump (first 32 bytes):
          73 6c 63 61 6e 30 00 00 00 00 00 00 00 00 00 00 slcan0..........
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
        backtrace:
          [<00000000a06eec0d>] __kmalloc+0x18b/0x2c0
          [<0000000083306e66>] kvmalloc_node+0x3a/0xc0
          [<000000006ac27f87>] alloc_netdev_mqs+0x17a/0x1080
          [<0000000061a996c9>] slcan_open+0x3ae/0x9a0
          [<000000001226f0f9>] tty_ldisc_open.isra.1+0x76/0xc0
          [<0000000019289631>] tty_set_ldisc+0x28c/0x5f0
          [<000000004de5a617>] tty_ioctl+0x48d/0x1590
          [<00000000daef496f>] do_vfs_ioctl+0x1c7/0x1510
          [<0000000059068dbc>] ksys_ioctl+0x99/0xb0
          [<000000009a6eb334>] __x64_sys_ioctl+0x78/0xb0
          [<0000000053d0332e>] do_syscall_64+0x16f/0x580
          [<0000000021b83b99>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
          [<000000008ea75434>] 0xfffffffffffffff
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarJouni Hogander <jouni.hogander@unikie.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b5a3997
    • Aleksander Morgado's avatar
      net: usb: qmi_wwan: add support for Foxconn T77W968 LTE modules · 802753cb
      Aleksander Morgado authored
      
      
      These are the Foxconn-branded variants of the Dell DW5821e modules,
      same USB layout as those.
      
      The QMI interface is exposed in USB configuration #1:
      
      P:  Vendor=0489 ProdID=e0b4 Rev=03.18
      S:  Manufacturer=FII
      S:  Product=T77W968 LTE
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      
      Signed-off-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      802753cb
    • Ioana Ciornei's avatar
      dpaa2-eth: free already allocated channels on probe defer · 5aa4277d
      Ioana Ciornei authored
      The setup_dpio() function tries to allocate a number of channels equal
      to the number of CPUs online. When there are not enough DPCON objects
      already probed, the function will return EPROBE_DEFER. When this
      happens, the already allocated channels are not freed. This results in
      the incapacity of properly probing the next time around.
      Fix this by freeing the channels on the error path.
      
      Fixes: d7f5a9d8
      
       ("dpaa2-eth: defer probe on object allocate")
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5aa4277d
  4. 12 Nov, 2019 3 commits
  5. 11 Nov, 2019 1 commit
  6. 10 Nov, 2019 1 commit
  7. 09 Nov, 2019 6 commits
    • Magnus Karlsson's avatar
      ixgbe: need_wakeup flag might not be set for Tx · 0843aa8f
      Magnus Karlsson authored
      
      
      The need_wakeup flag for Tx might not be set for AF_XDP sockets that
      are only used to send packets. This happens if there is at least one
      outstanding packet that has not been completed by the hardware and we
      get that corresponding completion (which will not generate an
      interrupt since interrupts are disabled in the napi poll loop) between
      the time we stopped processing the Tx completions and interrupts are
      enabled again. In this case, the need_wakeup flag will have been
      cleared at the end of the Tx completion processing as we believe we
      will get an interrupt from the outstanding completion at a later point
      in time. But if this completion interrupt occurs before interrupts
      are enable, we lose it and should at that point really have set the
      need_wakeup flag since there are no more outstanding completions that
      can generate an interrupt to continue the processing. When this
      happens, user space will see a Tx queue need_wakeup of 0 and skip
      issuing a syscall, which means will never get into the Tx processing
      again and we have a deadlock.
      
      This patch introduces a quick fix for this issue by just setting the
      need_wakeup flag for Tx to 1 all the time. I am working on a proper
      fix for this that will toggle the flag appropriately, but it is more
      challenging than I anticipated and I am afraid that this patch will
      not be completed before the merge window closes, therefore this easier
      fix for now. This fix has a negative performance impact in the range
      of 0% to 4%. Towards the higher end of the scale if you have driver
      and application on the same core and issue a lot of packets, and
      towards no negative impact if you use two cores, lower transmission
      speeds and/or a workload that also receives packets.
      
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0843aa8f
    • Magnus Karlsson's avatar
      i40e: need_wakeup flag might not be set for Tx · 70563957
      Magnus Karlsson authored
      
      
      The need_wakeup flag for Tx might not be set for AF_XDP sockets that
      are only used to send packets. This happens if there is at least one
      outstanding packet that has not been completed by the hardware and we
      get that corresponding completion (which will not generate an
      interrupt since interrupts are disabled in the napi poll loop) between
      the time we stopped processing the Tx completions and interrupts are
      enabled again. In this case, the need_wakeup flag will have been
      cleared at the end of the Tx completion processing as we believe we
      will get an interrupt from the outstanding completion at a later point
      in time. But if this completion interrupt occurs before interrupts
      are enable, we lose it and should at that point really have set the
      need_wakeup flag since there are no more outstanding completions that
      can generate an interrupt to continue the processing. When this
      happens, user space will see a Tx queue need_wakeup of 0 and skip
      issuing a syscall, which means will never get into the Tx processing
      again and we have a deadlock.
      
      This patch introduces a quick fix for this issue by just setting the
      need_wakeup flag for Tx to 1 all the time. I am working on a proper
      fix for this that will toggle the flag appropriately, but it is more
      challenging than I anticipated and I am afraid that this patch will
      not be completed before the merge window closes, therefore this easier
      fix for now. This fix has a negative performance impact in the range
      of 0% to 4%. Towards the higher end of the scale if you have driver
      and application on the same core and issue a lot of packets, and
      towards no negative impact if you use two cores, lower transmission
      speeds and/or a workload that also receives packets.
      
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      70563957
    • Jacob Keller's avatar
      igb/igc: use ktime accessors for skb->tstamp · 6acab13b
      Jacob Keller authored
      
      
      When implementing launch time support in the igb and igc drivers, the
      skb->tstamp value is assumed to be a s64, but it's declared as a ktime_t
      value.
      
      Although ktime_t is typedef'd to s64 it wasn't always, and the kernel
      provides accessors for ktime_t values.
      
      Use the ktime_to_timespec64 and ktime_set accessors instead of directly
      assuming that the variable is always an s64.
      
      This improves portability if the code is ever moved to another kernel
      version, or if the definition of ktime_t ever changes again in the
      future.
      
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Acked-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6acab13b
    • Arkadiusz Kubalewski's avatar
      i40e: Fix for ethtool -m issue on X722 NIC · 4c9da6f2
      Arkadiusz Kubalewski authored
      
      
      This patch contains fix for a problem with command:
      'ethtool -m <dev>'
      which breaks functionality of:
      'ethtool <dev>'
      when called on X722 NIC
      
      Disallowed update of link phy_types on X722 NIC
      Currently correct value cannot be obtained from FW
      Previously wrong value returned by FW was used and was
      a root cause for incorrect output of 'ethtool <dev>' command
      
      Signed-off-by: default avatarArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4c9da6f2
    • Nicholas Nunley's avatar
      iavf: initialize ITRN registers with correct values · 4eda4e00
      Nicholas Nunley authored
      Since commit 92418fb1
      
       ("i40e/i40evf: Use usec value instead of reg
      value for ITR defines") the driver tracks the interrupt throttling
      intervals in single usec units, although the actual ITRN registers are
      programmed in 2 usec units. Most register programming flows in the driver
      correctly handle the conversion, although it is currently not applied when
      the registers are initialized to their default values. Most of the time
      this doesn't present a problem since the default values are usually
      immediately overwritten through the standard adaptive throttling mechanism,
      or updated manually by the user, but if adaptive throttling is disabled and
      the interval values are left alone then the incorrect value will persist.
      
      Since the intended default interval of 50 usecs (vs. 100 usecs as
      programmed) performs better for most traffic workloads, this can lead to
      performance regressions.
      
      This patch adds the correct conversion when writing the initial values to
      the ITRN registers.
      
      Signed-off-by: default avatarNicholas Nunley <nicholas.d.nunley@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4eda4e00
    • Colin Ian King's avatar
      ice: fix potential infinite loop because loop counter being too small · 615457a2
      Colin Ian King authored
      Currently the for-loop counter i is a u8 however it is being checked
      against a maximum value hw->num_tx_sched_layers which is a u16. Hence
      there is a potential wrap-around of counter i back to zero if
      hw->num_tx_sched_layers is greater than 255.  Fix this by making i
      a u16.
      
      Addresses-Coverity: ("Infinite loop")
      Fixes: b36c598c
      
       ("ice: Updates to Tx scheduler code")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      615457a2
  8. 08 Nov, 2019 6 commits
    • Manish Chopra's avatar
      qede: fix NULL pointer deref in __qede_remove() · deabc871
      Manish Chopra authored
      
      
      While rebooting the system with SR-IOV vfs enabled leads
      to below crash due to recurrence of __qede_remove() on the VF
      devices (first from .shutdown() flow of the VF itself and
      another from PF's .shutdown() flow executing pci_disable_sriov())
      
      This patch adds a safeguard in __qede_remove() flow to fix this,
      so that driver doesn't attempt to remove "already removed" devices.
      
      [  194.360134] BUG: unable to handle kernel NULL pointer dereference at 00000000000008dc
      [  194.360227] IP: [<ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede]
      [  194.360304] PGD 0
      [  194.360325] Oops: 0000 [#1] SMP
      [  194.360360] Modules linked in: tcp_lp fuse tun bridge stp llc devlink bonding ip_set nfnetlink ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_umad rpcrdma sunrpc rdma_ucm ib_uverbs ib_iser rdma_cm iw_cm ib_cm libiscsi scsi_transport_iscsi dell_smbios iTCO_wdt iTCO_vendor_support dell_wmi_descriptor dcdbas vfat fat pcc_cpufreq skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd qedr ib_core pcspkr ses enclosure joydev ipmi_ssif sg i2c_i801 lpc_ich mei_me mei wmi ipmi_si ipmi_devintf ipmi_msghandler tpm_crb acpi_pad acpi_power_meter xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel mgag200
      [  194.361044]  qede i2c_algo_bit drm_kms_helper qed syscopyarea sysfillrect nvme sysimgblt fb_sys_fops ttm nvme_core mpt3sas crc8 ptp drm pps_core ahci raid_class scsi_transport_sas libahci libata drm_panel_orientation_quirks nfit libnvdimm dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_tables]
      [  194.361297] CPU: 51 PID: 7996 Comm: reboot Kdump: loaded Not tainted 3.10.0-1062.el7.x86_64 #1
      [  194.361359] Hardware name: Dell Inc. PowerEdge MX840c/0740HW, BIOS 2.4.6 10/15/2019
      [  194.361412] task: ffff9cea9b360000 ti: ffff9ceabebdc000 task.ti: ffff9ceabebdc000
      [  194.361463] RIP: 0010:[<ffffffffc03553c4>]  [<ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede]
      [  194.361534] RSP: 0018:ffff9ceabebdfac0  EFLAGS: 00010282
      [  194.361570] RAX: 0000000000000000 RBX: ffff9cd013846098 RCX: 0000000000000000
      [  194.361621] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9cd013846098
      [  194.361668] RBP: ffff9ceabebdfae8 R08: 0000000000000000 R09: 0000000000000000
      [  194.361715] R10: 00000000bfe14201 R11: ffff9ceabfe141e0 R12: 0000000000000000
      [  194.361762] R13: ffff9cd013846098 R14: 0000000000000000 R15: ffff9ceab5e48000
      [  194.361810] FS:  00007f799c02d880(0000) GS:ffff9ceacb0c0000(0000) knlGS:0000000000000000
      [  194.361865] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  194.361903] CR2: 00000000000008dc CR3: 0000001bdac76000 CR4: 00000000007607e0
      [  194.361953] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  194.362002] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  194.362051] PKRU: 55555554
      [  194.362073] Call Trace:
      [  194.362109]  [<ffffffffc0355500>] qede_remove+0x10/0x20 [qede]
      [  194.362180]  [<ffffffffb97d0f3e>] pci_device_remove+0x3e/0xc0
      [  194.362240]  [<ffffffffb98b3c52>] __device_release_driver+0x82/0xf0
      [  194.362285]  [<ffffffffb98b3ce3>] device_release_driver+0x23/0x30
      [  194.362343]  [<ffffffffb97c86d4>] pci_stop_bus_device+0x84/0xa0
      [  194.362388]  [<ffffffffb97c87e2>] pci_stop_and_remove_bus_device+0x12/0x20
      [  194.362450]  [<ffffffffb97f153f>] pci_iov_remove_virtfn+0xaf/0x160
      [  194.362496]  [<ffffffffb97f1aec>] sriov_disable+0x3c/0xf0
      [  194.362534]  [<ffffffffb97f1bc3>] pci_disable_sriov+0x23/0x30
      [  194.362599]  [<ffffffffc02f83c3>] qed_sriov_disable+0x5e3/0x650 [qed]
      [  194.362658]  [<ffffffffb9622df6>] ? kfree+0x106/0x140
      [  194.362709]  [<ffffffffc02cc0c0>] ? qed_free_stream_mem+0x70/0x90 [qed]
      [  194.362754]  [<ffffffffb9622df6>] ? kfree+0x106/0x140
      [  194.362803]  [<ffffffffc02cd659>] qed_slowpath_stop+0x1a9/0x1d0 [qed]
      [  194.362854]  [<ffffffffc035544e>] __qede_remove+0xae/0x130 [qede]
      [  194.362904]  [<ffffffffc03554e0>] qede_shutdown+0x10/0x20 [qede]
      [  194.362956]  [<ffffffffb97cf90a>] pci_device_shutdown+0x3a/0x60
      [  194.363010]  [<ffffffffb98b180b>] device_shutdown+0xfb/0x1f0
      [  194.363066]  [<ffffffffb94b66c6>] kernel_restart_prepare+0x36/0x40
      [  194.363107]  [<ffffffffb94b66e2>] kernel_restart+0x12/0x60
      [  194.363146]  [<ffffffffb94b6959>] SYSC_reboot+0x229/0x260
      [  194.363196]  [<ffffffffb95f200d>] ? handle_mm_fault+0x39d/0x9b0
      [  194.363253]  [<ffffffffb942b621>] ? __switch_to+0x151/0x580
      [  194.363304]  [<ffffffffb9b7ec28>] ? __schedule+0x448/0x9c0
      [  194.363343]  [<ffffffffb94b69fe>] SyS_reboot+0xe/0x10
      [  194.363387]  [<ffffffffb9b8bede>] system_call_fastpath+0x25/0x2a
      [  194.363430] Code: f9 e9 37 ff ff ff 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 4c 8d af 98 00 00 00 41 54 4c 89 ef 41 89 f4 53 e8 4c e4 55 f9 <80> b8 dc 08 00 00 01 48 89 c3 4c 8d b8 c0 08 00 00 4c 8b b0 c0
      [  194.363712] RIP  [<ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede]
      [  194.363764]  RSP <ffff9ceabebdfac0>
      [  194.363791] CR2: 00000000000008dc
      
      Signed-off-by: default avatarManish Chopra <manishc@marvell.com>
      Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
      Signed-off-by: default avatarSudarsana Kalluru <skalluru@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      deabc871
    • Mordechay Goodstein's avatar
      iwlwifi: pcie: don't consider IV len in A-MSDU · cb1a4bad
      Mordechay Goodstein authored
      
      
      From gen2 PN is totally offloaded to hardware (also the space for the
      IV isn't part of the skb).  As you can see in mvm/mac80211.c:3545, the
      MAC for cipher types CCMP/GCMP doesn't set
      IEEE80211_KEY_FLAG_PUT_IV_SPACE for gen2 NICs.
      
      This causes all the AMSDU data to be corrupted with cipher enabled.
      
      Signed-off-by: default avatarMordechay Goodstein <mordechay.goodstein@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      cb1a4bad
    • Alexander Sverdlin's avatar
      net: ethernet: octeon_mgmt: Account for second possible VLAN header · e4dd5608
      Alexander Sverdlin authored
      Octeon's input ring-buffer entry has 14 bits-wide size field, so to account
      for second possible VLAN header max_mtu must be further reduced.
      
      Fixes: 109cc165
      
       ("ethernet/cavium: use core min/max MTU checking")
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e4dd5608
    • Uwe Kleine-König's avatar
      pwm: bcm-iproc: Prevent unloading the driver module while in use · 24906a41
      Uwe Kleine-König authored
      The owner member of struct pwm_ops must be set to THIS_MODULE to
      increase the reference count of the module such that the module cannot
      be removed while its code is in use.
      
      Fixes: daa5abc4
      
       ("pwm: Add support for Broadcom iProc PWM controller")
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      24906a41
    • Dan Carpenter's avatar
      block: drbd: remove a stray unlock in __drbd_send_protocol() · 8e9c5230
      Dan Carpenter authored
      There are two callers of this function and they both unlock the mutex so
      this ends up being a double unlock.
      
      Fixes: 44ed167d
      
       ("drbd: rcu_read_lock() and rcu_dereference() for tconn->net_conf")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      8e9c5230
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Fix invalid EPB setting · c31432fa
      Srinivas Pandruvada authored
      The max value of EPB can only be 0x0F. Attempting to set more than that
      triggers an "unchecked MSR access error" warning which happens in
      intel_pstate_hwp_force_min_perf() called via cpufreq stop_cpu().
      
      However, it is not even necessary to touch the EPB from intel_pstate,
      because it is restored on every CPU online by the intel_epb.c code,
      so let that code do the right thing and drop the redundant (and
      incorrect) EPB update from intel_pstate.
      
      Fixes: af3b7379
      
       ("cpufreq: intel_pstate: Force HWP min perf before offline")
      Reported-by: default avatarQian Cai <cai@lca.pw>
      Cc: 5.2+ <stable@vger.kernel.org> # 5.2+
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [ rjw: Changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c31432fa