* [PATCH] pseries/iommu: remove default window before attempting DDW manipulation
From: Nishanth Aravamudan @ 2012-05-15 17:04 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, miltonm
An upcoming release of firmware will add DDW extensions, in particular
an API to "reset" the DMA window to the original configuration (32-bit,
2GB in size). With that API available, we can safely remove the default
window, increasing the resources available to firmware for creation of
larger windows for the slot in question -- if we encounter an error, we
can use the new API to reset the state of the slot.
Further, this same release of firmware will make it a hard requirement
for OSes to release the existing window before any other windows will be
shown as available, to avoid conflicts in addressing between the two
windows.
In anticipation of these changes, always remove the default window
before we do any DDW manipulations.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 0915b1a..526076b 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -707,6 +707,21 @@ static int __init disable_ddw_setup(char *str)
early_param("disable_ddw", disable_ddw_setup);
+static inline void __remove_ddw(struct device_node *np, const u32 *ddw_avail, u64 liobn)
+{
+ int ret;
+
+ ret = rtas_call(ddw_avail[2], 1, 1, NULL, liobn);
+ if (ret)
+ pr_warning("%s: failed to remove DMA window: rtas returned "
+ "%d to ibm,remove-pe-dma-window(%x) %llx\n",
+ np->full_name, ret, ddw_avail[2], liobn);
+ else
+ pr_debug("%s: successfully removed DMA window: rtas returned "
+ "%d to ibm,remove-pe-dma-window(%x) %llx\n",
+ np->full_name, ret, ddw_avail[2], liobn);
+}
+
static void remove_ddw(struct device_node *np)
{
struct dynamic_dma_window_prop *dwp;
@@ -736,15 +751,7 @@ static void remove_ddw(struct device_node *np)
pr_debug("%s successfully cleared tces in window.\n",
np->full_name);
- ret = rtas_call(ddw_avail[2], 1, 1, NULL, liobn);
- if (ret)
- pr_warning("%s: failed to remove direct window: rtas returned "
- "%d to ibm,remove-pe-dma-window(%x) %llx\n",
- np->full_name, ret, ddw_avail[2], liobn);
- else
- pr_debug("%s: successfully removed direct window: rtas returned "
- "%d to ibm,remove-pe-dma-window(%x) %llx\n",
- np->full_name, ret, ddw_avail[2], liobn);
+ __remove_ddw(np, ddw_avail, liobn);
delprop:
ret = prom_remove_property(np, win64);
@@ -869,6 +876,35 @@ static int create_ddw(struct pci_dev *dev, const u32 *ddw_avail,
return ret;
}
+static void restore_default_window(struct pci_dev *dev,
+ u32 ddw_restore_token, unsigned long liobn)
+{
+ struct eeh_dev *edev;
+ u32 cfg_addr;
+ u64 buid;
+ int ret;
+
+ /*
+ * Get the config address and phb buid of the PE window.
+ * Rely on eeh to retrieve this for us.
+ * Retrieve them from the pci device, not the node with the
+ * dma-window property
+ */
+ edev = pci_dev_to_eeh_dev(dev);
+ cfg_addr = edev->config_addr;
+ if (edev->pe_config_addr)
+ cfg_addr = edev->pe_config_addr;
+ buid = edev->phb->buid;
+
+ do {
+ ret = rtas_call(ddw_restore_token, 3, 1, NULL, cfg_addr,
+ BUID_HI(buid), BUID_LO(buid));
+ } while (rtas_busy_delay(ret));
+ dev_info(&dev->dev,
+ "ibm,reset-pe-dma-windows(%x) %x %x %x returned %d\n",
+ ddw_restore_token, cfg_addr, BUID_HI(buid), BUID_LO(buid), ret);
+}
+
/*
* If the PE supports dynamic dma windows, and there is space for a table
* that can map all pages in a linear offset, then setup such a table,
@@ -889,9 +925,13 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
u64 dma_addr, max_addr;
struct device_node *dn;
const u32 *uninitialized_var(ddw_avail);
+ const u32 *uninitialized_var(ddw_extensions);
+ u32 ddw_restore_token = 0;
struct direct_window *window;
struct property *win64;
struct dynamic_dma_window_prop *ddwprop;
+ const void *dma_window = NULL;
+ unsigned long liobn, offset, size;
mutex_lock(&direct_window_init_mutex);
@@ -911,7 +951,40 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
if (!ddw_avail || len < 3 * sizeof(u32))
goto out_unlock;
- /*
+ /*
+ * the extensions property is only required to exist in certain
+ * levels of firmware and later
+ * the ibm,ddw-extensions property is a list with the first
+ * element containing the number of extensions and each
+ * subsequent entry is a value corresponding to that extension
+ */
+ ddw_extensions = of_get_property(pdn, "ibm,ddw-extensions", &len);
+ if (ddw_extensions) {
+ /*
+ * each new defined extension length should be added to
+ * the top of the switch so the "earlier" entries also
+ * get picked up
+ */
+ switch (ddw_extensions[0]) {
+ /* ibm,reset-pe-dma-windows */
+ case 1:
+ ddw_restore_token = ddw_extensions[1];
+ break;
+ }
+ }
+
+ /*
+ * Only remove the existing DMA window if we can restore back to
+ * the default state. Removing the existing window maximizes the
+ * resources available to firmware for dynamic window creation.
+ */
+ if (ddw_restore_token) {
+ dma_window = of_get_property(pdn, "ibm,dma-window", NULL);
+ of_parse_dma_window(pdn, dma_window, &liobn, &offset, &size);
+ __remove_ddw(pdn, ddw_avail, liobn);
+ }
+
+ /*
* Query if there is a second window of size to map the
* whole partition. Query returns number of windows, largest
* block assigned to PE (partition endpoint), and two bitmasks
@@ -920,7 +993,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
dn = pci_device_to_OF_node(dev);
ret = query_ddw(dev, ddw_avail, &query);
if (ret != 0)
- goto out_unlock;
+ goto out_restore_window;
if (query.windows_available == 0) {
/*
@@ -929,7 +1002,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
* trading in for a larger page size.
*/
dev_dbg(&dev->dev, "no free dynamic windows");
- goto out_unlock;
+ goto out_restore_window;
}
if (query.page_size & 4) {
page_shift = 24; /* 16MB */
@@ -940,7 +1013,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
} else {
dev_dbg(&dev->dev, "no supported direct page size in mask %x",
query.page_size);
- goto out_unlock;
+ goto out_restore_window;
}
/* verify the window * number of ptes will map the partition */
/* check largest block * page size > max memory hotplug addr */
@@ -949,14 +1022,14 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
dev_dbg(&dev->dev, "can't map partiton max 0x%llx with %u "
"%llu-sized pages\n", max_addr, query.largest_available_block,
1ULL << page_shift);
- goto out_unlock;
+ goto out_restore_window;
}
len = order_base_2(max_addr);
win64 = kzalloc(sizeof(struct property), GFP_KERNEL);
if (!win64) {
dev_info(&dev->dev,
"couldn't allocate property for 64bit dma window\n");
- goto out_unlock;
+ goto out_restore_window;
}
win64->name = kstrdup(DIRECT64_PROPNAME, GFP_KERNEL);
win64->value = ddwprop = kmalloc(sizeof(*ddwprop), GFP_KERNEL);
@@ -1018,6 +1091,10 @@ out_free_prop:
kfree(win64->value);
kfree(win64);
+out_restore_window:
+ if (ddw_restore_token)
+ restore_default_window(dev, ddw_restore_token, liobn);
+
out_unlock:
mutex_unlock(&direct_window_init_mutex);
return dma_addr;
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply related
* Re: Build regressions/improvements in v3.4-rc7
From: Geert Uytterhoeven @ 2012-05-16 8:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Linuxppc-dev, the arch/x86 maintainers, Parisc List
In-Reply-To: <1337157034-22773-1-git-send-email-geert@linux-m68k.org>
On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.4-rc7 to v3.4-rc6[3], the summaries are:
> =C2=A0- build errors: +15/-14
15 regressions:
+ arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
fsl_diu_monitor_port' declared inside parameter list [-Werror]: =3D>
70:9, 84:9, 88:36
+ arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
a value, in function returning void [-Werror]: =3D> 189:2
+ arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
declaration isn't a prototype [-Werror=3Dstrict-prototypes]: =3D> 69:5,
88:6, 83:6, 187:1
+ arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
only this definition or declaration, which is probably not what you
want [-Werror]: =3D> 70:9
+ drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
use in this function): =3D> 799:80
powerpc randconfig
+ arch/x86/include/asm/uaccess_32.h: error: call to
'copy_from_user_overflow' declared with attribute error:
copy_from_user() buffer size is not provably correct: =3D> 211:26
error in i386-randconfig, warning in i386-defconfig
+ drivers/ptp/ptp_pch.c: error: implicit declaration of function
'kfree' [-Werror=3Dimplicit-function-declaration]: =3D> 576:2
+ drivers/ptp/ptp_pch.c: error: implicit declaration of function
'kzalloc' [-Werror=3Dimplicit-function-declaration]: =3D> 587:2
Patch send.
+ error: "handle_edge_irq" [drivers/gpio/gpio-pch.ko] undefined!: =3D> N=
/A
+ error: "irq_to_desc" [drivers/gpio/gpio-pch.ko] undefined!: =3D> N/A
Fixed in the mean time, I guess.
+ error: No rule to make target include/config/auto.conf: =3D> N/A
x86_64-randconfig
+ lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
constraints in an 'asm': =3D> 50:70
+ lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
constraints in an 'asm': =3D> 49:70
+ lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
constraints in an 'asm': =3D> 49:70
+ lib/mpi/mpih-div.c: error: inconsistent operand constraints in an
'asm': =3D> 135:122, 135:371, 97:122, 106:121, 106:370, 97:371
parisc-allmodconfig
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: James Bottomley @ 2012-05-16 14:46 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Parisc List, the arch/x86 maintainers, James Morris, linux-kernel,
Linuxppc-dev, Dmitry Kasatkin
In-Reply-To: <CAMuHMdUtL4_mv-e-EQAZmNcb9dAT=PXB59i7Vuj2vf8NnaBFzQ@mail.gmail.com>
On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
> constraints in an 'asm': => 50:70
> + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
> constraints in an 'asm': => 49:70
> + lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
> constraints in an 'asm': => 49:70
> + lib/mpi/mpih-div.c: error: inconsistent operand constraints in an
> 'asm': => 135:122, 135:371, 97:122, 106:121, 106:370, 97:371
>
> parisc-allmodconfig
Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm code.
The error in this case appears to be that umul_ppm() is implemented as
an xmpyu instruction. That's a floating point instruction. We
deliberately compile the kernel with floating point disabled because we
don't want to save and restore the floating point register file on each
context switch, hence the operand constraints are unsatisfiable.
It appears to be completely untested on non-x86 and to have been
imported via the security tree ... what are we supposed to do with this?
I thought the general principle was that asm code was really supposed to
be confined to the arch directories?
James
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Geert Uytterhoeven @ 2012-05-16 15:59 UTC (permalink / raw)
To: James Bottomley
Cc: Parisc List, the arch/x86 maintainers, James Morris, linux-kernel,
Linuxppc-dev, Dmitry Kasatkin
In-Reply-To: <1337179563.2985.80.camel@dabdike.int.hansenpartnership.com>
On Wed, May 16, 2012 at 4:46 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
>> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> =C2=A0 + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 50:70
>> =C2=A0 + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/mpih-div.c: error: inconsistent operand constraints in =
an
>> 'asm': =C2=A0=3D> 135:122, 135:371, 97:122, 106:121, 106:370, 97:371
>>
>> parisc-allmodconfig
>
> Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm code.
> The error in this case appears to be that umul_ppm() is implemented as
> an xmpyu instruction. =C2=A0That's a floating point instruction. =C2=A0We
> deliberately compile the kernel with floating point disabled because we
> don't want to save and restore the floating point register file on each
> context switch, hence the operand constraints are unsatisfiable.
It also does fishy things on m68k, cfr. https://lkml.org/lkml/2012/3/11/22
> It appears to be completely untested on non-x86 and to have been
> imported via the security tree ... what are we supposed to do with this?
> I thought the general principle was that asm code was really supposed to
> be confined to the arch directories?
Kick it out again, or contain it in staging?
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Kasatkin, Dmitry @ 2012-05-16 15:59 UTC (permalink / raw)
To: James Bottomley
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, James Morris,
Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <1337179563.2985.80.camel@dabdike.int.hansenpartnership.com>
On Wed, May 16, 2012 at 5:46 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
>> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> =C2=A0 + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 50:70
>> =C2=A0 + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/mpih-div.c: error: inconsistent operand constraints in =
an
>> 'asm': =C2=A0=3D> 135:122, 135:371, 97:122, 106:121, 106:370, 97:371
>>
>> parisc-allmodconfig
>
> Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm code.
> The error in this case appears to be that umul_ppm() is implemented as
> an xmpyu instruction. =C2=A0That's a floating point instruction. =C2=A0We
> deliberately compile the kernel with floating point disabled because we
> don't want to save and restore the floating point register file on each
> context switch, hence the operand constraints are unsatisfiable.
>
> It appears to be completely untested on non-x86 and to have been
> imported via the security tree ... what are we supposed to do with this?
> I thought the general principle was that asm code was really supposed to
> be confined to the arch directories?
>
> James
>
>
Yes.. it is suxx.
But it is only longlong.h and inherited from gpg..
And now there is a stuff such as /include/math-emu/soft-fp and
<stdlib/longlong.h>
I planned to look to that but now I will start doing it right away.
- Dmitry
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Benjamin Herrenschmidt @ 2012-05-16 23:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, Linuxppc-dev,
Scott Wood
In-Reply-To: <CAMuHMdUtL4_mv-e-EQAZmNcb9dAT=PXB59i7Vuj2vf8NnaBFzQ@mail.gmail.com>
On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > JFYI, when comparing v3.4-rc7 to v3.4-rc6[3], the summaries are:
> > - build errors: +15/-14
>
> 15 regressions:
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
> fsl_diu_monitor_port' declared inside parameter list [-Werror]: =>
> 70:9, 84:9, 88:36
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
> a value, in function returning void [-Werror]: => 189:2
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
> declaration isn't a prototype [-Werror=strict-prototypes]: => 69:5,
> 88:6, 83:6, 187:1
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
> only this definition or declaration, which is probably not what you
> want [-Werror]: => 70:9
> + drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
> use in this function): => 799:80
>
> powerpc randconfig
Thanks. These are all freescale platforms, the relevant people should be
already but I've added Scott and Kumar to the CC list just in case.
Cheers,
Ben.
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: John David Anglin @ 2012-05-17 0:27 UTC (permalink / raw)
To: James Bottomley
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, James Morris,
Linuxppc-dev, Dmitry Kasatkin, Geert Uytterhoeven
In-Reply-To: <1337179563.2985.80.camel@dabdike.int.hansenpartnership.com>
On 16-May-12, at 10:46 AM, James Bottomley wrote:
> Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm
> code.
> The error in this case appears to be that umul_ppm() is implemented as
> an xmpyu instruction. That's a floating point instruction. We
> deliberately compile the kernel with floating point disabled because
> we
> don't want to save and restore the floating point register file on
> each
> context switch, hence the operand constraints are unsatisfiable.
I haven't tried this but I think the parisc implementation of umul_ppmm
can be deleted. There is a generic version in the file.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply
* linux-next: manual merge of the crypto tree with the powerpc tree
From: Stephen Rothwell @ 2012-05-17 3:21 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-kernel, linux-next, Paul Mackerras, Andreas Westin,
Kent Yoder, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]
Hi Herbert,
Today's linux-next merge of the crypto tree got a conflict in
drivers/crypto/Kconfig between commit aef7b31c8833 ("powerpc/crypto:
Build files for the nx device driver") from the powerpc tree and commit
2789c08fffea ("crypto: ux500 - Add driver for CRYP hardware") from the
crypto 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 drivers/crypto/Kconfig
index f1ceeef,69fdf18..0000000
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@@ -296,21 -295,15 +296,32 @@@ config CRYPTO_DEV_TEGRA_AE
To compile this driver as a module, choose M here: the module
will be called tegra-aes.
+config CRYPTO_DEV_NX
+ tristate "Support for Power7+ in-Nest cryptographic accleration"
+ depends on PPC64 && IBMVIO
+ select CRYPTO_AES
+ select CRYPTO_CBC
+ select CRYPTO_ECB
+ select CRYPTO_CCM
+ select CRYPTO_GCM
+ select CRYPTO_AUTHENC
+ select CRYPTO_XCBC
+ select CRYPTO_SHA256
+ select CRYPTO_SHA512
+ help
+ Support for Power7+ in-Nest cryptographic acceleration. This
+ module supports acceleration for AES and SHA2 algorithms. If you
+ choose 'M' here, this module will be called nx_crypto.
+
+ config CRYPTO_DEV_UX500
+ tristate "Driver for ST-Ericsson UX500 crypto hardware acceleration"
+ depends on ARCH_U8500
+ select CRYPTO_ALGAPI
+ help
+ Driver for ST-Ericsson UX500 crypto engine.
+
+ if CRYPTO_DEV_UX500
+ source "drivers/crypto/ux500/Kconfig"
+ endif # if CRYPTO_DEV_UX500
+
endif # CRYPTO_HW
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the crypto tree with the powerpc tree
From: Herbert Xu @ 2012-05-17 3:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, linux-next, Paul Mackerras, Andreas Westin,
Kent Yoder, linuxppc-dev
In-Reply-To: <20120517132116.8a5378bce254fc39d20cb08a@canb.auug.org.au>
On Thu, May 17, 2012 at 01:21:16PM +1000, Stephen Rothwell wrote:
> Hi Herbert,
>
> Today's linux-next merge of the crypto tree got a conflict in
> drivers/crypto/Kconfig between commit aef7b31c8833 ("powerpc/crypto:
> Build files for the nx device driver") from the powerpc tree and commit
> 2789c08fffea ("crypto: ux500 - Add driver for CRYP hardware") from the
> crypto tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Looks fine. Thanks Stephen!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Li Zhong @ 2012-05-17 4:01 UTC (permalink / raw)
To: LKML; +Cc: Paul E. McKenney, Paul Mackerras, PowerPC email list
This patch tries to fix following lockdep complaints:
[ 81.882506] =================================
[ 81.882508] [ INFO: inconsistent lock state ]
[ 81.882511] 3.4.0-rc4-autokern1 #1 Not tainted
[ 81.882513] ---------------------------------
[ 81.882516] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 81.882519] swapper/5/0 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 81.882522] (call_function.lock){?.....}, at:
[<c0000000000fdaa0>] .ipi_call_lock+0x20/0x40
[ 81.882536] {IN-HARDIRQ-W} state was registered at:
[ 81.882538] [<c0000000000f5a9c>] .__lock_acquire+0x44c/0x9e0
[ 81.882543] [<c0000000000f60f4>] .lock_acquire+0xc4/0x260
[ 81.882548] [<c00000000063f648>] ._raw_spin_lock+0x48/0x70
[ 81.882554]
[<c0000000000fede4>] .generic_smp_call_function_interrupt+0x1d4/0x320
[ 81.882559] [<c000000000037020>] .smp_ipi_demux+0x90/0x100
[ 81.882565] [<c00000000004f98c>] .icp_hv_ipi_action+0x5c/0xc0
[ 81.882571] [<c00000000013420c>] .handle_irq_event_percpu
+0xec/0x570
[ 81.882577] [<c000000000138ab4>] .handle_percpu_irq+0x84/0xd0
[ 81.882582] [<c0000000000221b4>] .call_handle_irq+0x1c/0x2c
[ 81.882588] [<c0000000000103fc>] .do_IRQ+0x16c/0x500
[ 81.882593] [<c0000000000038d0>] hardware_interrupt_common
+0x150/0x180
[ 81.882598] [<c000000000010a38>] .arch_local_irq_restore+0x38/0x90
[ 81.882603] [<c000000000017450>] .cpu_idle+0x250/0x2d0
[ 81.882607] [<c000000000651ce0>] .start_secondary+0x378/0x384
[ 81.882613] [<c00000000000936c>] .start_secondary_prolog+0x10/0x14
[ 81.882618] irq event stamp: 332475
[ 81.882620] hardirqs last enabled at (332475):
[<c000000000640414>] ._raw_spin_unlock_irqrestore+0x94/0xc0
[ 81.882625] hardirqs last disabled at (332474):
[<c00000000063f7c0>] ._raw_spin_lock_irqsave+0x30/0x90
[ 81.882631] softirqs last enabled at (332288):
[<c0000000000873c4>] .irq_enter+0x94/0xd0
[ 81.882636] softirqs last disabled at (332287):
[<c0000000000873b4>] .irq_enter+0x84/0xd0
[ 81.882640]
[ 81.882641] other info that might help us debug this:
[ 81.882644] Possible unsafe locking scenario:
[ 81.882645]
[ 81.882647] CPU0
[ 81.882649] ----
[ 81.882650] lock(call_function.lock);
[ 81.882654] <Interrupt>
[ 81.882656] lock(call_function.lock);
[ 81.882660]
[ 81.882661] *** DEADLOCK ***
[ 81.882662]
[ 81.882664] no locks held by swapper/5/0.
[ 81.882666]
[ 81.882667] stack backtrace:
[ 81.882669] Call Trace:
[ 81.882672] [c0000003c07bf860] [c0000000000146f4] .show_stack
+0x74/0x1c0 (unreliable)
[ 81.882678] [c0000003c07bf910] [c0000000000f1304] .print_usage_bug
+0x1e4/0x230
[ 81.882683] [c0000003c07bf9d0] [c0000000000f150c] .mark_lock_irq
+0x1bc/0x3c0
[ 81.882688] [c0000003c07bfa90] [c0000000000f18a0] .mark_lock
+0x190/0x4b0
[ 81.882693] [c0000003c07bfb40] [c0000000000f1d10] .mark_irqflags
+0x150/0x240
[ 81.882697] [c0000003c07bfbd0] [c0000000000f5a9c] .__lock_acquire
+0x44c/0x9e0
[ 81.882702] [c0000003c07bfce0] [c0000000000f60f4] .lock_acquire
+0xc4/0x260
[ 81.882707] [c0000003c07bfdc0] [c00000000063f648] ._raw_spin_lock
+0x48/0x70
[ 81.882712] [c0000003c07bfe50] [c0000000000fdaa0] .ipi_call_lock
+0x20/0x40
[ 81.882717] [c0000003c07bfed0] [c000000000651aa0] .start_secondary
+0x138/0x384
[ 81.882722] [c0000003c07bff90]
[c00000000000936c] .start_secondary_prolog+0x10/0x14
>From the log, ipi_call_lock() is called in start_secondary() with irqs
enabled. The irqs are enabled by smp_ops->setup_cpu(), in following call
chain:
start_secondary --> smp_ops->setup_cpu --> smp_xics_setup_cpu -->
pseries_notify_cpu_idle_add_cpu --> cpuidle_disable_device -->
cpuidle_remove_state_sysfs --> cpuidle_free_state_kobj -->
wait_for_completion --> wait_for_common
>From my understanding of the codes, I think it's not necessary to call
pseries_notify_cpu_idle_add_cpu() in the early start_secondary()
function before irqs could be enabled.
pseries_notify_cpu_idle_add_cpu() actually does
cpuidle_disable_device(), and then cpuidle_enable_device(), which
releases and allocates the resources respectively. ( Also, all the data
are cleared and reinitialized after this cycle). The problem here is:
something like kzalloc(GFP_KERNEL), wait_for_completion() would have
problems running here where irqs are still disabled.
Actually, cpuidle_enable_device() is called for each possible cpu when
the driver is registered. So I don't think the resources needed to be
released and allocated each time cpu becomes online. Something like
cpuidle_reset_device() would be enough to clear and reinitialize the
data.
However, after some studying of the data to be cleared, I think it's
also reasonable to keep the previous data. For example:
/sys/devices/system/cpu/cpu#/cpuidle/state#/usage
the number of times this idle state has been entered
/sys/devices/system/cpu/cpu#/cpuidle/state#/time
the amount of time spent in this idle state
So I think we could just remove the function call doing the
disable/enable cycle:
Please correct me if I missed anything.
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/smp.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index e16bb8d..71706bc 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
set_cpu_current_state(cpu, CPU_STATE_ONLINE);
set_default_offline_state(cpu);
#endif
- pseries_notify_cpuidle_add_cpu(cpu);
}
static int __devinit smp_pSeries_kick_cpu(int nr)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Benjamin Herrenschmidt @ 2012-05-17 4:28 UTC (permalink / raw)
To: Li Zhong
Cc: PowerPC email list, Paul E. McKenney, Paul Mackerras, LKML,
deepthi
In-Reply-To: <1337227263.24471.23.camel@ThinkPad-T420>
On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
> This patch tries to fix following lockdep complaints:
.../...
> pseries_notify_cpu_idle_add_cpu() actually does
> cpuidle_disable_device(), and then cpuidle_enable_device(), which
> releases and allocates the resources respectively. ( Also, all the data
> are cleared and reinitialized after this cycle). The problem here is:
> something like kzalloc(GFP_KERNEL), wait_for_completion() would have
> problems running here where irqs are still disabled.
So yes, it looks definitely fishy. I don't have time to study cpuidle
today to check whether that's correct or not so I'm CCing Deepthi
Dharwar who did all that cpuidle work for pseries.
Deepthi, can you check whether that patch is correct ?
> Actually, cpuidle_enable_device() is called for each possible cpu when
> the driver is registered. So I don't think the resources needed to be
> released and allocated each time cpu becomes online. Something like
> cpuidle_reset_device() would be enough to clear and reinitialize the
> data.
>
> However, after some studying of the data to be cleared, I think it's
> also reasonable to keep the previous data. For example:
>
> /sys/devices/system/cpu/cpu#/cpuidle/state#/usage
> the number of times this idle state has been entered
> /sys/devices/system/cpu/cpu#/cpuidle/state#/time
> the amount of time spent in this idle state
>
> So I think we could just remove the function call doing the
> disable/enable cycle:
>
> Please correct me if I missed anything.
>
> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/smp.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/smp.c
> b/arch/powerpc/platforms/pseries/smp.c
> index e16bb8d..71706bc 100644
> --- a/arch/powerpc/platforms/pseries/smp.c
> +++ b/arch/powerpc/platforms/pseries/smp.c
> @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
> set_cpu_current_state(cpu, CPU_STATE_ONLINE);
> set_default_offline_state(cpu);
> #endif
> - pseries_notify_cpuidle_add_cpu(cpu);
> }
>
> static int __devinit smp_pSeries_kick_cpu(int nr)
^ permalink raw reply
* Re: Fixing a cputhread code documentation
From: Anshuman Khandual @ 2012-05-17 5:30 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <4FB12570.9090503@linux.vnet.ibm.com>
Hey Ben,
Because its too minor a documentation fix, did not write any description.
Not sure how it works, I thought this would be clubbed with other incoming
documentation fix in the same area.
On Monday 14 May 2012 09:02 PM, Anshuman Khandual wrote:
> diff --git a/arch/powerpc/include/asm/cputhreads.h b/arch/powerpc/include/asm/cputhreads.h
> index ce516e5..ac3eedb 100644
> --- a/arch/powerpc/include/asm/cputhreads.h
> +++ b/arch/powerpc/include/asm/cputhreads.h
> @@ -9,7 +9,7 @@
> * Note: This implementation is limited to a power of 2 number of
> * threads per core and the same number for each core in the system
> * (though it would work if some processors had less threads as long
> - * as the CPU numbers are still allocated, just not brought offline).
> + * as the CPU numbers are still allocated, just not brought online).
> *
> * However, the API allows for a different implementation in the future
> * if needed, as long as you only use the functions and not the variables
>
> --
> Anshuman Khandual
^ permalink raw reply
* Re: [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Deepthi Dharwar @ 2012-05-17 10:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: PowerPC email list, Paul E. McKenney, Paul Mackerras, LKML,
Li Zhong
In-Reply-To: <1337228910.30558.46.camel@pasglop>
On 05/17/2012 09:58 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
>> This patch tries to fix following lockdep complaints:
>
> .../...
>
>> pseries_notify_cpu_idle_add_cpu() actually does
>> cpuidle_disable_device(), and then cpuidle_enable_device(), which
>> releases and allocates the resources respectively. ( Also, all the data
>> are cleared and reinitialized after this cycle). The problem here is:
>> something like kzalloc(GFP_KERNEL), wait_for_completion() would have
>> problems running here where irqs are still disabled.
This is true when the system is booting up.
>
> So yes, it looks definitely fishy. I don't have time to study cpuidle
> today to check whether that's correct or not so I'm CCing Deepthi
> Dharwar who did all that cpuidle work for pseries.
>
> Deepthi, can you check whether that patch is correct ?
pseries_notify_cpu_idle_add_cpu() is essential to be called for
hotplug event. So by removing this call completely wouldn't
support cpus registering under cpuidle on hotplug and default idle is
executed on those with do not give much powersavings. Ideal way it to
have a notifier in pseries backend driver for hotplug notification and
then remove this function from here.
I am currently working on this patch, will post it out soon.
>
>> Actually, cpuidle_enable_device() is called for each possible cpu when
>> the driver is registered. So I don't think the resources needed to be
>> released and allocated each time cpu becomes online. Something like
>> cpuidle_reset_device() would be enough to clear and reinitialize the
>> data.
>>
>> However, after some studying of the data to be cleared, I think it's
>> also reasonable to keep the previous data. For example:
>>
>> /sys/devices/system/cpu/cpu#/cpuidle/state#/usage
>> the number of times this idle state has been entered
>> /sys/devices/system/cpu/cpu#/cpuidle/state#/time
>> the amount of time spent in this idle state
>>
>> So I think we could just remove the function call doing the
>> disable/enable cycle:
>>
>> Please correct me if I missed anything.
If removed, this would not handle cpu hotplug events for cpuidle.
>>
>> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
>> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/pseries/smp.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/smp.c
>> b/arch/powerpc/platforms/pseries/smp.c
>> index e16bb8d..71706bc 100644
>> --- a/arch/powerpc/platforms/pseries/smp.c
>> +++ b/arch/powerpc/platforms/pseries/smp.c
>> @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
>> set_cpu_current_state(cpu, CPU_STATE_ONLINE);
>> set_default_offline_state(cpu);
>> #endif
>> - pseries_notify_cpuidle_add_cpu(cpu);
>> }
>>
>> static int __devinit smp_pSeries_kick_cpu(int nr)
>
>
>
Cheers,
Deepthi
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Frank Svendsbøe @ 2012-05-17 14:37 UTC (permalink / raw)
To: robert.karl.berger, Tony Breeds; +Cc: Wolfgang Denk, linuxppc-dev
In-Reply-To: <4FA68C98.5070209@gmail.com>
On Sun, May 6, 2012 at 4:37 PM, Robert Berger
<robert.karl.berger@gmail.com> wrote:
> On 04/02/2012 09:28 AM, Tony Breeds wrote:
>> On Mon, Apr 02, 2012 at 12:01:55PM +1000, Benjamin Herrenschmidt wrote:
>>
>>> Ok, I've asked Tony to have a look at splitting the build decision
>>> in arch/powerpc/boot along the same lines as the CPU families... ie onl=
y
>>> wrappers for platforms potentially supported by the built kernel. That
>>> should fix it.
>>
>> Please try this patch. =A0Only lightly tested here. =A0I haven't "split =
up"
>> src-wlib yet as I wanted to verify I'm on the right track.
>
> I can confirm that it fixes the kilauea problem. Builds and runs so far.
> Are you going to push this upstream?
>
I can confirm this too (applied to 3.4-rc7). Tony?
Best regards,
Frank
^ permalink raw reply
* ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Anthony Foiani @ 2012-05-17 17:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Robert P. J. Day, Jeff Garzik, ashish kalra, Adrian Bunk
Greetings.
I was occasionally running into problems at boot time on an
MPC8315-based board (derived from the MPC831xRDB, apparently), using
SATA to talk to an SSD. My vendor suggested that I enable
CONFIG_MPC8315_DS.
That symbol is only found once in the entire kernel codebase:
$ git checkout v3.4-rc7
HEAD is now at 36be505... Linux 3.4-rc7
$ git grep -nH CONFIG_MPC8315_DS
drivers/ata/sata_fsl.c:729:#ifdef CONFIG_MPC8315_DS
There is no kconfig support for it at all.
It was added in 2007; further, this is the only commit in the entire
git history that contains this string:
commit e7eac96e8f0e57a6e9f94943557bc2b23be31471
Author: ashish kalra <ashish.kalra@freescale.com>
Date: Wed Oct 31 19:28:02 2007 +0800
ata/sata_fsl: Move MPC8315DS link speed limit workaround to specific ifdef
Signed-off-by: ashish kalra <ashish.kalra@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 5892472..e076e1f 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -652,6 +652,7 @@ static int sata_fsl_port_start(struct ata_port *ap)
VPRINTK("HControl = 0x%x\n", ioread32(hcr_base + HCONTROL));
VPRINTK("CHBA = 0x%x\n", ioread32(hcr_base + CHBA));
+#ifdef CONFIG_MPC8315_DS
/*
* Workaround for 8315DS board 3gbps link-up issue,
* currently limit SATA port to GEN1 speed
@@ -664,6 +665,7 @@ static int sata_fsl_port_start(struct ata_port *ap)
sata_fsl_scr_read(ap, SCR_CONTROL, &temp);
dev_printk(KERN_WARNING, dev, "scr_control, speed limited to %x\n",
temp);
+#endif
return 0;
}
This otherwise-unsupported variable was noted by Robert Day in 2008;
Adrian Bunk suggested a patch, but the Freescale folks said that it
was for a not-yet-mainlined board, so the patch was dropped:
http://marc.info/?l=linux-ide&m=121783965216004&w=2
As Robert notied again in 2010, it still wasn't mainlined:
http://marc.info/?l=linux-ide&m=121783965216004&w=2
And, obviously, it still isn't today.
Can the Freescale people tell us exactly what we should be testing to
determine when to enforce this restriction? A config variable that
points to a non-existent board doesn't seem much help.
Thanks,
Tony
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Timur Tabi @ 2012-05-17 17:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, Linuxppc-dev,
Geert Uytterhoeven, Scott Wood
In-Reply-To: <1337212281.30558.17.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Thanks. These are all freescale platforms, the relevant people should be
> already but I've added Scott and Kumar to the CC list just in case.
Seeing how this is my code, I'd say the relevant people were not CC'd. :-)
Anyway, I think I see what the problem is, but it does appear when I use
the normal defconfigs. What .config was being used?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Tabi Timur-B04825 @ 2012-05-17 17:52 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <4FB535D3.7000106@freescale.com>
On Thu, May 17, 2012 at 12:30 PM, Timur Tabi <timur@freescale.com> wrote:
> Anyway, I think I see what the problem is, but it does appear when I use
> the normal defconfigs. =A0What .config was being used?
I meant to say that it does NOT appear.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Geert Uytterhoeven @ 2012-05-17 18:42 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev
In-Reply-To: <CAOZdJXW2jmFG8hkBRMAsO-CJ3ruMd28LqS0b-BGZTU7FnpRi3Q@mail.gmail.com>
On Thu, May 17, 2012 at 7:52 PM, Tabi Timur-B04825 <B04825@freescale.com> w=
rote:
> On Thu, May 17, 2012 at 12:30 PM, Timur Tabi <timur@freescale.com> wrote:
>
>> Anyway, I think I see what the problem is, but it does appear when I use
>> the normal defconfigs. =C2=A0What .config was being used?
>
> I meant to say that it does NOT appear.
powerpc randconfig.
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Timur Tabi @ 2012-05-17 18:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, Linuxppc-dev,
Geert Uytterhoeven, Scott Wood
In-Reply-To: <1337212281.30558.17.camel@pasglop>
Benjamin Herrenschmidt wrote:
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
>> fsl_diu_monitor_port' declared inside parameter list [-Werror]: =>
>> 70:9, 84:9, 88:36
>> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
>> a value, in function returning void [-Werror]: => 189:2
>> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
>> declaration isn't a prototype [-Werror=strict-prototypes]: => 69:5,
>> 88:6, 83:6, 187:1
>> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
>> only this definition or declaration, which is probably not what you
>> want [-Werror]: => 70:9
So I think I have a fix for these, but I still would like the actual
.config so that I can be sure.
>> + drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
>> use in this function): => 799:80
I can't reproduce this one. MSR_GS is defined in reg_booke.h.
fsl_hypervisor.c should not be compiled on a non-booke platform. I don't
know if the fix is to add this to fsl_hypervisor.c:
#include <asm/reg_booke.h>
or if I should update the Kconfig:
config FSL_HV_MANAGER
tristate "Freescale hypervisor management driver"
depends on FSL_SOC
to
depends on FSL_BOOKE
or maybe
depends on FSL_BOOKE && FSL_SOC
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Timur Tabi @ 2012-05-17 18:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev
In-Reply-To: <CAMuHMdVszy2sk6f045krqr=PPQFnd-GrtJYJMQCCPzkq-65psg@mail.gmail.com>
Geert Uytterhoeven wrote:
> powerpc randconfig
Doesn't this generate a different .config every time it's run? Do I keep
generating random .config files until the problem shows up?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Scott Wood @ 2012-05-17 18:48 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <4FB546FB.807@freescale.com>
On 05/17/2012 01:44 PM, Timur Tabi wrote:
> Geert Uytterhoeven wrote:
>> powerpc randconfig
>
> Doesn't this generate a different .config every time it's run? Do I keep
> generating random .config files until the problem shows up?
>
Regardless of the config that shows this, the MSR[GS] check should go
away. If you have a /hypervisor node, you already know you're a guest.
-Scott
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Timur Tabi @ 2012-05-17 18:51 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <4FB547F9.7000804@freescale.com>
Scott Wood wrote:
> Regardless of the config that shows this, the MSR[GS] check should go
> away. If you have a /hypervisor node, you already know you're a guest.
Fair enough.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] mtd: Fix typo in Kconfig
From: Frank Svendsboe @ 2012-05-17 20:43 UTC (permalink / raw)
To: linux-mtd
Cc: dbaryshkov, randy.dunlap, linuxppc-dev, Frank Svendsboe,
dedekind1
MTD_OF_PARTS and the default setting is not working due to using 'Y'
instead of 'y', introduced in commit
d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and
possibly other boards using DTS defined partitions and not having
CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root
after v3.1.
Signed-off-by: Frank Svendsboe <frank.svendsboe@gmail.com>
---
drivers/mtd/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 5760c1a..27143e0 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -128,7 +128,7 @@ config MTD_AFS_PARTS
config MTD_OF_PARTS
tristate "OpenFirmware partitioning information support"
- default Y
+ default y
depends on OF
help
This provides a partition parsing function which derives
--
1.7.5.4
^ permalink raw reply related
* [PATCH] powerpc: fix irq distribution
From: Kim Phillips @ 2012-05-18 1:11 UTC (permalink / raw)
To: linuxppc-dev
setting CONFIG_IRQ_ALL_CPUS distributes IRQs to CPUs only when
the number of online CPUs equals NR_CPUS. See commit
280ff97494e0fef4124bee5c52e39b23a18dd283 "sparc64: fix and
optimize irq distribution" for more details.
Using the online mask fixes IRQ-to-CPU distribution on systems
that boot with less than NR_CPUS.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/kernel/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 2a599ce..c05fd53 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -891,7 +891,7 @@ int irq_choose_cpu(const struct cpumask *mask)
{
int cpuid;
- if (cpumask_equal(mask, cpu_all_mask)) {
+ if (cpumask_equal(mask, cpu_online_mask)) {
static int irq_rover;
static DEFINE_RAW_SPINLOCK(irq_rover_lock);
unsigned long flags;
--
1.7.10.2
^ permalink raw reply related
* Re: [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Li Zhong @ 2012-05-18 2:54 UTC (permalink / raw)
To: Deepthi Dharwar
Cc: Paul E. McKenney, PowerPC email list, Paul Mackerras, LKML
In-Reply-To: <4FB4D14A.20903@linux.vnet.ibm.com>
On Thu, 2012-05-17 at 15:52 +0530, Deepthi Dharwar wrote:
> On 05/17/2012 09:58 AM, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
> >> This patch tries to fix following lockdep complaints:
> >
> > .../...
> >
> >> pseries_notify_cpu_idle_add_cpu() actually does
> >> cpuidle_disable_device(), and then cpuidle_enable_device(), which
> >> releases and allocates the resources respectively. ( Also, all the data
> >> are cleared and reinitialized after this cycle). The problem here is:
> >> something like kzalloc(GFP_KERNEL), wait_for_completion() would have
> >> problems running here where irqs are still disabled.
>
>
> This is true when the system is booting up.
>
> >
> > So yes, it looks definitely fishy. I don't have time to study cpuidle
> > today to check whether that's correct or not so I'm CCing Deepthi
> > Dharwar who did all that cpuidle work for pseries.
> >
> > Deepthi, can you check whether that patch is correct ?
>
>
> pseries_notify_cpu_idle_add_cpu() is essential to be called for
> hotplug event. So by removing this call completely wouldn't
> support cpus registering under cpuidle on hotplug and default idle is
> executed on those with do not give much powersavings.
Maybe I missed that part.. would you please give some details how
removing this would prevent powersaving cpuidle being called after
hotplug?
After rereading the codes, I think ppc_md.power_save() is the one you
mentioned that could give much powersavings?
It is registered as pSeries_idle(), which calls cpuidle_idle_call().
It seems to me that it would still be called after hotplug.
Or maybe I misunderstood your point?
> Ideal way it to
> have a notifier in pseries backend driver for hotplug notification and
> then remove this function from here.
> I am currently working on this patch, will post it out soon.
>
> >
> >> Actually, cpuidle_enable_device() is called for each possible cpu when
> >> the driver is registered. So I don't think the resources needed to be
> >> released and allocated each time cpu becomes online. Something like
> >> cpuidle_reset_device() would be enough to clear and reinitialize the
> >> data.
> >>
> >> However, after some studying of the data to be cleared, I think it's
> >> also reasonable to keep the previous data. For example:
> >>
> >> /sys/devices/system/cpu/cpu#/cpuidle/state#/usage
> >> the number of times this idle state has been entered
> >> /sys/devices/system/cpu/cpu#/cpuidle/state#/time
> >> the amount of time spent in this idle state
> >>
> >> So I think we could just remove the function call doing the
> >> disable/enable cycle:
> >>
> >> Please correct me if I missed anything.
>
>
> If removed, this would not handle cpu hotplug events for cpuidle.
>
>
> >>
> >> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> >> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> ---
> >> arch/powerpc/platforms/pseries/smp.c | 1 -
> >> 1 files changed, 0 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/powerpc/platforms/pseries/smp.c
> >> b/arch/powerpc/platforms/pseries/smp.c
> >> index e16bb8d..71706bc 100644
> >> --- a/arch/powerpc/platforms/pseries/smp.c
> >> +++ b/arch/powerpc/platforms/pseries/smp.c
> >> @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
> >> set_cpu_current_state(cpu, CPU_STATE_ONLINE);
> >> set_default_offline_state(cpu);
> >> #endif
> >> - pseries_notify_cpuidle_add_cpu(cpu);
> >> }
> >>
> >> static int __devinit smp_pSeries_kick_cpu(int nr)
> >
> >
> >
>
> Cheers,
> Deepthi
^ 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