Re: [PATCH v3 11/14] ACPI: irq: introduce interrupt producer

[G Gregory]

On Tue, Oct 25, 2016 at 11:09:26PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo 
> 
> 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 
> Cc: Rafael J. Wysocki 
> Cc: Marc Zyngier 
> Cc: Agustin Vega-Frias 
> Cc: Lorenzo Pieralisi 
> ---
>  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 && >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(>dev, gsi, triggering, polarity);
>   if (irq >= 0) {
>   res->start = irq;
>   res->end = irq;
> @@ -424,27 +424,9 @@ 

Re: [PATCH v3 11/14] ACPI: irq: introduce interrupt producer

[G Gregory]

On Tue, Oct 25, 2016 at 11:09:26PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo 
> 
> 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 
> Cc: Rafael J. Wysocki 
> Cc: Marc Zyngier 
> Cc: Agustin Vega-Frias 
> Cc: Lorenzo Pieralisi 
> ---
>  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 && >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(>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 

Re: [PATCH] ACPI / amba: Remove CLK_IS_ROOT

[G Gregory]

On 20 April 2016 at 02:28, Stephen Boyd  wrote:
> This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
> CLK_IS_ROOT", 2016-02-02) so remove it.
>
> Cc: Graeme Gregory 
> Cc: Aleksey Makarov 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/acpi/acpi_amba.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
> index 2a61b54ab968..7f77c071709a 100644
> --- a/drivers/acpi/acpi_amba.c
> +++ b/drivers/acpi/acpi_amba.c
> @@ -35,8 +35,7 @@ static void amba_register_dummy_clk(void)
> if (amba_dummy_clk)
> return;
>
> -   amba_dummy_clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL,
> -   CLK_IS_ROOT, 0);
> +   amba_dummy_clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, 0, 
> 0);
> clk_register_clkdev(amba_dummy_clk, "apb_pclk", NULL);
>  }
>
Looks good to me.

Acked-by: Graeme Gregory 

Re: [PATCH] ACPI / amba: Remove CLK_IS_ROOT

[G Gregory]

On 20 April 2016 at 02:28, Stephen Boyd  wrote:
> This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
> CLK_IS_ROOT", 2016-02-02) so remove it.
>
> Cc: Graeme Gregory 
> Cc: Aleksey Makarov 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/acpi/acpi_amba.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
> index 2a61b54ab968..7f77c071709a 100644
> --- a/drivers/acpi/acpi_amba.c
> +++ b/drivers/acpi/acpi_amba.c
> @@ -35,8 +35,7 @@ static void amba_register_dummy_clk(void)
> if (amba_dummy_clk)
> return;
>
> -   amba_dummy_clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL,
> -   CLK_IS_ROOT, 0);
> +   amba_dummy_clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, 0, 
> 0);
> clk_register_clkdev(amba_dummy_clk, "apb_pclk", NULL);
>  }
>
Looks good to me.

Acked-by: Graeme Gregory 

Re: [Linaro-acpi] [PATCH V6 12/13] pci, pci-thunder-ecam: Add ACPI support for ThunderX ECAM.

[G Gregory]

On Tue, Apr 19, 2016 at 01:22:29PM +0200, Tomasz Nowicki wrote:
> 
> 
> On 19.04.2016 13:12, Graeme Gregory wrote:
> >On Tue, Apr 19, 2016 at 11:41:29AM +0100, G Gregory wrote:
> >>On 19 April 2016 at 11:26, Tomasz Nowicki <t...@semihalf.com> wrote:
> >>>On 15.04.2016 19:06, Tomasz Nowicki wrote:
> >>>>
> >>>>Passes 1.x miss PCI enhanced allocation (EA) header for fixed-BARs,
> >>>>thus these passes should use Cavium-specific config access functions
> >>>>that synthesize the missing EA capabilities.
> >>>>
> >>>>We already have DT driver which addresses errata requirements and
> >>>>allows to use special PCI config accessors. Currently this driver uses
> >>>>compatible = "cavium,pci-host-thunder-ecam" to mach against the errata.
> >>>>For ACPI case we need explicit errata number and corresponding
> >>>>DECLARE_ACPI_MCFG_FIXUP fixup code.
> >>>>
> >>>>Signed-off-by: Tomasz Nowicki <t...@semihalf.com>
> >>>>---
> >>>>   arch/arm64/Kconfig  | 14 ++
> >>>>   arch/arm64/include/asm/cpufeature.h |  3 ++-
> >>>>   arch/arm64/kernel/cpu_errata.c  |  8 
> >>>>   drivers/pci/host/pci-thunder-ecam.c | 35
> >>>>+++
> >>>>   4 files changed, 59 insertions(+), 1 deletion(-)
> >>>>
> >>>>diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >>>>index 1bded87..b7614b8 100644
> >>>>--- a/arch/arm64/Kconfig
> >>>>+++ b/arch/arm64/Kconfig
> >>>>@@ -445,6 +445,20 @@ config CAVIUM_ERRATUM_27456
> >>>>
> >>>>   If unsure, say Y.
> >>>>
> >>>>+config CAVIUM_ERRATUM_24575
> >>>>+   bool "Cavium erratum 24575: Enhanced Allocation (EA) emualaion"
> >>>>+   default y
> >>>>+   help
> >>>>+ Enable workaround for erratum 24575.
> >>>>+
> >>>>+ Early versions of the Cavium Thunder CN88XX processor are
> >>>>missing
> >>>>+ Enhanced Allocation (EA) capabilities for the fixed BAR
> >>>>addresses used
> >>>>+ by the on-SoC hardware blocks. The erratum adds config access
> >>>>+ functions that synthesize the missing EA capabilities for
> >>>>versions
> >>>>+ that are missing that information.
> >>>>+
> >>>>+ If unsure, say Y.
> >>>>+
> >>>>   endmenu
> >>>>
> >>>>
> >>>>diff --git a/arch/arm64/include/asm/cpufeature.h
> >>>>b/arch/arm64/include/asm/cpufeature.h
> >>>>index b9b6494..a78364e 100644
> >>>>--- a/arch/arm64/include/asm/cpufeature.h
> >>>>+++ b/arch/arm64/include/asm/cpufeature.h
> >>>>@@ -35,8 +35,9 @@
> >>>>   #define ARM64_ALT_PAN_NOT_UAO 10
> >>>>   #define ARM64_HAS_VIRT_HOST_EXTN  11
> >>>>   #define ARM64_WORKAROUND_CAVIUM_27456 12
> >>>>+#define ARM64_WORKAROUND_CAVIUM_24575  13
> >>>>
> >>>>-#define ARM64_NCAPS13
> >>>>+#define ARM64_NCAPS14
> >>>>
> >>>>   #ifndef __ASSEMBLY__
> >>>>
> >>>>diff --git a/arch/arm64/kernel/cpu_errata.c
> >>>>b/arch/arm64/kernel/cpu_errata.c
> >>>>index 06afd04..89c13d7 100644
> >>>>--- a/arch/arm64/kernel/cpu_errata.c
> >>>>+++ b/arch/arm64/kernel/cpu_errata.c
> >>>>@@ -97,6 +97,14 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> >>>>(1 << MIDR_VARIANT_SHIFT) | 1),
> >>>> },
> >>>>   #endif
> >>>>+#ifdef CONFIG_CAVIUM_ERRATUM_24575
> >>>>+   {
> >>>>+   /* Cavium ThunderX, pass 1.x */
> >>>>+   .desc = "Cavium erratum 24575",
> >>>>+   .capability = ARM64_WORKAROUND_CAVIUM_24575,
> >>>>+   MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
> >>>>+   },
> >>>>+#endif
> >>>> {
> >>>> }
> >>>>   };
> >>>>

Re: [Linaro-acpi] [PATCH V6 12/13] pci, pci-thunder-ecam: Add ACPI support for ThunderX ECAM.

[G Gregory]

On Tue, Apr 19, 2016 at 01:22:29PM +0200, Tomasz Nowicki wrote:
> 
> 
> On 19.04.2016 13:12, Graeme Gregory wrote:
> >On Tue, Apr 19, 2016 at 11:41:29AM +0100, G Gregory wrote:
> >>On 19 April 2016 at 11:26, Tomasz Nowicki  wrote:
> >>>On 15.04.2016 19:06, Tomasz Nowicki wrote:
> >>>>
> >>>>Passes 1.x miss PCI enhanced allocation (EA) header for fixed-BARs,
> >>>>thus these passes should use Cavium-specific config access functions
> >>>>that synthesize the missing EA capabilities.
> >>>>
> >>>>We already have DT driver which addresses errata requirements and
> >>>>allows to use special PCI config accessors. Currently this driver uses
> >>>>compatible = "cavium,pci-host-thunder-ecam" to mach against the errata.
> >>>>For ACPI case we need explicit errata number and corresponding
> >>>>DECLARE_ACPI_MCFG_FIXUP fixup code.
> >>>>
> >>>>Signed-off-by: Tomasz Nowicki 
> >>>>---
> >>>>   arch/arm64/Kconfig  | 14 ++
> >>>>   arch/arm64/include/asm/cpufeature.h |  3 ++-
> >>>>   arch/arm64/kernel/cpu_errata.c  |  8 
> >>>>   drivers/pci/host/pci-thunder-ecam.c | 35
> >>>>+++
> >>>>   4 files changed, 59 insertions(+), 1 deletion(-)
> >>>>
> >>>>diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >>>>index 1bded87..b7614b8 100644
> >>>>--- a/arch/arm64/Kconfig
> >>>>+++ b/arch/arm64/Kconfig
> >>>>@@ -445,6 +445,20 @@ config CAVIUM_ERRATUM_27456
> >>>>
> >>>>   If unsure, say Y.
> >>>>
> >>>>+config CAVIUM_ERRATUM_24575
> >>>>+   bool "Cavium erratum 24575: Enhanced Allocation (EA) emualaion"
> >>>>+   default y
> >>>>+   help
> >>>>+ Enable workaround for erratum 24575.
> >>>>+
> >>>>+ Early versions of the Cavium Thunder CN88XX processor are
> >>>>missing
> >>>>+ Enhanced Allocation (EA) capabilities for the fixed BAR
> >>>>addresses used
> >>>>+ by the on-SoC hardware blocks. The erratum adds config access
> >>>>+ functions that synthesize the missing EA capabilities for
> >>>>versions
> >>>>+ that are missing that information.
> >>>>+
> >>>>+ If unsure, say Y.
> >>>>+
> >>>>   endmenu
> >>>>
> >>>>
> >>>>diff --git a/arch/arm64/include/asm/cpufeature.h
> >>>>b/arch/arm64/include/asm/cpufeature.h
> >>>>index b9b6494..a78364e 100644
> >>>>--- a/arch/arm64/include/asm/cpufeature.h
> >>>>+++ b/arch/arm64/include/asm/cpufeature.h
> >>>>@@ -35,8 +35,9 @@
> >>>>   #define ARM64_ALT_PAN_NOT_UAO 10
> >>>>   #define ARM64_HAS_VIRT_HOST_EXTN  11
> >>>>   #define ARM64_WORKAROUND_CAVIUM_27456 12
> >>>>+#define ARM64_WORKAROUND_CAVIUM_24575  13
> >>>>
> >>>>-#define ARM64_NCAPS13
> >>>>+#define ARM64_NCAPS14
> >>>>
> >>>>   #ifndef __ASSEMBLY__
> >>>>
> >>>>diff --git a/arch/arm64/kernel/cpu_errata.c
> >>>>b/arch/arm64/kernel/cpu_errata.c
> >>>>index 06afd04..89c13d7 100644
> >>>>--- a/arch/arm64/kernel/cpu_errata.c
> >>>>+++ b/arch/arm64/kernel/cpu_errata.c
> >>>>@@ -97,6 +97,14 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> >>>>(1 << MIDR_VARIANT_SHIFT) | 1),
> >>>> },
> >>>>   #endif
> >>>>+#ifdef CONFIG_CAVIUM_ERRATUM_24575
> >>>>+   {
> >>>>+   /* Cavium ThunderX, pass 1.x */
> >>>>+   .desc = "Cavium erratum 24575",
> >>>>+   .capability = ARM64_WORKAROUND_CAVIUM_24575,
> >>>>+   MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
> >>>>+   },
> >>>>+#endif
> >>>> {
> >>>> }
> >>>>   };
> >>>>diff --git a/drivers/pci/host/pci-thunde

Re: [Linaro-acpi] [PATCH V6 12/13] pci, pci-thunder-ecam: Add ACPI support for ThunderX ECAM.

[G Gregory]

On 19 April 2016 at 11:26, Tomasz Nowicki  wrote:
> On 15.04.2016 19:06, Tomasz Nowicki wrote:
>>
>> Passes 1.x miss PCI enhanced allocation (EA) header for fixed-BARs,
>> thus these passes should use Cavium-specific config access functions
>> that synthesize the missing EA capabilities.
>>
>> We already have DT driver which addresses errata requirements and
>> allows to use special PCI config accessors. Currently this driver uses
>> compatible = "cavium,pci-host-thunder-ecam" to mach against the errata.
>> For ACPI case we need explicit errata number and corresponding
>> DECLARE_ACPI_MCFG_FIXUP fixup code.
>>
>> Signed-off-by: Tomasz Nowicki 
>> ---
>>   arch/arm64/Kconfig  | 14 ++
>>   arch/arm64/include/asm/cpufeature.h |  3 ++-
>>   arch/arm64/kernel/cpu_errata.c  |  8 
>>   drivers/pci/host/pci-thunder-ecam.c | 35
>> +++
>>   4 files changed, 59 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 1bded87..b7614b8 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -445,6 +445,20 @@ config CAVIUM_ERRATUM_27456
>>
>>   If unsure, say Y.
>>
>> +config CAVIUM_ERRATUM_24575
>> +   bool "Cavium erratum 24575: Enhanced Allocation (EA) emualaion"
>> +   default y
>> +   help
>> + Enable workaround for erratum 24575.
>> +
>> + Early versions of the Cavium Thunder CN88XX processor are
>> missing
>> + Enhanced Allocation (EA) capabilities for the fixed BAR
>> addresses used
>> + by the on-SoC hardware blocks. The erratum adds config access
>> + functions that synthesize the missing EA capabilities for
>> versions
>> + that are missing that information.
>> +
>> + If unsure, say Y.
>> +
>>   endmenu
>>
>>
>> diff --git a/arch/arm64/include/asm/cpufeature.h
>> b/arch/arm64/include/asm/cpufeature.h
>> index b9b6494..a78364e 100644
>> --- a/arch/arm64/include/asm/cpufeature.h
>> +++ b/arch/arm64/include/asm/cpufeature.h
>> @@ -35,8 +35,9 @@
>>   #define ARM64_ALT_PAN_NOT_UAO 10
>>   #define ARM64_HAS_VIRT_HOST_EXTN  11
>>   #define ARM64_WORKAROUND_CAVIUM_27456 12
>> +#define ARM64_WORKAROUND_CAVIUM_24575  13
>>
>> -#define ARM64_NCAPS13
>> +#define ARM64_NCAPS14
>>
>>   #ifndef __ASSEMBLY__
>>
>> diff --git a/arch/arm64/kernel/cpu_errata.c
>> b/arch/arm64/kernel/cpu_errata.c
>> index 06afd04..89c13d7 100644
>> --- a/arch/arm64/kernel/cpu_errata.c
>> +++ b/arch/arm64/kernel/cpu_errata.c
>> @@ -97,6 +97,14 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>>(1 << MIDR_VARIANT_SHIFT) | 1),
>> },
>>   #endif
>> +#ifdef CONFIG_CAVIUM_ERRATUM_24575
>> +   {
>> +   /* Cavium ThunderX, pass 1.x */
>> +   .desc = "Cavium erratum 24575",
>> +   .capability = ARM64_WORKAROUND_CAVIUM_24575,
>> +   MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
>> +   },
>> +#endif
>> {
>> }
>>   };
>> diff --git a/drivers/pci/host/pci-thunder-ecam.c
>> b/drivers/pci/host/pci-thunder-ecam.c
>> index f67c6d7..01de697 100644
>> --- a/drivers/pci/host/pci-thunder-ecam.c
>> +++ b/drivers/pci/host/pci-thunder-ecam.c
>> @@ -11,10 +11,14 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>
>> +#include 
>> +
>>   #include "../ecam.h"
>>
>> +
>>   static void set_val(u32 v, int where, int size, u32 *val)
>>   {
>> int shift = (where & 3) * 8;
>> @@ -376,5 +380,36 @@ static struct platform_driver thunder_ecam_driver = {
>>   };
>>   module_platform_driver(thunder_ecam_driver);
>>
>> +#ifdef CONFIG_ACPI
>> +
>> +static bool needs_cavium_erratum_24575(struct pci_cfg_fixup *fixup,
>> + struct acpi_pci_root *root)
>> +{
>> +   /*
>> +* We must match errata code and be hypervisor, quirk does not
>> apply
>> +* for virtual machines.
>> +*/
>> +   return cpus_have_cap(ARM64_WORKAROUND_CAVIUM_24575) &&
>> +  is_hyp_mode_available();
>> +}
>> +
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   0, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   1, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   2, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   3, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   10, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   11, 

Re: [Linaro-acpi] [PATCH V6 12/13] pci, pci-thunder-ecam: Add ACPI support for ThunderX ECAM.

[G Gregory]

On 19 April 2016 at 11:26, Tomasz Nowicki  wrote:
> On 15.04.2016 19:06, Tomasz Nowicki wrote:
>>
>> Passes 1.x miss PCI enhanced allocation (EA) header for fixed-BARs,
>> thus these passes should use Cavium-specific config access functions
>> that synthesize the missing EA capabilities.
>>
>> We already have DT driver which addresses errata requirements and
>> allows to use special PCI config accessors. Currently this driver uses
>> compatible = "cavium,pci-host-thunder-ecam" to mach against the errata.
>> For ACPI case we need explicit errata number and corresponding
>> DECLARE_ACPI_MCFG_FIXUP fixup code.
>>
>> Signed-off-by: Tomasz Nowicki 
>> ---
>>   arch/arm64/Kconfig  | 14 ++
>>   arch/arm64/include/asm/cpufeature.h |  3 ++-
>>   arch/arm64/kernel/cpu_errata.c  |  8 
>>   drivers/pci/host/pci-thunder-ecam.c | 35
>> +++
>>   4 files changed, 59 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 1bded87..b7614b8 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -445,6 +445,20 @@ config CAVIUM_ERRATUM_27456
>>
>>   If unsure, say Y.
>>
>> +config CAVIUM_ERRATUM_24575
>> +   bool "Cavium erratum 24575: Enhanced Allocation (EA) emualaion"
>> +   default y
>> +   help
>> + Enable workaround for erratum 24575.
>> +
>> + Early versions of the Cavium Thunder CN88XX processor are
>> missing
>> + Enhanced Allocation (EA) capabilities for the fixed BAR
>> addresses used
>> + by the on-SoC hardware blocks. The erratum adds config access
>> + functions that synthesize the missing EA capabilities for
>> versions
>> + that are missing that information.
>> +
>> + If unsure, say Y.
>> +
>>   endmenu
>>
>>
>> diff --git a/arch/arm64/include/asm/cpufeature.h
>> b/arch/arm64/include/asm/cpufeature.h
>> index b9b6494..a78364e 100644
>> --- a/arch/arm64/include/asm/cpufeature.h
>> +++ b/arch/arm64/include/asm/cpufeature.h
>> @@ -35,8 +35,9 @@
>>   #define ARM64_ALT_PAN_NOT_UAO 10
>>   #define ARM64_HAS_VIRT_HOST_EXTN  11
>>   #define ARM64_WORKAROUND_CAVIUM_27456 12
>> +#define ARM64_WORKAROUND_CAVIUM_24575  13
>>
>> -#define ARM64_NCAPS13
>> +#define ARM64_NCAPS14
>>
>>   #ifndef __ASSEMBLY__
>>
>> diff --git a/arch/arm64/kernel/cpu_errata.c
>> b/arch/arm64/kernel/cpu_errata.c
>> index 06afd04..89c13d7 100644
>> --- a/arch/arm64/kernel/cpu_errata.c
>> +++ b/arch/arm64/kernel/cpu_errata.c
>> @@ -97,6 +97,14 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>>(1 << MIDR_VARIANT_SHIFT) | 1),
>> },
>>   #endif
>> +#ifdef CONFIG_CAVIUM_ERRATUM_24575
>> +   {
>> +   /* Cavium ThunderX, pass 1.x */
>> +   .desc = "Cavium erratum 24575",
>> +   .capability = ARM64_WORKAROUND_CAVIUM_24575,
>> +   MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
>> +   },
>> +#endif
>> {
>> }
>>   };
>> diff --git a/drivers/pci/host/pci-thunder-ecam.c
>> b/drivers/pci/host/pci-thunder-ecam.c
>> index f67c6d7..01de697 100644
>> --- a/drivers/pci/host/pci-thunder-ecam.c
>> +++ b/drivers/pci/host/pci-thunder-ecam.c
>> @@ -11,10 +11,14 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>
>> +#include 
>> +
>>   #include "../ecam.h"
>>
>> +
>>   static void set_val(u32 v, int where, int size, u32 *val)
>>   {
>> int shift = (where & 3) * 8;
>> @@ -376,5 +380,36 @@ static struct platform_driver thunder_ecam_driver = {
>>   };
>>   module_platform_driver(thunder_ecam_driver);
>>
>> +#ifdef CONFIG_ACPI
>> +
>> +static bool needs_cavium_erratum_24575(struct pci_cfg_fixup *fixup,
>> + struct acpi_pci_root *root)
>> +{
>> +   /*
>> +* We must match errata code and be hypervisor, quirk does not
>> apply
>> +* for virtual machines.
>> +*/
>> +   return cpus_have_cap(ARM64_WORKAROUND_CAVIUM_24575) &&
>> +  is_hyp_mode_available();
>> +}
>> +
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   0, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   1, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   2, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   3, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   10, PCI_MCFG_BUS_ANY);
>> +DECLARE_ACPI_MCFG_FIXUP(NULL, needs_cavium_erratum_24575,
>> _thunder_ecam_ops,
>> +   11, PCI_MCFG_BUS_ANY);
>> 

Re: [PATCH v3] acpi, apei: add Boot Error Record Table (BERT) support

[G Gregory]

On 7 January 2016 at 16:21, Fu Wei  wrote:
> Hi Huang,
>
> On 7 January 2016 at 20:00, kbuild test robot  wrote:
>> Hi Huang,
>>
>> [auto build test WARNING on pm/linux-next]
>> [also build test WARNING on v4.4-rc8 next-20160106]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improving the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/fu-wei-linaro-org/acpi-apei-add-Boot-Error-Record-Table-BERT-support/20160107-193040
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
>> linux-next
>> config: x86_64-lkp (attached as .config)
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All warnings (new ones prefixed by >>):
>>
 drivers/acpi/apei/bert.c:31:14: warning: extra tokens at end of #undef 
 directive
>> #undef pr_fmt(fmt)
>>  ^
>>
>> vim +31 drivers/acpi/apei/bert.c
>>
>> 15   *
>> 16   * For more information about BERT, please refer to ACPI 
>> Specification
>> 17   * version 4.0, section 17.3.1
>> 18   *
>> 19   * This file is licensed under GPLv2.
>> 20   *
>> 21   */
>> 22
>> 23  #include 
>> 24  #include 
>> 25  #include 
>> 26  #include 
>> 27  #include 
>> 28
>> 29  #include "apei-internal.h"
>> 30
>>   > 31  #undef pr_fmt(fmt)
>
> Do you have any idea?
> I did not get warnings when I compiled this for arm64.
> But without it, I got "redefined" warning.
>
Shouldn't it be just

#undef pr_fmt

No arguments!

Graeme

>> 32  #define pr_fmt(fmt) "BERT: " fmt
>> 33
>> 34  static int bert_disable;
>> 35
>> 36  static void __init bert_print_all(struct acpi_bert_region *region,
>> 37unsigned int region_len)
>> 38  {
>> 39  /*
>>
>> ---
>> 0-DAY kernel test infrastructureOpen Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
> Ph: +86 21 61221326(direct)
> Ph: +86 186 2020 4684 (mobile)
> Room 1512, Regus One Corporate Avenue,Level 15,
> One Corporate Avenue,222 Hubin Road,Huangpu District,
> Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] acpi, apei: add Boot Error Record Table (BERT) support

[G Gregory]

On 7 January 2016 at 16:21, Fu Wei  wrote:
> Hi Huang,
>
> On 7 January 2016 at 20:00, kbuild test robot  wrote:
>> Hi Huang,
>>
>> [auto build test WARNING on pm/linux-next]
>> [also build test WARNING on v4.4-rc8 next-20160106]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improving the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/fu-wei-linaro-org/acpi-apei-add-Boot-Error-Record-Table-BERT-support/20160107-193040
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
>> linux-next
>> config: x86_64-lkp (attached as .config)
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All warnings (new ones prefixed by >>):
>>
 drivers/acpi/apei/bert.c:31:14: warning: extra tokens at end of #undef 
 directive
>> #undef pr_fmt(fmt)
>>  ^
>>
>> vim +31 drivers/acpi/apei/bert.c
>>
>> 15   *
>> 16   * For more information about BERT, please refer to ACPI 
>> Specification
>> 17   * version 4.0, section 17.3.1
>> 18   *
>> 19   * This file is licensed under GPLv2.
>> 20   *
>> 21   */
>> 22
>> 23  #include 
>> 24  #include 
>> 25  #include 
>> 26  #include 
>> 27  #include 
>> 28
>> 29  #include "apei-internal.h"
>> 30
>>   > 31  #undef pr_fmt(fmt)
>
> Do you have any idea?
> I did not get warnings when I compiled this for arm64.
> But without it, I got "redefined" warning.
>
Shouldn't it be just

#undef pr_fmt

No arguments!

Graeme

>> 32  #define pr_fmt(fmt) "BERT: " fmt
>> 33
>> 34  static int bert_disable;
>> 35
>> 36  static void __init bert_print_all(struct acpi_bert_region *region,
>> 37unsigned int region_len)
>> 38  {
>> 39  /*
>>
>> ---
>> 0-DAY kernel test infrastructureOpen Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
> Ph: +86 21 61221326(direct)
> Ph: +86 186 2020 4684 (mobile)
> Room 1512, Regus One Corporate Avenue,Level 15,
> One Corporate Avenue,222 Hubin Road,Huangpu District,
> Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[G Gregory]

On 4 January 2016 at 23:13, Timur Tabi  wrote:
> On Wed, Dec 23, 2015 at 8:19 AM, Aleksey Makarov
>  wrote:
>> From: Graeme Gregory 
>>
>> In ACPI this device is only defined in SBSA mode so
>> if we are coming from ACPI use this mode.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Aleksey Makarov 
>> ---
>>  drivers/tty/serial/amba-pl011.c | 37 ++---
>>  1 file changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/tty/serial/amba-pl011.c 
>> b/drivers/tty/serial/amba-pl011.c
>> index 899a771..974cb9e 100644
>> --- a/drivers/tty/serial/amba-pl011.c
>> +++ b/drivers/tty/serial/amba-pl011.c
>> @@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, 
>> const struct amba_id *id)
>> if (!uap)
>> return -ENOMEM;
>>
>> -   uap->clk = devm_clk_get(>dev, NULL);
>> -   if (IS_ERR(uap->clk))
>> -   return PTR_ERR(uap->clk);
>> -
>> -   uap->vendor = vendor;
>> -   uap->lcrh_rx = vendor->lcrh_rx;
>> -   uap->lcrh_tx = vendor->lcrh_tx;
>> -   uap->fifosize = vendor->get_fifosize(dev);
>> -   uap->port.irq = dev->irq[0];
>> -   uap->port.ops = _pl011_pops;
>> +   /* ACPI only defines SBSA variant */
>> +   if (has_acpi_companion(>dev)) {
>> +   /*
>> +* According to ARM ARMH0011 is currently the only mapping
>> +* of pl011 in ACPI and it's mapped to SBSA UART mode
>> +*/
>> +   uap->vendor = _sbsa;
>> +   uap->fifosize   = 32;
>> +   uap->port.ops   = _uart_pops;
>> +   uap->fixed_baud = 115200;
>
> I'm confused by this patch.  We already have code like this in
> tty-next, in the form of sbsa_uart_probe():
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/tty/+/tty-next/drivers/tty/serial/amba-pl011.c#2553
>
Because Russell expressed unhappiness at that code existing. So this
is an alternative method to do same thing with ACPI.

If the "arm,sbsa-uart" id was added to drivers/of/platform.c as an
AMBA id then the same could be done for DT as well.

Ultimately this patch is optional depending on maintainers opinion!

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[G Gregory]

On 4 January 2016 at 23:13, Timur Tabi  wrote:
> On Wed, Dec 23, 2015 at 8:19 AM, Aleksey Makarov
>  wrote:
>> From: Graeme Gregory 
>>
>> In ACPI this device is only defined in SBSA mode so
>> if we are coming from ACPI use this mode.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Aleksey Makarov 
>> ---
>>  drivers/tty/serial/amba-pl011.c | 37 ++---
>>  1 file changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/tty/serial/amba-pl011.c 
>> b/drivers/tty/serial/amba-pl011.c
>> index 899a771..974cb9e 100644
>> --- a/drivers/tty/serial/amba-pl011.c
>> +++ b/drivers/tty/serial/amba-pl011.c
>> @@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, 
>> const struct amba_id *id)
>> if (!uap)
>> return -ENOMEM;
>>
>> -   uap->clk = devm_clk_get(>dev, NULL);
>> -   if (IS_ERR(uap->clk))
>> -   return PTR_ERR(uap->clk);
>> -
>> -   uap->vendor = vendor;
>> -   uap->lcrh_rx = vendor->lcrh_rx;
>> -   uap->lcrh_tx = vendor->lcrh_tx;
>> -   uap->fifosize = vendor->get_fifosize(dev);
>> -   uap->port.irq = dev->irq[0];
>> -   uap->port.ops = _pl011_pops;
>> +   /* ACPI only defines SBSA variant */
>> +   if (has_acpi_companion(>dev)) {
>> +   /*
>> +* According to ARM ARMH0011 is currently the only mapping
>> +* of pl011 in ACPI and it's mapped to SBSA UART mode
>> +*/
>> +   uap->vendor = _sbsa;
>> +   uap->fifosize   = 32;
>> +   uap->port.ops   = _uart_pops;
>> +   uap->fixed_baud = 115200;
>
> I'm confused by this patch.  We already have code like this in
> tty-next, in the form of sbsa_uart_probe():
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/tty/+/tty-next/drivers/tty/serial/amba-pl011.c#2553
>
Because Russell expressed unhappiness at that code existing. So this
is an alternative method to do same thing with ACPI.

If the "arm,sbsa-uart" id was added to drivers/of/platform.c as an
AMBA id then the same could be done for DT as well.

Ultimately this patch is optional depending on maintainers opinion!

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] ACPI: amba bus probing support

[G Gregory]

On 21 December 2015 at 18:19, Andy Shevchenko  wrote:
> On Mon, Dec 21, 2015 at 6:41 PM, Aleksey Makarov
>  wrote:
>> From: Graeme Gregory 
>>
>> On ARM64 some devices use the AMBA device and not the platform bus for
>> probing so add support for this. Uses a dummy clock for apb_pclk as ACPI
>> does not have a suitable clock representation and to keep the core
>> AMBA bus code unchanged between probing methods.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Aleksey Makarov 
>> ---
>>  drivers/acpi/Makefile|   1 +
>>  drivers/acpi/acpi_amba.c | 149 
>> +++
>>  drivers/acpi/internal.h  |   5 ++
>>  3 files changed, 155 insertions(+)
>>  create mode 100644 drivers/acpi/acpi_amba.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 675eaf3..3cf732f 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -43,6 +43,7 @@ acpi-y+= pci_root.o 
>> pci_link.o pci_irq.o
>>  acpi-y += acpi_lpss.o acpi_apd.o
>>  acpi-y += acpi_platform.o
>>  acpi-y += acpi_pnp.o
>> +acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
>>  acpi-y += int340x_thermal.o
>>  acpi-y += power.o
>>  acpi-y += event.o
>> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
>> new file mode 100644
>> index 000..ebc8913
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_amba.c
>> @@ -0,0 +1,149 @@
>> +
>> +/*
>> + * ACPI support for platform bus type.
>> + *
>> + * Copyright (C) 2015, Linaro Ltd
>> + * Authors: Graeme Gregory 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "internal.h"
>> +
>> +static const struct acpi_device_id amba_id_list[] = {
>> +   {"ARMH0011", 0}, /* PL011 SBSA Uart */
>> +   {"ARMH0061", 0}, /* PL061 GPIO Device */
>> +   {"", 0},
>> +};
>> +
>> +static struct clk *amba_dummy_clk;
>> +
>> +static void amba_register_dummy_clk(void)
>> +{
>> +   struct clk *clk;
>> +
>> +   /* If clock already registered */
>> +   if (amba_dummy_clk)
>> +   return;
>> +
>> +   clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 
>> 0);
>> +   clk_register_clkdev(clk, "apb_pclk", NULL);
>> +
>> +   amba_dummy_clk = clk;
>> +}
>> +
>> +static int amba_handler_attach(struct acpi_device *adev,
>> +   const struct acpi_device_id *id)
>> +{
>> +   struct amba_device *dev = NULL;
>> +   struct acpi_device *acpi_parent;
>> +   struct resource_entry *rentry;
>> +   struct list_head resource_list;
>> +   struct resource *resources = NULL;
>> +   bool address_found = false;
>> +   int ret, count, irq_no = 0;
>> +
>> +   /* If the ACPI node already has a physical device attached, skip it. 
>> */
>> +   if (adev->physical_node_count)
>> +   return 0;
>> +
>> +   amba_register_dummy_clk();
>> +
>> +   dev = amba_device_alloc(NULL, 0, 0);
>> +   if (!dev) {
>> +   pr_err("%s(): amba_device_alloc() failed for %s\n",
>
> Can it be dev_err(>dev, …); ?
> Same for below cases.
>
Yes it probably can, I took the code directly from DT version and
didn't think of using adev->dev directly.

Graeme

>> +  __func__, dev_name(>dev));
>> +   return 0;
>> +   }
>> +
>> +   INIT_LIST_HEAD(_list);
>
>> +   count = acpi_dev_get_resources(adev, _list, NULL, NULL);
>> +   if (count < 0) {
>> +   return 0;
>> +   } else if (count > 0) {
>> +   resources = kmalloc_array(count, sizeof(struct resource),
>> +   GFP_KERNEL);
>> +   if (!resources) {
>> +   acpi_dev_free_resource_list(_list);
>> +   return 0;
>> +   }
>> +   count = 0;
>> +   list_for_each_entry(rentry, _list, node) {
>> +   switch (resource_type(rentry->res)) {
>> +   case IORESOURCE_MEM:
>> +   if (!address_found) {
>> +   dev->res = *rentry->res;
>> +   address_found = true;
>> +   }
>> +   break;
>> +   case IORESOURCE_IRQ:
>> +   if (irq_no < AMBA_NR_IRQS)
>> +   dev->irq[irq_no++] = 
>> rentry->res->start;
>> +   break;
>> +   default:
>> +

Re: [PATCH v2 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[G Gregory]

On 21 December 2015 at 18:11, Andy Shevchenko  wrote:
> On Mon, Dec 21, 2015 at 4:49 PM, Aleksey Makarov
>  wrote:
>> From: Graeme Gregory 
>>
>> In ACPI this device is only defined in SBSA mode so
>> if we are coming from ACPI use this mode.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Aleksey Makarov 
>> ---
>>  drivers/tty/serial/amba-pl011.c | 37 ++---
>>  1 file changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/tty/serial/amba-pl011.c 
>> b/drivers/tty/serial/amba-pl011.c
>> index 899a771..766ce4f 100644
>> --- a/drivers/tty/serial/amba-pl011.c
>> +++ b/drivers/tty/serial/amba-pl011.c
>> @@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, 
>> const struct amba_id *id)
>> if (!uap)
>> return -ENOMEM;
>>
>> -   uap->clk = devm_clk_get(>dev, NULL);
>> -   if (IS_ERR(uap->clk))
>> -   return PTR_ERR(uap->clk);
>> -
>> -   uap->vendor = vendor;
>> -   uap->lcrh_rx = vendor->lcrh_rx;
>> -   uap->lcrh_tx = vendor->lcrh_tx;
>> -   uap->fifosize = vendor->get_fifosize(dev);
>> -   uap->port.irq = dev->irq[0];
>> -   uap->port.ops = _pl011_pops;
>> +   /* ACPI only defines SBSA variant */
>> +   if (ACPI_COMPANION(>dev)) {
>
> has_acpi_companion()
>
>> +   /*
>> +* According to ARM ARMH0011 is currently the only mapping
>> +* of pl011 in ACPI and it's mapped to SBSA UART mode
>> +*/
>> +   uap->vendor = _sbsa;
>> +   uap->fifosize   = 32;
>> +   uap->port.ops   = _uart_pops;
>> +   uap->fixed_baud = 115200;
>
> Shouldn't you match by ID and provide the custom values if any?
> On the other hand have you checked if it's possible to use _DSD in this case?
>
So far I have not seen any use of SBSA UART other than this in real
life. I am a little opposed to providing complexity people are not
going to use.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[G Gregory]

On 21 December 2015 at 18:11, Andy Shevchenko  wrote:
> On Mon, Dec 21, 2015 at 4:49 PM, Aleksey Makarov
>  wrote:
>> From: Graeme Gregory 
>>
>> In ACPI this device is only defined in SBSA mode so
>> if we are coming from ACPI use this mode.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Aleksey Makarov 
>> ---
>>  drivers/tty/serial/amba-pl011.c | 37 ++---
>>  1 file changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/tty/serial/amba-pl011.c 
>> b/drivers/tty/serial/amba-pl011.c
>> index 899a771..766ce4f 100644
>> --- a/drivers/tty/serial/amba-pl011.c
>> +++ b/drivers/tty/serial/amba-pl011.c
>> @@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, 
>> const struct amba_id *id)
>> if (!uap)
>> return -ENOMEM;
>>
>> -   uap->clk = devm_clk_get(>dev, NULL);
>> -   if (IS_ERR(uap->clk))
>> -   return PTR_ERR(uap->clk);
>> -
>> -   uap->vendor = vendor;
>> -   uap->lcrh_rx = vendor->lcrh_rx;
>> -   uap->lcrh_tx = vendor->lcrh_tx;
>> -   uap->fifosize = vendor->get_fifosize(dev);
>> -   uap->port.irq = dev->irq[0];
>> -   uap->port.ops = _pl011_pops;
>> +   /* ACPI only defines SBSA variant */
>> +   if (ACPI_COMPANION(>dev)) {
>
> has_acpi_companion()
>
>> +   /*
>> +* According to ARM ARMH0011 is currently the only mapping
>> +* of pl011 in ACPI and it's mapped to SBSA UART mode
>> +*/
>> +   uap->vendor = _sbsa;
>> +   uap->fifosize   = 32;
>> +   uap->port.ops   = _uart_pops;
>> +   uap->fixed_baud = 115200;
>
> Shouldn't you match by ID and provide the custom values if any?
> On the other hand have you checked if it's possible to use _DSD in this case?
>
So far I have not seen any use of SBSA UART other than this in real
life. I am a little opposed to providing complexity people are not
going to use.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] ACPI: amba bus probing support

[G Gregory]

On 21 December 2015 at 18:19, Andy Shevchenko  wrote:
> On Mon, Dec 21, 2015 at 6:41 PM, Aleksey Makarov
>  wrote:
>> From: Graeme Gregory 
>>
>> On ARM64 some devices use the AMBA device and not the platform bus for
>> probing so add support for this. Uses a dummy clock for apb_pclk as ACPI
>> does not have a suitable clock representation and to keep the core
>> AMBA bus code unchanged between probing methods.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Aleksey Makarov 
>> ---
>>  drivers/acpi/Makefile|   1 +
>>  drivers/acpi/acpi_amba.c | 149 
>> +++
>>  drivers/acpi/internal.h  |   5 ++
>>  3 files changed, 155 insertions(+)
>>  create mode 100644 drivers/acpi/acpi_amba.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 675eaf3..3cf732f 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -43,6 +43,7 @@ acpi-y+= pci_root.o 
>> pci_link.o pci_irq.o
>>  acpi-y += acpi_lpss.o acpi_apd.o
>>  acpi-y += acpi_platform.o
>>  acpi-y += acpi_pnp.o
>> +acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
>>  acpi-y += int340x_thermal.o
>>  acpi-y += power.o
>>  acpi-y += event.o
>> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
>> new file mode 100644
>> index 000..ebc8913
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_amba.c
>> @@ -0,0 +1,149 @@
>> +
>> +/*
>> + * ACPI support for platform bus type.
>> + *
>> + * Copyright (C) 2015, Linaro Ltd
>> + * Authors: Graeme Gregory 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "internal.h"
>> +
>> +static const struct acpi_device_id amba_id_list[] = {
>> +   {"ARMH0011", 0}, /* PL011 SBSA Uart */
>> +   {"ARMH0061", 0}, /* PL061 GPIO Device */
>> +   {"", 0},
>> +};
>> +
>> +static struct clk *amba_dummy_clk;
>> +
>> +static void amba_register_dummy_clk(void)
>> +{
>> +   struct clk *clk;
>> +
>> +   /* If clock already registered */
>> +   if (amba_dummy_clk)
>> +   return;
>> +
>> +   clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 
>> 0);
>> +   clk_register_clkdev(clk, "apb_pclk", NULL);
>> +
>> +   amba_dummy_clk = clk;
>> +}
>> +
>> +static int amba_handler_attach(struct acpi_device *adev,
>> +   const struct acpi_device_id *id)
>> +{
>> +   struct amba_device *dev = NULL;
>> +   struct acpi_device *acpi_parent;
>> +   struct resource_entry *rentry;
>> +   struct list_head resource_list;
>> +   struct resource *resources = NULL;
>> +   bool address_found = false;
>> +   int ret, count, irq_no = 0;
>> +
>> +   /* If the ACPI node already has a physical device attached, skip it. 
>> */
>> +   if (adev->physical_node_count)
>> +   return 0;
>> +
>> +   amba_register_dummy_clk();
>> +
>> +   dev = amba_device_alloc(NULL, 0, 0);
>> +   if (!dev) {
>> +   pr_err("%s(): amba_device_alloc() failed for %s\n",
>
> Can it be dev_err(>dev, …); ?
> Same for below cases.
>
Yes it probably can, I took the code directly from DT version and
didn't think of using adev->dev directly.

Graeme

>> +  __func__, dev_name(>dev));
>> +   return 0;
>> +   }
>> +
>> +   INIT_LIST_HEAD(_list);
>
>> +   count = acpi_dev_get_resources(adev, _list, NULL, NULL);
>> +   if (count < 0) {
>> +   return 0;
>> +   } else if (count > 0) {
>> +   resources = kmalloc_array(count, sizeof(struct resource),
>> +   GFP_KERNEL);
>> +   if (!resources) {
>> +   acpi_dev_free_resource_list(_list);
>> +   return 0;
>> +   }
>> +   count = 0;
>> +   list_for_each_entry(rentry, _list, node) {
>> +   switch (resource_type(rentry->res)) {
>> +   case IORESOURCE_MEM:
>> +   if (!address_found) {
>> +   dev->res = *rentry->res;
>> +   address_found = true;
>> +   }
>> +   break;
>> +   case IORESOURCE_IRQ:
>> +   if (irq_no < AMBA_NR_IRQS)
>> +  

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

[G Gregory]

On 4 December 2015 at 10:20, Huang Rui  wrote:
> On Fri, Dec 04, 2015 at 09:59:28AM +0000, G Gregory wrote:
>> On 4 December 2015 at 09:42, Hanjun Guo  wrote:
>> > On 2015/12/4 17:17, Huang Rui wrote:
>> >> On Fri, Dec 04, 2015 at 10:50:23AM +0200, Mika Westerberg wrote:
>> >>> On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang Hongcheng wrote:
>> >>>> From: Huang Rui 
>> >>>>
>> >>>> Inspired by acpi platform bus type, to make driver "porting" more
>> >>>> straightforward, this patch introduces ACPI support to the AMBA bus
>> >>>> type. Instead of writing ACPI "glue" drivers for the exiting AMBA
>> >>>> drivers.
>> >>> Hmm, isn't there already similar patch series bringing AMBA ACPI
>> >>> support?
>> >>>
>> >>> https://lkml.org/lkml/2015/9/30/394
>> >> Err, I see the patch for the first time...
>> >>
>> >> But looks like it isn't accepted till now. Will he continue to work on
>> >> it?
>> >
>> > Sure, Graeme is working on the updated version now :)
>> >
>> Yes, as Hanjun said I am planning a v2. I've just been caught up in
>> other business this week and probably next week.
>>
>
> OK, thanks to clarify it. Could you please take care of AMD use case
> that we need a configurable fix_rate clk, periphid, and platform data?
>
I will take a look at your patch in detail when I redo my series.

Thanks

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

[G Gregory]

On 4 December 2015 at 09:42, Hanjun Guo  wrote:
> On 2015/12/4 17:17, Huang Rui wrote:
>> On Fri, Dec 04, 2015 at 10:50:23AM +0200, Mika Westerberg wrote:
>>> On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang Hongcheng wrote:
 From: Huang Rui 

 Inspired by acpi platform bus type, to make driver "porting" more
 straightforward, this patch introduces ACPI support to the AMBA bus
 type. Instead of writing ACPI "glue" drivers for the exiting AMBA
 drivers.
>>> Hmm, isn't there already similar patch series bringing AMBA ACPI
>>> support?
>>>
>>> https://lkml.org/lkml/2015/9/30/394
>> Err, I see the patch for the first time...
>>
>> But looks like it isn't accepted till now. Will he continue to work on
>> it?
>
> Sure, Graeme is working on the updated version now :)
>
Yes, as Hanjun said I am planning a v2. I've just been caught up in
other business this week and probably next week.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

[G Gregory]

On 4 December 2015 at 09:42, Hanjun Guo  wrote:
> On 2015/12/4 17:17, Huang Rui wrote:
>> On Fri, Dec 04, 2015 at 10:50:23AM +0200, Mika Westerberg wrote:
>>> On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang Hongcheng wrote:
 From: Huang Rui 

 Inspired by acpi platform bus type, to make driver "porting" more
 straightforward, this patch introduces ACPI support to the AMBA bus
 type. Instead of writing ACPI "glue" drivers for the exiting AMBA
 drivers.
>>> Hmm, isn't there already similar patch series bringing AMBA ACPI
>>> support?
>>>
>>> https://lkml.org/lkml/2015/9/30/394
>> Err, I see the patch for the first time...
>>
>> But looks like it isn't accepted till now. Will he continue to work on
>> it?
>
> Sure, Graeme is working on the updated version now :)
>
Yes, as Hanjun said I am planning a v2. I've just been caught up in
other business this week and probably next week.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

[G Gregory]

On 4 December 2015 at 10:20, Huang Rui <ray.hu...@amd.com> wrote:
> On Fri, Dec 04, 2015 at 09:59:28AM +, G Gregory wrote:
>> On 4 December 2015 at 09:42, Hanjun Guo <guohan...@huawei.com> wrote:
>> > On 2015/12/4 17:17, Huang Rui wrote:
>> >> On Fri, Dec 04, 2015 at 10:50:23AM +0200, Mika Westerberg wrote:
>> >>> On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang Hongcheng wrote:
>> >>>> From: Huang Rui <ray.hu...@amd.com>
>> >>>>
>> >>>> Inspired by acpi platform bus type, to make driver "porting" more
>> >>>> straightforward, this patch introduces ACPI support to the AMBA bus
>> >>>> type. Instead of writing ACPI "glue" drivers for the exiting AMBA
>> >>>> drivers.
>> >>> Hmm, isn't there already similar patch series bringing AMBA ACPI
>> >>> support?
>> >>>
>> >>> https://lkml.org/lkml/2015/9/30/394
>> >> Err, I see the patch for the first time...
>> >>
>> >> But looks like it isn't accepted till now. Will he continue to work on
>> >> it?
>> >
>> > Sure, Graeme is working on the updated version now :)
>> >
>> Yes, as Hanjun said I am planning a v2. I've just been caught up in
>> other business this week and probably next week.
>>
>
> OK, thanks to clarify it. Could you please take care of AMD use case
> that we need a configurable fix_rate clk, periphid, and platform data?
>
I will take a look at your patch in detail when I redo my series.

Thanks

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 0/5] console/acpi: add DBG2 and SPCR console configuration

[G Gregory]

On Wed, Sep 23, 2015 at 03:38:20PM +0800, Ming Lei wrote:
> Hi Leif,
> 
> 
> On Tue, Sep 8, 2015 at 8:43 PM, Leif Lindholm  
> wrote:
> > Support for configuring bootconsole and console via the ACPI tables
> > DBG2 (Debug Port Table 2) [1] and SPCR (Serial Port Console Redirection
> > Table) [2], defined by Microsoft, has been discussed on and off over the
> > years.
> >
> > [1] 
> > https://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
> > [2] 
> > https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
> >
> > Licensing concerns have prevented this happening in the past, but as of
> > 10 August 2015, these tables have both been released also under OWF 1.0
> > (http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0)
> > which is think is noncontroversially GPL-compatible?
> >
> > This set is a first attempt at implementing this.
> 
> From distribution view, the patchset looks very useful.
> 
> I have one simple question, are there other candidates for conveying this kind
> of information like what DBG2/SPCR does? Or are DBG2 and SPCR the
> offical speficiations to do such things in ARM server industry?
> 

They are mandated in the SBBR spec

Graeme


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 0/5] console/acpi: add DBG2 and SPCR console configuration

[G Gregory]

On Wed, Sep 23, 2015 at 03:38:20PM +0800, Ming Lei wrote:
> Hi Leif,
> 
> 
> On Tue, Sep 8, 2015 at 8:43 PM, Leif Lindholm  
> wrote:
> > Support for configuring bootconsole and console via the ACPI tables
> > DBG2 (Debug Port Table 2) [1] and SPCR (Serial Port Console Redirection
> > Table) [2], defined by Microsoft, has been discussed on and off over the
> > years.
> >
> > [1] 
> > https://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
> > [2] 
> > https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
> >
> > Licensing concerns have prevented this happening in the past, but as of
> > 10 August 2015, these tables have both been released also under OWF 1.0
> > (http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0)
> > which is think is noncontroversially GPL-compatible?
> >
> > This set is a first attempt at implementing this.
> 
> From distribution view, the patchset looks very useful.
> 
> I have one simple question, are there other candidates for conveying this kind
> of information like what DBG2/SPCR does? Or are DBG2 and SPCR the
> offical speficiations to do such things in ARM server industry?
> 

They are mandated in the SBBR spec

Graeme


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v4 00/10] ACPI GIC Self-probing, GICv2m and GICv3 support

[G Gregory]

On 11 August 2015 at 23:01, Timur Tabi  wrote:
> On 07/29/2015 05:08 AM, Hanjun Guo wrote:
>>
>> Patches are on top of Marc's branch irq/gsi-irq-domain-v2, and available
>> at:
>>
>> git://git.linaro.org/leg/acpi/acpi.git gsi-irqdomain
>
>
> Is it my imagination, or is Marc's branch based on v3.9-rc7?
>
Looks like 4.2-rc2 to me.

> Also, shouldn't this code be based on the upstream kernel, and not the LEG
> kernel?
>
Nothing LEG kernelly in there.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v4 00/10] ACPI GIC Self-probing, GICv2m and GICv3 support

[G Gregory]

On 11 August 2015 at 23:01, Timur Tabi ti...@codeaurora.org wrote:
 On 07/29/2015 05:08 AM, Hanjun Guo wrote:

 Patches are on top of Marc's branch irq/gsi-irq-domain-v2, and available
 at:

 git://git.linaro.org/leg/acpi/acpi.git gsi-irqdomain


 Is it my imagination, or is Marc's branch based on v3.9-rc7?

Looks like 4.2-rc2 to me.

 Also, shouldn't this code be based on the upstream kernel, and not the LEG
 kernel?

Nothing LEG kernelly in there.

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio

[G Gregory]

On 30 July 2015 at 10:37, G Gregory  wrote:
> On 30 July 2015 at 10:24, Peter Maydell  wrote:
>> On 30 July 2015 at 09:04, Michael S. Tsirkin  wrote:
>>> On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote:
>>>>
>>>> Why do we drop the previous way using "QEMU"? Something I missed?
>>>
>>> So that guests that bind to this interface will work fine with non QEMU
>>> implementations of virtio-mmio.
>>
>> I don't understand this sentence. If there are pre-existing
>> non-QEMU virtio-mmio implementations, then they're using
>> LNRO0005, and we should use it too.
>
> The only one I have come across is the ARM FVP model, and it happens
> that I chose the ID and maintain the tables for that so I can change
> it.
>
In fact, I would just add

Name (_HID, "QEMU")
Name (_HID, "1AF4103F")

To the tables so tables work with old (internal) kernels and new!

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio

[G Gregory]

On 30 July 2015 at 10:24, Peter Maydell  wrote:
> On 30 July 2015 at 09:04, Michael S. Tsirkin  wrote:
>> On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote:
>>>
>>> Why do we drop the previous way using "QEMU"? Something I missed?
>>
>> So that guests that bind to this interface will work fine with non QEMU
>> implementations of virtio-mmio.
>
> I don't understand this sentence. If there are pre-existing
> non-QEMU virtio-mmio implementations, then they're using
> LNRO0005, and we should use it too.

The only one I have come across is the ARM FVP model, and it happens
that I chose the ID and maintain the tables for that so I can change
it.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio

[G Gregory]

On 30 July 2015 at 10:37, G Gregory graeme.greg...@linaro.org wrote:
 On 30 July 2015 at 10:24, Peter Maydell peter.mayd...@linaro.org wrote:
 On 30 July 2015 at 09:04, Michael S. Tsirkin m...@redhat.com wrote:
 On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote:

 Why do we drop the previous way using QEMU? Something I missed?

 So that guests that bind to this interface will work fine with non QEMU
 implementations of virtio-mmio.

 I don't understand this sentence. If there are pre-existing
 non-QEMU virtio-mmio implementations, then they're using
 LNRO0005, and we should use it too.

 The only one I have come across is the ARM FVP model, and it happens
 that I chose the ID and maintain the tables for that so I can change
 it.

In fact, I would just add

Name (_HID, QEMU)
Name (_HID, 1AF4103F)

To the tables so tables work with old (internal) kernels and new!

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio

[G Gregory]

On 30 July 2015 at 10:24, Peter Maydell peter.mayd...@linaro.org wrote:
 On 30 July 2015 at 09:04, Michael S. Tsirkin m...@redhat.com wrote:
 On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote:

 Why do we drop the previous way using QEMU? Something I missed?

 So that guests that bind to this interface will work fine with non QEMU
 implementations of virtio-mmio.

 I don't understand this sentence. If there are pre-existing
 non-QEMU virtio-mmio implementations, then they're using
 LNRO0005, and we should use it too.

The only one I have come across is the ARM FVP model, and it happens
that I chose the ID and maintain the tables for that so I can change
it.

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] virtio_mmio: add ACPI probing

[G Gregory]

On 28 July 2015 at 21:12, Peter Maydell  wrote:
> On 28 July 2015 at 11:27, Michael S. Tsirkin  wrote:
>> On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote:
>>> On 28 July 2015 at 11:08, Michael S. Tsirkin  wrote:
>>> > On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
>>> >> Added the match table and pointers for ACPI probing to the driver.
>>> >>
>>> >> This uses the same identifier for virt devices as being used for qemu
>>> >> ARM64 ACPI support.
>>> >>
>>> >> http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e
>>> >>
>>> >> Signed-off-by: Graeme Gregory 
>
>>> >> +#ifdef CONFIG_ACPI
>>> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>>> >> + { "LNRO0005", },
>>> >> + { }
>>> >> +};
>>> >
>>> > Hmm - we have reserved QEMU in ASWG explicitly for this purpose.
>>> >
>>> > Pater - do you think it's a good idea to change this before QEMU 2.4
>>> > is released?
>>>
>>> Shannon's call, I guess. I don't know enough about ACPI to say.
>>> I thought these ACPI IDs were already fixed because they were
>>> what the kernel was looking for...
>
>> Apparently not :)
>
> Mmm. I'm not terribly happy about stuff being in QEMU before the
> ACPI spec for it has been finalised. We should not be picking
> stuff randomly on the fly...
>
> If we want to fix the ACPI IDs QEMU is using for 2.4 then we
> really need to do that now (ie within the next day or two).
>
It is upto the owner of the QEMU prefix to allocate numbers. This is
not an issue for ACPI spec at all.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] virtio_mmio: add ACPI probing

[G Gregory]

On 28 July 2015 at 11:27, Michael S. Tsirkin  wrote:
> On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote:
>> On 28 July 2015 at 11:08, Michael S. Tsirkin  wrote:
>> > On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
>> >> Added the match table and pointers for ACPI probing to the driver.
>> >>
>> >> This uses the same identifier for virt devices as being used for qemu
>> >> ARM64 ACPI support.
>> >>
>> >> http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e
>> >>
>> >> Signed-off-by: Graeme Gregory 
>> >> ---
>> >>  drivers/virtio/virtio_mmio.c | 10 ++
>> >>  1 file changed, 10 insertions(+)
>> >>
>> >> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
>> >> index 10189b5..f499d9d 100644
>> >> --- a/drivers/virtio/virtio_mmio.c
>> >> +++ b/drivers/virtio/virtio_mmio.c
>> >> @@ -58,6 +58,7 @@
>> >>
>> >>  #define pr_fmt(fmt) "virtio-mmio: " fmt
>> >>
>> >> +#include 
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> @@ -732,12 +733,21 @@ static struct of_device_id virtio_mmio_match[] = {
>> >>  };
>> >>  MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>> >>
>> >> +#ifdef CONFIG_ACPI
>> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>> >> + { "LNRO0005", },
>> >> + { }
>> >> +};
>> >
>> > Hmm - we have reserved QEMU in ASWG explicitly for this purpose.
>> >
>> > Pater - do you think it's a good idea to change this before QEMU 2.4
>> > is released?
>>
>> Shannon's call, I guess. I don't know enough about ACPI to say.
>> I thought these ACPI IDs were already fixed because they were
>> what the kernel was looking for...
>>
>> -- PMM
>
> Apparently not :)
>
We assigned LNRO in ASWG to avoid collisions with our prototypes/real
platforms so it makes sense to me to switch to QEMU.

I will submit a new patch if Shannon wants to switch to that form.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] virtio_mmio: add ACPI probing

[G Gregory]

On 28 July 2015 at 11:27, Michael S. Tsirkin m...@redhat.com wrote:
 On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote:
 On 28 July 2015 at 11:08, Michael S. Tsirkin m...@redhat.com wrote:
  On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
  Added the match table and pointers for ACPI probing to the driver.
 
  This uses the same identifier for virt devices as being used for qemu
  ARM64 ACPI support.
 
  http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e
 
  Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
  ---
   drivers/virtio/virtio_mmio.c | 10 ++
   1 file changed, 10 insertions(+)
 
  diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
  index 10189b5..f499d9d 100644
  --- a/drivers/virtio/virtio_mmio.c
  +++ b/drivers/virtio/virtio_mmio.c
  @@ -58,6 +58,7 @@
 
   #define pr_fmt(fmt) virtio-mmio:  fmt
 
  +#include linux/acpi.h
   #include linux/highmem.h
   #include linux/interrupt.h
   #include linux/io.h
  @@ -732,12 +733,21 @@ static struct of_device_id virtio_mmio_match[] = {
   };
   MODULE_DEVICE_TABLE(of, virtio_mmio_match);
 
  +#ifdef CONFIG_ACPI
  +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
  + { LNRO0005, },
  + { }
  +};
 
  Hmm - we have reserved QEMU in ASWG explicitly for this purpose.
 
  Pater - do you think it's a good idea to change this before QEMU 2.4
  is released?

 Shannon's call, I guess. I don't know enough about ACPI to say.
 I thought these ACPI IDs were already fixed because they were
 what the kernel was looking for...

 -- PMM

 Apparently not :)

We assigned LNRO in ASWG to avoid collisions with our prototypes/real
platforms so it makes sense to me to switch to QEMU.

I will submit a new patch if Shannon wants to switch to that form.

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] virtio_mmio: add ACPI probing

[G Gregory]

On 28 July 2015 at 21:12, Peter Maydell peter.mayd...@linaro.org wrote:
 On 28 July 2015 at 11:27, Michael S. Tsirkin m...@redhat.com wrote:
 On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote:
 On 28 July 2015 at 11:08, Michael S. Tsirkin m...@redhat.com wrote:
  On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
  Added the match table and pointers for ACPI probing to the driver.
 
  This uses the same identifier for virt devices as being used for qemu
  ARM64 ACPI support.
 
  http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e
 
  Signed-off-by: Graeme Gregory graeme.greg...@linaro.org

  +#ifdef CONFIG_ACPI
  +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
  + { LNRO0005, },
  + { }
  +};
 
  Hmm - we have reserved QEMU in ASWG explicitly for this purpose.
 
  Pater - do you think it's a good idea to change this before QEMU 2.4
  is released?

 Shannon's call, I guess. I don't know enough about ACPI to say.
 I thought these ACPI IDs were already fixed because they were
 what the kernel was looking for...

 Apparently not :)

 Mmm. I'm not terribly happy about stuff being in QEMU before the
 ACPI spec for it has been finalised. We should not be picking
 stuff randomly on the fly...

 If we want to fix the ACPI IDs QEMU is using for 2.4 then we
 really need to do that now (ie within the next day or two).

It is upto the owner of the QEMU prefix to allocate numbers. This is
not an issue for ACPI spec at all.

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 07/21] ACPI / sleep: Introduce arm64 specific acpi_sleep.c

[G Gregory]

On 4 March 2015 at 22:38, Rafael J. Wysocki  wrote:
> On Wednesday, February 25, 2015 04:39:47 PM Hanjun Guo wrote:
>> From: Graeme Gregory 
>>
>> ACPI 5.1 does not currently support S states for ARM64 hardware but
>> ACPI code will call acpi_target_system_state() for device power
>> management, so introduce acpi_sleep.c to allow other drivers to function
>> until S states are defined.
>>
>> Since it is arm64 specific stub holder, so let acpi_sleep.c to ARM64
>> specific.
>>
>> TODO: merge this with drivers/acpi/sleep.c once we fix the specification.
>>
>> CC: Rafael J. Wysocki 
>> Tested-by: Suravee Suthikulpanit 
>> Tested-by: Yijing Wang 
>> Tested-by: Mark Langsdorf 
>> Tested-by: Jon Masters 
>> Tested-by: Timur Tabi 
>> Tested-by: Robert Richter 
>> Acked-by: Robert Richter 
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Tomasz Nowicki 
>> Signed-off-by: Hanjun Guo 
>> ---
>>  arch/arm64/kernel/Makefile |  2 +-
>>  arch/arm64/kernel/acpi_sleep.c | 28 
>>  drivers/acpi/Makefile  |  2 ++
>>  3 files changed, 31 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm64/kernel/acpi_sleep.c
>>
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 218eb7e..4435943 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -34,7 +34,7 @@ arm64-obj-$(CONFIG_KGDB)+= kgdb.o
>>  arm64-obj-$(CONFIG_EFI)  += efi.o efi-stub.o efi-entry.o
>>  arm64-obj-$(CONFIG_PCI)  += pci.o
>>  arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
>> -arm64-obj-$(CONFIG_ACPI) += acpi.o
>> +arm64-obj-$(CONFIG_ACPI) += acpi.o acpi_sleep.o
>>
>>  obj-y+= $(arm64-obj-y) vdso/
>>  obj-m+= $(arm64-obj-m)
>> diff --git a/arch/arm64/kernel/acpi_sleep.c b/arch/arm64/kernel/acpi_sleep.c
>> new file mode 100644
>> index 000..54578ef
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi_sleep.c
>> @@ -0,0 +1,28 @@
>> +/*
>> + *  ARM64 Specific Sleep Functionality
>> + *
>> + *  Copyright (C) 2013-2014, Linaro Ltd.
>> + *  Author: Graeme Gregory 
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +
>> +/*
>> + * Currently the ACPI 5.1 standard does not define S states in a
>> + * manner which is usable for ARM64. These two stubs are sufficient
>> + * that system initialises and device PM works.
>> + */
>> +u32 acpi_target_system_state(void)
>> +{
>> + return ACPI_STATE_S0;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_target_system_state);
>> +
>> +int __init acpi_sleep_init(void)
>> +{
>> + return -ENOSYS;
>> +}
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 623b117..c32edf5 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -23,7 +23,9 @@ acpi-y  += nvs.o
>>
>>  # Power management related files
>>  acpi-y   += wakeup.o
>> +ifneq (,$(findstring $(ARCH),x86 ia64))
>
> This is super-ugly.  Isn't there a better way to do that?
>
Its the standard example in the GNU Make manual, I would certainly
love if someone had a batter suggestion.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 07/21] ACPI / sleep: Introduce arm64 specific acpi_sleep.c

[G Gregory]

On 4 March 2015 at 22:38, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Wednesday, February 25, 2015 04:39:47 PM Hanjun Guo wrote:
 From: Graeme Gregory graeme.greg...@linaro.org

 ACPI 5.1 does not currently support S states for ARM64 hardware but
 ACPI code will call acpi_target_system_state() for device power
 management, so introduce acpi_sleep.c to allow other drivers to function
 until S states are defined.

 Since it is arm64 specific stub holder, so let acpi_sleep.c to ARM64
 specific.

 TODO: merge this with drivers/acpi/sleep.c once we fix the specification.

 CC: Rafael J. Wysocki r...@rjwysocki.net
 Tested-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
 Tested-by: Yijing Wang wangyij...@huawei.com
 Tested-by: Mark Langsdorf mlang...@redhat.com
 Tested-by: Jon Masters j...@redhat.com
 Tested-by: Timur Tabi ti...@codeaurora.org
 Tested-by: Robert Richter rrich...@cavium.com
 Acked-by: Robert Richter rrich...@cavium.com
 Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
 Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
 Signed-off-by: Hanjun Guo hanjun@linaro.org
 ---
  arch/arm64/kernel/Makefile |  2 +-
  arch/arm64/kernel/acpi_sleep.c | 28 
  drivers/acpi/Makefile  |  2 ++
  3 files changed, 31 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm64/kernel/acpi_sleep.c

 diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
 index 218eb7e..4435943 100644
 --- a/arch/arm64/kernel/Makefile
 +++ b/arch/arm64/kernel/Makefile
 @@ -34,7 +34,7 @@ arm64-obj-$(CONFIG_KGDB)+= kgdb.o
  arm64-obj-$(CONFIG_EFI)  += efi.o efi-stub.o efi-entry.o
  arm64-obj-$(CONFIG_PCI)  += pci.o
  arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
 -arm64-obj-$(CONFIG_ACPI) += acpi.o
 +arm64-obj-$(CONFIG_ACPI) += acpi.o acpi_sleep.o

  obj-y+= $(arm64-obj-y) vdso/
  obj-m+= $(arm64-obj-m)
 diff --git a/arch/arm64/kernel/acpi_sleep.c b/arch/arm64/kernel/acpi_sleep.c
 new file mode 100644
 index 000..54578ef
 --- /dev/null
 +++ b/arch/arm64/kernel/acpi_sleep.c
 @@ -0,0 +1,28 @@
 +/*
 + *  ARM64 Specific Sleep Functionality
 + *
 + *  Copyright (C) 2013-2014, Linaro Ltd.
 + *  Author: Graeme Gregory graeme.greg...@linaro.org
 + *
 + *  This program is free software; you can redistribute it and/or modify
 + *  it under the terms of the GNU General Public License version 2 as
 + *  published by the Free Software Foundation.
 + */
 +
 +#include linux/acpi.h
 +
 +/*
 + * Currently the ACPI 5.1 standard does not define S states in a
 + * manner which is usable for ARM64. These two stubs are sufficient
 + * that system initialises and device PM works.
 + */
 +u32 acpi_target_system_state(void)
 +{
 + return ACPI_STATE_S0;
 +}
 +EXPORT_SYMBOL_GPL(acpi_target_system_state);
 +
 +int __init acpi_sleep_init(void)
 +{
 + return -ENOSYS;
 +}
 diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
 index 623b117..c32edf5 100644
 --- a/drivers/acpi/Makefile
 +++ b/drivers/acpi/Makefile
 @@ -23,7 +23,9 @@ acpi-y  += nvs.o

  # Power management related files
  acpi-y   += wakeup.o
 +ifneq (,$(findstring $(ARCH),x86 ia64))

 This is super-ugly.  Isn't there a better way to do that?

Its the standard example in the GNU Make manual, I would certainly
love if someone had a batter suggestion.

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property

[G Gregory]

On 2 February 2015 at 16:32, Mark Rutland  wrote:
> On Mon, Feb 02, 2015 at 01:50:52PM +, Graeme Gregory wrote:
>> On Mon, Feb 02, 2015 at 01:40:33PM +, Leif Lindholm wrote:
>> > On Mon, Feb 02, 2015 at 08:45:36PM +0800, Hanjun Guo wrote:
>> > > When system supporting both DT and ACPI but firmware providing
>> > > no dtb, we can use this linux,uefi-stub-generated-dtb property
>> > > to let kernel know that we can try ACPI configuration data even
>> > > if no "acpi=force" is passed in early parameters.
>> > >
>> > > CC: Mark Rutland 
>> > > CC: Jonathan Corbet 
>> > > CC: Catalin Marinas 
>> > > CC: Will Deacon 
>> > > CC: Leif Lindholm 
>> > > CC: Grant Likely 
>> > > CC: Matt Fleming 
>> > > Signed-off-by: Hanjun Guo 
>> > > ---
>> > >  Documentation/arm/uefi.txt |  3 +++
>> > >  arch/arm64/include/asm/acpi.h  |  1 +
>> > >  arch/arm64/kernel/setup.c  | 30 ++
>> > >  drivers/firmware/efi/libstub/fdt.c |  8 
>> > >  4 files changed, 42 insertions(+)
>> > >
>> > > diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
>> > > index d60030a..5f86eae 100644
>> > > --- a/Documentation/arm/uefi.txt
>> > > +++ b/Documentation/arm/uefi.txt
>> > > @@ -60,5 +60,8 @@ linux,uefi-mmap-desc-ver  | 32-bit | Version of the 
>> > > mmap descriptor format.
>> > >  
>> > > 
>> > >  linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.
>> > >  
>> > > 
>> > > +linux,uefi-stub-generated-dtb  | bool | Indication for no DTB provided 
>> > > by
>> > > +|  | firmware.
>> > > +
>> >
>> > Apologies for the late bikeshedding, but the discussion on this topic
>> > previsously was lively enough that I thought I'd let it die down a bit
>> > before seeing if I had anything to add.
>> >
>> > That, and I just realised something:
>> > One alternative to this added DT entry is that we could treat the
>> > absence of a registered UEFI configuration table as the indication
>> > that no HW description was provided from firmware, since the stub does
>> > not call InstallConfigurationTable() on the DT it generates. This does
>> > move the ability to detect to after efi_init(), but this should be
>> > fine for ACPI-purposes.
>> >
>> That would not work as expected in the kexec/Xen use case though as they
>> may genuinely boot with DT from an ACPI host without UEFI.
>
> I'm a little concerned by this case. How do we intend to pass stuff from
> Xen to the kernel in this case? When we initially discussed the stub
> prior to merging, we weren't quite sure if ACPI without UEFI was
> entirely safe.
>
> The linux,uefi-stub-kern-ver property was originally intended as a
> sanity-check feature to ensure nothing (including Xen) masqueraded as
> the stub, but for some reason the actual sanity check was never
> implemented.
>
>> > If that is deemed undesirable, I would still prefer Catalin's
>> > suggested name ("linux,bare-dtb"), which describes the state rather
>> > than the route we took to get there.
>> >
>> I agree.
>
> I guess this would be ok, though it would be nice to know which agent
> generated the DTB.
>

The most obvious scheme then is

linux,bare-dtb = "uefi-stub";

otherwise we generate a new binding for every component in the boot path.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property

[G Gregory]

On 2 February 2015 at 16:32, Mark Rutland mark.rutl...@arm.com wrote:
 On Mon, Feb 02, 2015 at 01:50:52PM +, Graeme Gregory wrote:
 On Mon, Feb 02, 2015 at 01:40:33PM +, Leif Lindholm wrote:
  On Mon, Feb 02, 2015 at 08:45:36PM +0800, Hanjun Guo wrote:
   When system supporting both DT and ACPI but firmware providing
   no dtb, we can use this linux,uefi-stub-generated-dtb property
   to let kernel know that we can try ACPI configuration data even
   if no acpi=force is passed in early parameters.
  
   CC: Mark Rutland mark.rutl...@arm.com
   CC: Jonathan Corbet cor...@lwn.net
   CC: Catalin Marinas catalin.mari...@arm.com
   CC: Will Deacon will.dea...@arm.com
   CC: Leif Lindholm leif.lindh...@linaro.org
   CC: Grant Likely grant.lik...@linaro.org
   CC: Matt Fleming matt.flem...@intel.com
   Signed-off-by: Hanjun Guo hanjun@linaro.org
   ---
Documentation/arm/uefi.txt |  3 +++
arch/arm64/include/asm/acpi.h  |  1 +
arch/arm64/kernel/setup.c  | 30 ++
drivers/firmware/efi/libstub/fdt.c |  8 
4 files changed, 42 insertions(+)
  
   diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
   index d60030a..5f86eae 100644
   --- a/Documentation/arm/uefi.txt
   +++ b/Documentation/arm/uefi.txt
   @@ -60,5 +60,8 @@ linux,uefi-mmap-desc-ver  | 32-bit | Version of the 
   mmap descriptor format.

   
linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.

   
   +linux,uefi-stub-generated-dtb  | bool | Indication for no DTB provided 
   by
   +|  | firmware.
   +
 
  Apologies for the late bikeshedding, but the discussion on this topic
  previsously was lively enough that I thought I'd let it die down a bit
  before seeing if I had anything to add.
 
  That, and I just realised something:
  One alternative to this added DT entry is that we could treat the
  absence of a registered UEFI configuration table as the indication
  that no HW description was provided from firmware, since the stub does
  not call InstallConfigurationTable() on the DT it generates. This does
  move the ability to detect to after efi_init(), but this should be
  fine for ACPI-purposes.
 
 That would not work as expected in the kexec/Xen use case though as they
 may genuinely boot with DT from an ACPI host without UEFI.

 I'm a little concerned by this case. How do we intend to pass stuff from
 Xen to the kernel in this case? When we initially discussed the stub
 prior to merging, we weren't quite sure if ACPI without UEFI was
 entirely safe.

 The linux,uefi-stub-kern-ver property was originally intended as a
 sanity-check feature to ensure nothing (including Xen) masqueraded as
 the stub, but for some reason the actual sanity check was never
 implemented.

  If that is deemed undesirable, I would still prefer Catalin's
  suggested name (linux,bare-dtb), which describes the state rather
  than the route we took to get there.
 
 I agree.

 I guess this would be ok, though it would be nice to know which agent
 generated the DTB.


The most obvious scheme then is

linux,bare-dtb = uefi-stub;

otherwise we generate a new binding for every component in the boot path.

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 18/18] Documentation: ACPI for ARM64

[G Gregory]

On 6 January 2015 at 13:50, Hanjun Guo  wrote:
> On 2015年01月06日 19:29, Catalin Marinas wrote:
>>
>> On Tue, Jan 06, 2015 at 11:11:07AM +, Hanjun Guo wrote:
>>>
>>> On 2015年01月05日 19:05, Catalin Marinas wrote:

 On Sun, Jan 04, 2015 at 09:39:24AM +, Hanjun Guo wrote:
>
> On 2014年12月25日 01:18, Catalin Marinas wrote:
> [...]
>>
>>
>> In addition to the above and _DSD requirements/banning, I would also
>> add
>> some clear statements around:
>>
>> _OSC: only global/published capabilities are allowed. For
>> device-specific _OSC we need a process or maybe we can ban them
>> entirely
>> and rely on _DSD once we clarify the process.
>>
>> _OSI: firmware must not check for certain _OSI strings. Here I'm not
>> sure what we would have to do for ARM Linux. Reporting "Windows" does
>> not make any sense but not reporting anything can, as Matthew Garrett
>> pointed out, can be interpreted by firmware as "Linux". In addition to
>> any statements in this document, I suggest you patch
>> drivers/acpi/acpica/utosi.c accordingly, maybe report "Linux" for ARM
>> and print a kernel warning so that we notice earlier.
>>
>> ACPI_OS_NAME: this is globally defined as "Microsoft Windows NT". It
>> doesn't make much sense in the ARM context. Could we change it to
>> "Linux" when CONFIG_ARM64?
>>>
>>>
>>> I think we can introduce a Kconfig such as CONFIG_ACPI_OS_NAME_LINUX,
>>> selected by ARM64 and change ACPI_OS_NAME to "Linux" when
>>> CONFIG_ACPI_OS_NAME_LINUX defined. (we can not add CONFIG_ARM64 in
>>> ACPICA code directly since it will be used by windows too)
>>>
>>> some code like below:
>>
>>
>> This looks fine for me (with some minor comments below) but I'm not an
>> ACPI expert to say there wouldn't be any issues.
>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index b1f9a20..de567a3 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -1,5 +1,6 @@
>>>config ARM64
>>>   def_bool y
>>> +   select ACPI_OS_NAME_LINUX if ACPI
>>>   select ARCH_BINFMT_ELF_RANDOMIZE_PIE
>>>   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>>>   select ARCH_HAS_GCOV_PROFILE_ALL
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index 8951cef..11a10ac 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -369,6 +369,10 @@ config ACPI_REDUCED_HARDWARE_ONLY
>>>
>>> If you are unsure what to do, do not enable this option.
>>>
>>> +config ACPI_OS_NAME_LINUX
>>> +   bool "Using Linux for _OS method" if EXPERT
>>> +   def_bool n
>>
>>
>> No need for a default n, it is off by default. Alternatively you could
>> say:
>>
>> default y if ARM64
>
>
> ok.
>
>>
>>> +
>>>source "drivers/acpi/apei/Kconfig"
>>>
>>>config ACPI_EXTLOG
>>> diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
>>> index 5a0a3e5..db5e13e 100644
>>> --- a/include/acpi/acconfig.h
>>> +++ b/include/acpi/acconfig.h
>>> @@ -69,7 +69,11 @@
>>> * code that will not execute the _OSI method unless _OS matches the
>>> string
>>> * below.  Therefore, change this string at your own risk.
>>> */
>>> +#ifndef ACPI_OS_NAME_USING_LINUX
>>>#define ACPI_OS_NAME"Microsoft Windows NT"
>>> +#else
>>> +#define ACPI_OS_NAME"Linux"
>>> +#endif
>>
>>
>> Can you not use CONFIG_ACPI_OS_NAME_LINUX directly here without
>> introducing another macro?
>
>
> acconfig.h is part of ACPICA core and will be shared by windows and
> other OS, so use CONFIG from Linux in this file is not allowed I think.
>

We could just propse
#ifndef ACPI_OS_NAME
#define ACPI_OS_NAME "Microsoft Windows NT"
#endif

to acpica maintainers. This will not alter Windows or other software usage
but we can then override it in Linux when/if we want to.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 18/18] Documentation: ACPI for ARM64

[G Gregory]

On 6 January 2015 at 11:20, Catalin Marinas  wrote:
> On Mon, Jan 05, 2015 at 08:16:30PM +, Arnd Bergmann wrote:
>> On Monday 05 January 2015 13:13:02 Catalin Marinas wrote:
>> > > since passing no DT tables to OS but
>> > > acpi=force is missing is a corner case, we can do a follow up patch to
>> > > fix that, does it make sense?
>> >
>> > Not entirely. Why would no dtb and no acpi=force be a corner case? I
>> > thought this should be the default when only ACPI tables are passed, no
>> > need for an additional acpi=force argument.
>>
>> We don't really support the case of only ACPI tables for now. The expectation
>> is that you always have working DT support, at least for the next few years
>> as ACPI features are ramping up, and without acpi=force it should not try
>> to use ACPI at all.
>
> So if both DT and ACPI are present, just use DT unless acpi=force is
> passed. So far I think we agree but what I want to avoid is always
> mandating acpi=force even when the DT tables are missing (in the long
> run).
>
> Now, what's preventing a vendor firmware from providing only ACPI
> tables? Do we enforce it in some way (arm-acpi.txt, kernel warning etc.)
> that both DT and ACPI are supported, or at least that dts files are
> merged in the kernel first?
>
How do we tell the difference between a DT passed purely for booting purposes
ie a skeleton DT. And one which actually has hardware description as this needs
to be done before unpacking the DT.

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 18/18] Documentation: ACPI for ARM64

[G Gregory]

On 6 January 2015 at 11:20, Catalin Marinas catalin.mari...@arm.com wrote:
 On Mon, Jan 05, 2015 at 08:16:30PM +, Arnd Bergmann wrote:
 On Monday 05 January 2015 13:13:02 Catalin Marinas wrote:
   since passing no DT tables to OS but
   acpi=force is missing is a corner case, we can do a follow up patch to
   fix that, does it make sense?
 
  Not entirely. Why would no dtb and no acpi=force be a corner case? I
  thought this should be the default when only ACPI tables are passed, no
  need for an additional acpi=force argument.

 We don't really support the case of only ACPI tables for now. The expectation
 is that you always have working DT support, at least for the next few years
 as ACPI features are ramping up, and without acpi=force it should not try
 to use ACPI at all.

 So if both DT and ACPI are present, just use DT unless acpi=force is
 passed. So far I think we agree but what I want to avoid is always
 mandating acpi=force even when the DT tables are missing (in the long
 run).

 Now, what's preventing a vendor firmware from providing only ACPI
 tables? Do we enforce it in some way (arm-acpi.txt, kernel warning etc.)
 that both DT and ACPI are supported, or at least that dts files are
 merged in the kernel first?

How do we tell the difference between a DT passed purely for booting purposes
ie a skeleton DT. And one which actually has hardware description as this needs
to be done before unpacking the DT.

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 18/18] Documentation: ACPI for ARM64

[G Gregory]

On 6 January 2015 at 13:50, Hanjun Guo hanjun@linaro.org wrote:
 On 2015年01月06日 19:29, Catalin Marinas wrote:

 On Tue, Jan 06, 2015 at 11:11:07AM +, Hanjun Guo wrote:

 On 2015年01月05日 19:05, Catalin Marinas wrote:

 On Sun, Jan 04, 2015 at 09:39:24AM +, Hanjun Guo wrote:

 On 2014年12月25日 01:18, Catalin Marinas wrote:
 [...]


 In addition to the above and _DSD requirements/banning, I would also
 add
 some clear statements around:

 _OSC: only global/published capabilities are allowed. For
 device-specific _OSC we need a process or maybe we can ban them
 entirely
 and rely on _DSD once we clarify the process.

 _OSI: firmware must not check for certain _OSI strings. Here I'm not
 sure what we would have to do for ARM Linux. Reporting Windows does
 not make any sense but not reporting anything can, as Matthew Garrett
 pointed out, can be interpreted by firmware as Linux. In addition to
 any statements in this document, I suggest you patch
 drivers/acpi/acpica/utosi.c accordingly, maybe report Linux for ARM
 and print a kernel warning so that we notice earlier.

 ACPI_OS_NAME: this is globally defined as Microsoft Windows NT. It
 doesn't make much sense in the ARM context. Could we change it to
 Linux when CONFIG_ARM64?


 I think we can introduce a Kconfig such as CONFIG_ACPI_OS_NAME_LINUX,
 selected by ARM64 and change ACPI_OS_NAME to Linux when
 CONFIG_ACPI_OS_NAME_LINUX defined. (we can not add CONFIG_ARM64 in
 ACPICA code directly since it will be used by windows too)

 some code like below:


 This looks fine for me (with some minor comments below) but I'm not an
 ACPI expert to say there wouldn't be any issues.

 diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
 index b1f9a20..de567a3 100644
 --- a/arch/arm64/Kconfig
 +++ b/arch/arm64/Kconfig
 @@ -1,5 +1,6 @@
config ARM64
   def_bool y
 +   select ACPI_OS_NAME_LINUX if ACPI
   select ARCH_BINFMT_ELF_RANDOMIZE_PIE
   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
   select ARCH_HAS_GCOV_PROFILE_ALL
 diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
 index 8951cef..11a10ac 100644
 --- a/drivers/acpi/Kconfig
 +++ b/drivers/acpi/Kconfig
 @@ -369,6 +369,10 @@ config ACPI_REDUCED_HARDWARE_ONLY

 If you are unsure what to do, do not enable this option.

 +config ACPI_OS_NAME_LINUX
 +   bool Using Linux for _OS method if EXPERT
 +   def_bool n


 No need for a default n, it is off by default. Alternatively you could
 say:

 default y if ARM64


 ok.


 +
source drivers/acpi/apei/Kconfig

config ACPI_EXTLOG
 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
 index 5a0a3e5..db5e13e 100644
 --- a/include/acpi/acconfig.h
 +++ b/include/acpi/acconfig.h
 @@ -69,7 +69,11 @@
 * code that will not execute the _OSI method unless _OS matches the
 string
 * below.  Therefore, change this string at your own risk.
 */
 +#ifndef ACPI_OS_NAME_USING_LINUX
#define ACPI_OS_NAMEMicrosoft Windows NT
 +#else
 +#define ACPI_OS_NAMELinux
 +#endif


 Can you not use CONFIG_ACPI_OS_NAME_LINUX directly here without
 introducing another macro?


 acconfig.h is part of ACPICA core and will be shared by windows and
 other OS, so use CONFIG from Linux in this file is not allowed I think.


We could just propse
#ifndef ACPI_OS_NAME
#define ACPI_OS_NAME Microsoft Windows NT
#endif

to acpica maintainers. This will not alter Windows or other software usage
but we can then override it in Linux when/if we want to.

Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/