[PATCH 0/1] xhci: Recognize USB 3.0 devices as superspeed at powerup
From: Manoj Iyer On Intel Panther Point chipset USB 3.0 devices show up as high-speed devices on powerup, but after an s3 cycle they are correctly recognized as SuperSpeed. At powerup switch the port to xHCI so that USB 3.0 devices are correctly recognized. This is a second attempt at fixing this based on review comments to my earlier patch from Andiry Xu BugLink: http://bugs.launchpad.net/bugs/1000424 Test results after applying patch == USB 3.0 device connected to SuperSpeed port [ 34.694033] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd [ 34.712925] scsi6 : usb-storage 4-1:1.0 [ 35.709947] scsi 6:0:0:0: Direct-Access JetFlash Transcend 16GB 1.00 PQ: 0 ANSI: 5 [ 35.710886] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 35.711475] sd 6:0:0:0: [sdc] 30871552 512-byte logical blocks: (15.8 GB/14.7 GiB) [ 35.712721] sd 6:0:0:0: [sdc] Write Protect is off [ 35.712725] sd 6:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 35.712841] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 35.714627] sdc: sdc1 USB 3.0 device connected to highspeed port --- [ 148.128616] usb 1-1.2: new high-speed USB device number 5 using ehci_hcd [ 148.226040] scsi7 : usb-storage 1-1.2:1.0 [ 149.225645] scsi 7:0:0:0: Direct-Access JetFlash Transcend 16GB 1.00 PQ: 0 ANSI: 5 [ 149.227690] sd 7:0:0:0: Attached scsi generic sg3 type 0 [ 149.230196] sd 7:0:0:0: [sdc] 30871552 512-byte logical blocks: (15.8 GB/14.7 GiB) [ 149.230555] sd 7:0:0:0: [sdc] Write Protect is off [ 149.230563] sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 149.231333] sd 7:0:0:0: [sdc] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 149.235822] sdc: sdc1 [ 149.238035] sd 7:0:0:0: [sdc] Attached SCSI removable disk Manoj Iyer (1): xhci: Recognize USB 3.0 devices as superspeed at powerup drivers/usb/host/pci-quirks.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] xhci: Unconditionally switch ports to xHCI on powerup
If this is a must-to-do thing for Intel Panther Point platform, then we need to make sure it's called on power up and resume. Yes, I think moving the code below hc_init label should work and I think it's a better solution than your original patch. Yes it effects a lot of machines (Lenovo), I will send out a new seperate patch with the fix. Thanks Manoj Thanks, Andiry On Tue, 21 Aug 2012, Andiry Xu wrote: On Tue, Aug 21, 2012 at 12:06 PM, wrote: From: Manoj Iyer USB 3.0 devices show up as high-speed devices on powerup, after an s3 cycle they are correctly recognized as SuperSpeed. At powerup unconditionally switch the port to xHCI like we do when we resume from suspend. BugLink: http://bugs.launchpad.net/bugs/1000424 Signed-off-by: Manoj Iyer --- drivers/usb/host/xhci-pci.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 9bfd4ca11..5c8dbea 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -48,6 +48,14 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev) if (!pci_set_mwi(pdev)) xhci_dbg(xhci, "MWI active\n"); + /* +* USB SuperSpeed ports are recognized as HighSpeed ports on powerup +* unconditionally switch the ports to xHCI like we do when resume +* from suspend. +*/ + if (usb_is_intel_switchable_xhci(pdev)) + usb_enable_xhci_ports(pdev); + Strange. This should have been called during system power up, in quirk_usb_handoff_xhci() of pci_quirks.c. Do you see that routine get called during power up? Thanks, Andiry xhci_dbg(xhci, "Finished xhci_pci_reinit\n"); return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Manoj Iyer Ubuntu/Canonical Hardware Enablement -- Manoj Iyer Ubuntu/Canonical Hardware Enablement -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] xhci: Unconditionally switch ports to xHCI on powerup
If this is a must-to-do thing for Intel Panther Point platform, then we need to make sure it's called on power up and resume. Yes, I think moving the code below hc_init label should work and I think it's a better solution than your original patch. Yes it effects a lot of machines (Lenovo), I will send out a new seperate patch with the fix. Thanks Manoj Thanks, Andiry On Tue, 21 Aug 2012, Andiry Xu wrote: On Tue, Aug 21, 2012 at 12:06 PM, manoj.i...@canonical.com wrote: From: Manoj Iyer manoj.i...@canonical.com USB 3.0 devices show up as high-speed devices on powerup, after an s3 cycle they are correctly recognized as SuperSpeed. At powerup unconditionally switch the port to xHCI like we do when we resume from suspend. BugLink: http://bugs.launchpad.net/bugs/1000424 Signed-off-by: Manoj Iyer manoj.i...@canonical.com --- drivers/usb/host/xhci-pci.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 9bfd4ca11..5c8dbea 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -48,6 +48,14 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev) if (!pci_set_mwi(pdev)) xhci_dbg(xhci, MWI active\n); + /* +* USB SuperSpeed ports are recognized as HighSpeed ports on powerup +* unconditionally switch the ports to xHCI like we do when resume +* from suspend. +*/ + if (usb_is_intel_switchable_xhci(pdev)) + usb_enable_xhci_ports(pdev); + Strange. This should have been called during system power up, in quirk_usb_handoff_xhci() of pci_quirks.c. Do you see that routine get called during power up? Thanks, Andiry xhci_dbg(xhci, Finished xhci_pci_reinit\n); return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Manoj Iyer Ubuntu/Canonical Hardware Enablement -- Manoj Iyer Ubuntu/Canonical Hardware Enablement -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] xhci: Recognize USB 3.0 devices as superspeed at powerup
From: Manoj Iyer manoj.i...@canonical.com On Intel Panther Point chipset USB 3.0 devices show up as high-speed devices on powerup, but after an s3 cycle they are correctly recognized as SuperSpeed. At powerup switch the port to xHCI so that USB 3.0 devices are correctly recognized. This is a second attempt at fixing this based on review comments to my earlier patch from Andiry Xu BugLink: http://bugs.launchpad.net/bugs/1000424 Test results after applying patch == USB 3.0 device connected to SuperSpeed port [ 34.694033] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd [ 34.712925] scsi6 : usb-storage 4-1:1.0 [ 35.709947] scsi 6:0:0:0: Direct-Access JetFlash Transcend 16GB 1.00 PQ: 0 ANSI: 5 [ 35.710886] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 35.711475] sd 6:0:0:0: [sdc] 30871552 512-byte logical blocks: (15.8 GB/14.7 GiB) [ 35.712721] sd 6:0:0:0: [sdc] Write Protect is off [ 35.712725] sd 6:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 35.712841] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 35.714627] sdc: sdc1 USB 3.0 device connected to highspeed port --- [ 148.128616] usb 1-1.2: new high-speed USB device number 5 using ehci_hcd [ 148.226040] scsi7 : usb-storage 1-1.2:1.0 [ 149.225645] scsi 7:0:0:0: Direct-Access JetFlash Transcend 16GB 1.00 PQ: 0 ANSI: 5 [ 149.227690] sd 7:0:0:0: Attached scsi generic sg3 type 0 [ 149.230196] sd 7:0:0:0: [sdc] 30871552 512-byte logical blocks: (15.8 GB/14.7 GiB) [ 149.230555] sd 7:0:0:0: [sdc] Write Protect is off [ 149.230563] sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 149.231333] sd 7:0:0:0: [sdc] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 149.235822] sdc: sdc1 [ 149.238035] sd 7:0:0:0: [sdc] Attached SCSI removable disk Manoj Iyer (1): xhci: Recognize USB 3.0 devices as superspeed at powerup drivers/usb/host/pci-quirks.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] xhci: Recognize USB 3.0 devices as superspeed at powerup
From: Manoj Iyer manoj.i...@canonical.com On Intel Panther Point chipset USB 3.0 devices show up as high-speed devices on powerup, but after an s3 cycle they are correctly recognized as SuperSpeed. At powerup switch the port to xHCI so that USB 3.0 devices are correctly recognized. BugLink: http://bugs.launchpad.net/bugs/1000424 Signed-off-by: Manoj Iyer manoj.i...@canonical.com --- drivers/usb/host/pci-quirks.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c index c5e9e4a..486e812 100644 --- a/drivers/usb/host/pci-quirks.c +++ b/drivers/usb/host/pci-quirks.c @@ -870,9 +870,10 @@ static void __devinit quirk_usb_handoff_xhci(struct pci_dev *pdev) /* Disable any BIOS SMIs and clear all SMI events*/ writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET); +hc_init: if (usb_is_intel_switchable_xhci(pdev)) usb_enable_xhci_ports(pdev); -hc_init: + op_reg_base = base + XHCI_HC_LENGTH(readl(base)); /* Wait for the host controller to be ready before writing any -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] xhci: Unconditionally switch ports to xHCI on powerup
Looks like in pci-quirks.c, we enter the do() while() loop, reach the end of extended capabilities and goto hc_init: label, skipping the switch. Probably moving the switch under the hc_init label might work? Currently we switch unconditionally on resume, so we could do the same at powerup as well. On Tue, 21 Aug 2012, Andiry Xu wrote: On Tue, Aug 21, 2012 at 12:06 PM, wrote: From: Manoj Iyer USB 3.0 devices show up as high-speed devices on powerup, after an s3 cycle they are correctly recognized as SuperSpeed. At powerup unconditionally switch the port to xHCI like we do when we resume from suspend. BugLink: http://bugs.launchpad.net/bugs/1000424 Signed-off-by: Manoj Iyer --- drivers/usb/host/xhci-pci.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 9bfd4ca11..5c8dbea 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -48,6 +48,14 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev) if (!pci_set_mwi(pdev)) xhci_dbg(xhci, "MWI active\n"); + /* +* USB SuperSpeed ports are recognized as HighSpeed ports on powerup +* unconditionally switch the ports to xHCI like we do when resume +* from suspend. +*/ + if (usb_is_intel_switchable_xhci(pdev)) + usb_enable_xhci_ports(pdev); + Strange. This should have been called during system power up, in quirk_usb_handoff_xhci() of pci_quirks.c. Do you see that routine get called during power up? Thanks, Andiry xhci_dbg(xhci, "Finished xhci_pci_reinit\n"); return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Manoj Iyer Ubuntu/Canonical Hardware Enablement -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] xhci: Unconditionally switch ports to xHCI on powerup
Looks like in pci-quirks.c, we enter the do() while() loop, reach the end of extended capabilities and goto hc_init: label, skipping the switch. Probably moving the switch under the hc_init label might work? Currently we switch unconditionally on resume, so we could do the same at powerup as well. On Tue, 21 Aug 2012, Andiry Xu wrote: On Tue, Aug 21, 2012 at 12:06 PM, manoj.i...@canonical.com wrote: From: Manoj Iyer manoj.i...@canonical.com USB 3.0 devices show up as high-speed devices on powerup, after an s3 cycle they are correctly recognized as SuperSpeed. At powerup unconditionally switch the port to xHCI like we do when we resume from suspend. BugLink: http://bugs.launchpad.net/bugs/1000424 Signed-off-by: Manoj Iyer manoj.i...@canonical.com --- drivers/usb/host/xhci-pci.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 9bfd4ca11..5c8dbea 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -48,6 +48,14 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev) if (!pci_set_mwi(pdev)) xhci_dbg(xhci, MWI active\n); + /* +* USB SuperSpeed ports are recognized as HighSpeed ports on powerup +* unconditionally switch the ports to xHCI like we do when resume +* from suspend. +*/ + if (usb_is_intel_switchable_xhci(pdev)) + usb_enable_xhci_ports(pdev); + Strange. This should have been called during system power up, in quirk_usb_handoff_xhci() of pci_quirks.c. Do you see that routine get called during power up? Thanks, Andiry xhci_dbg(xhci, Finished xhci_pci_reinit\n); return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Manoj Iyer Ubuntu/Canonical Hardware Enablement -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] xhci: Unconditionally switch ports to xHCI on powerup
From: Manoj Iyer USB 3.0 devices show up as high-speed devices on powerup, after an s3 cycle they are correctly recognized as SuperSpeed. At powerup unconditionally switch the port to xHCI like we do when we resume from suspend. BugLink: http://bugs.launchpad.net/bugs/1000424 Signed-off-by: Manoj Iyer --- drivers/usb/host/xhci-pci.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 9bfd4ca11..5c8dbea 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -48,6 +48,14 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev) if (!pci_set_mwi(pdev)) xhci_dbg(xhci, "MWI active\n"); + /* +* USB SuperSpeed ports are recognized as HighSpeed ports on powerup +* unconditionally switch the ports to xHCI like we do when resume +* from suspend. +*/ + if (usb_is_intel_switchable_xhci(pdev)) + usb_enable_xhci_ports(pdev); + xhci_dbg(xhci, "Finished xhci_pci_reinit\n"); return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] xhci: Unconditionally switch ports to xHCI on powerup
From: Manoj Iyer USB 3.0 devices show up as high-speed devices on powerup, after an s3 cycle they are correctly recognized as SuperSpeed. At powerup unconditionally switch the port to xHCI like we do when we resume from suspend. BugLink: http://bugs.launchpad.net/bugs/1000424 Test results: This patch was tested by me on a Lenovo system: 00:14.0 USB controller [0c03]: Intel Corporation Panther Point USB xHCI Host Con troller [8086:1e31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Lenovo Device [17aa:5002] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] xhci: Unconditionally switch ports to xHCI on powerup
From: Manoj Iyer manoj.i...@canonical.com USB 3.0 devices show up as high-speed devices on powerup, after an s3 cycle they are correctly recognized as SuperSpeed. At powerup unconditionally switch the port to xHCI like we do when we resume from suspend. BugLink: http://bugs.launchpad.net/bugs/1000424 Test results: This patch was tested by me on a Lenovo system: 00:14.0 USB controller [0c03]: Intel Corporation Panther Point USB xHCI Host Con troller [8086:1e31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Lenovo Device [17aa:5002] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 41 Region 0: Memory at 9060 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3h ot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Address: fee0300c Data: 4169 Kernel driver in use: xhci_hcd == BEFORE PATCH == [ 25.982350] eth1: no IPv6 routers present [ 27.577663] usb 2-1.1: new high-speed USB device number 3 using ehci_hcd [ 27.674465] scsi6 : usb-storage 2-1.1:1.0 [ 28.673788] scsi 6:0:0:0: Direct-Access JetFlash Transcend 16GB 1.00 PQ: 0 ANSI: 5 [ 28.674667] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 28.677284] sd 6:0:0:0: [sdc] 30871552 512-byte logical blocks: (15.8 GB/14.7 GiB) [ 28.677832] sd 6:0:0:0: [sdc] Write Protect is off [ 28.677839] sd 6:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 28.678454] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 28.682117] sdc: sdc1 [ 28.684179] sd 6:0:0:0: [sdc] Attached SCSI removable disk == AFTER PATCH USB 3.0 PORT == [ 56.653501] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd [ 56.672677] scsi6 : usb-storage 4-1:1.0 [ 57.669912] scsi 6:0:0:0: Direct-Access JetFlash Transcend 16GB 1.00 PQ: 0 ANSI: 5 [ 57.671100] sd 6:0:0:0: [sdc] 30871552 512-byte logical blocks: (15.8 GB/14.7 GiB) [ 57.671185] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 57.671389] sd 6:0:0:0: [sdc] Write Protect is off [ 57.671392] sd 6:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 57.671499] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 57.674480] sdc: sdc1 [ 57.675180] sd 6:0:0:0: [sdc] Attached SCSI removable disk == AFTER PATCH USB 2.0 PORT == [ 112.468810] usb 4-1: USB disconnect, device number 2 [ 117.688925] usb 1-1.2: new high-speed USB device number 5 using ehci_hcd [ 117.786131] scsi7 : usb-storage 1-1.2:1.0 [ 118.785809] scsi 7:0:0:0: Direct-Access JetFlash Transcend 16GB 1.00 PQ: 0 ANSI: 5 [ 118.788004] sd 7:0:0:0: Attached scsi generic sg3 type 0 [ 118.789848] sd 7:0:0:0: [sdc] 30871552 512-byte logical blocks: (15.8 GB/14.7 GiB) [ 118.790287] sd 7:0:0:0: [sdc] Write Protect is off [ 118.790294] sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 118.791072] sd 7:0:0:0: [sdc] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 118.796448] sdc: sdc1 [ 118.798525] sd 7:0:0:0: [sdc] Attached SCSI removable disk Manoj Iyer (1): xhci: Unconditionally switch ports to xHCI on powerup drivers/usb/host/xhci-pci.c |8 1 file changed, 8 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] xhci: Unconditionally switch ports to xHCI on powerup
From: Manoj Iyer manoj.i...@canonical.com USB 3.0 devices show up as high-speed devices on powerup, after an s3 cycle they are correctly recognized as SuperSpeed. At powerup unconditionally switch the port to xHCI like we do when we resume from suspend. BugLink: http://bugs.launchpad.net/bugs/1000424 Signed-off-by: Manoj Iyer manoj.i...@canonical.com --- drivers/usb/host/xhci-pci.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 9bfd4ca11..5c8dbea 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -48,6 +48,14 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev) if (!pci_set_mwi(pdev)) xhci_dbg(xhci, MWI active\n); + /* +* USB SuperSpeed ports are recognized as HighSpeed ports on powerup +* unconditionally switch the ports to xHCI like we do when resume +* from suspend. +*/ + if (usb_is_intel_switchable_xhci(pdev)) + usb_enable_xhci_ports(pdev); + xhci_dbg(xhci, Finished xhci_pci_reinit\n); return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Test on V490u
=
== After the patch ==
[ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/
[ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown
[ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX
[ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled
[ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in
laptop mode
[ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is
unblocked
[ 1350.307082] Registered led device: tpacpi::thinklight
[ 1350.307215] Registered led device: tpacpi::power
[ 1350.307255] Registered led device: tpacpi::standby
[ 1350.307294] Registered led device: tpacpi::thinkvantage
[ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not
loading native one
[ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor
(read only)
[ 1350.312287] input: ThinkPad Extra Buttons as
/devices/platform/thinkpad_acpi/input/input14
== Before the patch ==
sudo modprobe thinkpad_acpi
FATAL: Error inserting thinkpad_acpi
(/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko):
No such device
Test on B485
=
This patch was also test in a B485 where the thinkpad_acpi module does not
have any issues loading. But, I tested it to make sure this patch does not
break on already functioning models of Lenovo products.
[13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/
[13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown
[13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01
[13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is
unblocked
[13486.752883] Registered led device: tpacpi::thinklight
[13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not
loading native one
[13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor
(read only)
[13486.757147] input: ThinkPad Extra Buttons as
/devices/platform/thinkpad_acpi/input/input15
Signed-off-by: Manoj Iyer
---
drivers/platform/x86/thinkpad_acpi.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..d05c0a4 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8662,7 +8662,14 @@ static int __must_check __init get_thinkpad_model_data(
tp->model_str = kstrdup(s, GFP_KERNEL);
if (!tp->model_str)
return -ENOMEM;
- }
+ } else {
+ s = dmi_get_system_info(DMI_BIOS_VENDOR);
+ if (s && !(strnicmp(s, "Lenovo", 6))) {
+ tp->model_str = kstrdup(s, GFP_KERNEL);
+ if (!tp->model_str)
+ return -ENOMEM;
+ }
+ }
s = dmi_get_system_info(DMI_PRODUCT_NAME);
tp->nummodel_str = kstrdup(s, GFP_KERNEL);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Signed-off-by: Manoj Iyer
---
drivers/platform/x86/thinkpad_acpi.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..66dfdef 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8663,6 +8663,14 @@ static int __must_check __init get_thinkpad_model_data(
if (!tp->model_str)
return -ENOMEM;
}
+ else {
+ s = dmi_get_system_info(DMI_BIOS_VENDOR);
+ if (s && !(strnicmp(s, "Lenovo", 6))) {
+ tp->model_str = kstrdup(s, GFP_KERNEL);
+ if (!tp->model_str)
+ return -ENOMEM;
+ }
+ }
s = dmi_get_system_info(DMI_PRODUCT_NAME);
tp->nummodel_str = kstrdup(s, GFP_KERNEL);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Signed-off-by: Manoj Iyer
---
drivers/platform/x86/thinkpad_acpi.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..17692c8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8658,11 +8658,16 @@ static int __must_check __init get_thinkpad_model_data(
}
s = dmi_get_system_info(DMI_PRODUCT_VERSION);
- if (s && !(strnicmp(s, "ThinkPad", 8) && strnicmp(s, "Lenovo", 6))) {
+ if (s && !(strnicmp(s, "ThinkPad", 8) && strnicmp(s, "Lenovo", 6)))
tp->model_str = kstrdup(s, GFP_KERNEL);
- if (!tp->model_str)
- return -ENOMEM;
- }
+ else {
+ s = dmi_get_system_info(DMI_BIOS_VENDOR);
+ if (s && !(strnicmp(s, "Lenovo", 6)))
+ tp->model_str = kstrdup(s, GFP_KERNEL);
+ }
+
+ if (!tp->model_str)
+ return -ENOMEM;
s = dmi_get_system_info(DMI_PRODUCT_NAME);
tp->nummodel_str = kstrdup(s, GFP_KERNEL);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using
From: Manoj Iyer Please consider this patch to thinkapd_acpi, it loads the module on V-series systems that do not report with "Lenovo" or "ThinkPad" prefix to DMI_PRODUCT_VERSION query, but only returns model name. = Test on V490u = == After the patch == [ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown [ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX [ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled [ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode [ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 1350.307082] Registered led device: tpacpi::thinklight [ 1350.307215] Registered led device: tpacpi::power [ 1350.307255] Registered led device: tpacpi::standby [ 1350.307294] Registered led device: tpacpi::thinkvantage [ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14 == Before the patch == sudo modprobe thinkpad_acpi FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device = Test on B485 = This patch was also test in a B485 where the thinkpad_acpi module does not have any issues loading. But, I tested it to make sure this patch does not break on already functioning models of Lenovo products. [13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/ [13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown [13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01 [13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [13486.752883] Registered led device: tpacpi::thinklight [13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15 Manoj Iyer (1): thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR drivers/platform/x86/thinkpad_acpi.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using
From: Manoj Iyer manoj.i...@canonical.com Please consider this patch to thinkapd_acpi, it loads the module on V-series systems that do not report with Lenovo or ThinkPad prefix to DMI_PRODUCT_VERSION query, but only returns model name. = Test on V490u = == After the patch == [ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown [ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX [ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled [ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode [ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 1350.307082] Registered led device: tpacpi::thinklight [ 1350.307215] Registered led device: tpacpi::power [ 1350.307255] Registered led device: tpacpi::standby [ 1350.307294] Registered led device: tpacpi::thinkvantage [ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14 == Before the patch == sudo modprobe thinkpad_acpi FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device = Test on B485 = This patch was also test in a B485 where the thinkpad_acpi module does not have any issues loading. But, I tested it to make sure this patch does not break on already functioning models of Lenovo products. [13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/ [13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown [13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01 [13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [13486.752883] Registered led device: tpacpi::thinklight [13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15 Manoj Iyer (1): thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR drivers/platform/x86/thinkpad_acpi.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer manoj.i...@canonical.com
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Signed-off-by: Manoj Iyer manoj.i...@canonical.com
---
drivers/platform/x86/thinkpad_acpi.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..17692c8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8658,11 +8658,16 @@ static int __must_check __init get_thinkpad_model_data(
}
s = dmi_get_system_info(DMI_PRODUCT_VERSION);
- if (s !(strnicmp(s, ThinkPad, 8) strnicmp(s, Lenovo, 6))) {
+ if (s !(strnicmp(s, ThinkPad, 8) strnicmp(s, Lenovo, 6)))
tp-model_str = kstrdup(s, GFP_KERNEL);
- if (!tp-model_str)
- return -ENOMEM;
- }
+ else {
+ s = dmi_get_system_info(DMI_BIOS_VENDOR);
+ if (s !(strnicmp(s, Lenovo, 6)))
+ tp-model_str = kstrdup(s, GFP_KERNEL);
+ }
+
+ if (!tp-model_str)
+ return -ENOMEM;
s = dmi_get_system_info(DMI_PRODUCT_NAME);
tp-nummodel_str = kstrdup(s, GFP_KERNEL);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer manoj.i...@canonical.com
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Signed-off-by: Manoj Iyer manoj.i...@canonical.com
---
drivers/platform/x86/thinkpad_acpi.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..66dfdef 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8663,6 +8663,14 @@ static int __must_check __init get_thinkpad_model_data(
if (!tp-model_str)
return -ENOMEM;
}
+ else {
+ s = dmi_get_system_info(DMI_BIOS_VENDOR);
+ if (s !(strnicmp(s, Lenovo, 6))) {
+ tp-model_str = kstrdup(s, GFP_KERNEL);
+ if (!tp-model_str)
+ return -ENOMEM;
+ }
+ }
s = dmi_get_system_info(DMI_PRODUCT_NAME);
tp-nummodel_str = kstrdup(s, GFP_KERNEL);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer manoj.i...@canonical.com
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Test on V490u
=
== After the patch ==
[ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/
[ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown
[ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX
[ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled
[ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in
laptop mode
[ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is
unblocked
[ 1350.307082] Registered led device: tpacpi::thinklight
[ 1350.307215] Registered led device: tpacpi::power
[ 1350.307255] Registered led device: tpacpi::standby
[ 1350.307294] Registered led device: tpacpi::thinkvantage
[ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not
loading native one
[ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor
(read only)
[ 1350.312287] input: ThinkPad Extra Buttons as
/devices/platform/thinkpad_acpi/input/input14
== Before the patch ==
sudo modprobe thinkpad_acpi
FATAL: Error inserting thinkpad_acpi
(/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko):
No such device
Test on B485
=
This patch was also test in a B485 where the thinkpad_acpi module does not
have any issues loading. But, I tested it to make sure this patch does not
break on already functioning models of Lenovo products.
[13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/
[13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown
[13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01
[13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is
unblocked
[13486.752883] Registered led device: tpacpi::thinklight
[13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not
loading native one
[13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor
(read only)
[13486.757147] input: ThinkPad Extra Buttons as
/devices/platform/thinkpad_acpi/input/input15
Signed-off-by: Manoj Iyer manoj.i...@canonical.com
---
drivers/platform/x86/thinkpad_acpi.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..d05c0a4 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8662,7 +8662,14 @@ static int __must_check __init get_thinkpad_model_data(
tp-model_str = kstrdup(s, GFP_KERNEL);
if (!tp-model_str)
return -ENOMEM;
- }
+ } else {
+ s = dmi_get_system_info(DMI_BIOS_VENDOR);
+ if (s !(strnicmp(s, Lenovo, 6))) {
+ tp-model_str = kstrdup(s, GFP_KERNEL);
+ if (!tp-model_str)
+ return -ENOMEM;
+ }
+ }
s = dmi_get_system_info(DMI_PRODUCT_NAME);
tp-nummodel_str = kstrdup(s, GFP_KERNEL);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
Oops! This is embarrassing! my logic is flawed. Please ignore this patch,
I will resend it
NACK
On Thu, 2 Aug 2012, manoj.i...@canonical.com wrote:
From: Manoj Iyer
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Signed-off-by: Manoj Iyer
---
drivers/platform/x86/thinkpad_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..eec0b65 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8657,7 +8657,8 @@ static int __must_check __init get_thinkpad_model_data(
}
}
- s = dmi_get_system_info(DMI_PRODUCT_VERSION);
+ s = dmi_get_system_info(DMI_PRODUCT_VERSION) ?
+ dmi_get_system_info(DMI_BIOS_VENDOR) : NULL;
if (s && !(strnicmp(s, "ThinkPad", 8) && strnicmp(s, "Lenovo", 6))) {
tp->model_str = kstrdup(s, GFP_KERNEL);
if (!tp->model_str)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Manoj Iyer
Ubuntu/Canonical
Hardware Enablement
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Signed-off-by: Manoj Iyer
---
drivers/platform/x86/thinkpad_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..eec0b65 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8657,7 +8657,8 @@ static int __must_check __init get_thinkpad_model_data(
}
}
- s = dmi_get_system_info(DMI_PRODUCT_VERSION);
+ s = dmi_get_system_info(DMI_PRODUCT_VERSION) ?
+ dmi_get_system_info(DMI_BIOS_VENDOR) : NULL;
if (s && !(strnicmp(s, "ThinkPad", 8) && strnicmp(s, "Lenovo", 6))) {
tp->model_str = kstrdup(s, GFP_KERNEL);
if (!tp->model_str)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer In the latest V-series bios DMI_PRODUCT_VERSION does not contain the string Lenovo or Thinkpad, but is set to the model number, this causes the thinkpad_acpi module to fail to load. Recognize laptop as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo. BIOS Information Vendor: LENOVO Version: H7ET21WW (1.00 ) System Information Manufacturer: LENOVO Product Name: LV5DXXX Version: V490u This was tested by me on the Lenovo V490u Manoj Iyer (1): thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR drivers/platform/x86/thinkpad_acpi.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer manoj.i...@canonical.com In the latest V-series bios DMI_PRODUCT_VERSION does not contain the string Lenovo or Thinkpad, but is set to the model number, this causes the thinkpad_acpi module to fail to load. Recognize laptop as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo. BIOS Information Vendor: LENOVO Version: H7ET21WW (1.00 ) System Information Manufacturer: LENOVO Product Name: LV5DXXX Version: V490u This was tested by me on the Lenovo V490u Manoj Iyer (1): thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR drivers/platform/x86/thinkpad_acpi.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
From: Manoj Iyer manoj.i...@canonical.com
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Signed-off-by: Manoj Iyer manoj.i...@canonical.com
---
drivers/platform/x86/thinkpad_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..eec0b65 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8657,7 +8657,8 @@ static int __must_check __init get_thinkpad_model_data(
}
}
- s = dmi_get_system_info(DMI_PRODUCT_VERSION);
+ s = dmi_get_system_info(DMI_PRODUCT_VERSION) ?
+ dmi_get_system_info(DMI_BIOS_VENDOR) : NULL;
if (s !(strnicmp(s, ThinkPad, 8) strnicmp(s, Lenovo, 6))) {
tp-model_str = kstrdup(s, GFP_KERNEL);
if (!tp-model_str)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
Oops! This is embarrassing! my logic is flawed. Please ignore this patch,
I will resend it
NACK
On Thu, 2 Aug 2012, manoj.i...@canonical.com wrote:
From: Manoj Iyer manoj.i...@canonical.com
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Signed-off-by: Manoj Iyer manoj.i...@canonical.com
---
drivers/platform/x86/thinkpad_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index e7f7328..eec0b65 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -8657,7 +8657,8 @@ static int __must_check __init get_thinkpad_model_data(
}
}
- s = dmi_get_system_info(DMI_PRODUCT_VERSION);
+ s = dmi_get_system_info(DMI_PRODUCT_VERSION) ?
+ dmi_get_system_info(DMI_BIOS_VENDOR) : NULL;
if (s !(strnicmp(s, ThinkPad, 8) strnicmp(s, Lenovo, 6))) {
tp-model_str = kstrdup(s, GFP_KERNEL);
if (!tp-model_str)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Manoj Iyer
Ubuntu/Canonical
Hardware Enablement
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0
From: Manoj Iyer
Patch adds support for BCM20702A0 device id (0a5c:21f4).
usb-devices after patch was applied:
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=21f4 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=E4D53DF154D6
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
usb-devices before patch was applied:
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=21f4 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=E4D53DF154D6
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Manoj Iyer
Tested-by: Chris Gagnon
---
drivers/bluetooth/btusb.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 83ebb24..1ecb8e5 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -106,6 +106,7 @@ static struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x0a5c, 0x21e6) },
{ USB_DEVICE(0x0a5c, 0x21e8) },
{ USB_DEVICE(0x0a5c, 0x21f3) },
+ { USB_DEVICE(0x0a5c, 0x21f4) },
{ USB_DEVICE(0x413c, 0x8197) },
/* Foxconn - Hon Hai */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0
From: Manoj Iyer manoj.i...@canonical.com
Patch adds support for BCM20702A0 device id (0a5c:21f4).
usb-devices after patch was applied:
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=21f4 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=E4D53DF154D6
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
usb-devices before patch was applied:
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=21f4 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=E4D53DF154D6
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Manoj Iyer manoj.i...@canonical.com
Tested-by: Chris Gagnon chris.gag...@canonical.com
---
drivers/bluetooth/btusb.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 83ebb24..1ecb8e5 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -106,6 +106,7 @@ static struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x0a5c, 0x21e6) },
{ USB_DEVICE(0x0a5c, 0x21e8) },
{ USB_DEVICE(0x0a5c, 0x21f3) },
+ { USB_DEVICE(0x0a5c, 0x21f4) },
{ USB_DEVICE(0x413c, 0x8197) },
/* Foxconn - Hon Hai */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0
On Fri, 13 Apr 2012, Gustavo Padovan wrote: Gustavo, Sorry it took a long time to locate the hardware to get this info, I got this info from one our QA engg cced here. Do you want me to resubmit the patch ? Before the patch = T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f4 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=E4D53DF154D6 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) After the patch T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f4 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=E4D53DF154D6 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Hi Manoj, * Manoj Iyer [2012-04-11 13:39:23 -0500]: usb-devices: T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f4 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=E4D53DF15584 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) You need to give the usb-devices for the non-working case. I know it works but we need to document this right in the commit message. Gustavo -- Manoj Iyer Ubuntu/Canonical Hardware Enablement -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0
On Fri, 13 Apr 2012, Gustavo Padovan wrote: Gustavo, Sorry it took a long time to locate the hardware to get this info, I got this info from one our QA engg cced here. Do you want me to resubmit the patch ? Before the patch = T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f4 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=E4D53DF154D6 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) After the patch T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f4 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=E4D53DF154D6 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Hi Manoj, * Manoj Iyer manoj.i...@canonical.com [2012-04-11 13:39:23 -0500]: usb-devices: T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f4 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=E4D53DF15584 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) You need to give the usb-devices for the non-working case. I know it works but we need to document this right in the commit message. Gustavo -- Manoj Iyer Ubuntu/Canonical Hardware Enablement -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
Linus Torvalds wrote: On Fri, 27 Apr 2007, Andreas Dilger wrote: It's true that this is a "feature" of ext3 with data=ordered (the default), but I suspect the same thing is now true in reiserfs too. Oh, well.. Journalling sucks. Go back to ext2? ;) I was actually _really_ hoping that somebody would come along and tell everybody that this whole journal-logging is stupid, and that it's just better to not ever re-write blocks on disk, but instead write to new blocks with version numbers (and not re-use old blocks until new versions are stable on disk). Ah, "copy on write"! ZFS (Sun) and WAFL (NetApp) does this. Don't know about WAFL, but ZFS does logging too. -Manoj -- Manoj Joseph http://kerneljunkie.blogspot.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
Marat Buharov wrote: On 4/27/07, Andrew Morton <[EMAIL PROTECTED]> wrote: Aside: why the heck do applications think that their data is so important that they need to fsync it all the time. I used to run a kernel on my laptop which had "return 0;" at the top of fsync() and fdatasync(). Most pleasurable. So, if having fake fsync() and fdatasync() is pleasurable for laptop and desktop, may be it's time to add option into Kconfig which disables normal fsync behaviour in favor of robust desktop? Sure, a noop fsync/fdatasync would speed up some things. And I am sure Andrew Morton knew what he was doing and the consequences. But unless you care nothing about your data, you should not do it. It is as simple as that. No, it does not give you a robust desktop!! -Manoj -- Manoj Joseph http://kerneljunkie.blogspot.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ext3][kernels = 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
Marat Buharov wrote: On 4/27/07, Andrew Morton [EMAIL PROTECTED] wrote: Aside: why the heck do applications think that their data is so important that they need to fsync it all the time. I used to run a kernel on my laptop which had return 0; at the top of fsync() and fdatasync(). Most pleasurable. So, if having fake fsync() and fdatasync() is pleasurable for laptop and desktop, may be it's time to add option into Kconfig which disables normal fsync behaviour in favor of robust desktop? Sure, a noop fsync/fdatasync would speed up some things. And I am sure Andrew Morton knew what he was doing and the consequences. But unless you care nothing about your data, you should not do it. It is as simple as that. No, it does not give you a robust desktop!! -Manoj -- Manoj Joseph http://kerneljunkie.blogspot.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ext3][kernels = 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
Linus Torvalds wrote: On Fri, 27 Apr 2007, Andreas Dilger wrote: It's true that this is a feature of ext3 with data=ordered (the default), but I suspect the same thing is now true in reiserfs too. Oh, well.. Journalling sucks. Go back to ext2? ;) I was actually _really_ hoping that somebody would come along and tell everybody that this whole journal-logging is stupid, and that it's just better to not ever re-write blocks on disk, but instead write to new blocks with version numbers (and not re-use old blocks until new versions are stable on disk). Ah, copy on write! ZFS (Sun) and WAFL (NetApp) does this. Don't know about WAFL, but ZFS does logging too. -Manoj -- Manoj Joseph http://kerneljunkie.blogspot.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
Alan Cox wrote: Please do see: http://www.opensolaris.org/os/about/faq/licensing_faq/#patents Which appears to agree with everything I said not what you are claiming. The patent license is strictly tied to their implementation and its derivatives under the CDDL, so specifically acts to exclude Linux. I thought you said "incompatible with other OS products". I believe there are other OS products it is quite compatible with. The ports of ZFS seem to confirm this. That it is compatible with the Linux kernel was not what I was arguing. :) -Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
Alan Cox wrote: The real test of whether Sun were serious about ZFS being anywhere but Solaris is what they do to license it - they've patented everything they can, and made the code available only under licenses incompatible with other OS products. Their intent is quite clear, and quite sad. Please do see: http://www.opensolaris.org/os/about/faq/licensing_faq/#patents ZFS has been ported to some of those 'other OS products'. :) My two cents... -Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
Alan Cox wrote: The real test of whether Sun were serious about ZFS being anywhere but Solaris is what they do to license it - they've patented everything they can, and made the code available only under licenses incompatible with other OS products. Their intent is quite clear, and quite sad. Please do see: http://www.opensolaris.org/os/about/faq/licensing_faq/#patents ZFS has been ported to some of those 'other OS products'. :) My two cents... -Manoj - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
Alan Cox wrote: Please do see: http://www.opensolaris.org/os/about/faq/licensing_faq/#patents Which appears to agree with everything I said not what you are claiming. The patent license is strictly tied to their implementation and its derivatives under the CDDL, so specifically acts to exclude Linux. I thought you said incompatible with other OS products. I believe there are other OS products it is quite compatible with. The ports of ZFS seem to confirm this. That it is compatible with the Linux kernel was not what I was arguing. :) -Manoj - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.31 O_DIRECT support for ext3
On Tue, 9 Aug 2005, Arjan van de Ven wrote:
> On Tue, 2005-08-09 at 18:35 +0530, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > This is back-port of O_DIRECT support for ext3 from 2.6 to 2.4.31
> > kernel.
> >
> > Any suggestions/comments ?
>
> why?
>
> personally I think this is way out of scope for a 2.4.x release in this
> phase of 2.4's life.
>
> (also you wrapped your patch)
All other journal file systems in 2.4 have been supporting directIO and
there are multiple threads where people have been asking for it in ext3.
I needed it for one of my applications and sent it since it might be
useful for others as well.
(Resending the patch after getting the wrapping corrected)
Thanks.
--- linux-2.4-latest/fs/ext3/inode.c2005-08-08 11:46:52.0 +0530
+++ linux-2.4.31/fs/ext3/inode.c2005-08-09 14:59:16.0 +0530
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
/*
* SEARCH_FROM_ZERO forces each block allocation to search from the start
@@ -1388,6 +1389,68 @@
}
+#define DIO_CREDITS (EXT3_RESERVE_TRANS_BLOCKS + 32)
+
+static int ext3_direct_IO(int rw, struct inode * inode, struct kiobuf * iobuf,
unsigned long blocknr, int blocksize)
+{
+ ssize_t ret;
+ loff_t offset, final_size;
+ handle_t*handle = NULL;
+ int orphan = 0;
+ struct ext3_inode_info *ei = EXT3_I(inode);
+
+ offset = ((loff_t)blocknr) * blocksize;
+ final_size = offset + iobuf->length;
+
+ if (rw == WRITE) {
+
+ handle = ext3_journal_start(inode, DIO_CREDITS);
+ if (IS_ERR(handle)) {
+ ret = PTR_ERR(handle);
+ goto out;
+ }
+ if (final_size > inode->i_size) {
+ ret = ext3_orphan_add(handle, inode);
+ if (ret)
+ goto out_stop;
+ orphan = 1;
+ ei->i_disksize = inode->i_size;
+ }
+ }
+
+ ret = generic_direct_IO(rw, inode, iobuf, blocknr, blocksize,
ext3_get_block);
+
+ handle = journal_current_handle();
+
+out_stop:
+ if (handle) {
+ int err;
+
+ if (orphan && inode->i_nlink)
+ ext3_orphan_del(handle, inode);
+ if (orphan && ret > 0) {
+ loff_t end = offset + ret;
+ if (end > inode->i_size) {
+ ei->i_disksize = end;
+ inode->i_size = end;
+ /*
+ * We're going to return a positive `ret'
+ * here due to non-zero-length I/O, so there's
+ * no way of reporting error returns from
+ * ext3_mark_inode_dirty() to userspace. So
+ * ignore it.
+ */
+ ext3_mark_inode_dirty(handle, inode);
+ }
+ }
+ err = ext3_journal_stop(handle, inode);
+ if (ret == 0)
+ ret = err;
+ }
+out:
+ return ret;
+}
+
struct address_space_operations ext3_aops = {
readpage: ext3_readpage, /* BKL not held. Don't need */
writepage: ext3_writepage, /* BKL not held. We take it */
@@ -1397,6 +1460,7 @@
bmap: ext3_bmap, /* BKL held */
flushpage: ext3_flushpage, /* BKL not held. Don't need */
releasepage:ext3_releasepage, /* BKL not held. Don't need */
+ direct_IO: ext3_direct_IO,
};
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.31 O_DIRECT support for ext3
On Tue, 9 Aug 2005, Arjan van de Ven wrote:
On Tue, 2005-08-09 at 18:35 +0530, [EMAIL PROTECTED] wrote:
Hi,
This is back-port of O_DIRECT support for ext3 from 2.6 to 2.4.31
kernel.
Any suggestions/comments ?
why?
personally I think this is way out of scope for a 2.4.x release in this
phase of 2.4's life.
(also you wrapped your patch)
All other journal file systems in 2.4 have been supporting directIO and
there are multiple threads where people have been asking for it in ext3.
I needed it for one of my applications and sent it since it might be
useful for others as well.
(Resending the patch after getting the wrapping corrected)
Thanks.
--- linux-2.4-latest/fs/ext3/inode.c2005-08-08 11:46:52.0 +0530
+++ linux-2.4.31/fs/ext3/inode.c2005-08-09 14:59:16.0 +0530
@@ -31,6 +31,7 @@
#include linux/highuid.h
#include linux/quotaops.h
#include linux/module.h
+#include linux/iobuf.h
/*
* SEARCH_FROM_ZERO forces each block allocation to search from the start
@@ -1388,6 +1389,68 @@
}
+#define DIO_CREDITS (EXT3_RESERVE_TRANS_BLOCKS + 32)
+
+static int ext3_direct_IO(int rw, struct inode * inode, struct kiobuf * iobuf,
unsigned long blocknr, int blocksize)
+{
+ ssize_t ret;
+ loff_t offset, final_size;
+ handle_t*handle = NULL;
+ int orphan = 0;
+ struct ext3_inode_info *ei = EXT3_I(inode);
+
+ offset = ((loff_t)blocknr) * blocksize;
+ final_size = offset + iobuf-length;
+
+ if (rw == WRITE) {
+
+ handle = ext3_journal_start(inode, DIO_CREDITS);
+ if (IS_ERR(handle)) {
+ ret = PTR_ERR(handle);
+ goto out;
+ }
+ if (final_size inode-i_size) {
+ ret = ext3_orphan_add(handle, inode);
+ if (ret)
+ goto out_stop;
+ orphan = 1;
+ ei-i_disksize = inode-i_size;
+ }
+ }
+
+ ret = generic_direct_IO(rw, inode, iobuf, blocknr, blocksize,
ext3_get_block);
+
+ handle = journal_current_handle();
+
+out_stop:
+ if (handle) {
+ int err;
+
+ if (orphan inode-i_nlink)
+ ext3_orphan_del(handle, inode);
+ if (orphan ret 0) {
+ loff_t end = offset + ret;
+ if (end inode-i_size) {
+ ei-i_disksize = end;
+ inode-i_size = end;
+ /*
+ * We're going to return a positive `ret'
+ * here due to non-zero-length I/O, so there's
+ * no way of reporting error returns from
+ * ext3_mark_inode_dirty() to userspace. So
+ * ignore it.
+ */
+ ext3_mark_inode_dirty(handle, inode);
+ }
+ }
+ err = ext3_journal_stop(handle, inode);
+ if (ret == 0)
+ ret = err;
+ }
+out:
+ return ret;
+}
+
struct address_space_operations ext3_aops = {
readpage: ext3_readpage, /* BKL not held. Don't need */
writepage: ext3_writepage, /* BKL not held. We take it */
@@ -1397,6 +1460,7 @@
bmap: ext3_bmap, /* BKL held */
flushpage: ext3_flushpage, /* BKL not held. Don't need */
releasepage:ext3_releasepage, /* BKL not held. Don't need */
+ direct_IO: ext3_direct_IO,
};
/*
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Problem with DCE with Kernel Patch
Hello, While installing DCE 0.1.13 on RH Linux AS 2.1 Kernel 2.4.18-e.54smp running on Itanium, the system hangs and becomes unbootable. It then has to be started in single user mode, the dce rpm has to be removed and then booted. This happens with kernel patch 52/54. Has anyone faced a similar problem and resolved it ? . Any pointers in this regard will be really *nice*. Thanks in advance. -- Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with DCE with Kernel Patch
Hello, While installing DCE 0.1.13 on RH Linux AS 2.1 Kernel 2.4.18-e.54smp running on Itanium, the system hangs and becomes unbootable. It then has to be started in single user mode, the dce rpm has to be removed and then booted. This happens with kernel patch 52/54. Has anyone faced a similar problem and resolved it ? . Any pointers in this regard will be really *nice*. Thanks in advance. -- Manoj - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel panic with 2.4.3
Hi,
I am using 2.4.3 kernel and I am getting kernel panic.
It doesn't happen very regularly so may be difficult to simulate.
I connected my system to serial port and captured the log.
Please suggest a way so that I can track down the problem.
Will KGDB be of any help ?
Please reply to me directly as I am not on the linux-kernel mailing
list.
Thanks,
Manoj
([EMAIL PROTECTED])
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
EFLAGS: 0086
eax: ebx: cdfe4000 ecx: cdfe8db8 edx: c0101db8
esi: cdfe4000 edi: c0111654 ebp: cdfe5ba0 esp: cdfe5b90
ds: 0018 es: 0018 ss: 0018
Process test_hal (pid: 217, stackpage=cdfe5000)
Stack: cdfe4000 cdfe4000 c0111654 0046 cdfe5c58 c011192c c0111e54
cdfe4000
c0111654 c01072a4 cdfe5bc4 0002 0a78 cdfe4000
029e
db937034 40014588 cdfe5c08 ce280018 0018
c0214c0f
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] []
Code: 80 3d b0 56 27 c0 00 f3 90 7e f5 e9 2c a5 ef ff 80 3d 00 24
console shuts up ...
Program received signal SIGSEGV, Segmentation fault.
0xc0217900 in stext_lock () at af_packet.c:1864
1864 af_packet.c: No such file or directory.
begin 666 Wipro_Disclaimer.txt
M5($EN9F]R;6%T:6]N(&-O;G1A:6YE9"!A;F0@=')A;G-M:71T960@8GD@
M=6]U(&%R92!N;W1I9FEE9"!T:&%T(&%N
M>2!U2!W87D@;W(@:6X@86YY(FYE6]U(=F4@http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kernel panic with 2.4.3
Hi,
I am using 2.4.3 kernel and I am getting kernel panic.
It doesn't happen very regularly so may be difficult to simulate.
I connected my system to serial port and captured the log.
Please suggest a way so that I can track down the problem.
Will KGDB be of any help ?
Please reply to me directly as I am not on the linux-kernel mailing
list.
Thanks,
Manoj
([EMAIL PROTECTED])
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[c0217900]
EFLAGS: 0086
eax: ebx: cdfe4000 ecx: cdfe8db8 edx: c0101db8
esi: cdfe4000 edi: c0111654 ebp: cdfe5ba0 esp: cdfe5b90
ds: 0018 es: 0018 ss: 0018
Process test_hal (pid: 217, stackpage=cdfe5000)
Stack: cdfe4000 cdfe4000 c0111654 0046 cdfe5c58 c011192c c0111e54
cdfe4000
c0111654 c01072a4 cdfe5bc4 0002 0a78 cdfe4000
029e
db937034 40014588 cdfe5c08 ce280018 0018
c0214c0f
Call Trace: [c0111654] [c011192c] [c0111e54] [c0111654]
[c01072a4] [db937034] [c0214c0f]
[c01072a4] [c0214c0f] [c01072a4] [c0101db8] [db937000]
[c0111654] [c0111e54] [c0111654]
[c011192c] [db9165b4] [c0111654] [db9165b4] [c01daf08]
[c01072a4] [db9165b4] [db9165b4]
[c0108bb3] [db917408] [c0108db2] [c0107230] [c0112628]
[c01121f0] [db91a5a4] [c011211c]
[c0112b76] [d0905400] [db91a580] [db91a5a8] [db91a5a8]
[db91a1a0] [d0905400] [db91a4b7]
[db91a590] [db91a24b] [db91a580] [db937c0b] [c01310fa]
[c013102b] [c0140eec] [c014481e]
[db937088] [c010716f] [c014481e]
Code: 80 3d b0 56 27 c0 00 f3 90 7e f5 e9 2c a5 ef ff 80 3d 00 24
console shuts up ...
Program received signal SIGSEGV, Segmentation fault.
0xc0217900 in stext_lock () at af_packet.c:1864
1864 af_packet.c: No such file or directory.
begin 666 Wipro_Disclaimer.txt
M5AE($EN9F]R;6%T:6]N(-O;G1A:6YE9!A;F0@=')A;G-M:71T960@8GD@
M=AIR!%+4U!24P@:7,@')O')I971AGD@=\@E=I')O($QI;6ET960@
M86YD(ES(EN=5N95D(9OB @=7-E(]N;'D@8GD@=AE(EN9EV:61U
M86P@;W(@96YT:71Y('1O('=H:6-H( II=!IR!A91R97-S960L(%N9!M
M87D@8V]N=%I;B!I;F9OFUA=EO;B!T:%T(ES('!R:79I;5G960L(-O
M;F9I95N=EA;!OB *97AE;7!T(9R;VT@9ES8VQOW5R92!U;F1EB!A
M'!L:6-A8FQE(QA=RX@268@=AIR!IR!A(9OG=AF1E9!M97-S86=E
M+ *=AE(-O;G1E;G0@;V8@=AIR!%+4U!24P@;6%Y(YO=!H879E()E
M96X@V5N=!W:71H('1H92!A=71H;W)I='D@;V8@=AE( I#;VUP86YY+B!)
M9B!Y;W4@87)E(YO=!T:4@:6YT96YD960@F5C:7!I96YT+!A;B!A9V5N
M=!O9B!T:4@:6YT96YD960@G)E8VEP:65N=!OB!A(!P97)S;VX@F5S
M]NVEB;4@9F]R(1E;EV97)I;F@=AE(EN9F]R;6%T:6]N('1O('1H
M92!N86UE9 *F5C:7!I96YT+ @6]U(%R92!N;W1I9FEE9!T:%T(%N
M2!UV4L(1IW1R:6)U=EO;BP@=')A;G-M:7-S:6]N+!PFEN=EN9RP@
MF-O'EI;F@;W(@9ESV5M:6YA=EO;B!O9B!T:ES(EN9F]R;6%T:6]N
M(EN(%N2!W87D@;W(@:6X@86YY(UA;FYEB!IR *W1R:6-T;'D@')O
M:EB:71E9X@268@6]U(AA=F4@F5C96EV960@=AIR!C;VUM=6YI8V%T
M:6]N(EN(5RF]R+!P;5AV4@F1E;5T92!T:ES(UA:6P@)B!N;W1I
L9GD@=7,@:6UM961I871E;'D@870@;6%I;%D;6EN0'=I')O+F-O;2 *#0H
end
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Next hop and o/p i/f IP address
Hi list Sorry to bother you with such a trivial query. To make a routing decision ip_route_input() is called. It fills the skb->dst with appropriate entry. Can anyone point to the exact location where I can find the next hop and output interface IP address. It seems skb->dst->dev->ip_ptr->in_dev->ifa_list->ifa_address is o/p i/f ip address and skb->dst->neighbour->dev->ip_ptr->in_dev->ifa_list->ifa_address is next hop IP address Please correct me if I am wrong. Thanks for all the help. Manoj __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Next hop and o/p i/f IP address
Hi list Sorry to bother you with such a trivial query. To make a routing decision ip_route_input() is called. It fills the skb-dst with appropriate entry. Can anyone point to the exact location where I can find the next hop and output interface IP address. It seems skb-dst-dev-ip_ptr-in_dev-ifa_list-ifa_address is o/p i/f ip address and skb-dst-neighbour-dev-ip_ptr-in_dev-ifa_list-ifa_address is next hop IP address Please correct me if I am wrong. Thanks for all the help. Manoj __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: which gcc version?
hi On Thu, 5 Apr 2001, Alexander Viro wrote: > On Thu, 5 Apr 2001, Manoj Sontakke wrote: > > > Hi > > I am getting linker error "undefined reference to __divdi3". > > This is because c = a/b; where a,b,c are of type "long long" > > I understand this is gcc problem. > > I am doing this on a pentium with gcc -v = egcs-2.91.66 > > Don't do it in the kernel. It has nothing to gcc version. Addition and subtraction works fine. The problem is with multiplication and division. I am doing this to avoid floating point calculation and doing fixed point calculation. The rage is large enough to need "long long" Any other way to achieve this? thanks manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: which gcc version?
hi On Thu, 5 Apr 2001, Alexander Viro wrote: On Thu, 5 Apr 2001, Manoj Sontakke wrote: Hi I am getting linker error "undefined reference to __divdi3". This is because c = a/b; where a,b,c are of type "long long" I understand this is gcc problem. I am doing this on a pentium with gcc -v = egcs-2.91.66 Don't do it in the kernel. It has nothing to gcc version. Addition and subtraction works fine. The problem is with multiplication and division. I am doing this to avoid floating point calculation and doing fixed point calculation. The rage is large enough to need "long long" Any other way to achieve this? thanks manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
which gcc version?
Hi I am getting linker error "undefined reference to __divdi3". This is because c = a/b; where a,b,c are of type "long long" I understand this is gcc problem. I am doing this on a pentium with gcc -v = egcs-2.91.66 Thanks for all the help. Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
which gcc version?
Hi I am getting linker error "undefined reference to __divdi3". This is because c = a/b; where a,b,c are of type "long long" I understand this is gcc problem. I am doing this on a pentium with gcc -v = egcs-2.91.66 Thanks for all the help. Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Packet/frame generator
On Fri, 30 Mar 2001, Mircea Ciocan wrote: > Here is a nice packet building library: > > www.packetfactory.net/Projects/Libnet/ its broken. > > Can anyone tell me a good packet/frame generator for linux? > > thanks > > > > manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Packet/frame generator
Hi Can anyone tell me a good packet/frame generator for linux? thanks manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Packet/frame generator
Hi Can anyone tell me a good packet/frame generator for linux? thanks manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Packet/frame generator
On Fri, 30 Mar 2001, Mircea Ciocan wrote: Here is a nice packet building library: www.packetfactory.net/Projects/Libnet/ its broken. Can anyone tell me a good packet/frame generator for linux? thanks manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP layer bug?
Hi, On Mon, 26 Mar 2001, Oleg Drokin wrote: > Hello! > > On Mon, Mar 26, 2001 at 04:06:19PM +0530, Manoj Sontakke wrote: > > >2.4.x kernel. have not tried 2.2 > > >I just found somethig, I believe is kernel bug. > > >I am working with usbnet.c driver, which stores some of its > > >internal state in sk_buff.cb area. But once such skb passed to > > >upper layer with netif_rx, net/ipv4/ip_input.c reuses content of cb > > >(line #345), > > ip_options_compile() when called with first argument NULL resets cb to 0. > I have found that already. > > > This is probably because the cb is supposed to be used IP and above. The > Sure. > > > underlying layer(link and phy) could be anything so where from the > > ip_options should start will depend upon the underlying layer. > But here's the problem! > If I won't zero cb in my driver before netif_rx() call, > IP layer thinks that all my packets have various ip options set > (source routing most notable) U can set cb to zero, but u also plan to use cb for storing ur data. If that happens then u need to modify the way the macro IPCB (probably in net/ip.h) is defined. Also make sure to increase the size of cb to accomodate ur data. This will solve ur problem but making this general (part of the standard kernel code) needs a lot of work in the ip layer. The cb is also used by TCP. The same needs to be done in IP layer but this will again largly depend on the layers below and hence the complexity. The alternative to this is that u can add another buffer like cb in sk_buff. Manoj Sontakke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP layer bug?
Hi On Sun, 25 Mar 2001, Oleg Drokin wrote: > Hello! > >2.4.x kernel. have not tried 2.2 >I just found somethig, I believe is kernel bug. >I am working with usbnet.c driver, which stores some of its >internal state in sk_buff.cb area. But once such skb passed to >upper layer with netif_rx, net/ipv4/ip_input.c reuses content of cb >(line #345), ip_options_compile() when called with first argument NULL resets cb to 0. This is probably because the cb is supposed to be used IP and above. The underlying layer(link and phy) could be anything so where from the ip_options should start will depend upon the underlying layer. >and all packets that should go outside of beyond hosts >we have direct routes to, fails, because we think, they have source routing >enabled. >For now I workarounded it with filling skb->cb with zeroes before >netif_rx(), but I believe it is a kludge and networking layer should be fixed >instead. > >Thank you. > > Bye, > Oleg > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Regards, Manoj Sontakke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP layer bug?
Hi On Sun, 25 Mar 2001, Oleg Drokin wrote: Hello! 2.4.x kernel. have not tried 2.2 I just found somethig, I believe is kernel bug. I am working with usbnet.c driver, which stores some of its internal state in sk_buff.cb area. But once such skb passed to upper layer with netif_rx, net/ipv4/ip_input.c reuses content of cb (line #345), ip_options_compile() when called with first argument NULL resets cb to 0. This is probably because the cb is supposed to be used IP and above. The underlying layer(link and phy) could be anything so where from the ip_options should start will depend upon the underlying layer. and all packets that should go outside of beyond hosts we have direct routes to, fails, because we think, they have source routing enabled. For now I workarounded it with filling skb-cb with zeroes before netif_rx(), but I believe it is a kludge and networking layer should be fixed instead. Thank you. Bye, Oleg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Regards, Manoj Sontakke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP layer bug?
Hi, On Mon, 26 Mar 2001, Oleg Drokin wrote: Hello! On Mon, Mar 26, 2001 at 04:06:19PM +0530, Manoj Sontakke wrote: 2.4.x kernel. have not tried 2.2 I just found somethig, I believe is kernel bug. I am working with usbnet.c driver, which stores some of its internal state in sk_buff.cb area. But once such skb passed to upper layer with netif_rx, net/ipv4/ip_input.c reuses content of cb (line #345), ip_options_compile() when called with first argument NULL resets cb to 0. I have found that already. This is probably because the cb is supposed to be used IP and above. The Sure. underlying layer(link and phy) could be anything so where from the ip_options should start will depend upon the underlying layer. But here's the problem! If I won't zero cb in my driver before netif_rx() call, IP layer thinks that all my packets have various ip options set (source routing most notable) U can set cb to zero, but u also plan to use cb for storing ur data. If that happens then u need to modify the way the macro IPCB (probably in net/ip.h) is defined. Also make sure to increase the size of cb to accomodate ur data. This will solve ur problem but making this general (part of the standard kernel code) needs a lot of work in the ip layer. The cb is also used by TCP. The same needs to be done in IP layer but this will again largly depend on the layers below and hence the complexity. The alternative to this is that u can add another buffer like cb in sk_buff. Manoj Sontakke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fib entries
Hi I have a question related to forwarding information base(FIB). Depending upon destination IP address a packet can be a) for this machine b) for a machine to which this machine is directly connected c) for a machine to which this machine is not directly connected. Does FIB contain the entries for delivery for all the 3 cases or only for the third case Thanks in advance for all the help Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fib entries
Hi I have a question related to forwarding information base(FIB). Depending upon destination IP address a packet can be a) for this machine b) for a machine to which this machine is directly connected c) for a machine to which this machine is not directly connected. Does FIB contain the entries for delivery for all the 3 cases or only for the third case Thanks in advance for all the help Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: initialisation code
Hi Thanks for all the help. On Wed, 21 Mar 2001, Keith Owens wrote: > On Wed, 21 Mar 2001 22:00:51 +0530 (IST), > Manoj Sontakke <[EMAIL PROTECTED]> wrote: > > I have a initlisation function (just like pktsched_init in > >TC). Can anyone tell me, where in the kernel boot sequence should I make a > >call to my initialisation function. > > Welcome to the wonderful world of magic initialisation. > > (1) Declare your initialisation function as int __init foo_init(void). > > (2) Decide when your function needs to be called, e.g. after initialisers > for A, B, C but before initialisers for X, Y, Z. where do i find this ABC abs XYZ ? What if I have to make it as an insertable/removable module? > > (3) Edit the Makefile to insert obj-$(CONFIG_FOO) after the objects > that contain initialisers A, B, C and before the objects for > initialisers X, Y, Z. Do I need to edit the .config file to add CONFIG_FOO=y ? > > (4) Document why the order of this routine is required! Without docs > in the Makefile we have no idea if object order is correct or not. > of course manojs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
initialisation code
Hi I am trying to implement some QoS in kernel(in the IP layersimilar to TC. BTW TC works in the data-link layer). I am dequeuing the packets from the IP queue when the function ip_forward is called. After processing them, I am reinserting them back to the IP queue. I have a initlisation function (just like pktsched_init in TC). Can anyone tell me, where in the kernel boot sequence should I make a call to my initialisation function. Thanks in advance for all the help. Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
initialisation code
Hi I am trying to implement some QoS in kernel(in the IP layersimilar to TC. BTW TC works in the data-link layer). I am dequeuing the packets from the IP queue when the function ip_forward is called. After processing them, I am reinserting them back to the IP queue. I have a initlisation function (just like pktsched_init in TC). Can anyone tell me, where in the kernel boot sequence should I make a call to my initialisation function. Thanks in advance for all the help. Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: initialisation code
Hi Thanks for all the help. On Wed, 21 Mar 2001, Keith Owens wrote: On Wed, 21 Mar 2001 22:00:51 +0530 (IST), Manoj Sontakke [EMAIL PROTECTED] wrote: I have a initlisation function (just like pktsched_init in TC). Can anyone tell me, where in the kernel boot sequence should I make a call to my initialisation function. Welcome to the wonderful world of magic initialisation. (1) Declare your initialisation function as int __init foo_init(void). (2) Decide when your function needs to be called, e.g. after initialisers for A, B, C but before initialisers for X, Y, Z. where do i find this ABC abs XYZ ? What if I have to make it as an insertable/removable module? (3) Edit the Makefile to insert obj-$(CONFIG_FOO) after the objects that contain initialisers A, B, C and before the objects for initialisers X, Y, Z. Do I need to edit the .config file to add CONFIG_FOO=y ? (4) Document why the order of this routine is required! Without docs in the Makefile we have no idea if object order is correct or not. of course manojs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
quicksort for linked list
Hi Sorry, these questions do not belog here but i could not find any better place. 1. Is quicksort on doubly linked list is implemented anywhere? I need it for sk_buff queues. 2. Is Weighted Round Robin implemented in linux anyehere? thanks in advence. Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
quicksort for linked list
Hi Sorry, these questions do not belog here but i could not find any better place. 1. Is quicksort on doubly linked list is implemented anywhere? I need it for sk_buff queues. 2. Is Weighted Round Robin implemented in linux anyehere? thanks in advence. Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: spinlock help
hi
spin_lock_irq() andspin_lock_bh()
can they be of any use to u?
"Hen, Shmulik" wrote:
>
> How about if the same sequence occurred, but from two different drivers ?
>
> We've had some bad experience with this stuff. Our driver, which acts as an
> intermediate net driver, would call the hard_start_xmit in the base driver.
> The base driver, wanting to block receive interrupts would issue a
> 'spin_lock_irqsave(a,b)' and process the packet. If the TX queue is full, it
> could call an indication entry point in our intermediate driver to signal it
> to stop sending more packets. Since our indication function handles many
> types of indications but can process them only one at a time, we wanted to
> block other indications while queuing the request.
>
> The whole sequence would look like that:
>
> [our driver]
> ans_send() {
> .
> .
> e100_hard_start_xmit(dev, skb);
> .
> .
> }
>
> [e100.o]
> e100_hard_start_xmit() {
> .
> .
> spin_lock_irqsave(a,b);
> .
> .
> if(tx_queue_full)
> ans_notify(TX_QUEUE_FULL); <--
> .
> .
> spin_unlock_irqrestore(a,b);
> }
>
> [our driver]
> ans_notify() {
> .
> .
> spin_lock_irqsave(c,d);
> queue_request(req_type);
> spin_unlock_irqrestore(c,d);<--
> .
> .
> }
>
> At that point, for some reason, interrupts were back and the e100.o would
> hang in an infinite loop (we verified it on kernel 2.4.0-test10 +kdb that
> the processor was enabling interrupts and that the e100_isr was called for
> processing an Rx int.).
>
> How is that possible that a 'spin_unlock_irqrestore(c,d)' would also restore
> what should have been restored only with a 'spin_unlock_irqrestore(a,b)' ?
>
> Thanks in advance,
> Shmulik Hen
> Software Engineer
> Linux Advanced Networking Services
> Intel Network Communications Group
> Jerusalem, Israel.
>
> -Original Message-
> From: Nigel Gamble [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 07, 2001 1:54 AM
> To: Manoj Sontakke
> Cc: [EMAIL PROTECTED]
> Subject: Re: spinlock help
>
> On Tue, 6 Mar 2001, Manoj Sontakke wrote:
> > 1. when spin_lock_irqsave() function is called the subsequent code is
> > executed untill spin_unloc_irqrestore()is called. is this right?
>
> Yes. The protected code will not be interrupted, or simultaneously
> executed by another CPU.
>
> > 2. is this sequence valid?
> > spin_lock_irqsave(a,b);
> > spin_lock_irqsave(c,d);
>
> Yes, as long as it is followed by:
>
> spin_unlock_irqrestore(c, d);
> spin_unlock_irqrestore(a, b);
>
> Nigel Gamble[EMAIL PROTECTED]
> Mountain View, CA, USA. http://www.nrg.org/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Regards,
Manoj Sontakke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: spinlock help
hi
spin_lock_irq() andspin_lock_bh()
can they be of any use to u?
"Hen, Shmulik" wrote:
How about if the same sequence occurred, but from two different drivers ?
We've had some bad experience with this stuff. Our driver, which acts as an
intermediate net driver, would call the hard_start_xmit in the base driver.
The base driver, wanting to block receive interrupts would issue a
'spin_lock_irqsave(a,b)' and process the packet. If the TX queue is full, it
could call an indication entry point in our intermediate driver to signal it
to stop sending more packets. Since our indication function handles many
types of indications but can process them only one at a time, we wanted to
block other indications while queuing the request.
The whole sequence would look like that:
[our driver]
ans_send() {
.
.
e100_hard_start_xmit(dev, skb);
.
.
}
[e100.o]
e100_hard_start_xmit() {
.
.
spin_lock_irqsave(a,b);
.
.
if(tx_queue_full)
ans_notify(TX_QUEUE_FULL); --
.
.
spin_unlock_irqrestore(a,b);
}
[our driver]
ans_notify() {
.
.
spin_lock_irqsave(c,d);
queue_request(req_type);
spin_unlock_irqrestore(c,d);--
.
.
}
At that point, for some reason, interrupts were back and the e100.o would
hang in an infinite loop (we verified it on kernel 2.4.0-test10 +kdb that
the processor was enabling interrupts and that the e100_isr was called for
processing an Rx int.).
How is that possible that a 'spin_unlock_irqrestore(c,d)' would also restore
what should have been restored only with a 'spin_unlock_irqrestore(a,b)' ?
Thanks in advance,
Shmulik Hen
Software Engineer
Linux Advanced Networking Services
Intel Network Communications Group
Jerusalem, Israel.
-Original Message-
From: Nigel Gamble [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 1:54 AM
To: Manoj Sontakke
Cc: [EMAIL PROTECTED]
Subject: Re: spinlock help
On Tue, 6 Mar 2001, Manoj Sontakke wrote:
1. when spin_lock_irqsave() function is called the subsequent code is
executed untill spin_unloc_irqrestore()is called. is this right?
Yes. The protected code will not be interrupted, or simultaneously
executed by another CPU.
2. is this sequence valid?
spin_lock_irqsave(a,b);
spin_lock_irqsave(c,d);
Yes, as long as it is followed by:
spin_unlock_irqrestore(c, d);
spin_unlock_irqrestore(a, b);
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Regards,
Manoj Sontakke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
spinlock help
Hi Thankx in idvance for the help. 1. when spin_lock_irqsave() function is called the subsequent code is executed untill spin_unloc_irqrestore()is called. is this right? 2. is this sequence valid? spin_lock_irqsave(a,b); spin_lock_irqsave(c,d); Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
spinlock help
Hi Thankx in idvance for the help. 1. when spin_lock_irqsave() function is called the subsequent code is executed untill spin_unloc_irqrestore()is called. is this right? 2. is this sequence valid? spin_lock_irqsave(a,b); spin_lock_irqsave(c,d); Manoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
