On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote: > On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: > > On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: > > > The challenge here is that because struct netdev is initialized to all > > > zeros, code that consumes dev_id can't tell the difference between a > > > driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a > > > default (unset) value of 0. I think the only solution here is to make > > > sure the kernel drivers, if they need to set it, always set this > > > non-zero, so udev, seeing a non-zero value, knows it's a valid value > > > to use. > > > > These seem to be the 4 drivers currently setting dev_id: > > > > drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap->port[i]->dev_id = j; > > drivers/net/ethernet/freescale/fec.c: fep->dev_id = dev_id++; > > Look up a few lines: > > /* setup board info structure */ > fep = netdev_priv(ndev); > > fep is not a pointer to the net_device, but to the private device > structure. This is why I didn't include it in the list. Good catch. > > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev->dev_id = port - 1; > > drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; > > > > of these, both the mlx4 and siena drivers set them starting at 0. I > > think the fec driver might be doing so as well, but it's not as > > obvious. I'm pretty sure cxgb4 starts numbering at 1 just from > > reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be > > comfortable relying on the value of dev_id. > > I agree it looks like some cleanup is needed due to the inconsistency. > > This is still only an issue when a single function supports multiple > ethernet devices, right? I believe so, yes. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
