* Re: [PATCH] char: nvram: disable on ARM
From: Alexandre Belloni @ 2018-02-07 12:48 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CAK8P3a3dkAESaqGgLAV9uKKet20rVtBXqBJ-eNGbwQv1i05K7A@mail.gmail.com>
On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote:
> On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote:
> >> * arch/arm/kernel/time.c has this code
> >>
> >> #if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
> >> defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
> >> /* this needs a better home */
> >> DEFINE_SPINLOCK(rtc_lock);
> >> EXPORT_SYMBOL(rtc_lock);
> >> #endif /* pc-style 'CMOS' RTC support */
> >>
> >> That can be adapted now, or maybe we could move all definitions into
> >> a common place (that needs some more planning).
> >>
> >
> > Yes, on arm, the rtc_lock is mostly there to please
> > drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver
> > x86 and PPC specific.
> >
> > If we can get rid of arch/powerpc/platforms/chrp/time.c and
> > arch/powerpc/platforms/maple/time.c (so much duplicated code), then it
> > is x86 only.
>
> What about these:
>
> arch/alpha/kernel/rtc.c: spin_lock(&rtc_lock);
> arch/alpha/kernel/rtc.c: spin_unlock(&rtc_lock);
> arch/alpha/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/alpha/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
> arch/arm/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/arm/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
> arch/m32r/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/m32r/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
> arch/m68k/atari/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/m68k/atari/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
> arch/mn10300/kernel/rtc.c:DEFINE_SPINLOCK(rtc_lock);
> arch/mn10300/kernel/rtc.c:EXPORT_SYMBOL(rtc_lock);
> arch/powerpc/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/powerpc/kernel/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
> arch/sparc/kernel/time_32.c:DEFINE_SPINLOCK(rtc_lock);
> arch/sparc/kernel/time_32.c:EXPORT_SYMBOL(rtc_lock);
> arch/sparc/kernel/time_64.c:DEFINE_SPINLOCK(rtc_lock);
>
> Are they all obsolete?
>
Yes and no. For those architecture, the spinlock is only used to make
the driver compile. It is probably not actually needed or at least it
can be made local to the driver.
For alpha, I just realized I never sent a patch removing the spinlock
usage, I'll do that this cycle:
https://github.com/alexandrebelloni/linux/commit/e79e2a754a3a67f2d7e906bfda0042f9dcf66a0b
> >> $ cat /proc/driver/nvram
> >> Checksum status: valid
> >> # floppies : 0
> >> Floppy 0 type : none
> >> Floppy 1 type : none
> >> HD 0 type : none
> >> HD 1 type : none
> >> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0
> >> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0
> >> DOS base memory: 635 kB
> >> Extended memory: 65535 kB (configured), 65535 kB (tested)
> >> Gfx adapter : EGA, VGA, ... (with BIOS)
> >> FPU : not installed
> >>
> >
> > I really don't think anyone is using that but I don't really know much
> > about x86 and the specification this may be part of.
> >
> > I see the info may be used in drivers/video/fbdev/ and
> > drivers/platform/x86/thinkpad_acpi.c
>
> The thinkpad_acpi driver seems to look at some other bytes
> in the nvram, which have a platform specific meaning.
>
Yeah, I was more concerned that they need drivers/char/nvram.c for
nvram_read_byte so we can't simply remove the driver.
> For drivers/video/fbdev/, these appear to all be for pre-x86
> Apple Macintosh (m68k or powerpc).
>
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii
From: Jonathan Neuschäfer @ 2018-02-07 12:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Neuschäfer, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org list, linux-gpio,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Albert Herranz, Segher Boessenkool
In-Reply-To: <CACRpkdZLiw=e-XiS9cbQuJGJ2tJVV86qKaLCy2yG==FSENhAHw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]
On Wed, Feb 07, 2018 at 01:29:45PM +0100, Linus Walleij wrote:
> On Mon, Jan 22, 2018 at 6:04 AM, Jonathan Neuschäfer
> <j.neuschaefer@gmx.net> wrote:
>
> > The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
> > that supports a configurable number of pins (up to 32), interrupts, and
> > some special mechanisms to share the controller between the system's
> > security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
> > not supported.
> >
> > This patch adds a basic driver for this GPIO controller. Interrupt
> > support will come in a later patch.
> >
> > This patch is based on code developed by Albert Herranz and the GameCube
> > Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> > available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> > has grown quite dissimilar.
> >
> > Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> > Cc: Albert Herranz <albert_herranz@yahoo.es>
> > Cc: Segher Boessenkool <segher@kernel.crashing.org>
> > ---
> >
> > v2:
>
> All looks very good to me, Andy had some additional comments,
> once addressed in v3 I will apply this.
>
> You only need to resend this patch as I already applied the DT
> bindings.
This driver can't be used until the resource mapping problem on PPC32
(see patch 1/6 and the related discussion) is solved or worked around
with out-of-tree patches (such as patch 1/6). Should I send v3 anyway?
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] char: nvram: disable on ARM
From: Arnd Bergmann @ 2018-02-07 14:00 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20180207124839.GX3404@piout.net>
On Wed, Feb 7, 2018 at 1:48 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote:
>> On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
>> >> $ cat /proc/driver/nvram
>> >> Checksum status: valid
>> >> # floppies : 0
>> >> Floppy 0 type : none
>> >> Floppy 1 type : none
>> >> HD 0 type : none
>> >> HD 1 type : none
>> >> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0
>> >> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0
>> >> DOS base memory: 635 kB
>> >> Extended memory: 65535 kB (configured), 65535 kB (tested)
>> >> Gfx adapter : EGA, VGA, ... (with BIOS)
>> >> FPU : not installed
>> >>
>> >
>> > I really don't think anyone is using that but I don't really know much
>> > about x86 and the specification this may be part of.
>> >
>> > I see the info may be used in drivers/video/fbdev/ and
>> > drivers/platform/x86/thinkpad_acpi.c
>>
>> The thinkpad_acpi driver seems to look at some other bytes
>> in the nvram, which have a platform specific meaning.
>>
>
> Yeah, I was more concerned that they need drivers/char/nvram.c for
> nvram_read_byte so we can't simply remove the driver.
Ok, so the procfs interface may be obsolete, but we still need an
interface into the CMOS NVRAM data.
I see that the x86 version of nvram_read_byte is just a wrapper
around CMOS_READ(14 + addr). We also have some drivers
that call the low-level function directly:
arch/x86/include/asm/floppy.h: val = CMOS_READ(0x10) & 15;
arch/x86/kernel/bootflag.c: v = CMOS_READ(sbf_port);
drivers/char/mwave/smapi.c: usSmapiID = CMOS_READ(0x7C);
drivers/input/misc/wistron_btns.c: qlen = CMOS_READ(cmos_address);
I suppose we could make the thinkpad driver do the same,
or provide a 'static inline' version of nvram_read_byte somewhere.
Arnd
^ permalink raw reply
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Horia Geantă @ 2018-02-07 14:39 UTC (permalink / raw)
To: Christophe Leroy, Herbert Xu, David S. Miller
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <e47bf94ae44f23230b1647e31c9623f1075d3b79.1507284818.git.christophe.leroy@c-s.fr>
On 10/6/2017 4:06 PM, Christophe Leroy wrote:=0A=
> At every request, we map and unmap the same hash hw_context.=0A=
> =0A=
> This patch moves the dma mapping/unmapping in functions ahash_init()=0A=
> and ahash_import().=0A=
> =0A=
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>=0A=
> ---=0A=
> drivers/crypto/talitos.c | 80 ++++++++++++++++++++++++++++++++++--------=
------=0A=
> 1 file changed, 57 insertions(+), 23 deletions(-)=0A=
> =0A=
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c=0A=
> index ebfd6d982ed6..d495649d5267 100644=0A=
> --- a/drivers/crypto/talitos.c=0A=
> +++ b/drivers/crypto/talitos.c=0A=
> @@ -819,6 +819,7 @@ struct talitos_ctx {=0A=
> unsigned int keylen;=0A=
> unsigned int enckeylen;=0A=
> unsigned int authkeylen;=0A=
> + dma_addr_t dma_hw_context;=0A=
This doesn't look correct.=0A=
=0A=
talitos_ctx structure is the tfm context.=0A=
dma_hw_context is the IOVA of hw_context, located in talitos_ahash_req_ctx=
=0A=
structure (request context).=0A=
=0A=
If there are multiple requests in flight for the same tfm, dma_hw_context w=
ill=0A=
be overwritten.=0A=
=0A=
dma_hw_context needs to be moved in request context (talitos_ahash_req_ctx =
struct).=0A=
=0A=
Thanks,=0A=
Horia=0A=
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/mm: Flush radix process translations when setting MMU type
From: Laurent Vivier @ 2018-02-07 14:33 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
In-Reply-To: <20180201050944.30332-1-aik@ozlabs.ru>
On 01/02/2018 06:09, Alexey Kardashevskiy wrote:
> Radix guests do normally invalidate process-scoped translations when
> a new pid is allocated but migrated guests do not invalidate these so
> migrated guests crash sometime, especially easy to reproduce with
> migration happening within first 10 seconds after the guest boot start on
> the same machine.
>
> This adds the "Invalidate process-scoped translations" flush to fix
> radix guests migration.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v2:
> * removed PPC_TLBIE_5() from the !(old&PATH_HR) case as it is pointless
> on hash
>
> ---
>
>
> Not so sure that "process-scoped translations" only require flushing
> at pid allocation and migration.
>
> ---
> arch/powerpc/mm/pgtable_64.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
> index c9a623c..d75dd52 100644
> --- a/arch/powerpc/mm/pgtable_64.c
> +++ b/arch/powerpc/mm/pgtable_64.c
> @@ -471,6 +471,8 @@ void mmu_partition_table_set_entry(unsigned int lpid, unsigned long dw0,
> if (old & PATB_HR) {
> asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : :
> "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
> + asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : :
> + "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
> trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1);
> } else {
> asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :
>
This patch fixes for me a VM migration crash on POWER9.
Tested-by: Laurent Vivier <lvivier@redhat.com>
Thanks,
Laurent
^ permalink raw reply
* Re: [PATCH] char: nvram: disable on ARM
From: Alexandre Belloni @ 2018-02-07 15:47 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CAK8P3a2HscUSs-iV_3dp7+htN+LPFK2LnmiZNTKamQZwMSVxMA@mail.gmail.com>
On 07/02/2018 at 15:00:04 +0100, Arnd Bergmann wrote:
> On Wed, Feb 7, 2018 at 1:48 PM, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote:
> >> On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
>
> >> >> $ cat /proc/driver/nvram
> >> >> Checksum status: valid
> >> >> # floppies : 0
> >> >> Floppy 0 type : none
> >> >> Floppy 1 type : none
> >> >> HD 0 type : none
> >> >> HD 1 type : none
> >> >> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0
> >> >> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0
> >> >> DOS base memory: 635 kB
> >> >> Extended memory: 65535 kB (configured), 65535 kB (tested)
> >> >> Gfx adapter : EGA, VGA, ... (with BIOS)
> >> >> FPU : not installed
> >> >>
> >> >
> >> > I really don't think anyone is using that but I don't really know much
> >> > about x86 and the specification this may be part of.
> >> >
> >> > I see the info may be used in drivers/video/fbdev/ and
> >> > drivers/platform/x86/thinkpad_acpi.c
> >>
> >> The thinkpad_acpi driver seems to look at some other bytes
> >> in the nvram, which have a platform specific meaning.
> >>
> >
> > Yeah, I was more concerned that they need drivers/char/nvram.c for
> > nvram_read_byte so we can't simply remove the driver.
>
> Ok, so the procfs interface may be obsolete, but we still need an
> interface into the CMOS NVRAM data.
>
Actually, I just found
https://unix.stackexchange.com/questions/331419/is-dev-nvram-dangerous-to-write-to
So it seems to have real values for some people (even if they are
wrong).
That also points to https://sourceforge.net/projects/nvram-wakeup/ but I
don't think it is necessary. The RTC driver should be able to wakeup an
x86 platform.
All the other uses of /dev/nvram I could find with a simple google
search (i.e. saving and restoring CMOS settings) could just use
/sys/class/rtc/rtc0/device/nvram
> I see that the x86 version of nvram_read_byte is just a wrapper
> around CMOS_READ(14 + addr). We also have some drivers
> that call the low-level function directly:
>
> arch/x86/include/asm/floppy.h: val = CMOS_READ(0x10) & 15;
> arch/x86/kernel/bootflag.c: v = CMOS_READ(sbf_port);
> drivers/char/mwave/smapi.c: usSmapiID = CMOS_READ(0x7C);
> drivers/input/misc/wistron_btns.c: qlen = CMOS_READ(cmos_address);
>
> I suppose we could make the thinkpad driver do the same,
> or provide a 'static inline' version of nvram_read_byte somewhere.
>
I guess we can do that, provided we take rtc_lock before using
CMOS_READ.
Thinking of it, I think this means we don't need the lock for powerpc as
nvram_read_byte doesn't take it. So I guess it is only needed on x86.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7
From: Khalid Aziz @ 2018-02-07 16:04 UTC (permalink / raw)
To: Eric W. Biederman
Cc: davem, dave.hansen, aarcange, akpm, allen.pais, anthony.yznaga,
arnd, babu.moger, benh, bob.picco, bsingharora, corbet,
dan.j.williams, dave.jiang, david.j.aldridge, elena.reshetova,
glx, gregkh, hannes, hillf.zj, hpa, hughd, imbrenda, jack,
jag.raman, jane.chu, jglisse, jroedel, khalid, khandual,
kirill.shutemov, kstewart, ktkhai, liam.merwick, linux-arch,
linux-doc, linux-kernel, linux-mm, linuxppc-dev, linux, me,
mgorman, mgorman, mhocko, mike.kravetz, minchan, mingo, mingo,
mpe, nadav.amit, nagarathnam.muthusamy, nborisov, n-horiguchi,
nick.alcock, nitin.m.gupta, ombredanne, pasha.tatashin, paulus,
pombredanne, punit.agrawal, rob.gardner, ross.zwisler,
shannon.nelson, shli, sparclinux, steven.sistare, tglx,
thomas.tai, tklauser, tom.hromatka, vegard.nossum, vijay.ac.kumar,
willy, x86, zi.yan
In-Reply-To: <87h8qtfdvj.fsf@xmission.com>
On 02/07/2018 12:38 AM, ebiederm@xmission.com wrote:
> Khalid Aziz <khalid.aziz@oracle.com> writes:
>
>> On 02/01/2018 07:29 PM, ebiederm@xmission.com wrote:
>>> Khalid Aziz <khalid.aziz@oracle.com> writes:
>>>
>>>> V11 changes:
>>>> This series is same as v10 and was simply rebased on 4.15 kernel. Can
>>>> mm maintainers please review patches 2, 7, 8 and 9 which are arch
>>>> independent, and include/linux/mm.h and mm/ksm.c changes in patch 10
>>>> and ack these if everything looks good?
>>>
>>> I am a bit puzzled how this differs from the pkey's that other
>>> architectures are implementing to achieve a similar result.
>>>
>>> I am a bit mystified why you don't store the tag in a vma
>>> instead of inventing a new way to store data on page out.
>>
>> Hello Eric,
>>
>> As Steven pointed out, sparc sets tags per cacheline unlike pkey. This results
>> in much finer granularity for tags that pkey and hence requires larger tag
>> storage than what we can do in a vma.
>
> *Nod* I am a bit mystified where you keep the information in memory.
> I would think the tags would need to be stored per cacheline or per
> tlb entry, in some kind of cache that could overflow. So I would be
> surprised if swapping is the only time this information needs stored
> in memory. Which makes me wonder if you have the proper data
> structures.
>
> I would think an array per vma or something in the page tables would
> tend to make sense.
>
> But perhaps I am missing something.
The ADI tags are stored in spare bits in the RAM. ADI tag storage is
managed entirely by memory controller which maintains these tags per ADI
block. An ADI block is the same size as cacheline on M7. Tags for each
ADI block are associated with the physical ADI block, not the virtual
address. When a physical page is reused, the physical ADI tag storage
for that page is overwritten with new ADI tags, hence we need to store
away the tags when we swap out a page. Kernel updates the ADI tags for
physical page when it swaps a new page in. Each vma can cover variable
number of pages so it is best to store a pointer to the tag storage in
vma as opposed to actual tags in an array. Each 8K page can have 128
tags on it. Since each tag is 4 bits, we need 64 bytes per page to store
the tags. That can add up for a large vma.
>
>>> Can you please use force_sig_fault to send these signals instead
>>> of force_sig_info. Emperically I have found that it is very
>>> error prone to generate siginfo's by hand, especially on code
>>> paths where several different si_codes may apply. So it helps
>>> to go through a helper function to ensure the fiddly bits are
>>> all correct. AKA the unused bits all need to be set to zero before
>>> struct siginfo is copied to userspace.
>>>
>>
>> What you say makes sense. I followed the same code as other fault handlers for
>> sparc. I could change just the fault handlers for ADI related faults. Would it
>> make more sense to change all the fault handlers in a separate patch and keep
>> the code in arch/sparc/kernel/traps_64.c consistent? Dave M, do you have a
>> preference?
>
> It is my intention post -rc1 to start sending out patches to get the
> rest of not just sparc but all of the architectures using the new
> helpers. I have the code I just ran out of time befor the merge
> window opened to ensure everything had a good thorough review.
>
> So if you can handle the your new changes I expect I will handle the
> rest.
>
I can add a patch at the end of my series to update all force_sig_info()
in my patchset to force_sig_fault(). That will sync my patches up with
your changes cleanly. Does that work for you? I can send an updated
series with this change. Can you review and ack the patches after this
change.
Thanks,
Khalid
^ permalink raw reply
* Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7
From: Eric W. Biederman @ 2018-02-07 17:42 UTC (permalink / raw)
To: Khalid Aziz
Cc: davem, dave.hansen, aarcange, akpm, allen.pais, anthony.yznaga,
arnd, babu.moger, benh, bob.picco, bsingharora, corbet,
dan.j.williams, dave.jiang, david.j.aldridge, elena.reshetova,
glx, gregkh, hannes, hillf.zj, hpa, hughd, imbrenda, jack,
jag.raman, jane.chu, jglisse, jroedel, khalid, khandual,
kirill.shutemov, kstewart, ktkhai, liam.merwick, linux-arch,
linux-doc, linux-kernel, linux-mm, linuxppc-dev, linux, me,
mgorman, mgorman, mhocko, mike.kravetz, minchan, mingo, mingo,
mpe, nadav.amit, nagarathnam.muthusamy, nborisov, n-horiguchi,
nick.alcock, nitin.m.gupta, ombredanne, pasha.tatashin, paulus,
pombredanne, punit.agrawal, rob.gardner, ross.zwisler,
shannon.nelson, shli, sparclinux, steven.sistare, tglx,
thomas.tai, tklauser, tom.hromatka, vegard.nossum, vijay.ac.kumar,
willy, x86, zi.yan
In-Reply-To: <c50c053f-1ee7-81f9-99bb-e5f6fe6bb43e@oracle.com>
Khalid Aziz <khalid.aziz@oracle.com> writes:
> On 02/07/2018 12:38 AM, ebiederm@xmission.com wrote:
>> Khalid Aziz <khalid.aziz@oracle.com> writes:
>>
>>> On 02/01/2018 07:29 PM, ebiederm@xmission.com wrote:
>>>> Khalid Aziz <khalid.aziz@oracle.com> writes:
>>>>
>>>>> V11 changes:
>>>>> This series is same as v10 and was simply rebased on 4.15 kernel. Can
>>>>> mm maintainers please review patches 2, 7, 8 and 9 which are arch
>>>>> independent, and include/linux/mm.h and mm/ksm.c changes in patch 10
>>>>> and ack these if everything looks good?
>>>>
>>>> I am a bit puzzled how this differs from the pkey's that other
>>>> architectures are implementing to achieve a similar result.
>>>>
>>>> I am a bit mystified why you don't store the tag in a vma
>>>> instead of inventing a new way to store data on page out.
>>>
>>> Hello Eric,
>>>
>>> As Steven pointed out, sparc sets tags per cacheline unlike pkey. This results
>>> in much finer granularity for tags that pkey and hence requires larger tag
>>> storage than what we can do in a vma.
>>
>> *Nod* I am a bit mystified where you keep the information in memory.
>> I would think the tags would need to be stored per cacheline or per
>> tlb entry, in some kind of cache that could overflow. So I would be
>> surprised if swapping is the only time this information needs stored
>> in memory. Which makes me wonder if you have the proper data
>> structures.
>>
>> I would think an array per vma or something in the page tables would
>> tend to make sense.
>>
>> But perhaps I am missing something.
>
> The ADI tags are stored in spare bits in the RAM. ADI tag storage is
> managed entirely by memory controller which maintains these tags per
> ADI block. An ADI block is the same size as cacheline on M7. Tags for
> each ADI block are associated with the physical ADI block, not the
> virtual address. When a physical page is reused, the physical ADI tag
> storage for that page is overwritten with new ADI tags, hence we need
> to store away the tags when we swap out a page. Kernel updates the ADI
> tags for physical page when it swaps a new page in. Each vma can cover
> variable number of pages so it is best to store a pointer to the tag
> storage in vma as opposed to actual tags in an array. Each 8K page can
> have 128 tags on it. Since each tag is 4 bits, we need 64 bytes per
> page to store the tags. That can add up for a large vma.
If the tags are already stored in RAM I can see why it does not make any
sense to store them except on page out. Management wise this feels a
lot like the encrypted memory options I have been seeing on x86.
>>>> Can you please use force_sig_fault to send these signals instead
>>>> of force_sig_info. Emperically I have found that it is very
>>>> error prone to generate siginfo's by hand, especially on code
>>>> paths where several different si_codes may apply. So it helps
>>>> to go through a helper function to ensure the fiddly bits are
>>>> all correct. AKA the unused bits all need to be set to zero before
>>>> struct siginfo is copied to userspace.
>>>>
>>>
>>> What you say makes sense. I followed the same code as other fault handlers for
>>> sparc. I could change just the fault handlers for ADI related faults. Would it
>>> make more sense to change all the fault handlers in a separate patch and keep
>>> the code in arch/sparc/kernel/traps_64.c consistent? Dave M, do you have a
>>> preference?
>>
>> It is my intention post -rc1 to start sending out patches to get the
>> rest of not just sparc but all of the architectures using the new
>> helpers. I have the code I just ran out of time befor the merge
>> window opened to ensure everything had a good thorough review.
>>
>> So if you can handle the your new changes I expect I will handle the
>> rest.
>>
>
> I can add a patch at the end of my series to update all
> force_sig_info() in my patchset to force_sig_fault(). That will sync
> my patches up with your changes cleanly. Does that work for you? I can
> send an updated series with this change. Can you review and ack the
> patches after this change.
One additional patch would be fine. I can certainly review and ack that
part. You probably want to wait until post -rc1 so that you have a
clean base to work off of.
Eric
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/mm: Flush radix process translations when setting MMU type
From: Daniel Henrique Barboza @ 2018-02-07 17:49 UTC (permalink / raw)
To: Laurent Vivier, Alexey Kardashevskiy, linuxppc-dev
In-Reply-To: <fb14f2b5-03a3-c20b-b729-643d6a79504a@redhat.com>
On 02/07/2018 12:33 PM, Laurent Vivier wrote:
> On 01/02/2018 06:09, Alexey Kardashevskiy wrote:
>> Radix guests do normally invalidate process-scoped translations when
>> a new pid is allocated but migrated guests do not invalidate these so
>> migrated guests crash sometime, especially easy to reproduce with
>> migration happening within first 10 seconds after the guest boot start on
>> the same machine.
>>
>> This adds the "Invalidate process-scoped translations" flush to fix
>> radix guests migration.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * removed PPC_TLBIE_5() from the !(old&PATH_HR) case as it is pointless
>> on hash
>>
>> ---
>>
>>
>> Not so sure that "process-scoped translations" only require flushing
>> at pid allocation and migration.
>>
>> ---
>> arch/powerpc/mm/pgtable_64.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
>> index c9a623c..d75dd52 100644
>> --- a/arch/powerpc/mm/pgtable_64.c
>> +++ b/arch/powerpc/mm/pgtable_64.c
>> @@ -471,6 +471,8 @@ void mmu_partition_table_set_entry(unsigned int lpid, unsigned long dw0,
>> if (old & PATB_HR) {
>> asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : :
>> "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
>> + asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : :
>> + "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
>> trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1);
>> } else {
>> asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :
>>
> This patch fixes for me a VM migration crash on POWER9.
Same here.
Tested-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
>
> Tested-by: Laurent Vivier <lvivier@redhat.com>
>
> Thanks,
> Laurent
>
^ permalink raw reply
* Re: [PATCH] char: nvram: disable on ARM
From: Alexandre Belloni @ 2018-02-07 18:46 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20180207154700.GY3404@piout.net>
On 07/02/2018 at 16:47:00 +0100, Alexandre Belloni wrote:
> > >> > I really don't think anyone is using that but I don't really know much
> > >> > about x86 and the specification this may be part of.
> > >> >
> > >> > I see the info may be used in drivers/video/fbdev/ and
> > >> > drivers/platform/x86/thinkpad_acpi.c
> > >>
> > >> The thinkpad_acpi driver seems to look at some other bytes
> > >> in the nvram, which have a platform specific meaning.
> > >>
> > >
> > > Yeah, I was more concerned that they need drivers/char/nvram.c for
> > > nvram_read_byte so we can't simply remove the driver.
> >
> > Ok, so the procfs interface may be obsolete, but we still need an
> > interface into the CMOS NVRAM data.
> >
>
> Actually, I just found
> https://unix.stackexchange.com/questions/331419/is-dev-nvram-dangerous-to-write-to
>
> So it seems to have real values for some people (even if they are
> wrong).
>
> That also points to https://sourceforge.net/projects/nvram-wakeup/ but I
> don't think it is necessary. The RTC driver should be able to wakeup an
> x86 platform.
>
> All the other uses of /dev/nvram I could find with a simple google
> search (i.e. saving and restoring CMOS settings) could just use
> /sys/class/rtc/rtc0/device/nvram
>
Ok, the chromeos guys are using it for verified boot it seems:
https://chromium.googlesource.com/chromiumos/platform/vboot_reference
I'm wondering whether they really care about the checksum though.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* [PATCH] powerpc/via-pmu: Fix section mismatch warning
From: Mathieu Malaterre @ 2018-02-07 19:44 UTC (permalink / raw)
To: Michael Ellerman
Cc: Mathieu Malaterre, Benjamin Herrenschmidt, linuxppc-dev,
linux-kernel
Remove the __init annotation from pmu_init() to avoid the
following warning.
WARNING: vmlinux.o(.data+0x4739c): Section mismatch in reference from the variable via_pmu_driver to the function .init.text:pmu_init()
The variable via_pmu_driver references
the function __init pmu_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 08849e33c567..5f378272d5b2 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -378,7 +378,7 @@ static int pmu_probe(void)
return vias == NULL? -ENODEV: 0;
}
-static int __init pmu_init(void)
+static int pmu_init(void)
{
if (vias == NULL)
return -ENODEV;
--
2.11.0
^ permalink raw reply related
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: mad skateman @ 2018-02-07 21:00 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Madalin-cristian Bucur, Andrew Lunn,
linuxppc-dev@lists.ozlabs.org, Jamie Krueger
In-Reply-To: <1d62c827-0ff7-0372-a2f8-f1930e9f788c@xenosoft.de>
[-- Attachment #1: Type: text/plain, Size: 4878 bytes --]
Hi,
I just found out that something goes wrong within the ARP table (well thats
what i think). I hope someone has a clue..
When i bootup the AmigaOne X5000 with the Ethernet cable connected, it just
never senses the presence of the UTP cable.
I must run the following command as root: mii-tool -R eth0 ... it Resets
the transceiver and the ethernet connection is ready to go.
But then... it randomly dies....
After some digging i found that in a working situation the ARP table is
filled with the correct info. Router address, and corresponding MAC, C mask
and Interface.
(Working)
skateman@X5000LNX:~$ arp -n
Address HWtype HWaddress Flags Mask
Iface
192.168.22.66 ether 08:5b:0e:fd:db:6a C
eth0
No more traffic..it just suddenly dies...
skateman@X5000LNX:~$ ping www.google.com
ping: unknown host www.google.com
Rechecked the ARP... and found out it has lost the necessary info.
skateman@X5000LNX:~$ arp -n
Address HWtype HWaddress Flags Mask
Iface
192.168.22.66 (incomplete)
eth0
Anyone??? :-)
On Tue, Feb 6, 2018 at 12:20 PM, Christian Zigotzky <chzigotzky@xenosoft.de>
wrote:
> Hello,
>
> I have tried to figure out why there is a problem with the buffer space
> but unfortunately without any success. Any ideas? Could you please watch
> Skateman's video? [1]
>
> Thanks,
> Christian
>
> [1] https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
>
>
> On 03 February 2018 at 12:54PM, mad skateman wrote:
> >
> > For those interested... i have recorded a video of my X5000 DPAA
> Ethernet, and the weird problems..
> > In this Video i am also transfering hundereds of megabytes from my NAS
> to the X5000.
> > You will also see pings die... mostly after the 12th packet and giving
> the no buffer space error..
> > Hopefully someone might have a clue about what is happening.
> >
> > https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
> >
> > On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur <
> madalin.bucur@nxp.com> wrote:
> >
> > > -----Original Message-----
> > > From: Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:25 PM
> > > To: David S . Miller <davem@davemloft.net>
> > > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > > madskateman@gmail.com; 'Madalin-cristian Bucur' <
> madalin.bucur@nxp.com>;
> > > Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > > <Joakim.Tjernlund@infinera.com>
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > -----Original Message-----
> > > > From: netdev-owner@vger.kernel.org [mailto:
> netdev-owner@vger.kernel.org]
> > > > On Behalf Of Madalin-cristian Bucur
> > > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > > To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > > > <Joakim.Tjernlund@infinera.com>
> > > > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > > > madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> > > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > > >
> > > > > > That doesn't work really, having users to hit the bug, debug
> it, fix
> > > > it
> > > > > and then
> > > > > > find it fixed already in upstream, then specifically request
> it to
> > > be
> > > > > backported to stable.
> > > > > > I don't need this fix to be backported, already got it.
> Someone else
> > > > > might though.
> > > > >
> > > > > The "someone else might though" is a big point of asking for
> it to
> > > > > added to stable. The other reason is it means one less patch
> you need
> > > > > to maintain in your build.
> > > >
> > > > I've sent that patch [1] for net but I guess the timing was
> wrong and
> > > > it was merged to net-next.
> > > >
> > > > > > I would be interested in bug fixes upstream which fixes:
> > > > >
> > > > > Did you try upstream? Does it give the same errors?
> > > > >
> > > > > Andrew
> > > >
> > > > [1] https://patchwork.kernel.org/patch/10146119/
> > > >
> > > > Madalin
> > >
> > > Hi Dave,
> > >
> > > Can you please add the fix [1] to stable?
> > >
> > > Thank you,
> > > Madalin
> >
> > Sorry,
> >
> > I've provided the wrong link towards the patch (v1 instead of v3),
> > here's the correct one:
> >
> > https://patchwork.kernel.org/patch/10151969/
> >
> > Madalin
> >
> >
>
>
>
[-- Attachment #2: Type: text/html, Size: 8454 bytes --]
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Andrew Lunn @ 2018-02-07 21:17 UTC (permalink / raw)
To: mad skateman
Cc: Christian Zigotzky, Madalin-cristian Bucur,
linuxppc-dev@lists.ozlabs.org, Jamie Krueger
In-Reply-To: <CAHkrCmGrp3eUKYqRpv4__qw24yvL3Fou+MNwaDCX=XGgmFqRRg@mail.gmail.com>
On Wed, Feb 07, 2018 at 10:00:45PM +0100, mad skateman wrote:
> Hi,
>
> I just found out that something goes wrong within the ARP table (well thats
> what i think). I hope someone has a clue..
This looks like 'normal' behaviour. It has been reported that the
device runs out of buffers. That means it will fail to receive ARP
replies. So the ARP entry will time out and be removed, as it should.
Fix the buffer problem, and ARP will likely work properly.
Andrew
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Christian Zigotzky @ 2018-02-07 22:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: mad skateman, Madalin-cristian Bucur,
linuxppc-dev@lists.ozlabs.org, Jamie Krueger
In-Reply-To: <20180207211725.GA27167@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
Hi Andrew,
How can we fix the buffer problem?
Thanks,
Christian
On 7. Feb 2018, at 22:17, Andrew Lunn <andrew@lunn.ch> wrote:
On Wed, Feb 07, 2018 at 10:00:45PM +0100, mad skateman wrote:
Hi,
I just found out that something goes wrong within the ARP table (well thats
what i think). I hope someone has a clue..
——————
This looks like 'normal' behaviour. It has been reported that the
device runs out of buffers. That means it will fail to receive ARP
replies. So the ARP entry will time out and be removed, as it should.
Fix the buffer problem, and ARP will likely work properly.
Andrew
[-- Attachment #2: Type: text/html, Size: 4964 bytes --]
^ permalink raw reply
* [RFC] powerpc/hotplug/drcinfo: Fix bugs parsing ibm,drc-info structs
From: Michael Bringmann @ 2018-02-07 22:22 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Bringmann, Nathan Fontenot, Michael Ellerman, John Allen,
Tyrel Datwyler, Thomas Falcon
[Replace/withdraw previous patch submission to ensure that testing
of related patches on similar hardware progresses together.
Request comments about current state.]
This patch fixes a memory parsing bug when using of_prop_next_u32
calls at the start of a structure. Depending upon the value of
"cur" memory pointer argument to of_prop_next_u32, it will or it
won't advance the value of the returned memory pointer by the
size of one u32. This patch corrects the code to deal with that
indexing feature when parsing the ibm,drc-info structs for CPUs.
Also, need to advance the pointer at the end of_read_drc_info_cell
for same reason.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Fixes: 3f38000eda48 ("powerpc/firmware: Add definitions for new drc-info firmware feature" -- end of patch series applied to powerpc next)
---
arch/powerpc/platforms/pseries/of_helpers.c | 4 +---
arch/powerpc/platforms/pseries/pseries_energy.c | 2 ++
drivers/pci/hotplug/rpaphp_core.c | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/of_helpers.c b/arch/powerpc/platforms/pseries/of_helpers.c
index 6df192f..17b5938 100644
--- a/arch/powerpc/platforms/pseries/of_helpers.c
+++ b/arch/powerpc/platforms/pseries/of_helpers.c
@@ -65,9 +65,7 @@ int of_read_drc_info_cell(struct property **prop, const __be32 **curval,
/* Get drc-index-start:encode-int */
p2 = (const __be32 *)p;
- p2 = of_prop_next_u32(*prop, p2, &data->drc_index_start);
- if (!p2)
- return -EINVAL;
+ data->drc_index_start = of_read_number(p2, 1);
/* Get drc-name-suffix-start:encode-int */
p2 = of_prop_next_u32(*prop, p2, &data->drc_name_suffix_start);
diff --git a/arch/powerpc/platforms/pseries/pseries_energy.c b/arch/powerpc/platforms/pseries/pseries_energy.c
index 6ed2212..c7d84aa 100644
--- a/arch/powerpc/platforms/pseries/pseries_energy.c
+++ b/arch/powerpc/platforms/pseries/pseries_energy.c
@@ -64,6 +64,7 @@ static u32 cpu_to_drc_index(int cpu)
value = of_prop_next_u32(info, NULL, &num_set_entries);
if (!value)
goto err_of_node_put;
+ value++;
for (j = 0; j < num_set_entries; j++) {
@@ -126,6 +127,7 @@ static int drc_index_to_cpu(u32 drc_index)
value = of_prop_next_u32(info, NULL, &num_set_entries);
if (!value)
goto err_of_node_put;
+ value++;
for (j = 0; j < num_set_entries; j++) {
diff --git a/drivers/pci/hotplug/rpaphp_core.c b/drivers/pci/hotplug/rpaphp_core.c
index 53902c7..477a21c 100644
--- a/drivers/pci/hotplug/rpaphp_core.c
+++ b/drivers/pci/hotplug/rpaphp_core.c
@@ -253,6 +253,7 @@ static int rpaphp_check_drc_props_v2(struct device_node *dn, char *drc_name,
value = of_prop_next_u32(info, NULL, &entries);
if (!value)
return -EINVAL;
+ value++;
for (j = 0; j < entries; j++) {
of_read_drc_info_cell(&info, &value, &drc);
^ permalink raw reply related
* [RFC] powerpc/kernel: Add 'ibm,thread-groups' property for CPU allocation
From: Michael Bringmann @ 2018-02-07 22:23 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Bringmann, Nathan Fontenot, Michael Ellerman, John Allen,
Tyrel Datwyler, Thomas Falcon
[Withdraw/replace previous version submission. Awaiting hardware
for further migration tests. Request comments about current state.]
Add code to parse the new property 'ibm,thread-groups" when it is
present. The content of this property explicitly defines the number
of threads per core as well as the PowerPC 'threads_core_mask'.
The design provides a common device-tree for both P9 normal core and
P9 fused core systems. The new property has been observed to be
available on P9 pHyp systems, but it may not be present on OpenPower
BMC systems.
The property updates the kernel to know which CPUs/threads of each
core are actually present, and then use the map when adding cores
to the system at boot, or during hotplug operations.
* Previously, the information about the number of threads per core
was inferred solely from the "ibm,ppc-interrupt-server#s" property
in the system device tree.
* Also previous to this property, The mask of threads per CPU was
inferred to be a strict linear series from 0..(nthreads-1).
* There may be a different thread group mask for each core in the
system.
* Also after reading the property, we can determine which of the
possible threads we are allowed to online for each CPU. It is no
longer a simple linear sequence, but may be discontinuous e.g.
activate threads 1,2,3,5,6,7 on a core instead of 0-5 sequentially.
In the event of LPAR migration, we also provide a hook to re-process
the property in the event that it is changed. Rules about fused-core
and split-core migration are outside the scope of this change, however.
We update the 'ppc_thread_group_mask' for subsequent use by DLPAR
operations. It is the responsibility of the user to put the source
system into SMT4 mode when moving from a fused-core to split-core
target.
Implementation of the "ibm,thread-groups" property is spread across
a few files in the powerpc specific code:
* prom.c: Parse the property and create 'ppc_thread_group_mask'.
Use the mask in operation of early_init_dt_scan_cpus().
* setup-common.c: Parse the property, create 'ppc_thread_group_mask',
and use the value in cpu_init_thread_core_maps(), and
smp_setup_cpu_maps.
* hotplug-cpu.c: Use 'ppc_thread_group_mask' in several locations
where the code previously expected to iterate over a
linear series of active threads (0..nthreads-1).
* mobility.c: Look for and process changes to the thread group mask
in the context of post migration topology changes
Note that the "ibm,thread-groups" property also includes semantics
of 'thread-group' i.e. define one or more subgroups of the available
threads, each group of threads to be used for a specific class of
task. Translating thread group semantics into Linux kernel features
is TBD.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
---
Changes in V3:
-- Update patch description regarding latest changes.
-- Move parsing of new property to 'setup-common.c' in new function
'process_thread_group_masks'.
-- Ensure that code is able to handle unique thread group masks
for different cpus.
-- Add post migration topology check for 'ibm,thread-groups' using
new function process_thread_group_mask when appropriate.
-- Tune use of ppc_thread_group_mask during DLPAR operations.
Use new function process_thread_group_mask when appropriate.
-- Add some more description of property semantics/operation in
the case of LPAR migration.
---
arch/powerpc/include/asm/cputhreads.h | 6 +
arch/powerpc/kernel/setup-common.c | 136 ++++++++++++++++++++++++--
arch/powerpc/platforms/pseries/hotplug-cpu.c | 14 ++-
arch/powerpc/platforms/pseries/mobility.c | 6 +
4 files changed, 150 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/cputhreads.h b/arch/powerpc/include/asm/cputhreads.h
index d71a909..df6ade9 100644
--- a/arch/powerpc/include/asm/cputhreads.h
+++ b/arch/powerpc/include/asm/cputhreads.h
@@ -31,6 +31,12 @@
#define threads_core_mask (*get_cpu_mask(0))
#endif
+extern cpumask_t ppc_thread_group_mask;
+
+extern int process_thread_group_mask(struct device_node *dn,
+ const __be32 *prop, int prop_len);
+
+
/* cpu_thread_mask_to_cores - Return a cpumask of one per cores
* hit by the argument
*
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 8fd3a70..1102d12 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -416,13 +416,18 @@ void __init check_for_initrd(void)
EXPORT_SYMBOL_GPL(threads_shift);
EXPORT_SYMBOL_GPL(threads_core_mask);
-static void __init cpu_init_thread_core_maps(int tpc)
+cpumask_t ppc_thread_group_mask;
+EXPORT_SYMBOL_GPL(ppc_thread_group_mask);
+
+static void __init cpu_init_thread_core_maps(int tpc,
+ cpumask_t *thread_group_mask)
{
int i;
threads_per_core = tpc;
threads_per_subcore = tpc;
cpumask_clear(&threads_core_mask);
+ DBG("INFO: Entry %s (%d)\n", __FUNCTION__, tpc);
/* This implementation only supports power of 2 number of threads
* for simplicity and performance
@@ -432,12 +437,112 @@ static void __init cpu_init_thread_core_maps(int tpc)
for (i = 0; i < tpc; i++)
cpumask_set_cpu(i, &threads_core_mask);
+ cpumask_and(&threads_core_mask, &threads_core_mask, thread_group_mask);
printk(KERN_INFO "CPU maps initialized for %d thread%s per core\n",
tpc, tpc > 1 ? "s" : "");
printk(KERN_DEBUG " (thread shift is %d)\n", threads_shift);
}
+int process_thread_group_mask(struct device_node *dn,
+ const __be32 *prop, int prop_len)
+{
+ const __be32 *thrgrp;
+ const __be32 *intserv;
+ int lentg, len, cpu, nthreads = 1;
+ int j, k, rc = 0;
+ u32 cc_type = 0, no_split = 0, thr_per_split = 0;
+ DBG("INFO: Entry %s\n", __FUNCTION__);
+
+ /* First CPU/thread */
+ intserv = of_get_property(dn, "reg", &len);
+ if (intserv)
+ cpu = of_read_number(intserv, 1);
+ else
+ cpu = 0;
+
+ /* Num of threads in core */
+ intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s",
+ &len);
+ if (intserv) {
+ DBG(" ibm,ppc-interrupt-server#s -> %d threads\n",
+ nthreads);
+ } else {
+ DBG(" no ibm,ppc-interrupt-server#s -> 1 thread\n");
+ len = 4;
+ }
+
+ nthreads = len / sizeof(int);
+ DBG(" cpu %d nthreads %d\n", cpu, nthreads);
+
+ if (prop) {
+ thrgrp = prop;
+ } else {
+ thrgrp = of_get_property(dn, "ibm,thread-groups",
+ &lentg);
+ if (!thrgrp) {
+ rc = -ENOENT;
+ DBG(" error, %d\n", __LINE__);
+ goto endit;
+ }
+ }
+
+ /* Process the thread groups for the Core thread mask */
+ /* Characteristic type per table */
+ cc_type = of_read_number(thrgrp++, 1);
+
+ /*
+ * 1 : Group shares common L1, translation cache, and
+ * instruction data flow
+ * >1 : Reserved
+ */
+ if (cc_type != 1) {
+ rc = -EINVAL;
+ DBG(" error, %d\n", __LINE__);
+ goto endit;
+ }
+
+ /* No. splits */
+ no_split = of_read_number(thrgrp++, 1);
+ if (no_split == 0) {
+ rc = -EINVAL;
+ DBG(" error, %d\n", __LINE__);
+ goto endit;
+ }
+
+ /* Threads per split */
+ thr_per_split = of_read_number(thrgrp++, 1);
+ if (thr_per_split == 0) {
+ rc = -EINVAL;
+ DBG(" error, %d\n", __LINE__);
+ goto endit;
+ }
+
+ DBG(" Property ibm,thread-group "
+ "(cc_t=%d, no_spl=%d, thr_p_spl=%d)\n",
+ (int)cc_type, (int)no_split, (int)thr_per_split);
+
+ for (j = 0; j < no_split; j++) {
+ for (k = 0; k < thr_per_split; k++) {
+ u32 t = of_read_number(thrgrp++, 1);
+
+ cpumask_set_cpu(t, &ppc_thread_group_mask);
+ DBG(" !!enable thread %d\n", (int)t);
+ }
+ }
+
+endit:
+ if (rc) {
+ DBG(" WARNING: error processing (%d)"
+ "ibm,thread-group property\n", rc);
+ for (j = 0; j < nthreads; j++)
+ cpumask_set_cpu(cpu+j,
+ &ppc_thread_group_mask);
+ }
+
+ return rc;
+}
+EXPORT_SYMBOL(process_thread_group_mask);
/**
* setup_cpu_maps - initialize the following cpu maps:
@@ -489,20 +594,35 @@ void __init smp_setup_cpu_maps(void)
nthreads = len / sizeof(int);
+ process_thread_group_mask(dn, NULL, 0);
+
for (j = 0; j < nthreads && cpu < nr_cpu_ids; j++) {
bool avail;
- DBG(" thread %d -> cpu %d (hard id %d)\n",
- j, cpu, be32_to_cpu(intserv[j]));
-
avail = of_device_is_available(dn);
if (!avail)
avail = !of_property_match_string(dn,
"enable-method", "spin-table");
- set_cpu_present(cpu, avail);
- set_hard_smp_processor_id(cpu, be32_to_cpu(intserv[j]));
- set_cpu_possible(cpu, true);
+ DBG(" thread %d -> cpu %d (hard id %d) %d\n",
+ j, cpu, be32_to_cpu(intserv[j]),
+ cpumask_test_cpu(cpu, &ppc_thread_group_mask));
+
+ if (cpumask_test_cpu(cpu,
+ &ppc_thread_group_mask)) {
+ DBG(" !!thread %d present"
+ "/possible\n", (int)cpu);
+ set_cpu_present(cpu, avail);
+ set_hard_smp_processor_id(cpu,
+ be32_to_cpu(intserv[j]));
+ set_cpu_possible(cpu, true);
+ } else {
+ DBG(" !!NOT thread %d "
+ "present/possible\n", (int)cpu);
+ set_cpu_present(cpu, false);
+ set_cpu_possible(cpu, false);
+ }
+
cpu++;
}
}
@@ -561,7 +681,7 @@ void __init smp_setup_cpu_maps(void)
* every CPU in the system. If that is not the case, then some code
* here will have to be reworked
*/
- cpu_init_thread_core_maps(nthreads);
+ cpu_init_thread_core_maps(nthreads, &ppc_thread_group_mask);
/* Now that possible cpus are set, set nr_cpu_ids for later use */
setup_nr_cpu_ids();
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index a7d14aa7..106d0fe 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -36,6 +36,7 @@
#include <asm/xics.h>
#include <asm/xive.h>
#include <asm/plpar_wrappers.h>
+#include <asm/cputhreads.h>
#include "pseries.h"
#include "offline_states.h"
@@ -254,6 +255,8 @@ static int pseries_add_processor(struct device_node *np)
if (!intserv)
return 0;
+ process_thread_group_mask(np, NULL, 0);
+
zalloc_cpumask_var(&candidate_mask, GFP_KERNEL);
zalloc_cpumask_var(&tmp, GFP_KERNEL);
@@ -325,6 +328,7 @@ static void pseries_remove_processor(struct device_node *np)
cpu_maps_update_begin();
for (i = 0; i < nthreads; i++) {
thread = be32_to_cpu(intserv[i]);
+ cpumask_clear_cpu(thread, &ppc_thread_group_mask);
for_each_present_cpu(cpu) {
if (get_hard_smp_processor_id(cpu) != thread)
continue;
@@ -363,10 +367,12 @@ static int dlpar_online_cpu(struct device_node *dn)
BUG_ON(get_cpu_current_state(cpu)
!= CPU_STATE_OFFLINE);
cpu_maps_update_done();
- timed_topology_update(1);
- rc = device_online(get_cpu_device(cpu));
- if (rc)
- goto out;
+ if (cpumask_test_cpu(thread, &ppc_thread_group_mask)) {
+ timed_topology_update(1);
+ rc = device_online(get_cpu_device(cpu));
+ if (rc)
+ goto out;
+ }
cpu_maps_update_begin();
break;
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index f7042ad..0816ccf 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -20,6 +20,7 @@
#include <asm/machdep.h>
#include <asm/rtas.h>
+#include <asm/cputhreads.h>
#include "pseries.h"
static struct kobject *mobility_kobj;
@@ -121,6 +122,11 @@ static int update_dt_property(struct device_node *dn, struct property **prop,
}
if (!more) {
+ printk(KERN_INFO "INFO: Processing %s %s\n", __FUNCTION__, name);
+ if (strcmp(name, "ibm,thread-groups") == 0)
+ process_thread_group_mask(dn,
+ new_prop->value, new_prop->length);
+
of_update_property(dn, new_prop);
*prop = NULL;
}
^ permalink raw reply related
* [PATCH kernel] powerpc/pci: Fix broken INTx configuration via OF
From: Alexey Kardashevskiy @ 2018-02-08 5:33 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Benjamin Herrenschmidt, Bjorn Helgaas,
Michael Ellerman, Paul Mackerras, Rob Herring, Alistair Popple
Commit 59f47eff03a0 ("powerpc/pci: Use of_irq_parse_and_map_pci() helper")
correctly states that of_irq_parse_and_map_pci() does the same thing as
of_irq_parse_pci() does as it simply calls
of_irq_parse_pci() and irq_create_of_mapping().
However of_irq_parse_and_map_pci() not only returns 0 for success and
negative value for an error but also a positive virq value from
irq_create_of_mapping() which the mentioned commit ignores and
INTx config fails.
This fixes the of_irq_parse_and_map_pci() return value handling.
Fixes: 59f47eff03a0 "powerpc/pci: Use of_irq_parse_and_map_pci() helper"
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Found it on POWER9 + powernv system - almost all devices suddenly lost
INTx support.
---
arch/powerpc/kernel/pci-common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index ae2ede4..acbb44f2 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -370,7 +370,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
memset(&oirq, 0xff, sizeof(oirq));
#endif
/* Try to get a mapping from the device-tree */
- if (!of_irq_parse_and_map_pci(pci_dev, 0, 0)) {
+ virq = of_irq_parse_and_map_pci(pci_dev, 0, 0);
+ if (virq <= 0) {
u8 line, pin;
/* If that fails, lets fallback to what is in the config
--
2.11.0
^ permalink raw reply related
* Re: [bug report] powerpc/perf: Add nest IMC PMU support
From: Anju T Sudhakar @ 2018-02-08 6:31 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linuxppc-dev
In-Reply-To: <20180131152527.GA19851@mwanda>
Hi Dan Carpenter,
On Wednesday 31 January 2018 08:55 PM, Dan Carpenter wrote:
> Hello Anju T Sudhakar,
>
> The patch 885dcd709ba9: "powerpc/perf: Add nest IMC PMU support" from
> Jul 19, 2017, leads to the following static checker warning:
>
> arch/powerpc/perf/imc-pmu.c:1393 init_imc_pmu()
> warn: 'pmu_ptr' was already freed.
>
> arch/powerpc/perf/imc-pmu.c
> 1317 int init_imc_pmu(struct device_node *parent, struct imc_pmu *pmu_ptr, int pmu_idx)
> 1318 {
> 1319 int ret;
> 1320
> 1321 ret = imc_mem_init(pmu_ptr, parent, pmu_idx);
> 1322 if (ret) {
> 1323 imc_common_mem_free(pmu_ptr);
> 1324 return ret;
> 1325 }
>
> Change this to:
>
> if (ret)
> goto err_free_mpu_ptr;
>
> Or something instead of a direct return. That's more normal kernel
> style.
>
> 1326
> 1327 switch (pmu_ptr->domain) {
> 1328 case IMC_DOMAIN_NEST:
> 1329 /*
> 1330 * Nest imc pmu need only one cpu per chip, we initialize the
> 1331 * cpumask for the first nest imc pmu and use the same for the
> 1332 * rest. To handle the cpuhotplug callback unregister, we track
> 1333 * the number of nest pmus in "nest_pmus".
> 1334 */
> 1335 mutex_lock(&nest_init_lock);
> 1336 if (nest_pmus == 0) {
> 1337 ret = init_nest_pmu_ref();
> 1338 if (ret) {
> 1339 mutex_unlock(&nest_init_lock);
> 1340 goto err_free;
> 1341 }
> 1342 /* Register for cpu hotplug notification. */
> 1343 ret = nest_pmu_cpumask_init();
> 1344 if (ret) {
> 1345 mutex_unlock(&nest_init_lock);
> 1346 kfree(nest_imc_refc);
> 1347 kfree(per_nest_pmu_arr);
> 1348 goto err_free;
> 1349 }
> 1350 }
> 1351 nest_pmus++;
> 1352 mutex_unlock(&nest_init_lock);
> 1353 break;
> 1354 case IMC_DOMAIN_CORE:
> 1355 ret = core_imc_pmu_cpumask_init();
> 1356 if (ret) {
> 1357 cleanup_all_core_imc_memory();
> 1358 return ret;
>
> These direct returns don't look correct...
>
> 1359 }
> 1360
> 1361 break;
> 1362 case IMC_DOMAIN_THREAD:
> 1363 ret = thread_imc_cpu_init();
> 1364 if (ret) {
> 1365 cleanup_all_thread_imc_memory();
> 1366 return ret;
> 1367 }
> 1368
> 1369 break;
> 1370 default:
> 1371 return -1; /* Unknown domain */
>
> This one certainly looks like a memory leak. Plus -1 is -EPERM which is
> probably not the correct error code.
>
>
> 1372 }
> 1373
> 1374 ret = update_events_in_group(parent, pmu_ptr);
> 1375 if (ret)
> 1376 goto err_free;
> 1377
> 1378 ret = update_pmu_ops(pmu_ptr);
> 1379 if (ret)
> 1380 goto err_free;
> 1381
> 1382 ret = perf_pmu_register(&pmu_ptr->pmu, pmu_ptr->pmu.name, -1);
> 1383 if (ret)
> 1384 goto err_free;
> 1385
> 1386 pr_info("%s performance monitor hardware support registered\n",
> 1387 pmu_ptr->pmu.name);
> 1388
> 1389 return 0;
> 1390
> 1391 err_free:
> 1392 imc_common_mem_free(pmu_ptr);
> 1393 imc_common_cpuhp_mem_free(pmu_ptr);
> ^^^^^^^
> This is a use after free, it should be in the reverse order.
>
> err_free_cpuhp:
> imc_common_cpuhp_mem_free(pmu_ptr);
> err_free_pmu_ptr:
> imc_common_mem_free(pmu_ptr);
>
> 1394 return ret;
> 1395 }
>
> regards,
> dan carpenter
>
Apologies for the delayed response, I just got back from vacation.
Thank you for pointing out this, I will rework the code and send.
Regards,
Anju
^ permalink raw reply
* [PATCH] powerpc/vas: do not set uses_vas for kernel windows
From: Nicholas Piggin @ 2018-02-08 9:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin, Sukadev Bhattiprolu
cp_abort is only required or user windows, because kernel context
must not be preempted between a copy/paste pair.
Without this patch, the init task gets used_vas set when it runs
the nx842_powernv_init initcall, which opens windows for kernel
usage.
used_vas is then never cleared anywhere, so it gets propagated
into all other tasks. It's a property of the address space, so it
should really be cleared when a new mm is created (or in dup_mmap
if the mmaps are marked as VM_DONTCOPY). For now we seem to have
no such driver, so leave that for another patch.
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/powernv/vas-window.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c
index 2b3eb01ab110..b7c53a51c31b 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1063,16 +1063,16 @@ struct vas_window *vas_tx_win_open(int vasid, enum vas_cop_type cop,
rc = PTR_ERR(txwin->paste_kaddr);
goto free_window;
}
+ } else {
+ /*
+ * A user mapping must ensure that context switch issues
+ * CP_ABORT for this thread.
+ */
+ rc = set_thread_uses_vas();
+ if (rc)
+ goto free_window;
}
- /*
- * Now that we have a send window, ensure context switch issues
- * CP_ABORT for this thread.
- */
- rc = -EINVAL;
- if (set_thread_uses_vas() < 0)
- goto free_window;
-
set_vinst_win(vinst, txwin);
return txwin;
--
2.15.1
^ permalink raw reply related
* Re: [PATCH] powerpc/fsl/dts: fix the i2c-mux compatible for t104xqds
From: Peter Rosin @ 2018-02-08 9:32 UTC (permalink / raw)
To: linux-kernel, Scott Wood, Kumar Gala, Prabhakar Kushwaha
Cc: Rob Herring, Mark Rutland, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, devicetree, linuxppc-dev
In-Reply-To: <20170803125934.14960-1-peda@axentia.se>
[Adding some people whom seem relevant but did not get fingered by
get_maintainer.pl]
On 2017-08-03 14:59, Peter Rosin wrote:
> The sanctioned compatible is "nxp,pca9547".
Ping.
Cheers,
Peter
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> arch/powerpc/boot/dts/fsl/t104xqds.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t104xqds.dtsi b/arch/powerpc/boot/dts/fsl/t104xqds.dtsi
> index 2fd4cbe7098f..615479732252 100644
> --- a/arch/powerpc/boot/dts/fsl/t104xqds.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t104xqds.dtsi
> @@ -269,7 +269,7 @@
>
> i2c@118000 {
> pca9547@77 {
> - compatible = "philips,pca9547";
> + compatible = "nxp,pca9547";
> reg = <0x77>;
> };
> rtc@68 {
>
^ permalink raw reply
* [PATCH 1/2] powerpc/mm: Fix crashes with PUD level hugetlb config
From: Aneesh Kumar K.V @ 2018-02-08 10:34 UTC (permalink / raw)
To: benh, paulus, mpe, linuxram; +Cc: linuxppc-dev, Aneesh Kumar K.V
To support memory keys, we moved the hash pte slot information to the second
half of the page table. This was ok with PTE entries at level 4 and level 3.
We already allocate larger page table pages at those level to accomodate extra
details. For level 4 we already have the extra space which was used to track
4k hash page table entry details and at pmd level the extra space was allocated
to track the THP details.
With hugetlbfs PTE, we used this extra space at the PMD level to store the
slot details. But we also support hugetlbfs PTE at PUD leve and PUD level page
didn't allocate extra space. This resulted in memory corruption.
Fix this by allocating extra space at PUD level when HUGETLB is enabled. We
may need further changes to allocate larger space at PMD level when we enable
HUGETLB. That will be done in next patch.
Fixes:bf9a95f9a6481bc6e(" powerpc: Free up four 64K PTE bits in 64K backed HPTE pages")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
NOTE: In the long run we may want to look at my patch series to remove slot
tracking completely.
arch/powerpc/include/asm/book3s/32/pgtable.h | 1 +
arch/powerpc/include/asm/book3s/64/hash-64k.h | 5 +++++
arch/powerpc/include/asm/book3s/64/hash.h | 10 ++++++++++
arch/powerpc/include/asm/book3s/64/pgalloc.h | 6 +++---
arch/powerpc/include/asm/book3s/64/pgtable.h | 2 ++
arch/powerpc/include/asm/nohash/32/pgtable.h | 1 +
arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
arch/powerpc/mm/hash_utils_64.c | 1 +
arch/powerpc/mm/init-common.c | 4 ++--
arch/powerpc/mm/pgtable-radix.c | 1 +
arch/powerpc/mm/pgtable_64.c | 2 ++
11 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h b/arch/powerpc/include/asm/book3s/32/pgtable.h
index 30a155c0a6b0..c615abdce119 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -16,6 +16,7 @@
#define PGD_INDEX_SIZE (32 - PGDIR_SHIFT)
#define PMD_CACHE_INDEX PMD_INDEX_SIZE
+#define PUD_CACHE_INDEX PUD_INDEX_SIZE
#ifndef __ASSEMBLY__
#define PTE_TABLE_SIZE (sizeof(pte_t) << PTE_INDEX_SIZE)
diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h b/arch/powerpc/include/asm/book3s/64/hash-64k.h
index 338b7da468ce..c08b3b032ec0 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
@@ -146,7 +146,12 @@ static inline int hash__remap_4k_pfn(struct vm_area_struct *vma, unsigned long a
#else
#define H_PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
#endif
+#ifdef CONFIG_HUGETLB_PAGE
+#define H_PUD_TABLE_SIZE ((sizeof(pud_t) << PUD_INDEX_SIZE) + \
+ (sizeof(unsigned long) << PUD_INDEX_SIZE))
+#else
#define H_PUD_TABLE_SIZE (sizeof(pud_t) << PUD_INDEX_SIZE)
+#endif
#define H_PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
diff --git a/arch/powerpc/include/asm/book3s/64/hash.h b/arch/powerpc/include/asm/book3s/64/hash.h
index 0920eff731b3..234f141fb151 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -32,6 +32,16 @@
#else
#define H_PMD_CACHE_INDEX H_PMD_INDEX_SIZE
#endif
+/*
+ * We not store the slot details in the second half of page table.
+ * Increase the pud level table so that hugetlb ptes can be stored
+ * at pud level.
+ */
+#if defined(CONFIG_HUGETLB_PAGE) && defined(CONFIG_PPC_64K_PAGES)
+#define H_PUD_CACHE_INDEX (H_PUD_INDEX_SIZE + 1)
+#else
+#define H_PUD_CACHE_INDEX (H_PUD_INDEX_SIZE)
+#endif
/*
* Define the address range of the kernel non-linear virtual area
*/
diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h b/arch/powerpc/include/asm/book3s/64/pgalloc.h
index 1fcfa425cefa..53df86d3cfce 100644
--- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
+++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
@@ -93,13 +93,13 @@ static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return kmem_cache_alloc(PGT_CACHE(PUD_INDEX_SIZE),
+ return kmem_cache_alloc(PGT_CACHE(PUD_CACHE_INDEX),
pgtable_gfp_flags(mm, GFP_KERNEL));
}
static inline void pud_free(struct mm_struct *mm, pud_t *pud)
{
- kmem_cache_free(PGT_CACHE(PUD_INDEX_SIZE), pud);
+ kmem_cache_free(PGT_CACHE(PUD_CACHE_INDEX), pud);
}
static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
@@ -115,7 +115,7 @@ static inline void __pud_free_tlb(struct mmu_gather *tlb, pud_t *pud,
* ahead and flush the page walk cache
*/
flush_tlb_pgtable(tlb, address);
- pgtable_free_tlb(tlb, pud, PUD_INDEX_SIZE);
+ pgtable_free_tlb(tlb, pud, PUD_CACHE_INDEX);
}
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 51017726d495..3c14663d457d 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -232,11 +232,13 @@ extern unsigned long __pmd_index_size;
extern unsigned long __pud_index_size;
extern unsigned long __pgd_index_size;
extern unsigned long __pmd_cache_index;
+extern unsigned long __pud_cache_index;
#define PTE_INDEX_SIZE __pte_index_size
#define PMD_INDEX_SIZE __pmd_index_size
#define PUD_INDEX_SIZE __pud_index_size
#define PGD_INDEX_SIZE __pgd_index_size
#define PMD_CACHE_INDEX __pmd_cache_index
+#define PUD_CACHE_INDEX __pmd_cache_index
/*
* Because of use of pte fragments and THP, size of page table
* are not always derived out of index size above.
diff --git a/arch/powerpc/include/asm/nohash/32/pgtable.h b/arch/powerpc/include/asm/nohash/32/pgtable.h
index 504a3c36ce5c..03bbd1149530 100644
--- a/arch/powerpc/include/asm/nohash/32/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
@@ -24,6 +24,7 @@ extern int icache_44x_need_flush;
#define PGD_INDEX_SIZE (32 - PGDIR_SHIFT)
#define PMD_CACHE_INDEX PMD_INDEX_SIZE
+#define PUD_CACHE_INDEX PUD_INDEX_SIZE
#ifndef __ASSEMBLY__
#define PTE_TABLE_SIZE (sizeof(pte_t) << PTE_INDEX_SIZE)
diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h b/arch/powerpc/include/asm/nohash/64/pgtable.h
index abddf5830ad5..5c5f75d005ad 100644
--- a/arch/powerpc/include/asm/nohash/64/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -27,6 +27,7 @@
#else
#define PMD_CACHE_INDEX PMD_INDEX_SIZE
#endif
+#define PUD_CACHE_INDEX PUD_INDEX_SIZE
/*
* Define the address range of the kernel non-linear virtual area
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 7d07c7e17db6..cf290d415dcd 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1008,6 +1008,7 @@ void __init hash__early_init_mmu(void)
__pmd_index_size = H_PMD_INDEX_SIZE;
__pud_index_size = H_PUD_INDEX_SIZE;
__pgd_index_size = H_PGD_INDEX_SIZE;
+ __pud_cache_index = H_PUD_CACHE_INDEX;
__pmd_cache_index = H_PMD_CACHE_INDEX;
__pte_table_size = H_PTE_TABLE_SIZE;
__pmd_table_size = H_PMD_TABLE_SIZE;
diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
index eb8c6c8c4851..2b656e67f2ea 100644
--- a/arch/powerpc/mm/init-common.c
+++ b/arch/powerpc/mm/init-common.c
@@ -100,6 +100,6 @@ void pgtable_cache_init(void)
* same size as either the pgd or pmd index except with THP enabled
* on book3s 64
*/
- if (PUD_INDEX_SIZE && !PGT_CACHE(PUD_INDEX_SIZE))
- pgtable_cache_add(PUD_INDEX_SIZE, pud_ctor);
+ if (PUD_CACHE_INDEX && !PGT_CACHE(PUD_CACHE_INDEX))
+ pgtable_cache_add(PUD_CACHE_INDEX, pud_ctor);
}
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index 573a9a2ee455..27d096610369 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -535,6 +535,7 @@ void __init radix__early_init_mmu(void)
__pmd_index_size = RADIX_PMD_INDEX_SIZE;
__pud_index_size = RADIX_PUD_INDEX_SIZE;
__pgd_index_size = RADIX_PGD_INDEX_SIZE;
+ __pud_cache_index = RADIX_PUD_INDEX_SIZE;
__pmd_cache_index = RADIX_PMD_INDEX_SIZE;
__pte_table_size = RADIX_PTE_TABLE_SIZE;
__pmd_table_size = RADIX_PMD_TABLE_SIZE;
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index c9a623c2d8a2..a0f8928c0b86 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -82,6 +82,8 @@ unsigned long __pgd_index_size;
EXPORT_SYMBOL(__pgd_index_size);
unsigned long __pmd_cache_index;
EXPORT_SYMBOL(__pmd_cache_index);
+unsigned long __pud_cache_index;
+EXPORT_SYMBOL(__pud_cache_index);
unsigned long __pte_table_size;
EXPORT_SYMBOL(__pte_table_size);
unsigned long __pmd_table_size;
--
2.14.3
^ permalink raw reply related
* [PATCH 2/2] powerpc/mm/hash64: Allocate larger PMD table if hugetlb config is enabled.
From: Aneesh Kumar K.V @ 2018-02-08 10:34 UTC (permalink / raw)
To: benh, paulus, mpe, linuxram; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180208103442.22045-1-aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/book3s/64/hash-64k.h | 2 +-
arch/powerpc/include/asm/book3s/64/hash.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h b/arch/powerpc/include/asm/book3s/64/hash-64k.h
index c08b3b032ec0..ee440fb3d240 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
@@ -140,7 +140,7 @@ static inline int hash__remap_4k_pfn(struct vm_area_struct *vma, unsigned long a
}
#define H_PTE_TABLE_SIZE PTE_FRAG_SIZE
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined (CONFIG_HUGETLB_PAGE)
#define H_PMD_TABLE_SIZE ((sizeof(pmd_t) << PMD_INDEX_SIZE) + \
(sizeof(unsigned long) << PMD_INDEX_SIZE))
#else
diff --git a/arch/powerpc/include/asm/book3s/64/hash.h b/arch/powerpc/include/asm/book3s/64/hash.h
index 234f141fb151..0851c328bea6 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -23,7 +23,8 @@
H_PUD_INDEX_SIZE + H_PGD_INDEX_SIZE + PAGE_SHIFT)
#define H_PGTABLE_RANGE (ASM_CONST(1) << H_PGTABLE_EADDR_SIZE)
-#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && defined(CONFIG_PPC_64K_PAGES)
+#if (defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLB_PAGE)) && \
+ defined(CONFIG_PPC_64K_PAGES)
/*
* only with hash 64k we need to use the second half of pmd page table
* to store pointer to deposited pgtable_t
--
2.14.3
^ permalink raw reply related
* [RFC][PATCH bpf 1/2] bpf: allow 64-bit offsets for bpf function calls
From: Sandipan Das @ 2018-02-08 12:03 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linuxppc-dev, mpe, naveen.n.rao
The imm field of a bpf_insn is a signed 32-bit integer. For
JIT-ed bpf-to-bpf function calls, it stores the offset from
__bpf_call_base to the start of the callee function.
For some architectures, such as powerpc64, it was found that
this offset may be as large as 64 bits because of which this
cannot be accomodated in the imm field without truncation.
To resolve this, we additionally use the aux data within each
bpf_prog associated with the caller functions to store the
addresses of their respective callees.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
kernel/bpf/verifier.c | 39 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 5fb69a85d967..52088b4ca02f 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5282,6 +5282,19 @@ static int jit_subprogs(struct bpf_verifier_env *env)
* run last pass of JIT
*/
for (i = 0; i <= env->subprog_cnt; i++) {
+ u32 flen = func[i]->len, callee_cnt = 0;
+ struct bpf_prog **callee;
+
+ /* for now assume that the maximum number of bpf function
+ * calls that can be made by a caller must be at most the
+ * number of bpf instructions in that function
+ */
+ callee = kzalloc(sizeof(func[i]) * flen, GFP_KERNEL);
+ if (!callee) {
+ err = -ENOMEM;
+ goto out_free;
+ }
+
insn = func[i]->insnsi;
for (j = 0; j < func[i]->len; j++, insn++) {
if (insn->code != (BPF_JMP | BPF_CALL) ||
@@ -5292,6 +5305,26 @@ static int jit_subprogs(struct bpf_verifier_env *env)
insn->imm = (u64 (*)(u64, u64, u64, u64, u64))
func[subprog]->bpf_func -
__bpf_call_base;
+
+ /* the offset to the callee from __bpf_call_base
+ * may be larger than what the 32 bit integer imm
+ * can accomodate which will truncate the higher
+ * order bits
+ *
+ * to avoid this, we additionally utilize the aux
+ * data of each caller function for storing the
+ * addresses of every callee associated with it
+ */
+ callee[callee_cnt++] = func[subprog];
+ }
+
+ /* free up callee list if no function calls were made */
+ if (!callee_cnt) {
+ kfree(callee);
+ callee = NULL;
+ } else {
+ func[i]->aux->func = callee;
+ func[i]->aux->func_cnt = callee_cnt;
}
}
for (i = 0; i <= env->subprog_cnt; i++) {
@@ -5338,8 +5371,12 @@ static int jit_subprogs(struct bpf_verifier_env *env)
return 0;
out_free:
for (i = 0; i <= env->subprog_cnt; i++)
- if (func[i])
+ if (func[i]) {
+ /* cleanup callee list */
+ if (func[i]->aux->func)
+ kfree(func[i]->aux->func);
bpf_jit_free(func[i]);
+ }
kfree(func);
/* cleanup main prog to be interpreted */
prog->jit_requested = 0;
--
2.14.3
^ permalink raw reply related
* [RFC][PATCH bpf 2/2] bpf: powerpc64: add JIT support for multi-function programs
From: Sandipan Das @ 2018-02-08 12:03 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linuxppc-dev, mpe, naveen.n.rao
In-Reply-To: <20180208120306.2568-1-sandipan@linux.vnet.ibm.com>
This adds support for bpf-to-bpf function calls for the powerpc64
JIT compiler. After a round of the usual JIT passes, the offsets
to callee functions from __bpf_call_base are known. To update the
target addresses for the branch instructions associated with each
BPF_CALL, an extra pass is performed.
Since it is seen that the offsets may be as large as 64 bits for
powerpc64, we use the aux data associated with each caller to get
the correct branch target address rather than using the imm field
of the BPF_CALL instruction.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
arch/powerpc/net/bpf_jit_comp64.c | 77 ++++++++++++++++++++++++++++++++++-----
1 file changed, 67 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index 0a34b0cec7b7..f31f22c8cb0b 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -290,7 +290,7 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
/* Assemble the body code between the prologue & epilogue */
static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *ctx,
- u32 *addrs)
+ u32 *addrs, bool extra_pass)
{
const struct bpf_insn *insn = fp->insnsi;
int flen = fp->len;
@@ -299,6 +299,10 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
/* Start of epilogue code - will only be valid 2nd pass onwards */
u32 exit_addr = addrs[flen];
+ /* List of callee functions - will only be valid for the extra pass */
+ struct bpf_prog **callee = fp->aux->func;
+ u32 callee_cnt = fp->aux->func_cnt, callee_idx = 0;
+
for (i = 0; i < flen; i++) {
u32 code = insn[i].code;
u32 dst_reg = b2p[insn[i].dst_reg];
@@ -746,11 +750,17 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
break;
/*
- * Call kernel helper
+ * Call kernel helper or bpf function
*/
case BPF_JMP | BPF_CALL:
ctx->seen |= SEEN_FUNC;
- func = (u8 *) __bpf_call_base + imm;
+ if (insn[i].src_reg == BPF_PSEUDO_CALL && extra_pass)
+ if (callee && callee_idx < callee_cnt)
+ func = (u8 *) callee[callee_idx++]->bpf_func;
+ else
+ return -EINVAL;
+ else
+ func = (u8 *) __bpf_call_base + imm;
/* Save skb pointer if we need to re-cache skb data */
if ((ctx->seen & SEEN_SKB) &&
@@ -970,6 +980,14 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
return 0;
}
+struct powerpc64_jit_data {
+ struct bpf_binary_header *header;
+ u32 *addrs;
+ u8 *image;
+ u32 proglen;
+ struct codegen_context ctx;
+};
+
struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
{
u32 proglen;
@@ -977,6 +995,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
u8 *image = NULL;
u32 *code_base;
u32 *addrs;
+ struct powerpc64_jit_data *jit_data;
struct codegen_context cgctx;
int pass;
int flen;
@@ -984,6 +1003,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
struct bpf_prog *org_fp = fp;
struct bpf_prog *tmp_fp;
bool bpf_blinded = false;
+ bool extra_pass = false;
if (!fp->jit_requested)
return org_fp;
@@ -997,7 +1017,28 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
fp = tmp_fp;
}
+ jit_data = fp->aux->jit_data;
+ if (!jit_data) {
+ jit_data = kzalloc(sizeof(*jit_data), GFP_KERNEL);
+ if (!jit_data) {
+ fp = org_fp;
+ goto out;
+ }
+ fp->aux->jit_data = jit_data;
+ }
+
flen = fp->len;
+ addrs = jit_data->addrs;
+ if (addrs) {
+ cgctx = jit_data->ctx;
+ image = jit_data->image;
+ bpf_hdr = jit_data->header;
+ proglen = jit_data->proglen;
+ alloclen = proglen + FUNCTION_DESCR_SIZE;
+ extra_pass = true;
+ goto skip_init_ctx;
+ }
+
addrs = kzalloc((flen+1) * sizeof(*addrs), GFP_KERNEL);
if (addrs == NULL) {
fp = org_fp;
@@ -1010,10 +1051,10 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
cgctx.stack_size = round_up(fp->aux->stack_depth, 16);
/* Scouting faux-generate pass 0 */
- if (bpf_jit_build_body(fp, 0, &cgctx, addrs)) {
+ if (bpf_jit_build_body(fp, 0, &cgctx, addrs, false)) {
/* We hit something illegal or unsupported. */
fp = org_fp;
- goto out;
+ goto out_addrs;
}
/*
@@ -1031,9 +1072,10 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
bpf_jit_fill_ill_insns);
if (!bpf_hdr) {
fp = org_fp;
- goto out;
+ goto out_addrs;
}
+skip_init_ctx:
code_base = (u32 *)(image + FUNCTION_DESCR_SIZE);
/* Code generation passes 1-2 */
@@ -1041,7 +1083,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
/* Now build the prologue, body code & epilogue for real. */
cgctx.idx = 0;
bpf_jit_build_prologue(code_base, &cgctx);
- bpf_jit_build_body(fp, code_base, &cgctx, addrs);
+ bpf_jit_build_body(fp, code_base, &cgctx, addrs, extra_pass);
bpf_jit_build_epilogue(code_base, &cgctx);
if (bpf_jit_enable > 1)
@@ -1062,15 +1104,30 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
((u64 *)image)[1] = local_paca->kernel_toc;
#endif
+ bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE));
+
+ if (!fp->is_func || extra_pass) {
+ bpf_jit_binary_lock_ro(bpf_hdr);
+ } else {
+ jit_data->addrs = addrs;
+ jit_data->ctx = cgctx;
+ jit_data->proglen = proglen;
+ jit_data->image = image;
+ jit_data->header = bpf_hdr;
+ }
+
fp->bpf_func = (void *)image;
fp->jited = 1;
fp->jited_len = alloclen;
- bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE));
+ if (!fp->is_func || extra_pass) {
+out_addrs:
+ kfree(addrs);
+ kfree(jit_data);
+ fp->aux->jit_data = NULL;
+ }
out:
- kfree(addrs);
-
if (bpf_blinded)
bpf_jit_prog_release_other(fp, fp == org_fp ? tmp_fp : org_fp);
--
2.14.3
^ permalink raw reply related
* [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Michael Ellerman @ 2018-02-08 12:20 UTC (permalink / raw)
To: bhelgaas; +Cc: linux-pci, linuxppc-dev, torvalds, ruscur, bryantly, jjalvare
There's no reason pci_uevent_ers() needs to be inline in pci.h, so
move it out to a C file.
Given it's used by AER the obvious location would be somewhere in
drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
unfortunately that doesn't work in the case where EEH is enabled but
PCIEPORTBUS is not.
So for now put it in pci-driver.c, next to pci_uevent(), with an
appropriate #ifdef so it's not built if AER and EEH are both disabled.
While we're moving it also fix up the kernel doc comment for @pdev to
be accurate.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
drivers/pci/pci-driver.c | 36 ++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 38 +++-----------------------------------
2 files changed, 39 insertions(+), 35 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 3bed6beda051..f21e8b1bef80 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1517,6 +1517,42 @@ static int pci_uevent(struct device *dev, struct kobj_uevent_env *env)
return 0;
}
+#if defined(CONFIG_PCIEAER) || defined(CONFIG_EEH)
+/**
+ * pci_uevent_ers - emit a uevent during recovery path of pci device
+ * @pdev: pci device undergoing error recovery
+ * @err_type: type of error event
+ */
+void pci_uevent_ers(struct pci_dev *pdev, enum pci_ers_result err_type)
+{
+ int idx = 0;
+ char *envp[3];
+
+ switch (err_type) {
+ case PCI_ERS_RESULT_NONE:
+ case PCI_ERS_RESULT_CAN_RECOVER:
+ envp[idx++] = "ERROR_EVENT=BEGIN_RECOVERY";
+ envp[idx++] = "DEVICE_ONLINE=0";
+ break;
+ case PCI_ERS_RESULT_RECOVERED:
+ envp[idx++] = "ERROR_EVENT=SUCCESSFUL_RECOVERY";
+ envp[idx++] = "DEVICE_ONLINE=1";
+ break;
+ case PCI_ERS_RESULT_DISCONNECT:
+ envp[idx++] = "ERROR_EVENT=FAILED_RECOVERY";
+ envp[idx++] = "DEVICE_ONLINE=0";
+ break;
+ default:
+ break;
+ }
+
+ if (idx > 0) {
+ envp[idx++] = NULL;
+ kobject_uevent_env(&pdev->dev.kobj, KOBJ_CHANGE, envp);
+ }
+}
+#endif
+
static int pci_bus_num_vf(struct device *dev)
{
return pci_num_vf(to_pci_dev(dev));
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 024a1beda008..19c1dbcff0c6 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2280,41 +2280,9 @@ static inline bool pci_is_thunderbolt_attached(struct pci_dev *pdev)
return false;
}
-/**
- * pci_uevent_ers - emit a uevent during recovery path of pci device
- * @pdev: pci device to check
- * @err_type: type of error event
- *
- */
-static inline void pci_uevent_ers(struct pci_dev *pdev,
- enum pci_ers_result err_type)
-{
- int idx = 0;
- char *envp[3];
-
- switch (err_type) {
- case PCI_ERS_RESULT_NONE:
- case PCI_ERS_RESULT_CAN_RECOVER:
- envp[idx++] = "ERROR_EVENT=BEGIN_RECOVERY";
- envp[idx++] = "DEVICE_ONLINE=0";
- break;
- case PCI_ERS_RESULT_RECOVERED:
- envp[idx++] = "ERROR_EVENT=SUCCESSFUL_RECOVERY";
- envp[idx++] = "DEVICE_ONLINE=1";
- break;
- case PCI_ERS_RESULT_DISCONNECT:
- envp[idx++] = "ERROR_EVENT=FAILED_RECOVERY";
- envp[idx++] = "DEVICE_ONLINE=0";
- break;
- default:
- break;
- }
-
- if (idx > 0) {
- envp[idx++] = NULL;
- kobject_uevent_env(&pdev->dev.kobj, KOBJ_CHANGE, envp);
- }
-}
+#if defined(CONFIG_PCIEAER) || defined(CONFIG_EEH)
+void pci_uevent_ers(struct pci_dev *pdev, enum pci_ers_result err_type);
+#endif
/* Provide the legacy pci_dma_* API */
#include <linux/pci-dma-compat.h>
--
2.14.1
^ permalink raw reply related
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