| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/18 07:20 | flow | patch-triage |
1mArgs:null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"KMSANReasoning": "",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies `bma400_probe` in `drivers/iio/accel/bma400_core.c`, which is the probe routine for the Bosch BMA400 accelerometer driver (interfaced over I2C or SPI). This driver requires physical BMA400 hardware (or dedicated hardware emulation responding to register reads such as BMA400_CHIP_ID_REG) which is not emulated or available in standard QEMU/GCE virtualized fuzzing environments. Consequently, the modified code is structurally unreachable during fuzzing.",
"WorthFuzzing": false
} |
| 1/1 | 2026/09/18 07:20 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit acdc84a964d4a3ad56b815cb035c17726e0db7a7\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Fri Sep 18 07:20:01 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/iio/accel/bma400_core.c b/drivers/iio/accel/bma400_core.c\nindex 05f72707f8306..a5889b67585e8 100644\n--- a/drivers/iio/accel/bma400_core.c\n+++ b/drivers/iio/accel/bma400_core.c\n@@ -1783,7 +1783,6 @@ int bma400_probe(struct device *dev, struct regmap *regmap, int irq,\n \t\t\treturn dev_err_probe(data-\u003edev, ret,\n \t\t\t\t\t \"iio trigger register fail\\n\");\n \n-\t\tindio_dev-\u003etrig = iio_trigger_get(data-\u003etrig);\n \t\tret = devm_request_threaded_irq(dev, irq, NULL,\n \t\t\t\t\t\t\u0026bma400_interrupt,\n \t\t\t\t\t\tIRQF_TRIGGER_RISING | IRQF_ONESHOT,\n@@ -1799,6 +1798,9 @@ int bma400_probe(struct device *dev, struct regmap *regmap, int irq,\n \t\treturn dev_err_probe(data-\u003edev, ret,\n \t\t\t\t \"iio triggered buffer setup failed\\n\");\n \n+\tif (irq \u003e 0)\n+\t\tindio_dev-\u003etrig = iio_trigger_get(data-\u003etrig);\n+\n \treturn devm_iio_device_register(dev, indio_dev);\n }\n EXPORT_SYMBOL_NS(bma400_probe, \"IIO_BMA400\");\n"
} |
| 2/1 | 2026/09/18 07:20 | agent | patch-evaluator |
1mModel:core Args: null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies `bma400_probe` in `drivers/iio/accel/bma400_core.c`, which is the probe routine for the Bosch BMA400 accelerometer driver (interfaced over I2C or SPI). This driver requires physical BMA400 hardware (or dedicated hardware emulation responding to register reads such as BMA400_CHIP_ID_REG) which is not emulated or available in standard QEMU/GCE virtualized fuzzing environments. Consequently, the modified code is structurally unreachable during fuzzing.",
"WorthFuzzing": false
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit acdc84a964d4a3ad56b815cb035c17726e0db7a7
Author: syz-cluster <triage@syzkaller.com>
Date: Fri Sep 18 07:20:01 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/iio/accel/bma400_core.c b/drivers/iio/accel/bma400_core.c
index 05f72707f8306..a5889b67585e8 100644
--- a/drivers/iio/accel/bma400_core.c
+++ b/drivers/iio/accel/bma400_core.c
@@ -1783,7 +1783,6 @@ int bma400_probe(struct device *dev, struct regmap *regmap, int irq,
return dev_err_probe(data->dev, ret,
"iio trigger register fail\n");
- indio_dev->trig = iio_trigger_get(data->trig);
ret = devm_request_threaded_irq(dev, irq, NULL,
&bma400_interrupt,
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
@@ -1799,6 +1798,9 @@ int bma400_probe(struct device *dev, struct regmap *regmap, int irq,
return dev_err_probe(data->dev, ret,
"iio triggered buffer setup failed\n");
+ if (irq > 0)
+ indio_dev->trig = iio_trigger_get(data->trig);
+
return devm_iio_device_register(dev, indio_dev);
}
EXPORT_SYMBOL_NS(bma400_probe, "IIO_BMA400");
|
| 3/2 | 2026/09/18 07:20 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 3088 output: 33 thoughts: 81 Thoughts: **Analyzing the BMA400 Accelerometer Driver** Okay, here's what's running through my head. This patch is nestled within `drivers/iio/accel/bma400_core.c`. My immediate thought is, "Right, let's figure out the scope of this driver." I need to understand what the `bma400` is actually talking to: Is this something easily reproduced in my standard virtualized environment setups, like QEMU? Or is it more of a USB, I2C, or SPI device? Understanding the connection protocol is critical. I'm thinking, "Time to dive into the `bma400` code." I need a quick overview of the relevant files and drivers. I'll probably use my grepper skills to find anything related to "bma400" or just start reading some files to get a feel for the lay of the land. I need to quickly grasp the architecture and potential dependencies of this driver to assess the impact of this patch. |
| 4/2 | 2026/09/18 07:20 | tool | grepper |
0mArgs:{
"Expression": "bma400",
"PathPrefix": "drivers/iio/accel/"
}Results: {
"Output": "\nFull output is too long, showing 500 out of 689 lines.\nUse more precise expression if possible.\n\ndrivers/iio/accel/Kconfig=248=config BMA400\n--\ndrivers/iio/accel/Kconfig-259-\t To compile this driver as a module, choose M here: the\ndrivers/iio/accel/Kconfig:260:\t module will be called bma400_core and you will also get\ndrivers/iio/accel/Kconfig:261:\t bma400_i2c if I2C is enabled and bma400_spi if SPI is\ndrivers/iio/accel/Kconfig-262-\t enabled.\n--\ndrivers/iio/accel/Makefile=30=obj-$(CONFIG_BMA220_SPI) += bma220_spi.o\ndrivers/iio/accel/Makefile:31:obj-$(CONFIG_BMA400) += bma400_core.o\ndrivers/iio/accel/Makefile:32:obj-$(CONFIG_BMA400_I2C) += bma400_i2c.o\ndrivers/iio/accel/Makefile:33:obj-$(CONFIG_BMA400_SPI) += bma400_spi.o\ndrivers/iio/accel/Makefile-34-obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o\n--\ndrivers/iio/accel/bma400.h-2-/*\ndrivers/iio/accel/bma400.h:3: * Register constants and other forward declarations needed by the bma400\ndrivers/iio/accel/bma400.h-4- * sources.\n--\ndrivers/iio/accel/bma400.h-97-\ndrivers/iio/accel/bma400.h:98:enum bma400_generic_intr {\ndrivers/iio/accel/bma400.h-99-\tBMA400_GEN1_INTR = 0x1,\n--\ndrivers/iio/accel/bma400.h-127-\ndrivers/iio/accel/bma400.h:128:enum bma400_accel_data_src {\ndrivers/iio/accel/bma400.h-129-\tACCEL_FILT1 = 0x0,\n--\ndrivers/iio/accel/bma400.h-132-\ndrivers/iio/accel/bma400.h:133:enum bma400_ref_updt_mode {\ndrivers/iio/accel/bma400.h-134-\tBMA400_REF_MANUAL_UPDT_MODE = 0x0,\n--\ndrivers/iio/accel/bma400.h-143-\ndrivers/iio/accel/bma400.h:144:enum bma400_genintr_acceleval_axescomb {\ndrivers/iio/accel/bma400.h-145-\tBMA400_EVAL_X_OR_Y_OR_Z = 0x0,\n--\ndrivers/iio/accel/bma400.h-148-\ndrivers/iio/accel/bma400.h:149:enum bma400_detect_criterion {\ndrivers/iio/accel/bma400.h-150-\tBMA400_DETECT_INACTIVITY = 0x0,\n--\ndrivers/iio/accel/bma400.h-176- *\ndrivers/iio/accel/bma400.h:177: * Scale values for +-2g, +-4g, +-8g and +-16g are populated into bma400_scales\ndrivers/iio/accel/bma400.h-178- * array by left shifting BMA400_SCALE_MIN.\n--\ndrivers/iio/accel/bma400.h-186-\ndrivers/iio/accel/bma400.h:187:extern const struct regmap_config bma400_regmap_config;\ndrivers/iio/accel/bma400.h-188-\ndrivers/iio/accel/bma400.h:189:int bma400_probe(struct device *dev, struct regmap *regmap, int irq,\ndrivers/iio/accel/bma400.h-190-\t\t const char *name);\n--\ndrivers/iio/accel/bma400_core.c-34-\ndrivers/iio/accel/bma400_core.c:35:#include \"bma400.h\"\ndrivers/iio/accel/bma400_core.c-36-\n--\ndrivers/iio/accel/bma400_core.c-41- */\ndrivers/iio/accel/bma400_core.c:42:static int bma400_scales[8];\ndrivers/iio/accel/bma400_core.c-43-\n--\ndrivers/iio/accel/bma400_core.c-47- */\ndrivers/iio/accel/bma400_core.c:48:static int bma400_sample_freqs[14];\ndrivers/iio/accel/bma400_core.c-49-\ndrivers/iio/accel/bma400_core.c:50:static const int bma400_osr_range[] = { 0, 1, 3 };\ndrivers/iio/accel/bma400_core.c-51-\n--\ndrivers/iio/accel/bma400_core.c=66=static int double_tap2_min_delay[BMA400_TAP_TIM_LIST_LEN] = {\n--\ndrivers/iio/accel/bma400_core.c-73-/* See the ACC_CONFIG0 section of the datasheet */\ndrivers/iio/accel/bma400_core.c:74:enum bma400_power_mode {\ndrivers/iio/accel/bma400_core.c-75-\tPOWER_MODE_SLEEP = 0x00,\n--\ndrivers/iio/accel/bma400_core.c-80-\ndrivers/iio/accel/bma400_core.c:81:enum bma400_scan {\ndrivers/iio/accel/bma400_core.c-82-\tBMA400_ACCL_X,\n--\ndrivers/iio/accel/bma400_core.c-87-\ndrivers/iio/accel/bma400_core.c:88:struct bma400_sample_freq {\ndrivers/iio/accel/bma400_core.c-89-\tint hz;\n--\ndrivers/iio/accel/bma400_core.c-92-\ndrivers/iio/accel/bma400_core.c:93:enum bma400_activity {\ndrivers/iio/accel/bma400_core.c-94-\tBMA400_STILL,\n--\ndrivers/iio/accel/bma400_core.c-98-\ndrivers/iio/accel/bma400_core.c:99:struct bma400_data {\ndrivers/iio/accel/bma400_core.c-100-\tstruct device *dev;\n--\ndrivers/iio/accel/bma400_core.c-103-\tstruct iio_mount_matrix orientation;\ndrivers/iio/accel/bma400_core.c:104:\tenum bma400_power_mode power_mode;\ndrivers/iio/accel/bma400_core.c:105:\tstruct bma400_sample_freq sample_freq;\ndrivers/iio/accel/bma400_core.c-106-\tint oversampling_ratio;\n--\ndrivers/iio/accel/bma400_core.c-123-\ndrivers/iio/accel/bma400_core.c:124:struct bma400_genintr_info {\ndrivers/iio/accel/bma400_core.c:125:\tenum bma400_generic_intr genintr;\ndrivers/iio/accel/bma400_core.c-126-\tunsigned int intrmask;\ndrivers/iio/accel/bma400_core.c-127-\tenum iio_event_direction dir;\ndrivers/iio/accel/bma400_core.c:128:\tenum bma400_detect_criterion detect_mode;\ndrivers/iio/accel/bma400_core.c-129-};\n--\ndrivers/iio/accel/bma400_core.c-131-/* Lookup struct for determining GEN1/GEN2 based on dir */\ndrivers/iio/accel/bma400_core.c:132:static const struct bma400_genintr_info bma400_genintrs[] = {\ndrivers/iio/accel/bma400_core.c-133-\t[IIO_EV_DIR_RISING] = {\n--\ndrivers/iio/accel/bma400_core.c-146-\ndrivers/iio/accel/bma400_core.c:147:static inline const struct bma400_genintr_info *\ndrivers/iio/accel/bma400_core.c:148:get_bma400_genintr_info(enum iio_event_direction dir)\ndrivers/iio/accel/bma400_core.c-149-{\n--\ndrivers/iio/accel/bma400_core.c-152-\tcase IIO_EV_DIR_FALLING:\ndrivers/iio/accel/bma400_core.c:153:\t\treturn \u0026bma400_genintrs[dir];\ndrivers/iio/accel/bma400_core.c-154-\tdefault:\n--\ndrivers/iio/accel/bma400_core.c-158-\ndrivers/iio/accel/bma400_core.c:159:static bool bma400_is_writable_reg(struct device *dev, unsigned int reg)\ndrivers/iio/accel/bma400_core.c-160-{\n--\ndrivers/iio/accel/bma400_core.c-191-\ndrivers/iio/accel/bma400_core.c:192:static bool bma400_is_volatile_reg(struct device *dev, unsigned int reg)\ndrivers/iio/accel/bma400_core.c-193-{\n--\ndrivers/iio/accel/bma400_core.c-223-\ndrivers/iio/accel/bma400_core.c:224:const struct regmap_config bma400_regmap_config = {\ndrivers/iio/accel/bma400_core.c-225-\t.reg_bits = 8,\n--\ndrivers/iio/accel/bma400_core.c-228-\t.cache_type = REGCACHE_MAPLE,\ndrivers/iio/accel/bma400_core.c:229:\t.writeable_reg = bma400_is_writable_reg,\ndrivers/iio/accel/bma400_core.c:230:\t.volatile_reg = bma400_is_volatile_reg,\ndrivers/iio/accel/bma400_core.c-231-};\ndrivers/iio/accel/bma400_core.c:232:EXPORT_SYMBOL_NS(bma400_regmap_config, \"IIO_BMA400\");\ndrivers/iio/accel/bma400_core.c-233-\ndrivers/iio/accel/bma400_core.c=234=static const struct iio_mount_matrix *\ndrivers/iio/accel/bma400_core.c:235:bma400_accel_get_mount_matrix(const struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-236-\t\t\t const struct iio_chan_spec *chan)\ndrivers/iio/accel/bma400_core.c-237-{\ndrivers/iio/accel/bma400_core.c:238:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-239-\n--\ndrivers/iio/accel/bma400_core.c-242-\ndrivers/iio/accel/bma400_core.c:243:static const struct iio_chan_spec_ext_info bma400_ext_info[] = {\ndrivers/iio/accel/bma400_core.c:244:\tIIO_MOUNT_MATRIX(IIO_SHARED_BY_DIR, bma400_accel_get_mount_matrix),\ndrivers/iio/accel/bma400_core.c-245-\t{ }\n--\ndrivers/iio/accel/bma400_core.c-247-\ndrivers/iio/accel/bma400_core.c:248:static const struct iio_event_spec bma400_step_detect_event = {\ndrivers/iio/accel/bma400_core.c-249-\t.type = IIO_EV_TYPE_CHANGE,\n--\ndrivers/iio/accel/bma400_core.c-253-\ndrivers/iio/accel/bma400_core.c:254:static const struct iio_event_spec bma400_activity_event = {\ndrivers/iio/accel/bma400_core.c-255-\t.type = IIO_EV_TYPE_CHANGE,\n--\ndrivers/iio/accel/bma400_core.c-259-\ndrivers/iio/accel/bma400_core.c:260:static const struct iio_event_spec bma400_accel_event[] = {\ndrivers/iio/accel/bma400_core.c-261-\t{\n--\ndrivers/iio/accel/bma400_core.c=305=static ssize_t in_accel_gesture_tap_maxtomin_time_show(struct device *dev,\n--\ndrivers/iio/accel/bma400_core.c-309-\tstruct iio_dev *indio_dev = dev_to_iio_dev(dev);\ndrivers/iio/accel/bma400_core.c:310:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-311-\tint ret, reg_val, raw, vals[2];\n--\ndrivers/iio/accel/bma400_core.c=324=static ssize_t in_accel_gesture_tap_maxtomin_time_store(struct device *dev,\n--\ndrivers/iio/accel/bma400_core.c-328-\tstruct iio_dev *indio_dev = dev_to_iio_dev(dev);\ndrivers/iio/accel/bma400_core.c:329:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-330-\tint ret, val_int, val_fract, raw;\n--\ndrivers/iio/accel/bma400_core.c=373=static IIO_CONST_ATTR(in_accel_gesture_tap_value_available, \"0 1 2 3 4 5 6 7\");\ndrivers/iio/accel/bma400_core.c-374-\ndrivers/iio/accel/bma400_core.c:375:static struct attribute *bma400_event_attributes[] = {\ndrivers/iio/accel/bma400_core.c-376-\t\u0026iio_const_attr_in_accel_gesture_tap_value_available.dev_attr.attr,\n--\ndrivers/iio/accel/bma400_core.c-383-\ndrivers/iio/accel/bma400_core.c:384:static const struct attribute_group bma400_event_attribute_group = {\ndrivers/iio/accel/bma400_core.c:385:\t.attrs = bma400_event_attributes,\ndrivers/iio/accel/bma400_core.c-386-};\n--\ndrivers/iio/accel/bma400_core.c-398-\t\tBIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \\\ndrivers/iio/accel/bma400_core.c:399:\t.ext_info = bma400_ext_info, \\\ndrivers/iio/accel/bma400_core.c-400-\t.scan_index = _index,\t\\\n--\ndrivers/iio/accel/bma400_core.c-406-\t},\t\t\t\t\\\ndrivers/iio/accel/bma400_core.c:407:\t.event_spec = bma400_accel_event,\t\t\t\\\ndrivers/iio/accel/bma400_core.c:408:\t.num_event_specs = ARRAY_SIZE(bma400_accel_event)\t\\\ndrivers/iio/accel/bma400_core.c-409-}\n--\ndrivers/iio/accel/bma400_core.c-416-\t.scan_index = -1, /* No buffer support */\t\t\\\ndrivers/iio/accel/bma400_core.c:417:\t.event_spec = \u0026bma400_activity_event,\t\t\t\\\ndrivers/iio/accel/bma400_core.c-418-\t.num_event_specs = 1,\t\t\t\t\t\\\n--\ndrivers/iio/accel/bma400_core.c-420-\ndrivers/iio/accel/bma400_core.c:421:static const struct iio_chan_spec bma400_channels[] = {\ndrivers/iio/accel/bma400_core.c-422-\tBMA400_ACC_CHANNEL(0, X),\n--\ndrivers/iio/accel/bma400_core.c-441-\t\t.scan_index = -1, /* No buffer support */\ndrivers/iio/accel/bma400_core.c:442:\t\t.event_spec = \u0026bma400_step_detect_event,\ndrivers/iio/accel/bma400_core.c-443-\t\t.num_event_specs = 1,\n--\ndrivers/iio/accel/bma400_core.c-450-\ndrivers/iio/accel/bma400_core.c:451:static int bma400_get_temp_reg(struct bma400_data *data, int *val, int *val2)\ndrivers/iio/accel/bma400_core.c-452-{\n--\ndrivers/iio/accel/bma400_core.c-473-\ndrivers/iio/accel/bma400_core.c:474:static int bma400_get_accel_reg(struct bma400_data *data,\ndrivers/iio/accel/bma400_core.c-475-\t\t\t\tconst struct iio_chan_spec *chan,\n--\ndrivers/iio/accel/bma400_core.c-509-\ndrivers/iio/accel/bma400_core.c:510:static void bma400_output_data_rate_from_raw(int raw, unsigned int *val,\ndrivers/iio/accel/bma400_core.c-511-\t\t\t\t\t unsigned int *val2)\n--\ndrivers/iio/accel/bma400_core.c-519-\ndrivers/iio/accel/bma400_core.c:520:static int bma400_get_accel_output_data_rate(struct bma400_data *data)\ndrivers/iio/accel/bma400_core.c-521-{\n--\ndrivers/iio/accel/bma400_core.c-531-\t\t */\ndrivers/iio/accel/bma400_core.c:532:\t\tbma400_output_data_rate_from_raw(BMA400_ACC_CONFIG1_ODR_LP_RAW,\ndrivers/iio/accel/bma400_core.c-533-\t\t\t\t\t\t \u0026data-\u003esample_freq.hz,\n--\ndrivers/iio/accel/bma400_core.c-551-\ndrivers/iio/accel/bma400_core.c:552:\t\tbma400_output_data_rate_from_raw(odr, \u0026data-\u003esample_freq.hz,\ndrivers/iio/accel/bma400_core.c-553-\t\t\t\t\t\t \u0026data-\u003esample_freq.uhz);\n--\ndrivers/iio/accel/bma400_core.c-568-\ndrivers/iio/accel/bma400_core.c:569:static int bma400_set_accel_output_data_rate(struct bma400_data *data,\ndrivers/iio/accel/bma400_core.c-570-\t\t\t\t\t int hz, int uhz)\n--\ndrivers/iio/accel/bma400_core.c-604-\ndrivers/iio/accel/bma400_core.c:605:\tbma400_output_data_rate_from_raw(idx, \u0026data-\u003esample_freq.hz,\ndrivers/iio/accel/bma400_core.c-606-\t\t\t\t\t \u0026data-\u003esample_freq.uhz);\n--\ndrivers/iio/accel/bma400_core.c-609-\ndrivers/iio/accel/bma400_core.c:610:static int bma400_get_accel_oversampling_ratio(struct bma400_data *data)\ndrivers/iio/accel/bma400_core.c-611-{\n--\ndrivers/iio/accel/bma400_core.c-653-\ndrivers/iio/accel/bma400_core.c:654:static int bma400_set_accel_oversampling_ratio(struct bma400_data *data,\ndrivers/iio/accel/bma400_core.c-655-\t\t\t\t\t int val)\n--\ndrivers/iio/accel/bma400_core.c-705-\ndrivers/iio/accel/bma400_core.c:706:static int bma400_accel_scale_to_raw(struct bma400_data *data,\ndrivers/iio/accel/bma400_core.c-707-\t\t\t\t unsigned int val)\n--\ndrivers/iio/accel/bma400_core.c-722-\ndrivers/iio/accel/bma400_core.c:723:static int bma400_get_accel_scale(struct bma400_data *data)\ndrivers/iio/accel/bma400_core.c-724-{\n--\ndrivers/iio/accel/bma400_core.c-741-\ndrivers/iio/accel/bma400_core.c:742:static int bma400_set_accel_scale(struct bma400_data *data, unsigned int val)\ndrivers/iio/accel/bma400_core.c-743-{\n--\ndrivers/iio/accel/bma400_core.c-751-\ndrivers/iio/accel/bma400_core.c:752:\traw = bma400_accel_scale_to_raw(data, val);\ndrivers/iio/accel/bma400_core.c-753-\tif (raw \u003c 0)\n--\ndrivers/iio/accel/bma400_core.c-765-\ndrivers/iio/accel/bma400_core.c:766:static int bma400_get_power_mode(struct bma400_data *data)\ndrivers/iio/accel/bma400_core.c-767-{\n--\ndrivers/iio/accel/bma400_core.c-780-\ndrivers/iio/accel/bma400_core.c:781:static int bma400_set_power_mode(struct bma400_data *data,\ndrivers/iio/accel/bma400_core.c:782:\t\t\t\t enum bma400_power_mode mode)\ndrivers/iio/accel/bma400_core.c-783-{\n--\ndrivers/iio/accel/bma400_core.c-810-\t */\ndrivers/iio/accel/bma400_core.c:811:\tbma400_get_accel_output_data_rate(data);\ndrivers/iio/accel/bma400_core.c:812:\tbma400_get_accel_oversampling_ratio(data);\ndrivers/iio/accel/bma400_core.c-813-\treturn 0;\n--\ndrivers/iio/accel/bma400_core.c-815-\ndrivers/iio/accel/bma400_core.c:816:static int bma400_enable_steps(struct bma400_data *data, int val)\ndrivers/iio/accel/bma400_core.c-817-{\n--\ndrivers/iio/accel/bma400_core.c-831-\ndrivers/iio/accel/bma400_core.c:832:static int bma400_get_steps_reg(struct bma400_data *data, int *val)\ndrivers/iio/accel/bma400_core.c-833-{\n--\ndrivers/iio/accel/bma400_core.c-849-\ndrivers/iio/accel/bma400_core.c:850:static void bma400_init_tables(void)\ndrivers/iio/accel/bma400_core.c-851-{\n--\ndrivers/iio/accel/bma400_core.c-854-\ndrivers/iio/accel/bma400_core.c:855:\tfor (i = 0; i + 1 \u003c ARRAY_SIZE(bma400_sample_freqs); i += 2) {\ndrivers/iio/accel/bma400_core.c-856-\t\traw = (i / 2) + 5;\ndrivers/iio/accel/bma400_core.c:857:\t\tbma400_output_data_rate_from_raw(raw, \u0026bma400_sample_freqs[i],\ndrivers/iio/accel/bma400_core.c:858:\t\t\t\t\t\t \u0026bma400_sample_freqs[i + 1]);\ndrivers/iio/accel/bma400_core.c-859-\t}\ndrivers/iio/accel/bma400_core.c-860-\ndrivers/iio/accel/bma400_core.c:861:\tfor (i = 0; i + 1 \u003c ARRAY_SIZE(bma400_scales); i += 2) {\ndrivers/iio/accel/bma400_core.c-862-\t\traw = i / 2;\ndrivers/iio/accel/bma400_core.c:863:\t\tbma400_scales[i] = 0;\ndrivers/iio/accel/bma400_core.c:864:\t\tbma400_scales[i + 1] = BMA400_ACC_SCALE_MIN \u003c\u003c raw;\ndrivers/iio/accel/bma400_core.c-865-\t}\n--\ndrivers/iio/accel/bma400_core.c-867-\ndrivers/iio/accel/bma400_core.c:868:static void bma400_power_disable(void *data_ptr)\ndrivers/iio/accel/bma400_core.c-869-{\ndrivers/iio/accel/bma400_core.c:870:\tstruct bma400_data *data = data_ptr;\ndrivers/iio/accel/bma400_core.c-871-\tint ret;\n--\ndrivers/iio/accel/bma400_core.c-873-\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:874:\tret = bma400_set_power_mode(data, POWER_MODE_SLEEP);\ndrivers/iio/accel/bma400_core.c-875-\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-880-\ndrivers/iio/accel/bma400_core.c:881:static enum iio_modifier bma400_act_to_mod(enum bma400_activity activity)\ndrivers/iio/accel/bma400_core.c-882-{\n--\ndrivers/iio/accel/bma400_core.c-894-\ndrivers/iio/accel/bma400_core.c:895:static int bma400_init(struct bma400_data *data)\ndrivers/iio/accel/bma400_core.c-896-{\n--\ndrivers/iio/accel/bma400_core.c-918-\ndrivers/iio/accel/bma400_core.c:919:\tret = bma400_get_power_mode(data);\ndrivers/iio/accel/bma400_core.c-920-\tif (ret) {\n--\ndrivers/iio/accel/bma400_core.c-925-\tif (data-\u003epower_mode != POWER_MODE_NORMAL) {\ndrivers/iio/accel/bma400_core.c:926:\t\tret = bma400_set_power_mode(data, POWER_MODE_NORMAL);\ndrivers/iio/accel/bma400_core.c-927-\t\tif (ret) {\n--\ndrivers/iio/accel/bma400_core.c-937-\ndrivers/iio/accel/bma400_core.c:938:\tret = devm_add_action_or_reset(data-\u003edev, bma400_power_disable, data);\ndrivers/iio/accel/bma400_core.c-939-\tif (ret)\n--\ndrivers/iio/accel/bma400_core.c-941-\ndrivers/iio/accel/bma400_core.c:942:\tbma400_init_tables();\ndrivers/iio/accel/bma400_core.c-943-\ndrivers/iio/accel/bma400_core.c:944:\tret = bma400_get_accel_output_data_rate(data);\ndrivers/iio/accel/bma400_core.c-945-\tif (ret)\n--\ndrivers/iio/accel/bma400_core.c-947-\ndrivers/iio/accel/bma400_core.c:948:\tret = bma400_get_accel_oversampling_ratio(data);\ndrivers/iio/accel/bma400_core.c-949-\tif (ret)\n--\ndrivers/iio/accel/bma400_core.c-951-\ndrivers/iio/accel/bma400_core.c:952:\tret = bma400_get_accel_scale(data);\ndrivers/iio/accel/bma400_core.c-953-\tif (ret)\n--\ndrivers/iio/accel/bma400_core.c-968-\ndrivers/iio/accel/bma400_core.c:969:static int bma400_read_raw(struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-970-\t\t\t struct iio_chan_spec const *chan, int *val,\n--\ndrivers/iio/accel/bma400_core.c-972-{\ndrivers/iio/accel/bma400_core.c:973:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-974-\tunsigned int activity;\n--\ndrivers/iio/accel/bma400_core.c-981-\t\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:982:\t\t\tret = bma400_get_temp_reg(data, val, val2);\ndrivers/iio/accel/bma400_core.c-983-\t\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-985-\t\tcase IIO_STEPS:\ndrivers/iio/accel/bma400_core.c:986:\t\t\treturn bma400_get_steps_reg(data, val);\ndrivers/iio/accel/bma400_core.c-987-\t\tcase IIO_ACTIVITY:\n--\ndrivers/iio/accel/bma400_core.c-996-\t\t\t */\ndrivers/iio/accel/bma400_core.c:997:\t\t\tif (chan-\u003echannel2 == bma400_act_to_mod(activity))\ndrivers/iio/accel/bma400_core.c-998-\t\t\t\t*val = 100;\n--\ndrivers/iio/accel/bma400_core.c-1006-\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:1007:\t\tret = bma400_get_accel_reg(data, chan, val);\ndrivers/iio/accel/bma400_core.c-1008-\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-1052-\ndrivers/iio/accel/bma400_core.c:1053:static int bma400_read_avail(struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-1054-\t\t\t struct iio_chan_spec const *chan,\n--\ndrivers/iio/accel/bma400_core.c-1060-\t\t*type = IIO_VAL_INT_PLUS_MICRO;\ndrivers/iio/accel/bma400_core.c:1061:\t\t*vals = bma400_scales;\ndrivers/iio/accel/bma400_core.c:1062:\t\t*length = ARRAY_SIZE(bma400_scales);\ndrivers/iio/accel/bma400_core.c-1063-\t\treturn IIO_AVAIL_LIST;\n--\ndrivers/iio/accel/bma400_core.c-1065-\t\t*type = IIO_VAL_INT;\ndrivers/iio/accel/bma400_core.c:1066:\t\t*vals = bma400_osr_range;\ndrivers/iio/accel/bma400_core.c:1067:\t\t*length = ARRAY_SIZE(bma400_osr_range);\ndrivers/iio/accel/bma400_core.c-1068-\t\treturn IIO_AVAIL_RANGE;\n--\ndrivers/iio/accel/bma400_core.c-1070-\t\t*type = IIO_VAL_INT_PLUS_MICRO;\ndrivers/iio/accel/bma400_core.c:1071:\t\t*vals = bma400_sample_freqs;\ndrivers/iio/accel/bma400_core.c:1072:\t\t*length = ARRAY_SIZE(bma400_sample_freqs);\ndrivers/iio/accel/bma400_core.c-1073-\t\treturn IIO_AVAIL_LIST;\n--\ndrivers/iio/accel/bma400_core.c-1078-\ndrivers/iio/accel/bma400_core.c:1079:static int bma400_write_raw(struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-1080-\t\t\t struct iio_chan_spec const *chan, int val, int val2,\n--\ndrivers/iio/accel/bma400_core.c-1082-{\ndrivers/iio/accel/bma400_core.c:1083:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-1084-\tint ret;\n--\ndrivers/iio/accel/bma400_core.c-1095-\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:1096:\t\tret = bma400_set_accel_output_data_rate(data, val, val2);\ndrivers/iio/accel/bma400_core.c-1097-\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-1104-\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:1105:\t\tret = bma400_set_accel_scale(data, val2);\ndrivers/iio/accel/bma400_core.c-1106-\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-1109-\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:1110:\t\tret = bma400_set_accel_oversampling_ratio(data, val);\ndrivers/iio/accel/bma400_core.c-1111-\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-1114-\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:1115:\t\tret = bma400_enable_steps(data, val);\ndrivers/iio/accel/bma400_core.c-1116-\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-1122-\ndrivers/iio/accel/bma400_core.c:1123:static int bma400_write_raw_get_fmt(struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-1124-\t\t\t\t struct iio_chan_spec const *chan,\n--\ndrivers/iio/accel/bma400_core.c-1140-\ndrivers/iio/accel/bma400_core.c:1141:static int bma400_read_event_config(struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-1142-\t\t\t\t const struct iio_chan_spec *chan,\n--\ndrivers/iio/accel/bma400_core.c-1145-{\ndrivers/iio/accel/bma400_core.c:1146:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-1147-\n--\ndrivers/iio/accel/bma400_core.c-1174-\ndrivers/iio/accel/bma400_core.c:1175:static int bma400_steps_event_enable(struct bma400_data *data, int state)\ndrivers/iio/accel/bma400_core.c-1176-{\n--\ndrivers/iio/accel/bma400_core.c-1178-\ndrivers/iio/accel/bma400_core.c:1179:\tret = bma400_enable_steps(data, 1);\ndrivers/iio/accel/bma400_core.c-1180-\tif (ret)\n--\ndrivers/iio/accel/bma400_core.c-1192-\ndrivers/iio/accel/bma400_core.c:1193:static int bma400_generic_event_en(struct bma400_data *data,\ndrivers/iio/accel/bma400_core.c-1194-\t\t\t\t enum iio_event_direction dir,\n--\ndrivers/iio/accel/bma400_core.c-1198-\tunsigned int intrmask, regval;\ndrivers/iio/accel/bma400_core.c:1199:\tenum bma400_generic_intr genintr;\ndrivers/iio/accel/bma400_core.c:1200:\tenum bma400_detect_criterion detect_criterion;\ndrivers/iio/accel/bma400_core.c:1201:\tconst struct bma400_genintr_info *bma400_genintr;\ndrivers/iio/accel/bma400_core.c-1202-\ndrivers/iio/accel/bma400_core.c:1203:\tbma400_genintr = get_bma400_genintr_info(dir);\ndrivers/iio/accel/bma400_core.c:1204:\tif (!bma400_genintr)\ndrivers/iio/accel/bma400_core.c-1205-\t\treturn -EINVAL;\ndrivers/iio/accel/bma400_core.c-1206-\ndrivers/iio/accel/bma400_core.c:1207:\tgenintr = bma400_genintr-\u003egenintr;\ndrivers/iio/accel/bma400_core.c:1208:\tdetect_criterion = bma400_genintr-\u003edetect_mode;\ndrivers/iio/accel/bma400_core.c:1209:\tintrmask = bma400_genintr-\u003eintrmask;\ndrivers/iio/accel/bma400_core.c-1210-\n--\ndrivers/iio/accel/bma400_core.c-1257-\ndrivers/iio/accel/bma400_core.c:1258:static int bma400_tap_event_en(struct bma400_data *data,\ndrivers/iio/accel/bma400_core.c-1259-\t\t\t enum iio_event_direction dir, int state)\n--\ndrivers/iio/accel/bma400_core.c-1312-\ndrivers/iio/accel/bma400_core.c:1313:static int bma400_disable_adv_interrupt(struct bma400_data *data)\ndrivers/iio/accel/bma400_core.c-1314-{\n--\ndrivers/iio/accel/bma400_core.c-1332-\ndrivers/iio/accel/bma400_core.c:1333:static int bma400_write_event_config(struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-1334-\t\t\t\t const struct iio_chan_spec *chan,\n--\ndrivers/iio/accel/bma400_core.c-1337-{\ndrivers/iio/accel/bma400_core.c:1338:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-1339-\tint ret;\n--\ndrivers/iio/accel/bma400_core.c-1345-\t\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:1346:\t\t\tret = bma400_generic_event_en(data, dir, state);\ndrivers/iio/accel/bma400_core.c-1347-\t\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-1350-\t\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:1351:\t\t\tret = bma400_tap_event_en(data, dir, state);\ndrivers/iio/accel/bma400_core.c-1352-\t\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-1358-\t\tmutex_lock(\u0026data-\u003emutex);\ndrivers/iio/accel/bma400_core.c:1359:\t\tret = bma400_steps_event_enable(data, state);\ndrivers/iio/accel/bma400_core.c-1360-\t\tmutex_unlock(\u0026data-\u003emutex);\n--\ndrivers/iio/accel/bma400_core.c-1364-\t\tif (!data-\u003estep_event_en) {\ndrivers/iio/accel/bma400_core.c:1365:\t\t\tret = bma400_steps_event_enable(data, true);\ndrivers/iio/accel/bma400_core.c-1366-\t\t\tif (ret) {\n--\ndrivers/iio/accel/bma400_core.c-1378-\ndrivers/iio/accel/bma400_core.c:1379:static int bma400_read_event_value(struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-1380-\t\t\t\t const struct iio_chan_spec *chan,\n--\ndrivers/iio/accel/bma400_core.c-1385-{\ndrivers/iio/accel/bma400_core.c:1386:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-1387-\tint ret, reg_val, raw;\ndrivers/iio/accel/bma400_core.c:1388:\tenum bma400_generic_intr genintr;\ndrivers/iio/accel/bma400_core.c:1389:\tconst struct bma400_genintr_info *bma400_genintr;\ndrivers/iio/accel/bma400_core.c-1390-\n--\ndrivers/iio/accel/bma400_core.c-1395-\tcase IIO_EV_TYPE_MAG:\ndrivers/iio/accel/bma400_core.c:1396:\t\tbma400_genintr = get_bma400_genintr_info(dir);\ndrivers/iio/accel/bma400_core.c:1397:\t\tif (!bma400_genintr)\ndrivers/iio/accel/bma400_core.c-1398-\t\t\treturn -EINVAL;\ndrivers/iio/accel/bma400_core.c:1399:\t\tgenintr = bma400_genintr-\u003egenintr;\ndrivers/iio/accel/bma400_core.c-1400-\n--\ndrivers/iio/accel/bma400_core.c-1471-\ndrivers/iio/accel/bma400_core.c:1472:static int bma400_write_event_value(struct iio_dev *indio_dev,\ndrivers/iio/accel/bma400_core.c-1473-\t\t\t\t const struct iio_chan_spec *chan,\n--\ndrivers/iio/accel/bma400_core.c-1478-{\ndrivers/iio/accel/bma400_core.c:1479:\tstruct bma400_data *data = iio_priv(indio_dev);\ndrivers/iio/accel/bma400_core.c-1480-\tint ret, raw;\ndrivers/iio/accel/bma400_core.c:1481:\tenum bma400_generic_intr genintr;\ndrivers/iio/accel/bma400_core.c:1482:\tconst struct bma400_genintr_info *bma400_genintr;\ndrivers/iio/accel/bma400_core.c-1483-\n--\ndrivers/iio/accel/bma400_core.c-1488-\tcase IIO_EV_TYPE_MAG:\n\n"
} |
| 5/2 | 2026/09/18 07:20 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 17083 output: 35 thoughts: 64 Thoughts: **Analyzing the BMA400 Driver** Okay, so I'm diving into this `bma400` code, which, as I understand it, is the driver for the Bosch BMA400 accelerometer. My immediate thought is, "How is this thing actually connected?" Is it I2C or SPI? I need to figure out the communication protocol. The logical next step is to examine the `bma400_i2c.c` and `bma400_spi.c` files. That should give me a solid understanding of the hardware interface. |
| 6/2 | 2026/09/18 07:20 | tool | grepper |
0mArgs:{
"Expression": "bma400_probe",
"PathPrefix": "drivers/iio/accel/"
}Results: {
"Output": "drivers/iio/accel/bma400.h=187=extern const struct regmap_config bma400_regmap_config;\ndrivers/iio/accel/bma400.h-188-\ndrivers/iio/accel/bma400.h:189:int bma400_probe(struct device *dev, struct regmap *regmap, int irq,\ndrivers/iio/accel/bma400.h-190-\t\t const char *name);\n--\ndrivers/iio/accel/bma400_core.c=1644=static irqreturn_t bma400_interrupt(int irq, void *private)\n--\ndrivers/iio/accel/bma400_core.c-1739-\ndrivers/iio/accel/bma400_core.c:1740:int bma400_probe(struct device *dev, struct regmap *regmap, int irq,\ndrivers/iio/accel/bma400_core.c-1741-\t\t const char *name)\n--\ndrivers/iio/accel/bma400_core.c-1805-}\ndrivers/iio/accel/bma400_core.c:1806:EXPORT_SYMBOL_NS(bma400_probe, \"IIO_BMA400\");\ndrivers/iio/accel/bma400_core.c-1807-\n--\ndrivers/iio/accel/bma400_i2c.c=15=static int bma400_i2c_probe(struct i2c_client *client)\n--\ndrivers/iio/accel/bma400_i2c.c-25-\ndrivers/iio/accel/bma400_i2c.c:26:\treturn bma400_probe(\u0026client-\u003edev, regmap, client-\u003eirq, id-\u003ename);\ndrivers/iio/accel/bma400_i2c.c-27-}\n--\ndrivers/iio/accel/bma400_spi.c=62=static int bma400_spi_probe(struct spi_device *spi)\n--\ndrivers/iio/accel/bma400_spi.c-85-\ndrivers/iio/accel/bma400_spi.c:86:\treturn bma400_probe(\u0026spi-\u003edev, regmap, spi-\u003eirq, id-\u003ename);\ndrivers/iio/accel/bma400_spi.c-87-}\n"
} |
| 7/2 | 2026/09/18 07:20 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 17991 output: 46 thoughts: 47 Thoughts: Here's a summary of my mental process: **Diving into the BMA400 Probe Function** Okay, time to get my hands dirty. I need to take a look at the `bma400_probe` function. Specifically, I'm heading straight for the `drivers/iio/accel/bma400_core.c` file and zeroing in on lines 1730-1810. That should give me a good chunk of the probe implementation to dissect. I'm assuming that's where the critical initialization, device setup, and resource allocation are happening. I need to understand how this driver is handling the initial connection and configuration of the BMA400 accelerometer. I'll be looking for things like: how it's interacting with the I2C or SPI bus (depending on the platform), how the device registers are being accessed, any specific error handling, and how interrupts are set up, if applicable. Let's see if there are any obvious issues or areas ripe for optimization in this initial device setup phase. |
| 8/2 | 2026/09/18 07:20 | tool | read-file |
0mArgs:{
"File": "drivers/iio/accel/bma400_core.c",
"FirstLine": 1735,
"LineCount": 75
}Results: {
"Contents": "1735:\tunlock_err:\n1736:\t\tmutex_unlock(\u0026data-\u003emutex);\n1737:\t\treturn IRQ_NONE;\n1738:\t}\n1739:\t\n1740:\tint bma400_probe(struct device *dev, struct regmap *regmap, int irq,\n1741:\t\t\t const char *name)\n1742:\t{\n1743:\t\tstruct iio_dev *indio_dev;\n1744:\t\tstruct bma400_data *data;\n1745:\t\tint ret;\n1746:\t\n1747:\t\tindio_dev = devm_iio_device_alloc(dev, sizeof(*data));\n1748:\t\tif (!indio_dev)\n1749:\t\t\treturn -ENOMEM;\n1750:\t\n1751:\t\tdata = iio_priv(indio_dev);\n1752:\t\tdata-\u003eregmap = regmap;\n1753:\t\tdata-\u003edev = dev;\n1754:\t\n1755:\t\tret = bma400_init(data);\n1756:\t\tif (ret)\n1757:\t\t\treturn ret;\n1758:\t\n1759:\t\tret = iio_read_mount_matrix(dev, \u0026data-\u003eorientation);\n1760:\t\tif (ret)\n1761:\t\t\treturn ret;\n1762:\t\n1763:\t\tmutex_init(\u0026data-\u003emutex);\n1764:\t\tindio_dev-\u003ename = name;\n1765:\t\tindio_dev-\u003einfo = \u0026bma400_info;\n1766:\t\tindio_dev-\u003echannels = bma400_channels;\n1767:\t\tindio_dev-\u003enum_channels = ARRAY_SIZE(bma400_channels);\n1768:\t\tindio_dev-\u003eavailable_scan_masks = bma400_avail_scan_masks;\n1769:\t\tindio_dev-\u003emodes = INDIO_DIRECT_MODE;\n1770:\t\n1771:\t\tif (irq \u003e 0) {\n1772:\t\t\tdata-\u003etrig = devm_iio_trigger_alloc(dev, \"%s-dev%d\",\n1773:\t\t\t\t\t\t\t indio_dev-\u003ename,\n1774:\t\t\t\t\t\t\t iio_device_id(indio_dev));\n1775:\t\t\tif (!data-\u003etrig)\n1776:\t\t\t\treturn -ENOMEM;\n1777:\t\n1778:\t\t\tdata-\u003etrig-\u003eops = \u0026bma400_trigger_ops;\n1779:\t\t\tiio_trigger_set_drvdata(data-\u003etrig, indio_dev);\n1780:\t\n1781:\t\t\tret = devm_iio_trigger_register(data-\u003edev, data-\u003etrig);\n1782:\t\t\tif (ret)\n1783:\t\t\t\treturn dev_err_probe(data-\u003edev, ret,\n1784:\t\t\t\t\t\t \"iio trigger register fail\\n\");\n1785:\t\n1786:\t\t\tret = devm_request_threaded_irq(dev, irq, NULL,\n1787:\t\t\t\t\t\t\t\u0026bma400_interrupt,\n1788:\t\t\t\t\t\t\tIRQF_TRIGGER_RISING | IRQF_ONESHOT,\n1789:\t\t\t\t\t\t\tindio_dev-\u003ename, indio_dev);\n1790:\t\t\tif (ret)\n1791:\t\t\t\treturn dev_err_probe(data-\u003edev, ret,\n1792:\t\t\t\t\t\t \"request irq %d failed\\n\", irq);\n1793:\t\t}\n1794:\t\n1795:\t\tret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,\n1796:\t\t\t\t\t\t \u0026bma400_trigger_handler, NULL);\n1797:\t\tif (ret)\n1798:\t\t\treturn dev_err_probe(data-\u003edev, ret,\n1799:\t\t\t\t\t \"iio triggered buffer setup failed\\n\");\n1800:\t\n1801:\t\tif (irq \u003e 0)\n1802:\t\t\tindio_dev-\u003etrig = iio_trigger_get(data-\u003etrig);\n1803:\t\n1804:\t\treturn devm_iio_device_register(dev, indio_dev);\n1805:\t}\n1806:\tEXPORT_SYMBOL_NS(bma400_probe, \"IIO_BMA400\");\n1807:\t\n1808:\tMODULE_AUTHOR(\"Dan Robertson \u003cdan@dlrobertson.com\u003e\");\n1809:\tMODULE_AUTHOR(\"Jagath Jog J \u003cjagathjog1996@gmail.com\u003e\");\n"
} |
| 9/2 | 2026/09/18 07:20 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 19550 output: 45 thoughts: 984 Thoughts: **Analyzing the BMA400 Driver Patch for Fuzzing Potential** Okay, let's break this down. My initial thought is to understand the implications of this code change in `bma400_probe`. The patch moved the `iio_trigger_get` call and subsequent assignment of `indio_dev->trig` after the `devm_iio_triggered_buffer_setup` call, but only if the IRQ is greater than zero. The original placement seems odd. If `devm_iio_triggered_buffer_setup` or `request_threaded_irq` failed, `indio_dev->trig` was already set, and the trigger's reference count incremented, potentially leading to a resource leak. Moving the assignment after `devm_iio_triggered_buffer_setup` *seems* safer, but the IRQ check adds a conditional element. Now, the crucial question: can this code path even be reached during fuzzing, especially within a standard virtualized environment like those used by syzkaller? That's my primary concern. The documentation emphasizes reachability as the key criterion. I need to apply the "REACHABILITY IS THE PRIMARY GATE" principle. I'm going to carefully consider the "WHEN TO RETURN WorthFuzzing=false" negative criteria. Specifically, are the changes in code categorized as "Structurally unreachable hardware" or "Unreachable execution paths"? Is BMA400 an I2C/SPI device? Can these types of devices be readily instantiated and probed within a standard QEMU environment by syzkaller? I'm not sure. Can syzkaller or a user space process instantiate I2C devices? Do they provide means for creating new I2C devices via `/sys/bus/i2c/devices/i2c-*/new_device`? I need to check if syzkaller has pseudo-syscalls for i2c, or if BMA400 can even be probed through syzkaller. Let's look at the `bma400_init(data)` function called from `bma400_probe`. What's happening inside it is going to tell me whether the device is truly essential to the kernel. Let me check lines 895-940 of `bma400_core.c`! |
| 10/2 | 2026/09/18 07:20 | tool | read-file |
0mArgs:{
"File": "drivers/iio/accel/bma400_core.c",
"FirstLine": 895,
"LineCount": 45
}Results: {
"Contents": " 895:\tstatic int bma400_init(struct bma400_data *data)\n 896:\t{\n 897:\t\tstatic const char * const regulator_names[] = { \"vdd\", \"vddio\" };\n 898:\t\tunsigned int val;\n 899:\t\tint ret;\n 900:\t\n 901:\t\tret = devm_regulator_bulk_get_enable(data-\u003edev,\n 902:\t\t\t\t\t\t ARRAY_SIZE(regulator_names),\n 903:\t\t\t\t\t\t regulator_names);\n 904:\t\tif (ret)\n 905:\t\t\treturn dev_err_probe(data-\u003edev, ret, \"Failed to get regulators\\n\");\n 906:\t\n 907:\t\t/* Try to read chip_id register. It must return 0x90. */\n 908:\t\tret = regmap_read(data-\u003eregmap, BMA400_CHIP_ID_REG, \u0026val);\n 909:\t\tif (ret) {\n 910:\t\t\tdev_err(data-\u003edev, \"Failed to read chip id register\\n\");\n 911:\t\t\treturn ret;\n 912:\t\t}\n 913:\t\n 914:\t\tif (val != BMA400_ID_REG_VAL) {\n 915:\t\t\tdev_err(data-\u003edev, \"Chip ID mismatch\\n\");\n 916:\t\t\treturn -ENODEV;\n 917:\t\t}\n 918:\t\n 919:\t\tret = bma400_get_power_mode(data);\n 920:\t\tif (ret) {\n 921:\t\t\tdev_err(data-\u003edev, \"Failed to get the initial power-mode\\n\");\n 922:\t\t\treturn ret;\n 923:\t\t}\n 924:\t\n 925:\t\tif (data-\u003epower_mode != POWER_MODE_NORMAL) {\n 926:\t\t\tret = bma400_set_power_mode(data, POWER_MODE_NORMAL);\n 927:\t\t\tif (ret) {\n 928:\t\t\t\tdev_err(data-\u003edev, \"Failed to wake up the device\\n\");\n 929:\t\t\t\treturn ret;\n 930:\t\t\t}\n 931:\t\t\t/*\n 932:\t\t\t * TODO: The datasheet waits 1500us here in the example, but\n 933:\t\t\t * lists 2/ODR as the wakeup time.\n 934:\t\t\t */\n 935:\t\t\tusleep_range(1500, 2000);\n 936:\t\t}\n 937:\t\n 938:\t\tret = devm_add_action_or_reset(data-\u003edev, bma400_power_disable, data);\n 939:\t\tif (ret)\n"
} |
| 11/2 | 2026/09/18 07:20 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 21830 output: 45 thoughts: 570 Thoughts: **My Analysis of the BMA400 Driver and its Fuzzability** Okay, so I'm looking at this BMA400 accelerometer driver code, specifically lines 908-917. The first thing that jumps out is that the `bma400_init()` function *has* to read the chip ID register and confirm it's 0x90. This makes perfect sense; it's a fundamental sanity check to ensure we're talking to the right device. If `regmap_read` fails, or if the ID doesn't match, we immediately get a `-ENODEV` error. This is a crucial early check before the trigger setup and the core probe function even gets going! My immediate thought is, even if some clever sysfs hack *could* instantiate a device without the hardware being present, that initial chip ID read is going to trip us up. The code simply won't proceed without the correct response. We'd need something to *emulate* that response, so the driver *thinks* it's talking to a real BMA400. So, the next question is can QEMU emulate a BMA400? Quick check reveals that no, QEMU doesn't seem to have BMA400 on its emulation list. It has other devices, but not this one. Then my mind moves to the bigger picture, and how this fits into fuzzing, particularly with Syzkaller. Syzkaller's documentation repeatedly stresses that reachability is everything. If the code isn't executing in standard environments, such as GCE or QEMU, we're simply not going to find bugs. Syzkaller is going to target software-emulated devices like USB gadgets or netdev. But what about I2C and SPI? Does Syzkaller have any built-in support for *emulating* these interfaces, or at least for fuzzing drivers that use them? This feels like the critical question. I start to mentally scan the landscape and look for discussions about I2C/SPI or IIO drivers in the context of Syzkaller. And then I circle back to the device itself. Can we somehow fake it via USB? The BMA400 is *not* a USB device. It's an accelerometer that speaks I2C and SPI, period. So emulating it via USB is a no-go. We're back to figuring out how to get I2C/SPI support in the fuzzer. My next steps are probably going to be a deep dive into the `drivers/iio/accel/bma400_i2c.c` and `bma400_spi.c` files to look for more clues. |
| 12/2 | 2026/09/18 07:21 | tool | read-file |
0mArgs:{
"File": "drivers/iio/accel/bma400_i2c.c",
"FirstLine": 1,
"LineCount": 45
}Results: {
"Contents": " 1:\t// SPDX-License-Identifier: GPL-2.0-only\n 2:\t/*\n 3:\t * I2C IIO driver for Bosch BMA400 triaxial acceleration sensor.\n 4:\t *\n 5:\t * Copyright 2019 Dan Robertson \u003cdan@dlrobertson.com\u003e\n 6:\t *\n 7:\t * I2C address is either 0x14 or 0x15 depending on SDO\n 8:\t */\n 9:\t#include \u003clinux/i2c.h\u003e\n 10:\t#include \u003clinux/module.h\u003e\n 11:\t#include \u003clinux/regmap.h\u003e\n 12:\t\n 13:\t#include \"bma400.h\"\n 14:\t\n 15:\tstatic int bma400_i2c_probe(struct i2c_client *client)\n 16:\t{\n 17:\t\tconst struct i2c_device_id *id = i2c_client_get_device_id(client);\n 18:\t\tstruct regmap *regmap;\n 19:\t\n 20:\t\tregmap = devm_regmap_init_i2c(client, \u0026bma400_regmap_config);\n 21:\t\tif (IS_ERR(regmap)) {\n 22:\t\t\tdev_err(\u0026client-\u003edev, \"failed to create regmap\\n\");\n 23:\t\t\treturn PTR_ERR(regmap);\n 24:\t\t}\n 25:\t\n 26:\t\treturn bma400_probe(\u0026client-\u003edev, regmap, client-\u003eirq, id-\u003ename);\n 27:\t}\n 28:\t\n 29:\tstatic const struct i2c_device_id bma400_i2c_ids[] = {\n 30:\t\t{ .name = \"bma400\" },\n 31:\t\t{ }\n 32:\t};\n 33:\tMODULE_DEVICE_TABLE(i2c, bma400_i2c_ids);\n 34:\t\n 35:\tstatic const struct of_device_id bma400_of_i2c_match[] = {\n 36:\t\t{ .compatible = \"bosch,bma400\" },\n 37:\t\t{ }\n 38:\t};\n 39:\tMODULE_DEVICE_TABLE(of, bma400_of_i2c_match);\n 40:\t\n 41:\tstatic struct i2c_driver bma400_i2c_driver = {\n 42:\t\t.driver = {\n 43:\t\t\t.name = \"bma400\",\n 44:\t\t\t.of_match_table = bma400_of_i2c_match,\n 45:\t\t},\n"
} |
| 13/2 | 2026/09/18 07:21 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 23756 output: 44 thoughts: 18 Thoughts: Here's my take on the thought process, summarized as if I were considering the code: **Checking the SPI Implementation** Okay, so we're seeing an issue, and my first instinct is to drill down into the SPI implementation for the BMA400. We need to verify that the SPI communication is functioning correctly. Given what we know, `bma400_spi.c` is the logical place to start. Let's see if there are any obvious red flags in the SPI transaction setup, data framing, or error handling within that specific file. We should focus on how the driver interfaces with the underlying SPI bus – looking at the clock speed, chip select management, data formatting, and any potential timing conflicts. I'll need to pay close attention to the register read/write sequences to ensure they're adhering to the BMA400's datasheet specifications. We need to rule out a fundamental SPI communication problem as the root cause. |
| 14/2 | 2026/09/18 07:21 | tool | read-file |
0mArgs:{
"File": "drivers/iio/accel/bma400_spi.c",
"FirstLine": 55,
"LineCount": 45
}Results: {
"Contents": " 55:\tstatic const struct regmap_bus bma400_regmap_bus = {\n 56:\t\t.read = bma400_regmap_spi_read,\n 57:\t\t.write = bma400_regmap_spi_write,\n 58:\t\t.read_flag_mask = BIT(7),\n 59:\t\t.max_raw_read = BMA400_MAX_SPI_READ,\n 60:\t};\n 61:\t\n 62:\tstatic int bma400_spi_probe(struct spi_device *spi)\n 63:\t{\n 64:\t\tconst struct spi_device_id *id = spi_get_device_id(spi);\n 65:\t\tstruct regmap *regmap;\n 66:\t\tunsigned int val;\n 67:\t\tint ret;\n 68:\t\n 69:\t\tregmap = devm_regmap_init(\u0026spi-\u003edev, \u0026bma400_regmap_bus,\n 70:\t\t\t\t\t \u0026spi-\u003edev, \u0026bma400_regmap_config);\n 71:\t\tif (IS_ERR(regmap)) {\n 72:\t\t\tdev_err(\u0026spi-\u003edev, \"failed to create regmap\\n\");\n 73:\t\t\treturn PTR_ERR(regmap);\n 74:\t\t}\n 75:\t\n 76:\t\t/*\n 77:\t\t * Per the bma400 datasheet, the first SPI read may\n 78:\t\t * return garbage. As the datasheet recommends, the\n 79:\t\t * chip ID register will be read here and checked\n 80:\t\t * again in the following probe.\n 81:\t\t */\n 82:\t\tret = regmap_read(regmap, BMA400_CHIP_ID_REG, \u0026val);\n 83:\t\tif (ret)\n 84:\t\t\tdev_err(\u0026spi-\u003edev, \"Failed to read chip id register\\n\");\n 85:\t\n 86:\t\treturn bma400_probe(\u0026spi-\u003edev, regmap, spi-\u003eirq, id-\u003ename);\n 87:\t}\n 88:\t\n 89:\tstatic const struct spi_device_id bma400_spi_ids[] = {\n 90:\t\t{ \"bma400\", 0 },\n 91:\t\t{ }\n 92:\t};\n 93:\tMODULE_DEVICE_TABLE(spi, bma400_spi_ids);\n 94:\t\n 95:\tstatic const struct of_device_id bma400_of_spi_match[] = {\n 96:\t\t{ .compatible = \"bosch,bma400\" },\n 97:\t\t{ }\n 98:\t};\n 99:\tMODULE_DEVICE_TABLE(of, bma400_of_spi_match);\n"
} |
| 15/2 | 2026/09/18 07:21 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 24749 output: 155 thoughts: 863 Thoughts: **Analysis of BMA400 Driver Fuzzing Feasibility** Okay, so the `bma400_i2c` and `bma400_spi` drivers both depend on the physical hardware of the BMA400 sensor. I need to figure out if this driver is fuzzeable with syzkaller. Can syzkaller instantiate or mock I2C devices? It looks like it can use pseudo-syscalls for I2C, but those syscalls target `/dev/i2c-*` devices. The problem is, there's no emulated hardware, no mock I2C device with the expected chip ID, 0x90, responding to those I2C transactions. Even if I could somehow create an I2C client device using `new_device`, `regmap_read(data->regmap, BMA400_CHIP_ID_REG, &val)` is still going to perform an actual I2C read. Without the physical BMA400 chip present (or a dedicated QEMU emulation of it, which I don't see), that I2C read is going to fail with -ENXIO or -EIO. And the `bma400_init()` function explicitly checks the chip ID: if the read returns anything other than `BMA400_ID_REG_VAL`, it errors out with `-ENODEV`. This happens *before* the changes in `bma400_probe` are made. The code I'm looking at is *inside* `bma400_probe`, which only runs during device probing, and `bma400_init()` failing would exit before getting there. Alright, let's go back to the instructions. The key is "REACHABILITY IS THE PRIMARY GATE". The modified code has to be able to execute in standard virtualized environments. According to the document, if code is structurally unreachable, it MUST NOT be fuzzed. Specifically, structurally unreachable hardware like vendor-specific devices requiring physical ASICs and not emulated in QEMU should not be fuzzed. The BMA400 is a Bosch triaxial acceleration sensor that uses I2C or SPI. It requires the physical ASIC/hardware chip, which isn't present or emulated in standard environments (QEMU/GCE). So, `bma400_probe` can't be executed successfully. It's structurally unreachable hardware. Just to be sure, let me check the diff. It seems the modification is limited to `drivers/iio/accel/bma400_core.c` and specifically `bma400_probe()`. Yup, WorthFuzzing is definitely `false`. The BMA400 requires dedicated physical hardware (a Bosch BMA400 accelerometer over I2C/SPI), which isn't emulated in QEMU or GCE. The modified code in `bma400_probe()` is structurally unreachable. My output will include: * `WorthFuzzing=false` * `FocusSymbols: []` * `EnableConfigs: []` (or null/empty) * `Reasoning`: Briefly explaining why. All good. Final check. Ready to proceed. |
| 16/2 | 2026/09/18 07:21 | tool | set-results |
0mArgs:{
"EnableConfigs": [],
"FocusSymbols": [],
"Reasoning": "The patch modifies `bma400_probe` in `drivers/iio/accel/bma400_core.c`, which is the probe routine for the Bosch BMA400 accelerometer driver (interfaced over I2C or SPI). This driver requires physical BMA400 hardware (or dedicated hardware emulation responding to register reads such as BMA400_CHIP_ID_REG) which is not emulated or available in standard QEMU/GCE virtualized fuzzing environments. Consequently, the modified code is structurally unreachable during fuzzing.",
"WorthFuzzing": false
}Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies `bma400_probe` in `drivers/iio/accel/bma400_core.c`, which is the probe routine for the Bosch BMA400 accelerometer driver (interfaced over I2C or SPI). This driver requires physical BMA400 hardware (or dedicated hardware emulation responding to register reads such as BMA400_CHIP_ID_REG) which is not emulated or available in standard QEMU/GCE virtualized fuzzing environments. Consequently, the modified code is structurally unreachable during fuzzing.",
"WorthFuzzing": false
} |
| 17/1 | 2026/09/18 07:21 | action | If |
0mArgs:{
"WorthFuzzing": false
}Results: null |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|