On Fri, Oct 11, 2013 at 02:33:58PM +0800, Yijing Wang wrote:
>On 2013/10/11 14:16, Gavin Shan wrote:
>> On Fri, Oct 11, 2013 at 04:49:56PM +1100, Benjamin Herrenschmidt wrote:
>>> On Fri, 2013-09-06 at 14:30 -0600, Bjorn Helgaas wrote:
On Thu, Sep 05, 2013 at 03:55:27PM +0800, Yijing Wang wrot
On 2013/10/11 13:49, Benjamin Herrenschmidt wrote:
> On Fri, 2013-09-06 at 14:30 -0600, Bjorn Helgaas wrote:
>> On Thu, Sep 05, 2013 at 03:55:27PM +0800, Yijing Wang wrote:
>>> Use pci_is_pcie() to simplify code.
>>>
>>> Acked-by: Kumar Gala
>>> Reviewed-by: Gavin Shan
>>> Signed-off-by: Yijing W
On 2013/10/11 14:16, Gavin Shan wrote:
> On Fri, Oct 11, 2013 at 04:49:56PM +1100, Benjamin Herrenschmidt wrote:
>> On Fri, 2013-09-06 at 14:30 -0600, Bjorn Helgaas wrote:
>>> On Thu, Sep 05, 2013 at 03:55:27PM +0800, Yijing Wang wrote:
Use pci_is_pcie() to simplify code.
Acked-by: K
On Fri, Oct 11, 2013 at 04:49:56PM +1100, Benjamin Herrenschmidt wrote:
>On Fri, 2013-09-06 at 14:30 -0600, Bjorn Helgaas wrote:
>> On Thu, Sep 05, 2013 at 03:55:27PM +0800, Yijing Wang wrote:
>> > Use pci_is_pcie() to simplify code.
>> >
>> > Acked-by: Kumar Gala
>> > Reviewed-by: Gavin Shan
>>
On Thu, 2013-09-26 at 13:30 +1000, Anton Blanchard wrote:
> Add a VMX optimised xor, used primarily for RAID5. On a POWER7 blade
> this is a decent win:
>
>32regs: 17932.800 MB/sec
>altivec : 19724.800 MB/sec
>
> The bigger gain is when the same test is run in SMT4 mode, as it
> wou
On Fri, 2013-09-06 at 14:30 -0600, Bjorn Helgaas wrote:
> On Thu, Sep 05, 2013 at 03:55:27PM +0800, Yijing Wang wrote:
> > Use pci_is_pcie() to simplify code.
> >
> > Acked-by: Kumar Gala
> > Reviewed-by: Gavin Shan
> > Signed-off-by: Yijing Wang
> > Cc: Gavin Shan
> > Cc: Benjamin Herrenschmi
On 10/11/2013 07:41 AM, Michael Ellerman wrote:
> On Thu, Oct 10, 2013 at 02:20:22PM +0530, Anshuman Khandual wrote:
>> On 10/09/2013 11:33 AM, Michael Ellerman wrote:
>>> On Wed, Oct 09, 2013 at 10:16:32AM +0530, Anshuman Khandual wrote:
On 10/09/2013 06:51 AM, Michael Ellerman wrote:
> O
On Mon, 2013-09-30 at 23:44 +0300, Aaro Koskinen wrote:
> Hi,
>
> This is a resend of the v2 patchset:
>
> http://marc.info/?t=13779701321&r=1&w=2
>
> No changes except rebasing. Any chance to get these into v3.13?
BTW. Ack from me, Rafael feel free to merge these.
Cheers,
Ben.
___
Thanks for your review.
See my reply inline
> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: 2013年10月10日 星期四 18:04
> To: Tang Yuantian-B29983
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org;
> devicet...@vger.kernel.org; Li Yang-Leo-R58472
> Su
Add support for the arch_get_random_long() hook based on the H_RANDOM
hypervisor call. We trust the hypervisor to provide us with random data,
ie. we don't whiten it in anyway.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/pseries/Makefile | 2 +-
arch/powerpc/platforms/pseries/rng
Add a driver for the hwrng found in power7+ systems, based on the
existing code for the arch_get_random_long() hook.
We only register a single instance of the driver, not one per device,
because we use the existing per_cpu array of devices in the arch code.
This means we always read from the "clos
Add the plumbing to implement arch_get_random_long/int(). It didn't seem
worth adding an extra ppc_md hook for int, so we reuse the one for long.
Add an implementation for powernv based on the hwrng found in power7+
systems. We whiten the output of the hwrng, and the result passes all
the dieharde
On Thu, Oct 10, 2013 at 02:20:22PM +0530, Anshuman Khandual wrote:
> On 10/09/2013 11:33 AM, Michael Ellerman wrote:
> > On Wed, Oct 09, 2013 at 10:16:32AM +0530, Anshuman Khandual wrote:
> >> On 10/09/2013 06:51 AM, Michael Ellerman wrote:
> >>> On Tue, Oct 08, 2013 at 12:51:18PM +0530, Anshuman K
On Thu, 2013-10-10 at 18:25 -0500, Scott Wood wrote:
> Looking at some of the code in mm/, I suspect that the normal callers of
> set_pte_at() already have an unlock (and thus a sync)
Unlock is lwsync actually...
> already, so we may
> not even be relying on those retries. Certainly some of th
On Thu, 2013-10-10 at 17:31 -0500, Scott Wood wrote:
> On Mon, 2013-09-16 at 19:06 -0500, Scott Wood wrote:
> > On Mon, 2013-09-16 at 07:38 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2013-09-13 at 22:50 -0500, Scott Wood wrote:
> > > > The ISA says that a sync is needed to order a PTE write
Just to help us all understand "the loop" issue..
Here's an example of driver code which uses the existing MSI-X interfaces,
for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt.
This is from a new driver I'm working on right now:
static int xx_alloc_msix_irqs (struct xx_dev
On Mon, 2013-09-16 at 19:06 -0500, Scott Wood wrote:
> On Mon, 2013-09-16 at 07:38 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-09-13 at 22:50 -0500, Scott Wood wrote:
> > > The ISA says that a sync is needed to order a PTE write with a
> > > subsequent hardware tablewalk lookup. On e6500
On Thu, 2013-10-10 at 14:07 +0300, Claudiu Manoil wrote:
> On 10/4/2013 3:28 PM, Thomas Hühn wrote:
> >
> > [code]
> > [ 2671.841927] Oops: Exception in kernel mode, sig: 5 [#1]
> > [ 2671.847141] Freescale P1014
> > [ 2671.849925] Modules linked in: ath9k pppoe ppp_async iptable_nat
> > ath9k_comm
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Bhushan Bharat-R65777
> Sent: Tuesday, October 08, 2013 10:40 PM
> To: j...@8bytes.org; Bjorn Helgaas
> Cc: alex.william...@redhat.com; b...@kernel.crashing.org;
> g
On Thu, 2013-10-10 at 20:09 +, Sethi Varun-B16395 wrote:
>
> > -Original Message-
> > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> > boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
> > Sent: Tuesday, October 08, 2013 8:43 AM
> > To: Bhushan Bharat-R6
From: Joseph Myers
The e500 SPE floating-point emulation code is called from
SPEFloatingPointException and SPEFloatingPointRoundException in
arch/powerpc/kernel/traps.c. Those functions have support for
generating SIGFPE, but do_spe_mathemu and speround_handler don't
generate a return value to i
> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
> Sent: Tuesday, October 08, 2013 8:43 AM
> To: Bhushan Bharat-R65777
> Cc: ag...@suse.de; Wood Scott-B07421; linux-...@vger.kernel.org;
Hello,
On Thu, 10 Oct 2013 11:23:55 -0700
Brian Norris wrote:
...
> > making mpc512x_setup_diu(), mpc512x_release_bootmem(),
> > mpc512x_valid_monitor_port() and void mpc512x_set_pixel_clock()
> > should be okay.
>
> And mpc512x_init_diu()?
yes, it can be static, too.
>
> >> Then, you can get
Hello,
On Thu, Oct 10, 2013 at 9:09 AM, Anatolij Gustschin wrote:
> On Wed, 9 Oct 2013 12:29:31 -0700
> Brian Norris wrote:
> ...
>> > +#else
>> > +void __init mpc512x_setup_diu(void) { /* EMPTY */ }
>> > +void __init mpc512x_init_diu(void) { /* EMPTY */ }
>> > #endif
>> >
>> > void __init mpc
On Thu, Oct 10, 2013 at 09:28:27AM -0700, H. Peter Anvin wrote:
> On 10/10/2013 03:17 AM, Alexander Gordeev wrote:
> > On Wed, Oct 09, 2013 at 03:24:08PM +1100, Benjamin Herrenschmidt wrote:
> >
> > Ok, this suggestion sounded in one or another form by several people.
> > What about name it pcim_e
Hi,
I'm running Linux on a PowerPC-44x based board with 256 Megabytes of RAM at
0x5000. - 0x6000..Upon an error interrupt, I should load my recovery
module(non-Linux kernel) at 0x4000. and jump the execution to this.
Any suggestions for this implementation?
Would kexec allow me to lo
On 10/10/2013 03:17 AM, Alexander Gordeev wrote:
> On Wed, Oct 09, 2013 at 03:24:08PM +1100, Benjamin Herrenschmidt wrote:
>
> Ok, this suggestion sounded in one or another form by several people.
> What about name it pcim_enable_msix_range() and wrap in couple more
> helpers to complete an API:
>
Hi,
On Wed, 9 Oct 2013 12:29:31 -0700
Brian Norris wrote:
...
> > +#else
> > +void __init mpc512x_setup_diu(void) { /* EMPTY */ }
> > +void __init mpc512x_init_diu(void) { /* EMPTY */ }
> > #endif
> >
> > void __init mpc512x_init_IRQ(void)
>
> I see an alternative solution:
>
> Can't almost
On Thu, Oct 03, 2013 at 09:48:39PM +0200, Alexander Gordeev wrote:
>
> pci_enable_msix() may fail, but it can not return a positive number.
>
That is true according to the current logic but the comment on top of
pci_enable_msix() still says:
"A return of < 0 indicates a failure. Or a return of >
On Thu, 2013-10-10 at 16:54 +0200, Mercier Ivan wrote:
> Hi,
> I've got a KERN_INFO msg: "fsl-lbc a3p400.11: failed to get memory
> region" corresponding to my elbc device that I try to map.
> a3p400@3,0 {
> compatible = "fsl,elbc";
>
Hi,
I've got a KERN_INFO msg: "fsl-lbc a3p400.11: failed to get memory
region" corresponding to my elbc device that I try to map.
a3p400@3,0 {
compatible = "fsl,elbc";
reg = <0 0xe000 0x100>;
};
The correspondin
On 10/4/2013 3:28 PM, Thomas Hühn wrote:
[code]
[ 2671.841927] Oops: Exception in kernel mode, sig: 5 [#1]
[ 2671.847141] Freescale P1014
[ 2671.849925] Modules linked in: ath9k pppoe ppp_async iptable_nat
ath9k_common pppox p
e xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_qu
On Thu, 2013-10-10 at 21:06 +1100, Paul Mackerras wrote:
> On Thu, Oct 10, 2013 at 07:18:35PM +1100, Benjamin Herrenschmidt wrote:
> > The debugfs interface was essentially unused, and racy for anything
> > other than manual use by a developer. This provides a more useful
> > sysfs based one which
On Wed, Oct 09, 2013 at 03:24:08PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-10-08 at 20:55 -0700, H. Peter Anvin wrote:
> > Why not add a minimum number to pci_enable_msix(), i.e.:
> >
> > pci_enable_msix(pdev, msix_entries, nvec, minvec)
> >
> > ... which means "nvec" is the number of
On Thu, Oct 10, 2013 at 07:18:35PM +1100, Benjamin Herrenschmidt wrote:
> The debugfs interface was essentially unused, and racy for anything
> other than manual use by a developer. This provides a more useful
> sysfs based one which can be used by programs without racing with
> each other essentia
On Wed, Oct 09, 2013 at 07:38:24AM +0100, yuantian.t...@freescale.com wrote:
> From: Tang Yuantian
>
> The following SoCs will be affected: p2041, p3041, p4080,
> p5020, p5040, b4420, b4860, t4240
>
> Signed-off-by: Tang Yuantian
> Signed-off-by: Li Yang
> ---
> v5:
> - refine the bindin
On 10/09/2013 11:33 AM, Michael Ellerman wrote:
> On Wed, Oct 09, 2013 at 10:16:32AM +0530, Anshuman Khandual wrote:
>> On 10/09/2013 06:51 AM, Michael Ellerman wrote:
>>> On Tue, Oct 08, 2013 at 12:51:18PM +0530, Anshuman Khandual wrote:
On 10/08/2013 09:51 AM, Michael Ellerman wrote:
> O
Indirect XSCOM addresses normally have the top bit set (of the 64-bit
address). This doesn't work via the normal sysfs interface, so we use
a different encoding, which we need to convert before calling OPAL.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/platforms/powernv/opal-xscom.c |
The debugfs interface was essentially unused, and racy for anything
other than manual use by a developer. This provides a more useful
sysfs based one which can be used by programs without racing with
each other essentially by providing a file to read/write with an
offset being the scom address << 8
On P8, XSCOM addresses has a special "indirect" form that
requires more than 32-bits, so let's use u64 everywhere in
the code instead of u32.
Signed-off-by: Benjamin Herrenschmidt
---
This applies on top of my previously posted scom series
arch/powerpc/include/asm/scom.h | 8 --
40 matches
Mail list logo
