- 28 9月, 2009 1 次提交
-
-
由 Alexey Dobriyan 提交于
* mark struct vm_area_struct::vm_ops as const * mark vm_ops in AGP code But leave TTM code alone, something is fishy there with global vm_ops being used. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 9月, 2009 2 次提交
-
-
由 Stefan Richter 提交于
The inquiry delay is not necessary anymore in tests on a recent kernel. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Michael Buesch 提交于
Do not leak the allocated memory in case the mutex_trylock() failed to acquire the lock. Signed-off-by: NMichael Buesch <mb@bu3sch.de> This bug does not happen in practice: All raw1394 clients use libraw1394, and accesses to a libraw1394 handle need to be serialized by the client. This is documented in libraw1394's API reference. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 03 9月, 2009 1 次提交
-
-
由 Eric Dumazet 提交于
The generic packet receive code takes care of setting netdev->last_rx when necessary, for the sake of the bonding ARP monitor. Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Acked-by: NNeil Horman <nhorman@txudriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 9月, 2009 1 次提交
-
-
由 Stephen Hemminger 提交于
No need to put ethtool_ops in data, they should be const. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 01 9月, 2009 1 次提交
-
-
由 Stephen Hemminger 提交于
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 03 7月, 2009 1 次提交
-
-
由 Stefan Richter 提交于
Increase the command ORB data structure to transport up to 16 bytes long CDBs (instead of 12 bytes), and tell the SCSI mid layer about it. This is notably necessary for READ CAPACITY(16) and friends, i.e. support of large disks. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 21 6月, 2009 1 次提交
-
-
由 Stefan Richter 提交于
The new stack is now recommended over the old one if used for industrial video (IIDC/DCAM) or for storage devices (SBP-2) due to better performance, improved compatibility, added features, and security. It should also be functionally on par with and is more secure than the old ieee1394 stack in the use case of consumer video devices. IP-over-1394 support for the new stack is currently emerging, and a backend of the firedtv DVB driver to the new stack should be available soon. The one remaining area where the old stack is still required are audio devices, as the new stack is not yet able to support the FFADO FireWire audio framework. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 16 6月, 2009 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux1394-devel@lists.sourceforge.net Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Cc: Ben Collins <ben.collins@ubuntu.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 15 6月, 2009 2 次提交
-
-
由 Vegard Nossum 提交于
kmemcheck reports a use of uninitialized memory here, but it's not a real error. The structure in question has just been allocated, and the whole field is initialized, but it happens in two steps. We fix the false positive by inserting a kmemcheck annotation. Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
-
由 Vegard Nossum 提交于
Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
-
- 14 6月, 2009 1 次提交
-
-
由 Stefan Richter 提交于
The driver is now called firewire-net. It might implement the transport of other networking protocols in the future, notably IPv6 per RFC 3146. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 12 6月, 2009 1 次提交
-
-
由 Theodore Ts'o 提交于
The only user of the i_cindex element in the inode structure is used is by the firewire drivers. As part of an attempt to slim down the inode structure to save memory --- since a typical Linux system will have hundreds of thousands if not millions of inodes cached, a reduction in the size inode has high leverage. The firewire driver does not need i_cindex in any fast path, so it's simple enough to calculate when it is needed, instead of wasting space in the inode structure. Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu> Cc: krh@redhat.com Cc: stefanr@s5r6.in-berlin.de Cc: linux-fsdevel@vger.kernel.org Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 07 4月, 2009 1 次提交
-
-
由 Yang Hongyang 提交于
Replace all DMA_32BIT_MASK macro with DMA_BIT_MASK(32) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 25 3月, 2009 4 次提交
-
-
由 Stefan Richter 提交于
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
Eliminate the following warnings in raw1394_compat_write()'s error return path, seen on x86-64 with CONFIG_COMPAT=y: drivers/ieee1394/raw1394.c:381:17: warning: incorrect type in return expression (different address spaces) drivers/ieee1394/raw1394.c:381:17: expected char const [noderef] <asn:1>* drivers/ieee1394/raw1394.c:381:17: got void * drivers/ieee1394/raw1394.c:2252:14: warning: incorrect type in argument 1 (different address spaces) drivers/ieee1394/raw1394.c:2252:14: expected void const *ptr drivers/ieee1394/raw1394.c:2252:14: got char const [noderef] <asn:1>*[assigned] buffer drivers/ieee1394/raw1394.c:2253:19: warning: incorrect type in argument 1 (different address spaces) drivers/ieee1394/raw1394.c:2253:19: expected void const *ptr drivers/ieee1394/raw1394.c:2253:19: got char const [noderef] <asn:1>*[assigned] buffer Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Tobias Klauser 提交于
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 16 3月, 2009 1 次提交
-
-
由 Jonathan Corbet 提交于
Most fasync implementations do something like: return fasync_helper(...); But fasync_helper() will return a positive value at times - a feature used in at least one place. Thus, a number of other drivers do: err = fasync_helper(...); if (err < 0) return err; return 0; In the interests of consistency and more concise code, it makes sense to map positive return values onto zero where ->fasync() is called. Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: NJonathan Corbet <corbet@lwn.net>
-
- 27 2月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
It needs to happen before any firewire driver actually registers itself, and that was previously handled by having the Makefile list the core ieee1394 files before the drivers. But now there are firewire drivers in drivers/media, and the Makefile games aren't enough. So just make ieee1394_init happen earlier in the init sequence, the way all other bus layers already do. Reported-and-tested-by: NIngo Molnar <mingo@elte.hu> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Henrik Kurelid <henrik@kurelid.se> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Ben Backx <ben@bbackx.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 24 2月, 2009 5 次提交
-
-
由 Stefan Richter 提交于
hpsb_read, hpsb_write, hpsb_lock are sleeping functions which nobody is in danger to use in atomic context. Besides, in_interrupt does not cover all types of atomic context. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
While Module_Vendor_ID in the configuration ROM's root directory is mandatory, there often aren't vendor IDs in unit directories. This affects the new firedtv driver which is meant to be auto-loaded and matched only for vendor-specific devices. We now always copy ne->vendor_id into ud->vendor_id before we scan a unit directory (and fill in a possibly present vendor ID from there). This way, the root directory's vendor ID is used as fallback in the "uevent" environment for modprobe'ing per module alias when a node was plugged in, and in the driver match routine when protocol drivers are bound to unit directories. It will however not be used as sysfs attribute of a unit directory device. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
These will be used by the firedtv driver. Like hpsb_node_write() they are much better APIs for high-level drivers than hpsb_write() and its siblings --- easier to use correctly and also terser. Unlike hspb_node_write(), the two new functions will only be used by one call site. Hence make them static inline instead of exported symbols. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
A compiler barrier (explicit on the read side, implicit on the write side) is not quite enough for what has to be accomplished here. Use hardware memory barriers on systems which need them. (Of course a full fix of generation handling would require much more than this. The ieee1394 core's bus generation counter had to be tied to the controller's bus generation counter; cf. Kristian's stack. It's just that I have other current business with the code around these barrier()s, so why not do at least this small fix.) Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
Combination of the following changes: Tue, 26 Aug 2008 00:17:30 +0200 (CEST) firedtv: fix remote control input and update the scancode-to-keycode mapping to a current model. Per default, various media key keycodes are emitted which closely match what is printed on the remote. Userland can modify the mapping by means of evdev ioctls. (Not tested.) The old scancode-to-keycode mapping is left in the driver but cannot be modified by ioctls. This preserves status quo for old remotes. Tue, 26 Aug 2008 00:11:28 +0200 (CEST) firedtv: replace tasklet by workqueue job Non-atomic context is a lot nicer to work with. Sun, 24 Aug 2008 23:30:00 +0200 (CEST) firedtv: move some code back to ieee1394 core Partially reverts "ieee1394: remove unused code" of Linux 2.6.25. Sun, 24 Aug 2008 23:29:30 +0200 (CEST) firedtv: replace semaphore by mutex firesat->avc_sem and ->demux_sem have been used exactly like a mutex. The only exception is the schedule_remotecontrol tasklet which did a down_trylock in atomic context. This is not possible with mutex_trylock; however the whole remote control related code is non-functional anyway at the moment. This should be fixed eventually, probably by turning the tasklet into a worqueue job. Convert everything else from semaphore to mutex. Also rewrite a few of the affected functions to unlock the mutex at a single exit point, instead of in several branches. Sun, 24 Aug 2008 23:28:45 +0200 (CEST) firedtv: some header cleanups Unify #ifndef/#define/#endif guards against multiple inclusion. Drop extern keyword from function declarations. Remove #include's into header files where struct declarations suffice. Remove unused ohci1394 interface and related unused ieee1394 interfaces. Add a few missing #include's and remove a few apparently obsolete ones. Sort them alphabetically. Sun, 24 Aug 2008 23:27:45 +0200 (CEST) firedtv: nicer registration message and some initialization fixes Print the correct name in dvb_register_adapter(). While we are at it, replace two switch cascades by one for loop, remove a superfluous member of struct firesat and of two unused arguments of AVCIdentifySubunit(), and fix bogus kfree's in firesat_dvbdev_init(). Tue, 26 Aug 2008 14:24:17 +0200 (CEST) firesat: rename to firedtv Suggested by Andreas Monitzer. Besides DVB-S/-S2 receivers, the driver also supports DVB-C and DVB-T receivers, hence the previous project name is too narrow now. Not yet done: Rename source directory, files, types, variables... Sun, 24 Aug 2008 23:26:23 +0200 (CEST) firesat: add missing copyright notes Reported by Andreas Monitzer and Christian Dolzer. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 06 2月, 2009 1 次提交
-
-
由 Stefan Richter 提交于
On many Linux installations, the dv1394 driver will be auto-loaded whenever an AV/C device (e.g. camcorder or audio device) is plugged in. An irritating message would then appear in the kernel log. Defer this message to until a dv1394 character device file is actually used by a program. Also include the program name in the message and update the message slightly. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 30 1月, 2009 1 次提交
-
-
由 Stefan Richter 提交于
as per https://bugs.launchpad.net/bugs/294391. These got one sample of each iPod generation going. However there still occurred I/O stalls with the 3rd generation iPod which remain undiagnosed at the time of this writing. Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 29 1月, 2009 4 次提交
-
-
由 Stefan Richter 提交于
This makes sbp2 behave more like firewire-sbp2 which reports 0xff000000 as immediate value if there are no unit directory entries for model_id or firmware_revision. It does not reduce matches with the currently existing quirks table; the only zero entry there is for a device which actually does have a zero model_id. It only changes how model_id and firmware_revision are logged if they are missing. Other functionally unrelated changes: The model_id member of quirks list entries is renamed to model; the value (but not the effect) of SBP2_ROM_VALUE_WILDCARD is changed. Now this part of the source is identical with firewire-sbp2 for easier maintenance. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
1394-2008 clause 16.3.4.1 (1394b-2002 clause 16.3.1.1) defines tighter limits than 1394-2008 clause 6.2.2.3 (1394a-2000 clause 6.2.2.3). Our previously too large limit doesn't matter though if the controller reports its max_receive correctly. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
The hard-wired configuration of the top speed (until now S800) was unnecessary, remove it. If the local link layer controller supports S1600 or S3200, we now assume this speed for all present 1394b PHYs (except if they are behind 1394a repeaters) until nodemgr figured out the actual speed while fetching the config ROM. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 27 1月, 2009 1 次提交
-
-
由 Jean Delvare 提交于
Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
- 24 1月, 2009 1 次提交
-
-
由 Stefan Richter 提交于
Camcorders have a tendency to fail read requests to their config ROM and write request to their FCP command register with ack_busy_X. This has become a problem with newer kernels and especially Panasonic camcorders, causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently logs "send oops"; kino reports loss of AV/C control. I suspect that lower CPU scheduling latencies in newer kernels made this issue more prominent now. According to https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 this can be fixed by configuring the FireWire controller for more hardware retries for request transmission; these retries are evidently more successful than libavc1394's own retry loop (typically 3 tries on top of hardware retries). Presumably the same issue has been reported at https://bugzilla.redhat.com/show_bug.cgi?id=449252 and https://bugzilla.redhat.com/show_bug.cgi?id=477279 . Tested-by: Mathias Beilstein Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
- 07 1月, 2009 3 次提交
-
-
由 Stephen Hemminger 提交于
Use the network_device_stats field in network_device. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stephen Hemminger 提交于
Last_rx is now done if needed inside bonding. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stephen Hemminger 提交于
Convert to net_device_ops. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 1月, 2009 4 次提交
-
-
由 Harvey Harrison 提交于
After annotating the frame structs, this was left: drivers/ieee1394/dv1394.c:2113:23: warning: invalid assignment: |= drivers/ieee1394/dv1394.c:2113:23: left side has type restricted __le32 drivers/ieee1394/dv1394.c:2113:23: right side has type int drivers/ieee1394/dv1394.c:2121:24: warning: invalid assignment: &= drivers/ieee1394/dv1394.c:2121:24: left side has type restricted __le32 drivers/ieee1394/dv1394.c:2121:24: right side has type int drivers/ieee1394/dv1394.c:2123:24: warning: invalid assignment: |= drivers/ieee1394/dv1394.c:2123:24: left side has type restricted __le32 drivers/ieee1394/dv1394.c:2123:24: right side has type int Which looks like a real bug on a big-endian arch as it would set/clear the wrong bit. Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com> Bill Fink writes: I finally got a chance to test the patch on my kernel, and live DV viewing using xine still worked fine. Although I admit to being mystified how it works both before and after the patch, since the cpu_to_le32() calls that were added should result in byte swapping on PPC that wasn't being done before. I guess that either the code paths involved aren't actually being triggered by my xine DV viewing, or there's some fortuitous palindromic setting of bits. Tested-by: NBill Fink <billfink@mindspring.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Harvey Harrison 提交于
No Functional changes. Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Harvey Harrison 提交于
Mostly annotations of ether_type as a be16. Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Harvey Harrison 提交于
Two access functions get_max_rom and set_hw_config_rom are changed to take __be32 as well. Only bus_info_data was ever passed in so this is OK. All other uses of bus_info_data treated it as a be32 value already. Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-