D_CAN problems after devm_ioremap_resource conversion.

D_CAN problems after devm_ioremap_resource conversion.

[T Thayer]

Hello.

I've run into a problem with the Altera CycloneV SoCFPGA D_CAN driver
implementation after the devm_request_and_ioremap() to
devm_ioremap_resources() change (git commit
32766fff24a761079636bb96c389411d24a334c6. As another data point, I do
not have problems with 3.10 (which did not have the
devm_ioremap_resources() change).

I looked through the CAN mailing list archives but could not find any
issues that matched my symptoms.

Board #1 running 3.11 (git commit
d25903f894849fa799141e774c4ad34199e3e6a1) that I configure as:
canconfig can0 bitrate 500000
canconfig can0 start
candump can0


Board #2 running 3.10 that I configure as:
canconfig can0 bitrate 500000
canconfig can0 start
cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

But nothing appears on the Board#1 dump.

The strange thing is that if I type something (ie. the letter "A") in
Board#1's terminal window and then change to Board#2's terminal window
and do another
cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

then 2 messages show up on the candump (the original one and the one
just sent). From then on, typing
cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

shows up on Board#1. It almost seems like typing any character in
Board#1's terminal (which is waiting for data via candump) frees up
the candump buffer printout.

I don't know if this is an issue with candump or with the CAN driver.
It doesn't seem like a candump issue because it works OK if I revert
and rebuild the kernel before the above commit.  (and it breaks if I
update my tree to after the above commit and rebuild).

Thank you for any insight you may have,

Thor

Re: D_CAN problems after devm_ioremap_resource conversion.

[Tushar Behera]

On 26 September 2013 02:06, T Thayer <tthayer.linux@gmail.com> wrote:
> Hello.
>
> I've run into a problem with the Altera CycloneV SoCFPGA D_CAN driver
> implementation after the devm_request_and_ioremap() to
> devm_ioremap_resources() change (git commit
> 32766fff24a761079636bb96c389411d24a334c6. As another data point, I do
> not have problems with 3.10 (which did not have the
> devm_ioremap_resources() change).
>
> I looked through the CAN mailing list archives but could not find any
> issues that matched my symptoms.
>
> Board #1 running 3.11 (git commit
> d25903f894849fa799141e774c4ad34199e3e6a1) that I configure as:
> canconfig can0 bitrate 500000
> canconfig can0 start
> candump can0
>
>
> Board #2 running 3.10 that I configure as:
> canconfig can0 bitrate 500000
> canconfig can0 start
> cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88
>
> But nothing appears on the Board#1 dump.
>
> The strange thing is that if I type something (ie. the letter "A") in
> Board#1's terminal window and then change to Board#2's terminal window
> and do another
> cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88
>
> then 2 messages show up on the candump (the original one and the one
> just sent). From then on, typing
> cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88
>
> shows up on Board#1. It almost seems like typing any character in
> Board#1's terminal (which is waiting for data via candump) frees up
> the candump buffer printout.
>
> I don't know if this is an issue with candump or with the CAN driver.
> It doesn't seem like a candump issue because it works OK if I revert
> and rebuild the kernel before the above commit.  (and it breaks if I
> update my tree to after the above commit and rebuild).
>
> Thank you for any insight you may have,
>
> Thor

I don't have much understanding on how CAN works, hence I won't be of
much help here. Sorry.

Looking at the particular git patch, I can't find anything that would
change the behavior of the code.

-- 
Tushar Behera

Re: D_CAN problems after devm_ioremap_resource conversion.

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

On 09/25/2013 10:36 PM, T Thayer wrote:
> I've run into a problem with the Altera CycloneV SoCFPGA D_CAN driver
> implementation after the devm_request_and_ioremap() to
> devm_ioremap_resources() change (git commit
> 32766fff24a761079636bb96c389411d24a334c6. As another data point, I do
> not have problems with 3.10 (which did not have the
> devm_ioremap_resources() change).

That's good, you can use git bisect to find the patch that introduces
the problem. Use:

    git bisect 32766fff24a761079636bb96c389411d24a334c6 v3.10

then

    <build kernel>
    <test kernel>

if CAN doesn't work anymore

    git bisect bad

if kernel is still functional

    git bisect good

goto <build kernel>.

> I looked through the CAN mailing list archives but could not find any
> issues that matched my symptoms.
> 
> Board #1 running 3.11 (git commit
> d25903f894849fa799141e774c4ad34199e3e6a1) that I configure as:
> canconfig can0 bitrate 500000
> canconfig can0 start
> candump can0
> 
> 
> Board #2 running 3.10 that I configure as:
> canconfig can0 bitrate 500000
> canconfig can0 start
> cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88
> 
> But nothing appears on the Board#1 dump.
> 
> The strange thing is that if I type something (ie. the letter "A") in
> Board#1's terminal window and then change to Board#2's terminal window
> and do another
> cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

How's your terminal connected?
What happens if you send some ping packges to board#1 instead of typing
a letter?

> then 2 messages show up on the candump (the original one and the one
> just sent). From then on, typing
> cansend can0 -i 0x123 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88
> 
> shows up on Board#1. It almost seems like typing any character in
> Board#1's terminal (which is waiting for data via candump) frees up
> the candump buffer printout.

> I don't know if this is an issue with candump or with the CAN driver.
> It doesn't seem like a candump issue because it works OK if I revert
> and rebuild the kernel before the above commit.  (and it breaks if I
> update my tree to after the above commit and rebuild).

Instead of doing the bisect, you can checkout v3.11.1 and revert
32766fff24a761079636bb96c389411d24a334c6.

    git checkout v3.11.1
    git revert 32766fff24a761079636bb96c389411d24a334c6

    <build kernel>
    <test kernel>

Does the kernel work as expected?

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]