Re: [PATCH 7/8] IR: extend ir_raw_event and do refactoring

[Andy Walls <awalls@md.metrocast.net>]

On Wed, 2010-09-08 at 13:27 -0400, Jarod Wilson wrote:
> On Wed, Sep 08, 2010 at 12:50:46PM -0400, Andy Walls wrote:
> > On Wed, 2010-09-08 at 11:26 -0400, Jarod Wilson wrote:
> > > On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:

> > > 
> > > I'm generally good with this entire patch, but the union usage looks a
> > > bit odd, as the members aren't of the same size, which is generally
> > > what I've come to expect looking at other code.
> > 
> > Having a union with different sized members is perfectly valid C code. 
> > 

> Yeah, no, I know that it'll work, just that most of the unions I've
> actually paid any attention to had members all of the same size. Seemed
> like sort of an unwritten rule for in-kernel use. But its probably just
> fine.

Well if it's an unwritten rule, not everyone is following it. :)
There are numerous counter-examples in include/linux/*.h .  Here are a
few easy to see ones:

include/linux/input.h:
	union in struct ff_effect: ff_rumble vs. ff_periodic   

include/linux/i2c.h
	union i2c_smbus_data: byte vs. word vs. block[]

include/linux/kfifo.h
	DECLARE_KFIFO



> > >  I'd be inclined to
> > > simply move duty_cycle out of the union and leave just duration and
> > > carrier in it.
> > 
> > That's not necessary and it could be confusing depending on where you
> > put duty_cycle.
> 
> There's that. But without having code that actually uses duty_cycle in a
> meaningful way yet, its hard to say for sure. If carrier and duty_cycle
> were only being sent out in their own events, you might actually want a
> union of duration, carrier and duty_cycle. Though I suspect we'll probably
> want to pass along carrier and duty_cycle at the same time.

I suspect you're right on that.  I don't have any experience with
hardware that can actually estimate carrier freq or duty cycle.  I
suspect they can be measured together using edge detection on both
rising and falling edges.

Regards,
Andy