On Mon, 2013-09-09 at 08:35 +1000, Paul Mackerras wrote:
>
> Also, you need to indent your code correctly according to
> Documentation/CodingStyle.
Looks like the patch has been mangled by the mailer ... it's in HTML to
begin with :-)
Tom, you need to find a mailer setup that works for sending p
On Mon, 2013-09-09 at 18:37 -0700, Guenter Roeck wrote:
> powerpc allmodconfig build fails with:
>
> ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
>
> The problem was introduced with commit 15863ff3b (powerpc: Make chip-id
> information available to userspace).
Thanks,
On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
> On 09/08/2013 5:28 PM, Guenter Roeck wrote:
> > Hi all,
> >
> > powerpc allmodconfig build on the latest upstream kernel results in:
> >
> > ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> >
> > This is due to co
On Tue, 2013-09-10 at 18:47 -0500, Scott Wood wrote:
> No blank line before }
>
> > +CONFIG_CMDLINE_BOOL=y
> > +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
>
> I take it there's no way to pass a command line in from whatever loader
> this board uses... but you could put it in the d
Hi Linus !
Here are a handful of small powerpc fixes. A couple of section mismatches
(always worth fixing), a missing export of a new symbol causing build
failures of modules, a page fault deadlock fix (interestingly that
bug has been around for a LONG time, though it seems to be more easily
trigg
On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote:
> I wonder why we don't start from entry 31 so we can actually make use of
> that autodecrement. What will happen when we load the first normal TLB
> entry later on? I don't see any setting of SPRN_MD_CTR after this code,
> so won't it overwrit
On Fri, 2013-09-13 at 15:10 +1000, Michael Ellerman wrote:
> Looks like you merged the version with #define DEBUG.
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/setup_64.c#n13
Yes, it looks like I've been distracted, I'll remove it again (or you
can
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, without this sync
> we've been observed to die with a DSI due to a PTE write not being seen
> by a subsequent access, even when ev
fixes it by moving the stack switching up a level, making
irq_enter() and irq_exit() run off the irq stack.
Signed-off-by: Benjamin Herrenschmidt
---
This is the "band aid" discussed so far for the stack overflow
problem for powerpc. I assume sparc and i386 at least need
something simila
On Mon, 2013-09-23 at 17:56 +1000, Stephen Rothwell wrote:
> Hi Ben,
>
> On Mon, 23 Sep 2013 14:35:58 +1000 Benjamin Herrenschmidt
> wrote:
> >
> > diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> > index c69440c..0c9646f 100644
> > --- a
On Mon, 2013-09-23 at 09:47 -0700, Linus Torvalds wrote:
> On Sun, Sep 22, 2013 at 9:35 PM, Benjamin Herrenschmidt
> wrote:
> >
> > This is the "band aid" discussed so far for the stack overflow
> > problem for powerpc.
>
> I don't think it
re, let's remove the code completely from 64-bit. In order to avoid
a clutter of ifdef's, we remove the updates from C code completely
during interrupt stack switching, and instead maintain it from the
asm helper that is used to do the stack switching in the first place.
Signed-off-by: B
fixes it by moving the stack switching up a level, making
irq_enter() and irq_exit() run off the irq stack.
Signed-off-by: Benjamin Herrenschmidt
v2: Garbage collect now empty handle_one_irq()
---
arch/powerpc/include/asm/irq.h | 4 +-
arch/powerpc/kernel/irq.c | 104
This makes the "OF" zImage wrapper (zImage.pseries, zImage.pmac,
zImage.maple) work if booted via a flat device-tree (ePAPR boot
mode), and thus potentially usable with kexec.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/boot/Makefile| 4 ++--
arch/powerpc/
Starting secondary CPUs early on from Open Firmware and placing them
in a holding spin loop slows down the boot process significantly under
some hypervisors such as KVM.
This is also unnecessary when RTAS supports querying the CPU state
So let's not do it.
Signed-off-by: Benjamin Herrensc
rge
for you to fetch changes up to dbe78b40118636f2d5d276144239dd4bfd5f04f9:
powerpc/pseries: Do not start secondaries in Open Firmware (2013-09-25
14:19:00 +1000)
----
Benjamin Herrenschmidt (4):
powerpc/irq: Run so
On Thu, 2013-09-26 at 16:31 +1000, Michael Ellerman wrote:
> + pr_info_once("registering arch random hook\n");
Either pr_debug or make it nicer looking :-)
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.oz
On Thu, 2013-09-26 at 16:31 +1000, Michael Ellerman wrote:
> + pr_info("registered powernv hwrng.\n");
First letter of a line should get a capital :-) Also since
it's per-device, at least indicate the OF path or the chip number or
something ...
Cheers,
Ben.
_
On Thu, 2013-09-26 at 14:22 -0700, Greg Kroah-Hartman wrote:
> So, I shouldn't apply this patch? We should do something to fix this,
> if Debian has to drag this patch on for 5 years, that's an indication
> that this might be one solution we should use, right?
Ah sorry, dropped the ball on that
On Fri, 2013-09-27 at 13:32 +0530, Madhavan Srinivasan wrote:
> powerpc/kernel/sysfs.c exports purr with write permission.
> This may be valid for powernv kernel since purr is Hyp resource.
> But writing to the file in PowerVM lpar causes crash.
Testing powernv isn't right, you should test for hyp
Hi Linus, Yinghai !
Please consider reverting:
928bea964827d7824b548c1f8e06eccbbc4d0d7d
PCI: Delay enabling bridges until they're needed
(I'd suggest to revert now and maybe merge a better patch later)
This breaks PCI on the PowerPC "powernv" platform (which is booted via
kexec) and probably x8
On Fri, 2013-09-27 at 10:10 -0700, Linus Torvalds wrote:
> > So i would like to use the first way that you suggest : call pci_set_master
> > PCIe port driver.
>
> So I have to say, that if we can fix this with just adding a single
> new pci_set_master() call, we should do that before we decide to
On Fri, 2013-09-27 at 14:54 -0700, Yinghai Lu wrote:
> On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
> wrote:
>
> > Wouldn't it be better to simply have pci_enable_device() always set bus
> > master on a bridge? I don't see any case where it makes sens
On Fri, 2013-09-27 at 10:44 -0700, Yinghai Lu wrote:
> |/* Get and check PCI Express port services */
> |capabilities = get_port_device_capability(dev);
> |if (!capabilities)
> |return 0;
> |
> |pci_set_master(dev);
>
> so how come that pci_set_maste
On Fri, 2013-09-27 at 14:54 -0700, Yinghai Lu wrote:
> On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
> wrote:
>
> > Wouldn't it be better to simply have pci_enable_device() always set bus
> > master on a bridge? I don't see any case where it makes sens
On Fri, 2013-09-27 at 15:56 -0700, Yinghai Lu wrote:
> ok, please if you are ok attached one instead. It will print some warning
> about
> driver skipping pci_set_master, so we can catch more problem with drivers.
Except that the message is pretty cryptic :-) Especially since the
driver causing
On Fri, 2013-09-27 at 16:44 -0700, Yinghai Lu wrote:
> > Thus the port driver bails out before calling pci_set_master(). The fix
> > is to call pci_set_master() unconditionally. However that lead me to
> > find to a few interesting oddities in that port driver code:
>
> can we revert that partial
On Mon, 2013-09-30 at 12:29 -0700, Linus Torvalds wrote:
>
> But I'm cc'ing the POWER people, because I don't know the POWER8
> interfaces, and I don't want to necessarily call this "xbegin"/"xend"
> when I actually wrap it in some helper functions.
The main problem with powerpc TM is that we nee
On Mon, 2013-09-30 at 17:56 -0700, Linus Torvalds wrote:
> On Mon, Sep 30, 2013 at 5:36 PM, Michael Neuling wrote:
> >
> > The scary part is that we to make all register volatile. You were not
> > that keen on doing this as there are a lot of places in exception
> > entry/exit where we only save/
On Tue, 2013-10-01 at 16:31 +1000, Michael Ellerman wrote:
> > 1)Changed the test for to hypervisor mode instead of platform
>
> I think Ben's wrong about that.
>
> Almost all existing code uses FW_FEATURE_LPAR to differentiate
> hypervisor vs guest mode, so I think we should do the same here.
On Tue, 2013-10-01 at 11:39 +0300, Gleb Natapov wrote:
> On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
> > On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
> > > Il 26/09/2013 08:31, Michael Ellerman ha scritto:
> > > > Some powernv systems include a hwrng. Guests
On Tue, 2013-10-01 at 13:19 +0200, Paolo Bonzini wrote:
> Il 01/10/2013 11:38, Benjamin Herrenschmidt ha scritto:
> > So for the sake of that dogma you are going to make us do something that
> > is about 100 times slower ? (and possibly involves more lines of code)
>
> If
On Wed, 2013-10-02 at 10:46 +0200, Paolo Bonzini wrote:
>
> Thanks. Any chance you can give some numbers of a kernel hypercall and
> a userspace hypercall on Power, so we have actual data? For example a
> hypercall that returns H_PARAMETER as soon as possible.
I don't have (yet) numbers at han
On Wed, 2013-10-02 at 11:11 +0200, Alexander Graf wrote:
> Right, and the difference for the patch in question is really whether
> we handle in in kernel virtual mode or in QEMU, so the bulk of the
> overhead (kicking threads out of guest context, switching MMU
> context, etc) happens either way.
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
> Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> interface is disabled? Also hwrnd is MMIO in a host why guest needs to
> use hypercall instead of emulating the device (in kernel or somewhere
> else?).
Migration wil
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
> Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> interface is disabled? Also hwrnd is MMIO in a host why guest needs to
> use hypercall instead of emulating the device (in kernel or somewhere
> else?). Another things
On Wed, 2013-10-02 at 16:08 +0200, Alexander Graf wrote:
> A guest should live on the same permission level as a user space
> application. If you run QEMU as UID 1000 without access to /dev/mem,
> why should the guest suddenly be able to directly access a memory
> location (MMIO) it couldn't access
On Wed, 2013-10-02 at 17:10 +0300, Gleb Natapov wrote:
> > The hwrng is accessible by host userspace via /dev/mem.
> >
> Regular user has no access to /dev/mem, but he can start kvm guest and
> gain access to the device.
Seriously. You guys are really trying hard to make our life hell or
what ? T
On Wed, 2013-10-02 at 17:37 +0300, Gleb Natapov wrote:
> On Wed, Oct 02, 2013 at 04:33:18PM +0200, Paolo Bonzini wrote:
> > Il 02/10/2013 16:08, Alexander Graf ha scritto:
> > > > The hwrng is accessible by host userspace via /dev/mem.
> > >
> > > A guest should live on the same permission level a
On Thu, 2013-10-03 at 08:43 +0300, Gleb Natapov wrote:
> Why it can be a bad idea? User can drain hwrng continuously making other
> users of it much slower, or even worse, making them fall back to another
> much less reliable, source of entropy.
Not in a very significant way, we generate entropy a
On Sat, 2013-10-05 at 16:20 +0200, Alexander Gordeev wrote:
> So my point is - drivers should first obtain a number of MSIs they *can*
> get, then *derive* a number of MSIs the device is fine with and only then
> request that number. Not terribly different from memory or any other type
> of resourc
On Sun, 2013-10-06 at 08:02 +0200, Alexander Gordeev wrote:
> On Sun, Oct 06, 2013 at 08:46:26AM +1100, Benjamin Herrenschmidt wrote:
> > On Sat, 2013-10-05 at 16:20 +0200, Alexander Gordeev wrote:
> > > So my point is - drivers should first obtain a number of MSIs they *ca
On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote:
> I don't think the same race condition would happen with the loop. The
> problem case is where multiple msi(x) allocation fails completely
> because the global limit went down before inquiry and allocation. In
> the loop based interface, it'd r
all nesting from softirq
stack to irq stack even in the "safe" case but it's simpler that way
and matches what x86_64 does.
Reported-by: Cédric Le Goater
Tested-by: Cédric Le Goater
Signed-off-by: Benjamin Herrenschmidt
---
Linus, I don't have my git repo at hand right no
With OPALv3, the firmware can provide the address of it's internal console
to Linux, which we can then display using debugfs. This is handy for
diagnostics and debugging.
Signed-off-by: Benjamin Herrenschmidt
---
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/plat
On Tue, 2013-10-08 at 18:20 -0500, Scott Wood wrote:
> > So I'll apply these given an ack from the powerpc folks.
>
> ACK this patch. The second one I'd like to see broken up into
> digestible chunks so I can better review it.
Bjorn, for such FSL-only stuff, Scott ack is enough, don't wait for
m
On Wed, 2013-10-09 at 14:23 +1100, Michael Ellerman wrote:
> On Tue, Oct 08, 2013 at 06:46:40PM +1100, Benjamin Herrenschmidt wrote:
> > With OPALv3, the firmware can provide the address of it's internal console
> > to Linux, which we can then display using debugf
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 interrupts *requested*, and
> "minvec" is the minimum acceptable number (otherwise
On Wed, 2013-10-09 at 17:06 +1100, Michael Ellerman wrote:
> Call it twice.
>
> And you wonder why no one reviews your patches?
Not that easy :-) I had a look at using it and unless I did something
stupid, it wasn't actually that trivial to figure out what arg to pass
it for calling it twice, ie,
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.
It requires 8 bytes aligned and multiple of 8 bytes sized accesses
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/configs/chroma_defconfig | 2 +-
arch/powerpc/sysdev/Kconfig | 6 +-
arch/powerpc/sysdev/scom.c| 210 +-
3
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-xs
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
> >
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 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.
___
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
>
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 Tue, 2013-07-02 at 17:07 +0200, Hendrik Brueckner wrote:
> Introduce a new callback to explicitly handle the HUPCL termios control flag.
> This prepares for a follow-up commit for the hvc_iucv device driver to
> improve handling when to drop an established network connection.
>
> The callback n
On Fri, 2013-10-11 at 14:47 +0200, Hendrik Brueckner wrote:
> The tiocmget/tiocmset callbacks are used to set and get modem status and
> triggered through an tty ioctl.
>
> The dtr_rts() callback is different and it is used for DTS/RTS handshaking
> between the hvc_console (or any other tty_port)
On Fri, 2013-10-11 at 17:07 -0500, Scott Wood wrote:
> On Fri, 2013-10-11 at 10:51 +1100, Benjamin Herrenschmidt wrote:
> > 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
> >
On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> I've tracked the start of the strange instruction pointers in 'perf
> report' to a commit by Anton:
>
> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> Author: Anton Blanchard
> Date: Tue Jun 26 01:01:36 2012 +
>
> powerpc/perf
On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> >> I've tracked the start of the strange instruction pointers in 'perf
&g
On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> > > On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> > > wrote:
> > >
On Tue, 2013-10-15 at 17:36 +0200, Hendrik Brueckner wrote:
> Hi Benjamin,
>
> On Sat, Oct 12, 2013 at 07:43:24AM +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-10-11 at 14:47 +0200, Hendrik Brueckner wrote:
> > > The tiocmget/tiocmset callbacks are used to set
_DEBUG_PERF_USE_VMALLOC is not set
> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep BOOK3S .config
> CONFIG_PPC_BOOK3S_32=y
> CONFIG_PPC_BOOK3S=y
>
> more below...
>
> On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2013-10-15 at
On Wed, 2013-10-16 at 17:16 -0400, Martin Hicks wrote:
> That does fix the problem. v3.11 with the following:
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index eeae308..e91cf67 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-
On Wed, 2013-10-16 at 11:04 +0200, Hendrik Brueckner wrote:
> Indeed, two callbacks change the DTR line. The main difference is that
> tiocmget/tiocmset can be called from user space by ioctl. That's not the case
> for the dtr_cts callback. Also, tiocmget/tiocmset provide more flags that can
> b
On Thu, 2013-10-17 at 04:53 +0100, Ben Hutchings wrote:
> Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 introduces a trivial
> local denial of service.
Oops. Prarit, please send a fix asap ! I'm travelling right now.
Thanks !
Ben.
> > --- a/arch/powerpc/kernel/vio.c
> > +++ b/arch/powerpc/kern
On Wed, 2013-10-23 at 23:06 -0500, Kumar Gala wrote:
> On Oct 23, 2013, at 5:15 AM, Scott Wood wrote:
>
> > On Wed, 2013-10-23 at 00:07 -0500, Kumar Gala wrote:
> >> On Oct 18, 2013, at 2:38 AM, Wolfgang Denk wrote:
> >>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> >>>
On Fri, 2013-10-25 at 10:58 +0100, David Laight wrote:
> > This is not a distro issue. It's a libstdc++ portability issue. libstdc++
> > hardcodes lwsync unless __NO_LWSYNC__ is explicitly defined,
> > which you only get with -mcpu=8540/-mcpu=8548. When compiled
> > for any powerpc target other th
On Mon, 2013-10-28 at 04:26 -0700, Christian Kujau wrote:
> Hi,
>
> for quite some time the following is printed (twice) after doing
> "make oldconfig":
>
> [...]
> scripts/kconfig/conf --oldconfig Kconfig
> warning: (ADB_PMU_LED_IDE) selects LEDS_TRIGGER_IDE_DISK which has unmet
> direct depend
On Fri, 2013-10-18 at 14:40 -0500, Tom Musta wrote:
> This patch modifies the endian chicken switch in the single step
> emulation code (emulate_step()). The old (big endian) code bailed
> early if a load or store instruction was to be emulated in little
> endian mode.
>
> The new code modifies t
On Tue, 2013-10-29 at 21:25 -0700, Christian Kujau wrote:
> On Wed, 30 Oct 2013 at 10:13, Benjamin Herrenschmidt wrote:
> > You probably want to do that to the ADB_PMU_LED_IDE entry not the
> > ADB_PMU_LED one which doesn't have a dependency and isn't the one
> >
On Wed, 2013-10-30 at 17:14 +0100, Cédric Le Goater wrote:
> @@ -552,25 +552,25 @@ static void __init offb_init_nodriver(struct
> device_node *dp, int no_real_node)
> if (pp == NULL)
> pp = of_get_property(dp, "depth", &len);
> if (pp && len == sizeof(u32))
> -
On Wed, 2013-09-18 at 11:53 +0100, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha
>
> Since the definition of_find_next_cache_node is architecture independent,
> the existing definition in powerpc can be moved to driver/of/base.c
>
> Cc: Benjamin Herrenschmidt
On Thu, 2013-10-31 at 10:32 +, Sudeep KarkadaNagesha wrote:
> Thanks for the follow up. Grant wanted to see usage of this outside PPC and I
> pointed him[0] to the RFC[1] I had posted to support cacheinfo on ARM.
>
> These patches are based on v3.12-rc1, let me know if you want me to
> rebase
On Fri, 2013-11-01 at 17:24 -0500, Rob Herring wrote:
> On 11/01/2013 12:20 AM, Stephen Rothwell wrote:
> > Hi Rob,
> >
> > Today's linux-next merge of the dt-rh tree got a conflict in
> > arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of:
> > Move definition of of_find_next_cache_
On Fri, 2013-11-01 at 18:30 +0200, Victor Kaplansky wrote:
> "David Laight" wrote on 11/01/2013 06:25:29 PM:
> > gcc will do unexpected memory accesses for bit fields that are
> > adjacent to volatile data.
> > In particular it may generate 64bit sized (and aligned) RMW cycles
> > when accessing b
On Sun, 2013-11-03 at 16:17 +0100, Peter Zijlstra wrote:
> On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote:
> > If there was an smp_tmb(), I would likely use it in rcu_assign_pointer().
>
> Well, I'm obviously all for introducing this new barrier, for it will
> reduce a full mfenc
s a no-brainer.
Signed-off-by: Benjamin Herrenschmidt
---
This replaces the previously posted
"powerpc/scom: Replace debugfs interface with cleaner sysfs"
After discussion with Greg KH, we decided that debugfs was the
right place to put that faci
On Thu, 2013-10-31 at 13:38 -0500, Tom wrote:
> From: Tom Musta
>
> This patch modifies the unaligned access routines of the sstep.c
> module so that it properly reverses the bytes of storage operands
> in the little endian kernel kernel.
Do that patch differ from v1 ? (I already merged v1)
Che
On Thu, 2013-10-31 at 13:38 -0500, Tom wrote:
> From: Tom Musta
>
> This patch addresses unaligned single precision floating point loads
> and stores in the single-step code. The old implementation
> improperly treated an 8 byte structure as an array of two 4 byte
> words, which is a classic lit
ing the code so that the PPR value is loaded into
a GPR before MSR:RI is cleared.
Signed-off-by: Benjamin Herrenschmidt
---
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index 8deaaad..3c1acc3 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powe
On Tue, 2013-11-05 at 10:04 -0500, Alan Stern wrote:
> On Tue, 5 Nov 2013, Alistair Popple wrote:
>
> > The IBM Akebono board has an EHCI compliant USB host interface. This
> > patch adds support for it to the EHCI platform driver.
> >
> > Signed-off-by: Alistair Popple
> > Cc: Alan Stern
> > C
On Tue, 2013-11-05 at 18:16 +, Ben Hutchings wrote:
> On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
> [...]
> > --- a/drivers/net/ethernet/ibm/emac/Kconfig
> > +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> > @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> > bool
> > default n
> >
On Wed, 2013-11-06 at 12:38 +1100, Alistair Popple wrote:
> > Right, rgmii_mode_name() just has informative purposes and should be
> > removed, I would suggest using standard device tree bindings
> property
> > (phy-mode) anyway such that you could use of_get_phy_mode() and use
> > phy_interface_t
doesn't work
and an explicit rule must be added.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/boot/wrapper | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index ac16e99..2e1af74 100755
--- a/arch/powerpc/boot/wrappe
On Wed, 2013-11-06 at 14:50 +1100, Alistair Popple wrote:
> Actually a grep of "usb-ehci" turns up the ehci-ppc-of driver which I somehow
> missed. This driver works and uses .compatible = "usb-ehci" so I can use that
> instead if that is preferable?
>
> However it is basically the same as the e
On Wed, 2013-11-06 at 18:39 +1100, Alistair Popple wrote:
> diff --git a/arch/powerpc/boot/dts/sequoia.dts
> b/arch/powerpc/boot/dts/sequoia.dts
> index b1d3292..e28371e 100644
> --- a/arch/powerpc/boot/dts/sequoia.dts
> +++ b/arch/powerpc/boot/dts/sequoia.dts
> @@ -153,7 +153,7 @@
>
On Wed, 2013-11-06 at 12:24 +0100, Alexander Graf wrote:
> On 05.11.2013, at 08:42, Liu Ping Fan wrote:
>
> > Signed-off-by: Liu Ping Fan
>
> Patch description missing.
Do you really need a description for trivial one-lines whose subject
is a perfectly complete description already ?
> Please
On Thu, 2013-11-07 at 14:34 +1100, Alistair Popple wrote:
> Thanks. Based on the discussion for the EHCI driver I would like to change
> the
> compatibility string to "usb-ochi" (instead of "ibm,akebono-ohci"). Are you
> still happy for me to add the Acked-by with the alternate compatibility (an
On Thu, 2013-11-07 at 09:45 +0530, Deepthi Dharwar wrote:
> 'powerpc' would be very generic arch and would comprise of all platforms
> including embedded 32/64 bit to server 64 bit (similar to that of ARM).
> This driver does not intend to support complete powerpc arch, but just
> PSERIES and POWER
On Thu, 2013-11-07 at 08:52 +0100, Alexander Graf wrote:
> Am 06.11.2013 um 20:58 schrieb Benjamin Herrenschmidt
> :
>
> > On Wed, 2013-11-06 at 12:24 +0100, Alexander Graf wrote:
> >> On 05.11.2013, at 08:42, Liu Ping Fan wrote:
> >>
> >>>
On Thu, 2013-11-07 at 09:14 +0100, Alexander Graf wrote:
> > And ? An explanation isn't going to be clearer than the code in that
> > case ...
>
> It's pretty non-obvious when you do a git show on that patch in 1 year
> from now, as the redundancy is out of scope of what the diff shows.
And ? How
On Fri, 2013-11-08 at 04:10 +0100, Alexander Graf wrote:
> On 08.11.2013, at 03:44, Liu Ping Fan wrote:
>
> > syscall is a very common behavior inside guest, and this patch
> > optimizes the path for the emulation of BOOK3S_INTERRUPT_SYSCALL,
> > so hypervisor can return to guest without heavy ex
On Fri, 2013-11-08 at 15:05 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2013-11-08 at 04:10 +0100, Alexander Graf wrote:
> > On 08.11.2013, at 03:44, Liu Ping Fan wrote:
> >
> > > syscall is a very common behavior inside guest, and this patch
> > > optimi
igs
powerpc: Use 32 bit loads and stores when operating on condition register
values
powerpc: Add VMX optimised xor for RAID5
Bartlomiej Zolnierkiewicz (2):
powerpc/legacy_serial: Fix incorrect placement of __initdata tag
powerpc/8xx/tqm8xx: Fix incorrect placement of __i
From: Heiko Carstens
__get_user_pages_fast() may be called with interrupts disabled (see e.g.
get_futex_key() in kernel/futex.c) and therefore should use local_irq_save()
and local_irq_restore() instead of local_irq_disable()/enable().
Signed-off-by: Heiko Carstens
---
(Was originally sent to
for the kernel? I mean when I
> > see
> > head.S for the ppc64 architecture (all files are from 2.6.10 by the way),
> > I
> > do see an unconditional branch for do_hash_page wherein we "try to insert
> > an
> > HPTE". Within do_hash_page, af
On Mon, 2012-12-10 at 21:43 +, Grant Likely wrote:
> > Sorry for my pci ignorance (have never got hw for mb/zynq)
> > I just want to get better overview how we should we our drivers to
> be compatible.
> >
> > Does it mean that pci is supposed be always 64 bit wide?
> > And there is no option
701 - 800 of 7623 matches
Mail list logo
