aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-01-25hv_netvsc: Fix book keeping of skb during batching processHaiyang Zhang2-11/+23
Since eliminating send_completion_tid from struct hv_netvsc_packet, we haven't add proper book keeping for the skb of the batched packet. This patch fixes this issue and allows the previous skb is properly freed. Otherwise, a panic may happen. Thanks to Simon Xiao <[email protected]> for bisecting and analysis. Signed-off-by: Haiyang Zhang <[email protected]> Reviewed-by: K. Y. Srinivasan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25hv_netvsc: use skb_get_hash() instead of a homegrown implementationVitaly Kuznetsov1-64/+3
Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add VLAN ID to flow_keys")) introduced a performance regression in netvsc driver. Is problem is, however, not the above mentioned commit but the fact that netvsc_set_hash() function did some assumptions on the struct flow_keys data layout and this is wrong. Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change will also imply switching to Jenkins hash from the currently used Toeplitz but it seems there is no good excuse for Toeplitz to stay. Signed-off-by: Vitaly Kuznetsov <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25sit: set rtnl_link_ops before calling register_netdeviceThadeu Lima de Souza Cascardo1-2/+2
When creating a SIT tunnel with ip tunnel, rtnl_link_ops is not set before ipip6_tunnel_create is called. When register_netdevice is called, there is no linkinfo attribute in the NEWLINK message because of that. Setting rtnl_link_ops before calling register_netdevice fixes that. Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25net: fec: use CONFIG_ARM instead of CONFIG_ARCH_MXC/SOC_IMX28Johannes Berg2-7/+4
As Arnd Bergmann points out, using CONFIG_ARCH_MXC and/or SOC_IMX28 is wrong if some other ARM platform uses this device - the operation of the driver would depend on an unrelated ARM platform that might or might not be set for multi-platform kernels. Prior to my previous patch, any other platforms using it would have been broken already due to having the cbd_datlen/cbd_sc fields in the wrong order, but byte ordering correctly, so no such platforms can exist and work today. In any case, it seems likely that only Freescale SoCs use this part, and those are little-endian on ARM, so CONFIG_ARM is safe for them. Signed-off-by: Johannes Berg <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25defxx: fix build warningSudip Mukherjee1-4/+4
We are getting many build warnings about: 'bar_start' may be used uninitialized and 'bar_len' may be used uninitialized They are not actually uninitialized as dfx_get_bars() will initialize them properly. But still lets have them initialized just to satisfy the compiler (gcc 4.8.2). Signed-off-by: Sudip Mukherjee <[email protected]> Acked-by: Maciej W. Rozycki <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25net: macb: fix build warningSudip Mukherjee1-1/+1
We are getting build warning about: macb.c:2889:13: warning: 'tx_clk' may be used uninitialized in this function macb.c:2888:11: warning: 'hclk' may be used uninitialized in this function In reality they are not used uninitialized as clk_init() will initialize them, this patch will just silence the warning. Signed-off-by: Sudip Mukherjee <[email protected]> Acked-by: Nicolas Ferre <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25net: fec: make driver endian-safeJohannes Berg3-72/+101
The driver treats the device descriptors as CPU-endian, which appears to be correct with the default endianness on both ARM (typically LE) and PowerPC (typically BE) SoCs, indicating that the hardware block is generated differently. Add endianness annotations and byteswaps as necessary. It's not clear that the ifdef there really is correct and shouldn't just be #ifdef CONFIG_ARM, but I also can't test on anything but the i.MX6 HummingBoard where this gets it working with a BE kernel. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25net: dsa: fix mv88e6xxx switchesRussell King1-1/+1
Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops"), the Marvell 88E6xxx switch has been unable to pass traffic between ports - any received traffic is discarded by the switch. Taking a port out of bridge mode and configuring a vlan on it also the port to start passing traffic. With the debugfs files re-instated to allow debug of this issue by comparing the register settings between the working and non-working case, the reason becomes clear: GLOBAL GLOBAL2 SERDES 0 1 2 3 4 5 6 - 7: 1111 707f 2001 2 2 2 2 2 0 2 + 7: 1111 707f 2001 1 1 1 1 1 0 1 Register 7 for the ports is the default vlan tag register, and in the non-working setup, it has been set to 2, despite vlan 2 not being configured. This causes the switch to drop all packets coming in to these ports. The working setup has the default vlan tag register set to 1, which is the default vlan when none is configured. Inspection of the code reveals why. The code prior to this commit was: - for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) { ... - if (!err && vlan->flags & BRIDGE_VLAN_INFO_PVID) - err = ds->drv->port_pvid_set(ds, p->port, vid); but the new code is: + for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) { ... + } ... + if (pvid) + err = _mv88e6xxx_port_pvid_set(ds, port, vid); This causes the new code to always set the default vlan to one higher than the old code. Fix this. Fixes: 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops") Cc: <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-2582xx: FCC: Fixing a bug causing to FCC port lock-up (second try)Martin Roth1-1/+1
This is an additional patch to the one already submitted recently. The previous patch was not complete, and the FCC port lock-up scenario has been reproduced in lab. I had an opportunity to check the current patch in lab and the FCC port lock no longer freezes, while the previous patch still locks-up the FCC port. The current patch fixes a pointer arithmetic bug (second bug in the same line), which leads FCC port lock-up during underrun/collision handling. Within the tx_startup() function in mac-fcc.c, the address of last BD is not calculated correctly. As a result of wrong calculation of the last BD address, the next transmitted BD may be set to an area out of the transmit BD ring. This actually causes to port lock-up and it is not recoverable. Signed-off-by: Martin Roth <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25Merge branch 'enable-devices' into omap-for-v4.5/fixesTony Lindgren9887-177045/+513375
2016-01-25ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIVThomas Egerer2-0/+2
The ESP algorithms using CBC mode require echainiv. Hence INET*_ESP have to select CRYPTO_ECHAINIV in order to work properly. This solves the issues caused by a misconfiguration as described in [1]. The original approach, patching crypto/Kconfig was turned down by Herbert Xu [2]. [1] https://lists.strongswan.org/pipermail/users/2015-December/009074.html [2] http://marc.info/?l=linux-crypto-vger&m=145224655809562&w=2 Signed-off-by: Thomas Egerer <[email protected]> Acked-by: Herbert Xu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-01-25ARM: OMAP: Add PWM dmtimer platform data quirksNeil Armstrong1-0/+23
In order to set the currently platform dependent dmtimer functions pointers as platform data for the pwm-omap-dmtimer platform driver, add it to plat-omap auxdata_lookup table. Suggested-by: Tony Lindgren <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2016-01-25tracing/dma-buf/fence: Fix timeline str value on fence_annotate_wait_onGustavo Padovan1-1/+1
timeline was wrongly assigned with ->get_driver_name(). Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Gustavo Padovan <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2016-01-25drm/radeon: Ensure radeon bo is unreserved in radeon_gem_va_ioctlMatthew Dawson1-0/+1
Found with lockdep while testing gpu reset. Reviewed-by: Christian König <[email protected]> Signed-off-by: Matthew Dawson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-01-25btrfs: add free space tree to the cow-only listDavid Sterba1-1/+2
Signed-off-by: David Sterba <[email protected]>
2016-01-25btrfs: add free space tree to lockdep classesDavid Sterba1-0/+1
Signed-off-by: David Sterba <[email protected]>
2016-01-25ARM: dts: orion5x: gpio pin fixes for linkstation lswtglRoger Shimizu1-4/+4
Here're a few gpio pin related fixes: - remove pinctrl-0 definition from pinctrl, since those pins are used in other places such as gpio-fan and regulators. - keep initial state of power led - fix for alarm pin of gpio-fan. Fixes: dc57844a736f ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl") Signed-off-by: Roger Shimizu <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2016-01-25[media] exynos4-is: make VIDEO_SAMSUNG_EXYNOS4_IS tristateArnd Bergmann1-1/+1
With CONFIG_V4L2=m and VIDEO_SAMSUNG_EXYNOS4_IS=y, we can select the individual drivers as built-in code when that should not be possible: drivers/built-in.o: In function `s5pcsis_set_fmt': policy.c:(.text+0x13afdc): undefined reference to `v4l_bound_align_image' drivers/built-in.o: In function `s5pcsis_probe': policy.c:(.text+0x13b440): undefined reference to `v4l2_of_parse_endpoint' policy.c:(.text+0x13b72c): undefined reference to `v4l2_subdev_init' Changing VIDEO_SAMSUNG_EXYNOS4_IS to tristate means that the dependency from CONFIG_V4L2 propates to the individual Kconfig symbols and they can only be built as loadable modules if V4L2 or any other of the dependencies itself is a module. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-01-25of: drop symbols declared by _OF_DECLARE() from modulesMasahiro Yamada1-1/+1
The users of this macro (OF_EARLYCON_DECLARE, CLK_OF_DECLARE, IRQCHIP_DECLARE, etc.) are only parsed in the early boot stage. Such symbols contained in modules are never used. This commit fixes the link error introduced by commit b8d20e06eaad ("serial: 8250_uniphier: add earlycon support"); the combination of CONFIG_SERIAL_8250_UNIPHIER=m and CONFIG_SERIAL_8250_CONSOLE=y fails to link: ERROR: "early_serial8250_setup" [drivers/tty/serial/8250/8250_uniphier.ko] undefined! Fixes: b8d20e06eaad ("serial: 8250_uniphier: add earlycon support") Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2016-01-25MAINTAINERS: Add missing platform maintainers for dts filesRob Herring1-1/+18
Platform dts files need to be reviewed primarily by the platform maintainers as dts files typically go in thru their trees. Add the missing paths where there are existing maintainers listed. Signed-off-by: Rob Herring <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Acked-by: Santosh Shilimkar<[email protected]> Reviewed-by: Viresh Kumar <[email protected]> Acked-by: Florian Fainelli <[email protected]> Acked-by: Robert Jarzmik <[email protected]> Acked-by: Andy Gross <[email protected]> Acked-by: Sudeep Holla <[email protected]> Acked-by: Sebastian Hesselbarth <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Dinh Nguyen <[email protected]>
2016-01-25ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wvl/vlRoger Shimizu1-6/+6
The GPIOs controlling the LEDs, listed below, are active high, not low: - gpio-leds: "lswvl:red:alarm" pin - gpio-leds: "lswvl:red:func" pin - gpio-leds: "lswvl:amber:info" pin - gpio-leds: "lswvl:blue:func" pin - gpio-leds: "lswvl:red:hdderr{0,1}" pin Fixes: c43379e150aa ("ARM: dts: add buffalo linkstation ls-wvl/vl") Signed-off-by: Roger Shimizu <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2016-01-25ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wxl/wsxlRoger Shimizu1-5/+5
The GPIOs controlling the LEDs, listed below, are active high, not low: - gpio-leds: "lswxl:blue:power" pin - gpio-leds: "lswxl:red:func" pin - gpio-leds: "lswxl:red:hdderr{0,1}" pin Fixes: e54e4b1b622e ("ARM: dts: add buffalo linkstation ls-wxl/wsxl") Signed-off-by: Roger Shimizu <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2016-01-25ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wvl/vlRoger Shimizu1-12/+13
For kirkwood, gpio pins starts from 32 are in the 2nd bank, so it should be converted to "gpio1 <pin minus 32>" in dts file. e.g. gpio 40 should be "gpio1 8" The pin/bank issue was found when discussing Debian Bug #810894 [https://bugs.debian.org/810894#47] Fixes: c43379e150aa ("ARM: dts: add buffalo linkstation ls-wvl/vl") Reported-by: Arnaud Patard (Rtp) <[email protected]> Signed-off-by: Roger Shimizu <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2016-01-25ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wxl/wsxlRoger Shimizu1-14/+15
For kirkwood, gpio pins starts from 32 are in the 2nd bank, so it should be converted to "gpio1 <pin minus 32>" in dts file. e.g. gpio 40 should be "gpio1 8" Besides, a few other pin fixes for ls-wxl/wsxl, to match with mpp pin definition: - gpio-leds: "lswxl:blue:power" pin - gpio-leds: "lswxl:red:func" pin - gpio-leds: "lswxl:red:hdderr0" pin - gpio-leds: "lswxl:red:hdderr1" pin - gpio-fan: low/high/alarm pin The pin/bank issue was found when discussing Debian Bug #810894 [https://bugs.debian.org/810894#47] Fixes: e54e4b1b622e ("ARM: dts: add buffalo linkstation ls-wxl/wsxl") Reported-by: Arnaud Patard (Rtp) <[email protected]> Signed-off-by: Roger Shimizu <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2016-01-25crypto: chacha20-ssse3 - Align stack pointer to 64 bytesEli Cooper1-2/+4
This aligns the stack pointer in chacha20_4block_xor_ssse3 to 64 bytes. Fixes general protection faults and potential kernel panics. Cc: [email protected] Signed-off-by: Eli Cooper <[email protected]> Acked-by: Martin Willi <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2016-01-25PKCS#7: Don't require SpcSpOpusInfo in Authenticode pkcs7 signaturesPeter Jones1-3/+1
Dave Young reported: > Hi, > > I saw the warning "Missing required AuthAttr" when testing kexec, > known issue? Idea about how to fix it? > > The kernel is latest linus tree plus sevral patches from Toshi to > cleanup io resource structure. > > in function pkcs7_sig_note_set_of_authattrs(): > if (!test_bit(sinfo_has_content_type, &sinfo->aa_set) || > !test_bit(sinfo_has_message_digest, &sinfo->aa_set) || > (ctx->msg->data_type == OID_msIndirectData && > !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set))) { > pr_warn("Missing required AuthAttr\n"); > return -EBADMSG; > } > > The third condition below is true: > (ctx->msg->data_type == OID_msIndirectData && > !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set)) > > I signed the kernel with redhat test key like below: > pesign -c 'Red Hat Test Certificate' -i arch/x86/boot/bzImage -o /boot/vmlinuz-4.4.0-rc8+ -s --force And right he is! The Authenticode specification is a paragon amongst technical documents, and has this pearl of wisdom to offer: --------------------------------- Authenticode-Specific SignerInfo UnauthenticatedAttributes Structures The following Authenticode-specific data structures are present in SignerInfo authenticated attributes. SpcSpOpusInfo SpcSpOpusInfo is identified by SPC_SP_OPUS_INFO_OBJID (1.3.6.1.4.1.311.2.1.12) and is defined as follows: SpcSpOpusInfo ::= SEQUENCE { programName [0] EXPLICIT SpcString OPTIONAL, moreInfo [1] EXPLICIT SpcLink OPTIONAL, } --#public-- SpcSpOpusInfo has two fields: programName This field contains the program description: If publisher chooses not to specify a description, the SpcString structure contains a zero-length program name. If the publisher chooses to specify a description, the SpcString structure contains a Unicode string. moreInfo This field is set to an SPCLink structure that contains a URL for a Web site with more information about the signer. The URL is an ASCII string. --------------------------------- Which is to say that this is an optional *unauthenticated* field which may be present in the Authenticated Attribute list. This is not how pkcs7 is supposed to work, so when David implemented this, he didn't appreciate the subtlety the original spec author was working with, and missed the part of the sublime prose that says this Authenticated Attribute is an Unauthenticated Attribute. As a result, the code in question simply takes as given that the Authenticated Attributes should be authenticated. But this one should not, individually. Because it says it's not authenticated. It still has to hash right so the TBS digest is correct. So it is both authenticated and unauthenticated, all at once. Truly, a wonder of technical accomplishment. Additionally, pesign's implementation has always attempted to be compatible with the signatures emitted from contemporary versions of Microsoft's signtool.exe. During the initial implementation, Microsoft signatures always produced the same values for SpcSpOpusInfo - {U"Microsoft Windows", "http://www.microsoft.com"} - without regard to who the signer was. Sometime between Windows 8 and Windows 8.1 they stopped including the field in their signatures altogether, and as such pesign stopped producing them in commits c0c4da6 and d79cb0c, sometime around June of 2012. The theory here is that anything that breaks with pesign signatures would also be breaking with signtool.exe sigs as well, and that'll be a more noticed problem for firmwares parsing it, so it'll get fixed. The fact that we've done exactly this bug in Linux code is first class, grade A irony. So anyway, we should not be checking this field for presence or any particular value: if the field exists, it should be at the right place, but aside from that, as long as the hash matches the field is good. Signed-off-by: Peter Jones <[email protected]> Tested-by: Dave Young <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2016-01-25crypto: caam - make write transactions bufferable on PPC platformsHoria Geant?1-2/+2
Previous change (see "Fixes" tag) to the MCFGR register clears AWCACHE[0] ("bufferable" AXI3 attribute) (which is "1" at POR). This makes all writes non-bufferable, causing a ~ 5% performance drop for PPC-based platforms. Rework previous change such that MCFGR[AWCACHE]=4'b0011 (bufferable + cacheable) for all platforms. Note: For ARM-based platforms, AWCACHE[0] is ignored by the interconnect IP. Cc: <[email protected]> # 4.3+ Fixes: f10967495144 ("crypto: caam - fix snooping for write transactions") Signed-off-by: Horia Geant? <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2016-01-25ath9k_hw: ignore eeprom magic mismatch on flash based devicesFelix Fietkau1-6/+6
Many AR913x based devices (maybe others too) do not have a valid EEPROM magic in their calibration data partition. Fixes: 6fa658fd5ab2 ("ath9k: Simplify and fix eeprom endianness swapping") Signed-off-by: Felix Fietkau <[email protected]> Acked-by: Martin Blumenstingl <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2016-01-25drm/etnaviv: fix failure path if model is zeroRussell King1-2/+2
Fix the failure path to call pm_runtime_mark_last_busy() when failing due to the model field being zero. Acked-by: Christian Gmeiner <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2016-01-25drm/etnaviv: hold object lock while getting pages for coredumpLucas Stach1-0/+2
While all objects that get coredumped have an active IOVA and thus pages already populated, etnaviv_gem_get_pages() still requires the object lock to be held. Signed-off-by: Lucas Stach <[email protected]>
2016-01-25drm/etnaviv: remove owner assignment from platform_driverFabio Estevam1-1/+0
This platform_driver does not need to set an owner as it will be populated by the driver core. Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2016-01-25rtlwifi: rtl8821ae: Fix 5G failure when EEPROM is incorrectly encodedLarry Finger1-1/+1
Recently, it has been reported that D-Link DWA-582 cards, which use an RTL8812AE chip are not able to scan for 5G networks. The problems started with kernel 4.2, which is the first version that had commit d10101a60372 ("rtlwifi: rtl8821ae: Fix problem with regulatory information"). With this patch, the driver went from setting a default channel plan to using the value derived from EEPROM. Bug reports at https://bugzilla.kernel.org/show_bug.cgi?id=111031 and https://bugzilla.redhat.com/show_bug.cgi?id=1279653 are examples of this problem. The problem was solved once I learned that the internal country code was resulting in a regulatory set with only 2.4 GHz channels. With the RTL8821AE chips available to me, the country code was such that both 2.4 and 5 GHz channels are allowed. The fix is to allow both bands even when the EEPROM is incorrectly encoded. Fixes: d10101a60372 ("rtlwifi: rtl8821ae: Fix problem with regulatory information") Signed-off-by: Larry Finger <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Stable <[email protected]> [v4.2+] Signed-off-by: Kalle Valo <[email protected]>
2016-01-25rt2x00: fix monitor mode regressionEli Cooper9-11/+23
Since commit df1404650ccb ("mac80211: remove support for IFF_PROMISC") monitor mode for rt2x00 has been made effectively useless because the hardware filter is configured to drop packets whose intended recipient is not the device, regardless of the presence of monitor mode interfaces. This patch fixes this regression by adding explicit monitor mode support, and by configuring the hardware filter accordingly. Signed-off-by: Eli Cooper <[email protected]> Acked-by: Stanislaw Gruszka <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2016-01-25USB: option: fix Cinterion AHxx enumerationJohn Ernberg1-1/+1
In certain kernel configurations where the cdc_ether and option drivers are compiled as modules there can occur a race condition in enumeration. This causes the option driver to enumerate the ethernet(wwan) interface as usb-serial interfaces. usb-devices output for the modem: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e2d ProdID=0055 Rev=00.00 S: Manufacturer=Cinterion S: Product=AHx C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=10mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether Signed-off-by: John Ernberg <[email protected]> Fixes: 1941138e1c02 ("USB: added support for Cinterion's products...") Cc: stable <[email protected]> # v3.9: 8ff10bdb14a52 Signed-off-by: Johan Hovold <[email protected]>
2016-01-25[media] media: Kconfig: add dependency of HAS_DMASudip Mukherjee1-0/+1
The build of m32r allmodconfig fails with the error: drivers/media/v4l2-core/videobuf2-dma-contig.c:484:2: error: implicit declaration of function 'dma_get_cache_alignment' The build of videobuf2-dma-contig.c depends on HAS_DMA and it is correctly mentioned in the Kconfig but the symbol VIDEO_STI_BDISP also selects VIDEOBUF2_DMA_CONTIG, so it is trying to compile videobuf2-dma-contig.c even though HAS_DMA is not defined. Signed-off-by: Sudip Mukherjee <[email protected]> Acked-by: Sakari Ailus <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-01-25[media] exynos4-is: Wait for 100us before opening sensorJacek Anaszewski1-0/+6
Some user space use cases result in kernel hangup on the HIC_OPEN_SENSOR command write. In case when a minimalistic application is used for setting up the streaming, the hangups occur only occasionally. In case of GStreamer use cases it is always the case. Signed-off-by: Jacek Anaszewski <[email protected]> Acked-by: Kyungmin Park <[email protected]> Cc: Sylwester Nawrocki <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-01-25[media] exynos4-is: Open shouldn't fail when sensor entity is not linkedJacek Anaszewski1-19/+76
In order to allow for automatic media device entities linking from the level of libv4l plugin the open system call shouldn't fail, as the libv4l plugins can begin their job not until it succeeds. This patch allows for leaving the pipeline not linked on open and postpones verifying it to the moment when streamon callback is called. Signed-off-by: Jacek Anaszewski <[email protected]> Acked-by: Kyungmin Park <[email protected]> Cc: Sylwester Nawrocki <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-01-25[media] s5k6a3: Fix VIDIOC_SUBDEV_G_FMT ioctl for TRY formatJacek Anaszewski1-2/+1
VIDIOC_SUBDEV_G_FMT ioctl should return TRY format previously set with VIDIOC_SUBDEV_S_FMT. Currently it is not the case as only ACTIVE formats are saved in the driver. Since the driver doesn't alter hardware state in the set_fmt op anyway, the op can save the format in both TRY and ACTIVE case. Signed-off-by: Jacek Anaszewski <[email protected]> Acked-by: Kyungmin Park <[email protected]> Cc: Sylwester Nawrocki <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-01-25ARM: mvebu: ix4-300d: Add compatible property to "partitions" nodeGeert Uytterhoeven1-0/+1
As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible property to "partitions" node"), the "partitions" subnode of an SPI FLASH device node must have a compatible property. The partitions are no longer detected if it is not present. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Brian Norris <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2016-01-25ARM: mvebu: kirkwood: Add compatible property to "partitions" nodeGeert Uytterhoeven1-0/+1
As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible property to "partitions" node"), the "partitions" subnode of an SPI FLASH device node must have a compatible property. The partitions are no longer detected if it is not present. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2016-01-25arm64: Fix an enum typo in mm/dump.cMasanari Iida1-1/+1
This patch fixes a typo in mm/dump.c: "MODUELS_END_NR" should be "MODULES_END_NR". Signed-off-by: Masanari Iida <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25USB: mxu11x0: fix memory leak on usb_serial private dataMathieu OTHACEHE1-0/+20
On nominal execution, private data allocated on port_probe and attach are never freed. Add port_remove and release callbacks to free them respectively. Signed-off-by: Mathieu OTHACEHE <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2016-01-25[media] exynos4-is: fix a format string bugRasmus Villemoes1-2/+2
Ironically, 7d4020c3c400 ("[media] exynos4-is: fix some warnings when compiling on arm64") fixed some format string bugs but introduced a new one. buf_index is a simple int, so it should be printed with %d, not %pad (which is correctly used for dma_addr_t). Fixes: 7d4020c3c400 ("[media] exynos4-is: fix some warnings when compiling on arm64") Signed-off-by: Rasmus Villemoes <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-01-25[media] drivers/media: vsp1_video: fix compile errorAnders Roxell1-1/+1
This was found with the -RT patch enabled, but the fix should apply to non-RT also. Compilation error without this fix: ../drivers/media/platform/vsp1/vsp1_video.c: In function 'vsp1_pipeline_stopped': ../drivers/media/platform/vsp1/vsp1_video.c:524:2: error: expected expression before 'do' spin_unlock_irqrestore(&pipe->irqlock, flags); ^ Signed-off-by: Anders Roxell <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-01-25arm64: Honour !PTE_WRITE in set_pte_at() for kernel mappingsCatalin Marinas1-11/+10
Currently, set_pte_at() only checks the software PTE_WRITE bit for user mappings when it sets or clears the hardware PTE_RDONLY accordingly. The kernel ptes are written directly without any modification, relying solely on the protection bits in macros like PAGE_KERNEL. However, modifying kernel pte attributes via pte_wrprotect() would be ignored by set_pte_at(). Since pte_wrprotect() does not set PTE_RDONLY (it only clears PTE_WRITE), the new permission is not taken into account. This patch changes set_pte_at() to adjust the read-only permission for kernel ptes as well. As a side effect, existing PROT_* definitions used for kernel ioremap*() need to include PTE_DIRTY | PTE_WRITE. (additionally, white space fix for PTE_KERNEL_ROX) Acked-by: Andrey Ryabinin <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Reported-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25arm64: kernel: fix architected PMU registers unconditional accessLorenzo Pieralisi3-2/+19
The Performance Monitors extension is an optional feature of the AArch64 architecture, therefore, in order to access Performance Monitors registers safely, the kernel should detect the architected PMU unit presence through the ID_AA64DFR0_EL1 register PMUVer field before accessing them. This patch implements a guard by reading the ID_AA64DFR0_EL1 register PMUVer field to detect the architected PMU presence and prevent accessing PMU system registers if the Performance Monitors extension is not implemented in the core. Cc: Peter Maydell <[email protected]> Cc: Mark Rutland <[email protected]> Cc: <[email protected]> Fixes: 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0 initialization and restore") Signed-off-by: Lorenzo Pieralisi <[email protected]> Reported-by: Guenter Roeck <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25arm64: kasan: ensure that the KASAN zero page is mapped read-onlyArd Biesheuvel1-0/+9
When switching from the early KASAN shadow region, which maps the entire shadow space read-write, to the permanent KASAN shadow region, which uses a zero page to shadow regions that are not subject to instrumentation, the lowest level table kasan_zero_pte[] may be reused unmodified, which means that the mappings of the zero page that it contains will still be read-write. So update it explicitly to map the zero page read only when we activate the permanent mapping. Acked-by: Andrey Ryabinin <[email protected]> Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25arm64: hide __efistub_ aliases from kallsymsArd Biesheuvel1-15/+25
Commit e8f3010f7326 ("arm64/efi: isolate EFI stub from the kernel proper") isolated the EFI stub code from the kernel proper by prefixing all of its symbols with __efistub_, and selectively allowing access to core kernel symbols from the stub by emitting __efistub_ aliases for functions and variables that the stub can access legally. As an unintended side effect, these aliases are emitted into the kallsyms symbol table, which means they may turn up in backtraces, e.g., ... PC is at __efistub_memset+0x108/0x200 LR is at fixup_init+0x3c/0x48 ... [<ffffff8008328608>] __efistub_memset+0x108/0x200 [<ffffff8008094dcc>] free_initmem+0x2c/0x40 [<ffffff8008645198>] kernel_init+0x20/0xe0 [<ffffff8008085cd0>] ret_from_fork+0x10/0x40 The backtrace in question has nothing to do with the EFI stub, but simply returns one of the several aliases of memset() that have been recorded in the kallsyms table. This is undesirable, since it may suggest to people who are not aware of this that the issue they are seeing is somehow EFI related. So hide the __efistub_ aliases from kallsyms, by emitting them as absolute linker symbols explicitly. The distinction between those and section relative symbols is completely irrelevant to these definitions, and to the final link we are performing when these definitions are being taken into account (the distinction is only relevant to symbols defined inside a section definition when performing a partial link), and so the resulting values are identical to the original ones. Since absolute symbols are ignored by kallsyms, this will result in these values to be omitted from its symbol table. After this patch, the backtrace generated from the same address looks like this: ... PC is at __memset+0x108/0x200 LR is at fixup_init+0x3c/0x48 ... [<ffffff8008328608>] __memset+0x108/0x200 [<ffffff8008094dcc>] free_initmem+0x2c/0x40 [<ffffff8008645198>] kernel_init+0x20/0xe0 [<ffffff8008085cd0>] ret_from_fork+0x10/0x40 Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-01-25[media] atmel-isi: fix debug message which only show the first formatJosh Wu1-1/+1
Correct the debug output message to show correct format. Signed-off-by: Josh Wu <[email protected]> Signed-off-by: Guennadi Liakhovetski <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-01-25[media] soc_camera: cleanup control device on async_unbindWolfram Sang1-0/+2
I got the following WARN on a simple unbind/bind cycle: root@Lager:/sys/bus/i2c/drivers/adv7180# echo 6-0020 > unbind root@Lager:/sys/bus/i2c/drivers/adv7180# echo 6-0020 > bind [ 31.097652] adv7180 6-0020: chip found @ 0x20 (e6520000.i2c) [ 31.123744] ------------[ cut here ]------------ [ 31.128413] WARNING: CPU: 3 PID: 873 at drivers/media/platform/soc_camera/soc_camera.c:1463 soc_camera_async_bound+0x40/0xa0() [ 31.139896] CPU: 3 PID: 873 Comm: sh Not tainted 4.4.0-rc3-00062-ge8ae2c0b6bca2a #172 [ 31.147815] Hardware name: Generic R8A7790 (Flattened Device Tree) [ 31.154056] Backtrace: [ 31.156575] [<c0014bc0>] (dump_backtrace) from [<c0014d80>] (show_stack+0x20/0x24) [ 31.164233] r6:c05c5b33 r5:00000009 r4:00000000 r3:00404100 [ 31.170017] [<c0014d60>] (show_stack) from [<c01e2344>] (dump_stack+0x78/0x94) [ 31.177344] [<c01e22cc>] (dump_stack) from [<c0029e7c>] (warn_slowpath_common+0x98/0xc4) [ 31.185518] r4:00000000 r3:00000000 [ 31.189172] [<c0029de4>] (warn_slowpath_common) from [<c0029fa0>] (warn_slowpath_null+0x2c/0x34) [ 31.198043] r8:eb38df28 r7:eb38c5d0 r6:eb38de80 r5:e6962810 r4:eb38de80 [ 31.204898] [<c0029f74>] (warn_slowpath_null) from [<c0356348>] (soc_camera_async_bound+0x40/0xa0) [ 31.213955] [<c0356308>] (soc_camera_async_bound) from [<c03499a0>] (v4l2_async_test_notify+0x9c/0x108) [ 31.223430] r5:eb38c5ec r4:eb38de80 [ 31.227084] [<c0349904>] (v4l2_async_test_notify) from [<c0349dd8>] (v4l2_async_register_subdev+0x88/0xd0) [ 31.236822] r7:c07115c8 r6:c071160c r5:eb38c5ec r4:eb38de80 [ 31.242622] [<c0349d50>] (v4l2_async_register_subdev) from [<c0337040>] (adv7180_probe+0x2c8/0x3a4) [ 31.251753] r8:00000000 r7:00000001 r6:eb38de80 r5:ea973400 r4:eb38de10 r3:00000000 [ 31.259660] [<c0336d78>] (adv7180_probe) from [<c032dd80>] (i2c_device_probe+0x1a0/0x1e4) This gets fixed by clearing the control device pointer on async_unbind. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Guennadi Liakhovetski <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.