Do this by replacing sock_create_kern with inet_ctl_sock_create.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
uc_ttl is initialized in inet(6)_create and never changed except
setsockopt ioctl. Remove this assignment.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace sock_create_kern with inet_ctl_sock_create.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a generic requirement, so make inet_ctl_sock_create namespace
aware and create a inet_ctl_sock_destroy wrapper around
sk_release_kernel.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
All upper protocol layers are already use sock internally.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
sk->sk_proc->(un)hash is noop right now, so the unification is correct.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This call is nothing common with INET connection sockets code. It
simply creates an unhashes kernel sockets for protocol messages.
Move the new call into af_inet.c after the rename.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This seems a purism as module can't be unloaded, but though if cleanup
method is present it should be correct and clean all staff created.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace dccp_v(4|6)_ctl_socket with sock to unify a code with TCP/ICMP.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace tcp_socket with tcp_sock. This is more effective (less
derefferences on fast paths). Additionally, the approach is unified to
one used in ICMP.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Let it update the state of all CPUs. The network stack goes
into pains to feed the current IP addresses in, but it is not very
effective if that is only done for some random CPU instead of all.
So change it to feed bits into all CPUs. I decided to do that lockless
because well somewhat random results are ok.
v2: Drop rename so that this patch doesn't depend on x86 maintainers
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Anycast DST entries allocated inside ipv6_dev_ac_inc are leaked when
network device is stopped without removing IPv6 addresses from it. The
bug has been observed in the reality on 2.6.18-rhel5 kernel.
In the above case addrconf_ifdown marks all entries as obsolete and
ip6_del_rt called from __ipv6_dev_ac_dec returns ENOENT. The
referrence is not dropped.
The fix is simple. DST entry should not keep referrence when stored in
the FIB6 tree.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the other case it will be destroyed when last address will be removed
from lo inside a namespace. This will break IPv6 in several places. The
most obvious one is ip6_dst_ifdown.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
addrconf_ifdown is broken in respect to the usage of how
parameter. This function is called with (event != NETDEV_DOWN) and (2)
on the IPv6 stop. It the latter case inet6_dev from loopback device
should be destroyed.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
GFP_ATOMIC should not be used when GFP_KERNEL can be used.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The driver version numbers and changelog have not been updated in a
long while to reflect actual changes. Remove the version number and
add a notice that later changes can be tracked in SCM.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Commit 4994cd8dad introduced a
regression which causes xpad to report force feedback cababilities
for non-360 controllers too, even while there is no actual support
for those.
Fix that by adding a check for XTYPE_XBOX360 to xpad_init_ff().
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The buttons BTN_C and BTN_Z are only used in the original xbox
controller, not in xbox360 controller. Therefore only add them to
keybit when the controller is a non-360 one.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Add Mad Catz and 0x0e6f xbox360 controllers which are already found
in xpad_device[] table in xpad.c into the vendor id list. Also add
Logitech into the vendor list for Logitech Chillstream gamepads.
Also add the RedOctane Guitar Hero X-plorer.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The commit ae91d10aab inverted Y and RY
axes on xbox360 so that up is positive and down is negative.
This is wrong, as axes on game controllers have up as negative per
convention. Also, even xpad itself reports HAT0X with up as negative.
Fix that by inverting them again.
Also, according to http://bugzilla.kernel.org/show_bug.cgi?id=10337 the
original xbox controllers also have the Y and RY axes inverted.
Fix that by inverting them as well.
Cc: Brian Magnuson <bdmagnuson@gmail.com>
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
For devices not specifically listed in xpad.c, xpad->dpad_mapping
is initially set to MAP_DPAD_UNKNOWN. In xpad_probe() it gets changed
to either MAP_DPAD_TO_BUTTONS or MAP_DPAD_TO_AXES, depending on the
module parameter dpad_to_buttons.
However, MAP_DPAD_UNKNOWN is defined as -1, while the field is u8.
This results in actual value of 255, causing the MAP_DPAD_UNKNOWN
check in xpad_probe() to fail.
Fix that by defining MAP_DPAD_UNKNOWN as 2 instead.
Also, setting module parameter dpad_to_buttons to 1 should obviously
map dpad to buttons, while the default behaviour (0) should be to map
dpad to axes. However, dpad_to_buttons is directly assigned to
xpad->dpad_mapping, and as MAP_DPAD_TO_BUTTONS is 0, the actual
behaviour is reversed.
Fix that by negating dpad_to_buttons in assignment.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Match Xbox 360 controllers using the interface info, i.e. interface
class 255 (Vendor specific), subclass 93 and protocol 1, instead of
specifying the device ids individually. As the class is vendor-specific,
we have to still match against vendor id as well, though.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This does not look good, but there is no other choice. The compilation
without CONFIG_NET is broken and can not be fixed with ease.
After that there is no need for the following commits:
1567ca7eec3edf8fa5cc2d38f9a4f8
Revert them.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The ICMP relookup path is only meant to modify behaviour when
appropriate IPsec policies are in place and marked as requiring
relookups. It is certainly not meant to modify behaviour when
IPsec policies don't exist at all.
However, due to an oversight on the error paths existing behaviour
may in fact change should one of the relookup steps fail.
This patch corrects this by redirecting all errors on relookup
failures to the previous code path. That is, if the initial
xfrm_lookup let the packet pass, we will stand by that decision
should the relookup fail due to an error.
This should be safe from a security point-of-view because compliant
systems must install a default deny policy so the packet would'nt
have passed in that case.
Many thanks to Julian Anastasov for pointing out this error.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
This interface provides more flexible functionality for smp
infrastructure ... e.g. KVM frequently needs to operate on
a subset of cpus.
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Dynamic TR resource should be managed in the uniform way.
Add two interfaces for kernel:
ia64_itr_entry: Allocate a (pair of) TR for caller.
ia64_ptr_entry: Purge a (pair of ) TR by caller.
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Anthony Xu <anthony.xu@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This gets the FEC ethernet driver working again on the lite5200
platform.
The FEC driver is also compatible with the MPC5200, not only with the
MPC5200B, so this adds a suitable entry to the driver's match list.
Furthermore this adds the settings for the PHY in the dts file for the
Lite5200. Note, that this is not exactly the same as in the
Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
at :00 for the 5200B. This was tested on a Lite5200 and a Lite5200B,
both booted a kernel via tftp and mounted the root via nfs
successfully.
Signed-off-by: René Bürgel <r.buergel@unicontrol.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Handling of the proc_dir_entry->count was changed in 2.6.24-rc5.
After this change, the default value for pde->count is 1 and not 0 as
before. Therefore, if we want to check whether our procfs file is
already opened (already in use), we have to check if pde->count is
greater than 2 rather than 1.
Signed-off-by: Maxim Shchetynin <maxim@de.ibm.com>
Signed-off-by: Jens Osterkamp <jens@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
hash_page_sync() takes and releases the low level mmu hash
lock in order to sync with other processors disposing of page
tables. Because that lock can be needed to service hash misses
triggered by interrupt handlers, taking it must be done with
interrupts off. However, hash_page_sync() appears to be called
with interrupts enabled, thus causing occasional deadlocks.
We fix it by making sure hash_page_sync() masks interrupts while
holding the lock.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
A subtle bug sneaked into iSeries recently. On this platform, we must
not normally clear MSR:EE (the hardware external interrupt enable)
except for short periods of time. Taking an interrupt while
soft-disabled doesn't cause us to clear it for example.
The iSeries kernel expects to mostly run with MSR:EE enabled at all
times except in a few exception entry/exit code paths. Thus
local_irq_enable() doesn't check if it needs to hard-enable as it
expects this to be unnecessary on iSeries.
However, hard_irq_disable() _does_ cause MSR:EE to be cleared,
including on iSeries. A call to it was recently added to the
context switch code, thus causing interrupts to become disabled
for a long periods of time, causing the iSeries watchdog to kick
in under some circumstances and other nasty things.
This patch fixes it by making local_irq_enable() properly re-enable
MSR:EE on iSeries. It basically removes a return statement here
to make iSeries use the same code path as everybody else. That does
mean that we might occasionally get spurious decrementer interrupts
but I don't think that matters.
Another option would have been to make hard_irq_disable() a nop
on iSeries but I didn't like it much, in case we have good reasons
to hard-disable.
Part of the patch is fixes to make sure the hard_enabled PACA field
is properly set on iSeries as it used not to be before, since it
was mostly unused.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
A missing break statement in a switch caused cpm2_clk_setup() to initialize
SCC2 instead of SCC1.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch creates a common system reset routine for all 40x and 44x
systems. Previously only a 44x routine existed. But since this system
reset via the debug control register is common for 40x and 44x let's
share this code for all those platforms in ppc4xx_soc.c.
This patch also enables CONFIG_4xx_SOC for all 40x and 44x platforms.
Tested on Kilauea (405EX) and Canyonlands (440EX).
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
This target produces a flat binary rather than an ELF file,
fixes the entry point at the beginning of the image, and takes
a complete device tree with no fixups needed.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
The of_serial driver queries the current-speed property and attempts
to use it to register the custom_divisor property of the uart_port.
However, if current-speed is not set, then this code will dereference
a bad pointer. The fix is to only set custom_divisor when a
current-speed property appears in the device tree.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
The patch fixes a bug, where the PESDRn_UTLSET1 register was setup
wrongly resulting in a non working PCIe port 1. With this fix both
PCIe ports work fine again.
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Since the arch/powerpc PCI subsystem now does a complete re-assignment of
the resources, we can move from the unconditional PCIe PHY reset to the
conditional version. Now the PHY is only reset, if no link is established yet.
An additional PHY reset (one is already done in U-Boot) leads to problems
with some Atheros PCIe boards and some HP FPGA PCIe designs.
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Call dtc from the Makefile instead of the wrapper script so that the dt
blobs can be generated with a simple make invocation.
Using this patch allows board ports to trigger automatic building of .dtb
files by adding them to the image-y target list.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
