Hi Laurent,
On 18/09/18 11:35, Laurent Pinchart wrote:
> USB requests for video data are queued from two different locations in
> the driver, with the same code block occurring twice. Factor it out to a
> function.
>
> Signed-off-by: Laurent Pinchart
Looks good, and simplifies locking. Win win.
Hello,
On Thu, 2 Aug 2018 14:23:51 +, Vincent Pelletier
wrote:
> On Thu, 2 Aug 2018 00:45:14 +, "He, Bo" wrote:
> > Your patch fix the issue BUG: scheduling while atomic:
>
> Yes, although from my understanding of Felipe's answer, the actual bug
> is the "scheduling" part (sleeping in
Dear Partner,
We want to transfer to overseas ($50.500, 000.00) Fifth Million Five
Hundred Thousand United States Dollars) from the Bank of Africa, I
want to ask you to quietly look for a reliable and honest person who
will be capable and fit to provide either an existing bank account or
to set u
Hi Laurent,
On 18/09/18 11:35, Laurent Pinchart wrote:
> When USB requests for video data fail to be submitted, the driver
> signals a problem to the host by halting the video streaming endpoint.
> This is only valid in bulk mode, as isochronous transfers have no
> handshake phase and can't thus r
Hi Laurent,
On 18/09/18 11:35, Laurent Pinchart wrote:
> Adding device context to the kernel log messages make them more useful.
> Add new uvcg_* macros based on dev_*() that print both the gadget device
> name and the function name.
>
> While at it, remove a commented out printk statement and an
Hi Felipe,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.git tags/uvcg-20180925
for you to fetch changes up to
Hello there,
there is quite a big trouble around few specific keyboards that are
not working in Linux.
I personally have "Lenovo Professional Wireless Keyboard and Mouse
Combo 4X30H56803"
The keyboard is not working, mouse is. There is a lot of information
spread across multiple threads of many si
On Tue, Sep 25, 2018 at 07:29:43PM +0200, Peter Hostačný wrote:
> Hello there,
>
> there is quite a big trouble around few specific keyboards that are
> not working in Linux.
> I personally have "Lenovo Professional Wireless Keyboard and Mouse
> Combo 4X30H56803"
> The keyboard is not working, mou
Yes, it is most likely HID issue.
Thank you greatly for such a fast answer and for the direction!
Peter
On Tue, 25 Sep 2018 at 19:39, Greg KH wrote:
>
> On Tue, Sep 25, 2018 at 07:29:43PM +0200, Peter Hostačný wrote:
> > Hello there,
> >
> > there is quite a big trouble around few specific keyboa
> Hi Peter,
>
> On Fri, Sep 21, 2018 at 09:48:43AM +0800, Peter Chen wrote:
> > Type-C-to-A cable, and the USB3 HCD has already been NULL at that time.
> > The oops log like below:
> >
> > [681.782288] xhci-hcd xhci-hcd.1.auto: remove, state 1 [681.787490]
> > usb usb4: USB disconnect, device nu
On Fri, Sep 21, 2018 at 09:26:27PM +0900, Yoshihiro Shimoda wrote:
> This patch set is based on the latest Greg's usb.git / usb-testing branch
> (the commit id is ae8a2ca8a2215c7e31e6d874f7303801bb15fbbc)
>
> The previous code set the mode as peripheral mode by the UGCTRL2 register
> for R-Car D3.
On 9/24/2018 6:39 PM, Mathias Nyman wrote:
> On 21.09.2018 16:22, Sandeep Singh wrote:
>> From: Sandeep Singh
>>
>> Observed "TRB completion code (27)" error which corresponds to Stopped -
>> Length Invalid error(xhci spec section 4.17.4) while connecting USB to
>> SATA bridge.
>>
>> Looks like
Hi John,
On 9/24/2018 22:52, John Stultz wrote:
> On Sun, Sep 23, 2018 at 10:57 PM, Artur Petrosyan
> wrote:
>> Hi John,
>>
>> On 9/21/2018 05:05, John Stultz wrote:
>>> On Thu, Sep 20, 2018 at 7:17 AM, Artur Petrosyan
>>> wrote:
On 5/23/2018 01:57, John Stultz wrote:
> Its done automat
On Mon, Sep 24, 2018 at 04:31:51PM +0200, Karoly Pados wrote:
> This patch allows using the CBUS pins of FT-X devices as GPIO in CBUS
> bitbanging mode. There is no conflict between the GPIO and VCP
> functionality in this mode. Tested on FT230X and FT231X.
>
> As there is no way to request the cu
On Tue, Sep 25, 2018 at 12:06:35PM +0200, Johan Hovold wrote:
> On Mon, Sep 24, 2018 at 04:31:51PM +0200, Karoly Pados wrote:
> > +static void ftdi_gpio_set_multiple(struct gpio_chip *gc,
> > + unsigned long *mask, unsigned long *bits)
> > +{
> > + struct usb_serial_
Hi,
>> +#if defined(CONFIG_GPIOLIB)
>> +static const char * const ftdi_ftx_gpio_names[] = {
>> + "CBUS0", "CBUS1", "CBUS2", "CBUS3"
>> +};
>> +#endif
>
> We want to keep the ifdeffery to a minimum, so move this inside the
> gpiolib ifdef below (and possibly even into the function where it is
> us
>> gpiolib doesn't clear bits not in mask for you, so you need to OR with
>> *mask here to avoid setting random other bits.
>
> That was of course meant to be: *AND* with *mask.
>
Ah, okay, one question from my previous e-mail down.
On Tue, Sep 25, 2018 at 10:46:30AM +, Karoly Pados wrote:
> Hi,
>
> >> +#if defined(CONFIG_GPIOLIB)
> >> +static const char * const ftdi_ftx_gpio_names[] = {
> >> + "CBUS0", "CBUS1", "CBUS2", "CBUS3"
> >> +};
> >> +#endif
> >
> > We want to keep the ifdeffery to a minimum, so move this inside
>> + if (priv->gpio_output & BIT(gpio))
>> + return 0;
>> + else
>> + return 1;
>>
>> This could just simplified using negation (!), but perhaps this is
>> easier to parse as it stands.
>>
>> Sorry, it is not clear what your preferred action here is.
>> So should I leave it as is then or not?
>
On Tue, Sep 25, 2018 at 11:11:03AM +, Karoly Pados wrote:
> >> + if (priv->gpio_output & BIT(gpio))
> >> + return 0;
> >> + else
> >> + return 1;
> >>
> >> This could just simplified using negation (!), but perhaps this is
> >> easier to parse as it stands.
> >>
> >> Sorry, it is not clear wh
ps->dev->actconfig can be NULL and cause NULL-deref in usb_find_alt_setting()
before c9a4cb204e9e. fix this anyway by checking that ps->dev->actconfig is not
NULL, so usb_find_alt_setting() is not called with a known-bad argument.
Signed-off-by: Vladis Dronov
Reported-by: syzbot+19c3aaef85a89d451
This patch allows using the CBUS pins of FT-X devices as GPIO in CBUS
bitbanging mode. There is no conflict between the GPIO and VCP
functionality in this mode. Tested on FT230X and FT231X.
As there is no way to request the current CBUS register configuration
from the device, all CBUS pins are set
On Tue, 25 Sep 2018, Vladis Dronov wrote:
> ps->dev->actconfig can be NULL and cause NULL-deref in usb_find_alt_setting()
> before c9a4cb204e9e. fix this anyway by checking that ps->dev->actconfig is
> not
> NULL, so usb_find_alt_setting() is not called with a known-bad argument.
What reason is
The following changes since commit 7876320f88802b22d4e2daf7eb027dd14175a0f8:
Linux 4.19-rc4 (2018-09-16 11:52:37 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-4.19-rc6
for you to fetch changes up to 3e3b81965cbfa01fda6d7
> What reason is there for having two different fixes for the same bug?
> This one isn't going to get into any mainline trees that don't already
> have c9a4cb204e9e.
I believe this is the right thing to do, so usb_find_alt_setting()
is not called with a known-bad argument.
Honestly, I would chang
On Tue, 25 Sep 2018, Vladis Dronov wrote:
> > What reason is there for having two different fixes for the same bug?
> > This one isn't going to get into any mainline trees that don't already
> > have c9a4cb204e9e.
>
> I believe this is the right thing to do, so usb_find_alt_setting()
> is not cal
On Tue, Sep 25, 2018 at 5:15 PM, Alan Stern wrote:
> On Tue, 25 Sep 2018, Vladis Dronov wrote:
>
>> > What reason is there for having two different fixes for the same bug?
>> > This one isn't going to get into any mainline trees that don't already
>> > have c9a4cb204e9e.
>>
>> I believe this is th
On Wed, Aug 29, 2018 at 03:33:24PM +0800, Yinbo Zhu wrote:
> This patch is to add description of 'configure-gfladj' to binding
> so that configuring devicetree
Not a complete sentence.
The subject should be: "dt-bindings: usb: ..."
>
> Signed-off-by: Yinbo Zhu
> ---
> Documentation/devicetree/
Hi Florian,
> @@ -1415,6 +1415,9 @@ static int lan78xx_set_wol(struct net_device *netdev,
> if (wol->wolopts & WAKE_ARP)
> pdata->wol |= WAKE_ARP;
>
> + if (pdata->wol == 0)
> + return -EINVAL;
> +
It will make function return when disabling WOL.
Is there other
On 09/25/2018 10:19 AM, woojung@microchip.com wrote:
> Hi Florian,
>
>> @@ -1415,6 +1415,9 @@ static int lan78xx_set_wol(struct net_device *netdev,
>> if (wol->wolopts & WAKE_ARP)
>> pdata->wol |= WAKE_ARP;
>>
>> +if (pdata->wol == 0)
>> +return -EINVAL;
>> +
Hi Florian,
> >> + if (pdata->wol == 0)
> >> + return -EINVAL;
> >> +
> > It will make function return when disabling WOL.
>
> Huh, yes, good point.
>
> > Is there other place handling this scenario?
>
> How do you mean?
>
I meant there is another path I might miss when disabling WOL
On Tue, 25 Sep 2018, Andrey Konovalov wrote:
> On Tue, Sep 25, 2018 at 5:15 PM, Alan Stern wrote:
> > On Tue, 25 Sep 2018, Vladis Dronov wrote:
> >
> >> > What reason is there for having two different fixes for the same bug?
> >> > This one isn't going to get into any mainline trees that don't al
On Tue, Sep 25, 2018 at 3:04 AM, Artur Petrosyan
wrote:
> Just a clarification by this commit "[PATCH] usb: dwc2: Fix HiKey
> regression caused by power_down feature"
> https://marc.info/?l=linux-usb&m=152669095513248&w=2
>
> the power_down is disabled setting "p->power_down = false;" in
> "dwc2_s
On 09/25/2018 10:32 AM, woojung@microchip.com wrote:
> Hi Florian,
>
+ if (pdata->wol == 0)
+ return -EINVAL;
+
>>> It will make function return when disabling WOL.
>>
>> Huh, yes, good point.
>>
>>> Is there other place handling this scenario?
>>
>> How do you mean?
>
Hello, Alan, Andrey, all,
> > > (You'll be lucky if Linus doesn't see that. He yells at anybody who
> > > suggests adding BUG_ON for anything that doesn't completely crash
Now, may be not )
> > > How is this different from calling kfree() with a NULL argument?
It is not, it is the same case.
On Tue, Sep 04, 2018 at 02:34:12PM -0700, Prakruthi Deepak Heragu wrote:
> Documentation for Embedded USB Debugger (EUD) device tree bindings.
>
> Signed-off-by: Satya Durga Srinivasu Prabhala
> Signed-off-by: Prakruthi Deepak Heragu
> ---
> .../devicetree/bindings/soc/qcom/qcom,msm-eud.txt |
On Tue, 25 Sep 2018, Vladis Dronov wrote:
> > > What about adding a WARN_ON()? It doesn't crash the kernel and it will
> > > be detected and reported by syzbot.
>
> Yes, that would be a great solution.
>
> > Sure, we could do that. But would be the point?
>
> We know when usb_find_alt_setting(
Hi Florian,
> @@ -1401,19 +1401,10 @@ static int lan78xx_set_wol(struct net_device
...
> + if (pdata->wol & ~WAKE_ALL)
> + return -EINVAL;
If I understand correctly, it needs to check againt "wol->wolopts" than
pdata->wol.
> +
> + pdata->wol = wol->wolopts;
Thanks.
Woo
Hi John,
On 9/25/2018 21:59, John Stultz wrote:
> On Tue, Sep 25, 2018 at 3:04 AM, Artur Petrosyan
> wrote:
>> Just a clarification by this commit "[PATCH] usb: dwc2: Fix HiKey
>> regression caused by power_down feature"
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dlin
39 matches
Mail list logo
