1. 14 Jan, 2019 1 commit
  2. 10 Jan, 2019 2 commits
  3. 04 Jan, 2019 1 commit
    • Qian Cai's avatar
      drivers/base/platform.c: kmemleak ignore a known leak · 967d3010
      Qian Cai authored
      unreferenced object 0xffff808ec6dc5a80 (size 128):
        comm "swapper/0", pid 1, jiffies 4294938063 (age 2560.530s)
        hex dump (first 32 bytes):
          ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b  ........kkkkkkkk
          6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        backtrace:
          [<00000000476dcf8c>] kmem_cache_alloc_trace+0x430/0x500
          [<000000004f708d37>] platform_device_register_full+0xbc/0x1e8
          [<000000006c2a7ec7>] acpi_create_platform_device+0x370/0x450
          [<00000000ef135642>] acpi_default_enumeration+0x34/0x78
          [<000000003bd9a052>] acpi_bus_attach+0x2dc/0x3e0
          [<000000003cf4f7f2>] acpi_bus_attach+0x108/0x3e0
          [<000000003cf4f7f2>] acpi_bus_attach+0x108/0x3e0
          [<000000002968643e>] acpi_bus_scan+0xb0/0x110
          [<0000000010dd0bd7>] acpi_scan_init+0x1a8/0x410
          [<00000000965b3c5a>] acpi_init+0x408/0x49c
          [<00000000ed4b9fe2>] do_one_initcall+0x178/0x7f4
          [<00000000a5ac5a74>] kernel_init_freeable+0x9d4/0xa9c
          [<0000000070ea6c15>] kernel_init+0x18/0x138
          [<00000000fb8fff06>] ret_from_fork+0x10/0x1c
          [<0000000041273a0d>] 0xffffffffffffffff
      
      Then, faddr2line pointed out this line,
      
      /*
       * This memory isn't freed when the device is put,
       * I don't have a nice idea for that though.  Conceptually
       * dma_mask in struct device should not be a pointer.
       * See http://thread.gmane.org/gmane.linux.kernel.pci/9081
       */
      pdev->dev.dma_mask =
      	kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
      
      Since this leak has existed for more than 8 years and it does not
      reference other parts of the memory, let kmemleak ignore it, so users
      don't need to waste time reporting this in the future.
      
      Link: http://lkml.kernel.org/r/20181206160751.36211-1-cai@gmx.usSigned-off-by: default avatarQian Cai <cai@gmx.us>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      967d3010
  4. 02 Jan, 2019 1 commit
  5. 31 Dec, 2018 1 commit
  6. 28 Dec, 2018 2 commits
  7. 26 Dec, 2018 2 commits
  8. 20 Dec, 2018 3 commits
  9. 19 Dec, 2018 7 commits
    • Bartosz Golaszewski's avatar
      regmap: irq: add an option to clear status registers on unmask · c82ea33e
      Bartosz Golaszewski authored
      Some interrupt controllers whose interrupts are acked on read will set
      the status bits for masked interrupts without changing the state of
      the IRQ line.
      
      Some chips have an additional "feature" where if those set bits are
      not cleared before unmasking their respective interrupts, the IRQ
      line will change the state and we'll interpret this as an interrupt
      although it actually fired when it was masked.
      
      Add a new field to the irq chip struct that tells the regmap irq chip
      code to always clear the status registers before actually changing the
      irq mask values.
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c82ea33e
    • Matti Vaittinen's avatar
      regmap: regmap-irq/gpio-max77620: add level-irq support · 1c2928e3
      Matti Vaittinen authored
      Add level active IRQ support to regmap-irq irqchip. Change breaks
      existing regmap-irq type setting. Convert the existing drivers which
      use regmap-irq with trigger type setting (gpio-max77620) to work
      with this new approach. So we do not magically support level-active
      IRQs on gpio-max77620 - but add support to the regmap-irq for chips
      which support them =)
      
      We do not support distinguishing situation where HW supports rising
      and falling edge detection but not both. Separating this would require
      inventing yet another flags for IRQ types.
      Signed-off-by: default avatarMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      1c2928e3
    • Matti Vaittinen's avatar
      regmap: regmap-irq: Remove default irq type setting from core · 84267d1b
      Matti Vaittinen authored
      The common code should not set IRQ type. Read HW defaults to the
      cache at startup instead of forcing type to EDGE_BOTH. If
      default setting is needed this should be done via normal
      mechanisms or by chip specific code if normal mechanisms are not
      suitable for some reason. Common regmap-irq code should not have
      defaults hard-coded but keep the HW/boot defaults untouched.
      Signed-off-by: default avatarMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
      Tested-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      84267d1b
    • Daniel Vetter's avatar
      sysfs: Disable lockdep for driver bind/unbind files · 4f4b3743
      Daniel Vetter authored
      This is the much more correct fix for my earlier attempt at:
      
      https://lkml.org/lkml/2018/12/10/118
      
      Short recap:
      
      - There's not actually a locking issue, it's just lockdep being a bit
        too eager to complain about a possible deadlock.
      
      - Contrary to what I claimed the real problem is recursion on
        kn->count. Greg pointed me at sysfs_break_active_protection(), used
        by the scsi subsystem to allow a sysfs file to unbind itself. That
        would be a real deadlock, which isn't what's happening here. Also,
        breaking the active protection means we'd need to manually handle
        all the lifetime fun.
      
      - With Rafael we discussed the task_work approach, which kinda works,
        but has two downsides: It's a functional change for a lockdep
        annotation issue, and it won't work for the bind file (which needs
        to get the errno from the driver load function back to userspace).
      
      - Greg also asked why this never showed up: To hit this you need to
        unregister a 2nd driver from the unload code of your first driver. I
        guess only gpus do that. The bug has always been there, but only
        with a recent patch series did we add more locks so that lockdep
        built a chain from unbinding the snd-hda driver to the
        acpi_video_unregister call.
      
      Full lockdep splat:
      
      [12301.898799] ============================================
      [12301.898805] WARNING: possible recursive locking detected
      [12301.898811] 4.20.0-rc7+ #84 Not tainted
      [12301.898815] --------------------------------------------
      [12301.898821] bash/5297 is trying to acquire lock:
      [12301.898826] 00000000f61c6093 (kn->count#39){++++}, at: kernfs_remove_by_name_ns+0x3b/0x80
      [12301.898841] but task is already holding lock:
      [12301.898847] 000000005f634021 (kn->count#39){++++}, at: kernfs_fop_write+0xdc/0x190
      [12301.898856] other info that might help us debug this:
      [12301.898862]  Possible unsafe locking scenario:
      [12301.898867]        CPU0
      [12301.898870]        ----
      [12301.898874]   lock(kn->count#39);
      [12301.898879]   lock(kn->count#39);
      [12301.898883] *** DEADLOCK ***
      [12301.898891]  May be due to missing lock nesting notation
      [12301.898899] 5 locks held by bash/5297:
      [12301.898903]  #0: 00000000cd800e54 (sb_writers#4){.+.+}, at: vfs_write+0x17f/0x1b0
      [12301.898915]  #1: 000000000465e7c2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xd3/0x190
      [12301.898925]  #2: 000000005f634021 (kn->count#39){++++}, at: kernfs_fop_write+0xdc/0x190
      [12301.898936]  #3: 00000000414ef7ac (&dev->mutex){....}, at: device_release_driver_internal+0x34/0x240
      [12301.898950]  #4: 000000003218fbdf (register_count_mutex){+.+.}, at: acpi_video_unregister+0xe/0x40
      [12301.898960] stack backtrace:
      [12301.898968] CPU: 1 PID: 5297 Comm: bash Not tainted 4.20.0-rc7+ #84
      [12301.898974] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS 68SCF Ver. F.01 03/11/2011
      [12301.898982] Call Trace:
      [12301.898989]  dump_stack+0x67/0x9b
      [12301.898997]  __lock_acquire+0x6ad/0x1410
      [12301.899003]  ? kernfs_remove_by_name_ns+0x3b/0x80
      [12301.899010]  ? find_held_lock+0x2d/0x90
      [12301.899017]  ? mutex_spin_on_owner+0xe4/0x150
      [12301.899023]  ? find_held_lock+0x2d/0x90
      [12301.899030]  ? lock_acquire+0x90/0x180
      [12301.899036]  lock_acquire+0x90/0x180
      [12301.899042]  ? kernfs_remove_by_name_ns+0x3b/0x80
      [12301.899049]  __kernfs_remove+0x296/0x310
      [12301.899055]  ? kernfs_remove_by_name_ns+0x3b/0x80
      [12301.899060]  ? kernfs_name_hash+0xd/0x80
      [12301.899066]  ? kernfs_find_ns+0x6c/0x100
      [12301.899073]  kernfs_remove_by_name_ns+0x3b/0x80
      [12301.899080]  bus_remove_driver+0x92/0xa0
      [12301.899085]  acpi_video_unregister+0x24/0x40
      [12301.899127]  i915_driver_unload+0x42/0x130 [i915]
      [12301.899160]  i915_pci_remove+0x19/0x30 [i915]
      [12301.899169]  pci_device_remove+0x36/0xb0
      [12301.899176]  device_release_driver_internal+0x185/0x240
      [12301.899183]  unbind_store+0xaf/0x180
      [12301.899189]  kernfs_fop_write+0x104/0x190
      [12301.899195]  __vfs_write+0x31/0x180
      [12301.899203]  ? rcu_read_lock_sched_held+0x6f/0x80
      [12301.899209]  ? rcu_sync_lockdep_assert+0x29/0x50
      [12301.899216]  ? __sb_start_write+0x13c/0x1a0
      [12301.899221]  ? vfs_write+0x17f/0x1b0
      [12301.899227]  vfs_write+0xb9/0x1b0
      [12301.899233]  ksys_write+0x50/0xc0
      [12301.899239]  do_syscall_64+0x4b/0x180
      [12301.899247]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [12301.899253] RIP: 0033:0x7f452ac7f7a4
      [12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
      [12301.899273] RSP: 002b:00007ffceafa6918 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [12301.899282] RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f452ac7f7a4
      [12301.899288] RDX: 000000000000000d RSI: 00005612a1abf7c0 RDI: 0000000000000001
      [12301.899295] RBP: 00005612a1abf7c0 R08: 000000000000000a R09: 00005612a1c46730
      [12301.899301] R10: 000000000000000a R11: 0000000000000246 R12: 000000000000000d
      [12301.899308] R13: 0000000000000001 R14: 00007f452af4a740 R15: 000000000000000d
      
      Looking around I've noticed that usb and i2c already handle similar
      recursion problems, where a sysfs file can unbind the same type of
      sysfs somewhere else in the hierarchy. Relevant commits are:
      
      commit 356c05d5
      Author: Alan Stern <stern@rowland.harvard.edu>
      Date:   Mon May 14 13:30:03 2012 -0400
      
          sysfs: get rid of some lockdep false positives
      
      commit e9b526fe
      Author: Alexander Sverdlin <alexander.sverdlin@nsn.com>
      Date:   Fri May 17 14:56:35 2013 +0200
      
          i2c: suppress lockdep warning on delete_device
      
      Implement the same trick for driver bind/unbind.
      
      v2: Put the macro into bus.c (Greg).
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Ramalingam C <ramalingam.c@intel.com>
      Cc: Arend van Spriel <aspriel@gmail.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Bartosz Golaszewski <brgl@bgdev.pl>
      Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
      Cc: Vivek Gautam <vivek.gautam@codeaurora.org>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f4b3743
    • Yangtao Li's avatar
      PM / Domains: remove define_genpd_open_function() and define_genpd_debugfs_fops() · d32dcc6c
      Yangtao Li authored
      We already have the DEFINE_SHOW_ATTRIBUTE, There is no need to define
      such a macro, so remove define_genpd_open_function and
      define_genpd_debugfs_fops.
      
      Convert them to DEFINE_SHOW_ATTRIBUTE.
      Signed-off-by: default avatarYangtao Li <tiny.windzz@gmail.com>
      Acked-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d32dcc6c
    • Vincent Guittot's avatar
      PM-runtime: Switch autosuspend over to using hrtimers · 8234f673
      Vincent Guittot authored
      PM-runtime uses the timer infrastructure for autosuspend. This implies
      that the minimum time before autosuspending a device is in the range
      of 1 tick included to 2 ticks excluded
       -On arm64 this means between 4ms and 8ms with default jiffies
        configuration
       -And on arm, it is between 10ms and 20ms
      
      These values are quite high for embedded systems which sometimes want
      the duration to be in the range of 1 ms.
      
      It is possible to switch autosuspend over to using hrtimers to get
      finer granularity for short durations and take advantage of slack to
      retain some margins and get long timeouts with minimum wakeups.
      
      On an arm64 platform that uses 1ms for autosuspending timeout of its
      GPU, idle power is reduced by 10% with hrtimer.
      
      The latency impact on arm64 hikey octo cores is:
       - mark_last_busy: from 1.11 us to 1.25 us
       - rpm_suspend: from 15.54 us to 15.38 us
      [Only the code path of rpm_suspend() that starts hrtimer has been
      measured.]
      
      arm64 image (arm64 default defconfig) decreases by around 3KB
      with following details:
      
      $ size vmlinux-timer
         text	   data	    bss	    dec	    hex	filename
      12034646	6869268	 386840	19290754	1265a82	vmlinux
      
      $ size vmlinux-hrtimer
         text	   data	    bss	    dec	    hex	filename
      12030550	6870164	 387032	19287746	1264ec2	vmlinux
      
      The latency impact on arm 32bits snowball dual cores is :
       - mark_last_busy: from 0.31 us usec to 0.77 us
       - rpm_suspend: from 6.83 us to 6.67 usec
      
      The increase of the image for snowball platform that I used for
      testing performance impact, is neglictable (244B).
      
      $ size vmlinux-timer
         text	   data	    bss	    dec	    hex	filename
      7157961	2119580	 264120	9541661	 91981d	build-ux500/vmlinux
      
      size vmlinux-hrtimer
         text	   data	    bss	    dec	    hex	filename
      7157773	2119884	 264248	9541905	 919911	vmlinux-hrtimer
      
      And arm 32bits image (multi_v7_defconfig) increases by around 1.7KB
      with following details:
      
      $ size vmlinux-timer
         text	   data	    bss	    dec	    hex	filename
      13304443	6803420	 402768	20510631	138f7a7	vmlinux
      
      $ size vmlinux-hrtimer
         text	   data	    bss	    dec	    hex	filename
      13304299	6805276	 402768	20512343	138fe57	vmlinux
      Signed-off-by: default avatarVincent Guittot <vincent.guittot@linaro.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8234f673
    • Rafael J. Wysocki's avatar
      driver core: Add missing dev->bus->need_parent_lock checks · e121a833
      Rafael J. Wysocki authored
      __device_release_driver() has to check dev->bus->need_parent_lock
      before dropping the parent lock and acquiring it again as it may
      attempt to drop a lock that hasn't been acquired or lock a device
      that shouldn't be locked and create a lock imbalance.
      
      Fixes: 8c97a46a (driver core: hold dev's parent lock when needed)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e121a833
  10. 18 Dec, 2018 1 commit
  11. 17 Dec, 2018 2 commits
  12. 14 Dec, 2018 4 commits
    • Viresh Kumar's avatar
      PM / Domains: Propagate performance state updates · 18edf49c
      Viresh Kumar authored
      Currently a genpd only handles the performance state requirements from
      the devices under its control. This commit extends that to also handle
      the performance state requirement(s) put on the master genpd by its
      sub-domains. There is a separate value required for each master that
      the genpd has and so a new field is added to the struct gpd_link
      (link->performance_state), which represents the link between a genpd and
      its master. The struct gpd_link also got another field
      prev_performance_state, which is used by genpd core as a temporary
      variable during transitions.
      
      On a call to dev_pm_genpd_set_performance_state(), the genpd core first
      updates the performance state of the masters of the device's genpd and
      then updates the performance state of the genpd. The masters do the same
      and propagate performance state updates to their masters before updating
      their own. The performance state transition from genpd to its master is
      done with the help of dev_pm_opp_xlate_performance_state(), which looks
      at the OPP tables of both the domains to translate the state.
      Tested-by: default avatarRajendra Nayak <rnayak@codeaurora.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      18edf49c
    • Viresh Kumar's avatar
      PM / Domains: Factorize dev_pm_genpd_set_performance_state() · cd50c6d3
      Viresh Kumar authored
      Separate out _genpd_set_performance_state() and
      _genpd_reeval_performance_state() from
      dev_pm_genpd_set_performance_state() to handle performance state update
      related stuff. This will be used by a later commit.
      Tested-by: default avatarRajendra Nayak <rnayak@codeaurora.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      cd50c6d3
    • Viresh Kumar's avatar
      PM / Domains: Save OPP table pointer in genpd · 1067ae3e
      Viresh Kumar authored
      dev_pm_genpd_set_performance_state() will be required to call
      dev_pm_opp_xlate_performance_state() going forward to translate from
      performance state of a sub-domain to performance state of its master.
      And dev_pm_opp_xlate_performance_state() needs pointers to the OPP
      tables of both genpd and its master.
      
      Lets fetch and save them while the OPP tables are added. Fetching the
      OPP tables should never fail as we just added the OPP tables and so add
      a WARN_ON() for such a bug instead of full error paths.
      Tested-by: default avatarRajendra Nayak <rnayak@codeaurora.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      1067ae3e
    • Ulf Hansson's avatar
      PM / Domains: Make genpd performance states orthogonal to the idlestates · 68de2fe5
      Ulf Hansson authored
      It's quite questionable whether genpd internally should care about if the
      corresponding PM domain for a device is powered on, as to allow setting a
      new performance state for it. The assumptions creates an unnecessary
      limitation at this point, for both consumers and providers, but more
      importantly it also makes the code more complicated.
      
      Therefore, let's simplify the code to allow setting a performance state, by
      invoking the ->set_performance_state() callback, no matter whether the PM
      domain is powered on or off.
      
      Do note, this change means genpd providers needs to restore the performance
      state themselves during power on, via the ->power_on() callback. Moreover,
      they may also need to check that the PM domain is powered on, from their
      ->set_performance_state() callback, before deciding to update the state.
      Tested-by: default avatarRajendra Nayak <rnayak@codeaurora.org>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      68de2fe5
  13. 13 Dec, 2018 4 commits
    • Robin Murphy's avatar
      ACPI / scan: Refactor _CCA enforcement · e5361ca2
      Robin Murphy authored
      Rather than checking the DMA attribute at each callsite, just pass it
      through for acpi_dma_configure() to handle directly. That can then deal
      with the relatively exceptional DEV_DMA_NOT_SUPPORTED case by explicitly
      installing dummy DMA ops instead of just skipping setup entirely. This
      will then free up the dev->dma_ops == NULL case for some valuable
      fastpath optimisations.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Tested-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Tested-by: default avatarTony Luck <tony.luck@intel.com>
      e5361ca2
    • Christoph Hellwig's avatar
      dma-mapping: move dma_get_required_mask to kernel/dma · 05887cb6
      Christoph Hellwig authored
      dma_get_required_mask should really be with the rest of the DMA mapping
      implementation instead of in drivers/base as a lone outlier.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Tested-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Tested-by: default avatarTony Luck <tony.luck@intel.com>
      05887cb6
    • Bartosz Golaszewski's avatar
      regmap: irq: handle HW using separate rising/falling edge interrupts · bc998a73
      Bartosz Golaszewski authored
      Some interrupt controllers use separate bits for controlling rising
      and falling edge interrupts in the mask register i.e. they have one
      interrupt for rising edge and one for falling.
      
      We already handle the case where we have a single interrupt in the
      mask register and a separate type configuration register.
      
      Add a new switch to regmap_irq_chip which tells the framework to use
      the mask_base address for configuring the edge of the interrupts that
      define type_falling/rising_mask values.
      
      For such interrupts we never update the type_base bits. For interrupts
      that don't define type masks or their regmap irq chip doesn't set the
      type_in_mask to true everything stays the same.
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      bc998a73
    • Miquel Raynal's avatar
      platform-msi: Free descriptors in platform_msi_domain_free() · 81b1e6e6
      Miquel Raynal authored
      Since the addition of platform MSI support, there were two helpers
      supposed to allocate/free IRQs for a device:
      
          platform_msi_domain_alloc_irqs()
          platform_msi_domain_free_irqs()
      
      In these helpers, IRQ descriptors are allocated in the "alloc" routine
      while they are freed in the "free" one.
      
      Later, two other helpers have been added to handle IRQ domains on top
      of MSI domains:
      
          platform_msi_domain_alloc()
          platform_msi_domain_free()
      
      Seen from the outside, the logic is pretty close with the former
      helpers and people used it with the same logic as before: a
      platform_msi_domain_alloc() call should be balanced with a
      platform_msi_domain_free() call. While this is probably what was
      intended to do, the platform_msi_domain_free() does not remove/free
      the IRQ descriptor(s) created/inserted in
      platform_msi_domain_alloc().
      
      One effect of such situation is that removing a module that requested
      an IRQ will let one orphaned IRQ descriptor (with an allocated MSI
      entry) in the device descriptors list. Next time the module will be
      inserted back, one will observe that the allocation will happen twice
      in the MSI domain, one time for the remaining descriptor, one time for
      the new one. It also has the side effect to quickly overshoot the
      maximum number of allocated MSI and then prevent any module requesting
      an interrupt in the same domain to be inserted anymore.
      
      This situation has been met with loops of insertion/removal of the
      mvpp2.ko module (requesting 15 MSIs each time).
      
      Fixes: 552c494a ("platform-msi: Allow creation of a MSI-based stacked irq domain")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      81b1e6e6
  14. 11 Dec, 2018 1 commit
  15. 10 Dec, 2018 1 commit
  16. 06 Dec, 2018 5 commits
  17. 27 Nov, 2018 1 commit
  18. 26 Nov, 2018 1 commit