The RK3288 CRU system clock solution would suggest use
the vdpu clock source for the VPU(aclk_vpu and hclk_vpu).
Reading the registers of VPU(both VEPU and VDPU) would become all high
when the vepu is used as the clock source. It may be a bug in the SoC,
not sure whether it is fixed at RK3288W.
S
From: Arnd Bergmann
"gcc -Wunused" warns about one argument being assigned but not used:
drivers/staging/ccree/ssi_cipher.c: In function 'ssi_blkcipher_complete':
drivers/staging/ccree/ssi_cipher.c:747:41: error: parameter 'info' set but not
used [-Werror=unused-but-set-parameter]
We can simpl
Hi Arnd,
On Thu, May 11, 2017 at 2:38 PM, Arnd Bergmann wrote:
> "gcc -Wunused" warns about one argument being assigned but not used:
>
> drivers/staging/ccree/ssi_cipher.c: In function 'ssi_blkcipher_complete':
> drivers/staging/ccree/ssi_cipher.c:747:41: error: parameter 'info' set but
> not u
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|
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 GIC_SPI 193 IRQ_TYPE_NONE>,
> > <0x0800 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
> > <0x1000 0 0 0 &gic
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 changed
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
>
> > > + msm_mux_gpio
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.
> >
> > > 0x2
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 shou
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 othe
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 collap
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 furt
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 c
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
* Clarifi
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
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
@@ -167
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 use
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 73272f43ca01..b4e919
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 for
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
---
drive
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 DAX
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: https://git.kernel.org/pub/scm/linux/kerne
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 da
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] is
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 w
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
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
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 .con
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':
> driver
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
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 /sys/devices/system/clocksource/clo
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
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
b/drivers/staging/sm750fb/ddk750_display
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 +--
drivers/stag
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 +-
drivers/staging/sm750fb/dd
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
stag
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
b/d
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
drivers/staging/sm
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 file
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 d
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 ch
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
inde
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
b/drivers/net/wir
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 a/driver
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
>
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 c
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 y
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);
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&m=149464267427111&w=2 indicates that
you are using a SuSE hypervisor.
yes, that's corre
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 prese
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 fo
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).
>
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
On Sat, May 13, 2017 at 10:32:31PM +0200, Geert Uytterhoeven wrote:
> You better run that one through linux-spi, to avoid conflicts, cfr.
> https://patchwork.kernel.org/patch/9714993/
What I'm going to do is never-rebased #for-spi (well, never after -rc1)
merged into #work.uaccess and proposed fo
On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote:
> From: Linus Torvalds
> Date: Tue, 24 Mar 2015 10:42:18 -0700
> >
> > So I'd suggest we should just do a wholesale replacement of
> > __copy_to/from_user() with the non-underlined cases. Then, we could
> > switch insividual ones back
Hi Al,
On Sat, May 13, 2017 at 10:08 PM, Al Viro wrote:
> On Sat, May 13, 2017 at 08:56:59PM +0100, Al Viro wrote:
>
>> FWIW, just this cycle (this one I remembered off-hand, there might be
>> more):
>
> And looking through my queue (will be pushed to -next as soon as -rc1 goes
> out):
>
> commit
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 present when booting with Xen.
>
> sam
On 13/05/2017 21:05, PGNet Dev wrote:
> On 5/13/17 12:59 PM, Andrew Cooper wrote:
>> Ok. Lack of a clocksource is to be expected.
>>
>> The reason why the HPETs are unavailable is that dom0 is not a position
>> to program them; dom0 doesn't know what Xen has set up in the IDT.
>>
>> Use `xl dmesg`
On Sat, May 13, 2017 at 08:56:59PM +0100, Al Viro wrote:
> FWIW, just this cycle (this one I remembered off-hand, there might be
> more):
And looking through my queue (will be pushed to -next as soon as -rc1 goes
out):
commit 87fb4c8c103a4cdf17fead4aba58e96940a19a09
Author: Al Viro
Date: Thu
On 5/13/17 12:59 PM, Andrew Cooper wrote:
Ok. Lack of a clocksource is to be expected.
The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.
Use `xl dmesg` to get to the hypervisor dmesg log. You should see
m
On 13/05/2017 20:28, Randy Dunlap wrote:
> On 05/13/17 11:26, PGNet Dev wrote:
>> On 5/13/17 10:41 AM, Randy Dunlap wrote:
>>> [adding HPET driver maintainer]
>> Thanks
>>
>>> A couple of comments below...
In BIOS, HPET's enabled.
>>> How about if you just boot Linux without Xen? Does HPET sh
On 13/05/2017 20:49, PGNet Dev wrote:
> On 5/13/17 12:38 PM, Andrew Cooper wrote:
>> What is the issue here?
>>
>> Xen owns (and may use) any HPETs in the system. They are purposefully
>> unavailable to even dom0.
> The issue is that, when booting to Xen, hpet is not advertised as an
> available
On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote:
> > We should probably even consider looking at __get_user/__put_user().
> > Few of them are actually performance-critical.
>
> Look at that date. It's over two years ago. In the intervening two
> years, how many of those conversions
Randy Dunlap wrote:
> On 05/12/17 19:30, PGNet Dev wrote:
>> dmesg | grep -i hpet
>> [8.491738] hpet_acpi_add: no address or irqs in _CRS
>
> Above line marks a big failure.
> ^^^
>
>> Disassembling the firmware acpi tables
>>
>
On 05/10/2017 04:29 PM, Alan Cox wrote:
On Fri, 5 May 2017 19:20:16 -0400
Matt Brown wrote:
This patchset introduces the tiocsti_restrict sysctl, whose default is
controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this
control restricts all TIOCSTI ioctl calls from non CAP_SYS_A
On 5/13/17 12:45 PM, Clemens Ladisch wrote:
That table is not used by hpet_acpi_add; you have to check for the device
that mentions "PNP0103" in the DSDT table.
But anyway, as far as I can tell from my own machine, the _CRS in the
DSDT table never lists the HPET interrupts, and the HPET registra
While creating new device with NVM_DEV_CREATE if LUNs are already
allocated ioctl would return -ENOMEM which is wrong. This patch
propagates -EBUSY from nvm_reserve_luns which is correct response.
Fixes: ade69e243 ("lightnvm: merge gennvm with core")
Signed-off-by: Rakesh Pandit
---
drivers/lig
On 5/13/17 12:38 PM, Andrew Cooper wrote:
> What is the issue here?
>
> Xen owns (and may use) any HPETs in the system. They are purposefully
> unavailable to even dom0.
The issue is that, when booting to Xen, hpet is not advertised as an available
clocksource, AND reports the hpet boot error p
On 05/13/2017 04:51 AM, Kees Cook wrote:
> Adjusts for ReST markup and moves under LSM admin guide.
>
> Cc: John Johansen
> Signed-off-by: Kees Cook
Acked-by: John Johansen
> ---
> .../apparmor.txt => admin-guide/LSM/apparmor.rst} | 36
> ++
> Documentation/admin-guide/L
On Mai 13 2017, Rob Landley wrote:
> It's the "must be pushed/fetched explicitly" part that I couldn't figure
> out back when I tried it.
You have to use refs/replace/*:refs/replace/* as the refspec for push
and fetch. By default, push and fetch only look at refs/heads/*.
Andreas.
--
Andreas
On Sat, May 13, 2017 at 08:11:42PM +0100, Al Viro wrote:
> It's not impossible to review; the problem is in figuring out which codepaths
> are hot enough to worry about them. And I'm even more convinced that
> bulk search-and-replace is the right approach here; we probably _can_ get
If instance directories are deleted while there are registered function
triggers:
# cd /sys/kernel/debug/tracing/instances
# mkdir test
# echo "schedule:enable_event:sched:sched_switch" > test/set_ftrace_filter
# rmdir test
Unable to handle kernel paging request for data at address 0x000
Handle a NULL glob properly.
Signed-off-by: Naveen N. Rao
---
kernel/trace/ftrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 39dca4e86a94..28dc824ad072 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.
Add a test to ensure we clean up properly when removing an instance
with active event triggers.
Signed-off-by: Naveen N. Rao
---
Steven,
I have also removed what looked like an incorrect 'exit' in the middle
of this test. Kindly take a look if that's ok.
- Naveen
tools/testing/selftests/ftrace
This series fixes a kernel oops when an ftrace instance is deleted while
there are still active event triggers. Patch 2 provides details on how
to reproduce as well as the kernel oops message.
This issue was reported by Michael Ellerman as a crash seen when trying
to run the ftrace test suite. In
Fix a few bashisms in ftrace selftests.
Signed-off-by: Naveen N. Rao
---
tools/testing/selftests/ftrace/ftracetest | 2 +-
tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc | 2 +-
tools/testing/selftests/ftrace/test.d/functions | 4
On 05/13/17 11:26, PGNet Dev wrote:
> On 5/13/17 10:41 AM, Randy Dunlap wrote:
>> [adding HPET driver maintainer]
>
> Thanks
>
>> A couple of comments below...
>
>>> In BIOS, HPET's enabled.
>>
>> How about if you just boot Linux without Xen? Does HPET show up then?
>
> yes, it appears so:
>
On Fri 12 May 14:18 PDT 2017, John Stultz wrote:
> lvs7 {
> bias-pull-down;
> + regulator-always-on;
> };
Looking at the downstream regulator definition lvs7 is id
Hi Pavel,
[auto build test ERROR on mmotm/master]
[also build test ERROR on next-20170512]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Pavel-Tatashin/parallelized-struct-page-zeroing/20170507
On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote:
> On Sat, May 13, 2017 at 11:04 AM, Al Viro wrote:
> >
> >
> > My point is, this stuff needs looking at.
>
> No.
>
> You don't have a point. I've tried to explain that there's no
> performance difference, and there is no way in hell
On Sat, May 13, 2017 at 07:26:56PM +0100, Al Viro wrote:
> BTW, even in arch/* they tend to nest. E.g. arch/alpha has 133 callers
> total. Distribution by files:
> 35 arch/alpha/kernel/osf_sys.c
> 92 arch/alpha/kernel/signal.c
> 1 arch/alpha/kernel/traps.c
> 4 arch/alpha/lib
Use more common error logging style.
Signed-off-by: Karim Eshapa
---
crypto/algapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 9eed4ef..e4cc761 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -260,7 +260,7 @@ void crypto_alg
On Sat, May 13, 2017 at 11:04 AM, Al Viro wrote:
>
>
> My point is, this stuff needs looking at.
No.
You don't have a point. I've tried to explain that there's no
performance difference, and there is no way in hell that the current
"__" versions are better.
So what's the point in looking? All y
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':
drivers/dax/super.c:50:26: error: implicit declaration of function
'get_start
On Fri, May 12, 2017 at 05:52:18PM +0200, Luis R. Rodriguez wrote:
> On Fri, May 12, 2017 at 09:20:24AM +0900, AKASHI Takahiro wrote:
> > On Thu, May 11, 2017 at 08:26:29PM +0200, Luis R. Rodriguez wrote:
> > > On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> > > > On Fri, Apr 28,
Guenter Roeck writes:
> On 05/12/2017 01:03 PM, Eric W. Biederman wrote:
>> Guenter Roeck writes:
>>
>>> Hi Eric,
>>>
>>> On Fri, May 12, 2017 at 12:33:01PM -0500, Eric W. Biederman wrote:
Guenter Roeck writes:
> Hi Eric,
>
> On Fri, May 12, 2017 at 08:26:27AM -0500, Eric
On Sat, May 13, 2017 at 07:04:13PM +0100, Al Viro wrote:
> My point is, this stuff needs looking at. Even this quick look in arch/x86
> has shown several fairly different classes of that stuff, probably needing
> different approaches. And that - on an architecture that had tons of TLC
> around s
On 5/13/17 10:41 AM, Randy Dunlap wrote:
[adding HPET driver maintainer]
Thanks
A couple of comments below...
In BIOS, HPET's enabled.
How about if you just boot Linux without Xen? Does HPET show up then?
yes, it appears so:
cat devices/system/clocksource/clocksource0/available
tsc
On Sat, May 13, 2017 at 10:18:22AM -0700, Linus Torvalds wrote:
> > x86 actually tends to use get_user_ex/put_user_ex instead.
>
> Yes. Because anybody who *really* cared about performance will have
> converted already. The real cost has been stac/clac for a few years
> now.
On x86. Which has (
[adding HPET driver maintainer]
A couple of comments below...
On 05/12/17 19:30, PGNet Dev wrote:
> I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard.
>
> HPET's enabled in BIOS, and apparently firmware table data is available.
>
> But, hpet is not an available_clocksource.
>
> Where's
On 05/12/2017 12:49 PM, Andreas Schwab wrote:
> On Mai 12 2017, Rob Landley wrote:
>
>> Last I checked I couldn't just "git push" the fullhist tree to
>> git.kernel.org because git graft didn't propagate right.
>
> Perhaps you could recreate them with git replace --graft. That creates
> replace
Fix some unneeded exported symbols by marking them as static.
This was found with the 'sparse' tool.
Signed-off-by: Juan Antonio Pedreira Martos
---
.../media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
a/driv
> -Original Message-
> From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net]
> Sent: Saturday, May 13, 2017 15:54
> To: linux-...@vger.kernel.org; Bojan Prtvar ; Linus
> Walleij ; Paul Burton ;
> Shawn Lin ; Ulf Hansson
> ; Uri Yanai ; Winkler,
> Tomas
> Cc: LKML ; kernel-janit.
Compiling the UniPhier DT files with W=1, DTC warns like follows:
Warning (simple_bus_reg): Node
/soc/system-bus@58c0/support_card@1,1f0/ethernet@ simple-bus
unit address format error, expected "0"
Warning (simple_bus_reg): Node
/soc/system-bus@58c0/support_card@1,1f0/ua
Compiling the UniPhier DT files with W=1, DTC warns like follows:
Warning (simple_bus_reg): Node /soc/smpctrl@5980 simple-bus unit address
format error, expected "59801000"
Signed-off-by: Masahiro Yamada
---
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 2 +-
arch/arm64/boot/dts/soci
This option, if disabled, is used to alias find_first_bit() to
find_next_bit() with the trivial macro:
#define find_first_bit(addr, size) find_next_bit((addr), (size), 0)
And the same for find_first_zero_bit().
The problem here is that the implementation of find_next_bit() is more
complex, and t
On Sat, May 13, 2017 at 10:00 AM, Al Viro wrote:
> On Sat, May 13, 2017 at 09:15:07AM -0700, Linus Torvalds wrote:
>> > IOW, we have
>> > * most of users in arch/* (heavily dominated by signal-related
>> > code,
>> > both loads and stores). Those need careful massage; maybe unsafe-based
On 05/13/2017 04:35 AM, Thomas Gleixner wrote:
> On Fri, 12 May 2017, Eric W. Biederman wrote:
>> Which leaves me perplexed. The hashes from tglx's current tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
>> on kernel.org and the hashes in your full history tree differ.
>>
On Sat, May 13, 2017 at 06:00:56PM +0100, Al Viro wrote:
> > But I don't see the excuse for not just doing it. If nobody notices,
> > it's an obvious improvement. And if somebody *does* notice, we know
> > how to do it properly with unsafe_xyz_user(), because "__xyz_user()"
> > most definitely isn
On Sat, May 13, 2017 at 09:15:07AM -0700, Linus Torvalds wrote:
> > IOW, we have
> > * most of users in arch/* (heavily dominated by signal-related code,
> > both loads and stores). Those need careful massage; maybe unsafe-based
> > solution, maybe something else, but it's obviously per-ar
1 - 100 of 218 matches
Mail list logo
