- 17 4月, 2013 4 次提交
-
-
由 Matt Fleming 提交于
efivars.c has grown far too large and needs to be divided up. Create a new directory and move the persistence storage code to efi-pstore.c now that it uses the new efivar API. This helps us to greatly reduce the size of efivars.c and paves the way for moving other code out of efivars.c. Note that because CONFIG_EFI_VARS can be built as a module efi-pstore must also include support for building as a module. Reviewed-by: NTom Gundersen <teg@jklm.no> Tested-by: NTom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Anton Vorontsov <cbouatmailru@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Kees Cook <keescook@chromium.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: NTom Gundersen <teg@jklm.no> Tested-by: NTom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
Some machines have an EFI variable interface that does not conform to the UEFI specification, e.g. CONFIG_GOOGLE_SMI. Add the necessary code so that it's only possible to use one implementation of EFI variable operations at runtime. This allows us to keep a single (file-scope) global pointer 'struct efivars', which simplifies access. This will hopefully dissuade developers from accessing the generic operations struct directly in the future, as was done in the efivarfs and pstore code, thereby allowing future code to work with both the generic efivar ops and the google SMI ops. This may seem like a step backwards in terms of modularity, but we don't need to track more than one 'struct efivars' at one time. There is no synchronisation done between multiple EFI variable operations, and according to Mike no one is using both the generic EFI var ops and CONFIG_GOOGLE_SMI simultaneously, though a single kernel build _does_ need to able to support both. It also helps to clearly highlight which functions form the core of the efivars interface - those that require access to __efivars. Reviewed-by: NTom Gundersen <teg@jklm.no> Tested-by: NTom Gundersen <teg@jklm.no> Acked-by: NMike Waychison <mikew@google.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
There are currently two implementations of the utf16 string functions. Somewhat confusingly, they've got different names. Centralise the functions in efi.h. Reviewed-by: NTom Gundersen <teg@jklm.no> Tested-by: NTom Gundersen <teg@jklm.no> Reviewed-by: NMike Waychison <mikew@google.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
- 30 3月, 2013 3 次提交
-
-
由 Andy Shevchenko 提交于
On some hardware configurations we have got the request line with the offset. The patch introduces convert_slave_id() helper for that cases. The request line base is came from the driver data provided by the platform_device_id table. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
由 Arnd Bergmann 提交于
As reported by Wu Fengguang's build robot tracking sparse warnings, the dma_spec arguments in the dw_dma_xlate are already byte swapped on little-endian platforms and must not get swapped again. This code is currently not used anywhere, but will be used in Linux 3.10 when the ARM SPEAr platform starts using the generic DMA DT binding. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Reported-by: NFengguang Wu <fengguang.wu@intel.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
由 Alex Elder 提交于
A result of ENOENT from a read request for an object that's part of an rbd image indicates that there is a hole in that portion of the image. Similarly, a short read for such an object indicates that the remainder of the read should be interpreted a full read with zeros filling out the end of the request. This behavior is not correct for objects that are not backing rbd image data. Currently rbd_img_obj_request_callback() assumes it should be done for all objects. Change rbd_img_obj_request_callback() so it only does this zeroing for image objects. Encapsulate that special handling in its own function. Add an assertion that the image object request is a bio request, since we assume that (and we currently don't support any other types). This resolves a problem identified here: http://tracker.ceph.com/issues/4559 The regression was introduced by bf0d5f50. Reported-by: NDan van der Ster <dan@vanderster.com> Signed-off-by: NAlex Elder <elder@inktank.com> Reviewed-off-by: NSage Weil <sage@inktank.com>
-
- 29 3月, 2013 2 次提交
-
-
由 Nicholas Bellinger 提交于
This patch fixes a regression introduced in v3.8-rc1 code where a failed target_check_reservation() check in target_setup_cmd_from_cdb() was causing an incorrect SAM_STAT_GOOD status to be returned during a WRITE operation performed by an unregistered / unreserved iscsi initiator port. This regression is only effecting iscsi-target due to a special case check for TCM_RESERVATION_CONFLICT within iscsi_target_erl1.c:iscsit_execute_cmd(), and was still correctly disallowing WRITE commands from backend submission for unregistered / unreserved initiator ports, while returning the incorrect SAM_STAT_GOOD status due to the missing SAM_STAT_RESERVATION_CONFLICT assignment. This regression was first introduced with: commit de103c93 Author: Christoph Hellwig <hch@lst.de> Date: Tue Nov 6 12:24:09 2012 -0800 target: pass sense_reason as a return value Go ahead and re-add the missing SAM_STAT_RESERVATION_CONFLICT assignment during a target_check_reservation() failure, so that iscsi-target code sends the correct SCSI status. All other fabrics using target_submit_cmd_*() with a RESERVATION_CONFLICT call to transport_generic_request_failure() are not effected by this bug. Reported-by: NJeff Leung <jleung@curriegrad2004.ca> Cc: Christoph Hellwig <hch@lst.de> Cc: <stable@vger.kernel.org> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Nicholas Bellinger 提交于
This patch adds a VHOST_SCSI_FEATURES mask minus VIRTIO_RING_F_EVENT_IDX so that vhost-scsi-pci userspace will strip this feature bit once GET_FEATURES reports it as being unsupported on the host. This is to avoid a bug where ->handle_kicks() are missed when EVENT_IDX is enabled by default in userspace code. (mst: Rename to VHOST_SCSI_FEATURES + add comment) Acked-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NAsias He <asias@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
- 28 3月, 2013 4 次提交
-
-
由 Konstantin Holoborodko 提交于
It enhances the driver for FTDI-based USB serial adapters to recognize Mitsubishi Electric Corp. USB/RS422 Converters as FT232BM chips and support them. https://search.meau.com/?q=FX-USB-AWSigned-off-by: NKonstantin Holoborodko <klh.kernel@gmail.com> Tested-by: NKonstantin Holoborodko <klh.kernel@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Wei Yongjun 提交于
Fix to return a negative error code from the error handling case instead of 0, as returned elsewhere in this function. Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Reviewed-by: NJingoo Han <jg1.han@samsung.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 David Vrabel 提交于
In unmask_evtchn(), when the mask bit is cleared after testing for pending and the event becomes pending between the test and clear, then the upcall will not become pending and the event may be lost or delayed. Avoid this by always clearing the mask bit before checking for pending. If a hypercall is needed, remask the event as EVTCHNOP_unmask will only retrigger pending events if they were masked. This fixes a regression introduced in 3.7 by b5e57923 (xen/events: fix unmask_evtchn for PV on HVM guests) which reordered the clear mask and check pending operations. Changes in v2: - set mask before hypercall. Cc: stable@vger.kernel.org Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Konrad Rzeszutek Wilk 提交于
With the Xen ACPI stub code (CONFIG_XEN_STUB=y) enabled, the power C and P states are no longer uploaded to the hypervisor. The reason is that the Xen CPU hotplug code: xen-acpi-cpuhotplug.c and the xen-acpi-stub.c register themselves as the "processor" type object. That means the generic processor (processor_driver.c) stops working and it does not call (acpi_processor_add) which populates the per_cpu(processors, pr->id) = pr; structure. The 'pr' is gathered from the acpi_processor_get_info function which does the job of finding the C-states and figuring out PBLK address. The 'processors->pr' is then later used by xen-acpi-processor.c (the one that uploads C and P states to the hypervisor). Since it is NULL, we end skip the gathering of _PSD, _PSS, _PCT, etc and never upload the power management data. The end result is that enabling the CONFIG_XEN_STUB in the build means that xen-acpi-processor is not working anymore. This temporary patch fixes it by marking the XEN_STUB driver as BROKEN until this can be properly fixed. CC: jinsong.liu@intel.com Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 27 3月, 2013 12 次提交
-
-
由 Roland Stigge 提交于
The current lpc32xx_defconfig breaks like this, caused by recent phy restructuring: LD init/built-in.o drivers/built-in.o: In function `usb_hcd_nxp_probe': drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client' drivers/built-in.o: In function `lpc32xx_udc_probe': drivers/usb/gadget/lpc32xx_udc.c:3104: undefined reference to `isp1301_get_client' distcc[27867] ERROR: compile (null) on localhost failed make: *** [vmlinux] Error 1 Caused by 1c208881 (usb: Makefile: fix drivers/usb/phy/ Makefile entry) This patch fixes this by selecting USB_OTG_UTILS in Kconfig which causes the phy driver to be built again. Signed-off-by: NRoland Stigge <stigge@antcom.de> Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Benjamin Tissoires 提交于
Commit "HID: multitouch: use the callback "report" instead..." breaks the buttons of touchpads following the HID multitouch specification. The buttons were emmitted through hid-input, but as now the events are generated only in hid-multitouch, the buttons are not emmitted anymore. The input_event() call is far much simpler than the hid-input one as many of the different tests do not apply to multitouch touchpads. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Joerg Roedel 提交于
There is a bug introduced with commit 27c2127a that causes devices which are hot unplugged and then hot-replugged to not have per-device dma_ops set. This causes these devices to not function correctly. Fixed with this patch. Cc: stable@vger.kernel.org Reported-by: NAndreas Degert <andreas.degert@googlemail.com> Signed-off-by: NJoerg Roedel <joro@8bytes.org>
-
由 Al Viro 提交于
vcs_poll_data_free() calls unregister_vt_notifier(), which calls atomic_notifier_chain_unregister(), which calls synchronize_rcu(). Do it *after* we'd dropped ->f_lock. Cc: stable@vger.kernel.org (all kernels since 2.6.37) Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Yinghai Lu 提交于
During merging the PCI tree with the PM/ACPI tree, Linus noticed that we don't use the same lock using patten about ACPI PCI root as acpiphp. Here apply the same locking patten, and we need to execute acpi_bus_hot_remove_device() via acpi_os_hotplug_execute() as it also holds acpi_scan_lock. [rjw: Changelog] Reported-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYinghai Lu <yinghai@kernel.org> No-objection-from: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Chen Gong 提交于
In Table 18-289, ACPI5.0 SPEC, the error data length in CPER Generic Error Data Entry can be 0, which means this generic error data entry can have only one header. So fix the check conditon for it. Signed-off-by: NChen Gong <gong.chen@linux.intel.com> Reviewed-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Fabio Valentini 提交于
Add Sony Vaio VGN-FW21M to the device blacklist in drivers/acpi/sleep.c. Fixes suspend/resume on this device (device no longer reboots instead of resuming). References: https://bugzilla.kernel.org/show_bug.cgi?id=55001Signed-off-by: NFabio Valentini <fafatheone@gmail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Philip J Kelleher 提交于
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Philip J Kelleher 提交于
Commit d8d595df introduced a bug where we did not check for a NULL return from kmalloc(). Make rsxx_eeh_save_issued_dmas() return an error for that case, and make the callers handle that. Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Veaceslav Falico 提交于
If slave sysfs symlink failes to be created - we end up without removing the master sysfs symlink. Remove it in case of failure. Signed-off-by: NVeaceslav Falico <vfalico@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ming Lei 提交于
Johan's 'fix use-after-free in TIOCMIWAIT' patchset[1] introduces one bug which can cause kernel hang when opening port. This patch initialized the 'port->delta_msr_wait' waitqueue head to fix the bug which is introduced in 3.9-rc4. [1], http://marc.info/?l=linux-usb&m=136368139627876&w=2 Cc: stable <stable@vger.kernel.org> Signed-off-by: NMing Lei <tom.leiming@gmail.com> Acked-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Veaceslav Falico 提交于
skb->ip_summed should be CHECKSUM_UNNECESSARY when the driver reports that checksums were correct and CHECKSUM_NONE in any other case. They're currently placed vice versa, which breaks the forwarding scenario. Fix it by placing them as described above. Signed-off-by: NVeaceslav Falico <vfalico@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 3月, 2013 15 次提交
-
-
由 Wei Yongjun 提交于
Remove duplicated include. Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NJoerg Roedel <joro@8bytes.org>
-
由 Hans de Goede 提交于
Since commit a1fd2877: "[media] bttv-driver: fix two warnings" cropcap.defrect.height and cropcap.bounds.height for the PAL entry are 32 resp 30 pixels too large, if a userspace app (ie xawtv) actually tries to use the full advertised height, the resulting image is broken in ways only a screenshot can describe. The cause of this is the fix for this warning: drivers/media/pci/bt8xx/bttv-driver.c:308:3: warning: initialized field overwritten [-Woverride-init] In this chunk of the commit: @@ -301,11 +301,10 @@ const struct bttv_tvnorm bttv_tvnorms[] = { /* totalwidth */ 1135, /* sqwidth */ 944, /* vdelay */ 0x20, - /* sheight */ 576, - /* videostart0 */ 23) /* bt878 (and bt848?) can capture another line below active video. */ - .cropcap.bounds.height = (576 + 2) + 0x20 - 2, + /* sheight */ (576 + 2) + 0x20 - 2, + /* videostart0 */ 23) },{ .v4l2_id = V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_KR, .name = "NTSC", Which replaces the overriding of cropcap.bounds.height initialization outside of the CROPCAP macro (which also initializes it), with passing a different sheight value to the CROPCAP macro. There are 2 problems with this warning fix: 1) The sheight value is used twice in the CROPCAP macro, and the old code only changed one resulting value. 2) The old code increased the .cropcap.bounds.height value (and did not touch the .cropcap.defrect.height value at all) by 2, where as the fixed code increases it by 32, as the fixed code passes (576 + 2) + 0x20 - 2 to the CROPCAP macro, but the + 0x20 - 2 is already done by the macro so now is done twice for .cropcap.bounds.height, and also is applied to .cropcap.defrect.height where it should not be applied at all. This patch fixes this by adding an extraheight parameter to the CROPCAP entry and using it for the PAL entry. Cc: stable@kernel.org # For Kernel 3.8 Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jiri Benc 提交于
For 82576 MAC type, max_adj is reported as 1000000000 ppb. However, if this value is passed to igb_ptp_adjfreq_82576, incvalue overflows out of INCVALUE_82576_MASK, resulting in setting of zero TIMINCA.incvalue, stopping the PHC (instead of going at twice the nominal speed). Fix the advertised max_adj value to the largest value hardware can handle. As there is no min_adj value available (-max_adj is used instead), this will also prevent stopping the clock intentionally. It's probably not a big deal, other igb MAC types don't support stopping the clock, either. Signed-off-by: NJiri Benc <jbenc@redhat.com> Acked-by: NMatthew Vick <matthew.vick@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Stephen Hemminger 提交于
Trivial sparse warning. Signed-off-by: NStephen Hemminger <stephen@networkplumber.org> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Alex Williamson 提交于
igb is ineffective at setting a lower total VFs because: int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs) { ... /* Shouldn't change if VFs already enabled */ if (dev->sriov->ctrl & PCI_SRIOV_CTRL_VFE) return -EBUSY; Swap init ordering. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Acked-by: NGreg Rose <gregory.v.rose@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Alex Williamson 提交于
The max_vfs= option has always been self limiting to the number of VFs supported by the device. fa44f2f1 added SR-IOV configuration via sysfs, but in the process broke this self correction factor. The failing path is: igb_probe igb_sw_init if (max_vfs > 7) { adapter->vfs_allocated_count = 7; ... igb_probe_vfs igb_enable_sriov(, max_vfs) if (num_vfs > 7) { err = -EPERM; ... This leaves vfs_allocated_count = 7 and vf_data = NULL, so we bomb out when igb_probe finally calls igb_reset. It seems like a really bad idea, and somewhat pointless, to set vfs_allocated_count separate from vf_data, but limiting max_vfs is enough to avoid the null pointer. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Acked-by: NGreg Rose <gregory.v.rose@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Lior Levy 提交于
Fix a problem in i350 where anti spoofing configuration was written into a wrong register. Signed-off-by: NLior Levy <lior.levy@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 xunleer 提交于
When the ixgbevf driver is opened the request to allocate MSIX irq vectors may fail. In that case the driver will call ixgbevf_down() which will call ixgbevf_irq_disable() to clear the HW interrupt registers and calls synchronize_irq() using the msix_entries pointer in the adapter structure. However, when the function to request the MSIX irq vectors failed it had already freed the msix_entries which causes an OOPs from using the NULL pointer in synchronize_irq(). The calls to pci_disable_msix() and to free the msix_entries memory should not occur if device open fails. Instead they should be called during device driver removal to balance with the call to pci_enable_msix() and the call to allocate msix_entries memory during the device probe and driver load. Signed-off-by: NLi Xun <xunleer.li@huawei.com> Signed-off-by: NGreg Rose <gregory.v.rose@intel.com> Tested-by: NSibai Li <sibai.li@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Philip J Kelleher 提交于
This patch removes dynamic allocation on the stack error. Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 John Linn 提交于
The Boot ROM has an issue which will cause the driver to lock up as pending irqs are not being cleared. With them cleared it prevents that issue. This patch is needed for the current (3.9-rc3) mainline kernel. I guess it went unnoticed, because it was only tested with u-boot up until now. And u-boot maybe handles this. [s.trumtrar@pengutronix.de: cherry-picked from linux-xlnx.git] Signed-off-by: NSteffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
They were introduced by mistake in 3.7. Let's deprecate them now. For the reasons, see the text in Kconfig below. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
In 3.7 the 8250 module name was changed unintentionally from 8250 to 8250_core by commit 835d844d (8250_pnp: do pnp probe before legacy probe). We then had to re-introduce the old module options to ensure the old good 8250.nr_uart & co. still work. This can be done only by a very dirty hack and we did it in f2b8dfd9 (serial: 8250: Keep 8250.<xxxx> module options functional after driver rename). That is so damn ugly so that I decided to revert to the old module name and deprecate the new 8250_core options present in 3.7 and 3.8 only. The deprecation will happen in the following patch. Note that this patch changes the hack above to support "8250_core.*", because we now have "8250.*" natively. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Soeren Moch 提交于
[Description written by Alan Stern] Soeren tracked down a very difficult bug in ehci-hcd's DMA pool management of iTD and siTD structures. Some background: ehci-hcd gives each isochronous endpoint its own set of active and free itd's (or sitd's for full-speed devices). When a new itd is needed, it is taken from the head of the free list, if possible. However, itd's must not be used twice in a single frame because the hardware continues to access the data structure for the entire duration of a frame. Therefore if the itd at the head of the free list has its "frame" member equal to the current value of ehci->now_frame, it cannot be reused and instead a new itd is allocated from the DMA pool. The entries on the free list are not released back to the pool until the endpoint is no longer in use. The bug arises from the fact that sometimes an itd can be moved back onto the free list before itd->frame has been set properly. In Soeren's case, this happened because ehci-hcd can allocate one more itd than it actually needs for an URB; the extra itd may or may not be required depending on how the transfer aligns with a frame boundary. For example, an URB with 8 isochronous packets will cause two itd's to be allocated. If the URB is scheduled to start in microframe 3 of frame N then it will require both itds: one for microframes 3 - 7 of frame N and one for microframes 0 - 2 of frame N+1. But if the URB had been scheduled to start in microframe 0 then it would require only the first itd, which could cover microframes 0 - 7 of frame N. The second itd would be returned to the end of the free list. The itd allocation routine initializes the entire structure to 0, so the extra itd ends up on the free list with itd->frame set to 0 instead of a meaningful value. After a while the itd reaches the head of the list, and occasionally this happens when ehci->now_frame is equal to 0. Then, even though it would be okay to reuse this itd, the driver thinks it must get another itd from the DMA pool. For as long as the isochronous endpoint remains in use, this flaw in the mechanism causes more and more itd's to be taken slowly from the DMA pool. Since none are released back, the pool eventually becomes exhausted. This reuslts in memory allocation failures, which typically show up during a long-running audio stream. Video might suffer the same effect. The fix is very simple. To prevent allocations from the pool when they aren't needed, make sure that itd's sent back to the free list prematurely have itd->frame set to an invalid value which can never be equal to ehci->now_frame. This should be applied to -stable kernels going back to 3.6. Signed-off-by: NSoeren Moch <smoch@web.de> Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Ian Abbott 提交于
For the s626 driver, there is a bug in the handling of asynchronous commands on the AI subdevice when the stop source is `TRIG_NONE`. The command should run continuously until cancelled, but the interrupt handler stops the command running after the first scan. The command set-up function `s626_ai_cmd()` contains this code: switch (cmd->stop_src) { case TRIG_COUNT: /* data arrives as one packet */ devpriv->ai_sample_count = cmd->stop_arg; devpriv->ai_continous = 0; break; case TRIG_NONE: /* continous acquisition */ devpriv->ai_continous = 1; devpriv->ai_sample_count = 0; break; } The interrupt handler `s626_irq_handler()` contains this code: if (!(devpriv->ai_continous)) devpriv->ai_sample_count--; if (devpriv->ai_sample_count <= 0) { devpriv->ai_cmd_running = 0; /* ... */ } So `devpriv->ai_sample_count` is only decremented for the `TRIG_COUNT` case, but `devpriv->ai_cmd_running` is set to 0 (and the command stopped) regardless. Fix this in `s626_ai_cmd()` by setting `devpriv->ai_sample_count = 1` for the `TRIG_NONE` case. The interrupt handler will not decrement it so it will remain greater than 0 and the check for stopping the acquisition will fail. Cc: stable <stable@vger.kernel.org> Signed-off-by: NIan Abbott <abbotti@mev.co.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mauro Carvalho Chehab 提交于
When config options are: CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2=m CONFIG_I2C=m Compilation breaks, as reported by: https://bugzilla.kernel.org/show_bug.cgi?id=55681 Before changeset 7b34be71, no compilation errors occurred. However, the I2C code there at v4l2-device was incorrectly disabled. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-