- 23 May, 2023 3 commits
-
-
Marek Vasut authored
To simplify addition of support for new parts, drop unused register macros. No functional change. Acked-by: Crt Mori <cmo@melexis.com> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230510102251.10118-3-marex@denx.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marek Vasut authored
Sort the headers alphabetically. No functional change. Acked-by: Crt Mori <cmo@melexis.com> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230510102251.10118-2-marex@denx.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marek Vasut authored
Document support for MLX90615 Infra Red Thermometer, which seems to be the predecesor of MLX90614 . There are significant differences in the register layout compared to MLX90614, but the functionality of the device is virtually identical. Acked-by: Crt Mori <cmo@melexis.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230510102251.10118-1-marex@denx.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 21 May, 2023 4 commits
-
-
Andreas Klinger authored
Add myself as a maintainer for Honeywell mprls0025pa sensor. Signed-off-by: Andreas Klinger <ak@it-klinger.de> Link: https://lore.kernel.org/r/ZGNp+1uNAxi3uxjM@arbadSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andreas Klinger authored
Honeywell mprls0025pa is a series of pressure sensors. Add initial I2C support. Note: - IIO buffered mode is supported - SPI mode is not supported Signed-off-by: Andreas Klinger <ak@it-klinger.de> Link: https://lore.kernel.org/r/ZGNp3SqyOJeEcLsj@arbadSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andreas Klinger authored
Honeywell mprls0025pa is a pressure sensor series. There are many different models with different pressure ranges, units and transfer functions. The range and transfer function need to be set up in the dt. Therefore new properties honeywell,pmin-pascal, honeywell,pmax-pascal, honeywell,transfer-function are introduced. Add dt-bindings. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Andreas Klinger <ak@it-klinger.de> Link: https://lore.kernel.org/r/ZGNpve4ux5KJ3BNQ@arbadSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230515205048.19561-1-u.kleine-koenig@pengutronix.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 20 May, 2023 4 commits
-
-
Niklas Schnelle authored
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20230516110038.2413224-13-schnelle@linux.ibm.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Krzysztof Kozlowski authored
Reference iio.yaml schema from dtschema to allow already used mount-matrix property: msm8953-xiaomi-daisy.dtb: imu@6a: Unevaluated properties are not allowed ('mount-matrix' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230507173923.263741-1-krzysztof.kozlowski@linaro.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Herve Codina authored
After contributing the driver, add myself as the maintainer for the Renesas X9250 IIO driver. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20230509160852.158101-4-herve.codina@bootlin.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Herve Codina authored
The Renesas X9250 integrates four digitally controlled potentiometers. On each potentiometer, the X9250T has a 100 kOhms total resistance and the X9250U has a 50 kOhms total resistance. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20230509160852.158101-3-herve.codina@bootlin.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 13 May, 2023 26 commits
-
-
Herve Codina authored
The Renesas X9250 is a quad digitally controlled potentiometers. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230509160852.158101-2-herve.codina@bootlin.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Hermes Zhang authored
The Invensense ICM-20600 is a 6-axis MotionTracking device that combines a 3-axis gyroscope and an 3-axis accelerometer. It is very similar to the ICM20602 imu which is already supported by the mpu6050 driver. The main difference is that the ICM-20600 has a different WHOAMI value. Signed-off-by: Hermes Zhang <chenhuiz@axis.com> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20230505054853.2155326-3-chenhuiz@axis.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Hermes Zhang authored
ICM-20600 is almost same as ICM-20602 which already support in mpu6050 driver. Specify "invensense,icm20602" as a fallback compatible Signed-off-by: Hermes Zhang <chenhuiz@axis.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20230505054853.2155326-2-chenhuiz@axis.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marijn Suijten authored
Set the read_label() callback to return a friendly name provided in DT (firmware), in order to make in_{therm,voltage}X_label attributes show up in sysfs for userspace to consume a channel name. This is particularly useful for custom thermistors being attached to otherwise generically named GPIOs, where the name is known by the board DT. If the channel name isn't set in DT, use the datasheet_name hardcoded in the driver instead. Note that this doesn't fall back to fwnode_get_name() as that provides suboptimally readable names, with an @xx address suffix from board DT. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230502-iio-adc-propagate-fw-node-label-v3-5-6be5db6e6b5a@somainline.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marijn Suijten authored
datasheet_name is statically filled by a macro for every channel, and is nor should ever be set to NULL. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230502-iio-adc-propagate-fw-node-label-v3-4-6be5db6e6b5a@somainline.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marijn Suijten authored
Since the migration to fwnode_get_name in commit 4f47a236 ("iio: adc: qcom-spmi-adc5: convert to device properties") the resulting adc5_channel_prop::channel_name (renamed from datasheet_name in the previous patch) - which is propagated into iio_chan_spec::extend_name - was containing the DT node name including @xx suffix if a "label" property is not present, while adc5_channels::datasheet_name was thus far set by the macros but always remained unread. Put it to use instead of using a confusing name containing @xx in sysfs filenames (again, when "label" is not set). Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230502-iio-adc-propagate-fw-node-label-v3-3-6be5db6e6b5a@somainline.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marijn Suijten authored
iio_chan_spec::datasheet_name expects a channel/pin name on the hardware part, i.e. from its datasheet, instead of a friendly name from DT which typically describes the use of said channel. GPIO channels are commonly specialized in QCOM board DTS based on what a - typically thermistor - is connected to. Also rename adc5_channel_prop::datasheet_name to channel_name to that effect. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230502-iio-adc-propagate-fw-node-label-v3-2-6be5db6e6b5a@somainline.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marijn Suijten authored
As mentioned and discussed in [1] extend_name should not be used for full channel labels (and most drivers seem to only use it to express a short type of a channel) as this affects sysfs filenames, while the label name is supposed to be extracted from the *_label sysfs file instead. This appears to have been unclear to some drivers as extend_name is also used when read_label is unset, achieving an initial goal of providing sensible names in *_label sysfs files without noticing that sysfs filenames are (negatively and likely unintentionally) affected as well. Point readers of iio_chan_spec::extend_name to iio_info::read_label by mentioning deprecation and side-effects of this field. [1]: https://lore.kernel.org/linux-arm-msm/20221221223432.si2aasbleiicayfl@SoMainline.org/Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Link: https://lore.kernel.org/r/20230502-iio-adc-propagate-fw-node-label-v3-1-6be5db6e6b5a@somainline.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
Devices which may take a while to initialize during probe and which have no strong reason to probe synchronously can request asynchronous probing as default probe strategy. This can speed-up start times on some platforms. The KX022A gets probe delayed for at least two reasons. It enables the supply regulator, (which is likely to have ramp-up delay if it was disabled) and additionally it delays while the sensor itself is initializing. Changing to asynchronous probing may cause problems. Some of which are discussed in: https://lore.kernel.org/all/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/ Enable asynchronous probing for KX022A. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/24cea76c282a28b7a4dba297ab627176f8097907.1683185765.git.mazziesaccount@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
Devices which may take a while to initialize during probe and which have no strong reason to probe synchronously can request asynchronous probing as default probe strategy. This can speed-up start times on some platforms. The BU27034 gets probe delayed for at least two reasons. It enables the supply regulator, (which is likely to have ramp-up delay if it was disabled) and additionally it delays while the sensor itself is initializing. Changing to asynchronous probing may cause problems. Some of which are discussed in: https://lore.kernel.org/all/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/ Enabling async probing for the ROHM BU27034 should be fairly safe to try though as there is no in-tree users for it yet. If the async probing appears to be an issue we can switch easily back to synchronous (or better yet, fix the actual problem). Enable asynchronous probing for BU27034. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/e7088793e1868c77b1894b30cd026e8ed043ea7c.1683185765.git.mazziesaccount@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marijn Suijten authored
As discussed in [1] it is more convenient to use a generic `channel` node name for ADC channels while storing a friendly - board-specific instead of PMIC-specific - name in the label, if/when desired to overwrite the channel description already contained (but previously unused) in the driver [2]. The same `channel` node name pattern has also been set in iio/adc/adc.yaml, but this generic binding is not inherited as base for qcom,spmi-vadc bindings due to not having any other generic elements in common, besides the node name rule and reg property. Replace the .* name pattern with the `channel` literal, but leave the label property optional for bindings to choose to fall back a channel label hardcoded in the driver [2] instead. [1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u [2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230410202917.247666-6-marijn.suijten@somainline.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Nuno Sá authored
Just cosmetics. No functional change intended... Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20230216101452.591805-4-nuno.sa@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stefan Windfeldt-Prytz authored
This driver uses the continuous mode of the chip and integration time can be configured through sysfs. The constants for calculating lux value differs between packaging so it uses different compatible string for the two versions "ti,opt4001-picostar" and "ti,opt4001-sot-5x3" since the device id is the same. Datasheet: https://www.ti.com/lit/gpn/opt4001Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt-prytz@axis.com> Link: https://lore.kernel.org/r/20230323-add-opt4001-driver-v3-2-62e121dab294@axis.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stefan Windfeldt-Prytz authored
Add devicetree bindings for opt4001 ambient light sensor. Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt-prytz@axis.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230323-add-opt4001-driver-v3-1-62e121dab294@axis.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Christophe JAILLET authored
This driver does not use i2c, so there is no point in including <linux/i2c.h> Remove it. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/9d23cd04d7f99dc8d813584aae5268b57f92fcd8.1682320298.git.christophe.jaillet@wanadoo.frSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Frank Wunderlich authored
Add compatible string and specific clock property for mt7986. Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Link: https://lore.kernel.org/r/20230421132047.42166-3-linux@fw-web.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Sean Nyekjaer authored
Since nearly all stm32 dt's are using the legacy adc channel config, we should warn users about using it. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20230421083858.2613289-1-sean@geanix.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marius Hoch authored
This sensor can be found as CALS0001 on the Lenovo Yoga Tablet 2 series. Tested on a Lenovo Yoga Tablet 2 1051-F. Signed-off-by: Marius Hoch <mail@mariushoch.de> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230420232631.68864-1-mail@mariushoch.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Christophe JAILLET authored
dev_err_probe() already display the error code. There is no need to duplicate it explicitly in the error message. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/9373d41b0a1f3dc3fc0d31c1daaa19d9a7ec4dcd.1681575924.git.christophe.jaillet@wanadoo.frSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marius Hoch authored
Same as the lsm9ds0, except that the lsm303d doesn't feature a gyroscope. Signed-off-by: Marius Hoch <mail@mariushoch.de> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20230415231130.115094-7-mail@mariushoch.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marius Hoch authored
Per its datasheet, the LSM303D also features that pin. Signed-off-by: Marius Hoch <mail@mariushoch.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20230415231130.115094-6-mail@mariushoch.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marius Hoch authored
The lsm303d can be found as ACCL0001 on various Lenovo devices, including the Lenovo Yoga Tablet 2 1051-F, where I tested this patch. Dropped SPI support as per discussion in thread linked below. Signed-off-by: Marius Hoch <mail@mariushoch.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20230415231130.115094-5-mail@mariushoch.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marius Hoch authored
The lsm303d is basically the lsm9ds0 without the gyroscope (which the LSM9DS0 IMU driver doesn't handle), as far as I can tell. Signed-off-by: Marius Hoch <mail@mariushoch.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20230415231130.115094-4-mail@mariushoch.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marius Hoch authored
The lsm303d has the same register mapping as the lsm9ds0, thus we can just re-use that. Tested on a Lenovo Yoga Tablet 2 1051-F. Signed-off-by: Marius Hoch <mail@mariushoch.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20230415231130.115094-3-mail@mariushoch.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marius Hoch authored
The lsm303d has the same register mapping as the lsm9ds0, thus we can just re-use that. Tested on a Lenovo Yoga Tablet 2 1051-F. Signed-off-by: Marius Hoch <mail@mariushoch.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20230415231130.115094-2-mail@mariushoch.deSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Luca Weiss authored
The channel ADC5_USB_IN_V_16 is using 1/16 pre-scaling on at least pm7250b and pmi632. Allow that in the schema. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230414-pmi632-v1-5-fe94dc414832@z3ntu.xyzSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 07 May, 2023 3 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge tag 'perf-tools-for-v6.4-3-2023-05-06' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tool updates from Arnaldo Carvalho de Melo: "Third version of perf tool updates, with the build problems with with using a 'vmlinux.h' generated from the main build fixed, and the bpf skeleton build disabled by default. Build: - Require libtraceevent to build, one can disable it using NO_LIBTRACEEVENT=1. It is required for tools like 'perf sched', 'perf kvm', 'perf trace', etc. libtraceevent is available in most distros so installing 'libtraceevent-devel' should be a one-time event to continue building perf as usual. Using NO_LIBTRACEEVENT=1 produces tooling that is functional and sufficient for lots of users not interested in those libtraceevent dependent features. - Allow Python support in 'perf script' when libtraceevent isn't linked, as not all features requires it, for instance Intel PT does not use tracepoints. - Error if the python interpreter needed for jevents to work isn't available and NO_JEVENTS=1 isn't set, preventing a build without support for JSON vendor events, which is a rare but possible condition. The two check error messages: $(error ERROR: No python interpreter needed for jevents generation. Install python or build with NO_JEVENTS=1.) $(error ERROR: Python interpreter needed for jevents generation too old (older than 3.6). Install a newer python or build with NO_JEVENTS=1.) - Make libbpf 1.0 the minimum required when building with out of tree, distro provided libbpf. - Use libsdtc++'s and LLVM's libcxx's __cxa_demangle, a portable C++ demangler, add 'perf test' entry for it. - Make binutils libraries opt in, as distros disable building with it due to licensing, they were used for C++ demangling, for instance. - Switch libpfm4 to opt-out rather than opt-in, if libpfm-devel (or equivalent) isn't installed, we'll just have a build warning: Makefile.config:1144: libpfm4 not found, disables libpfm4 support. Please install libpfm4-dev - Add a feature test for scandirat(), that is not implemented so far in musl and uclibc, disabling features that need it, such as scanning for tracepoints in /sys/kernel/tracing/events. perf BPF filters: - New feature where BPF can be used to filter samples, for instance: $ sudo ./perf record -e cycles --filter 'period > 1000' true $ sudo ./perf script perf-exec 2273949 546850.708501: 5029 cycles: ffffffff826f9e25 finish_wait+0x5 ([kernel.kallsyms]) perf-exec 2273949 546850.708508: 32409 cycles: ffffffff826f9e25 finish_wait+0x5 ([kernel.kallsyms]) perf-exec 2273949 546850.708526: 143369 cycles: ffffffff82b4cdbf xas_start+0x5f ([kernel.kallsyms]) perf-exec 2273949 546850.708600: 372650 cycles: ffffffff8286b8f7 __pagevec_lru_add+0x117 ([kernel.kallsyms]) perf-exec 2273949 546850.708791: 482953 cycles: ffffffff829190de __mod_memcg_lruvec_state+0x4e ([kernel.kallsyms]) true 2273949 546850.709036: 501985 cycles: ffffffff828add7c tlb_gather_mmu+0x4c ([kernel.kallsyms]) true 2273949 546850.709292: 503065 cycles: 7f2446d97c03 _dl_map_object_deps+0x973 (/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2) - In addition to 'period' (PERF_SAMPLE_PERIOD), the other PERF_SAMPLE_ can be used for filtering, and also some other sample accessible values, from tools/perf/Documentation/perf-record.txt: Essentially the BPF filter expression is: <term> <operator> <value> (("," | "||") <term> <operator> <value>)* The <term> can be one of: ip, id, tid, pid, cpu, time, addr, period, txn, weight, phys_addr, code_pgsz, data_pgsz, weight1, weight2, weight3, ins_lat, retire_lat, p_stage_cyc, mem_op, mem_lvl, mem_snoop, mem_remote, mem_lock, mem_dtlb, mem_blk, mem_hops The <operator> can be one of: ==, !=, >, >=, <, <=, & The <value> can be one of: <number> (for any term) na, load, store, pfetch, exec (for mem_op) l1, l2, l3, l4, cxl, io, any_cache, lfb, ram, pmem (for mem_lvl) na, none, hit, miss, hitm, fwd, peer (for mem_snoop) remote (for mem_remote) na, locked (for mem_locked) na, l1_hit, l1_miss, l2_hit, l2_miss, any_hit, any_miss, walk, fault (for mem_dtlb) na, by_data, by_addr (for mem_blk) hops0, hops1, hops2, hops3 (for mem_hops) perf lock contention: - Show lock type with address. - Track and show mmap_lock, siglock and per-cpu rq_lock with address. This is done for mmap_lock by following the current->mm pointer: $ sudo ./perf lock con -abl -- sleep 10 contended total wait max wait avg wait address symbol ... 16344 312.30 ms 2.22 ms 19.11 us ffff8cc702595640 17686 310.08 ms 1.49 ms 17.53 us ffff8cc7025952c0 3 84.14 ms 45.79 ms 28.05 ms ffff8cc78114c478 mmap_lock 3557 76.80 ms 68.75 us 21.59 us ffff8cc77ca3af58 1 68.27 ms 68.27 ms 68.27 ms ffff8cda745dfd70 9 54.53 ms 7.96 ms 6.06 ms ffff8cc7642a48b8 mmap_lock 14629 44.01 ms 60.00 us 3.01 us ffff8cc7625f9ca0 3481 42.63 ms 140.71 us 12.24 us ffffffff937906ac vmap_area_lock 16194 38.73 ms 42.15 us 2.39 us ffff8cd397cbc560 11 38.44 ms 10.39 ms 3.49 ms ffff8ccd6d12fbb8 mmap_lock 1 5.43 ms 5.43 ms 5.43 ms ffff8cd70018f0d8 1674 5.38 ms 422.93 us 3.21 us ffffffff92e06080 tasklist_lock 581 4.51 ms 130.68 us 7.75 us ffff8cc9b1259058 5 3.52 ms 1.27 ms 703.23 us ffff8cc754510070 112 3.47 ms 56.47 us 31.02 us ffff8ccee38b3120 381 3.31 ms 73.44 us 8.69 us ffffffff93790690 purge_vmap_area_lock 255 3.19 ms 36.35 us 12.49 us ffff8d053ce30c80 - Update default map size to 16384. - Allocate single letter option -M for --map-nr-entries, as it is proving being frequently used. - Fix struct rq lock access for older kernels with BPF's CO-RE (Compile once, run everywhere). - Fix problems found with MSAn. perf report/top: - Add inline information when using --call-graph=fp or lbr, as was already done to the --call-graph=dwarf callchain mode. - Improve the 'srcfile' sort key performance by really using an optimization introduced in 6.2 for the 'srcline' sort key that avoids calling addr2line for comparision with each sample. perf sched: - Make 'perf sched latency/map/replay' to use "sched:sched_waking" instead of "sched:sched_waking", consistent with 'perf record' since d566a9c2 ("perf sched: Prefer sched_waking event when it exists"). perf ftrace: - Make system wide the default target for latency subcommand, run the following command then generate some network traffic and press control+C: # perf ftrace latency -T __kfree_skb ^C DURATION | COUNT | GRAPH | 0 - 1 us | 27 | ############# | 1 - 2 us | 22 | ########### | 2 - 4 us | 8 | #### | 4 - 8 us | 5 | ## | 8 - 16 us | 24 | ############ | 16 - 32 us | 2 | # | 32 - 64 us | 1 | | 64 - 128 us | 0 | | 128 - 256 us | 0 | | 256 - 512 us | 0 | | 512 - 1024 us | 0 | | 1 - 2 ms | 0 | | 2 - 4 ms | 0 | | 4 - 8 ms | 0 | | 8 - 16 ms | 0 | | 16 - 32 ms | 0 | | 32 - 64 ms | 0 | | 64 - 128 ms | 0 | | 128 - 256 ms | 0 | | 256 - 512 ms | 0 | | 512 - 1024 ms | 0 | | 1 - ... s | 0 | | # perf top: - Add --branch-history (LBR: Last Branch Record) option, just like already available for 'perf record'. - Fix segfault in thread__comm_len() where thread->comm was being used outside thread->comm_lock. perf annotate: - Allow configuring objdump and addr2line in ~/.perfconfig., so that you can use alternative binaries, such as llvm's. perf kvm: - Add TUI mode for 'perf kvm stat report'. Reference counting: - Add reference count checking infrastructure to check for use after free, done to the 'cpumap', 'namespaces', 'maps' and 'map' structs, more to come. To build with it use -DREFCNT_CHECKING=1 in the make command line to build tools/perf. Documented at: https://perf.wiki.kernel.org/index.php/Reference_Count_Checking - The above caught, for instance, fix, present in this series: - Fix maps use after put in 'perf test "Share thread maps"': 'maps' is copied from leader, but the leader is put on line 79 and then 'maps' is used to read the reference count below - so a use after put, with the put of maps happening within thread__put. Fixed by reversing the order of puts so that the leader is put last. - Also several fixes were made to places where reference counts were not being held. - Make this one of the tests in 'make -C tools/perf build-test' to regularly build test it and to make sure no direct access to the reference counted structs are made, doing that via accessors to check the validity of the struct pointer. ARM64: - Fix 'perf report' segfault when filtering coresight traces by sparse lists of CPUs. - Add support for 'simd' as a sort field for 'perf report', to show ARM's NEON SIMD's predicate flags: "partial" and "empty". arm64 vendor events: - Add N1 metrics. Intel vendor events: - Add graniterapids, grandridge and sierraforrest events. - Refresh events for: alderlake, aldernaken, broadwell, broadwellde, broadwellx, cascadelakx, haswell, haswellx, icelake, icelakex, jaketown, meteorlake, knightslanding, sandybridge, sapphirerapids, silvermont, skylake, tigerlake and westmereep-dp - Refresh metrics for alderlake-n, broadwell, broadwellde, broadwellx, haswell, haswellx, icelakex, ivybridge, ivytown and skylakex. perf stat: - Implement --topdown using JSON metrics. - Add TopdownL1 JSON metric as a default if present, but disable it for now for some Intel hybrid architectures, a series of patches addressing this is being reviewed and will be submitted for v6.5. - Use metrics for --smi-cost. - Update topdown documentation. Vendor events (JSON) infrastructure: - Add support for computing and printing metric threshold values. For instance, here is one found in thesapphirerapids json file: { "BriefDescription": "Percentage of cycles spent in System Management Interrupts.", "MetricExpr": "((msr@aperf@ - cycles) / msr@aperf@ if msr@smi@ > 0 else 0)", "MetricGroup": "smi", "MetricName": "smi_cycles", "MetricThreshold": "smi_cycles > 0.1", "ScaleUnit": "100%" }, - Test parsing metric thresholds with the fake PMU in 'perf test pmu-events'. - Support for printing metric thresholds in 'perf list'. - Add --metric-no-threshold option to 'perf stat'. - Add rand (reverse and) and has_pmem (optane memory) support to metrics. - Sort list of input files to avoid depending on the order from readdir() helping in obtaining reproducible builds. S/390: - Add common metrics: - CPI (cycles per instruction), prbstate (ratio of instructions executed in problem state compared to total number of instructions), l1mp (Level one instruction and data cache misses per 100 instructions). - Add cache metrics for z13, z14, z15 and z16. - Add metric for TLB and cache. ARM: - Add raw decoding for SPE (Statistical Profiling Extension) v1.3 MTE (Memory Tagging Extension) and MOPS (Memory Operations) load/store. Intel PT hardware tracing: - Add event type names UINTR (User interrupt delivered) and UIRET (Exiting from user interrupt routine), documented in table 32-50 "CFE Packet Type and Vector Fields Details" in the Intel Processor Trace chapter of The Intel SDM Volume 3 version 078. - Add support for new branch instructions ERETS and ERETU. - Fix CYC timestamps after standalone CBR ARM CoreSight hardware tracing: - Allow user to override timestamp and contextid settings. - Fix segfault in dso lookup. - Fix timeless decode mode detection. - Add separate decode paths for timeless and per-thread modes. auxtrace: - Fix address filter entire kernel size. Miscellaneous: - Fix use-after-free and unaligned bugs in the PLT handling routines. - Use zfree() to reduce chances of use after free. - Add missing 0x prefix for addresses printed in hexadecimal in 'perf probe'. - Suppress massive unsupported target platform errors in the unwind code. - Fix return incorrect build_id size in elf_read_build_id(). - Fix 'perf scripts intel-pt-events.py' IPC output for Python 2 . - Add missing new parameter in kfree_skb tracepoint to the python scripts using it. - Add 'perf bench syscall fork' benchmark. - Add support for printing PERF_MEM_LVLNUM_UNC (Uncached access) in 'perf mem'. - Fix wrong size expectation for perf test 'Setup struct perf_event_attr' caused by the patch adding perf_event_attr::config3. - Fix some spelling mistakes" * tag 'perf-tools-for-v6.4-3-2023-05-06' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (365 commits) Revert "perf build: Make BUILD_BPF_SKEL default, rename to NO_BPF_SKEL" Revert "perf build: Warn for BPF skeletons if endian mismatches" perf metrics: Fix SEGV with --for-each-cgroup perf bpf skels: Stop using vmlinux.h generated from BTF, use subset of used structs + CO-RE perf stat: Separate bperf from bpf_profiler perf test record+probe_libc_inet_pton: Fix call chain match on x86_64 perf test record+probe_libc_inet_pton: Fix call chain match on s390 perf tracepoint: Fix memory leak in is_valid_tracepoint() perf cs-etm: Add fix for coresight trace for any range of CPUs perf build: Fix unescaped # in perf build-test perf unwind: Suppress massive unsupported target platform errors perf script: Add new parameter in kfree_skb tracepoint to the python scripts using it perf script: Print raw ip instead of binary offset for callchain perf symbols: Fix return incorrect build_id size in elf_read_build_id() perf list: Modify the warning message about scandirat(3) perf list: Fix memory leaks in print_tracepoint_events() perf lock contention: Rework offset calculation with BPF CO-RE perf lock contention: Fix struct rq lock access perf stat: Disable TopdownL1 on hybrid perf stat: Avoid SEGV on counter->name ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull debugobjects fix from Thomas Gleixner: "A single fix for debugobjects: The recent fix to ensure atomicity of lookup and allocation inadvertently broke the pool refill mechanism, so that debugobject OOMs now in certain situations. The reason is that the functions which got updated no longer invoke debug_objecs_init(), which is now the only place to care about refilling the tracking object pool. Restore the original behaviour by adding explicit refill opportunities to those places" * tag 'core-debugobjects-2023-05-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: debugobject: Ensure pool refill (again)
-