1. 03 Feb, 2021 6 commits
  2. 02 Feb, 2021 31 commits
  3. 01 Feb, 2021 3 commits
    • Aleksandr Loktionov's avatar
      i40e: Revert "i40e: don't report link up for a VF who hasn't enabled queues" · f559a356
      Aleksandr Loktionov authored
      This reverts commit 2ad1274f
      
      VF queues were not brought up when PF was brought up after being
      downed if the VF driver disabled VFs queues during PF down.
      This could happen in some older or external VF driver implementations.
      The problem was that PF driver used vf->queues_enabled as a condition
      to decide what link-state it would send out which caused the issue.
      
      Remove the check for vf->queues_enabled in the VF link notify.
      Now VF will always be notified of the current link status.
      Also remove the queues_enabled member from i40e_vf structure as it is
      not used anymore. Otherwise VNF implementation was broken and caused
      a link flap.
      
      The original commit was a workaround to avoid breaking existing VFs though
      it's really a fault of the VF code not the PF. The commit should be safe to
      revert as all of the VFs we know of have been fixed. Also, since we now
      know there is a related bug in the workaround, removing it is preferred.
      
      Fixes: 2ad1274f ("i40e: don't report link up for a VF who hasn't enabled")
      Signed-off-by: default avatarAleksandr Loktionov <aleksandr.loktionov@intel.com>
      Signed-off-by: default avatarArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      f559a356
    • Linus Torvalds's avatar
      Merge tag 'media/v5.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 88bb507a
      Linus Torvalds authored
      Pull media fixes from Mauro Carvalho Chehab:
       "The rockship rkisp1 driver will be promoted from staging in 5.11.
      
        While not too late, do a few uAPI changes which are needed to better
        support its functionalities"
      
      * tag 'media/v5.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
        media: rockchip: rkisp1: extend uapi array sizes
        media: rockchip: rkisp1: carry ip version information
        media: rockchip: rkisp1: reduce number of histogram grid elements in uapi
        media: rkisp1: stats: mask the hist_bins values
        media: rkisp1: stats: remove a wrong cast to u8
        media: rkisp1: uapi: change hist_bins array type from __u16 to __u32
      88bb507a
    • Hans de Goede's avatar
      staging: rtl8723bs: Move wiphy setup to after reading the regulatory settings from the chip · 50af06d4
      Hans de Goede authored
      Commit 81f153fa ("staging: rtl8723bs: fix wireless regulatory API
      misuse") moved the wiphy_apply_custom_regulatory() call to earlier in the
      driver's init-sequence, so that it gets called before wiphy_register().
      
      But at this point in time the eFuses which code the regulatory-settings
      for the chip have not been read by the driver yet, causing
      _rtw_reg_apply_flags() to set the IEEE80211_CHAN_DISABLED flag on *all*
      channels.
      
      On the device where I initially tested the fix, a Jumper EZpad 7 tablet,
      this does not cause any problems because shortly after init the
      rtw_reg_notifier() gets called fixing things up. I guess this happens
      into response to receiving a (broadcast) packet with regulatory info
      from the access-point ?
      
      But on another device with a RTL8723BS wifi chip, an Acer Switch 10E
      (SW3-016), the rtw_reg_notifier() never gets called. I assume that some
      fuse has been set on this device to ignore regulatory info received from
      access-points.
      
      This means that on the Acer the driver is stuck in a state with all
      channels disabled, leading to non working Wifi.
      
      We cannot move the wiphy_apply_custom_regulatory() call back, because
      that call must be made before the wiphy_register() call.
      
      Instead move the entire rtw_wdev_alloc() call to after the Efuses have
      been read, fixing all channels being disabled in the initial channel-map.
      
      Fixes: 81f153fa ("staging: rtl8723bs: fix wireless regulatory API misuse")
      Cc: Johannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Link: https://lore.kernel.org/r/20210201152956.370186-2-hdegoede@redhat.comSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      50af06d4