U-CLASS SPI Bus and Devices
I ran into an issue today with a U-CLASS SPI NOR flash device on a NXP FlexSPI controller. U-Boot started correctly from the flash device but using 'sf probe 0:0' would always return 'Invalid bus 0 (err=-19)'. This error message is emitted by spi_get_bus_and_cs() in drivers/spi/spi-uclass.c. I traced the issue to uclass_get_device_by_seq() in drivers/core/uclass.c.
The function first searches the device list for a device that already claimed the sequence number (dev->seq). If not found it would look if a device requested that sequence number (dev->seq_req). That would always fail for my device. The bus had not been probed yet and hence dev->seq was -1 and the device also had dev->req_seq set to -1.
The board is using a device tree hence it would only make sense to set the requested sequence number via the device tree. However, there is no such thing and even if there was it might not be specified.
Consequently, the device was never probed although the driver was correctly set up via device tree.
I worked around it by simply setting dev->req_seq of the first device that had it set to -1 to the sequence number the search function was looking for (see patch below). It solved my problem but I don't know if that is the right way of addressing it. I could not find any other solution for this particular problem anywhere.
Rudi
From 0f05ab964fcc7d29d8d467e663d7daa72328cf66 Mon Sep 17 00:00:00 2001 From: Rudolf J Streif rudolf.streif@ibeeto.com Date: Tue, 17 Mar 2020 17:13:07 -0700 Subject: [PATCH] Fix issue with SPI device sequence number
If the requested sequence number for a SPI device was -1 (any) then the device would never be probed. This fix simply assigns the sequence number asked for at probing to the device if it has not been probed yet and the requested sequence number is -1.
Signed-off-by: Rudolf J Streif rudolf.streif@ibeeto.com --- drivers/core/uclass.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c index fc3157de39..e791103153 100644 --- a/drivers/core/uclass.c +++ b/drivers/core/uclass.c @@ -310,6 +310,8 @@ int uclass_find_device_by_seq(enum uclass_id id, int seq_or_req_seq,
uclass_foreach_dev(dev, uc) { debug(" - %d %d '%s'\n", dev->req_seq, dev->seq, dev->name); + if (find_req_seq && dev->req_seq == -1) + dev->req_seq = seq_or_req_seq; if ((find_req_seq ? dev->req_seq : dev->seq) == seq_or_req_seq) { *devp = dev;
I ran into an issue today with a U-CLASS SPI NOR flash device on a NXP FlexSPI controller. U-Boot started correctly from the flash device but using 'sf probe 0:0' would always return 'Invalid bus 0 (err=-19)'. This error message is emitted by spi_get_bus_and_cs() in drivers/spi/spi-uclass.c. I traced the issue to uclass_get_device_by_seq() in drivers/core/uclass.c.
The function first searches the device list for a device that already claimed the sequence number (dev->seq). If not found it would look if a device requested that sequence number (dev->seq_req). That would always fail for my device. The bus had not been probed yet and hence dev->seq was -1 and the device also had dev->req_seq set to -1.
The board is using a device tree hence it would only make sense to set the requested sequence number via the device tree. However, there is no such thing and even if there was it might not be specified.
Consequently, the device was never probed although the driver was correctly set up via device tree.
I worked around it by simply setting dev->req_seq of the first device that had it set to -1 to the sequence number the search function was looking for (see patch below). It solved my problem but I don't know if that is the right way of addressing it. I could not find any other solution for this particular problem anywhere.
Rudi
From 0f05ab964fcc7d29d8d467e663d7daa72328cf66 Mon Sep 17 00:00:00 2001 From: Rudolf J Streif rudolf.streif@ibeeto.com Date: Tue, 17 Mar 2020 17:13:07 -0700 Subject: [PATCH] Fix issue with SPI device sequence number
If the requested sequence number for a SPI device was -1 (any) then the device would never be probed. This fix simply assigns the sequence number asked for at probing to the device if it has not been probed yet and the requested sequence number is -1.
Signed-off-by: Rudolf J Streif rudolf.streif@ibeeto.com --- drivers/core/uclass.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c index fc3157de39..e791103153 100644 --- a/drivers/core/uclass.c +++ b/drivers/core/uclass.c @@ -310,6 +310,8 @@ int uclass_find_device_by_seq(enum uclass_id id, int seq_or_req_seq,
uclass_foreach_dev(dev, uc) { debug(" - %d %d '%s'\n", dev->req_seq, dev->seq, dev->name); + if (find_req_seq && dev->req_seq == -1) + dev->req_seq = seq_or_req_seq; if ((find_req_seq ? dev->req_seq : dev->seq) == seq_or_req_seq) { *devp = dev;
Hi Rudolf,
On Wed, 18 Mar 2020 at 05:25, Rudolf J Streif rudolf.streif@ibeeto.com wrote:
I ran into an issue today with a U-CLASS SPI NOR flash device on a NXP FlexSPI controller. U-Boot started correctly from the flash device but using 'sf probe 0:0' would always return 'Invalid bus 0 (err=-19)'. This error message is emitted by spi_get_bus_and_cs() in drivers/spi/spi-uclass.c. I traced the issue to uclass_get_device_by_seq() in drivers/core/uclass.c.
The function first searches the device list for a device that already claimed the sequence number (dev->seq). If not found it would look if a device requested that sequence number (dev->seq_req). That would always fail for my device. The bus had not been probed yet and hence dev->seq was -1 and the device also had dev->req_seq set to -1.
The board is using a device tree hence it would only make sense to set the requested sequence number via the device tree. However, there is no such thing and even if there was it might not be specified.
Consequently, the device was never probed although the driver was correctly set up via device tree.
I worked around it by simply setting dev->req_seq of the first device that had it set to -1 to the sequence number the search function was looking for (see patch below). It solved my problem but I don't know if that is the right way of addressing it. I could not find any other solution for this particular problem anywhere.
Rudi
You can put the SPI flash in the device tree with an alias pointing to it.. That is the intended way with driver model.
Regards, SImon
From 0f05ab964fcc7d29d8d467e663d7daa72328cf66 Mon Sep 17 00:00:00 2001 From: Rudolf J Streif rudolf.streif@ibeeto.com Date: Tue, 17 Mar 2020 17:13:07 -0700 Subject: [PATCH] Fix issue with SPI device sequence number
If the requested sequence number for a SPI device was -1 (any) then the device would never be probed. This fix simply assigns the sequence number asked for at probing to the device if it has not been probed yet and the requested sequence number is -1.
Signed-off-by: Rudolf J Streif rudolf.streif@ibeeto.com
drivers/core/uclass.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c index fc3157de39..e791103153 100644 --- a/drivers/core/uclass.c +++ b/drivers/core/uclass.c @@ -310,6 +310,8 @@ int uclass_find_device_by_seq(enum uclass_id id, int seq_or_req_seq,
uclass_foreach_dev(dev, uc) { debug(" - %d %d '%s'\n", dev->req_seq, dev->seq,dev->name);
if (find_req_seq && dev->req_seq == -1)dev->req_seq = seq_or_req_seq; if ((find_req_seq ? dev->req_seq : dev->seq) == seq_or_req_seq) { *devp = dev;-- 2.23.0
Hi Simon,
Thanks for your response.
On 5/7/20 6:36 PM, Simon Glass wrote:
Hi Rudolf,
On Wed, 18 Mar 2020 at 05:25, Rudolf J Streif rudolf.streif@ibeeto.com wrote:
I ran into an issue today with a U-CLASS SPI NOR flash device on a NXP FlexSPI controller. U-Boot started correctly from the flash device but using 'sf probe 0:0' would always return 'Invalid bus 0 (err=-19)'. This error message is emitted by spi_get_bus_and_cs() in drivers/spi/spi-uclass.c. I traced the issue to uclass_get_device_by_seq() in drivers/core/uclass.c.
The function first searches the device list for a device that already claimed the sequence number (dev->seq). If not found it would look if a device requested that sequence number (dev->seq_req). That would always fail for my device. The bus had not been probed yet and hence dev->seq was -1 and the device also had dev->req_seq set to -1.
The board is using a device tree hence it would only make sense to set the requested sequence number via the device tree. However, there is no such thing and even if there was it might not be specified.
Consequently, the device was never probed although the driver was correctly set up via device tree.
I worked around it by simply setting dev->req_seq of the first device that had it set to -1 to the sequence number the search function was looking for (see patch below). It solved my problem but I don't know if that is the right way of addressing it. I could not find any other solution for this particular problem anywhere.
Rudi
You can put the SPI flash in the device tree with an alias pointing to it.. That is the intended way with driver model.
The board I am using the the FSL/NXP LX2160A-RDB. The dts arch/arm/dts/fsl-lx2160a-rdb.dts defines:
/ { model = "NXP Layerscape LX2160ARDB Board"; compatible = "fsl,lx2160ardb", "fsl,lx2160a";
aliases { spi0 = &fspi; }; };
I am I missing something?
Regards,
Rudi
Regards, SImon
From 0f05ab964fcc7d29d8d467e663d7daa72328cf66 Mon Sep 17 00:00:00 2001 From: Rudolf J Streif rudolf.streif@ibeeto.com Date: Tue, 17 Mar 2020 17:13:07 -0700 Subject: [PATCH] Fix issue with SPI device sequence number
If the requested sequence number for a SPI device was -1 (any) then the device would never be probed. This fix simply assigns the sequence number asked for at probing to the device if it has not been probed yet and the requested sequence number is -1.
Signed-off-by: Rudolf J Streif rudolf.streif@ibeeto.com
drivers/core/uclass.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c index fc3157de39..e791103153 100644 --- a/drivers/core/uclass.c +++ b/drivers/core/uclass.c @@ -310,6 +310,8 @@ int uclass_find_device_by_seq(enum uclass_id id, int seq_or_req_seq,
uclass_foreach_dev(dev, uc) { debug(" - %d %d '%s'\n", dev->req_seq, dev->seq,dev->name);
if (find_req_seq && dev->req_seq == -1)dev->req_seq = seq_or_req_seq; if ((find_req_seq ? dev->req_seq : dev->seq) == seq_or_req_seq) { *devp = dev;-- 2.23.0
Hi Rudolf,
On Tue, 12 May 2020 at 18:02, Rudolf J Streif rudolf.streif@ibeeto.com wrote:
Hi Simon,
Thanks for your response.
On 5/7/20 6:36 PM, Simon Glass wrote:
Hi Rudolf,
On Wed, 18 Mar 2020 at 05:25, Rudolf J Streif rudolf.streif@ibeeto.com wrote:
I ran into an issue today with a U-CLASS SPI NOR flash device on a NXP FlexSPI controller. U-Boot started correctly from the flash device but using 'sf probe 0:0' would always return 'Invalid bus 0 (err=-19)'. This error message is emitted by spi_get_bus_and_cs() in drivers/spi/spi-uclass.c. I traced the issue to uclass_get_device_by_seq() in drivers/core/uclass.c.
The function first searches the device list for a device that already claimed the sequence number (dev->seq). If not found it would look if a device requested that sequence number (dev->seq_req). That would always fail for my device. The bus had not been probed yet and hence dev->seq was -1 and the device also had dev->req_seq set to -1.
The board is using a device tree hence it would only make sense to set the requested sequence number via the device tree. However, there is no such thing and even if there was it might not be specified.
Consequently, the device was never probed although the driver was correctly set up via device tree.
I worked around it by simply setting dev->req_seq of the first device that had it set to -1 to the sequence number the search function was looking for (see patch below). It solved my problem but I don't know if that is the right way of addressing it. I could not find any other solution for this particular problem anywhere.
Rudi
You can put the SPI flash in the device tree with an alias pointing to it.. That is the intended way with driver model.
The board I am using the the FSL/NXP LX2160A-RDB. The dts arch/arm/dts/fsl-lx2160a-rdb.dts defines:
/ { model = "NXP Layerscape LX2160ARDB Board"; compatible = "fsl,lx2160ardb", "fsl,lx2160a";
aliases { spi0 = &fspi; };};
I am I missing something?
That's SPI. I mean actually SPI flash, which would be a subnode of that,
Regards, SImon
participants (2)
-
Rudolf J Streif -
Simon Glass