All of 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 v2] MIDI driver for Behringer BCD2000 USB device
Date: Thu, 06 Feb 2014 17:16:41 +0100	[thread overview]
Message-ID: <52F3B569.3070406@zonque.org> (raw)
In-Reply-To: <52F3B348.5060907@kicherer.org>

On 02/06/2014 05:07 PM, Mario Kicherer wrote:
> On 05.02.2014 23:32, Daniel Mack wrote:

>> ERROR: DOS line endings
>>
>> Did you send the patch using git send-email?
> 
> Yes, I only get the two warnings as Takashi. I also moved the
> strings in one line as he suggested.

As Takashi pointed out, that might be my bad. I'm puzzled though, as I
didn't change my procedure.

>> You could add something like this:
>>
>> #ifdef CONFIG_SND_DEBUG
>> static void bcd2000_midi_hex_dump(const char *prefix,
>> 				  const unsigned char *buf, int len)
>> {
>> 	print_hex_dump(KERN_DEBUG, prefix,
>> 		       DUMP_PREFIX_NONE, 16, 1, buf, len, false);
>> }
>> #else
>> static inline void bcd2000_midi_hex_dump(const char *prefix,
>> 				  const unsigned char *buf, int len) {}
>> #endif
>>
>> And then just call the function from various places. That would safe you
>> the module parameter, the condition check, and an indentation level.
> 
> Hm, I removed the CONFIG_ part as the module parameter would allow
> me and possible users to debug things spontaneously. But I can use our
> approach if you think it would be better nonetheless?

I think so. Less debug conditionals in the code usually result in better
readability. But it's a nit really.

>>> +		/* safety check */
>>> +		if (bcd2k->midi_cmd_offset + tocopy < BUFSIZE &&
>>> +				buf_offset + tocopy < len) {
>>> +			memcpy(&bcd2k->midi_cmd_buf[bcd2k->midi_cmd_offset],
>>> +				&buf[buf_offset], tocopy);
>>> +		} else {
>>> +			snd_printk(KERN_ERR PREFIX "access violation in %s\n",
>>> +					__func__);
>>
>> You want to drop the entire packet here, right?
> 
> Hm, I'm not sure. A "return" after the snd_printk would do, right?

Yes, that should do.


Daniel

  reply	other threads:[~2014-02-06 16:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-05 20:10 [PATCH v2] MIDI driver for Behringer BCD2000 USB device Mario Kicherer
2014-02-05 22:32 ` Daniel Mack
2014-02-06  8:41   ` Takashi Iwai
2014-02-06 16:07   ` Mario Kicherer
2014-02-06 16:16     ` Daniel Mack [this message]
2014-02-06  9:21 ` Clemens Ladisch
2014-02-06 16:07   ` Mario Kicherer
2014-02-06 20:51     ` Clemens Ladisch

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=52F3B569.3070406@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.