* Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem
From: Patrice CHOTARD @ 2018-02-21 12:34 UTC (permalink / raw)
To: Marcus Folkesson, Wim Van Sebroeck, Guenter Roeck, Joel Stanley,
Nicolas Ferre, Alexandre Belloni, Florian Fainelli, Ray Jui,
Scott Branden, bcm-kernel-feedback-list@broadcom.com, Eric Anholt,
Stefan Wahren, Linus Walleij, Support Opensource, Baruch Siach,
William Breathitt Gray, Jimmy Vance, Keguang Zhang,
Joachim Eastwood, Tomas Winkler, Johannes Thumshirn,
Andreas Werner, Carlo Caione, Kevin Hilman, Matthias Brugger,
Wan ZongShun, Michal Simek, Vladimir Zapolskiy, Sylvain Lemieux,
Kukjin Kim, Krzysztof Kozlowski, Zwane Mwaikambo, Jim Cromie,
Barry Song, Maxime Ripard, Chen-Yu Tsai, Marc Gonzalez,
Mans Rullgard, Thierry Reding, Jonathan Hunter, Masahiro Yamada,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, Jun Nie,
Baoyou Xie, Shawn Guo
Cc: linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org,
adi-buildroot-devel@lists.sourceforge.net,
linux-mips@linux-mips.org, linux-amlogic@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, patches@opensource.cirrus.com
In-Reply-To: <20180220093119.23720-1-marcus.folkesson@gmail.com>
SGkgTWFyY3VzDQoNCk9uIDAyLzIwLzIwMTggMTA6MzEgQU0sIE1hcmN1cyBGb2xrZXNzb24gd3Jv
dGU6DQo+IC0gQWRkIFNQRFggaWRlbnRpZmllcg0KPiAtIFJlbW92ZSBib2lsZXIgcGxhdGUgbGlj
ZW5zZSB0ZXh0DQo+IC0gSWYgTU9EVUxFX0xJQ0VOU0UgYW5kIGJvaWxlciBwbGF0ZSBkb2VzIG5v
dCBtYXRjaCwgZ28gZm9yIGJvaWxlciBwbGF0ZQ0KPiAgICBsaWNlbnNlDQo+IA0KPiBTaWduZWQt
b2ZmLWJ5OiBNYXJjdXMgRm9sa2Vzc29uIDxtYXJjdXMuZm9sa2Vzc29uQGdtYWlsLmNvbT4NCj4g
LS0tDQo+IA0KPiBOb3RlczoNCj4gICAgICB2MTogUGxlYXNlIGhhdmUgYW4gZXh0cmEgbG9vayBh
dCBtZXNvbl9neGJiX3dkdC5jDQo+IA0KDQpbLi4uXQ0KDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJz
L3dhdGNoZG9nL3N0X2xwY193ZHQuYyBiL2RyaXZlcnMvd2F0Y2hkb2cvc3RfbHBjX3dkdC5jDQo+
IGluZGV4IGU2MTAwZTQ0N2RkOC4uMTc3ODI5YjM3OWRhIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJz
L3dhdGNoZG9nL3N0X2xwY193ZHQuYw0KPiArKysgYi9kcml2ZXJzL3dhdGNoZG9nL3N0X2xwY193
ZHQuYw0KPiBAQCAtMSwzICsxLDQgQEANCj4gKy8vIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBH
UEwtMi4wKw0KPiAgIC8qDQo+ICAgICogU1QncyBMUEMgV2F0Y2hkb2cNCj4gICAgKg0KPiBAQCAt
NSwxMSArNiw2IEBADQo+ICAgICoNCj4gICAgKiBBdXRob3I6IERhdmlkIFBhcmlzIDxkYXZpZC5w
YXJpc0BzdC5jb20+IGZvciBTVE1pY3JvZWxlY3Ryb25pY3MNCj4gICAgKiAgICAgICAgIExlZSBK
b25lcyA8bGVlLmpvbmVzQGxpbmFyby5vcmc+IGZvciBTVE1pY3JvZWxlY3Ryb25pY3MNCj4gLSAq
DQo+IC0gKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1
dGUgaXQgYW5kL29yDQo+IC0gKiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5jZQ0KPiAtICogYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uDQo+IC0gKiAyIG9mIHRoZSBMaWNlbmNl
LCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KPiAgICAqLw0KPiAgIA0K
DQpGb3Igc3RfbHBjX3dkdC5jDQoNCkFja2VkLWJ5OiBQYXRyaWNlIENob3RhcmQgPHBhdHJpY2Uu
Y2hvdGFyZEBzdC5jb20+DQoNClRoYW5rcw0KDQo=
^ permalink raw reply
* Re: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem
From: Patrice CHOTARD @ 2018-02-21 12:37 UTC (permalink / raw)
To: Marcus Folkesson, Wim Van Sebroeck, Guenter Roeck, Joel Stanley,
Nicolas Ferre, Alexandre Belloni, Eric Anholt, Stefan Wahren,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list@broadcom.com, Linus Walleij,
Support Opensource, Baruch Siach, William Breathitt Gray,
Jimmy Vance, Keguang Zhang, Joachim Eastwood, Tomas Winkler,
Johannes Thumshirn, Andreas Werner, Carlo Caione, Kevin Hilman,
Matthias Brugger, Wan ZongShun, Michal Simek, Vladimir Zapolskiy,
Sylvain Lemieux, Kukjin Kim, Krzysztof Kozlowski, Zwane Mwaikambo,
Jim Cromie, Barry Song, Maxime Ripard, Chen-Yu Tsai,
Marc Gonzalez, Mans Rullgard, Thierry Reding, Jonathan Hunter,
Masahiro Yamada, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Jun Nie, Baoyou Xie, Shawn Guo
Cc: linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org,
adi-buildroot-devel@lists.sourceforge.net,
linux-mips@linux-mips.org, linux-amlogic@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, patches@opensource.cirrus.com
In-Reply-To: <20180221122744.28300-1-marcus.folkesson@gmail.com>
SEkgTWFyY3VzDQoNCk9uIDAyLzIxLzIwMTggMDE6MjcgUE0sIE1hcmN1cyBGb2xrZXNzb24gd3Jv
dGU6DQo+IC0gQWRkIFNQRFggaWRlbnRpZmllcg0KPiAtIFJlbW92ZSBib2lsZXIgcGxhdGUgbGlj
ZW5zZSB0ZXh0DQo+IC0gSWYgTU9EVUxFX0xJQ0VOU0UgYW5kIGJvaWxlciBwbGF0ZSBkb2VzIG5v
dCBtYXRjaCwgZ28gZm9yIGJvaWxlciBwbGF0ZQ0KPiAgICBsaWNlbnNlDQo+IA0KPiBTaWduZWQt
b2ZmLWJ5OiBNYXJjdXMgRm9sa2Vzc29uIDxtYXJjdXMuZm9sa2Vzc29uQGdtYWlsLmNvbT4NCj4g
QWNrZWQtYnk6IEFkYW0gVGhvbXNvbiA8QWRhbS5UaG9tc29uLk9wZW5zb3VyY2VAZGlhc2VtaS5j
b20+DQo+IEFja2VkLWJ5OiBDaGFybGVzIEtlZXBheCA8Y2tlZXBheEBvcGVuc291cmNlLmNpcnJ1
cy5jb20+DQo+IEFja2VkLWJ5OiBNYW5zIFJ1bGxnYXJkIDxtYW5zQG1hbnNyLmNvbT4NCj4gQWNr
ZWQtYnk6IE1hdHRoaWFzIEJydWdnZXIgPG1hdHRoaWFzLmJnZ0BnbWFpbC5jb20+DQo+IEFja2Vk
LWJ5OiBNaWNoYWwgU2ltZWsgPG1pY2hhbC5zaW1la0B4aWxpbnguY29tPg0KPiBBY2tlZC1ieTog
TmVpbCBBcm1zdHJvbmcgPG5hcm1zdHJvbmdAYmF5bGlicmUuY29tPg0KPiBBY2tlZC1ieTogTmlj
b2xhcyBGZXJyZSA8bmljb2xhcy5mZXJyZUBtaWNyb2NoaXAuY29tPg0KPiBBY2tlZC1ieTogVGhp
ZXJyeSBSZWRpbmcgPHRyZWRpbmdAbnZpZGlhLmNvbT4NCj4gUmV2aWV3ZWQtYnk6IEVyaWMgQW5o
b2x0IDxlcmljQGFuaG9sdC5uZXQ+DQo+IC0tLQ0KPiANCj4gTm90ZXM6DQo+ICAgICAgdjM6DQo+
ICAgICAgCS0gS2VlcCBsaWNlbnNlIHRleHQgZm9yIGViYy1jMzg0X3dkdA0KPiAgICAgIHYyOg0K
PiAgICAgIAktIFB1dCBiYWNrIHJlbW92ZWQgY29weXJpZ2h0IHRleHRzIGZvciBtZXNvbl9neGJi
X3dkdCBhbmQgY29oOTAxMzI3X3dkdA0KPiAgICAgIAktIENoYW5nZSB0byBCU0QtMy1DbGF1c2Ug
Zm9yIG1lc29uX2d4YmJfd2R0DQo+ICAgICAgdjE6IFBsZWFzZSBoYXZlIGFuIGV4dHJhIGxvb2sg
YXQgbWVzb25fZ3hiYl93ZHQuYw0KPiANCg0KWy4uLl0NCg0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVy
cy93YXRjaGRvZy9zdF9scGNfd2R0LmMgYi9kcml2ZXJzL3dhdGNoZG9nL3N0X2xwY193ZHQuYw0K
PiBpbmRleCBlNjEwMGU0NDdkZDguLjE3NzgyOWIzNzlkYSAxMDA2NDQNCj4gLS0tIGEvZHJpdmVy
cy93YXRjaGRvZy9zdF9scGNfd2R0LmMNCj4gKysrIGIvZHJpdmVycy93YXRjaGRvZy9zdF9scGNf
d2R0LmMNCj4gQEAgLTEsMyArMSw0IEBADQo+ICsvLyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjog
R1BMLTIuMCsNCj4gICAvKg0KPiAgICAqIFNUJ3MgTFBDIFdhdGNoZG9nDQo+ICAgICoNCj4gQEAg
LTUsMTEgKzYsNiBAQA0KPiAgICAqDQo+ICAgICogQXV0aG9yOiBEYXZpZCBQYXJpcyA8ZGF2aWQu
cGFyaXNAc3QuY29tPiBmb3IgU1RNaWNyb2VsZWN0cm9uaWNzDQo+ICAgICogICAgICAgICBMZWUg
Sm9uZXMgPGxlZS5qb25lc0BsaW5hcm8ub3JnPiBmb3IgU1RNaWNyb2VsZWN0cm9uaWNzDQo+IC0g
Kg0KPiAtICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlIGl0IGFuZC9vcg0KPiAtICogbW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIExpY2VuY2UNCj4gLSAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBT
b2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbg0KPiAtICogMiBvZiB0aGUgTGljZW5j
ZSwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCj4gICAgKi8NCj4gICAN
Cg0KDQpGb3Igc3RfbHBjX3dkdC5jDQoNCkFja2VkLWJ5OiBQYXRyaWNlIENob3RhcmQgPHBhdHJp
Y2UuY2hvdGFyZEBzdC5jb20+DQoNClRoYW5rcw==
^ permalink raw reply
* [PATCH] powerpc/pseries: Fix duplicate firmware feature for DRC_INFO
From: Michael Ellerman @ 2018-02-21 13:05 UTC (permalink / raw)
To: mwb, nfont; +Cc: linuxppc-dev
We had a mid-air collision between two new firmware features, DRMEM_V2
and DRC_INFO, and they ended up with the same value.
No one's actually reported any problems, presumably because the new
firmware that supports both properties is not widely available, and
the two properties tend to be enabled together.
Still if we ever had one enabled but not the other, the bugs that
could result are many and varied. So fix it.
Fixes: 3f38000eda48 ("powerpc/firmware: Add definitions for new drc-info firmware feature")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/firmware.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
index 511acfd7ab0d..535add3f7791 100644
--- a/arch/powerpc/include/asm/firmware.h
+++ b/arch/powerpc/include/asm/firmware.h
@@ -52,7 +52,7 @@
#define FW_FEATURE_TYPE1_AFFINITY ASM_CONST(0x0000000100000000)
#define FW_FEATURE_PRRN ASM_CONST(0x0000000200000000)
#define FW_FEATURE_DRMEM_V2 ASM_CONST(0x0000000400000000)
-#define FW_FEATURE_DRC_INFO ASM_CONST(0x0000000400000000)
+#define FW_FEATURE_DRC_INFO ASM_CONST(0x0000000800000000)
#ifndef __ASSEMBLY__
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()
From: Michael Ellerman @ 2018-02-21 13:13 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Shilpasri G Bhat, Rafael J. Wysocki, Linux PM,
Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CAJZ5v0jEg7FELH6mBY16mB5sfo7s2mbH2SGheH4KVeKLnStjjg@mail.gmail.com>
"Rafael J. Wysocki" <rafael@kernel.org> writes:
> On Wed, Feb 21, 2018 at 6:54 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> On 21-02-18, 16:39, Michael Ellerman wrote:
>>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>
>>> > AFAICT, you will get -1 here only if the freq table had no valid
>>> > frequencies (or the freq table is empty). Why would that happen ?
>>>
>>> Bugs?
>>
>> The cupfreq driver shouldn't have registered itself in that case (i.e.
>> if the cpufreq table is empty).
>
> To be precise, ->init() should fail as that's where the table is
> created. The registration fails as a result then.
>
> But what if the bug is that ->init() doesn't fail when it should?
>
> I guess the core could double check the frequency table after ->init()
> if ->target_index is not NULL.
>
> The overall point here is that if you get a negative index in
> ->fast_switch(), that's way too late anyway and we should be able to
> catch that error much earlier.
OK.
Still it's one thing for the driver to print a warning and bail out,
it's another to access off the front of an array and keep running using
some junk values, or oops (though not in this case because the array
happens to be static).
cheers
^ permalink raw reply
* Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()
From: Rafael J. Wysocki @ 2018-02-21 13:25 UTC (permalink / raw)
To: Michael Ellerman
Cc: Rafael J. Wysocki, Viresh Kumar, Shilpasri G Bhat,
Rafael J. Wysocki, Linux PM, Linux Kernel Mailing List,
linuxppc-dev
In-Reply-To: <87vaeqqye8.fsf@concordia.ellerman.id.au>
On Wed, Feb 21, 2018 at 2:13 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> "Rafael J. Wysocki" <rafael@kernel.org> writes:
>
>> On Wed, Feb 21, 2018 at 6:54 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>> On 21-02-18, 16:39, Michael Ellerman wrote:
>>>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>>
>>>> > AFAICT, you will get -1 here only if the freq table had no valid
>>>> > frequencies (or the freq table is empty). Why would that happen ?
>>>>
>>>> Bugs?
>>>
>>> The cupfreq driver shouldn't have registered itself in that case (i.e.
>>> if the cpufreq table is empty).
>>
>> To be precise, ->init() should fail as that's where the table is
>> created. The registration fails as a result then.
>>
>> But what if the bug is that ->init() doesn't fail when it should?
>>
>> I guess the core could double check the frequency table after ->init()
>> if ->target_index is not NULL.
>>
>> The overall point here is that if you get a negative index in
>> ->fast_switch(), that's way too late anyway and we should be able to
>> catch that error much earlier.
>
> OK.
>
> Still it's one thing for the driver to print a warning and bail out,
> it's another to access off the front of an array and keep running using
> some junk values, or oops (though not in this case because the array
> happens to be static).
Well, let me rephrase. If ->fast_switch() runs, then it must not be
possible to get a negative index in it. That has to be guaranteed by
the core.
^ permalink raw reply
* Re: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem
From: Johannes Thumshirn @ 2018-02-21 13:31 UTC (permalink / raw)
To: Marcus Folkesson
Cc: Wim Van Sebroeck, Guenter Roeck, Joel Stanley, Nicolas Ferre,
Alexandre Belloni, Eric Anholt, Stefan Wahren, Florian Fainelli,
Ray Jui, Scott Branden, bcm-kernel-feedback-list, Linus Walleij,
Support Opensource, Baruch Siach, William Breathitt Gray,
Jimmy Vance, Keguang Zhang, Joachim Eastwood, Tomas Winkler,
Andreas Werner, Carlo Caione, Kevin Hilman, Matthias Brugger,
Wan ZongShun, Michal Simek, Vladimir Zapolskiy, Sylvain Lemieux,
Kukjin Kim, Krzysztof Kozlowski, Zwane Mwaikambo, Jim Cromie,
Barry Song, Patrice Chotard, Maxime Ripard, Chen-Yu Tsai,
Marc Gonzalez, Mans Rullgard, Thierry Reding, Jonathan Hunter,
Masahiro Yamada, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Jun Nie, Baoyou Xie, Shawn Guo, linux-watchdog,
linux-kernel, linux-arm-kernel, linux-rpi-kernel,
adi-buildroot-devel, linux-mips, linux-amlogic, linux-mediatek,
linux-samsung-soc, linux-tegra, linuxppc-dev, patches
In-Reply-To: <20180221122744.28300-1-marcus.folkesson@gmail.com>
On Wed, Feb 21, 2018 at 01:27:34PM +0100, Marcus Folkesson wrote:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
> license
[...]
> drivers/watchdog/mena21_wdt.c | 4 +--
Acked-by: Johannes Thumshirn <jth@kernel.org>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [RFC PATCH v0 1/2] powerpc, drmem: Fix unexpected flag value in ibm, dynamic-memory-v2
From: Bharata B Rao @ 2018-02-21 13:36 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, nfont, mwb
In-Reply-To: <87zi42r2bh.fsf@concordia.ellerman.id.au>
On Wed, Feb 21, 2018 at 10:48:18PM +1100, Michael Ellerman wrote:
> Bharata B Rao <bharata@linux.vnet.ibm.com> writes:
>
> > Memory addtion and removal by count and indexed-count methods
> > temporarily mark the LMBs that are being added/removed by a special
> > flag value DRMEM_LMB_RESERVED. Accessing flags value directly at
> > a few places without proper accessor method is causing two unexpected
> > side-effects:
> >
> > - DRMEM_LMB_RESERVED bit is becoming part of the flags word of
> > drconf_cell_v2 entries in ibm,dynamic-memory-v2 DT property.
> > - This results in extra drconf_cell entries in ibm,dynamic-memory-v2.
> > For example if 1G memory is added, it leads to one entry for 3 LMBs
> > and 1 separate entry for the last LMB. All the 4 LMBs should be
> > defined by one entry here.
> >
> > Fix this by always accessing the flags by its accessor method
> > drmem_lmb_flags().
> >
> > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
>
> Presumably:
>
> Fixes: 2b31e3aec1db ("powerpc/drmem: Add support for ibm, dynamic-memory-v2 property")
Yes.
Regards,
Bharata.
^ permalink raw reply
* RE: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem
From: Winkler, Tomas @ 2018-02-21 13:39 UTC (permalink / raw)
To: Marcus Folkesson, Wim Van Sebroeck, Guenter Roeck, Joel Stanley,
Nicolas Ferre, Alexandre Belloni, Eric Anholt, Stefan Wahren,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list@broadcom.com, Linus Walleij,
Support Opensource, Baruch Siach, William Breathitt Gray,
Jimmy Vance, Keguang Zhang, Joachim Eastwood, Johannes Thumshirn,
Andreas Werner, Carlo Caione, Kevin Hilman, Matthias Brugger,
Wan ZongShun, Michal Simek, Vladimir Zapolskiy, Sylvain Lemieux,
Kukjin Kim, Krzysztof Kozlowski, Zwane Mwaikambo, Jim Cromie,
Barry Song, Patrice Chotard, Maxime Ripard, Chen-Yu Tsai,
Marc Gonzalez, Mans Rullgard, Thierry Reding, Jonathan Hunter,
Masahiro Yamada, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Jun Nie, Baoyou Xie, Shawn Guo
Cc: linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org,
adi-buildroot-devel@lists.sourceforge.net,
linux-mips@linux-mips.org, linux-amlogic@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, patches@opensource.cirrus.com
In-Reply-To: <20180221122744.28300-1-marcus.folkesson@gmail.com>
PiANCj4gLSBBZGQgU1BEWCBpZGVudGlmaWVyDQo+IC0gUmVtb3ZlIGJvaWxlciBwbGF0ZSBsaWNl
bnNlIHRleHQNCj4gLSBJZiBNT0RVTEVfTElDRU5TRSBhbmQgYm9pbGVyIHBsYXRlIGRvZXMgbm90
IG1hdGNoLCBnbyBmb3IgYm9pbGVyIHBsYXRlDQo+ICAgbGljZW5zZQ0KPiANCj4gU2lnbmVkLW9m
Zi1ieTogTWFyY3VzIEZvbGtlc3NvbiA8bWFyY3VzLmZvbGtlc3NvbkBnbWFpbC5jb20+DQo+IEFj
a2VkLWJ5OiBBZGFtIFRob21zb24gPEFkYW0uVGhvbXNvbi5PcGVuc291cmNlQGRpYXNlbWkuY29t
Pg0KPiBBY2tlZC1ieTogQ2hhcmxlcyBLZWVwYXggPGNrZWVwYXhAb3BlbnNvdXJjZS5jaXJydXMu
Y29tPg0KPiBBY2tlZC1ieTogTWFucyBSdWxsZ2FyZCA8bWFuc0BtYW5zci5jb20+DQo+IEFja2Vk
LWJ5OiBNYXR0aGlhcyBCcnVnZ2VyIDxtYXR0aGlhcy5iZ2dAZ21haWwuY29tPg0KPiBBY2tlZC1i
eTogTWljaGFsIFNpbWVrIDxtaWNoYWwuc2ltZWtAeGlsaW54LmNvbT4NCj4gQWNrZWQtYnk6IE5l
aWwgQXJtc3Ryb25nIDxuYXJtc3Ryb25nQGJheWxpYnJlLmNvbT4NCj4gQWNrZWQtYnk6IE5pY29s
YXMgRmVycmUgPG5pY29sYXMuZmVycmVAbWljcm9jaGlwLmNvbT4NCj4gQWNrZWQtYnk6IFRoaWVy
cnkgUmVkaW5nIDx0cmVkaW5nQG52aWRpYS5jb20+DQo+IFJldmlld2VkLWJ5OiBFcmljIEFuaG9s
dCA8ZXJpY0BhbmhvbHQubmV0Pg0KPiAtLS0NCj4gDQo+IE5vdGVzOg0KPiAgICAgdjM6DQo+ICAg
ICAJLSBLZWVwIGxpY2Vuc2UgdGV4dCBmb3IgZWJjLWMzODRfd2R0DQo+ICAgICB2MjoNCj4gICAg
IAktIFB1dCBiYWNrIHJlbW92ZWQgY29weXJpZ2h0IHRleHRzIGZvciBtZXNvbl9neGJiX3dkdCBh
bmQNCj4gY29oOTAxMzI3X3dkdA0KPiAgICAgCS0gQ2hhbmdlIHRvIEJTRC0zLUNsYXVzZSBmb3Ig
bWVzb25fZ3hiYl93ZHQNCj4gICAgIHYxOiBQbGVhc2UgaGF2ZSBhbiBleHRyYSBsb29rIGF0IG1l
c29uX2d4YmJfd2R0LmMNCj4gDQo+ICAgKg0KPiAtICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29m
dHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkgaXQNCj4gLSAqIHVu
ZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAy
IGFzIHB1Ymxpc2hlZA0KPiAtICogYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCj4g
ICAqDQo+IA0KDQo+ICAjaW5jbHVkZSA8bGludXgvZXJyLmg+DQo+IGRpZmYgLS1naXQgYS9kcml2
ZXJzL3dhdGNoZG9nL21laV93ZHQuYyBiL2RyaXZlcnMvd2F0Y2hkb2cvbWVpX3dkdC5jDQo+IGlu
ZGV4IGI4MTk0YjAyYWJlMC4uODAyM2NmMjg2NTdhIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3dh
dGNoZG9nL21laV93ZHQuYw0KPiArKysgYi9kcml2ZXJzL3dhdGNoZG9nL21laV93ZHQuYw0KPiBA
QCAtMSwxNSArMSw3IEBADQo+ICsvLyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMA0K
PiAgLyoNCj4gICAqIEludGVsIE1hbmFnZW1lbnQgRW5naW5lIEludGVyZmFjZSAoSW50ZWwgTUVJ
KSBMaW51eCBkcml2ZXINCj4gICAqIENvcHlyaWdodCAoYykgMjAxNSwgSW50ZWwgQ29ycG9yYXRp
b24uDQo+IC0gKg0KPiAtICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4g
cmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkgaXQNCj4gLSAqIHVuZGVyIHRoZSB0ZXJtcyBh
bmQgY29uZGl0aW9ucyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsDQo+IC0gKiB2
ZXJzaW9uIDIsIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLg0K
PiAtICoNCj4gLSAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSBpdCB3
aWxsIGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQNCj4gLSAqIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQo+IE1FUkNIQU5UQUJJTElUWSBvcg0KPiAtICog
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UNCj4gZm9yDQo+IC0gKiBtb3JlIGRldGFpbHMuDQo+ICAgKi8NCj4gDQo+ICAj
aW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQo+IEBAIC02ODcsNSArNjc5LDUgQEAgc3RhdGljIHN0
cnVjdCBtZWlfY2xfZHJpdmVyIG1laV93ZHRfZHJpdmVyID0gew0KPiAgbW9kdWxlX21laV9jbF9k
cml2ZXIobWVpX3dkdF9kcml2ZXIpOw0KPiANCj4gIE1PRFVMRV9BVVRIT1IoIkludGVsIENvcnBv
cmF0aW9uIik7DQo+IC1NT0RVTEVfTElDRU5TRSgiR1BMIik7DQo+ICtNT0RVTEVfTElDRU5TRSgi
R1BMIHYyIik7DQo+ICBNT0RVTEVfREVTQ1JJUFRJT04oIkRldmljZSBkcml2ZXIgZm9yIEludGVs
IE1FSSBpQU1UIHdhdGNoZG9nIik7DQoNCkFja2VkLWJ5OiBUb21hcyBXaW5rbGVyIDx0b21hcy53
aW5rbGVyQGludGVsLmNvbT4NCg0KDQoNCg==
^ permalink raw reply
* Re: [RFC PATCH v0 0/2] ibm,dynamic-memory-v2 fix
From: Bharata B Rao @ 2018-02-21 13:41 UTC (permalink / raw)
To: Balbir Singh
Cc: open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Nathan Fontenot,
Michael Bringmann
In-Reply-To: <CAKTCnzm8TJBWG2VG9Bts2zQF01Tsya72bJJSTRimE32XuFC-YA@mail.gmail.com>
On Wed, Feb 21, 2018 at 11:27:20PM +1100, Balbir Singh wrote:
> On Wed, Feb 21, 2018 at 9:36 PM, Bharata B Rao
> <bharata@linux.vnet.ibm.com> wrote:
> > Patch 1 fixes a bug that results in unexpected flag bit in
> > ibm,dynamic-memory-v2 DT property and wrong number of entries
> > getting created in the same property during hotplug.
> >
>
> Could you please elaborate on what this means?
Described in 1/2 patch.
> Is there a test case -
> how do we reproduce this?
Hotplug some memory and check the entries in ibm,dynamic-memory-v2 and also
check the flags there, you will see DRMEM_LMB_RESERVED set, which
shouldn't be set.
You would need QEMU which supports ibm,dynamic-memory-v2. I have posted
the initial patches for that at:
http://lists.gnu.org/archive/html/qemu-ppc/2018-02/msg00236.html
Regards,
Bharata.
^ permalink raw reply
* Re: [PATCH] bpf, powerpc: fix jit for seccomp_data access
From: Mark Lord @ 2018-02-21 13:41 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Alexei Starovoitov, Daniel Borkmann, Kees Cook, Andy Lutomirski,
mpe, Will Drewry, linuxppc-dev
In-Reply-To: <32a60518-1de6-9f9c-b3e6-5e5292d6b289@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
On 18-02-21 07:52 AM, Mark Lord wrote:
> On 18-02-21 03:35 AM, Naveen N. Rao wrote:
..
>> Looks good to me, but I am not able to apply this patch. There seems to be whitespace damage.
>
> Here (attached) is a clean copy.
Again, this time with the commit message included!
I am using SECCOMP to filter syscalls on a ppc32 platform,
and noticed that the JIT compiler was failing on the BPF
even though the interpreter was working fine.
The issue was that the compiler was missing one of the instructions
used by SECCOMP, so here is a patch to enable JIT for that instruction.
Signed-Off-By: Mark Lord <mlord@pobox.com>
--- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.000000000 -0500
+++ linux/arch/powerpc/net/bpf_jit_comp.c 2018-02-20 14:41:20.805227494 -0500
@@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
break;
+ case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
+ PPC_LWZ_OFFS(r_A, r_skb, K);
+ break;
case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
break;
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
[-- Attachment #2: ppc-jit.patch --]
[-- Type: text/x-patch, Size: 940 bytes --]
I am using SECCOMP to filter syscalls on a ppc32 platform,
and noticed that the JIT compiler was failing on the BPF
even though the interpreter was working fine.
The issue was that the compiler was missing one of the instructions
used by SECCOMP, so here is a patch to enable JIT for that instruction.
Signed-Off-By: Mark Lord <mlord@pobox.com>
--- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.000000000 -0500
+++ linux/arch/powerpc/net/bpf_jit_comp.c 2018-02-20 14:41:20.805227494 -0500
@@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
break;
+ case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
+ PPC_LWZ_OFFS(r_A, r_skb, K);
+ break;
case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
break;
^ permalink raw reply
* Re: ocxl: Fix potential bad errno on irq allocation
From: Michael Ellerman @ 2018-02-21 13:43 UTC (permalink / raw)
To: Frederic Barrat, andrew.donnellan, linuxppc-dev; +Cc: dan.carpenter
In-Reply-To: <20180216130118.26008-1-fbarrat@linux.vnet.ibm.com>
On Fri, 2018-02-16 at 13:01:18 UTC, Frederic Barrat wrote:
> Fix some issues found by a static checker:
>
> When allocating an AFU interrupt, if the driver cannot copy the output
> parameters to userland, the errno value was not set to EFAULT
>
> Remove a (now) useless cast.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/423688abd9ab654044bddd82eb5983
cheers
^ permalink raw reply
* Re: powerpc/eeh: Add conditional check on notify_resume
From: Michael Ellerman @ 2018-02-21 13:43 UTC (permalink / raw)
To: Bryant G. Ly, benh, paulus; +Cc: aik, linuxppc-dev, jjalvare, seroyer
In-Reply-To: <1518720591-84657-1-git-send-email-bryantly@linux.vnet.ibm.com>
On Thu, 2018-02-15 at 18:49:51 UTC, "Bryant G. Ly" wrote:
> From: "Juan J. Alvarez" <jjalvare@linux.vnet.ibm.com>
>
> EEH structure is not populated with function
> notify resume when running on systems that do not support
> it, i.e: BMC. Hence adding a conditional check for NULL for
> systems that don't add function notify_resume.
>
> Signed-off-by: Juan J. Alvarez <jjalvare@linux.vnet.ibm.com>
> Reviewed-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
> Tested-by: Carol L. Soto <clsoto@us.ibm.com>
> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Tested-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
> Acked-by: Michael Neuling <mikey@neuling.org>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/521ca5a9859a870e354d1a6b84a6ff
cheers
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/mm/32: Use pfn_valid to check if pointer is in RAM
From: Jonathan Neuschäfer @ 2018-02-21 13:51 UTC (permalink / raw)
To: christophe leroy
Cc: Jonathan Neuschäfer, linuxppc-dev, linux-kernel,
Michael Ellerman, linux-mm, Joel Stanley, Benjamin Herrenschmidt,
Paul Mackerras, Balbir Singh, Guenter Roeck
In-Reply-To: <0d14cb2c-dd00-d258-cb15-302b2a9d684f@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
Hello Christophe,
On Tue, Feb 20, 2018 at 06:45:09PM +0100, christophe leroy wrote:
[...]
> > - if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
> > + if (slab_is_available() && pfn_valid(__phys_to_pfn(p)) &&
>
> I'm not sure this is equivalent:
>
> high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
> #define ARCH_PFN_OFFSET ((unsigned long)(MEMORY_START >> PAGE_SHIFT))
> #define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) < max_mapnr)
> set_max_mapnr(max_pfn);
>
> So in the current implementation it checks against max_low_pfn while your
> patch checks against max_pfn
>
> max_low_pfn = max_pfn = memblock_end_of_DRAM() >> PAGE_SHIFT;
> #ifdef CONFIG_HIGHMEM
> max_low_pfn = lowmem_end_addr >> PAGE_SHIFT;
> #endif
Good point, I haven't considered CONFIG_HIGHMEM before.
As far as I understand it, in the non-CONFIG_HIGHMEM case:
- max_low_pfn is set to the same value as max_pfn, so the ioremap
check should detect the same PFNs as RAM.
and with CONFIG_HIGHMEM:
- max_low_pfn is set to lowmem_end_addr >> PAGE_SHIFT
- but max_pfn isn't
So, I think you're right.
While looking through arch/powerpc/mm, I noticed that there's a
page_is_ram function, which simply uses the memblocks directly, on
PPC32. It seems like a good candidate for the RAM check in
__ioremap_caller, except that there's this code, which apparently
trashes memblock 0 completely on non-CONFIG_NEED_MULTIPLE_NODES:
https://elixir.bootlin.com/linux/v4.16-rc2/source/arch/powerpc/mm/mem.c#L223
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] bpf, powerpc: fix jit for seccomp_data access
From: Naveen N. Rao @ 2018-02-21 14:08 UTC (permalink / raw)
To: Mark Lord
Cc: Alexei Starovoitov, Daniel Borkmann, Kees Cook, linuxppc-dev,
Andy Lutomirski, mpe, Will Drewry
In-Reply-To: <2e79ef59-1731-f3a5-9868-c15beb939142@pobox.com>
Mark Lord wrote:
> On 18-02-21 07:52 AM, Mark Lord wrote:
>> On 18-02-21 03:35 AM, Naveen N. Rao wrote:
> ..
>>> Looks good to me, but I am not able to apply this patch. There seems to=
be whitespace damage.
>>=20
>> Here (attached) is a clean copy.
>=20
> Again, this time with the commit message included!
Thanks. However...
I am able to apply this using 'patch', but not with 'git am' since the=20
headers are missing. FWIW, the usual workflow is to make the changes and=20
commit it into your repository using 'git commit' and then use 'git=20
format-patch' to generate a patch file that you can then post.
I'll defer to Michael on whether he is ok to process this as it is.
>=20
> I am using SECCOMP to filter syscalls on a ppc32 platform,
> and noticed that the JIT compiler was failing on the BPF
> even though the interpreter was working fine.
>=20
> The issue was that the compiler was missing one of the instructions
> used by SECCOMP, so here is a patch to enable JIT for that instruction.
>=20
> Signed-Off-By: Mark Lord <mlord@pobox.com>
Minot nit: The correct (TM) tag to use is:
Signed-off-by:
(note the case)
>=20
> --- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.000000000 -05=
00
> +++ linux/arch/powerpc/net/bpf_jit_comp.c 2018-02-20 14:41:20.80522=
7494 -0500
> @@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
> BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) !=
=3D 4);
> PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,=
len));
> break;
> + case BPF_LDX | BPF_W | BPF_ABS: /* A =3D *((u32 *)(seccom=
p_data + K)); */
> + PPC_LWZ_OFFS(r_A, r_skb, K);
> + break;
> case BPF_LDX | BPF_W | BPF_LEN: /* X =3D skb->len; */
> PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff,=
len));
> break;
Apart from those aspects, for this patch:
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
- Naveen
=
^ permalink raw reply
* Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
From: Jonathan Neuschäfer @ 2018-02-21 14:42 UTC (permalink / raw)
To: Christophe LEROY
Cc: Jonathan Neuschäfer, linuxppc-dev, Joel Stanley,
linux-kernel, linux-mm
In-Reply-To: <193a407d-e6b8-9e29-af47-3d401b6414a0@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Hi,
On Wed, Feb 21, 2018 at 08:06:10AM +0100, Christophe LEROY wrote:
>
>
> Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit :
> > This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is
> > required to properly support the Nintendo Wii's memory layout, in which
> > there are two blocks of RAM and MMIO in the middle.
> >
> > Previously, this memory layout was handled by code that joins the two
> > RAM blocks into one, reserves the MMIO hole, and permits allocations of
> > reserved memory in ioremap. This hack didn't work with resource-based
> > allocation (as used for example in the GPIO driver for Wii[1]), however.
> >
> > After this patchset, users of the Wii can either select CONFIG_FLATMEM
> > to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new
> > behaviour.
>
> My question might me stupid, as I don't know PCC64 in deep, but when looking
> at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling the PPC64
> implements ram by blocks. Isn't it what you are trying to achieve ? Wouldn't
> it be feasible to map to what's done in PPC64 for PPC32 ?
Using page_is_ram in __ioremap_caller and the same memblock-based
approach that's used on PPC64 on PPC32 *should* work, but I think due to
the following line in initmem_init, it won't:
memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock.memory, 0);
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/mm/32: Use pfn_valid to check if pointer is in RAM
From: Jonathan Neuschäfer @ 2018-02-21 14:44 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: christophe leroy, linuxppc-dev, linux-kernel, Michael Ellerman,
linux-mm, Joel Stanley, Benjamin Herrenschmidt, Paul Mackerras,
Balbir Singh, Guenter Roeck
In-Reply-To: <20180221135119.d3qgvdck5yruomi7@latitude>
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
On Wed, Feb 21, 2018 at 02:51:19PM +0100, Jonathan Neuschäfer wrote:
[...]
> While looking through arch/powerpc/mm, I noticed that there's a
> page_is_ram function, which simply uses the memblocks directly, on
> PPC32.
Oops, I misread the code here. memblock is used on PPC64.
> It seems like a good candidate for the RAM check in
> __ioremap_caller, except that there's this code, which apparently
> trashes memblock 0 completely on non-CONFIG_NEED_MULTIPLE_NODES:
>
> https://elixir.bootlin.com/linux/v4.16-rc2/source/arch/powerpc/mm/mem.c#L223
>
>
> Thanks,
> Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH V2] powerpc/powernv : Add support to enable sensor groups
From: Shilpasri G Bhat @ 2018-02-21 14:55 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, linux-kernel, benh, Shilpasri G Bhat
Adds support to enable/disable a sensor group. This can be used to
select the sensor groups that needs to be copied to main memory by
OCC. Sensor groups like power, temperature, current, voltage,
frequency, utilization can be enabled/disabled at runtime.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
---
Changes from V1:
- Rebase on master
- Add documentation
.../ABI/testing/sysfs-firmware-opal-sensor-groups | 34 ++++++
arch/powerpc/include/asm/opal-api.h | 4 +-
arch/powerpc/include/asm/opal.h | 1 +
.../powerpc/platforms/powernv/opal-sensor-groups.c | 123 ++++++++++++++++-----
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
5 files changed, 132 insertions(+), 31 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
new file mode 100644
index 0000000..81081de
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
@@ -0,0 +1,34 @@
+What: /sys/firmware/opal/sensor_groups
+Date: January 2018
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sensor groups directory for POWER9 powernv servers
+
+ Each folder in this directory contains a sensor group
+ which are classified based on type of the sensor
+ like power, temperature, frequency, current, etc. They
+ can also indicate the group of sensors belonging to
+ different owners like CSM, Profiler, Job-Scheduler
+
+What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/clear
+Date: Januaury 2018
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sysfs file to clear the min-max of all the sensors
+ belonging to the group.
+
+ Writing 1 to this file will clear the minimum and
+ maximum values of all the sensors in the group. The
+ min-max of a sensor is the historical minimum and
+ maximum value of the sensor cached by OCC.
+
+What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/enable
+Date: Januaury 2018
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sysfs file to enable/disable the sensor-group
+
+ Writing 0 value to this file will disable the copying
+ of the sensor-group to main memory by OCC. And writing
+ 1 to this file will enable the sensor-group copying.
+ By default all the sensor-groups are enabled and will
+ be copied to main memory. This file can be used to
+ increase the update frequency of selective
+ sensor-groups.
diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
index 94bd1bf..b6bbbd8 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -204,7 +204,9 @@
#define OPAL_NPU_SPA_SETUP 159
#define OPAL_NPU_SPA_CLEAR_CACHE 160
#define OPAL_NPU_TL_SET 161
-#define OPAL_LAST 161
+#define OPAL_SENSOR_READ_U64 162
+#define OPAL_SENSOR_GROUP_ENABLE 163
+#define OPAL_LAST 163
/* Device tree flags */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 12e70fb..e708c41 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -286,6 +286,7 @@ int64_t opal_imc_counters_init(uint32_t type, uint64_t address,
int opal_get_power_shift_ratio(u32 handle, int token, u32 *psr);
int opal_set_power_shift_ratio(u32 handle, int token, u32 psr);
int opal_sensor_group_clear(u32 group_hndl, int token);
+int opal_sensor_group_enable(u32 group_hndl, int token, bool enable);
s64 opal_signal_system_reset(s32 cpu);
diff --git a/arch/powerpc/platforms/powernv/opal-sensor-groups.c b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
index 7e5a235..1a3359d 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor-groups.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
@@ -24,6 +24,8 @@
struct sg_attr {
u32 handle;
struct kobj_attribute attr;
+ u32 opal_no;
+ int enable;
};
static struct sensor_group {
@@ -32,34 +34,44 @@ struct sg_attr {
struct sg_attr *sgattrs;
} *sgs;
-static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static int sensor_group_clear(u32 handle)
{
- struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
struct opal_msg msg;
- u32 data;
- int ret, token;
-
- ret = kstrtoint(buf, 0, &data);
- if (ret)
- return ret;
-
- if (data != 1)
- return -EINVAL;
+ int token, ret;
token = opal_async_get_token_interruptible();
- if (token < 0) {
- pr_devel("Failed to get token\n");
+ if (token < 0)
return token;
+
+ ret = opal_sensor_group_clear(handle, token);
+ if (ret == OPAL_ASYNC_COMPLETION) {
+ ret = opal_async_wait_response(token, &msg);
+ if (ret) {
+ pr_devel("Failed to wait for the async response\n");
+ ret = -EIO;
+ goto out;
+ }
+ ret = opal_error_code(opal_get_async_rc(msg));
+ } else {
+ ret = opal_error_code(ret);
}
- ret = mutex_lock_interruptible(&sg_mutex);
- if (ret)
- goto out_token;
+out:
+ opal_async_release_token(token);
+ return ret;
+}
+
+static int sensor_group_enable(u32 handle, int enable)
+{
+ struct opal_msg msg;
+ int token, ret;
+
+ token = opal_async_get_token_interruptible();
+ if (token < 0)
+ return token;
- ret = opal_sensor_group_clear(sattr->handle, token);
- switch (ret) {
- case OPAL_ASYNC_COMPLETION:
+ ret = opal_sensor_group_enable(handle, token, enable);
+ if (ret == OPAL_ASYNC_COMPLETION) {
ret = opal_async_wait_response(token, &msg);
if (ret) {
pr_devel("Failed to wait for the async response\n");
@@ -67,39 +79,90 @@ static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
goto out;
}
ret = opal_error_code(opal_get_async_rc(msg));
- if (!ret)
- ret = count;
+ } else {
+ ret = opal_error_code(ret);
+ }
+
+out:
+ opal_async_release_token(token);
+ return ret;
+}
+
+static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
+ u32 data;
+ int ret;
+
+ ret = kstrtoint(buf, 0, &data);
+ if (ret)
+ return ret;
+
+ ret = mutex_lock_interruptible(&sg_mutex);
+ if (ret)
+ return ret;
+
+ ret = -EINVAL;
+ switch (sattr->opal_no) {
+ case OPAL_SENSOR_GROUP_CLEAR:
+ if (data == 1)
+ ret = sensor_group_clear(sattr->handle);
break;
- case OPAL_SUCCESS:
- ret = count;
+ case OPAL_SENSOR_GROUP_ENABLE:
+ if (data == 0 || data == 1) {
+ if (data != sattr->enable) {
+ ret = sensor_group_enable(sattr->handle, data);
+ if (!ret)
+ sattr->enable = data;
+ } else {
+ ret = 0;
+ }
+ }
break;
default:
- ret = opal_error_code(ret);
+ break;
}
-out:
+ if (!ret)
+ ret = count;
+
mutex_unlock(&sg_mutex);
-out_token:
- opal_async_release_token(token);
return ret;
}
+static ssize_t sg_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
+
+ return sprintf(buf, "%d\n", sattr->enable);
+}
+
static struct sg_ops_info {
int opal_no;
const char *attr_name;
ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count);
+ ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf);
+ umode_t mode;
} ops_info[] = {
- { OPAL_SENSOR_GROUP_CLEAR, "clear", sg_store },
+ { OPAL_SENSOR_GROUP_CLEAR, "clear", sg_store, NULL, 0220 },
+ { OPAL_SENSOR_GROUP_ENABLE, "enable", sg_store, sg_show, 0660 },
};
static void add_attr(int handle, struct sg_attr *attr, int index)
{
attr->handle = handle;
+ attr->opal_no = ops_info[index].opal_no;
sysfs_attr_init(&attr->attr.attr);
attr->attr.attr.name = ops_info[index].attr_name;
- attr->attr.attr.mode = 0220;
+ attr->attr.attr.mode = ops_info[index].mode;
attr->attr.store = ops_info[index].store;
+ attr->attr.show = ops_info[index].show;
+ if (attr->opal_no == OPAL_SENSOR_GROUP_ENABLE)
+ attr->enable = 1;
}
static int add_attr_group(const __be32 *ops, int len, struct sensor_group *sg,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 1b2936b..90c2b40 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -323,3 +323,4 @@ OPAL_CALL(opal_sensor_group_clear, OPAL_SENSOR_GROUP_CLEAR);
OPAL_CALL(opal_npu_spa_setup, OPAL_NPU_SPA_SETUP);
OPAL_CALL(opal_npu_spa_clear_cache, OPAL_NPU_SPA_CLEAR_CACHE);
OPAL_CALL(opal_npu_tl_set, OPAL_NPU_TL_SET);
+OPAL_CALL(opal_sensor_group_enable, OPAL_SENSOR_GROUP_ENABLE);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
From: Christophe LEROY @ 2018-02-21 15:02 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linuxppc-dev, Joel Stanley, linux-kernel, linux-mm
In-Reply-To: <20180221144240.pfu2run3pixt3pzo@latitude>
Le 21/02/2018 à 15:42, Jonathan Neuschäfer a écrit :
> Hi,
>
> On Wed, Feb 21, 2018 at 08:06:10AM +0100, Christophe LEROY wrote:
>>
>>
>> Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit :
>>> This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is
>>> required to properly support the Nintendo Wii's memory layout, in which
>>> there are two blocks of RAM and MMIO in the middle.
>>>
>>> Previously, this memory layout was handled by code that joins the two
>>> RAM blocks into one, reserves the MMIO hole, and permits allocations of
>>> reserved memory in ioremap. This hack didn't work with resource-based
>>> allocation (as used for example in the GPIO driver for Wii[1]), however.
>>>
>>> After this patchset, users of the Wii can either select CONFIG_FLATMEM
>>> to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new
>>> behaviour.
>>
>> My question might me stupid, as I don't know PCC64 in deep, but when looking
>> at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling the PPC64
>> implements ram by blocks. Isn't it what you are trying to achieve ? Wouldn't
>> it be feasible to map to what's done in PPC64 for PPC32 ?
>
> Using page_is_ram in __ioremap_caller and the same memblock-based
> approach that's used on PPC64 on PPC32 *should* work, but I think due to
> the following line in initmem_init, it won't:
>
> memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock.memory, 0);
Can't we just fix that ?
Christophe
>
>
> Thanks,
> Jonathan Neuschäfer
>
^ permalink raw reply
* Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
From: Arnd Bergmann @ 2018-02-21 16:03 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Rich Felker, Kernel Hardening, X86 ML, Paul Mackerras,
H. Peter Anvin, sparclinux, Sam Ravnborg, Yoshinori Sato,
Jonathan Corbet, Richard Weinberger, Linux-sh list, Ingo Molnar,
Emese Revfy, Kees Cook, uml-devel, Linux Kbuild mailing list,
Peter Oberparleiter, Jeff Dike, linuxppc-dev,
user-mode-linux-user, Thomas Gleixner, Michal Marek,
Ulf Magnusson, Greg Kroah-Hartman, Randy Dunlap,
open list:DOCUMENTATION, Linux Kernel Mailing List,
Linus Torvalds, David S. Miller
In-Reply-To: <CAK7LNAR3OMh9Q9ZfaBq=FpSJ-+DT5-RH_20ohV-iu34pX9hFKw@mail.gmail.com>
On Wed, Feb 21, 2018 at 1:57 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>>> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
>>>> <yamada.masahiro@socionext.com> wrote:
>>>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
>
> Hmm, I think I can implement those somehow.
> But, I hope we do not have many instances like this...
>
>
> If you know more naive cases, please share your knowledge.
>
One case that comes to mind would be architecture level selection on 32-bit
ARM, which is roughly this (I probably have some details wrong, but you
get the idea):
- older compilers don't support the latest architecture setting (-march=armv8
or -march=armv7ve)
- newer compilers no longer support really old architectures (-march=armv4)
- setting -mthumb requires setting one of -march=armv7-a, armv7ve, armv7-m or
armv8 if the compiler doesn't default to those
- on a compiler that defaults to -marm, setting -march=armv7-m requires
setting -mthumb (IIRC)
- really old compilers only support OABI, but not EABI
- newer compilers no longer support OABI
- mthumb requires EABI
- armv6 and higher are subtly broken with OABI, but only when using
certain inline assembly with 64-bit arguments in register pairs.
I think we just shouldn't try to capture all of the above correctly in Kconfig
conditionals.
Arnd
^ permalink raw reply
* Re: [PATCH 5/6] powerpc: Implement DISCONTIGMEM and allow selection on PPC32
From: Jonathan Neuschäfer @ 2018-02-21 16:08 UTC (permalink / raw)
To: kbuild test robot
Cc: Jonathan Neuschäfer, kbuild-all, linuxppc-dev, linux-kernel,
Michael Ellerman, linux-mm, Joel Stanley, Benjamin Herrenschmidt,
Paul Mackerras, Greg Kroah-Hartman, Thomas Gleixner,
Philippe Ombredanne, Kate Stewart, Nathan Fontenot,
Michael Bringmann, Thiago Jung Bauermann, Kees Cook
In-Reply-To: <201802210756.OZokd64C%fengguang.wu@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
On Wed, Feb 21, 2018 at 07:46:28AM +0800, kbuild test robot wrote:
[...]
> >> include/linux/mmzone.h:1239:19: error: conflicting types for 'pfn_valid'
> static inline int pfn_valid(unsigned long pfn)
> ^~~~~~~~~
> In file included from include/linux/mmzone.h:912:0,
> from include/linux/gfp.h:6,
> from include/linux/mm.h:10,
> from include/linux/mman.h:5,
> from arch/powerpc/kernel/asm-offsets.c:22:
> arch/powerpc/include/asm/mmzone.h:40:19: note: previous definition of 'pfn_valid' was here
> static inline int pfn_valid(int pfn)
> ^~~~~~~~~
> make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
> make[2]: Target '__build' not remade because of errors.
> make[1]: *** [prepare0] Error 2
> make[1]: Target 'prepare' not remade because of errors.
> make: *** [sub-make] Error 2
Oops, I'll fix this in the next version (and compile-test on ppc64...).
Weirdly enough, x86-32 and parisc define pfn_valid with an int
parameter, too (both of them since the Beginning Of Time, aka.
v2.6.12-rc2).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
From: Jonathan Neuschäfer @ 2018-02-21 16:52 UTC (permalink / raw)
To: Christophe LEROY
Cc: Jonathan Neuschäfer, linuxppc-dev, Joel Stanley,
linux-kernel, linux-mm
In-Reply-To: <a36983ec-5e97-e968-8143-1b2615ea55f8@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On Wed, Feb 21, 2018 at 04:02:25PM +0100, Christophe LEROY wrote:
[...]
> > > My question might me stupid, as I don't know PCC64 in deep, but when looking
> > > at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling the PPC64
> > > implements ram by blocks. Isn't it what you are trying to achieve ? Wouldn't
> > > it be feasible to map to what's done in PPC64 for PPC32 ?
> >
> > Using page_is_ram in __ioremap_caller and the same memblock-based
> > approach that's used on PPC64 on PPC32 *should* work, but I think due to
> > the following line in initmem_init, it won't:
> >
> > memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock.memory, 0);
>
> Can't we just fix that ?
I'll give it a try.
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] powerpc: Implement DISCONTIGMEM and allow selection on PPC32
From: christophe leroy @ 2018-02-21 17:53 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: Kate Stewart, Kees Cook, Greg Kroah-Hartman, Philippe Ombredanne,
linux-kernel, linux-mm, Michael Bringmann, Paul Mackerras,
kbuild-all, Thiago Jung Bauermann, Nathan Fontenot,
Thomas Gleixner, linuxppc-dev, Joel Stanley
In-Reply-To: <20180221160815.dxhpsejt74zeqqjd@latitude>
Le 21/02/2018 à 17:08, Jonathan Neuschäfer a écrit :
> On Wed, Feb 21, 2018 at 07:46:28AM +0800, kbuild test robot wrote:
> [...]
>>>> include/linux/mmzone.h:1239:19: error: conflicting types for 'pfn_valid'
>> static inline int pfn_valid(unsigned long pfn)
>> ^~~~~~~~~
>> In file included from include/linux/mmzone.h:912:0,
>> from include/linux/gfp.h:6,
>> from include/linux/mm.h:10,
>> from include/linux/mman.h:5,
>> from arch/powerpc/kernel/asm-offsets.c:22:
>> arch/powerpc/include/asm/mmzone.h:40:19: note: previous definition of 'pfn_valid' was here
>> static inline int pfn_valid(int pfn)
>> ^~~~~~~~~
>> make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
>> make[2]: Target '__build' not remade because of errors.
>> make[1]: *** [prepare0] Error 2
>> make[1]: Target 'prepare' not remade because of errors.
>> make: *** [sub-make] Error 2
>
> Oops, I'll fix this in the next version (and compile-test on ppc64...).
>
> Weirdly enough, x86-32 and parisc define pfn_valid with an int
> parameter, too (both of them since the Beginning Of Time, aka.
> v2.6.12-rc2).
>
Behind the fact that the pfn type is different, my understanding is that
you have to define CONFIG_HAVE_ARCH_PFN_VALID in the Kconfig in order to
avoid it being included in include/linux/mmzone.h
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 v12 07/11] mm: Add address parameter to arch_validate_prot()
From: Khalid Aziz @ 2018-02-21 17:15 UTC (permalink / raw)
To: akpm, benh, paulus, mpe, davem, dave.hansen
Cc: Khalid Aziz, bsingharora, nborisov, aarcange, anthony.yznaga,
mgorman, linuxram, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, gregkh, tglx, mhocko, n-horiguchi, jglisse,
henry.willard, aneesh.kumar, khandual, linuxppc-dev, linux-kernel,
linux-mm, sparclinux, Khalid Aziz
In-Reply-To: <cover.1519227112.git.khalid.aziz@oracle.com>
A protection flag may not be valid across entire address space and
hence arch_validate_prot() might need the address a protection bit is
being set on to ensure it is a valid protection flag. For example, sparc
processors support memory corruption detection (as part of ADI feature)
flag on memory addresses mapped on to physical RAM but not on PFN mapped
pages or addresses mapped on to devices. This patch adds address to the
parameters being passed to arch_validate_prot() so protection bits can
be validated in the relevant context.
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Cc: Khalid Aziz <khalid@gonehiking.org>
Reviewed-by: Anthony Yznaga <anthony.yznaga@oracle.com>
---
v8:
- Added addr parameter to powerpc arch_validate_prot() (suggested
by Michael Ellerman)
v9:
- new patch
arch/powerpc/include/asm/mman.h | 4 ++--
arch/powerpc/kernel/syscalls.c | 2 +-
include/linux/mman.h | 2 +-
mm/mprotect.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
index 07e3f54de9e3..e3f1b5ba5d5c 100644
--- a/arch/powerpc/include/asm/mman.h
+++ b/arch/powerpc/include/asm/mman.h
@@ -43,7 +43,7 @@ static inline pgprot_t arch_vm_get_page_prot(unsigned long vm_flags)
}
#define arch_vm_get_page_prot(vm_flags) arch_vm_get_page_prot(vm_flags)
-static inline bool arch_validate_prot(unsigned long prot)
+static inline bool arch_validate_prot(unsigned long prot, unsigned long addr)
{
if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_SAO))
return false;
@@ -51,7 +51,7 @@ static inline bool arch_validate_prot(unsigned long prot)
return false;
return true;
}
-#define arch_validate_prot(prot) arch_validate_prot(prot)
+#define arch_validate_prot arch_validate_prot
#endif /* CONFIG_PPC64 */
#endif /* _ASM_POWERPC_MMAN_H */
diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index a877bf8269fe..6d90ddbd2d11 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -48,7 +48,7 @@ static inline long do_mmap2(unsigned long addr, size_t len,
{
long ret = -EINVAL;
- if (!arch_validate_prot(prot))
+ if (!arch_validate_prot(prot, addr))
goto out;
if (shift) {
diff --git a/include/linux/mman.h b/include/linux/mman.h
index 6a4d1caaff5c..4b08e9c9c538 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -92,7 +92,7 @@ static inline void vm_unacct_memory(long pages)
*
* Returns true if the prot flags are valid
*/
-static inline bool arch_validate_prot(unsigned long prot)
+static inline bool arch_validate_prot(unsigned long prot, unsigned long addr)
{
return (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0;
}
diff --git a/mm/mprotect.c b/mm/mprotect.c
index e3309fcf586b..088ea9c08678 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -417,7 +417,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
end = start + len;
if (end <= start)
return -ENOMEM;
- if (!arch_validate_prot(prot))
+ if (!arch_validate_prot(prot, start))
return -EINVAL;
reqprot = prot;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries: Fix duplicate firmware feature for DRC_INFO
From: Tyrel Datwyler @ 2018-02-21 21:37 UTC (permalink / raw)
To: Michael Ellerman, mwb, nfont; +Cc: linuxppc-dev
In-Reply-To: <20180221130523.27836-1-mpe@ellerman.id.au>
On 02/21/2018 05:05 AM, Michael Ellerman wrote:
> We had a mid-air collision between two new firmware features, DRMEM_V2
> and DRC_INFO, and they ended up with the same value.
>
> No one's actually reported any problems, presumably because the new
> firmware that supports both properties is not widely available, and
> the two properties tend to be enabled together.
>
> Still if we ever had one enabled but not the other, the bugs that
> could result are many and varied. So fix it.
>
> Fixes: 3f38000eda48 ("powerpc/firmware: Add definitions for new drc-info firmware feature")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
Good catch.
Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> arch/powerpc/include/asm/firmware.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
> index 511acfd7ab0d..535add3f7791 100644
> --- a/arch/powerpc/include/asm/firmware.h
> +++ b/arch/powerpc/include/asm/firmware.h
> @@ -52,7 +52,7 @@
> #define FW_FEATURE_TYPE1_AFFINITY ASM_CONST(0x0000000100000000)
> #define FW_FEATURE_PRRN ASM_CONST(0x0000000200000000)
> #define FW_FEATURE_DRMEM_V2 ASM_CONST(0x0000000400000000)
> -#define FW_FEATURE_DRC_INFO ASM_CONST(0x0000000400000000)
> +#define FW_FEATURE_DRC_INFO ASM_CONST(0x0000000800000000)
>
> #ifndef __ASSEMBLY__
>
^ permalink raw reply
* Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
From: Ulf Magnusson @ 2018-02-21 21:39 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Arnd Bergmann, Rich Felker, Kernel Hardening, X86 ML,
Paul Mackerras, H. Peter Anvin, sparclinux, Sam Ravnborg,
Yoshinori Sato, Jonathan Corbet, Richard Weinberger,
Linux-sh list, Ingo Molnar, Emese Revfy, Kees Cook, uml-devel,
Linux Kbuild mailing list, Peter Oberparleiter, Jeff Dike,
linuxppc-dev, user-mode-linux-user, Thomas Gleixner, Michal Marek,
Greg Kroah-Hartman, Randy Dunlap, open list:DOCUMENTATION,
Linux Kernel Mailing List, Linus Torvalds, David S. Miller
In-Reply-To: <CAK7LNAR3OMh9Q9ZfaBq=FpSJ-+DT5-RH_20ohV-iu34pX9hFKw@mail.gmail.com>
On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
> > <yamada.masahiro@socionext.com> wrote:
> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
> >>> <yamada.masahiro@socionext.com> wrote:
> >>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> >>
> >> Let me clarify my concern.
> >>
> >> When we test the compiler flag, is there a case
> >> where a particular flag depends on -m{32,64} ?
> >>
> >> For example, is there a compiler that supports -fstack-protector
> >> for 64bit mode, but unsupports it for 32bit mode?
> >>
> >> $(cc-option -m32) -> y
> >> $(cc-option -m64) -> y
> >> $(cc-option -fstack-protector) -> y
> >> $(cc-option -m32 -fstack-protector) -> n
> >> $(cc-option -m64 -fstack-protector) -> y
> >>
> >> I guess this is unlikely to happen,
> >> but I am not whether it is zero possibility.
> >>
> >> If this could happen,
> >> $(cc-option ) must be evaluated together with
> >> correct bi-arch option (either -m32 or -m64).
> >>
> >>
> >> Currently, -m32/-m64 is specified in Makefile,
> >> but we are moving compiler tests to Kconfig
> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
> >
> > I don't think it can happen for this particular combination (stack protector
> > and word size), but I'm sure we'll eventually run into options that
> > need to be tested in combination. For the current CFLAGS_KERNEL
> > setting, we definitely have the case of needing the variables to be
> > evaluated in a specific order.
> >
>
>
>
>
> I was thinking of how we can handle complex cases
> in the current approach.
>
>
>
> (Case 1)
>
> Compiler flag -foo and -bar interacts, so
> we also need to check the combination of the two.
>
>
> config CC_HAS_FOO
> def_bool $(cc-option -foo)
>
> config CC_HAS_BAR
> def_bool $(cc-option -bar)
>
> config CC_HAS_FOO_WITH_BAR
> def_bool $(cc-option -foo -bar)
>
>
>
> (Case 2)
> Compiler flag -foo is sensitive to word-size.
> So, we need to test this option together with -m32/-m64.
> User can toggle CONFIG_64BIT, like i386/x86_64.
>
>
> config CC_NEEDS_M64
> def_bool $(cc-option -m64) && 64BIT
>
> config CC_NEEDS_M32
> def_bool $(cc-option -m32) && !64BIT
>
> config CC_HAS_FOO
> bool
> default $(cc-option -m64 -foo) if CC_NEEDS_M64
> default $(cc-option -m32 -foo) if CC_NEEDS_M32
> default $(cc-option -foo)
>
>
>
> (Case 3)
> Compiler flag -foo is sensitive to endian-ness.
>
>
> config CC_NEEDS_BIG_ENDIAN
> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
>
> config CC_NEEDS_LITTLE_ENDIAN
> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
>
> config CC_HAS_FOO
> bool
> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
> default $(cc-option -mlittle-endian -foo) if CC_NEEDS_LITTLE_ENDIAN
> default $(cc-option -foo)
>
>
>
>
> Hmm, I think I can implement those somehow.
> But, I hope we do not have many instances like this...
>
>
> If you know more naive cases, please share your knowledge.
>
> Thanks!
>
>
> --
> Best Regards
> Masahiro Yamada
Would get pretty bad if a test needs to consider multiple symbols.
Exponential explosion there...
I thought some more about the implementation of dynamic (post-parsing)
functions to see how bad it would get with the current implementation.
Some background on how things work now:
1. All expression operands in Kconfig are symbols.
2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
you symbols with those strings as names and S_UNKNOWN type (because
they act like references to undefined symbols).
3. For "foo-$(fn foo)", you also get a symbol with that string as its
name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
4. Symbols with S_UNKNOWN type get their name as their string value,
and the tristate value n.
So, if you do string expansion on the names of symbols with S_UNKNOWN
type in sym_calc_value(), you're almost there with the current
implementation, except for the tristate case.
Maybe you could set the tristate value of S_UNKNOWN symbols depending on
the string value you end up with. Things are getting pretty confusing at
that point.
Could have something like S_DYNAMIC as well. More Kconfig complexity...
Then there's other complications:
1. SYMBOL_CONST is no longer constant.
2. Dependency loop detection needs to consider symbol references
within strings.
3. Dependency loop detection relies on static knowledge of what
symbols a symbol depends on. That might get messy for certain
expansions, though it might be things you wouldn't do in practice.
4. Symbols still need to be properly invalidated. It looks like at
least menuconfig just does a dumb invalidate-everything whenever
the value of a symbol is changed though, so it might not require
extra work. (Bit messier in Kconfiglib, which does minimal
invalidation to keep scripts fast, but just need to extract a few
extra deps there.)
It looks like dynamic functions could get quite messy, but might be
doable if absolutely required. There's probably more devils in the
details though.
I don't think the static function model precludes switching models later
btw, when people have more experience.
Cheers,
Ulf
^ 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