Hi,
On 10/5/20 2:58 PM, Limonciello, Mario wrote:
On modern systems CPU/GPU/... performance is often dynamically configurable
in the form of e.g. variable clock-speeds and TPD. The performance is often
automatically adjusted to the load by some automatic-mechanism (which may
very well live
On Fri, Oct 09, 2020 at 09:52:37AM +0530, Viresh Kumar wrote:
> On 08-10-20, 20:14, Sudeep Holla wrote:
> > Hi,
> >
> > These series adds ARM MHU doorbell controller driver based on the
> > discussion[1]. The DT patches are just repost from Viresh's last posting[2]
> >
> > Regards,
> > Sudeep
>
On Tue, Oct 06, 2020 at 09:19:08AM +0100, Lad Prabhakar wrote:
> Hi All,
>
> This patches are part of series [1], where patch 1/2 was missed to be applied
> before YAML conversation and patch 2/2 was never applied.
>
> I have restored the Acks for patch 1/2 and patch 2/2 is unchanged.
>
> [1]
On 09/10/2020 14.15, Vinod Koul wrote:
>>> If for any any reason subsequent txn is for different direction, I would
>>> expect that parameters are set again before prep_ calls
>>
>> But in DEV_TO_DEV?
>
> Do we support that :D
>
>> If we have two peripherals, both needs config:
>> p1_config
Hi Greg, Sasha,
Can you pick this to 5.4:
commit dbd660e6b2884b864d2642d930a163d3bcebe4be
Author: Tommi Rantala
Date: Thu Apr 23 14:53:40 2020 +0300
perf test session topology: Fix data path
And this to 5.4 and older LTS trees too:
commit 29b4f5f188571c112713c35cc87eefb46efee612
+ ath11k list
Manivannan Sadhasivam writes:
> On Thu, Oct 08, 2020 at 11:03:42PM +0530, gokul...@codeaurora.org wrote:
>> On 2020-10-08 18:41, Manivannan Sadhasivam wrote:
>> > Hi,
>> >
>> > On Thu, Oct 08, 2020 at 06:02:24PM +0530, Gokul Sriram Palanisamy wrote:
>> > > Enabled MHI device
On 10/8/20 8:49 PM, John Garry wrote:
> The event code for events referencing std arch events is incorrectly
> evaluated in json_events().
>
> The issue is that je.event is evaluated properly from try_fixup(), but
> later NULLified from the real_event() call, as "event" may be NULL.
>
> Fix
On Fri 09-10-20 13:17:04, Michal Hocko wrote:
[...]
> +config PREEMPT_DYNAMIC
> + bool "Allow boot time preemption model selection"
depends on !ARCH_NO_PREEMPT
> + depends on PREEMPT_NONE || PREEMPT_VOLUNTARY
> + help
> + This option allows to define the preemption
On Fri, Oct 09, 2020 at 08:47:45AM +0200, Vasily Gorbik wrote:
> Currently BUILD_BUG() macro is expanded to smth like the following:
>do {
>extern void __compiletime_assert_0(void)
>__attribute__((error("BUILD_BUG failed")));
>if (!(!(1)))
>
Hi Lukasz,
On Thursday 08 Oct 2020 at 18:04:26 (+0100), Lukasz Luba wrote:
> The sustainable power value might come from the Device Tree or can be
> estimated in run time. There is no need to estimate every time when the
> governor is called and temperature is high. Instead, store the estimated
>
On 09-10-20, 12:10, Nicola Mazzucato wrote:
> I thought about it and looked for other platforms' DT to see if can reuse
> existing opp information. Unfortunately I don't think it is optimal. The
> reason
> being that, because cpus have the same opp table it does not necessarily mean
> that they
Hello Mr Gleixner,
thanks for your feedback we'll fix the issues not related to the time scale
topic as soon as possible.
Regarding your concerns about not using TAI timescale, we do admit that in many
situations TAI makes a lot of things way more easy and therefore is the way to
go.
Yet we
On Fri 09-10-20 12:48:09, Michal Hocko wrote:
[...]
> I will add the CONFIG_PREEMPT_DYNAMIC in the next version. I just have
> to think whether flipping the direction is really safe and easier in the
> end. For our particular usecase we are more interested in
> NONE<->VOLUNTARY at this moment and
On Thu, 8 Oct 2020 15:21:50 -0400
Steven Rostedt wrote:
> On Thu, 8 Oct 2020 18:22:07 +0900
> Masami Hiramatsu wrote:
>
> > Some of those issues are not introduced from this series. I think
> > we'd better fix those before introducing this series so that
> > we can backport it to stable
Hi,
On 10/5/20 3:13 PM, Benjamin Berg wrote:
Hi,
seems reasonable to me. Quite simple, but likely good enough as we are
sticking to only use well known names.
Just found a small typo.
Benjamin
On Sat, 2020-10-03 at 15:19 +0200, Hans de Goede wrote:
On modern systems CPU/GPU/... performance
On Fri, Oct 09, 2020 at 10:56:16AM +, David Laight wrote:
> From: Johannes Berg
> > Sent: 09 October 2020 11:48
> >
> > On Fri, 2020-10-09 at 12:41 +0200, Johannes Berg wrote:
> >
> > > If the fops doesn't have a release method, we don't even need
> > > to keep a reference to the real_fops,
On 09-10-20, 13:45, Peter Ujfalusi wrote:
> Hi Vinod,
>
> On 09/10/2020 13.30, Vinod Koul wrote:
> > Hi Peter,
> >
> > On 09-10-20, 12:04, Peter Ujfalusi wrote:
> >> On 08/10/2020 15.31, Vinod Koul wrote:
> >>> Some complex dmaengine controllers have capability to program the
> >>> peripheral
Linus Walleij writes:
> Hi Lars,
>
> I'm overall mostly happy with the latest posting (not the one I respond to
> here)
I'm glad we're getting there :-)
>
> On Thu, Oct 8, 2020 at 12:57 PM Lars Povlsen
> wrote:
>> > On Tue, Oct 6, 2020 at 4:25 PM Lars Povlsen
>> > wrote:
>
>> >> +
On 09/10/2020 11:02, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:e4fb79c7 Add linux-next specific files for 20201008
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1592ee1b90
> kernel config:
Hi Viresh, I'm glad it helped.
Please find below my reply.
On 10/9/20 6:39 AM, Viresh Kumar wrote:
> On 08-10-20, 17:00, Nicola Mazzucato wrote:
>> On 10/8/20 4:03 PM, Ionela Voinescu wrote:
>>> Hi Viresh,
>>>
>>> On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
On 07-10-20,
If arbitration is lost, the master automatically changes to slave mode.
I2SR_IBB may or may not be reset by hardware. Raising a STOP condition
by resetting I2CR_MSTA has no effect and will not clear I2SR_IBB.
So calling i2c_imx_bus_busy() is not required and would busy-wait until
timeout.
Arbitration Lost (IAL) can happen after every single byte transfer. If
arbitration is lost, the I2C hardware will autonomously switch from
master mode to slave. If a transfer is not aborted in this state,
consecutive transfers will not be executed by the hardware and will
timeout.
Signed-off-by:
Paolo,
Are there any issues or concerns about this patch?
Thank you,
Suravee
On 10/4/20 6:27 AM, Suravee Suthikulpanit wrote:
The function amd_ir_set_vcpu_affinity makes use of the parameter struct
amd_iommu_pi_data.prev_ga_tag to determine if it should delete struct
amd_iommu_pi_data from a
According to the "VFxxx Controller Reference Manual" (and the comment
block starting at line 97), Vybrid requires writing a one for clearing
an interrupt flag. Syncing the method for clearing I2SR_IIF in
i2c_imx_isr().
Signed-off-by: Christian Eggers
Fixes: 4b775022f6fd ("i2c: imx: add struct to
Changes in v5:
---
- Added missing "Tested-By" tags.
Changes in v4:
---
- Extend comment (W1C vs. W0C)
Changes in v3:
---
- dedicated function for clearing an irq
Changes in v2:
---
- Don't accidently clear additional status flags on Vybrid
Changes in v6:
---
- Fixed commit (W1C vs. W0C)
- Extended patch 1/3 for atomic case
- Added acks by Oleksij Rempel
Changes in v5:
---
- Added missing "Tested-By" tags.
Changes in v4:
---
- Extend comment (W1C vs. W0C)
Changes in v3:
---
-
Jozsef Kadlecsik wrote:
> > Any comments?
> > Here is a simple reproducer. The idea is to show that keepalive packets
> > in an idle tcp connection will be dropped (and the connection will time
> > out) if conntrack hooks are de-registered and then re-registered. The
> > reproducer has two
On Mon, 28 Sep 2020 at 14:26, Michael Walle wrote:
>
> Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
> path") this driver causes a kernel oops:
FYI,
This reported issue is now happening on Linus's master 5.9.0-rc8 on arm64
nxp-ls2088 devices.
Crash log,
-
[
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/seves
head: 0ddfb1cf3b6b07c97cff16ea69931d986f9622ee
commit: 6ccbd29ade0d159ee1be398dc9defaae567c253d [3/75] KVM: SVM: nested: Don't
allocate VMCB structures on stack
config: x86_64-randconfig-m001-20201008 (attached as
Tiezhu Yang (3):
MIPS: Loongson64: Select SMP in Kconfig to avoid build error
MIPS: Loongson64: Clean up numa.c
MIPS: Loongson64: Add /proc/boardinfo
arch/mips/Kconfig | 1 +
arch/mips/configs/loongson3_defconfig | 1 -
syzbot suspects this issue was fixed by commit:
commit bb8872a1e6bc911869a729240781076ed950764b
Author: Tuong Lien
Date: Sat Aug 29 19:37:55 2020 +
tipc: fix using smp_processor_id() in preemptible
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=100f5bb850
start
(1) Replace nid_to_addroffset() with nid_to_addrbase() and then remove the
related useless code.
(2) Since end_pfn = start_pfn + node_psize, use "node_psize" instead of
"end_pfn - start_pfn" to avoid the redundant calculation.
(3) After commit 6fbde6b492df ("MIPS: Loongson64: Move files to the
On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> We want all iomem mmaps to consistently revoke ptes when the kernel
> takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
> pci bar mmaps available through procfs and sysfs, which currently do
> not revoke mappings.
Add /proc/boardinfo to get mainboard and BIOS info easily on the Loongson
platform, this is useful to point out the current used mainboard type and
BIOS version when there exists problems related with hardware or firmware.
E.g. with this patch:
[loongson@linux ~]$ cat /proc/boardinfo
Board Info
In the current code, CONFIG_SMP can be set as N by user on the Loongson
platform, then there exists the following build error under !CONFIG_SMP:
CC arch/mips/kernel/asm-offsets.s
In file included from ./include/linux/gfp.h:9:0,
from ./include/linux/xarray.h:14,
On Fri, Oct 09, 2020 at 09:59:32AM +0200, Daniel Vetter wrote:
> We want to be able to revoke pci mmaps so that the same access rules
> applies as for /dev/kmem. Revoke support for devmem was added in
> 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
> region").
>
> The simplest
On Fri, 2020-10-09 at 10:56 +, David Laight wrote:
> From: Johannes Berg
> > Sent: 09 October 2020 11:48
> >
> > On Fri, 2020-10-09 at 12:41 +0200, Johannes Berg wrote:
> >
> > > If the fops doesn't have a release method, we don't even need
> > > to keep a reference to the real_fops, we can
From: Johannes Berg
> Sent: 09 October 2020 11:48
>
> On Fri, 2020-10-09 at 12:41 +0200, Johannes Berg wrote:
>
> > If the fops doesn't have a release method, we don't even need
> > to keep a reference to the real_fops, we can just fops_put()
> > them already in debugfs remove, and a later
Hi,
On 10/5/20 12:29 AM, Elia Devito wrote:
Hi Hans,
On 2020-10-03 9:19 a.m., Hans de Goede wrote:
On modern systems CPU/GPU/... performance is often dynamically configurable
in the form of e.g. variable clock-speeds and TPD. The performance is often
automatically adjusted to the load by some
Hi!
I am trying to run my sdl1-based app
under linux kms framebuffer (amdgpudrmfb
in my case).
The app itself works perfectly, but
console switching is not.
If I switch the console while the app
is drawing, then it will corrupt the
VC I switched to. It will just draw on
top of the VC's content.
On Fri, 2020-10-09 at 12:41 +0200, Johannes Berg wrote:
> If the fops doesn't have a release method, we don't even need
> to keep a reference to the real_fops, we can just fops_put()
> them already in debugfs remove, and a later full_proxy_release()
> won't call anything anyway - this just
From: David Woodhouse
Some hypervisors can allow the guest to use the Extended Destination ID
field in the MSI address to address up to 32768 CPUs.
This applies to all downstream devices which generate MSI cycles,
including HPET, I/OAPIC and PCI MSI.
HPET and PCI MSI use the same
On Fri 09-10-20 12:20:09, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:14:05PM +0200, Michal Hocko wrote:
> > On Fri 09-10-20 11:47:41, Peter Zijlstra wrote:
>
> > > That is, work backwards (from PREEMPT back to VOLUNTARY) instead of the
> > > other way around.
> >
> > My original idea was
From: David Woodhouse
This isn't really dependent on PCI MSI; it's just generic MSI which is
now supported by the generic x86_vector_domain. Move the HPET MSI
support back into hpet.c with the rest of the HPET support.
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/hpet.h | 11
From: David Woodhouse
This allows the host to indicate that MSI emulation supports 15-bit
destination IDs, allowing up to 32768 CPUs without interrupt remapping.
cf. https://patchwork.kernel.org/patch/11816693/ for qemu
Signed-off-by: David Woodhouse
Acked-by: Paolo Bonzini
---
From: David Woodhouse
The Intel IOMMU has an MSI-like configuration for its interrupt, but
it isn't really MSI. So it gets to abuse the high 32 bits of the address,
and puts the high 24 bits of the extended APIC ID there.
This isn't something that can be used in the general case for real MSIs,
From: David Woodhouse
This shouldn't be dependent on PCI_MSI. HPET and I/OAPIC can deliver
interrupts through MSI without having any PCI in the system at all.
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/apic.h | 8 +++-
arch/x86/kernel/apic/apic.c | 32
From: David Woodhouse
Currently, Linux as a hypervisor guest will enable x2apic only if there
are no CPUs present at boot time with an APIC ID above 255.
Hotplugging a CPU later with a higher APIC ID would result in a CPU
which cannot be targeted by external interrupts.
Add a filter in
On Fri, Oct 09, 2020 at 11:24:38AM +0100, Mark Rutland wrote:
> On Fri, Oct 09, 2020 at 10:43:18AM +0100, Mark Rutland wrote:
> > Hi Qian,
> >
> > On Fri, Oct 09, 2020 at 09:51:15AM +0100, Will Deacon wrote:
> > > On Thu, Oct 08, 2020 at 09:18:24PM -0400, Qian Cai wrote:
> > > > On Mon,
From: David Woodhouse
Bits 63-48 of the I/OAPIC Redirection Table Entry map directly to
bits 19-4 of the address used in the resulting MSI cycle.
Historically, the x86 MSI format only used the top 8 of those 16 bits as
the destination APIC ID, and the "Extended Destination ID" in the lower
8
From: David Woodhouse
The I/OAPIC generates an MSI cycle with address/data bits taken from its
Redirection Table Entry in some combination which used to make sense,
but now is just a bunch of bits which get passed through in some
seemingly arbitrary order.
Instead of making IRQ remapping
Hi Vinod,
On 09/10/2020 13.30, Vinod Koul wrote:
> Hi Peter,
>
> On 09-10-20, 12:04, Peter Ujfalusi wrote:
>> On 08/10/2020 15.31, Vinod Koul wrote:
>>> Some complex dmaengine controllers have capability to program the
>>> peripheral device, so pass on the peripheral configuration as part of
>>>
Fix the conditions for enabling x2apic on guests without interrupt
remapping, and support 15-bit Extended Destination ID to allow 32768
CPUs without IR on hypervisors that support it.
The last patch in the series now makes io_apic.c generate its RTE from
the MSI message created by the parent
On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote:
> On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > > do nothing for i915.
From: Johannes Berg
Currently, things will crash (or at least UAF) in release() when
a module owning a debugfs file, but that didn't set the fops.owner,
is removed while the offending debugfs file is open.
Since we have the proxy_fops, we can break that down into two
different cases:
If the
On Fri 09-10-20 12:14:31, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:10:44PM +0200, Michal Hocko wrote:
> > On Fri 09-10-20 11:42:45, Peter Zijlstra wrote:
> > > On Fri, Oct 09, 2020 at 11:12:18AM +0200, Michal Hocko wrote:
> > > > Is there any additional feedback? Should I split up the
Hi,
Em Fri, 9 Oct 2020 09:59:26 +0200
Daniel Vetter escreveu:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with
On Thu, Oct 08, 2020 at 12:43:17PM +0530, Sanjay R Mehta wrote:
> On 10/7/2020 1:08 AM, Lukas Wunner wrote:
> > On Tue, Oct 06, 2020 at 01:24:28PM -0500, Sanjay R Mehta wrote:
> I am supposed to use PCI_EXP_LNKSTA_DLLLA bit in my patch but have
> used PCI_EXP_DPC_CAP_DL_ACTIVE.
>
> The correct
SOCK_TSTAMP_NEW (timespec64 instead of timespec) is also used for
hardware time stamps (configured via SO_TIMESTAMPING_NEW).
User space (ptp4l) first configures hardware time stamping via
SO_TIMESTAMPING_NEW which sets SOCK_TSTAMP_NEW. In the next step, ptp4l
disables SO_TIMESTAMPNS(_NEW)
The comparison of optname with SO_TIMESTAMPING_NEW is wrong way around,
so SOCK_TSTAMP_NEW will first be set and than reset again. Additionally
move it out of the test for SOF_TIMESTAMPING_RX_SOFTWARE as this seems
unrelated.
This problem happens on 32 bit platforms were the libc has already
On 09-10-20, 12:00, Peter Ujfalusi wrote:
> Hi Vinod,
>
> On 08/10/2020 15.31, Vinod Koul wrote:
> > This controller provides DMAengine capabilities for a variety of peripheral
> > buses such as I2C, UART, and SPI. By using GPI dmaengine driver, bus
> > drivers can use a standardize interface
On 10/9/20 1:58 AM, Sean Christopherson wrote:
> On Thu, Oct 08, 2020 at 03:54:12PM +0800, yulei.ker...@gmail.com wrote:
>> From: Yulei Zhang
>>
>> Dmem page is pfn invalid but not mmio. Support cacheable
>> dmem page for kvm.
>>
>> Signed-off-by: Chen Zhuo
>> Signed-off-by: Yulei Zhang
>> ---
Hi Peter,
On 09-10-20, 12:04, Peter Ujfalusi wrote:
> On 08/10/2020 15.31, Vinod Koul wrote:
> > Some complex dmaengine controllers have capability to program the
> > peripheral device, so pass on the peripheral configuration as part of
> > dma_slave_config
> >
> > Signed-off-by: Vinod Koul
> >
This patch adds support for passing the multiple bssid config to the
kernel when adding an AP gets started. If the BSS is non-transmitting we
need to pass the ifidx of the transmitting parent. The multiple bssid
elements are passed as an array inside the beacon data. This allows use to
generate
On Fri, Oct 09, 2020 at 10:43:18AM +0100, Mark Rutland wrote:
> Hi Qian,
>
> On Fri, Oct 09, 2020 at 09:51:15AM +0100, Will Deacon wrote:
> > On Thu, Oct 08, 2020 at 09:18:24PM -0400, Qian Cai wrote:
> > > On Mon, 2020-10-05 at 17:43 +0100, Mark Rutland wrote:
> > > > The current initialization
Hi,
On 10/7/20 9:51 AM, Sumit Garg wrote:
> With the recent feature added to enable perf events to use pseudo NMIs
> as interrupts on platforms which support GICv3 or later, its now been
> possible to enable hard lockup detector (or NMI watchdog) on arm64
> platforms. So enable corresponding
When bringing up multi bssid APs we need to track the parent-child relation
aswell as figuring out if the BSS is (non-)transmitting. The new helper
function ieee80211_set_multiple_bssid_options() takes care of storing the
config as well as figuring out the runtime flags of the virtual interface.
As a non-transmitting interface does not broadcast a beacon, we do not want
to allow channel switch announcements. They need to be triggered on the
transmitting interface.
Signed-off-by: Aloka Dixit
Signed-off-by: John Crispin
---
net/mac80211/cfg.c | 3 +++
1 file changed, 3 insertions(+)
Changes in V4
* move multiple bssid config from add_interface to start_ap
* add ema support
John Crispin (4):
nl80211: add basic multiple bssid support
mac80211: add multiple bssid support to interface handling
mac80211: add multiple bssid/EMA support to beacon handling
mac80211: don't
With beacon_data now holding the additional information about the multiple
bssid elements, we need to honour these in the various beacon handling
code paths.
Extend ieee80211_beacon_get_template() to allow generation of multiple
bssid/EMA beacons. The API provides support for HW that can offload
Hi Will, Alex,
On Wed, 7 Oct 2020 at 14:22, Sumit Garg wrote:
>
> With the recent feature added to enable perf events to use pseudo NMIs
> as interrupts on platforms which support GICv3 or later, its now been
> possible to enable hard lockup detector (or NMI watchdog) on arm64
> platforms. So
On Fri, Oct 09, 2020 at 12:14:05PM +0200, Michal Hocko wrote:
> On Fri 09-10-20 11:47:41, Peter Zijlstra wrote:
> > That is, work backwards (from PREEMPT back to VOLUNTARY) instead of the
> > other way around.
>
> My original idea was that the config would only define the default
> preemption
On 10/9/20 11:16 AM, Catalin Marinas wrote:
> On Fri, Oct 09, 2020 at 10:56:02AM +0100, Vincenzo Frascino wrote:
>> On 10/9/20 9:11 AM, Catalin Marinas wrote:
>>> On Thu, Oct 08, 2020 at 07:24:12PM +0100, Vincenzo Frascino wrote:
On 10/2/20 3:06 PM, Catalin Marinas wrote:
> On Fri, Oct
On Fri, Oct 09, 2020 at 10:56:02AM +0100, Vincenzo Frascino wrote:
> On 10/9/20 9:11 AM, Catalin Marinas wrote:
> > On Thu, Oct 08, 2020 at 07:24:12PM +0100, Vincenzo Frascino wrote:
> >> On 10/2/20 3:06 PM, Catalin Marinas wrote:
> >>> On Fri, Oct 02, 2020 at 01:10:30AM +0200, Andrey Konovalov
On Fri, Oct 09, 2020 at 12:10:44PM +0200, Michal Hocko wrote:
> On Fri 09-10-20 11:42:45, Peter Zijlstra wrote:
> > On Fri, Oct 09, 2020 at 11:12:18AM +0200, Michal Hocko wrote:
> > > Is there any additional feedback? Should I split up the patch and repost
> > > for inclusion?
> >
> > Maybe
oops, CC'ed the wrong ML, sorry ...
On 09.10.20 12:13, John Crispin wrote:
Changes in V4
* move multiple bssid config from add_interface to start_ap
* add ema support
John Crispin (4):
nl80211: add basic multiple bssid support
mac80211: add multiple bssid support to interface handling
On Fri 09-10-20 11:47:41, Peter Zijlstra wrote:
> On Wed, Oct 07, 2020 at 02:35:53PM +0200, Michal Hocko wrote:
> > On Wed 07-10-20 14:21:44, Peter Zijlstra wrote:
> > > On Wed, Oct 07, 2020 at 02:04:01PM +0200, Michal Hocko wrote:
> > > > I wanted to make sure that the idea is sound for
Em Fri, 9 Oct 2020 09:59:23 +0200
Daniel Vetter escreveu:
> It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
> symbol from all over the tree (well just one place, somehow omap media
> driver still had this in its Kconfig, despite not using it).
>
> Reviewed-by: John
On Fri, Oct 09, 2020 at 10:59:45AM +0100, John Keeping wrote:
> No, it's not, although I would have saved several days debugging if it
> was! I backported the lockdep warning to prove that it caught this
> issue.
>
> The evidence it is possible to see on vanilla 5.4.x is:
>
> $ trace-cmd
On Fri 09-10-20 11:42:45, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 11:12:18AM +0200, Michal Hocko wrote:
> > Is there any additional feedback? Should I split up the patch and repost
> > for inclusion?
>
> Maybe remove PREEMPT_NONE after that? Since that's then equivalent to
> building
On Fri, Oct 9, 2020 at 11:56 AM Laurent Vivier wrote:
> This information is unused since the discontinuous memory support
> has been introduced in 2007.
>
> Fixes: 12d810c1b8c2 ("m68k: discontinuous memory support")
> Signed-off-by: Laurent Vivier
Reviewed-by: Geert Uytterhoeven
i.e. will
Hillf Danton wrote:
> + /*
> + * care to detect writers because
> + *
> + * read_seqbegin_or_lock(>cells_lock, );
> + *
> + * is unable to block
> +
On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
wrote:
>
> On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > do nothing for i915. Because i915 doesn't request any regions, like
> > pretty much all drm pci
Linus Walleij writes:
> Hi Lars!
>
> This is overall looking fine. Except for the 3 cell business. I just can't
> wrap my head around why that is needed.
>
> On Thu, Oct 8, 2020 at 3:05 PM Lars Povlsen
> wrote:
>
>> + '#gpio-cells':
>> +const: 3
>
> So at the very least needs a
On Fri, 9 Oct 2020 02:46:09 +0300
Vladimir Oltean wrote:
> On Thu, Oct 08, 2020 at 05:27:49PM +0100, John Keeping wrote:
> > With threadirqs, stmmac_interrupt() is called on a thread with hardirqs
> > enabled so we cannot call __napi_schedule_irqoff(). Under lockdep it
> > leads to:
> >
> >
On Fri, Oct 02, 2020 at 11:01:34PM +0530, Naresh Kamboju wrote:
> On Thu, 24 Sep 2020 at 21:51, Christian Brauner
> wrote:
> >
> > On Thu, Sep 24, 2020 at 04:33:17PM +0200, Christian Brauner wrote:
> > > On Wed, Sep 23, 2020 at 07:52:05PM +0530, Naresh Kamboju wrote:
> > > > selftests: pidfd:
This information is unused since the discontinuous memory support
has been introduced in 2007.
Fixes: 12d810c1b8c2 ("m68k: discontinuous memory support")
Signed-off-by: Laurent Vivier
---
arch/m68k/amiga/config.c| 8
arch/m68k/apollo/config.c | 1 -
On Fri, Oct 09, 2020 at 10:37:51AM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2020 at 11:09:27AM +0200, Peter Zijlstra wrote:
> > Patch 4 makes it all far worse by exposing it to pretty much everybody.
> >
> > Now, I think we can fix at least the user mappings with the below delta,
> > but if
On 10/9/20 9:11 AM, Catalin Marinas wrote:
> On Thu, Oct 08, 2020 at 07:24:12PM +0100, Vincenzo Frascino wrote:
>> On 10/2/20 3:06 PM, Catalin Marinas wrote:
>>> On Fri, Oct 02, 2020 at 01:10:30AM +0200, Andrey Konovalov wrote:
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
Hi,
What do you think about this patch?
Regards,
Mickaël
On 02/10/2020 09:18, Mickaël Salaün wrote:
> From: Mickaël Salaün
>
> Add a new DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING configuration
> to enable dm-verity signatures to be verified against the secondary
> trusted keyring.
On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> do nothing for i915. Because i915 doesn't request any regions, like
> pretty much all drm pci drivers. I guess this is some very old
> remnants from the
On Wed, Oct 07, 2020 at 02:35:53PM +0200, Michal Hocko wrote:
> On Wed 07-10-20 14:21:44, Peter Zijlstra wrote:
> > On Wed, Oct 07, 2020 at 02:04:01PM +0200, Michal Hocko wrote:
> > > I wanted to make sure that the idea is sound for maintainers first. The
> > > next step would be extending the
On Fri, Oct 09, 2020 at 01:00:14AM -0700, Yang Yang wrote:
> blk_exit_queue will free elevator_data, while blk_mq_run_work_fn
> will access it. Move cancel of hctx->run_work to the front of
> blk_exit_queue to avoid use-after-free.
>
> Fixes: 1b97871b501f ("blk-mq: move cancel of hctx->run_work
Hi Lars!
This is overall looking fine. Except for the 3 cell business. I just can't
wrap my head around why that is needed.
On Thu, Oct 8, 2020 at 3:05 PM Lars Povlsen wrote:
> + '#gpio-cells':
> +const: 3
So at the very least needs a description making it crystal clear why each
On Wed, 7 Oct 2020 14:56:23 -0400
Matthew Rosato wrote:
> Define a new configuration entry VFIO_PCI_ZDEV for VFIO/PCI.
>
> When this s390-only feature is configured we add capabilities to the
> VFIO_DEVICE_GET_INFO ioctl that describe features of the associated
> zPCI device and its underlying
On Thu, Oct 08, 2020 at 03:26:32PM +0300, Tommi Rantala wrote:
> XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
> into SKIP"), use SKIP instead.
>
> Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
> Signed-off-by: Tommi Rantala
> ---
Thanks!
Acked-by:
On Thu, Oct 08, 2020 at 03:26:31PM +0300, Tommi Rantala wrote:
> XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
> into SKIP"), use SKIP instead.
>
> Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
> Signed-off-by: Tommi Rantala
> ---
Thanks!
Acked-by:
On Thu, Oct 08, 2020 at 03:26:33PM +0300, Tommi Rantala wrote:
> XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
> into SKIP"), use SKIP instead.
>
> Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
> Signed-off-by: Tommi Rantala
> ---
Thanks!
Acked-by:
Hi Qian,
On Fri, Oct 09, 2020 at 09:51:15AM +0100, Will Deacon wrote:
> On Thu, Oct 08, 2020 at 09:18:24PM -0400, Qian Cai wrote:
> > On Mon, 2020-10-05 at 17:43 +0100, Mark Rutland wrote:
> > > The current initialization of the per-cpu offset register is difficult
> > > to follow and this
On Thu, Oct 08, 2020 at 03:26:22PM +0300, Tommi Rantala wrote:
> Drop unneeded header inclusion to fix pidfd compilation
> errors seen in Fedora 32:
>
> In file included from pidfd_open_test.c:9:
> ../../../../usr/include/linux/wait.h:17:16: error: expected identifier before
> numeric constant
801 - 900 of 1188 matches
Mail list logo
