linux-kernel - Re: [RFC V1 5/8] smi2021: Add smi2021

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Mar 2013 11:09:27 +0100
From:	Hans Verkuil <hverkuil@...all.nl>
To:	Jon Arne Jørgensen <jonarne@...arne.no>
Cc:	Bjørn Mork <bjorn@...k.no>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	elezegarcia@...il.com
Subject: Re: [RFC V1 5/8] smi2021: Add smi2021_video.c

On Wed 20 March 2013 11:06:36 Jon Arne Jørgensen wrote:
> On Mon, Mar 18, 2013 at 09:58:32AM +0100, Bjørn Mork wrote:
> > Hans Verkuil <hverkuil@...all.nl> writes:
> > 
> > >> +/*
> > >> + *
> > >> + * The device delivers data in chunks of 0x400 bytes.
> > >> + * The four first bytes is a magic header to identify the chunks.
> > >> + *	0xaa 0xaa 0x00 0x00 = saa7113 Active Video Data
> > >> + *	0xaa 0xaa 0x00 0x01 = PCM - 24Bit 2 Channel audio data
> > >> + */
> > >> +static void process_packet(struct smi2021_dev *dev, u8 *p, int len)
> > >> +{
> > >> +	int i;
> > >> +	u32 *header;
> > >> +
> > >> +	if (len % 0x400 != 0) {
> > >> +		printk_ratelimited(KERN_INFO "smi2021::%s: len: %d\n",
> > >> +				__func__, len);
> > >> +		return;
> > >> +	}
> > >> +
> > >> +	for (i = 0; i < len; i += 0x400) {
> > >> +		header = (u32 *)(p + i);
> > >> +		switch (__cpu_to_be32(*header)) {
> > >
> > > That's not right. You probably mean __be32_to_cpu, that makes more sense.
> > >
> > >> +		case 0xaaaa0000: {
> > >> +			parse_video(dev, p+i+4, 0x400-4);
> > >> +			break;
> > >> +		}
> > >> +		case 0xaaaa0001: {
> > >> +			smi2021_audio(dev, p+i+4, 0x400-4);
> > >> +			break;
> > >> +		}
> > 
> > This could be just me, but I would have done it like this to take
> > advantage of compile time constant conversions (and also dropping the
> > noisy extra {}s):
> > 
> > 		switch (*header) {
> > 		case cpu_to_be32(0xaaaa0000):
> > 			parse_video(dev, p+i+4, 0x400-4);
> > 			break;
> > 		case cpu_to_be32(0xaaaa0001):
> > 			smi2021_audio(dev, p+i+4, 0x400-4);
> > 			break;
> >                 ..
> > 
> > 
> > >From the name of the function I assume the difference may actually be
> > measurable here if this runs for every processed packet.
> > 
> > 
> 
> You are both right, I will have a second look at this code.
> I guess I'll try to implement Bjørns suggestion.
> 
> As I'm working with a byte-array, I could probably change this code to:
> 
> 		if (header[0] == 0xaa && header[1] == 0xaa
> 			&& header[2] == 0x00 && header[3] == 0x00) {
> 
> 			{...}
> 
> 		} else if (header[0] == 0xaa && header[1] == 0xaa
> 			&& header[2] == 0x00 && header[3] == 0x01) {
> 		
> 			{...}
> 		}
> 
> But I hope you agree that the switch statement is cleaner?
> 
> (I just find it hard to wrap my head around the big vs. little endian
> differences when dealing with hexadecimal integer notation :) )

Bjørn's solution is best in this case.

Regards,

	Hans

> 
> > Bjørn
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/