Re: [PATCH v3 1/6] drivers: phy: add generic PHY framework
Hi,
On Friday 19 April 2013 02:39 PM, Grant Likely wrote:
On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
We have decided not to implement the PHY layer as a separate bus layer.
The PHY provider can be part of any other bus. Making the PHY layer as a
bus will make the PHY provider to be part of multiple buses which will
lead to bad design. All we are trying to do here is keep the pool of PHY
devices under PHY class in this layer and help any controller that wants
to use the PHY to get it.
If you're using a class, then you already have your list of registered
phy devices! :-) No need to create another global list that you need to
manage.
right. We already use _class_dev_iter_ for finding the phy device.
.
.
+static struct phy *of_phy_lookup(struct device *dev, struct device_node
*node)
+{
+ struct phy *phy;
+ struct class_dev_iter iter;
+
+ class_dev_iter_init(iter, phy_class, NULL, NULL);
+ while ((dev = class_dev_iter_next(iter))) {
+ phy = container_of(dev, struct phy, dev);
+ if (node != phy-of_node)
+ continue;
+
+ class_dev_iter_exit(iter);
+ return phy;
+ }
+
+ class_dev_iter_exit(iter);
+ return ERR_PTR(-EPROBE_DEFER);
+}
.
.
however we can't get rid of the other list (phy_bind_list) where we
maintain the phy binding information. It's used for the non-dt boot case.
Why? If you're using a class, then it is always there. Why would non-DT
and DT be different in this regard? (more below)
Since there is at most a 1:N relationship between host controllers and
PHYs, there shouldn't be any need for a separate structure to describe
binding. Put the inding data into the struct phy itself. Each host
controller can have a list of phys that it is bound to.
No. Having the host controller to have a list of phys wont be a good
idea IMHO. The host controller is just an IP and the PHY to which it
will be connected can vary from board to board, platform to platform. So
ideally this binding should come from platform initialization code/dt data.
That is not what I mean. I mean the host controller instance should
contain a list of all the PHYs that are attached to it. There should not
Doesn't sound correct IMO. The host controller instance need not know
anything about the PHY instances that is connected to it. Think of it
similar to regulator, the controller wouldn't know which regulator it is
connected to, all it has to know is it just has a regulator connected to
it. It's up-to the regulator framework to give the controller the
correct regulator. It's similar here. It makes sense for me to keep a
list in the PHY framework in order for it to return the correct PHY (but
note that this list is not needed for dt boot).
With regulators and clocks it makes sense to have a global
registration place becase both implement an interconnected network
independent of the device that use them. (clocks depend on other clocks;
regulators depend on other regulators).
Phys are different. There is a 1:N relationship between host controllers
and phys, and you don't get a interconnected network of PHYs. Its a bad
idea to keep the binding data separate from the actual host controller
when there is nothing else that actually needs to use the data. It
creates a new set of data structures that need housekeeping to keep them
in sync with the actual device structures. It really is just a bad idea
and it becomes more difficult (in the non-DT case) to determine what
data is associated with a given host controller. You can't tell by
looking at the struct device.
Instead, for the non-DT case, do what we've always done for describing
connections. Put the phy reference into the host controllers
platform_data structure.
hmm... my only concern here is there is no way we can enforce the phy
reference is added in the platform_data structure.
That is what it is there for. That completely
eliminates the need to housekeep a new set of data structures.
Ok. Makes sense.
Thanks
Kishon
--
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/5] of_platform_driver and OF_DEVICE removal
On Monday 22 April 2013, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com This series is a relatively straight-forward removal of the last remaining user of of_platform_driver (ibmebus) and removal of CONFIG_OF_DEVICE which is always enabled when CONFIG_OF is enabled. Compile tested on powerpc and sparc. Acked-by: Arnd Bergmann a...@arndb.de -- 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: Creating a new xhci-hcd platform device
Hello everyone I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. 2. In the machine code – Register an “xhci-mv” platform device and initialize its resources based on device tree. I appreciate any input or comment Thanks in advance Yehuda Yitschak -- 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: Creating a new xhci-hcd platform device
Hi, On Mon, Apr 22, 2013 at 10:18:20AM +0300, yehuda yitchak wrote: Hello everyone I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. no new xhci-mv. Reuse xhci-plat.c which is supposed to be generic. 2. In the machine code – Register an “xhci-mv” platform device and initialize its resources based on device tree. right, except that you should use xhci-plat. -- balbi signature.asc Description: Digital signature
Re: Creating a new xhci-hcd platform device
On Mon, Apr 22, 2013 at 10:48 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Apr 22, 2013 at 10:18:20AM +0300, yehuda yitchak wrote: Hello everyone I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. no new xhci-mv. Reuse xhci-plat.c which is supposed to be generic. Then where am i supposed to initialize the SOC specific stuff For example in the host controller we have some registers that map the access to the DRAM space. i need a probe, suspend and resume hook to initialize them to save and restore them among other stuff. 2. In the machine code – Register an “xhci-mv” platform device and initialize its resources based on device tree. right, except that you should use xhci-plat. -- 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: Creating a new xhci-hcd platform device
HI, On Mon, Apr 22, 2013 at 11:17:25AM +0300, yehuda yitchak wrote: I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. no new xhci-mv. Reuse xhci-plat.c which is supposed to be generic. Then where am i supposed to initialize the SOC specific stuff before driver probe in your platform initialization ? For example in the host controller we have some registers that map the access to the DRAM space. i need a probe, suspend and resume hook to initialize them to save and restore them among other stuff. these sounds like it can be done in your bus dev_pm_ops, but hey, send a patch and we will see how similar will it look to xhci-plat.c, then figure out if we should have another glue or not. -- balbi signature.asc Description: Digital signature
Re: Creating a new xhci-hcd platform device
If the code is small, then I don't see any problem with adding it directly to the xhci-plat.c driver (or in this case you'll probably need an xhci-of binding as well) I was wondering if the marvell system supports a more generic way of attaching devices which have these bus window mappings on them, since there's several others. It may be worth looking into this (at least ask on the arm kernel list). It would probably be best to view the code before making much more in the way of comment. On 22 April 2013 09:18, yehuda yitchak yehud...@gmail.com wrote: Hello everyone I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. 2. In the machine code – Register an “xhci-mv” platform device and initialize its resources based on device tree. I appreciate any input or comment Thanks in advance Yehuda Yitschak -- 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 -- Ben Dooks, http://www.fluff.org/ben/ bjdo...@googlemail.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: Creating a new xhci-hcd platform device
On Mon, Apr 22, 2013 at 11:30 AM, Felipe Balbi ba...@ti.com wrote: HI, On Mon, Apr 22, 2013 at 11:17:25AM +0300, yehuda yitchak wrote: I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. no new xhci-mv. Reuse xhci-plat.c which is supposed to be generic. Then where am i supposed to initialize the SOC specific stuff before driver probe in your platform initialization ? For example in the host controller we have some registers that map the access to the DRAM space. i need a probe, suspend and resume hook to initialize them to save and restore them among other stuff. these sounds like it can be done in your bus dev_pm_ops, but hey, send a patch and we will see how similar will it look to xhci-plat.c, then figure out if we should have another glue or not. At this time entire machine still doesnt exist in mainline. Can you review a patch without the machine code in mainline ? -- 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: Creating a new xhci-hcd platform device
On Mon, Apr 22, 2013 at 11:54 AM, Ben Dooks bjdo...@googlemail.com wrote: If the code is small, then I don't see any problem with adding it directly to the xhci-plat.c driver (or in this case you'll probably need an xhci-of binding as well) im not sure it is small. you can look at drivers/dma/mv_xor.c function mv_xor_conf_mbus_windows for an example I was wondering if the marvell system supports a more generic way of attaching devices which have these bus window mappings on them, since there's several others. It may be worth looking into this (at least ask on the arm kernel list). i will look into it. i know some work has been done in plat-orion by thomas petazzoni. maybe there is a generic approach to this It would probably be best to view the code before making much more in the way of comment. i can send a patch tough the entire machine is still not in mainline Thanks Yehuda On 22 April 2013 09:18, yehuda yitchak yehud...@gmail.com wrote: Hello everyone I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. 2. In the machine code – Register an “xhci-mv” platform device and initialize its resources based on device tree. I appreciate any input or comment Thanks in advance Yehuda Yitschak -- 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 -- Ben Dooks, http://www.fluff.org/ben/ bjdo...@googlemail.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: Creating a new xhci-hcd platform device
Hi, On Mon, Apr 22, 2013 at 11:54:34AM +0300, yehuda yitchak wrote: I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. no new xhci-mv. Reuse xhci-plat.c which is supposed to be generic. Then where am i supposed to initialize the SOC specific stuff before driver probe in your platform initialization ? For example in the host controller we have some registers that map the access to the DRAM space. i need a probe, suspend and resume hook to initialize them to save and restore them among other stuff. these sounds like it can be done in your bus dev_pm_ops, but hey, send a patch and we will see how similar will it look to xhci-plat.c, then figure out if we should have another glue or not. At this time entire machine still doesnt exist in mainline. Can you review a patch without the machine code in mainline ? sure, no problem -- balbi signature.asc Description: Digital signature
Re: Creating a new xhci-hcd platform device
On Mon, Apr 22, 2013 at 12:13 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Apr 22, 2013 at 11:54:34AM +0300, yehuda yitchak wrote: I want to ask your advice on the best approach for implementing a new XHCI host controller. I am going to add Linux support for a new XHCI host controller for Marvell SOCs. I looked around the latest XHCI support code in the kernel and found that a platform driver called “xhci-hcd” exists. And there is also one XHCI device (DRD dwc3 used by Samsung and TI) that bounds to this driver. My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. Basically I need to initialize some SOC level registers and then register an xhci-hcd device. Also I need to implement suspend/resume hooks to save and restore the SOC registers initialized at the probe function. I was thinking to take the following approach: 1. Under drivers/usb/host - Register a new platform driver called “xhci-mv” which will initialize the SOC specific stuff and register an “xhci-hcd” platform device. no new xhci-mv. Reuse xhci-plat.c which is supposed to be generic. Then where am i supposed to initialize the SOC specific stuff before driver probe in your platform initialization ? For example in the host controller we have some registers that map the access to the DRAM space. i need a probe, suspend and resume hook to initialize them to save and restore them among other stuff. these sounds like it can be done in your bus dev_pm_ops, but hey, send a patch and we will see how similar will it look to xhci-plat.c, then figure out if we should have another glue or not. At this time entire machine still doesnt exist in mainline. Can you review a patch without the machine code in mainline ? sure, no problem thanks, i will upload it once its ready Yehuda -- 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
How to safe recover USB driver from broken hardware situation
Hi all, Recently, I have several customers troubled in safe recover USB function during the ESD situation (or some other situations, like short dp/dm, ground dp/dm, etc). I designed the ESD detect and recovery process, but I met some sync problems between host controller driver (eg, ehci) and class driver (eg, mass storage). For example, when khubd tries to disconnect usb device, it will try to stop thread usb-storage, but usb-storage is waiting some transfers to finish, qTD and QH operation may be finished (usb_submit_urb does not return error), but no watchdog timer and completion interrupt are occurred. I have: esd_detect_process and esd_recovery_process at host controller driver. At esd_detect_porcess It will disable usb interrupt and judge ASE and PSE, etc. At esd_recovery_process: It needs to reset controller (usbcmd.rst, and toggle portsc.pp bit, etc) I would like to have some synchronization mechanism between usb_submit_urb or (ehci_urb_enqueue) and my esd_detect_process and esd_recovery_process. But still not find a safe one, eg, I still met khubd's status changes D problem described above. Any suggestions are appreciated, Thanks. -- Best Regards, Peter Chen -- 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
Fwd: cdc_acm buffer allocation out of memory
Dear all, I'm getting following message from cdc_acm driver when plugging in my GSM module on Amlogic 8726-MXS platform (kernel v3.0.8): cdc_acm 1-1:1.4: ttyACM2: USB ACM device [ 26.730474@0] cdc_acm 1-1:1.6: This device cannot do calls on its own. It is not a modem. [ 26.733206@0] cdc_acm 1-1:1.6: out of memory (write buffer alloc) [ 26.740307@0] cdc_acm: probe of 1-1:1.6 failed with error -12 acm_write_buffers_alloc() function calls hcd_buffer_alloc() which allocates coherent memory for DMA transfers through dma_pool_alloc or dma_alloc_coherent. Can please someone give me an advice where is the memory available for these allocations defined? with best regards Jan -- 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: cdc_acm buffer allocation out of memory
Hello, 2013/4/22 Jan Pohanka xhpoha...@gmail.com: Dear all, I'm getting following message from cdc_acm driver when plugging in my GSM module on Amlogic 8726-MXS platform (kernel v3.0.8): cdc_acm 1-1:1.4: ttyACM2: USB ACM device [ 26.730474@0] cdc_acm 1-1:1.6: This device cannot do calls on its own. It is not a modem. [ 26.733206@0] cdc_acm 1-1:1.6: out of memory (write buffer alloc) [ 26.740307@0] cdc_acm: probe of 1-1:1.6 failed with error -12 acm_write_buffers_alloc() function calls hcd_buffer_alloc() which allocates coherent memory for DMA transfers through dma_pool_alloc or dma_alloc_coherent. Can please someone give me an advice where is the memory available for these allocations defined? If I am not wrong you should take a look at the define CONSISTENT_DMA_SIZE. Regards, Daniele -- 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 v5 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
Hello. On 22-04-2013 5:09, Simon Horman wrote: USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and registered in the Marzen board file. Move the data and code to their proper place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[] to 8a7779_standard_devices[] -- this seems legitimate since they are registered I've been pointed to the types in the above variable names privately. Don't know should I resend or Simon could fix s/8a7779/r8a7779/ while applying... well, the USB patches haven't been ACK'ed yet. I can fix that up. Is the series waiting on anything? Probably on Felipe's ACKs on rcar-phy.c patches... Felipe hasn't appeared on this list for a week but I see his mails from today. from r8a7779_add_standard_devices() anyway. Note that I'm deliberately changing the USB PHY platform device's 'id' field from (previously just omitted) 0 to -1 as the device is a single of its kind. Note also that the board and SoC code have to be in one patch to keep the code bisectable... The patch has been tested on the Marzen board. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Acked-by: Simon Horman horms+rene...@verge.net.au 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: Linux USB file storage gadget with new UDC
On Mon, 22 Apr 2013, victor yeo wrote: Here is a full log from the beginning which shows another problem. When the SCSI_READ_10 command below is received, there is a disconnect or port reset which causes the (-32) broken pipe problem. You really need to fix the old problems before worrying about new problems. The set_halt still isn't working, and the UDC continues to continues to call bulk_out_complete multiple times without receiving any packets. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0c 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 f8 9e 33 I think the UDC driver detects reset interrupt and inform gadget driver about the disconnect. The USB link is not stable. How can UDC driver maintain a stable USB link with the USB host? It would be easier to maintain a stable link if the UDC connected at high speed in the first place. The usbmon log shows that the connection was at full speed (12 Mb/s), not high speed (480 Mb/s) -- which means that this line: g_file_storage gadget: high-speed config #1 in the gadget log indicates another bug in the UDC driver. It told the gadget driver that the connection was high speed, but the connection really was full speed. 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 v5 0/9] Reorganize R8A7779/Marzen USB code
On Sat, Apr 20, 2013 at 01:55:12AM +0400, Sergei Shtylyov wrote: Hello. Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130419' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data Please can you rethink how you use get_maintainers.pl and send out patches? Sending them To everyone who get_maintainers.pl spits out is all well and good, but it means that there's no discrimination between those who have a primary interest in the patches and those who don't. Examples of people with a primary interest: those maintaining the platforms and/or those who you want to merge your patches. These should be on the To: line. Those who don't: everyone else who may have an interest - these go on the Cc: line. You're about the only person I regularly get patches for platforms which are sent To: me all the time, and really they are not important for me (though they are important enough for me to be Cc'd). What I'm saying is that having come back from a vacation last Tuesday, I could not just scan through this mailbox for all messages marked To me and treat those as being more important than everything else, because soo many of yours were captured by that. And I'm still tacking the backlog today, almost a week later. Please be more considerate to those who you're mailing. (Also, make sure you don't honor the Mail-Followup-To: header, which will lead your mailer to keep placing all recipients into the To: header on reply - because it breaks the above reasoning. The To: header should be those recipients who you are directly discussing, and Cc: is for interested side parties.) Thanks. -- 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: How to safe recover USB driver from broken hardware situation
On Mon, 22 Apr 2013, Peter Chen wrote: Hi all, Recently, I have several customers troubled in safe recover USB function during the ESD situation (or some other situations, like short dp/dm, ground dp/dm, etc). I designed the ESD detect and recovery process, but I met some sync problems between host controller driver (eg, ehci) and class driver (eg, mass storage). For example, when khubd tries to disconnect usb device, it will try to stop thread usb-storage, but usb-storage is waiting some transfers to finish, qTD and QH operation may be finished (usb_submit_urb does not return error), but no watchdog timer and completion interrupt are occurred. I have: esd_detect_process and esd_recovery_process at host controller driver. At esd_detect_porcess It will disable usb interrupt and judge ASE and PSE, etc. At esd_recovery_process: It needs to reset controller (usbcmd.rst, and toggle portsc.pp bit, etc) I would like to have some synchronization mechanism between usb_submit_urb or (ehci_urb_enqueue) and my esd_detect_process and esd_recovery_process. But still not find a safe one, eg, I still met khubd's status changes D problem described above. Any suggestions are appreciated, Thanks. Your recovery process should not need to make all these changes to ehci-hcd. Simply carry out the same actions as the dead: statement label in ehci_irq() -- that is, do the same thing as if an interrupt occurred with the STS_FATAL bit set. That code is all properly synchronized. Then unbind the driver from the controller and rebind it. Rebinding will reset the controller. 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: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Fri, 19 Apr 2013, Joe Rayhawk wrote: On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote: On Fri, 19 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One frame worked fine with the old driver. What is the reason for this regression? Perhaps that was a mistake. Joe, you can try changing the 2 above to a 1 to see if it fixes the problem. Hey, that worked great! Audio's coming through continuously, now. This change could be added to the driver, but I would prefer not to. In any case, it would be best if the usb-audio driver were changed to keep the pipeline length at least 2 ms at all times. Clemens, what do you suggest? 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] More initconst in ehci driver
On Sat, 20 Apr 2013, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
Signed-off-by: Andi Kleen a...@linux.intel.com
diff --git a/drivers/usb/host/ehci-platform.c
b/drivers/usb/host/ehci-platform.c
index ca75063..6a18f11 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -58,7 +58,7 @@ static int ehci_platform_reset(struct usb_hcd *hcd)
static struct hc_driver __read_mostly ehci_platform_hc_driver;
-static const struct ehci_driver_overrides platform_overrides __initdata = {
+static const struct ehci_driver_overrides platform_overrides __initconst = {
.reset =ehci_platform_reset,
};
Andi, you might as well fix up _all_ the EHCI platform drivers in
linux-next that need this change, not just two of them.
And the change is so small; you might as well put all of them into a
single patch instead of having half a dozen individual single-line
patches.
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: cdc_acm buffer allocation out of memory
You were right, thank you very much. regards Jan 2013/4/22 Daniele Palmas dnl...@gmail.com: Hello, 2013/4/22 Jan Pohanka xhpoha...@gmail.com: Dear all, I'm getting following message from cdc_acm driver when plugging in my GSM module on Amlogic 8726-MXS platform (kernel v3.0.8): cdc_acm 1-1:1.4: ttyACM2: USB ACM device [ 26.730474@0] cdc_acm 1-1:1.6: This device cannot do calls on its own. It is not a modem. [ 26.733206@0] cdc_acm 1-1:1.6: out of memory (write buffer alloc) [ 26.740307@0] cdc_acm: probe of 1-1:1.6 failed with error -12 acm_write_buffers_alloc() function calls hcd_buffer_alloc() which allocates coherent memory for DMA transfers through dma_pool_alloc or dma_alloc_coherent. Can please someone give me an advice where is the memory available for these allocations defined? If I am not wrong you should take a look at the define CONSISTENT_DMA_SIZE. Regards, Daniele -- 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] Fix initconst in ehci driver
From: Andi Kleen a...@linux.intel.com
Signed-off-by: Andi Kleen a...@linux.intel.com
diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index e9301fb..0a2efca 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -47,7 +47,7 @@ struct ehci_mxc_priv {
static struct hc_driver __read_mostly ehci_mxc_hc_driver;
-static const struct ehci_driver_overrides ehci_mxc_overrides __initdata = {
+static const struct ehci_driver_overrides ehci_mxc_overrides __initconst = {
.extra_priv_size = sizeof(struct ehci_mxc_priv),
};
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 170b939..b0fe8b5 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -385,7 +385,7 @@ static int ehci_pci_resume(struct usb_hcd *hcd, bool
hibernated)
static struct hc_driver __read_mostly ehci_pci_hc_driver;
-static const struct ehci_driver_overrides pci_overrides __initdata = {
+static const struct ehci_driver_overrides pci_overrides __initconst = {
.reset =ehci_pci_setup,
};
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..6a18f11 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -58,7 +58,7 @@ static int ehci_platform_reset(struct usb_hcd *hcd)
static struct hc_driver __read_mostly ehci_platform_hc_driver;
-static const struct ehci_driver_overrides platform_overrides __initdata = {
+static const struct ehci_driver_overrides platform_overrides __initconst = {
.reset =ehci_platform_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] Fix initconst in ehci driver
On Mon, 22 Apr 2013, Andi Kleen wrote: From: Andi Kleen a...@linux.intel.com Signed-off-by: Andi Kleen a...@linux.intel.com diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c You left out ehci-spear, ehci-s5p, and ehci-msm. 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 v2] usb: ehci-s5p: fix: Fix null pointer dereferencing
On 04/09/13 22:12, Vivek Gautam wrote: 7edb3da: (USB: EHCI: make ehci-s5p a separate driver) raised an issue with ehci-s5p's driver data. Now that 's5p_ehci_hcd' doesn't maintain pointer to 'usb_hcd' and s5p_ehci is nothing but a pointer to hcd-priv; add hcd to the driver data rather than s5p_ehci. This fixes issues with null pointer dereferencing in s5p_ehci_shutdown(), s5p_ehci_suspend(), s5p_ehci_resume(). Signed-off-by: Vivek Gautamgautam.vi...@samsung.com CC: Manjunath Goudarmanjunath.gou...@linaro.org CC: Arnd Bergmanna...@arndb.de CC: Jingoo Hanjg1@samsung.com Acked-by: Kukjin Kim kgene@samsung.com Thanks. - Kukjin --- Based on 'usb-next' drivers/usb/host/ehci-s5p.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index d8cb0ca..580548a 100644 --- a/drivers/usb/host/ehci-s5p.c +++ b/drivers/usb/host/ehci-s5p.c @@ -173,7 +173,7 @@ static int s5p_ehci_probe(struct platform_device *pdev) goto fail_add_hcd; } - platform_set_drvdata(pdev, s5p_ehci); + platform_set_drvdata(pdev, hcd); return 0; -- 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] Fix initconst in ehci driver
On Mon, Apr 22, 2013 at 01:16:11PM -0400, Alan Stern wrote: On Mon, 22 Apr 2013, Andi Kleen wrote: From: Andi Kleen a...@linux.intel.com Signed-off-by: Andi Kleen a...@linux.intel.com diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c You left out ehci-spear, ehci-s5p, and ehci-msm. They all don't have this problem. They const declarations are not __init* -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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] Fix initconst in ehci driver
On Mon, 22 Apr 2013, Andi Kleen wrote:
On Mon, Apr 22, 2013 at 01:16:11PM -0400, Alan Stern wrote:
On Mon, 22 Apr 2013, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
Signed-off-by: Andi Kleen a...@linux.intel.com
diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
diff --git a/drivers/usb/host/ehci-platform.c
b/drivers/usb/host/ehci-platform.c
You left out ehci-spear, ehci-s5p, and ehci-msm.
They all don't have this problem. They const declarations are not
__init*
What do you mean? Take a look at ehci-msm.c, for example, starting
around line 198:
static const struct ehci_driver_overrides msm_overrides __initdata = {
.reset = ehci_msm_reset,
};
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 v5 0/9] Reorganize R8A7779/Marzen USB code
Hello. Hello. On 04/22/2013 06:51 PM, Russell King - ARM Linux wrote: Hello. Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130419' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data Please can you rethink how you use get_maintainers.pl and send out patches? Sending them To everyone who get_maintainers.pl spits out is all well and good, but it means that there's no discrimination between those who have a primary interest in the patches and those who don't. Heh, yet I completely ignore the commit signers list that it has a habit to spitting out. :-) Examples of people with a primary interest: those maintaining the platforms and/or those who you want to merge your patches. These should be on the To: line. Those who don't: everyone else who may have an interest - these go on the Cc: line. You're about the only person I regularly get patches for platforms which are sent To: me all the time, and really they are not important for me (though they are important enough for me to be Cc'd). OK, I'll try to make this distinction in the future. I just didn't think the difference between To: and Cc: was really that important to anyone. What I'm saying is that having come back from a vacation last Tuesday, I could not just scan through this mailbox for all messages marked To me and treat those as being more important than everything else, because soo many of yours were captured by that. And I'm still tacking the backlog today, almost a week later. Sorry about that. Please be more considerate to those who you're mailing. (Also, make sure you don't honor the Mail-Followup-To: header, which will lead your mailer to keep placing all recipients into the To: header on reply - because it breaks the above reasoning. The To: header should be those recipients who you are directly discussing, and Cc: is for interested side parties.) That would be somewhat tougher, as I'm usually quick to hit the send button after completing the email, so can forget to change people from To: list to CC: list... but I'll have to promise to try to give it more attention from now on. Thanks. 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] Fix initconst in ehci driver
What do you mean? Take a look at ehci-msm.c, for example, starting
around line 198:
Maybe you changed it recently. It's not in 3.8-rc*
My LTO tree is only based on 3.8 at this point, not linux-next.
-Andi
static const struct ehci_driver_overrides msm_overrides __initdata = {
.reset = ehci_msm_reset,
};
Alan Stern
--
a...@linux.intel.com -- Speaking for myself only.
--
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: [RFT] xhci - correct comp_mode_recovery_timer on return from hibernate
On 04/18/2013 05:12 PM, Sarah Sharp wrote: On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote: Sarah, This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7. I can attach the S3_Suspend_message.log, if you like, but here are the last few lines. Is it hanging on suspend or on resume? Does S3 work on 3.9-rc7 with your original patch (without the new comp_timer_running variable)? Does S3 work on the effected system with vanilla 3.9-rc7? Sarah, Just to let you know I haven't forgotten you ... I have been sidetracked by hardware or firmware problems. I need to try a different system. -- 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] Fix initconst in ehci driver
On Mon, 22 Apr 2013, Andi Kleen wrote: What do you mean? Take a look at ehci-msm.c, for example, starting around line 198: Maybe you changed it recently. It's not in 3.8-rc* My LTO tree is only based on 3.8 at this point, not linux-next. Ah -- that's right, and it's why I specified linux-next in an earlier email. (By the way, what's LTO?) Tell you what... Let's hold off on these patches until 3.10-rc1 is out and then do all of them at once. Okay? 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 V2] usb: storage: Convert US_DEBUGP to usb_stor_dbg
On Fri, 19 Apr 2013, Joe Perches wrote:
@@ -966,11 +934,13 @@ static int realtek_cr_autosuspend_setup(struct us_data
*us)
static void realtek_cr_destructor(void *extra)
{
struct rts51x_chip *chip = (struct rts51x_chip *)extra;
-
- US_DEBUGP(%s: ---\n, __func__);
+ struct us_data *us;
if (!chip)
return;
+
+ us = chip-us;
+
#ifdef CONFIG_REALTEK_AUTOPM
if (ss_en) {
del_timer(chip-rts51x_suspend_timer);
From linux-next:
drivers/usb/storage/realtek_cr.c: In function 'realtek_cr_destructor':
drivers/usb/storage/realtek_cr.c:942:11: error: 'struct rts51x_chip' has no
member named 'us'
chip-us here is only defined when CONFIG_REALTEK_AUTOPM is 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
[PATCH 0/4] staging: dwc2: a few patches for dwc2 driver
Hi Greg, Here are a few patches for the dwc2 driver. The first three are some minor fixes/cleanups, and the last is a new platform device driver interface from Matthijs. Please apply. -- Paul Matthijs Kooijman (1): staging: dwc2: add platform device bindings Paul Zimmerman (3): staging: dwc2: fix potential null pointer access staging: dwc2: add missing newlines to debug messages staging: dwc2: check for null pointer before dereferencing it Documentation/devicetree/bindings/staging/dwc2.txt | 15 +++ drivers/staging/dwc2/Kconfig | 6 +- drivers/staging/dwc2/Makefile | 2 + drivers/staging/dwc2/core_intr.c | 2 +- drivers/staging/dwc2/hcd.c | 5 +- drivers/staging/dwc2/hcd_ddma.c| 10 +- drivers/staging/dwc2/hcd_intr.c| 13 +- drivers/staging/dwc2/platform.c| 145 + 8 files changed, 181 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/staging/dwc2.txt create mode 100644 drivers/staging/dwc2/platform.c -- 1.8.2.rc0.16.g20a599e -- 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 1/4] staging: dwc2: fix potential null pointer access
We were testing hsotg pointer for null after we had already
dereferenced it
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/staging/dwc2/hcd_ddma.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/dwc2/hcd_ddma.c b/drivers/staging/dwc2/hcd_ddma.c
index ab88f50..d2180b2 100644
--- a/drivers/staging/dwc2/hcd_ddma.c
+++ b/drivers/staging/dwc2/hcd_ddma.c
@@ -217,18 +217,18 @@ static void dwc2_update_frame_list(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh,
struct dwc2_host_chan *chan;
u16 i, j, inc;
- if (!qh-channel) {
- dev_err(hsotg-dev, qh-channel = %p, qh-channel);
+ if (!hsotg) {
+ pr_err(hsotg = %p, hsotg);
return;
}
- if (!hsotg) {
- dev_err(hsotg-dev, --hsotg = %p, hsotg);
+ if (!qh-channel) {
+ dev_err(hsotg-dev, qh-channel = %p, qh-channel);
return;
}
if (!hsotg-frame_list) {
- dev_err(hsotg-dev, ---hsotg-frame_list = %p,
+ dev_err(hsotg-dev, hsotg-frame_list = %p,
hsotg-frame_list);
return;
}
--
1.8.2.rc0.16.g20a599e
--
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 2/4] staging: dwc2: add missing newlines to debug messages
A few debug messages were missing newlines, add them
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/staging/dwc2/core_intr.c | 2 +-
drivers/staging/dwc2/hcd.c | 4 ++--
drivers/staging/dwc2/hcd_ddma.c | 6 +++---
drivers/staging/dwc2/hcd_intr.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/dwc2/core_intr.c b/drivers/staging/dwc2/core_intr.c
index 44c0166..4c9ad14 100644
--- a/drivers/staging/dwc2/core_intr.c
+++ b/drivers/staging/dwc2/core_intr.c
@@ -453,7 +453,7 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
int retval = 0;
if (dwc2_check_core_status(hsotg) 0) {
- dev_warn(hsotg-dev, Controller is disconnected);
+ dev_warn(hsotg-dev, Controller is disconnected\n);
goto out;
}
diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index 7a144c1..65b7348 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
@@ -1311,7 +1311,7 @@ static void dwc2_conn_id_status_change(struct work_struct
*work)
}
if (count 250)
dev_err(hsotg-dev,
- Connection id status change timed out);
+ Connection id status change timed out\n);
hsotg-op_state = OTG_STATE_B_PERIPHERAL;
dwc2_core_init(hsotg, false, -1);
dwc2_enable_global_interrupts(hsotg);
@@ -1328,7 +1328,7 @@ static void dwc2_conn_id_status_change(struct work_struct
*work)
}
if (count 250)
dev_err(hsotg-dev,
- Connection id status change timed out);
+ Connection id status change timed out\n);
hsotg-op_state = OTG_STATE_A_HOST;
/* Initialize the Core for Host mode */
diff --git a/drivers/staging/dwc2/hcd_ddma.c b/drivers/staging/dwc2/hcd_ddma.c
index d2180b2..5c0fd27 100644
--- a/drivers/staging/dwc2/hcd_ddma.c
+++ b/drivers/staging/dwc2/hcd_ddma.c
@@ -218,17 +218,17 @@ static void dwc2_update_frame_list(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh,
u16 i, j, inc;
if (!hsotg) {
- pr_err(hsotg = %p, hsotg);
+ pr_err(hsotg = %p\n, hsotg);
return;
}
if (!qh-channel) {
- dev_err(hsotg-dev, qh-channel = %p, qh-channel);
+ dev_err(hsotg-dev, qh-channel = %p\n, qh-channel);
return;
}
if (!hsotg-frame_list) {
- dev_err(hsotg-dev, hsotg-frame_list = %p,
+ dev_err(hsotg-dev, hsotg-frame_list = %p\n,
hsotg-frame_list);
return;
}
diff --git a/drivers/staging/dwc2/hcd_intr.c b/drivers/staging/dwc2/hcd_intr.c
index caa31ba..a8d8c53 100644
--- a/drivers/staging/dwc2/hcd_intr.c
+++ b/drivers/staging/dwc2/hcd_intr.c
@@ -2069,7 +2069,7 @@ int dwc2_hcd_intr(struct dwc2_hsotg *hsotg)
int retval = 0;
if (dwc2_check_core_status(hsotg) 0) {
- dev_warn(hsotg-dev, Controller is disconnected);
+ dev_warn(hsotg-dev, Controller is disconnected\n);
return 0;
}
--
1.8.2.rc0.16.g20a599e
--
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 3/4] staging: dwc2: check for null pointer before dereferencing it
We were testing qtd-urb pointer for null after we had already
dereferenced it
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/staging/dwc2/hcd_intr.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/dwc2/hcd_intr.c b/drivers/staging/dwc2/hcd_intr.c
index a8d8c53..6e5dbed 100644
--- a/drivers/staging/dwc2/hcd_intr.c
+++ b/drivers/staging/dwc2/hcd_intr.c
@@ -1377,13 +1377,12 @@ static void dwc2_hc_nyet_intr(struct dwc2_hsotg *hsotg,
hsotg-core_params-dma_enable 0) {
qtd-complete_split = 0;
qtd-isoc_split_offset = 0;
- if (++qtd-isoc_frame_index == qtd-urb-packet_count) {
- if (qtd-urb)
- dwc2_host_complete(hsotg,
- qtd-urb-priv,
- qtd-urb, 0);
+ if (qtd-urb
+ ++qtd-isoc_frame_index == qtd-urb-packet_count) {
+ dwc2_host_complete(hsotg, qtd-urb-priv,
+ qtd-urb, 0);
dwc2_release_channel(hsotg, chan, qtd,
- DWC2_HC_XFER_URB_COMPLETE);
+DWC2_HC_XFER_URB_COMPLETE);
} else {
dwc2_release_channel(hsotg, chan, qtd,
DWC2_HC_XFER_NO_HALT_STATUS);
--
1.8.2.rc0.16.g20a599e
--
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 4/4] staging: dwc2: add platform device bindings
From: Matthijs Kooijman matth...@stdin.nl
This adds a dwc_platform.ko module that can be loaded by using
compatible = snps,dwc2 in a device tree.
Signed-off-by: Matthijs Kooijman matth...@stdin.nl
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
Documentation/devicetree/bindings/staging/dwc2.txt | 15 +++
drivers/staging/dwc2/Kconfig | 6 +-
drivers/staging/dwc2/Makefile | 2 +
drivers/staging/dwc2/hcd.c | 1 +
drivers/staging/dwc2/platform.c| 145 +
5 files changed, 167 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/staging/dwc2.txt
create mode 100644 drivers/staging/dwc2/platform.c
diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt
b/Documentation/devicetree/bindings/staging/dwc2.txt
new file mode 100644
index 000..1a1b7cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -0,0 +1,15 @@
+Platform DesignWare HS OTG USB 2.0 controller
+-
+
+Required properties:
+- compatible : snps,dwc2
+- reg : Should contain 1 register range (address and length)
+- interrupts : Should contain 1 interrupt
+
+Example:
+
+usb@101c {
+compatible = ralink,rt3050-usb, snps,dwc2;
+reg = 0x101c 4;
+interrupts = 18;
+};
diff --git a/drivers/staging/dwc2/Kconfig b/drivers/staging/dwc2/Kconfig
index 2f75be7..f0b4739 100644
--- a/drivers/staging/dwc2/Kconfig
+++ b/drivers/staging/dwc2/Kconfig
@@ -8,9 +8,11 @@ config USB_DWC2
USB controller based on the DesignWare HSOTG IP Core.
If you choose to build this driver as dynamically linked
- modules, the core module will be called dwc2.ko, and the
+ modules, the core module will be called dwc2.ko, the
PCI bus interface module (if you have a PCI bus system)
- will be called dwc2_pci.ko.
+ will be called dwc2_pci.ko and the platform interface module
+ (for controllers directly connected to the CPU) will be called
+ dwc2_platform.ko.
NOTE: This driver at present only implements the Host mode
of the controller. The existing s3c-hsotg driver supports
diff --git a/drivers/staging/dwc2/Makefile b/drivers/staging/dwc2/Makefile
index 6dccf46..11529d3 100644
--- a/drivers/staging/dwc2/Makefile
+++ b/drivers/staging/dwc2/Makefile
@@ -19,5 +19,7 @@ dwc2-y+= hcd_queue.o
hcd_ddma.o
ifneq ($(CONFIG_PCI),)
obj-$(CONFIG_USB_DWC2) += dwc2_pci.o
endif
+obj-$(CONFIG_USB_DWC2) += dwc2_platform.o
dwc2_pci-y += pci.o
+dwc2_platform-y+= platform.o
diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index 65b7348..827ab78 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
@@ -2693,6 +2693,7 @@ void dwc2_set_all_params(struct dwc2_core_params *params,
int value)
for (i = 0; i size; i++)
p[i] = -1;
}
+EXPORT_SYMBOL_GPL(dwc2_set_all_params);
/*
* Initializes the HCD. This function allocates memory for and initializes the
diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
new file mode 100644
index 000..1f3d581
--- /dev/null
+++ b/drivers/staging/dwc2/platform.c
@@ -0,0 +1,145 @@
+/*
+ * platform.c - DesignWare HS OTG Controller platform driver
+ *
+ * Copyright (C) Matthijs Kooijman matth...@stdin.nl
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS
+ * IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR
Re: How to safe recover USB driver from broken hardware situation
On Mon, Apr 22, 2013 at 11:26:05AM -0400, Alan Stern wrote: On Mon, 22 Apr 2013, Peter Chen wrote: Hi all, Recently, I have several customers troubled in safe recover USB function during the ESD situation (or some other situations, like short dp/dm, ground dp/dm, etc). I designed the ESD detect and recovery process, but I met some sync problems between host controller driver (eg, ehci) and class driver (eg, mass storage). For example, when khubd tries to disconnect usb device, it will try to stop thread usb-storage, but usb-storage is waiting some transfers to finish, qTD and QH operation may be finished (usb_submit_urb does not return error), but no watchdog timer and completion interrupt are occurred. I have: esd_detect_process and esd_recovery_process at host controller driver. At esd_detect_porcess It will disable usb interrupt and judge ASE and PSE, etc. At esd_recovery_process: It needs to reset controller (usbcmd.rst, and toggle portsc.pp bit, etc) I would like to have some synchronization mechanism between usb_submit_urb or (ehci_urb_enqueue) and my esd_detect_process and esd_recovery_process. But still not find a safe one, eg, I still met khubd's status changes D problem described above. Any suggestions are appreciated, Thanks. Your recovery process should not need to make all these changes to ehci-hcd. Simply carry out the same actions as the dead: statement label in ehci_irq() -- that is, do the same thing as if an interrupt occurred with the STS_FATAL bit set. That code is all properly synchronized. Sometimes, there are no STS_FATAL and STA_ERR when ESD occurs. So, you suggest do the same thing for STS_FATAL at my esd_recovery_process? Then unbind the driver from the controller and rebind it. Rebinding will reset the controller. You mean unbind the controller driver? Any existed API can be called? I can't do rmmod at that time. Thanks. -- Best Regards, Peter Chen -- 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 v5 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
On Mon, Apr 22, 2013 at 05:34:05PM +0400, Sergei Shtylyov wrote: Hello. On 22-04-2013 5:09, Simon Horman wrote: USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and registered in the Marzen board file. Move the data and code to their proper place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[] to 8a7779_standard_devices[] -- this seems legitimate since they are registered I've been pointed to the types in the above variable names privately. Don't know should I resend or Simon could fix s/8a7779/r8a7779/ while applying... well, the USB patches haven't been ACK'ed yet. I can fix that up. Is the series waiting on anything? Probably on Felipe's ACKs on rcar-phy.c patches... Felipe hasn't appeared on this list for a week but I see his mails from today. Thanks, lets wait a little longer for his feedback. Please feel free to ping me if things stagnate. from r8a7779_add_standard_devices() anyway. Note that I'm deliberately changing the USB PHY platform device's 'id' field from (previously just omitted) 0 to -1 as the device is a single of its kind. Note also that the board and SoC code have to be in one patch to keep the code bisectable... The patch has been tested on the Marzen board. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Acked-by: Simon Horman horms+rene...@verge.net.au WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
