* Re: Time to get rid of CPU6 ERRATA on powerpc/8xx ?
From: Joakim Tjernlund @ 2018-01-07 18:34 UTC (permalink / raw)
To: christophe.leroy@c-s.fr, linuxppc-dev@lists.ozlabs.org,
mpe@ellerman.id.au, scottwood@freescale.com, paulus@samba.org,
segher@kernel.crashing.org, joakim.tjernlund@transmode.se
In-Reply-To: <26b73379-141c-a705-a552-6ee2b94f4961@c-s.fr>
T24gU3VuLCAyMDE4LTAxLTA3IGF0IDE3OjIzICswMTAwLCBjaHJpc3RvcGhlIGxlcm95IHdyb3Rl
Og0KPiBDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBv
cmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVz
cyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4N
Cj4gDQo+IA0KPiBUb2RheSwgTGludXgga2VybmVsIGluY2x1ZGVzIGEgd29ya2Fyb3VuZCBmb3Ig
Q1BVNiBFUlJBVEEgb24gdGhlIDh4eA0KPiBwb3dlcnBjLg0KPiANCj4gVGhpcyBFUlJBVEEgZXhp
c3RzIG9uIHRoZSA4MDEsIHRoZSA4MjMsIHRoZSA4NTUvODYwIGJlZm9yZSByZXZpc2lvbiBDLjAN
Cj4gSXQgZG9lc24ndCBjb25jZXJuIGFueSBtb2Rlcm4gdmVyc2lvbnMgb2YgdGhlIDh4eCwgbmVp
dGhlciB0aGUgODYwIHBhc3QNCj4gYW5kIGluY2x1ZGluZyByZXYgQy4wLCBub3IgdGhlIDg2NiBu
b3IgdGhlIDg4NQ0KPiANCj4gVGhpcyB3b3JrYXJvdW5kIGNvbXBsaWNhdGVzIHRoZSBUTEJtaXNz
IGFuZCBUTEJlcnJvciBoYW5kbGVycyBhbmQgbWFrZQ0KPiB0aGUgY29kZSBtb3JlIGFuZCBtb3Jl
IHVucmVhZGFibGUuDQo+IA0KPiBTaW5jZSB0aGlzIHdvcmthcm91bmQgYWRkcmVzc2VzIHZlcnkg
b2xkIHZlcnNpb25zIG9mIHRoZSA4eHgsIEknZCBsaWtlDQo+IHRvIGdldCByaWQgb2YgaXQuIERv
IHlvdSBzZWUgYW55IGdvb2QgcmVhc29uIHRvIGtlZXAgaXQgdG9kYXkgPyBJZiBub3QgSQ0KPiB3
aWxsIGNvbWUgd2l0aCBhIGNsZWFudXAgcGF0Y2ggaW4gdGhlIGNvbWluZyB3ZWVrcy4NCj4gDQo+
IEFub3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8ga2VlcCB0aGF0IHdvcmthcm91bmQgc2Vw
YXJhdGVkIGZyb20gdGhlDQo+IHJlc3Qgb2YgdGhlIGNvZGUgKGllIHVzaW5nIGRpZmZlcmVudCBy
ZWdpc3RlcnMgdG8gYXZvaWQvbGltaXQgY29kZQ0KPiBuZXN0aW5nKSwgaXQgd291bGQgYWRkIGEg
ZmV3IGN5Y2xlcyBidXQgd291bGQgaW5jcmVhc2UgcmVhZGFiaWxpdHkgd2hpbGUNCj4ga2VlcGlu
ZyB0aGUgRVJSQVRBIGluLCBhbGx0aG91Z2h0IG15IHByZWZlcmVuY2UgZ29lcyB0byBhIGNvbXBs
ZXRlDQo+IHJlbW92YWwgb2YgdGhlIHdvcmthcm91bmQuDQo+IA0KPiBTbywgdGhhbmtzIHRvIGxl
dCBtZSBrbm93IHlvdXIgb3BpbmlvbiBvbiB0aGF0Lg0KDQpIYXZpbmcgZG9uZSB3b3JrIG9uIFRM
QiBNaXNzL0Vycm9yLCBJIGFncmVlIHRoZSBDUFU2IGVycmF0YSBpcyBhIHBhaW4uDQpPbiBhbGwg
b3VyIDh4eCAoODZ4Lzg1MCkgd2UgbmV2ZXIgaGFkIHRvIHVzZSB0aGlzIGVycmF0YSBzbyBJIGFt
IGluIGZhdm91ciBmb3INCnJlbW92aW5nIENQVTYgRXJyYXRhIGZyb20gcmVjZW50IGtlcm5lbHMu
DQoNCiAgSm9ja2UNCg0K
^ permalink raw reply
* Re: Time to get rid of CPU6 ERRATA on powerpc/8xx ?
From: Segher Boessenkool @ 2018-01-07 18:21 UTC (permalink / raw)
To: christophe leroy
Cc: linuxppc-dev, Michael Ellerman, Paul Mackerras, Scott Wood,
Joakim Tjernlund
In-Reply-To: <61f2b2bb-bdc0-39f5-81df-dc931494bb4b@c-s.fr>
On Sun, Jan 07, 2018 at 06:51:26PM +0100, christophe leroy wrote:
> Le 07/01/2018 à 17:43, Segher Boessenkool a écrit :
> >On Sun, Jan 07, 2018 at 05:23:13PM +0100, christophe leroy wrote:
> >>Today, Linux kernel includes a workaround for CPU6 ERRATA on the 8xx
> >>powerpc.
> >>
> >>This ERRATA exists on the 801, the 823, the 855/860 before revision C.0
> >>It doesn't concern any modern versions of the 8xx, neither the 860 past
> >>and including rev C.0, nor the 866 nor the 885
> >>
> >>This workaround complicates the TLBmiss and TLBerror handlers and make
> >>the code more and more unreadable.
> >>
> >>Since this workaround addresses very old versions of the 8xx, I'd like
> >>to get rid of it. Do you see any good reason to keep it today ? If not I
> >>will come with a cleanup patch in the coming weeks.
> >
> >What is "very old"? It'll help if you give some indication.
>
> CPU6 bug is already announced fixed in rev C.0 in revision 1.4 of the
> ERRATA document, issued in August 2000.
And that is the newest chip that had the bug? Wow, very old indeed then.
> >Removing the workarounds is fine by me, of course... Maybe make it fail
> >to boot though, with an error message? Someone *will* try to run it on
> >an old system, *especially* if you think no one would.
>
> Ok, will see how we can do that. It means identifying each revision of
> the chip.
If it is *that* old you may not have to bother... Up to the maintainers
of course.
Segher
^ permalink raw reply
* Re: [PATCH -next] ASoC: fsl_ssi: Fix build error
From: Nicolin Chen @ 2018-01-07 17:55 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mark Brown, Liam Girdwood, Fabio Estevam, Xiubo Li, alsa-devel,
linuxppc-dev, linux-kernel, Maciej S . Szmigiero, Timur Tabi
In-Reply-To: <1515344750-6159-1-git-send-email-linux@roeck-us.net>
On Sun, Jan 07, 2018 at 09:05:50AM -0800, Guenter Roeck wrote:
> powerpc:mpc85xx_defconfig fails to build with the following errors.
>
> sound/soc/fsl/fsl_dma.c: In function 'fsl_soc_dma_probe':
> sound/soc/fsl/fsl_dma.c:916:34: error: 'CCSR_SSI_STX0' undeclared
> sound/soc/fsl/fsl_dma.c:917:34: error: 'CCSR_SSI_SRX0' undeclared
>
> Fixes: a818aa5f967b ("ASoC: fsl_ssi: Rename registers and fields macros")
> Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Thanks
> Cc: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
> Cc: Timur Tabi <timur@tabi.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> I would suggest to merge this patch into the offending patch to preserve
> bisectability.
>
> sound/soc/fsl/fsl_dma.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> index 0c11f434a374..8c2981b70f64 100644
> --- a/sound/soc/fsl/fsl_dma.c
> +++ b/sound/soc/fsl/fsl_dma.c
> @@ -913,8 +913,8 @@ static int fsl_soc_dma_probe(struct platform_device *pdev)
> dma->dai.pcm_free = fsl_dma_free_dma_buffers;
>
> /* Store the SSI-specific information that we need */
> - dma->ssi_stx_phys = res.start + CCSR_SSI_STX0;
> - dma->ssi_srx_phys = res.start + CCSR_SSI_SRX0;
> + dma->ssi_stx_phys = res.start + REG_SSI_STX0;
> + dma->ssi_srx_phys = res.start + REG_SSI_SRX0;
>
> iprop = of_get_property(ssi_np, "fsl,fifo-depth", NULL);
> if (iprop)
> --
> 2.7.4
>
^ permalink raw reply
* Re: Time to get rid of CPU6 ERRATA on powerpc/8xx ?
From: christophe leroy @ 2018-01-07 17:51 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Michael Ellerman, Paul Mackerras, Scott Wood,
Joakim Tjernlund
In-Reply-To: <20180107164304.GA21977@gate.crashing.org>
Le 07/01/2018 à 17:43, Segher Boessenkool a écrit :
> On Sun, Jan 07, 2018 at 05:23:13PM +0100, christophe leroy wrote:
>> Today, Linux kernel includes a workaround for CPU6 ERRATA on the 8xx
>> powerpc.
>>
>> This ERRATA exists on the 801, the 823, the 855/860 before revision C.0
>> It doesn't concern any modern versions of the 8xx, neither the 860 past
>> and including rev C.0, nor the 866 nor the 885
>>
>> This workaround complicates the TLBmiss and TLBerror handlers and make
>> the code more and more unreadable.
>>
>> Since this workaround addresses very old versions of the 8xx, I'd like
>> to get rid of it. Do you see any good reason to keep it today ? If not I
>> will come with a cleanup patch in the coming weeks.
>
> What is "very old"? It'll help if you give some indication.
CPU6 bug is already announced fixed in rev C.0 in revision 1.4 of the
ERRATA document, issued in August 2000.
>
> Removing the workarounds is fine by me, of course... Maybe make it fail
> to boot though, with an error message? Someone *will* try to run it on
> an old system, *especially* if you think no one would.
Ok, will see how we can do that. It means identifying each revision of
the chip.
Thanks
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
* [PATCH -next] ASoC: fsl_ssi: Fix build error
From: Guenter Roeck @ 2018-01-07 17:05 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Fabio Estevam, Xiubo Li, alsa-devel, linuxppc-dev,
linux-kernel, Guenter Roeck, Nicolin Chen, Maciej S . Szmigiero,
Timur Tabi
powerpc:mpc85xx_defconfig fails to build with the following errors.
sound/soc/fsl/fsl_dma.c: In function 'fsl_soc_dma_probe':
sound/soc/fsl/fsl_dma.c:916:34: error: 'CCSR_SSI_STX0' undeclared
sound/soc/fsl/fsl_dma.c:917:34: error: 'CCSR_SSI_SRX0' undeclared
Fixes: a818aa5f967b ("ASoC: fsl_ssi: Rename registers and fields macros")
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Cc: Timur Tabi <timur@tabi.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
I would suggest to merge this patch into the offending patch to preserve
bisectability.
sound/soc/fsl/fsl_dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
index 0c11f434a374..8c2981b70f64 100644
--- a/sound/soc/fsl/fsl_dma.c
+++ b/sound/soc/fsl/fsl_dma.c
@@ -913,8 +913,8 @@ static int fsl_soc_dma_probe(struct platform_device *pdev)
dma->dai.pcm_free = fsl_dma_free_dma_buffers;
/* Store the SSI-specific information that we need */
- dma->ssi_stx_phys = res.start + CCSR_SSI_STX0;
- dma->ssi_srx_phys = res.start + CCSR_SSI_SRX0;
+ dma->ssi_stx_phys = res.start + REG_SSI_STX0;
+ dma->ssi_srx_phys = res.start + REG_SSI_SRX0;
iprop = of_get_property(ssi_np, "fsl,fifo-depth", NULL);
if (iprop)
--
2.7.4
^ permalink raw reply related
* Re: Time to get rid of CPU6 ERRATA on powerpc/8xx ?
From: Segher Boessenkool @ 2018-01-07 16:43 UTC (permalink / raw)
To: christophe leroy
Cc: linuxppc-dev, Michael Ellerman, Paul Mackerras, Scott Wood,
Joakim Tjernlund
In-Reply-To: <26b73379-141c-a705-a552-6ee2b94f4961@c-s.fr>
On Sun, Jan 07, 2018 at 05:23:13PM +0100, christophe leroy wrote:
> Today, Linux kernel includes a workaround for CPU6 ERRATA on the 8xx
> powerpc.
>
> This ERRATA exists on the 801, the 823, the 855/860 before revision C.0
> It doesn't concern any modern versions of the 8xx, neither the 860 past
> and including rev C.0, nor the 866 nor the 885
>
> This workaround complicates the TLBmiss and TLBerror handlers and make
> the code more and more unreadable.
>
> Since this workaround addresses very old versions of the 8xx, I'd like
> to get rid of it. Do you see any good reason to keep it today ? If not I
> will come with a cleanup patch in the coming weeks.
What is "very old"? It'll help if you give some indication.
Removing the workarounds is fine by me, of course... Maybe make it fail
to boot though, with an error message? Someone *will* try to run it on
an old system, *especially* if you think no one would.
Thanks,
Segher
^ permalink raw reply
* Time to get rid of CPU6 ERRATA on powerpc/8xx ?
From: christophe leroy @ 2018-01-07 16:23 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman, Paul Mackerras, Scott Wood,
Joakim Tjernlund, Segher Boessenkool
Today, Linux kernel includes a workaround for CPU6 ERRATA on the 8xx
powerpc.
This ERRATA exists on the 801, the 823, the 855/860 before revision C.0
It doesn't concern any modern versions of the 8xx, neither the 860 past
and including rev C.0, nor the 866 nor the 885
This workaround complicates the TLBmiss and TLBerror handlers and make
the code more and more unreadable.
Since this workaround addresses very old versions of the 8xx, I'd like
to get rid of it. Do you see any good reason to keep it today ? If not I
will come with a cleanup patch in the coming weeks.
Another alternative would be to keep that workaround separated from the
rest of the code (ie using different registers to avoid/limit code
nesting), it would add a few cycles but would increase readability while
keeping the ERRATA in, allthought my preference goes to a complete
removal of the workaround.
So, thanks to let me know your opinion on that.
Christophe
---
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
* Spectre+Meltdown
From: Christian Zigotzky @ 2018-01-07 13:04 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, Olof Johansson
In-Reply-To: <874lnzz5y3.fsf@concordia.ellerman.id.au>
Hello Michael,
Thanks for your reply. We are using P.A. Semi and Freescale CPUs.
@Olof
Do you have some infos for us?
Thanks,
Christian
On 06/01/18 10:34, Michael Ellerman wrote:
> Christian Zigotzky <chzigotzky@xenosoft.de> writes:
>
>> Hi All,
>>
>> Do we have some information regarding Spectre+Meltdown for our users?
>>
>> It could be that we have some security issues in our PowerPC CPUs.
> There's a statement from IBM here:
>
> https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/
>
>
> I think you're mostly using pasemi CPUs right? I don't have any
> information on them, and obviously it's going to be hard to find anyone
> who might know. You might be best finding a proof of concept somewhere
> and actually testing it.
>
> cheers
>
^ permalink raw reply
* [PATCH] KVM: PPC: Use seq_puts() in kvmppc_exit_timing_show()
From: SF Markus Elfring @ 2018-01-07 9:18 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 7 Jan 2018 10:07:36 +0100
A headline should be quickly put into a sequence. Thus use the
function "seq_puts" instead of "seq_printf" for this purpose.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/powerpc/kvm/timing.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
index e44d2b2ea97e..1c03c978eb18 100644
--- a/arch/powerpc/kvm/timing.c
+++ b/arch/powerpc/kvm/timing.c
@@ -143,8 +143,7 @@ static int kvmppc_exit_timing_show(struct seq_file *m, void *private)
int i;
u64 min, max, sum, sum_quad;
- seq_printf(m, "%s", "type count min max sum sum_squared\n");
-
+ seq_puts(m, "type count min max sum sum_squared\n");
for (i = 0; i < __NUMBER_OF_KVM_EXIT_TYPES; i++) {
--
2.15.1
^ permalink raw reply related
* [PATCH] soc/fsl/guts: Add a NULL check for devm_kasprintf()
From: Fabio Estevam @ 2018-01-06 13:22 UTC (permalink / raw)
To: leoyang.li; +Cc: linuxppc-dev, yangbo.lu, Fabio Estevam
From: Fabio Estevam <fabio.estevam@nxp.com>
devm_kasprintf() may fail, so we should better add a NULL check
and propagate an error on failure.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/soc/fsl/guts.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index d89a6a8..82251b4 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -167,10 +167,16 @@ static int fsl_guts_probe(struct platform_device *pdev)
} else {
soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL, "QorIQ");
}
+ if (!soc_dev_attr.family)
+ return -ENOMEM;
soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
"svr:0x%08x", svr);
+ if (!soc_dev_attr.soc_id)
+ return -ENOMEM;
soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
(svr >> 4) & 0xf, svr & 0xf);
+ if (!soc_dev_attr.revision)
+ return -ENOMEM;
soc_dev = soc_device_register(&soc_dev_attr);
if (IS_ERR(soc_dev))
--
2.7.4
^ permalink raw reply related
* [GIT PULL] Please pull powerpc/linux.git powerpc-4.15-6 tag
From: Michael Ellerman @ 2018-01-06 12:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: benh, jsperbeck, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
Hi Linus,
Please pull one powerpc fix for 4.15:
The following changes since commit 7333b5aca412d6ad02667b5a513485838a91b136:
KVM: PPC: Book3S HV: Fix pending_pri value in kvmppc_xive_get_icp() (2017-12-22 15:36:24 +1100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.15-6
for you to fetch changes up to ecb101aed86156ec7cd71e5dca668e09146e6994:
powerpc/mm: Fix SEGV on mapped region to return SEGV_ACCERR (2018-01-02 21:12:33 +1100)
----------------------------------------------------------------
powerpc fixes for 4.15 #6
Just one fix to correctly return SEGV_ACCERR when we take a SEGV on a mapped
region. The bug was introduced in the refactoring of the page fault handler we
did in the previous release.
Thanks to:
John Sperbeck.
----------------------------------------------------------------
John Sperbeck (1):
powerpc/mm: Fix SEGV on mapped region to return SEGV_ACCERR
arch/powerpc/mm/fault.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* Re: Spectre+Meltdown
From: Michael Ellerman @ 2018-01-06 9:34 UTC (permalink / raw)
To: Christian Zigotzky, linuxppc-dev
In-Reply-To: <36E75811-C758-49B1-8E5C-3A2C44FD5DE9@xenosoft.de>
Christian Zigotzky <chzigotzky@xenosoft.de> writes:
> Hi All,
>
> Do we have some information regarding Spectre+Meltdown for our users?
>
> It could be that we have some security issues in our PowerPC CPUs.
There's a statement from IBM here:
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/
I think you're mostly using pasemi CPUs right? I don't have any
information on them, and obviously it's going to be hard to find anyone
who might know. You might be best finding a proof of concept somewhere
and actually testing it.
cheers
^ permalink raw reply
* Re: [RFC FIX v1 1/2] powerpc: Discover radix availability before scanning the memory nodes
From: Michael Ellerman @ 2018-01-05 23:28 UTC (permalink / raw)
To: Bharata B Rao, linuxppc-dev
Cc: nfont, aneesh.kumar, david, anton, Bharata B Rao
In-Reply-To: <1515150321-24894-2-git-send-email-bharata@linux.vnet.ibm.com>
Bharata B Rao <bharata@linux.vnet.ibm.com> writes:
> Currently device tree nodes for memory are scanned before the
> radix feature is discovered in mmu_early_init_devtree(). Move this
> routine ahead of scanning memory nodes so that we know if the
> guest is radix or not when scanning ibm,dynamic-reconfiguration-memory.
Sorry this doesn't work.
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index b15bae2..079d893 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -722,6 +722,8 @@ void __init early_init_devtree(void *params)
> */
> of_scan_flat_dt(early_init_dt_scan_chosen_ppc, boot_command_line);
>
> + mmu_early_init_devtree();
> +
You've moved this above parse_early_param(), but
mmu_early_init_devtree() uses disable_radix, which is an early param. So
this will break disable_radix handling.
It will probably break other things too because the ordering of this
init code is very fragile - bootstrapping is hard :)
> /* Scan memory nodes and rebuild MEMBLOCKs */
> of_scan_flat_dt(early_init_dt_scan_root, NULL);
> of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
> @@ -783,8 +785,6 @@ void __init early_init_devtree(void *params)
> spinning_secondaries = boot_cpu_count - 1;
> #endif
>
> - mmu_early_init_devtree();
> -
> #ifdef CONFIG_PPC_POWERNV
> /* Scan and build the list of machine check recoverable ranges */
> of_scan_flat_dt(early_init_dt_scan_recoverable_ranges, NULL);
cheers
^ permalink raw reply
* Re: [PATCH 09/67] arc: remove CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA
From: Vineet Gupta @ 2018-01-05 19:45 UTC (permalink / raw)
To: Christoph Hellwig, iommu@lists.linux-foundation.org
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Guan Xuetao,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org,
x86@kernel.org, linux-snps-arc@lists.infradead.org,
adi-buildroot-devel@lists.sourceforge.net,
linux-m68k@lists.linux-m68k.org, patches@groups.riscv.org,
linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Michal Simek, linux-parisc@vger.kernel.org,
linux-cris-kernel@axis.com, linux-kernel@vger.kernel.org,
linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20171229081911.2802-10-hch@lst.de>
On 12/29/2017 12:25 AM, Christoph Hellwig wrote:
> We always use the stub definitions, so remove the unused other code.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
FWIW, it was removed and reintroduced as one of the customers wanted it, which is
not relevant now !
Thx,
-Vineet
> ---
> arch/arc/Kconfig | 3 ---
> arch/arc/include/asm/dma-mapping.h | 7 -------
> arch/arc/mm/dma.c | 14 +++++++-------
> 3 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 9d5fd00d9e91..f3a80cf164cc 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -463,9 +463,6 @@ config ARCH_PHYS_ADDR_T_64BIT
> config ARCH_DMA_ADDR_T_64BIT
> bool
>
> -config ARC_PLAT_NEEDS_PHYS_TO_DMA
> - bool
> -
> config ARC_KVADDR_SIZE
> int "Kernel Virtual Address Space size (MB)"
> range 0 512
> diff --git a/arch/arc/include/asm/dma-mapping.h b/arch/arc/include/asm/dma-mapping.h
> index 94285031c4fb..7a16824bfe98 100644
> --- a/arch/arc/include/asm/dma-mapping.h
> +++ b/arch/arc/include/asm/dma-mapping.h
> @@ -11,13 +11,6 @@
> #ifndef ASM_ARC_DMA_MAPPING_H
> #define ASM_ARC_DMA_MAPPING_H
>
> -#ifndef CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA
> -#define plat_dma_to_phys(dev, dma_handle) ((phys_addr_t)(dma_handle))
> -#define plat_phys_to_dma(dev, paddr) ((dma_addr_t)(paddr))
> -#else
> -#include <plat/dma.h>
> -#endif
> -
> extern const struct dma_map_ops arc_dma_ops;
>
> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
> index fad18261ef6a..1d405b86250c 100644
> --- a/arch/arc/mm/dma.c
> +++ b/arch/arc/mm/dma.c
> @@ -60,7 +60,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
> /* This is linear addr (0x8000_0000 based) */
> paddr = page_to_phys(page);
>
> - *dma_handle = plat_phys_to_dma(dev, paddr);
> + *dma_handle = paddr;
>
> /* This is kernel Virtual address (0x7000_0000 based) */
> if (need_kvaddr) {
> @@ -92,7 +92,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
> static void arc_dma_free(struct device *dev, size_t size, void *vaddr,
> dma_addr_t dma_handle, unsigned long attrs)
> {
> - phys_addr_t paddr = plat_dma_to_phys(dev, dma_handle);
> + phys_addr_t paddr = dma_handle;
> struct page *page = virt_to_page(paddr);
> int is_non_coh = 1;
>
> @@ -111,7 +111,7 @@ static int arc_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> {
> unsigned long user_count = vma_pages(vma);
> unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - unsigned long pfn = __phys_to_pfn(plat_dma_to_phys(dev, dma_addr));
> + unsigned long pfn = __phys_to_pfn(dma_addr);
> unsigned long off = vma->vm_pgoff;
> int ret = -ENXIO;
>
> @@ -175,7 +175,7 @@ static dma_addr_t arc_dma_map_page(struct device *dev, struct page *page,
> if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> _dma_cache_sync(paddr, size, dir);
>
> - return plat_phys_to_dma(dev, paddr);
> + return paddr;
> }
>
> /*
> @@ -190,7 +190,7 @@ static void arc_dma_unmap_page(struct device *dev, dma_addr_t handle,
> size_t size, enum dma_data_direction dir,
> unsigned long attrs)
> {
> - phys_addr_t paddr = plat_dma_to_phys(dev, handle);
> + phys_addr_t paddr = handle;
>
> if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> _dma_cache_sync(paddr, size, dir);
> @@ -224,13 +224,13 @@ static void arc_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
> static void arc_dma_sync_single_for_cpu(struct device *dev,
> dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
> {
> - _dma_cache_sync(plat_dma_to_phys(dev, dma_handle), size, DMA_FROM_DEVICE);
> + _dma_cache_sync(dma_handle, size, DMA_FROM_DEVICE);
> }
>
> static void arc_dma_sync_single_for_device(struct device *dev,
> dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
> {
> - _dma_cache_sync(plat_dma_to_phys(dev, dma_handle), size, DMA_TO_DEVICE);
> + _dma_cache_sync(dma_handle, size, DMA_TO_DEVICE);
> }
>
> static void arc_dma_sync_sg_for_cpu(struct device *dev,
^ permalink raw reply
* Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Ard Biesheuvel @ 2018-01-05 18:29 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-mips, Benjamin Herrenschmidt, Will Deacon, Paul Mackerras,
H. Peter Anvin, sparclinux, linux-s390, Nicolas Pitre,
Michael Ellerman, the arch/x86 maintainers, Russell King,
Ingo Molnar, Serge E. Hallyn, Petr Mladek, Kees Cook,
Arnd Bergmann, Heiko Carstens, Steven Rostedt, James Morris,
Josh Poimboeuf, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Linus Torvalds, Linux Kernel Mailing List, Ralf Baechle,
David S. Miller, Sergey Senozhatsky, Jessica Yu,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, Thomas Garnier
In-Reply-To: <20180105182229.pjnlq3l5hzfac4na@armageddon.cambridge.arm.com>
On 5 January 2018 at 18:22, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Fri, Jan 05, 2018 at 06:01:33PM +0000, Ard Biesheuvel wrote:
>> On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
>> >> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
>> >> index e12d7d096fc0..7b05b404063a 100644
>> >> --- a/arch/arm/include/asm/jump_label.h
>> >> +++ b/arch/arm/include/asm/jump_label.h
>> >> @@ -45,5 +45,32 @@ struct jump_entry {
>> >> jump_label_t key;
>> >> };
>> >>
>> >> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
>> >> +{
>> >> + return entry->code;
>> >> +}
>> >> +
>> >> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
>> >> +{
>> >> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
>> >> +}
>> >> +
>> >> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
>> >> +{
>> >> + return (unsigned long)entry->key & 1UL;
>> >> +}
>> >> +
>> >> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
>> >> +{
>> >> + return entry->code == 0;
>> >> +}
>> >> +
>> >> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> >> +{
>> >> + entry->code = 0;
>> >> +}
>> >> +
>> >> +#define jump_label_swap NULL
>> >
>> > Is there any difference between these functions on any of the
>> > architectures touched? Even with the relative offset, arm64 and x86
>> > looked the same to me (well, I may have missed some detail).
>>
>> No, the latter two are identical everywhere, and the others are the
>> same modulo absolute vs relative.
>>
>> The issue is that the struct definition is per-arch so the accessors
>> should be as well.
>
> Up to this patch, even the jump_entry structure is the same on all
> architectures (the jump_label_t type differs).
>
> With relative offset, can you not just define jump_label_t to s32? At a
> quick grep in mainline, it doesn't seem to be used outside the structure
> definition.
>
I think we can just remove jump_label_t entirely, and replace it with
unsigned long for absolute, and s32 for relative. Maybe I am missing
something, but things like
#ifdef CONFIG_X86_64
typedef u64 jump_label_t;
#else
typedef u32 jump_label_t;
#endif
seem a bit pointless to me anyway.
>> Perhaps I should introduce two variants two asm-generic, similar to
>> how we have different flavors of unaligned accessors.
>
> You could as well define them directly in kernel/jump_label.h or, if
> used outside this file, include/linux/jump_label.h.
>
Perhaps I should define a Kconfig symbol after all for relative jump
labels, and just keep everything in the same file. The question is
whether I should use CONFIG_HAVE_ARCH_PREL32_RELOCATIONS for this as
well.
^ permalink raw reply
* Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Catalin Marinas @ 2018-01-05 18:22 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-mips, Benjamin Herrenschmidt, Will Deacon, Paul Mackerras,
H. Peter Anvin, sparclinux, linux-s390, Nicolas Pitre,
Michael Ellerman, the arch/x86 maintainers, Russell King,
Ingo Molnar, Serge E. Hallyn, Petr Mladek, Kees Cook,
Arnd Bergmann, Heiko Carstens, Steven Rostedt, James Morris,
Josh Poimboeuf, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Linus Torvalds, Linux Kernel Mailing List, Ralf Baechle,
David S. Miller, Sergey Senozhatsky, Jessica Yu,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, Thomas Garnier
In-Reply-To: <CAKv+Gu8zROE-TDpfbbVi3RPOr8BNcsN_s27Gr-VvMN+-eMU+Hg@mail.gmail.com>
On Fri, Jan 05, 2018 at 06:01:33PM +0000, Ard Biesheuvel wrote:
> On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
> >> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
> >> index e12d7d096fc0..7b05b404063a 100644
> >> --- a/arch/arm/include/asm/jump_label.h
> >> +++ b/arch/arm/include/asm/jump_label.h
> >> @@ -45,5 +45,32 @@ struct jump_entry {
> >> jump_label_t key;
> >> };
> >>
> >> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> >> +{
> >> + return entry->code;
> >> +}
> >> +
> >> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
> >> +{
> >> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
> >> +}
> >> +
> >> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
> >> +{
> >> + return (unsigned long)entry->key & 1UL;
> >> +}
> >> +
> >> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
> >> +{
> >> + return entry->code == 0;
> >> +}
> >> +
> >> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
> >> +{
> >> + entry->code = 0;
> >> +}
> >> +
> >> +#define jump_label_swap NULL
> >
> > Is there any difference between these functions on any of the
> > architectures touched? Even with the relative offset, arm64 and x86
> > looked the same to me (well, I may have missed some detail).
>
> No, the latter two are identical everywhere, and the others are the
> same modulo absolute vs relative.
>
> The issue is that the struct definition is per-arch so the accessors
> should be as well.
Up to this patch, even the jump_entry structure is the same on all
architectures (the jump_label_t type differs).
With relative offset, can you not just define jump_label_t to s32? At a
quick grep in mainline, it doesn't seem to be used outside the structure
definition.
> Perhaps I should introduce two variants two asm-generic, similar to
> how we have different flavors of unaligned accessors.
You could as well define them directly in kernel/jump_label.h or, if
used outside this file, include/linux/jump_label.h.
--
Catalin
^ permalink raw reply
* Re: [PATCH v4 2/7] linux/pci: Add uevents in AER and EEH error/resume
From: Bjorn Helgaas @ 2018-01-05 18:15 UTC (permalink / raw)
To: Bryant G. Ly
Cc: Benjamin Herrenschmidt, Paul Mackerras, mpe, seroyer, jjalvare,
alex.williamson, helgaas, aik, ruscur, linux-pci, linuxppc-dev,
bodong, eli, saeedm
In-Reply-To: <20180105164552.36371-3-bryantly@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4794 bytes --]
I doubt "linux/pci: " matches the powerpc convention and I know it doesn't
match the drivers/pci convention.
I'd suggest matching one or the other. In drivers/pci I would be using
"PCI/AER: ".
On Jan 5, 2018 10:46 AM, "Bryant G. Ly" <bryantly@linux.vnet.ibm.com> wrote:
> Devices can go offline when erors reported. This
> patch adds a change to the kernel object and lets udev
> know of error. When device resumes, a change is also set
> reporting device as online. Therefore, EEH and AER events
> are better propagated to user space for PCI devices in
> all arches.
>
> Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
> Signed-off-by: Juan J. Alvarez <jjalvare@linux.vnet.ibm.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> arch/powerpc/kernel/eeh_driver.c | 6 ++++++
> drivers/pci/pcie/aer/aerdrv_core.c | 3 +++
> include/linux/pci.h | 36 ++++++++++++++++++++++++++++++
> ++++++
> 3 files changed, 45 insertions(+)
>
> diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_
> driver.c
> index 3c0fa99c5533..beea2182d754 100644
> --- a/arch/powerpc/kernel/eeh_driver.c
> +++ b/arch/powerpc/kernel/eeh_driver.c
> @@ -228,6 +228,7 @@ static void *eeh_report_error(void *data, void
> *userdata)
>
> edev->in_error = true;
> eeh_pcid_put(dev);
> + pci_uevent_ers(dev, PCI_ERS_RESULT_NONE);
> return NULL;
> }
>
> @@ -381,6 +382,10 @@ static void *eeh_report_resume(void *data, void
> *userdata)
> driver->err_handler->resume(dev);
>
> eeh_pcid_put(dev);
> + pci_uevent_ers(dev, PCI_ERS_RESULT_RECOVERED);
> +#ifdef CONFIG_PCI_IOV
> + eeh_ops->notify_resume(eeh_dev_to_pdn(edev));
> +#endif
> return NULL;
> }
>
> @@ -416,6 +421,7 @@ static void *eeh_report_failure(void *data, void
> *userdata)
> driver->err_handler->error_detected(dev,
> pci_channel_io_perm_failure);
>
> eeh_pcid_put(dev);
> + pci_uevent_ers(dev, PCI_ERS_RESULT_DISCONNECT);
> return NULL;
> }
>
> diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
> b/drivers/pci/pcie/aer/aerdrv_core.c
> index 744805232155..8d7448063fd1 100644
> --- a/drivers/pci/pcie/aer/aerdrv_core.c
> +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> @@ -278,6 +278,7 @@ static int report_error_detected(struct pci_dev *dev,
> void *data)
> } else {
> err_handler = dev->driver->err_handler;
> vote = err_handler->error_detected(dev,
> result_data->state);
> + pci_uevent_ers(dev, PCI_ERS_RESULT_NONE);
> }
>
> result_data->result = merge_result(result_data->result, vote);
> @@ -341,6 +342,7 @@ static int report_resume(struct pci_dev *dev, void
> *data)
>
> err_handler = dev->driver->err_handler;
> err_handler->resume(dev);
> + pci_uevent_ers(dev, PCI_ERS_RESULT_RECOVERED);
> out:
> device_unlock(&dev->dev);
> return 0;
> @@ -541,6 +543,7 @@ static void do_recovery(struct pci_dev *dev, int
> severity)
> return;
>
> failed:
> + pci_uevent_ers(dev, PCI_ERS_RESULT_DISCONNECT);
> /* TODO: Should kernel panic here? */
> dev_info(&dev->dev, "AER: Device recovery failed\n");
> }
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index e3e94467687a..405630441b74 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2277,6 +2277,42 @@ 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);
> + }
> +}
> +
> /* provide the legacy pci_dma_* API */
> #include <linux/pci-dma-compat.h>
>
> --
> 2.14.3 (Apple Git-98)
>
>
[-- Attachment #2: Type: text/html, Size: 6227 bytes --]
^ permalink raw reply
* Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Ard Biesheuvel @ 2018-01-05 18:01 UTC (permalink / raw)
To: Catalin Marinas
Cc: Linux Kernel Mailing List, linux-mips, Benjamin Herrenschmidt,
Will Deacon, Paul Mackerras, H. Peter Anvin, sparclinux,
linux-s390, Nicolas Pitre, Michael Ellerman,
the arch/x86 maintainers, Russell King, Ingo Molnar,
Serge E. Hallyn, Petr Mladek, Kees Cook, Arnd Bergmann,
Heiko Carstens, Steven Rostedt, James Morris, Josh Poimboeuf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel, linuxppc-dev,
Ralf Baechle, Thomas Garnier, Sergey Senozhatsky, Jessica Yu,
Martin Schwidefsky, Andrew Morton, Linus Torvalds,
David S. Miller
In-Reply-To: <20180105175834.vqgpsme7itsdg54u@armageddon.cambridge.arm.com>
On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
>> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
>> index e12d7d096fc0..7b05b404063a 100644
>> --- a/arch/arm/include/asm/jump_label.h
>> +++ b/arch/arm/include/asm/jump_label.h
>> @@ -45,5 +45,32 @@ struct jump_entry {
>> jump_label_t key;
>> };
>>
>> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
>> +{
>> + return entry->code;
>> +}
>> +
>> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
>> +{
>> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
>> +}
>> +
>> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
>> +{
>> + return (unsigned long)entry->key & 1UL;
>> +}
>> +
>> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
>> +{
>> + return entry->code == 0;
>> +}
>> +
>> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> +{
>> + entry->code = 0;
>> +}
>> +
>> +#define jump_label_swap NULL
>
> Is there any difference between these functions on any of the
> architectures touched? Even with the relative offset, arm64 and x86
> looked the same to me (well, I may have missed some detail).
>
No, the latter two are identical everywhere, and the others are the
same modulo absolute vs relative.
The issue is that the struct definition is per-arch so the accessors
should be as well. Perhaps I should introduce two variants two
asm-generic, similar to how we have different flavors of unaligned
accessors.
^ permalink raw reply
* Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Catalin Marinas @ 2018-01-05 17:58 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-kernel, linux-mips, Benjamin Herrenschmidt, Will Deacon,
Paul Mackerras, H. Peter Anvin, sparclinux, linux-s390,
Nicolas Pitre, Michael Ellerman, x86, Russell King, Ingo Molnar,
Serge E. Hallyn, Petr Mladek, Kees Cook, Arnd Bergmann,
Heiko Carstens, Steven Rostedt, James Morris, Josh Poimboeuf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel, linuxppc-dev,
Ralf Baechle, Thomas Garnier, Sergey Senozhatsky, Jessica Yu,
Martin Schwidefsky, Andrew Morton, Linus Torvalds,
David S. Miller
In-Reply-To: <20180102200549.22984-8-ard.biesheuvel@linaro.org>
On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
> index e12d7d096fc0..7b05b404063a 100644
> --- a/arch/arm/include/asm/jump_label.h
> +++ b/arch/arm/include/asm/jump_label.h
> @@ -45,5 +45,32 @@ struct jump_entry {
> jump_label_t key;
> };
>
> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> +{
> + return entry->code;
> +}
> +
> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
> +{
> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
> +}
> +
> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
> +{
> + return (unsigned long)entry->key & 1UL;
> +}
> +
> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
> +{
> + return entry->code == 0;
> +}
> +
> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
> +{
> + entry->code = 0;
> +}
> +
> +#define jump_label_swap NULL
Is there any difference between these functions on any of the
architectures touched? Even with the relative offset, arm64 and x86
looked the same to me (well, I may have missed some detail).
--
Catalin
^ permalink raw reply
* Re: [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables
From: Ard Biesheuvel @ 2018-01-05 17:45 UTC (permalink / raw)
To: Catalin Marinas
Cc: Linux Kernel Mailing List, linux-mips, Benjamin Herrenschmidt,
Will Deacon, Paul Mackerras, H. Peter Anvin, sparclinux,
linux-s390, Nicolas Pitre, Michael Ellerman,
the arch/x86 maintainers, Russell King, Ingo Molnar,
Serge E. Hallyn, Petr Mladek, Kees Cook, Arnd Bergmann,
Heiko Carstens, Steven Rostedt, James Morris, Josh Poimboeuf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel, linuxppc-dev,
Ralf Baechle, Thomas Garnier, Sergey Senozhatsky, Jessica Yu,
Martin Schwidefsky, Andrew Morton, Linus Torvalds,
David S. Miller
In-Reply-To: <20180105174112.jk3mvo5qwg7l4vzo@armageddon.cambridge.arm.com>
On 5 January 2018 at 17:41, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Jan 02, 2018 at 08:05:44PM +0000, Ard Biesheuvel wrote:
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 10684b17d0bd..b6d51b4d5ce1 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
>> f->vendor == (u16) PCI_ANY_ID) &&
>> (f->device == dev->device ||
>> f->device == (u16) PCI_ANY_ID)) {
>> - calltime = fixup_debug_start(dev, f->hook);
>> - f->hook(dev);
>> - fixup_debug_report(dev, calltime, f->hook);
>> + void (*hook)(struct pci_dev *dev);
>> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
>> + hook = (void *)((unsigned long)&f->hook_offset +
>> + f->hook_offset);
>> +#else
>> + hook = f->hook;
>> +#endif
>
> More of a nitpick but I've seen this pattern in several places in your
> code, maybe worth defining a macro (couldn't come up with a better
> name):
>
> #define offset_to_ptr(off) \
> ((void *)((unsigned long)&(off) + (off)))
>
Yeah, good point. Or even
static inline void *offset_to_ptr(const s32 *off)
{
return (void *)((unsigned long)off + *off);
}
^ permalink raw reply
* Re: [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables
From: Catalin Marinas @ 2018-01-05 17:41 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-kernel, linux-mips, Benjamin Herrenschmidt, Will Deacon,
Paul Mackerras, H. Peter Anvin, sparclinux, linux-s390,
Nicolas Pitre, Michael Ellerman, x86, Russell King, Ingo Molnar,
Serge E. Hallyn, Petr Mladek, Kees Cook, Arnd Bergmann,
Heiko Carstens, Steven Rostedt, James Morris, Josh Poimboeuf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel, linuxppc-dev,
Ralf Baechle, Thomas Garnier, Sergey Senozhatsky, Jessica Yu,
Martin Schwidefsky, Andrew Morton, Linus Torvalds,
David S. Miller
In-Reply-To: <20180102200549.22984-6-ard.biesheuvel@linaro.org>
On Tue, Jan 02, 2018 at 08:05:44PM +0000, Ard Biesheuvel wrote:
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 10684b17d0bd..b6d51b4d5ce1 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
> f->vendor == (u16) PCI_ANY_ID) &&
> (f->device == dev->device ||
> f->device == (u16) PCI_ANY_ID)) {
> - calltime = fixup_debug_start(dev, f->hook);
> - f->hook(dev);
> - fixup_debug_report(dev, calltime, f->hook);
> + void (*hook)(struct pci_dev *dev);
> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> + hook = (void *)((unsigned long)&f->hook_offset +
> + f->hook_offset);
> +#else
> + hook = f->hook;
> +#endif
More of a nitpick but I've seen this pattern in several places in your
code, maybe worth defining a macro (couldn't come up with a better
name):
#define offset_to_ptr(off) \
((void *)((unsigned long)&(off) + (off)))
--
Catalin
^ permalink raw reply
* [PATCH v4 4/7] powerpc/kernel Add EEH operations to notify resume
From: Bryant G. Ly @ 2018-01-05 16:45 UTC (permalink / raw)
To: benh, paulus, mpe
Cc: seroyer, jjalvare, alex.williamson, helgaas, aik, ruscur,
linux-pci, linuxppc-dev, bodong, eli, saeedm, Bryant G. Ly
In-Reply-To: <20180105164552.36371-1-bryantly@linux.vnet.ibm.com>
When pseries SR-IOV is enabled and after a PF driver
has resumed from EEH, platform has to be notified
of the event so the child VFs can be allowed to
resume their normal recovery path.
This patch makes the EEH operation allow unfreeze
platform dependent code and adds the call to
pseries EEH code.
Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Signed-off-by: Juan J. Alvarez <jjalvare@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/powernv/eeh-powernv.c | 3 +-
arch/powerpc/platforms/pseries/eeh_pseries.c | 96 +++++++++++++++++++++++++++-
3 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 82829c65f31a..fd37cc101f4f 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -214,6 +214,7 @@ struct eeh_ops {
int (*write_config)(struct pci_dn *pdn, int where, int size, u32 val);
int (*next_error)(struct eeh_pe **pe);
int (*restore_config)(struct pci_dn *pdn);
+ int (*notify_resume)(struct pci_dn *pdn);
};
extern int eeh_subsystem_flags;
diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c b/arch/powerpc/platforms/powernv/eeh-powernv.c
index 0665b6d03cb3..33c86c1a1720 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -1704,7 +1704,8 @@ static struct eeh_ops pnv_eeh_ops = {
.read_config = pnv_eeh_read_config,
.write_config = pnv_eeh_write_config,
.next_error = pnv_eeh_next_error,
- .restore_config = pnv_eeh_restore_config
+ .restore_config = pnv_eeh_restore_config,
+ .notify_resume = NULL
};
#ifdef CONFIG_PCI_IOV
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
index ca6bbfd83701..898bb055cb19 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -749,6 +749,97 @@ static int pseries_eeh_restore_config(struct pci_dn *pdn)
return ret;
}
+#ifdef CONFIG_PCI_IOV
+int pseries_send_allow_unfreeze(struct pci_dn *pdn,
+ u16 *vf_pe_array, int cur_vfs)
+{
+ int rc;
+ int ibm_allow_unfreeze = rtas_token("ibm,open-sriov-allow-unfreeze");
+ unsigned long buid, addr;
+
+ addr = rtas_config_addr(pdn->busno, pdn->devfn, 0);
+ buid = pdn->phb->buid;
+ spin_lock(&rtas_data_buf_lock);
+ memcpy(rtas_data_buf, vf_pe_array, RTAS_DATA_BUF_SIZE);
+ rc = rtas_call(ibm_allow_unfreeze, 5, 1, NULL,
+ addr,
+ BUID_HI(buid),
+ BUID_LO(buid),
+ rtas_data_buf, cur_vfs * sizeof(u16));
+ spin_unlock(&rtas_data_buf_lock);
+ if (rc)
+ pr_warn("%s: Failed to allow unfreeze for PHB#%x-PE#%lx, rc=%x\n",
+ __func__,
+ pdn->phb->global_number, addr, rc);
+ return rc;
+}
+
+static int pseries_call_allow_unfreeze(struct eeh_dev *edev)
+{
+ struct pci_dn *pdn, *tmp, *parent, *physfn_pdn;
+ int cur_vfs = 0, rc = 0, vf_index, bus, devfn;
+ u16 *vf_pe_array;
+
+ vf_pe_array = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
+ if (!vf_pe_array)
+ return -ENOMEM;
+ if (pci_num_vf(edev->physfn ? edev->physfn : edev->pdev)) {
+ if (edev->pdev->is_physfn) {
+ cur_vfs = pci_num_vf(edev->pdev);
+ pdn = eeh_dev_to_pdn(edev);
+ parent = pdn->parent;
+ for (vf_index = 0; vf_index < cur_vfs; vf_index++)
+ vf_pe_array[vf_index] =
+ cpu_to_be16(pdn->pe_num_map[vf_index]);
+ rc = pseries_send_allow_unfreeze(pdn, vf_pe_array,
+ cur_vfs);
+ pdn->last_allow_rc = rc;
+ for (vf_index = 0; vf_index < cur_vfs; vf_index++) {
+ list_for_each_entry_safe(pdn, tmp,
+ &parent->child_list,
+ list) {
+ bus = pci_iov_virtfn_bus(edev->pdev,
+ vf_index);
+ devfn = pci_iov_virtfn_devfn(edev->pdev,
+ vf_index);
+ if (pdn->busno != bus ||
+ pdn->devfn != devfn)
+ continue;
+ pdn->last_allow_rc = rc;
+ }
+ }
+ } else {
+ pdn = pci_get_pdn(edev->pdev);
+ vf_pe_array[0] = cpu_to_be16(pdn->pe_number);
+ physfn_pdn = pci_get_pdn(edev->physfn);
+ rc = pseries_send_allow_unfreeze(physfn_pdn,
+ vf_pe_array, 1);
+ pdn->last_allow_rc = rc;
+ }
+ }
+
+ kfree(vf_pe_array);
+ return rc;
+}
+
+static int pseries_notify_resume(struct pci_dn *pdn)
+{
+ struct eeh_dev *edev = pdn_to_eeh_dev(pdn);
+
+ if (!edev)
+ return -EEXIST;
+
+ if (rtas_token("ibm,open-sriov-allow-unfreeze")
+ == RTAS_UNKNOWN_SERVICE)
+ return -EINVAL;
+
+ if (edev->pdev->is_physfn || edev->pdev->is_virtfn)
+ return pseries_call_allow_unfreeze(edev);
+
+ return 0;
+}
+#endif
+
static struct eeh_ops pseries_eeh_ops = {
.name = "pseries",
.init = pseries_eeh_init,
@@ -764,7 +855,10 @@ static struct eeh_ops pseries_eeh_ops = {
.read_config = pseries_eeh_read_config,
.write_config = pseries_eeh_write_config,
.next_error = NULL,
- .restore_config = pseries_eeh_restore_config
+ .restore_config = pseries_eeh_restore_config,
+#ifdef CONFIG_PCI_IOV
+ .notify_resume = pseries_notify_resume
+#endif
};
/**
--
2.14.3 (Apple Git-98)
^ permalink raw reply related
* [PATCH v4 6/7] pseries/pci: Associate PEs to VFs in configure SR-IOV
From: Bryant G. Ly @ 2018-01-05 16:45 UTC (permalink / raw)
To: benh, paulus, mpe
Cc: seroyer, jjalvare, alex.williamson, helgaas, aik, ruscur,
linux-pci, linuxppc-dev, bodong, eli, saeedm, Bryant G. Ly
In-Reply-To: <20180105164552.36371-1-bryantly@linux.vnet.ibm.com>
After initial validation of SR-IOV resources, firmware will
associate PEs to the dynamic VFs created within this call. This
patch adds the association of PEs to the PF array of PE numbers
indexed by VF.
Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Signed-off-by: Juan J. Alvarez <jjalvare@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/pci.c | 150 ++++++++++++++++++++++++++++++++++-
1 file changed, 148 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pci.c b/arch/powerpc/platforms/pseries/pci.c
index 48d3af026f90..eab96637d6cf 100644
--- a/arch/powerpc/platforms/pseries/pci.c
+++ b/arch/powerpc/platforms/pseries/pci.c
@@ -59,16 +59,162 @@ DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pcibios_name_device);
#endif
#ifdef CONFIG_PCI_IOV
+#define MAX_VFS_FOR_MAP_PE 256
+struct pe_map_bar_entry {
+ __be64 bar; /* Input: Virtual Function BAR */
+ __be16 rid; /* Input: Virtual Function Router ID */
+ __be16 pe_num; /* Output: Virtual Function PE Number */
+ __be32 reserved; /* Reserved Space */
+};
+
+int pseries_send_map_pe(struct pci_dev *pdev,
+ u16 num_vfs,
+ struct pe_map_bar_entry *vf_pe_array)
+{
+ struct pci_dn *pdn;
+ int rc;
+ unsigned long buid, addr;
+ int ibm_map_pes = rtas_token("ibm,open-sriov-map-pe-number");
+
+ if (ibm_map_pes == RTAS_UNKNOWN_SERVICE)
+ return -EINVAL;
+
+ pdn = pci_get_pdn(pdev);
+ addr = rtas_config_addr(pdn->busno, pdn->devfn, 0);
+ buid = pdn->phb->buid;
+ spin_lock(&rtas_data_buf_lock);
+ memcpy(rtas_data_buf, vf_pe_array,
+ RTAS_DATA_BUF_SIZE);
+ rc = rtas_call(ibm_map_pes, 5, 1, NULL, addr,
+ BUID_HI(buid), BUID_LO(buid),
+ rtas_data_buf,
+ num_vfs * sizeof(struct pe_map_bar_entry));
+ memcpy(vf_pe_array, rtas_data_buf, RTAS_DATA_BUF_SIZE);
+ spin_unlock(&rtas_data_buf_lock);
+
+ if (rc)
+ dev_err(&pdev->dev,
+ "%s: Failed to associate pes PE#%lx, rc=%x\n",
+ __func__, addr, rc);
+
+ return rc;
+}
+
+void pseries_set_pe_num(struct pci_dev *pdev, u16 vf_index, __be16 pe_num)
+{
+ struct pci_dn *pdn;
+
+ pdn = pci_get_pdn(pdev);
+ pdn->pe_num_map[vf_index] = be16_to_cpu(pe_num);
+ dev_dbg(&pdev->dev, "VF %04x:%02x:%02x.%x associated with PE#%x\n",
+ pci_domain_nr(pdev->bus),
+ pdev->bus->number,
+ PCI_SLOT(pci_iov_virtfn_devfn(pdev, vf_index)),
+ PCI_FUNC(pci_iov_virtfn_devfn(pdev, vf_index)),
+ pdn->pe_num_map[vf_index]);
+}
+
+int pseries_associate_pes(struct pci_dev *pdev, u16 num_vfs)
+{
+ struct pci_dn *pdn;
+ int i, rc, vf_index;
+ struct pe_map_bar_entry *vf_pe_array;
+ struct resource *res;
+ u64 size;
+
+ vf_pe_array = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
+ if (!vf_pe_array)
+ return -ENOMEM;
+
+ pdn = pci_get_pdn(pdev);
+ /* create firmware structure to associate pes */
+ for (vf_index = 0; vf_index < num_vfs; vf_index++) {
+ pdn->pe_num_map[vf_index] = IODA_INVALID_PE;
+ for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
+ res = &pdev->resource[i + PCI_IOV_RESOURCES];
+ if (!res->parent)
+ continue;
+ size = pcibios_iov_resource_alignment(pdev, i +
+ PCI_IOV_RESOURCES);
+ vf_pe_array[vf_index].bar =
+ cpu_to_be64(res->start + size * vf_index);
+ vf_pe_array[vf_index].rid =
+ cpu_to_be16((pci_iov_virtfn_bus(pdev, vf_index)
+ << 8) | pci_iov_virtfn_devfn(pdev,
+ vf_index));
+ vf_pe_array[vf_index].pe_num =
+ cpu_to_be16(IODA_INVALID_PE);
+ }
+ }
+
+ rc = pseries_send_map_pe(pdev, num_vfs, vf_pe_array);
+ /* Only zero is success */
+ if (!rc)
+ for (vf_index = 0; vf_index < num_vfs; vf_index++)
+ pseries_set_pe_num(pdev, vf_index,
+ vf_pe_array[vf_index].pe_num);
+
+ kfree(vf_pe_array);
+ return rc;
+}
+
+int pseries_pci_sriov_enable(struct pci_dev *pdev, u16 num_vfs)
+{
+ struct pci_dn *pdn;
+ int rc;
+ const int *max_vfs;
+ int max_config_vfs;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
+
+ max_vfs = of_get_property(dn, "ibm,number-of-configurable-vfs", NULL);
+
+ if (!max_vfs)
+ return -EINVAL;
+
+ /* First integer stores max config */
+ max_config_vfs = of_read_number(&max_vfs[0], 1);
+ if (max_config_vfs < num_vfs && num_vfs > MAX_VFS_FOR_MAP_PE) {
+ dev_err(&pdev->dev,
+ "Num VFs %x > %x Configurable VFs\n",
+ num_vfs, (num_vfs > MAX_VFS_FOR_MAP_PE) ?
+ MAX_VFS_FOR_MAP_PE : max_config_vfs);
+ return -EINVAL;
+ }
+
+ pdn = pci_get_pdn(pdev);
+ pdn->pe_num_map = kmalloc_array(num_vfs,
+ sizeof(*pdn->pe_num_map),
+ GFP_KERNEL);
+ if (!pdn->pe_num_map)
+ return -ENOMEM;
+
+ rc = pseries_associate_pes(pdev, num_vfs);
+
+ /* Anything other than zero is failure */
+ if (rc) {
+ dev_err(&pdev->dev, "Failure to enable sriov: %x\n", rc);
+ kfree(pdn->pe_num_map);
+ } else {
+ pci_vf_drivers_autoprobe(pdev, false);
+ }
+
+ return rc;
+}
+
int pseries_pcibios_sriov_enable(struct pci_dev *pdev, u16 num_vfs)
{
/* Allocate PCI data */
add_dev_pci_data(pdev);
- pci_vf_drivers_autoprobe(pdev, false);
- return 0;
+ return pseries_pci_sriov_enable(pdev, num_vfs);
}
int pseries_pcibios_sriov_disable(struct pci_dev *pdev)
{
+ struct pci_dn *pdn;
+
+ pdn = pci_get_pdn(pdev);
+ /* Releasing pe_num_map */
+ kfree(pdn->pe_num_map);
/* Release PCI data */
remove_dev_pci_data(pdev);
pci_vf_drivers_autoprobe(pdev, true);
--
2.14.3 (Apple Git-98)
^ permalink raw reply related
* [PATCH v4 2/7] linux/pci: Add uevents in AER and EEH error/resume
From: Bryant G. Ly @ 2018-01-05 16:45 UTC (permalink / raw)
To: benh, paulus, mpe
Cc: seroyer, jjalvare, alex.williamson, helgaas, aik, ruscur,
linux-pci, linuxppc-dev, bodong, eli, saeedm, Bryant G. Ly
In-Reply-To: <20180105164552.36371-1-bryantly@linux.vnet.ibm.com>
Devices can go offline when erors reported. This
patch adds a change to the kernel object and lets udev
know of error. When device resumes, a change is also set
reporting device as online. Therefore, EEH and AER events
are better propagated to user space for PCI devices in
all arches.
Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Signed-off-by: Juan J. Alvarez <jjalvare@linux.vnet.ibm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
arch/powerpc/kernel/eeh_driver.c | 6 ++++++
drivers/pci/pcie/aer/aerdrv_core.c | 3 +++
include/linux/pci.h | 36 ++++++++++++++++++++++++++++++++++++
3 files changed, 45 insertions(+)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 3c0fa99c5533..beea2182d754 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -228,6 +228,7 @@ static void *eeh_report_error(void *data, void *userdata)
edev->in_error = true;
eeh_pcid_put(dev);
+ pci_uevent_ers(dev, PCI_ERS_RESULT_NONE);
return NULL;
}
@@ -381,6 +382,10 @@ static void *eeh_report_resume(void *data, void *userdata)
driver->err_handler->resume(dev);
eeh_pcid_put(dev);
+ pci_uevent_ers(dev, PCI_ERS_RESULT_RECOVERED);
+#ifdef CONFIG_PCI_IOV
+ eeh_ops->notify_resume(eeh_dev_to_pdn(edev));
+#endif
return NULL;
}
@@ -416,6 +421,7 @@ static void *eeh_report_failure(void *data, void *userdata)
driver->err_handler->error_detected(dev, pci_channel_io_perm_failure);
eeh_pcid_put(dev);
+ pci_uevent_ers(dev, PCI_ERS_RESULT_DISCONNECT);
return NULL;
}
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c
index 744805232155..8d7448063fd1 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -278,6 +278,7 @@ static int report_error_detected(struct pci_dev *dev, void *data)
} else {
err_handler = dev->driver->err_handler;
vote = err_handler->error_detected(dev, result_data->state);
+ pci_uevent_ers(dev, PCI_ERS_RESULT_NONE);
}
result_data->result = merge_result(result_data->result, vote);
@@ -341,6 +342,7 @@ static int report_resume(struct pci_dev *dev, void *data)
err_handler = dev->driver->err_handler;
err_handler->resume(dev);
+ pci_uevent_ers(dev, PCI_ERS_RESULT_RECOVERED);
out:
device_unlock(&dev->dev);
return 0;
@@ -541,6 +543,7 @@ static void do_recovery(struct pci_dev *dev, int severity)
return;
failed:
+ pci_uevent_ers(dev, PCI_ERS_RESULT_DISCONNECT);
/* TODO: Should kernel panic here? */
dev_info(&dev->dev, "AER: Device recovery failed\n");
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e3e94467687a..405630441b74 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2277,6 +2277,42 @@ 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);
+ }
+}
+
/* provide the legacy pci_dma_* API */
#include <linux/pci-dma-compat.h>
--
2.14.3 (Apple Git-98)
^ permalink raw reply related
* [PATCH v4 7/7] pseries/setup: Add Initialization of VF Bars
From: Bryant G. Ly @ 2018-01-05 16:45 UTC (permalink / raw)
To: benh, paulus, mpe
Cc: seroyer, jjalvare, alex.williamson, helgaas, aik, ruscur,
linux-pci, linuxppc-dev, bodong, eli, saeedm, Bryant G. Ly
In-Reply-To: <20180105164552.36371-1-bryantly@linux.vnet.ibm.com>
When enabling SR-IOV in pseries platform,
the VF bar properties for a PF are reported on
the device node in the device tree.
This patch adds the IOV Bar resources to Linux
structures from the device tree for later use
when configuring SR-IOV by PF driver.
Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Signed-off-by: Juan J. Alvarez <jjalvare@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/pci.h | 2 +
arch/powerpc/kernel/pci_of_scan.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 164 +++++++++++++++++++++++++++++++++
3 files changed, 167 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 8dc32eacc97c..d82802ff5088 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -121,6 +121,8 @@ extern int remove_phb_dynamic(struct pci_controller *phb);
extern struct pci_dev *of_create_pci_dev(struct device_node *node,
struct pci_bus *bus, int devfn);
+extern unsigned int pci_parse_of_flags(u32 addr0, int bridge);
+
extern void of_scan_pci_bridge(struct pci_dev *dev);
extern void of_scan_bus(struct device_node *node, struct pci_bus *bus);
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 0d790f8432d2..20ceec4a5f5e 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -38,7 +38,7 @@ static u32 get_int_prop(struct device_node *np, const char *name, u32 def)
* @addr0: value of 1st cell of a device tree PCI address.
* @bridge: Set this flag if the address is from a bridge 'ranges' property
*/
-static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
+unsigned int pci_parse_of_flags(u32 addr0, int bridge)
{
unsigned int flags = 0;
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 1d6e2de2445c..e8f523cb5526 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -459,6 +459,162 @@ static void __init find_and_init_phbs(void)
of_pci_check_probe_only();
}
+#ifdef CONFIG_PCI_IOV
+enum rtas_iov_fw_value_map {
+ NUM_RES_PROPERTY = 0, /* Number of Resources */
+ LOW_INT = 1, /* Lowest 32 bits of Address */
+ START_OF_ENTRIES = 2, /* Always start of entry */
+ APERTURE_PROPERTY = 2, /* Start of entry+ to Aperture Size */
+ WDW_SIZE_PROPERTY = 4, /* Start of entry+ to Window Size */
+ NEXT_ENTRY = 7 /* Go to next entry on array */
+};
+
+enum get_iov_fw_value_index {
+ BAR_ADDRS = 1, /* Get Bar Address */
+ APERTURE_SIZE = 2, /* Get Aperture Size */
+ WDW_SIZE = 3 /* Get Window Size */
+};
+
+resource_size_t pseries_get_iov_fw_value(struct pci_dev *dev, int resno,
+ enum get_iov_fw_value_index value)
+{
+ const int *indexes;
+ struct device_node *dn = pci_device_to_OF_node(dev);
+ int i, num_res, ret = 0;
+
+ indexes = of_get_property(dn, "ibm,open-sriov-vf-bar-info", NULL);
+ if (!indexes)
+ return 0;
+
+ /*
+ * First element in the array is the number of Bars
+ * returned. Search through the list to find the matching
+ * bar
+ */
+ num_res = of_read_number(&indexes[NUM_RES_PROPERTY], 1);
+ if (resno >= num_res)
+ return 0; /* or an errror */
+
+ i = START_OF_ENTRIES + NEXT_ENTRY * resno;
+ switch (value) {
+ case BAR_ADDRS:
+ ret = of_read_number(&indexes[i], 2);
+ break;
+ case APERTURE_SIZE:
+ ret = of_read_number(&indexes[i + APERTURE_PROPERTY], 2);
+ break;
+ case WDW_SIZE:
+ ret = of_read_number(&indexes[i + WDW_SIZE_PROPERTY], 2);
+ break;
+ }
+
+ return ret;
+}
+
+void of_pci_set_vf_bar_size(struct pci_dev *dev, const int *indexes)
+{
+ struct resource *res;
+ resource_size_t base, size;
+ int i, r, num_res;
+
+ num_res = of_read_number(&indexes[NUM_RES_PROPERTY], 1);
+ num_res = min_t(int, num_res, PCI_SRIOV_NUM_BARS);
+ for (i = START_OF_ENTRIES, r = 0; r < num_res && r < PCI_SRIOV_NUM_BARS;
+ i += NEXT_ENTRY, r++) {
+ res = &dev->resource[r + PCI_IOV_RESOURCES];
+ base = of_read_number(&indexes[i], 2);
+ size = of_read_number(&indexes[i + APERTURE_PROPERTY], 2);
+ res->flags = pci_parse_of_flags(of_read_number
+ (&indexes[i + LOW_INT], 1), 0);
+ res->flags |= (IORESOURCE_MEM_64 | IORESOURCE_PCI_FIXED);
+ res->name = pci_name(dev);
+ res->start = base;
+ res->end = base + size - 1;
+ }
+}
+
+void of_pci_parse_iov_addrs(struct pci_dev *dev, const int *indexes)
+{
+ struct resource *res, *root, *conflict;
+ resource_size_t base, size;
+ int i, r, num_res;
+
+ /*
+ * First element in the array is the number of Bars
+ * returned. Search through the list to find the matching
+ * bars assign them from firmware into resources structure.
+ */
+ num_res = of_read_number(&indexes[NUM_RES_PROPERTY], 1);
+ for (i = START_OF_ENTRIES, r = 0; r < num_res && r < PCI_SRIOV_NUM_BARS;
+ i += NEXT_ENTRY, r++) {
+ res = &dev->resource[r + PCI_IOV_RESOURCES];
+ base = of_read_number(&indexes[i], 2);
+ size = of_read_number(&indexes[i + WDW_SIZE_PROPERTY], 2);
+ res->name = pci_name(dev);
+ res->start = base;
+ res->end = base + size - 1;
+ root = &iomem_resource;
+ dev_dbg(&dev->dev,
+ "pSeries IOV BAR %d: trying firmware assignment %pR\n",
+ r + PCI_IOV_RESOURCES, res);
+ conflict = request_resource_conflict(root, res);
+ if (conflict) {
+ dev_info(&dev->dev,
+ "BAR %d: %pR conflicts with %s %pR\n",
+ r + PCI_IOV_RESOURCES, res,
+ conflict->name, conflict);
+ res->flags |= IORESOURCE_UNSET;
+ }
+ }
+}
+
+static void pseries_pci_fixup_resources(struct pci_dev *pdev)
+{
+ const int *indexes;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
+
+ /*Firmware must support open sriov otherwise dont configure*/
+ indexes = of_get_property(dn, "ibm,open-sriov-vf-bar-info", NULL);
+ if (!indexes)
+ return;
+ /* Assign the addresses from device tree*/
+ of_pci_set_vf_bar_size(pdev, indexes);
+}
+
+static void pseries_pci_fixup_iov_resources(struct pci_dev *pdev)
+{
+ const int *indexes;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
+
+ if (!pdev->is_physfn || pdev->is_added)
+ return;
+ /*Firmware must support open sriov otherwise dont configure*/
+ indexes = of_get_property(dn, "ibm,open-sriov-vf-bar-info", NULL);
+ if (!indexes)
+ return;
+ /* Assign the addresses from device tree*/
+ of_pci_parse_iov_addrs(pdev, indexes);
+}
+
+static resource_size_t pseries_pci_iov_resource_alignment(struct pci_dev *pdev,
+ int resno)
+{
+ const __be32 *reg;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
+
+ /*Firmware must support open sriov otherwise report regular alignment*/
+ reg = of_get_property(dn, "ibm,is-open-sriov-pf", NULL);
+ if (!reg)
+ return pci_iov_resource_size(pdev, resno);
+
+ if (!pdev->is_physfn)
+ return 0;
+ return pseries_get_iov_fw_value(pdev,
+ resno - PCI_IOV_RESOURCES,
+ APERTURE_SIZE);
+}
+#endif
+
static void __init pSeries_setup_arch(void)
{
set_arch_panic_timeout(10, ARCH_PANIC_TIMEOUT);
@@ -490,6 +646,14 @@ static void __init pSeries_setup_arch(void)
vpa_init(boot_cpuid);
ppc_md.power_save = pseries_lpar_idle;
ppc_md.enable_pmcs = pseries_lpar_enable_pmcs;
+#ifdef CONFIG_PCI_IOV
+ ppc_md.pcibios_fixup_resources =
+ pseries_pci_fixup_resources;
+ ppc_md.pcibios_fixup_sriov =
+ pseries_pci_fixup_iov_resources;
+ ppc_md.pcibios_iov_resource_alignment =
+ pseries_pci_iov_resource_alignment;
+#endif
} else {
/* No special idle routine */
ppc_md.enable_pmcs = power4_enable_pmcs;
--
2.14.3 (Apple Git-98)
^ 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