* [RFC PATCH v2 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-11-02 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102165329.GB10528@bhelgaas-glaptop.roam.corp.google.com>
On Wed, Nov 2, 2016 at 9:53 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> Hi Duc,
>
> On Tue, Oct 25, 2016 at 06:24:32PM -0700, Duc Dang wrote:
> > PCIe controllers in X-Gene SoCs is not ECAM compliant: software
> > needs to configure additional controller's register to address
> > device at bus:dev:function.
> >
> > This patch depends on "ECAM quirks handling for ARM64 platforms"
> > series (http://www.spinics.net/lists/arm-kernel/msg530692.html,
> > the series was also modified by Bjorn) to address the limitation
> > above for X-Gene PCIe controller.
> >
> > The quirk will only be applied for X-Gene PCIe MCFG table with
> > OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>
> The quirks here contain some hard-coded address space consumed by
> ECAM. The ECAM quirk itself is not a generic description of that
> address space in the sense of a PCI BAR or an ACPI _CRS method, i.e.,
> the quirk description is not enough to keep other parts of the kernel
> from treating the address space as "available".
Your concern here is the controller register region that I declared as
hard-coded array of resource (xgene_vx_csr_res) is not owned by the
root bridge? So unlike DT case where kernel discovers and knows
exactly who owns this resource (and we can also use
platform_get_resource to get the resource); in ACPI case with ECAM
quirk, kernel knows who requests this resource but does not know who
owns it? Do I understand correctly?
>
> Can you add a note here in the changelog about how you are describing
> this space generically? The standard solution is a PNP0C02 device
> with _CRS that describes it.
>
> It would be ideal if you could open a bugzilla at bugzilla.kernel.org
> and attach there a dmesg log, /proc/iomem contents, and DSDT. This
> would show both the generic PNP0C02 piece and the ECAM quirk piece.
We don't have PNP0C02 device in our ACPI Table. Do you want me add a
PNP0C02 device into our firmware and check/document the difference in
/proc/iomem output?
>
> BTW, I did refresh and re-push the pci/ecam-v6 branch where I'm
> collecting this stuff, so if you want to rebase your patch on top of
> that and test it, that would be great.
Thanks, I will definitely do that.
>
> > Signed-off-by: Duc Dang <dhdang@apm.com>
> > ---
> > v2 changes:
> > 1. Get rid of pci-xgene-ecam.c file and fold quirk code into pci-xgene.c
> > 2. Redefine fixup array for X-Gene
> > 3. Use devm_ioremap_resource to map csr_base
> >
> > drivers/acpi/pci_mcfg.c | 30 ++++++++
> > drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++-
> > include/linux/pci-ecam.h | 5 ++
> > 3 files changed, 197 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> > index bb2c508..9dfc937 100644
> > --- a/drivers/acpi/pci_mcfg.c
> > +++ b/drivers/acpi/pci_mcfg.c
> > @@ -96,6 +96,36 @@ struct mcfg_fixup {
> > THUNDER_ECAM_MCFG(2, 12),
> > THUNDER_ECAM_MCFG(2, 13),
> > #endif
> > +#ifdef CONFIG_PCI_XGENE
> > +#define XGENE_V1_ECAM_MCFG(rev, seg) \
> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v1_pcie_ecam_ops }
> > +#define XGENE_V2_1_ECAM_MCFG(rev, seg) \
> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v2_1_pcie_ecam_ops }
> > +#define XGENE_V2_2_ECAM_MCFG(rev, seg) \
> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v2_2_pcie_ecam_ops }
> > +
> > + /* X-Gene SoC with v1 PCIe controller */
> > + XGENE_V1_ECAM_MCFG(1, 0),
> > + XGENE_V1_ECAM_MCFG(1, 1),
> > + XGENE_V1_ECAM_MCFG(1, 2),
> > + XGENE_V1_ECAM_MCFG(1, 3),
> > + XGENE_V1_ECAM_MCFG(1, 4),
> > + XGENE_V1_ECAM_MCFG(2, 0),
> > + XGENE_V1_ECAM_MCFG(2, 1),
> > + XGENE_V1_ECAM_MCFG(2, 2),
> > + XGENE_V1_ECAM_MCFG(2, 3),
> > + XGENE_V1_ECAM_MCFG(2, 4),
> > + /* X-Gene SoC with v2.1 PCIe controller */
> > + XGENE_V2_1_ECAM_MCFG(3, 0),
> > + XGENE_V2_1_ECAM_MCFG(3, 1),
> > + /* X-Gene SoC with v2.2 PCIe controller */
> > + XGENE_V2_2_ECAM_MCFG(4, 0),
> > + XGENE_V2_2_ECAM_MCFG(4, 1),
> > + XGENE_V2_2_ECAM_MCFG(4, 2),
> > +#endif
> > };
> >
> > static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> > diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
> > index 1de23d7..d6aa642 100644
> > --- a/drivers/pci/host/pci-xgene.c
> > +++ b/drivers/pci/host/pci-xgene.c
> > @@ -27,6 +27,8 @@
> > #include <linux/of_irq.h>
> > #include <linux/of_pci.h>
> > #include <linux/pci.h>
> > +#include <linux/pci-acpi.h>
> > +#include <linux/pci-ecam.h>
> > #include <linux/platform_device.h>
> > #include <linux/slab.h>
> >
> > @@ -64,6 +66,7 @@
> > /* PCIe IP version */
> > #define XGENE_PCIE_IP_VER_UNKN 0
> > #define XGENE_PCIE_IP_VER_1 1
> > +#define XGENE_PCIE_IP_VER_2 2
> >
> > struct xgene_pcie_port {
> > struct device_node *node;
> > @@ -97,7 +100,15 @@ static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
> > */
> > static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> > {
> > - struct xgene_pcie_port *port = bus->sysdata;
> > + struct pci_config_window *cfg;
> > + struct xgene_pcie_port *port;
> > +
> > + if (acpi_disabled)
> > + port = bus->sysdata;
> > + else {
> > + cfg = bus->sysdata;
> > + port = cfg->priv;
> > + }
> >
> > if (bus->number >= (bus->primary + 1))
> > return port->cfg_base + AXI_EP_CFG_ACCESS;
> > @@ -111,10 +122,18 @@ static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> > */
> > static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
> > {
> > - struct xgene_pcie_port *port = bus->sysdata;
> > + struct pci_config_window *cfg;
> > + struct xgene_pcie_port *port;
> > unsigned int b, d, f;
> > u32 rtdid_val = 0;
> >
> > + if (acpi_disabled)
> > + port = bus->sysdata;
> > + else {
> > + cfg = bus->sysdata;
> > + port = cfg->priv;
> > + }
> > +
> > b = bus->number;
> > d = PCI_SLOT(devfn);
> > f = PCI_FUNC(devfn);
> > @@ -158,7 +177,15 @@ static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
> > static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> > int where, int size, u32 *val)
> > {
> > - struct xgene_pcie_port *port = bus->sysdata;
> > + struct pci_config_window *cfg;
> > + struct xgene_pcie_port *port;
> > +
> > + if (acpi_disabled)
> > + port = bus->sysdata;
> > + else {
> > + cfg = bus->sysdata;
> > + port = cfg->priv;
> > + }
> >
> > if (pci_generic_config_read32(bus, devfn, where & ~0x3, 4, val) !=
> > PCIBIOS_SUCCESSFUL)
> > @@ -189,6 +216,138 @@ static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> > .write = pci_generic_config_write32,
> > };
> >
> > +#ifdef CONFIG_ACPI
> > +static struct resource xgene_v1_csr_res[] = {
> > + [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > + [1] = DEFINE_RES_MEM(0x1f2c0000UL, SZ_64K),
> > + [2] = DEFINE_RES_MEM(0x1f2d0000UL, SZ_64K),
> > + [3] = DEFINE_RES_MEM(0x1f500000UL, SZ_64K),
> > + [4] = DEFINE_RES_MEM(0x1f510000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > + struct acpi_device *adev = to_acpi_device(cfg->parent);
> > + struct acpi_pci_root *root = acpi_driver_data(adev);
> > + struct device *dev = cfg->parent;
> > + struct xgene_pcie_port *port;
> > + struct resource *csr;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + csr = &xgene_v1_csr_res[root->segment];
> > + port->csr_base = devm_ioremap_resource(dev, csr);
> > + if (IS_ERR(port->csr_base)) {
> > + kfree(port);
> > + return -ENOMEM;
> > + }
> > +
> > + port->cfg_base = cfg->win;
> > + port->version = XGENE_PCIE_IP_VER_1;
> > +
> > + cfg->priv = port;
> > +
> > + return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v1_pcie_ecam_ops = {
> > + .bus_shift = 16,
> > + .init = xgene_v1_pcie_ecam_init,
> > + .pci_ops = {
> > + .map_bus = xgene_pcie_map_bus,
> > + .read = xgene_pcie_config_read32,
> > + .write = pci_generic_config_write,
> > + }
> > +};
> > +
> > +static struct resource xgene_v2_1_csr_res[] = {
> > + [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > + [1] = DEFINE_RES_MEM(0x1f2c0000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v2_1_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > + struct acpi_device *adev = to_acpi_device(cfg->parent);
> > + struct acpi_pci_root *root = acpi_driver_data(adev);
> > + struct device *dev = cfg->parent;
> > + struct xgene_pcie_port *port;
> > + struct resource *csr;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + csr = &xgene_v2_1_csr_res[root->segment];
> > + port->csr_base = devm_ioremap_resource(dev, csr);
> > + if (IS_ERR(port->csr_base)) {
> > + kfree(port);
> > + return -ENOMEM;
> > + }
> > +
> > + port->cfg_base = cfg->win;
> > + port->version = XGENE_PCIE_IP_VER_2;
> > +
> > + cfg->priv = port;
> > +
> > + return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops = {
> > + .bus_shift = 16,
> > + .init = xgene_v2_1_pcie_ecam_init,
> > + .pci_ops = {
> > + .map_bus = xgene_pcie_map_bus,
> > + .read = xgene_pcie_config_read32,
> > + .write = pci_generic_config_write,
> > + }
> > +};
> > +
> > +static struct resource xgene_v2_2_csr_res[] = {
> > + [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > + [1] = DEFINE_RES_MEM(0x1f500000UL, SZ_64K),
> > + [2] = DEFINE_RES_MEM(0x1f2d0000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v2_2_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > + struct acpi_device *adev = to_acpi_device(cfg->parent);
> > + struct acpi_pci_root *root = acpi_driver_data(adev);
> > + struct device *dev = cfg->parent;
> > + struct xgene_pcie_port *port;
> > + struct resource *csr;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + csr = &xgene_v2_2_csr_res[root->segment];
> > + port->csr_base = devm_ioremap_resource(dev, csr);
> > + if (IS_ERR(port->csr_base)) {
> > + kfree(port);
> > + return -ENOMEM;
> > + }
> > +
> > + port->cfg_base = cfg->win;
> > + port->version = XGENE_PCIE_IP_VER_2;
> > +
> > + cfg->priv = port;
> > +
> > + return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops = {
> > + .bus_shift = 16,
> > + .init = xgene_v2_2_pcie_ecam_init,
> > + .pci_ops = {
> > + .map_bus = xgene_pcie_map_bus,
> > + .read = xgene_pcie_config_read32,
> > + .write = pci_generic_config_write,
> > + }
> > +};
> > +#endif
> > +
> > static u64 xgene_pcie_set_ib_mask(struct xgene_pcie_port *port, u32 addr,
> > u32 flags, u64 size)
> > {
> > diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> > index 35f0e81..40da3e7 100644
> > --- a/include/linux/pci-ecam.h
> > +++ b/include/linux/pci-ecam.h
> > @@ -65,6 +65,11 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
> > #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
> > extern struct pci_ecam_ops pci_thunder_ecam_ops;
> > #endif
> > +#ifdef CONFIG_PCI_XGENE
> > +extern struct pci_ecam_ops xgene_v1_pcie_ecam_ops;
> > +extern struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops;
> > +extern struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops;
> > +#endif
> >
> > #ifdef CONFIG_PCI_HOST_GENERIC
> > /* for DT-based PCI controllers that support ECAM */
> > --
> > 1.9.1
> >
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH 1/1] KVM: ARM64: Fix the issues when PMCCFILTR is configured
From: Wei Huang @ 2016-11-02 20:55 UTC (permalink / raw)
To: linux-arm-kernel
KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
But this function can't deals with PMCCFILTR correctly because the evtCount
bit of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, KVM
shouldn't return immediately, but instead it needs to check further if
select_idx is ARMV8_PMU_CYCLE_IDX.
Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
directly to attr.config. Istead it shoudl convert the request to
perf_event of type 0x11 (i.e. the "cpu cycle" event type).
Signed-off-by: Wei Huang <wei@redhat.com>
---
virt/kvm/arm/pmu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6e9c40e..13cc812 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -379,7 +379,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
/* Software increment event does't need to be backed by a perf event */
- if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+ if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR &&
+ select_idx != ARMV8_PMU_CYCLE_IDX)
return;
memset(&attr, 0, sizeof(struct perf_event_attr));
@@ -391,7 +392,7 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
attr.exclude_hv = 1; /* Don't count EL2 events */
attr.exclude_host = 1; /* Don't count host events */
- attr.config = eventsel;
+ attr.config = (select_idx == ARMV8_PMU_CYCLE_IDX) ? 0x011 : eventsel;
counter = kvm_pmu_get_counter_value(vcpu, select_idx);
/* The initial sample period (overflow count) of an event. */
--
2.7.4
^ permalink raw reply related
* Use of GICv3/ITS with PCIe host-generic driver - resizing ITS MAPD?
From: Marc Zyngier @ 2016-11-02 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CY1PR07MB2506C9B4133B1CE185AD0260D8A00@CY1PR07MB2506.namprd07.prod.outlook.com>
On Wed, Nov 02 2016 at 09:36:14 AM, Alan Douglas <adouglas@cadence.com> wrote:
> Hi Marc,
>
>> > When setting up bus 0, the ITS device is created, and
>> > its_build_map_cmd() sets the size of the ITS MAPD based on the number
>> > of interrupts claimed by bus 0. When subsequent buses are enumerated,
>> > the ITS device will be reused, however we do not increase the number
>> > of supported interrupts to allow for the additional interrupts claimed
>> > by the additional devices being enumerated. (This can be seen in
>> > its_msi_prepare(), which is called for each device which has MSI/MSI-X
>> > enabled, and will reuse an existing ITS. )
>>
>> Am I right in understanding that all the PCIe devices in your system end-up
>> aliasing to the same RequesterID? If so, that's a major issue. The ITS is
>> designed so that each device exposes its *own* RID, and have its own
>> Interrupt Translation Table (ITT).
>>
>> In your case, you seem to first discover the root port, which is not upstream
>> of anything, so it doesn't alias with anything at that point. We allocate the
>> corresponding ITT, and it's all fine. Until we start probing the rest, and ugly
>> things happen.
>>
> Yes, your understanding is correct. I will dig into this a bit
> further to see what is wrong then send an update. I suspect my DTS
> msi mapping.
Right. That would explain a lot of what you're seeing. In general, and
unless you have some funky remapping going on, you're better off having
a very straightforward msi-map property in your RC node (such as example
#1 in Documentation/devicetree/bindings/pci/pci-msi.txt).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [PATCHv2 0/6] CONFIG_DEBUG_VIRTUAL for arm64
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v2 of the series to add CONFIG_DEBUG_VIRTUAL support from arm64. This
has been split out into a number of patches:
Patch #1 Adds ARCH_HAS_DEBUG_VIRTUAL to avoid the need for adding arch
dependencies for DEBUG_VIRTUAL. This touches arch/x86/Kconfig
Patch #2 Cleans up cma to not rely on __pa_nodebug and have an #ifdef inline
in the function.
Patch #3 Adjust some macros in arm64 memory.h to be under __ASSEMBLY__
protection
Patch #4 Adds a cast for virt_to_pfn since __virt_to_phys for DEBUG_VIRTUAL no
longer has a cast.
Patch #5 Switches to using __pa_symbol for _end to avoid erroneously triggering
a bounds error with the debugging.
Patch #6 is the actual implementation of DEBUG_VIRTUAL. The biggest change from
the RFCv1 is the addition of __phys_addr_symbol. This is to handle several
places where the physical address of _end is needed. x86 avoids this problem by
doing its bounds check based on the entire possible image space which is well
beyond where _end would end up.
There are a few dependencies outside of arm64, so I don't know if
it will be easier for this to eventually go through arm64 or the mm tree.
Thanks,
Laura
Laura Abbott (6):
lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
mm/cma: Cleanup highmem check
arm64: Move some macros under #ifndef __ASSEMBLY__
arm64: Add cast for virt_to_pfn
arm64: Use __pa_symbol for _end
arm64: Add support for CONFIG_DEBUG_VIRTUAL
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/memory.h | 50 ++++++++++++++++++++++++-----------------
arch/arm64/mm/Makefile | 2 ++
arch/arm64/mm/init.c | 4 ++--
arch/arm64/mm/physaddr.c | 34 ++++++++++++++++++++++++++++
arch/x86/Kconfig | 1 +
lib/Kconfig.debug | 5 ++++-
mm/cma.c | 15 +++++--------
8 files changed, 79 insertions(+), 33 deletions(-)
create mode 100644 arch/arm64/mm/physaddr.c
--
2.10.1
^ permalink raw reply
* [PATCHv2 1/6] lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
DEBUG_VIRTUAL currently depends on DEBUG_KERNEL && X86. arm64 is getting
the same support. Rather than add a list of architectures, switch this
to ARCH_HAS_DEBUG_VIRTUAL and let architectures select it as
appropriate.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/x86/Kconfig | 1 +
lib/Kconfig.debug | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636..f533321 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,6 +23,7 @@ config X86
select ARCH_CLOCKSOURCE_DATA
select ARCH_DISCARD_MEMBLOCK
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+ select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b01e547..5050530 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -603,9 +603,12 @@ config DEBUG_VM_PGFLAGS
If unsure, say N.
+config ARCH_HAS_DEBUG_VIRTUAL
+ bool
+
config DEBUG_VIRTUAL
bool "Debug VM translations"
- depends on DEBUG_KERNEL && X86
+ depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
help
Enable some costly sanity checks in virtual to page code. This can
catch mistakes with virt_to_page() and friends.
--
2.10.1
^ permalink raw reply related
* [PATCHv2 2/6] mm/cma: Cleanup highmem check
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
6b101e2a3ce4 ("mm/CMA: fix boot regression due to physical address of
high_memory") added checks to use __pa_nodebug on x86 since
CONFIG_DEBUG_VIRTUAL complains about high_memory not being linearlly
mapped. arm64 is now getting support for CONFIG_DEBUG_VIRTUAL as well.
Rather than add an explosion of arches to the #ifdef, switch to an
alternate method to calculate the physical start of highmem using
the page before highmem starts. This avoids the need for the #ifdef and
extra __pa_nodebug calls.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
mm/cma.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/mm/cma.c b/mm/cma.c
index 384c2cb..71a2ec1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -235,18 +235,13 @@ int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t highmem_start;
int ret = 0;
-#ifdef CONFIG_X86
/*
- * high_memory isn't direct mapped memory so retrieving its physical
- * address isn't appropriate. But it would be useful to check the
- * physical address of the highmem boundary so it's justifiable to get
- * the physical address from it. On x86 there is a validation check for
- * this case, so the following workaround is needed to avoid it.
+ * We can't use __pa(high_memory) directly, since high_memory
+ * isn't a valid direct map VA, and DEBUG_VIRTUAL will (validly)
+ * complain. Find the boundary by adding one to the last valid
+ * address.
*/
- highmem_start = __pa_nodebug(high_memory);
-#else
- highmem_start = __pa(high_memory);
-#endif
+ highmem_start = __pa(high_memory - 1) + 1;
pr_debug("%s(size %pa, base %pa, limit %pa alignment %pa)\n",
__func__, &size, &base, &limit, &alignment);
--
2.10.1
^ permalink raw reply related
* [PATCHv2 3/6] arm64: Move some macros under #ifndef __ASSEMBLY__
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
Several macros for various x_to_y exist outside the bounds of an
__ASSEMBLY__ guard. Move them in preparation for support for
CONFIG_DEBUG_VIRTUAL.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/arm64/include/asm/memory.h | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b71086d..b4d2b32 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -102,25 +102,6 @@
#endif
/*
- * Physical vs virtual RAM address space conversion. These are
- * private definitions which should NOT be used outside memory.h
- * files. Use virt_to_phys/phys_to_virt/__pa/__va instead.
- */
-#define __virt_to_phys(x) ({ \
- phys_addr_t __x = (phys_addr_t)(x); \
- __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
- (__x - kimage_voffset); })
-
-#define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
-#define __phys_to_kimg(x) ((unsigned long)((x) + kimage_voffset))
-
-/*
- * Convert a page to/from a physical address
- */
-#define page_to_phys(page) (__pfn_to_phys(page_to_pfn(page)))
-#define phys_to_page(phys) (pfn_to_page(__phys_to_pfn(phys)))
-
-/*
* Memory types available.
*/
#define MT_DEVICE_nGnRnE 0
@@ -182,6 +163,25 @@ extern u64 kimage_voffset;
#define PHYS_PFN_OFFSET (PHYS_OFFSET >> PAGE_SHIFT)
/*
+ * Physical vs virtual RAM address space conversion. These are
+ * private definitions which should NOT be used outside memory.h
+ * files. Use virt_to_phys/phys_to_virt/__pa/__va instead.
+ */
+#define __virt_to_phys(x) ({ \
+ phys_addr_t __x = (phys_addr_t)(x); \
+ __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
+ (__x - kimage_voffset); })
+
+#define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
+#define __phys_to_kimg(x) ((unsigned long)((x) + kimage_voffset))
+
+/*
+ * Convert a page to/from a physical address
+ */
+#define page_to_phys(page) (__pfn_to_phys(page_to_pfn(page)))
+#define phys_to_page(phys) (pfn_to_page(__phys_to_pfn(phys)))
+
+/*
* Note: Drivers should NOT use these. They are the wrong
* translation for translating DMA addresses. Use the driver
* DMA support - see dma-mapping.h.
--
2.10.1
^ permalink raw reply related
* [PATCHv2 4/6] arm64: Add cast for virt_to_pfn
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
virt_to_pfn lacks a cast at the top level. Don't rely on __virt_to_phys
and explicitly cast to unsigned long.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/arm64/include/asm/memory.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b4d2b32..d773e2c 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -204,7 +204,7 @@ static inline void *phys_to_virt(phys_addr_t x)
#define __pa(x) __virt_to_phys((unsigned long)(x))
#define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
-#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys(x))
+#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
/*
* virt_to_page(k) convert a _valid_ virtual address to struct page *
--
2.10.1
^ permalink raw reply related
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
__pa_symbol is technically the marco that should be used for kernel
symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/arm64/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 212c4d1..3236eb0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -209,8 +209,8 @@ void __init arm64_memblock_init(void)
* linear mapping. Take care not to clip the kernel which may be
* high in memory.
*/
- memblock_remove(max_t(u64, memstart_addr + linear_region_size, __pa(_end)),
- ULLONG_MAX);
+ memblock_remove(max_t(u64, memstart_addr + linear_region_size,
+ __pa_symbol(_end)), ULLONG_MAX);
if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {
/* ensure that memstart_addr remains sufficiently aligned */
memstart_addr = round_up(memblock_end_of_DRAM() - linear_region_size,
--
2.10.1
^ permalink raw reply related
* [PATCHv2 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>
x86 has an option CONFIG_DEBUG_VIRTUAL to do additional checks
on virt_to_phys calls. The goal is to catch users who are calling
virt_to_phys on non-linear addresses immediately. As features
such as CONFIG_VMAP_STACK get enabled for arm64, this becomes
increasingly important. Add checks to catch bad virt_to_phys
usage.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/memory.h | 12 +++++++++++-
arch/arm64/mm/Makefile | 2 ++
arch/arm64/mm/physaddr.c | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/mm/physaddr.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..83b95bc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,6 +6,7 @@ config ARM64
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
select ARCH_CLOCKSOURCE_DATA
+ select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index d773e2c..eac3dbb 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -167,11 +167,19 @@ extern u64 kimage_voffset;
* private definitions which should NOT be used outside memory.h
* files. Use virt_to_phys/phys_to_virt/__pa/__va instead.
*/
-#define __virt_to_phys(x) ({ \
+#define __virt_to_phys_nodebug(x) ({ \
phys_addr_t __x = (phys_addr_t)(x); \
__x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
(__x - kimage_voffset); })
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern unsigned long __virt_to_phys(unsigned long x);
+extern unsigned long __phys_addr_symbol(unsigned long x);
+#else
+#define __virt_to_phys(x) __virt_to_phys_nodebug(x)
+#define __phys_addr_symbol __pa
+#endif
+
#define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
#define __phys_to_kimg(x) ((unsigned long)((x) + kimage_voffset))
@@ -202,6 +210,8 @@ static inline void *phys_to_virt(phys_addr_t x)
* Drivers should NOT use these either.
*/
#define __pa(x) __virt_to_phys((unsigned long)(x))
+#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
+#define __pa_nodebug(x) __virt_to_phys_nodebug((unsigned long)(x))
#define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 54bb209..377f4ab 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -5,6 +5,8 @@ obj-y := dma-mapping.o extable.o fault.o init.o \
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_ARM64_PTDUMP) += dump.o
obj-$(CONFIG_NUMA) += numa.o
+CFLAGS_physaddr.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
+obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
obj-$(CONFIG_KASAN) += kasan_init.o
KASAN_SANITIZE_kasan_init.o := n
diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
new file mode 100644
index 0000000..874c782
--- /dev/null
+++ b/arch/arm64/mm/physaddr.c
@@ -0,0 +1,34 @@
+#include <linux/mm.h>
+
+#include <asm/memory.h>
+
+unsigned long __virt_to_phys(unsigned long x)
+{
+ phys_addr_t __x = (phys_addr_t)x;
+
+ if (__x & BIT(VA_BITS - 1)) {
+ /*
+ * The linear kernel range starts in the middle of the virtual
+ * adddress space. Testing the top bit for the start of the
+ * region is a sufficient check.
+ */
+ return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
+ } else {
+ VIRTUAL_BUG_ON(x < kimage_vaddr || x >= (unsigned long)_end);
+ return (__x - kimage_voffset);
+ }
+}
+EXPORT_SYMBOL(__virt_to_phys);
+
+unsigned long __phys_addr_symbol(unsigned long x)
+{
+ phys_addr_t __x = (phys_addr_t)x;
+
+ /*
+ * This is intentionally different than above to be a tighter check
+ * for symbols.
+ */
+ VIRTUAL_BUG_ON(x < kimage_vaddr + TEXT_OFFSET || x > (unsigned long) _end);
+ return (__x - kimage_voffset);
+}
+EXPORT_SYMBOL(__phys_addr_symbol);
--
2.10.1
^ permalink raw reply related
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Will Deacon @ 2016-11-02 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031194414.61287-1-code@mmayer.net>
On Mon, Oct 31, 2016 at 12:44:14PM -0700, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> The new errata check leads to a warning with some older versions of the
> linker that do know how to work around the errata, but still use the
> original name of the command line option: --fix-cortex-a53. The commit
> in question that changed the name of the option can be found at [1].
> It looks like only "gold" is affected by this rename. Traditional "ld"
> isn't. (There, the argument was always called --fix-cortex-a53-843419.)
>
> To allow older versions of gold to properly handle the erratum if they
> can, check whether ld supports the old name of this option in addition
> to checking the new one.
>
> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=7a2a1c793578a8468604e661dda025ecb8d0bd20;hp=cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
If newer versions of gold accept the correct option name, why do we care?
Will
^ permalink raw reply
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Markus Mayer @ 2016-11-02 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102210331.GJ22791@arm.com>
On 2 November 2016 at 14:03, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Oct 31, 2016 at 12:44:14PM -0700, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> The new errata check leads to a warning with some older versions of the
>> linker that do know how to work around the errata, but still use the
>> original name of the command line option: --fix-cortex-a53. The commit
>> in question that changed the name of the option can be found at [1].
>> It looks like only "gold" is affected by this rename. Traditional "ld"
>> isn't. (There, the argument was always called --fix-cortex-a53-843419.)
>>
>> To allow older versions of gold to properly handle the erratum if they
>> can, check whether ld supports the old name of this option in addition
>> to checking the new one.
>>
>> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=7a2a1c793578a8468604e661dda025ecb8d0bd20;hp=cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f
>>
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>
> If newer versions of gold accept the correct option name, why do we care?
Because Documentation/Changes states that the minimum requirement for
binutils is 2.12. Right now, that is not really true. And not
everybody can always use the newest toolchain, for various reasons.
The question I am asking is: What do we have to lose by supporting both options?
Thanks,
-Markus
^ permalink raw reply
* [PATCH v3 11/14] ACPI: irq: introduce interrupt producer
From: Hanjun Guo @ 2016-11-02 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c403c4099fd5dcfcebb6b7ff5a51b915@codeaurora.org>
Hi Agustin,
Sorry for the late reply, on travailing for now.
On 10/29/2016 03:32 AM, agustinv at codeaurora.org wrote:
> Hey Hanjun,
>
> On 2016-10-25 11:09, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,
>>
>> Interrupt (ResourceUsage, EdgeLevel, ActiveLevel, Shared,
>> ResourceSourceIndex, ResourceSource, DescriptorName)
>> { InterruptList } => Buffer
>>
>> For the arguement ResourceUsage and DescriptorName, which means:
>>
>> ResourceUsage describes whether the device consumes the specified
>> interrupt ( ResourceConsumer ) or produces it for use by a child
>> device ( ResourceProducer ).
>> If nothing is specified, then ResourceConsumer is assumed.
>>
>> DescriptorName evaluates to a name string which refers to the
>> entire resource descriptor.
>>
>> So it can be used for devices connecting to a specific interrupt
>> prodcucer instead of the main interrupt controller in MADT. In the
>> real world, we have irqchip such as mbi-gen which connecting to
>> a group of wired interrupts and then issue msi to the ITS, devices
>> connecting to such interrupt controller fit this scope.
>>
>> For now the irq for ACPI only pointer to the main interrupt
>> controller's irqdomain, for devices not connecting to those
>> irqdomains, which need to present its irq parent, we can use
>> following ASL code to represent it:
>>
>> Interrupt(ResourceConsumer,..., "\_SB.IRQP") {12,14,....}
>>
>> then we can parse the interrupt producer with the full
>> path name "\_SB.IRQP".
>>
>> In order to do that, we introduce a pointer interrupt_producer
>> in struct acpi_device, and fill it when scanning irq resources
>> for acpi device if it specifies the interrupt producer.
>>
>> But for now when parsing the resources for acpi devices, we don't
>> pass the acpi device for acpi_walk_resoures() in drivers/acpi/resource.c,
>> so introduce a adev in struct res_proc_context to pass it as a context
>> to scan the interrupt resources, then finally pass to acpi_register_gsi()
>> to find its interrupt producer to get the virq from diffrent domains.
>>
>> With steps above ready, rework acpi_register_gsi() to get other
>> interrupt producer if devices not connecting to main interrupt
>> controller.
>>
>> Since we often pass NULL to acpi_register_gsi() and there is no interrupt
>> producer for devices connect to gicd on ARM or io-apic on X86, so it will
>> use the default irqdomain for those deivces and no functional changes to
>> those devices.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Agustin Vega-Frias <agustinv@codeaurora.org>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> ---
>> drivers/acpi/gsi.c | 10 ++++--
>> drivers/acpi/resource.c | 85
>> ++++++++++++++++++++++++++++++++++---------------
>> include/acpi/acpi_bus.h | 1 +
>> 3 files changed, 68 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
>> index ee9e0f2..29ee547 100644
>> --- a/drivers/acpi/gsi.c
>> +++ b/drivers/acpi/gsi.c
>> @@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi,
>> int trigger,
>> int polarity)
>> {
>> struct irq_fwspec fwspec;
>> + struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;
>>
>> - if (WARN_ON(!acpi_gsi_domain_id)) {
>> + if (adev && &adev->fwnode && adev->interrupt_producer)
>> + /* devices in DSDT connecting to spefic interrupt producer */
>> + fwspec.fwnode = adev->interrupt_producer;
>> + else if (acpi_gsi_domain_id)
>> + /* devices connecting to gicd in default */
>> + fwspec.fwnode = acpi_gsi_domain_id;
>> + else {
>> pr_warn("GSI: No registered irqchip, giving up\n");
>> return -EINVAL;
>> }
>>
>> - fwspec.fwnode = acpi_gsi_domain_id;
>> fwspec.param[0] = gsi;
>> fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
>> fwspec.param_count = 2;
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 56241eb..f1371cf 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -381,7 +381,7 @@ static void acpi_dev_irqresource_disabled(struct
>> resource *res, u32 gsi)
>> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED |
>> IORESOURCE_UNSET;
>> }
>>
>> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
>> +static void acpi_dev_get_irqresource(struct acpi_device *adev, struct
>> resource *res, u32 gsi,
>> u8 triggering, u8 polarity, u8 shareable,
>> bool legacy)
>> {
>> @@ -415,7 +415,7 @@ static void acpi_dev_get_irqresource(struct
>> resource *res, u32 gsi,
>> }
>>
>> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
>> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
>> + irq = acpi_register_gsi(&adev->dev, gsi, triggering, polarity);
>> if (irq >= 0) {
>> res->start = irq;
>> res->end = irq;
>> @@ -424,27 +424,9 @@ static void acpi_dev_get_irqresource(struct
>> resource *res, u32 gsi,
>> }
>> }
>>
>> -/**
>> - * acpi_dev_resource_interrupt - Extract ACPI interrupt resource
>> information.
>> - * @ares: Input ACPI resource object.
>> - * @index: Index into the array of GSIs represented by the resource.
>> - * @res: Output generic resource object.
>> - *
>> - * Check if the given ACPI resource object represents an interrupt
>> resource
>> - * and @index does not exceed the resource's interrupt count (true is
>> returned
>> - * in that case regardless of the results of the other checks)). If
>> that's the
>> - * case, register the GSI corresponding to @index from the array of
>> interrupts
>> - * represented by the resource and populate the generic resource
>> object pointed
>> - * to by @res accordingly. If the registration of the GSI is not
>> successful,
>> - * IORESOURCE_DISABLED will be set it that object's flags.
>> - *
>> - * Return:
>> - * 1) false with res->flags setting to zero: not the expected
>> resource type
>> - * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned
>> resource
>> - * 3) true: valid assigned resource
>> - */
>> -bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>> - struct resource *res)
>> +static bool __acpi_dev_resource_interrupt(struct acpi_device *adev,
>> + struct acpi_resource *ares, int index,
>> + struct resource *res)
>> {
>> struct acpi_resource_irq *irq;
>> struct acpi_resource_extended_irq *ext_irq;
>> @@ -460,7 +442,7 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> acpi_dev_irqresource_disabled(res, 0);
>> return false;
>> }
>> - acpi_dev_get_irqresource(res, irq->interrupts[index],
>> + acpi_dev_get_irqresource(adev, res, irq->interrupts[index],
>> irq->triggering, irq->polarity,
>> irq->sharable, true);
>> break;
>> @@ -470,7 +452,31 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> acpi_dev_irqresource_disabled(res, 0);
>> return false;
>> }
>> - acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>> +
>> + /*
>> + * It's a interrupt consumer device and connecting to specfic
>> + * interrupt controller. For now, we only support connecting
>> + * interrupts to one irq controller for a single device
>> + */
>> + if (ext_irq->producer_consumer == ACPI_CONSUMER
>> + && ext_irq->resource_source.string_length != 0
>> + && !adev->interrupt_producer) {
>> + acpi_status status;
>> + acpi_handle handle;
>> + struct acpi_device *device;
>> +
>> + status = acpi_get_handle(NULL,
>> ext_irq->resource_source.string_ptr, &handle);
>> + if (ACPI_FAILURE(status))
>> + return false;
>> +
>> + device = acpi_bus_get_acpi_device(handle);
>> + if (!device)
>> + return false;
>> +
>> + adev->interrupt_producer = &device->fwnode;
>
> You are missing an 'acpi_bus_put_acpi_device(device)' call here.
good catch!
>
> Besides that, this approach will not work in the case where a device
> wants to consume interrupts from multiple controllers since you are
> forcing adev->interrupt_producer to be the first resource_source
> found.
Yes, you are right, and it's in the comment of the code, we
can fix that to add some extra code.
>
> That's the reason I was advocating dynamic lookup (see [1]).
>
> I am about to submit V6 of my series where I also address the probe
> ordering issues by enabling re-initialization of platform_device
> resources when the resource was marked disabled due to the domain
> nor being there during ACPI bus scan.
I will take a deep look for your v6 patch set, probably we can
work together to get things down.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] ARM: socfpga: updates for socfpga_defconfig
From: Dinh Nguyen @ 2016-11-02 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478044484-2331-1-git-send-email-atull@opensource.altera.com>
On 11/01/2016 06:54 PM, Alan Tull wrote:
> This patch enables the following in the
> socfpga_defconfig:
>
> +CONFIG_OF_OVERLAY=y
> Enable support for Device Tree Overlays
>
> +CONFIG_FPGA_REGION=y
> Enable device tree overlay support for FPGA
> programming
>
> +CONFIG_FPGA_MGR_SOCFPGA_A10=y
> Enable partial reconfiguration for Altera
> Arria 10 FPGA
>
> +CONFIG_FPGA_BRIDGE=y
> Enable the FPGA Bridges framework
>
> +CONFIG_SOCFPGA_FPGA_BRIDGE=y
> Enable support for SoCFPGA hardware
> bridges
>
> +CONFIG_ALTERA_FREEZE_BRIDGE=y
> Enable support for the Altera Soft IP
> Freeze bridges
>
> Signed-off-by: Alan Tull <atull@opensource.altera.com>
> ---
> arch/arm/configs/socfpga_defconfig | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
> index f5b9bc5..18d3ec1 100644
> --- a/arch/arm/configs/socfpga_defconfig
> +++ b/arch/arm/configs/socfpga_defconfig
> @@ -54,6 +54,7 @@ CONFIG_DEVTMPFS_MOUNT=y
Applied!
Thanks,
Dinh
^ permalink raw reply
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Will Deacon @ 2016-11-02 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGt4E5tKHNQw=eLzFx-+g6yLwJ=xCTQEqNZHFZu6aOVpKm7X7w@mail.gmail.com>
On Wed, Nov 02, 2016 at 02:07:17PM -0700, Markus Mayer wrote:
> On 2 November 2016 at 14:03, Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Oct 31, 2016 at 12:44:14PM -0700, Markus Mayer wrote:
> >> From: Markus Mayer <mmayer@broadcom.com>
> >>
> >> The new errata check leads to a warning with some older versions of the
> >> linker that do know how to work around the errata, but still use the
> >> original name of the command line option: --fix-cortex-a53. The commit
> >> in question that changed the name of the option can be found at [1].
> >> It looks like only "gold" is affected by this rename. Traditional "ld"
> >> isn't. (There, the argument was always called --fix-cortex-a53-843419.)
> >>
> >> To allow older versions of gold to properly handle the erratum if they
> >> can, check whether ld supports the old name of this option in addition
> >> to checking the new one.
> >>
> >> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=7a2a1c793578a8468604e661dda025ecb8d0bd20;hp=cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f
> >>
> >> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> >
> > If newer versions of gold accept the correct option name, why do we care?
>
> Because Documentation/Changes states that the minimum requirement for
> binutils is 2.12. Right now, that is not really true. And not
> everybody can always use the newest toolchain, for various reasons.
Well the kernel still builds, right? Can binutils 2.12 even work around
843419? For people who can't use a recent toolchain, then they don't get
erratum workaround and we warn them about it.
> The question I am asking is: What do we have to lose by supporting both options?
We end up passing "--fix-cortex-a53" to the linker, without knowing what it
might do in the future.
Will
^ permalink raw reply
* [PATCH 1/3] ARM: davinci: da8xx: Fix ohci driver name
From: David Lechner @ 2016-11-02 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102124435.31777-2-ahaslam@baylibre.com>
On 11/02/2016 07:44 AM, Axel Haslam wrote:
> There is a single instance of the ohci driver,
> while the clk lookup table is making reference to "ohci"
> other subsystems (such as phy) are looking for "ohci.0"
>
This patch changes the "device" name, not the "driver" name. You use
"driver" above and in the subject.
> Since there is a single ohci instance, change the dev id
> to -1, and add the "-da8xx" for consitancy with the musb
> driver name.
It would be more accurate to say that you are adding "-da8xx" because
you are also changing the ohci _driver_ name in a separate patch.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
^ permalink raw reply
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Markus Mayer @ 2016-11-02 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102212747.GL22791@arm.com>
On 2 November 2016 at 14:27, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Nov 02, 2016 at 02:07:17PM -0700, Markus Mayer wrote:
>> On 2 November 2016 at 14:03, Will Deacon <will.deacon@arm.com> wrote:
>> > On Mon, Oct 31, 2016 at 12:44:14PM -0700, Markus Mayer wrote:
>> >> From: Markus Mayer <mmayer@broadcom.com>
>> >>
>> >> The new errata check leads to a warning with some older versions of the
>> >> linker that do know how to work around the errata, but still use the
>> >> original name of the command line option: --fix-cortex-a53. The commit
>> >> in question that changed the name of the option can be found at [1].
>> >> It looks like only "gold" is affected by this rename. Traditional "ld"
>> >> isn't. (There, the argument was always called --fix-cortex-a53-843419.)
>> >>
>> >> To allow older versions of gold to properly handle the erratum if they
>> >> can, check whether ld supports the old name of this option in addition
>> >> to checking the new one.
>> >>
>> >> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=7a2a1c793578a8468604e661dda025ecb8d0bd20;hp=cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f
>> >>
>> >> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> >
>> > If newer versions of gold accept the correct option name, why do we care?
>>
>> Because Documentation/Changes states that the minimum requirement for
>> binutils is 2.12. Right now, that is not really true. And not
>> everybody can always use the newest toolchain, for various reasons.
>
> Well the kernel still builds, right? Can binutils 2.12 even work around
> 843419? For people who can't use a recent toolchain, then they don't get
> erratum workaround and we warn them about it.
Correct. Linkers as old as 2.12 are not able to work around the
erratum, and the warning is accurate. So, there's no problem there.
But there are newer versions that do know how to work around the
erratum, but use the original name of the option. Right now, you could
be using a linker that knows how to fix the erratum, but instead, the
you get a warning, and the erratum is not fixed.
This one, for instance:
$ arm-linux-ld -v
GNU ld (GNU Binutils) Linaro 2014.11-2 2.24.0.20141017
Without the proposed patch, this linker will produce a kernel without
the workaround, but not because the linker can't do it, but because it
isn't given the command line argument it understands.
>> The question I am asking is: What do we have to lose by supporting both options?
>
> We end up passing "--fix-cortex-a53" to the linker, without knowing what it
> might do in the future.
It seems highly unlikely that such a generic option would be added in
the future, both, because the precedent has been set for topic
specific options, and because they know it has been used in the past,
so they wouldn't add a previously used option to do something
completely different. (And if they really did, then that would be a
huge binutils bug.)
So, we have a trade-off between a real world problem that does
currently exist and avoiding a theoretical issue that may never
materialize.
Regards,
-Markus
> Will
^ permalink raw reply
* [PATCH 1/3] ARM: pxa: mioa701: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-11-02 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474662654-23263-1-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> pxa_camera has transitioned from a soc_camera driver to a standalone
> v4l2 driver. Amend the device declaration accordingly.
Queued to pxa/for-next.
--
Robert
^ permalink raw reply
* [PATCH 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx
From: David Lechner @ 2016-11-02 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102124435.31777-3-ahaslam@baylibre.com>
On 11/02/2016 07:44 AM, Axel Haslam wrote:
> There is only one ohci on the da8xx series of chips,
> so remove the ".0" when creating the phy. Also add
> the "-da8xx" postfix to be consistent across davinci
> usb drivers.
It would be more accurate to say that the device name is being changed
in the mach board configuration files, so it is being changed here in
the lookup table to match the new name.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
^ permalink raw reply
* [PATCH 2/3] ARM: pxa: ezx: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-11-02 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474662654-23263-2-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> pxa_camera has transitioned from a soc_camera driver to a standalone
> v4l2 driver. Amend the device declaration accordingly.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Queued to pxa/for-next.
--
Robert
^ permalink raw reply
* [PATCH 3/3] ARM: pxa: em-x270: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-11-02 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474662654-23263-3-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> pxa_camera has transitioned from a soc_camera driver to a standalone
> v4l2 driver. Amend the device declaration accordingly.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Queued to pxa/for-next.
--
Robert
^ permalink raw reply
* [PATCH 3/3] usb: ohci-da8xx: rename driver to ohci-da8xx
From: David Lechner @ 2016-11-02 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102124435.31777-4-ahaslam@baylibre.com>
On 11/02/2016 07:44 AM, Axel Haslam wrote:
> To be consistent on the usb driver for the davinci
> platform follow the example of musb, and add the
> "-da8xx" postfix to the driver name.
>
It is probably worth mentioning that the existing driver name is "ohci"
which is a bit too generic.
^ permalink raw reply
* [PATCH v2] ARM: pxa: remove duplicated include from spitz.c
From: Robert Jarzmik @ 2016-11-02 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477742190-3300-1-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> From: Wei Yongjun <weiyj.lk@gmail.com>
>
> This partially reverts commit 12beb346710b ("Merge tag 'pxa-fixes-v4.8'
> of https://github.com/rjarzmik/linux into randconfig-4.8").
>
> This former patch introduced accidentally a double include of module.h.
>
> Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
> Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> [amended commit message and 2 comments]
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Queued to pxa/for-next.
--
Robert
^ permalink raw reply
* [PATCH v3 0/4] PXA cpufreq conversion to clock API
From: Robert Jarzmik @ 2016-11-02 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102044503.GC10786@vireshk-i7>
Viresh Kumar <viresh.kumar@linaro.org> writes:
> On 31-10-16, 20:54, Robert Jarzmik wrote:
>> Hi,
>>
>> This serie is a preparation to shift the cpufreq of pxa2xx platforms to clocks
>> API, next iteration.
>>
>> The first 3 patches are review and merge material :
>> - patch 1/4 for Viresh and Rafael
>> - patches 2/4 and 3/4 for me
>>
>> The 4th on is for review but not merge, as the clock changes must be fully
>> reviewed and go in first as a prequisite
>>
>> Since previous iteration, 2 and 3 were amended per Viresh's suggestion.
>>
>> Robert Jarzmik (4):
>> cpufreq: pxa: use generic platdev driver for device-tree
>> ARM: dts: pxa: add pxa25x cpu operating points
>> ARM: dts: pxa: add pxa27x cpu operating points
>> cpufreq: pxa: convert to clock API
>>
>> arch/arm/boot/dts/pxa25x.dtsi | 25 +++++
>> arch/arm/boot/dts/pxa27x.dtsi | 40 ++++++++
>> drivers/cpufreq/cpufreq-dt-platdev.c | 2 +
>> drivers/cpufreq/pxa2xx-cpufreq.c | 191 +++++++----------------------------
>> 4 files changed, 106 insertions(+), 152 deletions(-)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Ok, thanks Viresh.
Would you or Rafael take patch 1/4 "cpufreq: pxa: use generic platdev driver for
device-tree" through your tree please ?
I'll take patches 2 and 3 through my tree, and we'll wait for clock patches to
hit clock tree before I ask patch 4/4 to be applied.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v6 0/4] arm64: Allwinner A64 support based on sunxi-ng
From: Maxime Ripard @ 2016-11-02 21:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
As it was in the first iteration, this is the A64 support based on the
new sunxi-ng clock framework.
The support for it is quite minimal at the moment, but it should be
fairly easy to add new devices, as most of the design is shared with
older SoCs.
Let me know what you think,
Maxime
Changes from v5:
- Removed the redundant ioremap error code
- Converted to the generic pin muxing functions
- Removed the stale DT vendor removal
Changes from v4:
- Removed merged patches and added Chen-Yu's Acked by
- Fixed the interrupt-cells property to 3
- Fixed the rtc order
- Added the CLK_SET_RATE_UNGATE flags to the PLLs
- Added the CLK_SET_RATE_PARENT flags to the cpu clock
- Fixed a few offset and width
Changes from v3:
- Fix patch split
Changes from v2:
- Added pull-ups on the Pine64 i2c bus
- Removed the PMU since it doesn't work
- Refactored the sunxi-ng framework to deal with the specifities of
the A64 CCU, especially in terms of minimum factors.
- Fixed a few things in the CCU driver: added CLK_SET_RATE PARENT
flags, fixed some mux width, etc.
- Converted the CCU driver to a platform driver
- Added the DRAM reset line
- Added IDs for the USB muxes (even though we're not using them yet)
Changes from v1:
- Split the A64 CCU support out of the H3 driver
- Added the PMU support
- Removed the clocks node
- Rebased on top of current sunxi/clk-for-4.9 branch
Andre Przywara (3):
arm64: dts: add Allwinner A64 SoC .dtsi
Documentation: devicetree: add vendor prefix for Pine64
arm64: dts: add Pine64 support
Maxime Ripard (1):
clk: sunxi-ng: Add A64 clocks
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +-
Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 1 +-
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +-
MAINTAINERS | 1 +-
arch/arm64/boot/dts/Makefile | 1 +-
arch/arm64/boot/dts/allwinner/Makefile | 5 +-
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 50 +-
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 74 +-
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 263 ++-
drivers/clk/sunxi-ng/Kconfig | 11 +-
drivers/clk/sunxi-ng/Makefile | 1 +-
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 915 ++++++++-
drivers/clk/sunxi-ng/ccu-sun50i-a64.h | 72 +-
include/dt-bindings/clock/sun50i-a64-ccu.h | 134 +-
include/dt-bindings/reset/sun50i-a64-ccu.h | 98 +-
15 files changed, 1628 insertions(+), 0 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h
base-commit: d7c96a0efc8a9c67c498ea201c77735e35fb48c0
--
git-series 0.8.11
^ 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