All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: yhchuang@realtek.com, kvalo@codeaurora.org
Cc: Larry.Finger@lwfinger.net, pkshih@realtek.com,
	tehuang@realtek.com, sgruszka@redhat.com,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC v3 05/12] rtw88: mac files
Date: Mon, 08 Oct 2018 15:38:54 +0200	[thread overview]
Message-ID: <1539005934.3687.20.camel@sipsolutions.net> (raw)
In-Reply-To: <1538565659-29530-6-git-send-email-yhchuang@realtek.com> (sfid-20181003_132140_785991_2EB9771B)

On Wed, 2018-10-03 at 19:20 +0800, yhchuang@realtek.com wrote:
> 
> +	do {
> +		cnt--;
> +		value = rtw_read8(rtwdev, offset);
> +		value &= cmd->mask;
> +		if (value == (cmd->value & cmd->mask))
> +			return 0;
> +		if (cnt == 0) {
> +			if (rtw_hci_type(rtwdev) == RTW_HCI_TYPE_PCIE &&
> +			    flag == 0) {
> +				value = rtw_read8(rtwdev, REG_SYS_PW_CTRL);
> +				value |= BIT(3);
> +				rtw_write8(rtwdev, REG_SYS_PW_CTRL, value);
> +				value &= ~BIT(3);
> +				rtw_write8(rtwdev, REG_SYS_PW_CTRL, value);

It stands to reason this might need some sort of udelay() inbetween
togging the bit?

> +			value = rtw_read8(rtwdev, offset);
> +			value &= ~cur_cmd->mask;
> +			value |= (cur_cmd->value & cur_cmd->mask);
> +			rtw_write8(rtwdev, offset, value);

You might want to have a helper function/inline for this type of
sequence? Hmm, maybe I'm confusing it - now I can't find where I thought
it was also used elsewhere.

> +static bool check_firmware_size(const u8 *data, u32 size)
> +{
> +	u32 dmem_size;
> +	u32 imem_size;
> +	u32 emem_size;
> +	u32 real_size;
> +
> +	dmem_size = le32_to_cpu(*((__le32 *)(data + FW_HDR_DMEM_SIZE)));
> +	imem_size = le32_to_cpu(*((__le32 *)(data + FW_HDR_IMEM_SIZE)));
> +	emem_size = ((*(data + FW_HDR_MEM_USAGE)) & BIT(4)) ?
> +		    le32_to_cpu(*((__le32 *)(data + FW_HDR_EMEM_SIZE))) : 0;

This dereferencing data as __le32 seems very problematic due to
alignment concerns?

> +static bool ltecoex_read_reg(struct rtw_dev *rtwdev, u16 offset, u32 *val)
> +{
> +	u32 cnt = 10000;
> +
> +	while ((rtw_read8(rtwdev, LTECOEX_ACCESS_CTRL + 3) & BIT(5)) == 0) {
> +		if (cnt-- == 0)
> +			return false;
> +		udelay(50);
> +	}

You have this sort of loop a lot it seems - perhaps make a macro out of
it?

> +	buf = kmalloc(size, GFP_KERNEL);
> +	memcpy(buf, data, size);

kmemdup, but you need an error check too

> +	while (rtw_read32(rtwdev, REG_DDMA_CH0CTRL) & BIT_DDMACH0_OWN) {
> +		cnt--;
> +		if (cnt == 0)
> +			return -EBUSY;
> +	}

Here's another one of the loops, but it probably needs a udelay()?

> +static int iddma_download_firmware(struct rtw_dev *rtwdev, u32 src, u32 dst,
> +				   u32 len, u8 first)
> +{
> +	u32 cnt = DDMA_POLLING_COUNT;
> +	u32 ch0_ctrl = BIT_DDMACH0_CHKSUM_EN | BIT_DDMACH0_OWN;
> +
> +	while (rtw_read32(rtwdev, REG_DDMA_CH0CTRL) & BIT_DDMACH0_OWN) {
> +		cnt--;
> +		if (cnt == 0)
> +			return -EBUSY;
> +	}

and here

> +static void update_firmware_info(struct rtw_dev *rtwdev, const u8 *data)
> +{
> +	struct rtw_fw_state *fw = &rtwdev->fw;
> +
> +	fw->h2c_version =
> +		le16_to_cpu(*((__le16 *)(data + FW_HDR_H2C_FMT_VER)));
> +	fw->version =
> +		le16_to_cpu(*((__le16 *)(data + FW_HDR_VERSION)));

more potential alignment issues

> +start_download_firmware(struct rtw_dev *rtwdev, const u8 *data, u32 size)
> +{
> +	const u8 *cur_fw;
> +	u16 val;
> +	u16 fw_ctrl;
> +	u32 imem_size;
> +	u32 dmem_size;
> +	u32 emem_size;
> +	u32 addr;
> +	int ret;
> +
> +	dmem_size = le32_to_cpu(*((__le32 *)(data + FW_HDR_DMEM_SIZE)));
> +	imem_size = le32_to_cpu(*((__le32 *)(data + FW_HDR_IMEM_SIZE)));
> +	emem_size = ((*(data + FW_HDR_MEM_USAGE)) & BIT(4)) ?
> +		    le32_to_cpu(*((__le32 *)(data + FW_HDR_EMEM_SIZE))) : 0;

same here

> +	cnt = 1000;
> +	while (rtw_read8(rtwdev, REG_AUTO_LLT_V1) & BIT_AUTO_INIT_LLT_V1)
> +		if (cnt-- == 0)
> +			return -EBUSY;

missing udelay again?

johannes


  reply	other threads:[~2018-10-08 13:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03 11:20 [RFC v3 00/12] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips yhchuang
2018-10-03 11:20 ` [RFC v3 01/12] rtw88: main files yhchuang
2018-10-08 14:10   ` Johannes Berg
     [not found]   ` <201810081447.w98ElQfu018110@rtits1.realtek.com.tw>
2018-10-11  7:23     ` Tony Chuang
2018-10-11  7:30       ` Johannes Berg
2018-10-13 17:47       ` Kalle Valo
2018-10-22  3:40         ` Tony Chuang
2018-11-15 14:18           ` Kalle Valo
2018-10-03 11:20 ` [RFC v3 02/12] rtw88: core files yhchuang
2018-10-08 14:12   ` Johannes Berg
2018-10-03 11:20 ` [RFC v3 03/12] rtw88: hci files yhchuang
2018-10-03 11:20 ` [RFC v3 04/12] rtw88: trx files yhchuang
2018-10-03 11:20 ` [RFC v3 05/12] rtw88: mac files yhchuang
2018-10-08 13:38   ` Johannes Berg [this message]
2018-10-03 11:20 ` [RFC v3 06/12] rtw88: fw and efuse files yhchuang
2018-10-03 11:20 ` [RFC v3 07/12] rtw88: phy files yhchuang
2018-10-04 14:10   ` Stanislaw Gruszka
2018-10-08  2:28     ` Tony Chuang
2018-10-03 11:20 ` [RFC v3 08/12] rtw88: debug files yhchuang
2018-10-04 14:23   ` Stanislaw Gruszka
2018-10-08  7:57     ` Tony Chuang
2018-10-08 13:29   ` Johannes Berg
     [not found]   ` <201810081446.w98EkN0r017815@rtits1.realtek.com.tw>
2018-10-09  2:42     ` Tony Chuang
2018-10-03 11:20 ` [RFC v3 09/12] rtw88: chip files yhchuang
2018-10-04 14:36   ` Stanislaw Gruszka
2018-10-08  9:38     ` Tony Chuang
2018-10-03 11:20 ` [RFC v3 10/12] rtw88: 8822B init table yhchuang
2018-10-03 11:20 ` [RFC v3 11/12] rtw88: 8822C " yhchuang
2018-10-03 11:20 ` [RFC v3 12/12] rtw88: Kconfig & Makefile yhchuang
2018-10-08 14:00   ` Johannes Berg
     [not found]   ` <201810081447.w98ElIFH018051@rtits1.realtek.com.tw>
2018-10-09  5:10     ` Tony Chuang

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=1539005934.3687.20.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=Larry.Finger@lwfinger.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --cc=sgruszka@redhat.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.