This adds i.MX51 as the next user of the usbmisc driver.
Since the functional is similar i.MX53, we just rename the
definitions and add an alias for the new CPU.
Signed-off-by: Alexander Shiyan
---
drivers/usb/chipidea/usbmisc_imx.c | 40 +-
1 file changed, 22
This adds i.MX27 and i.MX31 as the next user of the usbmisc driver.
Signed-off-by: Alexander Shiyan
---
drivers/usb/chipidea/usbmisc_imx.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmis
Helló, van szüksége sürgős kölcsön néhány korai karácsonyi és hálaadás
vásárlás a barátod, és szeretett egy, akkor is, azért vagyunk itt, hogy
segítsen ki, a Jennifer pénzügyi cég is ad ki hitelt, a kamat, ami olyan
alacsony, mint 3 százalék, így üzlet elején és a lehető legjobb ajándék
a famil
> >
> > The second device with problems is Huawei E3276 (Speedstick LTE III,
> > Telekom, no Hilink, but ipv6-cabable version) This device worked before
> > with SLAAC, now with -next-20131107 it doesn't.
> Ouch. I noticed after submitting this driver that it probably has some
> flawed logic wr
On Saturday 09 November 2013 11:48:14 Greg KH did opine:
> On Sat, Nov 09, 2013 at 11:06:56AM -0500, Gene Heskett wrote:
> > So, in the interests of maintaining a square pixel, and a 1/1 pixel to
> > pixel ratio so as not to throw away usable resolution by blending or
> > interpolation effects in
On Sat, Nov 09, 2013 at 11:06:56AM -0500, Gene Heskett wrote:
> So, in the interests of maintaining a square pixel, and a 1/1 pixel to
> pixel ratio so as not to throw away usable resolution by blending or
> interpolation effects in the camera, is there a returned value in the lsusb
> -v or -vv
Greetings;
I am setting up a machine vision system, where the camera output is cropped
to the point of a pixel in the camera is 20+ on the computer screen since
we want .001" or .01mm accuracy in the final image presented to the machine
operator. Imagine if you will, a 2304xwhatever camera tha
On Sat, Nov 09, 2013 at 03:12:05PM +0100, Laurent Pinchart wrote:
> Hi Greg,
>
> On Tuesday 29 October 2013 18:47:26 Shimoda, Yoshihiro wrote:
> > Hi Laurent-san,
> >
> > (2013/10/29 7:49), Laurent Pinchart wrote:
> > > Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
> > >
Hi Greg,
On Tuesday 29 October 2013 18:47:26 Shimoda, Yoshihiro wrote:
> Hi Laurent-san,
>
> (2013/10/29 7:49), Laurent Pinchart wrote:
> > Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
> > clk_disable_unprepare() to get ready for the migration to the common
> > clock fr
Hi Felipe,
On Tuesday 29 October 2013 18:47:19 Shimoda, Yoshihiro wrote:
> Hi Laurent-san,
>
> (2013/10/29 7:49), Laurent Pinchart wrote:
> > Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
> > clk_disable_unprepare() to get ready for the migration to the common
> > clock
On Fri, Nov 08, 2013 at 08:44:35AM +0100, Bjørn Mork wrote:
> Johan Hovold writes:
>
> > Bjørn, do you want any more info for the commit message (e.g. interface
> > layout)?
>
> I believe it's nice to document the layout of complex composite devices
> if known, but if not then I don't see any ne
On Fri, Nov 08, 2013 at 10:53:11PM +0100, Colin Leitner wrote:
> This patch removes an erroneous check of CSIZE, which made it impossible to
> set
> CS5.
>
> Compiles clean, but couldn't test against hardware.
>
> Signed-off-by: Colin Leitner
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hov
On Fri, Nov 08, 2013 at 10:52:34PM +0100, Colin Leitner wrote:
> This patch removes an erroneous check of CSIZE, which made it impossible to
> set
> CS5.
>
> Compiles clean, but couldn't test against hardware.
The patch is obviously correct, but I've verified that CS5 actually
works using a MCS7
Fix race in generic write implementation, which could lead to
temporarily degraded throughput.
The current generic write implementation introduced by commit
27c7acf22047 ("USB: serial: reimplement generic fifo-based writes") has
always had this bug, although it's fairly hard to trigger and the
con
Fix regression introduced by commit 818f60365a29 ("USB: serial: add
memory flags to usb_serial_generic_write_start"), which incorrectly used
GFP_KERNEL in write(), which must not not sleep.
Reported-by: Dave Jones
Tested-by: Dave Jones
Cc: Dave Jones
Signed-off-by: Johan Hovold
---
drivers/us
Here are two bug fixes for v3.13. The first one fixes a long-standing,
non-critical, race in the generic write implementation. The second fixes
a recent regression due to the wrong memory allocation flag being used
in write(), something which for example triggers a BUG (sleep in
invalid context) wh
16 matches
Mail list logo
