Searched hist:5487 (Results 1 - 13 of 13) sorted by relevance
/linux-master/tools/tracing/rtla/src/ | ||
H A D | trace.h | diff 5487b6ce Wed Mar 02 12:01:34 MST 2022 Daniel Bristot de Oliveira <bristot@kernel.org> rtla/trace: Add trace event filter helpers Add a set of helper functions to allow rtla tools to filter events in the trace instance. Link: https://lkml.kernel.org/r/12623b1684684549d53b90f4bf66fae44584fd14.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira <bristot@kernel.org> Cc: Clark Williams <williams@redhat.com> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> |
H A D | trace.c | diff 5487b6ce Wed Mar 02 12:01:34 MST 2022 Daniel Bristot de Oliveira <bristot@kernel.org> rtla/trace: Add trace event filter helpers Add a set of helper functions to allow rtla tools to filter events in the trace instance. Link: https://lkml.kernel.org/r/12623b1684684549d53b90f4bf66fae44584fd14.1646247211.git.bristot@kernel.org Cc: Daniel Bristot de Oliveira <bristot@kernel.org> Cc: Clark Williams <williams@redhat.com> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> |
/linux-master/arch/x86/include/asm/ | ||
H A D | dma.h | diff c072b90c Tue Dec 09 19:09:01 MST 2014 Xishi Qiu <qiuxishi@huawei.com> x86/mm: Fix zone ranges boot printout This is the usual physical memory layout boot printout: ... [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal [mem 0x100000000-0xc3fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0xbf78ffff] [ 0.000000] node 0: [mem 0x100000000-0x63fffffff] [ 0.000000] node 1: [mem 0x640000000-0xc3fffffff] ... This is the log when we set "mem=2G" on the boot cmdline: ... [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] // should be 0x7fffffff, right? [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0x7fffffff] ... This patch fixes the printout, the following log shows the right ranges: ... [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0x7fffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0x7fffffff] ... Suggested-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Xishi Qiu <qiuxishi@huawei.com> Cc: Linux MM <linux-mm@kvack.org> Cc: <dave@sr71.net> Cc: Rik van Riel <riel@redhat.com> Link: http://lkml.kernel.org/r/5487AB3D.6070306@huawei.com Signed-off-by: Ingo Molnar <mingo@kernel.org> |
/linux-master/drivers/usb/core/ | ||
H A D | quirks.c | diff ca91fd8c Tue Apr 20 11:46:51 MDT 2021 Chris Chiu <chris.chiu@canonical.com> USB: Add reset-resume quirk for WD19's Realtek Hub Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work after the system resumes from suspend with remote wakeup enabled device connected: [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71) [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71) Information of this hub: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5 D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=5487 Rev= 1.47 S: Manufacturer=Dell Inc. S: Product=Dell dock C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms The failure results from the ETIMEDOUT by chance when turning on the suspend feature for the specified port of the hub. The port seems to be in an unknown state so the hub_activate during resume fails the hub_port_status, then the hub will fail to work. The quirky hub needs the reset-resume quirk to function correctly. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff ca91fd8c Tue Apr 20 11:46:51 MDT 2021 Chris Chiu <chris.chiu@canonical.com> USB: Add reset-resume quirk for WD19's Realtek Hub Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work after the system resumes from suspend with remote wakeup enabled device connected: [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71) [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71) Information of this hub: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5 D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=5487 Rev= 1.47 S: Manufacturer=Dell Inc. S: Product=Dell dock C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms The failure results from the ETIMEDOUT by chance when turning on the suspend feature for the specified port of the hub. The port seems to be in an unknown state so the hub_activate during resume fails the hub_port_status, then the hub will fail to work. The quirky hub needs the reset-resume quirk to function correctly. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
H A D | hub.c | diff 71424523 Thu May 13 10:54:04 MDT 2021 Chris Chiu <chris.chiu@canonical.com> USB: Verify the port status when timeout happens during port suspend On the Realtek high-speed Hub(0bda:5487), the port which has wakeup enabled_descendants will sometimes timeout when setting PORT_SUSPEND feature. After checking the PORT_SUSPEND bit in wPortStatus, it is already set which means the port has been suspended. We should treat it suspended to make sure it will be resumed correctly. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Link: https://lore.kernel.org/r/20210514045405.5261-2-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
/linux-master/arch/mips/include/asm/ | ||
H A D | cpu-features.h | diff 5487a7b6 Tue Jun 06 23:51:22 MDT 2023 Jiaxun Yang <jiaxun.yang@flygoat.com> MIPS: cpu-features: Use boot_cpu_type for CPU type based features Some CPU feature macros were using current_cpu_type to mark feature availability. However current_cpu_type will use smp_processor_id, which is prohibited under preemptable context. Since those features are all uniform on all CPUs in a SMP system, use boot_cpu_type instead of current_cpu_type to fix preemptable kernel. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> |
/linux-master/drivers/gpu/drm/radeon/ | ||
H A D | radeon_cs.c | diff 3fcb4f01 Mon Mar 01 23:42:12 MST 2021 Chen Li <chenli@uniontech.com> drm/radeon: Use kvmalloc for CS chunks The number of chunks/chunks_array may be passed in by userspace and can be large. It has been observed to cause kcalloc failures from trinity fuzzy test: WARNING: CPU: 0 PID: 5487 at mm/page_alloc.c:4385 __alloc_pages_nodemask+0x2d8/0x14d0 Obviously, the required order in this case is larger than MAX_ORDER. So, just use kvmalloc instead. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Chen Li <chenli@uniontech.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
/linux-master/arch/arm/mm/ | ||
H A D | proc-v7.S | diff 7ce236fc Thu Apr 30 10:06:09 MDT 2009 Catalin Marinas <catalin.marinas@arm.com> [ARM] 5487/1: ARM errata: Stale prediction on replaced interworking branch This patch adds the workaround for the 430973 Cortex-A8 (r1p0..r1p2) erratum. The BTAC/BTB is now flushed at every context switch. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> |
/linux-master/drivers/tty/serial/ | ||
H A D | qcom_geni_serial.c | diff a1b44ea3 Fri May 29 04:14:42 MDT 2020 satya priya <skakit@codeaurora.org> tty: serial: qcom_geni_serial: Add 51.2MHz frequency support To support BT use case over UART at baud rate of 3.2 Mbps, we need SE clocks to run at 51.2MHz frequency. Previously this frequency was not available in clk src, so, we were requesting for 102.4 MHz and dividing it internally by 2 to get 51.2MHz. As now 51.2MHz frequency is made available in clk src, adding this frequency to UART frequency table. We will save significant amount of power, if 51.2 is used because it belongs to LowSVS range whereas 102.4 fall into Nominal category. Signed-off-by: satya priya <skakit@codeaurora.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1590747282-5487-1-git-send-email-skakit@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
/linux-master/arch/x86/kernel/ | ||
H A D | e820.c | diff 29258cf4 Tue Dec 09 19:09:03 MST 2014 Xishi Qiu <qiuxishi@huawei.com> x86/mm: Use min() instead of min_t() in the e820 printout code The type of "MAX_DMA_PFN" and "xXx_pfn" are both unsigned long now, so use min() instead of min_t(). Suggested-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Xishi Qiu <qiuxishi@huawei.com> Cc: Linux MM <linux-mm@kvack.org> Cc: <dave@sr71.net> Cc: Rik van Riel <riel@redhat.com> Link: http://lkml.kernel.org/r/5487AB3F.7050807@huawei.com Signed-off-by: Ingo Molnar <mingo@kernel.org> |
/linux-master/arch/x86/mm/ | ||
H A D | init.c | diff c072b90c Tue Dec 09 19:09:01 MST 2014 Xishi Qiu <qiuxishi@huawei.com> x86/mm: Fix zone ranges boot printout This is the usual physical memory layout boot printout: ... [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal [mem 0x100000000-0xc3fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0xbf78ffff] [ 0.000000] node 0: [mem 0x100000000-0x63fffffff] [ 0.000000] node 1: [mem 0x640000000-0xc3fffffff] ... This is the log when we set "mem=2G" on the boot cmdline: ... [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] // should be 0x7fffffff, right? [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0x7fffffff] ... This patch fixes the printout, the following log shows the right ranges: ... [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0x7fffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0x7fffffff] ... Suggested-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Xishi Qiu <qiuxishi@huawei.com> Cc: Linux MM <linux-mm@kvack.org> Cc: <dave@sr71.net> Cc: Rik van Riel <riel@redhat.com> Link: http://lkml.kernel.org/r/5487AB3D.6070306@huawei.com Signed-off-by: Ingo Molnar <mingo@kernel.org> |
/linux-master/arch/arm/ | ||
H A D | Kconfig | diff 7ce236fc Thu Apr 30 10:06:09 MDT 2009 Catalin Marinas <catalin.marinas@arm.com> [ARM] 5487/1: ARM errata: Stale prediction on replaced interworking branch This patch adds the workaround for the 430973 Cortex-A8 (r1p0..r1p2) erratum. The BTAC/BTB is now flushed at every context switch. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> |
/linux-master/mm/ | ||
H A D | memory.c | diff 2c865995 Thu Mar 24 19:14:02 MDT 2022 Hugh Dickins <hughd@google.com> mm: unmap_mapping_range_tree() with i_mmap_rwsem shared Revert 48ec833b7851 ("Revert "mm/memory.c: share the i_mmap_rwsem"") to reinstate c8475d144abb ("mm/memory.c: share the i_mmap_rwsem"): the unmap_mapping_range family of functions do the unmapping of user pages (ultimately via zap_page_range_single) without modifying the interval tree itself, and unmapping races are necessarily guarded by page table lock, thus the i_mmap_rwsem should be shared in unmap_mapping_pages() and unmap_mapping_folio(). Commit 48ec833b7851 was intended as a short-term measure, allowing the other shared lock changes into 3.19 final, before investigating three trinity crashes, one of which had been bisected to commit c8475d144ab: [1] https://lkml.org/lkml/2014/11/14/342 https://lore.kernel.org/lkml/5466142C.60100@oracle.com/ [2] https://lkml.org/lkml/2014/12/22/213 https://lore.kernel.org/lkml/549832E2.8060609@oracle.com/ [3] https://lkml.org/lkml/2014/12/9/741 https://lore.kernel.org/lkml/5487ACC5.1010002@oracle.com/ Two of those were Bad page states: free_pages_prepare() found PG_mlocked still set - almost certain to have been fixed by 4.4 commit b87537d9e2fe ("mm: rmap use pte lock not mmap_sem to set PageMlocked"). The NULL deref on rwsem in [2]: unclear, only happened once, not bisected to c8475d144ab. No change to the i_mmap_lock_write() around __unmap_hugepage_range_final() in unmap_single_vma(): IIRC that's a special usage, helping to serialize hugetlbfs page table sharing, not to be dabbled with lightly. No change to other uses of i_mmap_lock_write() by hugetlbfs. I am not aware of any significant gains from the concurrency allowed by this commit: it is submitted more to resolve an ancient misunderstanding. Link: https://lkml.kernel.org/r/e4a5e356-6c87-47b2-3ce8-c2a95ae84e20@google.com Signed-off-by: Hugh Dickins <hughd@google.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Sasha Levin <sashal@kernel.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
Completed in 1936 milliseconds