On 11/29/2015 07:16 AM, Nicholas A. Bellinger wrote:
> Ping (2) on this series to Joel + Sebastian. ;)
>
> If there aren't any immediate objections on the fs/configfs/ side from
> JLBEC, I'll assume this series can be added as target-pending/for-next
> WIP code this week, yes..?
Yes, please. If
The gadget ethernet driver supports changing the MTU, but only allows this
when the USB cable is removed. The comment indicates that this is because
the "peer won't know". Even if the network link is still down and only the
USB link is established, the driver won't allow the change.
Other network
Hi Mian,
sorry for the bug, the fix looks correct.
Reviewed-by: Christoph Hellwig
--
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
On 30.11.2015 08:28, Saurabh Sengar wrote:
pinging in case this patch is lost.
On 6 November 2015 at 17:46, Saurabh Sengar wrote:
added iounmap inorder to free memory mapped to base before returning
Signed-off-by: Saurabh Sengar
---
drivers/usb/host/pci-quirks.c | 4 ++--
1 file changed,
Hi Mian,
Thank you for the patch.
On Saturday 28 November 2015 18:35:44 Mian Yousaf Kaukab wrote:
> 76e0da3 "usb-gadget/uvc: use per-attribute show and store methods"
> removed write permission for writeable attributes. Correct attribute
> permissions.
>
> Fixes: 76e0da3 "usb-gadget/uvc: use per
On Fri, 2015-11-27 at 18:39 -0800, Greg KH wrote:
> Yes, it's tough, I know, good luck.
>
> Also deal with multiple devices, busses that are ordered differently
> depending on the phase of the moon, and other fun things with dynamic
> devices and ioctls. It's a loosing battle :)
IMHO the fundame
Hi Mike,
[auto build test WARNING on: balbi-usb/next]
[also build test WARNING on: v4.4-rc3 next-20151127]
url:
https://github.com/0day-ci/linux/commits/Mike-Looijmans/usb-gadget-ether-Allow-changing-the-MTU/20151130-162847
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi
On Fri, 2015-11-27 at 00:04 +0100, Steinar H. Gunderson wrote:
> On Thu, Nov 26, 2015 at 01:26:32AM +0100, Steinar H. Gunderson wrote:
> >> There are numerous smaller issues: The allocated memory needs to be
> >> charged against usbfs_memory_usage
> > I'll fix this.
>
> Fixed in updated patch (at
The gadget ethernet driver supports changing the MTU, but only allows this
when the USB cable is removed. The comment indicates that this is because
the "peer won't know". Even if the network link is still down and only the
USB link is established, the driver won't allow the change.
Other network
On 27.11.2015 15:24, Mika Westerberg wrote:
There is a memory leak because acpi_evaluate_dsm() actually returns an
object which the caller is supposed to release. Fix this by calling
ACPI_FREE() for the returned object (this expands to kfree() so passing
NULL there is fine as well).
While there
Reduce number of memcpy's by 1-2 improve transmit performance by 2-4%,
or reduce CPU usage on a comparable value.
Signed-off-by: Ameen Ali
---
drivers/net/usb/smsc95xx.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c
usb2 ports need to signal resume for 20ms before moving to U0 state.
Both device and host can initiate resume.
On host initated resume port is set to resume state, sleep 20ms,
and finally set port to U0 state.
On device initated resume a port status interrupt with a port in resume
state in issued
Hi Mathias,
[auto build test WARNING on: v4.4-rc1]
[cannot apply to: v4.4-rc3 v4.4-rc2 next-20151127]
url:
https://github.com/0day-ci/linux/commits/Mathias-Nyman/xhci-fix-usb2-resume-timing-and-races/20151130-231438
config: i386-randconfig-r0-201548 (attached as .config)
reproduce
On Fri, 27 Nov 2015, Krzysztof Opasiak wrote:
> >> I run through your code and as far as I understand above is not exactly
> >> true. Your patch allows only to prevent userspace from accessing interfaces
> >> which has kernel drivers, there is no way to stop an application from
> >> taking
> >> c
On Thu, 26 Nov 2015, Steinar H. Gunderson wrote:
> On Wed, Nov 25, 2015 at 10:29:53AM -0500, Alan Stern wrote:
> > I want to see a modified version of your patch. Several things need to
> > be changed or fixed, but the major change needs to be the way memory is
> > allocated. It should be done
On 11/30/2015 05:16 PM, Alan Stern wrote:
On Fri, 27 Nov 2015, Krzysztof Opasiak wrote:
I run through your code and as far as I understand above is not exactly
true. Your patch allows only to prevent userspace from accessing interfaces
which has kernel drivers, there is no way to stop an appl
On Mon, Nov 30, 2015 at 06:12:22PM +0100, Krzysztof Opasiak wrote:
>
>
> On 11/30/2015 05:16 PM, Alan Stern wrote:
> >On Fri, 27 Nov 2015, Krzysztof Opasiak wrote:
> >
> I run through your code and as far as I understand above is not exactly
> true. Your patch allows only to prevent users
On 11/30/2015 06:20 PM, Greg KH wrote:
On Mon, Nov 30, 2015 at 06:12:22PM +0100, Krzysztof Opasiak wrote:
On 11/30/2015 05:16 PM, Alan Stern wrote:
On Fri, 27 Nov 2015, Krzysztof Opasiak wrote:
I run through your code and as far as I understand above is not exactly
true. Your patch allows
On Tue, Nov 17, 2015 at 04:00:58PM -0500, Don Zickus wrote:
> My recent Intel box is spewing these messages:
poke?
Cheers,
Don
>
> xhci_hcd :00:14.0: xHCI Host Controller
> xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> usb usb2: New USB device found, idVendor=1d6b,
On Sat, Nov 28 2015, Sergei Shtylyov wrote:
> On 11/28/2015 3:04 AM, Greg Kroah-Hartman wrote:
>
This file already uses pr_debug in a few places; this converts the
remaining printks.
>>>
>>> Are you aware that printk(KERN_DEBUG, ...) and pr_debug() are not
>>> equivalent?
>>
>> Yes
On Mon, 30 Nov 2015, Don Zickus wrote:
> On Tue, Nov 17, 2015 at 04:00:58PM -0500, Don Zickus wrote:
> > My recent Intel box is spewing these messages:
>
> poke?
>
> Cheers,
> Don
It's up to Greg KH to accept this patch; maybe you need to mail it to
him. He seems to be busy these days -- at le
On Tue, Nov 17, 2015 at 1:00 PM, Don Zickus wrote:
> My recent Intel box is spewing these messages:
>
> xhci_hcd :00:14.0: xHCI Host Controller
> xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
> usb usb2: New
USB interface drivers need to check number of endpoints before trying to
access/use them. Quite a few drivers only use the default setting
(altsetting 0), so let's allow them to declare number of endpoints in
altsetting 0 they require to operate and have USB core check it for us
instead of having e
On Mon, Nov 30, 2015 at 03:49:51PM -0500, Alan Stern wrote:
> On Mon, 30 Nov 2015, Don Zickus wrote:
>
> > On Tue, Nov 17, 2015 at 04:00:58PM -0500, Don Zickus wrote:
> > > My recent Intel box is spewing these messages:
> >
> > poke?
> >
> > Cheers,
> > Don
>
> It's up to Greg KH to accept this
On Mon, Nov 30, 2015 at 12:57:17PM -0800, Dan Williams wrote:
> On Tue, Nov 17, 2015 at 1:00 PM, Don Zickus wrote:
> > My recent Intel box is spewing these messages:
> >
> > xhci_hcd :00:14.0: xHCI Host Controller
> > xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> > usb
Because interrupt endpoints usually transmit such
small amounts of data, it seems pointless to prestart
transfers and try to get speed improvements. This
patch also sorts out a problem with CDC ECM function
where its notification endpoint gets stuck in busy
state and we continuously issue Update Tr
Hi,
Dmitry Torokhov writes:
> USB interface drivers need to check number of endpoints before trying to
> access/use them. Quite a few drivers only use the default setting
> (altsetting 0), so let's allow them to declare number of endpoints in
> altsetting 0 they require to operate and have USB c
On Mon, 2015-11-30 at 12:14 -0500, Alan Stern wrote:
> > +static struct usb_memory *
> > +find_memory_area(struct usb_dev_state *ps, const struct
> usbdevfs_urb *uurb)
> > +{
> > + struct usb_memory *usbm = NULL, *iter;
> > + unsigned long flags;
> > + unsigned long uurb_start = (unsign
On Mon, 30 Nov 2015, Oliver Neukum wrote:
> On Mon, 2015-11-30 at 12:14 -0500, Alan Stern wrote:
> > > +static struct usb_memory *
> > > +find_memory_area(struct usb_dev_state *ps, const struct
> > usbdevfs_urb *uurb)
> > > +{
> > > + struct usb_memory *usbm = NULL, *iter;
> > > + unsigned
On Mon, Nov 30, 2015 at 01:11:50PM -0800, Dmitry Torokhov wrote:
> USB interface drivers need to check number of endpoints before trying to
> access/use them. Quite a few drivers only use the default setting
> (altsetting 0), so let's allow them to declare number of endpoints in
> altsetting 0 they
On Mon, Nov 30, 2015 at 03:39:43PM -0600, Felipe Balbi wrote:
>
> Hi,
>
> Dmitry Torokhov writes:
> > USB interface drivers need to check number of endpoints before trying to
> > access/use them. Quite a few drivers only use the default setting
> > (altsetting 0), so let's allow them to declare
cp210x_get_config and cp210x_set_config were hard to use. They required
the buffer as an array of 32-bit values even for smaller values, and did
endian conversions on per-32-bit value basis, which is wrong for some
cp210x data structures (although not for any that were actually used.)
This change i
On Mon, Nov 30, 2015 at 2:18 PM, Greg Kroah-Hartman
wrote:
> On Mon, Nov 30, 2015 at 01:11:50PM -0800, Dmitry Torokhov wrote:
>> USB interface drivers need to check number of endpoints before trying to
>> access/use them. Quite a few drivers only use the default setting
>> (altsetting 0), so let's
On Mon, Nov 30, 2015 at 02:56:09PM -0800, Dmitry Torokhov wrote:
> On Mon, Nov 30, 2015 at 2:18 PM, Greg Kroah-Hartman
> wrote:
> > On Mon, Nov 30, 2015 at 01:11:50PM -0800, Dmitry Torokhov wrote:
> >> USB interface drivers need to check number of endpoints before trying to
> >> access/use them. Q
On Mon, Nov 30, 2015 at 3:36 PM, Greg Kroah-Hartman
wrote:
> On Mon, Nov 30, 2015 at 02:56:09PM -0800, Dmitry Torokhov wrote:
>> On Mon, Nov 30, 2015 at 2:18 PM, Greg Kroah-Hartman
>> wrote:
>> > On Mon, Nov 30, 2015 at 01:11:50PM -0800, Dmitry Torokhov wrote:
>> >> USB interface drivers need to
I'm seeing a problem that looks like an issue in the USB-Persist
feature. I'm finding that all my 3.0 thumb drives are torn down and
brought back up (fail USB-Persist) during resume from "suspend to
memory" if they are plugged into a 2.0 EHCI/OHCI only port on my
embedded system. This embedded syst
On Mon, Nov 30, 2015 at 04:47:18PM -0800, Dmitry Torokhov wrote:
> On Mon, Nov 30, 2015 at 3:36 PM, Greg Kroah-Hartman
> wrote:
> > On Mon, Nov 30, 2015 at 02:56:09PM -0800, Dmitry Torokhov wrote:
> >> On Mon, Nov 30, 2015 at 2:18 PM, Greg Kroah-Hartman
> >> wrote:
> >> > On Mon, Nov 30, 2015 at
Hi,
Here are two patches to fix rmmod for musb omap2430. This makes any
further work on this driver a bit easier.
Regards,
Tony
Tony Lindgren (2):
usb: musb: core: Fix handling of the phy notifications
usb: musb: Fix unbalanced pm_runtime_enable
drivers/phy/phy-twl4030-usb.c | 32 +++
We currently can't unload omap2430 MUSB platform glue driver module and
this cause issues for fixing the MUSB code further. The reason we can't
remove omap2430 is because it uses the PHY functions and also exports the
omap_musb_mailbox function that some PHY drivers are using.
Let's fix the issue
When reloading omap2430 kernel module we get a warning about
unbalanced pm_runtime_enable. Let's fix this. Note that we
need to do this after the child musb-core platform_device is
removed because of pm_runtime_irq_safe being set at the child.
Cc: Bin Liu
Cc: Felipe Balbi
Cc: Kishon Vijay Abraha
Otherwise rmmod omap2430; rmmod phy-twl4030-usb; modprobe omap2430
will try to use a non-existing phy and oops:
Unable to handle kernel paging request at virtual address b6f7c1f0
...
[] (devm_usb_get_phy_by_node) from []
(omap2430_musb_init+0x44/0x2b4 [omap2430])
[] (omap2430_musb_init [omap2430])
If we reload phy-twl4030-usb, we get a warning about unbalanced
pm_runtime_enable. Let's fix the issue and also fix idling of the
device on unload before we attempt to shut it down.
If we don't properly idle the PHY before shutting it down on removal,
the twl4030 ends up consuming about 62mW of ex
Hi,
Here are two fixes for rmmod and PM. These can be merged separately after
the review from the MUSB related changes.
Regards,
Tony
Tony Lindgren (2):
phy: twl4030-usb: Relase usb phy on unload
phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload
drivers/phy/phy-twl4030-
On Mon, 2015-11-30 at 17:09 -0800, Greg Kroah-Hartman wrote:
> > that would loop through endpoints so that drivers do not have to
> > open-code the loop and we indeed need to fix the drivers that
> blindly
> > grab endpoints at fixed offsets and expect them to be there and have
> > correct types.
>
44 matches
Mail list logo
