add firmware 1594EMS1.113 for Prestige 16 Studio A13VE

[vicajilau]

close #77

---

Adds EC firmware version 1594EMS1.113 to ALLOWED_FW_G2_1.

This is the same laptop model already supported via 1594EMS1.109
(#77 / #78), just a newer EC revision. CONF_G2_1 is reused unchanged.

Device

Model	MSI Prestige 16 Studio A13VE
Board	MS-1594
BIOS	E1594IMS.115
EC firmware	1594EMS1.113 (release date 2024-10-07)

For reference, the existing .109 entry was submitted with BIOS
E1594IMS.111 in #77.

Verification

Tested by loading the module with firmware=1594EMS1.109 and checking
that every attribute returned correct data before writing anything.

Reads, all consistent with the actual state of the machine:

• fw_version → 1594EMS1.113, read correctly from the EC
• fw_release_date → 2024-10-07, matches the DMI bios_date (10/07/2024)
• charge_control_end_threshold / start_threshold → 100 / 90 (factory default)
• cpu/realtime_temperature 53 °C, gpu/realtime_temperature 46 °C — plausible at idle
• cpu/realtime_fan_speed 50, gpu/realtime_fan_speed 60
• webcam on, webcam_block off — matches the built-in camera
• shift_mode comfort, fan_mode auto, cooler_boost off, super_battery off
  — all valid values from the corresponding available_* lists
• fn_key right, win_key left

No out-of-range or garbage values, which indicates the register map of
the .109 profile is unchanged on .113.

Writes, after the reads checked out:

• charge_control_end_threshold set to 80 → accepted, start_threshold
  adjusted to 70 automatically
• Survives a reboot with options msi-ec firmware=1594EMS1.109 in
  /etc/modprobe.d/
• UPower reports ChargeThresholdSupported: true and GNOME Settings
  exposes the charge limit control

EC memory dump

Taken with ec_sys (read-only) while the charge limit was set to 80%,
so 0xd7 reads d0 (0x80 | 80) rather than the factory 80.

     | _0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _a _b _c _d _e _f
-----+------------------------------------------------
0x0_ | 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1_ | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2_ | 00 00 00 00 00 00 00 00 0a 05 00 00 08 2c 0b 4b
0x3_ | 07 09 00 0d 01 00 50 81 a0 14 60 3b 10 02 e0 00
0x4_ | 00 00 62 00 20 0f 00 00 cb 0e 6c 3f fc 0b 00 00
0x5_ | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x6_ | 00 00 00 00 00 00 00 00 35 00 3c 46 50 55 5a 5f
0x7_ | 64 32 00 32 37 46 50 82 82 46 14 08 08 03 03 03
0x8_ | 2d 00 2d 3c 4b 50 55 57 5f 3c 00 3c 50 82 82 82
0x9_ | 82 00 03 03 03 03 03 02 06 14 7d 02 00 7d 2e 00
0xa_ | 31 35 39 34 45 4d 53 31 2e 31 31 33 31 30 30 37
0xb_ | 32 30 32 34 31 33 3a 32 30 3a 30 36 00 00 00 08
0xc_ | 00 00 07 35 00 00 19 00 00 84 00 85 00 00 00 00
0xd_ | 00 00 c1 83 0d 00 05 d0 00 00 00 00 00 06 00 00
0xe_ | e2 00 00 20 0f 00 00 c1 00 00 00 00 00 d2 01 00
0xf_ | 00 00 70 00 2d 38 00 00 64 00 00 00 00 01 01 00

Compared against the .109 dump in #77, the layout is identical:

• 0xa0 holds the firmware string in ASCII (1594EMS1.113 + 10072024
  • 13:20:06), matching the fw_release_date reported by the driver
• 0xd7 is the charge control register, as CONF_G2_1 expects
• Remaining differences are current settings, not layout changes