1. 11 3月, 2022 1 次提交
    • D
      PM: core: keep irq flags in device_pm_check_callbacks() · 524bb1da
      Dmitry Baryshkov 提交于
      The function device_pm_check_callbacks() can be called under the spin
      lock (in the reported case it happens from genpd_add_device() ->
      dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.
      
      However this function uncoditionally uses spin_lock_irq() /
      spin_unlock_irq(), thus not preserving the CPU flags. Use the
      irqsave/irqrestore instead.
      
      The backtrace for the reference:
      [    2.752010] ------------[ cut here ]------------
      [    2.756769] raw_local_irq_restore() called with IRQs enabled
      [    2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50
      [    2.772338] Modules linked in:
      [    2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S                5.17.0-rc6-00384-ge330d0d82eff-dirty #684
      [    2.781384] Freeing initrd memory: 46024K
      [    2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [    2.785841] pc : warn_bogus_irq_restore+0x34/0x50
      [    2.785844] lr : warn_bogus_irq_restore+0x34/0x50
      [    2.785846] sp : ffff80000805b7d0
      [    2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002
      [    2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800
      [    2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00
      [    2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff
      [    2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7
      [    2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8
      [    2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0
      [    2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0
      [    2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
      [    2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000
      [    2.889774] Call trace:
      [    2.892290]  warn_bogus_irq_restore+0x34/0x50
      [    2.896770]  _raw_spin_unlock_irqrestore+0x94/0xa0
      [    2.901690]  genpd_unlock_spin+0x20/0x30
      [    2.905724]  genpd_add_device+0x100/0x2d0
      [    2.909850]  __genpd_dev_pm_attach+0xa8/0x23c
      [    2.914329]  genpd_dev_pm_attach_by_id+0xc4/0x190
      [    2.919167]  genpd_dev_pm_attach_by_name+0x3c/0xd0
      [    2.924086]  dev_pm_domain_attach_by_name+0x24/0x30
      [    2.929102]  psci_dt_attach_cpu+0x24/0x90
      [    2.933230]  psci_cpuidle_probe+0x2d4/0x46c
      [    2.937534]  platform_probe+0x68/0xe0
      [    2.941304]  really_probe.part.0+0x9c/0x2fc
      [    2.945605]  __driver_probe_device+0x98/0x144
      [    2.950085]  driver_probe_device+0x44/0x15c
      [    2.954385]  __device_attach_driver+0xb8/0x120
      [    2.958950]  bus_for_each_drv+0x78/0xd0
      [    2.962896]  __device_attach+0xd8/0x180
      [    2.966843]  device_initial_probe+0x14/0x20
      [    2.971144]  bus_probe_device+0x9c/0xa4
      [    2.975092]  device_add+0x380/0x88c
      [    2.978679]  platform_device_add+0x114/0x234
      [    2.983067]  platform_device_register_full+0x100/0x190
      [    2.988344]  psci_idle_init+0x6c/0xb0
      [    2.992113]  do_one_initcall+0x74/0x3a0
      [    2.996060]  kernel_init_freeable+0x2fc/0x384
      [    3.000543]  kernel_init+0x28/0x130
      [    3.004132]  ret_from_fork+0x10/0x20
      [    3.007817] irq event stamp: 319826
      [    3.011404] hardirqs last  enabled at (319825): [<ffffd40e7eda0268>] __up_console_sem+0x78/0x84
      [    3.020332] hardirqs last disabled at (319826): [<ffffd40e7fd6d9d8>] el1_dbg+0x24/0x8c
      [    3.028458] softirqs last  enabled at (318312): [<ffffd40e7ec90410>] _stext+0x410/0x588
      [    3.036678] softirqs last disabled at (318299): [<ffffd40e7ed1bf68>] __irq_exit_rcu+0x158/0x174
      [    3.045607] ---[ end trace 0000000000000000 ]---
      Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      524bb1da
  2. 05 3月, 2022 1 次提交
  3. 22 2月, 2022 1 次提交
    • M
      driver core: Free DMA range map when device is released · d8f7a548
      Mårten Lindahl 提交于
      When unbinding/binding a driver with DMA mapped memory, the DMA map is
      not freed before the driver is reloaded. This leads to a memory leak
      when the DMA map is overwritten when reprobing the driver.
      
      This can be reproduced with a platform driver having a dma-range:
      
      dummy {
      	...
      	#address-cells = <0x2>;
      	#size-cells = <0x2>;
      	ranges;
      	dma-ranges = <...>;
      	...
      };
      
      and then unbinding/binding it:
      
      ~# echo soc:dummy >/sys/bus/platform/drivers/<driver>/unbind
      
      DMA map object 0xffffff800b0ae540 still being held by &pdev->dev
      
      ~# echo soc:dummy >/sys/bus/platform/drivers/<driver>/bind
      ~# echo scan > /sys/kernel/debug/kmemleak
      ~# cat /sys/kernel/debug/kmemleak
      unreferenced object 0xffffff800b0ae540 (size 64):
        comm "sh", pid 833, jiffies 4295174550 (age 2535.352s)
        hex dump (first 32 bytes):
          00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 80 00 00 00 00 00 00 00 80 00 00 00 00  ................
        backtrace:
          [<ffffffefd1694708>] create_object.isra.0+0x108/0x344
          [<ffffffefd1d1a850>] kmemleak_alloc+0x8c/0xd0
          [<ffffffefd167e2d0>] __kmalloc+0x440/0x6f0
          [<ffffffefd1a960a4>] of_dma_get_range+0x124/0x220
          [<ffffffefd1a8ce90>] of_dma_configure_id+0x40/0x2d0
          [<ffffffefd198b68c>] platform_dma_configure+0x5c/0xa4
          [<ffffffefd198846c>] really_probe+0x8c/0x514
          [<ffffffefd1988990>] __driver_probe_device+0x9c/0x19c
          [<ffffffefd1988cd8>] device_driver_attach+0x54/0xbc
          [<ffffffefd1986634>] bind_store+0xc4/0x120
          [<ffffffefd19856e0>] drv_attr_store+0x30/0x44
          [<ffffffefd173c9b0>] sysfs_kf_write+0x50/0x60
          [<ffffffefd173c1c4>] kernfs_fop_write_iter+0x124/0x1b4
          [<ffffffefd16a013c>] new_sync_write+0xdc/0x160
          [<ffffffefd16a256c>] vfs_write+0x23c/0x2a0
          [<ffffffefd16a2758>] ksys_write+0x64/0xec
      
      To prevent this we should free the dma_range_map when the device is
      released.
      
      Fixes: e0d07278 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
      Cc: stable <stable@vger.kernel.org>
      Suggested-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NMårten Lindahl <marten.lindahl@axis.com>
      Link: https://lore.kernel.org/r/20220216094128.4025861-1-marten.lindahl@axis.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8f7a548
  4. 17 2月, 2022 1 次提交
    • P
      regmap-irq: Update interrupt clear register for proper reset · d04ad245
      Prasad Kumpatla 提交于
      With the existing logic where clear_ack is true (HW doesn’t support
      auto clear for ICR), interrupt clear register reset is not handled
      properly. Due to this only the first interrupts get processed properly
      and further interrupts are blocked due to not resetting interrupt
      clear register.
      
      Example for issue case where Invert_ack is false and clear_ack is true:
      
          Say Default ISR=0x00 & ICR=0x00 and ISR is triggered with 2
          interrupts making ISR = 0x11.
      
          Step 1: Say ISR is set 0x11 (store status_buff = ISR). ISR needs to
                  be cleared with the help of ICR once the Interrupt is processed.
      
          Step 2: Write ICR = 0x11 (status_buff), this will clear the ISR to 0x00.
      
          Step 3: Issue - In the existing code, ICR is written with ICR =
                  ~(status_buff) i.e ICR = 0xEE -> This will block all the interrupts
                  from raising except for interrupts 0 and 4. So expectation here is to
                  reset ICR, which will unblock all the interrupts.
      
                  if (chip->clear_ack) {
                       if (chip->ack_invert && !ret)
                        ........
                       else if (!ret)
                           ret = regmap_write(map, reg,
                                  ~data->status_buf[i]);
      
      So writing 0 and 0xff (when ack_invert is true) should have no effect, other
      than clearing the ACKs just set.
      
      Fixes: 3a6f0fb7 ("regmap: irq: Add support to clear ack registers")
      Signed-off-by: NPrasad Kumpatla <quic_pkumpatl@quicinc.com>
      Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Link: https://lore.kernel.org/r/20220217085007.30218-1-quic_pkumpatl@quicinc.comSigned-off-by: NMark Brown <broonie@kernel.org>
      d04ad245
  5. 08 2月, 2022 1 次提交
    • R
      PM: s2idle: ACPI: Fix wakeup interrupts handling · cb1f65c1
      Rafael J. Wysocki 提交于
      After commit e3728b50 ("ACPI: PM: s2idle: Avoid possible race
      related to the EC GPE") wakeup interrupts occurring immediately after
      the one discarded by acpi_s2idle_wake() may be missed.  Moreover, if
      the SCI triggers again immediately after the rearming in
      acpi_s2idle_wake(), that wakeup may be missed too.
      
      The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup()
      when pm_wakeup_irq is 0, but that's not the case any more after the
      interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is
      cleared by the pm_wakeup_clear() call in s2idle_loop().  However,
      there may be wakeup interrupts occurring in that time frame and if
      that happens, they will be missed.
      
      To address that issue first move the clearing of pm_wakeup_irq to
      the point at which it is known that the interrupt causing
      acpi_s2idle_wake() to tun will be discarded, before rearming the SCI
      for wakeup.  Moreover, because that only reduces the size of the
      time window in which the issue may manifest itself, allow
      pm_system_irq_wakeup() to register two second wakeup interrupts in
      a row and, when discarding the first one, replace it with the second
      one.  [Of course, this assumes that only one wakeup interrupt can be
      discarded in one go, but currently that is the case and I am not
      aware of any plans to change that.]
      
      Fixes: e3728b50 ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE")
      Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cb1f65c1
  6. 22 1月, 2022 1 次提交
    • X
      firmware_loader: move firmware sysctl to its own files · 6aad36d4
      Xiaoming Ni 提交于
      Patch series "sysctl: 3rd set of kernel/sysctl cleanups", v2.
      
      This is the third set of patches to help address cleaning the kitchen
      seink in kernel/sysctl.c and to move sysctls away to where they are
      actually implemented / used.
      
      This patch (of 8):
      
      kernel/sysctl.c is a kitchen sink where everyone leaves their dirty
      dishes, this makes it very difficult to maintain.
      
      To help with this maintenance let's start by moving sysctls to places
      where they actually belong.  The proc sysctl maintainers do not want to
      know what sysctl knobs you wish to add for your own piece of code, we
      just care about the core logic.
      
      So move the firmware configuration sysctl table to the only place where
      it is used, and make it clear that if sysctls are disabled this is not
      used.
      
      [akpm@linux-foundation.org: export register_firmware_config_sysctl and unregister_firmware_config_sysctl to modules]
      [akpm@linux-foundation.org: use EXPORT_SYMBOL_NS_GPL instead]
      [sfr@canb.auug.org.au: fix that so it compiles]
        Link: https://lkml.kernel.org/r/20211201160626.401d828d@canb.auug.org.au
      [mcgrof@kernel.org: major commit log update to justify the move]
      
      Link: https://lkml.kernel.org/r/20211124231435.1445213-1-mcgrof@kernel.org
      Link: https://lkml.kernel.org/r/20211124231435.1445213-2-mcgrof@kernel.orgSigned-off-by: NXiaoming Ni <nixiaoming@huawei.com>
      Signed-off-by: NLuis Chamberlain <mcgrof@kernel.org>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Iurii Zaikin <yzaikin@google.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Stephen Kitt <steve@sk2.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: John Ogness <john.ogness@linutronix.de>
      Cc: Douglas Gilbert <dgilbert@interlog.com>
      Cc: James E.J. Bottomley <jejb@linux.ibm.com>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Lukas Middendorf <kernel@tuxforce.de>
      Cc: Antti Palosaari <crope@iki.fi>
      Cc: Amir Goldstein <amir73il@gmail.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Benjamin LaHaise <bcrl@kvack.org>
      Cc: Clemens Ladisch <clemens@ladisch.de>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Joseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Julia Lawall <julia.lawall@inria.fr>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Phillip Potter <phil@philpotter.co.uk>
      Cc: Qing Wang <wangqing@vivo.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Sebastian Reichel <sre@kernel.org>
      Cc: Suren Baghdasaryan <surenb@google.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6aad36d4
  7. 20 1月, 2022 3 次提交
    • K
      mm: percpu: add generic pcpu_populate_pte() function · 20c03576
      Kefeng Wang 提交于
      With NEED_PER_CPU_PAGE_FIRST_CHUNK enabled, we need a function to
      populate pte, this patch adds a generic pcpu populate pte function,
      pcpu_populate_pte(), which is marked __weak and used on most
      architectures, but it is overridden on x86, which has its own
      implementation.
      
      Link: https://lkml.kernel.org/r/20211216112359.103822-5-wangkefeng.wang@huawei.comSigned-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: Dennis Zhou <dennis@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20c03576
    • K
      mm: percpu: add generic pcpu_fc_alloc/free funciton · 23f91716
      Kefeng Wang 提交于
      With the previous patch, we could add a generic pcpu first chunk
      allocate and free function to cleanup the duplicated definations on each
      architecture.
      
      Link: https://lkml.kernel.org/r/20211216112359.103822-4-wangkefeng.wang@huawei.comSigned-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Dennis Zhou <dennis@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      23f91716
    • K
      mm: percpu: add pcpu_fc_cpu_to_node_fn_t typedef · 1ca3fb3a
      Kefeng Wang 提交于
      Add pcpu_fc_cpu_to_node_fn_t and pass it into pcpu_fc_alloc_fn_t, pcpu
      first chunk allocation will call it to alloc memblock on the
      corresponding node by it, this is prepare for the next patch.
      
      Link: https://lkml.kernel.org/r/20211216112359.103822-3-wangkefeng.wang@huawei.comSigned-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: Dennis Zhou <dennis@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1ca3fb3a
  8. 17 1月, 2022 1 次提交
  9. 08 1月, 2022 3 次提交
    • M
      kbuild: do not quote string values in include/config/auto.conf · 129ab0d2
      Masahiro Yamada 提交于
      The previous commit fixed up all shell scripts to not include
      include/config/auto.conf.
      
      Now that include/config/auto.conf is only included by Makefiles,
      we can change it into a more Make-friendly form.
      
      Previously, Kconfig output string values enclosed with double-quotes
      (both in the .config and include/config/auto.conf):
      
          CONFIG_X="foo bar"
      
      Unlike shell, Make handles double-quotes (and single-quotes as well)
      verbatim. We must rip them off when used.
      
      There are some patterns:
      
        [1] $(patsubst "%",%,$(CONFIG_X))
        [2] $(CONFIG_X:"%"=%)
        [3] $(subst ",,$(CONFIG_X))
        [4] $(shell echo $(CONFIG_X))
      
      These are not only ugly, but also fragile.
      
      [1] and [2] do not work if the value contains spaces, like
         CONFIG_X=" foo bar "
      
      [3] does not work correctly if the value contains double-quotes like
         CONFIG_X="foo\"bar"
      
      [4] seems to work better, but has a cost of forking a process.
      
      Anyway, quoted strings were always PITA for our Makefiles.
      
      This commit changes Kconfig to stop quoting in include/config/auto.conf.
      
      These are the string type symbols referenced in Makefiles or scripts:
      
          ACPI_CUSTOM_DSDT_FILE
          ARC_BUILTIN_DTB_NAME
          ARC_TUNE_MCPU
          BUILTIN_DTB_SOURCE
          CC_IMPLICIT_FALLTHROUGH
          CC_VERSION_TEXT
          CFG80211_EXTRA_REGDB_KEYDIR
          EXTRA_FIRMWARE
          EXTRA_FIRMWARE_DIR
          EXTRA_TARGETS
          H8300_BUILTIN_DTB
          INITRAMFS_SOURCE
          LOCALVERSION
          MODULE_SIG_HASH
          MODULE_SIG_KEY
          NDS32_BUILTIN_DTB
          NIOS2_DTB_SOURCE
          OPENRISC_BUILTIN_DTB
          SOC_CANAAN_K210_DTB_SOURCE
          SYSTEM_BLACKLIST_HASH_LIST
          SYSTEM_REVOCATION_KEYS
          SYSTEM_TRUSTED_KEYS
          TARGET_CPU
          UNUSED_KSYMS_WHITELIST
          XILINX_MICROBLAZE0_FAMILY
          XILINX_MICROBLAZE0_HW_VER
          XTENSA_VARIANT_NAME
      
      I checked them one by one, and fixed up the code where necessary.
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      129ab0d2
    • M
    • F
      regmap: Call regmap_debugfs_exit() prior to _init() · 530792ef
      Fabio Estevam 提交于
      Since commit cffa4b21 ("regmap: debugfs: Fix a memory leak when
      calling regmap_attach_dev"), the following debugfs error is seen
      on i.MX boards:
      
      debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present!
      
      In the attempt to fix the memory leak, the above commit added a NULL check
      for map->debugfs_name. For the first debufs entry, map->debugfs_name is NULL
      and then the new name is allocated via kasprintf().
      
      For the second debugfs entry, map->debugfs_name() is no longer NULL, so
      it will keep using the old entry name and the duplicate name error is seen.
      
      Quoting Mark Brown:
      
      "That means that if the device gets freed we'll end up with the old debugfs
      file hanging around pointing at nothing.
      ...
      To be more explicit this means we need a call to regmap_debugfs_exit()
      which will clean up all the existing debugfs stuff before we loose
      references to it."
      
      Call regmap_debugfs_exit() prior to regmap_debugfs_init() to fix
      the problem.
      
      Tested on i.MX6Q and i.MX6SX boards.
      
      Fixes: cffa4b21 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev")
      Suggested-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NFabio Estevam <festevam@denx.de>
      Link: https://lore.kernel.org/r/20220107163307.335404-1-festevam@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
      530792ef
  10. 06 1月, 2022 2 次提交
  11. 04 1月, 2022 1 次提交
  12. 30 12月, 2021 1 次提交
  13. 29 12月, 2021 1 次提交
  14. 28 12月, 2021 1 次提交
  15. 27 12月, 2021 1 次提交
  16. 23 12月, 2021 2 次提交
  17. 22 12月, 2021 1 次提交
  18. 21 12月, 2021 1 次提交
  19. 18 12月, 2021 6 次提交
  20. 17 12月, 2021 10 次提交