On Wed, Mar 04, 2015 at 12:35:08AM -0800, Sukadev Bhattiprolu wrote:
> +++ b/kernel/events/core.c
> @@ -3677,11 +3677,34 @@ u64 perf_event_read_value(struct perf_event *event,
> u64 *enabled, u64 *running,
> }
> EXPORT_SYMBOL_GPL(perf_event_read_value);
>
> +static int do_pmu_group_read(struct
On Wed, Mar 04, 2015 at 12:35:07AM -0800, Sukadev Bhattiprolu wrote:
> extern u64 perf_event_read_value(struct perf_event *event,
> - u64 *enabled, u64 *running);
> + u64 *enabled, u64 *running, int update);
>
I think someone recently s
On Wed, Mar 04, 2015 at 12:35:05AM -0800, Sukadev Bhattiprolu wrote:
> In addition to using the transaction interface to schedule events
> on a PMU, we will use it to also read a group of counters at once.
> Accordingly, add a flags parameter to the transaction interfaces.
> The flags indicate whee
On Mon, Mar 16, 2015 at 11:18 PM, Peter Hurley wrote:
> On 03/16/2015 11:12 PM, Pranith Kumar wrote:
>> On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley
>> wrote:
> What is your init?
I am using systemd from debian unstable.
>>>
>>> Do you have a stdout-path property defined in your
On 03/17/2015 04:34 AM, Michael Ellerman wrote:
> On Mon, 2015-03-16 at 16:30 +0530, Anshuman Khandual wrote:
>> On 03/16/2015 12:27 PM, Michael Ellerman wrote:
>>> This adds a test of the switch_endian() syscall we added in the previous
>>> commit.
>>>
>>> We test it by calling the endian switch s
Hi folks !
My -next branch has been somewhat dormant lately. Now that we have that
new two-headed maintainership model, I'll change the way it works.
I'm going to merge patches in topic branches exclusively. One per series
and a next-misc for random other stuff.
"next" itself will just be an agg
The patch removes struct eeh_dev::dn and the corresponding helper
functions: eeh_dev_to_of_node() and of_node_to_eeh_dev(). Instead,
eeh_dev_to_pdn() and pdn_to_eeh_dev() should be used to get the
pdn, which might contain device_node on PowerNV platform.
Signed-off-by: Gavin Shan
---
arch/powerp
Originally, EEH core probes on device_node or pci_dev to populate
EEH devices and PEs, which conflicts with the fact: SRIOV VFs are
usually enabled and created by PF's driver and they don't have the
corresponding device_nodes. Instead, SRIOV VFs have dynamically
created pci_dn, which can be used fo
There are 3 EEH operations whose arguments contain device_node:
read_config(), write_config() and restore_config(). The patch
replaces device_node with pci_dn.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h | 6 +-
arch/powerpc/kernel/eeh.c| 40 ++
The PCI config accessors previously relied on device_node. Unfortunately,
VFs don't have a corresponding device_node, so change the accessors to use
pci_dn instead.
[bhelgaas: changelog]
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14 +-
arch/powerpc/platfor
Originally, EEH probes on device_node or pci_dev and populates the
corresponding eeh_dev. In the subsequent patches, EEH will probes
on pci_dn and populates the corresponding eeh_dev. So we have to
cache some information in pci_dn, either from device_node or SRIOV
PF's enablement platform hook, to
The patch adds function traverse_pci_dn(), which is similar to
traverse_pci_devices() except it takes pci_dn, not device_node
as parameter. The pci_dev.c has been reworked to create eeh_dev
from pci_dn, instead of device_node.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h
Currently, the PCI config accessors are implemented based on device node.
Unfortunately, SRIOV VFs won't have the corresponding device nodes. pci_dn
will be used in replacement with device node for SRIOV VFs. So we have to
use pci_dn in PCI config accessors.
The patch refactors pci_dn in following
powerpc/eeh: Refactor to use pci_dn
Currently, EEH depends on device_node or pci_dev heavily. Unfortunately,
SRIOV VFs are supported depending on pci_dn heavily, which is conflicting
with EEH implementation. In order for better support EEH on SRIOV VF, the
EEH is better to be changed a bit to depe
On Tue, Mar 17, 2015 at 12:37:17PM +1100, Gavin Shan wrote:
Please ignore this and v2 with more changes according to Ben's comments
is on the way.
Thanks,
Gavin
>Currently, EEH depends on device_node or pci_dev heavily. Unfortunately,
>SRIOV VFs are supported depending on pci_dn heavily, which i
From: Greg Kurz
The goal is to verify vphn_unpack_associativity() parses VPHN numbers
correctly. We feed it with a variety of input values and compare with
expected results.
PAPR+ does not say much about VPHN parsing: I came up with a list of
tests that check many simple cases and some corner on
Fastsleep is one of the idle state which cpuidle subsystem currently
uses on power8 machines. In this state L2 cache is brought down to a
threshold voltage. Therefore when the core is in fastsleep, the
communication between L2 and L3 needs to be fenced. But there is a bug
in the current power8 chip
On 03/16/2015 11:12 PM, Pranith Kumar wrote:
> On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley
> wrote:
What is your init?
>>>
>>> I am using systemd from debian unstable.
>>
>> Do you have a stdout-path property defined in your dts to a serial
>> console you're not actually using?
>>
>
> I
On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley wrote:
>>> What is your init?
>>
>> I am using systemd from debian unstable.
>
> Do you have a stdout-path property defined in your dts to a serial
> console you're not actually using?
>
I am using tty0 as my console. From the config which I posted,
On 03/17/2015 06:45 AM, Alex Williamson wrote:
On Fri, 2015-03-13 at 19:07 +1100, Alexey Kardashevskiy wrote:
The existing IOMMU requires VFIO_IOMMU_ENABLE call to enable actual use
of the container (i.e. call DMA map/unmap) and this is where we check
the rlimit for locked pages. It assumes that
On 03/16/2015 10:02 PM, Pranith Kumar wrote:
> On Mon, Mar 16, 2015 at 7:22 PM, Michael Ellerman wrote:
>>
>> The log shows that init is being killed, that's what's causing the panic.
>>
>> The exitcode of init is 0x200, which due to the vagaries of UNIX is I think
>> an
>> "exit status" of 2 in
On Tue, 2015-03-17 at 12:02 +1100, Alexey Kardashevskiy wrote:
> On 03/17/2015 06:38 AM, Alex Williamson wrote:
> > On Fri, 2015-03-13 at 19:07 +1100, Alexey Kardashevskiy wrote:
> >> This adds create/remove window ioctls to create and remove DMA windows.
> >> sPAPR defines a Dynamic DMA windows ca
On Tue, 2015-17-02 at 22:00:34 UTC, Sukadev Bhattiprolu wrote:
> Add missing put_cpu_var() for 24x7 requests.
When did it go missing? I assume in upstream, in which case this should be a
separate patch which I could merge for 4.0.
cheers
___
Linuxppc-de
On Tue, 2015-17-02 at 22:00:33 UTC, Sukadev Bhattiprolu wrote:
> Break up the function single_24x7_request() into smaller functions.
> This would later enable us to "prepare" a multi-event request
> buffer and then submit a single hcall for several events.
This looks fine, though the names are a b
On Tue, 2015-17-02 at 22:00:31 UTC, Sukadev Bhattiprolu wrote:
> Move code that maps a perf_event to a 24x7 request buffer into a
> separate function, add_event_to_24x7_request().
>
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index e78b127..76c649a 100644
> --- a/arc
On Tue, 2015-17-02 at 22:00:28 UTC, Sukadev Bhattiprolu wrote:
> The function event_24x7_request() is essentially a wrapper to the
> function single_24x7_request() and can be dropped to simplify code.
>
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 7856e38..c189e
On Mon, Mar 16, 2015 at 7:22 PM, Michael Ellerman wrote:
>
> The log shows that init is being killed, that's what's causing the panic.
>
> The exitcode of init is 0x200, which due to the vagaries of UNIX is I think an
> "exit status" of 2 in the common usage.
>
> But it suggests that your init is
Originally, EEH core probes on device_node or pci_dev to populate
EEH devices and PEs, which conflicts with the fact: SRIOV VFs are
usually enabled and created by PF's driver and they don't have the
corresponding device_nodes. Instead, SRIOV VFs have dynamically
created pci_dn, which can be used fo
Originally, EEH probes on device_node or pci_dev and populates the
corresponding eeh_dev. In the subsequent patches, EEH will probes
on pci_dn and populates the corresponding eeh_dev. So we have to
cache some information in pci_dn, either from device_node or SRIOV
PF's enablement platform hook, to
There are 3 EEH operations whose arguments contain device_node:
read_config(), write_config() and restore_config(). The patch
replaces device_node with pci_dn.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h | 6 +-
arch/powerpc/kernel/eeh.c| 34 ++
The PCI config accessors previously relied on device_node. Unfortunately,
VFs don't have a corresponding device_node, so change the accessors to use
pci_dn instead.
[bhelgaas: changelog]
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14 +-
arch/powerpc/platfor
Currently, EEH depends on device_node or pci_dev heavily. Unfortunately,
SRIOV VFs are supported depending on pci_dn heavily, which is conflicting
with EEH implementation. In order for better support EEH on SRIOV VF, the
EEH is better to be changed a bit to depend on pci_dn, which is exactly
what t
pci_dn is the extension of PCI device node and is created from device node.
Unfortunately, VFs are enabled dynamically by PF's driver and they don't
have corresponding device nodes, and pci_dn. Refactor pci_dn to support
VFs:
* pci_dn is organized as a hierarchy tree. VF's pci_dn is put
The patch removes struct eeh_dev::dn and the corresponding helper
functions: eeh_dev_to_of_node() and of_node_to_eeh_dev(). Instead,
eeh_dev_to_pdn() and pdn_to_eeh_dev() should be used to get the
pdn, which might contain device_node on PowerNV platform.
Signed-off-by: Gavin Shan
---
arch/powerp
The patch adds function traverse_pci_dn(), which is similar to
traverse_pci_devices() except it takes pci_dn, not device_node
as parameter. The pci_dev.c has been reworked to create eeh_dev
from pci_dn, instead of device_node.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h
On 03/17/2015 06:38 AM, Alex Williamson wrote:
On Fri, 2015-03-13 at 19:07 +1100, Alexey Kardashevskiy wrote:
This adds create/remove window ioctls to create and remove DMA windows.
sPAPR defines a Dynamic DMA windows capability which allows
para-virtualized guests to create additional DMA windo
On Mon, 16 Mar 2015 12:02:51 +0200
Horia Geantă wrote:
> On 3/4/2015 2:23 AM, Kim Phillips wrote:
> > Only potential problem is getting the crypto API to set the GFP_DMA
> > flag in the allocation request, but presumably a
> > CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that.
>
> Seems the
On Tue, 2015-17-02 at 22:00:27 UTC, Sukadev Bhattiprolu wrote:
> Use pr_notice_ratelimited() to log error messages and remove
> the 'success_expected' parameter.
I don't understand how this is equivalent?
The current code uses success_expected to indicate that once it's done the
request once and
On Mon, 2015-03-16 at 09:30 -0400, Pranith Kumar wrote:
> On Mon, Mar 16, 2015 at 4:16 AM, Michael Ellerman wrote:
> > On Mon, 2015-03-16 at 01:34 -0400, Pranith Kumar wrote:
> >> On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar
> >> wrote:
> >> > Hello,
> >> >
> >> > I have a power mac mini 32-bi
On Mon, 2015-03-16 at 16:30 +0530, Anshuman Khandual wrote:
> On 03/16/2015 12:27 PM, Michael Ellerman wrote:
> > This adds a test of the switch_endian() syscall we added in the previous
> > commit.
> >
> > We test it by calling the endian switch syscall, and then executing some
> > code in the ot
> "Fabian" == Fabian Frederick writes:
> of_device_id is always used as const.
> (See driver.of_match_table and open firmware functions)
> Signed-off-by: Fabian Frederick
> ---
For this:
> drivers/tty/serial/uartlite.c | 2 +-
Acked-by: Peter Korsgaard
--
Bye, Peter
On Fri, 2015-03-13 at 19:07 +1100, Alexey Kardashevskiy wrote:
> The existing IOMMU requires VFIO_IOMMU_ENABLE call to enable actual use
> of the container (i.e. call DMA map/unmap) and this is where we check
> the rlimit for locked pages. It assumes that only as much memory
> as a default DMA wind
On Fri, 2015-03-13 at 19:07 +1100, Alexey Kardashevskiy wrote:
> This adds create/remove window ioctls to create and remove DMA windows.
> sPAPR defines a Dynamic DMA windows capability which allows
> para-virtualized guests to create additional DMA windows on a PCI bus.
> The existing linux kernel
On 03/16/2015 02:17 PM, Fabian Frederick wrote:
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
...
drivers/tty/serial/ucc_uart.c | 2 +-
For this driver:
Acked-by: Timur Tabi
__
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
---
drivers/macintosh/mediabay.c | 2 +-
drivers/macintosh/rack-meter.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/mediaba
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
---
drivers/char/hw_random/pasemi-rng.c | 2 +-
drivers/char/hw_random/powernv-rng.c | 2 +-
drivers/char/hw_random/ppc4xx-rng.c | 2 +-
drivers/char/ipmi/ipmi_si_intf.
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
---
drivers/tty/serial/apbuart.c| 2 +-
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 2 +-
drivers/tty/serial/fsl_lpuart.c | 2 +-
drivers/tt
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
---
drivers/tty/hvc/hvc_opal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index 071551b..
This small patchset adds const to of_device_id arrays in
drivers branch.
Fabian Frederick (35):
ata: constify of_device_id array
regulator: constify of_device_id array
thermal: constify of_device_id array
tty/hvc_opal: constify of_device_id array
tty: constify of_device_id array
power:
On 3/13/2015 4:08 PM, Martin Hicks wrote:
> Hi Horia,
>
> On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă
> wrote:
>>
>> While here: note that xts-talitos supports only two key lengths - 256
>> and 512 bits. There are tcrypt speed tests that check also for 384-bit
>> keys (which is out-of-spec, bu
On 03/16/2015 09:30 AM, Pranith Kumar wrote:
> On Mon, Mar 16, 2015 at 4:16 AM, Michael Ellerman wrote:
>> On Mon, 2015-03-16 at 01:34 -0400, Pranith Kumar wrote:
>>> On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar
>>> wrote:
Hello,
I have a power mac mini 32-bit system.
>>> .
On Mon, Mar 16, 2015 at 4:16 AM, Michael Ellerman wrote:
> On Mon, 2015-03-16 at 01:34 -0400, Pranith Kumar wrote:
>> On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar wrote:
>> > Hello,
>> >
>> > I have a power mac mini 32-bit system.
>> >
>> ...
>> > You can see the panic message here: http://imgu
Convert the simple spinlock to ticket-based. This is based on arm64
codes and only cover the systems which doesn't support shared
processors (a physical processor is multiplexed between several
virtual processors).
Signed-off-by: Kevin Hao
---
arch/powerpc/Kconfig | 5 ++
a
Move all of them to one place. No function change.
Signed-off-by: Kevin Hao
---
arch/powerpc/include/asm/spinlock.h | 71 -
1 file changed, 30 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/include/asm/spinlock.h
b/arch/powerpc/include/asm/spinlock
On a system with shared processors (a physical processor is multiplexed
between several virtual processors), we encode the lock owner into the
lock token in order to avoid unnecessarily spinning on a lock if the
lock holder isn't currently scheduled on a physical processor.
In the current kernel,
Hi,
This patch series convert the simple spinlock to ticket-based spinlock for the
platforms without shared processors. I have run the following command ten times
on a t4240rdb board (12 dual-threaded cpus):
./perf bench sched messaging -g 100
Before A
On 03/16/2015 12:27 PM, Michael Ellerman wrote:
> This adds a test of the switch_endian() syscall we added in the previous
> commit.
>
> We test it by calling the endian switch syscall, and then executing some
> code in the other endian to check everything went as expected. That code
> checks regi
On 3/4/2015 2:23 AM, Kim Phillips wrote:
> Only potential problem is getting the crypto API to set the GFP_DMA
> flag in the allocation request, but presumably a
> CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that.
Seems there are quite a few places that do not use the
{aead,ablkcipher_ahash}
On Mon, 2015-03-16 at 01:34 -0400, Pranith Kumar wrote:
> On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar wrote:
> > Hello,
> >
> > I have a power mac mini 32-bit system.
> >
> ...
> > You can see the panic message here: http://imgur.com/s1lH15g. (there
> > is no log and I have no serial console).
The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
to inject the specified EEH error, which is represented by
(struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
Signed-off-by: Gavin Shan
---
v2: Put additional arguments for error injection to union
---
Documentation
The patch defines PCI error types and functions in eeh.h and
exports function eeh_pe_inject_err(), which will be called by
VFIO driver to inject the specified PCI error to the indicated
PE for testing purpose.
Signed-off-by: Gavin Shan
---
v2: Use EEH_ERR_FUNC_{MIN,MAX} to validate PCI error func
61 matches
Mail list logo
