On 2016-06-13 15:40, Naveen N. Rao wrote:
On 2016/06/10 10:47PM, David Miller wrote:
From: "Naveen N. Rao"
Date: Tue, 7 Jun 2016 19:02:17 +0530
> Please note that patch [2] is a pre-requisite for this patchset, and is
> not yet upstream.
...
> [1] http://thread.gmane.org/gmane.linux.kernel/2
On Fri, Jun 17, 2016 at 08:32:10PM +1000, Michael Ellerman wrote:
>On Fri, 2016-20-05 at 06:41:41 UTC, Gavin Shan wrote:
>> diff --git a/arch/powerpc/include/asm/opal-api.h
>> b/arch/powerpc/include/asm/opal-api.h
>> index 9bb8ddf..2417c86 100644
>> --- a/arch/powerpc/include/asm/opal-api.h
>> +++
From: Wei Yongjun
Since we will remove items off the list using list_del() we need
to use a safe version of the list_for_each() macro aptly named
list_for_each_safe().
Signed-off-by: Wei Yongjun
---
drivers/net/ethernet/ibm/ibmvnic.c | 10 +-
1 file changed, 5 insertions(+), 5 deletion
On Fri, Jun 17, 2016 at 12:52 PM, Bjorn Helgaas wrote:
>>
>> and respin the whole patchset today.
>
> I added your acks and pushed the result to pci/resource. I'll also
> post these formally on the list so they're easier to find.
Please review patchset v13 that is against your new pci/resource b
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.
This patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource
flags parsing.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla
After
PCI: Let pci_mmap_page_range() take resource address
No user for __pci_mmap_make_offset in those arch.
Remove them.
Signed-off-by: Yinghai Lu
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
---
arch/microblaze/pci/pci-common.c | 63 ---
In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
to check exposed value with resource start/end in proc mmap path.
|start = vma->vm_pgoff;
|size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
|pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
|
Same as sparc version.
Make resource with consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.
Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.
Signed-off-by: Yinghai Lu
Cc: linuxpp
On 6/13/2016 3:44 PM, Topi Miettinen wrote:
> Track maximum size of locked memory, presented in /proc/self/limits.
You should have probably Cc:ed everyone on the cover letter and probably
patch 1 of this series. This patch is hard to decipher without the
additional context of those items. Howeve
On Fri, Jun 17, 2016 at 10:53:21PM +1000, Michael Ellerman wrote:
> On Tue, 2016-07-06 at 13:32:23 UTC, "Naveen N. Rao" wrote:
> > diff --git a/arch/powerpc/net/bpf_jit_comp64.c
> > b/arch/powerpc/net/bpf_jit_comp64.c
> > new file mode 100644
> > index 000..954ff53
> > --- /dev/null
> > +++ b/
On 06/15/2016 01:48 AM, Jacek Anaszewski wrote:
> Hi Andrew,
>
> Thanks for the patch.
>
> Please address the issue [1] raised by test bot and resubmit.
>
> Thanks,
> Jacek Anaszewski
>
> [1] https://lkml.org/lkml/2016/6/13/1091
>
It looks like some systems use 'gpio_led_register_device' to m
On Fri, 2016-06-17 at 17:59 -0400, Steven Rostedt wrote:
> Sorry for the late reply, this patch got pushed down in my INBOX.
>
> Could I get someone from PPC to review this patch, just to be safe?
The patch makes sense, I can try getting somebody onto porting
mmiotrace one of these days.
Cheers,
Sorry for the late reply, this patch got pushed down in my INBOX.
Could I get someone from PPC to review this patch, just to be safe?
Thanks!
-- Steve
On Wed, 11 May 2016 14:06:57 -0500
Bjorn Helgaas wrote:
> Previously, mmio_print_pcidev() put "user" addresses in the trace buffer.
> On mo
Am Freitag, 17 Juni 2016, 15:35:23 schrieb Dave Young:
> On 06/16/16 at 05:39pm, Thiago Jung Bauermann wrote:
> > Am Donnerstag, 16 Juni 2016, 09:58:53 schrieb Dave Young:
> > > On 06/15/16 at 01:21pm, Thiago Jung Bauermann wrote:
> > > > +int __weak arch_kexec_walk_mem(unsigned int image_type, boo
On 6/16/2016 5:42 PM, Andreas Schwab wrote:
Chris Metcalf writes:
Reviewing what other platforms do, it seems like powerpc compat mode may
have the opposite problem in little-endian mode, since arguments are passed
in "hi, lo" order unconditionally in arch/powerpc/kernel/sys_ppc32.c.
PPC32 is
"User" addresses are shown in /sys/devices/pci.../.../resource and
/proc/bus/pci/devices and used as mmap offsets for /proc/bus/pci/BB/DD.F
files. On sparc, these are PCI bus addresses, i.e., raw BAR values.
Previously pci_resource_to_user() computed the user address by
subtracting either pbm->io
"User" addresses are shown in /sys/devices/pci.../.../resource and
/proc/bus/pci/devices and used as mmap offsets for /proc/bus/pci/BB/DD.F
files. For I/O port resources on powerpc, these are PCI bus addresses,
i.e., raw BAR values.
Previously pci_resource_to_user() computed the user address by s
"User" addresses are shown in /sys/devices/pci.../.../resource and
/proc/bus/pci/devices and used as mmap offsets for /proc/bus/pci/BB/DD.F
files. For I/O port resources on microblaze, these are PCI bus addresses,
i.e., raw BAR values.
Previously pci_resource_to_user() computed the user address b
Replace the pci_resource_to_user() declarations in each arch that defines
HAVE_ARCH_PCI_RESOURCE_TO_USER with a single one in linux/pci.h.
Change the MIPS static inline implementation to a non-inline version so the
static inline doesn't conflict with the new non-static linux/pci.h
declaration.
No
The /sys/devices/pci.../.../resource and /proc/bus/pci/devices files
contain PCI BAR addresses. On most architectures these addresses are
"resource" values, e.g., CPU physical memory addresses or Linux I/O port
numbers. These may be offset from the raw PCI values if there are multiple
PCI host br
On Thu, Jun 09, 2016 at 01:20:23PM -0500, Bjorn Helgaas wrote:
> From: Yinghai Lu
>
> The powerpc-specific __pci_mmap_set_pgprot() does two things:
>
> 1) Disables write combining for I/O port space mappings
>
> This only affects procfs mappings. The pci_mmap_resource() sysfs path
>
On Fri, Jun 17, 2016 at 12:25:49PM -0700, Yinghai Lu wrote:
> On Thu, Jun 16, 2016 at 7:15 PM, Bjorn Helgaas wrote:
> > On Thu, Jun 09, 2016 at 03:25:52PM -0700, Yinghai Lu wrote:
> >> In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
> >> to check exposed value with resource st
On Thu, Jun 16, 2016 at 7:15 PM, Bjorn Helgaas wrote:
> On Thu, Jun 09, 2016 at 03:25:52PM -0700, Yinghai Lu wrote:
>> In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
>> to check exposed value with resource start/end in proc mmap path.
>>
>> |start = vma->vm_pgoff;
>>
If a cxl adapter faults on an invalid address for a kernel context, we
may enter copro_calculate_slb() with a NULL mm pointer (kernel
context) and an effective address which looks like a user
address. Which will cause a crash when dereferencing mm. It is clearly
an AFU bug, but there's no reason to
> On Jun 16, 2016, at 9:13 AM, Philippe Bergheaud
> wrote:
>
> This adds an afu_driver_ops structure with fetch_event() and
> event_delivered() callbacks. An AFU driver such as cxlflash can fill
> this out and associate it with a context to enable passing custom
> AFU specific events to userspac
On 6/15/2016 6:49 PM, Uma Krishnan wrote:
Some CXL Flash cards need notification of device shutdown
in order to flush pending I/Os.
A PCI notification hook for shutdown has been added where
the driver notifies the card and returns. When the device
is removed in the PCI remove path, notification
On Sat, 2016-11-06 at 07:18:12 UTC, Madhavan Srinivasan wrote:
> diff --git a/arch/powerpc/kernel/cpu_setup_power.S
> b/arch/powerpc/kernel/cpu_setup_power.S
> index 584e119fa8b0..a2080fde0cc5 100644
> --- a/arch/powerpc/kernel/cpu_setup_power.S
> +++ b/arch/powerpc/kernel/cpu_setup_power.S
> @@ -
On Sat, 2016-11-06 at 07:18:14 UTC, Madhavan Srinivasan wrote:
> This patch adds base enablement for the power9 PMU.
This is almost line-for-line identical to the Power8 code, with the exception of
some things you haven't sent yet because they're not ready.
Can you try and factor out some of the
On Tue, 2016-07-06 at 13:32:23 UTC, "Naveen N. Rao" wrote:
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c
> b/arch/powerpc/net/bpf_jit_comp64.c
> new file mode 100644
> index 000..954ff53
> --- /dev/null
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -0,0 +1,956 @@
...
> +
> +static void bpf
On Fri, Jun 17, 2016 at 02:43:31PM +0530, Madhavan Srinivasan wrote:
SNIP
>
>
> if (data->user_regs.abi) {
> - u64 mask = evsel->attr.sample_regs_user;
> + u.val64 = evsel->attr.sample_regs_user;
>
> - sz = hwe
On Friday, June 17, 2016 1:35:35 PM CEST Daniel Axtens wrote:
> > It would be better to fix the sparse compilation so the same endianess
> > is set that you get when calling gcc.
>
> I will definitely work on a patch to sparse! I'd still like this or
> something like it to go in though, so we can
On Fri, 2016-20-05 at 06:41:41 UTC, Gavin Shan wrote:
> diff --git a/arch/powerpc/include/asm/opal-api.h
> b/arch/powerpc/include/asm/opal-api.h
> index 9bb8ddf..2417c86 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -344,6 +348,18 @@ enum OpalP
On Friday 17 June 2016 12:07 PM, Jiri Olsa wrote:
> On Fri, Jun 17, 2016 at 10:52:38AM +0530, Madhavan Srinivasan wrote:
>> When decoding the perf_regs mask in regs_dump__printf(),
>> we loop through the mask using find_first_bit and find_next_bit functions.
>> And mask is of type "u64". But "u64
v3 tested here multiple times ! memleak is now gone.
Tested-by: Mathieu Malaterre
Thanks
On Thu, Jun 16, 2016 at 7:51 PM, Frank Rowand wrote:
> From: Frank Rowand
>
> Fix a memory leak resulting from memory allocation in safe_name().
> This patch fixes all call sites of safe_name().
>
> Mathi
On 06/16/16 at 05:39pm, Thiago Jung Bauermann wrote:
> Am Donnerstag, 16 Juni 2016, 09:58:53 schrieb Dave Young:
> > On 06/15/16 at 01:21pm, Thiago Jung Bauermann wrote:
> > > +/**
> > > + * arch_kexec_walk_mem - call func(data) on free memory regions
> > > + * @image_type: kimage.type
> > > + * @
On 17/06/16 09:33, Chris Smart wrote:
> Calling ISA 3.0 instructions copy, copy_first, paste and paste_last
> generates an alignment fault when copying or pasting unaligned
> data (128 byte). We catch this and send SIGBUS to the userspace
> process that caused it.
>
> We do not emulate these bec
36 matches
Mail list logo
