kernel/drivers/w1/masters, branch linux-6.9.y

w1: w1-gpio: Convert to platform remove callback returning void

2024-02-20T10:24:34Z

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 Link: https://lore.kernel.org/r/bd69ccde7395cf4bf63765e29c1ce83834d3669b.1708340114.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski

w1: sgi_w1: Convert to platform remove callback returning void

2024-02-20T10:24:34Z

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 Link: https://lore.kernel.org/r/68632fffa01f69eeaddfc0ad9de8f067b164e4fb.1708340114.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski

w1: omap_hdq: Convert to platform remove callback returning void

2024-02-20T10:24:33Z

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 Link: https://lore.kernel.org/r/f3a7eaee59020bf879249304eaaf9839c7e17222.1708340114.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski

w1: mxc_w1: Convert to platform remove callback returning void

2024-02-20T10:24:33Z

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 Link: https://lore.kernel.org/r/d805f3ccc5bc59584c2575b7b33a56a33f6812c7.1708340114.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski

w1: add UART w1 bus driver

2024-02-15T14:02:33Z

Add a UART 1-Wire bus driver. The driver utilizes the UART interface via the Serial Device Bus to create the 1-Wire timing patterns. The driver was tested on a "Raspberry Pi 3B" with a DS18B20 and on a "Variscite DART-6UL" with a DS18S20 temperature sensor. The 1-Wire timing pattern and the corresponding UART baud-rate with the interpretation of the transferred bytes are described in the document: Link: https://www.analog.com/en/technical-articles/using-a-uart-to-implement-a-1wire-bus-master.html In short, the UART peripheral must support full-duplex and operate in open-drain mode. The timing patterns are generated by a specific combination of baud-rate and transmitted byte, which corresponds to a 1-Wire read bit, write bit or reset. Signed-off-by: Christoph Winklhofer Link: https://lore.kernel.org/r/20240214-w1-uart-v7-3-6e21fa24e066@gmail.com [krzysztof: w1_uart_serdev_receive_buf() return type fixup] Signed-off-by: Krzysztof Kozlowski

w1: ds2490: support block sizes larger than 128 bytes in ds_read_block

2023-12-20T08:25:23Z

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: Marc Ferland Link: https://lore.kernel.org/r/20231218150230.1992448-2-marc.ferland@sonatest.com [krzysztof: fix checkpatch 'spaces preferred around'] Signed-off-by: Krzysztof Kozlowski

w1: amd_axi_w1: Explicitly include correct DT includes

2023-12-08T07:35:25Z

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it was merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20231207163318.2727816-1-robh@kernel.org Signed-off-by: Krzysztof Kozlowski

w1: gpio: rename pointer to driver data from pdata to ddata

2023-12-07T13:28:36Z

pdata is a relict when this was still platform data. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/f863cacc485a701268164c9734b6d4aef23dae3e.1701727212.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski

w1: gpio: Drop unused enable_external_pullup from driver data

2023-12-07T13:28:36Z

This member is always NULL, so drop it. That makes the suspend and resume callbacks empty, so they can be dropped, too. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/7009fc53745c8e0336e9379022ce648a60c519f8.1701727212.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski

w1: gpio: Don't use platform data for driver data

2023-12-07T13:28:35Z

struct device's .platform_data isn't for drivers to write to. For driver-specific data there is .driver_data instead. As there is no in-tree platform that provides w1_gpio_platform_data, drop the include file and replace it by a local struct w1_gpio_ddata. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/8f7ebe03ddaa5a5c6e2b36fecdf59da7fc373527.1701727212.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski