Hi Anastasia,

I've seen you put some questions about the programmer tickets[1-4] on
the meeting agenda. I hope I can provide some answers already. Looking
at the tickets, I see there are already lists of things to do. But you
ask what is left to do. So somewhere seems to be a misunderstanding.

* raiden_debug_spi: Seems ok. I think this one was really only missing
  a manpage entry. Now that it has some context, I guess an independent
  developer could actually review it now. ^^

* lspcon_i2c_spi & realtek_mst_i2c_spi: There's a misunderstanding I
  guess. The tickets say "Document ... programmer". But they list actual
  problems. My idea when I wrote the long lists of issues was not to
  document issues. But, hopefully, to get them addressed, in code.

  We could also document the issues, e.g. by cluttering the code with
  FIXME comments. This might at least slow the spreading of such code
  down. But I would have to ask, why have these drivers on the master
  branch? In one of the tickets it even says the driver is not used
  in production. Does that mean it's abandoned?

  Like I mentioned elsewhere, many of the issues could be mitigated by
  going through the board_enabled infrastructure. This was also men-
  tioned in the review of the mediatek_i2c_spi driver. All these I2C
  drivers could share a similar design, AFAICT.

  One of the manpage entries also revealed a new problem: I think it
  implies that after running `flashrom -p realtek_mst_i2c_spi:bus=0 -E`
  the device would be broken after a reset. That's unacceptable for
  flashrom. Another sign that it should go through the infrastructure
  of the internal programmer.

  Documentation for the hardware interface would also be very welcome.
  Basically, everything that one needs to understand the code (and can't
  be derived from flashrom sources) should be publicly documented.
  I think we should make this a rule for vendor additions.

* mediatek_i2c_spi: What I have to say about this, I did on Gerrit.
  What happened is clearly against our development guidelines. It's
  a copy of another driver, but we don't have the time to look into
  it so let the community take care of it? WTF?

Nico

[1] https://ticket.coreboot.org/issues/358
[2] https://ticket.coreboot.org/issues/360
[3] https://ticket.coreboot.org/issues/361
[4] https://ticket.coreboot.org/issues/376
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

Reply via email to