public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed

• * brcmsmac: TX power blocked in BCM4313
         [not found] ` <1424007136.2042747.227726249.45B6A0E2-2RFepEojUI2N1INw9kWLP6GC3tUn3ZHUQQ4Iyu8u01E@public.gmane.org>
  @ 2015-02-16 13:53   ` Nikita N.
         [not found]     ` <54E2107F.4000709@broadcom.com>
    0 siblings, 1 reply; 7+ messages in thread
  From: Nikita N. @ 2015-02-16 13:53 UTC (permalink / raw)
    To: hauke-5/S+JYg5SzeELgA04lAiVw,
  	brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
  	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
  	arend-dY08KVG/lbpWk0Htik3J/w, Kalle Valo, Pat Erley,
  	brudley-dY08KVG/lbpWk0Htik3J/w, Franky Lin,
  	meuleman-dY08KVG/lbpWk0Htik3J/w, linville-2XuSBdqkA4R54TAoqtyWWQ,
  	pieterpg-dY08KVG/lbpWk0Htik3J/w, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
  	wens-jdAy2FN1RRM, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
  	brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
  	netdev-u79uwXL29TY76Z2rM5mHXA,
  	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public•gmane.org
  
  Hi Dear brcmsmac Devs,
  following up my previous email, since I didn't receive any feedback, I
  took the trouble to test my understandings myself.
  First of all, I want to report the following fact: the TX power is
  blocked/fixed to 19dbm, no matter what local regdom or power setting.
  
  If that is an issue or bug or else I leave the decision to you.
  Another fact is that, the Windows driver for that same interface, is
  capable to push the transceiver at least 10 RSSI points higher than
  linux backports brcmsmac driver, which means it is *DO* possible to
  change the TX power.
  In my personal case I want to lower it, but even that is not possible:
  no setting is working, neither changing the regdom (iw reg set) nor the
  power (iwconfig wlan0 txpower, iw dev wlan0 set txpower fixed, iw phy
  wlan0 set txpower fixed).
  
  Now, as for my tests, I just tried to hard-code few values into the
  brcmsmac driver module, only to see if anything changes.
  In details I zeroed the values of all tx_power_offsets in the table
  populated in wlc_lcnphy_txpower_recalc_target (phy_lcn.c), and called
  wlc_lcnphy_set_target_tx_pwr with a value of 40 (minor that 52, which is
  the minimum I found debugging that function).
  Again, nothing changed (even if further calls to
  wlc_lcnphy_set_target_tx_pwr =40)
  
  It is my wish to create a patch for that "issue", which I want first to
  test here locally to me, and if working&interesting, I can propose it
  for merging in next release.
  But, AMOF, now I'm just stuck.
  
  In case anybody feels like giving away any hint/feedback, I would have
  few questions:
  1) is it "brcmsmac" linux backports driver still supported or
  deprecated?
  2) if deprecated, what is the supported driver for BCM4313?
  3) About my tests, was it correct zeroing all tx_power_offsets in the
  table and call wlc_lcnphy_set_target_tx_pwr=40, to get a TX power less
  that 19dbm?
  4) if it was not correct, or partially correct, what am I missing or
  doing wrong, in order to push the TX transceiver power less than 19dbm?
  
  Thanks for your attention.
  -- 
    Nikita N.
    nikitan-Z02xGKUfPWYS+FvcfC7Uqw@public•gmane.org
  
  
  On Sun, Feb 15, 2015, at 05:32 AM, Nikita N. wrote:
  > Hi Dear backports Devs for driver brcmsmac,
  > Coming to the point, I want to lower the TX power of my BCM4313, under
  > the official values set by the regdom, to any special value I need.
  > So I'm trying to build such a "personal" patch, only for me, based on
  > latest backports v3.19 and latest Ubuntu.
  > Useless to say, "iwconfig <wlan> txpower" doesn't work, the resulting TX
  > power doesn't change.
  > I know it doesn't work because I can measure the RSSI coming out from
  > the BCM4313, using another device: it doesn't change, whatever value I
  > set.
  > 
  > So, I gave a look at the code for the brcmsmac module, and I think I
  > found the location where the TX power is *finally* set: inside
  > wlc_lcnphy_txpower_recalc_target (phy_lcn.c), call to
  > wlc_lcnphy_set_target_tx_pwr.
  > AFAIU, in that function a table of tx_power_offsets (calculated by
  > another function) is written in the device EPROM registry, and the TX
  > power is set to the relative minimum.
  > 
  > Now, my question: is that the right way to change effectively the TX
  > power?
  > I need to ask You a confirmation about that, if that is correct, before
  > I start building my patch.
  > I don't want to frustrate my time developing in the wrong code, or
  > damage the device, or other issues... :)
  > 
  > Thank you for your attention, and looking forward your feedback.
  > 
  > -- 
  > http://www.fastmail.com - mmm... Fastmail...
  > 
  > --
  > To unsubscribe from this list: send the line "unsubscribe linux-wireless"
  > in
  > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public•gmane.org
  > More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
  -- 
  http://www.fastmail.com - The professional email service
  
  --
  To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
  the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public•gmane.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
  ^ permalink raw reply	[flat|nested] 7+ messages in thread

• • [parent not found: <54E2107F.4000709@broadcom.com>]

  • • * Re: brcmsmac: TX power blocked in BCM4313
             [not found]     ` <54E2107F.4000709@broadcom.com>
      @ 2015-02-16 18:53       ` Nikita N.
             [not found]         ` <54E24B48.80601@broadcom.com>
        0 siblings, 1 reply; 7+ messages in thread
      From: Nikita N. @ 2015-02-16 18:53 UTC (permalink / raw)
        To: Arend van Spriel
        Cc: hauke, brcm80211-dev-list, linux-wireless, Kalle Valo, Pat Erley,
      	brudley, Franky Lin, meuleman, linville, pieterpg, hdegoede, wens,
      	netdev, linux-kernel@vger•kernel.org
      
      Hi Arend,
      first of all, thank you for your answer.
      
      I'm very sorry to hear that negative feedback.
      So, AFAIU, there is no support in brcmsmac for regdom and power
      settings.
      
      I don't know how much Broadcom Corp. is complaint with IEEE Standard
      802.11-2007 (page 531), along that decision.
      Missing also the support for a complete functioning of tools such as
      iwconfig and iw, doesn't put Broadcom Corp. very much Linux supporting.
      When in fact in the Windows driver, the TX power control is explicitly
      enabled and fully operational.
      
      Now, I googled around, and found the following page:
      http://www.broadcom.com/support/802.11/linux_sta.php
      the README states explicitly:
      "iwconfig eth1 txpower & iwlist eth1 txpower set and get the drivers
      user-requested transmit power level. This can go up to 32 dbm and allows
      the user to lower the tx power to levels below the regulatory limit.
      Internally, the actual tx power is always kept within regulatory limits
      no matter what the user request is set to."
      
      Unfortunately, I don't know if also that STA driver works or not,
      because I was not even able to successfully compile&install it over
      latest Ubuntu shipped backports, even if applied all bug patches.
      Whose patches, BTW, are coming open-source also from contributors out of
      Broadcom Corp, driven simply by the wish to help the community, for
      free.
      
      So I would like to ask 3 questions:
      1) Why the same STA redgom and power support (shipped with that STA
      driver) was not applied also over the latest Linux backports?
      2) What exact Ubuntu core version and backports version, have been
      adapted by responsibility of Broadcom QA Testing team, to verify the
      correctness of specifications advertized officially on that Broadcom
      Corp. web page README?
      
      Finally I would like to take the opportunity to ask you Arend, about a
      issue I raised a year ago, here a remind FYI:
      http://permalink.gmane.org/gmane.linux.kernel.wireless.general/117985
      
      After more than *ONE* year, still the brcmsmac driver can not detect 11n
      modulated frames in monitor mode.
      Question:
      3) Can (at least) that STA driver detect 11n modulated frames in monitor
      mode?
      
      I hope you or someone here will be able to answer those questions,
      because I'm not going to replicate them elsewhere.
      Since I got really frustrated by all those unsatisfactory products and
      results from Broadcom Corp., the unsatisfactory support towards Linux
      community, and the unsatisfactory Customers care.
      
      Thanks for your attention. 
      -- 
        Nikita N.
        nikitan@operamail•com
      
      
      On Mon, Feb 16, 2015, at 07:45 AM, Arend van Spriel wrote:
      > On 02/16/15 14:53, Nikita N. wrote:
      > > Hi Dear brcmsmac Devs,
      > > following up my previous email, since I didn't receive any feedback, I
      > > took the trouble to test my understandings myself.
      > > First of all, I want to report the following fact: the TX power is
      > > blocked/fixed to 19dbm, no matter what local regdom or power setting.
      > 
      > Hi Nikita,
      > 
      > We saw your previous email just this morning. Basically, tx power 
      > control is explicitly disabled in brcmsmac. I think it was one of the 
      > internal requirements to get approval for this open-source effort.
      > 
      > > If that is an issue or bug or else I leave the decision to you.
      > > Another fact is that, the Windows driver for that same interface, is
      > > capable to push the transceiver at least 10 RSSI points higher than
      > > linux backports brcmsmac driver, which means it is *DO* possible to
      > > change the TX power.
      > > In my personal case I want to lower it, but even that is not possible:
      > > no setting is working, neither changing the regdom (iw reg set) nor the
      > > power (iwconfig wlan0 txpower, iw dev wlan0 set txpower fixed, iw phy
      > > wlan0 set txpower fixed).
      > >
      > > Now, as for my tests, I just tried to hard-code few values into the
      > > brcmsmac driver module, only to see if anything changes.
      > > In details I zeroed the values of all tx_power_offsets in the table
      > > populated in wlc_lcnphy_txpower_recalc_target (phy_lcn.c), and called
      > > wlc_lcnphy_set_target_tx_pwr with a value of 40 (minor that 52, which is
      > > the minimum I found debugging that function).
      > > Again, nothing changed (even if further calls to
      > > wlc_lcnphy_set_target_tx_pwr =40)
      > >
      > > It is my wish to create a patch for that "issue", which I want first to
      > > test here locally to me, and if working&interesting, I can propose it
      > > for merging in next release.
      > > But, AMOF, now I'm just stuck.
      > >
      > > In case anybody feels like giving away any hint/feedback, I would have
      > > few questions:
      > > 1) is it "brcmsmac" linux backports driver still supported or
      > > deprecated?
      > > 2) if deprecated, what is the supported driver for BCM4313?
      > > 3) About my tests, was it correct zeroing all tx_power_offsets in the
      > > table and call wlc_lcnphy_set_target_tx_pwr=40, to get a TX power less
      > > that 19dbm?
      > > 4) if it was not correct, or partially correct, what am I missing or
      > > doing wrong, in order to push the TX transceiver power less than 19dbm?
      > 
      > Sorry to say but I can not help you. I can not encourage (nor 
      > discourage) changing the phy code.
      > 
      > Regards,
      > Arend
      
      -- 
      http://www.fastmail.com - Send your email first class
      
      ^ permalink raw reply	[flat|nested] 7+ messages in thread

    • • [parent not found: <54E24B48.80601@broadcom.com>]

      • • * Re: brcmsmac: TX power blocked in BCM4313
                 [not found]         ` <54E24B48.80601@broadcom.com>
          @ 2015-02-17  9:03           ` Nikita N.
            2015-03-04 15:39             ` brcmsmac not compliant to 802.11 for BCM4313 Nikita N.
            0 siblings, 1 reply; 7+ messages in thread
          From: Nikita N. @ 2015-02-17  9:03 UTC (permalink / raw)
            To: Arend van Spriel
            Cc: hauke, brcm80211-dev-list, linux-wireless, Kalle Valo, Pat Erley,
          	brudley, Franky Lin, meuleman, linville, pieterpg, hdegoede, wens,
          	netdev, linux-kernel@vger•kernel.org
          
          Hi Arend,
           
          > brcmsmac does assure tx power is within regulatory limits by enforcing a 
          > world regulatory domain. So what is not supported is modifying tx power 
          > settings through user-space.
          
          Yes, I believe that could be right, *a* world regulatory domain looks
          indeed enforced, the USA one only, which is pre-set default inside
          EEPROM registries device, isn't it?
           
          > I know, but that driver is not fully open-source as it links in a binary 
          > blob.
          
          AFAIK, also brcmsmac needs at least 2 firmware files to operate, without
          those nothing works.
          Isn't it the same concept?
           
          > I totally lost track of this one. I am using brcmsmac in monitor mode 
          > using bcm43224 which captures 11n frames just fine. I will give it a try 
          > with a bcm4313. The assoc response in your capture shows undefined MCS 
          > set so maybe there really are no 11n MCS rates used (?).
          
          If that was a suggestion about to purchase a bcm43224 or any other
          Broadcom Corp. product, isn't really convincing, seen the overall
          support quality Customers are experiencing in here...
          About my capture file, in the case it was really incomplete someone
          could have informed me at least a year ago.
          But anyway no respectable QA Testing team needs a purchasing Customer to
          help in verifying such enormous issue, isn't it? 
           
          > Our team consist of two man working full-time on the upstream linux 
          > drivers. So our "customer care" is something that we try to deal with on 
          > the side and admittedly things slip between the cracks.
          
          Really, *TWO* men? Are you kidding? Is that how much Broadcom Corp.
          values the Linux community?
          Needles to remind, even if Linux users don't pay for the OS license as
          Windows do, they do pay allright for any Broadcom hardware they
          purchase!
          Internet startups which sell a button on internet, they have Dev and QA
          team 5 times bigger than that!
          I sense a very gross capacity and resource planning competence issue in
          here.
          I kindly ask you, please forward that mail to your higher Managers, on
          my personal behalf, Thanks.
          
          -- 
          http://www.fastmail.com - Same, same, but different...
          
          ^ permalink raw reply	[flat|nested] 7+ messages in thread

        • • * brcmsmac not compliant to 802.11 for BCM4313
              2015-02-17  9:03           ` Nikita N.
            @ 2015-03-04 15:39             ` Nikita N.
              2015-03-04 17:13               ` Pat Erley
                   [not found]               ` <54F7486B.7050608@broadcom.com>
              0 siblings, 2 replies; 7+ messages in thread
            From: Nikita N. @ 2015-03-04 15:39 UTC (permalink / raw)
              To: Arend van Spriel
              Cc: hauke, brcm80211-dev-list, linux-wireless, Kalle Valo, Pat Erley,
            	brudley, Franky Lin, meuleman, linville, pieterpg, hdegoede, wens,
            	netdev, linux-kernel@vger•kernel.org
            
            Dear Arend,
            as followup to my last inquiry, since it's passed more than 2 weeks, I'm
            afraid I didn't receive any answer.
            As from subject, I finally discovered that brcmsmac is not compliant to
            802.11 regulations for BCM4313.
            So, as purchasing customer, and member of Linux users community, I try
            to propose my questions to you again now, 3 in total:
             
            1) Regulatory domain - you wrote "brcmsmac does assure tx power is
            within regulatory limits by enforcing a world regulatory domain"
            That affirmation is *FALSE*.
            I spent the whole weekend putting brcmsmac under heavy trace, all
            functions, above all the phy ones.
            Some code "supposes" to enforce a regulatory domain, but the effect is
            total null.
            I tried recompile the regulatory domain database, those functions did
            not retrieve the new values.
            Whatever values I set for domain 00, the effect was null - BCM4313 kept
            functioning independently.
            The functions, phy and not, which are "supposed" to set the eeprom
            registries for regdomain enforce, have effect null - the BCM4313 kept
            functioning independently.
            I tried setting random numbers in those functions and registries, the
            effect was null - the BCM4313 kept functioning independently.
            At the edge of my frustration, I started commenting away from the code
            those whole phy functions, the effect was null again - the BCM4313 kept
            functioning independently.
            I don't know for what Broadcom hw device were written and *tested* those
            functions - but sure is, they do *NOT* work for BCM4313.
            Could you please explain how/where the BCM4313 is supposed to "enforcing
            a world regulatory domain" ?
            
            2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
            I informed you about this issue more than 1 year ago, and again 2 weeks
            ago.
            The issue still reproduces, and no sign of any fix.
            When/in what backports version, this issue is supposed to be fixed
            finally?
            
            3) I explicitly purchased this BCM4313 already 1 year ago, with the
            following specs: 0x4313 rev 0x01 package 0x08, 3 cores ChipCommon,
            IEEE802.11 and PCIe.
            I have been searching for any technical datasheet specification document
            about BCM4313 on Broadcom website and others.
            Did not find any.
            Could you please send me a detailed technical datasheet specification
            document about BCM4313, for programming/dev purposes?
            
            Thank you & Greetings
            
            
            
            On Tue, Feb 17, 2015, at 01:03 AM, Nikita N. wrote:
            > Hi Arend,
            >  
            > > brcmsmac does assure tx power is within regulatory limits by enforcing a 
            > > world regulatory domain. So what is not supported is modifying tx power 
            > > settings through user-space.
            > 
            > Yes, I believe that could be right, *a* world regulatory domain looks
            > indeed enforced, the USA one only, which is pre-set default inside
            > EEPROM registries device, isn't it?
            >  
            > > I know, but that driver is not fully open-source as it links in a binary 
            > > blob.
            > 
            > AFAIK, also brcmsmac needs at least 2 firmware files to operate, without
            > those nothing works.
            > Isn't it the same concept?
            >  
            > > I totally lost track of this one. I am using brcmsmac in monitor mode 
            > > using bcm43224 which captures 11n frames just fine. I will give it a try 
            > > with a bcm4313. The assoc response in your capture shows undefined MCS 
            > > set so maybe there really are no 11n MCS rates used (?).
            > 
            > If that was a suggestion about to purchase a bcm43224 or any other
            > Broadcom Corp. product, isn't really convincing, seen the overall
            > support quality Customers are experiencing in here...
            > About my capture file, in the case it was really incomplete someone
            > could have informed me at least a year ago.
            > But anyway no respectable QA Testing team needs a purchasing Customer to
            > help in verifying such enormous issue, isn't it? 
            >  
            > > Our team consist of two man working full-time on the upstream linux 
            > > drivers. So our "customer care" is something that we try to deal with on 
            > > the side and admittedly things slip between the cracks.
            > 
            > Really, *TWO* men? Are you kidding? Is that how much Broadcom Corp.
            > values the Linux community?
            > Needles to remind, even if Linux users don't pay for the OS license as
            > Windows do, they do pay allright for any Broadcom hardware they
            > purchase!
            > Internet startups which sell a button on internet, they have Dev and QA
            > team 5 times bigger than that!
            > I sense a very gross capacity and resource planning competence issue in
            > here.
            > I kindly ask you, please forward that mail to your higher Managers, on
            > my personal behalf, Thanks.
            > 
            > -- 
            > http://www.fastmail.com - Same, same, but different...
            > 
            
            -- 
            http://www.fastmail.com - Or how I learned to stop worrying and
                                      love email again
            
            ^ permalink raw reply	[flat|nested] 7+ messages in thread

          • • * Re: brcmsmac not compliant to 802.11 for BCM4313
                2015-03-04 15:39             ` brcmsmac not compliant to 802.11 for BCM4313 Nikita N.
              @ 2015-03-04 17:13               ` Pat Erley
                     [not found]               ` <54F7486B.7050608@broadcom.com>
                1 sibling, 0 replies; 7+ messages in thread
              From: Pat Erley @ 2015-03-04 17:13 UTC (permalink / raw)
                To: Nikita N., Arend van Spriel
                Cc: hauke, brcm80211-dev-list, linux-wireless, Kalle Valo, brudley,
              	Franky Lin, meuleman, linville, pieterpg, hdegoede, wens, netdev,
              	linux-kernel@vger•kernel.org
              
              (I don't know why I've been added on this e-mail chain, I'm not in any
                way linked to broadcom or any of their drivers)
              
              On 03/04/2015 09:39 AM, Nikita N. wrote:
              > Dear Arend,
              > as followup to my last inquiry, since it's passed more than 2 weeks, I'm
              > afraid I didn't receive any answer.
              > As from subject, I finally discovered that brcmsmac is not compliant to
              > 802.11 regulations for BCM4313.
              > So, as purchasing customer, and member of Linux users community, I try
              > to propose my questions to you again now, 3 in total:
              
              If it's not compliant to 802.11 Regulations, please state in what way 
              it's not compliant, and how to reproduce that.  People will take lack of 
              compliance seriously.  Read on for what I know about the various parts.
              
              >
              > 1) Regulatory domain - you wrote "brcmsmac does assure tx power is
              > within regulatory limits by enforcing a world regulatory domain"
              > That affirmation is *FALSE*.
              > I spent the whole weekend putting brcmsmac under heavy trace, all
              > functions, above all the phy ones.
              > Some code "supposes" to enforce a regulatory domain, but the effect is
              > total null.
              > I tried recompile the regulatory domain database, those functions did
              > not retrieve the new values.
              > Whatever values I set for domain 00, the effect was null - BCM4313 kept
              > functioning independently.
              > The functions, phy and not, which are "supposed" to set the eeprom
              > registries for regdomain enforce, have effect null - the BCM4313 kept
              > functioning independently.
              > I tried setting random numbers in those functions and registries, the
              > effect was null - the BCM4313 kept functioning independently.
              > At the edge of my frustration, I started commenting away from the code
              > those whole phy functions, the effect was null again - the BCM4313 kept
              > functioning independently.
              > I don't know for what Broadcom hw device were written and *tested* those
              > functions - but sure is, they do *NOT* work for BCM4313.
              > Could you please explain how/where the BCM4313 is supposed to "enforcing
              > a world regulatory domain" ?
              
              The 'World regulatory domain' is a basic set of rules that you can 
              create by taking all of the rules of the world and joining them into 1 
              'Most Restricted' set of rules.  It's likely that this is enforced in 
              the firmware and not in the driver.  The reason that recompiling the 
              regulatory database has no effect is, the firmware probably has it's own 
              'determination' of what those rules are.  If you want a device you can 
              tweak this stuff on (and possibly end up out of regulatory compliance), 
              find one that doesn't include it's own internal regulatory handling. 
              The World Regulatory Domain (00) was setup such that it should be legal 
              to use everywhere in the world.
              
              >
              > 2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
              > I informed you about this issue more than 1 year ago, and again 2 weeks
              > ago.
              > The issue still reproduces, and no sign of any fix.
              > When/in what backports version, this issue is supposed to be fixed
              > finally?
              
              They likely have higher priority 'problems' on their list like getting 
              new hardware that doesn't work at all (for any use case) working.  This 
              could be a firmware issue and not a driver issue, which would mean 
              they'd have to pass the issue to the firmware developers, who are also 
              likely working on whatever firmware management says they should be.
              
              >
              > 3) I explicitly purchased this BCM4313 already 1 year ago, with the
              > following specs: 0x4313 rev 0x01 package 0x08, 3 cores ChipCommon,
              > IEEE802.11 and PCIe.
              > I have been searching for any technical datasheet specification document
              > about BCM4313 on Broadcom website and others.
              > Did not find any.
              > Could you please send me a detailed technical datasheet specification
              > document about BCM4313, for programming/dev purposes?
              
              MOST chip manufacturers won't give you the detailed low level datasheets 
              for their wifi chips as often times you can make changes that cause the 
              hardware to transmit out of calibrated specs(and potentially damage 
              hardware) or outside of legal limits(and risk legal troubles).
              
              >
              > Thank you & Greetings
              >
              >
              >
              > On Tue, Feb 17, 2015, at 01:03 AM, Nikita N. wrote:
              >> Hi Arend,
              >>
              >>> brcmsmac does assure tx power is within regulatory limits by enforcing a
              >>> world regulatory domain. So what is not supported is modifying tx power
              >>> settings through user-space.
              >>
              >> Yes, I believe that could be right, *a* world regulatory domain looks
              >> indeed enforced, the USA one only, which is pre-set default inside
              >> EEPROM registries device, isn't it?
              >>
              >>> I know, but that driver is not fully open-source as it links in a binary
              >>> blob.
              >>
              >> AFAIK, also brcmsmac needs at least 2 firmware files to operate, without
              >> those nothing works.
              >> Isn't it the same concept?
              >>
              >>> I totally lost track of this one. I am using brcmsmac in monitor mode
              >>> using bcm43224 which captures 11n frames just fine. I will give it a try
              >>> with a bcm4313. The assoc response in your capture shows undefined MCS
              >>> set so maybe there really are no 11n MCS rates used (?).
              >>
              >> If that was a suggestion about to purchase a bcm43224 or any other
              >> Broadcom Corp. product, isn't really convincing, seen the overall
              >> support quality Customers are experiencing in here...
              >> About my capture file, in the case it was really incomplete someone
              >> could have informed me at least a year ago.
              >> But anyway no respectable QA Testing team needs a purchasing Customer to
              >> help in verifying such enormous issue, isn't it?
              >>
              >>> Our team consist of two man working full-time on the upstream linux
              >>> drivers. So our "customer care" is something that we try to deal with on
              >>> the side and admittedly things slip between the cracks.
              >>
              >> Really, *TWO* men? Are you kidding? Is that how much Broadcom Corp.
              >> values the Linux community?
              >> Needles to remind, even if Linux users don't pay for the OS license as
              >> Windows do, they do pay allright for any Broadcom hardware they
              >> purchase!
              >> Internet startups which sell a button on internet, they have Dev and QA
              >> team 5 times bigger than that!
              >> I sense a very gross capacity and resource planning competence issue in
              >> here.
              >> I kindly ask you, please forward that mail to your higher Managers, on
              >> my personal behalf, Thanks.
              >>
              >> --
              >> http://www.fastmail.com - Same, same, but different...
              >>
              >
              
              ^ permalink raw reply	[flat|nested] 7+ messages in thread

            • [parent not found: <54F7486B.7050608@broadcom.com>]

            • • * Re: brcmsmac not compliant to 802.11 for BCM4313
                       [not found]               ` <54F7486B.7050608@broadcom.com>
                @ 2015-03-05  8:23                 ` Nikita N.
                       [not found]                   ` <54F824D2.9030504@broadcom.com>
                  0 siblings, 1 reply; 7+ messages in thread
                From: Nikita N. @ 2015-03-05  8:23 UTC (permalink / raw)
                  To: Arend van Spriel
                  Cc: hauke, brcm80211-dev-list, linux-wireless, Kalle Valo, Pat Erley,
                	brudley, Franky Lin, meuleman, linville, pieterpg, hdegoede, wens,
                	netdev, linux-kernel@vger•kernel.org
                
                Dear Arend,
                
                > > I tried recompile the regulatory domain database, those functions did
                > > not retrieve the new values.
                > > Whatever values I set for domain 00, the effect was null - BCM4313 kept
                > > functioning independently.
                > That is exactly what should happen. The brcmsmac driver applies a 
                > so-called strict custom regulatory domain and does not follow any 
                > regulatory domain provisioning.
                
                As I understand your words, the BCM4313 has a proprietary regdomain, a
                so called "strict custom regulatory domain" buried in the firmware, and
                finish.
                That proprietary regdomain is applied when attaching brcmsmac Linux
                driver.
                But in other drivers, e.g. the wl driver, or ms-windows drivers all
                versions, the BCM4313 doesn't apply that "strict custom regulatory
                domain".
                In all other drivers, the BCM4313 applies different regdomains and
                relative power levels according to the system/OS.
                So now, after your explanation, logic tells me, the BCM4313 regdomain is
                locked only in the brcmsmac driver for Linux.
                Instead it operates open and fully functional in the other drivers.
                So now 3 more questions, if I'm allowed:
                1) What is assuring that proprietary "strict custom regulatory domain"
                is not obsolete/deprecated and compliant to 802.11 regulations?
                2) Regulatory domains can by 802.11 regulation change dynamically within
                time/country, why BCM4313 users are obliged to lock only on 1
                proprietary regdomain?
                3) Why BCM4313 is locked only for brcmsmac?
                
                > > 2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
                > > I informed you about this issue more than 1 year ago, and again 2 weeks
                > > ago.
                > > The issue still reproduces, and no sign of any fix.
                > > When/in what backports version, this issue is supposed to be fixed
                > > finally?
                > What is the deal about backports here. If there will be a fix it will be 
                > done upstream and eventually end up in a backports package. First need 
                > to root cause this issue.
                
                So now 2 more questions, if I'm allowed:
                4) Has been done any step so far, to root the cause of this issue?
                5) Since I have spent money&time on that device, I would like at least
                to monitor the work in progress done to root the cause of this issue -
                how can I?
                
                Thanks & Greetings
                
                On Wed, Mar 4, 2015, at 10:01 AM, Arend van Spriel wrote:
                > On 03/04/15 16:39, Nikita N. wrote:
                > > Dear Arend,
                > > as followup to my last inquiry, since it's passed more than 2 weeks, I'm
                > > afraid I didn't receive any answer.
                > 
                > Ok, you diverted my attention by presenting an absurd sense of reality. 
                > But let me put emotions aside and answer your questions below.
                > 
                > > As from subject, I finally discovered that brcmsmac is not compliant to
                > > 802.11 regulations for BCM4313.
                > > So, as purchasing customer, and member of Linux users community, I try
                > > to propose my questions to you again now, 3 in total:
                > >
                > > 1) Regulatory domain - you wrote "brcmsmac does assure tx power is
                > > within regulatory limits by enforcing a world regulatory domain"
                > > That affirmation is *FALSE*.
                > > I spent the whole weekend putting brcmsmac under heavy trace, all
                > > functions, above all the phy ones.
                > > Some code "supposes" to enforce a regulatory domain, but the effect is
                > > total null.
                > > I tried recompile the regulatory domain database, those functions did
                > > not retrieve the new values.
                > > Whatever values I set for domain 00, the effect was null - BCM4313 kept
                > > functioning independently.
                > 
                > That is exactly what should happen. The brcmsmac driver applies a 
                > so-called strict custom regulatory domain and does not follow any 
                > regulatory domain provisioning.
                > 
                > [87636.143361] cfg80211: Ignoring regulatory request set by core since 
                > the driver uses its own custom regulatory domain
                > 
                > > The functions, phy and not, which are "supposed" to set the eeprom
                > > registries for regdomain enforce, have effect null - the BCM4313 kept
                > > functioning independently.
                > > I tried setting random numbers in those functions and registries, the
                > > effect was null - the BCM4313 kept functioning independently.
                > > At the edge of my frustration, I started commenting away from the code
                > > those whole phy functions, the effect was null again - the BCM4313 kept
                > > functioning independently.
                > > I don't know for what Broadcom hw device were written and *tested* those
                > > functions - but sure is, they do *NOT* work for BCM4313.
                > > Could you please explain how/where the BCM4313 is supposed to "enforcing
                > > a world regulatory domain" ?
                > 
                > It is done in firmware.
                > 
                > > 2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
                > > I informed you about this issue more than 1 year ago, and again 2 weeks
                > > ago.
                > > The issue still reproduces, and no sign of any fix.
                > > When/in what backports version, this issue is supposed to be fixed
                > > finally?
                > 
                > What is the deal about backports here. If there will be a fix it will be 
                > done upstream and eventually end up in a backports package. First need 
                > to root cause this issue.
                > 
                > > 3) I explicitly purchased this BCM4313 already 1 year ago, with the
                > > following specs: 0x4313 rev 0x01 package 0x08, 3 cores ChipCommon,
                > > IEEE802.11 and PCIe.
                > > I have been searching for any technical datasheet specification document
                > > about BCM4313 on Broadcom website and others.
                > > Did not find any.
                > > Could you please send me a detailed technical datasheet specification
                > > document about BCM4313, for programming/dev purposes?
                > 
                > That is all proprietary information.
                > 
                > Regards.
                > Arend
                > 
                > >
                > > On Tue, Feb 17, 2015, at 01:03 AM, Nikita N. wrote:
                > >> Hi Arend,
                > >>
                > >>> brcmsmac does assure tx power is within regulatory limits by enforcing a
                > >>> world regulatory domain. So what is not supported is modifying tx power
                > >>> settings through user-space.
                > >>
                > >> Yes, I believe that could be right, *a* world regulatory domain looks
                > >> indeed enforced, the USA one only, which is pre-set default inside
                > >> EEPROM registries device, isn't it?
                > >>
                > >>> I know, but that driver is not fully open-source as it links in a binary
                > >>> blob.
                > >>
                > >> AFAIK, also brcmsmac needs at least 2 firmware files to operate, without
                > >> those nothing works.
                > >> Isn't it the same concept?
                > >>
                > >>> I totally lost track of this one. I am using brcmsmac in monitor mode
                > >>> using bcm43224 which captures 11n frames just fine. I will give it a try
                > >>> with a bcm4313. The assoc response in your capture shows undefined MCS
                > >>> set so maybe there really are no 11n MCS rates used (?).
                > >>
                > >> If that was a suggestion about to purchase a bcm43224 or any other
                > >> Broadcom Corp. product, isn't really convincing, seen the overall
                > >> support quality Customers are experiencing in here...
                > >> About my capture file, in the case it was really incomplete someone
                > >> could have informed me at least a year ago.
                > >> But anyway no respectable QA Testing team needs a purchasing Customer to
                > >> help in verifying such enormous issue, isn't it?
                > >>
                > >>> Our team consist of two man working full-time on the upstream linux
                > >>> drivers. So our "customer care" is something that we try to deal with on
                > >>> the side and admittedly things slip between the cracks.
                > >>
                > >> Really, *TWO* men? Are you kidding? Is that how much Broadcom Corp.
                > >> values the Linux community?
                > >> Needles to remind, even if Linux users don't pay for the OS license as
                > >> Windows do, they do pay allright for any Broadcom hardware they
                > >> purchase!
                > >> Internet startups which sell a button on internet, they have Dev and QA
                > >> team 5 times bigger than that!
                > >> I sense a very gross capacity and resource planning competence issue in
                > >> here.
                > >> I kindly ask you, please forward that mail to your higher Managers, on
                > >> my personal behalf, Thanks.
                > >>
                > >> --
                > >> http://www.fastmail.com - Same, same, but different...
                > >>
                > >
                > 
                
                -- 
                http://www.fastmail.com - mmm... Fastmail...
                
                ^ permalink raw reply	[flat|nested] 7+ messages in thread

              • • [parent not found: <54F824D2.9030504@broadcom.com>]

                • • * Re: brcmsmac not compliant to 802.11 for BCM4313
                           [not found]                   ` <54F824D2.9030504@broadcom.com>
                    @ 2015-03-05 18:50                     ` Nikita N.
                      0 siblings, 0 replies; 7+ messages in thread
                    From: Nikita N. @ 2015-03-05 18:50 UTC (permalink / raw)
                      To: Arend van Spriel
                      Cc: hauke, brcm80211-dev-list, linux-wireless, Kalle Valo, Pat Erley,
                    	brudley, Franky Lin, meuleman, linville, pieterpg, hdegoede, wens,
                    	netdev, linux-kernel@vger•kernel.org
                    
                    Dear Arend,
                    thanks for answering, unfortunately the answers open new questions
                    indeed, if I may.
                    
                    > > 1) What is assuring that proprietary "strict custom regulatory domain"
                    > > is not obsolete/deprecated and compliant to 802.11 regulations?
                    > This is a very hypothetical question. If regulation would indeed change 
                    > in such way we would have to release new firmware.
                    
                    That is not hypothetical at all, since we do *NOT* know what that
                    proprietary regdomain is enforcing.
                    That "strict custom regulatory domain" is proprietary Broadcom, hence
                    nobody knows what is written inside it, following all sad&known
                    considerations that Pat Erley explained (that is also the answer to you
                    Pat)
                    Now, to verify that such proprietary regdomain is enforcing a legal and
                    compliant regdomain, we should know it's details.
                    Question, is it possible to know how/what is written in that proprietary
                    regdomain inside the firmware?
                    
                    > > 2) Regulatory domains can by 802.11 regulation change dynamically within
                    > > time/country, why BCM4313 users are obliged to lock only on 1
                    > > proprietary regdomain?
                    > This is not mandatory. Using 1 restricted world regulatory domain is 
                    > fine as well as Pat Erley explained in his response.
                    
                    Sorry, what is not mandatory?
                    It is not mandatory that users are obliged to lock only on 1 proprietary
                    regdomain?
                    Of course it is not, it is not fair nor compliant to any regulations I
                    know of - do you?
                    It is not mandatory that 802.11 regulations change? sure, but they
                    change, indeed.
                    It is not mandatory regdomains rules change? sure, but they change,
                    indeed.
                    
                    > > 4) Has been done any step so far, to root the cause of this issue?
                    > I did hunt down a 4313 to do so and put it in my test laptop.
                    Thank you very much! :)
                    In the meantime, if you could please verify a possible solution coming
                    now to my mind.
                    I understood that Broadcom management doesn't want to give power
                    controls to user.
                    Very sad personally, but I don't see any help to that coming from you
                    (your managers).
                    So, maybe, do BCM4313 has more than 1 special proprietary preset
                    regdomain buried in the firmware?
                    If yes, it would be great if you could tell us (programmers) how we can
                    switch to any of those other preset regdomains.
                    So that we could test them, and find the one which best conform to our
                    local/country regulation.
                    It seems to me a fair compromise for solving that issue, isn't?
                    
                    > > 5) Since I have spent money&time on that device, I would like at least
                    > > to monitor the work in progress done to root the cause of this issue -
                    > > how can I?
                    > 
                    > You could create a bugzilla item on kernel.org.
                    
                    Sure will do.
                    As soon as someone from Broadcom QA Testing Team, will find that the
                    root cause of that issue depends on Linux kernel.
                    I guess I already did my best to try debugging and solving for *free* a
                    Broadcom issue which: 1) doesn't depend on me, 2) is locked down in a
                    proprietary firmware, 3) is protected by secrecy of proprietary Broadcom
                    informations.
                    
                    Thanks & Greetings.
                    
                    -- 
                      Nikita N.
                      nikitan@operamail•com
                    
                    
                    On Thu, Mar 5, 2015, at 01:41 AM, Arend van Spriel wrote:
                    > On 03/05/15 09:23, Nikita N. wrote:
                    > > Dear Arend,
                    > >
                    > >>> I tried recompile the regulatory domain database, those functions did
                    > >>> not retrieve the new values.
                    > >>> Whatever values I set for domain 00, the effect was null - BCM4313 kept
                    > >>> functioning independently.
                    > >> That is exactly what should happen. The brcmsmac driver applies a
                    > >> so-called strict custom regulatory domain and does not follow any
                    > >> regulatory domain provisioning.
                    > >
                    > > As I understand your words, the BCM4313 has a proprietary regdomain, a
                    > > so called "strict custom regulatory domain" buried in the firmware, and
                    > > finish.
                    > > That proprietary regdomain is applied when attaching brcmsmac Linux
                    > > driver.
                    > > But in other drivers, e.g. the wl driver, or ms-windows drivers all
                    > > versions, the BCM4313 doesn't apply that "strict custom regulatory
                    > > domain".
                    > > In all other drivers, the BCM4313 applies different regdomains and
                    > > relative power levels according to the system/OS.
                    > > So now, after your explanation, logic tells me, the BCM4313 regdomain is
                    > > locked only in the brcmsmac driver for Linux.
                    > > Instead it operates open and fully functional in the other drivers.
                    > > So now 3 more questions, if I'm allowed:
                    > > 1) What is assuring that proprietary "strict custom regulatory domain"
                    > > is not obsolete/deprecated and compliant to 802.11 regulations?
                    > 
                    > This is a very hypothetical question. If regulation would indeed change 
                    > in such way we would have to release new firmware.
                    > 
                    > > 2) Regulatory domains can by 802.11 regulation change dynamically within
                    > > time/country, why BCM4313 users are obliged to lock only on 1
                    > > proprietary regdomain?
                    > 
                    > This is not mandatory. Using 1 restricted world regulatory domain is 
                    > fine as well as Pat Erley explained in his response.
                    > 
                    > > 3) Why BCM4313 is locked only for brcmsmac?
                    > 
                    > I explained that in an earlier email. It was a requirement for getting 
                    > the driver open-sourced to avoid releasing proprietary code. For wl 
                    > driver that part is in the binary blob that runs on the host so it does 
                    > not need the restriction. Guess no further explanation is needed for the 
                    > windows driver.
                    > 
                    > >>> 2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
                    > >>> I informed you about this issue more than 1 year ago, and again 2 weeks
                    > >>> ago.
                    > >>> The issue still reproduces, and no sign of any fix.
                    > >>> When/in what backports version, this issue is supposed to be fixed
                    > >>> finally?
                    > >> What is the deal about backports here. If there will be a fix it will be
                    > >> done upstream and eventually end up in a backports package. First need
                    > >> to root cause this issue.
                    > >
                    > > So now 2 more questions, if I'm allowed:
                    > 
                    > You're pushing the limit ;-)
                    > 
                    > > 4) Has been done any step so far, to root the cause of this issue?
                    > 
                    > I did hunt down a 4313 to do so and put it in my test laptop.
                    > 
                    > > 5) Since I have spent money&time on that device, I would like at least
                    > > to monitor the work in progress done to root the cause of this issue -
                    > > how can I?
                    > 
                    > You could create a bugzilla item on kernel.org.
                    > 
                    > Regards,
                    > Arend
                    > 
                    > > Thanks&  Greetings
                    > >
                    > > On Wed, Mar 4, 2015, at 10:01 AM, Arend van Spriel wrote:
                    > >> On 03/04/15 16:39, Nikita N. wrote:
                    > >>> Dear Arend,
                    > >>> as followup to my last inquiry, since it's passed more than 2 weeks, I'm
                    > >>> afraid I didn't receive any answer.
                    > >>
                    > >> Ok, you diverted my attention by presenting an absurd sense of reality.
                    > >> But let me put emotions aside and answer your questions below.
                    > >>
                    > >>> As from subject, I finally discovered that brcmsmac is not compliant to
                    > >>> 802.11 regulations for BCM4313.
                    > >>> So, as purchasing customer, and member of Linux users community, I try
                    > >>> to propose my questions to you again now, 3 in total:
                    > >>>
                    > >>> 1) Regulatory domain - you wrote "brcmsmac does assure tx power is
                    > >>> within regulatory limits by enforcing a world regulatory domain"
                    > >>> That affirmation is *FALSE*.
                    > >>> I spent the whole weekend putting brcmsmac under heavy trace, all
                    > >>> functions, above all the phy ones.
                    > >>> Some code "supposes" to enforce a regulatory domain, but the effect is
                    > >>> total null.
                    > >>> I tried recompile the regulatory domain database, those functions did
                    > >>> not retrieve the new values.
                    > >>> Whatever values I set for domain 00, the effect was null - BCM4313 kept
                    > >>> functioning independently.
                    > >>
                    > >> That is exactly what should happen. The brcmsmac driver applies a
                    > >> so-called strict custom regulatory domain and does not follow any
                    > >> regulatory domain provisioning.
                    > >>
                    > >> [87636.143361] cfg80211: Ignoring regulatory request set by core since
                    > >> the driver uses its own custom regulatory domain
                    > >>
                    > >>> The functions, phy and not, which are "supposed" to set the eeprom
                    > >>> registries for regdomain enforce, have effect null - the BCM4313 kept
                    > >>> functioning independently.
                    > >>> I tried setting random numbers in those functions and registries, the
                    > >>> effect was null - the BCM4313 kept functioning independently.
                    > >>> At the edge of my frustration, I started commenting away from the code
                    > >>> those whole phy functions, the effect was null again - the BCM4313 kept
                    > >>> functioning independently.
                    > >>> I don't know for what Broadcom hw device were written and *tested* those
                    > >>> functions - but sure is, they do *NOT* work for BCM4313.
                    > >>> Could you please explain how/where the BCM4313 is supposed to "enforcing
                    > >>> a world regulatory domain" ?
                    > >>
                    > >> It is done in firmware.
                    > >>
                    > >>> 2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
                    > >>> I informed you about this issue more than 1 year ago, and again 2 weeks
                    > >>> ago.
                    > >>> The issue still reproduces, and no sign of any fix.
                    > >>> When/in what backports version, this issue is supposed to be fixed
                    > >>> finally?
                    > >>
                    > >> What is the deal about backports here. If there will be a fix it will be
                    > >> done upstream and eventually end up in a backports package. First need
                    > >> to root cause this issue.
                    > >>
                    > >>> 3) I explicitly purchased this BCM4313 already 1 year ago, with the
                    > >>> following specs: 0x4313 rev 0x01 package 0x08, 3 cores ChipCommon,
                    > >>> IEEE802.11 and PCIe.
                    > >>> I have been searching for any technical datasheet specification document
                    > >>> about BCM4313 on Broadcom website and others.
                    > >>> Did not find any.
                    > >>> Could you please send me a detailed technical datasheet specification
                    > >>> document about BCM4313, for programming/dev purposes?
                    > >>
                    > >> That is all proprietary information.
                    > >>
                    > >> Regards.
                    > >> Arend
                    > >>
                    > >>>
                    > >>> On Tue, Feb 17, 2015, at 01:03 AM, Nikita N. wrote:
                    > >>>> Hi Arend,
                    > >>>>
                    > >>>>> brcmsmac does assure tx power is within regulatory limits by enforcing a
                    > >>>>> world regulatory domain. So what is not supported is modifying tx power
                    > >>>>> settings through user-space.
                    > >>>>
                    > >>>> Yes, I believe that could be right, *a* world regulatory domain looks
                    > >>>> indeed enforced, the USA one only, which is pre-set default inside
                    > >>>> EEPROM registries device, isn't it?
                    > >>>>
                    > >>>>> I know, but that driver is not fully open-source as it links in a binary
                    > >>>>> blob.
                    > >>>>
                    > >>>> AFAIK, also brcmsmac needs at least 2 firmware files to operate, without
                    > >>>> those nothing works.
                    > >>>> Isn't it the same concept?
                    > >>>>
                    > >>>>> I totally lost track of this one. I am using brcmsmac in monitor mode
                    > >>>>> using bcm43224 which captures 11n frames just fine. I will give it a try
                    > >>>>> with a bcm4313. The assoc response in your capture shows undefined MCS
                    > >>>>> set so maybe there really are no 11n MCS rates used (?).
                    > >>>>
                    > >>>> If that was a suggestion about to purchase a bcm43224 or any other
                    > >>>> Broadcom Corp. product, isn't really convincing, seen the overall
                    > >>>> support quality Customers are experiencing in here...
                    > >>>> About my capture file, in the case it was really incomplete someone
                    > >>>> could have informed me at least a year ago.
                    > >>>> But anyway no respectable QA Testing team needs a purchasing Customer to
                    > >>>> help in verifying such enormous issue, isn't it?
                    > >>>>
                    > >>>>> Our team consist of two man working full-time on the upstream linux
                    > >>>>> drivers. So our "customer care" is something that we try to deal with on
                    > >>>>> the side and admittedly things slip between the cracks.
                    > >>>>
                    > >>>> Really, *TWO* men? Are you kidding? Is that how much Broadcom Corp.
                    > >>>> values the Linux community?
                    > >>>> Needles to remind, even if Linux users don't pay for the OS license as
                    > >>>> Windows do, they do pay allright for any Broadcom hardware they
                    > >>>> purchase!
                    > >>>> Internet startups which sell a button on internet, they have Dev and QA
                    > >>>> team 5 times bigger than that!
                    > >>>> I sense a very gross capacity and resource planning competence issue in
                    > >>>> here.
                    > >>>> I kindly ask you, please forward that mail to your higher Managers, on
                    > >>>> my personal behalf, Thanks.
                    > >>>>
                    > >>>> --
                    > >>>> http://www.fastmail.com - Same, same, but different...
                    > >>>>
                    > >>>
                    > >>
                    > >
                    > 
                    
                    -- 
                    http://www.fastmail.com - The way an email service should be
                    
                    ^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-03-05 18:50 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1424007136.2042747.227726249.45B6A0E2@webmail.messagingengine.com>
     [not found] ` <1424007136.2042747.227726249.45B6A0E2-2RFepEojUI2N1INw9kWLP6GC3tUn3ZHUQQ4Iyu8u01E@public.gmane.org>
2015-02-16 13:53   ` brcmsmac: TX power blocked in BCM4313 Nikita N.
     [not found]     ` <54E2107F.4000709@broadcom.com>
2015-02-16 18:53       ` Nikita N.
     [not found]         ` <54E24B48.80601@broadcom.com>
2015-02-17  9:03           ` Nikita N.
2015-03-04 15:39             ` brcmsmac not compliant to 802.11 for BCM4313 Nikita N.
2015-03-04 17:13               ` Pat Erley
     [not found]               ` <54F7486B.7050608@broadcom.com>
2015-03-05  8:23                 ` Nikita N.
     [not found]                   ` <54F824D2.9030504@broadcom.com>
2015-03-05 18:50                     ` Nikita N.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox