On Thu, 5 Apr 2018, Mark Kettenis wrote: > > Date: Thu, 5 Apr 2018 02:02:20 +1000 > > From: Jonathan Gray <j...@jsg.id.au> > > > > On Mon, Apr 02, 2018 at 11:52:08AM +0200, Stefan Fritsch wrote: > > > Hi, > > > > > > We have seen problems with em on i219V and i219LM. For example, "Hardware > > > Initialization Failed" if no cable is plugged in during boot, or watchdog > > > timeouts / hangs until next boot if the cable is removed while data is > > > transmitted. > > > > > > This patch adds a bunch of quirks and fixes from freebsd. > > > > Can you split this into a few patches? It would be easier to review/backout > > individual parts if needed.
I can do that. Will take a bit, though. > > > > Ie I wonder if the sw_flag parts could be done differently but other > > parts could go in without that. In the long term, it may be a good idea to scrap all files except if_em.c, write an openbsd specific e1000_osdep.c, and import all other files from freebsd. This would be similar to what is done for drm, though hopefully importing new versions of e1000 would be much less work than importing new versions of drm. I see no other sane way to keep track of all the hardware quirks. But I don't have time for that in the near future. > > printf format string could change from ", mac_type %#x phy_type %#x" > > to ", mac %#x phy %#x" though I'm not sold on the value of printing > > it to begin with. The PCH ems all have a single PHY, MAC can be > > inferred from pcidump. The question is how many intel PDFs do you need to read to get from pcidump to phy/mac type. > Must admit that it makes me a bit sad to print this as well. Maybe > wrap this in #ifdef DEBUG such that it is easy to enable for people > when requested. Will do that. Cheers, Stefan
