* [PATCH] PCI: Add pci=safemode option
From: Sinan Kaya @ 2018-05-30 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530043103.GA19734@kroah.com>
On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote:
> On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
>> Adding pci=safemode kernel command line parameter to turn off all PCI
>> Express service driver as well as all optional PCIe features such as LTR,
>> Extended tags, Relaxed Ordering etc.
>>
>> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
>> reconfigured with by the kernel in case BIOS hands off a broken
>> configuration.
>
> Why not fix the BIOS? That's what sane platforms do :)
>
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 2 ++
>> drivers/pci/pci.c | 7 +++++++
>> drivers/pci/pci.h | 2 ++
>> drivers/pci/pcie/portdrv_core.c | 2 +-
>> drivers/pci/probe.c | 6 ++++++
>> 5 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 641ec9c..247adbb 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3153,6 +3153,8 @@
>> noari do not use PCIe ARI.
>> noats [PCIE, Intel-IOMMU, AMD-IOMMU]
>> do not use PCIe ATS (and IOMMU device IOTLB).
>> + safemode turns of all optinal PCI features. Useful
>> + for bringup/troubleshooting.
>
> s/optinal/optional/ ?
sure.
>
> And you should explain what exactly in PCI is "optional". Who defines
> this and where is that list and what can go wrong if those options are
> not enabled?
Bjorn and I discussed the need for such a "safe" mode feature when you
want to bring up PCI for a platform. You want to turn off everything as
a starter and just stick to bare minimum.
I can add a few words describing them. The goal of this option is to keep
base PCI features with MSI only. Things like PME, AER, ASPM, Extended
Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode
is certainly not intended for production environments.
I can taint the kernel as a suggestion.
I defined minimum as just booting a device and to be able to do DMA traffic
only with 0 optimization
>
> In looking at your patch, I can't determine that at all, so there's no
> way that someone just looking at this sentence will be able to
> understand.
>
> thanks,
>
> greg k-h
>
--
Sinan Kaya
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 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-30 4:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPcyV=fdRu7oLXHMimSFR9ktJ23uBriswTStkEkAMbTaNw@mail.gmail.com>
On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
> Thanks for the patch.
>
> In case of Exynos, the booting CPU always has these information in DT
> and the booting CPU cannot be changed (chosen by firmware/hardware
> configuration).
But can the booting CPU be offlined ?
If yes, then this is how things are broken right now.
Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert
cpufreq driver and that will try to find these properties in CPU1.
> Therefore there is no real risk of falling although
> for correctness of DT your change makes sense.
>
> It is too late for this cycle for me so I'll pick it up after merge window.
> Alternatively, arm-soc guys can pick it up directly with my tag:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
No worries, you can pick it up later on.
--
viresh
^ permalink raw reply
* [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-05-30 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527654876-26716-1-git-send-email-okaya@codeaurora.org>
On 5/29/2018 9:34 PM, Sinan Kaya wrote:
> -int early_pci_allowed(void)
> -{
> - return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
> - PCI_PROBE_CONF1;
> -}
I should have kept this. I'll wait for more feedback before posting the
next rev.
--
Sinan Kaya
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] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-05-30 4:34 UTC (permalink / raw)
To: linux-arm-kernel
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 --
arch/x86/pci/early.c | 50 -------------------------
drivers/pci/pci.c | 4 ++
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 19 ++++++++++
8 files changed, 25 insertions(+), 66 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index c247612..4459270 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2986,7 +2986,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8 offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..e20d449 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -51,53 +51,3 @@ void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val)
outw(val, 0xcfc + (offset&2));
}
-int early_pci_allowed(void)
-{
- return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
- PCI_PROBE_CONF1;
-}
-
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0xffffffff)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
- if (func == 0) {
- type = read_pci_config_byte(bus, slot,
- func,
- PCI_HEADER_TYPE);
- if (!(type & 0x80))
- break;
- }
- }
- }
- }
-}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7c03701..ae5a2ae 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,8 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+bool pci_early_dump;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5848,6 +5850,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "earlydump")) {
+ pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
pci_realloc_get_opt(str + 8);
} else if (!strncmp(str, "realloc", 7)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..9c66b7d 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -7,7 +7,7 @@
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
extern const unsigned char pcie_link_speed[];
-
+extern bool pci_early_dump;
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
/* Functions internal to the PCI core code */
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 3840207..b1f068d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1549,6 +1549,22 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
return 0;
}
+static void early_dump_pci_device(struct pci_dev *pdev)
+{
+ u32 value[256 / 4];
+ int i;
+
+ dev_info(&pdev->dev, "pci 0000:%02x:%02x.%d config space:\n",
+ pdev->bus->number, PCI_SLOT(pdev->devfn),
+ PCI_FUNC(pdev->devfn));
+
+ for (i = 0; i < 256; i += 4)
+ pci_read_config_dword(pdev, i, &value[i / 4]);
+
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
+ 256, false);
+}
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -1598,6 +1614,9 @@ int pci_setup_device(struct pci_dev *dev)
pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
dev->vendor, dev->device, dev->hdr_type, dev->class);
+ if (pci_early_dump)
+ early_dump_pci_device(dev);
+
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH] PCI: Add pci=safemode option
From: Greg Kroah-Hartman @ 2018-05-30 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527650389-31575-1-git-send-email-okaya@codeaurora.org>
On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
> Adding pci=safemode kernel command line parameter to turn off all PCI
> Express service driver as well as all optional PCIe features such as LTR,
> Extended tags, Relaxed Ordering etc.
>
> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
> reconfigured with by the kernel in case BIOS hands off a broken
> configuration.
Why not fix the BIOS? That's what sane platforms do :)
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 ++
> drivers/pci/pci.c | 7 +++++++
> drivers/pci/pci.h | 2 ++
> drivers/pci/pcie/portdrv_core.c | 2 +-
> drivers/pci/probe.c | 6 ++++++
> 5 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 641ec9c..247adbb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3153,6 +3153,8 @@
> noari do not use PCIe ARI.
> noats [PCIE, Intel-IOMMU, AMD-IOMMU]
> do not use PCIe ATS (and IOMMU device IOTLB).
> + safemode turns of all optinal PCI features. Useful
> + for bringup/troubleshooting.
s/optinal/optional/ ?
And you should explain what exactly in PCI is "optional". Who defines
this and where is that list and what can go wrong if those options are
not enabled?
In looking at your patch, I can't determine that at all, so there's no
way that someone just looking at this sentence will be able to
understand.
thanks,
greg k-h
^ permalink raw reply
* Status of aspeed-bmc-opp-firestone (IBM S822LC)
From: Andrew Jeffery @ 2018-05-30 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <287c6a85-65ba-5782-e532-d17d517614f5@molgen.mpg.de>
Hi Paul,
On Wed, 30 May 2018, at 00:23, Paul Menzel wrote:
> Dear Joel, dear Linux folks,
>
>
> We have an IBM S822LC system (Firestone(?)). Building of OpenBMC
> currently fails, as the not everything was ported from dev-4.10 to
> dev-4.13 [1], and therefore a file cannot be found.
>
> Looking at upstream Linux, there are BMCs for Power 8 systems, like
> Palmetto, included.
>
> ```
> $ ls arch/arm/boot/dts/aspeed-bmc-opp-*
> arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> ```
>
> Does somebody know, why Firestone was not upstreamed? Is somebody
> working on upstreaming it? If not, do you have scripts to port such
> work? Manually cherry-picking stuff in this case is hard, as there are a
> lot of conflicts.
Firestone was never really maintained. We hacked around with it for a bit, but nothing concrete really came of it. As far as I'm aware, no-one is working on upstreaming it.
Also, I don't think there were any scripts used in the process, so it's going to be some drudge work to get things running.
Sorry that I don't have a more positive answer. Maybe someone else knows better.
Cheers,
Andrew
^ permalink raw reply
* [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Nixiaoming @ 2018-05-30 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529154523.GK17159@arm.com>
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64
When reading the code, I feel it is more appropriate to add macro control here.
-----Original Message-----
From: Will Deacon [mailto:will.deacon at arm.com]
Sent: Tuesday, May 29, 2018 11:45 PM
To: Nixiaoming <nixiaoming@huawei.com>
Cc: catalin.marinas at arm.com; ard.biesheuvel at linaro.org; marc.zyngier at arm.com; james.morse at arm.com; kristina.martsenko at arm.com; steve.capper at arm.com; tglx at linutronix.de; mingo at redhat.com; hpa at zytor.com; akpm at linux-foundation.org; vbabka at suse.cz; mhocko at suse.com; dave.hansen at linux.intel.com; dan.j.williams at intel.com; kirill.shutemov at linux.intel.com; zhang.jia at linux.alibaba.com; schwidefsky at de.ibm.com; heiko.carstens at de.ibm.com; gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; x86 at kernel.org; linux-s390 at vger.kernel.org
Subject: Re: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly when
> CONFIG_STRICT_KERNEL_RWX=y,
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
How are you achieving this configuration? In our Kconfig we select this
unconditionally.
Will
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: Sinan Kaya @ 2018-05-30 3:19 UTC (permalink / raw)
To: linux-arm-kernel
Adding pci=safemode kernel command line parameter to turn off all PCI
Express service driver as well as all optional PCIe features such as LTR,
Extended tags, Relaxed Ordering etc.
Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
reconfigured with by the kernel in case BIOS hands off a broken
configuration.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
drivers/pci/pci.c | 7 +++++++
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/portdrv_core.c | 2 +-
drivers/pci/probe.c | 6 ++++++
5 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 641ec9c..247adbb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3153,6 +3153,8 @@
noari do not use PCIe ARI.
noats [PCIE, Intel-IOMMU, AMD-IOMMU]
do not use PCIe ATS (and IOMMU device IOTLB).
+ safemode turns of all optinal PCI features. Useful
+ for bringup/troubleshooting.
pcie_scan_all Scan all possible PCIe devices. Otherwise we
only look for one device below a PCIe downstream
port.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d27f771..11f0282 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, disables most of the optional PCI features */
+bool pci_safe_mode;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5845,6 +5848,10 @@ static int __init pci_setup(char *str)
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
+ } else if (!strncmp(str, "safemode", 8)) {
+ pr_info("PCI: safe mode with minimum features\n");
+ pci_safe_mode = true;
+ pcie_bus_config = PCIE_BUS_SAFE;
} else if (!strncmp(str, "noats", 5)) {
pr_info("PCIe: ATS is disabled\n");
pcie_ats_disabled = true;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..4517bcd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -8,6 +8,8 @@
extern const unsigned char pcie_link_speed[];
+extern bool pci_safe_mode;
+
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
/* Functions internal to the PCI core code */
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index a5b3b3a..9fe4ed6 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -311,7 +311,7 @@ int pcie_port_device_register(struct pci_dev *dev)
/* Get and check PCI Express port services */
capabilities = get_port_device_capability(dev);
- if (!capabilities)
+ if (!capabilities || pci_safe_mode)
return 0;
pci_set_master(dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 3840207..295b79c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2047,6 +2047,9 @@ static void pci_configure_device(struct pci_dev *dev)
struct hotplug_params hpp;
int ret;
+ if (pci_safe_mode)
+ return;
+
pci_configure_mps(dev);
pci_configure_extended_tags(dev, NULL);
pci_configure_relaxed_ordering(dev);
@@ -2213,6 +2216,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Setup MSI caps & disable MSI/MSI-X interrupts */
pci_msi_setup_pci_dev(dev);
+ if (pci_safe_mode)
+ return;
+
/* Buffers for saving PCIe and PCI-X capabilities */
pci_allocate_cap_save_buffers(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
From: Sinan Kaya @ 2018-05-30 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525221024.GC92995@bhelgaas-glaptop.roam.corp.google.com>
Bjorn,
On 5/25/2018 3:10 PM, Bjorn Helgaas wrote:
> On Fri, May 25, 2018 at 09:30:59AM -0400, Sinan Kaya wrote:
>> On 5/24/2018 2:35 PM, Bjorn Helgaas wrote:
>>> That sounds like a reasonable idea, and it is definitely another can
>>> of worms. I looked briefly at some of the .shutdown() cases:
>>
>> should we throw it into 4.18 and see what happens?
>
> It wouldn't solve this particular problem because hpsa *does* have a
> .shutdown() method. The problem is that it doesn't work -- it's
> supposed to stop DMA and interrupts but it apparently doesn't.
>
> I think we need to fix hpsa first.
>
I don't know if you followed my latest V3 patch but I found a way to put
these two together to reach to an, IMO, more acceptable solution.
Sinan
--
Sinan Kaya
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] PCI: mediatek: Add system pm support for MT2712
From: honghui.zhang at mediatek.com @ 2018-05-30 2:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Honghui Zhang <honghui.zhang@mediatek.com>
The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
the internel control register will be reset after system resume. The PCIe
link should be re-established and the related control register values should
be re-set after system resume.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
CC: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 82 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index dabf1086..60f98d92 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -132,12 +132,14 @@ struct mtk_pcie_port;
/**
* struct mtk_pcie_soc - differentiate between host generations
* @need_fix_class_id: whether this host's class ID needed to be fixed or not
+ * @pm_support: whether the host's MTCMOS will be off when suspend
* @ops: pointer to configuration access functions
* @startup: pointer to controller setting functions
* @setup_irq: pointer to initialize IRQ functions
*/
struct mtk_pcie_soc {
bool need_fix_class_id;
+ bool pm_support;
struct pci_ops *ops;
int (*startup)(struct mtk_pcie_port *port);
int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
@@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
}
+static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct mtk_pcie *pcie;
+ struct mtk_pcie_port *port;
+ const struct mtk_pcie_soc *soc;
+
+ pdev = to_platform_device(dev);
+ pcie = platform_get_drvdata(pdev);
+ soc = pcie->soc;
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ clk_disable_unprepare(port->ahb_ck);
+ clk_disable_unprepare(port->sys_ck);
+ phy_power_off(port->phy);
+ }
+
+ return 0;
+}
+
+static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct mtk_pcie *pcie;
+ struct mtk_pcie_port *port;
+ const struct mtk_pcie_soc *soc;
+ int ret;
+
+ pdev = to_platform_device(dev);
+ pcie = platform_get_drvdata(pdev);
+ soc = pcie->soc;
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ ret = phy_power_on(port->phy);
+ if (ret) {
+ dev_err(dev, "could not power on phy\n");
+ return ret;
+ }
+ ret = clk_prepare_enable(port->sys_ck);
+ if (ret) {
+ dev_err(dev, "enable sys clock error\n");
+ phy_power_off(port->phy);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(port->ahb_ck);
+ if (ret) {
+ dev_err(dev, "enable ahb clock error\n");
+ phy_power_off(port->phy);
+ clk_disable_unprepare(port->sys_ck);
+ return ret;
+ }
+
+ ret = soc->startup(port);
+ if (ret) {
+ dev_err(dev, "pcie linkup failed\n");
+ phy_power_off(port->phy);
+ clk_disable_unprepare(port->sys_ck);
+ clk_disable_unprepare(port->ahb_ck);
+ return ret;
+ }
+
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ mtk_pcie_enable_msi(port);
+ }
+
+ return 0;
+}
+
+const struct dev_pm_ops mtk_pcie_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
+ mtk_pcie_resume_noirq)
+};
+
static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
.ops = &mtk_pcie_ops,
.startup = mtk_pcie_startup_port,
};
static const struct mtk_pcie_soc mtk_pcie_soc_mt2712 = {
+ .pm_support = true,
.ops = &mtk_pcie_ops_v2,
.startup = mtk_pcie_startup_port_v2,
.setup_irq = mtk_pcie_setup_irq,
@@ -1211,6 +1292,7 @@ static struct platform_driver mtk_pcie_driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
.suppress_bind_attrs = true,
+ .pm = &mtk_pcie_pm_ops,
},
};
builtin_platform_driver(mtk_pcie_driver);
--
2.6.4
^ permalink raw reply related
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Pratyush Anand @ 2018-05-30 2:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpO8KVVD_6ZJTW2SiyR8v0uDMA3H9yKHNw1=RKO+fd7KjA@mail.gmail.com>
Hi Bhupesh,
On Mon, May 28, 2018 at 2:33 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> Hi ARM64 maintainers,
[...]
>
> 4. Since 'memstart_addr' indicates the start of physical RAM, we
> randomize the same on basis of 'memstart_offset_seed' value above.
> Also the 'memstart_addr' value is available in '/proc/kallsyms' and
> hence can be accessed by user-space applications to read the
> 'memstart_addr' value.
User space can read, only when a system has either CONFIG_DEVMEM or
CONFIG_PROC_KCORE enabled. But, we can have a system which has
CONFIG_RANDOMIZE_BASE enabled but none of the kernel memory access
interface (other than kdump/vmcore).
>
> 5. Now since the PAGE_OFFSET value is also used by several user space
> tools (for e.g. makedumpfile tool uses the same to determine the start
> of linear region and hence to read PT_NOTE fields from /proc/kcore), I
> am not sure how to read the randomized value of the same in the KASLR
> enabled case.
>
Do we have a use case other than makedumpfile (I mean where we do not
have vmcore access)? For makedumpfile, we have following information
in vmcore, and I hope, that should be sufficient to find physical
address of any symbol from vmcore.
358 VMCOREINFO_NUMBER(VA_BITS);
359 /* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
360 vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
361 kimage_voffset);
362 vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
363 PHYS_OFFSET);
Regards
Pratyush
^ permalink raw reply
* [PATCH V3 2/2] scsi: hpsa: drop shutdown callback
From: Ryan Finnie @ 2018-05-30 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527542471-10316-2-git-send-email-okaya@codeaurora.org>
On 05/28/2018 02:21 PM, Sinan Kaya wrote:
> 'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during
> shutdown")' has been added to kernel to shutdown pending PCIe port
> service interrupts during reboot so that a newly started kexec kernel
> wouldn't observe pending interrupts.
>
> pcie_port_device_remove() is disabling the root port and switches by
> calling pci_disable_device() after all PCIe service drivers are shutdown.
>
> This has been found to cause crashes on HP DL360 Gen9 machines during
> reboot due to hpsa driver not clearing the bus master bit during the
> shutdown procedure by calling pci_disable_device().
>
> Drop the shutdown API and do an orderly clean up by using the remove.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
> Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
> Cc: stable at vger.kernel.org
> Reported-by: Ryan Finnie <ryan@finnie.org>
Tested successfully on DL360 Gen9 and DL380 Gen9.
Tested-by: Ryan Finnie <ryan@finnie.org>
^ permalink raw reply
* [PATCH V3 1/2] PCI: Try to clean up resources via remove if shutdown doesn't exist
From: Ryan Finnie @ 2018-05-30 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527542471-10316-1-git-send-email-okaya@codeaurora.org>
On 05/28/2018 02:21 PM, Sinan Kaya wrote:
> It is up to a driver to implement shutdown() callback. If shutdown()
> callback is not implemented, PCI device can have pending interrupt and
> even do DMA transactions while the system is going down.
>
> If kexec is in use, this can damage the newly booting kexec kernel
> or even prevent it from booting altogether. Fallback to calling the
> remove() callback if shutdown() isn't implemented for a given driver.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
> Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
> Cc: stable at vger.kernel.org
> Reported-by: Ryan Finnie <ryan@finnie.org>
Tested successfully on DL360 Gen9 and DL380 Gen9.
Tested-by: Ryan Finnie <ryan@finnie.org>
^ permalink raw reply
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Anson Huang @ 2018-05-30 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e0690c89b24b4b028e4a0dab63334af4b37fdd3.camel@nxp.com>
Hi, Leonard
Anson Huang
Best Regards!
> -----Original Message-----
> From: Leonard Crestez
> Sent: Tuesday, May 29, 2018 10:03 PM
> To: Anson Huang <anson.huang@nxp.com>; shawnguo at kernel.org; Andrey
> Smirnov <andrew.smirnov@gmail.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>; Abel Vesa
> <abel.vesa@nxp.com>; Richard Liu <xuegang.liu@nxp.com>
> Subject: Re: [PATCH] soc: imx: gpcv2: correct PGC offset
>
> On Tue, 2018-05-29 at 16:02 +0800, Anson Huang wrote:
> > Correct MIPI/PCIe/USB_HSIC's PGC offset based on design RTL, the value
> > on Reference Manual are incorrect.
> >
> > The correct offset should be as below:
> >
> > -#define PGC_MIPI 4
> > -#define PGC_PCIE 5
> > -#define PGC_USB_HSIC 8
> > +#define PGC_MIPI 16
> > +#define PGC_PCIE 17
> > +#define PGC_USB_HSIC 20
> > #define GPC_PGC_CTRL(n) (0x800 + (n) * 0x40)
> > #define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc)
>
> This gpcv2 driver is currently only used for PCI, it probably only works because
> domains happen to be turned on by default?
I think so.
>
> On imx7d upstream platform suspend is not yet supported but even doing
> device-level suspend causes a hang on resume somewhere in PCI on first read.
> This patch fixes that immediate hang.
I just added the imx7d platform suspend/resume support using psci in u-boot, patches
are sent out for review.
I did notice PCI resume cause system hang, the root cause is PCI controller registers
can NOT be accessed after resume, and the PCI PHY PLL is NOT locked when issue happen,
the PCI driver should implement suspend/resume and redo the init flow after resume, since
its power VDD1P0D are OFF after suspend.
I saw you sent out patch to fix it, thanks.
Anson.
>
> After suspend/resume lspci is broken (device doesn't properly resume), that
> probably requires more imx pci patches and unrelated to pgc.
>
> --
> Regards,
> Leonard
^ permalink raw reply
* [PATCH V2] soc: imx: gpcv2: correct PGC offset
From: Anson Huang @ 2018-05-30 1:30 UTC (permalink / raw)
To: linux-arm-kernel
Correct MIPI/PCIe/USB_HSIC's PGC offset based on
design RTL, the values in the Reference Manual
(Rev. 1, 01/2018 and the older ones) are incorrect.
The correct offset values should be as below:
0x800 ~ 0x83F: PGC for core0 of A7 platform;
0x840 ~ 0x87F: PGC for core1 of A7 platform;
0x880 ~ 0x8BF: PGC for SCU of A7 platform;
0xA00 ~ 0xA3F: PGC for fastmix/megamix;
0xC00 ~ 0xC3F: PGC for MIPI PHY;
0xC40 ~ 0xC7F: PGC for PCIe_PHY;
0xC80 ~ 0xCBF: PGC for USB OTG1 PHY;
0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY;
0xD00 ~ 0xD3F: PGC for USB HSIC PHY;
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
changes since V1:
add comment in code to make it more readable;
improve the commit message.
drivers/soc/imx/gpcv2.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index f4e3bd4..6ef18cf 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -39,10 +39,15 @@
#define GPC_M4_PU_PDN_FLG 0x1bc
-
-#define PGC_MIPI 4
-#define PGC_PCIE 5
-#define PGC_USB_HSIC 8
+/*
+ * The PGC offset values in Reference Manual
+ * (Rev. 1, 01/2018 and the older ones) GPC chapter's
+ * GPC_PGC memory map are incorrect, below offset
+ * values are from design RTL.
+ */
+#define PGC_MIPI 16
+#define PGC_PCIE 17
+#define PGC_USB_HSIC 20
#define GPC_PGC_CTRL(n) (0x800 + (n) * 0x40)
#define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc)
--
2.7.4
^ permalink raw reply related
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Anson Huang @ 2018-05-30 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHQ1cqF1-zkR_wQgRK1M3Wd+Hvha+St3jT=-Qvn1RM8N88qW8Q@mail.gmail.com>
Hi, Andrey
Anson Huang
Best Regards!
> -----Original Message-----
> From: Andrey Smirnov [mailto:andrew.smirnov at gmail.com]
> Sent: Wednesday, May 30, 2018 7:11 AM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <s.hauer@pengutronix.de>; Sascha Hauer <kernel@pengutronix.de>; Fabio
> Estevam <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel <linux-arm-kernel@lists.infradead.org>; linux-kernel
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH] soc: imx: gpcv2: correct PGC offset
>
> On Tue, May 29, 2018 at 1:02 AM, Anson Huang <Anson.Huang@nxp.com>
> wrote:
> > Correct MIPI/PCIe/USB_HSIC's PGC offset based on design RTL, the value
> > on Reference Manual are incorrect.
> >
>
> Nit: I'd s/the value on/the values in the/ here.
>
> > The correct offset should be as below:
> >
> > 0x800 ~ 0x83F: PGC for core0 of A7 platform;
> > 0x840 ~ 0x87F: PGC for core1 of A7 platform;
> > 0x880 ~ 0x8BF: PGC for SCU of A7 platform;
> > 0xA00 ~ 0xA3F: PGC for fastmix/megamix;
> > 0xC00 ~ 0xC3F: PGC for MIPI PHY;
> > 0xC40 ~ 0xC7F: PGC for PCIe_PHY;
> > 0xC80 ~ 0xCBF: PGC for USB OTG1 PHY;
> > 0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY;
> > 0xD00 ~ 0xD3F: PGC for USB HSIC PHY;
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > drivers/soc/imx/gpcv2.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c index
> > afc7ecc..132c946 100644
> > --- a/drivers/soc/imx/gpcv2.c
> > +++ b/drivers/soc/imx/gpcv2.c
> > @@ -40,9 +40,9 @@
> > #define GPC_M4_PU_PDN_FLG 0x1bc
> >
> >
> > -#define PGC_MIPI 4
> > -#define PGC_PCIE 5
> > -#define PGC_USB_HSIC 8
> > +#define PGC_MIPI 16
> > +#define PGC_PCIE 17
> > +#define PGC_USB_HSIC 20
>
> As a suggestion, please add a comment explicitly saying that those values
> might differ from what some version of the RM might specify.
> Explanation in commit message is great, but seeing a note in the code might
> save quite a bit of digging for someone who is reading the code, double
> checking those values and thinking that they might be wrong.
>
> Other than that:
>
> Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>
> Thanks,
> Andrey Smirnov
Thanks, I will improve them in V2 patch.
Anson.
^ permalink raw reply
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: Andy Shevchenko @ 2018-05-30 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-3-git-send-email-ray.jui@broadcom.com>
On Wed, May 30, 2018 at 12:58 AM, Ray Jui <ray.jui@broadcom.com> wrote:
> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
> INTD share the same interrupt line connected to the GIC in the system,
> while the status of each INTx can be obtained through the INTX CSR
> register
> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
> + SYS_RC_INTX_MASK) != 0) {
> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(dev, "unexpected INTx%u\n", bit);
> + }
> + }
do {
status = ...;
for_each_set_bit() {
...
}
} while (status);
would look slightly better for my opinion.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
From: Leo Yan @ 2018-05-30 0:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkzEU90aVtPMRqf=YHzee8DHq8JZttRuxjLKGz-gRYiBuw@mail.gmail.com>
Hi Mathieu,
On Tue, May 29, 2018 at 10:04:49AM -0600, Mathieu Poirier wrote:
[...]
> > As now this patch is big with more complex logic, so I consider to
> > split it into small patches:
> >
> > - Define CS_ETM_INVAL_ADDR;
> > - Fix for CS_ETM_TRACE_ON packet;
> > - Fix for exception packet;
> >
> > Does this make sense for you? I have concern that this patch is a
> > fixing patch, so not sure after spliting patches will introduce
> > trouble for applying them for other stable kernels ...
>
> Reverse the order:
>
> - Fix for CS_ETM_TRACE_ON packet;
> - Fix for exception packet;
> - Define CS_ETM_INVAL_ADDR;
>
> But you may not need to - see next comment.
>From the discussion context, I think here 'you may not need to' is
referring to my concern for applying patches on stable kernel, so I
should take this patch series as an enhancement and don't need to
consider much for stable kernel.
On the other hand, your suggestion is possible to mean 'not need
to' split into small patches (though I guess this is misunderstanding
for your meaning).
Could you clarify which is your meaning?
> >> > +
> >> > + /*
> >> > * The packet records the execution range with an exclusive end address
> >> > *
> >> > * A64 instructions are constant size, so the last executed
> >> > @@ -505,6 +519,18 @@ static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
> >> > return packet->end_addr - A64_INSTR_SIZE;
> >> > }
> >> >
> >> > +static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
> >> > +{
> >> > + /*
> >> > + * The packet is the CS_ETM_TRACE_ON packet if the start_addr is
> >> > + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
> >> > + */
> >> > + if (packet->start_addr == 0xdeadbeefdeadbeefUL)
> >> > + return 0;
> >>
> >> Same comment as above.
> >
> > Will do this.
> >
> >> > +
> >> > + return packet->start_addr;
> >> > +}
> >> > +
> >> > static inline u64 cs_etm__instr_count(const struct cs_etm_packet *packet)
> >> > {
> >> > /*
> >> > @@ -546,7 +572,7 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq)
> >> >
> >> > be = &bs->entries[etmq->last_branch_pos];
> >> > be->from = cs_etm__last_executed_instr(etmq->prev_packet);
> >> > - be->to = etmq->packet->start_addr;
> >> > + be->to = cs_etm__first_executed_instr(etmq->packet);
> >> > /* No support for mispredict */
> >> > be->flags.mispred = 0;
> >> > be->flags.predicted = 1;
> >> > @@ -701,7 +727,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq)
> >> > sample.ip = cs_etm__last_executed_instr(etmq->prev_packet);
> >> > sample.pid = etmq->pid;
> >> > sample.tid = etmq->tid;
> >> > - sample.addr = etmq->packet->start_addr;
> >> > + sample.addr = cs_etm__first_executed_instr(etmq->packet);
> >> > sample.id = etmq->etm->branches_id;
> >> > sample.stream_id = etmq->etm->branches_id;
> >> > sample.period = 1;
> >> > @@ -897,13 +923,28 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
> >> > etmq->period_instructions = instrs_over;
> >> > }
> >> >
> >> > - if (etm->sample_branches &&
> >> > - etmq->prev_packet &&
> >> > - etmq->prev_packet->sample_type == CS_ETM_RANGE &&
> >> > - etmq->prev_packet->last_instr_taken_branch) {
> >> > - ret = cs_etm__synth_branch_sample(etmq);
> >> > - if (ret)
> >> > - return ret;
> >> > + if (etm->sample_branches && etmq->prev_packet) {
> >> > + bool generate_sample = false;
> >> > +
> >> > + /* Generate sample for start tracing packet */
> >> > + if (etmq->prev_packet->sample_type == 0 ||
> >>
> >> What kind of packet is sample_type == 0 ?
> >
> > Just as explained above, sample_type == 0 is the packet which
> > initialized in the function cs_etm__alloc_queue().
> >
> >> > + etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
> >> > + generate_sample = true;
> >> > +
> >> > + /* Generate sample for exception packet */
> >> > + if (etmq->prev_packet->exc == true)
> >> > + generate_sample = true;
> >>
> >> Please don't do that. Exception packets have a type of their own and can be
> >> added to the decoder packet queue the same way INST_RANGE and TRACE_ON packets
> >> are. Moreover exception packet containt an address that, if I'm reading the
> >> documenation properly, can be used to keep track of instructions that were
> >> executed between the last address of the previous range packet and the address
> >> executed just before the exception occurred. Mike and Rob will have to confirm
> >> this as the decoder may be doing all that hard work for us.
> >
> > Sure, will wait for Rob and Mike to confirm for this.
> >
> > At my side, I dump the packet, the exception packet isn't passed to
> > cs-etm.c layer, the decoder layer only sets the flag
> > 'packet->exc = true' when exception packet is coming [1].
>
> That's because we didn't need the information. Now that we do a
> function that will insert a packet in the decoder packet queue and
> deal with the new packet type in the main decoder loop [2]. At that
> point your work may not be eligible for stable anymore and I think it
> is fine. Robert's work was an enhancement over mine and yours is an
> enhancement over his.
>
> [2]. https://elixir.bootlin.com/linux/v4.17-rc7/source/tools/perf/util/cs-etm.c#L999
Agree, will look into for exception packet and try to add new packet
type for this.
[...]
Thanks,
Leo Yan
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2018-05-29 23:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/include/asm/cputype.h
between commit:
1067a8130b17 ("ARM: add more CPU part numbers for Cortex and Brahma B15 CPUs")
from the arm tree and commits:
9e35ddc962a6 ("ARM: add Broadcom Brahma-B53 main ID definition")
842fa17d6c95 ("ARM: add Broadcom Brahma-B15 main ID definition")
from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/include/asm/cputype.h
index 26021980504d,d1b62ee69f3b..000000000000
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@@ -77,15 -75,11 +75,16 @@@
#define ARM_CPU_PART_CORTEX_A12 0x4100c0d0
#define ARM_CPU_PART_CORTEX_A17 0x4100c0e0
#define ARM_CPU_PART_CORTEX_A15 0x4100c0f0
+#define ARM_CPU_PART_CORTEX_A53 0x4100d030
+#define ARM_CPU_PART_CORTEX_A57 0x4100d070
+#define ARM_CPU_PART_CORTEX_A72 0x4100d080
+#define ARM_CPU_PART_CORTEX_A73 0x4100d090
+#define ARM_CPU_PART_CORTEX_A75 0x4100d0a0
#define ARM_CPU_PART_MASK 0xff00fff0
- /* Broadcom cores */
+ /* Broadcom implemented processors */
#define ARM_CPU_PART_BRAHMA_B15 0x420000f0
+ #define ARM_CPU_PART_BRAHMA_B53 0x42001000
/* DEC implemented cores */
#define ARM_CPU_PART_SA1100 0x4400a110
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/9058fefc/attachment.sig>
^ permalink raw reply
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Andrey Smirnov @ 2018-05-29 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e0690c89b24b4b028e4a0dab63334af4b37fdd3.camel@nxp.com>
On Tue, May 29, 2018 at 7:02 AM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> On Tue, 2018-05-29 at 16:02 +0800, Anson Huang wrote:
>> Correct MIPI/PCIe/USB_HSIC's PGC offset based on
>> design RTL, the value on Reference Manual are incorrect.
>>
>> The correct offset should be as below:
>>
>> -#define PGC_MIPI 4
>> -#define PGC_PCIE 5
>> -#define PGC_USB_HSIC 8
>> +#define PGC_MIPI 16
>> +#define PGC_PCIE 17
>> +#define PGC_USB_HSIC 20
>> #define GPC_PGC_CTRL(n) (0x800 + (n) * 0x40)
>> #define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc)
>
> This gpcv2 driver is currently only used for PCI, it probably only
> works because domains happen to be turned on by default?
>
That'd be my guess as well. I just tried commenting all of the code
related to GPC_PGC_CTRL in gpcv2 drive and PCIe still worked on my
SabreSD board.
> On imx7d upstream platform suspend is not yet supported but even doing
> device-level suspend causes a hang on resume somewhere in PCI on first
> read. This patch fixes that immediate hang.
>
> After suspend/resume lspci is broken (device doesn't properly resume),
> that probably requires more imx pci patches and unrelated to pgc.
>
Yeah, suspend of any kind was not a part of the use-case for me when I
was working on this driver, so it's not surprising to hear that it
doesn't work very well.
Thanks,
Andrey Smirnov
^ permalink raw reply
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Andrey Smirnov @ 2018-05-29 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527580944-10043-1-git-send-email-Anson.Huang@nxp.com>
On Tue, May 29, 2018 at 1:02 AM, Anson Huang <Anson.Huang@nxp.com> wrote:
> Correct MIPI/PCIe/USB_HSIC's PGC offset based on
> design RTL, the value on Reference Manual are incorrect.
>
Nit: I'd s/the value on/the values in the/ here.
> The correct offset should be as below:
>
> 0x800 ~ 0x83F: PGC for core0 of A7 platform;
> 0x840 ~ 0x87F: PGC for core1 of A7 platform;
> 0x880 ~ 0x8BF: PGC for SCU of A7 platform;
> 0xA00 ~ 0xA3F: PGC for fastmix/megamix;
> 0xC00 ~ 0xC3F: PGC for MIPI PHY;
> 0xC40 ~ 0xC7F: PGC for PCIe_PHY;
> 0xC80 ~ 0xCBF: PGC for USB OTG1 PHY;
> 0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY;
> 0xD00 ~ 0xD3F: PGC for USB HSIC PHY;
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> drivers/soc/imx/gpcv2.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index afc7ecc..132c946 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -40,9 +40,9 @@
> #define GPC_M4_PU_PDN_FLG 0x1bc
>
>
> -#define PGC_MIPI 4
> -#define PGC_PCIE 5
> -#define PGC_USB_HSIC 8
> +#define PGC_MIPI 16
> +#define PGC_PCIE 17
> +#define PGC_USB_HSIC 20
As a suggestion, please add a comment explicitly saying that those
values might differ from what some version of the RM might specify.
Explanation in commit message is great, but seeing a note in the code
might save quite a bit of digging for someone who is reading the code,
double checking those values and thinking that they might be wrong.
Other than that:
Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Thanks,
Andrey Smirnov
^ permalink raw reply
* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Russell King - ARM Linux @ 2018-05-29 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a43ce521-ed7f-6126-4ebf-5e0e303d00a3@gmail.com>
On Tue, May 29, 2018 at 03:45:12PM -0700, Frank Rowand wrote:
> If the kernel applies the overlay, an alternative to drivers is that the
> kernel could receive the overlay(s) in a similar manner as the method it
> currently receives the base devicetree. (The overlay(s) could be
> appended to the base devicetree, a wrapper could be placed around the
No wrappers, sorry. We already have too many places in the Linux
kernel and its decompressor that try to work out whether a device
tree or ATAGs are present and how large, and that is done in assembly
code. We don't need more complexity to deal with some kind of
wrapping of device trees as well.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Frank Rowand @ 2018-05-29 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529173314.GN17671@n2100.armlinux.org.uk>
On 05/29/18 10:33, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote:
>> On 05/22/18 13:01, Rob Herring wrote:
>>> I'll tell you up front, I'm not a fan of FIT image (nor uImage,
>>> Android boot image, $bootloader image). If you want a collection of
>>> files and some configuration data, use a filesystem and a text file.
>
> Me neither.
>
>> My gut feel is that using a filesystem and a text file is the easier way
>> to create the boot info. But that also makes applying the overlay(s)
>> during early Linux boot (at the point of FDT unflattening) impractical
>> (can't access the file system without a driver, the driver depends on
>> the devicetree, the devicetree depends upon the overlay).
>
> Why do you want to apply overlays during the kernel boot? The boot
> loader should be providing the kernel with the merged DT to describe
> the system that the kernel is running on - it's not the kernel's
> job to put that together.
I would much prefer that overlays get applied before the unflattened
devicetree is made available to the kernel instead of applying overlays
late in the boot (after many susbsystems and drivers are initialized)
or after boot.
If overlays are applied before the unflattened devicetree is made
available to the kernel then subsystems and drivers do not have to be
aware of the possibility of the data in the devicetree changing instead
of being invariant. (I will call this "apply early overlays" later in
this email.)
There are use cases of overlays where the overlay is not available until
late in the boot, or after the boot completes. I am not suggesting that
those use cases be ignored. That is a completely different conversation.
If overlays are applied before the unflattened devicetree is made
available to the kernel, there are at least two obvious methods
(and I can think of at least one more) -- either the kernel does it
or the bootloader does it. I do not see either of the two as being
the obvious and only correct choice. If the kernel does it, then
there is no need for multiple bootloaders to implement the same code.
If the bootloaders do it, then there is no need for multiple kernels
(Linux, BSD, etc) to implement the same code. I do not have a
strong opinion about whether the bootloaders or the kernels are a
better place to apply early overlays.
> The whole point of DT is to make the kernel _less_ tied to the hardware
> and more generic. If we're going to introduce an entirely new set of
> drivers into the kernel to "probe" the hardware to determine which
> overlays are required, then that's really defeating the purpose of DT.
If you read my circular dependency sentence carefully, I said a kernel
driver is impractical for the task of getting the overlay. So I agree.
If the kernel applies the overlay, an alternative to drivers is that the
kernel could receive the overlay(s) in a similar manner as the method it
currently receives the base devicetree. (The overlay(s) could be
appended to the base devicetree, a wrapper could be placed around the
base devicetree and the overlay(s), or some other implementation. There
are multiple ways to achieve the same result.)
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Pavel Machek @ 2018-05-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529210909.7m4cyhh524xqipju@earth.universe>
On Tue 2018-05-29 23:09:09, Sebastian Reichel wrote:
> Hi Pavel,
>
> On Tue, May 29, 2018 at 10:45:17PM +0200, Pavel Machek wrote:
> > > > > still results in working touchscreen, removing any of the three fields
> > > > > breaks it again.
> > > >
> > > > I bisected one regression down, see "omapdrm regression in v4.17-rc series"
> > > > not sure if it covers all the issues being discussed here though.
> > >
> > > Reverting 24aac6011f70 fixes screen on n900 in v4.17-rc for me. (But
> > > strange dependency on tsc2005 at 0 is still there).
> >
> > Laurent, your patch looks pretty obvious, but unfortunately breaks
> > display on Nokia N900.
> >
> > The patch is pretty big as is, perhaps you have version split to sdi
> > => *sdi and then static => dynamic allocation?
>
> There is a queued fix:
>
> https://github.com/freedesktop/drm-misc/commit/2bc5ff0bdc00d81d719dad74589317a260d583ed
Thanks for the pointer! I hope it makes it in time for v4.17...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/1dd6ade5/attachment.sig>
^ permalink raw reply
* Regression in Linux next again
From: Tony Lindgren @ 2018-05-29 22:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Linux next has a regression at least on beaglebone-x15 where
booting Linux hangs shortly after starting init when loading
modules with no output. I bisected it down to commit
456e7cdf3b1a ("regulator: core: Change voltage setting path")
I think I bisected this same issue for the second time now
but for a different merge window. What's up with that?
And then we also have commit 696861761a58 ("regulator: core: Add
voltage balancing mechanism") that fails to compile breaking
git bisect:
drivers/regulator/core.c: In function 'regulator_balance_voltage':
drivers/regulator/core.c:3284:9: error: implicit declaration of
function 'regulator_set_voltage'.
Reverting both patches fixes the issue for me. I could
not debug it further because of the compile error(s).
Regards,
Tony
^ 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