1. 27 3月, 2020 5 次提交
  2. 28 2月, 2020 1 次提交
    • R
      iommu: Use C99 flexible array in fwspec · 098accf2
      Robin Murphy 提交于
      Although the 1-element array was a typical pre-C99 way to implement
      variable-length structures, and indeed is a fundamental construct in the
      APIs of certain other popular platforms, there's no good reason for it
      here (and in particular the sizeof() trick is far too "clever" for its
      own good). We can just as easily implement iommu_fwspec's preallocation
      behaviour using a standard flexible array member, so let's make it look
      the way most readers would expect.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      098accf2
  3. 22 2月, 2020 2 次提交
    • R
      ACPI: PM: s2idle: Check fixed wakeup events in acpi_s2idle_wake() · 63fb9623
      Rafael J. Wysocki 提交于
      Commit fdde0ff8 ("ACPI: PM: s2idle: Prevent spurious SCIs from
      waking up the system") overlooked the fact that fixed events can wake
      up the system too and broke RTC wakeup from suspend-to-idle as a
      result.
      
      Fix this issue by checking the fixed events in acpi_s2idle_wake() in
      addition to checking wakeup GPEs and break out of the suspend-to-idle
      loop if the status bits of any enabled fixed events are set then.
      
      Fixes: fdde0ff8 ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
      Reported-and-tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      63fb9623
    • G
      hwmon: (w83627ehf) Fix crash seen with W83627DHG-P · e61d2392
      Guenter Roeck 提交于
      Loading the driver on a system with W83627DHG-P crashes as follows.
      
      w83627ehf: Found W83627DHG-P chip at 0x290
      BUG: kernel NULL pointer dereference, address: 0000000000000000
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP NOPTI
      CPU: 0 PID: 604 Comm: sensors Not tainted 5.6.0-rc2-00055-gca7e1fd1 #29
      Hardware name:  /D425KT, BIOS MWPNT10N.86A.0132.2013.0726.1534 07/26/2013
      RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
      Code: [... ]
      RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
      RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
      RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
      R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
      R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
      FS:  00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
      Call Trace:
       ? cp_new_stat+0x12d/0x160
       hwmon_attr_show_string+0x37/0x70 [hwmon]
       dev_attr_show+0x14/0x50
       sysfs_kf_seq_show+0xb5/0x1b0
       seq_read+0xcf/0x460
       vfs_read+0x9b/0x150
       ksys_read+0x5f/0xe0
       do_syscall_64+0x48/0x190
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      ...
      
      Temperature labels are not always present. Adjust sysfs attribute
      visibility accordingly.
      Reported-by: NMeelis Roos <mroos@linux.ee>
      Suggested-by: NDr. David Alan Gilbert <linux@treblig.org>
      Reviewed-by: NDr. David Alan Gilbert <linux@treblig.org>
      Cc: Meelis Roos <mroos@linux.ee>
      Cc: Dr. David Alan Gilbert <linux@treblig.org>
      Fixes: 266cd583 ("hwmon: (w83627ehf) convert to with_info interface")
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      e61d2392
  4. 21 2月, 2020 10 次提交
  5. 20 2月, 2020 9 次提交
    • G
      hwmon: (acpi_power_meter) Fix lockdep splat · badcd454
      Guenter Roeck 提交于
      Damien Le Moal reports a lockdep splat with the acpi_power_meter,
      observed with Linux v5.5 and later.
      
      ======================================================
      WARNING: possible circular locking dependency detected
      5.6.0-rc2+ #629 Not tainted
      ------------------------------------------------------
      python/1397 is trying to acquire lock:
      ffff888619080070 (&resource->lock){+.+.}, at: show_power+0x3c/0xa0 [acpi_power_meter]
      
                     but task is already holding lock:
      ffff88881643f188 (kn->count#119){++++}, at: kernfs_seq_start+0x6a/0x160
      
                     which lock already depends on the new lock.
      
                     the existing dependency chain (in reverse order) is:
      
                     -> #1 (kn->count#119){++++}:
             __kernfs_remove+0x626/0x7e0
             kernfs_remove_by_name_ns+0x41/0x80
             remove_attrs+0xcb/0x3c0 [acpi_power_meter]
             acpi_power_meter_notify+0x1f7/0x310 [acpi_power_meter]
             acpi_ev_notify_dispatch+0x198/0x1f3
             acpi_os_execute_deferred+0x4d/0x70
             process_one_work+0x7c8/0x1340
             worker_thread+0x94/0xc70
             kthread+0x2ed/0x3f0
             ret_from_fork+0x24/0x30
      
                     -> #0 (&resource->lock){+.+.}:
             __lock_acquire+0x20be/0x49b0
             lock_acquire+0x127/0x340
             __mutex_lock+0x15b/0x1350
             show_power+0x3c/0xa0 [acpi_power_meter]
             dev_attr_show+0x3f/0x80
             sysfs_kf_seq_show+0x216/0x410
             seq_read+0x407/0xf90
             vfs_read+0x152/0x2c0
             ksys_read+0xf3/0x1d0
             do_syscall_64+0x95/0x1010
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
                     other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(kn->count#119);
                                     lock(&resource->lock);
                                     lock(kn->count#119);
        lock(&resource->lock);
      
                      *** DEADLOCK ***
      4 locks held by python/1397:
       #0: ffff8890242d64e0 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x9b/0xb0
       #1: ffff889040be74e0 (&p->lock){+.+.}, at: seq_read+0x6b/0xf90
       #2: ffff8890448eb880 (&of->mutex){+.+.}, at: kernfs_seq_start+0x47/0x160
       #3: ffff88881643f188 (kn->count#119){++++}, at: kernfs_seq_start+0x6a/0x160
      
                     stack backtrace:
      CPU: 10 PID: 1397 Comm: python Not tainted 5.6.0-rc2+ #629
      Hardware name: Supermicro Super Server/X11DPL-i, BIOS 3.1 05/21/2019
      Call Trace:
       dump_stack+0x97/0xe0
       check_noncircular+0x32e/0x3e0
       ? print_circular_bug.isra.0+0x1e0/0x1e0
       ? unwind_next_frame+0xb9a/0x1890
       ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
       ? graph_lock+0x79/0x170
       ? __lockdep_reset_lock+0x3c0/0x3c0
       ? mark_lock+0xbc/0x1150
       __lock_acquire+0x20be/0x49b0
       ? mark_held_locks+0xe0/0xe0
       ? stack_trace_save+0x91/0xc0
       lock_acquire+0x127/0x340
       ? show_power+0x3c/0xa0 [acpi_power_meter]
       ? device_remove_bin_file+0x10/0x10
       ? device_remove_bin_file+0x10/0x10
       __mutex_lock+0x15b/0x1350
       ? show_power+0x3c/0xa0 [acpi_power_meter]
       ? show_power+0x3c/0xa0 [acpi_power_meter]
       ? mutex_lock_io_nested+0x11f0/0x11f0
       ? lock_downgrade+0x6a0/0x6a0
       ? kernfs_seq_start+0x47/0x160
       ? lock_acquire+0x127/0x340
       ? kernfs_seq_start+0x6a/0x160
       ? device_remove_bin_file+0x10/0x10
       ? show_power+0x3c/0xa0 [acpi_power_meter]
       show_power+0x3c/0xa0 [acpi_power_meter]
       dev_attr_show+0x3f/0x80
       ? memset+0x20/0x40
       sysfs_kf_seq_show+0x216/0x410
       seq_read+0x407/0xf90
       ? security_file_permission+0x16f/0x2c0
       vfs_read+0x152/0x2c0
      
      Problem is that reading an attribute takes the kernfs lock in the kernfs
      code, then resource->lock in the driver. During an ACPI notification, the
      opposite happens: The resource lock is taken first, followed by the kernfs
      lock when sysfs attributes are removed and re-created. Presumably this is
      now seen due to some locking related changes in kernfs after v5.4, but it
      was likely always a problem.
      
      Fix the problem by not blindly acquiring the lock in the notification
      function. It is only needed to protect the various update functions.
      However, those update functions are called anyway when sysfs attributes
      are read. This means that we can just stop calling those functions from
      the notifier, and the resource lock in the notifier function is no longer
      needed.
      
      That leaves two situations:
      
      First, METER_NOTIFY_CONFIG removes and re-allocates capability strings.
      While it did so under the resource lock, _displaying_ those strings was not
      protected, creating a race condition. To solve this problem, selectively
      protect both removal/creation and reporting of capability attributes with
      the resource lock.
      
      Second, removing and re-creating the attribute files is no longer protected
      by the resource lock. That doesn't matter since access to each individual
      attribute is protected by the kernfs lock. Userspace may get messed up if
      attributes disappear and reappear under its nose, but that is not different
      than today, and there is nothing we can do about it without major driver
      restructuring.
      
      Last but not least, when removing the driver, remove attribute functions
      first, then release capability strings. This avoids yet another race
      condition.
      Reported-by: NDamien Le Moal <Damien.LeMoal@wdc.com>
      Cc: Damien Le Moal <Damien.LeMoal@wdc.com>
      Cc: stable@vger.kernel.org # v5.5+
      Tested-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      badcd454
    • B
      ice: Wait for VF to be reset/ready before configuration · c54d209c
      Brett Creeley 提交于
      The configuration/command below is failing when the VF in the xml
      file is already bound to the host iavf driver.
      
      pci_0000_af_0_0.xml:
      
      <interface type='hostdev' managed='yes'>
      <source>
      <address type='pci' domain='0x0000' bus='0xaf' slot='0x0' function='0x0'/>
      </source>
      <mac address='00:de:ad:00:11:01'/>
      </interface>
      
      > virsh attach-device domain_name pci_0000_af_0_0.xml
      error: Failed to attach device from pci_0000_af_0_0.xml
      error: Cannot set interface MAC/vlanid to 00:de:ad:00:11:01/0 for
      	ifname ens1f1 vf 0: Device or resource busy
      
      This is failing because the VF has not been completely removed/reset
      after being unbound (via the virsh command above) from the host iavf
      driver and ice_set_vf_mac() checks if the VF is disabled before waiting
      for the reset to finish.
      
      Fix this by waiting for the VF remove/reset process to happen before
      checking if the VF is disabled. Also, since many functions for VF
      administration on the PF were more or less calling the same 3 functions
      (ice_wait_on_vf_reset(), ice_is_vf_disabled(), and ice_check_vf_init())
      move these into the helper function ice_check_vf_ready_for_cfg(). Then
      call this function in any flow that attempts to configure/query a VF
      from the PF.
      
      Lastly, increase the maximum wait time in ice_wait_on_vf_reset() to
      800ms, and modify/add the #define(s) that determine the wait time.
      This was done for robustness because in rare/stress cases VF removal can
      take a max of ~800ms and previously the wait was a max of ~300ms.
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c54d209c
    • M
      ice: Don't tell the OS that link is going down · 8a55c08d
      Michal Swiatkowski 提交于
      Remove code that tell the OS that link is going down when user
      change flow control via ethtool. When link is up it isn't certain
      that link goes down after 0x0605 aq command. If link doesn't go
      down, OS thinks that link is down, but physical link is up. To
      reset this state user have to take interface down and up.
      
      If link goes down after 0x0605 command, FW send information
      about that and after that driver tells the OS that the link goes
      down. So this code in ethtool is unnecessary.
      Signed-off-by: NMichal Swiatkowski <michal.swiatkowski@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8a55c08d
    • B
      ice: Don't reject odd values of usecs set by user · 840f8ad0
      Brett Creeley 提交于
      Currently if a user sets an odd [tx|rx]-usecs value through ethtool,
      the request is denied because the hardware is set to have an ITR
      granularity of 2us. This caused poor customer experience. Fix this by
      aligning to a register allowed value, which results in rounding down.
      Also, print a once per ring container type message to be clear about
      our intentions.
      
      Also, change the ITR_TO_REG define to be the bitwise and of the ITR
      setting and the ICE_ITR_MASK. This makes the purpose of ITR_TO_REG more
      obvious.
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      840f8ad0
    • D
      nfc: pn544: Fix occasional HW initialization failure · c3331d2f
      Dmitry Osipenko 提交于
      The PN544 driver checks the "enable" polarity during of driver's probe and
      it's doing that by turning ON and OFF NFC with different polarities until
      enabling succeeds. It takes some time for the hardware to power-down, and
      thus, to deassert the IRQ that is raised by turning ON the hardware.
      Since the delay after last power-down of the polarity-checking process is
      missed in the code, the interrupt may trigger immediately after installing
      the IRQ handler (right after the checking is done), which results in IRQ
      handler trying to touch the disabled HW and ends with marking NFC as
      'DEAD' during of the driver's probe:
      
        pn544_hci_i2c 1-002a: NFC: nfc_en polarity : active high
        pn544_hci_i2c 1-002a: NFC: invalid len byte
        shdlc: llc_shdlc_recv_frame: NULL Frame -> link is dead
      
      This patch fixes the occasional NFC initialization failure on Nexus 7
      device.
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3331d2f
    • K
      nvme: Fix uninitialized-variable warning · 15755854
      Keith Busch 提交于
      gcc may detect a false positive on nvme using an unintialized variable
      if setting features fails. Since this is not a fast path, explicitly
      initialize this variable to suppress the warning.
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      15755854
    • J
      s390/qdio: fill SBALEs with absolute addresses · 2db01da8
      Julian Wiedmann 提交于
      sbale->addr holds an absolute address (or for some FCP usage, an opaque
      request ID), and should only be used with proper virt/phys translation.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: NBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      2db01da8
    • J
      s390/qdio: fill SL with absolute addresses · e9091ffd
      Julian Wiedmann 提交于
      As the comment says, sl->sbal holds an absolute address. qeth currently
      solves this through wild casting, while zfcp doesn't care.
      
      Handle this properly in the code that actually builds the SL.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com>
      Reviewed-by: Steffen Maier <maier@linux.ibm.com> [for qdio]
      Reviewed-by: NBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      e9091ffd
    • A
      drm/amdgpu/display: clean up hdcp workqueue handling · 6c62ce80
      Alex Deucher 提交于
      Use the existence of the workqueue itself to determine when to
      enable HDCP features rather than sprinkling asic checks all over
      the code.  Also add a check for the existence of the hdcp
      workqueue in the irq handling on the off chance we get and HPD
      RX interrupt with the CP bit set.  This avoids a crash if
      the driver doesn't support HDCP for a particular asic.
      
      Fixes: 96a3b32e ("drm/amd/display: only enable HDCP for DCN+")
      Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206519Reviewed-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6c62ce80
  6. 19 2月, 2020 13 次提交
新手
引导
客服 返回
顶部