- 23 Apr, 2009 8 commits
-
-
Hendrik Brueckner authored
The SO_MSGLIMIT socket option modifies the message limit for new IUCV communication paths. The message limit specifies the maximum number of outstanding messages that are allowed for connections. This setting can be lowered by z/VM when an IUCV connection is established. Expects an integer value in the range of 1 to 65535. The default value is 65535. The message limit must be set before calling connect() or listen() for sockets. If sockets are already connected or in state listen, changing the message limit is not supported. For reading the message limit value, unconnected sockets return the limit that has been set or the default limit. For connected sockets, the actual message limit is returned. The actual message limit is assigned by z/VM for each connection and it depends on IUCV MSGLIMIT authorizations specified for the z/VM guest virtual machine. Signed-off-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by:
Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Hendrik Brueckner authored
If the skb cannot be copied to user iovec, always return -EFAULT. The skb is enqueued again, except MSG_PEEK flag is set, to allow user space applications to correct its iovec pointer. Signed-off-by:
-
Hendrik Brueckner authored
This patch provides the socket type SOCK_SEQPACKET in addition to SOCK_STREAM. AF_IUCV sockets of type SOCK_SEQPACKET supports an 1:1 mapping of socket read or write operations to complete IUCV messages. Socket data or IUCV message data is not fragmented as this is the case for SOCK_STREAM sockets. The intention is to help application developers who write applications or device drivers using native IUCV interfaces (Linux kernel or z/VM IUCV interfaces). Signed-off-by:
-
Hendrik Brueckner authored
Allow 'classification' of socket data that is sent or received over an af_iucv socket. For classification of data, the target class of an (native) iucv message is used. This patch provides the cmsg interface for iucv_sock_recvmsg() and iucv_sock_sendmsg(). Applications can use the msg_control field of struct msghdr to set or get the target class as a "socket control message" (SCM/CMSG). Signed-off-by:
-
Hendrik Brueckner authored
The patch allows to send and receive data in the parameter list of an iucv message. The parameter list is an arry of 8 bytes that are used by af_iucv as follows: 0..6 7 bytes for socket data and 7 1 byte to store the data length. Instead of storing the data length directly, the difference between 0xFF and the data length is used. This convention does not interfere with the existing use of PRM messages for shutting down the send direction of an AF_IUCV socket (shutdown() operation). Data lenghts greater than 7 (or PRM message byte 8 is less than 0xF8) denotes to special messages. Currently, the special SEND_SHUTDOWN message is supported only. To use IPRM messages, both communicators must set the IUCV_IPRMDATA flag during path negotiation, i.e. in iucv_connect() and path_pending(). To be compatible to older af_iucv implementations, sending PRM messages is controlled by the socket option SO_IPRMDATA_MSG. Receiving PRM messages does not depend on the socket option (but requires the IUCV_IPRMDATA path flag to be set). Sending/Receiving data in the parameter list improves performance for small amounts of data by reducing message_completion() interrupts and memory copy operations. Signed-off-by:
-
Hendrik Brueckner authored
Provide the socket operations getsocktopt() and setsockopt() to enable/disable sending of data in the parameter list of IUCV messages. The patch sets respective flag only. Signed-off-by:
-
Hendrik Brueckner authored
If the af_iucv communication partner quiesces the path to shutdown its receive direction, provide a quiesce callback implementation to shutdown the (local) send direction. This ensures that both sides are synchronized. Signed-off-by:
-
Ursula Braun authored
Some of the IUCV commands can be invoked in interrupt context. Those commands need a different per-cpu IUCV command parameter block, otherwise they might overwrite an IUCV command parameter of a not yet finished IUCV command invocation in process context. Signed-off-by:
-
- 22 Apr, 2009 3 commits
-
-
Mateusz Mandera authored
This trivial patch just "gets rid of" init_module and cleanup_module from drivers/net/8390p.c Signed-off-by:
Mateusz Mandera <ormi.linux@gmail.com> Signed-off-by:
-
Jesse Brandeburg authored
It was pointed out that the Intel wired ethernet drivers do not need to wake the tx queue since netif_carrier_on/off will take care of the qdisc management in order to guarantee the correct handling of the transmit routine enable state. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Alexander Beregalov authored
Fix simple typo. Caused by commit a1de9666 ("irda/sa1100_ir: convert to net_device_ops"). Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by:
-
- 21 Apr, 2009 16 commits
-
-
Michael S. Tsirkin authored
aio_write gets const struct iovec * but tun_chr_aio_write casts this to struct iovec * and modifies the iovec. As a result, attempts to use io_submit to send packets to a tun device fail with weird errors such as EINVAL. Since tun is the only user of skb_copy_datagram_from_iovec, we can fix this simply by changing the later so that it does not touch the iovec passed to it. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Michael S. Tsirkin authored
aio_read gets const struct iovec * but tun_chr_aio_read casts this to struct iovec * and modifies the iovec. As a result, attempts to use io_submit to get packets from a tun device fail with weird errors such as EINVAL. Fix by using the new skb_copy_datagram_const_iovec. Signed-off-by:
-
Michael S. Tsirkin authored
There's an skb_copy_datagram_iovec() to copy out of a paged skb, but it modifies the iovec, and does not support starting at an offset in the destination. We want both in tun.c, so let's add the function. It's a carbon copy of skb_copy_datagram_iovec() with enough changes to be annoying. Signed-off-by:
-
Joakim Tjernlund authored
This will make the system alot more responsive while ping flooding the ucc_geth ethernet interface. Also set NAPI weight to 64 as this is a common value. Signed-off-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by:
-
Jianjun Kong authored
unify the struct's name of "struct rtl8139_private *np" to "struct rtl8139_private *tp" most of them like this: struct rtl8139_private *tp = netdev_priv(dev); Signed-off-by:
Amos Kong <jianjun@zeuux.org> Signed-off-by:
-
Patrick McHardy authored
Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Peter Holik authored
usb driver for intellon int51x1 based PLC like devolo dlan duo with improvements suggested by the guys of the mailinglist: - name and prefix with int51x1 (Florian Fainelli) - use conversion functions cpu_to_le16 / le16_to_cpu (Oliver Neukum) - use pskb_may_pull instead of skb->len (Ilpo Järvinen) - better code in tx_fixup (Ilpo Järvinen) - use gotos for error handling (Ilpo Järvinen) - better description (Jon Smirl) Signed-off-by:
Peter Holik <peter@holik.at> Signed-off-by:
-
Peter Holik authored
because of using the same function get_ethernet_addr as cdc_ether.c i export usbnet_get_ethernet_addr from usbnet and fixed cdc_ether (suggested by Oliver Neukum). Signed-off-by:
-
Matt Carlson authored
This patch updates the tg3 version to 3.99. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Matt Carlson authored
After a shutdown reset, the LAA needs to be restored before posting the post-reset signature in shared memory. If the LAA is not restored before then, the bootcode will assume the factory default MAC address and WOL will not work with the LAA. Signed-off-by:
-
Matt Carlson authored
This patch restricts the CLKREQ bugfix to the A0 and A1 revisions of 57780 ASIC rev chips. Signed-off-by:
-
Matt Carlson authored
The 5761 WOL and LED fixes used the PCI device ID to as the activation key. The 5761S requires the same process. Signed-off-by:
-
Matt Carlson authored
On rare occasions, send BD corruptions can occur. This patch fixes the problem by increasing the L1 entry threshold to 4 milliseconds. Signed-off-by:
-
Matt Carlson authored
Some 57780 ASIC revision parts do not have NVRAM. Code the driver so that it is tolerant of this configuration. Signed-off-by:
-
Matt Carlson authored
The tg3 driver's ISR is coded to accept interrupts as its own if the status block tag does not equal the last tag the driver has seen. The last_tag field is updated from tg3_poll. In a screaming interrupt situation from another device sharing tg3's IRQ, tg3_poll does not get a chance to be called, so the last_tag will always be out of sync with the status block tag. Consequently, the driver will continually declare the screaming interrupts as its own, thus thwarting the screaming interrupt detection logic. This patch solves the problem by creating a new last_irq_tag member and recording the status block tag in the ISR. The ISR then checks the last_irq_tag for interrupt ownership. Many thanks to John Marvin for the detailed bug report and analysis and Michael Chan for the bugfix. Signed-off-by:
John Marvin <jsm@fc.hp.com> Signed-off-by:
-
David S. Miller authored
Conflicts: net/core/dev.c
-
- 20 Apr, 2009 13 commits
-
-
-
Matt Carlson authored
The recent NVRAM patches sanitized how the driver deals with NVRAM data, but they failed to bring the SEEPROM interfaces inline with the new strategy. This patch brings the SEEPROM interfaces up to date. This patch also reverts commit 0d489ffb ("tg3: fix big endian MAC address collection failure"). Signed-off-by:
Robin Holt <holt@sgi.com> Tested-by:
James Bottomley <james.bottomley@HansenPartnership.com> Signed-off-by:
-
Johannes Berg authored
"mac80211: fix basic rates setting from association response" introduced a copy/paste error. Unfortunately, this not just leads to wrong data being passed to the driver but is remotely exploitable for some hardware or driver combinations. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Cc: stable@kernel.org [2.6.29] Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Kalle Valo authored
Currently beacon loss detection triggers after a scan. A probe request is sent and a message like this is printed to the log: wlan0: beacon loss from AP 00:12:17:e7:98:de - sending probe request But in fact there is no beacon loss, the beacons are just not received because of the ongoing scan. Fix it by updating last_beacon after the scan has finished. Reported-by:
Jaswinder Singh Rajput <jaswinder@kernel.org> Signed-off-by:
Kalle Valo <kalle.valo@iki.fi> Acked-by:
-
Jouni Malinen authored
One of the code paths sending deauth/disassoc events ends up calling this function with rcu_read_lock held, so we must use GFP_ATOMIC in allocation routines. Reported-by:
Jouni Malinen <j@w1.fi> Signed-off-by:
-
Christian Lamparter authored
This patch fixes a hang on resume when the filesystem is not available and request_firmware blocks. However, the device does not accept the firmware on resume. and it will exit with: > firmware part 1 upload failed (-71). > device is in a bad state. please reconnect it! Reported-by:
Christian Lamparter <chunkeey@web.de> Signed-off-by:
-
Robert P. J. Day authored
Remove this unused Kconfig variable, which Intel apparently once promised to make use of but never did. Signed-off-by:
Robert P. J. Day <rpjday@crashcourse.ca> Acked-by:
-
Joerg Albert authored
swap mwl8k_remove and mwl8k_shutdown functions to allow "rmmod mwl8k; modprobe mwl8k" Signed-off-by:
Joerg Albert <jal2@gmx.de> Signed-off-by:
-
Christian Lamparter authored
This patch deactivates powersave in station mode. It does not work correctly yet, so the code does more harm than good. Reported-by:
-
Joe Perches authored
"not" is not printed without a space after %pM Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Ivo van Doorn authored
After suspend & resume the rt2x00 devices won't wakeup anymore due to a broken register information setup. The most important problem is the release of the EEPROM buffer which is completely cleared and never read again after the suspend. Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Herbert Xu authored
As the sk_sleep wait queue actually lives in tfile, which may be detached from the tun device, bad things will happen when we use sk_sleep after detaching. Since the tun device is the persistent data structure here (when requested by the user), it makes much more sense to have the wait queue live there. There is no reason to have it in tfile at all since the only time we can wait is if we have a tun attached. In fact we already have a wait queue in tun_struct, so we might as well use it. Reported-by:
Eric W. Biederman <ebiederm@xmission.com> Tested-by:
Christian Borntraeger <borntraeger@de.ibm.com> Tested-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
The commit c70f1829 ("tun: Fix races between tun_net_close and free_netdev") fixed a race where an asynchronous deletion of a tun device can hose a poll(2) on a tun fd attached to that device. However, this came at the cost of moving the tun wait queue into the tun file data structure. The problem with this is that it imposes restrictions on when and where the tun device can access the wait queue since the tun file may change at any time due to detaching and reattaching. In particular, now that we need to use the wait queue on the receive path it becomes difficult to properly synchronise this with the detachment of the tun device. This patch solves the original race in a different way. Since the race is only because the underlying memory gets freed, we can prevent it simply by ensuring that we don't do that until all tun descriptors ever attached to the device (even if they have since be detached because they may still be sitting in poll) have been closed. This is done by using reference counting the attached tun file descriptors. The refcount in tun->sk has been reappropriated for this purpose since it was already being used for that, albeit from the opposite angle. Note that we no longer zero tfile->tun since tun_get will return NULL anyway after the refcount on tfile hits zero. Instead it represents whether this device has ever been attached to a device. Signed-off-by:
-
