Announcement

Collapse
No announcement yet.

Linux's Qualcomm Ath10k Driver Getting WoWLAN, WCN3990 Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux's Qualcomm Ath10k Driver Getting WoWLAN, WCN3990 Support

    Phoronix: Linux's Qualcomm Ath10k Driver Getting WoWLAN, WCN3990 Support

    The Qualcomm/Atheros "Ath10k" Linux driver coming up in the Linux 4.20~5.0 kernel merge window is picking up two prominent features...

    http://www.phoronix.com/scan.php?pag...N-Plus-WCN3990

  • #2
    Kalle has also recently posted firmware updates for ath10k.

    https://www.spinics.net/lists/linux-...msg178842.html

    Comment


    • #3
      Will this "new" driver hide another closed-source binary inside?
      If so then ... no, thanks.
      (spoiler: yes, there's a brand new ath10k-20181010 blob in the firmware git).
      While new fantastic hardware with gazillions of new features and super boosted performance is always desirable (really? really really?),
      a tainted kernel is as desirable as a kick in the mouth or as a(n unwanted) system backdoor or a security hole.
      My favorite distro already has a 290+MB "linux-firmware" package installed (then you also have alsa-firmware, bluez-firmware and sane-firmware).
      A list can be seen here (beware: git ahead!).
      Yes, I am not using all those blobs at once. Just one or two. But why?
      Because the hardware support under Linux has lacked behind for years. So a BLOB has been considered better than nothing.
      But what about the so-called "now"?
      I wouldn't say that Linux relevance in the market is minimal or even marginal.
      And with home routers and smartphones running Linux, the relevance is rather high. Isn't it?

      I would like the Linux dev-board and the Linux whatever-committee to vote for a "please, publish that f*c*i*g source code or we won't support your hardware by license" motion.

      Then I wake up from my dreams and go on loading my blobs.
      Last edited by Uqbar; 10-16-2018, 02:48 AM.

      Comment


      • #4
        Are there any 802.11AC devices that don’t require blobs?

        Comment


        • #5
          Originally posted by Uqbar View Post
          Will this "new" driver hide another closed-source binary inside?
          If so then ... no, thanks.
          (spoiler: yes, there's a brand new ath10k-20181010 blob in the firmware git).
          While new fantastic hardware with gazillions of new features and super boosted performance is always desirable (really? really really?),
          a tainted kernel is as desirable as a kick in the mouth or as a(n unwanted) system backdoor or a security hole.
          My favorite distro already has a 290+MB "linux-firmware" package installed (then you also have alsa-firmware, bluez-firmware and sane-firmware).
          A list can be seen here (beware: git ahead!).
          Yes, I am not using all those blobs at once. Just one or two. But why?
          Because the hardware support under Linux has lacked behind for years. So a BLOB has been considered better than nothing.
          But what about the so-called "now"?
          I wouldn't say that Linux relevance in the market is minimal or even marginal.
          And with home routers and smartphones running Linux, the relevance is rather high. Isn't it?

          I would like the Linux dev-board and the Linux whatever-committee to vote for a "please, publish that f*c*i*g source code or we won't support your hardware by license" motion.

          Then I wake up from my dreams and go on loading my blobs.
          Fuck yeah. Dumping blobs does not count as support imho. I like my ath9k with open firmware and wifi fairness queuing.

          Comment


          • #6
            Originally posted by Uqbar View Post
            Will this "new" driver hide another closed-source binary inside?
            You are confusing blob drivers with firmware. Firmware does not taint the kernel, and is not "inside" a driver. Drivers run with the Kernel, in RAM and on the CPU.

            Firmware is run inside the peripheral's own controller/processors, regardless of the OS or driver. The only interaction with the Linux kernel is sending the blob to the peripheral.

            That's why a blob driver taints the kernel, and a firmware does not.


            Now the blob is loaded at runtime, while before it was often stored in a ROM in the peripheral itself.
            Loadable blobs are a significant improvement over ROMs as they still give the user as much control as possible, as you can decide what version of the blob to load (which allows you to sidestep any attempt to remove features in more recent firmwares or allows some working around firmware bugs by refusing update until they release a stable firmware), or IF you want to load the blob at all (which effectively disables the peripheral).

            Comment


            • #7
              Originally posted by cynical View Post
              Are there any 802.11AC devices that don’t require blobs?
              No, every ac device needs a firmware to work. https://en.wikipedia.org/wiki/Compar...reless_drivers

              Do note that a lot of wifi n devices rely on firmware flashed on a ROM in the device itself (see link above) anyway.

              Comment


              • #8
                Originally posted by starshipeleven View Post
                You are confusing blob drivers with firmware. Firmware does not taint the kernel, and is not "inside" a driver. Drivers run with the Kernel, in RAM and on the CPU.

                Firmware is run inside the peripheral's own controller/processors, regardless of the OS or driver. The only interaction with the Linux kernel is sending the blob to the peripheral.

                That's why a blob driver taints the kernel, and a firmware does not.


                Now the blob is loaded at runtime, while before it was often stored in a ROM in the peripheral itself.
                Loadable blobs are a significant improvement over ROMs as they still give the user as much control as possible, as you can decide what version of the blob to load (which allows you to sidestep any attempt to remove features in more recent firmwares or allows some working around firmware bugs by refusing update until they release a stable firmware), or IF you want to load the blob at all (which effectively disables the peripheral).
                In order to make hardware device work some software part is needed.
                I don't like it whenever that part is closed source.
                No matter whether that's run inside the device, on the host cpu or any other hardware part,
                at it cannot be peer reviewed, nor modified.

                Thanks for clarifying, though.

                Comment


                • #9
                  Originally posted by Uqbar View Post
                  In order to make hardware device work some software part is needed.
                  I don't like it whenever that part is closed source.
                  Eh, you're not wrong, but I'm just not really seeing a future where even low-level firmware for devices is opensource (and there are enough hardware manuals to actually make sense of it).
                  No matter whether that's run inside the device, on the host cpu or any other hardware part,
                  at it cannot be peer reviewed, nor modified.
                  The reason why it is seen as less important is that a peripheral is (or can be made) untrusted, so it won't have access to 100% the system like a driver has in Linux.

                  A driver in Linux can do whatever it wants, while a peripheral still has to follow the limitations of the communication protocol it is using, and there are measures to sandbox them, like with IOMMU/VT-d.

                  Comment


                  • #10
                    I understand your points. Especially the one about the differences between a driver and a firmware blob.
                    Nonetheless, I don't like it anyway.
                    Because there's no reason (for me at least) to keep that code opaque and hidden.
                    Especially if there's a way to reverse compile or to disassemble it.

                    Then we could discuss what can be done and cannot with a device running undisclosed software.
                    For example, a network adapter (wired or wireless) can do a lot of things, as the latest news seem to show.

                    Comment

                    Working...
                    X