- 29 6月, 2011 4 次提交
-
-
由 Benjamin Herrenschmidt 提交于
This will allow a different backend to share it Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
On pseries machines, consoles are provided by the hypervisor using a low level get_chars/put_chars type interface. However, this is really just a transport to the service processor which implements them either as "raw" console (networked consoles, HMC, ...) or as "hvsi" serial ports. The later is a simple packet protocol on top of the raw character interface that is supposed to convey additional "serial port" style semantics. In practice however, all it does is provide a way to read the CD line and set/clear our DTR line, that's it. We currently implement the "raw" protocol as an hvc console backend (/dev/hvcN) and the "hvsi" protocol using a separate tty driver (/dev/hvsi0). However this is quite impractical. The arbitrary difference between the two type of devices has been a major source of user (and distro) confusion. Additionally, there's an additional mini -hvsi implementation in the pseries platform code for our low level debug console and early boot kernel messages, which means code duplication, though that low level variant is impractical as it's incapable of doing the initial protocol negociation to establish the link to the FSP. This essentially replaces the dedicated hvsi driver and the platform udbg code completely by extending the existing hvc_vio backend used in "raw" mode so that: - It now supports HVSI as well - We add support for hvc backend providing tiocm{get,set} - It also provides a udbg interface for early debug and boot console This is overall less code, though this will only be obvious once we remove the old "hvsi" driver, which is still available for now. When the old driver is enabled, the new code still kicks in for the low level udbg console, replacing the old mini implementation in the platform code, it just doesn't provide the higher level "hvc" interface. In addition to producing generally simler code, this has several benefits over our current situation: - The user/distro only has to deal with /dev/hvcN for the hypervisor console, avoiding all sort of confusion that has plagued us in the past - The tty, kernel and low level debug console all use the same code base which supports the full protocol establishment process, thus the console is now available much earlier than it used to be with the old HVSI driver. The kernel console works much earlier and udbg is available much earlier too. Hackers can enable a hard coded very-early debug console as well that works with HVSI (previously that was only supported for the "raw" mode). I've tried to keep the same semantics as hvsi relative to how I react to things like CD changes, with some subtle differences though: - I clear DTR on close if HUPCL is set - Current hvsi triggers a hangup if it detects a up->down transition on CD (you can still open a console with CD down). My new implementation triggers a hangup if the link to the FSP is severed, and severs it upon detecting a up->down transition on CD. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
Embed the struct hvsi_header in the various packet definitions rather than open coding it multiple times. Will help provide stronger type checking. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
This moves various HVSI protocol definitions from the hvsi.c driver to a header file that can be used later on by a udbg implementation Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 09 6月, 2011 2 次提交
-
-
由 Steffen Sledz 提交于
E.g. newer CAN 2.0 A/B <=> USB 2.0 converters report idProduct=f3c2. Signed-off-by: NSteffen Sledz <sledz@dresearch-fe.de> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Geert Uytterhoeven 提交于
One new offender detected by the recently increased type checking in platform_get_drvdata(): drivers/rtc/rtc-m41t93.c: In function ‘m41t93_remove’: drivers/rtc/rtc-m41t93.c:192: warning: passing argument 1 of ‘platform_get_drvdata’ from incompatible pointer type Use spi_get_drvdata() instead of platform_get_drvdata(), cfr. commit 42fea15d ("spi/rtc-{ds1390,ds3234,m41t94}: Use spi_get_drvdata() for SPI devices") Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 08 6月, 2011 13 次提交
-
-
由 Linus Torvalds 提交于
The flush_to_ldisc() work entry has special logic to notice when it has seen the original tail of the data queue, and it avoids continuing the flush if it sees that _original_ tail rather than the current tail. This logic can trigger in case somebody is constantly adding new data to the tty while the flushing is active - and the intent is to avoid excessive CPU usage while flushing the tty, especially as we used to do this from a softirq context which made it non-preemptible. However, since we no longer re-arm the work-queue from within itself (because that causes other trouble: see commit a5660b41 "tty: fix endless work loop when the buffer fills up"), this just leads to possible hung tty's (most easily seen in SMP and with a test-program that floods a pty with data - nobody seems to have reported this for any real-life situation yet). And since the workqueue isn't done from timers and softirq's any more, it's doubtful whether the CPU useage issue is really relevant any more. So just remove the logic entirely, and see if anybody ever notices. Alternatively, we might want to re-introduce the "re-arm the work" for just this case, but then we'd have to re-introduce the delayed work model or some explicit timer, which really doesn't seem worth it for this. Reported-and-tested-by: NGuillaume Chazarain <guichaz@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alex Deucher 提交于
The current RE'd code causes blank screens and display problems on a lot of systems. So disable it by default for now. It can still be enabled by setting the audio parameter to 1. E.g.: radeon.audio=1 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38010 https://bugs.freedesktop.org/show_bug.cgi?id=27731 https://bugs.freedesktop.org/show_bug.cgi?id=35970 https://bugs.freedesktop.org/show_bug.cgi?id=26195 and many other reported problems. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Haid 提交于
On my x86_64 system with >4GB of ram and swiotlb instead of a hardware iommu (because I have a VIA chipset), the call to pci_set_dma_mask (see below) with 40bits returns an error. But it seems that the radeon driver is designed to have need_dma32 = true exactly if pci_set_dma_mask is called with 32 bits and false if it is called with 40 bits. I have read somewhere that the default are 32 bits. So if the call fails I suppose that need_dma32 should be set to true. And indeed the patch fixes the problem I have had before and which I had described here: http://choon.net/forum/read.php?21,106131,115940Acked-by: NAlex Deucher <alexdeucher@gmail.com> cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Wierdly the kms parser never initialised the family, it wasn't really used much, but the fmt checker patch started using it and it fell over. Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Greg Kroah-Hartman 提交于
This reverts commit a559d2c8. Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc when the option driver tries to bind to it. So revert this as it doesn't seem to be needed at all. Thanks to Michael Tokarev and Paweł Drobek for working on resolving this issue. Cc: Paweł Drobek <pawel.drobek@gmail.com> Cc: Michael Tokarev <mjt@tls.msk.ru> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Rafael J. Wysocki 提交于
The loops over connection ID strings in pm_runtime_clk_notify() should actually iterate over the strings and not over the elements of the first of them, so make them behave as appropriate. This fixes a regression introduced by commit 600b776e (OMAP1 / PM: Use generic clock manipulation routines for runtime PM). Reported-and-tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 H Hartley Sweeten 提交于
The Samsung GPIO drivers are always built-in when the relevant platform is selected. Change the Kconfig symbol to def_bool y dependant on the platform. Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Rafael J. Wysocki 提交于
If CONFIG_PM is not set, init_iommu_pm_ops() introduced by commit 134fac3f (PCI / Intel IOMMU: Use syscore_ops instead of sysdev class and sysdev) is not defined appropriately. Fix this issue. Reported-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Thomas Abraham 提交于
The S3C_GPIO_PULL_UP macro value incorrectly maps to a reserved setting of GPIO pull up/down registers on Exynos4 platform. Fix this incorrect mapping by adding wrappers to the s3c_gpio_setpull_updown and s3c_gpio_getpull_updown functions. Signed-off-by: NThomas Abraham <thomas.ab@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Julia Lawall 提交于
Add a label before the call to clk_put and jump to that in the error handling code that occurs after the call to clk_get has succeeded. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ expression e1,e2; statement S; @@ e1 = clk_get@p1(...); ... when != e1 = e2 when != clk_put(e1) when any if (...) { ... when != clk_put(e1) when != if (...) { ... clk_put(e1) ... } * return@p3 ...; } else S // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Acked-by: NEric Miao <eric.y.miao@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Stern 提交于
This patch (as1468) changes the Kconfig definition for USB_GADGET_DUALSPEED. This option is determined entirely by which device controller drivers are to be built, through Select statements; it does not need to be (and should not be) configurable by the user. Also, the "default n" line is superfluous -- everything defaults to N. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Stern 提交于
Like with other host controllers capable of operating at both high speed and full speed, we need to indicate that the emulated controller presented by dummy-hcd has this ability. Otherwise usbcore will not accept full-speed gadgets under dummy-hcd. This patch (as1469) sets the appropriate has_tt flag. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Stern 提交于
Some USB mass-storage devices have bugs that cause them not to handle the first READ(10) command they receive correctly. The Corsair Padlock v2 returns completely bogus data for its first read (possibly it returns the data in encrypted form even though the device is supposed to be unlocked). The Feiya SD/SDHC card reader fails to complete the first READ(10) command after it is plugged in or after a new card is inserted, returning a status code that indicates it thinks the command was invalid, which prevents the kernel from retrying the read. Since the first read of a new device or a new medium is for the partition sector, the kernel is unable to retrieve the device's partition table. Users have to manually issue an "hdparm -z" or "blockdev --rereadpt" command before they can access the device. This patch (as1470) works around the problem. It adds a new quirk flag, US_FL_INVALID_READ10, indicating that the first READ(10) should always be retried immediately, as should any failing READ(10) commands (provided the preceding READ(10) command succeeded, to avoid getting stuck in a loop). The patch also adds appropriate unusual_devs entries containing the new flag. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NSven Geggus <sven-usbst@geggus.net> Tested-by: NPaul Hartman <paul.hartman+linux@gmail.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> CC: <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 07 6月, 2011 21 次提交
-
-
Can't find evidence that this is actually done. Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
I doubt the clock is optional. In case it is it should not return with an error code because we leak everything. Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
this is more backwords than it has to be. Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
|drivers/usb/gadget/mv_udc_core.c:2108: error: label `error' used but not defined This seems to be broken since the initial commit. I changed this to a simple return. The other user is the probe code which lets ->probe() fail on error here. |drivers/usb/gadget/mv_udc_core.c:2107: warning: passing argument 1 of `dev_err' from incompatible pointer type |drivers/usb/gadget/mv_udc_core.c:2118: warning: initialization from incompatible pointer type |drivers/usb/gadget/mv_udc_core.c:2119: warning: initialization from incompatible pointer type |drivers/usb/gadget/mv_udc_core.c:2130: error: initializer element is not constant |drivers/usb/gadget/mv_udc_core.c:2130: error: (near initialization for `udc_driver.driver.pm') Cc: Chao Xie <chao.xie@marvell.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bryan Wu 提交于
drivers/usb/gadget/at91_udc.c: In function 'write_fifo': drivers/usb/gadget/at91_udc.c:421:2: error: implicit declaration of function 'prefetch' make[3]: *** [drivers/usb/gadget/at91_udc.o] Error 1 make[2]: *** [drivers/usb/gadget] Error 2 make[2]: *** Waiting for unfinished jobs.... Signed-off-by: NBryan Wu <bryan.wu@canonical.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Mark Brown 提交于
Currently the s3c-hsotg driver is extremely chatty, producing voluminous with large register dumps even in default operation. Tone this down so we're not chatty unless DEBUG is defined. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Sage Weil 提交于
Commit 64252c75 (vfs: remove dget() from dentry_unhash()) removed the useless dget from dentry_unhash but didn't fix up this caller in the usb code. There used to be exactly one dput per dentry_unhash call; now there are none. Tested-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NSage Weil <sage@newdream.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Ben Skeggs 提交于
PCI(E)GART isn't quite stable it seems, fall back to old method until I get the time to sort it out properly. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Hopefully the cause of nvc0 "page jumping" issue. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Reported-by: NMario Bachmann <grafgrimm77@gmx.de> Tested-by: NGreg Turner <gmturner007@ameritech.net> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Fixes various potential oopses. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Should hopefully get modesetting at least from this, it appears these are GF119 chipsets. Accel will come eventually, once I order a board. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Colin Cross 提交于
_set_gpio_triggering uses read-modify-write on bank registers, lock bank->lock around all calls to it to prevent register corruption if two cpus access gpios in the same bank at the same time. Signed-off-by: NColin Cross <ccross@android.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Colin Cross 提交于
Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits, causing only the last bit set to take effect, resulting in lost wakeups when the GPIO controller is in idle. Replace direct writes to IRQWAKEN with MOD_REG_BIT calls to perform a read-modify-write on the register. Signed-off-by: NColin Cross <ccross@android.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Russell King 提交于
WARNING: arch/arm/plat-omap/built-in.o(.devinit.text+0x46c): Section mismatch in reference from the function omap_gpio_probe() to the function .init.text:omap_gpio_chip_init() The function __devinit omap_gpio_probe() references a function __init omap_gpio_chip_init(). If omap_gpio_chip_init is only used by omap_gpio_probe then annotate omap_gpio_chip_init with a matching annotation. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Libor Pechacek 提交于
Protocol stall should not be fatal while reading port or hub status as it is transient state. Currently hub EP0 STALL during port status read results in failed device enumeration. This has been observed with ST-Ericsson (formerly Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard. Signed-off-by: NLibor Pechacek <lpechacek@suse.cz> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Mike Frysinger 提交于
After the prefetch/list.h restructure, drivers need to explicitly include linux/prefetch.h in order to use the prefetch() function. Otherwise, the current driver fails to build: drivers/usb/musb/musb_core.c: In function 'musb_write_fifo': drivers/usb/musb/musb_core.c:219: error: implicit declaration of function 'prefetch' make[3]: *** [drivers/usb/musb/musb_core.o] Error 1 Signed-off-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Toby Gray 提交于
This adds the Nokia E7 and C7 to the list of devices in cdc-acm, allowing the secondary ACM channel on the device to be exposed. Without this patch the ACM driver won't claim this secondary channel as it's marked as having a vendor-specific protocol. Signed-off-by: NToby Gray <toby.gray@realvnc.com> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alexey Khoroshilov 提交于
ep_write() acquires data->lock mutex in get_ready_ep() and releases it on all paths except for one: when usb_endpoint_xfer_isoc() failed. The patch adds mutex_unlock(&data->lock) at that path. It is similar to commit 00cc7a5f ("usb-gadget: unlock data->lock mutex on error path in ep_read()"), it was not fixed at that time by accident. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Torsten Hilbrich 提交于
The funtion option_send_status times out when sending USB messages to the interfaces 0, 1, and 2 of this UMTS stick. This results in a 5s timeout in the function causing other tty operations to feel very sluggish. This patch adds a blacklist entry for these 3 interfaces on the ZTE K3765-Z device. I was also able to reproduce the problem with v2.6.38 and v2.6.39. This is very similar to a problem fixed in commit 7a89e4cb Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Date: Wed Mar 9 09:19:48 2011 +0000 USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626 Signed-off-by: NTorsten Hilbrich <torsten.hilbrich@secunet.com> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-