- 23 Dec, 2023 4 commits
-
-
Andy Shevchenko authored
Update header inclusions to follow IWYU (Include What You Use) principle. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20231221144447.2762077-1-andriy.shevchenko@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Merge tag 'counter-updates-for-6.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-next William writes: First set of Counter updates for the 6.8 cycle A new Counter tool is introduced to provide a generic and flexible way to watch Counter device events from userspace. * tag 'counter-updates-for-6.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter: tools/counter: Remove unneeded semicolon tools/counter: Fix spelling mistake "componend" -> "component" MAINTAINERS: add myself as counter watch events tool maintainer tools/counter: add a flexible watch events tool
-
Greg Kroah-Hartman authored
Merge tag 'fpga-for-6.8-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga into char-misc-next Xu writes: FPGA Manager changes for 6.8-rc1 second part Not sure if it's too late for 6.8 rc1, but I try to speed up this intermediate change. - Uwe's change convert to new platform remove callback. All patches have been reviewed on the mailing list, and have been in the last linux-next releases (as part of our for-next branch). Signed-off-by:
Xu Yilun <yilun.xu@intel.com> * tag 'fpga-for-6.8-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga: fpga: zynq-fpga: Convert to platform remove callback returning void fpga: xilinx-pr-decoupler: Convert to platform remove callback returning void fpga: stratix10-soc: Convert to platform remove callback returning void fpga: socfpga-a10: Convert to platform remove callback returning void fpga: of-fpga-region: Convert to platform remove callback returning void fpga: intel-m10-bmc-sec-update: Convert to platform remove callback returning void fpga: dfl-fme-region: Convert to platform remove callback returning void fpga: dfl-fme-main: Convert to platform remove callback returning void fpga: dfl-fme-br: Convert to platform remove callback returning void fpga: dfl-afu-main: Convert to platform remove callback returning void fpga: altera-hps2fpga: Convert to platform remove callback returning void fpga: altera-freeze-bridge: Convert to platform remove callback returning void fpga: altera-fpga2sdram: Convert to platform remove callback returning void
-
Greg Kroah-Hartman authored
Merge tag 'icc-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next Georgi writes: interconnect changes for 6.8 This pull request contains the interconnect changes for the 6.8-rc1 merge window. These are just driver changes with the following highlights: Driver changes: - New interconnect driver for the SM8650 platform. - New interconnect driver for the SM6115 platform. - New interconnect driver for the X1E80100 (Snapdragon X Elite) platform. - Add compatible string for the BWMONv4 instance on the QCM2290 platform. - Complete the platform drivers conversion to the .remove_new callback returning void (mostly iMX, Exynos and the rest of Qcom drivers). Signed-off-by:
Georgi Djakov <djakov@kernel.org> * tag 'icc-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc: interconnect: qcom: sm6115: Fix up includes dt-bindings: interconnect: qcom,msm8998-bwmon: Add QCM2290 bwmon instance dt-bindings: interconnect: qcom,msm8998-bwmon: Add SM6115 bwmon instance interconnect: qcom: Add SM6115 interconnect provider driver dt-bindings: interconnect: Add Qualcomm SM6115 NoC interconnect: qcom: Add X1E80100 interconnect provider driver dt-bindings: interconnect: Add Qualcomm X1E80100 SoC dt-bindings: interconnect: qcom-bwmon: document SM8650 BWMONs interconnect: qcom: introduce RPMh Network-On-Chip Interconnect on SM8650 SoC dt-bindings: interconnect: document the RPMh Network-On-Chip Interconnect in Qualcomm SM8650 SoC interconnect: exynos: Convert to platform remove callback returning void interconnect: qcom/smd-rpm: Convert to platform remove callback returning void interconnect: qcom/osm-l3: Convert to platform remove callback returning void interconnect: qcom/msm8974: Convert to platform remove callback returning void interconnect: imx8mq: Convert to platform remove callback returning void interconnect: imx8mp: Convert to platform remove callback returning void interconnect: imx8mn: Convert to platform remove callback returning void interconnect: imx8mm: Convert to platform remove callback returning void interconnect: qcom: Make qnoc_remove return void
-
- 21 Dec, 2023 14 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Xu Yilun <yilun.xu@linux.intel.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'w1-drv-6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-w1 into char-misc-next Krzysztof writes: 1-Wire bus drivers for v6.8 1. Add new AMD AXI 1-wire host driver for AMD programmable logic IP core. 2. Add support for Analog Devices DS28EC20 EEPROM to existing DS2433 driver. 3. Few cleanups in W1 GPIO driver. * tag 'w1-drv-6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-w1: w1: ds2433: add support for ds28ec20 eeprom w1: ds2433: use the kernel bitmap implementation w1: ds2433: introduce a configuration structure w1: ds2433: remove unused definitions w1: ds2490: support block sizes larger than 128 bytes in ds_read_block w1: amd_axi_w1: Explicitly include correct DT includes w1: gpio: rename pointer to driver data from pdata to ddata w1: gpio: Drop unused enable_external_pullup from driver data w1: gpio: Don't use platform data for driver data w1: Add AXI 1-wire host driver for AMD programmable logic IP core dt-bindings: w1: Add AMD AXI w1 host and MAINTAINERS entry
-
- 20 Dec, 2023 8 commits
-
-
Yang Li authored
./tools/counter/counter_watch_events.c:233:3-4: Unneeded semicolon ./tools/counter/counter_watch_events.c:234:2-3: Unneeded semicolon ./tools/counter/counter_watch_events.c:333:2-3: Unneeded semicolon Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7782Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Reviewed-by:
Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20231220005143.84987-1-yang.lee@linux.alibaba.comSigned-off-by:
William Breathitt Gray <william.gray@linaro.org>
-
Colin Ian King authored
There are two spelling mistakes in the help text. Fix them. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
-
Greg Kroah-Hartman authored
Merge tag 'iio-for-6.8a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next Jonathan writes: 1st set of IIO new device support, features and cleanup for 6.8 New device support ------------------ adi,hmc425a * Add support for ADRF5740 attenuators. Minor changes to driver needed alongside new IDs. aosong,ags02ma * New driver for this volatile organic compounds sensor. bosch,bmp280 * Add BMP390 (small amount of refactoring + ID) bosch,bmi323 * New driver to support the BMI323 6-axis IMU. honeywell,hsc030pa * New driver supporting a huge number of SSC and HSC series pressure and temperature sensors. isil,isl76682 * New driver for this simple Ambient Light sensor. liteon,ltr390 * New driver for this ambient and ultraviolet light sensor. maxim,max34408 * New driver to support the MAX34408 and MAX34409 current monitoring ADCs. melexis,mlx90635 * New driver for this Infrared contactless temperature sensor. mirochip,mcp9600 * New driver for this thermocouple EMF convertor. ti,hdc3020 * New driver for this integrated relative humidity and temperature sensor. vishay,veml6075 * New driver for this UVA and UVB light sensor. General features ---------------- Device properties * Add fwnode_property_match_property_string() helper to allow matching single value property against an array of predefined strings. * Use fwnode_property_string_array_count() inside fwnode_property_match_string() instead of open coding the same. checkpatch.pl * Add exclusion of __aligned() from a warning reducing false positives on IIO drivers (and hopefully beyond) IIO Features ------------ core * New light channel modifiers for UVA and UVB. * Add IIO_CHAN_INFO_TROUGH as counterpart to IIO_CHAN_INFO_PEAK so that we can support device that keep running track of the lowest value they have seen in similar fashion to the existing peak tracking. adi,adis library * Use spi cs inactive delay even when a burst reading is performed. As it's now used every time, can centralize the handling in the SPI setup code in the driver. adi,ad2s1210 * Support for fixed-mode to this resolver driver where the A0 and A1 pins are hard wired to config mode in which case position and config must be read from appropriate config registers. * Support reset GPIO if present. adi,ad5791 * Allow configuration of presence of external amplifier in DT binding. adi,adis16400 * Add spi-cs-inactive-delay-ns to bindings to allow it to be tweaked if default delays are not quite enough for a specific board. adi,adis16475 * Add spi-cs-inactive-delay-ns to bindings to allow it to be tweaked if default delays are not quite enough for a specific board. bosch,bmp280 * Enable multiple chip IDs per family of devices. rohm,bu27008 * Add an illuminance channel calculated from RGB and IR data. Cleanup ------- Minor white space, typos and tidy up not explicitly called out. Core * Check that the available_scan_masks array passed to the IIO core by a driver is sensible by ensuring the entries are ordered so the minimum number of channels is enabled in the earlier entries (as they will be selected if sufficient for the requested channels). * Document that the available_scan_masks infrastructure doesn't currently handle masks that don't fit in a long int. * Improve intensity documentation to reflect that there is no expectation of sensible units (it's dependent on a frequency sensitivity curve) Various * Use new device_property_match_property_string() to replace open coded versions of the same thing. * Fix a few MAINTAINERS filenames. * i2c_get_match_data() and spi_get_device_match_data() pushed into more drivers reducing boilerplate handling. * Some unnecessary headers removed. * ACPI_PTR() removals. It's rarely worth using this. adi,ad7091r (early part of a series adding device support - useful in their own right) * Pass iio_dev directly an event handler rather than relying on broken use of dev_get_drvdata() as drvdata is never set in this driver. * Make sure alert is turned on. adi,ad9467 (general driver fixing up as precursor to iio-backend proposal which is under review for 6.9) * Fix reset gpio handling to match expected polarity. * Always handle error codes from spi_writes. * Add a driver instance local mutex to avoid some races. * Fix scale setting to align with available scale values. * Split array of chip_info structures up into named individual elements. * Convert to regmap. honeywell,mprls0025pa * Drop now unnecessary type references in DT binding for properties in pascals. invensense,mpu6050 * Don't eat a potentially useful return value from regmap_bulk_write() invensense,icm42600 * Use max macro to improve code readability and save a few lines. liteon,ltrf216a * Improve prevision of light intensity. microchip,mcp3911 * Use cleanup.h magic. qcom,spmi* * Fix wrong descriptions of SPMI reg fields in bindings. Other ---- mailmap * Update for Matt Ranostay * tag 'iio-for-6.8a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (83 commits) iio: adc: ad7091r: Align arguments to function call parenthesis iio: adc: ad7091r: Set alert bit in config register iio: adc: ad7091r: Pass iio_dev to event handler scripts: checkpatch: Add __aligned to the list of attribute notes iio: chemical: add support for Aosong AGS02MA dt-bindings: iio: chemical: add aosong,ags02ma dt-bindings: vendor-prefixes: add aosong iio: accel: bmi088: update comments and Kconfig dt-bindings: iio: humidity: Add TI HDC302x support iio: humidity: Add driver for ti HDC302x humidity sensors iio: ABI: document temperature and humidity peak/trough raw attributes iio: core: introduce trough info element for minimum values iio: light: driver for Lite-On ltr390 dt-bindings: iio: light: add ltr390 iio: light: isl76682: remove unreachable code iio: pressure: driver for Honeywell HSC/SSC series dt-bindings: iio: pressure: add honeywell,hsc030 doc: iio: Document intensity scale as poorly defined dt-bindings: iio: temperature: add MLX90635 device iio: temperature: mlx90635 MLX90635 IR Temperature sensor ...
-
Marc Ferland authored
The ds28ec20 eeprom is (almost) backward compatible with the ds2433. The only differences are: - the eeprom size is now 2560 bytes instead of 512; - the number of pages is now 80 (same page size as the ds2433: 256 bits); - the programming time has increased from 5ms to 10ms; This patch adds support for the ds28ec20 to the ds2433 driver. From the datasheet: The DS28EC20 provides a high degree of backward compatibility with the DS2433. Besides the different family codes, the only protocol change that is required on an existing DS2433 implementation is a lengthening of the programming duration (tPROG) from 5ms to 10ms. dmesg now returns: w1_master_driver w1_bus_master1: Attaching one wire slave 43.000000478756 crc e0 instead of: w1_master_driver w1_bus_master1: Attaching one wire slave 43.000000478756 crc e0 w1_master_driver w1_bus_master1: Family 43 for 43.000000478756.e0 is not registered. Test script writing/reading random data (CONFIG_W1_SLAVE_DS2433_CRC is not set): #!/bin/sh EEPROM=/sys/bus/w1/devices/43-000000478756/eeprom BINFILE1=/home/root/file1.bin BINFILE2=/home/root/file2.bin for BS in 1 2 3 4 8 16 32 64 128 256 512 1024 2560; do dd if=/dev/random of=${BINFILE1} bs=${BS} count=1 status=none dd if=${BINFILE1} of=${EEPROM} status=none dd if=${EEPROM} of=${BINFILE2} bs=${BS} count=1 status=none if ! cmp --silent ${BINFILE1} ${BINFILE2}; then echo file1 hexdump ${BINFILE1} echo file2 hexdump ${BINFILE2} echo FAIL exit 1 fi echo "${BS} OK!" done Results: # ./test.sh 1 OK! 2 OK! 3 OK! 4 OK! 8 OK! 16 OK! 32 OK! 64 OK! 128 OK! 256 OK! 512 OK! 1024 OK! 2560 OK! Tests with CONFIG_W1_SLAVE_DS2433_CRC=y: $ cat /proc/config.gz | gunzip | grep CONFIG_W1_SLAVE_DS2433 CONFIG_W1_SLAVE_DS2433=m CONFIG_W1_SLAVE_DS2433_CRC=y # create a 32 bytes block with a crc, i.e.: 00000000 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 |123456789:;<=>?@| 00000010 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e ba 63 |ABCDEFGHIJKLMN.c| # fill all 80 blocks $ dd if=test.bin of=/sys/bus/w1/devices/43-000000478756/eeprom bs=32 count=80 # read back all blocks, i.e.: $ hexdump -C /sys/bus/w1/devices/43-000000478756/eeprom 00000000 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 |123456789:;<=>?@| 00000010 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e ba 63 |ABCDEFGHIJKLMN.c| 00000020 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 |123456789:;<=>?@| 00000030 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e ba 63 |ABCDEFGHIJKLMN.c| ... 000009e0 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 |123456789:;<=>?@| 000009f0 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e ba 63 |ABCDEFGHIJKLMN.c| 00000a00 Note: both memories (ds2433 and ds28ec20) have been tested with the new driver. Signed-off-by:Marc Ferland <marc.ferland@sonatest.com> Co-developed-by:
Jean-Francois Dagenais <jeff.dagenais@gmail.com> Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
-
Marc Ferland authored
The ds2433 driver uses the 'validcrc' variable to mark out which pages have been successfully (crc is valid) retrieved from the eeprom and placed in the internal 'memory' buffer (see CONFIG_W1_SLAVE_DS2433_CRC). The current implementation assumes that the number of pages will never go beyond 32 pages (bit field is a u32). This is fine for the ds2433 since it only has 16 pages. On the ds28ec20 though, the number of pages increases to 80 which will not fit on a single u32. As a solution, I replaced the u32 variable with a standard bitmap and set the number of bits to 32 which is the same size we had before. Signed-off-by:
-
Marc Ferland authored
Add a ds2433_config structure for parameters that are different between the ds2433 and the ds28ec20. The goal is to reuse the same code for both chips. A pointer to this config structure is added to w1_f23_data and the CONFIG_W1_SLAVE_DS2433_CRC ifdefs are adjusted since now both driver configurations (with or without crc support) will make use of w1_f23_data. Also, the 'memory' buffer is now dynamically allocated based on the size specififed in the config structure to help support memories of different sizes. Signed-off-by:
-
Marc Ferland authored
Both W1_F23_TIME and W1_PAGE_COUNT are unused, get rid of them. Signed-off-by:
-
Marc Ferland authored
The current ds_read_block function only supports block sizes up to 128 bytes, which is the depth of the 'data out' fifo on the ds2490. Reading larger blocks will fail with a: -110 (ETIMEDOUT) from usb_control_msg(). Example: $ dd if=/sys/bus/w1/devices/43-000000478756/eeprom bs=256 count=1 yields to the following message from the kernel: usb 5-1: Failed to write 1-wire data to ep0x2: err=-110. I discovered this issue while implementing support for the ds28ec20 eeprom in the w1-2433 driver. This driver accepts reading blocks of sizes up to the size of the entire memory (2560 bytes in the case of the ds28ec20). Note that this issue _does not_ arise when the kernel is configured with CONFIG_W1_SLAVE_DS2433_CRC enabled since in this mode the driver reads one 32 byte block at a time (a single memory page). Also, from the ds2490 datasheet (2995.pdf, page 22, BLOCK I/O command): For a block write sequence the EP2 FIFO must be pre-filled with data before command execution. Additionally, for block sizes greater then the FIFO size, the FIFO content status must be monitored by host SW so that additional data can be sent to the FIFO when necessary. A similar EP3 FIFO content monitoring requirement exists for block read sequences. During a block read the number of bytes loaded into the EP3 FIFO must be monitored so that the data can be read before the FIFO overflows. Breaking the block in smaller 128 bytes chunks and simply calling the original code sequence has solved the issue for me. Tested with a DS1490F usb<->one-wire adapter and both the DS28EC20 and DS2433 eeprom memories. Signed-off-by:
-
- 19 Dec, 2023 2 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'extcon-next-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next Chanwoo writes: Update extcon next for v6.8 Detailed description for this pull request: 1. Fix possible memory leak of device name in extcon_dev_register() : Fix memory leak on error path of extcon_dev_register(). 2. Set interrupt polarity based on device-tree for extcon-usbc-tusb320.c :Remove 'IRQF_TRIGGER_FALLING' request which is not allowed on every interrupt controller (i.e. arm64 GIC). Replace flag by a request that depends on the actual device-tree setting. 3. Fix the comment style according to guide on extcon-qcom-spmi-misc.c. * tag 'extcon-next-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon: extcon: qcom-spmi-misc: don't use kernel-doc marker for comment extcon: usbc-tusb320: Set interrupt polarity based on device-tree extcon: fix possible name leak in extcon_dev_register()
-
Greg Kroah-Hartman authored
Merge tag 'mhi-for-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi into char-misc-next Manivannan writes: MHI Host ======== - Added alignment check for event ring read pointer to avoid the potential buffer corruption issue. - Added support for SDX75 modem which takes longer time to enter READY state. - Added spinlock to protect concurrent access while queuing transfer ring elements. - Dropped the read channel lock before invoking the client callback as the client can potentially queue buffers thus ending up wtih soft lockup. MHI Endpoint ============ - Used kzalloc() to allocate event ring elements instead of allocating the elements on the stack, as the endpoint controller trying to queue them may not be able to use vmalloc memory (using DMA). - Used slab allocator for allocting the memory for objects used frequently and are of fixed size. - Added support for interrupt moderation timer feature which is used by the host to limit the number of interrupts raised by the device for an event ring. - Added async read/write DMA support for transferring data between host and the endpoint. So far MHI EP stack assumed that the data will be transferred synchronously (i.e., it sends completion once the transfer APIs are returned). But this impacts the throughput if the controller is using DMA to do the transfer. So to add async suport, existing sync transfer APIs are renamed to {read/write}_sync and also introduced two new APIs {read/write}_async for carrying out the async transfer. Controllers implementing the async APIs should queue the buffers and return immediately without waiting for transfer completion. Once the transfer completion happens later, they should invoke the completion callback so that the MHI EP stack can send the completion event to the host. The controller driver patches (PCI EPF) for this async support are also merged to the MHI tree with Acks from PCI maintainers. - Fixed the DMA channel direction in error path of the PCI EPF driver. * tag 'mhi-for-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi: bus: mhi: host: Drop chan lock before queuing buffers bus: mhi: host: Add spinlock to protect WP access when queueing TREs PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single() bus: mhi: ep: Add checks for read/write callbacks while registering controllers bus: mhi: ep: Add support for async DMA read operation bus: mhi: ep: Add support for async DMA write operation PCI: epf-mhi: Enable MHI async read/write support PCI: epf-mhi: Add support for DMA async read/write operation PCI: epf-mhi: Simulate async read/write using iATU bus: mhi: ep: Introduce async read/write callbacks bus: mhi: ep: Rename read_from_host() and write_to_host() APIs bus: mhi: ep: Pass mhi_ep_buf_info struct to read/write APIs bus: mhi: ep: Add support for interrupt moderation timer bus: mhi: ep: Use slab allocator where applicable bus: mhi: host: Add alignment check for event ring read pointer bus: mhi: host: pci_generic: Add SDX75 based modem support bus: mhi: host: Add a separate timeout parameter for waiting ready bus: mhi: ep: Do not allocate event ring element on stack
-
- 18 Dec, 2023 3 commits
-
-
Fabrice Gasnier authored
Add MAINTAINERS entry for the counter watch events tool. William has been asking to add at least me as the point of contact for this utility. Signed-off-by:
-
Fabrice Gasnier authored
This adds a new counter tool to be able to test various watch events. A flexible watch array can be populated from command line, each field may be tuned with a dedicated command line sub-option in "--watch" string. Several watch events can be defined, each can have specific watch options, by using "--watch <watch 1 options> --watch <watch 2 options>". Watch options is a comma separated list. It also comes with a simple default watch (to monitor overflow/underflow events), used when no watch parameters are provided. It's equivalent to: counter_watch_events -w comp_count,scope_count,evt_ovf_udf The print_usage() routine proposes another example, from the command line, which generates a 2 elements watch array, to monitor: - overflow underflow events - capture events, on channel 3, that reads read captured data by specifying the component id (capture3_component_id being 7 here). Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'fpga-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga into char-misc-next Xu writes: FPGA Manager changes for 6.8-rc1 DFL: - Philipp's change uses memdup_array_user() to do better overflow check All patches have been reviewed on the mailing list, and have been in the last linux-next releases (as part of our for-next branch). Signed-off-by:
-
- 17 Dec, 2023 9 commits
-
-
Marcelo Schmitt authored
Align arguments to function call open parenthesis to comply with the Linux kernel coding style. Signed-off-by:
Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://lore.kernel.org/r/fc71a82d3b4a6bc6f511f27451dbd7a3280a8c95.1702746240.git.marcelo.schmitt1@gmail.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marcelo Schmitt authored
The ad7091r-base driver sets up an interrupt handler for firing events when inputs are either above or below a certain threshold. However, for the interrupt signal to come from the device it must be configured to enable the ALERT/BUSY/GPO pin to be used as ALERT, which was not being done until now. Enable interrupt signals on the ALERT/BUSY/GPO pin by setting the proper bit in the configuration register. Signed-off-by:
-
Marcelo Schmitt authored
Previous version of ad7091r event handler received the ADC state pointer and retrieved the iio device from driver data field with dev_get_drvdata(). However, no driver data have ever been set, which led to null pointer dereference when running the event handler. Pass the iio device to the event handler and retrieve the ADC state struct from it so we avoid the null pointer dereference and save the driver from filling the driver data field. Fixes: ca693001 ("iio: adc: Add support for AD7091R5 ADC") Signed-off-by:
-
Marcelo Schmitt authored
Checkpatch presumes attributes marked with __aligned(alignment) are part of a function declaration and throws a warning stating that those compiler attributes should have an identifier name which is not correct. Add __aligned compiler attributes to the list of attribute notes so they don't cause warnings anymore. Signed-off-by:
Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/1c5c93ecbd8c46a338b22a4ef52e51648e333c01.1702746240.git.marcelo.schmitt1@gmail.comSigned-off-by:
-
Anshul Dalal authored
A simple driver for the TVOC (Total Volatile Organic Compounds) sensor from Aosong: AGS02MA Steps in reading the VOC sensor value over i2c: 1. Read 5 bytes from the register `AGS02MA_TVOC_READ_REG` [0x00] 2. The first 4 bytes are taken as the big endian sensor data with final byte being the CRC 3. The CRC is verified and the value is returned over an `IIO_CHAN_INFO_RAW` channel as percents Tested on Raspberry Pi Zero 2W Datasheet: https://asairsensors.com/wp-content/uploads/2021/09/AGS02MA.pdfSigned-off-by:Anshul Dalal <anshulusr@gmail.com> Link: https://lore.kernel.org/r/20231215162312.143568-3-anshulusr@gmail.comSigned-off-by:
-
Anshul Dalal authored
Add bindings for Aosong AGS02MA TVOC sensor. The sensor communicates over i2c with the default address 0x1a. TVOC values can be read in the units of ppb and ug/m^3 at register 0x00. Datasheet: https://asairsensors.com/wp-content/uploads/2021/09/AGS02MA.pdfReviewed-by:
-
Anshul Dalal authored
Aosong Electronic Co., LTD. is a supplier for MEMS sensors such as AHT20 temperature and humidity sensor under the brand name Asair Acked-by:
-
Jun Yan authored
update the comments and Kconfig file with more descriptive and accurate information about newly added device: BMI085, BMI090L. Signed-off-by:
Jun Yan <jerrysteve1101@gmail.com> Signed-off-by:
-
Ayush Singh authored
Make gb-beagleplay greybus spec compliant by moving cport information to transport layer instead of using `header->pad` bytes. Greybus HDLC frame now has the following payload: 1. le16 cport 2. gb_operation_msg_hdr msg_header 3. u8 *msg_payload Fixes: ec558bbf ("greybus: Add BeaglePlay Linux Driver") Signed-off-by:
Ayush Singh <ayushdevel1325@gmail.com> Link: https://lore.kernel.org/r/20231217121133.74703-2-ayushdevel1325@gmail.comSigned-off-by:
-
