Announcement

Collapse
No announcement yet.

Popular USB DWC3 Linux Driver Likely To "Never Be Finished" With Continued Adaptations

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

  • Popular USB DWC3 Linux Driver Likely To "Never Be Finished" With Continued Adaptations

    Phoronix: Popular USB DWC3 Linux Driver Likely To "Never Be Finished" With Continued Adaptations

    Greg Kroah-Hartman on Friday sent in the USB/Thunderbolt updates for the Linux 5.19 kernel that is seeing its merge window end today. With the USB updates, Greg had some remarks on the DWC3 Linux driver that will likely "never be finished" given that this USB IP is appearing in lots of hardware but not consistently being implemented and thus continuing to require a lot of adaptations on the driver side...

    https://www.phoronix.com/scan.php?pa...olt-Linux-5.19

  • #2
    This is one form of embrace, extend extinguish. Every vendor does things a bit different and supports their differences in corporate operating systems, and leaves the open ones with endless work.

    The day cannot come fast enough when Linux is the reference standard, with kernel implementing the standard, and the hardware adapts to that, not the other way around.
    Last edited by varikonniemi; 05 June 2022, 07:17 AM.

    Comment


    • #3
      Thats why Linux need to be implemented in a object oriented programming programming language.

      Simply:

      public class XyzDwc3Module extends DwcModule implements usbInterface { ... }

      and DwcModule never ever needs to be changed.

      But in Linux they want 70ies like C most time and most people they need to keep their own codebase in shape.

      Comment


      • #4
        Originally posted by camel_case View Post
        Thats why Linux need to be implemented in a object oriented programming programming language.

        Simply:

        public class XyzDwc3Module extends DwcModule implements usbInterface { ... }
        That's basically what every subsystem does, just with variant detection (either by probing hardware or firmware description) and explicit function pointers.

        Comment


        • #5
          Originally posted by camel_case View Post
          Thats why Linux need to be implemented in a object oriented programming programming language.
          I have a lot of reservations about using OO for things that you need to be able to easily reason about or where absolute top performance is required. OO encourages a lot of anti-patterns in my opinion. Objects are an okay way to describe process but they're an absolutely terrible way to model data for example. Not to mention that it's a lot harder to understand how it will translate to machine code after it's compiled. Something nice about using C is that it's at least feasible to understand what it's going to compile to, which is kind of important when working on something low-level like the kernel. High level abstractions like OO are better for business domain problems and one could argue that functional languages are superior when it comes to expressibility and encourage patterns (like pure functions,) that can make it far easier to understand what an application is supposed to do.

          I'll get off my soapbox now.

          Edit: Side note, you don't need OO for polymorphic dispatch.
          Last edited by jrdoane; 05 June 2022, 10:12 AM.

          Comment


          • #6
            Originally posted by jrdoane View Post

            I have a lot of reservations about using OO for things that you need to be able to easily reason about or where absolute top performance is required. OO encourages a lot of anti-patterns in my opinion. Objects are an okay way to describe process but they're an absolutely terrible way to model data for example. Not to mention that it's a lot harder to understand how it will translate to machine code after it's compiled. Something nice about using C is that it's at least feasible to understand what it's going to compile to, which is kind of important when working on something low-level like the kernel. High level abstractions like OO are better for business domain problems and one could argue that functional languages are superior when it comes to expressibility and encourage patterns (like pure functions,) that can make it far easier to understand what an application is supposed to do.

            I'll get off my soapbox now.
            Pretty much spot on! The fact that C and non-OO paradigms are used in the kernel is not 70's era. It is a design choice and highly necessary as when dealing with a kernel there is far more hand tuning of code then most other applications. OO is really nice to use in a lot of instances, but it can cause a pretty hefty penalty. I recently had to convert OO code to non-OO because of the performance penalty. To be honest it probably could have stayed at OO, but trying to figure out the convoluted performance issues would have taken much longer than just switching to a more functional oriented approach.

            Comment


            • #7
              While this article is interesting it's nothing remotely unique to the DWC3 hardware. DWC2 was the same, so was a nubmer of ethernet controllers. It's more than once that I've seen reverse engineer a piece of hardware, develop a driver for it from scratch only to find out--normally when submitting it for inclusion in the kernel--that it's just a variant of an existing controller which already has a driver and the new author just needs to add a variant to that driver and be done. So much lost effort all because the users of these IPs either don't know how to just use the IP or they are stealing some IP and try very hard to hide that fact. Given that a lot of the variants do things like scramble the register addresses or move status bits around in them, etc. it's pretty clear they're obfuscating things.

              Comment


              • #8
                The whole thing reminds me about the Linux sound subsystem and some drivers needing multiple quirks due to deviating from the HDA standard. C is well enough equipped for that, so OO isn't really needed. You just detect the device ID and then patch a few structs and function pointers here and there to accomodate for the different behavior.

                Comment


                • #9
                  Originally posted by willmore View Post
                  Given that a lot of the variants do things like scramble the register addresses or move status bits around in them, etc. it's pretty clear they're obfuscating things.
                  At the low level hardware designs, it is completely up to the designer to choose which specific GPIO lines (and addresses, and status bits) do what, and there is no right choice, just a choice. Typically within one company an engineering group responsible for (say) USB designs will do the same thing again and again the same way, but in a different company they will choose differently. And if a company buys the USB IP from another company for their next product things get different all over again. This mostly does not matter as the company supplies drivers for their devices for the OS's they wish to support, but while android may be a target OS, the company may not wish to invest in the overhead(s) of getting the driver into Linux mainline, and just shipping a working driver to their platform partners is much less overhead. If one wants to make contribution(s) to the Linux kernel more palatable, one needs a more stable API, and less discussions within a subsystem about exactly how the code formatting should be, and what the internal variable names should be (since all of those are unlikely, I don't expect things to get a lot better any time soon).
                  Last edited by CommunityMember; 05 June 2022, 12:13 PM.

                  Comment


                  • #10
                    Originally posted by CommunityMember View Post

                    At the low level hardware designs, it is completely up to the designer to choose which specific GPIO lines (and addresses, and status bits) do what, and there is no right choice, just a choice. Typically within one company an engineering group responsible for (say) USB designs will do the same thing again and again the same way, but in a different company they will choose differently. And if a company buys the USB IP from another company for their next product things get different all over again. This mostly does not matter as the company supplies drivers for their devices for the OS's they wish to support, but while android may be a target OS, the company may not wish to invest in the overhead(s) of getting the driver into Linux mainline, and just shipping a working driver to their platform partners is much less overhead. If one wants to make contribution(s) to the Linux kernel more palatable, one needs a more stable API, and less discussions within a subsystem about exactly how the code formatting should be, and what the internal variable names should be (since all of those are unlikely, I don't expect things to get a lot better any time soon).
                    I would disagree because we see many public uses of these IP which are consistent and require almost no kludges. I'm thinking of NXP specifically who has nice documentation for thier parts and they lay everything out on the table. You're right when you say the designer using these IP can route address and data lines any way they want to, but that's the point. There is a standard layout for them, but if a designer choses to route them differently, they are making a choice to do things differently. I would argue that the motivation isn't some kind of short term routing convenience, but an intententional attempt to hide the (mostly unlicensed) IP they're using.

                    WRT the driver situation. I really don't care what's easier for a vendor. I'm in the open software community and their being a bad actor in that space is a problem. It may be harder to mainline a driver (or variant) than to just ship some hacked up thing in a BSP, but how many times do you have to do that before it would have been easier to just mainline it? Especially if it's a variant of an existing driver, all you'd need to do is add the register remapping function and you'd be done. But that would make it very clear what IP you were using, wouldn't it?

                    If your arguement is the old "Why take the effort to write good code once when I can write bad code dozens of times?" Then I don't think we're going to agree.

                    Comment

                    Working...
                    X