- 01 Feb, 2022 32 commits
-
-
Sebastian Reichel authored
Immutable branch between power-supply, mfd, i2c and extcon for for 5.18 This immutable branch fixes the charger setup on Xiaomi Mi Pad 2 and Lenovo Yogabook, which requires updates to multiple drivers throughout the tree. Signed-off-by:Sebastian Reichel <sre@kernel.org>
-
Hans de Goede authored
Make cht_wc_extcon_get_id() report RID_A for ACA adapters, instead of reporting ID_FLOAT. According to the spec. we should read the USB-ID pin ADC value to determine the resistance of the used pull-down resister and then return RID_A / RID_B / RID_C based on this. But all "Accessory Charger Adapter"s (ACAs) which users can actually buy always use a combination of a charging port with one or more USB-A ports, so they should always use a resistor indicating RID_A. But the spec is hard to read / badly-worded so some of them actually indicate they are a RID_B ACA even though they clearly are a RID_A ACA. To workaround this simply always return INTEL_USB_RID_A, which matches all the ACAs which users can actually buy. Acked-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com>
-
Hans de Goede authored
The bq25890 used on the Yogabook YB1-X90 / -X91 models relies on the extcon-driver's BC-1.2 charger detection, and the bq25890 driver expect this info to be available through a parent power_supply class-device which models the detected charger (idem to how the Type-C TCPM code registers a power_supply classdev for the connected charger). Add support for registering the power_supply class-device expected by this setup. Acked-by:
-
Hans de Goede authored
This is a preparation patch for adding support for registering a power_supply class device. Setting usbsrc to "CHT_WC_USBSRC_TYPE_SDP << CHT_WC_USBSRC_TYPE_SHIFT" will make the following switch-case return EXTCON_CHG_USB_SDP just as before, so there is no functional change. Acked-by:
-
Hans de Goede authored
So far the extcon-intel-cht-wc code has only been tested on devices with a Type-C connector with USB-PD, USB3 (superspeed) and DP-altmode support through a FUSB302 Type-C controller. Some devices with the intel-cht-wc PMIC however come with an USB-micro-B connector, or an USB-2 only Type-C connector without USB-PD. Which device-model we are running on can be identified with the new cht_wc_model intel_soc_pmic field. On models without a Type-C controller the extcon code must control the Vbus 5V boost converter and the USB role switch depending on the detected cable-type. Acked-by:
-
Hans de Goede authored
The CHT_WC_VBUS_GPIO_CTLO GPIO actually driving an external 5V Vboost converter for Vbus depends on the board on which the Cherry Trail - Whiskey Cove PMIC is actually used. Since the information about the exact PMIC setup is necessary in other places too, struct intel_soc_pmic now has a new cht_wc_model field indicating the board model. Only poke the CHT_WC_VBUS_GPIO_CTLO GPIO if this new field is set to INTEL_CHT_WC_GPD_WIN_POCKET, which indicates the Type-C (with PD and DP-altmode) setup used on the GPD pocket and GPD win; and on which this GPIO actually controls an external 5V Vboost converter. Acked-by:
-
Hans de Goede authored
The i2c-controller on the Cherry Trail - Whiskey Cove PMIC is special in that it is always connected to the I2C charger IC of the board on which the PMIC is used; and the charger IC is not described in ACPI, so the i2c-cht-wc code needs to instantiate an i2c-client for it itself. So far this was hardcoded to instantiate an i2c-client for the bq24292i, with all properties, etc. set to match how this charger is used on the GPD win and GPD pocket devices. There is a rudimentary check to make sure the ACPI tables are at least somewhat as expected, but this is far from accurate, leading to a wrong i2c-client being instantiated for the charger on some boards. Switch to the new DMI based intel_cht_wc_get_model() helper which is exported by the MFD driver for the CHT Whiskey Cove PMIC to help PMIC cell drivers like the i2c-cht-wc code reliably detect which board they are running on. And add board_info for the charger ICs as found on the other 2 known boards with a Whisky Cove PMIC. This has been tested on all 3 known boards. Acked-by:
Wolfram Sang <wsa@kernel.org> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
Tablet / laptop designs using an Intel Cherry Trail x86 main SoC with an Intel Whiskey Cove PMIC do not use a single standard setup for the charger, fuel-gauge and other chips surrounding the PMIC / charging+data USB port. Unlike what is normal on x86 this diversity in designs is not handled by the ACPI tables. On 2 of the 3 known designs there are no standard (PNP0C0A) ACPI battery devices and on the 3th design the ACPI battery device does not work under Linux due to it requiring non-standard and undocumented ACPI behavior. So to make things work under Linux we use native charger and fuel-gauge drivers on these devices, re-using the native drivers used on ARM boards with the same charger / fuel-gauge ICs. This requires various MFD-cell drivers for the CHT-WC PMIC cells to know which model they are exactly running on so that they can e.g. instantiate an I2C-client for the right model charger-IC (the charger is connected to an I2C-controller which is part of the PMIC). Rather then duplicating DMI-id matching to check which model we are running on in each MFD-cell driver, add a check for this to the shared drivers/mfd/intel_soc_pmic_chtwc.c code by using a DMI table for all 3 known models: 1. The GPD Win and GPD Pocket mini-laptops, these are really 2 models but the Pocket re-uses the GPD Win's design in a different housing: The WC PMIC is connected to a TI BQ24292i charger, paired with a Maxim MAX17047 fuelgauge + a FUSB302 USB Type-C Controller + a PI3USB30532 USB switch, for a fully functional Type-C port. 2. The Xiaomi Mi Pad 2: The WC PMIC is connected to a TI BQ25890 charger, paired with a TI BQ27520 fuelgauge, using the TI BQ25890 for BC1.2 charger type detection, for a USB-2 only Type-C port without PD. 3. The Lenovo Yoga Book YB1-X90 / Lenovo Yoga Book YB1-X91 series: The WC PMIC is connected to a TI BQ25892 charger, paired with a TI BQ27542 fuelgauge, using the WC PMIC for BC1.2 charger type detection and using the BQ25892's Mediatek Pump Express+ (1.0) support to enable charging with up to 12V through a micro-USB port. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Hans de Goede authored
Use the devm_regmap_field_bulk_alloc() helper function instead of open-coding this ourselves. Reviewed-by:
-
Yauhen Kharuzhy authored
Add a "linux,pump-express-vbus-max" property which indicates if the Pump Express+ protocol should be used to increase the charging protocol. If this new property is set and a DCP charger is detected then request a higher charging voltage through the Pump Express+ protocol. So far this new property is only used on x86/ACPI (non devicetree) devs, IOW it is not used in actual devicetree files. The devicetree-bindings maintainers have requested properties like these to not be added to the devicetree-bindings, so the new property is deliberately not added to the existing devicetree-bindings. Changes by Hans de Goede: - Port to my bq25890 patch-series + various cleanups - Make behavior configurable through a new "linux,pump-express-vbus-max" device-property - Sleep 1 second before re-checking the Vbus voltage after requesting it to be raised, to ensure that the ADC has time to sampled the new Vbus - Add VBUSV bq25890_tables[] entry and use it in bq25890_get_vbus_voltage() - Tweak commit message Signed-off-by:
Yauhen Kharuzhy <jekhor@gmail.com> Reviewed-by:
-
Hans de Goede authored
The bq25892 does not have builtin charger-type detection like the bq25980, there might be some external charger detection capability, which will be modelled as a power_supply class-device supplying the bq25892. Use the usb_type property value from the supplier psy-device to set the input-current-limit (when available). Reviewed-by:
-
Hans de Goede authored
The bq25890_charger code supports enabling/disabling the boost converter based on usb-phy notifications. But the usb-phy framework is not used on all boards/platforms. At support for registering the Vbus boost converter as a standard regulator when there is no usb-phy on the board. Also add support for providing regulator_init_data through platform_data for use on boards where device-tree is not used and the platform code must thus provide the regulator_init_data. Reviewed-by:
-
Hans de Goede authored
Add a bq25890_set_otg_cfg() helper function, this is a preparation patch for adding regulator support. Reviewed-by:
-
Hans de Goede authored
Drop the "if (!dev->platform_data)" check, this seems to be an attempt for allowing loading the driver on devices without devicetree stemming from the initial commit of the driver (with the presumed intention being the "return -ENODEV" else branch getting replaced with something else). With the new "linux,skip-init" and "linux,read-back-settings" properties the driver can actually supports devices without devicetree and this check no longer makes sense. While at it, also switch to dev_err_probe(), which is already used in various other places in the driver. Reviewed-by:
-
Hans de Goede authored
On boards where the "linux,skip-reset" boolean property is set we don't reset the charger; and on some boards where the fw takes care of initalizition F_CHG_CFG is set to 0 before handing control over to the OS. Explicitly set F_CHG_CFG to 1 on boards where we don't reset the charger, so that charging is always enabled on these boards, like it is always enabled on boards where we do reset the charger. Reviewed-by:
-
Hans de Goede authored
On most x86/ACPI devices there is no devicetree to supply the necessary init-data. Instead the firmware already fully initializes the bq25890 charger at boot. To support this, add support for reading back the settings from the chip through a new "linux,read-back-settings" boolean. So far this new property is only used on x86/ACPI (non devicetree) devs, IOW it is not used in actual devicetree files. The devicetree-bindings maintainers have requested properties like these to not be added to the devicetree-bindings, so the new property is deliberately not added to the existing devicetree-bindings. Reviewed-by:
-
Hans de Goede authored
On most x86/ACPI devices the firmware already fully initializes the bq25890 charger at boot, in this case it is best to not reset it at probe() time. At support for a new "linux,skip-reset" boolean property to support this. So far this new property is only used on x86/ACPI (non devicetree) devs, IOW it is not used in actual devicetree files. The devicetree-bindings maintainers have requested properties like these to not be added to the devicetree-bindings, so the new property is deliberately not added to the existing devicetree-bindings. Reviewed-by:
-
Hans de Goede authored
On most x86/ACPI devices there is no devicetree to supply the necessary init-data. Instead the firmware already fully initializes the bq25890 charger at boot. Factor out the current code to write all the init_data from devicetree into a new bq25890_rw_init_data() helper which can both write the data to the charger (the current behavior) as well as read it back from the charger into the init_data struct. This is a preparation patch for adding support for x86/ACPI device's where the init_data must be read back from the bq25890 charger. Reviewed-by:
-
Yauhen Kharuzhy authored
Take into account possible current reduction due to low-temperature when reading POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX. As described in the datasheet in cool (0-20° Celcius) conditions the current limit is decreased to 20% or 50% of ICHG field value depended on JEITA_ISET field. Also add NTC_FAULT field value to the debug message in bq25890_get_chip_state(). Changed by Hans de Goede: - Fix reading F_CHG_FAULT instead of F_NTC_FIELD for state->ntc_fault - Only read JEITA_ISET field if necessary - Tweak commit message a bit Signed-off-by:
-
Yauhen Kharuzhy authored
Rename the Input Current Limit field in the REG00 from IILIM to IINLIM accordingly with the bq2589x datasheet. This is just cosmetical change to reduce confusion. Signed-off-by:
-
Hans de Goede authored
Some (USB) charger ICs have variants with USB D+ and D- pins to do their own builtin charger-type detection, like e.g. the bq24190 and bq25890 and also variants which lack this functionality, e.g. the bq24192 and bq25892. In case the charger-type; and thus the input-current-limit detection is done outside the charger IC then we need some way to communicate this to the charger IC. In the past extcon was used for this, but if the external detection does e.g. full USB PD negotiation then the extcon cable-types do not convey enough information. For these setups it was decided to model the external charging "brick" and the parameters negotiated with it as a power_supply class-device itself; and power_supply_set_input_current_limit_from_supplier() was introduced to allow drivers to get the input-current-limit this way. But in some cases psy drivers may want to know other properties, e.g. the bq25892 can do "quick-charge" negotiation by pulsing its current draw, but this should only be done if the usb_type psy-property of its supplier is set to DCP (and device-properties indicate the board allows higher voltages). Instead of adding extra helper functions for each property which a psy-driver wants to query from its supplier, refactor power_supply_set_input_current_limit_from_supplier() into a more generic power_supply_get_property_from_supplier() function. Reviewed-by:
-
Hans de Goede authored
Some boards with an AXP288 fuel-gauge appear to have a broken (approx. 2 milli-ohm instead of 10) current sense resistor. This makes the coulomb-counter part of the fuel-gauge useless, but the OCV based capacity reporting is still working. Add a no_current_sense_res module_param to disable use of the coulomb-counter using parts of the fuel-gauge to allow users to work around this. Note this is a module parameter and not done through DMI quirks, since this seems to be a defect on some boards, not something which all boards of the same model share. Signed-off-by:
-
Hans de Goede authored
The valid flag is protected by the mutex, so code clearing it should take the mutex before cleating the valid flag. Signed-off-by:
-
Hans de Goede authored
Refactor the IRQ initialization code: * Move the looking up of the vIRQs to the beginning of probe(), failing probe early if this fails * Do the actual requesting of IRQs inline in probe() and properly abort probe() on errors * Use devm_request_threaded_irq(), completing the conversion of probe() to only use devm managed resources and remove the remove() driver function. Signed-off-by:
-
Hans de Goede authored
Use devm_power_supply_register() instead of power_supply_register(). Note as a side-effect this changes the release order so that now first the IRQs get free-ed and then the psy gets unregistered. This is actually a bug-fix since this fixes the IRQ possibly trying to reference the unregistered psy. Signed-off-by:
-
Hans de Goede authored
An existing comment already mentions we: "cannot use devm_iio_channel_get because x86 systems lack the device<->channel maps which iio_channel_get will try to use when passed a non NULL device pointer". Work around this by registering a devm action to free the iio-channels. This is a step on the way to fully converting the probe() function to only use devm managed resources. Signed-off-by:
-
Hans de Goede authored
Refactor probe a bit, introducing a new axp288_fuel_gauge_read_initial_regs() helper. This replaces a whole bunch of gotos and removes the unblock_punit_i2c_access label. Signed-off-by:
-
Hans de Goede authored
Add a dev local variable to probe() as shortcut for &pdev->dev, this is a preparation change for making more use of devm managed resources. Signed-off-by:
-
Carl Philipp Klemm authored
This allows cpcap-battery to detect whitch battery is inserted, HW4X or BW8X for xt875 and EB41 for xt894 by examining the battery nvmem. If no known battery is detected sane defaults are used. Signed-off-by:
Carl Philipp Klemm <philipp@uvos.xyz> Signed-off-by:
-
Evgeny Boger authored
As stated in [1], negative current values are used for discharging batteries. AXP PMICs internally have two different ADC channels for shunt current measurement: one used during charging and one during discharging. The values reported by these ADCs are unsigned. While the driver properly selects ADC channel to get the data from, it doesn't apply negative sign when reporting discharging current. [1] Documentation/ABI/testing/sysfs-class-power Signed-off-by:
Evgeny Boger <boger@wirenboard.com> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Miaoqian Lin authored
platform_get_irq() returns negative error number instead 0 on failure. And the doc of platform_get_irq() provides a usage example: int irq = platform_get_irq(pdev, 0); if (irq < 0) return irq; Fix the check of return value to catch errors correctly. Fixes: f7a388d6 ("power: reset: Add a driver for the Gemini poweroff") Signed-off-by:Miaoqian Lin <linmq006@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Sergey Shtylyov authored
Calling platform_get_irq_optional() doesn't make sense if you then bail out on any error it returns. Switch to calling platform_get_irq() instead and remove dev_err() call as platform_get_irq() already curses loudly on error. Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
-
- 31 Jan, 2022 1 commit
-
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worst scenario, could lead to heap overflows. Also, address the following sparse warnings: drivers/power/supply/cros_usbpd-charger.c:107:23: warning: using sizeof on a flexible structure Link: https://github.com/KSPP/linux/issues/174Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
- 23 Jan, 2022 6 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge tag 'perf-tools-for-v5.17-2022-01-22' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull more perf tools updates from Arnaldo Carvalho de Melo: - Fix printing 'phys_addr' in 'perf script'. - Fix failure to add events with 'perf probe' in ppc64 due to not removing leading dot (ppc64 ABIv1). - Fix cpu_map__item() python binding building. - Support event alias in form foo-bar-baz, add pmu-events and parse-event tests for it. - No need to setup affinities when starting a workload or attaching to a pid. - Use path__join() to compose a path instead of ad-hoc snprintf() equivalent. - Override attr->sample_period for non-libpfm4 events. - Use libperf cpumap APIs instead of accessing the internal state directly. - Sync x86 arch prctl headers and files changed by the new set_mempolicy_home_node syscall with the kernel sources. - Remove duplicate include in cpumap.h. - Remove redundant err variable. * tag 'perf-tools-for-v5.17-2022-01-22' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf tools: Remove redundant err variable perf test: Add parse-events test for aliases with hyphens perf test: Add pmu-events test for aliases with hyphens perf parse-events: Support event alias in form foo-bar-baz perf evsel: Override attr->sample_period for non-libpfm4 events perf cpumap: Remove duplicate include in cpumap.h perf cpumap: Migrate to libperf cpumap api perf python: Fix cpu_map__item() building perf script: Fix printing 'phys_addr' failure issue tools headers UAPI: Sync files changed by new set_mempolicy_home_node syscall tools headers UAPI: Sync x86 arch prctl headers with the kernel sources perf machine: Use path__join() to compose a path instead of snprintf(dir, '/', filename) perf evlist: No need to setup affinities when disabling events for pid targets perf evlist: No need to setup affinities when enabling events for pid targets perf stat: No need to setup affinities when starting a workload perf affinity: Allow passing a NULL arg to affinity__cleanup() perf probe: Fix ppc64 'perf probe add events failed' case
-
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-traceLinus Torvalds authored
Pull ftrace fix from Steven Rostedt: "Fix s390 breakage from sorting mcount tables. The latest merge of the tracing tree sorts the mcount table at build time. But s390 appears to do things differently (like always) and replaces the sorted table back to the original unsorted one. As the ftrace algorithm depends on it being sorted, bad things happen when it is not, and s390 experienced those bad things. Add a new config to tell the boot if the mcount table is sorted or not, and allow s390 to opt out of it" * tag 'trace-v5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace: Fix assuming build time sort works for s390
-
Steven Rostedt (Google) authored
To speed up the boot process, as mcount_loc needs to be sorted for ftrace to work properly, sorting it at build time is more efficient than boot up and can save milliseconds of time. Unfortunately, this change broke s390 as it will modify the mcount_loc location after the sorting takes place and will put back the unsorted locations. Since the sorting is skipped at boot up if it is believed that it was sorted at run time, ftrace can crash as its algorithms are dependent on the list being sorted. Add a new config BUILDTIME_MCOUNT_SORT that is set when BUILDTIME_TABLE_SORT but not if S390 is set. Use this config to determine if sorting should take place at boot up. Link: https://lore.kernel.org/all/yt9dee51ctfn.fsf@linux.ibm.com/ Fixes: 72b3942a ("scripts: ftrace - move the sort-processing in ftrace_init") Reported-by:
Sven Schnelle <svens@linux.ibm.com> Tested-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org>
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Bring include/uapi/linux/nfc.h into the UAPI compile-test coverage - Revert the workaround of CONFIG_CC_IMPLICIT_FALLTHROUGH - Fix build errors in certs/Makefile * tag 'kbuild-fixes-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: certs: Fix build error when CONFIG_MODULE_SIG_KEY is empty certs: Fix build error when CONFIG_MODULE_SIG_KEY is PKCS#11 URI Revert "Makefile: Do not quote value for CONFIG_CC_IMPLICIT_FALLTHROUGH" usr/include/Makefile: add linux/nfc.h to the compile-test coverage
-
git://github.com/norov/linuxLinus Torvalds authored
Pull bitmap updates from Yury Norov: - introduce for_each_set_bitrange() - use find_first_*_bit() instead of find_next_*_bit() where possible - unify for_each_bit() macros * tag 'bitmap-5.17-rc1' of git://github.com/norov/linux: vsprintf: rework bitmap_list_string lib: bitmap: add performance test for bitmap_print_to_pagebuf bitmap: unify find_bit operations mm/percpu: micro-optimize pcpu_is_populated() Replace for_each_*_bit_from() with for_each_*_bit() where appropriate find: micro-optimize for_each_{set,clear}_bit() include/linux: move for_each_bit() macros from bitops.h to find.h cpumask: replace cpumask_next_* with cpumask_first_* where appropriate tools: sync tools/bitmap with mother linux all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate cpumask: use find_first_and_bit() lib: add find_first_and_bit() arch: remove GENERIC_FIND_FIRST_BIT entirely include: move find.h from asm_generic to linux bitops: move find_bit_*_le functions from le.h to find.h bitops: protect find_first_{,zero}_bit properly
-
- 22 Jan, 2022 1 commit
-
-
Minghao Chi authored
Return value from perf_event__process_tracing_data() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lore.kernel.org/lkml/20220112080109.666800-1-chi.minghao@zte.com.cnSigned-off-by:
CGEL ZTE <cgel.zte@gmail.com> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
