>> just a comment: >> >> drivers with firmware have often had special parameters to the stop or >> reset functions to indicate a difference between "stop moving traffic" >> or "shut it all down". We seem to keep switching this back and forth. >> Reason is we've had some very bizzare failure conditions in drivers, >> in some cases even stop->firmware->restart ... RECURSION! It may not >> be worth simply deleting this flag, unless it is sure this driver's >> firmware-load / firmware-reset / "ifconfig down" / other behaviours >> will never (including in future chip models) need it. Then this >> flagging may simply have to be added back. > >Interesting. It seems such issues didn't prevail after all?
it has been a mess. the recursive driver was pgt(4) >And yes, we can simply add it back when needed. sure, but someone adding it back might add it "with some pieces missing", and then we round-trip bug discover a few times. not that this current framework is "right", but it looks close to right (strange thing: often a diff for the intentional removal of a thing makes it really clear what is is doing, too bad we rarely have such insight into the other parts of drivers, maybe we should invest heavy effort into deleting all features, to at least see what they look like and then repair them :) >By the way, the following files in dev/pci use this pattern: > >if_cas.c >if_ipw.c >if_iwi.c >if_iwn.c >if_nfe.c >if_pcn.c >if_stge.c >if_wpi.c >if_xge.c > >The 'disable' parameter only has an effect in pcn and stge >where it controls draining of the Rx queue. It has no effect >in any of the other drivers. Historical baggage? Maybe. pgt(4) was not a Bergamini driver, but it followed that framework. Wonder how malo(4) side-stepped this.
