On Wednesday 27 August 2008, Russell King wrote: > I sent a similar patch to the one below against mainline to Tony today. And I'm glad to see those updates. I used to constantly trip over code doing strange stuff in those areas, and it would be nice to see "sparse" approve a lot more driver code... > I've marked some changes with certain tags: > > - FIXME: where I think the code is just plain wrong - > - such as putting a physical address through a macro which converts > virtual to physical addresses (1510 and 1610 mcbsp). > - or passing virtual addresses to DMA functions (mcbsp). > - or passing physical addresses when what's required is a virtual address > (omap_udc). Yeah, the omap_udc one looks like the __REG() conversion patch just did the wrong thing. Fix looks trivial, and once I verify it then I'll send it through mainline. > - CHECKME: where I've changed something to make it build but I don't > know if this is right. > > - WBNI: more a preference to see something changed than a bug. > > Comments on the FIXMEs are what I'm really interested in, and preferably > having them actually fixed would be a good idea. I verified that the OMAP tree boots on my OMAP5912 OSK, at least once things like cpufreq, PM, and MTD are disabled. The MTD thing is a known/solved issue in mainline. (Block queue changes broke MTD...) The oopses in cpufreq and pm_idle are more cryptic. So I can try my patch for the omap_udc thing ... even though for OSK the mainline kernel ** DOES NOT BOOT ** and dies even before the kernel "hello, I'm RC5!" banner prints. Someone with a JTAG to throw at this might be able to fix that regression quickly. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
