linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: yhchuang@realtek.com
Cc: kvalo@codeaurora.org, Larry.Finger@lwfinger.net,
	pkshih@realtek.com, tehuang@realtek.com,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC v2 03/12] rtw88: hci files
Date: Thu, 4 Oct 2018 15:02:13 +0200	[thread overview]
Message-ID: <20181004130212.GC16819@redhat.com> (raw)
In-Reply-To: <1538553748-26364-4-git-send-email-yhchuang@realtek.com>

On Wed, Oct 03, 2018 at 04:02:19PM +0800, yhchuang@realtek.com wrote:
> +static inline u32
> +rtw_read_rf(struct rtw_dev *rtwdev, enum rtw_rf_path rf_path,
> +	    u32 addr, u32 mask)
> +{
> +	unsigned long flags;
> +	u32 val;
> +
> +	spin_lock_irqsave(&rtwdev->rf_lock, flags);
> +	val = rtwdev->chip->ops->read_rf(rtwdev, rf_path, addr, mask);
> +	spin_unlock_irqrestore(&rtwdev->rf_lock, flags);

What for is rtwdev->rf_lock lock ? Is possible to call
rtw_read_rf() or rtw_write_rf() in some simultanious way ?

> +static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb,
> +				 struct rtw_pci_rx_ring *rx_ring,
> +				 u32 idx, u32 desc_sz)
> +{
> +	struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
> +	struct rtw_pci_rx_buffer_desc *buf_desc;
> +	int buf_sz = RTK_PCI_RX_BUF_SIZE;
> +	dma_addr_t dma;
> +
> +	if (!skb)
> +		return -EINVAL;
Too late, see below.

> +
> +	dma = pci_map_single(pdev, skb->data, buf_sz, PCI_DMA_FROMDEVICE);
> +	if (pci_dma_mapping_error(pdev, dma))
> +		return -EBUSY;
> +
> +	*((dma_addr_t *)skb->cb) = dma;
> +	buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
> +						     idx * desc_sz);
> +	memset(buf_desc, 0, sizeof(*buf_desc));
> +	buf_desc->buf_size = cpu_to_le16(8216);

Why the difference between RTK_PCI_RX_BUF_SIZE = 9100 and this 8216 ? 

> +static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev,
> +				struct rtw_pci_rx_ring *rx_ring,
> +				u8 desc_size, u32 len)
> +{
> +	struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
> +	struct sk_buff *skb = NULL;
> +	dma_addr_t dma;
> +	u8 *head;
> +	int ring_sz = desc_size * len;
> +	int buf_sz = RTK_PCI_RX_BUF_SIZE;
> +	int i, allocated;
> +	int ret = 0;
> +
> +	head = pci_zalloc_consistent(pdev, ring_sz, &dma);
> +	if (!head) {
> +		rtw_err(rtwdev, "failed to allocate rx ring\n");
> +		return -ENOMEM;
> +	}
> +	rx_ring->r.head = head;
> +
> +	for (i = 0; i < len; i++) {
> +		skb = dev_alloc_skb(buf_sz);
> +		memset(skb->data, 0, buf_sz);
No error check. Also I think you should use different version to 
allow specify GPF_KERNEL flag, this is not atomic context.

> +static void rtw_pci_dma_check(struct rtw_dev *rtwdev,
> +			      struct rtw_pci_rx_ring *rx_ring,
> +			      u32 idx)
> +{
> +	struct rtw_chip_info *chip = rtwdev->chip;
> +	struct rtw_pci_rx_buffer_desc *buf_desc;
> +	u32 desc_sz = chip->rx_buf_desc_sz;
> +	u16 total_pkt_size;
> +	int i;
> +
> +	buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
> +						     idx * desc_sz);
> +	for (i = 0; i < 20; i++) {
> +		total_pkt_size = le16_to_cpu(buf_desc->total_pkt_size);
> +		if (total_pkt_size)
> +			return;
> +	}
> +
> +	if (i >= 20)
> +		rtw_warn(rtwdev, "pci bus timeout, drop packet\n");
This is not right, most likely you need to use
dma_sync_single_for_cpu() .

> +static int rtw_pci_tx(struct rtw_dev *rtwdev,
> +		      struct rtw_tx_pkt_info *pkt_info,
> +		      struct sk_buff *skb)
> +{
> +	struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> +	struct rtw_pci_tx_ring *ring;
> +	u8 queue = rtw_hw_queue_mapping(skb);
> +	int ret;
> +
> +	ret = rtw_pci_xmit(rtwdev, pkt_info, skb, queue);
> +	if (ret)
> +		return ret;
> +
> +	ring = &rtwpci->tx_rings[queue];
> +	if (avail_desc(ring->r.wp, ring->r.rp, ring->r.len) < 2) {
> +		ieee80211_stop_queue(rtwdev->hw, skb_get_queue_mapping(skb));
> +		ring->queue_stopped = true;
I think here is race condition with below code that wakes queue...

> +		if (ring->queue_stopped &&
> +		    avail_desc(ring->r.wp, ring->r.rp, ring->r.len) > 4) {
> +			q_map = skb_get_queue_mapping(skb);
> +			ieee80211_wake_queue(hw, q_map);
> +			ring->queue_stopped = false;

... here. This should be somehow synchronized.
> +		}
> +
> +		info = IEEE80211_SKB_CB(skb);
> +		ieee80211_tx_info_clear_status(info);
> +		info->flags |= IEEE80211_TX_STAT_ACK;
> +		ieee80211_tx_status_irqsafe(hw, skb);

Always report ACK ?
> +
> +static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
> +{
> +	struct rtw_dev *rtwdev = dev;
> +	struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> +	u32 irq_status[4];
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&rtwpci->irq_lock, flags);

flags not needed, interrupts are disabled in IRQ.

> +	rtw_pci_disable_interrupt(rtwdev, rtwpci);

This seems to be not needed as well.

> +static void rtw_pci_init_aspm(struct rtw_dev *rtwdev)
> +{
> +}
Something is missing ;-)

> +static void rtw_dbi_write8(struct rtw_dev *rtwdev, u16 addr, u8 data)
> +{
> +	u16 write_addr;
> +	u16 remainder = addr & 0x3;
> +	u8 flag;
> +	u8 cnt = 20;
> +
> +	write_addr = ((addr & 0x0ffc) | (BIT(0) << (remainder + 12)));
> +	rtw_write8(rtwdev, REG_DBI_WDATA_V1 + remainder, data);
> +	rtw_write16(rtwdev, REG_DBI_FLAG_V1, write_addr);
> +	rtw_write8(rtwdev, REG_DBI_FLAG_V1 + 2, 0x01);
> +
> +	flag = rtw_read8(rtwdev, REG_DBI_FLAG_V1 + 2);
> +	while (flag && (cnt != 0)) {
> +		udelay(10);
> +		flag = rtw_read8(rtwdev, REG_DBI_FLAG_V1 + 2);
> +		cnt--;
> +	}
> +
> +	WARN(flag, "DBI write fail");
We always print WARN, there is other return point in this function.

> +static void rtw_mdio_write(struct rtw_dev *rtwdev, u8 addr, u16 data, bool g1)
<snip>
> +	WARN(wflag, "MDIO write fail");
The same.

> +struct rtw_hci_ops rtw_pci_ops = {
<snip>
> +	.check_avail_desc = rtw_pci_check_avail_desc,
Not used ?

Thanks
Stanislaw
 

  reply	other threads:[~2018-10-04 13:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03  8:02 [RFC v2 00/12] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips yhchuang
2018-10-03  8:02 ` [RFC v2 01/12] rtw88: main files yhchuang
2018-10-03  8:02 ` [RFC v2 02/12] rtw88: core files yhchuang
2018-10-04 11:42   ` Stanislaw Gruszka
2018-10-04 13:52     ` Stanislaw Gruszka
2018-10-08  8:22     ` Tony Chuang
2018-10-03  8:02 ` [RFC v2 03/12] rtw88: hci files yhchuang
2018-10-04 13:02   ` Stanislaw Gruszka [this message]
2018-10-04 13:25     ` Stanislaw Gruszka
2018-10-05 12:07     ` Tony Chuang
2018-10-06 12:29       ` Kalle Valo
2018-10-08  9:03         ` Tony Chuang
2018-10-08  9:34       ` Stanislaw Gruszka
2019-03-25 14:33         ` Brian Norris
2018-10-03  8:02 ` [RFC v2 04/12] rtw88: trx files yhchuang
2018-10-04 13:19   ` Stanislaw Gruszka
2018-10-05  9:20     ` Tony Chuang
2018-10-06 12:32       ` Kalle Valo
2018-10-08  9:19         ` Stanislaw Gruszka
2018-10-08  9:35           ` Tony Chuang
2018-10-08  9:25       ` Stanislaw Gruszka
2018-10-03  8:02 ` [RFC v2 05/12] rtw88: mac files yhchuang
2018-10-03  8:02 ` [RFC v2 06/12] rtw88: fw and efuse files yhchuang
2018-10-04 10:49   ` Stanislaw Gruszka
2018-10-05  9:19     ` Tony Chuang
2018-10-08  9:15       ` Stanislaw Gruszka
2018-10-06 12:34     ` Kalle Valo
2018-10-03  8:02 ` [RFC v2 07/12] rtw88: phy files yhchuang
2018-10-03  8:02 ` [RFC v2 08/12] rtw88: debug files yhchuang
2018-10-03  8:02 ` [RFC v2 09/12] rtw88: chip files yhchuang
2018-10-03  8:02 ` [RFC v2 10/12] rtw88: 8822B init table yhchuang
2018-10-03  8:02 ` [RFC v2 11/12] rtw88: 8822C " yhchuang
2018-10-03  8:02 ` [RFC v2 12/12] rtw88: Kconfig & Makefile yhchuang
2018-10-03 16:15 ` [RFC v2 00/12] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips Sid Hayn
2018-10-03 16:52   ` Larry Finger
2018-10-03 16:57     ` Sid Hayn
2018-10-03 17:38       ` 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=20181004130212.GC16819@redhat.com \
    --to=sgruszka@redhat.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --cc=tehuang@realtek.com \
    --cc=yhchuang@realtek.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).