Re: [PATCH] powerpc/boot/dts: Fix dtc "pciex" warnings

2020-09-11 Thread Christian Lamparter 

Hello,

On 2020-09-08 20:52, Christian Lamparter wrote:

On Tue, Sep 8, 2020 at 9:12 AM Michael Ellerman  wrote:

Christian Lamparter  writes:

On 2020-06-23 15:03, Michael Ellerman wrote:

With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
warnings about our dts files, such as:

arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
Warning (pci_bridge): /plb/pciex@d: node name is not "pci"
or "pcie"




Unfortunately yes. This patch will break uboot code in Meraki MX60(W) / MX60.

  > 
https://github.com/riptidewave93/meraki-uboot/blob/mx60w-20180413/board/amcc/bluestone/bluestone.c#L1178

| if (!pci_available()) {
| fdt_find_and_setprop(blob, "/plb/pciex@d", "status",
|   "disabled", sizeof("disabled"), 1);
| }


Backstory: There are two version of the Meraki MX60. The MX60
and the MX60W. The difference is that the MX60W has a populated
mini-pcie slot on the PCB for a >W

I'm happy to revert that hunk if you think any one is actually booting
mainline on those.


The MX60(W) or APM82181 in general?

The APM82181 devices run really well on the kernel 5.8. The APM82181
had some bitrot and missing pieces. But I started at around 4.4 with
upstreaming various bits and stuff. For proof, I can post a bootlog from
my MyBook Live dev station running my mbl-debian on this weekend:
.


Here is the MyBook Live's Single Bootlog for 5.9-rc4.

root@mbl-debian:~# dmesg
[0.00] printk: bootconsole [udbg0] enabled
[0.00] Linux version 5.9.0-rc4+ (root@debian64) (powerpc-linux-gnu-gcc 
(Debian 10.2.0-3) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 Fri Sep 11 
22:13:07 CEST 2020
[0.00] Using PowerPC 44x Platform machine description
[0.00] -
[0.00] phys_mem_size = 0x1000
[0.00] dcache_bsize  = 0x20
[0.00] icache_bsize  = 0x20
[0.00] cpu_features  = 0x0120
[0.00]   possible= 0x4120
[0.00]   always  = 0x0020
[0.00] cpu_user_features = 0x8c008000 0x
[0.00] mmu_features  = 0x0008
[0.00] -
[0.00] Top of RAM: 0x1000, Total RAM: 0x1000
[0.00] Memory hole size: 0MB
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x0fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x0fff]
[0.00] Initmem setup node 0 [mem 0x-0x0fff]
[0.00] On node 0 totalpages: 16384
[0.00]   Normal zone: 40 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 16384 pages, LIFO batch:3
[0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 16344
[0.00] Kernel command line: 
root=PARTUUID=25a9cfcc-6b0d-4ae4-abbf-e5e2e3889a40 rw console=ttyS0,115200
[0.00] Dentry cache hash table entries: 32768 (order: 3, 131072 bytes, 
linear)
[0.00] Inode-cache hash table entries: 16384 (order: 2, 65536 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] Memory: 252528K/262144K available (5840K kernel code, 448K 
rwdata, 1824K rodata, 224K init, 312K bss, 9616K reserved, 0K cma-reserved)
[0.00] Kernel virtual memory layout:
[0.00]   * 0xffbdc000..0xc000  : fixmap
[0.00]   * 0xd100..0xffbdc000  : vmalloc & ioremap
[0.00] random: get_random_u32 called from 
cache_random_seq_create+0x68/0x128 with crng_init=0
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
[0.00] UIC0 (32 IRQ sources) at DCR 0xc0
[0.00] UIC1 (32 IRQ sources) at DCR 0xd0
[0.00] UIC2 (32 IRQ sources) at DCR 0xe0
[0.00] UIC3 (32 IRQ sources) at DCR 0xf0
[0.00] time_init: decrementer frequency = 800.08 MHz
[0.00] time_init: processor frequency   = 800.08 MHz
[0.16] clocksource: timebase: mask: 0x max_cycles: 
0xb881274fa3, max_idle_ns: 440795210636 ns
[0.008990] clocksource: timebase mult[140] shift[24] registered
[0.014011] clockevent: decrementer mult[ccef] shift[32] cpu[0]
[0.019133] Console: colour dummy device 80x25
[0.022213] pid_max: default: 32768 minimum: 301
[0.025920] Mount-cache hash table entries: 4096 (order: 0, 16384 bytes, 
linear)
[0.031945] Mountpoint-cache hash table entries: 4096 (order: 0, 16384 
bytes, linear)
[0.040909] devtmpfs: initialized
[

Re: [PATCH] powerpc/boot/dts: Fix dtc "pciex" warnings

2020-09-08 Thread Christian Lamparter 
Hello,

On Tue, Sep 8, 2020 at 9:12 AM Michael Ellerman  wrote:
> Christian Lamparter  writes:
> > On 2020-06-23 15:03, Michael Ellerman wrote:
> >> With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
> >> warnings about our dts files, such as:
> >>
> >>arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
> >>Warning (pci_bridge): /plb/pciex@d: node name is not "pci"
> >>or "pcie"
> >>
> >
> >
> > Unfortunately yes. This patch will break uboot code in Meraki MX60(W) / 
> > MX60.
> >
> >  > 
> > https://github.com/riptidewave93/meraki-uboot/blob/mx60w-20180413/board/amcc/bluestone/bluestone.c#L1178
> >
> > | if (!pci_available()) {
> > | fdt_find_and_setprop(blob, "/plb/pciex@d", "status",
> > |   "disabled", sizeof("disabled"), 1);
> > | }
> >
> >
> > Backstory: There are two version of the Meraki MX60. The MX60
> > and the MX60W. The difference is that the MX60W has a populated
> > mini-pcie slot on the PCB for a >W >
> > That said, this is not earth shattering.
>
> I'm happy to revert that hunk if you think any one is actually booting
> mainline on those.

The MX60(W) or APM82181 in general?

The APM82181 devices run really well on the kernel 5.8. The APM82181
had some bitrot and missing pieces. But I started at around 4.4 with
upstreaming various bits and stuff. For proof, I can post a bootlog from
my MyBook Live dev station running my mbl-debian on this weekend:
.

This WD MyBook Live project really only needs
 - vanilla 5.8 (I got rid of the make-kpkg hack by switching to make bindeb-pkg)
 - the MyBookLive DTS.
 - kernel config is based on arch/powerpc/configs/44x/bluestone_defconfig +
   (I enabled dwc2 (USB-Port on the DUO), SATA, ext4(+squashfs),
   gpio-support, leds-support, crypto44x)
 - a powerpc32 userspace (debian's sid still builds up-to-date powerpc packages)

For the MX60(W): We have those two supported in OpenWrt. Currently they
are running a OpenWrt kernel based on stable 5.4 series. The missing "bit"
is upstream support for the AR8327 ethernet switch. I know that the chip
can be supported by qca8k: 



But of course: My future work with the MX60(W) (and AR8327) depends on how
this series goes. I'm testing the waters with the Meraki MR24 AP and the
WD MyBook Live series. Reason being that both devices are well supported.
They are available in great quantities... and all the core functions
are working.

Cheers,
Christian

Re: [PATCH] powerpc/boot/dts: Fix dtc "pciex" warnings

2020-09-08 Thread Michael Ellerman 
Christian Lamparter  writes:
> On 2020-06-23 15:03, Michael Ellerman wrote:
>> With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
>> warnings about our dts files, such as:
>>
>>arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
>>Warning (pci_bridge): /plb/pciex@d: node name is not "pci"
>>or "pcie"
>>
>> The node name should not particularly matter, it's just a name, and
>> AFAICS there's no kernel code that cares whether nodes are *named*
>> "pciex" or "pcie". So shutup these warnings by converting to the name
>> dtc wants.
>>
>> As always there's some risk this could break something obscure that
>> does rely on the name, in which case we can revert.
>
> Hmm, I noticed this when I was looking up why nobody commented
> on my series of adding more devices to the APM82181/bluestone series:
>
> 
> (I'll post a v3 "soonish".)
>
>
> Unfortunately yes. This patch will break uboot code in Meraki MX60(W) / MX60.
>
>  > 
> https://github.com/riptidewave93/meraki-uboot/blob/mx60w-20180413/board/amcc/bluestone/bluestone.c#L1178
>
> | if (!pci_available()) {
> |     fdt_find_and_setprop(blob, "/plb/pciex@d", "status",
> |   "disabled", sizeof("disabled"), 1);
> | }
>
>
> Backstory: There are two version of the Meraki MX60. The MX60
> and the MX60W. The difference is that the MX60W has a populated
> mini-pcie slot on the PCB for a >W
> That said, this is not earth shattering.

I'm happy to revert that hunk if you think any one is actually booting
mainline on those.

cheers

> (In theory, this can also cause problems for the bluestone and canyonlands
> dev boards that have the option to be configured as either dual sata or
> pcie+sata But this is probably not a problem for customer boards)
>
> OT: Please note that the plb, opb and ebc node paths (/plb/opb/ebc) are
> hardcoded too :(. Amending the proper unit-addresses will lead to no-longer
> working DTBs as the "ranges" are missing.
>
> Cheers,
> Christian
>> Signed-off-by: Michael Ellerman 
>> ---
>>
>> diff --git a/arch/powerpc/boot/dts/bluestone.dts 
>> b/arch/powerpc/boot/dts/bluestone.dts
>> index cc965a1816b6..aa1ae94cd776 100644
>> --- a/arch/powerpc/boot/dts/bluestone.dts
>> +++ b/arch/powerpc/boot/dts/bluestone.dts
>> @@ -325,7 +325,7 @@ EMAC0: ethernet@ef600c00 {
>>  };
>>  };
>>   
>> -PCIE0: pciex@d {
>> +PCIE0: pcie@d {
>>  device_type = "pci";
>>  #interrupt-cells = <1>;
>>  #size-cells = <2>;

Re: [PATCH] powerpc/boot/dts: Fix dtc "pciex" warnings

2020-09-03 Thread Christian Lamparter 

On 2020-06-23 15:03, Michael Ellerman wrote:

With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
warnings about our dts files, such as:

   arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
   Warning (pci_bridge): /plb/pciex@d: node name is not "pci"
   or "pcie"

The node name should not particularly matter, it's just a name, and
AFAICS there's no kernel code that cares whether nodes are *named*
"pciex" or "pcie". So shutup these warnings by converting to the name
dtc wants.

As always there's some risk this could break something obscure that
does rely on the name, in which case we can revert.


Hmm, I noticed this when I was looking up why nobody commented
on my series of adding more devices to the APM82181/bluestone series:


(I'll post a v3 "soonish".)


Unfortunately yes. This patch will break uboot code in Meraki MX60(W) / MX60.

> 
https://github.com/riptidewave93/meraki-uboot/blob/mx60w-20180413/board/amcc/bluestone/bluestone.c#L1178

| if (!pci_available()) {
|     fdt_find_and_setprop(blob, "/plb/pciex@d", "status",
|   "disabled", sizeof("disabled"), 1);
| }


Backstory: There are two version of the Meraki MX60. The MX60
and the MX60W. The difference is that the MX60W has a populated
mini-pcie slot on the PCB for a >W
Signed-off-by: Michael Ellerman 
---

diff --git a/arch/powerpc/boot/dts/bluestone.dts 
b/arch/powerpc/boot/dts/bluestone.dts
index cc965a1816b6..aa1ae94cd776 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -325,7 +325,7 @@ EMAC0: ethernet@ef600c00 {
};
};
  
-		PCIE0: pciex@d {

+   PCIE0: pcie@d {
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;

Re: [PATCH] powerpc/boot/dts: Fix dtc "pciex" warnings

2020-07-16 Thread Michael Ellerman 
On Tue, 23 Jun 2020 23:03:20 +1000, Michael Ellerman wrote:
> With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
> warnings about our dts files, such as:
> 
>   arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
>   Warning (pci_bridge): /plb/pciex@d: node name is not "pci"
>   or "pcie"
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/boot/dts: Fix dtc "pciex" warnings
  https://git.kernel.org/powerpc/c/86bc917d2ac117ec922dbf8ed92ca989bf333281

cheers

Re: [PATCH] powerpc/boot/dts: Fix dtc "pciex" warnings

2020-06-23 Thread Stephen Rothwell 
Hi Michael,

On Tue, 23 Jun 2020 23:03:20 +1000 Michael Ellerman  wrote:
>
> With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
> warnings about our dts files, such as:
> 
>   arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
>   Warning (pci_bridge): /plb/pciex@d: node name is not "pci"
>   or "pcie"
> 
> The node name should not particularly matter, it's just a name, and
> AFAICS there's no kernel code that cares whether nodes are *named*
> "pciex" or "pcie". So shutup these warnings by converting to the name
> dtc wants.
> 
> As always there's some risk this could break something obscure that
> does rely on the name, in which case we can revert.
> 
> Signed-off-by: Michael Ellerman 

Thanks for that.  I have applied it to my "fixes" tree until it turns
up elsewhere.

-- 
Cheers,
Stephen Rothwell


pgpC3XufEBllF.pgp
Description: OpenPGP digital signature