On Thu, Oct 22, 2020 at 8:31 PM Christopher Unkel wrote:
>
> Writes of the md superblock are aligned to the logical blocks of the
> containing device, but no attempt is made to align them to physical
> block boundaries. This means that on a "512e" device (4k physical, 512
> logical) every
On Thu, Oct 22, 2020 at 8:31 PM Christopher Unkel wrote:
>
> Hello all,
>
> While investigating some performance issues on mdraid 10 volumes
> formed with "512e" disks (4k native/physical sector size but with 512
> byte sector emulation), I've found two cases where mdraid will
> needlessly issue
Em Thu, 22 Oct 2020 22:09:25 +0200
Krzysztof Kozlowski escreveu:
> On Thu, Oct 22, 2020 at 09:13:14PM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > this series doesn't seem to be applied and looking at the list of people
> > this mail was sent "To:" it's not obvious who is expected to take
If some bits were cleared by i2c_dw_read_clear_intrbits_slave() in
i2c_dw_isr_slave() and not handled immediately, those cleared bits would
not be shown again by later i2c_dw_read_clear_intrbits_slave(). They
therefore were forgotten to be handled.
i2c_dw_read_clear_intrbits_slave() should be
On 22-10-20, 13:57, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The restore_freq field in struct cpufreq_policy is only used by
> __target_index() in one place and a local variable in that function
> may as well be used instead of it, so drop it and modify
> __target_index()
On 10/22/2020 9:19 PM, Mathieu Desnoyers wrote:
- On Oct 21, 2020, at 9:54 PM, Xing Zhengjun zhengjun.x...@linux.intel.com
wrote:
[...]
In fact, 0-day just copy the will-it-scale benchmark from the GitHub, if
you think the will-it-scale benchmark has some issues, you can
contribute your
-randconfig-r034-20201022 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux
On 2020/10/22 23:25, Joel Fernandes wrote:
> On Thu, Oct 22, 2020 at 12:59 AM Li, Aubrey wrote:
>>
>> On 2020/10/20 9:43, Joel Fernandes (Google) wrote:
>>> From: Peter Zijlstra
>>>
>>> Because sched_class::pick_next_task() also implies
>>> sched_class::set_next_task() (and possibly
When unbinding the hns3 driver with the HNS3 VF, I got the following
kernel panic:
[ 265.709989] Unable to handle kernel paging request at virtual address
800054627000
[ 265.717928] Mem abort info:
[ 265.720740] ESR = 0x9647
[ 265.723810] EC = 0x25: DABT (current EL), IL = 32
On 22-10-20, 17:55, Vincent Guittot wrote:
> On Thu, 22 Oct 2020 at 17:45, A L wrote:
> >
> >
> >
> > From: Peter Zijlstra -- Sent: 2020-10-22 -
> > 14:29
> >
> > > On Thu, Oct 22, 2020 at 02:19:29PM +0200, Rafael J. Wysocki wrote:
> > >> > However I do want to retire ondemand,
On Thu, Oct 22, 2020 at 08:05:05PM -0700, Linus Torvalds wrote:
> On Thu, Oct 22, 2020 at 6:36 PM Daniel Díaz wrote:
> >
> > The kernel Naresh originally referred to is here:
> > https://builds.tuxbuild.com/SCI7Xyjb7V2NbfQ2lbKBZw/
>
> Thanks.
>
> And when I started looking at it, I realized
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. You will get:
- a new driver for ADC driven joysticks
- a new Zintix touchscreen driver
- enhancements to Intel SoC button array driver
-
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f9893351acaecf0a414baf9942b48d5bb5c688c6
commit: 6d82120f41561426dd67c86380d779b4599d070d device-dax: add an 'align'
attribute
date: 9 days ago
config: mips-randconfig-m031-20201022 (attached as .config
On Thu, 2020-10-22 at 08:02 +0100, Sudeep Holla wrote:
> On Thu, Oct 22, 2020 at 02:17:48PM +0800, Claude Yen wrote:
> > As suspend_set_ops is exported in commit a5e4fd8783a2
> > ("PM / Suspend: Export suspend_set_ops, suspend_valid_only_mem"),
> > exporting s2idle_set_ops to make kernel module
From: Izabela Bakollari
Dropwatch is a utility that monitors dropped frames by having userspace
record them over the dropwatch protocol over a file. This augument
allows live monitoring of dropped frames using tools like tcpdump.
With this feature, dropwatch allows two additional commands
发件人: Zhang, Qiang
发送时间: 2020年10月23日 11:55
收件人: Jens Axboe
抄送: v...@zeniv.linux.org.uk; io-ur...@vger.kernel.org;
linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org
主题: 回复: Question on io-wq
发件人: Jens
发件人: Jens Axboe
发送时间: 2020年10月22日 22:08
收件人: Zhang, Qiang
抄送: v...@zeniv.linux.org.uk; io-ur...@vger.kernel.org;
linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org
主题: Re: Question on io-wq
On 10/22/20 3:02 AM, Zhang,Qiang wrote:
>
> Hi Jens
Hello Lakshmi,
Lakshmi Ramasubramanian writes:
> On 10/20/20 8:17 PM, Mimi Zohar wrote:
>> On Tue, 2020-10-20 at 19:25 -0700, Lakshmi Ramasubramanian wrote:
>>> On 10/20/20 1:00 PM, Mimi Zohar wrote:
Hi Lakshmi,
On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote:
On Thu, 2020-10-22 at 19:54 -0700, Hugh Dickins wrote:
> On Thu, 22 Oct 2020, Rik van Riel wrote:
>
> > The allocation flags of anonymous transparent huge pages can be
> controlled
> > through the files in /sys/kernel/mm/transparent_hugepage/defrag,
> which can
> > help the system from getting
Clang warns about the extra parentheses in this comparison:
drivers/net/ethernet/freescale/ucc_geth.c:1361:28:
warning: equality comparison with extraneous parentheses
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_SGMII))
~^~~
It
Writes of the last page of the bitmap are padded out to the next logical
block boundary. However, they are not padded out to the next physical
block boundary, so the writes may be less than a physical block. On a
"512e" disk (logical block 512 bytes, physical block 4k) and if the last
page of
Refactor in preparation for a second use of the logic.
Signed-off-by: Christopher Unkel
---
drivers/md/md-bitmap.c | 72 +++---
1 file changed, 40 insertions(+), 32 deletions(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index
Hello all,
While investigating some performance issues on mdraid 10 volumes
formed with "512e" disks (4k native/physical sector size but with 512
byte sector emulation), I've found two cases where mdraid will
needlessly issue writes that start on 4k byte boundary, but are are
shorter than 4k:
1.
Writes of the md superblock are aligned to the logical blocks of the
containing device, but no attempt is made to align them to physical
block boundaries. This means that on a "512e" device (4k physical, 512
logical) every superblock update hits the 512-byte emulation and the
possible associated
Add the new functions prepare_to_busy_poll() and friends to
napi_busy_loop(). The busy polling cpu will be considered an idle
target during wake up balancing.
Suggested-by: Xi Wang
Signed-off-by: Josh Don
Signed-off-by: Xi Wang
---
net/core/dev.c | 8
1 file changed, 4 insertions(+),
Add the new functions prepare_to_busy_poll() and friends to
kvm_vcpu_block. The busy polling cpu will be considered an
idle target during wake up balancing.
cpu_relax is also added to the polling loop to improve the performance
of other hw threads sharing the busy polling core.
Suggested-by: Xi
Busy polling loops in the kernel such as network socket poll and kvm
halt polling have performance problems related to process scheduler load
accounting.
Both of the busy polling examples are opportunistic - they relinquish
the cpu if another thread is ready to run. This design, however, doesn't
On Thu, 22 Oct 2020, Geert Uytterhoeven wrote:
>
> Thanks for your patch...
>
You're welcome.
> I can't say I'm a fan of this...
>
Sorry.
>
> The real issue is this "extern struct platform_device scc_a_pdev,
> scc_b_pdev", circumventing the driver framework.
>
> Can we get rid of that?
On Wed, Oct 21, 2020 at 09:58:50PM -0700, Eric Biggers wrote:
> On Tue, Oct 20, 2020 at 04:39:53PM -0400, Arvind Sankar wrote:
> > The assignments to clear a through h and t1/t2 are optimized out by the
> > compiler because they are unused after the assignments.
> >
> > These variables shouldn't
On Thu, Oct 22, 2020 at 11:12:36PM -0400, Arvind Sankar wrote:
>
> I was aiming for 8 columns per line to match all the other groupings by
> eight. It does slightly exceed 100 columns but can this be an exception,
> or should I maybe make it 4 columns per line?
Please limit it to 4 columns.
On Wed, Oct 14, 2020 at 04:44:57PM -0700, Jim Mattson wrote:
> On Fri, Oct 9, 2020 at 9:17 AM Jim Mattson wrote:
> >
> > On Fri, Jul 10, 2020 at 8:48 AM Mohammed Gamal wrote:
> > > @@ -5308,6 +5314,18 @@ static int handle_ept_violation(struct kvm_vcpu
> > > *vcpu)
> > >
On Wed, Oct 21, 2020 at 10:02:19PM -0700, Eric Biggers wrote:
> On Tue, Oct 20, 2020 at 04:39:55PM -0400, Arvind Sankar wrote:
> > This reduces code size substantially (on x86_64 with gcc-10 the size of
> > sha256_update() goes from 7593 bytes to 1952 bytes including the new
> > SHA256_K array),
On Thu, Oct 22, 2020 at 6:36 PM Daniel Díaz wrote:
>
> The kernel Naresh originally referred to is here:
> https://builds.tuxbuild.com/SCI7Xyjb7V2NbfQ2lbKBZw/
Thanks.
And when I started looking at it, I realized that my original idea
("just look for __put_user_nocheck_X calls, there aren't so
Hi viro:
Through regfs is very sample and easy, but i think it is a Interest
, could give some suggestions?
Regards,
zc
在 2020/10/20 下午2:30, Zou Cao 写道:
register filesystem is mapping the register into file dentry, it
will use the io readio to get the register val. DBT file is use
to
On Thu, 22 Oct 2020, Rik van Riel wrote:
> The allocation flags of anonymous transparent huge pages can be controlled
> through the files in /sys/kernel/mm/transparent_hugepage/defrag, which can
> help the system from getting bogged down in the page reclaim and compaction
> code when many THPs
Hello,
On Tue, Oct 20, 2020 at 5:48 AM Stanislav Ivanichkin
wrote:
>
> Hi,
>
> +linux-perf-users@
>
> Gentle ping for this patch
>
> Many Thanks
>
> --
> Stanislav Ivanichkin
>
> > On 9 Oct 2020, at 09:45, Stanislav Ivanichkin
> > wrote:
> >
> > # ./perf trace -e sched:sched_switch -G test -a
The eeh-basic test got its own 60 seconds timeout (defined in commit
414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable
device.
And we have discovered that the number of breakable devices varies
on different hardware. The device recovery time ranges from 0 to 35
seconds. In
The driver does not implement a shutdown handler which leads to issues
when using kexec in certain scenarios. The NIC keeps on fetching
descriptors which gets flagged by the IOMMU with errors like this:
DMAR: DMAR:[DMA read] Request device [5e:00.0]fault addr f000
DMAR: DMAR:[DMA read]
On Thu, 22 Oct 2020, Tianxianting wrote:
> I see, If we add this patch, we need to get all cpu arch that support
> nested interrupts.
>
I was just calling into question 1. the benefit (does it improve
performance?) and 2. the code style (is it less portable?).
It's really the style question
On Fri, Oct 23, 2020 at 10:07 AM Michael Ellerman wrote:
>
> Po-Hsu Lin writes:
> > The eeh-basic test got its own 60 seconds timeout (defined in commit
> > 414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable
> > device.
> >
> > And we have discovered that the number of
Hi Linus,
This is an unusual 2nd pull request for merge window. I found a snafu in perf
driver which made it into 5.9-rc4 and thus the fix could go in now than wait for
5.10-rc2. Sorry for the trouble.
Thx,
-Vineet
->
The following changes since commit
Hi all,
Since the merge window is open, please do not add any v5.11 material to
your linux-next included branches until after v5.10-rc1 has been released.
Changes since 20201022:
Non-merge commits (relative to Linus' tree): 1952
2322 files changed, 329767 insertions(+), 37681 deletions
This patch introduces a new ioctl for vhost-vdpa device that can
report the iova range by the device.
For device that implements get_iova_range() method, we fetch it from
the vDPA device. If device doesn't implement get_iova_range() but
depends on platform IOMMU, we will query via
On Thu, Oct 22, 2020 at 6:56 PM Xie He wrote:
>
> My patch isn't complete. Because there are so many drivers with this
> problem, I feel it's hard to solve them all at once. So I only grepped
> "skb_padto" under "drivers/net/ethernet". There are other drivers
> under "ethernet" using "skb_pad",
This implements a sample get_iova_range() for the simulator which
advertise [0, ULLONG_MAX] as the valid range.
Signed-off-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c
Hi All:
This series introduces API for reporing IOVA range. This is a must for
userspace to work correclty:
- for the process that uses vhost-vDPA directly, the IOVA must be
allocated from this range.
- for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out
of range
- for
This patch introduce a config op to get valid iova range from the vDPA
device.
Signed-off-by: Jason Wang
---
include/linux/vdpa.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index eae0bfd87d91..30bc7a7223bb 100644
---
On 10/22/20 8:05 PM, Hillf Danton wrote:
> On Thu, 22 Oct 2020 08:08:09 -0600 Jens Axboe wrote:
>> On 10/22/20 3:02 AM, Zhang,Qiang wrote:
>>>
>>> Hi Jens Axboe
>>>
>>> There are some problem in 'io_wqe_worker' thread, when the
>>> 'io_wqe_worker' be create and Setting the affinity of CPUs in
On 10/16/20 9:45 AM, Jens Axboe wrote:
> Hi,
>
> The goal is this patch series is to decouple TWA_SIGNAL based task_work
> from real signals and signal delivery. The motivation is speeding up
> TWA_SIGNAL based task_work, particularly for threaded setups where
> ->sighand is shared across
drm_sysfs_connector_add() misses to call device_unregister() when
sysfs_create_link() fails to create. Add the missed function call
to fix it.
Fixes: e1a29c6c5955 ("drm: Add ddc link in sysfs created by drm_connector")
Signed-off-by: Jing Xiangfeng
---
drivers/gpu/drm/drm_sysfs.c | 13
On Thu, Oct 22, 2020 at 7:06 PM Namhyung Kim wrote:
>
> Current script to generate mmap flags and prot checks headers from the
> uapi/asm-generic directory but it might come from a different
> directory in some environment. So change the pattern to accept it.
>
> Signed-off-by: Namhyung Kim
Po-Hsu Lin writes:
> The eeh-basic test got its own 60 seconds timeout (defined in commit
> 414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable
> device.
>
> And we have discovered that the number of breakable devices varies
> on different hardware. The device recovery time
On 2020/10/22 18:05, zhenwei pi wrote:
On 10/22/20 5:55 PM, Chao Leng wrote:
On 2020/10/22 16:38, zhenwei pi wrote:
Hit a kernel warning:
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 0 at lib/refcount.c:28
RIP: 0010:refcount_warn_saturate+0xd9/0xe0
Call Trace:
On Wed, Oct 21, 2020 at 02:17:23PM +0200, Mauro Carvalho Chehab wrote:
> There are several warnings caused by a recent change
> 224ec489d3cd ("lockdep/Documention: Recursive read lock detection reasoning")
>
> Those are reported by htmldocs build:
>
>
Current script to generate mmap flags and prot checks headers from the
uapi/asm-generic directory but it might come from a different
directory in some environment. So change the pattern to accept it.
Signed-off-by: Namhyung Kim
---
tools/perf/trace/beauty/mmap_flags.sh | 4 ++--
Hi Linus,
Two cleanups that don't fit other categories:
- Finally get the task_work_add() cleanup done properly, so we don't
have random 0/1/false/true/TWA_SIGNAL confusing use cases. Updates all
callers, and also fixes up the documentation for task_work_add().
- While working on some TIF
On Thu, Oct 22, 2020 at 5:44 PM Jakub Kicinski wrote:
>
> On Thu, 22 Oct 2020 12:59:45 -0700 Xie He wrote:
> >
> > But I also see some drivers that want to pad the skb to a strange
> > length, and don't set their special min_mtu to match this length. For
> > example:
> >
> >
From: Vladimir Oltean Sent: Friday, October 23, 2020
9:34 AM
> Prior to the commit that this one fixes, the FIFO size was derived from the
> read-only register LPUARTx_FIFO[TXFIFOSIZE] using the following
> formula:
>
> TX FIFO size = 2 ^ (LPUARTx_FIFO[TXFIFOSIZE] - 1)
>
> The documentation
From: Vladimir Oltean Sent: Thursday, October 22, 2020
11:13 PM
> From: Vladimir Oltean
>
> Similar to the workaround applied by Michael Walle in commit c2f448cff22a
> ("tty: serial: fsl_lpuart: add LS1028A support"), it turns out that the
> LPUARTx_FIFO encoding for fields TXFIFOSIZE and
allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20201022
i386 randconfig-a005-20201022
i386
Hello!
On Thu, 22 Oct 2020 at 19:11, Linus Torvalds
wrote:
> On Thu, Oct 22, 2020 at 4:43 PM Linus Torvalds
> Would you mind sending me the problematic vmlinux file in private (or,
> likely better - a pointer to some place I can download it, it's going
> to be huge).
The kernel Naresh
Prior to the commit that this one fixes, the FIFO size was derived from
the read-only register LPUARTx_FIFO[TXFIFOSIZE] using the following
formula:
TX FIFO size = 2 ^ (LPUARTx_FIFO[TXFIFOSIZE] - 1)
The documentation for LS1021A is a mess. Under chapter 26.1.3 LS1021A
LPUART module special
On Wed, Oct 21, 2020 at 12:39 PM Richard Guy Briggs wrote:
> Here is an exmple I was able to generate after updating the testsuite
> script to include a signalling example of a nested audit container
> identifier:
>
>
> type=PROCTITLE msg=audit(2020-10-21 10:31:16.655:6731) :
>
On Thu, Oct 22, 2020 at 5:54 PM Jin Yao wrote:
>
> Ian reports an issue that the metric DRAM_BW_Use often remains 0.
>
> The metric expression for DRAM_BW_Use on CLX/SKX:
>
> "( 64 * ( uncore_imc@cas_count_read@ + uncore_imc@cas_count_write@ ) /
> 10 ) / duration_time"
>
> The counts of
On 22 Oct 2020, at 20:47, Roman Gushchin wrote:
> On Thu, Oct 22, 2020 at 07:42:45PM -0400, Zi Yan wrote:
>> On 22 Oct 2020, at 18:53, Roman Gushchin wrote:
>>
>>> This small patchset introduces a non-blocking version of cma_release()
>>> and simplifies the code in hugetlbfs, where previously we
Ian reports an issue that the metric DRAM_BW_Use often remains 0.
The metric expression for DRAM_BW_Use on CLX/SKX:
"( 64 * ( uncore_imc@cas_count_read@ + uncore_imc@cas_count_write@ ) /
10 ) / duration_time"
The counts of uncore_imc/cas_count_read/ and uncore_imc/cas_count_write/
are
On 10/21, Can Guo wrote:
> On 2020-10-21 12:52, jaeg...@kernel.org wrote:
> > On 10/21, Can Guo wrote:
> > > On 2020-10-21 03:52, Jaegeuk Kim wrote:
> > > > The below call stack prevents clk_gating at every IO completion.
> > > > We can remove the condition, ufshcd_any_tag_in_use(), since
> > > >
On Thu, Oct 22, 2020 at 07:42:45PM -0400, Zi Yan wrote:
> On 22 Oct 2020, at 18:53, Roman Gushchin wrote:
>
> > This small patchset introduces a non-blocking version of cma_release()
> > and simplifies the code in hugetlbfs, where previously we had to
> > temporarily drop hugetlb_lock around the
On Wed, Oct 21, 2020 at 8:07 AM Mark Salyzyn wrote:
> On 10/20/20 6:17 PM, Paul Moore wrote:
> > On Tue, Oct 20, 2020 at 3:17 PM Mark Salyzyn wrote:
> >> Add a flag option to get xattr method that could have a bit flag of
> >> XATTR_NOSECURITY passed to it. XATTR_NOSECURITY is generally then
>
On Thu, 22 Oct 2020 12:59:45 -0700 Xie He wrote:
> On Thu, Oct 22, 2020 at 8:22 AM Jakub Kicinski wrote:
> >
> > Are most of these drivers using skb_padto()? Is that the reason they
> > can't be sharing the SKB?
>
> Yes, I think if a driver calls skb_pad / skb_padto / skb_put_padto /
>
On Thu, Oct 22, 2020 at 04:59:56PM -0700, Shakeel Butt wrote:
> On Thu, Oct 22, 2020 at 10:25 AM Roman Gushchin wrote:
> >
> [snip]
> > >
> > > Since bf4f059954dc ("mm: memcg/slab: obj_cgroup API") is in 5.9, I
> > > think we can take this patch for 5.9 and 5.10 but keep Roman's cleanup
> > > for
Subtract the minimum padding between regions from the initial
remain_entropy. Without this, the last region could potentially
overflow past vaddr_end if we happen to get a specific sequence
of random numbers (although extremely unlikely in practice).
The bug can be demonstrated by replacing the
From: Ranjani Sridharan
Create an SOF client driver for IPC flood test. This
driver is used to set up the debugfs entries and the
read/write ops for initiating the IPC flood test that
would be used to measure the min/max/avg response times
for sending IPCs to the DSP. The debugfs ops definitions
From: Ranjani Sridharan
sof_probe_compr_ops are not platform-specific. So move
it to common compress code and export the symbol. The
compilation of the common compress code is already dependent
on the selection of CONFIG_SND_SOC_SOF_DEBUG_PROBES, so no
need to check the Kconfig section for
From: Ranjani Sridharan
A client in the SOF (Sound Open Firmware) context is a
device that needs to communicate with the DSP via IPC
messages. The SOF core is responsible for serializing the
IPC messages to the DSP from the different clients. One
example of an SOF client would be an IPC test
From: Ranjani Sridharan
Add a new client driver for probes support and move
all the probes-related code from the core to the
client driver.
The probes client driver registers a component driver
with one CPU DAI driver for extraction and creates a
new sound card with one DUMMY DAI link with a
From: Ranjani Sridharan
Remove the IPC flood test support in the SOF core as it is
now added in the IPC flood test client.
Reviewed-by: Pierre-Louis Bossart
Signed-off-by: Fred Oh
Signed-off-by: Ranjani Sridharan
Signed-off-by: Dave Ertman
---
sound/soc/sof/Kconfig| 8 --
From: Ranjani Sridharan
Add client APIs to invoke the platform-specific DSP probes
ops. Also, add a new API to get the SOF core device pointer
which will be used for DMA buffer allocation.
Reviewed-by: Pierre-Louis Bossart
Tested-by: Fred Oh
Signed-off-by: Ranjani Sridharan
Signed-off-by:
From: Ranjani Sridharan
Register the client device for probes support on the
CNL platform. Creating this client device alleviates the
need for modifying the sound card definitions in the existing
machine drivers to add support for the new probes feature in
the FW. This will result in the
From: Ranjani Sridharan
Add new ops for registering/unregistering clients based
on DSP capabilities and/or DT information.
Reviewed-by: Pierre-Louis Bossart
Signed-off-by: Ranjani Sridharan
Signed-off-by: Dave Ertman
---
sound/soc/sof/core.c | 10 ++
sound/soc/sof/ops.h |
From: Ranjani Sridharan
Define client ops for Intel platforms. For now, we only add
2 IPC test clients that will be used for run tandem IPC flood
tests for.
For ACPI platforms, change the Kconfig to select
SND_SOC_SOF_PROBE_WORK_QUEUE to allow the ancillary driver
to probe when the client is
Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
It enables drivers to create an auxiliary_device and bind an
auxiliary_driver to it.
The bus supports probe/remove shutdown and suspend/resume callbacks.
Each auxiliary_device has a unique string based id; driver binds to
Brief history of Auxiliary Bus
==
The auxiliary bus code was originally submitted upstream as virtual
bus, and was submitted through the netdev tree. This process generated
up to v4. This discussion can be found here:
On (20/10/22 13:42), Petr Mladek wrote:
> +static bool mute_console;
> +
> +static int __init mute_console_setup(char *str)
> +{
> + mute_console = true;
> + pr_info("All consoles muted.\n");
> +
> + return 0;
> +}
First of all, thanks a lot for picking this up and for the patch set!
allnoconfig
i386 randconfig-a002-20201022
i386 randconfig-a005-20201022
i386 randconfig-a003-20201022
i386 randconfig-a001-20201022
i386 randconfig-a006-20201022
i386 randconfig
On Thu, Oct 22, 2020 at 5:11 PM Linus Torvalds
wrote:
>
> In particular, I wonder if it's that KASAN causes some reload pattern,
> and the whole
>
> register __typeof__(*(ptr)) __val_pu asm("%"_ASM_AX);
> ..
> asm volatile(.. "r" (__val_pu) ..)
>
> thing causes problems.
That pattern
On 10/22/20 5:48 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (KCONFIG_NAME)
> produced this warning:
>
> fs/io_uring.c: In function 'loop_rw_iter':
> fs/io_uring.c:3141:21: warning: cast to pointer from integer of different
> size
On Thu, 22 Oct 2020 at 21:02, Paolo Bonzini wrote:
>
> On 22/10/20 03:34, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Per KVM_GET_SUPPORTED_CPUID ioctl documentation:
> >
> > This ioctl returns x86 cpuid features which are supported by both the
> > hardware and kvm in its default
On Thu, Oct 22, 2020 at 04:04:16PM -0700, James Bottomley wrote:
> On Thu, 2020-10-22 at 15:06 -0700, Moritz Fischer wrote:
> > The driver does not implement a shutdown handler which leads to
> > issues
> > when using kexec in certain scenarios. The NIC keeps on fetching
> > descriptors which gets
On Thu, Oct 22, 2020 at 4:43 PM Linus Torvalds
wrote:
>
> Thanks. Very funky, but thanks. I've been running that commit on my
> machine for over half a year, and it still looks "trivially correct"
> to me, but let me go look at it one more time. Can't argue with a
> reliable bisect and revert..
Hi Linus,
This should be the last round of things for rc1, a bunch of i915
fixes, some amdgpu, more font OOB fixes and one ttm fix just found
reading code.
Dave.
drm-next-2020-10-23:
drm fixes (round two) for 5.10-rc1
fbcon/fonts:
- Two patches to prevent OOB access
ttm:
- fix for eviction
On Thu, 22 Oct 2020 10:45:51 +0300 Alexandru Ardelean wrote:
> The ADIN1300/ADIN1200 support cable diagnostics using TDR.
>
> The cable fault detection is automatically run on all four pairs looking at
> all combinations of pair faults by first putting the PHY in standby (clear
> the LINK_EN bit,
On Thu, Oct 22, 2020 at 10:25 AM Roman Gushchin wrote:
>
[snip]
> >
> > Since bf4f059954dc ("mm: memcg/slab: obj_cgroup API") is in 5.9, I
> > think we can take this patch for 5.9 and 5.10 but keep Roman's cleanup
> > for 5.11.
> >
> > What does everyone think?
>
> I think we should use the link
On Wed, Oct 21, 2020 at 3:36 PM Theodore Y. Ts'o wrote:
>
> On Wed, Oct 21, 2020 at 02:16:56PM -0700, Randy Dunlap wrote:
> > On 10/21/20 2:15 PM, Brendan Higgins wrote:
> > > On Tue, Oct 20, 2020 at 12:37 AM Geert Uytterhoeven
> > > wrote:
> > >>
> > >> EXT4_KUNIT_TESTS selects EXT4_FS, thus
On Thu, Oct 22, 2020 at 1:55 PM Naresh Kamboju
wrote:
>
> The bad commit points to,
>
> commit d55564cfc222326e944893eff0c4118353e349ec
> x86: Make __put_user() generate an out-of-line call
>
> I have reverted this single patch and confirmed the reported
> problem is not seen anymore.
Thanks.
Hi all,
After merging the block tree, today's linux-next build (KCONFIG_NAME)
produced this warning:
fs/io_uring.c: In function 'loop_rw_iter':
fs/io_uring.c:3141:21: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
3141 |iovec.iov_base = (void __user *)
On 22 Oct 2020, at 18:53, Roman Gushchin wrote:
> This small patchset introduces a non-blocking version of cma_release()
> and simplifies the code in hugetlbfs, where previously we had to
> temporarily drop hugetlb_lock around the cma_release() call.
>
> It should help Zi Yan on his work on 1 GB
On Thu, Oct 22, 2020 at 5:32 PM Kees Cook wrote:
> I've been going back and forth on this, and I think what I've settled
> on is I'd like to avoid new CONFIG dependencies just for this feature.
> Instead, how about we just fill in SECCOMP_NATIVE and SECCOMP_COMPAT
> for all the
On Thu, Oct 22, 2020 at 10:22:25PM +0100, Matthew Wilcox (Oracle) wrote:
> +static int readpage_submit_bhs(struct page *page, struct blk_completion
> *cmpl,
> + unsigned int nr, struct buffer_head **bhs)
> +{
> + struct bio *bio = NULL;
> + unsigned int i;
> + int err;
> +
--
Mein Name ist Manuel Franco, ich bin der Gewinner des Powerball Mega
Jackpot-Gewinners in Höhe von 768 Millionen US-Dollar aus New Jersey,
USA,
und ich freue mich, Ihnen zu gratulieren, dass Sie zufällig unter den 5
glücklichen Menschen ausgewählt wurden, denen ich jeweils 2 Millionen
1 - 100 of 1016 matches
Mail list logo
