> > +struct descriptor {
> > + u32 req_count:16;
> > +
> > + u32 wait:2;
> > + u32 branch:2;
> > + u32 irq:2;
> > + u32 yy:1;
> > + u32 ping:1;
> > +
> > + u32 key:3;
> > + u32 status:1;
> > + u32 command:4;
> > +
> > + u32 data_address;
> > + u32 branch_address;
> > +
> > + u32 res_count:16;
> > + u32 transfer_status:16;
> > +} __attribute__ ((aligned(16)));
>
> you probably want __le32 annotations for sparse, right?
More than that... he wants no bitfields ! Right now, this code is broken
on some endians (I suspect big, dunno on what Kristian tested).
>
> And for the last two fields, I bet that using the normal 'u16' type
> (__le16?) would generate much better code than a bitfield:16 ever would.
Bah, it's endian broken anyway due to bitfield (ab)use.
> enum {
> constant1 = 1234,
> constant2 = 5678,
> };
>
> for constants. These actually have some type information attached by
> the compiler, and they show up as symbols in the debugger since they are
> not stripped out by the C pre-processor.
Note that while this is true for small constants, beware of the fact
that this is highly unrecommended for anything that doesn't fit in a
signed int. gcc has some dodgy extensions allowing non-int enums but you
don't want to go near them. Read a recent discussion with Linus & Viro
(a few days ago iirc) on lkml about it.
Since some of his constants have values up to 0x80000000, I'm not 100%
confident enum is the way to go, but if you are careful with sign, it
could still be.
> > +static void ar_context_run(struct ar_context *ctx)
> > +{
> > + reg_write(ctx->ohci, ctx->command_ptr, ctx->descriptor_bus | 1);
> > + reg_write(ctx->ohci, ctx->control_set, CONTEXT_RUN);
>
> PCI posting?
In that specific case (kicking the context), it doesn't matter much.
It's not a bug per-se not to do it, though you might get better
performances by making sure it's kicked right away.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
