On Wed, Oct 10, 2018 at 05:03:33PM -0600, Logan Gunthorpe wrote:
>
>
> On 2018-10-10 2:19 p.m., Bjorn Helgaas wrote:
> > I added the reviewed-by tags from Christoph, Jens' ack on the blkdev.h
> > change, and applied these to pci/peer-to-peer with the intent of
> > merging these for v4.20.
> >
>
On Wed, Oct 10, 2018 at 05:03:33PM -0600, Logan Gunthorpe wrote:
>
>
> On 2018-10-10 2:19 p.m., Bjorn Helgaas wrote:
> > I added the reviewed-by tags from Christoph, Jens' ack on the blkdev.h
> > change, and applied these to pci/peer-to-peer with the intent of
> > merging these for v4.20.
> >
>
Hi Linus,
After merging the pinctrl tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/pinctrl/bcm/pinctrl-ns.c: In function 'ns_pinctrl_probe':
drivers/pinctrl/bcm/pinctrl-ns.c:288:29: warning: cast from pointer to integer
of different size
Hi Linus,
After merging the pinctrl tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/pinctrl/bcm/pinctrl-ns.c: In function 'ns_pinctrl_probe':
drivers/pinctrl/bcm/pinctrl-ns.c:288:29: warning: cast from pointer to integer
of different size
On 10/10/2018 03:09 PM, Michal Hocko wrote:
> On Wed 10-10-18 08:39:22, Anshuman Khandual wrote:
> [...]
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 9df1d59..4bcbf1e 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -504,6 +504,16 @@
On 10/10/2018 03:09 PM, Michal Hocko wrote:
> On Wed 10-10-18 08:39:22, Anshuman Khandual wrote:
> [...]
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 9df1d59..4bcbf1e 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -504,6 +504,16 @@
Em Wed, 10 Oct 2018 17:00:01 -0700
James Bottomley escreveu:
> On Wed, 2018-10-10 at 18:23 -0500, Eric W. Biederman wrote:
> > James Bottomley writes:
> >
> > > Resend to show accumulated tags and also to add a third patch
> > > listing the TAB as the reporting point as a few people seem to
Em Wed, 10 Oct 2018 17:00:01 -0700
James Bottomley escreveu:
> On Wed, 2018-10-10 at 18:23 -0500, Eric W. Biederman wrote:
> > James Bottomley writes:
> >
> > > Resend to show accumulated tags and also to add a third patch
> > > listing the TAB as the reporting point as a few people seem to
On Wed, Oct 10, 2018 at 02:13:22PM -0700, Andy Lutomirski wrote:
> On Wed, Oct 10, 2018 at 11:17 AM Josh Poimboeuf wrote:
> >
> > On Wed, Oct 10, 2018 at 01:16:05PM -0500, Josh Poimboeuf wrote:
> > > On Wed, Oct 10, 2018 at 11:03:43AM -0700, Andy Lutomirski wrote:
> > > > > +#define
On Wed, Oct 10, 2018 at 02:13:22PM -0700, Andy Lutomirski wrote:
> On Wed, Oct 10, 2018 at 11:17 AM Josh Poimboeuf wrote:
> >
> > On Wed, Oct 10, 2018 at 01:16:05PM -0500, Josh Poimboeuf wrote:
> > > On Wed, Oct 10, 2018 at 11:03:43AM -0700, Andy Lutomirski wrote:
> > > > > +#define
Hi Jacek,
On 11 October 2018 at 04:43, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> I've finally managed to test this patch and it turned out
> that this implementation doesn't prevent what I had concerns
> about, i.e. setting intervals less then 50ms.
>
> What user needs to do to achieve that is
Hi Jacek,
On 11 October 2018 at 04:43, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> I've finally managed to test this patch and it turned out
> that this implementation doesn't prevent what I had concerns
> about, i.e. setting intervals less then 50ms.
>
> What user needs to do to achieve that is
I think the issue is that using vmx instructions after vmx off. The
scenario is:
1. kernel is rebooting and vmx is turned off by notification handler
kvm_reboot(),
and 'kvm_rebooting' is set.
2. But there is a pending KVM_CREATE_VCPU ioctl which will invoke
vmcs_clear()->
I think the issue is that using vmx instructions after vmx off. The
scenario is:
1. kernel is rebooting and vmx is turned off by notification handler
kvm_reboot(),
and 'kvm_rebooting' is set.
2. But there is a pending KVM_CREATE_VCPU ioctl which will invoke
vmcs_clear()->
Andes FPU hardware does not support denormalized number handling.
>From Andes FPU spec, FPU generates a denorm input to require kernel
to deal with this instrution operation when encountering a denormalized
operand. Hence an emulator for nds32 FPU ISA in kernel is needed to
satisfy the
Andes FPU hardware does not support denormalized number handling.
>From Andes FPU spec, FPU generates a denorm input to require kernel
to deal with this instrution operation when encountering a denormalized
operand. Hence an emulator for nds32 FPU ISA in kernel is needed to
satisfy the
This modification is quoted from glibc 'commit <
sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.c: Moved to>
(fe0b1e854ad32a69b260)'
Signed-off-by: Vincent Chen
---
include/math-emu/op-2.h | 97 ++
1 files changed, 46 insertions(+), 51
_FP_ROUND_ZERO is defined as 0 and used as a statemente in macro
_FP_ROUND. This generates "error: statement with no effect
[-Werror=unused-value]" from gcc. Defining _FP_ROUND_ZERO as (void)0 to
fix it.
This modification is quoted from glibc 'commit
(8ed1e7d5894000c155acbd06f)'
Signed-off-by:
For current nds32 FPU, arithmetic for denormalized number is unsupported.
When nds32 FPU finds the result of floating pointer instruction is a
denormlized number, nds32 FPU thinks an underflow condition is happened
and round the result to an appropriate number. It may cause precision
loss. This
This modification is quoted from glibc 'commit <
sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.c: Moved to>
(fe0b1e854ad32a69b260)'
Signed-off-by: Vincent Chen
---
include/math-emu/op-2.h | 97 ++
1 files changed, 46 insertions(+), 51
_FP_ROUND_ZERO is defined as 0 and used as a statemente in macro
_FP_ROUND. This generates "error: statement with no effect
[-Werror=unused-value]" from gcc. Defining _FP_ROUND_ZERO as (void)0 to
fix it.
This modification is quoted from glibc 'commit
(8ed1e7d5894000c155acbd06f)'
Signed-off-by:
For current nds32 FPU, arithmetic for denormalized number is unsupported.
When nds32 FPU finds the result of floating pointer instruction is a
denormlized number, nds32 FPU thinks an underflow condition is happened
and round the result to an appropriate number. It may cause precision
loss. This
This patchset contains basic components for nds32 FPU support such as
exception handler and context switch for FPU register. Lazy FPU is
supported in nds32 by default. User can through CONFIG_UNLZAY_FPU to
disable this feature. In addition, a floating point emulator is needed to
deal with all
This commit contains basic components for nds32 FPU support such as
FPU exception handler and context switch for FPU register.
Signed-off-by: Vincent Chen
---
arch/nds32/Kconfig |1 +
arch/nds32/Kconfig.cpu | 22 +++
arch/nds32/Makefile
This patchset contains basic components for nds32 FPU support such as
exception handler and context switch for FPU register. Lazy FPU is
supported in nds32 by default. User can through CONFIG_UNLZAY_FPU to
disable this feature. In addition, a floating point emulator is needed to
deal with all
This commit contains basic components for nds32 FPU support such as
FPU exception handler and context switch for FPU register.
Signed-off-by: Vincent Chen
---
arch/nds32/Kconfig |1 +
arch/nds32/Kconfig.cpu | 22 +++
arch/nds32/Makefile
On Wed, Oct 10, 2018 at 11:51 PM Kees Cook wrote:
>
> On Wed, Oct 10, 2018 at 12:03 AM, Miguel Ojeda
> wrote:
> > On Wed, Oct 10, 2018 at 8:12 AM Joel Stanley wrote:
> >>
> >> On Thu, 27 Sep 2018 at 05:07, Kees Cook wrote:
> >> >
> >> > Yeah, that's what I'd linked to in the patchwork URL.
On Wed, Oct 10, 2018 at 11:51 PM Kees Cook wrote:
>
> On Wed, Oct 10, 2018 at 12:03 AM, Miguel Ojeda
> wrote:
> > On Wed, Oct 10, 2018 at 8:12 AM Joel Stanley wrote:
> >>
> >> On Thu, 27 Sep 2018 at 05:07, Kees Cook wrote:
> >> >
> >> > Yeah, that's what I'd linked to in the patchwork URL.
Em Wed, 10 Oct 2018 13:09:40 -0700
James Bottomley escreveu:
> Significant concern has been expressed about the responsibilities outlined in
> the enforcement clause of the new code of conduct. Since there is concern
> that this becomes binding on the release of the 4.19 kernel, strip the
>
Em Wed, 10 Oct 2018 13:09:40 -0700
James Bottomley escreveu:
> Significant concern has been expressed about the responsibilities outlined in
> the enforcement clause of the new code of conduct. Since there is concern
> that this becomes binding on the release of the 4.19 kernel, strip the
>
Em Wed, 10 Oct 2018 13:08:35 -0700
James Bottomley escreveu:
> The current code of conduct has an ambiguity in the it considers publishing
> private information such as email addresses unacceptable behaviour. Since
> the Linux kernel collects and publishes email addresses as part of the patch
>
Em Wed, 10 Oct 2018 13:08:35 -0700
James Bottomley escreveu:
> The current code of conduct has an ambiguity in the it considers publishing
> private information such as email addresses unacceptable behaviour. Since
> the Linux kernel collects and publishes email addresses as part of the patch
>
Em Wed, 10 Oct 2018 21:13:13 +0100
Alan Cox escreveu:
> On Wed, 10 Oct 2018 13:10:30 -0700
> > +appropriate to the circumstances. The TAB is obligated to maintain
> > +confidentiality with regard to the reporter of an incident.
>
> I would add (except where required by law.)
With the
Em Wed, 10 Oct 2018 21:13:13 +0100
Alan Cox escreveu:
> On Wed, 10 Oct 2018 13:10:30 -0700
> > +appropriate to the circumstances. The TAB is obligated to maintain
> > +confidentiality with regard to the reporter of an incident.
>
> I would add (except where required by law.)
With the
Tisztelt felhasználó,
Postaládája túllépte a szokásos 100 MB tárolási korlátot, nem lesz képes
fogadni vagy küldeni e-mailt, amíg meg nem növeli a postaláda kvótáját. A levél
kvótájának növeléséhez kattintson az alábbi hivatkozásra, és töltse ki a
szükséges adatokat a postaláda-kvóta
Tisztelt felhasználó,
Postaládája túllépte a szokásos 100 MB tárolási korlátot, nem lesz képes
fogadni vagy küldeni e-mailt, amíg meg nem növeli a postaláda kvótáját. A levél
kvótájának növeléséhez kattintson az alábbi hivatkozásra, és töltse ki a
szükséges adatokat a postaláda-kvóta
Hi Pavel,
On 11 October 2018 at 00:00, Pavel Machek wrote:
> Hi!
>
> [Oops. I wrote this but forgot to send it? Anyway.. I guess it is
> redundant now.]
>
>> > +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> > @@ -0,0 +1,76 @@
>> > +What: /sys/class/leds//pattern
Hi all,
On Wed, 10 Oct 2018 13:22:24 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the kvm-ppc tree got a conflict in:
>
> include/uapi/linux/kvm.h
>
> between commit:
>
> 233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM")
>
> from the kvm-arm
Hi Pavel,
On 11 October 2018 at 00:00, Pavel Machek wrote:
> Hi!
>
> [Oops. I wrote this but forgot to send it? Anyway.. I guess it is
> redundant now.]
>
>> > +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> > @@ -0,0 +1,76 @@
>> > +What: /sys/class/leds//pattern
Hi all,
On Wed, 10 Oct 2018 13:22:24 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the kvm-ppc tree got a conflict in:
>
> include/uapi/linux/kvm.h
>
> between commit:
>
> 233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM")
>
> from the kvm-arm
In preparation for runtime randomization of the zone lists, take all
(well, most of) the list_*() functions in the buddy allocator and put
them in helper functions. Provide a common control point for injecting
additional behavior when freeing pages.
Cc: Michal Hocko
Cc: Dave Hansen
In preparation for runtime randomization of the zone lists, take all
(well, most of) the list_*() functions in the buddy allocator and put
them in helper functions. Provide a common control point for injecting
additional behavior when freeing pages.
Cc: Michal Hocko
Cc: Dave Hansen
On Thu, 4 Oct 2018 16:55:47 +
Song Liu wrote:
> > Works for me,
> >
> > Acked-by: Peter Zijlstra (Intel)
>
> Thanks Peter!
>
> Steven, could you please test/apply this?
Sorry for the late reply. Yeah, I just pulled this into my queue and
I've started running tests on it.
Thanks
John,
> However it does block us in future from enabling SCSI MQ in the driver.
We're going to remove the legacy I/O path so I'm not particularly keen
on merging something that's going in the opposite direction.
> This is because the IPTT index must be a unique value per HBA. However,
> if we
On Thu, 4 Oct 2018 16:55:47 +
Song Liu wrote:
> > Works for me,
> >
> > Acked-by: Peter Zijlstra (Intel)
>
> Thanks Peter!
>
> Steven, could you please test/apply this?
Sorry for the late reply. Yeah, I just pulled this into my queue and
I've started running tests on it.
Thanks
John,
> However it does block us in future from enabling SCSI MQ in the driver.
We're going to remove the legacy I/O path so I'm not particularly keen
on merging something that's going in the opposite direction.
> This is because the IPTT index must be a unique value per HBA. However,
> if we
Some data exfiltration and return-oriented-programming attacks rely on
the ability to infer the location of sensitive data objects. The kernel
page allocator, especially early in system boot, has predictable
first-in-first out behavior for physical pages. Pages are freed in
physical address order
Some data exfiltration and return-oriented-programming attacks rely on
the ability to infer the location of sensitive data objects. The kernel
page allocator, especially early in system boot, has predictable
first-in-first out behavior for physical pages. Pages are freed in
physical address order
When freeing a page with an order >= shuffle_page_order randomly select
the front or back of the list for insertion.
While the mm tries to defragment physical pages into huge pages this can
tend to make the page allocator more predictable over time. Inject the
front-back randomness to preserve
When freeing a page with an order >= shuffle_page_order randomly select
the front or back of the list for insertion.
While the mm tries to defragment physical pages into huge pages this can
tend to make the page allocator more predictable over time. Inject the
front-back randomness to preserve
Changes since v3 [1]:
* Replace runtime 'shuffle_page_order' parameter with a compile-time
CONFIG_SHUFFLE_PAGE_ALLOCATOR on/off switch and a
CONFIG_SHUFFLE_PAGE_ORDER if a distro decides that the default 4MB
shuffling boundary is not sufficient. Administrators will not be
burdened with
Changes since v3 [1]:
* Replace runtime 'shuffle_page_order' parameter with a compile-time
CONFIG_SHUFFLE_PAGE_ALLOCATOR on/off switch and a
CONFIG_SHUFFLE_PAGE_ORDER if a distro decides that the default 4MB
shuffling boundary is not sufficient. Administrators will not be
burdened with
On 10/11/2018 04:25 AM, Shuah Khan wrote:
On 10/07/2018 08:32 AM, Li Zhijian wrote:
ping
On 09/21/2018 06:00 PM, Li Zhijian wrote:
lizhijian@haswell-OptiPlex-9020:/home/lizj/linux/tools/testing/selftests$ make
[...snip...]
make ARCH=x86 CROSS_COMPILE= -C ../../../gpio
make[2]: Entering
On 10/11/2018 04:25 AM, Shuah Khan wrote:
On 10/07/2018 08:32 AM, Li Zhijian wrote:
ping
On 09/21/2018 06:00 PM, Li Zhijian wrote:
lizhijian@haswell-OptiPlex-9020:/home/lizj/linux/tools/testing/selftests$ make
[...snip...]
make ARCH=x86 CROSS_COMPILE= -C ../../../gpio
make[2]: Entering
On (10/10/18 22:10), Tetsuo Handa wrote:
> >> I've found at least 1 place that uses DEFAULT_RATELIMIT_INTERVAL*10:
> >> https://elixir.bootlin.com/linux/latest/source/fs/btrfs/extent-tree.c#L8365
> >> Probably we need something similar here.
>
> Since printk() is a significantly CPU consuming
On (10/10/18 22:10), Tetsuo Handa wrote:
> >> I've found at least 1 place that uses DEFAULT_RATELIMIT_INTERVAL*10:
> >> https://elixir.bootlin.com/linux/latest/source/fs/btrfs/extent-tree.c#L8365
> >> Probably we need something similar here.
>
> Since printk() is a significantly CPU consuming
ebied...@xmission.com (Eric W. Biederman) writes:
> Sean Christopherson writes:
>
>> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
>>> ebied...@xmission.com (Eric W. Biederman) writes:
>>>
>>> > So I am flummoxed. I am reading through the code and I don't see
>>> >
ebied...@xmission.com (Eric W. Biederman) writes:
> Sean Christopherson writes:
>
>> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
>>> ebied...@xmission.com (Eric W. Biederman) writes:
>>>
>>> > So I am flummoxed. I am reading through the code and I don't see
>>> >
Sean Christopherson writes:
> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> > So I am flummoxed. I am reading through the code and I don't see
>> > anything that could trigger this, and when I ran the supplied
Sean Christopherson writes:
> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> > So I am flummoxed. I am reading through the code and I don't see
>> > anything that could trigger this, and when I ran the supplied
On Wed, Oct 10, 2018 at 5:46 PM, Joel Fernandes wrote:
> On Wed, Oct 10, 2018 at 01:00:11PM +0300, Kirill A. Shutemov wrote:
[...]
>>
>> My worry is that some architecture has to allocate page table differently
>> depending on virtual address (due to aliasing or something). Original page
>> table
On Wed, Oct 10, 2018 at 5:46 PM, Joel Fernandes wrote:
> On Wed, Oct 10, 2018 at 01:00:11PM +0300, Kirill A. Shutemov wrote:
[...]
>>
>> My worry is that some architecture has to allocate page table differently
>> depending on virtual address (due to aliasing or something). Original page
>> table
Hi all,
On Thu, 6 Sep 2018 12:49:39 +0200 Peter Oberparleiter
wrote:
>
> On 28.08.2018 02:43, Masami Hiramatsu wrote:
> > I recently added a gcov profiling for ftrace, following
> > Documentation/dev-tools/gcov.rst.
> > 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
>
Hi all,
On Thu, 6 Sep 2018 12:49:39 +0200 Peter Oberparleiter
wrote:
>
> On 28.08.2018 02:43, Masami Hiramatsu wrote:
> > I recently added a gcov profiling for ftrace, following
> > Documentation/dev-tools/gcov.rst.
> > 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
>
Three avenues to rescind GPLv2 property. RAP strategy added.
Here's a case in NY where a Software distributor agreement violated New
York's Rule Against Perpetuities
McAllister Software Systems, Inc. v. Henry Schein, Inc., No. 06-0093,
2008 WL 922328 (E.D. Mo. April 2, 2008)
So we see that
Three avenues to rescind GPLv2 property. RAP strategy added.
Here's a case in NY where a Software distributor agreement violated New
York's Rule Against Perpetuities
McAllister Software Systems, Inc. v. Henry Schein, Inc., No. 06-0093,
2008 WL 922328 (E.D. Mo. April 2, 2008)
So we see that
On Wed, Oct 10, 2018 at 01:00:11PM +0300, Kirill A. Shutemov wrote:
> On Tue, Oct 09, 2018 at 04:04:47PM -0700, Joel Fernandes wrote:
> > On Wed, Oct 10, 2018 at 01:02:22AM +0300, Kirill A. Shutemov wrote:
> > > On Tue, Oct 09, 2018 at 01:14:00PM -0700, Joel Fernandes (Google) wrote:
> > > >
On Wed, Oct 10, 2018 at 01:00:11PM +0300, Kirill A. Shutemov wrote:
> On Tue, Oct 09, 2018 at 04:04:47PM -0700, Joel Fernandes wrote:
> > On Wed, Oct 10, 2018 at 01:02:22AM +0300, Kirill A. Shutemov wrote:
> > > On Tue, Oct 09, 2018 at 01:14:00PM -0700, Joel Fernandes (Google) wrote:
> > > >
Three avenues to rescind GPLv2 property. RAP strategy added.
Here's a case in NY where a Software distributor agreement violated New
York's Rule Against Perpetuities
McAllister Software Systems, Inc. v. Henry Schein, Inc., No. 06-0093,
2008 WL 922328 (E.D. Mo. April 2, 2008)
So we see that
Three avenues to rescind GPLv2 property. RAP strategy added.
Here's a case in NY where a Software distributor agreement violated New
York's Rule Against Perpetuities
McAllister Software Systems, Inc. v. Henry Schein, Inc., No. 06-0093,
2008 WL 922328 (E.D. Mo. April 2, 2008)
So we see that
Here's a case in NY where a Software distributor agreement violated New
York's Rule Against Perpetuities
McAllister Software Systems, Inc. v. Henry Schein, Inc., No. 06-0093,
2008 WL 922328 (E.D. Mo. April 2, 2008)
So we see that atleast one court in an important* jurisdiction is
applying the
Here's a case in NY where a Software distributor agreement violated New
York's Rule Against Perpetuities
McAllister Software Systems, Inc. v. Henry Schein, Inc., No. 06-0093,
2008 WL 922328 (E.D. Mo. April 2, 2008)
So we see that atleast one court in an important* jurisdiction is
applying the
While looking at native_sched_clock() disassembly I had
the surprise to see the compiler (gcc 7.3 here) had
optimized out the loop, meaning the code is broken.
Using the documented and approved API not only fixes the bug,
it also makes the code more readable.
Replacing five this_cpu_read() by
While looking at native_sched_clock() disassembly I had
the surprise to see the compiler (gcc 7.3 here) had
optimized out the loop, meaning the code is broken.
Using the documented and approved API not only fixes the bug,
it also makes the code more readable.
Replacing five this_cpu_read() by
On Wed, Oct 10, 2018 at 04:41:48PM -0700, Sean Christopherson wrote:
> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
> > ebied...@xmission.com (Eric W. Biederman) writes:
> >
> > > So I am flummoxed. I am reading through the code and I don't see
> > > anything that could
On Wed, Oct 10, 2018 at 04:41:48PM -0700, Sean Christopherson wrote:
> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
> > ebied...@xmission.com (Eric W. Biederman) writes:
> >
> > > So I am flummoxed. I am reading through the code and I don't see
> > > anything that could
QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on
domain can wakeup the SoC, when interrupts and GPIOs are routed to its
interrupt controller. Only select GPIOs that are deemed wakeup capable
are routed to specific PDC pins. During low power state, the pinmux
interrupt
Hi all,
This is a second attempt at enabling wakeup using GPIO IRQs. On the QCOM
SDM845i SoC, even when the TLMM gpiochip is powered off the the PDC always-on
interrupt controller can sense the GPIO interrupt as a signal, wakeup the
interrupt and replay the interrupt at the GIC.
Since, the
Hi all,
This is a second attempt at enabling wakeup using GPIO IRQs. On the QCOM
SDM845i SoC, even when the TLMM gpiochip is powered off the the PDC always-on
interrupt controller can sense the GPIO interrupt as a signal, wakeup the
interrupt and replay the interrupt at the GIC.
Since, the
QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on
domain can wakeup the SoC, when interrupts and GPIOs are routed to its
interrupt controller. Only select GPIOs that are deemed wakeup capable
are routed to specific PDC pins. During low power state, the pinmux
interrupt
On Fri, 05 Oct 2018 09:16:42 PDT (-0700), log...@deltatee.com wrote:
This patch implements sparsemem support for risc-v which helps pave the
way for memory hotplug and eventually P2P support.
We introduce Kconfig options for virtual and physical address bits which
are used to calculate the size
On Fri, 05 Oct 2018 09:16:42 PDT (-0700), log...@deltatee.com wrote:
This patch implements sparsemem support for risc-v which helps pave the
way for memory hotplug and eventually P2P support.
We introduce Kconfig options for virtual and physical address bits which
are used to calculate the size
On Mon, 8 Oct 2018 08:32:28 -0600 Jonathan Corbet wrote:
> On Mon, 8 Oct 2018 10:38:29 +0200
> David Hildenbrand wrote:
>
> > > I can do the renaming and add the patch
> > >
> > > "memory-hotplug.txt: add some details about locking internals"
> > >
> > > on top of the jc_docs tree.
> > >
On Mon, 8 Oct 2018 08:32:28 -0600 Jonathan Corbet wrote:
> On Mon, 8 Oct 2018 10:38:29 +0200
> David Hildenbrand wrote:
>
> > > I can do the renaming and add the patch
> > >
> > > "memory-hotplug.txt: add some details about locking internals"
> > >
> > > on top of the jc_docs tree.
> > >
On Wed, Oct 10, 2018 at 1:48 AM Michal Hocko wrote:
>
> On Tue 09-10-18 10:34:55, Dan Williams wrote:
> > On Tue, Oct 9, 2018 at 4:28 AM Michal Hocko wrote:
> > >
> > > On Thu 04-10-18 09:44:35, Dan Williams wrote:
> > > > Hi Michal,
> > > >
> > > > On Thu, Oct 4, 2018 at 12:53 AM Michal Hocko
On Wed, Oct 10, 2018 at 1:48 AM Michal Hocko wrote:
>
> On Tue 09-10-18 10:34:55, Dan Williams wrote:
> > On Tue, Oct 9, 2018 at 4:28 AM Michal Hocko wrote:
> > >
> > > On Thu 04-10-18 09:44:35, Dan Williams wrote:
> > > > Hi Michal,
> > > >
> > > > On Thu, Oct 4, 2018 at 12:53 AM Michal Hocko
On 11.10.2018 00:49, Chris Clayton wrote:
>> Now, knowing the "right" value you can experiment with what rtl_init_rxcfg()
>> writes (under the "default:" label for your NIC model).
>>
>
> This might be more interesting. Through a combination of viewing the output
> from pr_notice() and the
On 11.10.2018 00:49, Chris Clayton wrote:
>> Now, knowing the "right" value you can experiment with what rtl_init_rxcfg()
>> writes (under the "default:" label for your NIC model).
>>
>
> This might be more interesting. Through a combination of viewing the output
> from pr_notice() and the
On Wed, Oct 10, 2018 at 01:00:17PM -0700, Stephen Boyd wrote:
> This irq handler is always reading bytes from the device into a
> kmalloced buffer, so it's safe to mark this transaction as DMA safe.
> This avoids bouncing the buffer when an i2c controller decides to use
> DMA for a transaction.
>
Hi,
I was following the Coscheduling patch discussion on lkml and Peter
mentioned he had a patch series. I found the following on github.
https://github.com/pdxChen/gang/commits/sched_1.23-loadbal
I would like to test this with KVMs. Are the commits from 38d5acb to
f019876 sufficient? Also
On Wed, Oct 10, 2018 at 01:00:17PM -0700, Stephen Boyd wrote:
> This irq handler is always reading bytes from the device into a
> kmalloced buffer, so it's safe to mark this transaction as DMA safe.
> This avoids bouncing the buffer when an i2c controller decides to use
> DMA for a transaction.
>
Hi,
I was following the Coscheduling patch discussion on lkml and Peter
mentioned he had a patch series. I found the following on github.
https://github.com/pdxChen/gang/commits/sched_1.23-loadbal
I would like to test this with KVMs. Are the commits from 38d5acb to
f019876 sufficient? Also
On Wed, 2018-10-10 at 18:23 -0500, Eric W. Biederman wrote:
> James Bottomley writes:
>
> > Resend to show accumulated tags and also to add a third patch
> > listing the TAB as the reporting point as a few people seem to
> > want. If it gets the same level of support, I'll send it in with
> >
On Wed, 2018-10-10 at 18:23 -0500, Eric W. Biederman wrote:
> James Bottomley writes:
>
> > Resend to show accumulated tags and also to add a third patch
> > listing the TAB as the reporting point as a few people seem to
> > want. If it gets the same level of support, I'll send it in with
> >
Hi Greg,
Can you please pull the XFS update from the tag listed below? This
contains the fix for the clone_file_range data corruption issue I
mentioned in my -rc6 pull request (zero post-eof blocks), as well as
fixes for several other equally serious problems we found while
auditing the
Hi Greg,
Can you please pull the XFS update from the tag listed below? This
contains the fix for the clone_file_range data corruption issue I
mentioned in my -rc6 pull request (zero post-eof blocks), as well as
fixes for several other equally serious problems we found while
auditing the
On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> > So I am flummoxed. I am reading through the code and I don't see
> > anything that could trigger this, and when I ran the supplied reproducer
> > it did not reproduce for
On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> > So I am flummoxed. I am reading through the code and I don't see
> > anything that could trigger this, and when I ran the supplied reproducer
> > it did not reproduce for
On Tue, 9 Oct 2018 17:42:09 -0700 John Hubbard wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap way of detecting
> > this bug at
On Tue, 9 Oct 2018 17:42:09 -0700 John Hubbard wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap way of detecting
> > this bug at
101 - 200 of 1504 matches
Mail list logo
