lkml.org 
[lkml]   [2010]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: USB mass storage and ARM cache coherency
    From
    Date
    On Tue, 2010-02-02 at 17:11 +0000, Alan Stern wrote:
    > On Tue, 2 Feb 2010, Oliver Neukum wrote:
    >
    > > Am Dienstag, 2. Februar 2010 13:39:35 schrieb Catalin Marinas:
    > > > > For storage that is correct. But what about other sources of pages,
    > > > > for example iSCSI?
    > > >
    > > > In the iSCSI case, does the HCD driver write directly to a page cache
    > > > page? Or it just fills in network packets that are copied to page cache
    > > > pages by the iSCSI code (sorry, I'm not familiar with this part of the
    > > > kernel). If the latter, the cache flushing in the HCD driver would not
    > > > help and it needs to be done in the iSCSI code.
    > >
    > > As far as I can tell iSCSI does a private copy. But I don't know how
    > > many methods to transfer code pages over USB exist. I'd say the
    > > conservative solution is to flush for everything but control transfers.
    >
    > This doesn't make any sense. Nobody would ever use isochronous
    > transfers to store data into a code page because isochronous is
    > unreliable. (Audio isn't a counterexample -- audio data may be mapped
    > to userspace, but only to data pages, not code pages. And the problem
    > here is to maintain consistency between the D and I caches.)

    My issues is with both I-D coherency and D-cache aliasing caused by
    pages mapped in both user and kernel space (with different colours). The
    flush_dcache_page() call should target both cases.

    --
    Catalin



    \
     
     \ /
      Last update: 2010-02-02 18:23    [W:2.099 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site