On Thu, Aug 27, 2020 at 5:20 PM Alex Kiernan <alex.kier...@gmail.com> wrote: > > On Thu, Aug 27, 2020 at 2:03 PM Tom Rini <tr...@konsulko.com> wrote: > > > > On Thu, Aug 27, 2020 at 11:49:25AM +0200, Marek Vasut wrote: > > > On 8/27/20 11:43 AM, Alex Kiernan wrote: > > > > This reverts commit 0f036bf4b87e6416f5c4d23865a62a62d9073c20. > > > > > > > > With this change applied and CONFIG_ENV_ACCESS_IGNORE_FORCE disabled, > > > > the warning appears on every force overwrite, but the variable is then > > > > written to: > > > > > > > > => env print ethaddr > > > > ethaddr=00:1C:2B:08:AF:65 > > > > => env set ethaddr 00:00:00:00:00:00 > > > > ## Error: Can't overwrite "ethaddr" > > > > ## Error inserting "ethaddr" variable, errno=1 > > > > => env print ethaddr > > > > ethaddr=00:1C:2B:08:AF:65 > > > > => env set -f ethaddr 00:00:00:00:00:00 > > > > ## Error: Can't force access to "ethaddr" > > > > => env print ethaddr > > > > ethaddr=00:00:00:00:00:00 > > > > > > > > Signed-off-by: Alex Kiernan <alex.kier...@gmail.com> > > > > --- > > > > As I noted in my email, I can't see an immediately obvious way to make > > > > this work as intended and given we're at -rc3, I think a revert is the > > > > most appropriate way forward. > > > > > > Can you please spend some more time on proper fix, instead of just > > > reverting ? Reverting isn't the way forward most of the time. > > > > Can you assist in that? So far the original patch broke the EFI tests, > > but Heinrich and I came up with a compromise (but it's also I suspect > > that Alex saw). It is probably better to go back to the same behavior > > as the last release and try again next release once the problem can be > > addressed by someone. > > > > I had another play with it and think I have something that'll work, > though I leave my current job at the end of the week, so if it's not > right I'm unlikely to be able to fix it. >
Sorry, I ran out of time... so it's highly unlikely I'll get to look at this any time soon. Unfortunately I don't have access to that tree anymore either. -- Alex Kiernan
