Hi
Oliver Neukum 於 2015/11/3 下午 06:03 寫道:
On Tue, 2015-11-03 at 11:51 +0800, Peter Hung wrote:
+static int f81534_attach(struct usb_serial *serial)
+{
+ struct f81534_serial_private *serial_priv = NULL;
+ int status;
+ int i;
+ int offset;
+ uintptr_t setting_idx =
On Wed, 2015-11-04 at 16:19 +0800, Peter Hung wrote:
> Hi
>
> Oliver Neukum 於 2015/11/3 下午 06:03 寫道:
> > On Tue, 2015-11-03 at 11:51 +0800, Peter Hung wrote:
> >> +static int f81534_attach(struct usb_serial *serial)
> >> +{
> >> + struct f81534_serial_private *serial_priv = NULL;
> >> + int stat
Hi
Andy Shevchenko 於 2015/11/3 下午 05:45 寫道:
On Tue, Nov 3, 2015 at 5:51 AM, Peter Hung wrote:
+ *Please reference https://bitbucket.org/hpeter/fintek-general/src/
+ *with f81534/tools to get set_gpio.c & set_mode.c. Please use it
+ *carefully.
Would it be good to have this under
Hi Robert,
On 03/11/15 12:53, Robert Baldyga wrote:
> USB requests in Loopback function are allocated in loopback_get_alt()
> function, so we prefer to free them rather in loopback_disable() than
> in loopback_complete() when request is completed with error. It provides
> better symetry in resourc
On 11/04/2015 11:15 AM, Felipe Ferreri Tonello wrote:
> Hi Robert,
>
> On 03/11/15 12:53, Robert Baldyga wrote:
>> USB requests in Loopback function are allocated in loopback_get_alt()
>> function, so we prefer to free them rather in loopback_disable() than
>> in loopback_complete() when request i
Bjørn Mork [2015-11-03 13:37:56]:
> I guess this means that we need to add an interface count quirk to the
> qmi_wwan driver as well? I assume there are devices out there with the
> same device ID, the same ff/ff/ff interface descriptors, but with
> QMI/net on interface #0.
Indeed, your guess i
Petr Štetiar writes:
> Bjørn Mork [2015-11-03 13:37:56]:
>
>> I guess this means that we need to add an interface count quirk to the
>> qmi_wwan driver as well? I assume there are devices out there with the
>> same device ID, the same ff/ff/ff interface descriptors, but with
>> QMI/net on interf
Hi,
On 03-11-15 16:43, Oliver Neukum wrote:
This function must be called with a spinlock held.
Memory can be allocated only with GFP_ATOMIC. Passing
a gfp_t argument is a waste.
Signed-off-by: Oliver Neukum
Patch looks good to me:
Reviewed-by: Hans de Goede
Greg, can you pick this one up
Bjørn Mork [2015-11-04 13:15:10]:
> Based on that, I wonder if it wouldn't be more appropriate to simply do
> this as a device specific quirk in the qmi_wwan probe?
So rather something like this?
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 2a7c1be.
Petr Štetiar writes:
> Bjørn Mork [2015-11-04 13:15:10]:
>
>> Based on that, I wonder if it wouldn't be more appropriate to simply do
>> this as a device specific quirk in the qmi_wwan probe?
>
> So rather something like this?
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/q
I am having "Realtek rt8188eu" WIFI usb Adapter. Ubuntu detects my wifi
connections but the problem is it fails to connect. It doesn’t connects
at all..and also its signal strength is very weak...I Had tried every
solution but no success please solve this issue. I had also tried the
latest ma
Bjørn Mork [2015-11-04 16:57:06]:
> > +#define QUECTEL_EC20_VENDORID 0x05c6
> > +#define QUECTEL_EC20_PRODUCTID 0x9215
> > +#define QUECTEL_EC20_NINTERFACES 5
> > +#define QUECTEL_EC20_QMI_IFACE_FIX 4
>
> Not directly related to the issue at hand, but I sort of hate macros
> like
On Wed, Nov 04, 2015 at 09:34:43PM +0530, Shankey wrote:
>
> I am having "Realtek rt8188eu" WIFI usb Adapter. Ubuntu detects my wifi
> connections but the problem is it fails to connect. It doesn’t connects at
> all..and also its signal strength is very weak...I Had tried every solution
> but no s
On Wed, Nov 04, 2015 at 02:20:53PM +0100, Hans de Goede wrote:
> Hi,
>
> On 03-11-15 16:43, Oliver Neukum wrote:
> >This function must be called with a spinlock held.
> >Memory can be allocated only with GFP_ATOMIC. Passing
> >a gfp_t argument is a waste.
> >
> >Signed-off-by: Oliver Neukum
>
>
On Wed, 2015-11-04 at 16:57 +0100, Bjørn Mork wrote:
> Petr Štetiar writes:
>
> > Bjørn Mork [2015-11-04 13:15:10]:
> >
> >> Based on that, I wonder if it wouldn't be more appropriate to simply do
> >> this as a device specific quirk in the qmi_wwan probe?
> >
> > So rather something like this?
On Mon, Nov 02, 2015 at 04:00:42PM -0500, Alan Stern wrote:
> That commit was included in (approximately) the 4.1.5 or later stable
> kernel, and it is included in 4.2. You should be able to put one of
> those on a bootable USB stick.
I tried going down this route. After some back and forth, I
USB3 devices, because they are much newer, have much
less chance of having issues with larger transfers.
We still keep a limit because anything above 2048
sectors really rendered negligible speed
improvements, so we will simply ignore
that. Transferring 1MiB should already give us
pretty good perf
Just so we have some sort of documentation as to why
we limit our Mass Storage transfers to 240 sectors,
let's update the comment to make clearer that
devices were found that would choke with larger
transfers.
While at that, also make sure to clarify that other
operating systems have similar, albe
On Wed, Nov 04, 2015 at 02:48:32PM -0600, Felipe Balbi wrote:
> USB3 devices, because they are much newer, have much
> less chance of having issues with larger transfers.
>
> We still keep a limit because anything above 2048
> sectors really rendered negligible speed
> improvements, so we will sim
Hi,
Greg KH writes:
> On Wed, Nov 04, 2015 at 02:48:32PM -0600, Felipe Balbi wrote:
>> USB3 devices, because they are much newer, have much
>> less chance of having issues with larger transfers.
>>
>> We still keep a limit because anything above 2048
>> sectors really rendered negligible speed
On Wed, 4 Nov 2015, Felipe Balbi wrote:
> USB3 devices, because they are much newer, have much
> less chance of having issues with larger transfers.
>
> We still keep a limit because anything above 2048
> sectors really rendered negligible speed
> improvements, so we will simply ignore
> that. Tr
On Wed, 4 Nov 2015, Felipe Balbi wrote:
> Just so we have some sort of documentation as to why
> we limit our Mass Storage transfers to 240 sectors,
> let's update the comment to make clearer that
> devices were found that would choke with larger
> transfers.
>
> While at that, also make sure to
Hi,
Alan Stern writes:
> On Wed, 4 Nov 2015, Felipe Balbi wrote:
>
>> USB3 devices, because they are much newer, have much
>> less chance of having issues with larger transfers.
>>
>> We still keep a limit because anything above 2048
>> sectors really rendered negligible speed
>> improvements,
Hello.
On 11/4/2015 11:48 PM, Felipe Balbi wrote:
Just so we have some sort of documentation as to why
we limit our Mass Storage transfers to 240 sectors,
let's update the comment to make clearer that
devices were found that would choke with larger
transfers.
While at that, also make sure to c
Hi,
Alan Stern writes:
> On Wed, 4 Nov 2015, Felipe Balbi wrote:
>
>> Just so we have some sort of documentation as to why
>> we limit our Mass Storage transfers to 240 sectors,
>> let's update the comment to make clearer that
>> devices were found that would choke with larger
>> transfers.
>>
Hi,
Sergei Shtylyov writes:
> Hello.
>
> On 11/4/2015 11:48 PM, Felipe Balbi wrote:
>
>> Just so we have some sort of documentation as to why
>> we limit our Mass Storage transfers to 240 sectors,
>> let's update the comment to make clearer that
>> devices were found that would choke with larger
The following changes since commit 32b88194f71d6ae7768a29f87fbba454728273ee:
Linux 4.3-rc7 (2015-10-25 10:39:47 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.4-rc1
for you to fetch changes up to 0bbc367e21bfeea33230d8
Without this function, when the port is closed the data in the chip's
transmit FIFO are lost. If the actual byte count is reported the close
can be delayed until all data are sent.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 60 +++
The dwc2 interrupt handler is quite slow. On rk3288 with a few things
plugged into the ports and with cpufreq locked at 696MHz (to simulate
real world idle system), I can easily observe dwc2_handle_hcd_intr()
taking > 120 us, sometimes > 150 us. Note that SOF interrupts come
every 125 us with hig
In commit 94dfd7edfd5c ("USB: HCD: support giveback of URB in tasklet
context") support was added to give back the URB in tasklet context.
Let's take advantage of this in dwc2.
This speeds up the dwc2 interrupt handler considerably.
Signed-off-by: Douglas Anderson
---
drivers/usb/dwc2/hcd.c | 4
All other host controllers who want aligned buffers for DMA do it a
certain way. Let's do that too instead of working behind the USB core's
back. This makes our interrupt handler not take forever and also rips
out a lot of code, simplifying things a bunch.
This also has the side effect of removi
Previously we needed to set the max_transfer_size to explicitly be 65535
because the old driver would detect that our hardware could support much
bigger transfers and then would try to do them. This wouldn't work
since the DMA alignment code couldn't support it.
Later in commit e8f8c14d9da7 ("usb
timeval is deprecated and not y2038 safe. Its size also changes according
to 32 bit/ 64 bit compilation. Replace it with 32 and 64 bit versions of
its individual fields, giving two ioctls with different code values.
The two ioctls are necessary to maintain the 32 bit and 64 bit userspace
compatib
On Wednesday 04 November 2015 15:29:11 Deepa Dinamani wrote:
> timeval is deprecated and not y2038 safe. Its size also changes according
> to 32 bit/ 64 bit compilation. Replace it with 32 and 64 bit versions of
> its individual fields, giving two ioctls with different code values.
> The two ioct
On 10/12/2015 2:18 AM, Gregory Herrero wrote:
> status_buf needs to be freed in dwc2_hcd_remove().
>
> Signed-off-by: Gregory Herrero
> ---
> drivers/usb/dwc2/hcd.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/
Hi,
On Wed, Nov 4, 2015 at 2:53 PM, Douglas Anderson wrote:
> In commit 94dfd7edfd5c ("USB: HCD: support giveback of URB in tasklet
> context") support was added to give back the URB in tasklet context.
> Let's take advantage of this in dwc2.
>
> This speeds up the dwc2 interrupt handler consider
On Tue, Nov 03, 2015 at 09:51:11PM -0600, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> > On Tue, Nov 03, 2015 at 07:56:55AM -0600, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Nathan Sullivan writes:
> >> > The USB OTG support currently depends on power management
> >> > (CONFIG_PM) be
Hi,
Oliver Neukum 於 2015/11/4 下午 04:38 寫道:
On Wed, 2015-11-04 at 16:19 +0800, Peter Hung wrote:
Hi
Oliver Neukum 於 2015/11/3 下午 06:03 寫道:
On Tue, 2015-11-03 at 11:51 +0800, Peter Hung wrote:
+ for (i = 0; i < F81534_NUM_PORT; ++i)
+ atomic_set(&serial_priv->port_active[i]
On 11/3/2015 12:31 PM, Douglas Anderson wrote:
> If you've got your interrupt signals bouncing a bit as you insert your
> USB device, you might end up in a state when the device is connected but
> the driver doesn't know it.
>
> Specifically, the observed order is:
> 1. hardware sees connect
> 2
Hi
Peter Hung 於 2015/11/3 上午 11:51 寫道:
> This driver is for Fintek F81532/F81534 USB to Serial Ports IC.
> Changelog:
> v6
> 1. Re-implement the write()/resume() function. Due to this device cant be
> suitable with generic write(), we'll do the submit write URB when
> write()/
On 11/3/2015 12:31 PM, Douglas Anderson wrote:
> In general it is wise to clear interrupts before processing them. If
> you don't do that, you can get:
> 1. Interrupt happens
> 2. You look at system state and process interrupt
> 3. A new interrupt happens
> 4. You clear interrupt without proce
On 10/30/2015 1:33 PM, Douglas Anderson wrote:
> This is an attempt to rehash commit 0cf884e819e0 ("usb: dwc2: add bus
> suspend/resume for dwc2") on ToT. That commit was reverted in commit
> b0bb9bb6ce01 ("Revert "usb: dwc2: add bus suspend/resume for dwc2"")
> because apparently it broke the Alt
On 11/02/2015 06:32 AM, Oliver Neukum wrote:
> It looks like the throttling code isn't perfect yet
Yeah, that's still a todo (ie., fixing the premature unthrottle).
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...
On Thu, Nov 05, 2015 at 12:10:57AM +, John Youn wrote:
> On 10/12/2015 2:18 AM, Gregory Herrero wrote:
> > status_buf needs to be freed in dwc2_hcd_remove().
> >
> > Signed-off-by: Gregory Herrero
> > ---
> > drivers/usb/dwc2/hcd.c | 19 ++-
> > 1 file changed, 18 insertions(
44 matches
Mail list logo
