DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 84C71214C5
Subject: Re: [PATCH 03/19] wilc: add host_interface.h
To:     Johannes Berg <johannes@sipsolutions.net>,
        <linux-wireless@vger.kernel.org>
CC:     <kvalo@codeaurora.org>, <gregkh@linuxfoundation.org>,
        <ganesh.krishna@microchip.com>, <aditya.shankar@microchip.com>,
        <venkateswara.kaja@microchip.com>, <claudiu.beznea@microchip.com>,
        <adham.abozaeid@microchip.com>
References: <1537957525-11467-1-git-send-email-ajay.kathat@microchip.com>
 <1537957525-11467-4-git-send-email-ajay.kathat@microchip.com>
 <1539008417.3687.57.camel@sipsolutions.net>
 <f4ab9830-7892-a062-48c4-5c5c64b5caa0@microchip.com>
 <1539081379.3687.112.camel@sipsolutions.net>
From:   Ajay Singh <ajay.kathat@microchip.com>
Message-ID: <1d77cb4d-92c9-0ea4-bdd3-f16a2421406f@microchip.com>
Date:   Tue, 9 Oct 2018 17:14:23 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <1539081379.3687.112.camel@sipsolutions.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Received-SPF: None (protection.outlook.com: microchip.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2018 11:44:43.1762 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 686398bb-0e22-4e67-992e-08d62ddc9cf1
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2570
X-OriginatorOrg: microchip.com
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-wireless.vger.kernel.org>
X-Mailing-List: linux-wireless@vger.kernel.org


On 10/9/2018 4:06 PM, Johannes Berg wrote:
> On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
>
>>>> +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
>>>> +typedef void (*wilc_remain_on_chan_ready)(void *);
>> I think as per coding style the typedef for function pointer are allowed.
> True, I guess, but why do you need them?

Actually these function pointer are used in multiple places i.e inside
the struct and also for passing as the argument for the function. So i
think its better to keep them as typedef to simplify and avoid any 'line
over 80 chars' checkpatch issue. But anyway if you suggest we can modify
to remove these typedefs .

>>>> +struct rcvd_net_info {
>>>> +	u8 *buffer;
>>>> +	u32 len;
>>>> +};
>>>> +
>>>> +struct hidden_net_info {
>>>> +	u8  *ssid;
>>>> +	u8 ssid_len;
>>>> +};
>>>> +
>>>> +struct hidden_network {
>>>> +	struct hidden_net_info *net_info;
>>>> +	u8 n_ssids;
>>>> +};
>>> This seems really odd - what part doesn't cfg80211 already handle?
>> If I understood your question correctly,  you meant what extra
>> functionality 'hidden_network' struct is providing.
> Pretty much. It seems like you're trying to handle hidden SSIDs in some
> way, but ... that's odd.
>
>> Actually this structure is just used to keeps list of SSID's requested
>> in cfg80211 'scan' callback which is passed to firmware. The values are
>> extracted from 'cfg80211_scan_request[struct cfg80211_ssid *ssids 
>> -----  int n_ssids] received during scan.
> So then this has nothing to do with hidden SSID?

Yes, its not related to hidden SSID. Suppose cfg80211 scan is called
with SSID information(active scan) then SSID info will be maintained in
this structure.

Regards,
Ajay