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