Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.12-1 tag

On Tue, Feb 23, 2021 at 9:44 AM Linus Torvalds wrote: > > On Mon, Feb 22, 2021 at 4:06 AM Michael Ellerman wrote: > > > > Please pull powerpc updates for 5.12. > > Pulled. However: > > > mode change 100755 => 100644 > > tools/testing/selftests/powerpc/eeh/eeh-functions.sh > > create mode

Re: [PATCH] arch:powerpc simple_write_to_buffer return check

On Fri, Feb 5, 2021 at 5:17 AM Mayank Suman wrote: > > Signed-off-by: Mayank Suman commit messages aren't optional > --- > arch/powerpc/kernel/eeh.c| 8 > arch/powerpc/platforms/powernv/eeh-powernv.c | 4 ++-- > 2 files changed, 6 insertions(+), 6 deletions(-) > >

Re: [PATCH] powerpc/eeh: remove unneeded semicolon

On Tue, Feb 2, 2021 at 2:21 PM Yang Li wrote: > > Eliminate the following coccicheck warning: > ./arch/powerpc/kernel/eeh.c:782:2-3: Unneeded semicolon Doesn't appear to be a load-bearing semicolon. It's hard to tell with EEH. Reviewed-by: Oliver O'Halloran > > Reported-

Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed

On Tue, Nov 3, 2020 at 1:39 AM Cédric Le Goater wrote: > > On 10/14/20 4:55 AM, Alexey Kardashevskiy wrote: > > > > How do you remove PHBs exactly? There is no such thing in the powernv > > platform, I thought someone added this and you are fixing it but no. PHBs > > on powernv are created at

Re: [PATCH] powerpc/eeh_cache: Fix a possible debugfs deadlock

0xe8/0x218 > > Fixes: 5ca85ae6318d ("powerpc/eeh_cache: Add a way to dump the EEH address > cache") > Signed-off-by: Qian Cai Good catch, Reviewed-by: Oliver O'Halloran

Re: [Skiboot] [PATCH 0/3] warn and suppress irqflood

On Mon, Oct 26, 2020 at 12:11 AM Pingfan Liu wrote: > > On Sun, Oct 25, 2020 at 8:21 PM Oliver O'Halloran wrote: > > > > On Sun, Oct 25, 2020 at 10:22 PM Pingfan Liu wrote: > > > > > > On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner > > > wrote:

Re: [Skiboot] [PATCH 0/3] warn and suppress irqflood

On Sun, Oct 25, 2020 at 10:22 PM Pingfan Liu wrote: > > On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner wrote: > > > > On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote: > > > I hit a irqflood bug on powerpc platform, and two years ago, on a x86 > > > platform. > > > When the bug happens, the

Re: [PATCH -next] Revert "powerpc/pci: unmap legacy INTx interrupts when a PHB is removed"

On Thu, Oct 15, 2020 at 5:28 AM Qian Cai wrote: > > This reverts commit 3a3181e16fbde752007759f8759d25e0ff1fc425 which > causes memory corruptions on POWER9 NV. I was going to post this along with a fix for Cedric's original bug, but I can do that separately so: Acked-by: Oliver O'Halloran

Re: PCI: Race condition in pci_create_sysfs_dev_files

On Wed, Oct 7, 2020 at 10:26 AM Bjorn Helgaas wrote: > > I'm not really a fan of this because pci_sysfs_init() is a bit of a > hack to begin with, and this makes it even more complicated. > > It's not obvious from the code why we need pci_sysfs_init(), but > Yinghai hinted [1] that we need to

Re: [PATCH] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules

On Tue, Sep 29, 2020 at 6:50 AM Tyrel Datwyler wrote: > > On 9/23/20 11:41 PM, Oliver O'Halloran wrote: > > On Thu, Sep 24, 2020 at 3:15 PM Mamatha Inamdar > > wrote: > >> > >> This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules > &

Re: [PATCH] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules

On Sat, Sep 26, 2020 at 5:43 AM Bjorn Helgaas wrote: > > On Thu, Sep 24, 2020 at 04:41:39PM +1000, Oliver O'Halloran wrote: > > On Thu, Sep 24, 2020 at 3:15 PM Mamatha Inamdar > > wrote: > > > > > > This patch adds a brief MODULE_DESCRIPTION to rpadlpar_i

Re: [PATCH] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules

On Thu, Sep 24, 2020 at 3:15 PM Mamatha Inamdar wrote: > > This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules > (descriptions taken from Kconfig file) > > Signed-off-by: Mamatha Inamdar > --- > drivers/pci/hotplug/rpadlpar_core.c |1 + > 1 file changed, 1 insertion(+)

Re: [RFC PATCH] PCI/portdrv: No need to call pci_disable_device() during shutdown

On Fri, Sep 11, 2020 at 11:55 AM Tiezhu Yang wrote: > > On 09/11/2020 04:21 AM, Bjorn Helgaas wrote: > > [+cc Huacai] > > > > On Thu, Sep 10, 2020 at 02:41:39PM -0500, Bjorn Helgaas wrote: > >> On Sat, Sep 05, 2020 at 04:33:26PM +0800, Tiezhu Yang wrote: > >>> After commit 745be2e700cd ("PCIe:

Re: [PATCH v1 01/10] powerpc/pseries/iommu: Replace hard-coded page shift

On Mon, Aug 31, 2020 at 10:08 AM Alexey Kardashevskiy wrote: > > On 29/08/2020 05:55, Leonardo Bras wrote: > > On Fri, 2020-08-28 at 12:27 +1000, Alexey Kardashevskiy wrote: > >> > >> On 28/08/2020 01:32, Leonardo Bras wrote: > >>> Hello Alexey, thank you for this feedback! > >>> > >>> On Sat,

Re: [PATCH] powerpc/pseries: Add pcibios_default_alignment implementation

On Sat, Aug 22, 2020 at 6:51 AM Shawn Anastasio wrote: > > Implement pcibios_default_alignment for pseries so that > resources are page-aligned. The main benefit of this is being > able to map any resource from userspace via mechanisms like VFIO. Reviewed-by: Oliver O'Halloran

Re: [PATCH v2 1/4] libnvdimm: fix memmory leaks in of_pmem.c

Lei Yep, that's a bug. Reviewed-by: Oliver O'Halloran > --- > drivers/nvdimm/of_pmem.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/nvdimm/of_pmem.c b/drivers/nvdimm/of_pmem.c > index 10dbdcdfb9ce913..1292ffca7b2ecc0 100644 > --- a/drivers/nvdimm/of_pmem.c >

Re: [PATCH v2 1/4] libnvdimm: Fix memory leaks in of_pmem.c

On Wed, Aug 19, 2020 at 10:28 PM Markus Elfring wrote: > > > The memory priv->bus_desc.provider_name allocated by kstrdup() is not > > freed correctly. Personally I thought his commit message was perfectly fine. A little unorthodox, but it works. > How do you think about to choose an imperative

Re: [PATCH v2] PCI: Introduce flag for detached virtual functions

On Thu, Aug 13, 2020 at 7:00 PM Niklas Schnelle wrote: > > > On 8/13/20 3:55 AM, Oliver O'Halloran wrote: > > On Thu, Aug 13, 2020 at 5:21 AM Matthew Rosato > > wrote: > >> *snip* > >> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c > >> in

Re: [PATCH v2] PCI: Introduce flag for detached virtual functions

On Thu, Aug 13, 2020 at 6:33 AM Alex Williamson wrote: > > On Wed, 12 Aug 2020 15:21:11 -0400 > Matthew Rosato wrote: > > > @@ -521,7 +522,8 @@ static int vfio_basic_config_read(struct > > vfio_pci_device *vdev, int pos, > > count = vfio_default_config_read(vdev, pos, count, perm, offset,

Re: [PATCH v2] PCI: Introduce flag for detached virtual functions

On Thu, Aug 13, 2020 at 5:21 AM Matthew Rosato wrote: > > s390x has the notion of providing VFs to the kernel in a manner > where the associated PF is inaccessible other than via firmware. > These are not treated as typical VFs and access to them is emulated > by underlying firmware which can

Re: [PATCH -next] powerpc/powernv/sriov: Remove unused but set variable 'phb'

iov = pnv_iov_get(pdev); > num_vfs = iov->num_vfs; > base_pe = iov->vf_pe_arr[0].pe_number; > Acked-by: Oliver O'Halloran

Re: [PATCH v2] powerpc/powernv/pci: use ifdef to avoid dead code

On Sun, Jul 19, 2020 at 5:13 AM Greg Thelen wrote: > > Oliver O'Halloran wrote: > > > On Mon, Jun 15, 2020 at 9:33 AM Greg Thelen wrote: > >> > >> Commit dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE > >> configuration") removed a c

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

On Wed, Jul 15, 2020 at 8:03 AM Arnd Bergmann wrote: > > - Most error checking is static: PCIBIOS_BAD_REGISTER_NUMBER > only happens if you pass an invalid register number, but most > callers pass a compile-time constant register number that is > known to be correct, or the driver would

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

On Thu, 2020-07-02 at 09:32 +0200, Greg Kroah-Hartman wrote: > On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote: > > Yep, that's a problem. If we want to provide a useful mechanism to > > userspace then the default behaviour of the kernel can't undermine >

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote: > > *snip* > > > > I guess it would make sense to have an attribute for user space to > > > write to in order to make the kernel reject device plug-in events > > > coming from a given port or connector, but the kernel has no reliable > > > means to

Re: [PATCH 2/2] pci: Add parameter to disable attaching untrusted devices

On Fri, Jun 26, 2020 at 10:27 AM Rajat Jain wrote: > > Introduce a PCI parameter that disables the automatic attachment of > untrusted devices to their drivers. > > Signed-off-by: Rajat Jain > --- > Context: > > I set out to implement the approach outlined in >

Re: [PATCH 3/4] powerpc/pseries/iommu: Move window-removing part of remove_ddw into remove_dma_window

On Tue, Jun 23, 2020 at 11:12 AM Alexey Kardashevskiy wrote: > > On 23/06/2020 04:59, Leonardo Bras wrote: > > > >> Also, despite this particular file, the "pdn" name is usually used for > >> struct pci_dn (not device_node), let's keep it that way. > > > > Sure, I got confused for some time about

Re: [PATCH v2] powerpc/powernv/pci: use ifdef to avoid dead code

G_IOMMU_API see: > arch/powerpc/platforms/powernv/pci-ioda.c:1888:13: error: > 'pnv_ioda_setup_bus_dma' defined but not used > > Move pnv_ioda_setup_bus_dma() under CONFIG_IOMMU_API to avoid dead code. Doh! Thanks for the fix. Reviewed-by: Oliver O'Halloran

Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers

On Wed, Jun 10, 2020 at 7:04 AM Bjorn Helgaas wrote: > > To sketch this out, my understanding of how this would work is: > > - Expose the PCI pdev->untrusted bit in sysfs. We don't expose this > today, but doing so would be trivial. I think I would prefer a > sysfs name like

Re: [PATCH v1 1/1] PCI/ERR: Handle fatal error recovery for non-hotplug capable devices

On Wed, May 27, 2020 at 1:06 PM Kuppuswamy, Sathyanarayanan wrote: > > Yes, in case of DPC (Fatal errors) link is already reset. So we > don't need any special handling. This reset logic is mainly for > non-fatal errors. Why? In our experience most fatal errors aren't all that fatal and can be

Re: [PATCH v1 1/1] PCI/ERR: Handle fatal error recovery for non-hotplug capable devices

On Wed, May 27, 2020 at 12:00 PM Kuppuswamy, Sathyanarayanan wrote: > > Hi, > > On 5/21/20 7:56 PM, Yicong Yang wrote: > > > > > > On 2020/5/22 3:31, Kuppuswamy, Sathyanarayanan wrote: > >> > > Not exactly. In pci_bus_error_reset(), we call pci_slot_reset() only if it's > > hotpluggable. But we

Re: ioremap() called early from pnv_pci_init_ioda_phb()

On Sun, May 10, 2020 at 1:51 AM Christophe Leroy wrote: > > > > Le 08/05/2020 à 19:41, Qian Cai a écrit : > > > > > >> On May 8, 2020, at 10:39 AM, Qian Cai wrote: > >> > >> Booting POWER9 PowerNV has this message, > >> > >> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use >

Re: ioremap() called early from pnv_pci_init_ioda_phb()

On Sat, May 9, 2020 at 12:41 AM Qian Cai wrote: > > Booting POWER9 PowerNV has this message, > > "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use > early_ioremap() instead” > > but use the patch below will result in leaks because it will never call > early_iounmap()

Re: [PATCH v3 4/4] PCI: pciehp: Remove pciehp_green_led_{on,off,blink}()

On Tue, Aug 20, 2019 at 2:09 AM Denis Efremov wrote: > > Remove pciehp_green_led_{on,off,blink}() and use pciehp_set_indicators() > instead, since the code is mostly the same. > > Signed-off-by: Denis Efremov > --- > drivers/pci/hotplug/pciehp.h | 3 --- >

Re: [PATCH v3 1/4] PCI: pciehp: Add pciehp_set_indicators() to jointly set LED indicators

On Tue, Aug 20, 2019 at 2:07 AM Denis Efremov wrote: > > Add pciehp_set_indicators() to set power and attention indicators with a > single register write. Thus, avoiding waiting twice for Command Complete. > > Signed-off-by: Denis Efremov > --- > drivers/pci/hotplug/pciehp.h | 1 + >

Re: [PATCH v3 1/4] PCI: pciehp: Add pciehp_set_indicators() to jointly set LED indicators

On Tue, Aug 20, 2019 at 2:17 AM Denis Efremov wrote: > > Hi, > > On 8/19/19 7:06 PM, Denis Efremov wrote: > On 8/12/19 11:25 AM, sathyanarayanan kuppuswamy wrote: > > Do we need to switch case here ? if (pwr > 0) {} should work right ? > > I saved the switch here from v2. I think switch makes the

Re: [PATCH 2/4] powerpc/32: activate ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE

On Mon, Jul 15, 2019 at 4:49 PM Michael Ellerman wrote: > > Christophe Leroy writes: > > PPC32 also have flush_dcache_range() so it can also support > > ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes. > > > > Signed-off-by: Christophe Leroy > > --- > > arch/powerpc/Kconfig |

Re: [PATCH 4/4] powerpc/64: reuse PPC32 static inline flush_dcache_range()

On Tue, Jul 9, 2019 at 12:52 PM Aneesh Kumar K.V wrote: > > On 7/9/19 7:50 AM, Oliver O'Halloran wrote: > > On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V > > wrote: > >> > >> Christophe Leroy writes: > >> > >>> *snip* > >&

Re: [PATCH 4/4] powerpc/64: reuse PPC32 static inline flush_dcache_range()

On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V wrote: > > Christophe Leroy writes: > > > *snip* > > + if (IS_ENABLED(CONFIG_PPC64)) > > + isync(); > > } > > > Was checking with Michael about why we need that extra isync. Michael > pointed this came via > >

Re: [PATCH 2/4] powerpc/powernv: remove the unused tunneling exports

On Thu, May 23, 2019 at 5:51 PM Christoph Hellwig wrote: > > These have been unused ever since they've been added to the kernel. > > Signed-off-by: Christoph Hellwig > --- > arch/powerpc/include/asm/pnv-pci.h| 4 -- > arch/powerpc/platforms/powernv/pci-ioda.c | 4 +- >

Re: [PATCH 4/4] powerpc/powernv: remove the unused vas_win_paste_addr and vas_win_id functions

On Thu, May 23, 2019 at 5:56 PM Christoph Hellwig wrote: > > These two function have never been used since they were added to the > kernel. > > Signed-off-by: Christoph Hellwig > --- > arch/powerpc/include/asm/vas.h | 10 -- > arch/powerpc/platforms/powernv/vas-window.c |

Re: [PATCH v2 8/8] habanalabs: enable 64-bit DMA mask in POWER9

On Wed, Jun 12, 2019 at 4:53 PM Christoph Hellwig wrote: > > On Wed, Jun 12, 2019 at 04:35:22PM +1000, Oliver O'Halloran wrote: > > Setting a 48 bit DMA mask doesn't work today because we only allocate > > IOMMU tables to cover the 0..2GB range of PCI bus addresses. > > I

Re: [PATCH v2 8/8] habanalabs: enable 64-bit DMA mask in POWER9

On Wed, Jun 12, 2019 at 3:25 AM Oded Gabbay wrote: > > On Tue, Jun 11, 2019 at 8:03 PM Oded Gabbay wrote: > > > > On Tue, Jun 11, 2019 at 6:26 PM Greg KH wrote: > > > *snip* > > > > Now, when I tried to integrate Goya into a POWER9 machine, I got a > > reject from the call to

Re: [PATCH v2 8/8] habanalabs: enable 64-bit DMA mask in POWER9

On Wed, Jun 12, 2019 at 8:54 AM Benjamin Herrenschmidt wrote: > > On Tue, 2019-06-11 at 20:22 +0300, Oded Gabbay wrote: > > > > > So, to summarize: > > > If I call pci_set_dma_mask with 48, then it fails on POWER9. However, > > > in runtime, I don't know if its POWER9 or not, so upon failure I

[PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA

it's own, or the generic OF_NUMA, then always use the inline fallback in of.h so we don't need to futz around with exports. Cc: devicet...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Fixes: 298535c00a2c ("of, numa: Add NUMA of binding implementation.") Sig

[PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA

it's own, or the generic OF_NUMA, then always use the inline fallback in of.h so we don't need to futz around with exports. Cc: devicet...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Fixes: 298535c00a2c ("of, numa: Add NUMA of binding implementation.") Sig

[PATCH] drm/sti: Depend on OF rather than selecting it

tructure") Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org> Cc: Vincent Abriou <vincent.abr...@st.com> Cc: David Airlie <airl...@linux.ie> Cc: dri-de...@lists.freedesktop.org Cc: linux-i...@vger.kernel.org Cc: sta...@vger.kernel.org Signed-off-by: Oliver O'Halloran <ooh...@g

[PATCH] drm/sti: Depend on OF rather than selecting it

tructure") Cc: Benjamin Gaignard Cc: Vincent Abriou Cc: David Airlie Cc: dri-de...@lists.freedesktop.org Cc: linux-i...@vger.kernel.org Cc: sta...@vger.kernel.org Signed-off-by: Oliver O'Halloran --- Cc`ed to stable since the ia64 guys might want it backported. I'm not bothered if it just goes

[PATCH] kernel/memremap: Remove stale devres_free() call

devm_memremap_pages() fail gracefully. Fixes: e8d513483300 ("memremap: change devm_memremap_pages interface to use struct dev_pagemap") Cc: Logan Gunthorpe <log...@deltatee.com> Cc: Christoph Hellwig <h...@lst.de> Cc: Dan Williams <dan.j.willi...@intel.com> Signed-off-by: Oliver

[PATCH] kernel/memremap: Remove stale devres_free() call

devm_memremap_pages() fail gracefully. Fixes: e8d513483300 ("memremap: change devm_memremap_pages interface to use struct dev_pagemap") Cc: Logan Gunthorpe Cc: Christoph Hellwig Cc: Dan Williams Signed-off-by: Oliver O'Halloran --- Both in-tree users of devm_memremap_pages() embed dev_pagemap

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring wrote: > On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler > wrote: >> This patch introduces event tracepoints for tracking a device_nodes >> reference cycle as well as reconfig notifications generated in

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring wrote: > On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler > wrote: >> This patch introduces event tracepoints for tracking a device_nodes >> reference cycle as well as reconfig notifications generated in response >> to node/property manipulations. >>

[PATCH v2] mm, x86: Add ARCH_HAS_ZONE_DEVICE to Kconfig

Currently ZONE_DEVICE depends on X86_64 and this will get unwieldly as new architectures (and platforms) get ZONE_DEVICE support. Move to an arch selected Kconfig option to save us the trouble. Cc: linux...@kvack.org Signed-off-by: Oliver O'Halloran <ooh...@gmail.com> --- v2: add missin

[PATCH v2] mm, x86: Add ARCH_HAS_ZONE_DEVICE to Kconfig

Currently ZONE_DEVICE depends on X86_64 and this will get unwieldly as new architectures (and platforms) get ZONE_DEVICE support. Move to an arch selected Kconfig option to save us the trouble. Cc: linux...@kvack.org Signed-off-by: Oliver O'Halloran --- v2: add missing hunk --- arch/x86/Kconfig

[PATCH] mm, x86: Add ARCH_HAS_ZONE_DEVICE to Kconfig

Currently ZONE_DEVICE depends on X86_64 and this will get unwieldly as new architectures (and platforms) get ZONE_DEVICE support. Move to an arch selected Kconfig option to save us the trouble. Cc: linux...@kvack.org Signed-off-by: Oliver O'Halloran <ooh...@gmail.com> --- arch/x86/Kconf

[PATCH] mm, x86: Add ARCH_HAS_ZONE_DEVICE to Kconfig

Currently ZONE_DEVICE depends on X86_64 and this will get unwieldly as new architectures (and platforms) get ZONE_DEVICE support. Move to an arch selected Kconfig option to save us the trouble. Cc: linux...@kvack.org Signed-off-by: Oliver O'Halloran --- arch/x86/Kconfig | 1 + mm/Kconfig

Re: [PowerPC] 4.10.0 fails to build on BE config

On Tue, Feb 21, 2017 at 6:25 PM, abdul wrote: > Hi, > > Today's mainline build, breaks on Power6 and Power7 (all BE config) with > these build errors > > arch/powerpc/kernel/time.c: In function ‘running_clock’: > arch/powerpc/kernel/time.c:712:2: error: implicit

Re: [PowerPC] 4.10.0 fails to build on BE config

On Tue, Feb 21, 2017 at 6:25 PM, abdul wrote: > Hi, > > Today's mainline build, breaks on Power6 and Power7 (all BE config) with > these build errors > > arch/powerpc/kernel/time.c: In function ‘running_clock’: > arch/powerpc/kernel/time.c:712:2: error: implicit declaration of function >

Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300

On Fri, Jan 13, 2017 at 2:44 PM, Gautham R Shenoy wrote: > On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote: >> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote: >> > From: "Gautham R. Shenoy" >> > >> > Balbir pointed

Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300

On Fri, Jan 13, 2017 at 2:44 PM, Gautham R Shenoy wrote: > On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote: >> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote: >> > From: "Gautham R. Shenoy" >> > >> > Balbir pointed out that in idle_book3s.S and powernv/idle.c some

Re: [PATCH v2 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.

c) { > - powernv_states[nr_idle_states].target_residency = > - ((unsigned int)residency_ns[i]) / 1000; > - } > - > nr_idle_states++; > } > out: > diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h > index bb31373..c4e10f8 100644 > --- a/include/linux/cpuidle.h > +++ b/include/linux/cpuidle.h > @@ -62,6 +62,7 @@ struct cpuidle_state { > }; > > /* Idle State Flags */ > +#define CPUIDLE_FLAG_NONE (0x00) > #define CPUIDLE_FLAG_COUPLED (0x02) /* state applies to multiple cpus */ > #define CPUIDLE_FLAG_TIMER_STOP (0x04) /* timer is stopped on this state */ > > -- > 1.9.4 > Looks good otherwise. Reviewed-by: Oliver O'Halloran <ooh...@gmail.com>

Re: [PATCH v2 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.

> - ((unsigned int)residency_ns[i]) / 1000; > - } > - > nr_idle_states++; > } > out: > diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h > index bb31373..c4e10f8 100644 > --- a/include/linux/cpuidle.h > +++ b/include/linux/cpuidle.h > @@ -62,6 +62,7 @@ struct cpuidle_state { > }; > > /* Idle State Flags */ > +#define CPUIDLE_FLAG_NONE (0x00) > #define CPUIDLE_FLAG_COUPLED (0x02) /* state applies to multiple cpus */ > #define CPUIDLE_FLAG_TIMER_STOP (0x04) /* timer is stopped on this state */ > > -- > 1.9.4 > Looks good otherwise. Reviewed-by: Oliver O'Halloran

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Mon, Sep 12, 2016 at 3:27 PM, Christoph Hellwig wrote: > On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote: >> I think this goes back to our previous discussion about support for the PMEM >> programming model. Really I think what NVML needs isn't a way to tell

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Mon, Sep 12, 2016 at 3:27 PM, Christoph Hellwig wrote: > On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote: >> I think this goes back to our previous discussion about support for the PMEM >> programming model. Really I think what NVML needs isn't a way to tell if it >> is getting a

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

On Mon, Sep 12, 2016 at 3:31 AM, Dan Williams wrote: > As evidenced by this bug report [1], userspace libraries are interested > in whether a mapping is DAX mapped, i.e. no intervening page cache. > Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an >

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

On Mon, Sep 12, 2016 at 3:31 AM, Dan Williams wrote: > As evidenced by this bug report [1], userspace libraries are interested > in whether a mapping is DAX mapped, i.e. no intervening page cache. > Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > explicit "is dax"

Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.

On Tue, Aug 23, 2016 at 1:21 PM, Balbir Singh wrote: > >> zImage on ppc64 BE is an ELF32 file. This patch set only supports loading >> ELF files of the same class as the kernel, so a 64 bit kernel can't load an >> ELF32 file. It would be possible to add such support, but it

Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.

On Tue, Aug 23, 2016 at 1:21 PM, Balbir Singh wrote: > >> zImage on ppc64 BE is an ELF32 file. This patch set only supports loading >> ELF files of the same class as the kernel, so a 64 bit kernel can't load an >> ELF32 file. It would be possible to add such support, but it would be a new >>