Protocol driver probe function never invoked

Hi all,

I'm working with kernel 2.6.21.3 on Freescale iMXL-based platform. I have to write a SPI protocol driver for Quantum QT510 touch controller. As starting point for board-init code I used the driver released by Pavel Pisa:
http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/pimx1-board-spi.patch

In protocol driver I defined spi_driver like this:

static struct spi_driver qt510_driver = {
	.driver = {
		.name		= QT510_MODALIAS,
		.owner		= THIS_MODULE,
	},
	.probe		= qt510_probe,
	.remove		= __devexit_p(qt510_remove),
};

static int __init qt510_init(void)

{
	return spi_register_driver(&qt510_driver);
}

module_init(qt510_init);

In board-init code I used the same name for modalias field:

static struct spi_board_info parsy_spi_board_infos[] __initdata = {
	{
	 .modalias = "loopback",
	 .max_speed_hz = 1600000,
	 .bus_num = 1,
	 .chip_select = 0x00,
	 .mode = SPI_MODE_0,
	 .controller_data = &spi_controller_data[0],
	 },
	{
	 .modalias = QT510_MODALIAS,
	 .max_speed_hz = QT510_SPI_CLK_MAX,
	 .bus_num = 1,
	 .chip_select = 0x01,
	 .mode = SPI_MODE_3,
	 .controller_data = &spi_controller_data[1],
	 },
	{
	 .modalias = "tbd",
	 .max_speed_hz = 1600000,
	 .bus_num = 1,
	 .chip_select = 0x2,
	 .mode = SPI_MODE_0,
	 .controller_data = &spi_controller_data[2],
	 },
};

However the probe function (qt510_probe) is never invoked. In my understanding this is due to the fact that there are no devices associated to the bus:

bash-3.00# ls -la /sys/bus/spi/devices/
total 0

drwxr-xr-x  2 root root 0 Jan  1  1970 .
drwxr-xr-x  4 root root 0 Jan  1  1970 ..
bash-3.00# ls -la /sys/bus/spi/drivers/
total 0
drwxr-xr-x  4 root root 0 Jan  1  1970 .
drwxr-xr-x  4 root root 0 Jan  1  1970 ..
drwxr-xr-x  2 root root 0 Jan  1  1970 qt510
drwxr-xr-x  2 root root 0 Jan  1  1970 spidev

bash-3.00#

Am I missing something?

TIA,
llandre

DAVE Electronics System House - R&D Department

web:   http://www.dave-tech.it
email: r&d2-4VKA1VU3ct/[email protected]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

The probe function is not invoked because the controller does not allow to reach the max_speed_hz.
I did not realize this before because, even if the debug messages were enabled, I did not see any warning message about this.

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2-4VKA1VU3ct/[email protected]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

I want to be sure I understand this correctly. You're saying that the call to spi_setup() inside of spi_new_device() failed silently? And thus the scan_boardinfo() failed?

If so, I'm thinking the following patch would help ... right?

@@ -325,9 +325,17 @@ static void scan_boardinfo(struct spi_ma
 		unsigned		n;
 
 		for (n = bi->n_board_info; n > 0; n--, chip++) {
+			int	status;
+
 			if (chip->bus_num != master->bus_num)
 				continue;
-			(void) spi_new_device(master, chip);
+			status = spi_new_device(master, chip);
+			if (status < 0)
+				dev_err(master->cdev.dev,
+					"can't create spi_device, err %d; "
+					"chipselect %d, modalias %s\n",
+					status, chip->chip_select,
+					chip->modalias);
 		}
 	}
 	mutex_unlock(&board_lock);

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

Helps to run GCC *first* ...

@@ -327,7 +327,12 @@ static void scan_boardinfo(struct spi_ma
 		for (n = bi->n_board_info; n > 0; n--, chip++) {
 			if (chip->bus_num != master->bus_num)
 				continue;
-			(void) spi_new_device(master, chip);
+			if (spi_new_device(master, chip) == NULL)
+				dev_err(master->cdev.dev,
+					"can't create spi_device for "
+					"chipselect %d, modalias %s\n",
+					chip->chip_select,
+					chip->modalias);
 		}
 	}
 	mutex_unlock(&board_lock);

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

No, I did not make myself clear.
I was talking about this code in spi_imx.c:

	/* SPI datarate */
	tmp = spi_data_rate(spi->max_speed_hz);
	if (tmp == SPI_CONTROL_DATARATE_BAD) {
		status = -EINVAL;
		dev_err(&spi->dev,
			"setup - "
			"HW min speed (%d Hz) exceeds required "
			"max speed (%d Hz)\n",
			spi_speed_hz(SPI_CONTROL_DATARATE_MIN),
			spi->max_speed_hz);
		if (first_setup)
			goto err_first_setup;
		else
			/* Undo setup using chip as backup copy */

Since the reference clock feeding the SPI controller was too high, it was not able to generate the required SPI clock. Probably I did not pay enough attention, but it seems kernel did not print these error messages so it took a while to recognize that the this was the problem.

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2-4VKA1VU3ct/[email protected]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/