On Thu, Oct 14, 2010 at 8:18 PM, Catalin Marinas<catalin.marinas@arm.com> wrote:> On Thu, 2010-10-14 at 16:02 +0100, Felipe Contreras wrote:>> On Mon, Oct 11, 2010 at 3:30 PM, Catalin Marinas>> <catalin.marinas@arm.com> wrote:>> > Well, even if you allow Device memory via ioremap in Linux and the>> > hardware behaviour is not "unpredictable", it is not guaranteed to act>> > as a Device memory. You get speculative accesses via the Normal alias>> > and you may also get dirty cache lines evicted at random from the Normal>> > mapping (unless you invalidated the cache before). The dirty eviction is>> > valid even for pre-ARMv6 processors.>>>> I'm not familiar with device memory, but anyway, IIUC you are saying>> the normal mapping (original) might not work as expected... That's ok,>> because the only alias that uses after the ioremap() is the second>> one.>> No, I say that the Device memory that you are using may not work as> expected (i.e. Device memory). The other Normal mapping may be fine but> you don't care about it anyway.

Yes, the device memory mapping might not work as expected, it mightwork as normal memory, by _may_ you are also implying it might work asdevice memory on some cases. A driver might need only that, and yourchange would make it _never_ work as device memory. That might ormight not be desirable, but it's a _change_, which was my point.

>> > It may be just theoretical but architecture licensees implement the>> > hardware according to the ARM ARM. If it says "unpredictable", they>> > don't need to care much about this scenario as it is not allowed in>> > software and the hardware can be further optimised (well, I think>> > "unpredictable" doesn't allow hardware deadlocking or security>> > implications, so the memory corruption cannot be that random, possibly>> > just restricted to that memory range). It is probably ok on current>> > hardware but I cannot guarantee, you would have to check on a>> > case-by-case basis (CPU implementation).>>>> Exactly, so it's not the end of the world if this is still allowed one>> more release.>> Would there be any incentive for driver maintainers to fix the drivers> after one more release? AFAICT, this is a violation of the ioremap API> already.

I explained this already:

I think everyone agrees that the amount of people that try finalreleases is way bigger than the ones that try release candidates, andthat's the intention. And driver maintainers (if they have actuallyseen the warning) are not the only ones that can fix issues. So themore exposure the warning has, the more chances of some contributorfixing it.

I am not a driver maintainer, yet, for some strange reason I decidedto try 2.6.36-rc6 where I saw the warning for the first time, and Ifelt compelled to fix it, and I did, thanks to Russell, but it's tolate for .36 to get this driver fixed. Who says there aren't otherpeople like that out there? Well, you would never know if you don'tput the warning there in the first place.