commit 6396b852e46e562f4742ed0a9042b537eb26b8aa upstream.

Stage 2 fault handler marks a page as executable if it is handling an
execution fault or if it was a permission fault in which case the
executable bit needs to be preserved.

The logic to decide if the page should be marked executable is
duplicated for PMD and PTE entries. To avoid creating another copy
when support for PUD hugepages is introduced refactor the code to
share the checks needed to mark a page table entry as executable.
Signed-off-by: NPunit Agrawal <punit.agrawal@arm.com>
Reviewed-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: NChristoffer Dall <christoffer.dall@arm.com>
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linux.alibaba.com>
Acked-by: NZou Cao <zoucao@linux.alibaba.com>

commit 3f58bf63455588a260b6abc8761c48bc8977b919 upstream.

The code for operations such as marking the pfn as dirty, and
dcache/icache maintenance during stage 2 fault handling is duplicated
between normal pages and PMD hugepages.

Instead of creating another copy of the operations when we introduce
PUD hugepages, let's share them across the different pagesizes.
Signed-off-by: NPunit Agrawal <punit.agrawal@arm.com>
Reviewed-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: NChristoffer Dall <christoffer.dall@arm.com>
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linux.alibaba.com>
Acked-by: NZou Cao <zoucao@linux.alibaba.com>

commit d1878af3a5a6ac00bc8a3edfecf80539ee9c546e upstream.

When KVM traps an unhandled sysreg/coproc access from a guest, it logs
the guest PC. To aid debugging, it would be helpful to know which
exception level the trap came from, along with other PSTATE/CPSR bits,
so let's log the PSTATE/CPSR too.
Acked-by: NChristoffer Dall <christoffer.dall@arm.com>
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linux.alibaba.com>
Reviewed-by: NZou Cao <zoucao@linux.alibaba.com>

commit bd7d95cafb499e24903b7d21f9eeb2c5208160c2 upstream.

When we emulate a guest instruction, we don't advance the hardware
singlestep state machine, and thus the guest will receive a software
step exception after a next instruction which is not emulated by the
host.

We bodge around this in an ad-hoc fashion. Sometimes we explicitly check
whether userspace requested a single step, and fake a debug exception
from within the kernel. Other times, we advance the HW singlestep state
rely on the HW to generate the exception for us. Thus, the observed step
behaviour differs for host and guest.

Let's make this simpler and consistent by always advancing the HW
singlestep state machine when we skip an instruction. Thus we can rely
on the hardware to generate the singlestep exception for us, and never
need to explicitly check for an active-pending step, nor do we need to
fake a debug exception from the guest.

Cc: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: NChristoffer Dall <christoffer.dall@arm.com>
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linux.alibaba.com>
Reviewed-by: NZou Cao <zoucao@linux.alibaba.com>

[ Upstream commit 1723fdec5fcbc4de3d26bbb23a9e1704ee258955 ]

While devm_gpiod_get_index_optional() returns NULL if the GPIO is not
present (i.e. -ENOENT), it may still return other error codes, like
-EPROBE_DEFER.  Currently these are not handled, leading to
unrecoverable failures later in case of probe deferral:

    gpiod_set_consumer_name: invalid GPIO (errorpointer)
    gpiod_direction_output: invalid GPIO (errorpointer)
    gpiod_set_value_cansleep: invalid GPIO (errorpointer)
    gpiod_set_value_cansleep: invalid GPIO (errorpointer)
    gpiod_set_value_cansleep: invalid GPIO (errorpointer)

Detect and propagate errors to fix this.

Fixes: f3186dd876697e69 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

The Cadence controller also supports platforms specifying
native chipselects. When I enforce the use of high CS
for drivers opting in for using GPIO descriptors, I
inadvertedly switched the driver to also use active
high chip select for native chip selects.

Fix this by inverting the logic in the callback for the
native chip select. Rename the parameter from "is_high"
(which is interpreted as being high when 0, which is
confusing, I will not make any drug-related jokes here)
to "enabled" which is more intuitive, especially now that
it is true when CS is supposed to be enabled.

Cc: Wei Yongjun <weiyongjun1@huawei.com>
Fixes: cfeefa79dc37 ("spi: cadence: Convert to use CS GPIO descriptors")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

The DW controller also supports platforms specifying
native chipselects. When I enforce the use of high CS
for drivers opting in for using GPIO descriptors, I
inadvertedly switched the driver to also use active
high chip select for native chip selects.

As it turns out, the DW hardware driving chip selects
also thinks it is weird with active low chip selects
so all we need to do is remove an inversion in the
driver.

Cc: Jan Kotas <jank@cadence.com>
Reported-by: NJan Kotas <jank@cadence.com>
Tested-by: NJan Kotas <jank@cadence.com>
Fixes: 9400c41e77b8 ("spi: dw: Convert to use CS GPIO descriptors")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

All controllers using GPIO descriptors can by definition
support high CS connections, so just enforce this when
registering an SPI controller.

This fixes a regression where controllers were missing
SPI_CS_HIGH, the drivers would fail like this:

spi spi0.0: setup: unsupported mode bits 4
cdns-spi fd0b0000.spi: can't setup spi0.0, status -22

This is because as using descriptors moves the CS inversion
logic over to gpiolib, all such controllers are registered
with CS active high.

Cc: Jan Kotas <jank@cadence.com>
Reported-by: NJan Kotas <jank@cadence.com>
Tested-by: NJan Kotas <jank@cadence.com>
Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit 9400c41e77b8f1f9c711b08a6c79bdbc5681fb00 upstream

This converts the DesignWare (dw) SPI master driver to
use GPIO descriptors for chip select handling.

This driver has a duplicate DT parser in addition to the
one in the core, sets up the line as non-asserted and
relies on the core to drive the GPIOs.

It is a pretty straight-forward conversion.

Cc: Talel Shenhar <talel@amazon.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Linuxarm <linuxarm@huawei.com>
Tested-by: NJay Fang <f.fangjian@huawei.com>
Reviewed-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@alibaba.linux.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit 101a68e74fe089b975c407f1bc9359882b05489a upstream

This converts the DaVinci SPI master driver to use GPIO
descriptors for chip select handling.

DaVinci parses the device tree a second time for the chip
select GPIOs (no relying on the parsing already happening
in the SPI core) and handles inversion semantics locally.

We simply drop the extra parsing and set up and move the
CS handling to the core and gpiolib. The fact that the
driver is actively driving the GPIO in the
davinci_spi_chipselect() callback is confusing since the
host does not set SPI_MASTER_GPIO_SS so this should not
ever get called when using GPIO CS. I put in a comment
about this.

This driver also supports instantiation from board files,
but these are all using native chip selects so no problem
with GPIO lines here.

Cc: David Lechner <david@lechnology.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Linuxarm <linuxarm@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit 054320b25520ff3c2440f5d56233c8f672293b3c upstream

This converts the CLPS711x SPI master driver to use GPIO
descriptors for chip select handling.

The CLPS711x driver was merely requesting the GPIO and
setting the CS line non-asserted so this was a pretty
straight-forward conversion. The setup callback goes away.

Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Linuxarm <linuxarm@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit cfeefa79dc37d378216e2ced1600e297dd04e591 upstream

This converts the Cadence SPI master driver to use GPIO
descriptors for chip select handling.

The Cadence driver was allocating a state container just
to hold the requested GPIO line and contained lots of
polarity inversion code. As this is all handled by gpiolib
and a simple devm_* request in the core, and as the driver
is fully device tree only, most of this code chunk goes
away in favour of central handling. The setup/cleanup
callbacks goes away.

This driver does NOT drive the CS line by setting the
value of the GPIO so it relies on the SPI core to do
this, which should work just fine with the descriptors.

Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: Janek Kotas <jank@cadence.com>
Cc: Linuxarm <linuxarm@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit efc92fbb876014c8efa4d90f4ac4b49569f0a84e upstream

This converts the Atmel SPI master driver to use GPIO descriptors
for chip select handling.

The Atmel driver has duplicate code to look up and initialize CS
GPIOs from the device tree, so this is removed. It further has code
to retrieve a CS GPIO from .controller_data but this seems to be
completely unused in the kernel (legacy codepath?) so I deleted
this support. It keeps track of polarity when switching the CS, but
this is not needed anymore since we moved this over to the gpiolib.

The local handling of the "npcs_pin" (I guess this might mean
"negative polarity chip select pin") is preserved, but I strongly
suspect this can be switched over to handling by the core and
using the SPI_MASTER_GPIO_SS flag on the master to assure that
the additional CS handling in the driver is also done.

Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Radu Pirea <radu.pirea@microchip.com>
Cc: Linuxarm <linuxarm@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit 8db79547e79f6606b6d2d3b2bf6f36ec311195be upstream

This converts the ATH79 SPI master driver to use GPIO descriptors
for chip select handling.

The ATH79 driver was requesting the GPIO and driving it from the
bitbang .chipselect callback. Do not request it anymore as the SPI
core will request it, remove the line inversion semantics for the
GPIO case (handled by gpiolib) and let the SPI core deal with
requesting the GPIO line from the device tree node of the controller.

This driver can be instantiated from a board file (no device tree)
but the board files only use native CS (no GPIO lines) so we should
be fine just letting the SPI core grab the GPIO from the device.

The fact that the driver is actively driving the GPIO in the
ath79_spi_chipselect() callback is confusing since the host does
not set SPI_MASTER_GPIO_SS so this should not ever get called when
using GPIO CS. I put in a comment about this.

Cc: Felix Fietkau <nbd@nbd.name>
Cc: Alban Bedel <albeu@free.fr>
Cc: Linuxarm <linuxarm@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit f3186dd876697e696d07136623d5cf0a6fb0bc0f upstream

This augments the SPI core to optionally use GPIO descriptors
for chip select on a per-master-driver opt-in basis.

Drivers using this will rely on the SPI core to look up
GPIO descriptors associated with the device, such as
when using device tree or board files with GPIO descriptor
tables.

When getting descriptors from the device tree, this will in
turn activate the code in gpiolib that was
added in commit 6953c57ab172
("gpio: of: Handle SPI chipselect legacy bindings")
which means that these descriptors are aware of the active
low semantics that is the default for SPI CS GPIO lines
and we can assume that all of these are "active high" and
thus assign SPI_CS_HIGH to all CS lines on the DT path.

The previously used gpio_set_value() would call down into
gpiod_set_raw_value() and ignore the polarity inversion
semantics.

It seems like many drivers go to great lengths to set up the
CS GPIO line as non-asserted, respecting SPI_CS_HIGH. We pull
this out of the SPI drivers and into the core, and by simply
requesting the line as GPIOD_OUT_LOW when retrieveing it from
the device and relying on the gpiolib to handle any inversion
semantics. This way a lot of code can be simplified and
removed in each converted driver.

The end goal after dealing with each driver in turn, is to
delete the non-descriptor path (of_spi_register_master() for
example) and let the core deal with only descriptors.

The different SPI drivers have complex interactions with the
core so we cannot simply change them all over, we need to use
a stepwise, bisectable approach so that each driver can be
converted and fixed in isolation.

This patch has the intended side effect of adding support for
ACPI GPIOs as it starts relying on gpiod_get_*() to get
the GPIO handle associated with the device.

Cc: Linuxarm <linuxarm@huawei.com>
Acked-by: NJonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: NFangjian (Turing) <f.fangjian@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit f34ecdbd5661816ce8bbd7511f33181ffa8f4895 commit

This remove the check and subsequent return of error for the case when
a SPI device requires SPI_CS_WORD and is also configured to use a GPIO
for the CS line.

Commit a134cc414e86 ("spi: always use software fallback for SPI_CS_WORD
when using cs_gio") handles this case now, so this check is no longer
necessary.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit e2540da86ef83ed90e3c13e02c52991c515b12e5 upstream

This changes how the SPI message for the triggered buffer is setup in
the TI ADS7950 A/DC driver. By using the SPI_CS_WORD flag, we can read
multiple samples in a single SPI transfer. If the SPI controller
supports DMA transfers, we can see a significant reduction in CPU usage.

For example, on an ARM9 system running at 456MHz reading just 4 channels
at 100Hz: before this change, top shows the CPU usage of the IRQ thread
of this driver to be ~7.7%. After this change, the CPU usage drops to
~3.8%.

The use of big-endian for the raw data was cargo culted from another
driver when this driver was originally written. It used an SPI word size
of 8 bits and big-endian byte ordering to effectively emulate 16 bit
words.

Now, in order to inject a CS toggle between each word, we need to use
the correct word size, otherwise we would get a CS toggle half way
through each word 16-bit. The SPI subsystem uses CPU byte ordering for
multi-byte words. So, the data we get back from the SPI is going to be
CPU endian now no matter what. Converting that to big endian will just
add overhead on little endian systems so we opt to change the raw data
format from big endian to CPU endian.

There is a small risk that this could break some lazy userspace programs
that use the raw data without checking the data format. We can address
this if/when it actually comes up.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit a3762b13a596642586051d877efc80ff043bc42a upstream

This adds support for the SPI_CS_WORD flag to the TI DaVinci SPI
driver. This mode can be used as long as we are using the hardware
chip select and not a GPIO chip select.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit cbaa62e0094a840fecc853910e0c0454529cec03 upstream

This adds a default software implementation for the SPI_CS_WORD flag for
controllers that don't have such a feature.

The SPI_CS_WORD flag indicates that the CS line should be toggled
between each word sent, not just between each transfer. The
implementation works by using existing functions to split transfers into
one-word-sized transfers and sets the cs_change bit for each of the
new transfers.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@alibaba.linux.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit 0baf9eb25572eea0cf48249c1d152d8373956a7c upstream

This adds a new SPI mode flag, SPI_CS_WORD, that is used to indicate
that a SPI device requires the chip select to be toggled after each
word that is transferred.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@linux.alibaba.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit 56df612afb606dcefba8ab38ab32e052218b6050 upstream

The DaVinci SPI can use either:
- Internal chip selects (inside the SPI host)
- External chip selects (using GPIO)
- External chip selects passed in pdata

The last way of passing external chip selects through
platform data is not used in the kernel. Delete it to make
the code simpler when refactoring GPIO.

Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Michele Dionisio <michele.dionisio@gmail.com>
Cc: Frode Isaksen <fisaksen@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NZou Cao <zoucao@alibaba.linux.com>
Reviewed-by: NBaoyou Xie <xie.baoyou@linux.alibaba.com>

commit 24beb83ad289c68bce7c01351cb90465bbb1940a upstream.

The Hygon Dhyana CPU has the SMBus device with PCI device ID 0x790b,
which is the same as AMD CZ SMBus device. So add Hygon Dhyana support
to the i2c-piix4 driver by using the code path of AMD.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit e0ceeae708cebf22c990c3d703a4ca187dc837f5 upstream.

The Hygon family 18h multi-die processor platform supports 1, 2 or
4-Dies per socket. The topology looks like this:

  System View (with 1-Die 2-Socket):
             |------------|
           ------       -----
   SOCKET0 | D0 |       | D1 |  SOCKET1
           ------       -----

  System View (with 2-Die 2-socket):
             --------------------
             |     -------------|------
             |     |            |     |
           ------------       ------------
   SOCKET0 | D1 -- D0 |       | D3 -- D2 | SOCKET1
           ------------       ------------

  System View (with 4-Die 2-Socket) :
             --------------------
             |     -------------|------
             |     |            |     |
           ------------       ------------
           | D1 -- D0 |       | D7 -- D6 |
           | |  \/ |  |       | |  \/ |  |
   SOCKET0 | |  /\ |  |       | |  /\ |  | SOCKET1
           | D2 -- D3 |       | D4 -- D5 |
           ------------       ------------
             |     |            |     |
             ------|------------|     |
                   --------------------

Currently

  phys_proc_id = initial_apicid >> bits

calculates the physical processor ID from the initial_apicid by shifting
*bits*.

However, this does not work for 1-Die and 2-Die 2-socket systems.

According to document [1] section 2.1.11.1, the bits is the value of
CPUID_Fn80000008_ECX[12:15]. The possible values are 4, 5 or 6 which
mean:

  4 - 1 die
  5 - 2 dies
  6 - 3/4 dies.

Hygon programs the initial ApicId the same way as AMD. The ApicId is
read from CPUID_Fn00000001_EBX (see section 2.1.11.1 of referrence [1])
and the definition is as below (see section 2.1.10.2.1.3 of [1]):

      -------------------------------------------------
  Bit |     6     |   5  4  |    3   |    2   1   0   |
      |-----------|---------|--------|----------------|
  IDs | Socket ID | Node ID | CCX ID | Core/Thread ID |
      -------------------------------------------------

So for 3/4-Die configurations, the bits variable is 6, which is the same
as the ApicID definition field.

For 1-Die and 2-Die configurations, bits is 4 or 5, which will cause the
right shifted result to not be exactly the value of socket ID.

However, the socket ID should be obtained from ApicId[6]. To fix the
problem and match the ApicID field definition, set the shift bits to 6
for all Hygon family 18h multi-die CPUs.

Because AMD doesn't have 2-Socket systems with 1-Die/2-Die processors
(see reference [2]), this doesn't need to be changed on the AMD side but
only for Hygon.

References:
[1] https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
[2] https://www.amd.com/en/products/specifications/processors

 [bp: heavily massage commit message. ]
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/1553355740-19999-1-git-send-email-puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit d93217d84c6c7ef74bfeb606a1fb1ee28720646b upstream.

Add support for Hygon Dhyana family 18h processor for k10temp to get the
temperature. As Hygon Dhyana shares the same function interface with AMD
family 17h, so add Hygon PCI Vendor ID and reuse the code path of AMD.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Acked-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit 995d5f64b62f20f05b8e0972f07ec4d6c23333c9 upstream.

The tool cpupower is useful to get CPU frequency information and monitor
power stats on the Hygon Dhyana platform. So add Hygon Dhyana support to
it by checking vendor and family to share the code path of AMD family
17h.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NShuah Khan (Samsung OSG) <shuah@kernel.org>
CC: Prarit Bhargava <prarit@redhat.com>
CC: Shuah Khan <shuah@kernel.org>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Thomas Renninger <trenn@suse.com>
CC: linux-pm@vger.kernel.org
Link: http://lkml.kernel.org/r/5ce86123a7b9dad925ac583d88d2f921040e859b.1538583282.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit c4a3e94641449362ee970f521a2cdb0e8cd08690 upstream.

Add support for Hygon Dhyana CPU to EDAC.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: mchehab@kernel.org
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: thomas.lendacky@amd.com
Cc: linux-edac@vger.kernel.org
Link: https://lkml.kernel.org/r/9d71061301177822bc55b3bfd44f91057458d886.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit cc9690cfc7a36873b219d569049e10f073dd22e4 upstream.

The Hygon Dhyana CPU supports ACPI P-States, and there is SMBus device
(PCI device ID 0x790b) on the Hygon platform. Add Hygon Dhyana support
to the cpufreq driver by using the code path of AMD family 17h.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: rjw@rjwysocki.net
Cc: viresh.kumar@linaro.org
Cc: bp@alien8.de
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Cc: rafael@kernel.org
Cc: linux-pm@vger.kernel.org
Link: https://lkml.kernel.org/r/4db6f0f8537a93c172430c446a0297a6ab1c3c2d.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit 7377ed4bd56e6cc1ddbb63f03626fc5b92d3d6fe upstream.

The Hygon Dhyana CPU has NONSTOP TSC feature, so enable the ACPI driver
support to it.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: rjw@rjwysocki.net
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Cc: lenb@kernel.org
Cc: rafael@kernel.org
Cc: linux-acpi@vger.kernel.org
Link: https://lkml.kernel.org/r/cce6ee26f4e2ebbab493433264d89d7cea661284.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit 4044240365e85ef7ae43a6dc454669b57853124c upstream.

To make Xen work on the Hygon platform, reuse AMD's Xen support code
path for Hygon Dhyana CPU.

There are six core performance events counters per thread, so there are
six MSRs for these counters. Also there are four legacy PMC MSRs, they
are aliases of the counters.

In this version, use the legacy and safe version of MSR access. Tested
successfully with VPMU enabled in Xen on Hygon platform by testing with
perf.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: jgross@suse.com
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Cc: xen-devel@lists.xenproject.org
Link: https://lkml.kernel.org/r/311bf41f08f24550aa6c5da3f1e03a68d3b89dac.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit b8f4abb652146ddde04ab6e2a80e8cde27ff4470 upstream.

The Hygon Dhyana CPU has the SVM feature as AMD family 17h does.
So enable the KVM infrastructure support to it.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: pbonzini@redhat.com
Cc: rkrcmar@redhat.com
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Cc: kvm@vger.kernel.org
Link: https://lkml.kernel.org/r/654dd12876149fba9561698eaf9fc15d030301f8.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit ac78bd72355d0da64c073c12927264d4ff19b886 upstream.

The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. Add vendor checking for Hygon Dhyana to share the
code path of AMD family 17h.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: tony.luck@intel.com
Cc: thomas.lendacky@amd.com
Cc: linux-edac@vger.kernel.org
Link: https://lkml.kernel.org/r/87d8a4f16bdea0bfe0c0cf2e4a8d2c2a99b1055c.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit 1a576b23d63794f39a247fb31056eecccbf9a287 upstream.

The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD spectre mitigation code with Hygon Dhyana.

Also Hygon Dhyana is not affected by meltdown, so add exception for it.

 [ puwen: Convert Hygon Meltdown mitigation machinery to fit new code. ]
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Link: https://lkml.kernel.org/r/0861d39c8a103fc0deca15bafbc85d403666d9ef.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit da33dfef404174b0b452f4d2a9a9e00801794f3a upstream.

Add Hygon Dhyana support to the APIC subsystem. When running in 32 bit
mode, bigsmp should be enabled if there are more than 8 cores online.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Link: https://lkml.kernel.org/r/7a557265a8c7c9e842fe60f9d8e064458801aef3.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit c6babb5806b77c6ca7078c3487bb0a29704a4e38 upstream.

Hygon's PCI vendor ID is 0x1d94, and there are PCI devices
0x1450/0x1463/0x1464 for the host bridge on the Hygon Dhyana platform.
Add Hygon Dhyana support to the PCI and northbridge subsystems by using
the code path of AMD family 17h.

 [ bp: Massage commit message, sort local vars into reverse xmas tree
   order and move the amd_northbridges.num check up. ]

 [ puwen: Convert variable i to misc_count and adjust amd_root_ids
   in two place to match new code. ]
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>	# pci_ids.h
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Cc: helgaas@kernel.org
Cc: linux-pci@vger.kernel.org
Link: https://lkml.kernel.org/r/5f8877bd413f2ea0833378dd5454df0720e1c0df.1537885177.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit b7a5cb4f220e78490735b2b984ad29b7d8e612a9 upstream.

Exit early in functions which are meant to run on AMD only but which get
run on different vendor (VMs, etc).

 [ bp: rewrite commit message. ]
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: bhelgaas@google.com
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Cc: helgaas@kernel.org
Link: https://lkml.kernel.org/r/487d8078708baedaf63eb00a82251e228b58f1c2.1537885177.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit c3fecca457c1aa1c1a2f81bfe68393af244a263e upstream.

The ideal_nops for Hygon Dhyana CPU should be p6_nops.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Link: https://lkml.kernel.org/r/79e76c3173716984fe5fdd4a8e2c798bf4193205.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit 6d0ef316b9f8ea03fa867debda70b2f11a0b9736 upstream.

The PMU architecture for the Hygon Dhyana CPU is similar to the AMD
Family 17h one. To support it, call amd_pmu_init() to share the AMD PMU
initialization flow, and change the PMU name to "HYGON".

The Hygon Dhyana CPU supports both legacy and extension PMC MSRs (perf
counter registers and event selection registers), so add Hygon Dhyana
support in the similar way as AMD does.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Link: https://lkml.kernel.org/r/9d93ed54a975f33ef7247e0967960f4ce5d3d990.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit 0b13bec787dccca96f8c431da732657ae01baf9a upstream.

The Hygon Dhyana CPU uses no delay in smp_quirk_init_udelay(), and does
HLT on idle just like AMD does.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: bp@alien8.de
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Link: https://lkml.kernel.org/r/87000fa82e273f5967c908448414228faf61e077.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit 39dc6f154dac134e4612827cb5283934c1862cb8 upstream.

The Hygon Dhyana CPU has a special MSR way to force WB for memory >4GB,
and support TOP_MEM2. Therefore, it is necessary to add Hygon Dhyana
support in amd_special_default_mtrr().

The number of variable MTRRs for Hygon is 2 as AMD's.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Link: https://lkml.kernel.org/r/8246f81648d014601de3812ade40e85d9c50d9b3.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>

commit d4f7423efdd1419b17524d090ff9ff4024bcf09b upstream.

The Hygon Dhyana CPU has a topology extensions bit in CPUID. With
this bit, the kernel can get the cache information. So add support in
cpuid4_cache_lookup_regs() to get the correct cache size.

The Hygon Dhyana CPU also discovers num_cache_leaves via CPUID leaf
0x8000001d, so add support to it in find_num_cache_leaves().

Also add cacheinfo_hygon_init_llc_id() and init_hygon_cacheinfo()
functions to initialize Dhyana cache info. Setup cache cpumap in the
same way as AMD does.
Signed-off-by: NPu Wen <puwen@hygon.cn>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: bp@alien8.de
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Link: https://lkml.kernel.org/r/2a686b2ac0e2f5a1f2f5f101124d9dd44f949731.1537533369.git.puwen@hygon.cnAcked-by: NCaspar Zhang <caspar@linux.alibaba.com>