linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
	george0505 <george0505@realtek.com>,
	'Zhaoming_Li' <chaoming_li@realsil.com.cn>
Subject: Re: [RFC/RFT 1/8] rtlwifi: Prepare core for addition of USB driver
Date: Thu, 03 Feb 2011 22:16:18 -0600	[thread overview]
Message-ID: <4D4B7D92.7000402@lwfinger.net> (raw)
In-Reply-To: <20110203102552.GB3516@redhat.com>

Stanislaw,

Thank you for the thorough review. As noted below, I have some questions:

On 02/03/2011 04:25 AM, Stanislaw Gruszka wrote:

>> +static int _usbctrl_vendorreq_async_write(struct usb_device *udev, u8 request,
>> +					  u16 value, u16 index, void *pdata,
>> +					  u16 len, u8 requesttype)
>> +{
>> +	int rc;
>> +	unsigned int pipe;
>> +	u8 reqtype;
>> +	struct usb_ctrlrequest *dr;
>> +	struct urb *urb;
>> +	struct rtl819x_async_write_data {
>> +		u8 data[REALTEK_USB_VENQT_MAX_BUF_SIZE];
>> +		struct usb_ctrlrequest dr;
>> +	} *buf;
>> +
>> +	if (requesttype == VENDOR_READ) {
>> +		pipe = usb_rcvctrlpipe(udev, 0); /* read_in */
>> +		reqtype =  REALTEK_USB_VENQT_READ;
> This is not needed, or function should be named differently not _async_write.

This one I do not understand. The function does do an asynchronous write. Please
explain.

>> +	wvalue = (u16)(addr&0x0000ffff);
>> +	_usbctrl_vendorreq_sync(udev, request, wvalue, index, data, len,
>> +				requesttype);
>> +	ret = (le32_to_cpu(*data) & (0xffffffff >> ((4 - len) * 8)));
> Ok, BYTEMASK can be used, but what mean this magic? 

As the output of this routine is always cast with (u8) when len is 1 and (u16)
when len is 2, I think the magic can just disappear and ret can simply be

	ret = le32_to_cpu(*data);

I will test and have contacted the original author. There is similar magic in
_usb_write_async() that can also disappear.

>> +
>> +	 /* IBSS */
>> +	 mac->beacon_interval = 100;
>> +
>> +	 /* AMPDU */
>> +	 mac->min_space_cfg = 0;
>> +	 mac->max_mss_density = 0;
> Spaces.

Please explain what you mean by "spaces".

>> +static void _rtl_usb_rx_process(struct ieee80211_hw *hw, struct sk_buff *skb,
>> +				bool brxagg)
> Hungarian notation is prohibited in coding style, for me is
> pretty ok for structure fields, but not for local variables.
> 
>> +{
>> +	struct rtl_priv *rtlpriv = rtl_priv(hw);
>> +	u8 *rxdesc = skb->data;
>> +	struct ieee80211_hdr *hdr;
>> +	bool unicast = false;
>> +	u16 fc;
>> +	struct ieee80211_rx_status rx_status = {0};
>> +	struct rtl_stats stats = {
>> +		.signal = 0,
>> +		.noise = -98,
>> +		.rate = 0,
>> +	};
>> +
>> +	skb_pull(skb, RTL_RX_DESC_SIZE);
>> +	rtlpriv->cfg->ops->query_rx_desc(hw, &stats, &rx_status, rxdesc, skb);
>> +	skb_pull(skb, (stats.rx_drvinfo_size + stats.rx_bufshift));
>> +	hdr = (struct ieee80211_hdr *)(skb->data);
>> +	fc = le16_to_cpu(hdr->frame_control);
>> +	if (!stats.b_crc) {
> Is caller with brxagg == false prepared for stats.b_crc != 0 ?

As far as I can tell, the answer is yes, but will keep your question in mind.

>> +		memcpy(IEEE80211_SKB_RXCB(skb), &rx_status, sizeof(rx_status));
>> +
>> +		if (is_broadcast_ether_addr(hdr->addr1)) {
>> +			/*TODO*/;
>> +		} else if (is_multicast_ether_addr(hdr->addr1)) {
>> +			/*TODO*/
>> +		} else {
>> +			unicast = true;
>> +			rtlpriv->stats.rxbytesunicast +=  skb->len;
>> +		}
>> +
>> +		rtl_is_special_data(hw, skb, false);
>> +
>> +		if (ieee80211_is_data(fc)) {
>> +			rtlpriv->cfg->ops->led_control(hw, LED_CTL_RX);
>> +
>> +			if (unicast)
>> +				rtlpriv->link_info.num_rx_inperiod++;
>> +		}
>> +		if (!brxagg) {
>> +			if (likely(rtl_action_proc(hw, skb, false))) {
>> +				struct sk_buff *uskb = NULL;
>> +				u8 *pdata;
>> +
>> +				uskb = dev_alloc_skb(skb->len + 128);
>> +				memcpy(IEEE80211_SKB_RXCB(uskb), &rx_status,
>> +				       sizeof(rx_status));
>> +				pdata = (u8 *)skb_put(uskb, skb->len);
>> +				memcpy(pdata, skb->data, skb->len);
>> +				dev_kfree_skb_any(skb);
>> +				ieee80211_rx_irqsafe(hw, uskb);
>> +			} else {
>> +				dev_kfree_skb_any(skb);
>> +			}
> Instead of using rxagg argument, this probably should be done in separate
> function.

Good suggestion. I will do that.

>> +		}
>> +	}
>> +}
>> +
>> +static void _rtl_rx_pre_process(struct ieee80211_hw *hw, struct sk_buff *skb)
>> +{
>> +	struct sk_buff *_skb;
>> +	struct sk_buff_head rx_queue;
>> +	struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
>> +
>> +	skb_queue_head_init(&rx_queue);
>> +	rtlusb->usb_rx_segregate_hdl(hw, skb, &rx_queue);
> usb_rx_segregate_hdl is NULL ...

A check has been added. A future USB-based driver may not impose that condition.
> 
>> +static void _rtl_rx_completed(struct urb *_urb)
>> +{
>> +	struct sk_buff *skb = (struct sk_buff *)_urb->context;
>> +	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
>> +	struct rtl_usb *rtlusb = (struct rtl_usb *)info->rate_driver_data[0];
>> +	struct ieee80211_hw *hw = usb_get_intfdata(rtlusb->intf);
>> +	struct rtl_priv *rtlpriv = rtl_priv(hw);
>> +	int err = 0;
>> +
>> +	/* TODO: check */
>> +	if (unlikely(IS_USB_STOP(rtlusb)))
>> +		goto free;
>> +
>> +	if (likely(0 == _urb->status)) {
>> +		/* TODO: Move these code to work queue to improve CPU
>> +		 * utilization!  NOTE: We shall allocate another skb
>> +		 * and reuse the original one.
>> +		 */
>> +		skb_put(skb, _urb->actual_length);
>> +
>> +		if (likely(!rtlusb->usb_rx_segregate_hdl)) {
> ... and we check against that

All other suggestions have been adopted.

Thanks again,

Larry

  reply	other threads:[~2011-02-04  4:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-30 18:11 [RFC/RFT 0/8] rtl8192cu: Initial upload for comments Larry.Finger
2011-01-30 18:11 ` [RFC/RFT 1/8] rtlwifi: Prepare core for addition of USB driver Larry.Finger
2011-01-30 18:32   ` Hauke Mehrtens
2011-01-30 19:31     ` Larry Finger
2011-02-03 10:25   ` Stanislaw Gruszka
2011-02-04  4:16     ` Larry Finger [this message]
2011-02-04  6:29       ` Stanislaw Gruszka
2011-01-30 18:11 ` [RFC/RFT 2/8] rtl8192cu: Add new driver code - Part 1 Larry.Finger
2011-02-03 10:29   ` Stanislaw Gruszka
2011-01-30 18:11 ` [RFC/RFT 3/8] rtl8192cu: Add new driver code - Part 2 Larry.Finger
2011-02-03 11:28   ` Stanislaw Gruszka
2011-02-03 16:06     ` Larry Finger
2011-01-30 18:11 ` [RFC/RFT 4/8] rtl8192cu: Add new driver code - Part 3 Larry.Finger
2011-01-30 18:11 ` [RFC/RFT 5/8] rtl8192cu: Add new driver code - Part 4 Larry.Finger
2011-01-30 18:11 ` [RFC/RFT 6/8] rtl8192cu: Add new driver code - Part 5 Larry.Finger
2011-01-30 18:11 ` [RFC/RFT 7/8] rtl8192cu: Add new driver code - Part 6 Larry.Finger
2011-01-30 18:11 ` [RFC/RFT 8/8] rtl8192cu: Add new driver code - Part 7 Larry.Finger

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=4D4B7D92.7000402@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=chaoming_li@realsil.com.cn \
    --cc=george0505@realtek.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=sgruszka@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).