Hi Petr, Thank you for reverting the patches.
I'm trying to replicate the issue but so far I haven't had any luck, and just by looking at the code I'm not seeing where/what is could be breaking. Regarding the upstream patch, that one is just an enabler (read: it only extends the "mtd_add_partition" function but it does not add any code to force the access mode on sub-partitions). The reason for this is because this enforcement is done on the mtd parser code that is OpenWrt specific and implemented via kernel patches (not present on upstream). Best regards, Bruno Pena On Tue, Jan 21, 2020 at 7:57 PM Petr Štetiar <[email protected]> wrote: > Bruno Pena <[email protected]> [2020-01-21 14:53:54]: > > Hi, > > > Based on the last comment from Steve (fstools patch was not reverted), > I'm > > not sure if that's the root cause. > > you need to find out, but that Daniel's remark seems legit to me, your > patch > likely changed the mtd device open order/flags. > > > The kernel patch (which when reverted makes rootfs_data writable again) > > only enforces the parent mtd access mode on the sub-partitions. > > FYI I currently dont have time to fix that regression myself and since its > likely affecting a lot of users, so I've reverted those changes. I think, > that > this change is useful, so I'm still willing to merge it once fixed, no > worries. Having some upstream feedback beforehand would be a plus. > > BTW it would be fair to inform upstream about this possible issue as well, > so > the patch wont get merged in its current state, unless its double checked > (or > just write them, that you're planning v2, so the patch is removed from > their > Patchwork). > > -- ynezz >
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
