commit a6ff6cbf1fab ("usb: xhci: Add helper function xhci_set_power_on().")
created a helper to control port power that needs to be called with
xhci->lock held and interrupts disabled.
It relased the lock with spin_unlock_irqerstore using a new zero flag
variable instead of the origial flag from sp
On 12.04.2017 10:47, Ralph Sennhauser wrote:
Hi Guoqing Zhang,
Commit a6ff6cbf1fabe7500d8ac25e133e3346db0a0fca ("usb: xhci: Add helper
function xhci_set_power_on().") causes a null pointer dereference on an
armada-385. Below the kernel as well as the bisect log.
Seems Guoqing Zhang is not cur
Hi
On 12.04.2017 01:06, Dan Carpenter wrote:
Hello Guoqing Zhang,
The patch a6ff6cbf1fab: "usb: xhci: Add helper function
xhci_set_power_on()." from Apr 7, 2017, leads to the following static
checker warning:
Seems Guoqing Zhang is currently not reachable
I'll post a fix for this on the list
Hi Felipe,
On 4/11/2017 11:31 PM, Felipe Balbi wrote:
Hi,
(Thinh, for whatever I didn't receive your email via the list, replying
to myself)
Could it be because of the attached file?
Felipe Balbi writes:
Hmm, can you apply this patch and provide output when the failure
happens? I sugges
> I based my comments on the datasheet. For the LED_GPIO_CFG register, the
> datasheet says:
> > This register configures the external GPIO[2:0] pins.
>
> QFN package description also indicates GPIOs 0, 1 & 2.
> As an example for the LAN9514, pin 22 of the QFN indicates:
> > nSPD_LED/GPIO2
>
> In
Use the modern API to request MSI or MSI-X interrupts, which allows us to
get rid of the msix_entries array, as well as cleaning up the cleanup
code.
Signed-off-by: Christoph Hellwig
---
drivers/usb/host/xhci.c | 99 ++---
drivers/usb/host/xhci.h | 1
On 12/04/17 14:25, woojung@microchip.com wrote:
> > +/* LED General Purpose IO Configuration Register */
> > +#define LED_GPIO_CFG (0x24)
> > +#define LED_GPIO_CFG_SPD_LED (0x0100)/* GPIO2 as SPD LED
> > */
> > +#define LED_GPIO_CFG_LNK_LED (0x0010)/* G
On Mon, Apr 03, 2017 at 08:20:50PM +0200, Pavel Machek wrote:
> > > > > > ...1d.7: PCI fixup... pass 2
> > > > > > ...1d.7: PCI fixup... pass 3
> > > > > > ...1d.7: PCI fixup... pass 3 done
> > > > > >
> > > > > > ...followed by hang. So yes, it looks USB related.
> > > > > >
> > > > > > (Sometim
On Wed, Apr 12, 2017 at 1:13 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
John Youn writes:
>> Thinh Nguyen writes:
>>> The dwc3 driver can overwite its previous events if its top half IRQ
>>> handler gets invoked again before processing the events in the cache. We
>>>
From: Martin Wetterwald
Date: Wed, 12 Apr 2017 11:24:05 +0200
> This chip is used by a lot of embedded devices and also by the Raspberry
> Pi 1, 2 & 3 which were created to promote the study of computer
> sciences. Students wanting to learn kernel / network device driver
> programming through tho
On Wed, 12 Apr 2017, Felipe Balbi wrote:
> >> Maybe... But I can't shake the feeling that Greg KH would strongly
> >> disagree. Hasn't he said, many times in the past, that any dynamically
> >> allocated device structure _must_ have a real release routine?
> >> usb_udc_nop_release() doesn't
> +/* LED General Purpose IO Configuration Register */
> +#define LED_GPIO_CFG (0x24)
> +#define LED_GPIO_CFG_SPD_LED (0x0100)/* GPIO2 as SPD LED
> */
> +#define LED_GPIO_CFG_LNK_LED (0x0010)/* GPIO1 as LNK LED
> */
> +#define LED_GPIO_CFG_FDX_LED (0x0001)/* GPIO0 as
On Wed, Apr 12, 2017 at 5:21 PM, Peter Chen wrote:
> On Tue, Apr 11, 2017 at 08:46:24PM +0530, Niranjan Dighe wrote:
>> Currently usb_gadget_connect() is called only through gadget
>> registration via composite_driver_probe(). As a result, after a
>> disconnection, if the role transitions to host
On Wed, Apr 12, 2017 at 11:24:05AM +0200, Martin Wetterwald wrote:
> This chip is used by a lot of embedded devices and also by the Raspberry
> Pi 1, 2 & 3 which were created to promote the study of computer
> sciences. Students wanting to learn kernel / network device driver
> programming through
On Tue, Apr 11, 2017 at 08:46:24PM +0530, Niranjan Dighe wrote:
> Currently usb_gadget_connect() is called only through gadget
> registration via composite_driver_probe(). As a result, after a
> disconnection, if the role transitions to host and back to gadget,
> the gadget is not recognized by the
On Friday 07 April 2017 11:01 PM, Alexandre Bailon wrote:
>
>
> On 04/07/2017 06:15 PM, Alexandre Bailon wrote:
>>
>>
>> On 04/07/2017 04:36 PM, Sekhar Nori wrote:
>>> On Wednesday 05 April 2017 10:47 PM, Alexandre Bailon wrote:
The CPPI 4.1 DMA is sharing its clock with the USB OTG,
an
Hi,
David Laight writes:
> From: Felipe Balbi
>> David Laight writes:
>> >> > From: Felipe Balbi
>> >> >> Sent: 07 April 2017 12:37
>> >> >> Just like we did for all other endpoint types, let's rely on a chained
>> >> >> TRB pointing to ep0_bounce_addr in order to align transfer size. This
>> >
From: Felipe Balbi
> David Laight writes:
> >> > From: Felipe Balbi
> >> >> Sent: 07 April 2017 12:37
> >> >> Just like we did for all other endpoint types, let's rely on a chained
> >> >> TRB pointing to ep0_bounce_addr in order to align transfer size. This
> >> >> will make the code simpler.
> >
Hi,
David Laight writes:
>> > From: Felipe Balbi
>> >> Sent: 07 April 2017 12:37
>> >> Just like we did for all other endpoint types, let's rely on a chained
>> >> TRB pointing to ep0_bounce_addr in order to align transfer size. This
>> >> will make the code simpler.
>> > ...
>> >
>> > Is the dw
Hi,
David Laight writes:
> From: Felipe
>> Sent: 12 April 2017 06:57
>> Felipe Balbi writes:
>> >> From: Felipe Balbi
>> >>> Sent: 07 April 2017 12:37
>> >>> Just like we did for all other endpoint types, let's rely on a chained
>> >>> TRB pointing to ep0_bounce_addr in order to align transfer
From: Felipe
> Sent: 12 April 2017 06:57
> Felipe Balbi writes:
> >> From: Felipe Balbi
> >>> Sent: 07 April 2017 12:37
> >>> Just like we did for all other endpoint types, let's rely on a chained
> >>> TRB pointing to ep0_bounce_addr in order to align transfer size. This
> >>> will make the code
From: Felipe Balbi
> Sent: 12 April 2017 06:55
> David Laight writes:
>
> > From: Felipe Balbi
> >> Sent: 07 April 2017 12:37
> >> Just like we did for all other endpoint types, let's rely on a chained
> >> TRB pointing to ep0_bounce_addr in order to align transfer size. This
> >> will make the c
On 12 April 2017 at 10:24, Martin Wetterwald wrote:
> This chip is used by a lot of embedded devices and also by the Raspberry
> Pi 1, 2 & 3 which were created to promote the study of computer
> sciences. Students wanting to learn kernel / network device driver
> programming through those devices
This chip is used by a lot of embedded devices and also by the Raspberry
Pi 1, 2 & 3 which were created to promote the study of computer
sciences. Students wanting to learn kernel / network device driver
programming through those devices can only rely on the Linux kernel
driver source to make their
Am Mittwoch, den 12.04.2017, 07:13 +0800 schrieb Yuyang Du:
> With this patch, USB_SPEED_SUPER is a valid speed when attaching
> a USB3 SuperSpeed device.
>
Hi,
sorry this is just short sighted. If you do this, also add SS+
Regards
Oliver
--
To unsubscribe from this lis
Am Mittwoch, den 12.04.2017, 07:13 +0800 schrieb Yuyang Du:
> In order to support SuperSpeed devices, a USB3 HCD is added to
> share the USB2 HCD. As a result, a "VHCI" is composed of two
> vhci_hcds associated with the two HCDs respectively. So we add
> another level of abstraction, vhci, and thus
Hi Guoqing Zhang,
Commit a6ff6cbf1fabe7500d8ac25e133e3346db0a0fca ("usb: xhci: Add helper
function xhci_set_power_on().") causes a null pointer dereference on an
armada-385. Below the kernel as well as the bisect log.
Regards
Ralph
[2.481636] Unable to handle kernel NULL pointer dere
Hi,
Greg KH writes:
>> Here's what we have for most UDCs (net2280.c included):
>>
>> struct my_udc {
>> struct gadget gadget;
>> [...]
>> };
>>
>> probe()
>> {
>> struct my_udc *u;
>>
>> u = kzalloc(sizeof(*u), GFP_
On 04/11/2017 11:14 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
John Youn writes:
>> Thinh Nguyen writes:
>>> The dwc3 driver can overwite its previous events if its top half IRQ
>>> handler gets invoked again before processing the events in the cache. We
>>
>>
Each vhci has 2*VHCI_HC_PORTS ports, in which VHCI_HC_PORTS
ports are HighSpeed (or below), and VHCI_HC_PORTS are SuperSpeed.
This new macro VHCI_PORTS reflects this configuration.
Signed-off-by: Yuyang Du
---
drivers/usb/usbip/vhci.h | 5 -
drivers/usb/usbip/vhci_sysfs.c | 10 +--
As USB3 has (slightly) different bit meanings in the port
status. Add a new status bit array for USB3.
Signed-off-by: Yuyang Du
---
drivers/usb/usbip/vhci_hcd.c | 56 +++-
1 file changed, 50 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/usbip/vhc
Hi Shuah,
SuperSpeed (only) USB devices cannot be shared via usbip. This
patch series attempts to fix it.
The first 5 patches refactors the existing code to prepare for the
SuperSpeed addition. With this series, our SuperSpeed device works
fine.
Many thanks to Greg and Krzysztof for their patie
This patch adds a USB3 HCD to an existing USB2 HCD and provides
the support of SuperSpeed, in case the device can only be enumerated
with SuperSpeed.
The bulk of the added code in usb3_bos_desc and hub_control to support
SuperSpeed is borrowed from the commit 1cd8fd2887e162ad ("usb: gadget:
dummy_
With this patch, USB_SPEED_SUPER is a valid speed when attaching
a USB3 SuperSpeed device.
Signed-off-by: Yuyang Du
---
drivers/usb/usbip/vhci_sysfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index cac2319..3ad68ff 100644
This patch enables the new vhci structure. Its lock protects
both the USB2 hub and the shared USB3 hub.
Signed-off-by: Yuyang Du
---
drivers/usb/usbip/vhci.h | 2 -
drivers/usb/usbip/vhci_hcd.c | 206 -
drivers/usb/usbip/vhci_rx.c| 16 ++--
These helper function names are renamed to have their full struct
names to avoid confusion:
- hcd_to_vhci() -> hcd_to_vhci_hcd()
- vhci_to_hcd() -> vhci_hcd_to_hcd()
- vdev_to_vhci() -> vdev_to_vhci_hcd()
Signed-off-by: Yuyang Du
---
drivers/usb/usbip/vhci.h | 11 +--
drivers/u
In order to support SuperSpeed devices, a USB3 HCD is added to
share the USB2 HCD. As a result, a "VHCI" is composed of two
vhci_hcds associated with the two HCDs respectively. So we add
another level of abstraction, vhci, and thus this vhci structure.
Signed-off-by: Yuyang Du
---
drivers/usb/us
A vhci struct is added as the platform-specific data to the vhci
platform device, in order to get the vhci by its platform device.
This is done in vhci_hcd_init().
Signed-off-by: Yuyang Du
---
drivers/usb/usbip/vhci_hcd.c | 51
tools/usb/usbip/libsrc/
Every VHCI is a platform device, so move the platform_device struct
into the VHCI struct.
Signed-off-by: Yuyang Du
---
drivers/usb/usbip/vhci.h | 3 ++-
drivers/usb/usbip/vhci_hcd.c | 17 -
drivers/usb/usbip/vhci_sysfs.c | 6 +++---
3 files changed, 13 insertions(+), 13
39 matches
Mail list logo