Hi,
Petr Kulhavy writes:
> + - ti,usb2-phy-refclock-hz : Integer. Frequency in Hz of the USB 2.0 PHY
> reference clock,
> + either provided by the internal PLL or an external source.
> + The supported values are: 12MHz, 13MHz, 19.2MHz, 20MHz, 24MHz, 26MHz,
> 38.4MHz, 40MHz, 48MHz.
why
On Fri 11-03-16 12:56:10, Tejun Heo wrote:
> Hello, Jan.
>
> On Thu, Mar 03, 2016 at 10:33:10AM +0100, Jan Kara wrote:
> > > Ugh... that's nasty. I wonder whether the right thing to do is making
> > > writeback workers non-freezable. IOs are supposed to be blocked from
> > > lower layer anyway.
On 03/14/2016 11:27 AM, Greg Kroah-Hartman wrote:
> On Mon, Mar 14, 2016 at 09:09:22AM +0800, Lu Baolu wrote:
>> On 03/11/2016 08:06 AM, Greg Kroah-Hartman wrote:
>>> On Tue, Mar 08, 2016 at 03:53:44PM +0800, Lu Baolu wrote:
+struct intel_mux_dev {
+ struct device *dev;
+ char
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Monday, March 14, 2016 12:26 PM
> To: Rajesh Bhagat
> Cc: gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-o...@vger.kernel.org; Sriram Dash
> ; Rajesh Bha
On 13.03.2016 11:16, Mike Murdoch wrote:
On 2016-03-01 16:32, Mathias Nyman wrote:
On 18.02.2016 18:34, Mike Murdoch wrote:
On 2016-02-18 16:12, Mathias Nyman wrote:
On 16.02.2016 23:58, main.ha...@googlemail.com wrote:
On 2016-02-08 15:31, Mathias Nyman wrote:
Hi
On 06.02.2016 19:08,
Adds disable receiver detection in P3 quirk in DWC3 driver.
Rajesh Bhagat (2):
usb: dwc3: add disable receiver detection in P3 quirk
Documentation: dt: dwc3: Add snps,dis_rxdet_inp3_quirk property
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
drivers/usb/dwc3/core.c
Some freescale QorIQ platforms require to disable receiver detection
in P3 for correct detection of USB devices. If GUSB3PIPECTL(DISRXDETINP3)
is set, Core will change PHY power state to P2 and then perform receiver
detection. After receiver detection, Core will change PHY power state to
P3. Same q
On 10.03.2016 12:54, Alexandr Ivanov wrote:
In drivers/usb/host/xhci-ring.c there are two functions
(xhci_queue_bulk_tx and queue_bulk_sg_tx) that are very similar,
so a lot of code duplication.
This patch merges these functions into to one xhci_queue_bulk_tx.
Also counting the needed TRBs is mer
Add snps,dis_rxdet_inp3_quirk property which disables receiver detection
in PHY P3 power state.
Signed-off-by: Sriram Dash
Signed-off-by: Rajesh Bhagat
---
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/
Hi,
> Hi,
>
> Yoshihiro Shimoda writes:
> > [ text/plain ]
> > On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0) of
> > HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit
> > address memory pointers actually. So, in this case, this driver should
> > call dma_set_cohere
Hi,
> Yoshihiro Shimoda writes:
>
> > [ text/plain ]
> > This patch fixes an issue that cannot work if R-Car Gen2/3 run on
> > above 4GB physical memory environment to use a quirk XHCI_CLEAR_AC64.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/usb/host/xhci-plat.c | 7 +++
> >
This patch fixes an issue that cannot work if R-Car Gen2/3 run on
above 4GB physical memory environment to use a quirk XHCI_NO_64BIT_SUPPORT.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/host/xhci-plat.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/host/xhci
This patch set is based on the latest usb.git / usb-next branch.
(commit id = ce53bfc4374cada8b645765e2b4ad5831e760932)
Changes from v2:
- Change the quirk name to "XHCI_NO_64BIT_SUPPORT".
- Add comments for R-Car Gen2/3 (like a patch v1) in xhci-plat.c.
Changes from v1:
- Add a new quirk "XHC
On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0) of
HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit
address memory pointers actually. So, in this case, this driver should
call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup().
Otherwise, the xHCI contro
On Sat, 2016-03-12 at 20:30 -0800, Greg KH wrote:
> On Sat, Mar 12, 2016 at 07:56:03PM -0800, bruce m beach wrote:
> > I believe I can change the Device descriptors in firmware,
> > upload the new firmware and reboot the stick but wouldn't
> > the usb subsystem have the old device descriptor from t
On Sat, Mar 05, 2016 at 03:10:11PM +0100, Andrew Lunn wrote:
> > So, would you like to accept the generic solution like below:
> >
> > - Create a generic power sequence driver, and it will be probed
> > according to compatible string at device tree. At its probe,
> > we can create a power sequence
On Wed, Mar 09, 2016 at 05:16:50PM -0600, Li Yang wrote:
> On Tue, Mar 8, 2016 at 9:40 PM, Bjorn Andersson
> wrote:
> > On Tue, Mar 8, 2016 at 11:52 AM, Li Yang wrote:
> >> On Wed, Mar 2, 2016 at 4:59 PM, Li Yang wrote:
> >>> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
> >>> wrote:
>
Yoshihiro Shimoda writes:
> [ text/plain ]
> This patch set is based on the latest usb.git / usb-next branch.
> (commit id = ce53bfc4374cada8b645765e2b4ad5831e760932)
>
> Changes from v2:
> - Change the quirk name to "XHCI_NO_64BIT_SUPPORT".
> - Add comments for R-Car Gen2/3 (like a patch v1) in
Have you tested that bulk transfers still work as they should?
Yes, I have tested it with EJ168 USB 3.0 Host Controller and USB 3.0
storage device and didn't find any problems.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vge
On Fri, 2016-03-11 at 11:54 -0500, Alan Stern wrote:
> Perhaps I didn't do a good job of addressing the real underlying
> problem. That's why I asked if this was the right approach.
>
> In Daniel's case, usbhid_start() never got called. Perhaps that's the
> real problem? Anyway, this meant tha
The powermate driver expects at least one valid USB endpoint in its
probe function. If given malicious descriptors that specify 0 for
the number of endpoints, it will crash. Validate the number of
endpoints on the interface before using them.
The full report for this issue can be found here:
htt
On Mon, 14 Mar 2016, Jan Kara wrote:
> On Fri 11-03-16 12:56:10, Tejun Heo wrote:
> > Hello, Jan.
> >
> > On Thu, Mar 03, 2016 at 10:33:10AM +0100, Jan Kara wrote:
> > > > Ugh... that's nasty. I wonder whether the right thing to do is making
> > > > writeback workers non-freezable. IOs are supp
The iowarrior driver expects at least one valid endpoint. If given
malicious descriptors that specify 0 for the number of endpoints,
it will crash in the probe function. Ensure there is at least
one endpoint on the interface before using it.
The full report of this issue can be found here:
http:
The driver can be crashed with devices that expose crafted
descriptors with too few endpoints.
See:
http://seclists.org/bugtraq/2016/Mar/61
Signed-off-by: Oliver Neukum
---
drivers/usb/serial/digi_acceleport.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/serial/digi_accel
This addresses the DoS issue with respect to checking the number of ports
Ralf reported here:
http://seclists.org/bugtraq/2016/Mar/61
Could someone with the requisite hardware please test?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-us
On Mon, 14 Mar 2016, Oliver Neukum wrote:
> On Fri, 2016-03-11 at 11:54 -0500, Alan Stern wrote:
>
> > Perhaps I didn't do a good job of addressing the real underlying
> > problem. That's why I asked if this was the right approach.
> >
> > In Daniel's case, usbhid_start() never got called. Per
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) conditionally restarting IO
> > c) reset the flag
>
> Daniel's
Hi,
We're using Linux 3.14.60 and we'd like to use the Chipidea USB driver
that comes with it.
We enabled USB support as "built-in" (ie: not as kernel module):
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_PHY
On 2016-03-14 10:06, Mathias Nyman wrote:
> On 13.03.2016 11:16, Mike Murdoch wrote:
>>
>>
>> On 2016-03-01 16:32, Mathias Nyman wrote:
>>> On 18.02.2016 18:34, Mike Murdoch wrote:
On 2016-02-18 16:12, Mathias Nyman wrote:
> On 16.02.2016 23:58, main.ha...@googlemail.com wrote:
Hi Michal,
On 11/03/16 23:07, Michal Nazarewicz wrote:
> On Wed, Mar 09 2016, Felipe F. Tonello wrote:
>> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
>> devices.
>>
>> That caused the OUT endpoint to freeze if the host send any data packet of
>> length greater than 2
On Mon, Mar 14, 2016 at 10:12:53AM -0400, Josh Boyer wrote:
> The powermate driver expects at least one valid USB endpoint in its
> probe function. If given malicious descriptors that specify 0 for
> the number of endpoints, it will crash. Validate the number of
> endpoints on the interface befor
On Mon, Mar 14, 2016 at 09:15:48AM -0700, Greg Kroah-Hartman wrote:
> On Mon, Mar 14, 2016 at 10:12:53AM -0400, Josh Boyer wrote:
> > The powermate driver expects at least one valid USB endpoint in its
> > probe function. If given malicious descriptors that specify 0 for
> > the number of endpoint
On Mon, Mar 14, 2016 at 12:15 PM, Greg Kroah-Hartman
wrote:
> On Mon, Mar 14, 2016 at 10:12:53AM -0400, Josh Boyer wrote:
>> The powermate driver expects at least one valid USB endpoint in its
>> probe function. If given malicious descriptors that specify 0 for
>> the number of endpoints, it will
On Mon, Mar 14, 2016 at 9:46 AM, Josh Boyer wrote:
> On Mon, Mar 14, 2016 at 12:15 PM, Greg Kroah-Hartman
> wrote:
>> On Mon, Mar 14, 2016 at 10:12:53AM -0400, Josh Boyer wrote:
>>> The powermate driver expects at least one valid USB endpoint in its
>>> probe function. If given malicious descrip
On Mon, Mar 14, 2016 at 12:46:26PM -0400, Josh Boyer wrote:
> On Mon, Mar 14, 2016 at 12:15 PM, Greg Kroah-Hartman
> wrote:
> > On Mon, Mar 14, 2016 at 10:12:53AM -0400, Josh Boyer wrote:
> >> The powermate driver expects at least one valid USB endpoint in its
> >> probe function. If given malici
Setting up a gadget with the uac2 function results in:
Unable to handle kernel NULL pointer dereference at virtual address 0058
...
PC is at dwc2_hsotg_irq+0x7f0/0x908
LR is at dwc2_hsotg_irq+0x4c/0x908
Backtrace:
[] (dwc2_hsotg_irq) from []
(handle_irq_event_percpu+0x130/0x3ec)
Hi,
For various reasons I have been looking into the handling of virtual
monitor interfaces in drivers that link with the mac80211 module.
It is my understanding that monitor interfaces per se. are not "passed
down" to the driver module, and that driver modules should handle the
IEEE80211_CO
On Mon, Mar 14, 2016 at 08:47:34PM +, Roger James wrote:
> Hi,
>
> For various reasons I have been looking into the handling of virtual monitor
> interfaces in drivers that link with the mac80211 module.
Wonderful, but try sending this to the netdev@ mailing list, not
linux-usb :)
good luck!
On Sat, Mar 12, 2016 at 04:27:29PM -0800, Greg KH wrote:
> On Sat, Mar 12, 2016 at 11:44:51PM +, Nicolas Saenz Julienne wrote:
> > Signed-off-by: Nicolas Saenz Julienne
> > ---
> > drivers/usb/class/cdc-acm.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/usb/class/
Hi Guenter,
On Thu, Mar 10, 2016 at 3:54 AM, Guenter Roeck wrote:
> On 03/09/2016 06:29 PM, Alexey Klimov wrote:
>>
>> This patch creates new driver that supports StreamLabs usb watchdog
>> device. This device plugs into 9-pin usb header and connects to
>> reset pin and reset button on common PC.
Hi Alexey,
On 03/14/2016 06:02 PM, Alexey Klimov wrote:
Hi Guenter,
On Thu, Mar 10, 2016 at 3:54 AM, Guenter Roeck wrote:
On 03/09/2016 06:29 PM, Alexey Klimov wrote:
This patch creates new driver that supports StreamLabs usb watchdog
device. This device plugs into 9-pin usb header and conn
On 03/14/2016 02:00 AM, Felipe Balbi wrote:
Hi,
Petr Kulhavy writes:
+ - ti,usb2-phy-refclock-hz : Integer. Frequency in Hz of the USB 2.0 PHY
reference clock,
+ either provided by the internal PLL or an external source.
+ The supported values are: 12MHz, 13MHz, 19.2MHz, 20MHz, 24MHz
Greg wrote:
> lsusb is looking at the descriptor that the device originally gave the
> operating system and parsing that. You can't dynamically change your
> descriptors without resetting your device and having the OS restart it.
Oliver wrote:
> The firmware uploader may need to do a reset though.
43 matches
Mail list logo
