In current driver, power_supply_changed() is called whenever any of
the battery attribute changed. This causes kernel to increases the
'/sys/power/wakeup_count' and make suspend not working correctly.

This patch change this behavior to call power_supply_changed()
only when the battery capacity changed.
Signed-off-by: NPuthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: NDavid Riley <davidriley@chromium.org>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

- SOC is at 0x1C so we must add 0x4 as stated in the comment to read the
  right value.
- DCAP is at 0x3c so we also must use a value with the right offset to get
  the correct design capacity.

Actually testing on a bq27410 which has the same register map as bq27425
(but adds new registers).
Signed-off-by: NEric Bénard <eric@eukrea.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

This is only a small clean-up. The driver can be built without SYSFS
as there exist stubs for used functions.
Signed-off-by: NKarol Wrona <k.wrona@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

This patch fixes following build warning:

In file included from include/linux/printk.h:261:0,
                 from include/linux/kernel.h:13,
                 from include/linux/list.h:8,
                 from include/linux/module.h:9,
                 from drivers/power/bq24190_charger.c:11:
drivers/power/bq24190_charger.c: In function ‘bq24190_irq_handler_thread’:
include/linux/dynamic_debug.h:86:20: warning: ‘ss_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                    ^
drivers/power/bq24190_charger.c:1211:5: note: ‘ss_reg’ was declared here
  u8 ss_reg, f_reg;
     ^
In file included from include/linux/printk.h:261:0,
                 from include/linux/kernel.h:13,
                 from include/linux/list.h:8,
                 from include/linux/module.h:9,
                 from drivers/power/bq24190_charger.c:11:
include/linux/dynamic_debug.h:86:20: warning: ‘f_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                    ^
drivers/power/bq24190_charger.c:1211:13: note: ‘f_reg’ was declared here
  u8 ss_reg, f_reg;
Signed-off-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Add a reset driver for Renesas R-Mobile and SH-Mobile SoCs. It registers
a restart handler to trigger a soft power-on reset through the R-Mobile
System Controller.
The priority of this restart handler is 192, to allow a watchdog driver
to use priority 128.

Note that we do not use syscon-reboot, as the HPB (Peripheral Bus
Bridge) semaphore should be acquired on systems where both the ARM and
SH core are in use. The driver can be extended later to support this,
when needed.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Remove the function ab8500_fg_reinit() that is not used anywhere.

This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

drivers/power/max77693_charger.c:747:3-8: No need to set .owner here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

drivers/power/max77693_charger.c:615:1-4: WARNING: end returns can be simpified

 Simplify a trivial if-return sequence.  Possibly combine with a
 preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci

CC: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Now, as all VE platforms have to be booted with DT,
the code handling non-DT case can be removed.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Add myself as supporter to help in reviewing patches for Maxim 14577 and
77693 MUIC charger drivers. These are used on Exynos-based boards
(Trats 2, Gear 1 and Gear 2).
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Acked-By: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Document the settings exported by max77693 charger driver through sysfs
entries:
 - fast_charge_timer
 - top_off_threshold_current
 - top_off_timer
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Add new driver for Maxim 77693 switch-mode charger (part of max77693
MFD driver) providing power supply class information to userspace.

The charger has +20V tolerant input. Current input can be set from 0 to
2.58 A. The charger can deliver up to 2.1 A to the battery or 3.5 A to
the system (when supplying additional current from battery to system).

The driver is configured through DTS (battery and system related
settings) and sysfs entries (timers and top-off charging threshold).
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Prepare for adding support for Maxim 77693 charger by adding necessary
new defines.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Document new device tree bindings for Maxim 77693 charger driver.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

The driver mismatched 'num_supplicants' with 'num_supplies' of
power_supply structure.

It provided list of supplicants (power_supply.supplied_to) but did
not set the number of supplicants. Instead it set the num_supplies which
is used when iterating over number of supplies (power_supply.supplied_from).

As a result the list of supplicants was ignored by core because its size
was 0.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: <stable@vger.kernel.org>
Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Teach collie_battery driver to communicate to the kernel that it can
generate wakeup events. Handle enabling/disabling wakeup on battery full
event in suspend/resume callbacks.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

enable_irq_wakeup returns 0 in case it correctly enabled the IRQ to
generate the wakeup event (and thus resume should call disable_irq_wake).
Currently gpio-charger driver has this logic inverted. Correct that thus
correcting enable/disable_irq_wake() calls balance.

Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

This patch adds device driver of Richtek PMIC.
The driver support battery fuel gauge. Fuel gauge calculates and determines the
battery state of charge (SOC) according to battery open circuit voltage (OCV).
Also, this driver provides battery average voltage, voltage and battery present
property.

Cc: Sebastian Reichel <sre@kernel.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NBeomho Seo <beomho.seo@samsung.com>
Acked-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Document the fact that the trigger signal is now optional, and describe
the behavior when this is used.

While at it, fix a typo, and paraphrase a sentence to be less platform
specific.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Currently the ltc2952 supports only one button sequence to initiate
powerdown. This is not always desirable, as even prolonged button
presses can happen in use.

Allow ltc2952 users to pick their own power down sequence, by making the
trigger input optional. Since this still means that the ltc2952 may
power down the platform if the power button is pressed for about 5
seconds, we still need to make sure to start the watchdog toggle to
prolong the system power for as long as we need it.

This will still allow the system to control power using the kill signal.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

In ltc2952_poweroff_handler it is theoretically possible that the timer
fails to start on first pass (button press), but succeeds in starting on
the second (button release). This will cause the button press to be
misinterpreted, and will incorrectly shut down the system. Because a
picture says more than a thousand words:

Expected behavior:
tmr:      ++++++++++
btn: -----__________-----

Faulty behavior:
tmr:                +++++
btn: -----__________-----

Legend:
+ timer runs
_ button pressed
- button depressed

To prevent this from happening, check the value of the gpio before
starting the timer. If the button is active, we should start the timer,
else we should stop it.

The situation described can now still occur if the polarity of the input
pin is set incorrectly, but that at least is predictable behavior and
can be detected during the first tests.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Disable the timers when ltc2952_poweroff is removed. We don't want to
risk calling functions on data that no longer exist.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

The function pointers for the timers and pm_power_off are assigned with
C++ style
	foo = &func;

Let's change it instead to the more C style
	foo = func;
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

ltc2952_poweroff_handler uses gotos to return from the function. Since
we don't do cleanups exiting this function, just return IRQ_HANDLED on
the spot and be done with it.

While at it, remove the variable 'ret'. It was never used very much.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Documentation/SubmittingDrivers suggests these be implemented even when
they do nothing. On the other hand, the platform code calls these
functions 'legacy'. Suspend and resume operations should go into a
pm_ops structure, pointed at by the driver's pm field. This approach
would lead to a lot of boiler plate, while achieving nothing. Drop the
functions instead.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

As per Documentation/CodingStyle ch.4, we should keep global variables
to a mininum. Move the panic state into the driver data, regardless of
whether panic is a system state or not.

This removes the need for the custom _init and _exit functions, so
replace them with a call to the module_platform_driver() macro.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Documentation/CodingStyle ch.4 mentions in a side node that global
variables should only be used if you really need them. Reduce the use of
the global instance of ltc2952_poweroff so we may eventually remove it
entirely.

While at it, rename ltc2952_poweroff_data to ltc2952_poweroff, just to
save that little bit of typing.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

This reduces cleanup code and chance of errors.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

The three gpio's used by this driver are stored in an array of pointers.
This doesn't add much besides cleanups in a loop. In fact, it makes most
of the usage sites harder to read. Unroll the loop, and live with the
fact that cleanups become slightly larger.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Make use of the fact that we allocated resources can be automatically
deallocated. This reduces cleanup code and chance of errors. It also
removes the need for the virq member of the ltc2952_poweroff_data
struct.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Make use of the fact that the allocated resources can be automatically
deallocated. This reduces cleanup code and chance of leaks.
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Augment the Versatile reset driver to also handle the core
module reset sequence used on the Integrator/AP and
Integrator/CP.

Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Pull pin control fixes from Linus Walleij:
 "Here is a (hopefully final) slew of pin control fixes for the v3.19
  series.  The deadlock fix is kind of serious and tagged for stable,
  the rest is business as usual.

   - Fix two deadlocks around the pin control mutexes, a long-standing
     issue that manifest itself in plug/unplug of pin controllers.
     (Tagged for stable.)

   - Handle an error path with zero functions in the Qualcomm pin
     controller.

   - Drop a bogus second GPIO chip added in the Lantiq driver.

   - Fix sudden IRQ loss on Rockchip pin controllers.

   - Register the GIT tree in MAINTAINERS"

* tag 'pinctrl-v3.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  pinctrl: MAINTAINERS: add git tree reference
  pinctrl: qcom: Don't iterate past end of function array
  pinctrl: lantiq: remove bogus of_gpio_chip_add
  pinctrl: Fix two deadlocks
  pinctrl: rockchip: Avoid losing interrupts when supporting both edges

Pull networking fixes from David Miller:

 1) Socket addresses returned in the error queue need to be fully
    initialized before being passed on to userspace, fix from Willem de
    Bruijn.

 2) Interrupt handling fixes to davinci_emac driver from Tony Lindgren.

 3) Fix races between receive packet steering and cpu hotplug, from Eric
    Dumazet.

 4) Allowing netlink sockets to subscribe to unknown multicast groups
    leads to crashes, don't allow it.  From Johannes Berg.

 5) One to many socket races in SCTP fixed by Daniel Borkmann.

 6) Put in a guard against the mis-use of ipv6 atomic fragments, from
    Hagen Paul Pfeifer.

 7) Fix promisc mode and ethtool crashes in sh_eth driver, from Ben
    Hutchings.

 8) NULL deref and double kfree fix in sxgbe driver from Girish K.S and
    Byungho An.

 9) cfg80211 deadlock fix from Arik Nemtsov.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (36 commits)
  s2io: use snprintf() as a safety feature
  r8152: remove sram_read
  r8152: remove generic_ocp_read before writing
  bgmac: activate irqs only if there is nothing to poll
  bgmac: register napi before the device
  sh_eth: Fix ethtool operation crash when net device is down
  sh_eth: Fix promiscuous mode on chips without TSU
  ipv6: stop sending PTB packets for MTU < 1280
  net: sctp: fix race for one-to-many sockets in sendmsg's auto associate
  genetlink: synchronize socket closing and family removal
  genetlink: disallow subscribing to unknown mcast groups
  genetlink: document parallel_ops
  net: rps: fix cpu unplug
  net: davinci_emac: Add support for emac on dm816x
  net: davinci_emac: Fix ioremap for devices with MDIO within the EMAC address space
  net: davinci_emac: Fix incomplete code for getting the phy from device tree
  net: davinci_emac: Free clock after checking the frequency
  net: davinci_emac: Fix runtime pm calls for davinci_emac
  net: davinci_emac: Fix hangs with interrupts
  ip: zero sockaddr returned on error queue
  ...

Pull crypto fix from Herbert Xu:
 "This fixes a regression that arose from the change to add a crypto
  prefix to module names which was done to prevent the loading of
  arbitrary modules through the Crypto API.

  In particular, a number of modules were missing the crypto prefix
  which meant that they could no longer be autoloaded"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: add missing crypto module aliases

"sp->desc[i]" has 25 characters.  "dev->name" has 15 characters.  If we
used all 15 characters then the sprintf() would overflow.

I changed the "sprintf(sp->name, "%s Neterion %s"" to snprintf(), as
well, even though it can't overflow just to be consistent.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Hayes Wang says:

====================
r8152: couldn't read OCP_SRAM_DATA

Read OCP_SRAM_DATA would read additional bytes and may let
the hw abnormal.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Read OCP register 0xa43a~0xa43b would clear some flags which the hw
would use, and it may let the device lost. However, the unit of
reading is 4 bytes. That is, it would read 0xa438~0xa43b when calling
sram_read() to read OCP_SRAM_DATA.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For ocp_write_word() and ocp_write_byte(), there is a generic_ocp_read()
which is used to read the whole 4 byte data, keep the unchanged bytes,
and modify the expected bytes. However, the "byen" could be used to
determine which bytes of the 4 bytes to write, so the action could be
removed.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>