[sdwalker/sdwalker.github.io] c28eab: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: c28eab2a0c8c98d1fda6ed7d55dec08470332ee2 https://github.com/sdwalker/sdwalker.github.io/commit/c28eab2a0c8c98d1fda6ed7d55dec08470332ee2 Author: Stephen Walker Date: 2023-08-21 (Mon, 21 Aug 2023) Changed paths: M uscan/index-22.03.html M uscan/index-23.05.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm53xx: add nand subtarget
On 20.08.2023 23:54, Rafał Miłecki wrote: niedz., 20 sie 2023 o 20:50 Arınç ÜNAL napisał(a): On 20 August 2023 17:15:51 GMT+03:00, "Rafał Miłecki" wrote: sob., 19 sie 2023 o 17:12 Arınç ÜNAL 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. I agree. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 5/5] bcm53xx: Add network configuration for DIR-890L
On Sun, Aug 20, 2023 at 4:17 PM Rafał Miłecki wrote: > pon., 19 cze 2023 o 08:39 Linus Walleij napisał(a): > > This adds the lan/wan default bridge config and also the MAC > > NVRAM read-out for et2. > > > > DIR-885L was missing a default bridge config so I just added > > that too while I was at it. > > Why do you need to handle D-Link devices individually at all? Your > code seems to be identical to the default switch case "*)". Oh right, I don't know what I was thinking. Skip this patch! Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm53xx: add nand subtarget
niedz., 20 sie 2023 o 20:50 Arınç ÜNAL napisał(a): > On 20 August 2023 17:15:51 GMT+03:00, "Rafał Miłecki" > wrote: > >sob., 19 sie 2023 o 17:12 Arınç ÜNAL 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
Re: [PATCH] bcm53xx: add nand subtarget
On 20 August 2023 17:15:51 GMT+03:00, "Rafał Miłecki" wrote: >sob., 19 sie 2023 o 17:12 Arınç ÜNAL 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. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 4/5] bcm53xx: dir885/dir890: Tag both partitions as SEAMA
pon., 19 cze 2023 o 08:39 Linus Walleij napisał(a): > The newly added D-Link DIR-890L also needs to have a seama > tag on its partition so that it will be split properly by > mtdsplit. I'm skipping this one thanks to the [PATCH] ARM: dts: bcm5301x: Add SEAMA compatibles (great work, thank you!) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 5/5] bcm53xx: Add network configuration for DIR-890L
pon., 19 cze 2023 o 08:39 Linus Walleij napisał(a): > This adds the lan/wan default bridge config and also the MAC > NVRAM read-out for et2. > > DIR-885L was missing a default bridge config so I just added > that too while I was at it. Why do you need to handle D-Link devices individually at all? Your code seems to be identical to the default switch case "*)". ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm53xx: add nand subtarget
sob., 19 sie 2023 o 17:12 Arınç ÜNAL 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: wifi: mt76: mt7915: remove VHT160 capability on MT7915?
Am 20. August 2023 04:01:55 MESZ schrieb Thomas Walker : >Doing a little more reading and guessing that this is related to >https://forum.openwrt.org/t/802-11ax-worse-than-802-11ac-with-mt76-driver/126466/408? > >Giving it (VHT80 and explicitly enabling the coloring/beam forming ax >bits) a try. I'm not really one to be running iperf against every >config change, nor do I have more than 1 or 2 ax clients so maybe I >simply missed the potential perf impact? I just noticed when the >config I'd been using for 6+ months failed in a way that didn't >provide much of a useful error message and required bisecting to hunt >down. > >(And a likely inconsequential error in my initial report, the device >is an RB03, not RB01.) > >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel This might've been fixed already, but not in 23 rc, yet. https://github.com/openwrt/mt76/commit/bb3937d5c3e0b13c0d08747ec0fc9726fb4fd870 Regards Felix Baumann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
