linux/drivers/base/platform.c, branch v4.15

drivers: flag buses which demand DMA configuration

2017-10-19T14:34:52Z

We do not want the common dma_configure() pathway to apply indiscriminately to all devices, since there are plenty of buses which do not have DMA capability, and if their child devices were used for DMA API calls it would only be indicative of a driver bug. However, there are a number of buses for which DMA is implicitly expected even when not described by firmware - those we whitelist with an automatic opt-in to dma_configure(), assuming that the DMA address space and the physical address space are equivalent if not otherwise specified. Commit 723288836628 ("of: restrict DMA configuration") introduced a short-term fix by comparing explicit bus types, but this approach is far from pretty, doesn't scale well, and fails to cope at all with bus drivers which may be built as modules, like host1x. Let's refine things by making that opt-in a property of the bus type, which neatly addresses those problems and lets the decision of whether firmware description of DMA capability should be optional or mandatory stay internal to the bus drivers themselves. Signed-off-by: Robin Murphy Acked-by: Rob Herring Acked-by: Greg Kroah-Hartman Acked-by: Thierry Reding Signed-off-by: Christoph Hellwig

driver core: platform: Don't read past the end of "driver_override" buffer

2017-09-18T15:16:47Z

When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count+1 bytes for printing. Reject driver_override values of these lengths in driver_override_store(). This is in close analogy to commit 4efe874aace5 ("PCI: Don't read past the end of sysfs "driver_override" buffer") from Sasha Levin. Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'") Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: Nicolai Stange Signed-off-by: Greg Kroah-Hartman

Merge tag 'gpio-v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2017-07-07T19:40:27Z

Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.13 series. Some administrativa: I have a slew of 8250 serial patches and the new IOT2040 serial+GPIO driver coming in through this tree, along with a whole bunch of Exar 8250 fixes. These are ACKed by Greg and also hit drivers/platform/* where they are ACKed by Andy Shevchenko. Speaking about drivers/platform/* there is also a bunch of ACPI stuff coming through that route, again ACKed by Andy. The MCP23S08 changes are coming in here as well. You already have the commits in your tree, so this is just a result of sharing an immutable branch between pin control and GPIO. Core: - Export add/remove for lookup tables so that modules can export GPIO descriptor tables. - Handle GPIO sleep states: it is now possible to flag that a GPIO line may loose its state during suspend/resume of the system to save power. This is used in the Wolfson Micro Arizona driver. - ACPI-based GPIO was tightened up a lot around the edges. - Use bitmap_fill() to speed up a loop. New drivers: - Exar XRA1403 SPI-based GPIO. - MVEBU driver now supports Armada 7K and 8K. - LP87565 PMIC GPIO. - Renesas R-CAR R8A7743 (RZ/G1M). - The new IOT2040 8250 serial/GPIO also comes in through this changeset. Substantial driver changes: - Seriously fix the Exar 8250 GPIO portions to work. - The MCP23S08 was moved out to a pin control driver. - Convert MEVEBU to use regmap for register access. - Drop Vulcan support from the Broadcom driver. - Serious cleanup and improvement of the mockup driver, giving us a better test coverage. Misc: - Lots of janitorial clean up. - A bunch of documentation fixes" * tag 'gpio-v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (70 commits) serial: exar: Add support for IOT2040 device gpio-exar/8250-exar: Make set of exported GPIOs configurable platform: Accept const properties serial: exar: Factor out platform hooks gpio-exar/8250-exar: Rearrange gpiochip parenthood gpio: exar: Fix iomap request gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards serial: uapi: Add support for bus termination gpio: rcar: Add R8A7743 (RZ/G1M) support gpio: gpio-wcove: Fix GPIO control register offset calculation gpio: lp87565: Add support for GPIO gpio: dwapb: fix missing first irq for edgeboth irq type MAINTAINERS: Take maintainership for GPIO ACPI support gpio: exar: Fix reading of directions and values gpio: exar: Allocate resources on behalf of the platform device gpio-exar/8250-exar: Fix passing in of parent PCI device gpio: mockup: use devm_kcalloc() where applicable gpio: mockup: add myself as author gpio: mockup: improve the error message gpio: mockup: don't return magic numbers from probe() ...

platform: Accept const properties

2017-07-03T06:31:43Z

Aligns us with device_add_properties, the function we call. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko

driver core: platform: fix race condition with driver_override

2017-05-25T13:30:12Z

The driver_override implementation is susceptible to race condition when different threads are reading vs storing a different driver override. Add locking to avoid race condition. Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'") Cc: stable@vger.kernel.org Signed-off-by: Adrian Salido Signed-off-by: Greg Kroah-Hartman

of: Add function for generating a DT modalias with a newline

2017-03-22T19:56:13Z

The modalias sysfs attr is lacking a newline for DT aliases on platform devices. The macio and ibmebus correctly add the newline, but open code it. Introduce a new function, of_device_modalias(), that fills the buffer with the modalias including the newline and update users of the old of_device_get_modalias function. Signed-off-by: Rob Herring Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Frank Rowand Cc: linuxppc-dev@lists.ozlabs.org Acked-by: Greg Kroah-Hartman

Merge tag 'driver-core-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2017-02-22T19:44:32Z

Pull driver core updates from Greg KH: "Here is the "small" driver core patches for 4.11-rc1. Not much here, some firmware documentation and self-test updates, a debugfs code formatting issue, and a new feature for call_usermodehelper to make it more robust on systems that want to lock it down in a more secure way. All of these have been linux-next for a while now with no reported issues" * tag 'driver-core-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: kernfs: handle null pointers while printing node name and path Introduce STATIC_USERMODEHELPER to mediate call_usermodehelper() Make static usermode helper binaries constant kmod: make usermodehelper path a const string firmware: revamp firmware documentation selftests: firmware: send expected errors to /dev/null selftests: firmware: only modprobe if driver is missing platform: Print the resource range if device failed to claim kref: prefer atomic_inc_not_zero to atomic_add_unless debugfs: improve formatting of debugfs_real_fops()

ACPI: Add support for ResourceSource/IRQ domain mapping

2017-02-03T15:03:48Z

ACPI extended IRQ resources may contain a ResourceSource to specify an alternate interrupt controller. Introduce acpi_irq_get and use it to implement ResourceSource/IRQ domain mapping. The new API is similar to of_irq_get and allows re-initialization of a platform resource from the ACPI extended IRQ resource, and provides proper behavior for probe deferral when the domain is not yet present when called. Acked-by: Rafael J. Wysocki Acked-by: Lorenzo Pieralisi Reviewed-by: Hanjun Guo Tested-by: Hanjun Guo Signed-off-by: Agustin Vega-Frias Signed-off-by: Marc Zyngier

platform: Print the resource range if device failed to claim

2017-01-11T08:29:33Z

Sometimes we have the following error message: platform MSFT0101:00: failed to claim resource 1 acpi MSFT0101:00: platform device creation failed: -16 But there is not enough information to figure out which resource range failed to claim. Thus print the resource range at first-place thus /proc/iomem or ioports should tell us who already claimed this resource, then the driver bug or incorrect resource assignment which is running into this conflict can be diagnosed: platform MSFT0101:00: failed to claim resource 1: [mem 0xfed40000-0xfed40fff] acpi MSFT0101:00: platform device creation failed: -16 Suggested-by: Len Brown Reported-by: Wendy Wang Signed-off-by: Chen Yu Reviewed-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

driver-core: platform: Catch errors from calls to irq_get_irq_data

2016-09-27T10:30:37Z

irq_get_irq_data() can return NULL, which results in a nasty crash. Check its return value before passing it on to irqd_set_trigger_type(). Signed-off-by: Guenter Roeck Reviewed-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman