1. 08 12月, 2021 1 次提交
    • M
      clk: Don't parent clks until the parent is fully registered · 54baf56e
      Mike Tipton 提交于
      Before commit fc0c209c ("clk: Allow parents to be specified without
      string names") child clks couldn't find their parent until the parent
      clk was added to a list in __clk_core_init(). After that commit, child
      clks can reference their parent clks directly via a clk_hw pointer, or
      they can lookup that clk_hw pointer via DT if the parent clk is
      registered with an OF clk provider.
      
      The common clk framework treats hw->core being non-NULL as "the clk is
      registered" per the logic within clk_core_fill_parent_index():
      
      	parent = entry->hw->core;
      	/*
      	 * We have a direct reference but it isn't registered yet?
      	 * Orphan it and let clk_reparent() update the orphan status
      	 * when the parent is registered.
      	 */
      	if (!parent)
      
      Therefore we need to be extra careful to not set hw->core until the clk
      is fully registered with the clk framework. Otherwise we can get into a
      situation where a child finds a parent clk and we move the child clk off
      the orphan list when the parent isn't actually registered, wrecking our
      enable accounting and breaking critical clks.
      
      Consider the following scenario:
      
        CPU0                                     CPU1
        ----                                     ----
        struct clk_hw clkBad;
        struct clk_hw clkA;
      
        clkA.init.parent_hws = { &clkBad };
      
        clk_hw_register(&clkA)                   clk_hw_register(&clkBad)
         ...                                      __clk_register()
      					     hw->core = core
      					     ...
         __clk_register()
          __clk_core_init()
           clk_prepare_lock()
           __clk_init_parent()
            clk_core_get_parent_by_index()
             clk_core_fill_parent_index()
              if (entry->hw) {
      	 parent = entry->hw->core;
      
      At this point, 'parent' points to clkBad even though clkBad hasn't been
      fully registered yet. Ouch! A similar problem can happen if a clk
      controller registers orphan clks that are referenced in the DT node of
      another clk controller.
      
      Let's fix all this by only setting the hw->core pointer underneath the
      clk prepare lock in __clk_core_init(). This way we know that
      clk_core_fill_parent_index() can't see hw->core be non-NULL until the
      clk is fully registered.
      
      Fixes: fc0c209c ("clk: Allow parents to be specified without string names")
      Signed-off-by: NMike Tipton <quic_mdtipton@quicinc.com>
      Link: https://lore.kernel.org/r/20211109043438.4639-1-quic_mdtipton@quicinc.com
      [sboyd@kernel.org: Reword commit text, update comment]
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      54baf56e
  2. 27 10月, 2021 1 次提交
  3. 11 5月, 2021 1 次提交
  4. 03 4月, 2021 2 次提交
    • L
      clk: fix invalid usage of list cursor in unregister · 70454655
      Lukasz Bartosik 提交于
      Fix invalid usage of a list_for_each_entry cursor in
      clk_notifier_unregister(). When list is empty or if the list
      is completely traversed (without breaking from the loop on one
      of the entries) then the list cursor does not point to a valid
      entry and therefore should not be used. The patch fixes a logical
      bug that hasn't been seen in pratice however it is analogus
      to the bug fixed in clk_notifier_register().
      
      The issue was dicovered when running 5.12-rc1 kernel on x86_64
      with KASAN enabled:
      BUG: KASAN: global-out-of-bounds in clk_notifier_register+0xab/0x230
      Read of size 8 at addr ffffffffa0d10588 by task swapper/0/1
      
      CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1 #1
      Hardware name: Google Caroline/Caroline,
      BIOS Google_Caroline.7820.430.0 07/20/2018
      Call Trace:
       dump_stack+0xee/0x15c
       print_address_description+0x1e/0x2dc
       kasan_report+0x188/0x1ce
       ? clk_notifier_register+0xab/0x230
       ? clk_prepare_lock+0x15/0x7b
       ? clk_notifier_register+0xab/0x230
       clk_notifier_register+0xab/0x230
       dw8250_probe+0xc01/0x10d4
       ...
       Memory state around the buggy address:
        ffffffffa0d10480: 00 00 00 00 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00
        ffffffffa0d10500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
       >ffffffffa0d10580: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
                                ^
        ffffffffa0d10600: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
        ffffffffa0d10680: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00
        ==================================================================
      
      Fixes: b2476490 ("clk: introduce the common clock framework")
      Reported-by: NLukasz Majczak <lma@semihalf.com>
      Signed-off-by: NLukasz Bartosik <lb@semihalf.com>
      Link: https://lore.kernel.org/r/20210401225149.18826-2-lb@semihalf.comSigned-off-by: NStephen Boyd <sboyd@kernel.org>
      70454655
    • L
      clk: fix invalid usage of list cursor in register · 8d3c0c01
      Lukasz Bartosik 提交于
      Fix invalid usage of a list_for_each_entry cursor in
      clk_notifier_register(). When list is empty or if the list
      is completely traversed (without breaking from the loop on one
      of the entries) then the list cursor does not point to a valid
      entry and therefore should not be used.
      
      The issue was dicovered when running 5.12-rc1 kernel on x86_64
      with KASAN enabled:
      BUG: KASAN: global-out-of-bounds in clk_notifier_register+0xab/0x230
      Read of size 8 at addr ffffffffa0d10588 by task swapper/0/1
      
      CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1 #1
      Hardware name: Google Caroline/Caroline,
      BIOS Google_Caroline.7820.430.0 07/20/2018
      Call Trace:
       dump_stack+0xee/0x15c
       print_address_description+0x1e/0x2dc
       kasan_report+0x188/0x1ce
       ? clk_notifier_register+0xab/0x230
       ? clk_prepare_lock+0x15/0x7b
       ? clk_notifier_register+0xab/0x230
       clk_notifier_register+0xab/0x230
       dw8250_probe+0xc01/0x10d4
      ...
      Memory state around the buggy address:
       ffffffffa0d10480: 00 00 00 00 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00
       ffffffffa0d10500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
      >ffffffffa0d10580: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
                            ^
       ffffffffa0d10600: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
       ffffffffa0d10680: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00
       ==================================================================
      
      Fixes: b2476490 ("clk: introduce the common clock framework")
      Reported-by: NLukasz Majczak <lma@semihalf.com>
      Signed-off-by: NLukasz Bartosik <lb@semihalf.com>
      Link: https://lore.kernel.org/r/20210401225149.18826-1-lb@semihalf.comSigned-off-by: NStephen Boyd <sboyd@kernel.org>
      8d3c0c01
  5. 27 3月, 2021 1 次提交
  6. 23 3月, 2021 1 次提交
  7. 14 3月, 2021 1 次提交
  8. 09 2月, 2021 1 次提交
  9. 28 1月, 2021 1 次提交
    • N
      PM: clk: make PM clock layer compatible with clocks that must sleep · 0bfa0820
      Nicolas Pitre 提交于
      The clock API splits its interface into sleepable ant atomic contexts:
      
       - clk_prepare/clk_unprepare for stuff that might sleep
      
       - clk_enable_clk_disable for anything that may be done in atomic context
      
      The code handling runtime PM for clocks only calls clk_disable() on
      suspend requests, and clk_enable on resume requests. This means that
      runtime PM with clock providers that only have the prepare/unprepare
      methods implemented is basically useless.
      
      Many clock implementations can't accommodate atomic contexts. This is
      often the case when communication with the clock happens through another
      subsystem like I2C or SCMI.
      
      Let's make the clock PM code useful with such clocks by safely invoking
      clk_prepare/clk_unprepare upon resume/suspend requests. Of course, when
      such clocks are registered with the PM layer then pm_runtime_irq_safe()
      can't be used, and neither pm_runtime_suspend() nor pm_runtime_resume()
      may be invoked in atomic context.
      
      For clocks that do implement the enable and disable methods then
      everything just works as before.
      
      A note on sparse:
      According to https://lwn.net/Articles/109066/ there are things
      that sparse can't cope with. In particular, pm_clk_op_lock() and
      pm_clk_op_unlock() may or may not lock/unlock psd->lock depending on
      some runtime condition. To work around that we tell it the lock is
      always untaken for the purpose of static analisys.
      
      Thanks to Naresh Kamboju for reporting issues with the initial patch.
      Signed-off-by: NNicolas Pitre <npitre@baylibre.com>
      Tested-by: NNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0bfa0820
  10. 17 12月, 2020 2 次提交
  11. 15 11月, 2020 4 次提交
  12. 26 10月, 2020 1 次提交
  13. 04 8月, 2020 1 次提交
  14. 24 7月, 2020 2 次提交
  15. 22 6月, 2020 1 次提交
  16. 26 5月, 2020 1 次提交
  17. 06 5月, 2020 2 次提交
  18. 21 3月, 2020 1 次提交
  19. 29 2月, 2020 1 次提交
    • M
      clk: Fix phase init check · c3944ec8
      Maxime Ripard 提交于
      Commit 27608786 ("clk: Bail out when calculating phase fails during
      clk registration") introduced a check on error values at the time the
      clock is registered to bail out when such an error occurs. However, it
      doesn't check whether the returned value is positive which will happen
      if the driver returns a non-zero phase. Since a phase is usually a
      non-zero positive number this ends up returning something that isn't 0
      to the caller of __clk_core_init(), making most clks fail to register
      if they implement a phase clk op and return anything besides 0 for the
      phase.
      
      Fix this by returning the error if phase is less than zero or just
      return zero if the phase is a positive number.
      
      Fixes: 27608786 ("clk: Bail out when calculating phase fails during clk registration")
      Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
      Link: https://lkml.kernel.org/r/20200225134248.919889-1-maxime@cerno.techReported-by: N"kernelci.org bot" <bot@kernelci.org>
      [sboyd@kernel.org: Reword commit text to provide clarity]
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      c3944ec8
  20. 13 2月, 2020 6 次提交
  21. 04 2月, 2020 1 次提交
  22. 06 1月, 2020 1 次提交
  23. 05 1月, 2020 2 次提交
  24. 27 12月, 2019 1 次提交
    • G
      clk: Don't try to enable critical clocks if prepare failed · 12ead774
      Guenter Roeck 提交于
      The following traceback is seen if a critical clock fails to prepare.
      
      bcm2835-clk 3f101000.cprman: plld: couldn't lock PLL
      ------------[ cut here ]------------
      Enabling unprepared plld_per
      WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:1014 clk_core_enable+0xcc/0x2c0
      ...
      Call trace:
       clk_core_enable+0xcc/0x2c0
       __clk_register+0x5c4/0x788
       devm_clk_hw_register+0x4c/0xb0
       bcm2835_register_pll_divider+0xc0/0x150
       bcm2835_clk_probe+0x134/0x1e8
       platform_drv_probe+0x50/0xa0
       really_probe+0xd4/0x308
       driver_probe_device+0x54/0xe8
       device_driver_attach+0x6c/0x78
       __driver_attach+0x54/0xd8
      ...
      
      Check return values from clk_core_prepare() and clk_core_enable() and
      bail out if any of those functions returns an error.
      
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Fixes: 99652a46 ("clk: migrate the count of orphaned clocks at init")
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Link: https://lkml.kernel.org/r/20191225163429.29694-1-linux@roeck-us.netSigned-off-by: NStephen Boyd <sboyd@kernel.org>
      12ead774
  25. 24 12月, 2019 3 次提交
新手
引导
客服 返回
顶部