Linus Torvalds [Thu, 6 Oct 2011 23:15:10 +0000 (16:15 -0700)]
Merge git://github.com/davem330/net
* git://github.com/davem330/net:
net: fix typos in Documentation/networking/scaling.txt
bridge: leave carrier on for empty bridge
netfilter: Use proper rwlock init function
tcp: properly update lost_cnt_hint during shifting
tcp: properly handle md5sig_pool references
macvlan/macvtap: Fix unicast between macvtap interfaces in bridge mode
Paul Menzel [Wed, 31 Aug 2011 15:07:10 +0000 (17:07 +0200)]
x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE
In summary, this DMI quirk uses the _CRS info by default for the ASUS
M2V-MX SE by turning on `pci=use_crs` and is similar to the quirk
added by commit 2491762cfb47 ("x86/PCI: use host bridge _CRS info on
ASRock ALiveSATA2-GLAN") whose commit message should be read for further
information.
Since commit 3e3da00c01d0 ("x86/pci: AMD one chain system to use pci
read out res") Linux gives the following oops:
Trusting the ACPI _CRS information (`pci=use_crs`) fixes this problem.
$ dmesg | grep -i crs # with the quirk
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
The match has to be against the DMI board entries though since the vendor entries are not populated.
DMI: System manufacturer System Product Name/M2V-MX SE, BIOS 0304 10/30/2007
This quirk should be removed when `pci=use_crs` is enabled for machines
from 2006 or earlier or some other solution is implemented.
Using coreboot [1] with this board the problem does not exist but this
quirk also does not affect it either. To be safe though the check is
tightened to only take effect when the BIOS from American Megatrends is
used.
15:13 < ruik> but coreboot does not need that
15:13 < ruik> because i have there only one root bus
15:13 < ruik> the audio is behind a bridge
$ sudo dmidecode
BIOS Information
Vendor: American Megatrends Inc.
Version: 0304
Release Date: 10/30/2007
virtio-net: Verify page list size before fitting into skb
This patch verifies that the length of a buffer stored in a linked list
of pages is small enough to fit into a skb.
If the size is larger than a max size of a skb, it means that we shouldn't
go ahead building skbs anyway since we won't be able to send the buffer as
the user requested.
Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: virtualization@lists.linux-foundation.org Cc: netdev@vger.kernel.org Cc: kvm@vger.kernel.org Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This is based on an earlier patch by Nick Carter with comments
by David Lamparter but with some refinements. Thanks for their patience
this is a confusing area with overlap of standards, user requirements,
and compatibility with earlier releases.
It adds a new sysfs attribute
/sys/class/net/brX/bridge/group_fwd_mask
that controls forwarding of frames with address of: 01-80-C2-00-00-0X
The default setting has no forwarding to retain compatibility.
One change from earlier releases is that forwarding of group
addresses is not dependent on STP being enabled or disabled. This
choice was made based on interpretation of tie 802.1 standards.
I expect complaints will arise because of this, but better to follow
the standard than continue acting incorrectly by default.
The filtering mask is writeable, but only values that don't forward
known control frames are allowed. It intentionally blocks attempts
to filter control protocols. For example: writing a 8 allows
forwarding 802.1X PAE addresses which is the most common request.
Reported-by: David Lamparter <equinox@diac24.net> Original-patch-by: Nick Carter <ncarter100@gmail.com> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Tested-by: Benjamin Poirier <benjamin.poirier@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This resolves a regression seen by some users of bridging.
Some users use the bridge like a dummy device.
They expect to be able to put an IPv6 address on the device
with no ports attached. Although there are better ways of doing
this, there is no reason to not allow it.
Note: the bridge still will reflect the state of ports in the
bridge if there are any added.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Axel Lin [Wed, 5 Oct 2011 23:29:56 +0000 (07:29 +0800)]
ASoC: Return early with -EINVAL if invalid dai format is detected
Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Timur Tabi <timur@freescale.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Wolfram Sang [Thu, 6 Oct 2011 18:53:36 +0000 (20:53 +0200)]
ASoC: tlv320aic32x4 fix initialization of micpga routing
Checking the pdata-flags used 'or', so the check is always true. Use 'and' to
correctly mask the flags.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Barry Song [Thu, 6 Oct 2011 18:34:46 +0000 (20:34 +0200)]
PM / Hibernate: Add resumewait param to support MMC-like devices as resume file
Some devices like MMC are async detected very slow. For example,
drivers/mmc/host/sdhci.c launches a 200ms delayed work to detect
MMC partitions then add disk.
We have wait_for_device_probe() and scsi_complete_async_scans()
before calling swsusp_check(), but it is not enough to wait for MMC.
This patch adds resumewait kernel param just like rootwait so
that we have enough time to wait until MMC is ready. The difference is
that we wait for resume partition whereas rootwait waits for rootfs
partition (which may be on a different device).
This patch will make hibernation support many embedded products
without SCSI devices, but with devices like MMC.
[rjw: Modified the changelog slightly.]
Signed-off-by: Barry Song <Baohua.Song@csr.com> Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Paul Bolle [Thu, 6 Oct 2011 11:11:52 +0000 (13:11 +0200)]
bcmring: drop commented out line in Kconfig
There's no file named "drivers/char/bcmring/Kconfig". It seems it has
never been part of the mainline kernel tree. So there's nothing to be
sourced here.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Mark Brown [Thu, 6 Oct 2011 12:30:55 +0000 (13:30 +0100)]
ASoC: Ensure DAPM widgets are set up before we sync jacks
We synchronise jack state on startup - when we do that make sure that we
have set up all the DAPM widgets first in case we end up touching any of
the partially set up widgets when syncing the jack pins.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Jin Park [Tue, 4 Oct 2011 10:35:07 +0000 (12:35 +0200)]
mfd: Fix aat2870 build failure for x86_64
Without this fix, we get:
error: call to ‘copy_from_user_overflow’ declared with attribute error:
copy_from_user() buffer size is not provably correct
make[3]: *** [drivers/mfd/aat2870-core.o] Error 1
Module IRQs may still be disabled by DPM at the time the TWL6030
ISR runs, causing handle_simple_irq() to silently do nothing.
This may result in missing TWL RTC alarm wakeups, for example,
since the RTC child module ISR is not called to ack the IRQ.
Disable the TWL6030 IRQ during suspend, enable it at DPM resume
time, at which time the child module IRQs will be re-enabled.
Todd Poynor [Tue, 4 Oct 2011 09:52:29 +0000 (11:52 +0200)]
mfd: Fix twl6030 lockdep recursion warning on setting wake IRQs
LOCKDEP explicitly sets all irq_desc locks as a single lock-class,
causing "possible recursive locking detected" when the TWL RTC
driver calls through enable_irq_wake to twl6030_irq_set_wake,
which recursively calls irq_set_irq_wake. Although the
irq_desc and lock are different, LOCKDEP treats these as
equivalent, presumably due to problems that can be incurred
when locking more than one irq_desc, so best to avoid this.
Suspend/resume actions implemented as PM notifiers to avoid
touch the TWL core for this.