aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-03-18scsi: fc: use get/put_unaligned64 for wwn accessArnd Bergmann1-12/+3
A bug in the gcc-6.0 prerelease version caused at least one driver (lpfc) to have excessive stack usage when dealing with wwn data, on the ARM architecture. lpfc_scsi.c: In function 'lpfc_find_next_oas_lun': lpfc_scsi.c:117:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=] I have reported this as a gcc regression in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232 However, using a better implementation of wwn_to_u64() not only helps with the particular gcc problem but also leads to better object code for any version or architecture. The kernel already provides get_unaligned_be64() and put_unaligned_be64() helper functions that provide an optimized implementation with the desired semantics. The lpfc_find_next_oas_lun() function in the example that grew from 1146 bytes to 5144 bytes when moving from gcc-5.3 to gcc-6.0 is now 804 bytes, as the optimized get_unaligned_be64() load can be done in three instructions. The stack usage is now down to 28 bytes from 128 bytes with gcc-5.3 before. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Hannes Reinicke <[email protected]> Reviewed-by: Ewan Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2016-03-18fnic: move printk()s outside of the critical code section.Maurizio Lombardi1-7/+6
This patch moves a printk() outside of the code section where interrupt are disabled. In some cases a flood of error messages may cause a kernel panic. It also removes one of the printk()s because the same error message was printed twice. [709686.317197] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 12 [709686.317200] CPU: 12 PID: 1963 Comm: systemd-journal Tainted: GF O-------------- 3.10.0-229.el7.x86_64 #1 [709686.317201] Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.6.030620151309 03/06/2015 [709686.317206] ffffffff8182b2e8 00000000392722ba ffff88046fcc5c48 ffffffff81603f36 [709686.317209] ffff88046fcc5cc8 ffffffff815fd7da 0000000000000010 ffff88046fcc5cd8 [709686.317211] ffff88046fcc5c78 00000000392722ba ffff88046fcc5c88 000000000000000c [709686.317212] Call Trace: [709686.317221] <NMI> [<ffffffff81603f36>] dump_stack+0x19/0x1b [709686.317223] [<ffffffff815fd7da>] panic+0xd8/0x1e7 [709686.317227] [<ffffffff8110a760>] ? watchdog_enable_all_cpus.part.2+0x40/0x40 [709686.317229] [<ffffffff8110a822>] watchdog_overflow_callback+0xc2/0xd0 [709686.317233] [<ffffffff8114c901>] __perf_event_overflow+0xa1/0x250 [709686.317235] [<ffffffff8114d404>] perf_event_overflow+0x14/0x20 [709686.317239] [<ffffffff810301fd>] intel_pmu_handle_irq+0x1fd/0x410 [709686.317242] [<ffffffff811908d1>] ? unmap_kernel_range_noflush+0x11/0x20 [709686.317246] [<ffffffff81373574>] ? ghes_copy_tofrom_phys+0x124/0x210 [709686.317249] [<ffffffff8160cfcb>] perf_event_nmi_handler+0x2b/0x50 [709686.317251] [<ffffffff8160c719>] nmi_handle.isra.0+0x69/0xb0 [709686.317252] [<ffffffff8160c830>] do_nmi+0xd0/0x340 [709686.317256] [<ffffffff8160bb71>] end_repeat_nmi+0x1e/0x2e [709686.317260] [<ffffffff812e24fd>] ? memcpy+0xd/0x110 [709686.317263] [<ffffffff812e24fd>] ? memcpy+0xd/0x110 [709686.317265] [<ffffffff812e24fd>] ? memcpy+0xd/0x110 [709686.317269] <<EOE>> [<ffffffff8132c297>] ? vgacon_scroll+0x2d7/0x330 [709686.317273] [<ffffffff813a086c>] scrup+0xfc/0x110 [709686.317275] [<ffffffff813a0920>] lf+0xa0/0xb0 [709686.317278] [<ffffffff813a1b32>] vt_console_print+0x2d2/0x420 [709686.317283] [<ffffffff8106f4a1>] call_console_drivers.constprop.15+0x91/0xf0 [709686.317287] [<ffffffff8107069f>] console_unlock+0x3bf/0x400 [709686.317291] [<ffffffff81070996>] vprintk_emit+0x2b6/0x530 [709686.317294] [<ffffffff815fd961>] printk_emit+0x44/0x5b [709686.317297] [<ffffffff81070d98>] devkmsg_writev+0x158/0x1d0 [709686.317303] [<ffffffff811c5ef9>] do_sync_readv_writev+0x79/0xd0 [709686.317307] [<ffffffff811c73ee>] do_readv_writev+0xce/0x260 [709686.317310] [<ffffffff811c8d18>] ? __sb_start_write+0x58/0x110 [709686.317314] [<ffffffff811c7615>] vfs_writev+0x35/0x60 [709686.317318] [<ffffffff811c776c>] SyS_writev+0x5c/0xd0 [709686.317322] [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b Signed-off-by: Maurizio Lombardi <[email protected]> Reviewed-by: Laurence Oberman <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2016-03-18qla2xxx: avoid maybe_uninitialized warningArnd Bergmann1-7/+9
The qlt_check_reserve_free_req() function produces an incorrect warning when CONFIG_PROFILE_ANNOTATED_BRANCHES is set: drivers/scsi/qla2xxx/qla_target.c: In function 'qlt_check_reserve_free_req': drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt_in' may be used uninitialized in this function [-Werror=maybe-uninitialized] ql_dbg(ql_dbg_io, vha, 0x305a, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "qla_target(%d): There is no room in the request ring: vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d Req-in=%d Req-Length=%d\n", ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vha->vp_idx, vha->req->ring_index, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vha->req->cnt, req_cnt, cnt, cnt_in, vha->req->length); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] The problem is that gcc fails to track the state of the condition across an annotated branch. This slightly rearranges the code to move the second if() block into the first one, to avoid the warning while retaining the behavior of the code. Signed-off-by: Arnd Bergmann <[email protected]> Acked-By: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2016-03-18megaraid_sas: add missing curly braces in ioctl handlerArnd Bergmann1-1/+2
gcc-6 found a dubious indentation in the megasas_mgmt_fw_ioctl function: drivers/scsi/megaraid/megaraid_sas_base.c: In function 'megasas_mgmt_fw_ioctl': drivers/scsi/megaraid/megaraid_sas_base.c:6658:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] kbuff_arr[i] = NULL; ^~~~~~~~~ drivers/scsi/megaraid/megaraid_sas_base.c:6653:3: note: ...this 'if' clause, but it is not if (kbuff_arr[i]) ^~ The code is actually correct, as there is no downside in clearing a NULL pointer again. This clarifies the code and avoids the warning by adding extra curly braces. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 90dc9d98f01b ("megaraid_sas : MFI MPT linked list corruption fix") Reviewed-by: Hannes Reinecke <[email protected]> Acked-by: Sumit Saxena <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2016-03-18lpfc: fix misleading indentationArnd Bergmann1-2/+3
gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array() call in lpfc_online(), which clearly doesn't look right: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online': drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] lpfc_destroy_vport_work_array(phba, vports); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not if (vports != NULL) ^~ Looking at the patch that introduced this code, it's clear that the behavior is correct and the indentation is wrong. This fixes the indentation and adds curly braces around the previous if() block for clarity, as that is most likely what caused the code to be misindented in the first place. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 549e55cd2a1b ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list") Reviewed-by: Sebastian Herbszt <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Ewan D. Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2016-03-18perf symbols: Record text offset in dso to calculate objdump addressWang Nan2-6/+7
Store DSO's .text offset into DSO, used for VDSOs and will also be used for other needs, like handling kernel modules. Signed-off-by: Wang Nan <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Cody P Schafer <[email protected]> Cc: He Kuang <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kirill Smelkov <[email protected]> Cc: Li Zefan <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] [ Extracted from larger patch ] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-03-18Merge tag 'for-linus-4.6' of git://git.code.sf.net/p/openipmi/linux-ipmiLinus Torvalds2-13/+11
Pull IPMI updates from Corey Minyard: "Just some minor fixes, nothing big" * tag 'for-linus-4.6' of git://git.code.sf.net/p/openipmi/linux-ipmi: ipmi: do not probe ACPI devices if si_tryacpi is unset ipmi_si: Avoid a wrong long timeout on transaction done ipmi_si: Fix module parameter doc names ipmi_ssif: Fix logic around alert handling
2016-03-18Merge tag 'mfd-for-linus-4.6' of ↵Linus Torvalds58-277/+3256
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "New Drivers: - Freescale Touch Screen ADC - X-Powers AXP PMIC with RSB - TI TPS65086 Power Management IC (PMIC) New Device Support: - Supply device PCI IDs for Intel Broxton Fix-ups: - Move to clkdev_create() API; intel_quark_i2c_gpio - Complete re-write of TI's TPS65912 Power Management IC (PMIC) - Remove unnecessary function argument; axp20x - Separate out bus related code; axp20x - Coding Style changes; axp20x - Allow more drivers to be compiled as modules - Work around false positive 'used uninitialised' warning; db8500-prcmu Bug Fixes: - Remove do_div(); fsl-imx25-gcq - Fix driver init when built-in; tps65010 - Fix clock-unregister leak; intel-lpss" * tag 'mfd-for-linus-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (53 commits) mfd: intel-lpss: Pass I2C configuration via properties on BXT mfd: imx6sx: Add PCIe register definitions for iomuxc gpr mfd: ipaq-micro: Use __maybe_unused to hide pm functions mfd: max77686: Add max77802 to I2C device ID table mfd: max77686: Export OF module alias information mfd: max77686: Allow driver to be built as a module mfd: stmpe: Add the proper PWM resources mfd: tps65090: Set regmap config reg counts properly mfd: syscon: Return ENOTSUPP instead of ENOSYS when disabled mfd: as3711: Set regmap config reg counts properly mfd: rc5t583: Set regmap config reg counts properly gpio: tps65086: Add GPO driver for the TPS65086 PMIC mfd: mt6397: Add platform device ID table mfd: da9063: Fix missing volatile registers in the core regmap_range volatile lists mfd: mt6397: Add MT6323 support to MT6397 driver mfd: mt6397: Add support for different Slave types mfd: mt6397: int_con and int_status may vary in location dt-bindings: mfd: Add bindings for the MediaTek MT6323 PMIC mfd: da9062: Fix missing volatile registers in the core regmap_range volatile lists mfd: Add documentation for ACT8945A DT bindings ...
2016-03-18Merge tag 'sound-4.6-rc1' of ↵Linus Torvalds202-4360/+12770
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound updates from Takashi Iwai: "After a heavy storm by syzkaller in 4.5 cycle, we have relatively few changes in the core at this time while a lot of changes are found in the driver side, unsurprisingly. Below are some highlights: ALSA core: - A few more hardening in ALSA timer codes - An extension of sequencer API for advertising the card / pid - Small fixes in compress-offload and jack layers HD-audio: - Dynamic PCM assignment in HDMI/DP codec; preparation for upcoming DP-MST support - Lots of code refactoring for sharing with ASoC SKL driver - Regression fixes for Intel HDMI/DP - Fixups for CX20724 codec, Lenovo AiO USB-audio: - Add quirk_alias option to make quirk debugging easier - Fixes for possible Oops by malformed firmware Firewire: - Add support for FW-1804 in tascam driver - Improvements / changes in card registration, multi stream handling, etc for DICE - Lots of code refactoring ASoC: - Enhancements of still ongoing topology API - Lots of commits for Intel Skylake support including HDMI support - A few Intel Atom driver updates for recent devices - Lots of improvements to the Renesas drivers - Capture support for Qualcomm drivers - Support for TI DaVinci DRA7xxx devices - New machine drivers for Freescale systems with Cirrus CODECs, Mediatek systems with RT5650 CODECs - New CPU drivers for Allwinner S/PDIF controllers - New CODEC drivers for Maxim MAX9867 and MAX98926 and Realtek RT5514" * tag 'sound-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (291 commits) ALSA: hda - Fix mutex deadlock at HDMI/DP hotplug ALSA: ctl: change return value in compatibility layer so that it's the same value in core implementation ALSA: mixart: silence an uninitialized variable warning ALSA: usb-audio: Add sanity checks for endpoint accesses ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk() ALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk() ALSA: hda - Limit i915 HDMI binding only for HSW and later ALSA: hda - Fix unconditional GPIO toggle via automute ALSA: mixart: silence unitialized variable warnings ALSA: hda - Fixes double fault in nvhdmi_chmap_cea_alloc_validate_get_type ALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41. ALSA: hda - Add new GPU codec ID 0x10de0082 to snd-hda ASoC: rsnd: add simplified module explanation ASoC: hdac_hdmi: Add broxton device ID ASoC: Intel: Bxtn: Add Broxton PCI ID ASoC: Intel: Skylake: Move Skylake dsp ops & loader ops ASoC: Intel: add dmabuffer to common sst_dsp ASoC: Intel: Skylake: Unstatify skl_dsp_enable_core ASoC: Intel: Skylake: Fix whitepsace issues ASoC: Intel: Skylake: Move module id defines ...
2016-03-18ALSA: hda - Fix forgotten HDMI monitor_present updateTakashi Iwai1-0/+1
We forgot to copy monitor_present value when updating the ELD information. This won't change the ELD retrieval and the jack notification behavior, but appears only in the proc output. In that sense, it's no fatal error, but a bug is a bug is a bug. Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-03-18tools: Move utilities.mak from perf to tools/scripts/Arnaldo Carvalho de Melo6-5/+5
As it is used by several other tools, better move it outside tools/perf. Cc: Adrian Hunter <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Wang Nan <[email protected]> Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-03-18tracing: Have preempt(irqs)off trace preempt disabled functionsSteven Rostedt (Red Hat)1-2/+6
Joel Fernandes reported that the function tracing of preempt disabled sections was not being reported when running either the preemptirqsoff or preemptoff tracers. This was due to the fact that the function tracer callback for those tracers checked if irqs were disabled before tracing. But this fails when we want to trace preempt off locations as well. Joel explained that he wanted to see funcitons where interrupts are enabled but preemption was disabled. The expected output he wanted: <...>-2265 1d.h1 3419us : preempt_count_sub <-irq_exit <...>-2265 1d..1 3419us : __do_softirq <-irq_exit <...>-2265 1d..1 3419us : msecs_to_jiffies <-__do_softirq <...>-2265 1d..1 3420us : irqtime_account_irq <-__do_softirq <...>-2265 1d..1 3420us : __local_bh_disable_ip <-__do_softirq <...>-2265 1..s1 3421us : run_timer_softirq <-__do_softirq <...>-2265 1..s1 3421us : hrtimer_run_pending <-run_timer_softirq <...>-2265 1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq <...>-2265 1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq <...>-2265 1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq <...>-2265 1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq <...>-2265 1..s1 3423us : rcu_bh_qs <-__do_softirq <...>-2265 1d.s1 3423us : irqtime_account_irq <-__do_softirq <...>-2265 1d.s1 3423us : __local_bh_enable <-__do_softirq There's a comment saying that the irq disabled check is because there's a possible race that tracing_cpu may be set when the function is executed. But I don't remember that race. For now, I added a check for preemption being enabled too to not record the function, as there would be no race if that was the case. I need to re-investigate this, as I'm now thinking that the tracing_cpu will always be correct. But no harm in keeping the check for now, except for the slight performance hit. Link: http://lkml.kernel.org/r/[email protected] Fixes: 5e6d2b9cfa3a "tracing: Use one prologue for the preempt irqs off tracer function tracers" Cc: [email protected] # 2.6.37+ Reported-by: Joel Fernandes <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2016-03-18ARM: dts: uniphier: add pinmux node for I2C ch4Masahiro Yamada1-0/+5
This will be needed for UniPhier PH1-LD11 and PH1-LD20 SoCs. Signed-off-by: Masahiro Yamada <[email protected]>
2016-03-18ARM: dts: uniphier: add @{address} to EEPROM nodeMasahiro Yamada1-1/+1
Just for consistent coding style. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18ARM: dts: uniphier: add PH1-Pro4 Sanji board supportMasahiro Yamada2-0/+109
Initial commit for PH1-Pro4 Sanji board support. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18Merge tag 'for-linus' of ↵Linus Torvalds90-1973/+3618
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma Pull rdma updates from Doug Ledford: "Initial roundup of 4.6 merge window patches. This is the first of two pull requests. It is the smaller request, but touches for more different things (this is everything but what is in or going into staging). The pull request for the code in staging/rdma is on hold until after we decide what to do on the write/writev API issue and may be partially deferred until 4.7 as a result. Summary: - cxgb4 updates - nes updates - unification of iwarp portmapper code to core - add drain_cq API - various ib_core updates - minor ipoib updates - minor mlx4 updates - more significant mlx5 updates (including a minor merge conflict with net-next tree...merge is simple to resolve and Stephen's resolution was confirmed by Mellanox) - trivial net/9p rdma conversion - ocrdma RoCEv2 update - srpt updates" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: (85 commits) iwpm: crash fix for large connections test iw_cxgb3: support for iWARP port mapping iw_cxgb4: remove port mapper related code iw_nes: remove port mapper related code iwcm: common code for port mapper net/9p: convert to new CQ API IB/mlx5: Add support for don't trap rules net/mlx5_core: Introduce forward to next priority action net/mlx5_core: Create anchor of last flow table iser: Accept arbitrary sg lists mapping if the device supports it mlx5: Add arbitrary sg list support IB/core: Add arbitrary sg_list support IB/mlx5: Expose correct max_fast_reg_page_list_len IB/mlx5: Make coding style more consistent IB/mlx5: Convert UMR CQ to new CQ API IB/ocrdma: Skip using unneeded intermediate variable IB/ocrdma: Skip using unneeded intermediate variable IB/ocrdma: Delete unnecessary variable initialisations in 11 functions IB/core: Documentation fix in the MAD header file IB/core: trivial prink cleanup. ...
2016-03-18ARM: dts: uniphier: add PH1-Pro4 Ace board supportMasahiro Yamada2-0/+114
Initial commit for PH1-Pro4 Ace board support. Note: There are two variants for the amount of DDR memory; 1GB or 2GB. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18ARM: dts: uniphier: enable I2C channel 2 of ProXstream2 Gentil boardMasahiro Yamada1-0/+5
This is used for on-board inter-connection. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18ARM: dts: uniphier: add EEPROM node for ProXstream2 Gentil boardMasahiro Yamada1-0/+5
This board has an EEPROM (STMicroelectronics M24C64-WMN6TP) connected to the I2C channel 0 of the SoC. Its slave address is 0x54. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18ARM: dts: uniphier: add reference clock nodesMasahiro Yamada7-0/+33
Add master clock nodes generated by crystal oscillators. PH1-sLD3, PH1-LD4: 24.576 MHz PH1-Pro4, ProXstream2: 25.000 MHz PH1-Pro5: 20.000 MHz Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18ARM: dts: uniphier: rework UniPhier System Bus nodesMasahiro Yamada4-25/+37
During the review process of the UniPhier System Bus driver (drivers/bus/uniphier.c), the current binding of the System Bus Controller turned out to be no good. In order to make the driver really usable, we have to switch over to the new binding defined by Documentation/devicetree/bindings/bus/uniphier-system-bus.txt. The old binding will be still supported for a while to keep the backward compatibility. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18ARM: dts: uniphier: factor out ranges property of support cardMasahiro Yamada7-48/+3
This property is used in common by several boards. Move it to the common place (uniphier-support-card.dtsi). If necessary, each board can still override the property. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18arm64: dts: uniphier: rename PH1-LD10 to PH1-LD20Masahiro Yamada3-8/+8
Due to the company's awful projecting, this chip has been renamed to PH1-LD20. It has not been shipped yet, this change would have no impact on our customers. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18ARM: uniphier: rework SMP code to support new System Bus bindingMasahiro Yamada1-9/+16
During the review process of the UniPhier System Bus driver (drivers/bus/uniphier.c), the current binding of the System Bus Controller turned out to be no good. In order to use the driver, some nodes in the device trees must be tweaked. It would also have impacts on the SMP code because the SMP related registers are located in the System Bus Controller block. This commit reworks the smp_operations to support the new binding, but still supports the old binding, too. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18ARM: uniphier: add missing of_node_put()Masahiro Yamada1-0/+1
This node pointer is allocated by of_find_compatible_node() in this function. It should be put before exitting this function. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-03-18USB: uas: Reduce can_queue to MAX_CMNDSHans de Goede1-1/+1
The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags are shared between luns, so there is no need to claim that we can_queue some random large number. Not claiming that we can_queue 65536 commands, fixes the uas driver failing to initialize while allocating the tag map with a "Page allocation failure (order 7)" error on systems which have been running for a while and thus have fragmented memory. Cc: [email protected] Reported-and-tested-by: Yves-Alexis Perez <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-03-18USB: cdc-acm: more sanity checkingOliver Neukum1-0/+3
An attack has become available which pretends to be a quirky device circumventing normal sanity checks and crashes the kernel by an insufficient number of interfaces. This patch adds a check to the code path for quirky devices. Signed-off-by: Oliver Neukum <[email protected]> CC: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-03-18USB: usb_driver_claim_interface: add sanity checkingOliver Neukum1-1/+5
Attacks that trick drivers into passing a NULL pointer to usb_driver_claim_interface() using forged descriptors are known. This thwarts them by sanity checking. Signed-off-by: Oliver Neukum <[email protected]> CC: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-03-18usb/core: usb_alloc_dev(): fix setting of ->portnumNicolai Stange1-2/+3
With commit 69bec7259853 ("USB: core: let USB device know device node"), the port1 argument of usb_alloc_dev() gets overwritten as follows: ... usb_alloc_dev(..., unsigned port1) { ... if (!parent->parent) { port1 = usb_hcd_find_raw_port_number(..., port1); } ... } Later on, this now overwritten port1 gets assigned to ->portnum: dev->portnum = port1; However, since xhci_find_raw_port_number() isn't idempotent, the aforementioned commit causes a number of KASAN splats like the following: BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170 at addr ffff8801d9311670 Read of size 8 by task kworker/2:1/87 [...] Workqueue: usb_hub_wq hub_event 0000000000000188 000000005814b877 ffff8800cba17588 ffffffff8191447e 0000000041b58ab3 ffffffff82a03209 ffffffff819143a2 ffffffff82a252f4 ffff8801d93115e0 0000000000000188 ffff8801d9311628 ffff8800cba17588 Call Trace: [<ffffffff8191447e>] dump_stack+0xdc/0x15e [<ffffffff819143a2>] ? _atomic_dec_and_lock+0xa2/0xa2 [<ffffffff814e2cd1>] ? print_section+0x61/0xb0 [<ffffffff814e4939>] print_trailer+0x179/0x2c0 [<ffffffff814f0d84>] object_err+0x34/0x40 [<ffffffff814f4388>] kasan_report_error+0x2f8/0x8b0 [<ffffffff814eb91e>] ? __slab_alloc+0x5e/0x90 [<ffffffff812178c0>] ? __lock_is_held+0x90/0x130 [<ffffffff814f5091>] kasan_report+0x71/0xa0 [<ffffffff814ec082>] ? kmem_cache_alloc_trace+0x212/0x560 [<ffffffff81d99468>] ? xhci_find_raw_port_number+0x98/0x170 [<ffffffff814f33d4>] __asan_load8+0x64/0x70 [<ffffffff81d99468>] xhci_find_raw_port_number+0x98/0x170 [<ffffffff81db0105>] xhci_setup_addressable_virt_dev+0x235/0xa10 [<ffffffff81d9ea51>] xhci_setup_device+0x3c1/0x1430 [<ffffffff8121cddd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81d9fac0>] ? xhci_setup_device+0x1430/0x1430 [<ffffffff81d9fad3>] xhci_address_device+0x13/0x20 [<ffffffff81d2081a>] hub_port_init+0x55a/0x1550 [<ffffffff81d28705>] hub_event+0xef5/0x24d0 [<ffffffff81d27810>] ? hub_port_debounce+0x2f0/0x2f0 [<ffffffff8195e1ee>] ? debug_object_deactivate+0x1be/0x270 [<ffffffff81210203>] ? print_rt_rq+0x53/0x2d0 [<ffffffff8121657d>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff8226acfb>] ? _raw_spin_unlock_irqrestore+0x5b/0x60 [<ffffffff81250000>] ? irq_domain_set_hwirq_and_chip+0x30/0xb0 [<ffffffff81256339>] ? debug_lockdep_rcu_enabled+0x39/0x40 [<ffffffff812178c0>] ? __lock_is_held+0x90/0x130 [<ffffffff81196877>] process_one_work+0x567/0xec0 [...] Afterwards, xhci reports some functional errors: xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion code 0x11. xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion code 0x11. usb 4-3: device not accepting address 2, error -22 Fix this by not overwriting the port1 argument in usb_alloc_dev(), but storing the raw port number as required by OF in an additional variable, raw_port. Fixes: 69bec7259853 ("USB: core: let USB device know device node") Signed-off-by: Nicolai Stange <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-03-18USB: iowarrior: fix oops with malicious USB descriptorsJosh Boyer1-0/+6
The iowarrior driver expects at least one valid endpoint. If given malicious descriptors that specify 0 for the number of endpoints, it will crash in the probe function. Ensure there is at least one endpoint on the interface before using it. The full report of this issue can be found here: http://seclists.org/bugtraq/2016/Mar/87 Reported-by: Ralf Spenneberg <[email protected]> Cc: stable <[email protected]> Signed-off-by: Josh Boyer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-03-18nfsd: block and scsi layout drivers need to depend on CONFIG_BLOCKChristoph Hellwig1-2/+2
Signed-off-by: Christoph Hellwig <[email protected]> Reported-by: Randy Dunlap <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2016-03-18nfsd: add SCSI layout supportChristoph Hellwig11-8/+358
This is a simple extension to the block layout driver to use SCSI persistent reservations for access control and fencing, as well as SCSI VPD pages for device identification. For this we need to pass the nfs4_client to the proc_getdeviceinfo method to generate the reservation key, and add a new fence_client method to allow for fence actions in the layout driver. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2016-03-18nfsd: move some blocklayout codeChristoph Hellwig1-40/+50
Trivial reorganization, no change in behavior. Move some code around, pull some code out of block layoutcommit that will be useful for the scsi layout. [[email protected]: split off from "nfsd: add SCSI layout support"] Signed-off-by: J. Bruce Fields <[email protected]>
2016-03-18nfsd: add a new config option for the block layout driverChristoph Hellwig7-8/+20
Split the config symbols into a generic pNFS one, which is invisible and gets selected by the layout drivers, and one for the block layout driver. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2016-03-18nfs/blocklayout: add SCSI layout supportChristoph Hellwig5-25/+238
This is a trivial extension to the block layout driver to support the new SCSI layouts draft. There are three changes: - device identifcation through the SCSI VPD page. This allows us to directly use the udev generated persistent device names instead of requiring an expensive lookup by crawling every block device node in /dev and reading a signature for it. - use of SCSI persistent reservations to protect device access and allow for robust fencing. On the client sides this just means registering and unregistering a server supplied key. - an optimized LAYOUTCOMMIT payload that doesn't send unessecary fields to the server. Signed-off-by: Christoph Hellwig <[email protected]> Acked-by: Trond Myklebust <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2016-03-18i2c: octeon: Support I2C_M_RECV_LENDavid Daney1-5/+17
If I2C_M_RECV_LEN is set consider the length byte. Signed-off-by: David Daney <[email protected]> Signed-off-by: Jan Glauber <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2016-03-18i2c: octeon: Cleanup resource allocation codeJan Glauber1-15/+3
Remove resource values from struct i2c_octeon and use devm_ioremap_resource helper. Signed-off-by: Jan Glauber <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2016-03-18i2c: octeon: Cleanup i2c-octeon driverJan Glauber1-106/+84
Cleanup only without functional change. - removed DRV_VERSION - defines: use defines instead of plain values, use BIT_ULL macro, add comments - rename waitqueue return value to time_left - sort local variables by length - fix indentation and whitespace errors - make function return void if the result is not used (octeon_i2c_stop, octeon_i2c_set_clock) - remove debug code from octeon_i2c_stop - renamed some functions for readability - update copyright Signed-off-by: Jan Glauber <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2016-03-18of: Add vendor prefix for eGalax_eMPIA Technology IncFabio Estevam1-0/+1
eGalax_eMPIA Technology Inc (EETI) is a company specialized in touchscreen controller solutions. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2016-03-18tracing: Fix return while holding a lock in register_tracer()Chunyu Hu1-2/+4
commit d39cdd2036a6 ("tracing: Make tracer_flags use the right set_flag callback") introduces a potential mutex deadlock issue, as it forgets to free the mutex when allocaing the tracer_flags gets fail. The issue was found by Dan Carpenter through Smatch static code check tool. Link: http://lkml.kernel.org/r/[email protected] Fixes: d39cdd2036a6 ("tracing: Make tracer_flags use the right set_flag callback") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Chunyu Hu <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2016-03-18ftrace: Use kasprintf() in ftrace_profile_tracefs()Geliang Tang1-3/+1
Use kasprintf() instead of kmalloc() and snprintf(). Link: http://lkml.kernel.org/r/135a7bc36e51fd9eaa57124dd2140285b771f738.1458050835.git.geliangtang@163.com Acked-by: Namhyung Kim <[email protected]> Signed-off-by: Geliang Tang <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2016-03-18ftrace: Update dynamic ftrace calls only if necessaryJiri Olsa1-5/+5
Currently dynamic ftrace calls are updated any time the ftrace_ops is un/registered. If we do this update only when it's needed, we save lot of time for perf system wide ftrace function sampling/counting. The reason is that for system wide sampling/counting, perf creates event for each cpu in the system. Each event then registers separate copy of ftrace_ops, which ends up in FTRACE_UPDATE_CALLS updates. On servers with many cpus that means serious stall (240 cpus server): Counting: # time ./perf stat -e ftrace:function -a sleep 1 Performance counter stats for 'system wide': 370,663 ftrace:function 1.401427505 seconds time elapsed real 3m51.743s user 0m0.023s sys 3m48.569s Sampling: # time ./perf record -e ftrace:function -a sleep 1 [ perf record: Woken up 0 times to write data ] Warning: Processed 141200 events and lost 5 chunks! [ perf record: Captured and wrote 10.703 MB perf.data (135950 samples) ] real 2m31.429s user 0m0.213s sys 2m29.494s There's no reason to do the FTRACE_UPDATE_CALLS update for each event in perf case, because all the ftrace_ops always share the same filter, so the updated calls are always the same. It's required that only first ftrace_ops registration does the FTRACE_UPDATE_CALLS update (also sometimes the second if the first one used the trampoline), but the rest can be only cheaply linked into the ftrace_ops list. Counting: # time ./perf stat -e ftrace:function -a sleep 1 Performance counter stats for 'system wide': 398,571 ftrace:function 1.377503733 seconds time elapsed real 0m2.787s user 0m0.005s sys 0m1.883s Sampling: # time ./perf record -e ftrace:function -a sleep 1 [ perf record: Woken up 0 times to write data ] Warning: Processed 261730 events and lost 9 chunks! [ perf record: Captured and wrote 19.907 MB perf.data (256293 samples) ] real 1m31.948s user 0m0.309s sys 1m32.051s Link: http://lkml.kernel.org/r/[email protected] Acked-by: Namhyung Kim <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2016-03-18ftrace: Make ftrace_hash_rec_enable return update boolJiri Olsa1-10/+17
Change __ftrace_hash_rec_update to return true in case we need to update dynamic ftrace call records. It return false in case no update is needed. Link: http://lkml.kernel.org/r/[email protected] Acked-by: Namhyung Kim <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2016-03-18ALSA: hda - Really restrict i915 notifier to HSW+Takashi Iwai1-7/+17
The commit [b62232d429fa: ALSA: hda - Limit i915 HDMI binding only for HSW and later] tried to limit the usage of i915 audio notifier to the recent Intel models and switch to the old method on pre-Haswell models. However, it assumed that the i915 component binding hasn't been done on such models, and the assumption was wrong: namely, Baytrail had already the i915 component binding due to powerwell control. Thus, the workaround wasn't applied to Baytrail. For fixing this properly, this patch introduces a new flag indicating the usage of audio notifier and codec_has_acomp() refers to this flag instead of checking the existence of audio component. Reported-by: Ville Syrjälä <[email protected]> Cc: <[email protected]> # v4.5 Signed-off-by: Takashi Iwai <[email protected]>
2016-03-18x86/irq: Cure live lock in fixup_irqs()Thomas Gleixner2-18/+71
Harry reported, that he's able to trigger a system freeze with cpu hot unplug. The freeze turned out to be a live lock caused by recent changes in irq_force_complete_move(). When fixup_irqs() and from there irq_force_complete_move() is called on the dying cpu, then all other cpus are in stop machine an wait for the dying cpu to complete the teardown. If there is a move of an interrupt pending then irq_force_complete_move() sends the cleanup IPI to the cpus in the old_domain mask and waits for them to clear the mask. That's obviously impossible as those cpus are firmly stuck in stop machine with interrupts disabled. I should have known that, but I completely overlooked it being concentrated on the locking issues around the vectors. And the existance of the call to __irq_complete_move() in the code, which actually sends the cleanup IPI made it reasonable to wait for that cleanup to complete. That call was bogus even before the recent changes as it was just a pointless distraction. We have to look at two cases: 1) The move_in_progress flag of the interrupt is set This means the ioapic has been updated with the new vector, but it has not fired yet. In theory there is a race: set_ioapic(new_vector) <-- Interrupt is raised before update is effective, i.e. it's raised on the old vector. So if the target cpu cannot handle that interrupt before the old vector is cleaned up, we get a spurious interrupt and in the worst case the ioapic irq line becomes stale, but my experiments so far have only resulted in spurious interrupts. But in case of cpu hotplug this should be a non issue because if the affinity update happens right before all cpus rendevouz in stop machine, there is no way that the interrupt can be blocked on the target cpu because all cpus loops first with interrupts enabled in stop machine, so the old vector is not yet cleaned up when the interrupt fires. So the only way to run into this issue is if the delivery of the interrupt on the apic/system bus would be delayed beyond the point where the target cpu disables interrupts in stop machine. I doubt that it can happen, but at least there is a theroretical chance. Virtualization might be able to expose this, but AFAICT the IOAPIC emulation is not as stupid as the real hardware. I've spent quite some time over the weekend to enforce that situation, though I was not able to trigger the delayed case. 2) The move_in_progress flag is not set and the old_domain cpu mask is not empty. That means, that an interrupt was delivered after the change and the cleanup IPI has been sent to the cpus in old_domain, but not all CPUs have responded to it yet. In both cases we can assume that the next interrupt will arrive on the new vector, so we can cleanup the old vectors on the cpus in the old_domain cpu mask. Fixes: 98229aa36caa "x86/irq: Plug vector cleanup race" Reported-by: Harry Junior <[email protected]> Tested-by: Tony Luck <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Joe Lawrence <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Ben Hutchings <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603140931430.3657@nanos Signed-off-by: Thomas Gleixner <[email protected]>
2016-03-18x86/tsc: Prevent NULL pointer deref in calibrate_delay_is_known()Thomas Gleixner1-1/+5
The topology_core_cpumask is used to find a neighbour cpu in calibrate_delay_is_known(). It might not be allocated at the first invocation of that function on the boot cpu, when CONFIG_CPUMASK_OFFSTACK is set. The mask is allocated later in native_smp_prepare_cpus. As a consequence the underlying find_next_bit() call dereferences a NULL pointer. Add a proper check to prevent this. Fixes: c25323c07345 "x86/tsc: Use topology functions" Reported-and-tested-by: Richard W.M. Jones <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Josh Boyer <[email protected]> Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603180843270.3978@nanos Signed-off-by: Thomas Gleixner <[email protected]>
2016-03-18x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt()Dave Jones1-1/+1
Since 4.4, I've been able to trigger this occasionally: =============================== [ INFO: suspicious RCU usage. ] 4.5.0-rc7-think+ #3 Not tainted Cc: Andi Kleen <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> ------------------------------- ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 1 RCU used illegally from extended quiescent state! no locks held by swapper/3/0. stack backtrace: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3 ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6 ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60 Call Trace: <IRQ> [<ffffffff92560c2a>] dump_stack+0x67/0x9d [<ffffffff921376a6>] lockdep_rcu_suspicious+0xe6/0x100 [<ffffffff925ae7a7>] do_trace_write_msr+0x127/0x1a0 [<ffffffff92061c83>] native_apic_msr_eoi_write+0x23/0x30 [<ffffffff92054408>] smp_trace_call_function_interrupt+0x38/0x360 [<ffffffff92d1ca60>] trace_call_function_interrupt+0x90/0xa0 <EOI> [<ffffffff92ac5124>] ? cpuidle_enter_state+0x1b4/0x520 Move the entering_irq() call before ack_APIC_irq(), because entering_irq() tells the RCU susbstems to end the extended quiescent state, so that the following trace call in ack_APIC_irq() works correctly. Suggested-by: Andi Kleen <[email protected]> Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()" Signed-off-by: Dave Jones <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected]
2016-03-18ipmi: do not probe ACPI devices if si_tryacpi is unsetJoe Lawrence1-0/+3
Extend the tryacpi module parameter to turn off acpi_ipmi_probe such that hard-coded options (type, ports, address, etc.) have complete control over the smi_info data structures setup by the driver. Signed-off-by: Joe Lawrence <[email protected]> Signed-off-by: Corey Minyard <[email protected]>
2016-03-18ipmi_si: Avoid a wrong long timeout on transaction doneCorey Minyard1-2/+2
Under some circumstances, the IPMI state machine could return a call without delay option but the driver would still do a long delay because the result wasn't checked. Instead of calling the state machine after transaction done, just go back to the top of the processing to start over. Signed-off-by: Corey Minyard <[email protected]>
2016-03-18ipmi_si: Fix module parameter doc namesCorey Minyard1-2/+2
Several were tryacpi instead of their actual values. Signed-off-by: Corey Minyard <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.