On Mon, 1 Feb 2021 13:05:10 -0800 Edwin Peer wrote: > On Mon, Feb 1, 2021 at 12:29 PM Jakub Kicinski <k...@kernel.org> wrote: > > > > I think it should be deterministic. It should be possible to select > > > the appropriate mode either based on the current media type or the > > > current link mode (which implies a media type). Alternatively, if the > > > user space request only specifies a subset, such as speed, fall back > > > to the existing behaviour and don't supply the request to the driver > > > in the form of a compound link mode in those cases (perhaps indicating > > > this by not setting the capability bit). The former approach has the > > > potential to tidy up drivers if we decide that drivers providing the > > > capability can ignore the other fields and rely solely on link mode, > > > the latter is no worse than what we have today. > > > > The media part is beginning to sound concerning. Every time we > > under-specify an interface we end up with #vendors different > > interpretations. And since HW is programmed by FW in most high > > speed devices we can't even review the right thing is done. > > Each link mode implies a very specific media type, the kernel can > reject illegal combinations based on the supported bitmask before > calling upon the driver to select it.
Are you talking about validation against a driver-supplied list of HW-supported modes, or SFP-supported modes for a currently plugged in module? If I'm reading prior responses right it is the former. The concern is around "what happens if user selected nnG-SR4 but user plugged in nnG-CR4". The MAC/PHY/serdes settings will be identical.
