[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140602.175816.1677581007124366598.davem@davemloft.net>
Date: Mon, 02 Jun 2014 17:58:16 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: bhelgaas@...gle.com
Cc: weiyang@...ux.vnet.ibm.com, ogerlitz@...lanox.com,
netdev@...r.kernel.org, amirv@...lanox.com,
jackm@....mellanox.co.il
Subject: Re: [PATCH net] net/mlx4_core: Fix Oops on reboot when SRIOV VFs
are probed into the Host
From: Bjorn Helgaas <bhelgaas@...gle.com>
Date: Mon, 2 Jun 2014 10:10:01 -0600
> Writing a driver is not an empirical process of trying things to see
> what works. You need to actively design a consistent structure so you
> know why and when things are safe. I object to gratuitous "dev ==
> NULL" checks because often they are just a way of patching up a driver
> design that isn't well thought-out.
>
> As I wrote before:
>
> From the PCI core's perspective, after .probe() returns successfully,
> we can call any driver entry point and pass the pci_dev to it, and
> expect it to work. Doing mlx4_remove_one() in mlx4_pci_err_detected()
> sort of breaks that assumption because you clear out pci_drvdata().
> Right now, the only other entry point mlx4 really implements is
> mlx4_remove_one(), and it has a hack that tests whether pci_drvdata()
> is NULL. But that's ... a hack, and you'll have to do the same
> if/when you implement suspend/resume/sriov_configure/etc.
Agreed.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists