cxgb3 driver update

PATCH In review Divy Le Ray 2 participants 3 messages Aug 23, 2007

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

Al Viro

2007-08-23 07:02 UTC #1 lore raw

Review

Quoted 10 lines · Divy Le Ray

Hi Jeff,
I'm submitting three more patches for inclusion in netdev#upstream. These patches are built over the series I resent yesterday night. The patch numbering reflects the stacking.
Here is a brief description:
(quoted diff) +0 -3
-   avoid false positives in the xgmac hang workaround
-   Properly set the CQ_ERR bit in RDMA CQ contexts.
-   Update CQ context operations time out values

Speaking of cxgb3, could you explain what the hell is static int do_term(struct t3cdev *dev, struct sk_buff *skb)

{
        unsigned int hwtid = ntohl(skb->priority) >> 8 & 0xfffff;

doing? AFAIK, skb->priority is not net-endian...

Another odd place is
int t3_seeprom_write(struct adapter *adapter, u32 addr, u32 data)

{   
        u16 val;
        int attempts = EEPROM_MAX_POLL;
        unsigned int base = adapter->params.pci.vpd_cap_addr;

        if ((addr >= EEPROMSIZE && addr != EEPROM_STAT_ADDR) || (addr & 3))   
                return -EINVAL;

        pci_write_config_dword(adapter->pdev, base + PCI_VPD_DATA,
                               cpu_to_le32(data));
with callers like
int t3_seeprom_wp(struct adapter *adapter, int enable)
{
        return t3_seeprom_write(adapter, EEPROM_STAT_ADDR, enable ? 0xc : 0);

IOW, you really get little-endian values passed to pci_write_config_dword() and it expects a host-endian as the last argument...

Divy Le Ray

author

2007-08-23 22:03 UTC #2 lore raw

Hi Al,

Quoted 6 lines

Speaking of cxgb3, could you explain what the hell is static int do_term(struct t3cdev *dev, struct sk_buff *skb)
{
        unsigned int hwtid = ntohl(skb->priority) >> 8 & 0xfffff;
doing? AFAIK, skb->priority is not net-endian...

the RDMA connection id is saved in the skb's priority field for TERM messages because it is not in the CPL message that comes up from the hardware. Yet the RDMA driver needs it, so sge.c::process_responses() overloads the skb's priority and csum with these values.

Quoted 14 lines

Another odd place is
int t3_seeprom_write(struct adapter *adapter, u32 addr, u32 data)

{  
        u16 val;
        int attempts = EEPROM_MAX_POLL;
        unsigned int base = adapter->params.pci.vpd_cap_addr;

        if ((addr >= EEPROMSIZE && addr != EEPROM_STAT_ADDR) || (addr 
& 3))  
                return -EINVAL;

        pci_write_config_dword(adapter->pdev, base + PCI_VPD_DATA,
                               cpu_to_le32(data));

Quoted 9 lines

with callers like
int t3_seeprom_wp(struct adapter *adapter, int enable)
{
return t3_seeprom_write(adapter, EEPROM_STAT_ADDR, enable ?
0xc : 0);
IOW, you really get little-endian values passed to pci_write_config_dword() and it expects a host-endian as the last argument...

It looks like a bug. Thanks for spotting this.

Cheers,
Divy