user/sven/linux.git/Documentation/driver-api/driver-model/devres.rst, branch v5.15.162

Merge tag 'pwm/for-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

2021-07-08T19:18:04Z

Pull pwm updates from Thierry Reding: "This contains mostly various fixes, cleanups and some conversions to the atomic API. One noteworthy change is that PWM consumers can now pass a hint to the PWM core about the PWM usage, enabling PWM providers to implement various optimizations. There's also a fair bit of simplification here with the addition of some device-managed helpers as well as unification between the DT and ACPI firmware interfaces" * tag 'pwm/for-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (50 commits) pwm: Remove redundant assignment to pointer pwm pwm: ep93xx: Fix read of uninitialized variable ret pwm: ep93xx: Prepare clock before using it pwm: ep93xx: Unfold legacy callbacks into ep93xx_pwm_apply() pwm: ep93xx: Implement .apply callback pwm: vt8500: Only unprepare the clock after the pwmchip was removed pwm: vt8500: Drop if with an always false condition pwm: tegra: Assert reset only after the PWM was unregistered pwm: tegra: Don't needlessly enable and disable the clock in .remove() pwm: tegra: Don't modify HW state in .remove callback pwm: tegra: Drop an if block with an always false condition pwm: core: Simplify some devm_*pwm*() functions pwm: core: Remove unused devm_pwm_put() pwm: core: Unify fwnode checks in the module pwm: core: Reuse fwnode_to_pwmchip() in ACPI case pwm: core: Convert to use fwnode for matching docs: firmware-guide: ACPI: Add a PWM example dt-bindings: pwm: pwm-tiecap: Add compatible string for AM64 SoC dt-bindings: pwm: pwm-tiecap: Convert to json schema pwm: sprd: Don't check the return code of pwmchip_remove() ...

pwm: core: Remove unused devm_pwm_put()

2021-06-30T17:12:19Z

There are no users and seems no will come of the devm_pwm_put(). Remove the function. While at it, slightly update documentation. Signed-off-by: Andy Shevchenko Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding

driver core: Drop helper devm_platform_ioremap_resource_wc()

2021-05-27T13:51:33Z

Since the macro was introduced in 2019 (commit bb6243b4f73d ("drivers: platform: provide devm_platform_ioremap_resource_wc()") there is only a single user which hardly justifies the function for the small task it provides. So drop the helper and open-code it in the only user. Adapt the non-wc case accordingly. For a all-mod-config build on amd64 this change introduces the following changes according to bloat-o-meter: add/remove: 0/1 grow/shrink: 1/0 up/down: 20/-252 (-232) Function old new delta devm_platform_ioremap_resource_wc 252 - -252 sram_probe 796 816 +20 Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210525103711.956438-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman

Merge tag 'arm-apple-m1-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2021-04-26T19:30:36Z

Pull ARM Apple M1 platform support from Arnd Bergmann: "The Apple M1 is the processor used it all current generation Apple Macintosh computers. Support for this platform so far is rudimentary, but it boots and can use framebuffer and serial console over a special USB cable. Support for several essential on-chip devices (USB, PCIe, IOMMU, NVMe) is work in progress but was not ready in time. A very detailed description of what works is in the commit message of commit 1bb2fd3880d4 ("Merge tag 'm1-soc-bringup-v5' [..]") and on the AsahiLinux wiki" Link: https://lore.kernel.org/linux-arm-kernel/bdb18e9f-fcd7-1e31-2224-19c0e5090706@marcan.st/ * tag 'arm-apple-m1-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: asm-generic/io.h: Unbork ioremap_np() declaration arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree dt-bindings: display: Add apple,simple-framebuffer arm64: Kconfig: Introduce CONFIG_ARCH_APPLE irqchip/apple-aic: Add support for the Apple Interrupt Controller dt-bindings: interrupt-controller: Add DT bindings for apple-aic arm64: Move ICH_ sysreg bits from arm-gic-v3.h to sysreg.h of/address: Add infrastructure to declare MMIO as non-posted asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np arm64: Implement ioremap_np() to map MMIO as nGnRnE docs: driver-api: device-io: Document ioremap() variants & access funcs docs: driver-api: device-io: Document I/O access functions asm-generic/io.h: Add a non-posted variant of ioremap() arm64: arch_timer: Implement support for interrupt-names dt-bindings: timer: arm,arch_timer: Add interrupt-names support arm64: cputype: Add CPU implementor & types for the Apple M1 cores dt-bindings: arm: cpus: Add apple,firestorm & icestorm compatibles dt-bindings: arm: apple: Add bindings for Apple ARM platforms dt-bindings: vendor-prefixes: Add apple prefix

asm-generic/io.h: Add a non-posted variant of ioremap()

2021-04-08T11:18:38Z

ARM64 currently defaults to posted MMIO (nGnRE), but some devices require the use of non-posted MMIO (nGnRnE). Introduce a new ioremap() variant to handle this case. ioremap_np() returns NULL on arches that do not implement this variant. sparc64 is the only architecture that needs to be touched directly, because it includes neither of the generic io.h or iomap.h headers. This adds the IORESOURCE_MEM_NONPOSTED flag, which maps to this variant and marks a given resource as requiring non-posted mappings. This is implemented in the resource system because it is a SoC-level requirement, so existing drivers do not need special-case code to pick this ioremap variant. Then this is implemented in devres by introducing devm_ioremap_np(), and making devm_ioremap_resource() automatically select this variant when the resource has the IORESOURCE_MEM_NONPOSTED flag set. Acked-by: Marc Zyngier Signed-off-by: Hector Martin

iio: buffer-dma,adi-axi-adc: introduce devm_iio_dmaengine_buffer_setup()

2021-03-11T20:47:02Z

This change does a conversion of the devm_iio_dmaengine_buffer_alloc() to devm_iio_dmaengine_buffer_setup(). This will allocate an IIO DMA buffer and attach it to the IIO device, similar to devm_iio_triggered_buffer_setup() (though the underlying code is different, the final logic is the same). Since the only user of the devm_iio_dmaengine_buffer_alloc() was the adi-axi-adc driver, this change does the replacement in a single go in the driver. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210215104043.91251-7-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron

iio: kfifo: un-export devm_iio_kfifo_allocate() function

2021-03-11T20:47:01Z

At this point all drivers should use devm_iio_kfifo_buffer_setup() instead of manually allocating via devm_iio_kfifo_allocate() and assigning ops and modes. With this change, the devm_iio_kfifo_allocate() will be made private to the IIO core, since all drivers should call either devm_iio_kfifo_buffer_setup() or devm_iio_triggered_buffer_setup() to create a kfifo buffer. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210215104043.91251-6-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron

iio: kfifo: add devm_iio_kfifo_buffer_setup() helper

2021-03-11T20:47:01Z

This change adds the devm_iio_kfifo_buffer_setup() helper/short-hand, which groups the simple routine of allocating a kfifo buffers via devm_iio_kfifo_allocate() and calling iio_device_attach_buffer(). The mode_flags parameter is required, as the IIO kfifo supports 2 modes: INDIO_BUFFER_SOFTWARE & INDIO_BUFFER_TRIGGERED. The setup_ops parameter is optional. This function will be a bit more useful when needing to define multiple buffers per IIO device. The naming for this function has been inspired from iio_triggered_buffer_setup() since that one does a kfifo alloc + a pollfunc alloc. So, this should have a more familiar ring to what it is. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210215104043.91251-3-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron

rtc: rework rtc_register_device() resource management

2020-11-19T11:50:12Z

rtc_register_device() is a managed interface but it doesn't use devres by itself - instead it marks an rtc_device as "registered" and the devres callback for devm_rtc_allocate_device() takes care of resource release. This doesn't correspond with the design behind devres where managed structures should not be aware of being managed. The correct solution here is to register a separate devres callback for unregistering the device. While at it: rename rtc_register_device() to devm_rtc_register_device() and add it to the list of managed interfaces in devres.rst. This way we can avoid any potential confusion of driver developers who may expect there to exist a corresponding unregister function. Signed-off-by: Bartosz Golaszewski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl

rtc: add devm_ prefix to rtc_nvmem_register()

2020-11-19T11:50:11Z

rtc_nvmem_register() is a managed interface. It doesn't require any release function to be called at driver detach. To avoid confusing driver authors, let's rename it to devm_rtc_nvmem_register() and add it to the list of managed interfaces in Documentation/. Signed-off-by: Bartosz Golaszewski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201109163409.24301-6-brgl@bgdev.pl