> > +#ifdef IPATH_COSIM > > +extern __u32 sim_readl(const volatile void __iomem * addr); > > +extern __u64 sim_readq(const volatile void __iomem * addr); > > The driver has a strange mixture of int32_t, s32 and __s32. s32 is > preferred. The cosim stuff has been nuked, as it was old code anyway. With those functions gone, we now use int32_t (and related 8-, 16-, 32- and 64-bit signed and unsigned versions) consistently throughout the code. We'd prefer to keep it that way, instead of changing over to s32 and friends, as some of our header files are used by userland programs. Unless we put in magic typedef for s32 and friends in userland, that won't work, hence we use the C standard typedefs. Is this a problem? Regards, Robert. -- Robert Walsh Email: [email protected] PathScale, Inc. Phone: +1 650 934 8117 2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969 Mountain View, CA 94043
Attachment:
signature.asc
Description: This is a digitally signed message part
- References:
- [PATCH 00/13] [RFC] IB: PathScale InfiniPath driver
- From: Roland Dreier <[email protected]>
- [PATCH 01/13] [RFC] ipath basic headers
- From: Roland Dreier <[email protected]>
- Re: [PATCH 01/13] [RFC] ipath basic headers
- From: Andrew Morton <[email protected]>
- [PATCH 00/13] [RFC] IB: PathScale InfiniPath driver
- Prev by Date: Re: [2.6 patch] i386: always use 4k stacks
- Next by Date: Re: Makefile targets: tar & rpm pkgs, while using O=<dir> as non-root
- Previous by thread: Re: [PATCH 01/13] [RFC] ipath basic headers
- Next by thread: Re: [PATCH 00/13] [RFC] IB: PathScale InfiniPath driver
- Index(es):