Re: [PATCH v1] staging: ccree: fix all whitespace errors

Hi Dhiru, Thank you for patch. On Sat, May 13, 2017 at 5:52 PM, Dhiru Kholia wrote: > These whitespace issues were found by the checkpatch.pl script. This > patch helps in making the staging tree a bit cleaner. > > Signed-off-by: Dhiru Kholia >

Re: [PATCH v1] staging: ccree: fix all whitespace errors

Hi Dhiru, Thank you for patch. On Sat, May 13, 2017 at 5:52 PM, Dhiru Kholia wrote: > These whitespace issues were found by the checkpatch.pl script. This > patch helps in making the staging tree a bit cleaner. > > Signed-off-by: Dhiru Kholia > --- > drivers/staging/ccree/TODO

Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

Hi Arnd, Sorry to bother you again. On Thu, 2017-05-11 at 20:11 +0800, Ryder Lee wrote: > > interrupt-map-mask = <0xff800 0 0 0>; > > interrupt-map = <0x 0 0 0 GIC_SPI 193 IRQ_TYPE_NONE>, > > <0x0800 0 0 0 GIC_SPI 194 IRQ_TYPE_NONE>, > > <0x1000 0 0 0 GIC_SPI

Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

Hi Arnd, Sorry to bother you again. On Thu, 2017-05-11 at 20:11 +0800, Ryder Lee wrote: > > interrupt-map-mask = <0xff800 0 0 0>; > > interrupt-map = <0x 0 0 0 GIC_SPI 193 IRQ_TYPE_NONE>, > > <0x0800 0 0 0 GIC_SPI 194 IRQ_TYPE_NONE>, > > <0x1000 0 0 0 GIC_SPI

Re: [PATCH v2 02/18] arm64: dts: amlogic: Sort Makefile

Le 13/05/2017 à 16:33, Andreas Färber a écrit : Sort the .dtb files alphabetically to make clear where to add new ones. Signed-off-by: Andreas Färber --- v1 -> v2: * Rebased (new boards added) * Extended commit message arch/arm64/boot/dts/amlogic/Makefile | 6

Re: [PATCH v2 02/18] arm64: dts: amlogic: Sort Makefile

Le 13/05/2017 à 16:33, Andreas Färber a écrit : Sort the .dtb files alphabetically to make clear where to add new ones. Signed-off-by: Andreas Färber --- v1 -> v2: * Rebased (new boards added) * Extended commit message arch/arm64/boot/dts/amlogic/Makefile | 6 +++--- 1 file

Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

On Thu 11 May 03:33 PDT 2017, Varadarajan Narayanan wrote: > > > On 5/11/2017 4:13 AM, Bjorn Andersson wrote: > > On Thu 04 May 04:53 PDT 2017, Varadarajan Narayanan wrote: > > [..] > > > +enum ipq8074_functions { > > > > Please keep these sorted alphabetically. > > Ok > > > > +

Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

On Thu 11 May 03:33 PDT 2017, Varadarajan Narayanan wrote: > > > On 5/11/2017 4:13 AM, Bjorn Andersson wrote: > > On Thu 04 May 04:53 PDT 2017, Varadarajan Narayanan wrote: > > [..] > > > +enum ipq8074_functions { > > > > Please keep these sorted alphabetically. > > Ok > > > > +

Re: [PATCH 1/1] remoteproc: fix elf_loader da_to_va translation and writing beyond segment

On Thu 11 May 09:12 PDT 2017, Henri Roosen wrote: > On 05/11/2017 02:05 AM, Bjorn Andersson wrote: > > On Wed 03 May 05:12 PDT 2017, Henri Roosen wrote: > > > > > Consider a system with 2 memory regions: > > > 0x1fff8000 - 0x1fff: iram > > > > So I presume there's a hole here. > > > > >

Re: [PATCH 1/1] remoteproc: fix elf_loader da_to_va translation and writing beyond segment

On Thu 11 May 09:12 PDT 2017, Henri Roosen wrote: > On 05/11/2017 02:05 AM, Bjorn Andersson wrote: > > On Wed 03 May 05:12 PDT 2017, Henri Roosen wrote: > > > > > Consider a system with 2 memory regions: > > > 0x1fff8000 - 0x1fff: iram > > > > So I presume there's a hole here. > > > > >

Re: [PATCH V2] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

On 05/13/2017 03:05 AM, Andrew Morton wrote: > On Wed, 26 Apr 2017 09:27:31 +0530 Anshuman Khandual > wrote: > >> Though migrating gigantic HugeTLB pages does not sound much like real >> world use case, they can be affected by memory errors. Hence migration >> at

Re: [PATCH V2] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

On 05/13/2017 03:05 AM, Andrew Morton wrote: > On Wed, 26 Apr 2017 09:27:31 +0530 Anshuman Khandual > wrote: > >> Though migrating gigantic HugeTLB pages does not sound much like real >> world use case, they can be affected by memory errors. Hence migration >> at the PGD level HugeTLB pages

[GIT PULL] watchdog updates for v4.12

Hi Linus, As requested by Wim: Please pull watchdog updates for Linux v4.12 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git watchdog-for-linus-v4.12 Note: I had to drop one of the patches affecting drivers/watchdog/iTCO_wdt.c because it and some

[GIT PULL] watchdog updates for v4.12

Hi Linus, As requested by Wim: Please pull watchdog updates for Linux v4.12 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git watchdog-for-linus-v4.12 Note: I had to drop one of the patches affecting drivers/watchdog/iTCO_wdt.c because it and some

Re: [PATCH 1/2] ARM: dts: qcom-apq8064: Collapse usb support into one node

On Fri 12 May 14:18 PDT 2017, John Stultz wrote: > From: Stephen Boyd > > We currently have three device nodes for the same USB hardware > block, as evident by the reuse of the same reg address multiple > times. Now that the chipidea driver fully supports OTG with the >

Re: [PATCH 1/2] ARM: dts: qcom-apq8064: Collapse usb support into one node

On Fri 12 May 14:18 PDT 2017, John Stultz wrote: > From: Stephen Boyd > > We currently have three device nodes for the same USB hardware > block, as evident by the reuse of the same reg address multiple > times. Now that the chipidea driver fully supports OTG with the > MSM wrapper we can

Re: [PATCH] mm/madvise: Dont poison entire HugeTLB page for single page errors

On 05/12/2017 01:40 PM, Naoya Horiguchi wrote: > On Thu, Apr 20, 2017 at 04:36:27PM +0530, Anshuman Khandual wrote: >> Currently soft_offline_page() migrates the entire HugeTLB page, then >> dequeues it from the active list by making it a dangling HugeTLB page >> which ofcourse can not be used

Re: [PATCH] mm/madvise: Dont poison entire HugeTLB page for single page errors

On 05/12/2017 01:40 PM, Naoya Horiguchi wrote: > On Thu, Apr 20, 2017 at 04:36:27PM +0530, Anshuman Khandual wrote: >> Currently soft_offline_page() migrates the entire HugeTLB page, then >> dequeues it from the active list by making it a dangling HugeTLB page >> which ofcourse can not be used

[PATCH v3 1/5] dt-bindings: Add vendor prefix for Zidoo

Zidoo is a Chinese manufacturer of TV boxes. Acked-by: Arnd Bergmann Acked-by: Rob Herring Acked-by: Roc He Signed-off-by: Andreas Färber --- v2 -> v3: unchanged v1 -> v2: * Changed subject * Extended commit message

[PATCH v3 1/5] dt-bindings: Add vendor prefix for Zidoo

Zidoo is a Chinese manufacturer of TV boxes. Acked-by: Arnd Bergmann Acked-by: Rob Herring Acked-by: Roc He Signed-off-by: Andreas Färber --- v2 -> v3: unchanged v1 -> v2: * Changed subject * Extended commit message Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file

[PATCH v3 2/5] dt-bindings: arm: Add Realtek RTD1295 bindings

The Zidoo X9S and a few other recent TV boxes feature the Realtek RTD1295, a quad-core ARM Cortex-A53 SoC. Acked-by: Arnd Bergmann Acked-by: Roc He Acked-by: Rob Herring Signed-off-by: Andreas Färber --- v2 -> v3: unchanged

[PATCH v3 4/5] ARM64: dts: Add Realtek RTD1295 and Zidoo X9S

Add initial device trees for the RTD1295 SoC and the Zidoo X9S TV box. The CPUs lack the enable-method property because the vendor device tree uses a custom "rtk-spin-table" method and "psci" did not appear to work. The UARTs lack the interrupts properties because the vendor device tree connects

[PATCH v3 2/5] dt-bindings: arm: Add Realtek RTD1295 bindings

The Zidoo X9S and a few other recent TV boxes feature the Realtek RTD1295, a quad-core ARM Cortex-A53 SoC. Acked-by: Arnd Bergmann Acked-by: Roc He Acked-by: Rob Herring Signed-off-by: Andreas Färber --- v2 -> v3: unchanged v1 -> v2: * Changed subject * Extended commit message *

[PATCH v3 4/5] ARM64: dts: Add Realtek RTD1295 and Zidoo X9S

Add initial device trees for the RTD1295 SoC and the Zidoo X9S TV box. The CPUs lack the enable-method property because the vendor device tree uses a custom "rtk-spin-table" method and "psci" did not appear to work. The UARTs lack the interrupts properties because the vendor device tree connects

[PATCH v3 5/5] MAINTAINERS: Add Realtek section

Add myself as maintainer. Signed-off-by: Andreas Färber --- v2 -> v3: * Changed status to Maintained v2: new MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5ae4f7975b19..92c65bbc4ef3 100644 --- a/MAINTAINERS +++

[PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement

Hello, This mini-series adds initial support for the Realtek RTD1295 SoC and the Zidoo X9S TV box. v3 changes #address-cells, #size-cells and ranges. With these patches CPU0 can be booted with earlycon. PSCI doesn't work despite present in the vendor device tree; as enable-method it instead

[PATCH v3 3/5] ARM64: Prepare Realtek RTD1295

Add a Kconfig option ARCH_REALTEK. Acked-by: Arnd Bergmann Signed-off-by: Andreas Färber --- v1 -> v2 -> v3: unchanged arch/arm64/Kconfig.platforms | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/Kconfig.platforms

[PATCH v3 5/5] MAINTAINERS: Add Realtek section

Add myself as maintainer. Signed-off-by: Andreas Färber --- v2 -> v3: * Changed status to Maintained v2: new MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5ae4f7975b19..92c65bbc4ef3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@

[PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement

Hello, This mini-series adds initial support for the Realtek RTD1295 SoC and the Zidoo X9S TV box. v3 changes #address-cells, #size-cells and ranges. With these patches CPU0 can be booted with earlycon. PSCI doesn't work despite present in the vendor device tree; as enable-method it instead

[PATCH v3 3/5] ARM64: Prepare Realtek RTD1295

Add a Kconfig option ARCH_REALTEK. Acked-by: Arnd Bergmann Signed-off-by: Andreas Färber --- v1 -> v2 -> v3: unchanged arch/arm64/Kconfig.platforms | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index

Re: [PATCH v2] Coccinelle: api: Add offset_in_page.cocci

On Fri, 5 May 2017, Vaishali Thakkar wrote: > Use of offset_in_page is preferable instead of open coding. > This patch adds coccinelle script for suggesting the use of > macro offset_in_page. > > Signed-off-by: Vaishali Thakkar > --- > Changes since v1: > -

Re: [PATCH v2] Coccinelle: api: Add offset_in_page.cocci

On Fri, 5 May 2017, Vaishali Thakkar wrote: > Use of offset_in_page is preferable instead of open coding. > This patch adds coccinelle script for suggesting the use of > macro offset_in_page. > > Signed-off-by: Vaishali Thakkar > --- > Changes since v1: > - Add parenthesis around rule

[PATCH] dax: fix false CONFIG_BLOCK dependency

In the BLOCK=n case the dax core does not need to / must not emit the block-device-dax helpers. Otherwise it leads to compile errors. Cc: Arnd Bergmann Reported-by: Fabian Frederick Fixes: ef51042472f5 ("block, dax: move 'select DAX' from BLOCK to FS_DAX")

[PATCH] dax, xfs, ext4: compile out iomap-dax paths in the FS_DAX=n case

Tetsuo reports: fs/built-in.o: In function `xfs_file_iomap_end': xfs_iomap.c:(.text+0xe0ef9): undefined reference to `put_dax' fs/built-in.o: In function `xfs_file_iomap_begin': xfs_iomap.c:(.text+0xe1a7f): undefined reference to `dax_get_by_host' make: *** [vmlinux] Error 1 $ grep

[PATCH] dax: fix false CONFIG_BLOCK dependency

In the BLOCK=n case the dax core does not need to / must not emit the block-device-dax helpers. Otherwise it leads to compile errors. Cc: Arnd Bergmann Reported-by: Fabian Frederick Fixes: ef51042472f5 ("block, dax: move 'select DAX' from BLOCK to FS_DAX") Signed-off-by: Dan Williams ---

[PATCH] dax, xfs, ext4: compile out iomap-dax paths in the FS_DAX=n case

Tetsuo reports: fs/built-in.o: In function `xfs_file_iomap_end': xfs_iomap.c:(.text+0xe0ef9): undefined reference to `put_dax' fs/built-in.o: In function `xfs_file_iomap_begin': xfs_iomap.c:(.text+0xe1a7f): undefined reference to `dax_get_by_host' make: *** [vmlinux] Error 1 $ grep

Re: Makefile:541: arch/avr32/Makefile: No such file or directory

Hi robby, Too much automation maybe?? See the commit message: avr32: remove support for AVR32 and then the error message... On 05/13/17 17:05, kbuild test robot wrote: > Hi Hans-Christian, > > FYI, the error/warning still remains. > > tree:

Re: Makefile:541: arch/avr32/Makefile: No such file or directory

Hi robby, Too much automation maybe?? See the commit message: avr32: remove support for AVR32 and then the error message... On 05/13/17 17:05, kbuild test robot wrote: > Hi Hans-Christian, > > FYI, the error/warning still remains. > > tree:

Makefile:541: arch/avr32/Makefile: No such file or directory

Hi Hans-Christian, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2ea659a9ef488125eb46da6eb571de5eae5c43f6 commit: 26202873bb51fafdaa51be3e8de7aab9beb49f70 avr32: remove support for AVR32 architecture date: 13

Makefile:541: arch/avr32/Makefile: No such file or directory

Hi Hans-Christian, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2ea659a9ef488125eb46da6eb571de5eae5c43f6 commit: 26202873bb51fafdaa51be3e8de7aab9beb49f70 avr32: remove support for AVR32 architecture date: 13

[PATCH 0/3] PM / wakeup / ACPI: Suspend-to-idle wakeup fixes and optimization

Hi, Two recent commits related to suspend-to-idle introduced a couple of issues that need to be fixed. In addition to that, there turns out to be a way to avoid carrying out the "noirq" phase of device resume in order to check if wakeup triggered by an ACPI SCI is a real one, which patch [3/3]

[PATCH 0/3] PM / wakeup / ACPI: Suspend-to-idle wakeup fixes and optimization

Hi, Two recent commits related to suspend-to-idle introduced a couple of issues that need to be fixed. In addition to that, there turns out to be a way to avoid carrying out the "noirq" phase of device resume in order to check if wakeup triggered by an ACPI SCI is a real one, which patch [3/3]

[PATCH 3/3] ACPI / sleep: Simplify suspend-to-idle event processing loop

From: Rafael J. Wysocki Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) modified the core suspend-to-idle code to filter out spurious SCI interrupts received while suspended, but it implemented that by resuming the system partially

[PATCH 3/3] ACPI / sleep: Simplify suspend-to-idle event processing loop

From: Rafael J. Wysocki Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) modified the core suspend-to-idle code to filter out spurious SCI interrupts received while suspended, but it implemented that by resuming the system partially every time an SCI triggers

[PATCH 1/3] PM / wakeup: Fix up wakeup_source_report_event()

From: Rafael J. Wysocki Commit 8a537ece3d94 (PM / wakeup: Integrate mechanism to abort transitions in progress) modified wakeup_source_report_event() and wakeup_source_activate() to make it possible to call pm_system_wakeup() from the latter if so indicated by the

[PATCH 2/3] RTC: rtc-cmos: Fix wakeup from suspend-to-idle

From: Rafael J. Wysocki Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) modified the core suspend-to-idle code to filter out spurious SCI interrupts received while suspended, which requires ACPI event source handlers to report

[PATCH 1/3] PM / wakeup: Fix up wakeup_source_report_event()

From: Rafael J. Wysocki Commit 8a537ece3d94 (PM / wakeup: Integrate mechanism to abort transitions in progress) modified wakeup_source_report_event() and wakeup_source_activate() to make it possible to call pm_system_wakeup() from the latter if so indicated by the caller of the former (via a new

[PATCH 2/3] RTC: rtc-cmos: Fix wakeup from suspend-to-idle

From: Rafael J. Wysocki Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) modified the core suspend-to-idle code to filter out spurious SCI interrupts received while suspended, which requires ACPI event source handlers to report wakeup events in a way that will

xfs_iomap.c:undefined reference to `put_dax'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: cd636458904a04de2349c728323c5d2af1203bdf commit: ef51042472f55b325fd7f2b26a2e29fd89757234 block, dax: move "select DAX" from BLOCK to FS_DAX date: 5 days ago config: ia64-bigsur_defconfig (attached as

xfs_iomap.c:undefined reference to `put_dax'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: cd636458904a04de2349c728323c5d2af1203bdf commit: ef51042472f55b325fd7f2b26a2e29fd89757234 block, dax: move "select DAX" from BLOCK to FS_DAX date: 5 days ago config: ia64-bigsur_defconfig (attached as

Re: [PATCH linux-next] device-dax: fix BLOCK dependency

On Sat, May 13, 2017 at 11:59 AM, Fabian Frederick wrote: > commit ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX") > uses get_start_sect() which requires CONFIG_BLOCK > > make allnoconfig + dax gives the following: > > drivers/dax/super.c: In function

Re: [PATCH linux-next] device-dax: fix BLOCK dependency

On Sat, May 13, 2017 at 11:59 AM, Fabian Frederick wrote: > commit ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX") > uses get_start_sect() which requires CONFIG_BLOCK > > make allnoconfig + dax gives the following: > > drivers/dax/super.c: In function 'bdev_dax_pgoff': >

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > From: Dave Young > > Before invoking the arch specific handler, efi_mem_reserve() reserves > the given memory region through memblock. > > efi_bgrt_init() will call efi_mem_reserve() after mm_init(), at which > time memblock

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > From: Dave Young > > Before invoking the arch specific handler, efi_mem_reserve() reserves > the given memory region through memblock. > > efi_bgrt_init() will call efi_mem_reserve() after mm_init(), at which > time memblock is dead and should

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 5/13/17 3:15 PM, Valentin Vidic wrote: > Try booting without 'hpet=force,verbose clocksource=hpet' and it should > select xen by default: Nope. Well, not quite ... With both 'hpet=force,verbose clocksource=hpet' removed, I end up with cat

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 5/13/17 3:15 PM, Valentin Vidic wrote: > Try booting without 'hpet=force,verbose clocksource=hpet' and it should > select xen by default: Nope. Well, not quite ... With both 'hpet=force,verbose clocksource=hpet' removed, I end up with cat

[PATCH 2/9] staging: sm750fb: unifying macro definitions

This patch adds tabs into macro definitions so all rhs are on same column. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_display.h | 74 drivers/staging/sm750fb/ddk750_hwi2c.c | 4 +- drivers/staging/sm750fb/sm750.h

[PATCH 2/9] staging: sm750fb: unifying macro definitions

This patch adds tabs into macro definitions so all rhs are on same column. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_display.h | 74 drivers/staging/sm750fb/ddk750_hwi2c.c | 4 +- drivers/staging/sm750fb/sm750.h | 6 +-- 3 files

[PATCH 3/9] staging: sm750fb: reordering of macro definitions

This patch reorder definition of macros so all macros are in same order. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_display.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/sm750fb/ddk750_display.h

[PATCH 1/9] staging: sm750fb: fix length of lines

This patch breaks lines that are longer than 80 characters and joins together those, that are too short and can be placed at one. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_chip.c | 7 +++-- drivers/staging/sm750fb/ddk750_dvi.c| 35

[PATCH 6/9] staging: sm750fb: Remove typedef from "typedef enum _clock_type_t"

This patch removes typedefs from enum and renames it from "typedef enum _clock_type_t" to "enum clock_type" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_chip.h | 8 drivers/staging/sm750fb/ddk750_mode.c | 2 +-

[PATCH 3/9] staging: sm750fb: reordering of macro definitions

This patch reorder definition of macros so all macros are in same order. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_display.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/sm750fb/ddk750_display.h

[PATCH 1/9] staging: sm750fb: fix length of lines

This patch breaks lines that are longer than 80 characters and joins together those, that are too short and can be placed at one. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_chip.c | 7 +++-- drivers/staging/sm750fb/ddk750_dvi.c| 35 +--

[PATCH 6/9] staging: sm750fb: Remove typedef from "typedef enum _clock_type_t"

This patch removes typedefs from enum and renames it from "typedef enum _clock_type_t" to "enum clock_type" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_chip.h | 8 drivers/staging/sm750fb/ddk750_mode.c | 2 +-

[PATCH 0/9] staging: sm750fb: cleaning code

Folowing patches are cleaning some warnings and checkups from checkpatch.pl Matej Dujava (9): staging: sm750fb: fix length of lines staging: sm750fb: unifying macro definitions staging: sm750fb: reordering of macro definitions staging: sm750fb: removing unnecessary binary operations

[PATCH 4/9] staging: sm750fb: removing unnecessary binary operations

This patch remove unnecessary operation (eg. ``X | (0x0 << Y)`` to ``X``). Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_display.h | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git

[PATCH 0/9] staging: sm750fb: cleaning code

Folowing patches are cleaning some warnings and checkups from checkpatch.pl Matej Dujava (9): staging: sm750fb: fix length of lines staging: sm750fb: unifying macro definitions staging: sm750fb: reordering of macro definitions staging: sm750fb: removing unnecessary binary operations

[PATCH 4/9] staging: sm750fb: removing unnecessary binary operations

This patch remove unnecessary operation (eg. ``X | (0x0 << Y)`` to ``X``). Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_display.h | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/staging/sm750fb/ddk750_display.h

[PATCH 7/9] staging: sm750fb: Remove typedef from "typedef enum _disp_output_t"

This patch removes typedefs from enum and renames it from "typedef enum _disp_output_t" to "enum disp_output" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_display.c | 2 +- drivers/staging/sm750fb/ddk750_display.h | 8

[PATCH 9/9] staging: sm750fb: Remove typedef from "typedef enum _sii164_hot_plug_mode_t"

This patch removes typedefs from enum and renames it from "typedef enum _sii164_hot_plug_mode_t" to "enum sii164_hot_plug_mode" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_sii164.c | 2 +-

[PATCH 7/9] staging: sm750fb: Remove typedef from "typedef enum _disp_output_t"

This patch removes typedefs from enum and renames it from "typedef enum _disp_output_t" to "enum disp_output" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_display.c | 2 +- drivers/staging/sm750fb/ddk750_display.h | 8

[PATCH 9/9] staging: sm750fb: Remove typedef from "typedef enum _sii164_hot_plug_mode_t"

This patch removes typedefs from enum and renames it from "typedef enum _sii164_hot_plug_mode_t" to "enum sii164_hot_plug_mode" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_sii164.c | 2 +- drivers/staging/sm750fb/ddk750_sii164.h | 4 ++-- 2

[PATCH 8/9] staging: sm750fb: Remove typedef from "typedef enum _DPMS_t"

This patch removes typedefs from enum and renames it from "typedef enum _DPMS_t" to "enum DPMS" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_power.c | 2 +- drivers/staging/sm750fb/ddk750_power.h | 7 +++ 2 files

[PATCH 8/9] staging: sm750fb: Remove typedef from "typedef enum _DPMS_t"

This patch removes typedefs from enum and renames it from "typedef enum _DPMS_t" to "enum DPMS" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_power.c | 2 +- drivers/staging/sm750fb/ddk750_power.h | 7 +++ 2 files changed, 4 insertions(+), 5

[PATCH 5/9] staging: sm750fb: Remove typedef from "typedef enum _logical_chip_type_t"

This patch removes typedefs from enum and renames it from "typedef enum _logical_chip_type_t" to "enum logical_chip_type" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_chip.c | 4 ++-- drivers/staging/sm750fb/ddk750_chip.h |

[PATCH 5/9] staging: sm750fb: Remove typedef from "typedef enum _logical_chip_type_t"

This patch removes typedefs from enum and renames it from "typedef enum _logical_chip_type_t" to "enum logical_chip_type" as per kernel coding standards. Signed-off-by: Matej Dujava --- drivers/staging/sm750fb/ddk750_chip.c | 4 ++-- drivers/staging/sm750fb/ddk750_chip.h | 8 2 files

[PATCH] drm/sti:fix spelling mistake: "compoment" -> "component"

From: Colin Ian King Trivial fix to spelling mistake in DRM_ERROR message Signed-off-by: Colin Ian King --- drivers/gpu/drm/sti/sti_compositor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] drm/sti:fix spelling mistake: "compoment" -> "component"

From: Colin Ian King Trivial fix to spelling mistake in DRM_ERROR message Signed-off-by: Colin Ian King --- drivers/gpu/drm/sti/sti_compositor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_compositor.c b/drivers/gpu/drm/sti/sti_compositor.c

[PATCH] rtlwifi: rtl8723ae:fix spelling mistake: "Coexistance" -> "Coexistence"

From: Colin Ian King Trivial fix to spelling mistake in RT_TRACE text Signed-off-by: Colin Ian King --- drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] rtlwifi: rtl8723ae:fix spelling mistake: "Coexistance" -> "Coexistence"

From: Colin Ian King Trivial fix to spelling mistake in RT_TRACE text Signed-off-by: Colin Ian King --- drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c

[PATCH] staging: rtl8188eu, rtl8723bs: fix spelling mistake "Cancle" -> "Cancel"

From: Colin Ian King Trivial fix to spelling mistakes in a comments and RT_TRACE text. Signed-off-by: Colin Ian King --- drivers/staging/rtl8188eu/core/rtw_mlme.c | 4 ++-- drivers/staging/rtl8723bs/core/rtw_mlme.c | 4 ++-- 2 files changed,

[PATCH] staging: rtl8188eu, rtl8723bs: fix spelling mistake "Cancle" -> "Cancel"

From: Colin Ian King Trivial fix to spelling mistakes in a comments and RT_TRACE text. Signed-off-by: Colin Ian King --- drivers/staging/rtl8188eu/core/rtw_mlme.c | 4 ++-- drivers/staging/rtl8723bs/core/rtw_mlme.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On Sat, May 13, 2017 at 02:58:54PM -0700, PGNet Dev wrote: > Does this perhaps imply that Xen correctly uses HPET > > (XEN) [VT-D] MSI HPET: :f0:0f.0 > (XEN) Platform timer is 14.318MHz HPET I think so, yes. > but that Dom0 does not > > current_clocksource >

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On Sat, May 13, 2017 at 02:58:54PM -0700, PGNet Dev wrote: > Does this perhaps imply that Xen correctly uses HPET > > (XEN) [VT-D] MSI HPET: :f0:0f.0 > (XEN) Platform timer is 14.318MHz HPET I think so, yes. > but that Dom0 does not > > current_clocksource >

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 5/13/17 2:32 PM, Valentin Vidic wrote: > On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote: >> xl dmesg | grep -i hpet | grep -vi command >> [1.365876] hpet_acpi_add: no address or irqs in _CRS >> [1.365876] hpet_acpi_add: no address or irqs in _CRS > > Ah, guess this is

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 5/13/17 2:32 PM, Valentin Vidic wrote: > On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote: >> xl dmesg | grep -i hpet | grep -vi command >> [1.365876] hpet_acpi_add: no address or irqs in _CRS >> [1.365876] hpet_acpi_add: no address or irqs in _CRS > > Ah, guess this is

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote: > xl dmesg | grep -i hpet | grep -vi command > [1.365876] hpet_acpi_add: no address or irqs in _CRS > [1.365876] hpet_acpi_add: no address or irqs in _CRS Ah, guess this is caused by console_to_ring boot option. Better check

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote: > xl dmesg | grep -i hpet | grep -vi command > [1.365876] hpet_acpi_add: no address or irqs in _CRS > [1.365876] hpet_acpi_add: no address or irqs in _CRS Ah, guess this is caused by console_to_ring boot option. Better check

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 01:52:29PM -0700, Linus Torvalds wrote: > I wouldn't change the existing "memdup_user()" interface itself, but > if there really are users that can validly pass in a maxbyte value, > why not add a new helper: > > void *memdup_user_limit(userptr, nmember, nsize, maxsize);

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 01:52:29PM -0700, Linus Torvalds wrote: > I wouldn't change the existing "memdup_user()" interface itself, but > if there really are users that can validly pass in a maxbyte value, > why not add a new helper: > > void *memdup_user_limit(userptr, nmember, nsize, maxsize);

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 5/13/17 1:16 PM, Andrew Cooper wrote: We don't have code like that in upstream Xen. No function with that name, or a string which looks like that error message. noted http://marc.info/?l=linux-kernel=149464267427111=2 indicates that you are using a SuSE hypervisor. yes, that's correct

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 5/13/17 1:16 PM, Andrew Cooper wrote: We don't have code like that in upstream Xen. No function with that name, or a string which looks like that error message. noted http://marc.info/?l=linux-kernel=149464267427111=2 indicates that you are using a SuSE hypervisor. yes, that's correct

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 5/13/17 1:28 PM, Valentin Vidic wrote: On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote: back to the error at hand ... xl dmesg | grep -i hpet [1.365876] hpet_acpi_add: no address or irqs in _CRS [1.365876] hpet_acpi_add: no address or irqs in _CRS again, only

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 5/13/17 1:28 PM, Valentin Vidic wrote: On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote: back to the error at hand ... xl dmesg | grep -i hpet [1.365876] hpet_acpi_add: no address or irqs in _CRS [1.365876] hpet_acpi_add: no address or irqs in _CRS again, only

Linux 4.12-rc1

So I'm doing this one day early, because I don't like last-minute pull requests during the merge window anyway, and tomorrow is mother's day, so I may end up being roped into various happenings. Besides, this has actually been a pretty large merge window, so despite there technically being time

Linux 4.12-rc1

So I'm doing this one day early, because I don't like last-minute pull requests during the merge window anyway, and tomorrow is mother's day, so I may end up being roped into various happenings. Besides, this has actually been a pretty large merge window, so despite there technically being time

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 1:37 PM, Al Viro wrote: > > That's a valid point and it might apply to memdup_user() callers out there. > Potential variants: > * add an explicit upper bound on the size and turn that into > memdup_user() (and check that all memdup_user()

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 1:37 PM, Al Viro wrote: > > That's a valid point and it might apply to memdup_user() callers out there. > Potential variants: > * add an explicit upper bound on the size and turn that into > memdup_user() (and check that all memdup_user() callers are bounded). >

[PATCH v2] usb: misc: legousbtower: Fix memory leak

get_version_reply is not freed if function returns with success. Fixes: 942a48730faf ("usb: misc: legousbtower: Fix buffers on stack") Reported-by: Heikki Krogerus Signed-off-by: Maksim Salau --- v2: Changed tags to match guidelines.

[PATCH v2] usb: misc: legousbtower: Fix memory leak

get_version_reply is not freed if function returns with success. Fixes: 942a48730faf ("usb: misc: legousbtower: Fix buffers on stack") Reported-by: Heikki Krogerus Signed-off-by: Maksim Salau --- v2: Changed tags to match guidelines. drivers/usb/misc/legousbtower.c | 1 + 1 file changed, 1

  1   2   3   4   5   >