Since the return value is not checked anyhow, we don't need to store it.
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Those variables are immediately assigned a value afterwards.
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Currently when a gpio is defined for battery presence it is only used in
the sbs_get_battery_presence_and_health function for 2 properties.
All other properties currently try to read data form the battery before
returning an error if not present. We should know in advance that no
data is going to returned.
As the driver tries multiple times to access a property, this prevents
a lot of smbus accesses, which had a significant effect on device boot-up.
As when the device is registered lots of property accesses are attempted
during boot.
If no gpio is used for presence detection no change in behaviour should
occur.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
At least with the Inspired Energy compatible batteries a delay is required
after setting the capacity mode bit from amp to watts or the reverse.
Setting the bit and then immediately pooling the status register results
in an unknown error being returned in the register. Add the delay results
in and ok status being return. This was also seen when reading the charge
and energy registers where the wrong value was returned for the requested
mode.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Tested-by: Michael Heinemann <committed@heine.so>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Sort the header includes prior to adding to the list.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
checkpatch issued an error in having the FSF address in the comment.
As address may change and Linux already includes a copy.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The capacity mode bit is bit 15. Currently it is written as
default initialized enum and never shifted. This leads to
a behaviour where the BATTERY_MODE is not correctly
recognized and set again.
This commit initializes the enum accordingly.
Signed-off-by: Michael Heinemann <committed@heine.so>
Tested-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
According to the smart battery spec (1), the CAPACITY_MODE bit does not
influence the value read from RelativeStateOfCharge(), so don't bother
changing CAPACITY_MODE when doing such a read.
(1) - Smart Battery Data Specification, Rev 1.1, Dec. 11, 1998
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
A subset of smart battery commands return charge or energy depending on
the CAPACITY_MODE bit setting of BatteryMode(). In order to
unambiguously read a charge or energy value, it is necessary to ensure
that CAPACITY_MODE is set as desired, and not changed for the duration
of the attribute read.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
i2c_smbus commands handle the correct byte order for smbus transactions
internally. This will currently result in incorrect operation on big
endian systems.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
To simplify the sbs-manager code and notification of battery removal
use the i2c alert callback to notify the sbs-battery driver that an
event has occurred.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The status reported directly by the battery controller is not always
reliable and should be corrected based on the current draw information.
This implements such a correction with a dedicated function, called
where the supply status is retrieved.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
A mechanism to ignore the first external power change notification was
put in place years ago to ignore the power_supply_register notification.
However, this doesn't apply to the current situation anymore, as the
first notification is always the result of a legitimate power change.
This removes this deprecated mechanism, which puts back the driver's
state machine to a sane state (an ignored first notification previously
caused a charging/discharging status inversion).
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Since we use the default primary handler for the irq, IRQF_ONESHOT must
be set. Otherwise the request fails and the following errors are
displayed:
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 129
sbs-battery 0-000b: Failed to request irq: -22
Signed-off-by: Ryosuke Saito <raitosyo@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
There where still a few lingering references to pdata after commit
power: supply: sbs-battery: simplify DT parsing.
Remove pdata from struct·sbs_info and conditional checks to ser if this
was set from the i2c read / write functions.
Instead of call max in each function for incrementing poll_retry_count
do it once in the probe function.
Fixup null pointer dereference in to pdata in sbs_external_power_changed.
Change retry counts to u32 to avoid need for max.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
According to the Smart Battery Data Specification, the use
of ManufacturerAcess (register 0x0) is implementation-defined.
It appears that some batteries use writes to this register
in order to implement certain functionality, but others may
simply NAK all writes to it. As a result, write failures to
ManufacturerAccess should not be used as an indicator of
battery presence, nor as a failure to enter sleep mode.
The failed write access was seen with SANYO AP13J3K.
Cc: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
After the change to use the gpio descriptor interface, we get a warning if
-Wmaybe-uninitialized is added back to the build flags (it is currently
disabled:
drivers/power/supply/sbs-battery.c: In function 'sbs_probe':
drivers/power/supply/sbs-battery.c:760:28: error: 'pdata' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The problem is that if neither the DT properties nor a platform_data
pointer are provided, the chip->pdata pointer gets set to an uninitialized
value.
Looking at the code some more, I found that the sbs_of_populate_pdata
function is more complex than necessary and has confusing calling
conventions of possibly returning a valid pointer, a NULL pointer
or an ERR_PTR pointer (in addition to the uninitialized pointer).
To fix all of that, this gets rid of the chip->pdata pointer and
simply moves the two integers into the sbs_info structure. This
makes it much clearer from reading sbs_probe() what the precedence
of the three possible values are (pdata, DT, hardcoded defaults)
and completely avoids the #ifdef CONFIG_OF guards as
of_property_read_u32() gets replaced with a compile-time stub
when that is disabled, and returns an error if passed a NULL of_node
pointer.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 3b5dd3a494 ("power: supply: sbs-battery: Use gpio_desc and sleeping calls for battery detect")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Switch to using new gpio_desc interface and devm gpio get calls to
automatically manage gpio resource. Use gpiod_get_value which handles
active high / low calls.
If gpio_detect is set then force loading of the driver as it is
reasonable to assume that the battery may not be present.
Update the is_present flag immediately in the IRQ.
Remove legacy gpio specification from platform data.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Battery capacity level is a standard feature of sbs battery
That can be used to tell what the remainig battery capacity is, and
can tell if the battery has not been calibrated/initialized, which makes
the capacity and charging/discharging percentages invalid.
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Use devm_power_supply_register instead of power_supply_register.
Remove call to power_supply_unregister.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Currently the battery detect gpio can not be used with a chained interrupt
controller that requires threaded irq handlers. Use threaded irq instead.
In addition this was not going to be working at present because
chip->power_supply is assigned after the request irq call.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Use devm_kzalloc to allow memory to be freed automatically on
driver probe failure or removal.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This moves all power supply drivers from drivers/power/
to drivers/power/supply/. The intention is a cleaner
source tree, since drivers/power/ also contains frameworks
unrelated to power supply, like adaptive voltage scaling.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
