|
| Applied to 'sky2' branch of netdev-2.6.git. Let me know when the RX
| hangs are fixed, and we can push upstream.
Okay. Most all of your comments are straightforward
and fixes will be in the next version, but some need
a little more discussion...
|
| > +static void gm_phy_write(struct sky2_hw *hw, unsigned port, u16 reg, u16
val)
| > +{
| > + int i;
| > +
| > + gma_write16(hw, port, GM_SMI_DATA, val);
| > + gma_write16(hw, port, GM_SMI_CTRL,
| > + GM_SMI_CT_PHY_AD(PHY_ADDR_MARV) | GM_SMI_CT_REG_AD(reg));
| > +
| > + for (i = 0; i < PHY_RETRIES; i++) {
| > + udelay(1);
|
| PCI posting bug... do we care?
We always end up doing a read of the control register
so how is that a problem?
| > + sky2_write8(hw, SK_REG(port, GMAC_IRQ_MSK), 0);
| > + /* disable PHY IRQs */
| > + gm_phy_write(hw, port, PHY_MARV_INT_MASK, 0);
| > + gma_write16(hw, port, GM_MC_ADDR_H1, 0); /* clear MC hash */
| > + gma_write16(hw, port, GM_MC_ADDR_H2, 0);
| > + gma_write16(hw, port, GM_MC_ADDR_H3, 0);
| > + gma_write16(hw, port, GM_MC_ADDR_H4, 0);
|
| can this be done with two 32-bit writes? or writeq?
No that part of the chip seems to only really take 16 bit
accesses, and the multicast address parts are not contiguous.
| > +
| > + /* set LED Function Control register */
| > + gm_phy_write(hw, port, PHY_MARV_PHY_CTRL,
| > + (PHY_M_LEDC_LOS_CTRL(1) | /* LINK/ACT */
| > + PHY_M_LEDC_INIT_CTRL(7) | /* 10 Mbps */
| > + PHY_M_LEDC_STA1_CTRL(7) | /* 100 Mbps */
| > + PHY_M_LEDC_STA0_CTRL(7))); /* 1000
Mbps */
|
| are you enabling the -possibility- of turning on the LEDs, or actually
| turning on all these LEDs?
Not sure really, and don't have that flavor of chip to tell.
That piece copied from sk98lin.
| > +static inline void sky2_rx_add(struct sky2_port *sky2, dma_addr_t map, u16
len)
| > +{
| > + struct sky2_rx_le *le;
| > +
| > + if (sizeof(map) > sizeof(u32)) {
| > + le = sky2_next_rx(sky2);
| > + le->rx.addr = cpu_to_le32((u64) map >> 32);
|
| use (map >> 16) >> 16
Does it matter? because the map will be a 64 bit value
if we ever get to that part of the code anyway. On 32bit
address systems this code disappears.
| > +
| > + paddr = pci_map_single(sky2->hw->pdev, re->skb->data,
| > + rx_buf_size, PCI_DMA_FROMDEVICE);
| > +
| > + pci_unmap_len_set(re, maplen, rx_buf_size);
| > + pci_unmap_addr_set(re, mapaddr, paddr);
|
| pci_unmap???
This is book keeping for iommu systems. see other drivers.
| > +
| > +/*
| > + * Worst case number of list elements is 36
| > + * TSO + CHKSUM + ADDR64 + BUFFER + (ADDR+BUFFER)*MAXFRAGS
| > + */
| > +#define MAX_SKB_TX_LE (4 + 2*MAX_SKB_FRAGS)
| > +
| > +static inline int sky2_xmit_avail(const struct sky2_port *sky2)
| > +{
| > + return (sky2->tx_cons > sky2->tx_prod ? 0 : TX_RING_SIZE)
| > + + sky2->tx_cons - sky2->tx_prod - 1;
| > +}
|
| this seems terribly convoluted and fragile. can't you simplify things?
| Look at some other drivers for examples.
It is how e1000 does it, but will be reworking it to be
more like tg3 with variable ring size.
| > +
| > + /* Handle TCP checksum offload */
| > + ctrl = 0;
| > + if (skb->ip_summed == CHECKSUM_HW) {
| > + ptrdiff_t hdr = skb->h.raw - skb->data;
| > +
| > + ctrl = CALSUM | WR_SUM | INIT_SUM | LOCK_SUM;
| > + if (skb->nh.iph->protocol == IPPROTO_UDP)
| > + ctrl |= UDPTCP;
|
| is this bit set only for UDP?
It appears so from sk98lin driver, still needs testing.
| > + goto err_out_free_hw;
| > + }
| > +
| > + err = request_irq(pdev->irq, sky2_intr, SA_SHIRQ, DRV_NAME, hw);
| > + if (err) {
| > + printk(KERN_ERR PFX "%s: cannot assign irq %d\n",
| > + pci_name(pdev), pdev->irq);
| > + goto err_out_iounmap;
| > + }
|
| don't do this in probe, do it in dev->open(). reading your interrupt
| handling code you are OBVIOUSLY not ready to handle interrupts at this
| point.
Since this driver has to support dual port boards, it
gets wierd. I would rather just change to mask of irq's in HW
then get it at probe.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html