* [PATCH v5 1/4] gpio: mvebu: Add limited PWM support
From: Rob Herring @ 2017-04-13 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170409180931.4884-2-ralph.sennhauser@gmail.com>
On Sun, Apr 09, 2017 at 08:09:27PM +0200, Ralph Sennhauser wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> Armada 370/XP devices can 'blink' GPIO lines with a configurable on
> and off period. This can be modelled as a PWM.
>
> However, there are only two sets of PWM configuration registers for
> all the GPIO lines. This driver simply allows a single GPIO line per
> GPIO chip of 32 lines to be used as a PWM. Attempts to use more return
> EBUSY.
>
> Due to the interleaving of registers it is not simple to separate the
> PWM driver from the GPIO driver. Thus the GPIO driver has been
> extended with a PWM driver.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427287/
> URL: https://patchwork.ozlabs.org/patch/427295/
> [Ralph Sennhauser:
> * Port forward
> * Merge PWM portion into gpio-mvebu.c
> * Switch to atomic PWM API
> * Add new compatible string marvell,armada-370-xp-gpio
> * Update and merge documentation patch
> * Update MAINTAINERS]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
> ---
> .../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
> MAINTAINERS | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/gpio/gpio-mvebu.c | 324 ++++++++++++++++++++-
> 3 files changed, 346 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH V2] PM / OPP: Use - instead of @ for DT entries
From: Rob Herring @ 2017-04-13 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <70e7c7ee13722ab9c73cb073f88502eaf1ada5f5.1491816050.git.viresh.kumar@linaro.org>
On Mon, Apr 10, 2017 at 02:51:35PM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> V2:
> - Added more *-by tags.
> - Included TI DT and example files as well.
>
> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 20 +++----
> .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
> Documentation/devicetree/bindings/opp/opp.txt | 38 ++++++-------
> arch/arm/boot/dts/am4372.dtsi | 10 ++--
> arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
> arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
> arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
> arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
> arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
> arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
> arch/arm/boot/dts/pxa25x.dtsi | 8 +--
> arch/arm/boot/dts/pxa27x.dtsi | 14 ++---
> arch/arm/boot/dts/sun8i-a33.dtsi | 8 +--
> arch/arm/boot/dts/uniphier-pro5.dtsi | 32 +++++------
> arch/arm/boot/dts/uniphier-pxs2.dtsi | 16 +++---
> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
> arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 ++---
> arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 32 +++++------
> arch/arm64/boot/dts/zte/zx296718.dtsi | 10 ++--
> 20 files changed, 295 insertions(+), 295 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: iio: stm32-dac: Add support for STM32 DAC
From: Rob Herring @ 2017-04-13 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491839390-2449-2-git-send-email-fabrice.gasnier@st.com>
On Mon, Apr 10, 2017 at 05:49:49PM +0200, Fabrice Gasnier wrote:
> Document STMicroelectronics STM32 DAC (digital-to-analog converter).
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> Changes in v2:
> - use 'reg' instead of 'st,dac-channel' property
> - remove alignment from description
> ---
> .../devicetree/bindings/iio/dac/st,stm32-dac.txt | 61 ++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
From: Baicar, Tyler @ 2017-04-13 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412133447.n2yft7v266v6k6gh@pd.tnic>
On 4/12/2017 7:34 AM, Borislav Petkov wrote:
>> Subject: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
> Use a verb in your patch subjects: "Add support for ..." or so.
Hello Boris,
Will do in the next version.
>
> On Tue, Mar 28, 2017 at 01:30:32PM -0600, Tyler Baicar wrote:
>> Currently when a RAS error is reported it is not timestamped.
> What is a RAS error? You mean a hardware error?
Will change to hardware error.
>
>> The ACPI 6.1 spec adds the timestamp field to the generic error
>> data entry v3 structure. The timestamp of when the firmware
>> generated the error is now being reported.
> So what this patch does doesn't have a lot to to do with the Subject?
> Please state what the patch does in the Subject.
I'll change the wording to describe it better.
>
> Also, your commit message talks about adding timestamp but the patch
> does more. You need to state that too and explain what this patch does
> actually.
I'll break this up into two patches as you suggest below so that this
only adds the timestamp and the new patch adds the helper defines and usage.
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Reviewed-by: James Morse <james.morse@arm.com>
>> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> drivers/acpi/apei/ghes.c | 9 ++++---
>> drivers/firmware/efi/cper.c | 63 +++++++++++++++++++++++++++++++++++----------
>> include/acpi/ghes.h | 22 ++++++++++++++++
>> 3 files changed, 77 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 0241e36..9ddbb93 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -421,7 +421,8 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int
>> int flags = -1;
>> int sec_sev = ghes_severity(gdata->error_severity);
>> struct cper_sec_mem_err *mem_err;
>> - mem_err = (struct cper_sec_mem_err *)(gdata + 1);
>> +
>> + mem_err = acpi_hest_generic_data_payload(gdata);
>>
>> if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
>> return;
>> @@ -458,7 +459,8 @@ static void ghes_do_proc(struct ghes *ghes,
>> if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
>> CPER_SEC_PLATFORM_MEM)) {
>> struct cper_sec_mem_err *mem_err;
>> - mem_err = (struct cper_sec_mem_err *)(gdata+1);
>> +
>> + mem_err = acpi_hest_generic_data_payload(gdata);
>> ghes_edac_report_mem_error(ghes, sev, mem_err);
>>
>> arch_apei_report_mem_error(sev, mem_err);
>> @@ -468,7 +470,8 @@ static void ghes_do_proc(struct ghes *ghes,
>> else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
>> CPER_SEC_PCIE)) {
>> struct cper_sec_pcie *pcie_err;
>> - pcie_err = (struct cper_sec_pcie *)(gdata+1);
>> +
>> + pcie_err = acpi_hest_generic_data_payload(gdata);
>> if (sev == GHES_SEV_RECOVERABLE &&
>> sec_sev == GHES_SEV_RECOVERABLE &&
>> pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
>> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
>> index d425374..8fa4e23 100644
>> --- a/drivers/firmware/efi/cper.c
>> +++ b/drivers/firmware/efi/cper.c
>> @@ -32,6 +32,9 @@
>> #include <linux/acpi.h>
>> #include <linux/pci.h>
>> #include <linux/aer.h>
>> +#include <linux/printk.h>
>> +#include <linux/bcd.h>
>> +#include <acpi/ghes.h>
>>
>> #define INDENT_SP " "
>>
>> @@ -386,13 +389,37 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
>> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
>> }
>>
>> +static void cper_estatus_print_section_v300(const char *pfx,
>> + const struct acpi_hest_generic_data_v300 *gdata)
> Yuck, acpi_hest_generic_data_v300. Can we make those struct names smaller pls?
> And v300 is just silly.
>
> And then align args at opening brace.
Will do.
>
>> +{
>> + __u8 hour, min, sec, day, mon, year, century, *timestamp;
>> +
>> + if (gdata->validation_bits & ACPI_HEST_GEN_VALID_TIMESTAMP) {
>> + timestamp = (__u8 *)&(gdata->time_stamp);
>> + sec = bcd2bin(timestamp[0]);
>> + min = bcd2bin(timestamp[1]);
>> + hour = bcd2bin(timestamp[2]);
>> + day = bcd2bin(timestamp[4]);
>> + mon = bcd2bin(timestamp[5]);
>> + year = bcd2bin(timestamp[6]);
>> + century = bcd2bin(timestamp[7]);
> Align those vertically on the = sign.
Will do.
>
>> + printk("%stime: %7s %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx,
>> + 0x01 & *(timestamp + 3) ? "precise" : "",
> Move that test in a separate if-statement - that printk is unreadable as
> it is. Also, the test bit always comes second.
Will do.
>> century,
>> + year, mon, day, hour, min, sec);
>> + }
>> +}
>> +
>> static void cper_estatus_print_section(
>> - const char *pfx, const struct acpi_hest_generic_data *gdata, int sec_no)
>> + const char *pfx, struct acpi_hest_generic_data *gdata, int sec_no)
> static void
> cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data *gdata,
> int sec_no)
>
> looks much better.
All I did here was remove the const, but will do.
>> {
>> uuid_le *sec_type = (uuid_le *)gdata->section_type;
>> __u16 severity;
>> char newpfx[64];
>>
>> + if (acpi_hest_generic_data_version(gdata) >= 3)
> Jeez, that macro name is like a one-lined book!
>
> Let's make that "hest_gdata_ver()" or something else shorter.
As Joe mentioned, acpi_hest_generic<foo> is already used throughout this
code base. I do not see the value in varying from the preexisting naming
style.
>
>> + cper_estatus_print_section_v300(pfx,
>> + (const struct acpi_hest_generic_data_v300 *)gdata);
>> +
>> severity = gdata->error_severity;
>> printk("%s""Error %d, type: %s\n", pfx, sec_no,
>> cper_severity_str(severity));
>> @@ -403,14 +430,18 @@ static void cper_estatus_print_section(
>>
>> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
>> if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
>> - struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
>> + struct cper_sec_proc_generic *proc_err;
>> +
>> + proc_err = acpi_hest_generic_data_payload(gdata);
> This looks like an unrelated change. The payload function addition and the
> conversion of the code to use it should be a separate patch. And shorten that
> function name too pls.
I'll break this into two patches.
>
>> printk("%s""section_type: general processor error\n", newpfx);
>> if (gdata->error_data_length >= sizeof(*proc_err))
>> cper_print_proc_generic(newpfx, proc_err);
>> else
>> goto err_section_too_small;
>> } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
>> - struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
>> + struct cper_sec_mem_err *mem_err;
>> +
>> + mem_err = acpi_hest_generic_data_payload(gdata);
>> printk("%s""section_type: memory error\n", newpfx);
>> if (gdata->error_data_length >=
>> sizeof(struct cper_sec_mem_err_old))
>> @@ -419,7 +450,9 @@ static void cper_estatus_print_section(
>> else
>> goto err_section_too_small;
>> } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
>> - struct cper_sec_pcie *pcie = (void *)(gdata + 1);
>> + struct cper_sec_pcie *pcie;
>> +
>> + pcie = acpi_hest_generic_data_payload(gdata);
>> printk("%s""section_type: PCIe error\n", newpfx);
>> if (gdata->error_data_length >= sizeof(*pcie))
>> cper_print_pcie(newpfx, pcie, gdata);
>> @@ -438,7 +471,7 @@ void cper_estatus_print(const char *pfx,
>> const struct acpi_hest_generic_status *estatus)
>> {
>> struct acpi_hest_generic_data *gdata;
>> - unsigned int data_len, gedata_len;
>> + unsigned int data_len;
>> int sec_no = 0;
>> char newpfx[64];
>> __u16 severity;
>> @@ -451,12 +484,13 @@ void cper_estatus_print(const char *pfx,
>> printk("%s""event severity: %s\n", pfx, cper_severity_str(severity));
>> data_len = estatus->data_length;
>> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
>> +
>> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
>> - while (data_len >= sizeof(*gdata)) {
>> - gedata_len = gdata->error_data_length;
>> +
>> + while (data_len >= acpi_hest_generic_data_size(gdata)) {
>> cper_estatus_print_section(newpfx, gdata, sec_no);
>> - data_len -= gedata_len + sizeof(*gdata);
>> - gdata = (void *)(gdata + 1) + gedata_len;
>> + data_len -= acpi_hest_generic_data_record_size(gdata);
>> + gdata = acpi_hest_generic_data_next(gdata);
>> sec_no++;
>> }
>> }
>> @@ -486,12 +520,13 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
>> return rc;
>> data_len = estatus->data_length;
>> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
>> - while (data_len >= sizeof(*gdata)) {
>> - gedata_len = gdata->error_data_length;
>> - if (gedata_len > data_len - sizeof(*gdata))
>> +
>> + while (data_len >= acpi_hest_generic_data_size(gdata)) {
>> + gedata_len = acpi_hest_generic_data_error_length(gdata);
>> + if (gedata_len > data_len - acpi_hest_generic_data_size(gdata))
>> return -EINVAL;
>> - data_len -= gedata_len + sizeof(*gdata);
>> - gdata = (void *)(gdata + 1) + gedata_len;
>> + data_len -= gedata_len + acpi_hest_generic_data_size(gdata);
>> + gdata = acpi_hest_generic_data_next(gdata);
>> }
>> if (data_len)
>> return -EINVAL;
>> diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
>> index 68f088a..6ae318b 100644
>> --- a/include/acpi/ghes.h
>> +++ b/include/acpi/ghes.h
>> @@ -12,6 +12,18 @@
>> #define GHES_TO_CLEAR 0x0001
>> #define GHES_EXITING 0x0002
>>
>> +#define acpi_hest_generic_data_error_length(gdata) \
>> + (((struct acpi_hest_generic_data *)(gdata))->error_data_length)
>> +#define acpi_hest_generic_data_size(gdata) \
>> + ((acpi_hest_generic_data_version(gdata) >= 3) ? \
>> + sizeof(struct acpi_hest_generic_data_v300) : \
>> + sizeof(struct acpi_hest_generic_data))
>> +#define acpi_hest_generic_data_record_size(gdata) \
>> + (acpi_hest_generic_data_size(gdata) + \
>> + acpi_hest_generic_data_error_length(gdata))
>> +#define acpi_hest_generic_data_next(gdata) \
>> + ((void *)(gdata) + acpi_hest_generic_data_record_size(gdata))
> This is one unreadable pile of too long names with a clearly redundant
> and too long prefix. Please shorten it all.
>
>> +
>> struct ghes {
>> union {
>> struct acpi_hest_generic *generic;
>> @@ -73,3 +85,13 @@ static inline void ghes_edac_unregister(struct ghes *ghes)
>> {
>> }
>> #endif
>> +
>> +#define acpi_hest_generic_data_version(gdata) \
>> + (gdata->revision >> 8)
>> +
>> +static inline void *acpi_hest_generic_data_payload(struct acpi_hest_generic_data *gdata)
> Lemme try to shorten it:
>
> static inline void *acpi_hest_get_payload(struct acpi_hest_gdata *d)
> {
> if (hest_gdata_ver(d) >= 3)
> return (void *)(((struct acpi_hest_gdata_v3 *)d) + 1);
> else
> return d + 1;
> }
>
> Now this is much more readable IMO. You can actually see what's going
> on. And you still know what the struct names are.
>
> So let's drop all that unnecessary too long prefixing and make the
> code readable. That cper thing needs a lot more scrubbing, of course,
> but some other day.
I do not agree with this. The struct being passed to this function is
already named acpi_hest_generic_data in the existing code and all over
this code is named gdata not just d.
Also, these helpers already helped this code be significantly more
readable. They were added in version 4 of this series to reduce code
duplication and make iterating over the generic data entries readable.
https://lkml.org/lkml/2016/10/11/454
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v5 0/2] Handle Cavium ThunderX2 PCI topology quirk
From: Jayachandran C @ 2017-04-13 20:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Bjorn,
Here's v5 of the patchset with an updated commit message based on your
suggestion. I have added a paragraph at the end about MSI-X as well.
This is the newest in the series based on the discussion here:
https://www.spinics.net/lists/arm-kernel/msg575581.html
Previous discussions and patches:
http://www.spinics.net/lists/linux-pci/msg51001.html
https://patchwork.ozlabs.org/patch/582633/ and
https://lists.linuxfoundation.org/pipermail/iommu/2016-June/017681.html
Let me know if I missed anything, Thanks,
JC.
v4->v5:
- updated commit message for patch 2/2
v3->v4:
- new address of author
v2>v3:
- changed device flag name from PCI_DEV_FLAGS_DMA_ALIAS_ROOT to
PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT
- updated commit message to make the quirk clearer.
Jayachandran C (2):
PCI: Add device flag PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT
PCI: quirks: Fix ThunderX2 dma alias handling
drivers/pci/quirks.c | 14 ++++++++++++++
drivers/pci/search.c | 4 ++++
include/linux/pci.h | 2 ++
3 files changed, 20 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v5 1/2] PCI: Add device flag PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT
From: Jayachandran C @ 2017-04-13 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492115445-4069-1-git-send-email-jnair@caviumnetworks.com>
Add a new quirk flag PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT to limit the DMA
alias search to go no further than the bridge where the IOMMU unit is
attached.
The flag will be used to indicate a bridge device which forwards the
address translation requests to the IOMMU, i.e where the interrupt and
DMA requests leave the PCIe hierarchy and go into the system blocks.
Usually this happens at the PCI RC, so this flag is not needed. But
on systems where there are bridges that introduce aliases above the
"real" root bridge, this flag is needed to ensure that the function
pci_for_each_dma_alias() works correctly.
The function pci_for_each_dma_alias() is updated to stop when it see a
bridge with this flag set.
Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: David Daney <david.daney@cavium.com>
---
drivers/pci/search.c | 4 ++++
include/linux/pci.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 33e0f03..4c6044a 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -60,6 +60,10 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
tmp = bus->self;
+ /* stop at bridge where translation unit is associated */
+ if (tmp->dev_flags & PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT)
+ return ret;
+
/*
* PCIe-to-PCI/X bridges alias transactions from downstream
* devices using the subordinate bus number (PCI Express to
diff --git a/include/linux/pci.h b/include/linux/pci.h
index eb3da1a..3f596ac 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -178,6 +178,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
/* Get VPD from function 0 VPD */
PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
+ /* a non-root bridge where translation occurs, stop alias search here */
+ PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT = (__force pci_dev_flags_t) (1 << 9),
};
enum pci_irq_reroute_variant {
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Jayachandran C @ 2017-04-13 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492115445-4069-1-git-send-email-jnair@caviumnetworks.com>
On Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the
PCI topology is slightly unusual. For a multi-node system, it looks
like:
00:00.0 [PCI] bridge to [bus 01-1e]
01:0a.0 [PCI-PCIe bridge, type 8] bridge to [bus 02-04]
02:00.0 [PCIe root port, type 4] bridge to [bus 03-04] (XLATE_ROOT)
03:00.0 PCIe Endpoint
pci_for_each_dma_alias() assumes IOMMU translation is done at the root
of the PCI hierarchy. It generates 03:00.0, 01:0a.0, and 00:00.0 as
DMA aliases for 03:00.0 because buses 01 and 00 are non-PCIe buses that
doesn't carry the Requester ID.
Because the ThunderX2 IOMMU is at 02:00.0, the Requester IDs 01:0a.0
or 00:00.0 are never valid for the endpoint. This quirk stops alias
generation at the XLATE_ROOT bridge so we won't generate 01:0a.0 or
00:00.0
The current IOMMU code only maps the last alias (this is a separate bug
in itself). Prior to this quirk, we only created IOMMU mappings for the
invalid Requester ID 00:00:0, which never matched any DMA transactions.
With this quirk, we create IOMMU mappings for a valid Requester ID,
which fixes devices with no aliases but leaves devices with aliases
still broken.
The last alias for the endpoint is also used by the ARM GICv3 MSI-X
code. Without this quirk, the GIC Interrupt Translation Tables are
setup with the invalid Requester ID, and the MSI-X generated by the
device fails to be translated and routed.
Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: David Daney <david.daney@cavium.com>
---
drivers/pci/quirks.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6736836..564a84a 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3958,6 +3958,20 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2260, quirk_mic_x200_dma_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2264, quirk_mic_x200_dma_alias);
/*
+ * The IOMMU and interrupt controller on Broadcom Vulcan/Cavium ThunderX2 are
+ * associated not at the root bus, but at a bridge below. This quirk flag
+ * will ensure that the aliases are identified correctly.
+ */
+static void quirk_bridge_cavm_thrx2_pcie_root(struct pci_dev *pdev)
+{
+ pdev->dev_flags |= PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_BROADCOM, 0x9000,
+ quirk_bridge_cavm_thrx2_pcie_root);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_BROADCOM, 0x9084,
+ quirk_bridge_cavm_thrx2_pcie_root);
+
+/*
* Intersil/Techwell TW686[4589]-based video capture cards have an empty (zero)
* class code. Fix it.
*/
--
2.7.4
^ permalink raw reply related
* [PATCH V14 03/10] efi: parse ARM processor error
From: Baicar, Tyler @ 2017-04-13 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412165125.xzsovuficgbygkfp@pd.tnic>
On 4/12/2017 10:51 AM, Borislav Petkov wrote:
> On Tue, Mar 28, 2017 at 01:30:33PM -0600, Tyler Baicar wrote:
>> Add support for ARM Common Platform Error Record (CPER).
>> UEFI 2.6 specification adds support for ARM specific
>> processor error information to be reported as part of the
>> CPER records. This provides more detail on for processor error logs.
>>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Reviewed-by: James Morse <james.morse@arm.com>
>> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> drivers/firmware/efi/cper.c | 133 ++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/cper.h | 54 ++++++++++++++++++
>> 2 files changed, 187 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
>> index 8fa4e23..56aa516 100644
>> --- a/drivers/firmware/efi/cper.c
>> +++ b/drivers/firmware/efi/cper.c
>> @@ -110,12 +110,15 @@ void cper_print_bits(const char *pfx, unsigned int bits,
>> static const char * const proc_type_strs[] = {
>> "IA32/X64",
>> "IA64",
>> + "ARM",
>> };
>>
>> static const char * const proc_isa_strs[] = {
>> "IA32",
>> "IA64",
>> "X64",
>> + "ARM A32/T32",
>> + "ARM A64",
>> };
>>
>> static const char * const proc_error_type_strs[] = {
>> @@ -139,6 +142,18 @@ void cper_print_bits(const char *pfx, unsigned int bits,
>> "corrected",
>> };
>>
>> +static const char * const arm_reg_ctx_strs[] = {
>> + "AArch32 general purpose registers",
>> + "AArch32 EL1 context registers",
>> + "AArch32 EL2 context registers",
>> + "AArch32 secure context registers",
>> + "AArch64 general purpose registers",
>> + "AArch64 EL1 context registers",
>> + "AArch64 EL2 context registers",
>> + "AArch64 EL3 context registers",
>> + "Misc. system register structure",
>> +};
> That...
>
>> +
>> static void cper_print_proc_generic(const char *pfx,
>> const struct cper_sec_proc_generic *proc)
>> {
>> @@ -184,6 +199,114 @@ static void cper_print_proc_generic(const char *pfx,
>> printk("%s""IP: 0x%016llx\n", pfx, proc->ip);
>> }
>>
>> +static void cper_print_proc_arm(const char *pfx,
>> + const struct cper_sec_proc_arm *proc)
> ... and that function should go into:
>
> #if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
>
> Just put them close together so that you don't have too much ifdeffery.
Hello Boris,
I will move them close together and add the ifdef.
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 05/22] ARM: dts: at91: Add generic compatible string for I2C EEPROM
From: Peter Rosin @ 2017-04-13 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413182839.25381-6-javier@osg.samsung.com>
On 2017-04-13 20:28, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> Changes in v2: None
>
> arch/arm/boot/dts/at91-linea.dtsi | 2 +-
> arch/arm/boot/dts/at91-tse850-3.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/at91-linea.dtsi b/arch/arm/boot/dts/at91-linea.dtsi
> index 0721c8472509..9a19080fd3bf 100644
> --- a/arch/arm/boot/dts/at91-linea.dtsi
> +++ b/arch/arm/boot/dts/at91-linea.dtsi
> @@ -31,7 +31,7 @@
> status = "okay";
>
> eeprom at 51 {
> - compatible = "st,24c64";
> + compatible = "st,24c64","atmel,24c64";
> reg = <0x51>;
> pagesize = <32>;
> };
> diff --git a/arch/arm/boot/dts/at91-tse850-3.dts b/arch/arm/boot/dts/at91-tse850-3.dts
> index 7a68805a4eb5..6f005c14a6b0 100644
> --- a/arch/arm/boot/dts/at91-tse850-3.dts
> +++ b/arch/arm/boot/dts/at91-tse850-3.dts
> @@ -239,7 +239,7 @@
> };
>
> eeprom at 50 {
> - compatible = "nxp,24c02";
> + compatible = "nxp,24c02","atmel,24c02";
> reg = <0x50>;
> pagesize = <16>;
> };
>
Sure, in principle. But not having a space after the commas is a real OCD
trigger for me. My spine is rotating... :-)
Anyway, with those whitespace fixes (and without them too, but please):
Acked-by: Peter Rosin <peda@axentia.se>
Cheers,
peda
^ permalink raw reply
* [PATCH v4 1/2] ASoC: stm32: add bindings for SAI
From: Rob Herring @ 2017-04-13 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491925646-29113-2-git-send-email-olivier.moysan@st.com>
On Tue, Apr 11, 2017 at 05:47:25PM +0200, olivier moysan wrote:
> This patch adds documentation of device tree bindings for the
> STM32 SAI ASoC driver.
>
> Signed-off-by: olivier moysan <olivier.moysan@st.com>
> ---
> .../devicetree/bindings/sound/st,stm32-sai.txt | 89 ++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-sai.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> new file mode 100644
> index 0000000..c59a3d7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> @@ -0,0 +1,89 @@
> +STMicroelectronics STM32 Serial Audio Interface (SAI).
> +
> +The SAI interface (Serial Audio Interface) offers a wide set of audio protocols
> +as I2S standards, LSB or MSB-justified, PCM/DSP, TDM, and AC'97.
> +The SAI contains two independent audio sub-blocks. Each sub-block has
> +its own clock generator and I/O lines controller.
> +
> +Required properties:
> + - compatible: Should be "st,stm32f4-sai"
> + - reg: Base address and size of SAI common register set.
> + - clocks: Must contain phandle and clock specifier pairs for each entry
> + in clock-names.
> + - clock-names: Must contain "x8k" and "x11k"
> + "x8k": SAI parent clock for sampling rates multiple of 8kHz.
> + "x11k": SAI parent clock for sampling rates multiple of 11.025kHz.
> + - interrupts: cpu DAI interrupt line shared by SAI sub-blocks
> +
> +Optional properties:
> + - resets: Reference to a reset controller asserting the SAI
> +
> +SAI subnodes:
> +Two subnodes corresponding to SAI sub-block instances A et B can be defined.
> +Subnode can be omitted for unsused sub-block.
> +
> +SAI subnodes required properties:
> + - compatible: Should be "st,stm32-sai-sub-a" or "st,stm32-sai-sub-b"
> + for SAI sub-block A or B respectively.
> + - reg: Base address and size of SAI sub-block register set.
> + - clocks: Must contain one phandle and clock specifier pair
> + for sai_ck which feeds the internal clock generator.
> + - clock-names: Must contain "sai_ck".
> + - dmas: see Documentation/devicetree/bindings/dma/stm32-dma.txt
> + - dma-names: identifier string for each DMA request line
> + "tx": if sai sub-block is configured as playback DAI
> + "rx": if sai sub-block is configured as capture DAI
> + - pinctrl-names: should contain only value "default"
> + - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> +
> +Example:
> +sound_card {
> + compatible = "audio-graph-card";
> + dais = <&sai1b_port>;
> +};
> +
> +sai1: sai1 at 40015800 {
> + compatible = "st,stm32f4-sai";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
It's preferred if this is not empty and it limited to the address range
needed.
> + reg = <0x40015800 0x4>;
> + clocks = <&rcc 1 CLK_SAIQ_PDIV>, <&rcc 1 CLK_I2SQ_PDIV>;
> + clock-names = "x8k", "x11k";
> + interrupts = <87>;
> +
> + sai1b: audio-controller at 40015824 {
> + #sound-dai-cells = <0>;
> + compatible = "st,stm32-sai-sub-b";
> + reg = <0x40015824 0x1C>;
> + clocks = <&rcc 1 CLK_SAI2>;
> + clock-names = "sai_ck";
> + dmas = <&dma2 5 0 0x400 0x0>;
> + dma-names = "tx";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai1b>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sai1b_port: port at 0 {
Need to document how many ports and endpoints.
> + reg = <0>;
For a single port, you don't need a reg prop.
> + cpu_endpoint: endpoint {
> + remote-endpoint = <&codec_endpoint>;
> + audio-graph-card,format = "i2s";
> + audio-graph-card,bitclock-master = <&codec_endpoint>;
> + audio-graph-card,frame-master = <&codec_endpoint>;
The prefix is gone now.
> + };
> + };
> + };
> + };
> +};
> +
> +audio-codec {
> + codec_port: port {
> + codec_endpoint: endpoint {
> + remote-endpoint = <&cpu_endpoint>;
> + };
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* [RFC 4/8] regulator: core: Check enabling bypass respects constraints
From: Leonard Crestez @ 2017-04-13 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170407112212.gzv3p7ldkh62657m@sirena.org.uk>
On Fri, 2017-04-07 at 12:22 +0100, Mark Brown wrote:
> On Fri, Apr 07, 2017 at 01:51:52PM +0300, Leonard Crestez wrote:
> > It currently seems to work how I expect but from your statement it's
> > not clear if it's entirely intentional.
> The current behaviour of bypassed regulators is intentional.
I did not mean to imply that there is something wrong with bypassed
regulators. I just wanted more information about how regulators (non-
bypassed) pick their voltage when consumers allow a range.
After some more reading through the code it seems that the driver
itself receives the range (either through set_voltage or map_voltage)
and gets to make the choice.
So it seems fine for my concerns, sorry to bother you.
--
Regards,
Leonard
^ permalink raw reply
* [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
From: Borislav Petkov @ 2017-04-13 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a31ef45-68f6-d444-f174-4a485cccd696@codeaurora.org>
On Thu, Apr 13, 2017 at 02:30:21PM -0600, Baicar, Tyler wrote:
> I do not agree with this. The struct being passed to this function is
> already named acpi_hest_generic_data in the existing code and all over this
> code is named gdata not just d.
And I'm saying they're too long - the preexisting ones and the ones
you're adding - and impair readability. This whole driver is one
unreadable ugly pile and if I were the maintainer I would never allowed
it in its current form.
But I don't think it really has a maintainer - poor Rafael has to deal
with it because it is under drivers/acpi/ and that whole RAS firmware
crap got thrown over the wall at some point and now we're stuck with it.
So this is just my opinion since he asked me to take a look.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH V8 3/5] PCI/ASPM: add init hook to device_add
From: Bjorn Helgaas @ 2017-04-13 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491627351-1111-4-git-send-email-okaya@codeaurora.org>
Hi Sinan,
On Sat, Apr 08, 2017 at 12:55:49AM -0400, Sinan Kaya wrote:
> For bridges, have pcie_aspm_init_link_state() allocate a link_state,
> regardless of whether it currently has any children.
>
> pcie_aspm_init_link_state(): Called for bridges (upstream end of
> link) after all children have been enumerated. No longer needs to
> check aspm_support_enabled or pdev->has_secondary_link or the VIA
> quirk: pci_aspm_init() already checked that stuff, so we only need
> to check pdev->link_state here.
>
> Now that we are calling alloc_pcie_link_state() from pci_aspm_init()
> , get rid of pci_function_0 function and detect downstream link in
> pci_aspm_init_upstream() instead when the function number is 0.
>
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/pci/pcie/aspm.c | 72 ++++++++++++++++++++++++-------------------------
> 1 file changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index a80d64b..e33f84b 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -422,20 +422,6 @@ static void pcie_aspm_check_latency(struct pci_dev *endpoint)
> }
> }
>
> -/*
> - * The L1 PM substate capability is only implemented in function 0 in a
> - * multi function device.
> - */
> -static struct pci_dev *pci_function_0(struct pci_bus *linkbus)
> -{
> - struct pci_dev *child;
> -
> - list_for_each_entry(child, &linkbus->devices, bus_list)
> - if (PCI_FUNC(child->devfn) == 0)
> - return child;
> - return NULL;
> -}
> -
> /* Calculate L1.2 PM substate timing parameters */
> static void aspm_calc_l1ss_info(struct pcie_link_state *link,
> struct aspm_register_info *upreg,
> @@ -798,7 +784,6 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
> INIT_LIST_HEAD(&link->children);
> INIT_LIST_HEAD(&link->link);
> link->pdev = pdev;
> - link->downstream = pci_function_0(pdev->subordinate);
>
> /*
> * Root Ports and PCI/PCI-X to PCIe Bridges are roots of PCIe
> @@ -828,11 +813,33 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
>
> static int pci_aspm_init_downstream(struct pci_dev *pdev)
> {
> + struct pcie_link_state *link;
> + struct pci_dev *parent;
> +
> + /*
> + * The L1 PM substate capability is only implemented in function 0 in a
> + * multi function device.
> + */
> + if (PCI_FUNC(pdev->devfn) != 0)
> + return -EINVAL;
> +
> + parent = pdev->bus->self;
> + if (!parent)
> + return -EINVAL;
> +
> + link = parent->link_state;
> + link->downstream = pdev;
> return 0;
> }
>
> static int pci_aspm_init_upstream(struct pci_dev *pdev)
> {
> + struct pcie_link_state *link;
> +
> + link = alloc_pcie_link_state(pdev);
> + if (!link)
> + return -ENOMEM;
This allocates the link_state when we enumerate a Downstream Port
instead of when we enumerate a child device. We want the link_state
lifetime to match that of the Downstream Port, so this seems good.
But we shouldn't at the same time change the link_state deallocation
so it happens when the Downstream Port is removed, not when the child
device is removed?
> return 0;
> }
>
> @@ -843,6 +850,17 @@ static int pci_aspm_init_upstream(struct pci_dev *pdev)
> */
> int pci_aspm_init(struct pci_dev *pdev)
> {
> + if (!aspm_support_enabled)
> + return 0;
> +
> + if (!pci_is_pcie(pdev))
> + return -EINVAL;
> +
> + /* VIA has a strange chipset, root port is under a bridge */
> + if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT &&
> + pdev->bus->self)
> + return 0;
> +
> if (!pdev->has_secondary_link)
> return pci_aspm_init_downstream(pdev);
>
> @@ -859,33 +877,16 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
> struct pcie_link_state *link;
> int blacklist = !!pcie_aspm_sanity_check(pdev);
>
> - if (!aspm_support_enabled)
> - return;
> -
> - if (pdev->link_state)
> - return;
> -
> - /*
> - * We allocate pcie_link_state for the component on the upstream
> - * end of a Link, so there's nothing to do unless this device has a
> - * Link on its secondary side.
> - */
> - if (!pdev->has_secondary_link)
> - return;
> -
> - /* VIA has a strange chipset, root port is under a bridge */
> - if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT &&
> - pdev->bus->self)
> + if (!pdev->link_state)
> return;
>
> + link = pdev->link_state;
> down_read(&pci_bus_sem);
> if (list_empty(&pdev->subordinate->devices))
> goto out;
>
> mutex_lock(&aspm_lock);
> - link = alloc_pcie_link_state(pdev);
> - if (!link)
> - goto unlock;
> +
> /*
> * Setup initial ASPM state. Note that we need to configure
> * upstream links also because capable state of them can be
> @@ -910,7 +911,6 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
> pcie_set_clkpm(link, policy_to_clkpm_state(link));
> }
>
> -unlock:
> mutex_unlock(&aspm_lock);
> out:
> up_read(&pci_bus_sem);
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Fabio Estevam @ 2017-04-13 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANMBJr7We9uOyE6=BCWoe9L7xRKjOG6ScgtDGEgQ-hPawPeppg@mail.gmail.com>
On Thu, Apr 13, 2017 at 5:13 PM, Tyler Baker <tyler.baker@linaro.org> wrote:
> I've rebased this series on the next-20170413 for sanity sake, and
> realized there doesn't appear to be a way to select CONFIG_IMX_GPCV2.
> I forced it using 'default y' and configured with imx_v6_v7_defconfig.
> Now my board is booting. Before this series is applied, it may be good
> to have CONFIG_IMX_GPCV2 selected specifically for iMX7 platform,
> otherwise there will be boot regressions.
Something like this?
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index f03ef43..fe99a48 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -253,6 +253,7 @@ config RENESAS_H8S_INTC
config IMX_GPCV2
bool
+ def_bool y if SOC_IMX7D
select IRQ_DOMAIN
help
Enables the wakeup IRQs for IMX platforms with GPCv2 block
>
> I'd encounter a backtrace with next-20170413 + imx_v6_v7_defconfig +
> CONFIG_IMX_GPCV2=y
>
> Backtrace:
> [<c010c364>] (dump_backtrace) from [<c010c610>] (show_stack+0x18/0x1c)
but prior to fixing the Kconfig we need to fix this backtrace you reported.
Thanks
^ permalink raw reply related
* [PATCH 0/8][v2] arm64: defconfig: enable several options useful for ARM64 server platforms
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
ACPI-based ARM64 server platforms based, like the Qualcomm Datacenter
Technologies QDF2400, need several features and drivers enabled for
full functionality. This patchset enables many of those features.
The first patch, "resynchronize the defconfig" refreshes the ARM64
defconfig so that it's aligned with savedefconfig. This needs to be
done periodically, so that new patches avoid merge conflicts.
If the first patch does not apply cleanly, I ask the maintainer to
refresh it himself manually, following the instructions in the commit
message. The remaining 7 patches should apply cleanly on top of that.
Timur Tabi (8):
[v2] arm64: defconfig: resynchronize the defconfig
arm64: defconfig: enable ACPI_CPPC_CPUFREQ
arm64: defconfig: enable BLK_DEV_NVME
[v2] arm64: defconfig: enable EFI_CAPSULE_LOADER
arm64: defconfig: enable support for PCIe hotplug
arm64: defconfig: enable APEI and GHES features
[v2] arm64: defconfig: enable EDAC options
arm64: defconfig: enable QCOM_L2_PMU and QCOM_L3_PMU
arch/arm64/configs/defconfig | 114 ++++++++++++++++++++-----------------------
1 file changed, 54 insertions(+), 60 deletions(-)
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/8] [v2] arm64: defconfig: resynchronize the defconfig
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492116683-26399-1-git-send-email-timur@codeaurora.org>
Defconfig files become unsynchronized over time as Kconfig entries are
added, removed, or changed. Making specific changes to the defconfig
becomes difficult as unrelated differences can interfere. This problem
is easily remedied:
make defconfig
make savedefconfig
cp defconfig arch/arm64/configs/defconfig
git add arch/arm64/configs/defconfig
git commit -s
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 102 ++++++++++++++++++-------------------------
1 file changed, 42 insertions(+), 60 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 478bc68..17eb452 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -30,7 +30,6 @@ CONFIG_PROFILING=y
CONFIG_JUMP_LABEL=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_ALPINE=y
@@ -62,16 +61,15 @@ CONFIG_ARCH_XGENE=y
CONFIG_ARCH_ZX=y
CONFIG_ARCH_ZYNQMP=y
CONFIG_PCI=y
-CONFIG_PCI_MSI=y
CONFIG_PCI_IOV=y
-CONFIG_PCI_AARDVARK=y
-CONFIG_PCIE_RCAR=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_XGENE=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
CONFIG_PCIE_QCOM=y
CONFIG_PCIE_ARMADA_8K=y
+CONFIG_PCI_AARDVARK=y
+CONFIG_PCIE_RCAR=y
+CONFIG_PCI_HOST_GENERIC=y
+CONFIG_PCI_XGENE=y
CONFIG_ARM64_VA_BITS_48=y
CONFIG_SCHED_MC=y
CONFIG_NUMA=y
@@ -80,12 +78,11 @@ CONFIG_KSM=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_CMA=y
CONFIG_SECCOMP=y
-CONFIG_XEN=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
+CONFIG_XEN=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_COMPAT=y
-CONFIG_CPU_IDLE=y
CONFIG_HIBERNATION=y
CONFIG_ARM_CPUIDLE=y
CONFIG_CPU_FREQ=y
@@ -155,8 +152,8 @@ CONFIG_MTD_SPI_NOR=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_VIRTIO_BLK=y
-CONFIG_EEPROM_AT25=m
CONFIG_SRAM=y
+CONFIG_EEPROM_AT25=m
# CONFIG_SCSI_PROC_FS is not set
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_SAS_ATA=y
@@ -168,8 +165,8 @@ CONFIG_AHCI_CEVA=y
CONFIG_AHCI_MVEBU=y
CONFIG_AHCI_XGENE=y
CONFIG_AHCI_QORIQ=y
-CONFIG_SATA_RCAR=y
CONFIG_SATA_SIL24=y
+CONFIG_SATA_RCAR=y
CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
CONFIG_NETDEVICES=y
@@ -186,18 +183,17 @@ CONFIG_HNS_ENET=y
CONFIG_E1000E=y
CONFIG_IGB=y
CONFIG_IGBVF=y
-CONFIG_MVPP2=y
CONFIG_MVNETA=y
+CONFIG_MVPP2=y
CONFIG_SKY2=y
CONFIG_RAVB=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=m
-CONFIG_REALTEK_PHY=m
+CONFIG_MDIO_BUS_MUX_MMIOREG=y
CONFIG_MESON_GXL_PHY=m
CONFIG_MICREL_PHY=y
-CONFIG_MDIO_BUS_MUX=y
-CONFIG_MDIO_BUS_MUX_MMIOREG=y
+CONFIG_REALTEK_PHY=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_RTL8152=m
@@ -230,14 +226,14 @@ CONFIG_SERIAL_8250_UNIPHIER=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_MESON=y
+CONFIG_SERIAL_MESON_CONSOLE=y
CONFIG_SERIAL_SAMSUNG=y
CONFIG_SERIAL_SAMSUNG_CONSOLE=y
CONFIG_SERIAL_TEGRA=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=11
CONFIG_SERIAL_SH_SCI_CONSOLE=y
-CONFIG_SERIAL_MESON=y
-CONFIG_SERIAL_MESON_CONSOLE=y
CONFIG_SERIAL_MSM=y
CONFIG_SERIAL_MSM_CONSOLE=y
CONFIG_SERIAL_XILINX_PS_UART=y
@@ -261,14 +257,14 @@ CONFIG_I2C_UNIPHIER_F=y
CONFIG_I2C_RCAR=y
CONFIG_I2C_CROS_EC_TUNNEL=y
CONFIG_SPI=y
-CONFIG_SPI_MESON_SPIFC=m
CONFIG_SPI_BCM2835=m
CONFIG_SPI_BCM2835AUX=m
+CONFIG_SPI_MESON_SPIFC=m
CONFIG_SPI_ORION=y
CONFIG_SPI_PL022=y
CONFIG_SPI_QUP=y
-CONFIG_SPI_SPIDEV=m
CONFIG_SPI_S3C64XX=y
+CONFIG_SPI_SPIDEV=m
CONFIG_SPMI=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_PINCTRL_MAX77620=y
@@ -286,39 +282,36 @@ CONFIG_GPIO_PCA953X=y
CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_GPIO_MAX77620=y
CONFIG_POWER_RESET_MSM=y
-CONFIG_BATTERY_BQ27XXX=y
CONFIG_POWER_RESET_XGENE=y
CONFIG_POWER_RESET_SYSCON=y
+CONFIG_BATTERY_BQ27XXX=y
+CONFIG_SENSORS_ARM_SCPI=y
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_INA2XX=m
-CONFIG_SENSORS_ARM_SCPI=y
-CONFIG_THERMAL=y
-CONFIG_THERMAL_EMULATION=y
CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
CONFIG_CPU_THERMAL=y
-CONFIG_BCM2835_THERMAL=y
+CONFIG_THERMAL_EMULATION=y
CONFIG_EXYNOS_THERMAL=y
+CONFIG_BCM2835_THERMAL=y
CONFIG_WATCHDOG=y
-CONFIG_BCM2835_WDT=y
-CONFIG_RENESAS_WDT=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_MESON_GXBB_WATCHDOG=m
CONFIG_MESON_WATCHDOG=m
+CONFIG_RENESAS_WDT=y
+CONFIG_BCM2835_WDT=y
+CONFIG_MFD_CROS_EC=y
+CONFIG_MFD_CROS_EC_I2C=y
CONFIG_MFD_EXYNOS_LPASS=m
+CONFIG_MFD_HI655X_PMIC=y
CONFIG_MFD_MAX77620=y
-CONFIG_MFD_RK808=y
CONFIG_MFD_SPMI_PMIC=y
+CONFIG_MFD_RK808=y
CONFIG_MFD_SEC_CORE=y
-CONFIG_MFD_HI655X_PMIC=y
-CONFIG_REGULATOR=y
-CONFIG_MFD_CROS_EC=y
-CONFIG_MFD_CROS_EC_I2C=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_HI655X=y
CONFIG_REGULATOR_MAX77620=y
CONFIG_REGULATOR_PWM=y
-CONFIG_REGULATOR_QCOM_SMD_RPM=y
CONFIG_REGULATOR_QCOM_SPMI=y
CONFIG_REGULATOR_RK808=y
CONFIG_REGULATOR_S2MPS11=y
@@ -345,13 +338,12 @@ CONFIG_DRM_EXYNOS_DSI=y
CONFIG_DRM_EXYNOS_HDMI=y
CONFIG_DRM_EXYNOS_MIC=y
CONFIG_DRM_RCAR_DU=m
-CONFIG_DRM_RCAR_HDMI=y
CONFIG_DRM_RCAR_LVDS=y
CONFIG_DRM_RCAR_VSP=y
CONFIG_DRM_TEGRA=m
-CONFIG_DRM_VC4=m
CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_VC4=m
CONFIG_DRM_HISI_KIRIN=m
CONFIG_DRM_MESON=m
CONFIG_FB=y
@@ -366,26 +358,24 @@ CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_SOC=y
CONFIG_SND_BCM2835_SOC_I2S=m
-CONFIG_SND_SOC_RCAR=y
CONFIG_SND_SOC_SAMSUNG=y
+CONFIG_SND_SOC_RCAR=y
CONFIG_SND_SOC_AK4613=y
CONFIG_USB=y
CONFIG_USB_OTG=y
CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_XHCI_PLATFORM=y
-CONFIG_USB_XHCI_RCAR=y
-CONFIG_USB_EHCI_EXYNOS=y
CONFIG_USB_XHCI_TEGRA=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_MSM=y
+CONFIG_USB_EHCI_EXYNOS=y
CONFIG_USB_EHCI_HCD_PLATFORM=y
-CONFIG_USB_OHCI_EXYNOS=y
CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_EXYNOS=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
CONFIG_USB_RENESAS_USBHS=m
CONFIG_USB_STORAGE=y
-CONFIG_USB_DWC2=y
CONFIG_USB_DWC3=y
+CONFIG_USB_DWC2=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
@@ -398,7 +388,6 @@ CONFIG_USB_RENESAS_USBHS_UDC=m
CONFIG_MMC=y
CONFIG_MMC_BLOCK_MINORS=32
CONFIG_MMC_ARMMMCI=y
-CONFIG_MMC_MESON_GX=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ACPI=y
CONFIG_MMC_SDHCI_PLTFM=y
@@ -406,6 +395,7 @@ CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
CONFIG_MMC_SDHCI_CADENCE=y
CONFIG_MMC_SDHCI_TEGRA=y
+CONFIG_MMC_MESON_GX=y
CONFIG_MMC_SDHCI_MSM=y
CONFIG_MMC_SPI=y
CONFIG_MMC_SDHI=y
@@ -421,25 +411,24 @@ CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_PWM=y
CONFIG_LEDS_SYSCON=y
-CONFIG_LEDS_TRIGGERS=y
-CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_MAX77686=y
+CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_S5M=y
CONFIG_RTC_DRV_DS3232=y
CONFIG_RTC_DRV_EFI=y
+CONFIG_RTC_DRV_S3C=y
CONFIG_RTC_DRV_PL031=y
CONFIG_RTC_DRV_SUN6I=y
-CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_TEGRA=y
CONFIG_RTC_DRV_XGENE=y
-CONFIG_RTC_DRV_S3C=y
CONFIG_DMADEVICES=y
+CONFIG_DMA_BCM2835=m
CONFIG_MV_XOR_V2=y
CONFIG_PL330_DMA=y
-CONFIG_DMA_BCM2835=m
CONFIG_TEGRA20_APB_DMA=y
CONFIG_QCOM_BAM_DMA=y
CONFIG_QCOM_HIDMA_MGMT=y
@@ -452,18 +441,17 @@ CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
+CONFIG_COMMON_CLK_RK808=y
CONFIG_COMMON_CLK_SCPI=y
CONFIG_COMMON_CLK_CS2000_CP=y
CONFIG_COMMON_CLK_S2MPS11=y
-CONFIG_COMMON_CLK_PWM=y
-CONFIG_COMMON_CLK_RK808=y
CONFIG_CLK_QORIQ=y
+CONFIG_COMMON_CLK_PWM=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_MSM_GCC_8916=y
CONFIG_MSM_GCC_8994=y
CONFIG_MSM_MMCC_8996=y
CONFIG_HWSPINLOCK_QCOM=y
-CONFIG_MAILBOX=y
CONFIG_ARM_MHU=y
CONFIG_PLATFORM_MHU=y
CONFIG_BCM2835_MBOX=y
@@ -472,32 +460,29 @@ CONFIG_ARM_SMMU=y
CONFIG_ARM_SMMU_V3=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD=y
-CONFIG_QCOM_SMD_RPM=y
CONFIG_ROCKCHIP_PM_DOMAINS=y
CONFIG_ARCH_TEGRA_132_SOC=y
CONFIG_ARCH_TEGRA_210_SOC=y
CONFIG_ARCH_TEGRA_186_SOC=y
CONFIG_EXTCON_USB_GPIO=y
+CONFIG_IIO=y
+CONFIG_EXYNOS_ADC=y
CONFIG_PWM=y
CONFIG_PWM_BCM2835=m
+CONFIG_PWM_MESON=m
CONFIG_PWM_ROCKCHIP=y
+CONFIG_PWM_SAMSUNG=y
CONFIG_PWM_TEGRA=m
-CONFIG_PWM_MESON=m
-CONFIG_COMMON_RESET_HI6220=y
CONFIG_PHY_RCAR_GEN3_USB2=y
CONFIG_PHY_HI6220_USB=y
+CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_ROCKCHIP_INNO_USB2=y
CONFIG_PHY_ROCKCHIP_EMMC=y
-CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_XGENE=y
CONFIG_PHY_TEGRA_XUSB=y
CONFIG_ARM_SCPI_PROTOCOL=y
-CONFIG_ACPI=y
-CONFIG_IIO=y
-CONFIG_EXYNOS_ADC=y
-CONFIG_PWM_SAMSUNG=y
CONFIG_RASPBERRYPI_FIRMWARE=y
+CONFIG_ACPI=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
@@ -511,7 +496,6 @@ CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_OVERLAY_FS=m
CONFIG_VFAT_FS=y
-CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
@@ -539,11 +523,9 @@ CONFIG_MEMTEST=y
CONFIG_SECURITY=y
CONFIG_CRYPTO_ECHAINIV=y
CONFIG_CRYPTO_ANSI_CPRNG=y
-CONFIG_CRYPTO_DEV_SAFEXCEL=m
CONFIG_ARM64_CRYPTO=y
CONFIG_CRYPTO_SHA1_ARM64_CE=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y
CONFIG_CRYPTO_GHASH_ARM64_CE=y
CONFIG_CRYPTO_AES_ARM64_CE_CCM=y
CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
-# CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 2/8] arm64: defconfig: enable ACPI_CPPC_CPUFREQ
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492116683-26399-1-git-send-email-timur@codeaurora.org>
The CPPC CPUFreq driver is used on many ACPI-based ARM64 server systems.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 17eb452..345f6d8 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -89,6 +89,7 @@ CONFIG_CPU_FREQ=y
CONFIG_CPUFREQ_DT=y
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_ARM_SCPI_CPUFREQ=y
+CONFIG_ACPI_CPPC_CPUFREQ=m
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 3/8] arm64: defconfig: enable BLK_DEV_NVME
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492116683-26399-1-git-send-email-timur@codeaurora.org>
NVME is non-volatile storage media attached via PCIe. NVME devices
typically have much higher potential throughput than other block
devices, like SATA, NVME is a must-have requirement for ARM64 based
servers.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 345f6d8..71bc81e 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -153,6 +153,7 @@ CONFIG_MTD_SPI_NOR=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_VIRTIO_BLK=y
+CONFIG_BLK_DEV_NVME=m
CONFIG_SRAM=y
CONFIG_EEPROM_AT25=m
# CONFIG_SCSI_PROC_FS is not set
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 4/8] [v2] arm64: defconfig: enable EFI_CAPSULE_LOADER
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492116683-26399-1-git-send-email-timur@codeaurora.org>
CONFIG_EFI_CAPSULE_LOADER allows the user to update the EFI firmware,
which is useful on ARM64 server platforms.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 71bc81e..5c7082d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -484,6 +484,7 @@ CONFIG_PHY_XGENE=y
CONFIG_PHY_TEGRA_XUSB=y
CONFIG_ARM_SCPI_PROTOCOL=y
CONFIG_RASPBERRYPI_FIRMWARE=y
+CONFIG_EFI_CAPSULE_LOADER=y
CONFIG_ACPI=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 5/8] arm64: defconfig: enable support for PCIe hotplug
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492116683-26399-1-git-send-email-timur@codeaurora.org>
Some ARM64 server systems support PCIe hotplug, so enable the options
for that.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5c7082d..318c0aa 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -61,7 +61,10 @@ CONFIG_ARCH_XGENE=y
CONFIG_ARCH_ZX=y
CONFIG_ARCH_ZYNQMP=y
CONFIG_PCI=y
+CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_PCI_IOV=y
+CONFIG_HOTPLUG_PCI=y
+CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
CONFIG_PCIE_QCOM=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 6/8] arm64: defconfig: enable APEI and GHES features
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492116683-26399-1-git-send-email-timur@codeaurora.org>
ARM64 server platforms can support ACPI Platform Error Interface (APEI)
and Generic Hardware Error Source (GHES) features, so enable them.
Platforms which support the firmware-first RAS error reporting model
require APEI and GHES functionality for the OS to receive and report
error records provided by the platform.
PCIe AER functionality is required for PCIe AER errors to be properly
reported and recovered from.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 318c0aa..f24890d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -489,6 +489,9 @@ CONFIG_ARM_SCPI_PROTOCOL=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_EFI_CAPSULE_LOADER=y
CONFIG_ACPI=y
+CONFIG_ACPI_APEI=y
+CONFIG_ACPI_APEI_GHES=y
+CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 7/8] [v2] arm64: defconfig: enable EDAC options
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492116683-26399-1-git-send-email-timur@codeaurora.org>
Enable EDAC (Error Detection and Correction) support for ARM64 server
systems that feature it, so that user space applications can be
notified of memory errors.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f24890d..fef2475 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -419,6 +419,7 @@ CONFIG_LEDS_SYSCON=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_EDAC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_MAX77686=y
CONFIG_RTC_DRV_RK808=m
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 8/8] arm64: defconfig: enable QCOM_L2_PMU and QCOM_L3_PMU
From: Timur Tabi @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492116683-26399-1-git-send-email-timur@codeaurora.org>
Now that the drivers are available, enable support for L2 and L3
performance monitoring Qualcomm Datacenter Technologies Centriq SoCs.
These PMU drivers provide support for performance optimization.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index fef2475..d02e2bb 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -486,6 +486,8 @@ CONFIG_PHY_ROCKCHIP_INNO_USB2=y
CONFIG_PHY_ROCKCHIP_EMMC=y
CONFIG_PHY_XGENE=y
CONFIG_PHY_TEGRA_XUSB=y
+CONFIG_QCOM_L2_PMU=y
+CONFIG_QCOM_L3_PMU=y
CONFIG_ARM_SCPI_PROTOCOL=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_EFI_CAPSULE_LOADER=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V8 1/5] PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()
From: Bjorn Helgaas @ 2017-04-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491627351-1111-2-git-send-email-okaya@codeaurora.org>
Hi Sinan,
On Sat, Apr 08, 2017 at 12:55:47AM -0400, Sinan Kaya wrote:
> We need a callback from pci_init_capabilities function for every
> single new PCI device that is currently being added.
>
> pci_aspm_init() will be used to save the power on state of the HW.
>
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/pci/pcie/aspm.c | 10 ++++++++++
> drivers/pci/probe.c | 3 +++
> include/linux/pci.h | 2 ++
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 1dfa10c..dc36717 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -827,6 +827,16 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
> }
>
> /*
> + * pci_aspm_init: Initiate PCI express link state.
> + * It is called from device_add for every single pci device.
> + * @pdev: all pci devices
> + */
> +int pci_aspm_init(struct pci_dev *pdev)
> +{
> + return 0;
> +}
> +
> +/*
> * pcie_aspm_init_link_state: Initiate PCI express link state.
> * It is called after the pcie and its children devices are scanned.
> * @pdev: the root port or switch downstream port
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index dfc9a27..1e19364 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1847,6 +1847,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
>
> /* Advanced Error Reporting */
> pci_aer_init(dev);
> +
> + /* Active State Power Management */
> + pci_aspm_init(dev);
> }
>
> /*
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index eb3da1a..8828dd7 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1396,8 +1396,10 @@ static inline int pci_irq_get_node(struct pci_dev *pdev, int vec)
>
> #ifdef CONFIG_PCIEASPM
> bool pcie_aspm_support_enabled(void);
> +int pci_aspm_init(struct pci_dev *pdev);
I think these can go in drivers/pci/pci.h instead of the public
include/linux/pci.h. There's no ASPM section in drivers/pci/pci.h
yet, but I think we should add one.
It looks like the following things from include/linux/pci-aspm.h could
be moved there as well, since they're only used by the PCI core:
void pcie_aspm_init_link_state(struct pci_dev *pdev);
void pcie_aspm_exit_link_state(struct pci_dev *pdev);
void pcie_aspm_pm_state_change(struct pci_dev *pdev);
void pcie_aspm_powersave_config_link(struct pci_dev *pdev);
void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev);
void pcie_aspm_remove_sysfs_dev_files(struct pci_dev *pdev);
This would be a separate patch.
> #else
> static inline bool pcie_aspm_support_enabled(void) { return false; }
> +static inline int pci_aspm_init(struct pci_dev *pdev) { return -ENODEV; }
> #endif
>
> #ifdef CONFIG_PCIEAER
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V8 3/5] PCI/ASPM: add init hook to device_add
From: Bjorn Helgaas @ 2017-04-13 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413204800.GB28316@bhelgaas-glaptop.roam.corp.google.com>
On Thu, Apr 13, 2017 at 03:48:00PM -0500, Bjorn Helgaas wrote:
> Hi Sinan,
>
> On Sat, Apr 08, 2017 at 12:55:49AM -0400, Sinan Kaya wrote:
> > For bridges, have pcie_aspm_init_link_state() allocate a link_state,
> > regardless of whether it currently has any children.
> >
> > pcie_aspm_init_link_state(): Called for bridges (upstream end of
> > link) after all children have been enumerated. No longer needs to
> > check aspm_support_enabled or pdev->has_secondary_link or the VIA
> > quirk: pci_aspm_init() already checked that stuff, so we only need
> > to check pdev->link_state here.
> >
> > Now that we are calling alloc_pcie_link_state() from pci_aspm_init()
> > , get rid of pci_function_0 function and detect downstream link in
> > pci_aspm_init_upstream() instead when the function number is 0.
> >
> > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> > ---
> > drivers/pci/pcie/aspm.c | 72 ++++++++++++++++++++++++-------------------------
> > 1 file changed, 36 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index a80d64b..e33f84b 100644
> > --- a/drivers/pci/pcie/aspm.c
> > +++ b/drivers/pci/pcie/aspm.c
> > @@ -422,20 +422,6 @@ static void pcie_aspm_check_latency(struct pci_dev *endpoint)
> > }
> > }
> >
> > -/*
> > - * The L1 PM substate capability is only implemented in function 0 in a
> > - * multi function device.
> > - */
> > -static struct pci_dev *pci_function_0(struct pci_bus *linkbus)
> > -{
> > - struct pci_dev *child;
> > -
> > - list_for_each_entry(child, &linkbus->devices, bus_list)
> > - if (PCI_FUNC(child->devfn) == 0)
> > - return child;
> > - return NULL;
> > -}
> > -
> > /* Calculate L1.2 PM substate timing parameters */
> > static void aspm_calc_l1ss_info(struct pcie_link_state *link,
> > struct aspm_register_info *upreg,
> > @@ -798,7 +784,6 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
> > INIT_LIST_HEAD(&link->children);
> > INIT_LIST_HEAD(&link->link);
> > link->pdev = pdev;
> > - link->downstream = pci_function_0(pdev->subordinate);
> >
> > /*
> > * Root Ports and PCI/PCI-X to PCIe Bridges are roots of PCIe
> > @@ -828,11 +813,33 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev)
> >
> > static int pci_aspm_init_downstream(struct pci_dev *pdev)
> > {
> > + struct pcie_link_state *link;
> > + struct pci_dev *parent;
> > +
> > + /*
> > + * The L1 PM substate capability is only implemented in function 0 in a
> > + * multi function device.
> > + */
> > + if (PCI_FUNC(pdev->devfn) != 0)
> > + return -EINVAL;
> > +
> > + parent = pdev->bus->self;
> > + if (!parent)
> > + return -EINVAL;
> > +
> > + link = parent->link_state;
> > + link->downstream = pdev;
> > return 0;
> > }
> >
> > static int pci_aspm_init_upstream(struct pci_dev *pdev)
> > {
> > + struct pcie_link_state *link;
> > +
> > + link = alloc_pcie_link_state(pdev);
> > + if (!link)
> > + return -ENOMEM;
>
> This allocates the link_state when we enumerate a Downstream Port
> instead of when we enumerate a child device. We want the link_state
> lifetime to match that of the Downstream Port, so this seems good.
>
> But we shouldn't at the same time change the link_state deallocation
> so it happens when the Downstream Port is removed, not when the child
> device is removed?
I do see that you change the deallocation in patch [5/5], but I think
the deallocation change should be in the same patch as the allocation
change. Otherwise I think we have a use-after-free problem in this
sequence:
# initial enumeration
pci_device_add(downstream_port)
pci_aspm_init(downstream_port)
alloc_pcie_link_state
pci_device_add(endpoint)
pci_aspm_init(endpoint)
# hot-remove endpoint
pci_stop_dev(endpoint)
pcie_aspm_exit_link_state(endpoint)
link = parent->link_state
free_link_state(link)
# hot-add endpoint
pci_aspm_init(endpoint)
link = parent->link_state <--- use after free
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox