Skip to content
Snippets Groups Projects
  1. Mar 10, 2017
  2. Mar 09, 2017
    • Matthias Schiffer's avatar
      netifd: update to git HEAD version · 732645b0
      Matthias Schiffer authored
      
      91810ec system-linux: add VXLAN support
      
      Signed-off-by: default avatarMatthias Schiffer <mschiffer@universe-factory.net>
      732645b0
    • Daniel Golle's avatar
      rt2x00: mt7620: yet another beauty session · 181bc02d
      Daniel Golle authored
      
      So here is another round of improvements for MT7620 WiFi.
      
      This commit fixes a few significant issues related to TX_PWR_CFG_x and
      TX_ALC and also makes the code more readable by adding register
      descriptions for things added for MT7620 and use the usual bit-field
      access macros and the now defined macros instead of plain bit-ops and
      magic numbers.
      
      Properly describe EEPROM_TARGET_POWER at word 0x68 (== byte 0xD0) and
      thereby fix internal TXALC which would otherwise just read
      out-of-bounds of the EEPROM map.
      
      Split-out tx-power/ALC related stuff into an additional function.
      Fix VCO calibration, it was carried out properly in the channel
      switching but incomplete in the actual VCO calibration function.
      Also there is no need to trigger VCO calibration in channel switching,
      the VCO calibration function is already being called at this point.
      Remove it from channel switching function to avoid redundant code.
      
      The TX power calibration differs significantly from all other
      Mediatek/Ralink chips: They finally allow 0.5dB steps stored as 8-bit
      values for (almost) each bitrate -- and promptly ran out of space and
      for some reason didn't want to change the EEPROM layout. The hence
      opted for a scheme of sharing values for some adjecent bitrates and
      a highly over-complicated (or obfuscated?) way to populate the
      TX_PWR_CFG_x registers with the values stored in the EEPROM.
      The code here now looks much less complicated than what you see in the
      vendor's driver, however, it does the exact same thing:
      bGpwrdeltaMinus is a constant and always TRUE, hence half of the
      code was dead. Gpwrdelta is always 0 (rather than using the value read
      from the EEPROM). What remains is some very grotesque effort to avoid
      0x20, probably some hardware bug related to some misunderstanding of
      what a singed 8-bit value is (imagine: if it was a signed 6-bit value
      then someone could believe that 0x20 == 0x0). And then they didn't
      clean it up once they later on anandonned that whole story of having a
      constant offset for 40 MHz channels and just set the offset to be
      constant 0 -- there is no effort for avoiding 0x20 for the 20 MHz
      values stored in the EEPROM, hence that's probably just a forbidden
      value in the EEPROM specs and won't appear anyway...
      Anyway, the whole thing felt like solving some college math test
      where in the end everything cancels out and the result equals 0 ;)
      To make sure that channel bandwidth power compensation really doesn't
      need to be taken care of, output a warning when the corresponding
      value stored in the EEPROM is non-zero.
      
      Also there is no apparent reason to refrain from initializing RFCSR
      register 13, it doesn't fail what-so-ever.
      
      Signed-off-by: default avatarDaniel Golle <daniel@makrotopia.org>
      181bc02d
    • Rafał Miłecki's avatar
      bcm53xx: fix memory corruption caused by iproc PCE controller driver · edda26dc
      Rafał Miłecki authored
      
      This is a simple revert of upstream patch for now.
      
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      edda26dc
    • Kevin Darbyshire-Bryant's avatar
      dnsmasq: do not forward rfc6761 excluded domains · 3a06dd60
      Kevin Darbyshire-Bryant authored
      
      RFC 6761 defines a number of top level domains should not be forwarded
      to the Internet's domain servers since they are not responsible for
      those domains.
      
      This change adds a list of domains that will be blocked when 'boguspriv'
      is used and augments that which is already blocked by dnsmasq's notion
      of 'local service' using '--bogus-priv' i.e. RFC 1918 private addresses
      and IPv6 prefixes as defined in RFC 6303.
      
      To make this configurable rather than hard coded in dnsmasq's init
      script, a new file /usr/share/dnsmasq/rfc6761.conf is conditionally
      included.
      
      The default file matches the RFC 6761 recommendation along with a few
      other top level domains that should not be forwarded to the Internet.
      
      Compile & run tested Archer C7 v2
      
      Signed-off-by: default avatarKevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
      3a06dd60
  3. Mar 08, 2017
  4. Mar 07, 2017
  5. Mar 06, 2017
  6. Mar 05, 2017
  7. Mar 04, 2017
  8. Mar 03, 2017
Loading