- 01 7月, 2013 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller" This reverts commit 8d2f8cd4. As reported by Stefan, this device already works with the parport_serial driver, so the 8250_pci driver should not also try to grab it as well. Reported-by: NStefan Seyfried <stefan.seyfried@googlemail.com> Cc: Wang YanQing <udknight@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 6月, 2013 7 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
... and single return is quite sufficient to get out of function, TYVM Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 28 6月, 2013 1 次提交
-
-
由 Dave Airlie 提交于
Reported-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 27 6月, 2013 3 次提交
-
-
由 Josh Durgin 提交于
Sending the right snapshot context with each write is required for snapshots to work. Due to the ordering of calls, the snapshot context is never set for any requests. This causes writes to the current version of the image to be reflected in all snapshots, which are supposed to be read-only. This happens because rbd_osd_req_format_write() sets the snapshot context based on obj_request->img_request. At this point, however, obj_request->img_request has not been set yet, to the snapshot context is set to NULL. Fix this by moving rbd_img_obj_request_add(), which sets obj_request->img_request, before the osd request formatting calls. This resolves: http://tracker.ceph.com/issues/5465Reported-by: NKarol Jurak <karol.jurak@gmail.com> Signed-off-by: NJosh Durgin <josh.durgin@inktank.com> Reviewed-by: NSage Weil <sage@inktank.com> Reviewed-by: NAlex Elder <elder@linaro.org>
-
由 Zefan Li 提交于
We triggered an oops while running trinity with 3.4 kernel: BUG: unable to handle kernel paging request at 0000000100000d07 IP: [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci] PGD 640c0d067 PUD 0 Oops: 0000 [#1] PREEMPT SMP CPU 3 ... Pid: 7302, comm: trinity-child3 Not tainted 3.4.24.09+ 40 Huawei Technologies Co., Ltd. Tecal RH2285 /BC11BTSA RIP: 0010:[<ffffffffa0109738>] [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci] ... Call Trace: [<ffffffff8137c5c3>] sock_ioctl+0x153/0x280 [<ffffffff81195494>] do_vfs_ioctl+0xa4/0x5e0 [<ffffffff8118354a>] ? fget_light+0x3ea/0x490 [<ffffffff81195a1f>] sys_ioctl+0x4f/0x80 [<ffffffff81478b69>] system_call_fastpath+0x16/0x1b ... It's because the net device is not a dlci device. Reported-by: NLi Jinyue <lijinyue@huawei.com> Signed-off-by: NLi Zefan <lizefan@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Zefan Li 提交于
Otherwise the net device returned can be freed at anytime. Signed-off-by: NLi Zefan <lizefan@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 6月, 2013 11 次提交
-
-
由 Javier Martinez Canillas 提交于
Commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping") converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ domain instead of using a legacy mapping. Not using a legacy mapping has a number of benefits but it requires the platform to support SPARSE_IRQ which currently is not supported on OMAP1. So this change caused a regression on OMAP1 platforms [1]. Since this issue is not present on all OMAP2+ platforms, there is no need to revert the driver to use legacy domain mapping for all the platforms. [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89005.htmlSigned-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Darren Hart 提交于
Use DMI_BOARD_NAME to determine if we are running on a MinnowBoard and set the uart clock to 50MHz if so. This removes the need to pass the user_uartclk to the kernel at boot time. Signed-off-by: NDarren Hart <dvhart@linux.intel.com> Cc: Jiri Slaby <jslaby@suse.cz> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Gavin Shan 提交于
When the EEH error is the result of a fenced host bridge, MMIO accesses can be very slow (milliseconds) to timeout and return all 1's, thus causing the driver various timeout loops to take way too long and trigger soft-lockup warnings (in addition to taking minutes to recover). It might be worthwhile to check if for any of these cases, ffffffff is a valid possible value, and if not, bail early since that means the HW is either gone or isolated. In the meantime, checking that the PCI channel is offline would be workaround of the problem. Cc: <stable@vger.kernel.org> # v3.0+ Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
it does not compile since 09fc7d ("usb: musb: fix incorrect usage of resource pointer"). What makes me wonder most is if source of the Tested-by tag :) Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Fabio Estevam 提交于
commit ea1418b5 (usb: chipidea: i.MX: use devm_usb_get_phy_by_phandle to get phy) causes the USB host to miss the disconnect/connect events. In order to reproduce this problem: - Insert a USB thumb into the USB host port (connection is detected) - Remove it (no disconnect event will be reported) - Insert the USB thumb again (connection is not detected) Fix this problem by accessing the usb_phy structure using the private data instead of accessing a local structure. Tested on a mx28evk board. Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Acked-by: NPeter Chen <peter.chen@freescale.com> Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Emil Goode 提交于
This patch adds missing unlocks on error paths in the xhci_free_streams and xhci_configure_endpoint functions. Signed-off-by: NEmil Goode <emilgoode@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Michael S. Tsirkin 提交于
get user pages might fail partially in macvtap zero copy mode. To recover we need to put all pages that we got, but code used a wrong index resulting in double-free errors. Reported-by: NBrad Hubbard <bhubbard@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NJason Wang <jasowang@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael S. Tsirkin 提交于
get user pages might fail partially in tun zero copy mode. To recover we need to put all pages that we got, but code used a wrong index resulting in double-free errors. Reported-by: NBrad Hubbard <bhubbard@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NJason Wang <jasowang@redhat.com> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jacob Shin 提交于
When initializing the default powersave_bias value, we need to first make sure that this policy is running the ondemand governor. Reported-and-tested-by: NTim Gardner <tim.gardner@canonical.com> Signed-off-by: NJacob Shin <jacob.shin@amd.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Josh Durgin 提交于
rbd_dev_v2_header_onetime() fetches striping information, and checks whether the image can be read by compariing the stripe unit to the object size. It determines the object size by shifting the object order, which is 0 at this point since it has not been read yet. Move the call to get the image size and object order before rbd_dev_v2_header_onetime() so it is set before use. Signed-off-by: NJosh Durgin <josh.durgin@inktank.com> Reviewed-by: NSage Weil <sage@inktank.com>
-
由 Robert Love 提交于
fcoe_xmit was coded such that it would skip the vlan net device/layer and instead set some vlan flags and transmit on the real net device. The real net device has code that would add the vlan tag for fcoe skbs. This avoids some extra processing for data frames and provides a small performance improvement. Since fcoe_xmit was not using the vlan net device, __vlan_put_tag within the real net device's xmit routine was ultimately being called to set the vlan tag. With the below change the behavior of __vlan_put_tag changed slightly, it now sets the skb->protocol = vlan_proto. vlan_proto was not a field being set by fcoe_xmit, so the skb->protocol is now not being set to ETH_P_8021Q, as it should be. This patch converts fcoe_xmit to use the vlan_put_tag routine which will tag the skb and fcoe will continue to transmit fcoe skbs on the real net device. For reference, the below change was the one that altered the __vlan_put_tag behavior. commit 86a9bad3 Author: Patrick McHardy <kaber@trash.net> Date: Fri Apr 19 02:04:30 2013 +0000 net: vlan: add protocol argument to packet tagging functions Add a protocol argument to the VLAN packet tagging functions. In case of HW tagging, we need that protocol available in the ndo_start_xmit functions, so it is stored in a new field in the skb. The new field fits into a hole (on 64 bit) and doesn't increase the sks's size. Signed-off-by: NRobert Love <robert.w.love@intel.com> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
-
- 25 6月, 2013 15 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
Git commit 90797e6d ("drm/i915: create compact dma scatter lists for gem objects") makes certain assumptions about the under laying DMA API that are not always correct. On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup I see: [drm:intel_pipe_set_base] *ERROR* pin & fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 Bit of debugging traced it down to dma_map_sg failing (in i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB). That unfortunately are sizes that the SWIOTLB is incapable of handling - the maximum it can handle is a an entry of 512KB of virtual contiguous memory for its bounce buffer. (See IO_TLB_SEGSIZE). Previous to the above mention git commit the SG entries were of 4KB, and the code introduced by above git commit squashed the CPU contiguous PFNs in one big virtual address provided to DMA API. This patch is a simple semi-revert - were we emulate the old behavior if we detect that SWIOTLB is online. If it is not online then we continue on with the new compact scatter gather mechanism. An alternative solution would be for the the '.get_pages' and the i915_gem_gtt_prepare_object to retry with smaller max gap of the amount of PFNs that can be combined together - but with this issue discovered during rc7 that might be too risky. Reported-and-Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Imre Deak <imre.deak@intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: David Airlie <airlied@linux.ie> CC: <dri-devel@lists.freedesktop.org> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Boris BREZILLON 提交于
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to avoid common clk framework warnings. Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Dan Williams 提交于
These devices are all Gobi1K devices (according to the Windows INF files) and should be handled by qcserial instead of option. Their network port is handled by qmi_wwan. Signed-off-by: NDan Williams <dcbw@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Boris BREZILLON 提交于
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to avoid common clk framework warnings. Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Boris BREZILLON 提交于
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to avoid common clk framework warnings. Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Thomas Pugliese 提交于
This patch fixes a race condition that caused the HWA_HC interface probe function to occasionally fail. The HWA_HC would attempt to register itself with the HWA_RC by searching for a uwb_rc class device with the same parent device ptr. If the probe function for the HWA_RC interface had yet to run, the uwb_rc class device would not have been created causing the look up to fail and the HWA_HC probe function to return an error causing the device to be unusable. The fix is for the HWA to delay registering with the HWA_RC until receiving the command from userspace to start the wireless channel. It is the responsibility of userspace to ensure that the uwb_rc class device has been created before starting the HWA channel. Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Thomas Pugliese 提交于
This patch adds a sysfs attribute for the wireless host controller transaction retry count. It also changes the default value from 15 retries to infinite retries because the driver currently does not handle retry errors gracefully. Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Thomas Pugliese 提交于
This patch adds a sysfs attribute for the wireless USB host controller device notification transmit slot(DNTS) count and interval. It also changes the defaults from 16 slots in every MMC to a more reasonable 4 slots every 2ms. Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Shishkin 提交于
"ci13xxx" is bad for at least the following reasons: * people often mistype it * it doesn't add any informational value to the names it's used in * it needlessly attracts mail filters This patch replaces it with "ci_hdrc", "ci_udc" or "ci_hw", depending on the situation. Modules with ci13xxx prefix are also renamed accordingly and aliases are added for compatibility. Otherwise, no functional changes. Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Wei Yongjun 提交于
Remove duplicated include. Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 George Cherian 提交于
Do a release_mem_region of the hcd resource. Without this the subsequent insertion of module fails in request_mem_region. Signed-off-by: NGeorge Cherian <george.cherian@ti.com> Acked-by: NFelipe Balbi <balbi@ti.com> Cc: stable <stable@vger.kernel.org> # 3.4+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Arnaud Patard (Rtp) 提交于
Allow udev to autoload the module when booting with device-tree Signed-off-by: NArnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Aaron Lu 提交于
Commit 30dcf76a "libata: migrate ACPI code over to new bindings" mistakenly dropped the code to register hotplug notificaion handler for ATA port/devices, causing regression for people using ATA bay, as kernel bug #59871 shows. Fix this by adding back the hotplug notification handler registration code. Since this code has to be run once and notification needs to be installed on every ATA port/devices handle no matter if there is actual device attached, we can't do this in binding time for ATA device ACPI handle, as the binding only occurs when a SCSI device is created, i.e. there is device attached. So introduce the ata_acpi_hotplug_init() function to loop scan all ATA ACPI handles and if it is available, install the notificaion handler for it during ATA init time. With the ATA ACPI handle binding to SCSI device tree, it is possible now that when the SCSI hotplug work removes the SCSI device, the ACPI unbind function will find that the corresponding ACPI device has already been deleted by dock driver, causing a scaring message like: [ 128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt Fix this by waiting for SCSI hotplug task finish in our notificaion handler, so that the removal of ACPI device done in ACPI unbind function triggered by the removal of SCSI device is run earlier when ACPI device is still available. [rjw: Rebased] References: https://bugzilla.kernel.org/show_bug.cgi?id=59871Reported-bisected-and-tested-by: NDirk Griesbach <spamthis@freenet.de> Signed-off-by: NAaron Lu <aaron.lu@intel.com> Acked-by: NTejun Heo <tj@kernel.org> Cc: 3.6+ <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Sujith Manoharan 提交于
Make sure that a chip reset is done when IDLE is turned off - this fixes authentication timeouts. Cc: stable@vger.kernel.org Reported-by: NIgnacy Gawedzki <i@lri.fr> Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
ath_txq_schedule is called outside of the drv_tx call, so it needs RCU protection. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 24 6月, 2013 2 次提交
-
-
由 Marc Dietrich 提交于
Change the device name of the regulator function to the one chosen for MODULE_ALIAS. This fixes kernel auto-module loading for the regulator function. Signed-off-by: NMarc Dietrich <marvin24@gmx.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Rafael J. Wysocki 提交于
The interactions between the ACPI dock driver and the ACPI-based PCI hotplug (acpiphp) are currently problematic because of ordering issues during hot-remove operations. First of all, the current ACPI glue code expects that physical devices will always be deleted before deleting the companion ACPI device objects. Otherwise, acpi_unbind_one() will fail with a warning message printed to the kernel log, for example: [ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt [ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt [ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt [ 180.013656] port1: Oops, 'acpi_handle' corrupt This means, in particular, that struct pci_dev objects have to be deleted before the struct acpi_device objects they are "glued" with. Now, the following happens the during the undocking of an ACPI-based dock station: 1) hotplug_dock_devices() invokes registered hotplug callbacks to destroy physical devices associated with the ACPI device objects depending on the dock station. It calls dd->ops->handler() for each of those device objects. 2) For PCI devices dd->ops->handler() points to handle_hotplug_event_func() that queues up a separate work item to execute _handle_hotplug_event_func() for the given device and returns immediately. That work item will be executed later. 3) hotplug_dock_devices() calls dock_remove_acpi_device() for each device depending on the dock station. This runs acpi_bus_trim() for each of them, which causes the underlying ACPI device object to be destroyed, but the work items queued up by handle_hotplug_event_func() haven't been started yet. 4) _handle_hotplug_event_func() queued up in step 2) are executed and cause the above failure to happen, because the PCI devices they handle do not have the companion ACPI device objects any more (those objects have been deleted in step 3). The possible breakage doesn't end here, though, because hotplug_dock_devices() may return before at least some of the _handle_hotplug_event_func() work items spawned by it have a chance to complete and then undock() will cause _DCK to be evaluated and that will cause the devices handled by the _handle_hotplug_event_func() to go away possibly while they are being accessed. This means that dd->ops->handler() for PCI devices should not point to handle_hotplug_event_func(). Instead, it should point to a function that will do the work of _handle_hotplug_event_func() synchronously. For this reason, introduce such a function, hotplug_event_func(), and modity acpiphp_dock_ops to point to it as the handler. Unfortunately, however, this is not sufficient, because if the dock code were not changed further, hotplug_event_func() would now deadlock with hotplug_dock_devices() that called it, since it would run unregister_hotplug_dock_device() which in turn would attempt to acquire the dock station's hp_lock mutex already acquired by hotplug_dock_devices(). To resolve that deadlock use the observation that unregister_hotplug_dock_device() won't need to acquire hp_lock if PCI bridges the devices on the dock station depend on are prevented from being removed prematurely while the first loop in hotplug_dock_devices() is in progress. To make that possible, introduce a mechanism by which the callers of register_hotplug_dock_device() can provide "init" and "release" routines that will be executed, respectively, during the addition and removal of the physical device object associated with the given ACPI device handle. Make acpiphp use two new functions, acpiphp_dock_init() and acpiphp_dock_release(), that call get_bridge() and put_bridge(), respectively, on the acpiphp bridge holding the given device, for this purpose. In addition to that, remove the dock station's list of "hotplug devices" and make the dock code always walk the whole list of "dependent devices" instead in such a way that the loops in hotplug_dock_devices() and dock_event() (replacing the loops over "hotplug devices") will take references to the list entries that register_hotplug_dock_device() has been called for. That prevents the "release" routines associated with those entries from being called while the given entry is being processed and for PCI devices this means that their bridges won't be removed (by a concurrent thread) while hotplug_event_func() handling them is being executed. This change is based on two earlier patches from Jiang Liu. References: https://bugzilla.kernel.org/show_bug.cgi?id=59501Reported-and-tested-by: NAlexander E. Patrakov <patrakov@gmail.com> Tracked-down-by: NJiang Liu <jiang.liu@huawei.com> Tested-by: NIllya Klymov <xanf@xanf.me> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org>
-