LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 1/6] net/wan/fsl_ucc_hdlc: allow ucc index up to 4
From: Christophe LEROY @ 2018-08-29  7:09 UTC (permalink / raw)
  To: David Gounaris, qiang.zhao, netdev, linuxppc-dev
In-Reply-To: <917e8baf-3623-6fde-fed0-9ff859b72fea@c-s.fr>



Le 28/08/2018 à 15:34, Christophe LEROY a écrit :
> 
> 
> Le 28/08/2018 à 13:09, David Gounaris a écrit :
>> There is a need to allow higher indexes to be
>> able to support MPC83xx platforms. (UCC1-UCC5)
> 
> As far as I can see, MPC8358 has 8 UCCs (ref 
> https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/powerquicc-processors/powerquicc-ii-pro/powerquicc-ii-pro-processor-with-ddr2-tdm-pci-security-usb-quicc-engine-with-1-gb-ethernet-utopia:MPC8358E) 

Indeed, the code should use UCC_MAX_NUM which is defined in 
include/soc/fsl/qe/ucc.h

Christophe

> 
> 
> Christophe
> 
>>
>> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
>> ---
>>   drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c 
>> b/drivers/net/wan/fsl_ucc_hdlc.c
>> index 5f0366a125e2..3c0e0a1d19ba 100644
>> --- a/drivers/net/wan/fsl_ucc_hdlc.c
>> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
>> @@ -1015,7 +1015,7 @@ static int ucc_hdlc_probe(struct platform_device 
>> *pdev)
>>       }
>>       ucc_num = val - 1;
>> -    if ((ucc_num > 3) || (ucc_num < 0)) {
>> +    if ((ucc_num > 4) || (ucc_num < 0)) {
>>           dev_err(&pdev->dev, ": Invalid UCC num\n");
>>           return -EINVAL;
>>       }
>>

^ permalink raw reply

* Re: [PATCH v7 1/2] powerpc: Detect the presence of big-cores via "ibm,thread-groups"
From: Michael Neuling @ 2018-08-29  7:13 UTC (permalink / raw)
  To: Gautham R. Shenoy, Srikar Dronamraju, Michael Ellerman,
	Benjamin Herrenschmidt, Vaidyanathan Srinivasan, Akshay Adiga,
	Shilpasri G Bhat, Oliver O'Halloran, Nicholas Piggin,
	Murilo Opsfelder Araujo, Anton Blanchard
  Cc: linuxppc-dev, linux-kernel
In-Reply-To: <61048333bca549ffa275bf32eeb1a2480340a7e0.camel@neuling.org>

On Wed, 2018-08-29 at 17:04 +1000, Michael Neuling wrote:
> > +What: 		/sys/devices/system/cpu/cpu[0-9]+/small_core_siblings
>=20
> Shouldn't we put this in the topology/ subdir with with the other items l=
ike
> it?

Also, please follow the same format as *_sibilings files topology/ where th=
ey
are just a mask (this patch currently has it as a comma separated list).

Mikey

^ permalink raw reply

* Re: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
From: Christophe LEROY @ 2018-08-29  7:18 UTC (permalink / raw)
  To: Qiang Zhao, David Gounaris, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VI1PR04MB3247E6EBE63C39F5E1C792F191090@VI1PR04MB3247.eurprd04.prod.outlook.com>



Le 29/08/2018 à 04:54, Qiang Zhao a écrit :
> From: David Gounaris <david.gounaris@infinera.com>
> Date: 2018/8/28 19:09
>> Subject: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
>>
>> Set default HMASK to 0x0000 to use
>> promiscuous mode in the hdlc controller.

Why do you need to do that ?

An HDLC frame encapsulating Ethernet should look like:

HDLC Frame includes:
– Opening Flag		7E hex
– Address field		FF hex
– Control field		03 hex
– Information field	Original Ethernet Packet, 1522 octets max.
– FCS CRC16		(2 bytes)
– Closing Flag		7E hex

What do you mean by 'promiscuous mode' ?

In any case, should a filter mask be changed for promiscuous mode, I 
believe the change should be done at the time you enter promiscuous 
mode, not at all time.

Christophe

>>
>> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
>> ---
>>   drivers/net/wan/fsl_ucc_hdlc.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wan/fsl_ucc_hdlc.h b/drivers/net/wan/fsl_ucc_hdlc.h
>> index c21134c1f180..5bc3d1a6ca6e 100644
>> --- a/drivers/net/wan/fsl_ucc_hdlc.h
>> +++ b/drivers/net/wan/fsl_ucc_hdlc.h
>> @@ -134,7 +134,7 @@ struct ucc_hdlc_private {
>>
>>   #define HDLC_HEAD_MASK		0x0000
>>   #define DEFAULT_HDLC_HEAD	0xff44
>> -#define DEFAULT_ADDR_MASK	0x00ff
>> +#define DEFAULT_ADDR_MASK	0x0000
>>   #define DEFAULT_HDLC_ADDR	0x00ff
>>
>>   #define BMR_GBL			0x20000000
>> --
> 
> It is not proper to set default HMASK to 0x0000, how about to add a new property standing for hmask into device tree,
> If get this property from dtb, then set it with the value from dtb, otherwise, set it with default HMASK ox00ff?
> 
> Best Regards
> Qiang Zhao
> 

^ permalink raw reply

* Re: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
From: Joakim Tjernlund @ 2018-08-29  7:28 UTC (permalink / raw)
  To: christophe.leroy@c-s.fr, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, qiang.zhao@nxp.com, David Gounaris
In-Reply-To: <4244fe46-e8ed-9fd2-d243-cc84e7264a88@c-s.fr>

T24gV2VkLCAyMDE4LTA4LTI5IGF0IDA5OjE4ICswMjAwLCBDaHJpc3RvcGhlIExFUk9ZIHdyb3Rl
Og0KPiBDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBv
cmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVz
cyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4N
Cj4gDQo+IA0KPiBMZSAyOS8wOC8yMDE4IMOgIDA0OjU0LCBRaWFuZyBaaGFvIGEgw6ljcml0IDoN
Cj4gPiBGcm9tOiBEYXZpZCBHb3VuYXJpcyA8ZGF2aWQuZ291bmFyaXNAaW5maW5lcmEuY29tPg0K
PiA+IERhdGU6IDIwMTgvOC8yOCAxOTowOQ0KPiA+ID4gU3ViamVjdDogW1BBVENIIDQvNl0gbmV0
L3dhbi9mc2xfdWNjX2hkbGM6IGRlZmF1bHQgaG1hc2sgdmFsdWUNCj4gPiA+IA0KPiA+ID4gU2V0
IGRlZmF1bHQgSE1BU0sgdG8gMHgwMDAwIHRvIHVzZQ0KPiA+ID4gcHJvbWlzY3VvdXMgbW9kZSBp
biB0aGUgaGRsYyBjb250cm9sbGVyLg0KPiANCj4gV2h5IGRvIHlvdSBuZWVkIHRvIGRvIHRoYXQg
Pw0KPiANCj4gQW4gSERMQyBmcmFtZSBlbmNhcHN1bGF0aW5nIEV0aGVybmV0IHNob3VsZCBsb29r
IGxpa2U6DQo+IA0KPiBIRExDIEZyYW1lIGluY2x1ZGVzOg0KPiDigJMgT3BlbmluZyBGbGFnICAg
ICAgICAgIDdFIGhleA0KPiDigJMgQWRkcmVzcyBmaWVsZCAgICAgICAgIEZGIGhleA0KPiDigJMg
Q29udHJvbCBmaWVsZCAgICAgICAgIDAzIGhleA0KPiDigJMgSW5mb3JtYXRpb24gZmllbGQgICAg
IE9yaWdpbmFsIEV0aGVybmV0IFBhY2tldCwgMTUyMiBvY3RldHMgbWF4Lg0KPiDigJMgRkNTIENS
QzE2ICAgICAgICAgICAgICgyIGJ5dGVzKQ0KPiDigJMgQ2xvc2luZyBGbGFnICAgICAgICAgIDdF
IGhleA0KDQpJbiBvdXIgY2FzZSB0aGUgRXRoIGZyYW1lIHN0YXJ0cyBkaXJlY3RseSBhZnRlciB0
aGUgT3BlbmluZyBGbGFnIHNvDQp0aGVyZSBpcyBubyBGRiBhZGRyZXNzIGZpZWxkLg0KDQo+IA0K
PiBXaGF0IGRvIHlvdSBtZWFuIGJ5ICdwcm9taXNjdW91cyBtb2RlJyA/DQoNCkp1c3QgdGhhdCB3
ZSBkb24ndCB3YW50IGFueSBhZGRyZXNzIGZpbHRlcmluZyBvZiBwYWNrZXRzLiBJIGRvbid0IHRo
aW5rIHRoaXMgd291bGQNCmJlIGEgcHJvYmxlbSBmb3IgcHVyZSBIRExDIGZyYW1lcyBlaXRoZXIs
IGRvIHlvdT8NCg0KPiANCj4gSW4gYW55IGNhc2UsIHNob3VsZCBhIGZpbHRlciBtYXNrIGJlIGNo
YW5nZWQgZm9yIHByb21pc2N1b3VzIG1vZGUsIEkNCj4gYmVsaWV2ZSB0aGUgY2hhbmdlIHNob3Vs
ZCBiZSBkb25lIGF0IHRoZSB0aW1lIHlvdSBlbnRlciBwcm9taXNjdW91cw0KPiBtb2RlLCBub3Qg
YXQgYWxsIHRpbWUuDQo+IA0KPiBDaHJpc3RvcGhlDQo+IA0KPiA+ID4gDQo+ID4gPiBTaWduZWQt
b2ZmLWJ5OiBEYXZpZCBHb3VuYXJpcyA8ZGF2aWQuZ291bmFyaXNAaW5maW5lcmEuY29tPg0KPiA+
ID4gLS0tDQo+ID4gPiAgIGRyaXZlcnMvbmV0L3dhbi9mc2xfdWNjX2hkbGMuaCB8IDIgKy0NCj4g
PiA+ICAgMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pDQo+ID4g
PiANCj4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC93YW4vZnNsX3VjY19oZGxjLmggYi9k
cml2ZXJzL25ldC93YW4vZnNsX3VjY19oZGxjLmgNCj4gPiA+IGluZGV4IGMyMTEzNGMxZjE4MC4u
NWJjM2QxYTZjYTZlIDEwMDY0NA0KPiA+ID4gLS0tIGEvZHJpdmVycy9uZXQvd2FuL2ZzbF91Y2Nf
aGRsYy5oDQo+ID4gPiArKysgYi9kcml2ZXJzL25ldC93YW4vZnNsX3VjY19oZGxjLmgNCj4gPiA+
IEBAIC0xMzQsNyArMTM0LDcgQEAgc3RydWN0IHVjY19oZGxjX3ByaXZhdGUgew0KPiA+ID4gDQo+
ID4gPiAgICNkZWZpbmUgSERMQ19IRUFEX01BU0sgICAgICAgICAgICAgMHgwMDAwDQo+ID4gPiAg
ICNkZWZpbmUgREVGQVVMVF9IRExDX0hFQUQgIDB4ZmY0NA0KPiA+ID4gLSNkZWZpbmUgREVGQVVM
VF9BRERSX01BU0sgICAweDAwZmYNCj4gPiA+ICsjZGVmaW5lIERFRkFVTFRfQUREUl9NQVNLICAg
MHgwMDAwDQo+ID4gPiAgICNkZWZpbmUgREVGQVVMVF9IRExDX0FERFIgIDB4MDBmZg0KPiA+ID4g
DQo+ID4gPiAgICNkZWZpbmUgQk1SX0dCTCAgICAgICAgICAgICAgICAgICAgMHgyMDAwMDAwMA0K
PiA+ID4gLS0NCj4gPiANCj4gPiBJdCBpcyBub3QgcHJvcGVyIHRvIHNldCBkZWZhdWx0IEhNQVNL
IHRvIDB4MDAwMCwgaG93IGFib3V0IHRvIGFkZCBhIG5ldyBwcm9wZXJ0eSBzdGFuZGluZyBmb3Ig
aG1hc2sgaW50byBkZXZpY2UgdHJlZSwNCj4gPiBJZiBnZXQgdGhpcyBwcm9wZXJ0eSBmcm9tIGR0
YiwgdGhlbiBzZXQgaXQgd2l0aCB0aGUgdmFsdWUgZnJvbSBkdGIsIG90aGVyd2lzZSwgc2V0IGl0
IHdpdGggZGVmYXVsdCBITUFTSyBveDAwZmY/DQo+ID4gDQo+ID4gQmVzdCBSZWdhcmRzDQo+ID4g
UWlhbmcgWmhhbw0KPiA+IA0KDQo=

^ permalink raw reply

* [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
From: Krzysztof Kozlowski @ 2018-08-29  7:32 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Krzysztof Kozlowski, linuxppc-dev, linux-kernel
  Cc: Michal Kubecek

After commit faa16bc404d7 ("lib: Use existing define with
polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
directory thus any other user of this code should define proper include
path.

This fixes the build error on powerpc with CONFIG_KERNEL_XZ:

    In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
                     from ../arch/powerpc/boot/decompress.c:42:
    ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory

Reported-by: Michal Kubecek <mkubecek@suse.cz>
Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Only compile tested.
---
 arch/powerpc/boot/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 0fb96c26136f..ba4182fb185d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -63,7 +63,7 @@ ifeq ($(call cc-option-yn, -fstack-protector),y)
 BOOTCFLAGS	+= -fno-stack-protector
 endif
 
-BOOTCFLAGS	+= -I$(objtree)/$(obj) -I$(srctree)/$(obj)
+BOOTCFLAGS	+= -I$(objtree)/$(obj) -I$(srctree)/$(obj) -I$(srctree)/include
 
 DTC_FLAGS	?= -p 1024
 
-- 
2.7.4

^ permalink raw reply related

* Re: [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
From: Krzysztof Kozlowski @ 2018-08-29  7:55 UTC (permalink / raw)
  To: benh, paulus, mpe, linuxppc-dev, linux-kernel; +Cc: mkubecek
In-Reply-To: <1535527943-32566-1-git-send-email-krzk@kernel.org>

On Wed, 29 Aug 2018 at 09:32, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> After commit faa16bc404d7 ("lib: Use existing define with
> polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
> directory thus any other user of this code should define proper include
> path.
>
> This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
>
>     In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
>                      from ../arch/powerpc/boot/decompress.c:42:
>     ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory
>
> Reported-by: Michal Kubecek <mkubecek@suse.cz>

Reported earlier by Kbuild:
https://lkml.org/lkml/2018/8/23/47

for the credits:
Reported-by: kbuild test robot <lkp@intel.com>

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH] powerpc/time: Calculate proper wday
From: Joakim Tjernlund @ 2018-08-29  7:54 UTC (permalink / raw)
  To: linuxppc-dev

to_tm() hardcodes wday to -1 as "No-one uses the day of the week".
But recently rtc driver ds1307 does care and tries to correct wday.

Add wday calculation(stolen from rtc_time64_to_tm) to to_tm() to please ds1307.

Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
---
 arch/powerpc/kernel/time.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index fe6f3a285455..f4a09ee01944 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1160,6 +1160,9 @@ void to_tm(int tim, struct rtc_time * tm)
 	day = tim / SECDAY;
 	hms = tim % SECDAY;
 
+	/* day of the week, 1970-01-01 was a Thursday */
+	tm->tm_wday = (day + 4) % 7;
+
 	/* Hours, minutes, seconds are easy */
 	tm->tm_hour = hms / 3600;
 	tm->tm_min = (hms % 3600) / 60;
@@ -1180,11 +1183,6 @@ void to_tm(int tim, struct rtc_time * tm)
 
 	/* Days are what is left over (+1) from all that. */
 	tm->tm_mday = day + 1;
-
-	/*
-	 * No-one uses the day of the week.
-	 */
-	tm->tm_wday = -1;
 }
 EXPORT_SYMBOL(to_tm);
 
-- 
2.16.4

^ permalink raw reply related

* Re: [PATCH 2/2] sched/topology: Expose numa_mask set/clear functions to arch
From: Peter Zijlstra @ 2018-08-29  8:02 UTC (permalink / raw)
  To: Srikar Dronamraju
  Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
	Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
	Andre Wild, linuxppc-dev
In-Reply-To: <1533920419-17410-2-git-send-email-srikar@linux.vnet.ibm.com>

On Fri, Aug 10, 2018 at 10:30:19PM +0530, Srikar Dronamraju wrote:
> With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> sched domain") scheduler introduces an new numa level. However on shared
> lpars like powerpc, this extra sched domain creation can lead to
> repeated rcu stalls, sometimes even causing unresponsive systems on
> boot. On such stalls, it was noticed that init_sched_groups_capacity()
> (sg != sd->groups is always true).
> 
> INFO: rcu_sched self-detected stall on CPU
>  1-....: (240039 ticks this GP) idle=c32/1/4611686018427387906 softirq=782/782 fqs=80012
>   (t=240039 jiffies g=6272 c=6271 q=263040)
> NMI backtrace for cpu 1

> --- interrupt: 901 at __bitmap_weight+0x70/0x100
>     LR = __bitmap_weight+0x78/0x100
> [c00000832132f9b0] [c0000000009bb738] __func__.61127+0x0/0x20 (unreliable)
> [c00000832132fa00] [c00000000016c178] build_sched_domains+0xf98/0x13f0
> [c00000832132fb30] [c00000000016d73c] partition_sched_domains+0x26c/0x440
> [c00000832132fc20] [c0000000001ee284] rebuild_sched_domains_locked+0x64/0x80
> [c00000832132fc50] [c0000000001f11ec] rebuild_sched_domains+0x3c/0x60
> [c00000832132fc80] [c00000000007e1c4] topology_work_fn+0x24/0x40
> [c00000832132fca0] [c000000000126704] process_one_work+0x1a4/0x470
> [c00000832132fd30] [c000000000126a68] worker_thread+0x98/0x540
> [c00000832132fdc0] [c00000000012f078] kthread+0x168/0x1b0
> [c00000832132fe30] [c00000000000b65c]
> ret_from_kernel_thread+0x5c/0x80
> 
> Similar problem was earlier also reported at
> https://lwn.net/ml/linux-kernel/20180512100233.GB3738@osiris/
> 
> Allow arch to set and clear masks corresponding to numa sched domain.

What this Changelog fails to do is explain the problem and motivate why
this is the right solution.

As-is, this reads like, something's buggered, I changed this random thing
and it now works.

So what is causing that domain construction error?

^ permalink raw reply

* Re: [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
From: Mathieu Malaterre @ 2018-08-29  8:06 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	linuxppc-dev, LKML, mkubecek, Meelis Roos
In-Reply-To: <CAJKOXPe-fY5T8DMTgjQfrJN=b_9JcytYeeqkX9rQw6EbQ_GiXA@mail.gmail.com>

On Wed, Aug 29, 2018 at 9:59 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Wed, 29 Aug 2018 at 09:32, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > After commit faa16bc404d7 ("lib: Use existing define with
> > polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
> > directory thus any other user of this code should define proper include
> > path.
> >
> > This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
> >
> >     In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
> >                      from ../arch/powerpc/boot/decompress.c:42:
> >     ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory
> >
> > Reported-by: Michal Kubecek <mkubecek@suse.cz>
>
> Reported earlier by Kbuild:
> https://lkml.org/lkml/2018/8/23/47
>
> for the credits:
> Reported-by: kbuild test robot <lkp@intel.com>

Technically Meelis reported it earlier:

https://lkml.org/lkml/2018/8/22/365

;)

^ permalink raw reply

* Re: [PATCH] powerpc: disable support for relative ksymtab references
From: Nicholas Piggin @ 2018-08-29  8:09 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: linuxppc-dev, schwab, jeyu, mpe, will.deacon, mingo, akpm,
	linux-arch, Linus Torvalds
In-Reply-To: <20180829064753.7133-1-ard.biesheuvel@linaro.org>

On Wed, 29 Aug 2018 08:47:53 +0200
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> The newly added code that emits ksymtab entries as pairs of 32-bit
> relative references interacts poorly with the way powerpc lays out
> its address space: when a module exports a per-CPU variable, the
> primary module region covering the ksymtab entry -and thus the 32-bit
> relative reference- is too far away from the actual per-CPU variable's
> base address (to which the per-CPU offsets are applied to obtain the
> respective address of each CPU's copy), resulting in corruption when
> the module loader attempts to resolve symbol references of modules
> that are loaded on top and link to the exported per-CPU symbol.
> 
> So let's disable this feature on powerpc. Even though it implements
> CONFIG_RELOCATABLE, it does not implement CONFIG_RANDOMIZE_BASE and
> so KASLR kernels (which are the main target of the feature) do not
> exist on powerpc anyway.

Let's go with this for now. We have a bit more work to do with module
loader, linker, percpu, or all of the above. Thanks everyone.

Linus can you merge this? I think Michael is on vacation this week and
things are pretty crashy without it here. Don't need to call him off
the beach for it.

Thanks,
Nick

> 
> Reported-by: Andreas Schwab <schwab@linux-m68k.org>
> Suggested-by: Nicholas Piggin <nicholas.piggin@gmail.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/powerpc/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index db0b6eebbfa5..a80669209155 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -177,7 +177,6 @@ config PPC
>  	select HAVE_ARCH_KGDB
>  	select HAVE_ARCH_MMAP_RND_BITS
>  	select HAVE_ARCH_MMAP_RND_COMPAT_BITS	if COMPAT
> -	select HAVE_ARCH_PREL32_RELOCATIONS
>  	select HAVE_ARCH_SECCOMP_FILTER
>  	select HAVE_ARCH_TRACEHOOK
>  	select HAVE_CBPF_JIT			if !PPC64
> -- 
> 2.17.1
> 

^ permalink raw reply

* Re: [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
From: Krzysztof Kozlowski @ 2018-08-29  8:12 UTC (permalink / raw)
  To: malat; +Cc: benh, paulus, mpe, linuxppc-dev, linux-kernel, mkubecek, mroos
In-Reply-To: <CA+7wUsxE5gUXuUzkZ5bjz_d5WXab8RQxF3bre_DAMpUW=QpKTg@mail.gmail.com>

On Wed, 29 Aug 2018 at 10:06, Mathieu Malaterre <malat@debian.org> wrote:
>
> On Wed, Aug 29, 2018 at 9:59 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Wed, 29 Aug 2018 at 09:32, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > After commit faa16bc404d7 ("lib: Use existing define with
> > > polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
> > > directory thus any other user of this code should define proper include
> > > path.
> > >
> > > This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
> > >
> > >     In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
> > >                      from ../arch/powerpc/boot/decompress.c:42:
> > >     ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory
> > >
> > > Reported-by: Michal Kubecek <mkubecek@suse.cz>
> >
> > Reported earlier by Kbuild:
> > https://lkml.org/lkml/2018/8/23/47
> >
> > for the credits:
> > Reported-by: kbuild test robot <lkp@intel.com>
>
> Technically Meelis reported it earlier:
>
> https://lkml.org/lkml/2018/8/22/365
>
> ;)

Oh, right... so for the full credits:
Reported-by: Meelis Roos <mroos@linux.ee>

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCH] sched/topology: Use Identity node only if required
From: Peter Zijlstra @ 2018-08-29  8:43 UTC (permalink / raw)
  To: Srikar Dronamraju
  Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
	Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
	linuxppc-dev, Andre Wild
In-Reply-To: <20180810164533.GB42350@linux.vnet.ibm.com>

On Fri, Aug 10, 2018 at 09:45:33AM -0700, Srikar Dronamraju wrote:

> available: 4 nodes (0-3)
> node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39 64 65 66 67 68 69 70 71 96 97 98 99 100 101 102 103 128 129 130 131 132 133 134 135 160 161 162 163 164 165 166 167 192 193 194 195 196 197 198 199 224 225 226 227 228 229 230 231 256 257 258 259 260 261 262 263 288 289 290 291 292 293 294 295
> node 0 size: 536888 MB
> node 0 free: 533582 MB
> node 1 cpus: 24 25 26 27 28 29 30 31 56 57 58 59 60 61 62 63 88 89 90 91 92 93 94 95 120 121 122 123 124 125 126 127 152 153 154 155 156 157 158 159 184 185 186 187 188 189 190 191 216 217 218 219 220 221 222 223 248 249 250 251 252 253 254 255 280 281 282 283 284 285 286 287
> node 1 size: 502286 MB
> node 1 free: 501283 MB
> node 2 cpus: 16 17 18 19 20 21 22 23 48 49 50 51 52 53 54 55 80 81 82 83 84 85 86 87 112 113 114 115 116 117 118 119 144 145 146 147 148 149 150 151 176 177 178 179 180 181 182 183 208 209 210 211 212 213 214 215 240 241 242 243 244 245 246 247 272 273 274 275 276 277 278 279
> node 2 size: 503054 MB
> node 2 free: 502854 MB
> node 3 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47 72 73 74 75 76 77 78 79 104 105 106 107 108 109 110 111 136 137 138 139 140 141 142 143 168 169 170 171 172 173 174 175 200 201 202 203 204 205 206 207 232 233 234 235 236 237 238 239 264 265 266 267 268 269 270 271 296 297 298 299 300 301 302 303
> node 3 size: 503310 MB
> node 3 free: 498465 MB
> node distances:
> node   0   1   2   3
>   0:  10  40  40  40
>   1:  40  10  40  40
>   2:  40  40  10  40
>   3:  40  40  40  10
> 
> Extracting the contents of dmesg using sched_debug kernel parameter
> 
> CPU0 attaching NULL sched-domain.
> CPU1 attaching NULL sched-domain.
> ....
> ....
> CPU302 attaching NULL sched-domain.
> CPU303 attaching NULL sched-domain.
> BUG: arch topology borken
>      the DIE domain not a subset of the NODE domain

^^^^^ CLUE!!

but nowhere did you show what it thinks the DIE mask is.

>  CPU0 attaching sched-domain(s):
>    domain-2: sdA, span=0-303 level=NODE
>     groups: sg=sgL 0:{ span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295 cap=81920 }, sgM 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }, sdN 16:{ span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=73728 }, sgO 24:{ span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=73728 }
> CPU1  attaching sched-domain(s):
>    domain-2: sdB, span=0-303 level=NODE
> [  367.739387]     groups: sg=sgL 0:{ span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295 cap=81920 }, sgM 8:{ span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303 cap=81920 }, sdN 16:{ span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279 cap=73728 }, sgO 24:{ span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287 cap=73728 }

You forgot to provide the rest of it... what's domain-[01] look like?

DIE(j) should be:

	cpu_cpu_mask(j) := cpumask_of_node(cpu_to_node(j))

and NODE(j) should be:

	\Union_k cpumask_of_node(k) ; where node_distance(j,k) <= node_distance(0,0)

which, _should_ reduce to:

	cpumask_of_node(j)

and thus DIE and NODE _should_ be the same here.

So what's going sideways?

^ permalink raw reply

* RE: [PATCH] soc: Convert to using %pOFn instead of device_node.name
From: Qiang Zhao @ 2018-08-29  8:57 UTC (permalink / raw)
  To: Rob Herring, linux-kernel@vger.kernel.org
  Cc: Leo Li, Andy Gross, David Brown, Heiko Stuebner, Thierry Reding,
	Jonathan Hunter, Santosh Shilimkar, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org, linux-soc@vger.kernel.org
In-Reply-To: <20180828015252.28511-43-robh@kernel.org>

RnJvbTogUm9iIEhlcnJpbmcgPHJvYmhAa2VybmVsLm9yZz4NCkRhdGU6IDIwMTjE6jjUwjI4yNUg
OTo1Mw0KPiBUbzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZw0KPiBDYzogUWlhbmcgWmhh
byA8cWlhbmcuemhhb0BueHAuY29tPjsgTGVvIExpIDxsZW95YW5nLmxpQG54cC5jb20+OyBBbmR5
DQo+IEdyb3NzIDxhbmR5Lmdyb3NzQGxpbmFyby5vcmc+OyBEYXZpZCBCcm93biA8ZGF2aWQuYnJv
d25AbGluYXJvLm9yZz47IEhlaWtvDQo+IFN0dWVibmVyIDxoZWlrb0BzbnRlY2guZGU+OyBUaGll
cnJ5IFJlZGluZyA8dGhpZXJyeS5yZWRpbmdAZ21haWwuY29tPjsNCj4gSm9uYXRoYW4gSHVudGVy
IDxqb25hdGhhbmhAbnZpZGlhLmNvbT47IFNhbnRvc2ggU2hpbGlta2FyDQo+IDxzc2FudG9zaEBr
ZXJuZWwub3JnPjsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+IGxpbnV4LWFybS1r
ZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsgbGludXgtc29jQHZnZXIua2VybmVsLm9yZw0KPiBT
dWJqZWN0OiBbUEFUQ0hdIHNvYzogQ29udmVydCB0byB1c2luZyAlcE9GbiBpbnN0ZWFkIG9mIGRl
dmljZV9ub2RlLm5hbWUNCj4gDQo+IEluIHByZXBhcmF0aW9uIHRvIHJlbW92ZSB0aGUgbm9kZSBu
YW1lIHBvaW50ZXIgZnJvbSBzdHJ1Y3QgZGV2aWNlX25vZGUsDQo+IGNvbnZlcnQgcHJpbnRmIHVz
ZXJzIHRvIHVzZSB0aGUgJXBPRm4gZm9ybWF0IHNwZWNpZmllci4NCj4gDQo+IENjOiBRaWFuZyBa
aGFvIDxxaWFuZy56aGFvQG54cC5jb20+DQo+IENjOiBMaSBZYW5nIDxsZW95YW5nLmxpQG54cC5j
b20+DQo+IENjOiBBbmR5IEdyb3NzIDxhbmR5Lmdyb3NzQGxpbmFyby5vcmc+DQo+IENjOiBEYXZp
ZCBCcm93biA8ZGF2aWQuYnJvd25AbGluYXJvLm9yZz4NCj4gQ2M6IEhlaWtvIFN0dWVibmVyIDxo
ZWlrb0BzbnRlY2guZGU+DQo+IENjOiBUaGllcnJ5IFJlZGluZyA8dGhpZXJyeS5yZWRpbmdAZ21h
aWwuY29tPg0KPiBDYzogSm9uYXRoYW4gSHVudGVyIDxqb25hdGhhbmhAbnZpZGlhLmNvbT4NCj4g
Q2M6IFNhbnRvc2ggU2hpbGlta2FyIDxzc2FudG9zaEBrZXJuZWwub3JnPg0KPiBDYzogbGludXhw
cGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gQ2M6IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5m
cmFkZWFkLm9yZw0KPiBDYzogbGludXgtc29jQHZnZXIua2VybmVsLm9yZw0KPiBTaWduZWQtb2Zm
LWJ5OiBSb2IgSGVycmluZyA8cm9iaEBrZXJuZWwub3JnPg0KPiAtLS0NCj4gIGRyaXZlcnMvc29j
L2RvdmUvcG11LmMgICAgICAgICAgICB8ICA4ICsrKy0tLQ0KPiAgZHJpdmVycy9zb2MvZnNsL3Fl
L3FlX3RkbS5jICAgICAgIHwgIDQgKy0tDQo+ICBkcml2ZXJzL3NvYy9xY29tL2Fwci5jICAgICAg
ICAgICAgfCAgMiArLQ0KPiAgZHJpdmVycy9zb2Mvcm9ja2NoaXAvcG1fZG9tYWlucy5jIHwgNDQg
KysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLQ0KPiAgZHJpdmVycy9zb2MvdGVncmEvcG1j
LmMgICAgICAgICAgIHwgMTIgKysrKy0tLS0tDQo+ICBkcml2ZXJzL3NvYy90aS9rbmF2X2RtYS5j
ICAgICAgICAgfCAgOCArKystLS0NCj4gIGRyaXZlcnMvc29jL3RpL2tuYXZfcW1zc19xdWV1ZS5j
ICB8ICA4ICsrKy0tLQ0KPiAgNyBmaWxlcyBjaGFuZ2VkLCA0MyBpbnNlcnRpb25zKCspLCA0MyBk
ZWxldGlvbnMoLSkNCg0KRm9yIHFlX3RkbSBwYXJ0DQpBY2tlZC1ieTogUWlhbmcgWmhhbyA8cWlh
bmcuemhhb0BueHAuY29tPg0KDQo=

^ permalink raw reply

* Re: [PATCH] sched/topology: Use Identity node only if required
From: Peter Zijlstra @ 2018-08-29  8:57 UTC (permalink / raw)
  To: Srikar Dronamraju
  Cc: Ingo Molnar, LKML, Mel Gorman, Rik van Riel, Thomas Gleixner,
	Michael Ellerman, Heiko Carstens, Suravee Suthikulpanit,
	linuxppc-dev, Andre Wild
In-Reply-To: <20180829084348.GO24124@hirez.programming.kicks-ass.net>

On Wed, Aug 29, 2018 at 10:43:48AM +0200, Peter Zijlstra wrote:
> DIE(j) should be:
> 
> 	cpu_cpu_mask(j) := cpumask_of_node(cpu_to_node(j))

FWIW, I was expecting that to be topology_core_cpumask(), so I'm a
little confused myself just now.

> and NODE(j) should be:
> 
> 	\Union_k cpumask_of_node(k) ; where node_distance(j,k) <= node_distance(0,0)
> 
> which, _should_ reduce to:
> 
> 	cpumask_of_node(j)
> 
> and thus DIE and NODE _should_ be the same here.
> 
> So what's going sideways?

^ permalink raw reply

* Re: [PATCH] soc: Convert to using %pOFn instead of device_node.name
From: Heiko Stübner @ 2018-08-29  8:21 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-kernel, Qiang Zhao, Li Yang, Andy Gross, David Brown,
	Thierry Reding, Jonathan Hunter, Santosh Shilimkar, linuxppc-dev,
	linux-arm-kernel, linux-soc
In-Reply-To: <20180828015252.28511-43-robh@kernel.org>

Am Dienstag, 28. August 2018, 03:52:44 CEST schrieb Rob Herring:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.

>  drivers/soc/rockchip/pm_domains.c | 44 +++++++++++++++----------------

For the Rockchip-part
Acked-by: Heiko Stuebner <heiko@sntech.de>

^ permalink raw reply

* [PATCH] fsl: remove redundant pointer 'priv'
From: Colin King @ 2018-08-29  9:27 UTC (permalink / raw)
  To: Roy Pledge, Li Yang, linuxppc-dev, linux-arm-kernel
  Cc: kernel-janitors, linux-kernel

From: Colin Ian King <colin.king@canonical.com>

Pointer 'priv' is being assigned but is never used hence it is
redundant and can be removed.

Cleans up clang warning:
variable 'priv' set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/soc/fsl/dpio/dpio-driver.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
index b60b77bfaffa..e58fcc9096e8 100644
--- a/drivers/soc/fsl/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c
@@ -50,13 +50,10 @@ static void unregister_dpio_irq_handlers(struct fsl_mc_device *dpio_dev)
 
 static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu)
 {
-	struct dpio_priv *priv;
 	int error;
 	struct fsl_mc_device_irq *irq;
 	cpumask_t mask;
 
-	priv = dev_get_drvdata(&dpio_dev->dev);
-
 	irq = dpio_dev->irqs[0];
 	error = devm_request_irq(&dpio_dev->dev,
 				 irq->msi_desc->irq,
-- 
2.17.1

^ permalink raw reply related

* Re: [PATCH] fsl/qe: ucc: copy and paste bug in ucc_get_tdm_sync_shift()
From: Dan Carpenter @ 2018-08-29  9:39 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: qiang.zhao, kernel-janitors, linuxppc-dev, LKML, leoyang.li
In-Reply-To: <CA+7wUszWKm+qZQ7CQu3Kn7-aYeM-hSet03_PEh8EswNn141nyw@mail.gmail.com>

On Mon, Jun 04, 2018 at 02:06:45PM +0200, Mathieu Malaterre wrote:
> Where did the original go ?
> 
> https://patchwork.ozlabs.org/patch/868158/
> 
> 

Btw, we still haven't pushed a patch for this bug.

regards,
dan carpenter

^ permalink raw reply

* Re: [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
From: Michal Kubecek @ 2018-08-29 10:45 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	linuxppc-dev, linux-kernel
In-Reply-To: <1535527943-32566-1-git-send-email-krzk@kernel.org>

On Wed, Aug 29, 2018 at 09:32:23AM +0200, Krzysztof Kozlowski wrote:
> After commit faa16bc404d7 ("lib: Use existing define with
> polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
> directory thus any other user of this code should define proper include
> path.
> 
> This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
> 
>     In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
>                      from ../arch/powerpc/boot/decompress.c:42:
>     ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory
> 
> Reported-by: Michal Kubecek <mkubecek@suse.cz>
> Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> 
> ---
> 
> Only compile tested.
> ---
>  arch/powerpc/boot/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 0fb96c26136f..ba4182fb185d 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -63,7 +63,7 @@ ifeq ($(call cc-option-yn, -fstack-protector),y)
>  BOOTCFLAGS	+= -fno-stack-protector
>  endif
>  
> -BOOTCFLAGS	+= -I$(objtree)/$(obj) -I$(srctree)/$(obj)
> +BOOTCFLAGS	+= -I$(objtree)/$(obj) -I$(srctree)/$(obj) -I$(srctree)/include
>  
>  DTC_FLAGS	?= -p 1024
>  
> -- 
> 2.7.4
> 

With this patch 4.19-rc1 builds and boots on ppc64le. Thank you.

Tested-by: Michal Kubecek <mkubecek@suse.cz>

^ permalink raw reply

* Not able to boot cuImage for the target board with MPC8270 processor
From: sgosavi1 @ 2018-08-29 11:14 UTC (permalink / raw)
  To: linuxppc-dev

Hi Everyone,

Recently I took up the activity of switching from Linux kernel version
2.16.17.6 to version 4.15.13 for our target board that supports MPC8270
PowerPC  processor. As I understand the new kernel version mandates the use
of a device tree in the kernel source to describe the target board. I took
"pq2fads.dts" as a reference device tree file to port the kernel for our
target board. The U-boot version 1.1.4 that we currently use does not
support passing of device tree to kernel but passes the board information
structure used by the older kernel version we have been using so far. 

As suggested in the new kernel documentation I created a "cuImage.pq2fads"
kernel image which has the device tree and boot wrapper code embedded in the
image to support booting the kernel with older U-boot. However I am unable
to see any debug output after the dump from U-boot below.

U-Boot 1.1.4 (Aug  2 2018 - 06:27:35)

MPC8260 Reset Status: Check Stop, External Soft, External Hard

MPC8260 Clock Configuration
 - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq  25-75 , Core Freq 100-300
 - dfbrg 1, corecnf 0x1a, busdf 5, cpmdf 1, plldf 0, pllmf 5
 - vco_out  394515000, scc_clk   98628750, brg_clk   24657187
 - cpu_clk  263010000, cpm_clk  197257500, bus_clk   65752500

CPU:   MPC8260 (HiP7 Rev 14, Mask 1.0 1K49M) at 263.010 MHz
Board: Emerson MPC8270 CCB
Init SRAM, CAN, DOC...
UPMA done. Setting up UPMB
Rev B or Higher CPU Board
I2C:   ready
DRAM:  128 MB
FLASH: 16 MB
In:    serial
Out:   serial
Err:   serial
Net:   FCC1 ETHERNET, FCC2 ETHERNET
Press <foo> to STOP AUTOBOOT!:autoboot in 2 seconds
## Booting image at ffc00000 ...
   Image Name:   Linux-4.15.13
   Created:      2018-08-29  10:45:39 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1166748 Bytes =  1.1 MB
   Load Address: 00400000
   Entry Point:  004007a4
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK


I also checked the kernel dump at location associated with "_log_buf" symbol
in the System.map file in RAM but did not get any debug info.

Please can anyone suggest if I am missing something here and how can I get
the debug output on my serial console during bootup.

Thanks,
Sachin.
 



--
Sent from: http://linuxppc.10917.n7.nabble.com/linuxppc-dev-f3.html

^ permalink raw reply

* [RFC PATCH] powerpc/64/module: REL32 relocation range check
From: Nicholas Piggin @ 2018-08-29 11:56 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Nicholas Piggin, Alan Modra

The recent module relocation overflow crash demonstrated that we
have no range checking on REL32 relative relocations. This patch
implements a basic check, the same kernel that previously oopsed
and rebooted now continues with some of these errors when loading
the module:

    module_64: x_tables: REL32 527703503449812 out of range!

Question is whether other relocations (ADDR32, REL16, TOC16, etc.)
should also have overflow checks.
---
 arch/powerpc/kernel/module_64.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index a2636c250b7b..2a2fb656d23b 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -678,7 +678,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
 
 		case R_PPC64_REL32:
 			/* 32 bits relative (used by relative exception tables) */
-			*(u32 *)location = value - (unsigned long)location;
+			/* Convert value to relative */
+			value -= (unsigned long)location;
+			if (value + 0x80000000 > 0xffffffff) {
+				pr_err("%s: REL32 %li out of range!\n",
+				       me->name, (long int)value);
+				return -ENOEXEC;
+			}
+			*(u32 *)location = value;
 			break;
 
 		case R_PPC64_TOCSAVE:
-- 
2.18.0

^ permalink raw reply related

* Re: Not able to boot cuImage for the target board with MPC8270 processor
From: Christophe LEROY @ 2018-08-29 13:09 UTC (permalink / raw)
  To: sgosavi1, linuxppc-dev
In-Reply-To: <1535541276673-0.post@n7.nabble.com>



Le 29/08/2018 à 13:14, sgosavi1 a écrit :
> Hi Everyone,
> 
> Recently I took up the activity of switching from Linux kernel version
> 2.16.17.6 to version 4.15.13 for our target board that supports MPC8270
> PowerPC  processor. As I understand the new kernel version mandates the use
> of a device tree in the kernel source to describe the target board. I took
> "pq2fads.dts" as a reference device tree file to port the kernel for our
> target board. The U-boot version 1.1.4 that we currently use does not
> support passing of device tree to kernel but passes the board information
> structure used by the older kernel version we have been using so far.
> 
> As suggested in the new kernel documentation I created a "cuImage.pq2fads"
> kernel image which has the device tree and boot wrapper code embedded in the
> image to support booting the kernel with older U-boot. However I am unable
> to see any debug output after the dump from U-boot below.
> 
> U-Boot 1.1.4 (Aug  2 2018 - 06:27:35)
> 
> MPC8260 Reset Status: Check Stop, External Soft, External Hard
> 
> MPC8260 Clock Configuration
>   - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq  25-75 , Core Freq 100-300
>   - dfbrg 1, corecnf 0x1a, busdf 5, cpmdf 1, plldf 0, pllmf 5
>   - vco_out  394515000, scc_clk   98628750, brg_clk   24657187
>   - cpu_clk  263010000, cpm_clk  197257500, bus_clk   65752500
> 
> CPU:   MPC8260 (HiP7 Rev 14, Mask 1.0 1K49M) at 263.010 MHz
> Board: Emerson MPC8270 CCB
> Init SRAM, CAN, DOC...
> UPMA done. Setting up UPMB
> Rev B or Higher CPU Board
> I2C:   ready
> DRAM:  128 MB
> FLASH: 16 MB
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FCC1 ETHERNET, FCC2 ETHERNET
> Press <foo> to STOP AUTOBOOT!:autoboot in 2 seconds
> ## Booting image at ffc00000 ...
>     Image Name:   Linux-4.15.13
>     Created:      2018-08-29  10:45:39 UTC
>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>     Data Size:    1166748 Bytes =  1.1 MB
>     Load Address: 00400000
>     Entry Point:  004007a4
>     Verifying Checksum ... OK
>     Uncompressing Kernel Image ... OK
> 
> 
> I also checked the kernel dump at location associated with "_log_buf" symbol
> in the System.map file in RAM but did not get any debug info.
> 
> Please can anyone suggest if I am missing something here and how can I get
> the debug output on my serial console during bootup.

Have you selected CONFIG_PPC_EARLY_DEBUG (and probably 
CONFIG_PPC_EARLY_DEBUG_CPM) ?

Christophe

> 
> Thanks,
> Sachin.
>   
> 
> 
> 
> --
> Sent from: http://linuxppc.10917.n7.nabble.com/linuxppc-dev-f3.html
> 

^ permalink raw reply

* [PATCH v2 0/6] Ethernet over hdlc
From: David Gounaris @ 2018-08-29 13:13 UTC (permalink / raw)
  To: qiang.zhao, netdev, linuxppc-dev, robh+dt; +Cc: David Gounaris
In-Reply-To: <20180828110921.2542-2-david.gounaris@infinera.com>

Here is what has been changed in v2 after the review comments.

v2-0001: Using UCC_MAX_NUM
v2-0002: Unchanged
v2-0003: Changed commit message
v2-0004: Adding fsl,hmask into the dt instead of changing the default value.
v2-0005: Unchanged
v2-0006: Unchanged

Adding robh+dt@kernel.org for comments regarding dt.

Best Regards
David Gounaris

David Gounaris (6):
  net/wan/fsl_ucc_hdlc: allow ucc index up to 7
  net/wan/fsl_ucc_hdlc: allow PARITY_CRC16_PR0_CCITT parity
  net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
  net/wan/fsl_ucc_hdlc: hmask
  net/wan/fsl_ucc_hdlc: GUMR for non tsa mode
  net/wan/fsl_ucc_hdlc: tx timeout handler

 .../devicetree/bindings/soc/fsl/cpm_qe/network.txt |  6 +++++
 drivers/net/wan/fsl_ucc_hdlc.c                     | 28 +++++++++++++++++++---
 drivers/net/wan/fsl_ucc_hdlc.h                     |  1 +
 3 files changed, 32 insertions(+), 3 deletions(-)

-- 
2.13.6

^ permalink raw reply

* [PATCH v2 1/6] net/wan/fsl_ucc_hdlc: allow ucc index up to 7
From: David Gounaris @ 2018-08-29 13:13 UTC (permalink / raw)
  To: qiang.zhao, netdev, linuxppc-dev, robh+dt; +Cc: David Gounaris
In-Reply-To: <20180829131328.27901-1-david.gounaris@infinera.com>

There is a need to allow higher indexes to be
able to support MPC83xx platforms. (UCC1-UCC8)

Signed-off-by: David Gounaris <david.gounaris@infinera.com>
---
 drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 33df76405b86..5cf6dcba039c 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -1016,7 +1016,7 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
 	}
 
 	ucc_num = val - 1;
-	if ((ucc_num > 3) || (ucc_num < 0)) {
+	if ((ucc_num > UCC_MAX_NUM - 1) || (ucc_num < 0)) {
 		dev_err(&pdev->dev, ": Invalid UCC num\n");
 		return -EINVAL;
 	}
-- 
2.13.6

^ permalink raw reply related

* [PATCH v2 2/6] net/wan/fsl_ucc_hdlc: allow PARITY_CRC16_PR0_CCITT parity
From: David Gounaris @ 2018-08-29 13:13 UTC (permalink / raw)
  To: qiang.zhao, netdev, linuxppc-dev, robh+dt; +Cc: David Gounaris
In-Reply-To: <20180829131328.27901-1-david.gounaris@infinera.com>

Signed-off-by: David Gounaris <david.gounaris@infinera.com>
---
 drivers/net/wan/fsl_ucc_hdlc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 5cf6dcba039c..c8e526bf1130 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -781,7 +781,8 @@ static int ucc_hdlc_attach(struct net_device *dev, unsigned short encoding,
 
 	if (parity != PARITY_NONE &&
 	    parity != PARITY_CRC32_PR1_CCITT &&
-	    parity != PARITY_CRC16_PR1_CCITT)
+	    parity != PARITY_CRC16_PR1_CCITT && 
+	    parity != PARITY_CRC16_PR0_CCITT)
 		return -EINVAL;
 
 	priv->encoding = encoding;
-- 
2.13.6

^ permalink raw reply related

* [PATCH v2 3/6] net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
From: David Gounaris @ 2018-08-29 13:13 UTC (permalink / raw)
  To: qiang.zhao, netdev, linuxppc-dev, robh+dt; +Cc: David Gounaris
In-Reply-To: <20180829131328.27901-1-david.gounaris@infinera.com>

This patch is to avoid discarding ethernet
packets when using HDLC_ETH protocol.

Signed-off-by: David Gounaris <david.gounaris@infinera.com>
---
 drivers/net/wan/fsl_ucc_hdlc.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index c8e526bf1130..0f703d7be5e0 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -376,6 +376,10 @@ static netdev_tx_t ucc_hdlc_tx(struct sk_buff *skb, struct net_device *dev)
 		dev->stats.tx_bytes += skb->len;
 		break;
 
+	case ARPHRD_ETHER:
+		dev->stats.tx_bytes += skb->len;
+		break;
+
 	default:
 		dev->stats.tx_dropped++;
 		dev_kfree_skb(skb);
@@ -513,6 +517,8 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
 			break;
 
 		case ARPHRD_PPP:
+		case ARPHRD_ETHER:
+			
 			length -= HDLC_CRC_SIZE;
 
 			skb = dev_alloc_skb(length);
-- 
2.13.6

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox