{"push_id":2495055257,"size":72,"distinct_size":72,"ref":"refs/heads/master","head":"983909f8cd294f313d24a8d1af9b7bafc3593a08","before":"41d66bc07762b3c2ade937ee861b636ecfc1221c","commits":[{"sha":"0e962d49e0974ec13fc052fa837e301f60dbe258","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad Mixx 320\n\nThe Lenovo Ideapad Mixx 320 laptop uses a portrait LCD panel, add a\nquirk for this.\n\nWhile at it instead of duplicating the same drm_dmi_panel_orientation_data\nfor 3 laptops add a generic lcd800x1280_rightside_up orientation_data and\nuse that for all 3 (including the new Mixx 320 entry).\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/0e962d49e0974ec13fc052fa837e301f60dbe258"},{"sha":"3e0a89c956c076654c0cf0fb5cf3c7cd51498624","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"efi: Export boot-services code and data as debugfs-blobs\n\nSometimes it is useful to be able to dump the efi boot-services code and\ndata. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi,\nbut only if efi=debug is passed on the kernel-commandline as this requires\nnot freeing those memory-regions, which costs 20+ MB of RAM.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\n---\nChanges in v2:\n-Do not call pr_err on debugfs call failures","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/3e0a89c956c076654c0cf0fb5cf3c7cd51498624"},{"sha":"5c9563f2814c16ccae8fe83451de5a9de8e4895d","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"efi: Add embedded peripheral firmware support\n\nJust like with PCI options ROMs, which we save in the setup_efi_pci*\nfunctions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself\nsometimes may contain data which is useful/necessary for peripheral drivers\nto have access to.\n\nSpecifically the EFI code may contain an embedded copy of firmware which\nneeds to be (re)loaded into the peripheral. Normally such firmware would be\npart of linux-firmware, but in some cases this is not feasible, for 2\nreasons:\n\n1) The firmware is customized for a specific use-case of the chipset / use\nwith a specific hardware model, so we cannot have a single firmware file\nfor the chipset. E.g. touchscreen controller firmwares are compiled\nspecifically for the hardware model they are used with, as they are\ncalibrated for a specific model digitizer.\n\n2) Despite repeated attempts we have failed to get permission to\nredistribute the firmware. This is especially a problem with customized\nfirmwares, these get created by the chip vendor for a specific ODM and the\ncopyright may partially belong with the ODM, so the chip vendor cannot\ngive a blanket permission to distribute these.\n\nThis commit adds support for finding peripheral firmware embedded in the\nEFI code and making this available to peripheral drivers through the\nstandard firmware loading mechanism.\n\nNote we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end\nof start_kernel(), just before calling rest_init(), this is on purpose\nbecause the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for\nearly_memremap(), so the check must be done after mm_init(). This relies\non EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services()\nis called, which means that this will only work on x86 for now.\n\nReported-by: Dave Olsthoorn <dave@bewaar.me>\nSuggested-by: Peter Jones <pjones@redhat.com>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\n---\nChanges in v2:\n-Rebased on driver-core/driver-core-next\n-Add documentation describing the EFI embedded firmware mechanism to:\n Documentation/driver-api/firmware/request_firmware.rst\n-Add a new EFI_EMBEDDED_FIRMWARE Kconfig bool and only build the embedded\n fw support if this is set. This is an invisible option which should be\n selected by drivers which need this\n-Remove the efi_embedded_fw_desc and dmi_system_id-s for known devices\n from the efi-embedded-fw code, instead drivers using this are expected to\n export a dmi_system_id array, with each entries' driver_data pointing to a\n efi_embedded_fw_desc struct and register this with the efi-embedded-fw code\n-Use kmemdup to make a copy instead of efi_mem_reserve()-ing the firmware,\n this avoids us messing with the EFI memmap and avoids the need to make\n changes to efi_mem_desc_lookup()\n-Make the firmware-loader code only fallback to efi_get_embedded_fw() if the\n passed in device has the \"efi-embedded-firmware\" device-property bool set\n-Skip usermodehelper fallback when \"efi-embedded-firmware\" device-property\n is set\n\nChanges in v3:\n-Fix the docs using \"efi-embedded-fw\" as property name instead of\n \"efi-embedded-firmware\"","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/5c9563f2814c16ccae8fe83451de5a9de8e4895d"},{"sha":"d010fd4197d2eae3d0313f673426fef30cf8edcb","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"platform/x86: Rename silead_dmi to touchscreen_dmi\n\nNot only silead touchscreens need some extra info not available in the\nACPI tables to work properly. X86 devices with a Chipone ICN8505 chip also\nneed some DMI based extra configuration.\n\nThere is no reason to have separate dmi config code per touchscreen\ncontroller vendor. This commit renames silead_dmi to a more generic\ntouchscreen_dmi name (and Kconfig option) in preparation of adding\ninfo for tablets with an ICN8505 based touchscreen.\n\nNote there are no functional changes all code changes are limited to\nremoving references to silead where these are no longer applicable.\n\nAcked-by: Andy Shevchenko <andy.shevchenko@gmail.com>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/d010fd4197d2eae3d0313f673426fef30cf8edcb"},{"sha":"57cdd19c2fbfc35738e054f6c857a10a184ab228","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"platform/x86: touchscreen_dmi: Add EFI embedded firmware info support\n\nSofar we have been unable to get permission from the vendors to put the\nfirmware for touchscreens listed in touchscreen_dmi in linux-firmware.\n\nSome of the tablets with such a touchscreen have a touchscreen driver, and\nthus a copy of the firmware, as part of their EFI code.\n\nThis commit adds the necessary info for the new EFI embedded-firmware code\nto extract these firmwares, making the touchscreen work OOTB without the\nuser needing to manually add the firmware.\n\nAcked-by: Andy Shevchenko <andy.shevchenko@gmail.com>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/57cdd19c2fbfc35738e054f6c857a10a184ab228"},{"sha":"d78c3999c8676ac2b91725925984e355bbed5967","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tablet\n\nAdd touchscreen info for the Chuwi Vi8 Plus tablet. This tablet uses a\nChipone ICN8505 touchscreen controller, with the firmware used by the\ntouchscreen embedded in the EFI firmware.\n\nAcked-by: Andy Shevchenko <andy.shevchenko@gmail.com>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/d78c3999c8676ac2b91725925984e355bbed5967"},{"sha":"fa01f4a23788e8f98766545583c57c957b4c6545","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"ACPI / video: Only default only_lcd to true on Win8-ready _desktops_\n\nCommit 5928c281524f (\"ACPI / video: Default lcd_only to true on Win8-ready\nand newer machines\") made only_lcd default to true on all machines where\nacpi_osi_is_win8() returns true, including laptops.\n\nThe purpose of this is to avoid the bogus / non-working acpi backlight\ninterface which many newer BIOS-es define on desktop machines.\n\nBut this is causing a regression on some laptops, specifically on the\nDell XPS 13 2013 model, which does not have the LCD flag set for its\nfully functional ACPI backlight interface.\n\nRather then DMI quirking our way out of this, this commits changes the\nlogic for setting only_lcd to true, to only do this on machines with\na desktop (or server) dmi chassis-type.\n\nNote that we cannot simply only check the chassis-type and not register\nthe backlight interface based on that as there are some laptops and\ntablets which have their chassis-type set to \"3\" aka desktop. Hopefully\nthe combination of checking the LCD flag, but only on devices with\na desktop(ish) chassis-type will avoid the needs for DMI quirks for this,\nor at least limit the amount of DMI quirks which we need to a minimum.\n\nCc: James Hogan <jhogan@kernel.org>\nReported-and-tested-by: James Hogan <jhogan@kernel.org>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/fa01f4a23788e8f98766545583c57c957b4c6545"},{"sha":"4ba2b1f247a28b9caea9d8b3e31d5471bc4ac3bd","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"ACPI / AC: Remove initializer for unused ident dmi_system_id\n\nThe ac.c code does not use the dmi_system_id ident member, so there is\nno need to initialize it. This saves us storing the unused \"thinkpad e530\"\nstring as const data.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/4ba2b1f247a28b9caea9d8b3e31d5471bc4ac3bd"},{"sha":"46796b9f9718398e33600834cf37bf5671537f1a","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"ACPI / battery: Remove initializer for unused ident dmi_system_id\n\nThe battery code does not use the dmi_system_id ident member, so there is\nno need to initialize it. This saves us storing the unused strings as\nas const data.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/46796b9f9718398e33600834cf37bf5671537f1a"},{"sha":"93ec2b3b083a80d8188764a065b7202ee4a49c2b","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"ACPI / battery: Add handling for devices which wrongly report discharging state\n\nOn quite a few devices the battery code in the ACPI tables is buggy and\nfirst checks the charging status bits of the charger-IC, and if those\nreport not charging it will report discharging, without looking at the\npresence of AC power or at the battery dis(charge) current from the\nfuel-gauge.\n\nThis causes the wrong status to be reported for the battery in the\nfollowing quite common scenario:\n\n1) Plug in charger while battery is say half full, battery starts\ncharging, charging state bits indicate: pre-charge or fast-charge,\nACPI reported battery status is ok\n\n2) When fully charged charging state bits indicate: end-of-charge,\nACPI reported battery status is ok\n\n3) unplug the charger, wait 1 minute, replug. Now the battery voltage is\nstill above the start-charging threshold, so the charger will not start\ncharging to avoid wrecking the battery by repeatedly recharging the last 1%\ncapacity. The charger IC charging state bits now are all 0 (not-charging)\nand the broken ACPI code wrongly translate this to \"discharging\" and ends\nup setting the ACPI_BATTERY_STATE_DISCHARGING bit in its state field.\n\nReporting this \"not charging\" state as discharging is confusing for users,\nmaking the user think his adapter/power-brick is broken or not properly\nplugged in.\n\nThis commit adds a helper for handling the ACPI_BATTERY_STATE_DISCHARGING\nstate. This helper checks if we're an AC and the current going out of the\nbattery is 0 and in that case reports a status of \"not charging\" to\nuserspace rather then \"discharging\".\n\nThis replaces commit c68f0676ef7d (\"ACPI / battery: Add quirk for Asus\nGL502VSK and UX305LA\"), a previous fix for this which was reverted.\n\nCc: Kai-Heng Feng <kai.heng.feng@canonical.com>\nReviewed-by: Daniel Drake <drake@endlessm.com>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\n---\nChanges in v2:\n-Report \"not charging\" rather then \"full\"","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/93ec2b3b083a80d8188764a065b7202ee4a49c2b"},{"sha":"00d798ff07fad976710e19fc4013999a07087304","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"ACPI / battery: Ignore AC state in handle_discharging on systems where it is broken\n\nOn some devices the \"AC\" interface ACPI AML code uses the exact same broken\nlogic which is causing the battery code to wrongly report discharging to\ndetermine the \"AC\" state. Specifically the ACPI AML code is checking the\ncharging status bits of the charger-IC rather then the vbus present or\npower-good status bits.\n\nThis makes our workaround for devices which wrongly report discharging when\nplugged into AC while the charge is above the start charging threshold not\nwork on these devices.\n\nThis commit adds a battery_ac_is_broken flag and when that is set it skips\nthe power_supply_is_system_supplied() check in the workaround fixing this.\n\nThis flag gets set by a DMI quirk selected by systems where we know the AC\nAML code is broken in this way *and* the rate_now value can be trusted.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/00d798ff07fad976710e19fc4013999a07087304"},{"sha":"5a129e8a000545ce90c2998c0027aff81b8fb58f","author":{"name":"Carlo Caione","email":"69088b01848c9e171296e8a6c10279802a3a8a84@endlessm.com"},"message":"ACPI / Battery: Add quirk to avoid checking for PMIC with native driver\n\nWith commit dccfae6d4f4c (\"ACPI / battery: Add a blacklist with PMIC ACPI\nHIDs with a native battery driver\") a blacklist was introduced to avoid\nusing the ACPI drivers for the battery when a native PMIC driver was\nalready present. While this is in general a good idea (because of broken\nDSDT or proprietary and undocumented ACPI opregions for the ACPI battery\ndevices) there are some Cherry Trail devices which use a separate FG\ncontroller despite the AXP288 having a builtin FG.\n\nThe net effect of blacklisting the ACPI drivers is that on these devices\nthe battery reporting is broken since the AXP288 PMIC FG bits are not\nactually used on this hardware.\n\nThis commit adds a battery_do_not_check_pmic quirk for this and sets\nthis on the 2 devices currently known to use a separate FG controller,\nthe ECS EF20EA and the Lenovo Ideapad Miix 320.\n\nSigned-off-by: Carlo Caione <carlo@endlessm.com>\n[hdegoede@redhat.com: Merge the quirk handling and the adding of the dmi\n table entry into 1 commit, add a second dmi entry for the Miix 320]\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\n---\nChanges in v2 (Carlo Caione):\n-Use \"ACPI / Battery\" subject prefix\n-Split ACPI changes into 2 commits\n\nChanges in v3 (Hans de Goede):\n-Redo the patch split putting all changes to 1 file in a single commit\n-Add a second dmi entry for the Lenovo Ideapad Miix 320","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/5a129e8a000545ce90c2998c0027aff81b8fb58f"},{"sha":"d15f252dcf814f61acf9ef81e99ca01e9d35057e","author":{"name":"Carlo Caione","email":"69088b01848c9e171296e8a6c10279802a3a8a84@endlessm.com"},"message":"ACPI / AC: Add quirk to avoid checking for PMIC with native driver\n\nWith commit af3ec837b84b (\"ACPI / AC: Add a blacklist with PMIC ACPI HIDs\nwith a native charger driver\") a blacklist was introduced to avoid using\nthe ACPI drivers for AC when a native PMIC driver was already present.\nWhile this is in general a good idea (because of broken DSDT or proprietary\nand undocumented ACPI opregions for the ACPI AC devices) there are some\nCherry Trail devices which use a separate charger controller despite the\nAXP288 having a builtin charger.\n\nThe net effect of blacklisting the ACPI drivers is that on these devices\nthe AC reporting is broken since the AXP288 PMIC charger bits are not\nactually used on this hardware.\n\nThis commit adds an ac_do_not_check_pmic quirk for this and sets this on\nthe 2 devices currently known to use a separate FG controller,\nthe ECS EF20EA and the Lenovo Ideapad Miix 320.\n\nSigned-off-by: Carlo Caione <carlo@endlessm.com>\n[hdegoede@redhat.com: Merge the quirk handling and the adding of the dmi\n table entry into 1 commit, add a second dmi entry for the Miix 320]\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\n---\nChanges in v2 (Carlo Caione):\n-Use \"ACPI / AC\" subject prefix\n-Split ACPI changes into 2 commits\n\nChanges in v3 (Hans de Goede):\n-Redo the patch split putting all changes to 1 file in a single commit\n-Add a second dmi entry for the Lenovo Ideapad Miix 320","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/d15f252dcf814f61acf9ef81e99ca01e9d35057e"},{"sha":"16dcb7bc8f909e4657524ad9220c96c679ccc3fc","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"power: supply: axp288_charger: Do not bind when the charge function is not used\n\nSome devices with an AXP288 PMIC do not have a battery at all, or use\nexternal charger and fuelgauge ICs instead of the AXP288 builtin\nfunctionality.\n\nOn such devices we should not bind to the charge function to avoid\nexporting a non working power_supply class device.\n\nCc: Carlo Caione <carlo@endlessm.com>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/16dcb7bc8f909e4657524ad9220c96c679ccc3fc"},{"sha":"5d04a32ad86b7007bdd3fca886c05b8a8d86efc4","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"power: supply: axp288_fuelguage: Do not bind when the fg function is not used\n\nSome devices with an AXP288 PMIC do not have a battery at all, or use\nexternal charger and fuelgauge ICs instead of the AXP288 builtin\nfunctionality.\n\nOn such devices we should not bind to the fuelgauge function to avoid\nexporting a non working power_supply class device.\n\nThis also avoids the following errors repeating over and over again in\ndmesg:\n\naxp288_fuel_gauge axp288_fuel_gauge: capacity measurement not valid\naxp288_fuel_gauge axp288_fuel_gauge: Error 0xe2 contents not valid\npower_supply axp288_fuel_gauge: driver failed to report 'charge_now'\nproperty: -6\n\nCc: Carlo Caione <carlo@endlessm.com>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/5d04a32ad86b7007bdd3fca886c05b8a8d86efc4"},{"sha":"4686a3e2ccc3bbaafbf1a2215d6f0280c03e366f","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"ASoC: Intel: Disable SND_SOC_INTEL_BAYTRAIL when SND_SST_ATOM_HIFI2_PLATFORM is enabled\n\nThe sound/soc/intel/common/sst-acpi.c code only tries to load the\n\"baytrail-pcm-audio\" driver (and supporting board drivers) when\nSND_SST_ATOM_HIFI2_PLATFORM is not enabled, since otherwise these\nare handled by snd-soc-sst-atom-hifi2-platform.ko.\n\nSince these thus will never be used when SND_SST_ATOM_HIFI2_PLATFORM is\nenabled, building these drivers when it is enabled is useless.\n\nAdd a Kconfig dependency to reflect this, so that SND_SOC_INTEL_BAYTRAIL\ncannot be enabled when SND_SST_ATOM_HIFI2_PLATFORM is also enabled.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/4686a3e2ccc3bbaafbf1a2215d6f0280c03e366f"},{"sha":"738b8a9bab7b32bc6ac0ec725b92754ee0acf491","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"pwm: lpss: platform: Save/restore the ctrl register over a suspend/resume\n\nOn some devices the contents of the ctrl register get lost over a\nsuspend/resume and the PWM comes back up disabled after the resume.\n\nThis is seen on some Bay Trail devices with the PWM in ACPI enumerated\nmode, so it shows up as a platform device instead of a PCI device.\n\nIf we still think it is enabled and then try to change the duty-cycle\nafter this, we end up with a \"PWM_SW_UPDATE was not cleared\" error and\nthe PWM is stuck in that state from then on.\n\nThis commit adds suspend and resume pm callbacks to the pwm-lpss-platform\ncode, which save/restore the ctrl register over a suspend/resume, fixing\nthis.\n\nNote that:\n\n1) There is no need to do this over a runtime suspend, since we\nonly runtime suspend when disabled and then we properly set the enable\nbit and reprogram the timings when we re-enable the PWM.\n\n2) This may be happening on more systems then we realize, but has been\ncovered up sofar by a bug in the acpi-lpss.c code which was save/restoring\nthe regular device registers instead of the lpss private registers due to\nlpss_device_desc.prv_offset not being set. This is fixed by a later patch\nin this series.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/738b8a9bab7b32bc6ac0ec725b92754ee0acf491"},{"sha":"a414321b8db732d8d051f4dd43cea1de1e8f8e81","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"ACPI / LPSS: Add missing prv_offset setting for byt/cht PWM devices\n\nThe LPSS PWM device on on Bay Trail and Cherry Trail devices has a set\nof private registers at offset 0x800, the current lpss_device_desc for\nthem already sets the LPSS_SAVE_CTX flag to have these saved/restored\nover device-suspend, but the current lpss_device_desc was not setting\nthe prv_offset field, leading to the regular device registers getting\nsaved/restored instead.\n\nThis is causing the PWM controller to no longer work, resulting in a black\nscreen,  after a suspend/resume on systems where the firmware clears the\nAPB clock and reset bits at offset 0x804.\n\nThis commit fixes this by properly setting prv_offset to 0x800 for\nthe PWM devices.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/a414321b8db732d8d051f4dd43cea1de1e8f8e81"},{"sha":"fbe781e9a19152feb97f263167c8d91f831227ff","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"ACPI / LPSS: Only call pwm_add_table() for Bay Trail PWM if PMIC HRV is 2\n\nThe Point of View mobii wintab p800w Bay Trail tablet comes with a Crystal\nCove PMIC, yet uses the LPSS PWM for backlight control, rather then the\nCrystal Cove's PWM, so we need to call pwm_add_table() to add a\npwm_backlight mapping for the LPSS pwm despite there being an INT33FD\nACPI device present.\n\nOn all Bay Trail devices the _HRV object of the INT33FD ACPI device\nwill normally return 2, to indicate the Bay Trail variant of the CRC\nPMIC is present, except on this tablet where _HRV is 0xffff. I guess this\nis a hack to make the windows Crystal Cove PWM driver not bind.\n\nOut of the 44 DSTDs with an INT33FD device in there which I have (from\ndifferent model devices) only the pov mobii wintab p800w uses 0xffff for\nthe HRV.\n\nThe byt_pwm_setup code calls acpi_dev_present to check for the presence\nof a INT33FD ACPI device which indicates that a CRC PMIC is present and\nif the INT33FD ACPI device is present then byt_pwm_setup will not add\na pwm_backlight mapping for the LPSS pwm, so that the CRC PWM will get\nused instead.\n\nacpi_dev_present has a hrv parameter, this commit make us pass 2 instead\nof -1, so that things still match on normal tablets, but on this special\ncase with its _HRV of 0xffff, the check will now fail so that the\npwm_backlight mapping for the LPSS pwm gets added fixing backlight\nbrightness control on this device.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/fbe781e9a19152feb97f263167c8d91f831227ff"},{"sha":"e1b2a625445f3abbfc1b191380cf2b34181711ff","author":{"name":"Hans de Goede","email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com"},"message":"HID: intel_ish-hid: Move header size check to inside the loop\n\nWith the headersize check outside of the loop, the second time through\nthe loop the: \"payload_len = recv_msg->hdr.size;\" statement may deref\nrecv_msg while it is pointing outside of our input buffer.\n\nMove the headersize check to inside the loop to fix this.\n\nReviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>","distinct":true,"url":"https://api.github.com/repos/jwrdegoede/linux-sunxi/commits/e1b2a625445f3abbfc1b191380cf2b34181711ff"}]}
{"actor":{"display_login":"jwrdegoede"}}