From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5EF49C4345F for ; Mon, 15 Apr 2024 13:59:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ParR8sMJro1OyN4hG83QxZJB4021UlVnsYsSURdBhKc=; b=4ziAsRfyLGxtd8ehSqawMZ86NE k/rmI688XuL/SgMx2UMBDdOWxIrRpmxZ2bDURCh2rf+Qss2Hu64j+EZAclviIv6CqsMFxw6IYlvQe t1603BVcseRFzuPdYZT/sMLPf6kcMV8UsdA0W+liUTTJlpG61ix3Xfodww28KXSWmJzKNgcb19ttD 6HK5VEItQOJodt7UDKxgZp+SYrx2rIgkCYEGn/pjRQPUQmDBK6NX5sIrCH4xBkn7fEdJgWCYh+kyh jwv0pTbNmwPDuSCAYON2OGbtuk7JUAgR1VILitxiglaaABOw9Xz3d/NYFLY0DmzcrN1/azE9e0uMO eV9ZhGeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rwMrf-00000008bfI-0SNL for ath12k@archiver.kernel.org; Mon, 15 Apr 2024 13:59:19 +0000 Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.183]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rwMrb-00000008beg-3hV1 for ath12k@lists.infradead.org; Mon, 15 Apr 2024 13:59:17 +0000 X-Virus-Scanned: Proofpoint Essentials engine Received: from mail3.candelatech.com (mail2.candelatech.com [208.74.158.173]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 2160C6C0083; Mon, 15 Apr 2024 13:59:12 +0000 (UTC) Received: from [192.168.1.23] (unknown [98.97.34.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail3.candelatech.com (Postfix) with ESMTPSA id 1A8C713C2B0; Mon, 15 Apr 2024 06:59:10 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.candelatech.com 1A8C713C2B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=candelatech.com; s=default; t=1713189550; bh=dYGBAYVMcyF9m+bXfaVqlfW+2TEu/zOy8GIbiXDkQwc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fa6i1thD1sD0mp9OhKWv1W4KG0L8J9K/3yfDkv+36F3iDFMJFaftOnmEeM9keCQv3 Y/p1ZoCo386FUtS1dHodnCOoJPAeoR8i+JVwXfkNNBI9PbeB6zpcWJFTqnZ2DsHE7h Yc/l/BZFEFs14VHWq80lmVQ6vKSLcJjJugTub8K8= Message-ID: <5d689308-8104-406d-87b4-5f2ffe836d94@candelatech.com> Date: Mon, 15 Apr 2024 06:59:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/13] wifi: cfg80211: Add provision to advertise multiple radio in one wiphy Content-Language: en-MW To: Vasanthakumar Thiagarajan , Johannes Berg , Karthikeyan Periyasamy , ath12k@lists.infradead.org Cc: linux-wireless@vger.kernel.org References: <20240328072916.1164195-1-quic_periyasa@quicinc.com> <20240328072916.1164195-2-quic_periyasa@quicinc.com> <033185b0-f878-a50b-d0d9-57fa79439bdf@quicinc.com> <80fe5786-f764-455d-ac44-22adf7aeaf94@candelatech.com> <31f30c0e318904f3a082c7f213576ceb1f407141.camel@sipsolutions.net> <20b56e52-a5e2-70cd-a62a-8c4a3526c2cf@candelatech.com> <614bb8a8f1d9174ad7d87cf7636f657cda7b1ef9.camel@sipsolutions.net> <72f491f8-dd3a-0c9e-7490-4d51c86f2102@candelatech.com> <87de72e9-1d3b-b401-a712-9fe8734515b6@candelatech.com> <31aa6b18-8ca4-e4ce-f693-e818fc7e6932@quicinc.com> <54807acb-b7dc-851e-27ce-49e09df5e1e4@candelatech.com> From: Ben Greear Organization: Candela Technologies In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-MDID: 1713189553-fTbtfkeRA3Br X-MDID-O: us5;at1;1713189553;fTbtfkeRA3Br;;e45dbe21c4fc86b950914d8831baea70 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240415_065916_012043_DCD3EA85 X-CRM114-Status: GOOD ( 27.81 ) X-BeenThere: ath12k@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "ath12k" Errors-To: ath12k-bounces+ath12k=archiver.kernel.org@lists.infradead.org On 4/14/24 09:02, Vasanthakumar Thiagarajan wrote: > > > On 4/13/2024 9:10 PM, Ben Greear wrote: >> On 4/12/24 08:58, Ben Greear wrote: >>> On 4/12/24 07:31, Vasanthakumar Thiagarajan wrote: >> >>>> As said, please feel free to propose an alternate solution to address the issue. >>> >>> I do not know the particulars of your driver or driver's needs, but at high level: >>> >>> *  Leave existing wiphy mapping as is. >>> *  Allow adding new combined wiphy(s) on top of groups of underlying physical wiphys. Sort of >>>     like bridges on top of Eth ports. >>> *  The combined wiphy would report underlying wiphy's capabilities (for instance, a combined wiphy on top of >>>     3 single band phys would report itself as tri-band). >>> *  The combined wiphy would add new netlink field listing of its underlying wiphys. User-space wanting to control the combined >>>     wiphy would generally configure the underlying phys (to set 2.4g channel to 6, you'd set the underlying 2.4g >>>     wiphy to channel 6) >>> *  This should require very minimal changes to user space, except of course for new code to actually utilize >>>     the new combined wiphy. >>> *  MLO links and any other logic that needs the combined view would live on the combined wiphy (I understand >>>     from Johannes' comments this is a needed feature.) >>> *  Or user can ignore that combined wiphy entirely and directly use underlying wiphys like we use them currently >>>     for sniffers, stations, aps, combinations thereof. >>> *  Advanced use case could allow combined wiphy to use subset of underlying radios (add combined wiphy on 2.4 and 5g, use 6g for >>>     dedicated mesh backhaul/whatever). >>> *  Interesting logic would be needed to deal with constraints to properly share the underlying resources (you could not >>>     add 16 ap bssid to 2.4 wiphy and also add 16 other ones to the combined wiphy that also uses 2.4 radio most likely, >>>     for instance).  But I think that logic has to be written >>>     either way and is not overly worse with this approach. >> >> I had some further thoughts on this approach: >> >> *  If someone has 2 QCA radio cards, and each radio card has 3 phys, would it be possible to have a 6-link MLO >>     setup? >> > > As long as supported frequencies of the radios are not overlapping , it is technically possible to register 6 radios under one wiphy Couldn't you have MLO links where one is on 5ghz channel 36 and second is on 5ghz channel 149? Underlying radios could support entire 5ghz band, but would use non-overlapping channels. > >> *  Could two be200 be combined into a multi-channel concurrent MLO setup with this approach? >> > > By nature, MLO device is multi-channel concurrent. Not quite sure about the > be200 capability. be200 is eMLSR, I'm wondering if two be200 could be combined to make an STR MLMR link. > >> >> *  For multi-phy arrangements like QCA ath12k and MTK7996, I think the default configuration when the driver >>     loads should just be the physical phys by themselves (as mt7996, at least, does it now).  This would be fully backwards compatible with >>     current user-space and operation. > > There can be configuration knobs in the driver to register it differently... This is where I'd like to dynamically create them in user-space. > >  But the phys would have netlink attributes that >> lets user-space >>     know combined phys (cphys?) can be created on top of them.  User-space that knows about MLO can then >>     create the cphy(s) as wanted and build sta/vap/whatever on top of the cphys. >> > > Not quite positive on the combined_phy+legacy_phy design as mentioned in the previous mail. > >> *  For radios like be200 that are already designed to show a single phy to userspace, they would not >>     need any significant change. > > As mentioned, it is not lot of changes in hostapd/wpa_s. We'll post them once kernel > part is concluded. Thanks, Ben > > Vasanth > -- Ben Greear Candela Technologies Inc http://www.candelatech.com