On Wed, Dec 21, 2016 at 05:34:52PM -0600, Karthik Ramana Sankar wrote:
> Hi Linux-USB members,
>
> I currently have a Intel Xeon based Dell poweredge T320 server setup
> running Ubuntu server 14.04. I would like to add multiple USB3 devices
> (peripheral mode) to the system using multiple PLX base
dmesg with the patch applied
[root@localhost ~]# dmesg
[ 108.575683] usb 4-1.3: new SuperSpeed USB device number 3 using xhci_hcd
[ 108.596485] usb 4-1.3: New USB device found, idVendor=152d,
idProduct=9561
[ 108.603350] usb 4-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=5
[
The gpiod_get* function family does not want the -gpio suffix.
Use devm_gpiod_get_index_optional instead of devm_gpiod_get_optional.
The descriptor based APIs handle active high/low automatically.
The vbus-gpios are output, request enable while getting the gpio.
Don't try to get any vbus-gpios for
usb_get_dr_mode() expects the device-property to be spelled
"dr_mode" not "dr-mode".
Spelling it properly fixes the following warning showing up in dmesg:
[ 8704.500545] dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to
gadget
Signed-off-by: Hans de Goede
---
drivers/usb/dwc3/dwc3-pc
Using PLATFORM_DEVID_AUTO leads to an unpredictable name for the
platform child-device, which in turn makes it impossible for a phy
driver to use phy_create_lookup to register a phy attached to the
dwc3 controller, as that requires a constant dev_name.
This commit fixes this by using our own id al
On Thu, 2016-12-22 at 15:43 +0530, George Cherian wrote:
> dmesg with the patch applied
Hi,
did you apply both patches, yours and the one I posted?
And did you physically disconnect your device?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe
The Intel cherrytrail xhci controller has an extended cap mmio-range
which contains registers to control the muxing to the xhci (host mode)
or the dwc3 (device mode) and vbus-detection for the otg usb-phy.
Having a phy driver included in the xhci code (or under drivers/usb/host)
is not desirable.
Hi All,
Here are 2 patches which can and should be merged separately, but
which do belong together, as together they add support for the
usb-phy / mux bits found in the Intel Cherrytrail xhci vendor defined
extended capabilities registers.
I did not want to hide an entire phy driver inside the xh
Add a phy driver for the OTG USB PHY muxing and Vbus valid bits in the
Intel Vendor Defined XHCI extended capabilities region found on
Cherrytrail SoCs.
Note this depends on the xhci driver registering a platform device
named "phy_intel_cht_usb", which has an IOMEM resource 0 which points
to the I
Hi,
Hans de Goede writes:
> Hi All,
>
> Here are 2 patches which can and should be merged separately, but
> which do belong together, as together they add support for the
> usb-phy / mux bits found in the Intel Cherrytrail xhci vendor defined
> extended capabilities registers.
>
> I did not want
Hi,
On 22-12-16 13:11, Felipe Balbi wrote:
Hi,
Hans de Goede writes:
Hi All,
Here are 2 patches which can and should be merged separately, but
which do belong together, as together they add support for the
usb-phy / mux bits found in the Intel Cherrytrail xhci vendor defined
extended capabi
Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns für weitere Informationen.
--
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
Hi,
Hans de Goede writes:
>>> Here are 2 patches which can and should be merged separately, but
>>> which do belong together, as together they add support for the
>>> usb-phy / mux bits found in the Intel Cherrytrail xhci vendor defined
>>> extended capabilities registers.
>>>
>>> I did not want
Hi,
On 22-12-16 14:18, Felipe Balbi wrote:
Hans de Goede writes:
Baolu has worked on this for months but it turned out that several folks
said 'no' to his patchset. You're not really dealing with a PHY, it's
just a portmux which can generate some UTMI messages to make sure dwc3
is happy.
Hi Hans,
[auto build test ERROR on v4.9-rc8]
[also build test ERROR on next-20161222]
[cannot apply to usb/usb-testing phy/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/usb
From: Jérémy Lefaure
The function bfin_fifo_offset is defined but not used:
drivers/usb/musb/blackfin.c:36:12: warning: ‘bfin_fifo_offset’ defined
but not used [-Wunused-function]
static u32 bfin_fifo_offset(u8 epnum)
^~~~
Adding bfin_fifo_offset to bfin_ops fixes this
On 22.12.2016 14:45, Hans de Goede wrote:
Hi,
On 22-12-16 13:11, Felipe Balbi wrote:
Hi,
Hans de Goede writes:
Hi All,
Here are 2 patches which can and should be merged separately, but
which do belong together, as together they add support for the
usb-phy / mux bits found in the Intel Cher
Sorry for the multiple e-mails, re-sending my response message as a
plain text email.
Hi Greg,
Thanks a lot for the quick response!
Another quick question: In case of multiple PCIe cards, while loading
the g_mass_storage driver how do you associate a particular instance
of the driver to a partic
On Thu, Dec 22, 2016 at 10:32:38AM -0600, Karthik Ramana Sankar wrote:
> Another quick question: In case of multiple PCIe cards, while loading
> the g_mass_storage driver how do you associate a particular instance
> of the driver to a particular physical USB3 device PCIe card?
The same way you do
On Thu, Dec 22, 2016 at 08:43:55AM +0100, Peter Rosin wrote:
> The gpiod_get* function family does not want the -gpio suffix.
> Use devm_gpiod_get_index_optional instead of devm_gpiod_get_optional.
> The descriptor based APIs handle active high/low automatically.
> The vbus-gpios are output, reques
On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote:
> New property "snps,incr-burst-type-adjustment = , " for USB3.0 DWC3.
> Field "x": 1/0 - undefined length INCR burst type enable or not;
> Field "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type.
>
> While enabling un
Hi,
On 22-12-16 17:28, Mathias Nyman wrote:
On 22.12.2016 14:45, Hans de Goede wrote:
Hi,
On 22-12-16 13:11, Felipe Balbi wrote:
Hi,
Hans de Goede writes:
Hi All,
Here are 2 patches which can and should be merged separately, but
which do belong together, as together they add support for
On Thu, 22 Dec 2016, Greg KH wrote:
> On Thu, Dec 22, 2016 at 10:32:38AM -0600, Karthik Ramana Sankar wrote:
> > Another quick question: In case of multiple PCIe cards, while loading
> > the g_mass_storage driver how do you associate a particular instance
> > of the driver to a particular physical
On Wed, 21 Dec 2016, George Cherian wrote:
> Hi Oliver,
>
> I was working with this JMicron device and using the uas driver.
> I am seeing the following 2 issues.
>
> 1) On connect I see the following messages.
> xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or
> incorrect s
Hi,
On 12/22/2016 07:47 PM, Hans de Goede wrote:
> +static int intel_cht_usb_phy_probe(struct platform_device *pdev)
> +{
> + struct intel_cht_usb_phy *phy;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + resource_size_t size;
> + int i, ret;
> +
> + phy
Hi,
On 12/22/2016 09:18 PM, Felipe Balbi wrote:
> Hi,
>
> Hans de Goede writes:
Here are 2 patches which can and should be merged separately, but
which do belong together, as together they add support for the
usb-phy / mux bits found in the Intel Cherrytrail xhci vendor defined
>>>
Hi,
On 12/23/2016 06:10 AM, Hans de Goede wrote:
> Hi,
>
> On 22-12-16 17:28, Mathias Nyman wrote:
>> On 22.12.2016 14:45, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 22-12-16 13:11, Felipe Balbi wrote:
Hi,
Hans de Goede writes:
> Hi All,
>
> Here are 2 patches which c
On 2016-12-22 18:27, Greg Kroah-Hartman wrote:
> On Thu, Dec 22, 2016 at 08:43:55AM +0100, Peter Rosin wrote:
>> The gpiod_get* function family does not want the -gpio suffix.
>> Use devm_gpiod_get_index_optional instead of devm_gpiod_get_optional.
>> The descriptor based APIs handle active high/lo
Hi, Rob,
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, December 23, 2016 2:45 AM
> To: Jerry Huang
> Cc: ba...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; li...@armlinux.org.uk; devicet...@vger.kernel.org;
> linux-us
Hi Alan,
On Friday 23 December 2016 04:14 AM, Alan Stern wrote:
On Wed, 21 Dec 2016, George Cherian wrote:
Hi Oliver,
I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.
1) On connect I see the following messages.
xhci_hcd :00:11.0: ERROR
Hi Greg & Alan,
Thanks a lot for your responses. I am not very familiar with the
net2280 driver code. I will look into the net2280 driver code and the
associated USB mass storage gadget code and will let you know if I
have any further questions. I will also go ahead and buy couple of
USB3380 PCIe
In command timer function, xhci_handle_command_timeout(), xhci->lock
is unlocked before call into xhci_abort_cmd_ring(). This might cause
race between the timer function and the event handler.
The xhci_abort_cmd_ring() function sets the CMD_RING_ABORT bit in the
command register and polling it unt
Hi Mathias,
This is a follow-up patch for below comment
"fix the lock to cover abort+CRR check, and send it to usb-linus +stable"
in below discussion thread.
https://lkml.org/lkml/2016/12/21/186
It's based on v4.9.
Best regards,
Lu Baolu
Lu Baolu (1):
usb: xhci: hold lock over xhci_abort_c
Hi Mathias,
This is a follow-up patch for below comment
"rebase OGAWA Hirofumi's changes on top of that, and send to usb-linus only"
in below discussion thread.
https://lkml.org/lkml/2016/12/21/186
I rebased the patch and added unlock-before and lock-after xhci->lock during
waiting for the com
From: OGAWA Hirofumi
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
.
If xhci host fails to response to a command, the command
watchdog timer will be fired. The callback function will
abort and clear current command and restart the command
execution. If driver fails to restart command execution,
it will assume there is a larger problem in host and
report the situatio
Hi Mathias,
This patch series is for command timeout refactoring.
Patches
usb: xhci: remove unnecessary second abort try
usb: xhci: remove CRR polling in xhci_abort_cmd_ring()
are follow-ups of your comments of
"remove unnecessary second abort try as a separate patch, send to usb-next"
and
The second try was a workaround for (what we thought was) command
ring failing to stop in the first place. But this turns out to be
due to the race that we have fixed(see "xhci: Fix race related to
abort operation"). With that fix, it is time to remove the second
try.
Signed-off-by: Lu Baolu
---
xHCI driver aborts the command ring by setting CA (Command
Abort) bit in the command register. With this setting, host
should abort all command executions and generate a command
completion event with the completion code set to command
ring stopped. Software should time the completion of command
abo
Writing the CMD_RING_ABORT bit in xhci command register should
cause a command completion event with the command completion
code set to command ring stopped. However on some hosts, the
CMD_RING_RUNNING bit is correctly cleared but the completion
event is never sent.
Current xhci driver treats the
40 matches
Mail list logo
