lkml.org 
[lkml]   [2006]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
    On Fri, 01 Sep 2006 12:53:47 -0700
    Roland Dreier <rdreier@cisco.com> wrote:

    > Roland> My understanding is that __raw_writeq() is like writeq()
    > Roland> except not strongly ordered and without the byte-swap on
    > Roland> big-endian architectures. The __raw_writeX() variants are
    > Roland> convenient to avoid having to write inefficient code like
    > Roland> writel(swab32(foo), ...) when talking to a PCI device that
    > Roland> wants big-endian data. Without the raw variant, you end
    > Roland> up with a double swap on big-endian architectures.
    >
    > Oh, I left one other thing out: writeq() and __raw_writeq() shold be
    > atomic in the sense that no other transactions should be able to get
    > onto the IO bus in the middle -- so implementing writeq() as two
    > writel()s in a row is not allowed
    >
    > Andrew> OK. Can we please stop hacking around this in drivers and
    >
    > Andrew> a) work out what it's supposed to do
    >
    > Andrew> b) document that (Documentation/DocBook/deviceiobook.tmpl
    > Andrew> or code comment or whatever)
    >
    > Andrew> c) tell arch maintainers?
    >
    > Yes, I agree that's a good plan, especially the documentation part.
    > However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h
    > is legitimate: the driver uses __raw_writeq() when it exists and uses
    > two __raw_writel()s properly serialized with a device-specific lock to
    > get exactly the atomicity it needs on 32-bit archs.

    No, driver-specific workarounds are not legitimate, sorry.

    The driver should simply fail to compile on architectures which do not
    implement __raw_writeq().

    We can speed up the process by sending helpful emails to architecture
    maintainers, but they'll notice either way.

    Let's fix it once, and in the correct place.

    > It's an open question what drivers that don't actually need atomicity
    > but just want a convenient way to write 64 bits at time should do.

    Well yeah. We should sort out the design issues before implementing
    things ;)

    -
    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: 2006-09-01 22:13    [W:0.024 / U:90.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site