20 Mar, 2023

1 commit

  • Probing of regulators can be a slow operation and can contribute to
    slower boot times. This is especially true if a regulator is turned on
    at probe time (with regulator-boot-on or regulator-always-on) and the
    regulator requires delays (off-on-time, ramp time, etc).

    While the overall kernel is not ready to switch to async probe by
    default, as per the discussion on the mailing lists [1] it is believed
    that the regulator subsystem is in good shape and we can move
    regulator drivers over wholesale. There is no way to just magically
    opt in all regulators (regulators are just normal drivers like
    platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all
    regulators found in 'drivers/regulator' individually.

    Given the number of drivers touched and the impossibility to test this
    ahead of time, it wouldn't be shocking at all if this caused a
    regression for someone. If there is a regression caused by this patch,
    it's likely to be one of the cases talked about in [1]. As a "quick
    fix", drivers involved in the regression could be fixed by changing
    them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix
    would be to directly fix the problem that caused the issue with async
    probe.

    The approach here follows a similar approach that was used for the mmc
    subsystem several years ago [2]. In fact, I ran nearly the same python
    script to auto-generate the changes. The only thing I changed was to
    search for "i2c_driver", "spmi_driver", and "spi_driver" in addition
    to "platform_driver".

    [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk
    [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/

    Signed-off-by: Douglas Anderson
    Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid
    Signed-off-by: Mark Brown

    Douglas Anderson
     

27 Sep, 2021

1 commit

  • debugfs code complained at boot time that

    debugfs: Directory 'reg-dummy-regulator-dummy' with parent 'regulator'
    already present!

    if we compile kernel with DEBUG_TEST_DRIVER_REMOVE. The problem is that we
    don't provide .remove() method for dummy_regulator_driver, which should
    invoke regulator_unregister() on device teardown to properly free things.

    Though it's harmless as dummy_pdev never gets unbound in practice, let's
    use devm_regulator_register() to get rid of the inconsistency.

    Signed-off-by: Zenghui Yu
    Link: https://lore.kernel.org/r/20210925035507.1904-1-yuzenghui@huawei.com
    Signed-off-by: Mark Brown

    Zenghui Yu
     

14 Sep, 2020

1 commit

  • The only usage of dummy_initdata is to assign its address to the
    init_data field of the regulator_config struct and the only usage
    dummy_ops is to assign its address to the ops field in the
    regulator_desc struct, both which are const pointers. Make them const to
    allow the compiler to put them in read-only memory.

    Signed-off-by: Rikard Falkeborn
    Link: https://lore.kernel.org/r/20200913084114.8851-2-rikard.falkeborn@gmail.com
    Signed-off-by: Mark Brown

    Rikard Falkeborn
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

15 Dec, 2014

1 commit

  • Pull driver core update from Greg KH:
    "Here's the set of driver core patches for 3.19-rc1.

    They are dominated by the removal of the .owner field in platform
    drivers. They touch a lot of files, but they are "simple" changes,
    just removing a line in a structure.

    Other than that, a few minor driver core and debugfs changes. There
    are some ath9k patches coming in through this tree that have been
    acked by the wireless maintainers as they relied on the debugfs
    changes.

    Everything has been in linux-next for a while"

    * tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
    Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
    fs: debugfs: add forward declaration for struct device type
    firmware class: Deletion of an unnecessary check before the function call "vunmap"
    firmware loader: fix hung task warning dump
    devcoredump: provide a one-way disable function
    device: Add dev__once variants
    ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
    ath: use seq_file api for ath9k debugfs files
    debugfs: add helper function to create device related seq_file
    drivers/base: cacheinfo: remove noisy error boot message
    Revert "core: platform: add warning if driver has no owner"
    drivers: base: support cpu cache information interface to userspace via sysfs
    drivers: base: add cpu_device_create to support per-cpu devices
    topology: replace custom attribute macros with standard DEVICE_ATTR*
    cpumask: factor out show_cpumap into separate helper function
    driver core: Fix unbalanced device reference in drivers_probe
    driver core: fix race with userland in device_add()
    sysfs/kernfs: make read requests on pre-alloc files use the buffer.
    sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
    fs: sysfs: return EGBIG on write if offset is larger than file size
    ...

    Linus Torvalds
     

28 Oct, 2014

1 commit


20 Oct, 2014

1 commit


26 Feb, 2014

1 commit


20 Nov, 2012

1 commit


08 Aug, 2012

1 commit


10 May, 2012

1 commit


09 Apr, 2012

1 commit

  • Rather than adding new arguments to regulator_register() every time we
    want to add a new bit of dynamic information at runtime change the function
    to take these via a struct. By doing this we avoid needing to do further
    changes like the recent addition of device tree support which required each
    regulator driver to be updated to take an additional parameter.

    The regulator_desc which should (mostly) be static data is still passed
    separately as most drivers are able to configure this statically at build
    time.

    Signed-off-by: Mark Brown

    Mark Brown
     

24 Nov, 2011

1 commit

  • With device tree support for regulators, its needed that the
    regulator_dev->dev device has the right of_node attached.
    To be able to do this add an additional parameter to the
    regulator_register() api, wherein the dt-adapted driver can
    then pass this additional info onto the regulator core.

    Signed-off-by: Rajendra Nayak
    Signed-off-by: Mark Brown

    Rajendra Nayak
     

01 Nov, 2011

1 commit


09 Jun, 2011

1 commit

  • Recent changes in the driver core appear to mean that the data structures
    for the driver core are not fully initialised unless the driver is bound.
    Make sure the driver core knows the dummy driver is in use by binding it
    to a driver.

    Signed-off-by: Mark Brown
    Signed-off-by: Liam Girdwood

    Mark Brown
     

03 Mar, 2010

1 commit

  • In order to ease transitions with drivers are boards start using regulators
    provide an option to cause all regulator_get() calls to succeed, with a
    dummy always on regulator being supplied where one has not been configured.
    A warning is printed whenever the dummy regulator is used to aid system
    development.

    This regulator does not implement any regulator operations but will allow
    simple consumers which only do enable() and disable() calls to run. It
    is kept separate from the fixed voltage regulator to avoid Kconfig
    confusion on the part of users when it is extended to allow boards to
    explicitly use the dummy regulator to simplify cases where the majority
    of supplies are from fixed regulators without software control.

    This option is currently only effective for systems which do not specify
    full constriants. If required an override could also be provided to allow
    these systems to use the dummy regulator, though it is likely that
    unconfigured supplies on such systems will lead to error due to
    regulators being powered down more aggressively when not in use.

    Signed-off-by: Mark Brown
    Signed-off-by: Liam Girdwood

    Mark Brown