Meraki MR18 - port to ath79

Recently I got my hands on Meraki MR18, which is currently only supported on ar71xx. I found a WIP port in @chunkeey's staging tree, fixed up a couple of typos - and got it working successfully, after discussion with @justinb. However I wasn't as satisfied with LED support - due to caveats of userspace LEDs, so I updated the driver for NU801 to support OF platforms, and used it - with intention to upstream it to Linux.

@chunkeey et al. - what do you think? Is this approach worth upstreaming? Should I just open a draft PR?
My sources are here:
I haven't really touched Meraki Z1 also present in the tree, because I don't own the device, so I can't test.

1 Like

Many things here:

For the MR18: I have updated it a bit (had the caldata mixed up), you might want to check it out again. As for adding it to openwrt, there's the problem with that nand patch:

Just reverting his patch (like I do in my staging tree) will almost certainly break @xback ath79 nand device. :frowning_face:

For the NU801 part:

Please sent/develop your patches on the related Linux MLs first. My reasoning here is: They are the experts and they keep up with the latest trends (in fact they also make them up in most cases). If there's a positive reaction there and it moves to one of the various linux-next trees, I think everyone will gladly pick it up into openwrt.

Now there's something a bit off with the linux-led patchwork/mailinglist, I'm not so sure... It seems to be stuck?

As for nu801 and MR18... Thing is with OF/Devicetree drivers/devices submissions ist that, you are automatically looking at submitting a binding .yaml (and wait for it being reviewed-by/acked-by the device-tree folks) too. People there sometimes require that either "there's already an existing device in the upstream kernel which can make use of the driver/modification", or they request you to also upstream that MR18.dts...

Now, as luck would have it: The x86 EFI Cisco Meraki MX100 uses a nu801 chip! This is helpful because you already have a device in the upstream linux kernel... But this is x86 and would use platform_device for device enumeration/discovery. So you would be looking at adding support for the platform_device probing as well..

This is can be a ton of work just for a device.

1 Like

Ok then, I'll start with submitting patches for NU801 and see how it goes - this was my initial idea. I'll probably get a request to support RGB DT bindings as well, but I planned for this already.

Regarding NAND issue, I wonder, what could be done to fix that, without breaking other devices, beside introducing another DT knob.
Anyway, thanks a lot for review. I noticed the messed up calibration data earlier as well - you can pick my fixes to your tree, of course.
When I have some more free time, I'll return to that topic - I'd very much like to mount it on a mast as Hamnet node running ath79 than oldstable ar71xx.

1 Like

@riptidewave93 just pushed another round for nu801.

Nice to know, I'll give it a spin soon. But I think, that the LED is the easy part here, the NAND-flash issue worries me more.

I'll have another look at it asap.

1 Like

ok, maybe we start here? @xback Do you know which other ath79 nand device(s) conflicts with the revert?

1 Like

At the same time, what do you think about a quick round of review for my kernel nu801 driver update for upstreaming? I think I'll restore the platform data probe first - it was nuked, so I'd have to restore it for MX100.

Unless, there is a proper way to probe it from ACPI, unlike just shoving in a platform_driver instance from another module, @riptidewave93 do you know if this could be a chance? I presume the stock firmware did it this way as well. IIRC it still isn't possible to load device tree snippets on x86 :frowning:

I'll need to runtest all boards here.

@chunkeey and @xback any news? I'd be happy to see MR18 supported again in 22.03.