Add 3 helpers so that pincontrol definitions for pxa25x and pxa27x are
easier, and can be easily converted from old mfp mach-pxa code to
devicetree.
An example of such conversion would be :
static unsigned long mioa701_pin_config[] = {
GPIO32_MMC_CLK,
GPIO92_MMC_DAT_0,
Add device-tree description of the Mitac MIO A701 board.
This is aimed at replacing mioa701.c board file, and once stabilized,
the leftover, such as the suspend resume mechanics will rely on a new
IPL, and not the legacy Windows CE one.
Signed-off-by: Robert Jarzmik
---
This patch deserves some
Add 3 helpers so that pincontrol definitions for pxa25x and pxa27x are
easier, and can be easily converted from old mfp mach-pxa code to
devicetree.
An example of such conversion would be :
static unsigned long mioa701_pin_config[] = {
GPIO32_MMC_CLK,
GPIO92_MMC_DAT_0,
Add device-tree description of the Mitac MIO A701 board.
This is aimed at replacing mioa701.c board file, and once stabilized,
the leftover, such as the suspend resume mechanics will rely on a new
IPL, and not the legacy Windows CE one.
Signed-off-by: Robert Jarzmik
---
This patch deserves some
On 07/01/2018 05:56 PM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
There were some typos in patches #4 and #5, which I've fixed locally.
Let me know if anyone would like me to repost with those right away, otherwise
I'll wait for other review besides the kbuild test robot.
Meanwhile,
On 07/01/2018 05:56 PM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
There were some typos in patches #4 and #5, which I've fixed locally.
Let me know if anyone would like me to repost with those right away, otherwise
I'll wait for other review besides the kbuild test robot.
Meanwhile,
It is not good enough to have a soft limit for the number of
negative dentries in the system and print a warning if that limit is
exceeded. We need to do something about it when this happens.
This patch enables automatic pruning of negative dentries when
the soft limit is going to be exceeded.
It is not good enough to have a soft limit for the number of
negative dentries in the system and print a warning if that limit is
exceeded. We need to do something about it when this happens.
This patch enables automatic pruning of negative dentries when
the soft limit is going to be exceeded.
Doing negative dentry pruning using schedule_delayed_work() will
typically concentrate the pruning effort on one particular CPU. That is
not fair to the tasks running on that CPU. In addition, it is possible
that one CPU can have all its negative dentries pruned away while the
others can still
Doing negative dentry pruning using schedule_delayed_work() will
typically concentrate the pruning effort on one particular CPU. That is
not fair to the tasks running on that CPU. In addition, it is possible
that one CPU can have all its negative dentries pruned away while the
others can still
The current dentry number tracking code doesn't distinguish between
positive & negative dentries. It just reports the total number of
dentries in the LRU lists.
As excessive number of negative dentries can have an impact on system
performance, it will be wise to track the number of positive and
On Thu, Jun 28, 2018 at 11:17:43AM +0200, Jan Kara wrote:
> On Wed 27-06-18 19:42:01, John Hubbard wrote:
> > On 06/27/2018 10:02 AM, Jan Kara wrote:
> > > On Wed 27-06-18 08:57:18, Jason Gunthorpe wrote:
> > >> On Wed, Jun 27, 2018 at 02:42:55PM +0200, Jan Kara wrote:
> > >>> On Wed 27-06-18
It can be useful to make negative dentry limit enformcement a runtime
tuning parameter instead of just a boot time option. This allows system
administrator to disable limit enforcement in normal use, but turn it
on under certain circumstances.
A new /proc/sys/fs/enforce-neg-dentry-limit sysctl
If a rogue application that generates a large number of negative
dentries is running, the automatic negative dentries pruning process
may not be fast enough to clear up the negative dentries in time. In
this case, it is possible that negative dentries will use up most
of the available memory in
v4->v5:
- Backed to the latest 4.18 kernel and modify the code
accordingly. Patch 1 "Relocate dentry_kill() after lock_parent()"
is now no longer necessary.
- Make tracking and limiting of negative dentries an user configurable
option (CONFIG_DCACHE_TRACK_NEG_ENTRY) so that users
v4->v5:
- Backed to the latest 4.18 kernel and modify the code
accordingly. Patch 1 "Relocate dentry_kill() after lock_parent()"
is now no longer necessary.
- Make tracking and limiting of negative dentries an user configurable
option (CONFIG_DCACHE_TRACK_NEG_ENTRY) so that users
If a rogue application that generates a large number of negative
dentries is running, the automatic negative dentries pruning process
may not be fast enough to clear up the negative dentries in time. In
this case, it is possible that negative dentries will use up most
of the available memory in
The current dentry number tracking code doesn't distinguish between
positive & negative dentries. It just reports the total number of
dentries in the LRU lists.
As excessive number of negative dentries can have an impact on system
performance, it will be wise to track the number of positive and
On Thu, Jun 28, 2018 at 11:17:43AM +0200, Jan Kara wrote:
> On Wed 27-06-18 19:42:01, John Hubbard wrote:
> > On 06/27/2018 10:02 AM, Jan Kara wrote:
> > > On Wed 27-06-18 08:57:18, Jason Gunthorpe wrote:
> > >> On Wed, Jun 27, 2018 at 02:42:55PM +0200, Jan Kara wrote:
> > >>> On Wed 27-06-18
It can be useful to make negative dentry limit enformcement a runtime
tuning parameter instead of just a boot time option. This allows system
administrator to disable limit enforcement in normal use, but turn it
on under certain circumstances.
A new /proc/sys/fs/enforce-neg-dentry-limit sysctl
The negative dentry tracking is made a configurable option so that
users who don't care about negative dentry tracking will have the
option to disable it. The new config option DCACHE_TRACK_NEG_ENTRY
is disabled by default.
If this option is enabled, a new kernel parameter "neg_dentry_pc=<%>"
The negative dentry tracking is made a configurable option so that
users who don't care about negative dentry tracking will have the
option to disable it. The new config option DCACHE_TRACK_NEG_ENTRY
is disabled by default.
If this option is enabled, a new kernel parameter "neg_dentry_pc=<%>"
Matthew Wilcox writes:
> On Fri, Jun 22, 2018 at 11:51:33AM +0800, Huang, Ying wrote:
>> +++ b/mm/swap_state.c
>> @@ -433,7 +433,7 @@ struct page *__read_swap_cache_async(swp_entry_t entry,
>> gfp_t gfp_mask,
>> /*
>> * Swap entry may have been freed since our caller
Matthew Wilcox writes:
> On Fri, Jun 22, 2018 at 11:51:33AM +0800, Huang, Ying wrote:
>> +++ b/mm/swap_state.c
>> @@ -433,7 +433,7 @@ struct page *__read_swap_cache_async(swp_entry_t entry,
>> gfp_t gfp_mask,
>> /*
>> * Swap entry may have been freed since our caller
Matthew Wilcox writes:
> On Fri, Jun 29, 2018 at 09:17:16AM +0800, Huang, Ying wrote:
>> Matthew Wilcox writes:
>> > I'll take a look. Honestly, my biggest problem with this patch set is
>> > overuse of tagging:
>> >
>> > 59832 Jun 22 Huang, Ying ( 131) [PATCH -mm -v4 00/21] mm, THP,
Matthew Wilcox writes:
> On Fri, Jun 29, 2018 at 09:17:16AM +0800, Huang, Ying wrote:
>> Matthew Wilcox writes:
>> > I'll take a look. Honestly, my biggest problem with this patch set is
>> > overuse of tagging:
>> >
>> > 59832 Jun 22 Huang, Ying ( 131) [PATCH -mm -v4 00/21] mm, THP,
FYI, we noticed the following commit (built with gcc-7):
commit: b1ff47aacea95e5be1bedf2aee740395b52f4591 ("[PATCH 5/5] x86/kernel:
jump_table: use relative references")
url:
FYI, we noticed the following commit (built with gcc-7):
commit: b1ff47aacea95e5be1bedf2aee740395b52f4591 ("[PATCH 5/5] x86/kernel:
jump_table: use relative references")
url:
On 07/01/2018 07:58 PM, kbuild test robot wrote:
> Hi John,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.18-rc3]
> [cannot apply to next-20180629]
> [if your patch is applied to the wrong git tree,
On 07/01/2018 07:58 PM, kbuild test robot wrote:
> Hi John,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.18-rc3]
> [cannot apply to next-20180629]
> [if your patch is applied to the wrong git tree,
Hi Rafael,
it is two weeks since this email. Probably it was lost some where in the
space time continuum.
Can you please respond to it :)
On 17.06.2018 09:05, Shawn Guo wrote:
> On Tue, Jun 12, 2018 at 04:33:05PM +0200, Rafael J. Wysocki wrote:
>> On Tuesday, June 12, 2018 2:42:12 PM CEST
Hi Rafael,
it is two weeks since this email. Probably it was lost some where in the
space time continuum.
Can you please respond to it :)
On 17.06.2018 09:05, Shawn Guo wrote:
> On Tue, Jun 12, 2018 at 04:33:05PM +0200, Rafael J. Wysocki wrote:
>> On Tuesday, June 12, 2018 2:42:12 PM CEST
Hi Martijn,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 021c91791a5e7e85c567452f1be3e4c2c6cb6063
commit: 1190b4e38f97023154e6b3bef61b251aa5f970d0 ANDROID: binder: remove 32-bit
binder interface.
date: 7 weeks
Hi Martijn,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 021c91791a5e7e85c567452f1be3e4c2c6cb6063
commit: 1190b4e38f97023154e6b3bef61b251aa5f970d0 ANDROID: binder: remove 32-bit
binder interface.
date: 7 weeks
On 29-06-18, 16:52, Sébastien Szymanski wrote:
> i.MX6ULL has different operating ranges than i.MX6UL so add the
> operating points for the i.MX6ULL and removed them form board device
s/removed/remove/
s/form/from/
> trees. A 25mV offset is added to the minimum allowed values like for the
>
On 29-06-18, 16:52, Sébastien Szymanski wrote:
> i.MX6ULL has different operating ranges than i.MX6UL so add the
> operating points for the i.MX6ULL and removed them form board device
s/removed/remove/
s/form/from/
> trees. A 25mV offset is added to the minimum allowed values like for the
>
Hi all,
Changes since 20180629:
New tree: siox
The btrfs-kdave tree lost its build failure.
The fbdev tree lost its build failure.
The net-next tree gained conflicts against the net and rdma trees.
The akpm-current tree still had its build failure for which I reverted
a commit.
Non-merge
Hi all,
Changes since 20180629:
New tree: siox
The btrfs-kdave tree lost its build failure.
The fbdev tree lost its build failure.
The net-next tree gained conflicts against the net and rdma trees.
The akpm-current tree still had its build failure for which I reverted
a commit.
Non-merge
On Sun, Jul 01, 2018 at 08:11:32PM -0700, Paul E. McKenney wrote:
> On Sun, Jul 01, 2018 at 05:35:53PM -0700, Joel Fernandes wrote:
> > On Sun, Jul 01, 2018 at 03:27:49PM -0700, Paul E. McKenney wrote:
> > [...]
> > > > > +/*
> > > > > + * Report a deferred quiescent state if needed and safe to do
On Sun, Jul 01, 2018 at 08:11:32PM -0700, Paul E. McKenney wrote:
> On Sun, Jul 01, 2018 at 05:35:53PM -0700, Joel Fernandes wrote:
> > On Sun, Jul 01, 2018 at 03:27:49PM -0700, Paul E. McKenney wrote:
> > [...]
> > > > > +/*
> > > > > + * Report a deferred quiescent state if needed and safe to do
On 07/01/2018 07:47 PM, kbuild test robot wrote:
> Hi John,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.18-rc3]
> [cannot apply to next-20180629]
> [if your patch is applied to the wrong git tree, please drop
On 07/01/2018 07:47 PM, kbuild test robot wrote:
> Hi John,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.18-rc3]
> [cannot apply to next-20180629]
> [if your patch is applied to the wrong git tree, please drop
On 07/01/2018 07:11 PM, kbuild test robot wrote:
> Hi John,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.18-rc3]
> [cannot apply to next-20180629]
> [if your patch is applied to the wrong git tree,
On 07/01/2018 07:11 PM, kbuild test robot wrote:
> Hi John,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.18-rc3]
> [cannot apply to next-20180629]
> [if your patch is applied to the wrong git tree,
Hi Issac,
On Fri, Jun 29, 2018 at 01:55:12PM -0700, Isaac J. Manjarres wrote:
> When cpu_stop_queue_two_works() begins to wake the stopper
> threads, it does so without preemption disabled, which leads
> to the following race condition:
>
> The source CPU calls cpu_stop_queue_two_works(), with
Hi Issac,
On Fri, Jun 29, 2018 at 01:55:12PM -0700, Isaac J. Manjarres wrote:
> When cpu_stop_queue_two_works() begins to wake the stopper
> threads, it does so without preemption disabled, which leads
> to the following race condition:
>
> The source CPU calls cpu_stop_queue_two_works(), with
Hi James,
On 2018/6/29 23:58, James Morse wrote:
> Hi Dongjiu Geng,
>
> This patch doesn't apply on v4.18-rc2.
>
> Documentation/virtual/kvm/api.txt already has a 8.18 section. I guess you
> based
> this on v4.17.
Yes, indeed I based on v4.17.
>
> For posting patches, please use the latest
Hi James,
On 2018/6/29 23:58, James Morse wrote:
> Hi Dongjiu Geng,
>
> This patch doesn't apply on v4.18-rc2.
>
> Documentation/virtual/kvm/api.txt already has a 8.18 section. I guess you
> based
> this on v4.17.
Yes, indeed I based on v4.17.
>
> For posting patches, please use the latest
Linus Torvalds writes:
> On Fri, Jun 29, 2018 at 1:42 PM Larry Finger
> wrote:
>>
>> I have more information regarding this BUG. Line 700 of page-flags.h is the
>> macro PAGE_TYPE_OPS(Table, table). For further debugging, I manually expanded
>> the macro, and found that the bug line is
Linus Torvalds writes:
> On Fri, Jun 29, 2018 at 1:42 PM Larry Finger
> wrote:
>>
>> I have more information regarding this BUG. Line 700 of page-flags.h is the
>> macro PAGE_TYPE_OPS(Table, table). For further debugging, I manually expanded
>> the macro, and found that the bug line is
Li Zhijian (3):
selftests/android: fix compiling error
selftests/android: initialize heap_type to avoid compiling warning
selftests/gpio: unset OUTPUT for build tools/gpio
tools/testing/selftests/android/ion/Makefile| 5 -
tools/testing/selftests/android/ion/ionapp_export.c |
lizhijian@haswell-OptiPlex-9020:/home/lizj/linux/tools/testing/selftests/android/ion$
make
gcc -I. -I../../../../../drivers/staging/android/uapi/
-I../../../../../usr/include/ -Wall -O2 -gionapp_export.c ipcsocket.c
ionutils.c -o ionapp_export
gcc -I.
when we execute 'make' to build selftests, the TOP Makefile build gpio like:
selftests$ make ARCH= CROSS_COMPILE=
OUTPUT=/home/lizj/linux/tools/testing/selftests/gpio -C gpio
...
make[2]: Leaving directory '/home/lizj/linux/tools/gpio'
gcc -O2 -g -std=gnu99 -Wall
Li Zhijian (3):
selftests/android: fix compiling error
selftests/android: initialize heap_type to avoid compiling warning
selftests/gpio: unset OUTPUT for build tools/gpio
tools/testing/selftests/android/ion/Makefile| 5 -
tools/testing/selftests/android/ion/ionapp_export.c |
lizhijian@haswell-OptiPlex-9020:/home/lizj/linux/tools/testing/selftests/android/ion$
make
gcc -I. -I../../../../../drivers/staging/android/uapi/
-I../../../../../usr/include/ -Wall -O2 -gionapp_export.c ipcsocket.c
ionutils.c -o ionapp_export
gcc -I.
when we execute 'make' to build selftests, the TOP Makefile build gpio like:
selftests$ make ARCH= CROSS_COMPILE=
OUTPUT=/home/lizj/linux/tools/testing/selftests/gpio -C gpio
...
make[2]: Leaving directory '/home/lizj/linux/tools/gpio'
gcc -O2 -g -std=gnu99 -Wall
root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# make
make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
make[1]: Entering directory
'/root/linux-v4.18-rc2/tools/testing/selftests/android/ion'
gcc -I.
root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# make
make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
make[1]: Entering directory
'/root/linux-v4.18-rc2/tools/testing/selftests/android/ion'
gcc -I.
From: Honghui Zhang
The MTCMOS of PCIe Host for MT2712 and MT7622 will be off when system
suspend, and all the internal control register will be reset after system
resume. The PCIe link should be re-established and the related control
register values should be re-set after system resume.
From: Honghui Zhang
The MTCMOS of PCIe Host for MT2712 and MT7622 will be off when system
suspend, and all the internal control register will be reset after system
resume. The PCIe link should be re-established and the related control
register values should be re-set after system resume.
From: Honghui Zhang
The Mediatek's host controller has two slots, each with it's own control
registers. The host driver need to identify which slot was connected
in order to access the device's configuration space. There's problem
for current host driver to find out which slot was connected to
From: Honghui Zhang
Implement remove callback function for Mediatek PCIe driver to add
loadable kernel module support.
Signed-off-by: Honghui Zhang
---
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pcie-mediatek.c | 60 +++---
2 files
From: Honghui Zhang
The Mediatek's host controller has two slots, each with it's own control
registers. The host driver need to identify which slot was connected
in order to access the device's configuration space. There's problem
for current host driver to find out which slot was connected to
From: Honghui Zhang
Implement remove callback function for Mediatek PCIe driver to add
loadable kernel module support.
Signed-off-by: Honghui Zhang
---
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pcie-mediatek.c | 60 +++---
2 files
From: Honghui Zhang
The clocks was not enabled when enable MSI. This patch fix this
issue by calling mtk_pcie_enable_msi in mtk_pcie_startup_port_v2
since the clock was all enabled at that time.
The function of mtk_pcie_startup_port_v2's define location is
re-arranged to avoid
From: Honghui Zhang
This patchset includes misc patchs:
The first patch fixup the mtk_pcie_find_port logical which will cause system
could not touch the EP's configuration space which was connected to PCIe slot 1.
The second patch fixup the enable msi logical, the operation to enable msi
From: Honghui Zhang
The clocks was not enabled when enable MSI. This patch fix this
issue by calling mtk_pcie_enable_msi in mtk_pcie_startup_port_v2
since the clock was all enabled at that time.
The function of mtk_pcie_startup_port_v2's define location is
re-arranged to avoid
From: Honghui Zhang
This patchset includes misc patchs:
The first patch fixup the mtk_pcie_find_port logical which will cause system
could not touch the EP's configuration space which was connected to PCIe slot 1.
The second patch fixup the enable msi logical, the operation to enable msi
On 07/01/18 at 11:28pm, Pavel Tatashin wrote:
> > > So, on the first failure, we even stop trying to populate other
> > > sections. No more memory to do so.
> >
> > This is the thing I worry about. In old sparse_mem_maps_populate_node()
> > you can see, when not present or failed to populate, just
On 07/01/18 at 11:28pm, Pavel Tatashin wrote:
> > > So, on the first failure, we even stop trying to populate other
> > > sections. No more memory to do so.
> >
> > This is the thing I worry about. In old sparse_mem_maps_populate_node()
> > you can see, when not present or failed to populate, just
> > So, on the first failure, we even stop trying to populate other
> > sections. No more memory to do so.
>
> This is the thing I worry about. In old sparse_mem_maps_populate_node()
> you can see, when not present or failed to populate, just continue. This
> is the main difference between yours
> > So, on the first failure, we even stop trying to populate other
> > sections. No more memory to do so.
>
> This is the thing I worry about. In old sparse_mem_maps_populate_node()
> you can see, when not present or failed to populate, just continue. This
> is the main difference between yours
On 07/02/18 at 11:14am, Baoquan He wrote:
> On 07/01/18 at 11:03pm, Pavel Tatashin wrote:
> > > Ah, yes, I misunderstood it, sorry for that.
> > >
> > > Then I have only one concern, for vmemmap case, if one section doesn't
> > > succeed to populate its memmap, do we need to skip all the remaining
On 07/02/18 at 11:14am, Baoquan He wrote:
> On 07/01/18 at 11:03pm, Pavel Tatashin wrote:
> > > Ah, yes, I misunderstood it, sorry for that.
> > >
> > > Then I have only one concern, for vmemmap case, if one section doesn't
> > > succeed to populate its memmap, do we need to skip all the remaining
On 07/01/18 at 11:03pm, Pavel Tatashin wrote:
> > Ah, yes, I misunderstood it, sorry for that.
> >
> > Then I have only one concern, for vmemmap case, if one section doesn't
> > succeed to populate its memmap, do we need to skip all the remaining
> > sections in that node?
>
> Yes, in
On 07/01/18 at 11:03pm, Pavel Tatashin wrote:
> > Ah, yes, I misunderstood it, sorry for that.
> >
> > Then I have only one concern, for vmemmap case, if one section doesn't
> > succeed to populate its memmap, do we need to skip all the remaining
> > sections in that node?
>
> Yes, in
On Sun, Jul 01, 2018 at 05:35:53PM -0700, Joel Fernandes wrote:
> On Sun, Jul 01, 2018 at 03:27:49PM -0700, Paul E. McKenney wrote:
> [...]
> > > > +/*
> > > > + * Report a deferred quiescent state if needed and safe to do so.
> > > > + * As with rcu_preempt_need_deferred_qs(), "safe" involves
On Sun, Jul 01, 2018 at 05:35:53PM -0700, Joel Fernandes wrote:
> On Sun, Jul 01, 2018 at 03:27:49PM -0700, Paul E. McKenney wrote:
> [...]
> > > > +/*
> > > > + * Report a deferred quiescent state if needed and safe to do so.
> > > > + * As with rcu_preempt_need_deferred_qs(), "safe" involves
> > + if (!usemap) {
> > + pr_err("%s: usemap allocation failed", __func__);
>
> Wondering if we can provide more useful information for better debugging
> if failed. E.g here tell on what nid the usemap allocation failed.
>
> > +
> > + if (!usemap) {
> > + pr_err("%s: usemap allocation failed", __func__);
>
> Wondering if we can provide more useful information for better debugging
> if failed. E.g here tell on what nid the usemap allocation failed.
>
> > +
> Ah, yes, I misunderstood it, sorry for that.
>
> Then I have only one concern, for vmemmap case, if one section doesn't
> succeed to populate its memmap, do we need to skip all the remaining
> sections in that node?
Yes, in sparse_populate_node() we have the following:
294 for (pnum =
> Ah, yes, I misunderstood it, sorry for that.
>
> Then I have only one concern, for vmemmap case, if one section doesn't
> succeed to populate its memmap, do we need to skip all the remaining
> sections in that node?
Yes, in sparse_populate_node() we have the following:
294 for (pnum =
On Sun, Jul 01, 2018 at 05:37:32PM -0700, Joel Fernandes wrote:
> On Sun, Jul 01, 2018 at 03:25:01PM -0700, Paul E. McKenney wrote:
> [...]
> > > > @@ -602,6 +589,66 @@ static void rcu_read_unlock_special(struct
> > > > task_struct *t)
> > > > }
> > > > }
> > > >
> > > > +/*
> > > > +
On Sun, Jul 01, 2018 at 05:37:32PM -0700, Joel Fernandes wrote:
> On Sun, Jul 01, 2018 at 03:25:01PM -0700, Paul E. McKenney wrote:
> [...]
> > > > @@ -602,6 +589,66 @@ static void rcu_read_unlock_special(struct
> > > > task_struct *t)
> > > > }
> > > > }
> > > >
> > > > +/*
> > > > +
Hi John,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.18-rc3]
[cannot apply to next-20180629]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi John,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.18-rc3]
[cannot apply to next-20180629]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On 2018/7/2 10:16, Guenter Roeck wrote:
> On 07/01/2018 06:53 PM, Chao Yu wrote:
>> On 2018/7/2 4:57, Guenter Roeck wrote:
>>> gcc 8.1.0 complains:
>>>
>>> fs/f2fs/namei.c: In function 'f2fs_update_extension_list':
>>> fs/f2fs/namei.c:257:3: warning:
>>> 'strncpy' output truncated before
On 2018/7/2 10:16, Guenter Roeck wrote:
> On 07/01/2018 06:53 PM, Chao Yu wrote:
>> On 2018/7/2 4:57, Guenter Roeck wrote:
>>> gcc 8.1.0 complains:
>>>
>>> fs/f2fs/namei.c: In function 'f2fs_update_extension_list':
>>> fs/f2fs/namei.c:257:3: warning:
>>> 'strncpy' output truncated before
On 07/01/18 at 10:04pm, Pavel Tatashin wrote:
> +/*
> + * Initialize sparse on a specific node. The node spans [pnum_begin,
> pnum_end)
> + * And number of present sections in this node is map_count.
> + */
> +void __init sparse_init_nid(int nid, unsigned long pnum_begin,
> +
On 07/01/18 at 10:04pm, Pavel Tatashin wrote:
> +/*
> + * Initialize sparse on a specific node. The node spans [pnum_begin,
> pnum_end)
> + * And number of present sections in this node is map_count.
> + */
> +void __init sparse_init_nid(int nid, unsigned long pnum_begin,
> +
On 07/01/18 at 10:43pm, Pavel Tatashin wrote:
> On Sun, Jul 1, 2018 at 10:31 PM Baoquan He wrote:
> >
> > On 07/01/18 at 10:18pm, Pavel Tatashin wrote:
> > > > Here, I think it might be not right to jump to 'failed' directly if one
> > > > section of the node failed to populate memmap. I think
On 07/01/18 at 10:43pm, Pavel Tatashin wrote:
> On Sun, Jul 1, 2018 at 10:31 PM Baoquan He wrote:
> >
> > On 07/01/18 at 10:18pm, Pavel Tatashin wrote:
> > > > Here, I think it might be not right to jump to 'failed' directly if one
> > > > section of the node failed to populate memmap. I think
On Saturday 30 June 2018 04:29 AM, Santosh Shilimkar wrote:
> On 6/27/2018 9:15 PM, Kishon Vijay Abraham I wrote:
>> Santosh,
>>
>> On Friday 22 June 2018 03:46 PM, Kishon Vijay Abraham I wrote:
>>> Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
>>> binding.
>>>
>>> I've
On Saturday 30 June 2018 04:29 AM, Santosh Shilimkar wrote:
> On 6/27/2018 9:15 PM, Kishon Vijay Abraham I wrote:
>> Santosh,
>>
>> On Friday 22 June 2018 03:46 PM, Kishon Vijay Abraham I wrote:
>>> Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
>>> binding.
>>>
>>> I've
From: Randy Dunlap
Currently for x86, the "Memory Management" kconfig options are
displayed under "Processor type and features." This tends to
make them hidden or difficult to find.
This patch makes Memory Managment options a first-class menu by moving
it away from "Processor type and
From: Randy Dunlap
Currently for x86, the "Memory Management" kconfig options are
displayed under "Processor type and features." This tends to
make them hidden or difficult to find.
This patch makes Memory Managment options a first-class menu by moving
it away from "Processor type and
Hi John,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18-rc3]
[cannot apply to next-20180629]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi John,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18-rc3]
[cannot apply to next-20180629]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
From: Randy Dunlap
Verify that 'depmod' ($DEPMOD) is installed.
This is a partial revert of 620c231c7a7f (from 2012):
("kbuild: do not check for ancient modutils tools")
Also update Documentation/process/changes.rst to refer to
kmod instead of module-init-tools.
Fixes kernel bugzilla
From: Randy Dunlap
Verify that 'depmod' ($DEPMOD) is installed.
This is a partial revert of 620c231c7a7f (from 2012):
("kbuild: do not check for ancient modutils tools")
Also update Documentation/process/changes.rst to refer to
kmod instead of module-init-tools.
Fixes kernel bugzilla
1 - 100 of 1748 matches
Mail list logo
