Hi,
> From: Vivek Gautam, Sent: Tuesday, March 14, 2017 3:23 PM
>
> Adding vendor specific directories in phy to group
> phy drivers under their respective vendor umbrella.
>
> Also updated the MAINTAINERS file to reflect the correct
> directory structure for phy drivers.
>
> Signed-off-by: Vi
On 03/14/2017 03:22 PM, Vivek Gautam wrote:
> Adding vendor specific directories in phy to group
> phy drivers under their respective vendor umbrella.
>
> Also updated the MAINTAINERS file to reflect the correct
> directory structure for phy drivers.
>
> Signed-off-by: Vivek Gautam
> Acked-by: H
Hi Krzysztof,
On 03/14/2017 12:14 PM, Krzysztof Kozlowski wrote:
On Tue, Mar 14, 2017 at 8:22 AM, Vivek Gautam
wrote:
Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.
Also updated the MAINTAINERS file to reflect the correct
directory stru
Dave Mielke, on lun. 13 mars 2017 22:20:01 -0400, wrote:
> It's possible that this device is using high speed because it offers a
> feature
> to transfer its internal clipboard to the host, and it allows that clipboard
> to
> contain lots of data. Interestingly, though, hidden within a usage no
Hi,
Thanks for your help. I tried this patch and it works well.
So what else I should do? Will you help to merge it to trunk?
Thanks for your help.
Best Regards
Benson
On Fri, Mar 10, 2017 at 7:28 PM, Oliver Neukum wrote:
> Am Freitag, den 10.03.2017, 17:20 +0800 schrieb 家瑋:
>>
>
>
> Hi,
>
>
On 13.03.2017 23:59, Adam Wallis wrote:
Shutdown should be called for xhci_plat devices especially for
situations where kexec might be used by stopping DMA
transactions.
Signed-off-by: Adam Wallis
---
drivers/usb/host/xhci-plat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/us
Am Dienstag, den 14.03.2017, 17:13 +0800 schrieb 家瑋:
> Hi,
> Thanks for your help. I tried this patch and it works well.
> So what else I should do? Will you help to merge it to trunk?
> Thanks for your help.
>
Hi,
I will submit it. May I add a "Tested-by" tag from you?
Regards
On Thu, Mar 09, 2017 at 11:32:28AM -0600, Dan Williams wrote:
> Add Quectel UC15, UC20, EC21, and EC25. The EC20 is handled by
> qcserial due to a USB VID/PID conflict with an existing Acer
> device.
>
> Signed-off-by: Dan Williams
> ---
> NOTE: The UC20, EC21, and EC25 should also get a corresp
On a loaded virtualization host (dozen guests booting at the same time)
it may happen that the ohci controller emulation doesn't manage to do
timely frame processing, with the result that the io watchdog fires and
considers the controller being dead, even though it's only the emulation
being unusua
On Mon, 20 Feb 2017, Baolin Wang wrote:
[...]
> drivers/power/supply/wm831x_power.c | 63 +++
> drivers/usb/gadget/Kconfig |8 +
> drivers/usb/gadget/udc/Makefile |1 +
> drivers/usb/gadget/udc/charger.c| 865
> +++
> drivers/usb/gadge
From: Mason
> Sent: 13 March 2017 21:58
...
> I'd like to push support for this PCIe controller upstream.
>
> Is the code I posted on the right track?
> Maybe I can post a RFC patch tomorrow?
I think you need to resolve the problem of config space (and IO) cycles
before the driver can be deemed u
Hi,
On 14 March 2017 at 17:57, Lee Jones wrote:
> On Mon, 20 Feb 2017, Baolin Wang wrote:
>
> [...]
>
>> drivers/power/supply/wm831x_power.c | 63 +++
>> drivers/usb/gadget/Kconfig |8 +
>> drivers/usb/gadget/udc/Makefile |1 +
>> drivers/usb/gadget/udc/charger.c| 865
Hi,
It's OK for me. Thanks for your help
Best Regards
Benson
On Tue, Mar 14, 2017 at 5:44 PM, Oliver Neukum wrote:
> Am Dienstag, den 14.03.2017, 17:13 +0800 schrieb 家瑋:
>> Hi,
>> Thanks for your help. I tried this patch and it works well.
>> So what else I should do? Will you help to me
There is a small window during which the an URB may
remain active after disconnect has returned. If in that case
already freed memory may be accessed and executed.
The fix is to poison the URB befotre the work is flushed.
Typos fixed in v2
Signed-off-by: Oliver Neukum
---
drivers/usb/misc/lvste
The gadget code exports the bitfield for serial status changes
over the wire in its internal endianness. The fix is to convert
to little endian before sending it over the wire.
Signed-off-by: Oliver Neukum
Tested-by: 家瑋
CC: sta...@vger.kernel.org
---
drivers/usb/gadget/function/f_acm.c | 4 +++-
On 14/03/2017 11:23, David Laight wrote:
> Mason wrote:
>
>> I'd like to push support for this PCIe controller upstream.
>>
>> Is the code I posted on the right track?
>> Maybe I can post a RFC patch tomorrow?
>
> I think you need to resolve the problem of config space (and IO) cycles
> before t
Elena Reshetova writes:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova
> Sig
On Tue, 14 Mar 2017, Baolin Wang wrote:
> Hi,
>
> On 14 March 2017 at 17:57, Lee Jones wrote:
> > On Mon, 20 Feb 2017, Baolin Wang wrote:
> >
> > [...]
> >
> >> drivers/power/supply/wm831x_power.c | 63 +++
> >> drivers/usb/gadget/Kconfig |8 +
> >> drivers/usb/gadget/udc/Makefil
From: Mason
> Sent: 14 March 2017 12:06
> On 14/03/2017 11:23, David Laight wrote:
>
> > Mason wrote:
> >
> >> I'd like to push support for this PCIe controller upstream.
> >>
> >> Is the code I posted on the right track?
> >> Maybe I can post a RFC patch tomorrow?
> >
> > I think you need to reso
> Elena Reshetova writes:
>
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elen
On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote:
> > Elena Reshetova writes:
> >
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > > refcounter overflows that m
On Tue, 14 Mar 2017, Gerd Hoffmann wrote:
> On a loaded virtualization host (dozen guests booting at the same time)
> it may happen that the ohci controller emulation doesn't manage to do
> timely frame processing, with the result that the io watchdog fires and
> considers the controller being dea
USBTMC devices are required to have a bulk-in and a bulk-out endpoint,
but the driver failed to verify this, something which could lead to the
endpoint addresses being taken from uninitialised memory.
Make sure to zero all private data as part of allocation, and add the
missing endpoint sanity che
Make sure to initialise the return value to avoid having allocation
failures going unnoticed when allocating interrupt-endpoint resources.
This prevents use-after-free or worse when the device is later unbound.
Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488
READ_STATUS_BYT
On 17-03-13 17:00:20, Petko Manolov wrote:
> On 17-03-12 23:16:25, Philippe Reynes wrote:
> > The ethtool api {get|set}_settings is deprecated. We move this driver to
> > new
> > api {get|set}_link_ksettings.
> >
> > As I don't have the hardware, I'd be very pleased if someone may test this
> >
I have been archiving data from old hard drives, and I have a drive that
spins up, but does not finish detecting (the drive is faulty). When this
happens on kernel 4.10.1 there is some kind of a timeout, and the usb
port that my dock is plugged into is permanently disabled until I
reboot. Disconnec
On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola wrote:
> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola wrote:
>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola wrote:
>>> Hi Greg,
>>>
>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH wrote:
On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote:
>>
On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola wrote:
> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola wrote:
>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola wrote:
>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola wrote:
Hi Greg,
On Wed, Mar 8, 2017 at 5:15 PM, Greg KH wrote:
> On
Adds a similar log message to USB_CDC_NOTIFY_SERIAL_STATE as it is
already done with USB_CDC_NOTIFY_NETWORK_CONNECTION.
Signed-off-by: Tobias Herzog
---
drivers/usb/class/cdc-acm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
ind
write_used was introduced with commit 884b600f63dc ("[PATCH] USB: fix acm
trouble with terminals") but never used since.
Signed-off-by: Tobias Herzog
---
drivers/usb/class/cdc-acm.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h
index
USB devices may have very limitited endpoint packet sizes, so that
notifications can not be transferred within one single usb packet.
Reassembling of multiple packages may be necessary.
Signed-off-by: Tobias Herzog
---
drivers/usb/class/cdc-acm.c | 102 +++
Notifications may only be 8 bytes so long. Accessing the 9th and
10th byte of unimplemented/unknown notifications may be insecure.
Also check the length of known notifications before accessing anything
behind the 8th byte.
Signed-off-by: Tobias Herzog
---
drivers/usb/class/cdc-acm.c | 11 +++
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.
But this could c
33 matches
Mail list logo
