niedz., 20 sie 2023 o 20:50 Arınç ÜNAL <arinc.u...@arinc9.com> napisał(a): > On 20 August 2023 17:15:51 GMT+03:00, "Rafał Miłecki" <zaj...@gmail.com> > wrote: > >sob., 19 sie 2023 o 17:12 Arınç ÜNAL <arinc.u...@arinc9.com> napisał(a): > >> The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It > >> causes the devices with NVRAM in NAND to bootloop. Create a subtarget for > >> NAND devices and disable the driver on it. > >> > >> Disable NVMEM too as the bgmac_bcma driver will hang trying to retrieve the > >> MAC address without NVMEM_BRCM_NVRAM enabled. > > > >Adding a new subtarget just because one driver doesn't work correctly > >is an overkill. > > > >I'll handle that in some simple solution after holidays. > > Rafał, you've been aware of this problem and reportedly working on at least > diagnosing it for the last 6 months. You did not come up with anything yet. > Forgive me if I find it hard to believe that you will come up with a solution > in a short amount of time, if that's what you mean by after holidays as I > don't know what holidays you're referring to. > > In the meantime, there is a good amount of users unable to use the newer > OpenWrt versions on the affected devices because of a driver that provides a > rather trivial feature. I would like these devices to work again as soon as > possible as we've already lost a lot of time. > > To have these devices work again, I see these solutions: > > - First and the most obvious, fix the driver. I do not know the NVMEM > subsystem well enough to do it and am currently not interested to spend time > studying it. > > - Prevent the driver to read from the flash if NAND flash is detected. Once > the underlying cause is fixed, this can then be reverted. Like I stated > above, I lack the knowledge to do this. > > - This patch. It can be easily reverted in the future when or should the > issue be fixed. > > - My other patch submitted here that disables the driver for the whole > target. Currently, only four devices do not have NAND flash and two of these > devices are not set to be compiled anyway. I'd rather prefer this than > convoluting OpenWrt with another subtarget. I'd much rather prefer two > devices not benefiting the future provided by this driver compared to a lot > more devices being unable to boot. > > I feel like writing this mail has been a waste of time as lately I've never > seen you reply or in any way acknowledge that you've read any of my > responses, yet I've done it anyway, at least for the mailing list.
I'm not going to argue I handled it properly. It looked at it once then forgot it. My maintenance time is very limited and I'm not denying this. I assumed holidays end for most people with the end of August. I'm on a 1-week holiday family trip and I don't have time for development or hardware for testing. In my very personal opinion I prefer to leave support for those devices broken for another week (given it has been 6 months now) rather than push a (in my opinion) pretty hacky workaround. -- Rafał _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
