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