Some VMD devices provide a management window within MEMBAR2 that is used
to communicate out-of-band with child devices. This patch creates a
binary file for interacting with the interface.
OOB Reads/Writes are bounds-checked by sysfs_fs_bin_{read,write}
Signed-off-by: Jon Derrick
---
Depends on
If a process (qemu) with a lot of CPUs (128) try to munmap() a large chunk
of memory (496GB) mapped with THP, it takes an average of 275 seconds,
which can cause a lot of problems to the load (in qemu case, the guest
will lock for this time).
Trying to find the source of this bug, I found out most
On Mon, Sep 16, 2019 at 01:00:11PM -0700, David Rientjes wrote:
> On Mon, 16 Sep 2019, syzbot wrote:
> > HEAD commit:f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
general protection fault in vidioc_querycap
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] SMP KASAN
CPU: 0 PID: 293
On Mon Sep 16 19, Jarkko Sakkinen wrote:
tpm_send() does not give anymore the result back to the caller. This
would require another memcpy(), which kind of tells that the whole
approach is somewhat broken. Instead, as Mimi suggested, this commit
just wraps the data to the tpm_buf, and thus the re
On Mon, Sep 16, 2019 at 10:13:41AM -0400, KeMeng Shi wrote:
> Commit f786ecba41588 ("connector: add comm change event report to proc
> connector") added proc_comm_connector to report comm change event, and
> prctl will report comm change event when dealing with PR_SET_NAME case.
>
> prctl can onl
On Mon Sep 16 19, Jerry Snitselaar wrote:
On Mon Sep 16 19, Jarkko Sakkinen wrote:
tpm_send() does not give anymore the result back to the caller. This
would require another memcpy(), which kind of tells that the whole
approach is somewhat broken. Instead, as Mimi suggested, this commit
just wra
On Sat, Sep 14, 2019 at 12:03:26AM +, Wei Yang wrote:
> On Mon, Jul 08, 2019 at 04:27:40PM +0800, Wei Yang wrote:
> >Since ptent will not be changed after previous assignment of entry, it
> >is not necessary to do the assignment again.
> >
>
> Sounds this one is lost in the time line :-)
Don'
Intel Cherry Trail Whiskey Cove extcon driver connect USB data lines to
PMIC at driver probing for further charger detection. This causes reset of
USB data sessions and removing all devices from bus. If system was
booted from Live CD or USB dongle, this makes system unusable.
Check if USB ID pin i
Patch to prevent resetting USB connection if OTG device is connected
during of driver initialization.
v2:
Change (id == INTEL_USB_ID_FLOAT) check to (id != INTEL_USB_ID_GND) as
Hans de Goede advised.
> -Original Message-
> From: Denis Efremov
> Sent: Monday, September 16, 2019 4:42 PM
> To: Bjorn Helgaas
> Cc: Denis Efremov ; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org; Andrew Murray ;
> linux-hyp...@vger.kernel.org; KY Srinivasan ; Haiyang
> Zhang ; Stephen Hemminger
cfs_rq_clock_task() was first introduced in the commit f1b17280efbd
("sched: Maintain runnable averages across throttled periods"). Over
time, it has been graduately removed by the commits like,
d31b1a66cbe0 ("sched/fair: Factorize PELT update")
23127296889f ("sched/fair: Update scale invariance o
> On Sep 3, 2019, at 1:03 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2019-08-19 19:33:18 [-0500], Clark Williams wrote:
>> From: Clark Williams
>>
>> The following structures contain a member named 'irq_lock'.
>> These three locks are of type spinlock_t and are used in
>> multiple contex
On Mon, Sep 16, 2019 at 01:13:23PM -0700, Andrii Nakryiko wrote:
On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
wrote:
echo should be replaced with echo -e to handle '\n' correctly, but
instead, replace it with printf as some systems can't handle echo -e.
Signed-off-by: Ivan Khoronzhuk
---
Since we want to introduce master devices, rename macro so that we
have consistency between slave and master device access, following the
Grey Bus example.
Signed-off-by: Pierre-Louis Bossart
---
drivers/base/regmap/regmap-sdw.c | 4 ++--
drivers/soundwire/bus.c | 2 +-
drivers/soundwir
The current use of platform devices leads to limitations in terms of
API and problematic reference counts flagged during the review of
sysfs patches.
As suggested by Greg KH, this patch series introduces a 'Master
device' and gets rid of platform devices. The code is inspired by
GreyBus, e.g. 'gb_
Add clearer references to sdw_slave_driver for internal macros
No change for sdw_driver and module_sdw_driver to avoid compatibility
issues with existing codec devices
No functionality change.
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/bus_type.c | 21 +++--
Align with previous renames and shorten macro
No functionality change
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/bus_type.c | 9 -
include/linux/soundwire/sdw_type.h | 3 ++-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/soundwire/bus_type.c
Since we want an explicit support for the SoundWire Master device, add
the definitions, following the Grey Bus example.
Open: do we need to set a variable when dealing with the master uevent?
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/Makefile | 2 +-
drivers/soundwire/b
Use sdw_master_device and driver instead of platform devices
To quote GregKH:
"Don't mess with a platform device unless you really have no other
possible choice. And even then, don't do it and try to do something
else. Platform devices are really abused, don't perpetuate it "
In addition, rather
There are too many fields called 'res' so add prefix to make it easier
to track what the structures are.
Pure rename, no functionality change
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/intel.c | 37 +++--
1 file changed, 19 insertions(+), 18 deleti
Currently the bus does not have any explicit support for master
devices. Add explicit support for sdw_slave_type, so that in
follow-up patches we can add support for the sdw_md_type (md==Master
Device), following the Grey Bus example.
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/bu
Before we add master driver support, make sure there is no ambiguity
and no occirrences of sdw_drv_ functions.
No functionality change.
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/bus_type.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/s
From: Bard Liao
Setting an device driver is necessary for ASoC to register DAI
components.
Signed-off-by: Bard Liao
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/intel.c | 4
drivers/soundwire/master.c| 2 ++
include/linux/soundwire/sdw.h | 1 +
3 files changed, 7 ins
On Mon, Sep 16, 2019 at 10:41 AM Andy Lutomirski wrote:
>
> After some experimentation, I think y'all are just doing it wrong.
> GCC is very clever about this as long as it's given the chance. This
> test, for example, generates excellent code:
>
> #include
>
> __THROW __nonnull ((1)) __attribut
On Mon, 2019-09-16 at 21:51 +0200, Sebastian Andrzej Siewior wrote:
> On 2019-09-16 10:01:27 [-0400], Qian Cai wrote:
> > On Mon, 2019-09-16 at 11:03 +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-09-13 12:27:44 [-0400], Qian Cai wrote:
> > > …
> > > > Chain exists of:
> > > > random_write
When running on a system with >512MB RAM with a 32-bit kernel built with:
CONFIG_DEBUG_VIRTUAL=y
CONFIG_HIGHMEM=y
CONFIG_HARDENED_USERCOPY=y
all execve()s will fail due to argv copying into kmap()ed pages, and on
usercopy checking the calls ultimately of virt_to_page() wil
On Mon, 16 Sep 2019 13:51:58 -0700 (PDT)
Palmer Dabbelt wrote:
> On Mon, 16 Sep 2019 12:04:56 PDT (-0700), Darius Rad wrote:
> > On 9/15/19 2:20 PM, Marc Zyngier wrote:
> >> On Sun, 15 Sep 2019 18:31:33 +0100,
> >> Palmer Dabbelt wrote:
> >>
> >> Hi Palmer,
> >>
> >>>
> >>> On Sun, 15 Sep 20
> On 9/16/19, 04:35, "Michal Hocko" wrote:
> > diff --git a/mm/memory.c b/mm/memory.c
> > index e0c232fe81d9..55da24f33bc4 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -3311,6 +3311,8 @@ vm_fault_t alloc_set_pte(struct vm_fault *vmf,
> struct mem_cgroup *memcg,
The pull request you sent on Fri, 13 Sep 2019 09:42:29 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/edac_for_5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ff881842e12563f25d69a4e2e373f1ad392a7027
Thank you!
--
Deet-doot-dot, I am a bo
The pull request you sent on Mon, 16 Sep 2019 09:39:53 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git tags/i3c/for-5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/31dda85e49da949fdea5fd4e1fdeeabc44e59625
Thank you!
--
Deet-doot-dot, I am a b
The pull request you sent on Mon, 16 Sep 2019 00:03:31 +0100:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
> tags/regulator-v5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c4d11ccb2b5cec6cdef7aeeb0017473d23031d96
Thank you!
--
Deet-do
The pull request you sent on Mon, 16 Sep 2019 05:58:45 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
> tags/gpio-v5.4-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bbfe0d6b8b730af4954a0e0e741217eb3e1c58bc
Thank you!
--
Deet-doot-do
The pull request you sent on Sun, 15 Sep 2019 23:43:14 +0100:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
> tags/regmap-v5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0372fd1a70c4bc0731486851abe2048993f94a8d
Thank you!
--
Deet-doot-dot
The pull request you sent on Mon, 2 Sep 2019 17:31:21 +0300:
> git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a7bd4bcf138e7ec95c00d55fee158f6be378029b
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Tue, 10 Sep 2019 18:00:51 +0200:
> g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux
> tags/core-process-v5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c17112a5c413f20188da276c138484e7127cdc84
Thank you!
--
Deet-doot-
On Sep 16 2019, Andrii Nakryiko wrote:
> On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
> wrote:
>>
>> echo should be replaced with echo -e to handle '\n' correctly, but
>> instead, replace it with printf as some systems can't handle echo -e.
>>
>> Signed-off-by: Ivan Khoronzhuk
>> ---
>> sam
The pull request you sent on Fri, 13 Sep 2019 10:10:39 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8e97be2acd59e07539c5002e12ba6a9c0bb5e83b
Thank you!
--
Deet-doot-dot, I am a b
The pull request you sent on Mon, 16 Sep 2019 00:18:11 +0100:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aa62325dc38de2be8b1c27eb180ad3751b3f58ec
Thank you!
--
Deet-doot-dot, I am a
On Mon, 16 Sep 2019 12:40:10 PDT (-0700), sch...@suse.de wrote:
On Sep 16 2019, Palmer Dabbelt wrote:
On Sun, 15 Sep 2019 23:42:53 PDT (-0700), Christoph Hellwig wrote:
On Fri, Sep 13, 2019 at 01:40:27PM -0700, Palmer Dabbelt wrote:
OpenEmbedded passes "earlycon=sbi", which I can find in the
Dear RT Folks,
I'm pleased to announce the 4.19.72-rt25 stable release.
As you probably have noticed, it has been a long time since I released
a stable 4.19-rt. The reason for this delay is that one of my tests
failed after merging with the latest stable upstream. I refuse to push
r
On 9/16/19 4:51 PM, Palmer Dabbelt wrote:
> On Mon, 16 Sep 2019 12:04:56 PDT (-0700), Darius Rad wrote:
>> On 9/15/19 2:20 PM, Marc Zyngier wrote:
>>> On Sun, 15 Sep 2019 18:31:33 +0100,
>>> Palmer Dabbelt wrote:
>>>
>>> Hi Palmer,
>>>
On Sun, 15 Sep 2019 07:24:20 PDT (-0700), m...@kerne
syzbot has found a reproducer for the following crash on:
HEAD commit:f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=175cdb9560
kernel config: https://syzkaller.ap
This series builds on the 'soundwire: add Master device support,
GreyBus style' RFC'. It provides enhancements to the stream callbacks,
a split initialization. Most of the SOF patches were already submitted
in an earlier RFC, and feedback on the parameters was taken into
account. The main change he
From: Rander Wang
Rename 'config_stream' as 'params_stream' to be closer to ALSA/ASoC
concepts.
Add a 'free_stream' callback in case any resources allocated in the
'params_stream' stage need to be released.
Define structures for callbacks, mainly to allow for extensions as
needed.
Add the link
When interfaces can be pin-muxed, static information from ACPI might
not be enough. Add information on which links needs to be enabled by
hardware/firmware for a specific machine driver to be selected.
When walking through the list of possible machines, links will be
checked, which implies that co
For cases where an interface can be pin-muxed, we need to assess at
probe time which configuration should be used. In cases such as
SoundWire, we need to maintain an alternate list of machines and walk
through them when the primary detection based on ACPI _HID fails.
Signed-off-by: Pierre-Louis Bo
From: Rander Wang
It gets sdw runtime information from dai to prepare stream.
Signed-off-by: Rander Wang
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/intel.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel
Now that the SoundWire core supports the multi-step initialization,
call the relevant APIs.
The actual hardware enablement can be done in two places, ideally we'd
want to startup the IP as soon as possible but we need to work-out
additional hardware dependencies in corner cases. For the time being
For now we have a limited number of machine driver configurations, and
we can detect them based on the link configuration returned after
checking hardware and firmware (BIOS) configurations.
It's likely that in the future we will need to check for _ADR match as
well, which can easily be done by ex
These callbacks are invoked when a matching hw_params/hw_free() DAI
operation takes place, and will result in IPC operations with the SOF
firmware.
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/sof/intel/hda.c | 70 +++
1 file changed, 70 insertions(+)
di
From: Rander Wang
The sdw stream is allocated and stored in dai to share the sdw runtime
information.
Signed-off-by: Rander Wang
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/intel.c | 65 +++
1 file changed, 65 insertions(+)
diff --git a/drive
ALH was inserted in the wrong place during integration, add after DMIC
to mirror the file used by SOF firmware.
No functional change, just text move in the same file to better track
changes, if any.
Signed-off-by: Pierre-Louis Bossart
---
include/sound/sof/dai-intel.h | 18 +-
1
Select SoundWire capabilities on newer Intel platforms, starting with
CannonLake/CoffeeLake/CometLake.
As done for HDaudio, the SoundWire link is an opt-in capability. We
explicitly test for ACPI to avoid warnings on unmet dependencies on
the SoundWire side.
Signed-off-by: Pierre-Louis Bossart
-
From: Rander Wang
Make sure all calls to the SoundWire stream API are done and involve
callback
Signed-off-by: Rander Wang
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/intel.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/sound
From: Rander Wang
Sdw stream is enabled and disabled in trigger function.
Signed-off-by: Rander Wang
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/intel.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/soundwire/intel.c b/drive
Hi Linus,
Please pull this tiny gcc-plugins update for v5.4-rc1. It fixes a
potential problem in structure auto-selection (that was not triggered by
any existing kernel structures). This has been in linux-next for about 5
weeks.
Thanks!
-Kees
The following changes since commit 609488bc979f99f80
On Tue, 3 Sep 2019, Sultan Alsawaf wrote:
> From: Sultan Alsawaf
>
> Architecture-specific uaccess.h headers can have dependencies on
> linux/uaccess.h (i.e., VERIFY_WRITE), so it cannot be included directly.
> Since linux/uaccess.h includes asm/uaccess.h, just do that instead.
>
> This fixe
On Mon, Sep 16, 2019 at 01:35:21PM -0700, Andrii Nakryiko wrote:
On Mon, Sep 16, 2019 at 4:01 AM Ivan Khoronzhuk
wrote:
It can overlap with CFLAGS used for libraries built with gcc if
not now then in next patches. Correct it here for simplicity.
Signed-off-by: Ivan Khoronzhuk
---
With GCC
On Mon, Sep 16, 2019 at 2:35 PM Andreas Schwab wrote:
>
> On Sep 16 2019, Andrii Nakryiko wrote:
>
> > On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
> > wrote:
> >>
> >> echo should be replaced with echo -e to handle '\n' correctly, but
> >> instead, replace it with printf as some systems can'
On Mon, Sep 16, 2019 at 01:44:23PM -0700, Andrii Nakryiko wrote:
On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
wrote:
For arm, -D__LINUX_ARM_ARCH__=X is min version used as instruction
set selector and is absolutely required while parsing some parts of
headers. It's present in KBUILD_CFLAGS
On Mon, 2019-09-16 at 13:38 -0700, Linus Torvalds wrote:
> On Wed, Sep 11, 2019 at 2:29 PM Mimi Zohar wrote:
> >
> > The major feature in this pull request is IMA support for measuring
> > and appraising appended file signatures. In addition are a couple of
> > bug fixes and code cleanup to use s
On Mon, 16 Sep 2019 14:33:23 PDT (-0700), m...@kernel.org wrote:
On Mon, 16 Sep 2019 13:51:58 -0700 (PDT)
Palmer Dabbelt wrote:
On Mon, 16 Sep 2019 12:04:56 PDT (-0700), Darius Rad wrote:
> On 9/15/19 2:20 PM, Marc Zyngier wrote:
>> On Sun, 15 Sep 2019 18:31:33 +0100,
>> Palmer Dabbelt wrote:
On Mon, 16 Sep 2019 14:41:07 PDT (-0700), Darius Rad wrote:
On 9/16/19 4:51 PM, Palmer Dabbelt wrote:
On Mon, 16 Sep 2019 12:04:56 PDT (-0700), Darius Rad wrote:
On 9/15/19 2:20 PM, Marc Zyngier wrote:
On Sun, 15 Sep 2019 18:31:33 +0100,
Palmer Dabbelt wrote:
Hi Palmer,
On Sun, 15 Sep 201
On 9/10/19 4:31 PM, Mina Almasry wrote:
> Current behavior is that region_chg provides both a cache entry in
> resv->region_cache, AND a placeholder entry in resv->regions. region_add
> first tries to use the placeholder, and if it finds that the placeholder
> has been deleted by a racing region_de
On Thu, Aug 15, 2019 at 11:15:53AM -0700, Kees Cook wrote:
> With that out of the way, yes, let's do a mass conversion. As mentioned
> before, I think "fallthrough;" should be used here (to match "break;").
> Let's fork the C language. :)
FWIW, last week I asked Linus at the maintainer's summit wh
On 9/16/19 10:14 AM, Steve Wahl wrote:
> I'm intending to add something like this in the next version:
>
> /*
> * Only the region occupied by the kernel image has so far been checked
> against
> * the table of usable memory regions provided by the firmware, so
> * invalidate pages outside that
Hi Linus,
Please pull LED updates for 5.4-rc1.
There is one merge of tag with generic_lookup_helpers since
LED class has been made using class_find_device_by_name() helper:
Merge tag 'generic_lookup_helpers' into for-next
platform: Add platform_find_device_by_driver() helper
drivers
On 9/10/19 4:31 PM, Mina Almasry wrote:
> Remove duplicated code between region_chg and region_add, and refactor it into
> a common function, add_reservation_in_range. This is mostly done because
> there is a follow up change in this series that disables region
> coalescing in region_add, and I wan
On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > > I have attached the descriptions.
> >
> > Attachment is missing :)
>
> I saw it :)
>
> An
Hi all,
Changes since 20190915:
The arm64 tree acquired a conflict with the compiler-attributes tree.
The ia64 tree acquired a conflict with the dma-mapping tree.
The vfs tree acquired a conflict with the ubifds tree.
A workaround was applied for a merge issue between the drm and kbuild
trees
From: Peter Zijlstra
A bit in pwol_mask is set in b44_magic_pattern() by atomic set_bit().
But since pwol_mask is local and never exposed to concurrency, there is
no need to set bit in pwol_mask atomically.
set_bit() sets the bit in a single unsigned long location. Because
pwol_mask may not be a
From: Fenghua Yu
The x86_capability array in cpuinfo_x86 is defined as u32 and thus is
naturally aligned to 4 bytes. But, set_bit() and clear_bit() require
the array to be aligned to size of unsigned long (i.e. 8 bytes in
64-bit).
To fix the alignment issue, align the x86_capability array to siz
From: Fenghua Yu
cpu_caps_cleared[] and cpu_caps_set[] may not be aligned to unsigned long.
Atomic operations (i.e. set_bit() and clear_bit()) on the bitmaps may
access two cache lines (a.k.a. split lock) and cause the CPU to do a bus
lock to block all memory accesses from other processors to ens
This series is made up of three patches from Fenghua Yu's "Split lock"
series last posted here:
https://lore.kernel.org/kvm/1560897679-228028-1-git-send-email-fenghua...@intel.com/
Part 3 has been fixed to use a union to force alignment per
feedback from Thomas.
These parts are all simple fixes
On Mon, Sep 16, 2019 at 02:22:53AM +0100, Mark Brown wrote:
> Since it's very late and it seems useful to try to get a -next out with
> the state prior to the merge window opening I've used commit
> ec13c78d7b45 from the previous -next build rather than fix this up
> sorry, I'll come back to it to
On Fri, Sep 13, 2019 at 05:48:40AM +, S.j. Wang wrote:
> Hi
>
> >
> > On Tue, Sep 10, 2019 at 02:07:25AM +, S.j. Wang wrote:
> > > > On Mon, Sep 09, 2019 at 06:33:20PM -0400, Shengjiu Wang wrote:
> > > > > The ASRC support 24bit/16bit/8bit input width, so S20_3LE format
> > > > > should n
On Fri, Sep 13, 2019 at 10:28:05PM +0300, Daniel Baluta wrote:
> From: Mihai Serban
>
> EDMA requires the period size to be multiple of maxburst. Otherwise the
> remaining bytes are not transferred and thus noise is produced.
>
> We can handle this issue by adding a constraint on
> SNDRV_PCM_HW_
On Mon, Sep 16, 2019 at 12:59 PM H. Nikolaus Schaller
wrote:
> ping.
>
> Device omap3-gta04 is neither working with v5.3 nor linux-next quite a while
> and we need a solution.
Can't we just apply the last part of the patch in this thread:
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch
On Mon, Sep 16, 2019 at 5:46 PM Manivannan Sadhasivam
wrote:
> Add devicetree YAML binding for Actions Semi Owl SoC's SD/MMC/SDIO
> controller.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Linus Walleij
Neat use of yaml!
Yours,
Linus Walleij
On Fri, Sep 13, 2019 at 10:28:06PM +0300, Daniel Baluta wrote:
> From: Shengjiu Wang
>
> When Tx is synchronous with receiver the RMR should not be changed.
> When Rx is synchronous with transmitter the TMR should not be changed.
Would you please explain why and what bug this patch fixes?
We mig
The pull request you sent on Fri, 13 Sep 2019 11:20:15 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> tags/arm64-upstream
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e77fafe9afb53b7f4d8176c5cd5c10c43a905bc8
Thank you!
--
Deet-doot-dot,
The pull request you sent on Mon, 16 Sep 2019 20:29:32 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
> parisc-5.4-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d0a16fe934383ecdb605ab9312d700fb9099f75e
Thank you!
--
Deet-doot-dot,
The pull request you sent on Mon, 16 Sep 2019 10:42:15 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
> tags/m68k-for-v5.4-tag1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dbcda58ad98936079c48728c12c27a2f333fb484
Thank you!
--
Deet-d
The pull request you sent on Mon, 16 Sep 2019 08:20:33 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> tags/riscv/for-v5.4-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/58d4fafd0b4c36838077a5d7b17df537b7226f1c
Thank you!
--
Deet-
On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett wrote:
>
> The semantics many people want for secure key generation is urandom, but
> with a guarantee that it's seeded.
And that is exactly what I'd suggest GRND_SECURE should do.
The problem with:
> getrandom()'s default behaviour at present pro
Hello Daniel,
On Fri, Sep 13, 2019 at 10:28:07PM +0300, Daniel Baluta wrote:
> The SAI transmitter and receiver can be configured to operate with
> synchronous bit clock and frame sync.
>
> When Tx is synchronous with receiver RCSR.RE should be set in playback
> to enable the receiver which provi
On Mon, Sep 16, 2019 at 04:05:47PM -0700, Linus Torvalds wrote:
> On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett wrote:
> > Changing the default (even with kernel warnings) seems like
> > it risks people generating keys from an unseeded prng, and that seems
> > like a bad thing?
>
> I agree that
From: Randy Dunlap
Call uart_unregister_driver() conditionally instead of
unconditionally, only if it has been previously registered.
This uses driver.state, just as the sh-sci.c driver does.
Fixes this null pointer dereference in tty_unregister_driver(),
since the 'driver' argument is null:
17.09.2019 04:11, Matthew Garrett пишет:
In one case we have "Systems don't boot, but you can downgrade your
kernel"
You can't. There are way too many dedicated server providers where there
is no IPMI or any equivalent, and the only help that the staff can do is
to reinstall, wiping your data
On Mon, Sep 16, 2019 at 2:30 PM Linus Torvalds
wrote:
>
> On Mon, Sep 16, 2019 at 10:41 AM Andy Lutomirski wrote:
> >
> > After some experimentation, I think y'all are just doing it wrong.
> > GCC is very clever about this as long as it's given the chance. This
> > test, for example, generates e
On Tue, Sep 17, 2019 at 04:13:36AM +0500, Alexander E. Patrakov wrote:
> 17.09.2019 04:11, Matthew Garrett пишет:
> > In one case we have "Systems don't boot, but you can downgrade your
> > kernel"
>
> You can't. There are way too many dedicated server providers where there is
> no IPMI or any equ
On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett wrote:
>
> In one case we have "Systems don't boot, but you can downgrade your
> kernel" and in the other case we have "Your cryptographic keys are weak
> and you have no way of knowing unless you read dmesg", and I think
> causing boot problems is t
On Mon, Sep 16, 2019 at 4:14 PM Andy Lutomirski wrote:
>
> Well, when I wrote this email, I *thought* it was inlining the
> 'memset' function, but maybe I just can't read gcc's output today.
Not having your compiler, it's also possible that it works for you,
but just doesn't work for me.
> It se
On Mon, Sep 16, 2019 at 04:18:00PM -0700, Linus Torvalds wrote:
> On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett wrote:
> >
> > In one case we have "Systems don't boot, but you can downgrade your
> > kernel" and in the other case we have "Your cryptographic keys are weak
> > and you have no way o
On Mon, Sep 16, 2019 at 10:44:31AM -0700, Linus Torvalds wrote:
> - admit that the current situation actually causes problems, and has
> _existing_ bugs.
>
> - throw it out the window, with the timeout and big BIG warning when
> the problem cases trigger
The semantics many people want for secur
On Mon, Sep 16, 2019 at 07:45:37AM +, Robin Gong wrote:
> On 2019/9/13 15:31 robin wrote:>
> > Hi Dmitry,
> >
> > On 2019-09-12 22:13, Dmitry Torokhov wrote:
> > > Hi Robin,
> > >
> > > On Wed, Sep 04, 2019 at 06:23:29AM +, Robin van der Gracht wrote:
> > >> The first generation i.MX6 pr
Hello,
syzbot found the following crash on:
HEAD commit:2015a28f Add linux-next specific files for 20190915
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10f1dc6560
kernel config: https://syzkaller.appspot.com/x/.config?x=110691c2286b679a
dashboard
Hello,
syzbot found the following crash on:
HEAD commit:1609d760 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10236abe60
kernel config: https://syzkaller.appspot.com/x/.config?x=ed2b148cd67382ec
da
On 9/10/19 5:31 PM, Mina Almasry wrote:
These counters will track hugetlb reservations rather than hugetlb
memory faulted in. This patch only adds the counter, following patches
add the charging and uncharging of the counter.
Why are we adding these counters? I see the reasons in the cover let
601 - 700 of 847 matches
Mail list logo
