[flashrom] Re: Release preparations

[Richard Hughes]

On Tue, 17 May 2022 at 02:57, Anastasia Klimchuk  wrote:
> Thanks so much for your thoughts everyone!

One more, if it helps. For fwupd we always have the "main" branch as
"release ready" -- as in you can tag a release and drop a tarball
without doing anything more than writing some release notes. This
works really well for us, and most of the development is done in "wip"
branches, some of which exist for months and are pushed by multiple
people. For wip branches we have a policy of "no rebasing" so
sometimes the wip branch gets branched into a different branch,
rebased and then development continues. We only rebase the branch when
merging to fix any conflicts.

Having the development branch in this "always good to go" state means
we can always drop a new release about once a month, and encourage
downstreams to just ship the latest version, rather than telling them
to cherry pick specific patches for bugs users are hitting.

Just my 2p; feel free to ignore :)

Richard.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Anastasia Klimchuk]

Thanks so much for your thoughts everyone!

I have important information for this thread. Next flashrom dev
meeting which is this Thursday (in two days), specifically:

19th May 2022, 6:00 - 7:00 am UTC+0

will be discussing flashrom release!
There are two parts in the topic: next release v1.3 and also in
general what approach we want to have for future releases.

As you see on the meeting agenda here
https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFsKqw/edit?usp=sharing
Flashrom release is the first topic for 19th May.
Next topic is “flashrom binaries” which is probably related to the first one.
And if there is time left, the topic after that is “flashrom
cross-platform build testing” which is also related.

Everyone who is interested to discuss flashrom release is very very
welcome to join the meeting!

Also as I mentioned before, I created issues under parent task here
https://ticket.coreboot.org/issues/353 (some of them already assigned
to people).
Alternatively you can open the list of all flashrom issues and set filters:
category == Release prep && target version == 1.3

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Martin L Roth]

On Thu, Apr 28, 2022 at 9:36 PM Felix Singer  wrote:

> On Thu, 2022-04-28 at 08:22 -0400, Greg Troxel wrote:
> >
> > Anastasia Klimchuk  writes:
> >
> > > I haven’t done any releases before, so tell me if I am wrong. But
> > > what I am thinking when looking at the list of issues: maybe we can
> > > have some time for “just fixing issues on master” and after that do
> > > a release branch? Does it make sense? “Some time” won’t take
> > > forever (AU winter maybe?). I have issue #353 assigned to me, so
> > > now it has to happen :)
> >
> > My $0.02 from dealing with various projects.
> >
> > Flashrom is small and I think it's best to do the release off master,
> > getting everything done that needs to get done, and then beginning
> > the process with feature freeze, moving to regression and doc fixes
> > only, maybe alpha, beta, rc and then release.  Only when there is a
> > release create a branch that would be used for micro updates to the
> > release while master is back open for development.
>

I think this depends on what's happening for the release.  If code is just
being added, the master branch is fine.  It sounded like there might be a
desire to remove code to do the release.  In that case it probably makes
sense to get as close to the release as possible, branch, then remove any
code necessary for the release to happen.  After the code is removed, maybe
only allow stabilization changes and bugfixes onto that branch.


> > In order to make a release it is necessary to say no to further
> > changes. It is always possible to improve, but that leads to never
> > releasing, and users are better served with a series of better
> > releases, as long as each one does not have significant
> > regressions. This is easy to say and hard to do!
> >
> > Creating a release branch before release means changes happen in
> > master disconnected from release and there's backporting effort and a
> > lot more work. Not branching incentivizes everyone to get the release
> > done and hold their feature branches.
>
> Good thoughts. Though, I think we shouldn't think about the actual
> release process too much now, because there are many issues from the
> past open and many questions unanswered.
>
> For now, we should just focus on indentifying major issues, fixing
> these and see how that goes. Moving the issues Nico mentioned to the
> ticket system is a good first step. It could take some time until the
> actual release process can start, since I think there is lots of work
> to do to get to this point. However, things might look totally
> different in some weeks or months and so I would postpone this
> discussion. It doesn't make much sense to me to do that now.
>

I agree that it's too early to actually start the release process. It's
good to have a well defined process though, so that should probably start
now, before it's needed.

Maybe look over the coreboot release process and see what's useful to take
from that.
https://doc.coreboot.org/releases/checklist.html

Keep in mind though that coreboot releases are more of a snapshot of the
codebase at a certain point in time than an actual stabilized release, so
I'd imagine flashrom might want to do something like a testing checklist.

Martin
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Felix Singer]

On Thu, 2022-04-28 at 08:22 -0400, Greg Troxel wrote:
> 
> Anastasia Klimchuk  writes:
> 
> > I haven’t done any releases before, so tell me if I am wrong. But
> > what I am thinking when looking at the list of issues: maybe we can
> > have some time for “just fixing issues on master” and after that do
> > a release branch? Does it make sense? “Some time” won’t take
> > forever (AU winter maybe?). I have issue #353 assigned to me, so
> > now it has to happen :)
> 
> My $0.02 from dealing with various projects.
> 
> Flashrom is small and I think it's best to do the release off master,
> getting everything done that needs to get done, and then beginning
> the process with feature freeze, moving to regression and doc fixes
> only, maybe alpha, beta, rc and then release.  Only when there is a
> release create a branch that would be used for micro updates to the
> release while master is back open for development.
> 
> In order to make a release it is necessary to say no to further
> changes. It is always possible to improve, but that leads to never
> releasing, and users are better served with a series of better
> releases, as long as each one does not have significant
> regressions. This is easy to say and hard to do!
> 
> Creating a release branch before release means changes happen in
> master disconnected from release and there's backporting effort and a
> lot more work. Not branching incentivizes everyone to get the release
> done and hold their feature branches.

Good thoughts. Though, I think we shouldn't think about the actual
release process too much now, because there are many issues from the
past open and many questions unanswered.

For now, we should just focus on indentifying major issues, fixing
these and see how that goes. Moving the issues Nico mentioned to the
ticket system is a good first step. It could take some time until the
actual release process can start, since I think there is lots of work
to do to get to this point. However, things might look totally
different in some weeks or months and so I would postpone this
discussion. It doesn't make much sense to me to do that now.

// Felix
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Greg Troxel]

Anastasia Klimchuk  writes:

> I haven’t done any releases before, so tell me if I am wrong. But what I am
> thinking when looking at the list of issues: maybe we can have some time
> for “just fixing issues on master” and after that do a release branch? Does
> it make sense?
> “Some time” won’t take forever (AU winter maybe?). I have issue #353
> assigned to me, so now it has to happen :)

My $0.02 from dealing with various projects.

Flashrom is small and I think it's best to do the release off master,
getting everything done that needs to get done, and then beginning the
process with feature freeze, moving to regression and doc fixes only,
maybe alpha, beta, rc and then release.  Only when there is a release
create a branch that would be used for micro updates to the release
while master is back open for development.

In order to make a release it is necessary to say no to further
changes.  It is always possible to improve, but that leads to never
releasing, and users are better served with a series of better releases,
as long as each one does not have significant regressions.   This is
easy to say and hard to do!

Creating a release branch before release means changes happen in master
disconnected from release and there's backporting effort and a lot more
work.  Not branching incentivizes everyone to get the release done and
hold their feature branches.




signature.asc
Description: PGP signature
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Anastasia Klimchuk]

I have great news: I created items for the release in our bugtracker!

Here is a parent issue “Release v1.3” https://ticket.coreboot.org/issues/353
and it has 23 subtasks. The subtasks are the items from the original
starter email. Thank you so much Nico for going through the long history
and making the list, that’s a lot of work and time!

The very good thing is that now the big task is trackable, parallelizable
and open to anyone who can join the effort.

I looked into commits and gerrit reviews that correspond to those, I tried
to get some context. Surely all of the descriptions can be improved, or
more info can be added to issues. Especially if you are taking an issue and
start working on it.

Also, of course, more tasks can be added, if something is missing. Please
set the parent issue #353, category “Release prep” and target release 1.3
if you add a new task.

I assigned the parent issue to myself. Please tell me if anyone has
objections. I did it because at the last dev meeting the community decided
that I will be “release manager”. It was completely unexpected for me, but
it is true to say that I very much want the release to happen.
I really appreciate any help and advice from people!

As a separate note, the question of meson and make has been discussed in
this thread. And we now have a One Build System working group with the goal
to converge two flashrom build systems into one (meson). Here is the doc
with more info
.
Everyone who is interested in contributing to the effort can join! This
effort goes in parallel with release prep.

I haven’t done any releases before, so tell me if I am wrong. But what I am
thinking when looking at the list of issues: maybe we can have some time
for “just fixing issues on master” and after that do a release branch? Does
it make sense?
“Some time” won’t take forever (AU winter maybe?). I have issue #353
assigned to me, so now it has to happen :)


On Thu, Mar 24, 2022 at 2:34 AM Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2...@gmx.net> wrote:

> Hi Richard,
>
> Am 23.03.22 um 10:20 schrieb Richard Hughes:
> > On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger
> >  wrote:
> >> AFAIR there were three arguments for meson:
> >> - Meson build integrates nicely with other packages built by meson
> > This means we can build libflashrom as a subproject, which means we
> > can build the flashrom plugin even when the distro doesn't ship [a new
> > enough] flashrom package:
> > https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap
> >
> > That's just something you can't do with the Makefile, and removing the
> > subproject would force us to remove flashrom support from almost all
> > the CI systems we test fwupd with.
>
> It took me some time to understand the text of this last sentence, but
> I'm unsure about the implied subtext.
> The first paragraph implies that a fwupd build can rebuild flashrom as
> well. Interesting. In that case a Meson wrapper for Makefile might
> satisfy your requirements in principle, but not in spirit.
>
> For the subtext of the last sentence I'm not sure if the intended
> understanding was "use Meson or we'll drop flashrom" or "give us a way
> to keep our CI running with flashrom" or something entirely different.
> Sorry, English is not my native language. I'm trying understand if this
> is a technical (something doesn't work) or social (something is
> frustrating) problem or both. Analyzing your statement above with the
> linguistic tools of Schulz von Thun and Watzlawick gave me the
> impression that I'm missing something here.
>
>
> >> - Native support for most non-Linux platforms
> > I keep hearing this, but haven't got any actual data -- is there any
> > reason why the meson build system wouldn't "just work" with
> > *BSD/Win32/macOS?
>
> Someone would have to test it and document it. This also includes
> crossbuilds for MacOS and DOS on Linux which are both supported with
> Makefile.
> Documentation for the various Makefile based builds is available at
> https://github.com/flashrom/flashrom/blob/master/README . Copy/paste
> from a README is something that "just works". This is currently missing
> for our Meson build.
>
>
> >> I think Meson was a good idea, but it failed to get traction beyond "we
> >> need it for dynamic libflashrom".
> > I don't know how you've managed to get to "failed to get traction"
> > given that it's being built with meson in 4 of the biggest projects
> > (in terms of distribution, and number of deployed packages) using
> > flashrom.
>
> The switch to Meson in Debian has resulted in some regressions which
> caused people to join #flashrom IRC. Not all of the regressions were
> fixed. Maybe "failed to get traction" was the wrong phrase. "Nobody
> bothered to check the Meson build result and compare it to the Makefile
> reference" would be a more accurate description.
>
> This caused a mismatch between pac

[flashrom] Re: Release preparations

[Carl-Daniel Hailfinger]

Hi Richard,

Am 23.03.22 um 10:20 schrieb Richard Hughes:
> On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger
>  wrote:
>> AFAIR there were three arguments for meson:
>> - Meson build integrates nicely with other packages built by meson
> This means we can build libflashrom as a subproject, which means we
> can build the flashrom plugin even when the distro doesn't ship [a new
> enough] flashrom package:
> https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap
>
> That's just something you can't do with the Makefile, and removing the
> subproject would force us to remove flashrom support from almost all
> the CI systems we test fwupd with.

It took me some time to understand the text of this last sentence, but
I'm unsure about the implied subtext.
The first paragraph implies that a fwupd build can rebuild flashrom as
well. Interesting. In that case a Meson wrapper for Makefile might
satisfy your requirements in principle, but not in spirit.

For the subtext of the last sentence I'm not sure if the intended
understanding was "use Meson or we'll drop flashrom" or "give us a way
to keep our CI running with flashrom" or something entirely different.
Sorry, English is not my native language. I'm trying understand if this
is a technical (something doesn't work) or social (something is
frustrating) problem or both. Analyzing your statement above with the
linguistic tools of Schulz von Thun and Watzlawick gave me the
impression that I'm missing something here.


>> - Native support for most non-Linux platforms
> I keep hearing this, but haven't got any actual data -- is there any
> reason why the meson build system wouldn't "just work" with
> *BSD/Win32/macOS?

Someone would have to test it and document it. This also includes
crossbuilds for MacOS and DOS on Linux which are both supported with
Makefile.
Documentation for the various Makefile based builds is available at
https://github.com/flashrom/flashrom/blob/master/README . Copy/paste
from a README is something that "just works". This is currently missing
for our Meson build.


>> I think Meson was a good idea, but it failed to get traction beyond "we
>> need it for dynamic libflashrom".
> I don't know how you've managed to get to "failed to get traction"
> given that it's being built with meson in 4 of the biggest projects
> (in terms of distribution, and number of deployed packages) using
> flashrom.

The switch to Meson in Debian has resulted in some regressions which
caused people to join #flashrom IRC. Not all of the regressions were
fixed. Maybe "failed to get traction" was the wrong phrase. "Nobody
bothered to check the Meson build result and compare it to the Makefile
reference" would be a more accurate description.

This caused a mismatch between packagers picking up Meson and developers
(as well as users following the documentation) still using the Makefile.


> This is all so frustrating: This feels like more of an existential
> crisis about what flashrom actually *is* rather than a discussion
> about build systems.

I've seen this in many open source projects: A rewrite of some component
happens, but the rewrite has a different subset (and not a superset) of
features. As long as both the original and the rewritten version are
available, neither side will have any motivation to make their version a
superset of the features of the other side because their own use case
works well. As a result, everyone is frustrated.

My hope with flashrom is that it brings joy or at least works as a good
tool. It is definitely not my intention to frustrate you. I would love
to find a solution that makes everyone happy.


Regards,
Carl-Daniel
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Luc Verhaegen]

On Wed, Mar 23, 2022 at 09:20:18AM +, Richard Hughes wrote:
> On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger
>  wrote:
> > AFAIR there were three arguments for meson:
> > - Meson build integrates nicely with other packages built by meson
> 
> This means we can build libflashrom as a subproject, which means we
> can build the flashrom plugin even when the distro doesn't ship [a new
> enough] flashrom package:
> https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap
> 
> That's just something you can't do with the Makefile, and removing the
> subproject would force us to remove flashrom support from almost all
> the CI systems we test fwupd with.

Is meson unable to call `make` in a subdirectory?

Luc Verhaegen.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Richard Hughes]

On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger
 wrote:
> AFAIR there were three arguments for meson:
> - Meson build integrates nicely with other packages built by meson

This means we can build libflashrom as a subproject, which means we
can build the flashrom plugin even when the distro doesn't ship [a new
enough] flashrom package:
https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap

That's just something you can't do with the Makefile, and removing the
subproject would force us to remove flashrom support from almost all
the CI systems we test fwupd with.

> - Native support for most non-Linux platforms

I keep hearing this, but haven't got any actual data -- is there any
reason why the meson build system wouldn't "just work" with
*BSD/Win32/macOS?

> I think Meson was a good idea, but it failed to get traction beyond "we
> need it for dynamic libflashrom".

I don't know how you've managed to get to "failed to get traction"
given that it's being built with meson in 4 of the biggest projects
(in terms of distribution, and number of deployed packages) using
flashrom.

This is all so frustrating: This feels like more of an existential
crisis about what flashrom actually *is* rather than a discussion
about build systems.

Richard.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Carl-Daniel Hailfinger]

Am 22.03.22 um 07:01 schrieb David Hendricks:
> On Mon, Mar 21, 2022 at 4:48 PM Thomas Heijligen  wrote:
>
> Beside from the documentation, the meson file currently only works
> for Linux and was never announced as official way to build flashrom.
>
>
> The original reason for adding Meson was to support fwupd, a very
> important use case which AFAIK is only intended to work with internal
> programmers for in-system flashing in Linux.
>
> Mission creep was not the intention, though Meson has evidently gained
> popularity for other use cases. Notably, according to a comment in
> CB:61198  Chromium now
> uses Meson for all builds too. ChromeOS and fwupd are probably the
> biggest users of flashrom when it comes to use of internal
> programmers. Also, as mentioned earlier in the thread there are many
> distributions using Meson for packaging.
>
> It will be good to understand why they are going this route and if
> it's better for the project in the long run. Personally I am more
> familiar with Make, but even I can see that our Makefile is one that
> only a flashrom developer could love.

AFAIR there were three arguments for meson:
- Building dynamic libflashrom was nontrivial for the old makefile
(static libflashrom was always there)
- Meson is newer and easier on the eyes
- Meson build integrates nicely with other packages built by meson

Last time I checked, the following features were missing from the Meson
build script in flashrom:
- Complete crossbuild support
- Native support for most non-Linux platforms
- Support for quite a few programmers
- Anyone who checks that the binaries built by Meson and Makefile are
identical (admittedly that's not the fault of the code but a lack of
time/motivation)


There are even open bugs in Debian about Meson built flashrom:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955387
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976639

As a side note, we never used autotools even though one of the Debian
flashrom uploaders thinks so.


Our Makefile was not nice (I should know since I wrote most of the
ancient code). Nobody has shown up willing to add all the features of
Makefile to Meson and even if someone would be willing, we'd need
testers for all the features, which also didn't happen in the almost 3
years since Meson support was contributed.
I think Meson was a good idea, but it failed to get traction beyond "we
need it for dynamic libflashrom".

Side note: The now-defunct coreboot v3 also was a nice idea, but it
failed to gain the necessary developer mindshare due to missing support
for the use cases of most of the active coreboot developers. I was quite
sad because I really liked coreboot v3. While some good parts of it were
eventually adopted in coreboot v2/v4, quite a lot of development effort
was mostly useful for the learning experience. This feels similar.

AFAICS adding dynamic libflashrom support to Makefile would make the
Meson support a true subset and then we could switch back to using
Makefile for all cases. The current Makefile is a lot more readable than
the state 3 years ago, so arguably Meson did help.

Regards,
Carl-Daniel
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Thomas Heijligen]

On 22 March 2022 06:01:25 WET, David Hendricks  
wrote:
>It will be good to understand why they are going this route and if it's
>better for the project in the long run.
Meson is easier to use, especially when you have to deal with a lot of 
different projects. All variables you need are well defined and usable across 
all projects which uses meson. The build options are accessible without the 
need to dig into the buildfile or project documentation. With Makefiles every 
project has its own set of options and variables. That is an overhead you have 
to deal with as package maintainer.
>From a project developer perspective meson takes away a lot of work you 
>otherwise have to do by your own in the Makefile. For example system 
>determination, searching for dependencies and cashing of the build 
>configuration. 
>Personally I am more familiar with
>Make, but even I can see that our Makefile is one that only a flashrom
>developer could love.
I've spend a lot of time into the Makefile in the last month and my hope is 
that it's more readable by now. I'm truly not a fan of it and I would be happy 
if we can drop it. But implementation wise the meson.build is not better. It's 
a translation from the Makefile which makes only minimal use of mesons features.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[David Hendricks]

On Mon, Mar 21, 2022 at 4:48 PM Thomas Heijligen  wrote:

> Beside from the documentation, the meson file currently only works for
> Linux and was never announced as official way to build flashrom.
>

The original reason for adding Meson was to support fwupd, a very important
use case which AFAIK is only intended to work with internal programmers for
in-system flashing in Linux.

Mission creep was not the intention, though Meson has evidently gained
popularity for other use cases. Notably, according to a comment in CB:61198
 Chromium now uses Meson
for all builds too. ChromeOS and fwupd are probably the biggest users of
flashrom when it comes to use of internal programmers. Also, as mentioned
earlier in the thread there are many distributions using Meson for
packaging.

It will be good to understand why they are going this route and if it's
better for the project in the long run. Personally I am more familiar with
Make, but even I can see that our Makefile is one that only a flashrom
developer could love.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Thomas Heijligen]

On 21 March 2022 22:04:07 WET, Greg Troxel  wrote:
>
>Richard Hughes  writes:
>
>> On Mon, 21 Mar 2022 at 20:04, Nico Huber  wrote:
>>> There is also one big general issue: we need to maintain two build
>>> systems now. We can't use GNU make only, because nobody knows what
>>> the requirements of the Meson users are.
>>
>> My vote would be to remove the *Makefile*, and move 100% to Meson --
>> the modern build-system that's *already* being used by the packagers
>> for all the supported architectures and OS builds on dozens of
>> distros.
>
>FWIW, the pkgsrc build is currently using the Makefile.   I use that to
>get flashrom on NetBSD-9 amd64 to use with apu2.
>
>More importantly, the instructions in the README in flashrom 1.2 do not
>mention meson and say to use make.
>
>Similary,
>  https://www.flashrom.org/Downloads#Installation_from_source
>does not mention meson.
>(It also doesn't mention that specifically GNU make is required, vs BSD
>make, but that's pretty common to omit.)
>
>(I'm not claiming that building with meson wouldn't work, but just
>pointing out that "all packaging system builds use meson" is incorrect.)
>
>So if there is any talk of removing makefiles, there needs to be a
>release with formal support for meson including it being the standard
>approach in REAMDE and a deprecation warning.
>

Beside from the documentation, the meson file currently only works for Linux 
and was never announced as official way to build flashrom. Dropping the 
Makefile is also no option as long as the meson.build does not work with all 
platforms supported by flashrom. In a release we should have a consisted build 
system across all those platforms. 
The two build systems are also topic of the next developer meeting. Imo we 
should find a proper solution for the meson build file and do not rush for the 
next release.

-- Thomas
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Greg Troxel]

Richard Hughes  writes:

> On Mon, 21 Mar 2022 at 20:04, Nico Huber  wrote:
>> There is also one big general issue: we need to maintain two build
>> systems now. We can't use GNU make only, because nobody knows what
>> the requirements of the Meson users are.
>
> My vote would be to remove the *Makefile*, and move 100% to Meson --
> the modern build-system that's *already* being used by the packagers
> for all the supported architectures and OS builds on dozens of
> distros.

FWIW, the pkgsrc build is currently using the Makefile.   I use that to
get flashrom on NetBSD-9 amd64 to use with apu2.

More importantly, the instructions in the README in flashrom 1.2 do not
mention meson and say to use make.

Similary,
  https://www.flashrom.org/Downloads#Installation_from_source
does not mention meson.
(It also doesn't mention that specifically GNU make is required, vs BSD
make, but that's pretty common to omit.)

(I'm not claiming that building with meson wouldn't work, but just
pointing out that "all packaging system builds use meson" is incorrect.)

So if there is any talk of removing makefiles, there needs to be a
release with formal support for meson including it being the standard
approach in REAMDE and a deprecation warning.



signature.asc
Description: PGP signature
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Richard Hughes]

On Mon, 21 Mar 2022 at 20:04, Nico Huber  wrote:
> There is also one big general issue: we need to maintain two build
> systems now. We can't use GNU make only, because nobody knows what
> the requirements of the Meson users are.

My vote would be to remove the *Makefile*, and move 100% to Meson --
the modern build-system that's *already* being used by the packagers
for all the supported architectures and OS builds on dozens of
distros.

Richard
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Nico Huber]

Hello Richard,

On 21.03.22 17:23, Richard Hughes wrote:
> On Sun, 13 Mar 2022 at 15:49, Nico Huber  wrote:
>>> Also I understand Meson already got into v1.2? I thought the next version
>>> is based on the previous?
>> Yes, but I hope that doesn't mean we can't revert problems :)
>
> I don't think adding a smiley face makes it any less insulting to the
> people that added, and *continue to maintain* the meson feature.

sorry if the context offended you. I meant this rather generally: We
should be open to discuss such things. In the Meson case, I'd be happy
about any solution that avoids accidental use of Meson for releases,
i.e. when nobody tested if it's working correctly in a given environ-
ment.

>
>> The `meson.build` made it into v1.2, that is right but turned out to
>> cause more trouble than was expected. OS package maintainers quickly
>> adopted it without any second thought.
>
> Have you pondered why that might be? OS package maintainers usually
> don't change the way they build packages without a good reason.

I assume they got used to configuration systems like autotools/cmake/
Meson and use them by default if the necessary files are around. I
consider not using such a system the exception today.

>
>> And then all their packages had
>> issues because the `meson.build` did some things wrong (no version in-
>> formation in the binary for instance, no man page in the package, CLI
>> options not working).
>
> Are there any issues outstanding?

How should we know? Nobody is taking the time to really test the Meson
setup on Meson-supported platforms (except Linux). Or maybe somebody is
and doesn't tell us. The issues that were fixed so far were only iden-
tified when quirky binaries made it to the end users already. Fixing
issues is the easy part, one needs to find them first though. And if
that happens too late, it creates unnecessary work for developers and
package maintainers.

There is also one big general issue: we need to maintain two build
systems now. We can't use GNU make only, because nobody knows what
the requirements of the Meson users are. And we can't use Meson only,
because nobody knows if and how it works on all the platforms suppor-
ted by the Makefile.

Nico

> All this talk of "removing things"
> does not give me the warm-and-fuzzies for building things on top of
> the flashrom project.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Richard Hughes]

On Sun, 13 Mar 2022 at 15:49, Nico Huber  wrote:
> > Also I understand Meson already got into v1.2? I thought the next version
> > is based on the previous?
> Yes, but I hope that doesn't mean we can't revert problems :)

I don't think adding a smiley face makes it any less insulting to the
people that added, and *continue to maintain* the meson feature.

> The `meson.build` made it into v1.2, that is right but turned out to
> cause more trouble than was expected. OS package maintainers quickly
> adopted it without any second thought.

Have you pondered why that might be? OS package maintainers usually
don't change the way they build packages without a good reason.

> And then all their packages had
> issues because the `meson.build` did some things wrong (no version in-
> formation in the binary for instance, no man page in the package, CLI
> options not working).

Are there any issues outstanding? All this talk of "removing things"
does not give me the warm-and-fuzzies for building things on top of
the flashrom project.

Richard
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Nico Huber]

Hi,

On 21.03.22 10:11, Anastasia Klimchuk wrote:
> Thank you for the explanations! Really helpful.
>
> I am trying to understand the mechanics.
>
>> This is also why I suggested that we can drop suspicious
>> code from a release branch (i.e. we could branch 1.3.x now
>> and then delete code on that branch without affecting master).
>> Then the freeze might be over really quickly.
>
> This option would mean all the items from the first list are reverted in
> v1.3?

in the most extreme scenario, yes. Please note that I don't consider
everything on that list as a release blocker. Some things just looked
odd and may only need a second look.

> And then they, hopefully, all get fixed to the time of v1.4?
> (correct me if I am wrong)

Hopefully, yes. Not sure what to do if not, I wouldn't like to
repeatedly clean up on release branches. Also, some of the items
look like something we wouldn't even want on master, e.g. known
broken things.

>
> Then that means on the other end there is an ideal scenario where all the
> items from the first list are fixed (on master) and then v1.3 happens?

Then we would branch 1.3.x from master and v1.3-rc1 happens.

>
> And also a scenario in between when some of the items are fixed, but not
> all of them?

Pretty much, yes, and I'd hope for this. Better to compromise than to
wait forever ;)

>
> Which of these scenarios has minimum time to freeze master, and which one
> takes second place? I am asking because I fully agree with you, it seems
> just as you said “a very desperate measure”... so I am worried this may
> create a drama :\

Given that nobody reacted with "let's do it", it seems very unlikely
to me that we will exercise a freeze.

Nico
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Anastasia Klimchuk]

Thank you for the explanations! Really helpful.

I am trying to understand the mechanics.

“This is also why I suggested that we can drop suspicious
code from a release branch (i.e. we could branch 1.3.x now
and then delete code on that branch without affecting master).
Then the freeze might be over really quickly.”

This option would mean all the items from the first list are reverted in
v1.3?
And then they, hopefully, all get fixed to the time of v1.4?
(correct me if I am wrong)

Then that means on the other end there is an ideal scenario where all the
items from the first list are fixed (on master) and then v1.3 happens?

And also a scenario in between when some of the items are fixed, but not
all of them?

Which of these scenarios has minimum time to freeze master, and which one
takes second place? I am asking because I fully agree with you, it seems
just as you said “a very desperate measure”... so I am worried this may
create a drama :\

We have already created 5 bugs as “flashrom release blockers” in our
internal bug tracker (the only reason they are created in internal one is
because flashrom bug tracker is not ready yet). There is no secret info
there at all. That’s for all the items that are missing documentation.
It is not a hasty activity, we want to help! Release is important.
And especially the items which say “missing documentation”, it’s a
no-brainer, needs to be fixed.

“My latest idea about this is that we could add an option (e.g.
`inofficial`) and a whitelist of known working platforms. Such that
one would have to literally state they want an inofficial binary to
build on a platform with unknown status.”

Looks fine, let’s keep it unofficial (if it really is). Let’s just not
delete it :)

“I can work on that unless someone else wants the task.”

Thanks Martin! There is a patch currently for man page:
https://review.coreboot.org/c/flashrom/+/62768
But did you mean more than that?

On Fri, Mar 18, 2022 at 2:56 AM Nico Huber  wrote:

> On 13.03.22 16:28, Nico Huber wrote:
> > On 13.03.22 08:28, Anastasia Klimchuk wrote:
> >>> I suggest that we freeze the master branch for everything that is
> neither
> >>> a fix nor on the list (or a similar case that I missed)
> >>
> >> But how can we freeze master… that would mean no one can do any work?
> Maybe
> >> I am missing something?
> >
> > No you didn't miss anything :) it would be a very desperate
> > measure. However, I see no other solution to make progress
> > again without forking or further stalling a release. And
> > after 2 years I think the project has waited long enough.
>
> Sorry folks, I didn't mean to provoke any hasty activity to fix the
> listed problems. Rather to push us to talk about what we should fix
> before a release and what features we could do without in a release.
> If we'd wait for everything to be fixed at snail pace, I fear people
> would give up before another release happens (I would). Not to mention
> that people will continue to push more controversial patches in the
> meantime.
>
> Nico
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>


-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Nico Huber]

On 13.03.22 16:28, Nico Huber wrote:
> On 13.03.22 08:28, Anastasia Klimchuk wrote:
>>> I suggest that we freeze the master branch for everything that is neither
>>> a fix nor on the list (or a similar case that I missed)
>>
>> But how can we freeze master… that would mean no one can do any work? Maybe
>> I am missing something?
>
> No you didn't miss anything :) it would be a very desperate
> measure. However, I see no other solution to make progress
> again without forking or further stalling a release. And
> after 2 years I think the project has waited long enough.

Sorry folks, I didn't mean to provoke any hasty activity to fix the
listed problems. Rather to push us to talk about what we should fix
before a release and what features we could do without in a release.
If we'd wait for everything to be fixed at snail pace, I fear people
would give up before another release happens (I would). Not to mention
that people will continue to push more controversial patches in the
meantime.

Nico
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Martin L Roth]

On Sun, Mar 13, 2022 at 9:49 AM Nico Huber  wrote:

> On 13.03.22 08:28, Anastasia Klimchuk wrote:
>
...

> >> ad08aef6 Undocumented programmer. disable? drop from realease branch?
> >
> > I looked that is about raiden debug programmer. If it is undocumented,
> can
> > we document?
>
> Hopefully. IMO, the minimum for a new programmer to be accepted upstream
> is a section in the manpage, including documentation about programmer
> parameters. With such documentation at hand, we could even start to re-
> view the code ;)
>
> I had a look at the comment on top of `raiden_debug_spi.c` right now.
> I knew it was attached over USB, but it seems that the other end goes
> directly to the target device (not any kind of dongle between two
> computers). If that is the case, it would be important to know what
> Chromebook (I guess) models support it.


The raiden driver works with a number of different ChromeOS debug methods,
 not just chromebooks directly:
1) ChromeOS devices that support case closed debug (CCD) using the
SuzyQable.
  -  Make your own: https://www.youtube.com/watch?v=WGsyXlgSxFk
  - Was sold by sparkfun, but due to the chip shortages, it's out of stock.

2) ChromeOS devices that support CCD, using the Servo-V4 device.
 - This device and the two below are only available from google, because we
   haven't found a reseller that will partner with us to manufacture and
sell it.
 - Both of these are documented on the CCD page at chromium.org:

https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/docs/ccd.md

3) New ChromeOS devices that use the C2D2 debugger & 8-pin connector.
  - Somewhat documented at chromum.org:

https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/docs/using_em100_with_c2d2.md

4) Old ChromeoOS devices that use the older style servo connector, debugged
with the uServo debugger.
  - Documented at chromium.org:

https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/docs/servo_micro.md

The raiden driver is actually just a basic USB to serial driver that
expects the Google UBS VIDs & DIDs.  The flashrom interface
sets up the packets in the way that the debugger on the other end
of the device expects.

As Nico mentioned, there's good documentation in the flashrom code
already, and the entire rest of the interface is in the ChromeOS EC
codebase, so it shouldn't be difficult to get the documentation done.

I can work on that unless someone else wants the task.

Martin
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Nico Huber]

On 13.03.22 08:28, Anastasia Klimchuk wrote:
> Some of the things in the first list that I wanted to ask about:
>
>> cb973683 Added partial meson support which confuses package main-
>>  tainers.
>>  Should we remove it from or disable CLI building on release
>>  branches?”
>
> Oh, we are using meson in the chromium tree to build everything. I added a
> topic to the meeting agenda about Meson and Makefile, although it
> overflowed to the next meeting.
>
> Also I understand Meson already got into v1.2? I thought the next version
> is based on the previous?
>

Yes, but I hope that doesn't mean we can't revert problems :)

The `meson.build` made it into v1.2, that is right but turned out to
cause more trouble than was expected. OS package maintainers quickly
adopted it without any second thought. And then all their packages had
issues because the `meson.build` did some things wrong (no version in-
formation in the binary for instance, no man page in the package, CLI
options not working). Almost nobody tried to build the flashrom CLI
with Meson before. The known issues are fixed, but so far we only know
that it works on x86 and ARM with Linux (that's likely less than 10% of
what is expected to work with the Makefile).

My latest idea about this is that we could add an option (e.g.
`inofficial`) and a whitelist of known working platforms. Such that
one would have to literally state they want an inofficial binary to
build on a platform with unknown status.

>> ad08aef6 Undocumented programmer. disable? drop from realease branch?
>
> I looked that is about raiden debug programmer. If it is undocumented, can
> we document?

Hopefully. IMO, the minimum for a new programmer to be accepted upstream
is a section in the manpage, including documentation about programmer
parameters. With such documentation at hand, we could even start to re-
view the code ;)

I had a look at the comment on top of `raiden_debug_spi.c` right now.
I knew it was attached over USB, but it seems that the other end goes
directly to the target device (not any kind of dongle between two
computers). If that is the case, it would be important to know what
Chromebook (I guess) models support it.

Nico
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Nico Huber]

Hi Anastasia,

On 13.03.22 08:28, Anastasia Klimchuk wrote:
>> I've been scrolling through the commit log from v1.1 (the last release
>> I was involved) to today's master.
>
> I am wondering why v1.1, I know the latest released version is v1.2? Is
> there anything about v1.2 release why you don’t count it?

tl;dr it was done in a hurry, IIRC.

Starting with 1.0, I maintained release branches per minor release
(1.0.x, 1.1.x). The plan was to also make point releases on these
branches if any fixes made it into a new release (and also apply
to a release branch). I assume nobody kept track what might also
apply to these branches until today. And to be honest, I forgot
if there just wasn't anything applicable between v1.1 and v1.2 or
if we didn't check ;)

v1.1 was also the last release before some incredibly chaotic
development started. To converge forks, some people seemed to
push simple diffs of up- and downstream to upstream flashrom.
Not sure what drove it, but the idea seems to have been that
downstream was ahead, while it was actually years behind. Some
of such patches made it into the master branch and I wanted to
try at least one time to figure out if there was anything left
that wasn't reverted yet.

>
>> I suggest that we freeze the master branch for everything that is neither
>> a fix nor on the list (or a similar case that I missed)
>
> But how can we freeze master… that would mean no one can do any work? Maybe
> I am missing something?

No you didn't miss anything :) it would be a very desperate
measure. However, I see no other solution to make progress
again without forking or further stalling a release. And
after 2 years I think the project has waited long enough.

This is also why I suggested that we can drop suspicious
code from a release branch (i.e. we could branch 1.3.x now
and then delete code on that branch without affecting master).
Then the freeze might be over really quickly. We'd only need
to decide what to do with the code instead of fixing every-
thing at once. However, if that would result in no action on
the master branch until we branch 1.4.x, I would vote to delete
the code on the master branch too.

> Also I am looking at two lists. The first one, is my understanding correct,
> those can be bugs in bugtracker (which we will have soon right? :)) and
> assigned to different people?

Very much so.

>
> The second list Backport, are those good commits that go to the release?>
> What is happening with all the other commits? (between v1.1 and now that
> would be a lot of them). I am just trying to understand the technical
> process.

This is about the older release branches. I just wrote down the
commits that looked like they might fix something that was already
an issue years ago. IOW, the second list doesn't matter for the
v1.3 release.

Nico
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Rosen Penev]

On Sun, Mar 6, 2022 at 3:10 PM Nico Huber  wrote:
>
> Hi folks,
>
> people often ask me about a potential next release and what is holding
> me back. Long story short, I knew about some bad things in our master
> branch that make a release impossible and I was very much afraid that
> there could be more that I don't know about.
>
> I've been scrolling through the commit log from v1.1 (the last release
> I was involved) to today's master. Some of the things I found are simple
> like something missing for a flash chip entry. But most of it are things
> I'd rather not have on a release branch. And the list turned out to be
> much longer than I expected. OTOH, I didn't find issues of the worst
> kind I expected.
>
> Not sure how to go on from here. As this is a lot to do, I suggest
> that we freeze the master branch for everything that is neither a fix
> nor on the list (or a similar case that I missed). I noted sometimes
> that we could just drop the code from a release branch. If we'd decide
> to do that, we'd also need a plan how to stop the rot on the master
> branch.
I have these applied to the OpenWrt tree:
https://github.com/flashrom/flashrom/pulls/neheb . I recently rebased.
>
> Below are my raw notes, I don't have the time to write things up nicely.
> I noted the commit hash where things began, but tried to take the cur-
> rent state into account. For instance, when it's about a new programmer
> driver, I was looking at the file, not the initial patch.
>
> Cheers,
> Nico
>
> Recommended clean-ups and investigations before v1.3
> 
>
> * cb973683 Added partial meson support which confuses package main-
>tainers.
>Should we remove it from or disable CLI building on release
>branches?
>
> * 71b706f5 Adds some libflashrom APIs with questionable design, buggy
>implementation and no visible user. Would be easiest to drop
>and add back when somebody needs it.
>Open comment. Partially fixed up.
>
> * 86fc9cf7 Open comment. Partially fixed up.
>
> * 05c629be Looks incomplete, flash would be fully erased with
>programmers that lack native 4BA command support.
>
> * ad08aef6 Undocumented programmer. disable? drop from realease branch?
>
> * 703de983 Added `spireadmode` param to sb600spi. (How) does it work?
>
> * 13a2ef6c Added `lspcon_i2c_spi`. Too generic name: LSPCon is a concept
>but driver seems to be about a specific vendor/chip. No pro-
>bing just starts to write to hardcoded addresses. WP code
>contains magic numbers, board specific? Implements `spi_
>master` but contains hard-coded SPI opcodes. Not documented?
>disable? drop from release branch?
>
> * d97f87b0 Added `realtek_mst_i2c_spi`. No probing, starts by toggling
>a GPIO. Are GPIO settings board specific? Timeout checks seem
>to have regressed since original commit. Not documented?
>Changes clock settings, is this board specific? Implements
>`spi_master` with special cases in an opcode LUT, doesn't
>bail out on unknown codes. Falls back on unaligned reads/
>writes, were these paths tested? Fixups suggest that the
>original code wasn't properly tested, was it by now?
>disable? drop from release branch?
>
> * be4682dc Might miss some block erasers.
>
> * f82dd300 Might miss some block erasers.
>
> * a2dc4f7f It seems `clear_spi_id_cache()` is never called. Probably,
>should be before probing.
>
> * 3149822c Added variable size in `dummy_programmer`. Didn't look
>at it right now, but I remember it caused a lot of trouble.
>Probably not fully fixed up yet.
>
> * cb9f3cd0 Possible division by zero.
>
> * ca2e3bce Fixed some libpci usage. IIRC, there are many more similar
>cases that might need a fix now that libpci is more strict.
>
> * 0386aa17 sb600spi refactoring. Looks like it dropped an error message
>from many error paths.
>
> * f745d0e6, adbae0e2 Added infrastructure for S25F chips. Code style
>looks a bit outdated. Probably needs upstream review.
>
> * 8fa792fb Added chips with oddities and w/o reasoning, e.g:
>.total_size  = 16384,  /* This is just half the size */
>Complete patch needs review.
>
> * 855d6b6f Added Ryzen support to sb600spi. API violations. Stalled
>other cleanup work. Soft bricks machines with >16MiB flash.
>Patches on Gerrit.
>drop from release branch?
>
> * 32f4cb4f Looks like copy-pasta from Winbond chips. Might miss some
>block erasers. Missing 4BA_WRITE is probably wrong.
>
> * 45d50a10 Added support code for per-region file arguments. Review was
>interrupted, IIRC. Rebase was borked shortly before merge.
>Work never finished.
>
> * d4063bf3 Missed to update the manp

[flashrom] Re: Release preparations

[Anastasia Klimchuk]

Hello Nico,

“I've been scrolling through the commit log from v1.1 (the last release

I was involved) to today's master.”

I am wondering why v1.1, I know the latest released version is v1.2? Is
there anything about v1.2 release why you don’t count it?

“I suggest

that we freeze the master branch for everything that is neither a fix

nor on the list (or a similar case that I missed)”

But how can we freeze master… that would mean no one can do any work? Maybe
I am missing something?

Also I am looking at two lists. The first one, is my understanding correct,
those can be bugs in bugtracker (which we will have soon right? :)) and
assigned to different people?

The second list Backport, are those good commits that go to the release?

What is happening with all the other commits? (between v1.1 and now that
would be a lot of them). I am just trying to understand the technical
process.

Some of the things in the first list that I wanted to ask about:

“cb973683 Added partial meson support which confuses package main-

   tainers.

   Should we remove it from or disable CLI building on release

   branches?”

Oh, we are using meson in the chromium tree to build everything. I added a
topic to the meeting agenda about Meson and Makefile, although it
overflowed to the next meeting.

Also I understand Meson already got into v1.2? I thought the next version
is based on the previous?

“ad08aef6 Undocumented programmer. disable? drop from realease branch?”

I looked that is about raiden debug programmer. If it is undocumented, can
we document?


On Mon, Mar 7, 2022 at 10:10 AM Nico Huber  wrote:

> Hi folks,
>
> people often ask me about a potential next release and what is holding
> me back. Long story short, I knew about some bad things in our master
> branch that make a release impossible and I was very much afraid that
> there could be more that I don't know about.
>
> I've been scrolling through the commit log from v1.1 (the last release
> I was involved) to today's master. Some of the things I found are simple
> like something missing for a flash chip entry. But most of it are things
> I'd rather not have on a release branch. And the list turned out to be
> much longer than I expected. OTOH, I didn't find issues of the worst
> kind I expected.
>
> Not sure how to go on from here. As this is a lot to do, I suggest
> that we freeze the master branch for everything that is neither a fix
> nor on the list (or a similar case that I missed). I noted sometimes
> that we could just drop the code from a release branch. If we'd decide
> to do that, we'd also need a plan how to stop the rot on the master
> branch.
>
> Below are my raw notes, I don't have the time to write things up nicely.
> I noted the commit hash where things began, but tried to take the cur-
> rent state into account. For instance, when it's about a new programmer
> driver, I was looking at the file, not the initial patch.
>
> Cheers,
> Nico
>
> Recommended clean-ups and investigations before v1.3
> 
>
> * cb973683 Added partial meson support which confuses package main-
>tainers.
>Should we remove it from or disable CLI building on release
>branches?
>
> * 71b706f5 Adds some libflashrom APIs with questionable design, buggy
>implementation and no visible user. Would be easiest to drop
>and add back when somebody needs it.
>Open comment. Partially fixed up.
>
> * 86fc9cf7 Open comment. Partially fixed up.
>
> * 05c629be Looks incomplete, flash would be fully erased with
>programmers that lack native 4BA command support.
>
> * ad08aef6 Undocumented programmer. disable? drop from realease branch?
>
> * 703de983 Added `spireadmode` param to sb600spi. (How) does it work?
>
> * 13a2ef6c Added `lspcon_i2c_spi`. Too generic name: LSPCon is a concept
>but driver seems to be about a specific vendor/chip. No pro-
>bing just starts to write to hardcoded addresses. WP code
>contains magic numbers, board specific? Implements `spi_
>master` but contains hard-coded SPI opcodes. Not documented?
>disable? drop from release branch?
>
> * d97f87b0 Added `realtek_mst_i2c_spi`. No probing, starts by toggling
>a GPIO. Are GPIO settings board specific? Timeout checks seem
>to have regressed since original commit. Not documented?
>Changes clock settings, is this board specific? Implements
>`spi_master` with special cases in an opcode LUT, doesn't
>bail out on unknown codes. Falls back on unaligned reads/
>writes, were these paths tested? Fixups suggest that the
>original code wasn't properly tested, was it by now?
>disable? drop from release branch?
>
> * be4682dc Might miss some block erasers.
>
> * f82dd300 Might miss some block erasers.
>
> * a2dc4f7f It seems `cle