Bug fix in 'apbuart_cons.c' file ?

[Charles INGELS]

Hi Joel,

until now, I did not receive any answer from Daniel. I do not know if my
feedback has been taken into account, maybe for other users if they have
the same issue.

Nevertheless, the fix seems to work fine with no apparent side effects.

Regards,

Charles



Le 11.04.2017 à 03:29, Joel Sherrill a écrit :
> I'm going to assume that Daniel didn't see this since he didn't comment.
>
> On Apr 10, 2017 2:41 AM, "Charles INGELS" <charles.ingels at syderal.ch
> <mailto:charles.ingels at syderal.ch>> wrote:
>
>     Hello,
>
>     By using the APB Uart BSP on a SPARC LEON3 target, I think that I
>     have found something which seems to be incorrect.
>
>     In my RTEMS app, I just want to receive data through the UART1.
>     Such data are then echoed on the same interface.
>
>     When I want to open the '/dev/apbuart1' descriptor, I get a 'No
>     such file or directory' error message. I get the same error
>     message whatever is the descriptor I try to open ('/dev/apbuart0',
>     ...).
>
>     I am using the driver manager and I have defined the
>     CONFIGURE_DRIVER_AMBAPP_GAISLER_APBUART to have the driver manager
>     create the device descriptors. However, the descriptors are not
>     created.
>
>     I had a look at the content of the following file :
>
>     U:\rtems\src2\rtems\c\src\lib\libbsp\sparc\shared\uart\apbuart_cons.c
>
>     On line #278, the if statement does not explicitly test the value
>     returned by the call to function 'drvmgr_get_dev_prefix()'.
>
>     Since such function returns 0 in case of success, the content of
>     the if statement is never executed. Consequently, the variable
>     'priv->devName' is never initialized to the right string
>     '/dev/apbuart%d', it is always empty which seems to explain why
>     the device descriptor is not not created.
>
>     I have slightly modified the test with the following code :
>
>     if (drvmgr_get_dev_prefix(dev, prefix) != -1)
>     {
>     ...
>     }
>
>     I explicitly test the returned value against -1 (which is
>     considered as an error). With that code, the '/dev/apbuartX'
>     device descriptors are successfully created and communicate with
>     the UART.
>
>     So is it a known bug ? Will it be fixed in the next releases ? Is
>     the way I fixed it correct, or no ?
>
>     Such fix works for me but are there some side effects that shall
>     be taken into account ?
>
>     Thanks for your answers,
>
>     Regards,
>
>     Charles
>
>
>
>
>     -- 
>     *Charles INGELS*
>     Embedded software expert
>     charles.ingels at syderal.ch <mailto:charles.ingels at syderal.ch>
>     Phone /+41 (0)32 338 99 10 <tel:+41%2032%20338%2099%2010>/
>     iNum /+883 5100 0902 7759/
>
>     *SYDERAL SA*
>     Neuenburgstrasse 7
>     CH-3238 Gals (Suisse)
>     Desk /+41 (0)32 338 98 00 <tel:+41%2032%20338%2098%2000>/
>     Fax /+41 (0)32 338 99 34 <tel:+41%2032%20338%2099%2034>/
>     Web site http://www.syderal.ch
>     	
>
>
>     _______________________________________________
>     users mailing list
>     users at rtems.org <mailto:users at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/users
>     <http://lists.rtems.org/mailman/listinfo/users>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170424/c4ba2291/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170424/c4ba2291/attachment-0001.html>