All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, nguyendo@us.ibm.com, formosa@us.ibm.com,
	jallen@linux.vnet.ibm.com, brking@linux.vnet.ibm.com,
	nfont@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH net-next v2] Driver for IBM System i/p VNIC protocol
Date: Mon, 14 Dec 2015 12:05:10 -0600	[thread overview]
Message-ID: <566F04D6.3030007@linux.vnet.ibm.com> (raw)
In-Reply-To: <20151211.195358.1764064794354600517.davem@davemloft.net>

On 12/11/2015 06:53 PM, David Miller wrote:
> From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> Date: Tue,  8 Dec 2015 11:52:19 -0600
>
>> +static long h_reg_sub_crq(unsigned long unit_address, unsigned long token,
>> +			  unsigned long length, unsigned long *number,
>> +			  unsigned long *irq)
>> +{
>> +	long rc;
>> +	unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
> Please declare local variables from longest to shortest line, otherwise
> known as "reverse christmas tree" order.
>
> Audit this in your entire driver.
>
>> +	pool->rx_buff = kcalloc(pool->size, sizeof(struct ibmvnic_rx_buff),
>> +				GFP_KERNEL);
> Allocation failures not checked until much later in this function, where
> several other resources have been allocated meanwhile.  That doesn't
> make any sense at all.
>
>> +	adapter->closing = 1;
> Please use type 'bool' and values 'true' and 'false' for boolean
> values.
>
> Audit this in your entire driver.
>
>> +	if (ip_hdr(skb)->version == 4)
>> +		tx_crq.v1.flags1 |= IBMVNIC_TX_PROT_IPV4;
>> +	else if (ip_hdr(skb)->version == 6)
>> +		tx_crq.v1.flags1 |= IBMVNIC_TX_PROT_IPV6;
>> +
> You cannot dereference the protocol header of the SKB without
> first checking the skb->protocol value, otherwise you're looking
> at garbage.
>
>> +static int ibmvnic_set_mac(struct net_device *netdev, void *p)
>> +{
>> +	struct ibmvnic_adapter *adapter = netdev_priv(netdev);
>> +	struct sockaddr *addr = p;
>> +	union ibmvnic_crq crq;
>> +
>> +	if (!is_valid_ether_addr(addr->sa_data))
>> +		return -EADDRNOTAVAIL;
>> +
>> +	memset(&crq, 0, sizeof(crq));
>> +	crq.change_mac_addr.first = IBMVNIC_CRQ_CMD;
>> +	crq.change_mac_addr.cmd = CHANGE_MAC_ADDR;
>> +	ether_addr_copy(&crq.change_mac_addr.mac_addr[0], addr->sa_data);
>> +	ibmvnic_send_crq(adapter, &crq);
>> +
>> +	return 0;
>> +}
> You are responsible for copying the new MAC address into dev->dev_addr
> on success.

We do this in another function (handle_change_mac_rsp), which handles the response from firmware indicating whether the CHANGE_MAC_ADDR command was successful.  Is this acceptable? 

Thank you for your review comments and your time.

>
>> +static int ibmvnic_mii_ioctl(struct net_device *netdev, struct ifreq *ifr,
>> +			     int cmd)
>> +{
>  ...
>> +	return 0;
>> +}
>> +
>> +static int ibmvnic_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
>> +{
>> +	switch (cmd) {
>> +	case SIOCGMIIPHY:
>> +	case SIOCGMIIREG:
>> +	case SIOCSMIIREG:
>> +		return ibmvnic_mii_ioctl(netdev, ifr, cmd);
>> +	default:
>> +		return -EOPNOTSUPP;
>> +	}
>> +}
> This really doesn't make any sense.  Please just delete this.  You
> don't support MII reads or writes because they logically don't make
> sense on this device.
>
>> +static struct net_device_stats *ibmvnic_get_stats(struct net_device *dev)
>> +{
>> +	struct ibmvnic_adapter *adapter = netdev_priv(dev);
>> +
>> +	/* only return the current stats */
>> +	return &adapter->net_stats;
>> +}
> The default method does this for you as long as you properly use
> net_device's embedded stats, therefore you don't need to provide this
> at all.
>
> That's all I have any energy for, and as you can see nobody else wants
> to even try to review this driver.
>
> It's going to take a lot of respins and time before this driver is
> ready for upstream inclusion.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

      reply	other threads:[~2015-12-14 18:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 17:52 [PATCH net-next v2] Driver for IBM System i/p VNIC protocol Thomas Falcon
2015-12-12  0:53 ` David Miller
2015-12-14 18:05   ` Thomas Falcon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566F04D6.3030007@linux.vnet.ibm.com \
    --to=tlfalcon@linux.vnet.ibm.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=davem@davemloft.net \
    --cc=formosa@us.ibm.com \
    --cc=jallen@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=nguyendo@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.