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>
