The platform_data header file was dropped in the merged version of the
USB251xB driver. Therefore remove its reference from the MAINTAINERS file.
Signed-off-by: Richard Leitner
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5f..c776906 100
Rename oc-delay-* to oc-delay-us and make it expect a time value.
Furthermore add -ms suffix to power-on-time. There changes were
suggested by Rob Herring in https://lkml.org/lkml/2017/2/15/1283.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/usb/usb251xb.txt | 10 ---
Remove the max_{power,current}_{sp,bp} properties of the usb251xb driver
from devicetree. This is done to simplify the dt bindings as requested
by Rob Herring in https://lkml.org/lkml/2017/2/15/1283. If those
properties are ever needed by somebody they can be enabled again easily.
Signed-off-by: R
Mark the reg property as required and furthermore fix some typos and
spellings in the documentation.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/usb/usb251xb.txt | 23 +++---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/de
This patchset improves/fixes the USB251xB/xBi devicetree bindings as
recommended by Rob Herring.
CHANGES v2:
- Require exact values for oc-delay-us property
- Remove erroneous be32_to_cpu call in power-on-time-ms prop parsing
- Remove reference to inexistent file from MAINT
Hi Greg,
On Thu, Feb 23, 2017 at 08:51:03AM +0100, Greg KH wrote:
> And again, what specifically are you referring to, and again, have you
> tried the code out yourself? What is preventing you from testing this
> in your environment to determine if it works properly for you or not?
I did the exp
On Sat, Mar 04, 2017 at 02:21:28AM +0800, kbuild test robot wrote:
> Hi Johan,
>
> [auto build test WARNING on usb/usb-testing]
> [also build test WARNING on v4.10 next-20170303]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
>
Hi,
On 03/06/2017 02:02 AM, Yuyang Du wrote:
Hi Greg,
On Thu, Feb 23, 2017 at 08:51:03AM +0100, Greg KH wrote:
And again, what specifically are you referring to, and again, have you
tried the code out yourself? What is preventing you from testing this
in your environment to determine if it w
Am Montag, den 06.03.2017, 09:02 +0800 schrieb Yuyang Du:
> Hi Greg,
>
> On Thu, Feb 23, 2017 at 08:51:03AM +0100, Greg KH wrote:
> >
> > And again, what specifically are you referring to, and again, have
> > you
> > tried the code out yourself? What is preventing you from testing
> > this
> > i
Hi Greg and Heikki,
I can see that ucsi acpi interface driver is available in kernel tree. I have
following queries on the same. Kindly pardon my ignorance as i am a novice to
this.
- Is there any implementation of USB-C system policy manager (OPM) in
Linux?
- If yes to USB-C syst
On Mar 01 2017 or thereabouts, Joe Perches wrote:
> Use a more common logging style and remove the unnecessary
> OOM messages as there is default dump_stack when OOM.
>
> Miscellanea:
>
> o Hoist an assignment in an if
> o Realign arguments
> o Realign a deeply indented if descendent above a prin
On Mon, Mar 06, 2017 at 10:27:09AM +0100, Johan Hovold wrote:
> On Sat, Mar 04, 2017 at 02:21:28AM +0800, kbuild test robot wrote:
> > Hi Johan,
> >
> > [auto build test WARNING on usb/usb-testing]
> > [also build test WARNING on v4.10 next-20170303]
> > [if your patch is applied to the wrong git
On Mon, Mar 06, 2017 at 09:02:11AM +0800, Yuyang Du wrote:
> Hi Greg,
>
> On Thu, Feb 23, 2017 at 08:51:03AM +0100, Greg KH wrote:
> > And again, what specifically are you referring to, and again, have you
> > tried the code out yourself? What is preventing you from testing this
> > in your envir
Am Freitag, den 03.03.2017, 20:27 +0100 schrieb Mats Karrman:
> On 2017-03-03 13:59, Heikki Krogerus wrote:
>
> >
> > On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote:
> >
>
> >
> > How would something like that sound to you guys?
>
> Complicated... Need to marinate on that fo
[ +CC: Greg ]
On Fri, Mar 03, 2017 at 07:29:02PM +0100, Oliver Neukum wrote:
> Am Donnerstag, den 02.03.2017, 12:51 +0100 schrieb Johan Hovold:
> > This series refactors the endpoint sanity checks by allowing
> > subdrivers
> > to specify a minimum number of endpoints required per type and
> > let
On Mon, Mar 06, 2017 at 02:41:17PM +0530, Shah, Nehal-bakulchandra wrote:
> Hi Greg and Heikki,
>
>
> I can see that ucsi acpi interface driver is available in kernel tree. I have
> following queries on the same. Kindly pardon my ignorance as i am a novice to
> this.
>
> - Is there any imp
Hi,
On 03/03/2017 09:48 PM, Alan Stern wrote:
On Fri, 3 Mar 2017, László Monda wrote:
Hi Krzysztof, and thank you for the help!
Oh now I see. I missed this when I was reading this email for the first
time.
root@spark ~ # echo -n 2-10.3 > /sys/bus/usb/drivers/usb/unbind
You are trying t
Am Montag, den 06.03.2017, 10:23 +0100 schrieb Johan Hovold:
> [ +CC: Greg ]
>
> On Fri, Mar 03, 2017 at 07:29:02PM +0100, Oliver Neukum wrote:
> >
> > Am Donnerstag, den 02.03.2017, 12:51 +0100 schrieb Johan Hovold:
> > >
> > > This series refactors the endpoint sanity checks by allowing
> > >
On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote:
> Am Montag, den 06.03.2017, 10:23 +0100 schrieb Johan Hovold:
> > [ +CC: Greg ]
> >
> > On Fri, Mar 03, 2017 at 07:29:02PM +0100, Oliver Neukum wrote:
> > >
> > > Am Donnerstag, den 02.03.2017, 12:51 +0100 schrieb Johan Hovold:
> > >
Am Freitag, den 24.02.2017, 16:41 +0300 schrieb c400:
> when i disable IOMMU -> "Enable Intel DMA Remapping Device by
> default"
> the USB flash drive becomes completely invisible.
> Same stuff when i completely disable recompile kernel without IOMMU
The DMA map for the device seems to be incorrec
On Thu, 5 Jan 2017, Benjamin Tissoires wrote:
> For case 1, the hiddev documentation provides an ioctl to do the
> init manually. A solution could be to retrieve the requested report
> when EVIOCGUSAGE is called, in the same way hidraw does. I would be
> tempted to not change the behavior and hope
On 03/03/2017 20:02, Robin Murphy wrote:
> On 03/03/17 17:15, Mason wrote:
>
[1.264893] Unable to handle kernel paging request at virtual address
d08664f4
>
> Note that that's a reasonable approximation of a vmalloc address...
>
[1.272248] pgd = c0004000
[1.2750
Hi Mats,
On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote:
> On 2017-03-03 13:59, Heikki Krogerus wrote:
>
> > On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote:
> >
>
> > How would something like that sound to you guys?
>
> Complicated... Need to marinate on that fo
Hi Peter,
On Mon, Mar 06, 2017 at 09:15:51AM +0800, Peter Chen wrote:
> > > What interface you use when you receive this event to handle
> > > dual-role switch? I am wonder if a common dual-role class is
> > > needed, then we can have a common user utility.
> > >
> > > Eg, if "data_role" has chan
On Wed, 1 Mar 2017, Joe Perches wrote:
> Use a more common logging style and remove the unnecessary
> OOM messages as there is default dump_stack when OOM.
>
> Miscellanea:
>
> o Hoist an assignment in an if
> o Realign arguments
> o Realign a deeply indented if descendent above a printk
>
> Si
On Mar 06 2017 or thereabouts, Jiri Kosina wrote:
> On Thu, 5 Jan 2017, Benjamin Tissoires wrote:
>
> > For case 1, the hiddev documentation provides an ioctl to do the
> > init manually. A solution could be to retrieve the requested report
> > when EVIOCGUSAGE is called, in the same way hidraw do
On 06/03/2017 13:42, Mason wrote:
> So the kernel panics in xhci_find_next_ext_cap()
> ( drivers/usb/host/xhci-ext-caps.h:122 )
> http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122
>
> Any idea how this can happen?
>
> base = ioremap_nocache(pci_resource_start
the reference clock of HighSpeed port is 48M which comes from PLL;
the reference clock of SuperSpeed port is 26M which usually comes
from 26M oscillator directly, but some SoCs are not, add it for
compatibility, and put them into port node for flexibility.
Signed-off-by: Chunfeng Yun
---
drivers
add a new compatible string for "mt2712", and move reference clock
into each port node;
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 93 +---
1 file changed, 80 insertions(+), 13 deletions(-)
diff --git a/Documenta
there is a reference clock for each port, HighSpeed port is 48M,
and SuperSpeed port is 26M which usually comes from 26M oscillator
directly, but some SoCs is not. it is flexible to move it into port
node.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |8 ++--
split the old SuperSpeed port node into a HighSpeed one and a new
SuperSpeed one.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/a
Increase LFPS filter threshold to avoid some fake remote wakeup
signal which cause U3 link fail and link to U2 only at about
0.01% probability.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/phy/phy-mt65xx-usb
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If
The default value of RX detection stable time is 10us, and this
margin is too big for some critical cases which cause U3 link fail
and link to U2(probability is about 1%). So change it to 5us.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 18 ++
1 file changed
Jiri Kosina wrote:
> On Sat, 25 Feb 2017, Tobias Jakobi wrote:
>
>> For mouse devices we can currently change the polling interval
>> via usbhid.mousepoll. Implement the same thing for joysticks, so
>> users can reduce input latency this way.
>>
>> This has been tested with a Logitech RumblePad 2
There are some variations from mt2701 to mt2712:
1. banks shared by multiple ports are put back into each port,
such as SPLLC and U2FREQ;
2. add a new bank MISC for u2port, and CHIP for u3port;
3. bank's offset in each port are also rearranged;
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy
On Sat, 25 Feb 2017, Tobias Jakobi wrote:
> For mouse devices we can currently change the polling interval
> via usbhid.mousepoll. Implement the same thing for joysticks, so
> users can reduce input latency this way.
>
> This has been tested with a Logitech RumblePad 2 with jspoll=2,
> resulting
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
This series, for various different drivers, replaces atomic_t reference
counters with the new refcount_t type and API (see include/linux/refcount.h).
By doing this we prevent intentional or accidental
underflows or overflows that can led to use-after-free vulnerabilities.
The below patches are ful
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
Hi,
Roger Quadros writes:
> <<< No Message Collected >>>
You need to resend this. See also [1]
[1] https://marc.info/?l=linux-usb&m=148854335620717&w=2
--
balbi
signature.asc
Description: PGP signature
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
Signed-off-by: Hans Liljestrand
Signed-off-
[+linux-pci, just in case]
On 06/03/17 12:42, Mason wrote:
> On 03/03/2017 20:02, Robin Murphy wrote:
>
>> On 03/03/17 17:15, Mason wrote:
>>
> [1.264893] Unable to handle kernel paging request at virtual address
> d08664f4
>>
>> Note that that's a reasonable approximation of a vmall
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
Hi,
On Mon, Mar 06, 2017 at 02:41:17PM +0530, Shah, Nehal-bakulchandra wrote:
> Hi Greg and Heikki,
>
>
> I can see that ucsi acpi interface driver is available in kernel tree. I have
> following queries on the same. Kindly pardon my ignorance as i am a novice to
> this.
>
> - Is there any impl
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
Signed-off-by: Hans Liljestrand
Signed-off-
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
Signed-off-by: Hans Liljestrand
Signed-off-
Peter Senna Tschudin writes:
> On Sun, Feb 26, 2017 at 08:24:22PM +0100, Romain Perier wrote:
>> The PCI pool API is deprecated. This commits replaces the PCI pool old
>> API by the appropriated function with the DMA pool API.
>>
> Reviewed-by: Peter Senna Tschudin
Fine by me:
Acked-by: Felipe
Hi,
yuan linyu writes:
> From: yuan linyu
>
> a lot of embeded system SOC (e.g. freescale T2080) have both
> PCI and USB modules. But USB module is controlled by registers directly,
> it have no relationship with PCI module.
>
> when say N here it will not build PCI related code in USB driver.
The CPPI 4.1 driver polls register to workaround the premature TX
interrupt issue, but it causes audio playback underrun when triggered in
Isoch transfers.
Isoch doesn't do back-to-back transfers, the TX should be done by the
time the next transfer is scheduled. So skip this polling workaround for
Hi,
Vardan Mikayelyan writes:
> The functions with name hibernation are misnamed originally. They were only
> responsible for partial power down and not for hibernation.
>
> This patch set adds the real hibernation support for dwc2 driver and renames
> existing functions to power_down.xisting fu
On 06/03/2017 15:30, Robin Murphy wrote:
> On 06/03/17 12:42, Mason wrote:
>
>> $ arm-linux-gnueabihf-addr2line -i -e vmlinux c039fe44
>> arch/arm/include/asm/io.h:119
>>
>> In other words, readl()
>> Not as helpful as expected...
>
> I guess your toolchain isn't generating whatever debug info th
Hi,
Vardan Mikayelyan writes:
> Move usb_phy_generic_register() function call to the top, to simplify
> error handling.
>
> Replace kzalloc() with devm_kzalloc().
>
> After platform_device_add(), if we error out, we must do
> platform_device_unregister(), which also does the put. So lets move
>
Am Montag, den 06.03.2017, 12:27 +0100 schrieb Johan Hovold:
> On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote:
> >
> >
> > Yes, it would be wrong to see this as an attribute per driver.
> > It needs to apply when you match. AFAICS every serial subdriver
> > has a device table. Requ
cristian.bir...@microchip.com writes:
> From: Cristian Birsan
>
> Check fifo configuration values against device tree values for endpoint
> fifo in auto configuration mode (fifo_mode=0).
>
> Signed-off-by: Cristian Birsan
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 26
On Mon, Mar 06, 2017 at 02:14:51PM +0100, Oliver Neukum wrote:
> Am Montag, den 06.03.2017, 12:27 +0100 schrieb Johan Hovold:
> > On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote:
> > > Yes, it would be wrong to see this as an attribute per driver.
> > > It needs to apply when you mat
On Mon, Mar 06, 2017 at 04:48:50PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> yuan linyu writes:
> > From: yuan linyu
> >
> > a lot of embeded system SOC (e.g. freescale T2080) have both
> > PCI and USB modules. But USB module is controlled by registers directly,
> > it have no relationship with PC
On Mon, Mar 06, 2017 at 04:29:33PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
> > <<< No Message Collected >>>
>
> You need to resend this. See also [1]
Not sure what is wrong. This happens to me too, see [2]. And I sent the
patch v2 an hour ago, but the patch is still not on
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
Signed-off-by: Hans Liljestrand
Signed-off-
From: Mason
> Sent: 06 March 2017 13:50
> On 06/03/2017 13:42, Mason wrote:
>
> > So the kernel panics in xhci_find_next_ext_cap()
> > ( drivers/usb/host/xhci-ext-caps.h:122 )
> > http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122
> >
> > Any idea how this can happen?
On 03/06/2017 03:21 PM, Elena Reshetova wrote:
> 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.
The subject is wron
On 06/03/2017 16:27, David Laight wrote:
> Mason wrote:
>>
>>> So the kernel panics in xhci_find_next_ext_cap()
>>> ( drivers/usb/host/xhci-ext-caps.h:122 )
>>> http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122
>>>
>>> Any idea how this can happen?
>>>
>>> base =
On Mon, Mar 06, 2017 at 04:01:36PM +0100, Johan Hovold wrote:
> On Mon, Mar 06, 2017 at 02:14:51PM +0100, Oliver Neukum wrote:
> > Am Montag, den 06.03.2017, 12:27 +0100 schrieb Johan Hovold:
> > > On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote:
> > > > True, but again not specific
> From: Mason
> Sent: 06 March 2017 15:46
...
> >> The issue was that, on this platform, the PCI configuration space
> >> and memory space are multiplexed; in other words they reside at
> >> the same physical address, with a bit in MMIO to choose one or
> >> the other.
> >
> > Time to shoot another
Hi!
I have an external 2 disk hd enclosure with a UASP capable JMicron USB 3 bridge:
[1.271826] usb 4-1: New USB device found, idVendor=152d, idProduct=9561
[1.271952] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[1.272075] usb 4-1: Product: JMS56x Series
[1.2
Hello.
On 03/06/2017 05:20 PM, Elena Reshetova wrote:
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: Ele
Add missing sanity check to the bulk-in completion handler to avoid an
integer underflow that could be triggered by a malicious device.
This avoids leaking up to 56 bytes from after the URB transfer buffer to
user space.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Johan Ho
Remove the now redundant open callback and let core call the generic
handler for us instead.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/omninet.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 76564b3bebb9..dd70
Add missing sanity check to the bulk-in completion handler to avoid an
integer underflow that can be triggered by a malicious device.
This avoids leaking 128 kB of memory content from after the URB transfer
buffer to user space.
Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u3
This driver needlessly took another reference to the tty on open, a
reference which was then never released on close. This lead to not just
a leak of the tty, but also a driver reference leak that prevented the
driver from being unloaded after a port had once been opened.
Fixes: 4a90f09b20f4 ("tty
Fix a NULL-pointer dereference in the interrupt callback should a
malicious device send data containing a bad port number by adding the
missing sanity check.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 6 ++
1 file changed
These patches fix a NULL-deref and a couple of information leaks due to
missing sanity checks in completion handlers.
Included is also a tty-reference leak fix.
Johan
Johan Hovold (5):
USB: serial: io_ti: fix NULL-deref in interrupt callback
USB: serial: omninet: fix reference leaks at open
On 03/06/2017 09:21 AM, Elena Reshetova wrote:
> 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: E
Hi Heikki ,
Thanks for the prompt reply.
If i understood correctly the current driver(drivers/usb/misc/ucsi.c) supports
the OPM and rest all is taken care by EC FW with BIOS .
In ucsi.c file i did not find any mailbox related code. Am I missing something
here?
Thanks
Nehal
On 3/6/2017 8:01
On Mon, Mar 06, 2017 at 04:27:11PM +0100, Johannes Thumshirn wrote:
> On 03/06/2017 03:21 PM, Elena Reshetova wrote:
> > 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
Hi Roger,
Thank you for the patch.
On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote:
> On alternate setting change, webcam gadget sends us a UVC_EVENT_STREAMON
> or UVC_EVENT_STREAMOFF event. It expects delayed status response on
> STREAMON event only but doesn't expect us to send that response
Dne 24.1.2017 v 19:20 Felipe Balbi napsal(a):
>
> Hi,
>
> Petr Cvek writes:
>>> Greg KH writes:
>>> fine by me. Just lsusb will look funky ;-)
>>
>> Heh, true, but I thought lsusb would use a string if the device provided
>> it. Haven't looked at that portion of the code in a v
Dne 2.3.2017 v 09:19 Roger Quadros napsal(a):
> Petr,
>
> On 02/03/17 06:57, Petr Cvek wrote:
>> Dne 2.3.2017 v 00:22 Laurent Pinchart napsal(a):
>>> Hi Roger,
>>>
>>> On Wednesday 01 Mar 2017 17:09:51 Roger Quadros wrote:
Hi,
I'm no longer able to use g_webcam with uvc-gadget [1] s
1 - 100 of 110 matches
Mail list logo
