- 19 Apr, 2010 3 commits
-
-
Clemens Ladisch authored
We must compute the offset from the CSR register base with the full 48 address bits to prevent matching with addresses whose lower 32 bits happen to be equal with one of the specially handled registers. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Clemens Ladisch authored
Returning -EIO for all errors would not allow clients to determine if the resource allocation process itself failed, or if the resources are not available. (The latter information is needed by CMP to synchronize restoring of overlayed connections after a bus reset.) Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Clemens Ladisch authored
If there is a permanent error condition when communicating with the IRM, after the sixth error, the retry variable will be decremented to -1. If, in this case, the bits in channels_mask are not yet exhausted, the next channel is retried 2^32 times. To fix this, check that retry is never decremented beyond zero. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
- 15 Apr, 2010 2 commits
-
-
Stefan Richter authored
This was supposed to be generic "authors or copyright holders"; I mistakenly picked up text from a wrong file. Reported-by: Daniel K. <dk@uw.no> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
Among else, this allows projects like libdc1394 to carry copies of the ABI related header files without them or distributors having to worry about effects on the project's overall license terms. Switch to MIT license as suggested by Kristian. Also update the year in the copyright statement according to source history. Cc: Jay Fenlason <fenlason@redhat.com> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
-
- 10 Apr, 2010 5 commits
-
-
Stefan Richter authored
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Clemens Ladisch authored
Add the missing documentation for iso packets. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
A userspace client got to see uninitialized stack-allocated memory if it specified an _IOC_READ type of ioctl and an argument size larger than expected by firewire-core's ioctl handlers (but not larger than the core's union ioctl_arg). Fix this by clearing the requested buffer size to zero, but only at _IOR ioctls. This way, there is almost no runtime penalty to legitimate ioctls. The only legitimate _IOR is FW_CDEV_IOC_GET_CYCLE_TIMER with 12 or 16 bytes to memset. [Another way to fix this would be strict checking of argument size (and possibly direction) vs. command number. However, we then need a lookup table, and we need to allow for slight size deviations in case of 32bit userland on 64bit kernel.] Reported-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Clemens Ladisch authored
The definition of struct fw_cdev_iso_packet seems to imply that the header_length must be quadlet-aligned, and in fact, specifying an unaligned header has never really worked when using multiple packet structures, because the position of the next control word is computed by rounding the header_length _down_, so the last one to three bytes of the header would overlap the next control word. To avoid this problem, check that the header length is properly aligned. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Clemens Ladisch authored
In receive contexts, reject packets with header_length==0. This would be an instruction to queue zero packets which would not make sense. This prevents a division by zero in the OHCI driver. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
- 24 Mar, 2010 2 commits
-
-
Stefan Richter authored
The driver match strategy was: - Match vendor/model/specifier/version of the unit directory. - If that was a miss, match vendor from the root directory and model/specifier/version of the unit directory. This was inconsistent with how the modalias string was constructed until recently (take vendor/model from root directory and specifier/ version from unit directory). It was also inconsistent with how it is done since the parent commit: - Use vendor/model/specifier/version of the unit directory if possible, - fall back to one or more of vendor/model/specifier/version from the root directory depending on which ones are not present at the unit directory. Fix this inconsistency by sharing the ROM scanner function between modalias printer function and driver match function. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
The modalias string of devices that represent units on a FireWire node did not show Module_ID entries within unit directories. This was because firewire-core searched only the root directory of the configuration ROM for a Model_ID entry. We now search first the root directory, then the unit directory. IOW honor a unit directory's Model_ID if present, otherwise fall back to the root directory's model ID (if present). Furthermore, apply the same change to Vendor_ID. This had the same issue but it was less apparent because most devices provide Vendor_ID only in the root directory. And finally, also use this strategy for the remaining two IDs in the modalias, Specifier_ID and Version. It does not actually make sense to look for them elsewhere than in the unit directory because they are mandatory there. However, a uniform search order simplifies the implementation and has no adverse affect in practice. Side notes: - The older counterpart of this, nodemgr.c of ieee1394, looked for Vendor_ID first in the root directory, then in the unit directory, and for Model_ID only in the unit directory. - There is a single mainline driver which requires Vendor_ID and Model_ID --- the firedtv driver. This one worked because FireDTVs provide Vendor_ID in the root directory and Model_ID identically in root directory and unit directory. - Apart from firedtv, there are currently no drivers known to me (including userspace drivers) that look at the Vendor_ID or Model_ID of the modalias. Reported-by: Maciej Żenczykowski <zenczykowski@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
- 17 Mar, 2010 1 commit
-
-
Clemens Ladisch authored
Among the many entries in the TSB12LV22 errata list (TI literature number SLLS312) is the following: PCI Slave reads of the Cycle Timer register may occasionally get an incorrect value. Software may be able to validate value by reading the register multiple times rapidly and evaluating for a reasonable difference. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> (untested) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (added #define)
-
- 15 Mar, 2010 1 commit
-
-
Clemens Ladisch authored
If the bandwidth allocation fails, the error must be returned in *channel regardless of whether the channel allocation succeeded. Checking for c >= 0 is not correct if no channel allocation was requested, in which case this part of the code is reached with c == -EINVAL. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
- 24 Feb, 2010 26 commits
-
-
Stefan Richter authored
by the number of available isochronous DMA contexts and active quirks which is occasionally useful information. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
This bug was present in firewire-ohci since day one: The number of available isochronous receive DMA contexts was mixed up with that of available isochronous transmit DMA contexts. This is harmless on a few chips which offer the same number of contexts in both directions, but most chips nowadays implement only the standard minimum of 4 IR contexts, but 8 IT contexts. If a user attempted to run a lot of IR contexts at once, results with more than four were therefore unpredictable. I suppose the controller would simply refuse to start DMA of any unimplemented context. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
This way, we can advise users of precompiled kernel packages to test existing quirk fixes on chips which have not been listed yet, without them having to build a kernel from source. Note, to use this feature on a machine with more than one controller, steps like these are necessary: # lspci | grep 1394 # ls /sys/bus/pci/drivers/firewire_ohci/ # echo -n "0000:03:02.0" > /sys/bus/pci/drivers/firewire_ohci/unbind # echo 2 > /sys/module/firewire_ohci/parameters/quirks # echo -n "0000:03:02.0" > /sys/bus/pci/drivers/firewire_ohci/bind # echo 0 > /sys/module/firewire_ohci/parameters/quirks The parameter can also be used to switch off quirk flags that were hardwired into firewire-ohci's quirks table. Simply specify a non-zero quirks value but without any known flags, e.g. 0x100. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
We don't have a lot of quirks to take into account (especially since dual-buffer IR is out of the picture), but still, a table-based approach is more organized than a series of if () clauses. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
The config_rom struct members are only accessed during relatively infrequent self-ID-complete interrupts and only if the local config ROM was changed, while the ar_, at_, ir_, it_ members are used very frequently during I/O. Hence move the config_rom members further down. More importantly, make the huge self_id_buffer member the last one; this is only accessed in self-ID-complete interrupts. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
This code was no longer used since 2.6.33, "firewire: ohci: always use packet-per-buffer mode for isochronous reception" commit 090699c0. If anybody needs this code in the future for special purposes, it can be brought back in. But it must not be re-enabled by default; drivers (kernelspace or userspace drivers) should only get this mode if they explicitly request it. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
from array of char to union of structs. I already used a union to size the buffer which holds ioctl arguments; more consequent is to define it as an instance of this union in the first place. Also rename several local variables from "request" to "a"(rgument) since the term request can be mistaken to mean a transaction subaction, e.g. an instance of struct fw_request. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
so that clients can detect whether the FW_CDEV_IOC_GET_CYCLE_TIMER ioctl is reliable (on all tested controllers, especially the widely used VIA controllers, also NEC controllers, see commits b677532b and 1c1517ef). Also add a comment on the 2.6.32 iso xmit enhancement and on dual-buffer IR having been disabled in 2.6.33. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
The system time from CLOCK_REALTIME is not monotonic, hence problematic for the main user of the FW_CDEV_IOC_GET_CYCLE_TIMER ioctl. This issue exists in its successor ABI, i.e. raw1394, too. http://subversion.ffado.org/ticket/242 We now offer an alternative ioctl which lets the caller choose between CLOCK_REALTIME, CLOCK_MONOTONIC, and CLOCK_MONOTONIC_RAW as source of the local time, very similar to the clock_gettime libc function. The format of the local time return value matches that of clock_gettime (seconds and nanoseconds, instead of a single microseconds value from the existing ioctl). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
according to what it really does. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
If a device exposes a sparsely populated configuration ROM, firewire-core's sysfs interface and character device file interface showed random data in the gaps between config ROM blocks. Fix this by zero-initialization of the config ROM reader's scratch buffer. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
The stack size of 16 was artificially chosen and may be too small in extreme cases. A device won't be accessible then. Since it doesn't really matter to the slab allocator whether we ask for 1088 bytes or 2048 bytes of scratch memory, just allocate 2048 bytes for the sum of temporary config ROM image and stack, and we will never ever overflow the stack (because there simply can't be more stack items than ROM entries). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
It never happened yet, but better safe than sorry: If a device's config ROM contains a block which overlaps the boundary at 0xfffff00007ff, just ignore that one block instead of refusing to add the device representation. That way, upper layers (kernelspace or userspace drivers) might still be able to use the device to some degree. That's better than total inaccessibility of the device. Worse, the core would have logged only a generic "giving up on config rom" message which could only be debugged by feeding a firewire-ohci debug logging session through a config ROM interpreter, IOW would likely remain undiagnosed. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
The Panasonic AG-DV2500 tape deck contains an invalid entry in its configuration ROM root directory: A leaf pointer with the undefined key ID 0 and an offset that points way out of the standard config ROM area. This caused firewire-core to dismiss the device with the generic log message "giving up on config rom for node id...", after which it was of course impossible to access the tape deck with dvgrab or any other program. https://bugzilla.redhat.com/show_bug.cgi?id=449252#c29 The fix is to simply ignore this invalid ROM entry and proceed to read the valid rest of the ROM. There is a catch though: When the kernel later iterates over the ROM, it would be nasty having to check again for such too large ROM offsets. Therefore we manipulate the defective or unsupported ROM entry to become a harmless immediate entry that won't have any side effects later (an entry with the value 0x00000000). Reported-by: George Chriss Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Stefan Richter authored
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6Linus Torvalds authored
* 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6: parisc: Set PCI CLS early in boot.
-
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] Fix broken sn2 build
-
Carlos O'Donell authored
Set the PCI CLS early in the boot process to prevent device failures. In pcibios_set_master use the new pci_cache_line_size instead of a hard-coded value. Signed-off-by: Carlos O'Donell <carlos@codesourcery.com> Reviewed-by: Grant Grundler <grundler@google.com> Signed-off-by: Kyle McMartin <kyle@redhat.com>
-
git://git.monstr.eu/linux-2.6-microblazeLinus Torvalds authored
* 'for-linus' of git://git.monstr.eu/linux-2.6-microblaze: microblaze: Fix out_le32() macro microblaze: Fix cache loop function for cache range
-
git://git.kernel.dk/linux-2.6-blockLinus Torvalds authored
* 'for-linus' of git://git.kernel.dk/linux-2.6-block: Revert "block: improve queue_should_plug() by looking at IO depths"
-
Steven J. Magnani authored
Trailing semicolon causes compilation involving out_le32() to fail. Signed-off-by: Steven J. Magnani <steve@digidescorp.com> Signed-off-by: Michal Simek <monstr@monstr.eu>
-
Michal Simek authored
I create wrong asm code but none test shows that this part of code is wrong. I am not convinces that were good idea to create asm optimized macros for caches. The reason is that there is not optimization with previous code that's why make sense to add old code and do some benchmarking which functions are faster. Signed-off-by: Michal Simek <monstr@monstr.eu>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: net: bug fix for vlan + gro issue tc35815: Remove a wrong netif_wake_queue() call which triggers BUG_ON cdc_ether: new PID for Ericsson C3607w to the whitelist (resubmit) IPv6: better document max_addresses parameter MAINTAINERS: update mv643xx_eth maintenance status e1000: Fix DMA mapping error handling on RX iwlwifi: sanity check before counting number of tfds can be free iwlwifi: error checking for number of tfds in queue iwlwifi: set HT flags after channel in rxon
-
Ajit Khaparde authored
Traffic (tcp) doesnot start on a vlan interface when gro is enabled. Even the tcp handshake was not taking place. This is because, the eth_type_trans call before the netif_receive_skb in napi_gro_finish() resets the skb->dev to napi->dev from the previously set vlan netdev interface. This causes the ip_route_input to drop the incoming packet considering it as a packet coming from a martian source. I could repro this on 2.6.32.7 (stable) and 2.6.33-rc7. With this fix, the traffic starts and the test runs fine on both vlan and non-vlan interfaces. CC: Herbert Xu <herbert@gondor.apana.org.au> CC: Patrick McHardy <kaber@trash.net> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-