Hi!
> >>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> >>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> >> [..]
> >>> +What:/sys/class/leds//hw_pattern
> >>> +Date:September 2018
> >>> +KernelVersion: 4.20
> >>> +Description:
Hi!
> >>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> >>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> >> [..]
> >>> +What:/sys/class/leds//hw_pattern
> >>> +Date:September 2018
> >>> +KernelVersion: 4.20
> >>> +Description:
On Wed, 12 Sep 2018, Thomas Gleixner wrote:
> > case X86_BUG_SPECTRE_V2:
> > - return sprintf(buf, "%s%s%s%s\n",
> > spectre_v2_strings[spectre_v2_enabled],
> > + mutex_lock(_ctrl_mutex);
> > + ret = sprintf(buf, "%s%s%s%s%s\n",
> >
On Wed, 12 Sep 2018, Thomas Gleixner wrote:
> > case X86_BUG_SPECTRE_V2:
> > - return sprintf(buf, "%s%s%s%s\n",
> > spectre_v2_strings[spectre_v2_enabled],
> > + mutex_lock(_ctrl_mutex);
> > + ret = sprintf(buf, "%s%s%s%s%s\n",
> >
On Wed, 12 Sep 2018, Jiri Kosina wrote:
> case X86_BUG_SPECTRE_V2:
> - return sprintf(buf, "%s%s%s%s\n",
> spectre_v2_strings[spectre_v2_enabled],
> + mutex_lock(_ctrl_mutex);
> + ret = sprintf(buf, "%s%s%s%s%s\n",
>
On Wed, 12 Sep 2018, Jiri Kosina wrote:
> case X86_BUG_SPECTRE_V2:
> - return sprintf(buf, "%s%s%s%s\n",
> spectre_v2_strings[spectre_v2_enabled],
> + mutex_lock(_ctrl_mutex);
> + ret = sprintf(buf, "%s%s%s%s%s\n",
>
USER_DS when recording user stack data (2018-09-10
> 14:01:46 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-urgent-for-mingo-4.19-20180912
>
> for you to fetch changes up to 03db8b5
USER_DS when recording user stack data (2018-09-10
> 14:01:46 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-urgent-for-mingo-4.19-20180912
>
> for you to fetch changes up to 03db8b5
Em Wed, Sep 12, 2018 at 07:02:32PM +0200, Alexander Sverdlin escreveu:
> CC .../tools/objtool/builtin-check.o
> ...
> In file included from .../tools/arch/x86/include/uapi/asm/bitsperlong.h:11:0,
> from .../tools/include/asm-generic/bitops/__ffs.h:6,
>
Em Wed, Sep 12, 2018 at 07:02:32PM +0200, Alexander Sverdlin escreveu:
> CC .../tools/objtool/builtin-check.o
> ...
> In file included from .../tools/arch/x86/include/uapi/asm/bitsperlong.h:11:0,
> from .../tools/include/asm-generic/bitops/__ffs.h:6,
>
You mean '4.19-rc3', right?
Right, sorry.
[1.741458] Internal error: Oops - undefined instruction:
0 [#1] SMP ARM
[1.748182] CPU: 1 PID: 72 Comm: kworker/1:2 Tainted: G
W 4.19.0-rc3 #1
The 'W' taint means that there was a kernel warning before. Which
warning was
You mean '4.19-rc3', right?
Right, sorry.
[1.741458] Internal error: Oops - undefined instruction:
0 [#1] SMP ARM
[1.748182] CPU: 1 PID: 72 Comm: kworker/1:2 Tainted: G
W 4.19.0-rc3 #1
The 'W' taint means that there was a kernel warning before. Which
warning was
repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-urgent-for-mingo-4.19-20180912
for you to fetch changes up to 03db8b583d1c3c84963e08e2abf6c79081da5c31:
perf tools: Fix maps__find_symbol_by_name() (2018-09-11 14:12:51 -0300
repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-urgent-for-mingo-4.19-20180912
for you to fetch changes up to 03db8b583d1c3c84963e08e2abf6c79081da5c31:
perf tools: Fix maps__find_symbol_by_name() (2018-09-11 14:12:51 -0300
From: Arnaldo Carvalho de Melo
To get the changes in:
3e7a50ceb11e ("net: report min and max mtu network device settings")
2756f68c3149 ("net: bridge: add support for backup port")
a25717d2b604 ("xdp: support simultaneous driver and hw XDP attachment")
From: Arnaldo Carvalho de Melo
To get the changes in:
a449938297e5 ("KVM: s390: Add huge page enablement control")
8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
be26b3a73413 ("arm64: KVM: export the capability to set guest SError
syndrome")
From: Adrian Hunter
Commit 1c5aae7710bb ("perf machine: Create maps for x86 PTI entry
trampolines") revealed a problem with maps__find_symbol_by_name() that
resulted in probes not being found e.g.
$ sudo perf probe xsk_mmap
xsk_mmap is out of .text, skip it.
Probe point
From: Arnaldo Carvalho de Melo
To get the changes in:
3e7a50ceb11e ("net: report min and max mtu network device settings")
2756f68c3149 ("net: bridge: add support for backup port")
a25717d2b604 ("xdp: support simultaneous driver and hw XDP attachment")
From: Arnaldo Carvalho de Melo
To get the changes in:
a449938297e5 ("KVM: s390: Add huge page enablement control")
8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
be26b3a73413 ("arm64: KVM: export the capability to set guest SError
syndrome")
From: Adrian Hunter
Commit 1c5aae7710bb ("perf machine: Create maps for x86 PTI entry
trampolines") revealed a problem with maps__find_symbol_by_name() that
resulted in probes not being found e.g.
$ sudo perf probe xsk_mmap
xsk_mmap is out of .text, skip it.
Probe point
From: Arnaldo Carvalho de Melo
To get the changes in:
d67b6a206507 ("drm: writeback: Add client capability for exposing
writeback connectors")
This is for an argument to a DRM ioctl, which is not being prettyfied in
the 'perf trace' DRM ioctl beautifier, but will now that syscalls are
From: Arnaldo Carvalho de Melo
To get the changes in:
d67b6a206507 ("drm: writeback: Add client capability for exposing
writeback connectors")
This is for an argument to a DRM ioctl, which is not being prettyfied in
the 'perf trace' DRM ioctl beautifier, but will now that syscalls are
From: Arnaldo Carvalho de Melo
To get the changes in:
c48300c92ad9 ("vhost: fix VHOST_GET_BACKEND_FEATURES ioctl request
definition")
This makes 'perf trace' and other tools in the future using its
beautifiers in a libbeauty.so library be able to translate these new
ioctl to strings:
From: Arnaldo Carvalho de Melo
To get the changes in:
c48300c92ad9 ("vhost: fix VHOST_GET_BACKEND_FEATURES ioctl request
definition")
This makes 'perf trace' and other tools in the future using its
beautifiers in a libbeauty.so library be able to translate these new
ioctl to strings:
From: Arnaldo Carvalho de Melo
To get the changes in:
db7a2d1809a5 ("asm-generic: unistd.h: Wire up sys_rseq")
That wires up the new 'rsec' system call, which will automagically
support that syscall in the syscall table used by 'perf trace' on
arm/arm64.
This cures the following
From: Arnaldo Carvalho de Melo
To get the changes in:
09121255c784 ("perf/UAPI: Clearly mark __PERF_SAMPLE_CALLCHAIN_EARLY as
internal use")
This cures the following warning during perf's build:
Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h'
differs
From: Arnaldo Carvalho de Melo
To get the changes in:
db7a2d1809a5 ("asm-generic: unistd.h: Wire up sys_rseq")
That wires up the new 'rsec' system call, which will automagically
support that syscall in the syscall table used by 'perf trace' on
arm/arm64.
This cures the following
From: Arnaldo Carvalho de Melo
To get the changes in:
09121255c784 ("perf/UAPI: Clearly mark __PERF_SAMPLE_CALLCHAIN_EARLY as
internal use")
This cures the following warning during perf's build:
Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h'
differs
Jan, Baruch,
On Wed, 12 Sep 2018 21:49:41 +0300, Baruch Siach wrote:
> Jan Kundrát writes:
> > since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only
> > remap I/O space if configured"), my board (Solidrun Clearfog Base) won't
> > finish booting with 4.18-rc3 won't boot:
>
>
Jan, Baruch,
On Wed, 12 Sep 2018 21:49:41 +0300, Baruch Siach wrote:
> Jan Kundrát writes:
> > since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only
> > remap I/O space if configured"), my board (Solidrun Clearfog Base) won't
> > finish booting with 4.18-rc3 won't boot:
>
>
Hi Jan,
Jan Kundrát writes:
> since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only
> remap I/O space if configured"), my board (Solidrun Clearfog Base) won't
> finish booting with 4.18-rc3 won't boot:
You mean '4.19-rc3', right?
>> [1.741458] Internal error: Oops -
Hi Jan,
Jan Kundrát writes:
> since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only
> remap I/O space if configured"), my board (Solidrun Clearfog Base) won't
> finish booting with 4.18-rc3 won't boot:
You mean '4.19-rc3', right?
>> [1.741458] Internal error: Oops -
On Wed, Sep 12, 2018 at 02:42:08PM +0200, Thomas Gleixner wrote:
> Subject: x86/tsc: Prevent result truncation on 32 bit
> From: Chuanhua Lei
> Date: Thu Sep 6 18:03:23 2018 +0800
>
> From: Chuanhua Lei
>
> Commit 17f6bac2249356c795339e03a0742cd79be3cab8 upstream.
>
> Loops per jiffy is
On Wed, Sep 12, 2018 at 02:42:08PM +0200, Thomas Gleixner wrote:
> Subject: x86/tsc: Prevent result truncation on 32 bit
> From: Chuanhua Lei
> Date: Thu Sep 6 18:03:23 2018 +0800
>
> From: Chuanhua Lei
>
> Commit 17f6bac2249356c795339e03a0742cd79be3cab8 upstream.
>
> Loops per jiffy is
On Mon, 10 Sep 2018 10:59:56 -0700
Paulo Zanoni wrote:
> As a Kernel developer, I make heavy use of "make targz-pkg" in order
> to locally compile and remotely install my development Kernels. The
> nice feature I rely on is that after a normal "make", "make targz-pkg"
> only generates the
On Mon, 10 Sep 2018 10:59:56 -0700
Paulo Zanoni wrote:
> As a Kernel developer, I make heavy use of "make targz-pkg" in order
> to locally compile and remotely install my development Kernels. The
> nice feature I rely on is that after a normal "make", "make targz-pkg"
> only generates the
On Wed, Sep 12, 2018 at 10:00:57AM -0700, Nick Desaulniers wrote:
> On Tue, Sep 11, 2018 at 4:40 PM Nathan Chancellor
> wrote:
> >
> > Clang warns when implicitly converting from one enumerated type to
> > another. Avoid this by using the equivalent value from the expected
> > type.
> >
> > In
On Wed, Sep 12, 2018 at 10:00:57AM -0700, Nick Desaulniers wrote:
> On Tue, Sep 11, 2018 at 4:40 PM Nathan Chancellor
> wrote:
> >
> > Clang warns when implicitly converting from one enumerated type to
> > another. Avoid this by using the equivalent value from the expected
> > type.
> >
> > In
On Wed, Sep 12, 2018 at 10:20:34AM +0800, Song Qiang wrote:
> This driver was originally written by ST in 2016 as a misc input device
> driver, and hasn't been maintained for a long time. I grabbed some code
> from it's API and reformed it into a iio proximity device driver.
> This version of
On Wed, Sep 12, 2018 at 10:20:34AM +0800, Song Qiang wrote:
> This driver was originally written by ST in 2016 as a misc input device
> driver, and hasn't been maintained for a long time. I grabbed some code
> from it's API and reformed it into a iio proximity device driver.
> This version of
On 09/11/2018 10:05 PM, Pavel Machek wrote:
> On Tue 2018-09-11 12:08:20, Dan Murphy wrote:
>> Remove support for the LM3697 LED device
>> from the ti-lmu. The LM3697 will be supported
>> via a stand alone LED driver.
>>
>> Signed-off-by: Dan Murphy
>
> I'd really like to see better explanation
On 09/11/2018 10:05 PM, Pavel Machek wrote:
> On Tue 2018-09-11 12:08:20, Dan Murphy wrote:
>> Remove support for the LM3697 LED device
>> from the ti-lmu. The LM3697 will be supported
>> via a stand alone LED driver.
>>
>> Signed-off-by: Dan Murphy
>
> I'd really like to see better explanation
Hello Afonso,
On Wed, Sep 12, 2018 at 05:26:01PM +0800, kbuild test robot wrote:
> Hi Afonso,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on iio/togreg]
> [also build test ERROR on v4.19-rc3 next-20180912]
> [if your patch is applied
Hello Afonso,
On Wed, Sep 12, 2018 at 05:26:01PM +0800, kbuild test robot wrote:
> Hi Afonso,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on iio/togreg]
> [also build test ERROR on v4.19-rc3 next-20180912]
> [if your patch is applied
On Wed, Sep 12, 2018 at 02:52:33PM +0530, Vinod wrote:
> On 12-09-18, 09:29, Greg KH wrote:
> > On Wed, Aug 08, 2018 at 09:58:50PM +0530, Vinod wrote:
> > > Hey Greg,
> > >
> > > Please PULL to receive the soundwire update for v4.19-rc1 with a signed
> > > tag as you requested last time and the
On Wed, Sep 12, 2018 at 02:52:33PM +0530, Vinod wrote:
> On 12-09-18, 09:29, Greg KH wrote:
> > On Wed, Aug 08, 2018 at 09:58:50PM +0530, Vinod wrote:
> > > Hey Greg,
> > >
> > > Please PULL to receive the soundwire update for v4.19-rc1 with a signed
> > > tag as you requested last time and the
On Wed, Sep 12, 2018 at 05:13:05PM +0200, Arnd Bergmann wrote:
> These are all handled by the random driver, so instead of listing
> each ioctl, we can just use the same function to deal with both
> native and compat commands.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/char/random.c | 1 +
On Wed, Sep 12, 2018 at 05:13:05PM +0200, Arnd Bergmann wrote:
> These are all handled by the random driver, so instead of listing
> each ioctl, we can just use the same function to deal with both
> native and compat commands.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/char/random.c | 1 +
Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.
Signed-off-by: Venkata Narendra Kumar Gutta
Reviewed-by: Rob Herring
---
.../devicetree/bindings/arm/msm/qcom,llcc.txt
Cache error reporting controller detects and reports single and
double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.
Signed-off-by: Venkata Narendra Kumar Gutta
Reviewed-by: Evan Green
---
Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.
Signed-off-by: Venkata Narendra Kumar Gutta
Reviewed-by: Rob Herring
---
.../devicetree/bindings/arm/msm/qcom,llcc.txt
Cache error reporting controller detects and reports single and
double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.
Signed-off-by: Venkata Narendra Kumar Gutta
Reviewed-by: Evan Green
---
From: Channagoud Kadabi
Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports error reporting for
Last Level Cache Controller (LLCC) of Tag RAM and Data RAM. Interrupts
are triggered when the errors happen in the cache, the driver
From: Channagoud Kadabi
Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports error reporting for
Last Level Cache Controller (LLCC) of Tag RAM and Data RAM. Interrupts
are triggered when the errors happen in the cache, the driver
This series implements EDAC driver for QCOM SoCs. As of now, this driver
supports EDAC for Last Level Cache Controller (LLCC). LLCC EDAC driver is
to detect and report single and double bit errors on Last Level Cache
Controller (LLCC) cache. Interrupts are triggered when the errors happen
in the
This series implements EDAC driver for QCOM SoCs. As of now, this driver
supports EDAC for Last Level Cache Controller (LLCC). LLCC EDAC driver is
to detect and report single and double bit errors on Last Level Cache
Controller (LLCC) cache. Interrupts are triggered when the errors happen
in the
Currently, broadcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT).
Currently, broadcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT).
Answering to myself:
It looks like ext4 lazy init does not play well with loop device.
If the ext4 filesystem was previously created with lazy init there are
I/O errors. Disabling lazy init fixes problem. Bug or feature?
Thanks,
I'm mounting an ext4 filesystem residing on an AHCI SATA disk
Answering to myself:
It looks like ext4 lazy init does not play well with loop device.
If the ext4 filesystem was previously created with lazy init there are
I/O errors. Disabling lazy init fixes problem. Bug or feature?
Thanks,
I'm mounting an ext4 filesystem residing on an AHCI SATA disk
On 12-Sep 19:42, Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 06:35:15PM +0100, Patrick Bellasi wrote:
> > On 12-Sep 18:12, Peter Zijlstra wrote:
>
> > > No idea; but if you want to go all fancy you can replace he whole
> > > uclamp_map thing with something like:
> > >
> > > struct uclamp_map
On 12-Sep 19:42, Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 06:35:15PM +0100, Patrick Bellasi wrote:
> > On 12-Sep 18:12, Peter Zijlstra wrote:
>
> > > No idea; but if you want to go all fancy you can replace he whole
> > > uclamp_map thing with something like:
> > >
> > > struct uclamp_map
On Tue, Sep 11, 2018 at 8:36 PM, Bin Yang wrote:
> persistent_ram_vmap() returns the page start vaddr.
> persistent_ram_iomap() supports non-page-aligned mapping.
Oh, yes, good catch. This should probably be explicitly mentioned in
comments for these functions.
> persistent_ram_buffer_map()
On 12-Sep 19:34, Peter Zijlstra wrote:
> On Tue, Aug 28, 2018 at 02:53:11PM +0100, Patrick Bellasi wrote:
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index 72df2dc779bc..513608ae4908 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -764,6 +764,50 @@
On Tue, Sep 11, 2018 at 8:36 PM, Bin Yang wrote:
> persistent_ram_vmap() returns the page start vaddr.
> persistent_ram_iomap() supports non-page-aligned mapping.
Oh, yes, good catch. This should probably be explicitly mentioned in
comments for these functions.
> persistent_ram_buffer_map()
On 12-Sep 19:34, Peter Zijlstra wrote:
> On Tue, Aug 28, 2018 at 02:53:11PM +0100, Patrick Bellasi wrote:
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index 72df2dc779bc..513608ae4908 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -764,6 +764,50 @@
On Fri, Sep 07, 2018 at 08:33:22AM +0200, Krzysztof Kozlowski wrote:
>On Fri, 7 Sep 2018 at 02:54, Sasha Levin wrote:
>>
>> From: Krzysztof Kozlowski
>>
>> [ Upstream commit e5cda42c16d89720c29678f51d95a119490ef7d8 ]
>>
>> S5Pv210 and Exynos5433/Exynos7 have different address of
>>
On Fri, Sep 07, 2018 at 08:33:22AM +0200, Krzysztof Kozlowski wrote:
>On Fri, 7 Sep 2018 at 02:54, Sasha Levin wrote:
>>
>> From: Krzysztof Kozlowski
>>
>> [ Upstream commit e5cda42c16d89720c29678f51d95a119490ef7d8 ]
>>
>> S5Pv210 and Exynos5433/Exynos7 have different address of
>>
On 08/23/2018 04:24 AM, Cornelia Huck wrote:
On Thu, 23 Aug 2018 09:48:48 +0200
David Hildenbrand wrote:
Migration of AP devices is not supported by this patch series, so this
should
not be an issue.
Might not be a problem now, but could be later. As I said in a different
reply, the CPU
On 08/23/2018 04:24 AM, Cornelia Huck wrote:
On Thu, 23 Aug 2018 09:48:48 +0200
David Hildenbrand wrote:
Migration of AP devices is not supported by this patch series, so this
should
not be an issue.
Might not be a problem now, but could be later. As I said in a different
reply, the CPU
On Wed, Sep 12, 2018 at 06:35:15PM +0100, Patrick Bellasi wrote:
> On 12-Sep 18:12, Peter Zijlstra wrote:
> > No idea; but if you want to go all fancy you can replace he whole
> > uclamp_map thing with something like:
> >
> > struct uclamp_map {
> > union {
> > struct {
> >
On Wed, Sep 12, 2018 at 06:35:15PM +0100, Patrick Bellasi wrote:
> On 12-Sep 18:12, Peter Zijlstra wrote:
> > No idea; but if you want to go all fancy you can replace he whole
> > uclamp_map thing with something like:
> >
> > struct uclamp_map {
> > union {
> > struct {
> >
On 12-Sep 18:24, Peter Zijlstra wrote:
> On Tue, Aug 28, 2018 at 02:53:10PM +0100, Patrick Bellasi wrote:
> > static inline int __setscheduler_uclamp(struct task_struct *p,
> > const struct sched_attr *attr)
>
> But large for inline now.
Yes, Suren also
On 12-Sep 18:24, Peter Zijlstra wrote:
> On Tue, Aug 28, 2018 at 02:53:10PM +0100, Patrick Bellasi wrote:
> > static inline int __setscheduler_uclamp(struct task_struct *p,
> > const struct sched_attr *attr)
>
> But large for inline now.
Yes, Suren also
On Fri, Sep 07, 2018 at 01:33:55PM -0400, Boris Ostrovsky wrote:
>On 09/06/2018 08:36 PM, Sasha Levin wrote:
>> From: Vitaly Kuznetsov
>>
>> [ Upstream commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 ]
>>
>> Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
>> open") changed
On Fri, Sep 07, 2018 at 01:33:55PM -0400, Boris Ostrovsky wrote:
>On 09/06/2018 08:36 PM, Sasha Levin wrote:
>> From: Vitaly Kuznetsov
>>
>> [ Upstream commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 ]
>>
>> Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
>> open") changed
On Fri, Sep 07, 2018 at 07:42:23AM +0200, Greg Kroah-Hartman wrote:
>On Fri, Sep 07, 2018 at 12:35:52AM +, Sasha Levin wrote:
>> From: Sebastian Andrzej Siewior
>>
>> [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ]
>>
>> The USB completion callback does not disable interrupts
On Fri, Sep 07, 2018 at 07:42:23AM +0200, Greg Kroah-Hartman wrote:
>On Fri, Sep 07, 2018 at 12:35:52AM +, Sasha Levin wrote:
>> From: Sebastian Andrzej Siewior
>>
>> [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ]
>>
>> The USB completion callback does not disable interrupts
On 12-Sep 18:12, Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 04:56:19PM +0100, Patrick Bellasi wrote:
> > On 12-Sep 15:49, Peter Zijlstra wrote:
> > > On Tue, Aug 28, 2018 at 02:53:10PM +0100, Patrick Bellasi wrote:
>
> > > > +/**
> > > > + * uclamp_map: reference counts a utilization "clamp
On 12-Sep 18:12, Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 04:56:19PM +0100, Patrick Bellasi wrote:
> > On 12-Sep 15:49, Peter Zijlstra wrote:
> > > On Tue, Aug 28, 2018 at 02:53:10PM +0100, Patrick Bellasi wrote:
>
> > > > +/**
> > > > + * uclamp_map: reference counts a utilization "clamp
On Tue, Aug 28, 2018 at 02:53:11PM +0100, Patrick Bellasi wrote:
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 72df2dc779bc..513608ae4908 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -764,6 +764,50 @@ extern void rto_push_irq_work_func(struct irq_work
On Tue, Aug 28, 2018 at 02:53:11PM +0100, Patrick Bellasi wrote:
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 72df2dc779bc..513608ae4908 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -764,6 +764,50 @@ extern void rto_push_irq_work_func(struct irq_work
[+cc ACPI folks, LKML]
On Wed, Sep 12, 2018 at 04:21:40PM +0100, Jonathan Cameron wrote:
> The ACPI specification allows you to provide _PXM entries for devices based
> on their location on a particular bus. Let us use that if it is provided
> rather than just assuming it makes sense to put the
[+cc ACPI folks, LKML]
On Wed, Sep 12, 2018 at 04:21:40PM +0100, Jonathan Cameron wrote:
> The ACPI specification allows you to provide _PXM entries for devices based
> on their location on a particular bus. Let us use that if it is provided
> rather than just assuming it makes sense to put the
On Mon, Sep 10, 2018 at 10:42:05AM +0100, Vladimir Murzin wrote:
>On 02/09/18 14:07, Sasha Levin wrote:
>> From: Vladimir Murzin
>>
>> [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ]
>>
>> ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed
>> Sec_frac (bits [23:20]):
On Mon, Sep 10, 2018 at 10:42:05AM +0100, Vladimir Murzin wrote:
>On 02/09/18 14:07, Sasha Levin wrote:
>> From: Vladimir Murzin
>>
>> [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ]
>>
>> ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed
>> Sec_frac (bits [23:20]):
Fix the following checkpatch error:
ERROR: pointer location foo * bar should be foo *bar
FILE: drivers/watchdog/diag288_wdt.c:202
Signed-off-by: Jagdish Tirumala
---
drivers/watchdog/diag288_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Fix the following checkpatch error:
ERROR: pointer location foo * bar should be foo *bar
FILE: drivers/watchdog/diag288_wdt.c:202
Signed-off-by: Jagdish Tirumala
---
drivers/watchdog/diag288_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 09/11/2018 04:16 PM, Thomas Gleixner wrote:
> On Tue, 11 Sep 2018, Tim Chen wrote:
>> On 09/10/2018 04:46 AM, Jiri Kosina wrote:
>>> Nah, IBPB is actuall there, sorry. So I'll add reporting of STIBP + fixup
>>> the missing reporting of RSB_CTXSW for v6.
>>>
>>
>> I anticipate that STIBP
Please capitalize the subject as:
PCI: Provide pci_match_id() with CONFIG_PCI=n
On Mon, Sep 10, 2018 at 01:59:32PM +0200, Lubomir Rintel wrote:
> This spares drivers from #ifdef-ing on CONFIG_PCI if the driver can be
> optionally built on machines without PCI bus.
>
> Consistent with
On 09/11/2018 04:16 PM, Thomas Gleixner wrote:
> On Tue, 11 Sep 2018, Tim Chen wrote:
>> On 09/10/2018 04:46 AM, Jiri Kosina wrote:
>>> Nah, IBPB is actuall there, sorry. So I'll add reporting of STIBP + fixup
>>> the missing reporting of RSB_CTXSW for v6.
>>>
>>
>> I anticipate that STIBP
Please capitalize the subject as:
PCI: Provide pci_match_id() with CONFIG_PCI=n
On Mon, Sep 10, 2018 at 01:59:32PM +0200, Lubomir Rintel wrote:
> This spares drivers from #ifdef-ing on CONFIG_PCI if the driver can be
> optionally built on machines without PCI bus.
>
> Consistent with
On 9/12/18 2:11 AM, Michal Hocko wrote:
On Tue 11-09-18 19:29:21, Matthew Wilcox wrote:
On Tue, Sep 11, 2018 at 04:35:03PM -0700, Yang Shi wrote:
[...]
I didn't get to read the patch yet.
If you guys think this is the better way I could convert my patches to
go this way. It is simple to
On 9/12/18 2:11 AM, Michal Hocko wrote:
On Tue 11-09-18 19:29:21, Matthew Wilcox wrote:
On Tue, Sep 11, 2018 at 04:35:03PM -0700, Yang Shi wrote:
[...]
I didn't get to read the patch yet.
If you guys think this is the better way I could convert my patches to
go this way. It is simple to
On Wed, Sep 12, 2018 at 05:39:14PM +0100, Will Deacon wrote:
> Hi Sean,
>
> Thanks for looking at the patch.
>
> On Wed, Sep 12, 2018 at 08:09:39AM -0700, Sean Christopherson wrote:
> > On Wed, Sep 12, 2018 at 11:26:13AM +0100, Will Deacon wrote:
> > > The current ioremap() code uses a phys_addr
On Wed, Sep 12, 2018 at 05:39:14PM +0100, Will Deacon wrote:
> Hi Sean,
>
> Thanks for looking at the patch.
>
> On Wed, Sep 12, 2018 at 08:09:39AM -0700, Sean Christopherson wrote:
> > On Wed, Sep 12, 2018 at 11:26:13AM +0100, Will Deacon wrote:
> > > The current ioremap() code uses a phys_addr
> On Sep 12, 2018, at 7:29 AM, Thomas Gleixner wrote:
>
>> On Wed, 12 Sep 2018, Florian Weimer wrote:
>>> On 09/12/2018 04:17 PM, Thomas Gleixner wrote:
On Wed, 12 Sep 2018, Florian Weimer wrote:
Does this mean glibc can keep using a single vDSO entrypoint, the one we
have
> On Sep 12, 2018, at 7:29 AM, Thomas Gleixner wrote:
>
>> On Wed, 12 Sep 2018, Florian Weimer wrote:
>>> On 09/12/2018 04:17 PM, Thomas Gleixner wrote:
On Wed, 12 Sep 2018, Florian Weimer wrote:
Does this mean glibc can keep using a single vDSO entrypoint, the one we
have
On Tue, Sep 11, 2018 at 12:17:05PM +0200, Martin Steigerwald wrote:
> Cc´d Intel Gfx mailing list, in case somebody there knows something:
>
> Cc´d Thorsten for regression tracking… forgot initially. Can also open
> bug report at a later time but so far I cannot provide many details
> about the
On Tue, Sep 11, 2018 at 12:17:05PM +0200, Martin Steigerwald wrote:
> Cc´d Intel Gfx mailing list, in case somebody there knows something:
>
> Cc´d Thorsten for regression tracking… forgot initially. Can also open
> bug report at a later time but so far I cannot provide many details
> about the
501 - 600 of 1468 matches
Mail list logo
