aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* pinctrl: correct a offset while enumerating pinsChanho Park2012-01-03
| | | | | | | | | | | | | | | This patch modifies a offset while enumerating pins to support a partial pin space. If we use a pin number for enumerating pins, the pin space always starts with zero base. Indeed, we always check the pin is in the pin space. An extreme example, there is only two pins. One is 0. Another is 1000. We always enumerate whole offsets until 1000. For solving this problem, we use the offset of the pin array instead of the zero-based pin number. Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> [Restored sparse pin space comment] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: some typo fixesDong Aisheng2012-01-03
| | | | | | | Minor copyedits. Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: rename U300 and SIRF pin controllersLinus Walleij2012-01-03
| | | | | | | | | | | For stringent order, rename the pinmux-* pin controllers to pinctrl-* and also rename the Kconfig symbols and in-kernel users. Cc: Rongjun Ying <Rongjun.Ying@csr.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: pass name instead of device to pin_config_*Stephen Warren2012-01-03
| | | | | | | | | | | Obtaining a "struct pinctrl_dev *" is difficult for code not directly related to the pinctrl subsystem. However, the device name of the pinctrl device is fairly well known. So, modify pin_config_*() to take the device name instead of the "struct pinctrl_dev *". Signed-off-by: Stephen Warren <swarren@nvidia.com> [rebased on top of refactoring code] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: add "struct seq_file;" to pinconf.hStephen Warren2012-01-03
| | | | | | | | This allows one to include pinconf.h without having to include other headers first. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: conjure names for unnamed pinsLinus Walleij2012-01-03
| | | | | | | | | If pins with blank names are registered, we assign them names on-the-fly on the form "PINn" where n is the pin number for that pin on the specific controller. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: add a group-specific hog macroLinus Walleij2012-01-03
| | | | | | | | | | To create elegant tables for pinmux hogs on the PXA MMP platform, we need this hog macro that can specify both function and group in one go. Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: don't create a device for each pin controllerStephen Warren2012-01-03
| | | | | | | | | | | | | | | | Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* arm/u300: don't use PINMUX_MAP_PRIMARY*Stephen Warren2012-01-03
| | | | | | | The next patch will remove these macros. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: implement PINMUX_MAP_SYS_HOGStephen Warren2012-01-03
| | | | | | | | This is the same as PINMUX_MAP_PRIMARY_SYS_HOG, except that it allows you to specify a particular control device. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: add a pin config interfaceLinus Walleij2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl/coh901: driver to request its pinsLinus Walleij2012-01-03
| | | | | | | This makes the COH 901 driver request muxing of its GPIO pins from the pinmux-u300 driver using the standard API calls. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: u300-pinmux: register proper GPIO rangesLinus Walleij2012-01-03
| | | | | | | This register the actual GPIO ranges used by the COH901XXX GPIO driver. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: move the U300 GPIO driver to pinctrlLinus Walleij2012-01-03
| | | | | | | | This driver will be converted to a dual GPIO + pinctrl driver since it supports biasing and driving control options. Hopefully it can serve as an example. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* ARM: u300: localize GPIO assignmentsLinus Walleij2012-01-03
| | | | | | | | Move the GPIO assignments for the U300 variants down to a local header file in the mach-u300 directory. There is no point in broadcasting this across the entire kernel. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: make it possible to add multiple mapsLinus Walleij2012-01-03
| | | | | | | | | | | | Since we now anyway make a copy of the platform-supplied pinmux map, we can just as well make it possible to call the function adding maps several times, so as to simplify cases (as PXA) where several sets of disparate mappings need to be added depending on target platform. Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> Acked-by: Arnd Bergmann <arnd@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: make a copy of pinmux mapLinus Walleij2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | This makes a deep copy of the pinmux function map instead of keeping the copy supplied from the platform around. This makes it possible to tag the platforms map with __initdata as is also done as part of this patch. Rationale: a certain target platform (PXA) has numerous pinmux maps, many of which will be lying around unused after boot in a multi-platform binary. Instead, deep-copy the one we're going to use and tag them all __initdata so they go away after boot. ChangeLog v1->v2: - Fixup the deep copy, missed a few items on the struct, plus mark bool member non-const since we're making runtime copies if this stuff now. ChangeLog v2->v3: - Make a shallow copy (just copy the array of map structs) as Arnd noticed, string constants never get discarded by the kernel anyway, so these pointers may be safely copied over. Reviewed-by: Arnd Bergmann <arnd.bergmann@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: GPIO direction support for muxingLinus Walleij2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | When requesting a single GPIO pin to be muxed in, some controllers will need to poke a different value into the control register depending on whether the pin will be used for GPIO output or GPIO input. So create pinmux counterparts to gpio_direction_[input|output] in the pinctrl framework. ChangeLog v1->v2: - This also amends the documentation to make it clear the this function and associated machinery is *ONLY* intended as a backend to gpiolib machinery, not for everyone and his dog to start playing around with pins. ChangeLog v2->v3: - Don't pass an argument to the common request function, instead provide pinmux_* counterparts to the gpio_direction_[input|output] calls, simpler and anyone can understand it. ChangeLog v3->v4: - Fix numerous spelling mistakes and dangling text in documentation. Add Ack and Rewewed-by. Cc: Igor Grinberg <grinberg@compulab.co.il> Acked-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: print pin range in GPIO range debugsLinus Walleij2012-01-03
| | | | | | | | Show the mapped pin range corresponding to the GPIO range in debugfs for pin controllers. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: add a pin_base for sparse gpio-rangesChanho Park2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables mapping a base offset of gpio ranges with a pin offset even if does'nt matched. A base of pinctrl_gpio_range means a base offset of gpio. However, we cannot convert gpio to pin number for sparse gpio ranges just only using a gpio base offset. We can convert a gpio to real pin number(even if not matched) using a new pin_base which means a base pin offset of requested gpio range. Now, the pin control subsystem passes the pin base offset to the pinmux driver. For example, let's assume below two gpio ranges in the system. static struct pinctrl_gpio_range gpio_range_a = { .name = "chip a", .id = 0, .base = 32, .pin_base = 32, .npins = 16, .gc = &chip_a; }; static struct pinctrl_gpio_range gpio_range_b = { .name = "chip b", .id = 0, .base = 48, .pin_base = 64, .npins = 8, .gc = &chip_b; }; We can calucalate a exact pin ranges even if doesn't matched with gpio ranges. chip a: gpio-range : [32 .. 47] pin-range : [32 .. 47] chip b: gpio-range : [48 .. 55] pin-range : [64 .. 71] Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: unify pin type from signed to unsignedMarek Belisko2012-01-03
| | | | | | | | We want singned pins to mean "invalid" only on the outside of the subsystem. Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: documentation updateLinus Walleij2012-01-03
| | | | | | | | | | | | | Update the docs removing an obsolete __refdata tag and document the mysterious return value of pin_free(). And fixes up some various confusions in the pinctrl documentation. Reported-by: Rajendra Nayak <rnayak@ti.com> Reported-by: Randy Dunlap <rdunlap@xenotime.net> Reported-by: Thomas Abraham <thomas.abraham@linaro.org> Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: add explicit gpio_disable_free pinmux_opStephen Warren2012-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a completely different manner than they select which function to mux out of that pin. In order to support a single "free" pinmux_op, the driver would need to maintain a per-pin state of requested-for-gpio vs. requested-for- function. However, that's a lot of work when the core already has explicit separate paths for gpio request/free and function request/free. So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free() call it when appropriate. When doing this, I noticed that when calling pin_request(): !!gpio == (gpio_range != NULL) ... and so I collapsed those two parameters in both pin_request(), and when adding writing the new code in pin_free(). Also, for pin_free(): !!free_func == (gpio_range != NULL) However, I didn't want pin_free() to know about the GPIO function naming special case, so instead, I reworked pin_free() to always return the pin's previously requested function, and now pinmux_free_gpio() calls kfree(function). This is much more balanced with the allocation having been performed in pinmux_request_gpio(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: remove double pin validity check.Marek Belisko2012-01-03
| | | | | | | | | Function pin_is_valid just call pin_desc_get which is in pin_request call some line below. Remove pin_is_valid() check. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: move group lookup to coreLinus Walleij2012-01-03
| | | | | | | | Now also the core needs to look up pin groups so move the lookup function there and expose it in the internal header. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: iterate over u300_pmx_mask's in u300_pmx_endisableRajendra Nayak2012-01-03
| | | | | | | | Fix u300_pmx_endisable() to iterate over the list of 'bits' and 'mask' populated as part of u300_pmx_functions.mask[] Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* MAINTAINERS: Fix pinctrl subsystem's directoryStephen Warren2012-01-03
| | | | | Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: remove two unused global variablesUwe Kleine-König2011-12-08
| | | | | Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl: make the "Debug PINCTRL calls" entry actually do somethingUwe Kleine-König2011-12-08
| | | | | | | DEBUG_PINCTRL wasn't used at all and DEBUG_PINMUX doesn't exist. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pinctrl/sirf: fix pin number typo for SPI1Barry Song2011-12-02
| | | | | Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* Linux 3.2-rc3Linus Torvalds2011-11-23
|
* Merge git://github.com/rustyrussell/linuxLinus Torvalds2011-11-23
|\ | | | | | | | | | | | | * git://github.com/rustyrussell/linux: virtio-pci: make reset operation safer virtio-mmio: Correct the name of the guest features selector virtio: add HAS_IOMEM dependency to MMIO platform bus driver
| * virtio-pci: make reset operation saferMichael S. Tsirkin2011-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virtio pci device reset actually just does an I/O write, which in PCI is really posted, that is it can complete on CPU before the device has received it. Further, interrupts might have been pending on another CPU, so device callback might get invoked after reset. This conflicts with how drivers use reset, which is typically: reset unregister a callback running after reset completed can race with unregister, potentially leading to use after free bugs. Fix by flushing out the write, and flushing pending interrupts. This assumes that device is never reset from its vq/config callbacks, or in parallel with being added/removed, document this assumption. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * virtio-mmio: Correct the name of the guest features selectorSasha Levin2011-11-23
| | | | | | | | | | | | | | | | | | | | Guest features selector spelling mistake. Cc: Pawel Moll <pawel.moll@arm.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * virtio: add HAS_IOMEM dependency to MMIO platform bus driverHeiko Carstens2011-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | Fix this compile error on s390: CC [M] drivers/virtio/virtio_mmio.o drivers/virtio/virtio_mmio.c: In function 'vm_get_features': drivers/virtio/virtio_mmio.c:107:2: error: implicit declaration of function 'writel' Cc: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* | Merge branch 'upstream-linus' of git://github.com/jgarzik/libata-devLinus Torvalds2011-11-23
|\ \ | | | | | | | | | | | | | | | * 'upstream-linus' of git://github.com/jgarzik/libata-dev: libata: fix build without BMDMA [libata] ahci_platform: fix DT probing
| * | libata: fix build without BMDMAAlexander Beregalov2011-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix these errors: drivers/ata/libata-sff.c:2538:3: error: implicit declaration of function 'ata_pci_bmdma_prepare_host' drivers/ata/libata-sff.c:2549:40: error: 'ata_bmdma_interrupt' undeclared (first use in this function) Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | [libata] ahci_platform: fix DT probingRob Herring2011-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change in commit 904c04feaf13ed "ahci_platform: Add the board_ids..." doesn't work for the DT probing case as platform_get_device_id returns NULL. Pick the default ahci_port_info in this case. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com> Cc: Richard Zhu <richard.zhu@linaro.org> Cc: linux-ide@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* | | Merge branch 'for-linus' of ↵Linus Torvalds2011-11-23
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci: PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs PCI: pciehp: wait 100 ms after Link Training check PCI: pciehp: wait 1000 ms before Link Training check PCI: pciehp: Retrieve link speed after link is trained PCI: Let PCI_PRI depend on PCI PCI: Fix compile errors with PCI_ATS and !PCI_IOV PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug
| * | | PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDsBjorn Helgaas2011-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we claimed device ID 0x7450, regardless of the vendor, which is clearly wrong. Now we'll claim that device ID only for AMD. I suspect this was just a typo in the original code, but it's possible this change will break shpchp on non-7450 AMD bridges. If so, we'll have to fix them as we find them. Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863 Reported-by: Ralf Jung <ralfjung-e@gmx.de> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | PCI: pciehp: wait 100 ms after Link Training checkKenji Kaneshige2011-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the port supports Link speeds greater than 5.0 GT/s, we must wait for 100 ms after Link training completes before sending configuration request. Acked-by: Yinghai Lu <yinghai@kernel.org> Tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | PCI: pciehp: wait 1000 ms before Link Training checkKenji Kaneshige2011-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to wait for 1000 ms after Data Link Layer Link Active (DLLLA) bit reads 1b before sending configuration request. Currently pciehp does this wait after checking Link Training (LT) bit. But we need it before checking LT bit because LT is still set even after DLLLA bit is set on some platforms. Acked-by: Yinghai Lu <yinghai@kernel.org> Tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | PCI: pciehp: Retrieve link speed after link is trainedYinghai Lu2011-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During hot plug, board_added will call pciehp_power_on_slot(). But link speed is updated in pciehp_power_on_slot(). We should not update link speed there, because that is too early. So move the link speed update to pciehp_check_link_status() after making sure the link has been trained. -v2: fix compile warning that Kenji found. Signed-off-by: Yinghai Lu <yinghai.lu@oracle.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | PCI: Let PCI_PRI depend on PCIJoerg Roedel2011-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This avoids the PCI_PRI question in 'make config' when PCI is not selected. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | PCI: Fix compile errors with PCI_ATS and !PCI_IOVJoerg Roedel2011-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ats and sroiv members of 'struct pci_dev' are required for the ATS code already, even without IOV support compiled in. So depend on ATS here. This is fine with PCI_IOV too because it selects PCI_ATS. Also the prototypes for ATS need to be available for PCI_ATS. Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplugRafael J. Wysocki2011-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the kernel has requested control of the PCIe native hotplug feature for a given root complex, the acpiphp driver should not try to handle that root complex and it should leave it to pciehp. Failing to do so causes problems to happen if acpiphp is loaded before pciehp on such systems. To address this issue make find_root_bridges() ignore PCIe root complexes with PCIe native hotplug enabled and make add_bridge() return error code if PCIe native hotplug is enabled for the given root port. This causes acpiphp to refuse to load if PCIe native hotplug is enabled for all complexes and to refuse binding to the root complexes with PCIe native hotplug is enabled. Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | | | Merge branch 'for-linus' of ↵Linus Torvalds2011-11-23
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs: eCryptfs: Extend array bounds for all filename chars eCryptfs: Flush file in vma close eCryptfs: Prevent file create race condition
| * | | | eCryptfs: Extend array bounds for all filename charsTyler Hicks2011-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From mhalcrow's original commit message: Characters with ASCII values greater than the size of filename_rev_map[] are valid filename characters. ecryptfs_decode_from_filename() will access kernel memory beyond that array, and ecryptfs_parse_tag_70_packet() will then decrypt those characters. The attacker, using the FNEK of the crafted file, can then re-encrypt the characters to reveal the kernel memory past the end of the filename_rev_map[] array. I expect low security impact since this array is statically allocated in the text area, and the amount of memory past the array that is accessible is limited by the largest possible ASCII filename character. This patch solves the issue reported by mhalcrow but with an implementation suggested by Linus to simply extend the length of filename_rev_map[] to 256. Characters greater than 0x7A are mapped to 0x00, which is how invalid characters less than 0x7A were previously being handled. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by: Michael Halcrow <mhalcrow@google.com> Cc: stable@kernel.org
| * | | | eCryptfs: Flush file in vma closeTyler Hicks2011-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dirty pages weren't being written back when an mmap'ed eCryptfs file was closed before the mapping was unmapped. Since f_ops->flush() is not called by the munmap() path, the lower file was simply being released. This patch flushes the eCryptfs file in the vm_ops->close() path. https://launchpad.net/bugs/870326 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Cc: stable@kernel.org [2.6.39+]
| * | | | eCryptfs: Prevent file create race conditionTyler Hicks2011-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The file creation path prematurely called d_instantiate() and unlock_new_inode() before the eCryptfs inode info was fully allocated and initialized and before the eCryptfs metadata was written to the lower file. This could result in race conditions in subsequent file and inode operations leading to unexpected error conditions or a null pointer dereference while attempting to use the unallocated memory. https://launchpad.net/bugs/813146 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Cc: stable@kernel.org
generated by cgit v1.2.2 (git 2.25.0) at 2025-02-10 10:02:14 -0500