Re: [PATCH] c6x: Use generic clkdev.h header

On Tue, 2015-09-15 at 16:09 -0700, Stephen Boyd wrote: > The c6x clkdev.h header is the same as the asm-generic header, so > just use the asm-generic one. > > Signed-off-by: Stephen Boyd > --- Pulled into c6x tree for next merge window. Thanks! -- To unsubscribe from

Re: [PATCH] c6x: Use generic clkdev.h header

On Tue, 2015-09-15 at 16:09 -0700, Stephen Boyd wrote: > The c6x clkdev.h header is the same as the asm-generic header, so > just use the asm-generic one. > > Signed-off-by: Stephen Boyd > --- Pulled into c6x tree for next merge window. Thanks! -- To unsubscribe from

Re: [PATCH] mm/early_ioremap: add explicit #include of asm/early_ioremap.h

ned-off-by: Ard Biesheuvel > --- Acked-by: Mark Salter > > I ran into this by accident when trying to enable to the generic ioremap > implementation for 32-bit ARM. > > mm/early_ioremap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/early_ioremap.c b/mm/e

Re: [Linaro-acpi] [RFC 4/5] tty/console: use SPCR table to define console

On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > From: Torez Smith > > If console= is not added to the kernel command line, the console > is not registered until much further into the booting process. This patch > adds support to parse the SPCR ACPI table to pull console support out, >

Re: [Linaro-acpi] [RFC 4/5] tty/console: use SPCR table to define console

On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > From: Torez Smith > > If console= is not added to the kernel command line, the console > is not registered until much further into the booting process. This patch > adds support to parse the SPCR ACPI table to pull

Re: [Linaro-acpi] [RFC 4/5] tty/console: use SPCR table to define console

On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > From: Torez Smith > > If console= is not added to the kernel command line, the console > is not registered until much further into the booting process. This patch > adds support to parse the SPCR ACPI table to pull

Re: [PATCH] mm/early_ioremap: add explicit #include of asm/early_ioremap.h

gned-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- Acked-by: Mark Salter <msal...@redhat.com> > > I ran into this by accident when trying to enable to the generic ioremap > implementation for 32-bit ARM. > > mm/early_ioremap.c | 1 + > 1 file changed, 1 inser

Re: [PATCH v2] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

is means we also need to > sort it first. > > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- Tested-by: Mark Salter <msal...@redhat.com> Reviewed-by: Mark Salter <msal...@redhat.com> > > As discussed off list, this is the arm64 side of what we shou

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote: > > > */ > > > - if (!buf || !buf[0]) > > > - if (IS_ENABLED(CONFIG_OF_FLATTREE)) > > > + if (!buf || !buf[0]) { > > > + if (!acpi_disabled) > > > > How do we know for sure that "acpi" has been parsed before

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote: > On Tue, Sep 08, 2015 at 12:38:59PM -0400, Mark Salter wrote: > > On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > > > The ACPI DBG2 table defines a debug console. Add support for parsing it > > > and

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > The ACPI DBG2 table defines a debug console. Add support for parsing it > and using it to select earlycon destination when no arguments provided. > > Signed-off-by: Leif Lindholm > --- > arch/arm64/kernel/acpi.c | 2 + >

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > The ACPI DBG2 table defines a debug console. Add support for parsing it > and using it to select earlycon destination when no arguments provided. > > Signed-off-by: Leif Lindholm > --- > arch/arm64/kernel/acpi.c

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > The ACPI DBG2 table defines a debug console. Add support for parsing it > and using it to select earlycon destination when no arguments provided. > > Signed-off-by: Leif Lindholm > --- > arch/arm64/kernel/acpi.c

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote: > On Tue, Sep 08, 2015 at 12:38:59PM -0400, Mark Salter wrote: > > On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > > > The ACPI DBG2 table defines a debug console. Add support for parsing it > > > and

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote: > On Tue, Sep 08, 2015 at 12:38:59PM -0400, Mark Salter wrote: > > On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote: > > > The ACPI DBG2 table defines a debug console. Add support for parsing it > > > and

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote: > > > */ > > > - if (!buf || !buf[0]) > > > - if (IS_ENABLED(CONFIG_OF_FLATTREE)) > > > + if (!buf || !buf[0]) { > > > + if (!acpi_disabled) > > > > How do we know for sure that "acpi" has been parsed before

Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support

On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote: > > > */ > > > - if (!buf || !buf[0]) > > > - if (IS_ENABLED(CONFIG_OF_FLATTREE)) > > > + if (!buf || !buf[0]) { > > > + if (!acpi_disabled) > > > > How do we know for sure that "acpi" has been parsed before

[PATCH] phylib: fix device deletion order in mdiobus_unregister()

bus device is deleted. Signed-off-by: Mark Salter --- drivers/net/phy/mdio_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 46a14cb..02a4615 100644 --- a/drivers/net/phy/mdio_bus.c +++ b/drivers/net/phy/mdio_bus.c

[PATCH] phylib: fix device deletion order in mdiobus_unregister()

bus device is deleted. Signed-off-by: Mark Salter <msal...@redhat.com> --- drivers/net/phy/mdio_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 46a14cb..02a4615 100644 --- a/drivers/net/phy/mdio_bus.c +++ b

[PATCH] phylib: fix device deletion order in mdiobus_unregister()

bus device is deleted. Signed-off-by: Mark Salter <msal...@redhat.com> --- drivers/net/phy/mdio_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 46a14cb..02a4615 100644 --- a/drivers/net/phy/mdio_bus.c +++ b

Re: [PATCH 3/3] efi/arm64: clean up efi_get_fdt_params() interface

On Wed, 2015-08-26 at 16:04 +0200, Ard Biesheuvel wrote: > On 26 August 2015 at 15:24, Leif Lindholm > wrote: > > As we now have a common debug infrastructure between core and arm64 > > efi, > > drop the bit of the interface passing verbose output flags around. > > > > Signed-off-by: Leif

Re: [PATCH 3/3] efi/arm64: clean up efi_get_fdt_params() interface

On Wed, 2015-08-26 at 16:04 +0200, Ard Biesheuvel wrote: On 26 August 2015 at 15:24, Leif Lindholm leif.lindh...@linaro.org wrote: As we now have a common debug infrastructure between core and arm64 efi, drop the bit of the interface passing verbose output flags around.

Re: [PATCH 3/3] efi/arm64: clean up efi_get_fdt_params() interface

On Wed, 2015-08-26 at 16:04 +0200, Ard Biesheuvel wrote: On 26 August 2015 at 15:24, Leif Lindholm leif.lindh...@linaro.org wrote: As we now have a common debug infrastructure between core and arm64 efi, drop the bit of the interface passing verbose output flags around.

Re: h8300 build failures in linux-next (in rcu code, gcc 5.x related, not limited to h8300)

On Tue, 2015-08-25 at 20:02 +0200, Oleg Nesterov wrote: > On 08/25, Oleg Nesterov wrote: > > > > On 08/26, Yoshinori Sato wrote: > > > > > > Yes. > > > gcc bug #67055. > > > Already fixed in trunk. > > > > Yes, thanks a lot. > > > > Paul, it seems that gcc actually dislikes your ec90a194a

Re: h8300 build failures ijn linux-next

On Tue, 2015-08-25 at 14:56 +0900, Yoshinori Sato wrote: > On Tue, 25 Aug 2015 03:34:20 +0900, > Guenter Roeck wrote: > > > > Hi, > > > > In linux-next as of today (0824), all h8300 builds fail for me with an > > internal > > compiler error. > > > > Building h8300:allnoconfig ... failed > >

Re: h8300 build failures ijn linux-next

On Tue, 2015-08-25 at 14:56 +0900, Yoshinori Sato wrote: On Tue, 25 Aug 2015 03:34:20 +0900, Guenter Roeck wrote: Hi, In linux-next as of today (0824), all h8300 builds fail for me with an internal compiler error. Building h8300:allnoconfig ... failed -- Error

Re: h8300 build failures in linux-next (in rcu code, gcc 5.x related, not limited to h8300)

On Tue, 2015-08-25 at 20:02 +0200, Oleg Nesterov wrote: On 08/25, Oleg Nesterov wrote: On 08/26, Yoshinori Sato wrote: Yes. gcc bug #67055. Already fixed in trunk. Yes, thanks a lot. Paul, it seems that gcc actually dislikes your ec90a194a rcu: Create a

[bug #45794] another EFI PXE boot problem

Follow-up Comment #2, bug #45794 (project grub): You're right. Sorry for the noise. I was debugging with a Fedora-patched version of upstream which erroneously adds the exclusive flag in grub_efi_net_config. I completely missed that and blamed the wrong party.

[PATCH V4 2/3] arm64: support initrd outside kernel linear map

The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure to boot. This patch catches that situation and relocates the initrd to be fully within the linear map. Signed-off-by: Mark Salter

[PATCH V4 3/3] x86: use generic early mem copy

The early_ioremap library now has a generic copy_from_early_mem() function. Use the generic copy function for x86 relocate_initrd(). Signed-off-by: Mark Salter --- arch/x86/kernel/setup.c | 22 +- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/arch/x86/kernel

[PATCH V4 1/3] mm: add utility for early copy from unmapped ram

In some early boot circumstances, it may be necessary to copy from RAM outside the kernel linear mapping to mapped RAM. The need to relocate an initrd is one example in the x86 code. This patch creates a helper function based on current x86 code. Signed-off-by: Mark Salter --- include/asm

[PATCH V4 0/3] mm: Add generic copy from early unmapped RAM

: * Change cover letter subject to highlight the added generic code * Add patch for x86 to use common copy_from_early_mem() Mark Salter (3): mm: add utility for early copy from unmapped ram arm64: support initrd outside kernel linear map x86: use generic early mem copy arch/arm64/kernel

Re: [PATCH V3 2/3] arm64: support initrd outside kernel linear map

On Mon, 2015-08-17 at 12:22 +0100, Will Deacon wrote: > Hi Mark, > > On Sun, Aug 16, 2015 at 09:49:27PM +0100, Mark Salter wrote: > > The use of mem= could leave part or all of the initrd outside of > > the kernel linear map. This will lead to an error when unpacking > >

Re: [PATCH V3 2/3] arm64: support initrd outside kernel linear map

On Mon, 2015-08-17 at 12:22 +0100, Will Deacon wrote: Hi Mark, On Sun, Aug 16, 2015 at 09:49:27PM +0100, Mark Salter wrote: The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure

[PATCH V4 3/3] x86: use generic early mem copy

The early_ioremap library now has a generic copy_from_early_mem() function. Use the generic copy function for x86 relocate_initrd(). Signed-off-by: Mark Salter msal...@redhat.com --- arch/x86/kernel/setup.c | 22 +- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git

[PATCH V4 2/3] arm64: support initrd outside kernel linear map

The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure to boot. This patch catches that situation and relocates the initrd to be fully within the linear map. Signed-off-by: Mark Salter

[PATCH V4 1/3] mm: add utility for early copy from unmapped ram

In some early boot circumstances, it may be necessary to copy from RAM outside the kernel linear mapping to mapped RAM. The need to relocate an initrd is one example in the x86 code. This patch creates a helper function based on current x86 code. Signed-off-by: Mark Salter msal...@redhat.com

[PATCH V4 0/3] mm: Add generic copy from early unmapped RAM

: * Change cover letter subject to highlight the added generic code * Add patch for x86 to use common copy_from_early_mem() Mark Salter (3): mm: add utility for early copy from unmapped ram arm64: support initrd outside kernel linear map x86: use generic early mem copy arch/arm64/kernel

[PATCH V3 3/3] x86: use generic early mem copy

The early_ioremap library now has a generic copy_from_early_mem() function. Use the generic copy function for x86 relocate_initrd(). Signed-off-by: Mark Salter --- arch/x86/kernel/setup.c | 22 +- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/arch/x86/kernel

[PATCH V3 2/3] arm64: support initrd outside kernel linear map

The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure to boot. This patch catches that situation and relocates the initrd to be fully within the linear map. Signed-off-by: Mark Salter

[PATCH V3 1/3] mm: add utility for early copy from unmapped ram

In some early boot circumstances, it may be necessary to copy from RAM outside the kernel linear mapping to mapped RAM. The need to relocate an initrd is one example in the x86 code. This patch creates a helper function based on current x86 code. Signed-off-by: Mark Salter --- include/asm

[PATCH V3 0/3] mm: Add generic copy from early unmapped RAM

in copy_from_early_mem() * Removed unneeded MAX_MAP_CHUNK from x86 setup.c * Moved #ifdef outside arm64 relocate_initrd() definition. Changes from V1: * Change cover letter subject to highlight the added generic code * Add patch for x86 to use common copy_from_early_mem() Mark Salter

[PATCH V3 3/3] x86: use generic early mem copy

The early_ioremap library now has a generic copy_from_early_mem() function. Use the generic copy function for x86 relocate_initrd(). Signed-off-by: Mark Salter msal...@redhat.com --- arch/x86/kernel/setup.c | 22 +- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git

[PATCH V3 2/3] arm64: support initrd outside kernel linear map

The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure to boot. This patch catches that situation and relocates the initrd to be fully within the linear map. Signed-off-by: Mark Salter

[PATCH V3 1/3] mm: add utility for early copy from unmapped ram

In some early boot circumstances, it may be necessary to copy from RAM outside the kernel linear mapping to mapped RAM. The need to relocate an initrd is one example in the x86 code. This patch creates a helper function based on current x86 code. Signed-off-by: Mark Salter msal...@redhat.com

[PATCH V3 0/3] mm: Add generic copy from early unmapped RAM

in copy_from_early_mem() * Removed unneeded MAX_MAP_CHUNK from x86 setup.c * Moved #ifdef outside arm64 relocate_initrd() definition. Changes from V1: * Change cover letter subject to highlight the added generic code * Add patch for x86 to use common copy_from_early_mem() Mark Salter

[PATCH V2 1/3] mm: add utility for early copy from unmapped ram

In some early boot circumstances, it may be necessary to copy from RAM outside the kernel linear mapping to mapped RAM. The need to relocate an initrd is one example in the x86 code. This patch creates a helper function based on current x86 code. Signed-off-by: Mark Salter --- include/asm

[PATCH V2 2/3] arm64: support initrd outside kernel linear map

The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure to boot. This patch catches that situation and relocates the initrd to be fully within the linear map. Signed-off-by: Mark Salter

[PATCH V2 3/3] x86: use generic early mem copy

The early_ioremap library now has a generic copy_from_early_mem() function. Use the generic copy function for x86 relocate_initrd(). Signed-off-by: Mark Salter --- arch/x86/kernel/setup.c | 21 + 1 file changed, 1 insertion(+), 20 deletions(-) diff --git a/arch/x86/kernel

[PATCH V2 0/3] mm: Add generic copy from early unmapped RAM

subject to highlight the added generic code * Add patch for x86 to use common copy_from_early_mem() Mark Salter (3): mm: add utility for early copy from unmapped ram arm64: support initrd outside kernel linear map x86: use generic early mem copy arch/arm64/kernel/setup.c | 55

[PATCH V2 2/3] arm64: support initrd outside kernel linear map

The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure to boot. This patch catches that situation and relocates the initrd to be fully within the linear map. Signed-off-by: Mark Salter

[PATCH V2 0/3] mm: Add generic copy from early unmapped RAM

subject to highlight the added generic code * Add patch for x86 to use common copy_from_early_mem() Mark Salter (3): mm: add utility for early copy from unmapped ram arm64: support initrd outside kernel linear map x86: use generic early mem copy arch/arm64/kernel/setup.c | 55

[PATCH V2 3/3] x86: use generic early mem copy

The early_ioremap library now has a generic copy_from_early_mem() function. Use the generic copy function for x86 relocate_initrd(). Signed-off-by: Mark Salter msal...@redhat.com --- arch/x86/kernel/setup.c | 21 + 1 file changed, 1 insertion(+), 20 deletions(-) diff --git

[PATCH V2 1/3] mm: add utility for early copy from unmapped ram

In some early boot circumstances, it may be necessary to copy from RAM outside the kernel linear mapping to mapped RAM. The need to relocate an initrd is one example in the x86 code. This patch creates a helper function based on current x86 code. Signed-off-by: Mark Salter msal...@redhat.com

[no subject]

unsubscribe devicetree -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] arm64: support initrd outside of mapped RAM

orrected that for this reply. Oops. Thanks. > > On Tue, Jul 28, 2015 at 03:32:39PM +0100, Mark Salter wrote: > > When booting an arm64 kernel w/initrd using UEFI/grub, use of mem= will > > likely > > cut off part or all of the initrd. This leaves it outside the kernel >

[PATCH 1/2] mm: add utility for early copy from unmapped ram

In some early boot circumstances, it may be necessary to copy from RAM outside the kernel linear mapping to mapped RAM. The need to relocate an initrd is one example in the x86 code. This patch creates a helper function based on current x86 code. Signed-off-by: Mark Salter --- include/asm

[PATCH 0/2] arm64: support initrd outside of mapped RAM

. The current x86 code uses early_memremap() to copy the original initrd from unmapped to mapped RAM. This patchset creates a generic copy_from_early_mem() utility based on that x86 code and has arm64 use it to relocate the initrd if necessary. Mark Salter (2): mm: add utility for early copy from

[PATCH 2/2] arm64: support initrd outside kernel linear map

The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure to boot. This patch catches that situation and relocates the initrd to be fully within the linear map. Signed-off-by: Mark Salter

[PATCH 2/2] arm64: support initrd outside kernel linear map

The use of mem= could leave part or all of the initrd outside of the kernel linear map. This will lead to an error when unpacking the initrd and a probable failure to boot. This patch catches that situation and relocates the initrd to be fully within the linear map. Signed-off-by: Mark Salter

[PATCH 1/2] mm: add utility for early copy from unmapped ram

In some early boot circumstances, it may be necessary to copy from RAM outside the kernel linear mapping to mapped RAM. The need to relocate an initrd is one example in the x86 code. This patch creates a helper function based on current x86 code. Signed-off-by: Mark Salter msal...@redhat.com

[PATCH 0/2] arm64: support initrd outside of mapped RAM

. The current x86 code uses early_memremap() to copy the original initrd from unmapped to mapped RAM. This patchset creates a generic copy_from_early_mem() utility based on that x86 code and has arm64 use it to relocate the initrd if necessary. Mark Salter (2): mm: add utility for early copy from

Re: [PATCH 0/2] arm64: support initrd outside of mapped RAM

. On Tue, Jul 28, 2015 at 03:32:39PM +0100, Mark Salter wrote: When booting an arm64 kernel w/initrd using UEFI/grub, use of mem= will likely cut off part or all of the initrd. This leaves it outside the kernel linear map which leads to failure when unpacking. The x86 code has

Re: [PATCH 1/1] mm, mpx: add "vm_flags_t vm_flags" arg to do_mmap_pgoff()

On Fri, 2015-07-24 at 10:39 -0400, Paul Gortmaker wrote: > On Thu, Jul 16, 2015 at 6:26 PM, Oleg Nesterov wrote: > > Add the additional "vm_flags_t vm_flags" argument to do_mmap_pgoff(), > > rename it to do_mmap(), and re-introduce do_mmap_pgoff() as a simple > > wrapper on top of do_mmap().

Re: [PATCH 1/1] mm, mpx: add vm_flags_t vm_flags arg to do_mmap_pgoff()

On Fri, 2015-07-24 at 10:39 -0400, Paul Gortmaker wrote: On Thu, Jul 16, 2015 at 6:26 PM, Oleg Nesterov o...@redhat.com wrote: Add the additional vm_flags_t vm_flags argument to do_mmap_pgoff(), rename it to do_mmap(), and re-introduce do_mmap_pgoff() as a simple wrapper on top of

[PATCH] arm64: remove dead code

Commit 68234df4ea79 ("arm64: kill flush_cache_all()") removed soft_reset() from the kernel. This was the only caller of setup_mm_for_reboot(), so remove that also. Signed-off-by: Mark Salter --- arch/arm64/include/asm/mmu.h | 1 - arch/arm64/mm/mmu.c | 11 --- 2 fil

[PATCH] arm64: remove dead code

Commit 68234df4ea79 (arm64: kill flush_cache_all()) removed soft_reset() from the kernel. This was the only caller of setup_mm_for_reboot(), so remove that also. Signed-off-by: Mark Salter msal...@redhat.com --- arch/arm64/include/asm/mmu.h | 1 - arch/arm64/mm/mmu.c | 11

Re: [PATCH] c67: irq: don't reimplement __handle_domain_irq()

On Tue, 2015-06-23 at 16:59 -0500, Felipe Balbi wrote: > c6x_do_IRQ() had a reimplementation of > __handle_domain_irq(), instead just call > that. Actually, the other way around. The __handle_domain_irq() function is relatively recent compared to the c6x code. Anyway, your patch needed a "select

Re: [PATCH] c67: irq: don't reimplement __handle_domain_irq()

On Tue, 2015-06-23 at 16:59 -0500, Felipe Balbi wrote: c6x_do_IRQ() had a reimplementation of __handle_domain_irq(), instead just call that. Actually, the other way around. The __handle_domain_irq() function is relatively recent compared to the c6x code. Anyway, your patch needed a select

[bug #45204] EFI PXE boot fails for some firmware

Follow-up Comment #7, bug #45204 (project grub): Works for me. Thanks! ___ Reply to this item at: http://savannah.gnu.org/bugs/?45204 ___ Message sent via/by Savannah

Re: [PATCH] efi: Work around ia64 build problem with ESRT driver.

On Mon, 2015-06-08 at 11:09 +0100, Matt Fleming wrote: > On Fri, 05 Jun, at 03:14:54PM, Peter Jones wrote: > > So, I'm told this problem exists in the world: > > -- > > Subject: Build error in -next due to 'efi: Add esrt support' > > > > Building

Re: [PATCH v3] ARM: early fixmap support for earlycon

On Sat, 2015-06-06 at 10:29 -0500, Rob Herring wrote: > On Sat, Jun 6, 2015 at 8:29 AM, Stefan Agner wrote: > > On 2015-06-06 14:48, Russell King - ARM Linux wrote: > >> On Sat, Jun 06, 2015 at 02:31:28PM +0200, Stefan Agner wrote: > > > >>> --- a/arch/arm/include/asm/fixmap.h > >>> +++

Re: [PATCH v3] ARM: early fixmap support for earlycon

On Sat, 2015-06-06 at 10:29 -0500, Rob Herring wrote: On Sat, Jun 6, 2015 at 8:29 AM, Stefan Agner ste...@agner.ch wrote: On 2015-06-06 14:48, Russell King - ARM Linux wrote: On Sat, Jun 06, 2015 at 02:31:28PM +0200, Stefan Agner wrote: snip --- a/arch/arm/include/asm/fixmap.h +++

Re: [PATCH] efi: Work around ia64 build problem with ESRT driver.

On Mon, 2015-06-08 at 11:09 +0100, Matt Fleming wrote: On Fri, 05 Jun, at 03:14:54PM, Peter Jones wrote: So, I'm told this problem exists in the world: -- Subject: Build error in -next due to 'efi: Add esrt support' Building ia64:defconfig

Re: [PATCH] efi: Work around ia64 build problem with ESRT driver.

On Mon, 2015-06-08 at 11:09 +0100, Matt Fleming wrote: On Fri, 05 Jun, at 03:14:54PM, Peter Jones wrote: So, I'm told this problem exists in the world: -- Subject: Build error in -next due to 'efi: Add esrt support' Building ia64:defconfig

Re: [RFT v2 23/48] c6x, irq: Prepare for killing the first parameter 'irq' of irq_flow_handler_t

5 deletions(-) Acked-by: Mark Salter -- 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: [RFT v2 43/48] genirq, arch: Kill the first parameter 'irq' of irq_flow_handler_t

- > arch/tile/kernel/pci_gx.c |4 ++-- > arch/unicore32/kernel/irq.c |2 +- > 9 files changed, 10 insertions(+), 10 deletions(-) For c6x: Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [RFT v2 43/48] genirq, arch: Kill the first parameter 'irq' of irq_flow_handler_t

|4 ++-- arch/unicore32/kernel/irq.c |2 +- 9 files changed, 10 insertions(+), 10 deletions(-) For c6x: Acked-by: Mark Salter msal...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More

Re: [RFT v2 23/48] c6x, irq: Prepare for killing the first parameter 'irq' of irq_flow_handler_t

deletions(-) Acked-by: Mark Salter msal...@redhat.com -- 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 0/8] Consolidate ACPI PCI root common code into ACPI core

On Fri, 2015-06-05 at 00:29 +0800, Jiang Liu wrote: > On 2015/6/4 23:51, Mark Salter wrote: > > On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote: > >> On 2015/6/4 14:31, Hanjun Guo wrote: > >>> Hi Jiang, > >>> > >>> On 2015年06月04日 09:54, Ji

Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core

On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote: > On 2015/6/4 14:31, Hanjun Guo wrote: > > Hi Jiang, > > > > On 2015年06月04日 09:54, Jiang Liu wrote: > >> On 2015/6/4 4:27, Al Stone wrote: > >>> On 06/02/2015 12:12 AM, Jiang Liu wrote: > This patch set consolidates common code to support

Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core

On Fri, 2015-06-05 at 00:29 +0800, Jiang Liu wrote: On 2015/6/4 23:51, Mark Salter wrote: On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote: On 2015/6/4 14:31, Hanjun Guo wrote: Hi Jiang, On 2015年06月04日 09:54, Jiang Liu wrote: On 2015/6/4 4:27, Al Stone wrote: On 06/02/2015 12:12

Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core

On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote: On 2015/6/4 14:31, Hanjun Guo wrote: Hi Jiang, On 2015年06月04日 09:54, Jiang Liu wrote: On 2015/6/4 4:27, Al Stone wrote: On 06/02/2015 12:12 AM, Jiang Liu wrote: This patch set consolidates common code to support ACPI PCI root on x86

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On Wed, 2015-06-03 at 09:37 -0500, Suravee Suthikulanit wrote: > On 5/28/2015 9:38 PM, Mark Salter wrote: > > On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote: > >> >Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, > >> >se

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On Wed, 2015-06-03 at 09:37 -0500, Suravee Suthikulanit wrote: On 5/28/2015 9:38 PM, Mark Salter wrote: On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote: Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On Wed, 2015-06-03 at 09:37 -0500, Suravee Suthikulanit wrote: On 5/28/2015 9:38 PM, Mark Salter wrote: On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote: Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On Wed, 2015-06-03 at 09:37 -0500, Suravee Suthikulanit wrote: On 5/28/2015 9:38 PM, Mark Salter wrote: On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote: Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On Wed, 2015-06-03 at 09:37 -0500, Suravee Suthikulanit wrote: On 5/28/2015 9:38 PM, Mark Salter wrote: On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote: Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

t; specifies ACPI_CCA_REQUIRED in arm64 Kconfig. > > In addition, to handle the case when _CCA is missing, arm64 would assign > dummy_dma_ops to disable DMA capability of the device. > > Acked-by: Catalin Marinas > Signed-off-by: Mark Salter > Signed-off-by: Suravee Suthikulp

[bug #45204] EFI PXE boot fails for some firmware

Follow-up Comment #5, bug #45204 (project grub): I added code to dump the filter info: +static void dump_snp_filter(grub_efi_simple_network_t *net) +{ + struct grub_efi_simple_network_mode *m = net-mode; + int i; + + grub_dprintf(efi, FilterMask[%x] FilterSetting[%x]

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

ACPI_CCA_REQUIRED in arm64 Kconfig. In addition, to handle the case when _CCA is missing, arm64 would assign dummy_dma_ops to disable DMA capability of the device. Acked-by: Catalin Marinas catalin.mari...@arm.com Signed-off-by: Mark Salter msal...@redhat.com Signed-off-by: Suravee Suthikulpanit

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

ACPI_CCA_REQUIRED in arm64 Kconfig. In addition, to handle the case when _CCA is missing, arm64 would assign dummy_dma_ops to disable DMA capability of the device. Acked-by: Catalin Marinas catalin.mari...@arm.com Signed-off-by: Mark Salter msal...@redhat.com Signed-off-by: Suravee Suthikulpanit

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

ACPI_CCA_REQUIRED in arm64 Kconfig. In addition, to handle the case when _CCA is missing, arm64 would assign dummy_dma_ops to disable DMA capability of the device. Acked-by: Catalin Marinas catalin.mari...@arm.com Signed-off-by: Mark Salter msal...@redhat.com Signed-off-by: Suravee Suthikulpanit

[bug #45204] EFI PXE boot fails for some firmware

: Major Priority: 5 - Normal Item Group: Software Error Status: None Privacy: Public Assigned to: None Originator Name: Mark Salter Originator Email: msal...@redhat.com Open/Closed: Open

[bug #45204] EFI PXE boot fails for some firmware

Additional Item Attachment, bug #45204 (project grub): File name: efinet-save-and-restore-SNP-rx-filters.patch Size:2 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?45204 ___

[bug #45204] EFI PXE boot fails for some firmware

Follow-up Comment #3, bug #45204 (project grub): I originally did explicitly add UNICAST/BROADCAST rather than previous settings. But I wasn't sure if MULTICAST would be needed since ipv6 was supported on the platform. MULTICAST was allowed for both ipv4 and ipv6, so I ended up saving/restoring

Re: [PATCH] arm64: support ACPI tables outside of kernel RAM

On Fri, 2015-05-22 at 11:34 +0100, Catalin Marinas wrote: > On Mon, May 18, 2015 at 06:49:28PM +0200, Ard Biesheuvel wrote: > > On 18 May 2015 at 18:41, Catalin Marinas wrote: > > > On Mon, May 18, 2015 at 09:58:45AM -0400, Mark Salter wrote: > > >> On Mon, 2015

Re: [PATCH] arm64: support ACPI tables outside of kernel RAM

On Fri, 2015-05-22 at 13:53 +0100, Catalin Marinas wrote: > On Fri, May 22, 2015 at 08:46:02AM -0400, Mark Salter wrote: > > On Fri, 2015-05-22 at 11:34 +0100, Catalin Marinas wrote: > > > OK, so my preferred options, in this order: > > > > > > 1. Change the

Re: [PATCH] arm64: support ACPI tables outside of kernel RAM

On Fri, 2015-05-22 at 11:34 +0100, Catalin Marinas wrote: > On Mon, May 18, 2015 at 06:49:28PM +0200, Ard Biesheuvel wrote: > > On 18 May 2015 at 18:41, Catalin Marinas wrote: > > > On Mon, May 18, 2015 at 09:58:45AM -0400, Mark Salter wrote: > > >> On Mon, 2015

Re: [PATCH] arm64: support ACPI tables outside of kernel RAM

On Fri, 2015-05-22 at 11:34 +0100, Catalin Marinas wrote: On Mon, May 18, 2015 at 06:49:28PM +0200, Ard Biesheuvel wrote: On 18 May 2015 at 18:41, Catalin Marinas catalin.mari...@arm.com wrote: On Mon, May 18, 2015 at 09:58:45AM -0400, Mark Salter wrote: On Mon, 2015-05-18 at 12:11 +0100

<    1   2   3   4   5   6   7   8   9   10   >