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(+)

                                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