Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Mack <daniel@zonque.org>
To: Mario Kicherer <dev@kicherer.org>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] MIDI driver for Behringer BCD2000 USB device
Date: Wed, 05 Feb 2014 16:49:20 +0100	[thread overview]
Message-ID: <52F25D80.4060904@zonque.org> (raw)
In-Reply-To: <52F259D0.9070705@kicherer.org>

On 02/05/2014 04:33 PM, Mario Kicherer wrote:
> 
> Hi Daniel,
> 
> thank you very much for your comments! I hope I fixed most of the
> points but I also have a few questions/comments:
> 
> On 05.02.2014 11:54, Daniel Mack wrote:
>>> +#ifdef CONFIG_USB_DEBUG
>>> +#define DEBUG	1
>>> +#else
>>> +#define DEBUG	0
>>> +#endif
>>
>> Please use the define directly instead of introducing a new one.
> 
> I replaced it with:
> 
> #ifndef CONFIG_USB_DEBUG
> #define CONFIG_USB_DEBUG 0
> #endif

No, don't fiddle with CONFIG_* symbols. What I mean is: use the CONFIG_
macro in your code instead if 'DEBUG'. And also, maybe use
CONFIG_SND_DEBUG instead.

> As it can be undefined. I hope that's okay.

Ah, so I'd recommend you move code that depends on this define into a
separate function, and stub it out with a no-op if it's not defined.
Something like this:

#ifdef CONFIG_SND_DEBUG
static void foo_dump()
{
	...
}
#else
static inline void foo_dump() {}
#endif

...
{
	...
	foo_dump();
	...
}

It makes to code more readable if there are less #ifdef.

>> Your patch has a huge number of style issues, which
>> scripts/checkpatch.pl will point you to. I got:
> 
> Interesting, I copied many issues from other modules. :)

You're welcome to send patches to fix them :)
A general rule is: "Do as we say, not as we do".

> If fixed most of them except these:
> 
> WARNING: quoted string split across lines
> #310: FILE: sound/usb/bcd2000/bcd2000.c:254:
> +                       "bcd2000_midi_send(%p): usb_submit_urb() failed"
> +                       "ret=%d, len=%d\n", substream, ret, len);
> 
> WARNING: quoted string split across lines
> #392: FILE: sound/usb/bcd2000/bcd2000.c:336:
> +                               "bcd2000_init_device: usb_submit_urb() 
> failed,"
> +                               "ret=%d: ", ret);
> 
> I don't know how to avoid them, as all strings in one line would be
> longer than 80 characters.

Yep, I'd say that's okay. I'd prefer non-split string over the 80-char
rule. However, consider using __func__ rather than the manual function
name copy; that might solve your problem as well.

>>> +		/* determine the number of bytes we want to copy this time */
>>> +		tocopy = min( 3 - bcd2k->midi_cmd_offset, length - (buf_offset - 1));
>>> +		
>>> +		if (tocopy > 0) {
>>
>> tocopy is unsigned char, so this check is always true, and the copy
>> routine can overflow in case bcd2k->midi_cmd_offset < 3.
> 
> I don't understand your point here. It could be zero.

Yes, I'm sorry. I was looking at the '< 0' condition that can occur if
'bcd2k->midi_cmd_offset < 3'.

> But I changed it
> to a condition that checks if both offsets are within the length of the
> two involved buffers.

Great. Please also double-check whether a maliciously behaving device
could cause any harm to your buffer logic. It's easy to hack a simple
microcontroller to match the driver and then through random stuff at
your routines. Your code must be able to cope with everything it is fed to.

>> Please, no dead code. Remove those lines entirely if you don't need them.
> 
> Ah okay, I planned to reactive them with the audio part. But I removed
> them for now.
> 
> As far as I understood, I should repost the new patch as [PATCH v2].

Correct.

> I
> will check this evening if the device still works and send it to the
> list afterwards.


Thanks,
Daniel

  reply	other threads:[~2014-02-05 15:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-01 19:54 [PATCH] MIDI driver for Behringer BCD2000 USB device Mario Kicherer
2014-02-05 10:54 ` Daniel Mack
2014-02-05 15:33   ` Mario Kicherer
2014-02-05 15:49     ` Daniel Mack [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-02-20 12:31 Mario Kicherer
2014-02-20 12:44 ` Daniel Mack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52F25D80.4060904@zonque.org \
    --to=daniel@zonque.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=dev@kicherer.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox