Add two optional current-limit knobs surfaced through
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT, selected by which input source
is currently online:
- DC (DOK / TA-IN): a "dc-current-limit-gpios" array drives the
GPIOs of an external resistor mux connected to the MAX8903 IDC pin
(DC Current-Limit Set Input, pin 11). The IDC pin programs the
step-down DC input current limit from 0.5 A to 2 A via R_IDC when
the DCM mode pin is logic-high. The DT property
"dc-current-limit-mapping" describes the (current_ua, gpio_value)
pairs the board can program; the driver picks the largest entry
whose limit is <= the requested limit. A 0 uA entry, used to
stop drawing DC current, is selectable by issuing a 0 uA request
(the selection uses a -1 "not found" sentinel rather than
tracking best_limit > 0, so the all-zero entry can win).
- USB (UOK / USB-IN): a single "usb-current-limit-gpio" drives the
MAX8903 IUSB pin (USB Current-Limit Set Input, pin 7). The IUSB
pin is silicon-fixed per the MAX8903 datasheet Pin Description:
logic-low selects 100 mA, logic-high selects 500 mA. The two
values are encoded as MAX8903_USB_CURRENT_LIMIT_{LOW,HIGH}_UA
#defines with the datasheet quote in a header comment. The
requested limit picks HIGH if it can absorb 500 mA, else LOW,
else returns -EINVAL rather than silently programming a higher
current that would violate the system power budget. Mirroring
the DC-priority policy in the get path: when ta_in is asserted
the part draws from DC regardless of USB state, so the set path
only routes to USB when DC is not online.
The dispatch in max8903_set_property() to the DC vs USB path needs to
match the active source flag set by the corresponding *_ok GPIO IRQ
handler; both update sites take a new struct mutex source_lock so the
check and the resulting hardware write cannot be torn by a concurrent
IRQ flipping the source-online flag mid-decision. The DOK/UOK IRQ
handlers hold source_lock across the full read-modify-evaluate block
(line sampling, ta_in/usb_in update, dcm/cen GPIO writes, psy type
update) so the cen enable calculation reads a stable other-source
flag rather than racing with the peer IRQ. The IRQs are requested
with IRQF_ONESHOT (threaded), so a sleepable lock is the right
primitive in both contexts. max8903_get_property() also takes
source_lock briefly to snapshot the source flags and current-limit
values so userspace never observes a torn pair of
(source-online flag, current-limit ua).
dc-current-limit-mapping gpio_value entries are validated at parse
against the GPIO array width so a malformed DT value is rejected
instead of being silently truncated by gpiod_set_array_value() and
selecting the wrong mux level. ndescs is also bounded to
< BITS_PER_TYPE(u32) to keep BIT(ndescs) well-defined on 32-bit.
The mapping is additionally required to contain a gpio_value=0
entry: devm_gpiod_get_array_optional() asks for GPIOD_OUT_LOW, so
the hardware mux starts at gpio_value 0, and the driver seeds
dc_current_limit_ua from the matching map entry. A DT lacking the
all-zero entry is rejected with -EINVAL because otherwise the
reported INPUT_CURRENT_LIMIT could disagree with the mux state
until a set_property write picks a real value.
Negative INPUT_CURRENT_LIMIT requests are rejected at the
set_property entry: val->intval is signed, the set_*_current_limit()
helpers take a u32, and a negative cast would silently widen to a
huge unsigned value, bypass the upper-bound guard and program the
maximum permitted current.
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
Link: https://patch.msgid.link/20260605-submit-power-max8903-dc-limit-v2-2-0c5396e98f14@herrie.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add three optional properties to the MAX8903 charger binding to
describe board-level GPIO control of the DC and USB input current
limits:
DC input (TA / DOK pin):
- dc-current-limit-gpios (1..4 GPIOs): mux control lines feeding
the MAX8903 IDC resistor mux;
- dc-current-limit-mapping (uint32-matrix of {microamps,
gpio_bit_pattern} pairs): the available current levels and the
GPIO bit pattern that selects each level.
USB input (USB / UOK pin):
- usb-current-limit-gpios: a single GPIO driving the IUSB pin.
The IUSB pin is silicon-fixed by the MAX8903 datasheet (Pin
Description): low selects 100 mA, high selects 500 mA. Only
the GPIO mapping is board-specific; the current values are
not exposed in DT.
A dependentRequired block ties dc-current-limit-gpios and
dc-current-limit-mapping together so an incomplete DT cannot pass
validation with only one half of the pair.
These let userspace clamp the input draw via the standard
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT power_supply attribute. The HP
TouchPad uses both: two TLMM lines select between 0.5 A, 1.0 A,
1.5 A and 2.0 A DC input current limits behind the MAX8903B
charger, and a third TLMM line picks the IUSB 100 mA / 500 mA
limit.
These are purely additive; existing platforms remain unaffected.
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260605-submit-power-max8903-dc-limit-v2-1-0c5396e98f14@herrie.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The driver has a match table for the i2c bus wired into its driver
structure, but the table is not exported with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE() entry so module alias information
is generated for automatic module loading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the driver registration structure, and the missing module alias
publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260704152428.51844-1-pengpeng@iscas.ac.cn
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The driver has a match table for the pci bus wired into its driver
structure, but the table is not exported with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE() entry so module alias information
is generated for automatic module loading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the driver registration structure, and the missing module alias
publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260704152336.51384-1-pengpeng@iscas.ac.cn
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
In bq256xx_array_parse() the inner "if (val < array[i])" repeats the
second half of the enclosing "if (val > array[i - 1] && val < array[i])",
so it is always true and the "else return i" arm is dead code. The
function performs a round-down table lookup, so returning i - 1 for a
value that falls strictly between two entries is the intended result.
Collapse the redundant branch into a single "return i - 1;"; no
functional change.
Signed-off-by: Anas Khan <anxkhn28@gmail.com>
Link: https://patch.msgid.link/20260702194547.65209-1-anxkhn28@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add support for PbAc, NiZn, RAM, and ZnAr chemistries as defined in the
Smart Battery Data Specification v1.1 (Section 5.1.30 DeviceChemistry).
Currently, the sbs-battery driver only handles LION, LiP, NiCd and NiMH.
The Smart Battery specification defines 8 possible values:
- Lead Acid (PbAc)
- Lithium Ion (LION)
- Nickel Cadmium (NiCd)
- Nickel Metal Hydride (NiMH)
- Nickel Zinc (NiZn)
- Rechargeable Alkaline-Manganese (RAM)
- Zinc Air (ZnAr)
- Lithium Polymer (LiP)
Link: https://sbs-forum.org/specs/sbdat110.pdf
Signed-off-by: Boris Shtrasman <borissh1983@gmail.com>
Link: https://patch.msgid.link/20260624135718.286771-3-borissh1983@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Modify test_sysfs_prop_optional_list to allow multi line parameters, in
order to comply with checkpatch output that limit line by 100 chars.
Allow use cases like:
test_sysfs_prop_optional_list \
property_name "value1","value2","val3","very_long_option"\
,"extra_long_option" \
,"even_more_data"
Signed-off-by: Boris Shtrasman <borissh1983@gmail.com>
Link: https://patch.msgid.link/20260625160556.54830-2-borissh1983@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add a driver that decodes the Reset Status Register (RSR) of the
Freescale ColdFire MCF5441x Reset Controller Module at probe time
and exposes the cause via the power_on_reason sysfs ABI.
The RSR can latch several cause bits simultaneously (Reference
Manual chapter 12.3.2); the driver picks one cause per a priority
that favours the most explanatory diagnostic.
The register layout is described in the driver so it can be built
with COMPILE_TEST on any architecture.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
Link: https://patch.msgid.link/20260617-coldfire-rcm-power-on-reason-v3-1-1a7c7b6b14e7@yoseli.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
cros_usbpd_charger_probe() reads two port counts from the EC and uses
one of them, num_charger_ports, as the loop bound when populating a
fixed-size array:
struct port_data *ports[EC_USB_PD_MAX_PORTS]; /* 8 entries */
...
for (i = 0; i < charger->num_charger_ports; i++)
charger->ports[charger->num_registered_psy++] = port;
Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports
(from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The
only validation is a sanity check that compares the two EC-reported
values against each other:
if (num_charger_ports < num_usbpd_ports ||
num_charger_ports > num_usbpd_ports + 1)
return -EPROTO;
It never checks either count against EC_USB_PD_MAX_PORTS, the size of
the ports[] array. A malfunctioning, malicious or compromised EC that
reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for
example both 255) passes this check, and the loop then writes N pointers
into the 8-entry ports[] array embedded in the devm_kzalloc()'d
charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976
bytes): a slab out-of-bounds write.
Reject a port count larger than the ports[] array can hold.
Fixes: f68b883e8f ("power: supply: add cros-ec USBPD charger driver.")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260616-b4-disp-5e197080-v2-1-8aa5bffce945@proton.me
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
cros_pchg_probe() registers an EC event notifier whose callback uses the
devm-allocated charger_data via container_of(). The driver has no
remove callback and does not unregister the notifier, so the notifier
chain can retain a pointer to freed driver state after unbind or probe
cleanup.
Register a devm cleanup action immediately after the notifier is
installed so the notifier is unregistered before the driver state is
released. Also fail probe if the notifier cannot be registered, instead
of leaving a charger device that cannot receive EC events.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260615063105.39152-1-pengpeng@iscas.ac.cn
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The restart-handler binding documents "priority" as a uint32 value in
the range 0 to 255. The syscon reboot driver stored it in an int and
used the signed DT helper, which makes the helper type disagree with
the schema.
Read "priority" as u32 so the driver follows the binding while
preserving the same default value.
Assisted-by: Codex:gpt-5-5
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260612215325.1889302-1-robh@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The battery drivers read properties whose bindings use signed values
for temperature thresholds and unsigned values for voltage thresholds.
Some helpers used the opposite signedness, which makes property type
checking report real mismatches.
Use signed helpers where the binding and DTS allow negative values, and
use unsigned helpers for voltage properties documented as uint32 cells.
Assisted-by: Codex:gpt-5-5
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260612215308.1888834-1-robh@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
