Searched hist:5487 (Results 1 - 13 of 13) sorted by relevance

/linux-master/tools/tracing/rtla/src/
H A Dtrace.hdiff 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 Dtrace.cdiff 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 Ddma.hdiff 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 Dquirks.cdiff 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 Dhub.cdiff 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 Dcpu-features.hdiff 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 Dradeon_cs.cdiff 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 Dproc-v7.Sdiff 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 Dqcom_geni_serial.cdiff 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 De820.cdiff 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 Dinit.cdiff 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 DKconfigdiff 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 Dmemory.cdiff 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