Hello,
there is a spec from USB regarding high current charging (on top of USB3.0).
Do you know if there is any driver support required, and if so, when will this
be available with Linux?
Best regards
Carsten
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
> Hi,
>
> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> > Hi Felipe,
> >
> > On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripar
On 25.02.2015 12:11, Maxime Ripard wrote:
> On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
>> Hi,
>>
>> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
>>> Hi Felipe,
>>>
>>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
Hi,
On Tue, Feb 2
On 02/23/2015 11:28 PM, Felipe Balbi wrote:
On Fri, Feb 06, 2015 at 09:01:16AM +0800, Peter Chen wrote:
On Thu, Feb 05, 2015 at 09:24:02PM +0800, Zhangfei Gao wrote:
Since phy is definitely used in usb controller, load the phy
earlier to make boot time shorter.
Signed-off-by: Zhangfei Gao
-
On 02/23/2015 11:36 PM, Felipe Balbi wrote:
Hi,
On Sun, Feb 22, 2015 at 11:10:36AM +0800, zhangfei wrote:
+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
+{
+ struct usb_otg *otg = priv->phy.otg;
+
+ if (!otg->gadget)
+ return;
+
+ if (o
Hi Felipe,
Can you take this series or would you like me to resend it?
BR,
Yousaf
> -Original Message-
> From: Kaukab, Yousaf
> Sent: Monday, February 2, 2015 10:55 AM
> To: linux-usb@vger.kernel.org; ba...@ti.com; ricardo.riba...@gmail.com;
> st...@rowland.harvard.edu
> Cc: Kaukab, Yousa
On Wed, Feb 25, 2015 at 08:39:49AM +, Schmid, Carsten wrote:
> Hello,
>
> there is a spec from USB regarding high current charging (on top of USB3.0).
> Do you know if there is any driver support required, and if so, when
> will this be available with Linux?
I think the spec will answer the "
On Mon, Nov 24, 2014 at 04:17:12PM -0800, Andrew Bresticker wrote:
> This series adds support for xHCI on NVIDIA Tegra SoCs. This includes:
> - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI,
> - patches 4 and 5: adding a driver for the mailbox used to communicate
>with t
On 23.02.2015 19:02, Aleksander Morgado wrote:
> On Mon, Feb 23, 2015 at 4:23 PM, Mathias Nyman
> wrote:
>> Hi
>>
>> On 23.02.2015 13:52, Aleksander Morgado wrote:
>>> When a control transfer has a short data stage, the xHCI controller
>>> generates
>>> two transfer events: a COMP_SHORT_TX event
On Wed, Feb 25, 2015 at 09:28:36PM +0800, zhangfei wrote:
> +static void hi6220_detect_work(struct work_struct *work)
> +{
> + struct hi6220_priv *priv =
> + container_of(work, struct hi6220_priv, work.work);
> + int gpio_id, gpio_vbus;
>
Hi,
On Wed, Feb 25, 2015 at 09:19:30PM +0800, zhangfei wrote:
> >>>Since phy is definitely used in usb controller, load the phy
> >>>earlier to make boot time shorter.
> >>>
> >>>Signed-off-by: Zhangfei Gao
> >>>---
> >>> drivers/usb/Makefile | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 delet
When a control transfer has a short data stage, the xHCI controller
generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short,
only the
COMP_SUCCESS event occurs. There
Hi Thierry,
> Sorry for taking so awfully long to look at this. I've spent some time
> looking at various pieces of documentation and I concluded that
> representing the port assignment as muxing options doesn't seem right
> after all. Instead I've come up with an alternate proposal (attached).
>
On Mon, Feb 23, 2015 at 05:17:58AM -0700, Max Mansfield wrote:
> This patch integrates Cyber Cortex AV boards with the existing
> ftdi_jtag_quirk in order to
> use serial port 0 with JTAG which is required by the manufacturers' software.
>
> Steps: 2
>
> [ftdi_sio_ids.h]
> 1. Defined the device
On Tue, Feb 24, 2015 at 06:16:18PM +0800, Peter Hung wrote:
> The F81232 bulk-in is RX data + LSR channel, data format is
> [LSR+Data][LSR+Data]. , We had implemented in f81232_process_read_urb().
>
> Signed-off-by: Peter Hung
> ---
> drivers/usb/serial/f81232.c | 69
> +
On Tue, Feb 24, 2015 at 06:16:20PM +0800, Peter Hung wrote:
> The interrupt endpoint will report current IIR. If we got IIR with MSR changed
> , We will do read MSR with interrupt_work worker to do f81232_read_msr()
> function.
>
> We also confirmd MSR strange delta value is not locking-issue. The
On Tue, Feb 24, 2015 at 06:16:22PM +0800, Peter Hung wrote:
> We put FCR/IER initial step to f81232_port_enable(). When port is open,
> it set MSR interrupt on. Otherwise set it off.
>
> Signed-off-by: Peter Hung
> ---
> drivers/usb/serial/f81232.c | 39 +++
>
On Tue, Feb 24, 2015 at 06:16:21PM +0800, Peter Hung wrote:
> This patch implement relative MCR/MSR function, such like
> tiocmget()/tiocmset()/dtr_rts()/carrier_raised()
>
> original f81232_carrier_raised() compared with wrong value UART_DCD.
> It's should compared with UART_MSR_DCD.
>
> Signed-
On Tue, Feb 24, 2015 at 06:16:17PM +0800, Peter Hung wrote:
> We add f81232_get_register()/f81232_set_register() and necessary defines
> for future patch with communication with F81232 USB control endpoint.
>
> Because of this is a preparatory patch, there are unused function warning
> with compili
On Tue, Feb 24, 2015 at 06:16:23PM +0800, Peter Hung wrote:
> The original driver had do not any h/w change in driver.
> This patch implements with configure H/W for
> baud/parity/word length/stop bits functional in f81232_set_termios().
>
> This patch also implement DTR/RTS control when baudrate
Hi Neil,
On Tue, Feb 24, 2015 at 03:01:29PM +1100, NeilBrown wrote:
> twl4030_charger currently finds the associated phy
> using usb_get_phy() which will return the first USB2 phy.
> If your platform has multiple such phys (as mine does),
> this is not reliable (and reliably fails on the GTA04).
>
Hi Alan,
I think I see what's going on. Permit me to comment on your
explanation of urb->use_count first, since it's relevant later on.
> Here's the story:
>
> A new URB has its use_count set to 0 by usb_init_urb.
>
> The use_count is incremented when the URB is submitted,
>
On Wed, Feb 25, 2015 at 09:27:36AM -0800, Andrew Bresticker wrote:
> Hi Thierry,
>
> > Sorry for taking so awfully long to look at this. I've spent some time
> > looking at various pieces of documentation and I concluded that
> > representing the port assignment as muxing options doesn't seem righ
On Wed, Feb 25, 2015 at 1:15 PM, Thierry Reding
wrote:
> On Wed, Feb 25, 2015 at 09:27:36AM -0800, Andrew Bresticker wrote:
>> Hi Thierry,
>>
>> > Sorry for taking so awfully long to look at this. I've spent some time
>> > looking at various pieces of documentation and I concluded that
>> > repres
Redundant bitwise operation on 'pm' in 'switch' statement.
Signed-off-by : Ameen Ali
---
drivers/usb/host/ohci-tmio.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
index e9a6eec..c580615 100644
--- a/drivers/usb/host/ohci-tmio.
The "break" statements are missing by intention.
On Wed, 25 Feb 2015, Ameen Ali wrote:
> Redundant bitwise operation on 'pm' in 'switch' statement.
Why do you say the operations are redundant?
> Signed-off-by : Ameen Ali
> ---
> drivers/usb/host/ohci-tmio.c | 3 +++
> 1 file changed, 3 insert
Hi Sudeep,
Thank you for the patch.
On Tuesday 24 February 2015 17:53:42 Sudeep Holla wrote:
> As per the ISP1761 data sheet, the DcChipID register represents
> the hardware version number (0015h) and the chip ID (8210h) for the
> Peripheral Controller.
>
> This patch fixes the chip ID value use
Without those we will see a kernel WARN()
when loading musb on am335x devices.
Signed-off-by: Felipe Balbi
---
drivers/dma/cppi41.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 512cb8e2805e..4e9cc8e8100c 100644
--- a/drivers/dma/cppi41.c
+
On Wed, Feb 11, 2015 at 7:35 PM, Bjorn Andersson
wrote:
> Changing the name of the regulator_set_optimum_mode() to
> regulator_set_load() better reflects that the API is doing.
>
Any comments on this?
I'm going to propose a patch to the mmc framework calling this api, so
it would be good to know
Just another AX88178-based 10/100/1000 USB-to-Ethernet dongle. This one
shows up in lsusb as: "Sitecom Europe B.V. LN-028 Network USB 2.0 Adapter".
Signed-off-by: Luca Ceresoli
Cc: Francois Romieu
Cc: "David S. Miller"
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
drivers/
30 matches
Mail list logo
