upstream commit id: 04b4b00613
Commit 0ad9500e16 ("slub: prefetch next freelist pointer in
slab_alloc()") introduced prefetch_freepointer() because when other
cpu(s) freed objects into a page that current cpu owns, the freelist
link is hot on cpu(s) which freed objects and possibly very cold on
current cpu.
But if freelist link chain is hot on cpu(s) which freed objects, it's
better to invalidate that chain because they're not going to access
again within a short time.
So use prefetchw instead of prefetch. On supported architectures like
x86 and arm, it invalidates other copied instances of a cache line when
prefetching it.
Before:
Time: 91.677
Performance counter stats for 'hackbench -g 100 -l 10000':
1462938.07 msec cpu-clock # 15.908 CPUs utilized
18072550 context-switches # 12.354 K/sec
1018814 cpu-migrations # 696.416 /sec
104558 page-faults # 71.471 /sec
1580035699271 cycles # 1.080 GHz (54.51%)
2003670016013 instructions # 1.27 insn per cycle (54.31%)
5702204863 branch-misses (54.28%)
643368500985 cache-references # 439.778 M/sec (54.26%)
18475582235 cache-misses # 2.872 % of all cache refs (54.28%)
642206796636 L1-dcache-loads # 438.984 M/sec (46.87%)
18215813147 L1-dcache-load-misses # 2.84% of all L1-dcache accesses (46.83%)
653842996501 dTLB-loads # 446.938 M/sec (46.63%)
3227179675 dTLB-load-misses # 0.49% of all dTLB cache accesses (46.85%)
537531951350 iTLB-loads # 367.433 M/sec (54.33%)
114750630 iTLB-load-misses # 0.02% of all iTLB cache accesses (54.37%)
630135543177 L1-icache-loads # 430.733 M/sec (46.80%)
22923237620 L1-icache-load-misses # 3.64% of all L1-icache accesses (46.76%)
91.964452802 seconds time elapsed
43.416742000 seconds user
1422.441123000 seconds sys
After:
Time: 90.220
Performance counter stats for 'hackbench -g 100 -l 10000':
1437418.48 msec cpu-clock # 15.880 CPUs utilized
17694068 context-switches # 12.310 K/sec
958257 cpu-migrations # 666.651 /sec
100604 page-faults # 69.989 /sec
1583259429428 cycles # 1.101 GHz (54.57%)
2004002484935 instructions # 1.27 insn per cycle (54.37%)
5594202389 branch-misses (54.36%)
643113574524 cache-references # 447.409 M/sec (54.39%)
18233791870 cache-misses # 2.835 % of all cache refs (54.37%)
640205852062 L1-dcache-loads # 445.386 M/sec (46.75%)
17968160377 L1-dcache-load-misses # 2.81% of all L1-dcache accesses (46.79%)
651747432274 dTLB-loads # 453.415 M/sec (46.59%)
3127124271 dTLB-load-misses # 0.48% of all dTLB cache accesses (46.75%)
535395273064 iTLB-loads # 372.470 M/sec (54.38%)
113500056 iTLB-load-misses # 0.02% of all iTLB cache accesses (54.35%)
628871845924 L1-icache-loads # 437.501 M/sec (46.80%)
22585641203 L1-icache-load-misses # 3.59% of all L1-icache accesses (46.79%)
90.514819303 seconds time elapsed
43.877656000 seconds user
1397.176001000 seconds sys
[xuyu]:
The latency of 'hackbench -g 100 -l 10000' in a x86 guest with 8 CPU
and 16G memory is 92.81 (w/o this path) and 91.2018 (w/ this patch),
respectively.
Link: https://lkml.org/lkml/2021/10/8/598=20
Link: https://lkml.kernel.org/r/20211011144331.70084-1-42.hyeyoo@gmail.com
Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>
Reviewed-by: Gang Deng <gavin.dg@linux.alibaba.com>
Signed-off-by: johnnyaiai <johnnyaiai@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
Reviewed-by: robinlai <robinlai@tencent.com>
cause to packet hash to the same cpu.
Mask the call of hns3_set_rx_skb_rss_type function, let protocal
stack calculate hash value, this will scatter packet to different cpu.
commit 1756d7994a upstream
cgroup process migration permission checks are performed at write time as
whether a given operation is allowed or not is dependent on the content of
the write - the PID. This currently uses current's credentials which is a
potential security weakness as it may allow scenarios where a less
privileged process tricks a more privileged one into writing into a fd that
it created.
This patch makes both cgroup2 and cgroup1 process migration interfaces to
use the credentials saved at the time of open (file->f_cred) instead of
current's.
Reported-by: "Eric W. Biederman" <ebiederm@xmission.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 187fe84067 ("cgroup: require write perm on common ancestor when moving processes on the default hierarchy")
Reviewed-by: Michal Koutný <mkoutny@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Singed-off-by: Alex Shi <alexsshi@tencent.com>
Conflicts:
kernel/cgroup/cgroup.c
commit cc8f7fe1f5 upstream.
Add __GFP_ZERO flag for alloc_page in function bio_copy_kern to initialize
the buffer of a bio.
Signed-off-by: Haimin Zhang <tcs.kernel@gmail.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20220216084038.15635-1-tcs.kernel@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
[nobelbarakat: Backported to 5.4: Manually added __GFP_ZERO flag]
Signed-off-by: Nobel Barakat <nobelbarakat@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit f71f01394f upstream.
Interrupt handler bad_flp_intr() may cause a UAF on the recently freed
request just to increment the error count. There's no point keeping
that one in the request anyway, and since the interrupt handler uses a
static pointer to the error which cannot be kept in sync with the
pending request, better make it use a static error counter that's reset
for each new request. This reset now happens when entering
redo_fd_request() for a new request via set_next_request().
One initial concern about a single error counter was that errors on one
floppy drive could be reported on another one, but this problem is not
real given that the driver uses a single drive at a time, as that
PC-compatible controllers also have this limitation by using shared
signals. As such the error count is always for the "current" drive.
Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Tested-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit 2400617da7 upstream.
Split the current bounce buffering logic used with persistent grants
into it's own option, and allow enabling it independently of
persistent grants. This allows to reuse the same code paths to
perform the bounce buffering required to avoid leaking contiguous data
in shared pages not part of the request fragments.
Reporting whether the backend is to be trusted can be done using a
module parameter, or from the xenstore frontend path as set by the
toolstack when adding the device.
This is CVE-2022-33742, part of XSA-403.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit 2f446ffe9d upstream.
When allocating pages to be used for shared communication with the
backend always zero them, this avoids leaking unintended data present
on the pages.
This is CVE-2022-26365, part of XSA-403.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
Commit abf1fd5919 upstream.
It isn't enough to check whether a grant is still being in use by
calling gnttab_query_foreign_access(), as a mapping could be realized
by the other side just after having called that function.
In case the call was done in preparation of revoking a grant it is
better to do so via gnttab_end_foreign_access_ref() and check the
success of that operation instead.
For the ring allocation use alloc_pages_exact() in order to avoid
high order pages in case of a multi-page ring.
If a grant wasn't unmapped by the backend without persistent grants
being used, set the device state to "error".
This is CVE-2022-23036 / part of XSA-396.
Reported-by: Demi Marie Obenour <demi@invisiblethingslab.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit 0fd08a34e8 upstream.
The Xen blkfront driver is still vulnerable for an attack via excessive
number of events sent by the backend. Fix that by using lateeoi event
channels.
This is part of XSA-391
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit b94e4b147f upstream.
Today blkfront will trust the backend to send only sane response data.
In order to avoid privilege escalations or crashes in case of malicious
backends verify the data to be within expected limits. Especially make
sure that the response always references an outstanding request.
Introduce a new state of the ring BLKIF_STATE_ERROR which will be
switched to in case an inconsistency is being detected. Recovering from
this state is possible only via removing and adding the virtual device
again (e.g. via a suspend/resume cycle).
Make all warning messages issued due to valid error responses rate
limited in order to avoid message floods being triggered by a malicious
backend.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Link: https://lore.kernel.org/r/20210730103854.12681-4-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit 8f5a695d99 upstream.
In order to avoid a malicious backend being able to influence the local
copy of a request build the request locally first and then copy it to
the ring page instead of doing it the other way round as today.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Link: https://lore.kernel.org/r/20210730103854.12681-3-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit 71b66243f9 upstream.
In order to avoid problems in case the backend is modifying a response
on the ring page while the frontend has already seen it, just read the
response into a local buffer in one go and then operate on that buffer
only.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Link: https://lore.kernel.org/r/20210730103854.12681-2-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit 233087ca06 upstream.
Minh Yuan reported a concurrency use-after-free issue in the floppy code
between raw_cmd_ioctl and seek_interrupt.
[ It turns out this has been around, and that others have reported the
KASAN splats over the years, but Minh Yuan had a reproducer for it and
so gets primary credit for reporting it for this fix - Linus ]
The problem is, this driver tends to break very easily and nowadays,
nobody is expected to use FDRAWCMD anyway since it was used to
manipulate non-standard formats. The risk of breaking the driver is
higher than the risk presented by this race, and accessing the device
requires privileges anyway.
Let's just add a config option to completely disable this ioctl and
leave it disabled by default. Distros shouldn't use it, and only those
running on antique hardware might need to enable it.
Link: https://lore.kernel.org/all/000000000000b71cdd05d703f6bf@google.com/
Link: https://lore.kernel.org/lkml/CAKcFiNC=MfYVW-Jt9A3=FPJpTwCD2PL_ULNCpsCVE5s8ZeBQgQ@mail.gmail.com
Link: https://lore.kernel.org/all/CAEAjamu1FRhz6StCe_55XY5s389ZP_xmCF69k987En+1z53=eg@mail.gmail.com
Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
Reported-by: syzbot+8e8958586909d62b6840@syzkaller.appspotmail.com
Reported-by: cruise k <cruise4k@gmail.com>
Reported-by: Kyungtae Kim <kt0755@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Tested-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit 294f2fc6da upstream.
Currently, for all op verification we call __red_deduce_bounds() and
__red_bound_offset() but we only call __update_reg_bounds() in bitwise
ops. However, we could benefit from calling __update_reg_bounds() in
BPF_ADD, BPF_SUB, and BPF_MUL cases as well.
For example, a register with state 'R1_w=invP0' when we subtract from
it,
w1 -= 2
Before coerce we will now have an smin_value=S64_MIN, smax_value=U64_MAX
and unsigned bounds umin_value=0, umax_value=U64_MAX. These will then
be clamped to S32_MIN, U32_MAX values by coerce in the case of alu32 op
as done in above example. However tnum will be a constant because the
ALU op is done on a constant.
Without update_reg_bounds() we have a scenario where tnum is a const
but our unsigned bounds do not reflect this. By calling update_reg_bounds
after coerce to 32bit we further refine the umin_value to U64_MAX in the
alu64 case or U32_MAX in the alu32 case above.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/158507151689.15666.566796274289413203.stgit@john-Precision-5820-Tower
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Haisu Wang <haisuwang@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
commit b75cd21827 upstream.
During the PV driver life cycle the mappings are added to
the RB-tree by set_foreign_p2m_mapping(), which is called from
gnttab_map_refs() and are removed by clear_foreign_p2m_mapping()
which is called from gnttab_unmap_refs(). As both functions end
up calling __set_phys_to_machine_multi() which updates the RB-tree,
this function can be called concurrently.
There is already a "p2m_lock" to protect against concurrent accesses,
but the problem is that the first read of "phys_to_mach.rb_node"
in __set_phys_to_machine_multi() is not covered by it, so this might
lead to the incorrect mappings update (removing in our case) in RB-tree.
In my environment the related issue happens rarely and only when
PV net backend is running, the xen_add_phys_to_mach_entry() claims
that it cannot add new pfn <-> mfn mapping to the tree since it is
already exists which results in a failure when mapping foreign pages.
But there might be other bad consequences related to the non-protected
root reads such use-after-free, etc.
While at it, also fix the similar usage in __pfn_to_mfn(), so
initialize "struct rb_node *n" with the "p2m_lock" held in both
functions to avoid possible bad consequences.
This is CVE-2022-33744 / XSA-406.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
Reviewed-by: samuelliao <samuelliao@tencent.com>
commit 330f4c53d3 upstream.
It was missing a semicolon.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Fixes: 25875aa71d ("ARM: include unprivileged BPF status in Spectre V2 reporting").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
Reviewed-by: samuelliao <samuelliao@tencent.com>
commit 25875aa71d upstream.
The mitigations for Spectre-BHB are only applied when an exception
is taken, but when unprivileged BPF is enabled, userspace can
load BPF programs that can be used to exploit the problem.
When unprivileged BPF is enabled, report the vulnerable status via
the spectre_v2 sysfs file.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
Reviewed-by: samuelliao <samuelliao@tencent.com>
commit 9dd78194a3 upstream.
As per other architectures, add support for reporting the Spectre
vulnerability status via sysfs CPU.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
[ preserve res variable - gregkh ]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Reviewed-by: Alex Shi <alexsshi@tencent.com>
Reviewed-by: samuelliao <samuelliao@tencent.com>
Ori Module.kabi_tkci has more than 10000 symbols, most of
them won't be used by customer's ko. So, change Module.kabi_tkci
to core kabi, to reduce symbols.
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Reviewed-by: samuelliao <samuelliao@tencent.com>
__stack_chk_guard crc is depend on gcc version, and tkci's gcc
is gcc-11 (not gcc-8). So, remove gcc version related symbols
from Module.kabi baseline.
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Reviewed-by: samuelliao <samuelliao@tencent.com>
Tkci has changed the config, that causing to change kabi.
So update Module.kabi_tkci as kabi baseline for checkkabi.
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Reviewed-by: samuelliao <samuelliao@tencent.com>
In tkci, x86_tkbuild and arm64_tkbuild build the kernel with no
sign config. So, add Module.kabi_nosign for tkci check kabi.
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Reviewed-by: samuelliao <samuelliao@tencent.com>
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
This module is depended by input_leds, otherwise dist build complain:
filter-modules.sh: depmod: WARNING: kernel/drivers/input/input-leds.ko
needs unknown symbol led_classdev_unregister
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Reviewed-by: Kairui Song <kasong@tencent.com>
An invalid parameter takes effect on linux-5.x, replace with another parameter
Reviewed-by: Hongbo Mao <maohongbo@phytium.com.cn>
(cherry picked from commit 1195435707)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
I2S driver support for Phytium desktop and embedded CPUs, such as E2000.
(cherry picked from commit 68c0c72315)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
This patch adds a driver for the PWM controller found on Phytium SoCs.
source from Phytium commit 1a1d6db9a1e4e60f80e9c5360056ef0c84f446b1.
Reviewed-by: Hongbo Mao <maohongbo@phytium.com.cn>
(cherry picked from commit 14f5c0b48c)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
This patch adds the Phytium Random Number Generator (RNG) support.
Reviewed-by:maohongbo<maohongbo@phytium.com.cn>
Signed-off-by: Zhang Yiqun <zhangyiqun@phytium.com.cn>
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn>
(cherry picked from commit 20b202182a)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
This patch adds the Phytium Multimedia Card Interface (MCI) driver.
Signed-off-by: Cheng Quan <chengquan@phytium.com.cn>
Signed-off-by: Lai Xueyu <laixueyu1280@phytium.com.cn>
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn>
(cherry picked from commit ea9baaf77c)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Add support for the Phytium SD host controller driver.
Signed-off-by: Cheng Quan <chengquan@phytium.com.cn>
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn>
(cherry picked from commit e5d35c5590)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Signed-off-by: Feng Jun <fengjun@phytium.com.cn>
Signed-off-by: Song Wenting <songwenting@phytium.com.cn>
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn>
(cherry picked from commit 89e4af5b21)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Phytium Pe220x SoCs includes an 8-channel, 10-bit single ended ADC
This patch add this ADC driver support
Signed-off-by: wangzhimin <wangzhimin1179@phytium.com.cn>
(cherry picked from commit 0b1dadff13)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
This patch adds support for the 1-wire master interface of Phytium.
Signed-off-by: wangzhimin <wangzhimin1179@phytium.com.cn>
(cherry picked from commit 06cac346ea)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
This patch adds support for Phytium keypad controller driver on Phytium SoCs.
Signed-off-by: Song Wenting <songwenting@phytium.com.cn>
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn>
Signed-off-by: Shuo Li <lishuo@phytium.com.cn>
(cherry picked from commit 8fe5729e2d)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
add new spi-nor flash support
Reviewed-by: Hongbo Mao <maohongbo@phytium.com.cn>
(cherry picked from commit 6ab4f737d9)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
add Phytium hwspinlock support for E-series Socs
verifyed on Phytium E2000D
Reviewed-by: Hongbo Mao <maohongbo@phytium.com.cn>
(cherry picked from commit effffb8226)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Support for the Phytium JPEG Encoder Engine embedded in the Phytium SOCs.The engine can capture and compress video data from digital or analog sources.
Reviewed-by:maohongbo<maohongbo@phytium.com.cn>
Signed-off-by: Wang Min <wangmin@phytium.com.cn>
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn>
(cherry picked from commit 6f9e10130c)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
adds a simple device driver to expose the BT interface
on Phytium SoC as a character device. Such SOCs are commonly
used as BMCs (BaseBoard Management Controllers) and this driver
implements the BMC side of the BT interface.
(cherry picked from commit ccb23948d0)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Conflicts:
drivers/char/ipmi/Kconfig
drivers/char/ipmi/Makefile
add support for the Phytium QuadSPI controller driver
verifyed on Phytium D2000
Reviewed-by: Hongbo Mao <maohongbo@phytium.com.cn>
(cherry picked from commit bce2cf32f3)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Since current Phytium Px210 xHCI host controller does not support
USB Gen2(10Gbps) well, add the XHCI_SLOWDOWN_QUIRK quirk and
modify the limited speed to 5Gbps.
Signed-off-by: Feng Jun <fengjun@phytium.com.cn>
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn>
(cherry picked from commit 50f3eecbba)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Add a driver for fan tachometer and capture counter of Phytium SoCs.
Signed-off-by: wangzhimin <wangzhimin1179@phytium.com.cn>
(cherry picked from commit cf09b9c0f0)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Add an standalone irqchip driver to handle Phytium PCI legacy interrupt.
When processing legacy INTx interrupts on some Phytium SoCs, the interrupt
status registers have be cleared by software explicitly. We introduce this
standalone irqchip which sits between the PCI legacy interrupt and the GIC,
applying hierarchical irqdomain to integrate the ack in the existing INTx
processing flow.
Signed-off-by: wangzhimin <wangzhimin1179@phytium.com.cn>
(cherry picked from commit aa66828d35)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
When mapping a LPI, the ITS driver picks the first possible
affinity, which is in most cases CPU0, assuming that if
that's not suitable, someone will come and set the affinity
to something more interesting.
It apparently isn't the case, and people complain of poor
performance when many interrupts are glued to the same CPU.
So let's place the interrupts by finding the "least loaded"
CPU (that is, the one that has the fewer LPIs mapped to it).
So called 'managed' interrupts are an interesting case where
the affinity is actually dictated by the kernel itself, and
we should honor this.
Reported-by: John Garry <john.garry@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1575642904-58295-1-git-send-email-john.garry@huawei.com
Link: https://lore.kernel.org/r/20200515165752.121296-3-maz@kernel.org
(cherry picked from commit 840775cad1)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
In order to improve the distribution of LPIs among CPUs, let start by
tracking the number of LPIs assigned to CPUs, both for managed and
non-managed interrupts (as separate counters).
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/20200515165752.121296-2-maz@kernel.org
(cherry picked from commit aca60b181c)
Signed-off-by: Alex Shi <alexsshi@tencent.com>
Hyeonggon Yoo