- 23 11月, 2012 1 次提交
-
-
由 Mika Westerberg 提交于
ACPI 5 introduced I2cSerialBus resource that makes it possible to enumerate and configure the I2C slave devices behind the I2C controller. This patch adds helper functions to support I2C slave enumeration. An ACPI enabled I2C controller driver only needs to call acpi_i2c_register_devices() in order to get its slave devices enumerated, created and bound to the corresponding ACPI handle. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 21 11月, 2012 3 次提交
-
-
由 Rafael J. Wysocki 提交于
The current platform device creation and registration code in acpi_create_platform_device() is quite convoluted. This function takes an ACPI device node as an argument and eventually calls platform_device_register_resndata() to create and register a platform device object on the basis of the information contained in that code. However, it doesn't associate the new platform device with the ACPI node directly, but instead it relies on acpi_platform_notify(), called from within device_add(), to find that ACPI node again with the help of acpi_platform_find_device() and acpi_platform_match() and then attach the new platform device to it. This causes an additional ACPI namespace walk to happen and is clearly suboptimal. Use the observation that it is now possible to initialize the ACPI handle of a device before calling device_add() for it to make this code more straightforward. Namely, add a new field to struct platform_device_info allowing us to pass the ACPI handle of interest to platform_device_register_full(), which will then use it to initialize the new device's ACPI handle before registering it. This will cause acpi_platform_notify() to use the ACPI handle from the device structure directly instead of using the .find_device() routine provided by the device's bus type. In consequence, acpi_platform_bus, acpi_platform_find_device(), and acpi_platform_match() are not necessary any more, so remove them. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Rafael J. Wysocki 提交于
To avoid adding an ACPI handle pointer to struct device on architectures that don't use ACPI, or generally when CONFIG_ACPI is not set, in which cases that pointer is useless, define struct acpi_dev_node that will contain the handle pointer if CONFIG_ACPI is set and will be empty otherwise and use it to represent the ACPI device node field in struct device. In addition to that define macros for reading and setting the ACPI handle of a device that don't generate code when CONFIG_ACPI is unset. Modify the ACPI subsystem to use those macros instead of referring to the given device's ACPI handle directly. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Rafael J. Wysocki 提交于
Currently, the ACPI handles of devices are initialized from within device_add(), by acpi_bind_one() called from acpi_platform_notify() which first uses the .find_device() routine provided by the device's bus type to find the matching device node in the ACPI namespace. This is a source of some computational overhead and, moreover, the correctness of the result depends on the implementation of .find_device() which is known to fail occasionally for some bus types (e.g. PCI). In some cases, however, the corresponding ACPI device node is known already before calling device_add() for the given struct device object and the whole .find_device() dance in acpi_platform_notify() is then simply unnecessary. For this reason, make it possible to initialize the ACPI handles of devices before calling device_add() for them. Modify acpi_platform_notify() to call acpi_bind_one() in advance to check the device's existing ACPI handle and skip the .find_device() search if that is successful. Change acpi_bind_one() accordingly. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
- 17 11月, 2012 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Currently acpi_dev_process_resource() returns AE_ABORT_METHOD to terminate the acpi_walk_resources() it is called from if the .preproc() routine provided by the caller of acpi_dev_get_resources() initiating the resources walk returns an error code. It is better to use AE_CTRL_TERMINATE for this purpose, however, so do that. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
- 15 11月, 2012 8 次提交
-
-
由 Rafael J. Wysocki 提交于
Currently, whoever wants to use ACPI device resources has to call acpi_walk_resources() to browse the buffer returned by the _CRS method for the given device and create filters passed to that routine to apply to the individual resource items. This generally is cumbersome, time-consuming and inefficient. Moreover, it may be problematic if resource conflicts need to be resolved, because the different users of _CRS will need to do that in a consistent way. However, if there are resource conflicts, the ACPI core should be able to resolve them centrally instead of relying on various users of acpi_walk_resources() to handle them correctly together. For this reason, introduce a new function, acpi_dev_get_resources(), that can be used by subsystems to obtain a list of struct resource objects corresponding to the ACPI device resources returned by _CRS and, if necessary, to apply additional preprocessing routine to the ACPI resources before converting them to the struct resource format. Make the ACPI code that creates platform device objects use acpi_dev_get_resources() for resource processing instead of executing acpi_walk_resources() twice by itself, which causes it to be much more straightforward and easier to follow. In the future, acpi_dev_get_resources() can be extended to meet the needs of the ACPI PNP subsystem and other users of _CRS in the kernel. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Rafael J. Wysocki 提交于
Use common routines in drivers/acpi/resource.c to parse ACPI device resources while creating platform device objects. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Rafael J. Wysocki 提交于
Move some code used for parsing ACPI device resources from the PNP subsystem to the ACPI core, so that other bus types (platform, SPI, I2C) can use the same routines for parsing resources in a consistent way, without duplicating code. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Mika Westerberg 提交于
Using _UID makes the ACPI platform bus code depend on BIOS to get it right. If it doesn't we fail to create the platform device as the name should be unique. The ACPI core already makes a unique name when it first creates the ACPI device so we can use that same name as the platform device name instead of trusting that the BIOS sets the _UIDs correctly. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
With ACPI 5 it is now possible to enumerate traditional SoC peripherals, like serial bus controllers and slave devices behind them. These devices are typically based on IP-blocks used in many existing SoC platforms and platform drivers for them may already be present in the kernel tree. To make driver "porting" more straightforward, add ACPI support to the platform bus type. Instead of writing ACPI "glue" drivers for the existing platform drivers, register the platform bus type with ACPI to create platform device objects for the drivers and bind the corresponding ACPI handles to those platform devices. This should allow us to reuse the existing platform drivers for the devices in question with the minimum amount of modifications. This changeset is based on Mika Westerberg's and Mathias Nyman's work. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NH. Peter Anvin <hpa@zytor.com> Acked-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Andy Shevchenko 提交于
These functions might be called from modules as well so make sure they are exported. In addition, implement empty version of acpi_unregister_gsi() and remove the one from pci_irq.c. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NH. Peter Anvin <hpa@zytor.com> Acked-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
Introduce function acpi_match_device() allowing callers to match struct device objects with populated acpi_handle fields against arrays of ACPI device IDs. Also introduce function acpi_driver_match_device() using acpi_match_device() internally and allowing callers to match a struct device object against an array of ACPI device IDs provided by a device driver. Additionally, introduce macro ACPI_PTR() that may be used by device drivers to escape pointers to data structures whose definitions depend on CONFIG_ACPI. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NH. Peter Anvin <hpa@zytor.com> Acked-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
With ACPI 5 we are starting to see devices that don't natively support discovery but can be enumerated with the help of the ACPI namespace. Typically, these devices can be represented in the Linux device driver model as platform devices or some serial bus devices, like SPI or I2C devices. Since we want to re-use existing drivers for those devices, we need a way for drivers to specify the ACPI IDs of supported devices, so that they can be matched against device nodes in the ACPI namespace. To this end, it is sufficient to add a pointer to an array of supported ACPI device IDs, that can be provided by the driver, to struct device. Moreover, things like ACPI power management need to have access to the ACPI handle of each supported device, because that handle is used to invoke AML methods associated with the corresponding ACPI device node. The ACPI handles of devices are now stored in the archdata member structure of struct device whose definition depends on the architecture and includes the ACPI handle only on x86 and ia64. Since the pointer to an array of supported ACPI IDs is added to struct device_driver in an architecture-independent way, it is logical to move the ACPI handle from archdata to struct device itself at the same time. This also makes code more straightforward in some places and follows the example of Device Trees that have a poiter to struct device_node in there too. This changeset is based on Mika Westerberg's work. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NH. Peter Anvin <hpa@zytor.com> Acked-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 10 11月, 2012 3 次提交
-
-
由 Andreas Larsson 提交于
This adds sparc support for platform_get_irq that in the normal case use platform_get_resource() to get an irq. This standard approach fails for sparc as there are no resources of type IORESOURCE_IRQ for irqs for sparc. Cross platform drivers can then use this standard platform function and work on sparc instead of having to have a special case for sparc. Signed-off-by: NAndreas Larsson <andreas@gaisler.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wang Dongsheng 提交于
If a gianfar ethernet device is down prior to hibernating a system, it will no longer be present upon system restore. For example: ~# ifconfig eth0 down ~# echo disk > /sys/power/state <trigger a restore from hibernation> ~# ifconfig eth0 up SIOCSIFFLAGS: No such device This happens because the restore function bails out early upon finding devices that were not up at hibernation. In doing so, it never gets to the netif_device_attach call at the end of the restore function. Adding the netif_device_attach as done here also makes the gfar_restore code consistent with what is done in the gfar_resume code. Cc: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: NWang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NClaudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Steve Glendinning 提交于
when something goes wrong, a flood of these messages can be generated by usbnet (thousands per second). This doesn't generally *help* the condition so this patch ratelimits the rate of their generation. There's an underlying problem in usbnet's kevent deferral mechanism which needs fixing, specifically that events *can* get dropped and not handled. This patch doesn't address this, but just mitigates fallout caused by the current implemention. Signed-off-by: NSteve Glendinning <steve.glendinning@shawell.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 11月, 2012 8 次提交
-
-
由 Thomas Hellstrom 提交于
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NDmitry Torokhov <dtor@vmware.com> Cc: stable@vger.kernel.org Cc: linux-graphics-maintainer@vmware.com Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
The device would not reset properly when resuming from hibernation. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NDmitry Torokhov <dtor@vmware.com> Cc: stable@vger.kernel.org Cc: linux-graphics-maintainer@vmware.com Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Cornelia Huck 提交于
Virtio wants to release used indices after the corresponding virtio device has been unregistered. However, virtio does not hold an extra reference, giving up its last reference with device_unregister(), making accessing dev->index afterwards invalid. I actually saw problems when testing my (not-yet-merged) virtio-ccw code: - device_add virtio-net,id=xxx -> creates device virtio<n> with n>0 - device_del xxx -> deletes virtio<n>, but calls ida_simple_remove with an index of 0 - device_add virtio-net,id=xxx -> tries to add virtio0, which is still in use... So let's save the index we want to release before calling device_unregister(). Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com> Acked-by: NSjur Brændeland <sjur.brandeland@stericsson.com> Cc: stable@kernel.org Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Maarten Lankhorst 提交于
Commit c0077061 accidentally inverted the logic for nouveau_acpi_edid, causing it to only show a connector as connected when the edid could not be retrieved with acpi. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Kelly Doran 提交于
Signed-off-by: NKelly Doran <kel.p.doran@gmail.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
It slipped in thanks to typeless API. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
nv04_graph_priv / nv04_graph_chan are not defined in this context... Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
It's a miracle it compiles at all - nv04_vm_priv does not exist anywhere in the tree. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 08 11月, 2012 16 次提交
-
-
由 Alex Deucher 提交于
This register is needed for streamout to work properly. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
-
由 Alex Deucher 提交于
These regs were being wronly rejected leading to rendering issues. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=56876Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
-
由 Ian Coolidge 提交于
cdc_eem frames might need to contain 802.1Q VLAN Ethernet frames. URB/skb sizing from usbnet will default to the hard_mtu, so account for the VLAN header by expanding that via hard_header_len Signed-off-by: NIan Coolidge <iancoolidge@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ian Coolidge 提交于
Checking skb->len against ETH_FRAME_LEN assumes a 1514 ethernet frame size. With an 802.1Q VLAN header, ethernet frame length can now be 1518. Validate frame length against that. Signed-off-by: NIan Coolidge <iancoolidge@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vipul Pandya 提交于
INGPADBOUNDARY_MASK is already shifted. No need to shift it again. On reloading a driver it was resulting in a bad SGE FL MTU sizes [1536, 9088] error. This only causes an issue on systems that have L1 cache size of 32B, 128B, 512B, 2048B or 4096B. Signed-off-by: NJay Hernandez <jay@chelsio.com> Signed-off-by: NVipul Pandya <vipul@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Lee Jones 提交于
It doesn't make much sense to enable ISDN services if you don't intend to connect to a network. Therefore insisting that ISDN depends on NETDEVICES seems logical. We can then remove any guards mentioning NETDEVICES inside all subordinate drivers. This also has the nice side-effect of fixing the warning below when ISDN_I4L && !CONFIG_NETDEVICES at compile time. This patch fixes: drivers/isdn/i4l/isdn_common.c: In function ‘isdn_ioctl’: drivers/isdn/i4l/isdn_common.c:1278:8: warning: unused variable ‘s’ [-Wunused-variable] Cc: Karsten Keil <isdn@linux-pingi.de> Cc: netdev@vger.kernel.org Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vipul Pandya 提交于
We should not assume reserve fields to be don't cares as fields may change. Clearing data structures before using. Signed-off-by: NJay Hernandez <jay@chelsio.com> Signed-off-by: NVipul Pandya <vipul@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Seungwon Jeon 提交于
If host clock is disabled, host cannot detect a card in case of using CD internal for detection. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Thomas Abraham 提交于
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arnd Bergmann 提交于
The of_device_id match data is now marked as const and must not be modified. This changes the dw_mmc to mark all pointers passing the dw_mci_drv_data or dw_mci_dma_ops structures as const, and also marks the static definitions as const. drivers/mmc/host/dw_mmc-exynos.c: In function 'dw_mci_exynos_probe': drivers/mmc/host/dw_mmc-exynos.c:234:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default] Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Thomas Abraham <thomas.abraham@linaro.org> Cc: Will Newton <will.newton@imgtec.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arnd Bergmann 提交于
The MODULE_DEVICE_TABLE entry for dw_mci_exynos_match was incorrectly copied from the platform back-end, which causes this error when building the driver as a loadable module: drivers/mmc/host/dw_mmc-exynos.c: At top level: drivers/mmc/host/dw_mmc-exynos.c:226:34: error: '__mod_of_device_table' aliased to undefined symbol 'dw_mci_pltfm_match' This patch fixes the problem by just using the correct string. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Thomas Abraham <thomas.abraham@linaro.org> Cc: Will Newton <will.newton@imgtec.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Chris Ball 提交于
Commit 473b095a ("mmc: sdhci: fix incorrect command used in tuning") introduced a NULL dereference at resume-time if an SD 3.0 host controller raises the SDHCI_NEEDS_TUNING flag while no card is inserted. Seen on an OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too. Signed-off-by: NChris Ball <cjb@laptop.org> Cc: stable <stable@vger.kernel.org> [3.3+]
-
由 Kevin Liu 提交于
There are two problems here: The check for vmmc was printing an unnecessary pr_info() when host->vmmc is NULL. The intent of the check for vqmmc was to only remove UHS if we have a regulator that doesn't support the required voltage, but since IS_ERR() doesn't catch NULL, we were actually removing UHS modes if vqmmc isn't present at all -- since it isn't present for most users, this breaks UHS for them. This patch fixes that UHS regression in 3.7-rc1. Signed-off-by: NKevin Liu <kliu5@marvell.com> Signed-off-by: NBin Wang <binw@marvell.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Russell King - ARM Linux 提交于
1. Never ever publish a device in the system before it has been setup to a usable state. 2. Unregister the device _BEFORE_ taking away any resources it may be using. 3. Don't check clks against NULL. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Guennadi Liakhovetski 提交于
A recent commit "mmc: sh_mmcif: fix clock management" has introduced a use after free bug in sh_mmcif.c: in sh_mmcif_remove() the call to mmc_free_host() frees private driver data, therefore using it afterwards is a bug. Revert that hunk. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: stable@vger.kernel.org [3.6] Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Adrian Hunter 提交于
The SDHCI standard defines a 256 byte register set but a device that specifies a larger iomem region is not an error. Alter the message condition accordingly. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-