lkml.org 
[lkml]   [2012]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] NVMe: Fix compilation on architecturs without readq/writeq
    From
    On Thu, Feb 2, 2012 at 10:05, James Bottomley <jbottomley@parallels.com> wrote:
    > On Wed, 2012-02-01 at 15:35 -0800, Linus Torvalds wrote:
    >> On Tue, Jan 31, 2012 at 4:23 AM, Ingo Molnar <mingo@elte.hu> wrote:
    >> >
    >> > non-atomic sounds good to me too.
    >>
    >> You both apparently missed the related discussion that some devices
    >> really do care about order, even if they don't care about atomicity.
    >>
    >> So we'd actually have two versions of the header file, one
    >> little-endian, and one big-endian. Then the driver that knows it
    >> doesn't need the atomic 'readq()' that is always defined, but wants a
    >> low-bytes-first version would just do
    >>
    >>    #include <linux/io64-little-endian.h>
    >>
    >> (or "big-endian" if it wants to read/write high bits first). Most
    >> drivers probably don't care, but apparently NVMe does.
    >
    > And this was about the point I concluded last time that it simply wasn't
    > worth it with the number of different possibilities for the primitives
    > and trying to come up with a sensible naming scheme ... it's just easier
    > to open code because then you get exactly what you meant.
    >
    > Incidentally, the last time this came up was with mpt fusion: for a
    > write to a 64 bit register, it didn't care about order, but it did care
    > about interleaving as in if you write one half of a 64 bit register and
    > then write to another register, the 64 bit register effectively gets
    > written with zeros in the part you didn't write to, so we had to put a
    > spin lock in the open coded writeb/w/l/q() to make sure the card didn't
    > get interleaved writes.
    >
    > James
    >

    As you say, readq/writeq without any description about the semantics
    of atomicity will cause confusion in such a case.

    But new plan for non-atomic readq/writeq is defining non-atomic readq/writeq
    in the header file like asm-generic/io-nonatomic-hi-lo.h, and the file name
    is a good documentation for the description.

    The drivers which use readq/writeq without the line like
    #include <asm-generic/io-nonatomic-hi-lo.h>
    will cause compile error in the 32-bit environment.

    --
    Hitoshi Mitake
    h.mitake@gmail.com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-02-04 16:37    [W:0.026 / U:92.068 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site