summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* power: supply: max17042_battery: Add support for the CHARGE_FULL_DESIGN propertyHans de Goede2017-05-011-0/+10
| | | | | | | | The info is there, lets export it as a property. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: max17042_battery: mAh readings depend on r_sns valueHans de Goede2017-05-011-1/+4
| | | | | | | | | | The PROP_CHARGE_FULL code was hardcoded for the default sense resistor of 0.010 Ohm, make it use r_sns which contains the actual sense resistor value in micro-Ohms instead. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: max17042_battery: Add support for the VOLT_MIN propertyHans de Goede2017-05-011-0/+8
| | | | | | | | The info is there, so lets export it, like we already do for VOLT_MAX. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: max17042_battery: Add support for the TECHNOLOGY attributeHans de Goede2017-05-011-0/+4
| | | | | | | | | | | | | | | The max17042 is intended for Li-Ion or Li-Po batteries, add a TECHNOLOGY attribute to reflect this. Note this is hardcoded to Li-Ion as there is no way to tell the difference, and Lithium-Ion Polymer batteries are a sub-family of Lithium-Ion so Li-Ion technically is correct for both. Using Li-Ion for both is already done by many drivers and is much better then not providing any technology info at all. Suggested-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: max17042_battery: Add external_power_changed callbackHans de Goede2017-05-011-0/+6
| | | | | | | | | If our supplier changes status, chances are we've changed status too, let any listeners know about this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: max17042_battery: Add support for the STATUS propertyHans de Goede2017-05-011-0/+46
| | | | | | | | | | | | | | | | Userspace prefers the driver having a status property over having to guess itself. Specifically this will properly make the GNOME3 UI (and likely others) properly show discharging / charging / full status, instead of always showing discharging as status. Note that in the case there is no charger driver supplying the max17042, then a status of unknown will get returned. At least upower treats this the same as not having a status attribute, so in this case nothing changes from a userspace pov. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: max17042_battery: Add default platform_data fallback dataHans de Goede2017-05-011-7/+53
| | | | | | | | | | | | | | | | Some x86 machines use a max17047 fuel-gauge and x86 might be missing platform_data if not provided by SFI. This commit adds default platform_data as fallback option so that the driver can work on boards where no platform_data is provided. Since not all boards have a thermistor hooked up, set temp_min to 0 and change the health checks from temp <= temp_min to temp < temp_min to not trigger on such boards (where temp reads 0). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: max17047_battery: The temp alert values are 8-bit 2's complementHans de Goede2017-05-011-2/+2
| | | | | | | | | The temp alert values are 8-bit 2's complement, so sign-extend them before reporting them back to the caller. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: max17042_battery: Use sign_extend32 instead of DIY codeHans de Goede2017-05-011-21/+3
| | | | | | | | | Use sign_extend32 to sign-extend variables where necessary instead of DIY code. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: ab8500_charger: spelling: "prechage" -> "precharge"Colin Ian King2017-05-011-1/+1
| | | | | | | trivial fix to spelling mistake in dev_error message. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: axp20x_usb_power: add IIO dependencyArnd Bergmann2017-05-011-7/+8
| | | | | | | | | | | | | | | | | | | When CONFIG_IIO=m and the axp20x_usb_power driver is built-in, we get a link time error: drivers/power/built-in.o: In function `axp20x_usb_power_get_property': undefined reference to `iio_read_channel_processed' drivers/power/built-in.o: In function `axp20x_usb_power_probe': undefined reference to `devm_iio_channel_get' undefined reference to `devm_iio_channel_get' This adds the same dependency that we already have for the AC power driver to the USB power driver. For consistency, I'm also moving the two closer together in the Kconfig file. Fixes: 33863c938caa ("power: supply: axp20x_usb_power: use IIO channels when available") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: isp1704: Fix unchecked return value of devm_kzallocPan Bian2017-05-011-0/+4
| | | | | | | | | | | Function devm_kzalloc() will return a NULL pointer. However, in function isp1704_charger_probe(), the return value of devm_kzalloc() is directly used without validation. This may result in a bad memory access bug. Fixes: 34a109610e2a ("isp1704_charger: Add DT support") Signed-off-by: Pan Bian <bianpan2016@163.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: generic-adc-battery: use SIMPLE_DEV_PM_OPS helper macroRahul Bedarkar2017-05-011-13/+4
| | | | | | | Replace ifdefs with SIMPLE_DEV_PM_OPS helper macro. Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: sbs-battery: fix the sbs interrupt requestRyosuke Saito2017-05-011-1/+1
| | | | | | | | | | | | 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>
* power: supply: add battery driver for AXP20X and AXP22X PMICsQuentin Schulz2017-05-013-0/+515
| | | | | | | | | | | | | | | | | | | The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply. This patch adds the battery power supply driver to get various data from the PMIC, such as the battery status (charging, discharging, full, dead), current max limit, current current, battery capacity (in percentage), voltage max and min limits, current voltage and battery capacity (in Ah). This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data provider. Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: bq24190_charger: Deprecate battery class and replicate its ↵Liam Breck2017-05-011-35/+111
| | | | | | | | | | | | | | | | | | | features in charger The driver was registering two classes, bq24190-battery & -charger. Because the power supply framework cannot surface features from multiple drivers in a single class, a fuel gauge driver would create a third class, which some power management utilities cannot see. Deprecate the -battery class for future removal and replicate its features in -charger. Set /sys/class...-charger/online = pg_stat && !batfet_disable. If device_property "omit-battery-class" is set, don't register -battery. Cc: Tony Lindgren <tony@atomide.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Liam Breck <kernel@networkimprov.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: Make power_supply_am_i_supplied return -ENODEV if there are ↵Hans de Goede2017-05-011-5/+15
| | | | | | | | | | | | | | | | | | | | | | | no suppliers It is sensible to assume that the hardware actually always has a way of charging the battery so when power_supply_am_i_supplied does not find any suppliers, that does not mean that there are none, but simply that no power_supply-drivers are registered / bound for any suppliers for the supply calling power_supply_am_i_supplied. At which point a fuel-gauge driver calling power_supply_am_i_supplied() cannot determine whether the battery is being charged or not. Allow a caller of power_supply_am_i_supplied to differentiate between there not being any suppliers, vs no suppliers being online by returning -ENODEV if there are no suppliers matching supplied_to / supplied_from, which allows fuel-gauge drivers to return POWER_SUPPLY_STATUS_UNKNOWN rather then POWER_SUPPLY_STATUS_DISCHARGING if there are no suppliers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: twl4030-charger: don't check if battery is presentH. Nikolaus Schaller2017-05-011-36/+0
| | | | | | | | | | | | | | | | | | | | We can't assume that the battery is or stays present after probing on devices with replaceable battery. On some devices (e.g. GTA04 or OpenPanodra) it can be removed and even be hot swapped by the user while device continues to operate through external AC or USB power (as long as system power consumption remains below ca. 500mA as provided by USB). Under certain conditions it is possible to boot without battery. So it makes no sense to check for this situation during probe and make the charger driver (and its status reports) completely non-operational if the battery can be inserted later. Tested on: GTA04 and OpenPandora. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: twl4030-charger: add writable INPUT_CURRENT_LIMIT propertyH. Nikolaus Schaller2017-05-011-0/+59
| | | | | | | | | | | | | Currently, the twl4030 charger defines its own max_current by directly creating sysfs nodes. It should use the input_current_limit property which is e.g. used by the bq24257 driver. This patch adds the input_current_property with the same semantics as the max_current property. The code to manage the max_current property is removed by a separate patch. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: bq24190_charger: Add disable-reset device-propertyHans de Goede2017-05-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow platform-code to disable the reset on probe and suspend/resume by setting a "disable-reset" boolean device property on the device. There are several reasons why the platform-code may want to disable the reset on probe and suspend/resume: 1) Resetting the charger should never be necessary it should always have sane values programmed. If it is running with invalid values while we are not running (system turned off or suspended) there is a big problem as that may lead to overcharging the battery. 2) The reset in suspend() is meant to put the charger back into default mode, but this is not necessary and not a good idea. If the charger has been programmed with a higher max charge_current / charge_voltage then putting it back in default-mode will reset those to the safe power-on defaults, leading to slower charging, or charging to a lower voltage (and thus not using the full capacity) while suspended which is undesirable. Reprogramming the max charge_current / charge_voltage after the reset will not help here as that will put the charger back in host mode and start the i2c watchdog if the host then does not do anything for 40s (iow if we're suspended for more then 40s) the watchdog expires resetting the device to default-mode, including resetting all the registers to there safe power-on defaults. So the only way to keep using custom charge settings while suspending is to keep the charger in its normal running state with the i2c watchdog disabled. This is fine as the charger will still automatically switch from constant current to constant voltage and stop charging when the battery is full. 3) Besides never being necessary resetting the charger also causes problems on systems where the charge voltage limit is set higher then the reset value, if this is the case and the charger is reset while charging and the battery voltage is between the 2 voltages, then about half the time the charger gets confused and claims to be charging (REG08 contains 0x64) but in reality the charger has decoupled itself from VBUS (Q1 off) and is drawing 0A from VBUS, leaving the system running from the battery. This last problem is happening on a GPD-win mini PC with a bq24292i charger chip combined with a max17047 fuel-gauge and a LiHV battery. I've checked and TI does not list any errata for the bq24292i which could explain this (there are no errata at all). Cc: Liam Breck <kernel@networkimprov.net> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Liam Breck <kernel@networkimprov.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
* power: supply: bq24190_charger: Use new extcon_register_notifier_all()Hans de Goede2017-04-141-2/+2
| | | | | | | | | | | | | | When I submitted the extcon handling I had a patch pending for the extcon sub-system for extcon_register_notifier to take -1 as cable id for listening for all type cable events on an extcon with a single notifier. In the end it was decided to instead add a new extcon_register_notifier_all function for this, switch to using this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Liam Breck <kernel@networkimprov.net> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* Merge remote-tracking branch 'chanwoo-extcon/ib-extcon-4.12' into psy-nextSebastian Reichel2017-04-143-0/+130
|\
| * extcon: Add new extcon_register_notifier_all() to monitor all external ↵Chanwoo Choi2017-04-043-0/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | connectors The extcon core already provides the extcon_register_notifier() function in order to register the notifier block which is used to monitor the state change for the specific external connector such as EXTCON_USB, EXTCON_USB_HOST and so on. The extcon consumer uses the this function. The extcon consumer might need to monitor the all supported external connectors from the extcon device. In this case, The extcon consumer should have each notifier_block structure for each external connector. This patch adds the new extcon_register_notifier_all() function that extcon consumer is able to monitor the state change of all supported external connectors by using only one notifier_block structure. - List of new added functions: int extcon_register_notifier_all(struct extcon_dev *edev, struct notifier_block *nb); int extcon_unregister_notifier_all(struct extcon_dev *edev, struct notifier_block *nb); int devm_extcon_register_notifier_all(struct device *dev, struct extcon_dev *edev, struct notifier_block *nb); void devm_extcon_unregister_notifier_all(struct device *dev, struct extcon_dev *edev, struct notifier_block *nb); Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
* | power: supply: bq24190_charger: Longer delay while polling reset flagLiam Breck2017-04-141-7/+4
| | | | | | | | | | | | | | | | | | | | On chip reset, polling loop used udelay(10) which is too short to be useful. Instead, use usleep_range(100, 200). Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: bq24190_charger: Uniform pm_runtime_get() failure handlingLiam Breck2017-04-141-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On pm_runtime_get() failure, always emit an error message. Prevent unbalanced pm_runtime_get by calling: pm_runtime_put_noidle() in irq handler pm_runtime_put_sync() on any probe() failure Rename probe() out labels instead of renumbering them. Fixes: 13d6fa8447fa ("power: bq24190_charger: Use PM runtime autosuspend") Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: bq24190_charger: Clean up extcon codeLiam Breck2017-04-141-38/+46
| | | | | | | | | | | | | | | | | | | | Polishing and fixes for initial extcon patch. Fixes: 4db249b6f3b4 ("power: supply: bq24190_charger: Use extcon to determine ilimit, 5v boost") Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: bq24190_charger: Limit over/under voltage fault loggingLiam Breck2017-04-141-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the charger is unplugged before the battery is full we may see an over/under voltage fault. Ignore this rather then emitting a message or uevent. This fixes messages like these getting logged on charger unplug + replug: bq24190-charger 15-006b: Fault: boost 0, charge 1, battery 0, ntc 0 bq24190-charger 15-006b: Fault: boost 0, charge 0, battery 0, ntc 0 Cc: Tony Lindgren <tony@atomide.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: New driver for LEGO MINDSTORMS EV3 batteryDavid Lechner2017-04-143-0/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new driver for the LEGO MINDSTORMS EV3 battery. The EV3 is an embedded ARM device that can use 6 AA batteries or a special rechargeable Li-ion battery pack. The rechargeable battery pack presses a special key switch in the battery compartment to indicate that it is present. The EV3 is only capable of monitoring battery voltage and current. The charging circuit is built into the rechargeable battery pack and there is no way to communicate with is, so we can't provide any information about charging status. When not using the rechargeable battery pack, it is most common to use alkaline batteries to power the device, but it is also common for people to use rechargeable NiMH batteries. Since there is not a way to automatically differentiate between these, the technology property is made writable. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: tps65217: remove debug messages for function callsEnric Balletbo i Serra2017-04-141-4/+0
| | | | | | | | | | | | | | Equivalent information can be nowadays obtained using function tracer. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: ltc2941-battery-gauge: Add OF device ID tableJavier Martinez Canillas2017-04-141-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: charger-manager: simplify return statementsAndi Shyti2017-04-141-21/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some trivial improvements on the returning value of the functions: - remove unnecessary goto labels that just return, return immediately, instead. - do not initialize when not needed. - return the value from the calling function that fails instead of politically choosing -EINVAL. Signed-off-by: Andi Shyti <andi@etezian.org> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: lp8788: prevent out of bounds array accessGiedrius Statkevičius2017-04-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | val might become 7 in which case stime[7] (array of length 7) would be accessed during the scnprintf call later and that will cause issues. Obviously, string concatenation is not intended here so just a comma needs to be added to fix the issue. Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver") Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: cpcap-charger: Add minimal CPCAP PMIC battery chargerTony Lindgren2017-04-143-0/+690
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The custom CPCAP PMIC used on Motorola phones such as Droid 4 has a USB battery charger. It can optionally also have a companion chip that is used for wireless charging. The charger on CPCAP also can feed VBUS for the USB host mode. This can be handled by the existing kernel phy_companion interface. Cc: devicetree@vger.kernel.org Cc: Marcel Partap <mpartap@gmx.net> Cc: Michael Scott <michael.scott@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: bq24190_charger: Use extcon to determine ilimit, 5v boostHans de Goede2017-04-142-0/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for monitoring an extcon device with USB SDP/CDP/DCP and HOST cables and adjust ilimit and enable/disable the 5V boost converter accordingly. This is necessary on systems where the PSEL pin is hardwired high and ILIM needs to be set by software based on the detected charger type, as well as on systems where the 5V boost converter is used, as that always needs to be enabled from software. Cc: Liam Breck <kernel@networkimprov.net> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: bq24190_charger: Add support for bq24192iHans de Goede2017-04-141-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bq24192 and bq24192i are mostly identical to the bq24190, TI even published a single datasheet for all 3 of them. The difference between the bq24190 and bq24192[i] is the way charger-type detection is done, the bq24190 is to be directly connected to the USB a/b lines, where as the the bq24192[i] has a gpio which should be driven high/low externally depending on the type of charger connected, from a register level access pov there is no difference. The differences between the bq24192 and bq24192i are: 1) Lower default charge rate on the bq24192i 2) Pre-charge-current can be max 640 mA on the bq24192i On x86/ACPI systems the code which instantiates the i2c client may not know the exact variant being used, so instead of coding the model-id in the i2c_id struct and bailing if it does not match, check the reported model-id matches one of the supported variants. This commit only adds support for the bq24192i as I don't have a bq24192 to test with, adding support for the bq24192 should be as simple as also accepting its model-id in the model-id test. Cc: Liam Breck <kernel@networkimprov.net> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: bq24190_charger: Use i2c-core irq-mapping codeHans de Goede2017-04-141-63/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The i2c-core already maps of irqs before calling the driver's probe function and there are no in tree users of bq24190_platform_data->gpio_int. Remove the redundant custom irq-mapping code and just use client->irq. Cc: Liam Breck <kernel@networkimprov.net> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: bq24190_charger: mark PM functions as __maybe_unusedArnd Bergmann2017-04-141-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without CONFIG_PM, we get a harmless warning: drivers/power/supply/bq24190_charger.c:1514:12: error: 'bq24190_runtime_resume' defined but not used [-Werror=unused-function] drivers/power/supply/bq24190_charger.c:1501:12: error: 'bq24190_runtime_suspend' defined but not used [-Werror=unused-function] To avoid the warning, we can mark all four PM functions as __maybe_unused, which also lets us remove the incorrect #ifdef. Fixes: 3d8090cba638 ("power: bq24190_charger: Check the interrupt status on resume") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Liam Breck <kernel@networkimprov.net> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: sbs-charger: simplified bool functionDaniel Perez2017-04-141-4/+1
| | | | | | | | | | Signed-off-by: Daniel Perez <danielperezdeandres@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: ab8500: Replaced spaces with tabs in indentMunir Contractor2017-04-141-4/+4
| | | | | | | | | | | | | | | | This patch fixes 4 checkpatch.pl errors on lines 433 to 436: ERROR: code indent should use tabs where possible Signed-off-by: Munir Contractor <munircontractor@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: bq25890: Use gpiod_get()Andy Shevchenko2017-04-141-1/+1
| | | | | | | | | | | | | | Since index is always 0, replace gpiod_get_index() by gpiod_get(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: twl4030_charger: remove incorrect __exit markupsDmitry Torokhov2017-04-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: reset: Add a driver for the Gemini poweroffLinus Walleij2017-04-143-0/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Gemini (SL3516) SoC has a special power controller block that only deal with shutting down the system. If you do not register a driver and activate the block, the power button on the systems utilizing this SoC will do an uncontrolled power cut, which is why it is important to have a special poweroff driver. The most basic functionality is to just shut down the system by writing a special bit in the control register after the system has reached pm_poweroff. It also handles the poweroff from a button or other sources: When the poweroff button is pressed, or a signal is sent to poweroff from an infrared remote control, or when the RTC fires a special alarm (!) the system emits an interrupt. At this point, Linux must acknowledge the interrupt and proceed to do an orderly shutdown of the system. After adding this driver, pressing the poweroff button gives this dmesg: root@gemini:/ root@gemini:/ gemini-poweroff 4b000000.power-controller: poweroff button pressed calling shutdown scripts.. setting /dev/rtc0 from system time unmounting file systems... umount: tmpfs busy - remounted read-only umount: can't unmount /: Invalid argument The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system poweroff uhci_hcd 0000:00:09.1: HCRESET not completed yet! uhci_hcd 0000:00:09.0: HCRESET not completed yet! reboot: Power down gemini-poweroff 4b000000.power-controller: Gemini power off Cc: Janos Laube <janos.dev@gmail.com> Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com> Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: linux-pm@vger.kernel.org Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: supply: max17040: Add OF device ID tableJavier Martinez Canillas2017-04-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: reset: syscon-poweroff: add a mask propertyGuy Shapiro2017-04-141-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Make the syscon-poweroff driver accept value and mask instead of just value. Prior to this patch, the property name for the value was 'mask'. If only the mask property is defined on a node, maintain compatibility by using it as the value. Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: bq24190_charger: Use PM runtime autosuspendTony Lindgren2017-04-141-42/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We can get quite a few interrupts when the battery is trickle charging. Let's enable PM runtime autosuspend to avoid constantly toggling device driver PM runtime state. Let's use a 600 ms timeout as that's how long the USB chager detection might take. Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Liam Breck <kernel@networkimprov.net> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power: bq24190_charger: Check the interrupt status on resumeTony Lindgren2017-04-141-10/+52
|/ | | | | | | | | | | | | | | | | | | | | | | | | Some SoCs like omap3 can configure GPIO irqs to use Linux generic dedicated wakeirq support. If the dedicated wakeirq is configured, the SoC will use a always-on interrupt controller to produce wake-up events. If bq24190 is configured for dedicated wakeirq, we need to check the interrupt status on PM runtime resume. This is because the Linux generic wakeirq will call pm_runtime_resume() on the device on a wakeirq. And as the bq24190 interrupt is falling edge sensitive and only active for 250 us, there will be no device interrupt seen by the runtime SoC IRQ controller. Note that this can cause spurious interrupts on omap3 devices with bq24190 connected to gpio banks 2 - 5 as there's a glitch on those pins waking from off mode as listed in "Advisory 1.45". Devices with this issue should not configure the optional wakeirq interrupt in the dts file. Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Liam Breck <kernel@networkimprov.net> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* Merge tag 'char-misc-4.11-rc4' of ↵Linus Torvalds2017-03-2619-85/+99
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "A smattering of different small fixes for some random driver subsystems. Nothing all that major, just resolutions for reported issues and bugs. All have been in linux-next with no reported issues" * tag 'char-misc-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (21 commits) extcon: int3496: Set the id pin to direction-input if necessary extcon: int3496: Use gpiod_get instead of gpiod_get_index extcon: int3496: Add dependency on X86 as it's Intel specific extcon: int3496: Add GPIO ACPI mapping table extcon: int3496: Rename GPIO pins in accordance with binding vmw_vmci: handle the return value from pci_alloc_irq_vectors correctly ppdev: fix registering same device name parport: fix attempt to write duplicate procfiles auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches Drivers: hv: vmbus: Don't leak memory when a channel is rescinded Drivers: hv: vmbus: Don't leak channel ids Drivers: hv: util: don't forget to init host_ts.lock Drivers: hv: util: move waiting for release to hv_utils_transport itself vmbus: remove hv_event_tasklet_disable/enable vmbus: use rcu for per-cpu channel list mei: don't wait for os version message reply mei: fix deadlock on mei reset intel_th: pci: Add Gemini Lake support intel_th: pci: Add Denverton SOC support intel_th: Don't leak module refcount on failure to activate ...
| * Merge tag 'extcon-fixes-for-4.11-rc3' of ↵Greg Kroah-Hartman2017-03-222-12/+29
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus Chanwoo writes: Update extcon for v4.11-rc3 This patch fixes issues for Intel INT3496 ACPI device as following: - Propagate error code of gpiod_to_irq(). - Set the ID pin as the input direction if firmware has the bug - Rename the gpio name for bining according to the documentation. - Add gpio acpi mapping table and the dependency on X86. - Use the devm_gpiod_get() instead of gpiod_get_index because of acpi mapping table.
| | * extcon: int3496: Set the id pin to direction-input if necessaryHans de Goede2017-03-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the new more strict ACPI gpio code the dsdt's IoRestriction flags are honored on gpiod_get, but in some dsdt's it is wrong, so explicitly call gpiod_direction_input on the id gpio if necessary. This fixes the following errors when the int3496 code is used together with the new more strict ACPI gpio code: [ 2382.484415] gpio gpiochip1: (INT33FF:01): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ [ 2382.484425] gpio gpiochip1: (INT33FF:01): unable to lock HW IRQ 3 for IRQ [ 2382.484429] genirq: Failed to request resources for INT3496:00 (irq 174) on irqchip chv-gpio [ 2382.484518] intel-int3496 INT3496:00: can't request IRQ for USB ID GPIO: -22 [ 2382.500359] intel-int3496: probe of INT3496:00 failed with error -22 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
| | * extcon: int3496: Use gpiod_get instead of gpiod_get_indexHans de Goede2017-03-221-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we've an acpi mapping table we should be using gpiod_get instead of gpiod_get_index. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>