* [ 00/16] 3.0.42-stable review
@ 2012-08-20 3:55 Greg Kroah-Hartman
2012-08-20 3:56 ` [ 01/16] s390/compat: fix mmap compat system calls Greg Kroah-Hartman
` (15 more replies)
0 siblings, 16 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2012-08-20 3:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Greg KH, torvalds, akpm, alan
From: Greg KH <gregkh@linuxfoundation.org>
This is the start of the stable review cycle for the 3.0.42 release.
There are 17 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Aug 22 03:54:56 UTC 2012.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.42-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Makefile | 4 +-
arch/s390/kernel/compat_linux.c | 2 -
arch/x86/xen/p2m.c | 36 ++++
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +-
drivers/gpu/drm/radeon/evergreen.c | 57 -------
drivers/gpu/drm/radeon/radeon_asic.h | 8 +-
drivers/gpu/drm/radeon/rv515.c | 13 --
drivers/infiniband/ulp/srp/ib_srp.c | 87 +++++++---
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
drivers/usb/host/pci-quirks.c | 7 +
drivers/usb/host/pci-quirks.h | 1 +
drivers/usb/host/xhci-pci.c | 10 ++
drivers/usb/host/xhci.c | 8 +-
drivers/usb/host/xhci.h | 1 +
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 7 +
drivers/usb/serial/mos7840.c | 9 +-
drivers/usb/serial/option.c | 281 +++++++++++++-------------------
fs/ext4/super.c | 1 +
fs/fuse/file.c | 2 +-
include/linux/usb.h | 21 +++
21 files changed, 284 insertions(+), 280 deletions(-)
^ permalink raw reply [flat|nested] 25+ messages in thread* [ 01/16] s390/compat: fix mmap compat system calls 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 02/16] fuse: verify all ioctl retry iov elements Greg Kroah-Hartman ` (14 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Heiko Carstens, Martin Schwidefsky From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Heiko Carstens <heiko.carstens@de.ibm.com> commit e85871218513c54f7dfdb6009043cb638f2fecbe upstream. The native 31 bit and the compat behaviour for the mmap system calls differ: In native 31 bit mode the passed in address for the mmap system call will be unmodified passed to sys_mmap_pgoff(). In compat mode however the passed in address will be modified with compat_ptr() which masks out the most significant bit. The result is that in native 31 bit mode each mmap request (with MAP_FIXED) will fail where the most significat bit is set, while in compat mode it may succeed. This odd behaviour was introduced with d3815898 "[S390] mmap: add missing compat_ptr conversion to both mmap compat syscalls". To restore a consistent behaviour accross native and compat mode this patch functionally reverts the above mentioned commit. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/s390/kernel/compat_linux.c | 2 -- 1 file changed, 2 deletions(-) --- a/arch/s390/kernel/compat_linux.c +++ b/arch/s390/kernel/compat_linux.c @@ -631,7 +631,6 @@ asmlinkage unsigned long old32_mmap(stru return -EFAULT; if (a.offset & ~PAGE_MASK) return -EINVAL; - a.addr = (unsigned long) compat_ptr(a.addr); return sys_mmap_pgoff(a.addr, a.len, a.prot, a.flags, a.fd, a.offset >> PAGE_SHIFT); } @@ -642,7 +641,6 @@ asmlinkage long sys32_mmap2(struct mmap_ if (copy_from_user(&a, arg, sizeof(a))) return -EFAULT; - a.addr = (unsigned long) compat_ptr(a.addr); return sys_mmap_pgoff(a.addr, a.len, a.prot, a.flags, a.fd, a.offset); } ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 02/16] fuse: verify all ioctl retry iov elements 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman 2012-08-20 3:56 ` [ 01/16] s390/compat: fix mmap compat system calls Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 03/16] xen: mark local pages as FOREIGN in the m2p_override Greg Kroah-Hartman ` (13 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Zach Brown, Miklos Szeredi From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zach Brown <zab@redhat.com> commit fb6ccff667712c46b4501b920ea73a326e49626a upstream. Commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that the total iovec from the client doesn't overflow iov_length() but it only checked the first element. The iovec could still overflow by starting with a small element. The obvious fix is to check all the elements. The overflow case doesn't look dangerous to the kernel as the copy is limited by the length after the overflow. This fix restores the intention of returning an error instead of successfully copying less than the iovec represented. I found this by code inspection. I built it but don't have a test case. I'm cc:ing stable because the initial commit did as well. Signed-off-by: Zach Brown <zab@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/fuse/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -1710,7 +1710,7 @@ static int fuse_verify_ioctl_iov(struct size_t n; u32 max = FUSE_MAX_PAGES_PER_REQ << PAGE_SHIFT; - for (n = 0; n < count; n++) { + for (n = 0; n < count; n++, iov++) { if (iov->iov_len > (size_t) max) return -ENOMEM; max -= iov->iov_len; ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 03/16] xen: mark local pages as FOREIGN in the m2p_override 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman 2012-08-20 3:56 ` [ 01/16] s390/compat: fix mmap compat system calls Greg Kroah-Hartman 2012-08-20 3:56 ` [ 02/16] fuse: verify all ioctl retry iov elements Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 04/16] drm/i915: correctly order the ring init sequence Greg Kroah-Hartman ` (12 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Stefano Stabellini, Konrad Rzeszutek Wilk From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> commit b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f upstream. When the frontend and the backend reside on the same domain, even if we add pages to the m2p_override, these pages will never be returned by mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will always fail, so the pfn of the frontend will be returned instead (resulting in a deadlock because the frontend pages are already locked). INFO: task qemu-system-i38:1085 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. qemu-system-i38 D ffff8800cfc137c0 0 1085 1 0x00000000 ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0 ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0 ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0 Call Trace: [<ffffffff81101ee0>] ? __lock_page+0x70/0x70 [<ffffffff81a0fdd9>] schedule+0x29/0x70 [<ffffffff81a0fe80>] io_schedule+0x60/0x80 [<ffffffff81101eee>] sleep_on_page+0xe/0x20 [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0 [<ffffffff81101ed7>] __lock_page+0x67/0x70 [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40 [<ffffffff811867e6>] ? bio_add_page+0x36/0x40 [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60 [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70 [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0 [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00 [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60 [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00 [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390 [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00 [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0 [<ffffffff81104027>] generic_file_aio_read+0x737/0x780 [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0 [<ffffffff811038f0>] ? find_get_pages+0x150/0x150 [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0 [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90 [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0 [<ffffffff811998b8>] do_io_submit+0x708/0xb90 [<ffffffff81199d50>] sys_io_submit+0x10/0x20 [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b The explanation is in the comment within the code: We need to do this because the pages shared by the frontend (xen-blkfront) can be already locked (lock_page, called by do_read_cache_page); when the userspace backend tries to use them with direct_IO, mfn_to_pfn returns the pfn of the frontend, so do_blockdev_direct_IO is going to try to lock the same pages again resulting in a deadlock. A simplified call graph looks like this: pygrub QEMU ----------------------------------------------- do_read_cache_page io_submit | | lock_page ext3_direct_IO | bio_add_page | lock_page Internally the xen-blkback uses m2p_add_override to swizzle (temporarily) a 'struct page' to have a different MFN (so that it can point to another guest). It also can easily find out whether another pfn corresponding to the mfn exists in the m2p, and can set the FOREIGN bit in the p2m, making sure that mfn_to_pfn returns the pfn of the backend. This allows the backend to perform direct_IO on these pages, but as a side effect prevents the frontend from using get_user_pages_fast on them while they are being shared with the backend. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/x86/xen/p2m.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -683,6 +683,7 @@ int m2p_add_override(unsigned long mfn, unsigned long uninitialized_var(address); unsigned level; pte_t *ptep = NULL; + int ret = 0; pfn = page_to_pfn(page); if (!PageHighMem(page)) { @@ -706,6 +707,24 @@ int m2p_add_override(unsigned long mfn, list_add(&page->lru, &m2p_overrides[mfn_hash(mfn)]); spin_unlock_irqrestore(&m2p_override_lock, flags); + /* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in + * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other + * pfn so that the following mfn_to_pfn(mfn) calls will return the + * pfn from the m2p_override (the backend pfn) instead. + * We need to do this because the pages shared by the frontend + * (xen-blkfront) can be already locked (lock_page, called by + * do_read_cache_page); when the userspace backend tries to use them + * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so + * do_blockdev_direct_IO is going to try to lock the same pages + * again resulting in a deadlock. + * As a side effect get_user_pages_fast might not be safe on the + * frontend pages while they are being shared with the backend, + * because mfn_to_pfn (that ends up being called by GUPF) will + * return the backend pfn rather than the frontend pfn. */ + ret = __get_user(pfn, &machine_to_phys_mapping[mfn]); + if (ret == 0 && get_phys_to_machine(pfn) == mfn) + set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)); + return 0; } EXPORT_SYMBOL_GPL(m2p_add_override); @@ -717,6 +736,7 @@ int m2p_remove_override(struct page *pag unsigned long uninitialized_var(address); unsigned level; pte_t *ptep = NULL; + int ret = 0; pfn = page_to_pfn(page); mfn = get_phys_to_machine(pfn); @@ -743,6 +763,22 @@ int m2p_remove_override(struct page *pag /* No tlb flush necessary because the caller already * left the pte unmapped. */ + /* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present + * somewhere in this domain, even before being added to the + * m2p_override (see comment above in m2p_add_override). + * If there are no other entries in the m2p_override corresponding + * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for + * the original pfn (the one shared by the frontend): the backend + * cannot do any IO on this page anymore because it has been + * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of + * the original pfn causes mfn_to_pfn(mfn) to return the frontend + * pfn again. */ + mfn &= ~FOREIGN_FRAME_BIT; + ret = __get_user(pfn, &machine_to_phys_mapping[mfn]); + if (ret == 0 && get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) && + m2p_find_override(mfn) == NULL) + set_phys_to_machine(pfn, mfn); + return 0; } EXPORT_SYMBOL_GPL(m2p_remove_override); ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (2 preceding siblings ...) 2012-08-20 3:56 ` [ 03/16] xen: mark local pages as FOREIGN in the m2p_override Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-21 5:13 ` Herton Ronaldo Krzesinski 2012-08-20 3:56 ` [ 05/16] drm/radeon: do not reenable crtc after moving vram start address Greg Kroah-Hartman ` (11 subsequent siblings) 15 siblings, 1 reply; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Jani Nikula, Yang Guang, Daniel Vetter From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daniel Vetter <daniel.vetter@ffwll.ch> commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream. We may only start to set up the new register values after having confirmed that the ring is truely off. Otherwise the hw might lose the newly written register values. This is caught later on in the init sequence, when we check whether the register writes have stuck. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 Tested-by: Yang Guang <guang.a.yang@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -150,8 +150,6 @@ static int init_ring_common(struct intel I915_WRITE_HEAD(ring, 0); ring->write_tail(ring, 0); - /* Initialize the ring. */ - I915_WRITE_START(ring, obj->gtt_offset); head = I915_READ_HEAD(ring) & HEAD_ADDR; /* G45 ring initialization fails to reset head to zero */ @@ -177,6 +175,11 @@ static int init_ring_common(struct intel } } + /* Initialize the ring. This must happen _after_ we've cleared the ring + * registers with the above sequence (the readback of the HEAD registers + * also enforces ordering), otherwise the hw might lose the new ring + * register values. */ + I915_WRITE_START(ring, obj->gtt_offset); I915_WRITE_CTL(ring, ((ring->size - PAGE_SIZE) & RING_NR_PAGES) | RING_REPORT_64K | RING_VALID); ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-20 3:56 ` [ 04/16] drm/i915: correctly order the ring init sequence Greg Kroah-Hartman @ 2012-08-21 5:13 ` Herton Ronaldo Krzesinski 2012-08-21 6:42 ` Daniel Vetter 0 siblings, 1 reply; 25+ messages in thread From: Herton Ronaldo Krzesinski @ 2012-08-21 5:13 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: linux-kernel, stable, torvalds, akpm, alan, Jani Nikula, Yang Guang, Daniel Vetter On Sun, Aug 19, 2012 at 08:56:03PM -0700, Greg Kroah-Hartman wrote: > From: Greg KH <gregkh@linuxfoundation.org> > > 3.0-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Daniel Vetter <daniel.vetter@ffwll.ch> > > commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream. > > We may only start to set up the new register values after having > confirmed that the ring is truely off. Otherwise the hw might lose the > newly written register values. This is caught later on in the init > sequence, when we check whether the register writes have stuck. > > Reviewed-by: Jani Nikula <jani.nikula@intel.com> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 > Tested-by: Yang Guang <guang.a.yang@intel.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [...] I had the same problem as on 3.2 with this change, i915 stopped working unable to initialize render ring, eg. on one of the boots here: [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 head 00001020 tail 00000000 start 00001000 But unlike I was expecting as with 3.2 case, picking commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in init_ring_common") here isn't enough, it continues to fail even if I try to increase the delay in the wait_for, I'm not sure why yet... may be something else is going on, or 3.0 has something else missing. Also the same proposed patch for 3.4.10 gives the same problem, but picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work again like happend on first 3.2.28 proposed update. Only 3.0 is misteriously failing either way here. -- []'s Herton ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-21 5:13 ` Herton Ronaldo Krzesinski @ 2012-08-21 6:42 ` Daniel Vetter 2012-08-21 13:11 ` Herton Ronaldo Krzesinski 0 siblings, 1 reply; 25+ messages in thread From: Daniel Vetter @ 2012-08-21 6:42 UTC (permalink / raw) To: Herton Ronaldo Krzesinski Cc: Greg Kroah-Hartman, linux-kernel, stable, torvalds, akpm, alan, Jani Nikula, Yang Guang On Tue, Aug 21, 2012 at 7:13 AM, Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> wrote: > On Sun, Aug 19, 2012 at 08:56:03PM -0700, Greg Kroah-Hartman wrote: >> From: Greg KH <gregkh@linuxfoundation.org> >> >> 3.0-stable review patch. If anyone has any objections, please let me know. >> >> ------------------ >> >> From: Daniel Vetter <daniel.vetter@ffwll.ch> >> >> commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream. >> >> We may only start to set up the new register values after having >> confirmed that the ring is truely off. Otherwise the hw might lose the >> newly written register values. This is caught later on in the init >> sequence, when we check whether the register writes have stuck. >> >> Reviewed-by: Jani Nikula <jani.nikula@intel.com> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 >> Tested-by: Yang Guang <guang.a.yang@intel.com> >> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> >> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > [...] > > I had the same problem as on 3.2 with this change, i915 stopped working > unable to initialize render ring, eg. on one of the boots here: > [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 head 00001020 tail 00000000 start 00001000 > > But unlike I was expecting as with 3.2 case, picking commit > f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in > init_ring_common") here isn't enough, it continues to fail even if I > try to increase the delay in the wait_for, I'm not sure why yet... may > be something else is going on, or 3.0 has something else missing. > > Also the same proposed patch for 3.4.10 gives the same problem, but > picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work > again like happend on first 3.2.28 proposed update. Only 3.0 > is misteriously failing either way here. I guess we're missing something then still in the stable backports for 3.0. Herton, what machine do you have exaclty (lspci -nn)? Greg, I think for now it's better if you hold off on merging this patch to 3.0 until this is sorted out. Thanks, Daniel -- Daniel Vetter daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-21 6:42 ` Daniel Vetter @ 2012-08-21 13:11 ` Herton Ronaldo Krzesinski 2012-08-21 16:55 ` Daniel Vetter 0 siblings, 1 reply; 25+ messages in thread From: Herton Ronaldo Krzesinski @ 2012-08-21 13:11 UTC (permalink / raw) To: Daniel Vetter Cc: Greg Kroah-Hartman, linux-kernel, stable, torvalds, akpm, alan, Jani Nikula, Yang Guang On Tue, Aug 21, 2012 at 08:42:35AM +0200, Daniel Vetter wrote: > On Tue, Aug 21, 2012 at 7:13 AM, Herton Ronaldo Krzesinski > <herton.krzesinski@canonical.com> wrote: > > I had the same problem as on 3.2 with this change, i915 stopped working > > unable to initialize render ring, eg. on one of the boots here: > > [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 head 00001020 tail 00000000 start 00001000 > > > > But unlike I was expecting as with 3.2 case, picking commit > > f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in > > init_ring_common") here isn't enough, it continues to fail even if I > > try to increase the delay in the wait_for, I'm not sure why yet... may > > be something else is going on, or 3.0 has something else missing. > > > > Also the same proposed patch for 3.4.10 gives the same problem, but > > picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work > > again like happend on first 3.2.28 proposed update. Only 3.0 > > is misteriously failing either way here. > > I guess we're missing something then still in the stable backports for > 3.0. Herton, what machine do you have exaclty (lspci -nn)? It's a G41 based board: 00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller [8086:2e30] (rev 03) 00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e32] (rev 03) 00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 01) 00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 1 [8086:27d0] (rev 01) 00:1c.2 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 3 [8086:27d4] (rev 01) 00:1d.0 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 [8086:27c9] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 [8086:27ca] (rev 01) 00:1d.3 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 [8086:27cb] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller [8086:27cc] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01) 00:1f.2 IDE interface [0101]: Intel Corporation N10/ICH7 Family SATA IDE Controller [8086:27c0] (rev 01) 00:1f.3 SMBus [0c05]: Intel Corporation N10/ICH 7 Family SMBus Controller [8086:27da] (rev 01) 02:00.0 Ethernet controller [0200]: Atheros Communications AR8151 v1.0 Gigabit Ethernet [1969:1073] (rev c0) > > Greg, I think for now it's better if you hold off on merging this > patch to 3.0 until this is sorted out. > > Thanks, Daniel > -- > Daniel Vetter > daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- []'s Herton ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-21 13:11 ` Herton Ronaldo Krzesinski @ 2012-08-21 16:55 ` Daniel Vetter 2012-08-22 4:50 ` Herton Ronaldo Krzesinski 0 siblings, 1 reply; 25+ messages in thread From: Daniel Vetter @ 2012-08-21 16:55 UTC (permalink / raw) To: Herton Ronaldo Krzesinski Cc: Greg Kroah-Hartman, linux-kernel, stable, torvalds, akpm, alan, Jani Nikula, Yang Guang On Tue, Aug 21, 2012 at 3:11 PM, Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> wrote: > On Tue, Aug 21, 2012 at 08:42:35AM +0200, Daniel Vetter wrote: >> On Tue, Aug 21, 2012 at 7:13 AM, Herton Ronaldo Krzesinski >> <herton.krzesinski@canonical.com> wrote: >> > I had the same problem as on 3.2 with this change, i915 stopped working >> > unable to initialize render ring, eg. on one of the boots here: >> > [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 head 00001020 tail 00000000 start 00001000 >> > >> > But unlike I was expecting as with 3.2 case, picking commit >> > f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in >> > init_ring_common") here isn't enough, it continues to fail even if I >> > try to increase the delay in the wait_for, I'm not sure why yet... may >> > be something else is going on, or 3.0 has something else missing. >> > >> > Also the same proposed patch for 3.4.10 gives the same problem, but >> > picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work >> > again like happend on first 3.2.28 proposed update. Only 3.0 >> > is misteriously failing either way here. >> >> I guess we're missing something then still in the stable backports for >> 3.0. Herton, what machine do you have exaclty (lspci -nn)? > > It's a G41 based board: Hm, I've reviewed git log and bug reports and I have no idea what's missing on 3.0. I guess the best course of action is to not apply this patch to 3.0 stable - it fixes an ivb issue anyway, and 3.0 is a rather old kernel for ivb support anyway (we generally recommend 3.2.x for ivb). -Daniel > > 00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller [8086:2e30] (rev 03) > 00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e32] (rev 03) > 00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 01) > 00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 1 [8086:27d0] (rev 01) > 00:1c.2 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 3 [8086:27d4] (rev 01) > 00:1d.0 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) > 00:1d.1 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 [8086:27c9] (rev 01) > 00:1d.2 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 [8086:27ca] (rev 01) > 00:1d.3 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 [8086:27cb] (rev 01) > 00:1d.7 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller [8086:27cc] (rev 01) > 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1) > 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01) > 00:1f.2 IDE interface [0101]: Intel Corporation N10/ICH7 Family SATA IDE Controller [8086:27c0] (rev 01) > 00:1f.3 SMBus [0c05]: Intel Corporation N10/ICH 7 Family SMBus Controller [8086:27da] (rev 01) > 02:00.0 Ethernet controller [0200]: Atheros Communications AR8151 v1.0 Gigabit Ethernet [1969:1073] (rev c0) > >> >> Greg, I think for now it's better if you hold off on merging this >> patch to 3.0 until this is sorted out. >> >> Thanks, Daniel >> -- >> Daniel Vetter >> daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch >> > > -- > []'s > Herton -- Daniel Vetter daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-21 16:55 ` Daniel Vetter @ 2012-08-22 4:50 ` Herton Ronaldo Krzesinski 2012-08-22 22:44 ` Herton Ronaldo Krzesinski 0 siblings, 1 reply; 25+ messages in thread From: Herton Ronaldo Krzesinski @ 2012-08-22 4:50 UTC (permalink / raw) To: Daniel Vetter Cc: Greg Kroah-Hartman, linux-kernel, stable, torvalds, akpm, alan, Jani Nikula, Yang Guang [-- Attachment #1: Type: text/plain, Size: 5694 bytes --] On Tue, Aug 21, 2012 at 06:55:30PM +0200, Daniel Vetter wrote: > On Tue, Aug 21, 2012 at 3:11 PM, Herton Ronaldo Krzesinski > <herton.krzesinski@canonical.com> wrote: > > On Tue, Aug 21, 2012 at 08:42:35AM +0200, Daniel Vetter wrote: > >> On Tue, Aug 21, 2012 at 7:13 AM, Herton Ronaldo Krzesinski > >> <herton.krzesinski@canonical.com> wrote: > >> > I had the same problem as on 3.2 with this change, i915 stopped working > >> > unable to initialize render ring, eg. on one of the boots here: > >> > [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 head 00001020 tail 00000000 start 00001000 > >> > > >> > But unlike I was expecting as with 3.2 case, picking commit > >> > f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in > >> > init_ring_common") here isn't enough, it continues to fail even if I > >> > try to increase the delay in the wait_for, I'm not sure why yet... may > >> > be something else is going on, or 3.0 has something else missing. > >> > > >> > Also the same proposed patch for 3.4.10 gives the same problem, but > >> > picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work > >> > again like happend on first 3.2.28 proposed update. Only 3.0 > >> > is misteriously failing either way here. > >> > >> I guess we're missing something then still in the stable backports for > >> 3.0. Herton, what machine do you have exaclty (lspci -nn)? > > > > It's a G41 based board: > > Hm, I've reviewed git log and bug reports and I have no idea what's > missing on 3.0. I guess the best course of action is to not apply this > patch to 3.0 stable - it fixes an ivb issue anyway, and 3.0 is a > rather old kernel for ivb support anyway (we generally recommend 3.2.x > for ivb). > -Daniel Yeah, 3.0 being old, if it was only for ivb, supported only later, makes sense. I continued investigating this today, and some things are looking very strange to me. Here is what I discovered and narrowed down so far: * There is difference of behaviour depending on which environment I build 3.0: Originally I built the 3.0 kernel on Ubuntu Oneiric, gcc is 4.6.1, binutils 2.21.53.20110810 (I'm just saying the versions, not sure if it makes a difference or not, and the distro toolchain usually is patched so the versions may not mean much). Then I tried building the 3.0 kernel on a newer environment/distro version, Ubuntu Precise, gcc is 4.6.3, binutils 2.22. - Building the stock 3.0.42 proposed kernel on both Ubuntu distros (Oneiric and Precise), and testing them, I get the same render ring initialization failure. - Building 3.0.42 with commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 picked on top gives a different result though: The kernel built on Oneiric continues to fail, while the one built on Precise then works. This was very weird, and I suspected of the toolchain. But the generated assembly is the same, I also compared the objdump output of the built i915 module, and there were no differences in the init_common_ring function. There were some differences in other places, but no difference in the section of code patched between the working case to the non-working case. Really didn't made sense, and probably something else is going on, related to code size or timing or alignment somewhere, I don't know, but I was unable yet to detect really what's the cause. I also noticed something else. I started to patch the init_ring_common function reading back and printing the render ring buffer pointer values that were being set, with the attached patch, and building the kernel on the environment which the bug happens (Oneiric). This is the relevant output I got, I numbered by hand to comment after: 1) [ 34.872786] i915: ctl 00000000 head 00000000 tail 00000000 start 00000000 [ 34.872789] i915: ctl 00000000 head 00000000 tail 00000000 start 00000000 [ 34.872792] i915: ctl 00000000 head 00000000 tail 00000000 start 00000000 [ 34.872793] i915: head = 00000000 [ 34.872795] i915: ctl 00000000 head 00000000 tail 00000000 start 00000000 2) [ 34.872797] i915: head = 00001000 [ 34.872798] i915: ctl 00000000 head 00001000 tail 00000000 start 00001000 3) [ 35.880034] i915: timeout [ 35.936111] [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 head 00007cc4 tail 00000000 start 00001000 [ 35.936174] i915: 00000001 00001000 00007cc4 [ 35.936229] vga_switcheroo: disabled [ 35.936232] [drm:i915_driver_load] *ERROR* failed to init modeset [ 35.954182] i915 0000:00:02.0: PCI INT A disabled [ 35.954188] i915: probe of 0000:00:02.0 failed with error -5 1) At first run, the render ring buffer is "stopped", everything is zero. The zeros written to ctl, head and tail changes nothing, everything stays zero, as expected. 2) These are the values read after I915_WRITE_START runs. For some reason on this machine here, after start address was written, the head is set the same as the start (?), and this is the root of the failing case here. I was reading the documentation, and it says when you write the start address, both head and tail offsets are reset, and thus this doesn't make sense and shouldn't have happened. May be that's why the code before has that comment: "/* G45 ring initialization fails to reset head to zero */", perhaps that code was there for this case. Strange that depending on where you build things the problem happens or not, not sure if is just luck or it has something to do with this. 3) head never gets to zero, and seems to continue to increment by itself, looking at the head value read in the failure path. I'm not sure if this shed some light, or confuses things even more... -- []'s Herton [-- Attachment #2: ring.patch --] [-- Type: text/x-diff, Size: 2594 bytes --] diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 38ae0ec..a5ba981 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -145,16 +145,43 @@ static int init_ring_common(struct intel_ring_buffer *ring) struct drm_i915_gem_object *obj = ring->obj; u32 head; + printk("i915: ctl %08x head %08x tail %08x start %08x\n", + I915_READ_CTL(ring), + I915_READ_HEAD(ring), + I915_READ_TAIL(ring), + I915_READ_START(ring)); + /* Stop the ring if it's running. */ I915_WRITE_CTL(ring, 0); + + printk("i915: ctl %08x head %08x tail %08x start %08x\n", + I915_READ_CTL(ring), + I915_READ_HEAD(ring), + I915_READ_TAIL(ring), + I915_READ_START(ring)); + I915_WRITE_HEAD(ring, 0); + + printk("i915: ctl %08x head %08x tail %08x start %08x\n", + I915_READ_CTL(ring), + I915_READ_HEAD(ring), + I915_READ_TAIL(ring), + I915_READ_START(ring)); + ring->write_tail(ring, 0); head = I915_READ_HEAD(ring) & HEAD_ADDR; + printk("i915: head = %08x\n", head); + + printk("i915: ctl %08x head %08x tail %08x start %08x\n", + I915_READ_CTL(ring), + I915_READ_HEAD(ring), + I915_READ_TAIL(ring), + I915_READ_START(ring)); /* G45 ring initialization fails to reset head to zero */ if (head != 0) { - DRM_DEBUG_KMS("%s head not reset to zero " + DRM_ERROR("%s head not reset to zero " "ctl %08x head %08x tail %08x start %08x\n", ring->name, I915_READ_CTL(ring), @@ -180,6 +207,17 @@ static int init_ring_common(struct intel_ring_buffer *ring) * also enforces ordering), otherwise the hw might lose the new ring * register values. */ I915_WRITE_START(ring, obj->gtt_offset); + head = I915_READ_HEAD(ring) & HEAD_ADDR; + printk("i915: head = %08x\n", head); + + printk("i915: ctl %08x head %08x tail %08x start %08x\n", + I915_READ_CTL(ring), + I915_READ_HEAD(ring), + I915_READ_TAIL(ring), + I915_READ_START(ring)); + if (wait_for((I915_READ_HEAD(ring) & HEAD_ADDR) == 0, 1000)) + printk("i915: timeout\n"); + I915_WRITE_CTL(ring, ((ring->size - PAGE_SIZE) & RING_NR_PAGES) | RING_REPORT_64K | RING_VALID); @@ -195,6 +233,7 @@ static int init_ring_common(struct intel_ring_buffer *ring) I915_READ_HEAD(ring), I915_READ_TAIL(ring), I915_READ_START(ring)); + printk("i915: %08x %08x %08x\n", I915_READ_CTL(ring) & RING_VALID, obj->gtt_offset, I915_READ_HEAD(ring) & HEAD_ADDR); return -EIO; } ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-22 4:50 ` Herton Ronaldo Krzesinski @ 2012-08-22 22:44 ` Herton Ronaldo Krzesinski 2012-08-23 8:10 ` Daniel Vetter 0 siblings, 1 reply; 25+ messages in thread From: Herton Ronaldo Krzesinski @ 2012-08-22 22:44 UTC (permalink / raw) To: Daniel Vetter Cc: Greg Kroah-Hartman, linux-kernel, stable, torvalds, akpm, alan, Jani Nikula, Yang Guang On Wed, Aug 22, 2012 at 01:50:16AM -0300, Herton Ronaldo Krzesinski wrote: > On Tue, Aug 21, 2012 at 06:55:30PM +0200, Daniel Vetter wrote: > > On Tue, Aug 21, 2012 at 3:11 PM, Herton Ronaldo Krzesinski > > <herton.krzesinski@canonical.com> wrote: > > > On Tue, Aug 21, 2012 at 08:42:35AM +0200, Daniel Vetter wrote: > > >> On Tue, Aug 21, 2012 at 7:13 AM, Herton Ronaldo Krzesinski > > >> <herton.krzesinski@canonical.com> wrote: > > >> > I had the same problem as on 3.2 with this change, i915 stopped working > > >> > unable to initialize render ring, eg. on one of the boots here: > > >> > [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 head 00001020 tail 00000000 start 00001000 > > >> > > > >> > But unlike I was expecting as with 3.2 case, picking commit > > >> > f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in > > >> > init_ring_common") here isn't enough, it continues to fail even if I > > >> > try to increase the delay in the wait_for, I'm not sure why yet... may > > >> > be something else is going on, or 3.0 has something else missing. > > >> > > > >> > Also the same proposed patch for 3.4.10 gives the same problem, but > > >> > picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work > > >> > again like happend on first 3.2.28 proposed update. Only 3.0 > > >> > is misteriously failing either way here. > > >> > > >> I guess we're missing something then still in the stable backports for > > >> 3.0. Herton, what machine do you have exaclty (lspci -nn)? > > > > > > It's a G41 based board: > > > > Hm, I've reviewed git log and bug reports and I have no idea what's > > missing on 3.0. I guess the best course of action is to not apply this > > patch to 3.0 stable - it fixes an ivb issue anyway, and 3.0 is a > > rather old kernel for ivb support anyway (we generally recommend 3.2.x > > for ivb). > > -Daniel > > Yeah, 3.0 being old, if it was only for ivb, supported only later, makes > sense. I continued investigating this today, and some things are looking > very strange to me. Here is what I discovered and narrowed down so far: [...] Really sorry about this, but it was a hardware+bios setting problem here. I finished investigating what was happening here, and is related to the DRAM installed on this machine. The memory installed is DDR3-1333, and on bios it was configured as that, but turns out the chipset (G41) only supports up to DDR3-1066 (as on specs, although the motherboard lists the 1333 as supported, but as "OC", and allows configuring this way automatically or manually). After setting manually back to 1066, I stopped seeing all the weird behaviour, like the writes to the start address don't trigger anymore setting on the head offset. I'm sorry about that, and really it's a brown paper bag time for me :(. The machine worked fine and passed through memtest and never gave any problems, this was the first time (seems only the video device didn't like the memory setting, and the code change probably changed timing in the right way to pop up this now, also never had graphics corruption or other noticeable problems). I retested kernels that gave problems and they run fine now. -- []'s Herton ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-22 22:44 ` Herton Ronaldo Krzesinski @ 2012-08-23 8:10 ` Daniel Vetter 2012-08-23 16:18 ` Herton Ronaldo Krzesinski 0 siblings, 1 reply; 25+ messages in thread From: Daniel Vetter @ 2012-08-23 8:10 UTC (permalink / raw) To: Herton Ronaldo Krzesinski Cc: Greg Kroah-Hartman, linux-kernel, stable, torvalds, akpm, alan, Jani Nikula, Yang Guang On Thu, Aug 23, 2012 at 12:44 AM, Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> wrote: > Really sorry about this, but it was a hardware+bios setting problem > here. I finished investigating what was happening here, and is related to > the DRAM installed on this machine. The memory installed is DDR3-1333, > and on bios it was configured as that, but turns out the chipset (G41) > only supports up to DDR3-1066 (as on specs, although the motherboard > lists the 1333 as supported, but as "OC", and allows configuring this > way automatically or manually). > > After setting manually back to 1066, I stopped seeing all the weird > behaviour, like the writes to the start address don't trigger anymore > setting on the head offset. I'm sorry about that, and really it's a > brown paper bag time for me :(. The machine worked fine and passed > through memtest and never gave any problems, this was the first > time (seems only the video device didn't like the memory setting, and > the code change probably changed timing in the right way to pop up this > now, also never had graphics corruption or other noticeable problems). > I retested kernels that gave problems and they run fine now. Well, at least we could clear this up. Greg, please pick up the following patches for 3.0 (if you haven't already): f01db988ef6f6c70a6cc36ee71e4a98a68901229 and 0d8957c8a90bbb5d34fab9a304459448a5131e06 Note that all kernels that need f01db backported also need b7884eb45ec98c0d34c7f49005ae9d4b4b4e38f6 (to fix a regression introduce by the former). Thanks, Daniel -- Daniel Vetter daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [ 04/16] drm/i915: correctly order the ring init sequence 2012-08-23 8:10 ` Daniel Vetter @ 2012-08-23 16:18 ` Herton Ronaldo Krzesinski 0 siblings, 0 replies; 25+ messages in thread From: Herton Ronaldo Krzesinski @ 2012-08-23 16:18 UTC (permalink / raw) To: Daniel Vetter Cc: Greg Kroah-Hartman, linux-kernel, stable, torvalds, akpm, alan, Jani Nikula, Yang Guang On Thu, Aug 23, 2012 at 10:10:18AM +0200, Daniel Vetter wrote: > On Thu, Aug 23, 2012 at 12:44 AM, Herton Ronaldo Krzesinski > <herton.krzesinski@canonical.com> wrote: > > Really sorry about this, but it was a hardware+bios setting problem > > here. I finished investigating what was happening here, and is related to > > the DRAM installed on this machine. The memory installed is DDR3-1333, > > and on bios it was configured as that, but turns out the chipset (G41) > > only supports up to DDR3-1066 (as on specs, although the motherboard > > lists the 1333 as supported, but as "OC", and allows configuring this > > way automatically or manually). > > > > After setting manually back to 1066, I stopped seeing all the weird > > behaviour, like the writes to the start address don't trigger anymore > > setting on the head offset. I'm sorry about that, and really it's a > > brown paper bag time for me :(. The machine worked fine and passed > > through memtest and never gave any problems, this was the first > > time (seems only the video device didn't like the memory setting, and > > the code change probably changed timing in the right way to pop up this > > now, also never had graphics corruption or other noticeable problems). > > I retested kernels that gave problems and they run fine now. > > Well, at least we could clear this up. > > Greg, please pick up the following patches for 3.0 (if you haven't already): > > f01db988ef6f6c70a6cc36ee71e4a98a68901229 and > 0d8957c8a90bbb5d34fab9a304459448a5131e06 > > Note that all kernels that need f01db backported also need > b7884eb45ec98c0d34c7f49005ae9d4b4b4e38f6 (to fix a regression > introduce by the former). b7884eb45ec98c0d34c7f49005ae9d4b4b4e38f6 needs some backporting for 3.0, I did it in advance, build tested and installed here on a sandybridge based laptop on x86_64: >From 3adf724d83de569510f2df0b91a097de92372970 Mon Sep 17 00:00:00 2001 From: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon, 4 Jun 2012 11:18:15 +0200 Subject: [PATCH 2/2] drm/i915: hold forcewake around ring hw init commit b7884eb45ec98c0d34c7f49005ae9d4b4b4e38f6 upstream. Empirical evidence suggests that we need to: On at least one ivb machine when running the hangman i-g-t test, the rings don't properly initialize properly - the RING_START registers seems to be stuck at all zeros. Holding forcewake around this register init sequences makes chip reset reliable again. Note that this is not the first such issue: commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 Author: Sean Paul <seanpaul@chromium.org> Date: Fri Mar 16 12:43:22 2012 -0400 drm/i915: Add wait_for in init_ring_common added delay loops to make RING_START and RING_CTL initialization reliable on the blt ring at boot-up. So I guess it won't hurt if we do this unconditionally for all force_wake needing gpus. To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new intel_info bit for that. v2: Fixup missing commas in static struct and properly handling the error case in init_ring_common, both noticed by Jani Nikula. Cc: stable@vger.kernel.org Reported-and-tested-by: Yang Guang <guang.a.yang@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [herton: backport to 3.0: - adjust for different struct intel_device_info layouts - drop changes to Haswell, not present in 3.0 - NEEDS_FORCE_WAKE is on i915_drv.h, and doesn't have IS_VALLEYVIEW ] Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> --- drivers/gpu/drm/i915/i915_drv.c | 4 ++++ drivers/gpu/drm/i915/i915_drv.h | 9 ++++++--- drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +++++++++++++--- 3 files changed, 23 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 111686a..9111d4c 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -181,6 +181,7 @@ static const struct intel_device_info intel_sandybridge_d_info = { .need_gfx_hws = 1, .has_hotplug = 1, .has_bsd_ring = 1, .has_blt_ring = 1, + .has_force_wake = 1, }; static const struct intel_device_info intel_sandybridge_m_info = { @@ -189,6 +190,7 @@ static const struct intel_device_info intel_sandybridge_m_info = { .has_fbc = 1, .has_bsd_ring = 1, .has_blt_ring = 1, + .has_force_wake = 1, }; static const struct intel_device_info intel_ivybridge_d_info = { @@ -196,6 +198,7 @@ static const struct intel_device_info intel_ivybridge_d_info = { .need_gfx_hws = 1, .has_hotplug = 1, .has_bsd_ring = 1, .has_blt_ring = 1, + .has_force_wake = 1, }; static const struct intel_device_info intel_ivybridge_m_info = { @@ -204,6 +207,7 @@ static const struct intel_device_info intel_ivybridge_m_info = { .has_fbc = 0, /* FBC is not enabled on Ivybridge mobile yet */ .has_bsd_ring = 1, .has_blt_ring = 1, + .has_force_wake = 1, }; static const struct pci_device_id pciidlist[] = { /* aka */ diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index b570415..e80acf9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -234,6 +234,7 @@ struct intel_device_info { u8 is_broadwater : 1; u8 is_crestline : 1; u8 is_ivybridge : 1; + u8 has_force_wake:1; u8 has_fbc : 1; u8 has_pipe_cxsr : 1; u8 has_hotplug : 1; @@ -986,6 +987,8 @@ struct drm_i915_file_private { #define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT) #define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX) +#define HAS_FORCE_WAKE(dev) (INTEL_INFO(dev)->has_force_wake) + #include "i915_trace.h" extern struct drm_ioctl_desc i915_ioctls[]; @@ -1342,9 +1345,9 @@ void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv); /* We give fast paths for the really cool registers */ #define NEEDS_FORCE_WAKE(dev_priv, reg) \ - (((dev_priv)->info->gen >= 6) && \ - ((reg) < 0x40000) && \ - ((reg) != FORCEWAKE)) + ((HAS_FORCE_WAKE((dev_priv)->dev)) && \ + ((reg) < 0x40000) && \ + ((reg) != FORCEWAKE)) #define __i915_read(x, y) \ static inline u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \ diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 38ae0ec..1e225d9 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -141,10 +141,15 @@ u32 intel_ring_get_active_head(struct intel_ring_buffer *ring) static int init_ring_common(struct intel_ring_buffer *ring) { - drm_i915_private_t *dev_priv = ring->dev->dev_private; + struct drm_device *dev = ring->dev; + drm_i915_private_t *dev_priv = dev->dev_private; struct drm_i915_gem_object *obj = ring->obj; + int ret = 0; u32 head; + if (HAS_FORCE_WAKE(dev)) + gen6_gt_force_wake_get(dev_priv); + /* Stop the ring if it's running. */ I915_WRITE_CTL(ring, 0); I915_WRITE_HEAD(ring, 0); @@ -195,7 +200,8 @@ static int init_ring_common(struct intel_ring_buffer *ring) I915_READ_HEAD(ring), I915_READ_TAIL(ring), I915_READ_START(ring)); - return -EIO; + ret = -EIO; + goto out; } if (!drm_core_check_feature(ring->dev, DRIVER_MODESET)) @@ -206,7 +212,11 @@ static int init_ring_common(struct intel_ring_buffer *ring) ring->space = ring_space(ring); } - return 0; +out: + if (HAS_FORCE_WAKE(dev)) + gen6_gt_force_wake_put(dev_priv); + + return ret; } /* -- 1.7.5.4 > > Thanks, Daniel > -- > Daniel Vetter > daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- []'s Herton ^ permalink raw reply related [flat|nested] 25+ messages in thread
* [ 05/16] drm/radeon: do not reenable crtc after moving vram start address 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (3 preceding siblings ...) 2012-08-20 3:56 ` [ 04/16] drm/i915: correctly order the ring init sequence Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 06/16] ext4: avoid kmemcheck complaint from reading uninitialized memory Greg Kroah-Hartman ` (10 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable; +Cc: Greg KH, torvalds, akpm, alan, Jerome Glisse From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jerome Glisse <jglisse@redhat.com> commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream. It seems we can not update the crtc scanout address. After disabling crtc, update to base address do not take effect after crtc being reenable leading to at least frame being scanout from the old crtc base address. Disabling crtc display request lead to same behavior. So after changing the vram address if we don't keep crtc disabled we will have the GPU trying to read some random system memory address with some iommu this will broke the crtc engine and will lead to broken display and iommu error message. So to avoid this, disable crtc. For flicker less boot we will need to avoid moving the vram start address. This patch should also fix : https://bugs.freedesktop.org/show_bug.cgi?id=42373 Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/gpu/drm/radeon/evergreen.c | 57 ----------------------------------- drivers/gpu/drm/radeon/radeon_asic.h | 8 +--- drivers/gpu/drm/radeon/rv515.c | 13 ------- 3 files changed, 2 insertions(+), 76 deletions(-) --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -1019,24 +1019,8 @@ void evergreen_agp_enable(struct radeon_ void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save *save) { - save->vga_control[0] = RREG32(D1VGA_CONTROL); - save->vga_control[1] = RREG32(D2VGA_CONTROL); save->vga_render_control = RREG32(VGA_RENDER_CONTROL); save->vga_hdp_control = RREG32(VGA_HDP_CONTROL); - save->crtc_control[0] = RREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET); - save->crtc_control[1] = RREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET); - if (rdev->num_crtc >= 4) { - save->vga_control[2] = RREG32(EVERGREEN_D3VGA_CONTROL); - save->vga_control[3] = RREG32(EVERGREEN_D4VGA_CONTROL); - save->crtc_control[2] = RREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET); - save->crtc_control[3] = RREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET); - } - if (rdev->num_crtc >= 6) { - save->vga_control[4] = RREG32(EVERGREEN_D5VGA_CONTROL); - save->vga_control[5] = RREG32(EVERGREEN_D6VGA_CONTROL); - save->crtc_control[4] = RREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET); - save->crtc_control[5] = RREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET); - } /* Stop all video */ WREG32(VGA_RENDER_CONTROL, 0); @@ -1147,47 +1131,6 @@ void evergreen_mc_resume(struct radeon_d /* Unlock host access */ WREG32(VGA_HDP_CONTROL, save->vga_hdp_control); mdelay(1); - /* Restore video state */ - WREG32(D1VGA_CONTROL, save->vga_control[0]); - WREG32(D2VGA_CONTROL, save->vga_control[1]); - if (rdev->num_crtc >= 4) { - WREG32(EVERGREEN_D3VGA_CONTROL, save->vga_control[2]); - WREG32(EVERGREEN_D4VGA_CONTROL, save->vga_control[3]); - } - if (rdev->num_crtc >= 6) { - WREG32(EVERGREEN_D5VGA_CONTROL, save->vga_control[4]); - WREG32(EVERGREEN_D6VGA_CONTROL, save->vga_control[5]); - } - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC0_REGISTER_OFFSET, 1); - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC1_REGISTER_OFFSET, 1); - if (rdev->num_crtc >= 4) { - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC2_REGISTER_OFFSET, 1); - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC3_REGISTER_OFFSET, 1); - } - if (rdev->num_crtc >= 6) { - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC4_REGISTER_OFFSET, 1); - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC5_REGISTER_OFFSET, 1); - } - WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET, save->crtc_control[0]); - WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET, save->crtc_control[1]); - if (rdev->num_crtc >= 4) { - WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET, save->crtc_control[2]); - WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET, save->crtc_control[3]); - } - if (rdev->num_crtc >= 6) { - WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET, save->crtc_control[4]); - WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET, save->crtc_control[5]); - } - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0); - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0); - if (rdev->num_crtc >= 4) { - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC2_REGISTER_OFFSET, 0); - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC3_REGISTER_OFFSET, 0); - } - if (rdev->num_crtc >= 6) { - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC4_REGISTER_OFFSET, 0); - WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC5_REGISTER_OFFSET, 0); - } WREG32(VGA_RENDER_CONTROL, save->vga_render_control); } --- a/drivers/gpu/drm/radeon/radeon_asic.h +++ b/drivers/gpu/drm/radeon/radeon_asic.h @@ -253,13 +253,10 @@ void rs690_line_buffer_adjust(struct rad * rv515 */ struct rv515_mc_save { - u32 d1vga_control; - u32 d2vga_control; u32 vga_render_control; u32 vga_hdp_control; - u32 d1crtc_control; - u32 d2crtc_control; }; + int rv515_init(struct radeon_device *rdev); void rv515_fini(struct radeon_device *rdev); uint32_t rv515_mc_rreg(struct radeon_device *rdev, uint32_t reg); @@ -387,11 +384,10 @@ void r700_cp_fini(struct radeon_device * * evergreen */ struct evergreen_mc_save { - u32 vga_control[6]; u32 vga_render_control; u32 vga_hdp_control; - u32 crtc_control[6]; }; + void evergreen_pcie_gart_tlb_flush(struct radeon_device *rdev); int evergreen_init(struct radeon_device *rdev); void evergreen_fini(struct radeon_device *rdev); --- a/drivers/gpu/drm/radeon/rv515.c +++ b/drivers/gpu/drm/radeon/rv515.c @@ -281,12 +281,8 @@ int rv515_debugfs_ga_info_init(struct ra void rv515_mc_stop(struct radeon_device *rdev, struct rv515_mc_save *save) { - save->d1vga_control = RREG32(R_000330_D1VGA_CONTROL); - save->d2vga_control = RREG32(R_000338_D2VGA_CONTROL); save->vga_render_control = RREG32(R_000300_VGA_RENDER_CONTROL); save->vga_hdp_control = RREG32(R_000328_VGA_HDP_CONTROL); - save->d1crtc_control = RREG32(R_006080_D1CRTC_CONTROL); - save->d2crtc_control = RREG32(R_006880_D2CRTC_CONTROL); /* Stop all video */ WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 0); @@ -311,15 +307,6 @@ void rv515_mc_resume(struct radeon_devic /* Unlock host access */ WREG32(R_000328_VGA_HDP_CONTROL, save->vga_hdp_control); mdelay(1); - /* Restore video state */ - WREG32(R_000330_D1VGA_CONTROL, save->d1vga_control); - WREG32(R_000338_D2VGA_CONTROL, save->d2vga_control); - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 1); - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 1); - WREG32(R_006080_D1CRTC_CONTROL, save->d1crtc_control); - WREG32(R_006880_D2CRTC_CONTROL, save->d2crtc_control); - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 0); - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 0); WREG32(R_000300_VGA_RENDER_CONTROL, save->vga_render_control); } ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 06/16] ext4: avoid kmemcheck complaint from reading uninitialized memory 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (4 preceding siblings ...) 2012-08-20 3:56 ` [ 05/16] drm/radeon: do not reenable crtc after moving vram start address Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 07/16] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk Greg Kroah-Hartman ` (9 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable; +Cc: Greg KH, torvalds, akpm, alan, Theodore Tso From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Theodore Ts'o <tytso@mit.edu> commit 7e731bc9a12339f344cddf82166b82633d99dd86 upstream. Commit 03179fe923 introduced a kmemcheck complaint in ext4_da_get_block_prep() because we save and restore ei->i_da_metadata_calc_last_lblock even though it is left uninitialized in the case where i_da_metadata_calc_len is zero. This doesn't hurt anything, but silencing the kmemcheck complaint makes it easier for people to find real bugs. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45631 (which is marked as a regression). Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/ext4/super.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -860,6 +860,7 @@ static struct inode *ext4_alloc_inode(st ei->i_reserved_meta_blocks = 0; ei->i_allocated_meta_blocks = 0; ei->i_da_metadata_calc_len = 0; + ei->i_da_metadata_calc_last_lblock = 0; spin_lock_init(&(ei->i_block_reservation_lock)); #ifdef CONFIG_QUOTA ei->i_reserved_quota = 0; ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 07/16] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk. 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (5 preceding siblings ...) 2012-08-20 3:56 ` [ 06/16] ext4: avoid kmemcheck complaint from reading uninitialized memory Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 08/16] xhci: Increase reset timeout for Renesas 720201 host Greg Kroah-Hartman ` (8 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Sarah Sharp, Gary E. Miller From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sarah Sharp <sarah.a.sharp@linux.intel.com> commit 5cb7df2b2d3afee7638b3ef23a5bcb89c6f07bd9 upstream. Gary reports that with recent kernels, he notices more xHCI driver warnings: xhci_hcd 0000:03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? We think his Etron xHCI host controller may have the same buggy behavior as the Fresco Logic xHCI host. When a short transfer is received, the host will mark the transfer as successfully completed when it should be marking it with a short completion. Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron host is discovered. Note that Gary has revision 1, but if Etron fixes this bug in future revisions, the quirk will have no effect. This patch should be backported to kernels as old as 2.6.36, that contain a backported version of commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 "xhci: Add new short TX quirk for Fresco Logic host." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Gary E. Miller <gem@rellim.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/host/xhci-pci.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -145,6 +145,7 @@ static int xhci_pci_setup(struct usb_hcd pdev->device == PCI_DEVICE_ID_ASROCK_P67) { xhci->quirks |= XHCI_RESET_ON_RESUME; xhci_dbg(xhci, "QUIRK: Resetting on resume\n"); + xhci->quirks |= XHCI_TRUST_TX_LENGTH; } if (pdev->vendor == PCI_VENDOR_ID_VIA) xhci->quirks |= XHCI_RESET_ON_RESUME; ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 08/16] xhci: Increase reset timeout for Renesas 720201 host. 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (6 preceding siblings ...) 2012-08-20 3:56 ` [ 07/16] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 09/16] xhci: Switch PPT ports to EHCI on shutdown Greg Kroah-Hartman ` (7 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Sarah Sharp, Edwin Klein Mentink From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sarah Sharp <sarah.a.sharp@linux.intel.com> commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b upstream. The NEC/Renesas 720201 xHCI host controller does not complete its reset within 250 milliseconds. In fact, it takes about 9 seconds to reset the host controller, and 1 second for the host to be ready for doorbell rings. Extend the reset and CNR polling timeout to 10 seconds each. This patch should be backported to kernels as old as 2.6.31, that contain the commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff and HW initialization." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Edwin Klein Mentink <e.kleinmentink@zonnet.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/host/xhci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -163,7 +163,7 @@ int xhci_reset(struct xhci_hcd *xhci) xhci_writel(xhci, command, &xhci->op_regs->command); ret = handshake(xhci, &xhci->op_regs->command, - CMD_RESET, 0, 250 * 1000); + CMD_RESET, 0, 10 * 1000 * 1000); if (ret) return ret; @@ -172,7 +172,8 @@ int xhci_reset(struct xhci_hcd *xhci) * xHCI cannot write to any doorbells or operational registers other * than status until the "Controller Not Ready" flag is cleared. */ - return handshake(xhci, &xhci->op_regs->status, STS_CNR, 0, 250 * 1000); + return handshake(xhci, &xhci->op_regs->status, + STS_CNR, 0, 10 * 1000 * 1000); } /* ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 09/16] xhci: Switch PPT ports to EHCI on shutdown. 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (7 preceding siblings ...) 2012-08-20 3:56 ` [ 08/16] xhci: Increase reset timeout for Renesas 720201 host Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 10/16] USB: add USB_VENDOR_AND_INTERFACE_INFO() macro Greg Kroah-Hartman ` (6 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Sarah Sharp, Denis Turischev From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sarah Sharp <sarah.a.sharp@linux.intel.com> commit e95829f474f0db3a4d940cae1423783edd966027 upstream. The Intel desktop boards DH77EB and DH77DF have a hardware issue that can be worked around by BIOS. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS will work around this, but not all. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. The Intel Windows driver switches the ports back to EHCI, so change the Linux xHCI driver to do the same. Unfortunately, we can't tell the two effected boards apart from other working motherboards, because the vendors will change the DMI strings for the DH77EB and DH77DF boards to their own custom names. One example is Compulab's mini-desktop, the Intense-PC. Instead, key off the Panther Point xHCI host PCI vendor and device ID, and switch the ports over for all PPT xHCI hosts. The only impact this will have on non-effected boards is to add a couple hundred milliseconds delay on boot when the BIOS has to switch the ports over from EHCI to xHCI. This patch should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Denis Turischev <denis@compulab.co.il> Tested-by: Denis Turischev <denis@compulab.co.il> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/host/pci-quirks.c | 7 +++++++ drivers/usb/host/pci-quirks.h | 1 + drivers/usb/host/xhci-pci.c | 9 +++++++++ drivers/usb/host/xhci.c | 3 +++ drivers/usb/host/xhci.h | 1 + 5 files changed, 21 insertions(+) --- a/drivers/usb/host/pci-quirks.c +++ b/drivers/usb/host/pci-quirks.c @@ -798,6 +798,13 @@ void usb_enable_xhci_ports(struct pci_de } EXPORT_SYMBOL_GPL(usb_enable_xhci_ports); +void usb_disable_xhci_ports(struct pci_dev *xhci_pdev) +{ + pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0); + pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0); +} +EXPORT_SYMBOL_GPL(usb_disable_xhci_ports); + /** * PCI Quirks for xHCI. * --- a/drivers/usb/host/pci-quirks.h +++ b/drivers/usb/host/pci-quirks.h @@ -10,6 +10,7 @@ void usb_amd_quirk_pll_disable(void); void usb_amd_quirk_pll_enable(void); bool usb_is_intel_switchable_xhci(struct pci_dev *pdev); void usb_enable_xhci_ports(struct pci_dev *xhci_pdev); +void usb_disable_xhci_ports(struct pci_dev *xhci_pdev); #else static inline void usb_amd_quirk_pll_disable(void) {} static inline void usb_amd_quirk_pll_enable(void) {} --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -140,6 +140,15 @@ static int xhci_pci_setup(struct usb_hcd xhci->quirks |= XHCI_SPURIOUS_SUCCESS; xhci->quirks |= XHCI_EP_LIMIT_QUIRK; xhci->limit_active_eps = 64; + /* + * PPT desktop boards DH77EB and DH77DF will power back on after + * a few seconds of being shutdown. The fix for this is to + * switch the ports from xHCI to EHCI on shutdown. We can't use + * DMI information to find those particular boards (since each + * vendor will change the board name), so we have to key off all + * PPT chipsets. + */ + xhci->quirks |= XHCI_SPURIOUS_REBOOT; } if (pdev->vendor == PCI_VENDOR_ID_ETRON && pdev->device == PCI_DEVICE_ID_ASROCK_P67) { --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -594,6 +594,9 @@ void xhci_shutdown(struct usb_hcd *hcd) { struct xhci_hcd *xhci = hcd_to_xhci(hcd); + if (xhci->quirks && XHCI_SPURIOUS_REBOOT) + usb_disable_xhci_ports(to_pci_dev(hcd->self.controller)); + spin_lock_irq(&xhci->lock); xhci_halt(xhci); spin_unlock_irq(&xhci->lock); --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1316,6 +1316,7 @@ struct xhci_hcd { #define XHCI_RESET_ON_RESUME (1 << 7) #define XHCI_AMD_0x96_HOST (1 << 9) #define XHCI_TRUST_TX_LENGTH (1 << 10) +#define XHCI_SPURIOUS_REBOOT (1 << 13) unsigned int num_active_eps; unsigned int limit_active_eps; /* There are two roothubs to keep track of bus suspend info for */ ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 10/16] USB: add USB_VENDOR_AND_INTERFACE_INFO() macro 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (8 preceding siblings ...) 2012-08-20 3:56 ` [ 09/16] xhci: Switch PPT ports to EHCI on shutdown Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 11/16] USB: support the new interfaces of Huawei Data Card devices in option driver Greg Kroah-Hartman ` (5 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Marcel Holtmann, Gustavo Padovan, Henrik Rydberg From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> commit d81a5d1956731c453b85c141458d4ff5d6cc5366 upstream. A lot of Broadcom Bluetooth devices provides vendor specific interface class and we are getting flooded by patches adding new device support. This change will help us enable support for any other Broadcom with vendor specific device that arrives in the future. Only the product id changes for those devices, so this macro would be perfect for us: { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) } Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: Henrik Rydberg <rydberg@bitmath.se> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- include/linux/usb.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -757,6 +757,27 @@ static inline int usb_make_path(struct u .bInterfaceSubClass = (sc), \ .bInterfaceProtocol = (pr) +/** + * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb vendor with a class of usb interfaces + * @vend: the 16 bit USB Vendor ID + * @cl: bInterfaceClass value + * @sc: bInterfaceSubClass value + * @pr: bInterfaceProtocol value + * + * This macro is used to create a struct usb_device_id that matches a + * specific vendor with a specific class of interfaces. + * + * This is especially useful when explicitly matching devices that have + * vendor specific bDeviceClass values, but standards-compliant interfaces. + */ +#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \ + .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \ + | USB_DEVICE_ID_MATCH_VENDOR, \ + .idVendor = (vend), \ + .bInterfaceClass = (cl), \ + .bInterfaceSubClass = (sc), \ + .bInterfaceProtocol = (pr) + /* ----------------------------------------------------------------------- */ /* Stuff for dynamic usb ids */ ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 11/16] USB: support the new interfaces of Huawei Data Card devices in option driver 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (9 preceding siblings ...) 2012-08-20 3:56 ` [ 10/16] USB: add USB_VENDOR_AND_INTERFACE_INFO() macro Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 12/16] USB: option: add ZTE K5006-Z Greg Kroah-Hartman ` (4 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable; +Cc: Greg KH, torvalds, akpm, alan, fangxiaozhi From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: fangxiaozhi <huananhu@huawei.com> commit ee6f827df9107139e8960326e49e1376352ced4d upstream. In this patch, we add new declarations into option.c to support the new interfaces of Huawei Data Card devices. And at the same time, remove the redundant declarations from option.c. Signed-off-by: fangxiaozhi <huananhu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/serial/option.c | 279 +++++++++++++++++--------------------------- 1 file changed, 111 insertions(+), 168 deletions(-) --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -80,85 +80,9 @@ static void option_instat_callback(struc #define OPTION_PRODUCT_GTM380_MODEM 0x7201 #define HUAWEI_VENDOR_ID 0x12D1 -#define HUAWEI_PRODUCT_E600 0x1001 -#define HUAWEI_PRODUCT_E220 0x1003 -#define HUAWEI_PRODUCT_E220BIS 0x1004 -#define HUAWEI_PRODUCT_E1401 0x1401 -#define HUAWEI_PRODUCT_E1402 0x1402 -#define HUAWEI_PRODUCT_E1403 0x1403 -#define HUAWEI_PRODUCT_E1404 0x1404 -#define HUAWEI_PRODUCT_E1405 0x1405 -#define HUAWEI_PRODUCT_E1406 0x1406 -#define HUAWEI_PRODUCT_E1407 0x1407 -#define HUAWEI_PRODUCT_E1408 0x1408 -#define HUAWEI_PRODUCT_E1409 0x1409 -#define HUAWEI_PRODUCT_E140A 0x140A -#define HUAWEI_PRODUCT_E140B 0x140B -#define HUAWEI_PRODUCT_E140C 0x140C -#define HUAWEI_PRODUCT_E140D 0x140D -#define HUAWEI_PRODUCT_E140E 0x140E -#define HUAWEI_PRODUCT_E140F 0x140F -#define HUAWEI_PRODUCT_E1410 0x1410 -#define HUAWEI_PRODUCT_E1411 0x1411 -#define HUAWEI_PRODUCT_E1412 0x1412 -#define HUAWEI_PRODUCT_E1413 0x1413 -#define HUAWEI_PRODUCT_E1414 0x1414 -#define HUAWEI_PRODUCT_E1415 0x1415 -#define HUAWEI_PRODUCT_E1416 0x1416 -#define HUAWEI_PRODUCT_E1417 0x1417 -#define HUAWEI_PRODUCT_E1418 0x1418 -#define HUAWEI_PRODUCT_E1419 0x1419 -#define HUAWEI_PRODUCT_E141A 0x141A -#define HUAWEI_PRODUCT_E141B 0x141B -#define HUAWEI_PRODUCT_E141C 0x141C -#define HUAWEI_PRODUCT_E141D 0x141D -#define HUAWEI_PRODUCT_E141E 0x141E -#define HUAWEI_PRODUCT_E141F 0x141F -#define HUAWEI_PRODUCT_E1420 0x1420 -#define HUAWEI_PRODUCT_E1421 0x1421 -#define HUAWEI_PRODUCT_E1422 0x1422 -#define HUAWEI_PRODUCT_E1423 0x1423 -#define HUAWEI_PRODUCT_E1424 0x1424 -#define HUAWEI_PRODUCT_E1425 0x1425 -#define HUAWEI_PRODUCT_E1426 0x1426 -#define HUAWEI_PRODUCT_E1427 0x1427 -#define HUAWEI_PRODUCT_E1428 0x1428 -#define HUAWEI_PRODUCT_E1429 0x1429 -#define HUAWEI_PRODUCT_E142A 0x142A -#define HUAWEI_PRODUCT_E142B 0x142B -#define HUAWEI_PRODUCT_E142C 0x142C -#define HUAWEI_PRODUCT_E142D 0x142D -#define HUAWEI_PRODUCT_E142E 0x142E -#define HUAWEI_PRODUCT_E142F 0x142F -#define HUAWEI_PRODUCT_E1430 0x1430 -#define HUAWEI_PRODUCT_E1431 0x1431 -#define HUAWEI_PRODUCT_E1432 0x1432 -#define HUAWEI_PRODUCT_E1433 0x1433 -#define HUAWEI_PRODUCT_E1434 0x1434 -#define HUAWEI_PRODUCT_E1435 0x1435 -#define HUAWEI_PRODUCT_E1436 0x1436 -#define HUAWEI_PRODUCT_E1437 0x1437 -#define HUAWEI_PRODUCT_E1438 0x1438 -#define HUAWEI_PRODUCT_E1439 0x1439 -#define HUAWEI_PRODUCT_E143A 0x143A -#define HUAWEI_PRODUCT_E143B 0x143B -#define HUAWEI_PRODUCT_E143C 0x143C -#define HUAWEI_PRODUCT_E143D 0x143D -#define HUAWEI_PRODUCT_E143E 0x143E -#define HUAWEI_PRODUCT_E143F 0x143F #define HUAWEI_PRODUCT_K4505 0x1464 #define HUAWEI_PRODUCT_K3765 0x1465 -#define HUAWEI_PRODUCT_E14AC 0x14AC -#define HUAWEI_PRODUCT_K3806 0x14AE #define HUAWEI_PRODUCT_K4605 0x14C6 -#define HUAWEI_PRODUCT_K5005 0x14C8 -#define HUAWEI_PRODUCT_K3770 0x14C9 -#define HUAWEI_PRODUCT_K3771 0x14CA -#define HUAWEI_PRODUCT_K4510 0x14CB -#define HUAWEI_PRODUCT_K4511 0x14CC -#define HUAWEI_PRODUCT_ETS1220 0x1803 -#define HUAWEI_PRODUCT_E353 0x1506 -#define HUAWEI_PRODUCT_E173S 0x1C05 #define QUANTA_VENDOR_ID 0x0408 #define QUANTA_PRODUCT_Q101 0xEA02 @@ -615,104 +539,123 @@ static const struct usb_device_id option { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GLX) }, { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GKE) }, { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GLE) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1401, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1402, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1403, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1404, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1405, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1406, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1407, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1408, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1409, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E140A, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E140B, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E140C, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E140D, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E140E, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E140F, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1410, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1411, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1412, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1413, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1414, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1415, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1416, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1417, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1418, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1419, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E141A, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E141B, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E141C, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E141D, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E141E, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E141F, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1420, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1421, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1422, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1423, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1424, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1425, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1426, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1427, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1428, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1429, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E142A, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E142B, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E142C, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E142D, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E142E, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E142F, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1430, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1431, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1432, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1433, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1434, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1435, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1436, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1437, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1438, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1439, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143A, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143B, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143C, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143D, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143E, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E143F, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173S, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4505, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3765, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_ETS1220, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E14AC, 0xff, 0xff, 0xff) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3806, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605, 0xff, 0x01, 0x31) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605, 0xff, 0x01, 0x32) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005, 0xff, 0x01, 0x31) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005, 0xff, 0x01, 0x32) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005, 0xff, 0x01, 0x33) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770, 0xff, 0x02, 0x31) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770, 0xff, 0x02, 0x32) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771, 0xff, 0x02, 0x31) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771, 0xff, 0x02, 0x32) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510, 0xff, 0x01, 0x31) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510, 0xff, 0x01, 0x32) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511, 0xff, 0x01, 0x31) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511, 0xff, 0x01, 0x32) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x01, 0x01) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x01, 0x02) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x01, 0x03) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x01, 0x10) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x01, 0x12) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x01, 0x13) }, - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x02, 0x01) }, /* E398 3G Modem */ - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x02, 0x02) }, /* E398 3G PC UI Interface */ - { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353, 0xff, 0x02, 0x03) }, /* E398 3G Application Interface */ + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0xff, 0xff) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x01) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x02) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x03) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x04) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x05) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x06) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0D) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0E) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0F) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x10) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x12) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x13) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x14) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x15) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x17) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x18) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x19) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1C) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x31) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x32) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x33) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x34) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x35) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x36) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3D) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3E) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3F) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x48) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x49) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4C) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x61) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x62) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x63) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x64) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x65) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x66) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6D) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6E) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6F) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x78) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x79) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x7A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x7B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x7C) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x01) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x02) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x03) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x04) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x05) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x06) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x0A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x0B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x0D) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x0E) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x0F) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x10) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x12) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x13) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x14) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x15) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x17) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x18) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x19) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x1A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x1B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x1C) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x31) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x32) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x33) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x34) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x35) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x36) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x3A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x3B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x3D) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x3E) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x3F) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x48) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x49) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x4A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x4B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x4C) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x61) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x62) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x63) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x64) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x65) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x66) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6D) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6E) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6F) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x78) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x79) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x7A) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x7B) }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x7C) }, + + { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_V640) }, { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_V620) }, { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_V740) }, ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 12/16] USB: option: add ZTE K5006-Z 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (10 preceding siblings ...) 2012-08-20 3:56 ` [ 11/16] USB: support the new interfaces of Huawei Data Card devices in option driver Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 13/16] USB: ftdi_sio: Add VID/PID for Kondo Serial USB Greg Kroah-Hartman ` (3 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Bjørn Mork, Thomas Schäfer From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Bjørn Mork <bjorn@mork.no> commit f1b5c997e68533df1f96dcd3068a231bca495603 upstream. The ZTE (Vodafone) K5006-Z use the following interface layout: 00 DIAG 01 secondary 02 modem 03 networkcard 04 storage Ignoring interface #3 which is handled by the qmi_wwan driver. Signed-off-by: Bjørn Mork <bjorn@mork.no> Cc: Thomas Schäfer <tschaefer@t-online.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -882,6 +882,8 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1008, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1010, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1012, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1018, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)&net_intf3_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1057, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1058, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1059, 0xff, 0xff, 0xff) }, ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 13/16] USB: ftdi_sio: Add VID/PID for Kondo Serial USB 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (11 preceding siblings ...) 2012-08-20 3:56 ` [ 12/16] USB: option: add ZTE K5006-Z Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 14/16] usb: serial: mos7840: Fixup mos7840_chars_in_buffer() Greg Kroah-Hartman ` (2 subsequent siblings) 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Ozan Çağlayan From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ozan Çağlayan <ozancag@gmail.com> commit 7724a1edbe463b06d4e7831a41149ba095b16c53 upstream. This adds VID/PID for Kondo Kagaku Co. Ltd. Serial USB Adapter interface: http://www.kondo-robot.com/EN/wp/?cat=28 Tested by controlling an RCB3 board using libRCB3. Signed-off-by: Ozan Çağlayan <ozancag@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 7 +++++++ 2 files changed, 8 insertions(+) --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -809,6 +809,7 @@ static struct usb_device_id id_table_com { USB_DEVICE(LARSENBRUSGAARD_VID, LB_ALTITRACK_PID) }, { USB_DEVICE(GN_OTOMETRICS_VID, AURICAL_USB_PID) }, { USB_DEVICE(PI_VID, PI_E861_PID) }, + { USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) }, { USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) }, { USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID), .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk }, --- a/drivers/usb/serial/ftdi_sio_ids.h +++ b/drivers/usb/serial/ftdi_sio_ids.h @@ -795,6 +795,13 @@ #define PI_E861_PID 0x1008 /* E-861 piezo controller USB connection */ /* + * Kondo Kagaku Co.Ltd. + * http://www.kondo-robot.com/EN + */ +#define KONDO_VID 0x165c +#define KONDO_USB_SERIAL_PID 0x0002 + +/* * Bayer Ascensia Contour blood glucose meter USB-converter cable. * http://winglucofacts.com/cables/ */ ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 14/16] usb: serial: mos7840: Fixup mos7840_chars_in_buffer() 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (12 preceding siblings ...) 2012-08-20 3:56 ` [ 13/16] USB: ftdi_sio: Add VID/PID for Kondo Serial USB Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 15/16] rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb Greg Kroah-Hartman 2012-08-20 3:56 ` [ 16/16] IB/srp: Fix a race condition Greg Kroah-Hartman 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable; +Cc: Greg KH, torvalds, akpm, alan, Mark Ferrell From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mark Ferrell <mferrell@uplogix.com> commit 5c263b92f828af6a8cf54041db45ceae5af8f2ab upstream. * Use the buffer content length as opposed to the total buffer size. This can be a real problem when using the mos7840 as a usb serial-console as all kernel output is truncated during boot. Signed-off-by: Mark Ferrell <mferrell@uplogix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/serial/mos7840.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/usb/serial/mos7840.c +++ b/drivers/usb/serial/mos7840.c @@ -1191,9 +1191,12 @@ static int mos7840_chars_in_buffer(struc } spin_lock_irqsave(&mos7840_port->pool_lock, flags); - for (i = 0; i < NUM_URBS; ++i) - if (mos7840_port->busy[i]) - chars += URB_TRANSFER_BUFFER_SIZE; + for (i = 0; i < NUM_URBS; ++i) { + if (mos7840_port->busy[i]) { + struct urb *urb = mos7840_port->write_urb_pool[i]; + chars += urb->transfer_buffer_length; + } + } spin_unlock_irqrestore(&mos7840_port->pool_lock, flags); dbg("%s - returns %d", __func__, chars); return chars; ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 15/16] rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb. 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (13 preceding siblings ...) 2012-08-20 3:56 ` [ 14/16] usb: serial: mos7840: Fixup mos7840_chars_in_buffer() Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 2012-08-20 3:56 ` [ 16/16] IB/srp: Fix a race condition Greg Kroah-Hartman 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Jeongdo Son, John W. Linville From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jeongdo Son <sohn9086@gmail.com> commit a769f9577232afe2c754606a83aad85127e7052a upstream. This is a RT3070 based device. Signed-off-by: Jeongdo Son <sohn9086@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/net/wireless/rt2x00/rt2800usb.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/wireless/rt2x00/rt2800usb.c +++ b/drivers/net/wireless/rt2x00/rt2800usb.c @@ -829,6 +829,7 @@ static struct usb_device_id rt2800usb_de { USB_DEVICE(0x0411, 0x015d) }, { USB_DEVICE(0x0411, 0x016f) }, { USB_DEVICE(0x0411, 0x01a2) }, + { USB_DEVICE(0x0411, 0x01ee) }, /* Corega */ { USB_DEVICE(0x07aa, 0x002f) }, { USB_DEVICE(0x07aa, 0x003c) }, ^ permalink raw reply [flat|nested] 25+ messages in thread
* [ 16/16] IB/srp: Fix a race condition 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman ` (14 preceding siblings ...) 2012-08-20 3:56 ` [ 15/16] rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb Greg Kroah-Hartman @ 2012-08-20 3:56 ` Greg Kroah-Hartman 15 siblings, 0 replies; 25+ messages in thread From: Greg Kroah-Hartman @ 2012-08-20 3:56 UTC (permalink / raw) To: linux-kernel, stable Cc: Greg KH, torvalds, akpm, alan, Joseph Glanville, David Dillow, Bart Van Assche, Roland Dreier From: Greg KH <gregkh@linuxfoundation.org> 3.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Bart Van Assche <bvanassche@acm.org> commit 220329916c72ee3d54ae7262b215a050f04a18fc upstream. Avoid a crash caused by the scmnd->scsi_done(scmnd) call in srp_process_rsp() being invoked with scsi_done == NULL. This can happen if a reply is received during or after a command abort. Reported-by: Joseph Glanville <joseph.glanville@orionvm.com.au> Reference: http://marc.info/?l=linux-rdma&m=134314367801595 Acked-by: David Dillow <dillowda@ornl.gov> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/infiniband/ulp/srp/ib_srp.c | 87 ++++++++++++++++++++++++++---------- 1 file changed, 63 insertions(+), 24 deletions(-) --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -568,24 +568,62 @@ static void srp_unmap_data(struct scsi_c scmnd->sc_data_direction); } -static void srp_remove_req(struct srp_target_port *target, - struct srp_request *req, s32 req_lim_delta) +/** + * srp_claim_req - Take ownership of the scmnd associated with a request. + * @target: SRP target port. + * @req: SRP request. + * @scmnd: If NULL, take ownership of @req->scmnd. If not NULL, only take + * ownership of @req->scmnd if it equals @scmnd. + * + * Return value: + * Either NULL or a pointer to the SCSI command the caller became owner of. + */ +static struct scsi_cmnd *srp_claim_req(struct srp_target_port *target, + struct srp_request *req, + struct scsi_cmnd *scmnd) { unsigned long flags; - srp_unmap_data(req->scmnd, target, req); + spin_lock_irqsave(&target->lock, flags); + if (!scmnd) { + scmnd = req->scmnd; + req->scmnd = NULL; + } else if (req->scmnd == scmnd) { + req->scmnd = NULL; + } else { + scmnd = NULL; + } + spin_unlock_irqrestore(&target->lock, flags); + + return scmnd; +} + +/** + * srp_free_req() - Unmap data and add request to the free request list. + */ +static void srp_free_req(struct srp_target_port *target, + struct srp_request *req, struct scsi_cmnd *scmnd, + s32 req_lim_delta) +{ + unsigned long flags; + + srp_unmap_data(scmnd, target, req); + spin_lock_irqsave(&target->lock, flags); target->req_lim += req_lim_delta; - req->scmnd = NULL; list_add_tail(&req->list, &target->free_reqs); spin_unlock_irqrestore(&target->lock, flags); } static void srp_reset_req(struct srp_target_port *target, struct srp_request *req) { - req->scmnd->result = DID_RESET << 16; - req->scmnd->scsi_done(req->scmnd); - srp_remove_req(target, req, 0); + struct scsi_cmnd *scmnd = srp_claim_req(target, req, NULL); + + if (scmnd) { + scmnd->result = DID_RESET << 16; + scmnd->scsi_done(scmnd); + srp_free_req(target, req, scmnd, 0); + } } static int srp_reconnect_target(struct srp_target_port *target) @@ -1055,11 +1093,18 @@ static void srp_process_rsp(struct srp_t complete(&target->tsk_mgmt_done); } else { req = &target->req_ring[rsp->tag]; - scmnd = req->scmnd; - if (!scmnd) + scmnd = srp_claim_req(target, req, NULL); + if (!scmnd) { shost_printk(KERN_ERR, target->scsi_host, "Null scmnd for RSP w/tag %016llx\n", (unsigned long long) rsp->tag); + + spin_lock_irqsave(&target->lock, flags); + target->req_lim += be32_to_cpu(rsp->req_lim_delta); + spin_unlock_irqrestore(&target->lock, flags); + + return; + } scmnd->result = rsp->status; if (rsp->flags & SRP_RSP_FLAG_SNSVALID) { @@ -1074,7 +1119,9 @@ static void srp_process_rsp(struct srp_t else if (rsp->flags & (SRP_RSP_FLAG_DIOVER | SRP_RSP_FLAG_DIUNDER)) scsi_set_resid(scmnd, be32_to_cpu(rsp->data_in_res_cnt)); - srp_remove_req(target, req, be32_to_cpu(rsp->req_lim_delta)); + srp_free_req(target, req, scmnd, + be32_to_cpu(rsp->req_lim_delta)); + scmnd->host_scribble = NULL; scmnd->scsi_done(scmnd); } @@ -1613,25 +1660,17 @@ static int srp_abort(struct scsi_cmnd *s { struct srp_target_port *target = host_to_target(scmnd->device->host); struct srp_request *req = (struct srp_request *) scmnd->host_scribble; - int ret = SUCCESS; shost_printk(KERN_ERR, target->scsi_host, "SRP abort called\n"); - if (!req || target->qp_in_error) - return FAILED; - if (srp_send_tsk_mgmt(target, req->index, scmnd->device->lun, - SRP_TSK_ABORT_TASK)) + if (!req || target->qp_in_error || !srp_claim_req(target, req, scmnd)) return FAILED; + srp_send_tsk_mgmt(target, req->index, scmnd->device->lun, + SRP_TSK_ABORT_TASK); + srp_free_req(target, req, scmnd, 0); + scmnd->result = DID_ABORT << 16; - if (req->scmnd) { - if (!target->tsk_mgmt_status) { - srp_remove_req(target, req, 0); - scmnd->result = DID_ABORT << 16; - } else - ret = FAILED; - } - - return ret; + return SUCCESS; } static int srp_reset_device(struct scsi_cmnd *scmnd) ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2012-08-23 16:18 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-20 3:55 [ 00/16] 3.0.42-stable review Greg Kroah-Hartman 2012-08-20 3:56 ` [ 01/16] s390/compat: fix mmap compat system calls Greg Kroah-Hartman 2012-08-20 3:56 ` [ 02/16] fuse: verify all ioctl retry iov elements Greg Kroah-Hartman 2012-08-20 3:56 ` [ 03/16] xen: mark local pages as FOREIGN in the m2p_override Greg Kroah-Hartman 2012-08-20 3:56 ` [ 04/16] drm/i915: correctly order the ring init sequence Greg Kroah-Hartman 2012-08-21 5:13 ` Herton Ronaldo Krzesinski 2012-08-21 6:42 ` Daniel Vetter 2012-08-21 13:11 ` Herton Ronaldo Krzesinski 2012-08-21 16:55 ` Daniel Vetter 2012-08-22 4:50 ` Herton Ronaldo Krzesinski 2012-08-22 22:44 ` Herton Ronaldo Krzesinski 2012-08-23 8:10 ` Daniel Vetter 2012-08-23 16:18 ` Herton Ronaldo Krzesinski 2012-08-20 3:56 ` [ 05/16] drm/radeon: do not reenable crtc after moving vram start address Greg Kroah-Hartman 2012-08-20 3:56 ` [ 06/16] ext4: avoid kmemcheck complaint from reading uninitialized memory Greg Kroah-Hartman 2012-08-20 3:56 ` [ 07/16] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk Greg Kroah-Hartman 2012-08-20 3:56 ` [ 08/16] xhci: Increase reset timeout for Renesas 720201 host Greg Kroah-Hartman 2012-08-20 3:56 ` [ 09/16] xhci: Switch PPT ports to EHCI on shutdown Greg Kroah-Hartman 2012-08-20 3:56 ` [ 10/16] USB: add USB_VENDOR_AND_INTERFACE_INFO() macro Greg Kroah-Hartman 2012-08-20 3:56 ` [ 11/16] USB: support the new interfaces of Huawei Data Card devices in option driver Greg Kroah-Hartman 2012-08-20 3:56 ` [ 12/16] USB: option: add ZTE K5006-Z Greg Kroah-Hartman 2012-08-20 3:56 ` [ 13/16] USB: ftdi_sio: Add VID/PID for Kondo Serial USB Greg Kroah-Hartman 2012-08-20 3:56 ` [ 14/16] usb: serial: mos7840: Fixup mos7840_chars_in_buffer() Greg Kroah-Hartman 2012-08-20 3:56 ` [ 15/16] rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb Greg Kroah-Hartman 2012-08-20 3:56 ` [ 16/16] IB/srp: Fix a race condition Greg Kroah-Hartman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).