Announcement

Collapse
No announcement yet.

Linux 5.13 Merge Window Kicks Off With Microsoft Surface Improvements, Gigabyte WMI Driver

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

  • Linux 5.13 Merge Window Kicks Off With Microsoft Surface Improvements, Gigabyte WMI Driver

    Phoronix: Linux 5.13 Merge Window Kicks Off With Microsoft Surface Improvements, Gigabyte WMI Driver

    Following yesterday's Linux 5.12 release the merge window for Linux 5.13 is officially open. One of the first pull requests of this new merge window is for the platform-drivers-x86 updates, which primarily encompass Intel/AMD Linux laptop driver support improvements and other related x86 platform drivers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by Hans de Goede
    dell-wmi-sysman:
    […]
    - Cleanup create_attributes_level_sysfs_files()
    - Make sysman_init() return -ENODEV of the interfaces are not found
    - Cleanup sysman_init() error-exit handling
    - Fix release_attributes_data() getting called twice on init_bios_attributes() failure
    - Make it safe to call exit_foo_attributes() multiple times
    - Fix possible NULL pointer deref on exit
    - Fix crash caused by calling kset_unregister twice
    Hm? I am confused. Those commits have been present in 5.11.11 release while 5.12 was in development, so I'd assume they should be present in the kernel once 5.13 development is started. Are they not? Were they accidentally missed from 5.12 development cycle, or what happened?

    Comment


    • #3
      Will the new Gigabyte WMI driver replace the it87 module I have added to my X570 AORUS ELITE?
      Works great on Gigabyte X570 Aorus Master with a 3900x, bios F31b. Arch with kernel 5.10.11, and setting the modprobe flag options it87 ignore_resource_conflict=1 (don’t think this is actually necessary for my motherboard).modinfo it87 reports: filename: /lib/modules/5.10.11-arch1-1/kernel/drivers/hwmon/it87.ko.xz version: v1.0-52-g2b8b4fe license: GPL description: IT8705F/IT871xF/IT872xF hardware monitoring driver author: Chris Gauthron, Jean Delvare

      Comment


      • #4
        gigabyte-wmi:
        - add support for B550M AORUS PRO-P
        - add X570 AORUS ELITE

        I pulled this from


        I wonder if that means I disable the it87 module I added

        Comment


        • #5
          Hi,

          Originally posted by Hi-Angel View Post

          Hm? I am confused. Those commits have been present in 5.11.11 release while 5.12 was in development, so I'd assume they should be present in the kernel once 5.13 development is started. Are they not? Were they accidentally missed from 5.12 development cycle, or what happened?
          These commits fix some Dell Latitudes not booting. So they were cherry picked from my for-next branch and send out in a post 5.12-rc2 fixes pull-req, which landed them in 5.12, after which they got added (cherry picked) to 5.11.11. The "git pull-req" for this pull-req used 5.12-rc2 as start (since that was the base for my for-next branch this cycle). So the commits which got added as fixes to 5.12 post 5.12-rc2 also show up in the short-log here.

          I hope this helps explain what is going on here.

          Regards,

          Hans

          Comment


          • #6
            Oh, I think I see. So, the (general I presume?) workflow is: fixes land first to a branch targeting the next to-be-developed kernel (which was 5.13 in this case), then they get cherry-picked to older versions where they matter, including the current in-development kernel (which was 5.12 here).

            Originally posted by hansdegoede View Post
            Hi,



            These commits fix some Dell Latitudes not booting. So they were cherry picked from my for-next branch and send out in a post 5.12-rc2 fixes pull-req, which landed them in 5.12, after which they got added (cherry picked) to 5.11.11. The "git pull-req" for this pull-req used 5.12-rc2 as start (since that was the base for my for-next branch this cycle). So the commits which got added as fixes to 5.12 post 5.12-rc2 also show up in the short-log here.

            I hope this helps explain what is going on here.

            Regards,

            Hans

            Comment

            Working...
            X