Il giorno sab 2 ott 2021 alle ore 01:35 Rosen Penev <ros...@gmail.com> ha scritto: > > On Fri, Oct 1, 2021 at 3:05 PM Hauke Mehrtens <ha...@hauke-m.de> wrote: > > > > On 9/30/21 10:40 PM, Paul Spooren wrote: > > > > > > On 9/30/21 10:01, Nick wrote: > > >> > > >> On 9/30/21 21:43, Daniel Golle wrote: > > >>> On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote: > > >>>> On 30/09/2021 01:19, Nick wrote: > > >>>>> On 9/29/21 22:28, Hauke Mehrtens wrote: > > >>>>> > > >>>>>> kernel 5.10: > > >>>>>> We should get all targets to kernel 5.10. All targets which are not > > >>>>>> on kernel 5.10 when we branch off should get removed. > > >>>>> Kernel 5.15 could be also a LTS Kernel that should be released in the > > >>>>> end of October? Why not aiming for it if we plan to release in 2022? > > >>>> This would undoubtedly delay the next release, as we've seen in the > > >>>> past. We don't even have all targets on 5.10, which was released > > >>>> roughly > > >>>> 9 months ago. You do the math. If we target 5.15, I doubt we'll even > > >>>> see > > >>>> a release in 2022. > > >>> I also believe we should do the next release based on Linux 5.10 and > > >>> try branching still this year (which I believe is realistic to make all > > >>> targets build with 5.10 till then), so we can target April 2022 as time > > >>> of release. > > > > I agree with you Daniel and think this timeline is reasonable. > > > > >> Sounds good, so we can go on with 5.15 when it is released? > > > > > > Some targets already moved to 5.10 as default, feel free to add 5.15 as > > > the new TESTING kernel there. > > > > I am against adding support for kernel 5.15 now, we should better wait > > till after we branched the relase off. > > > > > > > >> I think the most problematic thing is if we want to have DSA support > > >> for all targets as requirement. Not sure if this is possible. > > > > > > It seems fine found a okay'ish middle ground between DSA and non-DSA, so > > > I'd not make DSA blocking for the next release but continue to integrate > > > it where ever possible (and stable). > > > > I think we will never convert all swconfig drivers to DSA. I do not > > think anyone will invest the time to write a DSA driver for the ADM6996L > > chip for example. It could be that we just remove support for the last > > boards which still use swconfig in some years. > Not that many look like they can get DSA treatment. With realtek > switches, only RTL8366RB seems supported upstream. ar8216 can be
Wait. Ar8216 can't be supported for qca8k (extensive rework of the entire driver. He has an entirely different scheme. qca8k = ar8326 8337 Do you have a list of the ar8216 devices? > replaced by qca8k currently but lots of testing is needed. I have no > idea about mediatek and why it has an swconfig driver when there's a > DSA one upstream. > > > > Hauke > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel