Re: [PATCH v2 10/21] memblock: refactor internal allocation functions

On Sun, Feb 03, 2019 at 08:39:20PM +1100, Michael Ellerman wrote: > Mike Rapoport writes: > > > Currently, memblock has several internal functions with overlapping > > functionality. They all call memblock_find_in_range_node() to find free > > memory and then reserve the

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

On Thu, Jan 31, 2019 at 08:07:29AM +0100, Christophe Leroy wrote: > > > Le 31/01/2019 à 07:44, Christophe Leroy a écrit : > > > > > >Le 31/01/2019 à 07:41, Mike Rapoport a écrit : > >>On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote: > >

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote: > > > Le 21/01/2019 à 09:04, Mike Rapoport a écrit : > >Add check for the return value of memblock_alloc*() functions and call > >panic() in case of error. > >The panic message repeats the one used by p

Re: [PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic

On Fri, Jan 25, 2019 at 05:45:02PM +, Catalin Marinas wrote: > On Mon, Jan 21, 2019 at 10:03:53AM +0200, Mike Rapoport wrote: > > diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c > > index ae34e3a..2c61ea4 100644 > > --- a/arch/arm64/mm/numa.c > >

[PATCH v2 02/21] powerpc: use memblock functions returning virtual address

additional call sites ] Signed-off-by: Christophe Leroy Signed-off-by: Mike Rapoport --- arch/powerpc/kernel/dt_cpu_ftrs.c | 3 +-- arch/powerpc/kernel/irq.c | 5 - arch/powerpc/kernel/paca.c| 6 +- arch/powerpc/kernel/prom.c| 5 - arch/powerpc/kernel/setup_32

[PATCH v2 00/21] Refine memblock API

memblock. v2 changes: * replace some more %lu with %zu * remove panics where they are not needed in s390 and in printk * collect Acked-by and Reviewed-by. Christophe Leroy (1): powerpc: use memblock functions returning virtual address Mike Rapoport (20): openrisc: prefer memblock APIs returning

[PATCH v2 05/21] memblock: emphasize that memblock_alloc_range() returns a physical address

llocations. Signed-off-by: Mike Rapoport --- include/linux/memblock.h | 5 ++--- mm/cma.c | 10 -- mm/memblock.c| 9 + 3 files changed, 11 insertions(+), 13 deletions(-) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index f7ef313..66df

[PATCH v2 07/21] memblock: memblock_phys_alloc(): don't panic

Make the memblock_phys_alloc() function an inline wrapper for memblock_phys_alloc_range() and update the memblock_phys_alloc() callers to check the returned value and panic in case of error. Signed-off-by: Mike Rapoport --- arch/arm/mm/init.c | 4 arch/arm64/mm/mmu.c

[PATCH v2 04/21] memblock: drop memblock_alloc_base_nid()

The memblock_alloc_base_nid() is a oneliner wrapper for memblock_alloc_range_nid() without any side effect. Replace it's usage by the direct calls to memblock_alloc_range_nid(). Signed-off-by: Mike Rapoport --- include/linux/memblock.h | 3 --- mm/memblock.c| 15 -

[PATCH v2 08/21] memblock: drop __memblock_alloc_base()

The __memblock_alloc_base() function tries to allocate a memory up to the limit specified by its max_addr parameter. Depending on the value of this parameter, the __memblock_alloc_base() can is replaced with the appropriate memblock_phys_alloc*() variant. Signed-off-by: Mike Rapoport Acked-by

[PATCH v2 11/21] memblock: make memblock_find_in_range_node() and choose_memblock_flags() static

These functions are not used outside memblock. Make them static. Signed-off-by: Mike Rapoport --- include/linux/memblock.h | 4 mm/memblock.c| 4 ++-- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index

[PATCH v2 12/21] arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0)

The last parameter of memblock_alloc_from() is the lower limit for the memory allocation. When it is 0, the call is equivalent to memblock_alloc(). Signed-off-by: Mike Rapoport Acked-by: Paul Burton # MIPS part --- arch/alpha/kernel/core_cia.c | 2 +- arch/alpha/kernel/pci_iommu.c | 4

[PATCH v2 13/21] arch: don't memset(0) memory returned by memblock_alloc()

memblock_alloc() already clears the allocated memory, no point in doing it twice. Signed-off-by: Mike Rapoport Acked-by: Geert Uytterhoeven # m68k --- arch/c6x/mm/init.c | 1 - arch/h8300/mm/init.c| 1 - arch/ia64/kernel/mca.c | 2 -- arch/m68k/mm/mcfmmu.c | 1

[PATCH v2 16/21] mm/percpu: add checks for the return value of memblock_alloc*()

Add panic() calls if memblock_alloc() returns NULL. The panic() format duplicates the one used by memblock itself and in order to avoid explosion with long parameters list replace open coded allocation size calculations with a local variable. Signed-off-by: Mike Rapoport --- mm/percpu.c | 73

[PATCH v2 15/21] sparc: add checks for the return value of memblock_alloc*()

accommodate the change. Signed-off-by: Mike Rapoport Acked-by: David S. Miller --- arch/sparc/kernel/prom_32.c | 2 ++ arch/sparc/kernel/setup_64.c | 6 ++ arch/sparc/kernel/smp_64.c | 12 arch/sparc/mm/init_64.c | 11 +++ arch/sparc/mm/srmmu.c| 8 5

[PATCH v2 18/21] swiotlb: add checks for the return value of memblock_alloc*()

Add panic() calls if memblock_alloc() returns NULL. The panic() format duplicates the one used by memblock itself and in order to avoid explosion with long parameters list replace open coded allocation size calculations with a local variable. Signed-off-by: Mike Rapoport --- kernel/dma

[PATCH v2 10/21] memblock: refactor internal allocation functions

y CMA with exact requirement for lower bounds. The memblock_phys_alloc_nid() function is completely dropped as it is not used anywhere outside memblock and its only usage can be replaced by a call to memblock_alloc_range_nid(). Signed-off-by: Mike Rapoport --- include/linux/memblock.h | 1

[PATCH v2 17/21] init/main: add checks for the return value of memblock_alloc*()

Add panic() calls if memblock_alloc() returns NULL. The panic() format duplicates the one used by memblock itself and in order to avoid explosion with long parameters list replace open coded allocation size calculations with a local variable. Signed-off-by: Mike Rapoport --- init/main.c | 26

[PATCH v2 21/21] memblock: drop memblock_alloc_*_nopanic() variants

As all the memblock allocation functions return NULL in case of error rather than panic(), the duplicates with _nopanic suffix can be removed. Signed-off-by: Mike Rapoport Acked-by: Greg Kroah-Hartman --- arch/arc/kernel/unwind.c | 3 +-- arch/sh/mm/init.c | 2 +- arch/x86

[PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic

direct call to memblock_alloc_range_nid() and update the memblock_phys_alloc_try_nid() callers to check the returned value and panic in case of error. Signed-off-by: Mike Rapoport --- arch/arm64/mm/numa.c | 4 arch/powerpc/mm/numa.c | 4 mm/memblock.c | 4 +++- 3 files changed

[PATCH v2 20/21] memblock: memblock_alloc_try_nid: don't panic

As all the memblock_alloc*() users are now checking the return value and panic() in case of error, the panic() call can be removed from the core memblock allocator, namely memblock_alloc_try_nid(). Signed-off-by: Mike Rapoport --- mm/memblock.c | 15 +-- 1 file changed, 5 insertions

[PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

one below with manual massaging of format strings. @@ expression ptr, size, align; @@ ptr = memblock_alloc(size, align); + if (!ptr) + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__, size, align); Signed-off-by: Mike Rapoport Reviewed-by: Guo Ren # c

[PATCH v2 14/21] ia64: add checks for the return value of memblock_alloc*()

accommodate the change. Signed-off-by: Mike Rapoport --- arch/ia64/kernel/mca.c | 20 ++-- arch/ia64/mm/contig.c | 8 ++-- arch/ia64/mm/discontig.c| 4 arch/ia64/mm/init.c | 38 ++ arch/ia64/mm

[PATCH v2 09/21] memblock: drop memblock_alloc_base()

The memblock_alloc_base() function tries to allocate a memory up to the limit specified by its max_addr parameter and panics if the allocation fails. Replace its usage with memblock_phys_alloc_range() and make the callers check the return value and panic in case of error. Signed-off-by: Mike

[PATCH v2 03/21] memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc

e following semantic patch: @@ expression size, align; @@ - memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ANYWHERE) + memblock_phys_alloc(size, align) Signed-off-by: Mike Rapoport --- arch/arm/mm/init.c | 2 +- arch/sh/boards/mach-ap325rxa/setup.c | 2 +- arch/sh/boards/mach-

[PATCH v2 01/21] openrisc: prefer memblock APIs returning virtual address

The allocation of the page tables memory in openrics uses memblock_phys_alloc() and then converts the returned physical address to virtual one. Use memblock_alloc_raw() and add a panic() if the allocation fails. Signed-off-by: Mike Rapoport --- arch/openrisc/mm/init.c | 5 - 1 file changed

[PATCH 03/21] memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc

e following semantic patch: @@ expression size, align; @@ - memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ANYWHERE) + memblock_phys_alloc(size, align) Signed-off-by: Mike Rapoport --- arch/arm/mm/init.c | 2 +- arch/sh/boards/mach-ap325rxa/setup.c | 2 +- arch/sh/boards/mach-

[PATCH 00/21] Refine memblock API

memblock. Christophe Leroy (1): powerpc: use memblock functions returning virtual address Mike Rapoport (20): openrisc: prefer memblock APIs returning virtual address memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc memblock: drop memblock_alloc_base_nid() memblock

[PATCH 02/21] powerpc: use memblock functions returning virtual address

additional call sites ] Signed-off-by: Christophe Leroy Signed-off-by: Mike Rapoport --- arch/powerpc/kernel/dt_cpu_ftrs.c | 3 +-- arch/powerpc/kernel/irq.c | 5 - arch/powerpc/kernel/paca.c| 6 +- arch/powerpc/kernel/prom.c| 5 - arch/powerpc/kernel/setup_32

[PATCH 07/21] memblock: memblock_phys_alloc(): don't panic

Make the memblock_phys_alloc() function an inline wrapper for memblock_phys_alloc_range() and update the memblock_phys_alloc() callers to check the returned value and panic in case of error. Signed-off-by: Mike Rapoport --- arch/arm/mm/init.c | 4 arch/arm64/mm/mmu.c

[PATCH 05/21] memblock: emphasize that memblock_alloc_range() returns a physical address

llocations. Signed-off-by: Mike Rapoport --- include/linux/memblock.h | 5 ++--- mm/cma.c | 10 -- mm/memblock.c| 9 + 3 files changed, 11 insertions(+), 13 deletions(-) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index f7ef313..66df

[PATCH 08/21] memblock: drop __memblock_alloc_base()

The __memblock_alloc_base() function tries to allocate a memory up to the limit specified by its max_addr parameter. Depending on the value of this parameter, the __memblock_alloc_base() can is replaced with the appropriate memblock_phys_alloc*() variant. Signed-off-by: Mike Rapoport --- arch

[PATCH 12/21] arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0)

The last parameter of memblock_alloc_from() is the lower limit for the memory allocation. When it is 0, the call is equivalent to memblock_alloc(). Signed-off-by: Mike Rapoport --- arch/alpha/kernel/core_cia.c | 2 +- arch/alpha/kernel/pci_iommu.c | 4 ++-- arch/alpha/kernel/setup.c | 2

[PATCH 10/21] memblock: refactor internal allocation functions

y CMA with exact requirement for lower bounds. The memblock_phys_alloc_nid() function is completely dropped as it is not used anywhere outside memblock and its only usage can be replaced by a call to memblock_alloc_range_nid(). Signed-off-by: Mike Rapoport --- include/linux/memblock.h | 1

[PATCH 18/21] swiotlb: add checks for the return value of memblock_alloc*()

Add panic() calls if memblock_alloc() returns NULL. The panic() format duplicates the one used by memblock itself and in order to avoid explosion with long parameters list replace open coded allocation size calculations with a local variable. Signed-off-by: Mike Rapoport --- kernel/dma

[PATCH 13/21] arch: don't memset(0) memory returned by memblock_alloc()

memblock_alloc() already clears the allocated memory, no point in doing it twice. Signed-off-by: Mike Rapoport --- arch/c6x/mm/init.c | 1 - arch/h8300/mm/init.c| 1 - arch/ia64/kernel/mca.c | 2 -- arch/m68k/mm/mcfmmu.c | 1 - arch/microblaze/mm/init.c | 6

[PATCH 20/21] memblock: memblock_alloc_try_nid: don't panic

As all the memblock_alloc*() users are now checking the return value and panic() in case of error, the panic() call can be removed from the core memblock allocator, namely memblock_alloc_try_nid(). Signed-off-by: Mike Rapoport --- mm/memblock.c | 15 +-- 1 file changed, 5 insertions

[PATCH 17/21] init/main: add checks for the return value of memblock_alloc*()

Add panic() calls if memblock_alloc() returns NULL. The panic() format duplicates the one used by memblock itself and in order to avoid explosion with long parameters list replace open coded allocation size calculations with a local variable. Signed-off-by: Mike Rapoport --- init/main.c | 26

[PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()

one below with manual massaging of format strings. @@ expression ptr, size, align; @@ ptr = memblock_alloc(size, align); + if (!ptr) + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__, size, align); Signed-off-by: Mike Rapoport --- arch/alpha/kernel/

[PATCH 16/21] mm/percpu: add checks for the return value of memblock_alloc*()

Add panic() calls if memblock_alloc() returns NULL. The panic() format duplicates the one used by memblock itself and in order to avoid explosion with long parameters list replace open coded allocation size calculations with a local variable. Signed-off-by: Mike Rapoport --- mm/percpu.c | 73

[PATCH 14/21] ia64: add checks for the return value of memblock_alloc*()

accommodate the change. Signed-off-by: Mike Rapoport --- arch/ia64/kernel/mca.c | 20 ++-- arch/ia64/mm/contig.c | 8 ++-- arch/ia64/mm/discontig.c| 4 arch/ia64/mm/init.c | 38 ++ arch/ia64/mm

[PATCH 21/21] memblock: drop memblock_alloc_*_nopanic() variants

As all the memblock allocation functions return NULL in case of error rather than panic(), the duplicates with _nopanic suffix can be removed. Signed-off-by: Mike Rapoport --- arch/arc/kernel/unwind.c | 3 +-- arch/sh/mm/init.c | 2 +- arch/x86/kernel/setup_percpu.c | 10

[PATCH 15/21] sparc: add checks for the return value of memblock_alloc*()

accommodate the change. Signed-off-by: Mike Rapoport --- arch/sparc/kernel/prom_32.c | 2 ++ arch/sparc/kernel/setup_64.c | 6 ++ arch/sparc/kernel/smp_64.c | 12 arch/sparc/mm/init_64.c | 11 +++ arch/sparc/mm/srmmu.c| 8 5 files changed, 39

[PATCH 11/21] memblock: make memblock_find_in_range_node() and choose_memblock_flags() static

These functions are not used outside memblock. Make them static. Signed-off-by: Mike Rapoport --- include/linux/memblock.h | 4 mm/memblock.c| 4 ++-- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index

[PATCH 09/21] memblock: drop memblock_alloc_base()

The memblock_alloc_base() function tries to allocate a memory up to the limit specified by its max_addr parameter and panics if the allocation fails. Replace its usage with memblock_phys_alloc_range() and make the callers check the return value and panic in case of error. Signed-off-by: Mike

[PATCH 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic

direct call to memblock_alloc_range_nid() and update the memblock_phys_alloc_try_nid() callers to check the returned value and panic in case of error. Signed-off-by: Mike Rapoport --- arch/arm64/mm/numa.c | 4 arch/powerpc/mm/numa.c | 4 mm/memblock.c | 4 +++- 3 files changed

[PATCH 04/21] memblock: drop memblock_alloc_base_nid()

The memblock_alloc_base_nid() is a oneliner wrapper for memblock_alloc_range_nid() without any side effect. Replace it's usage by the direct calls to memblock_alloc_range_nid(). Signed-off-by: Mike Rapoport --- include/linux/memblock.h | 3 --- mm/memblock.c| 15 -

[PATCH 01/21] openrisc: prefer memblock APIs returning virtual address

The allocation of the page tables memory in openrics uses memblock_phys_alloc() and then converts the returned physical address to virtual one. Use memblock_alloc_raw() and add a panic() if the allocation fails. Signed-off-by: Mike Rapoport --- arch/openrisc/mm/init.c | 5 - 1 file changed

Re: ASMedia SATA Bridge not enumerating without quirk

installing kmod-usb-storage-uas everything kicked into life Sorry for the noise On 21 March 2018 at 17:55, Mike Lothian wrote: > Lastly here's the lsusb -v and dmesg from 4.9.87 on the router without > the quirk added > > On 21 March 2018 at 17:50, Mike Lothian wrote: >> A

Re: ASMedia SATA Bridge not enumerating without quirk

Lastly here's the lsusb -v and dmesg from 4.9.87 on the router without the quirk added On 21 March 2018 at 17:50, Mike Lothian wrote: > Also here's the kernel config for the router, it's now 4.9.87 > > > > On 21 March 2018 at 17:23, Menion wrote: >> Yes tha

Re: ASMedia SATA Bridge not enumerating without quirk

; I cannot answer here, but I am wondering if it is possible that if the > kernel is compiled without UAS support, then a device showing UASP > capability won't get enumerated at all instead of being downgraded to > usb-storage. > > 2018-03-21 18:19 GMT+01:00 Mike Lothian : &

Re: ASMedia SATA Bridge not enumerating without quirk

or USB-STORAGE mode? > I cannot answer here, but I am wondering if it is possible that if the > kernel is compiled without UAS support, then a device showing UASP > capability won't get enumerated at all instead of being downgraded to > usb-storage. > > 2018-03-21 18:19 GMT+01:0

Re: ASMedia SATA Bridge not enumerating without quirk

o strange, it is completely dead from USB host perspective > in UASP mode > What lsusb shows when it is attached in UASP mode? > Can you test it with some "regular" host with USB 3.0, like a PC? > > 2018-03-21 18:07 GMT+01:00 Mike Lothian : >> Sorry, yes that was me

Re: ASMedia SATA Bridge not enumerating without quirk

eattach > the device? > Anyhow I see some strange reset from the USB host. What is this > device? Perhaps some self-powered external HDD? > > 2018-03-21 17:56 GMT+01:00 Mike Lothian : >> It had both, as did my follow up, the follow up should be more clear though >> >&g

Re: ASMedia SATA Bridge not enumerating without quirk

It had both, as did my follow up, the follow up should be more clear though On 21 March 2018 at 16:45, Menion wrote: > You sent the dmesg with quirks :u enabled > We need the one without quirks :u, when the device takes UAS driver > Bye > > 2018-03-21 17:41 GMT+01:00 Mike

Re: ASMedia SATA Bridge not enumerating without quirk

So I rebooted my router, and repeated without the other usb stick attached So you should have it with it booting without the quirk, reconnecting without the quirk, then reconnecting with the quirk, where the hard disk is enumerated On 21 March 2018 at 16:41, Mike Lothian wrote: >

Re: ASMedia SATA Bridge not enumerating without quirk

Hi Please find attached my dmesg Cheers Mike On 21 March 2018 at 16:12, Oliver Neukum wrote: > Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH: >> > I'm guessing it doesn't quite match up with the rules already in place >> > in uas-detect.h >> &g

ASMedia SATA Bridge not enumerating without quirk

t.h Looks like it's an ASM1053 that can't do UAS Regards Mike lsusb Description: Binary data

[PATCH] usb: phy-generic: Use gpiod_set_value_cansleep

The nop_reset and shutdown methods are called in a context that can sleep, so use gpiod_set_value_cansleep instead of gpiod_set_value. If you've connected the reset line to a GPIO expander, you'd get a kernel "slowpath" warning with gpiod_set_value. Signed-off-by: Mike Loo

Re: USB-C Devices only show up if connected at boot

On 29 January 2018 at 09:44, Mika Westerberg wrote: > On Sat, Jan 27, 2018 at 01:31:00PM +0000, Mike Lothian wrote: >> On 26 January 2018 at 09:53, Mike Lothian wrote: >> > On 26 January 2018 at 08:31, Mika Westerberg >> > wrote: >> >> On Fri, Jan 26,

Re: USB-C Devices only show up if connected at boot

On 26 January 2018 at 09:53, Mike Lothian wrote: > On 26 January 2018 at 08:31, Mika Westerberg > wrote: >> On Fri, Jan 26, 2018 at 08:07:56AM +, Mike Lothian wrote: >>> Whether CONFIG_HOTPLUG_PCI_ACPI=y or CONFIG_HOTPLUG_PCI_ACPI=n the >>> device doesn'

Re: USB-C Devices only show up if connected at boot

On 26 January 2018 at 08:31, Mika Westerberg wrote: > On Fri, Jan 26, 2018 at 08:07:56AM +0000, Mike Lothian wrote: >> Whether CONFIG_HOTPLUG_PCI_ACPI=y or CONFIG_HOTPLUG_PCI_ACPI=n the >> device doesn't show unless echo 1 > /sys/bus/pci/rescan is issued > > That

Re: USB-C Devices only show up if connected at boot

On 26 January 2018 at 06:33, Mika Westerberg wrote: > On Thu, Jan 25, 2018 at 10:20:02PM +0000, Mike Lothian wrote: >> I've just tried this and the USB-C device was detected :D This is the >> first time it's ever been detected after boot >> >> 02:00.0

Re: USB-C Devices only show up if connected at boot

On 25 January 2018 at 21:31, Mike Lothian wrote: > > Hi > > I've tried with and without those being set, neither help, having > CONFIG_HOTPLUG_PCI_ACPI=y on causes my NVMe drive to disappear after > suspend > > I'll switch back into windows and check I'v

Re: USB-C Devices only show up if connected at boot

On Thu, 25 Jan 2018 at 10:52 Mika Westerberg wrote: > > On Thu, Jan 25, 2018 at 12:35:49PM +0200, Heikki Krogerus wrote: > > +Mika > > > > On Tue, Jan 23, 2018 at 05:43:27PM +, Mike Lothian wrote: > > > On Tue, 23 Jan 2018 at 17:30 Greg KH wrote: > > &g

RE: Request to add new VID/PID to PL2303 driver

Thanks, guys! Do you know what kernel version will I find this addition? -Original Message- From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold Sent: Thursday, January 25, 2018 4:55 PM To: 'g...@kroah.com' Cc: Chu.Mike [朱堅宜]; Johan Hovold; linux-usb@vger.kernel.org Sub

Request to add new VID/PID to PL2303 driver

Thanks, Mike Chu Prolific Technology Inc. 保密警語: 本電子郵件內容及其附加檔案均視為機密資料，受保密合約保護或依法不得洩漏。其內容僅供指定收件人按限定範圍或特殊目的合法使用，未經授權者收到此信息均無權閱讀、使用、複製、洩漏或散佈。若您並非本郵件之指定收件人，請即刻回覆郵件並永久刪除此郵件及其附件和銷毀所有複印文件。電子郵件的傳輸可能遭攔截、損毀、遺失、破壞、遲到或不完整、或包含病毒，無法保證其安全或無誤。寄件人不承擔因本電子郵件的錯誤或遺漏所產生的任何損害賠償責任。 Confidentiality Notice: This e-mail

Re: USB-C Devices only show up if connected at boot

On 24 January 2018 at 10:42, Oliver Neukum wrote: > Am Mittwoch, den 24.01.2018, 10:30 + schrieb Mike Lothian: > > echo "file $NAMEOFKERNELSOURCEFILEYOUWANT +mfp" > > /sys/kernel/debug/dynamic_debug/control > > HTH > Oliver > OK

Re: USB-C Devices only show up if connected at boot

On 24 January 2018 at 10:04, Oliver Neukum wrote: > Am Mittwoch, den 24.01.2018, 09:36 + schrieb Mike Lothian: >> >> I've played around with this some more, if the device is connected >> after boot nothing shows when it's plugged in >> >>

Re: USB-C Devices only show up if connected at boot

g the hard drive didn't enumerate > > It sounds like your machine has a lot of ACPI issues :( > > greg k-h Hi I've played around with this some more, if the device is connected after boot nothing shows when it's plugged in I did however get more messages out when I disconnected the device after booting with it (see attached) Regards Mike dmesg.extra.info.xz Description: application/xz

Re: USB-C Devices only show up if connected at boot

On Wed, 24 Jan 2018 at 04:07 Greg KH wrote: > > On Tue, Jan 23, 2018 at 05:43:27PM +, Mike Lothian wrote: > > On Tue, 23 Jan 2018 at 17:30 Greg KH wrote: > > > > > > On Tue, Jan 23, 2018 at 05:12:03PM +, Mike Lothian wrote: > > > > Hi > >

Re: USB-C Devices only show up if connected at boot

> > Hi Mike, > > You did not specify what provides the USB-C port. > > I suppose that your USB-C port is actually a Thunderbolt 3 port from an Intel > controller. > > What you describe is a well known bug that affects all Thunderbolt 3 ports > and this bug has alwa

Re: USB-C Devices only show up if connected at boot

On Tue, 23 Jan 2018 at 17:30 Greg KH wrote: > > On Tue, Jan 23, 2018 at 05:12:03PM +, Mike Lothian wrote: > > Hi > > > > I raised https://bugzilla.kernel.org/show_bug.cgi?id=198557 but was > > informed by Greg bugs should be raised on the mailing list not in

USB-C Devices only show up if connected at boot

dmesg, the device works fine if connected via USB-A I've witnessed this behaviour since getting the laptop at the end of 2015 so this isn't a regression The full dmesg can be seen here https://bugzilla.kernel.org/attachment.cgi?id=273801 Thanks for any help you can offer Mike -- To u

Re: dvb usb issues since kernel 4.9

cy is bounded by the sched_wakeup_granularity_ns, > which with 3 ms is not good enough for their use-case. Note of caution wrt twiddling sched_wakeup_granularity_ns: it must remain < sched_latency_ns/2 else you effectively disable wakeup preemption completely, turning CFS into a tick granularity

Re: [PATCH][RFC] usb: hub: Cycle HUB power when initialization fails

On 03-11-17 18:27, Alan Stern wrote: On Fri, 3 Nov 2017, Mike Looijmans wrote: Sometimes the USB device gets confused about the state of the initialization and the connection fails. In particular, the device thinks that it's already set up and running while the host thinks the device

[PATCH][RFC] usb: hub: Cycle HUB power when initialization fails

b 1-1-port3: attempt power cycle usb 1-1.3: new high-speed USB device number 21 using ci_hdrc usb-storage 1-1.3:1.2: USB Mass Storage device detected Signed-off-by: Mike Looijmans --- This is a fix I did for a customer which might be appropriate for upstream. What do you think? drivers

USB- Kernel 4.4.0.-59 / -62 - Hardware (Sense) Errors without a reason

16.04 with a clean installation. The Bugtracker at redhat shows a similar issue: https://bugzilla.redhat.com/show_bug.cgi?id=1351305 Regards Mike OS: Xubuntu 16.04 Kernel: - Linux toshiba 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:36:54 UTC 2017 i686 athlon i686 GNU/Linux and Linux

[PATCH] usb: core: urb make use of usb_endpoint_maxp_mult

acket size") Signed-off-by: Mike Krinkin --- drivers/usb/core/urb.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c index 0be49a1..d75cb8c 100644 --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -412,1

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

Hello, On 2016-08-01 13:57, Durval Menezes wrote: > Hi Mathias, > > On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman > wrote: >>> On 01.08.2016 13:15, Durval Menezes wrote: >>> Hello Mike, Mathias, list, >>> >>> On 06.02.2016 19:08, Mike Murdoc

[PATCH] cp210x: Add ID for Link ECU

The Link ECU is an aftermarket ECU computer for vehicles that provides full tuning abilities as well as datalogging and displaying capabilities via the USB to Serial adapter built into the device. Signed-off-by: Mike Manning --- drivers/usb/serial/cp210x.c |2 ++ 1 file changed, 2

[PATCH] cp210x: Add ID for Link ECU

Please find attached patch file for addition of Link G4 and Link G4+ Ecu's. >From a705ab11807ee600b9252f15681f64a346377629 Mon Sep 17 00:00:00 2001 Subject: [PATCH] cp210x: Add ID for Link ECU From: Mike Manning The Link ECU is an aftermarket ECU computer for vehicles that provides full

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

On 2016-03-14 10:06, Mathias Nyman wrote: > On 13.03.2016 11:16, Mike Murdoch wrote: >> >> >> On 2016-03-01 16:32, Mathias Nyman wrote: >>> On 18.02.2016 18:34, Mike Murdoch wrote: >>>> >>>> >>>> On 2016-02-18 16:12, Mathias Nyman

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

On 2016-03-01 16:32, Mathias Nyman wrote: > On 18.02.2016 18:34, Mike Murdoch wrote: >> >> >> On 2016-02-18 16:12, Mathias Nyman wrote: >>> On 16.02.2016 23:58, main.ha...@googlemail.com wrote: >>>> >>>> >>>> On 2016-02-08 15

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

On 2016-02-18 16:12, Mathias Nyman wrote: > On 16.02.2016 23:58, main.ha...@googlemail.com wrote: >> >> >> On 2016-02-08 15:31, Mathias Nyman wrote: >>> Hi >>> >>> On 06.02.2016 19:08, Mike Murdoch wrote: >>>> Bug ID: 111251 >>&g

NEC uPD720200 xHCI Controller dies when Runtime PM enabled

Bug ID: 111251 Hello, I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on kernel 4.4.1-gentoo. 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Lenovo uPD720200 USB 3.0 Host Controller Flags: bus master, f

Re: [PATCH v2] usb: gadget: ether: Allow changing the MTU

Just a "ping" reminder, I'd like to inquire about the status of this patch... On 30-11-15 12:18, Mike Looijmans wrote: The gadget ethernet driver supports changing the MTU, but only allows this when the USB cable is removed. The comment indicates that this is because the &

[PATCH v2] usb: gadget: ether: Allow changing the MTU

using "ifconfig usb0 mtu 15000") without having to manually pull the plug or change the driver's default setting. This is especially important after commit bba787a860fa ("usb: gadget: ether: Allow jumbo frames") Signed-off-by: Mike Looijmans --- v2: Fix commit reference (

[PATCH] usb: gadget: ether: Allow changing the MTU

using "ifconfig usb0 mtu 15000") without having to manually pull the plug or change the driver's default setting. This is especially important after commit bba787a860fa: "usb: gadget: ether: Allow jumbo frames". Signed-off-by: Mike Looijmans --- drivers/usb/gadget/function/

Re: [PATCH] usb/gadget/function/u_ether.c: Allow jumbo frames

e set from user space, and the impact on performance is quite impressive. On 05-08-15 08:54, Mike Looijmans wrote: USB network adapters support Jumbo frames. The only thing blocking that feature is the code in the gadget driver that disposes of packets larger than 1518 bytes, and the limit on the

Re: [PATCH] usb/gadget/function/u_ether.c: Allow jumbo frames

ping... More than a week has passed, haven't seen any response though. Any comments? On 05-08-15 08:54, Mike Looijmans wrote: USB network adapters support Jumbo frames. The only thing blocking that feature is the code in the gadget driver that disposes of packets larger than 1518 bytes

[PATCH] usb/gadget/function/u_ether.c: Allow jumbo frames

MTU=15000, PC-to-gadget: 239 Mbps, Gadget-to-PC: 361 Mbps On boards with slower CPUs the performance improvement will be relatively much larger, e.g. an OMAP-L138 increased from 40 to 220 Mbps using a similar patch on an 2.6.37 kernel. Signed-off-by: Mike Looijmans --- drivers/usb/gadget

Re: [PATCH 1/2] usb: chipidea: Reduce ULPI PHY reset pulse to datasheet spec of 1us

On 02-07-15 11:39, David Laight wrote: From: Peter Chen Sent: 30 June 2015 03:06 On Fri, Jun 26, 2015 at 03:47:03PM +0200, Mike Looijmans wrote: The datasheet for the 334x PHY mentions that a reset can be performed: "... by bringing the pin low for a minimum of 1 microsecond and then hig

[PATCH 1/2] usb: chipidea: Reduce ULPI PHY reset pulse to datasheet spec of 1us

t the chip will assert the DIR output. 1ms seems like a safe time to wait for that to happen, so no change there. Signed-off-by: Mike Looijmans --- drivers/usb/chipidea/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/co

[PATCH 2/2] usb: chipidea: Wait 50 ms before reading ID bit

ated while already being supplied from the host PC. Signed-off-by: Mike Looijmans --- drivers/usb/chipidea/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index c865abe..4c6cf48 100644 --- a/drivers/usb/chipidea/core.c +++ b/d

Re: XHCI, "brain-dead scanner", and microframe rounding

Aww, that's too bad. Let me know if you'd like me to test a modified version when you get the time. --Mike Mammarella On May 21, 2015, at 4:18 AM, Mathias Nyman wrote: > Hi > > The fix went upstream, but caused regression for other users, and had to be > revert

Re: XHCI, "brain-dead scanner", and microframe rounding

On Jan 29, 2015, at 8:42 AM, Mathias Nyman wrote: > On 27.01.2015 14:12, Gunter Königsmann wrote: >> That's very good news indeed. >> >> Will re-run the tests on my scanner and looking forward to the fix entering >> mainline. In the meantime I can acknowledge that with the fix my computer >> ac

Re: XHCI, "brain-dead scanner", and microframe rounding

conds, and start the scan around 477. This is awesome! I'm not familiar with how long this sort of fix usually takes to show up in official kernels; when might that happen? I'd be interested to try and get it picked up by distribution kernel packages (if the patch applies cleanly) so I can st

Re: XHCI, "brain-dead scanner", and microframe rounding

On Mon, 15 Sep 2014, Mathias Nyman wrote: On 09/14/2014 01:52 AM, Mike Mammarella wrote: On Sat, 26 Jul 2014, Mike Mammarella wrote: On Fri, 4 Jul 2014, Mathias Nyman wrote: On 07/01/2014 09:07 AM, Mike Mammarella wrote: Hi Can you add xhci debugging by enabling CONFIG_DYNAMIC_DEBUG, and

Re: XHCI, "brain-dead scanner", and microframe rounding

On Sat, 26 Jul 2014, Mike Mammarella wrote: On Fri, 4 Jul 2014, Mathias Nyman wrote: On 07/01/2014 09:07 AM, Mike Mammarella wrote: Hi Can you add xhci debugging by enabling CONFIG_DYNAMIC_DEBUG, and run `echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control`

  1   2   >