On Tue, 2019-01-15 at 23:49 +0100, Tobias Ulmer wrote:
> Hi,
>
> both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
>
> Surely I'm not the first to run into this, but I couldn't find any
> discussion or bug report. Sorry if you're already aware.
>
> You can see it hang here
On Wed, 2019-01-09 at 17:32 +1100, Alexey Kardashevskiy wrote:
> I have just moved the "Mellanox Technologies MT27700 Family
> [ConnectX-4]" from garrison to firestone machine and there it does not
> produce an EEH, with the same kernel and skiboot (both upstream + my
> debug). Hm. I cannot really
On Wed, 2019-01-09 at 15:53 +1100, Alexey Kardashevskiy wrote:
> "A PCI completion timeout occurred for an outstanding PCI-E transaction"
> it is.
>
> This is how I bind the device to vfio:
>
> echo vfio-pci > '/sys/bus/pci/devices/:01:00.0/driver_override'
> echo vfio-pci >
On Mon, 2019-01-07 at 21:01 -0700, Jason Gunthorpe wrote:
>
> > In a very cryptic way that requires manual parsing using non-public
> > docs sadly but yes. From the look of it, it's a completion timeout.
> >
> > Looks to me like we don't get a response to a config space access
> > during the
On Sat, 2019-01-05 at 10:51 -0700, Jason Gunthorpe wrote:
>
> > Interesting. I've investigated this further, though I don't have as
> > many new clues as I'd like. The problem occurs reliably, at least on
> > one particular type of machine (a POWER8 "Garrison" with ConnectX-4).
> > I don't yet
On Thu, 2018-12-27 at 11:05 -0800, Guenter Roeck wrote:
> Hi,
>
> I am getting the attached runtime warnings when enabling certain debug
> options in powerpc code. The warnings are seen with pretty much all
> platforms, and all active kernel releases.
>
> Question: Is it worthwhile to keep
On Wed, 2018-10-17 at 10:01 +0200, Christoph Hellwig wrote:
> This option isn't actually used anywhere.
Oh my, that's ancient. Probably didn't make the cut from arch/ppc to
arch/powerpc
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc
On Thu, 2018-12-20 at 21:02 -0500, Steven Rostedt wrote:
> On Fri, 21 Dec 2018 12:11:35 +1100
> Benjamin Herrenschmidt wrote:
>
> > Hi Steven !
> >
> > I'm trying to untangle something, and I need your help :-)
> >
> > In commit 3cb5f1a3e58c0bd70d47
On Tue, 2018-10-09 at 15:24 +0200, Christoph Hellwig wrote:
> * Find the least restrictive zone that is entirely below the
> @@ -324,11 +305,14 @@ void __init paging_init(void)
> printk(KERN_DEBUG "Memory hole size: %ldMB\n",
>(long int)((top_of_ram - total_ram) >> 20));
Hi Steven !
I'm trying to untangle something, and I need your help :-)
In commit 3cb5f1a3e58c0bd70d47d9907cc5c65192281dee, you added a summy
stack frame around the assembly calls to trace_hardirqs_on/off on the
ground that when using the latency tracer (irqsoff), you might poke at
CALLER_ADDR1
> > /*
> >* MSR_KERNEL is > 0x1 on 4xx/Book-E since it include MSR_CE.
> > @@ -205,20 +208,46 @@ transfer_to_handler_cont:
> > mflrr9
> > lwz r11,0(r9) /* virtual address of handler */
> > lwz r9,4(r9)/* where to go when done */
> >
o it a bit more.
I'll work more on this in the next few days, comments appreciated.
Not-signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/entry_32.S | 113 ++-
arch/powerpc/kernel/head_44x.S | 9 +--
arch/powerpc/kernel/head_booke.h
On Wed, 2018-12-19 at 08:50 +0530, Aneesh Kumar K.V wrote:
> Christoph Hellwig writes:
>
> > On Tue, Dec 18, 2018 at 03:11:37PM +0530, Aneesh Kumar K.V wrote:
> > > +EXPORT_SYMBOL(huge_ptep_modify_prot_start);
> >
> > The only user of this function is the one you added in the last patch
> > in
On Tue, 2018-12-18 at 09:17 -0800, Christoph Hellwig wrote:
> This series seems to miss patches 1 and 2.
Odd, I got them...
Ben.
On Tue, 2018-12-11 at 19:17 +0100, Christian Zigotzky wrote:
> X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the
> kernel starts but it doesn't find any hard disks (partitions). That
> means this is also the bad commit for the P5020 board.
What are the disks hanging off ?
1G
reserved for PCI memory, it's only 512M aligned. The code doesn't
know how to split that into 2 different PMMs and fails, so limit
the region to 512M.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/boot/dts/bamboo.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --
BookE and 40x processors lack the MSR:RI bit. However, we have a
few common code places that rely on it.
This fixes it by not defining MSR_RI on those processor types and
using the appropriate ifdef's in those locations.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/reg.h
On Mon, 2018-12-10 at 20:33 +0100, Christoph Hellwig wrote:
> On Mon, Dec 10, 2018 at 05:04:46PM +, Rui Salvaterra wrote:
> > Hi, Christoph and Ben,
> >
> > It just came to my mind (and this is most likely a stupid question,
> > but still)… Is there any possibility of these changes having an
On Tue, 2018-11-27 at 08:42 +0100, Christoph Hellwig wrote:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.
I completely missed your posting of V4 ! I was wondering what was
taking you so long :)
I'll give it a spin & send acks over the next 2 or 3 days.
Cheers,
On Tue, 2018-12-04 at 12:19 +0100, Mathieu Malaterre wrote:
> On Tue, Dec 4, 2018 at 12:09 PM Benjamin Herrenschmidt
> wrote:
> > Hi folks !
> >
> > Does anybody still has the manual or schematics (or both!) of the old
> > "ebony" ppc440gp eval board aro
Hi folks !
Does anybody still has the manual or schematics (or both!) of the old
"ebony" ppc440gp eval board around by any chance ?
Cheers
Ben.
On Fri, 2018-11-30 at 11:44 +, Rui Salvaterra wrote:
> Thanks for the quick response! I applied it on top of your
> powerpc-dma.4 branch and retested.
> I'm not seeing nouveau complaining anymore (I'm not using X11 or any
> DE, though).
> In any case and FWIW, this series is
>
> Tested-by:
This fixes it.
Signed-off-by: Benjamin Herrenschmidt
Fixes: 78e5dfea8 powerpc: dts: replace 'linux,stdout-path' with 'stdout-path'
---
diff --git a/arch/powerpc/kernel/legacy_serial.c
b/arch/powerpc/kernel/legacy_serial.c
index 33b34a5..5b9dce1 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/ar
On Thu, 2018-11-08 at 18:52 +0100, Christophe LEROY wrote:
>
> In signal_32.c and signal_64.c, save_user_regs() calls __put_user() to
> modify code, then calls flush_icache_range() on user addresses.
>
> Shouldn't flush_icache_range() be performed with userspace access
> protection unlocked ?
On Wed, 2018-11-07 at 09:35 +0100, Christophe LEROY wrote:
> Hi Ben,
>
> I have an issue on the 8xx with this change
Ah ouch...
.../...
> > +/* Is this a bad kernel fault ? */
> > +static bool bad_kernel_fault(bool is_exec, unsigned long error_code,
> > +unsigned
On Wed, 2018-10-31 at 18:54 +0100, Florian Weimer wrote:
>
> It would matter to C code which returns the address of a global variable
> in the main program through and (implicit) int return value.
>
> The old behavior hid some pointer truncation issues.
Hiding bugs like that is never a good
On Tue, 2018-10-30 at 13:58 +0100, Christoph Hellwig wrote:
> Please take my patch instead. We have a kernel polcity to not keep
> dead code around, and everyone including Linus and the attending IBMers
> confirmed this.
Let's call a cat a cat ... ;-)
It's not *dead* code. It's code that is
On Tue, 2018-10-30 at 02:42 +0100, Christian Zigotzky wrote:
> OF patch for the latest Git kernel: http://www.xenosoft.de/of_v2.patch
This just seems to revert a whole bunch of stuff, not really the right
way to go. Why is of_get_next_cpu_node() not finding your CPUs ? There
must be something
On Tue, 2018-10-16 at 20:58 +0300, Raz wrote:
> Section 5.7.3
> "Storage accesses in real, hypervisor real, and virtual real
> addressing modes are performed in a manner that depends on the
> contents of MSR HV , VPM, VRMASD, HRMOR, RMLS, RMOR (see Chapter 2),
> bit 0 of the
> effective address
On Tue, 2018-10-16 at 13:19 +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 16 Oct 2018 13:02:16 +1100 Stephen Rothwell
> wrote:
> >
> > Reverting fe3d2a45e8079fdd7d4da1ff07f4b40bc3cb499f (and the following 2
> > commits) produces a kernel that boots.
>
> Instead of that, I applied this
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index cbd54fe30367..306562d4d818 100644
--- a/arch/powerpc/kernel/prom_init.c
This makes __prombss its own section, and for now store
it in .bss.
This will give us the ability later to store it elsewhere
and/or free it after boot (it's about 8KB).
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 2 +-
arch/powerpc/kernel/vmlinux.lds.S | 3
This replaces all occurrences of __initdata for uninitialized
data with a new __prombss
Currently __promdata is defined to be __initdata but we'll
eventually change that.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 55 +
1 file
It's never modified either
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index e44f55be64ba..2e1ebf26e8e4 100644
--- a/arch/powerpc
Initialize it dynamically instead of statically
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 9852cdb8bb9e..70f2bde06ab3
As they are no longer used past the end of prom_init
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 03b171bb1c29
We removed support for running under any OPAL version
earlier than v3 in 2015 (they never saw the light of day
anyway), but we kept some leftovers of this support in
prom_init.c, so let's take it out.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 125
Make the existing initialized definition constant and copy
it to a __prombss copy
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel
When creating the boot-time FDT from an actual Open Firmware live
tree, let's generate "phandle" properties for the phandles instead
of the old deprecated "linux,phandle".
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 12 +---
1 file c
prom_init.c must not modify the kernel image outside
of the .bss.prominit section. Thus make sure that
prom_init.o doesn't have anything in any of these:
.data
.bss
.init.data
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init_check.sh | 16
It is never modified
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index a1ba56e8c917..e44f55be64ba 100644
--- a/arch/powerpc/kernel
It's not used anywhere else
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 9b38a2e5dd35..a1ba56e8c917 100644
--- a/arch/powerpc
There's some antiquated debug output that's trying
to do a hand-made hexdump and turning into horrible
1-byte-per-line output these days.
Use print_hex_dump() instead
Signed-off-by: Benjamin Herrenschmidt
---
drivers/macintosh/windfarm_smu_sat.c | 25 +++--
1 file changed
On Tue, 2018-10-09 at 21:37 +1100, Michael Ellerman wrote:
> Technically yes. But I thought because we build with mcmodel=medium
> we'll never actually get multiple TOCs in the kernel itself, so it
> doesn't actually matter.
>
> So this seems to work for now:
Ok, fine. I forgot about DOTSYM.
On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> > -* Because 32-bit DMA masks are so common we expect every
> > architecture
> > -* to be able to satisfy them - either by not supporting more
> > physical
> > -* memory, or by providing a ZONE_DMA32. If neither
On Mon, 2018-10-08 at 09:16 +, Christophe Leroy wrote:
> The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
> moves the thread_info into task_struct.
We need to make sure we don't have code that assumes that we don't take
faults on TI access.
On ppc64, the stack SLB
On Mon, 2018-10-08 at 17:04 +1000, Nicholas Piggin wrote:
> On Mon, 08 Oct 2018 15:08:31 +1100
> Benjamin Herrenschmidt wrote:
>
> > HMIs will crash the kernel due to
> >
> > BRANCH_LINK_TO_FAR(hmi_exception_realmode)
> >
> > Calling into the OPD inst
HMIs will crash the kernel due to
BRANCH_LINK_TO_FAR(hmi_exception_realmode)
Calling into the OPD instead of the actual code.
Signed-off-by: Benjamin Herrenschmidt
---
This hack fixes it for me, but it's not great. Nick, any better idea ?
diff --git a/arch/powerpc/kernel/exceptions
On Fri, 2018-10-05 at 00:07 +0300, Mike Rapoport wrote:
> When a memblock allocation APIs are called with align = 0, the alignment is
> implicitly set to SMP_CACHE_BYTES.
>
> Replace all such uses of memblock APIs with the 'align' parameter explicitly
> set to SMP_CACHE_BYTES and stop implicit
On Mon, 2018-10-01 at 16:32 +0200, Christoph Hellwig wrote:
> FYI, I've pulled this into the dma-mapping tree to make forward
> progress. All but oatch 4 had formal ACKs, and for that one Robin
> was fine even without and explicit ack. I'll also send a patch to
> better document the zone
On Thu, 2018-09-27 at 15:49 +0200, Christoph Hellwig wrote:
> On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> > I'm not sure this is entirely right.
> >
> > Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> > fail if you
ristoph Hellwig
(For powerpc)
Acked-by: Benjamin Herrenschmidt
> ---
> arch/ia64/include/asm/dma-mapping.h | 2 --
> arch/ia64/include/asm/machvec.h | 7 ---
> arch/ia64/include/asm/machvec_init.h | 1 -
> arch/ia64/include/asm/machvec_sn2.h | 2 --
> arch/ia6
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> This way an architecture with less than 4G of RAM can support dma_mask
> smaller than 32-bit without a ZONE_DMA. Apparently that is a common
> case on powerpc.
Anything that uses a b43 wifi adapter which has a 31-bit limitation
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> +static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
> + u64 *phys_mask)
> +{
> + if (force_dma_unencrypted())
> + *phys_mask = __dma_to_phys(dev, dma_mask);
> + else
> +
into account.
This looks like it will be usable if/when we switch powerpc to
dma/direct.c
Acked-by: Benjamin Herrenschmidt
---
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/dma-direct.h | 1 +
> kernel/dma/direct.c| 21 ++---
> 2 files changed, 19
On Wed, 2018-09-12 at 11:58 -0500, Bjorn Helgaas wrote:
> > Add the generic PCI core error recovery files to the powerpc EEH
> > MAINTAINERS entry so the powerpc folks will be copied on changes to the
> > generic PCI error handling strategy.
>
> I really want to make sure the powerpc folks are
On Wed, 2018-09-12 at 08:02 -0500, Bjorn Helgaas wrote:
> [+cc Arnd, powerpc folks]
[+Oliver]
> On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote:
> > Hello Bjorn,
> >
> > On s390 we currently handle SRIOV within firmware. Which means
> > that the PF is under firmware control and
On Mon, 2018-09-10 at 19:00 +0300, Sergey Miroshnichenko wrote:
>
> Yes, missing a real EEH event is possible, unfortunately, and it is
> indeed worth mentioning.
>
> To reduce this probability the next patchset I'll post in a few days
> among other things puts all the affected device drivers to
On Wed, 2018-09-05 at 18:40 +0300, Sergey Miroshnichenko wrote:
> Reading an empty slot returns all ones, which triggers a false
> EEH error event on PowerNV.
>
> New callbacks pcibios_rescan_prepare/done are introduced to
> pause/resume the EEH during rescan.
This freaks me out a bit. EEH will
On Wed, 2018-09-05 at 18:40 +0300, Sergey Miroshnichenko wrote:
> PowerNV doesn't depend on PCIe topology info from DT anymore, and now
> it is able to enumerate the fabric and assign the bus numbers.
No it's not, at least unless we drop P7 support.
P7 has constraints on the bus ranges being
On Wed, 2018-09-05 at 18:40 +0300, Sergey Miroshnichenko wrote:
> The pci_dn structures can be created not only from DT, but also
> directly from newly discovered PCIe devices, so allocate them
> dynamically.
I'd rather we moved towards killing pci_dn completely to be honest :)
> Signed-off-by:
On Fri, 2018-08-31 at 14:58 +1000, Benjamin Herrenschmidt wrote:
>
> > A long shot, but something to consider, is that I failed to cover the
> > cases of dynamic devicetree updates (removing nodes that contain a
> > phandle) in ways other than overlays. Michael
On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
>
> > If I force output with "-f", the resulting file has no occurrences
> > of "phandle".
>
> Are you booting with BootX or Open Firmware ?
Assuming you are using BootX (or miBoot), can
On Sat, 2018-09-01 at 09:36 +1000, Finn Thain wrote:
> > The patched kernel (Finn's vmlinux-4.18.0-1-gd44cf7e41c19) boots
> > normally on my Beige G3 Desktop using BootX.
> >
>
> Ben sent two patches, so I picked the most recent one and applied it by
> hand due to corrupted whitespace.
On Fri, 2018-08-31 at 06:28 -0600, Mac User wrote:
> On 8/30/18 10:49 PM, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
> >
> > ...
> > Assuming you are using BootX (or miBoot), can you try this patch ?
>
&g
On Thu, 2018-08-30 at 21:36 -0700, Frank Rowand wrote:
> > No idea whether that's relevant; I haven't done any further investigation.
> > Complete dmesg output is attached. Please let me know if there's any more
> > information you need to help find the bug.
> >
> > Thanks.
>
> I don't have
On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
>
> > If I force output with "-f", the resulting file has no occurrences
> > of "phandle".
>
> Are you booting with BootX or Open Firmware ?
Assuming you are using BootX (or miBoot), can
On Thu, 2018-08-30 at 20:39 -0600, Mac User wrote:
> On 8/29/18 7:05 PM, Rob Herring wrote:
>
> > On Wed, Aug 29, 2018 at 7:44 PM Finn Thain
> > wrote:
> > > Hi Frank,
> > >
> > > Linux v4.17 and later will no longer boot on a G3 PowerMac. The boot hangs
> > > very early, before any video
On Mon, 2018-08-27 at 13:03 +1000, Nicholas Piggin wrote:
> Local radix TLB flush operations that operate on congruence classes
> have explicit ERAT flushes for POWER9. The process scoped LPID flush
> did not have a flush, so add it.
Paul, is that an actual bug ? I think the ERAT is flushed on
On Thu, 2018-08-23 at 07:19 -0500, Segher Boessenkool wrote:
> If one implementation does case insensitive, it will most likely just work,
> because people do not make insane names differing only in case on purpose.
Apple did :-)
ide, vs IDE, ata vs ATA, I've seen all sort of crap there, esp. on
s already updated to check for bot the bits.
> > This
> > make sure page table walkers will find the pte present and things like
> > pte_pfn(pte) returns the right value.
> >
> > Based on the original patch from Benjamin Herrenschmidt
> >
> >
> >
On Thu, 2018-08-23 at 06:43 -0500, Rob Herring wrote:
> On Thu, Aug 23, 2018 at 4:02 AM Grant Likely wrote:
> >
> >
> > What problem are you trying to solve?
>
> I'm looking at removing device_node.name and using full_name instead
> (which now is only the local node name plus unit-address).
On Thu, 2018-08-23 at 07:24 +0200, Christoph Hellwig wrote:
> > Well, iommus can have bypass regions, which we also use for
> > performance, so we do at dma_set_mask() time "swap" the ops around, and
> > in that case, we do want to check the mask against the actual top of
> > memory...
>
> That
On Wed, 2018-08-22 at 20:26 -0500, Rob Herring wrote:
> On Wed, Aug 22, 2018 at 8:14 PM Benjamin Herrenschmidt
> wrote:
> >
> > On Wed, 2018-08-22 at 19:47 -0500, Rob Herring wrote:
> > > The default DT string handling in the kernel is node names and
> > &
On Wed, 2018-08-22 at 19:47 -0500, Rob Herring wrote:
> The default DT string handling in the kernel is node names and
> compatibles are case insensitive and property names are case sensitive
> (Sparc is the the only variation and is opposite). It seems only PPC
> (and perhaps only Power Macs?)
On Wed, 2018-08-22 at 08:58 +0200, Christoph Hellwig wrote:
> On Thu, Aug 09, 2018 at 09:54:33AM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> > > We need to take the DMA offset and encryption bit into account whe
On Wed, 2018-08-22 at 08:53 +0200, Christoph Hellwig wrote:
> On Thu, Aug 09, 2018 at 09:44:18AM +1000, Benjamin Herrenschmidt wrote:
> > We do have the occasional device with things like 31-bit DMA
> > limitation. We know they happens to work because those systems
> > can
On Wed, 2018-08-22 at 08:45 +0200, Christoph Hellwig wrote:
> On Thu, Aug 09, 2018 at 10:01:16AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2018-07-31 at 14:16 +0200, Christoph Hellwig wrote:
> > > It turns out cxl actually uses it. So for now skip this patch,
> >
On Wed, 2018-08-22 at 09:02 +0200, Christoph Hellwig wrote:
> On Thu, Aug 09, 2018 at 10:27:46AM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> > > The requirement to disable local irqs over kmap_atomic is long gone,
>
On Tue, 2018-08-21 at 15:13 +1000, Nicholas Piggin wrote:
> This patch moves SLB miss handlers completely to C, using the standard
> exception handler macros to set up the stack and branch to C.
>
> This can be done because the segment containing the kernel stack is
> always bolted, so accessing
On Tue, 2018-08-21 at 11:44 +0930, Joel Stanley wrote:
> Deciding wich govenors should be built into the kernel can be left to
> users to configure.
>
> Fixes: 81f359027a3a ("cpufreq: powernv: Select CPUFreq related Kconfig
> options for powernv")
> Signed-off-by: Joel Stanley
Can you add them
suitable
for backporting to stable and distros, while the proper PCI fix will probably
be significantly more invasive.
Signed-off-by: Benjamin Herrenschmidt
CC: sta...@vger.kernel.org
---
v2. Fix unused variables warning.
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc
suitable
for backporting to stable and distros, while the proper PCI fix will probably
be significantly more invasive.
Signed-off-by: Benjamin Herrenschmidt
CC: sta...@vger.kernel.org
---
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index
On Mon, 2018-08-13 at 17:06 +0530, Gautham R Shenoy wrote:
> Hi Srikar,
>
> Thanks for reviewing the patch.
>
> On Thu, Aug 09, 2018 at 06:27:43AM -0700, Srikar Dronamraju wrote:
> > * Gautham R. Shenoy [2018-08-09 11:02:07]:
> >
> > >
> > > int threads_per_core, threads_per_subcore,
On Thu, 2018-08-09 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> > For completeness, virtio could also have its own bounce buffer
> > outside of DMA API one. I don't see lots of benefits to this
> > though.
>
> Not fan of that either...
To elaborate a bit ...
For our
On Thu, 2018-08-09 at 10:54 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> > These are identical to the arch specific ones, so remove them.
> >
> > Signed-off-by: Christoph Hellwig
>
> Acked-by: Benjamin Herrensc
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> The remaining implementation for coherent caches is functionally
> identical to the default provided in common code.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/power
dig one of these things to test, which might take a while.
Acked-by: Benjamin Herrenschmidt
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/include/asm/dma-mapping.h | 29 -
> arch
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> These are identical to the arch specific ones, so remove them.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/include/asm/dma-direct.h | 4
> arch/powerpc/inc
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> These do the same functionality as the existing helpers, but do it
> simpler, and also allow the (optional) use of CMA.
>
> Note that the swiotlb code now calls into the dma_direct code directly,
> given that it doesn't work with
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> These methods are optional to start with, no need to implement no-op
> versions.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/kernel/dma.c | 16
>
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> The ppc32 case of dma_nommu_dma_supported already was a no-op, and the
> 64-bit case came to the same conclusion as dma_direct_supported, so
> replace it with the generic version.
It's not at all equivalent (see my review on your
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> Just fold the calculation into __phys_to_dma/__dma_to_phys as those are
> the only places that should know about it.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/power
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> Use the standard portable helper instead of the powerpc specific one,
> which is about to go away.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/kernel/dma-swiotlb.c
> callers.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/include/asm/dma-mapping.h | 5 -
> arch/powerpc/kernel/dma.c | 14 ++
> arch/powerpc/mm/dma-noncoherent.c | 15 +++
> arch/power
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> The requirement to disable local irqs over kmap_atomic is long gone,
> so remove those calls.
Really ? I'm trying to verify that and getting lost in a mess of macros
from hell in the per-cpu stuff but if you look at our implementation
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/kernel/setup_32.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc
On Tue, 2018-07-31 at 14:16 +0200, Christoph Hellwig wrote:
> It turns out cxl actually uses it. So for now skip this patch,
> although random code in drivers messing with dma ops will need to
> be sorted out sooner or later.
CXL devices are "special", they bypass the classic iommu in favor of
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/include/asm/dma-mapping.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h
On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote:
> We need to take the DMA offset and encryption bit into account when selecting
> a zone. Add a helper that takes those into account and use it.
That whole "encryption" stuff seems to be completely specific to the
way x86 does memory
101 - 200 of 7203 matches
Mail list logo
