Re: [PATCH] klp: make object/func-walking helpers more robust

On Thu, Apr 28, 2016 at 04:34:08PM +0200, Miroslav Benes wrote: > Current object-walking helper checks the presence of obj->funcs to > determine the end of objs array in klp_object structure. This is > somewhat fragile because one can easily forget about funcs definition > during livepatch

Re: [PATCH] klp: make object/func-walking helpers more robust

On Thu, Apr 28, 2016 at 04:34:08PM +0200, Miroslav Benes wrote: > Current object-walking helper checks the presence of obj->funcs to > determine the end of objs array in klp_object structure. This is > somewhat fragile because one can easily forget about funcs definition > during livepatch

Re: Question about request queues in I/O scheduling

Max Kanushin writes: > Thank you very much for the reply. My general idea is take control of all > request queues to block and unblock them manually depending on their load. > One of my steps is to find a length of a queue to decide if to block it. > Actually I think I've found

Re: Question about request queues in I/O scheduling

Max Kanushin writes: > Thank you very much for the reply. My general idea is take control of all > request queues to block and unblock them manually depending on their load. > One of my steps is to find a length of a queue to decide if to block it. > Actually I think I've found the way. If I got

Re: [PATCH v2] devpts: Make ptmx be owned by the userns owner as a fallback

On Tue, Mar 15, 2016 at 1:05 PM, Andy Lutomirski wrote: > New devpts instances have ptmx owned by the inner uid and gid 0. > > For container-style namespaces (LXC, etc), this should have no > effect, this is fine. > > For sandbox-style namespaces (xdg-app and similar), this is >

Re: [PATCH v2] devpts: Make ptmx be owned by the userns owner as a fallback

On Tue, Mar 15, 2016 at 1:05 PM, Andy Lutomirski wrote: > New devpts instances have ptmx owned by the inner uid and gid 0. > > For container-style namespaces (LXC, etc), this should have no > effect, this is fine. > > For sandbox-style namespaces (xdg-app and similar), this is > problematic --

Re: [PATCH] gpio: tegra: Implement gpio_get_direction callback

On 04/29/2016 06:31 AM, Laxman Dewangan wrote: Implement gpio_get_direction() callback for Tegra GPIO. The direction is only valid if the pin is configured as GPIO. If pin is not configured in GPIO mode then this function return error. This makes debugfs and initial reading of the state of the

Re: [PATCH] gpio: tegra: Implement gpio_get_direction callback

On 04/29/2016 06:31 AM, Laxman Dewangan wrote: Implement gpio_get_direction() callback for Tegra GPIO. The direction is only valid if the pin is configured as GPIO. If pin is not configured in GPIO mode then this function return error. This makes debugfs and initial reading of the state of the

Re: [PATCH 25/25] arm64:ilp32: add ARM64_ILP32 to Kconfig

On Fri, Apr 29, 2016 at 07:08:55PM +0300, Yury Norov wrote: > On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote: > > On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote: > > > +config ARM64_ILP32 > > > + bool "Kernel support for ILP32" > > > + select COMPAT_WRAPPER > > > +

Re: [PATCH 25/25] arm64:ilp32: add ARM64_ILP32 to Kconfig

On Fri, Apr 29, 2016 at 07:08:55PM +0300, Yury Norov wrote: > On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote: > > On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote: > > > +config ARM64_ILP32 > > > + bool "Kernel support for ILP32" > > > + select COMPAT_WRAPPER > > > +

Re: klp: make object/func-walking helpers more robust

+++ Miroslav Benes [29/04/16 09:48 +0200]: On Thu, 28 Apr 2016, Josh Poimboeuf wrote: On Thu, Apr 28, 2016 at 02:21:31PM -0400, Jessica Yu wrote: > +++ Miroslav Benes [28/04/16 16:34 +0200]: > > Current object-walking helper checks the presence of obj->funcs to > > determine the end of objs

Re: klp: make object/func-walking helpers more robust

+++ Miroslav Benes [29/04/16 09:48 +0200]: On Thu, 28 Apr 2016, Josh Poimboeuf wrote: On Thu, Apr 28, 2016 at 02:21:31PM -0400, Jessica Yu wrote: > +++ Miroslav Benes [28/04/16 16:34 +0200]: > > Current object-walking helper checks the presence of obj->funcs to > > determine the end of objs

Re: [PATCH 25/25] arm64:ilp32: add ARM64_ILP32 to Kconfig

On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote: > On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote: > > +config ARM64_ILP32 > > + bool "Kernel support for ILP32" > > + select COMPAT_WRAPPER > > + help > > + This option enables support for AArch64 ILP32 user

Re: [PATCH 25/25] arm64:ilp32: add ARM64_ILP32 to Kconfig

On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote: > On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote: > > +config ARM64_ILP32 > > + bool "Kernel support for ILP32" > > + select COMPAT_WRAPPER > > + help > > + This option enables support for AArch64 ILP32 user

Re: [PATCH 25/25] arm64:ilp32: add ARM64_ILP32 to Kconfig

On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote: > +config ARM64_ILP32 > + bool "Kernel support for ILP32" > + select COMPAT_WRAPPER > + help > + This option enables support for AArch64 ILP32 user space. ILP32 > + is an ABI where long and pointers are 32bits but

Re: [PATCH 25/25] arm64:ilp32: add ARM64_ILP32 to Kconfig

On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote: > +config ARM64_ILP32 > + bool "Kernel support for ILP32" > + select COMPAT_WRAPPER > + help > + This option enables support for AArch64 ILP32 user space. ILP32 > + is an ABI where long and pointers are 32bits but

Re: [PATCH v2 6/6] mmc: sdhci-of-arasan: overwrite enhanced strobe callback

On Fri, 2016-04-29 at 10:48:34 +0800, Shawn Lin wrote: > Currently sdhci-arasan 5.1 can support enhanced strobe function, > and we now limit it just for "arasan,sdhci-5.1". Add > mmc-hs400-enhanced-strobe in DT to enable the function if we'r sure > our controller can support it. > >

Re: [PATCH v2 6/6] mmc: sdhci-of-arasan: overwrite enhanced strobe callback

On Fri, 2016-04-29 at 10:48:34 +0800, Shawn Lin wrote: > Currently sdhci-arasan 5.1 can support enhanced strobe function, > and we now limit it just for "arasan,sdhci-5.1". Add > mmc-hs400-enhanced-strobe in DT to enable the function if we'r sure > our controller can support it. > >

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote: > You are trying to take a generalized kernel and somehow "know" about the > hardware ahead of time it is going to run on. That seems like two > conflicting requirements, don't you agree? We would have the 8250 serial port in any kernel.

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote: > You are trying to take a generalized kernel and somehow "know" about the > hardware ahead of time it is going to run on. That seems like two > conflicting requirements, don't you agree? We would have the 8250 serial port in any kernel.

Re: [PATCH 24/25] arm64:ilp32: add vdso-ilp32 and use for signal return

On Wed, Apr 06, 2016 at 01:08:46AM +0300, Yury Norov wrote: > ILP32 VDSO exports next symbols: > __kernel_rt_sigreturn; > __kernel_gettimeofday; > __kernel_clock_gettime; > __kernel_clock_getres; [...] > +$(obj)/gettimeofday-ilp32.o: $(src)/../vdso/gettimeofday.S > + $(call

Re: [PATCH 24/25] arm64:ilp32: add vdso-ilp32 and use for signal return

On Wed, Apr 06, 2016 at 01:08:46AM +0300, Yury Norov wrote: > ILP32 VDSO exports next symbols: > __kernel_rt_sigreturn; > __kernel_gettimeofday; > __kernel_clock_gettime; > __kernel_clock_getres; [...] > +$(obj)/gettimeofday-ilp32.o: $(src)/../vdso/gettimeofday.S > + $(call

Re: [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree

On 4/28/2016 11:44 PM, Geert Uytterhoeven wrote: > On Fri, Apr 29, 2016 at 8:39 AM, Gaurav Minocha > wrote: >> On Thu, Apr 28, 2016 at 3:32 PM, Rob Herring wrote: >>> On Thu, Apr 28, 2016 at 4:46 PM, Frank Rowand >>>

Re: [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree

On 4/28/2016 11:44 PM, Geert Uytterhoeven wrote: > On Fri, Apr 29, 2016 at 8:39 AM, Gaurav Minocha > wrote: >> On Thu, Apr 28, 2016 at 3:32 PM, Rob Herring wrote: >>> On Thu, Apr 28, 2016 at 4:46 PM, Frank Rowand >>> wrote: From: Frank Rowand Determining which kernel config

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 04:37:57PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote: > > On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: > > > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > > > > On Thu, Apr 28, 2016 at

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 04:37:57PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote: > > On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: > > > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > > > > On Thu, Apr 28, 2016 at

Re: [PATCH v2 08/11] serial: sh-sci: Correct pin initialization on (H)SCIF

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Correct pin initialization on (H)SCIF: > - RTS must be deasserted (it's active low), > - SCK must be an input, as it may be used as the optional external > clock input. > > Initial pin configuration must always be done: > - Regardless

Re: [PATCH v2 08/11] serial: sh-sci: Correct pin initialization on (H)SCIF

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Correct pin initialization on (H)SCIF: > - RTS must be deasserted (it's active low), > - SCK must be an input, as it may be used as the optional external > clock input. > > Initial pin configuration must always be done: > - Regardless

Re: [PATCH kernel v4 02/11] vfio/spapr: Relax the IOMMU compatibility check

On Fri, 29 Apr 2016 18:55:15 +1000 Alexey Kardashevskiy wrote: > We are going to have multiple different types of PHB on the same system > with POWER8 + NVLink and PHBs will have different IOMMU ops. However > we only really care about one callback - create_table - so we can >

Re: [PATCH kernel v4 02/11] vfio/spapr: Relax the IOMMU compatibility check

On Fri, 29 Apr 2016 18:55:15 +1000 Alexey Kardashevskiy wrote: > We are going to have multiple different types of PHB on the same system > with POWER8 + NVLink and PHBs will have different IOMMU ops. However > we only really care about one callback - create_table - so we can > relax the

Re: [PATCH v2 07/11] serial: sh-sci: Add more Serial Port Control/Data Register documentation

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Improve documentation for the SCIFA/SCIFB Serial Port Control and Data > Registers: > - State clearly that the RTS and CTS lines are active-low, > - Document the bits related to the serial port's SCK, RXD, and TXD > pins. Reviewed-by:

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Thu, Apr 28, 2016 at 02:57:11PM +0200, Borislav Petkov wrote: > > After d2f7cbe7b26a74 ("x86/efi: Runtime services virtual mapping") was > > introduced (I'm sure you remember the BIOS issue we had a while back) we > > had to fall back to using EFI_OLD_MEMMAP, so for a while we relied on > >

Re: [PATCH kernel v4 01/11] vfio_pci: Test for extended capabilities if config space > 256 bytes

On Fri, 29 Apr 2016 18:55:14 +1000 Alexey Kardashevskiy wrote: > PCI-Express spec says that reading 4 bytes at offset 100h should return > zero if there is no extended capability so VFIO reads this dword to > know if there are extended capabilities. > > However it is not always

Re: [PATCH v2 07/11] serial: sh-sci: Add more Serial Port Control/Data Register documentation

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Improve documentation for the SCIFA/SCIFB Serial Port Control and Data > Registers: > - State clearly that the RTS and CTS lines are active-low, > - Document the bits related to the serial port's SCK, RXD, and TXD > pins. Reviewed-by:

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Thu, Apr 28, 2016 at 02:57:11PM +0200, Borislav Petkov wrote: > > After d2f7cbe7b26a74 ("x86/efi: Runtime services virtual mapping") was > > introduced (I'm sure you remember the BIOS issue we had a while back) we > > had to fall back to using EFI_OLD_MEMMAP, so for a while we relied on > >

Re: [PATCH kernel v4 01/11] vfio_pci: Test for extended capabilities if config space > 256 bytes

On Fri, 29 Apr 2016 18:55:14 +1000 Alexey Kardashevskiy wrote: > PCI-Express spec says that reading 4 bytes at offset 100h should return > zero if there is no extended capability so VFIO reads this dword to > know if there are extended capabilities. > > However it is not always possible to

Re: [PATCH v2 06/11] serial: sh-sci: Add more Serial Port Register documentation

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Improve documentation for the (H)SCIF Serial Port Register: > - Make it clear the RTS and CTS lines are active-low, > - Document the bits related to the serial port's clock pin. Reviewed-by: Peter Hurley

Re: [PATCH v2 06/11] serial: sh-sci: Add more Serial Port Register documentation

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Improve documentation for the (H)SCIF Serial Port Register: > - Make it clear the RTS and CTS lines are active-low, > - Document the bits related to the serial port's clock pin. Reviewed-by: Peter Hurley

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Friday 29 April 2016 16:13:38 Yury Norov wrote: > On Fri, Apr 29, 2016 at 12:43:41AM +0200, Arnd Bergmann wrote: > > On Friday 29 April 2016 01:21:37 Yury Norov wrote: > > > > > > arch/arm64/kernel/sys_ilp32.c:59:0: warning: "__SYSCALL" redefined > > > #define __SYSCALL(nr, sym) [nr] = sym,

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Friday 29 April 2016 16:13:38 Yury Norov wrote: > On Fri, Apr 29, 2016 at 12:43:41AM +0200, Arnd Bergmann wrote: > > On Friday 29 April 2016 01:21:37 Yury Norov wrote: > > > > > > arch/arm64/kernel/sys_ilp32.c:59:0: warning: "__SYSCALL" redefined > > > #define __SYSCALL(nr, sym) [nr] = sym,

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Fri, Apr 29, 2016 at 10:01:15AM +0100, Matt Fleming wrote: > On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote: > > > > From what I know, this works because the first PGD entry (the one > > containing the identity mappings) of the trampoline_pgd is shared with > > the main kernel PGD

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Fri, Apr 29, 2016 at 10:01:15AM +0100, Matt Fleming wrote: > On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote: > > > > From what I know, this works because the first PGD entry (the one > > containing the identity mappings) of the trampoline_pgd is shared with > > the main kernel PGD

Re: [PATCH v2 05/11] serial: sh-sci: Do not open-code sci_getreg()

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Replace open-coded variants of sci_getreg() by function calls, and drop > intermediate variables where appropriate. Reviewed-by: Peter Hurley

Re: [PATCH v2 04/11] serial: sh-sci: Add support for GPIO-controlled modem lines

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Enhance the Renesas SCI UART driver to add support for GPIO-controlled > modem lines (CTS, DSR, DCD, RNG, RTS, DTR), using the serial_mctrl_gpio > helpers. > > GPIO-controlled modem lines can be used when dedicated modem lines are > not

Re: [PATCH v2 05/11] serial: sh-sci: Do not open-code sci_getreg()

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Replace open-coded variants of sci_getreg() by function calls, and drop > intermediate variables where appropriate. Reviewed-by: Peter Hurley

Re: [PATCH v2 04/11] serial: sh-sci: Add support for GPIO-controlled modem lines

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Enhance the Renesas SCI UART driver to add support for GPIO-controlled > modem lines (CTS, DSR, DCD, RNG, RTS, DTR), using the serial_mctrl_gpio > helpers. > > GPIO-controlled modem lines can be used when dedicated modem lines are > not

Re: [PATCH] sched/core: don't include asm/mmu_context from drivers

On Friday 29 April 2016 09:42:18 Steven Rostedt wrote: > On Fri, 29 Apr 2016 10:52:32 +0200 > Arnd Bergmann wrote: > > > This reverts the earlier fix attempt and works around the problem > > by including both linux/mmu_context.h and asm/mmu_context.h from > > kernel/sched/core.c.

Re: [PATCH] sched/core: don't include asm/mmu_context from drivers

On Friday 29 April 2016 09:42:18 Steven Rostedt wrote: > On Fri, 29 Apr 2016 10:52:32 +0200 > Arnd Bergmann wrote: > > > This reverts the earlier fix attempt and works around the problem > > by including both linux/mmu_context.h and asm/mmu_context.h from > > kernel/sched/core.c. This is not a

Re: [PATCH v2 03/11] serial: sh-sci: Always set TIOCM_CTS in .get_mctrl() callback

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Documentation/serial/driver clearly states: > > If the port does not support CTS, DCD or DSR, the driver should > indicate that the signal is permanently active. > > Hence always set TIOCM_CTS, as we currently don't look at the CTS >

Re: [PATCH v2 03/11] serial: sh-sci: Always set TIOCM_CTS in .get_mctrl() callback

On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: > Documentation/serial/driver clearly states: > > If the port does not support CTS, DCD or DSR, the driver should > indicate that the signal is permanently active. > > Hence always set TIOCM_CTS, as we currently don't look at the CTS >

Re: [PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

Adding David, forgot that before hitting send. -Daniel On Fri, Apr 29, 2016 at 5:36 PM, Daniel Vetter wrote: > On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote: >> >> On 29/04/16 17:55, Daniel Vetter wrote: >> >> >> Who's calling {write,fillrect,copyarea,imageblit}

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote: > On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: > > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > > > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote: > > > > Currently autoconf spends

Re: [PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

Adding David, forgot that before hitting send. -Daniel On Fri, Apr 29, 2016 at 5:36 PM, Daniel Vetter wrote: > On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote: >> >> On 29/04/16 17:55, Daniel Vetter wrote: >> >> >> Who's calling {write,fillrect,copyarea,imageblit} in an atomic

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote: > On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: > > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > > > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote: > > > > Currently autoconf spends

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr 2016, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Matt Fleming wrote: > > On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote: > > > On Fri, 29 Apr 2016, Ingo Molnar wrote: > > > > Also, it would be nice to have all things EFI in a single tree, the > > > > conflicts are >

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr 2016, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Matt Fleming wrote: > > On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote: > > > On Fri, 29 Apr 2016, Ingo Molnar wrote: > > > > Also, it would be nice to have all things EFI in a single tree, the > > > > conflicts are >

Re: [PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote: > > On 29/04/16 17:55, Daniel Vetter wrote: > > >> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context? > >> That sounds like a very bad idea to me... > >> > >> If this is only for accumulating changes, I think it

Re: [PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote: > > On 29/04/16 17:55, Daniel Vetter wrote: > > >> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context? > >> That sounds like a very bad idea to me... > >> > >> If this is only for accumulating changes, I think it

Re: linux-next: Tree for Apr 29 (btrfs)

On 04/29/16 00:13, Stephen Rothwell wrote: > Hi all, > > Changes since 20160428: > on i386: fs/built-in.o: In function `scrub_raid56_parity': scrub.c:(.text+0x2d06fb): undefined reference to `__udivdi3' -- ~Randy

Re: linux-next: Tree for Apr 29 (btrfs)

On 04/29/16 00:13, Stephen Rothwell wrote: > Hi all, > > Changes since 20160428: > on i386: fs/built-in.o: In function `scrub_raid56_parity': scrub.c:(.text+0x2d06fb): undefined reference to `__udivdi3' -- ~Randy

Re: [PATCH v3 1/7] ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data

* Peter Ujfalusi [160429 03:55]: > The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the > sidetone only receives the ICLK from the main McBSP module. > Since the McBSP and sidetone is using the very same clock from PRCM level > the sidetone must not have

Re: [PATCH v3 1/7] ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data

* Peter Ujfalusi [160429 03:55]: > The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the > sidetone only receives the ICLK from the main McBSP module. > Since the McBSP and sidetone is using the very same clock from PRCM level > the sidetone must not have the prcm section to

Re: [PATCH] mm/zsmalloc: don't fail if can't create debugfs info

On Fri, Apr 29, 2016 at 10:50:13AM -0400, Dan Streetman wrote: > On Fri, Apr 29, 2016 at 1:37 AM, Minchan Kim wrote: > > On Fri, Apr 29, 2016 at 09:38:24AM +0900, Sergey Senozhatsky wrote: > >> On (04/28/16 15:07), Andrew Morton wrote: > >> > Needed a bit of tweaking due to >

Re: [PATCH] mm/zsmalloc: don't fail if can't create debugfs info

On Fri, Apr 29, 2016 at 10:50:13AM -0400, Dan Streetman wrote: > On Fri, Apr 29, 2016 at 1:37 AM, Minchan Kim wrote: > > On Fri, Apr 29, 2016 at 09:38:24AM +0900, Sergey Senozhatsky wrote: > >> On (04/28/16 15:07), Andrew Morton wrote: > >> > Needed a bit of tweaking due to > >> >

Re: Question about request queues in I/O scheduling

Max Kanushin writes: > Hello, > > I was searching for a way to find out the length of a request_queue > (that is defined as a structure in > linux/include/linux/blkdev.h). However I am new to the kernel > development and can't figure out where is the actual list of requests >

Re: Question about request queues in I/O scheduling

Max Kanushin writes: > Hello, > > I was searching for a way to find out the length of a request_queue > (that is defined as a structure in > linux/include/linux/blkdev.h). However I am new to the kernel > development and can't figure out where is the actual list of requests > to be processed by

Re: [PATCH] gpio: tegra: Implement gpio_get_direction callback

On 29/04/16 13:31, Laxman Dewangan wrote: > Implement gpio_get_direction() callback for Tegra GPIO. > The direction is only valid if the pin is configured as > GPIO. If pin is not configured in GPIO mode then this > function return error. > > This makes debugfs and initial reading of the state

Re: [PATCH] gpio: tegra: Implement gpio_get_direction callback

On 29/04/16 13:31, Laxman Dewangan wrote: > Implement gpio_get_direction() callback for Tegra GPIO. > The direction is only valid if the pin is configured as > GPIO. If pin is not configured in GPIO mode then this > function return error. > > This makes debugfs and initial reading of the state

Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

On 28.04.2016 15:21, Felipe Balbi wrote: Hi, dmesg from PC host side (after adding your change without my patch): [17907.984647] usb 6-2: new SuperSpeed USB device number 54 using xhci_hcd [17908.012036] usb 6-2: No SuperSpeed endpoint companion for config 1 interface 1 altsetting 0 ep 2:

Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

On 28.04.2016 15:21, Felipe Balbi wrote: Hi, dmesg from PC host side (after adding your change without my patch): [17907.984647] usb 6-2: new SuperSpeed USB device number 54 using xhci_hcd [17908.012036] usb 6-2: No SuperSpeed endpoint companion for config 1 interface 1 altsetting 0 ep 2:

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote: > > > Currently autoconf spends 25ms (on my laptop) testing if the UART > > > exported to it by KVM

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote: > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote: > > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote: > > > Currently autoconf spends 25ms (on my laptop) testing if the UART > > > exported to it by KVM

Re: [RFC PATCH 0/8] perf tools: Update strbuf to remove xrealloc

On Fri, 29 Apr 2016 11:54:54 -0300 Arnaldo Carvalho de Melo wrote: > Em Fri, Apr 29, 2016 at 11:46:32PM +0900, Masami Hiramatsu escreveu: > > Hi Arnaldo, > > > > This patch series does refactoring strbuf and xrealloc related code > > to remove xrealloc since it can call die()

Re: [RFC PATCH 0/8] perf tools: Update strbuf to remove xrealloc

On Fri, 29 Apr 2016 11:54:54 -0300 Arnaldo Carvalho de Melo wrote: > Em Fri, Apr 29, 2016 at 11:46:32PM +0900, Masami Hiramatsu escreveu: > > Hi Arnaldo, > > > > This patch series does refactoring strbuf and xrealloc related code > > to remove xrealloc since it can call die() to exit

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:41:14AM +0100, Richard W.M. Jones wrote: > On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote: > > 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones : > > > [This is an opinionated patch, mainly for discussion.] > > > > > > I'm trying to

Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.

On Fri, Apr 29, 2016 at 08:41:14AM +0100, Richard W.M. Jones wrote: > On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote: > > 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones : > > > [This is an opinionated patch, mainly for discussion.] > > > > > > I'm trying to reduce the time taken

Re: [PATCH] Fix issue with dmesg.py and python 3.X

Hi Dom, On 08/04/16 04:33, Dom Cote wrote: > Hi Kieran, > > Thanks for the feedback. > > I am going to need to build a version of gdb with python 2.7 to see what > the differences are, and try to abstract them in the best possible way. > > Then I will send a new patch and incorporate what you

Re: [PATCH] Fix issue with dmesg.py and python 3.X

Hi Dom, On 08/04/16 04:33, Dom Cote wrote: > Hi Kieran, > > Thanks for the feedback. > > I am going to need to build a version of gdb with python 2.7 to see what > the differences are, and try to abstract them in the best possible way. > > Then I will send a new patch and incorporate what you

Re: [PATCH perf/core v2 0/8] perf tools: Update strbuf to remove xrealloc

Em Sat, Apr 30, 2016 at 12:09:41AM +0900, Masami Hiramatsu escreveu: > Hi Arnaldo, > > Here is the 2nd version of the strbuf update, and just rebased on > the latest perf/core :) In order to avoid confusion, I've added > v2 on tag. > > This patch series does refactoring strbuf and xrealloc

Re: [PATCH perf/core v2 0/8] perf tools: Update strbuf to remove xrealloc

Em Sat, Apr 30, 2016 at 12:09:41AM +0900, Masami Hiramatsu escreveu: > Hi Arnaldo, > > Here is the 2nd version of the strbuf update, and just rebased on > the latest perf/core :) In order to avoid confusion, I've added > v2 on tag. > > This patch series does refactoring strbuf and xrealloc

Re: [PATCH 3.16 106/217] sd: disable discard_zeroes_data for UNMAP

Martin, On Fri, Apr 29, 2016 at 9:16 AM, Martin K. Petersen wrote: >> "Rafael" == Rafael David Tinoco writes: > > Rafael, > > Rafael> And this happened because the storage in question didn't set > Rafael> properly "max_ws_blocks" (it

Re: [PATCH 3.16 106/217] sd: disable discard_zeroes_data for UNMAP

Martin, On Fri, Apr 29, 2016 at 9:16 AM, Martin K. Petersen wrote: >> "Rafael" == Rafael David Tinoco writes: > > Rafael, > > Rafael> And this happened because the storage in question didn't set > Rafael> properly "max_ws_blocks" (it was 0) from VPD 0xb0 (max_ws_blocks > Rafael> is

Re: [PATCH v4 04/13] USB: ch341: fix USB buffer allocations

On 2016-04-29 14:52, Johan Hovold wrote: @@ -168,9 +168,9 @@ static int ch341_set_handshake(struct usb_device *dev, u8 control) static int ch341_get_status(struct usb_device *dev, struct ch341_private *priv) { - char *buffer; + unsigned char *buffer; int r; -

Re: [PATCH v4 04/13] USB: ch341: fix USB buffer allocations

On 2016-04-29 14:52, Johan Hovold wrote: @@ -168,9 +168,9 @@ static int ch341_set_handshake(struct usb_device *dev, u8 control) static int ch341_get_status(struct usb_device *dev, struct ch341_private *priv) { - char *buffer; + unsigned char *buffer; int r; -

Re: [RFC PATCH v1 13/18] x86: DMA support for memory encryption

On 04/29/2016 02:17 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 26, 2016 at 05:58:12PM -0500, Tom Lendacky wrote: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA

Re: [BUG] vfio device assignment regression with THP ref counting redesign

On Fri, 29 Apr 2016 10:06:11 +0300 "Kirill A. Shutemov" wrote: > On Thu, Apr 28, 2016 at 08:45:42PM -0600, Alex Williamson wrote: > > On Fri, 29 Apr 2016 03:51:06 +0300 > > "Kirill A. Shutemov" wrote: > > > > > On Fri, Apr 29, 2016 at 01:21:27AM

Re: [RFC PATCH v1 13/18] x86: DMA support for memory encryption

On 04/29/2016 02:17 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 26, 2016 at 05:58:12PM -0500, Tom Lendacky wrote: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA

Re: [BUG] vfio device assignment regression with THP ref counting redesign

On Fri, 29 Apr 2016 10:06:11 +0300 "Kirill A. Shutemov" wrote: > On Thu, Apr 28, 2016 at 08:45:42PM -0600, Alex Williamson wrote: > > On Fri, 29 Apr 2016 03:51:06 +0300 > > "Kirill A. Shutemov" wrote: > > > > > On Fri, Apr 29, 2016 at 01:21:27AM +0200, Andrea Arcangeli wrote: > > > > Hello

Re: [PART1 RFC v4 08/11] svm: Add VMEXIT handlers for AVIC

2016-04-28 17:08-0500, Suravee Suthikulanit: > On 4/12/2016 11:22 AM, Radim Krčmář wrote: >> 2016-04-07 03:20-0500, Suravee Suthikulpanit: >> > From: Suravee Suthikulpanit >> > >> > This patch introduces VMEXIT handlers, avic_incomplete_ipi_interception() >> > and

Re: [PART1 RFC v4 08/11] svm: Add VMEXIT handlers for AVIC

2016-04-28 17:08-0500, Suravee Suthikulanit: > On 4/12/2016 11:22 AM, Radim Krčmář wrote: >> 2016-04-07 03:20-0500, Suravee Suthikulpanit: >> > From: Suravee Suthikulpanit >> > >> > This patch introduces VMEXIT handlers, avic_incomplete_ipi_interception() >> > and

Re: [RFC PATCH 0/8] perf tools: Update strbuf to remove xrealloc

Em Fri, Apr 29, 2016 at 11:46:32PM +0900, Masami Hiramatsu escreveu: > Hi Arnaldo, > > This patch series does refactoring strbuf and xrealloc related code > to remove xrealloc since it can call die() to exit immediately when > it hits any error. Instead of that, it should return error code to >

Re: [RFC PATCH 0/8] perf tools: Update strbuf to remove xrealloc

Em Fri, Apr 29, 2016 at 11:46:32PM +0900, Masami Hiramatsu escreveu: > Hi Arnaldo, > > This patch series does refactoring strbuf and xrealloc related code > to remove xrealloc since it can call die() to exit immediately when > it hits any error. Instead of that, it should return error code to >

[PATCH perf/core v2 7/8] perf help: Do not use ALLOC_GROW in add_cmd_list

Replace ALLOC_GROW with normal realloc code in add_cmd_list() so that it can handle errors directly. Signed-off-by: Masami Hiramatsu --- tools/perf/util/help-unknown-cmd.c | 30 ++ 1 file changed, 22 insertions(+), 8 deletions(-) diff --git

[PATCH perf/core v2 7/8] perf help: Do not use ALLOC_GROW in add_cmd_list

Replace ALLOC_GROW with normal realloc code in add_cmd_list() so that it can handle errors directly. Signed-off-by: Masami Hiramatsu --- tools/perf/util/help-unknown-cmd.c | 30 ++ 1 file changed, 22 insertions(+), 8 deletions(-) diff --git

Re: [PATCH v4 01/13] USB: ch341: fix error handling on resume

On 2016-04-29 14:16, Johan Hovold wrote: On Fri, Apr 15, 2016 at 11:14:04PM +0200, Grigori Goronzy wrote: This may fail, do not assume it always works. Signed-off-by: Grigori Goronzy --- drivers/usb/serial/ch341.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

Re: [PATCH v4 01/13] USB: ch341: fix error handling on resume

On 2016-04-29 14:16, Johan Hovold wrote: On Fri, Apr 15, 2016 at 11:14:04PM +0200, Grigori Goronzy wrote: This may fail, do not assume it always works. Signed-off-by: Grigori Goronzy --- drivers/usb/serial/ch341.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH perf/core v2 6/8] perf pmu: Make pmu_formats_string to check return value of strbuf

Make pmu_formats_string() to check return value of strbuf APIs so that it can detect errors in it. Signed-off-by: Masami Hiramatsu --- tools/perf/util/pmu.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/perf/util/pmu.c

[PATCH perf/core v2 4/8] perf: Make alias handler to check return value of strbuf

Make alias handler and sq_quote_argv to check the return value of strbuf APIs. In sq_quote_argv() calls die(), but this fix handles strbuf failure as a special case and returns to caller, since the caller - handle_alias() also has to check the return value of other strbuf APIs and those checks can

[PATCH perf/core v2 8/8] perf tools: Remove xrealloc and ALLOC_GROW

Remove unused xrealloc() and ALLOC_GROW() from libperf. Signed-off-by: Masami Hiramatsu --- tools/perf/util/Build |1 - tools/perf/util/cache.h | 19 --- tools/perf/util/util.h|6 -- tools/perf/util/wrapper.c | 29

[PATCH perf/core v2 4/8] perf: Make alias handler to check return value of strbuf

Make alias handler and sq_quote_argv to check the return value of strbuf APIs. In sq_quote_argv() calls die(), but this fix handles strbuf failure as a special case and returns to caller, since the caller - handle_alias() also has to check the return value of other strbuf APIs and those checks can

<    2   3   4   5   6   7   8   9   10   11   >