that information
> was (or is now) contained at the top of the file in the comments.
>
This is all fine with me.
Acked-by: Graeme Gregory
Thanks
> Cc: Tony Lindgren
> Cc: Lee Jones
> Cc: Graeme Gregory
> Cc: Jorge Eduardo Candelaria
> Cc: linux-o...@vger.kernel.org
> Signed-off-by
that information
> was (or is now) contained at the top of the file in the comments.
>
This is all fine with me.
Acked-by: Graeme Gregory
Thanks
> Cc: Tony Lindgren
> Cc: Lee Jones
> Cc: Graeme Gregory
> Cc: Jorge Eduardo Candelaria
> Cc: linux-o...@vger.kernel.org
> Signed-off-by
Tables/Armada70x0/Dsdt.asl#L131
>
> I will appreciate any comments or remarks.
>
Nice work, this looks pretty neat to me, for series.
Reviewed-by: Graeme Gregory <graeme.greg...@linaro.org>
Thanks
Graeme
> Best regards,
> Marcin
>
> Changelog:
> v2 -> v3:
> * 1/7,
Tables/Armada70x0/Dsdt.asl#L131
>
> I will appreciate any comments or remarks.
>
Nice work, this looks pretty neat to me, for series.
Reviewed-by: Graeme Gregory
Thanks
Graeme
> Best regards,
> Marcin
>
> Changelog:
> v2 -> v3:
> * 1/7, 2/7
> - Add Rafael's Acked-
On Mon, Jan 08, 2018 at 06:17:06PM +0100, Marcin Wojtas wrote:
> Hi Andrew,
>
>
>
> 2018-01-08 16:42 GMT+01:00 Andrew Lunn :
> > w> I am not familiar with MDIO, but if its similar or a specific
> >> implementation of a serial bus that does sound sane!
> >
>
> Thanks for
On Mon, Jan 08, 2018 at 06:17:06PM +0100, Marcin Wojtas wrote:
> Hi Andrew,
>
>
>
> 2018-01-08 16:42 GMT+01:00 Andrew Lunn :
> > w> I am not familiar with MDIO, but if its similar or a specific
> >> implementation of a serial bus that does sound sane!
> >
>
> Thanks for digging, I will check
On Mon, Jan 08, 2018 at 03:53:12PM +0100, Andrew Lunn wrote:
> On Mon, Jan 08, 2018 at 02:45:48PM +0000, Graeme Gregory wrote:
> > On Thu, Jan 04, 2018 at 05:20:36PM +0100, Andrew Lunn wrote:
> > > > > I already agreed with 'reg' being awkward in the later emails.
> &g
On Mon, Jan 08, 2018 at 03:53:12PM +0100, Andrew Lunn wrote:
> On Mon, Jan 08, 2018 at 02:45:48PM +0000, Graeme Gregory wrote:
> > On Thu, Jan 04, 2018 at 05:20:36PM +0100, Andrew Lunn wrote:
> > > > > I already agreed with 'reg' being awkward in the later emails.
> &g
On Thu, Jan 04, 2018 at 05:20:36PM +0100, Andrew Lunn wrote:
> > > I already agreed with 'reg' being awkward in the later emails.
> > > Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
> > >
> > Ah it is an actual address, then yes _ADR is probably more appropriate.
>
>
On Thu, Jan 04, 2018 at 05:20:36PM +0100, Andrew Lunn wrote:
> > > I already agreed with 'reg' being awkward in the later emails.
> > > Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
> > >
> > Ah it is an actual address, then yes _ADR is probably more appropriate.
>
>
On Wed, Jan 03, 2018 at 12:12:06PM +0100, Marcin Wojtas wrote:
> Hi Graeme,
>
> 2018-01-03 12:00 GMT+01:00 Graeme Gregory <graeme.greg...@linaro.org>:
> > On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> >> On 18 December 2017 at 10:17, Marcin Wo
On Wed, Jan 03, 2018 at 12:12:06PM +0100, Marcin Wojtas wrote:
> Hi Graeme,
>
> 2018-01-03 12:00 GMT+01:00 Graeme Gregory :
> > On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> >> On 18 December 2017 at 10:17, Marcin Wojtas wrote:
> >>
On Sun, Dec 31, 2017 at 08:23:54PM +0100, Andrew Lunn wrote:
> > * Modify way of obtaining interrupts - with ACPI they are resources
> > bound to struct platform_device and it's not possible to obtain
> > them directly from the child node. Hence a formula is used, depending
> > on the
On Sun, Dec 31, 2017 at 08:23:54PM +0100, Andrew Lunn wrote:
> > * Modify way of obtaining interrupts - with ACPI they are resources
> > bound to struct platform_device and it's not possible to obtain
> > them directly from the child node. Hence a formula is used, depending
> > on the
On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> On 18 December 2017 at 10:17, Marcin Wojtas wrote:
> > Hi,
> >
> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> > First three patches introduce fwnode helpers for obtaining PHY
> >
On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> On 18 December 2017 at 10:17, Marcin Wojtas wrote:
> > Hi,
> >
> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> > First three patches introduce fwnode helpers for obtaining PHY
> > information from nodes and
On 11 September 2017 at 13:28, Andreas Schwab <sch...@suse.de> wrote:
> On Sep 11 2017, Graeme Gregory <graeme.greg...@linaro.org> wrote:
>
>> Considering the SPCR table in question seems mildly insane, you could
>> always unload the SPCR in grub.
>
> How do you
On 11 September 2017 at 13:28, Andreas Schwab wrote:
> On Sep 11 2017, Graeme Gregory wrote:
>
>> Considering the SPCR table in question seems mildly insane, you could
>> always unload the SPCR in grub.
>
> How do you "unload the SPCR"? But in any case, consol
On 11 September 2017 at 12:39, Andreas Schwab wrote:
> On Sep 11 2017, Leif Lindholm wrote:
>
>> Are you asking because you want to use a different console in a lab
>> setup or because there are issues with SPCR on your platform?
>
> The console from the
On 11 September 2017 at 12:39, Andreas Schwab wrote:
> On Sep 11 2017, Leif Lindholm wrote:
>
>> Are you asking because you want to use a different console in a lab
>> setup or because there are issues with SPCR on your platform?
>
> The console from the SPCR is not the one forwarded by the BMC.
On 4 August 2017 at 23:51, Rafael J. Wysocki <raf...@kernel.org> wrote:
> On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
> <graeme.greg...@linaro.org> wrote:
>> A couple of patches to build on the SPCR quirks support already upstreamed.
>>
>> 1 - Moonshot m400
On 4 August 2017 at 23:51, Rafael J. Wysocki wrote:
> On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
> wrote:
>> A couple of patches to build on the SPCR quirks support already upstreamed.
>>
>> 1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
xgene v1/v2 chips are also used on moonshot cartridges that have
different table headers to the ones on Mustang. Extend the quirk
so it also recognises the Moonshot M400 variant too.
Signed-off-by: Graeme Gregory <graeme.greg...@linaro.org>
---
drivers/acpi/spcr.c | 13 ++---
xgene v1/v2 chips are also used on moonshot cartridges that have
different table headers to the ones on Mustang. Extend the quirk
so it also recognises the Moonshot M400 variant too.
Signed-off-by: Graeme Gregory
---
drivers/acpi/spcr.c | 13 ++---
1 file changed, 10 insertions(+), 3
handling to avoid setting a baud rate and therefore using
the UART as configured by firmware.
Signed-off-by: Graeme Gregory <graeme.greg...@linaro.org>
---
drivers/acpi/spcr.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/spcr.c b/driver
handling to avoid setting a baud rate and therefore using
the UART as configured by firmware.
Signed-off-by: Graeme Gregory
---
drivers/acpi/spcr.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 1457ef0b0fd5
A couple of patches to build on the SPCR quirks support already upstreamed.
1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
HPe specific headers so extend quirk to understand those too.
2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
situation
A couple of patches to build on the SPCR quirks support already upstreamed.
1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
HPe specific headers so extend quirk to understand those too.
2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
situation
Tested on our Linaro moonshot
Tested-by: Graeme Gregory <graeme.greg...@linaro.org>
Thanks
> ---
> v4:
> - Rebase on top of pci/ecam tree
> - Introduce xgene_get_csr_resource to discover MMIO register space
> (per Mark's test code).
> - Refactor .init functions for pci
e and configure
> controller registers to select and address the target secondary device.
>
> The quirk will only be applied for X-Gene PCIe MCFG table with
> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>
> Signed-off-by: Duc Dang
Tested on our Linaro mo
On Sat, Dec 03, 2016 at 05:06:31AM -0500, Jon Masters wrote:
> Hi Duc, all,
>
> (and changing the subject and trimming/adjusting the CC)
>
> On 12/02/2016 02:39 PM, Duc Dang wrote:
> > On Fri, Dec 2, 2016 at 12:11 AM, Jon Masters wrote:
> >> You're welcome.
> >>
> >>
On Sat, Dec 03, 2016 at 05:06:31AM -0500, Jon Masters wrote:
> Hi Duc, all,
>
> (and changing the subject and trimming/adjusting the CC)
>
> On 12/02/2016 02:39 PM, Duc Dang wrote:
> > On Fri, Dec 2, 2016 at 12:11 AM, Jon Masters wrote:
> >> You're welcome.
> >>
> >> (Unrelated) Note that I
On Tue, Nov 22, 2016 at 03:05:29PM +, Gabriele Paoloni wrote:
> Hi Tomasz
>
> > -Original Message-
> > From: Tomasz Nowicki [mailto:t...@semihalf.com]
> > Sent: 22 November 2016 13:58
> > To: liudongdong (C); helg...@kernel.org; a...@arndb.de;
> > raf...@kernel.org;
On Tue, Nov 22, 2016 at 03:05:29PM +, Gabriele Paoloni wrote:
> Hi Tomasz
>
> > -Original Message-
> > From: Tomasz Nowicki [mailto:t...@semihalf.com]
> > Sent: 22 November 2016 13:58
> > To: liudongdong (C); helg...@kernel.org; a...@arndb.de;
> > raf...@kernel.org;
On Fri, Oct 28, 2016 at 04:50:07PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 18, 2016 at 05:04:07PM +0100, Lorenzo Pieralisi wrote:
> > In ARM ACPI systems, IOMMU components are specified through static
> > IORT table entries. In order to create platform devices for the
> > corresponding ARM
On Fri, Oct 28, 2016 at 04:50:07PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 18, 2016 at 05:04:07PM +0100, Lorenzo Pieralisi wrote:
> > In ARM ACPI systems, IOMMU components are specified through static
> > IORT table entries. In order to create platform devices for the
> > corresponding ARM
On Thu, Sep 08, 2016 at 12:34:16PM -0400, Mark Salter wrote:
> On Thu, 2016-09-08 at 12:16 +0100, Will Deacon wrote:
> > On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
> > >
> > >
> > > On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> > > >
> > > > SBBR mentions SPCR as a
On Thu, Sep 08, 2016 at 12:34:16PM -0400, Mark Salter wrote:
> On Thu, 2016-09-08 at 12:16 +0100, Will Deacon wrote:
> > On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
> > >
> > >
> > > On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> > > >
> > > > SBBR mentions SPCR as a
On Thu, Sep 08, 2016 at 12:16:55PM +0100, Will Deacon wrote:
> On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
> >
> > On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> > > SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64
> > >
> > > Earlycon should be set up
On Thu, Sep 08, 2016 at 12:16:55PM +0100, Will Deacon wrote:
> On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
> >
> > On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> > > SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64
> > >
> > > Earlycon should be set up
MCFG IDs along with custom pci_ops structure and initialization
> call.
>
> As an example, the last patch presents quirk handling mechanism usage for
> ThunderX PEM driver.
>
Series looks good to me.
Reviewed-by: Graeme Gregory <graeme.greg...@linaro.org>
> v4 ->
MCFG IDs along with custom pci_ops structure and initialization
> call.
>
> As an example, the last patch presents quirk handling mechanism usage for
> ThunderX PEM driver.
>
Series looks good to me.
Reviewed-by: Graeme Gregory
> v4 -> v5
> - rebase against v4.8-rc1
&g
On Mon, Jun 20, 2016 at 04:19:14PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 20, 2016 at 03:26:39PM +0300, Aleksey Makarov wrote:
> >
> > On 06/02/2016 09:02 PM, Aleksey Makarov wrote:
> > >
> > > On 05/20/2016 04:03 PM, Aleksey Makarov wrote:
> >
> > Hi Russell,
> >
> > Can you
On Mon, Jun 20, 2016 at 04:19:14PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 20, 2016 at 03:26:39PM +0300, Aleksey Makarov wrote:
> >
> > On 06/02/2016 09:02 PM, Aleksey Makarov wrote:
> > >
> > > On 05/20/2016 04:03 PM, Aleksey Makarov wrote:
> >
> > Hi Russell,
> >
> > Can you
On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki wrote:
> > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> >> > On 2016/6/30
On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki wrote:
> > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> >> > On 2016/6/30 21:27, Rafael J. Wysocki
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
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
ntroduces a new function acpi_console_check().
> >> This function is called when a new uart is registered at serial_core.c
> >> the same way OF code checks for console. If the registered uart is the
> >> console specified by SPCR table, this function calls
> >&g
ntroduces a new function acpi_console_check().
> >> This function is called when a new uart is registered at serial_core.c
> >> the same way OF code checks for console. If the registered uart is the
> >> console specified by SPCR table, this function calls
> >&g
On Tue, Apr 05, 2016 at 06:00:31PM -0600, Al Stone wrote:
> On 04/05/2016 02:56 AM, Charles Garcia-Tobin wrote:
> >
> >
> > On 04/04/2016 23:52, "Mark Rutland" wrote:
> >
> >> Hi,
> >>
> >> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
> >>> This is a
On Tue, Apr 05, 2016 at 06:00:31PM -0600, Al Stone wrote:
> On 04/05/2016 02:56 AM, Charles Garcia-Tobin wrote:
> >
> >
> > On 04/04/2016 23:52, "Mark Rutland" wrote:
> >
> >> Hi,
> >>
> >> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
> >>> This is a proposal for adding ACPI
On 22/03/16 21:45, David Daney wrote:
On 03/22/2016 11:48 AM, Jon Masters wrote:
On 03/08/2016 06:59 PM, David Daney wrote:
From: David Daney
v15:
- Make the distance-map node optional (again), if it is not in
the device tree, default values are used.
- Minor
On 22/03/16 21:45, David Daney wrote:
On 03/22/2016 11:48 AM, Jon Masters wrote:
On 03/08/2016 06:59 PM, David Daney wrote:
From: David Daney
v15:
- Make the distance-map node optional (again), if it is not in
the device tree, default values are used.
- Minor
On Tue, Mar 08, 2016 at 11:29:30AM +, Julien Grall wrote:
> Fill up the recently introduced gic_kvm_info with the virtual GIC
> information.
>
> Signed-off-by: Julien Grall
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc
On Tue, Mar 08, 2016 at 11:29:30AM +, Julien Grall wrote:
> Fill up the recently introduced gic_kvm_info with the virtual GIC
> information.
>
> Signed-off-by: Julien Grall
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
>
> ---
> Changes in v3:
> - Add ACPI
On Mon, Feb 22, 2016 at 04:45:17PM +0100, Matthias Brugger wrote:
>
>
> On 22/02/16 14:46, Aleksey Makarov wrote:
> >From: Leif Lindholm
> >
> >In order to support selecting earlycon via either ACPI or DT, move
> >the decision on whether to attempt ACPI configuration
On Mon, Feb 22, 2016 at 04:45:17PM +0100, Matthias Brugger wrote:
>
>
> On 22/02/16 14:46, Aleksey Makarov wrote:
> >From: Leif Lindholm
> >
> >In order to support selecting earlycon via either ACPI or DT, move
> >the decision on whether to attempt ACPI configuration into the
> >early_param
On Mon, Feb 01, 2016 at 09:01:26AM +, Graeme Gregory wrote:
> On Mon, Jan 25, 2016 at 05:45:22PM +0600, Aleksey Makarov wrote:
> > 'ARM Server Base Boot Requiremets' [1] mention SPCR
> > (Serial Port Console Redirection Table) [2] as a mandatory ACPI table
> > that specif
On Mon, Jan 25, 2016 at 05:45:22PM +0600, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mention SPCR
> (Serial Port Console Redirection Table) [2] as a mandatory ACPI table
> that specifies the configuration of serial console.
>
> Parse this table and check if any registered
On Mon, Jan 25, 2016 at 05:45:22PM +0600, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mention SPCR
> (Serial Port Console Redirection Table) [2] as a mandatory ACPI table
> that specifies the configuration of serial console.
>
> Parse this table and check if any registered
On Mon, Feb 01, 2016 at 09:01:26AM +, Graeme Gregory wrote:
> On Mon, Jan 25, 2016 at 05:45:22PM +0600, Aleksey Makarov wrote:
> > 'ARM Server Base Boot Requiremets' [1] mention SPCR
> > (Serial Port Console Redirection Table) [2] as a mandatory ACPI table
> > that specif
On Tue, Jan 05, 2016 at 10:23:08AM -0600, Timur Tabi wrote:
> G Gregory wrote:
> >>>I'm confused by this patch. We already have code like this in
> >>>tty-next, in the form of sbsa_uart_probe():
> >>>
>
On Tue, Jan 05, 2016 at 10:23:08AM -0600, Timur Tabi wrote:
> G Gregory wrote:
> >>>I'm confused by this patch. We already have code like this in
> >>>tty-next, in the form of sbsa_uart_probe():
> >>>
>
On Fri, Dec 04, 2015 at 11:24:20AM +0800, Wang Hongcheng wrote:
> AMD pl330 is a UART DMA device, it shares one ACPI item with UART. So
> a platform device and an acpi device will be created according to
> AMD0020 ACPI dev. And its mem base address must have an offset. As a
> result,
On Fri, Dec 04, 2015 at 11:24:20AM +0800, Wang Hongcheng wrote:
> AMD pl330 is a UART DMA device, it shares one ACPI item with UART. So
> a platform device and an acpi device will be created according to
> AMD0020 ACPI dev. And its mem base address must have an offset. As a
> result,
On Thu, Dec 03, 2015 at 09:54:43AM +0800, yankejian wrote:
> Add support for getting the PHY devices on an MDIO bus by ACPI.
> Currently many of the ethernet drivers are open coding a solution
> for reading data out of ACPI to find the correct PHY device.
> This patch implements a set of common
On Thu, Dec 03, 2015 at 09:54:43AM +0800, yankejian wrote:
> Add support for getting the PHY devices on an MDIO bus by ACPI.
> Currently many of the ethernet drivers are open coding a solution
> for reading data out of ACPI to find the correct PHY device.
> This patch implements a set of common
On Tue, Dec 01, 2015 at 03:21:47AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 11:38:50 AM Graeme Gregory wrote:
> > In ACPI this device is only defined in SBSA mode so
> > if we are probing from ACPI use this mode.
> >
> > Cc: Rafael J. Wysocki
On Tue, Dec 01, 2015 at 03:16:53AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 11:38:49 AM Graeme Gregory wrote:
> > Call the amba device creation function in the default enumeration path,
> > this is the same location platform devices are probed.
>
On Tue, Dec 01, 2015 at 03:16:53AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 11:38:49 AM Graeme Gregory wrote:
> > Call the amba device creation function in the default enumeration path,
> > this is the same location platform devices are probed.
>
On Tue, Dec 01, 2015 at 03:21:47AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 11:38:50 AM Graeme Gregory wrote:
> > In ACPI this device is only defined in SBSA mode so
> > if we are probing from ACPI use this mode.
> >
> > Cc: Rafael J. Wysocki
Hi Fu Wei,
Looks ok to me.
Reviewed by: Graeme Gregory
Thanks
On Mon, Nov 09, 2015 at 03:31:19PM +0800, fu@linaro.org wrote:
> From: Fu Wei
>
> This driver bases on linux kernel watchdog framework, and
> use "pretimeout" in the framework. It supports getting ti
Hi Fu Wei,
Looks ok to me.
Reviewed by: Graeme Gregory <graeme.greg...@linaro.org>
Thanks
On Mon, Nov 09, 2015 at 03:31:19PM +0800, fu@linaro.org wrote:
> From: Fu Wei <fu@linaro.org>
>
> This driver bases on linux kernel watchdog framework, and
> use "
Call the amba device creation function in the default enumeration path,
this is the same location platform devices are probed.
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Russell King
Signed-off-by: Graeme Gregory
---
drivers/acpi/scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
Cc: Russell King
Signed-off-by: Graeme Gregory
---
drivers/acpi/Makefile| 1 +
drivers/acpi/acpi_amba.c | 157 +++
include/linux/acpi.h | 1 +
3 files changed, 159 insertions(+)
create mode 100644 drivers/acpi/acpi_amba.c
diff --git
As discussed when Shannon Zhao sent a patch to add platform_device support
to pl061 driver. Russel and other maintainers prefered that ACPI learned
how to create AMBA devices rather than converting/adding platform_device
support to AMBA drivers.
In ACPI this device is only defined in SBSA mode so
if we are probing from ACPI use this mode.
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Russell King
Cc: Greg Kroah-Hartman
Signed-off-by: Graeme Gregory
---
drivers/tty/serial/amba-pl011.c | 32 +---
1 file changed
Call the amba device creation function in the default enumeration path,
this is the same location platform devices are probed.
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
Cc: Russell King <li...@arm.linux.org.uk>
Signed-off-by: Graeme Gr
As discussed when Shannon Zhao sent a patch to add platform_device support
to pl061 driver. Russel and other maintainers prefered that ACPI learned
how to create AMBA devices rather than converting/adding platform_device
support to AMBA drivers.
In ACPI this device is only defined in SBSA mode so
if we are probing from ACPI use this mode.
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
Cc: Russell King <li...@arm.linux.org.uk>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Signe
t;r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
Cc: Russell King <li...@arm.linux.org.uk>
Signed-off-by: Graeme Gregory <graeme.greg...@linaro.org>
---
drivers/acpi/Makefile| 1 +
drivers/acpi/acpi_amba.c | 157 +++
include/linux/acp
ompiled for x86 and ia64 with no
> known failures.
>
> Changes for v3:
>-- Reviewed-and-tested-by from Sudeep Holla for arm64 parts
>-- Clearer language in error messages (Graeme Gregory, Timur Tabi)
>-- Double checked that inserting call to bad_madt_entry() into the
>
On Wed, Sep 09, 2015 at 03:09:47PM -0600, Al Stone wrote:
> The existing BAD_MADT_ENTRY macro only checks that the size of the data
> structure for an MADT subtable matches the length entry in the subtable.
> This is, unfortunately, not reliable. Nor, as it turns out, does it have
> anything to
ompiled for x86 and ia64 with no
> known failures.
>
> Changes for v3:
>-- Reviewed-and-tested-by from Sudeep Holla for arm64 parts
>-- Clearer language in error messages (Graeme Gregory, Timur Tabi)
>-- Double checked that inserting call to bad_madt_entry() into the
>
On Wed, Sep 09, 2015 at 03:09:47PM -0600, Al Stone wrote:
> The existing BAD_MADT_ENTRY macro only checks that the size of the data
> structure for an MADT subtable matches the length entry in the subtable.
> This is, unfortunately, not reliable. Nor, as it turns out, does it have
> anything to
On Wed, Jul 29, 2015 at 09:17:08PM +0300, 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 fo
On Wed, Jul 29, 2015 at 09:17:08PM +0300, 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
On Thu, Aug 06, 2015 at 05:33:10PM -0700, David Daney wrote:
> From: David Daney
>
> Find out which PHYs belong to which BGX instance in the ACPI way.
>
> Set the MAC address of the device as provided by ACPI tables. This is
> similar to the implementation for devicetree in
>
On Thu, Aug 06, 2015 at 05:33:10PM -0700, David Daney wrote:
From: David Daney david.da...@cavium.com
Find out which PHYs belong to which BGX instance in the ACPI way.
Set the MAC address of the device as provided by ACPI tables. This is
similar to the implementation for devicetree in
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
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
Hi,
I thought I would send this patch as an RFC. It is something I did when
another linaro engineer was modifying acpica-tools to not require /dev/mem.
It exports the 3 tables that are not currenly exported in sysfs.
Currently I do not think there is any user of this because acpica-tools can
On some architectures /dev/mem is being removed. For debug/analysis
tools like FWTS/acpidump we therefore need to expose the ACPI root
tables in sysfs like the other tables.
Signed-off-by: Graeme Gregory
---
drivers/acpi/sysfs.c | 123 +++
1 file
On Tue, Jul 21, 2015 at 11:07:55AM +0100, Marc Zyngier wrote:
> The irqdomain code is not entierely really ACPI friendly, as it has
> some built-in knowledge of the device-tree. Nothing too harmful, but
> enough to scare the ARM ACPI developpers which end up with their own
> version of the square
On Tue, Jul 21, 2015 at 11:08:00AM +0100, Marc Zyngier wrote:
> Now that the basic ACPI GSI code is irq domain aware, make sure
> that the ACPI support in the GIC doesn't pointlessly deviate from
> the DT path.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/irqchip/irq-gic.c | 17
On some architectures /dev/mem is being removed. For debug/analysis
tools like FWTS/acpidump we therefore need to expose the ACPI root
tables in sysfs like the other tables.
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
---
drivers/acpi/sysfs.c | 123
Hi,
I thought I would send this patch as an RFC. It is something I did when
another linaro engineer was modifying acpica-tools to not require /dev/mem.
It exports the 3 tables that are not currenly exported in sysfs.
Currently I do not think there is any user of this because acpica-tools can
On Tue, Jul 21, 2015 at 11:08:00AM +0100, Marc Zyngier wrote:
Now that the basic ACPI GSI code is irq domain aware, make sure
that the ACPI support in the GIC doesn't pointlessly deviate from
the DT path.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-gic.c
On Tue, Jul 21, 2015 at 11:07:55AM +0100, Marc Zyngier wrote:
The irqdomain code is not entierely really ACPI friendly, as it has
some built-in knowledge of the device-tree. Nothing too harmful, but
enough to scare the ARM ACPI developpers which end up with their own
version of the square
1 - 100 of 262 matches
Mail list logo