Hello
How are you? Am SARAH MONGAR. For an Export Business am, writing
to inform you, concerning business proposer in Agriculture raw
materials export supply to Germany. If you are good in Business kindly
write me on my mail I'D sarahmor1...@gmail.com
SARAH MONGAR
E-mail:
Hi Daniel,
On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
> On 19/11/2018 12:29, Alexey Brodkin wrote:
> > It turned out we used to use default implementation of sched_clock()
> > from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> > by default we had 10 msec granularity of
Hello
How are you? Am SARAH MONGAR. For an Export Business am, writing
to inform you, concerning business proposer in Agriculture raw
materials export supply to Germany. If you are good in Business kindly
write me on my mail I'D sarahmor1...@gmail.com
SARAH MONGAR
E-mail:
Hi Daniel,
On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
> On 19/11/2018 12:29, Alexey Brodkin wrote:
> > It turned out we used to use default implementation of sched_clock()
> > from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> > by default we had 10 msec granularity of
On 19/11/2018 21:27, Jon Hunter wrote:
>
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> The memory interface configuration and re-calibration interval are left
>> unassigned on resume from LP1 because these registers are shadowed and
>> require latching after being adjusted.
>>
>>
On 19/11/2018 21:27, Jon Hunter wrote:
>
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> The memory interface configuration and re-calibration interval are left
>> unassigned on resume from LP1 because these registers are shadowed and
>> require latching after being adjusted.
>>
>>
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The external memory arbitration configuration is getting reset after
> memory entering into self-refresh mode, it shall be restored on the
> exit. Note that MC_EMEM_ARB_CFG register is shadowed and latching
> happens on the EMC timing update. This
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The external memory arbitration configuration is getting reset after
> memory entering into self-refresh mode, it shall be restored on the
> exit. Note that MC_EMEM_ARB_CFG register is shadowed and latching
> happens on the EMC timing update. This
I made early boot time stamps available for SPARC and X86.
x86:
https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatas...@oracle.com
sparc:
https://www.spinics.net/lists/sparclinux/msg18063.html
As discussed at plumbers, I would like to add the same for arm64. The
implementation does
I made early boot time stamps available for SPARC and X86.
x86:
https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatas...@oracle.com
sparc:
https://www.spinics.net/lists/sparclinux/msg18063.html
As discussed at plumbers, I would like to add the same for arm64. The
implementation does
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f4fc1e0544b7..4df41a66b403
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f4fc1e0544b7..4df41a66b403
On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner wrote:
>
> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> > wrote:
> > > That can be done without a loop by comparing the level counter for the
> > > two pid
On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner wrote:
>
> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> > wrote:
> > > That can be done without a loop by comparing the level counter for the
> > > two pid
On Mon, Nov 19, 2018 at 08:39:41PM +0100, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
>
> > Generally speaking the untrusted code that would try to use spectrev2
> > to attack the other processes is more likely to run inside SECCOMP
> > jail than outside, so if SECCOMP
On Sun, Nov 18, 2018 at 4:56 PM Guenter Roeck wrote:
>
> On 11/17/18 7:29 AM, Rob Herring wrote:
> > On Fri, Nov 09, 2018 at 11:56:06AM +1300, Chris Packham wrote:
> >> With the addition of the invert-pwm property the adt7475 needs its own
> >> binding documentation rather being captured under
On Mon, Nov 19, 2018 at 08:39:41PM +0100, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
>
> > Generally speaking the untrusted code that would try to use spectrev2
> > to attack the other processes is more likely to run inside SECCOMP
> > jail than outside, so if SECCOMP
On Sun, Nov 18, 2018 at 4:56 PM Guenter Roeck wrote:
>
> On 11/17/18 7:29 AM, Rob Herring wrote:
> > On Fri, Nov 09, 2018 at 11:56:06AM +1300, Chris Packham wrote:
> >> With the addition of the invert-pwm property the adt7475 needs its own
> >> binding documentation rather being captured under
Hello,
syzbot found the following crash on:
HEAD commit:bae4e109837b mlxsw: spectrum: Expose discard counters via ..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11b5e77b40
kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
Hello,
syzbot found the following crash on:
HEAD commit:bae4e109837b mlxsw: spectrum: Expose discard counters via ..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11b5e77b40
kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> wrote:
> > That can be done without a loop by comparing the level counter for the
> > two pid namespaces.
> >
> >>
> >> And you can rewrite pidns_get_parent to use it. So you
On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> wrote:
> > That can be done without a loop by comparing the level counter for the
> > two pid namespaces.
> >
> >>
> >> And you can rewrite pidns_get_parent to use it. So you
On 2018-11-19, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> wrote:
> > That can be done without a loop by comparing the level counter for the
> > two pid namespaces.
> >
> >>
> >> And you can rewrite pidns_get_parent to use it. So you would instead be
> >>
On 2018-11-19, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> wrote:
> > That can be done without a loop by comparing the level counter for the
> > two pid namespaces.
> >
> >>
> >> And you can rewrite pidns_get_parent to use it. So you would instead be
> >>
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The DRAM refresh-interval is getting erroneously set to "1" on exiting
> from memory self-refreshing mode. The clobbered interval causes the
> "refresh request overflow timeout" error raised by the External Memory
> Controller on exiting from LP1 on
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The DRAM refresh-interval is getting erroneously set to "1" on exiting
> from memory self-refreshing mode. The clobbered interval causes the
> "refresh request overflow timeout" error raised by the External Memory
> Controller on exiting from LP1 on
>
> Decleare struct tpm_header that replaces struct tpm_input_header and
Typo
> struct tpm_output_header.
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 9 -
> drivers/char/tpm/tpm.h| 27
On 11/19/18 11:32 AM, Andrea Arcangeli wrote:
> The specs don't say if by making it immune from BTB mistraining, it
> also could prevent to mistrain the BTB in order to attack what's
> outside the SECCOMP jail. Probably it won't and I doubt we can rely on
> it even if some implementation could do
>
> Decleare struct tpm_header that replaces struct tpm_input_header and
Typo
> struct tpm_output_header.
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 9 -
> drivers/char/tpm/tpm.h| 27
On 11/19/18 11:32 AM, Andrea Arcangeli wrote:
> The specs don't say if by making it immune from BTB mistraining, it
> also could prevent to mistrain the BTB in order to attack what's
> outside the SECCOMP jail. Probably it won't and I doubt we can rely on
> it even if some implementation could do
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The memory interface configuration and re-calibration interval are left
> unassigned on resume from LP1 because these registers are shadowed and
> require latching after being adjusted.
>
> Signed-off-by: Dmitry Osipenko
> ---
>
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The memory interface configuration and re-calibration interval are left
> unassigned on resume from LP1 because these registers are shadowed and
> require latching after being adjusted.
>
> Signed-off-by: Dmitry Osipenko
> ---
>
Introduce mailbox controller driver for ZynqMP IPI(Inter-processor
interrupt) IP core.
As the device tree bindings have been updated. Do not have "Reviewed-by"
nor "Acked-by" in the dt-bindings commit.
v6:
- dts-binding, remove compatible property from IPI subnode
v5:
- fix check patch
Introduce mailbox controller driver for ZynqMP IPI(Inter-processor
interrupt) IP core.
As the device tree bindings have been updated. Do not have "Reviewed-by"
nor "Acked-by" in the dt-bindings commit.
v6:
- dts-binding, remove compatible property from IPI subnode
v5:
- fix check patch
Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
in ZynqMP SoC used for the communication between various processor
systems.
Signed-off-by: Wendy Liang
---
.../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 127 +
1 file changed, 127 insertions(+)
create
On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner wrote:
> That can be done without a loop by comparing the level counter for the
> two pid namespaces.
>
>>
>> And you can rewrite pidns_get_parent to use it. So you would instead be
>> doing:
>>
>> if (pidns_is_descendant(proc_pid_ns,
Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
in ZynqMP SoC used for the communication between various processor
systems.
Signed-off-by: Wendy Liang
---
.../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 127 +
1 file changed, 127 insertions(+)
create
On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner wrote:
> That can be done without a loop by comparing the level counter for the
> two pid namespaces.
>
>>
>> And you can rewrite pidns_get_parent to use it. So you would instead be
>> doing:
>>
>> if (pidns_is_descendant(proc_pid_ns,
On 19/11/2018 17:05, Dmitry Osipenko wrote:
> On 19.11.2018 18:42, Jon Hunter wrote:
>>
>> On 18/11/2018 22:06, Dmitry Osipenko wrote:
>>> On 30.08.2018 21:54, Dmitry Osipenko wrote:
Hello,
This patch series fixes couple bugs in the memory self-refresh code.
The EMC / MC
This patch is to introduce ZynqMP IPI mailbox controller driver
to use the ZynqMP IPI block as mailboxes.
Signed-off-by: Wendy Liang
---
drivers/mailbox/Kconfig| 9 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/zynqmp-ipi-mailbox.c | 762
On 19/11/2018 17:05, Dmitry Osipenko wrote:
> On 19.11.2018 18:42, Jon Hunter wrote:
>>
>> On 18/11/2018 22:06, Dmitry Osipenko wrote:
>>> On 30.08.2018 21:54, Dmitry Osipenko wrote:
Hello,
This patch series fixes couple bugs in the memory self-refresh code.
The EMC / MC
This patch is to introduce ZynqMP IPI mailbox controller driver
to use the ZynqMP IPI block as mailboxes.
Signed-off-by: Wendy Liang
---
drivers/mailbox/Kconfig| 9 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/zynqmp-ipi-mailbox.c | 762
On 2018-11-19, Christian Brauner wrote:
> On Tue, Nov 20, 2018 at 08:18:10AM +1100, Aleksa Sarai wrote:
> > On 2018-11-19, Christian Brauner wrote:
> > > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > > On 2018-11-19, Christian Brauner wrote:
> > > > > + if (info) {
> >
>
> The error logging for tpm2_commit_space() is in a wrong place. This commit
> moves it inside that function.
>
> Cc: James Bottomley
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 2 --
> drivers/char/tpm/tpm2-space.c| 9
On 2018-11-19, Christian Brauner wrote:
> On Tue, Nov 20, 2018 at 08:18:10AM +1100, Aleksa Sarai wrote:
> > On 2018-11-19, Christian Brauner wrote:
> > > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > > On 2018-11-19, Christian Brauner wrote:
> > > > > + if (info) {
> >
>
> The error logging for tpm2_commit_space() is in a wrong place. This commit
> moves it inside that function.
>
> Cc: James Bottomley
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 2 --
> drivers/char/tpm/tpm2-space.c| 9
On 2018-11-20, Aleksa Sarai wrote:
> On 2018-11-19, Christian Brauner wrote:
> > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > On 2018-11-19, Christian Brauner wrote:
> > > > + if (info) {
> > > > + ret = __copy_siginfo_from_user(sig, , info);
> > > > +
On 2018-11-20, Aleksa Sarai wrote:
> On 2018-11-19, Christian Brauner wrote:
> > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > On 2018-11-19, Christian Brauner wrote:
> > > > + if (info) {
> > > > + ret = __copy_siginfo_from_user(sig, , info);
> > > > +
On Tue, Nov 20, 2018 at 08:18:10AM +1100, Aleksa Sarai wrote:
> On 2018-11-19, Christian Brauner wrote:
> > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > On 2018-11-19, Christian Brauner wrote:
> > > > + if (info) {
> > > > + ret =
On Tue, Nov 20, 2018 at 08:18:10AM +1100, Aleksa Sarai wrote:
> On 2018-11-19, Christian Brauner wrote:
> > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > On 2018-11-19, Christian Brauner wrote:
> > > > + if (info) {
> > > > + ret =
On Tue, Nov 20, 2018 at 08:18:10AM +1100, Aleksa Sarai wrote:
> On 2018-11-19, Christian Brauner wrote:
> > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > On 2018-11-19, Christian Brauner wrote:
> > > > + if (info) {
> > > > + ret =
On Tue, Nov 20, 2018 at 08:18:10AM +1100, Aleksa Sarai wrote:
> On 2018-11-19, Christian Brauner wrote:
> > On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > > On 2018-11-19, Christian Brauner wrote:
> > > > + if (info) {
> > > > + ret =
From: liuzhongzhu
Query the queue information of the current NIC
such as BD size, queue header and tail pointer.
This patch adds support for debugfs command:
echo queue info 1 > cmd
it can print queue config information...
root@(none)# echo queue info 1 > cmd
hns3 :7d:00.0: queue info
From: liuzhongzhu
Query the queue information of the current NIC
such as BD size, queue header and tail pointer.
This patch adds support for debugfs command:
echo queue info 1 > cmd
it can print queue config information...
root@(none)# echo queue info 1 > cmd
hns3 :7d:00.0: queue info
Hello,
Sean Young wrote:
> When building BPF code using "clang -target bpf -c", clang does not
> define __linux__.
>
> To build BPF IR decoders the include linux/lirc.h is needed which
> includes linux/types.h. Currently this workaround is needed:
>
>
On 11/15/2018 4:47 PM, Bhupesh Sharma wrote:
> Adding 'page_offset_base' to the vmcoreinfo can be specially useful for
> live-debugging of a running kernel via user-space utilities
> like makedumpfile (see [1]).
I agree.
> Recently, I saw an issue with the 'makedumpfile' utility (see [2] for
>
Hello,
Sean Young wrote:
> When building BPF code using "clang -target bpf -c", clang does not
> define __linux__.
>
> To build BPF IR decoders the include linux/lirc.h is needed which
> includes linux/types.h. Currently this workaround is needed:
>
>
On 11/15/2018 4:47 PM, Bhupesh Sharma wrote:
> Adding 'page_offset_base' to the vmcoreinfo can be specially useful for
> live-debugging of a running kernel via user-space utilities
> like makedumpfile (see [1]).
I agree.
> Recently, I saw an issue with the 'makedumpfile' utility (see [2] for
>
On 2018-11-19, Christian Brauner wrote:
> On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > On 2018-11-19, Christian Brauner wrote:
> > > + if (info) {
> > > + ret = __copy_siginfo_from_user(sig, , info);
> > > + if (unlikely(ret))
> > > + goto
On 2018-11-19, Christian Brauner wrote:
> On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > On 2018-11-19, Christian Brauner wrote:
> > > + if (info) {
> > > + ret = __copy_siginfo_from_user(sig, , info);
> > > + if (unlikely(ret))
> > > + goto
On Mon, Nov 19, 2018 at 09:55:18PM +0100, Christian Brauner wrote:
> On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > On 2018-11-19, Christian Brauner wrote:
> > > + if (info) {
> > > + ret = __copy_siginfo_from_user(sig, , info);
> > > + if (unlikely(ret))
> > >
On Mon, Nov 19, 2018 at 09:55:18PM +0100, Christian Brauner wrote:
> On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> > On 2018-11-19, Christian Brauner wrote:
> > > + if (info) {
> > > + ret = __copy_siginfo_from_user(sig, , info);
> > > + if (unlikely(ret))
> > >
On Mon, 19 Nov 2018, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
>
> > > @@ -452,12 +542,6 @@ static void __init spectre_v2_select_mitigation(void)
> > > setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > > pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
Hi Christoph,
On Thu, Nov 15, 2018 at 08:05:32PM +0100, Christoph Hellwig wrote:
> There is no good reason to duplicate the PCI menu in every architecture.
> Instead provide a selectable HAVE_PCI symbol that indicates availability
> of PCI support, and a FORCE_PCI symbol to for PCI on and the
On Mon, 19 Nov 2018, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
>
> > > @@ -452,12 +542,6 @@ static void __init spectre_v2_select_mitigation(void)
> > > setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > > pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
Hi Christoph,
On Thu, Nov 15, 2018 at 08:05:32PM +0100, Christoph Hellwig wrote:
> There is no good reason to duplicate the PCI menu in every architecture.
> Instead provide a selectable HAVE_PCI symbol that indicates availability
> of PCI support, and a FORCE_PCI symbol to for PCI on and the
Hi Bartosz,
On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
> automatic base selection") broke the network support in legacy boot
> mode for da850-evm since we can no longer request the MDIO clock
Hi Bartosz,
On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
> automatic base selection") broke the network support in legacy boot
> mode for da850-evm since we can no longer request the MDIO clock
On Mon 19-11-18 12:34:09, Hugh Dickins wrote:
> On Mon, 19 Nov 2018, Michal Hocko wrote:
> > On Mon 19-11-18 15:10:16, Michal Hocko wrote:
> > [...]
> > > In other words. Why cannot we do the following?
> >
> > Baoquan, this is certainly not the right fix but I would be really
> > curious whether
On Mon 19-11-18 12:34:09, Hugh Dickins wrote:
> On Mon, 19 Nov 2018, Michal Hocko wrote:
> > On Mon 19-11-18 15:10:16, Michal Hocko wrote:
> > [...]
> > > In other words. Why cannot we do the following?
> >
> > Baoquan, this is certainly not the right fix but I would be really
> > curious whether
On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> > @@ -452,12 +542,6 @@ static void __init spectre_v2_select_mitigation(void)
> > setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
> > switch\n");
> >
> > - /* Initialize
On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> > @@ -452,12 +542,6 @@ static void __init spectre_v2_select_mitigation(void)
> > setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context
> > switch\n");
> >
> > - /* Initialize
On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> On 2018-11-19, Christian Brauner wrote:
> > + if (info) {
> > + ret = __copy_siginfo_from_user(sig, , info);
> > + if (unlikely(ret))
> > + goto err;
> > + /*
> > +* Not
On Tue, Nov 20, 2018 at 07:28:57AM +1100, Aleksa Sarai wrote:
> On 2018-11-19, Christian Brauner wrote:
> > + if (info) {
> > + ret = __copy_siginfo_from_user(sig, , info);
> > + if (unlikely(ret))
> > + goto err;
> > + /*
> > +* Not
On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
> IRQ numbering") the davinci GPIO driver fails to probe if we boot
> in legacy mode from any of the board files. Since the driver now
> expects
On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
> IRQ numbering") the davinci GPIO driver fails to probe if we boot
> in legacy mode from any of the board files. Since the driver now
> expects
On Mon, Aug 13, 2018 at 12:03:07PM +0530, Amit Nischal wrote:
> Add support for the graphics clock controller found on SDM845
> based devices. This would allow graphics drivers to probe and
> control their clocks.
>
> Signed-off-by: Amit Nischal
> ---
> drivers/clk/qcom/Kconfig| 9 +
>
On Mon, Aug 13, 2018 at 12:03:07PM +0530, Amit Nischal wrote:
> Add support for the graphics clock controller found on SDM845
> based devices. This would allow graphics drivers to probe and
> control their clocks.
>
> Signed-off-by: Amit Nischal
> ---
> drivers/clk/qcom/Kconfig| 9 +
>
On Mon, Nov 19, 2018 at 10:44:30AM -0800, Florian Fainelli wrote:
> On 11/15/18 5:16 PM, Guenter Roeck wrote:
> > On Thu, Nov 15, 2018 at 11:48:20AM -0800, Florian Fainelli wrote:
> >>
> >> OK, would you mind testing this below? It seems to me that 8250_of.c is
> >> incompatible with
On 11/19/2018 04:58 AM, Thomas Gleixner wrote:
>> +DECLARE_STATIC_KEY_TRUE(cpu_smt_enabled);
>
> And here it is declared unconditionally which allows code to use it despite
> CONFIG_HOTPLUG_SMT=n and subsequently breaks the build.
Will put this under #ifdef CONFIG_HOTPLUG_SMT
Tim
On Mon, Nov 19, 2018 at 10:44:30AM -0800, Florian Fainelli wrote:
> On 11/15/18 5:16 PM, Guenter Roeck wrote:
> > On Thu, Nov 15, 2018 at 11:48:20AM -0800, Florian Fainelli wrote:
> >>
> >> OK, would you mind testing this below? It seems to me that 8250_of.c is
> >> incompatible with
On 11/19/2018 04:58 AM, Thomas Gleixner wrote:
>> +DECLARE_STATIC_KEY_TRUE(cpu_smt_enabled);
>
> And here it is declared unconditionally which allows code to use it despite
> CONFIG_HOTPLUG_SMT=n and subsequently breaks the build.
Will put this under #ifdef CONFIG_HOTPLUG_SMT
Tim
On November 19, 2018 12:40:25 PM PST, Borislav Petkov wrote:
>On Mon, Nov 19, 2018 at 12:17:35PM -0800, H. Peter Anvin wrote:
>> On 11/19/18 11:52 AM, Andy Lutomirski wrote:
>> >
>> > I thought I benchmarked this on Intel at some point and found the
>> > LFENCE;RDTSC variant to be slightly
On November 19, 2018 12:40:25 PM PST, Borislav Petkov wrote:
>On Mon, Nov 19, 2018 at 12:17:35PM -0800, H. Peter Anvin wrote:
>> On 11/19/18 11:52 AM, Andy Lutomirski wrote:
>> >
>> > I thought I benchmarked this on Intel at some point and found the
>> > LFENCE;RDTSC variant to be slightly
On Sun, Nov 11, 2018 at 12:59:43PM +0800, Leo Yan wrote:
> When an exception packet comes, it contains the info for exception
> number; the exception number indicates the exception types, so from it
> we can know if the exception is taken for interrupt, system call or
> other traps, etc. But
On Sun, Nov 11, 2018 at 12:59:43PM +0800, Leo Yan wrote:
> When an exception packet comes, it contains the info for exception
> number; the exception number indicates the exception types, so from it
> we can know if the exception is taken for interrupt, system call or
> other traps, etc. But
On Fri, 16 Nov 2018, Tim Chen wrote:
> +static const struct {
> + const char *option;
> + enum spectre_v2_app2app_mitigation_cmd cmd;
> + bool secure;
> +} app2app_options[] = {
> + { "off",SPECTRE_V2_APP2APP_CMD_NONE, false },
> + { "lite",
On Fri, 16 Nov 2018, Tim Chen wrote:
> +static const struct {
> + const char *option;
> + enum spectre_v2_app2app_mitigation_cmd cmd;
> + bool secure;
> +} app2app_options[] = {
> + { "off",SPECTRE_V2_APP2APP_CMD_NONE, false },
> + { "lite",
On Mon, Aug 13, 2018 at 12:03:03PM +0530, Amit Nischal wrote:
> Changes in v3:
> * Modified the determine_rate() op to use the min/max rate range
> to round the requested rate within the set_rate range. With this,
> requested set rate will always stay within the limits.
>
> Changes in v2:
>
On Mon, Aug 13, 2018 at 12:03:03PM +0530, Amit Nischal wrote:
> Changes in v3:
> * Modified the determine_rate() op to use the min/max rate range
> to round the requested rate within the set_rate range. With this,
> requested set rate will always stay within the limits.
>
> Changes in v2:
>
On Mon, Nov 19, 2018 at 12:17:35PM -0800, H. Peter Anvin wrote:
> On 11/19/18 11:52 AM, Andy Lutomirski wrote:
> >
> > I thought I benchmarked this on Intel at some point and found the
> > LFENCE;RDTSC variant to be slightly faster. But I believe you, so:
> >
> > Acked-by: Andy Lutomirski
> >
On Mon, Nov 19, 2018 at 12:17:35PM -0800, H. Peter Anvin wrote:
> On 11/19/18 11:52 AM, Andy Lutomirski wrote:
> >
> > I thought I benchmarked this on Intel at some point and found the
> > LFENCE;RDTSC variant to be slightly faster. But I believe you, so:
> >
> > Acked-by: Andy Lutomirski
> >
On Mon, 19 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 15:10:16, Michal Hocko wrote:
> [...]
> > In other words. Why cannot we do the following?
>
> Baoquan, this is certainly not the right fix but I would be really
> curious whether it makes the problem go away.
>
> > diff --git
On Mon, 19 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 15:10:16, Michal Hocko wrote:
> [...]
> > In other words. Why cannot we do the following?
>
> Baoquan, this is certainly not the right fix but I would be really
> curious whether it makes the problem go away.
>
> > diff --git
On 2018-11-19, Christian Brauner wrote:
> + if (info) {
> + ret = __copy_siginfo_from_user(sig, , info);
> + if (unlikely(ret))
> + goto err;
> + /*
> + * Not even root can pretend to send signals from the kernel.
> +
On 2018-11-19, Christian Brauner wrote:
> + if (info) {
> + ret = __copy_siginfo_from_user(sig, , info);
> + if (unlikely(ret))
> + goto err;
> + /*
> + * Not even root can pretend to send signals from the kernel.
> +
On 2018-11-19, Daniel Colascione wrote:
> > I wonder how fast it would be holding a pid with another open()ed fd.
> > And then you need to read comm (or how you filter whom to kill).
> > It seems to me that procfs will be even slower with this safe-way.
> > But I might misunderstand the idea,
On Fri, 16 Nov 2018, Tim Chen wrote:
> +static enum spectre_v2_app2app_mitigation_cmd __init
> + spectre_v2_parse_app2app_cmdline(enum spectre_v2_mitigation_cmd
> v2_cmd)
> +{
> + enum spectre_v2_app2app_mitigation_cmd cmd;
> + char arg[20];
> + int ret, i;
> +
> + if
On 2018-11-19, Daniel Colascione wrote:
> > I wonder how fast it would be holding a pid with another open()ed fd.
> > And then you need to read comm (or how you filter whom to kill).
> > It seems to me that procfs will be even slower with this safe-way.
> > But I might misunderstand the idea,
On Fri, 16 Nov 2018, Tim Chen wrote:
> +static enum spectre_v2_app2app_mitigation_cmd __init
> + spectre_v2_parse_app2app_cmdline(enum spectre_v2_mitigation_cmd
> v2_cmd)
> +{
> + enum spectre_v2_app2app_mitigation_cmd cmd;
> + char arg[20];
> + int ret, i;
> +
> + if
401 - 500 of 3448 matches
Mail list logo
