Skip to contentSkip to conversation

spi: spidev: Fix for reverting spi max speed value only on failure

PATCH In review Vivek Pernamitta 2 participants 2 messages Jun 2, 2019 – Jun 3, 2019 SPI

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 spi: spidev: Fix for reverting spi max speed value only on failure

When user space application request for change in spi clock using ioctl, current value is taken back-up and new value is assigned to spi->max_speed_hz, then spi_setup() function is called with new value. If spi_setup() function fails, it needs reverting to old spi_max_speed value only in failure condition.

---
 drivers/spi/spidev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/spi/spidev.c +3 -2
index 30498cf25f3b..70382b642f37 100644
@@ -458,9 +458,10 @@ spidev_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 			retval = spi_setup(spi);
 			if (retval >= 0)
 				spidev->speed_hz = tmp;
-			else
+			else {
 				dev_dbg(&spi->dev, "%d Hz (max)\n", tmp);
-			spi->max_speed_hz = save;
+				spi->max_speed_hz = save;
+			}
 		}
 		break;
 
Signature · 1 line
2.17.1
maintainer
#1 lore raw
Quoted 5 lines · Vivek Pernamitta

When user space application request for change in spi clock using ioctl, current value is taken back-up and new value is assigned to spi->max_speed_hz, then spi_setup() function is called with new value. If spi_setup() function fails, it needs reverting to old spi_max_speed value only in failure condition.

The current behaviour is intentional, we're not modifying max_speed_hz so we can continue to enforce the kernel limit no matter what userspace asked for - actually looking at the code we should probably have an explicit error check in there to reject attempts to raise it here, not sure why we're not doing that already.