| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"New Support & Features:
- MediaTek MT6397: Add mt6323 AUXADC support
- MediaTek MT6397: Add mt6323 EFUSE support
- Spreadtrum SC27xx: Add SC2730 regulator cell
Improvements & Fixes:
- Apple SMC: Fix key count endianness annotation
- Azoteq IQS62x: Reject zero-length firmware records
- ChromeOS EC: Introduce cros_ec_read_features helper and read
features during probe to catch transfer errors
- Cirrus Logic CS42L43: Fix regmap defaults ordering
- Cirrus Logic CS42L43: Remove redundant NULL checks on SoundWire
- Congatec Board Controller: Fix teardown ordering in cgbc_remove()
- HP iPAQ Micro: Fix out-of-bounds stack read in ipaq_micro_str
- Marvell 88PM886: Initialize the battery page
- QNAP MCU: Keep the reply buffer alive past a command timeout
- RAVE SP: Validate received frame payload lengths
- Silicon Labs Si476x: Drop duplicate NULL checks
- Silicon Labs Si476x: Modernize GPIO handling
- Silicon Motion SM501: Fix potential memory leaks during remove
- UCB1x00: Convert Assabet gpio-keys to use software nodes and
register software node for GPIO controller
- Viperboard: Fix native fields type in structures as little-endian
- Viperboard: Remove redundant NULL check before kfree()
- X-Powers AXP20x: Preserve other control bits when powering off
Cleanups & Refactoring:
- Core: Drop unused assignment of spi_device_id driver data
- Core: Initialize spi_device_id arrays using member names
- Core: Unify style of spi_device_id arrays
- Maintainers: Add Intel LPSS section to follow the changes
- Maintainers: Add a mailing list entry to MFD
- Cirrus Logic CS42L43: Format sdw_device_id table
- Cirrus Logic CS42L43: Use new SoundWire enumeration helper
- ROHM PMIC: Factor out power button registration and convert
gpio-keys to use software nodes
- ST-Ericsson DB8500: Fold dbx500 header into db8500
Device Tree Binding Updates:
- Core: Add techvision vendor prefix
- Marvell 88PM886: Allow vbus regulator
- MediaTek MT8195 SCP: Add support for MT8189 SoC
- Qualcomm SPMI PMIC: Document PMG1110
- Qualcomm SPMI PMIC: Document haptics device
- Qualcomm TCSR: Add compatible for Hawi and Maili SoCs
- Qualcomm TCSR: Add compatible for Shikra
- Qualcomm TCSR: Document the IPQ9650 TCSR block
- STMicroelectronics STMPE: Fix typo st,stmpe601 (should be
st,stmpe610)
- Syscon: Add ESWIN EIC7700 compatible
- Syscon: Allow syscon compatible for Loongson-2K0300 chip id
- Syscon: Disallow simple-bus with syscon
- Syscon: Drop custom select for older dtschema
- TI OMAP USBHS TLL: Convert to DT schema"
* tag 'mfd-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (45 commits)
mfd: cs42l43: Fix regmap defaults ordering
dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id
dt-bindings: mfd: syscon: Add ESWIN EIC7700 compatible
mfd: qnap-mcu: keep the reply buffer alive past a command timeout
dt-bindings: mfd: qcom,tcsr: Document the IPQ9650 TCSR block
mfd: macsmc: Fix key count endianness annotation
dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
mfd: iqs62x: Reject zero-length firmware records
mfd: rave-sp: validate received frame payload lengths
mfd: sm501: Fix potential memory leaks during remove
mfd: viperboard: Fix native fields type in structures as little-endian
mfd: si476x-i2c: Get rid of duplicate NULL checks
dt-bindings: mfd: Convert OMAP USB TLL to DT schema
mfd: cgbc: Fix teardown ordering in cgbc_remove()
mfd: mt6397-core: Add mt6323 AUXADC support
dt-bindings: mfd: qcom,tcsr: Add compatible for Hawi and Maili SoCs
mfd: rohm: Factor out power button registration
mfd: ucb1x00: Convert Assabet gpio-keys to use software nodes
mfd: ucb1x00: Register software node for GPIO controller
mfd: cs42l43: Tidy up formatting on sdw_device_id table
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Tzung-Bi Shih:
"New:
- Add post_power_on_delay_ms for Hana in of_hw_prober
Improvements:
- Use dumb trackpad prober for Spherion in of_hw_prober
Fixes:
- Check bound of firmware-reported data in cros_ec_sensorhub and
cros_ec_typec
- Fix memory overread in cros_ec_sensorhub
- Fix resource leak in cros_ec_debugfs
- Clamp payload length for LIGHTBAR_CMD_SET_PROGRAM_EX in
cros_ec_lightbar
Cleanups:
- Drop unused platform_device_id driver data
- Remove redundant log"
* tag 'chrome-platform-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: of_hw_prober: Add delay for hana trackpads
platform/chrome: lightbar: Limit payload to max packet size
platform/chrome: cros_ec_debugfs: Unregister panic notifier
platform/chrome: cros_ec_debugfs: Clean up console log on probe failure
platform/chrome: cros_ec: Remove redundant dev_err()
platform/chrome: sensorhub: Fix dropped timestamp events and log spam
platform/chrome: sensorhub: Fix memory overread in ring handler
platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count
platform/chrome: of_hw_prober: Use dumb trackpad prober for Spherion
platform/chrome: Drop unused assignment of platform_device_id driver data
platform/chrome: sensorhub: Bound the EC-reported sensor number
|
|
Up until now, the MT8173 elm/hana device tree has set the dedicated
regulator supplying the trackpad as always-on, simply because the Elan
driver was missing proper delays. As a result the delay for the
Synaptics trackpad was also omitted, as it was not strictly required
under such a model and delayed the availability of the trackpad to the
user.
The Elan driver recently gained proper delays after power-up, with
adaptive skipping of the delay if the regulator was originally
on. The I2C HID driver and I2C OF component prober library gained
similar adaptive delay skipping. The device tree will be fixed to have
the regulator not be always on, and proper post-power-on delay time
added to the I2C HID device.
Also add the post-power-on delay to the ChromeOS OF component prober,
so that if the regulator is off at the time of probing, the prober knows
to wait for the hardware to initialize.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20260811122011.3539250-8-wenst@chromium.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
The LIGHTBAR_CMD_SET_PROGRAM command uses an 8-bit size field for its
payload length, but the protocol-negotiated `max_request` may exceed
the maximum value an 8-bit integer can represent.
When this occurs, large payloads (e.g., >255 bytes) integer wrap the
8-bit size variable when assigning `param->set_program_ex.size`, causing
truncation and parse failures downstream in the EC firmware stack.
Clamp `max_size` to the maximum value the structural size field can
support.
Fixes: 9600b8bdbfe4 ("platform/chrome: lightbar: Add support for large sequence")
Signed-off-by: Alexis Savery <asavery@google.com>
Link: https://lore.kernel.org/r/20260730204240.2227178-1-asavery@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
cros_ec_debugfs_probe() registers notifier_panic with the EC panic
notifier chain. The remove path tears down debugfs and the console log,
but leaves the notifier registered. A later panic notification can call
back into the removed instance and queue work that accesses released
data.
Unregister the panic notifier before tearing down the debugfs and
console log state.
This issue was found by a static analysis tool.
Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://lore.kernel.org/r/f3ab74ef8034be63bb45a325f3d54656d658817f.1785320940.git.getshell@seu.edu.cn
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Add a dedicated error label for failures after successful console log
setup.
Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://lore.kernel.org/r/c00974953a1b952f51f0f021d7f9fad134159909.1785320940.git.getshell@seu.edu.cn
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Extract the EC feature-reading logic from cros_ec_check_features() into
cros_ec_read_features() helper function.
Currently, cros_ec_check_features() swallows command transfer errors. By
isolating the transaction logic into an explicit helper that returns the
actual transfer error code, subsequent callers (such as the cros_ec_dev
driver during device probing) can catch a read error.
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260608211518.2214740-2-akuchynski@chromium.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_threaded_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
Link: https://lore.kernel.org/r/20260717112103.213017-3-panchuang@vivo.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Commit 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported
sensor number") evaluated the `sensor_num` against the bounds limit even
for timestamp events. A timestamp event typically has a `sensor_num` of
0xff [1], causing the driver to flag it as invalid and skip to the next
event.
As a result, we'd see a flooding of "Invalid sensor number 255 from EC"
warning logs and these timestamp events were being dropped.
Move the bounds-check into cros_ec_sensor_ring_process_event() and
evaluate it only after standalone timestamp events have already been
processed and returned early.
[1] https://crrev.com/219ca6ef82ba266da788b673ee4ad50bd3ea1285/common/motion_sense_fifo.c#427
Fixes: 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported sensor number")
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20260715024454.4127571-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
files)
Replace the #include of <linux/mod_devicetable.h> by the more specific
<linux/device-id/*.h> where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
`max_response` and `sensor_num` are read from different EC commands:
- `max_response` is from cros_ec_get_proto_info().
ec_dev->max_response = info->max_response_packet_size -
sizeof(struct ec_host_response);
- `sensor_num` is from cros_ec_get_sensor_count().
sensor_num = cros_ec_get_sensor_count(ec);
With a malfunctioning EC firmware, it is possible that the `msg->insize`
(i.e., `fifo_info_length` in the context) could be clamped in
cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`.
int fifo_info_length =
sizeof(struct ec_response_motion_sense_fifo_info) +
sizeof(u16) * sensorhub->sensor_num;
This means the number of read bytes could be less than expected. As a
result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler()
overreads the `resp->fifo_info` buffer.
Check the return value of cros_ec_cmd_xfer_status() and abort if the
number of bytes read does not match the expected length.
Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20260702082745.1014968-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
cros_typec_register_partner_pdos() copies the partner PDOs from the EC
TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array.
memcpy(caps_desc.pdo, resp->source_cap_pdos,
sizeof(u32) * resp->source_cap_count);
...
memcpy(caps_desc.pdo, resp->sink_cap_pdos,
sizeof(u32) * resp->sink_cap_count);
PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields
from the EC. The only check is that they are not both zero. If either is
larger than 7, the memcpy writes past the end of the array on the stack.
A count of 255 overflows it by about 1 KB. The EC source arrays are only
seven entries wide. A larger count reads past them too.
The ChromeOS EC firmware caps these counts today, so a compliant setup
does not hit this. The kernel should still validate these values rather
than trust them.
Validate the counts in cros_typec_register_partner_pdos() next to the
memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS.
The rest of cros_typec_handle_status() still runs so events are handled
and cleared.
Fixes: 348a2e8c93d3 ("platform/chrome: cros_ec_typec: Register partner PDOs")
Suggested-by: Andrei Kuchynski <akuchynski@chromium.org>
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Andrei Kuchynski <akuchynski@chromium.org>
Link: https://lore.kernel.org/r/20260625130056.3378097-1-maoyixie.tju@gmail.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
The trackpad power supply on Spherion is the system common 3.3V power
rail. This is always on as long as the main processor is running.
Switch to the dumb trackpad prober since it does not need to manage
the power rail.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20260625060859.1020483-1-wenst@chromium.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
The drivers explicitly set the .driver_data member of struct
platform_device_id to zero without relying on that value. Drop these
unused assignments.
While touching these arrays use a single space in the list terminator
consistently.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/5b72bac661bdf1c874bea4b91ce3c2eccc84bba1.1781690554.git.u.kleine-koenig@baylibre.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Each EC FIFO event carries an 8-bit sensor number (in->sensor_num).
cros_ec_sensorhub_ring_handler() validates the FIFO event count, the
per-read count and the ring bound, but not the sensor number, which
cros_ec_sensor_ring_process_event() then uses unchecked to index
sensorhub->batch_state[] - allocated with only sensorhub->sensor_num
entries. A sensor number of sensor_num or larger is an out-of-bounds
read and write of batch_state[].
Validate the sensor number in the ring handler, where each event is read
from the EC, and drop a malformed event before it is used.
Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Link: https://lore.kernel.org/r/20260618-b4-disp-adb3f790-v3-1-3a164ed63cbd@proton.me
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Both ARM and ARM64 which are a dependency for CHROME_PLATFORMS have
seldomly used big-endian variants.
The ChromeOS EC framework and drivers are written under the assumption
that they will be running on a little-endian systems. Code which would
be broken on big-endian can be found trivially.
Some examples:
cros_ec.c: suspend_params.sleep_timeout_ms = ec_dev->suspend_timeout_ms
cros_ec_debugfs.c: resp->time_since_ec_boot_ms
cros_ec_wdt.c: arg.req.reboot_timeout_sec = wdd->timeout
Prevent the build for big-endian systems.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20260531-cros-big-endian-v1-2-0cc90f39c636@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
CROS_EC depends on CHROME_PLATFORMS which already declares these
dependencies.
Remove the duplication.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20260531-cros-big-endian-v1-1-0cc90f39c636@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Introduce a rwsem for protecting `ec_dev` to prevent Use-After-Free on
the `ec_dev`.
- Writers: In driver's probe() and remove().
- Readers: In file operations.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260525052654.4076429-5-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Introduce an event relayer mechanism. Instead of each open file
registering directly with `ec_dev->event_notifier`, the platform device
registers a single relayer notifier. Individual files then register
with a local subscribers list in `chardev_pdata`.
This allows the driver to safely disconnect from the event chain
`ec_dev->event_notifier` during cros_ec_chardev_remove(), preventing
events from being delivered to open files after the device is removed,
while still allowing those files to be closed safely later.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260525052654.4076429-4-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Move `ec_dev` and `cmd_offset` from `chardev_priv` to `chardev_pdata` as
they are per-device properties but not per-open-file properties.
Hold a reference to `chardev_pdata` for each open file to ensure the
data remains valid even if the underlying platform device is removed.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260525052654.4076429-3-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Introduce struct chardev_pdata to hold platform driver data.
The platform driver data is allocated by kzalloc() instead of devm
variant, allowing for managed cleanup that can eventually extend beyond
device removal if files are still open.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260525052654.4076429-2-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20260519150819.1591409-2-u.kleine-koenig@baylibre.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
wilco_ec event driver.
Fixes: 27d58498f690 ("platform/chrome: wilco_ec: event: Convert to a platform driver")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/2076666.usQuhbGJ8B@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
chromeos_tbmc driver.
Fixes: a2676ead257f ("platform/chrome: chromeos_tbmc: Convert to a platform driver")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/1875121.VLH7GnMWUR@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
chromeos_privacy_screen driver.
Fixes: d3c2872ae323 ("platform/chrome: Convert ChromeOS privacy-screen driver to platform")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/3357444.5fSG56mABF@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
The ifdeffery is unnecessary, as the compiler can already optimize away
all of the mfd-specific code based on the IS_ENABLED() in
keyboard_led_is_mfd_device().
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20260404-cros_kbd_led-cleanup-v1-3-0dc1100d54e3@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Make the code simpler to read by passing the 'struct keyboard_led' as
a parameter to the 'init' callbacks instead of relying on the platform
device driver data.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20260404-cros_kbd_led-cleanup-v1-2-0dc1100d54e3@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
The maximum brightness is always 100. There is no need to read that from
the driver data.
Remove the superfluous driver data.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20260404-cros_kbd_led-cleanup-v1-1-0dc1100d54e3@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
A race condition exists between the probe of cros-ec-sysfs and
cros-ec-sensorhub.
The `kb_wake_angle` attribute should only be visible if the sensor hub
detects two or more accelerometers. If cros_ec_sysfs_probe() runs
before cros_ec_sensorhub_register() completes sensor enumeration, the
sysfs attributes are created while `has_kb_wake_angle` is still false,
hiding `kb_wake_angle` incorrectly.
Store the created attribute group pointer in `ec_dev->group`. When
the sensor hub completes sensor enumeration, it checks for this group
and calls sysfs_update_group() to notify the sysfs core to re-evaluate
attribute visibility. This ensures the `kb_wake_angle` attribute
visibility is correctly updated regardless of the driver probe order.
Co-developed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20260407102615.1605317-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
cros_typec_register_thunderbolt() missed initializing the `adata->lock`
mutex. This leads to a NULL dereference when the mutex is later
acquired (e.g. in cros_typec_altmode_work()).
Initialize the mutex in cros_typec_register_thunderbolt() to fix the
issue.
Cc: stable@vger.kernel.org
Fixes: 3b00be26b16a ("platform/chrome: cros_ec_typec: Thunderbolt support")
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Link: https://lore.kernel.org/r/20260505053403.3335740-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Simplify the driver by using devm interfaces, which allow to drop
probe() error paths and the remove() callback.
Change is not equivalent in the workqueue itself: use non-legacy API
which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is
used to update logs, thus there is no point to run it for memory
reclaim.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20260305-workqueue-devm-v2-10-66a38741c652@oss.qualcomm.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
In all cases in which a struct acpi_driver is used for binding a driver
to an ACPI device object, a corresponding platform device is created by
the ACPI core and that device is regarded as a proper representation of
underlying hardware. Accordingly, a struct platform_driver should be
used by driver code to bind to that device. There are multiple reasons
why drivers should not bind directly to ACPI device objects [1].
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ChromeOS Wilco Embedded Controller event
ACPI driver to a platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/9600287.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
To facilitate subsequent conversion of the driver to a platform one,
make it install an ACPI notify handler directly instead of using
a .notify() callback in struct acpi_driver.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/7931926.EvYhyI6sBW@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
In all cases in which a struct acpi_driver is used for binding a driver
to an ACPI device object, a corresponding platform device is created by
the ACPI core and that device is regarded as a proper representation of
underlying hardware. Accordingly, a struct platform_driver should be
used by driver code to bind to that device. There are multiple reasons
why drivers should not bind directly to ACPI device objects [1].
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ChromeOS tablet mode change (TBMC) ACPI
driver to a platform one.
After this change, the subordinate input device and wakeup source class
device will be registered under the platform device used for driver
binding instead of its ACPI companion.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/10827297.nUPlyArG6x@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
To facilitate subsequent conversion of the driver to a platform one,
make it install an ACPI notify handler directly instead of using
a .notify() callback in struct acpi_driver.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/3413961.aeNJFYEL58@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
The wakeup source added by device_init_wakeup() in chromeos_tbmc_add()
needs to be dropped during driver removal, so add a .remove() callback
to the driver for this purpose.
Fixes: 0144c00ed86b ("platform/chrome: chromeos_tbmc: Report wake events")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/6151957.MhkbZ0Pkbq@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
In all cases in which a struct acpi_driver is used for binding a driver
to an ACPI device object, a corresponding platform device is created by
the ACPI core and that device is regarded as a proper representation of
underlying hardware. Accordingly, a struct platform_driver should be
used by driver code to bind to that device. There are multiple reasons
why drivers should not bind directly to ACPI device objects [1].
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ChromeOS privacy-screen ACPI driver
to a platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/1963835.tdWV9SEqCh@rafael.j.wysocki
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Enabling tracing with:
echo 1 > /sys/kernel/debug/tracing/events/cros_ec/cros_ec_request_start/enable
To monitor the command and response size. The defaults are 194 and 128 respectively:
cros_ec_request_start: version: 0, offset: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 194, insize: 128
Reduce the sizes to the expected subcommands.
Signed-off-by: Gwendal Grignou <gwendal@google.com>
Link: https://lore.kernel.org/r/20260204035036.697955-1-gwendal@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
This converts some of the visually simpler cases that have been split
over multiple lines. I only did the ones that are easy to verify the
resulting diff by having just that final GFP_KERNEL argument on the next
line.
Somebody should probably do a proper coccinelle script for this, but for
me the trivial script actually resulted in an assertion failure in the
middle of the script. I probably had made it a bit _too_ trivial.
So after fighting that far a while I decided to just do some of the
syntactically simpler cases with variations of the previous 'sed'
scripts.
The more syntactically complex multi-line cases would mostly really want
whitespace cleanup anyway.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This is the exact same thing as the 'alloc_obj()' version, only much
smaller because there are a lot fewer users of the *alloc_flex()
interface.
As with alloc_obj() version, this was done entirely with mindless brute
force, using the same script, except using 'flex' in the pattern rather
than 'objs*'.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt updates from Greg KH:
"Here is the "big" set of USB and Thunderbolt driver updates for
7.0-rc1. Overall more lines were removed than added, thanks to
dropping the obsolete isp1362 USB host controller driver, always a
nice change.
Other than that, nothing major happening here, highlights are:
- lots of dwc3 driver updates and new hardware support added
- usb gadget function driver updates
- usb phy driver updates
- typec driver updates and additions
- USB rust binding updates for syntax and formatting changes
- more usb serial device ids added
- other smaller USB core and driver updates and additions
All of these have been in linux-next for a long time, with no reported
problems"
* tag 'usb-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (77 commits)
usb: typec: ucsi: Add Thunderbolt alternate mode support
usb: typec: hd3ss3220: Check if regulator needs to be switched
usb: phy: tegra: parametrize PORTSC1 register offset
usb: phy: tegra: parametrize HSIC PTS value
usb: phy: tegra: return error value from utmi_wait_register
usb: phy: tegra: cosmetic fixes
dt-bindings: usb: renesas,usbhs: Add RZ/G3E SoC support
usb: dwc2: fix resume failure if dr_mode is host
usb: cdns3: fix role switching during resume
usb: dwc3: gadget: Move vbus draw to workqueue context
USB: serial: option: add Telit FN920C04 RNDIS compositions
usb: dwc3: Log dwc3 address in traces
usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN
usb: phy: tegra: add HSIC support
usb: phy: tegra: use phy type directly
usb: typec: ucsi: Enforce mode selection for cros_ec_ucsi
usb: typec: ucsi: Support mode selection to activate altmodes
usb: typec: Introduce mode_selection bit
usb: typec: Implement mode selection
usb: typec: Expose alternate mode priority via sysfs
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Tzung-Bi Shih:
"New cros_ec_lightbar features:
- Report the number of exposed LED segments via sysfs
- Support large sequence of program to be transmitted
Fixes:
- Don't touch fwnode_handle::dev which is a private field
- Fix wrong assignment for response size in cros_ec_lightbar
Cleanups:
- Use acpi_get_local_u64_address() helper"
* tag 'chrome-platform-v7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: lightbar: Use flexible array member
platform/chrome: lightbar: Fix lightbar_program_ex alignment
platform/chrome: lightbar: Add support for large sequence
platform/chrome: lightbar: Report number of segments
platform/chrome: cros_ec_lightbar: Fix response size initialization
platform/chrome: cros_typec_switch: Use acpi_get_local_u64_address()
platform/chrome: cros_typec_switch: Don't touch struct fwnode_handle::dev
|
|
Current sequences are limited to 192 bytes. Increase support to whatever
the EC support. If the sequence is too long, the EC will return an
OVERFLOW error.
Test: Check sending a large sequence is received by the EC.
Signed-off-by: Gwendal Grignou <gwendal@google.com>
Link: https://lore.kernel.org/r/20260130081351.487517-2-gwendal@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Add attribue `num_segments` to return the number of exposed LED segments
in the lightbar. It can be smaller than the number of physical leds in
the lightbar.
Test: Check the attribute is present and returns a value when read.
Signed-off-by: Gwendal Grignou <gwendal@google.com>
Link: https://lore.kernel.org/r/20260130081351.487517-1-gwendal@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Commit 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce
ligthbar get version command") meant to set smaller values for both
request and response sizes.
However, it incorrectly assigned the response size to the `result` field
instead of `insize`. Fix it.
Reported-by: Gwendal Grignou <gwendal@google.com>
Closes: https://lore.kernel.org/chrome-platform/CAMHSBOVrrYaB=1nEqZk09VkczCrj=6B-P8Fe29TpPdSDgT2CCQ@mail.gmail.com
Fixes: 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command")
Link: https://lore.kernel.org/r/20260130040335.361997-1-tzungbi@kernel.org
Reviewed-by: Gwendal Grignou <gwendal@google.com>
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
This flag specifies that the Embedded Controller (EC) must receive explicit
approval from the Application Processor (AP) before initiating Type-C
alternate modes or USB4 mode.
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Link: https://patch.msgid.link/20260119131824.2529334-3-akuchynski@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Now we have a helper so there's no need to open-code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20260120131413.1697891-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
The 'dev' field in struct fwnode is special and related to device links,
There no driver should use it for printing messages. Fix incorrect use
of private field.
Fixes: affc804c44c8 ("platform/chrome: cros_typec_switch: Add switch driver")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20260120131413.1697891-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
