Apply for a loan at 3% reply to this Email for more Info
--
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
This is a new phy driver for the SoC USB controllers on the TI DA8XX
family of microcontrollers. The USB 1.1 PHY is just a simple on/off.
The USB 2.0 PHY also allows overriding the VBUS and ID pins.
Signed-off-by: David Lechner
---
v2 changes: This is new patch in v2.
On Tue, Mar 15, 2016 at 12:54:13PM -0400, Jaret Cantu wrote:
> The TX settings can be calibrated for particular hardware. The
> phy is reset by Linux, so this cannot be handled by the bootloader.
>
> The TRM mentions that the maximum resistance should be used for the
> DN/DP calibration in order
On Thu, 17 Mar 2016, Lipengcheng wrote:
> Hi,
>In the files of ohci-platform.c and ehci-platform.c, they have only a
> control reset. Can the files have one more controller reset?
Currently only one reset is allowed.
>Our usb2 controller using a synopsis, need bus reset, root hub
On Mon, 14 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-14 at 11:03 -0400, Alan Stern wrote:
> > On Mon, 14 Mar 2016, Oliver Neukum wrote:
>
> > > It seems to me that hid_resume_common() needs to be split into three
> > > parts
> > >
> > > a) doing the stuff for pending resets
> > > b)
On Fri, Mar 18, 2016 at 4:26 PM,
Greg KH wrote:
> Hi,
>
> I'm getting the following oops with my USB sound device using Linus's
> latest tree of the moment, which has the sound tree pull in it. Anyone
> seen this before?
>
Hi Greg,
Nicolai Stange sent in a fix for
Am 29.02.2016 17:10, schrieb Greg KH:
> On Mon, Feb 29, 2016 at 02:47:45PM +0100, walter harms wrote:
>> Hello List,
>>
>> is someone aware of a problem with DTR in that driver ?
>>
>> I use: Linux version 3.4.53-MMI-SW.401_0.1-43
>
> That's a very old and obsolete kernel version. Please ask
On Fri, 18 Mar 2016, Rajesh Bhagat wrote:
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2897,10 +2897,14 @@ done:
> /* The xHC may think the device is already reset,
>* so ignore the status.
>*/
> -
On Fri, Mar 11, 2016 at 09:29:45AM +0100, Petr Kulhavy wrote:
> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
>
> Signed-off-by: Petr Kulhavy
> ---
> v1:
>
> v2:
> - using standard properties "dr_mode", "mentor,power", "mentor,num-eps",
>
Hi,
On Wed, Mar 16, 2016 at 11:28 AM, John Youn wrote:
> On 3/10/2016 11:14 AM, John Youn wrote:
>> On 3/9/2016 11:06 AM, Doug Anderson wrote:
>>> Stefan,
>>>
>>> On Wed, Mar 9, 2016 at 11:01 AM, Stefan Wahren
>>> wrote:
> Doug Anderson
Hi Baolin,
[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
Device tree binding for new phy-da8xx-usb driver.
Signed-off-by: David Lechner
---
v2 changes: This is new patch in v2.
.../devicetree/bindings/phy/phy-da8xx-usb.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644
On 03/16/2016 12:38 PM, Sergei Shtylyov wrote:
On 03/16/2016 07:57 AM, David Lechner wrote:
Also, I am not finding any existing data structure to pass the musb
set_mode
function to the phy in either usb_phy or usb_otg. Setting the mode
(host/peripheral/otg) is done in the same PHY register, so
Hi,
Gil Weber writes:
>> interesting. Wonder what Windows is doing differently. Yeah, I guess the
>> best way forward is to find which commit caused the regression and git
>> bisect is the way to do that. Would be nice to see v3.13, v3.14,
>> v3.15... are
The existing workaround of forcing DEVSPD to SUPER_SPEED
for HIGH_SPEED ports is causing another side effect
which causes erratic interrupts and delayed gadget
enumeration of upto 2 seconds.
Work around the run/stop issue by detecting if
it happened using debug LTSSM state and issuing
soft reset
On Fri, Mar 18, 2016 at 04:09:50PM -0700, Linus Torvalds wrote:
> On Fri, Mar 18, 2016 at 3:58 PM, Greg KH wrote:
> >
> > Yes, people did report issues with that yesterday, and I queued up a
> > patch for it, it's attached below, but I didn't think it would cause any
>
On Thu, 17 Mar 2016, poma wrote:
> On 17.03.2016 19:02, Jes Sorensen wrote:
> > Jes Sorensen writes:
> >> Xose Vazquez Perez writes:
> >>> Hi,
> >>>
> >>> If I do:
> >>> # echo "0bda 8176" > /sys/bus/usb/drivers/rtl8xxxu/new_id
> >>
> >> Hi Xose,
Attacks that trick drivers into passing a NULL pointer
to usb_driver_claim_interface() using forged descriptors are
known. This thwarts them by sanity checking.
Signed-off-by: Oliver Neukum
CC: sta...@vger.kernel.org
---
drivers/usb/core/driver.c | 6 +-
1 file changed, 5
-fix-setting-of-portnum/20160318-062419
config: i386-randconfig-x017-201611 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki
On Thu, Mar 17, 2016 at 11:38:42AM +0100, Oliver Neukum wrote:
> An attack using the lack of sanity checking in probe
> is known. This patch checks for the existance of a
> second port.
> CVE-2016-3136
>
> Signed-off-by: Oliver Neukum
> CC: sta...@vger.kernel.org
> ---
>
An attack using the lack of sanity checking in probe
is known. This patch checks for the existance of a
second port.
CVE-2016-3136
Signed-off-by: Oliver Neukum
CC: sta...@vger.kernel.org
---
drivers/usb/serial/mct_u232.c | 4
1 file changed, 4 insertions(+)
diff --git
On 16 March 2016 at 20:09, Oliver Neukum wrote:
> On Wed, 2016-03-16 at 19:46 +0800, Baolin Wang wrote:
>> This patch introduces the usb charger driver based on usb gadget that
>> makes an enhancement to a power driver. It works well in practice but
>> that requires a system
On 03/17/2016 03:27 PM, Chanwoo Choi wrote:
> Hi Lu,
>
> On 2016년 03월 17일 16:16, Lu Baolu wrote:
>> Hi Chanwoo,
>>
>> On 03/17/2016 02:07 PM, Chanwoo Choi wrote:
>>> Hi Lu,
>>>
>>> To handle extcon (external connector), I implemented the unique id
>>> for each external connector on patch[1]
Hi,
I have a composite usb device where order of binding the drivers to
interfaces matters.
When the device is plugged in binding is from 0-th till n-th interface
but in usb_reset_device function in /drivers/usb/core/hub.c after
reset binding is done in revers order from n-th till 0.
Is there a
Hi,
Roger Quadros writes:
> The existing workaround (for STAR#9000525659) of forcing
> DEVSPD to SUPER_SPEED for HIGH_SPEED ports is causing
> another side effect which causes erratic interrupts and delayed gadget
> enumeration of upto 2 seconds.
right, but the real problem is
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
A usb port mux could be abstracted as the following elements:
1) mux state: HOST or PERIPHERAL;
2) an extcon cable which triggers the change of mux state between
On 16 March 2016 at 19:48, Felipe Balbi wrote:
>
> Hi Baolin,
>
> Baolin Wang writes:
>> [ text/plain ]
>> Currently the Linux kernel does not provide any standard integration of this
>> feature that integrates the USB subsystem with the system power
Hi,
Gil Weber writes:
>> > I finally bisect the kernel (I didn't known that command, thanks for the
>> > tip)
>> > and found that it doesn't work anymore from this commit :
>> >
>> > b0bac2581c1918cc4ab0aca01977ad69f0bc127a is the first bad commit
>> >
On Fri, 18 Mar 2016, Mikolaj Ch wrote:
> Thanks, right I was looking at older version of Linux (3.8) before
> https://github.com/torvalds/linux/commit/6aec044cc2f5670cf3b143c151c8be846499bd15.
> But the question remains why post_reset method is called in reverse
> order for interfaces.
It is an
On Fri, Mar 18, 2016 at 03:12:15PM -0700, Greg KH wrote:
> On Fri, Mar 18, 2016 at 02:58:27PM -0700, Linus Torvalds wrote:
> > On Fri, Mar 18, 2016 at 2:43 PM, Linus Torvalds
> > wrote:
> > >
> > > Something in this - or possibly the tty pull, but that doesn't sound
On Fri, Mar 18, 2016 at 3:58 PM, Greg KH wrote:
>
> Yes, people did report issues with that yesterday, and I queued up a
> patch for it, it's attached below, but I didn't think it would cause any
> issues with non-OF systems either. I wanted to give it a few days
>
On Fri, Mar 18, 2016 at 03:51:34PM -0700, Linus Torvalds wrote:
> On Fri, Mar 18, 2016 at 2:58 PM, Linus Torvalds
> wrote:
> >
> > Yeah, the bisect is now solidly in the usb part.
>
> The commit that ends up being marked bad is odd, but there it is:
> 69bec7259853
On Fri, Mar 18, 2016 at 2:58 PM, Linus Torvalds
wrote:
>
> Yeah, the bisect is now solidly in the usb part.
The commit that ends up being marked bad is odd, but there it is:
69bec7259853 "USB: core: let USB device know device node".
Very odd, but I tested multiple
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.
Signed-off-by: Heikki Krogerus
Signed-off-by: Lu Baolu
On Wed, 2016-03-16 at 10:41 -0400, Alan Stern wrote:
> While adding your check to usb_driver_claim_interface() is a reasonable
> thing to do, it might not solve all the problems. A driver might still
> try to use the invalid interface pointer (perhaps when writing out an
> error message). It
Stefan Wahren writes:
> Hi Eric,
> hi Martin,
>
>> John Youn hat am 16. März 2016 um 19:28 geschrieben:
>>
>>
>> On 3/10/2016 11:14 AM, John Youn wrote:
>> > On 3/9/2016 11:06 AM, Doug Anderson wrote:
>> >> Stefan,
>> >>
>> >> On Wed, Mar 9, 2016
On Fri, 18 Mar 2016, Lu Baolu wrote:
> Some Intel platforms have an USB port mux controlled by GPIOs.
> There's a single ACPI platform device that provides both USB ID
> extcon device and a USB port mux device. This MFD driver will
> split the 2 devices for their respective drivers.
>
>
Greg KH writes:
> Hi,
>
> I'm getting the following oops with my USB sound device using Linus's
> latest tree of the moment, which has the sound tree pull in it. Anyone
> seen this before?
Yes, and a fix is on its way:
On Fri, Mar 18, 2016 at 02:58:27PM -0700, Linus Torvalds wrote:
> On Fri, Mar 18, 2016 at 2:43 PM, Linus Torvalds
> wrote:
> >
> > Something in this - or possibly the tty pull, but that doesn't sound
> > very likely - has killed my USB keyboard on my desktop.
>
>
On Fri, Mar 18, 2016 at 05:00:25PM -0600, Shuah Khan wrote:
> On Fri, Mar 18, 2016 at 4:26 PM,
> Greg KH wrote:
> > Hi,
> >
> > I'm getting the following oops with my USB sound device using Linus's
> > latest tree of the moment, which has the sound tree pull in it.
Hi Eric,
hi Martin,
> John Youn hat am 16. März 2016 um 19:28 geschrieben:
>
>
> On 3/10/2016 11:14 AM, John Youn wrote:
> > On 3/9/2016 11:06 AM, Doug Anderson wrote:
> >> Stefan,
> >>
> >> On Wed, Mar 9, 2016 at 11:01 AM, Stefan Wahren
> >>
Hi,
I'm getting the following oops with my USB sound device using Linus's
latest tree of the moment, which has the sound tree pull in it. Anyone
seen this before?
thanks,
greg k-h
[ +0.002298] input: Schiit Audio USB Modi Device as
42 matches
Mail list logo