* Re: [PATCH 2/6] cxlflash: Update cxl-specific arguments to generic cookie
From: Matthew R. Ochs @ 2018-01-07 19:40 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1515020065-43649-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Wed, Jan 03, 2018 at 04:54:25PM -0600, Uma Krishnan wrote:
> Convert cxl-specific pointers to generic cookies to facilitate future
> enhancements.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 1/6] cxlflash: Reset command ioasc
From: Matthew R. Ochs @ 2018-01-07 19:36 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Uma Krishnan, linux-scsi, James Bottomley, Martin K. Petersen,
Manoj N. Kumar, linuxppc-dev, Frederic Barrat, Christophe Lombard
In-Reply-To: <be8c1d08-f78a-a7f0-d912-e638646db80e@au1.ibm.com>
On Thu, Jan 04, 2018 at 05:33:48PM +1100, Andrew Donnellan wrote:
> On 04/01/18 09:54, Uma Krishnan wrote:
> >In the event of a command failure, cxlflash returns the failure to the
> >upper layers to process. After processing the error, when the command is
> >queued again, the private command structure will not be zeroed and the
> >ioasc could be stale. Per the SISLite specification, the AFU only sets the
> >ioasc in the presence of a failure. Thus, even though the original command
> >succeeds the second time, the command is considered a failure due to stale
> >ioasc. This cycle repeats indefinitely and can cause a hang or IO failure.
> >
> >To fix the issue, clear the ioasc before queuing any command.
> >
> >Fixes: 479ad8e9d48c ("scsi: cxlflash: Remove zeroing of private command
> >data")
> >Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
>
> Should this go to stable?
Not a bad idea.
^ permalink raw reply
* Re: [PATCH 1/6] cxlflash: Reset command ioasc
From: Matthew R. Ochs @ 2018-01-07 19:27 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1515020042-43590-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Wed, Jan 03, 2018 at 04:54:02PM -0600, Uma Krishnan wrote:
> In the event of a command failure, cxlflash returns the failure to the
> upper layers to process. After processing the error, when the command is
> queued again, the private command structure will not be zeroed and the
> ioasc could be stale. Per the SISLite specification, the AFU only sets the
> ioasc in the presence of a failure. Thus, even though the original command
> succeeds the second time, the command is considered a failure due to stale
> ioasc. This cycle repeats indefinitely and can cause a hang or IO failure.
>
> To fix the issue, clear the ioasc before queuing any command.
>
> Fixes: 479ad8e9d48c ("scsi: cxlflash: Remove zeroing of private command
> data")
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: Spectre+Meltdown
From: Olof Johansson @ 2018-01-07 18:54 UTC (permalink / raw)
To: Christian Zigotzky; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <86eade29-a56d-2aab-050e-366f4d43ab2f@xenosoft.de>
On Sun, Jan 7, 2018 at 5:04 AM, Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
> Hello Michael,
>
> Thanks for your reply. We are using P.A. Semi and Freescale CPUs.
>
> @Olof
> Do you have some infos for us?
I'm low on spare time to experiment and explore what might be exposed
or not, and I no longer have any proprietary microarchitecture
documentation of the core.
I suggest reaching out to your supplier of the silicon for commercial
support and information, or just going with what I'm sure will be
architecturally generic solutions to the problem when IBM has them
ready.
-Olof
^ permalink raw reply
* 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
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