Hi,
On Fri, Apr 12, 2013 at 01:55:02AM +, Paul Zimmerman wrote:
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Tuesday, April 09, 2013 12:42 AM
> >
> > On Tue, Apr 09, 2013 at 02:36:51AM +, Paul Zimmerman wrote:
> > > I'm getting a crash when I rmmod the dwc3-pci driver in latest
On Thursday 11 April 2013 10:28:33 Dan Williams wrote:
> > Looks it isn't a good practice to duplicate code in above four functions,
> > but
> > it should be OK to merge first.
>
> Oliver requested this approach. I'd originally taken your suggestion to
> merge them, but this proved somewhat more
On Thursday, April 11, 2013 5:00 PM Alan Stern wrote:
> On Thu, 11 Apr 2013, Andrzej Pietrasiewicz wrote:
>
> > This adds a new sysfs root device to serve as a replacement for
> > devices which are available only when a gadget is being bound.
> >
> > It is motivated by adding configfs support to U
Hi Folks,
I am trying to understand working of one hibernation scenario wrt to usb
device controller say dwc3.
1. Host PC goes to suspend and enters into U3.
2. Device also enters U3 and generate hibernation event to software.
3. At this moment system with usb device goes to power save mode
(s
On Fri, Apr 12, 2013 at 2:37 PM, Oliver Neukum wrote:
>> The work will complete when memory is reclaimed, and the rx/tx path is
>> still working, so memory reclaim can continue and the deadlock may not
>> be caused, may it?
>
> Only if the memory allocation goes to the same interface. If the block
On Friday 12 April 2013 17:42:46 Ming Lei wrote:
> On Fri, Apr 12, 2013 at 2:37 PM, Oliver Neukum wrote:
> >> The work will complete when memory is reclaimed, and the rx/tx path is
> >> still working, so memory reclaim can continue and the deadlock may not
> >> be caused, may it?
> >
> > Only if t
On Fri, Apr 12, 2013 at 6:02 PM, Oliver Neukum wrote:
> On Friday 12 April 2013 17:42:46 Ming Lei wrote:
>> On Fri, Apr 12, 2013 at 2:37 PM, Oliver Neukum wrote:
>> >> The work will complete when memory is reclaimed, and the rx/tx path is
>> >> still working, so memory reclaim can continue and th
Oliver Neukum writes:
> On Friday 12 April 2013 17:42:46 Ming Lei wrote:
>
>> Wrt. the usbnet_status_start() API, looks no good reason to call
>> it in another queue context, it should be enough to call it in probe() or
>> bind() if init_status() can be put before info->bind() in usbnet_probe().
>
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
---
v2: remove useless debug prints
change module author and copyright
use "usb" in devicetree example instead of "otg"
---
Documentation/devicetree
Hi Marc,
> > /** > > + * dwc2_load_property() - Load a single property from the
> > devicetree
> > + * node into the given variable.
> > + *
> > + * @dev: Platform device
> > + * @res: The variable to put the loaded value into
> > + * @name: The name of the devicetree property to load
> > + */
>
Hi Paul,
> These are the core parameters that I think are needed right now:
>
> dma_enable
> dma_desc_enable
> host_rx_fifo_size
> host_nperio_tx_fifo_size
> host_perio_tx_fifo_size
> max_transfer_size
> max_packet_count
> host_channels
>
> p
On Fri, 12 Apr 2013, victor yeo wrote:
> Thanks, i print out additional information in gadget driver and UDC
> driver. Here are another problem. In usbmon trace, the time difference
> between first SCSI_INQUIRY command and the second TEST_UNIT_READY
> command is large. So i check the driver log fi
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/staging/dwc2/hcd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dw
On Fri, Apr 12, 2013 at 10:41:48PM +0800, Wei Yongjun wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as returned elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Patch looks good good to me.
Reviewed-by: Matthijs Kooijman
Gr.
Matthijs
--
T
Begin forwarded message:
Date: Fri, 12 Apr 2013 07:27:18 -0700
From: "bugzilla-dae...@bugzilla.kernel.org"
To: "step...@networkplumber.org"
Subject: [Bug 56521] New: No support of Motorola ZN5 USBnet in zaurus module
https://bugzilla.kernel.org/show_bug.cgi?id=56521
Summary: No
On Fri, Apr 12, 2013 at 08:32:59AM -0700, Stephen Hemminger wrote:
> Created an attachment (id=98391)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=98391)
> zaurus.patch
We need a patch in email form.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb
Hi,
>> Thanks, i print out additional information in gadget driver and UDC
>> driver. Here are another problem. In usbmon trace, the time difference
>> between first SCSI_INQUIRY command and the second TEST_UNIT_READY
>> command is large. So i check the driver log file. When SCSI_INQUIRY is
>> rec
On Sat, 13 Apr 2013, victor yeo wrote:
> > The same thing happened when the 0xA1 command was received:
> >
> >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12,
> >> Hi=512
> >> g_file_storage gadget: bulk-in, length 0:
> >> [start_transfer] 43425355 12
> >> ept1 in queue l
On Tue, Mar 19, 2013 at 12:12:01PM -0400, Alan Stern wrote:
> If you want to find out what caused those resets, capture a usbmon
> trace for bus 2. It may provide a clue.
I've finally captured a usbmon trace at a time when it broke, but I'm
not sure what I'm looking at. I'm assuming it's a hardw
On Fri, 12 Apr 2013, Andrzej Pietrasiewicz wrote:
> > > registered with register_netdev. But in order to register it, its
> > > parent device must be known and it becomes known only later during
> > > gadget's bind.
> >
> > Why must this happen before the gadget driver is bound? What can't it
>
Hello.
On 04/12/2013 04:34 AM, Simon Horman wrote:
Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130410' 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 arc
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Friday, April 12, 2013 8:21 AM
>
> On Fri, Apr 12, 2013 at 10:41:48PM +0800, Wei Yongjun wrote:
> > Fix to return a negative error code from the error handling
> > case instead of 0, as returned elsewhere in this function.
> >
> > Signed
On Fri, Apr 12, 2013 at 06:52:40PM +, Paul Zimmerman wrote:
> > From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> > Sent: Friday, April 12, 2013 8:21 AM
> >
> > On Fri, Apr 12, 2013 at 10:41:48PM +0800, Wei Yongjun wrote:
> > > Fix to return a negative error code from the error handling
> >
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
>
> > These are the core parameters that I think are needed right now:
> >
> > dma_enable
> > dma_desc_enable
> > host_rx_fifo_size
> > host_nperio_tx_fifo_size
> > host_perio_tx_fifo_size
> > max_transfer_size
> > ma
On Fri, 12 Apr 2013, Bruce Guenter wrote:
> On Tue, Mar 19, 2013 at 12:12:01PM -0400, Alan Stern wrote:
> > If you want to find out what caused those resets, capture a usbmon
> > trace for bus 2. It may provide a clue.
>
> I've finally captured a usbmon trace at a time when it broke, but I'm
>
> From: Pratyush Anand [mailto:pratyush.an...@st.com]
> Sent: Friday, April 12, 2013 1:44 AM
>
> Hi Folks,
>
> I am trying to understand working of one hibernation scenario wrt to usb
> device controller say dwc3.
>
> 1. Host PC goes to suspend and enters into U3.
> 2. Device also enters U3 and
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Friday, April 12, 2013 3:42 AM
>
> 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
>
> ---
> v2: remove useless debug prints
> change
Hi Paul,
On Fri, Apr 12, 2013 at 09:09:51PM +, Paul Zimmerman wrote:
> > From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> > Sent: Friday, April 12, 2013 3:42 AM
> >
> > This adds a dwc_platform.ko module that can be loaded by using
> > compatible = "snps,dwc2" in a device tree.
> >
> > S
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Friday, April 12, 2013 2:33 PM
>
> On Fri, Apr 12, 2013 at 09:09:51PM +, Paul Zimmerman wrote:
> > > From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> > > Sent: Friday, April 12, 2013 3:42 AM
> > >
> > > This adds a dwc_platform.k
Hi Paul,
> Also, at the top of dwc2_driver_probe() there is a call to
> dwc2_set_all_params(), which is in a different module and thus won't
> link.
Ah, good point. I guess I should have added a
EXPORT_SYMBOL_GPL(dwc2_set_all_params) as well when adding the
declaration to hcd.h in the previous pat
Hello.
On 04/10/2013 05:31 AM, Kuninori Morimoto wrote:
Please add this "tested on xxx" comment on each patch's log area, not only on
[0/x].
We need it on "git log"
I'm going to post R8A7778/BOCK-W series following this one, and all the
patches in 1st series should additionally be test
On 04/13/2013 03:07 AM, I wrote:
Please add this "tested on xxx" comment on each patch's log area,
not only on [0/x].
We need it on "git log"
I'm going to post R8A7778/BOCK-W series following this one, and
all the
patches in 1st series should additionally be tested on BOCK-W. Well, I
Hello.
Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130412' 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-shmob
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
Sometimes there is a need to initialize some non-standard registers mapped to
the EHCI region before accessing the standard EHCI registers. Add pre_setup()
method with 'struct usb_hcd *' parameter to be called just before ehci_setup()
to the 'ehci-platform' driver's platform data for this purpos
Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since v
Now that the EHCI internal buffer setup is done by the platform code, we can
remove such code from this driver as it never really belonged here. We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).
The patch has been tested on the Marz
Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.
Signed-off-by: Sergei Shtylyov
Acked-by: Kuninori Morimoto
Acked-by: Simon Horman
---
Changes since version 3:
- lowercased the SoC name in the
The memory region that is used by the driver overlaps EHCI and OHCI register
regions for absolutely no reason now -- fix it by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...
N
Currently the driver hard-codes USBPCTRL0 register to 0. It is wrong since this
register contains board-specific USB ports configuration and so its value should
be somehow passed via the platform data. Add file with
the 'struct rcar_phy_platform_data' containing various bit fields describing
USB
Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY
Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in rcar_usb_phy_shutdown() anymore as that does not make
sense. Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.
The patch has been tested o
Hello.
Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130412' tag and the R8A7779/Marzen patchset I've just posted.
It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY
The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up during USB-PHY startup depending on
whether a ferrite bead is in use or not. So, we now handle
Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC; add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.
Also, don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7
Register the USB PHY device from bockw_init(), passing the platform data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov
---
Changes since the original pos
Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
Enable USB storage driver and SCSI disk driver that it needs as well...
Signed-off-by: Sergei Shtylyov
---
arch/arm/configs/bockw_defconfig | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
Index: rene
Ping! :)
On Tue, Apr 09, 2013 at 10:33:31PM +0400, Vladimir Murzin wrote:
> If for whatever reason we fall into fail path in xhci_mem_init()
> before bw table gets initialized we may access the uninitialized lists
> in xhci_mem_cleanup().
>
> Check for bw table before traversing lists in cleanup
48 matches
Mail list logo
