Re: usb/serial/io_ti.c broken on BE systems
Johan Hovold johan@... writes: Care to test the patch below (against usb-next) on both your LE and BE machines? Thanks I'll try your patch next WE. I've patched the code in a similar way a few days ago, but I have strange problems: I can do a write and a read, but then I have to close the serial port or the next write/read will block... Cheers, -- Ludovic Drolez. http://www.aopensource.com - The Android Open Source Portal http://www.drolez.com - Personal site - Linux and Free Software -- 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
Re: USB to Serial converter code pl2303
[ Please make sure to CC the linux-usb list as well. ] On Tue, Feb 18, 2014 at 02:57:45AM +0100, Magnus wrote: After plugging in the plexgear adapter into my linux boxes: Fedora 18, Debian 3.11.0-15-generic #25-Ubuntu and weezy it doesnt send any commands to the servo controller chip on the other side of the converter. I can open the port /dev/ttyUSB0 and send to it with stty, but not a beep on the other side. I have also set the tty Baudrate manually to 2400 but this made no difference. My code does this as well including setting stopbit parity and so on. First verify that the converter works by connecting it to a serial port on your PC and using a terminal program such as minicom at 115200 baud (and the same port settings including flow control) on both ends. Also make sure you got the wiring right (e.g. use a null-modem cable). Some data i get from Linux and Plexgear converter follows: $ lsmod | grep pl2303 pl2303 18527 0 usbserial 38603 1 pl2303 $ lsusb Bus 005 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port $ lsusb -v Bus 005 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Couldn't open device, some information will be missing (My comment... hmm, but it can read from it ?).. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x067b Prolific Technology, Inc. idProduct 0x2303 PL2303 Serial Port bcdDevice3.00 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 I can code some, but i dont know where to start so any help on this is highly appreciated. When i google to find info on adapters i read that bMaxPacketSize0 64 indicates that its a counterfeit product but i paid 250 Swedish for it and that not very cheap for a univeristy student i think. This device is likely not a clone, but should be supported by the pl2303 driver either way (at least at 115200 baud). Good luck, Johan -- 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
Re: usb/serial/io_ti.c broken on BE systems
On Tue, Feb 18, 2014 at 08:49:17AM +, Ludovic wrote: Johan Hovold johan@... writes: Care to test the patch below (against usb-next) on both your LE and BE machines? Thanks I'll try your patch next WE. Great. I've patched the code in a similar way a few days ago, but I have strange problems: I can do a write and a read, but then I have to close the serial port or the next write/read will block... Apparently no one has been using this device on a BE system before so there could be further endian issues. See if you can reproduce the second problem with the patch I sent applied, and post a log from when it occurs while running with debugging enabled. Oh, and you're stuck on an old kernel on you router, right? Any chance you can try this on a recent kernel such as v3.13? There's been quite a few changes to the driver since v3.3. Thanks, Johan -- 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
Re: usbserial_generic, idVendor=1a28, idProduct=6010
On Sun, Feb 16, 2014 at 12:35:06PM +0100, Emanuel Koczwara wrote: Hi, I have a device (thermal printer) which communicates through rs232. It has also usb adapter/converter build-in. root@emanuel-laptop:/home/emanuel# lsusb Bus 004 Device 004: ID 8086:0189 Intel Corp. Bus 004 Device 008: ID 1a28:6010 -- here Who is the manufacturer and what is the model? Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 003: ID 0458:003a KYE Systems Corp. (Mouse Systems) NetScroll+ Mini Traveler / Genius NetScroll 120 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 05ca:181f Ricoh Co., Ltd Bus 001 Device 003: ID 138a:0011 Validity Sensors, Inc. VFS5011 Fingerprint Reader Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@emanuel-laptop:/home/emanuel# lsusb -d 1a28:6010 -v Bus 004 Device 008: ID 1a28:6010 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1a28 idProduct 0x6010 bcdDevice5.00 iManufacturer 4 (error) iProduct 14 (error) iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 55 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 90mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 14 (error) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 14 (error) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0001 Self Powered After 'modprobe usbserial vendor=0x1a28 product=0x6010' the device is working, /dev/ttyUSB0 pops out. I can read and write to /dev/ttyUSB0 and it responds. [34449.932999] usb 4-1.3: new full-speed USB device number 8 using ehci-pci [34450.029508] usb 4-1.3: string descriptor 0 read error: -32 [34450.029521] usb 4-1.3: New USB device found, idVendor=1a28, idProduct=6010 [34450.029526] usb 4-1.3: New USB device strings: Mfr=4, Product=14, SerialNumber=0 [34450.029927] usbserial_generic 4-1.3:1.0: The generic usb-serial driver is only for testing and one-off prototypes. [34450.029932] usbserial_generic
Re: [RFC 1/2] usb: gadget: zero: Add support for interrupt EP
Dear Andrezej,
On 2/10/2014 7:15 PM, Andrzej Pietrasiewicz wrote:
W dniu 10.02.2014 14:16, Amit Virdi pisze:
Interrupt endpoints behave quite similar to the bulk endpoints with the
difference that the endpoints expect data sending/reception request at
particular intervals till the whole data has not been transmitted.
The interrupt EP support is added to gadget zero. A new alternate setting (=2)
has been added. It has 6 endpoints (2-BULK, 2-ISOC, 2-INTERRUPT). The default
parameters are set as:
bInterval: 4
wMaxPacketSize: 1024
However, the same can be overridden through the module parameter interface.
The module parameter interface is available only in legacy mode,
that is using g_zero.ko. Both sourcesink and loopback now support
configfs.
Thanks for the enlightenment. I'll implement parameter passing through
configfs.
The code is tested for HS and SS on a platform having DWC3 controller.
Signed-off-by: Amit Virdi amit.vi...@st.com
snip
+static unsigned int_interval;
+static unsigned int_maxpacket;
+static unsigned int_mult;
+static unsigned int_maxburst;
For these you need appropriate configfs attributes (files).
Below there is a typical way to create the attributes.
/*
* show means to copy data from kernel to user;
* you get the opts pointer and copy the relevant data to the page
*/
static ssize_t f_ss_opts_pattern_show(struct f_ss_opts *opts, char *page)
{
int result;
mutex_lock(opts-lock);
result = sprintf(page, %d, opts-pattern);
mutex_unlock(opts-lock);
return result;
}
/*
* store means to copy data from user to the kernel;
* you take data from the page and interpret it;
* if it is ok, you store it in the opts
*/
static ssize_t f_ss_opts_pattern_store(struct f_ss_opts *opts,
const char *page, size_t len)
{
int ret;
u8 num;
mutex_lock(opts-lock);
if (opts-refcnt) {
ret = -EBUSY;
goto end;
}
ret = kstrtou8(page, 0, num);
if (ret)
goto end;
if (num != 0 num != 1 num != 2) {
ret = -EINVAL;
goto end;
}
opts-pattern = num;
ret = len;
end:
mutex_unlock(opts-lock);
return ret;
}
static struct f_ss_opts_attribute f_ss_opts_pattern =
__CONFIGFS_ATTR(pattern, S_IRUGO | S_IWUSR,
f_ss_opts_pattern_show,
f_ss_opts_pattern_store);
/*
* definitions of f_ss_opts_isoc_interval co follow
*/
...
/*
* hereyou should create your implementations of
* f_ss_opts_int_interval_show/store co
*/
/*
*and then attach the attributes to the config item;
* which translates to making new files appear in their
* directory
*/
static struct configfs_attribute *ss_attrs[] = {
f_ss_opts_pattern.attr,
f_ss_opts_isoc_interval.attr,
f_ss_opts_isoc_maxpacket.attr,
f_ss_opts_isoc_mult.attr,
f_ss_opts_isoc_maxburst.attr,
f_ss_opts_bulk_buflen.attr,
/* HERE */
f_ss_opts_isoc_interval.attr,
NULL,
};
Ok, I got it.
I'll incorporate your comments and send V1 in sometime.
Regards
Amit Virdi
--
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
Re: [BUG] FL1009: xHCI host not responding to stop endpoint command.
Dear Arnaud Ebalard, On Sat, 18 Jan 2014 22:49:17 +0100, Arnaud Ebalard wrote: I started suspecting the introduction of MSI support in Marvell PCIe host controller driver (FL1009 is on the PCIe bus) and compiled a a 3.13.0-rc8 w/ CONFIG_PCI_MSI disabled (it was enabled in all my previous tests): I did not manage to reproduce the issue with this kernel. As a side note, commits 5b4deb6526bd, 31f614edb726 and 627dfcc249e2 are ATM, I do not know if the problem is related to a bug in introduced MSI support or some weird incompatibility of that functionality with the FL1009 which would require some quirk in XHCI stack. Thomas, I took a look at the changes but I am not familiar w/ how MSI work. You may have an idea on what is going on here. I finally got some idea: your kernel 3.13-rc7 lacks a very important fix we did in the irqchip driver MSI handling. You really need to have http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/irqchip/irq-armada-370-xp.c?id=c7f7bd4a136e4b02dd2a66bf95aec545bd93e8db applied to get proper MSI behavior. Without this patch, there is a race condition, and some MSI interrupts might be lost. This commit was merged in v3.14-rc2, and backported to 3.13 and previous stable releases. Can you test after applying this commit? ps: Thomas, this is completely unrelated but the code below caught my eye at the beginning of a hunk in 31f614edb726. When CONFIG_PCI_MSI is disabled, why is irqnr now compared to 1 instead of 0? This is not important. IRQs 0 and 1 are reserved for doorbells, which are only used for IPI (IRQ 0) and MSI (IRQ 1). Therefore, doing irq_find_mapping() for either IRQ 0 or IRQ 1 is not useful. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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
gadget support
hi all In my PC have the kernel linux usb gadget support enabled but when i try to load the module: sudo modprobe g_ether FATAL: Error inserting g_ether (/lib/modules/3.13.2/kernel/drivers/usb/gadget/g_ether.ko): No such device maybe my usb is not supported by the driver. I don't know. i have a NM10/ICH7 Family USB UHCI Controller -- Atte. Arturo -- 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
[PATCH v2 3/3] usb: chipidea: msm: Initialize offset of the capability registers
From: Ivan T. Ivanov iiva...@mm-sol.com
Since commit 62bb84e (usb: gadget: ci13xxx: convert to platform device)
start address of the capability registers is not passed correctly to
udc_probe(). Fix this.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 3f67f1f..7ed3fad 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -47,6 +47,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
.name = ci_hdrc_msm,
+ .capoffset = DEF_CAPOFFSET,
.flags = CI_HDRC_REGS_SHARED |
CI_HDRC_REQUIRE_TRANSCEIVER |
CI_HDRC_DISABLE_STREAMING,
--
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
[PATCH v2 0/3] usb: chipidea: msm: Clean and fix glue layer driver
From: Ivan T. Ivanov iiva...@mm-sol.com Hi, This series intend to fix driver, which was broken for a while. It is used to create peripheral role device, which in coordination with phy-usb-msm driver will provide USB2.0 gadget support for Qualcomm targets. Changes since initial version. - Address comments from Peter - better description of the changes. - Drop patch 4 - till USB PHY driver is ready Ivan T. Ivanov (3): usb: chipidea: msm: Add device tree binding information usb: chipidea: msm: Add device tree support usb: chipidea: msm: Initialize offset of the capability registers .../devicetree/bindings/usb/msm-hsusb.txt | 17 ++ drivers/usb/chipidea/ci_hdrc_msm.c | 24 +++- 2 files changed, 40 insertions(+), 1 deletion(-) -- 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
[PATCH v2 2/3] usb: chipidea: msm: Add device tree support
From: Ivan T. Ivanov iiva...@mm-sol.com
Allows controller to be specified via device tree.
Pass PHY phandle specified in DT to core driver.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 2d51d85..3f67f1f 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -57,9 +57,21 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
static int ci_hdrc_msm_probe(struct platform_device *pdev)
{
struct platform_device *plat_ci;
+ struct usb_phy *phy;
dev_dbg(pdev-dev, ci_hdrc_msm_probe\n);
+ /*
+* OTG(PHY) driver takes care of PHY initialization, clock management,
+* powering up VBUS, mapping of registers address space and power
+* management.
+*/
+ phy = devm_usb_get_phy_by_phandle(pdev-dev, usb-phy, 0);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ ci_hdrc_msm_platdata.phy = phy;
+
plat_ci = ci_hdrc_add_device(pdev-dev,
pdev-resource, pdev-num_resources,
ci_hdrc_msm_platdata);
@@ -86,10 +98,19 @@ static int ci_hdrc_msm_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id msm_ci_dt_match[] = {
+ { .compatible = qcom,ci-hdrc, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, msm_ci_dt_match);
+
static struct platform_driver ci_hdrc_msm_driver = {
.probe = ci_hdrc_msm_probe,
.remove = ci_hdrc_msm_remove,
- .driver = { .name = msm_hsusb, },
+ .driver = {
+ .name = msm_hsusb,
+ .of_match_table = msm_ci_dt_match,
+ },
};
module_platform_driver(ci_hdrc_msm_driver);
--
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
Re: [PATCH 0/7] usb: dwc2/s3c-hsotg: Combine drivers into a single DRD
On 02/17/2014 09:18 AM, Robert Baldyga wrote:
On 02/17/2014 01:37 AM, Jingoo Han wrote:
On Friday, February 14, 2014 6:44 PM, Robert Baldyga wrote:
On 02/13/2014 10:10 PM, dingu...@altera.com wrote:
From: Dinh Nguyen dingu...@altera.com
Hello,
This patch series combines the dwc2 host driver and the s3c-hsotg
peripheral
driver into a single dual-roler driver similar to the dwc3.
Hi.
It looks like it doesn't work on Samsung platforms without device-tree
support.
Hi Robert Baldyga,
In order to test this patch, the current mainline kernel requires
additional patches to support device-tree. The following patches
are necessary.
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/179920.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/179921.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/179922.html
The last one should be modified for your machine.
It will not help on platforms which never had and never will have
device-tree support.
Hi,
I have tested it also on device with device tree support. I got error:
[2.10] dwc2/s3c-hsotg 1248.hsotg: dwc2_core_init(ee13f010)
[2.10] dwc2/s3c-hsotg 1248.hsotg: dwc2_core_reset()
[4.18] dwc2/s3c-hsotg 1248.hsotg: dwc2_core_reset() HANG!
Soft Reset GRSTCTL=8001
[4.19] dwc2/s3c-hsotg 1248.hsotg: dwc2_core_init(): Reset
failed, aborting
[4.195000] dwc2/s3c-hsotg: probe of 1248.hsotg failed with error -16
Best regards
Robert Baldyga
Samsung RD Institute Poland
The patch series moves the s3c-hsotg files into the /dwc2 folder, so this
is
the final location of the driver. When the driver is built as a kernel
module,
it will be dwc2.ko and dwc2_platform.ko.
patch 1/7 : Edit the defines in dwc2/hw.h so that the s3c-hsotg driver can
use
the defines in hw.h. So we can remove s3c-hsotg.h in a
subsequent
patch.
patch 2/7 : Moves the s3c-hsotg driver into /dwc2 folder. Building the
s3c-hsotg
driver will now be a Kconfig option under DWC2. Also replaces
the
s3c-hsotg.h header file for dwc2/hw.h.
patch 3/7 : Moves the s3c-hsotg data structure into a common place,
core.h, so
that final DRD can use it.
patch 4/7 : Add the gadget data structure to a common data structure,
dwc2_hsotg, which is the data structure that will encapsulate
host
and peripheral modes for the final DRD. The bulk for this patch
is edits the in s3c-hsotg.c to reference the new data
structure.
patch 5/7 : Replaces the s3c_hostg_irq handler with the
dwc2_handle_common_intr
in dwc2. Updates the dwc2 IRQ routines to call the s3c-hsotg
gadget
functions for peripheral mode.
patch 6/7 : Update the Kconfig and Makefile to enable building of the
single
DRD. At this stage the the driver is behaving as a dual-role
driver.
patch 7/7 : Decouple host/peripheral functionality when buildling the
driver in
host or peripheral mode only.
This patchset is based on 3.14-rc2. I have only tested on the SOCFPGA
platform
which has v2.93a of dual-role IP.
Thanks,
Dinh Nguyen (7):
usb: dwc2: Add defines to support the s3c-hsotg driver
usb: s3c-hsotg: Move s3c-hsotg into dwc2 folder
usb: s3c-hsotg: Move s3c-hsotg data structures
usb: dwc2: Add the s3c-hsotg data structures to main dwc2_hsotg data
structure
usb: dwc2: combine the dwc2 and s3c_hsotg to use a single IRQ handler
usb: dwc2: Enable the dwc2/s3c-hsotg to be a single dual-role driver
usb: dwc2: Split out the dwc2/sc3-hsotg driver mode's build
dependency
drivers/usb/dwc2/Kconfig | 28 +
drivers/usb/dwc2/Makefile| 17 +-
drivers/usb/dwc2/core.c |1 +
drivers/usb/dwc2/core.h | 225 +++-
drivers/usb/dwc2/core_intr.c | 108 +-
drivers/usb/dwc2/hcd.c |7 +-
drivers/usb/dwc2/hcd.h | 23 +-
drivers/usb/dwc2/hw.h| 23 +-
drivers/usb/dwc2/platform.c | 50 +-
drivers/usb/{gadget = dwc2}/s3c-hsotg.c | 1807
+++---
drivers/usb/gadget/Kconfig |7 -
drivers/usb/gadget/Makefile |1 -
drivers/usb/gadget/s3c-hsotg.h | 378 ---
13 files changed, 1128 insertions(+), 1547 deletions(-)
rename drivers/usb/{gadget = dwc2}/s3c-hsotg.c (57%)
delete mode 100644 drivers/usb/gadget/s3c-hsotg.h
---
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Paul Zimmerman pa...@synopsys.com
Cc: Felipe Balbi ba...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Matt Porter mpor...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Matthijs Kooijman matth...@stdin.nl
Cc: Jingoo Han jg1@samsung.com
Cc: Sachin Kamat
[PATCH net-next 14/14] r8152: support get_msglevel and set_msglevel
Support get_msglevel and set_msglevel.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index db98842..0654bd3 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2852,6 +2852,20 @@ out_set_wol:
return ret;
}
+static u32 rtl8152_get_msglevel(struct net_device *dev)
+{
+ struct r8152 *tp = netdev_priv(dev);
+
+ return tp-msg_enable;
+}
+
+static void rtl8152_set_msglevel(struct net_device *dev, u32 value)
+{
+ struct r8152 *tp = netdev_priv(dev);
+
+ tp-msg_enable = value;
+}
+
static void rtl8152_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *info)
{
@@ -2895,6 +2909,8 @@ static struct ethtool_ops ops = {
.get_settings = rtl8152_get_settings,
.set_settings = rtl8152_set_settings,
.get_link = ethtool_op_get_link,
+ .get_msglevel = rtl8152_get_msglevel,
+ .set_msglevel = rtl8152_set_msglevel,
.get_wol = rtl8152_get_wol,
.set_wol = rtl8152_set_wol,
};
--
1.8.4.2
--
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
[PATCH net-next 07/14] r8152: combine PHY reset with set_speed
PHY reset is necessary after some hw settings. However, it would
cause the linking down, and so does the set_speed function. Combine
the PHY reset with set_speed function. That could reduce the frequency
of linking down and accessing the PHY register.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 57 ++---
1 file changed, 45 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c7bae39..b3155da 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -436,6 +436,7 @@ enum rtl8152_flags {
RTL8152_SET_RX_MODE,
WORK_ENABLE,
RTL8152_LINK_CHG,
+ PHY_RESET,
};
/* Define these values to match your device */
@@ -1796,6 +1797,29 @@ static void r8152_power_cut_en(struct r8152 *tp, bool
enable)
}
+static void rtl_phy_reset(struct r8152 *tp)
+{
+ u16 data;
+ int i;
+
+ clear_bit(PHY_RESET, tp-flags);
+
+ data = r8152_mdio_read(tp, MII_BMCR);
+
+ /* don't reset again before the previous one complete */
+ if (data BMCR_RESET)
+ return;
+
+ data |= BMCR_RESET;
+ r8152_mdio_write(tp, MII_BMCR, data);
+
+ for (i = 0; i 50; i++) {
+ msleep(20);
+ if ((r8152_mdio_read(tp, MII_BMCR) BMCR_RESET) == 0)
+ break;
+ }
+}
+
static void rtl_clear_bp(struct r8152 *tp)
{
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_0, 0);
@@ -1854,6 +1878,7 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
}
r8152b_disable_aldps(tp);
+ set_bit(PHY_RESET, tp-flags);
}
static void r8152b_exit_oob(struct r8152 *tp)
@@ -2042,6 +2067,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
data = sram_read(tp, SRAM_10M_AMP2);
data |= AMP_DN;
sram_write(tp, SRAM_10M_AMP2, data);
+
+ set_bit(PHY_RESET, tp-flags);
}
static void r8153_u1u2en(struct r8152 *tp, bool enable)
@@ -2295,12 +2322,26 @@ static int rtl8152_set_speed(struct r8152 *tp, u8
autoneg, u16 speed, u8 duplex)
bmcr = BMCR_ANENABLE | BMCR_ANRESTART;
}
+ if (test_bit(PHY_RESET, tp-flags))
+ bmcr |= BMCR_RESET;
+
if (tp-mii.supports_gmii)
r8152_mdio_write(tp, MII_CTRL1000, gbcr);
r8152_mdio_write(tp, MII_ADVERTISE, anar);
r8152_mdio_write(tp, MII_BMCR, bmcr);
+ if (test_bit(PHY_RESET, tp-flags)) {
+ int i;
+
+ clear_bit(PHY_RESET, tp-flags);
+ for (i = 0; i 50; i++) {
+ msleep(20);
+ if ((r8152_mdio_read(tp, MII_BMCR) BMCR_RESET) == 0)
+ break;
+ }
+ }
+
out:
return ret;
@@ -2364,6 +2405,10 @@ static void rtl_work_func_t(struct work_struct *work)
if (test_bit(RTL8152_SET_RX_MODE, tp-flags))
_rtl8152_set_rx_mode(tp-netdev);
+
+ if (test_bit(PHY_RESET, tp-flags))
+ rtl_phy_reset(tp);
+
out1:
return;
}
@@ -2459,7 +2504,6 @@ static void r8152b_enable_fc(struct r8152 *tp)
static void r8152b_init(struct r8152 *tp)
{
u32 ocp_data;
- int i;
rtl_clear_bp(tp);
@@ -2491,14 +2535,6 @@ static void r8152b_init(struct r8152 *tp)
r8152b_enable_aldps(tp);
r8152b_enable_fc(tp);
- r8152_mdio_write(tp, MII_BMCR, BMCR_RESET | BMCR_ANENABLE |
- BMCR_ANRESTART);
- for (i = 0; i 100; i++) {
- udelay(100);
- if (!(r8152_mdio_read(tp, MII_BMCR) BMCR_RESET))
- break;
- }
-
/* enable rx aggregation */
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL);
ocp_data = ~RX_AGG_DISABLE;
@@ -2569,9 +2605,6 @@ static void r8153_init(struct r8152 *tp)
r8153_enable_eee(tp);
r8153_enable_aldps(tp);
r8152b_enable_fc(tp);
-
- r8152_mdio_write(tp, MII_BMCR, BMCR_RESET | BMCR_ANENABLE |
- BMCR_ANRESTART);
}
static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
--
1.8.4.2
--
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
[PATCH net-next 13/14] r8152: set disable_hub_initiated_lpm
Set disable_hub_initiated_lpm = 1.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ff02d5d..db98842 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3159,6 +3159,7 @@ static struct usb_driver rtl8152_driver = {
.resume = rtl8152_resume,
.reset_resume = rtl8152_resume,
.supports_autosuspend = 1,
+ .disable_hub_initiated_lpm = 1,
};
module_usb_driver(rtl8152_driver);
--
1.8.4.2
--
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
[PATCH net-next 12/14] r8152: replace netif_rx with netif_receive_skb
Replace netif_rx with netif_receive_skb to avoid disabling irq frequently for increasing the efficiency. Signed-off-by: Hayes Wang hayesw...@realtek.com --- drivers/net/usb/r8152.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 3ff11ed..ff02d5d 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1464,7 +1464,7 @@ static void rx_bottom(struct r8152 *tp) memcpy(skb-data, rx_data, pkt_len); skb_put(skb, pkt_len); skb-protocol = eth_type_trans(skb, netdev); - netif_rx(skb); + netif_receive_skb(skb); stats-rx_packets++; stats-rx_bytes += pkt_len; -- 1.8.4.2 -- 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
[PATCH net-next 08/14] r8152: move some functions from probe to open
Add up method for rtl_ops and asign relative functions. Move
clear_bp() and hw_phy_cfg() from init method to up method of rtl_ops.
Call rtl_ops.up() for ndo_open() and rtl_ops.down for ndo_stop().
Replace allocating the memory in probe() with in ndo_open().
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 45 +
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b3155da..828572a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -515,6 +515,7 @@ struct r8152 {
void (*init)(struct r8152 *);
int (*enable)(struct r8152 *);
void (*disable)(struct r8152 *);
+ void (*up)(struct r8152 *);
void (*down)(struct r8152 *);
void (*unload)(struct r8152 *);
} rtl_ops;
@@ -1878,6 +1879,10 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
}
r8152b_disable_aldps(tp);
+
+ rtl_clear_bp(tp);
+
+ r8152b_enable_aldps(tp);
set_bit(PHY_RESET, tp-flags);
}
@@ -1891,6 +1896,7 @@ static void r8152b_exit_oob(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
rxdy_gated_en(tp, true);
+ r8152b_hw_phy_cfg(tp);
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CR, 0x00);
@@ -2033,6 +2039,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8152_mdio_write(tp, MII_BMCR, data);
}
+ r8153_clear_bp(tp);
+
if (tp-version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
data = ~CTAP_SHORT_EN;
@@ -2418,6 +2426,12 @@ static int rtl8152_open(struct net_device *netdev)
struct r8152 *tp = netdev_priv(netdev);
int res = 0;
+ res = alloc_all_mem(tp);
+ if (res)
+ goto out;
+
+ tp-rtl_ops.up(tp);
+
rtl8152_set_speed(tp, AUTONEG_ENABLE,
tp-mii.supports_gmii ? SPEED_1000 : SPEED_100,
DUPLEX_FULL);
@@ -2431,9 +2445,11 @@ static int rtl8152_open(struct net_device *netdev)
netif_device_detach(tp-netdev);
netif_warn(tp, ifup, netdev, intr_urb submit failed: %d\n,
res);
+ free_all_mem(tp);
}
+out:
return res;
}
@@ -2447,9 +2463,11 @@ static int rtl8152_close(struct net_device *netdev)
cancel_delayed_work_sync(tp-schedule);
netif_stop_queue(netdev);
tasklet_disable(tp-tl);
- tp-rtl_ops.disable(tp);
+ tp-rtl_ops.down(tp);
tasklet_enable(tp-tl);
+ free_all_mem(tp);
+
return res;
}
@@ -2505,21 +2523,14 @@ static void r8152b_init(struct r8152 *tp)
{
u32 ocp_data;
- rtl_clear_bp(tp);
-
if (tp-version == RTL_VER_01) {
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_LED_FEATURE);
ocp_data = ~LED_MODE_MASK;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_LED_FEATURE, ocp_data);
}
- r8152b_hw_phy_cfg(tp);
-
r8152_power_cut_en(tp, false);
-
- r8152b_exit_oob(tp);
-
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_PHY_PWR);
ocp_data |= TX_10M_IDLE_EN | PFM_PWM_SWITCH;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_PHY_PWR, ocp_data);
@@ -2568,8 +2579,6 @@ static void r8153_init(struct r8152 *tp)
ocp_data = ~TIMER11_EN;
ocp_write_word(tp, MCU_TYPE_USB, USB_WDT11_CTRL, ocp_data);
- r8153_clear_bp(tp);
-
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_LED_FEATURE);
ocp_data = ~LED_MODE_MASK;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_LED_FEATURE, ocp_data);
@@ -2590,8 +2599,6 @@ static void r8153_init(struct r8152 *tp)
r8153_power_cut_en(tp, false);
r8153_u1u2en(tp, true);
- r8153_first_init(tp);
-
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, ALDPS_SPDWN_RATIO);
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, EEE_SPDWN_RATIO);
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
@@ -2618,10 +2625,10 @@ static int rtl8152_suspend(struct usb_interface *intf,
pm_message_t message)
usb_kill_urb(tp-intr_urb);
cancel_delayed_work_sync(tp-schedule);
tasklet_disable(tp-tl);
+ tp-rtl_ops.down(tp);
+ tasklet_enable(tp-tl);
}
- tp-rtl_ops.down(tp);
-
return 0;
}
@@ -2632,6 +2639,7 @@ static int rtl8152_resume(struct usb_interface *intf)
tp-rtl_ops.init(tp);
netif_device_attach(tp-netdev);
if (netif_running(tp-netdev)) {
+ tp-rtl_ops.up(tp);
rtl8152_set_speed(tp, AUTONEG_ENABLE,
tp-mii.supports_gmii ? SPEED_1000 : SPEED_100,
[PATCH net-next 03/14] r8152: replace some types from int to bool
Modify the following functions.
- r8153_u1u2en
- r8153_u2p3en
- r8153_power_cut_en
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2d5e761..4888e4f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1989,7 +1989,7 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP2, data);
}
-static void r8153_u1u2en(struct r8152 *tp, int enable)
+static void r8153_u1u2en(struct r8152 *tp, bool enable)
{
u8 u1u2[8];
@@ -2001,7 +2001,7 @@ static void r8153_u1u2en(struct r8152 *tp, int enable)
usb_ocp_write(tp, USB_TOLERANCE, BYTE_EN_SIX_BYTES, sizeof(u1u2), u1u2);
}
-static void r8153_u2p3en(struct r8152 *tp, int enable)
+static void r8153_u2p3en(struct r8152 *tp, bool enable)
{
u32 ocp_data;
@@ -2013,7 +2013,7 @@ static void r8153_u2p3en(struct r8152 *tp, int enable)
ocp_write_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL, ocp_data);
}
-static void r8153_power_cut_en(struct r8152 *tp, int enable)
+static void r8153_power_cut_en(struct r8152 *tp, bool enable)
{
u32 ocp_data;
@@ -2261,8 +2261,8 @@ static void rtl8152_down(struct r8152 *tp)
static void rtl8153_down(struct r8152 *tp)
{
- r8153_u1u2en(tp, 0);
- r8153_power_cut_en(tp, 0);
+ r8153_u1u2en(tp, false);
+ r8153_power_cut_en(tp, false);
r8153_disable_aldps(tp);
r8153_enter_oob(tp);
r8153_enable_aldps(tp);
@@ -2455,7 +2455,7 @@ static void r8153_init(struct r8152 *tp)
u32 ocp_data;
int i;
- r8153_u1u2en(tp, 0);
+ r8153_u1u2en(tp, false);
for (i = 0; i 500; i++) {
if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_BOOT_CTRL)
@@ -2471,7 +2471,7 @@ static void r8153_init(struct r8152 *tp)
msleep(20);
}
- r8153_u2p3en(tp, 0);
+ r8153_u2p3en(tp, false);
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_WDT11_CTRL);
ocp_data = ~TIMER11_EN;
@@ -2496,8 +2496,8 @@ static void r8153_init(struct r8152 *tp)
ocp_data |= SEN_VAL_NORMAL | SEL_RXIDLE;
ocp_write_word(tp, MCU_TYPE_USB, USB_AFE_CTRL2, ocp_data);
- r8153_power_cut_en(tp, 0);
- r8153_u1u2en(tp, 1);
+ r8153_power_cut_en(tp, false);
+ r8153_u1u2en(tp, true);
r8153_first_init(tp);
@@ -2677,7 +2677,7 @@ static void rtl8152_unload(struct r8152 *tp)
static void rtl8153_unload(struct r8152 *tp)
{
- r8153_power_cut_en(tp, 1);
+ r8153_power_cut_en(tp, true);
}
static int rtl_ops_init(struct r8152 *tp, const struct usb_device_id *id)
--
1.8.4.2
--
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
[PATCH net-next 11/14] r8152: disable teredo for RTL8152
Disable teredo for RTL8152 by default. Signed-off-by: Hayes Wang hayesw...@realtek.com --- drivers/net/usb/r8152.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index f303549..3ff11ed 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -2021,6 +2021,7 @@ static void r8152b_exit_oob(struct r8152 *tp) ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data); rxdy_gated_en(tp, true); + r8153_teredo_off(tp); r8152b_hw_phy_cfg(tp); ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML); -- 1.8.4.2 -- 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
[PATCH net-next 10/14] r8152: support runtime suspend
Support runtime suspend for RTL8152 and RTL8153.
Move tx_bottom() from tasklet to delayed_work. That avoids to
transmit tx packets after calling autosuspend.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 181 ++--
1 file changed, 158 insertions(+), 23 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5d520be..f303549 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -445,6 +445,7 @@ enum rtl8152_flags {
RTL8152_SET_RX_MODE,
WORK_ENABLE,
RTL8152_LINK_CHG,
+ SELECTIVE_SUSPEND,
PHY_RESET,
};
@@ -877,11 +878,21 @@ static u16 sram_read(struct r8152 *tp, u16 addr)
static int read_mii_word(struct net_device *netdev, int phy_id, int reg)
{
struct r8152 *tp = netdev_priv(netdev);
+ int ret;
if (phy_id != R8152_PHY_ID)
return -EINVAL;
- return r8152_mdio_read(tp, reg);
+ ret = usb_autopm_get_interface(tp-intf);
+ if (ret 0)
+ goto out;
+
+ ret = r8152_mdio_read(tp, reg);
+
+ usb_autopm_put_interface(tp-intf);
+
+out:
+ return ret;
}
static
@@ -892,7 +903,12 @@ void write_mii_word(struct net_device *netdev, int phy_id,
int reg, int val)
if (phy_id != R8152_PHY_ID)
return;
+ if (usb_autopm_get_interface(tp-intf) 0)
+ return;
+
r8152_mdio_write(tp, reg, val);
+
+ usb_autopm_put_interface(tp-intf);
}
static
@@ -978,6 +994,8 @@ static void read_bulk_callback(struct urb *urb)
if (!netif_carrier_ok(netdev))
return;
+ usb_mark_last_busy(tp-udev);
+
switch (status) {
case 0:
if (urb-actual_length ETH_ZLEN)
@@ -1045,6 +1063,8 @@ static void write_bulk_callback(struct urb *urb)
list_add_tail(agg-list, tp-tx_free);
spin_unlock_irqrestore(tp-tx_lock, flags);
+ usb_autopm_put_interface_async(tp-intf);
+
if (!netif_carrier_ok(tp-netdev))
return;
@@ -1055,7 +1075,7 @@ static void write_bulk_callback(struct urb *urb)
return;
if (!skb_queue_empty(tp-tx_queue))
- tasklet_schedule(tp-tl);
+ schedule_delayed_work(tp-schedule, 0);
}
static void intr_callback(struct urb *urb)
@@ -1313,7 +1333,7 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
{
struct sk_buff_head skb_head, *tx_queue = tp-tx_queue;
unsigned long flags;
- int remain;
+ int remain, ret;
u8 *tx_data;
__skb_queue_head_init(skb_head);
@@ -1361,19 +1381,28 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
spin_unlock_irqrestore(tx_queue-lock, flags);
}
- netif_tx_lock(tp-netdev);
+ netif_tx_lock_bh(tp-netdev);
if (netif_queue_stopped(tp-netdev)
skb_queue_len(tp-tx_queue) tp-tx_qlen)
netif_wake_queue(tp-netdev);
- netif_tx_unlock(tp-netdev);
+ netif_tx_unlock_bh(tp-netdev);
+
+ ret = usb_autopm_get_interface(tp-intf);
+ if (ret 0)
+ goto out_tx_fill;
usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
agg-head, (int)(tx_data - (u8 *)agg-head),
(usb_complete_t)write_bulk_callback, agg);
- return usb_submit_urb(agg-urb, GFP_ATOMIC);
+ ret = usb_submit_urb(agg-urb, GFP_KERNEL);
+ if (ret 0)
+ usb_autopm_put_interface(tp-intf);
+
+out_tx_fill:
+ return ret;
}
static void rx_bottom(struct r8152 *tp)
@@ -1511,7 +1540,6 @@ static void bottom_half(unsigned long data)
return;
rx_bottom(tp);
- tx_bottom(tp);
}
static
@@ -1621,7 +1649,7 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
netif_stop_queue(netdev);
if (!list_empty(tp-tx_free))
- tasklet_schedule(tp-tl);
+ schedule_delayed_work(tp-schedule, 0);
return NETDEV_TX_OK;
}
@@ -1876,6 +1904,25 @@ static void __rtl_set_wol(struct r8152 *tp, u32 wolopts)
device_set_wakeup_enable(tp-udev-dev, false);
}
+static void rtl_runtime_suspend_enable(struct r8152 *tp, bool enable)
+{
+ if (enable) {
+ u32 ocp_data;
+
+ __rtl_set_wol(tp, WAKE_ANY);
+
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CONFIG34);
+ ocp_data |= LINK_OFF_WAKE_EN;
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_CONFIG34, ocp_data);
+
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
+ } else {
+ __rtl_set_wol(tp, tp-saved_wolopts);
+ }
+}
+
static void rtl_phy_reset(struct r8152 *tp)
{
u16 data;
@@ -2467,6
[PATCH net-next 06/14] r8152: clear BMCR_PDOWN
Modify the method of enabling the PHY to clear BMCR_PDOWN only.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2a778fa..c7bae39 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1845,7 +1845,14 @@ static inline void r8152b_enable_aldps(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- r8152_mdio_write(tp, MII_BMCR, BMCR_ANENABLE);
+ u16 data;
+
+ data = r8152_mdio_read(tp, MII_BMCR);
+ if (data BMCR_PDOWN) {
+ data = ~BMCR_PDOWN;
+ r8152_mdio_write(tp, MII_BMCR, data);
+ }
+
r8152b_disable_aldps(tp);
}
@@ -1995,7 +2002,11 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
u16 data;
ocp_reg_write(tp, OCP_ADC_CFG, CKADSEL_L | ADC_EN | EN_EMI_L);
- r8152_mdio_write(tp, MII_BMCR, BMCR_ANENABLE);
+ data = r8152_mdio_read(tp, MII_BMCR);
+ if (data BMCR_PDOWN) {
+ data = ~BMCR_PDOWN;
+ r8152_mdio_write(tp, MII_BMCR, data);
+ }
if (tp-version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
--
1.8.4.2
--
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
[PATCH net-next 09/14] r8152: support WOL
Support WOL for RTL8152 and RTL8153.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 118 ++--
1 file changed, 105 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 828572a..5d520be 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -23,7 +23,7 @@
#include linux/ipv6.h
/* Version Information */
-#define DRIVER_VERSION v1.04.0 (2014/01/15)
+#define DRIVER_VERSION v1.05.0 (2014/02/18)
#define DRIVER_AUTHOR Realtek linux nic maintainers nic_s...@realtek.com
#define DRIVER_DESC Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
#define MODULENAME r8152
@@ -62,6 +62,8 @@
#define PLA_RSTTELLY 0xe800
#define PLA_CR 0xe813
#define PLA_CRWECR 0xe81c
+#define PLA_CONFIG12 0xe81e /* CONFIG1, CONFIG2 */
+#define PLA_CONFIG34 0xe820 /* CONFIG3, CONFIG4 */
#define PLA_CONFIG50xe822
#define PLA_PHY_PWR0xe84c
#define PLA_OOB_CTRL 0xe84f
@@ -216,7 +218,14 @@
/* PAL_BDC_CR */
#define ALDPS_PROXY_MODE 0x0001
+/* PLA_CONFIG34 */
+#define LINK_ON_WAKE_EN0x0010
+#define LINK_OFF_WAKE_EN 0x0008
+
/* PLA_CONFIG5 */
+#define BWF_EN 0x0040
+#define MWF_EN 0x0020
+#define UWF_EN 0x0010
#define LAN_WAKE_EN0x0002
/* PLA_LED_FEATURE */
@@ -521,6 +530,7 @@ struct r8152 {
} rtl_ops;
int intr_interval;
+ u32 saved_wolopts;
u32 msg_enable;
u32 tx_qlen;
u16 ocp_base;
@@ -1798,6 +1808,74 @@ static void r8152_power_cut_en(struct r8152 *tp, bool
enable)
}
+#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
+
+static u32 __rtl_get_wol(struct r8152 *tp)
+{
+ u32 ocp_data;
+ u32 wolopts = 0;
+
+ ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_CONFIG5);
+ if (!(ocp_data LAN_WAKE_EN))
+ return 0;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CONFIG34);
+ if (ocp_data LINK_ON_WAKE_EN)
+ wolopts |= WAKE_PHY;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CONFIG5);
+ if (ocp_data UWF_EN)
+ wolopts |= WAKE_UCAST;
+ if (ocp_data BWF_EN)
+ wolopts |= WAKE_BCAST;
+ if (ocp_data MWF_EN)
+ wolopts |= WAKE_MCAST;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CFG_WOL);
+ if (ocp_data MAGIC_EN)
+ wolopts |= WAKE_MAGIC;
+
+ return wolopts;
+}
+
+static void __rtl_set_wol(struct r8152 *tp, u32 wolopts)
+{
+ u32 ocp_data;
+
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CONFIG34);
+ ocp_data = ~LINK_ON_WAKE_EN;
+ if (wolopts WAKE_PHY)
+ ocp_data |= LINK_ON_WAKE_EN;
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_CONFIG34, ocp_data);
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CONFIG5);
+ ocp_data = ~(UWF_EN | BWF_EN | MWF_EN | LAN_WAKE_EN);
+ if (wolopts WAKE_UCAST)
+ ocp_data |= UWF_EN;
+ if (wolopts WAKE_BCAST)
+ ocp_data |= BWF_EN;
+ if (wolopts WAKE_MCAST)
+ ocp_data |= MWF_EN;
+ if (wolopts WAKE_ANY)
+ ocp_data |= LAN_WAKE_EN;
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_CONFIG5, ocp_data);
+
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CFG_WOL);
+ ocp_data = ~MAGIC_EN;
+ if (wolopts WAKE_MAGIC)
+ ocp_data |= MAGIC_EN;
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_CFG_WOL, ocp_data);
+
+ if (wolopts WAKE_ANY)
+ device_set_wakeup_enable(tp-udev-dev, true);
+ else
+ device_set_wakeup_enable(tp-udev-dev, false);
+}
+
static void rtl_phy_reset(struct r8152 *tp)
{
u16 data;
@@ -2002,10 +2080,6 @@ static void r8152b_enter_oob(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8152_RMS);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CFG_WOL);
- ocp_data |= MAGIC_EN;
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_CFG_WOL, ocp_data);
-
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CPCR);
ocp_data |= CPCR_RX_VLAN;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_CPCR, ocp_data);
@@ -2018,8 +2092,6 @@ static void r8152b_enter_oob(struct r8152 *tp)
ocp_data |= NOW_IS_OOB | DIS_MCU_CLROOB;
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL, ocp_data);
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CONFIG5, LAN_WAKE_EN);
-
rxdy_gated_en(tp, false);
ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
@@ -2217,10 +2289,6 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS,
[PATCH net-next 04/14] r8152: load the default MAC address
Except for RTL_VER_01, replace loading the MAC address from PLA_IDR
with from PLA_BACKUP. The default MAC address may be modified by
the other OS, so the PLA_IDR may be not the default MAC address.
The data in the PLA_BACKUP address of the RTL_VER_01 may be destoryed,
so load MAC address from PLA_IDR for RTL_VER_01.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4888e4f..3847c35 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -889,11 +889,26 @@ int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg,
gfp_t mem_flags);
static inline void set_ethernet_addr(struct r8152 *tp)
{
struct net_device *dev = tp-netdev;
+ int ret;
u8 node_id[8] = {0};
- if (pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id) 0)
+ if (tp-version == RTL_VER_01)
+ ret = pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id);
+ else
+ ret = pla_ocp_read(tp, PLA_BACKUP, sizeof(node_id), node_id);
+
+ if (ret 0) {
netif_notice(tp, probe, dev, inet addr fail\n);
- else {
+ } else {
+ if (tp-version != RTL_VER_01) {
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR,
+ CRWECR_CONFIG);
+ pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES,
+ sizeof(node_id), node_id);
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR,
+ CRWECR_NORAML);
+ }
+
memcpy(dev-dev_addr, node_id, dev-addr_len);
memcpy(dev-perm_addr, dev-dev_addr, dev-addr_len);
}
--
1.8.4.2
--
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
[PATCH net-next 00/14] r8152: improvement and new features
Change some flows or behavior to improve the efficiency or make the code readable. Besides, support WOL and runtime suspend. Hayes Wang (14): r8152: move some functions r8152: add three functions r8152: replace some types from int to bool r8152: load the default MAC address r8152: reduce the frequency of spin_lock r8152: clear BMCR_PDOWN r8152: combine PHY reset with set_speed r8152: move some functions from probe to open r8152: support WOL r8152: support runtime suspend r8152: disable teredo for RTL8152 r8152: replace netif_rx with netif_receive_skb r8152: set disable_hub_initiated_lpm r8152: support get_msglevel and set_msglevel drivers/net/usb/r8152.c | 711 +++- 1 file changed, 526 insertions(+), 185 deletions(-) -- 1.8.4.2 -- 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
[PATCH net-next 01/14] r8152: move some functions
Move the following functions which is for the further coding.
- rtl_clear_bp
- r8153_clear_bp
- r8153_teredo_off
- r8152b_disable_aldps
- r8152b_enable_aldps
- r8152b_hw_phy_cfg
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 106
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index d89dbe3..f042a85 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1721,6 +1721,59 @@ static void rtl8152_disable(struct r8152 *tp)
rtl8152_nic_reset(tp);
}
+static void rtl_clear_bp(struct r8152 *tp)
+{
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_0, 0);
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_2, 0);
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_4, 0);
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_6, 0);
+ ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_0, 0);
+ ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_2, 0);
+ ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_4, 0);
+ ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_6, 0);
+ mdelay(3);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_BP_BA, 0);
+ ocp_write_word(tp, MCU_TYPE_USB, USB_BP_BA, 0);
+}
+
+static void r8153_clear_bp(struct r8152 *tp)
+{
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_BP_EN, 0);
+ ocp_write_byte(tp, MCU_TYPE_USB, USB_BP_EN, 0);
+ rtl_clear_bp(tp);
+}
+
+static void r8153_teredo_off(struct r8152 *tp)
+{
+ u32 ocp_data;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TEREDO_CFG);
+ ocp_data = ~(TEREDO_SEL | TEREDO_RS_EVENT_MASK | OOB_TEREDO_EN);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_TEREDO_CFG, ocp_data);
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_WDT6_CTRL, WDT6_SET_MODE);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_REALWOW_TIMER, 0);
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TEREDO_TIMER, 0);
+}
+
+static void r8152b_disable_aldps(struct r8152 *tp)
+{
+ ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPDNPS | LINKENA | DIS_SDSAVE);
+ msleep(20);
+}
+
+static inline void r8152b_enable_aldps(struct r8152 *tp)
+{
+ ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPWRSAVE | ENPDNPS |
+ LINKENA | DIS_SDSAVE);
+}
+
+static void r8152b_hw_phy_cfg(struct r8152 *tp)
+{
+ r8152_mdio_write(tp, MII_BMCR, BMCR_ANENABLE);
+ r8152b_disable_aldps(tp);
+}
+
static void r8152b_exit_oob(struct r8152 *tp)
{
u32 ocp_data;
@@ -1865,18 +1918,6 @@ static void r8152b_enter_oob(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
}
-static void r8152b_disable_aldps(struct r8152 *tp)
-{
- ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPDNPS | LINKENA | DIS_SDSAVE);
- msleep(20);
-}
-
-static inline void r8152b_enable_aldps(struct r8152 *tp)
-{
- ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPWRSAVE | ENPDNPS |
- LINKENA | DIS_SDSAVE);
-}
-
static void r8153_hw_phy_cfg(struct r8152 *tp)
{
u32 ocp_data;
@@ -1961,19 +2002,6 @@ static void r8153_power_cut_en(struct r8152 *tp, int
enable)
ocp_write_word(tp, MCU_TYPE_USB, USB_MISC_0, ocp_data);
}
-static void r8153_teredo_off(struct r8152 *tp)
-{
- u32 ocp_data;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TEREDO_CFG);
- ocp_data = ~(TEREDO_SEL | TEREDO_RS_EVENT_MASK | OOB_TEREDO_EN);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_TEREDO_CFG, ocp_data);
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_WDT6_CTRL, WDT6_SET_MODE);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_REALWOW_TIMER, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TEREDO_TIMER, 0);
-}
-
static void r8153_first_init(struct r8152 *tp)
{
u32 ocp_data;
@@ -2308,28 +2336,6 @@ static int rtl8152_close(struct net_device *netdev)
return res;
}
-static void rtl_clear_bp(struct r8152 *tp)
-{
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_0, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_2, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_4, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_6, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_0, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_2, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_4, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_6, 0);
- mdelay(3);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_BP_BA, 0);
- ocp_write_word(tp, MCU_TYPE_USB, USB_BP_BA, 0);
-}
-
-static void r8153_clear_bp(struct r8152 *tp)
-{
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_BP_EN, 0);
- ocp_write_byte(tp, MCU_TYPE_USB, USB_BP_EN, 0);
- rtl_clear_bp(tp);
-}
-
static void r8152b_enable_eee(struct r8152 *tp)
{
u32 ocp_data;
@@ -2378,12 +2384,6 @@ static void r8152b_enable_fc(struct r8152 *tp)
r8152_mdio_write(tp, MII_ADVERTISE, anar);
}
-static void r8152b_hw_phy_cfg(struct r8152 *tp)
-{
-
Re: gadget support
W dniu 18.02.2014 14:15, Arturo Veras pisze: hi all In my PC have the kernel linux usb gadget support enabled but when i Why do you have usb gadget support in a PC in the first place? What are you trying to achieve? What you could achieve is for example to make your PC act as a mass storage device which can be connected to some PC host via USB. try to load the module: sudo modprobe g_ether FATAL: Error inserting g_ether (/lib/modules/3.13.2/kernel/drivers/usb/gadget/g_ether.ko): No such device Does your system have a USB device controller (UDC or OTG chip)? If not, the above is exactly what you should get. maybe my usb is not supported by the driver. I don't know. i have a NM10/ICH7 Family USB UHCI Controller UHCI is a host controller, not a device controller. You need a UDC/OTG chip in your system. If you don't have the required hardware, you can use the dummy_hcd driver, which combines a host and a device controllers emulated in software. But this is meant for playing with USB gadgets development; the dummy hcd is connected (in software) to the dummy udc so taking the example of mass storage you can make your PC act as a mass storage device connected to the very same PC acting both as a host and a device. AP -- 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
Re: USB 3380 using net2280 driver
Hi, *always* Cc the mailing list please. On Mon, Feb 17, 2014 at 04:43:11PM -0800, Amit Uttamchandani wrote: I was looking at the changes for net2280.c and saw your name come up in a few of the more recent changes. I wanted to know, are you aware of support for PLXs USB 338o using this net2280 driver? no, those are two completely different controllers. Linux doesn't support USB 3380 as of today. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: host: xhci-plat: Use module_platform_driver()
On Fri, Jan 31, 2014 at 02:27:09AM -0200, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Using module_platform_driver() can make the code simpler.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Acked-by: Felipe Balbi ba...@ti.com
---
Build-tested only
drivers/usb/host/xhci-plat.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 8abda5c..488e3d4 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -242,13 +242,4 @@ static struct platform_driver usb_xhci_driver = {
},
};
MODULE_ALIAS(platform:xhci-hcd);
-
-int xhci_register_plat(void)
-{
- return platform_driver_register(usb_xhci_driver);
-}
-
-void xhci_unregister_plat(void)
-{
- platform_driver_unregister(usb_xhci_driver);
-}
+module_platform_driver(usb_xhci_driver);
--
1.8.1.2
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
On 02/14/2014 03:33 PM, Lee Jones wrote:
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 60a3bed..ce620a8 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
- omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
You can't do that. These changes will have to be in the same patch as
the core change i.e. where they are initialised.
I'm not touching them anywhere in this series. When core changes are you
referring to?
The ones in:
arch/arm/mach-omap2/cclock3xxx_data.c
OK, right. They are now no longer needed so I'll get rid of them.
In fact that change should either be in a separate patch or combined with PATCH
2
in this series. What do you suggest?
cheers,
-roger
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
--
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
Re: [PATCH v2 1/2] usb: host: xhci-plat: Use module_platform_driver()
On Fri, Jan 31, 2014 at 02:29:52AM -0200, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Using module_platform_driver() can make the code simpler.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Acked-by: Felipe Balbi ba...@ti.com
---
Build-tested only
Changes since v1:
- Mark the patch as 1/2
drivers/usb/host/xhci-plat.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 8abda5c..488e3d4 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -242,13 +242,4 @@ static struct platform_driver usb_xhci_driver = {
},
};
MODULE_ALIAS(platform:xhci-hcd);
-
-int xhci_register_plat(void)
-{
- return platform_driver_register(usb_xhci_driver);
-}
-
-void xhci_unregister_plat(void)
-{
- platform_driver_unregister(usb_xhci_driver);
-}
+module_platform_driver(usb_xhci_driver);
--
1.8.1.2
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH Resend 2/2] usb: gadget: s3c-hsudc: Remove unused label
On Mon, Feb 03, 2014 at 01:59:39PM +0530, Sachin Kamat wrote: Fixes the following compilation warning: drivers/usb/gadget/s3c-hsudc.c: In function ‘s3c_hsudc_probe’: drivers/usb/gadget/s3c-hsudc.c:1347:1: warning: label ‘err_add_device’ defined but not used [-Wunused-label] Signed-off-by: Sachin Kamat sachin.ka...@linaro.org What about this one ? --- drivers/usb/gadget/s3c-hsudc.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c index ea4bbfe72ec0..10c6a128250c 100644 --- a/drivers/usb/gadget/s3c-hsudc.c +++ b/drivers/usb/gadget/s3c-hsudc.c @@ -1344,7 +1344,6 @@ static int s3c_hsudc_probe(struct platform_device *pdev) return 0; err_add_udc: -err_add_device: clk_disable(hsudc-uclk); err_res: if (!IS_ERR_OR_NULL(hsudc-transceiver)) -- 1.7.9.5 -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/2] usb: host: xhci-plat: Fix build warning when !CONFIG_PM
On Fri, Jan 31, 2014 at 02:29:53AM -0200, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Building keystone_defconfig leads to the following build warnings:
drivers/usb/host/xhci-plat.c:203:12: warning: 'xhci_plat_suspend' defined but
not used [-Wunused-function]
drivers/usb/host/xhci-plat.c:211:12: warning: 'xhci_plat_resume' defined but
not used [-Wunused-function]
Cc: Olof Johansson o...@lixom.net
Reported-by: Olof Johansson o...@lixom.net
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Acked-by: Felipe Balbi ba...@ti.com
---
Build-tested only
Changes since v1:
- none
drivers/usb/host/xhci-plat.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 9c2e583..104e48f 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -199,7 +199,7 @@ static int xhci_plat_remove(struct platform_device *dev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int xhci_plat_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
@@ -215,14 +215,9 @@ static int xhci_plat_resume(struct device *dev)
return xhci_resume(xhci, 0);
}
+#endif /* CONFIG_PM_SLEEP */
-static const struct dev_pm_ops xhci_plat_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
-};
-#define DEV_PM_OPS (xhci_plat_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(xhci_plat_pm_ops, xhci_plat_suspend,
xhci_plat_resume);
#ifdef CONFIG_OF
static const struct of_device_id usb_xhci_of_match[] = {
@@ -237,7 +232,7 @@ static struct platform_driver usb_xhci_driver = {
.remove = xhci_plat_remove,
.driver = {
.name = xhci-hcd,
- .pm = DEV_PM_OPS,
+ .pm = xhci_plat_pm_ops,
.of_match_table = of_match_ptr(usb_xhci_of_match),
},
};
--
1.8.1.2
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH Resend 1/2] usb: gadget: s3c2410_udc: Fix build error
On Mon, Feb 03, 2014 at 01:59:38PM +0530, Sachin Kamat wrote: Pass value instead of address as expected by 'usb_ep_set_maxpacket_limit'. Fixes the following compilation error introduced by commit e117e742d310 (usb: gadget: add maxpacket_limit field to struct usb_ep): drivers/usb/gadget/s3c2410_udc.c: In function ‘s3c2410_udc_reinit’: drivers/usb/gadget/s3c2410_udc.c:1632:3: error: cannot take address of bit-field ‘maxpacket’ usb_ep_set_maxpacket_limit(ep-ep, ep-ep.maxpacket); Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Reviewed-by: Robert Baldyga r.bald...@samsung.com is this still needed for -rc4 ? --- drivers/usb/gadget/s3c2410_udc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c index f04b2c3154de..dd9678f85c58 100644 --- a/drivers/usb/gadget/s3c2410_udc.c +++ b/drivers/usb/gadget/s3c2410_udc.c @@ -1629,7 +1629,7 @@ static void s3c2410_udc_reinit(struct s3c2410_udc *dev) ep-ep.desc = NULL; ep-halted = 0; INIT_LIST_HEAD(ep-queue); - usb_ep_set_maxpacket_limit(ep-ep, ep-ep.maxpacket); + usb_ep_set_maxpacket_limit(ep-ep, ep-ep.maxpacket); } } -- 1.7.9.5 -- balbi signature.asc Description: Digital signature
Re: Remove dependency on BROKEN from drives/usb/musb/da8xx.c glue
On Mon, Feb 03, 2014 at 11:57:32AM +0100, Christian Riesch wrote: Hi, commit 787f5627bec80094db487bfcb401e9744f181aed usb: musb: make davinci and da8xx glues depend on BROKEN Signed-off-by: Felipe Balbi ba...@ti.com adds a dependency of the drivers/usb/musb/da8xx.c driver to BROKEN. I have successfully tested this driver with kernel 3.13 on a custom Texas Instruments AM1808 board in gadget mode, RNDIS network gadget. Therefore I would like to see this BROKEN dependency removed. What would be required for removing this dependency? Is removing the include of the mach/da8xx.h header sufficient? In the mailing list yeah. Remove mach/da8xx.h and make sure it builds cleanly on other arches. discussion on the patch, Sergei Shtylyov mentioned that this would mean duplicating the definitions. Would this be ok, just copying them to drivers/usb/musb/da8xx.c? whatever is used by mach and driver should be sitting in a public header which both include. Say something like linux/usb/musb-da8xx.h or something similar. -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: gadget: remove unused parameter from udc_stop in usb_gadget_ops
On Tue, Dec 17, 2013 at 09:40:35AM +0100, Robert Baldyga wrote: This patch removes parameter struct usb_gadget_driver* from udc_stop() function in struct usb_gadget_ops. This parameter is useless in udc_stop() function, and UDC drivers can work well without it, so removeing it makes code clearer. This patch modifies UDC drivers to make them compatible witch changed API. It also modifies udc-core.c, where udc_stop() function is used. Signed-off-by: Robert Baldyga r.bald...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com I really need Tested-bys before I can apply this patch. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: dwc3: fix wrong bit mask in dwc3_event_devt
Hi,
On Tue, Jan 07, 2014 at 05:45:50PM +0800, Huang Rui wrote:
Per dwc3 2.70a spec in the Device-Specific Event (DEVT), the field of
Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits
not 8 bits. And the following reserved field uses [31:25] bits not
[31:24] bits, and it has 7 bits.
So in dwc3_event_devt, the bit mask should be:
event_info[24:16] 9 bits
reserved31_25 [31:25] 7 bits
This patch should be backported to kernels as old as 3.2, that contain
the commit 72246da40f3719af3bfd104a2365b32537c27d83 usb: Introduce
DesignWare USB3 DRD Driver.
This paragraph shouldn't be in the commit log (I'll fix it, don't
worry), also this doesn't really need to be backported all the way back
since this was changed between 2.00a and 2.30a version of the core,
which didn't even exist back then.
Cc: sta...@vger.kernel.org
Signed-off-by: Huang Rui ray.hu...@amd.com
---
Changes from v1 - v2:
- Add CC stable mail list.
drivers/usb/dwc3/core.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index f8af8d4..69c4583 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -815,15 +815,15 @@ struct dwc3_event_depevt {
* 12 - VndrDevTstRcved
* @reserved15_12: Reserved, not used
* @event_info: Information about this event
- * @reserved31_24: Reserved, not used
+ * @reserved31_25: Reserved, not used
*/
struct dwc3_event_devt {
u32 one_bit:1;
u32 device_event:7;
u32 type:4;
u32 reserved15_12:4;
- u32 event_info:8;
- u32 reserved31_24:8;
+ u32 event_info:9;
+ u32 reserved31_25:7;
} __packed;
/**
--
1.8.1.2
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/6] usb: gadget: gr_udc: Make struct platform_device variable name clearer
On Thu, Jan 09, 2014 at 11:54:13AM +0100, Andreas Larsson wrote:
Rename struct platform_device pointers from ofdev to pdev for clarity.
Suggested by Mark Rutland.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
drivers/usb/gadget/gr_udc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 914cbd8..e66dcf0 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -2071,9 +2071,9 @@ static int gr_udc_init(struct gr_udc *dev)
return 0;
}
-static int gr_remove(struct platform_device *ofdev)
+static int gr_remove(struct platform_device *pdev)
{
- struct gr_udc *dev = dev_get_drvdata(ofdev-dev);
+ struct gr_udc *dev = dev_get_drvdata(pdev-dev);
you can use platform_get_drvdata()
@@ -2083,7 +2083,7 @@ static int gr_remove(struct platform_device *ofdev)
gr_dfs_delete(dev);
if (dev-desc_pool)
dma_pool_destroy(dev-desc_pool);
- dev_set_drvdata(ofdev-dev, NULL);
+ dev_set_drvdata(pdev-dev, NULL);
and platform_set_drvdata()
--
balbi
signature.asc
Description: Digital signature
Re: USB 3380 using net2280 driver
On Tue, Feb 18, 2014 at 7:12 AM, Felipe Balbi ba...@ti.com wrote: On Mon, Feb 17, 2014 at 04:43:11PM -0800, Amit Uttamchandani wrote: I was looking at the changes for net2280.c and saw your name come up in a few of the more recent changes. I wanted to know, are you aware of support for PLXs USB 338o using this net2280 driver? no, those are two completely different controllers. Linux doesn't support USB 3380 as of today. It might be possible to use this code as a starting point: http://patchwork.openwrt.org/patch/2889/ -- 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
Re: [PATCH v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 60a3bed..ce620a8 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
-omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
You can't do that. These changes will have to be in the same patch as
the core change i.e. where they are initialised.
I'm not touching them anywhere in this series. When core changes are you
referring to?
The ones in:
arch/arm/mach-omap2/cclock3xxx_data.c
OK, right. They are now no longer needed so I'll get rid of them.
In fact that change should either be in a separate patch or combined with
PATCH 2
in this series. What do you suggest?
A separate patch will do fine.
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
goto err_mem;
}
-omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
goto err_mem;
}
-omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
Re: [PATCH 2/2] USB: at91: using USBA_NR_DMAS for DMA channels
On Fri, Jan 17, 2014 at 10:59:25AM +0800, Bo Shen wrote:
When the SoC is earlier than sama5d3 SoC, which have the same number
endpoints and DMAs. However for sama5d3 SoC, it has different number
for endpoints and DMAs. So, define USBA_NR_DMAs for DMA channels
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/atmel_usba_udc.c | 2 +-
drivers/usb/gadget/atmel_usba_udc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index 7e67a81..5cded1c 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1661,7 +1661,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (dma_status) {
int i;
- for (i = 1; i USBA_NR_ENDPOINTS; i++)
+ for (i = 1; i USBA_NR_DMAS; i++)
if (dma_status (1 i))
usba_dma_irq(udc, udc-usba_ep[i]);
}
diff --git a/drivers/usb/gadget/atmel_usba_udc.h
b/drivers/usb/gadget/atmel_usba_udc.h
index 2922db5..a70706e 100644
--- a/drivers/usb/gadget/atmel_usba_udc.h
+++ b/drivers/usb/gadget/atmel_usba_udc.h
@@ -210,7 +210,7 @@
#define USBA_FIFO_BASE(x)((x) 16)
/* Synth parameters */
-#define USBA_NR_ENDPOINTS7
+#define USBA_NR_DMAS 7
what's the difference ? You just renamed this macro. Also, please
clarify a bit your commit log.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote:
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP
On Fri, Jan 17, 2014 at 12:26:50PM -0600, Josh Cartwright wrote:
On Fri, Jan 17, 2014 at 11:58:51AM -0600, Josh Cartwright wrote:
Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.
Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().
While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.
This address the following errors Russell King has hit doing randconfig
builds:
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of
function 'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of
function 'msm_otg_resume'
Cc: Ivan T. Ivanov iiva...@mm-sol.com
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Josh Cartwright jo...@codeaurora.org
---
v1-v2: Change conditional to simply CONFIG_PM (thanks ccov and khilman!)
drivers/usb/phy/phy-msm-usb.c | 57
---
1 file changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8546c8d..5b169a7 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
[..]
@@ -440,7 +414,32 @@ static int msm_otg_reset(struct usb_phy *phy)
#define PHY_SUSPEND_TIMEOUT_USEC (500 * 1000)
#define PHY_RESUME_TIMEOUT_USEC(100 * 1000)
-#ifdef CONFIG_PM_SLEEP
+#if CONFIG_PM
*sigh*. This, of course, should have been #ifdef CONFIG_PM. Fixed
v3 below.
sorry, please git send-email it properly.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/6] usb: otg-fsm: add HNP polling operation function.
On Mon, Jan 20, 2014 at 10:00:15AM +0800, Li Jun wrote:
This patch adds HNP polling operation function for OTG fsm.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/phy/phy-fsm-usb.c |2 ++
include/linux/usb/otg-fsm.h |9 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/phy/phy-fsm-usb.c b/drivers/usb/phy/phy-fsm-usb.c
index c47e5a6..ef91961 100644
--- a/drivers/usb/phy/phy-fsm-usb.c
+++ b/drivers/usb/phy/phy-fsm-usb.c
@@ -169,6 +169,7 @@ static int otg_set_state(struct otg_fsm *fsm, enum
usb_otg_state new_state)
otg_set_protocol(fsm, PROTO_HOST);
usb_bus_start_enum(fsm-otg-host,
fsm-otg-host-otg_port);
+ otg_start_hnp_polling(fsm);
break;
case OTG_STATE_A_IDLE:
otg_drv_vbus(fsm, 0);
@@ -203,6 +204,7 @@ static int otg_set_state(struct otg_fsm *fsm, enum
usb_otg_state new_state)
*/
if (!fsm-a_bus_req || fsm-a_suspend_req_inf)
otg_add_timer(fsm, A_WAIT_ENUM);
+ otg_start_hnp_polling(fsm);
break;
case OTG_STATE_A_SUSPEND:
otg_drv_vbus(fsm, 1);
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index b6ba1bf..79c6ee8 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -127,6 +127,7 @@ struct otg_fsm_ops {
void(*start_pulse)(struct otg_fsm *fsm);
void(*start_adp_prb)(struct otg_fsm *fsm);
void(*start_adp_sns)(struct otg_fsm *fsm);
+ void(*start_hnp_polling)(struct otg_fsm *fsm);
why ? HNP polling is a generic operation, is it not ? Which means you
shouldn't need to add this function pointer here, just implement a
generic helper function, ideally in usb-common.c
Also, I need to see a patch adding proper kernel doc to those
structures.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP
On Tue, Feb 18, 2014 at 10:24:16AM -0600, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 12:26:50PM -0600, Josh Cartwright wrote:
On Fri, Jan 17, 2014 at 11:58:51AM -0600, Josh Cartwright wrote:
Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.
Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().
While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.
This address the following errors Russell King has hit doing randconfig
builds:
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of
function 'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of
function 'msm_otg_resume'
Cc: Ivan T. Ivanov iiva...@mm-sol.com
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Josh Cartwright jo...@codeaurora.org
---
v1-v2: Change conditional to simply CONFIG_PM (thanks ccov and khilman!)
drivers/usb/phy/phy-msm-usb.c | 57
---
1 file changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8546c8d..5b169a7 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
[..]
@@ -440,7 +414,32 @@ static int msm_otg_reset(struct usb_phy *phy)
#define PHY_SUSPEND_TIMEOUT_USEC (500 * 1000)
#define PHY_RESUME_TIMEOUT_USEC (100 * 1000)
-#ifdef CONFIG_PM_SLEEP
+#if CONFIG_PM
*sigh*. This, of course, should have been #ifdef CONFIG_PM. Fixed
v3 below.
sorry, please git send-email it properly.
No problem, will do. FWIW, it's applicable with git am --scissors.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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
Re: [PATCH] usb: musb: correct use of schedule_delayed_work()
On Wed, Feb 05, 2014 at 03:34:18PM +0100, Daniel Mack wrote: schedule_delayed_work() takes the delay in jiffies, not msecs. This bug slipped in with the recent reset logic cleanup (8ed1fb790ea: usb: musb: finish suspend/reset work independently from musb_hub_control()). Signed-off-by: Daniel Mack dan...@zonque.org doesn't apply. Please refresh against my testing/fixes (give me about an hour until I push the updated branch though). -- balbi signature.asc Description: Digital signature
[PATCH RESEND v3] usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP
Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.
Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().
While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.
This address the following errors Russell King has hit doing randconfig
builds:
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function
'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function
'msm_otg_resume'
Cc: Ivan T. Ivanov iiva...@mm-sol.com
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Josh Cartwright jo...@codeaurora.org
---
drivers/usb/phy/phy-msm-usb.c | 57 ---
1 file changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 64c9d14e..5b37b81 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -159,32 +159,6 @@ put_3p3:
return rc;
}
-#ifdef CONFIG_PM_SLEEP
-#define USB_PHY_SUSP_DIG_VOL 50
-static int msm_hsusb_config_vddcx(int high)
-{
- int max_vol = USB_PHY_VDD_DIG_VOL_MAX;
- int min_vol;
- int ret;
-
- if (high)
- min_vol = USB_PHY_VDD_DIG_VOL_MIN;
- else
- min_vol = USB_PHY_SUSP_DIG_VOL;
-
- ret = regulator_set_voltage(hsusb_vddcx, min_vol, max_vol);
- if (ret) {
- pr_err(%s: unable to set the voltage for regulator
- HSUSB_VDDCX\n, __func__);
- return ret;
- }
-
- pr_debug(%s: min_vol:%d max_vol:%d\n, __func__, min_vol, max_vol);
-
- return ret;
-}
-#endif
-
static int msm_hsusb_ldo_set_mode(int on)
{
int ret = 0;
@@ -440,7 +414,32 @@ static int msm_otg_reset(struct usb_phy *phy)
#define PHY_SUSPEND_TIMEOUT_USEC (500 * 1000)
#define PHY_RESUME_TIMEOUT_USEC(100 * 1000)
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
+
+#define USB_PHY_SUSP_DIG_VOL 50
+static int msm_hsusb_config_vddcx(int high)
+{
+ int max_vol = USB_PHY_VDD_DIG_VOL_MAX;
+ int min_vol;
+ int ret;
+
+ if (high)
+ min_vol = USB_PHY_VDD_DIG_VOL_MIN;
+ else
+ min_vol = USB_PHY_SUSP_DIG_VOL;
+
+ ret = regulator_set_voltage(hsusb_vddcx, min_vol, max_vol);
+ if (ret) {
+ pr_err(%s: unable to set the voltage for regulator
+ HSUSB_VDDCX\n, __func__);
+ return ret;
+ }
+
+ pr_debug(%s: min_vol:%d max_vol:%d\n, __func__, min_vol, max_vol);
+
+ return ret;
+}
+
static int msm_otg_suspend(struct msm_otg *motg)
{
struct usb_phy *phy = motg-phy;
@@ -1734,22 +1733,18 @@ static int msm_otg_pm_resume(struct device *dev)
}
#endif
-#ifdef CONFIG_PM
static const struct dev_pm_ops msm_otg_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(msm_otg_pm_suspend, msm_otg_pm_resume)
SET_RUNTIME_PM_OPS(msm_otg_runtime_suspend, msm_otg_runtime_resume,
msm_otg_runtime_idle)
};
-#endif
static struct platform_driver msm_otg_driver = {
.remove = msm_otg_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
-#ifdef CONFIG_PM
.pm = msm_otg_dev_pm_ops,
-#endif
},
};
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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
Re: [PATCH] usb: musb: correct use of schedule_delayed_work()
On 02/18/2014 05:33 PM, Felipe Balbi wrote: On Wed, Feb 05, 2014 at 03:34:18PM +0100, Daniel Mack wrote: schedule_delayed_work() takes the delay in jiffies, not msecs. This bug slipped in with the recent reset logic cleanup (8ed1fb790ea: usb: musb: finish suspend/reset work independently from musb_hub_control()). Signed-off-by: Daniel Mack dan...@zonque.org doesn't apply. Please refresh against my testing/fixes (give me about an hour until I push the updated branch though). Oh, I'm sorry. Greg said he would queue them up as you were on vacation, so I don't know what's the status here. Greg, can you still drop the patches so they can go through Felipe's tree? Might be best not to cause merge trouble here ... Thanks, Daniel signature.asc Description: OpenPGP digital signature
Re: [PATCH] usb: gadget: fix NULL pointer dereference
On Fri, Jan 17, 2014 at 05:04:55PM +0100, Michal Nazarewicz wrote: On Thu, Jan 16 2014, Andrzej Pietrasiewicz wrote: Fix possible NULL pointer dereference introduced in 219580e64f035bb9018dbb08d340f90b0ac50f8c usb: f_fs: check quirk to pad epout buf size when not aligned to maxpacketsize after 3.13-rc1. In cases we do wait with: wait_event_interruptible(epfile-wait, (ep = epfile-ep)); for endpoint to be enabled, functionfs_bind() has not been called yet and epfile-ffs-gadget is still NULL and the automatic variable 'gadget' has been initialized with NULL at the point of its definition. Later on it is used as a parameter to: usb_ep_align_maybe(gadget, ep-ep, len) which in turn dereferences it. This patch fixes it by moving the actual assignment to the local 'gadget' variable after the potential waiting has completed. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Acked-by: Michal Nazarewicz min...@mina86.com But since gadget is only used in the “if (!halt)” part of the code, could you simply move definition of the variable inside the if? should I wait for another revision ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: fix NULL pointer dereference
On Tue, Feb 18, 2014 at 10:40:12AM -0600, Felipe Balbi wrote: On Fri, Jan 17, 2014 at 05:04:55PM +0100, Michal Nazarewicz wrote: On Thu, Jan 16 2014, Andrzej Pietrasiewicz wrote: Fix possible NULL pointer dereference introduced in 219580e64f035bb9018dbb08d340f90b0ac50f8c usb: f_fs: check quirk to pad epout buf size when not aligned to maxpacketsize after 3.13-rc1. In cases we do wait with: wait_event_interruptible(epfile-wait, (ep = epfile-ep)); for endpoint to be enabled, functionfs_bind() has not been called yet and epfile-ffs-gadget is still NULL and the automatic variable 'gadget' has been initialized with NULL at the point of its definition. Later on it is used as a parameter to: usb_ep_align_maybe(gadget, ep-ep, len) which in turn dereferences it. This patch fixes it by moving the actual assignment to the local 'gadget' variable after the potential waiting has completed. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Acked-by: Michal Nazarewicz min...@mina86.com But since gadget is only used in the “if (!halt)” part of the code, could you simply move definition of the variable inside the if? should I wait for another revision ? nevermind, you already sent it ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP
On Tue, Feb 18, 2014 at 10:33:21AM -0600, Josh Cartwright wrote:
On Tue, Feb 18, 2014 at 10:24:16AM -0600, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 12:26:50PM -0600, Josh Cartwright wrote:
On Fri, Jan 17, 2014 at 11:58:51AM -0600, Josh Cartwright wrote:
Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.
Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().
While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.
This address the following errors Russell King has hit doing randconfig
builds:
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of
function 'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of
function 'msm_otg_resume'
Cc: Ivan T. Ivanov iiva...@mm-sol.com
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Josh Cartwright jo...@codeaurora.org
---
v1-v2: Change conditional to simply CONFIG_PM (thanks ccov and
khilman!)
drivers/usb/phy/phy-msm-usb.c | 57
---
1 file changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c
b/drivers/usb/phy/phy-msm-usb.c
index 8546c8d..5b169a7 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
[..]
@@ -440,7 +414,32 @@ static int msm_otg_reset(struct usb_phy *phy)
#define PHY_SUSPEND_TIMEOUT_USEC (500 * 1000)
#define PHY_RESUME_TIMEOUT_USEC(100 * 1000)
-#ifdef CONFIG_PM_SLEEP
+#if CONFIG_PM
*sigh*. This, of course, should have been #ifdef CONFIG_PM. Fixed
v3 below.
sorry, please git send-email it properly.
No problem, will do. FWIW, it's applicable with git am --scissors.
ahaa, I didn't know about that option. Thanks :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: musb: correct use of schedule_delayed_work()
On Tue, Feb 18, 2014 at 05:41:12PM +0100, Daniel Mack wrote: On 02/18/2014 05:33 PM, Felipe Balbi wrote: On Wed, Feb 05, 2014 at 03:34:18PM +0100, Daniel Mack wrote: schedule_delayed_work() takes the delay in jiffies, not msecs. This bug slipped in with the recent reset logic cleanup (8ed1fb790ea: usb: musb: finish suspend/reset work independently from musb_hub_control()). Signed-off-by: Daniel Mack dan...@zonque.org doesn't apply. Please refresh against my testing/fixes (give me about an hour until I push the updated branch though). Oh, I'm sorry. Greg said he would queue them up as you were on vacation, so I don't know what's the status here. Greg, can you still drop the patches so they can go through Felipe's tree? Might be best not to cause merge trouble here ... If it's already in Greg's tree, don't worry ;-) I'm just trying to catch up with my inbox ;-) cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v9 01/12] usb: doc: phy-mxs: Add more compatible strings
On Fri, Dec 27, 2013 at 10:38:30AM +0800, Peter Chen wrote: Add fsl,imx6q-usbphy for imx6dq and imx6dl, add fsl,imx6sl-usbphy for imx6sl. Signed-off-by: Peter Chen peter.c...@freescale.com anybody from DT to give me an Acked-by ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v9 11/12] usb: phy-mxs: Add system suspend/resume API
On Fri, Dec 27, 2013 at 10:38:40AM +0800, Peter Chen wrote:
We need this to keep PHY's power on or off during the system
suspend mode. If we need to enable USB wakeup, then we
must keep PHY's power being on during the system suspend mode.
Otherwise, we need to keep PHY's power being off to save power.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/phy/phy-mxs-usb.c | 61
+
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 96aac05..53b8dad 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -57,6 +57,10 @@
#define BM_USBPHY_DEBUG_CLKGATE BIT(30)
/* Anatop Registers */
+#define ANADIG_ANA_MISC0 0x150
+#define ANADIG_ANA_MISC0_SET 0x154
+#define ANADIG_ANA_MISC0_CLR 0x158
+
#define ANADIG_USB1_VBUS_DET_STAT0x1c0
#define ANADIG_USB2_VBUS_DET_STAT0x220
@@ -65,6 +69,9 @@
#define ANADIG_USB2_LOOPBACK_SET 0x244
#define ANADIG_USB2_LOOPBACK_CLR 0x248
+#define BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG BIT(12)
+#define BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG_SL BIT(11)
+
#define BM_ANADIG_USB1_VBUS_DET_STAT_VBUS_VALID BIT(3)
#define BM_ANADIG_USB2_VBUS_DET_STAT_VBUS_VALID BIT(3)
@@ -134,6 +141,16 @@ struct mxs_phy {
int port_id;
};
+static inline bool is_imx6q_phy(struct mxs_phy *mxs_phy)
+{
+ return mxs_phy-data == imx6q_phy_data;
+}
+
+static inline bool is_imx6sl_phy(struct mxs_phy *mxs_phy)
+{
+ return mxs_phy-data == imx6sl_phy_data;
+}
+
static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
{
int ret;
@@ -382,6 +399,8 @@ static int mxs_phy_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mxs_phy);
+ device_set_wakeup_capable(pdev-dev, true);
+
ret = usb_add_phy_dev(mxs_phy-phy);
if (ret)
return ret;
@@ -398,6 +417,47 @@ static int mxs_phy_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
please use CONFIG_PM instead.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 2/3] usb: chipidea: msm: Add device tree support
Hello. On 02/18/2014 04:21 PM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Allows controller to be specified via device tree. Pass PHY phandle specified in DT to core driver. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com --- drivers/usb/chipidea/ci_hdrc_msm.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) You also need to describe the binding you're creating in Documentation/devicetree/bindings/usb/file.txt. WBR, Sergei -- 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
Re: [PATCH] u_ether: move receiving to RX workqueue
Hi,
On Mon, Feb 17, 2014 at 02:26:54PM +0800, Clanlab (Taiwan) Linux Project wrote:
@@ -1168,5 +1191,23 @@ void gether_disconnect(struct gether *link)
}
EXPORT_SYMBOL(gether_disconnect);
+static int __init gether_init(void)
+{
+ gether_wq = create_singlethread_workqueue(gether);
+ if (gether_wq == NULL) {
+ pr_err(Cannot initialize work queue\n);
+ return -ENOMEM;
+ }
+ return 0;
+}
+module_init(gether_init);
+
+static void __exit gether_exit(void)
+{
+ destroy_workqueue(gether_wq);
+
trailing whitespace.
+}
+module_exit(gether_exit);
this is actually supposed to be a library which gets linked against the
actual function module. You need to find a better way to ensure
destroy_workqueue is called.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote:
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
!root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled.
--
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
Re: [EHCI Debug Port] Linux fails to setup EHCI debug port
On Tue, Feb 18, 2014 at 02:46:00PM +0800, Lu, Baolu wrote: Hi list, Linux kernel (3.12.8) fails to setup EHCI debug port on my Sandy Bridge server. This seems to be a normal thing as I tried on other machines and got the same result. Do you have a EHCI debug connector to attach to it? That is required in order to be able to enable this, it's a separate device you must plug into the machine. thanks, greg k-h -- 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
Re: [EHCI Debug Port] Linux fails to setup EHCI debug port
On Tue, Feb 18, 2014 at 09:01:29AM -0800, Greg KH wrote: On Tue, Feb 18, 2014 at 02:46:00PM +0800, Lu, Baolu wrote: Hi list, Linux kernel (3.12.8) fails to setup EHCI debug port on my Sandy Bridge server. This seems to be a normal thing as I tried on other machines and got the same result. Do you have a EHCI debug connector to attach to it? That is required in you can make one, if you wish: http://www.coreboot.org/DIY_EHCI_debug_dongle -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 08:59:11AM -0800, Greg KH wrote:
On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote:
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
!root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled.
in that case, files will be created on parent directory right ? If we
pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in
__create_file().
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 2/3] usb: chipidea: msm: Add device tree support
Hi, On Tue, 2014-02-18 at 20:53 +0300, Sergei Shtylyov wrote: Hello. On 02/18/2014 04:21 PM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Allows controller to be specified via device tree. Pass PHY phandle specified in DT to core driver. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com --- drivers/usb/chipidea/ci_hdrc_msm.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) You also need to describe the binding you're creating in Documentation/devicetree/bindings/usb/file.txt. Did you check [PATCH v2 1/3]? Regards, Ivan WBR, Sergei -- 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
Re: [PATCH v2 2/3] usb: chipidea: msm: Add device tree support
On Tue, 2014-02-18 at 08:08 -0600, Josh Cartwright wrote:
Hey Ivan-
Nit below.
On Tue, Feb 18, 2014 at 03:21:20PM +0200, Ivan T. Ivanov wrote:
+static struct of_device_id msm_ci_dt_match[] = {
const?
Thanks, will do.
Regards,
Ivan
+ { .compatible = qcom,ci-hdrc, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, msm_ci_dt_match);
--
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
Re: [PATCH net-next 07/14] r8152: combine PHY reset with set_speed
Hi Hayes,
2014-02-18 5:49 GMT-08:00 Hayes Wang hayesw...@realtek.com:
PHY reset is necessary after some hw settings. However, it would
cause the linking down, and so does the set_speed function. Combine
the PHY reset with set_speed function. That could reduce the frequency
of linking down and accessing the PHY register.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 57
++---
1 file changed, 45 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c7bae39..b3155da 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -436,6 +436,7 @@ enum rtl8152_flags {
RTL8152_SET_RX_MODE,
WORK_ENABLE,
RTL8152_LINK_CHG,
+ PHY_RESET,
};
/* Define these values to match your device */
@@ -1796,6 +1797,29 @@ static void r8152_power_cut_en(struct r8152 *tp, bool
enable)
}
+static void rtl_phy_reset(struct r8152 *tp)
+{
+ u16 data;
+ int i;
+
+ clear_bit(PHY_RESET, tp-flags);
+
+ data = r8152_mdio_read(tp, MII_BMCR);
+
+ /* don't reset again before the previous one complete */
+ if (data BMCR_RESET)
+ return;
+
+ data |= BMCR_RESET;
+ r8152_mdio_write(tp, MII_BMCR, data);
+
+ for (i = 0; i 50; i++) {
+ msleep(20);
+ if ((r8152_mdio_read(tp, MII_BMCR) BMCR_RESET) == 0)
+ break;
+ }
+}
If you implemented libphy in the driver you would not have to
duplicate that and you could use phy_init_hw() or
genphy_soft_reset() to perform the BMCR-based software reset.
+
static void rtl_clear_bp(struct r8152 *tp)
{
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_0, 0);
@@ -1854,6 +1878,7 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
}
r8152b_disable_aldps(tp);
+ set_bit(PHY_RESET, tp-flags);
}
static void r8152b_exit_oob(struct r8152 *tp)
@@ -2042,6 +2067,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
data = sram_read(tp, SRAM_10M_AMP2);
data |= AMP_DN;
sram_write(tp, SRAM_10M_AMP2, data);
+
+ set_bit(PHY_RESET, tp-flags);
}
static void r8153_u1u2en(struct r8152 *tp, bool enable)
@@ -2295,12 +2322,26 @@ static int rtl8152_set_speed(struct r8152 *tp, u8
autoneg, u16 speed, u8 duplex)
bmcr = BMCR_ANENABLE | BMCR_ANRESTART;
}
+ if (test_bit(PHY_RESET, tp-flags))
+ bmcr |= BMCR_RESET;
+
if (tp-mii.supports_gmii)
r8152_mdio_write(tp, MII_CTRL1000, gbcr);
r8152_mdio_write(tp, MII_ADVERTISE, anar);
r8152_mdio_write(tp, MII_BMCR, bmcr);
+ if (test_bit(PHY_RESET, tp-flags)) {
+ int i;
+
+ clear_bit(PHY_RESET, tp-flags);
+ for (i = 0; i 50; i++) {
+ msleep(20);
+ if ((r8152_mdio_read(tp, MII_BMCR) BMCR_RESET) == 0)
+ break;
+ }
+ }
+
out:
return ret;
@@ -2364,6 +2405,10 @@ static void rtl_work_func_t(struct work_struct *work)
if (test_bit(RTL8152_SET_RX_MODE, tp-flags))
_rtl8152_set_rx_mode(tp-netdev);
+
+ if (test_bit(PHY_RESET, tp-flags))
+ rtl_phy_reset(tp);
+
out1:
return;
}
@@ -2459,7 +2504,6 @@ static void r8152b_enable_fc(struct r8152 *tp)
static void r8152b_init(struct r8152 *tp)
{
u32 ocp_data;
- int i;
rtl_clear_bp(tp);
@@ -2491,14 +2535,6 @@ static void r8152b_init(struct r8152 *tp)
r8152b_enable_aldps(tp);
r8152b_enable_fc(tp);
- r8152_mdio_write(tp, MII_BMCR, BMCR_RESET | BMCR_ANENABLE |
- BMCR_ANRESTART);
- for (i = 0; i 100; i++) {
- udelay(100);
- if (!(r8152_mdio_read(tp, MII_BMCR) BMCR_RESET))
- break;
- }
-
/* enable rx aggregation */
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL);
ocp_data = ~RX_AGG_DISABLE;
@@ -2569,9 +2605,6 @@ static void r8153_init(struct r8152 *tp)
r8153_enable_eee(tp);
r8153_enable_aldps(tp);
r8152b_enable_fc(tp);
-
- r8152_mdio_write(tp, MII_BMCR, BMCR_RESET | BMCR_ANENABLE |
- BMCR_ANRESTART);
}
static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
--
1.8.4.2
--
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/
--
Florian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH] usb: musb: correct use of schedule_delayed_work()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2014 05:44 PM, Felipe Balbi wrote: On Tue, Feb 18, 2014 at 05:41:12PM +0100, Daniel Mack wrote: On 02/18/2014 05:33 PM, Felipe Balbi wrote: On Wed, Feb 05, 2014 at 03:34:18PM +0100, Daniel Mack wrote: schedule_delayed_work() takes the delay in jiffies, not msecs. This bug slipped in with the recent reset logic cleanup (8ed1fb790ea: usb: musb: finish suspend/reset work independently from musb_hub_control()). Signed-off-by: Daniel Mack dan...@zonque.org doesn't apply. Please refresh against my testing/fixes (give me about an hour until I push the updated branch though). Oh, I'm sorry. Greg said he would queue them up as you were on vacation, so I don't know what's the status here. Greg, can you still drop the patches so they can go through Felipe's tree? Might be best not to cause merge trouble here ... If it's already in Greg's tree, don't worry ;-) I'm just trying to catch up with my inbox ;-) Can't seem to find my patches anywhere in Greg's git. I saw that you updated your testing/fixes branch and wanted to rebase, but the remaining patch (usb: musb: correct use of schedule_delayed_work()) applies on top of that head[*] just fine. Same for you? Thanks, Daniel [*] https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/fixesid=3823b71 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTA5bxAAoJELphMRr8Y1Qkm64P/3HlRJNSfMNaSp8MIVgnjJ43 xbpeyvcLiNaInPpw+Oz0NiQ+yK6z70YTn0+hA4YJfyQbbVsRI3b4QrzSR6KzGCMV afhJ4xyVqEshD6zWC2toiOgT02aBG4xZVfg+17m3RwcpFMAANIuHhnFSDtC5z99y igyfoIZSb3rR3GOSyEU+dq6VcGy047IYbMBgDlmMmhA/Z6BuIKWohT6olyomWti5 ExGgv6g3H3C26nvIm1YcMo8bmn5+LAuY+lzjialcxixnahOFdP5y/o+l00dWIZcw fGA87uWWz9yP24qFP40d1dt1av79BdsJMQNCw98FRAWdzRBNKzRiYL+laNe9wBKY nNyghQIxfHZTaL+gJtCflxkQY51VA+30i34a5idxq3cpSFfSx9XVwGp+DEqPfccA V4GdHxfpiJqvZ64fKJRTdKlVJ6mWkpWbEwnitOOk6x6dkYOsi0Evi6zUedbzLa5h 0gR7vZik8gJi4KzzdfPDYp7rbbvIJA7ahXNIazpy4/PchbthYhIWQcJ/UGpk/7JA QN4Rd1SCs0ELC7EOQxDAwqudssqC3YUjj+HY/JWjMIeC/Au7Wyhk7Ty3ZHTpJq7F rtfRtmxewUsbH1xeJd0k+rtp8dp7Wl/2Qr5oxp2qKiMeSBMEjEkJ6B7I4fTzpM7W Wn7uhY7mAEQKhB2kH4pg =qyOR -END PGP SIGNATURE- -- 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
Re: [PATCH] usb: musb: correct use of schedule_delayed_work()
On Tue, Feb 18, 2014 at 06:22:57PM +0100, Daniel Mack wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2014 05:44 PM, Felipe Balbi wrote: On Tue, Feb 18, 2014 at 05:41:12PM +0100, Daniel Mack wrote: On 02/18/2014 05:33 PM, Felipe Balbi wrote: On Wed, Feb 05, 2014 at 03:34:18PM +0100, Daniel Mack wrote: schedule_delayed_work() takes the delay in jiffies, not msecs. This bug slipped in with the recent reset logic cleanup (8ed1fb790ea: usb: musb: finish suspend/reset work independently from musb_hub_control()). Signed-off-by: Daniel Mack dan...@zonque.org doesn't apply. Please refresh against my testing/fixes (give me about an hour until I push the updated branch though). Oh, I'm sorry. Greg said he would queue them up as you were on vacation, so I don't know what's the status here. Greg, can you still drop the patches so they can go through Felipe's tree? Might be best not to cause merge trouble here ... If it's already in Greg's tree, don't worry ;-) I'm just trying to catch up with my inbox ;-) Can't seem to find my patches anywhere in Greg's git. I saw that you updated your testing/fixes branch and wanted to rebase, but the remaining patch (usb: musb: correct use of schedule_delayed_work()) applies on top of that head[*] just fine. Same for you? weird, maybe I applied another dependency which I didn't have at the time. Will try in a bit, running my 300 randconfig build script now, it'll take a few hours I guess :-p cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 11:03:35AM -0600, Felipe Balbi wrote:
On Tue, Feb 18, 2014 at 08:59:11AM -0800, Greg KH wrote:
On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote:
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each
instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long
timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue
*glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
!root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled.
in that case, files will be created on parent directory right ?
If, for some reason, creating a directory fails and then creating a file
would succeed, yes, that will happen.
If we pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in
__create_file().
No, because -ENODEV will only happen if debugfs is not enabled, so no
dereference will ever happen.
Don't worry about checking return values from debugfs, it shouldn't be
needed.
thanks,
greg k-h
--
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
Re: [PATCH v2 2/3] usb: chipidea: msm: Add device tree support
On 02/18/2014 08:14 PM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Allows controller to be specified via device tree. Pass PHY phandle specified in DT to core driver. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com --- drivers/usb/chipidea/ci_hdrc_msm.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) You also need to describe the binding you're creating in Documentation/devicetree/bindings/usb/file.txt. Did you check [PATCH v2 1/3]? Did you send it to 'linux-usb'? I just didn't get the patch. (Typically, the bindings are described in the same patch the DT support is added to the driver bu YMMV, of course.) Regards, Ivan WBR, Sergei -- 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
Re: USB 3380 using net2280 driver
On Tue, Feb 18, 2014 at 07:55:13AM -0800, Kevin Cernekee wrote: On Tue, Feb 18, 2014 at 7:12 AM, Felipe Balbi ba...@ti.com wrote: On Mon, Feb 17, 2014 at 04:43:11PM -0800, Amit Uttamchandani wrote: I was looking at the changes for net2280.c and saw your name come up in a few of the more recent changes. I wanted to know, are you aware of support for PLXs USB 338o using this net2280 driver? no, those are two completely different controllers. Linux doesn't support USB 3380 as of today. It might be possible to use this code as a starting point: http://patchwork.openwrt.org/patch/2889/ Thanks. Yes, I had found that patch sometime back. It actually originates from the linux driver provided by PLX (search for Linux SDK): http://www.plxtech.com/products/usbcontrollers/usb3380 The driver provided by PLX has quite a bit of changes to other files in the gadget directory as well. So I had thought if net2280 was similar enough to usb3380, that it can be modified to support the basic functionality of usb3380. But based on the responses, it looks like it is a completely different architecture. -- 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
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
Hi,
On Tue, Feb 18, 2014 at 09:30:21AM -0800, Greg KH wrote:
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue
*glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
!root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled.
in that case, files will be created on parent directory right ?
If, for some reason, creating a directory fails and then creating a file
would succeed, yes, that will happen.
If we pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in
__create_file().
No, because -ENODEV will only happen if debugfs is not enabled, so no
dereference will ever happen.
Don't worry about checking return values from debugfs, it shouldn't be
needed.
aha, now I see. I missed the:
348 if (error) {
349 dentry = NULL;
350 simple_release_fs(debugfs_mount, debugfs_mount_count);
351 }
in fs/debugfs/inode.c::__create_file(). I'll apply this patch in a few
hours (randconfig running).
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] usb/xhci: fix compilation warning when !CONFIG_PCI !CONFIG_PM
Hi Sarah,
On Mon, Jan 06, 2014 at 07:02:19PM -0800, David Cohen wrote:
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
It happens due to lack of __maybe_unused flag on xhci_msix_sync_irqs()
function in case of !CONFIG_PCI.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
Ping :)
Any comments here?
Br, David
Change v1 - v2:
- xhci_msix_sync_irqs() already uses __maybe_unused flag when CONFIG_PCI is
set. Proper solution is to add same flag when !CONFIG_PCI instead of define
function as inline.
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..ed6b717b8ee1 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -406,7 +406,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
}
--
1.8.4.2
--
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
Re: [PATCH v2] usb/xhci: fix compilation warning when !CONFIG_PCI !CONFIG_PM
On Tue, Feb 18, 2014 at 10:00:30AM -0800, David Cohen wrote:
Hi Sarah,
On Mon, Jan 06, 2014 at 07:02:19PM -0800, David Cohen wrote:
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
It happens due to lack of __maybe_unused flag on xhci_msix_sync_irqs()
function in case of !CONFIG_PCI.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
Ping :)
Any comments here?
Br, David
Change v1 - v2:
- xhci_msix_sync_irqs() already uses __maybe_unused flag when CONFIG_PCI is
set. Proper solution is to add same flag when !CONFIG_PCI instead of
define
function as inline.
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..ed6b717b8ee1 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -406,7 +406,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
bellow is likely a better fix. Usually stubs are marked inline, rather
than getting an unused attribute:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3712359..8f1a6d5 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -404,16 +404,16 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
#else
-static int xhci_try_enable_msi(struct usb_hcd *hcd)
+static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
{
return 0;
}
-static void xhci_cleanup_msix(struct xhci_hcd *xhci)
+static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
}
--
balbi
signature.asc
Description: Digital signature
Re: [RESEND] [PATCH] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
Sorry for the delay in reviewing this. It helps me if you don't make the
patch in-reply-to a months old thread. :) I'll take a look at this
shortly.
Sarah Sharp
On Tue, Feb 18, 2014 at 09:42:39AM +0200, Denis Turischev wrote:
The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.
Signed-off-by: Denis Turischev de...@compulab.co.il
---
drivers/usb/host/xhci-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 3c898c1..9233d12 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
*/
if (pdev-subsystem_vendor == PCI_VENDOR_ID_HP)
xhci-quirks |= XHCI_SPURIOUS_WAKEUP;
+
+ xhci-quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev-vendor == PCI_VENDOR_ID_ETRON
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
-- 1.8.1.2
--
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
Re: [PATCH v2] usb/xhci: fix compilation warning when !CONFIG_PCI !CONFIG_PM
On Tue, Feb 18, 2014 at 12:47:41PM -0600, Felipe Balbi wrote:
On Tue, Feb 18, 2014 at 10:00:30AM -0800, David Cohen wrote:
Hi Sarah,
On Mon, Jan 06, 2014 at 07:02:19PM -0800, David Cohen wrote:
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
It happens due to lack of __maybe_unused flag on xhci_msix_sync_irqs()
function in case of !CONFIG_PCI.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
Ping :)
Any comments here?
Br, David
Change v1 - v2:
- xhci_msix_sync_irqs() already uses __maybe_unused flag when CONFIG_PCI
is
set. Proper solution is to add same flag when !CONFIG_PCI instead of
define
function as inline.
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..ed6b717b8ee1 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -406,7 +406,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
bellow is likely a better fix. Usually stubs are marked inline, rather
than getting an unused attribute:
Thanks for commenting. That would be actually the v1 of my patch :)
I changed after I see the proper function has __maybe_unused flag.
But I'm fine with Sarah picking any of the patch's versions.
Br, David
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3712359..8f1a6d5 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -404,16 +404,16 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
#else
-static int xhci_try_enable_msi(struct usb_hcd *hcd)
+static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
{
return 0;
}
-static void xhci_cleanup_msix(struct xhci_hcd *xhci)
+static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
}
--
balbi
--
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
Re: [OPW] USB subsystem questions
Hi, On Sun, Feb 16, 2014 at 12:42 AM, Alan Stern st...@rowland.harvard.edu wrote: That's true when it is invoked from userspace. It can also be invoked directly by a kernel driver; in that case no file is needed. I managed to get it working but I think what I did is rather flawed. The problem is where I get that struct dev_state *owner parameter from. The closest to this I found to be the filelist member in struct usb_device. So I got the owner as: owner = list_entry(udev-filelist.next, struct dev_state, list); This works but that list is supposed to be the list of open files for that device. No files are opened in this case. Should I initialize a struct dev_state variable similary to usbdev_open()? Unrelated to this, USB/IP still has a problem when the device is no longer shared. In this case, the device should be rebound to the old drivers and be used normally. While resetting the configuration triggers a new binding process for interface drivers, on the core level, where usbip-host driver is, the device remains unbound. One hack-ish way to solve this would be to manually rebind the device to the old driver. Is there any better way to trigger a new driver binding at core level? Thanks, Valentina -- 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
Re: [PATCH v4 13/14] usb: force warm reset to break resume livelock
On Tue, Feb 11, 2014 at 07:29:40PM -0800, Julius Werner wrote: I believe I am seeing a polling livelock scenario as described by Julius. Julius was talking about what happens when the host controller itself gets reset (and therefore remembers nothing about any device) whereas the device still thinks it is in U3. Is that the scenario you're encountering? I thought you were working on normal runtime PM. When you turn the power back on for a port, it should start out in RxDetect and switch to Polling as it detects Rx terminations. If the downstream device is unhappy for any reason (e.g. in SS.Inactive or still in U3) and sends no or wrong responses to the LFPS Polling, the hub's port will either move to ComplianceMode or keep cycling back and forth between RxDetect and Polling. The latter is especially dangerous because it's hard to detect (if you just sample the port status you might see RxDetect, which would also be expected if there is nothing connected at all), so I'm thinking an unconditional warm reset might be unavoidable. That is why we proposed to go that route for the Synopsys controller, and I think the same will apply to this situation (since I think turning off a PortPower bit in XHCI will make the controller forget a previous U3 state and return to RxDetect when you turn it back on again, even though the actual VBUS line to the device may not have been disabled after all). Julius, are you sure the Synopsys host will actually power off the ports? The Intel hosts need some special ACPI methods, so I'm not sure if Dan's issue with ports after power on could even be seen on the Synopsys host. The Synopsys issue (as I remember it, please correct me if I'm wrong) would only be triggered if the host lost power during S3, and was halted and reset after a register restore failure. I think the solution we agreed to was to implement a Synopsys host quirk that would warm reset all ports unconditionally on register restore failure. Was that right? Then there's Dan's issue. Dan, does the port go into SS.Inactive before the host starts to cycle between RxDetect and Polling and U0 for this case? Hans also ran into this issue (or at least a variation of it), and proposed a patch to fix it. https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-streamsid=3fd14185404e3a298a3f6b6c6f21ff8d41bb2747 Can you take a look at it, and see if it would address your issue? I think it will catch the case where we transition from SS.Inactive - RxDetect - Polling. One other thought (I don't know if it is the right thing to do) is that we might _always_ perform a warm reset after powering-on a SuperSpeed port, without bothering to call hub_port_debounce_be_connected. I'm leaning in that direction. However, the decision comes down to the relative occurrence frequency of devices that fall into this trap vs those that successfully recover and would suffer the additional latency of a warm reset. Is a warm reset significantly longer than an ordinary reset? We have to do some kind of reset in any case. After all, the power session _has_ been interrupted. (Assuming the power switching worked...) USB 3.0 ports don't need to be reset on connect as a matter of course. The should usually just start training themselves and eventually become ready as soon as the wires touch. An extra warm reset would add 80-120ms delay to the port resume. (In comparison, a hot reset should not take more than 12ms, probably even much less.) I would rather avoid warm reset unconditionally on connect whenever possible, because 80-120ms is too long of a delay for some embedded/tablet systems that come into and out of S3 very often. With this in place we may want to consider reducing the timeout and relying on warm reset for recovery. Why? I'm not familiar with the intricacies of USB-3 link state changes, but there seem to be only two possibilities: Either PORT_LS_POLLING is a valid state to be in while trying to establish a SuperSpeed connection, in which case we don't want to reduce the timeout, Or it isn't a valid state, in which case we should abort the debounce immediately. It is a valid transitional state, unfortunately, but in a working case it should resolve itself within a few milliseconds (probably less than 10). Maybe we should try to differentiate between USB 2.0 and 3.0 devices in hub_port_debounce()? I think due to the built-in link training in USB 3.0, the classic debouncing doesn't really make sense anymore (and wastes a lot of time since SuperSpeed links can train really fast when they work). As for this patch, I think the best approach would be to wait for the device to come back in usb_port_runtime_resume() (through hub_port_debounce() or something else), and if it doesn't show up always set the bit to warm reset the port (regardless of
Re: v3.14-rc2+ WARNING: CPU: 0 PID: 24108 at fs/sysfs/group.c:216 sysfs_remove_group+0xa3/0xb0()
On Tue, 18 Feb 2014, [windows-1252] Michal �mucr wrote: On 17.2.2014 20:48, Alan Stern wrote: This isn't a USB problem. Hello, I'm experiencing very similar messages after every disconnection of USB soundcard (snd-usb-audio module). During searching for other similar occurrences of message, i've found few patches. One kind basically prevents sysfs from popping those messages at sysfs group attribute removal - https://lkml.org/lkml/2013/11/23/102 and isn't included in 3.14-rc2, other kind of patches, if i got that correctly, fixes removal ordering or its visibility at underlying subsystem (eg. SCSI, PCI for Thunderbolt hotplugging) to make sysfs happy. Do you know, that there was some general decision, to intentionally don't modify sysfs and fix that for every subsystem, which triggers that messages? Yes, there was indeed such a decision. Just asking, because then it would be probably nice to modify something also at USB audio.. my dmesg with WARNING: http://vpub.smucr.cz/pub/bbb/debug/dmesg-reconnections.log and i probably not alone: http://forums.funtoo.org/viewtopic.php?pid=10327 If you want to pursue this, you should contact the alsa-devel mailing list and the maintainers of the Sound subsystem. Alan Stern -- 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
Re: [PATCH] usb: mark *hci_pci irqs with IRQF_NO_THREAD
On Tue, 18 Feb 2014, Stanislaw Gruszka wrote: On Mon, Feb 17, 2014 at 09:48:14AM -0500, Alan Stern wrote: On Mon, 17 Feb 2014, Stanislaw Gruszka wrote: There is threadirqs kenel boot option which allow to force interrupt routines to be performed as thread. USB irq routines use spin_lock(*hci-lock) variant without disabling interrupts, what is perfectly fine, but that can cause deadlock when forced thread irqs are used. Deadlock scenario is quite reproducible for me, as I can not boot system with threadirqs option, when some USB device is connected. Patch marks USB irq routines with IRQF_NO_THREAD to prevent forced threading. This doesn't explain the entire story. As far as we know the deadlock affects only ehci-hcd, because only ehci-hcd uses an hrtimer callback, and hrtimer callbacks run in interrupt context even when threadirqs is specified. Yes, you have right. Maybe the patch should include a comment explaining that the IRQF_NO_THREAD flag will not be needed when hrtimer callbacks are threaded. I can add that to the patch, but perhaps better would be to just change ehci_irq to use spin_lock_irqsave, that will allow to have threaded interrupt in cost of very little penalty. Either approach would be acceptable to me. Using IRQF_NO_THREAD avoids the extra overhead of spin_lock_irqsave when IRQs aren't threaded. Alan Stern -- 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
Re: [BUG] FL1009: xHCI host not responding to stop endpoint command.
Hi Thomas, Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Dear Arnaud Ebalard, On Sat, 18 Jan 2014 22:49:17 +0100, Arnaud Ebalard wrote: I started suspecting the introduction of MSI support in Marvell PCIe host controller driver (FL1009 is on the PCIe bus) and compiled a a 3.13.0-rc8 w/ CONFIG_PCI_MSI disabled (it was enabled in all my previous tests): I did not manage to reproduce the issue with this kernel. As a side note, commits 5b4deb6526bd, 31f614edb726 and 627dfcc249e2 are ATM, I do not know if the problem is related to a bug in introduced MSI support or some weird incompatibility of that functionality with the FL1009 which would require some quirk in XHCI stack. Thomas, I took a look at the changes but I am not familiar w/ how MSI work. You may have an idea on what is going on here. I finally got some idea: your kernel 3.13-rc7 lacks a very important fix we did in the irqchip driver MSI handling. You really need to have http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/irqchip/irq-armada-370-xp.c?id=c7f7bd4a136e4b02dd2a66bf95aec545bd93e8db applied to get proper MSI behavior. Without this patch, there is a race condition, and some MSI interrupts might be lost. This commit was merged in v3.14-rc2, and backported to 3.13 and previous stable releases. Can you test after applying this commit? Just to be sure, I compiled a 3.13 w/ PCI_MSI enabled and w/o the fix: it failed as usual. Then, I just applied the fix on top of it and tested again: I was unable to make it fail, i.e. this oneline fixes the issue. Sarah, I guess this also validates the fact that FL1009 has good MSI support ;-) Thanks for the time you both spent. Let's close the case. Cheers, a+ -- 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
Re: [PATCH v4 13/14] usb: force warm reset to break resume livelock
Hi, + Paul as he might have better details about the Synopsys core host-side implementation On Tue, Feb 18, 2014 at 12:42:53PM -0800, Sarah Sharp wrote: On Tue, Feb 11, 2014 at 07:29:40PM -0800, Julius Werner wrote: I believe I am seeing a polling livelock scenario as described by Julius. Julius was talking about what happens when the host controller itself gets reset (and therefore remembers nothing about any device) whereas the device still thinks it is in U3. Is that the scenario you're encountering? I thought you were working on normal runtime PM. When you turn the power back on for a port, it should start out in RxDetect and switch to Polling as it detects Rx terminations. If the downstream device is unhappy for any reason (e.g. in SS.Inactive or still in U3) and sends no or wrong responses to the LFPS Polling, the hub's port will either move to ComplianceMode or keep cycling back and forth between RxDetect and Polling. The latter is especially dangerous because it's hard to detect (if you just sample the port status you might see RxDetect, which would also be expected if there is nothing connected at all), so I'm thinking an unconditional warm reset might be unavoidable. That is why we proposed to go that route for the Synopsys controller, and I think the same will apply to this situation (since I think turning off a PortPower bit in XHCI will make the controller forget a previous U3 state and return to RxDetect when you turn it back on again, even though the actual VBUS line to the device may not have been disabled after all). Julius, are you sure the Synopsys host will actually power off the ports? The Intel hosts need some special ACPI methods, so I'm not sure if Dan's issue with ports after power on could even be seen on the Synopsys host. The Synopsys issue (as I remember it, please correct me if I'm wrong) would only be triggered if the host lost power during S3, and was halted and reset after a register restore failure. I think the solution we agreed to was to implement a Synopsys host quirk that would warm reset all ports unconditionally on register restore failure. Was that right? Then there's Dan's issue. Dan, does the port go into SS.Inactive before the host starts to cycle between RxDetect and Polling and U0 for this case? Hans also ran into this issue (or at least a variation of it), and proposed a patch to fix it. https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-streamsid=3fd14185404e3a298a3f6b6c6f21ff8d41bb2747 Can you take a look at it, and see if it would address your issue? I think it will catch the case where we transition from SS.Inactive - RxDetect - Polling. One other thought (I don't know if it is the right thing to do) is that we might _always_ perform a warm reset after powering-on a SuperSpeed port, without bothering to call hub_port_debounce_be_connected. I'm leaning in that direction. However, the decision comes down to the relative occurrence frequency of devices that fall into this trap vs those that successfully recover and would suffer the additional latency of a warm reset. Is a warm reset significantly longer than an ordinary reset? We have to do some kind of reset in any case. After all, the power session _has_ been interrupted. (Assuming the power switching worked...) USB 3.0 ports don't need to be reset on connect as a matter of course. The should usually just start training themselves and eventually become ready as soon as the wires touch. An extra warm reset would add 80-120ms delay to the port resume. (In comparison, a hot reset should not take more than 12ms, probably even much less.) I would rather avoid warm reset unconditionally on connect whenever possible, because 80-120ms is too long of a delay for some embedded/tablet systems that come into and out of S3 very often. With this in place we may want to consider reducing the timeout and relying on warm reset for recovery. Why? I'm not familiar with the intricacies of USB-3 link state changes, but there seem to be only two possibilities: Either PORT_LS_POLLING is a valid state to be in while trying to establish a SuperSpeed connection, in which case we don't want to reduce the timeout, Or it isn't a valid state, in which case we should abort the debounce immediately. It is a valid transitional state, unfortunately, but in a working case it should resolve itself within a few milliseconds (probably less than 10). Maybe we should try to differentiate between USB 2.0 and 3.0 devices in hub_port_debounce()? I think due to the built-in link training in USB 3.0, the classic debouncing doesn't really make sense anymore (and wastes a lot of time since SuperSpeed links can train really fast when they work). As
Re: [BUG] FL1009: xHCI host not responding to stop endpoint command.
Dear Arnaud Ebalard, On Tue, 18 Feb 2014 21:54:31 +0100, Arnaud Ebalard wrote: I finally got some idea: your kernel 3.13-rc7 lacks a very important fix we did in the irqchip driver MSI handling. You really need to have http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/irqchip/irq-armada-370-xp.c?id=c7f7bd4a136e4b02dd2a66bf95aec545bd93e8db applied to get proper MSI behavior. Without this patch, there is a race condition, and some MSI interrupts might be lost. This commit was merged in v3.14-rc2, and backported to 3.13 and previous stable releases. Can you test after applying this commit? Just to be sure, I compiled a 3.13 w/ PCI_MSI enabled and w/o the fix: it failed as usual. Then, I just applied the fix on top of it and tested again: I was unable to make it fail, i.e. this oneline fixes the issue. Cool! Sarah, I guess this also validates the fact that FL1009 has good MSI support ;-) Thanks for the time you both spent. Let's close the case. You're welcome. Sorry for having realized so late from where the problem could be coming from, and that it was in fact already fixed. Thanks to you for reporting and investigating the issue in the first place! Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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
Re: [PATCH 0/7] usb: dwc2/s3c-hsotg: Combine drivers into a single DRD
Hi, On Tue, Feb 18, 2014 at 03:14:25PM -0600, Dinh Nguyen wrote: On Fri, 2014-02-14 at 22:50 +, Paul Zimmerman wrote: From: Jingoo Han [mailto:jg1@samsung.com] Sent: Thursday, February 13, 2014 11:46 PM On Friday, February 14, 2014 2:27 PM, Peter Chen wrote: On Thu, Feb 13, 2014 at 03:10:40PM -0600, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com Hello, This patch series combines the dwc2 host driver and the s3c-hsotg peripheral driver into a single dual-roler driver similar to the dwc3. Does s3c-hsotg use dwc usb2 ip too? If it is, the structure should like ip driver + glue layer. If not, why needs to put them together, I am a little puzzled here. Yes, 's3c-hsotg' also uses DWC USB2 IP. As DWC3 USB driver (./drivers/usb/dwc3/), 'IP driver + glue layer' looks good. Best regards, Jingoo Han Well, DWC3 is a little different. It has a standards-based host API, xHCI, that is (almost) completely independent from its non-standards- based device API (I say 'almost' because of the optional OTG functionality). This means the two drivers have to be separate, to support other xHCI implementations that don't have the device mode functionality. But it also complicates some things, like the implementation of OTG support, which perhaps can be seen by the fact that there is almost no OTG support yet in the DWC3 driver (except for role switching). I don't think having separate drivers is undermining OTG support. It's just that nobody has put down the effort to implement it ;-) Whereas the DWC2 host and device modes both use a proprietary API, so there is no need to have separate drivers, because there are no other implementations of the core except the Synopsys one. Also, quite a few of the registers are shared between host and device modes, so keeping the two drivers separate would mean duplicating some code that could be shared between them. That said, I would have no objection to keeping the two drivers separate, as long as it doesn't create significant difficulties with the implementation. Dinh, what do you think? Did you consider the possibility of keeping the two drivers separate, perhaps sharing some code in a library module? For example, you could have dwc2-lib.ko, dwc2.ko, and s3c-hsotg.ko. dwc2-lib.ko would always be loaded, and dwc2.ko or s3c-hsotg.ko (or both) would be loaded depending on which mode is selected. Each driver would have its own interrupt handler, both of them sharing the common IRQ. They would both have their own probe methods, too. No, I didn't think of this possibility. This initial patch was to try to remove some duplicating of code between dwc2/s3c-hsotg without breaking them too badly. But I think I failed in this aspect from the initial testing. I like your suggestion of keeping the drivers separate with a library module for the role-switching. Do you see this driver being able to go full OTG in the future? And if so, will one method be more adaptable than the other to enable OTG? I haven't thought too deeply about this, so maybe it's a bad idea. But you are the one doing the work, so I think the final decision should be yours. So let try your approach. But does moving s3c-hostg into the dwc2 folder and sharing 1 define file still valid? I would say combining those driver is the best thing you guys can do for several reasons. It will make sure everybody uses a single generic driver, it'll help you avoid code duplication (how many other dwc2 implementations have we seen on linux-usb alone ?), it'll focus efforts to stabilize a single dwc2 driver etc. In fact, I have been asking Samsung folks to cleanup s3c-hsotg for quite a while now exactly so we could have a single dwc2 driver for host and device. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/3] usb: chipidea: msm: Add device tree support
On Tue, Feb 18, 2014 at 07:31:55PM +0100, Sergei Shtylyov wrote: On 02/18/2014 08:14 PM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Allows controller to be specified via device tree. Pass PHY phandle specified in DT to core driver. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com --- drivers/usb/chipidea/ci_hdrc_msm.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) You also need to describe the binding you're creating in Documentation/devicetree/bindings/usb/file.txt. Did you check [PATCH v2 1/3]? Did you send it to 'linux-usb'? I just didn't get the patch. (Typically, the bindings are described in the same patch the DT support is added to the driver bu YMMV, of course.) Although I would personally agree that this is the most logical method, it would appear that the DT guys disagree with us [1]. Lately, they seem to have either given up or are otherwise preoccupied, so perhaps you can still slip a few patches by them. ;) -Courtney [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.txt -- 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
RE: [PATCH 0/7] usb: dwc2/s3c-hsotg: Combine drivers into a single DRD
From: Dinh Nguyen [mailto:dingu...@altera.com] Sent: Tuesday, February 18, 2014 1:14 PM On Fri, 2014-02-14 at 22:50 +, Paul Zimmerman wrote: From: Jingoo Han [mailto:jg1@samsung.com] Sent: Thursday, February 13, 2014 11:46 PM On Friday, February 14, 2014 2:27 PM, Peter Chen wrote: On Thu, Feb 13, 2014 at 03:10:40PM -0600, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com Hello, This patch series combines the dwc2 host driver and the s3c-hsotg peripheral driver into a single dual-roler driver similar to the dwc3. Does s3c-hsotg use dwc usb2 ip too? If it is, the structure should like ip driver + glue layer. If not, why needs to put them together, I am a little puzzled here. Yes, 's3c-hsotg' also uses DWC USB2 IP. As DWC3 USB driver (./drivers/usb/dwc3/), 'IP driver + glue layer' looks good. Best regards, Jingoo Han Well, DWC3 is a little different. It has a standards-based host API, xHCI, that is (almost) completely independent from its non-standards- based device API (I say 'almost' because of the optional OTG functionality). This means the two drivers have to be separate, to support other xHCI implementations that don't have the device mode functionality. But it also complicates some things, like the implementation of OTG support, which perhaps can be seen by the fact that there is almost no OTG support yet in the DWC3 driver (except for role switching). Whereas the DWC2 host and device modes both use a proprietary API, so there is no need to have separate drivers, because there are no other implementations of the core except the Synopsys one. Also, quite a few of the registers are shared between host and device modes, so keeping the two drivers separate would mean duplicating some code that could be shared between them. That said, I would have no objection to keeping the two drivers separate, as long as it doesn't create significant difficulties with the implementation. Dinh, what do you think? Did you consider the possibility of keeping the two drivers separate, perhaps sharing some code in a library module? For example, you could have dwc2-lib.ko, dwc2.ko, and s3c-hsotg.ko. dwc2-lib.ko would always be loaded, and dwc2.ko or s3c-hsotg.ko (or both) would be loaded depending on which mode is selected. Each driver would have its own interrupt handler, both of them sharing the common IRQ. They would both have their own probe methods, too. No, I didn't think of this possibility. This initial patch was to try to remove some duplicating of code between dwc2/s3c-hsotg without breaking them too badly. But I think I failed in this aspect from the initial testing. I like your suggestion of keeping the drivers separate with a library module for the role-switching. Do you see this driver being able to go full OTG in the future? And if so, will one method be more adaptable than the other to enable OTG? I don't think having separate drivers should affect the ability to implement OTG, in fact I think a lot of the OTG-capable controllers have separate drivers for host and peripheral mode. I haven't thought too deeply about this, so maybe it's a bad idea. But you are the one doing the work, so I think the final decision should be yours. So let try your approach. But does moving s3c-hostg into the dwc2 folder and sharing 1 define file still valid? I think it would be a little weird to have the peripheral driver in a different directory than the host, especially if they share a common library module. So I think that is still the best approach. -- Paul
Re: [PATCH net-next 00/14] r8152: improvement and new features
From: Hayes Wang hayesw...@realtek.com Date: Tue, 18 Feb 2014 21:48:57 +0800 Change some flows or behavior to improve the efficiency or make the code readable. Besides, support WOL and runtime suspend. Series applied, but as Florian mentioned you should seriously consider converting this driver to use phylib. -- 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
Re: v3.14-rc2+ WARNING: CPU: 0 PID: 24108 at fs/sysfs/group.c:216 sysfs_remove_group+0xa3/0xb0()
On 18. 2. 2014 21:51, Alan Stern wrote: On Tue, 18 Feb 2014, [windows-1252] Michal �mucr wrote: On 17.2.2014 20:48, Alan Stern wrote: This isn't a USB problem. Hello, I'm experiencing very similar messages after every disconnection of USB soundcard (snd-usb-audio module). During searching for other similar occurrences of message, i've found few patches. One kind basically prevents sysfs from popping those messages at sysfs group attribute removal - https://lkml.org/lkml/2013/11/23/102 and isn't included in 3.14-rc2, other kind of patches, if i got that correctly, fixes removal ordering or its visibility at underlying subsystem (eg. SCSI, PCI for Thunderbolt hotplugging) to make sysfs happy. Do you know, that there was some general decision, to intentionally don't modify sysfs and fix that for every subsystem, which triggers that messages? Yes, there was indeed such a decision. Just asking, because then it would be probably nice to modify something also at USB audio.. my dmesg with WARNING: http://vpub.smucr.cz/pub/bbb/debug/dmesg-reconnections.log and i probably not alone: http://forums.funtoo.org/viewtopic.php?pid=10327 If you want to pursue this, you should contact the alsa-devel mailing list and the maintainers of the Sound subsystem. Alan Stern Hello Alan, thank you for information. Best regards, Michal Smucr -- 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
RE: [PATCH v4 13/14] usb: force warm reset to break resume livelock
From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, February 18, 2014 1:05 PM Hi, + Paul as he might have better details about the Synopsys core host-side implementation On Tue, Feb 18, 2014 at 12:42:53PM -0800, Sarah Sharp wrote: On Tue, Feb 11, 2014 at 07:29:40PM -0800, Julius Werner wrote: I believe I am seeing a polling livelock scenario as described by Julius. Julius was talking about what happens when the host controller itself gets reset (and therefore remembers nothing about any device) whereas the device still thinks it is in U3. Is that the scenario you're encountering? I thought you were working on normal runtime PM. When you turn the power back on for a port, it should start out in RxDetect and switch to Polling as it detects Rx terminations. If the downstream device is unhappy for any reason (e.g. in SS.Inactive or still in U3) and sends no or wrong responses to the LFPS Polling, the hub's port will either move to ComplianceMode or keep cycling back and forth between RxDetect and Polling. The latter is especially dangerous because it's hard to detect (if you just sample the port status you might see RxDetect, which would also be expected if there is nothing connected at all), so I'm thinking an unconditional warm reset might be unavoidable. That is why we proposed to go that route for the Synopsys controller, and I think the same will apply to this situation (since I think turning off a PortPower bit in XHCI will make the controller forget a previous U3 state and return to RxDetect when you turn it back on again, even though the actual VBUS line to the device may not have been disabled after all). Julius, are you sure the Synopsys host will actually power off the ports? The Intel hosts need some special ACPI methods, so I'm not sure if Dan's issue with ports after power on could even be seen on the Synopsys host. The Synopsys issue (as I remember it, please correct me if I'm wrong) would only be triggered if the host lost power during S3, and was halted and reset after a register restore failure. I think the solution we agreed to was to implement a Synopsys host quirk that would warm reset all ports unconditionally on register restore failure. Was that right? Then there's Dan's issue. Dan, does the port go into SS.Inactive before the host starts to cycle between RxDetect and Polling and U0 for this case? Hans also ran into this issue (or at least a variation of it), and proposed a patch to fix it. https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-streamsid=3fd14185404e3a298a3f6b6c6f21ff8d41bb2747 Can you take a look at it, and see if it would address your issue? I think it will catch the case where we transition from SS.Inactive - RxDetect - Polling. One other thought (I don't know if it is the right thing to do) is that we might _always_ perform a warm reset after powering-on a SuperSpeed port, without bothering to call hub_port_debounce_be_connected. I'm leaning in that direction. However, the decision comes down to the relative occurrence frequency of devices that fall into this trap vs those that successfully recover and would suffer the additional latency of a warm reset. Is a warm reset significantly longer than an ordinary reset? We have to do some kind of reset in any case. After all, the power session _has_ been interrupted. (Assuming the power switching worked...) USB 3.0 ports don't need to be reset on connect as a matter of course. The should usually just start training themselves and eventually become ready as soon as the wires touch. An extra warm reset would add 80-120ms delay to the port resume. (In comparison, a hot reset should not take more than 12ms, probably even much less.) I would rather avoid warm reset unconditionally on connect whenever possible, because 80-120ms is too long of a delay for some embedded/tablet systems that come into and out of S3 very often. With this in place we may want to consider reducing the timeout and relying on warm reset for recovery. Why? I'm not familiar with the intricacies of USB-3 link state changes, but there seem to be only two possibilities: Either PORT_LS_POLLING is a valid state to be in while trying to establish a SuperSpeed connection, in which case we don't want to reduce the timeout, Or it isn't a valid state, in which case we should abort the debounce immediately. It is a valid transitional state, unfortunately, but in a working case it should resolve itself within a few milliseconds (probably less than 10). Maybe we should try to differentiate between USB 2.0 and 3.0 devices in hub_port_debounce()? I think due to the built-in link
Re: [PATCH 05/25] libusbg: Update strings only when writting US English strings.
Hello.
On 02/17/2014 09:53 PM, Krzysztof Opasiak wrote:
Strings in current verison of library are hardcoded to
US English. Functions which set strings are generic and
allow to set other languages, but internal library structures
should be update only when setting US English strings.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
src/usbg.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/usbg.c b/src/usbg.c
index e62eb01..2264e7c 100644
--- a/src/usbg.c
+++ b/src/usbg.c
@@ -617,7 +617,10 @@ void usbg_set_gadget_serial_number(struct gadget *g, int
lang, char *serno)
mkdir(path, S_IRWXU|S_IRWXG|S_IRWXO);
- strcpy(g-strs.str_ser, serno);
+ /* strings in library are hardcoded to US English for now */
+ if (lang == LANG_US_ENG) {
+ strcpy(g-strs.str_ser, serno);
+ }
usbg_write_string(path, , serialnumber, serno);
}
@@ -630,7 +633,10 @@ void usbg_set_gadget_manufacturer(struct gadget *g, int
lang, char *mnf)
mkdir(path, S_IRWXU|S_IRWXG|S_IRWXO);
- strcpy(g-strs.str_mnf, mnf);
+ /* strings in library are hardcoded to US English for now */
+ if (lang == LANG_US_ENG) {
+ strcpy(g-strs.str_mnf, mnf);
+ }
usbg_write_string(path, , manufacturer, mnf);
}
@@ -643,7 +649,10 @@ void usbg_set_gadget_product(struct gadget *g, int lang,
char *prd)
mkdir(path, S_IRWXU|S_IRWXG|S_IRWXO);
- strcpy(g-strs.str_prd, prd);
+ /* strings in library are hardcoded to US English for now */
+ if (lang == LANG_US_ENG) {
+ strcpy(g-strs.str_prd, prd);
+ }
usbg_write_string(path, , product, prd);
}
@@ -758,7 +767,10 @@ void usbg_set_config_string(struct config *c, int lang,
char *str)
mkdir(path, S_IRWXU|S_IRWXG|S_IRWXO);
- strcpy(c-str_cfg, str);
+ /* strings in library are hardcoded to US English for now */
+ if (lang == LANG_US_ENG) {
+ strcpy(c-str_cfg, str);
+ }
I guess you haven't run your patch via scripts/checkpatch.pl, otherwise
you would have seen it protesting against single statement *if* arms in {}.
Well, some common sense applies as well since {} are completely unnecessary.
WBR, Sergei
--
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
Re: [PATCH 05/25] libusbg: Update strings only when writting US English strings.
Hello.
On 02/19/2014 02:07 AM, Sergei Shtylyov wrote:
Strings in current verison of library are hardcoded to
US English. Functions which set strings are generic and
allow to set other languages, but internal library structures
should be update only when setting US English strings.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
[...]
I guess you haven't run your patch via scripts/checkpatch.pl, otherwise
you would have seen it protesting against single statement *if* arms in {}.
Well, some common sense applies as well since {} are completely unnecessary.
Ah, I have initially overlooked that it's libusbg patch -- libusbg may
have its own style peculiarities.
WBR, Sergei
--
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
Re: [PATCH 15/25] libusbg: Add getter for config name.
Hello.
On 02/17/2014 09:53 PM, Krzysztof Opasiak wrote:
Add usbg_get_config_name() and usbg_get_config_name_len()
to avoid direct config structure members access.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
include/usbg/usbg.h | 16
src/usbg.c | 10 ++
2 files changed, 26 insertions(+)
diff --git a/include/usbg/usbg.h b/include/usbg/usbg.h
index 0f3fe4c..ac5f730 100644
--- a/include/usbg/usbg.h
+++ b/include/usbg/usbg.h
@@ -480,6 +480,22 @@ extern struct config *usbg_create_config(struct gadget *g,
char *name,
struct config_attrs *c_attrs, struct config_strs *c_strs);
/**
+ * @brief Get config name length
+ * @param c Config which name length should be returned
+ * @return Length of name string or -1 if error occurred.
+ */
+extern size_t usbg_get_config_name_len(struct config *c);
+
+/**
+ * @brieg Get config name
+ * @param c Pointer to config
+ * @param buf Buffer where name should be copied
+ * @param len Length of given buffer
+ * @return Pointer to destination or NULL if error occurred.
+ */
+extern char *usbg_get_config_name(struct config* c, char *buf, size_t len);
Be consistent in your coding style: always put * next to the variable name
(this is kernel style though).
+
+/**
* @brief Set the USB configuration attributes
* @param c Pointer to configuration
* @param c_attrs Configuration attributes
diff --git a/src/usbg.c b/src/usbg.c
index 073efd6..1f1e6d0 100644
--- a/src/usbg.c
+++ b/src/usbg.c
@@ -925,6 +925,16 @@ struct config *usbg_create_config(struct gadget *g, char
*name,
return c;
}
+size_t usbg_get_config_name_len(struct config *c)
+{
+ return c ? strlen(c-name): -1;
+}
+
+char *usbg_get_config_name(struct config* c, char *buf, size_t len)
Same here.
WBR, Sergei
--
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
Re: [PATCH v2 2/3] usb: chipidea: msm: Add device tree support
Hello. On 02/19/2014 12:34 AM, Courtney Cavin wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Allows controller to be specified via device tree. Pass PHY phandle specified in DT to core driver. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com --- drivers/usb/chipidea/ci_hdrc_msm.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) You also need to describe the binding you're creating in Documentation/devicetree/bindings/usb/file.txt. Did you check [PATCH v2 1/3]? Did you send it to 'linux-usb'? I just didn't get the patch. (Typically, the bindings are described in the same patch the DT support is added to the driver bu YMMV, of course.) Although I would personally agree that this is the most logical method, it would appear that the DT guys disagree with us [1]. Lately, they Thank you for the reference. seem to have either given up or are otherwise preoccupied, so perhaps you can still slip a few patches by them. ;) Yeah, I was at last able to get my Ethernet driver bindings applied. :-) -Courtney [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.txt WBR, Sergei -- 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
Re: [PATCH v4 13/14] usb: force warm reset to break resume livelock
Julius, are you sure the Synopsys host will actually power off the ports? The Intel hosts need some special ACPI methods, so I'm not sure if Dan's issue with ports after power on could even be seen on the Synopsys host. The Synopsys issue (as I remember it, please correct me if I'm wrong) would only be triggered if the host lost power during S3, and was halted and reset after a register restore failure. I think the solution we agreed to was to implement a Synopsys host quirk that would warm reset all ports unconditionally on register restore failure. Was that right? Then there's Dan's issue. Dan, does the port go into SS.Inactive before the host starts to cycle between RxDetect and Polling and U0 for this case? Sorry, I didn't mean to pull the Synopsys issue into this thread... we should probably keep that separate in https://lkml.org/lkml/2013/12/9/336 , or this will get too confusing. Some aspects of that issue are definitely different, e.g. there's no port power being turned off there (on the contrary, the problem is that the power session stays alive during suspend but the xHC gets reset and forgets about it). I just wanted to point out that both issues can lead to the same state (by different means) where the port status cycles between RxDetect and Polling, because they both reset the host controller's port state to RxDetect in a way that the device might not notice (or not react correctly to). I think whenever the host port state gets forced back to RxDetect while the device is in SS.Inactive (or anything that can lead to SS.Inactive after a few unexpected packets) you will get into this state, and you will only get back out of there through a warm reset (or by physically cutting off VBUS). Hans also ran into this issue (or at least a variation of it), and proposed a patch to fix it. https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-streamsid=3fd14185404e3a298a3f6b6c6f21ff8d41bb2747 Can you take a look at it, and see if it would address your issue? I think it will catch the case where we transition from SS.Inactive - RxDetect - Polling. I don't think that's targeting the same problem. Hans seems to be describing a situation where the device connects again even though he doesn't want it to -- in our case, the device doesn't connect even though we want that. His patch shouldn't do anything for our issue since he checks for PORT_STAT_CONNECTION, and that bit will be unset when the host port is stuck in RxDetect/Polling. It is a valid transitional state, unfortunately, but in a working case it should resolve itself within a few milliseconds (probably less than 10). Maybe we should try to differentiate between USB 2.0 and 3.0 devices in hub_port_debounce()? I think due to the built-in link training in USB 3.0, the classic debouncing doesn't really make sense anymore (and wastes a lot of time since SuperSpeed links can train really fast when they work). As for this patch, I think the best approach would be to wait for the device to come back in usb_port_runtime_resume() (through hub_port_debounce() or something else), and if it doesn't show up always set the bit to warm reset the port (regardless of LTSSM state, since even if it says RxDetect I wouldn't be sure that there is really nothing connected). We could then also use those bits in the lost power case of xhci_resume() to try and work around the problems with that Synopsys controller. That's a lot of changes to the hub core. Would an xHCI quirk be simpler? Is there some scenario I'm missing that the S3 resume quirk wouldn't handle? We don't need to change hub_port_debounce() right away... that was just an additional suggestion to make things more efficient for SuperSpeed devices in general. I think for now (in order to solve Dan's problem), it would be best if he just calls hub_port_debounce() in usb_port_runtime_resume() (which should bring a connected device back in the majority of cases), and always queues up a warm reset if that fails. (This is essentially what his patch is already doing, just get rid of the extra check for USB_SS_PORT_LS_POLLING in the error path which I think might be a little too specific and overlook cases where the RxDetect/Polling cycle just happens to be at RxDetect in that moment.) -- 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
Re: [PATCH v4 13/14] usb: force warm reset to break resume livelock
On Tue, Feb 18, 2014 at 2:40 PM, Julius Werner jwer...@chromium.org wrote: Can you take a look at it, and see if it would address your issue? I think it will catch the case where we transition from SS.Inactive - RxDetect - Polling. I don't think that's targeting the same problem. Hans seems to be describing a situation where the device connects again even though he doesn't want it to -- in our case, the device doesn't connect even though we want that. His patch shouldn't do anything for our issue since he checks for PORT_STAT_CONNECTION, and that bit will be unset when the host port is stuck in RxDetect/Polling. Yes, agreed. It is a valid transitional state, unfortunately, but in a working case it should resolve itself within a few milliseconds (probably less than 10). Maybe we should try to differentiate between USB 2.0 and 3.0 devices in hub_port_debounce()? I think due to the built-in link training in USB 3.0, the classic debouncing doesn't really make sense anymore (and wastes a lot of time since SuperSpeed links can train really fast when they work). As for this patch, I think the best approach would be to wait for the device to come back in usb_port_runtime_resume() (through hub_port_debounce() or something else), and if it doesn't show up always set the bit to warm reset the port (regardless of LTSSM state, since even if it says RxDetect I wouldn't be sure that there is really nothing connected). We could then also use those bits in the lost power case of xhci_resume() to try and work around the problems with that Synopsys controller. That's a lot of changes to the hub core. Would an xHCI quirk be simpler? Is there some scenario I'm missing that the S3 resume quirk wouldn't handle? We don't need to change hub_port_debounce() right away... that was just an additional suggestion to make things more efficient for SuperSpeed devices in general. I think for now (in order to solve Dan's problem), it would be best if he just calls hub_port_debounce() in usb_port_runtime_resume() (which should bring a connected device back in the majority of cases), and always queues up a warm reset if that fails. (This is essentially what his patch is already doing, just get rid of the extra check for USB_SS_PORT_LS_POLLING in the error path which I think might be a little too specific and overlook cases where the RxDetect/Polling cycle just happens to be at RxDetect in that moment.) That's the plan, and I also want to test a usb device quirk flag to unconditionally warm reset on power-session loss since it does seem to be device specifc in my case. -- 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
Re: [PATCH] usb: mark *hci_pci irqs with IRQF_NO_THREAD
On Mon, 17 Feb 2014, Stanislaw Gruszka wrote:
There is threadirqs kenel boot option which allow to force interrupt
routines to be performed as thread.
USB irq routines use spin_lock(*hci-lock) variant without disabling
interrupts, what is perfectly fine, but that can cause deadlock when
forced thread irqs are used. Deadlock scenario is quite reproducible for
me, as I can not boot system with threadirqs option, when some USB
device is connected. Patch marks USB irq routines with IRQF_NO_THREAD
to prevent forced threading.
Signed-off-by: Stanislaw Gruszka sgrus...@redhat.com
NACK.
This is the wrong approach and will break RT. See the discussion about
EHCI.
Thanks,
tglx
---
drivers/usb/core/hcd-pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index d59d993..b4fa1a5 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -264,7 +264,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
down_write(companions_rwsem);
dev_set_drvdata(dev-dev, hcd);
for_each_companion(dev, hcd, ehci_pre_add);
- retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED);
+ retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED |
IRQF_NO_THREAD);
if (retval != 0)
dev_set_drvdata(dev-dev, NULL);
for_each_companion(dev, hcd, ehci_post_add);
@@ -272,7 +272,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
} else {
down_read(companions_rwsem);
dev_set_drvdata(dev-dev, hcd);
- retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED);
+ retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED |
IRQF_NO_THREAD);
if (retval != 0)
dev_set_drvdata(dev-dev, NULL);
else
--
1.7.11.7
--
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
Re: [PATCH v4 13/14] usb: force warm reset to break resume livelock
We don't need to change hub_port_debounce() right away... that was just an additional suggestion to make things more efficient for SuperSpeed devices in general. I think for now (in order to solve Dan's problem), it would be best if he just calls hub_port_debounce() in usb_port_runtime_resume() (which should bring a connected device back in the majority of cases), and always queues up a warm reset if that fails. (This is essentially what his patch is already doing, just get rid of the extra check for USB_SS_PORT_LS_POLLING in the error path which I think might be a little too specific and overlook cases where the RxDetect/Polling cycle just happens to be at RxDetect in that moment.) That's the plan, and I also want to test a usb device quirk flag to unconditionally warm reset on power-session loss since it does seem to be device specifc in my case. For what it's worth, I think you might not need a quirk flag since you are not really loosing anything in that case. If the first hub_port_debounce() fails to reconnect, the device is either quirky or there is no device attached at all. In the first case we want the warm reset, and in the second case the warm reset is pointless but also doesn't cost us anything (assuming it runs totally asynchronous, which I think your patch guarantees). The only case where we really need to avoid wasting those 100ms is on ports which are connected and already usable, but those should be caught by hub_port_debounce() already. -- 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
Re: [PATCH v9 01/12] usb: doc: phy-mxs: Add more compatible strings
On Tue, Feb 18, 2014 at 10:49:24AM -0600, Felipe Balbi wrote: On Fri, Dec 27, 2013 at 10:38:30AM +0800, Peter Chen wrote: Add fsl,imx6q-usbphy for imx6dq and imx6dl, add fsl,imx6sl-usbphy for imx6sl. Signed-off-by: Peter Chen peter.c...@freescale.com anybody from DT to give me an Acked-by ? Unfortunately, the DT maintainers and list are not on copy. Shawn -- 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
Re: [PATCH 2/2] USB: at91: using USBA_NR_DMAS for DMA channels
On Wed, Feb 19, 2014 at 09:14:58AM +0800, Bo Shen wrote:
Hi Felipe Balbi,
On 02/19/2014 12:19 AM, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 10:59:25AM +0800, Bo Shen wrote:
When the SoC is earlier than sama5d3 SoC, which have the same number
endpoints and DMAs. However for sama5d3 SoC, it has different number
for endpoints and DMAs. So, define USBA_NR_DMAs for DMA channels
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/atmel_usba_udc.c | 2 +-
drivers/usb/gadget/atmel_usba_udc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index 7e67a81..5cded1c 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1661,7 +1661,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (dma_status) {
int i;
- for (i = 1; i USBA_NR_ENDPOINTS; i++)
+ for (i = 1; i USBA_NR_DMAS; i++)
if (dma_status (1 i))
usba_dma_irq(udc, udc-usba_ep[i]);
}
diff --git a/drivers/usb/gadget/atmel_usba_udc.h
b/drivers/usb/gadget/atmel_usba_udc.h
index 2922db5..a70706e 100644
--- a/drivers/usb/gadget/atmel_usba_udc.h
+++ b/drivers/usb/gadget/atmel_usba_udc.h
@@ -210,7 +210,7 @@
#define USBA_FIFO_BASE(x) ((x) 16)
/* Synth parameters */
-#define USBA_NR_ENDPOINTS 7
+#define USBA_NR_DMAS 7
what's the difference ? You just renamed this macro. Also, please
clarify a bit your commit log.
As commit message said, the SoC before sama5d3, the endpoint number
is the same as DMA channel number, so use endpoints definition for
DMA channel number, however after sama5d3, the endpoints is not the
same as DMA channel, so use DMA micro for DMA channels.
which means you're just renaming the macro for the sake of clarity.
That's fine, just needs to be clearer in commit message.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v9 01/12] usb: doc: phy-mxs: Add more compatible strings
On Wed, Feb 19, 2014 at 09:12:49AM +0800, Shawn Guo wrote: On Tue, Feb 18, 2014 at 10:49:24AM -0600, Felipe Balbi wrote: On Fri, Dec 27, 2013 at 10:38:30AM +0800, Peter Chen wrote: Add fsl,imx6q-usbphy for imx6dq and imx6dl, add fsl,imx6sl-usbphy for imx6sl. Signed-off-by: Peter Chen peter.c...@freescale.com anybody from DT to give me an Acked-by ? Unfortunately, the DT maintainers and list are not on copy. Then we need this series to be resent. I'll drop from my queue for now. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 13/14] usb: force warm reset to break resume livelock
On Tue, Feb 18, 2014 at 3:39 PM, Julius Werner jwer...@chromium.org wrote: We don't need to change hub_port_debounce() right away... that was just an additional suggestion to make things more efficient for SuperSpeed devices in general. I think for now (in order to solve Dan's problem), it would be best if he just calls hub_port_debounce() in usb_port_runtime_resume() (which should bring a connected device back in the majority of cases), and always queues up a warm reset if that fails. (This is essentially what his patch is already doing, just get rid of the extra check for USB_SS_PORT_LS_POLLING in the error path which I think might be a little too specific and overlook cases where the RxDetect/Polling cycle just happens to be at RxDetect in that moment.) That's the plan, and I also want to test a usb device quirk flag to unconditionally warm reset on power-session loss since it does seem to be device specifc in my case. For what it's worth, I think you might not need a quirk flag since you are not really loosing anything in that case. If the first hub_port_debounce() fails to reconnect, the device is either quirky or there is no device attached at all. In the first case we want the warm reset, and in the second case the warm reset is pointless but also doesn't cost us anything (assuming it runs totally asynchronous, which I think your patch guarantees). No, it's not asynchronous. The only case where we really need to avoid wasting those 100ms is on ports which are connected and already usable, but those should be caught by hub_port_debounce() already. The quirk would stop the the implementation from wasting its time on the 2 second reconnect timeout on devices known to have problems recovering from a logical power session loss and simply issue the warm-reset immediately. That said, I should also look to see how long devices take to reconnect on average and if that is more than 120ms maybe it would make sense to unconditionally warm reset. -- 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
Re: [PATCH 2/2] USB: at91: using USBA_NR_DMAS for DMA channels
On 02/19/2014 09:22 AM, Felipe Balbi wrote:
On Wed, Feb 19, 2014 at 09:14:58AM +0800, Bo Shen wrote:
Hi Felipe Balbi,
On 02/19/2014 12:19 AM, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 10:59:25AM +0800, Bo Shen wrote:
When the SoC is earlier than sama5d3 SoC, which have the same number
endpoints and DMAs. However for sama5d3 SoC, it has different number
for endpoints and DMAs. So, define USBA_NR_DMAs for DMA channels
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/atmel_usba_udc.c | 2 +-
drivers/usb/gadget/atmel_usba_udc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index 7e67a81..5cded1c 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1661,7 +1661,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (dma_status) {
int i;
- for (i = 1; i USBA_NR_ENDPOINTS; i++)
+ for (i = 1; i USBA_NR_DMAS; i++)
if (dma_status (1 i))
usba_dma_irq(udc, udc-usba_ep[i]);
}
diff --git a/drivers/usb/gadget/atmel_usba_udc.h
b/drivers/usb/gadget/atmel_usba_udc.h
index 2922db5..a70706e 100644
--- a/drivers/usb/gadget/atmel_usba_udc.h
+++ b/drivers/usb/gadget/atmel_usba_udc.h
@@ -210,7 +210,7 @@
#define USBA_FIFO_BASE(x) ((x) 16)
/* Synth parameters */
-#define USBA_NR_ENDPOINTS 7
+#define USBA_NR_DMAS 7
what's the difference ? You just renamed this macro. Also, please
clarify a bit your commit log.
As commit message said, the SoC before sama5d3, the endpoint number
is the same as DMA channel number, so use endpoints definition for
DMA channel number, however after sama5d3, the endpoints is not the
same as DMA channel, so use DMA micro for DMA channels.
which means you're just renaming the macro for the sake of clarity.
That's fine, just needs to be clearer in commit message.
Thanks, I will send v2 to make the commit message more clearer.
Best Regards,
Bo Shen
--
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
Re: [PATCH v9 01/12] usb: doc: phy-mxs: Add more compatible strings
On Wed, Feb 19, 2014 at 08:44:12AM +0800, Peter Chen wrote: On Tue, Feb 18, 2014 at 07:24:19PM -0600, Felipe Balbi wrote: On Wed, Feb 19, 2014 at 09:12:49AM +0800, Shawn Guo wrote: On Tue, Feb 18, 2014 at 10:49:24AM -0600, Felipe Balbi wrote: On Fri, Dec 27, 2013 at 10:38:30AM +0800, Peter Chen wrote: Add fsl,imx6q-usbphy for imx6dq and imx6dl, add fsl,imx6sl-usbphy for imx6sl. Signed-off-by: Peter Chen peter.c...@freescale.com anybody from DT to give me an Acked-by ? Unfortunately, the DT maintainers and list are not on copy. Then we need this series to be resent. I'll drop from my queue for now. -- balbi Oh, I had thought it was ok that shawn has applied dts change. Do we really need dts maintainer's ack for doc if dts has already applied? Yes. If DT maintainers have objection, I will need to drop the dts patch too. Shawn -- 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
[PATCH v2 1/2] USB: at91: fix the number of endpoint parameter
In sama5d3 SoC, there are 16 endpoints, which is different with
earlier SoCs (only have 7 endpoints). The USBA_NR_ENDPOINTS micro
is not suitable for sama5d3. So, get the endpoints number through
the udc-num_ep, which get from platform data for non-dt kernel,
or parse from dt node.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
Changes in v2:
- Make the commit message more clearer.
drivers/usb/gadget/atmel_usba_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index 2cb52e0..7e67a81 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1670,7 +1670,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (ep_status) {
int i;
- for (i = 0; i USBA_NR_ENDPOINTS; i++)
+ for (i = 0; i udc-num_ep; i++)
if (ep_status (1 i)) {
if (ep_is_control(udc-usba_ep[i]))
usba_control_irq(udc, udc-usba_ep[i]);
--
1.8.5.2
--
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
RE: [PATCH net-next 07/14] r8152: combine PHY reset with set_speed
Florian Fainelli [mailto:f.faine...@gmail.com]
Sent: Wednesday, February 19, 2014 1:19 AM
To: Hayes Wang
Cc: netdev; nic_s...@realtek.com;
linux-ker...@vger.kernel.org; linux-usb
Subject: Re: [PATCH net-next 07/14] r8152: combine PHY reset
with set_speed
[...]
+static void rtl_phy_reset(struct r8152 *tp)
+{
+ u16 data;
+ int i;
+
+ clear_bit(PHY_RESET, tp-flags);
+
+ data = r8152_mdio_read(tp, MII_BMCR);
+
+ /* don't reset again before the previous one complete */
+ if (data BMCR_RESET)
+ return;
+
+ data |= BMCR_RESET;
+ r8152_mdio_write(tp, MII_BMCR, data);
+
+ for (i = 0; i 50; i++) {
+ msleep(20);
+ if ((r8152_mdio_read(tp, MII_BMCR)
BMCR_RESET) == 0)
+ break;
+ }
+}
If you implemented libphy in the driver you would not have to
duplicate that and you could use phy_init_hw() or
genphy_soft_reset() to perform the BMCR-based software reset.
Thanks for you suggestion. I would study about those.
Best Regards,
Hayes
--
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
