The function patch_insn_write() expects that the text_mutex is already
held. There's a case that text_mutex is acquired by ftrace_run_update_code()
under syscall context but then patch_insn_write() will be executed under the
migration kthread context as we involves stop machine. So we should remove
The limit of 4 chipselects for the BCM2835 was not required and also was
not inforced. Without inforcement it was possible to make a device tree
over this limit which would trample memory.
The chipselect count is now obtained from the device tree and expanded
if more devices are added.
Signed-off
Hi,
On Tue, Mar 09, 2021 at 11:22:26AM -0800, Roman Kiryanov wrote:
> On Fri, Feb 5, 2021 at 6:31 PM wrote:
> >
> > From: Roman Kiryanov
> >
> > This will allow to use the BATTERY_GOLDFISH driver
> > without enabling GOLDFISH.
>
> Hi Sebastian, could you please take a look at my patch?
>
> Tha
Dan's address bounces, and has been bouncing for some time as he moved
to other projects.
I believe TI should be more careful with this, and should assign
alternate contacts for their drivers.
Anyway what we can do now is to remove the obsolete address.
Signed-off-by: Pavel Machek
---
(I'm s
On Fri, Feb 5, 2021 at 6:31 PM wrote:
>
> From: Roman Kiryanov
>
> This will allow to use the BATTERY_GOLDFISH driver
> without enabling GOLDFISH.
Hi Sebastian, could you please take a look at my patch?
Thank you.
On Tue, Feb 16, 2021 at 10:59:51PM -0500, Sean Behan wrote:
> ---
> drivers/staging/emxx_udc/emxx_udc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/emxx_udc/emxx_udc.c
> b/drivers/staging/emxx_udc/emxx_udc.c
> index 3536c03ff523..741147a4f0fe 100644
> --- a/drivers/st
---
drivers/staging/emxx_udc/emxx_udc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 3536c03ff523..741147a4f0fe 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -38,7
From: Roman Kiryanov
This will allow to use the BATTERY_GOLDFISH driver
without enabling GOLDFISH.
Signed-off-by: Roman Kiryanov
---
drivers/power/supply/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfi
On 18/1/21 9:57 pm, Mel Gorman wrote:
On Mon, Jan 18, 2021 at 09:32:18PM +1100, Imran Khan wrote:
task_numa_fault is invoked from do_numa_page/do_huge_pmd_numa_page,
for task_numa_work induced memory faults. task_numa_work is scheduled
from task_tick_numa which is invoked only if sched_numa_b
On Mon, Jan 18, 2021 at 09:32:18PM +1100, Imran Khan wrote:
> task_numa_fault is invoked from do_numa_page/do_huge_pmd_numa_page,
> for task_numa_work induced memory faults. task_numa_work is scheduled
> from task_tick_numa which is invoked only if sched_numa_balancing
> is true.
>
> So task_numa_
task_numa_fault is invoked from do_numa_page/do_huge_pmd_numa_page,
for task_numa_work induced memory faults. task_numa_work is scheduled
from task_tick_numa which is invoked only if sched_numa_balancing
is true.
So task_numa_fault will not get invoked if sched_numa_balancing is
false and hence we
On Mon, Nov 30, 2020 at 7:42 PM Masahiro Yamada wrote:
>
> On Tue, Dec 1, 2020 at 12:29 PM Masahiro Yamada wrote:
> >
> > The -gdwarf-4 flag is supported by GCC 4.5+, and also by Clang.
> >
> > You can see it at https://godbolt.org/z/6ed1oW
(this link misses -gdwarf-4 for clang, but I think that
On Tue, Dec 1, 2020 at 12:29 PM Masahiro Yamada wrote:
>
> The -gdwarf-4 flag is supported by GCC 4.5+, and also by Clang.
>
> You can see it at https://godbolt.org/z/6ed1oW
>
> For gcc 4.5.3 pane,line 37:.value 0x4
> For clang 10.0.1 pane, line 117: .short 4
>
> Given Documentation/
The -gdwarf-4 flag is supported by GCC 4.5+, and also by Clang.
You can see it at https://godbolt.org/z/6ed1oW
For gcc 4.5.3 pane,line 37:.value 0x4
For clang 10.0.1 pane, line 117: .short 4
Given Documentation/process/changes.rst stating GCC 4.9 is the minimal
version, this cc-opt
From: Lei Chen
It's unnecessary to call wbt_update_limits explicitly within wbt_init,
because it will be called in the following function wbt_queue_depth_changed.
Signed-off-by: Lei Chen
---
block/blk-wbt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/blk-wbt.c b/block/blk-wbt.c
in
On Wed, Sep 09, 2020 at 05:36:32PM +0800, Yi Li wrote:
> Remove duplicate include file
>
> Signed-off-by: Yi Li
Reviewed-by: Mike Rapoport
> ---
> arch/arm/mm/mmu.c | 1 -
> mm/slab.h | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> in
Remove duplicate include file
Signed-off-by: Yi Li
---
arch/arm/mm/mmu.c | 1 -
mm/slab.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index c36f977b2ccb..7bbcdb29413e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -34,7 +34,6 @@
This patch was generated, and sent by a script I was working on (and
apparently, still am), that would run sparse,
detect unused variables and eliminate them. However, upon manual
inspection, it became clear
to me that these functions are in fact necessary. I'm sorry this
mistake happened. Kindly i
A few unused variables that were defined were found and removed.
Signed-off-by: Anant Thazhemadam
---
drivers/staging/comedi/drivers/dt2814.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/dt2814.c
b/drivers/staging/comedi/drivers/dt2814.c
index bcf4d5444faf
Hello,
On Sat, 29 Aug 2020, Yaroslav Bolyukin wrote:
> This dependency was added as part of commit ecefa32ffda201975
> ("ipvs: Fix faulty IPv6 extension header handling in IPVS"), because it
> had dependency on ipv6_find_hdr, which was located in iptables-specific
> code
>
> But it is
This dependency was added as part of commit ecefa32ffda201975
("ipvs: Fix faulty IPv6 extension header handling in IPVS"), because it
had dependency on ipv6_find_hdr, which was located in iptables-specific
code
But it is no longer required after commit e6f890cfde0e74d5b
("ipv6:Move ipv6_find_hdr()
Le 28/08/2020 à 00:07, Lach a écrit :
> This dependency was added in 63dca2c0b0e7a92cb39d1b1ecefa32ffda201975,
> because this commit had dependency on
> ipv6_find_hdr, which was located in iptables-specific code
>
> But it is no longer required, because
> f8f626754ebeca613cf1af2e6f890cfde0e74d5b
Xu Wang wrote:
> Remove unneeded variable t1 seed_encrypt() and
> seed_decrypt().
>
> Signed-off-by: Xu Wang
> ---
> crypto/seed.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/crypto/seed.c b/crypto/seed.c
> index 5e3bef3a617d..69b3058d6a32 100644
> --- a/crypto/s
This dependency was added in 63dca2c0b0e7a92cb39d1b1ecefa32ffda201975, because
this commit had dependency on
ipv6_find_hdr, which was located in iptables-specific code
But it is no longer required, because f8f626754ebeca613cf1af2e6f890cfde0e74d5b
moved them to a more common location
---
include
Hello,
On Fri, 28 Aug 2020, Lach wrote:
> This dependency was added in 63dca2c0b0e7a92cb39d1b1ecefa32ffda201975,
> because this commit had dependency on
> ipv6_find_hdr, which was located in iptables-specific code
>
> But it is no longer required, because
> f8f626754ebeca613cf1af2e6f
This dependency was added in 63dca2c0b0e7a92cb39d1b1ecefa32ffda201975, because
this commit had dependency on
ipv6_find_hdr, which was located in iptables-specific code
But it is no longer required, because f8f626754ebeca613cf1af2e6f890cfde0e74d5b
moved them to a more common location
---
net/net
Hi Luc,
On Tue, Aug 25, 2020 at 1:25 AM Luc Van Oostenryck
wrote:
>
> Sparse supports __has_attribute() since 2018-08-31, so the comment
> is not true anymore but more importantly is rather confusing.
>
> So remove it.
>
> Signed-off-by: Luc Van Oostenryck
Thanks! Queuing it.
Cheers,
Miguel
Sparse supports __has_attribute() since 2018-08-31, so the comment
is not true anymore but more importantly is rather confusing.
So remove it.
Signed-off-by: Luc Van Oostenryck
---
include/linux/compiler_attributes.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/compile
Remove unneeded variable t1 seed_encrypt() and
seed_decrypt().
Signed-off-by: Xu Wang
---
crypto/seed.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/seed.c b/crypto/seed.c
index 5e3bef3a617d..69b3058d6a32 100644
--- a/crypto/seed.c
+++ b/crypto/seed.c
@@ -366,7
Hi,
On Mon, Aug 03, 2020 at 10:44:49AM -0300, Daniel Gutson wrote:
> Currently, the intel-spi-pci driver tries to unconditionally set
> the SPI chip writeable. After discussing in the LKML, the original
> author decided that it was better to remove the attempt.
>
> Context, the intel-spi has a m
On Mon, Aug 3, 2020 at 10:55 AM Arnd Bergmann wrote:
>
> On Mon, Aug 3, 2020 at 3:45 PM Daniel Gutson
> wrote:
>
> > However, this flag applies only for a number of devices, coming from the
> > platform driver, whereas the devices detected through the PCI driver
> > (intel-spi-pci) are not subjec
On Mon, Aug 3, 2020 at 3:45 PM Daniel Gutson
wrote:
> However, this flag applies only for a number of devices, coming from the
> platform driver, whereas the devices detected through the PCI driver
> (intel-spi-pci) are not subject to this check since the configuration
> takes place in intel-spi-
Currently, the intel-spi-pci driver tries to unconditionally set
the SPI chip writeable. After discussing in the LKML, the original
author decided that it was better to remove the attempt.
Context, the intel-spi has a module argument that controls
whether the driver attempts to turn the SPI flash
Hi Nico,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.8-rc3 next-20200702]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as docum
Allow padata_do_multithreaded function to be called after bootstrap.
Signed-off-by: Nico Pache
---
include/linux/padata.h | 2 +-
kernel/padata.c| 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/padata.h b/include/linux/padata.h
index 7302efff5..2e7
Am 29.06.20 um 23:10 schrieb Wolfram Sang:
Hi Alexander,
thanks for trying to fix this, yet I have some doubts.
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:
Rationale:
https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
I think we need some text here
Hi Alexander,
thanks for trying to fix this, yet I have some doubts.
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:
> Rationale:
> https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
I think we need some text here. Clicking on a link to understand what a
patc
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:
> Rationale:
> https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
>
> Signed-off-by: Alexander A. Klimov
> ---
> @Jon I thought about what I said and *no*, unfortunately I *can't* automate
> the detection of su
Rationale:
https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
Signed-off-by: Alexander A. Klimov
---
@Jon I thought about what I said and *no*, unfortunately I *can't* automate
the detection of such as easy as the HTTPSifying. As you maybe see below
cleaning up is even "harder"
On Tue, Apr 28, 2020 at 05:18:13PM +0200, Daniel Vetter wrote:
> On Mon, Apr 27, 2020 at 10:05:17AM +0200, Michal Orzel wrote:
> > As suggested by the TODO list of DRM subsystem:
> > -remove the member hsync of drm_display_mode
> > -convert code using hsync member to use drm_mode_hsync()
> >
> > S
On Mon, Apr 27, 2020 at 10:05:17AM +0200, Michal Orzel wrote:
> As suggested by the TODO list of DRM subsystem:
> -remove the member hsync of drm_display_mode
> -convert code using hsync member to use drm_mode_hsync()
>
> Signed-off-by: Michal Orzel
I think Ville has a bunch of patches doing thi
On 10/04, Joel Fernandes wrote:
>
> On Fri, Oct 04, 2019 at 05:41:03PM +0200, Oleg Nesterov wrote:
> > On 10/04, Joel Fernandes (Google) wrote:
> > >
> > > Taking a step back, why did we intend to have
> > > to wait for a new GP if another rcu_sync_exit() comes while one is still
> > > in progress?
Hi "Joel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on rcu/dev]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
ba
Hi "Joel,
I love your patch! Yet something to improve:
[auto build test ERROR on rcu/dev]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tre
Hi Oleg,
On Fri, Oct 04, 2019 at 05:41:03PM +0200, Oleg Nesterov wrote:
> On 10/04, Joel Fernandes (Google) wrote:
> >
> > But this is not always true if you consider the following events:
>
> I'm afraid I missed your point, but...
>
> > -->
> > GP num 11
On 10/04, Joel Fernandes (Google) wrote:
>
> But this is not always true if you consider the following events:
I'm afraid I missed your point, but...
> -->
> GP num 11 2
> GP state ie px r
On Fri, Oct 04, 2019 at 10:57:41AM -0400, Joel Fernandes (Google) wrote:
> From: Joel Fernandes
>
> Please consider this is an RFC for discussion only. Just want to discuss
> why the GP_REPLAY state is needed at all.
And I messed up the subject prefix, but this is *really* RFC and for
discussion
From: Joel Fernandes
Please consider this is an RFC for discussion only. Just want to discuss
why the GP_REPLAY state is needed at all.
Here's the intention AFAICS:
When rcu_sync_exit() has happened, the gp_state changes to GP_EXIT while
we wait for a grace period before transitioning to GP_IDLE
From: marcussorealheis
---
drivers/clk/rockchip/clk-cpu.c | 2 +-
drivers/clk/samsung/clk-cpu.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
fs/xfs/xfs_inode.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions
From: Corey Minyard
These files were added as part of the FMC subsystem, but were not
removed when the FMC subsystem was removed in 6a80b30086 "fmc: Delete
the FMC subsystem". They have no users, so remove them.
Signed-off-by: Corey Minyard
Cc: Linus Walleij
Cc: Pat Riehecky
Cc: Alessandro R
Hi,
(CC: +devicetree list:
memreserving the initrd, which linux then frees causes a zombie memreserve in
all future
kexec'd kernels)
On 03/07/2019 12:42, huang.jun...@zte.com.cn wrote:
On 02/07/2019 11:34, Yi Wang wrote:
> From: Junhua Huang
> The 'commit 50d7ba36b916 ("arm64: expo
Hi,
On 03/07/2019 10:16, huang.jun...@zte.com.cn wrote:
>> On 02/07/2019 11:34, Yi Wang wrote:
>>> From: Junhua Huang
>>> The 'commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
>>> /proc/iomem")'
>>> show the reserved memblock in /proc/iomem. But the initrd's reserved
>>> memb
Hello,
On 02/07/2019 11:34, Yi Wang wrote:
> From: Junhua Huang
>
> The 'commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
> /proc/iomem")'
> show the reserved memblock in /proc/iomem. But the initrd's reserved memblock
> will be freed in free_initrd_mem(), which executes afte
From: Junhua Huang
The 'commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
/proc/iomem")'
show the reserved memblock in /proc/iomem. But the initrd's reserved memblock
will be freed in free_initrd_mem(), which executes after the
reserve_memblock_reserved_regions().
So there are
On Wed, Jun 12, 2019 at 11:12 AM David Brown wrote:
>
> I no longer regularly work on this platform, and only have a few
> increasingly outdated boards. Andy has primarily been doing the
> maintenance.
>
> Signed-off-by: David Brown
> ---
> Resending this, hopefully with text=flowed not set in t
I no longer regularly work on this platform, and only have a few
increasingly outdated boards. Andy has primarily been doing the
maintenance.
Signed-off-by: David Brown
---
Resending this, hopefully with text=flowed not set in the email
headers.
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
On Wed, Jun 12, 2019 at 09:54:11AM -0600, David Brown wrote:
> I no longer regularly work on this platform, and only have a few
> increasingly outdated boards. Andy has primarily been doing the
> maintenance.
>
> Signed-off-by: David Brown
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-
I no longer regularly work on this platform, and only have a few
increasingly outdated boards. Andy has primarily been doing the
maintenance.
Signed-off-by: David Brown
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 57f496cff999..27df8f46a283 1
On Tue, 07 May 2019, Masahiro Yamada wrote:
> These files do not define (USBHS_)DRIVER_NAME. Yet, they can be
> successfully compiled because they are never built as a module by
> anyone, i.e, the MODULE_ALIAS() calls are always no-op.
>
> A problem showed up when a patch "moduleparam: Save infor
* Daniel Lezcano [190506 17:40]:
> On 06/05/2019 19:28, Masahiro Yamada wrote:
> > These files do not define (USBHS_)DRIVER_NAME. Yet, they can be
> > successfully compiled because they are never built as a module by
> > anyone, i.e, the MODULE_ALIAS() calls are always no-op.
> >
> > A problem sh
On 06/05/2019 19:28, Masahiro Yamada wrote:
> These files do not define (USBHS_)DRIVER_NAME. Yet, they can be
> successfully compiled because they are never built as a module by
> anyone, i.e, the MODULE_ALIAS() calls are always no-op.
>
> A problem showed up when a patch "moduleparam: Save inform
These files do not define (USBHS_)DRIVER_NAME. Yet, they can be
successfully compiled because they are never built as a module by
anyone, i.e, the MODULE_ALIAS() calls are always no-op.
A problem showed up when a patch "moduleparam: Save information about
built-in modules in separate file" is appl
On Sat, Mar 30, 2019 at 1:54 PM Masahiro Yamada
wrote:
>
> The "WITH Linux-syscall-note" should be added to headers exported to
> the user-space.
>
> Some kernel-space headers have "WITH Linux-syscall-note", which seems
> a mistake.
>
> [1] arch/x86/include/asm/hyperv-tlfs.h
>
> 5a4858032217 ("x86
The "WITH Linux-syscall-note" should be added to headers exported to
the user-space.
Some kernel-space headers have "WITH Linux-syscall-note", which seems
a mistake.
[1] arch/x86/include/asm/hyperv-tlfs.h
5a4858032217 ("x86/hyper-v: move hyperv.h out of uapi") moved this file
out of uapi, but mi
On Tue, 2019-02-26 at 17:43 -0700, Shaobo He wrote:
> The fixes included in this commit essentially removes NULL pointer
> checks on the return values of function `get_queue_ctx` as well as
> `v4l2_m2m_get_vq` defined in file v4l2-mem2mem.c.
>
> Function `get_queue_ctx` is very unlikely to return
The fixes included in this commit essentially removes NULL pointer
checks on the return values of function `get_queue_ctx` as well as
`v4l2_m2m_get_vq` defined in file v4l2-mem2mem.c.
Function `get_queue_ctx` is very unlikely to return a NULL pointer
because its return value is an address composed
Hi Shaobo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v5.0-rc8 next-20190225]
[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 Shaobo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v5.0-rc8 next-20190225]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/
The fixes included in this commit essentially removes NULL pointer
checks on the return values of function `get_queue_ctx` as well as
`v4l2_m2m_get_vq` defined in file v4l2-mem2mem.c.
Function `get_queue_ctx` is very unlikely to return a NULL pointer
because its return value is an address composed
On Fri, Feb 08, 2019 at 02:04:38PM +, Tom Murphy wrote:
> This variable is useless.
>
> ---
> drivers/iommu/dma-iommu.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
A similar change is already in the iommu tree[1].
Joerg
[1]
https://git.kernel.org/pub/scm/linux/kernel
This variable is useless.
---
drivers/iommu/dma-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 8e04b0603a4a..eff301d5e496 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -291,7 +29
This patchset introduces support for MediaTek Command-Queue DMA controller in
dt-bindings, and simplifies the controller by removing redundant structures.
Main changes to the initial version:
- remove redundant queue structure in mtk_cqdma_pchan
- remove redundant completion management
- remove r
On Fri, Jan 04, 2019 at 10:03:42AM -0800, Linus Torvalds wrote:
> On Fri, Jan 4, 2019 at 9:42 AM Guenter Roeck wrote:
> >
> > ... and this is just the very first build I happened to try this morning.
>
> It will fail for all sparc32 builds. And unlike the powerpc case, I
> hadn't even noticed thi
On Fri, Jan 4, 2019 at 9:42 AM Guenter Roeck wrote:
>
> ... and this is just the very first build I happened to try this morning.
It will fail for all sparc32 builds. And unlike the powerpc case, I
hadn't even noticed this one.
Trivial fix for powerpc/sparc32 pushed out. Hopefully that was all o
On Fri, Jan 4, 2019 at 1:28 AM Mathieu Malaterre wrote:
>
> Revert commit 05a4ab823983 ("powerpc/uaccess: fix warning/error with
> access_ok()") to fix the following compilation error:
Gaah. I even *looked* at the powerpc use of 'type', but then when I
was actually going through my manual editing
Mathieu Malaterre a écrit :
In commit 05a4ab823983 ("powerpc/uaccess: fix warning/error with
access_ok()") an attempt was made to remove a warning by referencing the
variable `type`, however in commit 96d4f267e40f ("Remove 'type' argument
from access_ok() function") the variable `type` has been
In commit 05a4ab823983 ("powerpc/uaccess: fix warning/error with
access_ok()") an attempt was made to remove a warning by referencing the
variable `type`, however in commit 96d4f267e40f ("Remove 'type' argument
from access_ok() function") the variable `type` has been removed.
Revert commit 05a4ab8
On Wed, Oct 31, 2018 at 12:15 PM Mathieu Malaterre wrote:
>
> GCC 4.6 is the minimum supported now.
>
> Signed-off-by: Mathieu Malaterre
> ---
> scripts/mod/file2alias.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alia
On Wed, Oct 31, 2018 at 5:14 PM Masahiro Yamada
wrote:
>
> On Wed, Oct 31, 2018 at 8:28 PM Miguel Ojeda
> wrote:
> >
> > By the way, is it possible that scripts/ and similar stuff uses
> > directly include/linux/compiler_attributes.h (whenever it hits
> > mainline, see
> > https://github.com/oje
On Wed, Oct 31, 2018 at 8:28 PM Miguel Ojeda
wrote:
>
> On Wed, Oct 31, 2018 at 12:18 PM Mathieu Malaterre wrote:
> >
> > GCC 4.6 is the minimum supported now.
> >
> > Signed-off-by: Mathieu Malaterre
> > ---
> > scripts/mod/file2alias.c | 6 +-
> > 1 file changed, 1 insertion(+), 5 deletio
On Wed, Oct 31, 2018 at 12:18 PM Mathieu Malaterre wrote:
>
> GCC 4.6 is the minimum supported now.
>
> Signed-off-by: Mathieu Malaterre
> ---
> scripts/mod/file2alias.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alia
GCC 4.6 is the minimum supported now.
Signed-off-by: Mathieu Malaterre
---
scripts/mod/file2alias.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 28a61665bb9c..4b59564d4706 100644
--- a/scripts/mod/file2alias.c
Em Thu, May 03, 2018 at 03:50:32PM -0400, William Cohen escreveu:
> Signed-off-by: William Cohen
> ---
> tools/perf/pmu-events/arch/x86/mapfile.csv | 1 -
> 1 file changed, 1 deletion(-)
Thanks, applied.
- Arnaldo
> diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv
> b/tools/perf/pmu-e
Signed-off-by: William Cohen
---
tools/perf/pmu-events/arch/x86/mapfile.csv | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv
b/tools/perf/pmu-events/arch/x86/mapfile.csv
index 93656f2fd53a..7e3cce3bcf3b 100644
--- a/tools/perf/pmu-events/arch/x86/mapf
On Sat, Feb 03, 2018 at 01:48:19PM +0800, 540263...@qq.com wrote:
> From: qize wang <540263...@qq.com>
>
> The set_real_mode_mem function always print a raw kernel pointer to the
> kernel log
> at every boot. So just remove raw pointer from printk message.
>
> Reported-by: qize wang
> Cc: stabl
2018-01-27 8:00 GMT+09:00 Marc Herbert :
> Masahiro,
>
> On 17/01/2018 20:31, Masahiro Yamada wrote:
>
>> Sorry for my late reply.
>
> I think we're even now :-)
>
>>> I'd like to keep that sentence because it's there to explain the legacy and
>>> confusing "--silentoldconfig" name which unfortunat
Masahiro,
On 17/01/2018 20:31, Masahiro Yamada wrote:
> Sorry for my late reply.
I think we're even now :-)
>> I'd like to keep that sentence because it's there to explain the legacy and
>> confusing "--silentoldconfig" name which unfortunately still sticks out in
>> the *current* conf.c inter
Hi Marc,
Sorry for my late reply.
2018-01-13 7:49 GMT+09:00 Marc Herbert :
> Masahiro,
>
> On 09/01/2018 23:17, Masahiro Yamada wrote:
>
>> > "(oldconfig used to be more verbose)"
>
>>The historical background is git.
>>If people are interested in archeology,
>>they would be able t
Hi Karim,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc8 next-20180115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/
Signed-off-by: Karim Eshapa
Thanks,
Karim
---
include/linux/tnum.h | 2 +-
kernel/bpf/tnum.c | 13 +++--
kernel/bpf/verifier.c | 12
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/include/linux/tnum.h b/include/linux/tnum.h
index 0d2d3da..ddb1250 1006
Signed-off-by: Karim Eshapa
Thanks,
Karim
---
include/linux/tnum.h | 2 +-
kernel/bpf/tnum.c | 13 +++--
kernel/bpf/verifier.c | 12
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/include/linux/tnum.h b/include/linux/tnum.h
index 0d2d3da..ddb1250 1006
Masahiro,
On 09/01/2018 23:17, Masahiro Yamada wrote:
> > "(oldconfig used to be more verbose)"
>The historical background is git.
>If people are interested in archeology,
>they would be able to do it by "git log", "git blame", etc.
>We are generally interested in the current
2018-01-06 7:21 GMT+09:00 Marc Herbert :
> On 04/01/2018 09:21, Masahiro Yamada wrote:
>> (+CC Michal's new address)
>>
>> 2017-12-19 10:26 GMT+09:00 Marc Herbert :
>>> As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189
>>> silentoldconfig has become a misnomer. It has become an in
On 04/01/2018 09:21, Masahiro Yamada wrote:
> (+CC Michal's new address)
>
> 2017-12-19 10:26 GMT+09:00 Marc Herbert :
>> As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189
>> silentoldconfig has become a misnomer. It has become an internal
>> interface and "oldconfig" is just as
(+CC Michal's new address)
2017-12-19 10:26 GMT+09:00 Marc Herbert :
> As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189
> silentoldconfig has become a misnomer. It has become an internal
> interface and "oldconfig" is just as silent now.
Hmm, I'd like to be sure about your int
As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189
silentoldconfig has become a misnomer. It has become an internal
interface and "oldconfig" is just as silent now. It's not part of the
user interface so remove it from "make help" to stop confusing people
trying to use it as seen f
On 3 August 2017 at 18:53, Dan Carpenter wrote:
> On Thu, Aug 03, 2017 at 06:23:54PM +0530, hari prasath wrote:
>> On 3 August 2017 at 11:52, kbuild test robot wrote:
>> > Hi Hari,
>> >
>> > [auto build test WARNING on staging/staging-testing]
>> > [also build test WARNING on next-20170802]
>> >
On Thu, Aug 03, 2017 at 06:23:54PM +0530, hari prasath wrote:
> On 3 August 2017 at 11:52, kbuild test robot wrote:
> > Hi Hari,
> >
> > [auto build test WARNING on staging/staging-testing]
> > [also build test WARNING on next-20170802]
> > [cannot apply to v4.13-rc3]
> > [if your patch is applied
On 3 August 2017 at 11:52, kbuild test robot wrote:
> Hi Hari,
>
> [auto build test WARNING on staging/staging-testing]
> [also build test WARNING on next-20170802]
> [cannot apply to v4.13-rc3]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
Hi Hari,
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20170802]
[cannot apply to v4.13-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Hari-Prasath/R
1 - 100 of 1976 matches
Mail list logo
