- 15 Oct, 2015 1 commit
-
-
Dan Carpenter authored
We cap the upper bound of "idx" but not the negative side. Let's make it unsigned to fix this. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 13 Oct, 2015 4 commits
-
-
Ricard Wanderlof authored
Rounding must take place before multiplication with the frame size, since each packet contains a whole number of frames. We must also properly consider the data interval, as a larger data interval will result in larger packets, which, depending on the sampling frequency, can result in packet sizes that are less than integral multiples of the packet size for a lower data interval. Detailed explanation and rationale: The code before this commit had the following expression on line 613 to calculate the maximum isochronous packet size: maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3)) >> (16 - ep->datainterval); Here, ep->freqmax is the maximum assumed sample frequency, calculated from the nominal sample frequency plus 25%. It is ultimately derived from ep->freqn, which is in the units of frames per packet, from get_usb_full_speed_rate() or usb_high_speed_rate(), as applicable, in Q16.16 format. The expression essentially adds the Q16.16 equivalent of 0.999... (i.e. the largest number less than one) to the sample rate, in order to get a rate whose integer part is rounded up from the fractional value. The multiplication with (frame_bits >> 3) yields the number of bytes in a packet, and the (16 >> ep->datainterval) then converts it from Q16.16 back to an integer, taking into consideration the bDataInterval field of the endpoint descriptor (which describes how often isochronous packets are transmitted relative to the (micro)frame rate (125us or 1ms, for USB high speed and full speed, respectively)). For this discussion we will initially assume a bDataInterval of 0, so the second line of the expression just converts the Q16.16 value to an integer. In order to illustrate the problem, we will set frame_bits 64, which corresponds to a frame size of 8 bytes. The problem here is twofold. First, the rounding operation consists of the addition of 0x0.ffff and subsequent conversion to integer, but as the expression stands, the conversion to integer is done after multiplication with the frame size, rather than before. This results in the resulting maxsize becoming too large. Let's take an example. We have a sample rate of 96 kHz, so our ep->freqn is 0xc0000 (see usb_high_speed_rate()). Add 25% (line 612) and we get 0xf0000. The calculated maxsize is then ((0xf0000 + 0x0ffff) * 8) >> 16 = 127 . However, if we do the number of bytes calculation in a less obscure way it's more apparent what the true corresponding packet size is: we get ceil(96000 * 1.25 / 8000) * 8 = 120, where 1.25 is the 25% from line 612, and the 8000 is the number of isochronous packets per second on a high speed USB connection (125 us microframe interval). This is fixed by performing the complete rounding operation prior to multiplication with the frame rate. The second problem is that when considering the ep->datainterval, this must be done before rounding, in order to take the advantage of the fact that if the number of bytes per packet is not an integer, the resulting rounded-up integer is not necessarily a factor of two when the data interval is increased by the same factor. For instance, assuming a freqency of 41 kHz, the resulting bytes-per-packet value for USB high speed is 41 kHz / 8000 = 5.125, or 0x52000 in Q16.16 format. With a data interval of 1 (ep->datainterval = 0), this means that 6 frames per packet are needed, whereas with a data interval of 2 we need 10.25, i.e. 11 frames needed. Rephrasing the maxsize expression to: maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) * (frame_bits >> 3); for the above 96 kHz example we instead get ((0xf0000 + 0xffff) >> 16) * 8 = 120 which is the correct value. We can also do the calculation with a non-integer sample rate which is when rounding comes into effect: say we have 44.1 kHz (resulting ep->freqn = 0x58333, and resulting ep->freqmax 0x58333 * 1.25 = 0x6e3ff (rounded down)): Original maxsize = ((0x6e3ff + 0xffff) * 8) << 16 = 63 (63.124.. rounded down) True maxsize = ceil(44100 * 1.25 / 8000) * 8 = 7 * 8 = 56 New maxsize = ((0x6e3ff + 0xffff) >> 16) * 8 = 7 * 8 = 56 This is also corroborated by the wMaxPacketSize check on line 616. Assume that wMaxPacketSize = 104, with ep->maxpacksize then having the same value. As 104 < 127, we get maxsize = 104. ep->freqmax is then recalculated to (104 / 8) << 16 = 0xd0000 . Putting that rate into the original maxsize calculation yields a maxsize of ((0xd0000 + 0xffff) * 8) >> 16 = 111 (with decimals 111.99988). Clearly, we should get back the 104 here, which we would with the new expression: ((0xd0000 + 0xffff) >> 16) * 8 = 104 . (The error has not been a problem because it only results in maxsize being a bit too big which just wastes a couple of bytes, either as a result of the first maxsize calculation, or because the resulting calculation will hit the wMaxPacketSize value before the packet is too big, resulting in fixing the size to wMaxPacketSize even though the packet is actually not too long.) Tested with an Edirol UA-5 both at 44.1 kHz and 96 kHz. Signed-off-by:
Ricard Wanderlof <ricardw@axis.com> Signed-off-by:
-
Takashi Iwai authored
-
David Henningsson authored
Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo mic input where one channel has reverse polarity. Alsa-info available at: https://launchpadlibrarian.net/220846272/AlsaInfo.txt Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1504778Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Vinod Koul authored
Compiling the hdac extended core on arm fails with below error: sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_writel': >> sound/hda/ext/hdac_ext_bus.c:29:2: error: implicit declaration of >> function +'writel' [-Werror=implicit-function-declaration] writel(value, addr); ^ sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_readl': >> sound/hda/ext/hdac_ext_bus.c:34:2: error: implicit declaration of >> function +'readl' [-Werror=implicit-function-declaration] return readl(addr); This is fixed by explicitly including io.h Fixes: 99463b3a - ('ALSA: hda: provide default bus io ops extended hdac') Reported-by:kbuild test robot <lkp@intel.com> Suggested-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
- 12 Oct, 2015 5 commits
-
-
Takashi Sakamoto authored
Currently, this driver picks up model name with be32_to_cpu() macro to align characters. This is wrong operation because the result is different depending on CPU endiannness. Additionally, vendor released several versions of firmware for this series. It's not better to assign model-dependent information to device entry according to the version field. This commit fixes these bugs. The name of model is picked up correctly and used to identify model-dependent information. Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Fixes: c0949b27 ('ALSA: firewire-tascam: add skeleton for TASCAM FireWire series') Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
Takashi Sakamoto authored
TASCAM FireWire series has some LEDs on its surface. These LEDs can be turned on/off by receiving asynchronous transactions to a certain address. One of the LEDs is labels as 'FireWire'. It's better to light it up when this driver starts to work. Besides, the LED for 'FireWire' is turned off at bus reset. This commit implements this idea. Signed-off-by:
-
Takashi Sakamoto authored
In former commits, this driver got functionalities to transfer/receive MIDI messages to/from TASCAM FireWire series. This commit adds some ALSA MIDI ports to enable userspace applications to use the functionalities. I note that this commit doesn't support virtual MIDI ports which console models support. A physical controls can be assigned to a certain MIDI ports including physical and virtual. But the way is not clear. Signed-off-by:
-
Takashi Sakamoto authored
TASCAM FireWire series use asynchronous transaction to receive MIDI messages. The transaction should be sent to a certain address. This commit supports the outgoing MIDI messages. The messages in the transaction includes some quirks: * One MIDI message is transferred in one quadlet transaction, except for system exclusives. * MIDI running status is not allowed, thus transactions always include status byte. * The basic data format is the same as transferring MIDI messages supported in previous commit. Signed-off-by:
-
Takashi Sakamoto authored
TASCAM FireWire series use asynchronous transaction to transfer MIDI messages. The transaction is sent to a registered address. This commit supports the incoming MIDI messages. The messages in the transaction include some quirks: * Two quadlets are used for one MIDI message and one timestamp. * Usually, the first byte of the first quadlet includes MIDI port and MSB 4 bit of MIDI status. For system exclusive message, the first byte includes MIDI port and 0x04, or 0x07 in the end of the message. * The rest of the first quadlet includes MIDI bytes up to 3. * Several set of MIDI messages and timestamp can be transferred in one block transaction, up to 8 sets. I note that TASCAM FireWire series ignores ID bytes of system exclusive message. When receiving system exclusive messages with ID bytes on physical MIDI bus, the series transfers the messages without ID bytes on IEEE 1394 bus, and vice versa. Signed-off-by:
-
- 11 Oct, 2015 9 commits
-
-
Takashi Sakamoto authored
In former commits, asynchronous transactions are supported for physical controls. This commit adds a pair of MIDI ports for them. This driver already adds diferrent number of ALSA MIDI ports for physical MIDI ports, and the number of in/out ports are different. As seeing as 'amidi' program in alsa-utils package, a pair of in/out MIDI ports is expected with the same name. Therefore, this commit adds a pair of new ports to the first. Signed-off-by:
-
Takashi Sakamoto authored
ALSA: firewire-digi00x: add support of asynchronous transaction for outgoing MIDI messages to physical controls In previous commit, asynchronous transaction for incoming MIDI messages from physical controls is supported. The physical controls may be controlled by receiving MIDI messages at a certain address. This commit supports asynchronous transaction for this purpose. Signed-off-by:
-
Takashi Sakamoto authored
ALSA: firewire-digi00x: add support of asynchronous transaction for incoming MIDI messages from physical controls Digi 00x series has two types of model; rack and console. The console models have physical controls. The model can transmit control messages. These control messages are transferred by asynchronous transactions to registered address. This commit supports the asynchronous transaction. Signed-off-by:
-
Takashi Sakamoto authored
This commit adds MIDI functionality to capture/playback MIDI messages from/to physical MIDI ports. These messages are transferred in isochronous packets. When no substreams request AMDTP streams to run, this driver starts the streams at current sampling rate. When other substreams start at different sampling rate, the streams are stopped temporarily, then start again at requested sampling rate. This operation can generate missing MIDI bytes, thus it's preferable to start PCM substreams at favorite sampling rate in advance. Digi 002/003 console also has a set of MIDI port for physical controls. These ports are added in later commits. Signed-off-by:
-
Takashi Sakamoto authored
In Digi 002/003 protocol, MIDI messages are transferred in the last data channel of data blocks. Although this data channel has a label of 0x80, it's not fully MIDI conformant data channel especially because the Counter field always zero independently of included MIDI bytes. The 4th byte of the data channel in LSB tells the number of included MIDI bytes. This byte also includes the number of MIDI port. Therefore, the data format in this data channel is: * 1st: 0x80 as label * 2nd: MIDI bytes * 3rd: 0 or MIDI bytes * 4th: the number of MIDI byte and the number of MIDI port This commit adds support of MIDI messages in data block processing layer. Like AM824 data format, this data channel has a capability to transfer more MIDI messages than the capability of phisical MIDI bus. Therefore, a throttle for data rate is required to prevent devices' internal buffer to overflow. Signed-off-by:
-
Takashi Sakamoto authored
Original code for 'DoubleOhThree' encoding was written with '__u8' type, while the type is usually used to export something to userspace. This commit replaces the type with 'u8'. Signed-off-by:
-
Keith A. Milner authored
This patch enables interrupt transfer mode for MIDI ports on newer Boss/Roland devices such as the GT-100/001 which support interrupt transfer on both IN and OUT MIDI endpoints. Previously this wasn't being enabled for these devices as the code was specifically looking for the scenario where the IN endpoint supported interrupt transfer and the OUT endpoint was bulk transfer. Newer devices support interrupt transfer for both endpoints. This has been tested on Boss devices GT-001, BR-80 and JS-8 and Roland VS-20. It would benefit from some regresison testing with other devices if possible. Signed-off-by:
Keith A. Milner <maillist@superlative.org> Signed-off-by:
-
Takashi Sakamoto authored
In firewire-lib, isochronous packet streaming is stopped when detecting wrong value for FMT field of CIP headers. Although this is appropriate to IEC 61883-1 and 6, some BeBoB based devices with vendors' customization use invalid value to FMT field of CIP headers in the beginning of streaming. $ journalctl snd-bebob fw1.0: Detect unexpected protocol: 01000000 8000ffff I got this log with M-Audio FireWire 1814. In this line, the value of FMT field is 0x00, while it should be 0x10 in usual AMDTP. Except for the beginning, these devices continue to transfer packets with valid value for FMT field, except for the beginning. Therefore, in this case, firewire-lib should continue to process packets. The former implementation of firewire-lib performs it. This commit loosens the handling of wrong value, to continue packet processing in the case. Fixes: 414ba022 ('ALSA: firewire-lib: add support arbitrary value for fmt/fdf fields in CIP header') Signed-off-by:
-
Julia Lawall authored
The structures of type snd_bebob_clock_spec, snd_bebob_rate_spec, snd_bebob_meter_spec, and snd_bebob_spec are never modified after they are initialized. Make them all const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Tested-by:
-
- 09 Oct, 2015 6 commits
-
-
Takashi Sakamoto authored
Currently, when asynchronous transactions finish in error state and retries, work scheduling and work running also continues. This should be canceled at fatal error because it can cause endless loop. This commit enables to cancel transferring MIDI messages when transactions encounter fatal errors. This is achieved by setting error state. Signed-off-by:
-
Takashi Sakamoto authored
Typically, the target devices have internal buffer to adjust output of received MIDI messages for MIDI serial bus, while the capacity of the buffer is limited. IEEE 1394 transactions can transfer more MIDI messages than MIDI serial bus can. This can cause buffer over flow in device side. This commit adds throttle to limit MIDI data rate by counting intervals between two MIDI messages. Usual MIDI messages consists of two or three bytes. This requires 1.302 to 1.953 mili-seconds interval between these messages. This commit uses kernel monotonic time service to calculate the time of next transaction. Signed-off-by:
-
Takashi Sakamoto authored
Currently, when two MIDI trigger callbacks can be called immediately, transactions for the second MIDI messages can be postpone till next trigger callback. This is not good for real-time message transmission. This commit schedules work again at response handling callback if the MIDI substream still includes untransferred MIDI messages. Signed-off-by:
-
Takashi Sakamoto authored
Currently, when waiting for a response, callers can start another transaction by scheduling another work. This is not good for error processing of transaction, especially the first response is too late. This commit serialize request/response transactions, by adding one boolean member to represent idling state. Signed-off-by:
-
Takashi Sakamoto authored
Some models receive MIDI messages via IEEE 1394 asynchronous transactions. In this case, MIDI messages are transferred in fixed-length payload. It's nice that firewire-lib module has common helper functions. This commit implements this idea. Each driver adds 'struct snd_fw_async_midi_port' in its instance structure. In probing, it should call snd_fw_async_midi_port_init() to initialize the structure with some parameters such as target address, the length of payload in a transaction and a pointer for callback function to fill the payload buffer. At 'struct snd_rawmidi_ops.trigger()' callback, it should call 'snd_fw_async_midi_port_run()' to start transactions. Each driver should ensure that the lifetime of MIDI substream continues till calling 'snd_fw_async_midi_port_finish()'. The helper functions support retries to transferring MIDI messages when transmission errors occur. When transactions are successful, the helper functions call 'snd_rawmidi_transmit_ack()' internally to consume MIDI bytes in the buffer. Therefore, Each driver is expected to use 'snd_rawmidi_transmit_peek()' to tell the number of bytes to transfer to return value of 'fill' callback. Signed-off-by:
-
Kosuke Tatsukawa authored
snd_seq_oss_readq_put_event() seems to be missing a memory barrier which might cause the waker to not notice the waiter and miss sending a wake_up as in the following figure. snd_seq_oss_readq_put_event snd_seq_oss_readq_wait ------------------------------------------------------------------------ /* wait_event_interruptible_timeout */ /* __wait_event_interruptible_timeout */ /* ___wait_event */ for (;;) { prepare_to_wait_event(&wq, &__wait, state); spin_lock_irqsave(&q->lock, flags); if (waitqueue_active(&q->midi_sleep)) /* The CPU might reorder the test for the waitqueue up here, before prior writes complete */ if ((q->qlen>0 || q->head==q->tail) ... __ret = schedule_timeout(__ret) if (q->qlen >= q->maxlen - 1) { memcpy(&q->q[q->tail], ev, sizeof(*ev)); q->tail = (q->tail + 1) % q->maxlen; q->qlen++; ------------------------------------------------------------------------ There are two other place in sound/core/seq/oss/ which have similar code. The attached patch removes the call to waitqueue_active() leaving just wake_up() behind. This fixes the problem because the call to spin_lock_irqsave() in wake_up() will be an ACQUIRE operation. I found this issue when I was looking through the linux source code for places calling waitqueue_active() before wake_up*(), but without preceding memory barriers, after sending a patch to fix a similar issue in drivers/tty/n_tty.c (Details about the original issue can be found here: https://lkml.org/lkml/2015/9/28/849). Signed-off-by:Kosuke Tatsukawa <tatsu@ab.jp.nec.com> Signed-off-by:
-
- 08 Oct, 2015 2 commits
-
-
Vinod Koul authored
Now that we have introduced the core fns we should make hda use these helpers Signed-off-by:
-
Subhransu S. Prusty authored
The current codec helpers are local to hda code and needs to be moved to core so that other users can use it. The helpers to read/write the codec and to check the power state of widgets is copied Signed-off-by:
Subhransu S. Prusty <subhransu.s.prusty@intel.com> Signed-off-by:
-
- 07 Oct, 2015 3 commits
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.3 Quite a few fixes here but they're all very small and driver specific, none of them really stand out if you aren't using the relevant hardware but they're all useful if you do happen to have an affected device.
-
Mark Brown authored
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/db1200', 'asoc/fix/dwc', 'asoc/fix/imx-ssi', 'asoc/fix/maintainers', 'asoc/fix/rt5645', 'asoc/fix/sgtl5000' and 'asoc/fix/tas2552' into asoc-linus
-
- 06 Oct, 2015 2 commits
-
-
Mark Brown authored
Neither myself or Liam is especially interested in this driver any more and the devices are already covered by the general ex-Wolfson entry so just remove this. Signed-off-by:
Liam Girdwood <liam.r.girdwood@linux.intel.com>
-
Andreas Dannenberg authored
The minimum volume level for the TAS2552 (control register value 0x00) is -7dB however the driver declares it as -0.07dB. Running amixer before the patch reports: dBscale-min=-0.07dB,step=1.00dB,mute=0 Running amixer with the patch applied reports: dBscale-min=-7.00dB,step=1.00dB,mute=0 Signed-off-by:
Andreas Dannenberg <dannenberg@ti.com> Signed-off-by:
-
- 05 Oct, 2015 3 commits
-
-
Jeeja KP authored
if the stream is decoupled and both link and host are used, while releasing the stream, need to check if link and host stream are not in use. This patch adds fix to check if the host/link stream is in used before coupling it back when releasing the stream. Signed-off-by:
Jeeja KP <jeeja.kp@intel.com> Signed-off-by:
-
Subhransu S. Prusty authored
Bits in LOSIDV need to be set to map the stream id for specific link. Fixing this by setting the required bits in the register. Signed-off-by:
-
Takashi Iwai authored
When OSS emulation is loaded on ISA SB AWE32 chip, we get now kernel warnings like: WARNING: CPU: 0 PID: 2791 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x51/0x80() sysfs: cannot create duplicate filename '/devices/isa/sbawe.0/sound/card0/seq-oss-0-0' It's because both emux synth and opl3 drivers try to register their OSS device object with the same static index number 0. This hasn't been a big problem until the recent rewrite of device management code (that exposes sysfs at the same time), but it's been an obvious bug. This patch works around it just by using a different index number of emux synth object. There can be a more elegant way to fix, but it's enough for now, as this code won't be touched so often, in anyway. Reported-and-tested-by:
Michael Shell <list1@michaelshell.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 04 Oct, 2015 5 commits
-
-
Takashi Iwai authored
The recent widget power saving introduced some unavoidable click noises on old IDT 92HD73xx chips while it still seems working on the compatible new chips. In the bugzilla, we tried lots of tests and workarounds, but they didn't help much. So, let's disable the feature for these specific chips as the least (but safest) fix. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104981 Cc: <stable@vger.kernel.org> # v4.1+ Signed-off-by:
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tileLinus Torvalds authored
Pull strscpy string copy function implementation from Chris Metcalf. Chris sent this during the merge window, but I waffled back and forth on the pull request, which is why it's going in only now. The new "strscpy()" function is definitely easier to use and more secure than either strncpy() or strlcpy(), both of which are horrible nasty interfaces that have serious and irredeemable problems. strncpy() has a useless return value, and doesn't NUL-terminate an overlong result. To make matters worse, it pads a short result with zeroes, which is a performance disaster if you have big buffers. strlcpy(), by contrast, is a mis-designed "fix" for strlcpy(), lacking the insane NUL padding, but having a differently broken return value which returns the original length of the source string. Which means that it will read characters past the count from the source buffer, and you have to trust the source to be properly terminated. It also makes error handling fragile, since the test for overflow is unnecessarily subtle. strscpy() avoids both these problems, guaranteeing the NUL termination (but not excessive padding) if the destination size wasn't zero, and making the overflow condition very obvious by returning -E2BIG. It also doesn't read past the size of the source, and can thus be used for untrusted source data too. So why did I waffle about this for so long? Every time we introduce a new-and-improved interface, people start doing these interminable series of trivial conversion patches. And every time that happens, somebody does some silly mistake, and the conversion patch to the improved interface actually makes things worse. Because the patch is mindnumbing and trivial, nobody has the attention span to look at it carefully, and it's usually done over large swatches of source code which means that not every conversion gets tested. So I'm pulling the strscpy() support because it *is* a better interface. But I will refuse to pull mindless conversion patches. Use this in places where it makes sense, but don't do trivial patches to fix things that aren't actually known to be broken. * 'strscpy' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: tile: use global strscpy() rather than private copy string: provide strscpy() Make asm/word-at-a-time.h available on all architectures
-
Takashi Sakamoto authored
Current ALSA BeBoB drivers has an entry for this model, while the value of vendor ID seems to be wrong according to an user's report. The vendor had released no updated firmware, thus we can judge that this model had not changed the content of its config ROM. It's reasonable to fix the ID according to the report. $ ./linux-firewire-utils/src/crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 0425720f bus_info_length 4, crc_length 37, crc 29199 404 31333934 bus_name "1394" 408 f0646122 irmc 1, cmc 1, isc 1, bmc 1, pmc 0, cyc_clk_acc 100, max_rec 6 (128), max_rom 1, gen 2, spd 2 (S400) 40c 00000ff2 company_id 00000f | 410 00004697 device_id f200004697 | EUI-64 00000ff200004697 root directory ----------------------------------------------------------------- 414 000859be directory_length 8, crc 22974 418 04000082 hardware version 41c 0c0083c0 node capabilities per IEEE 1394 420 03000ff2 vendor 424 8100000a --> descriptor leaf at 44c 428 17010065 model 42c 8100000d --> descriptor leaf at 460 430 13000910 version 434 d1000001 --> unit directory at 438 unit directory at 438 ----------------------------------------------------------------- 438 0004ccec directory_length 4, crc 52460 43c 1200a02d specifier id: 1394 TA 440 13010001 version: AV/C 444 17010065 model 448 8100000d --> descriptor leaf at 47c descriptor leaf at 44c ----------------------------------------------------------------- 44c 0004152a leaf_length 4, crc 5418 450 00000000 textual descriptor 454 00000000 minimal ASCII 458 4d61636b "Mack" 45c 69650000 "ie" descriptor leaf at 460 ----------------------------------------------------------------- 460 000612b5 leaf_length 6, crc 4789 464 00000000 textual descriptor 468 00000000 minimal ASCII 46c 4f6e7978 "Onyx" 470 20466972 " Fir" 474 65776972 "ewir" 478 65000000 "e" descriptor leaf at 47c ----------------------------------------------------------------- 47c 000612b5 leaf_length 6, crc 4789 480 00000000 textual descriptor 484 00000000 minimal ASCII 488 4f6e7978 "Onyx" 48c 20466972 " Fir" 490 65776972 "ewir" 494 65000000 "e" $ cat /proc/asound/card3/firewire/firmware Manufacturer: bridgeCo Protocol Ver: 1 Build Ver: 0 GUID: 0x00000FF200004697 Model ID: 0x82 Model Rev: 1 Firmware Date: 20040430 Firmware Time: 131527 Firmware ID: 0x10065 Firmware Ver: 2320 Base Addr: 0x20080000 Max Size: 1572864 Loader Date: 20040430 Loader Time: 112036 Reported-by:Andrzej Gansiniec <andrzej@gansiniec.pl> Signed-off-by:
-
git://neil.brown.name/mdLinus Torvalds authored
Pull md fixes from Neil Brown: "Assorted fixes for md in 4.3-rc. Two tagged for -stable, and one is really a cleanup to match and improve kmemcache interface. * tag 'md/4.3-fixes' of git://neil.brown.name/md: md/bitmap: don't pass -1 to bitmap_storage_alloc. md/raid1: Avoid raid1 resync getting stuck md: drop null test before destroy functions md: clear CHANGE_PENDING in readonly array md/raid0: apply base queue limits *before* disk_stack_limits md/raid5: don't index beyond end of array in need_this_block(). raid5: update analysis state for failed stripe md: wait for pending superblock updates before switching to read-only
-
