Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04566C64EBC for ; Thu, 4 Oct 2018 13:42:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C5FB120652 for ; Thu, 4 Oct 2018 13:42:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C5FB120652 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727336AbeJDUgQ (ORCPT ); Thu, 4 Oct 2018 16:36:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26616 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727264AbeJDUgQ (ORCPT ); Thu, 4 Oct 2018 16:36:16 -0400 Received: from smtp.corp.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4260886668; Thu, 4 Oct 2018 13:42:55 +0000 (UTC) Received: from localhost (unknown [10.43.2.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id D6C769E7C7; Thu, 4 Oct 2018 13:42:54 +0000 (UTC) Date: Thu, 4 Oct 2018 15:42:53 +0200 From: Stanislaw Gruszka To: Kalle Valo Cc: Larry Finger , Tony Chuang , "linux-wireless@vger.kernel.org" , Pkshih , Andy Huang Subject: Re: [PATCH 01/12] rtwlan: main files Message-ID: <20181004134252.GA20484@redhat.com> References: <1537509847-21087-2-git-send-email-yhchuang@realtek.com> <20180927135040.GA4712@redhat.com> <20180928092918.GC8323@redhat.com> <20181002102957.GB25116@redhat.com> <4b50e06f-2fd0-9378-d283-1ca6d02f9586@lwfinger.net> <87k1mx28dg.fsf@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k1mx28dg.fsf@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 04 Oct 2018 13:42:55 +0000 (UTC) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Thu, Oct 04, 2018 at 03:39:55PM +0300, Kalle Valo wrote: > >> Can we put the configuration file in the firmware directory? > >> Should we package them into binary files? Or just put the raw data. > >> > >> We can test the performance for it. After we got the result, we will make a decision > >> about it. And if we decide to put them in the firmware directory, will send a patch. > >> For now, I think we can just leave them in the .c. > > > > Yes, you could put the configuration files in the firmware directory. > > I would put them in binary form, not as text files. That way the size > > would be smaller, and it would not be possible to alter them, > > particularly if the binary file is checksummed. > > > > It would likely be OK if only the agc table was stored in this way. > > That would take away about half of the lines in the 8822b table file. > > So what's the worry here? The lines of source code, binary size or what? > > .../net/wireless/realtek/rtw88/rtw8822b_table.c | 20783 +++++++++++++++++++ > > Looking at the diffstat rtw8822b_table.c seems to be 20 kLOC, IMHO it's > not that bad as it's just data. But of course I might be missing > something as I haven't checked patches yet. My concern was it's plenty of redundant data, for example: 0x81C, 0xFF000003, 0x81C, 0xFE000003, 0x81C, 0xFD020003, 0x81C, 0xFC040003, 0x81C, 0xFB060003, 0x81C, 0xFA080003, 0x81C, 0xF90A0003, 0x81C, 0xF80C0003, 0x81C, 0xF70E0003, 0x81C, 0xF6100003, Approx 10000 lines like this, braked by lines like this 0x90000012, 0x00000000, 0x40000000, 0x00000000, in more or less regular way. Not big deal, but perhaps this could be coded in much more compact way. Regards Stanislaw