Age | Commit message (Collapse) | Author | Files | Lines |
|
When mounting a cgroup hierarchy with disabled controller in cgroup v1,
all available controllers will be attached.
For example, boot with cgroup_no_v1=cpu or cgroup_disable=cpu, and then
mount with "mount -t cgroup -ocpu cpu /sys/fs/cgroup/cpu", then all
enabled controllers will be attached except cpu.
Fix this by adding disabled controller check in cgroup1_parse_param().
If the specified controller is disabled, just return error with information
"Disabled controller xx" rather than attaching all the other enabled
controllers.
Fixes: f5dfb5315d34 ("cgroup: take options parsing into ->parse_monolithic()")
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Reviewed-by: Zefan Li <lizefan.x@bytedance.com>
Reviewed-by: Michal Koutný <mkoutny@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
UEFI/RM no longer use IED scripts from the VBIOS, though they appear to
have been updated for use by the x86 VBIOS code, so we should be able to
continue using them for the moment.
Unfortunately, we require some hacks to do so, as the BeforeLinkTraining
IED script became a pointer to an array of scripts instead, without a
revbump of the relevant tables.
There's also some changes to SOR clock divider fiddling, which are
hopefully correct enough that things work as they should.
AFAIK, GA100 shouldn't have display, so it hasn't been added.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GV100 code, and not required on GA100, as
it shouldn't have display.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GM200 code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
GA100 appears to be compatible with GK104 code, the others have some
register moves.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU102 code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU102 code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GK20A code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
No VPR scrub. GA102 and GA104 have a new VRAM size detection method.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with NV50 code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GM200 code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Fortunately, all the interrupts we need to bring up basic display support
are contained in a single leaf register, allowing this basic (but hackish)
implementation.
There's a bunch more invasive patches to come implementing all this in a
better/more complete way, but trying to get a minimal series out first.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
VPLL regs changed a bit. There's more stuff to do around these, but it's
less invasive to stick those changes into disp for now.
None of that belongs here anymore anyhow - fix that someday.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Forcing PRAMIN-shadowing off for GA100, as it requires display, and we don't
know if/where the fuse register for detecting its presence is.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GP100 code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
GA100 hidden behind a module option, as it's not been as well verified
since initial bring-up and may need additional changes.
There's no display anyway, so this can wait for a bit.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
RM does this around transactions, and it seemed to help while debugging
AUXCH issues on GA102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
No functional changes here yet.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Whatever it is that we were doing before doesn't work on Ampere.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau 0000:09:00.0: bios: 00000000: type 00, 65024 bytes
[ 906.381205] nouveau 0000:09:00.0: bios: 0000fe00: type 03, 91648 bytes
[ 906.405213] nouveau 0000:09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau 0000:09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau 0000:09:00.0: bios: 00000000: type 00, 60416 bytes
[ 22.984174] nouveau 0000:09:00.0: bios: 0000ec00: type 03, 71168 bytes
[ 23.010446] nouveau 0000:09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau 0000:09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau 0000:09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
tcp_disconnect() expects the caller acquires the sock lock,
but mptcp_disconnect() is not doing that. Add the missing
required lock.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Fixes: 76e2a55d1625 ("mptcp: better msk-level shutdown.")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Link: https://lore.kernel.org/r/f818e82b58a556feeb71dcccc8bf1c87aafc6175.1610638176.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
[Why]
Find out when we try to disable CRC calculation, crc generation is still
enabled. Main reason is that dc_stream_configure_crc() will never get
called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE.
[How]
Add checking condition that when source is
AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call
dc_stream_configure_crc() to disable crc calculation.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This reverts commit c920888c604d72799d057bbcd9e28a6c003ccfbe.
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Alexander Deucher <Alexander.Deucher@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Bindu R <Bindu.R@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This reverts commit 6ae09fa49147e557eb6aebbb5b2059b63706d454.
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Alexander Deucher <Alexander.Deucher@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Bindu R <Bindu.R@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This reverts commit f01afd1ee48816457fb22e201f1d0cfb14589904.
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Alexander Deucher <Alexander.Deucher@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Bindu R <Bindu.R@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add function to set power brake sequence.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Cited patch below blocked the TLS TX device offload unless HW_CSUM
is set. This broke devices that use IP_CSUM && IP6_CSUM.
Here we fix it.
Note that the single HW_TLS_TX feature flag indicates support for
both IPv4/6, hence it should still be disabled in case only one of
(IP_CSUM | IPV6_CSUM) is set.
Fixes: ae0b04b238e2 ("net: Disable NETIF_F_HW_TLS_TX when HW_CSUM is disabled")
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reported-by: Rohit Maheshwari <rohitm@chelsio.com>
Reviewed-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Link: https://lore.kernel.org/r/20210114151215.7061-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
As far as I can tell we haven't heard from Gerrit for roughly
5 years now. DCCP patch would really benefit from some review.
Gerrit was the last maintainer so mark this entry as orphaned.
Subsystem DCCP PROTOCOL
Changes 38 / 166 (22%)
(No activity)
Top reviewers:
[6]: kstewart@linuxfoundation.org
[6]: allison@lohutok.net
[5]: edumazet@google.com
INACTIVE MAINTAINER Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Move Wensong Zhang to credits, we haven't heard from
him in years.
Subsystem IPVS
Changes 83 / 226 (36%)
Last activity: 2020-11-27
Wensong Zhang <wensong@linux-vs.org>:
Simon Horman <horms@verge.net.au>:
Committer c24b75e0f923 2019-10-24 00:00:00 33
Tags 7980d2eabde8 2020-10-12 00:00:00 76
Julian Anastasov <ja@ssi.bg>:
Author 7980d2eabde8 2020-10-12 00:00:00 26
Tags 4bc3c8dc9f5f 2020-11-27 00:00:00 78
Top reviewers:
[6]: horms+renesas@verge.net.au
INACTIVE MAINTAINER Wensong Zhang <wensong@linux-vs.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Aviad wrote parts of the initial TLS implementation
but hasn't been contributing to TLS since.
Subsystem NETWORKING [TLS]
Changes 123 / 308 (39%)
Last activity: 2020-12-01
Boris Pismenny <borisp@nvidia.com>:
Tags 138559b9f99d 2020-11-17 00:00:00 1
Aviad Yehezkel <aviadye@nvidia.com>:
John Fastabend <john.fastabend@gmail.com>:
Author e91de6afa81c 2020-06-01 00:00:00 22
Tags e91de6afa81c 2020-06-01 00:00:00 29
Daniel Borkmann <daniel@iogearbox.net>:
Author c16ee04c9b30 2018-10-20 00:00:00 7
Committer b8e202d1d1d0 2020-02-21 00:00:00 19
Tags b8e202d1d1d0 2020-02-21 00:00:00 28
Jakub Kicinski <kuba@kernel.org>:
Author 5c39f26e67c9 2020-11-27 00:00:00 89
Committer d31c08007523 2020-12-01 00:00:00 15
Tags d31c08007523 2020-12-01 00:00:00 117
Top reviewers:
[50]: dirk.vandermerwe@netronome.com
[26]: simon.horman@netronome.com
[14]: john.hurley@netronome.com
INACTIVE MAINTAINER Aviad Yehezkel <aviadye@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
While ENA has 3 reviewers and 2 maintainers, we mostly see review
tags and comments from the maintainers. While we very much appreciate
Zorik's invovment in the community let's trim the reviewer list
down to folks we've seen tags from.
Subsystem AMAZON ETHERNET DRIVERS
Changes 13 / 269 (4%)
Last activity: 2020-11-24
Netanel Belgazal <netanel@amazon.com>:
Author 24dee0c7478d 2019-12-10 00:00:00 43
Tags 0e3a3f6dacf0 2020-07-21 00:00:00 47
Arthur Kiyanovski <akiyano@amazon.com>:
Author 0e3a3f6dacf0 2020-07-21 00:00:00 79
Tags 09323b3bca95 2020-11-24 00:00:00 104
Guy Tzalik <gtzalik@amazon.com>:
Tags 713865da3c62 2020-09-10 00:00:00 3
Saeed Bishara <saeedb@amazon.com>:
Tags 470793a78ce3 2020-02-11 00:00:00 2
Zorik Machulsky <zorik@amazon.com>:
Top reviewers:
[4]: sameehj@amazon.com
[3]: snelson@pensando.io
[3]: shayagr@amazon.com
INACTIVE MAINTAINER Zorik Machulsky <zorik@amazon.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Shrijeet has moved on from VRF-related work.
Subsystem VRF
Changes 30 / 120 (25%)
Last activity: 2020-12-09
David Ahern <dsahern@kernel.org>:
Author 1b6687e31a2d 2020-07-23 00:00:00 1
Tags 9125abe7b9cb 2020-12-09 00:00:00 4
Shrijeet Mukherjee <shrijeet@gmail.com>:
Top reviewers:
[13]: dsahern@gmail.com
[4]: dsa@cumulusnetworks.com
INACTIVE MAINTAINER Shrijeet Mukherjee <shrijeet@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Move Alexey to CREDITS.
I am probably not giving him enough justice with
the description line..
Subsystem NETWORKING [IPv4/IPv6]
Changes 1535 / 5111 (30%)
Last activity: 2020-12-10
"David S. Miller" <davem@davemloft.net>:
Author b7e4ba9a91df 2020-12-09 00:00:00 407
Committer e0fecb289ad3 2020-12-10 00:00:00 3992
Tags e0fecb289ad3 2020-12-10 00:00:00 3978
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>:
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>:
Tags d5d8760b78d0 2016-06-16 00:00:00 8
Top reviewers:
[225]: edumazet@google.com
[222]: dsahern@gmail.com
[176]: ncardwell@google.com
INACTIVE MAINTAINER Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Jay was not active in recent years and does not have plans
to return to work on ATLX drivers.
Subsystem ATLX ETHERNET DRIVERS
Changes 20 / 116 (17%)
Last activity: 2020-02-24
Jay Cliburn <jcliburn@gmail.com>:
Chris Snook <chris.snook@gmail.com>:
Tags ea973742140b 2020-02-24 00:00:00 1
Top reviewers:
[4]: andrew@lunn.ch
[2]: kuba@kernel.org
[2]: o.rempel@pengutronix.de
INACTIVE MAINTAINER Jay Cliburn <jcliburn@gmail.com>
Acked-by: Chris Snook <chris.snook@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Both virtio net and napi_get_frags() allocate skbs
with a very small skb->head
While using page fragments instead of a kmalloc backed skb->head might give
a small performance improvement in some cases, there is a huge risk of
under estimating memory usage.
For both GOOD_COPY_LEN and GRO_MAX_HEAD, we can fit at least 32 allocations
per page (order-3 page in x86), or even 64 on PowerPC
We have been tracking OOM issues on GKE hosts hitting tcp_mem limits
but consuming far more memory for TCP buffers than instructed in tcp_mem[2]
Even if we force napi_alloc_skb() to only use order-0 pages, the issue
would still be there on arches with PAGE_SIZE >= 32768
This patch makes sure that small skb head are kmalloc backed, so that
other objects in the slab page can be reused instead of being held as long
as skbs are sitting in socket queues.
Note that we might in the future use the sk_buff napi cache,
instead of going through a more expensive __alloc_skb()
Another idea would be to use separate page sizes depending
on the allocated length (to never have more than 4 frags per page)
I would like to thank Greg Thelen for his precious help on this matter,
analysing crash dumps is always a time consuming task.
Fixes: fd11a83dd363 ("net: Pull out core bits of __netdev_alloc_skb and add __napi_alloc_skb")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://lore.kernel.org/r/20210113161819.1155526-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In general, device drivers should not be enabled by default.
Fixes: 657bc1d10bfc23ac ("r8153_ecm: avoid to be prior to r8152 driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210113144309.1384615-1-geert+renesas@glider.be
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The Synopsys TSN MAC supports Qbv base times in the past, but only up to a
certain limit. As a result, a taprio qdisc configuration with a small
base time (for example when treating the base time as a simple phase
offset) is not applied by the hardware and silently ignored.
This was observed on an NXP i.MX8MPlus device, but likely affects all
TSN-variants of the MAC.
Fix the issue by making sure the base time is in the future, pushing it by
an integer amount of cycle times if needed. (a similar check is already
done in several other taprio implementations, see for example
drivers/net/ethernet/intel/igc/igc_tsn.c#L116 or
drivers/net/dsa/sja1105/sja1105_ptp.h#L39).
Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API")
Signed-off-by: Yannick Vignon <yannick.vignon@nxp.com>
Link: https://lore.kernel.org/r/20210113131557.24651-2-yannick.vignon@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When configuring a 802.1Qbv schedule through the tc taprio qdisc on an NXP
i.MX8MPlus device, the effective cycle time differed from the requested one
by N*96ns, with N number of entries in the Qbv Gate Control List. This is
because the driver was adding a 96ns margin to each interval of the GCL,
apparently to account for the IPG. The problem was observed on NXP
i.MX8MPlus devices but likely affected all devices relying on the same
configuration callback (dwmac 4.00, 4.10, 5.10 variants).
Fix the issue by removing the margins, and simply setup the MAC with the
provided cycle time value. This is the behavior expected by the user-space
API, as altering the Qbv schedule timings would break standards conformance.
This is also the behavior of several other Ethernet MAC implementations
supporting taprio, including the dwxgmac variant of stmmac.
Fixes: 504723af0d85 ("net: stmmac: Add basic EST support for GMAC5+")
Signed-off-by: Yannick Vignon <yannick.vignon@nxp.com>
Link: https://lore.kernel.org/r/20210113131557.24651-1-yannick.vignon@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
A function has a different name between their prototype
and its kernel-doc markup:
../net/tipc/link.c:2551: warning: expecting prototype for link_reset_stats(). Prototype was for tipc_link_reset_stats() instead
../net/tipc/node.c:1678: warning: expecting prototype for is the general link level function for message sending(). Prototype was for tipc_node_xmit() instead
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
We need to unregister the netdevice if config failed.
.ndo_uninit takes care of most of the heavy lifting.
This was uncovered by recent commit c269a24ce057 ("net: make
free_netdev() more lenient with unregistering devices").
Previously the partially-initialized device would be left
in the system.
Reported-and-tested-by: syzbot+2393580080a2da190f04@syzkaller.appspotmail.com
Fixes: e2f1f072db8d ("sit: allow to configure 6rd tunnels via netlink")
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://lore.kernel.org/r/20210114012947.2515313-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add ftrace.instance.INSTANCE.tracing_on support to ftrace2bconf.sh
and bconf2ftrace.sh.
commit 8490db06f914 ("tracing/boot: Add per-instance tracing_on
option support") added the per-instance tracing_on option,
but forgot to update the helper scripts.
Link: https://lkml.kernel.org/r/160749166410.3497930.14204335886811029800.stgit@devnote2
Cc: stable@vger.kernel.org
Fixes: 8490db06f914 ("tracing/boot: Add per-instance tracing_on option support")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
|
|
The Logitech MX Ergo trackball supports HID++ 4.5 over Bluetooth. Add its
product ID to the table so we can get battery monitoring support.
(The hid-logitech-hidpp driver already recognizes it when connected via
a Unifying Receiver.)
[jkosina@suse.cz: fix whitespace damage]
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Fix the error type value for PCI Express uncorrectable non-fatal
error to 0x00000080 and fix the error type value for PCI Express
uncorrectable fatal error to 0x00000100.
See Advanced Configuration and Power Interface Specification,
version 6.2, table "18-409 Error Type Definition".
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Reported-by: Lijian Zhao <lijian.zhao@intel.com>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
add DID 0x164C into pciidlist under CHIP_RENOIR family.
Signed-off-by: mengwang <mengbing.wang@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 5.10.x
|
|
Add green_sardine PCI id support and map it to renoir asic type.
v2: add apu flag
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 5.10.x
|
|
This patch is to update atomfirmware parser for the memory type and
bandwidth of DDR5 and DDR4.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The address of the GOLDEN_TSC_COUNT_UPPER/GOLDEN_TSC_COUNT_LOWER for
Vnagogh are different from the others.
The offset of the GOLDEN_TSC_COUNT_UPPER for Vangogh is 0x0025 by
calculation.
The offset of the GOLDEN_TSC_COUNT_LOWER for Vangogh is 0x0026 by
calculation.
Signed-off-by: chen gong <curry.gong@amd.com>
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|