[openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Andrew Morton]

On Fri, 1 Sep 2006 21:43:43 +0100
Russell King <rmk+lkml at arm.linux.org.uk> wrote:

> On Fri, Sep 01, 2006 at 01:04:44PM -0700, Andrew Morton wrote:
> > On Fri, 01 Sep 2006 12:53:47 -0700
> > Roland Dreier <rdreier at cisco.com> wrote:
> > > 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().
> 
> So, what you're basically saying is that on architectures which can _NOT_
> implement an atomic __raw_writeq(), certain drivers simply will not be
> available?

If the driver *requires* an atomic __raw_writeq(), then yes.  The driver
cannot work correctly on that machine.

If, however, there is some way in which we can make the hardware work on
that machine (say, with other locking) then we got the __raw_writeq()
interface design (whatever that is) wrong.

IOW, the best way of tackling this is to work out what we're trying to do,
design an interface, then implement it.

Doing funny workarounds within individual drivers isn't the way to address
this.  In fact it's an indication that something is wrong.

> > We can speed up the process by sending helpful emails to architecture
> > maintainers, but they'll notice either way.
> 
> I think you're completely wrong in the context of the message you're
> replying to - it's talking about an _atomic_ 64-bit write.
> 
> Sure, if you want a _non-atomic_ 64-bit write then that's possible,
> but many 32-bit architectures can't do a 64-bit atomic IO write and
> that isn't something they can "fix".

If the hardware/driver absolutely requires that the 64-bit write be atomic
on-the-bus then sure, the fix is to disable that driver on that
architecture in Kconfig.

If, however, the atomicity requirement is a software thing (we need to be
atomic against other CPU reads and writes) then that can be solved with
locking, and we can design APIs for this which can be implemented
efficiently on all architectures.