* Re: [PATCH 3/6] libnvdimm: Add device-tree based driver
From: Dan Williams @ 2018-03-23 17:07 UTC (permalink / raw)
To: Oliver O'Halloran; +Cc: linux-nvdimm, Device Tree, linuxppc-dev
In-Reply-To: <20180323081209.31387-3-oohall@gmail.com>
On Fri, Mar 23, 2018 at 1:12 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
> This patch adds peliminary device-tree bindings for the NVDIMM driver.
*preliminary
> Currently this only supports one bus (created at probe time) which all
> regions are added to with individual regions being created by a platform
> device driver.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> ---
> I suspect the platform driver should be holding a reference to the
> created region. I left that out here since previously Dan has said
> he'd rather keep the struct device internal to libnvdimm and the only
> other way a region device can disappear is when the bus is unregistered.
Hmm, but this still seems broken if bus teardown races region
teardown. I think the more natural model, given the way libnvdimm is
structured, to have each of these of_nd_region instances create their
own nvdimm bus. Thoughts?
^ permalink raw reply
* Re: [PATCH 2/6] libnvdimm: Add nd_region_destroy()
From: Dan Williams @ 2018-03-23 16:59 UTC (permalink / raw)
To: Oliver O'Halloran; +Cc: linux-nvdimm, Device Tree, linuxppc-dev
In-Reply-To: <20180323081209.31387-2-oohall@gmail.com>
On Fri, Mar 23, 2018 at 1:12 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
> Currently there's no way to remove a region from and nvdimm_bus without
> tearing down the whole bus. This patch adds an API for removing a single
> region from the bus so that we can implement a sensible unbind operation
> for the of_nd_region platform driver.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> ---
> drivers/nvdimm/region_devs.c | 6 ++++++
> include/linux/libnvdimm.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
> index 2f1d5771100e..76f46fd1fae0 100644
> --- a/drivers/nvdimm/region_devs.c
> +++ b/drivers/nvdimm/region_devs.c
> @@ -1039,6 +1039,12 @@ struct nd_region *nvdimm_blk_region_create(struct nvdimm_bus *nvdimm_bus,
> }
> EXPORT_SYMBOL_GPL(nvdimm_blk_region_create);
>
> +void nd_region_destroy(struct nd_region *region)
Let's put this in the "nvdimm_" namespace so it pairs with the
nvdimm_*_region_create() apis.
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Jason Gunthorpe @ 2018-03-23 16:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Oliver, Sinan Kaya,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-rdma@vger.kernel.org
In-Reply-To: <1521726722.16434.312.camel@kernel.crashing.org>
On Fri, Mar 23, 2018 at 12:52:02AM +1100, Benjamin Herrenschmidt wrote:
> > > - Make writel_relaxed() be a simple store without barriers, and
> > > readl_relaxed() be "eieio, read, eieio", thus allowing write combining
> > > to happen between successive writel_relaxed on WC space (no change on
> > > normal NC space) while maintaining the ordering between relaxed reads
> > > and writes. The flip side is a (slight) increased overhead of
> > > readl_relaxed.
> >
> > Are there many drivers that actually do writeX() on WC space?
> > memory-barriers.txt
> > pretty much says that all bets are off and no ordering guarantees can be assumed
> > when using readX/writeX on prefetchable IO memory. It seems sketchy enough to
> > give me some pause, but maybe it works fine elsewhere.
>
> I don't know whether any does it, but I want to provide a way for a
> driver to somewhat reliably obtain write combine semantics without
> having to hand code endian swap and other horrors involved with using
> __raw_* accessors.
Many of the drivers in drivers/infiniband work with write combining
memory.
The usual pattern is a desire to push 32 or 64 bytes to the WC BAR as
efficiently as possible, ideally in a single PCI-E TLP.
A memcpy_to_wc primitive could probably cover these use cases, no need
to redesign the IO accessors..
The WC memory is never read, so read/write order is not important to
any infiniband driver.
What is very important is keeping the WC behavior isolated within the
spinlock. WC to the same addresses cannot be permitted in this pattern:
writel(addr = 0);
mmiowmb();
spin_unlock();
spin_lock()
writel(addr = 0);
The CPU must always generate two PCI-E TLPs to the device.
This is a super performance critical operation for most drivers and
directly impacts network performance.
Jason
^ permalink raw reply
* Re: [PATCH] cxl: disable the lazy approach for irqs in POWERVM environment.
From: christophe lombard @ 2018-03-23 16:17 UTC (permalink / raw)
To: benh, linuxppc-dev, fbarrat, vaibhav, andrew.donnellan
In-Reply-To: <1521771288.16434.326.camel@au1.ibm.com>
Le 23/03/2018 à 03:14, Benjamin Herrenschmidt a écrit :
> On Thu, 2018-03-22 at 17:37 +0100, Christophe Lombard wrote:
>> The cxl driver cannot disable the interrupt at the device level and has
>> to use disable_irq[_nosync] instead.
>> To avoid the implementation of the lazy optimisation (the interrupt is
>> marked disabled, but the hardware is left unmasked), we can disable it,
>> for a particular irq line, by calling
>> 'irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY)'.
>
> Why do you need that ? What's wrong with the lazy approach ? It makes
> disable_irq/enable_irq faster...
>
> You shouldn't need that unless your device is generating a *LOT* of
> irqs while disabled.
>
An issue on POWERVM (CAPI) has been introduced with the following patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bf22ff45bed664aefb5c4e43029057a199b7070c
The PSL or AFU interrupts are never received by the cxl driver because
the interrupts are never unmasked.
Without this patch (genirq: Avoid unnecessary low level irq function
calls), the callback desc->irq_data.chip->irq_unmask(&desc->irq_data);
(= ics_rtas_unmask_irq()) is called by default through irq_enable().
The cxl driver disables the interrupts before attaching the process
element and enables the interrupts after that.
In the current code, irq_enable() unmasks the irq only if the irq state
is IRQD_IRQ_MASKED but it does not.
Call irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY) allows forcing
irq_disable() to update the irq state to IRQD_IRQ_MASKED and by default
irq_enable() will unmask the irq through ics_rtas_unmask_irq().
>> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
>> ---
>> drivers/misc/cxl/guest.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
>> index f58b4b6c..dc476e1 100644
>> --- a/drivers/misc/cxl/guest.c
>> +++ b/drivers/misc/cxl/guest.c
>> @@ -389,6 +389,7 @@ static void disable_afu_irqs(struct cxl_context *ctx)
>> hwirq = ctx->irqs.offset[r];
>> for (i = 0; i < ctx->irqs.range[r]; hwirq++, i++) {
>> virq = irq_find_mapping(NULL, hwirq);
>> + irq_set_status_flags(virq, IRQ_DISABLE_UNLAZY);
>> disable_irq(virq);
>> }
>> }
^ permalink raw reply
* Re: [PATCH RFC rebase 9/9] powerpc/64: barrier_nospec: Add commandline trigger
From: Diana Madalina Craciun @ 2018-03-23 15:59 UTC (permalink / raw)
To: Michal Suchanek, linuxppc-dev@lists.ozlabs.org
Cc: Kate Stewart, Madhavan Srinivasan, Mahesh Salgaonkar, Al Viro,
Paul Mackerras, Michael Neuling, Bryant G. Ly, Naveen N. Rao,
Daniel Axtens, Nicholas Piggin, Cédric Le Goater,
David Gibson, Greg Kroah-Hartman, linux-kernel@vger.kernel.org,
Sergey Senozhatsky, Masami Hiramatsu, Andrew Donnellan,
Philippe Ombredanne, Joe Perches, Oliver O'Halloran,
Andrew Morton, Tobin C. Harding
In-Reply-To: <1dcf7403042daddcdb8109f6b852b9bb9d768f89.1521141122.git.msuchanek@suse.de>
On 3/15/2018 9:34 PM, Michal Suchanek wrote:=0A=
> Add commandline options spectre_v2 and nospectre_v2=0A=
>=0A=
> These are named same as similar x86 options regardless of actual effect=
=0A=
> to not require platform-specific configuration.=0A=
>=0A=
> Supported options:=0A=
> nospectre_v2 or spectre_v2=3Doff - speculation barrier not used=0A=
> spectre_v2=3Don or spectre_v2=3Dauto - speculation barrier used=0A=
=0A=
Why the barrier is enabled only for spectre variant 2 mitigations? It=0A=
can be used as well for variant 1 mitigations. In fact I am not sure=0A=
that the places where it is used fall under spectre 2 at all.=0A=
=0A=
>=0A=
> Changing the settings after boot is not supported and VM migration may=0A=
> change requirements so auto is same as on.=0A=
>=0A=
> Based on s390 implementation=0A=
>=0A=
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>=0A=
> ---=0A=
> arch/powerpc/kernel/setup_64.c | 22 ++++++++++++++++++++++=0A=
> 1 file changed, 22 insertions(+)=0A=
>=0A=
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_6=
4.c=0A=
> index f6678a7b6114..c74e656265df 100644=0A=
> --- a/arch/powerpc/kernel/setup_64.c=0A=
> +++ b/arch/powerpc/kernel/setup_64.c=0A=
> @@ -840,6 +840,28 @@ static int __init handle_no_pti(char *p)=0A=
> }=0A=
> early_param("nopti", handle_no_pti);=0A=
> =0A=
> +static int __init nospectre_v2_setup_early(char *str)=0A=
> +{=0A=
> + no_nospec =3D true;=0A=
> + return 0;=0A=
> +}=0A=
> +early_param("nospectre_v2", nospectre_v2_setup_early);=0A=
> +=0A=
> +static int __init spectre_v2_setup_early(char *str)=0A=
> +{=0A=
> + if (str && !strncmp(str, "on", 2))=0A=
> + no_nospec =3D false;=0A=
> +=0A=
> + if (str && !strncmp(str, "off", 3))=0A=
> + no_nospec =3D true;=0A=
> +=0A=
> + if (str && !strncmp(str, "auto", 4))=0A=
> + no_nospec =3D false;=0A=
> +=0A=
> + return 0;=0A=
> +}=0A=
> +early_param("spectre_v2", spectre_v2_setup_early);=0A=
> +=0A=
> static void do_nothing(void *unused)=0A=
> {=0A=
> /*=0A=
=0A=
Thanks,=0A=
=0A=
Diana=0A=
=0A=
^ permalink raw reply
* Re: [PATCH net-next] ibmvnic: Potential NULL dereference in clean_one_tx_pool()
From: Thomas Falcon @ 2018-03-23 15:06 UTC (permalink / raw)
To: Dan Carpenter, Benjamin Herrenschmidt
Cc: John Allen, Paul Mackerras, Michael Ellerman, netdev,
linuxppc-dev, kernel-janitors
In-Reply-To: <20180323113615.GA28518@mwanda>
On 03/23/2018 06:36 AM, Dan Carpenter wrote:
> There is an && vs || typo here, which potentially leads to a NULL
> dereference.
Thanks for catching that!
>
> Fixes: e9e1e97884b7 ("ibmvnic: Update TX pool cleaning routine")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
> index 5632c030811b..0389a7a52152 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -1135,7 +1135,7 @@ static void clean_one_tx_pool(struct ibmvnic_adapter *adapter,
> u64 tx_entries;
> int i;
>
> - if (!tx_pool && !tx_pool->tx_buff)
> + if (!tx_pool || !tx_pool->tx_buff)
> return;
>
> tx_entries = tx_pool->num_buffers;
>
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Sinan Kaya @ 2018-03-23 13:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Oliver
Cc: linuxppc dev list, linux-rdma@vger.kernel.org, Marc Zyngier,
Will Deacon
In-Reply-To: <1521764168.16434.324.camel@kernel.crashing.org>
On 3/22/2018 8:16 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-22 at 12:51 -0500, Sinan Kaya wrote:
>> On 3/22/2018 8:52 AM, Benjamin Herrenschmidt wrote:
>>>>> No, it's not sufficient.
>>>
>>> Just to clarify ... barrier() is just a compiler barrier, it means the
>>> compiler will generate things in the order they are written. This isn't
>>> sufficient on archs with an OO memory model, where an actual memory
>>> barrier instruction needs to be emited.
>>
>> Surprisingly, ARM64 GCC compiler generates a write barrier as
>> opposed to preventing code reordering.
>>
>> I was curious if this is an ARM only thing or not.
>
> Are you sure of that ? I thought it's the ARM implementation of writel
> that had an explicit write barrier in it:
Yes, I'm %100 sure. The answer is both writel() and barrier() generates
a write barrier instruction. I found this by searching the kernel disassembly
for back to back "dsb st" instruction.
>
> #define writel(v,c) ({ __iowmb(); writel_relaxed((v),(c)); })
>
> And __iowmb() is
>
> #define __iowmb() wmb()
>
> Note, I'm a bit dubious about this in ARM:
>
> #define readl(c) ({ u32 __v = readl_relaxed(c); __iormb(); __v; }
>
> Will, Marc, on powerpc, we put a sync *before* the read in readl etc...
>
> The reasoning was there could be some DMA setup followed by a side
> effect readl rather than a side effect writel to trigger a DMA. Granted
> I wouldn't expect modern devices to be that stupid, but I have vague
> memory of some devices back in the day having that sort of read ops.
>
> In general, I though the model offerred by x86 and thus by Linux
> readl/writel was full synchronization both before and after the MMIO,
> vs either other MMIO or all other forms of ops (cachable memory, locks
> etc...).
>
> Also, can't the above readl_relaxed leak out of a lock ?
I think you are asking about PPC, correct?
I read somewhere that PPC implementation keeps track of MMIO accesses and
has an implicit barrier inside the spin_unlock() code for such accesses.
Isn't this true?
>
> Cheers,
> Ben.
>
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Matthew Wilcox @ 2018-03-23 12:48 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <1521736598-12812-1-git-send-email-blackzert@gmail.com>
On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
Why should this be done in the kernel rather than libc? libc is perfectly
capable of specifying random numbers in the first argument of mmap.
^ permalink raw reply
* Re: DMA Mapping Error in ppc64
From: Jared Bents @ 2018-03-23 12:41 UTC (permalink / raw)
To: Oliver; +Cc: linuxppc-dev
In-Reply-To: <CAOSf1CFHSnfBgnkyFi1o3SQp7pJvQBk64eAv+SPmOmMVzzQC3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6270 bytes --]
Thank you for the advice. Looks like I get to try to rewrite the ath9k and
ath10k drivers to use dma_alloc_coherent() instead of kmemdup() and
dev_alloc_skb()
On Thu, Mar 22, 2018 at 8:19 PM, Oliver <oohall@gmail.com> wrote:
> On Fri, Mar 23, 2018 at 1:37 AM, Jared Bents
> <jared.bents@rockwellcollins.com> wrote:
> > Thank you for the response but unfortunately, it looks like I already
> > have that and it is being used. To verify, I commented that out and
> > got the failure "dma_direct_alloc_coherent: No suitable zone for pfn
> > 0xe0000". Below is the code flow for function
> > ath10k_pci_hif_exchange_bmi_msg which is showing the first dma mapping
> > error.
> >
> > ath10k_pci_hif_exchange_bmi_msg -> dma_map_single ->
> > dma_map_single_attrs -> swiotlb_map_page -> dma_capable (returns
> > false)
> >
> >
> > dma_capable is what reports the failure in that flow.
> >
> > static inline bool dma_capable(struct device *dev, dma_addr_t addr,
> size_t size)
> > {
> > #ifdef CONFIG_SWIOTLB
> > struct dev_archdata *sd = &dev->archdata;
> >
> > if (sd->max_direct_dma_addr && addr + size > sd->max_direct_dma_addr)
> > return false;
> > #endif
> >
> > if (!dev->dma_mask)
> > return false;
> >
> > return addr + size - 1 <= *dev->dma_mask;
> > }
> > Getting the below values:
> > addr = 1ee376218
> > size = 4
> > sd->max_direct_dma_addr = e0000000 which is I believe DMA window size
> (e0000000)
> >
> > when executed sd->max_direct_dma_addr(e0000000) && addr(1ee376218) +
> > size(4) becomes e0000004 which is > sd->max_direct_dma_addr (e0000000)
> >
> >
> > So even though limit_zone_pfn(ZONE_DMA32, 1UL << (31 - PAGE_SHIFT)) is
> > being used in arch/powerpc/platforms/85xx/corenet_generic.c,
>
> > kmemdup(req, req_len, GFP_KERNEL) is returning an address that when
> > sent to dma_map_single(), results in a bad map.
>
> You need to use (GFP_KERNEL | GFP_DMA32) to constrain the allocations
> to ZONE_DMA32. Without that the kmemdup() will allocate from any zone
> so you'll probably get an unmappable address.
>
> That said, the driver probably shouldn't be using kmemdup() here.
> DMA-API.txt pretty explicitly says that drivers should not assume that
> dma_map_single() will work with arbitrary memory. It should be using
> dma_alloc_coherent() or a dma pool here.
>
> > - Jared
> >
> > On Wed, Mar 21, 2018 at 11:54 PM, Oliver <oohall@gmail.com> wrote:
> >> On Thu, Mar 22, 2018 at 8:00 AM, Jared Bents
> >> <jared.bents@rockwellcollins.com> wrote:
> >>> Hi all,
> >>>
> >>> Apologies for the amount of information but we've been debugging this
> >>> for a while and I wanted to get what we are seeing captured as much as
> >>> possible. We are a T1042 processor and have a total 8GB DDR and our
> >>> kernel version is fsl-sdk-v2.0-1703 (linux v4.1.35) as that is the
> >>> latest version supplied by NXP.
> >>>
> >>> A while ago we ported from 32 bit to 64 bit. Everything continued to
> >>> work except the ath10k module we have. So as a first step, we checked
> >>> to see if an ath9k module also failed to work and it was also no
> >>> longer working. The ath10k is working fine on a 32 bit system but
> >>> it's not working on 64 bit system as we are getting dma mapping errors
> >>> when trying to initialize the wifi modules.
> >>>
> >>> pci_bus 0002:01: bus scan returning with max=01
> >>> pci_bus 0002:01: busn_res: [bus 01] end is updated to 01
> >>> pci_bus 0002:00: bus scan returning with max=01
> >>> ath10k_pci 0000:01:00.0: unable to get target info from device
> >>> ath10k_pci 0000:01:00.0: could not get target info (-5)
> >>> ath10k_pci 0000:01:00.0: could not probe fw (-5)
> >>> ath10k_pci 0001:01:00.0: Direct firmware load for
> >>> ath10k/cal-pci-0001:01:00.0.bin failed with error -2
> >>>
> >>>
> >>> First, we have tried the mainline kernel (v4.15) to see if that would
> >>> fix the issue, it did not. So I made a patch for the ath10k driver to
> >>> restrict to just GFP_DMA areas when allocating memory or creating
> >>> sk_buffs and have attached it. The ath10k wifi modules now initialize
> >>> correctly but when I try to connect them and send traffic, they get a
> >>> DMA mapping error from the sk_buff that it receives from elsewhere in
> >>> the kernel. So while the driver appears to be fixable with the patch,
> >>> the modules are still unusable due to data being sent to the driver
> >>> when ath10k_tx is called and it tries to dma map with the provided
> >>> skb. Also, according to the ath10k mailing list, GFP_DMA is not
> >>> supposed to be used in general. The error below is the same sort of
> >>> dma mapping error that is seen when initializing the modules without
> >>> the patch to OR with GFP_DMA.
> >>>
> >>> ath10k_pci 0001:01:00.0: failed to transmit packet, dropping: -5
> >>>
> >>>
> >>> We asked on the ath10k mailing list if anyone else is having this
> >>> problem and no one else seems to have the issue but they are using
> >>> different architectures (ARM or X86). As a result, it does not seem to
> >>> be a driver issue to us but something within the PowerPC arch. So we
> >>> dug a little deeper to try to find what addresses being mapped are
> >>> working and what address being mapped are not working.
> >>>
> >>> We found that when the virtual address of data pointer (a member of
> >>> sk_buff) is above ~3.7 GB RAM address range then return address from
> >>> dma_map_single API is failed to validate in dma_mapping_error
> >>> function.
> >>>
> >>> We also noticed that in a 64bit machine sometimes ping is working and
> >>> because of the virtual address is under ~3.7GAM RAM address range. So
> >>> if we set mem=2048M in the bootargs, the ath10k module works
> >>> perfectly, however this isn't a real solution since it cuts our
> >>> available RAM from 8GB to 2GB.
> >>
> >> I think there's a known issue with the freescale PCIe root complex
> >> where it can't DMA beyond the 4GB mark. There's a workaround in
> >> the form of limit_zone_pfn() which you can use to put the lower 4GB into
> >> ZONE_DMA32 and allocate from there rather than ZONE_NORMAL.
> >> For details of how to use it have a look at corenet_gen_setup_arch() in
> >> arch/powerpc/platforms/85xx/corenet_generic.c
> >>
> >> Hope that helps,
> >> Oliver
>
[-- Attachment #2: Type: text/html, Size: 8533 bytes --]
^ permalink raw reply
* Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec
From: Mathieu Malaterre @ 2018-03-23 12:24 UTC (permalink / raw)
To: christophe leroy
Cc: Michael Ellerman, LKML, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <97df68d1-d4fe-bf8e-7852-9b418eec042f@c-s.fr>
On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy
<christophe.leroy@c-s.fr> wrote:
>
>
> Le 22/03/2018 =C3=A0 21:20, Mathieu Malaterre a =C3=A9crit :
>>
>> Some functions prototypes were missing for the non-altivec code. Add the
>> missing prototypes directly in xor_vmx, fix warnings treated as errors
>> with
>> W=3D1:
>>
>> arch/powerpc/lib/xor_vmx_glue.c:18:6: error: no previous prototype fo=
r
>> =E2=80=98xor_altivec_2=E2=80=99 [-Werror=3Dmissing-prototypes]
>> arch/powerpc/lib/xor_vmx_glue.c:29:6: error: no previous prototype fo=
r
>> =E2=80=98xor_altivec_3=E2=80=99 [-Werror=3Dmissing-prototypes]
>> arch/powerpc/lib/xor_vmx_glue.c:40:6: error: no previous prototype fo=
r
>> =E2=80=98xor_altivec_4=E2=80=99 [-Werror=3Dmissing-prototypes]
>> arch/powerpc/lib/xor_vmx_glue.c:52:6: error: no previous prototype fo=
r
>> =E2=80=98xor_altivec_5=E2=80=99 [-Werror=3Dmissing-prototypes]
>>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> ---
>> arch/powerpc/lib/xor_vmx.h | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/powerpc/lib/xor_vmx.h b/arch/powerpc/lib/xor_vmx.h
>> index 5c2b0839b179..2173e3c84151 100644
>> --- a/arch/powerpc/lib/xor_vmx.h
>> +++ b/arch/powerpc/lib/xor_vmx.h
>> @@ -19,3 +19,17 @@ void __xor_altivec_4(unsigned long bytes, unsigned lo=
ng
>> *v1_in,
>> void __xor_altivec_5(unsigned long bytes, unsigned long *v1_in,
>> unsigned long *v2_in, unsigned long *v3_in,
>> unsigned long *v4_in, unsigned long *v5_in)=
;
>> +
>> +void xor_altivec_2(unsigned long bytes, unsigned long *v1_in,
>> + unsigned long *v2_in);
>> +
>
>
> Only used in one place, should be static instead of adding it in a .h
>
> Same for the other ones.
$ git grep xor_altivec_2
[...]
arch/powerpc/lib/xor_vmx_glue.c:EXPORT_SYMBOL(xor_altivec_2);
Are you sure I can change this function to static ?
> Christophe
>
>
>> +void xor_altivec_3(unsigned long bytes, unsigned long *v1_in,
>> + unsigned long *v2_in, unsigned long *v3_in)=
;
>> +
>> +void xor_altivec_4(unsigned long bytes, unsigned long *v1_in,
>> + unsigned long *v2_in, unsigned long *v3_in,
>> + unsigned long *v4_in);
>> +
>> +void xor_altivec_5(unsigned long bytes, unsigned long *v1_in,
>> + unsigned long *v2_in, unsigned long *v3_in,
>> + unsigned long *v4_in, unsigned long *v5_in)=
;
>>
>
> ---
> L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=
=C3=A9rifi=C3=A9e par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
^ permalink raw reply
* Re: [PATCH 19/19] powerpc/tau: Synchronize function prototypes and body
From: christophe leroy @ 2018-03-23 12:22 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-20-malat@debian.org>
Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit :
> Some function prototypes and body for Thermal Assist Units were not in
> sync. Update the function definition to match the existing function
> declaration found in `setup-common.c`, changing an `int` return type to a
> `u32` return type. Move the prototypes to a header file. Fix the following
> warnings, treated as error with W=1:
>
> arch/powerpc/kernel/tau_6xx.c:257:5: error: no previous prototype for ‘cpu_temp_both’ [-Werror=missing-prototypes]
> arch/powerpc/kernel/tau_6xx.c:262:5: error: no previous prototype for ‘cpu_temp’ [-Werror=missing-prototypes]
> arch/powerpc/kernel/tau_6xx.c:267:5: error: no previous prototype for ‘tau_interrupts’ [-Werror=missing-prototypes]
>
> Compile tested with CONFIG_TAU_INT.
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/kernel/irq.c | 2 +-
> arch/powerpc/kernel/setup-common.c | 6 ------
> arch/powerpc/kernel/setup.h | 6 ++++++
> arch/powerpc/kernel/tau_6xx.c | 7 +++++--
> 4 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index f88038847790..3777b6e09142 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -89,7 +89,7 @@ atomic_t ppc_n_lost_interrupts;
>
> #ifdef CONFIG_TAU_INT
> extern int tau_initialized;
> -extern int tau_interrupts(int);
> +extern u32 tau_interrupts(unsigned long cpu);
> #endif
> #endif /* CONFIG_PPC32 */
>
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index d73ec518ef80..bd3675c3984b 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -192,12 +192,6 @@ void machine_halt(void)
> machine_hang();
> }
>
> -
> -#ifdef CONFIG_TAU
> -extern u32 cpu_temp(unsigned long cpu);
> -extern u32 cpu_temp_both(unsigned long cpu);
> -#endif /* CONFIG_TAU */
> -
> #ifdef CONFIG_SMP
> DEFINE_PER_CPU(unsigned int, cpu_pvr);
> #endif
> diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
> index d768023a04bd..3c9c19430439 100644
> --- a/arch/powerpc/kernel/setup.h
> +++ b/arch/powerpc/kernel/setup.h
> @@ -70,4 +70,10 @@ void kvm_cma_reserve(void);
> static inline void kvm_cma_reserve(void) { };
> #endif
>
> +#ifdef CONFIG_TAU
> +extern u32 cpu_temp(unsigned long cpu);
> +extern u32 cpu_temp_both(unsigned long cpu);
> +extern u32 tau_interrupts(unsigned long cpu);
extern keyword is not needed
Christophe
> +#endif /* CONFIG_TAU */
> +
> #endif /* __ARCH_POWERPC_KERNEL_SETUP_H */
> diff --git a/arch/powerpc/kernel/tau_6xx.c b/arch/powerpc/kernel/tau_6xx.c
> index 1fc6a89a978e..e2ab8a111b69 100644
> --- a/arch/powerpc/kernel/tau_6xx.c
> +++ b/arch/powerpc/kernel/tau_6xx.c
> @@ -27,6 +27,9 @@
> #include <asm/cache.h>
> #include <asm/8xx_immap.h>
> #include <asm/machdep.h>
> +#include <asm/asm-prototypes.h>
> +
> +#include "setup.h"
>
> static struct tau_temp
> {
> @@ -259,12 +262,12 @@ u32 cpu_temp_both(unsigned long cpu)
> return ((tau[cpu].high << 16) | tau[cpu].low);
> }
>
> -int cpu_temp(unsigned long cpu)
> +u32 cpu_temp(unsigned long cpu)
> {
> return ((tau[cpu].high + tau[cpu].low) / 2);
> }
>
> -int tau_interrupts(unsigned long cpu)
> +u32 tau_interrupts(unsigned long cpu)
> {
> return (tau[cpu].interrupts);
> }
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 15/19] powerpc: Add missing prototype
From: christophe leroy @ 2018-03-23 12:20 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-16-malat@debian.org>
Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit :
> Add one missing prototype for function rh_dump_blk. Fix warning treated as
> error in W=1:
>
> arch/powerpc/lib/rheap.c:740:6: error: no previous prototype for ‘rh_dump_blk’ [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/include/asm/rheap.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/rheap.h b/arch/powerpc/include/asm/rheap.h
> index 172381769cfc..e75d96de19a0 100644
> --- a/arch/powerpc/include/asm/rheap.h
> +++ b/arch/powerpc/include/asm/rheap.h
> @@ -83,6 +83,9 @@ extern int rh_get_stats(rh_info_t * info, int what, int max_stats,
> /* Simple dump of remote heap info */
> extern void rh_dump(rh_info_t * info);
>
> +/* Simple dump of remote info block */
> +extern void rh_dump_blk(rh_info_t *info, rh_block_t *blk);
> +
Only used in one place, should be static
Christophe
> /* Set owner of taken block */
> extern int rh_set_owner(rh_info_t * info, unsigned long start, const char *owner);
>
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec
From: christophe leroy @ 2018-03-23 12:19 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-15-malat@debian.org>
Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit :
> Some functions prototypes were missing for the non-altivec code. Add the
> missing prototypes directly in xor_vmx, fix warnings treated as errors with
> W=1:
>
> arch/powerpc/lib/xor_vmx_glue.c:18:6: error: no previous prototype for ‘xor_altivec_2’ [-Werror=missing-prototypes]
> arch/powerpc/lib/xor_vmx_glue.c:29:6: error: no previous prototype for ‘xor_altivec_3’ [-Werror=missing-prototypes]
> arch/powerpc/lib/xor_vmx_glue.c:40:6: error: no previous prototype for ‘xor_altivec_4’ [-Werror=missing-prototypes]
> arch/powerpc/lib/xor_vmx_glue.c:52:6: error: no previous prototype for ‘xor_altivec_5’ [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/lib/xor_vmx.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/powerpc/lib/xor_vmx.h b/arch/powerpc/lib/xor_vmx.h
> index 5c2b0839b179..2173e3c84151 100644
> --- a/arch/powerpc/lib/xor_vmx.h
> +++ b/arch/powerpc/lib/xor_vmx.h
> @@ -19,3 +19,17 @@ void __xor_altivec_4(unsigned long bytes, unsigned long *v1_in,
> void __xor_altivec_5(unsigned long bytes, unsigned long *v1_in,
> unsigned long *v2_in, unsigned long *v3_in,
> unsigned long *v4_in, unsigned long *v5_in);
> +
> +void xor_altivec_2(unsigned long bytes, unsigned long *v1_in,
> + unsigned long *v2_in);
> +
Only used in one place, should be static instead of adding it in a .h
Same for the other ones.
Christophe
> +void xor_altivec_3(unsigned long bytes, unsigned long *v1_in,
> + unsigned long *v2_in, unsigned long *v3_in);
> +
> +void xor_altivec_4(unsigned long bytes, unsigned long *v1_in,
> + unsigned long *v2_in, unsigned long *v3_in,
> + unsigned long *v4_in);
> +
> +void xor_altivec_5(unsigned long bytes, unsigned long *v1_in,
> + unsigned long *v2_in, unsigned long *v3_in,
> + unsigned long *v4_in, unsigned long *v5_in);
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 13/19] powerpc/52xx: Add missing functions prototypes
From: christophe leroy @ 2018-03-23 12:18 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-14-malat@debian.org>
Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
> The function prototypes were declared within a `#ifdef CONFIG_PPC_LITE5200`
> block which would prevent them from being visible when compiling
> `mpc52xx_pm.c`. Move the prototypes outside of the `#ifdef` block to fix
> the following warnings treated as errors with W=1:
>
> arch/powerpc/platforms/52xx/mpc52xx_pm.c:58:5: error: no previous prototype for ‘mpc52xx_pm_prepare’ [-Werror=missing-prototypes]
> arch/powerpc/platforms/52xx/mpc52xx_pm.c:113:5: error: no previous prototype for ‘mpc52xx_pm_enter’ [-Werror=missing-prototypes]
> arch/powerpc/platforms/52xx/mpc52xx_pm.c:181:6: error: no previous prototype for ‘mpc52xx_pm_finish’ [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/include/asm/mpc52xx.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc52xx.h b/arch/powerpc/include/asm/mpc52xx.h
> index e94cede14522..0f6b3cbb119f 100644
> --- a/arch/powerpc/include/asm/mpc52xx.h
> +++ b/arch/powerpc/include/asm/mpc52xx.h
> @@ -350,14 +350,14 @@ extern struct mpc52xx_suspend mpc52xx_suspend;
> extern int __init mpc52xx_pm_init(void);
> extern int mpc52xx_set_wakeup_gpio(u8 pin, u8 level);
>
> -#ifdef CONFIG_PPC_LITE5200
> -extern int __init lite5200_pm_init(void);
> -
> /* lite5200 calls mpc5200 suspend functions, so here they are */
> extern int mpc52xx_pm_prepare(void);
> extern int mpc52xx_pm_enter(suspend_state_t);
> extern void mpc52xx_pm_finish(void);
> extern char saved_sram[0x4000]; /* reuse buffer from mpc52xx suspend */
> +
> +#ifdef CONFIG_PPC_LITE5200
> +extern int __init lite5200_pm_init(void);
extern keyword is not needed
Christophe
> #endif
> #endif /* CONFIG_PM */
>
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 12/19] powerpc/powermac: Add missing prototype for note_bootable_part()
From: christophe leroy @ 2018-03-23 12:14 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-13-malat@debian.org>
Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
> Add a missing prototype for function `note_bootable_part` to silence a
> warning treated as error with W=1:
>
> arch/powerpc/platforms/powermac/setup.c:361:12: error: no previous prototype for ‘note_bootable_part’ [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/platforms/powermac/setup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
> index ab668cb72263..e3d00f8af441 100644
> --- a/arch/powerpc/platforms/powermac/setup.c
> +++ b/arch/powerpc/platforms/powermac/setup.c
> @@ -352,6 +352,7 @@ static int pmac_late_init(void)
> }
> machine_late_initcall(powermac, pmac_late_init);
>
> +extern void note_bootable_part(dev_t dev, int part, int goodness);
extern keyword is not needed
Christophe
> /*
> * This is __ref because we check for "initializing" before
> * touching any of the __init sensitive things and "initializing"
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 11/19] powerpc/powermac: Move pmac_pfunc_base_install prototype to header file
From: christophe leroy @ 2018-03-23 12:13 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-12-malat@debian.org>
Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
> The pmac_pfunc_base_install prototype was declared in powermac/smp.c since
> function was used there, move it to pmac_pfunc.h header to be visible in
> pfunc_base.c. Fix a warning treated as error with W=1:
>
> arch/powerpc/platforms/powermac/pfunc_base.c:330:12: error: no previous prototype for ‘pmac_pfunc_base_install’ [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/include/asm/pmac_pfunc.h | 1 +
> arch/powerpc/platforms/powermac/smp.c | 1 -
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/pmac_pfunc.h b/arch/powerpc/include/asm/pmac_pfunc.h
> index 73bd8f28f2a8..99f7a288789a 100644
> --- a/arch/powerpc/include/asm/pmac_pfunc.h
> +++ b/arch/powerpc/include/asm/pmac_pfunc.h
> @@ -245,6 +245,7 @@ extern void pmf_put_function(struct pmf_function *func);
>
> extern int pmf_call_one(struct pmf_function *func, struct pmf_args *args);
>
> +extern int pmac_pfunc_base_install(void);
extern keyword is not needed
Christophe
>
> /* Suspend/resume code called by via-pmu directly for now */
> extern void pmac_pfunc_base_suspend(void);
> diff --git a/arch/powerpc/platforms/powermac/smp.c b/arch/powerpc/platforms/powermac/smp.c
> index 95275e0e2efa..447da6db450a 100644
> --- a/arch/powerpc/platforms/powermac/smp.c
> +++ b/arch/powerpc/platforms/powermac/smp.c
> @@ -65,7 +65,6 @@
> #endif
>
> extern void __secondary_start_pmac_0(void);
> -extern int pmac_pfunc_base_install(void);
>
> static void (*pmac_tb_freeze)(int freeze);
> static u64 timebase;
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH net-next] ibmvnic: Potential NULL dereference in clean_one_tx_pool()
From: Dan Carpenter @ 2018-03-23 11:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Thomas Falcon
Cc: John Allen, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, netdev, linuxppc-dev, kernel-janitors
There is an && vs || typo here, which potentially leads to a NULL
dereference.
Fixes: e9e1e97884b7 ("ibmvnic: Update TX pool cleaning routine")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 5632c030811b..0389a7a52152 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1135,7 +1135,7 @@ static void clean_one_tx_pool(struct ibmvnic_adapter *adapter,
u64 tx_entries;
int i;
- if (!tx_pool && !tx_pool->tx_buff)
+ if (!tx_pool || !tx_pool->tx_buff)
return;
tx_entries = tx_pool->num_buffers;
^ permalink raw reply related
* Re: [1/3] powerpc/mm/radix: Remove unused code
From: Michael Ellerman @ 2018-03-23 11:11 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus, mauricfo; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180323045627.16800-1-aneesh.kumar@linux.vnet.ibm.com>
On Fri, 2018-03-23 at 04:56:25 UTC, "Aneesh Kumar K.V" wrote:
> These function are not used in the code. Remove them.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Series applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/99491e2d0e50c53a0620dfec340b24
cheers
^ permalink raw reply
* Re: [1/2] powerpc/mm: Add tracking of the number of coprocessors using a context
From: Michael Ellerman @ 2018-03-23 11:11 UTC (permalink / raw)
To: Balbir Singh, linuxppc-dev; +Cc: aneesh.kumar, npiggin
In-Reply-To: <20180322222906.22084-1-bsingharora@gmail.com>
On Thu, 2018-03-22 at 22:29:05 UTC, Balbir Singh wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Currently, when using coprocessors (which use the Nest MMU), we
> simply increment the active_cpu count to force all TLB invalidations
> to be come broadcast.
>
> Unfortunately, due to an errata in POWER9, we will need to know
> more specifically that coprocessors are in use.
>
> This maintains a separate copros counter in the MMU context for
> that purpose.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Tested-by: Balbir Singh <bsingharora@gmail.com>
Series applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/aff6f8cb3e2170b9e58b0932bce7bf
cheers
^ permalink raw reply
* Re: powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
From: Michael Ellerman @ 2018-03-23 11:11 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180321022228.9606-1-npiggin@gmail.com>
On Wed, 2018-03-21 at 02:22:28 UTC, Nicholas Piggin wrote:
> force_external_irq_replay() can be called in the do_IRQ path with
> interrupts hard enabled and soft disabled if may_hard_irq_enable() set
> MSR[EE]=1. It updates local_paca->irq_happened with a load, modify,
> store sequence. If a maskable interrupt hits during this sequence, it
> will go to the masked handler to be marked pending in irq_happened.
> This update will be lost when the interrupt returns and the store
> instruction executes. This can result in unpredictable latencies,
> timeouts, lockups, etc.
>
> Fix this by ensuring hard interrupts are disabled before modifying
> irq_happened.
>
> This could cause any maskable asynchronous interrupt to get lost, but
> it was noticed on P9 SMP system doing RDMA NVMe target over 100GbE,
> so very high external interrupt rate and high IPI rate. The hang was
> bisected down to enabling doorbell interrupts for IPIs. These provided
> an interrupt type that could run at high rates in the do_IRQ path,
> stressing the race.
>
> Fixes: 1d607bb3bd ("powerpc/irq: Add mechanism to force a replay of interrupts")
> Reported-by: Carol L. Soto <clsoto@us.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/ff6781fd1bb404d8a551c02c35c70c
cheers
^ permalink raw reply
* Re: [PATCH 07/19] powerpc/powermac: Make some functions static
From: christophe leroy @ 2018-03-23 11:05 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-8-malat@debian.org>
Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
> These functions can all be static, make it so. Fix warnings treated as
> errors with W=1:
>
> arch/powerpc/platforms/powermac/pci.c:1022:6: error: no previous prototype for ‘pmac_pci_fixup_ohci’ [-Werror=missing-prototypes]
> arch/powerpc/platforms/powermac/pci.c:1057:6: error: no previous prototype for ‘pmac_pci_fixup_cardbus’ [-Werror=missing-prototypes]
> arch/powerpc/platforms/powermac/pci.c:1094:6: error: no previous prototype for ‘pmac_pci_fixup_pciata’ [-Werror=missing-prototypes]
>
> Also add gcc attribute unused to fix a warning treated as error with W=1:
>
> arch/powerpc/platforms/powermac/pci.c:784:19: error: variable ‘has_address’ set but not used [-Werror=unused-but-set-variable]
> arch/powerpc/platforms/powermac/pci.c:907:22: error: variable ‘ht’ set but not used [-Werror=unused-but-set-variable]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/platforms/powermac/pci.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c
> index 0b8174a79993..d3b9818dd880 100644
> --- a/arch/powerpc/platforms/powermac/pci.c
> +++ b/arch/powerpc/platforms/powermac/pci.c
> @@ -781,7 +781,7 @@ static int __init pmac_add_bridge(struct device_node *dev)
> struct resource rsrc;
> char *disp_name;
> const int *bus_range;
> - int primary = 1, has_address = 0;
> + int primary = 1, has_address __maybe_unused = 0;
YOu could remove it completely, it is never used
>
> DBG("Adding PCI host bridge %pOF\n", dev);
>
> @@ -904,7 +904,7 @@ static int pmac_pci_root_bridge_prepare(struct pci_host_bridge *bridge)
> void __init pmac_pci_init(void)
> {
> struct device_node *np, *root;
> - struct device_node *ht = NULL;
> + struct device_node *ht __maybe_unused = NULL;
Shouldn't ht be enclosed into #ifdef CONFIG_PPC64 instead ?
Christophe
>
> pci_set_flags(PCI_CAN_SKIP_ISA_ALIGN);
>
> @@ -1019,7 +1019,7 @@ static bool pmac_pci_enable_device_hook(struct pci_dev *dev)
> return true;
> }
>
> -void pmac_pci_fixup_ohci(struct pci_dev *dev)
> +static void pmac_pci_fixup_ohci(struct pci_dev *dev)
> {
> struct device_node *node = pci_device_to_OF_node(dev);
>
> @@ -1054,7 +1054,7 @@ void __init pmac_pcibios_after_init(void)
> }
> }
>
> -void pmac_pci_fixup_cardbus(struct pci_dev* dev)
> +static void pmac_pci_fixup_cardbus(struct pci_dev *dev)
> {
> if (!machine_is(powermac))
> return;
> @@ -1091,7 +1091,7 @@ void pmac_pci_fixup_cardbus(struct pci_dev* dev)
>
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_TI, PCI_ANY_ID, pmac_pci_fixup_cardbus);
>
> -void pmac_pci_fixup_pciata(struct pci_dev* dev)
> +static void pmac_pci_fixup_pciata(struct pci_dev *dev)
> {
> u8 progif = 0;
>
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 05/19] powerpc/chrp/setup: Add attribute unused and make some functions static
From: christophe leroy @ 2018-03-23 11:01 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-6-malat@debian.org>
Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
> Add gcc attribute unused to silence a warning.
>
> These functions can all be static, make it so. Fix warnings treated as
> errors with W=1:
>
> arch/powerpc/platforms/chrp/setup.c:97:6: error: no previous prototype for ‘chrp_show_cpuinfo’ [-Werror=missing-prototypes]
> arch/powerpc/platforms/chrp/setup.c:302:13: error: no previous prototype for ‘chrp_setup_arch’ [-Werror=missing-prototypes]
> arch/powerpc/platforms/chrp/setup.c:385:16: error: variable ‘idu_size’ set but not used [-Werror=unused-but-set-variable]
> arch/powerpc/platforms/chrp/setup.c:526:13: error: no previous prototype for ‘chrp_init_IRQ’ [-Werror=missing-prototypes]
> arch/powerpc/platforms/chrp/setup.c:559:1: error: no previous prototype for ‘chrp_init2’ [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/platforms/chrp/setup.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
> index 481ed133e04b..85df479fd631 100644
> --- a/arch/powerpc/platforms/chrp/setup.c
> +++ b/arch/powerpc/platforms/chrp/setup.c
> @@ -94,7 +94,7 @@ static const char *chrp_names[] = {
> "Total Impact Briq"
> };
>
> -void chrp_show_cpuinfo(struct seq_file *m)
> +static void chrp_show_cpuinfo(struct seq_file *m)
> {
> int i, sdramen;
> unsigned int t;
> @@ -299,7 +299,7 @@ static __init void chrp_init(void)
> of_node_put(node);
> }
>
> -void __init chrp_setup_arch(void)
> +static void __init chrp_setup_arch(void)
> {
> struct device_node *root = of_find_node_by_path("/");
> const char *machine = NULL;
> @@ -382,7 +382,7 @@ static void __init chrp_find_openpic(void)
> {
> struct device_node *np, *root;
> int len, i, j;
> - int isu_size, idu_size;
> + int isu_size, idu_size __maybe_unused;
idu_size is never used, you could remove it completely
Christophe
> const unsigned int *iranges, *opprop = NULL;
> int oplen = 0;
> unsigned long opaddr;
> @@ -523,7 +523,7 @@ static void __init chrp_find_8259(void)
> }
> }
>
> -void __init chrp_init_IRQ(void)
> +static void __init chrp_init_IRQ(void)
> {
> #if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(CONFIG_XMON)
> struct device_node *kbd;
> @@ -555,7 +555,7 @@ void __init chrp_init_IRQ(void)
> #endif
> }
>
> -void __init
> +static void __init
> chrp_init2(void)
> {
> #ifdef CONFIG_NVRAM
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 04/19] powerpc/kvm: Mark variable tmp unused
From: christophe leroy @ 2018-03-23 10:08 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-5-malat@debian.org>
Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
> Add gcc attribute unused to variable tmp. Fix warning treated as error with
> W=1:
>
> arch/powerpc/kernel/kvm.c:675:6: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/kernel/kvm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
> index 9ad37f827a97..cd3c088283f9 100644
> --- a/arch/powerpc/kernel/kvm.c
> +++ b/arch/powerpc/kernel/kvm.c
> @@ -672,7 +672,7 @@ static void kvm_use_magic_page(void)
> {
> u32 *p;
> u32 *start, *end;
> - u32 tmp;
> + u32 tmp __maybe_unused;
> u32 features;
>
> /* Tell the host to map the magic page to -4096 on all CPUs */
>
This fonction should use fault_in_pages_readable() instead of
hardcoding the verification.
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 03/19] powerpc: Mark variables as unused
From: christophe leroy @ 2018-03-23 10:03 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-4-malat@debian.org>
Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
> Add gcc attribute unused for two variables. Fix warnings treated as errors
> with W=1:
>
> arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not used [-Werror=unused-but-set-variable]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/kernel/prom_init.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index acf4b2e0530c..6a3ac4522144 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -603,7 +603,7 @@ static void __init early_cmdline_parse(void)
> const char *opt;
>
> char *p;
> - int l = 0;
> + int l __maybe_unused = 0;
>
> prom_cmd_line[0] = 0;
> p = prom_cmd_line;
> @@ -1385,7 +1385,7 @@ static void __init reserve_mem(u64 base, u64 size)
> static void __init prom_init_mem(void)
> {
> phandle node;
> - char *path, type[64];
> + char *path __maybe_unused, type[64];
path is only used if DEBUG_PROM is defined, so it should be enclosed
into #ifdef DEBUG_PROM
Christophe
> unsigned int plen;
> cell_t *p, *endp;
> __be32 val;
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 02/19] powerpc/powermac: Mark variable x as unused
From: christophe leroy @ 2018-03-23 9:38 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180322202007.23088-3-malat@debian.org>
Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
> Since the value of x is never intended to be read, declare it with gcc
> attribute as unused. Fix warning treated as error with W=1:
>
> arch/powerpc/platforms/powermac/udbg_scc.c:76:9: error: variable ‘x’ set but not used [-Werror=unused-but-set-variable]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/platforms/powermac/udbg_scc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powermac/udbg_scc.c b/arch/powerpc/platforms/powermac/udbg_scc.c
> index d83135a9830e..c38ca406df1a 100644
> --- a/arch/powerpc/platforms/powermac/udbg_scc.c
> +++ b/arch/powerpc/platforms/powermac/udbg_scc.c
> @@ -73,7 +73,7 @@ void udbg_scc_init(int force_scc)
> struct device_node *stdout = NULL, *escc = NULL, *macio = NULL;
> struct device_node *ch, *ch_def = NULL, *ch_a = NULL;
> const char *path;
> - int i, x;
> + int i, x __maybe_unused;
You could just replace 'x = in_8(sccc)' by 'in_8(sccc)' and get rid of
the x.
Christophe
>
> escc = of_find_node_by_name(NULL, "escc");
> if (escc == NULL)
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox