Since only regulator_ena_gpio_request() allocates rdev->ena_pin, and it
guarantees that same gpiod gets same pin structure, it is enough to
compare just the pointers. Also we know there can be only one matching
entry on the list. Rework the code take advantage of the facts.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/3ff002c7aa3bd774491af4291a9df23541fcf892.1597195321.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

By calling device_initialize() earlier and noting that kfree(NULL) is
ok, we can save a bit of code in error handling and plug of_node leak.
Fixed commit already did part of the work.

Fixes: 9177514c ("regulator: fix memory leak on error path of regulator_register()")
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: NVladimir Zapolskiy <vz@mleia.com>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/f5035b1b4d40745e66bacd571bbbb5e4644d21a1.1597195321.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Pull regulator_list_mutex into set_consumer_device_supply() and keep
allocations outside of it. Fourth of the fs_reclaim deadlock case.

Fixes: 45389c47 ("regulator: core: Add early supply resolution for regulators")
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/f0380bdb3d60aeefa9693c4e234d2dcda7e56747.1597195321.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Move all allocations outside of the regulator_lock()ed section.

======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #535 Not tainted
------------------------------------------------------
f2fs_discard-179:7/702 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0

but task is already holding lock:
cb95b080 (&dcc->cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

[...]

-> #3 (fs_reclaim){+.+.}-{0:0}:
       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       __kmalloc_track_caller+0x54/0x218
       kstrdup+0x40/0x5c
       create_regulator+0xf4/0x368
       regulator_resolve_supply+0x1a0/0x200
       regulator_register+0x9c8/0x163c

[...]

other info that might help us debug this:

Chain exists of:
  regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock

[...]

Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/6eebc99b2474f4ffaa0405b15178ece0e7e4f608.1597195321.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Move another allocation out of regulator_list_mutex-protected region, as
reclaim might want to take the same lock.

WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0

but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (fs_reclaim){+.+.}-{0:0}:
       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       kmem_cache_alloc_trace+0x40/0x1e8
       regulator_register+0x384/0x1630
       devm_regulator_register+0x50/0x84
       reg_fixed_voltage_probe+0x248/0x35c
[...]
other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               lock(regulator_list_mutex);
                               lock(fs_reclaim);
  lock(regulator_list_mutex);

 *** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
 #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
 #1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8
[...]

Fixes: 541d052d ("regulator: core: Only support passing enable GPIO descriptors")
[this commit only changes context]
Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Allocating memory with regulator_list_mutex held makes lockdep unhappy
when memory pressure makes the system do fs_reclaim on eg. eMMC using
a regulator. Push the lock inside regulator_init_coupling() after the
allocation.

======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #533 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
cca78ca4 (&sbi->write_io[i][j].io_rwsem){++++}-{3:3}, at: __submit_merged_write_cond+0x104/0x154
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}-{0:0}:
       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       __kmalloc+0x54/0x218
       regulator_register+0x860/0x1584
       dummy_regulator_probe+0x60/0xa8
[...]
other info that might help us debug this:

Chain exists of:
  &sbi->write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaim

Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               lock(regulator_list_mutex);
                               lock(fs_reclaim);
  lock(&sbi->write_io[i][j].io_rwsem);
 *** DEADLOCK ***

1 lock held by kswapd0/383:
 #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
[...]

Fixes: d8ca7d18 ("regulator: core: Introduce API for regulators coupling customization")
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200810093931.50624-1-colin.king@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix possible NULL pointer dereference.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20200802032509.305425-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

The desc->name field is allocated with devm_kstrdup, but is also kfreed
on the error path, causing it to be double freed. Remove the kfree on
the error path.

Fixes: 8d9f8d57 ("regulator: Add driver for cros-ec-regulator")
Signed-off-by: NPi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200728091909.2009771-1-pihsun@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Use module_i2c_driver to simplify driver init boilerplate.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20200725014414.1825183-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

The change corrects registration and deregistration on error path
of a regulator, the problem was manifested by a reported memory
leak on deferred probe:

    as3722-regulator as3722-regulator: regulator 13 register failed -517

    # cat /sys/kernel/debug/kmemleak
    unreferenced object 0xecc43740 (size 64):
      comm "swapper/0", pid 1, jiffies 4294937640 (age 712.880s)
      hex dump (first 32 bytes):
        72 65 67 75 6c 61 74 6f 72 2e 32 34 00 5a 5a 5a  regulator.24.ZZZ
        5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      backtrace:
        [<0c4c3d1c>] __kmalloc_track_caller+0x15c/0x2c0
        [<40c0ad48>] kvasprintf+0x64/0xd4
        [<109abd29>] kvasprintf_const+0x70/0x84
        [<c4215946>] kobject_set_name_vargs+0x34/0xa8
        [<62282ea2>] dev_set_name+0x40/0x64
        [<a39b6757>] regulator_register+0x3a4/0x1344
        [<16a9543f>] devm_regulator_register+0x4c/0x84
        [<51a4c6a1>] as3722_regulator_probe+0x294/0x754
        ...

The memory leak problem was introduced as a side ef another fix in
regulator_register() error path, I believe that the proper fix is
to decouple device_register() function into its two compounds and
initialize a struct device before assigning any values to its fields
and then using it before actual registration of a device happens.

This lets to call put_device() safely after initialization, and, since
now a release callback is called, kfree(rdev->constraints) shall be
removed to exclude a double free condition.

Fixes: a3cde953 ("regulator: core: fix regulator_register() error paths to properly release rdev")
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Cc: Wen Yang <wenyang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20200724005013.23278-1-vz@mleia.comSigned-off-by: NMark Brown <broonie@kernel.org>

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200719200623.61524-1-grandmaster@al2klimov.deSigned-off-by: NMark Brown <broonie@kernel.org>

When requesting the enable GPIO, the driver should do so with the
correct output level matching some expected state. This is especially
important if the regulator is a critical one, such as a supply for
the boot CPU. This is currently done by checking for the enable-at-boot
property, but this is not documented in the device tree binding, nor
does it match the common regulator properties.

Honor the common regulator-boot-on property by checking the boot_on
constraint setting within the DT probe path. This is the same as what
is done in the fixed regulator driver.

Also add a comment stating that the enable-at-boot property should not
be used.

Fixes: 006694d0 ("regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20200720132809.26908-1-wens@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Part of the regulator_get() code is already factored out into
create_regulator(). This patch factors out some of the regulator_put()
code into destroy_regulator() so that create_regulator() has a
corresponding unwind function. Subsequent patches will use this
function.
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200716042053.1927676-3-saravanak@google.comSigned-off-by: NMark Brown <broonie@kernel.org>

Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.

This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.

  [sumits: reworked the driver design as per upstream review]
Signed-off-by: NNisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20200622124110.20971-5-sumit.semwal@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Some regulators might need to verify that they have indeed been enabled
after the enable() call is made and enable_time delay has passed.

This is implemented by repeatedly checking is_enabled() upto
poll_enabled_time, waiting for the already calculated enable delay in
each iteration.
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20200622124110.20971-2-sumit.semwal@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

It is never modified, so make it const to allow the compiler to put it
in read-only memory.
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: NPi-Hsun Shih <pihsun@chromium.org>
Link: https://lore.kernel.org/r/20200711114409.9911-1-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Line up descriptions, start description with a lower-case character and
omit old definitions such as quoting the old argument "consumer".
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200708124832.3441649-4-lee.jones@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Kerneldoc validation gets confused if syntax isn't "@.*: ".

Adding the missing colons squashes the following W=1 warnings:
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Link: https://lore.kernel.org/r/20200708124832.3441649-3-lee.jones@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Provide descriptions for some missing function args and
rename others to match the names used.

Fixes the following W=1 warning(s):

 drivers/regulator/devres.c:187: warning: Function parameter or member 'dev' not described in 'devm_regulator_register'
 drivers/regulator/devres.c:226: warning: Function parameter or member 'dev' not described in 'devm_regulator_unregister'
 drivers/regulator/devres.c:226: warning: Function parameter or member 'rdev' not described in 'devm_regulator_unregister'
 drivers/regulator/devres.c:226: warning: Excess function parameter 'regulator' description in 'devm_regulator_unregister'
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200708124832.3441649-2-lee.jones@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

This patch adds support for COMPILE_TEST while fixing a warning when
no support for device tree is there.
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/1c437154873ace65ff738a0ebca511308f1cecc1.camel@googlemail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add missing .owner field in regulator_desc, which is used for refcounting.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20200706080944.663750-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add NXP pca9450 pmic driver.
Signed-off-by: NRobin Gong <yibin.gong@nxp.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Link: https://lore.kernel.org/r/1593793178-9737-2-git-send-email-yibin.gong@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch adds support for ON Semiconductor FAN53880 regulator.

The FAN53880 is an I2C porgrammable power management IC (PMIC)
that contains a BUCK (step-down converter), four LDOs (low dropouts)
and one BOOST (step-up converter).  It is designed for mobile power
applications.
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/20200702210846.31659-2-chf.fritz@googlemail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use the new .probe_new for mp886x. It does not use the const
struct i2c_device_id * argument, so convert it to utilise the
simplified i2c driver registration.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200702100200.1a4c65d1@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

The null pointer check on regmap that checks for a dev_get_regmap failure
is currently returning -ENOENT if the regmap succeeded. Fix this by adding
in the missing ! operator.

Fixes: 4fe66d5a ("regulator: Add support for QCOM PMIC VBUS booster")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Addresses-Coverity: ("Dereference after null check")
Link: https://lore.kernel.org/r/20200702115659.38208-1-colin.king@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

Implementing of_map_mode is necessary to be able to specify operating
modes in the devicetree using 'regulator-allowed-modes', and to change
regulator modes.
Signed-off-by: NAnand K Mistry <amistry@google.com>
Link: https://lore.kernel.org/r/20200702131350.3.I6a0bc18fcdb2fe13e838a31e6d034d0e095368bc@changeidSigned-off-by: NMark Brown <broonie@kernel.org>

This will allow device trees to make use of these constants.
Signed-off-by: NAnand K Mistry <amistry@google.com>
Link: https://lore.kernel.org/r/20200702131350.1.I96e67ab7b4568287eb939e8a572cbc03e87f1aa0@changeidSigned-off-by: NMark Brown <broonie@kernel.org>

The SY8827N from Silergy Corp is a single output DC/DC converter. The
voltage can be controlled via I2C.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200702171438.20edc523@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

Implementing of_map_mode is necessary to be able to specify operating
modes in the devicetree using 'regulator-allowed-modes', and to change
regulator modes.
Signed-off-by: NAnand K Mistry <amistry@google.com>
Link: https://lore.kernel.org/r/20200702162231.v2.3.I7acfb591bfacf3b1b04a3d388385098bfcc9fecd@changeidSigned-off-by: NMark Brown <broonie@kernel.org>

This will allow device trees to make use of these constants.
Signed-off-by: NAnand K Mistry <amistry@google.com>
Link: https://lore.kernel.org/r/20200702162231.v2.1.Icf69e2041b1af4548347018186c3ba6310f53e66@changeidSigned-off-by: NMark Brown <broonie@kernel.org>

This driver enables outputs by setting bit EN_BUCKn in the BUCKn_CTRL1
register. However, if bit EN_PIN_CTRLn in the same register is set, the
output is actually enabled only if EN_BUCKn is set AND an enable pin is
active. Since the driver does not touch EN_PIN_CTRLn, the choice is left to
the hardware, which in turn gets this bit from OTP memory, and in absence
of OTP data it uses a default value that is documented in the datasheet for
LP8752x, but not for LP8756x.

Thus the driver doesn't really "know" whether it is actually enabling the
output or not.

In order to make sure activation is always driver-controlled, just clear
the EN_PIN_CTRLn bit. Now all activation solely depend on the EN_BUCKn bit.
Signed-off-by: NLuca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20200622204329.11147-2-luca@lucaceresoli.netSigned-off-by: NMark Brown <broonie@kernel.org>

IPQ6018 SoC uses the PMIC MP5496. SMPA2 and LDOA2 regulator controls the
APSS and SDCC voltage scaling respectively. Add support for the same.
Signed-off-by: NKathiravan T <kathirav@codeaurora.org>
Link: https://lore.kernel.org/r/1592889472-6843-5-git-send-email-kathirav@codeaurora.orgSigned-off-by: NMark Brown <broonie@kernel.org>

These are never modified, so make them const to allow the compiler to
put them in read-only memory.

Before:
   text    data     bss     dec     hex filename
  20362    2592     152   23106    5a42 drivers/regulator/qcom_spmi-regulator.o

After:
   text    data     bss     dec     hex filename
  21814    1140     152   23106    5a42 drivers/regulator/qcom_spmi-regulator.o
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200629194632.8147-3-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

These are never modified, so make them const to allow the compiler to
put them in read-only memory.

Before:
   text    data     bss     dec     hex filename
  17485     500       8   17993    4649 drivers/regulator/qcom_rpm-regulator.o

After:
   text    data     bss     dec     hex filename
  17881     104       8   17993    4649 drivers/regulator/qcom_rpm-regulator.o
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200629194632.8147-2-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals.  This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/20200626185516.18018-5-wcheng@codeaurora.orgSigned-off-by: NMark Brown <broonie@kernel.org>

This was an upstreaming error.  Remove it as it's not to be used.

Fixes the following W=1 kernel build warning:

 drivers/regulator/qcom_smd-regulator.c:477:36: warning: ‘pmi8994_boost’ defined but not used [-Wunused-const-variable=]
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-10-lee.jones@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

W=1 kernel builds report a lack of descriptions for various
function arguments.  In reality they are documented, but the
formatting was not as expected '@.*:'.  Instead, some weird
arg identifiers were used.

This change fixes the following warnings:

 drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'dev' not described in 'wm8400_register_regulator'
 drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'reg' not described in 'wm8400_register_regulator'
 drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'initdata' not described in 'wm8400_register_regulator'
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Cc: patches@opensource.cirrus.com
Link: https://lore.kernel.org/r/20200626065738.93412-9-lee.jones@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

'rid' is declared as unsigned int, so there is little point checking for <0.

Removing these checks fixes the following W=1 warnings:

 drivers/regulator/tps65218-regulator.c: In function ‘tps65218_pmic_set_suspend_enable’:
 drivers/regulator/tps65218-regulator.c:131:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
 131 | if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
 | ^
 drivers/regulator/tps65218-regulator.c: In function ‘tps65218_pmic_set_suspend_disable’:
 drivers/regulator/tps65218-regulator.c:144:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
 144 | if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
 | ^
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: linux-omap@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-8-lee.jones@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Until now the aforementioned return value has been ignored.
Previous and current calls to tps65217_reg_read() return
instantly when the value is not 0, so let's do that.

Fixes the following W=1 warning:

 drivers/regulator/tps65217-regulator.c: In function ‘tps65217_regulator_probe’:
 drivers/regulator/tps65217-regulator.c:227:9: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
 227 | int i, ret;
 | ^~~
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Cc: Russ Dill <Russ.Dill@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: AnilKumar Ch <anilkumar@ti.com>
Cc: linux-omap@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-7-lee.jones@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>