DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFF43205C9
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 6413C60D3B
From:   Kalle Valo <kvalo@codeaurora.org>
To:     Larry Finger <Larry.Finger@lwfinger.net>
Cc:     Stanislaw Gruszka <sgruszka@redhat.com>,
        Tony Chuang <yhchuang@realtek.com>,
        "linux-wireless\@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        Pkshih <pkshih@realtek.com>, Andy Huang <tehuang@realtek.com>
Subject: Re: [PATCH 01/12] rtwlan: main files
References: <1537509847-21087-1-git-send-email-yhchuang@realtek.com>
        <1537509847-21087-2-git-send-email-yhchuang@realtek.com>
        <20180927135040.GA4712@redhat.com>
        <F7CD281DE3E379468C6D07993EA72F84D08D9F56@RTITMBSVM01.realtek.com.tw>
        <20180928092918.GC8323@redhat.com>
        <F7CD281DE3E379468C6D07993EA72F84D08DB7E3@RTITMBSVM01.realtek.com.tw>
        <20181002102957.GB25116@redhat.com>
        <a54dec4e-1164-f9c5-c791-3396a239eeba@lwfinger.net>
Date:   Thu, 04 Oct 2018 15:35:44 +0300
In-Reply-To: <a54dec4e-1164-f9c5-c791-3396a239eeba@lwfinger.net> (Larry
        Finger's message of "Tue, 2 Oct 2018 10:23:44 -0500")
Message-ID: <87o9c928kf.fsf@codeaurora.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Larry Finger <Larry.Finger@lwfinger.net> writes:

> On 10/2/18 5:29 AM, Stanislaw Gruszka wrote:
>> On Fri, Sep 28, 2018 at 11:32:41AM +0000, Tony Chuang wrote:
>>>> 	if (rtw_hci_tx(rtwdev, &pkt_info, skb))
>>>> 		dev_kfree_skb_any(skb)
>>>>
>>>> just to remove 'return;' and out label.
>>>
>>>
>>> OK, but why not use ieee80211_free_txskb, should it be better for mac80211?
>>
>> Yes, it is better as it also do some extra thing for dropped frame.
>>
>>>>> OK, but I think this is needed, our tables have different forms ....
>>>>
>>>> Not sure if that is better solution, but could the tables be pre-prarsed
>>>> by user-space program and then embed in the driver in ready to send
>>>> to the hardware from ?
>>>>
>>>> Also there are lot of redundancy in those tables, for example:
>>>>
>>>> +	0x81C, 0xFF000003,
>>>> +	0x81C, 0xF5000003,
>>>> +	0x81C, 0xF4020003,
>>>> +	0x81C, 0xF3040003,
>>>> +	0x81C, 0xF2060003,
>>>> +	0x81C, 0xF1080003,
>>>> +	0x81C, 0xF00A0003,
>>>> +	0x81C, 0xEF0C0003,
>>>> +	0x81C, 0xEE0E0003,
>>>> +	0x81C, 0xED100003,
>>>> +	0x81C, 0xEC120003,
>>>> +	0x81C, 0xEB140003,
>>>> +	0x81C, 0xEA160003,
>>>> +	0x81C, 0xE9180003,
>>>> +	0x81C, 0xE81A0003,
>>>> +	0x81C, 0xE71C0003,
>>>> +	0x81C, 0xE61E0003,
>>>> +	0x81C, 0xE5200003,
>>>>
>>>> 0x81C and 0003 repeats in many lines.
>>>>
>>>> This seems to be parse data, not that we have to write 0x81C
>>>> register many times. Would be possible to remove the redundancy?
>>>
>>>
>>> No, they cannot be removed, the sequence matters.
>>> And it is really writing to 0x81C ...
>>> It is really magic, I cannot believe to this, too.
>>
>> This is contradiction for what I asked you before, i.e. doing parsing
>> in user space, but since we have this parsing mechanism in the driver
>> perhaps the tables can be coded in some more compact way, for example:
>>
>> { prefix, suffix, len, {data} }
>>
>> { 0x81C, 0x0003, N ,
>>    { 0xFF02 , 0xF500 , .... , 0xE520 } }
>>
>> The rtw8822b_table.c file is quite big.
>
> You might also consider having these tables as a configuration file
> read from the firmware directory.

Configuration files for upstream drivers is something I would like to
avoid until we have a generic solution. That seems to come up now and
then but there does not seem to be any consensus how it should be
implemented.

-- 
Kalle Valo