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
I'm in the same situation - I have a device as well and I'm sort-of using it with my local builds now, though I'd like the official support restored as well. I probably need to rebase the support which is up on my Github.
I'm also happy to test this out on my spare mr18. Would be great if you can provide me a build. I have limited experience in creating snapshot builds off custom repos.
