Re: [PATCH 2/3] Import fw-ohci driver.

[Benjamin Herrenschmidt]

> > +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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/