Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mario Kicherer <dev@kicherer.org>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH v2] MIDI driver for Behringer BCD2000 USB device
Date: Thu, 06 Feb 2014 17:07:38 +0100	[thread overview]
Message-ID: <52F3B34A.3090209@kicherer.org> (raw)
In-Reply-To: <52F35430.8040502@ladisch.de>

On 06.02.2014 10:21, Clemens Ladisch wrote:
>> +config SND_USB_BCD2000
>> +	tristate "Behringer BCD2000 MIDI driver"
>> +	select SND_HWDEP
>
> Why HWDEP?

I admit, I copied this from the other modules (caiaq I believe). After
grepping the documentation, I'm not sure if I need this. Should I remove
it?

> There is no need to have "usb" in the module name if that is the only
> bus this device works with.

Okay, after looking at the other modules I thought that it is common to
use the "snd-usb" prefix. Should I remove it? I find it useful, e.g., to
recognize it in a "lsmod".

>> -obj-$(CONFIG_SND) += misc/ usx2y/ caiaq/ 6fire/ hiface/
>> +obj-$(CONFIG_SND) += misc/ usx2y/ caiaq/ 6fire/ hiface/ bcd2000/
>
> If there is only a single source file, just put it into misc/.
> If you plan to have multiple source files, then this file should have
> "_midi" in its name.

Okay, I thought that the code is short enough to put everything in one
file but I think with the audio part it would be best to split the file.
I can move it to misc/ or do you think an own subdirectory is okay to
avoid moving it in later versions?

>> +#include "../usbaudio.h"
>> +#include "../midi.h"
>
> Are these headers needed?

After cleaning up the code with Daniel, no, it's not needed anymore. 
Removed.


>> +static void bcd2000_midi_handle_input(struct bcd2000 *bcd2k,
>> +					const unsigned char *buf, int len)
>> +	/*
>> +	 * The MIDI packets the BCD2000 sends can be arbitrarily truncated or
>> +	 * concatenated. Therefore, this loop accumulates the bytes from the
>> +	 * input buffer until a full valid MIDI packet is in the MIDI command
>> +	 * buffer "midi_cmd_buf".
>> +	 */
>
> ALSA does not require full MIDI commands, and handles running status.

Oh, okay. So, should I just pass everything through to
snd_rawmidi_receive() ?

>> +static int bcd2000_midi_output_close(struct snd_rawmidi_substream *substream)
>> +{
>> +	struct bcd2000 *bcd2k = substream->rmidi->private_data;
>> +	if (bcd2k->midi_out_active) {
>> +		usb_free_urb(bcd2k->midi_out_urb);
>
> Why is this the right place to free the URB?

Good point, doesn't really make sense as it only allocated once. I'll
remove it.

>> +static void bcd2000_midi_output_done(struct urb *urb)
>> +{
>> ...
>> +	if (!bcd2k->midi_out_substream)
>> +		return;
>> +
>> +	bcd2000_midi_send(bcd2k, bcd2k->midi_out_substream);
>
> The midi_out_substream field gets modified asynchronously by the trigger
> callback; this might happen between these two statements.
>
> Assuming that setting a pointer is atomic, use ACCESS_ONCE.

You mean like this:

struct snd_rawmidi_substream * midi_out_substream;
midi_out_substream = ACCESS_ONCE(bcd2k->midi_out_substream);
if (!midi_out_substream)
	return;
bcd2000_midi_send(bcd2k, midi_out_substream);


>> +static void bcd2000_init_midi(struct bcd2000 *bcd2k)
>> +{
>> +	bcd2k->midi_in_urb = usb_alloc_urb(0, GFP_KERNEL);
>> +	bcd2k->midi_out_urb = usb_alloc_urb(0, GFP_KERNEL);
>
> Error checking.

Okay, I guess I should close everything I opened in this module before
or would a "return" suffice?

Thank you for your comments!
Mario

  reply	other threads:[~2014-02-06 16:07 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
2014-02-06  9:21 ` Clemens Ladisch
2014-02-06 16:07   ` Mario Kicherer [this message]
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=52F3B34A.3090209@kicherer.org \
    --to=dev@kicherer.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    /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