aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-05-31reservation: add headerdoc commentsRob Clark2-4/+121
Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sumit Semwal <[email protected]>
2016-05-31dma-buf: headerdoc fixesRob Clark1-3/+10
Apparently nobody noticed that dma-buf.h wasn't actually pulled into docbook build. And as a result the headerdoc comments bitrot a bit. Add missing params/fields. Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sumit Semwal <[email protected]>
2016-05-31Merge tag 'gpio-v4.7-2' of ↵Linus Torvalds2-58/+41
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "A bunch of GPIO fixes for the v4.7 series: - Drop the lock before reading out the GPIO direction setting in drivers supporting the .get_direction() callback: some of them may be slowpath. - Flush GPIO direction setting before locking a GPIO as an IRQ: some electronics or other poking around in the registers behind our back may have happened, so flush the direction status before trying to lock the line for use by IRQs. - Bail out silently when asked to perform operations on NULL GPIO descriptors. That is what all the get_*_optional() is about: we get optional GPIO handles, if they are not there, we get NULL. - Handle compatible ioctl() correctly: we need to convert the ioctl() pointer using compat_ptr() here like everyone else. - Disable the broken .to_irq() on the LPC32xx platform. The whole irqchip infrastructure was replaced in the last merge window, and a new implementation will be needed" * tag 'gpio-v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: drop lock before reading GPIO direction gpio: bail out silently on NULL descriptors gpio: handle compatible ioctl() pointers gpio: flush direction status in gpiochip_lock_as_irq() gpio: lpc32xx: disable broken to_irq support
2016-05-31ALSA: uapi: Add three missing header files to Kbuild fileRobert P. J. Day1-0/+3
include/uapi/sound/Kbuild was missing the inclusion of three header files in that directory. Signed-off-by: Robert P. J. Day <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-05-31arm64: KVM: vgic-v3: Relax synchronization when SRE==1Marc Zyngier1-7/+16
The GICv3 backend of the vgic is quite barrier heavy, in order to ensure synchronization of the system registers and the memory mapped view for a potential GICv2 guest. But when the guest is using a GICv3 model, there is absolutely no need to execute all these heavy barriers, and it is actually beneficial to avoid them altogether. This patch makes the synchonization conditional, and ensures that we do not change the EL1 SRE settings if we do not need to. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31arm64: KVM: vgic-v3: Prevent the guest from messing with ICC_SRE_EL1Marc Zyngier1-4/+2
Both our GIC emulations are "strict", in the sense that we either emulate a GICv2 or a GICv3, and not a GICv3 with GICv2 legacy support. But when running on a GICv3 host, we still allow the guest to tinker with the ICC_SRE_EL1 register during its time slice: it can switch SRE off, observe that it is off, and yet on the next world switch, find the SRE bit to be set again. Not very nice. An obvious solution is to always trap accesses to ICC_SRE_EL1 (by clearing ICC_SRE_EL2.Enable), and to let the handler return the programmed value on a read, or ignore the write. That way, the guest can always observe that our GICv3 is SRE==1 only. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31arm64: KVM: Make ICC_SRE_EL1 access return the configured SRE valueMarc Zyngier1-1/+12
When we trap ICC_SRE_EL1, we handle it as RAZ/WI. It would be more correct to actual make it RO, and return the configured value when read. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31KVM: arm/arm64: vgic-v3: Always resample level interruptsMarc Zyngier1-5/+9
When reading back from the list registers, we need to perform two actions for level interrupts: 1) clear the soft-pending bit if the interrupt is not pending anymore *in the list register* 2) resample the line level and propagate it to the pending state But these two actions shouldn't be linked, and we should *always* resample the line level, no matter what state is in the list register. Otherwise, we may end-up injecting spurious interrupts that have been already retired. Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31KVM: arm/arm64: vgic-v2: Always resample level interruptsMarc Zyngier1-5/+9
When reading back from the list registers, we need to perform two actions for level interrupts: 1) clear the soft-pending bit if the interrupt is not pending anymore *in the list register* 2) resample the line level and propagate it to the pending state But these two actions shouldn't be linked, and we should *always* resample the line level, no matter what state is in the list register. Otherwise, we may end-up injecting spurious interrupts that have been already retired. Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31KVM: arm/arm64: vgic-v3: Clear all dirty LRsChristoffer Dall1-4/+3
When saving the state of the list registers, it is critical to reset them zero, as we could otherwise leave unexpected EOI interrupts pending for virtual level interrupts. Cc: [email protected] # v4.6+ Signed-off-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2016-05-31KVM: arm/arm64: vgic-v2: Clear all dirty LRsChristoffer Dall1-4/+3
When saving the state of the list registers, it is critical to reset them zero, as we could otherwise leave unexpected EOI interrupts pending for virtual level interrupts. Cc: [email protected] # v4.6+ Signed-off-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2016-05-31arm64: enable CONFIG_SET_MODULE_RONX by defaultMark Rutland1-12/+13
The SET_MODULE_RONX protections are effectively the same as the DEBUG_RODATA protections we enabled by default back in commit 57efac2f7108e325 ("arm64: enable CONFIG_DEBUG_RODATA by default"). It seems unusual to have one but not the other. As evidenced by the help text, the rationale appears to be that SET_MODULE_RONX interacts poorly with tracing and patching, but both of these make use of the insn framework, which takes SET_MODULE_RONX into account. Any remaining issues are bugs which should be fixed regardless of the default state of the option. This patch enables DEBUG_SET_MODULE_RONX by default, and replaces the help text with a new wording derived from the DEBUG_RODATA help text, which better describes the functionality. Previously, the DEBUG_RODATA entry was inconsistently indented with spaces, which are replaced with tabs as with the other Kconfig entries. Additionally, the wording of recommended defaults is made consistent for all options. These are placed in a new paragraph, unquoted, as a full sentence (with a period/full stop) as this appears to be the most common form per $(git grep 'in doubt'). Cc: Catalin Marinas <[email protected]> Cc: Laura Abbott <[email protected]> Acked-by: Kees Cook <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-05-31arm64: Remove orphaned __addr_ok() definitionRobin Murphy1-13/+0
Since commit 12a0ef7b0ac3 ("arm64: use generic strnlen_user and strncpy_from_user functions"), the definition of __addr_ok() has been languishing unused; eradicate the sucker. CC: Catalin Marinas <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-05-31mac80211: fix fast_tx header alignmentFelix Fietkau1-1/+1
The header field is defined as u8[] but also accessed as struct ieee80211_hdr. Enforce an alignment of 2 to prevent unnecessary unaligned accesses, which can be very harmful for performance on many platforms. Fixes: e495c24731a2 ("mac80211: extend fast-xmit for more ciphers") Cc: [email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2016-05-31mac80211: mesh: flush mesh paths unconditionallyBob Copeland1-0/+4
Currently, the mesh paths associated with a nexthop station are cleaned up in the following code path: __sta_info_destroy_part1 synchronize_net() __sta_info_destroy_part2 -> cleanup_single_sta -> mesh_sta_cleanup -> mesh_plink_deactivate -> mesh_path_flush_by_nexthop However, there are a couple of problems here: 1) the paths aren't flushed at all if the MPM is running in userspace (e.g. when using wpa_supplicant or authsae) 2) there is no synchronize_rcu between removing the path and readers accessing the nexthop, which means the following race is possible: CPU0 CPU1 ~~~~ ~~~~ sta_info_destroy_part1() synchronize_net() rcu_read_lock() mesh_nexthop_resolve() mpath = mesh_path_lookup() [...] -> mesh_path_flush_by_nexthop() sta = rcu_dereference( mpath->next_hop) kfree(sta) access sta <-- CRASH Fix both of these by unconditionally flushing paths before destroying the sta, and by adding a synchronize_net() after path flush to ensure no active readers can still dereference the sta. Fixes this crash: [ 348.529295] BUG: unable to handle kernel paging request at 00020040 [ 348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] *pde = 00000000 [ 348.530014] Oops: 0000 [#1] PREEMPT [ 348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ] [ 348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G O 4.6.0-rc5-wt=V1 #1 [ 348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014 [ 348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000 [ 348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0 [ 348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008 [ 348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40 [ 348.530014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690 [ 348.530014] Stack: [ 348.530014] 00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0 [ 348.530014] f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320 [ 348.530014] f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1 [ 348.530014] Call Trace: [ 348.530014] [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211] [ 348.530014] [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211] [ 348.530014] [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211] [ 348.530014] [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211] [ 348.530014] [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3 [ 348.530014] [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b [ 348.530014] [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4] [ 348.530014] [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat] [ 348.530014] [<c04c6f45>] ? netif_skb_features+0x14d/0x30a [ 348.530014] [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211] [ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc [ 348.530014] [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv] [ 348.530014] [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv] [ 348.530014] [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv] [ 348.530014] [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv] [ 348.530014] [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv] [ 348.530014] [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv] [ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb] [ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc [ 348.530014] [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge] [ 348.530014] [<f843a35f>] br_forward_finish+0x29/0x74 [bridge] [ 348.530014] [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge] [ 348.530014] [<f843a714>] __br_forward+0x89/0xe7 [bridge] [ 348.530014] [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge] [ 348.530014] [<f843a234>] deliver_clone+0x34/0x3b [bridge] [ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [<f843a66d>] br_flood+0x77/0x95 [bridge] [ 348.530014] [<f843a809>] br_flood_forward+0x13/0x1a [bridge] [ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge] [ 348.530014] [<c04e9b2b>] ? nf_iterate+0x2b/0x6b [ 348.530014] [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge] [ 348.530014] [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge] [ 348.530014] [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b [ 348.530014] [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge] [ 348.530014] [<c023cea4>] ? resched_curr+0x19/0x37 [ 348.530014] [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe [ 348.530014] [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc [ 348.530014] [<c04c4fc1>] __netif_receive_skb+0x47/0x55 [ 348.530014] [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a [ 348.530014] [<c04c61ef>] napi_gro_receive+0x3a/0x94 [ 348.530014] [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb] [ 348.530014] [<c0242bd8>] ? swake_up_locked+0x14/0x26 [ 348.530014] [<c04c5d29>] net_rx_action+0xde/0x250 [ 348.530014] [<c022a743>] __do_softirq+0x8a/0x163 [ 348.530014] [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19 [ 348.530014] [<c021100f>] do_softirq_own_stack+0x26/0x2c [ 348.530014] <IRQ> [ 348.530014] [<c022a957>] irq_exit+0x31/0x6f [ 348.530014] [<c0210eb2>] do_IRQ+0x8d/0xa0 [ 348.530014] [<c058152c>] common_interrupt+0x2c/0x40 [ 348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005 [ 348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40 [ 348.530014] CR2: 0000000000020040 [ 348.530014] ---[ end trace 48556ac26779732e ]--- [ 348.530014] Kernel panic - not syncing: Fatal exception in interrupt [ 348.530014] Kernel Offset: disabled Cc: [email protected] Reported-by: Fred Veldini <[email protected]> Tested-by: Fred Veldini <[email protected]> Signed-off-by: Bob Copeland <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2016-05-31mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNALMartin Willi1-0/+1
A wmediumd that does not send this attribute causes a NULL pointer dereference, as the attribute is accessed even if it does not exist. The attribute was required but never checked ever since userspace frame forwarding has been introduced. The issue gets more problematic once we allow wmediumd registration from user namespaces. Cc: [email protected] Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx") Signed-off-by: Martin Willi <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2016-05-31powerpc: Use privileged SPR number for MMCR2Thomas Huth1-1/+1
We are already using the privileged versions of MMCR0, MMCR1 and MMCRA in the kernel, so for MMCR2, we should better use the privileged versions, too, to be consistent. Fixes: 240686c13687 ("powerpc: Initialise PMU related regs on Power8") Cc: [email protected] # v3.10+ Suggested-by: Paul Mackerras <[email protected]> Signed-off-by: Thomas Huth <[email protected]> Acked-by: Paul Mackerras <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-05-31powerpc: Fix definition of SIAR and SDAR registersThomas Huth1-2/+2
The SIAR and SDAR registers are available twice, one time as SPRs 780 / 781 (unprivileged, but read-only), and one time as the SPRs 796 / 797 (privileged, but read and write). The Linux kernel code currently uses the unprivileged SPRs - while this is OK for reading, writing to that register of course does not work. Since the KVM code tries to write to this register, too (see the mtspr in book3s_hv_rmhandlers.S), the contents of this register sometimes get lost for the guests, e.g. during migration of a VM. To fix this issue, simply switch to the privileged SPR numbers instead. Cc: [email protected] Signed-off-by: Thomas Huth <[email protected]> Acked-by: Paul Mackerras <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-05-31Revert "arm64: hugetlb: partial revert of 66b3923a1a0f"Will Deacon1-0/+14
This reverts commit ff7925848b50050732ac0401e0acf27e8b241d7b. Now that the contiguous-hint hugetlb regression has been debugged and fixed upstream by 66ee95d16a7f ("mm: exclude HugeTLB pages from THP page_mapped() logic"), we can revert the previous partial revert of this feature. Signed-off-by: Will Deacon <[email protected]>
2016-05-31netfilter: nf_ct_helper: bail out on duplicated helpersPablo Neira Ayuso1-5/+4
Don't allow registration of helpers using the same tuple: { l3proto, l4proto, src-port } We lookup for the helper from the packet path using this tuple through __nf_ct_helper_find(). Therefore, we have to avoid having two helpers with the same tuple to ensure predictible behaviour. Don't compare the helper string names anymore since it is valid to register two helpers with the same name, but using different tuples. This is also implicitly fixing up duplicated helper registration via ports= modparam since the name comparison was defeating the tuple duplication validation. Reported-by: Feng Gao <[email protected]> Reported-by: Taehee Yoo <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2016-05-31pinctrl: mediatek: fix dual-edge code defecthongkun.cao1-2/+3
When a dual-edge irq is triggered, an incorrect irq will be reported on condition that the external signal is not stable and this incorrect irq has been registered. Correct the register offset. Cc: [email protected] Signed-off-by: Hongkun Cao <[email protected]> Reviewed-by: Matthias Brugger <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-31ARC: don't enable DISCONTIGMEM unconditionallyVineet Gupta1-2/+2
Signed-off-by: Vineet Gupta <[email protected]>
2016-05-31drm/omap: include gpio/consumer.h where neededArnd Bergmann9-8/+6
A lot of the display drivers for OMAP use the gpio descriptor functions that are only available in linux/gpio.h if GPIOLIB is enabled and otherwise produce a build error: drivers/gpu/drm/omapdrm/displays/encoder-opa362.c: In function 'opa362_enable': drivers/gpu/drm/omapdrm/displays/encoder-opa362.c:101:3: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration] drivers/gpu/drm/omapdrm/displays/panel-dpi.c: In function 'panel_dpi_probe_pdata': drivers/gpu/drm/omapdrm/displays/panel-dpi.c:189:23: error: implicit declaration of function 'gpio_to_desc' [-Werror=implicit-function-declaration] drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c: In function 'sharp_ls_enable': drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c:120:3: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration] This replaces the existing linux/gpio.h with linux/gpio/consumer.h where needed. In case of panel-lgphilips-lb035q02.c however, we also have to include linux/gpio.h to get the definition of gpio_is_valid and gpio_set_value_cansleep that are used for the non-DT case. Signed-off-by: Arnd Bergmann <[email protected]> [[email protected]: resolved conflicts] Signed-off-by: Tomi Valkeinen <[email protected]>
2016-05-31drm/omap: include linux/seq_file.h where neededArnd Bergmann7-0/+9
The omapdrm driver relies on this header to be included implicitly, but this does not always work, and I get this error in randconfig builds: gpu/drm/omapdrm/dss/hdmi_phy.c: In function 'hdmi_phy_dump': gpu/drm/omapdrm/dss/hdmi_phy.c:34:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] gpu/drm/omapdrm/dss/hdmi_wp.c: In function 'hdmi_wp_dump': gpu/drm/omapdrm/dss/hdmi_wp.c:26:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] gpu/drm/omapdrm/dss/hdmi_pll.c: In function 'hdmi_pll_dump': gpu/drm/omapdrm/dss/hdmi_pll.c:30:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] This adds the #include statements in all files that have a seq_printf statement. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-05-31Revert "drm/omap: no need to select OMAP2_DSS"Peter Ujfalusi1-0/+1
This reverts commit 1c278e5e3718d15475ec08ee2135f37a6b13361c. If DRM_OMAP does not select OMAP2_DSS it is possible to build a kernel with DRM_OMAP only and not selecting OMAP2_DSS. Since omapdrm depends on OMAP2_DSS this will result on broken kernel build. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-05-31drm/omap: Remove regulator API abusePeter Ujfalusi3-27/+0
regulator_can_change_voltage() is deprecated and it's use is not necessary as commit: 6a0028b3dd67b regulator: Deprecate regulator_can_change_voltage() describers it clearly. Also, regulator_set_voltage() is misused in the driver, as it is supposed to be used only in cases where the regulator voltage needs to be changed dynamically at runtime. In DSS's case, we always want a fixed voltage, set in the .dts files. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-05-31OMAPDSS: HDMI5: Change DDC timingsJim Lodes2-4/+4
The DDC scl high and low times were set to the minimum values from the i2c specification, but the i2c specification takes into account the rise time and fall time to calculate the frequency. To pass HDMI certification DDC can not exceed 100kHz therefore in a system where the rise times and fall times are negligible the high and low times for scl need to be 10us. Signed-off-by: Jim Lodes <[email protected]> Signed-off-by: J.D. Schroeder <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-05-31OMAPDSS: HDMI5: Fix AVI infoframeJim Lodes2-2/+2
The AVI infoframe R0-R3 in the 2nd data byte represents the Active Format Aspect Ratio. It is four bits long not two bits. This fixes that mask used to extract the bits before writing the bits to the hardware registers. Signed-off-by: Jim Lodes <[email protected]> Signed-off-by: J.D. Schroeder <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-05-31drm/omap: fix OMAP4 hdmi_core_powerdown_disable()Tomi Valkeinen1-1/+1
hdmi_core_powerdown_disable() is supposed to disable HDMI core's power-down mode. However, the function sets the power-down bit to 0, which means "enable power-down". This hasn't caused any issues as the PD seems to affect only interrupts from HDMI core, and none of those interrupts are used at the moment. CEC functionality requires core interrupts, and the PD mode needs to be fixed. This patch fixes hdmi_core_powerdown_disable() to actually disable the PD mode. Signed-off-by: Tomi Valkeinen <[email protected]> Reported-by: Hans Verkuil <[email protected]>
2016-05-31drm/omap: Fix missing includesTomi Valkeinen6-0/+6
With certain kernel config options many omapdrm files fail to compile due to missing include of linux/gpio/consumer.h and linux/of.h. This patch adds those includes. Signed-off-by: Tomi Valkeinen <[email protected]> Reported-by: Dan Murphy <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]>
2016-05-31drm/omapdrm: include pinctrl/consumer.h where neededArnd Bergmann1-0/+1
In some configurations, we can build the OMAP dss driver without implictly including the pinctrl consumer definitions, causing a build error: gpu/drm/omapdrm/dss/dss.c: In function 'dss_runtime_suspend': gpu/drm/omapdrm/dss/dss.c:1268:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration] This adds an explicit #include. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-05-31Btrfs: fix race between device replace and read repairFilipe Manana1-0/+10
While we are finishing a device replace operation we can have a concurrent task trying to do a read repair operation, in which case it will call btrfs_map_block() to get a struct btrfs_bio which can have a stripe that points to the source device of the device replace operation. This allows for the read repair task to dereference the stripe's device pointer after the device replace operation has freed the source device, resulting in an invalid memory access. This is similar to the problem solved by my previous patch in the same series and named "Btrfs: fix race between device replace and discard". So fix this by surrounding the call to btrfs_map_block() and the code that uses the returned struct btrfs_bio with calls to btrfs_bio_counter_inc_blocked() and btrfs_bio_counter_dec(), giving the proper serialization with the finishing phase of the device replace operation. Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: Josef Bacik <[email protected]>
2016-05-31Btrfs: fix race between device replace and discardFilipe Manana1-0/+6
While we are finishing a device replace operation, we can make a discard operation (fs mounted with -o discard) do an invalid memory access like the one reported by the following trace: [ 3206.384654] general protection fault: 0000 [#1] PREEMPT SMP [ 3206.387520] Modules linked in: dm_mod btrfs crc32c_generic xor raid6_pq acpi_cpufreq tpm_tis psmouse tpm ppdev sg parport_pc evdev i2c_piix4 parport processor serio_raw i2c_core pcspkr button loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom ata_generic sd_mod virtio_scsi ata_piix libata virtio_pci virtio_ring scsi_mod e1000 virtio floppy [last unloaded: btrfs] [ 3206.388595] CPU: 14 PID: 29194 Comm: fsstress Not tainted 4.6.0-rc7-btrfs-next-29+ #1 [ 3206.388595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014 [ 3206.388595] task: ffff88017ace0100 ti: ffff880171b98000 task.ti: ffff880171b98000 [ 3206.388595] RIP: 0010:[<ffffffff8124d233>] [<ffffffff8124d233>] blkdev_issue_discard+0x5c/0x2a7 [ 3206.388595] RSP: 0018:ffff880171b9bb80 EFLAGS: 00010246 [ 3206.388595] RAX: ffff880171b9bc28 RBX: 000000000090d000 RCX: 0000000000000000 [ 3206.388595] RDX: ffffffff82fa1b48 RSI: ffffffff8179f46c RDI: ffffffff82fa1b48 [ 3206.388595] RBP: ffff880171b9bcc0 R08: 0000000000000000 R09: 0000000000000001 [ 3206.388595] R10: ffff880171b9bce0 R11: 000000000090f000 R12: ffff880171b9bbe8 [ 3206.388595] R13: 0000000000000010 R14: 0000000000004868 R15: 6b6b6b6b6b6b6b6b [ 3206.388595] FS: 00007f6182e4e700(0000) GS:ffff88023fdc0000(0000) knlGS:0000000000000000 [ 3206.388595] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3206.388595] CR2: 00007f617c2bbb18 CR3: 000000017ad9c000 CR4: 00000000000006e0 [ 3206.388595] Stack: [ 3206.388595] 0000000000004878 0000000000000000 0000000002400040 0000000000000000 [ 3206.388595] 0000000000000000 ffff880171b9bbe8 ffff880171b9bbb0 ffff880171b9bbb0 [ 3206.388595] ffff880171b9bbc0 ffff880171b9bbc0 ffff880171b9bbd0 ffff880171b9bbd0 [ 3206.388595] Call Trace: [ 3206.388595] [<ffffffffa042899e>] btrfs_issue_discard+0x12f/0x143 [btrfs] [ 3206.388595] [<ffffffffa042899e>] ? btrfs_issue_discard+0x12f/0x143 [btrfs] [ 3206.388595] [<ffffffffa042e862>] btrfs_discard_extent+0x87/0xde [btrfs] [ 3206.388595] [<ffffffffa04303b5>] btrfs_finish_extent_commit+0xb2/0x1df [btrfs] [ 3206.388595] [<ffffffff8149c246>] ? __mutex_unlock_slowpath+0x150/0x15b [ 3206.388595] [<ffffffffa04464c4>] btrfs_commit_transaction+0x7fc/0x980 [btrfs] [ 3206.388595] [<ffffffff8149c246>] ? __mutex_unlock_slowpath+0x150/0x15b [ 3206.388595] [<ffffffffa0459af6>] btrfs_sync_file+0x38f/0x428 [btrfs] [ 3206.388595] [<ffffffff811a8292>] vfs_fsync_range+0x8c/0x9e [ 3206.388595] [<ffffffff811a82c0>] vfs_fsync+0x1c/0x1e [ 3206.388595] [<ffffffff811a8417>] do_fsync+0x31/0x4a [ 3206.388595] [<ffffffff811a8637>] SyS_fsync+0x10/0x14 [ 3206.388595] [<ffffffff8149e025>] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 3206.388595] [<ffffffff81100c6b>] ? time_hardirqs_off+0x9/0x14 [ 3206.388595] [<ffffffff8108e87d>] ? trace_hardirqs_off_caller+0x1f/0xaa This happens because when we call btrfs_map_block() from btrfs_discard_extent() to get a btrfs_bio structure, the device replace operation has not finished yet, but before we use the device of one of the stripes from the returned btrfs_bio structure, the device object is freed. This is illustrated by the following diagram. CPU 1 CPU 2 btrfs_dev_replace_start() (...) btrfs_dev_replace_finishing() btrfs_start_transaction() btrfs_commit_transaction() (...) btrfs_sync_file() btrfs_start_transaction() (...) btrfs_commit_transaction() btrfs_finish_extent_commit() btrfs_discard_extent() btrfs_map_block() --> returns a struct btrfs_bio with a stripe that has a device field pointing to source device of the replace operation (the device that is being replaced) mutex_lock(&uuid_mutex) mutex_lock(&fs_info->fs_devices->device_list_mutex) mutex_lock(&fs_info->chunk_mutex) btrfs_dev_replace_update_device_in_mapping_tree() --> iterates the mapping tree and for each extent map that has a stripe pointing to the source device, it updates the stripe to point to the target device instead btrfs_rm_dev_replace_blocked() --> waits for fs_info->bio_counter to go down to 0 btrfs_rm_dev_replace_remove_srcdev() --> removes source device from the list of devices mutex_unlock(&fs_info->chunk_mutex) mutex_unlock(&fs_info->fs_devices->device_list_mutex) mutex_unlock(&uuid_mutex) btrfs_rm_dev_replace_free_srcdev() --> frees the source device --> iterates over all stripes of the returned struct btrfs_bio --> for each stripe it dereferences its device pointer --> it ends up finding a pointer to the device used as the source device for the replace operation and that was already freed So fix this by surrounding the call to btrfs_map_block(), and the code that uses the returned struct btrfs_bio, with calls to btrfs_bio_counter_inc_blocked() and btrfs_bio_counter_dec(), so that the finishing phase of the device replace operation blocks until the the bio counter decreases to zero before it frees the source device. This is the same approach we do at btrfs_map_bio() for example. Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: Josef Bacik <[email protected]>
2016-05-30Merge branch 'uuid' (lib/uuid fixes from Andy)Linus Torvalds4-2/+139
Merge lib/uuid fixes from Andy Shevchenko. * emailed patches from Andy Shevchenko <[email protected]>: lib/uuid.c: use correct offset in uuid parser lib/uuid: add a test module
2016-05-30lib/uuid.c: use correct offset in uuid parserBjørn Mork1-2/+2
Use '+ 0' and '+ 1' as offsets, like they were intended, instead of adding to the result. Fixes: 2b1b0d66704a ("lib/uuid.c: introduce a few more generic helpers") Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-05-30lib/uuid: add a test moduleAndy Shevchenko3-0/+137
It appears that somehow I missed a test of the latest UUID rework which landed in the kernel. Present a small test module to avoid such cases in the future. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-05-30Merge branch 'linus' of ↵Linus Torvalds3-6/+14
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes the following issues: - missing selection in public_key that may result in a build failure - Potential crash in error path in omap-sham - ccp AES XTS bug that affects requests larger than 4096" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: ccp - Fix AES XTS error for request sizes above 4096 crypto: public_key: select CRYPTO_AKCIPHER crypto: omap-sham - potential Oops on error in probe
2016-05-30libceph: use %s instead of %pE in dout()sIlya Dryomov2-5/+5
Commit d30291b985d1 ("libceph: variable-sized ceph_object_id") changed dout()s in what is now encode_request() and ceph_object_locator_to_pg() to use %pE, mostly to document that, although all rbd and cephfs object names are NULL-terminated strings, ceph_object_id will handle any RADOS object name, including the one containing NULs, just fine. However, it turns out that vbin_printf() can't handle anything but ints and %s - all %p suffixes are ignored. The buffer %p** points to isn't recorded, resulting in trash in the messages if the buffer had been reused by the time bstr_printf() got to it. Signed-off-by: Ilya Dryomov <[email protected]>
2016-05-30libceph: put request only if it's done in handle_reply()Ilya Dryomov1-3/+3
handle_reply() may be called twice on the same request: on ack and then on commit. This occurs on btrfs-formatted OSDs or if cephfs sync write path is triggered - CEPH_OSD_FLAG_ACK | CEPH_OSD_FLAG_ONDISK. handle_reply() handles this with the help of done_request(). Fixes: 5aea3dcd5021 ("libceph: a major OSD client update") Signed-off-by: Ilya Dryomov <[email protected]>
2016-05-30libceph: change ceph_osdmap_flag() to take osdcIlya Dryomov4-29/+28
For the benefit of every single caller, take osdc instead of map. Also, now that osdc->osdmap can't ever be NULL, drop the check. Signed-off-by: Ilya Dryomov <[email protected]>
2016-05-30ARC: [intc-compact] simplify code for 2 priority levelsVineet Gupta3-40/+6
ARC700 support for 2 interrupt priorities historically allowed even slow perpherals such as emac and uart to setup high priority interrupts which was wrong from the beginning as they could possibly delay the more critical timer interrupt. The hardware support for 2 level interrupts in ARCompact is less than ideal anyways (judging from the "hacks" in low level entry code and thus is not used in productions systems I know of. So reduce the scope of this to timer only, thereby reducing a bunch of complexity. Signed-off-by: Vineet Gupta <[email protected]>
2016-05-30gpio: drop lock before reading GPIO directionLinus Walleij1-2/+2
When adding the gpiochip, the GPIO HW drivers' callback get_direction() could get called in atomic context. Some of the GPIO HW drivers may sleep when accessing the register. Move the lock before initializing the descriptors. Reported-by: Laxman Dewangan <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-30gpio: bail out silently on NULL descriptorsLinus Walleij1-3/+8
In fdeb8e1547cb9dd39d5d7223b33f3565cf86c28e ("gpio: reflect base and ngpio into gpio_device") assumed that GPIO descriptors are either valid or error pointers, but gpiod_get_[index_]optional() actually return NULL descriptors and then all subsequent calls should just bail out. Cc: [email protected] Cc: Sergei Shtylyov <[email protected]> Cc: Florian Fainelli <[email protected]> Cc: Andrew Lunn <[email protected]> Fixes: fdeb8e1547cb ("gpio: reflect base and ngpio into gpio_device") Reported-by: Uwe Kleine-König <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-30writeback: use higher precision calculation in domain_dirty_limits()Tejun Heo1-9/+12
As vm.dirty_[background_]bytes can't be applied verbatim to multiple cgroup writeback domains, they get converted to percentages in domain_dirty_limits() and applied the same way as vm.dirty_[background]ratio. However, if the specified bytes is lower than 1% of available memory, the calculated ratios become zero and the writeback domain gets throttled constantly. Fix it by using per-PAGE_SIZE instead of percentage for ratio calculations. Also, the updated DIV_ROUND_UP() usages now should yield 1/4096 (0.0244%) as the minimum ratio as long as the specified bytes are above zero. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Miao Xie <[email protected]> Link: http://lkml.kernel.org/g/[email protected] Cc: [email protected] # v4.2+ Fixes: 9fc3a43e1757 ("writeback: separate out domain_dirty_limits()") Reviewed-by: Jan Kara <[email protected]> Adjusted comment based on Jan's suggestion. Signed-off-by: Jens Axboe <[email protected]>
2016-05-30gpio: handle compatible ioctl() pointersLinus Walleij1-2/+13
If we're using the compatible ioctl() we need to handle the argument pointer in a special way or there will be trouble. Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs") Reported-by: Dmitry Torokhov <[email protected]> Reviewed-by: Dmitry Torokhov <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-30vfio/type1: Fix build warningAlex Williamson1-1/+1
This function cannot actually be called with npage = 0, so in practice this doesn't return an uninitialized value. Signed-off-by: Alex Williamson <[email protected]>
2016-05-30vfio/pci: Fix ordering of eventfd vs virqfd shutdownAlex Williamson1-3/+3
Both the INTx and MSI/X disable paths do an eventfd_ctx_put() for the trigger eventfd before calling vfio_virqfd_disable() any potential mask and unmask eventfds. This opens a use-after-free race where an inopportune irqfd can reference the freed signalling eventfd. Reorder to avoid this possibility. Signed-off-by: Alex Williamson <[email protected]>
2016-05-30cpufreq: intel_pstate: Downgrade print level for _PPCSrinivas Pandruvada1-1/+1
Downgrade pr_info to pr_debug for the "_PPC limits will be enforced" message. In server systems with many cores this message is annoying. Signed-off-by: Srinivas Pandruvada <[email protected]> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2016-05-30ALSA: hda/realtek - Add support for new codecs ALC700/ALC701/ALC703Kailang Yang1-0/+16
Support new codecs for ALC700/ALC701/ALC703. Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-05-30ALSA: hda/realtek - ALC256 speaker noise issueKailang Yang1-5/+47
That is some different register for ALC255 and ALC256. ALC256 can't fit with some ALC255 register. This issue is cause from LDO output voltage control. This patch is updated the right LDO register value. Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.