18 Sep, 2020

1 commit

  • …matti.vaittinen@fi.rohmeurope.com>:

    Initial support for ROHM BD9576MUF and BD9573MUF PMICs.

    These PMICs are primarily intended to be used to power the R-Car family
    processors. BD9576MUF includes some additional safety features the
    BD9573MUF does not have. This initial version of drivers does not
    utilize these features and for now the SW behaviour is identical.

    Please note that this version of drivers is only tested on BD9576MUF
    but according to the data-sheets the relevant parts of registers should
    be same so drivers should also work on BD9573MUF.

    This patch series includes MFD, watchdog and regulator drivers with
    basic functionality such as:

    - Enabling and pinging the watchdog
    - configuring watchog timeout / window from device-tree
    - reading regulator states/voltages
    - enabling/disabling VOUT1 (VD50) when control mode B is used.

    This patch series does not bring interrupt support. BD9576MUF and BD9573MUF
    are designed to keep the IRQ line low for whole duration of error
    condition. IRQ can't be 'acked'. So proper IRQ support would require
    some IRQ limiter implementation (delayed unmask?) in order to not hog
    the CPU.

    ---

    Matti Vaittinen (6):
    dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs
    dt_bindings: regulator: Add ROHM BD9576MUF and BD9573MUF PMICs
    mfd: Support ROHM BD9576MUF and BD9573MUF
    wdt: Support wdt on ROHM BD9576MUF and BD9573MUF
    regulator: Support ROHM BD9576MUF and BD9573MUF
    MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers

    .../bindings/mfd/rohm,bd9576-pmic.yaml | 129 +++++++
    .../regulator/rohm,bd9576-regulator.yaml | 33 ++
    MAINTAINERS | 4 +
    drivers/mfd/Kconfig | 11 +
    drivers/mfd/Makefile | 1 +
    drivers/mfd/rohm-bd9576.c | 130 +++++++
    drivers/regulator/Kconfig | 10 +
    drivers/regulator/Makefile | 1 +
    drivers/regulator/bd9576-regulator.c | 337 ++++++++++++++++++
    drivers/watchdog/Kconfig | 13 +
    drivers/watchdog/Makefile | 1 +
    drivers/watchdog/bd9576_wdt.c | 295 +++++++++++++++
    include/linux/mfd/rohm-bd957x.h | 61 ++++
    include/linux/mfd/rohm-generic.h | 2 +
    14 files changed, 1028 insertions(+)
    create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
    create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml
    create mode 100644 drivers/mfd/rohm-bd9576.c
    create mode 100644 drivers/regulator/bd9576-regulator.c
    create mode 100644 drivers/watchdog/bd9576_wdt.c
    create mode 100644 include/linux/mfd/rohm-bd957x.h

    base-commit: f4d51dffc6c01a9e94650d95ce0104964f8ae822
    --
    2.21.0

    --
    Matti Vaittinen, Linux device drivers
    ROHM Semiconductors, Finland SWDC
    Kiviharjunlenkki 1E
    90220 OULU
    FINLAND

    ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
    Simon says - in Latin please.
    ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
    Thanks to Simon Glass for the translation =]

    Mark Brown
     

08 Sep, 2020

1 commit

  • regulator_notifier_call_chain() doesn't need rdev lock and rdev's
    existence is assumed in the code anyway. Remove the locks from drivers.

    Signed-off-by: Michał Mirosław
    Acked-by: Adam Thomson
    Reviewed-by: Dmitry Osipenko
    Link: https://lore.kernel.org/r/42393f66dcc4d80dcd9797be45216b4035aa96cb.1597032945.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Mark Brown

    Michał Mirosław
     

24 Aug, 2020

1 commit

  • Replace the existing /* fall through */ comments and its variants with
    the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
    fall-through markings when it is the case.

    [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

    Signed-off-by: Gustavo A. R. Silva

    Gustavo A. R. Silva
     

13 Jan, 2020

1 commit

  • Use the new .probe_new for i2c drivers.
    These drivers do not use const struct i2c_device_id * argument, so convert
    them to utilise the simplified i2c driver registration.

    Signed-off-by: Axel Lin
    Link: https://lore.kernel.org/r/20200109155808.22003-1-axel.lin@ingics.com
    Signed-off-by: Mark Brown

    Axel Lin
     

07 Oct, 2019

1 commit

  • devm_gpiod_get_from_of_node() is being retired in favor of
    [devm_]fwnode_gpiod_get_index(), that behaves similar to
    devm_gpiod_get_index(), but can work with arbitrary firmware node. It
    will also be able to support secondary software nodes.

    Let's switch this driver over.

    Note that now that we have a good non-devm API for getting GPIO from
    arbitrary firmware node, there is no reason to use devm API here as
    regulator core takes care of managing lifetime of "enable" GPIO and we
    were immediately detaching requested GPIO from devm anyway.

    Signed-off-by: Dmitry Torokhov
    Link: https://lore.kernel.org/r/20191004231017.130290-3-dmitry.torokhov@gmail.com
    Reviewed-by: Linus Walleij
    Signed-off-by: Mark Brown

    Dmitry Torokhov
     

09 Sep, 2019

1 commit

  • The CS GPIO line is clearly optional GPIO (and marked as such in the
    binding document) and we should handle it accordingly. The current code
    treats all errors as meaning that there is no GPIO defined, which is
    wrong, as it does not handle deferrals raised by the underlying code
    properly, nor does it recognize non-existing GPIO from any other
    initialization error.

    As far as I can see the only reason the driver, unlike all others,
    is using OF-specific devm_gpiod_get_from_of_node() so that it can
    assign a custom label to the selected GPIO line. Given that noone else
    needs that, it should not be doing that either.

    Let's switch to using more appropriate devm_gpiod_get_optional().

    Signed-off-by: Dmitry Torokhov
    Link: https://lore.kernel.org/r/20190904214200.GA66118@dtor-ws
    Signed-off-by: Mark Brown

    Dmitry Torokhov
     

09 Aug, 2019

1 commit


24 May, 2019

2 commits


13 May, 2019

1 commit

  • Adding regulator driver for the device Dialog SLG51000.

    The SLG51000 device contains seven compact and customizable low
    dropout regulators and is designed for high performance camera modules
    and other small multi-rail applications.

    Signed-off-by: Eric Jeong
    Signed-off-by: Mark Brown

    Eric Jeong