Re: FOR COMMENT: void __iomem * and similar casts are Bad News

[David Brownell <david-b@pacbell.net>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html