* Re: linux-next: build failure after merge of the kvm-ppc tree
From: Alexander Graf @ 2012-05-16 9:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20120516091501.GA30694@bloggs.ozlabs.ibm.com>
On 05/16/2012 11:15 AM, Paul Mackerras wrote:
> On Wed, May 16, 2012 at 05:24:16PM +1000, Stephen Rothwell wrote:
>> Hi Alexander,
>>
>> After merging the kvm-ppc tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> ERROR: "kvm_hpt_order" [arch/powerpc/kvm/kvm.ko] undefined!
>>
>> Caused by commit ec26346431bb ("KVM: PPC: Book3S HV: Make the guest hash
>> table size configurable").
> Oops, my fault, kvm_hpt_order needs to be exported for when KVM is
> a module. Patch coming.
Fixed in kvm-ppc-next. Sorry for the noise.
Alex
^ permalink raw reply
* Re: linux-next: build failure after merge of the kvm-ppc tree
From: Paul Mackerras @ 2012-05-16 9:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Alexander Graf, linux-next, linux-kernel
In-Reply-To: <20120516172416.781859dbc2febbda67407576@canb.auug.org.au>
On Wed, May 16, 2012 at 05:24:16PM +1000, Stephen Rothwell wrote:
> Hi Alexander,
>
> After merging the kvm-ppc tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ERROR: "kvm_hpt_order" [arch/powerpc/kvm/kvm.ko] undefined!
>
> Caused by commit ec26346431bb ("KVM: PPC: Book3S HV: Make the guest hash
> table size configurable").
Oops, my fault, kvm_hpt_order needs to be exported for when KVM is
a module. Patch coming.
Paul.
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the staging tree
From: Stephen Rothwell @ 2012-05-16 8:58 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Maxime Ripard, Greg KH,
Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/at91sam9g20.dtsi between commit 7cb2e629a240 ("ARM:
AT91: Add ADC driver to the at91sam9g20 dtsi") from the staging tree and
commit 5b6089cb6f28 ("ARM: at91: add at91sam9260 DT support") from the
arm-soc tree.
So, I didn't know what to do with this, so I used the arm-soc version of
this file (effectively throwing away the staging tree change). Hints,
anyone?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2012-05-16 8:50 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Haojian Zhuang, Russell King
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/Kconfig between commit 98fab064d321 ("ARM: Remove unnecessary
selection of TICK_ONESHOT") from the arm tree and commit c24b31147a06
("ARM: mmp: support DT in irq") from the arm-soc tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/Kconfig
index b1a717c,852b12b..0000000
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -627,6 -616,8 +611,7 @@@ config ARCH_MM
select CLKDEV_LOOKUP
select GENERIC_CLOCKEVENTS
select GPIO_PXA
+ select IRQ_DOMAIN
- select TICK_ONESHOT
select PLAT_PXA
select SPARSE_IRQ
select GENERIC_ALLOCATOR
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the gpio tree with the s5p tree
From: Stephen Rothwell @ 2012-05-16 8:43 UTC (permalink / raw)
To: Grant Likely
Cc: linux-next, linux-kernel, Sangsu Park, Thomas Abraham, Kukjin Kim,
Olof Johansson
[-- Attachment #1: Type: text/plain, Size: 6852 bytes --]
Hi Grant,
Today's linux-next merge of the gpio tree got a conflict in
drivers/gpio/gpio-samsung.c between commit ef04afd5451b ("ARM: EXYNOS:
add GPC4 bank instance") from the s5p tree and commit fd454997d687
("gpio: samsung: refactor gpiolib init for exynos4/5") from the gpio tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/gpio/gpio-samsung.c
index f88bb9f,5d49aff..0000000
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@@ -2722,6 -2714,219 +2722,222 @@@ static __init void exynos_gpiolib_attac
}
#endif /* defined(CONFIG_ARCH_EXYNOS) && defined(CONFIG_OF) */
+ static __init void exynos4_gpiolib_init(void)
+ {
+ #ifdef CONFIG_CPU_EXYNOS4210
+ struct samsung_gpio_chip *chip;
+ int i, nr_chips;
+ void __iomem *gpio_base1, *gpio_base2, *gpio_base3;
+ int group = 0;
+ void __iomem *gpx_base;
+
+ /* gpio part1 */
+ gpio_base1 = ioremap(EXYNOS4_PA_GPIO1, SZ_4K);
+ if (gpio_base1 == NULL) {
+ pr_err("unable to ioremap for gpio_base1\n");
+ goto err_ioremap1;
+ }
+
+ chip = exynos4_gpios_1;
+ nr_chips = ARRAY_SIZE(exynos4_gpios_1);
+
+ for (i = 0; i < nr_chips; i++, chip++) {
+ if (!chip->config) {
+ chip->config = &exynos_gpio_cfg;
+ chip->group = group++;
+ }
+ exynos_gpiolib_attach_ofnode(chip,
+ EXYNOS4_PA_GPIO1, i * 0x20);
+ }
+ samsung_gpiolib_add_4bit_chips(exynos4_gpios_1,
+ nr_chips, gpio_base1);
+
+ /* gpio part2 */
+ gpio_base2 = ioremap(EXYNOS4_PA_GPIO2, SZ_4K);
+ if (gpio_base2 == NULL) {
+ pr_err("unable to ioremap for gpio_base2\n");
+ goto err_ioremap2;
+ }
+
+ /* need to set base address for gpx */
+ chip = &exynos4_gpios_2[16];
+ gpx_base = gpio_base2 + 0xC00;
+ for (i = 0; i < 4; i++, chip++, gpx_base += 0x20)
+ chip->base = gpx_base;
+
+ chip = exynos4_gpios_2;
+ nr_chips = ARRAY_SIZE(exynos4_gpios_2);
+
+ for (i = 0; i < nr_chips; i++, chip++) {
+ if (!chip->config) {
+ chip->config = &exynos_gpio_cfg;
+ chip->group = group++;
+ }
+ exynos_gpiolib_attach_ofnode(chip,
+ EXYNOS4_PA_GPIO2, i * 0x20);
+ }
+ samsung_gpiolib_add_4bit_chips(exynos4_gpios_2,
+ nr_chips, gpio_base2);
+
+ /* gpio part3 */
+ gpio_base3 = ioremap(EXYNOS4_PA_GPIO3, SZ_256);
+ if (gpio_base3 == NULL) {
+ pr_err("unable to ioremap for gpio_base3\n");
+ goto err_ioremap3;
+ }
+
+ chip = exynos4_gpios_3;
+ nr_chips = ARRAY_SIZE(exynos4_gpios_3);
+
+ for (i = 0; i < nr_chips; i++, chip++) {
+ if (!chip->config) {
+ chip->config = &exynos_gpio_cfg;
+ chip->group = group++;
+ }
+ exynos_gpiolib_attach_ofnode(chip,
+ EXYNOS4_PA_GPIO3, i * 0x20);
+ }
+ samsung_gpiolib_add_4bit_chips(exynos4_gpios_3,
+ nr_chips, gpio_base3);
+
+ #if defined(CONFIG_CPU_EXYNOS4210) && defined(CONFIG_S5P_GPIO_INT)
+ s5p_register_gpioint_bank(IRQ_GPIO_XA, 0, IRQ_GPIO1_NR_GROUPS);
+ s5p_register_gpioint_bank(IRQ_GPIO_XB, IRQ_GPIO1_NR_GROUPS, IRQ_GPIO2_NR_GROUPS);
+ #endif
+
+ return;
+
+ err_ioremap3:
+ iounmap(gpio_base2);
+ err_ioremap2:
+ iounmap(gpio_base1);
+ err_ioremap1:
+ return;
+ #endif /* CONFIG_CPU_EXYNOS4210 */
+ }
+
+ static __init void exynos5_gpiolib_init(void)
+ {
+ #ifdef CONFIG_SOC_EXYNOS5250
+ struct samsung_gpio_chip *chip;
+ int i, nr_chips;
+ void __iomem *gpio_base1, *gpio_base2, *gpio_base3, *gpio_base4;
+ int group = 0;
+ void __iomem *gpx_base;
+
+ /* gpio part1 */
+ gpio_base1 = ioremap(EXYNOS5_PA_GPIO1, SZ_4K);
+ if (gpio_base1 == NULL) {
+ pr_err("unable to ioremap for gpio_base1\n");
+ goto err_ioremap1;
+ }
+
++ /* need to set base address for gpc4 */
++ exynos5_gpios_1[11].base = gpio_base1 + 0x2E0;
++
+ /* need to set base address for gpx */
- chip = &exynos5_gpios_1[20];
++ chip = &exynos5_gpios_1[21];
+ gpx_base = gpio_base1 + 0xC00;
+ for (i = 0; i < 4; i++, chip++, gpx_base += 0x20)
+ chip->base = gpx_base;
+
+ chip = exynos5_gpios_1;
+ nr_chips = ARRAY_SIZE(exynos5_gpios_1);
+
+ for (i = 0; i < nr_chips; i++, chip++) {
+ if (!chip->config) {
+ chip->config = &exynos_gpio_cfg;
+ chip->group = group++;
+ }
+ exynos_gpiolib_attach_ofnode(chip,
+ EXYNOS5_PA_GPIO1, i * 0x20);
+ }
+ samsung_gpiolib_add_4bit_chips(exynos5_gpios_1,
+ nr_chips, gpio_base1);
+
+ /* gpio part2 */
+ gpio_base2 = ioremap(EXYNOS5_PA_GPIO2, SZ_4K);
+ if (gpio_base2 == NULL) {
+ pr_err("unable to ioremap for gpio_base2\n");
+ goto err_ioremap2;
+ }
+
+ chip = exynos5_gpios_2;
+ nr_chips = ARRAY_SIZE(exynos5_gpios_2);
+
+ for (i = 0; i < nr_chips; i++, chip++) {
+ if (!chip->config) {
+ chip->config = &exynos_gpio_cfg;
+ chip->group = group++;
+ }
+ exynos_gpiolib_attach_ofnode(chip,
+ EXYNOS5_PA_GPIO2, i * 0x20);
+ }
+ samsung_gpiolib_add_4bit_chips(exynos5_gpios_2,
+ nr_chips, gpio_base2);
+
+ /* gpio part3 */
+ gpio_base3 = ioremap(EXYNOS5_PA_GPIO3, SZ_4K);
+ if (gpio_base3 == NULL) {
+ pr_err("unable to ioremap for gpio_base3\n");
+ goto err_ioremap3;
+ }
+
+ /* need to set base address for gpv */
+ exynos5_gpios_3[0].base = gpio_base3;
+ exynos5_gpios_3[1].base = gpio_base3 + 0x20;
+ exynos5_gpios_3[2].base = gpio_base3 + 0x60;
+ exynos5_gpios_3[3].base = gpio_base3 + 0x80;
+ exynos5_gpios_3[4].base = gpio_base3 + 0xC0;
+
+ chip = exynos5_gpios_3;
+ nr_chips = ARRAY_SIZE(exynos5_gpios_3);
+
+ for (i = 0; i < nr_chips; i++, chip++) {
+ if (!chip->config) {
+ chip->config = &exynos_gpio_cfg;
+ chip->group = group++;
+ }
+ exynos_gpiolib_attach_ofnode(chip,
+ EXYNOS5_PA_GPIO3, i * 0x20);
+ }
+ samsung_gpiolib_add_4bit_chips(exynos5_gpios_3,
+ nr_chips, gpio_base3);
+
+ /* gpio part4 */
+ gpio_base4 = ioremap(EXYNOS5_PA_GPIO4, SZ_4K);
+ if (gpio_base4 == NULL) {
+ pr_err("unable to ioremap for gpio_base4\n");
+ goto err_ioremap4;
+ }
+
+ chip = exynos5_gpios_4;
+ nr_chips = ARRAY_SIZE(exynos5_gpios_4);
+
+ for (i = 0; i < nr_chips; i++, chip++) {
+ if (!chip->config) {
+ chip->config = &exynos_gpio_cfg;
+ chip->group = group++;
+ }
+ exynos_gpiolib_attach_ofnode(chip,
+ EXYNOS5_PA_GPIO4, i * 0x20);
+ }
+ samsung_gpiolib_add_4bit_chips(exynos5_gpios_4,
+ nr_chips, gpio_base4);
+ return;
+
+ err_ioremap4:
+ iounmap(gpio_base3);
+ err_ioremap3:
+ iounmap(gpio_base2);
+ err_ioremap2:
+ iounmap(gpio_base1);
+ err_ioremap1:
+ return;
+
+ #endif /* CONFIG_SOC_EXYNOS5250 */
+ }
+
/* TODO: cleanup soc_is_* */
static __init int samsung_gpiolib_init(void)
{
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the usb tree with the s5p tree
From: Stephen Rothwell @ 2012-05-16 8:03 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Marek Szyprowski, Kyungmin Park,
Kukjin Kim, Lukasz Majewski
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
arch/arm/mach-exynos/mach-universal_c210.c between commit 6dafa4aead1b
("ARM: EXYNOS: Add DRM core device support for Universal C210 board")
from the s5p tree and commit 126625e1bf32 ("usb:hsotg:samsung:cosmetic
Move <linux/platform_data/s3c-hsotg.h> to proper place") from the usb
tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-exynos/mach-universal_c210.c
index dd8ec8d4,bc8bf3b..0000000
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@@ -23,7 -23,7 +23,8 @@@
#include <linux/i2c-gpio.h>
#include <linux/i2c/mcs.h>
#include <linux/i2c/atmel_mxt_ts.h>
+ #include <linux/platform_data/s3c-hsotg.h>
+#include <drm/exynos_drm.h>
#include <asm/mach/arch.h>
#include <asm/hardware/gic.h>
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree with the tip tree
From: Gleb Natapov @ 2012-05-16 7:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Avi Kivity, Marcelo Tosatti, linux-next, linux-kernel, Alan Cox,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20120516171435.3b0a9c8a531081ff290763aa@canb.auug.org.au>
On Wed, May 16, 2012 at 05:14:35PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvm tree got a conflict in
> arch/x86/include/asm/kvm_para.h between commit c3709e6734da ("x86, kvm:
> KVM paravirt kernels don't check for CPUID being unavailable") from the
> tip tree and commit 9b72d3b07dd9 ("KVM guest: make kvm_para_available()
> check hypervisor bit reading cpuid leaf") from the kvm tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Fix looks good to me.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc arch/x86/include/asm/kvm_para.h
> index 183922e,a7a7a94..0000000
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@@ -170,17 -178,16 +178,19 @@@ static inline int kvm_para_available(vo
> unsigned int eax, ebx, ecx, edx;
> char signature[13];
>
> + if (boot_cpu_data.cpuid_level < 0)
> + return 0; /* So we don't blow up on old processors */
> +
> - cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
> - memcpy(signature + 0, &ebx, 4);
> - memcpy(signature + 4, &ecx, 4);
> - memcpy(signature + 8, &edx, 4);
> - signature[12] = 0;
> + if (cpu_has_hypervisor) {
> + cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
> + memcpy(signature + 0, &ebx, 4);
> + memcpy(signature + 4, &ecx, 4);
> + memcpy(signature + 8, &edx, 4);
> + signature[12] = 0;
>
> - if (strcmp(signature, "KVMKVMKVM") == 0)
> - return 1;
> + if (strcmp(signature, "KVMKVMKVM") == 0)
> + return 1;
> + }
>
> return 0;
> }
--
Gleb.
^ permalink raw reply
* linux-next: manual merge of the percpu tree with the tip tree
From: Stephen Rothwell @ 2012-05-16 7:36 UTC (permalink / raw)
To: Tejun Heo, Rusty Russell, Christoph Lameter
Cc: linux-next, linux-kernel, Suresh Siddha, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Alex Shi
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]
Hi all,
Today's linux-next merge of the percpu tree got a conflict in
arch/x86/mm/tlb.c between commit a6fca40f1d7f ("x86, tlb: Switch cr3 in
leave_mm() only when needed") from the tip tree and commit c6ae41e7d469
("x86: replace percpu_xxx funcs with this_cpu_xxx") from the percpu tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/mm/tlb.c
index 125bcad,3804471..0000000
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@@ -61,13 -61,11 +61,13 @@@ static DEFINE_PER_CPU_READ_MOSTLY(int,
*/
void leave_mm(int cpu)
{
- struct mm_struct *active_mm = percpu_read(cpu_tlbstate.active_mm);
- if (percpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
++ struct mm_struct *active_mm = this_cpu_read(cpu_tlbstate.active_mm);
+ if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
BUG();
- cpumask_clear_cpu(cpu,
- mm_cpumask(this_cpu_read(cpu_tlbstate.active_mm)));
- load_cr3(swapper_pg_dir);
+ if (cpumask_test_cpu(cpu, mm_cpumask(active_mm))) {
+ cpumask_clear_cpu(cpu, mm_cpumask(active_mm));
+ load_cr3(swapper_pg_dir);
+ }
}
EXPORT_SYMBOL_GPL(leave_mm);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the crypto tree with the arm tree
From: Linus Walleij @ 2012-05-16 7:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Herbert Xu, linux-next, linux-kernel, Russell King,
Andreas Westin
In-Reply-To: <20120516151441.59baed915e31738642fd52dd@canb.auug.org.au>
On Wed, May 16, 2012 at 7:14 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the crypto tree got a conflict in
> arch/arm/mach-ux500/devices-common.h between commit 08956a0e8a69 ("ARM:
> 7372/1: ux500: factor out dynamic amba device allocator") from the tree
> and commit 585d188f8072 ("mach-ux500: crypto - core support for CRYP/HASH
> module") from the crypto tree.
>
> Just context changes (maybe). I fixed it up (see below) and can carry
> the fix as necessary.
>
> I suspect that there may be something deeper here, though.
This looks correct, thanks Stephen!
Linus Walleij
^ permalink raw reply
* linux-next: build failure after merge of the kvm-ppc tree
From: Stephen Rothwell @ 2012-05-16 7:24 UTC (permalink / raw)
To: Alexander Graf; +Cc: linux-next, linux-kernel, Paul Mackerras
[-- Attachment #1: Type: text/plain, Size: 421 bytes --]
Hi Alexander,
After merging the kvm-ppc tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: "kvm_hpt_order" [arch/powerpc/kvm/kvm.ko] undefined!
Caused by commit ec26346431bb ("KVM: PPC: Book3S HV: Make the guest hash
table size configurable").
I have used the kvm-ppc tree from next-20120514 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the kvm tree with the tip tree
From: Stephen Rothwell @ 2012-05-16 7:14 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti
Cc: linux-next, linux-kernel, Alan Cox, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Gleb Natapov
[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]
Hi all,
Today's linux-next merge of the kvm tree got a conflict in
arch/x86/include/asm/kvm_para.h between commit c3709e6734da ("x86, kvm:
KVM paravirt kernels don't check for CPUID being unavailable") from the
tip tree and commit 9b72d3b07dd9 ("KVM guest: make kvm_para_available()
check hypervisor bit reading cpuid leaf") from the kvm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/include/asm/kvm_para.h
index 183922e,a7a7a94..0000000
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@@ -170,17 -178,16 +178,19 @@@ static inline int kvm_para_available(vo
unsigned int eax, ebx, ecx, edx;
char signature[13];
+ if (boot_cpu_data.cpuid_level < 0)
+ return 0; /* So we don't blow up on old processors */
+
- cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
- memcpy(signature + 0, &ebx, 4);
- memcpy(signature + 4, &ecx, 4);
- memcpy(signature + 8, &edx, 4);
- signature[12] = 0;
+ if (cpu_has_hypervisor) {
+ cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
+ memcpy(signature + 0, &ebx, 4);
+ memcpy(signature + 4, &ecx, 4);
+ memcpy(signature + 8, &edx, 4);
+ signature[12] = 0;
- if (strcmp(signature, "KVMKVMKVM") == 0)
- return 1;
+ if (strcmp(signature, "KVMKVMKVM") == 0)
+ return 1;
+ }
return 0;
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (battery tree related)
From: Stephen Rothwell @ 2012-05-16 6:12 UTC (permalink / raw)
To: Mika Westerberg; +Cc: Anton Vorontsov, linux-next, linux-kernel
In-Reply-To: <20120507082637.GH31494@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]
Hi all,
On Mon, 7 May 2012 11:26:37 +0300 Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
>
> On Mon, May 07, 2012 at 05:14:58PM +1000, Stephen Rothwell wrote:
> >
> > After merging the final tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > drivers/power/smb347-charger.c: In function 'smb347_probe':
> > drivers/power/smb347-charger.c:1039:2: error: implicit declaration of function 'IS_ERR' [-Werror=implicit-function-declaration]
> > drivers/power/smb347-charger.c:1040:3: error: implicit declaration of function 'PTR_ERR' [-Werror=implicit-function-declaration]
> >
> > Caused by commit 34298d40e585 ("smb347-charger: Convert to regmap API").
>
> I'm unable to reproduce this on x86 build. I guess <linux/err.h> gets
> included implicitly there.
>
> Patch below should fix this. Anton, care to pick this one as well (or fold
> it into the 34298d40e585 ("smb347-charger: Convert to regmap API") commit)?
>
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> Subject: [PATCH] smb347-charger: include missing <linux/err.h>
>
> Without the include we get build errors like:
>
> drivers/power/smb347-charger.c: In function 'smb347_probe':
> drivers/power/smb347-charger.c:1039:2: error: implicit declaration of function 'IS_ERR' [-Werror=implicit-function-declaration]
> drivers/power/smb347-charger.c:1040:3: error: implicit declaration of function 'PTR_ERR' [-Werror=implicit-function-declaration]
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
> drivers/power/smb347-charger.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/power/smb347-charger.c b/drivers/power/smb347-charger.c
> index 09d19d2..f8eedd8 100644
> --- a/drivers/power/smb347-charger.c
> +++ b/drivers/power/smb347-charger.c
> @@ -11,6 +11,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include <linux/err.h>
> #include <linux/gpio.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
Ping?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the mfd tree
From: Stephen Rothwell @ 2012-05-16 6:09 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: linux-next, linux-kernel, Mark Brown
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
Hi Samuel,
After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/built-in.o: In function `wm8400_i2c_probe':
wm8400-core.c:(.text+0x100165): undefined reference to `devm_regmap_init_i2c'
drivers/built-in.o: In function `wm8400_module_init':
wm8400-core.c:(.init.text+0xb43c): undefined reference to `i2c_register_driver'
drivers/built-in.o: In function `wm8400_module_exit':
wm8400-core.c:(.exit.text+0x655): undefined reference to `i2c_del_driver'
Probably caused by commit 96cd102ae039 ("mfd: Don't support non-modular
wm8400 build") which was introduced to fix other problems. In this
build, CONFIG_I2C=m and CONFIG_REGMAP_I2C=m.
I have used the mfd tree from next-20120511 again for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the crypto tree with the arm tree
From: Stephen Rothwell @ 2012-05-16 5:14 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-next, linux-kernel, Linus Walleij, Russell King,
Andreas Westin
[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]
Hi Herbert,
Today's linux-next merge of the crypto tree got a conflict in
arch/arm/mach-ux500/devices-common.h between commit 08956a0e8a69 ("ARM:
7372/1: ux500: factor out dynamic amba device allocator") from the tree
and commit 585d188f8072 ("mach-ux500: crypto - core support for CRYP/HASH
module") from the crypto tree.
Just context changes (maybe). I fixed it up (see below) and can carry
the fix as necessary.
I suspect that there may be something deeper here, though.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-ux500/devices-common.h
index f75bcb2,89c5a59..0000000
--- a/arch/arm/mach-ux500/devices-common.h
+++ b/arch/arm/mach-ux500/devices-common.h
@@@ -11,8 -11,17 +11,13 @@@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/sys_soc.h>
+#include <linux/amba/bus.h>
#include <plat/i2c.h>
+ #include <mach/crypto-ux500.h>
+
-extern struct amba_device *
-dbx500_add_amba_device(struct device *parent, const char *name,
- resource_size_t base, int irq, void *pdata,
- unsigned int periphid);
-
+ extern struct platform_device *
+ dbx500_add_platform_device_noirq(const char *name, int id,
+ resource_size_t base, void *pdata);
struct spi_master_cntlr;
@@@ -81,10 -90,58 +86,59 @@@ dbx500_add_i2c(struct device *parent, i
static inline struct amba_device *
dbx500_add_rtc(struct device *parent, resource_size_t base, int irq)
{
- return dbx500_add_amba_device(parent, "rtc-pl031", base, irq, NULL, 0);
+ return amba_apb_device_add(parent, "rtc-pl031", base, SZ_4K, irq,
+ 0, NULL, 0);
}
+ struct cryp_platform_data;
+
+ static inline struct platform_device *
+ dbx500_add_cryp1(struct device *parent, int id, resource_size_t base, int irq,
+ struct cryp_platform_data *pdata)
+ {
+ struct resource res[] = {
+ DEFINE_RES_MEM(base, SZ_4K),
+ DEFINE_RES_IRQ(irq),
+ };
+
+ struct platform_device_info pdevinfo = {
+ .parent = parent,
+ .name = "cryp1",
+ .id = id,
+ .res = res,
+ .num_res = ARRAY_SIZE(res),
+ .data = pdata,
+ .size_data = sizeof(*pdata),
+ .dma_mask = DMA_BIT_MASK(32),
+ };
+
+ return platform_device_register_full(&pdevinfo);
+ }
+
+ struct hash_platform_data;
+
+ static inline struct platform_device *
+ dbx500_add_hash1(struct device *parent, int id, resource_size_t base,
+ struct hash_platform_data *pdata)
+ {
+ struct resource res[] = {
+ DEFINE_RES_MEM(base, SZ_4K),
+ };
+
+ struct platform_device_info pdevinfo = {
+ .parent = parent,
+ .name = "hash1",
+ .id = id,
+ .res = res,
+ .num_res = ARRAY_SIZE(res),
+ .data = pdata,
+ .size_data = sizeof(*pdata),
+ .dma_mask = DMA_BIT_MASK(32),
+ };
+
+ return platform_device_register_full(&pdevinfo);
+ }
+
struct nmk_gpio_platform_data;
void dbx500_add_gpios(struct device *parent, resource_size_t *base, int num,
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the sparc-next tree
From: Sam Ravnborg @ 2012-05-16 5:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David Miller, netdev, linux-next, linux-kernel
In-Reply-To: <20120516143944.57a648287aa5cd1a5930254e@canb.auug.org.au>
On Wed, May 16, 2012 at 02:39:44PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> arch/sparc/Makefile between commit e1d7de8377e6 ("sparc: introduce
> arch/sparc/Kbuild") from the sparc-next tree and commit 2809a2087cc4
> ("net: filter: Just In Time compiler for sparc") from the net-next tree.
>
> I suspect that the core-y net bit below should be changed to be a obj-y
> bit of arch/sparc/Kbuild ...
Correct - like this:
arch/sparc/Kbuild:
obj-y += net/
Sam
^ permalink raw reply
* Re: linux-next: manual merge of the kbuild tree with the sparc-next tree
From: Sam Ravnborg @ 2012-05-16 4:46 UTC (permalink / raw)
To: David Miller; +Cc: sfr, mmarek, linux-next, linux-kernel
In-Reply-To: <20120515.235747.716576574995746023.davem@davemloft.net>
On Tue, May 15, 2012 at 11:57:47PM -0400, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 16 May 2012 13:44:30 +1000
>
> > Today's linux-next merge of the kbuild tree got a conflict in
> > arch/sparc/boot/Makefile between commit 51f19cfa76d7 ("sparc32: drop
> > build time btfixup patching") from the sparc-next tree and commit
> > 95698570510b ("kbuild: refactor final link of sparc32") from the kbuild
> > tree.
> >
> > I have no idea, so I used the version from the sparc-next tree.
> >
> > Sam, can you have a look and work this out, please?
>
> As Sam states in:
>
> http://patchwork.ozlabs.org/patch/159094/
>
> This patch will conflict badly with a patch in kbuild-next.
>
> The fix is simple - drop all changes from kbuild-next.
>
> :-)
The above comment is true for both arch/sparc/Makefile and
arch/sparc/bot/Makefile.
sparc-next will also conflict with net-next.
net-next add the following line to arch/sparc/Makefile:
+core-y += arch/sparc/net/
The fix is to add this line to the newly introduced
arch/sparc/Kbuild file like this:
obj-y += net/
Sorry for these conflicts but we have been busy in sparc land
this round.
Sam
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the sparc-next tree
From: Stephen Rothwell @ 2012-05-16 4:39 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Sam Ravnborg
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
arch/sparc/Makefile between commit e1d7de8377e6 ("sparc: introduce
arch/sparc/Kbuild") from the sparc-next tree and commit 2809a2087cc4
("net: filter: Just In Time compiler for sparc") from the net-next tree.
I suspect that the core-y net bit below should be changed to be a obj-y
bit of arch/sparc/Kbuild ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/sparc/Makefile
index b9a72e2,0e5de13..0000000
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@@ -52,8 -64,9 +52,9 @@@ endi
head-y := arch/sparc/kernel/head_$(BITS).o
head-y += arch/sparc/kernel/init_task.o
-core-y += arch/sparc/kernel/
-core-y += arch/sparc/mm/ arch/sparc/math-emu/
+# See arch/sparc/Kbuild for the core part of the kernel
+core-y += arch/sparc/
+ core-y += arch/sparc/net/
libs-y += arch/sparc/prom/
libs-y += arch/sparc/lib/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the kbuild tree with the sparc-next tree
From: David Miller @ 2012-05-16 3:57 UTC (permalink / raw)
To: sfr; +Cc: mmarek, linux-next, linux-kernel, sam
In-Reply-To: <20120516134430.14f8e43c6f75604410dae815@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 May 2012 13:44:30 +1000
> Today's linux-next merge of the kbuild tree got a conflict in
> arch/sparc/boot/Makefile between commit 51f19cfa76d7 ("sparc32: drop
> build time btfixup patching") from the sparc-next tree and commit
> 95698570510b ("kbuild: refactor final link of sparc32") from the kbuild
> tree.
>
> I have no idea, so I used the version from the sparc-next tree.
>
> Sam, can you have a look and work this out, please?
As Sam states in:
http://patchwork.ozlabs.org/patch/159094/
This patch will conflict badly with a patch in kbuild-next.
The fix is simple - drop all changes from kbuild-next.
:-)
^ permalink raw reply
* linux-next: manual merge of the kbuild tree with the sparc-next tree
From: Stephen Rothwell @ 2012-05-16 3:44 UTC (permalink / raw)
To: Michal Marek; +Cc: linux-next, linux-kernel, Sam Ravnborg, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
Hi Michal,
Today's linux-next merge of the kbuild tree got a conflict in
arch/sparc/boot/Makefile between commit 51f19cfa76d7 ("sparc32: drop
build time btfixup patching") from the sparc-next tree and commit
95698570510b ("kbuild: refactor final link of sparc32") from the kbuild
tree.
I have no idea, so I used the version from the sparc-next tree.
Sam, can you have a look and work this out, please?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the nfs tree
From: Stephen Rothwell @ 2012-05-16 2:49 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-next, linux-kernel, Bryan Schumaker
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Hi Trond,
After merging the nfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/nfs/super.c: In function 'nfs_get_cache_cookie':
fs/nfs/super.c:2361:12: error: 'struct nfs_server' has no member named 'fscache_key'
fs/nfs/super.c:2362:16: error: 'struct nfs_server' has no member named 'fscache_key'
fs/nfs/super.c:2363:16: error: 'struct nfs_server' has no member named 'fscache_key'
fs/nfs/super.c:2367:2: warning: passing argument 3 of 'nfs_fscache_get_super_cookie' makes pointer from integer without a cast [enabled by default]
fs/nfs/fscache.h:173:20: note: expected 'struct nfs_clone_mount *' but argument is of type 'int'
Casued by commit 2311b9439ce8 ("NFS: Don't pass mount data to
nfs_fscache_get_super_cookie()"). This build has CONFIG_NFS_FSCACHE
unset. grep is your friend.
I have used the nfs tree from next-20120514 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the userns tree
From: Eric W. Biederman @ 2012-05-16 1:12 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20120514191337.e06ca84184b73b20b5c52689@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Eric,
>
> After merging the userns tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/stat.c: In function 'cp_new_stat64':
> fs/stat.c:354:61: error: expected ';' before ')' token
> fs/stat.c:354:61: error: expected statement before ')' token
> fs/stat.c:355:61: error: expected ';' before ')' token
> fs/stat.c:355:61: error: expected statement before ')' token
>
> I have dropped the userns tree for today.
*puts paper bag on head*
Thanks, and fixed.
Eric
^ permalink raw reply
* Re: linux-next: Tree for May 10 (fs/inode.c)
From: Myklebust, Trond @ 2012-05-15 0:49 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Randy Dunlap, Stephen Rothwell, linux-next@vger.kernel.org, LKML,
Al Viro
In-Reply-To: <CAP=VYLrAjGjCHDhxrEypaKcqK1Yx7_XY_TZofsf5V9x7GCGr7g@mail.gmail.com>
On Thu, 2012-05-10 at 21:36 -0400, Paul Gortmaker wrote:
> On Thu, May 10, 2012 at 5:23 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > On 05/10/2012 02:26 AM, Stephen Rothwell wrote:
> >
> >> Hi all,
> >>
> >> Changes since 20120508:
> >
> >
> > when CONFIG_BLOCK is not set:
> >
> > fs/inode.c:1777:6: error: redefinition of 'inode_dio_wait'
> > include/linux/fs.h:2476:20: note: previous definition of 'inode_dio_wait'
> > was here
>
> Also seen on some arm builds:
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/6291357/
> http://kisskb.ellerman.id.au/kisskb/buildresult/6291378/
>
> 5eff3957ce8d14c2a254844743dfb84e19e7c2ae is the first bad commit
> commit 5eff3957ce8d14c2a254844743dfb84e19e7c2ae
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Mon May 7 10:44:29 2012 -0400
>
> NFS: Ensure that setattr and getattr wait for O_DIRECT write completion
>
> Use the same mechanism as the block devices are using, but move the
> helper functions from fs/direct-io.c into fs/inode.c to remove the
> dependency on CONFIG_BLOCK.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Fred Isaman <iisaman@netapp.com>
>
> :040000 040000 ae33e2ffd172e4d7e2ad6ed219de32de936548cc
> ef2df66b34559dbc0782add108e24a6ef6e4e2ca M fs
> bisect run success
>
> P.
Sorry about being so late with this. The changes to include/linux/fs.h
had not been committed in the original branch. Today's linux-next should
have that fixed...
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* linux-next commit "ARM: dma-mapping: move all dma bounce code to separate dma ops structure"
From: Paul Gortmaker @ 2012-05-14 23:47 UTC (permalink / raw)
To: m.szyprowski
Cc: kyungmin.park, subash.ramaswamy,
linux-arm-kernel@lists.infradead.org, linux-next@vger.kernel.org
Hi Marek,
Can you have a re-visit to this commit?
commit 3c7c51817e8666aa507104d1ae624c5113ecbe01
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Fri Feb 10 19:55:20 2012 +0100
ARM: dma-mapping: move all dma bounce code to separate dma ops structure
It seems some builds were still relying on the old behaviour,
as git bisect on one of the fails led to the above commit.
Here is the failure:
arch/arm/common/dmabounce.c:459:12: error: 'generic_dma_map_sg' undeclared here (not in a function)
arch/arm/common/dmabounce.c:460:14: error: 'generic_dma_unmap_sg' undeclared here (not in a function)
arch/arm/common/dmabounce.c:461:21: error: 'generic_dma_sync_sg_for_cpu' undeclared here (not in a function)
arch/arm/common/dmabounce.c:462:24: error: 'generic_dma_sync_sg_for_device' undeclared here (not in a function)
make[2]: *** [arch/arm/common/dmabounce.o] Error 1
It happens on several ARM in-tree defconfig files, such as these.
http://kisskb.ellerman.id.au/kisskb/buildresult/6320182/
http://kisskb.ellerman.id.au/kisskb/buildresult/6320161/
http://kisskb.ellerman.id.au/kisskb/buildresult/6294024/
http://kisskb.ellerman.id.au/kisskb/buildresult/6320159/
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH -next] net/codel: Add missing #include <linux/prefetch.h>
From: David Miller @ 2012-05-14 21:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: geert, edumazet, dave.taht, netdev, linux-kernel, linux-next
In-Reply-To: <1337029498.8512.624.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 May 2012 23:04:58 +0200
> On Mon, 2012-05-14 at 21:47 +0200, Geert Uytterhoeven wrote:
>> m68k allmodconfig:
>>
>> net/sched/sch_codel.c: In function ‘dequeue’:
>> net/sched/sch_codel.c:70: error: implicit declaration of function ‘prefetch’
>> make[1]: *** [net/sched/sch_codel.o] Error 1
>>
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> ---
>
> I plaid guilty
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: linux-next: manual merge of the akpm tree with the arm-soc tree
From: Turquette, Mike @ 2012-05-14 21:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Arnd Bergmann, linux-kernel, linux-next,
Olof Johansson, linux-arm-kernel
In-Reply-To: <20120514192404.91f9477851ad8485a2112973@canb.auug.org.au>
On Mon, May 14, 2012 at 2:24 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> drivers/clk/Kconfig between commit d269b974e32c ("clk: remove
> COMMON_CLK_DISABLE_UNUSED") from the arm-soc tree and commit "clk: remove
> redundant depends on from drivers/Kconfig" from the akpm tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Hi Stephen,
The fix-up is correct.
Thanks,
Mike
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc drivers/clk/Kconfig
> index 4864407,4f10a21..0000000
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@@ -23,9 -22,18 +23,8 @@@ config COMMON_CL
> menu "Common Clock Framework"
> depends on COMMON_CLK
>
> -config COMMON_CLK_DISABLE_UNUSED
> - bool "Disabled unused clocks at boot"
> - ---help---
> - Traverses the entire clock tree and disables any clocks that are
> - enabled in hardware but have not been enabled by any device drivers.
> - This saves power and keeps the software model of the clock in line
> - with reality.
> -
> - If in doubt, say "N".
> -
> config COMMON_CLK_DEBUG
> bool "DebugFS representation of clock tree"
> - depends on COMMON_CLK
> select DEBUG_FS
> ---help---
> Creates a directory hierchy in debugfs for visualizing the clk
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox