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
next prev parent 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 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.