On Tue, Oct 09, 2018 at 12:25:01PM -0400, Thara Gopinath wrote:
> cpu_capacity relflects the maximum available capacity of a cpu. Thermal
> pressure on a cpu means this maximum available capacity is reduced. This
> patch reduces the average thermal pressure for a cpu from its maximum
> available
On Tue, Oct 09, 2018 at 12:25:01PM -0400, Thara Gopinath wrote:
> cpu_capacity relflects the maximum available capacity of a cpu. Thermal
> pressure on a cpu means this maximum available capacity is reduced. This
> patch reduces the average thermal pressure for a cpu from its maximum
> available
On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:
> This patch creates a dedicated vdev subdevice for each vdev declared
> in firmware resource table and associates carveout named "vdev%dbuffer"
> (with %d vdev index in resource table) if any as dma coherent memory pool.
>
> Then vdev subdevice
On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:
> This patch creates a dedicated vdev subdevice for each vdev declared
> in firmware resource table and associates carveout named "vdev%dbuffer"
> (with %d vdev index in resource table) if any as dma coherent memory pool.
>
> Then vdev subdevice
On Tue, Oct 09, 2018 at 02:05:01PM -0700, Guenter Roeck wrote:
> On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.160 release.
> > There are 113 patches in this series, all will be posted as a response
> > to this one.
On Wed, Oct 10, 2018 at 09:42:46AM +0530, Naresh Kamboju wrote:
> On Tue, 9 Oct 2018 at 21:44, Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.18.13 release.
> > > There are 168
On Tue, Oct 09, 2018 at 02:05:01PM -0700, Guenter Roeck wrote:
> On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.160 release.
> > There are 113 patches in this series, all will be posted as a response
> > to this one.
On Wed, Oct 10, 2018 at 09:42:46AM +0530, Naresh Kamboju wrote:
> On Tue, 9 Oct 2018 at 21:44, Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.18.13 release.
> > > There are 168
Laurent Pinchart schrieb:
> Hi Josh,
>
> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
>> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
>>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley
Laurent Pinchart schrieb:
> Hi Josh,
>
> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
>> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
>>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley
* Yi Sun wrote:
> On 18-10-09 12:54:27, Ingo Molnar wrote:
> >
> > * Yi Sun wrote:
> >
> > > Follow PV spinlock mechanism to implement the callback functions
> > > to allow the CPU idling and kicking operations on Hyper-V.
> >
> > > +#if defined(CONFIG_SMP)
> > > +
* Yi Sun wrote:
> On 18-10-09 12:54:27, Ingo Molnar wrote:
> >
> > * Yi Sun wrote:
> >
> > > Follow PV spinlock mechanism to implement the callback functions
> > > to allow the CPU idling and kicking operations on Hyper-V.
> >
> > > +#if defined(CONFIG_SMP)
> > > +
On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
>> chips.
>>
>> Similarly,
On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
>> chips.
>>
>> Similarly,
Hi all,
Changes since 20181009:
The ext4 tree lost its build failure.
The kvm-ppc tree gained a conflict against the kvm-arm tree.
Non-merge commits (relative to Linus' tree): 9423
8942 files changed, 420582 insertions(+), 194157 deletions
Hi all,
Changes since 20181009:
The ext4 tree lost its build failure.
The kvm-ppc tree gained a conflict against the kvm-arm tree.
Non-merge commits (relative to Linus' tree): 9423
8942 files changed, 420582 insertions(+), 194157 deletions
On Tue, Oct 09, 2018 at 12:24:55PM -0400, Thara Gopinath wrote:
> Thermal governors can respond to an overheat event for a cpu by
> capping the cpu's maximum possible frequency. This in turn
> means that the maximum available compute capacity of the
> cpu is restricted. But today in linux kernel,
On Tue, Oct 09, 2018 at 12:24:55PM -0400, Thara Gopinath wrote:
> Thermal governors can respond to an overheat event for a cpu by
> capping the cpu's maximum possible frequency. This in turn
> means that the maximum available compute capacity of the
> cpu is restricted. But today in linux kernel,
Hi Jiri,
Yes, this happens when entry->map is NULL. While your fix seems correct, the
following commit from Milian Wolff had already addressed this. I think this
was pulled in with one of Arnaldo's recent perf/urgent updates.
ff4ce2885af8 ("perf report: Don't try to map ip to invalid map")
Hi Jiri,
Yes, this happens when entry->map is NULL. While your fix seems correct, the
following commit from Milian Wolff had already addressed this. I think this
was pulled in with one of Arnaldo's recent perf/urgent updates.
ff4ce2885af8 ("perf report: Don't try to map ip to invalid map")
Hi Nathan,
On Mon, Oct 08, 2018 at 03:20:41PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/platform/chrome/chromeos_tbmc.c:102:14: warning: duplicate
> 'const' declaration specifier [-Wduplicate-decl-specifier]
> static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
>
Hi Nathan,
On Mon, Oct 08, 2018 at 03:20:41PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/platform/chrome/chromeos_tbmc.c:102:14: warning: duplicate
> 'const' declaration specifier [-Wduplicate-decl-specifier]
> static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
>
On Tue, Oct 09, 2018 at 10:56:14PM +, Leonard Crestez wrote:
> On Tue, 2018-10-09 at 08:37 +, Abel Vesa wrote:
> > +struct clk *imx_clk_composite_8m_flags(const char *name,
> > + const char **parent_names,
> > + int
On Tue, Oct 09, 2018 at 10:56:14PM +, Leonard Crestez wrote:
> On Tue, 2018-10-09 at 08:37 +, Abel Vesa wrote:
> > +struct clk *imx_clk_composite_8m_flags(const char *name,
> > + const char **parent_names,
> > + int
On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:
> int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw)
> diff --git a/drivers/remoteproc/remoteproc_virtio.c
> b/drivers/remoteproc/remoteproc_virtio.c
[..]
> @@ -114,6 +122,10 @@ static struct virtqueue *rp_find_vq(struct
On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:
> int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw)
> diff --git a/drivers/remoteproc/remoteproc_virtio.c
> b/drivers/remoteproc/remoteproc_virtio.c
[..]
> @@ -114,6 +122,10 @@ static struct virtqueue *rp_find_vq(struct
Installation Notes for Teo En Ming Extremely Simple Linux 1810.08
=
Definitely must watch YouTube video: https://www.youtube.com/watch?v=YrJADssqaQU
Author: Mr. Turritopsis Dohrnii Teo En Ming
Country: Singapore
Start: 8th October
Installation Notes for Teo En Ming Extremely Simple Linux 1810.08
=
Definitely must watch YouTube video: https://www.youtube.com/watch?v=YrJADssqaQU
Author: Mr. Turritopsis Dohrnii Teo En Ming
Country: Singapore
Start: 8th October
Hi Filippo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux-sof-driver/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Filippo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux-sof-driver/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Greg,
please pull s390 fixes for 4.19:
The following changes since commit 4b92e7fd76e94624e3d5ff56b3d6a5788c4a7ac8:
Merge tag 'mtd/fixes-for-4.19-rc5' of git://git.infradead.org/linux-mtd
(2018-09-20 11:25:20 +0200)
are available in the git repository at:
Hi Greg,
please pull s390 fixes for 4.19:
The following changes since commit 4b92e7fd76e94624e3d5ff56b3d6a5788c4a7ac8:
Merge tag 'mtd/fixes-for-4.19-rc5' of git://git.infradead.org/linux-mtd
(2018-09-20 11:25:20 +0200)
are available in the git repository at:
Hi Emil,
On Wed, Oct 3, 2018 at 11:43 AM Emil Karlson wrote:
>
> Commit 57e94c8b974db2d83c60e1139c89a70806abbea0 caused cros-ec keyboard events
> be truncated on many chromebooks so that Left and Right keys on Column 12 were
> always 0. Use ret as memcpy len to fix this.
>
> The old code was
Hi Emil,
On Wed, Oct 3, 2018 at 11:43 AM Emil Karlson wrote:
>
> Commit 57e94c8b974db2d83c60e1139c89a70806abbea0 caused cros-ec keyboard events
> be truncated on many chromebooks so that Left and Right keys on Column 12 were
> always 0. Use ret as memcpy len to fix this.
>
> The old code was
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Hi Enrico,
On Wed, Oct 03, 2018 at 11:45:06AM -0700, Enrico Granata wrote:
> From: Enrico Granata
>
> This commit allows cros_ec_lpc to register a direct IRQ instead of relying
> on the ACPI notification chain to receive MKBP events.
>
> This change is done in the interest of allowing reduced
Hi Enrico,
On Wed, Oct 03, 2018 at 11:45:06AM -0700, Enrico Granata wrote:
> From: Enrico Granata
>
> This commit allows cros_ec_lpc to register a direct IRQ instead of relying
> on the ACPI notification chain to receive MKBP events.
>
> This change is done in the interest of allowing reduced
Hi Lee,
Sorry for the super late reply to your email before. I wanted to make sure
this wasn't dropped so we could get this into v4.20.
Thanks,
Benson
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the
Hi Lee,
Sorry for the super late reply to your email before. I wanted to make sure
this wasn't dropped so we could get this into v4.20.
Thanks,
Benson
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the
Hi Greg,
Sorry for the late in the cycle request, but this one is fairly urgent.
Please pull thi fix to chrome platform. A patch that landed
for 4.19 broke cros_ec based chromebooks' keyboards, and this fixes them.
Thanks,
Benson
The following changes since commit
Hi Suzuki
On 2018/10/10 1:22, Suzuki K Poulose wrote:
>
>
> On 08/10/18 13:34, Dongjiu Geng wrote:
>> The commit 539aee0edb9f ("KVM: arm64: Share the parts of
>> get/set events useful to 32bit") shares the get/set events
>> helper for arm64 and arm32, it is better also share the check
>> for
Hi Greg,
Sorry for the late in the cycle request, but this one is fairly urgent.
Please pull thi fix to chrome platform. A patch that landed
for 4.19 broke cros_ec based chromebooks' keyboards, and this fixes them.
Thanks,
Benson
The following changes since commit
Hi Suzuki
On 2018/10/10 1:22, Suzuki K Poulose wrote:
>
>
> On 08/10/18 13:34, Dongjiu Geng wrote:
>> The commit 539aee0edb9f ("KVM: arm64: Share the parts of
>> get/set events useful to 32bit") shares the get/set events
>> helper for arm64 and arm32, it is better also share the check
>> for
On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques wrote:
>
> Current implementation of cephfs fallocate isn't correct as it doesn't
> really reserve the space in the cluster, which means that a subsequent
> call to a write may actually fail due to lack of space. In fact, it is
> currently possible
On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques wrote:
>
> Current implementation of cephfs fallocate isn't correct as it doesn't
> really reserve the space in the cluster, which means that a subsequent
> call to a write may actually fail due to lack of space. In fact, it is
> currently possible
On Tue, 9 Oct 2018 at 00:03, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 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.
>
>
On Tue, 9 Oct 2018 at 00:03, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 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.
>
>
On Tue, 9 Oct 2018 at 00:08, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.132 release.
> There are 59 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.
>
>
On Tue, 9 Oct 2018 at 00:08, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.132 release.
> There are 59 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.
>
>
On Tue, 9 Oct 2018 at 21:45, Greg Kroah-Hartman
wrote:
>
> On Mon, Oct 08, 2018 at 08:30:41PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.75 release.
> > There are 94 patches in this series, all will be posted as a response
> > to this one. If
On Tue, 9 Oct 2018 at 21:45, Greg Kroah-Hartman
wrote:
>
> On Mon, Oct 08, 2018 at 08:30:41PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.75 release.
> > There are 94 patches in this series, all will be posted as a response
> > to this one. If
From: John Hubbard
An upcoming patch requires a way to operate on each page that
any of the get_user_pages_*() variants returns.
In preparation for that, consolidate the error handling for
__get_user_pages(). This provides a single location (the "out:" label)
for operating on the collected set
On Tue, 9 Oct 2018 at 21:44, Greg Kroah-Hartman
wrote:
>
> On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.13 release.
> > There are 168 patches in this series, all will be posted as a response
> > to this one. If
From: John Hubbard
An upcoming patch requires a way to operate on each page that
any of the get_user_pages_*() variants returns.
In preparation for that, consolidate the error handling for
__get_user_pages(). This provides a single location (the "out:" label)
for operating on the collected set
On Tue, 9 Oct 2018 at 21:44, Greg Kroah-Hartman
wrote:
>
> On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.13 release.
> > There are 168 patches in this series, all will be posted as a response
> > to this one. If
On Wed, 10 Oct 2018, Tetsuo Handa wrote:
> syzbot is hitting RCU stall due to memcg-OOM event.
> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
>
> What should we do if memcg-OOM found no killable task because the allocating
> task
> was oom_score_adj == -1000 ?
On Wed, 10 Oct 2018, Tetsuo Handa wrote:
> syzbot is hitting RCU stall due to memcg-OOM event.
> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
>
> What should we do if memcg-OOM found no killable task because the allocating
> task
> was oom_score_adj == -1000 ?
From: John Hubbard
For infiniband code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(), or
put_user_pages*(), instead of put_page()
This is a tiny part of the second step of fixing the problem described
in [1]. The steps are:
1) Provide
From: John Hubbard
Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().
Also introduces put_user_pages(), and a few dirty/locked variations,
as a replacement for
From: John Hubbard
Changes since v4:
-- Changed the new put_user_page*() functions to operate only on the head
page, because that's how the final version of those functions will work.
(Andrew Morton's feedback prompted this, thanks!)
-- Added proper documentation of the new
From: John Hubbard
For infiniband code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(), or
put_user_pages*(), instead of put_page()
This is a tiny part of the second step of fixing the problem described
in [1]. The steps are:
1) Provide
From: John Hubbard
Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().
Also introduces put_user_pages(), and a few dirty/locked variations,
as a replacement for
From: John Hubbard
Changes since v4:
-- Changed the new put_user_page*() functions to operate only on the head
page, because that's how the final version of those functions will work.
(Andrew Morton's feedback prompted this, thanks!)
-- Added proper documentation of the new
On 10/09/2018 07:28 PM, Zi Yan wrote:
> cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86
> PMD migration entry check)
>
> On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:
>
>> A normal mapped THP page at PMD level should be correctly differentiated
>> from a PMD
On 10/09/2018 07:28 PM, Zi Yan wrote:
> cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86
> PMD migration entry check)
>
> On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:
>
>> A normal mapped THP page at PMD level should be correctly differentiated
>> from a PMD
On 09-10-18, 10:40, Pierre Yves MORDRET wrote:
>
>
> On 10/07/2018 06:00 PM, Vinod wrote:
> > On 28-09-18, 15:01, Pierre-Yves MORDRET wrote:
> >> This patch adds support of DMA/MDMA chaining support.
> >> It introduces an intermediate transfer between peripherals and STM32 DMA.
> >> This
On 09-10-18, 10:40, Pierre Yves MORDRET wrote:
>
>
> On 10/07/2018 06:00 PM, Vinod wrote:
> > On 28-09-18, 15:01, Pierre-Yves MORDRET wrote:
> >> This patch adds support of DMA/MDMA chaining support.
> >> It introduces an intermediate transfer between peripherals and STM32 DMA.
> >> This
Hi Arnaldo,
Did you get a chance to look at this again?
On Thu, Aug 30, 2018, at 14:50, Benjamin Peterson wrote:
> Thanks for the review.
>
> On Thu, Aug 30, 2018, at 11:28, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Aug 27, 2018 at 08:53:44PM -0700, Benjamin Peterson escreveu:
> > > Example
Hi Arnaldo,
Did you get a chance to look at this again?
On Thu, Aug 30, 2018, at 14:50, Benjamin Peterson wrote:
> Thanks for the review.
>
> On Thu, Aug 30, 2018, at 11:28, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Aug 27, 2018 at 08:53:44PM -0700, Benjamin Peterson escreveu:
> > > Example
Hi Enric,
On Wed, Oct 3, 2018 at 4:01 AM Enric Balletbo i Serra
wrote:
>
> Hi Emil,
>
> Many thanks to catch this and fix. Some comments below.
>
> You missed to add the v2, please send the next patch with v3 prefix.
>
> On 28/9/18 19:08, Emil Karlson wrote:
> > Commit
Hi Enric,
On Wed, Oct 3, 2018 at 4:01 AM Enric Balletbo i Serra
wrote:
>
> Hi Emil,
>
> Many thanks to catch this and fix. Some comments below.
>
> You missed to add the v2, please send the next patch with v3 prefix.
>
> On 28/9/18 19:08, Emil Karlson wrote:
> > Commit
Hi Adam
Yes, MMC_DDR52 can use pins_100mhz. You can do that, thanks!
Best Regards
Bough Chen
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Adam Ford
> Sent: 2018年10月9日 21:38
> To: linux-...@vger.kernel.org; Linux
Hi Adam
Yes, MMC_DDR52 can use pins_100mhz. You can do that, thanks!
Best Regards
Bough Chen
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Adam Ford
> Sent: 2018年10月9日 21:38
> To: linux-...@vger.kernel.org; Linux
On 10/09/2018 07:44 PM, Michal Hocko wrote:
> On Fri 05-10-18 13:04:43, Anshuman Khandual wrote:
>> Does the following sound close enough to what you are looking for ?
>
> I do not think so
Okay.
>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 9df1d59..070c419
On 10/09/2018 07:44 PM, Michal Hocko wrote:
> On Fri 05-10-18 13:04:43, Anshuman Khandual wrote:
>> Does the following sound close enough to what you are looking for ?
>
> I do not think so
Okay.
>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 9df1d59..070c419
> -Original Message-
> From: Esben Haabendal On Behalf Of Esben
> Haabendal
> Sent: 2018年10月9日 19:21
> To: Chuanhua Han
> Cc: Boris Brezillon ; broo...@kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the
> -Original Message-
> From: Esben Haabendal On Behalf Of Esben
> Haabendal
> Sent: 2018年10月9日 19:21
> To: Chuanhua Han
> Cc: Boris Brezillon ; broo...@kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the
On 18-10-09 12:54:27, Ingo Molnar wrote:
>
> * Yi Sun wrote:
>
> > Follow PV spinlock mechanism to implement the callback functions
> > to allow the CPU idling and kicking operations on Hyper-V.
>
> > +#if defined(CONFIG_SMP)
> > + smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> >
On 18-10-09 12:54:27, Ingo Molnar wrote:
>
> * Yi Sun wrote:
>
> > Follow PV spinlock mechanism to implement the callback functions
> > to allow the CPU idling and kicking operations on Hyper-V.
>
> > +#if defined(CONFIG_SMP)
> > + smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> >
Hi Paul,
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 tree and commit:
aa069a996951 ("KVM: PPC: Book3S HV: Add a VM capability to
Hi Paul,
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 tree and commit:
aa069a996951 ("KVM: PPC: Book3S HV: Add a VM capability to
From: Kuninori Morimoto
74aup1g157gw needs i0 and i1 pin as input, select and output it by
sel gpio pin. This driver adds new 74aup1g157gw as clock multiplexer.
"nxp,74aup1g157gw-clk" will select most closest input as output,
"nxp,74aup1g157gw-audio-clk" will select 48kHz/44.1kHz categorized
From: Kuninori Morimoto
74aup1g157gw needs i0 and i1 pin as input, select and output it by
sel gpio pin. This patch adds description for 74aup1g157gw as clock
multiplexer.
"nxp,74aup1g157gw-clk" will select most closest input as output,
"nxp,74aup1g157gw-audio-clk" will select 48kHz/44.1kHz
From: Kuninori Morimoto
74aup1g157gw needs i0 and i1 pin as input, select and output it by
sel gpio pin. This patch adds description for 74aup1g157gw as clock
multiplexer.
"nxp,74aup1g157gw-clk" will select most closest input as output,
"nxp,74aup1g157gw-audio-clk" will select 48kHz/44.1kHz
From: Kuninori Morimoto
74aup1g157gw needs i0 and i1 pin as input, select and output it by
sel gpio pin. This driver adds new 74aup1g157gw as clock multiplexer.
"nxp,74aup1g157gw-clk" will select most closest input as output,
"nxp,74aup1g157gw-audio-clk" will select 48kHz/44.1kHz categorized
Hi Michael, Stephen, Rob, Mark
These adds 74aup1g157gw 2-input multiplexer as clock driver.
Kuninori Morimoto (2):
dt-bindings: clock: add description of 74aup1g157gw
clk: add 74aup1g157gw 2-input multiplexer as clock driver
Hi Michael, Stephen, Rob, Mark
These adds 74aup1g157gw 2-input multiplexer as clock driver.
Kuninori Morimoto (2):
dt-bindings: clock: add description of 74aup1g157gw
clk: add 74aup1g157gw 2-input multiplexer as clock driver
Hi Jacek,
On 10 October 2018 at 02:37, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> On 10/09/2018 02:01 PM, Baolin Wang wrote:
>> Hi Jacek and Pavel,
>>
>> On 5 October 2018 at 04:00, Jacek Anaszewski
>> wrote:
>>> Hi Baolin,
>>>
>>> On 10/03/2018 03:21 AM, Baolin Wang wrote:
Hi Jacek,
Hi Jacek,
On 10 October 2018 at 02:37, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> On 10/09/2018 02:01 PM, Baolin Wang wrote:
>> Hi Jacek and Pavel,
>>
>> On 5 October 2018 at 04:00, Jacek Anaszewski
>> wrote:
>>> Hi Baolin,
>>>
>>> On 10/03/2018 03:21 AM, Baolin Wang wrote:
Hi Jacek,
The function name in the comment is not correct.
Signed-off-by: Wei Yang
---
include/linux/rbtree_augmented.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/rbtree_augmented.h b/include/linux/rbtree_augmented.h
index af8a61be2d8d..9510c677ac70 100644
---
The function name in the comment is not correct.
Signed-off-by: Wei Yang
---
include/linux/rbtree_augmented.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/rbtree_augmented.h b/include/linux/rbtree_augmented.h
index af8a61be2d8d..9510c677ac70 100644
---
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Quoting Doug Anderson (2018-10-09 14:18:26)
> Hi,
> On Tue, Oct 9, 2018 at 12:45 PM Stephen Boyd wrote:
> >
> > Quoting Doug Anderson (2018-10-09 10:48:55)
> > >
> > > Ah, you're suggesting separating the platform_get_irq() and the
> > > request_irq() so that we call platform_get_irq() as the
Quoting Doug Anderson (2018-10-09 14:18:26)
> Hi,
> On Tue, Oct 9, 2018 at 12:45 PM Stephen Boyd wrote:
> >
> > Quoting Doug Anderson (2018-10-09 10:48:55)
> > >
> > > Ah, you're suggesting separating the platform_get_irq() and the
> > > request_irq() so that we call platform_get_irq() as the
On Tue, 2018-10-09 at 14:47 -0400, Johannes Weiner wrote:
> These workloads also deal with tens of thousands of open files and
> use
> /proc for introspection, which ends up growing the proc_inode_cache
> to
> absurdly large sizes - again at the cost of valuable cache space,
> which isn't a
On Tue, 2018-10-09 at 14:47 -0400, Johannes Weiner wrote:
> These workloads also deal with tens of thousands of open files and
> use
> /proc for introspection, which ends up growing the proc_inode_cache
> to
> absurdly large sizes - again at the cost of valuable cache space,
> which isn't a
Thanks Finn, I will take a good look at that and try to use it in my build.
Thank you,
Leonardo Bras
On Wed, Oct 3, 2018 at 11:00 PM Finn Thain wrote:
>
> On Wed, 3 Oct 2018, Leonardo Bras wrote:
>
> > Both ccache and distcc seem very interesting, I will take my time to
> > study them better as
Thanks Finn, I will take a good look at that and try to use it in my build.
Thank you,
Leonardo Bras
On Wed, Oct 3, 2018 at 11:00 PM Finn Thain wrote:
>
> On Wed, 3 Oct 2018, Leonardo Bras wrote:
>
> > Both ccache and distcc seem very interesting, I will take my time to
> > study them better as
1 - 100 of 1434 matches
Mail list logo
