Re: [PATCH] mtd: fix mtd_blkdevs problem with caches on somearchitectures (2.6.31)

[Ilya Loginov]

On Sun, 22 Nov 2009 09:53:50 +0000
David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:

> The thing is, having a function called flush_dcache_page() which doesn't
> actually flush a page of the dcache is just blatantly stupid.

Unfortunately, it's well-established that all architectures have these 
functions. Many kernel systems, for example file systems drivers (ext2,
ext3, ntfs), use them.

In letter to Andrew Morton I wrote that among 20 architectures this call
is not empty only for 8 of them. And it is the problem.

But some architectures really need this call. And kernel has to work
reasonably with them too. Therefore it is required often to call for
empty functions.
 
> It's misnamed -- it should probably be called something like
> 'flush_valiased_dcache_page()' or 'unalias_dcache_page()' instead, since
> I believe it's only supposed to cope with aliasing issues with virtually
> indexed caches.

I don't think so. For example I had this bug on the processor, which 
icache don't finds for data in dcache. There was no dcache aliases.
 
> If you're talking about _extending_ the existing silly name to a new
> ARCH_IMPLEMENTS_FOO macro or Kconfig option, perhaps this would be a
> good time to fix the nomenclature, rather than propagating the error?

Andrew has showed me in his first letter another topic in this mailing.
It is said there that there is no reasonable infrastructure in kernel to
correct such things. The first patch can fix bug in the mtd but the 
problem of useless cycle on many architectures is arising. 

It is because there is nothing associated with the flush_dcache_page()
function. 

This way enable us to solve and this problem too. But I agree that it
is not elegant. Have you any idea how to make it better?

Thanks!

-- 
Ilya Loginov <isloginov@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/