Getting help / reporting bugs in Freescale's code

[PhilEndecott]

What do people here consider the best thing to do with bug reports, or problems that look like bugs but need more investigation, in Freescale's kernel and library code? I'm not aware of a bug tracker. This forum seems to be the only support venue, and it doesn't seem to be overflowing with Freescale people eager to hear about my experiences with their code. What do other people do? Just fix the bugs in your own trees not try to push them anywhere? Here is my current issue: in drivers/mxc/ipu/ipu_device.c, at line 413 there is a call to wait_event_interruptible_timeout that does does not correctly handle signals. It should detect a <0 return from that call and cause the ioctl to return -ERESTARTSYS. That will cause libc to retry the ioctl after the signal handler has run. Instead it returns -1, which is -EPERM; the userspace IPU code assumes this error is a timeout which causes mxc_ipu_lib_task_buf_update to fail. It would be great to have some nice smooth way to discuss and fix such issues, but my fear is that it is not so easy. Would anyone like to prove me wrong?

[sidebranch]

Phil,

just checking, was this issue fixed at some point in Freescale's releases?

Here is my current issue: in drivers/mxc/ipu/ipu_device.c, at line 413 there is a call to wait_event_interruptible_timeout that does does not correctly handle signals. It should detect a <0 return from that call and cause the ioctl to return -ERESTARTSYS.

Regards,

Leon.

[PhilEndecott]

> I never heard of a place where user of BSP can push their patches. Right. I guess what has changed in the last couple of years has been the availability of these "low cost" boards. It seems to me that the purpose of these boards, from the point of view of the silicon vendor, must be precisely so that people like me can help improve the quality of their code (for free). For this to work they need to either push their drivers promptly to mainline so that I can submit patches to the appropriate mainline maintainer, or they need to accept patches directly from me. (Or I guess someone like Linaro can do the work for them. But Linaro's per-vendor activity still seems completely opaque to me.) If they do nothing, then the cheap boards are - from their point of view - not achieving anything. > applying patches coming from users can be a lot of work, > and some time hazardous Come off it, they're not exactly being overwhelmed with people asking "Where do I send this patch?" are they! And the issues that I've found so far are all no-brainers.

[Claude_Sylvain]

Hello Phil,

>
> If I "git clone" imx_2.6.35_11.05.01, I think I will need some Advanced
> Git Skills when they dump the next version. I mean, ideally I would
> push patches and they would get incorporated ASAP - but more realistically,
> Freescale is going to ignore my changes and I'm going to have to carry
> them over locally.
>
> (Am I the only person considering doing this sort of thing?)
>

- I had the same concerns in mind some years ago, when working
  with a ColdFire V4 EVK, and uCLinux.
  And since this time, I never heard of a place where user of BSP can
  push their patches.
  Maybe it is because the process of applying patches coming from
  users can be a lot of work, and some time hazardous.


Just my 2 cents.

Claude

[rlorriaux]

you will want to do a "git rebase" to apply your custom patches to the newest versions.

[PhilEndecott]

> the imx_2.6.35_11.05.01 head appears to be the latest. Right. So from what I can see, Freescale updates this repository with a "code dump" into a new branch for each release, perhaps copied from somewhere else where they're doing the actual work. (I conclude this because the only commits that I see since the branch creation are mainline commits.) If I "git clone" imx_2.6.35_11.05.01, I think I will need some Advanced Git Skills when they dump the next version. I mean, ideally I would push patches and they would get incorporated ASAP - but more realistically, Freescale is going to ignore my changes and I'm going to have to carry them over locally. (Am I the only person considering doing this sort of thing?)

[EricNelson]

No imx_latest branch, but the  imx_2.6.35_11.05.01 head appears to be the latest.

[PhilEndecott]

OK, so now I just need to brush up my git-foo so that I can understand what's there. If I view http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git and look at the "shortlog" or "tags" I see Linus' tagging of 2.6.39 and similar, mixed in with imx_2.6.35_* versions being tagged. I presume that that doesn't mean that I can check out a 2.6.39 that includes the freescale drivers, does it? So is there an "imx_latest" that I could try to track? This could get complicated.....

[EricNelson]

Yeah. This is __much__ easier than the versions in the multiple code drops from Freescale for each target platform (Android, LTIB).

It's also much easier to monitor.

[PhilEndecott]

Hi Eric, http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;... WOW! WOW! WOW!!!!! I had no idea that there was a git repository. Thank you so much for posting that URL. (Why is this not mentioned in any of the docs, websites, etc. that I have read? I have been trying to work with a set of patches in a tarfile inside a tarfile inside a 700-megabyte tarfile. It would have been so much easier to just "git pull".)

[EricNelson]

Hi Phil,

You're right about this not being clear, especially since there isn't a clear "Linux kernel" group and no obvious way to use imxcommunity with an e-mail client.

Many of these types of discussions occur within the Freescale forums at this URL, but I think the intent from 

Freescale is to move toward imxcommunity.

     http://forums.freescale.com/t5/i-MX-Microprocessors/bd-p/IMXCOMM

Does anyone from Freescale want to comment?

Should we create a new "Linux kernel" group?

BTW, Phil, you're absolutely right about the bug in ipu_device.c and it appears to be in the latest sources:

      http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;f=drivers/mxc/ipu3/ipu_device.c;h...