- 19 Jul, 2022 11 commits
-
-
Miaoqian Lin authored
of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 327156c5 ("mfd: max77620: Add core driver for MAX77620/MAX20024") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220601043222.64441-1-linmq006@gmail.com
-
Lukas Bulwahn authored
Commit b38213c6 ("dt-bindings: mfd: maxim,max77693: Convert to dtschema") converts max77693.txt to maxim,max77693.yaml and adjusts the file entry in MAINTAINERS accordingly. Unfortunately, the merge commit afb67df3 ("Merge branches [...] into ibs-for-mfd-merged") resolves some conflict in MAINTAINERS in such a way that the file entry for the converted text file max77693.txt, removed in the commit above, is added back into MAINTAINERS. Remove the file entry to this converted text file in MAXIM PMIC AND MUIC DRIVERS FOR EXYNOS BASED BOARDS. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Instead of explicit casting, use %pa specifier to format the variable of resource_size_t type. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Uwe Kleine-König authored
The driver never calls the disable callback, so drop the member from the platform struct and all callbacks from the actual platform datas. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
None of the in-tree instantiations of struct t7l66xb_platform_data provides a disable callback. So better don't dereference this function pointer unconditionally. As there is no user, drop it completely instead of calling it conditional. This is a preparation for making platform remove callbacks return void. Fixes: 1f192015 ("mfd: driver for the T7L66XB TMIO SoC") Signed-off-by:
-
Uwe Kleine-König authored
Up to now asic3_gpio_remove() returns zero unconditionally. This makes it easier to see in the caller that there is no error to handle. This is a preparation for making platform remove callbacks return void. Signed-off-by:
-
Andy Shevchenko authored
The actual status of the code is Supported. Reported-by:
Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by:
-
Rahul T R authored
Add a pattern property for clock-controller, also update the example with a clock-controller node Signed-off-by:
Rahul T R <r-ravikumar@ti.com> Reviewed-by:
-
Conor Dooley authored
Convert the dt binding for the da9063/da9063l to yaml. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Luca Ceresoli authored
My Bootlin address is preferred from now on. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by:
Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by:
-
Lee Jones authored
Merge branches 'ib-mfd-acpi-for-rafael-5.20', 'ib-mfd-edac-i2c-leds-pinctrl-platform-watchdog-5.20' and 'ib-mfd-soc-bcm-5.20' into ibs-for-mfd-merged
-
- 14 Jul, 2022 12 commits
-
-
Henning Schild authored
On Apollo Lake the pinctrl drivers will now come up without ACPI. Use that instead of open coding it. Create a new driver for that which can later be filled with more GPIO based models, and which has different dependencies. Signed-off-by:
Henning Schild <henning.schild@siemens.com> Signed-off-by:
Lee Jones <lee@kernel.org>
-
Henning Schild authored
The two drivers that used to use this have been switched over to the common P2SB accessor, so this code is not needed any longer. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Henning Schild authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
-
Henning Schild authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Andy Shevchenko authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Andy Shevchenko authored
The driver uses rather voodoo kind of castings and I/O accessors. Replace it with proper __iomem annotation and readl()/readq() calls. Signed-off-by:
-
Andy Shevchenko authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Acked-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Tan Jui Nee authored
Add support for non-ACPI systems, such as system that uses Advanced Boot Loader (ABL) whereby a platform device has to be created in order to bind with pin control and GPIO. At the moment, Intel Apollo Lake In-Vehicle Infotainment (IVI) system requires a driver to hide and unhide P2SB to lookup P2SB BAR and pass the PCI BAR address to GPIO. Signed-off-by:
Tan Jui Nee <jui.nee.tan@intel.com> Co-developed-by:
-
Andy Shevchenko authored
Instead of open coding p2sb_bar() functionality we are going to use generic library. There is one more user en route. This is more than just a clean-up. It also fixes a potential issue seen when SPI BAR is 64-bit. The current code works if and only if the PCI BAR of the hidden device is inside 4G address space. In case when firmware decides to go above 4G, we will get a wrong address. Signed-off-by:
-
Andy Shevchenko authored
Factor out duplicate code to lpc_ich_enable_spi_write() helper function. Signed-off-by:
-
Andy Shevchenko authored
In some cases we may get a platform device that has ACPI companion which is different to the pin control described in the ACPI tables. This is primarily happens when device is instantiated by board file. In order to allow this device being enumerated, refactor intel_pinctrl_get_soc_data() to check the matching data instead of ACPI companion. Reported-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
-
Jonathan Yong authored
SoC features such as GPIO are accessed via a reserved MMIO area, we don't know its address but can obtain it from the BAR of the P2SB device, that device is normally hidden so we have to temporarily unhide it, read address and hide it back. There are already a few users and at least one more is coming which require an access to Primary to Sideband (P2SB) bridge in order to get IO or MMIO BAR hidden by BIOS. Create a library to access P2SB for x86 devices in a unified way. Background information ====================== Note, the term "bridge" is used in the documentation and it has nothing to do with a PCI (host) bridge as per the PCI specifications. The P2SB is an interesting device by its nature and hardware design. First of all, it has several devices in the hardware behind it. These devices may or may not be represented as ACPI devices by a firmware. It also has a hardwired (to 0s) the least significant bits of the base address register which is represented by the only 64-bit BAR0. It means that OS mustn't reallocate the BAR. On top of that in some cases P2SB is represented by function 0 on PCI slot (in terms of B:D.F) and according to the PCI specification any other function can't be seen until function 0 is present and visible. In the PCI configuration space of P2SB device the full 32-bit register is allocated for the only purpose of hiding the entire P2SB device. As per [3]: 3.1.39 P2SB Control (P2SBC)—Offset E0h Hide Device (HIDE): When this bit is set, the P2SB will return 1s on any PCI Configuration Read on IOSF-P. All other transactions including PCI Configuration Writes on IOSF-P are unaffected by this. This does not affect reads performed on the IOSF-SB interface. This doesn't prevent MMIO accesses, although preventing the OS from assigning these addresses. The firmware on the affected platforms marks the region as unusable (by cutting it off from the PCI host bridge resources) as depicted in the Apollo Lake example below: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0070-0x0077] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] pci_bus 0000:00: root bus resource [mem 0x7c000001-0x7fffffff window] pci_bus 0000:00: root bus resource [mem 0x7b800001-0x7bffffff window] pci_bus 0000:00: root bus resource [mem 0x80000000-0xcfffffff window] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xefffffff window] pci_bus 0000:00: root bus resource [bus 00-ff] The P2SB 16MB BAR is located at 0xd0000000-0xd0ffffff memory window. The generic solution ==================== The generic solution for all cases when we need to access to the information behind P2SB device is a library code where users ask for necessary resources by demand and hence those users take care of not being run on the systems where this access is not required. The library provides the p2sb_bar() API to retrieve the MMIO of the BAR0 of the device from P2SB device slot. P2SB unconditional unhiding awareness ===================================== Technically it's possible to unhide the P2SB device and devices on the same PCI slot and access them at any time as needed. But there are several potential issues with that: - the systems were never tested against such configuration and hence nobody knows what kind of bugs it may bring, especially when we talk about SPI NOR case which contains Intel FirmWare Image (IFWI) code (including BIOS) and already known to be problematic in the past for end users - the PCI by its nature is a hotpluggable bus and in case somebody attaches a driver to the functions of a P2SB slot device(s) the end user experience and system behaviour can be unpredictable - the kernel code would need some ugly hacks (or code looking as an ugly hack) under arch/x86/pci in order to enable these devices on only selected platforms (which may include CPU ID table followed by a potentially growing number of DMI strings The future improvements ======================= The future improvements with this code may go in order to gain some kind of cache, if it's possible at all, to prevent unhiding and hiding many times to take static information that may be saved once per boot. Links ===== [1]: https://lab.whitequark.org/notes/2017-11-08/accessing-intel-ich-pch-gpios/ [2]: https://cdrdv2.intel.com/v1/dl/getContent/332690?wapkw=332690 [3]: https://cdrdv2.intel.com/v1/dl/getContent/332691?wapkw=332691 [4]: https://medium.com/@jacksonchen_43335/bios-gpio-p2sb-70e9b829b403Signed-off-by:
Jonathan Yong <jonathan.yong@intel.com> Co-developed-by:
-
- 04 Jul, 2022 6 commits
-
-
Nicolas Saenz Julienne authored
Bypass power_on/power_off() when running on BCM2711 as they are not needed. Signed-off-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Peter Robinson <pbrobinson@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Stefan Wahren authored
In BCM2711 the new RPiVid ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one. Use the fact that 'pm->rpivid_asb' is populated as a hint that we're on BCM2711. Signed-off-by:
-
Stefan Wahren authored
The macros in order to access the ASB registers have a hard coded base address. So extending them for other platforms would make them harder to read. As a solution resolve these macros. Signed-off-by:
-
Stefan Wahren authored
The functions to control the async AXI bridges are almost identical. So define a general function to handle it and keep the original ones as wrapper. This should make this driver easier to extend. Signed-off-by:
-
Stefan Wahren authored
In BCM2711 the new RPiVid ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one. As per the devicetree bindings, BCM2711 will provide both the old and new ASB resources, so get both of them and pass them into 'bcm2835-power,' which will take care of selecting which one to use accordingly. Since the RPiVid ASB's resources were being provided prior to formalizing the bindings[1], also support the old DT files that didn't use 'reg-names.' [1] See: 7dbe8c62 ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by:
-
Nicolas Saenz Julienne authored
If available in firmware, find resources by their 'reg-names' position instead of relying on hardcoded offsets. Care is taken to support old firmware nonetheless. Signed-off-by:
-
- 27 Jun, 2022 1 commit
-
-
Rafael J. Wysocki authored
Instead of walking the list of children of an ACPI device directly, use acpi_dev_for_each_child() to carry out an action for all of the given ACPI device's children. This will help to eliminate the children list head from struct acpi_device as it is redundant and it is used in questionable ways in some places (in particular, locking is needed for walking the list pointed to it safely, but it is often missing). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
- 06 Jun, 2022 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull file descriptor fix from Al Viro: "Fix for breakage in #work.fd this window" * tag 'pull-work.fd-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fix the breakage in close_fd_get_file() calling conventions change
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull mm hotfixes from Andrew Morton: "Fixups for various recently-added and longer-term issues and a few minor tweaks: - fixes for material merged during this merge window - cc:stable fixes for more longstanding issues - minor mailmap and MAINTAINERS updates" * tag 'mm-hotfixes-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/oom_kill.c: fix vm_oom_kill_table[] ifdeffery x86/kexec: fix memory leak of elf header buffer mm/memremap: fix missing call to untrack_pfn() in pagemap_range() mm: page_isolation: use compound_nr() correctly in isolate_single_pageblock() mm: hugetlb_vmemmap: fix CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON MAINTAINERS: add maintainer information for z3fold mailmap: update Josh Poimboeuf's email
-
- 05 Jun, 2022 7 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull delay-accounting update from Andrew Morton: "A single featurette for delay accounting. Delayed a bit because, unusually, it had dependencies on both the mm-stable and mm-nonmm-stable queues" * tag 'mm-nonmm-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: delayacct: track delays from write-protect copy
-
Linus Torvalds authored
The bluetooth code uses our bitmap infrastructure for the two bits (!) of connection setup flags, and in the process causes odd problems when it converts between a bitmap and just the regular values of said bits. It's completely pointless to do things like bitmap_to_arr32() to convert a bitmap into a u32. It shoudln't have been a bitmap in the first place. The reason to use bitmaps is if you have arbitrary number of bits you want to manage (not two!), or if you rely on the atomicity guarantees of the bitmap setting and clearing. The code could use an "atomic_t" and use "atomic_or/andnot()" to set and clear the bit values, but considering that it then copies the bitmaps around with "bitmap_to_arr32()" and friends, there clearly cannot be a lot of atomicity requirements. So just use a regular integer. In the process, this avoids the warnings about erroneous use of bitmap_from_u64() which were triggered on 32-bit architectures when conversion from a u64 would access two words (and, surprise, surprise, only one word is needed - and indeed overkill - for a 2-bit bitmap). That was always problematic, but the compiler seems to notice it and warn about the invalid pattern only after commit 0a97953f ("lib: add bitmap_{from,to}_arr64") changed the exact implementation details of 'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell. Fixes: fe92ee64 ("Bluetooth: hci_core: Rework hci_conn_params flags") Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/ Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/ Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reviewed-by:
Yury Norov <yury.norov@gmail.com> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Al Viro authored
It used to grab an extra reference to struct file rather than just transferring to caller the one it had removed from descriptor table. New variant doesn't, and callers need to be adjusted. Reported-and-tested-by: syzbot+47dd250f527cb7bebf24@syzkaller.appspotmail.com Fixes: 6319194e ("Unify the primitives for file descriptor closing") Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 SGX fix from Thomas Gleixner: "A single fix for x86/SGX to prevent that memory which is allocated for an SGX enclave is accounted to the wrong memory control group" * tag 'x86-urgent-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sgx: Set active memcg prior to shmem allocation
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 mm cleanup from Thomas Gleixner: "Use PAGE_ALIGNED() instead of open coding it in the x86/mm code" * tag 'x86-mm-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm: Use PAGE_ALIGNED(x) instead of IS_ALIGNED(x, PAGE_SIZE)
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 microcode updates from Thomas Gleixner: - Disable late microcode loading by default. Unless the HW people get their act together and provide a required minimum version in the microcode header for making a halfways informed decision its just lottery and broken. - Warn and taint the kernel when microcode is loaded late - Remove the old unused microcode loader interface - Remove a redundant perf callback from the microcode loader * tag 'x86-microcode-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/microcode: Remove unnecessary perf callback x86/microcode: Taint and warn on late loading x86/microcode: Default-disable late loading x86/microcode: Rip out the OLD_INTERFACE
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 cleanups from Thomas Gleixner: "A set of small x86 cleanups: - Remove unused headers in the IDT code - Kconfig indendation and comment fixes - Fix all 'the the' typos in one go instead of waiting for bots to fix one at a time" * tag 'x86-cleanups-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86: Fix all occurences of the "the the" typo x86/idt: Remove unused headers x86/Kconfig: Fix indentation of arch/x86/Kconfig.debug x86/Kconfig: Fix indentation and add endif comments to arch/x86/Kconfig
-
