kernel/drivers/w1, 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: make w1_bus_type const

2024-02-15T13:55:05Z

Now that the driver core can properly handle constant struct bus_type, move the w1_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman Suggested-by: Greg Kroah-Hartman Signed-off-by: Ricardo B. Marliere Link: https://lore.kernel.org/r/20240204-bus_cleanup-w1-v1-1-a0f4c84d7db3@marliere.net Signed-off-by: Krzysztof Kozlowski

w1: ds2433: add support for ds28ec20 eeprom

2023-12-20T08:25:25Z

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 Co-developed-by: Jean-Francois Dagenais Signed-off-by: Jean-Francois Dagenais Link: https://lore.kernel.org/r/20231218150230.1992448-6-marc.ferland@sonatest.com Signed-off-by: Krzysztof Kozlowski

w1: ds2433: use the kernel bitmap implementation

2023-12-20T08:25:25Z

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 Link: https://lore.kernel.org/r/20231218150230.1992448-5-marc.ferland@sonatest.com Signed-off-by: Krzysztof Kozlowski

w1: ds2433: introduce a configuration structure

2023-12-20T08:25:25Z

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 Link: https://lore.kernel.org/r/20231218150230.1992448-4-marc.ferland@sonatest.com Signed-off-by: Krzysztof Kozlowski

w1: ds2433: remove unused definitions

2023-12-20T08:25:25Z

Both W1_F23_TIME and W1_PAGE_COUNT are unused, get rid of them. Signed-off-by: Marc Ferland Link: https://lore.kernel.org/r/20231218150230.1992448-3-marc.ferland@sonatest.com Signed-off-by: Krzysztof Kozlowski