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.
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.
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..
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.
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