mirror of
https://github.com/ukui/kernel.git
synced 2026-03-09 10:07:04 -07:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Conflicts:
drivers/net/ethernet/emulex/benet/be.h
drivers/net/netconsole.c
net/bridge/br_private.h
Three mostly trivial conflicts.
The net/bridge/br_private.h conflict was a function signature (argument
addition) change overlapping with the extern removals from Joe Perches.
In drivers/net/netconsole.c we had one change adjusting a printk message
whilst another changed "printk(KERN_INFO" into "pr_info(".
Lastly, the emulex change was a new inline function addition overlapping
with Joe Perches's extern removals.
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
David S. Miller
@@ -18,8 +18,8 @@ Introduction
|
||||
Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
|
||||
oriented protocol designed to solve issues present in UDP and TCP, particularly
|
||||
for real-time and multimedia (streaming) traffic.
|
||||
It divides into a base protocol (RFC 4340) and plugable congestion control
|
||||
modules called CCIDs. Like plugable TCP congestion control, at least one CCID
|
||||
It divides into a base protocol (RFC 4340) and pluggable congestion control
|
||||
modules called CCIDs. Like pluggable TCP congestion control, at least one CCID
|
||||
needs to be enabled in order for the protocol to function properly. In the Linux
|
||||
implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as
|
||||
the TCP-friendly CCID3 (RFC 4342), are optional.
|
||||
|
||||
@@ -103,7 +103,7 @@ Additional Configurations
|
||||
PRO/100 Family of Adapters is e100.
|
||||
|
||||
As an example, if you install the e100 driver for two PRO/100 adapters
|
||||
(eth0 and eth1), add the following to a configuraton file in /etc/modprobe.d/
|
||||
(eth0 and eth1), add the following to a configuration file in /etc/modprobe.d/
|
||||
|
||||
alias eth0 e100
|
||||
alias eth1 e100
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
Introduction
|
||||
============
|
||||
The IEEE 802.15.4 working group focuses on standartization of bottom
|
||||
The IEEE 802.15.4 working group focuses on standardization of bottom
|
||||
two layers: Medium Access Control (MAC) and Physical (PHY). And there
|
||||
are mainly two options available for upper layers:
|
||||
- ZigBee - proprietary protocol from ZigBee Alliance
|
||||
@@ -66,7 +66,7 @@ net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
|
||||
code via plain sk_buffs. On skb reception skb->cb must contain additional
|
||||
info as described in the struct ieee802154_mac_cb. During packet transmission
|
||||
the skb->cb is used to provide additional data to device's header_ops->create
|
||||
function. Be aware, that this data can be overriden later (when socket code
|
||||
function. Be aware that this data can be overridden later (when socket code
|
||||
submits skb to qdisc), so if you need something from that cb later, you should
|
||||
store info in the skb->data on your own.
|
||||
|
||||
|
||||
@@ -197,7 +197,7 @@ state information because the file format is subject to change. It is
|
||||
implemented to provide extra debug information to help diagnose
|
||||
problems.) Users should use the netlink API.
|
||||
|
||||
/proc/net/pppol2tp is also provided for backwards compaibility with
|
||||
/proc/net/pppol2tp is also provided for backwards compatibility with
|
||||
the original pppol2tp driver. It lists information about L2TPv2
|
||||
tunnels and sessions only. Its use is discouraged.
|
||||
|
||||
|
||||
@@ -4,23 +4,23 @@ Information you need to know about netdev
|
||||
|
||||
Q: What is netdev?
|
||||
|
||||
A: It is a mailing list for all network related linux stuff. This includes
|
||||
A: It is a mailing list for all network-related Linux stuff. This includes
|
||||
anything found under net/ (i.e. core code like IPv6) and drivers/net
|
||||
(i.e. hardware specific drivers) in the linux source tree.
|
||||
(i.e. hardware specific drivers) in the Linux source tree.
|
||||
|
||||
Note that some subsystems (e.g. wireless drivers) which have a high volume
|
||||
of traffic have their own specific mailing lists.
|
||||
|
||||
The netdev list is managed (like many other linux mailing lists) through
|
||||
The netdev list is managed (like many other Linux mailing lists) through
|
||||
VGER ( http://vger.kernel.org/ ) and archives can be found below:
|
||||
|
||||
http://marc.info/?l=linux-netdev
|
||||
http://www.spinics.net/lists/netdev/
|
||||
|
||||
Aside from subsystems like that mentioned above, all network related linux
|
||||
development (i.e. RFC, review, comments, etc) takes place on netdev.
|
||||
Aside from subsystems like that mentioned above, all network-related Linux
|
||||
development (i.e. RFC, review, comments, etc.) takes place on netdev.
|
||||
|
||||
Q: How do the changes posted to netdev make their way into linux?
|
||||
Q: How do the changes posted to netdev make their way into Linux?
|
||||
|
||||
A: There are always two trees (git repositories) in play. Both are driven
|
||||
by David Miller, the main network maintainer. There is the "net" tree,
|
||||
@@ -35,7 +35,7 @@ A: There are always two trees (git repositories) in play. Both are driven
|
||||
Q: How often do changes from these trees make it to the mainline Linus tree?
|
||||
|
||||
A: To understand this, you need to know a bit of background information
|
||||
on the cadence of linux development. Each new release starts off with
|
||||
on the cadence of Linux development. Each new release starts off with
|
||||
a two week "merge window" where the main maintainers feed their new
|
||||
stuff to Linus for merging into the mainline tree. After the two weeks,
|
||||
the merge window is closed, and it is called/tagged "-rc1". No new
|
||||
@@ -46,7 +46,7 @@ A: To understand this, you need to know a bit of background information
|
||||
things are in a state of churn), and a week after the last vX.Y-rcN
|
||||
was done, the official "vX.Y" is released.
|
||||
|
||||
Relating that to netdev: At the beginning of the 2 week merge window,
|
||||
Relating that to netdev: At the beginning of the 2-week merge window,
|
||||
the net-next tree will be closed - no new changes/features. The
|
||||
accumulated new content of the past ~10 weeks will be passed onto
|
||||
mainline/Linus via a pull request for vX.Y -- at the same time,
|
||||
@@ -59,16 +59,16 @@ A: To understand this, you need to know a bit of background information
|
||||
IMPORTANT: Do not send new net-next content to netdev during the
|
||||
period during which net-next tree is closed.
|
||||
|
||||
Shortly after the two weeks have passed, (and vX.Y-rc1 is released) the
|
||||
Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
|
||||
tree for net-next reopens to collect content for the next (vX.Y+1) release.
|
||||
|
||||
If you aren't subscribed to netdev and/or are simply unsure if net-next
|
||||
has re-opened yet, simply check the net-next git repository link above for
|
||||
any new networking related commits.
|
||||
any new networking-related commits.
|
||||
|
||||
The "net" tree continues to collect fixes for the vX.Y content, and
|
||||
is fed back to Linus at regular (~weekly) intervals. Meaning that the
|
||||
focus for "net" is on stablilization and bugfixes.
|
||||
focus for "net" is on stabilization and bugfixes.
|
||||
|
||||
Finally, the vX.Y gets released, and the whole cycle starts over.
|
||||
|
||||
@@ -217,7 +217,7 @@ A: Attention to detail. Re-read your own work as if you were the
|
||||
to why it happens, and then if necessary, explain why the fix proposed
|
||||
is the best way to get things done. Don't mangle whitespace, and as
|
||||
is common, don't mis-indent function arguments that span multiple lines.
|
||||
If it is your 1st patch, mail it to yourself so you can test apply
|
||||
If it is your first patch, mail it to yourself so you can test apply
|
||||
it to an unpatched tree to confirm infrastructure didn't mangle it.
|
||||
|
||||
Finally, go back and read Documentation/SubmittingPatches to be
|
||||
|
||||
@@ -45,7 +45,7 @@ processing.
|
||||
|
||||
Conversion of the reception path involves calling poll() on the file
|
||||
descriptor, once the socket is readable the frames from the ring are
|
||||
processsed in order until no more messages are available, as indicated by
|
||||
processed in order until no more messages are available, as indicated by
|
||||
a status word in the frame header.
|
||||
|
||||
On kernel side, in order to make use of memory mapped I/O on receive, the
|
||||
@@ -56,7 +56,7 @@ Dumps of kernel databases automatically support memory mapped I/O.
|
||||
|
||||
Conversion of the transmit path involves changing message construction to
|
||||
use memory from the TX ring instead of (usually) a buffer declared on the
|
||||
stack and setting up the frame header approriately. Optionally poll() can
|
||||
stack and setting up the frame header appropriately. Optionally poll() can
|
||||
be used to wait for free frames in the TX ring.
|
||||
|
||||
Structured and definitions for using memory mapped I/O are contained in
|
||||
@@ -231,7 +231,7 @@ Ring setup:
|
||||
if (setsockopt(fd, NETLINK_TX_RING, &req, sizeof(req)) < 0)
|
||||
exit(1)
|
||||
|
||||
/* Calculate size of each invididual ring */
|
||||
/* Calculate size of each individual ring */
|
||||
ring_size = req.nm_block_nr * req.nm_block_size;
|
||||
|
||||
/* Map RX/TX rings. The TX ring is located after the RX ring */
|
||||
|
||||
@@ -89,8 +89,8 @@ packets. The name 'carrier' and the inversion are historical, think of
|
||||
it as lower layer.
|
||||
|
||||
Note that for certain kind of soft-devices, which are not managing any
|
||||
real hardware, there is possible to set this bit from userpsace.
|
||||
One should use TVL IFLA_CARRIER to do so.
|
||||
real hardware, it is possible to set this bit from userspace. One
|
||||
should use TVL IFLA_CARRIER to do so.
|
||||
|
||||
netif_carrier_ok() can be used to query that bit.
|
||||
|
||||
|
||||
@@ -144,7 +144,7 @@ An overview of the RxRPC protocol:
|
||||
(*) Calls use ACK packets to handle reliability. Data packets are also
|
||||
explicitly sequenced per call.
|
||||
|
||||
(*) There are two types of positive acknowledgement: hard-ACKs and soft-ACKs.
|
||||
(*) There are two types of positive acknowledgment: hard-ACKs and soft-ACKs.
|
||||
A hard-ACK indicates to the far side that all the data received to a point
|
||||
has been received and processed; a soft-ACK indicates that the data has
|
||||
been received but may yet be discarded and re-requested. The sender may
|
||||
|
||||
@@ -160,7 +160,7 @@ Where:
|
||||
o pmt: core has the embedded power module (optional).
|
||||
o force_sf_dma_mode: force DMA to use the Store and Forward mode
|
||||
instead of the Threshold.
|
||||
o force_thresh_dma_mode: force DMA to use the Shreshold mode other than
|
||||
o force_thresh_dma_mode: force DMA to use the Threshold mode other than
|
||||
the Store and Forward mode.
|
||||
o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode.
|
||||
o fix_mac_speed: this callback is used for modifying some syscfg registers
|
||||
@@ -175,7 +175,7 @@ Where:
|
||||
registers.
|
||||
o custom_cfg/custom_data: this is a custom configuration that can be passed
|
||||
while initializing the resources.
|
||||
o bsp_priv: another private poiter.
|
||||
o bsp_priv: another private pointer.
|
||||
|
||||
For MDIO bus The we have:
|
||||
|
||||
@@ -271,7 +271,7 @@ reset procedure etc).
|
||||
o dwmac1000_dma.c: dma functions for the GMAC chip;
|
||||
o dwmac1000.h: specific header file for the GMAC;
|
||||
o dwmac100_core: MAC 100 core and dma code;
|
||||
o dwmac100_dma.c: dma funtions for the MAC chip;
|
||||
o dwmac100_dma.c: dma functions for the MAC chip;
|
||||
o dwmac1000.h: specific header file for the MAC;
|
||||
o dwmac_lib.c: generic DMA functions shared among chips;
|
||||
o enh_desc.c: functions for handling enhanced descriptors;
|
||||
@@ -364,4 +364,4 @@ Auto-negotiated Link Parter Ability.
|
||||
10) TODO:
|
||||
o XGMAC is not supported.
|
||||
o Complete the TBI & RTBI support.
|
||||
o extened VLAN support for 3.70a SYNP GMAC.
|
||||
o extend VLAN support for 3.70a SYNP GMAC.
|
||||
|
||||
@@ -68,7 +68,7 @@ Module parameters
|
||||
|
||||
There are several parameters which may be provided to the driver when
|
||||
its module is loaded. These are usually placed in /etc/modprobe.d/*.conf
|
||||
configuretion files. Example:
|
||||
configuration files. Example:
|
||||
|
||||
options 3c59x debug=3 rx_copybreak=300
|
||||
|
||||
@@ -178,7 +178,7 @@ max_interrupt_work=N
|
||||
|
||||
The driver's interrupt service routine can handle many receive and
|
||||
transmit packets in a single invocation. It does this in a loop.
|
||||
The value of max_interrupt_work governs how mnay times the interrupt
|
||||
The value of max_interrupt_work governs how many times the interrupt
|
||||
service routine will loop. The default value is 32 loops. If this
|
||||
is exceeded the interrupt service routine gives up and generates a
|
||||
warning message "eth0: Too much work in interrupt".
|
||||
|
||||
@@ -105,7 +105,7 @@ reduced by the following measures or a combination thereof:
|
||||
later.
|
||||
The lapb module interface was modified to support this. Its
|
||||
data_indication() method should now transparently pass the
|
||||
netif_rx() return value to the (lapb mopdule) caller.
|
||||
netif_rx() return value to the (lapb module) caller.
|
||||
(2) Drivers for kernel versions 2.2.x should always check the global
|
||||
variable netdev_dropping when a new frame is received. The driver
|
||||
should only call netif_rx() if netdev_dropping is zero. Otherwise
|
||||
|
||||
131
MAINTAINERS
131
MAINTAINERS
@@ -1009,6 +1009,7 @@ ARM/Marvell Armada 370 and Armada XP SOC support
|
||||
M: Jason Cooper <jason@lakedaemon.net>
|
||||
M: Andrew Lunn <andrew@lunn.ch>
|
||||
M: Gregory Clement <gregory.clement@free-electrons.com>
|
||||
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-mvebu/
|
||||
@@ -1016,6 +1017,7 @@ F: arch/arm/mach-mvebu/
|
||||
ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
|
||||
M: Jason Cooper <jason@lakedaemon.net>
|
||||
M: Andrew Lunn <andrew@lunn.ch>
|
||||
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-dove/
|
||||
@@ -1148,6 +1150,13 @@ F: drivers/net/ethernet/i825xx/ether1*
|
||||
F: drivers/net/ethernet/seeq/ether3*
|
||||
F: drivers/scsi/arm/
|
||||
|
||||
ARM/Rockchip SoC support
|
||||
M: Heiko Stuebner <heiko@sntech.de>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-rockchip/
|
||||
F: drivers/*/*rockchip*
|
||||
|
||||
ARM/SHARK MACHINE SUPPORT
|
||||
M: Alexander Schulz <alex@shark-linux.de>
|
||||
W: http://www.shark-linux.de/shark.html
|
||||
@@ -2719,6 +2728,8 @@ T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
|
||||
DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
|
||||
M: Vinod Koul <vinod.koul@intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
L: dmaengine@vger.kernel.org
|
||||
Q: https://patchwork.kernel.org/project/linux-dmaengine/list/
|
||||
S: Supported
|
||||
F: drivers/dma/
|
||||
F: include/linux/dma*
|
||||
@@ -2822,7 +2833,7 @@ M: Terje Bergström <tbergstrom@nvidia.com>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
L: linux-tegra@vger.kernel.org
|
||||
T: git git://anongit.freedesktop.org/tegra/linux.git
|
||||
S: Maintained
|
||||
S: Supported
|
||||
F: drivers/gpu/host1x/
|
||||
F: include/uapi/drm/tegra_drm.h
|
||||
F: Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
|
||||
@@ -4358,7 +4369,10 @@ F: arch/x86/kernel/microcode_intel.c
|
||||
|
||||
INTEL I/OAT DMA DRIVER
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
S: Maintained
|
||||
M: Dave Jiang <dave.jiang@intel.com>
|
||||
L: dmaengine@vger.kernel.org
|
||||
Q: https://patchwork.kernel.org/project/linux-dmaengine/list/
|
||||
S: Supported
|
||||
F: drivers/dma/ioat*
|
||||
|
||||
INTEL IOMMU (VT-d)
|
||||
@@ -8310,14 +8324,72 @@ L: linux-media@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/media/rc/ttusbir.c
|
||||
|
||||
TEGRA SUPPORT
|
||||
TEGRA ARCHITECTURE SUPPORT
|
||||
M: Stephen Warren <swarren@wwwdotorg.org>
|
||||
M: Thierry Reding <thierry.reding@gmail.com>
|
||||
L: linux-tegra@vger.kernel.org
|
||||
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
|
||||
S: Supported
|
||||
N: [^a-z]tegra
|
||||
|
||||
TEGRA ASOC DRIVER
|
||||
M: Stephen Warren <swarren@wwwdotorg.org>
|
||||
S: Supported
|
||||
F: sound/soc/tegra/
|
||||
|
||||
TEGRA CLOCK DRIVER
|
||||
M: Peter De Schrijver <pdeschrijver@nvidia.com>
|
||||
M: Prashant Gaikwad <pgaikwad@nvidia.com>
|
||||
S: Supported
|
||||
F: drivers/clk/tegra/
|
||||
|
||||
TEGRA DMA DRIVER
|
||||
M: Laxman Dewangan <ldewangan@nvidia.com>
|
||||
S: Supported
|
||||
F: drivers/dma/tegra20-apb-dma.c
|
||||
|
||||
TEGRA GPIO DRIVER
|
||||
M: Stephen Warren <swarren@wwwdotorg.org>
|
||||
S: Supported
|
||||
F: drivers/gpio/gpio-tegra.c
|
||||
|
||||
TEGRA I2C DRIVER
|
||||
M: Laxman Dewangan <ldewangan@nvidia.com>
|
||||
S: Supported
|
||||
F: drivers/i2c/busses/i2c-tegra.c
|
||||
|
||||
TEGRA IOMMU DRIVERS
|
||||
M: Hiroshi Doyu <hdoyu@nvidia.com>
|
||||
S: Supported
|
||||
F: drivers/iommu/tegra*
|
||||
|
||||
TEGRA KBC DRIVER
|
||||
M: Rakesh Iyer <riyer@nvidia.com>
|
||||
M: Laxman Dewangan <ldewangan@nvidia.com>
|
||||
S: Supported
|
||||
F: drivers/input/keyboard/tegra-kbc.c
|
||||
|
||||
TEGRA PINCTRL DRIVER
|
||||
M: Stephen Warren <swarren@wwwdotorg.org>
|
||||
S: Supported
|
||||
F: drivers/pinctrl/pinctrl-tegra*
|
||||
|
||||
TEGRA PWM DRIVER
|
||||
M: Thierry Reding <thierry.reding@gmail.com>
|
||||
S: Supported
|
||||
F: drivers/pwm/pwm-tegra.c
|
||||
|
||||
TEGRA SERIAL DRIVER
|
||||
M: Laxman Dewangan <ldewangan@nvidia.com>
|
||||
S: Supported
|
||||
F: drivers/tty/serial/serial-tegra.c
|
||||
|
||||
TEGRA SPI DRIVER
|
||||
M: Laxman Dewangan <ldewangan@nvidia.com>
|
||||
S: Supported
|
||||
F: drivers/spi/spi-tegra*
|
||||
|
||||
TEHUTI ETHERNET DRIVER
|
||||
M: Andy Gospodarek <andy@greyhouse.net>
|
||||
L: netdev@vger.kernel.org
|
||||
@@ -8853,61 +8925,14 @@ W: http://pegasus2.sourceforge.net/
|
||||
S: Maintained
|
||||
F: drivers/net/usb/rtl8150.c
|
||||
|
||||
USB SERIAL BELKIN F5U103 DRIVER
|
||||
M: William Greathouse <wgreathouse@smva.com>
|
||||
USB SERIAL SUBSYSTEM
|
||||
M: Johan Hovold <jhovold@gmail.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/usb/serial/belkin_sa.*
|
||||
|
||||
USB SERIAL CYPRESS M8 DRIVER
|
||||
M: Lonnie Mendez <dignome@gmail.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://geocities.com/i0xox0i
|
||||
W: http://firstlight.net/cvs
|
||||
F: drivers/usb/serial/cypress_m8.*
|
||||
|
||||
USB SERIAL CYBERJACK DRIVER
|
||||
M: Matthias Bruestle and Harald Welte <support@reiner-sct.com>
|
||||
W: http://www.reiner-sct.de/support/treiber_cyberjack.php
|
||||
S: Maintained
|
||||
F: drivers/usb/serial/cyberjack.c
|
||||
|
||||
USB SERIAL DIGI ACCELEPORT DRIVER
|
||||
M: Peter Berger <pberger@brimson.com>
|
||||
M: Al Borchers <alborchers@steinerpoint.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/usb/serial/digi_acceleport.c
|
||||
|
||||
USB SERIAL DRIVER
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/usb/usb-serial.txt
|
||||
F: drivers/usb/serial/generic.c
|
||||
F: drivers/usb/serial/usb-serial.c
|
||||
F: drivers/usb/serial/
|
||||
F: include/linux/usb/serial.h
|
||||
|
||||
USB SERIAL EMPEG EMPEG-CAR MARK I/II DRIVER
|
||||
M: Gary Brubaker <xavyer@ix.netcom.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/usb/serial/empeg.c
|
||||
|
||||
USB SERIAL KEYSPAN DRIVER
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/usb/serial/*keyspan*
|
||||
|
||||
USB SERIAL WHITEHEAT DRIVER
|
||||
M: Support Department <support@connecttech.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.connecttech.com
|
||||
S: Supported
|
||||
F: drivers/usb/serial/whiteheat*
|
||||
|
||||
USB SMSC75XX ETHERNET DRIVER
|
||||
M: Steve Glendinning <steve.glendinning@shawell.net>
|
||||
L: netdev@vger.kernel.org
|
||||
|
||||
2
Makefile
2
Makefile
@@ -1,7 +1,7 @@
|
||||
VERSION = 3
|
||||
PATCHLEVEL = 12
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc6
|
||||
EXTRAVERSION =
|
||||
NAME = One Giant Leap for Frogkind
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
#include <asm/pgalloc.h>
|
||||
#include <asm/mmu.h>
|
||||
|
||||
static int handle_vmalloc_fault(struct mm_struct *mm, unsigned long address)
|
||||
static int handle_vmalloc_fault(unsigned long address)
|
||||
{
|
||||
/*
|
||||
* Synchronize this task's top level page-table
|
||||
@@ -27,7 +27,7 @@ static int handle_vmalloc_fault(struct mm_struct *mm, unsigned long address)
|
||||
pud_t *pud, *pud_k;
|
||||
pmd_t *pmd, *pmd_k;
|
||||
|
||||
pgd = pgd_offset_fast(mm, address);
|
||||
pgd = pgd_offset_fast(current->active_mm, address);
|
||||
pgd_k = pgd_offset_k(address);
|
||||
|
||||
if (!pgd_present(*pgd_k))
|
||||
@@ -72,7 +72,7 @@ void do_page_fault(struct pt_regs *regs, unsigned long address)
|
||||
* nothing more.
|
||||
*/
|
||||
if (address >= VMALLOC_START && address <= VMALLOC_END) {
|
||||
ret = handle_vmalloc_fault(mm, address);
|
||||
ret = handle_vmalloc_fault(address);
|
||||
if (unlikely(ret))
|
||||
goto bad_area_nosemaphore;
|
||||
else
|
||||
|
||||
@@ -9,11 +9,6 @@
|
||||
model = "ARM Integrator/CP";
|
||||
compatible = "arm,integrator-cp";
|
||||
|
||||
aliases {
|
||||
arm,timer-primary = &timer2;
|
||||
arm,timer-secondary = &timer1;
|
||||
};
|
||||
|
||||
chosen {
|
||||
bootargs = "root=/dev/ram0 console=ttyAMA0,38400n8 earlyprintk";
|
||||
};
|
||||
@@ -24,14 +19,18 @@
|
||||
};
|
||||
|
||||
timer0: timer@13000000 {
|
||||
/* TIMER0 runs @ 25MHz */
|
||||
compatible = "arm,integrator-cp-timer";
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
timer1: timer@13000100 {
|
||||
/* TIMER1 runs @ 1MHz */
|
||||
compatible = "arm,integrator-cp-timer";
|
||||
};
|
||||
|
||||
timer2: timer@13000200 {
|
||||
/* TIMER2 runs @ 1MHz */
|
||||
compatible = "arm,integrator-cp-timer";
|
||||
};
|
||||
|
||||
|
||||
@@ -971,11 +971,11 @@ static const struct mips_perf_event mipsxx74Kcore_cache_map
|
||||
[C(LL)] = {
|
||||
[C(OP_READ)] = {
|
||||
[C(RESULT_ACCESS)] = { 0x1c, CNTR_ODD, P },
|
||||
[C(RESULT_MISS)] = { 0x1d, CNTR_EVEN | CNTR_ODD, P },
|
||||
[C(RESULT_MISS)] = { 0x1d, CNTR_EVEN, P },
|
||||
},
|
||||
[C(OP_WRITE)] = {
|
||||
[C(RESULT_ACCESS)] = { 0x1c, CNTR_ODD, P },
|
||||
[C(RESULT_MISS)] = { 0x1d, CNTR_EVEN | CNTR_ODD, P },
|
||||
[C(RESULT_MISS)] = { 0x1d, CNTR_EVEN, P },
|
||||
},
|
||||
},
|
||||
[C(ITLB)] = {
|
||||
|
||||
@@ -473,7 +473,7 @@ static void __init fill_ipi_map(void)
|
||||
{
|
||||
int cpu;
|
||||
|
||||
for (cpu = 0; cpu < NR_CPUS; cpu++) {
|
||||
for (cpu = 0; cpu < nr_cpu_ids; cpu++) {
|
||||
fill_ipi_map1(gic_resched_int_base, cpu, GIC_CPU_INT1);
|
||||
fill_ipi_map1(gic_call_int_base, cpu, GIC_CPU_INT2);
|
||||
}
|
||||
@@ -574,8 +574,9 @@ void __init arch_init_irq(void)
|
||||
/* FIXME */
|
||||
int i;
|
||||
#if defined(CONFIG_MIPS_MT_SMP)
|
||||
gic_call_int_base = GIC_NUM_INTRS - NR_CPUS;
|
||||
gic_resched_int_base = gic_call_int_base - NR_CPUS;
|
||||
gic_call_int_base = GIC_NUM_INTRS -
|
||||
(NR_CPUS - nr_cpu_ids) * 2 - nr_cpu_ids;
|
||||
gic_resched_int_base = gic_call_int_base - nr_cpu_ids;
|
||||
fill_ipi_map();
|
||||
#endif
|
||||
gic_init(GIC_BASE_ADDR, GIC_ADDRSPACE_SZ, gic_intr_map,
|
||||
@@ -599,7 +600,7 @@ void __init arch_init_irq(void)
|
||||
printk("CPU%d: status register now %08x\n", smp_processor_id(), read_c0_status());
|
||||
write_c0_status(0x1100dc00);
|
||||
printk("CPU%d: status register frc %08x\n", smp_processor_id(), read_c0_status());
|
||||
for (i = 0; i < NR_CPUS; i++) {
|
||||
for (i = 0; i < nr_cpu_ids; i++) {
|
||||
arch_init_ipiirq(MIPS_GIC_IRQ_BASE +
|
||||
GIC_RESCHED_INT(i), &irq_resched);
|
||||
arch_init_ipiirq(MIPS_GIC_IRQ_BASE +
|
||||
|
||||
@@ -126,7 +126,7 @@ static int rt_timer_probe(struct platform_device *pdev)
|
||||
return -ENOENT;
|
||||
}
|
||||
|
||||
rt->membase = devm_request_and_ioremap(&pdev->dev, res);
|
||||
rt->membase = devm_ioremap_resource(&pdev->dev, res);
|
||||
if (IS_ERR(rt->membase))
|
||||
return PTR_ERR(rt->membase);
|
||||
|
||||
|
||||
@@ -195,6 +195,8 @@ common_stext:
|
||||
ldw MEM_PDC_HI(%r0),%r6
|
||||
depd %r6, 31, 32, %r3 /* move to upper word */
|
||||
|
||||
mfctl %cr30,%r6 /* PCX-W2 firmware bug */
|
||||
|
||||
ldo PDC_PSW(%r0),%arg0 /* 21 */
|
||||
ldo PDC_PSW_SET_DEFAULTS(%r0),%arg1 /* 2 */
|
||||
ldo PDC_PSW_WIDE_BIT(%r0),%arg2 /* 2 */
|
||||
@@ -203,6 +205,8 @@ common_stext:
|
||||
copy %r0,%arg3
|
||||
|
||||
stext_pdc_ret:
|
||||
mtctl %r6,%cr30 /* restore task thread info */
|
||||
|
||||
/* restore rfi target address*/
|
||||
ldd TI_TASK-THREAD_SZ_ALGN(%sp), %r10
|
||||
tophys_r1 %r10
|
||||
|
||||
@@ -40,9 +40,11 @@ static ssize_t exitcode_proc_write(struct file *file,
|
||||
const char __user *buffer, size_t count, loff_t *pos)
|
||||
{
|
||||
char *end, buf[sizeof("nnnnn\0")];
|
||||
size_t size;
|
||||
int tmp;
|
||||
|
||||
if (copy_from_user(buf, buffer, count))
|
||||
size = min(count, sizeof(buf));
|
||||
if (copy_from_user(buf, buffer, size))
|
||||
return -EFAULT;
|
||||
|
||||
tmp = simple_strtol(buf, &end, 0);
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user