All of lore.kernel.org
 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 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.