On Fri, Aug 23, 2019 at 02:11:28PM +, Schmid, Carsten wrote:
> Using managed device resources in usb_hcd_pci_probe() allows devm usage for
> resource subranges, such as the mmio resource for the platform device
> created to control host/device mode mux, which is a xhci extended
> capability, an
writes:
> +static int cdc_ncm_resume (struct usb_interface *intf)
> +{
> + struct usbnet *dev = usb_get_intfdata(intf);
> + struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
> + int ret;
> +
> + ret = usbnet_resume(intf);
> + if (ret != 0)
> + goto erro
On Fri, 2019-08-23 at 11:21 -0400, Alan Stern wrote:
> > I wonder since f_tcm is also the only user, whether we could change
> > the
> > matching logic to either:
> >
> >- Don't try to match, return streams is available. This could be
> > problematic if the UDC supports streams on some EPs and
Hi Alan,
> From: Alan Stern, Sent: Saturday, August 24, 2019 12:33 AM
>
> On Fri, 23 Aug 2019, Yoshihiro Shimoda wrote:
>
> > This patch fixes an issue that the following error is
> > possible to happen when ohci hardware causes an interruption
> > and the system is shutting down at the same tim
Auto-delink requires writing special registers to ums-realtek device.
Unconditionally enable auto-delink may break newer devices.
So only enable auto-delink by default for the original three IDs,
0x0138, 0x0158 and 0x0159.
Realtek is working on a patch to properly support auto-delink for other
ID
The option named "auto_delink_en" is a bit misleading, as setting it to
false doesn't really disable auto-delink but let auto-delink be firmware
controlled.
Rename it to reflect the real usage of this parameter.
Signed-off-by: Kai-Heng Feng
---
drivers/usb/storage/realtek_cr.c | 10 +-
On Mon, Aug 26, 2019 at 12:46:29PM +0800, Kai-Heng Feng wrote:
> The option named "auto_delink_en" is a bit misleading, as setting it to
> false doesn't really disable auto-delink but let auto-delink be firmware
> controlled.
>
> Rename it to reflect the real usage of this parameter.
>
> Signed-o
On Mon, Aug 26, 2019 at 12:46:30PM +0800, Kai-Heng Feng wrote:
> Auto-delink requires writing special registers to ums-realtek device.
> Unconditionally enable auto-delink may break newer devices.
>
> So only enable auto-delink by default for the original three IDs,
> 0x0138, 0x0158 and 0x0159.
>
The option named "auto_delink_en" is a bit misleading, as setting it to
false doesn't really disable auto-delink but let auto-delink be firmware
controlled.
Update the description to reflect the real usage of this parameter.
Signed-off-by: Kai-Heng Feng
---
v2:
- Only update module parameter des
Auto-delink requires writing special registers to ums-realtek device.
Unconditionally enable auto-delink may break newer devices.
So only enable auto-delink by default for the original three IDs,
0x0138, 0x0158 and 0x0159.
Realtek is working on a patch to properly support auto-delink for other
ID
[Sorry, I had previously sent the message to the list but has been
rejected. Sorry for any duplicate]
Il giorno ven, 23/08/2019 alle 16.42 -0400, Alan Stern ha scritto:
> On Fri, 23 Aug 2019, Andrea Vai wrote:
>
> > Il giorno mar, 20/08/2019 alle 13.13 -0400, Alan Stern ha scritto:
> > > On Mon,
On Wed, Aug 14, 2019 at 9:57 PM Mathias Nyman
wrote:
>
> On 11.8.2019 11.22, Ikjoon Jang wrote:
> > Xhci re-enables a slot on transaction error in set_address using
> > xhci_disable_slot() + xhci_alloc_dev().
> >
> > But in this case, xhci_alloc_dev() creates debugfs entries upon an
> > existing d
12 matches
Mail list logo
