On Thu, Oct 23, 2014 at 11:27:07PM +0100, Bjorn Helgaas wrote:
> On Thu, Oct 23, 2014 at 04:23:06PM +0100, Lorenzo Pieralisi wrote:
> > The number of windows allocated for the host bridge depends on the
> > bus resource. Instead of first allocating the windows and then
> > l
corresponding to the resource to be mapped, ie no
additional offset should be applied.
Cc: Arnd Bergmann
Cc: Russell King
Signed-off-by: Lorenzo Pieralisi
---
arch/arm/kernel/bios32.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm
er() before carrying out sanity checks
in pci_mmap_fits() so that the check is carried out on the resource
values as expected from the userspace mmap API.
Cc: Arnd Bergmann
Cc: Bjorn Helgaas
Cc: Benjamin Herrenschmidt
Cc: Russell King
Cc: David S. Miller
Cc: Michal Simek
Cc: Martin Wilck
Si
passed
from user space. Second patch fixes the way the pgoff is handled in
the ARM pci_mmap_page_range() implementation.
v1 posting:
http://marc.info/?l=linux-kernel&m=141337461318554&w=2
v1 => v2
- Reworded commit log as per RMK comments
Lorenzo Pieralisi (2):
drivers: pci: fix pc
On Fri, Oct 17, 2014 at 02:37:08PM +0100, Hanjun Guo wrote:
> Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
> from the GICC Structure introduced by ACPI 5.1.
>
> MPIDR is the CPU hardware ID as local APIC ID on x86 platform, so we use
> MPIDR not the GIC CPU interface ID
On Mon, Oct 27, 2014 at 12:03:35PM +, Will Deacon wrote:
> On Thu, Oct 23, 2014 at 04:23:07PM +0100, Lorenzo Pieralisi wrote:
> > In order to consolidate DT configuration for PCI host controllers in the
> > kernel, a new API (ie of_pci_get_host_bridge_resources()) was develop
On Thu, Oct 23, 2014 at 05:52:06PM +0100, Jason Gunthorpe wrote:
> On Thu, Oct 23, 2014 at 12:27:31PM +0100, Lorenzo Pieralisi wrote:
>
> > I think that by removing that, we could switch to CONFIG_PCI_DOMAINS_GENERIC
> > on ARM32. I will remove the dependency in drivers/pc
+ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -37,6 +37,7 @@
> compatible = "arm,cortex-a57", "arm,armv8";
> enable-method = "psci";
enable-method should be after reg, it is not an ordering issues added
by this patch but I s
On Fri, Oct 24, 2014 at 05:28:04PM +0100, Lorenzo Pieralisi wrote:
> The way PCI memory resources are exported to user space through procfs
> is not uniform across architectures. In particular, some architectures
> (ie SPARC) export the resource PCI bus address to user space, whereas
>
Hi Guenter,
On Wed, Jul 22, 2015 at 03:22:57PM +0100, Guenter Roeck wrote:
> On 07/22/2015 02:14 AM, Lorenzo Pieralisi wrote:
> > Bjorn, Guenter,
> >
> > On Thu, Jul 09, 2015 at 11:59:16AM +0100, Lorenzo Pieralisi wrote:
> >> When a PCI bus is scanned, upon P
On Thu, Jul 23, 2015 at 05:12:57PM +0100, Bjorn Helgaas wrote:
> On Thu, Jul 09, 2015 at 11:59:16AM +0100, Lorenzo Pieralisi wrote:
> > When a PCI bus is scanned, upon PCI bridge detection the kernel
> > has to read the bridge registers to set-up its resources so that
>
On Thu, Jul 23, 2015 at 05:47:44PM +0100, Guenter Roeck wrote:
> On 07/23/2015 09:12 AM, Bjorn Helgaas wrote:
> > On Thu, Jul 09, 2015 at 11:59:16AM +0100, Lorenzo Pieralisi wrote:
> >> When a PCI bus is scanned, upon PCI bridge detection the kernel
> >> has to read the
(&data, gsi, irq_type);
> + if (err)
> + return err;
>
> - /* Set irq type if specified and different than the current one */
> - if (irq_type != IRQ_TYPE_NONE &&
> - irq_type != irq_get_trigger_type(irq))
> - irq_set_ir
On Fri, Jul 24, 2015 at 09:55:42AM +0100, Will Deacon wrote:
> On Thu, Jul 23, 2015 at 06:48:45PM +0100, Lorenzo Pieralisi wrote:
> > On Thu, Jul 23, 2015 at 05:12:57PM +0100, Bjorn Helgaas wrote:
> > > I'm a little uneasy that we might break some alpha or mips system, sinc
qchip/irq-gic.c | 45
> ++---
> include/linux/irqchip/arm-gic.h | 2 +-
> 2 files changed, 34 insertions(+), 13 deletions(-)
Reviewed-by: Lorenzo Pieralisi
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index b41ccf5..c
unsigned long domain_token,
> + int (*populate)(struct acpi_gsi_descriptor *,
> + u32, unsigned int));
> +
> #ifdef CONFIG_X86_IO_APIC
> extern int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity);
On Tue, Jul 07, 2015 at 04:01:45PM +0100, Guenter Roeck wrote:
> Hi Lorenzo,
>
> On 07/07/2015 07:40 AM, Lorenzo Pieralisi wrote:
> > On Fri, Jun 19, 2015 at 05:24:13PM +0100, Lorenzo Pieralisi wrote:
> >> Hi Guenter,
> >>
> >> On Thu, Jun 18, 201
On Wed, Jun 24, 2015 at 12:02:14AM +0100, Bjorn Helgaas wrote:
> On Tue, Jun 23, 2015 at 5:46 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2015-06-02 at 15:55 +0100, Lorenzo Pieralisi wrote:
> >> While at it, do you think it is reasonable to also claim the bridge
> &
Hi Jisheng,
On Wed, Jul 08, 2015 at 01:51:07PM +0100, Jisheng Zhang wrote:
> Functions implemented on arm64 to suspend cpu and translate the idle
> state index passed by the cpu_suspend core call to a valid PSCI state
> are not arm64 specific and should be moved to generic code so that they
> can
On Wed, Jul 08, 2015 at 01:51:08PM +0100, Jisheng Zhang wrote:
> This patch implements cpuidle_ops using psci. After this patch, we can
> use cpuidle-arm.c with psci backend for both arm and arm64.
>
> Signed-off-by: Jisheng Zhang
> ---
> arch/arm/kernel/Makefile | 1 +
> arch/arm/kernel/
On Thu, Jul 09, 2015 at 09:43:04AM +0100, Jisheng Zhang wrote:
> On Thu, 9 Jul 2015 16:31:24 +0800
> Jisheng Zhang wrote:
>
> > As for the suspend member function, the to-be-suspended cpu is always
> > the calling cpu itself, so the 'cpu' parameter may not be necessary, let
> > driver get 'cpu' i
PCI_PROBE_ONLY
flag before reading the bridge bases.
Signed-off-by: Lorenzo Pieralisi
Cc: Ralf Baechle
Cc: James E.J. Bottomley
Cc: Michael Ellerman
Cc: Bjorn Helgaas
Cc: Richard Henderson
Cc: Benjamin Herrenschmidt
Cc: David Howells
Cc: Russell King
Cc: Tony Luck
Cc: David S. Miller
Cc: Ingo
sap, if we can use the struct pci_bus.msi pointer patch that's
trivial).
I know that the way forward is by doing it through domains and this
patchset, just asking (to understand why pcibios_msi_controller is
even needed on arm at present).
> This has been tested on arm64 with GI
Hi Lukasz,
On Wed, Aug 26, 2015 at 11:43:04AM +0100, Marc Zyngier wrote:
> Hi Lukasz,
>
> On 26/08/15 08:04, Anaczkowski, Lukasz wrote:
> > On Monday, August 3, 2015 8:26 PM
> > Lukasz Anaczkowski wrote:
> >
> >> v2: Fixed ARM64 syntax error
> >
> > Hi Marc,
> >
> > Does this patch look ok no
On Wed, Aug 26, 2015 at 06:49:29PM +0100, Lukasz Anaczkowski wrote:
[...]
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 2e19189..d5c9a1b 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -214,27 +214,45 @@ void acpi_table_print_madt_entry(struct
> acp
On Tue, Jul 28, 2015 at 11:45:42AM +0100, Ley Foon Tan wrote:
[...]
> +static int altera_pcie_parse_request_of_pci_ranges(struct altera_pcie *pcie)
> +{
> + int err, res_valid = 0;
> + struct device *dev = &pcie->pdev->dev;
> + struct device_node *np = dev->of_node;
> + re
On Sun, Jul 26, 2015 at 10:45:54PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 15, 2015 at 04:40:56PM +0100, Lorenzo Pieralisi wrote:
> > static struct cpuidle_ops psci_cpuidle_ops __initdata = {
> > .suspend = cpu_psci_cpu_suspend,
> > .init = c
On Mon, Jul 27, 2015 at 10:45:07AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 27, 2015 at 10:16:02AM +0100, Lorenzo Pieralisi wrote:
> > Yes, I would only ask you, if the plan above (which can be implemented
> > in two steps) makes sense to you please consider acceptin
Hi David,
On Wed, Jul 15, 2015 at 05:54:43PM +0100, David Daney wrote:
> From: David Daney
>
> The default is to continue doing the what we have done before, but add
> a hook so that this can be overridden.
This commit log is inappropriate. On top of that, it is already
complicated enough to ke
Hi David,
On Wed, Jul 15, 2015 at 05:54:45PM +0100, David Daney wrote:
> From: David Daney
>
-ENOCOMMITLOG
> Signed-off-by: David Daney
> ---
> drivers/pci/host/Kconfig| 12 +
> drivers/pci/host/Makefile | 2 +
> drivers/pci/host/pcie-thunder-pem.c | 462
> +
Hi David,
On Thu, Jul 16, 2015 at 06:00:36PM +0100, David Daney wrote:
> On 07/16/2015 02:04 AM, Lorenzo Pieralisi wrote:
> > Hi David,
> >
> > On Wed, Jul 15, 2015 at 05:54:43PM +0100, David Daney wrote:
> >> From: David Daney
> >>
> [...]
> >>
On Thu, Apr 14, 2016 at 01:55:32AM -0400, Jon Masters wrote:
[...]
> > I will comment on the patches as soon as I have time to review
> > them, I certainly would like to understand what we have to do with the
> > rest of the code though (provided this series is good to go) see above.
>
> Right.
struct fwnode_handle *iort_pci_get_domain(struct pci_dev *pdev, u32
req_id);
This patch fixes the warnings with a struct pci_dev forward declaration
in the IORT header file.
Signed-off-by: Lorenzo Pieralisi
Cc: Tomasz Nowicki
---
include/linux/iort.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/li
signature so that it does not take anymore the DT specific
of_phandle_args argument and replaces it with the DT agnostic
iommu_fwspec one.
Signed-off-by: Lorenzo Pieralisi
Cc: Matthias Brugger
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Rob Herring
Cc: Krzysztof Kozlowski
Cc: Robin Murphy
Cc: Tomasz
.
Based on prior work by Hanjun Guo .
Signed-off-by: Lorenzo Pieralisi
Cc: Hanjun Guo
Cc: Tomasz Nowicki
Cc: "Rafael J. Wysocki"
---
drivers/acpi/iort.c | 59 +++--
1 file changed, 53 insertions(+), 6 deletions(-)
diff --git a/drivers/a
domain
kernel layer, this patch adds an additional fwnode type FWNODE_IOMMU.
This patch also implements a glue kernel layer that allows to
allocate/free FWNODE_IOMMU fwnode_handle structures and associate
them with IOMMU devices.
Signed-off-by: Lorenzo Pieralisi
Cc: Joerg Roedel
Cc: "Raf
by the kernel on boot and allows
to detect and configure the ARM SMMU devices present in the system.
Based on prior work by Hanjun Guo .
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Robin Murphy
Cc: Tomasz Nowicki
---
drivers/iommu/arm-smmu.c | 240
iommu_fwspec
can be converted to it too in all kernel components currently making
use of it.
Signed-off-by: Lorenzo Pieralisi
Cc: Joerg Roedel
Cc: "Rafael J. Wysocki"
Cc: Marc Zyngier
---
Documentation/IRQ-domain.txt | 2 +-
arch/arm/mach-exynos/suspend.c | 6 +++---
arches.
Signed-off-by: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Robin Murphy
Cc: Tomasz Nowicki
Cc: Joerg Roedel
Cc: "Rafael J. Wysocki"
---
drivers/acpi/glue.c | 4 +--
drivers/acpi/iort.c | 85 +
drivers/acpi/scan.
() callback that allows
streamid translation on ACPI based ARM system.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Robin Murphy
---
drivers/iommu/arm-smmu.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 84bcff7
so that other FW interfaces (ie ACPI) can
reuse the HW probing functions and skip the DT portion accordingly.
This patch implements no functional change, only code reshuffling.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Robin Murphy
---
drivers/iommu/arm-smmu.c | 80
d with
the driver specific callback is matched.
Signed-off-by: Lorenzo Pieralisi
Cc: Tomasz Nowicki
Cc: "Rafael J. Wysocki"
Cc: Marc Zyngier
---
drivers/acpi/iort.c | 2 ++
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/iort.h | 3 +++
3 files c
The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world)
components that allow creating the kernel data structures required to
probe and initialize the IOMMU devices.
This patch provides support in the IORT kernel code to register IOMMU
components.
Signed-off-by: Lorenzo Pieralisi
o/?l=linux-arm-kernel&m=145675372917701&w=2
T.Nowicki "Introduce ACPI world to ITS irqchip"
https://marc.info/?l=linux-acpi&m=145976009630179&w=2
Tested on Juno-r2 board with both DT and ACPI probing paths.
Lorenzo Pieralisi (11):
drivers: acpi: iort: fix struct pci_dev com
Hi Al,
On Mon, Mar 28, 2016 at 06:06:42PM -0600, Al Stone wrote:
> The ACPI 6.1 specification was recently released at the end of January
> 2016, but the arm64 kernel documentation for the use of ACPI was written
> for the 5.1 version of the spec. There were significant additions to the
> spec th
On Fri, Apr 15, 2016 at 10:41:02AM -0600, Al Stone wrote:
> On 04/15/2016 08:37 AM, Lorenzo Pieralisi wrote:
> > Hi Al,
> >
> > On Mon, Mar 28, 2016 at 06:06:42PM -0600, Al Stone wrote:
> >> The ACPI 6.1 specification was recently released at the end of January
&
On Thu, Apr 28, 2016 at 04:48:00PM -0500, Bjorn Helgaas wrote:
[...]
> > +static int pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root,
> > + struct acpi_pci_generic_root_info *ri)
> > +{
> > + u16 seg = root->segment;
> > + u8 bus_start = root->secondary
On Thu, Apr 28, 2016 at 05:47:15PM -0400, Jon Masters wrote:
[...]
> >>> In general, there's no reason we can't reassign BARs, whether we're
> >>> using DT, ACPI, or whatever. In many cases, systems with ACPI also
> >>> assign all the BARs in firmware, and Linux doesn't reassign them
> >>> unles
On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote:
>
>
> On 28.04.16 20:06, Bjorn Helgaas wrote:
> > On Thu, Apr 28, 2016 at 06:41:42PM +0200, Alexander Graf wrote:
> >> On 04/28/2016 06:20 PM, Bjorn Helgaas wrote:
> >>> On Thu, Apr 28, 2016 at 12:22:24AM +0200, Alexander Graf wrote:
On Fri, Apr 29, 2016 at 11:05:34PM +0530, Jayachandran C wrote:
> On Fri, Apr 29, 2016 at 2:07 PM, Lorenzo Pieralisi
> wrote:
> > On Thu, Apr 28, 2016 at 04:48:00PM -0500, Bjorn Helgaas wrote:
> >
> > [...]
> >
> >> > +static int pci_acpi_set
On Mon, May 02, 2016 at 06:56:13PM +0530, Jayachandran C wrote:
> On Mon, May 2, 2016 at 6:13 PM, Tomasz Nowicki wrote:
> > On 04/27/2016 01:17 PM, Lorenzo Pieralisi wrote:
> >>
> >> On Tue, Apr 26, 2016 at 09:26:49PM -0500, Bjorn Helgaas wrote:
> >>>
&
On Tue, May 03, 2016 at 07:52:52PM +0530, Jayachandran C wrote:
> On Tue, May 3, 2016 at 4:32 PM, Lorenzo Pieralisi
> wrote:
> > On Mon, May 02, 2016 at 06:56:13PM +0530, Jayachandran C wrote:
> >> On Mon, May 2, 2016 at 6:13 PM, Tomasz Nowicki wrote:
> >> >
On Tue, May 10, 2016 at 09:18:49AM +0200, Daniel Lezcano wrote:
> On the ARM64 architecture, when CPUIDLE is not set in the configuration,
> the compilation raises a couple of warnings:
>
> drivers/firmware/psci.c:70:12: warning: 'psci_pd_power_off' defined but not
> used [-Wunused-function]
> dr
On Mon, May 09, 2016 at 08:53:36PM -0500, Bjorn Helgaas wrote:
> On Tue, May 10, 2016 at 12:56:37AM +0200, Rafael J. Wysocki wrote:
> > On Friday, April 15, 2016 07:06:36 PM Tomasz Nowicki wrote:
> > > Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
> > > bridge initialization
On Tue, May 10, 2016 at 12:18:59AM +0200, Rafael J. Wysocki wrote:
[...]
> > >> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > >> index ae3fe4e..4581e0e 100644
> > >> --- a/drivers/acpi/pci_root.c
> > >> +++ b/drivers/acpi/pci_root.c
> > >> @@ -564,6 +564,11 @@ static int acpi
On Tue, May 10, 2016 at 08:37:00PM +0200, Rafael J. Wysocki wrote:
> On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote:
> > This patch provides a way to set the ACPI companion in PCI code.
> > We define acpi_pci_set_companion() to set the ACPI companion pointer and
> > call it from PCI core co
On Wed, May 11, 2016 at 05:43:14PM -0500, Bjorn Helgaas wrote:
> On Wed, May 11, 2016 at 10:30:51PM +0200, Rafael J. Wysocki wrote:
> > On Wed, May 11, 2016 at 12:11 PM, Lorenzo Pieralisi
> > wrote:
> > > On Tue, May 10, 2016 at 08:37:00PM +0200, Rafael J. Wysocki wrot
On Sun, May 22, 2016 at 01:42:52PM -0700, Steve Muckle wrote:
> On Sun, May 22, 2016 at 12:39:12PM +0200, Peter Zijlstra wrote:
> > On Fri, May 20, 2016 at 05:53:41PM +0530, Shilpasri G Bhat wrote:
> > >
> > > Below are the comparisons by disabling watchdog.
> > > Both schedutil and ondemand have
On Fri, May 20, 2016 at 11:14:03AM +0200, Ard Biesheuvel wrote:
> On 20 May 2016 at 10:40, Gabriele Paoloni wrote:
> > Hi Ard
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> [...]
> >>
> >> Is the PCIe root complex so special that you cannot simpl
On Tue, May 17, 2016 at 12:48:53PM -0400, Jon Masters wrote:
> On 05/17/2016 12:44 PM, Jon Masters wrote:
>
> > 1). During development of a platform, it is much easier to debug
> > problems with tables if you can test replacement ones without having to
> > respin the firmware. In the server world,
Hi Bjorn,
On Mon, May 23, 2016 at 06:39:18PM -0500, Bjorn Helgaas wrote:
[...]
> On Mon, May 23, 2016 at 03:16:01PM +, Gabriele Paoloni wrote:
> I don't think of ECAM support itself as a "driver". It's just a
> service available to drivers, similar to OF resource parsing.
>
> Per PCI Firmw
Hi Duc,
On Wed, May 25, 2016 at 04:13:35PM -0700, Duc Dang wrote:
> On Thu, Feb 25, 2016 at 9:38 AM, Lorenzo Pieralisi
> wrote:
> > On Wed, Feb 24, 2016 at 02:28:10PM -0800, Duc Dang wrote:
> >> On Wed, Feb 24, 2016 at 8:16 AM, Marc Zyngier wrote:
> >> > On
[+ Rafael]
On Thu, May 26, 2016 at 01:49:23PM -0700, Duc Dang wrote:
> Hi Lorenzo,
>
> On Thu, May 26, 2016 at 5:34 AM, Lorenzo Pieralisi
> wrote:
> > Hi Duc,
> >
> > On Wed, May 25, 2016 at 04:13:35PM -0700, Duc Dang wrote:
> >> On Thu, Feb 25, 2016 at
On Tue, Apr 26, 2016 at 09:26:49PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 15, 2016 at 07:06:37PM +0200, Tomasz Nowicki wrote:
> > As we now have valid PCI host bridge device reference we can
> > introduce code that is going to find its bus domain number using
> > ACPI _SEG method.
> >
> > Note
parsing
> > is confined in one single arch callback that can be easily removed
> > when code parsing PCI legacy IRQs is consolidated and moved to core
> > PCI code.
> >
> > Signed-off-by: Tomasz Nowicki
> > Suggested-by: Lorenzo Pieralisi
> > ---
> >
On Tue, Apr 26, 2016 at 09:39:16PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote:
> > Platforms that have memory mapped IO port (such as ARM64) need special
> > handling for PCI I/O resources. For host bridge's resource probing case
> > these resources
On Wed, Apr 27, 2016 at 04:10:36PM +0100, liviu.du...@arm.com wrote:
> On Wed, Apr 27, 2016 at 03:26:59PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Apr 26, 2016 at 09:39:16PM -0500, Bjorn Helgaas wrote:
> > > On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote:
>
On Wed, Apr 27, 2016 at 11:44:53AM -0500, Bjorn Helgaas wrote:
> On Wed, Apr 27, 2016 at 12:17:58PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Apr 26, 2016 at 09:26:49PM -0500, Bjorn Helgaas wrote:
> > > On Fri, Apr 15, 2016 at 07:06:37PM +0200, Tomasz Nowicki wrote:
> >
On Wed, May 11, 2016 at 12:11 PM, Lorenzo Pieralisi
> >>> wrote:
> >>> > On Tue, May 10, 2016 at 08:37:00PM +0200, Rafael J. Wysocki wrote:
> >>> >> On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki
> >>> >> wrote:
>
> [cut]
>
On Tue, Nov 10, 2015 at 01:50:46PM +0800, Jiang Liu wrote:
[...]
> >> In particular, I would like to understand, for an eg DWordIO descriptor,
> >> what Range Minimum, Range Maximum and Translation Offset represent,
> >> they can't mean different things depending on the SW parsing them,
> >> this
On Wed, Nov 11, 2015 at 09:55:37PM +0100, Arnd Bergmann wrote:
> On Wednesday 11 November 2015 17:46:47 Lorenzo Pieralisi wrote:
> > On Tue, Nov 10, 2015 at 01:50:46PM +0800, Jiang Liu wrote:
> > If we go with this approach though, you are not adding the offset to
> > the reso
Please trim your emails, thanks.
On Fri, Nov 13, 2015 at 01:57:30PM +0100, Tomasz Nowicki wrote:
> On 12.11.2015 16:05, Jiang Liu wrote:
[...]
> >>>IA64 actually ignores the translation type flag and just assume it's
> >>>TypeTranslation, so there may be some IA64 BIOS implementations
> >>>accid
On Thu, Dec 03, 2015 at 09:58:14PM +0100, Arnd Bergmann wrote:
[...]
> > Let's first rewind a bit though, to summarize:
> >
> > 1) we need a way to configure a "generic host controller" with host
> >controller specific config methods (ie ECAM, even though is a PCI
> >standard it is not s
On Wed, Dec 16, 2015 at 06:21:37PM +0530, Jayachandran C. wrote:
[...]
> > That list is there to manage hotplug bridges, what makes you think
> > it is not necessary ? Jiang (in CC) can certainly comment on that and
> > how that list handling can be updated/simplified, if possible.
>
> Looking t
Hi Jiang,
On Sat, Nov 14, 2015 at 01:49:08AM +0800, Jiang Liu wrote:
[...]
> > Not really. My concern is that there might be platforms out there with
> > an offset between the CPU and PCI physical address spaces, and if we
> > remove the offset value in acpi_decode_space we can break them,
> > b
> ---
> arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 16
> 1 file changed, 16 insertions(+)
Acked-by: Lorenzo Pieralisi
>
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 39d0676..3649ce
On Wed, Dec 02, 2015 at 10:59:05PM +0800, fu@linaro.org wrote:
[...]
> +#ifdef CONFIG_ACPI_APEI
> +extern int acpi_disable_cmcff;
> +#endif
>
> static inline void disable_acpi(void)
> {
> @@ -94,6 +97,7 @@ static inline const char *acpi_get_enable_method(int cpu)
>
> #ifdef CONFI
Hi Gab,
On Thu, Dec 03, 2015 at 11:19:58PM +0800, Gabriele Paoloni wrote:
[...]
> +void acpi_arm64_quirks(void)
> +{
> + int i = 0;
> +
> + while (quirks_array[i]) {
> + acpi_scan_add_handler(quirks_array[i]);
> + i++;
> + }
> +
> +}
This code is not arm64 sp
On Wed, Sep 09, 2015 at 02:47:55PM +0100, Tomasz Nowicki wrote:
[...]
> > I think (but I am happy to be corrected) that the map_bus() hook
> > (ie that's why struct pci_bus is required in eg pci_generic_config_write)
> > is there to ensure that when the generic accessors are called
> > a) we have
On Fri, Sep 11, 2015 at 01:35:36PM +0100, Tomasz Nowicki wrote:
> On 11.09.2015 13:20, Lorenzo Pieralisi wrote:
[...]
> >>> With that in place using raw_pci_write/read or the generic accessors
> >>> becomes almost identical, with code requiring the pci_bus to be
>
On Tue, Dec 08, 2015 at 03:03:03PM +0800, fu@linaro.org wrote:
> From: Tomasz Nowicki
[...]
> +#if defined(__i386__) || defined(__x86_64__)
> /*
> * Check if firmware advertises firmware first mode. We need FF bit to be set
> * along with a set of MC banks which work in FF mode.
> */
On Tue, Dec 08, 2015 at 09:08:24PM +0800, Fu Wei wrote:
> Hi Lorenzo,
>
>
>
> On 8 December 2015 at 20:52, Hanjun Guo wrote:
> > Hi Lorenzo,
> >
> > On 12/08/2015 08:34 PM, Lorenzo Pieralisi wrote:
> >>
> >> On Tue, Dec 08, 2015 at 03:03:03
On Wed, Dec 09, 2015 at 03:31:41PM +0530, Jayachandran C. wrote:
> [trimmed the cc list a bit]
> On Mon, Dec 07, 2015 at 02:31:17PM -0600, Bjorn Helgaas wrote:
> > On Tue, Oct 27, 2015 at 05:38:31PM +0100, Tomasz Nowicki wrote:
> [...]
> > >
> > > Tomasz Nowicki (10):
> > > x86, pci: Reorder log
On Tue, Jul 21, 2015 at 11:07:57AM +0100, Marc Zyngier wrote:
> struct device_node is very much DT specific, and the original authors
> of the irqdomain subsystem recognized that tie, and went as far as
> mentionning that this could be replaced by some "void *token",
> should another firmware infra
On Tue, Jul 21, 2015 at 11:08:00AM +0100, Marc Zyngier wrote:
> Now that the basic ACPI GSI code is irq domain aware, make sure
> that the ACPI support in the GIC doesn't pointlessly deviate from
> the DT path.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/irqchip/irq-gic.c | 17 ++--
On Tue, Jul 21, 2015 at 11:07:59AM +0100, Marc Zyngier wrote:
> Now that the irqdomain layer is a bit more ACPI friendly, add the
> mapping code that allows irq_create_acpi_mapping to be called.
>
> As we only support the GIC so far, support is pretty limited.
>
> Signed-off-by: Marc Zyngier
> -
Bjorn, Guenter,
On Thu, Jul 09, 2015 at 11:59:16AM +0100, Lorenzo Pieralisi wrote:
> When a PCI bus is scanned, upon PCI bridge detection the kernel
> has to read the bridge registers to set-up its resources so that
> the PCI resource hierarchy can be validated properly.
>
>
Hi Tomasz,
On Wed, Jan 13, 2016 at 02:20:59PM +0100, Tomasz Nowicki wrote:
[...]
> @@ -4796,14 +4797,34 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus,
> struct device *parent)
>* API and update the use_dt_domains value to keep track of method we
>* are using to assign dom
On Thu, Jan 21, 2016 at 07:38:51PM +0100, Tomasz Nowicki wrote:
[...]
> >I think you can reshuffle a bit the code to make it easier to follow.
> >
> >How about this ? (on top of mainline, I just compiled it do not
> >take it verbatim):
> >
> >-- >8 --
> >diff --git a/drivers/pci/pci.c b/drivers/p
cy bits which are otherwise
pretty complex to untangle, so (apart from a few nits below):
Reviewed-by: Lorenzo Pieralisi
[...]
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> new file mode 100644
> index 000..ea84365
> --- /dev/null
> +++ b/drivers/acpi/pci
be generalized if common functionality is found among
arches) allowing arches where PCI_Config regions are currently required
to override it (eg x86) as needed and providing at the same time
default stubs for arches that do not require them".
?
> Suggested-by: Lorenzo Pieralisi
> S
Guys,
On Wed, Feb 17, 2016 at 04:35:30PM +0100, Tomasz Nowicki wrote:
[...]
> >In my patchset, I had a slightly different and I think better approach
> >for
> >this without calling the _SEG method again. Please see
> >http://www.spinics.net/lists/arm-kernel/msg478167.html
> >
easily removed
when code parsing PCI legacy IRQs is consolidated and moved to core
PCI code".
?
> Signed-off-by: Tomasz Nowicki
> Suggested-by: Lorenzo Pieralisi
> ---
> arch/arm64/kernel/pci.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> d
ci_mcfg_dev_base(struct pci_bus *bus,
> + unsigned int devfn, int offset)
> +{ return NULL; }
> +#endif
> +
> #else/* CONFIG_ACPI */
> static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
> static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
I think it can even be squashed, anyway:
Reviewed-by: Lorenzo Pieralisi
MCFG region to a bridge structure, the end result
should be equivalent though, so:
Reviewed-by: Lorenzo Pieralisi
>
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 0467b00..3282f2a 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
>
to dirver/acpi/ directory
> - fixed IO resource handling
> - introduced PCI config accessors quirks matching
> - moved ACPI_COMPANION_SET to generic code
>
> v1 - https://lkml.org/lkml/2015/10/27/504
> v2 - https://lkml.org/lkml/2015/12/16/246
> v3 - http://lkml.iu.edu/hyper
On Thu, Feb 18, 2016 at 08:25:35PM +0800, liudongdong (C) wrote:
[...]
> >+/*
> >+ * Map a pci_mmcfg_region, can be overrriden by arch
> >+ */
> >+int __weak pci_mmconfig_map_resource(struct device *dev,
> >+struct pci_mmcfg_region *mcfg)
> >+{
> >+struct resource *tmp;
> >+void __iom
On Thu, Feb 18, 2016 at 06:13:57PM +, Catalin Marinas wrote:
> On Thu, Feb 18, 2016 at 06:03:54PM +, Will Deacon wrote:
> > On Thu, Feb 18, 2016 at 05:54:47PM +, Catalin Marinas wrote:
> > > On Thu, Feb 18, 2016 at 05:27:38PM +, Mark Rutland wrote:
> > > > @@ -145,6 +146,7 @@ ENTRY(
Hi,
On Mon, Feb 01, 2016 at 07:36:57PM +0800, Hanjun Guo wrote:
> On 2016/2/1 18:25, Lorenzo Pieralisi wrote:
> >The [0 - 64k] ACPI PCI IO port resource boundary check in:
> >
> >acpi_dev_ioresource_flags()
> >
> >is currently applied blindly in the ACPI resourc
tions(-)
This patch has to be squashed with the previous one otherwise it
has bisectability issues (ie the previous patch passes the parent
to the pci_create_root_bus() call so, without this patch applied,
the companion initialization would fail).
Other than that:
Reviewed-by: Lorenzo Pieralis
701 - 800 of 2178 matches
Mail list logo
