- 10 Nov, 2016 1 commit
-
-
David Wu authored
commit 399c168a upstream. We found a bug that i2c transfer sometimes failed on 3066a board with stabel-4.8, the con register would be updated by uninitialized tuning value, it made the i2c transfer failed. So give the tuning value to be zero during rk3x_i2c_v0_calc_timings. Signed-off-by:
David Wu <david.wu@rock-chips.com> Tested-by:
Andy Yan <andy.yan@rock-chips.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 31 Oct, 2016 39 commits
-
-
Greg Kroah-Hartman authored
-
Vishal Verma authored
commit e046114a upstream. nvdimm_clear_poison cleared the user-visible badblocks, and sent commands to the NVDIMM to clear the areas marked as 'poison', but it neglected to clear the same areas from the internal poison_list which is used to marshal ARS results before sorting them by namespace. As a result, once on-demand ARS functionality was added: 37b137ff nfit, libnvdimm: allow an ARS scrub to be triggered on demand A scrub triggered from either sysfs or an MCE was found to be adding stale entries that had been cleared from gendisk->badblocks, but were still present in nvdimm_bus->poison_list. Additionally, the stale entries could be triggered into producing stale disk->badblocks by simply disabling and re-enabling the namespace or region. This adds the missing step of clearing poison_list entries when clearing poison, so that it is always in sync with badblocks. Fixes: 37b137ff ("nfit, libnvdimm: allow an ARS scrub to be triggered on demand") Signed-off-by:
Vishal Verma <vishal.l.verma@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Lorenzo Pieralisi authored
commit 13f392eb upstream. On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI tegra host bridge driver adds the PCI IO resource retrieved from firmware to the host bridge resource windows even if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Add the PCI host bridge driver pci_remap_iospace() failure path and do not add the corresponding PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, fixing the issue. Fixes: e6e9f471 ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one") Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Lorenzo Pieralisi authored
commit bcd7b718 upstream. On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI designware host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: cbce7900 ("PCI: designware: Make driver arch-agnostic") Signed-off-by:
-
Lorenzo Pieralisi authored
commit 53f4f7ee upstream. On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI versatile host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: b7e78170 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver") Signed-off-by:
-
Lorenzo Pieralisi authored
commit 43281ede upstream. On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI common host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: 4e64dbe2 ("PCI: generic: Expose pci_host_common_probe() for use by other drivers") Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Lorenzo Pieralisi authored
commit db047f8a upstream. On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridge's memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI aardvark host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: 8c39d710 ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by:
-
Lorenzo Pieralisi authored
commit 5e8c8732 upstream. On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI rcar host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: 5d2917d4 ("PCI: rcar: Convert to DT resource parsing API") Signed-off-by:
-
Javier Martinez Canillas authored
commit 0b965a13 upstream. Commit b8d368ca ("ARM: dts: omap3: overo: remove unneded unit names in display nodes") removed the unit names for all Overo display nodes that didn't have a reg property. But the display in arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi does have a reg property so the correct fix was to make the unit name match the value of the reg property, instead of removing it. This patch fixes the following DTC warning for boards using this dtsi: "ocp/spi@48098000/display has a reg or ranges property, but no unit name" Fixes: b8d368ca ("ARM: dts: omap3: overo: remove unneded unit names in display nodes") Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Linus Walleij authored
commit c4ad7256 upstream. The ethernet version in the earlier RealView EB variants is LAN91C111 and not LAN9118 according to ARM DUI 0303E "RealView Emulation Baseboard User Guide" page 3-57. Make sure that this is used for the base variant of the board. As the DT bindings for LAN91C111 does not specify any power supplies, these need to be deleted from the DTS file. Fixes: 2440d29d ("ARM: dts: realview: support all the RealView EB board variants") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jon Mason authored
commit c53beb47 upstream. The BCM958625HR board has 2GB of RAM available. Increase the amount from 512MB to 2GB and add the device type to the memory entry. Fixes: 9a4865d4 ("ARM: dts: NSP: Specify RAM amount for BCM958625HR board") Signed-off-by:
Jon Mason <jon.mason@broadcom.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Robert Jarzmik authored
commit ca26475b upstream. The commit 9bf448c6 ("ARM: pxa: use generic gpio operation instead of gpio register") from Oct 17, 2011, leads to the following static checker warning: arch/arm/mach-pxa/spitz_pm.c:172 spitz_charger_wakeup() warn: double left shift '!gpio_get_value(SPITZ_GPIO_KEY_INT) << (1 << ((SPITZ_GPIO_KEY_INT) & 31))' As Dan reported, the value is shifted three times : - once by gpio_get_value(), which returns either 0 or BIT(gpio) - once by the shift operation '<<' - a last time by GPIO_bit(gpio) which is BIT(gpio) Therefore the calculation lead to a chained or operator of : - (1 << gpio) << (1 << gpio) = (2^gpio)^gpio = 2 ^ (gpio * gpio) It is be sheer luck the former statement works, only because each gpio used is strictly smaller than 6, and therefore 2^(gpio^2) never overflows a 32 bits value, and because it is used as a boolean value to check a gpio activation. As the xxx_charger_wakeup() functions are used as a true/false detection mechanism, take that opportunity to change their prototypes from integer return value to boolean one. Fixes: 9bf448c6 ("ARM: pxa: use generic gpio operation instead of gpio register") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Joe Perches <joe@perches.com> Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Robert Jarzmik authored
commit 9ba63e3c upstream. Since its initial commit, the driver is buggy for multiple interrupts handling. The translation from the former lubbock.c file was not complete, and might stall all interrupt handling when multiple interrupts occur. This is especially true when inside the interrupt handler and if a new interrupt comes and is not handled, leaving the output line still held, and not creating a transition as the GPIO block behind would expect to trigger another cplds_irq_handler() call. For the record, the hardware is working as follows. The interrupt mechanism relies on : - one status register - one mask register Let's suppose the input irq lines are called : - i_sa1111 - i_lan91x - i_mmc_cd Let's suppose the status register for each irq line is called : - status_sa1111 - status_lan91x - status_mmc_cd Let's suppose the interrupt mask for each irq line is called : - irqen_sa1111 - irqen_lan91x - irqen_mmc_cd Let's suppose the output irq line, connected to GPIO0 is called : - o_gpio0 The behavior is as follows : - o_gpio0 = not((status_sa1111 & irqen_sa1111) | (status_lan91x & irqen_lan91x) | (status_mmc_cd & irqen_mmc_cd)) => this is a N-to-1 NOR gate and multiple AND gates - irqen_* is exactly as programmed by a write to the FPGA - status_* behavior is governed by a bi-stable D flip-flop => on next FPGA clock : - if i_xxx is high, status_xxx becomes 1 - if i_xxx is low, status_xxx remains as it is - if software sets status_xxx to 0, the D flip-flop is reset => status_xxx becomes 0 => on next FPGA clock cycle, if i_xxx is high, status_xxx becomes 1 again Fixes: fc9e38c0 ("ARM: pxa: lubbock: use new pxa_cplds driver") Reported-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Christophe Leroy authored
commit 6b8cb66a upstream. On some CPUs like the 8xx, _PAGE_RW hence _PAGE_WRITE is defined as 0 and _PAGE_RO has to be set when a page is not writable _PAGE_RO is defined by default in pte-common.h, however BOOK3S/64 doesn't include that file so _PAGE_RO has to be defined explicitly in book3s/64/pgtable.h Fixes: a7b9f671 ("powerpc32: adds handling of _PAGE_RO") Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Pan Xinhui authored
commit 11b7e154 upstream. When we merge two contiguous partitions whose signatures are marked NVRAM_SIG_FREE, We need update prev's length and checksum, then write it to nvram, not cur's. So lets fix this mistake now. Also use memset instead of strncpy to set the partition's name. It's more readable if we want to fill up with duplicate chars . Fixes: fa2b4e54 ("powerpc/nvram: Improve partition removal") Signed-off-by:
Pan Xinhui <xinhui.pan@linux.vnet.ibm.com> Signed-off-by:
-
Cyril Bur authored
commit b0f16b46 upstream. giveup_all() causes FPU/VMX/VSX facilities to be disabled in a threads MSR. If the thread performing the giveup was transactional, the kernel must record which facilities were in use before the giveup as the thread must have these facilities re-enabled on return to userspace. >From process.c: /* * This is called if we are on the way out to userspace and the * TIF_RESTORE_TM flag is set. It checks if we need to reload * FP and/or vector state and does so if necessary. * If userspace is inside a transaction (whether active or * suspended) and FP/VMX/VSX instructions have ever been enabled * inside that transaction, then we have to keep them enabled * and keep the FP/VMX/VSX state loaded while ever the transaction * continues. The reason is that if we didn't, and subsequently * got a FP/VMX/VSX unavailable interrupt inside a transaction, * we don't know whether it's the same transaction, and thus we * don't know which of the checkpointed state and the transactional * state to use. */ Calling check_if_tm_restore_required() will set TIF_RESTORE_TM and save the MSR if needed. Fixes: c2085059 ("powerpc: create giveup_all()") Signed-off-by:
Cyril Bur <cyrilbur@gmail.com> Signed-off-by:
-
Cyril Bur authored
commit dc16b553 upstream. Comment from arch/powerpc/kernel/process.c:967: If userspace is inside a transaction (whether active or suspended) and FP/VMX/VSX instructions have ever been enabled inside that transaction, then we have to keep them enabled and keep the FP/VMX/VSX state loaded while ever the transaction continues. The reason is that if we didn't, and subsequently got a FP/VMX/VSX unavailable interrupt inside a transaction, we don't know whether it's the same transaction, and thus we don't know which of the checkpointed state and the ransactional state to use. restore_math() restore_fp() and restore_altivec() currently may not restore the registers. It doesn't appear that this is more serious than a performance penalty. If the math registers aren't restored the userspace thread will still be run with the facility disabled. Userspace will not be able to read invalid values. On the first access it will take an facility unavailable exception and the kernel will detected an active transaction, at which point it will abort the transaction. There is the possibility for a pathological case preventing any progress by transactions, however, transactions are never guaranteed to make progress. Fixes: 70fe3d98 ("powerpc: Restore FPU/VEC/VSX if previously used") Signed-off-by:
-
Johannes Thumshirn authored
commit 0d667f72 upstream. In _scsih_io_done() we test if the ioc->logging_level does _not_ have the MPT_DEBUG_REPLY bit set and if it hasn't we print the debug messages. This unfortunately is the wrong way around. Note, the actual bug is older than af009411 but this commit removed the CONFIG_SCSI_MPT3SAS_LOGGING Kconfig option which hid the bug. Fixes: af009411 'mpt2sas, mpt3sas: Remove SCSI_MPTXSAS_LOGGING entry from Kconfig' Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Acked-by:
Chaitra P B <chaitra.basappa@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
John Crispin authored
commit 6bcf3f63 upstream. The following commit introduced a regression by not properly masking the calculated value. Fixes: 47a01ee9 ("pinctrl: qcom: Clear all function selection bits") Signed-off-by:
John Crispin <john@phrozen.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by:
-
Chen-Yu Tsai authored
commit 06ad11be upstream. The R_PIO device node is missing #interrupt-cells, which causes interrupt parsing to fail to match it as a valid interrupt controller. Add #interrupt-cells to it. Also remove the unnecesary #address-cells and #size-cells. Fixes: 1ac56a6d ("ARM: dts: sun9i: Add A80 R_PIO pin controller device node") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Luca Coelho authored
commit 75cfe338 upstream. We were assigning the return value of iwl_mvm_ctdp_command() to a variable, but never checking it. If this command fails, we should not allow the interface up process to proceed, since it is potentially dangerous to ignore thermal management requirements. Fixes: commit 5c89e7bc ("iwlwifi: mvm: add registration to cooling device") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Sara Sharon authored
commit 341d7eb8 upstream. AP queue is properly released, but P2P queue isn't. Fixes: commit 4c965139 ("iwlwifi: mvm: support p2p device frames tx on dqa queue #2") Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
-
Sara Sharon authored
commit 9a73a7d2 upstream. On default queue we will not receive frame release notification, but the BAR itself. Upon receiving the BAR driver should look at the NSSN and adjust window accordingly. Fixes: b915c101 ("iwlwifi: mvm: add reorder buffer per queue") Signed-off-by:
-
Liad Kaufman authored
commit a0315dea upstream. When a STA is removed in DQA mode, if no traffic went through its reserved queue, the txq continues to be marked as reserved and no STA can use it. Make sure that in such a case the reserved queue is marked as free when the STA is removed. Fixes: commit 24afba76 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues") Signed-off-by:
Liad Kaufman <liad.kaufman@intel.com> Signed-off-by:
-
Sara Sharon authored
commit ca3b9c6b upstream. Since the SCD_QUEUE_CFG command was introduced the driver calls iwl_trans_txq_enable_cfg() with a NULL for scd_cfg parameter. This makes the transport avoid writing to the SCD pointers, since it can cause races with firmware, which is also accessing the registers. The transport only updates the write pointer in that case. Fix a wrong call to iwl_trans_txq_enable() which caused a scd_cfg parameter to be sent to transport, resulting with an access to SCD registers. Fixes: 58f2cc57 ("iwlwifi: mvm: support dqa-mode scd queue redirection") Signed-off-by:
-
Liad Kaufman authored
commit 7585c354 upstream. In iwl_mvm_rx_tx_cmd_single(), when checking if a given TID is aggregated, the driver doesn't check whether or not the queue itself can be aggregated. For example, a management queue might be marked as aggregated if TID 0 is aggregated on a (different) data queue. Make sure that mgmt frames are sent with TID IWL_TID_NON_QOS, and in this way make sure no mixups of this sort happen. Fixes: commit 24afba76 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues") Signed-off-by:
-
Haim Dreyfuss authored
commit a6c934b3 upstream. In 9000 family products we added an option to let the OEM fuse the mac address via registers. If these registers are zeroed we use the OTP address instead. Make sure that the address provided by the OEM is valid and, if not, fall back to the OTP address as well. Fixes: commit 17c867bf ("iwlwifi: add support for getting HW address from CSR") Signed-off-by:
Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit 432746f8 upstream. When we call symbol__fixup_duplicate() we use algorithms to pick the "best" symbols for cases where there are various functions/aliases to an address, and those check zero size symbols, which, before calling symbol__fixup_end() are _all_ symbols in a just parsed kallsyms file. So first fixup the end, then fixup the duplicates. Found while trying to figure out why 'perf test vmlinux' failed, see the output of 'perf test -v vmlinux' to see cases where the symbols picked as best for vmlinux don't match the ones picked for kallsyms. Cc: Anton Blanchard <anton@samba.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Fixes: 694bf407 ("perf symbols: Add some heuristics for choosing the best duplicate symbol") Link: http://lkml.kernel.org/n/tip-rxqvdgr0mqjdxee0kf8i2ufn@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit c97b40e4 upstream. We can allow aliases to be kept, but we were checking this just when loading vmlinux files, be consistent, do it for any symbol table loading code that calls symbol__fixup_duplicate() by making this function check .allow_aliases instead. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Fixes: 680d926a ("perf symbols: Allow symbol alias when loading map for symbol name") Link: http://lkml.kernel.org/n/tip-z0avp0s6cfjckc4xj3pdfjdz@git.kernel.orgSigned-off-by:
-
Namhyung Kim authored
commit 9a6ad25b upstream. When the --hierarchy option is used, each entry has its own hpp_list to show the result. But it is not updating the width of each column for perf-top. The perf-report command has no problem since it resets it during header display. $ sudo perf top --hierarchy --stdio PerfTop: 160 irqs/sec kernel:38.8% exact: 100.0% [4000Hz cycles:pp], (all, 12 CPUs) ---------------------------------------------------------------------- 52.32% perf 24.74% [.] __symbols__insert 5.62% [.] rb_next 5.14% [.] dso__load_sym Move the code into hists__fprintf() so that it can be called always. Also it'd be better to put similar code together. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Tested-by:
-
Namhyung Kim authored
commit 5ff3e7a2 upstream. When --hierarchy option is used, each entry has its own hpp_list to show the result. But it missed to update width of each column. Before: - 46.29% 48.12% netctl-auto + 31.44% 29.25% [kernel.vmlinux] + 8.52% 11.55% libc-2.22.so + 5.19% 6.91% bash + 10.75% 11.83% wpa_cli + 8.25% 2.23% swapper + 6.45% 5.40% tr + 4.81% 8.09% awk + 4.15% 2.85% firefox + 3.86% 2.53% sh After: - 46.29% 48.12% netctl-auto + 31.44% 29.25% [kernel.vmlinux] + 8.52% 11.55% libc-2.22.so + 5.19% 6.91% bash + 10.75% 11.83% wpa_cli + 8.25% 2.23% swapper + 6.45% 5.40% tr + 4.81% 8.09% awk + 4.15% 2.85% firefox + 3.86% 2.53% sh Committer note: Full testing instructions: 1) Record with an event group: $ perf record -e '{cycles,instructions}' make -j4 2) Use report in hierarchy mode, to get a few expanded trees on the same screen, use --percent-limit: $ perf report --hierarchy --percent-limit 0.5 Samples: 103K of event 'anon group { cycles:u, instructions:u }', Event count (approx.): 57317631725 Overhead Command / Shared Object / Symbol ◆ - 58.89% 55.12% cc1 ▒ - 50.26% 48.10% cc1 ▒ 3.61% 5.13% [.] _cpp_lex_token ▒ 2.58% 0.78% [.] ht_lookup_with_hash ▒ 1.31% 1.30% [.] ggc_internal_alloc ▒ 1.08% 2.25% [.] get_combined_adhoc_loc ▒ 1.01% 1.95% [.] ira_init ▒ 0.96% 1.78% [.] linemap_position_for_column ▒ 0.65% 1.01% [.] cpp_get_token_with_location ▒ - 7.52% 6.58% libc-2.23.so ▒ 1.70% 1.78% [.] _int_malloc ▒ 0.69% 0.75% [.] _int_free ▒ 0.67% 0.42% [.] malloc_consolidate ▒ - 0.58% 0.42% ld-2.23.so ▒ no entry >= 0.50% ▒ - 0.52% 0.03% [kernel.vmlinux] ▒ no entry >= 0.50% ▒ Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: 1b2dbbf4 ("perf hists: Use own hpp_list for hierarchy mode") Link: http://lkml.kernel.org/r/20160920053025.13989-1-namhyung@kernel.orgSigned-off-by:
-
Ravi Bangoria authored
commit 25b8592e upstream. 'make -C tools/perf build-test' is failing with below log for poewrpc. In file included from /tmp/tmp.3eEwmGlYaF/perf-4.8.0-rc4/tools/perf/perf.h:15:0, from util/cpumap.h:8, from util/env.c:1: /tmp/tmp.3eEwmGlYaF/perf-4.8.0-rc4/tools/perf/perf-sys.h:23:56: fatal error: ../../arch/powerpc/include/uapi/asm/unistd.h: No such file or directory compilation terminated. I bisected it and found it's failing from commit ad430729 ("Remove: kernel unistd*h files from perf's MANIFEST, not used"). Header file '../../arch/powerpc/include/uapi/asm/unistd.h' is included only for powerpc in tools/perf/perf-sys.h. By looking closly at commit history, I found little weird thing: Commit f2d9cae9 ("perf powerpc: Use uapi/unistd.h to fix build error") replaced 'asm/unistd.h' with 'uapi/asm/unistd.h' Commit d2709c7c ("perf: Make perf build for x86 with UAPI disintegration applied") removes all arch specific 'uapi/asm/unistd.h' for all archs and adds generic <asm/unistd.h>. Commit f0b9abfb ("Merge branch 'linus' into perf/core") again includes 'uapi/asm/unistd.h' for powerpc. Don't know how exactly this happened as this change is not part of commit also. Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1472630591-5089-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com Fixes: ad430729 ("Remove: kernel unistd*h files from perf's MANIFEST, not used") Signed-off-by:
-
Namhyung Kim authored
commit d9ea48bc upstream. Milian reported that the event group on TUI shows duplicated overhead. This was due to a bug on calculating hpp->buf position. The hpp_advance() was called from __hpp__slsmg_color_printf() on TUI but it's already called from the hpp__call_print_fn macro in __hpp__fmt(). The end result is that the print function returns number of bytes it printed but the buffer advanced twice of the length. This is generally not a problem since it doesn't need to access the buffer again. But with event group, overhead needs to be printed multiple times and hist_entry__snprintf_alignment() tries to fill the space with buffer after it printed. So it (brokenly) showed the last overhead again. The bug was there from the beginning, but I think it's only revealed when the alignment function was added. Reported-by:
Milian Wolff <milian.wolff@kdab.com> Signed-off-by:
-
Wang Nan authored
commit f2c8852e upstream. On ARM32 building it report following error when we build with libbabeltrace: util/data-convert-bt.c: In function 'add_bpf_output_values': util/data-convert-bt.c:440:3: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format] cc1: all warnings being treated as errors Fix it by changing %lu to %zu. Signed-off-by:
Wang Nan <wangnan0@huawei.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Zefan Li <lizefan@huawei.com> Cc: pi3orama@163.com Fixes: 6122d57e ("perf data: Support converting data from bpf_perf_event_output()") Link: http://lkml.kernel.org/r/1475035126-146587-1-git-send-email-wangnan0@huawei.comSigned-off-by:
-
Geert Uytterhoeven authored
commit 2cf9a578 upstream. clk-divider uses clk_readl()/clk_writel() everywhere, except in clk_divider_round_rate(), where plain readl() is used. Change this to clk_readl(), as it makes a difference on powerpc. Fixes: e6d5e7d9 ("clk-divider: Fix READ_ONLY when divider > 1") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Jean-Francois Moine authored
commit 3174b0c9 upstream. This patch reverts commit 023bd716 ("clk: skip unnecessary set_phase if nothing to do"), fixing two problems: * in some SoCs, the hardware phase delay depends on the rate ratio of the clock and its parent. So, changing this ratio may imply to set new hardware values, even if the logical delay is the same. * when the delay was the same as previously, an error was returned. Signed-off-by:
Jean-Francois Moine <moinejf@free.fr> Fixes: 023bd716 ("clk: skip unnecessary set_phase if nothing to do") Signed-off-by:
-
Stephen Boyd authored
commit f155d15b upstream. Before commit 0861e5b8 (clk: Add clk_hw OF clk providers, 2016-02-05) __of_clk_get_from_provider() would return an error pointer of the provider's choosing if there was a provider registered and EPROBE_DEFER otherwise. After that commit, it would return EPROBE_DEFER regardless of whether or not the provider returned an error. This is odd and can lead to behavior where clk consumers keep probe deferring when they should be seeing some other error. Let's restore the previous behavior where we only return EPROBE_DEFER when there isn't a provider in our of_clk_providers list. Otherwise, return the error from the last provider we find that matches the node. Reported-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Fixes: 0861e5b8 ("clk: Add clk_hw OF clk providers") Signed-off-by:
-
Tang Yuantian authored
commit 8964193f upstream. The offset of Core Cluster clock control/status register on cluster group V3 version is different from others, and should be plus 0x70000. Signed-off-by:
Tang Yuantian <yuantian.tang@nxp.com> Reviewed-by:
Scott Wood <oss@buserror.net> Fixes: 9e19ca2f ("clk: qoriq: Add ls2080a support.") Signed-off-by:
-
Srinivas Kandagatla authored
commit 6d91f2c0 upstream. This patch selects QCOM_GDSC Kconfig for msm8996 GCC and MMCC clock controllers, as these provide some of the gdscs on the SOC. Also selecting this config will make it align with other drivers which do the same. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Fixes: 52111672 ("clk: qcom: gdsc: Add GDSCs in msm8996 GCC") Fixes: 7e824d50 ("clk: qcom: gdsc: Add mmcc gdscs for msm8996 family") Signed-off-by:
-
