Hi,
Kindly pull the new firmware from the following URL.
git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
Thanks
Ganesh
The following changes since commit 3f1ab9f5f381515992c51baab7bd30d46126b068:
cxgb4: update firmware to revision 1.17.14.0 (2018-01-17 02:48:30 -0800)
are avail
Commit-ID: d47924417319e3b6a728c0b690f183e75bc2a702
Gitweb: https://git.kernel.org/tip/d47924417319e3b6a728c0b690f183e75bc2a702
Author: Thomas Gleixner
AuthorDate: Tue, 16 Jan 2018 19:59:59 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 17 Jan 2018 11:56:47 +0100
x86/intel_rdt/cqm:
Em Tue, 16 Jan 2018 19:40:55 -0800
Matthew Wilcox escreveu:
> From: Matthew Wilcox
>
> At some stage of the conversion pipeline, something thought that the
> DocBook entity # should be rendered as NUM instead of #.
>
> Signed-off-by: Matthew Wilcox
Reviewed-by: Mauro Carvalho Chehab
> ---
>
On Wed, Jan 10, 2018 at 2:20 AM, Dmitry Vyukov wrote:
> Hello,
>
> syzkaller has hit the following memory leak on 4.15-rc7.
> Reproducer is attached.
>
> unreeferenced object 0x88002c9ac400 (size 4096):
> comm "syz-executor0", pid 12349, jiffies 4295751114 (age 10.067s)
> hex dump (first 3
Linus Torvalds wrote:
> > It turned out that CONFIG_FLATMEM was irrelevant. I just did not hit it.
>
> So have you actually been able to see the problem with FLATMEM, or is
> this based on the bisect? Because I really think the bisect is pretty
> much guaranteed to be wrong.
Oops, this "it" is "a
Hi,
On Wed, Jan 17, 2018 at 09:30:45AM +, shufan_lee(?) wrote:
> Dear Heikki,
>
> Sorry for bothering.
>
> Just want to check is there anything we need to modify?
I'll check the patch this week, but please note that we are -rc8, so
nothing is going to happen before -rc1 is out.
> Applied to linux-kbuild/misc.
How would you like to get a related document updated?
https://bottest.wiki.kernel.org/coccicheck#types_of_tests
Regards,
Markus
On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann wrote:
> Don't know if there's such a possibility, but it would be nice if we could
> target fuzzing for specific subsystems in related subtrees directly (e.g.
> for bpf in bpf and bpf-next trees as one example). Dmitry?
Hi Daniel,
It's doable.
L
Le 17/01/2018 à 04:19, Aneesh Kumar K.V a écrit :
On 01/16/2018 10:18 PM, Christophe LEROY wrote:
Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
An application running with libhugetlbfs fails to allocate
additional pages to HEAP due to the hugemap being done
On Wednesday, January 17, 2018 10:14:23 AM CET Geert Uytterhoeven wrote:
> Hi Rafael,
>
> On Mon, Jan 15, 2018 at 5:17 PM, Rafael J. Wysocki wrote:
> > On Mon, Jan 15, 2018 at 3:26 PM, Ulf Hansson wrote:
> >> On 15 January 2018 at 14:22, Geert Uytterhoeven
> >> wrote:
> >
> > [cut]
> >
> >>>
>
On Wed, Jan 17, 2018 at 01:08:58PM +0200, Heikki Krogerus wrote:
> Hi,
>
> On Wed, Jan 17, 2018 at 09:30:45AM +, shufan_lee(?) wrote:
> > Dear Heikki,
> >
> > Sorry for bothering.
> >
> > Just want to check is there anything we need to modify?
>
> I'll check the patch this week,
From: Colin Ian King
The function its_fsl_mc_msi_init is local to the source and does
not need to be in global scope, so make it static.
Cleans up sparse warning:
symbol 'its_fsl_mc_msi_init' was not declared. Should it be static?
Signed-off-by: Colin Ian King
---
drivers/staging/fsl-mc/bus/i
On 01/17/2018 11:03 AM, Florian Weimer wrote:
> On 01/17/2018 10:48 AM, Martin Schwidefsky wrote:
>> rc = syscall(__NR_s390_modify_bp);
>> if (rc) {
>> perror("s390_modify_bp");
>> exit(EXIT_FAILURE);
>> }
>
> Isn't this traditionally
On Tue, 2 Jan 2018, David Howells wrote:
> Thomas Gleixner wrote:
>
> > > #define INIT_CPU_TIMERS(s)
> > > \
> > ...
> > That macro is only used in init_task.c Why not moving it there and get rid
> > of the whole macro maze in the header file?
>
>
Commit-ID: 45d55e7bac4028af93f5fa324e69958a0b868e96
Gitweb: https://git.kernel.org/tip/45d55e7bac4028af93f5fa324e69958a0b868e96
Author: Thomas Gleixner
AuthorDate: Tue, 16 Jan 2018 12:20:18 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 17 Jan 2018 12:11:36 +0100
x86/apic/vector: Fi
Paolo,
while this is kvm code, my current plan is to submit the "final" version after
review and probably some fixes/renames via Martin together with the other
patches. Are you ok with that? Right now it seems that the CAP number is still
fine.
Christian
On 01/17/2018 10:48 AM, Martin Schwidefs
Fix to return error code -ENOMEM from the mempool_create_kmalloc_pool()
error handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/md/dm-crypt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
ind
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/mtd/onenand/omap2.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/
Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/char/ipmi/ipmi_powernv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_powernv
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 4 +---
drivers/perf/hisilicon/hisi_uncore_hha_pmu.c | 4 +---
drivers/perf/hisilicon/hisi_un
> while this is kvm code, my current plan is to submit the "final"
> version after review and probably some fixes/renames via Martin
> together with the other patches. Are you ok with that? Right now it
> seems that the CAP number is still fine.
Sure, though there will be a capability introduced b
Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: Wei Yongjun
---
drivers/phy/broadcom/phy-brcm-usb.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/
From: Colin Ian King
The functions devlink_resource_find and devlink_resource_validate_children
are local to the source and do not need to be in global scope, so make
them static.
Cleans up sparse warnings:
symbol 'devlink_resource_find' was not declared. Should it be static?
warning: symbol 'de
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/memory/ti-emif-pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
inde
The patch
ASoC: Intel: remove second duplicated assignment to pointer 'res'
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 2
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/slimbus/qcom-ctrl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/slimbus/qcom-ctrl.c b/drivers/slim
On 01/17/2018 12:22 PM, Paolo Bonzini wrote:
>> while this is kvm code, my current plan is to submit the "final"
>> version after review and probably some fixes/renames via Martin
>> together with the other patches. Are you ok with that? Right now it
>> seems that the CAP number is still fine.
>
On 01/17/2018 12:28 PM, Christian Borntraeger wrote:
>
>
> On 01/17/2018 12:22 PM, Paolo Bonzini wrote:
>>> while this is kvm code, my current plan is to submit the "final"
>>> version after review and probably some fixes/renames via Martin
>>> together with the other patches. Are you ok with
On 17/01/2018 12:29, Christian Borntraeger wrote:
>> The problem is not that I announce the facility, I in fact announce that the
>> programmatic interface is available (the sebc sync reg and the usage of that
>> field).
>> (So the CAP is part of this patch to have both in lockstep)
>> A non-exist
Replace pointer comparison to 0 with NULL in prepare_ftrace_return
to improve code readability. Identified with coccinelle script
'badzero.cocci'.
Signed-off-by: Mathieu Malaterre
---
arch/mips/kernel/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/kernel/f
> #define ECB_GS 0x40
> #define ECB_TE 0x10
> #define ECB_SRSI 0x04
> diff --git a/arch/s390/include/uapi/asm/kvm.h
> b/arch/s390/include/uapi/asm/kvm.h
> index 38535a57..20b9e9f 100644
> --- a/arch/s390/include/uapi/asm/kvm.h
> +++ b/arch/s390/include/uapi/asm/
On 17/01/18 05:26, Tomasz Figa wrote:
On Tue, Jan 16, 2018 at 10:25 PM, Jeffy Chen wrote:
It's hard to undo bus_set_iommu() in the error path, so move it to the
end of rk_iommu_probe().
Does this work fine now? I remember we used to need this called in an
early initcall for all the ARM/ARM64
On 01/17/2018 12:33 PM, David Hildenbrand wrote:
>
>> #define ECB_GS 0x40
>> #define ECB_TE 0x10
>> #define ECB_SRSI0x04
>> diff --git a/arch/s390/include/uapi/asm/kvm.h
>> b/arch/s390/include/uapi/asm/kvm.h
>> index 38535a57..20b9e9f 100644
>> --- a/arch/s390/i
On 2018年01月17日 19:07, Xin Long wrote:
On Wed, Jan 10, 2018 at 2:20 AM, Dmitry Vyukov wrote:
Hello,
syzkaller has hit the following memory leak on 4.15-rc7.
Reproducer is attached.
unreeferenced object 0x88002c9ac400 (size 4096):
comm "syz-executor0", pid 12349, jiffies 4295751114 (ag
On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> [This is the same conflict I reported the day before yesterday, but one
> of the commits has moved and another that contributed has been dropped.]
> diff --cc arch/x86/include/asm/cpufeatures.h
> index aa09559b2c0b,19f35be95f16..
> --- a/ar
On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> Dave Martin writes:
>
> > On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote:
> >> Dave Martin writes:
> >>
> >> > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote:
> >> >> Setting si_code to 0
On Tue, Jan 16, 2018 at 06:14:58PM -0800, David Rientjes wrote:
> There are three significant concerns about the cgroup aware oom killer as
> it is implemented in -mm:
>
> (1) allows users to evade the oom killer by creating subcontainers or
> using other controllers since scoring is done pe
On Tue, Jan 16, 2018 at 2:57 PM, Juergen Gross wrote:
> There seem to exist several grub2 versions trashing
> boot_params.hdr.acpi_rsdp_addr.
>
> So don't just believe this address to be valid, but verify it pointing
> to a valid RSDP table.
>
> Signed-off-by: Juergen Gross
> ---
> To be applied
On 17/01/2018 12:14, Christian Borntraeger wrote:
>
>
> On 01/17/2018 11:03 AM, Florian Weimer wrote:
>> On 01/17/2018 10:48 AM, Martin Schwidefsky wrote:
>>> rc = syscall(__NR_s390_modify_bp);
>>> if (rc) {
>>> perror("s390_modify_bp");
>>> exi
In case when timers are migrated to a CPU, after it exits
idle, but before timer base is forwarded, either from
run_timer_softirq()/mod_timer()/add_timer_on(), it's
possible that migrated timers are queued, based on older
clock value. This can cause delays in handling those timers.
For example, co
On Wed, 10 Jan 2018 16:43:23 +0100,
Takashi Iwai wrote:
>
> On Wed, 10 Jan 2018 16:23:43 +0100,
> Mika Westerberg wrote:
> >
> > On Wed, Jan 10, 2018 at 04:13:51PM +0100, Takashi Iwai wrote:
> > > Hi,
> > >
> > > on the recent kernels, i2c-i801 skips the creation of iTCO wdt when
> > > ACPI WDAT
From: Colin Ian King
The pointer mos_parport is being initialized to pp->private_data and
then the assignment is duplicated after a spin lock. Remove the
initialization as it occurs before the spin lock and it is a redundant
assignment.
Cleans up clang warnings:
drivers/usb/serial/mos7720.c:521
Hi,
This series is a continuation of the work started by Daniel [1]. The goal
is to use GICv3 interrupt priorities to simulate an NMI.
To achieve this, set two priorities, one for standard interrupts and
another, higher priority, for NMIs. Whenever we want to disable interrupts,
we mask the stand
From: Daniel Thompson
Currently it is not possible to detect features of the boot CPU
until the other CPUs have been brought up.
This prevents us from reacting to features of the boot CPU until
fairly late in the boot process. To solve this we allow a subset
of features (that are likely to be co
From: Daniel Thompson
Currently irqflags is implemented using the PSR's I bit. It is possible
to implement irqflags by using the co-processor interface to the GIC.
Using the co-processor interface makes it feasible to simulate NMIs
using GIC interrupt prioritization.
This patch changes the irqfl
Add functions to read/write priorities to the GIC [re]distributor.
Signed-off-by: Julien Thierry
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
---
drivers/irqchip/irq-gic-common.c | 10 ++
drivers/irqchip/irq-gic-common.h | 2 ++
2 files changed, 12 insertions(+)
diff --git
arm64 does not provide native NMIs. Emulate the NMI behaviour using GIC
priorities.
Add the possibility to set an IRQ as an NMI and the handling of the NMI.
If the view of GIC priorities is the secure one (i.e. SCR_EL3.FIQ == 0), do
not allow the use of NMIs. Emit a warning when attempting to set
The values non secure EL1 needs to use for priority registers depends on
the value of SCR_EL3.FIQ.
Since we don't have access to SCR_EL3, we fake an interrupt and compare the
GIC priority with the one present in the [re]distributor.
Also, add firmware requirements related to SCR_EL3.
Signed-off-
From: Daniel Thompson
Currently alternatives are applied very late in the boot process (and
a long time after we enable scheduling). Some alternative sequences,
such as those that alter the way CPU context is stored, must be applied
much earlier in the boot sequence.
Introduce apply_alternatives
On Wed, 17 Jan 2018 12:14:52 +0100
Christian Borntraeger wrote:
> On 01/17/2018 11:03 AM, Florian Weimer wrote:
> > On 01/17/2018 10:48 AM, Martin Schwidefsky wrote:
> >> rc = syscall(__NR_s390_modify_bp);
> >> if (rc) {
> >> perror("s390_modify_bp");
> >>
On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> I will keep FPE_FIXME as a place holder until this gets sorted out.
>
> There is a second issue I am looking at in this location,
> and maybe I don't have to address it now. But it looks like the code is
> calling send_sig_info
On Tuesday 16 January 2018 10:51 PM, David Lechner wrote:
> On 01/16/2018 08:00 AM, Sekhar Nori wrote:
>> On Monday 08 January 2018 07:47 AM, David Lechner wrote:
>>> +void __init da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1)
>>> +{
>>> + struct clk_onecell_data *clk_data;
>>> +
>>>
Hi Greg,
On Wed, Jan 17, 2018 at 12:14:02PM +0100, Greg KH wrote:
> On Wed, Jan 17, 2018 at 01:08:58PM +0200, Heikki Krogerus wrote:
> > Hi,
> >
> > On Wed, Jan 17, 2018 at 09:30:45AM +, shufan_lee(?) wrote:
> > > Dear Heikki,
> > >
> > > Sorry for bothering.
> > >
> > > Just wa
On Wed, 17 Jan 2018 10:48:33 +0100
Martin Schwidefsky wrote:
> This patch series implements multiple mitigations for the speculative
> execution findings:
> 1. The definition of the gmb() barrier as currently used by the
>distributions, we may have to find a better name for it
> 2. The archit
On 17 January 2018 at 10:19, Will Deacon wrote:
> On Tue, Jan 16, 2018 at 02:08:32PM +, Mark Rutland wrote:
>> Currently the arm/arm64 runtime code registers the runtime servies
>> pagetables with ptdump regardless of whether runtime services page
>> tables have been created.
>>
>> As efi_mm.p
see V4 discussion.. :)
I didn't see any v4
Hi Alexey,
On 2018-01-16, Alexey Dobriyan wrote:
> do_task_stat() accesses IP and SP of a task without bumping reference
> count of a stack (which became an entity with independent lifetime at
> some point).
>
> Steps to reproduce:
>
> #include
> #include
> #include
> #include
> #include
> #
On Wed 2018-01-17 11:19:53, Byungchul Park wrote:
> On 1/10/2018 10:24 PM, Petr Mladek wrote:
> > From: Steven Rostedt
> > By Petr Mladek about possible new deadlocks:
> >
> > The thing is that we move console_sem only to printk() call
> > that normally calls console_unlock() as well. It means th
On 01/17/2018 01:00 PM, Cornelia Huck wrote:
> On Wed, 17 Jan 2018 10:48:33 +0100
> Martin Schwidefsky wrote:
>
>> This patch series implements multiple mitigations for the speculative
>> execution findings:
>> 1. The definition of the gmb() barrier as currently used by the
>>distributions,
On Wed, 17 Jan 2018, Lingutla Chandrasekhar wrote:
> In case when timers are migrated to a CPU, after it exits
> idle, but before timer base is forwarded, either from
> run_timer_softirq()/mod_timer()/add_timer_on(), it's
> possible that migrated timers are queued, based on older
> clock value. Th
On Wed, 17 Jan 2018, Thomas Gleixner wrote:
> On Wed, 17 Jan 2018, Lingutla Chandrasekhar wrote:
And please fix the subject line:
kernel: time:
is not the proper subsystem prefix.
git log should give you a hint.
Aside of that the text after the prefix starts with an uppercase letter.
Than
The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: Luis de Bethencourt
---
Hi,
After fixing the same thing in drivers/staging/rtl8723bs/, Joe Perches
suggested I fix it treewide [0].
Best regards,
Luis
[0]
http://dri
Hi,
On 17/01/18 11:54, Julien Thierry wrote:
This series is a continuation of the work started by Daniel [1]. The goal
is to use GICv3 interrupt priorities to simulate an NMI.
I have submitted a separate series making use of this feature for the
ARM PMUv3 interrupt [1].
[1] https://www.sp
Hi,
On Wed, Jan 17, 2018 at 1:47 AM, Guo Yi wrote:
> This patch fix the bluetooth 6lowpan disconnect fail bug.
>
> The type of the same address type have different define value in HCI layer
> and L2CAP layer.That makes disconnect fail due to wrong network type.User
> will not be able to disconnec
On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King - ARM Linux wrote:
> On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> > I will keep FPE_FIXME as a place holder until this gets sorted out.
> >
> > There is a second issue I am looking at in this location,
> > and maybe I d
On 17/01/2018 12:45, Thomas Gleixner wrote:
> On Wed, 17 Jan 2018, Stephen Rothwell wrote:
>> [This is the same conflict I reported the day before yesterday, but one
>> of the commits has moved and another that contributed has been dropped.]
>> diff --cc arch/x86/include/asm/cpufeatures.h
>> index
On 16/01/18 13:25, Jeffy Chen wrote:
Suggested-by: Robin Murphy
Signed-off-by: Jeffy Chen
---
Changes in v2: None
drivers/iommu/rockchip-iommu.c | 38 +++---
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/drivers/iommu/rockchip-iommu.c b/dri
On 17/01/18 12:49, Rafael J. Wysocki wrote:
> On Tue, Jan 16, 2018 at 2:57 PM, Juergen Gross wrote:
>> There seem to exist several grub2 versions trashing
>> boot_params.hdr.acpi_rsdp_addr.
>>
>> So don't just believe this address to be valid, but verify it pointing
>> to a valid RSDP table.
>>
>>
On Tuesday 16 January 2018 10:46 PM, David Lechner wrote:
>>> +static const struct davinci_psc_clk_info da830_psc0_info[]
>>> __initconst = {
>>> + LPSC(0, 0, tpcc, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> + LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> + LPSC(2, 0, tptc1, pll0
On Thu, 4 Jan 2018, Yang Shi wrote:
> There are nested loops on debug objects free path, sometimes it may take
> over hundred thousands of loops, then cause soft lockup with !CONFIG_PREEMPT
> occasionally, like below:
Please trim back traces. The whole module info and whatever is completely
irrel
Dear Johannes,
On 01/04/18 16:08, Johannes Berg wrote:
Hi,
Can you reproduce this?
[ 54.426491] UBSAN: Undefined behaviour in net/wireless/nl80211.c:718:4
[ 54.426492] signed integer overflow:
[ 54.426493] -1665903437 * 100 cannot be represented in type 'int'
Obviously.
However, it
On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> On 17/01/2018 12:45, Thomas Gleixner wrote:
> > On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> >> [This is the same conflict I reported the day before yesterday, but one
> >> of the commits has moved and another that contributed has been dropped.]
> >> di
On Wed, Jan 17, 2018 at 10:05:56AM +, Suzuki K Poulose wrote:
> When a CPU is brought up after we have finalised the system
> wide capabilities (i.e, features and errata), we make sure the
> new CPU doesn't need a new errata work around which has not been
> detected already. However we don't ru
On Tuesday 16 January 2018 10:21 PM, David Lechner wrote:
>>> +static struct clk *davinci_psc_clk_register(const char *name,
>>> + const char *parent_name,
>>> + struct regmap *regmap,
>>> + u32 lpsc, u32 pd, u32 flags)
>>> +{
>>
On Wed, Jan 17, 2018 at 4:19 PM, Tomasz Figa wrote:
>
> P.S. Looks like your email client is set to HTML messages. Your
> messages might end up dropped from the mailing list.
Never mind. Looks like gmail started displaying quotations in plain
text as graphics.
Best regards,
Tomasz
On 16/01/18 17:35, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> On 16/01/18 16:46, Ingo Molnar wrote:
>>>
>>> * Juergen Gross wrote:
>>>
There seem to exist several grub2 versions trashing
boot_params.hdr.acpi_rsdp_addr.
So don't just believe this address to be valid,
On 16/01/18 13:25, Jeffy Chen wrote:
IOMMU drivers are supposed to call this function instead of manually
creating a group in their .add_device callback. This behavior is not
strictly required by ARM DMA mapping implementation, but ARM64 already
relies on it. This patch fixes the rockchip-iommu d
Hi,
Thanks for your comments.
On 01/17/18 at 09:57am, Petr Mladek wrote:
> On Wed 2018-01-17 12:50:57, Dave Young wrote:
> > It is useful to print kdump kernel loaded status in dump_stack()
> > especially when panic happens so that we can differenciate
> > kdump kernel early hang and a normal p
On 17/01/2018 13:23, Thomas Gleixner wrote:
> On Wed, 17 Jan 2018, Paolo Bonzini wrote:
>> On 17/01/2018 12:45, Thomas Gleixner wrote:
>>> On Wed, 17 Jan 2018, Stephen Rothwell wrote:
[This is the same conflict I reported the day before yesterday, but one
of the commits has moved and anot
On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> On 17/01/2018 13:23, Thomas Gleixner wrote:
> > No. Keep it and lets next time coordinate the relevant bits and pieces
> > better. I reserve that bit 20 and let Linus sort out the trivial conflict
> > when merging the stuff.
>
> Thank you. In the future
From: yuzhoujian
Introduce a new option to print counts for fixed number of times
and update perf-stat documentation accordingly.
Show below is the output of the new option for perf stat.
$perf stat -I 1000 --times-print 2 -e cycles -a
# time counts unit ev
From: yuzhoujian
Introduce a new option to print counts for fixed number of times
and update perf-stat documentation accordingly.
Show below is the output of the new option for perf stat.
$perf stat -I 1000 --times-print 2 -e cycles -a
# time counts unit ev
On Wed, Jan 17, 2018 at 12:15:05PM +, Dave Martin wrote:
> On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King - ARM Linux wrote:
> > On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> > > I will keep FPE_FIXME as a place holder until this gets sorted out.
> > >
> > > Ther
Hi,
this patchset makes __do_SAK() to take tasklist_lock for very small time
in comparison to that it does now. Though this function is executed
in process context and it takes tasklist_lock read locked with interrupts
enabled,
another tasks may want to take it for writing with interrupt disabled
There were made several efforts to make __do_SAK()
working in process context long ago, but it does
not solves the problem completely. Since __do_SAK()
may take tasklist_lock for a long time, the concurent
processes, waiting for write lock with interrupts
disabled (e.g., forking), get into the same
This reverts commit 20ac94378de5.
send_sig() does not take tasklist_lock for a long time,
so this commit and the problem it solves are not relevant
anymore.
Also, the problem of force_sig() is it clears SIGNAL_UNKILLABLE
flag, thus even global init may be killed by __do_SAK(),
which is definitely
From: Oleg Nesterov
The patch makes __do_SAK() iterate a next thread files
only in case of the thread's files are different
to previous. I.e., if all threads points the same
files_struct, the files will be iterated only once.
Since all threads have the same files_struct is
the generic case for m
On Wed, 17 Jan 2018, Martin Schwidefsky wrote:
> Implement nospec_load() and nospec_ptr() for s390 with the new
> gmb() barrier between the boundary condition and the load that
> may not be done speculatively.
FWIW the naming seems to be changing constantly. The latest patchset from
Dan Williams
Hi Thomas,
On Wed, 17 Jan 2018 13:23:17 +0100 (CET) Thomas Gleixner
wrote:
>
> On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> > On 17/01/2018 12:45, Thomas Gleixner wrote:
> > > On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> > >> [This is the same conflict I reported the day before yesterday, b
In case when timers are migrated to a CPU, after it exits
idle, but before timer base is forwarded, either from
run_timer_softirq()/mod_timer()/add_timer_on(), it's
possible that migrated timers are queued, based on older
clock value. This can cause delays in handling those timers.
For example, co
FYI, we noticed the following commit (built with gcc-7):
commit: c0033af7eec3e728c6b70d75950e632ace4c8a55 ("hugetlbfs: Convert to
fs_context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context
in testcase: trinity
with following parameters:
runtime: 300s
Hi Robin,
On 01/17/2018 08:18 PM, Robin Murphy wrote:
@@ -91,7 +92,6 @@ struct rk_iommu {
void __iomem **bases;
int num_mmu;
int *irq;
Nit: irq seems to be redundant now as well.
oops, will fix it.
-int num_irq;
bool reset_disabled;
struct iommu_device io
Hi,
Sorry for the basic mistakes, posted new patch V1.
On 1/17/2018 5:39 PM, Thomas Gleixner wrote:
On Wed, 17 Jan 2018, Thomas Gleixner wrote:
On Wed, 17 Jan 2018, Lingutla Chandrasekhar wrote:
And please fix the subject line:
kernel: time:
is not the proper subsystem prefix.
git log
Hi Robin,
On 01/17/2018 08:31 PM, Robin Murphy wrote:
On 16/01/18 13:25, Jeffy Chen wrote:
IOMMU drivers are supposed to call this function instead of manually
creating a group in their .add_device callback. This behavior is not
strictly required by ARM DMA mapping implementation, but ARM64 alr
On 17.01.2018 00:13, Oleg Nesterov wrote:
> On 01/16, Kirill Tkhai wrote:
>>
>> On 15.01.2018 23:51, Oleg Nesterov wrote:
>>>
kill:
- force_sig(SIGKILL, p);
+ send_sig(SIGKILL, p, 1);
>>>
>>> Agreed, I didn't actually want to use force_sig(SIGKILL), copy-and-paste
On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> On Wed, 17 Jan 2018 13:23:17 +0100 (CET) Thomas Gleixner
> wrote:
> > No. Keep it and lets next time coordinate the relevant bits and pieces
> > better. I reserve that bit 20 and let Linus sort out the trivial conflict
> > when merging the stuff.
>
On 01/17/2018 08:47 PM, JeffyChen wrote:
+static struct iommu_group *rk_iommu_device_group(struct device *dev)
+{
+struct iommu_group *group;
+int ret;
+
+group = iommu_group_get(dev);
+if (!group) {
This check is pointless - if dev->iommu_group were non-NULL you wouldn't
have
Sounds great for us (Nuvoton).
Avi.
On Wed, Jan 17, 2018 at 8:32 AM, Wang, Haiyue
wrote:
>
>
> On 2018-01-17 07:06, Joel Stanley wrote:
>>
>> On Tue, Jan 16, 2018 at 2:59 PM, Corey Minyard wrote:
>>>
>>> On 01/16/2018 05:43 AM, Haiyue Wang wrote:
The KCS (Keyboard Controller Style) in
On 15.1.2018 11:19, Arnd Bergmann wrote:
> On Mon, Jan 15, 2018 at 11:14 AM, Michal Simek wrote:
>> On 15.1.2018 10:29, Arnd Bergmann wrote:
>>> On Sun, Jan 14, 2018 at 2:01 AM, kbuild test robot wrote:
Hi Arnd,
I love your patch! Yet something to improve:
[auto build tes
On 16/01/18 13:25, Jeffy Chen wrote:
There would be some masters sharing the same IOMMU device. Put them in
the same iommu group and share the same iommu domain.
Signed-off-by: Jeffy Chen
---
Changes in v2: None
drivers/iommu/rockchip-iommu.c | 39 +++
1
201 - 300 of 1318 matches
Mail list logo
