On 5/19/2017 11:04 AM, Srinivasan J wrote: > Hi Wei, > Yes the changes are in ixgbe_dev_start( ), the patch shows > the function as eth_ixgbevf_pci_remove() probably due to the way diff > recognizes the change. I have tested the change using Intel > Corporation 82599ES.
Hi Srinivasan, Wei, What is the latest status of the patch? Are all issues pointed by Wie addressed in the patch, or are we waiting for a new version? Thanks, ferruh > > Thanks, > Srini > > On Tue, May 16, 2017 at 9:04 AM, Dai, Wei <wei....@intel.com> wrote: >> Hi, Srini >> >> There is a bit confusion. Your patch shows that your code is added into the >> function eth_ixgbevf_pci_remove( ). >> But it is not. It is added into the fucntion ixgbe_dev_start( ), right ? >> So would you please rebase it to R 17.05 ? >> >> Which type of ixgbe device id did you tested ? >> >> There are many MAC types with different device id. >> >> The function ixgbe_pf_reset_hw(hw) is called before your adding code. >> ixgbe_pf_reset_hw() calls hw->mac.ops.reset_hw( ) which may points to >> following different function for different MAC type. >> Ixgbe_reset_hw_82598( ) calls hw->phy.ops.init(hw) if hw->phy.reset_disable >> == false . >> Ixgbe_reset_hw_82599( ) calls hw->phy.ops.init(hw) unconditionally. >> ixgbe_reset_hw_X540( ) doesn't' call pw->phy.ops.init(hw). For X540, >> hw->phy.ops.init points to ixgbe_init_phy_ops_generic() which only >> initialize some function pointers. >> Ixgbe_rest_hw_x550em() calls hw->phy.ops.init(hw) unconditionally. >> >> And for VF, ixgbe_reset_hw_vf( ) and ixgbevf_hv_reset_hw_vf( ) don't call >> hw->phy.ops.init(hw) anywhere. >> >> Thanks & Best Regards >> -Wei >> >>> -----Original Message----- >>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon >>> Sent: Sunday, May 7, 2017 6:36 AM >>> To: Srinivasan J <srinid...@gmail.com> >>> Cc: dev@dpdk.org; Lu, Wenzhuo <wenzhuo...@intel.com>; Ananyev, >>> Konstantin <konstantin.anan...@intel.com> >>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped >>> SFP/SFP+ >>> >>> 06/05/2017 15:51, Srinivasan J: >>>> Hi, >>>> Do we need an explicit "Acked-by" keyword for this >>>> patch to be accepted and applied? >>> >>> Yes, given it is not a trivial patch, an ack from the maintainer is >>> required. >>> Anyway, it has been submitted too late for 17.05 testing.
