Update the documentation to use interrupts-extended format for
specifying the TLMM summary IRQ line that is requested from GIC and the
PDC interrupts corresponding to the wakeup capable GPIOs.
Update the example to show PDC interrupts for the wakeup capable GPIOs
for SDM845.
Cc:
Enable TLMM IRQs to be sensed by PDC when we enter suspend. It is
possible that the TLMM may be powered off and not detect GPIOs that are
configured as wake up interrupts. By hooking into suspend callbacks, we
allow PDC IRQs to take over and wake up the system if wakeup interrupts
are triggered.
Update the documentation to use interrupts-extended format for
specifying the TLMM summary IRQ line that is requested from GIC and the
PDC interrupts corresponding to the wakeup capable GPIOs.
Update the example to show PDC interrupts for the wakeup capable GPIOs
for SDM845.
Cc:
Enable TLMM IRQs to be sensed by PDC when we enter suspend. It is
possible that the TLMM may be powered off and not detect GPIOs that are
configured as wake up interrupts. By hooking into suspend callbacks, we
allow PDC IRQs to take over and wake up the system if wakeup interrupts
are triggered.
On Tue, Sep 4, 2018 at 1:07 PM Pasha Tatashin
wrote:
>
> Hi Alexander,
>
> This is a wrong way to do it. memblock_virt_alloc_try_nid_raw() does not
> initialize allocated memory, and by setting memory to all ones in debug
> build we ensure that no callers rely on this function to return zeroed
>
On Tue, Sep 4, 2018 at 1:07 PM Pasha Tatashin
wrote:
>
> Hi Alexander,
>
> This is a wrong way to do it. memblock_virt_alloc_try_nid_raw() does not
> initialize allocated memory, and by setting memory to all ones in debug
> build we ensure that no callers rely on this function to return zeroed
>
On Mon, Aug 27 2018 at 14:01 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2018-08-24 10:14:32)
On Fri, Aug 24 2018 at 02:22 -0600, Stephen Boyd wrote:
>Quoting Lina Iyer (2018-08-17 12:10:23)
>> During suspend the system may power down some of the system rails. As a
>> result, the TLMM hw
On Mon, Aug 27 2018 at 14:01 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2018-08-24 10:14:32)
On Fri, Aug 24 2018 at 02:22 -0600, Stephen Boyd wrote:
>Quoting Lina Iyer (2018-08-17 12:10:23)
>> During suspend the system may power down some of the system rails. As a
>> result, the TLMM hw
On Tue, Sep 04, 2018 at 01:35:34PM -0700, Vito Caputo wrote:
> Implement a new class of swap space for backing dirty pages which fail
> to write back. Pages in this space survive reboots, essentially backing
> the implicit commitment POSIX establishes in the face of asynchronous
> writeback
On Tue, Sep 04, 2018 at 01:35:34PM -0700, Vito Caputo wrote:
> Implement a new class of swap space for backing dirty pages which fail
> to write back. Pages in this space survive reboots, essentially backing
> the implicit commitment POSIX establishes in the face of asynchronous
> writeback
On Tue, Sep 04, 2018 at 04:26:11PM -0400, Steven Rostedt wrote:
> On Sat, 1 Sep 2018 21:16:39 -0700
> "Paul E. McKenney" wrote:
>
> > On Sat, Sep 01, 2018 at 06:45:31PM -0400, Steven Rostedt wrote:
> > > On Sat, 1 Sep 2018 10:54:42 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Sat,
On Tue, Sep 04, 2018 at 04:26:11PM -0400, Steven Rostedt wrote:
> On Sat, 1 Sep 2018 21:16:39 -0700
> "Paul E. McKenney" wrote:
>
> > On Sat, Sep 01, 2018 at 06:45:31PM -0400, Steven Rostedt wrote:
> > > On Sat, 1 Sep 2018 10:54:42 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Sat,
On Tue, Sep 04, 2018 at 04:18:18PM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 14:54 -0400, J. Bruce Fields wrote:
> > On Tue, Sep 04, 2018 at 06:23:48PM +0200, Rogier Wolff wrote:
> > > On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
> > > > Well, I think the point was that
On Tue, Sep 04, 2018 at 04:18:18PM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 14:54 -0400, J. Bruce Fields wrote:
> > On Tue, Sep 04, 2018 at 06:23:48PM +0200, Rogier Wolff wrote:
> > > On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
> > > > Well, I think the point was that
On 8/31/2018 12:20 PM, Florian Fainelli wrote:
Enable the SFP connected to port 5 of the switch and wire up all GPIOs
to the SFP cage. Because of a hardware limitation of the i2c controller
on the iProc SoCs which prevents large i2c (> 63 bytes) transactions to
work, we use the i2c-gpio
On 8/31/2018 12:20 PM, Florian Fainelli wrote:
Enable the SFP connected to port 5 of the switch and wire up all GPIOs
to the SFP cage. Because of a hardware limitation of the i2c controller
on the iProc SoCs which prevents large i2c (> 63 bytes) transactions to
work, we use the i2c-gpio
On 8/30/18 11:11 PM, Christoph Hellwig wrote:
-#define flush_tlb_all() sbi_remote_sfence_vma(NULL, 0, -1)
+static inline void remote_sfence_vma(struct cpumask *cmask, unsigned long
start,
+unsigned long size)
+{
+ struct cpumask hmask;
+
+
On 8/30/18 11:11 PM, Christoph Hellwig wrote:
-#define flush_tlb_all() sbi_remote_sfence_vma(NULL, 0, -1)
+static inline void remote_sfence_vma(struct cpumask *cmask, unsigned long
start,
+unsigned long size)
+{
+ struct cpumask hmask;
+
+
On Tue, Sep 04, 2018 at 10:52:46AM -0700, Roman Gushchin wrote:
> Reparenting of all pages is definitely an option to consider,
Reparenting pages would be great indeed, but I'm not sure we could do
that, because we'd have to walk over page lists of semi-active kmem
caches and do it consistently
On Tue, Sep 04, 2018 at 10:52:46AM -0700, Roman Gushchin wrote:
> Reparenting of all pages is definitely an option to consider,
Reparenting pages would be great indeed, but I'm not sure we could do
that, because we'd have to walk over page lists of semi-active kmem
caches and do it consistently
On Thu, Aug 09, 2018 at 06:06:09PM +0800, Anson Huang wrote:
> On some i.MX SoCs' low power mode, UART iomux settings
Would be nice to point out specific affected SoCs.
> may be lost, need to add pinctrl sleep/default mode switch
> during suspend/resume to make sure UART iomux settings are
>
On Thu, Aug 09, 2018 at 06:06:09PM +0800, Anson Huang wrote:
> On some i.MX SoCs' low power mode, UART iomux settings
Would be nice to point out specific affected SoCs.
> may be lost, need to add pinctrl sleep/default mode switch
> during suspend/resume to make sure UART iomux settings are
>
Hello,
On Thu, Aug 09, 2018 at 06:06:08PM +0800, Anson Huang wrote:
> In noirq suspend/resume stage with no_console_suspend enabled,
> .imx_console_write() may be called to print out log_buf
> message by .printk(), so there will be race condition between
> .imx_console_write() and
Hello,
On Thu, Aug 09, 2018 at 06:06:08PM +0800, Anson Huang wrote:
> In noirq suspend/resume stage with no_console_suspend enabled,
> .imx_console_write() may be called to print out log_buf
> message by .printk(), so there will be race condition between
> .imx_console_write() and
On Sat, 1 Sep 2018 21:16:39 -0700
"Paul E. McKenney" wrote:
> On Sat, Sep 01, 2018 at 06:45:31PM -0400, Steven Rostedt wrote:
> > On Sat, 1 Sep 2018 10:54:42 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Sat, Sep 01, 2018 at 07:35:59PM +0200, Borislav Petkov wrote:
> > > > This is a
On Sat, 1 Sep 2018 21:16:39 -0700
"Paul E. McKenney" wrote:
> On Sat, Sep 01, 2018 at 06:45:31PM -0400, Steven Rostedt wrote:
> > On Sat, 1 Sep 2018 10:54:42 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Sat, Sep 01, 2018 at 07:35:59PM +0200, Borislav Petkov wrote:
> > > > This is a
Hi Chen Yu,
On 9/4/2018 10:46 AM, Chen Yu wrote:
> On a platform with MB resource enabled, a divided-by-zero
> exception is triggered when accessing 'size':
>
> [ 151.193447] divide error: [#1] SMP PTI
> [ 151.197743] CPU: 93 PID: 1929 Comm: cat Not tainted 4.19.0-rc2-debug-rdt+
> #25
>
Hi Chen Yu,
On 9/4/2018 10:46 AM, Chen Yu wrote:
> On a platform with MB resource enabled, a divided-by-zero
> exception is triggered when accessing 'size':
>
> [ 151.193447] divide error: [#1] SMP PTI
> [ 151.197743] CPU: 93 PID: 1929 Comm: cat Not tainted 4.19.0-rc2-debug-rdt+
> #25
>
As we augmented the regulator core to accept a GPIO descriptor instead
of a GPIO number, we can augment the fixed GPIO regulator to look up
and pass that descriptor directly from device tree or board GPIO
descriptor look up tables.
Some boards just auto-enumerate their fixed regulator platform
As we augmented the regulator core to accept a GPIO descriptor instead
of a GPIO number, we can augment the fixed GPIO regulator to look up
and pass that descriptor directly from device tree or board GPIO
descriptor look up tables.
Some boards just auto-enumerate their fixed regulator platform
Hi Baolin,
On 09/04/2018 01:01 PM, Baolin Wang wrote:
> This patch implements the 'pattern_set'and 'pattern_clear'
> interfaces to support SC27XX LED breathing mode.
>
> Signed-off-by: Baolin Wang
> ---
> Changes from v7:
> - Add its own ABI documentation file.
>
> Changes from v6:
> - None.
Hi Baolin,
On 09/04/2018 01:01 PM, Baolin Wang wrote:
> This patch implements the 'pattern_set'and 'pattern_clear'
> interfaces to support SC27XX LED breathing mode.
>
> Signed-off-by: Baolin Wang
> ---
> Changes from v7:
> - Add its own ABI documentation file.
>
> Changes from v6:
> - None.
On 09/04/2018 01:32 PM, Greg Kroah-Hartman wrote:
> On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.18.6 release.
>> There are 123 patches in this series, all will be posted as a response
>> to this one. If anyone has
On 09/04/2018 01:32 PM, Greg Kroah-Hartman wrote:
> On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.18.6 release.
>> There are 123 patches in this series, all will be posted as a response
>> to this one. If anyone has
On Tue, 2018-09-04 at 14:54 -0400, J. Bruce Fields wrote:
> On Tue, Sep 04, 2018 at 06:23:48PM +0200, Rogier Wolff wrote:
> > On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
> > > Well, I think the point was that in the above examples you'd prefer that
> > > the read just fail--no
On Tue, 2018-09-04 at 14:54 -0400, J. Bruce Fields wrote:
> On Tue, Sep 04, 2018 at 06:23:48PM +0200, Rogier Wolff wrote:
> > On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
> > > Well, I think the point was that in the above examples you'd prefer that
> > > the read just fail--no
Hi,
On Tue, 4 Sep 2018 16:34:56 +0200
Ulf Hansson wrote:
> On 2 September 2018 at 09:30, Andreas Kemnade wrote:
> > after unbinding mmc I get things like this:
> > [ 185.294067] mmc1: card 0001 removed
> > [ 185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -13
> >
> > The
Hi,
On Tue, 4 Sep 2018 16:34:56 +0200
Ulf Hansson wrote:
> On 2 September 2018 at 09:30, Andreas Kemnade wrote:
> > after unbinding mmc I get things like this:
> > [ 185.294067] mmc1: card 0001 removed
> > [ 185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -13
> >
> > The
Hi,
> Eric Anholt hat am 4. September 2018 um 19:41 geschrieben:
>
>
> Stephen Rothwell writes:
>
> > [ Unknown signature status ]
> > Hi Eric,
> >
> > Fetching the bcm2835 tree (git://github.com/anholt/linux.git#for-next)
> > produces this error:
> >
> > fatal: Couldn't find remote ref
Hi,
> Eric Anholt hat am 4. September 2018 um 19:41 geschrieben:
>
>
> Stephen Rothwell writes:
>
> > [ Unknown signature status ]
> > Hi Eric,
> >
> > Fetching the bcm2835 tree (git://github.com/anholt/linux.git#for-next)
> > produces this error:
> >
> > fatal: Couldn't find remote ref
Hi Alexander,
This is a wrong way to do it. memblock_virt_alloc_try_nid_raw() does not
initialize allocated memory, and by setting memory to all ones in debug
build we ensure that no callers rely on this function to return zeroed
memory just by accident.
And, the accidents are frequent because
Hi Alexander,
This is a wrong way to do it. memblock_virt_alloc_try_nid_raw() does not
initialize allocated memory, and by setting memory to all ones in debug
build we ensure that no callers rely on this function to return zeroed
memory just by accident.
And, the accidents are frequent because
On Tue, Sep 4, 2018 at 12:50 PM, Sean Christopherson
wrote:
> Cc-ing Jann and Andy.
>
> On Tue, Aug 07, 2018 at 10:29:20AM -0700, Sean Christopherson wrote:
>> Kernel addresses are always mapped with _PAGE_USER=0, i.e. PKRU
>> isn't enforced, and so we should never see X86_PF_PK set on a
>>
On Tue, Sep 4, 2018 at 12:50 PM, Sean Christopherson
wrote:
> Cc-ing Jann and Andy.
>
> On Tue, Aug 07, 2018 at 10:29:20AM -0700, Sean Christopherson wrote:
>> Kernel addresses are always mapped with _PAGE_USER=0, i.e. PKRU
>> isn't enforced, and so we should never see X86_PF_PK set on a
>>
On Tue, 4 Sep 2018 12:45:28 +0100 Will Deacon wrote:
> This series builds on the core changes I previously posted here:
>
> rfc:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-August/597821.html
> v1:
>
On Tue, 4 Sep 2018 12:45:28 +0100 Will Deacon wrote:
> This series builds on the core changes I previously posted here:
>
> rfc:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-August/597821.html
> v1:
>
On Tue, Sep 4, 2018 at 12:25 PM Dave Hansen wrote:
>
> On 09/04/2018 11:33 AM, Alexander Duyck wrote:
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1444,7 +1444,7 @@ void * __init memblock_virt_alloc_try_nid_raw(
> >
> > ptr = memblock_virt_alloc_internal(size, align,
> >
On Tue, Sep 4, 2018 at 12:25 PM Dave Hansen wrote:
>
> On 09/04/2018 11:33 AM, Alexander Duyck wrote:
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1444,7 +1444,7 @@ void * __init memblock_virt_alloc_try_nid_raw(
> >
> > ptr = memblock_virt_alloc_internal(size, align,
> >
inet_fill_ifaddr() already took 6 arguments which meant the 7th argument
would need to be pushed onto the stack on x86.
Add a new struct inet_fill_args which holds common information passed
to inet_fill_ifaddr() and shortens the function to three pointer arguments.
Signed-off-by: Christian
inet_fill_ifaddr() already took 6 arguments which meant the 7th argument
would need to be pushed onto the stack on x86.
Add a new struct inet_fill_args which holds common information passed
to inet_fill_ifaddr() and shortens the function to three pointer arguments.
Signed-off-by: Christian
The spi-dw driver currently only supports 8 or 16 bits per word.
Since the hardware supports 4-16 bits per word, adapt the driver
to also support this.
Tested on socfpga cyclone5 with a 9-bit SPI display.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Andy Shevchenko
---
Changes in v3
- remove
Cc-ing Jann and Andy.
On Tue, Aug 07, 2018 at 10:29:20AM -0700, Sean Christopherson wrote:
> Kernel addresses are always mapped with _PAGE_USER=0, i.e. PKRU
> isn't enforced, and so we should never see X86_PF_PK set on a
> kernel address fault. WARN once to capture the issue in case we
> somehow
The spi-dw driver currently only supports 8 or 16 bits per word.
Since the hardware supports 4-16 bits per word, adapt the driver
to also support this.
Tested on socfpga cyclone5 with a 9-bit SPI display.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Andy Shevchenko
---
Changes in v3
- remove
Cc-ing Jann and Andy.
On Tue, Aug 07, 2018 at 10:29:20AM -0700, Sean Christopherson wrote:
> Kernel addresses are always mapped with _PAGE_USER=0, i.e. PKRU
> isn't enforced, and so we should never see X86_PF_PK set on a
> kernel address fault. WARN once to capture the issue in case we
> somehow
(cc linux-mm).
And thanks.
On Tue, 04 Sep 2018 17:08:34 +0200 Jacek Tomaka wrote:
> Hello,
>
> I was trying to track down the performance differences of one of my
> applications
> between running it on kernel used in Centos 7.4 and the latest 4.x version.
> On 4.x kernels its performance
(cc linux-mm).
And thanks.
On Tue, 04 Sep 2018 17:08:34 +0200 Jacek Tomaka wrote:
> Hello,
>
> I was trying to track down the performance differences of one of my
> applications
> between running it on kernel used in Centos 7.4 and the latest 4.x version.
> On 4.x kernels its performance
Am Dienstag, 4. September 2018, 04:11:07 CEST schrieb Haibo Xu (Arm Technology
China):
> Hi Richard,
>
> What do you mean by done it in the core? moving macro definition to
> include/uapi/linux/ptrace.h?
> The patch is strictly follow x86's sematic on PTRACE_SYSEMU/SINGLESTEP
> support.
Well,
Am Dienstag, 4. September 2018, 04:11:07 CEST schrieb Haibo Xu (Arm Technology
China):
> Hi Richard,
>
> What do you mean by done it in the core? moving macro definition to
> include/uapi/linux/ptrace.h?
> The patch is strictly follow x86's sematic on PTRACE_SYSEMU/SINGLESTEP
> support.
Well,
> On 4 Sep 2018, at 11:05 pm, Martin Blumenstingl
> wrote:
>
> Hi Christian,
>
> On Tue, Sep 4, 2018 at 4:47 PM chewitt wrote:
>>
>> This change adds the ttyAML1 uart used by the brmcfmac sdio module in
>> the WeTek Hub and WeTek Play 2 devices.
> do you know which Broadcom chip this is
> On 4 Sep 2018, at 11:05 pm, Martin Blumenstingl
> wrote:
>
> Hi Christian,
>
> On Tue, Sep 4, 2018 at 4:47 PM chewitt wrote:
>>
>> This change adds the ttyAML1 uart used by the brmcfmac sdio module in
>> the WeTek Hub and WeTek Play 2 devices.
> do you know which Broadcom chip this is
On Mon, 3 Sep 2018 09:22:47 -0700
Andi Kleen wrote:
> Fix ETM build failure
> ---
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 2ae640257fdb..0296405f38b2 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -1432,7 +1432,8 @@ int
On Mon, 3 Sep 2018 09:22:47 -0700
Andi Kleen wrote:
> Fix ETM build failure
> ---
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 2ae640257fdb..0296405f38b2 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -1432,7 +1432,8 @@ int
On 09/03/2018 11:53 PM, Pavel Machek wrote:
> Hi!
>
>>> +static int pattern_trig_start_pattern(struct led_classdev *led_cdev)
>>> +{
>>> + struct pattern_trig_data *data = led_cdev->trigger_data;
>>> +
>>> + if (!data->npatterns)
>>> + return 0;
>>> +
>>> + if
On 09/03/2018 11:53 PM, Pavel Machek wrote:
> Hi!
>
>>> +static int pattern_trig_start_pattern(struct led_classdev *led_cdev)
>>> +{
>>> + struct pattern_trig_data *data = led_cdev->trigger_data;
>>> +
>>> + if (!data->npatterns)
>>> + return 0;
>>> +
>>> + if
On Tue, 4 Sep 2018, Benjamin Tissoires wrote:
> Hi Jiri,
>
> there is no real link between those 4 commit but the fact that I wrote
> them today ;)
>
> 2 patches should at least be scheduled for v4.19: 1/4 and 3/4
> Both are stable fixes for mistakes I made in v4.18.
>
> Patch 2 and 4 are just
On Tue, 4 Sep 2018, Benjamin Tissoires wrote:
> Hi Jiri,
>
> there is no real link between those 4 commit but the fact that I wrote
> them today ;)
>
> 2 patches should at least be scheduled for v4.19: 1/4 and 3/4
> Both are stable fixes for mistakes I made in v4.18.
>
> Patch 2 and 4 are just
On Tue, Sep 04, 2018 at 01:52:25PM +0530, Naresh Kamboju wrote:
> On 3 September 2018 at 22:25, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.9.125 release.
> > There are 107 patches in this series, all will be posted as a response
> > to this one. If
On Tue, Sep 04, 2018 at 01:52:25PM +0530, Naresh Kamboju wrote:
> On 3 September 2018 at 22:25, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.9.125 release.
> > There are 107 patches in this series, all will be posted as a response
> > to this one. If
On Tue, Sep 04, 2018 at 09:49:43AM +0530, Naresh Kamboju wrote:
> On 3 September 2018 at 22:24, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.14.68 release.
> > There are 165 patches in this series, all will be posted as a response
> > to this one. If
On Tue, Sep 04, 2018 at 09:49:43AM +0530, Naresh Kamboju wrote:
> On 3 September 2018 at 22:24, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.14.68 release.
> > There are 165 patches in this series, all will be posted as a response
> > to this one. If
On Tue, Sep 04, 2018 at 10:08:13AM +0530, Naresh Kamboju wrote:
> On 3 September 2018 at 22:26, Greg Kroah-Hartman
> wrote:
> > 4.18-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Peter Zijlstra
> >
> > commit
On Tue, Sep 04, 2018 at 10:08:13AM +0530, Naresh Kamboju wrote:
> On 3 September 2018 at 22:26, Greg Kroah-Hartman
> wrote:
> > 4.18-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Peter Zijlstra
> >
> > commit
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.6 release.
> There are 123 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.6 release.
> There are 123 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Sep 03, 2018 at 06:54:46PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.68 release.
> There are 165 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Sep 03, 2018 at 06:54:46PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.68 release.
> There are 165 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, 4 Sep 2018, Benjamin Tissoires wrote:
> When implementing commit 7f81c8db5489 ("HID: multitouch: simplify
> the settings of the various features"), I wrongly removed a test
> that made sure we never try to set the second InputMode feature
> to something else than 0.
>
> This broke badly
On Tue, 4 Sep 2018, Benjamin Tissoires wrote:
> When implementing commit 7f81c8db5489 ("HID: multitouch: simplify
> the settings of the various features"), I wrongly removed a test
> that made sure we never try to set the second InputMode feature
> to something else than 0.
>
> This broke badly
On Tue, Sep 4, 2018 at 6:13 AM Abel Vesa wrote:
>
> On Tue, Aug 28, 2018 at 12:11:13PM -0700, Andrey Smirnov wrote:
> > On Tue, Aug 28, 2018 at 3:58 AM Abel Vesa wrote:
> > >
> > > On Fri, Aug 24, 2018 at 09:40:11AM +0200, Sascha Hauer wrote:
> > > > +Cc Andrey Smirnov who made me aware of this
On Tue, Sep 4, 2018 at 6:13 AM Abel Vesa wrote:
>
> On Tue, Aug 28, 2018 at 12:11:13PM -0700, Andrey Smirnov wrote:
> > On Tue, Aug 28, 2018 at 3:58 AM Abel Vesa wrote:
> > >
> > > On Fri, Aug 24, 2018 at 09:40:11AM +0200, Sascha Hauer wrote:
> > > > +Cc Andrey Smirnov who made me aware of this
On 09/03/2018 10:55 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.125 release.
> There are 107 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 09/03/2018 10:55 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.125 release.
> There are 107 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 08/29/18 18:34, Manivannan Sadhasivam wrote:
On Wed, Aug 29, 2018 at 10:24:12AM +0200, Saravanan Sekar wrote:
Add pinctrl driver for Actions Semi S700 SoC. The driver supports pinctrl,
pinmux and pinconf functionalities through a range of registers common to
both gpio driver and pinctrl
On 08/29/18 18:34, Manivannan Sadhasivam wrote:
On Wed, Aug 29, 2018 at 10:24:12AM +0200, Saravanan Sekar wrote:
Add pinctrl driver for Actions Semi S700 SoC. The driver supports pinctrl,
pinmux and pinconf functionalities through a range of registers common to
both gpio driver and pinctrl
On 09/04/2018 11:33 AM, Alexander Duyck wrote:
> +++ b/mm/page_alloc.c
> @@ -1231,7 +1231,7 @@ void __meminit reserve_bootmem_region(phys_addr_t
> start, phys_addr_t end)
> /* Avoid false-positive PageTail() */
> INIT_LIST_HEAD(>lru);
>
> -
On 09/04/2018 11:33 AM, Alexander Duyck wrote:
> +++ b/mm/page_alloc.c
> @@ -1231,7 +1231,7 @@ void __meminit reserve_bootmem_region(phys_addr_t
> start, phys_addr_t end)
> /* Avoid false-positive PageTail() */
> INIT_LIST_HEAD(>lru);
>
> -
On 09/03/2018 10:48 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.154 release.
> There are 80 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 09/03/2018 10:48 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.154 release.
> There are 80 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On Tue, Sep 4, 2018 at 10:07 PM Afonso Bordado wrote:
>
> This patch adds support for reading/writing ODR/Scale
>
> We don't support the scale boost modes.
> @@ -44,7 +44,10 @@
> #define FXAS21002C_REG_F_EVENT 0x0A
> #define FXAS21002C_REG_INT_SRC_FLAG0x0B
> #define
On Tue, Sep 4, 2018 at 10:07 PM Afonso Bordado wrote:
>
> This patch adds support for reading/writing ODR/Scale
>
> We don't support the scale boost modes.
> @@ -44,7 +44,10 @@
> #define FXAS21002C_REG_F_EVENT 0x0A
> #define FXAS21002C_REG_INT_SRC_FLAG0x0B
> #define
On 09/04/2018 11:33 AM, Alexander Duyck wrote:
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1444,7 +1444,7 @@ void * __init memblock_virt_alloc_try_nid_raw(
>
> ptr = memblock_virt_alloc_internal(size, align,
> min_addr, max_addr, nid);
>
On 09/04/2018 11:33 AM, Alexander Duyck wrote:
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1444,7 +1444,7 @@ void * __init memblock_virt_alloc_try_nid_raw(
>
> ptr = memblock_virt_alloc_internal(size, align,
> min_addr, max_addr, nid);
>
On 09/03/2018 10:48 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.121 release.
> There are 56 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 09/03/2018 10:48 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.121 release.
> There are 56 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On Tue, Sep 4, 2018 at 10:08 PM Afonso Bordado wrote:
>
> FXAS21002C is a 3 axis gyroscope with integrated temperature sensor
>
> Signed-off-by: Afonso Bordado
> ---
> Changes in v3
>- Use unsigned int on regmap functions
>- Remove the export of the regmap config
>- Fix undefined
On Tue, Sep 4, 2018 at 10:08 PM Afonso Bordado wrote:
>
> FXAS21002C is a 3 axis gyroscope with integrated temperature sensor
>
> Signed-off-by: Afonso Bordado
> ---
> Changes in v3
>- Use unsigned int on regmap functions
>- Remove the export of the regmap config
>- Fix undefined
On Tue, Sep 4, 2018 at 10:07 PM Afonso Bordado wrote:
>
> Add entry for fxas21002c gyroscope driver and add myself as
> maintainer of this driver.
>
> Signed-off-by: Afonso Bordado
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
>
On Tue, Sep 4, 2018 at 10:07 PM Afonso Bordado wrote:
>
> Add entry for fxas21002c gyroscope driver and add myself as
> maintainer of this driver.
>
> Signed-off-by: Afonso Bordado
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
>
On Sat, Sep 01, 2018 at 07:28:23PM +0800, Fengguang Wu wrote:
> Signed-off-by: Fengguang Wu
> ---
> arch/x86/kvm/Kconfig | 11 +++
> arch/x86/kvm/Makefile | 4
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index
On Sat, Sep 01, 2018 at 07:28:23PM +0800, Fengguang Wu wrote:
> Signed-off-by: Fengguang Wu
> ---
> arch/x86/kvm/Kconfig | 11 +++
> arch/x86/kvm/Makefile | 4
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index
201 - 300 of 1168 matches
Mail list logo
