On Tue, Jul 13, 2010 at 01:58:50PM +0000, Michael Shalayeff wrote:
> re
> i was testing the diff on our shitz here and it works.
> dual-port Intel PRO/1000 on pci-express and on-boards.
> added a couple more checks where it seemed to make sense.
> those ports having problems before seem to work now.
> cu

Skipping the parts from the original diff

> @@ -846,20 +847,21 @@ em_initialize_hardware_bits(struct em_hw *hw)
>  
>                  if (reg_tctl & E1000_TCTL_MULR)
>                      reg_tarc1 &= ~0x10000000;   /* Clear bit 28 if MULR is 
> 1b */
>                  else
>                      reg_tarc1 |= 0x10000000;    /* Set bit 28 if MULR is 0b 
> */
>  
>                  E1000_WRITE_REG(hw, TARC1, reg_tarc1);
>                  break;
>              case em_82573:
>              case em_82574:
> +            case em_82575:
>                  reg_ctrl_ext = E1000_READ_REG(hw, CTRL_EXT);
>                  reg_ctrl = E1000_READ_REG(hw, CTRL);
>  
>                  reg_ctrl_ext &= ~0x00800000;    /* Clear bit 23 */
>                  reg_ctrl_ext |= 0x00400000;     /* Set bit 22 */
>                  reg_ctrl &= ~0x20000000;        /* Clear bit 29 */
>  
>                  E1000_WRITE_REG(hw, CTRL_EXT, reg_ctrl_ext);
>                  E1000_WRITE_REG(hw, CTRL, reg_ctrl);
>                  break;

What are these magic numbers doing and why is it needed on 82575+?

> @@ -3864,21 +3866,21 @@ em_write_phy_reg_ex(struct em_hw *hw, uint32_t reg_add
>  
>  STATIC int32_t
>  em_read_kmrn_reg(struct em_hw *hw,
>                      uint32_t reg_addr,
>                      uint16_t *data)
>  {
>      uint32_t reg_val;
>      uint16_t swfw;
>      DEBUGFUNC("em_read_kmrn_reg");
>  
> -    if ((hw->mac_type == em_80003es2lan) &&
> +    if ((hw->mac_type == em_80003es2lan || hw->mac_type == em_82575) &&
>          (E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1)) {
>          swfw = E1000_SWFW_PHY1_SM;
>      } else {
>          swfw = E1000_SWFW_PHY0_SM;
>      }
>      if (em_swfw_sync_acquire(hw, swfw))
>          return -E1000_ERR_SWFW_SYNC;
>  
>      /* Write register address */
>      reg_val = ((reg_addr << E1000_KUMCTRLSTA_OFFSET_SHIFT) &


Yes, although this function is never called on 82575/82576.

> @@ -5944,20 +5946,21 @@ em_rar_set(struct em_hw *hw,
>       * while we work.  Then, we clear the Address Valid AV bit for all MAC
>       * addresses and undo the re-direction to manageability.
>       * Now, frames are coming in again, but the MAC won't accept them, so
>       * far so good.  We now proceed to initialize RSS (if necessary) and
>       * configure the Rx unit.  Last, we re-enable the AV bits and continue
>       * on our merry way.
>       */
>      switch (hw->mac_type) {
>      case em_82571:
>      case em_82572:
> +    case em_82575:
>      case em_80003es2lan:
>          if (hw->leave_av_bit_off == TRUE)
>              break;
>      default:
>          /* Indicate to hardware the Address is Valid. */
>          rar_high |= E1000_RAH_AV;
>          break;
>      }
>  
>      E1000_WRITE_REG_ARRAY(hw, RA, (index << 1), rar_low);

I'm not convinced about this part either, the rar handling
in the most recent version of the Intel code in FreeBSD is
quite different, perhaps more than just this should be changed.

Reply via email to